Bug#819840: [Aptitude-devel] Bug#819840: aptitude: Segfaults if suspended and foregrounded on virtual linux console
2016-04-23 21:54 Axel Beckert: Hi Manuel, did I mention that this issue is TUI related? Haven't really tried to suspend aptitude in commandline mode while it's waiting for me to press enter or such. Yeah, that's what I had understood. In fact, waiting for "press key to continue" ignores the Ctrl-Z. Manuel A. Fernandez Montecelo wrote: >Not sure if it's gdb which is broken on armhf or something else. Did you try with valgrind, btw? Nope. Will try on the Raspberry Pi when I'm back home. In armhf unusably slow I suppose, but in x86 is usable (~1 minute). I think that you can redirect valgrind's stderr and still use curses. While I still can reproduce the issue with aptitude 0.8 on armhf (about a day ago), I (to some extent unfortunately) can no more reproduce it on amd64 (now). Interestingly I have another phenomenon with Ctrl-Z on amd64 now: You always get strange behaviours! (midway between :D and :/) On a linux vt console it only works once: I can suspend aptitude once with Ctrl-Z and foreground it again with "fg". But from then on, Ctrl-Z seems to be a no-op inside aptitude's TUI. Works fine though in an xterm or a screen session (inside the same xterm). I can always suspend repeatedly also with the latest version (and my compiled version from master and other flags like debugging enabled), both in xterms and Linux VT. Also with aptitude inside tmux after ssh inside an xterm (konsole). Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#822331: "E: Cannot remove aptitude within aptitude" on multi-arch
Control: severity -1 minor Control: tags -1 + moreinfo Hi, 2016-04-23 14:48 Christian Klein: Package: aptitude Version: 0.8-1 Severity: normal From time to time, I invoke a "purge" (_ key) on the "Not Installed Packages" section in aptitude to remove any config data for packages that were removed but not purged. With aptitude in unstable, this gives an error "E: Cannot remove aptitude within aptitude". With aptitude in testing (0.7.5-3), this is not the case. I guess this is triggered by the fact that I have multi-arch configured to use i386 and amd64 packages, and the "Not Installed Packages" section contains the aptitude:i386 package (which, however, is obviously uninstalled, as I use the aptitude:amd64 package). This was because some previous complaints saying that basically aptitude shouldn't allow to remove itself, and errors caused if doing so. I think that it's a good idea to keep it. Perhaps the error can be avoided in your use-case if remove/purge (and thus, the error message) are only made effective in the case that the package is not already removed/purged. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#822329: aptitude: Hold Package and Upgrade Package slow
Hi, 2016-04-23 14:29 Christian Klein: Package: aptitude Version: 0.8-1 Severity: important Since upgrading to 0.8-1, standard operations in aptitude are really slow. When requesting an upgrade of a package (+) or holding (h) a package, or downgrading a package, aptitude takes several seconds to respond (with 100% cpu usage). While I know that this annoying behavior happens if a package dependency is broken, I didn't encounter it for a normal upgrade/hold operation until upgrading to 0.8-1. A downgrade to 0.7.5-3 in testing immediately brought back the old behaviour (annoyingly slow only if there are broken packages around), so I'm pretty sure that this was newly introduced in some version after 0.7.5-3, probably with the new 0.8 release. Since I got a pretty fast Skylake PC i really wonder why aptitude needs several seconds to complete such operations. This is probably for the fix of #819636, maybe the check is too expensive and not worth it after all. (In my not-bleeding-edge system takes 1s or a fraction, not several seconds). As a work-around, disabling "Install recommends automatically" should help with the speed, but I'm not sure if you'll want to do this (use at your own risk!). Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#822272: aptitude: No more forgets reinstallation instruction after reinstallation has happened
Hi, 2016-04-22 21:32 Axel Beckert: Package: aptitude Version: 0.8-1 Severity: normal If I select a package for reinstallation by pressing "L" in the TUI and then press 2x "g", the package will be reinstalled. Afterwards at "Press Return to continue, 'q' followed by Return to quit." I press (not Ctrl-C) and it still lists that package for reinstallation. Hmmm, I cannot reproduce it (this is becoming a trend... but I am not doing it on purpose, I promise!). I tried now with e.g. netris (has the virtue of being small and probably harmless) and works fine. I am pretty sure that I tested that this would not happen when implementing the feature, because it was the problem that prevented it from being implemented before, and also the reason why "q+Enter" needs to do some processing rather than exiting more quickly -- to detect upgrades and reinstalls and other changes in states, and save it to not repeat them in later sessions. Does it happen with any package that you try? I don't have any clue of what might be wrong. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#822208: aptitude: [INTL:ja] Japanese translation of po file update
Control: tags -1 + pending Hi, 2016-04-22 01:54 Takuma Yamada: Package: aptitude Version: 0.6.11-1+b1 Severity: wishlist Tags: l10n patch Dear Maintainer, Here's Japanese translation of po (ja.po) file that reviewed by several Japanese Debian developers and users. Please copy the attachment into po/ja.po. Commited, thanks! The number of changed strings is not big, and in particular msgids are not changed, so I'm assuming that it's related to the version 0.7.8 or 0.8 released yesterday. (The "Version: 0.6.11-1+b1" confused me a bit, wondering if it was for a stable update -- I don't know if it's customary to use "Version: X" of the bug report to indicate the version of the translation). Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#555896: aptitude: dist-upgrade doesn't install new essential pkgs from non-default release
Control: tags -1 + pending Control: owner -1 ! 2016-04-21 21:41 GMT+01:00 Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>: > Control: tags -1 + pending > Control: owner -1 ! > > > 2009-11-12 12:47 Ivan Vilata i Balaguer: >> >> >> Assuming that the behaviour of ``apt-get`` is right (see #216768), >> Aptitude should also install >> the new essential packages when ``dist-upgrade`` is run. Thanks! > > > Fixed now, marking as +pending (and the sibling #757028). Replying to bug report now... -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#820486: I follow aptitude's advice and end up with a broken (B) package
Control: tags -1 + moreinfo Hi, 2016-04-09 00:24 積丹尼 Dan Jacobson: Package: aptitude Version: 0.7.8-1 I follow aptitude's advice and end up with a broken (B) package: iBA libgdal20 - Geospatial Data Abstraction Library It would help to know why it is broken, e.g. if there are missing recommends, otherwise there's not much that one can do. Incidentally, the newly released 0.8 has better support for this. The curses interface says why the package is broken, I am not sure if cmdline's "why" does the same, but without knowing the source of the problem not much can be done. In any case, upgrading in the middle of a transition doesn't seem like a great idea, in those cases it's better if you choose the solution of "keep existing versions of these packages", rather than insisting in upgrading them (otherwise aptitude tries to upgrade, even if some brokenness happens). Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#693684: aptitude -t option does not work as documented; -t unstable download gets package from experimental
Hi Josh, 2016-04-20 01:50 Josh Triplett: Package: aptitude Version: 0.7.8-1 Severity: normal "man aptitude" says: -t , --target-release Set the release from which packages should be installed. For instance, “aptitude -t experimental ...” will install packages from the experimental distribution unless you specify otherwise. For the command-line actions “changelog”, “download”, and “show”, this is equivalent to appending / to each package named on the command-line; However: /tmp$ aptitude -t unstable download apt-listchanges Get: 1 http://ftp.us.debian.org/debian experimental/main amd64 apt-listchanges all 3.1 [101 kB] Fetched 101 kB in 0s (301 kB/s) /tmp$ aptitude download apt-listchanges/unstable Get: 1 http://ftp.us.debian.org/debian unstable/main amd64 apt-listchanges all 2.89 [95.7 kB] Fetched 95.7 kB in 0s (267 kB/s) The same goes for "show" and "changelog". Thanks for the report. Note for future review: this is probably the same issue as #693684, or at least should be considered at the same time. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#757028: aptitude: aptitude does not install new essential packages automatically
Control: tags -1 + pending Control: owner -1 ! Hi Stanley, 2014-08-04 17:59 Stanley Schade: Package: aptitude Version: 0.6.11-1 Severity: normal Dear Maintainer, 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. Fixed now, marking as +pending (and the sibling #555896). -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#798530: [aptitude] safe-upgrade is marking packages as manually installed
Control: tags -1 - moreinfo Control: close -1 Hi, 2016-03-08 22:47 Manuel A. Fernandez Montecelo: Control: tags -1 + moreinfo Hi Jon, 2015-09-10 11:23 Jon Ander Peñalba: Some packages are being marked as manually installed after running 'aptitude safe-upgrade', is this normal behavior? No, it's not. There have been several cases of these problems of missing auto-flags being fixed in the last few versions. Would you be able to upgrade to version 0.7.8, test it for a while, and verify if you keep seeing the same type of behaviour? If you keep seeing the behaviour, please tell me a clear test case as you did in the original report (thanks for that!). Closing now, please reopen if you can reproduce with recent versions. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#709432: aptitude not able to mount cdrom in hurd
Control: tags -1 - moreinfo help Control: close -1 Hi again, 2015-09-08 23:53 Manuel A. Fernandez Montecelo: Control: tags -1 + moreinfo help Hi Praveen, 2013-05-23 11:13 Praveen A: package: aptitude severity: important when cdrom is disconnected at boot time and reconnected after system is booted, aptitude cannot mount the cdrom when trying to install software from it. If the cdrom is connected during boot, aptitude can mount and install it. During boot time I get a message hd2 "tray is open or drive not ready" Environment is virtualbox. Probably aptitude is not the best place to file this bug. But don't know which other component to file it. Sorry, but it's been a decade or so since I tested the Hurd for a short period of time, and I am not familiar at all with problems like this. In fact, I think that I never relied on aptitude and CDs in any Debian system for more than a decade either. We are going to have more clues or extra help from somebody if this bug is to be addressed. This doesn't seem to be a bug in aptitude, since it doesn't deal with hardware drives at all, and the different methods to install (http, cdrom, etc) come from apt. After 3 years open, since nobody is working on it, it's better to close it. If/when people do care, they will open a new report (hopefully to the package actually able to fix this issue) and provide current information. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#153572: aptitude: once asked for disks, no getting out
Control: tags -1 - moreinfo help Control: close -1 2015-11-11 01:16 Manuel A. Fernandez Montecelo: Control: tags -1 + moreinfo help 2015-11-11 0:56 GMT+00:00 積丹尼 Dan Jacobson <jida...@jidanni.org>: Your mail has no bug number at all. Thanks for noticing. I don't know. I haven't used that hardware in many years. All right, no idea either. "MAFM" == Manuel A Fernandez Montecelo <manuel.montez...@gmail.com> writes: MAFM> Control: tags -1 + moreinfo help MAFM> Hi, MAFM> 2002-07-19 14:29 Dan Jacobson: Package: aptitude Version: 0.2.11.1-2 Severity: minor Once one sees "Please insert the follow disk ..." there is no getting out. There is only one choice "OK". No consideration is allowed of a user wanting to "q" quit out at this point. No mention of what to do if one wants to do something different at this point is given on the screen. MAFM> Is this still happening? I need some help, because none of the MAFM> computers that I can check have optical (much less floppy) media. Since I don't have the hardware to test and nobody followed up for 14 years, I assume that the issue is either fixed or nobody cares, so closing. If/when people do care, they will open a new report and provide current information. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#723010: libgmp-dev: please reinstate lib64gmp-dev on ppc64
Hi, 2016-04-16 13:09 GMT+01:00 Bill Allombert <bill.allomb...@math.u-bordeaux.fr>: > unarchive 723010 > reopen 723010 > quit > On Sat, Mar 12, 2016 at 01:10:44PM +, Manuel A. Fernandez Montecelo wrote: > dd >> Version: 2:6.0.0+dfsg-4 >> Hi, > > Please always CC the submitter when closing a bug, thanks! Sorry, I thought that with the email sent by -done it was enough to get you notified -- that's what most people do it in the packages that I have close contact with. >> (bug triaging on the fly while looking at other things, sorry if not >> welcome...) >> >> 2013-09-15 12:19 Bill Allombert: >> >Package: libgmp-dev >> >Version: 2:5.1.2+dfsg-2 >> >Severity: wishlist >> > >> >Hello Steve, >> > >> >Please reinstate lib64gmp-dev on powerpc until ppc64 is an official Debian >> >distribution. And maybe the same for sparc/sparc64. Otherwise, there will >> >be >> >no ppc 64bit libgmp-dev for jessie since unofficial ports only carry sid. >> >> If not before, I think that this was fixed in version 2:6.0.0+dfsg-4 >> long ago. > > Hello Manuel, > > I cannot find this package in the archive: > %rmadison lib64gmp-dev > lib64gmp-dev | 2:5.0.5+dfsg-2 | oldstable | powerpc > so I assume this bug was not fixed. > Which is too bad beacuse the unofficial ppc64 port is not reliable > currently, which is especially important when using multiarch. (the following it's an explanation of my reasoning why I closed it, I don't have any stakes in this). I thought that the issue was "solved" in a way because 2:6.0.0+dfsg-4 doesn't provide any package named lib64gmp-dev or lib32gmp-dev (removed in 2:5.1.2+dfsg-3), neither for this architecture nor for any others, and because libgmp-dev has been built successfully in recent versions of the package for ppc64. At the time you submitted another bug #714998 against the package because "You can easily check on <http://packages.debian.org/sid/libgmp-dev> that there is no libgmp-dev packages for ppc64". There was, but due to a bug in the code generating the website, it didn't appear there (according to comments in that report). Since libgmp-dev in ppc64 is it's been working for years, I expected that the problem was indeed solved for you, and that you would be able to use ppc64's libgmp-dev for the speed gains, and that this bug just laid forgotten in the BTS. Sorry for all the mess. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#820493: aptitude: does not install package from Build-Depends
2016-04-09 11:12 GMT+01:00 Dmitry Smirnov <only...@debian.org>: > On Saturday, 9 April 2016 10:57:49 AM AEST Manuel A. Fernandez Montecelo > wrote: >> That's why I was asking for the "log" of build-deps to be installed and >> so on, maybe there's a clue there. > > So what exactly do you need? Build log itself is not (very) helpful... >From "buildpackage" until it starts unpacking the package's source and compiling. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#820493: aptitude: does not install package from Build-Depends
2016-04-09 10:47 Dmitry Smirnov: Since /usr/lib/pbuilder/pbuilder-satisfydepends (pointing to pbuilder-satisfydepends-aptitude by default) uses things like: -y \ --without-recommends -o APT::Install-Recommends=false \ it's more likely that the build-dep installation was suppresed after resolving conflicts due to the transition and the implicit "-y", or something similar to that effect. Interesting, thanks. I wonder how can we identify what relationships are responsible if that's the case... That's why I was asking for the "log" of build-deps to be installed and so on, maybe there's a clue there. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#820493: aptitude: does not install package from Build-Depends
2016-04-09 10:23 Manuel A. Fernandez Montecelo: Hi, 2016-04-09 09:53 Dmitry Smirnov: On Saturday, 9 April 2016 9:44:23 AM AEST Manuel A. Fernandez Montecelo wrote: Please provide more information, like an error or the messages that it prints. There is no error message. I already provided everything I know about this problem so I have nothing to add... Dependency is just not installed silently so later package FTBFS when required package from Build-Depends can not be found. I had to use alternative "pbuilder-satisfydepends-classic" as workaround... OK. I'm pretty sure problem was introduced in 0.7.6-1 or later as everything were working fine in January 2016. With thousands of people using pbuilder in unstable continously (I among them), if this was a _general_ problem created with 0.7.6-1 (uploaded almost 1.5+ months ago) I'm quite sure that we would have more reports by now. It's more likely that this is because: (PTS for civicrm) This package is part of the ongoing testing transition known as php7.0. Please avoid uploads unrelated to this transition, they would likely delay it and require supplementary work from the release managers. On the other hand, if your package has problems preventing it to migrate to testing, please fix them as soon as possible. You can probably find supplementary information in the debian-release archives or in the corresponding release.debian.org bug. Since /usr/lib/pbuilder/pbuilder-satisfydepends (pointing to pbuilder-satisfydepends-aptitude by default) uses things like: -y \ --without-recommends -o APT::Install-Recommends=false \ it's more likely that the build-dep installation was suppresed after resolving conflicts due to the transition and the implicit "-y", or something similar to that effect. Also, possibly related: https://lists.debian.org/debian-devel/2016/04/msg00168.html Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#820493: aptitude: does not install package from Build-Depends
Hi, 2016-04-09 09:53 Dmitry Smirnov: On Saturday, 9 April 2016 9:44:23 AM AEST Manuel A. Fernandez Montecelo wrote: Please provide more information, like an error or the messages that it prints. There is no error message. I already provided everything I know about this problem so I have nothing to add... Dependency is just not installed silently so later package FTBFS when required package from Build-Depends can not be found. I had to use alternative "pbuilder-satisfydepends-classic" as workaround... OK. I'm pretty sure problem was introduced in 0.7.6-1 or later as everything were working fine in January 2016. With thousands of people using pbuilder in unstable continously (I among them), if this was a _general_ problem created with 0.7.6-1 (uploaded almost 1.5+ months ago) I'm quite sure that we would have more reports by now. It's more likely that this is because: (PTS for civicrm) This package is part of the ongoing testing transition known as php7.0. Please avoid uploads unrelated to this transition, they would likely delay it and require supplementary work from the release managers. On the other hand, if your package has problems preventing it to migrate to testing, please fix them as soon as possible. You can probably find supplementary information in the debian-release archives or in the corresponding release.debian.org bug. Since /usr/lib/pbuilder/pbuilder-satisfydepends (pointing to pbuilder-satisfydepends-aptitude by default) uses things like: -y \ --without-recommends -o APT::Install-Recommends=false \ it's more likely that the build-dep installation was suppresed after resolving conflicts due to the transition and the implicit "-y", or something similar to that effect. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#820493: aptitude: does not install package from Build-Depends
Control: tags -1 + moreinfo 2016-04-09 03:41 Dmitry Smirnov: Package: aptitude Version: 0.7.8-1 Severity: important Control: affects -1 pbuilder civicrm Package "civicrm" FTBFS in "pbuilder" because Aptitude do not install "php-gettext" package listed in civicrm's Build-Depends. I can only build CiviCRM in pbuilder if I add the following to ~/.pbuilderrc: PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-classic" Please investigate. Please provide more information, like an error or the messages that it prints. I am not able to test this right now, and otherwise this information can get lost in the next dinstall, or my mirror can contain different information. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819840: [Aptitude-devel] Bug#819840: aptitude: Segfaults if suspended and foregrounded on virtual linux console
2016-04-06 01:22 Axel Beckert: Not sure if it's gdb which is broken on armhf or something else. Did you try with valgrind, btw? In armhf unusably slow I suppose, but in x86 is usable (~1 minute). I think that you can redirect valgrind's stderr and still use curses. Other than that, I updated all my unstable today and still no crash. It occured to me that maybe your crashes are caused by some config options that you have and are not default, e.g. mini-buffer IIRC. Most of the widgets use sigc++ and threads and so on, so maybe that's the reason why you can reproduce it consistently and I don't (I use almost always the defaults, except when checking things). You can try by moving the config away and see if it still crashes or not, then enabling the options one by one (esp. the ones related to widgets/interface). If I can reproduce it there will be a better chance to fix it, otherwise I'm totally in the dark and without any clues. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819943: really should add an unforbid-version command
Control: tags -1 + wontfix Control: close -1 2016-04-06 01:07 積丹尼 Dan Jacobson: I see. Please add the @()@: To revert the action, "aptitude install " will remove the ban. To remove the forbidden version without installing the candidate version, the current @(installed, not candidate)@ version should be appended: "install =". else people will think you mean Debian's current version, not my computer's current version. Thanks. 2016-04-07 11:18 積丹尼 Dan Jacobson: reopen 819943 retitle say "currently installed version" else means "Debian's current version" thanks How about: To revert the action, "aptitude install " will remove the ban. To remove the forbidden version setting without installing the candidate version, the currently installed version should be appended: "install =". Given that the terms "current" and "candidate" related to versions of packages are core concepts of apt and aptitude and are referred as such everywhere in the interfaces and documentation, and that you've been using them for many years, I would have hoped that you'd get familiarised with them by now. Besides, these are the paragraphs that you want to change: "By default, aptitude will select the forbidden version to be the one which the package would normally be upgraded (the candidate version). This may be overridden by appending “=” to the package name: for instance, “aptitude forbid-version vim=1.2.3.broken-4”. To revert the action, “aptitude install ” will remove the ban. To remove the forbidden version without installing the candidate version, the current version should be appended: “install =”." Look at the explanation of "(the candidate version)" in the first paragraph, and the contrast beteween "candidate" and "current" of the second one. With the context, it's pretty clear that "current" can only possibly be the currently installed version of the package. Adding "installed", as you suggest in the latest spin to this bug report, is not going to make it any clearer when reading the description of "forbid-version" as a whole. Instead of highlighting the fact of "current" being ambigous when you remove the context, as you do in the latest messages, perhaps you should spend more time on re-reading the whole 3 paragraphs of documentation of this feature and see how they make sense. PS: I already asked you to making maintainers spend so much time on petty bugs which seem to be only important or documentation unintelligible to you. In particular, please stop reopening when I already made clear that I will not make any change related to this. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#820014: ITP: openscenegraph-3.4 -- Portable, high level graphics toolkit for the development high performance graphics applications.
Hi,
2016-04-05 23:21 Sebastiaan Couwenberg:
On 04/05/2016 10:37 PM, Alberto Luaces wrote:
Sebastiaan Couwenberg writes:
As maintainer of several packages that build depend on
libopen{scenegraph,threads}-dev I'm strongly in favour of a single
openscenegraph source package. Let's just prepare the transition to 3.4
in experimental.
As a maintainer with packages that build-depend on OSG, you shouldn't be
affected by this move, not until there are plans to substitute 3.2 with
3.4 (e.g. renaming the -dev package).
As a maintainer of packages on which OSG build-depends, you can be.
I don't understand what you're trying to say about dropping packages
without warning. Are you concerned that if Debian switches to 3.4 along
with all reverse dependencies, that OSG users will be inconvenienced by
not having 3.2 in Debian any more?
Debian is not only about internal reverse dependencies, users are using
OSG on their own.
In fact, the main motivation for me to maintain OSG (and I am pretty
sure that for the previous maintainer as well, and probably for Alberto
too), is to use directly OSG. I do not even use any of the rdepends at
all, except maybe that I played with flightgear a couple of times long
ago.
So there's definitely an interest in both 3.2 and 3.4 irregardless of
the internal dependencies within Debian.
Dropping reverse dependencies that don't work with 3.4 is an option to
not block the transition for too long, but that shouldn't happen without
warning when properly handling a transition.
AFAIK only Markus Wanner has tested his packages with OSG >= 3.3 and the
results were not encouraging. That just means that his upstreams need to
work on their OSG 3.4 support so we can incorporate those changes in
Debian to keep everything working.
I expect that qgis, osgearth, sfcgal, ossim & otb will all need changes
to support OSG 3.4 too. Once the 3.4 packages are in experimental the
reverse dependencies can be tested and bugs filed.
That's one of the main points of these plans -- to have both for a while
so rdepends migrate at their own pace, and when no rdeps uses 3.2 and
upstream retires support or there are plans to do it soon, remove 3.2.
I think that your OSG-dependent work is not going to be harder —quite
the opposite, since you can choose whichever stable version works or
benefits into your packages, but if that were not the case, I'm of
course open to suggestions.
Because of the interdependencies of the various GIS packages, I don't
want them to use different OSG versions. That is asking for trouble.
The GIS packages will have to migrate to the new OSG version in
lockstep, then.
As long as they don't depend on libopenscenegraph-3.4-dev, everything
should be fine.
OSG is a reverse dependency of GDAL, which requires rebuilds of its
rdeps every new upstream release. Having another OSG version in the
distribution means at least another reasonably big package that needs to
be tested every time including its rdeps that also depend on gdal. The
VTK5/VTK6 unpleasantness was a constant pain in the gdal transitions
too, I'd rather not have OSG take its place now that we're almost rid of
VTK5.
We can keep OSG-3.4 away from testing for a while, if that's what
concerns you about being a rdep of gdal. Packages not in testing are
not a problem for transitions / migrations.
Please talk to the Release Team about your plans to maintain two OSG
branches, if they don't share the concerns I expect them to have there
is nothing stopping your from packaging 3.4 separately. If they do, it
may save you some work on the separate package.
There are tons of packages with multiple APIs/ABIs, starting with the
SDL ones which I maintain, but also guile-1.8/2.0, the kde4/kde5 mess,
or oddities / inconveniences like gcc-4.9 being the still default for
some fringe architectures.
I would very much like to have only to care about one API of the SDL
packages and all its "modules", but this is not possible. Many years
after SDL-v2 being there, and unsupported by upstream since 2012, 75% of
packages still depend on SDL-1.2, there are 300~400 rdepds of
libsdl-1.2.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#743625: aptitude: internal error
Control: forcemerge 587087 743625 -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#487887: Aptitude command line "remove" no longer respects packages marked to keep
Control: tags -1 + moreinfo
(I haven't looked in detail at the problems described in the merged bug
report #693144 and long messages following it, but keeping in the loop
because of the findings and considerations regarding #487887)
Hi,
2008-06-27 04:50 Daniel Burrows:
On Wed, Jun 25, 2008 at 05:16:05AM +0800, Telemachus <telemac...@ld.net.au> was
heard to say:
On the command line, I can no longer remove a package but keep one of
the auto-installed dependencies. I could swear that I used to be able
to do this:
aptitude purge mpd libshout3+
Maybe it depends on the specific examples, but this works for me with
the following example.
I cannot try with libshout3, because it has other rdeps in my system so
it doesn't get removed anyway, but with libnfs8:
# aptitude -s purge mpd
The following packages will be REMOVED:
libadplug-2.2.1-0v5{u} libbinio1v5{u} libnfs8{u} libwildmidi-config{u}
libwildmidi1{u} mpd{p}
0 packages upgraded, 0 newly installed, 6 to remove and 184 not upgraded.
Need to get 0 B of archives. After unpacking 2,160 kB will be freed.
Note: Using 'Simulate' mode.
Do you want to continue? [Y/n/?] n
Abort.
# aptitude -s purge mpd libnfs8+
libnfs8 is already installed at the requested version (1.9.8-1)
libnfs8 is already installed at the requested version (1.9.8-1)
The following packages will be REMOVED:
libadplug-2.2.1-0v5{u} libbinio1v5{u} libwildmidi-config{u} libwildmidi1{u}
mpd{p}
0 packages upgraded, 0 newly installed, 5 to remove and 184 not upgraded.
Need to get 0 B of archives. After unpacking 1,905 kB will be freed.
Note: Using 'Simulate' mode.
Do you want to continue? [Y/n/?] n
Abort.
I thought this used to work as well. But I think I've found the
problem in the code, and it goes back to at least 2002. Can you verify
that this was working before? (because I could swear I remember using
it) This may be due to the changes last year in how automatic packages
are handled (although I can't see how). For my own future reference,
the problem is that I use an action group to defer computation of, e.g.,
unused packages, until I'm done applying all the command-line actions.
That's probably good overall, but it does mean that install commands
won't cancel unused-removals since the unused-removal hasn't taken
effect yet.
Oh, the other thing that I can see that might have affected this is
the change that caused the "install" operation on a package to not
affect its automatic flag unless the package was already installed.
I don't know if Daniel Burrows had changed something to make this work
at the time without closing the bug (doesn't look like it, due to the
bug merged later), if something has changed later on fixing this problem
(e.g. in the 0.7 series), if it's an unknown change in libapt that now
causes this to work (e.g. the many changes of apt 1.1), or if it's
erratic and not really fixed.
But in any case...
Your suggestion seems like a good idea, but I'm not sure what the
follow-on consequences would be if I just slapped it in right now.
However, you can get a similar effect by doing:
# aptitude remove mpd "libshout3"
I think that this is the best way to solve the situation -- to mark the
packages as manually installed, either within the same action or, if it
doesn't work for some reason (tries to be removed before being marked as
manually installed), in a previous action.
If the package that one wants to preserved is (kept) installed but
marked as automatically installed, it can be removed as a result of the
next run, for example.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#301100: aptitude: 'justification' field
Control: tags -1 - moreinfo Control: close -1 2016-04-05 20:50 Manuel A. Fernandez Montecelo: So in principle I think that this request is basically fulfilled, not closing yet in the case that there's some comment. Failure to deliver the message, so closing now. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#301100: aptitude: 'justification' field
Control: tags -1 + moreinfo Hi Dann, 2005-03-23 20:04 dann frazier: Package: aptitude Version: 0.2.15.8-1 Severity: wishlist I'd like to see a feature in aptitude that allows for "justification" tags for packages on a system. For instance, on a multi-admin system, it would be nice for admin1 to be able to aptitude install a package, and add a note justifying its existance. For example: # aptitude install docbook-utils \ --justification="User allison needs this for her tech-writing class, we can remove it at the end of spring semester 2005." aptitude when then store this justification for the docbook-utils package and for all of the dependencies it drags in (which should probably have an automatic justification added that refers to the docbook-utils justification, and classifies itself as a dependency). When cleaning up the system, aptitude could be queried to determine why certain packages are installed. I could imagine people using this text field for rfc822 formatted data, and use that for categorization. Example fields might be: Users: bobm, brett, dannf Courses: CS143 Purgeable: No Pulled-in-by: python2.4 Installed-by: dannf Upgrade-restrictions: Don't upgrade!! new version breaks abi w/ user app User removals, course cancellations, etc, could all trigger cleanup events. aptitude seems like a logical place for this feature, since it already seems to track why some packages have been installed implicitly. Even if you don't have the time/interest to implement this feature yourself, please let me know if you think aptitude is a good place for it. ... and 10+ years later, a reply to this. The following is less fancy than it was requested, but I think that user tags present for a few years can be used for this, only that the spaces are not allowed in the tags (they were allowed once, but caused problems and were removed since). aptitude --add-user-tag Allison-needs-it docbook-utils aptitude search -F '%p %T' '?user-tag(.*)' etc. man aptitude for more info. Of course, even if user-tags in aptitude are simple, the tags applied to can be stored in another file/DB easily, and then attach the other data. So in principle I think that this request is basically fulfilled, not closing yet in the case that there's some comment. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#568302: prompt [Y/n/q/1/2/3/4/5/6...] if necessary
Control: tags -1 + wontfix Control: close -1 2010-02-04 16:33 jida...@jidanni.org: DB> The one thing that might make sense would be to add an ellipsis, DB> [Y/n/q/?/...] [Y/n/q/.../?] DB> assuming that users would actually read that as "there are more DB> options, press '?' to view them" and not "enter three periods to do DB> something." I kind of like "[Y/n/q/.../?]", but searching across all of the Debian source packages, doesn't seem to be a common pattern to have: https://codesearch.debian.net/perpackage-results/y%2Fn%2F/2/page_0 (only looked to the first few pages) Nothing matches "y/n/..." in real code: https://codesearch.debian.net/results/y%2Fn%2F%5C.%5C.%5C./page_0 "y/n.*/\?" is not very popular either: https://codesearch.debian.net/results/y%2Fn.*%2F%5C%3F/page_0 I don't recall seeing examples of this in other tools, either. So in the absence of evidence that this is a good thing to add, no seconds or more opinions for many years, I think that it's better to stay as we are. Closing the bug after many years gathering dust. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#592836: hotkey for adding package without "recommends" list?
Hi Harald, 2010-08-13 08:17 Harald Dunkel: Package: aptitude Version: 0.6.3-3 Severity: wishlist It would be nice to have separate hotkeys to install a package with our without the recommended packages. Changing this in the preferences again and again is pretty painful. Maybe the '&' could be used to ignore the recommended packages, while '+' includes all recommended packages as before. Perhaps the barely visible 'I' can be used for this, I don't know how well it works in practice. (It probably should be added to menus and maybe needs better documentation). Also, you can use '+' and then selectively remove/purge the Recommends planned to be installed, I think that it shuold work fine, and in most cases would be less taxing than editing the file. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#707662: [Aptitude-devel] Bug#806770: aptitude: Command parameter to restore /etc/ configuration files easily
Note: #707662 and #806770 are related, but not sure if should be merged, adding this note for future triaging. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#820116: aptitude-doc-en: downgrades are not documented in "Costs in the interactive dependency resolver"
Control: severity - wishlist Control: tags -1 + help 2016-04-05 16:25 Vincent Lefevre: Package: aptitude-doc-en Version: 0.7.8-1 Severity: normal Downgrades are not mentioned at all in Section "Costs in the interactive dependency resolver" of the aptitude manual. Since they are not supported by Debian, one has the impression that they cannot be proposed, while they can be proposed in practice. In particular, it should be documented where they appear in Table 2.2 on cost levels. There are many things not supported, like using unstable or experimental, or upgrading packages from oldstable to unstable, or from a random point of snapshot.d.o to the present, than neither aptitude nor other tools warn about. Some of these combinations are not known to aptitude or the rest of package management tools, they cannot know if the currently installed package is from the last stable or from the stable 10 years ago. Even some of the upgrade problems from one stable version to the next are only tested during the freeze, if at all. Also, whether pkg-a_v1.3 is not safe to upgrade from pkg-a_v1.2 because it's an ABI breakage is not known to these tools, and happens far more often and causes many more problems than downgrades. I downgrade packages many times, if only for testing aptitude bugs, and I often experience far more problems with day-to-day upgrades than with downgrades, so YMMV. I don't think that it's particularly useful to mention/highlight downgrades, since these are not supposed to be seen by users using stable and upgrading to the next stable, which is the only scenario that Debian really supports. Users who don't do this and mix versions in which aptitude can suggest downgrades are on their own and should know how to deal with them. In any case, I don't plan to work on this issue, tagging +help in the case that somebody feels like it. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#762932: aptitude Bug#762932: With Aptitude::ProblemResolver::SolutionCost=removals, aptitude full-upgrade chooses to downgrade a package
2016-04-05 15:51 GMT+01:00 Vincent Lefevre <vinc...@vinc17.net>: > What's the problem with offering this choice to the user? The problem is that I have to spend time implementing this request, and that: a) I think that there are many other things worth spending my time (even within the realm of aptitude) rather than implement this feature, and b) it means complicating even more the situation and complexity of with aptitude's resolver, which I feel that it's unhelpful in general You seem to ignore these very important factors in all your replies to aptitude's bug reports. Time to develop aptitude is not infinite, incrementing complexity of programs doesn't always create a positive net result, and discussing repeatedly these issues ad nauseam does not help the development of aptitude. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#644544: aptitude does not fully update suggest/recommend dependency changes on conflict resolution
Control: tags -1 - moreinfo Control: close -1 Hi, 2016-01-14 00:42 Manuel A. Fernandez Montecelo: Control: tags -1 + moreinfo unreproducible Hi Yann, 2011-10-06 21:19 Yann Dirson: Package: aptitude Version: 0.6.4-1 Severity: normal After pulseaudio migrated to testing with an upgrade from "suggests: rtkit" to a "recommends", higging "U" selects rtkit for install, with flag "auto-installed". So far, OK. There are a couple of conflicts, and I select a resolution that "keeps" pulseaudio - to the version that has the "suggests", that is. But rtkit is kept, listed as "piA", but with the "reason" panel listing no recommends or depends, but just the suggests. I think that the problem of the case above lies in ambiguity of interpreting what the user wants. In this situation, if you Undo (Control-U), it would Undo previous actions, including reverting the selection to install rtkit automatically. If you simply fiddle with packages back and forth, aptitude doesn't exactly know which ones you installed willingly and which you didn't. One interpretation is that maybe you liked the decision to install rtkit, and just decided to not install the dependency after all. It might also happen that other packages that you had installed recommended rtkit, so once selected to install, it will not be removed automatically. It would be nice to know what happened if/when you pressed 'g' for the preview, I guess that it would have deselected rtkit. Trying to reproduce this with a random set of packages (lib4store0-dbgsym and lib4store0), if I press "+" on the former the latter gets "piA", same as in your case. If then I press "-" on lib4store0-dbgsym to keep it uninstalled, lib4store0 gets immediately deselected (== kept uninstalled). So I think that this got somehow fixed in the interim. Can you still reproduce it? So I am going to close this report now, please reopen if you experience it again in the future. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#731318: aptitude: keeps switching a package between architectures on safe-upgrade
Control: tags -1 - moreinfo Control: close -1 2016-03-10 10:42 Manuel A. Fernandez Montecelo: 2016-03-09 22:45 GMT+00:00 Shai Berger <s...@platonix.com>: Hi Manuel, On Tuesday 08 March 2016 00:52:36 Manuel A. Fernandez Montecelo wrote: Did you keep observing this problem in recent years/releases? I'm not sure when was the last time I saw the problem; anyway, since the last major ABI transitions (gcc 5 together with KDE5, IIRC) I have not updated the system regularly and so I cannot comment. OK, thanks for the feedback! So I will close the report now. Please reopen or open a new one if you see this happening in the future. I am sure that somebody else will do, if not you :) Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819840: aptitude: Segfaults if suspended and foregrounded on virtual linux console
Hi, 2016-04-05 14:41 GMT+01:00 Axel Beckert <a...@debian.org>: > Hi Manuel, > > Manuel A. Fernandez Montecelo wrote: >> I was trying to say that the functions whose name appear >> (vsnprintf_chk and the other _chk) are not part of >> aptitude/apt/cwidget, and other of the functions in the backtrace >> don't show names, so if you have of you have dbgsym of aptitude >> installed (as the message of "loading symbols" indicate), it's not >> part of aptitude. >> >> If you install libcwidget*-dbg, libapt*-dbg and any other -dbg of the >> "aptitude software stack" (sigc++, boost, libc6...) maybe something >> appears in that backtrace. > > aptitude-dbgsym and libc6-dbgsym was already installed. I've installed > libcwidget*-dbg, libapt*-dbg, libsigc++-*-dbgsym and libboost-dbg > today. > > But now I can't reproduce the segfault anymore, at least on amd64. And > the backtrace from the existing segfaults hasn't changed much -- if at > all -- since then: > > (gdb) bt > #0 0x7fe2861e5973 in ?? () > #1 0x in ?? () > #2 0x00011839 in ?? () > #3 0x0800 in ?? () > #4 0x7fe287fa8b0c in ___vsprintf_chk (s=0x7ffd08eb4380 "", > flags=-1416311776, slen=140724753089664, format=0x564aab94cc10 > "\260R\266\252JV", > args=0x564aa764dc78, args@entry=0x7ffd08eb44c8) at vsprintf_chk.c:85 > #5 0x7fe287fa8a5d in ___sprintf_chk (s=, flags= out>, slen=, format=) at sprintf_chk.c:31 > #6 0x564aa764dc78 in ?? () > #7 0x564aab94cc20 in ?? () > #8 0x7fe289d335d4 in cwidget::toplevel::eventq () from > /usr/lib/x86_64-linux-gnu/libcwidget.so.3 > #9 0x0080 in ?? () > #10 0x7ffd08eb4b20 in ?? () > #11 0x564aab94cc10 in ?? () > #12 0x000d in ?? () > #13 0xfffc in ?? () > #14 0x7fe288af204f in pthread_cond_wait@@GLIBC_2.3.2 () at > ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183 > #15 0x in ?? () > (gdb) > > Will try the same at home on the Raspberry Pi's console again, too. Seeing that cwidget's events are involved, with the hairiness of cwidget's own threads implementation and sigc++ mixed, and seeing that libsigc++-2.0 was updated recently, I am wondering if it has something to do with that. I have the same versions, though, so I should be able to reproduce it if it's happening often -- altough this kind of weirdness is typical of issues involving threads. I very rarely use Linux virtual consoles and aptitude. I don't know if you use them enough to be able to tell if it's a behaviour that only started recently while not happening for years, or simply you don't use it often enough to see if it was only present since recently? Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#762932: aptitude Bug#762932: With Aptitude::ProblemResolver::SolutionCost=removals, aptitude full-upgrade chooses to downgrade a package
2016-04-05 15:21 GMT+01:00 Vincent Lefevre <vinc...@vinc17.net>: > On 2016-04-05 13:42:49 +0100, Manuel A. Fernandez Montecelo wrote: >> So after studying this for a while, this is normal behaviour when using >> "removals", which only pays attention to minimise the number of >> removals, no matter any other considerations like upgrades, downgrades, >> or prefering packages with higher priorities. > > Well, there are two issues: > > 1. The documentation /usr/share/doc/aptitude/html/en/ch02s03s04.html > does not mention downgrades at all. So, since downgrades are not > supported by Debian, the user is right to assume that downgrades > will never be proposed. If aptitude proposes downgrades, then this > MUST be documented. > > 2. There should be a way to avoid downgrades completely. Not going to happen, as explained in previous messages. > I think that this is not a good excuse. The system should offer a way > to exclude downgrades whatever the context. You think that and I don't think so, that's why is both a wishlist and a wontfix. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#651947: aptitude has buggy dependency resolution.
Hi, 2011-12-13 08:55 dE .: Package: aptitude Version: 0.6.4-1.2 Severity: important Aptitude suggests removal of 284 packages in favor of keeping update-inetd at version 4.40 which it complains as being held, which is not true. Corresponding attachment aptitude_bug. As noted in another reply to this bug report, aptitude doesn't complaint about update-inetd being held as in "having a hold", but on being "kept back" (i.e. not considered for upgrade) in the given resolution attempt. Also, aptitude states perl-base: Conflicts: update-inetd, but this's not written in aptitude show perl-base. As noted in yet another reply, perl (5.14.2-6) added a conflicts with "update-inetd (<< 4.41)". apt-get, Synaptic and other apt implementation's behavior is to upgrade update-inetd instead as show in file apt-get_output. So this is indeed the problem, aptitude usually offers solutions involving the removal of many packages before others in which update-inetd is upgraded. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819840: aptitude: Segfaults if suspended and foregrounded on virtual linux console
2016-04-05 12:26 GMT+01:00 Axel Beckert <a...@debian.org>:
> Hi Manuel,
>
>> >This does not happen, if
>> >
>> >* if tried inside an xterm
>> >* if just TERM is set to "linux", but the terminal is no virtual linux
>> > console, i.e. "env TERM=linux aptitude" does not exhibit the issue.
>>
>> What's "TERM" in the vt console?
>
> linux
>
>> Mine is "linux", and as you noted, it works fine.
>
> I didn't say that. I just said that in a non-virtual-console (i.e. an
> xterm), "env TERM=linux aptitude" does not crash. I didn't say, that
> TERM=linux in general prevents the crash. It's just not sufficient to
> provoke the crash.
Ah, OK, I misunderstood. I was testing those in Linux virtual console
(more details below). I hoped that your default in virtual console
was not "linux" so I could reproduce it and see what was going on.
> But if you don't get the crash on the vt console, I wonder what else
> is needed to provoke the crash as I was able to reproduce it on two Sid
> machines with different architectures out of the box.
>
> Is there a chance that LC_CHAR is involved? That's usually set to
> something with .UTF-8 at the end for me, either en_{GB,US,DK}.UTF-8 or
> C.UTF-8.
# env | egrep '^(TERM|LC|LANG)'
TERM=linux
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
Setting "LANG=C.UTF-8" also doesn't trigger the crash when starting
aptitude, control-z, fg.
>> If I "unset TERM" or set it to the empty string, aptitude refuses to
>> start ("Error opening terminal: unknown"). If I set it to "linux",
>> "xterm" or "xterm-256color" it works fine. "vt100" works fine, but
>> no colours.
>
> Did you try these variants inside an terminal emulator under X or on a
> Linux virtual console?
I had tested all of the above in the virtual console; and then I tried
some of them also in xterms (xterm and konsole in particular), just as
a matter of trying to see if it was triggered there.
>> In any case, I couldn't get it to crash by suspending and restoring.
>
> Can you cross-check if you really had the same environment (vt
> console)? It seems there may have been some misunderstanding wrt. just
> setting $TERM vs the really used type of terminal. The latter matters,
> the former is either irrelevant or at least not sufficient.
So yes, I was testing all of the above in the virtual consoles.
>> None of the functions which name appears are from aptitude, cwidget or
>> apt, unfortunately.
>
> Oops. So this might be somewhere deeper down?
Not sure.
I was trying to say that the functions whose name appear
(vsnprintf_chk and the other _chk) are not part of
aptitude/apt/cwidget, and other of the functions in the backtrace
don't show names, so if you have of you have dbgsym of aptitude
installed (as the message of "loading symbols" indicate), it's not
part of aptitude.
If you install libcwidget*-dbg, libapt*-dbg and any other -dbg of the
"aptitude software stack" (sigc++, boost, libc6...) maybe something
appears in that backtrace.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#762932: aptitude Bug#762932: With Aptitude::ProblemResolver::SolutionCost=removals, aptitude full-upgrade chooses to downgrade a package
Control: severity -1 wishlist
Control: tags -1 + wontfix
Hi,
2015-09-21 12:43 Manuel A. Fernandez Montecelo:
If I ask aptitude to upgrade a package and the dependencies cannot be
fulfilled (as explained above for unstable), it is natural that aptitude
tries to come up with weird solutions. That includes downgrading. So
if I want to upgrade the version of 10 packages in unstable, and they
depend on the new libstdc++6, and there is one dependency from
experimental (libmad1.1) which had been compiled against the old
libstdc++6 while there is "libmad1.0" in unstable compiled against the
new libstdc++6, is is natural and reasonable that aptitude offers me a
downgrade -- it is the easiest way to satisfy upgrading 10 packages and
just downgrading one, without removals or other also negative effects.
I am the master juggling blades, I am using unstable and experimental, I
tweak the resolver parameters to my heart's content, I ask to upgrade
things in the middle of a terribly complicated transition, and aptitude
does not treat me like as an idiot: it *offers* me a *possible solution*
to the conflicting states after an action that I *requested*, that
includes downgrades. It didn't break my system just casually like
sitting there on the filesystem, or while doing "aptitude update", or
when reinstalling a package, or upgrading from one stable to the next.
I don't see anything wrong with that, that is part of the core function
of aptitude, to put me in charge. In fact, I would be disappointed if
aptitude didn't offer me slightly awkward solutions that would fit the
bill sometimes.
[...]
According to the documentation, "removal" means: "Counts the number of
packages that the solution removes".
I assume that this works as intended and doesn't like solutions like
removing obsolete libraries (of which there are lots lately, specially
after the *v5 mass-renaming for example and with gcc-5 adding lots of
"breaks" to some packages), so maybe it doesn't have better options (in
terms of "resolver costs") than to downgrade.
So after studying this for a while, this is normal behaviour when using
"removals", which only pays attention to minimise the number of
removals, no matter any other considerations like upgrades, downgrades,
or prefering packages with higher priorities.
Using the default ("safety, priority") puts dangerous actions like
downgrades or changing to other non-default versions in a different
"safety" level, so they are not offered as the first solutions.
"safety, removals" can probably be used to avoid having downgrades while
minimising removals.
Even in this case, the fact that it was offering downgrades instead of
upgrades at the time when this was reported was because of the chaos
caused by the GCC-5/C++11 transition (the worst in a decade).
So only when the combination of all these unlikely cases happen
simultaneously, downgrades are offered. Downgrades are highlighted and
have to be confirmed explicitly by the sysadmin.
It's working as documented and not a bug.
By default it probably does, because I can't remember if I was ever
offered a downgrade. Again, you were using non-default options.
Note also about full-upgrade:
full-upgrade
Upgrades installed packages to their most recent version, removing
or installing packages as necessary. This command is less
conservative than safe-upgrade and thus more likely to perform
unwanted actions. However, it is capable of upgrading packages
that safe-upgrade cannot upgrade.
So, in short, if you don't want surprises, probably you should use
"safe-upgrade" and not "full-upgrade -y".
[...]
No, the best solution is to require the user to solve the problem
manually.
Well, it idoes, it offered you a solution, as far as I am aware, for
you to decide. Only when passing "-y" it didn't, and rightly so.
Ditto.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819943: really should add an unforbid-version command
2016-04-05 04:09 積丹尼 Dan Jacobson: So indeed in the man page To remove the forbidden version without installing the candidate version, the current version should be appended: "install =". is utterly totally wrong. Please remove it. # aptitude search --disable-columns -F '%c%a%M %p %v %V' debian-keyring i debian-keyring 2016.01.20 2016.03.22 # aptitude forbid-version debian-keyring=2016.03.22 No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 185 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. # aptitude search --disable-columns -F '%c%a%M %p %v %V' debian-keyring iF debian-keyring 2016.01.20 2016.03.22 # aptitude install debian-keyring=2016.01.20 debian-keyring is already installed at the requested version (2016.01.20) debian-keyring is already installed at the requested version (2016.01.20) No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 184 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. Current status: 185 (+1) upgradable. # aptitude search --disable-columns -F '%c%a%M %p %v %V' debian-keyring i debian-keyring 2016.01.20 2016.03.22 Q.E.D. I.e., works as intended and documented. set debian-reference-en aptitude forbid-version $@ aptitude search $@ #shows F aptitude install $@=2.59 # abort with n, we don't want to install it. aptitude search $@ #still F Exactly, because by saying "n" you didn't complete the action to "remove the forbid on that version". Installing a version that it's already installed is harmless, so you don't need to say no. So again it works as expected and documented. You wouldn't want the state modified if you reply "no" to a question to modify the state, that would be a much more serious bug. Please change it to Currently there is no way to remove the forbidden version without installing the candidate version. Or better Currently there is no way to remove the forbidden version NOTATION without installing the candidate version. Nope. Also, more in general, it would be useful if you stop reporting duplicate bugs reported only weeks ago (often by you, e.g. 773023 and 804103) or looking for unexisting problems, then discussing to death and looking for further things to modify in the same bug report so they can never be closed. That keeps maintainers wasting time chasing and handling bug reports rather than working on more important problems, and wasting time repeating again and again the reasons why they don't want to change things that you suggest. If the reason why you don't try to avoid duplicate bugs is "but... but... there are too many!", consider whether your actions submitting dozens of inane bugs or duplicates to aptitude without searching for them is contributing to piling lots of bugs that then are difficult to triage and search; or if they are of any benefit to the advancement of aptitude as a whole to deal with these inane and duplicate reports rather than working on more important issues. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819943: really should add an unforbid-version command
Control: severity -1 wishlist Control: tags -1 + wontfix Hi, 2016-04-04 03:05 積丹尼 Dan Jacobson: Package: aptitude Version: 0.7.8-1 Today I will inspect the how hard it is to just simple reverse the action of # aptitude forbid-version somepackage so we are back to the state before we did it. The man page says To revert the action, "aptitude install " will remove the ban. To remove the forbidden version without installing the candidate version, the current version should be appended: "install =". Well I think you really should an unforbid-version command. The documentation was improved after another recent request of yours (duplicate, actually), #773023. forbid-version Forbid a package from being upgraded to a particular version, while allowing automatic upgrades to future versions. This is useful for example to avoid a known broken version of a package, without having to set and clear manual holds. By default, aptitude will select the forbidden version to be the one which the package would normally be upgraded (the candidate version). This may be overridden by appending “=” to the package name: for instance, “aptitude forbid-version vim=1.2.3.broken-4”. To revert the action, “aptitude install ” will remove the ban. To remove the forbidden version without installing the candidate version, the current version should be appended: “install =”. I think that it will explains quite clearly how to achieve what you want, if you really want to undo "forbids". Also the man page should say if only one version can be forbidden or more. It only mentions a single version that can be forbidden throughout the 3 paragraphs, and implies that forbidding several version is a job for "hold". This seems to be sufficiently clear for mostly everybody, since there are no duplicates about the issue in the last few years but yours. Also one thinks I could just use forbid-version=0 to clear it, but that is not a current version of that package. And # aptitude forbid-version package1 package2 package3 ... package20 will require an enormous amount of work to reverse, digging up each version number... forbid-version is to mark a specific version of a package that you are quite sure that you don't want to install, e.g. with a RC bug or a problem that affects your systems badly. Whenever a new version is available, the system will happily upgrade to new versions, e.g. with dist-upgrade. So, as the doc explains quite clearly, forbid-version is intended as a shortcut for "temporary holds" on a specific version which self-destroy when a new version is available and the sysadmin requires an upgrade of the system, a set of package or a single package. If you find that you're using forbid-version and need to revert it quite often _without installing the new version of the packages already available at the same time_, perhaps you would like to use only "hold" (and its corresponding "unhold"), because the use that you are asking is not what forbid-version is intended for and you are actually using it as a "hold". Blurring the lines even more between forbid-version and hold is IMO not a very useful thing to do in general, and not cost-effective. tl;dr: if you are not happy with the shorcut and semantics of "forbid", just use the more general "hold". OK, let's try # aptitude install xserver-xorg-video-cirrus=1:1.5.3-1+b1 We will very likely encounter some "The following actions will resolve these dependencies: Remove the following packages:" questions which we will very probably answer "n", never reaching the point where supposedly the forbid-version will be erased without installing the package before quitting! And, when you think about it # aptitude install xserver-xorg-video-cirrus= means the same as # aptitude install xserver-xorg-video-cirrus so if one didn't want to install the package one would answer "n" when asked so never reaching the step where ... anyway one big no-op and the forbid-version stays. It works exactly as intended... install will attempt to install a new version. If you don't want to install a new version after all, having a "forbid" on a version that you don't want installed _yet_ is harmless; so you don't need to remove the "forbid" until/unless you are sure that you want to install that version. Catch-22. That there are conflicts when installing a version of a package, which in turn cause the packages to be suggested to be removed or other actions (a bunch of them upgraded at the same time, for example) is completely orthogonal to the question at hand. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819942: command line mode war against TERM=dumb
Control: forcemerge 817276 -1 Hi, 2016-04-04 02:58 積丹尼 Dan Jacobson: Package: aptitude Version: 0.7.8-1 I am using a emacs shell-mode window. # aptitude install xserver-xorg-video-cirrus=1:1.5.3-1+b1 aptitude cannot run in ncurses mode with terminal type "dumb" So must use: # TERM=linux aptitude install xserver-xorg-video-cirrus=1:1.5.3-1+b1 # TERM= aptitude install xserver-xorg-video-cirrus=1:1.5.3-1+b1 # unset TERM; aptitude install xserver-xorg-video-cirrus=1:1.5.3-1+b1 You don't allow TERM=dumb (bug) but allow no TERM at all (fine). $ TERM= aptitude Error opening terminal: unknown. That is fine. But that is ncurses mode, and what I was doing wasn't. This looks like a duplicate of #817276, merging. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819840: aptitude: Segfaults if suspended and foregrounded on virtual linux console
Hi Axel,
2016-04-03 00:29 Axel Beckert:
Package: aptitude
Version: 0.7.8-1
Hi,
aptitude segfaults under the following circumstances:
1. Log in as root on a Linux virtual console, i.e. after pressing
Ctrl-Alt-F1.
2. Start aptitude in TUI mode, i.e. without any options or parameters.
3. Press Ctrl-Z to suspend aptitude.
4. Enter "fg" on the commandline and press Enter to bring aptitude back
to the foreground.
5. Segfault.
This does not happen, if
* if tried inside an xterm
* if just TERM is set to "linux", but the terminal is no virtual linux
console, i.e. "env TERM=linux aptitude" does not exhibit the issue.
What's "TERM" in the vt console?
Mine is "linux", and as you noted, it works fine. If I "unset TERM" or
set it to the empty string, aptitude refuses to start ("Error opening
terminal: unknown"). If I set it to "linux", "xterm" or
"xterm-256color" it works fine. "vt100" works fine, but no colours.
In any case, I couldn't get it to crash by suspending and restoring.
I am no expert in TERM, so I'm not sure which other values are possible
and which ones are correct.
Unfortunately I was not able to reproduce the issue under gdb
directly. But this is the backtrace I got out of the core dump:
Reading symbols from /usr/bin/aptitude-curses...Reading symbols from
/usr/lib/debug/.build-id/17/b0aa382e98a7c74b766fe389e4e2c494dd8cce.debug...done.
done.
warning: core file may not match specified executable file.
[New LWP 6201]
[New LWP 6202]
[New LWP 6203]
[New LWP 6204]
[New LWP 6219]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `aptitude'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x7fe2861e5973 in ?? ()
[Current thread is 1 (Thread 0x7fe28a8d1780 (LWP 6201))]
(gdb) bt
#0 0x7fe2861e5973 in ?? ()
#1 0x in ?? ()
#2 0x00011839 in ?? ()
#3 0x0800 in ?? ()
#4 0x7fe287fa8b0c in ___vsprintf_chk (s=0x7ffd08eb4380 "", flags=-1416311776,
slen=140724753089664, format=0x564aab94cc10 "\260R\266\252JV",
args=0x564aa764dc78, args@entry=0x7ffd08eb44c8) at vsprintf_chk.c:85
#5 0x7fe287fa8a5d in ___sprintf_chk (s=, flags=,
slen=, format=) at sprintf_chk.c:31
#6 0x564aa764dc78 in ?? ()
#7 0x564aab94cc20 in ?? ()
#8 0x7fe289d335d4 in ?? () from /usr/lib/x86_64-linux-gnu/libcwidget.so.3
#9 0x0080 in ?? ()
#10 0x7ffd08eb4b20 in ?? ()
#11 0x564aab94cc10 in ?? ()
#12 0x000d in ?? ()
#13 0xfffc in ?? ()
#14 0x7fe288af204f in pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:183
#15 0x in ?? ()
(gdb)
None of the functions which name appears are from aptitude, cwidget or
apt, unfortunately.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#266061: Reason inference for unused removals is confused by ORed/virtual dependencies
Control: tags -1 + pending 2004-08-16 16:07 Daniel Burrows: Package: aptitude Version: 0.2.15.6-1 Severity: normal If I have both aptitude-doc-cs installed automatically and remove aptitude, no dependency information is shown for aptitude-doc-cs (which gets garbage-collected), presumably because it was being held on the system via a virtual dependency. Upon removal of aptitude (which is forbidden now, but I disabled the check for testing), this is the explanation given for aptitude-doc-en (marked for removal, because of "pkg_unused_removed"): === aptitude-doc-en (remove, 0.7.8-1) was installed automatically; it is being removed because all of the packages which depend upon it are being removed: * aptitude (remove, 0.7.8-1) recommends aptitude-doc-en | aptitude-doc (provided by aptitude-doc-cs 0.7.8-1, aptitude-doc-en 0.7.8-1, aptitude-doc-es 0.7.8-1, aptitude-doc-fi 0.7.8-1, aptitude-doc-fr 0.7.8-1, aptitude-doc-it 0.7.8-1, aptitude-doc-ja 0.7.8-1, aptitude-doc-ru 0.7.8-1) === However, for aptitude-doc-cs there is/was no information shown. I changed the implementation so it also takes into account reverse dependencies of the virtual packages provided by the package under inspection (which is "aptitude-doc"). So now this also shows identical information, even when it's through a virtual package: === aptitude-doc-cs (remove, 0.7.8-1) was installed automatically; it is being removed because all of the packages which depend upon it are being removed: * aptitude (remove, 0.7.8-1) recommends aptitude-doc-en | aptitude-doc (provided by aptitude-doc-cs 0.7.8-1, aptitude-doc-en 0.7.8-1, aptitude-doc-es 0.7.8-1, aptitude-doc-fi 0.7.8-1, aptitude-doc-fr 0.7.8-1, aptitude-doc-it 0.7.8-1, aptitude-doc-ja 0.7.8-1, aptitude-doc-ru 0.7.8-1) === So marking as +pending. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819002: aptitude: can't remove user tag by the 'aptitude remove-user-tag tag package' command
Control: tags -1 + pending Hi Vladislav, 2016-03-22 17:31 Vladislav: Package: aptitude Version: 0.7.8-1 Severity: important Dear Maintainer, * What led up to the situation? I added the user tag to package meld, than tried to remove it. * What exactly did you do (or not do) that was effective (or ineffective)? 'aptitude --add-user-tag meld install meld' 'aptitude remove-user-tag meld meld' Last command must remove the user tag (according to manual), but this does not worked. Then I tried: 'aptitude --remove-user-tag meld reinstall meld' This also does not worked. * What was the outcome of this action? Nothing happens. * What outcome did you expect instead? Removing user tag meld from package meld. This will be fixed in the next version, marking as +pending, thanks for the report. If it still doesn't work after that, please reopen (or open a new report if it's related to user-tags but a different problem). Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#651410: aptitude: in dependency resolutions, aptitude should favor library removal
2016-03-22 13:27 Vincent Lefevre:
Hi Manuel,
On 2016-03-18 15:15:11 +, Manuel A. Fernandez Montecelo wrote:
2011-12-08 11:53 Vincent Lefevre:
> The second solution is OK, as only a library package is removed, and
> such a package with no dependencies on it is useless.
Not necessarily. The library might have been installed by hand for
extra sound plugins or other codecs, mesa libraries not strictly needed
according to the dependency system but worthy to have in that machine,
dvd decoding, or to support something installed in the system outside of
the package managers (e.g. a special version of a webserver or other
software, compiled in /usr/local, mounted through NFS, etc).
If it's not really installed for a special purpose, should have been
marked as automatically installed to get rid of it sooner.
All my libraries are automatically installed. However some
automatically installed packages are not marked as automatically
installed. Perhaps due to some aptitude bug. I had reported a
bug in the past:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720386
Yeah, there were dozens of bugs like that. Some were addressed a while
ago and some are WIP, but still a few/many problems still remain.
Now, the fact that a library was automatically installed doesn't
mean that it is safe to remove. For instance:
1. The user installed libfoo-dev to compile a program using
library foo. This automatically installs libfoo. It may also
happens that both were already installed for some other reason
(e.g. as a dependency).
2. The user compiles and installs his program.
3. After an upgrade, there is an ABI incompatibility in library foo,
so that libfoo-dev now depends on libfoo3. At this point, there is
no longer a dependency on libfoo, so that it will automatically be
removed.
Of course, the user may have marked package libfoo as manually
installed, but I wonder whether most users do so. It is not always
obvious to know which library packages were needed.
Package manager tools don't have any knowledge of the system outside of
the dependencies, so if there are local software needing packages (be
that a library or any other package/command, the same bad effects happen
if other packages get removed) only the user can act upon that.
About your phrase if "a library was automatically installed doesn't mean
that it is safe to remove", seems to argue about the very title of this
report and what you were saying in it ("The second solution is OK, as
only a library package is removed, and such a package with no
dependencies on it is useless"); and goes in favour of what I was saying
in the previous message -- I don't think that libs should be favoured to
be removed in conflict resolutions, as originally proposed.
(Besides, deciding which packages are libraries is not trivial nor
accurate, there are many packages badly classified as section "libs"
which are not libs or the other way around; and weirdness with non-C/C++
languages).
Also, a long time after marking some library package as manually
installed, one may no longer remember the reason.
If the user cannot, the packaging system cannot know either.
Still, either we remove completely the mechanism of auto-installed
(which will not happen) or we have to admit that removing as soon as
there are no rev-deps is the best thing to do, and the way that this
auto-installed thing was designed to work (and copied to apt afterwards,
I believe).
If this is somehow undesired, one can always resort to manage all
packages manually.
IMHO, the right thing to do would be to write some tool that manages
such dependencies, possibly in some automatic way (e.g. with ldd and
dpkg -S).
That's not the job of a tool like aptitude, though.
It's would be relatively easy to build such a tool and then regularly to
call apt/aptitude to unmark such packages as auto; or possibly hook on
apt updates a-la apt-listchanges or apt-listbugs.
But more seriously, I think that the real problem is prefering many
removals and some keeps rather than a few upgrades and a single removal,
but not because it's specifically a library involved in that.
A single removal is bad if it is an application.
That's strange coming from you, who use the resolver costs of minimizing
removals ;-)
aptitude and apt have sometimes to remove, not install or do other nasty
actions when packages conflict, there's no way around that. Removals
are critical to deal e.g. with obsolete packages and upgrades, even if
the removal of that library could end up breaking packages (your example
above).
My sentence above was about the original report. If removals are
necessary, as they were in that case, better /offer first/ to remove 1
and upgrade 11 than to remove 20 and leaving others untouched (the 2
solutions mentioned in the original report).
If the user is not happy with the offer, s/he can always ask aptitude
for another solution, and reject those who
Bug#818919: aptitude runs wild
2016-03-22 13:37 zieg...@uni-freiburg.de: aptitude search "?description(1234)" shows the progress of a filterung process. So I waited 5 minutes to the expected output. aptitude markauto 1234 gives also a result after 5 minutes. On the other hand lz4 decompresses all packagefiles together in a second ! Yes, but aptitude (through libapt) probably has to do it for every package as it's being processed. Maybe this could be avoided in the command line, but not in curses, which is probably the main mode of aptitude. Or otherwise, those files be uncompressed for all the time during the operation of the aptitude, which kind of defeats the purpose of that option if one uses aptitude frequently. In any case, from what I can see, there's no way to control this using the libapt API. So we could maybe issue a warning if this option is detected, but I think that there's not much else that we can do as things stand. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819636: aptitude: wants to remove a recommended package
More info about this. In my system, with unstable and the old libecm0 and gmp-ecm installed by hand (so they are "obsolete"): # apt-get -s install gmp-ecm ... The following additional packages will be installed: libecm1 The following NEW packages will be installed: libecm1 The following packages will be upgraded: gmp-ecm 1 upgraded, 1 newly installed, 0 to remove and 145 not upgraded. Inst libecm1 (7.0+ds-1 Debian:unstable [amd64]) Inst gmp-ecm [6.4.4-2] (7.0+ds-1 Debian:unstable [amd64]) Conf libecm1 (7.0+ds-1 Debian:unstable [amd64]) Conf gmp-ecm (7.0+ds-1 Debian:unstable [amd64]) # apt-get -s upgrade ... The following packages have been kept back: gmp-ecm libecm0 # apt-get -s dist-upgrade ... The following NEW packages will be installed: libecm1 The following packages have been kept back: libecm0 The following packages will be upgraded: [...] gmp-ecm [...] So it seems that a direct request to install (upgrade) a package is always granted, even if libecm0 is left behind with unfulfilled recommends. Maybe it's because of being obsolete packages, unlike in the system where this originally happened. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819636: aptitude: wants to remove a recommended package
Control: tags -1 + moreinfo 2016-04-01 0:29 GMT+01:00 Vincent Lefevre <vinc...@vinc17.net>: >> If the above is indeed what happens, the end result is not very useful >> in this particular case; but from aptitude's POV if the user marks for >> upgrade is because it doesn't want the current version of gpm-ecm. >> Therefore, keeping the current version of gpm-ecm is not considered a >> good option, and aptitude might break the recommends as a lesser evil > > This rather contradicts what David Kalnischkies says about Recommends > in <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489896#12>: > > "Recommends are installed by default by design as this is what the Debian > policy requires. > > Not installing them (even while fixing up broken systems) means that we > leave the system "slightly broken" as recommend packages should be > installed… so, mot a bug, but by design." Yes, that's true, as long as you don't have options set to the contrary (that's what I was asking). So not honouring them is the problem. (There are some cases where the packages might be unavailable in a given suite, due to wrong/obsolete dependencies or other cases. I am not sure what happens in that case, maybe the package is simply uninstallable). >> In particular, it seems that while you keep this package installed, >> "apt-get dist-upgrade" will not allow you to upgrade gmp-ecm at all >> until you remove libecm0, which doesn't sound very useful for the user >> either if it indeed wants to ugprade that package. > > Note that I didn't say that I wanted to upgrade the package, but > to upgrade the system. aptitude doesn't differentiate (and probably it cannot, specially in interactive mode) between "upgrading a package" and "upgrading the system", or "upgrading packages matching a pattern". Even if it can, I don't think that it's useful to split hairs like this. > Since libecm1 is the successor of libecm0, > the right thing would have been to propose the upgrade to libecm1 > (ditto for the -dev package). aptitude doesn't know if libecm1 is the successor of libecm0, if it's compatible or it will break other packages which still depend on the old library (as it's the case of many lib transitions with renaming lib packages, as this case) or if it's just another package with a similar name. So it shouldn't propose it as an an upgrade. In normal circumstances, users want to have packages installed (gmp-ecm in this case) and libraries as pulled in as necessary, marked as auto dependencies (yes, there are bugs in this area, but that's the general idea). When this package gets upgraded, new libs can get pulled in automatically, and old/obsolete marked automatically get removed. That's the normal workflow that tools and maintainers follow, I don't think that they are going to start adding dependencies between library packages like that. > BTW, what will happen with the next > Debian/stable? Will the user be prevented from upgrading to the > new gmp-ecm packages by "apt-get dist-upgrade"? Since I don't use apt-get and apt-get dist-upgrade I don't know what's the actual behaviour, but it seems to me that the same that it's preventing you from upgrade now, it will probably prevent that in the future. If you didn't have several versions enabled at the same time, libecm0 would maybe be detected as "obsolete" and maybe then apt-get dist-ugprade would decide to go ahead with the upgrade and remove the obsolete package. But since your package is marked as manually installed, it probably does not try to remove it anyway, even if it was "obsolete". >> These kind of behaviours are particularly important for dist-upgrades >> from stable to next stable, when many packages can be left behind as >> obsolete packages (or local packages installed by the user from >> elsewhere), and recommend non-existent packages in the new stable. > > I think that the right solution would be to warn the user before > breaking Recommends. In any case, never break Recommends if this > is not necessary. What aptitude was doing until recently when requesting to upgrade gmp-ecm was to upgrade it and unmark it as auto (because otherwise it would be removed, as it happens now). It was one of the sources of the "silently looses auto flags", it seems. So there are 3 possibilities: old behaviour (upgrade, ignore broken recommends and set no-auto), current behaviour (upgrade ignoring broken recommends but preserve auto, which in this case results in removal because of "unused"), silently ignoring the upgrade request, emitting an error, or invoking the resolver. I am not sure what's the best behaviour yet, probably invoking the full resolver is the best option. The others, some might be acceptable depending on the context, but probably not good overall. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819636: aptitude: wants to remove a recommended package
r local packages installed by the user from elsewhere), and recommend non-existent packages in the new stable. About this particular case, there are some odd factors influencing this behaviour: - the "libecm0 Recommends gmp-ecm (= 6.4.4+ds-5)" is slightly odd. libecm0 can Recommend (or maybe just Suggest) gpm-ecm, but requiring an exact version doesn't make a lot of sense. It's almost surely not required to have an exact version, they most probably just added it because since it comes from the same source, and if only one suite of Debian is used at a time, it works fine. If several suites are used at the same time, then there are several libecmX in the system, and they require a different "exact version" of the same package, things cannot work very well. - mark some suite as having more priority than the others, so aptitude doesn't consider all the suites equally valid for resolution. from the original report: APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') e.g. if you prefer "stable" and mark pin priorities accordingly, gmp-ecm would not be marked for ugprade. "libecm0" and "libecm1" depending on a different version of gmp-ecm should not co-exist, in the mind of the maintainers who set the dependencies like that. however, as things are in your system, all versions of all packages are the same for aptitude, and it has a harder time making the right decision (or makes some decisions impossible at all). There are several solutions which you most probably are aware about, but anyway, maybe for others who stumble upon the same problem: - if you really want gpm-ecm, mark it as manually installed. (it's a bit odd that you have that one as auto and libecm0 as manual, when normally it's the other way around, but I assume that it's on purpose). - if you want to stay with libecm0 for some reason, gmp-ecm will never be upgraded. you can set a Hold to avoid constant nagging. - you can upgrade to libecm1 instead, and gpm-ecm will be upgraded as well Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#776728: newsbeuter: nasty memory leak in 2.8
2016-03-31 18:52 GMT+01:00 Nikos Tsipinakis <ni...@tsipinakis.com>: > On Thu, Mar 31, 2016 at 05:46:32PM +0100, Manuel A. Fernandez Montecelo wrote: >> Uhm, sorry for not being clear. I know that the Debian maintainers >> were busy with other stuff. >> >> What it was not clear to me was why this was present in both 2.8 *and* >> 2.9 upstream, e.g., if the original patch had been reverted because it >> caused other problems. > > Oh, I am not really sure. I havent followed the 2.9 development that closely > and > I really dont feel like digging into 2 years worth of commits to find out, its > fixed anyway so does it really matter? It would matter if the patch that you're going to apply was the old patch that was first added for 2.9 to fix a problem in 2.8, and then disappeared for unknown reasons before 2.9 was actually released. Maybe the reasons were actually that upstream specifically reverted the patch before 2.9 because of causing other problems. That was my reason for asking. Since the one that you want to apply was added after 2.9, I suppose that it's fine :) -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#776728: newsbeuter: nasty memory leak in 2.8
2016-03-31 17:35 GMT+01:00 Nikos Tsipinakis <ni...@tsipinakis.com>: > On Thu, Mar 31, 2016 at 04:10:06PM +0100, Manuel A. Fernandez Montecelo wrote: >> Was it left out for some particular reason? >> >> I have quite a lot of memory so this is not critical for me in any way >> (but thanks for taking care of this). But I imagine that many of the >> users of newsbeuter can be annoyed by that, so I am curious why this >> memory problem has been going on for so long. > > As mentioned above, many users are running newsbeuter in hosts with limited > memory and a 1/2GB memory footprint for a text based RSS reader is simply > ridiculous and since there are no other important bugs open I am releasing a > revision with the patch immediately(its also is a nice excuse to migrate the > package to debhelper :) ) > > As for why it has been going on for that long, the leak was first observed > right > after the release of 2.8 for which a patch was released but was not added to > debian since the previous maintainer was busy, in 2.9 the issue re-appeared > for > some reason(either its a new memory leak or a regression of the old one), a > patch was released right after that and unfortunately I didn't notice it > before > uploading the new version. Uhm, sorry for not being clear. I know that the Debian maintainers were busy with other stuff. What it was not clear to me was why this was present in both 2.8 *and* 2.9 upstream, e.g., if the original patch had been reverted because it caused other problems. Thanks for the explanation and maintaining this program. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819603: aptitude: [INTL:ja] Japanese translation of po documentation update
Control: tags -1 + pending Hi Takuma, 2016-03-31 02:42 Takuma Yamada: Package: aptitude Version: 0.6.11-1+b1 Severity: wishlist Tags: l10n patch Dear Maintainer, Here's Japanese translationf of po documentation (ja.po) file I think that you mean program translation, not the documentation :-) that >reviewed by several Japanese Debian developers and users. Please copy the attachment into po/ja.po. Done now, thanks! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#776728: newsbeuter: nasty memory leak in 2.8
2016-03-31 14:54 GMT+01:00 Nikos Tsipinakis <ni...@tsipinakis.com>: > Hello, > > On Wed, Mar 30, 2016 at 10:12:35PM +0100, Manuel A. Fernandez Montecelo wrote: >> It seems that 2.9 still uses a lot of memory (at least in my >> use-case), 800MB right now after being restarted a few hours ago. >> >> So re-opening this bug. > > Apparently the patch for the memory leak didn't fully make it into 2.9, I'll > upload a patched version later today. Was it left out for some particular reason? I have quite a lot of memory so this is not critical for me in any way (but thanks for taking care of this). But I imagine that many of the users of newsbeuter can be annoyed by that, so I am curious why this memory problem has been going on for so long. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#776728: newsbeuter: nasty memory leak in 2.8
Control: reopen -1 Control: found -1 newsbeuter/2.9-2 Hi Nikos, 2016-01-03 11:30 GMT+00:00 Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>: > It would be very nice to get this fixed, it's getting up to 800+MB of > mem within hours, it seems to stabilise a bit after that. > > Version 2.9 was released a few weeks after this last message as > promised, and fixes the problem, so it would be extra nice to have the > new version! It seems that 2.9 still uses a lot of memory (at least in my use-case), 800MB right now after being restarted a few hours ago. So re-opening this bug. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#403289: add shorcut to compile a software
Control: tags -1 + wontfix Hi Ludovic, 2006-12-15 23:04 Ludovic Gasc: Package: aptitude Version: 0.4.4-1 With apt-build, it's possible to recompile easily a deb. It would be greatful if it's possible with a keyboard shortcut to select a software to recompile. Thanks for your response. 2011-08-30 08:50 Daniel Hartwig: severity 403289 wishlist block 403289 by 403372 468897 quit Compiling source packages requires fetching both the source [1] and any build-dep [2]. [1] 403372 -- To include option for download the source archives [2] 468897 -- implement build-dep and source actions (The following is mostly a consideration of the difficulty of the problem, not a reply to the original report per se). The implementation of this feature is not trivial, and there are many considerations to make. Firstly, fetching source and installing build-dependencies is not a solved problem in aptitude, as the reply above said; so these mechanisms would have to be implemented first. But what it's more important, aptitude would have to make several non-trivial decisions or implement quite a few things with the requested feature, with such as a high-level thing as compiling by pressing a key. For example, one has to download and install all build-dependencies, which can mean a huge amount of data to download (e.g. installing tetex to create the documentation), so a warning has to be issued in this case (perhaps the user thinks that compiling a small package is a small matter, but the process can eat up a lot of bandwith and surprise/annoy the user). Another matter is where to download the source. There's a well established place for downloading packages to be installed (/var/cache/apt/archives), but not so for such things as a package to be compiled. /usr/local/src? Maybe, but /usr/ can be mounted as read-only. /tmp/ or /var/tmp? /var/cache/aptitude-build? Perhaps, but compiling big packages like the web browsers can use a huge amount of space and could fill /tmp or the root partition with pretty disastrous consequences, so the program would have to get some kind of confirmation from the user of where to download this. A config variable could be used for that, but at least for the first time, the user would have to acknowledge it. apt-build doesn't suffer from this because it does that in the current directory, I think. There are other non-trivial questions to be solved like what to do when aptitude is root, because running such things as root is perhaps not the wisest thing to do; or what to do if the user is in the middle of a session of installing/removing packages (installing build-deps could ruin, or conflict, with the current actions). apt-build doesn't have to deal with the problem of being in the middle of a session, or being run interactively in ncurses. Doing this with the command line of aptitude could have similar advantages of simplifying the process a lot, but then again we already have apt-build for that. The last thing to consider that I will delve into is... why do all of this? In the original request, this is to "recompile" software. If it's software available in Debian (so build-deps can be installed and the package source downloaded), specially with the drive towards reproducible builds, the result should be an identical binary package, so I am not sure if this is the goal. If the goal is to (re)compile a package with some modifications, then the process cannot be automated, and a shell has to be spawned to be able to apply patches, or changing commands in debian/rules, enabling/disabling features (e.g. support for wayland, or codecs) or issuing different compilation flags. This is again another thing that would be better served by something more like apt-build (or apt source + HACK + debuild; or git-buildpackage; or any of the other tools) and not doing it interactively from the curses interface of aptitude. ... so these are some of the problems that come to mind as decisions to make to implement this feature. A simple keypress triggering actions like recompiling a package is not straightforward to implement at all. Given that this has been requested a decade ago and there's no drive to implement this any time soon, I am marking it as +wontfix for the time being. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#819208: qemubuilder: Please allow to pass -append arguments to Qemu
Package: qemubuilder Version: 0.78 Severity: wishlist Hi, As far as I can tell, there's no way to pass arguments to the kernel to be run, -append in Qemu. It would be very nice if qemubuilder had a way to do this, specially from the arch config file. Thanks for your work maintaining this program. Cheers. -- Manuel
Bug#818919: aptitude runs wild
Hi again, (one thing, please keep the address of the bug report in the recipients, otherwise these replies don't get registered) 2016-03-22 9:33 GMT+00:00 <zieg...@uni-freiburg.de>: > I let gdb run on "aptitude markauto 1234" for several seconds. and then > interrupted it. The backtrace was: > > Program received signal SIGINT, Interrupt. > 0x7470f091 in LZ4_decompress_safe_usingDict () from > /usr/lib/x86_64-linux-gnu/liblz4.so.1 > (gdb) bt > #0 0x7470f091 in LZ4_decompress_safe_usingDict () from > /usr/lib/x86_64-linux-gnu/liblz4.so.1 > #1 0x747143b9 in LZ4F_decompress () from > /usr/lib/x86_64-linux-gnu/liblz4.so.1 > #2 0x77b0e58e in ?? () from > /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 > #3 0x77b063e1 in FileFd::Read(void*, unsigned long long, unsigned > long long*) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 > #4 0x77b0ed5d in ?? () from > /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 > #5 0x77b98798 in pkgTagFile::Jump(pkgTagSection&, unsigned long > long) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 > #6 0x77b895ba in pkgRecords::Lookup(pkgCache::DescFileIterator > const&) () from /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 > #7 0x557213f1 in > get_long_description[abi:cxx11](pkgCache::VerIterator const&, pkgRecords*) > (ver=..., records=) at ../../../../src/generic/apt/apt.cc:1412 > #8 0x556f45f2 in cmdline_applyaction (s=..., > seen_virtual_packages=std::set with 0 elements, > action=action@entry=cmdline_markauto, to_install=std::set with 0 elements, > to_hold=std::set with 0 elements, > to_remove=std::set with 0 elements, to_purge=std::set with 0 elements, > verbose=0, policy=..., arch_only=false, allow_auto=false, > term_metrics=std::shared_ptr (count 5, weak 0) 0x55b488f0) > at ../../../src/cmdline/cmdline_action.cc:626 > #9 0x556a8e0e in cmdline_do_action (argc=, > argv=, status_fname=, simulate=, > assume_yes=, download_only=, fix_broken=false, > showvers=false, > showdeps=false, showsize=false, showwhy=false, visual_preview=false, > always_prompt=false, resolver_mode=, > safe_resolver_show_actions=false, no_new_installs=false, > no_new_upgrades=false, > user_tags=std::vector of length 0, capacity 0, arch_only=false, > queue_only=false, verbose=0) at ../../../src/cmdline/cmdline_do_action.cc:332 > #10 0x555b3e7e in main (argc=3, argv=) at > ../../src/main.cc:1241 > > > My package-list-files were lz4-compressed. (Like > "http.debian.net_debian_dists_testing_main_binary-amd64_Packages.lz4", > due to "Acquire::GzipIndexes true;"). Wenn I use instead uncompressed > package-files, "aptitude markauto 1234" works as it should. Good clue. Maybe it's the same underlying cause as with #697724 then. aptitude requires access to fields that are not in apt's binary caches, so it probably decompresses the file for every package that tries to match the description against. Maybe we find a way around this, but in general using "Acquire::GzipIndexes" with aptitude is not good, specially if using the curses interface. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#818919: aptitude markauto runs wild, if package does not exist
2016-03-22 7:00 GMT+00:00 <zieg...@uni-freiburg.de>: > Hi, here > > aptitude markauto 123 > > yields > > Couldn't find any package whose name is "123", but > there are 23 packages which contain "123" in their name..." > > So there must be a problem reading the description of packagens. What does aptitude search "?description(1234)" say? -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#818919: aptitude markauto runs wild, if package does not exist
Control: tags -1 + moreinfo Hi, 2016-03-21 18:23 zieg...@uni-freiburg.de: Package: aptitude Version: 0.7.8-1 Severity: normal Tags: upstream Dear Maintainer, If PATTERN does not match a package, the command aptitude markauto PATTERN does not stop, using 100% CPU. Example aptitude markauto 1234 The same is true for "aptitude forbid-version". It works fine around here: # aptitude markauto 1234 Couldn't find any package matching "1234", but there are 15 packages which contain "1234" in their description: modem-cmd modem-cmd:i386 libmath-nocarry-perl libnxml0 libnxml0:i386 tcs tcs:i386 postgresql-9.5-prefix postgresql-9.5-prefix:i386 libscalar-properties-perl golang-github-jinzhu-now-dev libnxml0-dbg libnxml0-dbg:i386 libnxml0-dev libnxml0-dev:i386 Unable to apply some actions, aborting # aptitude forbid-version 1234 Couldn't find any package matching "1234", but there are 15 packages which contain "1234" in their description: modem-cmd modem-cmd:i386 libmath-nocarry-perl libnxml0 libnxml0:i386 tcs tcs:i386 postgresql-9.5-prefix postgresql-9.5-prefix:i386 libscalar-properties-perl golang-github-jinzhu-now-dev libnxml0-dbg libnxml0-dbg:i386 libnxml0-dev libnxml0-dev:i386 Unable to apply some actions, aborting Would you be able to get a backtrace with gdb or valgrind, aptitude-dbgsym installed, and Control-C after a few seconds when looping (maybe a couple of minutes with valgrind)? Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#795228: aptitude: upgraded a package to experimental without notice
Control: tags -1 + moreinfo Hi, 2015-08-12 01:46 Vincent Lefevre: Package: aptitude Version: 0.6.11-1+b1 Severity: important Yesterday, during an upgrade of my Debian/unstable machine with aptitude via its UI (with the new libstdc++6 in particular), aptitude upgraded a package (powertop) from unstable to experimental (see aptitude log in attachment), and I wasn't aware of this until now. On another machine, I can see that by default, packages are not upgraded to experimental. For instance, on another machine (with blocked packages), "aptitude install apt" refuse to upgrade apt (ditto via its UI), while "aptitude install -t experimental apt" proposes to upgrade it. openntpd 1:5.7p4-1 was the only experimental package I installed manually (with "apt-get install openntpd/experimental", IIRC). For the aptitude configuration, I have: Aptitude::ProblemResolver::SolutionCost "removals"; (in the attachment) ... [UPGRADE] libstdc++6:amd64 5.1.1-14 -> 5.2.1-15 ... [UPGRADE] powertop:amd64 2.6.1-1 -> 2.7-1~exp1 ... libstdc++6 added breaks on "powertop (<= 2.6.1-1)", still present today. This was for the big transition and change in ABI that happened a few days before the report, on the 1st of August, for the big GCC-5 / C++11 ABI transition. Probably the libstdc++6 maintainer didn't realise that a version of powertop was present in experimental, or didn't consider the option to add breaks to versions in experimental in general (the transition was taxing enough for everybody, and on him specially), but actually it should have added breaks this version too. In that case, you wouldn't have been able to upgrade libstdc++6 while powertop was not recompiled against it with a binNMU (and 2.8 was uploaded at some point in september), or powertop would have to be removed. With the SolutionCost of "removals", aptitude doesn't take into account installing by priorities or non-default releases, it just tries to minimise the removals, so seing that it could solve the problem by upgrading to 2.7-1~exp1, it just did that. In the preview window of the curses interface it shows the candidate version to be installed (2.7-1~exp1), and in the solution resolver in curses (that transition in particular used to cause many conflicts) and the command line shows something similar to [1], including version and suite. The "upgrade" in the command line is a bit more silent, one can show versions with --show-versions. With patterns in the command line one can select whether to upgrade only packages with a given priority, or not from archive experimental, for example. [1] Upgrade the following packages: ... 35) libblkid1 [2.27.1-3 (now) -> 2.27.1-6 (unstable)] -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#651410: aptitude: in dependency resolutions, aptitude should favor library removal
Hi Vincent,
2011-12-08 11:53 Vincent Lefevre:
Package: aptitude
Version: 0.6.4-1.2
Severity: normal
The dependency resolution is suboptimal, even buggy. For instance:
# aptitude install evolution
The following NEW packages will be installed:
libgnome-desktop-3-2{a}
The following packages will be upgraded:
evolution gnome-desktop3-data
The following packages are RECOMMENDED but will NOT be installed:
bogofilter spamassassin
2 packages upgraded, 1 newly installed, 0 to remove and 34 not upgraded.
Need to get 1955 kB of archives. After unpacking 20.5 kB will be used.
The following packages have unmet dependencies:
libgnome-desktop-3-0: Depends: gnome-desktop3-data (= 3.0.2-2) but 3.2.1-3 is
to be installed.
evolution-plugins: Depends: evolution (= 3.0.3-3) but 3.0.3-3+b1 is to be
installed.
The following actions will resolve these dependencies:
Remove the following packages:
1) cheese
2) eog
3) evolution
4) evolution-plugins
5) gnome-accessibility
6) gnome-applets
7) gnome-control-center
8) gnome-core
9) gnome-panel
10) gnome-power-manager
11) gnome-screensaver
12) gnome-session
13) gnome-session-fallback
14) gnome-settings-daemon
15) gnome-shell
16) gnome-sushi
17) libevolution
18) libgnome-desktop-3-0
19) nautilus
20) nautilus-sendto
Leave the following dependencies unresolved:
21) alacarte recommends gnome-panel
22) evolution-common recommends evolution
23) gdm3 recommends gnome-power-manager (>= 2.28)
24) gdm3 recommends gnome-settings-daemon
25) gnome-control-center recommends gnome-session
26) gnome-control-center-data recommends gnome-control-center (>= 1:3.0.2-3)
27) gnome-session recommends gnome-power-manager
28) gnome-session-fallback recommends gnome-power-manager
29) gnome-system-tools recommends gnome-control-center (>= 1:2.10.1-1)
30) metacity recommends gnome-session | x-session-manager
31) mousetweaks recommends gnome-control-center
32) evolution recommends evolution-plugins
33) gnome-panel-data recommends gnome-panel
34) nautilus-data recommends nautilus
35) totem-plugins recommends gnome-settings-daemon
36) gnome-panel recommends gnome-session (>= 2.26)
37) gnome-panel recommends gnome-control-center
Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:
Remove the following packages:
1) libgnome-desktop-3-0
Upgrade the following packages:
2) cheese [3.2.2-1 (now, testing) -> 3.2.2-1+b1 (unstable)]
3) eog [3.2.2-2 (now, testing) -> 3.2.2-2+b1 (unstable)]
4) evolution-plugins [3.0.3-3 (now, testing) -> 3.0.3-3+b1 (unstable)]
5) gnome-control-center [1:3.0.2-3 (now, testing) -> 1:3.0.2-3+b1 (unstable
6) gnome-panel [3.2.1-1 (now) -> 3.2.1-1+b1 (unstable)]
7) gnome-screensaver [3.0.1-3 (now, testing) -> 3.2.0-2+b1 (unstable)]
8) gnome-settings-daemon [3.0.3-3 (now, testing) -> 3.0.3-3+b1 (unstable)]
9) gnome-shell [3.0.2-8 (now, testing) -> 3.0.2-8+b1 (unstable)]
10) libevolution [3.0.3-3 (now, testing) -> 3.0.3-3+b1 (unstable)]
11) nautilus [3.2.1-2 (now) -> 3.2.1-2+b1 (unstable)]
Accept this solution? [Y/n/q/?]
The first solution is really bad as it removes various useful packages,
including evolution, that was asked to be installed on the command line
(I regard this one as a bug).
Agree. Since there are many duplicates about other conflict resolution
preferences including not honouring user's requests, for the rest of the
reply I don't consider this question.
The second solution is OK, as only a library package is removed, and
such a package with no dependencies on it is useless.
Not necessarily. The library might have been installed by hand for
extra sound plugins or other codecs, mesa libraries not strictly needed
according to the dependency system but worthy to have in that machine,
dvd decoding, or to support something installed in the system outside of
the package managers (e.g. a special version of a webserver or other
software, compiled in /usr/local, mounted through NFS, etc).
If it's not really installed for a special purpose, should have been
marked as automatically installed to get rid of it sooner.
I don't think that libraries should be treated that specially for
reasons of removals as in the example of the original report. "useless"
doc packages or conflicts between icon sets might also come to mind as
being favoured to remove in conflict resolutions -- after all not having
doc installed usually doesn't break binaries ;-)
But more seriously, I think that the real problem is prefering many
removals and some keeps rather than a few upgrades and a single removal,
but not because it's specifically a library involved in that.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#608811: aptitude: Should prefer to install package in experimental rather than no version at all
Control: tags -1 + wontfix
Hi,
2011-01-03 17:16 Nelson A. de Oliveira:
Package: aptitude
Version: 0.6.3-3.2
Severity: wishlist
Hi!
See:
=
# aptitude install transmission-cli
The following NEW packages will be installed:
transmission-cli{b}
0 packages upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
Need to get 378 kB of archives. After unpacking 811 kB will be used.
The following packages have unmet dependencies:
transmission-cli: Depends: transmission-common (= 2.03-2) but 2.11-1 is
installed.
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) transmission-cli [Not Installed]
Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:
Install the following packages:
1) transmission-cli [2.11-1 (experimental)]
Accept this solution? [Y/n/q/?]
=
The first option is to keep the current version (to not install the
package); it's necessary to ask for the next solution to get what I
want.
aptitude doesn't know that you prefer to install the version from
experimental than the one from unstable, if it's pinned lower:
=
# apt-cache policy transmission-cli
transmission-cli:
Installed: (none)
Candidate: 2.03-2
Version table:
2.11-1 0
100 http://ftp.us.debian.org/debian/ experimental/main i386 Packages
2.03-2 0
500 http://ftp.us.debian.org/debian/ sid/main i386 Packages
=
While I know that the install candidate is 2.03-2 (and aptitude will try
to install it), aptitude should prefer to install the new package at
experimental. The first logical solution seems to be "install the
version from experimental"
There are safety mechanisms in aptitude to not install versions from
"non-default versions", and there are many bugs already complaining that
it's very easy for them to install versions in aptitude inadvertently,
even when aptitude prints "experimental" in the process.
So many people would not agree that installing from "experimental" is
the first logical solution.
(since it already has all the dependencies
installed and it has been asked to install it) instead not installing the
desired package.
The request was to install the package from the (implicit) default
version.
To install particular versions or from other suites (from "man
aptitude"):
install
Install one or more packages. The packages should be listed after
the “install” command; if a package name contains a tilde character
(“~”) or a question mark (“?”), it will be treated as a search
pattern and every package matching the pattern will be installed
(see the section “Search Patterns” in the aptitude reference
manual).
To select a particular version of the package, append “=”
to the package name: for instance, “aptitude install
apt=0.3.1”. Similarly, to select a package from a particular
archive, append “/” to the package name: for instance,
“aptitude install apt/experimental”. You cannot specify both an
archive and a version for a package.
So marking this as +wontfix.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#795228: aptitude: upgraded a package to experimental without notice
minor corrections: In that case, you wouldn't have been able to upgrade libstdc++6 while powertop was not recompiled against it with a binNMU (and 2.8 was uploaded at some point in september), or powertop would have to be removed. 2.8 was uploaded in November, not in September, but a binNMU (2.6.1-1+b1) was scheduled on the 17th of August for this libstdc++ transition. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#542264: aptitude: Strange messages from dependency resolver
Control: tags -1 - moreinfo Control: close -1 2015-12-29 11:33 To Frank Küster: I think the the behaviour of aptitude with candidate releases was suboptimal compared to a few years ago, but improved since then, including in the more recent 0.7.* series. Did you observe this behaviour lately? There were just too many changes since the version against which this was original reported (0.4.11.11-1+b2) and now, and the packages involved far away in the past which makes it quite difficult to try to reproduce now. I am not aware of similar bug reports still opened. If this was not resolved and the problem is still reproducible with recent versions, please reopen it with a recent example. Closing now. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#419501: aptitude: Strange conflict resolution
Control: tags -1 + moreinfo Hi Christoph, 2007-04-23 15:05 Christoph Pleger: Hello, On Fri, 20 Apr 2007 07:03:00 -0700 Daniel Burrows <dburr...@debian.org> wrote: On Fri, Apr 20, 2007 at 09:31:31AM +0200, Christoph Pleger <christoph.ple...@cs.uni-dortmund.de> was heard to say: > Hello Daniel, > > On Thu, 19 Apr 2007 20:37:16 -0700 > Daniel Burrows <dburr...@debian.org> wrote: > > > It looks like the problem is that aptitude is noticing that you > > have a > > pile of unresolved recommendations and fixing them for you. The > > weird thing, to me, is that there are no candidates to resolve the > > recommendations, which I bet is why aptitude insists on removing > > the packages. > > When I add cupsys-bsd to the package list which I set by "dpkg > --set-selections", all desired packages are installed. But I do not > want do that, see below. What I mean by that is that aptitude can't find any way to resolve the recommendations, other than removing the recommenders. Eliminating all hard dependency conflicts "fixes" the problem because aptitude doesn't have to resolve dependencies at all (it only notices broken recommendations when it's kicked into dependency resolution). Have you tried turning down the penalty for leaving recommendations unsatisfied? That helped, but I think that aptitude should never let packages uninstalled only because of recommendations that cannot be fulfilled. I am not aware of such problems for a long time, and there are no other similar bug reports. Are you aware of this still happening nowadays? I can try to reproduce it, but for that I have to find such a package or create an artificial one... might take a bit to get around doing it. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#671486: aptitude: does not select prefered alternative on alternative replacement
2016-03-17 20:45 To Yann Dirson: IMO and according to policy [1], there's nothing special about the first alternative. [1] https://www.debian.org/doc/debian-policy/ch-relationships.html I mean specifically this sentence: In such a case, that part of the dependency can be satisfied by any one of the alternative packages. and the lack of mention of preference of some alternative over the others in that section. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#818582: aptitude cannot deal with often changing IP
Control: tags -1 + moreinfo Hi Jaakov, 2016-03-18 09:56 Jaakov: Package: aptitude Version: 0.7.5-3 Some internet providers change the IP address of clients frequently - approximately once a minute instead of once a day. "aptitude update" and aptitude downloads executed by such clients cannot deal with this fact - neither with passive nor with active sockets. They manage to download a bit before the IP change and then say that a socket cannot be connected. An improvement is needed. If it's already implemented, I'd like to see the documentation of this feature. aptitude doesn't use sockets directly, the download functionality happens through libapt, so I don't think that we can do much about it. The problem also happens when using apt, I suppose? Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#671486: aptitude: does not select prefered alternative on alternative replacement
Control: tags -1 + moreinfo Hi Yann, 2012-05-04 14:28 Yann Dirson: Package: aptitude Version: 0.6.6-1 * Base situation: $ apt-cache policy phonon phonon: Installed: 4:4.6.0really4.5.1-1 Candidate: 4:4.6.0.0-1 alternative "phonon-backend-vlc | phonon-backend" provided by phonon-backend-xine [...] => phonon-backend-null appears to be taken randomly, while there is a prefered alternative listed IMO and according to policy [1], there's nothing special about the first alternative. [1] https://www.debian.org/doc/debian-policy/ch-relationships.html I think that it's a special case for buildds or common practice that people do to ensure installability when building and so on, but nothing that the package managers have to abide to. I think that aptitude doesn't pay attention at all about the relative position, but even if it does initially, it tries to be smart about it in cases of conflicts and install packages depending on the overall solution. E.g. if you have many of the -vlc or -xine dependencies installed it might prefer one over the other, in the case of -null maybe it prefers it simply because it has to install less packages. (From a high level point of view, aptitude cannot make the cognitive leap of thinking that if "-null" is "desirable" because it installs few packages, maybe it is because in fact it provides less/no functionality compared with the others). So, all in all, I don't think that this is a bug, but a feature; and the fact that other tools prefer the first solution is to overcome limitations on their side. Also note the side problem of an alternative removing 18 packages and breaking a Recommends being prefered over selecting another alternative. Maybe worth split the bug for this one ? There are many about that already :-) Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#346321: aptitude: offers upgrade to exp version (pri -10) instead of unst version (990)
Control: tags -1 + moreinfo Oi Henrique, 2006-01-07 00:22 Henrique de Moraes Holschuh: Package: aptitude Version: 0.4.1-1 Severity: important I am tagging this as important because any bug that makes people install experimental packages unawares is quite problematic :) $ apt-cache policy libarts1c2a libarts1c2a: Installed: 1.4.3-3 Candidate: 1.5.0-3 Version table: 1.5.0-3 0 990 http://mirrors.kernel.org unstable/main Packages 990 http://ftp.fi.debian.org unstable/main Packages 1.5.0-2 0 -10 http://mirrors.kernel.org experimental/main Packages -10 http://ftp.fi.debian.org experimental/main Packages *** 1.4.3-3 0 100 /var/lib/dpkg/status However, aptitude does this: libarts1c2a recommends libarts1-akode --\ The following actions will resolve this dependency: -> Upgrade libarts1c2a [1.4.3-3 (now) -> 1.5.0-2 (experimental, experimental)] -> Keep libarts1c2a at version 1.4.3-3 (now) -> Remove libarts1c2a [1.4.3-3 (now)] -> Install libarts1-akode [4:3.5.0-2 (experimental, experimental)] -> Leave the dependency "libarts1c2a recommends libarts1-akode" unresolved. i.e it prefers to install the experimental version, even if it is priority -10. The correct solution is to install libarts1c2a 1.5.0-3, and leave the dependency unresolved. OR to hold everything. But installing anything that has a negative priority is a no-no. For reference, my /etc/apt/preferences is: Package: * Pin: release a=experimental Pin-Priority: -10 This should not happen with "recent" versions of aptitude, recent as in the last 6 years at least, because solutions involving installations / upgrades of non-default versions are kept in a different level and only offered last, if at all, below upgrading to default versions, removing it or keeping everything at the same version. Have you experience this behaviour recently? Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#406976: aptitude: source-strictness is not strict enough
2016-03-18 11:36 Steinar H. Gunderson: On Fri, Mar 18, 2016 at 11:33:41AM +, Manuel A. Fernandez Montecelo wrote: Have you had some recent-ish experience with this, and remember if it behaves in the same way? I don't think it's nearly as bad as it was, but it's still not _good_. Last instance I can recall was trying to install fglrx-driver on unstable (which requires downgrading X to the version in testing); it would frequently give me 2-3 completely bogus results before giving me one that would actually install the fglrx-driver package. That's on a machine where I haven't modified request-strictness from the defaults at all, though, so perhaps it doesn't count? I have been investigating this lately, and that's another problem with many variants/complaints, e.g. your bug #453935 or someone else's #610845, hopefully it'll be addressed soon (but it's a problem going back and forth for years, a trade-off between "ability to dist-upgrade", "unattended-upgrades" and user's requests/expectations... so it's difficult to balance). This specific problem of this bug report about upgrading to experimental might be different because the solutions using "non-default releases" are placed in another level/tier, but the score that you were using is only relevant within the same tier /nowadays/ (I don't know back then), so no matter how much one changes the Source-Strictness it will not cross the boundaries. The question is if it considers all packages in "experimental" as non-default and goes to another tier, all of them non-default except the one requested to be installed in the command line, or all but the one requested plus its dependencies that are necessary to upgrade (which seems to be what you want here). I am not sure if the last is a good idea in general, because there are several complaints that aptitude is/was too eager to upgrade to experimental when it shouldn't because experimental is very bad or something, even when the submitters were requesting some packages to upgrade to experimental in the same action. (You probably know this, but as a workaround for people landing in this page...) For complex and infrequent solutions, rejecting some actions of the first suggestions with 'r' in the solution screens/questions (both in curses and in command line) would probably be enough to guide very quickly towards a solution, in the absence of big problems like transitions that make your request impossible to fulfill.. If the packages that one wants to upgrade are the same set causing always problems, pinning those in particular might help (apt_preferences). Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#556881: aptitude: unable to install a package A that depends on B, if B Provides A and at the same time Conflicts/Breaks/Replaces A
Control: retitle -1 aptitude: unable to install a package A that depends on B, if B Provides A and at the same time Conflicts/Breaks/Replaces A Control: tags -1 + help 2009-11-18 00:20 Raphael Geissert: Package: apt Version: 0.7.23.1 Hi, Given the following circumstances, apt fails to find a solution: 8<->8 Package: foo Depends: bar Package: bar Provides: foo Conflicts: foo Replaces: foo # apt-get install foo Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: foo: Depends: bar but it is not going to be installed E: Broken packages 8<->8 The obvious solution here is to simply install bar, and not foo. 2009-11-18 01:05 Raphael Geissert: retitle 556799 readahead is uninstallable with current dependencies resolvers block 556799 with 556869,556881 tag 556799 confirmed thanks 2009/11/17 Sven Joachim <svenj...@gmx.de>: Package: readahead-fedora Version: 2:1.5.4-2 Severity: serious Thank you for providing a transitional readahead package, but there is a little problem with it. Namely, it is not actually installable: [...] The solution is to version the "Conflicts: readahead", obviously. Yes and no. Yes, because it is currently uninstallable because of a, IMO, a bug on the resolvers' side (but I plan to workaround it, don't worry) as there _is_ a solution. No, because the conflict is there to avoid installing readahead-fedora together with whatever other readahead implementation you may choose to install (say sreadahead, ureadahead, etc; they all provide 'readahead'). The current workaround on the users side is to install the *real* package, not the transitional one. That is, install readahead-fedora or upgrade from readahead, but don't install readahead. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net 2009-11-18 13:23 Daniel Burrows: Personally, I think that assuming that "bar" should be installed without any more hints from the user is a bit of a stretch; they asked to install "foo", not "bar", and it can't be installed. I don't know that aptitude should be trying to second-guess its command line here. I do think that it would make sense for aptitude to print out a list of packages that C/P/R "foo". Daniel 2009-11-18 15:25 Raphael Geissert: Hi Daniel, 2009/11/18 Daniel Burrows <dburr...@debian.org>: Personally, I think that assuming that "bar" should be installed without any more hints from the user is a bit of a stretch; they asked to install "foo", not "bar", and it can't be installed. I don't know that aptitude should be trying to second-guess its command line here. The thing is that bar provides "foo", satisfying the user request. I do think that it would make sense for aptitude to print out a list of packages that C/P/R "foo". It would be great if aptitude does that, in case the outcome of this request is that such a package is still considered uninstallable and "broken". Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net Quoting the relevant messages from the report (including the reply to Sven's, which is hidden in the BTS website for some reason). As the reply from Sven, I think that perhaps Conflicts or other fields should be versioned, but didn't think much about it. In any case, it's still open in apt but maybe has been silently fixed. aptitude relies on apt for the normal resolution, so if it's either fixed or present in apt, it's still the same in aptitude for the normal cases. This should be easy to test using equivs. Tagging +help in the case that there's some charitable soul wanting to lend a hand. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#693921: [Aptitude-devel] Bug#693921: fails to resolve empathy/experimental dependencies, fails with signal 6
2013-03-29 08:33 Sjoerd Simons:
On Wed, Nov 28, 2012 at 11:32:51AM -0800, Christoph Egger wrote:
Hi!
Christoph Egger <christ...@debian.org> writes:
> Daniel Hartwig <mand...@gmail.com> writes:
>> On 22 November 2012 03:36, Christoph Egger <christ...@debian.org> wrote:
It's also easily reproducible with a `mk-build-dep` in
empathy/experimental and isntalling aptitude in a minimal chroot, dpkg
-i the build-dep and have aptitude [1] resolve it
[1] aptitude -y --without-recommends -o Dpkg::Options::=--force-confold -o
Aptitude::CmdLine::Ignore-Trust-Violations=false -o Aptitude::ProblemResolver::StepScore=100 -o
Aptitude::ProblemResolver::SolutionCost="safety, priority, non-default-versions" -o
Aptitude::ProblemResolver::Hints::KeepDummy="reject empathy-build-deps :UNINST" -o
Aptitude::ProblemResolver::Keep-All-Level=55000 -o
Aptitude::ProblemResolver::Remove-Essential-Level=maximum install empathy-build-deps
I used this method to reproduce the issue for current gnome-shell/experimental.
The trigger seems to be the usage of non-default-versions in the SolutionCost,
using the default ("safety, priority") like e.g. pbuilder does results in
aptitude successfully finding a solution.
Note for future handling of this bug:
#418385 contains some hint on the use of -y that prevents some "cutoff"
measures to kick in, affecting pbuilder.
Not sure if it's related or not, but just a note to explore in the
future.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#406976: aptitude: source-strictness is not strict enough
Control: tags -1 + moreinfo Hi Steinar, 2007-01-15 11:49 Steinar H. Gunderson: Package: aptitude Version: 0.4.4-1 Severity: normal Hi, I'm trying to force in newer evince (since I need it for a presentation) _and_ still keep GNOME: fugl:~> LANG=C sudo aptitude install gnome evince/experimental Reading package lists... Done [...] The following packages are BROKEN: gimp libgtk2.0-0 The following packages are unused and will be REMOVED: bsh gcj-4.1-base gij gij-4.1 gimp-data gnuplot gnuplot-nox gnuplot-x11 lapack3 libg2c0 libgcj-bc libgcj-common libgcj7-0 libgd2-noxpm libhsqldb-java libicu36 libjaxp1.2-java libjaxp1.3-java libjline-java libmdbtools libneon26 libpoppler0c2-glib libservlet2.3-java libstlport4.6c2 libufsparse libwpd8c2a libxalan2-java libxerces2-java libxt-java openoffice.org openoffice.org-base openoffice.org-calc openoffice.org-common openoffice.org-core openoffice.org-draw openoffice.org-impress openoffice.org-java-common openoffice.org-math openoffice.org-writer python-uno refblas3 ttf-opensymbol The following NEW packages will be automatically installed: gimp-print gimp-svg gnome-office libwmf0.2-7 The following NEW packages will be installed: gimp-print gimp-svg gnome gnome-office libwmf0.2-7 0 packages upgraded, 6 newly installed, 42 to remove and 0 not upgraded. Need to get 3422kB/3448kB of archives. After unpacking 295MB will be freed. The following packages have unmet dependencies: gimp: Depends: gimp-data (= 2.2.13-1) but it is not installable Conflicts: libgimp2.0 (>= 2.3.0) but 2.3.13-1 is installed. libgtk2.0-0: Conflicts: libwmf0.2-7 (<= 0.2.8.4-2) but 0.2.8.4-2 is to be installed. Resolving dependencies... open: 59; closed: 34; defer: 0; conflict: 11 .The following actions will resolve these dependencies: Keep the following packages at their current version: libpoppler0c2-glib [0.4.5-5 (testing, unstable, now)] Downgrade the following packages: bug-buddy [2.16.0-1 (experimental, now) -> 2.14.0-4 (testing, unstable)] evince [0.6.1-1 (experimental, now) -> 0.4.0-3 (testing)] gimp-data [2.3.13-1 (experimental, now) -> 2.2.13-1 (testing, unstable)] gtk2-engines [1:2.8.2-2 (experimental, now) -> 1:2.8.2-1 (testing, unstable)] gtk2-engines-pixbuf [2.10.7-1 (experimental, now) -> 2.8.20-4 (unstable)] libgimp2.0 [2.3.13-1 (experimental, now) -> 2.2.6-1sarge1 (stable)] libgnomeui-0 [2.16.1-1 (experimental, now) -> 2.14.1-2 (testing, unstable)] libgnomeui-common [2.16.1-1 (experimental, now) -> 2.14.1-2 (testing, unstable)] libgtk2.0-0 [2.10.7-1 (experimental, now) -> 2.8.20-4 (unstable)] libgtk2.0-common [2.10.7-1 (experimental, now) -> 2.8.20-4 (unstable)] librsvg2-2 [2.16.0-3 (experimental, now) -> 2.14.4-2 (testing, unstable)] librsvg2-common [2.16.0-3 (experimental, now) -> 2.14.4-2 (testing, unstable)] Score is -298 Given that my Request-Strictness is set to 1 (which is now the default, I believe), this score is too high; my guess is that it thinks having evince 0.4.0-3 satisfies my request for "evince/experimental". In any case, it appears to be quite impossible to ask it to drop all "solutions" mentioning evince from testing/unstable, short of removing them from the local Packages files. This has happened many years ago, before the resolver was heavily reworked in the last few years. I am not sure if the situation is better now due to aptitude having into account that "experimental" is the default release for this operation, or if it's worse because it considers that versions for experimental are not default for the other packages that you didn't request. Have you had some recent-ish experience with this, and remember if it behaves in the same way? You probably know about this, but in general, if the upgrade to experimental is indeed possible, you can guide the solution easily by rejecting all downgrades to testing/unstable and asking for the next solutions. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#457188: aptitude: unexpected empty solution error
Control: tags -1 + moreinfo Hi Jiří, 2007-12-20 11:15 Jiří Paleček: Package: aptitude Version: 0.4.9-1 Severity: normal Hello, I tried to install the fbdev xorg video driver and got this error from aptitude while resolving dependencies. The situation is as follows: there are two versions of -video-fbdev, 0.4.1-1 (testing) and 0.4.1-4. The former provides -video-driver-1.0, the latter provides -video-driver-2. My version of xorg conflicts with -video-driver-1.0. What happened: after I selected -video-fbdev, the testing version was selected. This selection conflicts with my xorg, so I went to the resolver. I selected the solution of installing the unstable version, and tried to use that solution. At this moment, I got the error "unexpected empty solution" (or something, it was in Czech). The correct driver package was selected, but xorg still was marked as broken. Even when I've undone everything, xorg was marked as broken although the selection did not contain any conflicts. When I selected the unstable version in the beginning, everything was OK. Have you seen this report lately? I haven't seen any secondings or duplicates in the last few years, and haven't experience it myself as far as I can remember. Given that this happened before a time when the resolver was heavily reworked, I guess that the problem was fixed, or at least heavily morphed into something else now. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#795228: aptitude: upgraded a package to experimental without notice
2016-03-17 02:43 Vincent Lefevre: Hi, On 2016-03-17 00:10:55 +, Manuel A. Fernandez Montecelo wrote: With the SolutionCost of "removals", aptitude doesn't take into account installing by priorities or non-default releases, it just tries to minimise the removals, so seing that it could solve the problem by upgrading to 2.7-1~exp1, it just did that. IMHO, that's bad. Other people beg to differ, e.g. #608811 and #658635. I am generally of the same opinion as you, and so is aptitude with the default rules, so the suggestions of upgrading packages to experimental or other non-default releases is offerend only last. FYI, I chose the "removals" SolutionCost to avoid breaking the system due to removed packages. But installing experimental packages is not a good solution as such packages may break the system. There should be a way to block upgrades as long as they are not safe (no removals of manually installed packages[*], no experimental packages). [*] except when the feature is provided by another package (such as with renamed packages). "removals" just tries to minimise the number of removals, without having other things into account like "don't upgrade to packages in experimental". Looking at the documentation, maybe you should use "safety, removals", "priority, removals" or "non-default-actions*1000 + removals". Probably none of these combinations are tested, and things are quite difficult with the resolver as they are, so no promises that it will work better or that it will not produce unexpected/undesired results sometimes, though. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#346321: aptitude: offers upgrade to exp version (pri -10) instead of unst version (990)
Control: tags -1 - moreinfo Control: close -1 2016-03-18 0:59 GMT+00:00 Henrique de Moraes Holschuh <h...@debian.org>: >> >However, aptitude does this: >> >libarts1c2a recommends libarts1-akode >> >--\ The following actions will resolve this dependency: >> > -> Upgrade libarts1c2a [1.4.3-3 (now) -> 1.5.0-2 (experimental, >> > experimental)] >> > -> Keep libarts1c2a at version 1.4.3-3 (now) >> > -> Remove libarts1c2a [1.4.3-3 (now)] >> > -> Install libarts1-akode [4:3.5.0-2 (experimental, experimental)] >> > -> Leave the dependency "libarts1c2a recommends libarts1-akode" unresolved. >> > >> >i.e it prefers to install the experimental version, even if it is priority >> >-10. The correct solution is to install libarts1c2a 1.5.0-3, and leave the >> >dependency unresolved. OR to hold everything. But installing anything that >> >has a negative priority is a no-no. >> > >> >For reference, my /etc/apt/preferences is: >> >Package: * >> >Pin: release a=experimental >> >Pin-Priority: -10 >> >> This should not happen with "recent" versions of aptitude, recent as in >> the last 6 years at least, because solutions involving installations / >> upgrades of non-default versions are kept in a different level and only >> offered last, if at all, below upgrading to default versions, removing >> it or keeping everything at the same version. >> >> Have you experience this behaviour recently? > > No, but that doesn't mean anything: sometime after I reported the bug, I > disabled experimental, and I don't think I had any reason to reenable it in > the last decade (if I did, I most certainly used a disposable chroot, got > the job done, dropped the chroot in the bitbucket and promptly forgot about > it). > > One would have to test current apt (or better yet, stable apt) to be sure. >From my reading of the code, tests that I was doing lately, as well using experimental myself for many years, and from the lack of "secondings" to this bug or similar complaints in hundreds (or more like about a thousand) bug reports that I have triaged in the last few years, I know that this was not a case that happened at least in this decade, not under normal conditions in any case. I was just trying to get confirmation from you as submitter. There are still hundreds of open bugs. If the submitters are not interested if they are still happening, I am not all that interested in getting down to the last detail of every one of them, when there is no reasonable indication that ancient bugs continue present. Still, I just tested this specifically with experimental priority -10 and -1000 and with git-man which caused the full resolver to be involved, and the offerings to upgrade to experimental always come last (Remove, Upgrade to unstable, Keep, Upgrade to experimental). So closing the report now. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#406976: aptitude: source-strictness is not strict enough
2016-03-18 12:30 GMT+00:00 Steinar H. Gunderson <sgunder...@bigfoot.com>: > On Fri, Mar 18, 2016 at 12:15:02PM +0000, Manuel A. Fernandez Montecelo wrote: >> This specific problem of this bug report about upgrading to experimental >> might be different because the solutions using "non-default releases" >> are placed in another level/tier, but the score that you were using is >> only relevant within the same tier /nowadays/ (I don't know back then), >> so no matter how much one changes the Source-Strictness it will not >> cross the boundaries. > > Ah, so tiers trump scoring? I wasn't aware of that. And I don't think the UI > makes that clear in any reasonable way either. With the default settings, yes. "safety" uses a classification based in levels/tiers, so actions considered dangerous are classified in tiers and only offered later. http://aptitude.alioth.debian.org/doc/en/ch02s03s04.html This is the reason why "keep all" is in another tier (higher, which means "more undesirable"), meaning "cancel user request" and thus only offered after others. It doesn't consider "remove the package that you asked to upgrade" as cancelling your actions, so that's the reason why it offers that before "keep all". (Some of these are counter-intuitive for interactive or small upgrades, and I am trying to address them, but they seem to have to do with automatic/dist-upgrades and being able to leave packages behind when obsolete and so on). >> For complex and infrequent solutions, rejecting some actions of the >> first suggestions with 'r' in the solution screens/questions (both in >> curses and in command line) would probably be enough to guide very >> quickly towards a solution, in the absence of big problems like >> transitions that make your request impossible to fulfill.. > > I don't think I've ever used 'r'; I've just used 'n'. I wasn't aware that > you could do much more than just ask for the next solution. I mentioned it, just in case. http://aptitude.alioth.debian.org/doc/en/ch02s03s03.html Basically, you can 'r'eject and 'a'pprove some of the solutions (or, since the last version 0.7.8, to whole subtrees like 'r' to "remove the following packages" or 'a' to accept "packages to be upgraded"), so these will disappear from solutions offered which have not been generated yet... and so you converge quicker to the solution that you are looking for. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#663134: aptitude: safe-upgrade fails on libgcc1 version skew
Control: tags -1 + moreinfo Hi, 2012-03-10 10:00 Sven Joachim: 2. Insert some logic to not mark packages violating the multiarch lockstep requirement, thereby avoiding invoking the resolver and the resulting status messages. Option 2 is easy, but personally I'd like to avoid it because it is an extra layer on top of the native APT implementation of the multiarch spec (i.e. implicit Breaks: self on these packages). Also, aptitude's behaviour would internally deviate from apt-get's even though the results would appear similar. There is also the theoretical possibility that the requirement to upgrade "M-A:same" packages in lockstep might be lifted some day (Guillem proposed this, but was apparently convinced/persuaded not to do this). There are people talking about this from time to time, because it's annoying at several levels, specially when some arches are at different binNMU levels than others. People have pinged the bug lately, I forgot which one it is. In general, I think that this is a transient problem only affecting unstable (as far as I can tell) and in the vast majority of cases only for a few hours until the version becomes available, and that it might be solved by another means. So this has been happening for a few years already and maybe it's not fixed soon, but the lazy person in me still thinks that the best option is "wait and see" :-) Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#615481: Package flags handling broken
Control: tags -1 - moreinfo Control: close -1 2016-03-18 16:52 GMT+00:00 Yuri D'Elia <wav...@thregr.org>: > On Fri, Mar 18 2016, Manuel A. Fernandez Montecelo > <manuel.montez...@gmail.com> wrote: >> So the observed behaviours reported seem to be addressed, at least in >> the general case. There are some other open reports about (mis)handling >> of automatic flags pending to investigate, and there might be some cases >> still lurking. > > Yes, the current version of aptitude seem to have corrected many > problems with the auto flags. > > You can close this report. Good that things have improved, and thanks for the feedback. Closing the bug now. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#817547: [Aptitude-devel] Bug#817547: aptitude: Download size miscalculated (not re-calculated?) after an TUI install run
Control: tags -1 + pending Hi, 2016-03-09 23:34 To Axel Beckert: Hi Axel, 2016-03-09 20:58 Axel Beckert: Hi again, Axel Beckert wrote: At the end I pressed enter where it says "Press Return to continue." On top, aptitude says "Disk: +36.9 kBDL: 109 MB/109 MB" despite only "sassc" is marked as being installed which needs 36.9 kB disk space if installed I think these "109MB" are wrong here since just installing sassc surely can't cause over 100MB of needed downloads. If I quit aptitude with "q" + "y" and start it again with "aptitude", that line only says "Disk: +36.9 kB DL: 0 B/11.5 kB" which approximately what I expect. That's strange. If the installation is successful, seems to work fine. Reinstalling packages also produce strange effects, I haven't been able to find a proper pattern yet. I think that part of the problem is that the signals when updated the planned action of the package are not emitted as they should, or at least as I expected. Needs more investigation... I think that I fixed the problem, at least in all the cases that I tested (including the failure to install sassc and pysassc [1]), by resetting the information when the internal pkgcache is closed (which is done before running dpkg, for example). In any case, please do keep an eye on this in the near future just in case (I am sure that you'll do it even if I don't ask :) ). [1] sassc fails: Unpacking sassc (3.3.2-3) ... dpkg: error processing archive /var/cache/apt/archives/sassc_3.3.2-3_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/sassc.1.gz', which is also in package pysassc 0.9.3-1 Processing triggers for libc-bin (2.21-9) ... Processing triggers for man-db (2.7.5-1) ... Errors were encountered while processing: /var/cache/apt/archives/sassc_3.3.2-3_amd64.deb These 3 get installed: Setting up libsass0:amd64 (3.3.3-1) ... Setting up python-libsass (0.9.3-1) ... Setting up pysassc (0.9.3-1) ... And afterwards, once the curses thing is reloaded, sassc remains to be installed and the DL size field shows: DL: 0 B/11.5 kB Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#246672: aptitude: quit directly instead of pressing a key to continue
Control: tags -1 + pending 2016-03-11 13:12 martin f krafft: also sprach Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> [2016-03-11 00:22 +0100]: So having that into account, what's the reply to the question above? It seems a bit too much to have to return to ncurses and let aptitude not only rebuild its cache, but also build views etc. So implemented now. Despite the modest amount of changes in the end, there was lots of time involved in solving this and other problems found in the way, causing crashes or undesired effects when trying to do more direct things like "exit()", "cwidget::toplevel::shutdown()" and others in sequence, etc. Currently it seems to work fine, but there is a slight chance that it needs to be pulled out if it still crashes under some conditions that were not tested. The commit comment follows. [curses] Be able to Quit after dpkg run (Closes: #246672) The current implementation seems to work, but the handling of these issues is a bit brittle and with lots of circular dependencies, with signals and events happening everywhere. E.g view (cwidget objects) being reloaded automatically when cache is reloaded, while cwidget is supended for dpkg run. The initial events trigger further updates and triggers using cwidget objects and other structures, sometimes depending on different options being enabled or how the curses mode was launched (e.g. "visual preview", or "solution screen"). In any case, the cache needs to be reloaded (and with it, state saved to disk) to perform some updates/cleanup after dpkg runs, like resetting "reinstall" state when done (the "save pending reinstall" was implemented in this version), or unmarking upgraded packages as needing upgrade after the version has been upgraded to the desired one (bug fixed in this version, when aptitude was not acknowledging the "upgrade" as having taken place, and still marking it as update in the next runs). Presumably all of these complications are why this hand't been implemented before, in all the intervening years. Still I thought that it was worth to implement it now because it will now at least save the user/system from spending time in some of the curses actions, save a few extra keystrokes, and with it a few seconds (specially in slower systems) having to keep an eye just for quitting. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#818046: cwidget: keybindings::get(std::string tag) should use tag as case-insensitive
Source: cwidget Version: 0.5.17-4 Severity: important When inserting with set() the tag it's stored as uppercase, so get() should do the same transformation, otherwise it's confusing and appears to be buggy. -- Manuel
Bug#721358: coreutils: use dummy man when cross build
User: helm...@debian.org Usertags: rebootstrap 2016-03-12 17:03 To Eleanor Chen: Hi, 2013-08-30 18:03 Eleanor Chen: Package: src:coreutils During cross build help2man may not run leading FTBFS, it would be good if it uses dummy-man. Here is the patch for it, but I'm not sure if it's an appropriate solution. It would be very beneficial to have this patch applied, or an equivalent solution, for cross-compilation / bootstrapping. Several ports are in the works again, and being able to rebootstrap easily and quickly such a fundamental package as coreutils is a very worthwhile thing to have in some cases. Of course the manual pages would not be "valid" initially, but even without native recompilations of the same versions once (re)bootstrapped, this would auto-heal when newer versions of the package enter in the archive and get compiled for the new architecture. Other possibilities suggested by Helmut include: - ship pre-generated manual pages (probably a bit involved) - to not build man pages with "nodoc" build options / profiles (so cross-compilation could use this profile/options) - have "Build-Depends: $self:native " and run help2man on the binaries instead. The latter has been applied for flex, for example, the patch is not very intrusive: https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=flex_help2man.debdiff;bug=762180;att=1;msg=5 If you are happy to apply this and prefer this solution, we can prepare a patch. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#721358: coreutils: use dummy man when cross build
Hi, 2013-08-30 18:03 Eleanor Chen: Package: src:coreutils During cross build help2man may not run leading FTBFS, it would be good if it uses dummy-man. Here is the patch for it, but I'm not sure if it's an appropriate solution. It would be very beneficial to have this patch applied, or an equivalent solution, for cross-compilation / bootstrapping. Several ports are in the works again, and being able to rebootstrap easily and quickly such a fundamental package as coreutils is a very worthwhile thing to have in some cases. Of course the manual pages would not be "valid" initially, but even without native recompilations of the same versions once (re)bootstrapped, this would auto-heal when newer versions of the package enter in the archive and get compiled for the new architecture. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#775942: FTCBFS for multilib enabled architectures
2016-03-12 16:08 László Böszörményi (GCS): On Sat, Mar 12, 2016 at 2:27 PM, Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> wrote: 2015-01-24 18:43 Guillem Jover: Alternatively, the multilib packages could just be dropped (at least in experimental), given that the only package currently Build-Depending on them in the archive (gdb for its gdb64 package) has now stopped building the package and I expect should stop Build-Depending on it soon in experimental. This way we simplify our build processes, and move further into using proper multiarch. Attached patch does exactly that (only build tested). Would be possible to drop these packages now? There are some ports in the works right now that would probably benefit from this. A new release is expected soon, will drop the packages then. Otherwise I'll drop those anyway in some days. That's great to hear, thanks! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#755287: src:libmng: Please upload new version
Hi again, 2016-03-12 13:13 To Kartik Mistry: 2016-03-12 13:06 GMT+00:00 Kartik Mistry <kartik.mis...@gmail.com>: On Sat, Mar 12, 2016 at 6:11 PM, Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> wrote: I don't know what happened but this is still not in Debian, was the new version rejected by FTP masters for some reason? After this message welcoming changes and the package being in LowNMU list, I took the liberty to check-out the repo and make some minimal changes (modify the changelog with Closes of bug reports submitted at the time of afterwards, and apply Helmut Grohne's patch). Thanks a lot. Mostly I forgot after changes were made. Let me check. If I don't respond back in a day - feel free to NMU as usual! According to the BTS, Tobias did upload to DELAYED/5, so something must have happened. Also I just contacted Helmut because when testing, his patch doesn't seem to apply anymore (maybe it's because of the additional dh_autoreconf step that was added for 2.0.2). Working along with Helmut, he determined that the problem was to use -cc instead of -gcc. So I pushed one more change: Use "CC = $(DEB_HOST_GNU_TYPE)-gcc" instead of "-cc" Things build fine and lintian only complains about the latest policy standard version, non-nmu revision (since you signed it, it's not a NMU anymore), and some formatting stuff in d/copyright. Since you are active now and this needs some package-specific knowledge (that I don't have) to deal with rdeps and so on, should I understand that you'll take care of this, or do you prefer me to handle the upload and transition? Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#775942: FTCBFS for multilib enabled architectures
Hi, 2015-01-24 18:43 Guillem Jover: Hi! On Wed, 2015-01-21 at 20:07:54 +0100, Helmut Grohne wrote: Source: expat Version: 2.1.0-6 Tags: patch User: helm...@debian.org Usertags: rebootstrap Trying to cross build expat for e.g. powerpc results in a build failure during dh_strip. It built lib64expat1 using "gcc -m64" which produced amd64 objects instead of ppc64 objects which powerpc-linux-gnu-strip does not understand. I am attaching a patch that changes the build inject a suitable CC variable which makes cross building expat work. Alternatively, the multilib packages could just be dropped (at least in experimental), given that the only package currently Build-Depending on them in the archive (gdb for its gdb64 package) has now stopped building the package and I expect should stop Build-Depending on it soon in experimental. This way we simplify our build processes, and move further into using proper multiarch. Attached patch does exactly that (only build tested). Would be possible to drop these packages now? There are some ports in the works right now that would probably benefit from this. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#760762: expat: Please build a debug package
Hi, (randomly passing by and commenting...) 2014-09-07 18:03 Laurent Bigonville: Source: expat Version: 2.1.0-6 Severity: wishlist Hi, Would be nice if libexpat had a -dbg package with its debug symbols. I think that this is not necessary now that we have -dbgsym, so probably this can be closed. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#755287: src:libmng: Please upload new version
2016-03-12 13:06 GMT+00:00 Kartik Mistry <kartik.mis...@gmail.com>: > On Sat, Mar 12, 2016 at 6:11 PM, Manuel A. Fernandez Montecelo > <manuel.montez...@gmail.com> wrote: >> I don't know what happened but this is still not in Debian, was the new >> version rejected by FTP masters for some reason? >> >> After this message welcoming changes and the package being in LowNMU >> list, I took the liberty to check-out the repo and make some minimal >> changes (modify the changelog with Closes of bug reports submitted at >> the time of afterwards, and apply Helmut Grohne's patch). > > Thanks a lot. Mostly I forgot after changes were made. Let me check. > If I don't respond back in a day - feel free to NMU as usual! According to the BTS, Tobias did upload to DELAYED/5, so something must have happened. Also I just contacted Helmut because when testing, his patch doesn't seem to apply anymore (maybe it's because of the additional dh_autoreconf step that was added for 2.0.2). Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#755287: src:libmng: Please upload new version
Hi, 2014-08-04 10:40 Kartik Mistry: On Sun, Aug 3, 2014 at 11:39 AM, Tobias Frost <t...@debian.org> wrote: I've prepared a package for the new libmng upstream version 2.0.2. Please see attached diff (ONLY the debian directory given.) NOTE: The diff is against 1.0.10-3, not against the NMU I just uploaded to DELAYED/5 As the soname changes, the target is experimental to prepare for an transition. Wonderful. I'm at VAC right now and possible for you to update, collab-maint/libmng.git repo with NMU or direct upload? I will be happy to see commits done there! I don't know what happened but this is still not in Debian, was the new version rejected by FTP masters for some reason? After this message welcoming changes and the package being in LowNMU list, I took the liberty to check-out the repo and make some minimal changes (modify the changelog with Closes of bug reports submitted at the time of afterwards, and apply Helmut Grohne's patch). Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#709623: src:zlib: patch using build profiles
Hi, 2015-01-21 19:37 Guillem Jover: Hi! On Wed, 2015-01-21 at 18:51:11 +, Mark Brown wrote: On Wed, Jan 21, 2015 at 06:38:56PM +0100, Guillem Jover wrote: > A patch can be easily provided if you'd agree with this! I'm not going to look at this until after the release, sorry. I had been intending to just drop the cross packages then already so need to provide a patch. (I'm assuming there's a missing "no" there?) Ah sorry, it was not meant as requesting a change during the freeze, this just came up now as a possible preferable solution and wanted to note it down here. It's great if you were already planning on dropping those packages after the freeze. Are the any plans to go ahead with this? This would be a good time to do it, the next freeze is not that far away (although it's now delayed a wee bit), and there are several ports in the works that would probably benefit from this. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#807516: python-hdate is wrongly marked Multi-Arch: foreign
Hi,
2015-12-09 23:02 Helmut Grohne:
Package: python-hdate
Version: 1.6-3
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
In processing bug #757113, it seems that too much multiarch got applied.
The python-hdate package contains a python extension and thus cannot be
marked Multi-Arch: foreign.
The correct solution to #757113 is to the patch in #792874.
Maintainers, would you mind us applying this as a NMU?
The patch is minimal, but it's needed to be able to cross-build
important packages for bootstrapping such as bsdmainutils and its
rev-deps.
diff --minimal -Nru libhdate-1.6/debian/control libhdate-1.6/debian/control
--- libhdate-1.6/debian/control 2015-08-17 14:46:34.0 +0200
+++ libhdate-1.6/debian/control 2015-12-09 23:54:06.0 +0100
@@ -26,7 +26,6 @@
Package: python-hdate
Section: python
Architecture: any
-Multi-Arch: foreign
Provides: ${python:Provides}
Depends: libhdate1 (= ${binary:Version}), ${python:Depends}, ${shlibs:Depends},
${misc:Depends}
Description: Provides a library that help use hebrew dates (python bindings)
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#817776: [aptitude] SIGABRT when quitting curses mode after unresolvable conflicts
2016-03-11 6:28 GMT+00:00 Katsuhiko Nishimra <ktns...@gmail.com>: > Hi, > > On Fri, Mar 11, 2016 at 01:56:21AM +0000, Manuel A. Fernandez Montecelo wrote: >> 2016-03-11 1:51 GMT+00:00 Katsuhiko Nishimra <ktns...@gmail.com>: >> >> >> >> The problem is that I cannot reproduce the situation by getting the >> >> "Resolve these dependencies by hand?", so I cannot test whether it >> >> worked or not. >> > Is the fixed package or the patch available? >> > If I can get it, I'll test it and report you a result. >> >> Yes, it is: >> >> https://anonscm.debian.org/cgit/aptitude/aptitude.git/commit/?id=63017db3cd7593b2494d77b3f220912df21ed738 > > I've confirmed the SIGABRT has gone after applying this patch. > > Many thanks to your resolution. Thanks for the confirmation :-) -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#817776: [aptitude] SIGABRT when quitting curses mode after unresolvable conflicts
2016-03-11 1:51 GMT+00:00 Katsuhiko Nishimra <ktns...@gmail.com>: >> >> The problem is that I cannot reproduce the situation by getting the >> "Resolve these dependencies by hand?", so I cannot test whether it >> worked or not. > Is the fixed package or the patch available? > If I can get it, I'll test it and report you a result. Yes, it is: https://anonscm.debian.org/cgit/aptitude/aptitude.git/commit/?id=63017db3cd7593b2494d77b3f220912df21ed738 Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#246672: aptitude: quit directly instead of pressing a key to continue
2016-03-10 18:54 martin f krafft: also sprach Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com> [2016-03-10 18:04 +0100]: I don't know if your complaint is more the speed side of reloading the cache, or that you just don't see the need and don't want curses to be restored just for quitting. In the latter case, maybe it would not be very difficult to implement what you ask, but the reloading of the cache would continue to be there. Shouldn't the reloading of the cache happen in the background right away? Why do I need to hit a key for it to start. Instead, start it right away, and let the user hit a key to continue or 'q' to quit. If s/he continues, then the UI can pick up the background process. If 'q' is pressed instead, say that "aptitude is shutting down" until the background process returns. Would be a nice idea, but aptitude is absolutely not ready to do this in the short or medium term. That is, not going to happen anytime soon for this particular case. So having that into account, what's the reply to the question above? Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#246672: aptitude: quit directly instead of pressing a key to continue
Control: tags -1 + moreinfo Hi, 2004-04-30 11:10 martin f krafft: Package: aptitude Version: 0.2.14-3 Severity: wishlist When aptitude finished installing packages, it would be nice to have it say "Please press 'q' to quit or any key to continue". ctrl-c seems to work, but it's not very nice to just SIGINT the running process like that, especially because the terminal sometimes gets messed up then. 2011-12-14 08:08 Daniel Hartwig: When aptitude finished installing packages, it would be nice to have it say "Please press 'q' to quit or any key to continue". ctrl-c seems to work, but it's not very nice to just SIGINT the running process like that, especially because the terminal sometimes gets messed up then. Whilst it is possible to SIGINT at that point, there are subtle reasons why you might not want to do that. See #429388 for some discussion of the issue. With aptitude's current state tracking it does not look like it is possible to avoid the cache reload (i.e. exit quickly) after running dpkg and keep the cache consistent. There are some other reasons, like aptitude being able to detect packages to be "upgraded"/"downgraded" once the action is performed. If a package is marked for upgrade and was indeed upgraded by dpkg but aptitude doesn't refresh the information in its database (we had bug #721426 related with that), and then "apt update" happens somewhere, the package will be marked for upgrade the next time that aptitude is fired-up. So basically aptitude needs to re-read the status of the system and write back its own database, which is what takes longer when coming back to curses mode (which is what the merged bug #296726 complains about). I don't know if your complaint is more the speed side of reloading the cache, or that you just don't see the need and don't want curses to be restored just for quitting. In the latter case, maybe it would not be very difficult to implement what you ask, but the reloading of the cache would continue to be there. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#157984: aptitude: better open/close fold shortcut
Control: tags -1 + moreinfo #157984 (with merged #168427), #415449 and #241945 have similar suggestions, but slightly different -- if not worth a merge, at least can be considered at the same time. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#497727: many commands append trailing blanks
Control: tags -1 + wontfix Hi, 2008-09-02 21:57 jida...@jidanni.org: Package: aptitude Version: 0.4.11.9-1 Severity: wishlist Many commands append trailing blanks. # aptitude search bash|grep -c ' $' 2 This is because of virtual packages with empty descriptions, but it doesn't always happen. $ aptitude search base-files |grep -c ' $' 0 # aptitude why desktop-file-utils|grep -c ' $' 3 This one produces zero now. No big deal to some, but for full bladder control do fix one day. $ dpkg -l bash\*|grep -c ' $' 0 $ apt-cache search apt|grep -c ' $' 0 I don't understand what's the harm in having some extra blanks, why it would be of any benefit to remove them, or why we should spend time tracking those cases that produce extra blanks. Part of the reason why aptitude works in this way it's because it uses common code with the curses interface and e.g. tries to make columns even in command-line mode (although if piped/redirected since recently, does --disable-columns). In some cases if the columns are blank or there are similar conditions, these effects of having extra blanks are produced. Sharing code is a bigger benefit than trying to not have some extra blanks, even if that was a worthwhile goal to pursue. So +wontfix. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#270909: aptitude: speed
Control: tags -1 + wontfix 2004-09-09 18:27 Dan Jacobson: Package: aptitude Version: 0.2.15.2-1 Severity: wishlist If you get spare time, one day soup-up aptitude so it is as fast as the competition: $ time apt-cache show lsb>&- real0m0.012s user0m0.007s sys 0m0.005s $ time aptitude show lsb>&- real0m1.265s user0m1.202s sys 0m0.062s I've been spending some time optimizing several things as part of 0.7.7. aptitude is much more complex than apt-get in the sense than it links to many more libraries, has curses interface (same binary), etc; not even talking about apt-cache that does even less. Additionally, there are many features from aptitude that are used in "show", like: showing debtags, user-tags, and this needs to read the debtags DB and other things, which makes things slower. "show -v" shows several version of the package, so it has to scan further. There are aptitude-specific features on top of that, e.g.: - checking if the package is "Automatically installed" (feature which apt has now in another database, that apt-cache doesn't seem to read so "apt-cache show" doesn't include) - "Forbidden", etc. - or the fact that "aptitude show" works with patterns So comparing the two without having into account the extra features doesn't really make sense, we are not going to remove the extra features to improve the times anyway. Lastly, the comparison is showing a simple case where the package does not exist or is virtual. The times are very different and the gap much smaller for cases with the (newer) "apt" interface when matching packages with variable names (even if aptitude continues to do more things in this case): $ time apt show aptitude-commo. >&- WARNING: apt does not have a stable CLI interface. Use with caution in scripts. real0m0.417s user0m0.412s sys 0m0.000s $ time aptitude show ~n^aptitude-common$ >&- real0m0.670s user0m0.640s sys 0m0.024s ... so in summary, the comparison was apples with oranges, when it's apples and apples the difference is not very high. And I don't think that it's worth spending time optimising for cases which take less than a second anyway, there are many other priorities in aptitude right now (and have been for a long time), so marking as +wontfix. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#721426: aptitude: packages are sometimes selected for upgrade by default just after aptitude is started
Control: tags -1 - moreinfo + pending Hi, 2016-03-09 15:31 Vincent Lefevre: But I notice the same issue on a different machine, where last in /var/log/aptitude, I get: Aptitude 0.7.8: log report Mon, Mar 7 2016 14:22:40 +0100 but: -rw-r--r-- 1 root root 9490347 2016-03-07 14:04:58 pkgstates -rw-r--r-- 1 root root 9489801 2016-03-07 14:03:27 pkgstates.old with lots of "Upgrade: yes" in pkgstates (all these packages are at their latest version, so that the bug is not visible when running aptitude). I detected the (I think) only one case where it didn't remove "Upgrade: yes" lines as soon as the package is in the desired version, and forces to write pkgstates in that case, so I think that this will be fixed now. If this keeps happening in the next versions, please reopen. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#686626: aptitude Bug#686626: Should not arch-qualfy arch-less packages on dpkg calls
Control: owner -1 ! Control: tags -1 +pending 2012-09-09 01:03 Daniel Hartwig: Directly, this only concerns “Reconfigure package” action in the interactive interface Feature to be removed, so bug marked as +pending. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
