From wavexx at thregr.org Tue Jul 7 11:17:28 2015 From: wavexx at thregr.org (Yuri D'Elia) Date: Tue, 07 Jul 2015 13:17:28 +0200 Subject: [Aptitude-devel] Bug#791662: debdelta integration Message-ID: <20150707111728.15852.55606.reportbug@localhost> Package: aptitude Version: 0.6.11-1+b1 Severity: wishlist First, some debdelta praise: I've been using debdelta on and off over the last years depending on the circumstances. Whenever I'm working on a lousy/slow internet connection (quite often, unfortunately), debdelta is effectively my only chance to perform upgrades to massive packages like tetex, libreoffice, or the like. The bandwidth saving are, in most cases, absolutely enormous (especially when packaging tweaks are being pushed). I'm all for systematic integration of debdelta into apt. However, after tracking the integration progress over the years, it looks it might take even longer. This is why I decided now to file this whishlist into aptitude in the hope of moving things forward, and faster. It would be awesome if aptitude itself supported debdelta when installed. This would mean to run `debdelta-upgrade [selected package list]` as opposed to downloading the packages directly. I couldn't care less about the progress meter in this scenario, and having "something that works" would be better than just running "debdelta-upgrade" blindly and then continuing with aptitude. I believe *many* users would realize debdelta existed if debdelta was actually integrated into aptitude and suggested as a dependency. debdelta is suggested by 'libcupt' (and thus, when cupt is installed), but sincerely I have no use for another frontend if I'm already using aptitude. It would also be *very* important, irregardless if debdelta is installed and/or if it will ever be integrated on a lower level, to allow the user to switch between regular/debdelta updates though an option in the configuration: debdelta trades between CPU time and bandwidth, and if you have a decent network connection, debdelta is often slower. A setting is definitely warranted. Thanks. From Tom_Roche at pobox.com Sat Jul 11 21:38:49 2015 From: Tom_Roche at pobox.com (Tom Roche) Date: Sat, 11 Jul 2015 17:38:49 -0400 Subject: [Aptitude-devel] dist-upgrade vs full-upgrade, aka the apt-get jihad Message-ID: <878uame5na.fsf@pobox.com> summary: Are there any significant current reasons to prefer `apt-get dist-upgrade` to `aptitude full-upgrade`? If so: what are they? If not: are there any plans to update relevant Debian documents such as the Debian Reference[1] or bug#=411280[2]? details: I like the `aptitude` CLI, which I've used since I started using Debian-based distros early in this millenium. (I very rarely use the CUI or NUI or whatever you call it[3].) However, `aptitude` does regularly bring one annoyance (to me--YMMV): whenever I post to a list or a forum, if I even mention `aptitude`, I get a bunch of responses telling me to use `apt-get` instead. Even when the problem appears to be hardware-related[4], i.e., to have no relation to debian packaging, much less one's APT frontend. The `apt-get` jihadis are especially emphatic when discussing release upgrade. They have no doubt that one really should `apt-get dist-upgrade` to, e.g., go from wheezy to jessie. But, AFAICS, this is based solely on (in increasing order of emphasis) 1. bad `aptitude` experiences in the distant past 2. bug#=411280[2], an 8.5-year-old archived bug, on which the last activity was 5 years ago. 3. Debian Reference section#=2.2.1[1], which cites ... bug#=411280. > 2.2.1. apt-get / apt-cache vs. aptitude > Although aptitude is a very nice interactive tool which the author mainly uses, you should know some cautionary facts: > * The aptitude command is not recommended for the release-to-release system upgrade on the stable Debian system after the new release. > * The use of "apt-get dist-upgrade" is recommended for it. See Bug #411280.[/quote] This timeframe seems relevant since, IIRC (and please correct me if wrong) project=aptitude revived ~2011 after long inactivity by Daniel Burrows. If that's correct, one might reasonably infer that problems observed 2007-2010 (the time during which bug#=411280[2] was active) have since been addressed. Hence my questions: 1. Should `aptitude full-upgrade` still be deprecated relative to `apt-get dist-upgrade`? if so: 1.1. What currently makes `apt-get dist-upgrade` {better, more reliable} than `aptitude full-upgrade`? if not: 1.2. Is any effort being made to correct the currently-misleading reference[1] or bug[2]? TIA, Tom Roche [1]: https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_literal_apt_get_literal_literal_apt_cache_literal_vs_literal_aptitude_literal [2]: http://bugs.debian.org/411280 [3]: I.e., the `ncurses`-based, character-mode UI one gets if one calls `aptitude` with no arguments. What *do* you call it? [4]: http://forums.debian.net/viewtopic.php?f=10&t=123574 From abe at debian.org Sun Jul 12 12:58:56 2015 From: abe at debian.org (Axel Beckert) Date: Sun, 12 Jul 2015 14:58:56 +0200 Subject: [Aptitude-devel] apt-get dist-upgrade vs aptitude full-upgrade, aka the apt-get jihad In-Reply-To: <878uame5na.fsf@pobox.com> References: <878uame5na.fsf@pobox.com> Message-ID: <20150712125855.GN30802@sym.noone.org> Hi Tom, Tom Roche wrote: > Subject: dist-upgrade vs full-upgrade, aka the apt-get jihad This subject is misleading since you've wrote to the aptitude mailing list and aptitude understands both, dist-upgrade and full-upgrade. (And "apt" also understands "full-upgrade", btw.) And there is no such thing as a war between aptitude and apt(-get), except maybe about the number of unresolved bug reports[1]. ;-) [1] https://lists.alioth.debian.org/pipermail/aptitude-devel/2012-January/001823.html Both tools have different use cases and audiences. If people actually do fight that war, they're wrong. They likely belong to only one audience and don't know about the other audience. > summary: Are there any significant current reasons to prefer > `apt-get dist-upgrade` to `aptitude full-upgrade`? Yes. > If so: what are they? apt(-get) (dist|full)-upgrade is for one-shot commands, aptitude full-upgrade s for doing dist-upgrades where you want to change the autmatically made decisions interactively. They have different dependency resolver engines -- on purpose. > If not: are there any plans to update relevant Debian documents such > as the Debian Reference[1] or bug#=411280[2]? Bug #411280 has been resolved in 2010. And I don't see what's wrong with the Debian References: If you don't want to think about the difference between apt-get and aptitude on the command-line, it is (IMHO strongly) recommended to use apt-get or apt as that one in most cases produces better one-shot dependency resolutions. (And I'm saying this as a convinced and long-time aptitude user -- who btw. is happy that APT got a nicer CLI with "apt".) > I like the `aptitude` CLI, which I've used since I started using > Debian-based distros early in this millenium. (I very rarely use the > CUI or NUI or whatever you call it[3].) What parts of the aptitude CLI do you like that much? There are many small differences solely on the CLI, but not everyone will notice them. > However, `aptitude` does regularly bring one annoyance (to > me--YMMV): whenever I post to a list or a forum, if I even mention > `aptitude`, I get a bunch of responses telling me to use `apt-get` > instead. That's usually bullshit. The decision between apt(-get) and aptitude is only up to the local system administrator -- except in one case: When writing documentation. Then you should always use apt-get. So if you're not asking for advice on how to write documentation or your question is about dependency resolution, just ignore it and tell people that _this_ makes no difference. > The `apt-get` jihadis are especially emphatic when > discussing release upgrade. Where they are right since apt-get and aptitude make a relevant difference there. You should not ask them if you're asking for aptitude advice. > They have no doubt that one really should `apt-get dist-upgrade` to, > e.g., go from wheezy to jessie. That's the official recommendation for dist-upgrades from oldstable to stable, but YMMV, e.g. if you're mixing releases. Others may have again different preferences, e.g. I use aptitude's TUI for dist-upgrades. > But, AFAICS, this is based solely on (in increasing order of > emphasis) I'd just simply say they don't know better. (And please notice that at least the active APT developers are no such jihadists -- and they should know best. :-) > This timeframe seems relevant since, IIRC (and please correct me if > wrong) project=aptitude revived ~2011 after long inactivity by > Daniel Burrows. If that's correct, one might reasonably infer that > problems observed 2007-2010 (the time during which bug#=411280[2] > was active) have since been addressed. Your observation is correct, but the conclusion seems wrong. > 1. Should `aptitude full-upgrade` still be deprecated relative to `apt-get dist-upgrade`? Yes. > 1.1. What currently makes `apt-get dist-upgrade` {better, more reliable} than `aptitude full-upgrade`? Different target audience -- especially the one without experience and hence abiding to documentation as much as possible. You don't want bloody beginners to fiddle around with dependency resolution manually -- and that's what aptitude's dependency resolver has been written for. So if it's not for the TUI, I'd recommend "apt" for beginners nowadays. If they gained some experience and ran into some dependency issues (i.e. in unstable) _and_ are dissatisfied with apt, they should have a look at aptitude's interactive dependency resolution. And if they like the TUI, they should just use it. There's no APT alternative for that, except maybe, hmmm, dselect? Well, no -- there's a reason why I switched from dselect to aptitude over a decade ago. ;-) Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE From Tom_Roche at pobox.com Sun Jul 12 16:20:51 2015 From: Tom_Roche at pobox.com (Tom Roche) Date: Sun, 12 Jul 2015 12:20:51 -0400 Subject: [Aptitude-devel] apt-get dist-upgrade vs aptitude full-upgrade, aka the apt-get jihad In-Reply-To: <20150712125855.GN30802@sym.noone.org> References: <20150712125855.GN30802@sym.noone.org> <878uame5na.fsf@pobox.com> Message-ID: <874ml9e49o.fsf@pobox.com> summary: the Debian "general public" is being regularly told that `apt-get dist-upgrade` is recommended over `aptitude dist-upgrade`--period, full stop. `apt` and `aptitude` developers who are concerned that users be better informed should recommend slightly more accurate text to the the Debian Reference (DR) maintainer(s): e.g., * `apt-get dist-upgrade` is better for non-interactive usecases, especially for beginners lacking sufficient knowledge of Debian packaging and package dependencies. * `aptitude dist-upgrade` is better for interactive usecases (e.g., more complicated upgrades from less-standard repositories), provided one has the knowledge required to interact successfully. details: Axel Beckert Sun, 12 Jul 2015 14:58:56 +0200[1] > [This thread's Subject line] is misleading[:] aptitude understands both dist-upgrade and full-upgrade. Fair enough: I'll use both `apt-get dist-upgrade` and `aptitude dist-upgrade` below and in future. > (And "apt" also understands "full-upgrade", btw.) That I did not know; thanks for the info. That being said, this is probably the first time I've ever seen `apt full-upgrade` or `apt-get full-upgrade` mentioned in print, and I'd bet money it's not a widespread usage. Tom Roche Sat, 11 Jul 2015 17:38:49 -0400[2] >> `aptitude` does regularly bring one annoyance (to me--YMMV): whenever I post to a list or a forum, >> if I even mention `aptitude`, I get a bunch of responses telling me to use `apt-get` instead. >> Even when the problem appears to be hardware-related[3], i.e., to have no relation to debian packaging[.] >> The `apt-get` jihadis are especially emphatic when discussing [dist-upgrade]. > You should not ask them if you're asking for aptitude advice. My point above is precisely that, even when one is asking a non-packaging question in a general forum (see the linked thread[3]) and *is not* "asking for `aptitude` advice`, one gets `apt-get` advice, precisely because of >> (in increasing order of emphasis) >> 1. bad `aptitude` experiences in the distant past >> 2. bug#=411280[4], an 8.5-year-old archived bug, on which the last activity was 5 years ago. >> 3. Debian Reference section#=2.2.1[5], which cites ... bug#=411280. Obviously `apt` and `aptitude` developers can't affect item#=1, but IMHO you really should contact the DR maintainer(s) about item#=3, if only because item#=2 would probably not be misinterpreted as relevant if it was not cited and linked to from the DR. >> are there any plans to update relevant Debian documents such as the Debian Reference[5] or bug#=411280[4]? > Bug #411280 has been resolved in 2010. > And I don't see what's wrong with the Debian References Quoting the relevant text: DR section#=2.2.1[5] >>> The aptitude command is not recommended for the release-to-release system upgrade on the stable Debian system after the new release. The use of "apt-get dist-upgrade" is recommended for [that]. See Bug #411280[3, link in original] As a native speaker of English, I must protest that the meaning of that DR text differs greatly from that in Herr Beckert's post: > apt(-get) (dist|full)-upgrade is for one-shot commands, aptitude full-upgrade [is] for [when] you want to change [its programmatic recommendations] interactively. ... > If you don't want to think about the difference between apt-get and aptitude on the command-line, it is (IMHO strongly) recommended to use apt-get or apt as that one in most cases produces better one-shot dependency resolutions. ... > I'd recommend "apt" for beginners nowadays. If they [gain] some experience and [run] into some dependency issues ([e.g.,] in unstable) _and_ are dissatisfied with apt, they should have a look at aptitude's interactive dependency resolution. > And if they like [aptitude's] TUI, they should just use it. ICBW (please correct where wrong), but Beckert is saying that * `apt-get dist-upgrade` is better for non-interactive usecases, especially for beginners. * `aptitude dist-upgrade` is better for interactive usecases, e.g., involving packages with dependency issues. * `apt`'s package dependency resolver is not more or less robust or error-prone than `aptitude`'s (and vv). That's quite different from the (IMHO) nuance-free meaning of DR section#=2.2.1[5] above, which moreover continues: >>> * apt-get is most suitable for the major system upgrade between releases, etc. >>> * apt-get offers a *robust* [bold in original] package dependency resolver. No nuance there! > When writing documentation[,] you should always use apt-get. That statement seems, frankly, bizarre. The better recommendation (IMHO) for Debian documentation (esp references) is to tell Debian users which tools are better for which usecases--*not* to tell users that `apt-get dist-upgrade` is recommended over `aptitude dist-upgrade`, "end of story" (as they say in the US). Instead, why not tell users (via, e.g., the DR) that * `apt-get dist-upgrade` is better for non-interactive usecases, especially for beginners lacking sufficient knowledge of Debian packaging and package dependencies. * `aptitude dist-upgrade` is better for interactive usecases (e.g., more complicated upgrades from less-standard repositories), provided one has the knowledge required to interact successfully. * `apt-get` and `aptitude` use different package dependency resolvers for different usecases, but one is not more robust than the other. * bug#=411280[4] is no longer relevant. ? TIA, Tom Roche [1]: http://lists.alioth.debian.org/pipermail/aptitude-devel/2015-July/004859.html [2]: http://lists.alioth.debian.org/pipermail/aptitude-devel/2015-July/004858.html [3]: http://forums.debian.net/viewtopic.php?f=10&t=123574 [4]: http://bugs.debian.org/411280 [5]: https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_literal_apt_get_literal_literal_apt_cache_literal_vs_literal_aptitude_literal From abe at debian.org Mon Jul 13 09:14:44 2015 From: abe at debian.org (Axel Beckert) Date: Mon, 13 Jul 2015 11:14:44 +0200 Subject: [Aptitude-devel] apt-get dist-upgrade vs aptitude full-upgrade, aka the apt-get jihad In-Reply-To: <874ml9e49o.fsf@pobox.com> References: <20150712125855.GN30802@sym.noone.org> <878uame5na.fsf@pobox.com> <874ml9e49o.fsf@pobox.com> Message-ID: <20150713091444.GO30802@sym.noone.org> Tom Roche wrote: > > When writing documentation[,] you should always use apt-get. > > That statement seems, frankly, bizarre. No, it just misses context. Maybe this slightly expanded version is more clear: When writing installation instructions for your software on Debian, you should always use apt-get. (The statement was not targetted towards Debian's own documentation.) Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE From Tom_Roche at pobox.com Mon Jul 13 16:17:59 2015 From: Tom_Roche at pobox.com (Tom Roche) Date: Mon, 13 Jul 2015 12:17:59 -0400 Subject: [Aptitude-devel] apt-get dist-upgrade vs aptitude full-upgrade, aka the apt-get jihad In-Reply-To: <20150713091444.GO30802@sym.noone.org> References: <20150713091444.GO30802@sym.noone.org> <20150712125855.GN30802@sym.noone.org> <878uame5na.fsf@pobox.com> <874ml9e49o.fsf@pobox.com> Message-ID: <87y4ikt4js.fsf@pobox.com> Tom Roche Sun, 12 Jul 2015 12:20:51 -0400[1] >> why not tell users (via [the Debian Reference][2]) that >> * `apt-get dist-upgrade` is better for non-interactive usecases, especially for beginners lacking sufficient knowledge of Debian packaging and package dependencies. >> * `aptitude dist-upgrade` is better for interactive usecases (e.g., more complicated upgrades from less-standard repositories), provided one has the knowledge required to interact successfully. >> * `apt-get` and `aptitude` use different package dependency resolvers for different usecases, but one is not more robust than the other. >> * bug#=411280[3] is no longer relevant. Axel Beckert Mon, 13 Jul 2015 11:14:44 +0200[4] > When writing installation instructions for your software on Debian, you should always use apt-get. > (The statement was not targetted towards Debian's own documentation.) However I was plainly discussing "Debian's own documentation." So my recommendation stands: some representative of the `aptitude` developers, possibly accompanied by some of the `apt` developers (some of whom seem to be on this list), should communicate the facts above (which Beckert corroborates[5]) to the Debian Reference maintainer(s) by the recommended mechanism: 3.6. Bug reports on [the Debian Reference][6] >>> Please file bug reports on the debian-reference package using reportbug(1) if you find any issues on this document. Please include correction suggestion by "diff -u" to the plain text version or to the source. I'll cheerfully contribute "correction suggestion" if desired. I'd `reportbug` on the DR myself, except that I'm just "some guy on the internet," and IMHO this really should be done by more knowledgeable people, such as `aptitude` and `apt` developers. TIA, Tom Roche [1]: http://lists.alioth.debian.org/pipermail/aptitude-devel/2015-July/004860.html [2]: https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_literal_apt_get_literal_literal_apt_cache_literal_vs_literal_aptitude_literal [3]: http://bugs.debian.org/411280 [4]: http://lists.alioth.debian.org/pipermail/aptitude-devel/2015-July/004861.html [5]: http://lists.alioth.debian.org/pipermail/aptitude-devel/2015-July/004859.html [6]: https://www.debian.org/doc/manuals/debian-reference/pr01.en.html#_bug_reports_on_this_document From abe at debian.org Mon Jul 13 16:42:29 2015 From: abe at debian.org (Axel Beckert) Date: Mon, 13 Jul 2015 18:42:29 +0200 Subject: [Aptitude-devel] apt-get dist-upgrade vs aptitude full-upgrade, aka the apt-get jihad In-Reply-To: <87y4ikt4js.fsf@pobox.com> References: <20150713091444.GO30802@sym.noone.org> <20150712125855.GN30802@sym.noone.org> <878uame5na.fsf@pobox.com> <874ml9e49o.fsf@pobox.com> <87y4ikt4js.fsf@pobox.com> Message-ID: <20150713164228.GP30802@sym.noone.org> Hi, Tom Roche wrote: > Axel Beckert Mon, 13 Jul 2015 11:14:44 +0200[4] > > When writing installation instructions for your software on Debian, you should always use apt-get. > > > (The statement was not targetted towards Debian's own documentation.) > > However I was plainly discussing "Debian's own documentation." Which is IMHO still affected: If there's general Debian documentation about how to install a package, it should use apt-get (and likely does). > So my recommendation stands: some representative of the `aptitude` > developers, possibly accompanied by some of the `apt` developers > (some of whom seem to be on this list), should communicate the facts > above (which Beckert corroborates[5]) to the Debian Reference > maintainer(s) by the recommended mechanism. As mentioned before I see no big need to change the Debian Reference. > I'll cheerfully contribute "correction suggestion" if desired. I'd > `reportbug` on the DR myself, except that I'm just "some guy on the > internet," and IMHO this really should be done by more knowledgeable > people, such as `aptitude` and `apt` developers. I'd like to hear at least one other involved developer on that topic before doing anything in that direction (if at all). Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE From badalisc7 at thewayofunix.org Thu Jul 16 14:39:07 2015 From: badalisc7 at thewayofunix.org (Badalisc) Date: Thu, 16 Jul 2015 16:39:07 +0200 Subject: [Aptitude-devel] Bug#792601: aptitude: newline in user tags breaks pkgstates file Message-ID: <55A7C20B.1000803@thewayofunix.org> Package: aptitude Version: 0.6.11-1+b1 Severity: normal Dear Maintainer, I know that whitespaces other than space itself are very unlikely to be used in user tags, but aptitude silently accepts any of them even though they are not handled correctly. With newlines you can do a little injection: # aptitude search '^coreutils$' i coreutils - GNU core utilities # aptitude add-user-tag $'\nState:3' coreutils # aptitude search '^coreutils$' id coreutils - GNU core utilities (now it is marked for removal) Or you can make aptitude unusable: # aptitude add-user-tag $'foo bar\n' coreutils # aptitude install bash [ ERR] Reading extended state information [ ERR] Initializing package states [ ERR] Initializing package states E: Unterminated '"' in the user-tags list of the package coreutils. [ ERR] Reading extended state information [ ERR] Initializing package states [ ERR] Initializing package states E: Unterminated '"' in the user-tags list of the package coreutils. Also, other whitespaces like tab are treated differently from normal spaces: # aptitude add-user-tag 'foo bar' coreutils (adds the single tag 'foo bar') # aptitude remove-user-tag 'foo bar' coreutils (removes it) # aptitude add-user-tag $'foo\tbar' coreutils (adds two tags, 'foo' and 'bar') # aptitude remove-user-tag $'foo\hbar' coreutils (no effect) # aptitude remove-user-tag bar coreutils (now only 'foo' is left) Given pkgstates' email header-like format and the csv-like format for the subfields, perhaps the sensible solution for the newline problem would be to just forbid newline in tags. About the other problem, I noticed that tags not containing at least one space (x20), double quote or backslash are never written in quoted form, but if they contain other whitespaces they probably should. (an empty string as a tag name is also accepted and written unquoted which has no effect) -- Package-specific info: Terminal: xterm $DISPLAY not set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.11 compiled at Nov 8 2014 13:34:39 Compiler: g++ 4.9.1 Compiled against: apt version 4.12.0 NCurses version 5.9 libsigc++ version: 2.4.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20140913 cwidget version: 0.5.17 Apt version: 4.12.0 aptitude linkage: linux-vdso.so.1 (0x00007ffe5afd8000) libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x00007f2b6b1c4000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x00007f2b6af8e000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f2b6ad64000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x00007f2b6ab5e000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x00007f2b6a848000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f2b6a57f000) libboost_iostreams.so.1.55.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x00007f2b6a367000) libxapian.so.22 => /usr/lib/libxapian.so.22 (0x00007f2b69f56000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2b69d39000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2b69a2e000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2b6972d000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2b69517000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2b6916e000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f2b68f6b000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2b68d67000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2b68b4c000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f2b6893c000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f2b68719000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2b68511000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f2b6830c000) /lib64/ld-linux-x86-64.so.2 (0x00007f2b6bb86000) -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common 0.6.11-1 ii libapt-pkg4.12 1.0.9.8 ii libboost-iostreams1.55.0 1.55.0+dfsg-3 ii libc6 2.19-18 ii libcwidget3 0.5.17-2 ii libgcc1 1:4.9.2-10 ii libncursesw5 5.9+20140913-1+b1 ii libsigc++-2.0-0c2a 2.4.0-1 ii libsqlite3-0 3.8.7.1-1+deb8u1 ii libstdc++6 4.9.2-10 ii libtinfo5 5.9+20140913-1+b1 ii libxapian22 1.2.19-1 Versions of packages aptitude recommends: pn aptitude-doc-en | aptitude-doc pn libparse-debianchangelog-perl ii sensible-utils 0.0.9 Versions of packages aptitude suggests: pn apt-xapian-index pn debtags ii tasksel 3.31+deb8u1 -- no debconf information From doko at debian.org Fri Jul 17 13:28:17 2015 From: doko at debian.org (Matthias Klose) Date: Fri, 17 Jul 2015 15:28:17 +0200 Subject: [Aptitude-devel] Bug#777778: aptitude: ftbfs with GCC-5 Message-ID: <55A902F1.4060703@debian.org> reopen 777778 thanks this fails later, once xapian and cwidget are built using GCC 5. Making all in matching make[6]: Entering directory '/scratch/packages/tmp/aptitude-0.6.11/build-arch/src/generic/apt/matching' g++ -DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. -I../../../../../src/generic/apt/matching -I../../../.. -I../../../.. -I../../../../../src/generic/apt/matching -I../../../../.. -I../../../../../src -D_FORTIFY_SOURCE=2 -I/usr/include -DHELPDIR=\"/usr/share/aptitude\" -DPKGDATADIR=\"/usr/share/aptitude\" -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -O2 -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -I/usr/lib/x86_64-linux-gnu/cwidget -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -D_REENTRANT -fno-strict-aliasing -Wall -c -o parse.o ../../../../../src/generic/apt/matching/parse.cc In file included from ../../../../../src/generic/util/immset.h:31:0, from ../../../../../src/generic/apt/matching/parse.cc:54: ../../../../../src/generic/util/compare3.h:294:62: error: template argument 1 is invalid class compare3_f > ^ ../../../../../src/generic/util/compare3.h:332:42: error: template argument 1 is invalid class compare3_f > ^ ../../../../../src/generic/util/compare3.h:333:57: error: template argument 1 is invalid : public compare3_f_container > ^ Makefile:405: recipe for target 'parse.o' failed make[6]: *** [parse.o] Error 1 From owner at bugs.debian.org Fri Jul 17 13:33:07 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Fri, 17 Jul 2015 13:33:07 +0000 Subject: [Aptitude-devel] Processed: Re: Bug#777778: aptitude: ftbfs with GCC-5 References: <55A902F1.4060703@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > reopen 777778 Bug #777778 {Done: Martin Michlmayr } [src:aptitude] aptitude: ftbfs with GCC-5 Bug reopened Ignoring request to alter fixed versions of bug #777778 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 777778: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777778 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From manuel.montezelo at gmail.com Fri Jul 17 23:29:56 2015 From: manuel.montezelo at gmail.com (Manuel A. Fernandez Montecelo) Date: Sat, 18 Jul 2015 00:29:56 +0100 Subject: [Aptitude-devel] apt-get dist-upgrade vs aptitude full-upgrade, aka the apt-get jihad In-Reply-To: <20150713164228.GP30802@sym.noone.org> References: <20150713091444.GO30802@sym.noone.org> <20150712125855.GN30802@sym.noone.org> <878uame5na.fsf@pobox.com> <874ml9e49o.fsf@pobox.com> <87y4ikt4js.fsf@pobox.com> <20150713164228.GP30802@sym.noone.org> Message-ID: <20150717232956.GA31559@reva.itsari.org> 2015-07-13 17:42 Axel Beckert: >Hi, > >Tom Roche wrote: >> >> So my recommendation stands: some representative of the `aptitude` >> developers, possibly accompanied by some of the `apt` developers >> (some of whom seem to be on this list), should communicate the facts >> above (which Beckert corroborates[5]) to the Debian Reference >> maintainer(s) by the recommended mechanism. > >As mentioned before I see no big need to change the Debian Reference. > >> I'll cheerfully contribute "correction suggestion" if desired. I'd >> `reportbug` on the DR myself, except that I'm just "some guy on the >> internet," and IMHO this really should be done by more knowledgeable >> people, such as `aptitude` and `apt` developers. > >I'd like to hear at least one other involved developer on that topic >before doing anything in that direction (if at all). I agree with what Axel previously said in this thread: And I don't see what's wrong with the Debian References: If you don't want to think about the difference between apt-get and aptitude on the command-line, it is (IMHO strongly) recommended to use apt-get or apt as that one in most cases produces better one-shot dependency resolutions. (And I'm saying this as a convinced and long-time aptitude user -- who btw. is happy that APT got a nicer CLI with "apt".) And I also do not see the need to change the documentation. apt is better maintained and the primary and de-facto tool for package management in Debian in the last few years. Also aptitude in the last few years with the config by default comes with strange suggestions like prefering to remove hundreds of packages before upgrading one or a few packages. I don't know how this affects full dist-upgrades, since I haven't done any system upgrade for years (running unstable and updating on demand with aptitude, often cherry-picking updates), but it would surprise me that aptitude works more reliably than apt for this job. Cheers. -- Manuel A. Fernandez Montecelo From manuel.montezelo at gmail.com Fri Jul 17 23:33:45 2015 From: manuel.montezelo at gmail.com (Manuel A. Fernandez Montecelo) Date: Sat, 18 Jul 2015 00:33:45 +0100 Subject: [Aptitude-devel] Bug#790568: Bug#790568: Minesweeper: unused strings marked for translation In-Reply-To: <559254F9.2060905@norsjovallen.se> References: <559254F9.2060905@norsjovallen.se> Message-ID: <20150717233345.GB31559@reva.itsari.org> 2015-06-30 09:36 Anders Jonsson: >Package: aptitude >Version: 0.6.11-1+b1 >Severity: minor > >When reviewing the Swedish translation of aptitude i noticed that >there are about twenty strings in the translation that are commented >out in an "#if 0" block at least since 2005.They are however still >offered for translation. > >The concerned strings are in cmine::checkend() in src/mine/cmine.cc >and are no longer used messages when the user loses the minesweeper >game in aptitude. This commented out section can probably be removed >to lessen the size of future translations. Thanks for the patch, I will try to apply it soon. .oO I sometimes wonder if it would not be better to just remove the minesweeper altogether. It is sort of fun/amusing and it's not a big burden to keep it going, but as cases like these show, it's not zero-maintainance either. Cheers. -- Manuel A. Fernandez Montecelo From doko at debian.org Sat Jul 18 08:50:01 2015 From: doko at debian.org (Matthias Klose) Date: Sat, 18 Jul 2015 10:50:01 +0200 Subject: [Aptitude-devel] Bug#792681: cwidget ftbfs with GCC 5 In-Reply-To: References: <55A8FF6A.3010006@debian.org> Message-ID: <55AA1339.8060700@debian.org> On 07/17/2015 06:57 PM, Manuel A. Fernandez Montecelo wrote: > Hello, > > 2015-07-17 14:13 GMT+01:00 Matthias Klose : >> Package: src:cwidget >> Version: 0.5.17-2 >> Severity: normal >> Tags: sid stretch patch >> User: debian-gcc at lists.debian.org >> Usertags: ftbfs-gcc-5 >> >> GCC 5 complains about using c++11 features without passing -std=c++11. Also >> setting the maintainer flag without exporting it doesn't help. >> >> patch at >> https://launchpadlibrarian.net/211899860/cwidget_0.5.17-2ubuntu1_0.5.17-2ubuntu2.diff.gz > > If I found the correct build log where you determined this [1], the > compiler fails when including > > In file included from /usr/include/c++/5/string:52:0, > from ../../../src/cwidget/curses++.h:25, > from colors.cc:22: > > Line 22 of colors is: > #include > > And line 25 of curses++.h is: > #include > > The error is: > ----------------------- > /usr/include/c++/5/bits/basic_string.h: In instantiation of 'union > std::__cxx11::basic_string::': > /usr/include/c++/5/bits/basic_string.h:119:7: required from 'class > std::__cxx11::basic_string' > ../../../src/cwidget/curses++.h:199:31: required from here > /usr/include/c++/5/bits/basic_string.h:121:53: error: member > 'cwidget::wchtype > std::__cxx11::basic_string:: union>::_M_local_buf [1]' with constructor not allowed in union > _CharT _M_local_buf[_S_local_capacity + 1]; > ^ > /usr/include/c++/5/bits/basic_string.h:121:53: note: unrestricted > unions only available with -std=c++11 or -std=gnu++11 > ----------------------- > > This is because wchtype does not seem to be able to be used as part of > unions inside basic_string.h because the constructors/destructors are > not "trivial" enough. > > I was trying to work around this for a while, because I think that > forcing c++11 mode will have cascading effects on rev-deps (currently > only one within Debian, but it is aptitude with almost 100% of > reported installations by popcon), but I could not find a satisfactory > solution yet. > > Is there a deadline to fix this? yes, Jul 31. please see my email to d-d-a. > [1] https://people.debian.org/~doko/logs/gcc5-20150701-ftbfs/logs-failed-gcc5/cwidget_0.5.17-2_unstable_gcc5.log this was the error I saw: Making all in config make[5]: Entering directory '/scratch/packages/tmp/cwidget-0.5.17/src/cwidget/config' /bin/bash ../../../libtool --tag=CXX --mode=compile g++ -DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. -I../../.. -Wall -Werror -I../../.. -I. -I../../.. -I../../../src -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -c -o colors.lo colors.cc libtool: compile: g++ -DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. -I../../.. -Wall -Werror -I../../.. -I. -I../../.. -I../../../src -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT -I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -c colors.cc -fPIC -DPIC -o .libs/colors.o In file included from /usr/include/c++/5/string:52:0, from ../../../src/cwidget/curses++.h:25, from colors.cc:22: /usr/include/c++/5/bits/basic_string.h: In instantiation of 'union std::__cxx11::basic_string::': /usr/include/c++/5/bits/basic_string.h:119:7: required from 'class std::__cxx11::basic_string' ../../../src/cwidget/curses++.h:199:31: required from here /usr/include/c++/5/bits/basic_string.h:121:53: error: member 'cwidget::wchtype std::__cxx11::basic_string::::_M_local_buf [1]' with constructor not allowed in union _CharT _M_local_buf[_S_local_capacity + 1]; ^ /usr/include/c++/5/bits/basic_string.h:121:53: note: unrestricted unions only available with -std=c++11 or -std=gnu++11 Makefile:448: recipe for target 'colors.lo' failed make[5]: *** [colors.lo] Error 1 make[5]: Leaving directory '/scratch/packages/tmp/cwidget-0.5.17/src/cwidget/config' Makefile:603: recipe for target 'all-recursive' failed make[4]: *** [all-recursive] Error 1 From manuel.montezelo at gmail.com Sat Jul 18 21:29:25 2015 From: manuel.montezelo at gmail.com (Manuel A. Fernandez Montecelo) Date: Sat, 18 Jul 2015 22:29:25 +0100 Subject: [Aptitude-devel] Bug#792681: cwidget ftbfs with GCC 5 In-Reply-To: <55AA1339.8060700@debian.org> References: <55A8FF6A.3010006@debian.org> <55AA1339.8060700@debian.org> Message-ID: <20150718212925.GA19311@reva.itsari.org> 2015-07-18 09:50 Matthias Klose: >On 07/17/2015 06:57 PM, Manuel A. Fernandez Montecelo wrote: >> Hello, >> >> 2015-07-17 14:13 GMT+01:00 Matthias Klose : >>> Package: src:cwidget >>> Version: 0.5.17-2 >>> Severity: normal >>> Tags: sid stretch patch >>> User: debian-gcc at lists.debian.org >>> Usertags: ftbfs-gcc-5 >>> >>> GCC 5 complains about using c++11 features without passing -std=c++11. Also >>> setting the maintainer flag without exporting it doesn't help. >>> >>> patch at >>> https://launchpadlibrarian.net/211899860/cwidget_0.5.17-2ubuntu1_0.5.17-2ubuntu2.diff.gz >> >> If I found the correct build log where you determined this [1], the >> compiler fails when including >> >> In file included from /usr/include/c++/5/string:52:0, >> from ../../../src/cwidget/curses++.h:25, >> from colors.cc:22: >> >> Line 22 of colors is: >> #include >> >> And line 25 of curses++.h is: >> #include >> >> The error is: >> ----------------------- >> /usr/include/c++/5/bits/basic_string.h: In instantiation of 'union >> std::__cxx11::basic_string::': >> /usr/include/c++/5/bits/basic_string.h:119:7: required from 'class >> std::__cxx11::basic_string' >> ../../../src/cwidget/curses++.h:199:31: required from here >> /usr/include/c++/5/bits/basic_string.h:121:53: error: member >> 'cwidget::wchtype >> std::__cxx11::basic_string::> union>::_M_local_buf [1]' with constructor not allowed in union >> _CharT _M_local_buf[_S_local_capacity + 1]; >> ^ >> /usr/include/c++/5/bits/basic_string.h:121:53: note: unrestricted >> unions only available with -std=c++11 or -std=gnu++11 >> ----------------------- >> >> This is because wchtype does not seem to be able to be used as part of >> unions inside basic_string.h because the constructors/destructors are >> not "trivial" enough. >> >> I was trying to work around this for a while, because I think that >> forcing c++11 mode will have cascading effects on rev-deps (currently >> only one within Debian, but it is aptitude with almost 100% of >> reported installations by popcon), but I could not find a satisfactory >> solution yet. >> >> Is there a deadline to fix this? > >yes, Jul 31. please see my email to d-d-a. OK. I knew of the deadline to set GCC-5 as default, I was asking in the case that you planned to NMU before that or not even after it was made default. >> [1] https://people.debian.org/~doko/logs/gcc5-20150701-ftbfs/logs-failed-gcc5/cwidget_0.5.17-2_unstable_gcc5.log > >this was the error I saw: >[...] >Making all in config >make[5]: Entering directory >'/scratch/packages/tmp/cwidget-0.5.17/src/cwidget/config' >/bin/bash ../../../libtool --tag=CXX --mode=compile g++ >-DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. -I../../.. -Wall -Werror >-I../../.. -I. -I../../.. -I../../../src -D_FORTIFY_SOURCE=2 -g -O2 >-fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT >-I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -c -o >colors.lo colors.cc >libtool: compile: g++ -DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. >-I../../.. -Wall -Werror -I../../.. -I. -I../../.. -I../../../src >-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat >-Werror=format-security -D_REENTRANT -I/usr/include/sigc++-2.0 >-I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -c colors.cc -fPIC -DPIC -o >.libs/colors.o >In file included from /usr/include/c++/5/string:52:0, > from ../../../src/cwidget/curses++.h:25, > from colors.cc:22: >/usr/include/c++/5/bits/basic_string.h: In instantiation of 'union >std::__cxx11::basic_string::': >/usr/include/c++/5/bits/basic_string.h:119:7: required from 'class >std::__cxx11::basic_string' >../../../src/cwidget/curses++.h:199:31: required from here >/usr/include/c++/5/bits/basic_string.h:121:53: error: member 'cwidget::wchtype >std::__cxx11::basic_string::::_M_local_buf >[1]' with constructor not allowed in union > _CharT _M_local_buf[_S_local_capacity + 1]; > ^ >/usr/include/c++/5/bits/basic_string.h:121:53: note: unrestricted unions only >available with -std=c++11 or -std=gnu++11 >Makefile:448: recipe for target 'colors.lo' failed >make[5]: *** [colors.lo] Error 1 >make[5]: Leaving directory '/scratch/packages/tmp/cwidget-0.5.17/src/cwidget/config' >Makefile:603: recipe for target 'all-recursive' failed >make[4]: *** [all-recursive] Error 1 I get this error with GCC-5 even if I let the default or explicitly set -std=c++98, which is strange -- why does it try to include C++11 stuff even then, like the namespaces in "required from 'class std::__cxx11::basic_string'" in the errors above? It's a bit odd. Also, this code did not change for many years and it was compiling fine, I was trying to look at GCC changelog but I did not see anything immediately obvious that it causes it to fail after years working fine. Anyway, aptitude with GCC-5 and -std=c++98 also suffers the same problem as cwidget, because it fails to compile the cwidget header, if nothing else. But if cwidget goes C++11, it forces aptitude to go C++11, and it doesn't work for other reasons (that I am working to fix), so we are between a rock and a hard place. Even if I can fix things in time before the deadline, maybe subtle changes like the ABI problems make aptitude fail in catastrophic ways, there is not much time to expose it and be tested before the deadline in experimental or similar. I am thinking that the best solution is to force them to stay with gcc-4.9 for the time being, it looks the safest bet. After that or in parallel, as soon as I get things working, I can upload to experimental the changes that allow them to work with C++11, and keep it there for a while before moving to unstable. Cheers. -- Manuel A. Fernandez Montecelo From manuel.montezelo at gmail.com Sat Jul 18 21:29:25 2015 From: manuel.montezelo at gmail.com (Manuel A. Fernandez Montecelo) Date: Sat, 18 Jul 2015 22:29:25 +0100 Subject: [Aptitude-devel] Bug#777778: Bug#792681: cwidget ftbfs with GCC 5 In-Reply-To: <55AA1339.8060700@debian.org> References: <55A8FF6A.3010006@debian.org> <55AA1339.8060700@debian.org> Message-ID: <20150718212925.GA19311@reva.itsari.org> 2015-07-18 09:50 Matthias Klose: >On 07/17/2015 06:57 PM, Manuel A. Fernandez Montecelo wrote: >> Hello, >> >> 2015-07-17 14:13 GMT+01:00 Matthias Klose : >>> Package: src:cwidget >>> Version: 0.5.17-2 >>> Severity: normal >>> Tags: sid stretch patch >>> User: debian-gcc at lists.debian.org >>> Usertags: ftbfs-gcc-5 >>> >>> GCC 5 complains about using c++11 features without passing -std=c++11. Also >>> setting the maintainer flag without exporting it doesn't help. >>> >>> patch at >>> https://launchpadlibrarian.net/211899860/cwidget_0.5.17-2ubuntu1_0.5.17-2ubuntu2.diff.gz >> >> If I found the correct build log where you determined this [1], the >> compiler fails when including >> >> In file included from /usr/include/c++/5/string:52:0, >> from ../../../src/cwidget/curses++.h:25, >> from colors.cc:22: >> >> Line 22 of colors is: >> #include >> >> And line 25 of curses++.h is: >> #include >> >> The error is: >> ----------------------- >> /usr/include/c++/5/bits/basic_string.h: In instantiation of 'union >> std::__cxx11::basic_string::': >> /usr/include/c++/5/bits/basic_string.h:119:7: required from 'class >> std::__cxx11::basic_string' >> ../../../src/cwidget/curses++.h:199:31: required from here >> /usr/include/c++/5/bits/basic_string.h:121:53: error: member >> 'cwidget::wchtype >> std::__cxx11::basic_string::> union>::_M_local_buf [1]' with constructor not allowed in union >> _CharT _M_local_buf[_S_local_capacity + 1]; >> ^ >> /usr/include/c++/5/bits/basic_string.h:121:53: note: unrestricted >> unions only available with -std=c++11 or -std=gnu++11 >> ----------------------- >> >> This is because wchtype does not seem to be able to be used as part of >> unions inside basic_string.h because the constructors/destructors are >> not "trivial" enough. >> >> I was trying to work around this for a while, because I think that >> forcing c++11 mode will have cascading effects on rev-deps (currently >> only one within Debian, but it is aptitude with almost 100% of >> reported installations by popcon), but I could not find a satisfactory >> solution yet. >> >> Is there a deadline to fix this? > >yes, Jul 31. please see my email to d-d-a. OK. I knew of the deadline to set GCC-5 as default, I was asking in the case that you planned to NMU before that or not even after it was made default. >> [1] https://people.debian.org/~doko/logs/gcc5-20150701-ftbfs/logs-failed-gcc5/cwidget_0.5.17-2_unstable_gcc5.log > >this was the error I saw: >[...] >Making all in config >make[5]: Entering directory >'/scratch/packages/tmp/cwidget-0.5.17/src/cwidget/config' >/bin/bash ../../../libtool --tag=CXX --mode=compile g++ >-DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. -I../../.. -Wall -Werror >-I../../.. -I. -I../../.. -I../../../src -D_FORTIFY_SOURCE=2 -g -O2 >-fstack-protector-strong -Wformat -Werror=format-security -D_REENTRANT >-I/usr/include/sigc++-2.0 -I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -c -o >colors.lo colors.cc >libtool: compile: g++ -DLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H -I. >-I../../.. -Wall -Werror -I../../.. -I. -I../../.. -I../../../src >-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat >-Werror=format-security -D_REENTRANT -I/usr/include/sigc++-2.0 >-I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include -c colors.cc -fPIC -DPIC -o >.libs/colors.o >In file included from /usr/include/c++/5/string:52:0, > from ../../../src/cwidget/curses++.h:25, > from colors.cc:22: >/usr/include/c++/5/bits/basic_string.h: In instantiation of 'union >std::__cxx11::basic_string::': >/usr/include/c++/5/bits/basic_string.h:119:7: required from 'class >std::__cxx11::basic_string' >../../../src/cwidget/curses++.h:199:31: required from here >/usr/include/c++/5/bits/basic_string.h:121:53: error: member 'cwidget::wchtype >std::__cxx11::basic_string::::_M_local_buf >[1]' with constructor not allowed in union > _CharT _M_local_buf[_S_local_capacity + 1]; > ^ >/usr/include/c++/5/bits/basic_string.h:121:53: note: unrestricted unions only >available with -std=c++11 or -std=gnu++11 >Makefile:448: recipe for target 'colors.lo' failed >make[5]: *** [colors.lo] Error 1 >make[5]: Leaving directory '/scratch/packages/tmp/cwidget-0.5.17/src/cwidget/config' >Makefile:603: recipe for target 'all-recursive' failed >make[4]: *** [all-recursive] Error 1 I get this error with GCC-5 even if I let the default or explicitly set -std=c++98, which is strange -- why does it try to include C++11 stuff even then, like the namespaces in "required from 'class std::__cxx11::basic_string'" in the errors above? It's a bit odd. Also, this code did not change for many years and it was compiling fine, I was trying to look at GCC changelog but I did not see anything immediately obvious that it causes it to fail after years working fine. Anyway, aptitude with GCC-5 and -std=c++98 also suffers the same problem as cwidget, because it fails to compile the cwidget header, if nothing else. But if cwidget goes C++11, it forces aptitude to go C++11, and it doesn't work for other reasons (that I am working to fix), so we are between a rock and a hard place. Even if I can fix things in time before the deadline, maybe subtle changes like the ABI problems make aptitude fail in catastrophic ways, there is not much time to expose it and be tested before the deadline in experimental or similar. I am thinking that the best solution is to force them to stay with gcc-4.9 for the time being, it looks the safest bet. After that or in parallel, as soon as I get things working, I can upload to experimental the changes that allow them to work with C++11, and keep it there for a while before moving to unstable. Cheers. -- Manuel A. Fernandez Montecelo From josef.andersson at fripost.org Mon Jul 20 02:17:45 2015 From: josef.andersson at fripost.org (Josef Andersson) Date: Mon, 20 Jul 2015 04:17:45 +0200 Subject: [Aptitude-devel] Bug#792911: Updated Swedish translation for aptitude Message-ID: <55AC5A49.8070402@fripost.org> Package: aptitude Version: 0.6.11 Attached is an updated Swedish translation for aptitude, originated from trunk ( so really is 0.6.11 and ++), reviewed by fellow translator at the Swedish tp-sv-project. Please commit. Best Regards Josef Andersson -------------- next part -------------- A non-text attachment was scrubbed... Name: aptitude_updated_sv_transl.zip Type: application/zip Size: 62550 bytes Desc: not available URL: From josef.andersson at gmail.com Mon Jul 20 02:26:20 2015 From: josef.andersson at gmail.com (Josef Andersson) Date: Mon, 20 Jul 2015 04:26:20 +0200 Subject: [Aptitude-devel] Bug#792912: Updated Swedish translation for aptitude In-Reply-To: <55AC5A49.8070402@fripost.org> References: <55AC5A49.8070402@fripost.org> Message-ID: <55AC5C4C.4030607@gmail.com> Package: aptitude Version: 0.6.11 Attached is an updated Swedish translation for aptitude, originated from trunk ( so really is 0.6.11 and ++), reviewed by fellow translator at the Swedish tp-sv-project. Please commit. Best Regards Josef Andersson -------------- next part -------------- A non-text attachment was scrubbed... Name: aptitude_updated_sv_transl.zip Type: application/zip Size: 62550 bytes Desc: not available URL: From doko at debian.org Mon Jul 20 14:24:12 2015 From: doko at debian.org (Matthias Klose) Date: Mon, 20 Jul 2015 16:24:12 +0200 Subject: [Aptitude-devel] Bug#792681: cwidget ftbfs with GCC 5 In-Reply-To: <20150718212925.GA19311@reva.itsari.org> References: <55A8FF6A.3010006@debian.org> <55AA1339.8060700@debian.org> <20150718212925.GA19311@reva.itsari.org> Message-ID: <55AD048C.7010608@debian.org> On 07/18/2015 11:29 PM, Manuel A. Fernandez Montecelo wrote: > Anyway, aptitude with GCC-5 and -std=c++98 also suffers the same problem as > cwidget, because it fails to compile the cwidget header, if nothing else. But > if cwidget goes C++11, it forces aptitude to go C++11, and it doesn't work for > other reasons (that I am working to fix), so we are between a rock and a hard > place. > > Even if I can fix things in time before the deadline, maybe subtle changes like > the ABI problems make aptitude fail in catastrophic ways, there is not much time > to expose it and be tested before the deadline in experimental or similar. > > I am thinking that the best solution is to force them to stay with gcc-4.9 for > the time being, it looks the safest bet. After that or in parallel, as soon as > I get things working, I can upload to experimental the changes that allow them > to work with C++11, and keep it there for a while before moving to unstable. no, this is definitely *not* an option. cwidget and aptitude b-d on libsigc++-2, and this will be built using GCC 5. There will be neither g++-4.9 nor g++-4.8 in the archive once we finish this transition. Maintainers don't have the choice to fall-back to an older version this time. Matthias From doko at debian.org Mon Jul 20 14:24:12 2015 From: doko at debian.org (Matthias Klose) Date: Mon, 20 Jul 2015 16:24:12 +0200 Subject: [Aptitude-devel] Bug#777778: Bug#792681: cwidget ftbfs with GCC 5 In-Reply-To: <20150718212925.GA19311@reva.itsari.org> References: <55A8FF6A.3010006@debian.org> <55AA1339.8060700@debian.org> <20150718212925.GA19311@reva.itsari.org> Message-ID: <55AD048C.7010608@debian.org> On 07/18/2015 11:29 PM, Manuel A. Fernandez Montecelo wrote: > Anyway, aptitude with GCC-5 and -std=c++98 also suffers the same problem as > cwidget, because it fails to compile the cwidget header, if nothing else. But > if cwidget goes C++11, it forces aptitude to go C++11, and it doesn't work for > other reasons (that I am working to fix), so we are between a rock and a hard > place. > > Even if I can fix things in time before the deadline, maybe subtle changes like > the ABI problems make aptitude fail in catastrophic ways, there is not much time > to expose it and be tested before the deadline in experimental or similar. > > I am thinking that the best solution is to force them to stay with gcc-4.9 for > the time being, it looks the safest bet. After that or in parallel, as soon as > I get things working, I can upload to experimental the changes that allow them > to work with C++11, and keep it there for a while before moving to unstable. no, this is definitely *not* an option. cwidget and aptitude b-d on libsigc++-2, and this will be built using GCC 5. There will be neither g++-4.9 nor g++-4.8 in the archive once we finish this transition. Maintainers don't have the choice to fall-back to an older version this time. Matthias From manuel.montezelo at gmail.com Mon Jul 20 15:02:00 2015 From: manuel.montezelo at gmail.com (Manuel A. Fernandez Montecelo) Date: Mon, 20 Jul 2015 16:02:00 +0100 Subject: [Aptitude-devel] Bug#792681: cwidget ftbfs with GCC 5 In-Reply-To: <55AD048C.7010608@debian.org> References: <55A8FF6A.3010006@debian.org> <55AA1339.8060700@debian.org> <20150718212925.GA19311@reva.itsari.org> <55AD048C.7010608@debian.org> Message-ID: 2015-07-20 15:24 GMT+01:00 Matthias Klose : > On 07/18/2015 11:29 PM, Manuel A. Fernandez Montecelo wrote: >> Anyway, aptitude with GCC-5 and -std=c++98 also suffers the same problem as >> cwidget, because it fails to compile the cwidget header, if nothing else. But >> if cwidget goes C++11, it forces aptitude to go C++11, and it doesn't work for >> other reasons (that I am working to fix), so we are between a rock and a hard >> place. >> >> Even if I can fix things in time before the deadline, maybe subtle changes like >> the ABI problems make aptitude fail in catastrophic ways, there is not much time >> to expose it and be tested before the deadline in experimental or similar. >> >> I am thinking that the best solution is to force them to stay with gcc-4.9 for >> the time being, it looks the safest bet. After that or in parallel, as soon as >> I get things working, I can upload to experimental the changes that allow them >> to work with C++11, and keep it there for a while before moving to unstable. > > no, this is definitely *not* an option. cwidget and aptitude b-d on > libsigc++-2, and this will be built using GCC 5. There will be neither g++-4.9 > nor g++-4.8 in the archive once we finish this transition. Maintainers don't > have the choice to fall-back to an older version this time. Right. So I have been working through the weekend to get aptitude to compile with -std=c++11 (working in my system but still not pushed). As you reported, there are problems compiling aptitude with gcc-5 in the default mode, and after the failure that you reported it will stumble upon the same problem that cwidget when including that cwidget header (for which passing "-std=c++11" is the simplest solution, and also the only that I found so far). In terms of C++-based dependencies, aptitude depends on libsigc++-2.0, xapian-core (#791312, it will not be ready immediately but soon enough, it seems), apt and boost (gcc-5 ready, it seems). I don't know the details about sigc++ and apt, but if all of them are going to be compiled with gcc-5 soon after its move to unstable, cwidget and aptitude will be ready as well. Now we have to work out the details about how to upload the changes, enable them in lockstep and avoid breakages as much as possible (e.g. tighten versions on the compiler and lib dependencies). Cheers. -- Manuel A. Fernandez Montecelo From manuel.montezelo at gmail.com Mon Jul 20 15:02:00 2015 From: manuel.montezelo at gmail.com (Manuel A. Fernandez Montecelo) Date: Mon, 20 Jul 2015 16:02:00 +0100 Subject: [Aptitude-devel] Bug#777778: Bug#792681: cwidget ftbfs with GCC 5 In-Reply-To: <55AD048C.7010608@debian.org> References: <55A8FF6A.3010006@debian.org> <55AA1339.8060700@debian.org> <20150718212925.GA19311@reva.itsari.org> <55AD048C.7010608@debian.org> Message-ID: 2015-07-20 15:24 GMT+01:00 Matthias Klose : > On 07/18/2015 11:29 PM, Manuel A. Fernandez Montecelo wrote: >> Anyway, aptitude with GCC-5 and -std=c++98 also suffers the same problem as >> cwidget, because it fails to compile the cwidget header, if nothing else. But >> if cwidget goes C++11, it forces aptitude to go C++11, and it doesn't work for >> other reasons (that I am working to fix), so we are between a rock and a hard >> place. >> >> Even if I can fix things in time before the deadline, maybe subtle changes like >> the ABI problems make aptitude fail in catastrophic ways, there is not much time >> to expose it and be tested before the deadline in experimental or similar. >> >> I am thinking that the best solution is to force them to stay with gcc-4.9 for >> the time being, it looks the safest bet. After that or in parallel, as soon as >> I get things working, I can upload to experimental the changes that allow them >> to work with C++11, and keep it there for a while before moving to unstable. > > no, this is definitely *not* an option. cwidget and aptitude b-d on > libsigc++-2, and this will be built using GCC 5. There will be neither g++-4.9 > nor g++-4.8 in the archive once we finish this transition. Maintainers don't > have the choice to fall-back to an older version this time. Right. So I have been working through the weekend to get aptitude to compile with -std=c++11 (working in my system but still not pushed). As you reported, there are problems compiling aptitude with gcc-5 in the default mode, and after the failure that you reported it will stumble upon the same problem that cwidget when including that cwidget header (for which passing "-std=c++11" is the simplest solution, and also the only that I found so far). In terms of C++-based dependencies, aptitude depends on libsigc++-2.0, xapian-core (#791312, it will not be ready immediately but soon enough, it seems), apt and boost (gcc-5 ready, it seems). I don't know the details about sigc++ and apt, but if all of them are going to be compiled with gcc-5 soon after its move to unstable, cwidget and aptitude will be ready as well. Now we have to work out the details about how to upload the changes, enable them in lockstep and avoid breakages as much as possible (e.g. tighten versions on the compiler and lib dependencies). Cheers. -- Manuel A. Fernandez Montecelo From juchem at gmail.com Mon Jul 20 19:21:45 2015 From: juchem at gmail.com (Marcelo Juchem) Date: Mon, 20 Jul 2015 12:21:45 -0700 Subject: [Aptitude-devel] Bug#793042: aptitude: Preview doesn't separate pkg to be upgraded and auto upgraded Message-ID: Package: aptitude Version: 0.6.11-1+b1 Severity: normal The preview window (pressing g once) displays groups for packages to be installed, removed and held back, for instance. It also displays separate groups for packages to be automatically installed, removed and held back. For packages to be upgraded, though, both manually and automatically selected packages are grouped together. They should be displayed separately for easier inspection and conformance to the other action types. Aptitude should display two groups for packages to be upgraded: one for manually and one for automatically selected packages. -- Package-specific info: Terminal: xterm-256color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.11 compiled at Nov 8 2014 13:34:39 Compiler: g++ 4.9.1 Compiled against: apt version 4.12.0 NCurses version 5.9 libsigc++ version: 2.4.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20150516 cwidget version: 0.5.17 Apt version: 4.12.0 aptitude linkage: linux-vdso.so.1 (0x00007ffd32f4e000) libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x00007ff79f38b000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x00007ff79f155000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007ff79ef2b000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x00007ff79ed25000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x00007ff79ea0f000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007ff79e741000) libboost_iostreams.so.1.55.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x00007ff79e529000) libxapian.so.22 => /usr/lib/libxapian.so.22 (0x00007ff79e112000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff79def5000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff79dbe9000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff79d8e8000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff79d6d2000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff79d329000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007ff79d126000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff79cf22000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff79cd07000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007ff79caf7000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007ff79c8d4000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff79c6cc000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007ff79c4c7000) /lib64/ld-linux-x86-64.so.2 (0x00007ff79fd4d000) -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common 0.6.11-1 ii libapt-pkg4.12 1.0.9.10 ii libboost-iostreams1.55.0 1.55.0+dfsg-4 ii libc6 2.19-19 ii libcwidget3 0.5.17-2 ii libgcc1 1:5.1.1-14 ii libncursesw5 5.9+20150516-2 ii libsigc++-2.0-0c2a 2.4.1-1 ii libsqlite3-0 3.8.10.2-1 ii libstdc++6 5.1.1-14 ii libtinfo5 5.9+20150516-2 ii libxapian22 1.2.21-1 Versions of packages aptitude recommends: pn aptitude-doc-en | aptitude-doc ii libparse-debianchangelog-perl 1.2.0-5 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: pn apt-xapian-index pn debtags pn tasksel -- no debconf information -------------- next part -------------- An HTML attachment was scrubbed... URL: From jianghl at ad-r.net Tue Jul 21 10:25:23 2015 From: jianghl at ad-r.net (=?windows-1251?B?wPD46O3t6Oru4g==?=) Date: Tue, 21 Jul 2015 14:25:23 +0400 Subject: [Aptitude-devel] =?cp1251?b?x+Dw4OHu8uDpIO3gIP3r6PLt++kg7vLk+/Ug?= =?cp1251?b?8yDs7vD/Li4ue2plemt3aGd9?= Message-ID: <2D289ECDC6123F3CE0E5AC40B40B7383@ejfg> ????? ?????? ?? ??????? ????? ? ????!?[eexsczqq] ????? ???? ????... [http://tinyurl.com/npdk952] [odkxp] [yrcoxcl] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ban.artem.v at gmail.com Wed Jul 22 17:04:31 2015 From: ban.artem.v at gmail.com (artem_banschikov) Date: Wed, 22 Jul 2015 20:04:31 +0300 Subject: [Aptitude-devel] Bug#793307: aptitude: Add a confirmation for changing 'automatic' flag Message-ID: <20150722170431.28068.13611.reportbug@debian> Package: aptitude Version: 0.6.11-1+b1 Severity: wishlist Dear Maintainer, I occasionally pressed 'm' button when 'All installed packages' item was choosen, so all my packages were marked as manually installed. 'm' is placed right under 'j' which is often used for navigation, so occasional presses on it is a real problem for me. Please, add some kind of confirmation for changing package 'automatic' flag with 'm' button. Also, I saw some bugs when aptitude forgets 'automatic' flag for some packages and I thought some of them may be inspited by occasional 'm' press. -- Package-specific info: Terminal: rxvt-unicode $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.11 compiled at Nov 8 2014 13:34:39 Compiler: g++ 4.9.1 Compiled against: apt version 4.12.0 NCurses version 5.9 libsigc++ version: 2.4.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20150516 cwidget version: 0.5.17 Apt version: 4.12.0 aptitude linkage: linux-vdso.so.1 (0x00007ffefdbc2000) libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x00007f8c8d223000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x00007f8c8cfed000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f8c8cdc3000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x00007f8c8cbbd000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x00007f8c8c8a7000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f8c8c5d9000) libboost_iostreams.so.1.55.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x00007f8c8c3c1000) libxapian.so.22 => /usr/lib/libxapian.so.22 (0x00007f8c8bfaa000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8c8bd8d000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8c8ba81000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8c8b780000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8c8b56a000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8c8b1c1000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f8c8afbe000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8c8adba000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8c8ab9f000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f8c8a98f000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f8c8a76c000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f8c8a564000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f8c8a35f000) /lib64/ld-linux-x86-64.so.2 (0x00007f8c8dbe5000) -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (99, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common 0.6.11-1 ii libapt-pkg4.12 1.0.9.10 ii libboost-iostreams1.55.0 1.55.0+dfsg-4 ii libc6 2.19-19 ii libcwidget3 0.5.17-2 ii libgcc1 1:5.1.1-14 ii libncursesw5 5.9+20150516-2 ii libsigc++-2.0-0c2a 2.4.1-1 ii libsqlite3-0 3.8.10.2-1 ii libstdc++6 5.1.1-14 ii libtinfo5 5.9+20150516-2 ii libxapian22 1.2.21-1 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc] 0.6.11-1 ii libparse-debianchangelog-perl 1.2.0-5 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: ii apt-xapian-index 0.47 pn debtags ii tasksel 3.32 -- no debconf information From abe at debian.org Wed Jul 22 17:24:07 2015 From: abe at debian.org (Axel Beckert) Date: Wed, 22 Jul 2015 19:24:07 +0200 Subject: [Aptitude-devel] Bug#793307: Bug#793307: aptitude: Add a confirmation for changing 'automatic' flag In-Reply-To: <20150722170431.28068.13611.reportbug@debian> References: <20150722170431.28068.13611.reportbug@debian> Message-ID: <20150722172407.GM2433@sym.noone.org> Hi, artem_banschikov wrote: > I occasionally pressed 'm' button when 'All installed packages' item was > choosen, so all my packages were marked as manually installed. 'm' is placed > right under 'j' which is often used for navigation, so occasional > presses on it is a real problem for me. There's an undo function in aptitude, bound to Ctrl-U. This easily reverts such mistakes (if they're noticed quickly enough). > Please, add some kind of confirmation for changing package > 'automatic' flag with 'm' button. I'd consider that rather annoying, but I can understand the motivation. If we do so, we should a) make it optional (on by default is fine for me), b) only ask for confirmation if it would catch more than one package (i.e. for whole branches) c) only for "m", not for "M" (as the subject may suggest) > Also, I saw some bugs when aptitude forgets 'automatic' flag for > some packages and I thought some of them may be inspited by > occasional 'm' press. Possibly. But there are definitely cases where this happens without mistyping key-press commands. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE From ban.artem.v at gmail.com Wed Jul 22 19:01:30 2015 From: ban.artem.v at gmail.com (artem_banschikov) Date: Wed, 22 Jul 2015 22:01:30 +0300 Subject: [Aptitude-devel] Bug#793307: Bug#793307: aptitude: Add a confirmation for changing 'automatic' flag In-Reply-To: <20150722172407.GM2433@sym.noone.org> References: <20150722170431.28068.13611.reportbug@debian> <20150722172407.GM2433@sym.noone.org> Message-ID: <20150722190130.GA7205@localhost> On Wed, 22 Jul 2015 19:24:07 +0200 Axel Beckert wrote: Hi, > If we do so, we should > > a) make it optional (on by default is fine for me), Completely agree. > b) only ask for confirmation if it would catch more than one package > (i.e. for whole branches) I thought about three options: ask for one package, ask for multiple packages, not ask at all. There is file deletion dialog in Ranger file-manager made in this way. > c) only for "m", not for "M" (as the subject may suggest) Confirmation for "M" may be added for consistency. Anyway I'll be glad if you make exactly as you said as it will entirely solve my problem. Best regards, Artyom. From manuel.montezelo at gmail.com Fri Jul 24 18:54:09 2015 From: manuel.montezelo at gmail.com (Manuel A. Fernandez Montecelo) Date: Fri, 24 Jul 2015 19:54:09 +0100 Subject: [Aptitude-devel] Bug#793307: Bug#793307: Bug#793307: aptitude: Add a confirmation for changing 'automatic' flag In-Reply-To: <20150722190130.GA7205@localhost> References: <20150722170431.28068.13611.reportbug@debian> <20150722172407.GM2433@sym.noone.org> <20150722190130.GA7205@localhost> Message-ID: <20150724185409.GA3068@reva.itsari.org> 2015-07-22 20:01 artem_banschikov: >On Wed, 22 Jul 2015 19:24:07 +0200 Axel Beckert wrote: >Hi, >> If we do so, we should >> >> a) make it optional (on by default is fine for me), >Completely agree. >> b) only ask for confirmation if it would catch more than one package >> (i.e. for whole branches) >I thought about three options: ask for one package, ask for multiple >packages, not ask at all. There is file deletion dialog in Ranger >file-manager made in this way. >> c) only for "m", not for "M" (as the subject may suggest) >Confirmation for "M" may be added for consistency. > >Anyway I'll be glad if you make exactly as you said as it will entirely solve >my problem. > >Best regards, Artyom. What about Undo (Control-U), as Axel suggested in the previous e-mail? IMO it is a more general solution, and already implemented, so it should be favoured rather than adding these new options (unless it does not work). Cheers. -- Manuel A. Fernandez Montecelo From owner at bugs.debian.org Sun Jul 26 13:30:08 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Sun, 26 Jul 2015 13:30:08 +0000 Subject: [Aptitude-devel] Processed: tagging 758226 References: <1437917257-2431-bts-abe@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > tags 758226 + pending Bug #758226 [aptitude] [l10n] Updated Czech translation of aptitude Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 758226: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758226 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Sun Jul 26 13:33:04 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Sun, 26 Jul 2015 13:33:04 +0000 Subject: [Aptitude-devel] Processed: tagging 760812 References: <1437917458-3252-bts-abe@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > tags 760812 + pending Bug #760812 [aptitude] aptitude: [INTL:ru] Russian program translation update Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 760812: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760812 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From abe at debian.org Sun Jul 26 13:44:26 2015 From: abe at debian.org (Axel Beckert) Date: Sun, 26 Jul 2015 15:44:26 +0200 Subject: [Aptitude-devel] Bug#762340: Bug#762340: aptitude: [INTL:de] partially updated German man page translation In-Reply-To: <20140921111050.GA27249@Debian-50-lenny-64-minimal> References: <20140921111050.GA27249@Debian-50-lenny-64-minimal> Message-ID: <20150726134426.GC2433@sym.noone.org> Control: tag -1 + moreinfo Hi Helge, Helge Kreutzmann wrote: > Please find the partial updated German man page translation > for aptitude at > http://www.helgefjell.de/data/aptitude_0.6.10-1_de.po.bz2 This looks rather like a complete rewrite than something partial: ? git diff --stat po/de.po | 27013 +++++++++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 18992 insertions(+), 8020 deletions(-) ? wc -l po/de.po 9373 po/de.po I'm especially concerned because it removes copyright statements of some of the previous translators. I'd expect either no removal at all or the removal of all previous translators if the file has been rewritten from scratch. diff --git a/po/de.po b/po/de.po index 2bffb38..18028f6 100644 --- a/po/de.po +++ b/po/de.po @@ -1,9373 +1,20346 @@ -# Deutsche ?bersetzung zu Aptitude -# Copyright (c) 2002 Daniel Burrows -# Copyright (c) 2002 Erich Schubert -# Copyright (c) 2004 Sebastian Kapfer -# Copyright (c) 2004 Dennis Stampfer -# Copyright (c) 2006, 2008 Jens Seidel -# Copyright (c) 2010-2013 Holger Wansing -# Copyright (c) 2013 Benjamin Weis +# German translation of aptitude's documentation. +# This file is distributed under the same license as the aptitude package. +# Sebastian Kapfer , 2004. +# Jens Seidel , 2009. +# Mario Bl?ttermann , 2014. I'd be happy if you or Mario could explain these changes. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE From owner at bugs.debian.org Sun Jul 26 13:45:07 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Sun, 26 Jul 2015 13:45:07 +0000 Subject: [Aptitude-devel] Processed: Re: Bug#762340: aptitude: [INTL:de] partially updated German man page translation References: <20150726134426.GC2433@sym.noone.org> <20140921111050.GA27249@Debian-50-lenny-64-minimal> Message-ID: Processing control commands: > tag -1 + moreinfo Bug #762340 [aptitude] aptitude: [INTL:de] partially updated German man page translation Added tag(s) moreinfo. -- 762340: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762340 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Sun Jul 26 14:06:06 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Sun, 26 Jul 2015 14:06:06 +0000 Subject: [Aptitude-devel] Processed: limit source to aptitude, tagging 770073, tagging 771618 References: <1437919349-2447-bts-abe@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > limit source aptitude Limiting to bugs with field 'source' containing at least one of 'aptitude' Limit currently set to 'source':'aptitude' > tags 770073 + pending Bug #770073 [aptitude] [PATCH] Add documentation on missing package states Bug #771305 [aptitude] mantual: document 'T' state flag Bug #771704 [aptitude] aptitude-doc: ?Current state? flag values list is incomplete Added tag(s) pending. Added tag(s) pending. Added tag(s) pending. > tags 771618 + pending Bug #771618 [aptitude] aptitude: [l10n] Updated catalan translation Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 770073: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770073 771305: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771305 771618: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771618 771704: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771704 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From abe at debian.org Sun Jul 26 14:10:43 2015 From: abe at debian.org (Axel Beckert) Date: Sun, 26 Jul 2015 16:10:43 +0200 Subject: [Aptitude-devel] Bug#762340: Bug#762340: Bug#762340: aptitude: [INTL:de] partially updated German man page translation In-Reply-To: <20150726134426.GC2433@sym.noone.org> References: <20140921111050.GA27249@Debian-50-lenny-64-minimal> <20150726134426.GC2433@sym.noone.org> Message-ID: <20150726141043.GD2433@sym.noone.org> Control: tag -1 - moreinfo + pending Hi Helge and Mario, Axel Beckert wrote: > Helge Kreutzmann wrote: > > Please find the partial updated German man page translation > > for aptitude at > > http://www.helgefjell.de/data/aptitude_0.6.10-1_de.po.bz2 > > This looks rather like a complete rewrite than something partial: My fault: I diffed it against the program translation instead of the man page translation. Of course that gives a huge diff. ;-) Sorry for the noise. Will apply it in the git repository soon. Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE From owner at bugs.debian.org Sun Jul 26 14:15:05 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Sun, 26 Jul 2015 14:15:05 +0000 Subject: [Aptitude-devel] Processed: Re: Bug#762340: Bug#762340: aptitude: [INTL:de] partially updated German man page translation References: <20150726141043.GD2433@sym.noone.org> <20140921111050.GA27249@Debian-50-lenny-64-minimal> Message-ID: Processing control commands: > tag -1 - moreinfo + pending Bug #762340 [aptitude] aptitude: [INTL:de] partially updated German man page translation Removed tag(s) moreinfo. Bug #762340 [aptitude] aptitude: [INTL:de] partially updated German man page translation Added tag(s) pending. -- 762340: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762340 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Sun Jul 26 14:21:07 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Sun, 26 Jul 2015 14:21:07 +0000 Subject: [Aptitude-devel] Processed: tagging 773807 References: <1437920213-3882-bts-abe@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > tags 773807 + pending Bug #773807 [aptitude] aptitude: [l10n] Updated French translation for aptitude documentation Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 773807: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773807 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Sun Jul 26 14:24:05 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Sun, 26 Jul 2015 14:24:05 +0000 Subject: [Aptitude-devel] Processed: tagging 776706 References: <1437920487-3609-bts-abe@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > tags 776706 + pending Bug #776706 [aptitude] aptitude: [INTL:it] Updated Italian translation of aptitude documentation via po4a Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 776706: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776706 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Sun Jul 26 14:27:04 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Sun, 26 Jul 2015 14:27:04 +0000 Subject: [Aptitude-devel] Processed: tagging 778425 References: <1437920732-1825-bts-abe@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > tags 778425 + pending Bug #778425 [aptitude] aptitude: [INTL:nl] Dutch po file for the aptitude package Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 778425: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778425 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Sun Jul 26 14:30:09 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Sun, 26 Jul 2015 14:30:09 +0000 Subject: [Aptitude-devel] Processed: limit source to aptitude, tagging 686124, tagging 686142, tagging 686646 References: <1437920853-2551-bts-abe@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > limit source aptitude Limiting to bugs with field 'source' containing at least one of 'aptitude' Limit currently set to 'source':'aptitude' > # Categorical Browser Removal > tags 686124 + pending Bug #686124 [aptitude] aptitude segfaults when trying to use a new categorical package browser Bug #702529 [aptitude] aptitude: segfault when selecting "new view", "by category" Bug #704965 [aptitude] Segmentation fault when opening Views -> Categorical Browser Bug #717317 [aptitude] aptitude: segfault when choosing Views -> New Categorical Browser in ncurses interface Bug #782872 [aptitude] aptitude: SIGSEGV got when create "New Categorical Browser" Added tag(s) pending. Added tag(s) pending. Added tag(s) pending. Added tag(s) pending. Added tag(s) pending. > tags 686142 + pending Bug #686142 [aptitude] aptitude: categorical browser does not display arch on foreign-arch package names Added tag(s) pending. > tags 686646 + pending Bug #686646 [aptitude] aptitude: Invisible hierachy or improperly ordered package sets in categorical browser Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 686124: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686124 686142: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686142 686646: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686646 702529: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702529 704965: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704965 717317: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717317 782872: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782872 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Sun Jul 26 14:51:07 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Sun, 26 Jul 2015 14:51:07 +0000 Subject: [Aptitude-devel] Processed: tagging 777778 References: <1437922050-283-bts-abe@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > tags 777778 + pending Bug #777778 [src:aptitude] aptitude: ftbfs with GCC-5 Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 777778: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777778 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From owner at bugs.debian.org Sun Jul 26 15:03:11 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Sun, 26 Jul 2015 15:03:11 +0000 Subject: [Aptitude-devel] Processed: tagging 736934 References: <1437922806-2036-bts-abe@debian.org> Message-ID: Processing commands for control at bugs.debian.org: > tags 736934 + pending Bug #736934 [aptitude] aptitude: Minesweeper: Saving/Loading keybindings documented wrongly Added tag(s) pending. > thanks Stopping processing here. Please contact me if you need assistance. -- 736934: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736934 Debian Bug Tracking System Contact owner at bugs.debian.org with problems From abe at debian.org Sun Jul 26 15:07:37 2015 From: abe at debian.org (Axel Beckert) Date: Sun, 26 Jul 2015 17:07:37 +0200 Subject: [Aptitude-devel] Bug#298734: [PATCH] Add by-site group policy In-Reply-To: References: Message-ID: <20150726150737.GA24640@sym.noone.org> Hi, Daniel Hartwig wrote in 2011: > tags 298734 + patch > block 603269 by 298734 > thanks > > Attached patch contains a group policy named `site' for grouping > packages according to their origin site (server). [...] > - packages available from multiple sites appear *once* under each Sounds good to me. > apt_preferences refers to this data using the keyword `origin', > however, I have decided to use `site' for the group policy as I intend > to now work on an equivilent search term and `?origin' is already in > use. > > Using the keyword `origin' for this data seems more descriptive to me. > I think that the group policy could be `origin' and the search term > `?origin-site', any opinions on this? Why not just "?site"? > I consider the patch to be fairly complete, however opinions and > naming suggestions are welcome. Looks fine to me. I though would prefer the shorter search term "?site". Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE From debian at helgefjell.de Sun Jul 26 17:14:58 2015 From: debian at helgefjell.de (Helge Kreutzmann) Date: Sun, 26 Jul 2015 19:14:58 +0200 Subject: [Aptitude-devel] Bug#762340: Bug#762340: Bug#762340: aptitude: [INTL:de] partially updated German man page translation In-Reply-To: <20150726141043.GD2433@sym.noone.org> References: <20140921111050.GA27249@Debian-50-lenny-64-minimal> <20150726134426.GC2433@sym.noone.org> <20150726141043.GD2433@sym.noone.org> Message-ID: <20150726171458.GA26895@Debian-50-lenny-64-minimal> Hello Axel, On Sun, Jul 26, 2015 at 04:10:43PM +0200, Axel Beckert wrote: > Control: tag -1 - moreinfo + pending > Hi Helge and Mario, > > Axel Beckert wrote: > > Helge Kreutzmann wrote: > > > Please find the partial updated German man page translation > > > for aptitude at > > > http://www.helgefjell.de/data/aptitude_0.6.10-1_de.po.bz2 > > > > This looks rather like a complete rewrite than something partial: Partial because Mario "only" worked on completing parts of the translation. Rather than let it bit rot we decided to hand it in so that a future translator can pick it off where Mario left. (Similar to the situation before Mario). > My fault: I diffed it against the program translation instead of the > man page translation. Of course that gives a huge diff. ;-) > > Sorry for the noise. Will apply it in the git repository soon. That is great. Thanks. Greetings Helge -- Dr. Helge Kreutzmann debian at helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 828 bytes Desc: Digital signature URL: From ban.artem.v at gmail.com Wed Jul 29 20:13:23 2015 From: ban.artem.v at gmail.com (artem_banschikov) Date: Wed, 29 Jul 2015 23:13:23 +0300 Subject: [Aptitude-devel] Bug#793307: Bug#793307: Bug#793307: aptitude: Add a confirmation for changing 'automatic' flag In-Reply-To: <20150724185409.GA3068@reva.itsari.org> References: <20150722170431.28068.13611.reportbug@debian> <20150722172407.GM2433@sym.noone.org> <20150722190130.GA7205@localhost> <20150724185409.GA3068@reva.itsari.org> Message-ID: <20150729201323.GA14783@localhost> On Fri, 24 Jul 2015 19:54:09 +0100 "Manuel A. Fernandez Montecelo" wrote: > 2015-07-22 20:01 artem_banschikov: > >On Wed, 22 Jul 2015 19:24:07 +0200 Axel Beckert wrote: > >Hi, > >> If we do so, we should > >> > >> a) make it optional (on by default is fine for me), > >Completely agree. > >> b) only ask for confirmation if it would catch more than one package > >> (i.e. for whole branches) > >I thought about three options: ask for one package, ask for multiple > >packages, not ask at all. There is file deletion dialog in Ranger > >file-manager made in this way. > >> c) only for "m", not for "M" (as the subject may suggest) > >Confirmation for "M" may be added for consistency. > > > >Anyway I'll be glad if you make exactly as you said as it will entirely solve > >my problem. > > > >Best regards, Artyom. > > > What about Undo (Control-U), as Axel suggested in the previous e-mail? > > IMO it is a more general solution, and already implemented, so it should be > favoured rather than adding these new options (unless it does not work). > > > Cheers. > -- > Manuel A. Fernandez Montecelo > > From ban.artem.v at gmail.com Wed Jul 29 20:36:41 2015 From: ban.artem.v at gmail.com (=?UTF-8?Q?=D0=90=D1=80=D1=82=D1=91=D0=BC_?= =?UTF-8?Q?=D0=91=D0=B0=D0=BD=D1=89=D0=B8=D0=BA=D0=BE=D0=B2?=) Date: Wed, 29 Jul 2015 23:36:41 +0300 Subject: [Aptitude-devel] Bug#793307: Bug#793307: Bug#793307: aptitude: Add a confirmation for changing 'automatic' flag Message-ID: On Fri, 24 Jul 2015 19:54:09 +0100 "Manuel A. Fernandez Montecelo" < manuel.montezelo at gmail.com> wrote: > 2015-07-22 20:01 artem_banschikov: > >On Wed, 22 Jul 2015 19:24:07 +0200 Axel Beckert wrote: > >Hi, > >> If we do so, we should > >> > >> a) make it optional (on by default is fine for me), > >Completely agree. > >> b) only ask for confirmation if it would catch more than one package > >> (i.e. for whole branches) > >I thought about three options: ask for one package, ask for multiple > >packages, not ask at all. There is file deletion dialog in Ranger > >file-manager made in this way. > >> c) only for "m", not for "M" (as the subject may suggest) > >Confirmation for "M" may be added for consistency. > > > >Anyway I'll be glad if you make exactly as you said as it will entirely solve > >my problem. > > > >Best regards, Artyom. > > > What about Undo (Control-U), as Axel suggested in the previous e-mail? > > IMO it is a more general solution, and already implemented, so it should be > favoured rather than adding these new options (unless it does not work). 1) It may be not obvious for unexperienced user. 2) It may be not noticed quickly enough. But optional warning in status screen may be added for using "m" on multiple packages. Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tracy at listshunter.com Fri Jul 31 18:00:12 2015 From: tracy at listshunter.com (tracy at listshunter.com) Date: Fri, 31 Jul 2015 23:30:12 +0530 Subject: [Aptitude-devel] Technology User Contacts Message-ID: <118901d0cbba$c07c1fa0$41745ee0$@com> Hello, Hope today finds you well. I'm Tracy here. I was going through your website and Understand about your product, would you be interested in reaching out to Technology and Software User Contacts, Which will enable you to reach your product and brand to the right audience List Contains: Application/technology users, Company Name, Web Address, Contact Name, Verified Email, Job Title, Application Type, Complete Mailing Address, Phone Number, FAX Number, Total Employees, SIC Code, and Industry details. We do not provide Email address such as: Info, Marketing, Support, Services, Contact etc. Every single email address will be a professional/Business email address. If this interests you or want to get more details. Let me know your exact target audience and geography, I'll get back to you with information on the counts, pricing etc. Target Industry : Target Job Title : Target Geography : Look forward for your response. Regards Tracy Johnson | Online Marketing Manager www.elisthunter.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From owner at bugs.debian.org Fri Jul 31 21:12:05 2015 From: owner at bugs.debian.org (Debian Bug Tracking System) Date: Fri, 31 Jul 2015 21:12:05 +0000 Subject: [Aptitude-devel] Processed: Merging duplicate bugs References: <55BBE3DB.1050501@norsjovallen.se> Message-ID: Processing commands for control at bugs.debian.org: > merge 792911 792912 Bug #792911 [aptitude] Updated Swedish translation for aptitude Bug #792912 [aptitude] Updated Swedish translation for aptitude Merged 792911 792912 > thanks Stopping processing here. Please contact me if you need assistance. -- 792911: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792911 792912: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792912 Debian Bug Tracking System Contact owner at bugs.debian.org with problems