Bug#757440: aptitude: wants to remove some package though dependencies are fine
Control: tags -1 + confirmed Control: severity -1 important Control: owner -1 ! On 8 August 2014 16:23, Vincent Lefevre vinc...@vinc17.net wrote: Package: aptitude Version: 0.6.11-1 Severity: normal I type 'U', and get for linux-libc-dev:i386: Some dependencies of linux-libc-dev:i386 are not satisfied: * linux-libc-dev:i386 breaks linux-libc-dev (!= 3.14.13-2) The following packages conflict with linux-libc-dev:i386: * linux-libc-dev breaks linux-libc-dev:i386 (!= 3.14.15-1) Hello Thanks for the report. This is apparently due to aptitude's incomplete multiarch support. The program should be upgrading groups like this in lockstep, before the problem resolver gets involved. Will get that fixed for Jessie. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757028: aptitude: aptitude does not install new essential packages automatically
On 5 August 2014 01:08, Axel Beckert a...@debian.org wrote: Hi, Stanley Schade wrote: I am running an up-to-date installation of jessie and recently found that aptitude does not install the new init package automatically, though it is marked as essential. ... which is what I would expect. AFAIK there's no obligation to install essential packages if they pop up newly -- unless another package depends on it.. APT and Aptitude just both warn the user if you try to remove them. Some time last year I tested apt-get vs aptitude on this. IIRC apt-get dist-upgrade would install new essential packages, and I believe that aptitude should as well (but does not yet). Ignoring the specific case here of init systems, any system without all essential packages installed should be considered broken, in some sense. From debian-policy: Essential is defined as the minimal set of functionality that must be available and usable on the system at all times … I think that apt-get is doing the right thing here, and aptitude should be updated (a minor change) to also do this. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756510: [Aptitude-devel] Bug#756510: Couldn't find any package whose name or description matched ... printed twice
Control: forcemerge 498239 -1 On 30 July 2014 21:19, 積丹尼 Dan Jacobson jida...@jidanni.org wrote: Package: aptitude Version: 0.6.11-1 Severity: minor Doubled error line: # aptitude install BLAAA Couldn't find any package whose name or description matched BLAAA Couldn't find any package whose name or description matched BLAAA No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 10 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. Do you want to continue? [Y/n/?] Hello Dan Thanks for the report. We will get this fixed for Jessie. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755677: [Aptitude-devel] Bug#755677: aptitude: Recognizes Debian Backports packages as official for downloading changelogs on the CLI, but not in the TUI
Control: tags -1 + confirmed Control: owner -1 ! On 22 July 2014 18:21, Axel Beckert a...@debian.org wrote: Package: aptitude Version: 0.6.11-1 Control: found -1 0.6.8.2-1 Hi, I actually ran into the following on Debian Wheezy, but then also was able to reproduce this in Sid: If I try to download and view the changelog of a package from an official Debian Backports repository (e.g. http://metadata.ftp-master.debian.org/changelogs/main/r/redmine/wheezy-backports_changelog, the repository's release identification is release v=,o=Debian Backports,a=wheezy-backports,n=wheezy-backports,l=Debian Backports,c=main) in the NCurses TUI by pressing Shift-C, aptitude currently claims, it's not an official package: You can only view changelogs of official Debian packages. And yes, there is a related fix in Sid (https://bugs.debian.org/714619), but only in one place out of two as it seems: only for the command line interface. And indeed, if I do the same from the command line on Sid, it works as expected, at least in Sid: aptitude changelog redmine=2.5.1-2\~bpo70+2 works fine. There seems to be some kind of code duplication. The according code locations are: Yes. One of the major issues attempting to be addressed on the wip (real soon now). The duplicated code was already removed on the 0.6.9 branch IIRC. Thank for spotting. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757028: aptitude: aptitude does not install new essential packages automatically
Control: tags -1 + confirmed Control: owner -1 ! On 5 August 2014 09:02, Stanley Schade nood0...@web.de wrote: Hi again, Am Montag, 4. August 2014, 19:08:35 schrieb Axel Beckert: Hi, Stanley Schade wrote: [...] aptitude does not install the new init package automatically, though it is marked as essential. ... which is what I would expect. AFAIK there's no obligation to install essential packages if they pop up newly -- unless another package depends on it.. I could not find such an obligation either. debian-policy section 3.5 (Dependencies) implies the obligation: Packages are not required to declare any dependencies they have on other packages which are marked Essential (see below), and should not do so unless they depend on a particular version of that package. See also [1]. #555896 is related, though specifically about new essential packages in a non-default release. Regards [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=216768#46 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751117: aptitude segfaults when trying to acquire root powers via sudo
Control: tags -1 + moreinfo On 10 June 2014 21:32, Jose Antonio Ortega Ruiz j...@gnu.org wrote: Package: aptitude Version: 0.6.11-1 Severity: important I've got a local configuration file in ~/.aptitude/config with the contents: aptitude::Keep-Unused-Pattern ; aptitude::Delete-Unused-Pattern ; aptitude::Suppress-Read-Only-Warning true; aptitude::Get-Root-Command sudo; and my user belongs to the sudoers group, and sudo is configured so that that user does not need to type her password when executing sudo commands. This setup has been working for years, and broke a few days ago. When i do a U in aptitude to update the package list, i get the usual dialog asking me if i'd like to change the root account. When i accept by hitting return on the Become root button, aptitude immediately segfaults. Hello I can not reproduce this on i386 using same versions of dependencies as listed in your report. Please install the packages aptitude-dbg and libcwidget3-dbg, reproduce, and provide a backtrace. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750160: RFS: aptitude/0.6.11-1 [RC]
On 10 June 2014 04:58, Axel Beckert a...@debian.org wrote: One remark though about something I didn't notice with the previous version: aptitude doesn't seem to cleanly build twice in a row. After a non-chrooted build with debuild and debclean afterwards, pdebuild for the chrooted build initially failed as follows: […] aptitude-0.6.11/doc/ru/aptitude.xml aptitude-0.6.11/doc/ru/manpage.xml dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/aptitude_0.6.11-1.diff.7en63G dpkg-source: info: you can integrate the local changes with dpkg-source --commit dpkg-buildpackage: error: dpkg-source -b aptitude-0.6.11 gave error exit status 2 The mentioned diff shows that these files are new files. So they should be cleaned up in the clean target. Yes, this issue has been around for some time. Maybe adding doc/??/aptitude.xml doc/??/manpage.xml to debian/clean helps -- unless the source files are matched by this, too. The source are doc/en/aptitude.xml. Anyway, this is simple enough to fix. Thanks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750159: aptitude: Manage real and effective user ID for security
Package: aptitude Version: 0.6.10-1 Severity: important Tags: confirmed Aptitude is often invoked using su or sudo for privileges to manage packages. These are not required when calling some other utilities, such as the pager (as in 'aptitude changelog') or reportbug, or creating and accessing user (rather than root) files. Common practice to drop these privileges is to swap the real and effective user ID. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#463510: aptitude: Remove option to run reportbug
On 2 June 2014 15:17, Matijs van Zuijlen mat...@matijs.net wrote: A suggestion is made in the -done mail that would indeed alleviate the problem somewhat (swapping user ids), but I see no follow-up bug to arrange for this to happen. Are you expecting me to file any follow-up bugs? No. See http://bugs.debian.org/750159 if it pleases you. Kind regards, Matijs -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750160: RFS: aptitude/0.6.11-1 [RC]
Package: sponsorship-requests Severity: important X-Debbugs-CC: aptitude-de...@lists.alioth.debian.org Dear mentors I am looking for a sponsor for my package aptitude * Package name: aptitude Version : 0.6.11-1 Upstream Author : Aptitude Devel aptitude-de...@lists.alioth.debian.org * URL : http://aptitude.alioth.debian.org/ * License : GPL-2+ Section : admin It builds those binary packages: aptitude - terminal-based package manager aptitude-common - architecture independent files for the aptitude package manager aptitude-dbg - Debug symbols for the aptitude package manager aptitude-doc-cs - Czech manual for aptitude, a terminal-based package manager aptitude-doc-en - English manual for aptitude, a terminal-based package manager aptitude-doc-es - Spanish manual for aptitude, a terminal-based package manager aptitude-doc-fi - Finnish manual for aptitude, a terminal-based package manager aptitude-doc-fr - French manual for aptitude, a terminal-based package manager aptitude-doc-it - Italian manual for aptitude, a terminal-based package manager aptitude-doc-ja - Japanese manual for aptitude, a terminal-based package manager aptitude-doc-ru - Russian manual for aptitude, a terminal-based package manager To access further information about this package, please visit the following URL: http://mentors.debian.net/package/aptitude Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/aptitude/aptitude_0.6.11-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * Includes fix for FTBFS with gcc-4.9. * New upstream release: - Load package tags from APT if debtags database is not available. (Closes: #501732) - Remove -Werror from default compiler flags. (Closes: #746824) - No longer use libept. (Closes: #504153, #677551) * Translation updates: - Italian (Closes: #741875) - Portuguese (Closes: #748141) * Correct typo in description of aptitude-common. (Closes: #746960) * Remove non-ASCII punctuation from changelog. (Closes: #745680) * Drop apt-xapian-index to Suggests. (and misc. upstream changes, as noted in NEWS) Regards Daniel Hartwig -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750160: RFS: aptitude/0.6.11-1 [RC]
On 2 June 2014 19:29, Axel Beckert a...@debian.org wrote: There are at least the following packaging changes which is not mentioned in the changelog entry, but IMHO should: * There's a new build-dependency on libxapian-dev. This seems due to upstream changes. Nevertheless this should be mentioned in the changelog. Will add: * debian/control: New Build-Depends on libxapian-dev, replacing libept-dev. * Multiple added Multi-Arch: headers. Those were added in 0.6.10-2 (experimental), and covered by this changelog entry: * Make aptitude installable on non-native architectures Thanks to Rogier for noting this (Closes: #697278) or should I add a new note, explicitly mentioning the headers in debian/control? Since you don't seem to have pushed the packaging changes yet, I suspect making these changes without an ugly looking commit history is still possible. Right. Please advise on the previous question, and I will upload a new candidate. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750160: RFS: aptitude/0.6.11-1 [RC]
On 2 June 2014 19:48, Axel Beckert a...@debian.org wrote: Hi Daniel, Daniel Hartwig wrote: Will add: * debian/control: New Build-Depends on libxapian-dev, replacing libept-dev. Thanks. Uploaded (mentors.d.n). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748141: aptitude: [INTL:pt] Updated Portuguese translation for program
Control: tags -1 + pending On 15 May 2014 02:48, Miguel Figueiredo el...@debianpt.org wrote: Package: aptitude Version: n/a Tags: l10n, patch Severity: wishlist Updated Portuguese translation for aptitude's program messages. Translator: Miguel Figueiredo el...@debianpt.org Feel free to use it. Applied, thanks. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671780: aptitude: Please move ~/.aptitude/cache to $XDG_CACHE_HOME (default ~/.cache)
After initially merging the patch, it has been reverted due to complications with file ownership and requirements of the XDG basedir specification. Briefly, the basedir specification states that non-existent directories are to be created and with initial mode 0700. The path used can come from $HOME, $XDG_CACHE_HOME, or a default. Not an issue for programs run under the effective id of the logged in user. But that is not how aptitude is always run. Different means of gaining root privileges do filter any of these environment variables, and it is not clear whether the user has intentionally or not set any of them, nor which user is supposed to own the cache directories once created. Example: $ export XDG_CACHE_HOME=/usercache/foo # perhaps set on login ... $ su ... $ aptitude Counter example: $ su ... $ export XDG_CACHE_HOME=/rootcache $ aptitude su _may_ have cleared XDG_CACHE_HOME or may not have, depending on system configuration. It is not obvious to aptitude whether the user is expecting this to have been passed to aptitude, nor which user should have ownership of the stated path if aptitude has to create it. Other scenarios introduce similar ambiguity. The change is reverted until a simple mechanism can be decided upon, perhaps similar to what happens with ~/.aptitude/config (only create if the path is within the real users HOME, but even this has some problems). Regards Daniel Hartwig -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748524: aptitude dies with an error message but exits with an exit code of 0 (zero)
Control: forcemerge 675833 -1 On 18 May 2014 08:17, Daniel Leidert daniel.leid...@wgdd.de wrote: Package: aptitude Version: 0.6.10-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was trying to hack something together and found, that e.g. aptitude changelog bluefish/squeeze-backports reports an error, because there is no changelog of bluefish here. But why does aptitude then exit with an exit code of zero (0)? It shouldn't do that. It should throw an error, which then can be catched. Sure. This will be resolved for Jessie. Regards, Daniel - -- Package-specific info: Terminal: xterm $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.10 compiled at Feb 20 2014 17:26:22 Compiler: g++ 4.8.2 Compiled against: apt version 4.12.0 NCurses version 5.9 libsigc++ version: 2.2.11 Ept support enabled. Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20140118 cwidget version: 0.5.17 Apt version: 4.12.0 aptitude linkage: linux-vdso.so.1 (0x7fffa55a8000) libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x7fd18dc98000) libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7fd18da63000) libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7fd18d838000) libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7fd18d633000) libcwidget.so.3 = /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7fd18d32c000) libept.so.1.aptpkg4.12 = /usr/lib/x86_64-linux-gnu/libept.so.1.aptpkg4.12 (0x7fd18d0cf000) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7fd18ccd1000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7fd18cab9000) libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fd18c7fc000) libboost_iostreams.so.1.54.0 = /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.54.0 (0x7fd18c5e2000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd18c3c5000) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fd18c0b9000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fd18bdb6000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fd18bba) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fd18b7f5000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7fd18b5f2000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fd18b3ee000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7fd18b1dd000) liblzma.so.5 = /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fd18afba000) libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fd18adb4000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7fd18abac000) /lib64/ld-linux-x86-64.so.2 (0x7fd18e62d000) - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (850, 'unstable'), (700, 'testing'), (560, 'stable'), (500, 'oldstable'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages aptitude depends on: ii aptitude-common 0.6.10-1 ii libapt-pkg4.121.0.3 ii libboost-iostreams1.54.0 1.54.0-5 ii libc6 2.18-6 ii libcwidget3 0.5.17-1 ii libept1.4.12 1.0.12 ii libgcc1 1:4.9.0-3 ii libncursesw5 5.9+20140118-1 ii libsigc++-2.0-0c2a2.2.11-3 ii libsqlite3-0 3.8.4.3-3 ii libstdc++64.9.0-3 ii libtinfo5 5.9+20140118-1 ii libxapian22 1.2.17-1 ii zlib1g1:1.2.8.dfsg-1 Versions of packages aptitude recommends: pn apt-xapian-indexnone pn aptitude-doc-en | aptitude-doc none ii libparse-debianchangelog-perl 1.2.0-1 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: pn debtags none ii tasksel 3.20 - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlN3/B4ACgkQm0bx+wiPa4wIsQCgxgyrt2iRpeuf5p0n9Hoh/VKf Q1AAoNAuqvV12C8AB0Kqtuw7CZS9ktXy =6yUv -END PGP SIGNATURE- ___ Aptitude-devel mailing list aptitude-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747442: [Aptitude-devel] Bug#747442: aptitude: progs run by aptitude (apt-listbugs, how-can-I-help block apt when they crash
On 9 May 2014 02:08, Stephen McGregor x...@stephen-mcgregor.com wrote: Package: aptitude Version: 0.6.10 Severity: grave Justification: renders package unusable Dear Maintainer, the specific situation: - [ already filed as #747406 against ruby] -a ruby corruption is crashing both apt-listbugs AND how-can-I-help - thus aptitude returns a failure and does NOT install the desired packages - the apt system is now completely broken: these packages can not be removed and no others can be installed. - apt-get is also affected and no longer works. the general case --- important - any program run by aptitude (such as apt-listbugs or how-can-I-help) that crashes will break the apt system. - this is a critical bug: any type of failure in sub-programs should have NO effect on aptitude. Not a bug, this is the intended and documented behaviour [1]. These hook programs are permitted to prevent an install action from proceeding by returning failure. In this case, the hook programs themselves fail to run, but it can not be assumed that it is the administrators wishes to proceed anyway. For example if the purpose of having apt-listbugs installed is to prevent buggy packages from being installed, that purpose _would_ be defeated. Do you trust to install packages without that program screening them first? If so, you can inform apt of this decision by removing the bothersome lines from apt.conf. [1] From apt.conf(5): Pre-Install-Pkgs This is a list of shell commands to run before invoking dpkg(1). Like options this must be specified in list notation. The commands are invoked in order using /bin/sh; *should any fail APT will abort*. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742708: [Aptitude-devel] Bug#742708: aptitude confused about to-be-installed version
Control: forcemerge 740750 -1 On 26 March 2014 22:37, Ralf Jung p...@ralfj.de wrote: Package: aptitude Version: 0.6.10-1 Severity: normal Dear Maintainer, Hello when there are several versions of a package available, aptitude seems to be confused when I ask it to install a specific version. Steps to reproduce: [snipped] This is a recent issue with apt that is not simple to workaround in aptitude. A patch is already proposed for apt to resolve that. Thank you -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740750: MarkInstall resets candidate, breaks interactive problem resolution
(Discussion started here: https://lists.debian.org/deity/2014/03/msg00015.html) On 12 March 2014 01:21, David Kalnischkies da...@kalnischkies.de wrote: On Tue, Mar 11, 2014 at 12:11:57PM +0100, David Kalnischkies wrote: On Thu, Mar 06, 2014 at 10:24:37AM +0800, Daniel Hartwig wrote: commit 446551c8ffd2c9cb9dcd707c94590e73009f7dd9 […] I need to investigate also whether a previous change to call MarkDelete under the same situation also impacts this use case. No idea really, but I would presume that if this is called for a leaf package it is just another unsatisfied dependency to be resolved. If on the other hand it is a request coming from the user it is protected by FromUser (assuming MarkInstall is called this way). I wonder a bit how this all works at all though with this loopbreaking (the MarkDelete is just the topping) as it was introduced in df77d8a5 (May 2011) by - surprise surprise - me. For interactive use it would probably be better to continue and let the user fix the breakage later. I guess we should move this check out into a IsInstallOk submethod so that you can at least disable this check (and we can stop at the beginning rather than somewhere in the middle). Will see if I can make this work. Attached are two changes which should implement it this way and I guess are better suited to fix the problem as they remove this specific loopbreaking from MarkInstall and moving it to IsInstallOk which a frontend can override and hence disable this and/or other checks. I can see in the aptitude code that you are overriding this method already, so in case we would go with this everything should magically work for aptitude again as it used to be back in the old days, right? Or is there something I am missing? Correct. It is working as previously now, thank you. I am reassigning the regression report (#740750) for your closing. Looking with codesearch suggests that no other frontend is playing with IsInstallOk, so the behavior changes only in so far that breakage (introduced in May 2011, so it might very well be expected behavior now) is now more obvious as the loop is not even started instead of broken somewhere down the line, which sounds like a good thing and an easy way out of this problem is present as well if need be. I was surprised that I could not reproduce this in synaptic, though IIRC they use pinning (force version in their lingo) to change the candidate. Thank you for your quick response on this issue. Regards Daniel Hartwig -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741875: aptitude: [INTL-it] Updated Italian translation of aptitude po4a docs
Control: tags -1 + pending On 17 March 2014 03:34, Beatrice Torracca beatri...@libero.it wrote: Package: aptitude Version: 0.6.10-1 Severity: wishlist Tags: l10n patch Hello! This is the updated .po file with the Italian translation of aptitude po4a docs (aptitude-doc-it and man pages). I did (try to) subit a similar bug several hours ago, but I think I made some mistake. I do apologize in advance if this bug gets duplicated. Please include the updated translation in your next upload. Thank you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740750: aptitude: Regression: Cannot mark specific version for installation unless dependencies are satisfied
On 5 March 2014 01:25, Andreas Kloeckner inf...@tiker.net wrote: Package: aptitude Version: 0.6.10-2 Severity: normal Dear Maintainer, previously, I was able to do the following in aptitude: 1) Hit [Enter] on a package I wanted. 2) Scroll down, pick the version I want, hit [+]. 3) Sort out the broken dependencies of that version, if needed. 4) Be happy. Now, at step 2), aptitude will only mark the default version of the package (not the chosen one) for installation if that version will have broken dependencies after installation. Applies only to packages with another version currently installed. Related to the fix for an apt issue [1], also possibly an earlier change to the same function. I will investigate further and query apt developers about this. Regards [1] http://bugs.debian.org/735967 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#415449: aptitude: improve package list browsing
On 3 March 2014 00:53, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Control: tags -1 + moreinfo Opinions about this? I think that it would be nice and I wished for something similar many times (default binding, not something that I would add and would have to carry from system to system). However I am not sure if the proposed key is the best approach. For example, pressing ] in any element of a tree could close that branch, that's what feels more natural for me. The original poster seems unaware of the ^ and ] bindings. And if arrow_left closes the branch from any sub-element, at least arrow_right should open the branch (maybe there are other simetries as well). These keys are often used to traverse up and down. However, rather than Left always closing the branch, it should move up a level (like ^) or close the branch depending on the current position. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738350: [Aptitude-devel] Bug#738350: Bug#738350: aptitude: Reconfiguring missing in Package submenu
On 3 March 2014 03:12, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: 2014-02-09 16:41 GMT+00:00 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com: Another option would be to have them in after a separator, like Information, Cycle package information and Changelog. In fact, Changelog is a immediate action much like Reportbug, isn't it? Information and Cycle are also immediate. BTW, I think that perhaps Reconfigure should not be so immediate, and behave like Reinstall instead. Does apt support this? What to do about this one? What are you suggesting to do? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562595: [Aptitude-devel] Bug#562595: aptitude: downloads some packages twice
On 3 March 2014 03:22, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Control: tags -1 + moreinfo Hi, Is this bug still happening? I haven't experience it, at least recently, in several systems that I administer. I suspect this is rather to do with duplicate lines in the progress output as is seen with list updates. At least list update duplicates are due to the apt infrastructure sending the file through decompression stages, which is considered a separate fetch. I don't have much idea about why this can be happening, if anybody can provide any info it would be helpful. Reading the apt-pkg/acquire.cc and apt-pkg/contrib/progress.cc is a start. If you are interested in resolving such problems you must understand the implementation and workings of these classes. Questions you can look at: * does the list update duplicates issues still occur? * why does it occur (for your information only, and to help in further investigating) * does a similar process happen with package fetching? * is that the issue here? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562595: [Aptitude-devel] Bug#562595: aptitude: downloads some packages twice
On 3 March 2014 08:29, Daniel Hartwig mand...@gmail.com wrote: On 3 March 2014 03:22, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Control: tags -1 + moreinfo Hi, Is this bug still happening? I haven't experience it, at least recently, in several systems that I administer. Which sources are those systems using (for your info.), do they match the ones with duplicate lines in the bug report, and do those servers issue http redirects? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738350: [Aptitude-devel] Bug#738350: Bug#738350: aptitude: Reconfiguring missing in Package submenu
On 3 March 2014 08:21, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: 2014-03-03 0:12 GMT+00:00 Daniel Hartwig mand...@gmail.com: On 3 March 2014 03:12, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: 2014-02-09 16:41 GMT+00:00 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com: Another option would be to have them in after a separator, like Information, Cycle package information and Changelog. In fact, Changelog is a immediate action much like Reportbug, isn't it? Information and Cycle are also immediate. BTW, I think that perhaps Reconfigure should not be so immediate, and behave like Reinstall instead. Does apt support this? It calls dpkg-reconfigure directly. For me it would make more sense if we can hold the action until hitting g, as the rest of the actions do, including Reinstall. So the answer is: no. What to do about this one? What are you suggesting to do? As I said reportbug (now gone) is an immediate action, so like chagelog. reconfigure, if keeps being immediate, also here (or perhaps with its own separator, since it's somewhat different than the other ones, performing an action on the package rather than simply gathering and showing information). If it holds until pressing g and confirming, like reinstall, I would put it besides reinstall. Seems you have it all figured out. Lets see a patch. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#463510: [Aptitude-devel] Bug#463510: Bug#463510: Bug#412830: aptitude: Remove option to run reportbug
On 3 March 2014 03:12, Manuel A. Fernandez Montecelo
manuel.montez...@gmail.com wrote:
Control: tags 463510 + pending
2014-02-09 15:52 GMT+00:00 Manuel A. Fernandez Montecelo
manuel.montez...@gmail.com:
So I am going to remove reportbug and close that bug report, and then
investigate the other one.
Abitily to run reportbug removed (bug 463510), marking as pending.
http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=51e7dceaf7d04b406deea72a72aed8085b70ca60
What is the relevance of this change to cmdline_prompt.cc:
{
- const int quiet = aptcfg-FindI(Quiet, 0);
-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720074: [Aptitude-devel] Bug#720074: Bug#647474: aptitude: When piping, stdout doesn't include RECOMMENDED but will not be installed
On 3 March 2014 00:38, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Control: tags 647474 + pending Control: owner 647474 ! 2014-02-09 10:43 GMT+00:00 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com: But as I also said, I think that the way in which Daniel Burrows solved this at the time is the wrong way and that should have accepted the (verbose 0) from Ubuntu. I don't understand why he didn't, but I think that that's what we should do. [...] I still would like to solve this for the next release 0.6.8.5, better with the (verbose = 0) than with the patch above. This is an unintrusive change that should not get in the way of wip-cmdline. Fix commited, with the verbose flag: http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=39803644412f7c99093744a2735f9acc495a583f Apparently you never figured out that the reason to show recommends-not-installed without --verbose is to alert the user to the unusual situation of their absence. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#463510: [Aptitude-devel] Bug#463510: Bug#463510: Bug#412830: aptitude: Remove option to run reportbug
On 3 March 2014 08:40, Manuel A. Fernandez Montecelo
manuel.montez...@gmail.com wrote:
2014-03-03 0:38 GMT+00:00 Daniel Hartwig mand...@gmail.com:
On 3 March 2014 03:12, Manuel A. Fernandez Montecelo
manuel.montez...@gmail.com wrote:
Control: tags 463510 + pending
2014-02-09 15:52 GMT+00:00 Manuel A. Fernandez Montecelo
manuel.montez...@gmail.com:
So I am going to remove reportbug and close that bug report, and then
investigate the other one.
Abitily to run reportbug removed (bug 463510), marking as pending.
http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=51e7dceaf7d04b406deea72a72aed8085b70ca60
What is the relevance of this change to cmdline_prompt.cc:
{
- const int quiet = aptcfg-FindI(Quiet, 0);
-
-Werror made it abort compiling (unused variable).
So it is unrelated to the other changes in the commit; fix it separately.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#349414: aptitude: missing format string %-escape for the archive of the installed version
Control: tags -1 = wontfix On 21 February 2014 06:05, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Control: tags -1 + moreinfo Hi, The reason why this is not straightforward, as far as I can tell, is because there's no place where this information is saved. Right. Archives are sources of new packages and updates, and should only be thought of in those terms. It is complex and not that useful to reason in terms of which archive did some installed package come from. There is also no search term for this, and neither should there be. Packages can be installed by several means, including by hand with dpkg, and in the basic information (.deb itself, or Packages files separately) there is no information about where it came from. I think that apt (and aptitude through libapt) extract this information from the content of /var/lib/apt/lists/ , that is, the set of Packages coming from whatever is enabled in your sources.list, mapping backwards the candidate version to the source of the Packages file where the version appears. For packages installed by hand or obsolete (installed through regular repositories/mirrors but not present anymore in the Packages list of the repository), this information is not present anywhere in the system at the moment (again, as far as I can tell). So I think it would not be an easy undertaking in the way in which things work at the moment. Lots of work for a complicated implementation, just to support a reasoning model which is also complicated and not that useful. Opinions about what to do? Nothing. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671780: aptitude: Please move ~/.aptitude/cache to $XDG_CACHE_HOME (default ~/.cache)
Control: tags -1 + pending On 10 February 2014 06:43, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Hi, I created the attached patch, similar to Josh's but moving the cache if exists. I am fine with integrating Josh's patch as well. I will merge Josh's patch after some testing this weekend. The name XDG_CACHE_DIR/aptitude-download-cache is not great. In the future we may want another file in there, such as binary cache of aptitude pkgstates. Changing the name to aptitude/metadata, as that is what this particular file is used for (changelogs now, perhaps copyright file in the future). The reason for this new stab with the modified patch is because I think that somehow it's important to remove the litter and not leave ~/.aptitude/cache behind. Lots going on there, too much for a simple cache file. I think that this file is small enough and loosing its contents unimportant enough that perhaps this is not needed (and the paraphernalia to achieve this is a bit ugly, and probably not foolproof). Right. But in that case perhaps we should remove instead of move? Just a cache file, user can clean it up as they desire. Anyway, I think that it would be nice to fix this. Thanks Josh for bringing this to our attention and providing the patch. Yes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740009: aptitude: auto-installed package, depended on by non-installed virtual package provider, not removed
On 25 February 2014 05:43, Zack Weinberg za...@panix.com wrote: Package: aptitude Version: 0.6.10-1 Severity: normal On a (deliberately minimal) system with bsd-mailx, nullmailer, and libpcre3 installed, but nothing that actually depends on libpcre3 installed, and libpcre3 set to auto-installed, libpcre3 will not be autoremoved, How are you attempting to autoremove the package? Aptitude performs this task as the opportunity presents itself, though there are some known issues. Usually running aptitude install without further arguments is sufficient. because: # aptitude why libpcre3 i bsd-mailx Depends default-mta | mail-transport-agent p exim4-daemon-light Provides mail-transport-agent p exim4-daemon-light Depends libpcre3 (= 8.10) It looks as if the dependency solver is not paying attention to which concrete package is satisfying bsd-mailx's dependency on mail-transport-agent on this system. The output from why is not related to the dependency solver or autoremoval of packages. It simply finds the most relevant reason it can (refer to man page for details) to install or keep installed the specified package, and this may or may not involves packages that are actually installed. In your situation, there is no fully installed dependency chain and the reason shown by this command is not keeping the package from being removed. A manual 'aptitude purge libpcre3' went through without complaint. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739854: libapt-pkg-dev: get list of changelog URIs
Package: libapt-pkg-dev Version: 0.9.15.1 Severity: minor Noted on another bug [1] and no doubt observed by anyone who has read the source of more than one frontend, libapt should contain a function to generate a list of possible changelog URIs for a package. Currently apt-get, aptitude, synaptic, and maybe others all duplicate this inconsistently. Suggest at least the obvious, minimal interface: // return a list of possible changelog URIs to be tried in order std::liststd::string GetChangelogURIs(pkgCache::VerIterator) using appropriate parts of apt-get.cc as that supports the additional check for changelogs being stored alongside package files under pool/ (although I have no idea whether any derivative is using that). This will also provide a central location to update in response to issues such as the recent change to metadata.ftp-master.d.o and https usage. [1] http://bugs.debian.org/738785#35 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738785: Bug#739854: libapt-pkg-dev: get list of changelog URIs
user debian...@lists.debian.org usertag 739854 + gift thanks Nice to have, but not a serious blocker. Contact de...@lists.debian.org or myself if the previous mail did not contain enough information to implement. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738785: Bug#739854: libapt-pkg-dev: get list of changelog URIs
On 23 February 2014 18:42, Daniel Hartwig mand...@gmail.com wrote: user debian...@lists.debian.org usertag 739854 + gift thanks Nice to have, but not a serious blocker. Contact de...@lists.debian.org or myself if the previous mail did not contain enough information to implement. This mail should have gone to #739854. The control header is ok. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739854: libapt-pkg-dev: get list of changelog URIs
Nice to have, but not a serious blocker. Contact de...@lists.debian.org or myself if the previous mail did not contain enough information to implement. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739934: control files for sections and descriptions
Package: ftp.debian.org Severity: wishlist Dear maintainer Currently there are at least several areas where (localized) section descriptions are duplicated [1,2,3]. There are problems with this: - packages.d.o misses metadata, and aptitude did also until recently; - wrong or misleading description of sections [4]. Suggest to have new control files either on the main archive or metadata.f-m.d.o, with contents like: Section: admin Description-en: Administration Utilities Utilities to administer system resources, manage user accounts, etc. and taking the initial descriptions perhaps from packages.d.o, which are short and informative. Regards Daniel Hartwig [1] aptitude: using '/section-descriptions' for names and descriptions [2] synaptic: using gettext for names [3] http://packages.debian.org/unstable/ [4] http://bugs.launchpad.net/bugs/8952 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738326: Summary of reassigned bug
On 24 February 2014 13:09, Daniel Dickinson csh...@cshore.neomailbox.net wrote: On 23/02/14 08:00 PM, David Kalnischkies wrote: As far as I know 'aptitude why' displays the first reason it can find and for aptitude suggests are a reason. They aren't automatically installed by it though (but apt/aptitude have an option for it). why more describes why a package isn't autoremoved… Ok, so it's possible that if there are multiple reasons that aptitude why wouldn't show the real one but the first one it found? In that case I will fire up aptitude and see if the info screen that lists why a package got installed The information about why the solver chooses to install a particular package is not available once that installation is complete. This command shows possible reasons why the package should be installed (or for keeping the package installed) based on the current state of things. In some situations, that is equivalent to what you are looking for, but there are times when it is not. In particular, this is not a crystal ball that gazes inside some past instance of the dependency solver. (and IIRC includes every path, not just the first) has what I'm looking for. I guess I kind of assumed that aptitude why would show all reasons. From the manual: By default aptitude outputs only the “most installed, strongest, tightest, shortest” dependency chain. To view all of the possible reasons, use --verbose. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726021: gtest: missing google test shared library (was package libgtest0)
Control: tags -1 + wontfix Yves Fischer wrote: Dear Maintainer, with commit Switch to cmake. Install full source. [1] you removed the package libgtest0. Due to this it is not possible to build google test projects in debian the same way as using redhat linux, where a libgtest/libgtest_main is provided as a shared library. I'm not sure about your reasons, however please consider re-adding this package. Shared library is no longer provided due to upstream recommendation. From README.Debian: Use of precompiled libgtest Not Recommended --- The Google C++ Testing Framework uses conditional compilation for some things. Because of the C++ One Definition Rule, gtest must be compiled with exactly the same flags as your C++ code under test. Because this is hard to manage, upstream no longer recommends using precompiled libraries [1]. [1] http://groups.google.com/group/googletestframework/browse_thread/thread/668eff1cebf5309d You can find examples of using the library under /usr/share/doc/libgtest-dev/examples, and more advice within the quoted README.Debian. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537858: aptitude: comments on i18n
On 8 February 2014 23:29, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Control: tags -1 + pending Thanks for raising this up and the recommendations. Some of these things are obsolete already, but I addressed most of the rest of the things, will be present in the new releases: http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=cea7fd08e76f1be6f6069522e72c2d9fdcb7a825 Several comments: - About no-summary, first-package and so on, both the original messages in english and the translated ones are accepted by the program, so yes, they should be translated Maybe it would be better to not allow translation of keywords at all, it's not allowed in other places --e.g., the why command itself--, so the way in which is done is inconsistent and generates more work for both devels and translators without much benefit for the user, I think. Suggestions/comments about this? I agree. These keywords are part of the programs configuration and should not be accepted in localized form. Those which currently accept localized forms should be deprecated with a suitable warning. - Then, in the error message, since both the english and the translated are accepted, I think that the translators should put both, but I don't know what's the common practice. Makes sense. - I didn't change the ForTranslators thing yet. Is TRANSLATORS used (virtually) everywhere? I believe so. Or different projects use different conversions and it's all right? It is acceptable to use different tokens, though there is no reason for aptitude to remain inconsistent with most other projects here. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#412830: aptitude: Remove option to run reportbug
On 9 February 2014 03:41, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Control: block 412830 by 463510 Control: tags 463510 + moreinfo Hi, I was pondering about this and I am leaning towards accepting the suggestion in #463510 and remove the option to run reportbug altogether, for the reasons explained. Which would be a way to fix #412830 (thus adding the block). The issue with suspect–resume still needs to be solved. It is a clear indication that something is not operating correctly and may only reappear in another form (it has in the past IIRC). Opinions, please? Investigate the cause of the suspect–resume issue first. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#469100: aptitude: please add short version of commands
On 9 February 2014 03:47, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Control: tags -1 + moreinfo I am considering doing this, but even if relatively simple, it would be quite a lot of work documenting it, adding hints in --help, even deciding the best short names and solving clashes, possibly some new messages for translation... All excellent reasons to not do this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647474: aptitude: When piping, stdout doesn't include RECOMMENDED but will not be installed
Control: tags -1 = confirmed Control: owner -1 ! On 9 February 2014 09:05, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: forcemerge 647474 720074 severity 647474 minor owner 647474 ! tags 647474 + patch moreinfo stop Hi, The problem was introduced here in 2007, after a feature request which was previously implemented in Ubuntu: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452202 The basic problem is that showing the recommends in command line mode depends on the option Quiet (which can be set by -q in the command line, or -o Quiet=integer). It turns out that in src/main.cc, this option is set up automatically to a positive number if the output is not a tty (the case of pipes or redirections), even if the user didn't request it through the command line explicitly: int curr_quiet = aptcfg-FindI(quiet, 0); if(seen_quiet) aptcfg-SetNoUser(quiet, quiet); if(quiet == 0 !isatty(1)) aptcfg-SetNoUser(quiet, std::max(curr_quiet, 1)); The code above cannot be fixed, since the progress operations depend on this to work correctly. The issues here are addressed adequately in wip-cmdline. I created the patch, attached. The solution is not very good for my taste, but Daniel Burrows solved it in this way, attaching this message to the Quiet option (which doesn't happen for any other output than progress-like), so this is the quick and dirty fix chaning behaviour minimally and fixing this problem. I say minimally because I don't think that users will rely (and thus, complain if changes behaviour) on something as subtle as setting the option -q explicitly while using pipes/redirection for other reasons, to specifically avoid printing this message. This presumes too much. It is not possible to determine this quiet_because_of_pipe_or_redirection at the point it is introduced, using the test it does. In any case, resolved in wip-cmdline. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570377: aptitude chooses to remove packages instead of upgrading
On 6 February 2014 06:37, Vincent Lefevre vinc...@vinc17.net wrote: On 2014-02-05 00:56:26 +0800, Daniel Hartwig wrote: On 4 February 2014 19:53, Vincent Lefevre vinc...@vinc17.net wrote: On 2014-02-04 10:49:53 +0800, Daniel Hartwig wrote: Again, I am only addressing the proposed patch. There are better options, such as adjusting the default value of Aptitude::ProblemResolver::SolutionCost to account for the number of removals vs installs, or similar, but people should use such settings and provide feedback on the quality of the solutions and their order. It would be better if aptitude could tell the reasons that led to the proposed solution. Do you mean: --\ icedtea6-plugin depends upon openjdk-6-jre (= 6b18-1.8.13-0+squeeze2) - Remove icedtea6-plugin [6b18-1.8.13-0+squeeze2 (now, oldstable)] --\ openjdk-6-jre depends upon libjpeg8 - Remove openjdk-6-jre [6b18-1.8.13-0+squeeze2 (now)] ? Something like that. Perhaps that's what the -v --show-why options do. Use 'o' when examining a solution in the curses interface. On the command line, set Aptitude::CmdLine::Resolver-Show-Steps=1. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570377: aptitude chooses to remove packages instead of upgrading
On 4 February 2014 19:53, Vincent Lefevre vinc...@vinc17.net wrote: On 2014-02-04 10:49:53 +0800, Daniel Hartwig wrote: Again, I am only addressing the proposed patch. There are better options, such as adjusting the default value of Aptitude::ProblemResolver::SolutionCost to account for the number of removals vs installs, or similar, but people should use such settings and provide feedback on the quality of the solutions and their order. It would be better if aptitude could tell the reasons that led to the proposed solution. Do you mean: --\ icedtea6-plugin depends upon openjdk-6-jre (= 6b18-1.8.13-0+squeeze2) - Remove icedtea6-plugin [6b18-1.8.13-0+squeeze2 (now, oldstable)] --\ openjdk-6-jre depends upon libjpeg8 - Remove openjdk-6-jre [6b18-1.8.13-0+squeeze2 (now)] ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720750: aptitude: search returns different numbers of packages depending on sort order
On 3 February 2014 17:46, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: 2014-02-03 Daniel Hartwig mand...@gmail.com: Control: tags -1 - pending On 3 February 2014 02:56, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Control: tags -1 + pending Fix commited, it will be included in the next release if no problem is found with the fix. http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=845a868dc3a7af063c586c2b6ebf5e97daa90491 + +/* mafm: Disabled because it does not respect the 3 way comparison of the + * sort policies, so it removes from the result set any items with the same + * result for the given policy (package_results_eq with successful result, + * which means comparison result zero in policy). + * + * This is usually not noticeable in names (should be unique) or sizes of + * packages (very rare that the size is the same); but it does not work well + * on versions (repeated sometimes) and specially not in priorities, since + * they are only a few of them for all of the packages in the archive. + output.erase(std::unique(output.begin(), output.end(), aptitude::cmdline::package_results_eq(sort_policy)), output.end()); +*/ The search results will now include duplicate packages where there are multiple search patterns matching the same package: $ ./aptitude search '?name(^emacs24)' '?name(^emacs24)' p emacs24 - GNU Emacs editor (with GTK+ user interface p emacs24 - GNU Emacs editor (with GTK+ user interface [...] (That example is obviously contrived, but it is quite common for multiple patterns to have overlapping matches.) Perhaps it has the intended effect then? ;-) Duplicates are not desirable, even if it resolves the issue with missing packages. Anyway, lets just have it reverted and fixed on wip-cmdline (weeks now, see below). It is package_results_eq that must be corrected to properly address this. That function should consider package equality, rather than equality in sort_policy. Please revert. Note that package_results_eq no longer exists after wip-cmdline as search results are collected in a pkgset [libapt] which guarantees to contain only unique packages. Likewise for versions using verset. If you like, feel free to submit a patch for consideration that addresses the issue in package_results_eq. Though, as I mentioned, this will otherwise be resolved by the pending merge of wip-cmdline. When is this going to be fixed more or less? Weeks or months? I expect within two weeks. If it's weeks I can revert the one above and it's probably fine, the bug is minor and has been present since 2010 at least (feabf55d in 2010-04-16). Also related to this is the earlier addition of installsizechange. This is a 2-way comparison, inconsistent with the rest of the sorting module which is 3-way. There is this comment: + // mafm: if returning zero, the comparison stops for + // other packages Clearly this refers to bug #720750. Are there other areas you know about where this is an issue? If there are, we can fix those instead of hacking around them in the sorting module. Sorting module presently relies on 3-way comparisons for functionality such as chaining (as with a sort policy of priority, name). At present, installsizechange will fail to chain correctly and this should be corrected. What do you mean? It's already fixed after I realised that the problem was elsewhere: Right, I did not see that earlier. http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=1583a5b2212ed22319b3a3b6d4d4b047c34cd71c I don't know more areas where this is an issue, no. Nor do I. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570377: [Aptitude-devel] Bug#570377: aptitude chooses to remove packages instead of upgrading
On 2 February 2014 14:56, Chris Tillman toff.till...@gmail.com wrote: Tags: patch I think the root of the problem (removing being preferential to upgrading in Aptitude's worldview) is that the safe-level and remove-level default scores are the same. Hi Thanks for your interest and patch. Unfortunately, it is not an acceptable solution to apply to the _default_ settings. There is nothing fundamentally better or worse about either removals or installs, in some situations you might find this: solution 1: upgrade 20 packages solution 2: remove 1 Whichever is more preferable in these situations is up to the individual user to decide based on whatever particular packages are suggested for upgrade, install, or removal—aptitude can not know how the user values those individual actions. The point of the safety cost _levels_ is to broadly class categories of actions, and in that sense, installing or upgrading to a package in the target release is no better or worse than removing a non-essential package. Tweaking the default settings as per the patch here is not to be done lightly. Considering the architecture of the problem resolver as a whole, it is not an acceptable solution. I recommend any of Axels suggestions for individual users who are bothered by this, especially the comments about guiding the resolver by e.g. rejecting particular actions _before_ asking for the next solution. This is also covered in the users manual, _Resolving Dependencies Interactively_. That is the most effective way of informing the resolver about your desires. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#357542: aptitude: changelog display does not work on recent uploads
On 1 February 2014 23:25, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: 2014-01-31 Daniel Hartwig mand...@gmail.com: On 31 January 2014 20:32, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Control: owner -1 ! This can probably be fixed now by downloading the files from the target distribution, when the first attempt to get by package name and version fails, e.g.: experimental_changelog unstable_changelog Those files are updated at the same time as NAME_VERSION_changelog, so if this is not available then DIST_changelog will be for an older version and not contain the recent changes. I think that it would happen the contrary, the DIST_changelog would always be same or newer, and if anything NAME_VERSION+1_changelog replaced the version that aptitude asks about. Because this metadata central place would be always more up to date than the mirror (or the last aptitude update). Even if giving a newer version than expected, I think that it's a nicer fall-back than having a 404 because it cannot find the file for the exact version, and by the most recent version of the changelog one can see (if one cares about looking at the version line) that the version is not available. Sure, if a newer version is fetched that is certainly ok. In general, DIST_changelog should always exist, unless the package is removed or renamed, that's why I think that it would be a good fallback. Right. http://metadata.ftp-master.debian.org/changelogs/main/m/mono/ Does this service update more immediately than packages.d.o? If so, then it is quite possibly this is not an issue any more. I expect that, being under control of FTP masters (gatekeepers of packages in the archive), is more up to date than packages.d.o in the past, even if only for propagation delays. Right. The metadata service is updated as part of the dak runs, i.e. at the same time or immediately after the rest of the archive is updated. A quick look at timestamps of some changelogs shows delays in the order of tens of minutes as opposed to the hours or more that packages.d.o used to take. But packages.d.o now is a redirection to metadata. The only real difference now is probably that aptitude would be accessing with an extra redirection that could cause problem if the redirection goes away (the lack of which caused the original bug report) or the server is down. Sysadmins also announced that metadata is serverd by a CDN now, so perhaps is a tad more efficient. If the delay is still noticeable (I have not noticed since the switch), then DIST_changelog may be a reasonable fallback. I presume the user will want some notice that they have not received the most recent changelog/changelog for the version they requested. I think that this would almost always only happen in testing or unstable (not stable), I don't think that this realistically can affect anybody in stable, or that nobody will cares enough (if anything, the newer version will contain important fixes). Personally, using mostly unstable (where this can happen more often), I am not overly worried about the versions of packages that I am about to install which maybe are not in the mirrors, because the situation in unstable can change at any moment (it's perfectly possible to have more than 1 version uploaded per day), and in testing at least once per day. In any case, perhaps is an issue for some users, and we can add the suggested warning. Is printing a warning message along with the example below enough (which cannot be seen until after the pager quits), or should it require to press a key to make sure that the user notices before seeing the changelog in the pager? Get: Changelog of libdrm Get: Changelog of libdrm2 Warning: Changelog of libdrm2 is for latest version in unstable (3.2-1 not found) Sure, something like that. Perhaps wait to see if it is still a problem after the next release (with changelogs fetched from the new service). Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570377: [Aptitude-devel] Bug#570377: aptitude chooses to remove packages instead of upgrading
The safety cost levels are not intended to fine tune the results. They are a broad base to start from. There are other parameters for Aptitude::ProblemResolver::SolutionCost to provide tweaking (e.g. 3 * removals + installs). Details are in the manual, where I think it is quite clear. More details follow. On 4 February 2014 02:10, Chris Tillman toff.till...@gmail.com wrote: Thanks very much for your reply and explanation, Daniel. I can appreciate that fiddling with defaults is a serious consideration. However, the scoring system replaced the tiered system where removals were considered less desirable than upgrades. So longtime users perceived a drastic change in behaviour and in aptitude's attitude. I don't know why, with equal scores, aptitude now prefers the removals option. Even with 3 to remove or 2 to upgrade, it still suggests the removals first. The default setup is not configured to compare the number of removals vs upgrades. You can adjust Aptitude::ProblemResolver::SolutionCost to something like safety, removals if you care to fine tune as such. Changing something like that is more desirable (I explain later about safety cost levels), but requires people to change their own settings, use it for some time, and provide feedback before any change to the defaults will be considered. By adjusting the default just one point, its behaviour was completely different and it became a pleasure to use rather than seeming a constant battle. There may not be a philosophical difference between recommending removal of 3 packages including gnome, vs. upgrading 2 packages including the one you asked to upgrade, but there is definitely a psychological difference. So I'd argue that the 1-point advantage given to upgrades would represent that psychological preference. I really wonder about even the philosophical difference being 0. Users are attempting to maintain their system. If a user asks for an install or upgrade, surely more upgrades would be preferable. If they are doing removals or downgrades, then perhaps removals would be the direction they would want to go. Perhaps aptitude could be more sensitive to the requested operation and adjust priorities accordingly. Would you be open to a patch for that? No, as this makes the program less predictable. Also, many sets of user requests are not exclusively upgrades, installs, or removals, sessions are often a mixture of these. And, in any case, I certainly can't understand why the defaults chosen should be carved in stone. 1, 2, 5 ... these seem to have been set nearly arbitrarily. Do we have any data about real-world user actions, i.e. x choices presented in scored order and score[i] actually chosen, that would allow us to zero in on truly representative weights which minimise i? The safety cost _levels_ are set so as to provide a broad base from which to work. There are additional settings you can use in Aptitude::ProblemResolver::SolutionCost to provide fine tuning based on the number of removals vs. installs, etc.. The reason for the large spacing of the _levels_ is to permit enough room for the other costs to tweak the situation according to users tastes, e.g. weighing a solution with 3 removals as less desirable than 2 upgrades. With the change you propose—and only that—then _any_ solution with removals will be weighed after all solutions of installs/upgrades (to default release), even if it is a single solution of 1 removal vs dozens of solutions with hundreds of installs. This is not a desirable default. You can tweak the settings on your machine in different ways, using each for a while to get a proper feel. Some feedback based on long term use of different settings would be useful. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570377: [Aptitude-devel] Bug#570377: aptitude chooses to remove packages instead of upgrading
On 4 February 2014 10:24, Vincent Lefevre vinc...@vinc17.net wrote: On 2014-02-04 01:29:30 +0800, Daniel Hartwig wrote: There is nothing fundamentally better or worse about either removals or installs, in some situations you might find this: solution 1: upgrade 20 packages solution 2: remove 1 Whichever is more preferable in these situations is up to the individual user to decide based on whatever particular packages are suggested for upgrade, install, or removal—aptitude can not know how the user values those individual actions. Could you explain why, e.g. by giving a practical example? In my prior response, I am only addressing the proposed patch to tweak the safety cost levels. As the manual explains, the safety cost levels are meant to be broad--a base on which further tweaking can be provided. There are additional operators, such as removals and installs that can be inserted in to the safety cost calculation and provide tweaking. So my comments about the two being equivalent are only at the scope of the _safety cost levels_. Because I would say: A remove can be caused by some obsolete package due to a conflict with the newly installed package (or one of its dependencies). But in such a case, the remove would occur in *every* solution. If a package is not obsolete, aptitude should never propose it for removal when another solution can solve the problem. That is not the results from the current problem resolver, removals often pop up in isolated solutions, including different solutions with different removals. I do not know why that happens, however, given that it does, the proposed change to safety levels will dismiss some potentially trivial, very short solutions (e.g. 1 removal) in favour of dozens or more solutions that install/upgrade hundreds of packages each. Again, I am only addressing the proposed patch. There are better options, such as adjusting the default value of Aptitude::ProblemResolver::SolutionCost to account for the number of removals vs installs, or similar, but people should use such settings and provide feedback on the quality of the solutions and their order. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570377: aptitude chooses to remove packages instead of upgrading
To begin chasing down a real, workable solution: The default SolutionCost is safety, priority. I suspect the main problem here may be due to the unintended interactions of priority when there are/aren't removals involved, but do not have time to investigate further just yet *hint*. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#357542: aptitude: changelog display does not work on recent uploads
Control: tags -1 + moreinfo [Waiting on feedback whether this is still an issue on the new changelog service run by ftp-master.] On 31 January 2014 20:32, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Control: owner -1 ! This can probably be fixed now by downloading the files from the target distribution, when the first attempt to get by package name and version fails, e.g.: experimental_changelog unstable_changelog After more consideration, I am not really fond of this proposal because it disregards the user request. aptitude changelog foo=VER explicit request for specified version aptitude changelog foo implicit request for candidate version Error checking is generally being tightened in aptitude, and that includes cases where the users request can not be fulfilled. Anyway, whether this remains an issue using the new changelog service should be seen first before taking further action. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#720750: aptitude: search returns different numbers of packages depending on sort order
Control: tags -1 - pending On 3 February 2014 02:56, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Control: tags -1 + pending Fix commited, it will be included in the next release if no problem is found with the fix. http://anonscm.debian.org/gitweb/?p=aptitude/aptitude.git;a=commitdiff;h=845a868dc3a7af063c586c2b6ebf5e97daa90491 + +/* mafm: Disabled because it does not respect the 3 way comparison of the + * sort policies, so it removes from the result set any items with the same + * result for the given policy (package_results_eq with successful result, + * which means comparison result zero in policy). + * + * This is usually not noticeable in names (should be unique) or sizes of + * packages (very rare that the size is the same); but it does not work well + * on versions (repeated sometimes) and specially not in priorities, since + * they are only a few of them for all of the packages in the archive. + output.erase(std::unique(output.begin(), output.end(), aptitude::cmdline::package_results_eq(sort_policy)), output.end()); +*/ The search results will now include duplicate packages where there are multiple search patterns matching the same package: $ ./aptitude search '?name(^emacs24)' '?name(^emacs24)' p emacs24 - GNU Emacs editor (with GTK+ user interface p emacs24 - GNU Emacs editor (with GTK+ user interface [...] (That example is obviously contrived, but it is quite common for multiple patterns to have overlapping matches.) It is package_results_eq that must be corrected to properly address this. That function should consider package equality, rather than equality in sort_policy. Please revert. Note that package_results_eq no longer exists after wip-cmdline as search results are collected in a pkgset [libapt] which guarantees to contain only unique packages. Likewise for versions using verset. If you like, feel free to submit a patch for consideration that addresses the issue in package_results_eq. Though, as I mentioned, this will otherwise be resolved by the pending merge of wip-cmdline. Also related to this is the earlier addition of installsizechange. This is a 2-way comparison, inconsistent with the rest of the sorting module which is 3-way. There is this comment: + // mafm: if returning zero, the comparison stops for + // other packages Clearly this refers to bug #720750. Are there other areas you know about where this is an issue? If there are, we can fix those instead of hacking around them in the sorting module. Sorting module presently relies on 3-way comparisons for functionality such as chaining (as with a sort policy of priority, name). At present, installsizechange will fail to chain correctly and this should be corrected. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697278: aptitude-common: Please make aptitude installable on non-native architectures
Rogier rogier...@gmail.com wrote: When trying to install aptitude on a non-native architecture, installation fails because not suitable installation candidates are found for some dependencies, in particular for aptitude-common: [shell transcript] I assume a simple 'Multi-Arch: foreign' would fix this ? Yes. I have marked all binary packages with appropriate Multi-Arch fields. This is enough on this side, but some dependencies are not yet updated for multiarch (such as libxapian22) so I will send some patches their way also. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#357542: aptitude: changelog display does not work on recent uploads
On 31 January 2014 20:32, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Control: owner -1 ! This can probably be fixed now by downloading the files from the target distribution, when the first attempt to get by package name and version fails, e.g.: experimental_changelog unstable_changelog Those files are updated at the same time as NAME_VERSION_changelog, so if this is not available then DIST_changelog will be for an older version and not contain the recent changes. http://metadata.ftp-master.debian.org/changelogs/main/m/mono/ Does this service update more immediately than packages.d.o? If so, then it is quite possibly this is not an issue any more. If the delay is still noticeable (I have not noticed since the switch), then DIST_changelog may be a reasonable fallback. I presume the user will want some notice that they have not received the most recent changelog/changelog for the version they requested. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539978: marked as done (show says an installed package is not installed)
Control: reopen -1 Control: tags -1 = confirmed Control: severity -1 minor Control: owner -1 ! Control: retitle -1 [cmdline] show UPGRADE misleads by reporting not installed [To clarify this report. Also, taking ownership as it is entangled with wip-cmdline.] Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: # aptitude versions '^apt$' Package apt: i 0.9.14.2100 p 0.9.15unstable 500 # aptitude show apt Package: apt Essential: yes State: installed Automatically installed: no Version: 0.9.14.2 The package details shown above are for the installed version. The manual states that show displays the candidate version, which is presently not the case due to open issues with version selection on the command line [1]. Details for the candidate version still show not installed: $ aptitude show acpi | grep '^\(Pac\|Ver\|Sta\)' Package: acpi State: installed Version: 1.6-1 $ aptitude show acpi=CANDIDATE | grep '^\(Pac\|Ver\|Sta\)' Package: acpi State: not installed Version: 1.7-1 The concern being that it is misleading to report not installed for upgrades, though it may be technically correct, in a sense. It has been suggested to make things more clear by changing the state field to say not installed, upgrade or similar. An alternative is for aptitude show PKG to display both the candidate and installed versions, as apt-cache does. The wip-cmdline branch resolves the version selection issues and will make this issue with State more prominent again. The issue will be tended to in a continuation of that work. Regards Daniel Hartwig [1] http://bugs.debian.org/687474 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539978: marked as done (show says an installed package is not installed)
On 1 February 2014 13:58, Daniel Hartwig mand...@gmail.com wrote: The concern being that it is misleading to report not installed for upgrades, though it may be technically correct, in a sense. It has been suggested to make things more clear by changing the state field to say not installed, upgrade or similar. The same concern is valid for multi-arch alternates, especially in the case of M-A: foreign packages that have an installed equivalent. An alternative is for aptitude show PKG to display both the candidate and installed versions, as apt-cache does. Another alternate is to handle this similar to how the curses interface does, including a list of versions at the end. Such an approach has to be clear about informing the user which version is providing the details, as dependencies, etc. are prone to change. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#267162: Bug#267162: marked as done (aptitude: not installed not noted upon purge)
On 24 January 2014 18:06, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: 2014-01-24 02:38 Daniel Hartwig: This issue and other inconsistencies in the command line interface will be addressed by an extensive work I have in progress to restructure that module, using new tools exported by apt. The foundations of this work was in the 0.6.9 release, but that has been reworked and will be applied once the final changes are complete. I think that it would be useful to document things like this, in bug reports or elsewhere, and use public branches to know what's going on, otherwise people will not magically know that things like this are being worked on. For the original work, see the wip-cmdline branch. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573626: [Aptitude-devel] Bug#573626: Bug#573626: Bug#573626: aptitude: Terrible Interactive Search Performance
On 24 January 2014 05:11, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: That's why I am not sure if it's better to leave this open or close it. Realistically, I don't think that this is going to be fixed, Not immediately, but that is no reason to close it off. There is real work that can be done here, especially after work on startup times. and in any case not because of the existence of this problem, so leaving it open will not increase the chances of it being fixed. Leaving the report open does bring it to the attention of people looking to work on real issues. This task is perhaps interesting to someone looking to do non-trivial work. Also it was ignored for the best part of 4 years with no me toos. me toos is not really the character of bugs.d.o. Lack of these does not indicate disinterest. I only see it useful as a reminder, or to leave hints like what you gave above. Yes. For these and similar reasons many bugs are left open. Closing the reports does not make the issues go away. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#267162: [Aptitude-devel] Bug#267162: marked as done (aptitude: not installed not noted upon purge)
-- Forwarded message -- From: Dan Jacobson jida...@jidanni.org To: Debian Bug Tracking System sub...@bugs.debian.org Cc: Date: Sat, 21 Aug 2004 03:01:49 +0800 Subject: aptitude: not installed not noted upon purge # aptitude purge libgd2-xpm ... The following packages have been kept back: You forgot the ... is not installed line! -- Forwarded message -- From: Manuel A. Fernandez Montecelo manuel.montez...@gmail.com This bug report was submitted many years ago and never handled. This does not seem to happen now as described in the bug report (at least in my system, with pretty much the stock configuration). In the time between the bug report and your testing, it was decided that such output is only when --verbose is used. The inconsistency is still there, as confirmed by examination of the code and performing the commands with verbose enabled. This issue and other inconsistencies in the command line interface will be addressed by an extensive work I have in progress to restructure that module, using new tools exported by apt. The foundations of this work was in the 0.6.9 release, but that has been reworked and will be applied once the final changes are complete. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496724: aptitude-doc-en: html output fails validation
retitle -1 aptitude-doc-en: html output fails validation (html 4 strict) done On 22 January 2014 05:33, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: Hi, I cannot reproduce this bug now: $ validate --verbose /usr/share/doc/aptitude/html/en/index.html Checking /usr/share/doc/aptitude/html/en/index.html with HTML 4.01 Transitional document type... No errors! It seems to have been fixed in this commit, present in 0.6.8: commit 59d734c9028463c8b436851960195f8c69ef0693 Author: Daniel Hartwig mand...@gmail.com Date: Fri May 11 16:54:56 2012 +0800 Add doctype headers to html docs. The alt part is not fixed yet, it seems. Correct, the alt tags are required by html 4 strict and html 5, and are important for accessibility with text-only browsers, screen readers, etc. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718243: aptitude: sources + policy
On 1 August 2013 15:52, Axel Stammler a...@users.sourceforge.net wrote: The final sources line (localhost) refers to my own collection of scripts, which I have used for a long time. It worked without problems under Squeeze. Do you also get this error when using apt-get? -- sources.list: deb http://flora-e/debian ./ deb http://montevideo.homedns.org/debian ./ Do these repositories implement secure apt (see apt-secure(8))? Otherwise, if they are explicitly trusted you should indicate this like so: deb [trusted=yes] http://flora-e/debian ./ deb [trusted=yes] http://montevideo.homedns.org/debian ./ You mentioned that you get this error intermittently. The policy information you submitted for libreoffice-lightproof-en indicates an official server, so it is unlikely that is the culprit. Can you identify a single package or server that triggers it? Next time this occurs, cancel the installation and try to find the smallest set of packages that triggers the warning. One of those packages will be from the untrusted source and this will help identify the problem. You can then use ‘apt-cache policy PKG1 …’ to identify the sources being used. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718243: [Aptitude-devel] Bug#718243: aptitude: complains about supposedly untrusted packages at _every_ install attempt
Control: severity -1 normal On 29 July 2013 13:45, Axel Stammler a...@users.sourceforge.net wrote: Package: aptitude Version: 0.6.8.2-1 Severity: important Dear Maintainer, _Every_ time I call Aptitude with the install option, I get a message like WARNING: untrusted versions of the following packages will be installed! […] That happens even though all repositories I use have all keys installed (if necessary at all). A simple update run suffices to make the message disappear so that the installation can then proceed, but this only works for a day or so. Next time the warning appears again. Which sources are you using? Provide /etc/apt/sources.list and all files under /etc/apt/sources.list.d Also, the output from these commands: $ apt-cache policy $ apt-cache policy libreoffice-lightproof-en -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708812: [aptitude] aptitude segfaults upon being called.
Control: block 716828 by 716944 On 24 July 2013 19:03, Lifeng Sun lifong...@gmail.com wrote: [aptitude] suffers another FTBFS bug [6]. The current versions of google-mock and gtest in unstable are incompatible with each other. As google-mock relies on gtest, aptitude will continue to FTBFS until that situation is resolved. See http://bugs.debian.org/716944. There are also issues with gcc4.8 and boost that are fixed in git, but waiting for boost1.54 to become the default (or patched boost1.49 and boost1.53). http://bugs.debian.org/701243. Is there any plan to fix these bugs? I can help to fix it on mipsel. Once the blocking issues are resolved it will be no problem to get aptitude building again. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717317: aptitude: segfault when choosing Views - New Categorical Browser in ncurses interface
Control: tags -1 + confirmed Control: merge -1 686124 On 19 July 2013 17:42, Lorenz H-S lorenz-...@lgh-alumni.de wrote: Package: aptitude Version: 0.6.8.2-1 Severity: normal Dear Maintainer, upon choosing Views - New Categorical Browser in aptitude's ncurses inferace, it crashes reprocducibly with a segmentation fault. Hello Thanks for the report. We will be removing this feature in the near future. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716992: aptitude does not purge deleted packages when it asks for user confirmation
On 17 July 2013 01:16, Uwe Storbeck u...@ibr.ch wrote: Hi Daniel APT::Get::Purge should not have any effect in aptitude. Its name indicates it is only used by apt-get. Oh, I always thought aptitude inherits apt settings ... Options in the APT namespace, yes, and some others, but APT::Get is specific to one tool. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716944: google-mock: please upload r437 snapshot to syncronize with recent gtest snapshot
Package: google-mock Version: 1.6.0-1 Severity: normal Dear Maintainer, gtest is recently bumped to 1.7.0~svn20130629-2 [1]. The 1.6.0 release of googlemock is incompatible with this, though r437 [2] is. Please upload that version to keep the packages functional. I appreciate that you do not use the embedded copy of gtest, so let us keep these syncronized. Regards [1] http://code.google.com/p/googletest/source/detail?r=655 [2] http://code.google.com/p/googlemock/source/detail?r=437 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Foreign Architectures: mipsel Kernel: Linux 2.6.32-5-686-bigmem (SMP w/1 CPU core) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages google-mock depends on: ii libgtest-dev 1.7.0~svn20130629-2 ii python2.7.3-4 google-mock recommends no packages. google-mock suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716992: [Aptitude-devel] Bug#716992: aptitude does not purge deleted packages when it asks for user confirmation
Control: merge -1 568876 Control: tags -1 + confirmed On 16 July 2013 01:07, Uwe Storbeck u...@ibr.ch wrote: Package: aptitude Version: 0.6.8.2-1 Severity: normal Dear Maintainer, I have set APT::Get::Purge and Aptitude::Purge-Unused to true. Aptitude normally honors these settings when it (auto-)deletes packages. Hello APT::Get::Purge should not have any effect in aptitude. Its name indicates it is only used by apt-get. As you observe, and as the name implies, Aptitude::Purge-Unused applies only to autoremoved packages. But when aptitude runs into a situation where it has to ask the user for confirmation (e.g. when it has to delete other packages because of conflicts or dependencies) it ignores these settings and only deletes the packages without purging the config files. Presently there is no option to do what you ask, which is beyond the scope of Purge-Unused. Responding to those prompts where “remove this package to resolve a conflict” is not the same as removing an unused package. This is something to be looked at during the next development cycle. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714429: search for explicitly downgraded packages
On 3 July 2013 15:54, Harald Dunkel harald.dun...@aixigo.de wrote: Hi folks, please note that I don't want to loose the information which packages have been downgraded on purpose. I just want to _list_ these packages. Maybe a new search option could help? This is almost equivalent to installing an older version and holding it to avoid future upgrades. You should then search for upgradable, held packages: ‘~U~ahold’ (which will not work until such packages are listed as upgradable). Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710210: Current and upcoming toolchain changes for jessie
On 2 July 2013 10:56, Steve M. Robbins st...@sumost.ca wrote: Hi Daniel, I'd like some more information regarding these two bugs, where Boost has defined but not used a local typedef. On Fri, Jun 14, 2013 at 09:24:20AM +0800, Daniel Hartwig wrote: severity 710210 serious severity 710211 serious So a serious bug is defined as: a severe violation of Debian policy (roughly, it violates a must or required directive), or, in the package maintainer's or release manager's opinion, makes the package unsuitable for release. I looked through policy in vain for an applicable directive. Did you have one in mind? If not, what is your rationale for this severity? I did not have a specific directive in mind. I was forwarding the severity of the blocked bug. Please consider the severity as you like. I can guess you are concerned that this compiler warning causes a build failure for other packages that treat errors as warnings. I agree this is a nuisance and will endeavour to fix the issue. Appreciated. Libraries should not be generating avoidable compiler warnings. Anyway, fixing in boost is certainly better than applying the workaround in multiple packages. Small patch is a plus. However, in general I cannot agree that this alone makes it serious. The build failure is caused by the package using -Werror. An easy workaround is to add -Wno-unused-local-typedef for those packages using Boost and -Werror. Regards, -Steve -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714186: aptitude's Segmentation fault
Control: tags -1 + pending On 27 June 2013 01:12, Илья Мыльница mylntsa.ilya...@gmail.com wrote: Package: aptitude Version: 0.6.8.2-1 When I try to append %r escape to format of status line it crashes and prints Ouch! Got SIGSEGV, dying..\nSegmentation fault and does it every next running, like that: Thanks for the report. This is now fixed on the stable-0.6 branch for the next release. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714429: Bug#714429: search for explicitly downgraded packages
On 29 June 2013 17:57, Axel Beckert a...@debian.org wrote: Daniel Hartwig wrote: Please list the steps used to downgrade the package. Select a package, press v, press + on the package in Testing, press g 2x. After the package has been downgraded, exit aptitude. Start aptitide again and the package won't be listed in the list of upgradable packages (i.e. not match ~U). The request to install the older version is being stored in pkgstates file, even though it has already been performed. Starting the program again sets the candidate version as requested, that version is already installed, so the package is not considered upgradable. That is indeed a bug as the downgrade request should not be saved once it is performed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714429: search for explicitly downgraded packages
On 29 June 2013 15:14, Harald Dunkel ha...@afaics.de wrote: Package: aptitude Version: 0.6.8.2-1 Usually I have both testing and unstable in my sources.list. Problem: If I explicitly downgrade a package to testing (e.g. cryptsetup), then aptitude search ~U or aptitude search ~ahold don't tell later. Removing testing from sources.list doesn't help. Please list the steps used to downgrade the package. Do you use apt_preferences(5) (“pinning”) or package holds to achieve this? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714429: search for explicitly downgraded packages
On 29 June 2013 16:14, Daniel Hartwig mand...@gmail.com wrote: On 29 June 2013 15:14, Harald Dunkel ha...@afaics.de wrote: Package: aptitude Version: 0.6.8.2-1 Usually I have both testing and unstable in my sources.list. Problem: If I explicitly downgrade a package to testing (e.g. cryptsetup), then aptitude search ~U or aptitude search ~ahold don't tell later. Removing testing from sources.list doesn't help. Please list the steps used to downgrade the package. Do you use apt_preferences(5) (“pinning”) or package holds to achieve this? Also note that ‘aptitude search ~ahold’ will not return packages held with other programs, e.g. ‘apt-mark hold foo’. See http://bugs.debian.org/137771. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713906: [Aptitude-devel] Bug#713906: autoinstall packages persist after purge
Control: severity -1 minor
Control: merge -1 590308
Control: tags -1 + confirmed
On 24 June 2013 02:03, jida...@jidanni.org wrote:
Package: aptitude
Version: 0.6.9.1-1
[This experimental version has been withdrawn, I recommend you
downgrade to the latest in unstable.]
# aptitude -o APT::Install-Recommends=true install alsa-utils
The following NEW packages will be installed:
alsa-base{a} (R: alsa-utils) (for alsa-utils) alsa-utils
# aptitude -o APT::Install-Recommends=true purge alsa-utils
The following packages will be REMOVED:
alsa-utils{p}
Maybe it's because the two mutually recommend each other.
Something like that. An empty install run should remove the cruft:
# aptitude install
otherwise it will likely be cleaned up during some subsequent operation.
Anyway here's my conf settings
APT::Default-Release experimental;//just order them in sources.list UNTRUE
[The order is significant only in choosing a server to download a
specific version from.]
P.S. the man page says
-R, --without-recommends
Do not treat recommendations as dependencies when installing new
packages (this overrides settings in /etc/apt/apt.conf and
~/.aptitude/config). Packages previously installed due to
recommendations will not be removed.
This corresponds to the pair of configuration options
Apt::Install-Recommends and Apt::AutoRemove::InstallRecommends.
-r, --with-recommends
Treat recommendations as dependencies when installing new packages
(this overrides settings in /etc/apt/apt.conf and
~/.aptitude/config).
This corresponds to the configuration option
Apt::Install-Recommends
But then oddly doesn't explain why Apt::AutoRemove::InstallRecommends is
not affected by the latter.
[That should read ‘Apt::AutoRemove::RecommendsImportant’. I have just
fixed it.]
The AutoRemove setting is only relevant to support the later part of
‘-R’, that is:
Packages previously installed due to recommendations will
not be removed.
The behaviour of aptitudes ‘--without-recommends’ is now handled in
apt by two components. To maintain the traditional behaviour of this
option we have to _enable_ ‘RecommendsImportant’ to adjust the
autoremoval behaviour. Nothing similar is required for
‘--with-recommends’ as there are no problematic interactions.
Such explanations are not suitable for the manual page.
Also when you say 'corresponds' you should say if it corresponds to
setting them false or true. Same with all the others on the man page.
Noted. On my TODO list is to adopt a better style for these anyway,
including not documenting negative versions of options separately as
this only wastes space.
P.S. reading
file:///usr/share/doc/aptitude/html/en/ch02s02s06.html
Managing automatically installed packages
it seems like my assumptions in line with what it says...
so something is wrong.
Anyway please tell me how I can now clean up all the
aptitude search ~M
packages that even
deborphan --guess-all
can't detect shouldn't still be there.
Try:
# aptitude install \
-oAPT::AutoRemove::RecommendsImportant=false \
-oAPT::AutoRemove::SuggestsImportant=false
Although it may not select precisely the set you are interested in.
Regards
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713909: [Aptitude-devel] Bug#713909: slash operator when there are more than one /experimental
Control: found -1 0.6.8.2-1 Control: tags -1 + wontfix On 24 June 2013 03:18, jida...@jidanni.org wrote: Package: aptitude Version: 0.6.9.1-1 Man page says Similarly, to select a package from a particular archive, append /archive to the package name: for instance, aptitude install apt/experimental. However in the case of # apt-cache policy iceweasel iceweasel: Installed: (none) Candidate: 23.0~a2+20130621004018-1 Version table: 23.0~a2+20130621004018-1 0 990 http://mozilla.debian.net/ experimental/iceweasel-aurora i386 Packages 21.0-1 0 990 http://ftp.br.debian.org/debian/ experimental/main i386 Packages 17.0.6esr-1 0 500 http://ftp.br.debian.org/debian/ unstable/main i386 Packages There is no way we can choose further, # aptitude -s install iceweasel/experimental/main Couldn't find any package whose name or description matched iceweasel/experimental Couldn't find any package whose name or description matched iceweasel/experimental E: Unable to locate package iceweasel/experimental E: Unable to locate package iceweasel/experimental (we must resort to install iceweasel=21.0-1.) Here and in sources.list(5) the terms ‘archive’ and ‘distribution’ mean the same thing. Probably we should update aptitude documentation to use ‘distribution’ as apt-get(8) does. The output from apt-cache policy is for convenience, and does not indicate that there is a ‘experimental/iceweasel-aurora’ distribution. As far as apt is concerned, only the most recent version in each distribution is relevant. The component (‘iceweasel-aurora’ and ‘main’) is not imporant. To select a non-default version one time, use “=VERSION” syntax as you noted. For something more permanent, use apt_prefences(5) which is the preferred way to handle such precise policy settings. I do not see the utility of enabling the iceweasel-aurora source if you are not interested in having those versions _by default_. To include all ways of selecting packages on the command line makes a very complicated syntax which is undesirable, and the reason why there is apt_preferences(5). Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626251: /usr/bin/apt-get: apt-get source package/oldstable doesn't work either
On 16 June 2013 16:12, Bill Blough de...@blough.us wrote: As a followup to my previous message - When running apt-get source package It appears that package needs to be a binary package name, not a source package name. This makes my earlier observation about the deb entries make a little more sense to me, and leads me to believe that this behavior is by design. Yes. However, reading the apt-get man page, it's not clear to me that apt-get source does not allow specifying a source package name instead of a binary package name. Maybe something should be mentioned in the man page in case someone else comes along that's as dense as me ;-) You can use ‘--only-source’ to specify source package name. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671440: pdiffs
On 15 June 2013 07:11, David Kalnischkies kalnischkies+deb...@gmail.com wrote: On Fri, Jun 14, 2013 at 9:22 PM, Joey Hess jo...@debian.org wrote: * Add some kind of profile support, so I can tell apt when it'm in a bandwidth constrained environment. You can build a config file and load it with -c ~/constrained.conf That should be pretty much the same as a profile. Or do some magic with an ifupdown script maybe. Right, and that is all the support apt needs. Using ifupdown/nm/etc. to enable and disable such a config file is the best way to go. Those systems are precisely where network profile management should go and indeed are set up to handle just that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710210: Current and upcoming toolchain changes for jessie
severity 710210 serious severity 710211 serious severity 710253 serious -- On 13 June 2013 20:51, Matthias Klose d...@debian.org wrote: GCC 4.8 is now the default on all x86 architectures, and on all ARM architectures (the latter confirmed by the Debian ARM porters). Raising severity of these bugs accordingly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710751: why should work on patterns
On 2 June 2013 11:13, jida...@jidanni.org wrote: The latter should work just like # aptitude why bluetooth bluez bluez-compat libbluetooth3 i bluetooth Suggests bluez-cups p bluez-cupsDepends cups p cups Suggests hplip p hplip Suggests python-notify i python-notify Depends libgtk2.0-0 (= 2.8.0) i libgtk2.0-0 Suggests gvfs i A gvfs Suggests gvfs-backends p gvfs-backends Depends libbluetooth3 (= 4.91) Hello What is the function of the non-final arguments (‘bluetooth’ … ‘bluez-compat’) doing in this example? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710689: [Aptitude-devel] Bug#710689: aptitude: use unicode character in the trees
On 2 June 2013 10:42, Christoph Anton Mitterer cales...@scientia.net wrote: On Sun, 2013-06-02 at 09:25 +0800, Daniel Hartwig wrote: Do you have any complaint with the current drawing of tree nodes, other than “its not the precise unicode graphing characters”? Well not compliant... it's just that time moved on,... unicode is standard now unless for the most bare minimum situations where you perhaps end up with C locale (probably not situations where aptitude is used?) Systems where LANG or LC was set incorrectly, or where package locale is missing, broken, or under configured, or with fonts deliberately lacking unicode ranges to save on space. In such cases the fallback is C locale and it must be supported. Many standard tools, e.g. tree move on and at least provide/auto-detect unicode enabled output in addition to ASCII fallbacks. If tree maintainers want to support that then that is up to them. I do not want to support using different glyphs depending on locale, even if it is only two options depending on ascii or unicode. I have already spent far too much time fixing problems caused by this when e.g. translations do not render properly, or did previously and do no longer because of changes elsewhere. Anyway... I don't quite understand why this should be new to aptitude, as it already seems to use these box drawing characters (which are surely not ASCII), take e.g. ftp://ftp.debian.┌───┐iff [Downloaded] ftp://ftp.debian.│Downloaded 6906 kB in 1min 38s (70,1 kB/s).│iff [Downloaded] ftp://ftp.debian.│ [ Continue ] [ Cancel ] │ownloaded] ftp://ftp.debian.└───┘ownloaded] or any scroll bars chich use: ▒ A timely reminder to eliminate such faults. There are outstanding bug reports about e.g. misrenderings on non-utf8 locales due to precisely use of those glyphs. WRT, GNU Coding... well... they're quite old fashioned in some ways ;) These are conservative for precisely the goal of being portable across systems and languages. I am not really interested in tweaking glyphs where such already work fine. Now returning to finish up the wheezy branch so stable systems can have less quirky multiarch support. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618342: aptitude: inconsistent behaviour with apt-cache on non-readable sources.list file
Michael Prokop m...@debian.org wrote: /etc/apt/sources.list.d/foo.list contains something like: deb https://$USER:$PASSWD@$MIRROR internal main and because of confidential information ($USER/$PASSWD) the file is read-only for root (600). This is not a comment on the reported bug (not quoted here), but a note about usage. It is not ideal to include authentication credentials in sources.list. Those files should be world readable (or atleast readable by all apt-cache and aptitude users). There is a poorly documented option to use /etc/apt/auth.conf, which is formatted like netrc(5). Credentials should be placed in this file, with sources.list just containing the $MIRROR part. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710662: RM: aptitude/experimental -- RoM; abandoned development preview
Package: ftp.debian.org Severity: normal X-Debbugs-CC: aptitude-de...@lists.alioth.debian.org Dear ftpmasters Please remove aptitude 0.6.9.1-1 in experimental. It is decided for some time to abandon this branch, we do no longer support it. The next release will use a higher version number, though it will not include most of the changes from that branch. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710689: aptitude: use unicode character in the trees
Control: severity 133481 minor Control: merge 133481 -1 On 1 June 2013 23:23, Christoph Anton Mitterer cales...@scientia.net wrote: Package: aptitude Version: 0.6.8.2-1 Severity: wishlist Hi. It would be nice when aptitude would use unicode characters for the trees in the dependency lists, e.g. instead of: --\ Depends (3) something like this: ├─ Depends (3) Hello In the C locale we will continue to use only ASCII. The GNU Coding Standards is a fine reference for this type of thing, and will continue following its recommendations here. It would be possible to allow Unicode compatible locales to specify these characters in the po files, however, I am very much in favour of keeping such interface elements consistent across all locales which requires sticking to whatever restrictions are placed on the C locale. It is very difficult to keep bugs out of the interface when localizations impact the interface layout as well as content. Do you have any complaint with the current drawing of tree nodes, other than “its not the precise unicode graphing characters”? Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710687: aptitude: highlight the alternative dependencies bar |
On 2 June 2013 09:10, Christoph Anton Mitterer cales...@scientia.net wrote: Hi Daniel. On Sun, 2013-06-02 at 01:03 +, Debian Bug Tracking System wrote: Unnecessary noise. Visual cues such as alternate colour are quite attention grabbing and must be reserved for very important details such as e.g. broken packages and changing state. The alternatives are displayed in the common control file format, using an alternate colour on the syntax characters is quite distracting. Well one could have done something like this with an option that defaults to off. Implementing and supporting optional features adds work. I have no interest doing this for features which are only of subjective value. You will see this attitude reflected in the next major development branch where many existing options will be deprecated. So everybody not liking it, could have left it as is. Apart from that, just colourising the bar | itself (I wasn't talking about the whole line of course), doesn't seem that intention grabbing, does it? That is what I understood you to mean, just the bar. However, I consider this would be more distracting. And yes, it is rather a matter of taste. Anyway, I think we do have a general problem in Debian, that one cannot really follow what one wants with respect to alternatives... as well as when such are added or dropped. […] Personally I dont have trouble with that. Although it does place some burden on the administrator, the information is well structured and certainly not hidden. I leave your other reports about that open, maybe someone has suggestions e.g. for an algorithm to detect such changes. Just yesterday I saw a case, where a package recommends some libsocket-perl | libsocket6-perl package or something like that. However, libsocket6-perl was already installed earlier as a strict dependency... so I never noticed that the other package recommended libsocket-perl. As a follow up, there was really functionality missing. In aptitude you can pres ‘[’ on the line which says e.g. Recommends, and expands the whole tree under it. Items in that tree correspond to the alternatives in each recommendation, and are colourized based on package state. I find such a view quite useful and always use it when changes packages I am very interested in. I see your related requests are really to collapse the colourizing in those subtrees to the Recommends line itself. Personally I would find that distracting, and the information is already presented that way in the subtree. Anyway, leaving them open people can comment. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710587: aptitude: unable to purge a package
Hello Shirish
On 1 June 2013 11:29, shirish शिरीष shirisha...@gmail.com wrote:
Package: aptitude
Version: 0.6.9.1-1
Severity: normal
Can you reproduce this with 0.6.8.2-1? We are unable to support the
current experimental version.
$ aptitude search gnotski
c gnotski -
Klotski puzzle game for GNOME (transitional package)
$ sudo aptitude purge gnotski -y
The following packages will be REMOVED:
gnotski{p}
0 packages upgraded, 0 newly installed, 1 to remove and 4 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
D01: deferred_remove package gnotski:all
dpkg: warning: ignoring request to remove gnotski which isn't installed
What is the output of:
$ dpkg --version apt-cache policy gnotski dpkg -l gnotski
Regards
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680474: /usr/bin/apt-get: apt-get autoremove remove gdm3 python
On 30 May 2013 14:29, Justin R. Isaacson tombston...@shaw.ca wrote: I understand the last post states that this may not actually be a bug, but for some reason after running apt-get autoremove my debian 7 wheezy became un-useable as it removed the wpa-supplicant, libre office, pulse audio, and countless other essential packages. I really am at a loss as to how they became listed as unused in the first place. This is my first time bug reporting I would like to know how I can make this more beneficial to you in the future. What details should I include. If you are busy, which you probably are just give me a link to where I can educate myself on proper bug reporting etiquette. Thank-you. =D Hello Helpful information for such problems: - the complete output of ‘apt-get autoremove’ (you may use ‘script’ to record this) - history of package removals, e.g. /var/log/dpkg.log* - history of the system: is this a fresh install of wheezy or upgrade from previous release? The packages you mention are among those typically installed by desktop metapackages, such as ‘gnome’ and ‘task-gnome-desktop’. These metapackages can be removed if one of their dependencies is removed. As an example, perhaps you did not like having ‘gimp’ installed and removed it, this would cause the ‘gnome’ metapackages to be removed and consequently all these other packages in addition. If something like that has happened it is not really a bug. Please dont report a bug in that case, as it will only be closed. Your options are to either take all packages which the metapackage installs, or manually install just the subset you wish to keep. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701243: still... aptitude: ftbfs with GCC-4.8
On 29 May 2013 14:38, Daniel Hartwig mand...@gmail.com wrote: Problems in Boost still cause aptitude to FTBFS with gcc-4.8. New point release to be made available once these blocking bugs are fixed: - http://bugs.debian.org/710210 in libboost1.53-dev - http://bugs.debian.org/710211 in libboost1.49-dev There is a similar issue with google-mock and gcc-4.8. If needed that part of the test suite can be temporarily disabled to avoid holding up the transitions. The google-mock (actually in googletest) has been filed and is also blocking. A patch cherry-picked from upstream is provided. [1] The aptitude master branch is now updated such that it builds successfully with gcc-4.8 provided that gtest and boost are both patched. An upload will be made once all blocking bugs are closed. Regards [1] http://bugs.debian.org/710253 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709169: leaks daemon during build, breaking buildd
Control: tags -1 + pending On 25 May 2013 12:30, Daniel Hartwig mand...@gmail.com wrote: On 21 May 2013 17:52, Peter Palfrader wea...@debian.org wrote: Package: distcc Version: 3.2~rc1-1 Severity: serious Hi, it seems the distcc build leaks daemons during its build. This breaks buildds that try to build it since schroot is unable to cleanly close the ssession at the end of the build. Thanks for spotting that. The daemon is leaked by NoDetachDaemon_Case. Before teardown the process tree is: […] I have suggested to upstream that this is a bug in the handling of --no-detach, and also mentioned a possible solution. For now I have prepared a new debian package that disables this test. There are also some test case failures that seem due to running the suite in parallel and some etc. Fix these soon. These are also addressed in the new package. As those are the only changes, anyone should feel free to sponsor the upload currently waiting here: http://mentors.debian.net/debian/pool/main/d/distcc/distcc_3.2~rc1-2.dsc Package is tested locally with sbuild and parallel builds, and should also be sufficient to build on hurd. I can not determine if there will be further architecture-specific failures. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708170: clone doesn't properly handle blocked-by [only uses blocks]
Don Armstrong d...@debian.org wrote:
On Mon, 13 May 2013, Jakub Wilk wrote:
Apparently the blocked-by relation between #692286 and #708166 was
inverted.
Yeah; this is a bug in the cloning; I'll get a fix out for it soonish.
My perlfu is weak, but something like attached?
From 3ce917993c54c3e84851cfc44e367ba51e97e54d Mon Sep 17 00:00:00 2001
From: Daniel Hartwig mand...@gmail.com
Date: Wed, 29 May 2013 13:35:13 +0800
Subject: [PATCH] make clone properly handle blocked-by bugs
* Debbugs/Control.pm (clone_bug): Ensure that each new bug is
correctly blocked-by the same bugs as the original. Refactor for
both blocks and blocked-by, perform only the minimal number of
updates.
Closes: #708170
---
Debbugs/Control.pm | 32 +++-
1 file changed, 15 insertions(+), 17 deletions(-)
diff --git a/Debbugs/Control.pm b/Debbugs/Control.pm
index 44d0062..7ce0f15 100644
--- a/Debbugs/Control.pm
+++ b/Debbugs/Control.pm
@@ -2962,25 +2962,23 @@ sub clone_bug {
__end_control(%info);
# bugs that this bug is blocking are also blocked by the new clone(s)
for my $bug (split ' ', $data-{blocks}) {
- for my $new_bug (@new_bugs) {
- set_blocks(bug = $new_bug,
- block = $bug,
- hash_slice(%param,
- keys %common_options,
- keys %append_action_options),
- );
- }
+ set_blocks(bug = $bug,
+ block = @new_bugs,
+ add = 1,
+ hash_slice(%param,
+ keys %common_options,
+ keys %append_action_options),
+ );
}
# bugs that this bug is blocked by are also blocking the new clone(s)
-for my $bug (split ' ', $data-{blockedby}) {
- for my $new_bug (@new_bugs) {
- set_blocks(bug = $bug,
- block = $new_bug,
- hash_slice(%param,
- keys %common_options,
- keys %append_action_options),
- );
- }
+my @blockers = split ' ', $data-{blockedby};
+for my $new_bug (@new_bugs) {
+ set_blocks(bug = $new_bug,
+ block = @blockers,
+ hash_slice(%param,
+ keys %common_options,
+ keys %append_action_options),
+ );
}
}
--
1.7.10.4
Bug#701243: still... aptitude: ftbfs with GCC-4.8
On 28 May 2013 20:17, Axel Beckert a...@debian.org wrote: Hi Daniel, Daniel Hartwig wrote: On 3 May 2013 04:56, Dmitrijs Ledkovs x...@debian.org wrote: I have now tried building aptitude using ubuntu saucy chroot which has gcc-4.8 and boost1.53. This resulted in the following build failure: http://paste.ubuntu.com/5627193/ A patch for that was last month posted to aptitude-devel. Now that #701243 (FTBFS with gcc 4.8) has been raised to severity serious, are then any short-term update plans -- also with regards to the upcoming libboost transition (http://bugs.debian.org/704032)? Problems in Boost still cause aptitude to FTBFS with gcc-4.8. New point release to be made available once these blocking bugs are fixed: - http://bugs.debian.org/710210 in libboost1.53-dev - http://bugs.debian.org/710211 in libboost1.49-dev There is a similar issue with google-mock and gcc-4.8. If needed that part of the test suite can be temporarily disabled to avoid holding up the transitions. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710208: aptitude: FTBFS with Boost 1.53
Control: tags -1 - patch Test suite requires further work: In file included from ../../../../src/cmdline/mocks/teletype.cc:23:0: ../../../../src/cmdline/mocks/terminal.h:56:9: error: ambiguous template specialization ‘make_sharedaptitude::cmdline::mocks::terminal_output’ for ‘boost::shared_ptraptitude::cmdline::mocks::terminal_output boost::make_sharedaptitude::cmdline::mocks::terminal_output()’ boost::make_sharedterminal_output(); ^ In file included from /usr/include/boost/smart_ptr/make_shared.hpp:15:0, from /usr/include/boost/make_shared.hpp:15, from ../../../../src/generic/util/mocks/mock_util.h:24, from ../../../../src/cmdline/mocks/teletype.h:24, from ../../../../src/cmdline/mocks/teletype.cc:21: /usr/include/boost/smart_ptr/make_shared_object.hpp:134:72: note: candidates are: templateclass T typename boost::detail::sp_if_not_arrayT::type boost::make_shared() template class T typename boost::detail::sp_if_not_array T ::type make_shared() ^ In file included from ../../../../src/cmdline/mocks/teletype.cc:23:0: ../../../../src/cmdline/mocks/terminal.h:35:45: note: templateclass T boost::shared_ptrX boost::make_shared() templatetypename T boost::shared_ptrT make_shared(); -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710253: libgtest-dev: GTEST_COMPILE_ASSERT_ triggers unused-local-typedef warning with GCC 4.8
Package: libgtest-dev
Version: 1.6.0-2
Severity: normal
Tags: upstream patch
Control: block 701243 by -1
Dear Maintainer,
googletest 1.6 and earlier has GEST_COMPILE_ASSERT_ that triggers
unused-local-typedef warnings with GCC 4.8. These are fatal for all
users of -Werror e.g. aptitude.
Attached patch is part of an upstream commit and does allow aptitude
to build ok (after patching for aptitudes own issues). Please apply.
Regards
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686-bigmem (SMP w/1 CPU core)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-- no debconf information
Descripton: avoid unused-local-typedef
Origin: http://code.google.com/p/googletest/source/detail?r=643
diff --git a/include/gtest/internal/gtest-port.h b/include/gtest/internal/gtest-port.h
index f78994a..dc4fe0c 100644
--- a/include/gtest/internal/gtest-port.h
+++ b/include/gtest/internal/gtest-port.h
@@ -813,8 +813,8 @@ struct CompileAssert {
};
#define GTEST_COMPILE_ASSERT_(expr, msg) \
- typedef ::testing::internal::CompileAssert(bool(expr)) \
- msg[bool(expr) ? 1 : -1]
+ typedef ::testing::internal::CompileAssert(static_castbool(expr)) \
+ msg[static_castbool(expr) ? 1 : -1] GTEST_ATTRIBUTE_UNUSED_
// Implementation details of GTEST_COMPILE_ASSERT_:
//
Bug#710210: libboost1.53-dev: BOOST_STATIC_ASSERT triggers unused-local-typedef warning with GCC 4.8
Package: libboost1.53-dev Version: 1.53.0-4 Severity: normal Tags: upstream patch Control: block 701243 by -1 Dear Maintainer, Boost 1.53 and earlier have a BOOST_STATIC_ASSERT macro that generates unused-local-typedef warnings with GCC 4.8. These are fatal for all users of -Werror. This was previously mentioned as part of the report against 1.49 (#701377) but seems to have been missed in 1.49.0-4. The attached patch is cherry picked from 1.54. Please include this in 1.53 and 1.49. Regards -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686-bigmem (SMP w/1 CPU core) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libboost1.53-dev depends on: ii libc6 2.17-3 ii libgcc1 1:4.8.0-7 ii libicu484.8.1.1-12 ii libstdc++-4.8-dev [libstdc++-dev] 4.8.0-7 ii libstdc++6 4.8.0-7 ii libstdc++6-4.7-dev [libstdc++-dev] 4.7.2-5 libboost1.53-dev recommends no packages. Versions of packages libboost1.53-dev suggests: pn default-jdk none ii docbook-xml 4.5-7.2 ii docbook-xsl 1.78.1+dfsg-1 ii doxygen 1.7.6.1-2.1 pn fop none pn libboost-atomic1.53-dev none pn libboost-chrono1.53-dev none pn libboost-context1.53-dev none pn libboost-date-time1.53-devnone pn libboost-exception1.53-devnone pn libboost-filesystem1.53-dev none pn libboost-graph-parallel1.53-dev none pn libboost-graph1.53-devnone ii libboost-iostreams1.53-dev1.53.0-4 pn libboost-locale1.53-dev none pn libboost-math1.53-dev none pn libboost-mpi-python1.53-dev none pn libboost-mpi1.53-dev none pn libboost-program-options1.53-dev none ii libboost-python1.53-dev 1.53.0-4 pn libboost-random1.53-dev none ii libboost-regex1.53-dev1.53.0-4 ii libboost-serialization1.53-dev1.53.0-4 pn libboost-signals1.53-dev none pn libboost-system1.53-dev none ii libboost-test1.53-dev 1.53.0-4 pn libboost-thread1.53-dev none pn libboost-timer1.53-devnone pn libboost-wave1.53-dev none pn libboost1.53-doc none ii xsltproc 1.1.26-14.1 -- no debconf information Description: [BOOST_STATIC_ASSERT]: GCC 4.8 warns unused local typedef Part of upstream changeset [82886]. Bug: https://svn.boost.org/trac/boost/ticket/7242 Origin: https://svn.boost.org/trac/boost/changeset/82886 --- a/boost/static_assert.hpp +++ b/boost/static_assert.hpp @@ -43,6 +43,14 @@ #else # define BOOST_STATIC_ASSERT_BOOL_CAST(x) (bool)(x) #endif +// +// If the compiler warns about unused typedefs then enable this: +// +#if defined(__GNUC__) ((__GNUC__ 4) || ((__GNUC__ == 4) (__GNUC_MINOR__ = 7))) +# define BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE __attribute__((unused)) +#else +# define BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE +#endif #ifndef BOOST_NO_STATIC_ASSERT # define BOOST_STATIC_ASSERT( B ) static_assert(B, #B) @@ -122,7 +130,7 @@ #define BOOST_STATIC_ASSERT( B ) \ typedef ::boost::static_assert_test\ sizeof(::boost::STATIC_ASSERTION_FAILURE BOOST_STATIC_ASSERT_BOOL_CAST( B ) )\ - BOOST_JOIN(boost_static_assert_typedef_, __LINE__) + BOOST_JOIN(boost_static_assert_typedef_, __LINE__) BOOST_STATIC_ASSERT_UNUSED_ATTRIBUTE #endif #else
Bug#710017: RFS: distcc/3.2~rc1-2 [RC] -- simple distributed compiler
Package: sponsorship-requests Severity: important X-Debbugs-CC: John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de Dear mentors, I am looking for a sponsor for my package distcc Package name: distcc Version : 3.2~rc1-2 Upstream Author : Martin Pool m...@samba.org URL : http://code.google.com/p/distcc/ License : GPL-2+ Section : devel It builds those binary packages: distcc - simple distributed compiler client and server distcc-pump - pump mode for distcc a distributed compiler client and server distccmon-gnome - GTK+ monitor for distcc a distributed client and server The previous upload included many upstream changes to fix longstanding issues in the test suite. Some unexpected problems remained that were exposed by buildd failures on most architectures. This upload strives to address the cause of these failures. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/distcc Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/d/distcc/distcc_3.2~rc1-2.dsc distcc (3.2~rc1-2) experimental; urgency=low [ Daniel Hartwig ] * do not run tests in parallel * debian/patches: - 12_test-debian.patch: NoDetachDaemon_Case is broken and leaves an orphaned process; disabled to keep buildd happy (Closes: #709169) - 14_test-reliability.patch: improve reliability of tests Regards Subject: From: Daniel Hartwig mand...@gmail.com --text follows this line-- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709169: leaks daemon during build, breaking buildd
Control: tags -1 + confirmed Control: owner -1 ! On 21 May 2013 17:52, Peter Palfrader wea...@debian.org wrote: Package: distcc Version: 3.2~rc1-1 Severity: serious Hi, it seems the distcc build leaks daemons during its build. This breaks buildds that try to build it since schroot is unable to cleanly close the ssession at the end of the build. Thanks for spotting that. The daemon is leaked by NoDetachDaemon_Case. Before teardown the process tree is: $ ps xf | grep distccd | grep -v grep 1973 pts/1S+ 0:00 \_ /bin/sh -c distccd «ARGS» 1974 pts/1SN 0:00 \_ distccd «ARGS» 1975 pts/1SN 0:00 \_ distccd «ARGS» 1976 pts/1SN 0:00 \_ distccd «ARGS» 1977 pts/1SN 0:00 \_ distccd «ARGS» The test teardown is equivalent to: $ kill 1973 $ ps xf | grep distccd | grep -v grep 1974 pts/1SN 0:00 distccd «ARGS» 1975 pts/1SN 0:00 \_ distccd «ARGS» 1976 pts/1SN 0:00 \_ distccd «ARGS» 1977 pts/1SN 0:00 \_ distccd «ARGS» which does not look right to me. There are also some test case failures that seem due to running the suite in parallel and some etc. Fix these soon. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709351: synaptic: Synaptic garbles package sources
Control: tags -1 + confirmed Control: merge 360338 -1 On 23 May 2013 23:41, Sebastian Dalfuß s...@sedf.de wrote: Hello. On Thu, May 23, 2013 at 04:50:08PM +0200, Michael Vogt wrote: Could you please attach a screenshot of the window that breaks the sources.list ? What steps will I need to take to reproduce this? Attached you'll find a screenshot. To reproduce: simply open that window and look at the section line. Thanks, Sebastian Merging with 360338. This is a fairly old issue, but I do not really use synaptic so only noticed it recently. See also http://bugs.debian.org/301979 which is related but not quite the same. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708812: [Aptitude-devel] Bug#708812: [aptitude] aptitude segfaults upon being called.
On 19/05/2013 1:09 AM, Javier Vasquez j.e.vasque...@gmail.com wrote: Package: aptitude Version: 0.6.8.2-1 Architecture: mipsel After Today's (2013/05/18) aptitude safe-upgrade, aptitude segfaults upon calling it. I'm attaching the strace log when calling aptitude. Please install aptitude-dbg and send a stack trace from gdb. What version of libapt-pkg4.12 and apt? Seems like apt-get still works, though aptitude ncurses UI is really missed, and I'm used to aptitude already, :-) I'm running on mipsel architecture for on a loongson-2f mini-pc. Thanks, -- Javier. ___ Aptitude-devel mailing list aptitude-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
Bug#708845: Why on package: synaptic 0.75.13 on Debian 7 i see Ubuntu?
Control: severity -1 minor Control: merge 691681 708409 -1 On 19/05/2013 8:33 AM, Abderraouf Adjal abderraouf.ad...@gmail.com wrote: Package: synaptic Version: 0.75.13 Tags: Ubuntu, synaptic User: Abderraouf A. Why on package: synaptic 0.75.13 on Debian 7 i see Ubuntu? I am on Debian NOT Ubuntu. Look at the Screenshot. Looks like a simple oversight.
Bug#708345: aptitude: Aptitude fails to download changelogs for many packages
Control: found -1 0.6.8.2-1 Control: tags -1 + confirmed On 15 May 2013 16:45, Ralf Jung p...@ralfj.de wrote: Package: aptitude Version: 0.6.9.1-1 Severity: normal Dear Maintainer, for around a month now, aptitude fails to download changelogs for many packages, including most (of not all) packages which have been updated since then. Download fails for all changelogs due to relocation of data on debian web sites. You notice that changelog works for some packages because aptitude will use the local copy when it is the most recent. First I suspected this a bug in the Debian websites, but according to the BTS [1] [2], these have been fixed, and indeed the links on packages.qa.debian.org and packages.debian.org work fine. Aptitude however uses a disfunctional URL. For a long time changelogs are accessible under http://packages.debian.org/changelogs/. As indicated by the new PTS links these are now under http://ftp-master.metadata.debian.org/changelogs/ and, unfortunately, not using a compatible path. Had the paths been compatible you could workaround by setting Apt::Changelogs::Server in apt.conf. As the structure of the old URIs is hardcoded in many places, hopefully the old paths will be setup to redirect soon. Anyway, confirming as path construction in aptitude must be fixed. Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708345: aptitude: Aptitude fails to download changelogs for many packages
Control: tags -1 - confirmed On 15 May 2013 17:30, Daniel Hartwig mand...@gmail.com wrote: For a long time changelogs are accessible under http://packages.debian.org/changelogs/. As indicated by the new PTS links these are now under http://ftp-master.metadata.debian.org/changelogs/ and, unfortunately, not using a compatible path. Had the paths been compatible you could workaround by setting Apt::Changelogs::Server in apt.conf. As the structure of the old URIs is hardcoded in many places, hopefully the old paths will be setup to redirect soon. See http://lists.debian.org/debian-www/2013/05/msg4.html. Anyway, confirming as path construction in aptitude must be fixed. Deconfirming for the moment, until the situation stabalizes and it is decided which should be the canonical URI. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
