[Aptitude-devel] Bug#1065435: aptitude: FTBFS on armhf and armel (probably -Werror=implicit-function-declaration related)
On 2024-03-04 16:01 +0100, Axel Beckert wrote:
> 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).
Not really, these arches now default to a 64-bit time_t and therefore
you get the conflicting types (suseconds_t is a long int,
__suseconds64_t a long long int). This has nothing to do with implicit
function declarations.
Cheers,
Sven
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude
Control: severity -1 normal
On 2024-02-28 15:49 +0100, Vincent Lefevre wrote:
> Source: apt
> Version: 2.7.12+nmu1
> Severity: serious
>
> While there are no upgrade issues with apt itself (according
> to "apt install -s apt"), aptitude does not want to upgrade
> apt automatically, while this just appears to be a package
> rename:
>
> # aptitude install apt
> The following packages will be upgraded:
> apt{b} apt-doc
> 2 packages upgraded, 0 newly installed, 0 to remove and 180 not upgraded.
> Need to get 1622 kB of archives. After unpacking 0 B will be used.
> The following packages have unmet dependencies:
> apt : Depends: libapt-pkg6.0t64 (>= 2.7.12+nmu1) but it is not going to be
> installed
> apt-utils : Depends: apt (= 2.7.12) but 2.7.12+nmu1 is to be installed
> The following actions will resolve these dependencies:
>
> Keep the following packages at their current version:
> 1) apt [2.7.12 (now, testing)]
>
> I don't know whether this is actually an issue with aptitude, but at
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059068#15
>
> David Kalnischkies says:
> | You should really know this by now as that isn't your first report, but
> | okay: Upgrade problems are NEVER a problem to be solved in apt,
> | they are ALWAYS a problem in the involved packages. NO EXCEPTIONS.
>
> So, I suppose that this is also the case for aptitude: if aptitude
> cannot upgrade just because of a rename, then this is a problem in
> the involved packages.
No, in this case it is a problem with aptitude's resolver which
manifests itself due to the following configuration setting:
> Aptitude::ProblemResolver::SolutionCost "safety, removals";
This does cause aptitude to hold apt back by default, rather than remove
libapt-pkg6.0. You can press 'n' at the prompt, the next solution
aptitude then suggests is to upgrade apt.
Cheers,
Sven
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1057688: aptitude: Stray input on window click when running under tmux
Control: reassign -1 ncurses-base 6.4+20231118-1 Control: retitle -1 ncurses-base: mouse malfunctions in tmux On 2023-12-08 14:29 -0500, Thomas Dickey wrote: > On Fri, Dec 08, 2023 at 05:01:43PM +0100, Sven Joachim wrote: >> >> However, tmux got changed the other way around: it already had used >> xterm+focus, and you added xterm+sm+1006. This is the diff hunk: >> >> , >> | @@ -8550,7 +8556,7 @@ tmux|tmux terminal multiplexer, >> |use=ecma+italics, use=ecma+strikeout, use=xterm+edit, >> |use=xterm+pcfkeys, use=xterm+sl, use=xterm+tmux, >> |use=screen, use=bracketed+paste, use=report+version, >> | - use=xterm+focus, >> | + use=xterm+focus, use=xterm+sm+1006, >> | >> | tmux-256color|tmux with 256 colors, >> |use=xterm+256setaf, use=tmux, >> ` >> >> That seems to be not really intended and should likely be reverted, >> given the issue at hand. > > will do. Thanks, I will either cherry-pick that fix or upgrade to the 20231209 patchlevel, then we are all set. Cheers, Sven ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1057688: aptitude: Stray input on window click when running under tmux
On 2023-12-07 17:41 -0500, Thomas Dickey wrote: > On Thu, Dec 07, 2023 at 06:06:49PM +0100, Axel Beckert wrote: >> 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. > > It's probaby the same issue as this; > > 20231028 > + move xterm focus mode 1004 from xterm+sm+1006 into xterm+focus as > fe/fd capabilities, like vim (vim-pr #13440). Looking at the misc/terminfo.src changes in that patchlevel, I see that you added xterm+focus to several terminfo entries that had used xterm+sm+1006, which is logical and in line with the NEWS entry. However, tmux got changed the other way around: it already had used xterm+focus, and you added xterm+sm+1006. This is the diff hunk: , | @@ -8550,7 +8556,7 @@ tmux|tmux terminal multiplexer, | use=ecma+italics, use=ecma+strikeout, use=xterm+edit, | use=xterm+pcfkeys, use=xterm+sl, use=xterm+tmux, | use=screen, use=bracketed+paste, use=report+version, | - use=xterm+focus, | + use=xterm+focus, use=xterm+sm+1006, | | tmux-256color|tmux with 256 colors, | use=xterm+256setaf, use=tmux, ` That seems to be not really intended and should likely be reverted, given the issue at hand. > (a change to the terminal description to help vim turned out to expose one > of the VTE bugs - fixed by making it less likely for other applications > to trigger the bug) There is no VTE involved in this case, I reproduced the problem in xterm. Cheers, Sven ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
[Aptitude-devel] Bug#1057688: aptitude: Stray input on window click when running under tmux
Hi, Debian ncurses maintainer here, bringing the ncurses upstream developer into the loop. On 2023-12-06 22:28 -0700, Antonio Russo wrote: > Package: aptitude > Version: 0.8.13-5 > Severity: normal > X-Debbugs-Cc: aeru...@aerusso.net > > Dear maintainer, > > If I run aptitude inside xterm, and click on an aptitude TUI element (say, a > particular > package), that package will be selected. If, instead, I am running aptitude > inside tmux, > and I click on said element, it appears many garbage characters are sent to > aptitude, > including probably m and M, (the symptom is the automatic install state of > packages changes). > > If I manually set TERM=xterm inside the tmux window, everything works. > Alternatively, outside > of tmux, if I set TERM=tmux-256color I get the same bad behavior in aptitude. > > If I downgrade all ncurses packages to 6.4+20231016, I don't get this > behavior. The culprit is the addition of xterm+sm+1006 (xterm SGR-mouse) to the tmux/tmux-256color terminfo entries in the ncurses 20231028 patchlevel. 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. Cheers, Sven ___ Aptitude-devel mailing list Aptitude-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
