[Aptitude-devel] Bug#890469: Bug#890469: aptitude: sometimes fails to resolve dependencies in a good way with '+' in the UI

On 2018-02-15 01:48:46 +0100, Axel Beckert wrote: > Vincent Lefevre wrote: > > --\ Recommends (1) > > --- stardict-gnome (>= 3.0.1-9.4) | stardict-gtk (>= 3.0.1-9.4) [...] > > This choice is surprising. > > Not really. At that moment neither of the two alt

[Aptitude-devel] Bug#890469: aptitude: sometimes fails to resolve dependencies in a good way with '+' in the UI

Package: aptitude Version: 0.8.10-6 Severity: normal Contrary to apt, aptitude sometimes fails to resolve dependencies in a good way with '+' in the UI. Here's an example. With the UI, I currently have: --\ utils Various system utilities (5) --\ main The main Debian arch

[Aptitude-devel] Bug#872477: aptitude: incorrect mentioned architecture on dependency information

Package: aptitude Version: 0.8.8-1 Severity: normal In an upgrade, aptitude shows: Actions Undo Package Resolver Search Options Views Help C-T: Menu ?: Help q: Quit u: Update g: Preview/Download/Install/Remove Pkgs PackagesPreview aptitu

[Aptitude-devel] Bug#871686: aptitude: should not replace a package of the default architecture by a foreign one

Package: aptitude Version: 0.8.8-1 Severity: normal I currently have: i A libwayland-bin 1.13.0-1 1.14.0-1 i libwayland-dev 1.13.0-1 1.14.0-1 i A libwayland-clien 1.13.0-1 1.14.0-1 i A libwayland-curso 1

[Aptitude-devel] Bug#836708: aptitude: refuses to upgrade packages, 'g' says "Actions: no changes"

On 2017-03-21 00:11:19 +0100, Manuel A. Fernandez Montecelo wrote: > 2017-03-07 3:48 GMT+01:00 Vincent Lefevre : > > On 2017-03-06 22:57:18 +0100, Manuel A. Fernandez Montecelo wrote: > >> 2016-09-05 02:33 Vincent Lefevre: > >> > On 2016-09-05 01:50:04 +0200, Vincent

[Aptitude-devel] Bug#836708: aptitude: refuses to upgrade packages, 'g' says "Actions: no changes"

Control: reopen -1 Hi, On 2017-03-06 22:57:18 +0100, Manuel A. Fernandez Montecelo wrote: > 2016-09-05 02:33 Vincent Lefevre: > > On 2016-09-05 01:50:04 +0200, Vincent Lefevre wrote: > > > In the UI, I've selected various packages for upgrade; I can see > > &g

[Aptitude-devel] Bug#847954: aptitude breaks Recommends with a wrong justification and no warnings

Package: aptitude Version: 0.8.3-1+b2 Severity: normal I want to upgrade the nvidia packages from 367.57-2 to 375.20-4, and I get: --\ Packages to be upgraded (41) iuA libegl-nvidia0 +78.8 kB 367.57-2

[Aptitude-devel] Bug#847089: aptitude: resolver mishandles OR'ed versioned Recommends

Package: aptitude Version: 0.8.3-1+b2 Severity: normal TD;LR To satisfy an OR'ed versioned Recommends, the resolver should prefer a package upgrade over a new package installation (which may yield a conflict with the other choice), even though this is not the first choice. I have: --\ utils

[Aptitude-devel] Bug#844300: Bug#844300: Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

On 2016-11-22 13:44:16 +0100, Axel Beckert wrote: > Thanks for these additional details. I currently think that this might > suffice to further track down the issue. So if the additional state > bundle is too much effort, we'll see how far we come with this. The bundle is very large (380 MB). I've

[Aptitude-devel] Bug#844300: Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

On 2016-11-22 12:36:32 +0100, Axel Beckert wrote: > Vincent Lefevre wrote: > > In any case, if the dependencies are correct, the package system > > should never be put in a broken state. > > I'm sorry but that's wrong. Maintainer scripts can still put packa

Re: [Aptitude-devel] Bug#844300: nvidia-driver-libs:amd64: upgrade failure due to dependency issue

Control: reassign -1 aptitude Control: retitle -1 aptitude can put the package system in a broken state with different versions of a MultiArch package Control: severity -1 serious On 2016-11-22 09:10:01 +, Luca Boccassi wrote: > On Tue, 2016-11-22 at 04:27 +0100, Vincent Lefevre wr

[Aptitude-devel] Bug#659341: aptitude: loops while resolving dependencies

On 2016-10-19 12:32:32 +0200, Vincent Lefevre wrote: > Same problem with aptitude's UI, by hitting "U" to upgrade. > And the allocated memory constantly increases. After 16 minutes, > it takes 1.7 GB: > > cventin:~> ps -FC aptitude > UIDPID PPID C

[Aptitude-devel] Bug#836708: aptitude: refuses to upgrade packages, 'g' says "Actions: no changes"

On 2016-09-05 01:50:04 +0200, Vincent Lefevre wrote: > In the UI, I've selected various packages for upgrade; I can see > no breakages. But the 'g' key doesn't have any effect, it just > says: "[1(1)/...] Actions: no changes" with no explanations. And &#

[Aptitude-devel] Bug#826941: aptitude: inconsistent decisions for auto-installed package removal / empty list for the reason

Control: found -1 0.8.2-1 Still occurs (empty list for the reason). This time, the removed packages were: [REMOVE, NOT USED] vlc-plugin-notify:amd64 2.2.4-3 [REMOVE, NOT USED] vlc-plugin-samba:amd64 2.2.4-3 due to the vlc rebuild (2.2.4-3 -> 2.2.4-3+b1). -- Vincent Lefèvre - Web:

[Aptitude-devel] Bug#826941: Bug#826941: aptitude: inconsistent decisions for auto-installed package removal / empty list for the reason

On 2016-06-11 01:04:25 +0200, Axel Beckert wrote: > Hi, > > Vincent Lefevre wrote: > > After doing an update ("u" in the UI) and tried to upgrade ("U"), > > which I cancelled, > > How have you cancelled it? Ctrl-u > > aptitude wants to rem

[Aptitude-devel] Bug#826941: aptitude: inconsistent decisions for auto-installed package removal / empty list for the reason

Package: aptitude Version: 0.8.1-1 Severity: normal After doing an update ("u" in the UI) and tried to upgrade ("U"), which I cancelled, aptitude wants to remove two packages: --\ Packages being removed because they are no longer used (2) idA linux-headers-4.5.0-1-amd64 -456

[Aptitude-devel] Bug#825707: aptitude: should not regard a package as removed when another package has a Provides on it

On 2016-05-31 19:12:40 +0100, Manuel A. Fernandez Montecelo wrote: > 2016-05-29 01:46 Vincent Lefevre: > > In the gnuplot5-data upgrade, one has: > > > > Package: gnuplot5-data > > Source: gnuplot5 > > Version: 5.0.3+dfsg2-1 > > Depends: aglfn, gnuplot-tex &

[Aptitude-devel] Bug#825707: aptitude: should not regard a package as removed when another package has a Provides on it

Package: aptitude Version: 0.8.1-1 Severity: wishlist In the gnuplot5-data upgrade, one has: Package: gnuplot5-data Source: gnuplot5 Version: 5.0.3+dfsg2-1 Depends: aglfn, gnuplot-tex currently installed, and the new version has: Package: gnuplot5-data Source: gnuplot5 Version: 5.0.3+dfsg2-2 Re

[Aptitude-devel] Bug#823928: aptitude wants to remove manually installed packages with SolutionCost "safety, removals"

On 2016-05-18 12:11:18 +0100, Manuel A. Fernandez Montecelo wrote: > > For each package proposed for upgrade: > > 1. Type '+'. > > 2. If there is any removal, cancel. > > 3. Otherwise, choose to upgrade. > > Only that to upgrade, sometimes, packages left behind (e.g. in > transitions) have to

[Aptitude-devel] Bug#823928: aptitude wants to remove manually installed packages with SolutionCost "safety, removals"

On 2016-05-18 10:04:50 +0100, Manuel A. Fernandez Montecelo wrote: > 2016-05-18 2:53 GMT+01:00 Vincent Lefevre : > > On 2016-05-18 01:26:45 +0100, Manuel A. Fernandez Montecelo wrote: > >> 2016-05-17 3:15 GMT+01:00 Vincent Lefevre : > >> > But note that I use Solut

[Aptitude-devel] Bug#823928: aptitude wants to remove manually installed packages with SolutionCost "safety, removals"

On 2016-05-18 01:26:45 +0100, Manuel A. Fernandez Montecelo wrote: > 2016-05-17 3:15 GMT+01:00 Vincent Lefevre : > > But note that I use SolutionCost "safety, removals", so that it should > > avoid packages from experimental or remove packages. > > aptitude never

[Aptitude-devel] Bug#823927: aptitude: MultiArch searching beeps the terminal

On 2016-05-14 14:43:26 +0100, Manuel A. Fernandez Montecelo wrote: > So I think that the best solution now is to change the documentation to > better reflect this behaviour, and not change the current > implementation. There should be a way to disable the beep entirely, then. -- Vincent Lefèvre

[Aptitude-devel] Bug#823928: aptitude wants to remove manually installed packages with SolutionCost "safety, removals"

Hi, On 2016-05-14 10:53:03 +0100, Manuel A. Fernandez Montecelo wrote: > 2016-05-10 15:14 Vincent Lefevre: > > cventin:~> aptitude upgrade -s > > Resolving dependencies... > > Unable to resolve dependencies for the upgrade: no solution found. > > Unable to safely res

[Aptitude-devel] Bug#823928: aptitude wants to remove manually installed packages with SolutionCost "safety, removals"

In the UI, I get the same behavior as with --full-resolver: aptitude wants to remove packages. And in both cases, if I look at the next solutions, aptitude wants to remove more and more packages. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

[Aptitude-devel] Bug#823927: aptitude: MultiArch searching beeps the terminal

Package: aptitude Version: 0.8.1-1 Severity: minor I get (visual) beeps in my terminal when searching for MultiArch packages. For instance, if I type /libwine:i386 I get a beep for the characters ":", "i", "3" and "8", which is annoying. -- Package-specific info: Terminal: xterm-debian $DISPLAY i

[Aptitude-devel] Bug#397728: aptitude should purge deleted packages at the end

Hi, On 2016-05-04 20:20:59 +0100, Manuel A. Fernandez Montecelo wrote: > 2006-11-09 01:33 Vincent Lefevre: > > One may want to mark deleted packages as purge to get rid of obsolete > > configuration files. But some configuration files may be common to a > > package to be pu

[Aptitude-devel] Bug#720386: aptitude: Upgrade marks newly installed packages as manually installed

On 2016-04-26 23:47:13 +0100, Manuel A. Fernandez Montecelo wrote: > Many of these problems were fixed in releases of the 0.7 series; I > suppose that this was one of those cases. Note that I can at least notice a related issue with aptitude 0.7.2-1 or later: libgnomevfs2-0 was automatically insta

[Aptitude-devel] Bug#820436: www.debian.org: en and fr descriptions of APT::AutoRemove::RecommendsImportant in aptitude manual are inconsistent

On 2016-04-08 17:32:06 +0100, Adam D. Barratt wrote: > Control: reassign -1 aptitude-doc-fr 0.7.8-1 > > [Full quote for aptitude maintainers] It should also have been Cc'ed to the maintainers since the reassign comes too late. > On Fri, 2016-04-08 at 14:09 +0200, Vinc

[Aptitude-devel] Bug#819636: aptitude: wants to remove a recommended package

On 2016-04-01 16:24:47 +0100, Manuel A. Fernandez Montecelo wrote: > 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

[Aptitude-devel] Bug#651410: aptitude: in dependency resolutions, aptitude should favor library removal

On 2016-04-01 19:58:20 +0100, Manuel A. Fernandez Montecelo wrote: > 2016-03-22 13:27 Vincent Lefevre: > > A single removal is bad if it is an application. > > That's strange coming from you, who use the resolver costs of minimizing > removals ;-) Not really. What I w

[Aptitude-devel] Bug#762932: aptitude Bug#762932: With Aptitude::ProblemResolver::SolutionCost=removals, aptitude full-upgrade chooses to downgrade a package

On 2016-04-05 16:19:27 +0100, Manuel A. Fernandez Montecelo wrote: > 2016-04-05 15:51 GMT+01:00 Vincent Lefevre : > > 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

[Aptitude-devel] Bug#795228: aptitude: upgraded a package to experimental without notice

On 2016-04-05 16:27:38 +0100, Manuel A. Fernandez Montecelo wrote: > This is basically the same as #762932, but with upgrades to experimental > instead of downgrades, so marking as +wontfix and closing (we already > have the other bug to explain why it's a +wontfix). Yes, clearly, about this bug,

[Aptitude-devel] Bug#820116: aptitude-doc-en: downgrades are not documented in "Costs in the interactive dependency resolver"

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 i

[Aptitude-devel] Bug#762932: aptitude Bug#762932: With Aptitude::ProblemResolver::SolutionCost=removals, aptitude full-upgrade chooses to downgrade a package

On 2016-04-05 15:26:38 +0100, Manuel A. Fernandez Montecelo wrote: > 2016-04-05 15:21 GMT+01:00 Vincent Lefevre : > > 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 > >>

[Aptitude-devel] Bug#762932: aptitude Bug#762932: With Aptitude::ProblemResolver::SolutionCost=removals, aptitude full-upgrade chooses to downgrade a package

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 pac

[Aptitude-devel] Bug#819636: aptitude: wants to remove a recommended package

Hi, On 2016-03-31 21:05:57 +0100, Manuel A. Fernandez Montecelo wrote: > 2016-03-31 12:55 Vincent Lefevre: > > ypig:~> aptitude why gmp-ecm > > i libecm0 Recommends gmp-ecm (= 6.4.4+ds-5) > > Side note: If I recall correctly, "aptitude why" explains the

[Aptitude-devel] Bug#651410: aptitude: in dependency resolutions, aptitude should favor library removal

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 li

[Aptitude-devel] Bug#795228: aptitude: upgraded a package to experimental without notice

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

[Aptitude-devel] Bug#721426: aptitude: packages are sometimes selected for upgrade by default just after aptitude is started

On 2016-03-09 16:31:39 +0100, Vincent Lefevre wrote: > 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

[Aptitude-devel] Bug#721426: aptitude: packages are sometimes selected for upgrade by default just after aptitude is started

On 2016-03-09 14:14:03 +, Manuel A. Fernandez Montecelo wrote: [...] > What's the difference between them? "Upgrade: yes" is the same in > pkgstates.old and pkgstates, respectively. > > (If you mean the "remove reason" might be correct or a small > incorrection but probably without any practi

[Aptitude-devel] Bug#721426: aptitude: packages are sometimes selected for upgrade by default just after aptitude is started

Control: retitle -1 aptitude: packages from the previous upgrade are still selected for upgrade by default if there is again a new version I think this title corresponds more precisely to what I could observe. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTM

[Aptitude-devel] Bug#721426: aptitude: packages are sometimes selected for upgrade by default just after aptitude is started

On 2016-03-09 12:46:04 +0100, Vincent Lefevre wrote: > I have: > > -rw-r--r-- 1 9536507 2016-03-09 11:15:43 /var/lib/aptitude/pkgstates > -rw-r--r-- 1 9526471 2016-03-08 09:38:42 /var/lib/aptitude/pkgstates.old > > Note that /var/lib/aptitude/pkgstates dates from before the

[Aptitude-devel] Bug#721426: aptitude: packages are sometimes selected for upgrade by default just after aptitude is started

Control: reopen -1 Control: found -1 0.7.8-1 On 2016-03-01 18:32:44 +, Manuel A. Fernandez Montecelo wrote: > 2016-03-01 17:43 Vincent Lefevre: > > On 2016-03-01 15:02:59 +, Manuel A. Fernandez Montecelo wrote: > > > 2013-08-31 12:41 Vincent Lefevre: > > > &g

[Aptitude-devel] Bug#721426: aptitude: packages are sometimes selected for upgrade by default just after aptitude is started

Control: tags -1 - moreinfo On 2016-03-01 15:02:59 +, Manuel A. Fernandez Montecelo wrote: > 2013-08-31 12:41 Vincent Lefevre: > > When I start "aptitude" (no arguments, curses interface), packages are > > sometimes selected for upgrade by default, for no appare

[Aptitude-devel] Bug#815554: Bug#815554: aptitude: truncated hostname in header line (regression)

On 2016-02-22 21:22:44 +, Manuel A. Fernandez Montecelo wrote: > I had to do some changes to the size due to #810221 -- the fields Broken > and Download size are more important than host for most people, I guess. I don't think they need much precision (3 or 4 digits is enough). Also note that

[Aptitude-devel] Bug#815554: aptitude: truncated hostname in header line (regression)

Package: aptitude Version: 0.7.6-1 Severity: minor When I run aptitude, I get the following header line: aptitude 0.7.6 @ cven on my machine cventin, i.e. the hostname is truncated. If I downgrade to 0.7.5-3, I get the full hostname as expected. -- Package-specific info: Terminal: xterm-debian

[Aptitude-devel] Bug#806595: Workaround

On 2015-12-17 17:22:52 +0100, kay wrote: > Have faced same issue. Here is my workaround. > > --- /usr/sbin/update-pepperflashplugin-nonfree.orig 2015-12-17 > 17:22:00.184075270 +0100 > +++ /usr/sbin/update-pepperflashplugin-nonfree 2015-12-17 > 17:21:40.280204140 +0100 [...] This is unrelate

[Aptitude-devel] Bug#642030: aptitude: cannot forbid more than 1 version of a package

On 2015-11-13 12:07:18 +, Manuel A. Fernandez Montecelo wrote: > 2015-11-13 11:31 GMT+00:00 Vincent Lefevre : > > On 2015-11-13 10:59:01 +, Manuel A. Fernandez Montecelo wrote: > >> > >> So when you put packages on hold in testing, say "v1", and &qu

[Aptitude-devel] Bug#642030: aptitude: cannot forbid more than 1 version of a package

On 2015-11-13 10:59:01 +, Manuel A. Fernandez Montecelo wrote: > 2015-11-13 2:10 GMT+00:00 Vincent Lefevre : > > On 2015-11-12 21:57:33 +, Manuel A. Fernandez Montecelo wrote: > >> In your example above, using hold also would not install v2 from > >> testin

[Aptitude-devel] Bug#642030: aptitude: cannot forbid more than 1 version of a package

On 2015-11-12 21:57:33 +, Manuel A. Fernandez Montecelo wrote: > In your example above, using hold also would not install v2 from > testing, and when v4 appears, you notice and unhold, and all is well. > What's the drawback of using Hold in your use-case? No, when a package is on hold, aptitud

[Aptitude-devel] Bug#642030: aptitude: cannot forbid more than 1 version of a package

On 2015-11-12 14:24:10 +, Manuel A. Fernandez Montecelo wrote: > In the general case, if one is using v9-1 from unstable, v9-2 appears > in unstable and v8-2 appears in testing and aptitude allows to forbid > both, until it is actually released, one still doesn't know if the > problem is going

[Aptitude-devel] Bug#642030: aptitude: cannot forbid more than 1 version of a package

On 2015-11-12 14:37:40 +0100, Vincent Lefevre wrote: > Remember that users can track both testing and unstable, and aptitude > does not always try to install the latest version. The problem I had > is that when I did "F" on the unstable version, aptitude then wanted > to

[Aptitude-devel] Bug#642030: aptitude: cannot forbid more than 1 version of a package

Control: reopen -1 On 2015-11-12 11:59:15 +, Manuel A. Fernandez Montecelo wrote: > Even if this worked for multiple versions, if you are unsure in which > version the package is going to fix a problem, I am sure concerning which version*s* to forbid. > it is more practical to use the Hold f

[Aptitude-devel] Bug#570377: Aptitude removals

On 2015-10-11 21:36:19 +1300, Chris Tillman wrote: > I bought a new (used) computer, and installed a new system. This annoying > behaviour came back, of course, because I had set the old one up to get rid > of it. > > For anyone being affected by these bugs, or annoyed by removals being > offered

[Aptitude-devel] Bug#762932: Bug#762932: aptitude: in an upgrade with 'U', aptitude chose to downgrade a package

On 2015-09-21 14:11:13 +0100, Manuel A. Fernandez Montecelo wrote: > 2015-09-21 13:40 GMT+01:00 Vincent Lefevre : > > Basically, two things are said: > > > > 1. Some packages cannot be installed (for some period), which is OK > >for me, and this cannot be avoided.

[Aptitude-devel] Bug#762932: Bug#762932: aptitude: in an upgrade with 'U', aptitude chose to downgrade a package

Hi, On 2015-09-21 12:43:08 +0100, Manuel A. Fernandez Montecelo wrote: > The website also says: > > http://www.debian.org/releases/ > > unstable > > The unstable distribution is where active development of Debian > occurs. Generally, this distribution is run by developers and those > who l

[Aptitude-devel] Bug#762932: Bug#762932: aptitude: in an upgrade with 'U', aptitude chose to downgrade a package

On 2015-09-20 16:27:39 +0200, Axel Beckert wrote: > Vincent Lefevre wrote: > > Note that I use the following option: > > > > Aptitude::ProblemResolver::SolutionCost "removals"; > > > > so that packages don't get removed. > > Which IMHO

[Aptitude-devel] Bug#799532: aptitude: typing Ctrl-L during an upgrade puts aptitude in background

On 2015-09-20 12:04:48 +0100, Manuel A. Fernandez Montecelo wrote: > 2015-09-20 2:08 GMT+01:00 Vincent Lefevre : > > On 2015-09-20 02:50:45 +0200, Vincent Lefevre wrote: > >> > >zira:~> pstree -ap 29204 > >> > >bash,29204 > >> > > └─aptit

[Aptitude-devel] Bug#799532: aptitude: typing Ctrl-L during an upgrade puts aptitude in background

On 2015-09-20 02:50:45 +0200, Vincent Lefevre wrote: > > >zira:~> pstree -ap 29204 > > >bash,29204 > > > └─aptitude,29206 > > > ├─(dpkg,29277) > > > ├─dpkg,30424 --status-fd 76 --configure geoclue-2.0:amd64 ... > > >

[Aptitude-devel] Bug#799532: aptitude: typing Ctrl-L during an upgrade puts aptitude in background

On 2015-09-20 01:25:50 +0100, Manuel A. Fernandez Montecelo wrote: > I cannot reproduce with these steps and also 0.7.1-1. I can no longer reproduce. > >zira:~> pstree -ap 29204 > >bash,29204 > > └─aptitude,29206 > > ├─(dpkg,29277) > > ├─dpkg,30424 --status-fd 76 --configure geoclue-2.0:a

[Aptitude-devel] Bug#799532: aptitude: typing Ctrl-L during an upgrade puts aptitude in background

Package: aptitude Version: 0.7.1-1 Severity: important During an upgrade from the aptitude UI, I got: Configuration file '/etc/lightdm/lightdm.conf' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do abou

[Aptitude-devel] Bug#762932: aptitude: in an upgrade with 'U', aptitude chose to downgrade a package

On 2015-09-19 19:42:07 +0200, Vincent Lefevre wrote: > since downgrading packages is not supported by Debian and can break > the system. and this can happen automatically with "aptitude full-upgrade -y": $ aptitude full-upgrade -y -s The following packages will be upgrade

[Aptitude-devel] Bug#762932: aptitude: in an upgrade with 'U', aptitude chose to downgrade a package

Control: found -1 0.7.1-1 Control: severity -1 grave since downgrading packages is not supported by Debian and can break the system. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic

[Aptitude-devel] Bug#795228: aptitude: upgraded a package to experimental without notice

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'

[Aptitude-devel] Bug#642030: aptitude: cannot forbid more than 1 version of a package

Control: found -1 0.6.11-1 On 2011-09-18 20:16:55 +0200, Yann Dirson wrote: > If I have forbidden a package version in testing, and I see in > unstable a new version with the bug not fixed, I cannot forbid that > new one: if I do, the version in testing is not forbidden any more and > will likely

[Aptitude-devel] Bug#762932: aptitude: in an upgrade with 'U', aptitude chose to downgrade a package

On 2014-09-26 14:29:04 +0200, Vincent Lefevre wrote: > In my latest upgrade with 'U' from the curses interface, aptitude > chose to downgrade gir1.2-evince-3.0 from 3.12.2-1 to 3.4.0-3.1. > Downgrading should never be the default choice. Re-upgraded this package didn't le

[Aptitude-devel] Bug#762932: aptitude: in an upgrade with 'U', aptitude chose to downgrade a package

Package: aptitude Version: 0.6.11-1 Severity: normal In my latest upgrade with 'U' from the curses interface, aptitude chose to downgrade gir1.2-evince-3.0 from 3.12.2-1 to 3.4.0-3.1. Downgrading should never be the default choice. I've attached the dpkg log excerpt corresponding to this upgrade.

[Aptitude-devel] Bug#746995: aptitude upgrade is inconsistent (UI vs command line)

On 2014-05-05 10:10:34 +0800, Daniel Hartwig wrote: > The curses and command line interfaces are not equivalent. The curses > interface provides more detailed feedback and perhaps greater > opportunity for the user to browse the proposed set of actions, and > for this reason is less conservative w

[Aptitude-devel] Bug#746995: aptitude upgrade is inconsistent (UI vs command line)

Package: aptitude Version: 0.6.10-1 Severity: normal With an upgrade from the UI (key U), aptitude wants to remove sysvinit-core by default: Actions Undo Package Resolver Search Options Views Help C-T: Menu ?: Help q: Quit u: Update g: Download/Install/Remove Pkgs Pack

[Aptitude-devel] Bug#342835: aptitude: "X will be automatically removed because of dependency errors:" then no errors shown

Control: found -1 0.6.10-1 I've just got this problem. aptitude shows: --\ Packages being deleted due to unsatisfied dependencies (1) id linux-image-amd6 -37.9 kB 3.12+55 3.13+56 Linux for 64-bit PCs (meta-package) linux-image-amd64 will be automatically removed because of de

[Aptitude-devel] Bug#570377: aptitude chooses to remove packages instead of upgrading

On 2014-02-05 00:56:26 +0800, Daniel Hartwig wrote: > On 4 February 2014 19:53, Vincent Lefevre wrote: > > On 2014-02-04 10:49:53 +0800, Daniel Hartwig wrote: > >> Again, I am only addressing the proposed patch. There are better > >> options, such as adjusting the def

[Aptitude-devel] Bug#570377: Bug#570377: aptitude chooses to remove packages instead of upgrading

On 2014-02-04 10:49:53 +0800, Daniel Hartwig wrote: > On 4 February 2014 10:24, Vincent Lefevre wrote: > > Because I would say: A remove can be caused by some obsolete package > > due to a conflict with the newly installed package (or one of its > > dependencies). But in su

[Aptitude-devel] Bug#570377: Bug#570377: aptitude chooses to remove packages instead of upgrading

On 2014-02-04 01:29:30 +0800, Daniel Hartwig wrote: > There is nothing fundamentally better or worse about either removals > or installs, in some situations you might find this: > > solution 1: upgrade 20 packages > solution 2: remove 1 > > Whichever is more preferable in these situations is up

[Aptitude-devel] Bug#570377: aptitude chooses to remove packages instead of upgrading

On 2014-01-30 10:01:58 +0100, Axel Beckert wrote: > Vincent Lefevre wrote: > > aptitude sometimes prefers to remove packages instead of upgrading. > > Which is IMHO fine in general. I don't see why it would be fine. Upgrading (to satisfy the dependencies) should always be fav

[Aptitude-devel] Bug#730795: aptitude: buggy newline output with aptitude-curses in case of error during package install

On 2013-11-29 17:37:59 +0100, Sven Joachim wrote: > More likely it's due to a buggy change in apt 0.9.13. The problem is > also reproducible with apt-get rather than aptitude, in a quite minimal > pbuilder chroot. Would the bug be in libapt-pkg.so.4.12.0 from libapt-pkg4.12? Indeed, that's a rece

[Aptitude-devel] Bug#730795: Bug#730795: aptitude: buggy newline output with aptitude-curses in case of error during package install

Hi Axel, On 2013-11-29 17:11:21 +0100, Axel Beckert wrote: > Same here, also with xterm and on nearly every architecture. But > just for a few days so far. I didn't notice it either in the past, but I don't remember when the previous error occurred. > Since aptitude hasn't seen much change recen

[Aptitude-devel] Bug#730795: aptitude: buggy newline output with aptitude-curses in case of error during package install

Control: retitle -1 aptitude: terminal problems (newline, keyboard) with aptitude-curses in case of error during package install On 2013-11-29 16:51:54 +0100, Vincent Lefevre wrote: [...] > Press Return to continue. > > See the incorrect newline handling after the dpkg error (the

[Aptitude-devel] Bug#730795: aptitude: buggy newline output with aptitude-curses in case of error during package install

Package: aptitude Version: 0.6.8.2-1.2 Severity: normal In an upgrade with aptitude (/usr/bin/aptitude-curses alternative in my case): ypig:/home/vlefevre# aptitude Retrieving bug reports... Done Parsing Found/Fixed information... Done Retrieving bug reports... Done Parsing Found/Fixed informatio

[Aptitude-devel] Bug#729527: Bug#729527: aptitude says Error: Timeout was reached

On 2013-11-26 13:05:51 +0100, Axel Beckert wrote: > 20packagekit interacts with DBus, so I can imagine it to cause such an > error message. I can't find it in the packagekit. But both /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.3.0 have it. > Can

[Aptitude-devel] Bug#729527: Bug#729527: aptitude says Error: Timeout was reached

On 2013-11-26 10:00:50 +0100, Axel Beckert wrote: > At least I haven't this issue on any of my machine, so I suspect > either a mirror or an APT hook issue. Since Vincent and shirish come > from at least different cultures, I expect they use different mirrors, > hence this is likely not a mirror is

[Aptitude-devel] Bug#729527: aptitude says Error: Timeout was reached

Hi, On 2013-11-14 01:18:14 +0530, shirish शिरीष wrote: > This has been happening for quite sometime now. I call up to update > the index and aptitude updates the whole index. At the very end it > gives this :- > > Error: Timeout was reached Same problem on my machine. AFAIK, it has been occurrin

[Aptitude-devel] Bug#721426: aptitude: packages are sometimes selected for upgrade by default just after aptitude is started

Package: aptitude Version: 0.6.8.2-1.2 Severity: normal When I start "aptitude" (no arguments, curses interface), packages are sometimes selected for upgrade by default, for no apparent reason. Since this behavior is not documented in the man page, I assume that this is a bug. Such packages are s

[Aptitude-devel] Bug#720386: aptitude: Upgrade marks newly installed packages as manually installed

And here's the diff of /var/lib/apt/extended_states between the contents before and after the upgrade: --- extended_states 2013-08-21 11:13:18.0 +0200 +++ /var/lib/apt/extended_states2013-08-21 11:18:36.0 +0200 @@ -8630,7 +8630,11 @@ Architecture: amd64 Auto-Installed

[Aptitude-devel] Bug#669569: aptitude: "aptitude changelog": Changelog download failed: Download queue destroyed.

Package: aptitude Version: 0.6.6-1+b1 Severity: normal One can no longer get changelogs. For instance: $ aptitude changelog gnome-core Err Changelog of gnome-core E: Changelog download failed: Download queue destroyed. E: Couldn't find a change

[Aptitude-devel] Bug#669093: Bug#669093: E: Internal error: APT::pkgPackageManager::MaxLoopCount reached in SmartConfigure for ..., aborting

On 2012-04-17 16:53:15 +0200, Vincent Lefevre wrote: > On 2012-04-17 15:32:27 +0200, Axel Beckert wrote: > > Vincent Lefevre wrote: > > > Note: this looks similar to > > > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669044 > > > htt

[Aptitude-devel] Bug#669093: Bug#669093: E: Internal error: APT::pkgPackageManager::MaxLoopCount reached in SmartConfigure for ..., aborting

On 2012-04-17 15:32:27 +0200, Axel Beckert wrote: > Vincent Lefevre wrote: > > Note: this looks similar to > > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669044 > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669060 > > > > reported agai

[Aptitude-devel] Bug#669093: E: Internal error: APT::pkgPackageManager::MaxLoopCount reached in SmartConfigure for ..., aborting

Package: aptitude Version: 0.6.6-1+b1 Severity: important When I want to upgrade with aptitude 0.6.6-1+b1 from its ncurses interface, I get the following error: ┌──┐ │E: Internal error: APT::pkgPackageManager::MaxLoopCoun

[Aptitude-devel] Bug#643335: aptitude silently loses changes when run as non-root

On 2012-04-15 08:54:09 +0800, Daniel Hartwig wrote: > On 15 April 2012 00:38, Vincent Lefevre wrote: > > On 2012-04-14 22:08:20 +0800, Daniel Hartwig wrote: > >> This is set if you previously selected "Never display this message > >> again" when presented with

[Aptitude-devel] Bug#643335: aptitude silently loses changes when run as non-root

On 2012-04-14 22:08:20 +0800, Daniel Hartwig wrote: > This is set if you previously selected "Never display this message > again" when presented with the warning. I don't think I had ever selected this (on two machines, it would be even more surprising). -- Vincent Lefèvre - Web:

[Aptitude-devel] Bug#643335: aptitude silently loses changes when run as non-root

On 2012-04-14 12:30:28 +0800, Daniel Hartwig wrote: > A warning is displayed on the first change with instructions on > becoming root, though this can be disabled. > > What is the value of 'aptitude::Suppress-Read-Only-Warning' in your > configuration? > > $ apt-config -c .aptitude/config dump |