[Aptitude-devel] Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

On 2024-04-30 11:49:57 +0200, Julian Andres Klode wrote: > This bug has since been reassigned to aptitude. Solver limitations > in aptitude wrt t64 handling should not be considered release critical, > it makes no sense to remove aptitude from testing for it; there are > still plenty of other

[Aptitude-devel] Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

Hi, On 2024-04-28 19:21:18 -0300, Facundo Gaich wrote: > Today I upgraded one of my unstable machines and saw several instances of > something I believe is the same bug. The resolver seems to be failing to > choose to upgrade certain dependencies. What's more, in the aptitude GUI > I can see the

[Aptitude-devel] Bug#1064969: aptitude: broken dependency resolution

Control: found -1 0.8.13-6 Control: retitle -1 aptitude: broken dependency resolution Bug still present. For instance, the following works as expected: cventin:~> aptitude install -s grub-common libefiboot1t64 libefivar1t64 The following NEW packages will be installed: libefiboot1t64

[Aptitude-devel] Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

And on a 3rd machine, where I used aptitude --log-file=/tmp/aptitude.log --log-level=info dpkg: dependency problems prevent removal of libb2-1:amd64: libqt6core6t64:amd64 depends on libb2-1 (>= 0.98.1). dpkg: error

[Aptitude-devel] Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

The same problem occurred on another machine, with other packages: dpkg: dependency problems prevent removal of libjte2:amd64: libisofs6t64:amd64 depends on libjte2. dpkg: error processing package libjte2:amd64 (--purge): dependency problems - not removing (Reading database ... 708510 files

[Aptitude-devel] Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

On 2024-03-07 17:15:05 +, Simon McVittie wrote: > I can confirm that version 2.24.33-4 of libgtk2.0-common, libgtk2.0-0t64 > and libgtk2.0-bin are, in fact, installable (I have them installed > right now). I can't see any dependency relationships between them that > look suspicious. > > If

[Aptitude-devel] Bug#1065605: aptitude: useless backup of pkgstates

Package: aptitude Version: 0.8.13-5+b2 Severity: minor I ran aptitude to do an upgrade from the TUI (dpkg failed), then quit just after it. This was before 11:28, since I reported this failure at this time. But /var/lib/aptitude contains -rw-r--r-- 1 root root 10438852 2024-03-07 11:29:40

[Aptitude-devel] Bug#1065554: Bug#1065554: aptitude: the TUI silently breaks a "Recommends"

On 2024-03-06 21:36:09 +0100, Axel Beckert wrote: > Hi Vincent, > > Vincent Lefevre wrote: > > Do you need the bundle? > > Actually that would be interesting, as I have a vague idea how it > might have been triggered and would like to experiment a bit if I can > find a

[Aptitude-devel] Bug#1065554: Bug#1065554: aptitude: the TUI silently breaks a "Recommends"

On 2024-03-06 16:47:47 +0100, Axel Beckert wrote: > Hi Vincent, > > Vincent Lefevre wrote: > > The aptitude TUI silently breaks a "Recommends": > > I've seen also already seen this, but so far it always was for a > reason here: > > * On multiar

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

And even in a simple case line cnee: qaa:~> aptitude install -s cnee The following packages will be REMOVED: libxnee0{u} The following packages will be upgraded: cnee{b} 1 packages upgraded, 0 newly installed, 1 to remove and 263 not upgraded. Need to get 50.4 kB of archives. After

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

On 2024-02-28 17:28:51 +0100, Sven Joachim wrote: > No, in this case it is a problem with aptitude's resolver which > manifests itself due to the following configuration setting: > > > Aptitude::ProblemResolver::SolutionCost "safety, removals"; > > This does cause aptitude to hold apt back by

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

On 2024-02-29 14:11:41 +0900, Simon Richter wrote: > Hi, > > On 2/28/24 23:49, Vincent Lefevre wrote: > > > # aptitude install apt > > The following packages will be upgraded: > >apt{b} apt-doc > > 2 packages upgraded, 0 newly installed, 0 to remove and 18

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

On 2024-02-28 18:32:20 +0100, Vincent Lefevre wrote: > OK, but it appears that now, there are *many* other packages in > a similar situation, and sometimes, aptitude wants to remove a > potentially important package (see below). The resolution should > be automatic in case of pa

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

On 2024-02-28 17:28:51 +0100, Sven Joachim wrote: > On 2024-02-28 15:49 +0100, Vincent Lefevre wrote: > > So, I suppose that this is also the case for aptitude: if aptitude > > cannot upgrade just because of a rename, then this is a problem in > > the involved packages.

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

On 2024-02-28 15:56:56 +0100, Julian Andres Klode wrote: > aptitude is not our chosen tool for distribution upgrades, as such > failures there are not release critical for the packages. So while > this is release critical for aptitude, it's a wishlist bug for apt > that probably would end up being

[Aptitude-devel] Bug#1061734: aptitude: in TUI, incorrect "will be automatically removed because of dependency errors" message

Note that there was a similar bug in the past (2005, fixed in 2016): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342835 with title: aptitude: "X will be automatically removed because of dependency errors:" then no errors shown On 2024-01-29 11:20:45 +0100, Vincent Lef

[Aptitude-devel] Bug#1061734: aptitude: in TUI, incorrect "will be automatically removed because of dependency errors" message

Package: aptitude Version: 0.8.13-5+b1 Severity: normal When I choose to upgrade swig from the TUI, I get the incorrect message swig4.0 (remove, 4.1.0-0.3) will be automatically removed because of dependency errors:

[Aptitude-devel] Bug#1059071: aptitude: wants to remove a package, breaking a dependency

I've noticed that this isn't included by default. I'm using Aptitude::ProblemResolver::SolutionCost "safety, removals"; -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC

[Aptitude-devel] Bug#1056959: aptitude: can't upgrade wireshark to 4.2.0-1 without explicitly upgrading wireshark-common or removing wireshark-qt

Package: aptitude Version: 0.8.13-5 Severity: normal With the aptitude TUI or command line, it is not possible to upgrade wireshark to 4.2.0-1 without explicitly upgrading wireshark-common too or removing wireshark-qt. With both interfaces, the proposed default is to keep both wireshark and

[Aptitude-devel] Bug#1051923: aptitude: incorrect dependency resolution for ghostscript vs virtual package ghostscript-x

And ghostscript 10.02.0~dfsg-2 has just appeared. Its changelog says * declare that ghostscript replaces older ghostscript-x so that now Package: ghostscript Version: 10.02.0~dfsg-2 Installed-Size: 180 Maintainer: Debian QA Group Architecture: amd64 Replaces: ghostscript-x (<<

[Aptitude-devel] Bug#1051923: aptitude: incorrect dependency resolution for ghostscript vs virtual package ghostscript-x

Note that just in case this would matter, I have several packages that depend on ghostscript-x: gv pspresent xournal -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project

[Aptitude-devel] Bug#1051923: aptitude: incorrect dependency resolution for ghostscript vs virtual package ghostscript-x

Package: aptitude Version: 0.8.13-5 Severity: normal I have the following ghostscript-related packages installed: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)

[Aptitude-devel] Bug#1042897: aptitude: viewing a package's changelog from the TUI outputs a warning that is immediately erased

On 2023-08-05 13:04:56 +0200, Sven Joachim wrote: > Ah yes, Guillem implemented the "verbose" option three years ago in > reaction to #967911. And it could not be used back then because the > dpkg version offering it was only uploaded several months later, but now > it certainly can be used. :-)

[Aptitude-devel] Bug#1042897: aptitude: viewing a package's changelog from the TUI outputs a warning that is immediately erased

On 2023-08-04 18:06:24 +0200, Sven Joachim wrote: > On 2023-08-04 01:57 +0200, Vincent Lefevre wrote: > > > On 2023-08-03 16:52:07 +0200, Sven Joachim wrote: [...] > >> It should prevent these errors from showing up in the first place. > > > > If aptitude knows wh

[Aptitude-devel] Bug#1043050: aptitude: incorrect exit value in aptitude-changelog-parser

Package: aptitude Version: 0.8.13-5 Severity: normal Tags: patch /usr/bin/aptitude-changelog-parser has: eval { require Dpkg::Changelog::Parse; Dpkg::Changelog::Parse->import(); 1; } or do { warn "warning: Dpkg::Changelog::Parse not present, install libdpkg-perl\n"; exit 0;

[Aptitude-devel] Bug#1042897: aptitude: viewing a package's changelog from the TUI outputs a warning that is immediately erased

On 2023-08-03 16:52:07 +0200, Sven Joachim wrote: > On 2023-08-02 15:51 +0200, Vincent Lefevre wrote: > > Package: aptitude > > Version: 0.8.13-5 > > Severity: normal > > > > When I use "C" (View a package's changelog) on clang-15 from the > >

[Aptitude-devel] Bug#1042897: aptitude: viewing a package's changelog from the TUI outputs a warning that is immediately erased

Package: aptitude Version: 0.8.13-5 Severity: normal When I use "C" (View a package's changelog) on clang-15 from the aptitude TUI, I get a warning that is immediately erased, so that it is impossible to read it. I suppose that aptitude should redirect stderr from aptitude-changelog-parser so

[Aptitude-devel] Bug#933335: aptitude: Please add support for dpkg frontend lock

Control: found -1 0.8.13-5 Just to say that this still occurs. The error message is now [...] Setting up apt (2.6.1) ... dpkg: error: dpkg frontend lock was locked by another process with pid 4191235 Note: removing the lock file is always wrong, can damage the locked area and the entire system.

[Aptitude-devel] Bug#1033558: aptitude-common: aptitude-curses.8.gz man page: unclear/wrong text for Example 12

Package: aptitude-common Version: 0.8.13-5 Severity: minor When searching for "Example" in the aptitude-curses(8) man page, I get: Example 12. Usage of --show-summary --show-summary used with -v to display all the reasons a package is installed: There are several issues. 1. Why "12"

[Aptitude-devel] Bug#1033556: aptitude: "aptitude --show-summary=all-packages why ..." outputs the wrong package for Provides

Package: aptitude Version: 0.8.13-5 Severity: normal Consider for instance: $ aptitude why mailutils i muttprint Recommends mutt | sylpheed | gnus | xfmail | exmh | mail-reader i A mailutils Provides mail-reader Here, one can see that mailutils provides mail-reader. $ aptitude

[Aptitude-devel] Bug#1033357: Bug#1033357: aptitude: TUI does not display all error messages

On 2023-03-23 19:23:58 +0100, Axel Beckert wrote: > Ran into this today, too. I think we had this already when bullseye > switched from testing to stable or so and I think there's a bug report > for this, too, already. Will search later for that one. I don't remember about this one, but there was

[Aptitude-devel] Bug#1033359: aptitude: should propose to update the Codename value, like apt

Package: aptitude Version: 0.8.13-5 Severity: wishlist With "aptitude update", I get: [...] Get: 31 https://ftp.debian.org/debian experimental InRelease [101 kB] E: Repository 'https://ftp.debian.org/debian experimental InRelease' changed its 'Codename' value from 'experimental' to 'rc-buggy'

[Aptitude-devel] Bug#1033357: aptitude: TUI does not display all error messages

Package: aptitude Version: 0.8.13-5 Severity: minor I've got the following error message from the TUI (with 'u' to update): ┌──┐ │E: Failed to download some files ▒│ │W: Failed

[Aptitude-devel] Bug#1032654: Bug#1032654: aptitude: missing message about the Debian bookworm change concerning non-free-firmware

On 2023-03-11 19:16:52 +0100, Axel Beckert wrote: > > This message should have been displayed by aptitude. > > Did you test "aptitude update" or "aptitude -u" or both? I've tried 'u' from the aptitude TUI, "aptitude update" and "aptitude -u". No messages. > > Without it, the user who uses

[Aptitude-devel] Bug#1032654: aptitude: missing message about the Debian bookworm change concerning non-free-firmware

Package: aptitude Version: 0.8.13-5 Severity: important I'm using testing+unstable, and Debian changed the non-free component to "non-free non-free-firmware" some time ago, and nothing has been announced. I've recently learnt that with apt 2.6, a message is output about that with "apt update",

[Aptitude-devel] Bug#1030643: aptitude: buggy handling of "Provides:" when trying to remove a package

Package: aptitude Version: 0.8.13-5 Severity: normal When I want to remove the libldap2-dev transitional package from the command line, I get: cventin:~> aptitude remove -s libldap2-dev The following packages will be REMOVED: libldap-dev{u} libldap2-dev 0 packages upgraded, 0 newly

[Aptitude-devel] Bug#979186: Bug#979186: Bug#979186: aptitude: in the TUI, "+" changes the version of some packages in an inconsistent way

Control: found -1 0.8.13-5 On 2021-02-14 12:28:00 +0100, Vincent Lefevre wrote: > On 2021-01-04 11:35:46 +0100, Axel Beckert wrote: > > Will have a closer look later, earliest this evening. > > Any news? This occurred again: i libc-bin 2.35-1

[Aptitude-devel] Bug#1019465: Bug#1019465: aptitude: wants to remove the required package lsb-base with a broken reason

Hi Axel, On 2022-09-10 15:34:50 +0200, Axel Beckert wrote: > Vincent Lefevre wrote: > > After marking some packages for upgrade, I get: > > > > --\ Packages being deleted due to unsatisfied dependencies (1) > > id lsb-base -50.2 kB 11.2

[Aptitude-devel] Bug#1019465: aptitude: wants to remove the required package lsb-base with a broken reason

Package: aptitude Version: 0.8.13-5 Severity: important After marking some packages for upgrade, I get: --\ Packages being deleted due to unsatisfied dependencies (1) id lsb-base -50.2 kB 11.2 11.2 with Linux Standard Base init script functionality lsb-base

[Aptitude-devel] Bug#1013075: aptitude: "aptitude why" outputs a chain with a package that is not installed

Package: aptitude Version: 0.8.13-4 Severity: normal zira:~> aptitude why gobject-introspection i libglib2.0-dev Suggests libgirepository1.0-dev (>= 1.62) p libgirepository1.0-dev Depends gobject-introspection (= 1.72.0-1+b1) while libgirepository1.0-dev isn't installed. So

[Aptitude-devel] Bug#940819: aptitude: meaningless message "it is being removed because..." / issue with ORed dependency

Control: found -1 0.8.13-3 This time with: --\ Packages being automatically installed to satisfy dependencies (1) piA rlfe +50.2 kB 8.1-2 --\ Packages being removed because they are no longer used (2) idA ledit-313 kB 2.04-5 2.04-5

[Aptitude-devel] Bug#999766: aptitude: in the TUI, with "+m" on a piA package, aptitude doesn't remember the manually installed state

On 2021-11-16 14:53:15 +0100, Vincent Lefevre wrote: > I've output debug information with the following two cases, quitting > after step 6: > * '+' is used (before 'm'); > * '+' is not used. > > The only differences with --log-level=debug (after filtering out > the pr

[Aptitude-devel] Bug#999766: aptitude: in the TUI, with "+m" on a piA package, aptitude doesn't remember the manually installed state

Package: aptitude Version: 0.8.13-3 Severity: normal With ksh 2020.0.0+really93u+20120801-10 installed and ksh93u+m not yet installed, I have the following issue (always reproducible): # aptitude 1. I type 'U' to upgrade. I get aptitude 0.8.13 @ cventin #Broken: 1 Disk: -151 MB DL:

[Aptitude-devel] Bug#979186: Bug#979186: Bug#979186: aptitude: in the TUI, "+" changes the version of some packages in an inconsistent way

Control: found -1 0.8.13-3 (reproducible with the bundle) Hi, On 2021-01-04 11:35:46 +0100, Axel Beckert wrote: > Will have a closer look later, earliest this evening. Any news? -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

[Aptitude-devel] Bug#980035: Bug#980035: aptitude: segmentation fault when starting aptitude

On 2021-01-14 02:14:29 +0100, Axel Beckert wrote: > Since Julian has uploaded a fix as apt/2.1.18, would you mind checking > if you can still reproduce the issue in any way? I couldn't manage to reproduce it with apt 2.1.18. -- Vincent Lefèvre - Web: 100% accessible

[Aptitude-devel] Bug#980053: Bug#980035: Bug#980035: aptitude: segmentation fault when starting aptitude

[moved to Cc: 980053] Hi, On 2021-01-13 15:33:00 +0100, Axel Beckert wrote: > Vincent Lefevre wrote: > > Hmm... I think that you should forget that test. I thought > > that aptitude-run-state-bundle would only depend on files from > > aptitude-segv.bundle, but it still r

[Aptitude-devel] Bug#980035: Bug#980035: Bug#980035: aptitude: segmentation fault when starting aptitude

On 2021-01-13 15:07:26 +0100, Axel Beckert wrote: > Vincent: Got the bundle, thanks! Wasn't able to provoke a segfault > with it, even not after pressing "u". With the bundle, the crash occurs while the UI isn't displayed yet. But I can see in particular: 2300077 stat("/var/lib/dpkg/status",

[Aptitude-devel] Bug#980035: aptitude: segmentation fault when starting aptitude

On 2021-01-13 12:04:57 +0100, Vincent Lefevre wrote: > On 2021-01-13 11:24:33 +0100, Vincent Lefevre wrote: > > A bundle is available for a limited time: > > > > https://www.vinc17.net/aptitude-segv.bundle > > > > I can reproduce the crash (but not always) w

[Aptitude-devel] Bug#980035: Bug#980035: aptitude: segmentation fault when starting aptitude

On 2021-01-13 14:46:21 +0100, Vincent Lefevre wrote: > On 2021-01-13 12:31:05 +0100, Julian Andres Klode wrote: > > Smells like 980037? Bug in APT's cache building upon mremap() in new > > code path in 2.1.16/17. > > Yes, I first rebuilt apt, and > > aptitud

[Aptitude-devel] Bug#980035: Bug#980035: aptitude: segmentation fault when starting aptitude

On 2021-01-13 12:31:05 +0100, Julian Andres Klode wrote: > Smells like 980037? Bug in APT's cache building upon mremap() in new > code path in 2.1.16/17. Yes, I first rebuilt apt, and aptitude-run-state-bundle aptitude-segv.bundle was still crashing, then applied the patch suggested at

[Aptitude-devel] Bug#980035: aptitude: segmentation fault when starting aptitude

On 2021-01-13 11:24:33 +0100, Vincent Lefevre wrote: > A bundle is available for a limited time: > > https://www.vinc17.net/aptitude-segv.bundle > > I can reproduce the crash (but not always) with > > aptitude-run-state-bundle aptitude-segv.bundle > > on this

[Aptitude-devel] Bug#980035: aptitude: segmentation fault when starting aptitude

A bundle is available for a limited time: https://www.vinc17.net/aptitude-segv.bundle I can reproduce the crash (but not always) with aptitude-run-state-bundle aptitude-segv.bundle on this machine and on another one. -- Vincent Lefèvre - Web: 100% accessible

[Aptitude-devel] Bug#980035: aptitude: segmentation fault when starting aptitude

On 2021-01-13 10:29:17 +0100, Vincent Lefevre wrote: > However, if I run "strace -f -o str.out aptitude", I don't always > get a segmentation fault. So there may be another reason. When it crashes, this seems to be at the same place: [...] 2237416 read(3, "ym_19981025-

[Aptitude-devel] Bug#980035: aptitude: segmentation fault when starting aptitude

Package: aptitude Version: 0.8.13-2+b1 Severity: grave Justification: renders package unusable Tags: security I got a first "segmentation fault" just after updating ('u' in the TUI). Now, each time I run aptitude, a segmentation occurs one second after starting it. I suppose that it doesn't like

[Aptitude-devel] Bug#979186: Bug#979186: aptitude: in the TUI, "+" changes the version of some packages in an inconsistent way

On 2021-01-04 08:42:53 +0100, Axel Beckert wrote: > Can you do an aptitude-create-state-bundle either before (preferred) > or after that situation and upload it somewhere? It's available here for a short period: https://www.vinc17.net/aptitude.bundle (I created it at about the same time as my

[Aptitude-devel] Bug#966488: aptitude corrupts package install selection after dpkg error

On 2020-07-29 11:06:16 +0200, Vincent Lefevre wrote: > An upgrade with aptitude failed due to a dpkg lock error (bug 95). > Then I noticed that not all packages were upgraded, so that I started > aptitude again to complete the upgrade. I typed 'g', but got: > > [1(1)/...] Acti

[Aptitude-devel] Bug#966488: aptitude corrupts package install selection after dpkg error

Package: aptitude Version: 0.8.13-1+b1 Severity: grave Justification: causes non-serious data loss An upgrade with aptitude failed due to a dpkg lock error (bug 95). Then I noticed that not all packages were upgraded, so that I started aptitude again to complete the upgrade. I typed 'g', but

[Aptitude-devel] Bug#960811: aptitude: unreadable text with default SolutionActionApproved UI style

Package: aptitude Version: 0.8.12-3 Severity: normal With the default SolutionActionApproved UI style, the text for "Leave the following recommendations unresolved" is unreadable due to the poor choice of color (see attached screenshot). Adding "set bold" solves the issue. -- Package-specific

[Aptitude-devel] Bug#959869: Bug#959869: aptitude: "aptitude why" should take Provides into account

On 2020-05-06 13:17:11 +0200, Julian Andres Klode wrote: > On Wed, May 06, 2020 at 12:43:54PM +0200, Vincent Lefevre wrote: > > zira% aptitude why x11proto-core-dev > > i tk8.5-dev Depends x11proto-core-dev > > > > but I can remove the package without breaking the dep

[Aptitude-devel] Bug#959869: aptitude: "aptitude why" should take Provides into account

Package: aptitude Version: 0.8.12-3 Severity: wishlist zira% aptitude why x11proto-core-dev i tk8.5-dev Depends x11proto-core-dev but I can remove the package without breaking the dependency: zira% apt remove -s x11proto-core-dev NOTE: This is only a simulation! apt needs root

[Aptitude-devel] Bug#934541: aptitude: upgraded a package to experimental without notice, though SolutionCost has "safety" first

On 2020-02-24 09:45:46 +0100, Vincent Lefevre wrote: > Control: found -1 0.8.12-1 > > This bug still occurs. During an upgrade last month: > > Aptitude 0.8.12: log report > Mon, Jan 27 2020 13:16:20 +0100 > [...] > [UPGRADE] bash-completion:amd64 1:2.9-1 -> 1:2.10-1

[Aptitude-devel] Bug#934541: aptitude: upgraded a package to experimental without notice, though SolutionCost has "safety" first

Control: found -1 0.8.12-1 This bug still occurs. During an upgrade last month: Aptitude 0.8.12: log report Mon, Jan 27 2020 13:16:20 +0100 [...] [UPGRADE] bash-completion:amd64 1:2.9-1 -> 1:2.10-1 [UPGRADE] dict-wn:amd64 1:3.0-35 -> 1:3.0-36 [UPGRADE] ksh:amd64 2020.0.0-2.1 -> 2020.0.0-4

[Aptitude-devel] Bug#940819: aptitude: meaningless message "it is being removed because..." / issue with ORed dependency

On 2019-09-20 11:48:53 +0200, Vincent Lefevre wrote: > During an upgrade, a package is automatically marked as to be removed > and the corresponding reason is meaningless: > > xserver-xorg-video-tdfx (remove, 1:1.4.7-1+b1) was installed automatically; > it ▒ > is being r

[Aptitude-devel] Bug#934541: aptitude: upgraded a package to experimental without notice, though SolutionCost has "safety" first

Package: aptitude Version: 0.8.11-7 Severity: important In /etc/apt/apt.conf.d/10aptitude I have Aptitude::ProblemResolver::SolutionCost "safety, removals"; but in an upgrade on 2019-07-08, aptitude upgraded a package to experimental while I did not ask it explicitly and without any warning. In

[Aptitude-devel] Bug#931619: aptitude: InRelease fetch errors for stable, stable-updates and testing

Package: aptitude Version: 0.8.11-7 Severity: normal I get the following obscure error messages when updating from the UI: ┌──┐ │E: Failed to download some files ▒│ │W: Failed

[Aptitude-devel] Bug#922735: aptitude truncates the version number in the visual interface

Package: aptitude Version: 0.8.11-7 Severity: normal aptitude truncates the version number of packages, even when the window width is large: i A --\ wpasupplicant

Re: [Aptitude-devel] Bug#686346: dpkg is wrong about the install state of docbook-mathml, making the system in inconsistent state

On 2012-09-03 21:05:06 +0200, Guillem Jover wrote: > Control: clone -1 aptitude > > [ CCing aptitude due to the clone, please see the bug report for more > details, also about it probably deserving to be serious. ] The clone still isn't in the BTS while there are more recent bugs than