From dburrows at debian.org Thu Nov 5 16:22:37 2009 From: dburrows at debian.org (Daniel Burrows) Date: Thu, 5 Nov 2009 08:22:37 -0800 Subject: [Aptitude-devel] Screenshot support is in the tree. Message-ID: <20091105162237.GA15234@emurlahn.burrows.local> Hello list, I've been silent for a while due to a combination of real life stuff and being too busy coding to write about coding. :) Anyway, I thought you all might be interested to know that I have just completed and checked in an initial implementation of screenshot support for aptitude. Aside from where the screenshots show up in the interface (only "Page 6" of the package information tab right now) and a few minor internal tweaks I want to make, everything else seems to work. This took longer than I expected, mostly because I ended up forcing myself to do it "right". This led to a bunch of follow-on changes: * enhancements to the file cache, which can now store last-modified dates (so we don't miss updated screenshots) * a global download queue for aptitude, with support for checking last-modified dates, announcing download status to the main thread, canceling downloads in progress, merging downloads of the same URI, adding new downloads to an existing queue, etc. (basically a bunch of machinery to safely run an Acquire process in the background while still letting you inject into it) * a global cache of screenshot downloads for the GTK+ interface, to avoid loading the same screenshot into memory twice. Note that a global queue is probably the "right" solution here, since the resources being accessed (network and disk) are also global. I think the download queue will be very nice for any future changes that involve downloading from the network. It could also be used to enhance changelog downloads, although I don't think that's a high enough priority item to actually do it right now. :-) Daniel From intervyu at yahoo.com Fri Nov 6 16:51:50 2009 From: intervyu at yahoo.com (cursuri perfectionare) Date: Fri, 6 Nov 2009 18:51:50 +0200 Subject: [Aptitude-devel] invitatie la cursuri gratuite online Message-ID: <20091105.XWYRNFCWNGUMEPMY@yahoo.com> An HTML attachment was scrubbed... URL: From ocampagne at gmail.com Fri Nov 13 19:27:01 2009 From: ocampagne at gmail.com (Omar Campagne) Date: Fri, 13 Nov 2009 20:27:01 +0100 Subject: [Aptitude-devel] Pictures and update of the Spanish translation. Message-ID: <20091113192701.GB6539@gmail.com> Hello: Sorry it took so long to make the pictures, I've been negligent. I hope this pics and the es.diff can make it to the repo's the next bugfix release. Due to the size of the attachments, I've uploaded them to dropbox. I am CCing the list, since you didn't apply the last es.po diff I sent and I haven't heard from you in a while (we are all busy :), so please Daniel, don't be shy and upload it :) Although the Spanish translation is complete, this diff (rather big) adds many fixes and corrections after its endeavour through the debian-l10n-spanish list and my 2 or 3 consecutive readings. I would very much appreciate to see it in, as it greatly polishes the translation. It's huge size for a diff is due to some strings changing shape after msgmerge's work. No problem, but not real corrections in some cases. I'm afraid not all the pictures are reproducible (packages that don't exist, relationships that are not there anymore) so I'll just use the original ones in that situation (which are self-explained cases). The original pics are also included in the tar.gz, so you only need to drop the contents in. There is the es.diff [1], backed against latest sources, the complete es.po [2] (just in case), and the pictures tar.gz file [3]. [1] http://dl.dropbox.com/u/430223/es.diff [2] http://dl.dropbox.com/u/430223/es.po [3] http://dl.dropbox.com/u/430223/aptitude-images.tar.gz Best regards, Omar. -- "Why stop now just when I'm hating it?" -- Marvin The Paranoid Android From jensseidel at users.sf.net Sat Nov 14 12:54:03 2009 From: jensseidel at users.sf.net (Jens Seidel) Date: Sat, 14 Nov 2009 13:54:03 +0100 Subject: [Aptitude-devel] Pictures and update of the Spanish translation. In-Reply-To: <20091113192701.GB6539@gmail.com> References: <20091113192701.GB6539@gmail.com> Message-ID: <20091114125402.GA18410@merkur.sol.de> Hi Omar, On Fri, Nov 13, 2009 at 08:27:01PM +0100, Omar Campagne wrote: > Sorry it took so long to make the pictures, I've been negligent. I hope > this pics and the es.diff can make it to the repo's the next bugfix > release. thanks, I committed it and sorry for being silent so long. Please check that I did everything right (at least I tested via "make distcheck"). Jens From TheCuteKid at iammyownboss.co.uk Sat Nov 14 18:35:12 2009 From: TheCuteKid at iammyownboss.co.uk (TheCuteKid at iammyownboss.co.uk) Date: Sat, 14 Nov 2009 18:35:12 +0000 Subject: [Aptitude-devel] Cute Kid of the Year - enter to win $25,000 Message-ID: Welcome to The CuteKid, the internet?s largest online child photo contest! Judged by professional talent and casting agents. Do you have a Cute Kid? If so, we invite you to join our growing community of loving parents just like you by submitting a photo of YOUR cute kid for a chance to win a $25,000 College Tuition Fund! Submit your photo today! Enter today and receive instant rewards like a 1 year subscription to Parenting Magazine and a 8X10 Canvas portrait of your photo. If you have a cute kid that is just waiting to be discovered, don?t delay. Membership is free and easy ? Sign Up Today! For more information about the 2008 CuteKid? of the Year Contest, please visit our How it Works page. If you seek more information including our address, Click here. -- If you do not want to receive any more newsletters, http://www.solduk.com/design/mailer/?p=unsubscribe&uid=ef33c9a6db3596d37051342d232c9bda To update your preferences and to unsubscribe visit http://www.solduk.com/design/mailer/?p=preferences&uid=ef33c9a6db3596d37051342d232c9bda Forward a Message to Someone http://www.solduk.com/design/mailer/?p=forward&uid=ef33c9a6db3596d37051342d232c9bda&mid=4 -- Powered by PHPlist, www.phplist.com -- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: powerphplist.png Type: image/png Size: 2408 bytes Desc: not available URL: From ocampagne at gmail.com Sat Nov 14 23:00:17 2009 From: ocampagne at gmail.com (Omar Campagne) Date: Sun, 15 Nov 2009 00:00:17 +0100 Subject: [Aptitude-devel] Pictures and update of the Spanish translation. In-Reply-To: <20091114125402.GA18410@merkur.sol.de> References: <20091113192701.GB6539@gmail.com> <20091114125402.GA18410@merkur.sol.de> Message-ID: <20091114230017.GC15647@gmail.com> > Please check that > I did everything right (at least I tested via "make distcheck"). Looks fine to me running po4a and xsltproc. Instead of the blank space where the picture should go, I got the small area with the word "image" in it, as in the original built version. I suppose pics get added with another process (in case you didn't notice, I'm not really techy :) I ran ./configure (to see them with pics) following instructions in README, and got ./configure: line 7511: syntax error near unexpected token `AX_BOOST_IOSTREAMS' ./configure: line 7511: `AX_BOOST_IOSTREAMS' Regards, Omar From dburrows at debian.org Sun Nov 15 19:46:36 2009 From: dburrows at debian.org (Daniel Burrows) Date: Sun, 15 Nov 2009 11:46:36 -0800 Subject: [Aptitude-devel] Screenshot support is in the tree. In-Reply-To: <20091105162237.GA15234@emurlahn.burrows.local> References: <20091105162237.GA15234@emurlahn.burrows.local> Message-ID: <20091115194636.GA19243@hummingbird> Just a quick update on this. I've got pretty much everything thrashed out here. However, there is a problem with the background download queue, where it sometimes gets "stuck" and can't download any more screenshots. In fact, I often get this the second time I look at a screenshot. I think this may be related to abusing apt's Acquire system in ways that it was never supposed to be abused, but I haven't tracked down exactly what's happening or how to work around it. Daniel From jensseidel at users.sf.net Sun Nov 15 20:01:57 2009 From: jensseidel at users.sf.net (Jens Seidel) Date: Sun, 15 Nov 2009 21:01:57 +0100 Subject: [Aptitude-devel] Pictures and update of the Spanish translation. In-Reply-To: <20091114230017.GC15647@gmail.com> References: <20091113192701.GB6539@gmail.com> <20091114125402.GA18410@merkur.sol.de> <20091114230017.GC15647@gmail.com> Message-ID: <20091115200154.GA19880@merkur.sol.de> On Sun, Nov 15, 2009 at 12:00:17AM +0100, Omar Campagne wrote: > > Please check that > > I did everything right (at least I tested via "make distcheck"). > Looks fine to me running po4a and xsltproc. Instead of the blank space where > the picture should go, I got the small area with the word "image" in it, > as in the original built version. I suppose pics get added with another > process (in case you didn't notice, I'm not really techy :) Calling make (e.g. in doc/es) is sufficient to get images in the generated html files, at least with the current Makefiles (or for English even with old ones). > I ran ./configure (to see them with pics) following instructions in > README, and got > > ./configure: line 7511: syntax error near unexpected token `AX_BOOST_IOSTREAMS' > ./configure: line 7511: `AX_BOOST_IOSTREAMS' I suggest you start ./autogen.sh before as this generates ./configure. Apart from this nothing else should be required. Jens From dburrows at debian.org Sun Nov 15 20:42:38 2009 From: dburrows at debian.org (Daniel Burrows) Date: Sun, 15 Nov 2009 12:42:38 -0800 Subject: [Aptitude-devel] Acquire considered non-threadsafe Message-ID: <20091115204237.GB19243@hummingbird> For the last few years, aptitude has been running apt's Acquire queue in a background thread, with the idea that doing so would provide more responsiveness in the UI. I had assumed (yes, you can slap me now) that this would be OK, since a download queue "shouldn't need" to access global resources. However, today I happened to be reading through the Acquire code to track down an unrelated aptitude problem, and I noticed that in fact the Acquire code is completely non-threadsafe: it is never safe to use it in a different thread from any other libapt function. (please note: by "threadsafe" I mean "safe to use in a multi-threaded program", not the more stringent "safe to access from multiple threads at once", which isn't necessary for Acquire) I haven't performed a full audit, but the Acquire code *at least* uses the global _error variable: (1) If _error->PendingError() is true, the download loop will abort and return Failed. This means that if some other thread inserts an error into the global error queue, the Acquire process will fail for no obvious reason. (2) Various Item subclasses add errors in their status callbacks, which could cause race conditions with any other thread that inserts errors into the global queue. At best, this will lead to an error item being leaked and dropped from the queue. Also, several Item subclasses test for the existence of errors before deciding whether to proceed. I'm guessing that these haven't shown up until now as a problem because you need very specific timing for them to matter, and most users probably don't do anything that would cause trouble while aptitude is downloading. But these are still definitely bugs IMO. In particular, since the Pulse() callback could invoke arbitrary user code (and indeed will normally drive the program's GUI while it's running), (1) is a problem even for single-threaded apt clients. Any action the user takes that generates errors in the global queue has the potential to interrupt an ongoing download. I guess in the single-threaded case, you can flush the error queue on the way out of Pulse(), but I still don't like it. I'm not sure what the best way to deal with this is. I'd really like to redesign Acquire to be thread-safe (and not to suck in various other ways), but there would be a significant chance of breaking existing users of the class. For instance, a custom Item object that relied on inserting errors to ask the download to fail would no longer work properly. One option is to design more sensible behavior, then allow client code to request it on an opt-in basis. Let users of the Acquire class enable a "threadsafe" mode that changes its behavior to be more sensible: throw out the global error queue for a start, but I'll want to audit all this code to ensure that it's safe for multithreaded programs. This might also involve writing new versions of existing routines to pass error information back explicitly. For instance, I notice that we need to test _error to find out whether pkgRecords::Lookup succeeded. It should really return an extra value indicating whether the lookup succeeded, or just return a pointer that's NULL if the lookup failed. There are some other very nice options involving rewriting or reimplementing the "download queue" logic (i.e., just pkgAcquire), but getting threadsafety does require changing the behavior of pkgAcquire::Item in any event. I'm assuming that we don't want to have two parallel implementations of this functionality, and that non-backwards-compatible changes are considered unacceptable, in which case the opt-in approach is the only solution I can think of. It would also be good, IMO, to modify the error class to be threadsafe no matter what. A simple mutex could handle that. Once I get the next major release of aptitude out, I want to take a crack at this; I hate knowing that the program contains obscure race conditions. Daniel From ocampagne at gmail.com Sun Nov 15 22:23:00 2009 From: ocampagne at gmail.com (Omar Campagne) Date: Sun, 15 Nov 2009 23:23:00 +0100 Subject: [Aptitude-devel] Pictures and update of the Spanish translation. In-Reply-To: <20091115200154.GA19880@merkur.sol.de> References: <20091113192701.GB6539@gmail.com> <20091114125402.GA18410@merkur.sol.de> <20091114230017.GC15647@gmail.com> <20091115200154.GA19880@merkur.sol.de> Message-ID: <20091115222300.GA5136@gmail.com> > I suggest you start ./autogen.sh before as this generates ./configure. Apart > from this nothing else should be required. Cheers, I went crazy the other day, and today I realized I had aclocal1.11, and this time I was able to call autogen. The reflection of my knowledge... Pictures are finely inserted, yet the quality is poor since I had to make them so light yet big, as in the original. Still, they get the point across. Thanks for the tips Jens, there have been a few so far :). Omar From jensseidel at users.sf.net Mon Nov 16 06:03:01 2009 From: jensseidel at users.sf.net (Jens Seidel) Date: Mon, 16 Nov 2009 07:03:01 +0100 Subject: [Aptitude-devel] Pictures and update of the Spanish translation. In-Reply-To: <20091115222300.GA5136@gmail.com> References: <20091113192701.GB6539@gmail.com> <20091114125402.GA18410@merkur.sol.de> <20091114230017.GC15647@gmail.com> <20091115200154.GA19880@merkur.sol.de> <20091115222300.GA5136@gmail.com> Message-ID: <20091116060259.GA20812@merkur.sol.de> On Sun, Nov 15, 2009 at 11:23:00PM +0100, Omar Campagne wrote: > Pictures are finely inserted, yet the quality is poor since I had to > make them so light yet big, as in the original. Yep, I noticed this too but assumed a browser problem. How did you created the images? Have you reduced the resolution to keep these small? Maybe you can use pictures which higher resolution and apply the tool optipng to better compress the PNGs. Daniel wrote yesterday about snapshot support but I think he doesn't refer to snapshots of aptitude so that these cannot automatically created, right? > Still, they get the point across. Thanks for the tips Jens, there have > been a few so far :). Another one: Test also the install target of the Makefile (installs into the drectory given via configure's option --prefix or /usr/local) and verify that the images look fine. I initially forget about it :-) Jens From ocampagne at gmail.com Mon Nov 16 13:50:17 2009 From: ocampagne at gmail.com (Omar Campagne) Date: Mon, 16 Nov 2009 14:50:17 +0100 Subject: [Aptitude-devel] Pictures and update of the Spanish translation. In-Reply-To: <20091116060259.GA20812@merkur.sol.de> References: <20091113192701.GB6539@gmail.com> <20091114125402.GA18410@merkur.sol.de> <20091114230017.GC15647@gmail.com> <20091115200154.GA19880@merkur.sol.de> <20091115222300.GA5136@gmail.com> <20091116060259.GA20812@merkur.sol.de> Message-ID: <20091116135017.GA23431@gmail.com> > How did you created > the images? Have you reduced the resolution to keep these small? Maybe you > can use pictures which higher resolution and apply the tool optipng to better > compress the PNGs. Thanks for the tip, I'm already looking at optipng. I used gimp to resize the image, and then I changed mode RGB colors for indexed to further reduce the size (in bytes) of the image. I will retake the pics and use optipng, see if I can get a better quality. I think the biggest issue with quality is that I have to set a 400-300 (rough count) size for the image, and then reduce color quality to make it have the mere 10-15 kb they are supposed to have. My pictures are actually heavier than Daniel's. However, once the documentation is built, the pictures are resized in the manual, taking all the width it can (and corresponding height). Because of that, they look bad. Small pic way too resized. Daniel, is there any reason why you wanted such big pics in the manual? Sometimes they are so big I cannot view them in the screen. > Another one: Test also the install target of the Makefile (installs into the > drectory given via configure's option --prefix or /usr/local) and verify > that the images look fine. I initially forget about it :-) I will do so and mail back, thanks. Omar -- "Why stop now just when I'm hating it?" -- Marvin The Paranoid Android From dburrows at debian.org Tue Nov 17 02:30:47 2009 From: dburrows at debian.org (Daniel Burrows) Date: Mon, 16 Nov 2009 18:30:47 -0800 Subject: [Aptitude-devel] Pictures and update of the Spanish translation. In-Reply-To: <20091116060259.GA20812@merkur.sol.de> References: <20091113192701.GB6539@gmail.com> <20091114125402.GA18410@merkur.sol.de> <20091114230017.GC15647@gmail.com> <20091115200154.GA19880@merkur.sol.de> <20091115222300.GA5136@gmail.com> <20091116060259.GA20812@merkur.sol.de> Message-ID: <20091117023047.GA382@hummingbird> On Mon, Nov 16, 2009 at 07:03:01AM +0100, Jens Seidel was heard to say: > Daniel wrote yesterday about snapshot support but I think he doesn't refer > to snapshots of aptitude so that these cannot automatically created, right? No, I was talking about a new feature in the upcoming release where the GTK+ frontend can download and display package screenshots automatically from screenshot.debian.net. Daniel From dburrows at debian.org Tue Nov 17 02:35:22 2009 From: dburrows at debian.org (Daniel Burrows) Date: Mon, 16 Nov 2009 18:35:22 -0800 Subject: [Aptitude-devel] Pictures and update of the Spanish translation. In-Reply-To: <20091116135017.GA23431@gmail.com> References: <20091113192701.GB6539@gmail.com> <20091114125402.GA18410@merkur.sol.de> <20091114230017.GC15647@gmail.com> <20091115200154.GA19880@merkur.sol.de> <20091115222300.GA5136@gmail.com> <20091116060259.GA20812@merkur.sol.de> <20091116135017.GA23431@gmail.com> Message-ID: <20091117023522.GB382@hummingbird> On Mon, Nov 16, 2009 at 02:50:17PM +0100, Omar Campagne was heard to say: > > How did you created > > the images? Have you reduced the resolution to keep these small? Maybe you > > can use pictures which higher resolution and apply the tool optipng to better > > compress the PNGs. > > Thanks for the tip, I'm already looking at optipng. I used gimp to > resize the image, and then I changed mode RGB colors for indexed to > further reduce the size (in bytes) of the image. The images I took are just raw screenshots, no postprocessing involved. If I remember correctly, they were taken using the Gnome screenshot tool in an 80x24 xterm with the default font. > However, once the documentation is built, the pictures are resized in > the manual, taking all the width it can (and corresponding height). > Because of that, they look bad. Small pic way too resized. > > Daniel, is there any reason why you wanted such big pics in the manual? > Sometimes they are so big I cannot view them in the screen. No. I believe that what you're seeing there is just the default output of the docbook XSL stylesheets (they appear to set all screenshots / images to take up the full page width). Probably a little spelunking in their docs would turn up the parameter that needs to change to adjust this behavior. Daniel From ocampagne at gmail.com Tue Nov 17 02:55:34 2009 From: ocampagne at gmail.com (Omar Campagne) Date: Tue, 17 Nov 2009 03:55:34 +0100 Subject: [Aptitude-devel] Pictures and update of the Spanish translation. In-Reply-To: <20091117023522.GB382@hummingbird> References: <20091113192701.GB6539@gmail.com> <20091114125402.GA18410@merkur.sol.de> <20091114230017.GC15647@gmail.com> <20091115200154.GA19880@merkur.sol.de> <20091115222300.GA5136@gmail.com> <20091116060259.GA20812@merkur.sol.de> <20091116135017.GA23431@gmail.com> <20091117023522.GB382@hummingbird> Message-ID: <20091117025534.GA3619@gmail.com> > The images I took are just raw screenshots, no postprocessing > involved. If I remember correctly, they were taken using the Gnome > screenshot tool in an 80x24 xterm with the default font. My pictures turn to be way heavier than yours. Up to 38 Kb. Yours go up to 14 kb, as well as the french translation. That's why my postprocess. I used gnome-screenshot as well, but on gnome-terminal(?) I'll try xterm. > screenshots / images to take up the full page width). Probably a > little spelunking in their docs would turn up the parameter that needs > to change to adjust this behavior. http://www.sagehill.net/docbookxsl/ImageSizing.html Found this around. Omar -- "Why stop now just when I'm hating it?" -- Marvin The Paranoid Android From jak at debian.org Wed Nov 18 15:03:05 2009 From: jak at debian.org (Julian Andres Klode) Date: Wed, 18 Nov 2009 16:03:05 +0100 Subject: [Aptitude-devel] Acquire considered non-threadsafe In-Reply-To: <20091115204237.GB19243@hummingbird> References: <20091115204237.GB19243@hummingbird> Message-ID: <20091118131543.GA4996@debian.org> On Sun, Nov 15, 2009 at 12:42:38PM -0800, Daniel Burrows wrote: > There are some other very nice options involving rewriting or > reimplementing the "download queue" logic (i.e., just pkgAcquire), but > getting threadsafety does require changing the behavior of > pkgAcquire::Item in any event. I'm assuming that we don't want to have > two parallel implementations of this functionality, and that > non-backwards-compatible changes are considered unacceptable, in which > case the opt-in approach is the only solution I can think of. We should really start talking about APT 0.8 sometime soon, and break some APIs. The problem I have with Acquire is its low speed when queuing items which is probably caused by the use of a linked list (20000 items take multiple minutes to be queued, whereas APT2 queues them in less than a second[1]). Other ideas: (a) a common abstract base class for the *Summation classes (b) a new cache format which can be resized in reality (c) new dependency resolver [porting aptitude's one?] (d) external dependency resolvers (e) new buildsystem (e.g. raw autotools) and reworked packaging (f) storing errno inside the error handling objects, for bindings (nice to have errno). The whole thing could be targeted for Squeeze+1, i.e. for 2012; with 0.8.0 in November 2010; so we have one additional year to stabilize things again. But I don't think anyone wants to do this. [1] APT2 only has a sequential fetcher with one queue (an array-using list) at the moment, it may be a bit slower once there are multiple workers and queues. But I don't expect it to be as slow as APT's. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. From dburrows at debian.org Thu Nov 19 12:31:13 2009 From: dburrows at debian.org (Daniel Burrows) Date: Thu, 19 Nov 2009 04:31:13 -0800 Subject: [Aptitude-devel] Acquire considered non-threadsafe In-Reply-To: <20091118131543.GA4996@debian.org> References: <20091115204237.GB19243@hummingbird> <20091118131543.GA4996@debian.org> Message-ID: <20091119123112.GC13897@hummingbird> On Wed, Nov 18, 2009 at 04:03:05PM +0100, Julian Andres Klode was heard to say: > On Sun, Nov 15, 2009 at 12:42:38PM -0800, Daniel Burrows wrote: > > There are some other very nice options involving rewriting or > > reimplementing the "download queue" logic (i.e., just pkgAcquire), but > > getting threadsafety does require changing the behavior of > > pkgAcquire::Item in any event. I'm assuming that we don't want to have > > two parallel implementations of this functionality, and that > > non-backwards-compatible changes are considered unacceptable, in which > > case the opt-in approach is the only solution I can think of. > > We should really start talking about APT 0.8 sometime soon, and break > some APIs. The problem I have with Acquire is its low speed when queuing > items which is probably caused by the use of a linked list (20000 items > take multiple minutes to be queued, whereas APT2 queues them in less than > a second[1]). Acquire is also really painful to develop against, although that's more just the general pain of dealing with apt. Also, apt2? When did that happen? > (a) a common abstract base class for the *Summation classes Sounds reasonable. > (b) a new cache format which can be resized in reality I wonder if apt really needs an mmap'd cache here. In fact, I wonder about using sqlite -- I did a little experimentation with it and got decent performance. The big problem (from my point of view) would be teaching client code to treat the database transactionally rather than as a linked set of in-memory objects, but it way more cleaner and more flexible than what we have now. (I know I came down on this last time it was mentioned here, but I've done a bit of work with sqlite since then and I have a lot of respect for it) If an mmap'd cache really is desired, I suggest looking at Boost.Interprocess, which provides all sorts of routines for dealing with mmap'd memory segments. > (c) new dependency resolver [porting aptitude's one?] > (d) external dependency resolvers > (e) new buildsystem (e.g. raw autotools) and reworked > packaging Those sound very good. > (f) storing errno inside the error handling objects, > for bindings (nice to have errno). Please, please, kill the global error queue. This is a disaster from a threadsafety point of view, but also just from a general design perspective. There's way too much code that does if(!_error->PendingError()) fail(); when the error could have been caused by something entirely unrelated to what this code is interested in. Put error-handling oun either a return-code basis or an exception basis, but not this wird intermediate thing where random errors cause failure. If you want to know about inner errors, use a logging framework (I prefer log4cxx). I would add one more item: (g) use modern C++ coding conventions (at least for new code) apt was designed in 1996 or so, and it shows. Modern C++ is a lot cleaner, easier to maintain and easier to write than the weird mishmash of C and "object-oriented programming" that apt is written in. Also, a lot of modern C++ programs link against Boost, which provides a ton of well-designed utility libraries for stuff that you would otherwise have to write yourself, and that you'd end up writing badly. (apt-pkg/contrib/ is full of that sort of thing) > But I don't think anyone wants to do this. Personally, I would totally love to clean up the apt code and fix some of my chronic annoyances with it. I just don't have the spare time, and apparently neither does anyone else (except some guy who thinks it should be written in Perl (!?!?)). :-( Daniel From jackyf at debian.org Thu Nov 19 16:03:05 2009 From: jackyf at debian.org (Eugene V. Lyubimkin) Date: Thu, 19 Nov 2009 18:03:05 +0200 Subject: [Aptitude-devel] Acquire considered non-threadsafe In-Reply-To: <20091119123112.GC13897@hummingbird> References: <20091115204237.GB19243@hummingbird> <20091118131543.GA4996@debian.org> <20091119123112.GC13897@hummingbird> Message-ID: <4B056C39.9090704@debian.org> Daniel Burrows wrote: > Personally, I would totally love to clean up the apt code and fix > some of my chronic annoyances with it. I just don't have the spare > time, and apparently neither does anyone else (except some guy who > thinks it should be written in Perl (!?!?)). :-( It's apparently /me, so I am answering to this: no, I wrote/am writing a partial APT replacement in Perl, that's all. I don't think it should/must be written in some language. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From jak at debian.org Thu Nov 19 17:09:42 2009 From: jak at debian.org (Julian Andres Klode) Date: Thu, 19 Nov 2009 18:09:42 +0100 Subject: [Aptitude-devel] Acquire considered non-threadsafe In-Reply-To: <20091119123112.GC13897@hummingbird> References: <20091115204237.GB19243@hummingbird> <20091118131543.GA4996@debian.org> <20091119123112.GC13897@hummingbird> Message-ID: <20091119141657.GA4136@debian.org> On Thu, Nov 19, 2009 at 04:31:13AM -0800, Daniel Burrows wrote: > On Wed, Nov 18, 2009 at 04:03:05PM +0100, Julian Andres Klode was heard to say: > > On Sun, Nov 15, 2009 at 12:42:38PM -0800, Daniel Burrows wrote: > > > There are some other very nice options involving rewriting or > > > reimplementing the "download queue" logic (i.e., just pkgAcquire), but > > > getting threadsafety does require changing the behavior of > > > pkgAcquire::Item in any event. I'm assuming that we don't want to have > > > two parallel implementations of this functionality, and that > > > non-backwards-compatible changes are considered unacceptable, in which > > > case the opt-in approach is the only solution I can think of. > > > > We should really start talking about APT 0.8 sometime soon, and break > > some APIs. The problem I have with Acquire is its low speed when queuing > > items which is probably caused by the use of a linked list (20000 items > > take multiple minutes to be queued, whereas APT2 queues them in less than > > a second[1]). > > Acquire is also really painful to develop against, although that's > more just the general pain of dealing with apt. > > Also, apt2? When did that happen? APT2 will be a package management library + applications written in Vala, but at the moment it's just a few parsers and a simple acquire system. And it's intented to be cross-distro, just like PackageKit. I just had no better name when I started it. It's currently MIT-licensed, but may switch to the LGPL-2.1+ soon (as this is what all its dependencies like glib use). Code is at http://git.debian.org/?p=users/jak/apt2.git;a=summary, but it is slightly outdated compared to my local branch (which is LGPL-2.1+ licensed). > > > (b) a new cache format which can be resized in reality > > I wonder if apt really needs an mmap'd cache here. In fact, I wonder > about using sqlite -- I did a little experimentation with it and got > decent performance. The big problem (from my point of view) would be > teaching client code to treat the database transactionally rather than > as a linked set of in-memory objects, but it way more cleaner and more > flexible than what we have now. Working with databases is a bit complicated. It makes development not really convenient. > > > (c) new dependency resolver [porting aptitude's one?] > > (d) external dependency resolvers > > (e) new buildsystem (e.g. raw autotools) and reworked > > packaging > > Those sound very good. I already have a CMake buildsystem in the works which can already build apt-pkg and apt-inst. I expect this to be able to replace the current one and build exactly the same packages afterwards; so backwards compatibility is preserved. I will publish a new branch soon. I chose CMake because it does not require hundreds of files in the tree or shipping generated files. And it also appears to be faster. > > > (f) storing errno inside the error handling objects, > > for bindings (nice to have errno). > > Please, please, kill the global error queue. This is a disaster from > a threadsafety point of view, but also just from a general design > perspective. There's way too much code that does > > if(!_error->PendingError()) > fail(); > > when the error could have been caused by something entirely unrelated > to what this code is interested in. > > Put error-handling oun either a return-code basis or an exception > basis, but not this wird intermediate thing where random errors cause > failure. If you want to know about inner errors, use a logging > framework (I prefer log4cxx). As far as I can tell from the documentation, the APT error handling should only be used for boolean functions. If the function has an error, it pushes a message to the error stack and returns false. If we used it this way only, we would have no multi-threading problems. Exceptions are a bit tricky in C++ as they can happen unexpectedly. Google's C++ style guide says no; so we should probably also say no. Log4cxx would effectively cause APT binaries to be GPL-3+ licensed, as GPL-2 is incompatible with the Apache License. This could be a problem for GPL-2 only programs using them. But it may still be worth it. > > > I would add one more item: > > (g) use modern C++ coding conventions (at least for new code) > > apt was designed in 1996 or so, and it shows. Modern C++ is a lot > cleaner, easier to maintain and easier to write than the weird mishmash > of C and "object-oriented programming" that apt is written in. Also, > a lot of modern C++ programs link against Boost, which provides a ton > of well-designed utility libraries for stuff that you would otherwise > have to write yourself, and that you'd end up writing badly. > (apt-pkg/contrib/ is full of that sort of thing) We should not forget that APT has priority important, and boost libraries are optional. But we could switch APT to the subset of C++0x which is supported by GCC 4.3, the version in stable. > > > But I don't think anyone wants to do this. > > Personally, I would totally love to clean up the apt code and fix > some of my chronic annoyances with it. I just don't have the spare > time, and apparently neither does anyone else (except some guy who > thinks it should be written in Perl (!?!?)). :-( Cupt is great as a prototype and can give us a direction in terms of features. As long as you are not running an embedded system and as long as Perl works things are okay. Some kind of a roadmap: * identify stuff we don't use anymore and remove it, eg. apt-pkg/vendor*, apt-inst/database*, apt-inst/deb/dpkgdb*. * drop compatibility for GCC < 4.3, and other stuff older then what is included in Debian Lenny. * rework the buildsystem using CMake -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. From info at geniedream.com Thu Nov 19 22:07:19 2009 From: info at geniedream.com (info at geniedream.com) Date: Thu, 19 Nov 2009 23:07:19 +0100 Subject: [Aptitude-devel] MAKE MONEY FAST!! Message-ID: CHECK IT OUT !! http://WWW.MAKEMONEYWITHGOLD.CO.UK http://www.makemoneywithgold.co.uk a subsidiary of http://www.geniedream.com World Class Series . A Genie Dream Product www.geniedream.com -- If you do not want to receive any more newsletters, http://mailer.geniedream.com/?p=unsubscribe&uid=0f3f702eda43246e6e2738d13a9187d8 To update your preferences and to unsubscribe visit http://mailer.geniedream.com/?p=preferences&uid=0f3f702eda43246e6e2738d13a9187d8 Forward a Message to Someone http://mailer.geniedream.com/?p=forward&uid=0f3f702eda43246e6e2738d13a9187d8&mid=1 -- Powered by PHPlist, www.phplist.com -- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: powerphplist.png Type: image/png Size: 2408 bytes Desc: not available URL: From ocampagne at gmail.com Fri Nov 20 12:32:10 2009 From: ocampagne at gmail.com (Omar Campagne) Date: Fri, 20 Nov 2009 13:32:10 +0100 Subject: [Aptitude-devel] Spanish translation update and images Message-ID: <20091120123210.GA15017@gmail.com> Hello: Indeed, taking the screenshots on a xterm window makes pics lighter. Now the look just like the originals. Images: http://dl.dropbox.com/u/430223/aptitude-pics.tar.gz Translation update: http://dl.dropbox.com/u/430223/es.diff Regards, Omar -- "Why stop now just when I'm hating it?" -- Marvin The Paranoid Android From ocampagne at gmail.com Fri Nov 20 12:41:06 2009 From: ocampagne at gmail.com (Omar Campagne) Date: Fri, 20 Nov 2009 13:41:06 +0100 Subject: [Aptitude-devel] Build spanish documentation issue. Message-ID: <20091120124106.GB15017@gmail.com> Hello (separating issues): I triggered autogen, and then configure --prefix=.... If I run make and make install within the doc/fr directory, I get output-html, output-man and output-txt in the fr directory with make, and share/doc and share/man in the directory set with --prefix with make install. If I do the same on the doc/es directory, I only get output-html en the doc/es directory with make and the .xml generated documents. And if I trigger make install, instead of copying the files to the --prefix directory, it just triggers xsltproc again. Summing up, output-man and output-txt are not generated in doc/es, and nothing gets installed in the --prefix directory. Regards, Omar. From ott at mirix.org Sat Nov 21 13:29:27 2009 From: ott at mirix.org (Matthias-Christian Ott) Date: Sat, 21 Nov 2009 14:29:27 +0100 Subject: [Aptitude-devel] Find recommened packages which aren't dependencies Message-ID: <20091121132927.GA2266@marix> Hi, although this is the development mailing list of aptitude, I want to ask a rather difficult usage question: How do I find the packages which were installed, because the are recommened, but aren't required by any package? Regards, Matthias-Christian From dburrows at debian.org Mon Nov 23 15:41:42 2009 From: dburrows at debian.org (Daniel Burrows) Date: Mon, 23 Nov 2009 07:41:42 -0800 Subject: [Aptitude-devel] Acquire considered non-threadsafe In-Reply-To: <20091119141657.GA4136@debian.org> References: <20091115204237.GB19243@hummingbird> <20091118131543.GA4996@debian.org> <20091119123112.GC13897@hummingbird> <20091119141657.GA4136@debian.org> Message-ID: <20091123154142.GA22733@emurlahn.burrows.local> On Thu, Nov 19, 2009 at 06:09:42PM +0100, Julian Andres Klode was heard to say: > On Thu, Nov 19, 2009 at 04:31:13AM -0800, Daniel Burrows wrote: > > Also, apt2? When did that happen? > APT2 will be a package management library + applications written in Vala, > but at the moment it's just a few parsers and a simple acquire system. And > it's intented to be cross-distro, just like PackageKit. I just had no better > name when I started it. It's currently MIT-licensed, but may switch to the > LGPL-2.1+ soon (as this is what all its dependencies like glib use). Hm. I'm pretty skeptical about writing a system tool like this in a high-level language. Both from the point of view of dependency fragility and because you want it to be easy to access the functionality from other languages. In fact, I've occasionally wondered if it makes sense for the public API of an apt successor to be pure C (even if the implementation is C++ behind the scenes). C++ ABIs are obnoxiously fragile and poorly defined, for one thing. (although very convenient if you're writing in C++) > > I wonder if apt really needs an mmap'd cache here. In fact, I wonder > > about using sqlite -- I did a little experimentation with it and got > > decent performance. The big problem (from my point of view) would be > > teaching client code to treat the database transactionally rather than > > as a linked set of in-memory objects, but it way more cleaner and more > > flexible than what we have now. > Working with databases is a bit complicated. It makes development not > really convenient. It's true that it's hard to keep the database contained in a library. > > > > > (f) storing errno inside the error handling objects, > > > for bindings (nice to have errno). > > > > Please, please, kill the global error queue. This is a disaster from > > a threadsafety point of view, but also just from a general design > > perspective. There's way too much code that does > > > > if(!_error->PendingError()) > > fail(); > > > > when the error could have been caused by something entirely unrelated > > to what this code is interested in. > > > > Put error-handling oun either a return-code basis or an exception > > basis, but not this wird intermediate thing where random errors cause > > failure. If you want to know about inner errors, use a logging > > framework (I prefer log4cxx). > As far as I can tell from the documentation, the APT error handling should > only be used for boolean functions. If the function has an error, it pushes > a message to the error stack and returns false. If we used it this way only, > we would have no multi-threading problems. Many uses of PendingError() in apt-pkg need to be fixed then. The problem is, when it's used this way, you can't tell which errors the code is actually supposed to detect, which makes it tricky to pull the call out safely (you'll end up changing behavior). Would you be OK with a patch that eliminated these usages anyway? What if I also changed the code to use return codes in places where it's obvious which error(s) is/are being checked? Grep shows me 38 uses of PendingError() in apt-pkg. At a quick glance, it looks like most of those are problematic. I didn't look closely enough to determine how hard each one will be to fix. I would like to emphasize that this is not just a multi-threading problem; any time that the error queue might be in an unknown state (for instance, after pkgAcquire::Pulse() is invoked), you could see spurious failures. > Exceptions are a bit tricky in C++ as they can happen unexpectedly. Google's > C++ style guide says no; so we should probably also say no. Do we work for Google? I wanna get paid in that case :P But seriously, I don't really care whether we use exceptions or return codes. I guess "Google says so" is as good (or bad) a reason as any. The biggest thing in favor of one or the other as far as I'm concerned is that exceptions can abort constructors, which means you don't have to do the dance of storing a flag to track whether an object constructed itself properly. On the other hand, exceptions that happen in destructors tend to have horrible results. > > I would add one more item: > > > > (g) use modern C++ coding conventions (at least for new code) > > > > apt was designed in 1996 or so, and it shows. Modern C++ is a lot > > cleaner, easier to maintain and easier to write than the weird mishmash > > of C and "object-oriented programming" that apt is written in. Also, > > a lot of modern C++ programs link against Boost, which provides a ton > > of well-designed utility libraries for stuff that you would otherwise > > have to write yourself, and that you'd end up writing badly. > > (apt-pkg/contrib/ is full of that sort of thing) > > We should not forget that APT has priority important, and boost libraries > are optional. But we could switch APT to the subset of C++0x which is > supported by GCC 4.3, the version in stable. OTOH, most of the Boost libraries are compile-time-only, so aside from bootstrapping this isn't necessarily a problem (assuming we don't use iostreams or anything like that); policy explicitly excludes build-time dependencies from priority rules. On the first hand, a good shared_ptr implementation, which is in C++0x IIRC, would be a nice starting point; most of the other stuff I use from Boost is more special-purpose. And C++0x has some other really nice (and badly needed) stuff in it. > Some kind of a roadmap: > > * identify stuff we don't use anymore and remove it, eg. > apt-pkg/vendor*, apt-inst/database*, apt-inst/deb/dpkgdb*. > * drop compatibility for GCC < 4.3, and other stuff older > then what is included in Debian Lenny. > * rework the buildsystem using CMake (ABI breaking stuff) * Write a more organized download system. (see below) Maybe also figure out a style guide for C++ going forwards (e.g., recommend not using exceptions, using smart pointers, using STL containers, etc). As far as the download system goes, I'd prefer to see an explicit two-level design, where the lower level downloads URIs without caring what they "mean", and the upper level manages "jobs" that download multiple URIs (such as "update some packages"), using the lower level object to do the actual download. This would make it a lot easier for code linked against apt to make use of apt's nice download functionality without having to jump through hoops just to download a URI. (one of my pet peeves) In aptitude, I have built an internal API that provides a low-level URI downloader running in a background thread. Currently it's based on Acquire, but with a little work it could replace Acquire instead (at first glance, the Acquire main loop and the download queue management would need to be incorporated). I think it's a good example of the simple interface I'm thinking about, anyway: http://hg.debian.org/hg/aptitude/head/file/b8a7fc61b13c/src/generic/apt/download_queue.h The reason I use a single background thread for all downloads is that (a) download resources are normally global (only one network connection), and (b) this means that clients don't have to deal with threading themselves (other than providing a function that passes a callback to their "main" thread) -- as far as they're concerned, the "download complete" event arrives as a message in the main event loop. They just have to provide a threadsafe way of passing callbacks to the main thread, which is generally a fairly simple task. (of course, for clients that don't have a main loop, you can provide convenience code to block the main thread while running a download) The upper level would handle what's currently mostly done by pkgAcquire::Item, but without being "special" the way that class is (it has friend relations with the download queue right now). I particularly would like to see some way of grouping together the various processes that take place for a single "object" that's being downloaded (index, .deb, etc); that would make it possible to show much better progress information than is really feasible right now. Also, the upper level should be able to run in the background (whether using a continuation-based coding style or in a real background thread) without blocking execution, so that GUI programs don't have to either poll for events or write the threading code themselves. Daniel From dburrows at debian.org Mon Nov 23 16:32:48 2009 From: dburrows at debian.org (Daniel Burrows) Date: Mon, 23 Nov 2009 08:32:48 -0800 Subject: [Aptitude-devel] Find recommened packages which aren't dependencies In-Reply-To: <20091121132927.GA2266@marix> References: <20091121132927.GA2266@marix> Message-ID: <20091123163248.GA26620@emurlahn.burrows.local> On Sat, Nov 21, 2009 at 02:29:27PM +0100, Matthias-Christian Ott was heard to say: > although this is the development mailing list of aptitude, I want to > ask a rather difficult usage question: > > How do I find the packages which were installed, because the are > recommened, but aren't required by any package? I'm not sure you can really do this via the search language right now. You could just disable recommendations and see what would be removed: $ aptitude -s -o 'apt::autoremove::recommendsimportant=false' -o 'aptitude::recommends-important=false' -o 'aptitude::keep-recommends=false' -o 'apt::install-recommends=false' install Daniel From jak at debian.org Mon Nov 23 23:00:21 2009 From: jak at debian.org (Julian Andres Klode) Date: Tue, 24 Nov 2009 00:00:21 +0100 Subject: [Aptitude-devel] Acquire considered non-threadsafe In-Reply-To: <20091123154142.GA22733@emurlahn.burrows.local> References: <20091115204237.GB19243@hummingbird> <20091118131543.GA4996@debian.org> <20091119123112.GC13897@hummingbird> <20091119141657.GA4136@debian.org> <20091123154142.GA22733@emurlahn.burrows.local> Message-ID: <20091123234555.GA27234@debian.org> On Mon, Nov 23, 2009 at 07:41:42AM -0800, Daniel Burrows wrote: > On Thu, Nov 19, 2009 at 06:09:42PM +0100, Julian Andres Klode was heard to say: > > On Thu, Nov 19, 2009 at 04:31:13AM -0800, Daniel Burrows wrote: > > > Also, apt2? When did that happen? > > APT2 will be a package management library + applications written in Vala, > > but at the moment it's just a few parsers and a simple acquire system. And > > it's intented to be cross-distro, just like PackageKit. I just had no better > > name when I started it. It's currently MIT-licensed, but may switch to the > > LGPL-2.1+ soon (as this is what all its dependencies like glib use). > > Hm. I'm pretty skeptical about writing a system tool like this in a > high-level language. Both from the point of view of dependency > fragility and because you want it to be easy to access the functionality > from other languages. In fact, I've occasionally wondered if it makes > sense for the public API of an apt successor to be pure C (even if the > implementation is C++ behind the scenes). C++ ABIs are obnoxiously > fragile and poorly defined, for one thing. (although very convenient if > you're writing in C++) Vala compiles to C, and provides a C-API comparable to other GObject libraries such as GTK+. You get a C library with a header file and everything, and you can write applications using the library in C. For now, dependencies are libglib2.0-0 libgee1 (container classes) libsoup2.4-1 (HTTP/HTTPS acquire part) The latter one could be replaced with a limited http downloader for embedded systems; which only depends on libglib2.0-0. > > > > > > > > (f) storing errno inside the error handling objects, > > > > for bindings (nice to have errno). > > > > > > Please, please, kill the global error queue. This is a disaster from > > > a threadsafety point of view, but also just from a general design > > > perspective. There's way too much code that does > > > > > > if(!_error->PendingError()) > > > fail(); > > > > > > when the error could have been caused by something entirely unrelated > > > to what this code is interested in. > > > > > > Put error-handling oun either a return-code basis or an exception > > > basis, but not this wird intermediate thing where random errors cause > > > failure. If you want to know about inner errors, use a logging > > > framework (I prefer log4cxx). > > As far as I can tell from the documentation, the APT error handling should > > only be used for boolean functions. If the function has an error, it pushes > > a message to the error stack and returns false. If we used it this way only, > > we would have no multi-threading problems. > > Many uses of PendingError() in apt-pkg need to be fixed then. The > problem is, when it's used this way, you can't tell which errors the > code is actually supposed to detect, which makes it tricky to pull the > call out safely (you'll end up changing behavior). Would you be OK with > a patch that eliminated these usages anyway? What if I also changed the > code to use return codes in places where it's obvious which error(s) > is/are being checked? > > Grep shows me 38 uses of PendingError() in apt-pkg. At a quick > glance, it looks like most of those are problematic. I didn't look > closely enough to determine how hard each one will be to fix. > > I would like to emphasize that this is not just a multi-threading > problem; any time that the error queue might be in an unknown state (for > instance, after pkgAcquire::Pulse() is invoked), you could see spurious > failures. OK. > > > Exceptions are a bit tricky in C++ as they can happen unexpectedly. Google's > > C++ style guide says no; so we should probably also say no. > > Do we work for Google? I wanna get paid in that case :P > Just a reference. > OTOH, most of the Boost libraries are compile-time-only, so aside from > bootstrapping this isn't necessarily a problem (assuming we don't use > iostreams or anything like that); policy explicitly excludes build-time > dependencies from priority rules. On the first hand, a good shared_ptr > implementation, which is in C++0x IIRC, would be a nice starting point; > most of the other stuff I use from Boost is more special-purpose. And > C++0x has some other really nice (and badly needed) stuff in it. shared_ptr is also available in std::tr1::shared_ptr, at least in current GCC versions. We could even require a GCC with the C++0x stuff we need an build with --std=c++0x. > > > Some kind of a roadmap: > > > > * identify stuff we don't use anymore and remove it, eg. > > apt-pkg/vendor*, apt-inst/database*, apt-inst/deb/dpkgdb*. > > * drop compatibility for GCC < 4.3, and other stuff older > > then what is included in Debian Lenny. > > * rework the buildsystem using CMake > > (ABI breaking stuff) > * Write a more organized download system. (see below) > > Maybe also figure out a style guide for C++ going forwards (e.g., > recommend not using exceptions, using smart pointers, using STL > containers, etc). Or copy Google's style guide and remove the stuff we don't like; and adjust it to our coding standards. Their style guide is very complete, and thus a good base. > As far as the download system goes, I'd prefer to see an explicit > two-level design, where the lower level downloads URIs without caring > what they "mean", and the upper level manages "jobs" that download > multiple URIs (such as "update some packages"), using the lower level > object to do the actual download. This would make it a lot easier for > code linked against apt to make use of apt's nice download functionality > without having to jump through hoops just to download a URI. (one of my > pet peeves) Yes. > > In aptitude, I have built an internal API that provides a low-level > URI downloader running in a background thread. Currently it's based on > Acquire, but with a little work it could replace Acquire instead > (at first glance, the Acquire main loop and the download queue management > would need to be incorporated). I think it's a good example of the > simple interface I'm thinking about, anyway: > > http://hg.debian.org/hg/aptitude/head/file/b8a7fc61b13c/src/generic/apt/download_queue.h I'm missing a few parts like a target filename, but maybe this is defined somewhere else? -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. From sebi at wh-netz.de Fri Nov 27 12:04:29 2009 From: sebi at wh-netz.de (Sebastian Heil) Date: Fri, 27 Nov 2009 13:04:29 +0100 Subject: [Aptitude-devel] changelog ~U Message-ID: <4B0FC04D.2040207@wh-netz.de> Hello guys, I noticed that you can only make a changelog on full package name. So you have to type in something like "aptitude changelog linux-image-2.6.26-2-686=2.6.26-19". Unlike the other actions you can not use the search patterns (e.g. aptitude show ~U, aptitude download ~U, ...). But this would be a greatful feature because now I use apticron altogether with apt-listchanges and have to let it send me an email everytime I want to see the changelog of all upgradeable packages. If the search patterns were active in changelog I could simply use "aptitude changelog ~U" in the terminal and it would be a big help for me. Or is there an underlying cause why not all of the actions use the search patterns? Thanks in advance Sebastian Heil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From cyril.chaboisseau at free.fr Sat Nov 28 11:44:58 2009 From: cyril.chaboisseau at free.fr (Cyril Chaboisseau) Date: Sat, 28 Nov 2009 12:44:58 +0100 Subject: [Aptitude-devel] search for word "package" returns high number of results Message-ID: <20091128114458.GA28360@adren.org> Looking for a package manager, I did the following search: aptitude search ~dpackage which gave me a very high (14636) number of packages which of course are not related to my query this is a around half of what I would get with the 'true' query term $ aptitude search ~T|wc -l 31614 this might have to do with the fact that the word "package" is being taken into account (e.g. indexed) when looking in the description BTW, this "bug" is also present with apt which returns a lower number of results: $ apt-cache search package|wc -l 14558 -- Cyril Chaboisseau From dburrows at debian.org Mon Nov 30 12:11:50 2009 From: dburrows at debian.org (Daniel Burrows) Date: Mon, 30 Nov 2009 04:11:50 -0800 Subject: [Aptitude-devel] search for word "package" returns high number of results In-Reply-To: <20091128114458.GA28360@adren.org> References: <20091128114458.GA28360@adren.org> Message-ID: <20091130121150.GA11871@emurlahn.burrows.local> On Sat, Nov 28, 2009 at 12:44:58PM +0100, Cyril Chaboisseau was heard to say: > Looking for a package manager, I did the following search: > > aptitude search ~dpackage > > which gave me a very high (14636) number of packages which of course are > not related to my query Well, yes, they are. You asked for packages whose description contains "package"; you got them. Unfortunately, a lot of packages say something like "documentation for this package is available in foo-doc" or "this package contains..." in their description. They aren't relevant to what you *wanted*, but then you'll have to tell aptitude more specifically what you want (maybe something like "?description(package *manager)"). > BTW, this "bug" is also present with apt which returns a lower number of > results: > > $ apt-cache search package|wc -l > 14558 Odd that it's less. As far as I can tell from a quick check, apt-cache doesn't search packages that are locally installed but not present in the archive. Daniel