[Aptitude-devel] Bug#1065435: Bug#1065435: aptitude: FTBFS on armhf and armel (probably -Werror=implicit-function-declaration related)
Hi Steinar and Christoph,
Steinar H. Gunderson wrote:
> struct timeval
> {
> #ifdef __USE_TIME_BITS64
> __time64_t tv_sec;/* Seconds. */
> __suseconds64_t tv_usec; /* Microseconds. */
> #else
> __time_t tv_sec; /* Seconds. */
> __suseconds_t tv_usec;/* Microseconds. */
> #endif
> };
> #endif
>
> But the fix is straightforward, no? Just change the offending test to
> something like
>
> CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
>
> and it should work no matter what type c.tv_usec is. Or, if you prefer
> brace-initialization (which would prevent you from ever writing in a too-big
> value, like 999 or something):
>
> CPPUNIT_ASSERT_EQUAL(decltype(c.tv_usec){99}, c.tv_usec);
>
> /* Steinar */
Thanks for the patch!
Christoph Biedl wrote:
> Therefore, any progress on this?
Not before the patch (hints) from Steinar. (Although there's also a
recent merge request mentioning some FTBFS fix, but it's unclear if
this issue is meant or something else. Will have to look into it,
too.)
> Do you need help?
I'm happy about any help with aptitude as we currently don't really
have any active upstream developer. C++ is not something that I'm
particularly good at.
> I didn't get very far at a first glance, aptitude's build
> dependencies are currently uninstallable, at least in arm{el,hf}.
I got my sid armhf Raspi fixed today (it stopped booting a while ago,
seemed to have been a usrmerge related issue), so I can now test
patches locally on armhf again.
Will try to get an upload done based on Steinar's patch instructions
soon-ish. But I first need to get the Raspi uptodate with the current
state of Sid.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1065554: Bug#1065554: aptitude: the TUI silently breaks a "Recommends"
Hi Vincent, Vincent Lefevre wrote: > > I've seen also already seen this, but so far it always was for a > > reason here: > > > > * On multiarch hosts, amd64 and i386 weren't in sync and there were > > Breaks against any version not being the same version. > > This is not a multiarch host yet. That was already mentioned in the original bug report's footer, yes. Otherwise I would have asked. :-) > > * An initial solution pulls in a package which Breaks the package in > > question and that pulled in package later (manually or due to other > > conflicts by manual changes) gets set to "keep uninstalled", but the > > effect of its Breaks is not reverted. > > I cannot see any Breaks of at-spi2-core. Yes, I've checked that, too. That's also why I mentioned them: These cases don't apply and hence it's NOT one of the two common cases, where it's more obvious (albeit not necessarily good) that this happens. [I removed the additional details, but they might come in handy later, so thanks!] > > But in your case neither of that seems to be case. So it indeed might > > be a bug in this case. > > 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 simpler reproducer. BTW, do I remember right that you have APT::Install-Recommends set "false"? Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1065554: Bug#1065554: aptitude: the TUI silently breaks a "Recommends"
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 multiarch hosts, amd64 and i386 weren't in sync and there were Breaks against any version not being the same version. * An initial solution pulls in a package which Breaks the package in question and that pulled in package later (manually or due to other conflicts by manual changes) gets set to "keep uninstalled", but the effect of its Breaks is not reverted. But in your case neither of that seems to be case. So it indeed might be a bug in this case. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1065435: aptitude: FTBFS on armhf and armel (probably -Werror=implicit-function-declaration related)
Source: aptitude
Version: 0.8.13-5
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: a...@debian.org, z...@debian.org
Citing from https://buildd.debian.org/status/package.php?p=aptitude:
BinNMU changelog for aptitude on amd64, arm64, armel, armhf, i386, mips64el,
ppc64el, riscv64, s390x, alpha, hppa, hurd-i386, ia64, loong64, m68k, powerpc,
ppc64, sh4, sparc64 and x32:
Rebuild for time_t
Tail of log for aptitude on armel:
/usr/include/cppunit/TestAssert.h:161:6: note: candidate: ‘template
void CppUnit::assertEquals(const T&, const T&, SourceLine, const std::string&)’
161 | void assertEquals( const T& expected,
| ^~~~
/usr/include/cppunit/TestAssert.h:161:6: note: template argument
deduction/substitution failed:
../../tests/test_misc.cc:187:5: note: deduced conflicting types for parameter
‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long int’})
187 | CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
| ^
make[3]: *** [Makefile:869: test_misc.o] Error 1
make[3]: Leaving directory '/<>/build/tests'
make[2]: *** [Makefile:1169: check-am] Error 2
make[2]: Leaving directory '/<>/build/tests'
/bin/sh: 1: ./cppunit_test: not found
make[1]: *** [debian/rules:39: override_dh_auto_test-arch] Error 127
make[1]: Leaving directory '/<>'
make: *** [debian/rules:22: binary-arch] Error 2
Tail of log for aptitude on armhf:
/usr/include/cppunit/TestAssert.h:161:6: note: candidate: ‘template
void CppUnit::assertEquals(const T&, const T&, SourceLine, const std::string&)’
161 | void assertEquals( const T& expected,
| ^~~~
/usr/include/cppunit/TestAssert.h:161:6: note: template argument
deduction/substitution failed:
../../tests/test_misc.cc:187:5: note: deduced conflicting types for parameter
‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long int’})
187 | CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
| ^
make[3]: *** [Makefile:869: test_misc.o] Error 1
make[3]: Leaving directory '/<>/build/tests'
make[2]: *** [Makefile:1169: check-am] Error 2
make[2]: Leaving directory '/<>/build/tests'
/bin/sh: 1: ./cppunit_test: not found
make[1]: *** [debian/rules:39: override_dh_auto_test-arch] Error 127
make[1]: Leaving directory '/<>'
make: *** [debian/rules:22: binary-arch] Error 2
Given the time and the architectures failing, this is probably related
to dpkg switching on -Werror=implicit-function-declaration on these
architectures (see https://bugs.debian.org/1065371 and a good summary
of a similar case in https://bugs.debian.org/1065431 against lintian).
-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude
aptitude version information:
aptitude 0.8.13
Compiler: g++ 13.2.0
Compiled against:
apt version 6.0.0
NCurses version 6.4
libsigc++ version: 2.12.1
Gtk+ support disabled.
Qt support disabled.
Current library versions:
NCurses version: ncurses 6.4.20240113
cwidget version: 0.5.18
Apt version: 6.0.0
aptitude linkage:
linux-vdso.so.1 (0x7ffc0a3eb000)
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
(0x7f8fca645000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0
(0x7f8fc9e0)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6
(0x7f8fca1c6000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6
(0x7f8fca191000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0
(0x7f8fca188000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4
(0x7f8fca084000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0
(0x7f8fc9c8a000)
libboost_iostreams.so.1.83.0 =>
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.83.0 (0x7f8fca06a000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30
(0x7f8fc9a0)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f8fc960)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f8fc9921000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f8fca03b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8fc941e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8fc9c85000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f8fc9c8)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f8fc9c61000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
(0x7f8fc990e000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f8fc98d1000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7f8fc98ab000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7f8fc935d000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f8fc9878000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0
(0x7f8fc927b000)
libgcrypt.so.20 =>
[Aptitude-devel] Bug#1057688: Bug#1057688: aptitude: Stray input on window click when running under tmux
Hi Sven,
Sven Joachim via Aptitude-devel wrote:
> Debian ncurses maintainer here, bringing the ncurses upstream developer
> into the loop.
Thanks for that!
> In addition to aptitude, mouse support is also broken in dialog(1) under
> tmux.
>
> > Maybe this bug should instead be assigned to ncurses?
>
> Probably should be reassigned to ncurses-base, but let's first see what
> Thomas has to say about it.
JFTR: If it turns out as a bug which indeed needs not (only) to be
fixed in ncurses, it's likely not in aptitude but in libcwidget4. (The
separation stems from times where aptitude still also had a GUI
frontend.)
P.S.: Thanks to Thomas for fixing the recent ncurses issues (htop,
etc.) so quickly at upstream!
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1036447: aptitude: Doesn't accept uppercase letters (Y/N) on yes/no questions
Package: aptitude Version: 0.8.13-5 Severity: minor Tags: upstream On prompts like e.g. "Really quit Aptitude? [n]y", aptitude does not accept uppercase letters like Y or N as answer. Originally reported in Ubuntu at https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/2020232 -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'testing-security'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages aptitude depends on: ii aptitude-common 0.8.13-5+abe+test1+bug1032654 ii libapt-pkg6.0 2.6.0 ii libboost-iostreams1.74.0 1.74.0+ds1-21 ii libc6 2.36-9 ii libcwidget4 0.5.18-6 ii libgcc-s1 12.2.0-14 ii libncursesw6 6.4-4 ii libsigc++-2.0-0v5 2.12.0-1 ii libsqlite3-0 3.40.1-2 ii libstdc++612.2.0-14 ii libtinfo6 6.4-4 ii libxapian30 1.4.22-1 Versions of packages aptitude recommends: ii libdpkg-perl1.21.22 ii sensible-utils 0.0.17+nmu1 Versions of packages aptitude suggests: ii apt-xapian-index0.53 ii aptitude-doc-cs [aptitude-doc] 0.8.13-5+abe+test1+bug1032654 ii aptitude-doc-en [aptitude-doc] 0.8.13-5+abe+test1+bug1032654 ii aptitude-doc-es [aptitude-doc] 0.8.13-5+abe+test1+bug1032654 ii aptitude-doc-fi [aptitude-doc] 0.8.13-5+abe+test1+bug1032654 ii aptitude-doc-fr [aptitude-doc] 0.8.13-5+abe+test1+bug1032654 ii aptitude-doc-it [aptitude-doc] 0.8.13-5+abe+test1+bug1032654 ii aptitude-doc-ja [aptitude-doc] 0.8.13-5+abe+test1+bug1032654 ii aptitude-doc-nl [aptitude-doc] 0.8.13-5+abe+test1+bug1032654 ii aptitude-doc-ru [aptitude-doc] 0.8.13-5+abe+test1+bug1032654 ii debtags 2.1.5 ii tasksel 3.72 -- no debconf information ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1035976: Bug#1035976: Bug#1035976: aptitude dies with SEGV
Hi Harald, Harald Dunkel wrote: > apparently it is not sufficient to just add the entry to sources.list.d. > I had to update the local cache to make aptitude die. Ok, another try: # pbuilder update --autocleanaptcache # pbuilder login ## apt install aptitude wget gpg ca-certificates ## wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor -o /etc/apt/trusted.gpg.d/hashicorp-archive-keyring.gpg ## echo "deb https://apt.releases.hashicorp.com bookworm main" > /etc/apt/sources.list.d/hashicorp.list ## apt update Hit:1 http://debian.ethz.ch/debian sid InRelease Get:2 https://apt.releases.hashicorp.com bookworm InRelease [12.9 kB] Get:3 https://apt.releases.hashicorp.com bookworm/main amd64 Packages [84.4 kB] ## aptitude TUI comes up. No crash. > > * Do you have any custom settings for settings influencing aptitude's > >package display like "Aptitude::UI::Package-Display-Format" or > >"Aptitude::UI::Default-Grouping"? > > No, I just have > > # cat .aptitude/config Looks harmless indeed. > > * Under which locale settings does it happen for you? > > On some systems I have set LANG=C or LANG=en_US.UTF-8, but I can reproduce > this using > > # locale > LANG= > LANGUAGE= > LC_CTYPE="POSIX" > LC_NUMERIC="POSIX" > LC_TIME="POSIX" > LC_COLLATE="POSIX" > LC_MONETARY="POSIX" > LC_MESSAGES="POSIX" > LC_PAPER="POSIX" > LC_NAME="POSIX" > LC_ADDRESS="POSIX" > LC_TELEPHONE="POSIX" > LC_MEASUREMENT="POSIX" > LC_IDENTIFICATION="POSIX" > LC_ALL= > > I doubt that this is related to the locale. Thanks. I indeed think we can rule that out, too. Then again, I'm out of ideas now, except for looking with strace where the crash happens. > > If you neither use any of these settings nor use a non-english locale, > > is there any chance that you can install these packages (for > > bookworm/sid, otherwise run "find-dbgsym-packages aptitude" from the > > debian-goodies package) on one of the affected machines: > > > > strace aptitude-dbgsym libapt-pkg6.0-dbgsym > > libboost-iostreams1.74.0-dbgsym libbz2-1.0-dbgsym libc6-dbg > > libcap2-dbgsym libcwidget4-dbgsym libelogind0-dbgsym libgcc-s1-dbgsym > > libgcrypt20-dbgsym libgpg-error0-dbgsym liblz4-1-dbgsym > > liblzma5-dbgsym libncursesw6-dbgsym libsigc++-2.0-0v5-dbgsym > > libsqlite3-0-dbgsym libstdc++6-dbgsym libtinfo6-dbgsym libudev1-dbgsym > > libuuid1-dbgsym libxapian30-dbgsym libxxhash0-dbgsym libzstd1-dbgsym > > zlib1g-dbgsym > > > > libelogind0? This breaks systemd. Ah, sorry, didn'y notice that. Wanted to avoid that you need to install debian-goodies for find-dbgsym-packages so I ran "find-dbgsym-packages --all aptitude" on one of my systems. Seems as if the output actually depends on which alternatives have been chosen on the local system. Of course libsystemd0-dbgsym is fine as well if you have libsystemd0 installed. (I also doubt that all of these are really necessary. Probably "aptitude-dbgsym libapt-pkg6.0-dbgsym libboost-iostreams1.74.0-dbgsym libcwidget4-dbgsym libgcc-s1-dbgsym libncursesw6-dbgsym libsigc++-2.0-0v5-dbgsym libxapian30-dbgsym" already suffice to cover everything which might be involved in such a crash, especially since it does not happen when downloading or accessing the package lists.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1035976: Bug#1035976: aptitude dies with SEGV
Control: tag -1 + unreproducible moreinfo Hi Harald, Harald Dunkel wrote: > For testing I scanned all additional repositories in my sources.list.d. > It dies about > > deb [arch=amd64 > signed-by=/etc/apt/trusted.gpg.d/hashicorp-archive-keyring.gpg] > https://apt.releases.hashicorp.com bookworm main > > see https://www.hashicorp.com/official-packaging-guide. Sorry to bother you again, but while this looked very good as potential cause (or actually still does), I can't reproduce it inside a Sid pbuilder chroot. So I assume there's another detail which is required, too, to reproduce it. Some more ideas to check: * Do you have any custom settings for settings influencing aptitude's package display like "Aptitude::UI::Package-Display-Format" or "Aptitude::UI::Default-Grouping"? * Under which locale settings does it happen for you? If you neither use any of these settings nor use a non-english locale, is there any chance that you can install these packages (for bookworm/sid, otherwise run "find-dbgsym-packages aptitude" from the debian-goodies package) on one of the affected machines: strace aptitude-dbgsym libapt-pkg6.0-dbgsym libboost-iostreams1.74.0-dbgsym libbz2-1.0-dbgsym libc6-dbg libcap2-dbgsym libcwidget4-dbgsym libelogind0-dbgsym libgcc-s1-dbgsym libgcrypt20-dbgsym libgpg-error0-dbgsym liblz4-1-dbgsym liblzma5-dbgsym libncursesw6-dbgsym libsigc++-2.0-0v5-dbgsym libsqlite3-0-dbgsym libstdc++6-dbgsym libtinfo6-dbgsym libudev1-dbgsym libuuid1-dbgsym libxapian30-dbgsym libxxhash0-dbgsym libzstd1-dbgsym zlib1g-dbgsym And then run "strace -o aptitude-1035976.strace aptitude" and send me that file? (Probably best in compressed form.) Because that's what I just wanted to do if I would have been able to reproduce it. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1035976: Bug#1035976: aptitude dies with SEGV
Hi Harald, Harald Dunkel wrote: > For testing I scanned all additional repositories in my sources.list.d. > It dies about > > deb [arch=amd64 > signed-by=/etc/apt/trusted.gpg.d/hashicorp-archive-keyring.gpg] > https://apt.releases.hashicorp.com bookworm main Thanks for figuring out that. Will see if I can figure out more. > I don't know who is to blame here, but I hope this helps I currently asssume that there is some field unset in their repo meta data, which aptitude's GUI (and only the GUI) expects to be set unconditionally. I guess stracing will reveal some more details. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1035976: Bug#1035976: aptitude dies with SEGV
Control: found -1 0.8.13-3
Control: tag -1 + moreinfo
Hi Harald,
Harald Dunkel wrote:
> Running aptitude without arguments in a ssh session to a remote
> host I see the "loading cache" message as usual, but then it dies
> with
>
> Ouch! Got SIGSEGV, dying..
> Segmentation fault
>
> aptitude update, upgrade etc work without problems, AFAICT.
I assume this happens primarily as root on the remote host.
> I can reproduce this on several remote hosts running Bullseye or
> Testing,
Marking as found in 0.8.13-3 then.
> so it must be related to my environment somehow (Testing
> on a desktop PC), but it doesn't tell.
Ack. Doesn't look like a repo issue. Except maybe, if there's a common
non-debian APT repo involved.
Oh, and since about when is this happening? I assume this showed up
only recently, not for years. :-)
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1033623: Bug#1033623: aptitude TUI does not provide a way to invoke "safe-upgrade" command
Control: severity -1 wishlist Control: tag -1 + confirmed Hi, Piotr Dąbrowski wrote: > There is no way to invoke "safe-upgrade" command from aptitude TUI. Indeed. Never noticed (or missed that) so far in like two decades of using aptitude. I though agree that there are cases where this might helpful. > Maybe a new menu item and a shortcut should be added for "safe-upgrade"? Yes, that's a good idea. Maybe I or Y (just beside U on most keyboard layouts). > Or "U" replaced with "safe-upgrade", while "full-upgrade" given a new > shortcut? I don't think that's a good idea as it breaks current TUI workflows and the muscle memory of users. > Or a dialog could ask which type of upgrade the user wants to > invoke? Neither that, for the same reason. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1033357: Bug#1033357: aptitude: TUI does not display all error messages
Control: severity -1 important Control: tag -1 confirmed Hi Vincent, Vincent Lefevre wrote: > I've got the following error message from the TUI (with 'u' to update): > > ┌──┐ > │E: Failed to download some files > ▒│ > │W: Failed to fetch > ▒│ > │ https://ftp.debian.org/debian/dists/experimental/InRelease: > ▒│ > │E: Some index files failed to download. They have been ignored, or old ones > ▒│ > │ used instead. > ▒│ > │[ Ok ] > │ > └──┘ > > However, "aptitude update" (like "apt update") is more informative: > > [...] > 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' > E: Failed to download some files > W: Failed to fetch > https://ftp.debian.org/debian/dists/experimental/InRelease: > E: Some index files failed to download. They have been ignored, or old ones > used instead. 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. Interestingly compared to your last bug repoirt this time I think the severity is higher, as this is an error which doesn't let you to properly continue without proper explanation. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1032654: Bug#1032654: aptitude: missing message about the Debian bookworm change concerning non-free-firmware
dn't and from the code it also seems that this option has no influence on how aptitude uses apt's DumpErrors(). Anyway, despite I uncovered some more severe issues while trying to understand how apt's and aptitude's message handling works internally, I strongly disagree about the severity of the initial bug report (at least those parts which were clear enough) and agree with the apt developers that the message about the Debian bookworm change concerning non-free-firmware is only a notice, not a warning. And I don't expect that Manuel (and surely not me myself) will change something in the way aptitude handles messages from apt for bookworm as it likely will be way more invasive than is good at this stage of the freeze. Hence tagging it as wontfix, too. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1028046: aptitude: Segfault when updating package list while mirror update was running
Package: aptitude Version: 0.8.13-5 Severity: normal aptitude just crashed with a segfault for me when updating the package list while a mirror update was close to be finished on the used Debian mirror. (Haven't seen a segfault in aptitude for quite a while, so I assume this is either a rather seldom race condition or — probably less likely — triggered by a recent update of apt.) [2(1)/...] Resolving dependencies. e: Examine !: Apply .: Next ,: Previous Ouch! Got SIGSEGV, dying.. 100% [1]20272 segmentation fault (core dumped) aptitude -u aptitude -u 554.84s user 35.81s system 144% cpu 6:49.49 total Backtrace: Reading symbols from /usr/bin/aptitude-curses... Reading symbols from /usr/lib/debug/.build-id/7b/241a91e617342e555693ae8e22daf38a7276f9.debug... Illegal process-id: 20272-0-0-11-1672996274-c6--usr-bin-aptitude-curses.core. [New LWP 20272] [New LWP 20273] [New LWP 20274] [New LWP 20275] [New LWP 24174] [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 -u'. Program terminated with signal SIGSEGV, Segmentation fault. #0 operator+ (m=..., p=) at ./obj-x86_64-linux-gnu/include/apt-pkg/pkgcache.h:104 104 ./obj-x86_64-linux-gnu/include/apt-pkg/pkgcache.h: No such file or directory. [Current thread is 1 (Thread 0x7f9b1d2228c0 (LWP 20272))] (gdb) bt #0 operator+ (m=..., p=) at ./obj-x86_64-linux-gnu/include/apt-pkg/pkgcache.h:104 #1 pkgCache::DepIterator::operator++ (this=this@entry=0x7ffd004162b0) at ./apt-pkg/pkgcache.cc:474 #2 0x55598034ea72 in surrounding_or (dep=..., start=..., end=..., cache=) at ../../../../src/generic/apt/apt.cc:813 #3 0x5559802cd6c4 in aptitude_resolver_dep::aptitude_resolver_dep (this=0x7ffd00416470, dep=, _prv=, _cache=) at ../../../src/generic/apt/aptitude_resolver_universe.h:422 #4 0x5559804436a1 in aptitude_resolver_version::dep_iterator::operator* (this=0x7ffd004164f0) at ../../../../src/generic/apt/aptitude_resolver_universe.h:813 #5 aptitude_universe::dep_iterator::operator* (this=0x7ffd004164c0) at ../../../../src/generic/apt/aptitude_resolver_universe.h:1235 #6 generic_problem_resolver::generic_problem_resolver (this=this@entry=0x555983f4f990, _step_score=_step_score@entry=-10, _broken_score=_broken_score@entry=-100, _unfixed_soft_score=_unfixed_soft_score@entry=-200, infinity=infinity@entry=100, _full_solution_score=_full_solution_score@entry=50, _unfixed_soft_cost=..., _future_horizon=50, _initial_state=..., _universe=...) at ../../../../src/generic/problemresolver/problemresolver.h:3786 #7 0x555980434926 in aptitude_resolver::aptitude_resolver (this=this@entry=0x555983f4f990, step_score=-10, broken_score=broken_score@entry=-100, unfixed_soft_score=unfixed_soft_score@entry=-200, infinity=infinity@entry=100, resolution_score=resolution_score@entry=50, unfixed_soft_cost=..., future_horizon=50, _cost_settings=..., initial_installations=..., cache=0x555981a4c0d0, _policy=0x5559896c0450) at ../../../../src/generic/apt/aptitude_resolver.cc:734 #8 0x5559803b3b16 in resolver_manager::create_resolver (this=0x5559818227c0) at ../../../../src/generic/apt/resolver_manager.cc:968 #9 0x5559803b4dcb in resolver_manager::maybe_create_resolver (this=0x5559818227c0, consider_policybroken=) at ../../../../src/generic/apt/resolver_manager.cc:805 #10 0x5559803b556f in resolver_manager::maybe_create_resolver (this=0x5559818227c0) at ../../../../src/generic/apt/resolver_manager.h:474 #11 resolver_manager::resolver_manager (this=this@entry=0x5559818227c0, _cache_file=_cache_file@entry=0x555985809060, _initial_installations=...) at ../../../../src/generic/apt/resolver_manager.cc:195 #12 0x5559803564eb in apt_load_cache (progress_bar=progress_bar@entry=0x555981a39d60, do_initselections=do_initselections@entry=true, operation_needs_lock=operation_needs_lock@entry=true, status_fname=status_fname@entry=0x0, reset_reinstall=reset_reinstall@entry=false) at ../../../../src/generic/util/immset.h:258 #13 0x55598038e098 in download_update_manager::finish (this=this@entry=0x55598d035a80, res=res@entry=pkgAcquire::Continue, progress=0x555981a39d60, k=...) at ../../../../src/generic/apt/download_update_manager.cc:209 #14 0x5559802c0c90 in ui_download_manager::done (this=0x55598d136d40, t=, res=pkgAcquire::Continue) at /usr/include/cwidget/generic/util/ref_ptr.h:159 #15 0x55598023734c in sigc::slot2::operator() (_A_a2=@0x7ffd00417464: pkgAcquire::Continue, _A_a1=@0x7ffd00417468: 0x55598450dca0, this=0x7ffd00417470) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:798 #16 (anonymous namespace)::do_download_complete (t=, res=, continuation=...) at ../../src/download_thread.cc:220 #17 0x55598023bcd3 in sigc::pointer_functor3, void>::operator() (this=0x555981a12b60, _A_a3=...,
[Aptitude-devel] Bug#1023559: Bug#1023559: show with no arguments
Control: tag -1 + confirmed Hi Dan, Dan Jacobson wrote: > Package: aptitude > Version: 0.8.13-5 > Severity: wishlist > > $ aptitude show > with no arguments should print a usage message. Indeed. Or at least do something useful instead of just loading the whole DB and then exiting. Thanks for the report! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1023268: Bug#1023268: aptitude: apt-listchanges fails
Hi Nicolas, Nicolas Patrois wrote: > apt-listchanges fails with aptitude (not with apt or with synaptic). Interesting. Thanks for the bug report. > Here is its error output: > > Récupération des rapports de bogue… Fait > Analyse des informations Trouvé/Corrigé… Fait > Invalid MIT-MAGIC-COOKIE-1 key > Invalid MIT-MAGIC-COOKIE-1 key > > (apt-listchanges:9303): Gtk-CRITICAL **: 12:49:38.236: > _gtk_style_provider_private_get_settings: assertion > 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed > > (apt-listchanges:9303): Gtk-CRITICAL **: 12:49:38.236: > _gtk_style_provider_private_get_settings: assertion > 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed > > (apt-listchanges:9303): Gtk-CRITICAL **: 12:49:38.236: > _gtk_style_provider_private_get_settings: assertion > 'GTK_IS_STYLE_PROVIDER_PRIVATE (provider)' failed > Segmentation fault (core dumped) > E: Le sous-processus /usr/bin/apt-listchanges --apt || test $? -lt 10 a > renvoyé > un code d'erreur (1) > E: Failure running script /usr/bin/apt-listchanges --apt || test $? -lt 10 Hrm, this looks to me as if apt-listchanges wants to open some GTK program. For me, apt-listchanges works fine, but I let it display news just with less. So a few question: * Does this already happen for quite a while or is this a new behaviour from just very recently? * Which pager have you configured (for apt-listchanges)? — I have no idea, why apt-listchanges should try to open a GTK application otherwise. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1020286: Bug#1020286: aptitude 0.8.13 @ Microknoppix
Control: retitle -1 aptitude: Removal of thousands of packages on Microknoppix Control: tag -1 + moreinfo Hi Anton, Anton Wessel wrote: > Package: aptitude > Version: 0.8.13 @ Microknoppix Which package version exactly? > When downloading and installing a few packages, aptitude 0.8.13 @ > Microknoppix had removed thousend and more packages -- even with option > "--save-resolver". If they're marked as "automatically installed" and there's no dependency on them anymore, aptitude will do that. (And apt would by default show a huge "apt autoremove" list.) >From my mind: --save-resolver makes aptitude to prefer keeping packages rather not updated instead of removing conflicting packages in case of dependency conflicts. (I must admit the wording "it will never remove a package" in the man page might be suboptimal. It is meant to be in the context of the beginning of the paragraph which says "When package dependency problems are encountered".) But with such few details (more or less none), there's no chance to track the real reason down, especially not if it's a bug or just an unlucky set of "automatically installed" flags. Were you able to stop before this happened? Would it still happen if you start aptitude again? If that's the case, please run aptitude-create-state-bundle /tmp/large-package-removal-0.8.13-microknoppix (or similar, the file name actually doesn't matter) and send the resulting file to us. If it's too large for e-mail, please try to upload it somewhere and send the link. The file will contain all subscribed package lists as well as the state of all installed packages as aptitude seems them. So if you consider these to be too personal information, feel free to just send the file or link to me and feel free to encrypt it with PGP for one of my PGP keys shown below. (The 4096 bits key is also available in the file /usr/share/keyrings/debian-keyring.gpg if the package debian-keyring is installed.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1019465: Bug#1019465: Bug#1019465: aptitude: wants to remove the required package lsb-base with a broken reason
Control: tag -1 - moreinfo Hi Vincent, Vincent Lefevre wrote: > > > Linux Standard Base init script functionality > > > lsb-base (remove, 11.2) will be automatically removed because of > > > dependency▒ > > > errors: > > > ▒ > > > > Where did this show up? I didn't get this. Or at least can't remember > > it. Was this a pop-up message? > > After typing 'g' (to "perform all pending installations, removals, > and upgrades") and putting the cursor over the > > id lsb-base -50.2 kB 11.2 11.2 > > line (in order to learn why this package is removed). This is what > the bottom part of the window shows. Ah, I didn't see that because I have the description window hidden by default. Thanks for the explanation. > > > but no errors shown!!! > > > > Because they were resolved. > > OK, so the real reason should be given. Ack. > > > It seems to be triggered by the upgrade of sysvinit packages from > > > 3.04-1 to 3.05-2. In the sysvinit 3.05-1 log message: > > > > > > * Take over library scripts from lsb-base. > > > > Yes, but because of this: > > > > Conflicts: lsb-base > > Normally conflicts produce an error on packages that must not be > removed. Here, I suppose that this is OK because of > > Provides: lsb-base (= 11.1.0) > > (by default, this is not shown by aptitude in the package description). Hmmm, yeah, that probably should be fixed, too. > > So from my point of view aptitude did everything correctly and I don't > > see a bug here. > > Well, the "because of dependency errors" in the above message is > incorrect and very confusing. Since there are no dependency errors, > this cannot be because of dependency errors. Indeed. Thanks for the additional information! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1019465: Bug#1019465: aptitude: wants to remove the required package lsb-base with a broken reason
Control: tag -1 + moreinfo
Hi Vincent,
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 11.2
which is correct, yes.
> Linux Standard Base init script functionality
> lsb-base (remove, 11.2) will be automatically removed because of dependency
> ▒
> errors:
> ▒
Where did this show up? I didn't get this. Or at least can't remember
it. Was this a pop-up message?
> but no errors shown!!!
Because they were resolved.
> It seems to be triggered by the upgrade of sysvinit packages from
> 3.04-1 to 3.05-2. In the sysvinit 3.05-1 log message:
>
> * Take over library scripts from lsb-base.
Yes, but because of this:
Conflicts: lsb-base
So from my point of view aptitude did everything correctly and I don't
see a bug here.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1019447: Bug#1019447: aptitude: Wrong "Press Return to continue" after succesful installation
raction. I see. Thanks for this explicit hint. It really helped to see that you really want that. (Previously I couldn't really imagine this as I'm quite happy that it stops there. I'm just annoyed that can't say "quit" when starting the run, hence the fourth item above. :-) > Again, that is stupid: I disagree. :-) > when you run some lengthy installation you go away from display and > when you return back it asks for Enter then it forces you to wait > until UI is reloaded. JFTR: We're talking about a second on a 5 year old PC with SSDs and at most a minute or two on a very old legacy system with slow CPU (e.g. a Pentium 4 Mobile) and a slow, rotating disk. I see your point, but if its worse or better than the initial variant which you want back depends a lot on how you use aptitude. Let me summarize: * Initially there seemed no "Press Enter" at all. There you then had to press "q" and aptitude would save its stuff, but you don't have to wait unless you need the shell prompt directly again. * In between you had to press Enter, then wait until you can press "q" to quit and then wait again in case you need the shell prompt directly again. This was clearly the worst combination. * Now you have the option to press "q" before it is returning to the TUI for saving some stuff to disk, but you also only have to wait for that if need the shell prompt directly again. From my point of view this is slightly better than the initial variant as the pressing of "q" comes earlier (before the TUI is loaded again and not afterwards) and hence saves you these seconds (or minutes) you argue about by only having to wait for them in case you want back to the shell prompt. I though see that if you start such a run and get back only later, you loose a few seconds. Seems to depend a lot on the way how someone's using the TUI. > That interaction didn't help me in any single case. At least some people (obviously the person implemented or requested this and me myself :-) want to see that output in any case. I see quite a few cases where it makes sense to wait before the user is acknowledging that the output has been seen (or is not relevant): E.g. it is very useful if you have APT plugins like how-can-i-help which output some information at the end of each run. Also with local post-action hooks which e.g. run hardlink over /usr/share/doc/ and then display some statistics about the save disk space benefit from that prompt. Anyway, let's see this as a feature request. It might count as UI regression, too, but I don't see it really as a bug. Hence I set the severity to wishlist, but also tagged the issue as confirmed, i.e. that there is indeed need for such a feature. I'm though aware that adding a configurable option is way less trivial than hardcoding a different behaviour. Nevertheless: Patches for such a feature are of course welcome. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1019447: Bug#1019447: aptitude: Wrong "Press Return to continue" after succesful installation
Control: tag -1 + moreinfo
Hi Aleksey,
thanks for the bug report.
Aleksey Midenkov wrote:
> Since some version aptitude started to behave strangely: it asks user
> interaction after each successful installation.
I thought that the "Press Return to continue" was always there, just
the "'q' followed by Return to quit" has been added as a feature
somewhen 7 or 8 years ago. But now I'm no more sure if that "Press
Return to continue" was really there before.
What definitely has been added around that time (in 0.7.3 from October
2015) was this "Perfoming actions" line when switching from TUI to
installation output. (https://bugs.debian.org/323371)
> Press Return to continue, 'q' followed by Return to quit.
>
> That is strange because 'q' returns first into the UI and then
> quits.
This is correct and is intended.
> So no obvious reason to use 'q' from the above interaction because 'q'
> also works from the UI.
No, the reason is that you don't have to wait to reload the database
before being able to press "q" again.
> I guess the above pause was added to display
> the errors if any happened
There is no pause in that sense. The time the UI is displayed is AFAIK
needed to properly write down the current state of aptitude's package
list after the package installation.
> but the condition in the code for that was chosen wrongly.
The only thing I remember from discussions back then is that querying
for a "q" keypress without the following "Enter" press was much more
work than worth it and would have required a rewrite of the whole
input handling at that point in the workflow.
> I hope you will find the below patch well-suited for stopping
> bugging you with that useless pause.
>
> --- b/src/ui.cc 2020-05-21 06:32:38.0 +0300
> +++ b/src/ui.cc 2022-09-09 13:41:49.752101187 +0300
> @@ -1276,7 +1276,7 @@
> pkgPackageManager::OrderResult rval = f(-1);
>
> bool quit_after_dpkg_run = false;
> -if(rval != pkgPackageManager::Incomplete)
> +if(rval != pkgPackageManager::Completed)
>{
> cout << _("Press Return to continue, 'q' followed by Return to
> quit.") << endl;
Doesn't make sense to me. But maybe I also still haven't understood
what you're actually trying to achieve.
What exactly do you expect aptitude to do when the package
installation/update/removal run ended?
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1017492: aptitude: aptitude-changelog-parser: warning: unknow information field '' in input data in parsed version of changelog
Package: aptitude
Version: 0.8.13-5
Severity: minor
Pressing "C" for getting the changelog on debian-policy when marked for
updating from 4.6.1.0 to 4.6.1.1, aptitude-changelog-parser throws a
warning (multiple times) and scrambles the whole screen with them:
Packages
debian-policy changes
debian-policy (4.6.1.1) unstable; urgency=medium
#
iu apfsprogs
it20210928-2 0+git20220815+ds-1 ▒
* d/control: Add Homepage field (Closes: #1012879). 0482
kB 1.9.0-1 1.9.0-2▒
Thanks to Benjamin Drung for the suggestion. 0
20.2 MB 1.9.0-1 1.9.0-2
▒
* Upgrading checklist for 4.5.1: apply wording change from 07f1b39
89.1 kB 0.9.0-3 0.9.0-4
▒
(Closes: #1017095).0 -1024 B 150
kB 0.15.1-1 0.15.1-2 ▒
▒
-- Sean Whitton Sat, 13 Aug 2022 17:13:34
-07002585 kB 1.6.12-1 1.6.12-2
▒
iuA i oot-common 0338
kB 1.6.12-1 1.6.12-2 ▒
debian-policy (4.6.1.0) unstable; urgency=medium 1 +75.8 kB
3494 kB 5.18.0-1 5.19.0-1
▒
▒
* Policy: Allow non-64-bit packages to install to /usr/lib64
▒
Wording: Sean Whitton
▒
Seconded: Simon McVittie
▒
Seconded: Russ Allbery
▒
Closes: #992601
▒
* Policy: Define 'upstream' & document several version conventions
▒
Wording: Russ Allbery
▒
Seconded: Sam Hartman
▒
Seconded: Sean Whitton
▒
Closes: #542288, #850729
▒
* virtual-package-names-list: Add {default,}dbus-system-bus (Closes:
#998063).
▒
Thanks to Simon McVittie for the patch.
▒
iu* Update 9.7.2 and 9.7.3 for package split of bin:mime-support into
4792 kB 4:5.96.0-1 4:5.97.0-1
▒
iu bin:media-types and bin:mailcap (Closes: #1008480).0 +4096 B 508
kB 1.50.7+ds-1 1.50.9+ds-1▒
iu Thanks to Charles Plessy for the patch.0
95.2 kB 1.50.7+ds-1 1.50.9+ds-1
▒
iu i m 0157
kB 1.50.7+ds-1 1.50.9+ds-1▒
* Fix several problems with footnote regarding the autobuilders and
▒
build dependency alternatives (Closes: #999826).
▒
iu Thanks to Johannes Schauer Marin Rodrigues for the report and patch.kB
[Aptitude-devel] Bug#1012895: cwidget RC bug: Please upload or grant me cwidget team membership on Salsa
Hi Manuel,
Manuel A. Fernandez Montecelo wrote:
> > I know you're busy with RISC-V and other stuff, but please do me a
> > small favour and add me to the cwidget team on Salsa, probably via
> > https://salsa.debian.org/groups/cwidget-team/-/group_members
>
> Yeah, I dedicate my stuff mostly to RISC-V because I have nothing to
> spare in the last few years, and even there I'm lacking :-(
Oh. :-/
> I had seen this from pabs but will not have time at least until mid
> next week, so better if you do it and have permissions in general
> anyway, as you say.
Thanks for adding my to the cwidget team. I will do an cwidget upload
within the next few days and afterwards an aptitude upload.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1012895: cwidget RC bug: Please upload or grant me cwidget team membership on Salsa
Hi Manuel, TL;DR: Please grant me cwidget team membership on Salsa so we don't have to NMU it. Or just do an upload of cwidget with the patch from #1015925. I know you're busy with RISC-V and other stuff, but please do me a small favour and add me to the cwidget team on Salsa, probably via https://salsa.debian.org/groups/cwidget-team/-/group_members Background: There are currently RC bugs in aptitude and cwidget which both cause aptitude to FTBFS with GCC 12: https://bugs.debian.org/1015925 https://bugs.debian.org/1012895 Both bug reports have patches by pabs (Cc'ed). Without having the cwidget bugs (#1015925) fixed, I can't fix the aptitude one (#1012895). Currently you're the only "cwidget team" member on Salsa. I've requested team membership there a few days ago, so I can do proper "Team uploads" for cwidget, too. Otherwise pabs or me would have to NMU cwidget. And I think having a second uploader for cwidget would be good in the long run anyway, especially because aptitude is its only library user. Other options beside the NMU are (obviously) that you do a quick upload of cwidget with pabs' patch from #1015925. (Sent from my non-debian address to your non-debian address due to the current GMail fuckup which causes tons of false positive mail rejections by GMail, especially with mails forwarded by the BTS.) Kind regards, Axel -- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: a...@deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: a...@noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/ signature.asc Description: PGP signature ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1012895: Bug#1012895: aptitude: ftbfs with GCC-12
Hi Paul, Paul Wise wrote: > On Tue, 2022-07-26 at 00:28 +0200, Axel Beckert wrote: > > Paul Wise wrote: > > > I tried to build aptitude, found it fails due to cwidget bug #1015925. > > > > Do you intend to NMU that? > > I'd prefer the cwidget team take care of it, […] > > Not really true. It's just that we haven't made a real "upstream" > > release for quite a while because Manuel is mostly busy with the RISC > > V port. Manuel is "the cwidget team": https://salsa.debian.org/groups/cwidget-team/-/group_members I've requested team membership now as it kinda doesn't make sense that Manuel does this alone despite aptitude is AFAIK the only consumer so far. > > As far I understood, it doesn't make sense to upload a new aptitude > > package before #1015925 is fixed. > > Agreed. Ok, so let's see if I get into that team. I'll also try to nudge separately due to the current GMail fuckup. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1012895: aptitude: ftbfs with GCC-12
Hi Paul, Paul Wise wrote: > I tried to build aptitude, found it fails due to cwidget bug #1015925. Do you intend to NMU that? > The issue is that the operator<< functions are not declared before the > call site, so forward declarations before HelperMacros.h are needed: Thanks for having looked into this. > I'm not sure how to contribute this change to the package because this > should be a native package but isn't I'm not that sure about this. But it is probably historically grown. > and has debian/patches/ Correct, this is mostly used for short-term fixes. > but also an upstream master branch Correct. This is where actual development and new "upstream" releases happen. > that seems to be unused. Not really true. It's just that we haven't made a real "upstream" release for quite a while because Manuel is mostly busy with the RISC V port. > I suggest merging the contents of debian/patches/ to the upstream > master branch IIRC this is partially already done. > and then cherry-picking the FTBFS patches to a new minor > release branch instead of using debian/patches/. If it needs to be done quick, it will not happen that way. > I've filed two merge requests with two different approaches, one is a > commit for the master branch and one a patch for the debian-sid branch. Thanks. Attaching the patch here would have sufficed, though. As far I understood, it doesn't make sense to upload a new aptitude package before #1015925 is fixed. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1012895: Bug#1012895: Bug#1012895: aptitude: ftbfs with GCC-12
Control: tag -1 - moreinfo Hi Matthias, Matthias Klose wrote: > > > > GCC 11 defaults to the GNU++17 standard. If your package installs > > > > header files in /usr/include, please don't work around C++17 issues > > > > by choosing a lower C++ standard for the package build, but fix these > > > > issues to build with the C++17 standard. > > > > > > Is the same copy & paste error from the GCC 11 bug reports back then > > > as above or is this actually correct for GCC 12? Please clarify. > > yes, the default C++ standard didn't change for GCC 12. Thanks! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1012895: Bug#1012895: aptitude: ftbfs with GCC-12
Control: tag -1 + moreinfo Hi Matthias, Matthias Klose wrote: > The package fails to build in a test rebuild on at least amd64 with > gcc-12/g++-12, but succeeds to build with gcc-11/g++-11. Thanks for the heads up! > To build with GCC 11, either set CC=gcc-11 CXX=g++-11 explicitly, I think you mean 12 instead of 11. > GCC 11 defaults to the GNU++17 standard. If your package installs > header files in /usr/include, please don't work around C++17 issues > by choosing a lower C++ standard for the package build, but fix these > issues to build with the C++17 standard. Is the same copy & paste error from the GCC 11 bug reports back then as above or is this actually correct for GCC 12? Please clarify. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#999766: Bug#999766: aptitude: in the TUI, with "+m" on a piA package, aptitude doesn't remember the manually installed state
Control: tag -1 + confirmed Hi Vincent, thanks for the detailed bug report with all the steps to reproduce. Vincent Lefevre wrote: > 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: 123 MB/123 > MB > > [1(1)/...] Actions: 7 keeps > e: Examine !: Apply .: Next ,: Previous > > 2. I type 'g' to perform the pending operations, keeping these > unrelated packages. This gives: > > --\ Packages to be upgraded (1) > iu ksh -3312 kB 2020.0.0+really93u+20120 20210511 > --\ Packages being automatically installed to satisfy dependencies (1) > piA ksh93u+m +3284 kB 1.0.0~beta.1-1 > > 3. Over ksh93u+m, I type '+m' (the '+' does nothing but it is actually > important to reproduce the bug), where 'm' now declares ksh93u+m as to > be manually installed. [...] > --\ Packages being removed because they are no longer used (1) > idA ksh93u+m -3284 kB 1.0.0~beta.1-1 1.0.0~beta.1-1 > > while this package should have been considered manually installed > due to step 3. Correct, I can reproduce it, also with just pressing "U" again instead of quitting, i.e. it seems as if every action which writes down and rereads the current state triggers this unexpected behaviour. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#999383: Bug#999383: aptitude: bashism in configure script
Control: tag -1 + moreinfo confirmed patch Hi Andrej, Andrej Shadura wrote: > It is possible your package uses configure script with bash features not > present in POSIX without explicitly declaring the need to bash shell; this > currently works as configure scripts select bash, but when dash enables > LINENO support, I'm sorry, but I don't get it: Why does _ENABLING_ a feature (which I assume adds more compatibility with Bash) causes more issues than without? Please explain what this change actually does or give pointers to according documentation. > your configure script may start failing. According to your attached log it's clearly not the configure script. > […] > [ 477s] config.status: creating po/Makefile > [ 477s] config.status: executing depfiles commands > [ 477s] config.status: executing copy-gtest commands > [ 477s] config.status: executing copy-gmock commands > [ 478s] make[1]: Leaving directory '/usr/src/packages/BUILD' > [ 478s]dh_auto_build -O--builddirectory=build > -O--dbgsym-migration=aptitude-dbg The configure script succeeded and dh_auto_build was started. > [ 478s] cd build && make -j3 ^^^ This is not helpful when trying to debug build failures. Please refrain from using parallel building for such bug reports in the future as it usually just hides the real issue. Thanks in advance. I've rebuilt it with -j1 and can confirm that the configure script is not the issue, but this part from your build log: > [ 1024s] make[5]: Entering directory '/usr/src/packages/BUILD/build/doc/fi' > [ 1024s] rm -fr output-man/ > [ 1024s] rm -fr output-readme/ README.fi > [ 1024s] /usr/bin/xsltproc -o output-man/aptitude.8 > ../../../doc/aptitude-man.xsl ../../../doc/fi/aptitude.xml > [ 1024s] /usr/bin/xsltproc -o output-readme/index.html > ../../../doc/aptitude-txt.xsl ../../../doc/fi/aptitude.xml > [ 1024s] rm -fr output-html/ > [ 1024s] /usr/bin/xsltproc -o output-html/ ../../../doc/aptitude-html.xsl > ../../../doc/fi/aptitude.xml > [ 1025s] Note: meta source : no *info/productname or alternative > aptitude > [ 1025s] Note: meta source : see http://www.docbook.org/tdg5/en/html/produ > aptitude > [ 1025s] Note: meta source : no refentry/refmeta/refmiscinfo@class=source > aptitude > [ 1025s] Note: meta source : see http://www.docbook.org/tdg5/en/html/refmi > aptitude > [ 1025s] Note: meta version: no *info/productnumber or alternative > aptitude > [ 1025s] Note: meta version: see http://www.docbook.org/tdg5/en/html/produ > aptitude > [ 1025s] Note: meta version: no refentry/refmeta/refmiscinfo@class=version > aptitude > [ 1025s] Note: meta version: see http://www.docbook.org/tdg5/en/html/refmi > aptitude > [ 1025s] Warn: meta source : no fallback for source, so inserted a fixme > aptitude > [ 1025s] Warn: AUTHOR sect.: no personblurb|contrib for Daniel Burrows > [ 1025s] Note: AUTHOR sect.: see http://www.docbook.org/tdg5/en/html/contr > [ 1025s] Note: AUTHOR sect.: see http://www.docbook.org/tdg5/en/html/perso > [ 1025s] Warn: AUTHOR sect.: no personblurb|contrib for Daniel Burrows > aptitude > [ 1025s] Note: AUTHOR sect.: see http://www.docbook.org/tdg5/en/html/contr > aptitude > [ 1025s] Note: AUTHOR sect.: see http://www.docbook.org/tdg5/en/html/perso > aptitude > [ 1025s] Note: Writing aptitude.8 > [ 1025s] ln -f output-man/aptitude.8 . > [ 1025s] ../../../doc/fi/fixman aptitude.8 > [ 1025s] sed: no input files > [ 1025s] sed: no input files > [ 1025s] sed: no input files > [ 1025s] sed: no input files > [ 1025s] sed: no input files > [ 1025s] sed: no input files > [ 1025s] make[5]: *** [Makefile:967: docbook-man-stamp] Error 4 I'm not sure why the following patch fixes the issue, but it does so at the expense of some more forks per build: diff --git a/buildlib/docbook.mk b/buildlib/docbook.mk index 9ec1b433..de03f0b4 100644 --- a/buildlib/docbook.mk +++ b/buildlib/docbook.mk @@ -129,7 +129,7 @@ docbook-man-stamp: $(DOCBOOK_XML) aptitude-man.xsl aptitude-common.xsl @if [ -x "$(srcdir)/fixman" ]; then \ for i in $(DOCBOOK_MANS); do \ echo "$(srcdir)/fixman $$i"; \ - . $(srcdir)/fixman $$i; \ + $(srcdir)/fixman $$i; \ done; \ fi touch docbook-man-stamp It is also unclear to me what the relation of this patch to line numbers or a variable called LINENO is. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#967911: Bug#967911: aptitude: aptitude-changelog-parser leaves garbage on the screen
Hi Guillem,
Guillem Jover wrote:
> > In any case, Dpkg::Changelog defaults to printing these parsing
> > problems as warnings, but there is no way to pass a «verbose => 0» via
> > changelog_parse(). I'll add support for that too.
>
> This is now supported since dpkg 1.20.6, so I'm attaching the updated
> patch.
Thanks!
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#995256: Bug#995256: aptitude: TUI loops "Can't find a source to download ..." error
Hi David, David Kalnischkies wrote: > > I wonder if there is a kind of race condition if aptitude is running > > and then either on the admin on the commandline or a background job > > runs "apt update". > > That can indeed mess up some things as the cache (which is then old) > still points to file locations in the "old" files rather than what an > update might have placed in there in the meantime. […] > > So this package in question is arch:all. > > > > But according to the screenshot, aptitude wants > > texlive-fonts-recommended:amd64 for whatever reason — which indeed > > does not exist. > > This is a misunderstanding. An arch:all deb file is always attributed to > be of the native architecture, in your case amd64. That is because > libapt makes a difference between a package(name with architecture) and > a version (of a package with version number & architecture). […] Thanks for these explanations and clarifications, much appreciated! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#995256: Bug#995256: aptitude: TUI loops "Can't find a source to download ..." error
Hi IOhannes, IOhannes m zmoelnig wrote: > - aptitude opens new *red* window where it prints > > > E: Can't find a source to download version 'VERSION' of 'PACKAGE' > > - the error window grows as one such line is printed about every 500ms > until it finally fills the entire height of the screen I think I've seen that once or twice, too, but way to seldom to actually bother as I considered it to be caused by inconsistencies outside aptitude. > - quitting aptitude and restarting it makes the problem go away H. > I have no idea why this happens, but originally thought it might be related to > not having run 'update' as a first step. I'd rather imagine something the other way round: I wonder if there is a kind of race condition if aptitude is running and then either on the admin on the commandline or a background job runs "apt update". > in the meantime i'm not so sure about this anymore (e.g. as i think i don't > have > to run 'update' in the restarted aptitude). No, you don't have to. Aptitude more or less just reads what files are in /var/lib/apt/lists/ (and some more state files). > in any case, i have not been able to find a way to reliably reproduce the > problem (it just happens every now and then). Ack. > i've seen this problem for a "long time" by now (probably pre 2021) Yes, haven't seen it recently. > i've attached a screenshot. Thanks! There's an interesting fact visible. First let's look at that package: ~ → apt-cache show texlive-fonts-recommended Package: texlive-fonts-recommended Source: texlive-base Version: 2021.20210921-1 Installed-Size: 15031 Maintainer: Debian TeX Task Force Architecture: all So this package in question is arch:all. But according to the screenshot, aptitude wants texlive-fonts-recommended:amd64 for whatever reason — which indeed does not exist. So it's probably _not_ related to updating package lists in the background. And yes, I've recently seen such an issue elsewhere, namely here: https://salsa.debian.org/debian/zsh/-/jobs/1950702#L1463 The relevant lines are: The following packages have unmet dependencies: zsh-cross-build-deps:arm64 : Depends: cm-super-minimal:arm64 which is a virtual package and is not provided by any available package Unable to resolve dependencies! Giving up... (And yes, cm-super-minimal is arch:all as well.) Then again, the above was already during dependency resolution and not in the preview. It though still might be caused by the same bug mixing up arch:all with arch:any packages as the above error message stems from src/cmdline/cmdline_resolver.cc and hence is commandline-specific. I tried to fix this in zsh like this: https://salsa.debian.org/debian/zsh/-/commit/801f5e105ad6d1f767d28c8311edd263790f419f And it indeed fixed the crossbuild CI check: https://salsa.debian.org/debian/zsh/-/jobs/1946010 But unfortunately then on the buildds it failed for the arch:all build with "B-D uninstallable" (note the missing 5.8-8 upload on https://buildd.debian.org/status/logs.php?pkg=zsh=all) and I had to revert that "fix". > Architecture: amd64 (x86_64) > Foreign Architectures: i386 I wonder if this is a multiarch related bug since the case I mentioned above was a cross-build and hence also has multiarch involved. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#994504: Bug#994504: Bug#994504: Don't just say "not a real package"
Control: tag -1 - moreinfo Hi Jidanni, 積丹尼 Dan Jacobson wrote: > In this particular case, all I found was this package was mentioned in > other installed packages' headers. Thanks for this detail! And indeed, there are two types of packages which can be seen as virtual or non-real package and it could help to make a difference: * Those provided by a package (can be installed, etc.) — those are officially called "virtual" in the Debian Policy. * Those mentioned in package relations by other packages, but not (or no more) existing. Those exist in the dependency tree, but are not installable. I've seen those being called "virtual" as well, but I think that was never an official term for them. might have been a technical thing somewhere. > I don't know if that makes it a virtual package or not. Both these types were also called "virtual" and I'm not sure which terms should be used to distinguish between them. Aptitude calls the latter usually "UNAVAILABLE" in the context of dependencies, but something like "mentioned" or "referred to" seems more precise. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#994504: Bug#994504: Don't just say "not a real package"
Control: tag -1 + moreinfo Hi Jidanni, 積丹尼 Dan Jacobson wrote: > Package: aptitude > Version: 0.8.13-3 > Severity: wishlist > > $ aptitude show ttf-unifont > Package: ttf-unifont > State: not a real package > $ apt show ttf-unifont > Package: ttf-unifont > State: not a real package (virtual) > > That's a little better. I doubt that. To my knowledge "virtual" and "not a real package" are equivalent. Adding that would only make sense if there are other types of non-real packages. Otherwise it'd just be redundant and hence bloat. Do you know of any other non-real package type than "virtual"? Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#931543: Bug#915246: Bug#931536: aptitude update fails to cope with changed release info
Hi, Francesco Poli wrote: > this bug is still unfixed in aptitude... Correct. > Are there any plans to fix this bug in aptitude once and for all? I assume so, yes. But not by myself as this is outside of my C/C++ capabilities. (In other words: I hope that Manuel — or someone else — will find time to tackle this at some point with one of the next upstream releases.) Oh, and of course: Patches are welcome! If there are well working patches, I can also apply them in the upstream branches and do upstream releases with them. I just can't write new C++ code from scratch. (I other words: Within the Aptitude team, I'm primarily the package maintainer and Manuel does nearly all of the upstream development.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#991578: Bug#991578: aptitude: document state indicator letters more clearly
Hi Greg,
Greg Wooledge wrote:
> On Wed, Jul 28, 2021 at 10:06:45AM +0200, Axel Beckert wrote:
> > From my mind there are also some more possible states, which seem not
> > to be documented in the manual at all on a first glance. IIRC these
> > are:
> >
> > H or h = on hold
> > U or u = unpacked, but not configured, e.g. if the configure step in
> > the previous run failed.
> > B = broken (dependencies are not fullfilled)
> > F = forbidden version
>
> For whatever reason, the aptitude developers did not include all of
> the state letters in the man page. They only included the "most
> common" ones,
Ah, didn't notice this was in the man page and not the complete
manual.
> even though the example right above that section includes
> a letter that isn't in their list ("h").
Hehe.
> This patch only moves things around within the man page.
Yeah, I'm aware of it. I just used your bug report as reminder that
this part might need some more care on top of your patch.
> A larger set of state letters is documented at
> <https://www.debian.org/doc/manuals/aptitude/ch02.en.html> (more
> specifically,
> <https://www.debian.org/doc/manuals/aptitude/ch02s02s02.en.html>)
> which I *think* is what the man page is referring to when it talks
> about an "aptitude reference manual" or "reference guide".
Yes. Thanks for the pointer that we have them already in the manual.
> I don't know whether that's a complete set either.
Looks complete on a first glance. *phew* :-)
> The developers chose to keep that information out of the man page,
Yeah, in the man page this might make sense.
> and I didn't want to step on any toes,
As mentioned before, my mail was no critic on your patch. Just an
addendum for us Aptitude maintainers.
> If the developers would like the full set of state letters to
> be documented in the man page, I would definitely welcome that.
Thanks for sharing your opinion on that!
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#991578: Bug#991578: aptitude: document state indicator letters more clearly
Control: tag -1 + confirmed Hi Greg, Greg Wooledge wrote: > This patch improves the documentation of the state indicator letters, used > in the output of the "search" and "why" actions. Thanks a lot, this indeed looks like an improvement! >From my mind there are also some more possible states, which seem not to be documented in the manual at all on a first glance. IIRC these are: H or h = on hold U or u = unpacked, but not configured, e.g. if the configure step in the previous run failed. B = broken (dependencies are not fullfilled) F = forbidden version Except for "B" I'm not sure if they're lower or upper case, but that should be easy to check. IIRC those letters follow the letters in the first three columns of the "dpkg -l" output where usually bad. (Except for "A" and "F" which dpkg doesn't know about.) And then I vaguely remember that dpkg also knows the state "half-installed" which is worse than "unconfigured" and usually requires to purge the package first before reinstalling it. But I forgot the letter for it. Maybe the capital H. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#990118: Bug#990118: show packages that are not from the default release
Hi Simon,
Simon Richter wrote:
> it would be nice if there was a way to find packages whose local version is
> higher than the version from the archive that would be selected,
Aptitude is quite flexible and this is already possible. :-)
My shell has the following alias (and there is the idea to put this
one and others as small scripts into the aptitude or an add-on
package):
alias aptitude-newer-than-in-archive='aptitude -o
"Aptitude::Pkg-Display-Limit=~i ?any-version(!~O.) !~U !~o"'
> possibly as a new toplevel group "Downgradeable Packages".
Should be possible as well already. It might not be perfect yet, but I
have the following in my /etc/apt/apt.conf:
Aptitude::UI {
Default-Grouping "pattern(~i ?any-version(!~O.) !~U !~o => Non-upgradable
packages not from archive, ?true
||),filter(missing),status,section(subdir,passthrough),pattern(~O, !~O =>
other),pattern(~A, !~A => other),section(topdir),priority";
}
There's though a chance that this group then includes packages which
are actually upgradable, but just to packages where the repo or
package has a pinning lower than 100. IIRC there were cases where this
caught packages in cases like the pinning constellation mentionend
below or at least similar cases as the package with pinning below 100
are not considered for upgrading:
Pinning Source Package version
990 sid 1.2.3
100 local 1.2.3+local← would match
90 autobuild 1.2.4~autobuild
No more sure. Worked good enough for me, so I use it that way for
years now. :-)
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#988177: Bug#988177: aptitude: character encoding issues within the manual
Control: tag -1 + confirmed Dear Christoph, Christoph Anton Mitterer wrote: > When opening the manual from within aptitude, I always see character > encoding issues (just within the manual, the rest of aptitude is > fine). Good catch! As devleoper you barely look into the manual yourself. And if I do, I usually use the web browser with the HTML variant. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#902652: Bug#902652: aptitude doesn't autoremove kernels
Control: notfound 902652 0.8.13-3
Contyrol: severity 902652 norma;
Dear Jidanni,
> Proof that aptitude is not ready for
>
>/usr/share/doc/apt/NEWS.Debian.gz
>apt (2.1.16) unstable; urgency=medium
>
> Automatically remove unused kernels on apt {dist,full}-upgrade. To revert
> to previous behavior, set APT::Get::AutomaticRemove::Kernels to false or
> pass --no-auto-remove to the command. apt-get remains unchanged.
Proof that this is wrong:
That feature wasn't present in apt 1.4.8 which was present when the
original bug was reported. Hence reverting your changes to this bug
report.
Feel free to report a separate bug report for compatibility with the
2.1.16 apt changes.
And wrt. to
https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/1772688:
Please note that apt-get hasn't changed either and behaves differently
that apt. And nobody stated that aptitude will follow apt and not
apt-get. (Nobody has stated the opposite either, though, but it's
obviously the default.)
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#962926: Bug#962926: Images of aptitude screens are illegible due to being scaled to browser width
Hi Norman, thanks for sharing your thoughts and experiments on this issue. Norman Rasmussen wrote: > With respect to asciinema: I found two asciicast to svg converters: > - https://github.com/marionebl/svg-term-cli (MIT) This seems not packaged in Debian so far. > - https://github.com/nbedos/termtosvg (BSD-3-Clause) This is packaged since Bullseye: https://packages.debian.org/search?keywords=termtosvg > Both generated an animated svg by default, but have an option to extract > a single frame (svg-term-cli), or all frames (termtosvg). I found that > termtosvg rendered aptitude better than svg-term-cli. It's also the only option from these two as of now. :-) > I also tried the Secure Shell chrome extension (which uses hterm > internally, both nassh and hterm as BSD-3-Clause), and while it's > possible to capture a decent screenshot with it, the output is html and > not svg. The latter is no issue, but IMHO even a feature. The need to use a Chrome extension is though a complete no-go. Actually rather than SVG I'd rather use "aha" to generate HTML from terminal output. An example is attached although the foreground on the cyan lines should be black, not grey. (Not sure if this is a bug in aha or if it is caused by myself removing some additional content caused by the screen session around it.) So IMHO it currently would be worse than what we have now. It's though not completely trivial to trick a TUI application to pipe output into aha without making it recognize that the output is not a terminal. "script" and "screen" help there, but it's still non-trivial to actually script it (in case that's wanted and needed — at least currently it's not needed). > I'm not sure how much switching to svg would help overall. Removing the > 100% width would probably help the most. While it might help in this case, I fear that it will cause other readablity issues like being unreadable for those who require larger fonts. > Refreshing the images at a higher resolution wouldn't hurt either. Yes, but only if you also use some larger font. Otherwise the situations gets worse. > Both are easier than trying to change the image format. Well, if we want to stay with images, SVG is IMHO the way to go. The question is if HTML screenshots are not even better for e.g. blind people because they're actually "readable screenshots". And they're scalable, too. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE Title: stdin aptitude 0.8.13 @ c6 Disk: +3072 B DL: 1877 kB/2829 kB --\ Upgradable Packages (4) --\ admin Administrative utilities (install software, manage users, etc) (1) --\ Debian (1) --\ unstable (1) --\ main The main Debian archive (1) --\ Priority optional (1) iu (pinsysdig 0 +7168 B 14.4 MB 0.26.7-2+b2 0.27.1-0.2 --\ mail Programs to write, send, and route email messages (1) --\ Debian (1) --\ unstable (1) --\ main The main Debian archive (1) --\ Priority optional (1) iu (pinofflineimap3 0 -4096 B 627 kB 0.0~git20210218.76c7a72+ 0.0~git20210225.1e7ef9e+ --\ python Python programming language and libraries (1) --\ Debian (1) --\ unstable (1) --\ main The main Debian archive (1)
[Aptitude-devel] Bug#982716: Bug#982716: aptitude: FTBFS: tests failed
Hi David,
Axel Beckert wrote:
> > So I guess what is intended here is more like:
> > | char * endptr;
> > | errno = 0;
> > | auto score_tweaks = strtol(action.c_str(), , 10);
> > | if (errno != 0 || *endptr != '\0')
>
> I applied the following patch locally:
>
> --- a/src/generic/apt/aptitude_resolver.cc
> +++ b/src/generic/apt/aptitude_resolver.cc
> @@ -673,7 +673,10 @@
>else
> {
>unsigned long score_tweak = 0;
> - if(!StrToNum(action.c_str(), score_tweak, action.size()))
> + char * endptr;
> + errno = 0;
> + auto score_tweaks = strtol(action.c_str(), , 10);
> + if (errno != 0 || *endptr != '\0')
> {
> // TRANSLATORS: actions ("approve", etc.) are keywords and should
> // not be translated
>
> The initially failing test indeed seems fixed, but now another test
> fails:
Thanks for the hint on being untested and written without copy &
paste. There was indeed a typo in there which was not detected by the
compiler: score_tweak vs score_tweaks (singular vs plural in variable
name). Fixing that and removing the leading "auto" variable
declaration seems the proper fix.
Thanks for the help nevertheless!
Will upload the fix soon.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#982763: aptitude-doc-en: Talks about "the non-free section" — which is not a section
Package: aptitude-doc-en Version: 0.8.13-2 Severity: minor Documenting quickly as I'm currently busy with other stuff (namely #982716) and I don't want that I forget about it: Citing from https://www.debian.org/doc/manuals/aptitude/ch02s03s05.en.html: > the target “?section(non-free)” will select any package in the > non-free section. There is no "non-free" section. "non-free" is a separate archive. Nevertheless the example itself is still correct as these packages do have "Section: non-free/$section" in their meta-data. But "the non-free section" is still wrong. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled aptitude-doc-en depends on no packages. aptitude-doc-en recommends no packages. Versions of packages aptitude-doc-en suggests: ii aptitude 0.8.13-2+b1 -- no debconf information ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#982716: Bug#982716: Bug#982716: aptitude: FTBFS: tests failed
Hi David,
David Kalnischkies wrote:
> On Sat, Feb 13, 2021 at 06:11:03PM +0100, Lucas Nussbaum wrote:
> > Relevant part (hopefully):
> […]
> > > FAIL: cppunit_test
> […]
> | aptitude_resolver.cc:680 ERROR - Invalid hint "-143 aptitude <4.3.0": the
> action "-143" should be "approve", "reject", or a number.
[…]
> So I guess what is intended here is more like:
> | char * endptr;
> | errno = 0;
> | auto score_tweaks = strtol(action.c_str(), , 10);
> | if (errno != 0 || *endptr != '\0')
I applied the following patch locally:
--- a/src/generic/apt/aptitude_resolver.cc
+++ b/src/generic/apt/aptitude_resolver.cc
@@ -673,7 +673,10 @@
else
{
unsigned long score_tweak = 0;
- if(!StrToNum(action.c_str(), score_tweak, action.size()))
+ char * endptr;
+ errno = 0;
+ auto score_tweaks = strtol(action.c_str(), , 10);
+ if (errno != 0 || *endptr != '\0')
{
// TRANSLATORS: actions ("approve", etc.) are keywords and should
// not be translated
The initially failing test indeed seems fixed, but now another test
fails:
Test Results:
Run: 199 Failures: 1 Errors: 0
1) test: ResolverHintsTest::testHintParse (F) line: 147
../../tests/test_resolver_hints.cc
assertion failed
- Expression: h == t.h
- Checking 40 g++: tweak 0 ?exact-name("g++") installed == tweak 40
?exact-name("g++") installed
Currently trying to understand why.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#982716: Bug#982716: Bug#982716: aptitude: FTBFS: tests failed
Hi David, you were quicker. Thanks! :-) David Kalnischkies wrote: > On Sat, Feb 13, 2021 at 06:11:03PM +0100, Lucas Nussbaum wrote: > > Relevant part (hopefully): > […] > > > FAIL: cppunit_test > […] > | aptitude_resolver.cc:680 ERROR - Invalid hint "-143 aptitude <4.3.0": the > action "-143" should be "approve", "reject", or a number. Yep, also found this to be the failing test and suspected apt 2.1.19/2.1.20 as the culprit. Especially "Forbid negative values in unsigned StrToNum explicitly" of 2.1.19 looked suspiciously related. ;-) > The test uses aptitude_resolver::hint::parse in > src/generic/apt/aptitude_resolver.cc > which in line 676 uses StrToNum to parse the hint which fails with > apt >= 2.1.19 as StrToNum is refusing to parse negative numbers now. > > The data type of StrToNum is unsigned and using strtoull internally > which works on an unsigned long long (ull), too, but defines that > for negative numbers "the negation of the result of the conversion" is > returned… which tends to be unexpected (Negative numbers played a minor > role in e.g. CVE-2020-27350 for example). […] > So I guess what is intended here is more like: > | char * endptr; > | errno = 0; > | auto score_tweaks = strtol(action.c_str(), , 10); > | if (errno != 0 || *endptr != '\0') Will test, thanks! > Note that I have not checked my hypotheses. (The code samples are also > typed in my mail client, so I have probably included some typos letting > them not even compile.) I'm glad about your reply definitely. > Sorry for this breaking change this late in the cycle! Apology accepted. :-) > If its any consolation I am also angry that I not only not managed > to finish the fuzzing project in time, but also not managed to > salvage the more useful bit in a more timely fashion either. Actually, when I read that changelog summary, I just thought "Wow!" So please please keep on that work! Better late than never! :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#982716: Bug#982716: aptitude: FTBFS: tests failed
Control: tag -1 + confirm Hi Lucas, thanks for the bug report! Lucas Nussbaum wrote: > Source: aptitude > Version: 0.8.13-2 > Severity: serious […] > During a rebuild of all packages in sid, your package failed to build > on amd64. Indeed, can reproduce it here locally despite it still worked a few weeks ago. Wouldn't have expected this at this stage of the freeze. :-/ Wonder who^Wwhat broke that. Anyway, will investigate. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#982272: Bug#982272: Bug#982272: Grammar of "xx packages upgraded..."
Hi David, David Kalnischkies wrote: > On Mon, Feb 08, 2021 at 09:19:49AM +0800, 積丹尼 Dan Jacobson wrote: > > Or even more accurate, instead, AA should be "to upgrade", BB "to newly > > install", and DD "to upgrade". > ^^ ^^ [...] > all the while not changing it in the middle of the freeze either. [...] > I doubt that is on the agenda all to soon. Very much not going to happen > in freeze at least. Please calm down. :-) Dan reported it as "minor" and not as "important". And that's what it is: minor. I do not expect that he expected us to fix that immediately. So yes, we will have a look at and maybe fix it — eventually. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#963790: Bug#963790: Bug#963790: aptitude: crashes on arm64
Control: tags -1 + moreinfo unreproducible Hi Mikulas, Axel Beckert wrote: > Will also try to setup an arm64 unstable on a Raspberry Pi and see if > I can reproduce this. Used aptitude on a Raspberry Pi 4 with arm64 for several weeks now without a single crash. Do you still experience this issue? If so, can you provide a state bundle created with aptitude-create-state-bundle so that I can try to see if I can reproduce it that way on my Raspberry Pi? Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#980035: Bug#980035: aptitude: segmentation fault when starting aptitude
Control: clone -1 -2
Control: retitle -2 aptitude-run-state-bundle: uses some local files instead of
only those from the bundle
Control: tag -2 - security
Control: tag -1 + moreinfo
Control: severity -2 normal
Hi Vincent,
Vincent Lefevre wrote:
> 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", {st_mode=S_IFREG|0644, st_size=3777850,
> ...}) = 0
> 2300081 openat(AT_FDCWD, "/var/lib/dpkg/arch", O_RDONLY) = -1 ENOENT (No such
> file or directory)
> 2300082 openat(AT_FDCWD, "/var/lib/dpkg/arch", O_RDONLY) = -1 ENOENT (No such
> file or directory)
> 2300083 openat(AT_FDCWD, "/var/lib/dpkg/arch", O_RDONLY) = -1 ENOENT (No such
> file or directory)
> 2300077 stat("/var/lib/apt-xapian-index/index", {st_mode=S_IFREG|0644,
> st_size=41, ...}) = 0
> 2300077 openat(AT_FDCWD, "/var/lib/apt-xapian-index/index", O_RDONLY) = 36
> 2300077 openat(AT_FDCWD, "/var/lib/aptitude//pkgstates", O_RDONLY) =
> 36
Yep, and the later seems to have bitten me a bit when testing the
bundle. At least chromium had no more forbidden version afterwards
which was unexpected.
Then again, /var/lib/aptitude//pkgstates is in your bundle as
.//var/lib/aptitude/pkgstates, so there's no reason for a fall-back or
so.
> 2300077 openat(AT_FDCWD, "/var/lib/debtags/package-tags", O_RDONLY) = -1
> ENOENT (No such file or directory)
> 222 symlinkat("/var/local/apt/./Packages", 4,
> ".//var/lib/apt/lists/_var_local_apt_._Packages") = 0
>
> while most files are read from the /tmp version.
>
> So, as this seems to depend on the system, this is not surprising.
Ack.
> > But as mentioned in #980037 this seems normal in such a case without
> > a special kernel. So thanks for the bug report!
>
> Note that I do *not* have a special kernel.
I know. That's the reason why I mentioned this.
> So this is unrelated.
Not necessarily. It's possible. But IMHO unlikely.
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?
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#980035: Bug#980035: Bug#980035: aptitude: segmentation fault when starting aptitude
Hi,
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 reads some other files from
> /var/lib according to strace. And now I get
>
> --- Upgradable Packages (65)
>
> instead of
>
> --- Upgradable Packages (61)
>
> Since the crashes are very sensitive to the system status, the
> above test might not be reliable.
Ack. That's now https://bugs.debian.org/980053 :-)
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#980035: Bug#980035: Bug#980035: aptitude: segmentation fault when starting aptitude
Control: clone -1 -2
Control: retile -2 aptitude-create-state-bundle should include more files from
file:/// URLs
Control: severity -2 minor
Control: submitter -2 Axel Beckert
Control: tag -2 - security
Hi Julian and Vincent,
Julian Andres Klode wrote:
> > 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.
H, works still fine for me so far with 2.1.17.
> > I suppose that it doesn't like some data that have been fetched.
> > Tagging security for this reason.
>
> Smells like 980037?
Yep, smells like something which came in with apt 2.1.17.
> Bug in APT's cache building upon mremap() in new code path in
> 2.1.16/17.
I'd rather guess 2.1.17 only given the time of the bug report.
Then again, I so far didn't run into it, neither with "aptitude -u"
(as I usually do on several boxes several times per day) nor with
pressing "u" inside the TUI.
Vincent: Got the bundle, thanks! Wasn't able to provoke a segfault
with it, even not after pressing "u". But as mentioned in #980037 this
seems normal in such a case without a special kernel. So thanks for
the bug report!
Then again, it argued about some missing files. Seems as if
aptitude-create-state-bundle should copy way more files when handling
file:/// URLs:
# aptitude-run-state-bundle ~abe/aptitude/aptitude-segv-#980035.bundle aptitude
update
[…]
Get: 33 file:/var/local/apt ./ Packages
Err file:/var/local/apt ./ Packages
File not found - /var/local/apt/./Packages (2: No such file or directory)
Get: 34 file:/var/local/apt ./ Translation-en
[…]
Fetched 87.9 MB in 10s (8426 kB/s)
W: Download is performed unsandboxed as root as file
'/tmp/aptitudebug.9E6xy9EY0/var/lib/apt/lists/partial/ftp.fr.debian.org_debian_dists_stable_InRelease'
couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
E: Failed to download some files
[…]
W: Failed to fetch file:/var/local/apt/./Packages: File not found -
/var/local/apt/./Packages (2: No such file or directory)
E: Some index files failed to download. They have been ignored, or old ones
used instead.
Created a new bug report for that.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#979186: Bug#979186: Bug#979186: aptitude: in the TUI, "+" changes the version of some packages in an inconsistent way
Control: tag -1 - moreinfo
Hi Vincent,
Vincent Lefevre wrote:
> 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:
Thanks! Fetched it.
> > Oh, and what is your setting of aptitude::Auto-Install (aka
> > "Automatically resolve dependencies of a package when it is selected")
> > and maybe other settings which might play a role here?
>
> My only settings concerning aptitude:
>
> Aptitude::UI::Package-Display-Format "%c%a%M %p %Z %24v %24V";
>
> Aptitude::UI::Styles {
> // Add bold to avoid a readability issue.
> SolutionActionApproved { fg white; bg green; set bold; };
> };
These shouldn't be relevant.
> Aptitude::ProblemResolver::SolutionCost "safety, removals";
That might play in here, thanks!
> > Do you have any special /etc/apt/preferences* settings which might
> > play a role here, too?
>
> Only:
[…]
> Package: flashplugin-nonfree:any
Probably not relevant either.
Will have a closer look later, earliest this evening.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#979186: Bug#979186: aptitude: in the TUI, "+" changes the version of some packages in an inconsistent way
Control: tag -1 + unreproducible moreinfo Hi Vincent, thanks for the very detailed bug report. Vincent Lefevre wrote: > After starting aptitude, I type "[" over "Upgradable Packages" and > get: > > [...] > --\ libs Collections of software routines (9) > --\ main The main Debian archive (9) > i A gvfs 1.46.1-1 1.46.1-2 > > i A gvfs-daemons 1.46.1-1 1.46.1-2 > i A gvfs-libs 1.46.1-1 1.46.1-2 > [...] > > Then I type "+" over "gvfs". I get: > > [...] > --\ libs Collections of software routines (9) > --\ main The main Debian archive (9) > iBA gvfs +1024 B 1.46.1-1 1.46.1-2 > i A gvfs-daemons 1.46.1-1 1.46.1-1 > i A gvfs-libs 1.46.1-1 1.46.1-1 > [...] > userspace virtual filesystem - GIO module > Some dependencies of gvfs (broken, 1.46.1-1) are not satisfied: > ▒ > > ▒ > * gvfs (upgrade, 1.46.1-1 -> 1.46.1-2) depends on gvfs-common (= 1.46.1-2) > ▒ > [UNAVAILABLE] > ▒ > * gvfs (upgrade, 1.46.1-1 -> 1.46.1-2) depends on gvfs-daemons (>= > 1.46.1-2) ▒ > * gvfs (upgrade, 1.46.1-1 -> 1.46.1-2) depends on gvfs-libs (= 1.46.1-2) > ▒ > > Notice that the versions of gvfs-daemons and gvfs-libs in the last > column have changed from 1.46.1-2 to 1.46.1-1! > > Then when I type Ctrl-u to undo the last action, I get: > > [...] > --\ libs Collections of software routines (9) > --\ main The main Debian archive (9) > i A gvfs 1.46.1-1 1.46.1-2 > > i A gvfs-daemons 1.46.1-1 1.46.1-1 > i A gvfs-libs 1.46.1-1 1.46.1-1 > [...] > > The versions are still the changed ones. I agree that this behaviour is strange and I also believe that this happened to you. Unforunately I can't reproduce this here as it automatically upgrades gvfs-daemons and gvfs-libs here. It then reports gvfs-backends and gvfs-fuse as broken and (IMHO correctly) suggests to upgrade them, too. Can you do an aptitude-create-state-bundle either before (preferred) or after that situation and upload it somewhere? Oh, and what is your setting of aptitude::Auto-Install (aka "Automatically resolve dependencies of a package when it is selected") and maybe other settings which might play a role here? Tried it with both, on (see above) and off. But even in the latter case I can't reproduce this: iBA gvfs 5 +1024 B 408 kB 1.46.1-1 1.46.1-2 i A gvfs-common 03632 kB 1.46.1-1 1.46.1-2 i A gvfs-daemons 1561 kB 1.46.1-1 1.46.1-2 i A gvfs-libs 0471 kB 1.46.1-1 1.46.1-2 Do you have any special /etc/apt/preferences* settings which might play a role here, too? (All these questions should also be answered by providing a aptitude state bundle.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#978171: Bug#978171: Bug#978171: aptitude: FTBFS: pkgcachegen.h:32:10: fatal error: xxhash.h: No such file or directory
Hi Sven,
Sven Joachim wrote:
> > Looks like a missing dependency on libxxhash-dev on a first glance.
> >
> > Will check if that helps. (And I wonder where that one got lost.)
>
> It did not get lost, rather I suppose that the latest apt upload
> introduced this new include without adding a proper dependency on
> libxxhash-dev to libapt-pkg-dev.
That's what I meant with "got lost" more or less. Thanks!
So this should be fixed in src:apt then? (Cc'ing our deities. ;-)
Otherwise I'd do a 0.8.13-3 upload with that b-d added.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#978171: Bug#978171: aptitude: FTBFS: pkgcachegen.h:32:10: fatal error: xxhash.h: No such file or directory
Hi Lucas,
Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
Thanks for the bug report!
> > /usr/include/apt-pkg/pkgcachegen.h:32:10: fatal error: xxhash.h: No such
> > file or directory
> >32 | #include
> > | ^~
> > compilation terminated.
> > make[6]: *** [Makefile:582: apt.o] Error 1
Looks like a missing dependency on libxxhash-dev on a first glance.
Will check if that helps. (And I wonder where that one got lost.)
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#963667: Bug#963667: aptitude: Aptitude segmentation fault
Control: tag -1 + confirmed
Control: retitle -1 aptitude: segmentation fault if a file under
/etc/apt/preferences.d is not readable for the user running aptitude
Hi,
Bardot Jerome wrote:
> As user i did :
> aptitude search nouveau
This is not really much information and looking through the backtrace
is a bit like searching for a needle in the haystack.
Nevertheless, thanks to the hint by Gert, it helped to also pinpoint
the issue in your case (see below), so thanks for including it!
Gert Robben wrote:
> I have the same outcome, but I don't know if it's the same cause.
> Anyway, I found aptitude segfaults, when the active uid cannot read some
> file.
Thanks for that hint! That seems to be the cause of Jerome's segfault,
too, namely the file /etc/apt/preferences.d/99my-custom-repository:
stat("/etc/apt/preferences.d/99my-custom-repository", {st_mode=S_IFREG|0640,
st_size=317, ...}) = 0
openat(AT_FDCWD, "/etc/apt/preferences.d/99my-custom-repository",
O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 EACCES (Permission non accordée)
> $ su -c 'touch /etc/apt/preferences.d/test'
> $ aptitude search nouveau
> (works fine)
> $ su -c 'chmod -r /etc/apt/preferences.d/test'
I assume there is a "600" or "640" missing in that last line.
> Maybe you have the same problem?
It is.
> But I use stable, not testing.
Chances are high that this issue is in there for quite a while,
probably related to some API extensions of libapt* to expose better
error handling.
Anyway, I can now reproduce this here:
$ aptitude search nouveau
[1]16941 segmentation fault (core dumped) aptitude search nouveau
$
apt itself seems to catch this case and throws a warning:
$ apt search nouveau
Sorting... Done
Full Text Search... Done
bumblebee/unstable,testing 3.2.1-26 amd64
NVIDIA Optimus support for Linux
[…]
W: Unable to read /etc/apt/preferences.d/foobar - open (13: Permission denied)
$
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#867006: Bug#866974: Patch fixing 'Assertion "resman->resolver_exists()" failed.'
Hi Ahzo, Ahzo wrote: > # aptitude # select 'test-b' for installation, press g > Uncaught exception: ../../src/ui.cc:1549: void auto_fix_broken(): Assertion > "resman->resolver_exists()" failed. Bingo! There it is. Thanks again! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#867006: Patch fixing 'Assertion "resman->resolver_exists()" failed.'
Dear Ahzo, Ahzo wrote: > the failure can be reliably reproduced with both the CLI (fatal > exception) and the TUI (assertion failure) in a minimal chroot Thanks for that! This makes it way easier to analyse this. Worked fine. > Attached is a patch which fixes the problem by removing two checks > for !TargetVer() in the resolver code responsible for examining > Provides. Thanks even more for that! :-) Will test this and then likely apply both patches and do an update of aptitude. (Either an upstream release or an intermediate Debian upload with patches. Not sure yet.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#963545: Bug#963545: Bug#963545: aptitude-create-state-bundle can't deal with no $HOME/.aptitude present
Control: tag -1 + pending
Dear Jidanni,
Axel Beckert wrote:
> > But what's the big deal? Why can't the program proceed if it isn't
> > present?
>
> Because tar trips over it.
Actually, aptitude-create-state-bundle still exits with 0 and the file
is still generated. So it's a really, really minor and cosmetic issue.
> Passing --ignore-failed-read to tar should suffice.
Done that now in the master branch. It actually has no impact on the
resulting file. It just downgrades tar's output from "error" to
"warning".
It will be fixed in the next aptitude upstream release. This will
probably be 0.8.14. It is not fixed in the 0.8.13-2 package I just
uploaded with a patch to fix a FTBFS.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#963545: Bug#963545: aptitude-create-state-bundle can't deal with no $HOME/.aptitude present
Control: tag -1 + confirmed patch
Control: severity -1 minor
Dear Jidanni,
積丹尼 Dan Jacobson wrote:
> # aptitude-create-state-bundle /tmp/z
> tar: .//root/.aptitude: Cannot stat: No such file or directory
> tar: Exiting with failure status due to previous errors
>
> Well the man page says $HOME/.aptitude, which looks different than the
> above.
Not really. Depending on the user and the current working directory,
this is (and from my point of view also looks) the same.
> But what's the big deal? Why can't the program proceed if it isn't
> present?
Because tar trips over it.
Passing --ignore-failed-read to tar should suffice.
> Aptitude itself can still run, why not aptitude-create-state-bundle?
Because aptitude doesn't call tar.
> P.S., why not also grab a apt-config dump too?
Why should we? We already have that data by including /etc/apt/ in the
tar ball. Using "apt-config dump" whould just add completely
unnecessary complexity.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#509100: Processed: Re: Bug#966640: build-depends: debhelper-compat (= 13) cannot be satisfied
Control: severity -1 important
Hii Sam,
Sam Hartman wrote:
> Axel> Yeah, this is a long-standing and known issue in aptitude.
>
> I'd ask the aptitude developers to consider whether this issue should be
> reprioritized as important rather than normal.
Good point, thanks! Done herewith. (And Cc'ed to the master bug report
on this.)
> Last year, we decided that the recommended way to build most
> packages is to use debhelper. The recommended way to describe a
> debhelper compatibility level is a dependency of the form
>
> debhelper-compat (= 13)
Totally valid point.
> So, aptitude build-dep is not able to process build dependencies on
> the recommended way of describing Debian source packages.
>
> As more and more packages adopt this recommended approach aptitude
> build-dep is going to become more and more useless.
Ack.
> Even if you are not able to fix the problem promptly, would it be
> possible to detect detect that this situation is happening in the
> build-dep path and recommend using a different resolver?
Another potential not full-blown, but more suitable solution would be
let libapt's resolver translate and maybe even resolve the build-deps
into non-virtual packages and then continue with them as if they would
be the build-depedencies.
Only drawback I see so far: No possibility to interactively choose an
alternative resolution for virtual packages, if there's one.
Manuel: What do you think of this variant?
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#966640: Processed: Re: Bug#966640: build-depends: debhelper-compat (= 13) cannot be satisfied
Control: forcemerge 509100 -1 Hi, Debian Bug Tracking System wrote: > > reassign -1 aptitude > Bug #966640 [src:krb5] build-depends: debhelper-compat (= 13) cannot be > satisfied > Bug reassigned from package 'src:krb5' to 'aptitude'. Yeah, this is a long-standing and known issue in aptitude. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#950334: Bug#950334: aptitude: Help -> User's Manual contains special characters
Hi Diego,
Diego Escalante wrote:
> This is actually a broader bug and not related to specific locales.
Suspected that, yes. But then again, not in the way you noticed. (I
suspected ISO-Latin encoded chacracters in source code files, e.g.
French or German contributor names, not hardcoded encoding names…)
> The issue is that `src/ui.cc` defaults to transcoding the README files
> to ISO-8859-1, and since all the README files are already UTF-8, you get
> glitchy glyphs.
I guess I wasn't aware of that when coverting them after Lintian
warnings or so. At least I did that for many of my packages. Not sure
if I was the one who did it with aptitude, but chances are not that
low. ;-)
> I'm attaching a patch for this specific issue, but note that I have an
> open MR which includes this and a few more encoding related fixes:
> https://salsa.debian.org/apt-team/aptitude/-/merge_requests/10/commits
Thanks a lot!
Funnily
https://salsa.debian.org/apt-team/aptitude/-/merge_requests/10/diffs
doesn't really show the changes as it at least partially seems to
convert the encoding line by line. So both, old and especially new
look good. :-)
> Note also that I wasn't able to properly test this because of the
> current FTBFS in:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966875
Ack. Yeah, I'm aware of it. Building with gcc 9 instead of 10 should
work, in case you're curious to see if it flies. :-)
> But that said, this is merely a string replacement, shouldn't be
> problematic.
Ack, I think so, too.
I though think we should not merge it before that FTBFS is fixed.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#966875: Bug#966875: aptitude: FTBFS: ../../../../src/generic/views/download_progress.cc:49:11: error: no match for ‘operator<<’ (operand types are ‘std::ostream’ {aka ‘std::basic
CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::__shared_ptr<_Tp, _Lp>&)’ /usr/include/c++/10/cstddef:125:5: note: candidate: ‘template constexpr std::__byte_op_t<_IntegerType> std::operator<<(std::byte, _IntegerType)’ /usr/include/c++/10/string_view:622:5: note: candidate: ‘template std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, std::basic_string_view<_CharT, _Traits>)’ /usr/include/c++/10/system_error:262:5: note: candidate: ‘template std::basic_ostream<_CharT, _Traits>& std::operator<<(std::basic_ostream<_CharT, _Traits>&, const std::error_code&)’ Admittedly my C++ knowledge doesn't go deep enough to understand where I might put these. Hopefully Manuel or someone else can chime in. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#966488: Bug#966488: aptitude corrupts package install selection after dpkg error
Control: severity -1 important
Dear Vincent,
Vincent Lefevre wrote:
> Severity: grave
> Justification: causes non-serious data loss
while I agree that this is "data loss" and that it's anything but
"serious" (and serious is less than grave btw. ;-), I disagree that
this validates the "grave" severity. IMHO it's at most "minor
data-loss". Hence downgrading the severity to important. (My gut
feeling would even say this is "normal" at most.)
Besides that, aptitude for quite a long time, like decades, has the
issue that it saves not all details of actions, e.g. it does only save
that you want to upgrade, but not to which version. Not sure what
happens if that version has a lower preference, it might even ignore
it as it can't find a version to upgrade to with higher preference.
Also not sure if there's even a bug report for that.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#963790: Bug#963790: aptitude: crashes on arm64
Hi Mikulas, Mikulas Patocka wrote: > > Wonder if this should be reassigned to the kernel then. Any chance > > that you find evidence in this by other similar (maybe other curses or > > slang?) applications crashing, too. > > The crash happens in the libcwidget library I feared that. > and aptitude is the only package that uses it. Ack. It was written for aptitude and no other software adopted it. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#963790: Bug#963790: aptitude: crashes on arm64
Hi Mikulas,
Mikulas Patocka wrote:
> > > Aptitude crashes on arm64. If I ress 'q' and quit aptitude, I get a crash.
> > > If I press 'g' to let aptitude do some work, I get a crash.
> >
> > Hmmm, I assume this is reproducible on your machine?
>
> Yes - it is 100% reproducible.
Thanks!
> I've found out that the crash only happens with the kernel 5.8-rc.
> Aptitude works on 5.7.
Okay… O.o
Wonder if this should be reassigned to the kernel then. Any chance
that you find evidence in this by other similar (maybe other curses or
slang?) applications crashing, too.
> So, it may be bug in the kernel and not aptitude. I
> bisected it, and it is caused by the kernel commit
> d27865279f12035c730818aa1a0280fada866a37.
This seems to be an arm64-only commit, so I assume this is really
arm64-specific.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#963790: Bug#963790: aptitude: crashes on arm64
Hi Mikulas, thanks for the bug report Mikulas Patocka wrote: > Aptitude crashes on arm64. If I ress 'q' and quit aptitude, I get a crash. > If I press 'g' to let aptitude do some work, I get a crash. Hmmm, I assume this is reproducible on your machine? I recently got a crash on i386, but IIRC not during pressing any keys but during dependency resolution and on a box with just 1 GB of RAM. Expected it to be a OOM issue because of that. Will keep an eye on this on those architectures I use daily. Will also try to setup an arm64 unstable on a Raspberry Pi and see if I can reproduce this. > This is the stacktrace of the crash: Thanks for these details. P.S.: I updated the bug title, just "aptitude" is not that much helpful. ;-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#963716: Bug#963716: Dependency resolution led to additional problem requiring further dependency resolution
Control: tag -1 + confirmed Hi Josh, Josh Triplett wrote: > When trying to upgrade current unstable, I encountered a dependency > resolution issue I've never seen in aptitude before. Because "chromium > conflicts with libavcodec58 (= 7:4.3-2)", aptitude suggested the > solution of removing libavcodec58 and installing libavcodec-extra58. > However, accepting that solution (pressing '!') then introduced new > problems, where libavcodec-extra58's dependencies weren't satisfied. Indeed, I ran into this, too with chromium and libavcodec58, too. Don't remember all the details anymore, though. > Accepting *that* solution by pressing '!' again turned up the problem > that "chromium (upgrade, 81.0.4044.92-1 -> 83.0.4103.116-1) conflicts > with libavcodec58 (= 7:4.3-2) (provided by libavcodec-extra58 7:4.3-2)". I didn't notice that this goes further recursively as I intervened and solved this myself. And since it so far only surfaced one single time, I didn't think much about it. But the way you describe it sounds more severe than I expected. It also shows that this wasn't just a one-time issue showing up on only my system. > It seems like aptitude wasn't actually evaluating the consequences of > its proposed dependency resolutions to ensure they reached a valid > dependency state. Ack. This is though probably nothing new and only surfaced through the current situation around chromium and ffmpeg where (dependency-wise) you either can have ffmpeg from testing and chromium from unstable or vice versa. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#962926: Bug#962926: Images of aptitude screens are illegible due to being scaled to browser width
Control: tag -1 + unreproducible moreinfo patch Hi Joshua, thanks for the bug report. Joshua C. Lackey wrote: > All of the screenshots are illegible because a width="100%" property > is set in each tag, causing them to be stretched and introducing > significant aliasing. I can confirm that they are stretch to full width. > Resizing the browser window to a smaller size > does not help much. Due to the low resolution of the images (484x316) > and small size of the text, even minimal scaling causes blurring and > aliasing. I though unfortunately (or luckily, depending on the point of view ;-) can't reproduce this in Chromium from unstable. Even in fullscreen mode on a 1900x1200 screen, they're crisp, sharp and very readable for me, but of course also very pixely. Sounds like a potential browser bug to me. Scaled images should never be more blurry than unscaled images. They just should be more pixely. In which browser did you have that effect? Maybe you can make a screenshot of the issue, too. > The text, though small, is completely clear and legible when > the images are rendered at their native resolution. Same for me in any scaling, i.e. I can't reproduce this. :-/ > I suggest removing the width='100%' property from each of the the > tags in the DocBook XML source (/doc/en/aptitude.xml) or > adding an img selector in the CSS stylesheet (/doc/aptitude.css) with > a width:auto property, which will override the the HTML tags. While I do see that this at least would solve the issue described above, I'm reluctant to actually do this as it would introduce legibility issues on big screens with high resolutions for some people due to the (as you noted) rather small resolutions of the pictures. The only clean solution for this which comes to my mind, is to redo all the screenshots in some terminal with scalable fonts and do vectorised SVG screenshots, e.g. with gtk-vector-screenshot. Just tried this, but defacto, there's a PNG inside the SVG, at least when trying inside lxterminal or gnome-terminal. :-( Another idea is to use aha (https://github.com/theZiz/aha), but this is non-trivial with a TUI application and only usable in HTML, not in PDF, etc. We though could let them render in a browser and take a vector screenshot of that. If I do a "hardcopy" in screen and pipe that file through aha, the layout is fine, but it doesn't catch the ANSI colors. Piping the saved transcript of "script -c aptitude" through aha messes with the indentation, but keeps the colors. Best result (but still unusable) so far was with: $ printf '[qy\n' | aptitude | aha > aptitude.html But actually the "[" had no effect. asciinema might also be an option, too, but that's usually for videos not for pictures. But we could freeze a frame and take a vector screenshot then. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#934135: Bug#934135: aptitude: depends on libparse-debianchangelog-perl that has no upstream maintainer
Control: tag -1 + pending Hi again, Axel Beckert wrote: > Problem: It doesn't work for me, no more highlighting of new changelog > entries — which I is why I haven't pushed my changes yet. [...] > You need to test it on upgradable packages. (And check how > it looks without the patch first: All entries between the currently > installed version and the new version should be bold. Found out what missing: Guillem's patched Makefile.am and also debian/control, but missed debian/aptitude-common.install, so the upstream build-system installed the file, but the package build system did not. Works now for me. Can continue on preparing a new upstream release. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#934135: Bug#934135: aptitude: depends on libparse-debianchangelog-perl that has no upstream maintainer
Hi again, Axel Beckert wrote: > > > After some thought, I think a local aptitude-specific wrapper might be > > > even better and obviates the question of whether dpkg-parsechangelog > > > should be moved or not. :) > > > > FWIW, this makes sense to me. > > Ack, and I'm actually on it. Tried to incorporate it last weekend. > > Problem: It doesn't work for me, no more highlighting of new changelog > entries — which I is why I haven't pushed my changes yet. > > Maybe I should push them to a branch. Will do. Did that now. The commit by Guillem with my fixes is in https://salsa.debian.org/apt-team/aptitude/-/tree/debian-sid-test-upstream-patches I also started to prepare a new aptitude upstream release (but still without Guillem's patch — that's what the branch above is for) and pushed my other changes to the debian-sid branch. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
Re: [Aptitude-devel] Bug#934135: Bug#934135: aptitude: depends on libparse-debianchangelog-perl that has no upstream maintainer
Control: clone -1 -2 aptitude FTBFS with new po4a Control: reassign -2 src:aptitude 0.8.12-3 Control: severity -2 serious Control: tag -2 = ftbfs Hi, one more thing: intrigeri wrote: > I have applied Guillem's patch and fixed the typo mentioned below, on > top of current sid's 0.8.12-3 You also need to remove the hunk which modifies debian/control. Doing that from debian/patches is bad. > (after disabling the build of doc translations as this makes the > package FTBFS for me with current po4a; same on the Reproducible > Builds infra¹), Worked for me last weekend. But indeed, it FTBFS now. Hence documenting it. Will fix that, too. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#934135: Bug#934135: Bug#934135: aptitude: depends on libparse-debianchangelog-perl that has no upstream maintainer
Hi intrigeri, intrigeri wrote: > Guillem Jover (2019-08-09): > > After some thought, I think a local aptitude-specific wrapper might be > > even better and obviates the question of whether dpkg-parsechangelog > > should be moved or not. :) > > FWIW, this makes sense to me. Ack, and I'm actually on it. Tried to incorporate it last weekend. Problem: It doesn't work for me, no more highlighting of new changelog entries — which I is why I haven't pushed my changes yet. Maybe I should push them to a branch. Will do. > > See the attached patch, which has seen no testing, but can do that > > once and if it is deemed a good path forward. > > Thanks a lot! Yes. There's IIRC one typo in it, but without that fix, it IIRC doesn't even compile. > Dear Aptitude maintainers, FYI this is now the last remaining blocker > for the removal of libparse-debian-changelog-perl, so I'm trying > to facilitate the integration of Guillem's patch: > > I have applied Guillem's patch and fixed the typo mentioned below, on > top of current sid's 0.8.12-3 (after disabling the build of doc > translations as this makes the package FTBFS for me with current po4a; > same on the Reproducible Builds infra¹), and I did these tests: > > - `aptitude changelog apt` works Yes, but as far as I can see in this case, libparse-debianchangelog-perl seems not used at all, based on the behaviour with 0.8.12-3. :-) (Which might be a kind of missing feature, but is probably overkill, because it would bloat up what is done to accomplish that massively. :-) > - In the Aptitude UI I could view the changelog of both >installed and non-installed packages. Irrelevant. You need to test it on upgradable packages. (And check how it looks without the patch first: All entries between the currently installed version and the new version should be bold. > I'm not sure if any of those exercises the affected code path. > > I'm happy to do more tests if it helps fix this bug, but I would > need some guidance regarding what/how to test :) See above. > > -dist_bin_SCRIPTS = aptitude-create-state-bundle aptitude-run-state-bundle > > +dist_bin_SCRIPTS = apitude-changelog-parser \ > > + aptitude-create-state-bundle aptitude-run-state-bundle > > Typo: apitute-changelog-parser → aptitude-changelog-parser Ack. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#960562: Bug#960562: had to reinstall a package to avoid 'bullying'
aptitude configuration. (Also can be seen by the "p" in "{pu}" as that
indicates that Aptitude::Purge-Unused is being set.)
So my only explanation so far is that he has something in his aptitude
or apt configuration which makes fdisk marked as automatically
installed. Potential candidate for such a thing are
* APT::Move-Autobit-Sections::
* APT::AutoRemove::RecommendsImportant (when set to false)
* APT::AutoRemove::SuggestsImportant (when set to false)
* Aptitude::Keep-Recommends (when set to false)
* Aptitude::Keep-Suggests (when set to false)
I though was not able to find a combination of these and
Aptitude::Purge-Unused to provoke this behaviour either.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Thanks for the Team uploads
Hi Julian, sorry for not responding early, but it was a busy weekend for me. Planned to work on your bug this evening, but you were quicker. Seeing that it actually needed two uploads, I'm glad you looked at it closer. Thanks! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#953410: Bug#953410: question: get rid of "The following packages are RECOMMENDED but will NOT be installed"
Hi Martin,
Martin Monperrus wrote:
> > That would have been my first idea where to ask questions
>
> Me too :) I looked on https://lists.debian.org/completeindex.html,
Fair enough.
> where the list is not listed for some reason.
Yep, lists.debian.org is something different lists.alioth.debian.org:
* lists.debian.org are mailing lists officially maintained and run by
the Debian project.
* lists.alioth.debian.org (and its successor alioth-lists.debian.net
where the DNS entry points to nowadays) contains bascially lists,
any project member could create without any assistance or approval
from the Debian project's list masters, i.e. the lists hosted there
are "self-service" mailing lists. ("Alioth" previously was Debian's
self-service project hosting service. The mailing lists are what is
still left from this service.)
I must admit that this is anything but obvious, especially for people
not directly involved with Debian.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#953410: Bug#953410: question: get rid of "The following packages are RECOMMENDED but will NOT be installed"
Control: retitle -1 Option to suppres the "The following packages are
RECOMMENDED but will NOT be installed" message/list
Control: severity -1 wishlist
Hi Martin,
Martin Monperrus wrote:
> This is a question, not a bug report. I know that this channel may not be
> optimal, but I've exhausted the other alternatives.
You seem not to have written to the mailing list listed in the
Maintainer header of the aptitude package. That would have been my
first idea where to ask questions:
$ apt-cache show aptitude | fgrep Maintainer
Maintainer: Aptitude Development Team
> How to disable message "The following packages are RECOMMENDED but will NOT be
> installed" in aptitude?
I'm not aware of such an option and
https://www.debian.org/doc/manuals/aptitude/ch02s05s05.en.html doesn't
list anything in that direction either.
Taking this as feature request then, retitling the bug report and
setting the severity to wishlist.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#953402: aptitude: %i display format no more works, just displays "(pinning not available)"
Package: aptitude Version: 0.8.12-3 Severity: normal I use %i to show me in the aptitude package list which packages I have pinned and which not. Since at least 0.8.12-3 (maybe also 0.8.12-2, didn't check), i.e. the patches for APT 2.0 (or linking against APT 1.9/2.0) this no more works and even shows for pinned packages just "(pinning not available)". Example setting from /root/.aptitude/config: aptitude::UI::Package-Display-Format "%c%a%M%Si %p %r %9Z %8I %15v# %15V#"; Not sure if this is related to 1.9.11's * policy: Implement pinning by source package (Closes: #166032) as this seems to have no direct relation as just potentially affecting source packages. But maybe this caused some unintended collateral damage? Julian: Can you please comment if this is a expected change which requires changes in aptitude or some unintended changes which needs fixing in apt? (And if the latter is the case, maybe reassigning the bug report and setting a proper "affects". TIA! :-) -- Package-specific info: Terminal: eterm-color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.12 Compiler: g++ 9.2.1 20200224 Compiled against: apt version 6.0.0 NCurses version 6.2 libsigc++ version: 2.10.2 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.2.20200212 cwidget version: 0.5.18 Apt version: 6.0.0 aptitude linkage: linux-vdso.so.1 (0x7fffe1f49000) libapt-pkg.so.6.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0 (0x7f6e6df23000) libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x7f6e6dee8000) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x7f6e6deb9000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f6e6deb) libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4 (0x7f6e6ddaa000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f6e6dc8) libboost_iostreams.so.1.67.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7f6e6dc6) libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x7f6e6da46000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f6e6da25000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f6e6d858000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f6e6d713000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f6e6d6f9000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f6e6d537000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f6e6d51f000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f6e6d502000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f6e6d4ef000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f6e6d4c6000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f6e6d4a4000) libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x7f6e6d3f8000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f6e6d3cd000) libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x7f6e6d336000) libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 (0x7f6e6d219000) /lib64/ld-linux-x86-64.so.2 (0x7f6e6e5aa000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f6e6d214000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f6e6d207000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f6e6d1fe000) libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7f6e6d1f5000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7f6e6d1d2000) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages aptitude depends on: ii aptitude-common 0.8.12-3 ii libapt-pkg6.0 2.0.0 ii libboost-iostreams1.67.0 1.67.0-17 ii libc6 2.29-10 ii libcwidget4 0.5.18-5 ii libgcc-s1 10-20200304-1 ii libncursesw6 6.2-1 ii libsigc++-2.0-0v5 2.10.2-1 ii libsqlite3-0 3.31.1-4 ii libstdc++610-20200304-1 ii libtinfo6 6.2-1 ii libxapian30 1.4.14-2 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl 1.2.0-13 ii
Re: [Aptitude-devel] Version number matching question
Hi Jonas, Jonas Bechtel wrote: > I've got a question: I try to update evince-common, which is not possible > because it breaks the evince package. > Aptitude then looks like this: > > Origin URI: > http://security.debian.org/pool/updates/main/e/evince/evince_3.30.2-3+deb10u1_i386.deb From the version number I gather you're having this issue on Debian 10 Buster. Seeing i386 packages: Is this a multi-arch system, i.e. does it use i386 and amd64 packages or just i386 packages? I only have Buster amd64 here, so might not see exactly the same package relations. > --\ Depends (19) > --- dconf-gsettings-backend | gsettings-backend > --\ evince-common:all (< 3.31) (UNSATISFIED) > idA evince-common 3.30.2-3 > -11.0 MB > --\ evince-common:all (>= 3.30) (UNSATISFIED) > idA evince-common 3.30.2-3 > -11.0 MB > > > The installation overview looks like this: > > --\ Packages with unsatisfied dependencies (1) > iB evince:i386 > 3.30.2-3+deb10 3.30.2-3+deb10 > --\ Packages to be upgraded (1) > iuA evince-common > 3.30.2-3 3.30.2-3+deb10 > --\ Packages being held back (969) Looks like it won't update evince-common for some reason. Do you happen to have apt-listbugs installed? It might pin packages to older versions due to bugs so they aren't upgraded. > Some dependencies of evince:i386 (broken, 3.30.2-3+deb10u1) are not > satisfied:▒ > > ▒ > * evince:i386 (held/unchanged, 3.30.2-3+deb10u1) depends on > evince-common:all (< 3.31) (provided by ▒ > evince-common 3.30.2-3) > ▒ > > So the question here is: why is > > 3.30 <= 3.30.2-3 < 3.31 > but not > 3.30 <= 3.30.2-3+deb10 < 3.31 ? I suspect another issue here as 3.30 <= 3.30.2-3+deb10 < 3.31 is true, too, and also worked for me on Buster (but amd64). Can you please run "aptitude-create-state-bundle evince.tbz2" on that system after having exited aptitude with "q" (so that the current state is saved). It will put all files relevant to reproduce this issue (package lists, package states, aptitude settings, etc.) into a bzip2 compressed tar archive given as parameter. It might become something between 20 and 200 MB, so it's usually not suitable for transfering by e-mail. Uploading it somewhere and telling us (or just me if you don't want the link published in a public list archive) the link to it. > Institut für Bahntechnik We might have some common acquaintances... :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
Re: [Aptitude-devel] how to get verbosity in aptitude command-line mode via its configuration file.
Hi shirish, shirish शिरीष wrote: > While I'm asking the same question at > https://unix.stackexchange.com/questions/555993/verbosity-in-aptitude-command-line-mode > > just for completeness asking the same here too - Thanks! I replied there: https://unix.stackexchange.com/a/556303 TL;DR: I can't reproduce this. For me, there is a difference of one additional line—from Debian 8 Jessie up to Debian Sid. I though found a related bug while doing so, reported at https://bugs.debian.org/946458 Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#946458: aptitude: "aptitude -o Aptitude::CmdLine::Verbose= " with = 1 or higher is never verbose
Package: aptitude Version: 0.8.12-1 Severity: minor Control: found -1 0.8.11-7 Control: found -1 0.8.7-1 Control: found -1 0.6.11-1 This is more or less the findings from the comments of https://unix.stackexchange.com/a/556038 and my answer at https://unix.stackexchange.com/a/556303: While "aptitude -v moo" to "aptitude -vv moo" works as expected and—as Stephen Kitt (X-Debbugs-Cc'ed) mentioned—also setting "Aptitude::CmdLine::Verbose" in the config file works, e.g. "aptitude -o Aptitude::CmdLine::Verbose=6 moo" (nor any other value I tried, e.g. 2 or 5) works as if not a single "-v" has been specified, i.e. seems to be ignored. Since many other combinations of "aptitude -o " work fine (I use them daily in aliases), and "aptitude -o Aptitude::CmdLine::Verbose=2 update" is not as verbose as "aptitude -v update" is (see https://unix.stackexchange.com/a/556303), I suspect there is a bug in parsing specifically the "Aptitude::CmdLine::Verbose" option when given on the commandline via "-o". -- Package-specific info: Terminal: eterm-color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.12 Compiler: g++ 9.2.1 20190821 Compiled against: apt version 5.0.2 NCurses version 6.1 libsigc++ version: 2.10.1 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.1.20191019 cwidget version: 0.5.18 Apt version: 5.0.2 aptitude linkage: linux-vdso.so.1 (0x7fff31f9e000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7fb88a38b000) libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x7fb88a35) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x7fb88a321000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7fb88a318000) libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4 (0x7fb88a212000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fb88a0ed000) libboost_iostreams.so.1.67.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7fb88a0cd000) libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x7fb889eb4000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fb889e93000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fb889cba000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fb889b75000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fb889b5b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb88000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fb889981000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fb889964000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7fb889951000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fb889928000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7fb889906000) libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x7fb88985a000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7fb88982f000) libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x7fb889798000) /lib64/ld-linux-x86-64.so.2 (0x7fb88aa25000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fb889793000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fb889788000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fb88977d000) libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7fb889775000) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages aptitude depends on: ii aptitude-common 0.8.12-1 ii libapt-pkg5.0 1.8.4 ii libboost-iostreams1.67.0 1.67.0-15 ii libc6 2.29-3 ii libcwidget4 0.5.18-5 ii libgcc1 1:9.2.1-21 ii libncursesw6 6.1+20191019-1 ii libsigc++-2.0-0v5 2.10.2-1 ii libsqlite3-0 3.30.1-1 ii libstdc++69.2.1-21 ii libtinfo6 6.1+20191019-1 ii libxapian30 1.4.12-1 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl 1.2.0-13 ii sensible-utils 0.0.12+nmu1 Versions of packages aptitude suggests: ii apt-xapian-index0.50 ii aptitude-doc-en [aptitude-doc]
[Aptitude-devel] Bug#939023: Bug#939023: More details
Hi Nikolaus, Nikolaus Rath wrote: > Maybe it's related to the amount of packages scheduled for removal? Some more > experiments: > > # aptitude purge --schedule-only '~i ~pextra' > (works) > > # aptitude purge --schedule-only '~i ~poptional' > [ ERR] Writing extended state information Thanks for that detail! That likely helps to track this down. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#935615: Bug#935615: aptitude: FTBFS on amd64
Hi Manuel, Ivo De Decker wrote: > A binnmu of aptitude in unstable fails on amd64: > > https://buildd.debian.org/status/package.php?p=aptitude Do you happen to know if any of your recent commits to the master branch already fixes this issue? I haven't found any which looks fitting on a first glance... If you can pinpoint one or more commits, I can cherry pick them and do a quick upload to fix this issue. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#934367: Bug#934367: group binary packages by source package
Hi,
Sven Joachim wrote:
> > Probably its difficult to implement, but what I am *really*
> > missing in aptitude is a list of source packages. If I press
> > '[' it should expand to list all its binary packages to
> > chose from.
>
> That is already there: Views → New Source Package View :-)
Thanks! But it's admittedly rather well hidden. So hidden that even I
forgot about that view. :-)
If I recall correctly, the abandoned 0.6.9 branch had a feature where
you can select the "Source Package" line in a binary package view and
then press Enter on it ("[" would be another, probably more helpful
option) and then you got a list of all binary packages from that
source package.
Maybe we can ressurrect that feature from the 0.6.9 branch — in case
my recollection is correct.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#934379: aptitude: Mouse scroll-wheel does not work in changelog view
Package: aptitude Version: 0.8.11-7 Severity: minor Hi, I just noticed that while the scroll-wheel works in the package list view, it doesn't work after having pressed C to view the changelog of a package. This would be especially useful for packages with large changelog entries like the kernel images. -- Package-specific info: Terminal: eterm-color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.11 Compiler: g++ 8.2.0 Compiled against: apt version 5.0.2 NCurses version 6.1 libsigc++ version: 2.10.1 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.1.20190803 cwidget version: 0.5.17 Apt version: 5.0.2 aptitude linkage: linux-vdso.so.1 (0x7ffc63752000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7f12966ca000) libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x7f129668f000) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x7f129665f000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f1296656000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7f129655) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f129642c000) libboost_iostreams.so.1.67.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7f129640c000) libboost_system.so.1.67.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f1296405000) libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x7f12961d9000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f12961b8000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f1295fe) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f1295e5d000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f1295e41000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f1295c8) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f1295c66000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f1295c49000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f1295c36000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f1295c0e000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f1295bed000) libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x7f1295b4d000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f1295b27000) libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 (0x7f1295a9) /lib64/ld-linux-x86-64.so.2 (0x7f1296d43000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f1295a8b000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f1295a7f000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f1295a76000) libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7f1295a6e000) -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages aptitude depends on: ii aptitude-common 0.8.11-7 ii libapt-pkg5.0 1.8.2 ii libboost-iostreams1.67.0 1.67.0-13 ii libboost-system1.67.0 1.67.0-13 ii libc6 2.28-10 ii libcwidget3v5 0.5.17-11 ii libgcc1 1:9.1.0-10 ii libncursesw6 6.1+20190803-1 ii libsigc++-2.0-0v5 2.10.1-2 ii libsqlite3-0 3.29.0-1 ii libstdc++69.1.0-10 ii libtinfo6 6.1+20190803-1 ii libxapian30 1.4.11-1 Versions of packages aptitude recommends: ii libparse-debianchangelog-perl 1.2.0-13 ii sensible-utils 0.0.12 Versions of packages aptitude suggests: ii apt-xapian-index0.50 ii aptitude-doc-en [aptitude-doc] 0.8.11-7 ii debtags 2.1.5 ii tasksel 3.54 -- no debconf information ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#934135: Bug#934135: aptitude: depends on libparse-debianchangelog-perl that has no upstream maintainer
Hi Guillem,
Guillem Jover wrote:
> aptitude Recommends libparse-debianchangelog-perl, which has had no
> upstream maintainer since 2011.
Yes, I've asked Frank if he'd pass over upstream to someone else. No
response so far IIRC.
> I'm attaching an old patch I had around, which I thought I had sent
> out, but apparently not (perhaps only on IRC), to switch to
> libdpkg-perl's parser which is the successor of this package.
Yay, thanks! I really didn't want to go back to dpkg-parsechangelog
which would pull in whole dpkg-dev.
Looks fine on a first glance. I though nowadays would probably replace
"-e" with "-E". But that's details.
But seeq also my reply to your mail in the thread of
https://bugs.debian.org/933128 — waiting for a reply there before
continuing here...
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#931913: Bug#931913: aptitude: The certificate is NOT trusted when using https to fetch packages from security.debian.org in buster
Hi J.L., J. L. Lee wrote: > In this case, Debian Wiki page on SourcesList > (https://wiki.debian.org/SourcesList) needs to be rephrased slightly. Thanks for this hint! Done now: https://wiki.debian.org/SourcesList?action=diff=88=89 Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#931718: Bug#931718: new packages list forgets about old packages
Control: tag -1 - moreinfo unreproducible + confirmed
Hi Matus,
Matus UHLAR - fantomas wrote:
> On 09.07.19 18:05, Axel Beckert wrote:
> > I assume you did not exit aptitude inbetween, right
>
> I did. What I did was:
Ok, exiting aptitude inbetween is what I usually do, too.
> 2. change sources.list to point to buster archive.
>
> # rm sources.list; ln -s sources.list.buster sources.list
I don't think that using a symlink instead of editing the file makes a
difference.
> 3. run aptitude, see only installed packages marked as obsolete:
>
> --- Obsolete and Locally Created Packages (3978)
[...]
> 4. run 'u'pdate packages list, see no old packages, but all uninstalled as
> new:
Gotcha! Doing this in two instead of one step is is the relevant
difference and cause for this issue.
I usually use "aptitude -u" instead here, which updates the package
lists before calculating any view and then there's no problem either.
(Also speeds things up as the view needs to be built only once. :-)
So as soon as you generate a new view with all packages obsolete, it's
clear that afterwards, all other packages are new.
I suspect that this is caused by some subtle change in how libapt sees
its cache if the sources.list has been modified after the last package
list update".
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#931718: Bug#931718: new packages list forgets about old packages
Control: tag -1 + moreinfo unreproducible Hi Matus, thanks for the bug report. Matus UHLAR - fantomas wrote: > I am trying to look which packages are new in buster that were not in > stretch. I am using aptitude since it't great tool for browsing packages. > > until now it was easy: > > do 'f'orget new packages in aptitude > change sources.list to point to new release > do 'u'pdate packages list I assume you did not exit aptitude inbetween, right > but now, when I do this, aptitude seems to forget all info about packages > previously available. So every package is listed under "New Packages"? I can't reproduce this. I just did the following inside an uptodate Stretch pbuilder chroot: * Start "aptitude" It shows this view: --- Actions Undo Package Resolver Search Options Views Help C-T: Menu ?: Help q: Quit u: Update g: Preview/Download/Install/Remove Pkgs aptitude 0.8.7 @ c6 --- Installed Packages (128) --- Not Installed Packages (50663) --- Virtual Packages (5897) These packages are currently installed on your computer. ▒ ▒ This group contains 128 packages. ▒ --- * Press Ctrl-Z * Edit /etc/apt/sources.list and change any occurrence of "stretch" to "buster". * Called "fg" to get aptitude into the foreground again. * Pressed "u" in aptitude's TUI. Now aptitude shows me this view: --- Actions Undo Package Resolver Search Options Views Help C-T: Menu ?: Help q: Quit u: Update g: Preview/Download/Install/Remove Pkgs aptitude 0.8.7 @ c6 --- Upgradable Packages (111) --- New Packages (13184) --- Installed Packages (2) --- Not Installed Packages (43508) --- Obsolete and Locally Created Packages (15) --- Virtual Packages (14460) A newer version of these packages is available. ▒ ▒ This group contains 111 packages. ▒ --- Which is more or less what I would expect: * 13184 new binary packages (You should get the same number on amd64 unless you also have contrib/non-free or third-party repos enabled.) * 111 of the 128 installed packages of the minimal chroot are updatable. * 2 are unchanged between stretch and buster. * 15 are no more in buster. Maybe you can post even more verbose steps how to reproduce this. Otherwise I have no idea what could be different with your setup to cause such a different behaviour. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#867006: Bug#867006: aptitude crashes with Uncaught exception: ../../src/ui.cc:1548: void auto_fix_broken(): Assertion "resman->resolver_exists()" failed.
Control: found -1 0.8.11-7
Hi again,
Axel Beckert wrote:
> Sven Joachim wrote:
> > On 2017-07-03 08:14 -0300, Thadeu Lima de Souza Cascardo wrote:
> > > While browsing around the view and marking packages for upgrade,
> > > aptitude crashed with the following exception:
> > >
> > > Uncaught exception: ../../src/ui.cc:1548: void auto_fix_broken():
> > > Assertion "resman->resolver_exists()" failed.
> >
> > This seems to be the same problem as #866974. Do you have
> > libcpan-meta-perl installed?
>
> Not sure if it's really the same problem as in Sven's #866974 case
> (which I can reproduce in the TUI and on the commandline) there was no
> hard exiting (I wouldn't call it crash, but that's nitpicking) due to
> a Assertion being not true. Hence not merging for the moment.
Ran into the same issue as #867006 during a dist-upgrade from stretch
to buster, when upgrading nearly all perl packages (libraries,
Perl's binaries and binaries linked against libperl):
Uncaught exception: ../../src/ui.cc:1548: void auto_fix_broken(): Assertion
"resman->resolver_exists()" failed.
It though only happened on a single machine so far, despite it's my
tenth (or so) dist-upgrade from stretch to buster...
Initially it only happened if I pressed "g" in the preview, but after
saving the desired package state by quiting aptitude with "q" and then
starting it again, it immediately happens if I press "g" in the
initial TUI view.
I then tried to get a useful backtrace and installed all debug
packages via "apt install $(find-dbgsym-packages $(which aptitude))".
After that I still was able to reproduce the crash, but I noticed that
there was a dependency conflict:
perl-modules-5.28 breaks libparse-cpan-meta-perl provided by the
(in #866974 by Sven already suspected) libcpan-meta-perl.
Solving this conflict manually (which I'm quite but not 100% sure
hasn't been displayed before) also solved the crash.
Unfortunately as soon as I attach to aptitude with "gdb -p $pid",
aptitude no more seems to react on keyboard input. It though
immediately crashes once I detach gdb from it. :-(
Trying to get the crash on the commandline with "aptitude install"
fails (well, succeeds) as it properly handles the case:
# aptitude install
The following NEW packages will be installed:
libb-debug-perl{a} libcrypt-openssl-random-perl{a}
libdevel-callchecker-perl{a}
libdynaloader-functions-perl{a} libperl5.28{a} perl-modules-5.28{ab}
The following packages will be REMOVED:
libdata-random-perl{u} libextutils-pkgconfig-perl{pu} libgnome2-canvas-perl{a}
libgnome2-gconf-perl{a} libgnome2-perl{a} libgnome2-vfs-perl{a}
libgnome2-wnck-perl{a}
libgtk2-imageview-perl{a} libgtk2-unique-perl{a} libgtkimageview0{pu}
liblexical-sealrequirehints-perl{pu} libmagickcore-6.q16-3{pu}
libnet-dropbox-api-perl{pu}
libnet-oauth-perl{pu} libnfqueue-perl{ap} libproc-simple-perl{pu}
libunique-1.0-0{pu}
libx11-protocol-other-perl{pu} shutter{ap}
The following packages will be upgraded:
eperl finch irssi libacme-damn-perl libalgorithm-combinatorics-perl
libalgorithm-diff-xs-perl
libanyevent-perl libapt-pkg-perl libasync-interrupt-perl libautobox-perl
libautovivification-perl
libb-compiling-perl libb-hooks-op-annotation-perl libb-hooks-op-check-perl
libb-utils-perl
libbareword-filehandles-perl libbit-vector-perl libcache-fastmmap-perl
libcairo-gobject-perl
libcairo-perl libcflow-perl libclass-c3-xs-perl libclass-load-xs-perl
libclass-methodmaker-perl
libclass-xsaccessor-perl libclone-perl libcommon-sense-perl
libcompress-bzip2-perl
libcompress-raw-lzma-perl libcoro-perl libcrypt-blowfish-perl
libcrypt-cast5-perl
libcrypt-des-perl libcrypt-eksblowfish-perl libcrypt-openssl-bignum-perl
libcrypt-openssl-rsa-perl
libcrypt-rijndael-perl libcrypt-smime-perl libcrypt-ssleay-perl
libcrypt-twofish-perl
libcurses-perl libdata-dump-streamer-perl libdata-structure-util-perl
libdate-calc-xs-perl
libdate-pcalc-perl libdatetime-perl libdbd-pg-perl libdbd-sqlite3-perl
libdbi-perl
libdevel-caller-perl libdevel-callsite-perl libdevel-cover-perl
libdevel-declare-perl
libdevel-leak-perl libdevel-lexalias-perl libdevel-nytprof-perl
libdevel-overloadinfo-perl
libdevel-refcount-perl libdevel-size-perl libdevel-stacktrace-perl
libdevice-usb-perl
libdigest-jhash-perl libdigest-sha-perl libdigest-sha3-perl
libencode-hanextra-perl libev-perl
libevent-perl libfcgi-perl libffi-platypus-perl libfile-fcntllock-perl
libfile-fnmatch-perl
libfile-rsyncp-perl libfilesys-df-perl libfilter-perl libforks-perl libgd-perl
libglib-object-introspection-perl libglib-perl libgtk2-perl libguard-perl
libhash-fieldhash-perl
libhash-storediterator-perl libhtml-parser-perl libhttp-parser-xs-perl
libimage-magick-q16-perl
libindirect-perl libio-aio-perl libio-interface-perl li
[Aptitude-devel] Bug#931619: Bug#931619: aptitude: InRelease fetch errors for stable, stable-updates and testing
Control: forcemerge 915246 -1 Hi Vincent, Vincent Lefevre wrote: > I get the following obscure error messages when updating from the UI: [...] > "apt update" has no issues, but it has asked me some questions, > that aptitude didn't do: thanks for the report. This is a duplicate of #915246, #931536, and #931543, hence merging. Please see my comments in these bug reports. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#915246: Bug#931536: aptitude update fails to cope with changed release info
Hi Francesco, Michael and Sven, Francesco Poli (wintermute) wrote: > As you know, Debian buster has been released yesterday and the current > Debian testing has just been renamed from 'buster' to 'bullseye'. > > Good, but... today I tried to update the repository lists and upgrade > my Debian testing boxes with aptitude: […] > E: Repository 'http://deb.debian.org/debian testing InRelease' changed its > 'Codename' value from 'buster' to 'bullseye' > E: Failed to download some files > W: Failed to fetch http://deb.debian.org/debian/dists/testing/InRelease: > E: Some index files failed to download. They have been ignored, or old ones > used instead. Indeed. This also seems to have an impact where buster changed from "testing" to "stable", see https://bugs.debian.org/931543. That's actually prompted by a change in libapt (as Sven already pointed out in #931543) which aptitude indeed hasn't been updated a for. I though must admit that we actually were aware of this issue as I ran into it with a third-party repo a few months ago, see https://bugs.debian.org/915246. But admittedly I totally underestimated its severity and especially also its impact at release time as I didn't think of that exactly the same will happen when Debian shifts all suite names at release time. Sorry for that. I hope that Manuel (CCc'ed) can provide a fix which we then can also apply to aptitude in Buster in the first minor update which is expected in about a month. The official workaround is to use "apt update" once inbetween, answer its questions (with "y" :-) and then continue to use aptitude. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#926371: Bug#926371: aptitude: FTBFS with gcc 8.3
Hi Santiago,
Santiago Vila wrote:
> On Thu, Apr 04, 2019 at 11:31:34AM +0200, Axel Beckert wrote:
> > > make[6]: *** [Makefile:412: download_progress.o] Error 1
> >
> > Will test later (once the dist-upgrade is through) with 8.3.0-5 from
> > unstable, too.
>
> Note: The rebuilds I triggered on reproducible-builds worked ok,
Yes, and it compiled fine again after I upgraded g++-8 and gcc-8 to
8.3.0-5. I suspect this is a case of of
https://bugs.debian.org/926234, which was introduced in 8.3.0-2,
boost-related (aptitude uses boost) and was fixed in 8.3.0-5 which is
not yet in buster.
I'll build it a few more times with 8.3.0-5 to make sure it's not
non-deterministic, but I'm optimistic, that this is a duplicate of
#926234 in g++-8 8.3.0-2 to 8.3.0-4.
> but not the one on the armhf architecture in unstable:
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/aptitude.html
At least this morning 6:02 UTC, g++-8 8.3.0-5 was not yet available on
armhf Raspberry Pi running Debian Sid. And according to
https://buildd.debian.org/status/package.php?p=gcc-8 the armhf build
only finished ("installed") around 6:54 UTC, so it very likely wasn't
yet available to a build having started at 06:54:26 UTC this morning.
I currently don't have my SSO client certificate handy. Can you
schedule another reproducible builds rebuild on armhf? At least on my
Sid Raspberry Pi, 8.3.0-5 is now available on armhf, too.
> (Not sure how to interpret that. Maybe it's a compiler bug after all).
If the armhf builds are fixed the next rebuild, too, I'm very
confident, that it is.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#926371: Bug#926371: aptitude: FTBFS with gcc 8.3
Control: tag -1 + confirmed Hi Santiago, thanks for the bug report. I can confirm this build failure with g++-8/8.3.0-3 (already past testing). Santiago Vila wrote: > I tried to build this package in buster but it failed: [...] > In file included from /usr/include/boost/mpl/aux_/include_preprocessed.hpp:37, > from /usr/include/boost/mpl/quote.hpp:45, > from /usr/include/boost/mpl/aux_/full_lambda.hpp:25, > from /usr/include/boost/mpl/lambda.hpp:22, > from /usr/include/boost/mpl/iter_fold.hpp:20, > from /usr/include/boost/variant/detail/initializer.hpp:28, > from /usr/include/boost/variant/variant.hpp:30, > from /usr/include/boost/variant.hpp:17, > from ../../../../../src/generic/views/download_progress.h:25, > from > ../../../../../src/generic/views/mocks/download_progress.h:26, > from > ../../../../../src/generic/views/mocks/download_progress.cc:23: > /usr/include/boost/mpl/aux_/preprocessed/gcc/quote.hpp:64:8: error: > redeclared here as 'template class F' > struct quote3 > ^~ > make[6]: *** [Makefile:412: download_progress.o] Error 1 Will test later (once the dist-upgrade is through) with 8.3.0-5 from unstable, too. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#925445: Bug#925445: Aw: Bug#925445 closed by Julian Andres Klode (Re: Bug#925445: jessie-backports packages for amd64 have disappeared from mirrors)
Hi Nik, Nik Wrt wrote: > Many thanks for your fast reply. How do I contact the LTS or backports people? https://lists.debian.org/debian-lts/ → debian-...@lists.debian.org https://lists.debian.org/debian-backports/ → debian-backpo...@lists.debian.org And the latter already has your question — answered: https://lists.debian.org/debian-backports/2019/03/msg00043.html Please also see https://lists.debian.org/debian-backports/2019/03/msg00039.html Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#915246: aptitude: doesn't cope with "Repository '…' changed its 'Origin' value from 'A' to 'B'. This must be accepted explicitly before updates for this repository can be applied.
Package: aptitude Version: 0.8.11-6 Severity: normal I just got this dialog from the aptitude TUI after updating package list with "aptitude -u": ┌─┐ │E: Failed to download some files ▒│ │W: Failed to fetch https://deb.opera.com/opera/dists/stable/InRelease: ▒│ │W: Failed to fetch https://deb.opera.com/opera-beta/dists/stable/InRelease: ▒│ │W: Failed to fetch https://deb.opera.com/opera-snapshot/dists/stable/InRelease: ▒│ │E: Some index files failed to download. They have been ignored, or old ones used instead. ▒│ │ [ Ok ] │ └─┘ With "aptitude update", it looks like this, showing more details: Fetched 269 kB in 15s (18.2 kB/s) E: Repository 'https://deb.opera.com/opera stable InRelease' changed its 'Origin' value from 'Opera Software ASA' to 'Opera Software AS' E: Repository 'https://deb.opera.com/opera-beta stable InRelease' changed its 'Origin' value from 'Opera Software ASA' to 'Opera Software AS' E: Repository 'https://deb.opera.com/opera-snapshot stable InRelease' changed its 'Origin' value from 'Opera Software ASA' to 'Opera Software AS' E: Failed to download some files W: Failed to fetch https://deb.opera.com/opera/dists/stable/InRelease: W: Failed to fetch https://deb.opera.com/opera-beta/dists/stable/InRelease: W: Failed to fetch https://deb.opera.com/opera-snapshot/dists/stable/InRelease: E: Some index files failed to download. They have been ignored, or old ones used instead. But with "apt update" I get this dialog (and afterwards two more) instead of just failing package list updates: E: Repository 'https://deb.opera.com/opera stable InRelease' changed its 'Origin' value from 'Opera Software ASA' to 'Opera Software AS' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. Do you want to accept these changes and continue updating from this repository? [y/N] Seems as if currently aptitude doesn't have the capability to make a dialog out of this. Additionally, it shows less of the error message(s) in TUI mode than in CLI mode despite it IMHO shou;dn't. -- Package-specific info: Terminal: eterm-color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.11 Compiler: g++ 8.2.0 Compiled against: apt version 5.0.2 NCurses version 6.1 libsigc++ version: 2.10.1 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.1.20181013 cwidget version: 0.5.17 Apt version: 5.0.2 aptitude linkage: linux-vdso.so.1 (0x7fffbf3e6000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7f2ffc266000) libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 (0x7f2ffc22c000) libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x7f2ffc1fe000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f2ffc1f5000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7f2ffc0ef000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f2ffbfce000) libboost_iostreams.so.1.67.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.67.0 (0x7f2ffbfae000) libboost_system.so.1.67.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.67.0 (0x7f2ffbfa7000) libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x7f2ffbd7c000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f2ffbd5b000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f2ffbbd8000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f2ffba44000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f2ffba28000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f2ffb86b000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f2ffb852000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f2ffb634000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f2ffb621000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f2ffb3fb000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f2ffb1dc000) libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x7f2ffb141000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f2ffb121000) /lib64/ld-linux-x86-64.so.2 (0x7f2ffc8db000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f2ffb11c000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
[Aptitude-devel] Bug#908838: Bug#908838: aptitude-doc-en: Links to http://debtags.alioth.debian.org/
Control: tag -1 + confirmed Control: severity -1 normal Hi, Mykola Nikishov wrote: > At least, in file:///usr/share/doc/aptitude/html/en/ch02s04s05.html#searchTag: > > For more information on tags and debtags, see > http://debtags.alioth.debian.org. Indeed. And there's more alioth URLs which need to be changed: debian/control:Homepage: https://aptitude.alioth.debian.org/ doc/en/aptitude.xml: url='http://cwidget.alioth.debian.org'>. doc/en/aptitude.xml: url='http://debtags.alioth.debian.org'/>. doc/en/aptitude.xml: url='http://debtags.alioth.debian.org'/>. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#906695: Bug#906695: aptitude: apt doesn't call fsync on the file extended_states
Control: tag -1 - moreinfo Hi Mikulas, Mikulas Patocka wrote: > I've straced unattended-upgrade while doing an upgrade and it also > doesn't use fsync, just like aptitude: Thanks for the details. So before cloning this twice for apt and unattended-upgrades, I'd like to know if that's maybe an issue in one of apt's libraries which all these tools use. David: Can you enlighten us here? Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
