Your message dated Thu, 3 Dec 2015 13:42:14 +0000 with message-id <CAPQ4b8nHNuFV+cY6N46=MZEYkuT=nmxzjzotrjaftyi7dew...@mail.gmail.com> and subject line Re: aptitude: unmarkauto not working? has caused the Debian Bug report #516131, regarding aptitude: unmarkauto not working? to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 516131: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516131 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: aptitude Version: 0.4.11.11-1 Severity: normal I try this: tucano:/tmp# aptitude install octave3.1-info Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Reading task descriptions... Done The following packages will be REMOVED: glpk-doc{u} glpk-utils{u} 0 packages upgraded, 0 newly installed, 2 to remove and 0 not upgraded. Need to get 0B of archives. After unpacking 1892kB will be freed. Do you want to continue? [Y/n/?] n Abort. Okay, this is normal: i removed the old empty glpk package, so I have to tell aptitude that I really want these. So I do: tucano:/tmp# aptitude unmarkauto glpk-doc glpk-utils Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Reading task descriptions... Done The following packages will be REMOVED: glpk-doc{u} glpk-utils{u} 0 packages upgraded, 0 newly installed, 2 to remove and 0 not upgraded. Need to get 0B of archives. After unpacking 1892kB will be freed. Do you want to continue? [Y/n/?] n Abort. Something is going wrong. I cannot seem to be able to tell aptitude that I really want those packages. -- Package-specific info: aptitude 0.4.11.11 compiled at Nov 20 2008 05:11:32 Compiler: g++ 4.3.2 Compiled against: apt version 4.6.0 NCurses version 5.7 libsigc++ version: 2.0.18 Ept support enabled. Current library versions: NCurses version: ncurses 5.7.20081213 cwidget version: 0.5.12 Apt version: 4.6.0 linux-vdso.so.1 => (0x00007fff6ffff000) libapt-pkg-libc6.7-6.so.4.6 => /usr/lib/libapt-pkg-libc6.7-6.so.4.6 (0x00007f1e67a36000) libncursesw.so.5 => /lib/libncursesw.so.5 (0x00007f1e677eb000) libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x00007f1e675e6000) libcwidget.so.3 => /usr/lib/libcwidget.so.3 (0x00007f1e67313000) libept.so.0 => /usr/lib/libept.so.0 (0x00007f1e6709a000) libxapian.so.15 => /usr/lib/libxapian.so.15 (0x00007f1e66d30000) libz.so.1 => /usr/lib/libz.so.1 (0x00007f1e66b19000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f1e668fd000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f1e665f1000) libm.so.6 => /lib/libm.so.6 (0x00007f1e6636e000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f1e66157000) libc.so.6 => /lib/libc.so.6 (0x00007f1e65e04000) libutil.so.1 => /lib/libutil.so.1 (0x00007f1e65c01000) libdl.so.2 => /lib/libdl.so.2 (0x00007f1e659fd000) /lib64/ld-linux-x86-64.so.2 (0x00007f1e67cf7000) Terminal: screen.linux $DISPLAY is set. `which aptitude`: /usr/bin/aptitude aptitude version information: aptitude linkage: -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-proposed-updates') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=it_IT@euro (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6. 0.7.20.2 Advanced front-end for dpkg ii libc6 2.7-18 GNU C Library: Shared libraries ii libcwidget3 0.5.12-4 high-level terminal interface libr ii libept0 0.5.26 High-level library for managing De ii libgcc1 1:4.3.3-3 GCC support library ii libncursesw5 5.7+20081213-1 shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.18-2 type-safe Signal Framework for C++ ii libstdc++6 4.3.3-3 The GNU Standard C++ Library v3 ii libxapian15 1.0.7-4 Search engine library ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-do 0.4.11.11-1 English manual for aptitude, a ter ii libparse-debianchangelog-per 1.1.1-2 parse Debian changelogs and output Versions of packages aptitude suggests: pn debtags <none> (no description available) ii tasksel 2.78 Tool for selecting tasks for insta -- no debconf information
--- End Message ---
--- Begin Message ---2015-12-03 12:52 GMT+00:00 Francesco Potortì <[email protected]>: >>2009-02-19 13:01 Francesco Potort�: >>> >>> >>>[...] >>> >>> tucano:/tmp# aptitude unmarkauto glpk-doc glpk-utils >>> Reading package lists... Done >>> Building dependency tree >>> Reading state information... Done >>> Reading extended state information >>> Initializing package states... Done >>> Reading task descriptions... Done >>> The following packages will be REMOVED: >>> glpk-doc{u} glpk-utils{u} >>> 0 packages upgraded, 0 newly installed, 2 to remove and 0 not upgraded. >>> Need to get 0B of archives. After unpacking 1892kB will be freed. >>> Do you want to continue? [Y/n/?] n >>> Abort. >>> >>>Something is going wrong. I cannot seem to be able to tell aptitude >>>that I really want those packages. >> >>Unfortunately this package does not exist and the new octave-info >>doesn't have the same dependencies. >> >>But in general, I have not observed this kind of behaviour nor have seen >>bugs reported related to this in the recent years/versions. Some parts >>of the resolver were changed a lot in those years, esp. in the run up to >>0.6. >> >>Have you experienced the same behaviour since, or did it only happen >>during that time? > > Maybe I have had the same behaviour other times, but I do not remember. > The only thing that I know is that I still remember that every time I > tried using nomarkauto it did not work, but it is not something that I > do often. > > Also, I suspect that nomarkauto is a rarely used command, so I would not > rely on lack of feedback to assume that it works. And osrry, I have not > ime now to devise a different test to check the functionality of > unmarkauto. I use it from time to time, and specially lately trying to verify some bug reports, many related with *auto. Some of the users submitting bug reports to aptitude frequently use the command as well. So Iif the bug is present in such as a general case as presented, and with a clear bug title, there are high chances that this report would have been "seconded" in 6 years, perhaps even have many duplicates. If it so happens that it's only hit (or reported) once every several years, I am going to assume that either it works or else nobody cares enough about unmarkauto or reporting, in which case it doesn't warrant to keep a bug report open indefinitely just in case that there might be a latent bug hidden somewhere (otherwise we would be buried of more than a thousand bug reports, as it happened not so long ago, and unable to operate). Even if not present now, the problems can have been caused also by external factors like the implementation of libapt, and can resurface at any point anyway (by external factors or changes in aptitude), so it can be dealt with if somebody finds it again with a fresh use case. So closing the bug for now. Cheers. -- Manuel A. Fernandez Montecelo <[email protected]>
--- End Message ---
_______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
