Bug#1067946: dietlibc: Includes non-free Sun RPC
Bastian Germann dixit: >> Do you have a link? > > No. It is not a public address. Ah, yes, that is unfortunate. I used to be subscribed and have no idea why I’m not, but I re-subscribed (though have not yet seen any traffic in the last couple of days). >> What did upstream say? > > No upstream response up to now. OK. I just asked in #d-ftp whether we can get an official statement on whether “we received this as part of dietlibc (a product or program developed by user” (i.e. Fefe) under GPL will suffice (which I personally consider true). If they say yes, I’ll fix that the block is missing from d/copyright and have a look at #1069365 (unless Christian prefers to). If they say no, we’ll have to inform reverse dependencies of this, ask upstream again with some more urgency, and prepare for removal of this meanwhile (I don’t think we can just swap out such much code in the packaging)… or possibly excise the sunrpc code and hope this doesn’t break any users. Until then… no idea. Wait and drink tea, or something? bye, //mirabilos -- 18:47⎜ well channels… you see, I see everything in the same window anyway 18:48⎜ i know, you have some kind of telnet with automatic pong 18:48⎜ haha, yes :D 18:49⎜ though that's more tinyirc – sirc is more comfy
Bug#1067946: dietlibc: Includes non-free Sun RPC
Hi Bastian, >I have already informed upstream about it. did you do that on a mailing list? Do you have a link? What did upstream say? Still unconvinced, //mirabilos -- If Harry Potter gets a splitting headache in his scar when he’s near Tom Riddle (aka Voldemort), does Tom get pain in the arse when Harry is near him? -- me, wondering why it’s not Jerry Potter………
Bug#1069678: openjdk-8: CVE-2024-21011 CVE-2024-21068 CVE-2024-21085 CVE-2024-21094
tags 1069678 + pending thanks I’m working on it. Upload should come RSN. AIUI the security team can feel free to ignore openjdk-8 as it’s in sid for bootstrapping and preparing ELTS upgrades and downstreams purposes, and not “as is” security-supported in Debian, so if it helps lowering the workload…
Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in
reassign 1052197 xorgxrdp affects 1052197 xrdp found 1052197 1:0.2.12-1 fixed 1052197 1:0.2.12-1+deb11u1 fixed 1052197 1:0.9.19-1 thanks Gürkan Myczko dixit: > This bug has been closed upstream, and upstream packages have been in > the archive for a while. No, the bug has been fixed by binNMUing the affected package (or, actually, no-change-uploading, with apo forgetting to close the bug) so it got rebuilt against the upgraded other package. But, yes, the bug can be closed. bye, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"...
Bug#1067946: dietlibc: Includes non-free Sun RPC
Bastian Germann dixit: >dietlibc includes the sunrpc code from old glibc versions, which is >demonstrated to be non-free in #181493. The text in dietlibc reads thusly though: Users * may copy or modify Sun RPC without charge, but are not authorized * to license or distribute it to anyone else except as part of a product or * program developed by the user. One could argue that dietlibc is a product developed by Fefe, who then licences and distributes it (under GPL) to others, which (as long as that notice is included) is covered. I see dancer already said so, and… | Sun has repeatedly clarified elsewhere that the intent of this is | essentially "MIT/X11, except you may not distribute this product | alone." … don’t we have other things like that in the archive, with the justification that it’s trivial to add something to it. And I don’t follow the others in that thread who think that the licence of the product developed by the (first) user cannot be transitive. Note both IANAL+TINLA, but so are the folks on d-legal. The clarification by Sun also says so. Not that I’m adverse to replacing things with better-licenced things, but I don’t think it warrants rc-bugginess (the lack of the licence in d/copyright does but is a different topic). But… >I have already informed upstream about it. … this is where this is best dealt with. Thanks. bye, //mirabilos -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Bug#1067829: nfs-utils: FTBFS on arm{el,hf}: export-cache.c:110:51: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘time_t’ {aka ‘long long int’} [-Werror=format=]
Emanuele Rocca dixit: >The attached patch by Vladimir Petko was sent upstream and fixes the >FTBFS on armhf/armel. The patch is catastrophically wrong. +- snprintf(flushtime, sizeof(flushtime), "%ld\n", now); ++ snprintf(flushtime, sizeof(flushtime), "%lld\n", now); Change that to: ++ snprintf(flushtime, sizeof(flushtime), "%lld\n", (long long)now); time_t is not guaranteed to be 64-bit (or even integer, by ISO C), it must always be coerced into the expected type for printf. Please forward this upstream as well. Might as well want to check that flushtime is large enough, too. bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
Andrey Rakhmatullin dixit: >OPAL_THREAD_ADD_FETCH64 is defined under #if OPAL_HAVE_ATOMIC_MATH_64 Yes. >, and I suspect not all of its uses also are. That’s what I get from this, yes. >And I assume this arch doesn't have 64-bit atomics. No native ones, yes. I *think* either libatomic or libatomic_ops(?) make them available, but very slowly, using a syscall to guarantee atomicity (those systems are normally uniprocessor) on m68k. If possible, avoiding them would be preferrable. (For example, in some cases, like reading a 64-bit timestamp, if the writing direction is known and stable, reading twice then comparing is a possible alternative at least for some architectures (e.g. I know BSD code for sparc does it that way). I guess you’ll have to ask the porters of 32-bit arches with no native 64-bit atomics for details. Though I had thought GCC’s builtin atomics use the aforementioned kernel-based workaround from that library these days? bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#1067399: openjdk-17-jre: uninstallable (depends on wrong libraries)
Package: openjdk-17-jre Version: 17.0.11~6ea-1 Severity: serious Justification: uninstallable Depends: openjdk-17-jre-headless (= 17.0.11~6ea-1), libglib2.0-0t64 (>= 2.24), […], libcups2, […] This must of course be libcups2t64.
Bug#1067247: pulseaudio: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
Source: pulseaudio Version: 16.1+dfsg1-3 Severity: serious Justification: FTBFS Tags: ftbfs X-Debbugs-Cc: t...@mirbsd.de Unfortunately, as with umockdev, I have no idea what is going on here… does it #undef _FILE_OFFSET_BITS or something?
Bug#1067208: umockdev: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
Source: umockdev Version: 0.18.0-1 Severity: serious Justification: FTBFS on t64-affected archs X-Debbugs-Cc: t...@mirbsd.de Tags: ftbfs cc -Ilibumockdev-preload.so.0.0.0.p -I. -I.. -fdiagnostics-color=always -Wall -Winvalid-pch -std=gnu11 -Werror=missing-prototypes -Werror=strict-prototypes -Werror=nested-externs -Werror=pointer-arith -Werror=implicit-function-declaration -Werror=implicit-int -Werror=int-conversion -Werror=old-style-definition -Werror=pointer-arith -Werror=init-self -Werror=format-security -Werror=format=2 -Werror=return-type -Werror=uninitialized -Wcast-align -Wno-error=pragmas -Wno-error=discarded-qualifiers -Wno-error=incompatible-pointer-types -Wno-error=pointer-sign -Wno-unused-but-set-variable -Wno-unused-function -Wno-unused-label -Wno-unused-value -Wno-unused-variable -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=default -MD -MQ libumockdev-preload.so.0.0.0.p/src_libumockdev-preload.c.o -MF libumockdev-preload.so.0.0.0.p/src_libumockdev-preload.c.o.d -o libumockdev-preload.so.0.0.0.p/src_libumockdev-preload.c.o -c ../src/libumockdev-preload.c In file included from /usr/include/features.h:393, from /usr/include/assert.h:35, from ../src/libumockdev-preload.c:31: /usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" 26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64" | ^ I admit I don’t exactly see what’s going on here. Does it maybe #unset _FILE_OFFSET_BITS or something?
Bug#1065436: cyrus-sasl2 accesses resources from the network during the build
Matthias Klose dixit: > the Debian build log doesn't show this error message, so this sphinx > inventory is fetched from the website during the build. Huh? Does sbuild/buildd not unshare the network? I added that to pbuilder some time ago and vaguely recall that there was an expectation that the buildds do that as well, and a bit of back and forth leading to the loopback interface being initialised in the separate namespace but nothing more. bye, //mirabilos -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Bug#1067198: libgts-0.7-5t64: emits shlib dependencies on libgts-0.7-5
Package: libgts-0.7-5t64 Version: 0.7.6+darcs121130-5.1 Severity: grave Justification: uninstallable X-Debbugs-Cc: t...@mirbsd.de, vor...@debian.org Control: affects -1 src:graphviz libgvc6 When building against libgts-0.7-5t64, the generated packages get a shlib:Depends of 'libgts-0.7-5 (>= 0.7.6)' instead of the expected libgts-0.7-5t64. This is probably because the shlibs… | libgts-0.7 5 libgts-0.7-5t64 (>= 0.7.6+darcs121130) … and symbols… | libgts-0.7.so.5 libgts-0.7-5 #MINVER# | gts_allow_floating_edges@Base 0.7.6 […] … control files disagree. This is a t64 transition showstopper (vala B-D graphviz).
Bug#1067055: openmpi: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'
Source: openmpi Version: 4.1.6-7 Severity: serious Justification: ftbfs Tags: ftbfs Tag: ftbfs X-Debbugs-Cc: t...@mirbsd.de […] libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../../../../opal/mca/btl/ofi -I../../../../opal/include -I../../../../ompi/include -I../../../../oshmem/include -I../../../../opal/mca/hwloc/hwloc201/hwloc/include/private/autogen -I../../../../opal/mca/hwloc/hwloc201/hwloc/include/hwloc/autogen -I../../../../ompi/mpiext/cuda/c -I../../../../../.. -I../../../.. -I../../../../../../opal/include -I../../../../../../orte/include -I../../../../orte/include -I../../../../../../ompi/include -I../../../../../../oshmem/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/local/include -I/usr/local/include -DNDEBUG -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/tmp/buildd/openmpi-4.1.6=. -fstack-protector-strong -Wformat -Werror=format-security -O3 -finline-functions -fno-strict-aliasing -c ../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c -fPIC -DPIC -o .libs/btl_ofi_rdma.o In file included from ../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c:14: ../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c: In function 'mca_btl_ofi_get': ../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.h:33:13: error: implicit declaration of function 'OPAL_THREAD_ADD_FETCH64'; did you mean 'OPAL_THREAD_ADD_FETCH32'? [-Werror=implicit-function-declaration] 33 | OPAL_THREAD_ADD_FETCH64(&(module)->outstanding_rdma, 1); \ | ^~~ ../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c:70:5: note: in expansion of macro 'MCA_BTL_OFI_NUM_RDMA_INC' 70 | MCA_BTL_OFI_NUM_RDMA_INC(ofi_btl); | ^~~~ ../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c:82:40: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 82 | remote_address = (remote_address - (uint64_t) remote_handle->base_addr); |^ ../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c: In function 'mca_btl_ofi_put': ../../../../../../opal/mca/btl/ofi/btl_ofi_rdma.c:132:40: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 132 | remote_address = (remote_address - (uint64_t) remote_handle->base_addr); |^ cc1: some warnings being treated as errors make[4]: *** [Makefile:1946: btl_ofi_rdma.lo] Error 1 make[4]: Leaving directory '/tmp/buildd/openmpi-4.1.6/debian/build-gfortran/opal/mca/btl/ofi'
Bug#1066137: gnupg1: fails to build gpgkeys_ldap, probably due to -Werror=implicit-function-declaration
Hi Andreas, >Afaict ghostscript/fig2dev have stopped being blockers so I do not plan >on doing another upload (with more work for the other autobuilders) just >to temporarily disable these b-ds. Indeed, that’s fine. But including that in the n̲e̲x̲t̲ upload you do anyway would be nice. Thanks, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#1066214: cyrus-sasl2: FTBFS: gssapi.c:1600:9: error: implicit declaration of function âgsskrb5_register_acceptor_identityâ [-Werror=implicit-function-declaration]
Dixi quod… >Suggested fix: > >+ AC_CHECK_HEADERS(gssapi/gssapi_krb5.h) > AC_CHECK_FUNCS(gsskrb5_register_acceptor_identity) > if test "$ac_cv_func_gsskrb5_register_acceptor_identity" = no ; then >- AC_CHECK_HEADERS(gssapi/gssapi_krb5.h) > >If it’s really that, anyway. At least it allows the build to proceed further. It’s still building, though, so I cannot say if this fixes the build. (Thanks to #1066811 the result will not work right anyway.) bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs
Bug#1066138: gnupg1: fails to build gpgkeys_ldap, probably due to -Werror=implicit-function-declaration
Dixi quod… >I just tested the 2.2 patch on gnupg1, and it applies cleanly, >[…] >For gnupg1, the B-D are also already installable, so there’s no >current need to modify them there, just apply the same patch as >was applied in gnupg2 2.2 and upload. It finished building with the patch, so please do ☻ Thanks, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#1066214: cyrus-sasl2: FTBFS: gssapi.c:1600:9: error: implicit declaration of function ‘gsskrb5_register_acceptor_identity’ [-Werror=implicit-function-declaration]
Andrey Rakhmatullin dixit: >On Wed, Mar 13, 2024 at 12:36:37PM +0100, Lucas Nussbaum wrote: >> > gssapi.c:1600:9: error: implicit declaration of function >> > ‘gsskrb5_register_acceptor_identity’ >> > [-Werror=implicit-function-declaration] >> > 1600 | gsskrb5_register_acceptor_identity(keytab_path); >> > | ^~ >The function should be declared in , in this case it's >/usr/include/heimdal/gssapi/gssapi_krb5.h from heimdal-multidev, but >build-heimdal/config.h defines HAVE_GSSKRB5_REGISTER_ACCEPTOR_IDENTITY but >doesn't define HAVE_GSSAPI_GSSAPI_KRB5_H, so is not >included but the code is compiled. That’s because m4/sasl2.m4… AC_CHECK_FUNCS(gsskrb5_register_acceptor_identity) if test "$ac_cv_func_gsskrb5_register_acceptor_identity" = no ; then AC_CHECK_HEADERS(gssapi/gssapi_krb5.h) if test "$ac_cv_header_gssapi_gssapi_krb5_h" = "yes"; then AC_CHECK_DECL(gsskrb5_register_acceptor_identity, [AC_DEFINE(HAVE_GSSKRB5_REGISTER_ACCEPTOR_IDENTITY,1, [Define if your GSSAPI implementation defines gsskrb5_register_acceptor_identity])],, [ AC_INCLUDES_DEFAULT #include ]) fi fi … only checks for the header file if gsskrb5_register_acceptor_identity is not found without it included. Suggested fix: + AC_CHECK_HEADERS(gssapi/gssapi_krb5.h) AC_CHECK_FUNCS(gsskrb5_register_acceptor_identity) if test "$ac_cv_func_gsskrb5_register_acceptor_identity" = no ; then - AC_CHECK_HEADERS(gssapi/gssapi_krb5.h) If it’s really that, anyway. bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#1066138: gnupg1: fails to build gpgkeys_ldap, probably due to -Werror=implicit-function-declaration
Hi again, >on 1.x or 2.4 before the weekend. I just tested the 2.2 patch on gnupg1, and it applies cleanly, and configure also seems happy: […] checking whether the resolver is usable... yes checking whether LDAP via "-lldap" is present and sane... yes checking for ldap_get_option... yes checking for ldap_set_option... yes checking for ldap_start_tls_s... yes checking for ldap_start_tls_sA... no checking for gawk... (cached) mawk […] For gnupg1, the B-D are also already installable, so there’s no current need to modify them there, just apply the same patch as was applied in gnupg2 2.2 and upload. Thanks, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#1066811: cyrus-sasl2: assumes time_t fits into long for printf and scanf(!), will break on big endian
Source: cyrus-sasl2
Version: 2.1.28+dfsg1-4
Severity: serious
Justification: breaks
X-Debbugs-Cc: t...@mirbsd.de
cyrus-sasl2, before aborting the build due to #1066214, spews
several warnings like the following:
[…]
otp.c:648:43: warning: format '%ld' expects argument of type 'long int', but
argument 7 has type 'time_t' {aka 'long long int'} [-Wformat=]
648 | sprintf(data, "%s\t%04d\t%s\t%s\t%020ld",
| ~^
| |
| long int
| %020lld
649 | alg, seq, seed, buf, timeout);
| ~~~
| |
| time_t {aka long long int}
otp.c:709:48: warning: format '%ld' expects argument of type 'long int *', but
argument 7 has type 'time_t *' {aka 'long long int *'} [-Wformat=]
709 | sscanf(secret, "%s\t%04d\t%s\t%s\t%020ld",
| ~^
||
|long int *
| %020lld
710 |alg, seq, seed, buf, timeout);
| ~~~
| |
| time_t * {aka long long int *}
[…]
These are actual problems that not only result in bad data
being printed or read but, if the time_t argument is not
(like here) the last one, also wrong arguments being used
for subsequent positional parameters.
Please fix *all* -Wformat mismatches involving time_t, for
example:
- sprintf(data, "%s\t%04d\t%s\t%s\t%020ld",
+ sprintf(data, "%s\t%04d\t%s\t%s\t%020lld",
- alg, seq, seed, buf, timeout);
+ alg, seq, seed, buf, (long long)timeout);
+ long long tmptimeout;
- sscanf(secret, "%s\t%04d\t%s\t%s\t%020ld",
+ sscanf(secret, "%s\t%04d\t%s\t%s\t%020lld",
- alg, seq, seed, buf, timeout);
+ alg, seq, seed, buf, tmptimeout);
+ timeout = tmptimeout;
Justification: I’ve been fixing bugs like these on MirBSD
since its i386 port switched to 64-bit time_t in 2004…
Thanks,
//mirabilos
--
16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml
Bug#1066138: gnupg1: fails to build gpgkeys_ldap, probably due to -Werror=implicit-function-declaration
Hi Andreas >I have upload a fix for 2.2 OK, that should help. >probably will not be able to spend any time on 1.x or 2.4 before the weekend. They can probably wait until then, no worries. >It is fixed in 2.4 and I am very reluctant to backport major packaging >updates to 2.2 For some values of major; Helmut already verified that the resulting binary packages are identical, and… >since I think we will need to ship some kind of 2.4 in trixie. … this massively helps with the current transition in unstable, which has to come before thinking of trixie. Even gdb-13 has temporarily lost its gdb B-D, and pam temporarily broke ABI by not including one module, to help the transition. For gnupg2 this is a no-change-in-binary source change, so of much less impact. Thanks, //mirabilos -- Gast: „Ein Bier, bitte!“ Wirt: „Geht auch alkoholfrei?“ Gast: „Geht auch Spielgeld?“
Bug#1066137: gnupg2: -Werror=implicit-function-declaration failure testing for ldap_open
clone 1066137 -1 reassign -1 gnupg1 1.4.23-1.1 retitle -1 gnupg1: fails to build gpgkeys_ldap, probably due to -Werror=implicit-function-declaration thanks Dixi quod… >This matches the following failure mode at the end of the build: Same for gnupg1 according to the buildd page: https://buildd.debian.org/status/package.php?p=gnupg1 >Trying to binNMU gnupg2 to make it installable during t64 transition, Please do also reduce the B-D as Helmut noted in #980768; specifically, dropping ghostscript, imagemagick, libcurl4-gnutls-dev and transfig from src:gnupg2 produces identical binary packages according to his analysis. Perhaps some of that applies to gnupg1 as well. This will help tremendously. Thanks, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#1066137: gnupg2: -Werror=implicit-function-declaration failure testing for ldap_open
Source: gnupg2
Version: 2.2.40-1.1
Severity: serious
Justification: ftbfs
X-Debbugs-Cc: t...@mirbsd.de
Trying to binNMU gnupg2 to make it installable during t64 transition,
I notice the following configury output:
[…]
checking for library containing dn_skipname... none required
checking whether the resolver is usable... yes
checking whether LDAP via "-lldap" is present and sane... no
checking whether I can make LDAP be sane with lber.h... no
checking whether LDAP via "-lldap -llber" is present and sane... no
checking whether I can make LDAP be sane with lber.h... no
checking whether LDAP via "-lldap -llber -lresolv" is present and sane... no
checking whether I can make LDAP be sane with lber.h... no
checking whether LDAP via "-lwldap32" is present and sane... no
checking whether I can make LDAP be sane with lber.h... no
checking for ber_free in -llber... yes
configure: WARNING:
***
*** Building without LDAP support.
*** No CRL access or X.509 certificate search available.
***
checking for sendmail... no
[…]
This matches the following failure mode at the end of the build:
19:50⎜ I can't build gnugpg2:
19:50⎜dh_install -a -O--builddirectory=build
19:50⎜ dh_install: warning: Cannot find (any matches for)
⎜"debian/tmp/usr/lib/gnupg/dirmngr_ldap" (tried in ., debian/tmp)
19:50⎜ dh_install: warning: dirmngr missing files:
⎜debian/tmp/usr/lib/gnupg/dirmngr_ldap
19:50⎜ dh_install: error: missing files, aborting
The cause in config.log:
configure:11580: checking whether LDAP via "-lldap" is present and sane
configure:11600: gcc -o conftest -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/tmp/buildd/gnupg2-2.2.40=.
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat
-Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2
-specs=/usr/share/dpkg/pie-link.specs -Wl,-z,relro -Wl,-z,now conftest.c -lldap
>&5
conftest.c: In function 'main':
conftest.c:96:1: error: implicit declaration of function 'ldap_open'; did you
mean 'ldap_turn'? [-Werror=implicit-function-declaration]
96 | ldap_open("foobar",1234);
| ^
| ldap_turn
cc1: some warnings being treated as errors
configure:11600: $? = 1
configure: failed program was:
[…]
| /* end confdefs.h. */
|
| #ifdef _WIN32
| #include
| #include
| #else
| #include
| #endif
|
| int
| main (void)
| {
| ldap_open("foobar",1234);
| ;
| return 0;
| }
configure:11608: result: no
Prototypes are now mandatory, both for C23 and because the t64 transition
can only work if prototypes are properly used.
bye,
//mirabilos
Bug#989736: Bug#1066051: openjdk-8: make package usable on systems without t64 packages
close 1066051 thanks Fab Stz dixit: >I usually install openjdk-8 from unstable on bookworm. This has never been officially supported. I’ve had an entire discussion around that last month, which I will quote parts from below, for context. >However this is not possible anymore because now it depends on t64 packages. Yes, this is to be expected. >Would it be possible to still install it on systems without t64 by >updating the dependencies/build-depends? No. But (see the background information below) I’ll be making available openjdk-8 packages built for bookworm in the “wtf-lts” extrepo soon (with the next upload, which will be done once the t64 transition has settled, i.e. in some days) if you don’t mind an inofficial repo (though operated by the same person who uploads the package to Debian proper so…), although for amd64 and i386 only at the moment, as I lack hardware to build for other platforms (tell me if you need that). The RSS feed for the wtf extrepo will tell you when. You can obtain that at http://www.mirbsd.org/~tg/Debs/NEWS.rss (s/\.rss// for plaintext). Quotes, some paraphrased, follow. Cc’ing the relevant bug for archival and public readability. OpenJDK 8 is included with Debian 9 (stretch) only, although it has been retrofitted to Debian 8 (jessie) for ELTS as it still is actively maintained, in contrast to jessie’s OpenJDK 7. Debian 10 and 11 shipped OpenJDK 11, due to misalignment between Debian’s and OpenJDK-LTS’ release cycles. > (why does #989736 to keep OpenJDK out of testing and stable exist?) The reason behind it is that every Debian release contains exactly one, and only one, supported OpenJDK version; the security team does not have resources for more (unlike commercial distributions, nobody is paid for their work). OpenJDK 8 had already been dropped from Debian, but I’ve resurrected it and took over maintenance. We still use it in Debian proper for: • staging new releases for ELTS (ELTS is not part of Debian proper but an external offering, although basically done by the same people) • bootstrapping new environments (like Kotlin) that depend on JDK 8 for their bootstrapping process This is all done in “unstable”; Kotlin was only able to enter “testing” once it met the release goals for the “next-stable”, that is to build with that then-future release’s default JDK. > There are a number of applications still depending on Java 8. Most of these should still run with 11 at least, even if they can only be built on 8 or with special options (I wrote a Maven parent POM that manages this). I know of exceptions that use undocumented/inofficial interfaces that are not actually part of the JDK’s API. For these, it’s really SOL… I personally don’t have a problem with making OpenJDK 8 releases available for other Debian releases; this is in fact how my involvement in this started (I did it for a customer but also made the results publicly available). If you don’t mind external repositories, you can use the builds from there. I recently stopped making builds for Debian 7 (wheezy) even if that is technically still feasible, because it is no longer supported by even ELTS. Debian 8 and 9 are provided OpenJDK 8 by Freexian ELTS. I produce builds for Debian 10 and 11, amd64 and i386 only (I lack the machines to do more currently). I don’t provide these packages for Debian 12 because I do not use the latter and have no way to test them and can so save time. Given incentive (a nice offer) I might add more to this mix. I also provide OpenJDK 8 for all *buntu LTS releases that Canonical allows Launchpad to build for, for all architectures the respective releases have, via a PPA. > (would be convenient to add openjdk-8 to stable) Once a Debian stable is released, packages aren’t added to it any more, barring special cases in LTS/ELTS releases like the aforementioned switching jessie from OpenJDK 7 to 8, or they all getting newer kernels. > (does the bugreport mean it will forever be blocked from making it to stable?) Yes, it blocks OpenJDK 8 from ever reaching testing, and a new stable is made by copying a frozen testing at the point in time where the release gets made. This is, indeed, the purpose of that debbugs item. The “Outlook” and the first message should have made that clear. (The latter also said to contact me so all is fine.) This is the compromise that allowed OpenJDK 8 to be kept in Debian at all, i.e. in Debian unstable; otherwise the security team would have veto’d this. There is no way for OpenJDK 8 to be supported in a stable Debian release any more. That doesn’t mean I desupport this in the package itself. While I don’t build for or test on wheezy or precise any more, these two and anything newer, up to the latest respective releases, should work, and I occasionally do things to make it so. You just have to obtain them from elsewhere than Debian itself… or, of course, do the
Bug#1065696: E: unsupported command: poweroff.no-molly-guard
Package: molly-guard Version: 0.8.3 Severity: grave Justification: renders package unusable Severity chosen both because this makes the package unusable (I will have to remove it now) and because it breaks the whole system (boot). root@aranym:/var/cache/apt/archives # poweroff W: molly-guard: SSH session detected! Please type in hostname of the machine to poweroff: aranym E: unsupported command: poweroff.no-molly-guard 1|root@aranym:/var/cache/apt/archives # which poweroff.no-molly-guard /usr/sbin/poweroff.no-molly-guard root@aranym:/var/cache/apt/archives # dpkg -S /usr/sbin/poweroff.no-molly-guard diversion by molly-guard from: /usr/sbin/poweroff diversion by molly-guard to: /usr/sbin/poweroff.no-molly-guard root@aranym:/var/cache/apt/archives # dpkg -S /usr/sbin/poweroff diversion by molly-guard from: /usr/sbin/poweroff diversion by molly-guard to: /usr/sbin/poweroff.no-molly-guard molly-guard, sysvinit-core: /usr/sbin/poweroff At this point, I thought this was somehow a bug in sysvinit-core, but… root@aranym:/var/cache/apt/archives # ll /usr/sbin/poweroff* lrwxrwxrwx 1 root root 30 Dec 22 22:23 /usr/sbin/poweroff -> ../lib/molly-guard/molly-guard* lrwxrwxrwx 1 root root 4 Feb 29 11:22 /usr/sbin/poweroff.no-molly-guard -> halt* root@aranym:/var/cache/apt/archives # less /usr/sbin/poweroff.no-molly-guard #!/bin/sh # # shutdown -- wrapper script to guard against accidental shutdowns […] ME=molly-guard […] … this shows pretty clearly who’s at fault here. The system was just converted to UsrMove in order to be able to install a newer kernel for upgrading. -- System Information: Debian Release: buster/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: m68k Kernel: Linux 4.19.0-4-m68k Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/lksh Init: sysvinit (via /sbin/init) Versions of packages molly-guard depends on: ii procps 2:3.3.15-2 molly-guard recommends no packages. molly-guard suggests no packages. -- no debconf information
Bug#1050429: [musl] musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'
>-%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem >include%s >+%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem >include%s %(old_cc1) Since old_cc1 includes cc1_cpu already, it can probably even be dropped. bye, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'
Hi musl maintainers, waldi indeed provided a fix for this bug forgot to Cc me, so I missed it until now. I tested this: (sid_mips64el-dchroot)tg@eberlin:~$ sh -x $(which musl-gcc) hello.c + exec mips64el-linux-gnuabi64-gcc hello.c -specs /usr/lib/mips64el-linux-musl/musl-gcc.specs mips64el-linux-gnuabi64-gcc: error: unrecognized command-line option '-EL' (sid_mips64el-dchroot)tg@eberlin:~$ mips64el-linux-gnuabi64-gcc hello.c -specs ~/musl-gcc.specs (sid_mips64el-dchroot)tg@eberlin:~$ ./a.out hi (sid_mips64el-dchroot)tg@eberlin:~$ diff -u /usr/lib/mips64el-linux-musl/musl-gcc.specs musl-gcc.specs --- /usr/lib/mips64el-linux-musl/musl-gcc.specs 2023-11-10 19:30:40.0 + +++ musl-gcc.specs 2024-02-03 08:07:01.309465472 + @@ -1,10 +1,11 @@ %rename cpp_options old_cpp_options +%rename cc1 old_cc1 *cpp_options: -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem include%s %(old_cpp_options) *cc1: -%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem include%s +%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem include%s %(old_cc1) *link_libgcc: -L/usr/lib/mips64el-linux-musl -L .%s This change (to tools/musl-gcc.specs.sh in the source tree) probably makes sense on all architectures, so perhaps do that even. Upstream should also consider including this and check which of the original specs need not be removed and can be kept like this. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1059040: libxml2: ABI change? (undefined references)
On Fri, 12 Jan 2024, Rafael Laboissière wrote: > experimental, the configure script does detect the absence of the > xmlNanoFTPNewCtxt function in the libxml2 library (version > 2.12.3+dfsg-0exp1) and disables the call to the xmlNanoFTP* functions. > However, this rebuilt will not be automatically triggered without a > bump in the SONAME version of libxml2. > > In summary, the introduction of version 2.12 of libxml2 in unstable > will need a proper and coordinated transition. No, this will still break partial upgrades. Losing symbols needs a major shlib version change *including*, in Debian, changing the binary package name so that the old and new shlibs are coïnstallable. And this needs to be exercised in experimental first, not only when introducing this to unstable. Alternatively, bring the symbols back. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1059040: libxml2: ABI change? (undefined references)
On Mon, 25 Dec 2023, Rene Engelhard wrote: > In any case, *this* bug is about the ABI change: removed symbols/versions > other > stuff relies on. > > Long story short: libxml2 2.12 has still a long road to go with much work on > your side until you can upload it to unstable. Sounds like it needs a solib major version and package name change for coïnstallability, upgrades, etc. *or* a fix that restores the prior ABI. Perhaps first ask upstream whether the removal was desired (and in which case they would do the version bump). bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1057550: cvs: FTBFS: FAIL: test-getdate.sh
tags 1057550 + pending thanks Santiago Vila dixit: > Hi. I think we can skip the ssh thing, as this one is easy > to diagnose: Missing Build-Depends on tzdata. > > Please use debootstrap from trixie/sid to reproduce. Details here: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060 Oh, indeed. TIL. A quick check on sid/main shows: grep-dctrl -FPriority required -a --not -FEssential yes -sPackage <… Package: apt Package: debconf Package: e2fsprogs Package: libpam-modules Package: libpam-modules-bin Package: libpam-runtime Package: mawk Package: mount Package: passwd Package: tzdata Out of these, apt, debconf, libpam* and (as in the bugreport) mawk are present but e2fsprogs, mount, passwd and tzdata are absent idd. I’ll upload. Thanks, //mirabilos -- 13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs 16:06⎜ Thank god I found you =) 20:03│«bioe007:#cvs» mira2k: ty 18:36⎜«ThunderChicken:#cvs» mirabilos FTW! 23:03⎜«mithraic:#cvs» aaah. thanks 18:50⎜«grndlvl:#cvs» thankyou18:50⎜«grndlvl:#cvs» worked perfectly
Bug#1055901: Acknowledgement (raspi-firmware: postinst fails, makes bad assumption about existence of /boot/firmware/)
Hi, this applies only to Raspian, not to Debian; in Debian, older releases used /boot/firmware as well. I suggest to go ask the Raspian people to fix what they broke. Mixing packages from other distributions (here Raspian) with Debian packages is not generally supported. bye, //mirabilos (not speaking for the maintainers of this package specifically)
Bug#1055484: libpam-elogind-compat has ineffective replaces for libpam-systemd due to /usr-merge
On Tue, 7 Nov 2023, Helmut Grohne wrote: >Do you know why Breaks+Replaces has been chosen here? Do you see any >issues with upgrading to Conflicts? Probably because lintian indicates that that should be the normal thing to do in such cases, and before UsrMove it was the working thing, too… bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1052942: insserv: FTBFS: insserv: Could not read script nolsbheader: No such file or directory
On Tue, 31 Oct 2023, Mark Hindley wrote: >As Ian pointed out[2], there are significant and surprising changes in looping >order and behaviour between the successful and failing testsuites. The diff is >attached. Could this be related to #989284 where we also haven’t figured out yet why this happens on that machine? Meow, //mirabilos -- Infrastrukturexperte • Qvest Digital AG Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 18196 • USt-ID (VAT): DE274355441 Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg Vorsitzender Aufsichtsrat: Peter Nöthen
Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in
On Thu, 21 Sep 2023, Markus Koschany wrote: >dependency problem between xrdp and xorgxrdp. If you claim that without a >rebuild of xorgxrdp a new upstream version of xrdp would be broken, then this >is a strong indication that xorgxrdp should be more than a recommendation in >Debian terms: No, just some kind of ABI thing, but I doubt xrdp upstream already even guarantees stable ABIs for 0.x releases. Probably something like the X server itself or Perl, where xrdp Provides xrdp-abi (= 0.9.21) and xorgxrdp Depends xrdp-abi (= 0.9.12) and therefore automatically needs a binNMU to get the newer one *and* lockstep upgrades are enforced by that. >From the Debian Policy "Declaring relationships between packages" > >"The Depends field should be used if the depended-on package is required for >the depending package to provide a significant amount of functionality." Yes. Not applicable here, xrdp does not need xorgxrdp to provide a significant part of use cases. xorgxrdp is a plugin that can be added to provide the third significant use case out of three, AIUI. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in
tags 1052197 + patch thanks On Wed, 20 Sep 2023, Thorsten Glaser wrote: >I’ll try binNMU’ing (locally) xorgxrdp, and if that doesn’t help, OK, that helped! It went fast. Installing the binNMU’d package xorgxrdp_0.2.12-1+b0.1_amd64.deb (and killing all /usr/lib/xorg/Xorg processes spawned from xrdp, visible by using :10 and higher as DISPLAY numbers) fixed this. So please ask someone (SRM, I believe) to schedule binNMUs of xorgxrdp for all oldstable architectures in oldstable. Thanks! bye, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"...
Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in
On Wed, 20 Sep 2023, Thorsten Glaser wrote: >Attached … and now with. //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-) buglogs.tgz Description: application/gtar-compressed
Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in
Hallo Markus, >the new Bullseye version of xrdp is identical to the version in Bookworm. Thus >the underlying problem is probably more complex and I don't suspect that >something is wrong with xrdp itself but more likely with a configuration option >or related software packages which do something different than in Bookworm. either that, or xorgxrdp must also be updated, or at least rebuilt against the newer xrdp? Maybe? >I definitely need more information about your setup or xrdp in general to debug I’ve now purged and reinstalled xrdp and xorgxrdp on the machine with… less “interesting” history, but the effect is still present. Selecting previously unselected package xrdp. (Reading database ... 210637 files and directories currently installed.) Preparing to unpack .../xrdp_0.9.21.1-1~deb11u1_amd64.deb ... Unpacking xrdp (0.9.21.1-1~deb11u1) ... Selecting previously unselected package xorgxrdp. Preparing to unpack .../xorgxrdp_1%3a0.2.12-1_amd64.deb ... Unpacking xorgxrdp (1:0.2.12-1) ... Setting up xrdp (0.9.21.1-1~deb11u1) ... Generating 2048 bit rsa key... ssl_gen_key_xrdp1 ok saving to /etc/xrdp/rsakeys.ini Starting Remote Desktop Protocol server: xrdp-sesman xrdp. Setting up xorgxrdp (1:0.2.12-1) ... >this issue. Possible reasons for the behavior may be: > >1. TLS / connection problem ? Did you do "adduser xrdp ssl-cert" ? Maybe a new >TLS configuration option in 0.9.21.1? The xrdp user is not in ssl-cert, but I never used those either. >2. graphic drivers ? I read that hardware accelerated drivers may cause such What graphic drivers? xrdp+xorgxrdp runs headlessly. >/var/log/xrdp-sesman.log >/var/log/xrdp.log >~/.xsession-errors Attached, and I’ll also add /.xorgxrdp.10.log ☻ >journalctl -S -2m That won’t do much other than say command not found ;-) I don’t know that thing but I assume you’ll want to see whether there’s anything relevant in syslog. Starting at package installation, there is: Sep 20 19:32:45 tglase-edge groupadd[16356]: group added to /etc/group: name=xrdp, GID=119 Sep 20 19:32:45 tglase-edge groupadd[16356]: group added to /etc/gshadow: name=xrdp Sep 20 19:32:45 tglase-edge groupadd[16356]: new group: name=xrdp, GID=119 Sep 20 19:32:45 tglase-edge useradd[16364]: new user: name=xrdp, UID=110, GID=119, home=/run/xrdp, shell=/usr/sbin/nologin, from=/dev/pts/2 Sep 20 19:32:45 tglase-edge chage[16375]: changed password expiry for xrdp Sep 20 19:32:46 tglase-edge xrdp-sesman[16502]: [INFO ] starting xrdp-sesman with pid 16502 Sep 20 19:32:46 tglase-edge xrdp[16504]: [INFO ] address [0.0.0.0] port [3389] mode 1 Sep 20 19:32:46 tglase-edge xrdp[16504]: [INFO ] listening to port 3389 on 0.0.0.0 Sep 20 19:32:46 tglase-edge xrdp[16504]: [INFO ] xrdp_listen_pp done Sep 20 19:32:48 tglase-edge xrdp[16506]: [INFO ] starting xrdp with pid 16506 Sep 20 19:32:49 tglase-edge xrdp[16506]: [INFO ] address [0.0.0.0] port [3389] mode 1 Sep 20 19:32:49 tglase-edge xrdp[16506]: [INFO ] listening to port 3389 on 0.0.0.0 Sep 20 19:32:49 tglase-edge xrdp[16506]: [INFO ] xrdp_listen_pp done Sep 20 19:32:54 tglase-edge xrdp-sesman[16502]: [INFO ] receiving SIGHUP Sep 20 19:32:54 tglase-edge xrdp-sesman[16502]: [INFO ] configuration reloaded, log subsystem restarted Sep 20 19:32:54 tglase-edge sudo: pam_unix(sudo:session): session closed for user root Sep 20 19:33:07 tglase-edge xrdp[16506]: [INFO ] Socket 12: AF_INET6 connection received from :::172.34.0.14 port 51122 Sep 20 19:33:07 tglase-edge xrdp[17463]: [INFO ] Using default X.509 certificate: /etc/xrdp/cert.pem Sep 20 19:33:08 tglase-edge xrdp[17463]: [INFO ] Using default X.509 key file: /etc/xrdp/key.pem Sep 20 19:33:08 tglase-edge xrdp[17463]: [ERROR] Cannot read private key file /etc/xrdp/key.pem: Permission denied Sep 20 19:33:08 tglase-edge xrdp[17463]: [WARN ] Cannot accept TLS connections because certificate or private key file is not readable. certificate file: [/etc/xrdp/cert.pem], private key file: [/etc/xrdp/key.pem] Sep 20 19:33:08 tglase-edge xrdp[17463]: [INFO ] Security protocol: configured [RDP], requested [SSL|HYBRID|RDP], selected [RDP] Sep 20 19:33:08 tglase-edge xrdp[17463]: [INFO ] Connected client computer name: x61w Sep 20 19:33:08 tglase-edge xrdp[17463]: [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x0409] Sep 20 19:33:08 tglase-edge xrdp[17463]: [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [us] options [] Sep 20 19:33:08 tglase-edge xrdp[17463]: [INFO ] Non-TLS connection established from :::172.34.0.14 port 51122: with security level : high Sep 20 19:33:08 tglase-edge xrdp[17463]: [INFO ] xrdp_caps_process_pointer: client supports new(color) cursor Sep 20 19:33:08 tglase-edge xrdp[17463]: [WARN ] Received [MS-RDPBCGR] TS_CONFIRM_ACTIVE_PDU - TS_CAPS_SET capabilitySetType = 27 is unknown - Ignored Sep 20 19:33:08 tglase-edge xrdp[17463]: [INFO ] Loading keymap file
Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in
On Tue, 19 Sep 2023, Thorsten Glaser wrote: >Then, to test it, I logged in, but all I get is a window with a turquoise >background, nothing on it. I *can* however see in ps(1) that my session >(IceWM, kwalletcli) is started; it’s just not transmitted to rdesktop. It also has funny messages in the ~/.xorgxrdp.10.log file: [1498607.917] rdpRRGetInfo: [1498608.022] rdpRRGetInfo: [1498608.075] rdpCapture: mode 65535 not implemented [1498608.075] rdpCapRect: rdpCapture failed On another system, the screen gets mostly black after login, with a small turquoise strip (see attached screenshot), and its logfile has other funny messages: [1494040.566] rdpCapture1: unimplemented color conversion I’ve used both systems actively till date. bye, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜ also warum machen die xorg Jungs eigentlich alles kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…
Bug#1052197: xrdp: after bullseye-security upgrade, empty turquoise screen after logging in
Package: xrdp Version: 0.9.21.1-1~deb11u1 Severity: serious Justification: does not work X-Debbugs-Cc: t...@mirbsd.de, t...@security.debian.org I’ve just upgraded the xrdp package. I had made sure to terminate the old service before the new version is started. Then, to test it, I logged in, but all I get is a window with a turquoise background, nothing on it. I *can* however see in ps(1) that my session (IceWM, kwalletcli) is started; it’s just not transmitted to rdesktop. -- System Information: Debian Release: 11.7 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldoldstable-updates'), (500, 'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-25-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages xrdp depends on: ii adduser 3.118+deb11u1 ii init-system-helpers 1.60 ii libc62.31-13+deb11u6 ii libfuse2 2.9.9-5 ii libjpeg62-turbo 1:2.0.6-4 ii libopus0 1.3.1-0.1 ii libpam0g 1.4.0-9+deb11u1 ii libssl1.11.1.1w-0~deb11u1 ii libx11-6 2:1.7.2-1+deb11u1 ii libxfixes3 1:5.0.3-2 ii libxrandr2 2:1.5.1-1 ii lsb-base 11.1.0 ii ssl-cert 1.1.0+nmu1 Versions of packages xrdp recommends: ii fuse 2.9.9-5 ii xorgxrdp 1:0.2.15-1 Versions of packages xrdp suggests: pn guacamole Versions of packages xorgxrdp depends on: ii libc6 2.31-13+deb11u6 ii libepoxy0 1.5.5-1 pn xorg-input-abi-24 ii xserver-xorg-core [xorg-video-abi-24] 2:1.20.11-1+deb11u6 Versions of packages xorgxrdp recommends: pn xorg Versions of packages xrdp is related to: ii tightvncserver [vnc-server] 1:1.3.10-3 ii xserver-xorg-legacy 2:1.20.11-1+deb11u6 -- no debconf information
Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'
reassign 1050429 gcc-13 13.2.0-2
notfound 1050429 12.3.0-8
affects 1050429 musl-tools
thanks
Dixi quod…
>The -EL is not even musl-specific?!
>
>(sid_mips64el-dchroot)tg@eller:~$ cat
>"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
[…]
Worse, doing mips64el-linux-gnuabi64-gcc{,-12} -dumpspecs and
diffing the result, there’s no change regarding -EL either.
This looks like a genuine GCC bug? I’m reassigning.
bye,
//mirabilos
--
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'
Dixi quod…
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -EL
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -specs
>"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
>mips64el-linux-gnuabi64-gcc: error: unrecognized command-line option '-EL'
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc-12 hi.c -EL
>(sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc-12 hi.c -specs
>"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
>(sid_mips64el-dchroot)tg@eller:~$ _
>
>… but a regression (?) in GCC 13 versus GCC 12.
The -EL is not even musl-specific?!
(sid_mips64el-dchroot)tg@eller:~$ cat
"/usr/lib/mips64el-linux-musl/musl-gcc.specs"
%rename cpp_options old_cpp_options
*cpp_options:
-nostdinc -isystem /usr/include/mips64el-linux-musl -isystem include%s
%(old_cpp_options)
*cc1:
%(cc1_cpu) -nostdinc -isystem /usr/include/mips64el-linux-musl -isystem
include%s
*link_libgcc:
-L/usr/lib/mips64el-linux-musl -L .%s
*libgcc:
libgcc.a%s %:if-exists(libgcc_eh.a%s)
*startfile:
%{!shared: /usr/lib/mips64el-linux-musl/Scrt1.o}
/usr/lib/mips64el-linux-musl/crti.o crtbeginS.o%s
*endfile:
crtendS.o%s /usr/lib/mips64el-linux-musl/crtn.o
*link:
-dynamic-linker /lib/ld-musl-mips64el.so.1 -nostdlib %{shared:-shared}
%{static:-static} %{rdynamic:-export-dynamic}
*esp_link:
*esp_options:
*esp_cpp_options:
(sid_mips64el-dchroot)tg@eller:~$ _
There’s no -EL in that file‽ So apparently GCC 13 is breaking of itself?
bye,
//mirabilos
--
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'
Dixi quod… >According to upstream documentation, -EL is supposed to be supported >by the compiler driver: OK so it’s not the compiler *driver*… (sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -EL (sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc hi.c -specs "/usr/lib/mips64el-linux-musl/musl-gcc.specs" mips64el-linux-gnuabi64-gcc: error: unrecognized command-line option '-EL' (sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc-12 hi.c -EL (sid_mips64el-dchroot)tg@eller:~$ mips64el-linux-gnuabi64-gcc-12 hi.c -specs "/usr/lib/mips64el-linux-musl/musl-gcc.specs" (sid_mips64el-dchroot)tg@eller:~$ _ … but a regression (?) in GCC 13 versus GCC 12. bye, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜ also warum machen die xorg Jungs eigentlich alles kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…
Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'
Hm. According to upstream documentation, -EL is supposed to be supported by the compiler driver: https://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999
Bug#1050429: musl: unusable on mipsel, mips64el: mipsel-linux-gnu-gcc: unrecognised command-line option '-EL'
Package: musl-tools Version: 1.2.3-1 Severity: serious Justification: unusable on release architectures X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org Control: affects -1 src:mksh Unsure if it’s musl or gcc-13_13.2.0-2 but building a simple test program fails on both mips64el and mipsel: $ musl-gcc […] -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -static conftest.c mipsel-linux-gnu-gcc: error: unrecognized command-line option '-EL' If doing 'gcc -v' (normal gcc, not musl-gcc wrapper) the -EL shows up in: COLLECT_GCC_OPTIONS='-g' '-O2' '-ffile-prefix-map=/<>=.' '-fstack-protector-strong' '-Wformat=1' '-Werror=format-security' '-Wall' '-Wextra' '-I' '.' '-I' '../..' '-Wdate-time' '-D' '_FORTIFY_SOURCE=2' '-D' 'MKSH_EARLY_LOCALE_TRACKING' '-D' 'KSH_VERSIONNAME_VENDOR_EXT=" +Debian"' '-D' 'MKSH_BUILDMEAT' '-D' 'MKSH_BUILDSH=1' '-D' '_GNU_SOURCE' '-D' 'SETUID_CAN_FAIL_WITH_EAGAIN=1' '-v' '-march=mips32r2' '-mfpxx' '-mllsc' '-mno-lxc1-sxc1' '-mno-madd4' '-mips32r2' '-EL' '-mabi=32' '-dumpdir' 'a-' musl-gcc uses mipsel-linux-gnu-gcc (or mips64el-linux-gnuabi64-gcc) instead of gcc, but it’s still Debian 13.2.0-2 according to --version.
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
James Addison dixit: >AssertionError [ERR_ASSERTION]: The input did not match the regular > expression /RangeError: Maximum call stack size exceeded/. Input: > >'Segmentation fault\n' You removed the subtraction of V8_STACK_RESERVE when mutilating my patch; this may be related (if it still appears with, raise the constant). You also removed the integer safety check (the comparison with 2³¹-1). Don’t. bye, //mirabilos -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
James Addison dixit:
>... to add something like this:
Ouch, by going via a string?! I wouldn’t have thought of that…
> if (!(flags & ProcessInitializationFlags::kNoAdjustResourceLimits)) {
>struct rlimit lim;
>if (getrlimit(RLIMIT_STACK, ) == 0) {
> char stackSize[32];
32 is magic and may also be wrong here.
> int buflen = snprintf(stackSize, sizeof(stackSize),
>"--stack-size=%d", lim.rlim_cur);
%d isn’t right for lim.rlim_cur, which is of type rlim_t.
--stack-size seems to take in KiB, and we’d want a reserve.
> if (buflen < sizeof(stackSize)) {
>V8::SetFlagsFromString(stackSize, buflen);
> }
>}
> }
So, taking your next post into account, probably something more
like this:
#define V8_STACK_RESERVE 128
if (!(flags & ProcessInitializationFlags::kNoAdjustResourceLimits)) {
struct rlimit lim;
char stackSize[sizeof("--stack-size=") + /* 2³¹ */ 10];
if (getrlimit(RLIMIT_STACK, ))
fprintf(stderr, "W: stack size adjustment: cannot get
RLIMIT_STACK\n");
else if (lim.rlim_cur == RLIM_INFINITY)
fprintf(stderr, "W: stack size adjustment: RLIMIT_STACK is
unlimited\n");
else if ((lim.rlim_cur /= 1024) <= V8_STACK_RESERVE)
fprintf(stderr, "W: stack size adjustment: RLIMIT_STACK is too
small\n");
else if ((lim.rlim_cur -= V8_STACK_RESERVE) >= /* 2³¹ */ 2147483647)
fprintf(stderr, "W: stack size adjustment: RLIMIT_STACK is too
large\n");
else
V8::SetFlagsFromString(stackSize, snprintf(stackSize,
sizeof(stackSize),
"--stack-size=%d", (int)lim.rlim_cur));
}
Untested, still not back to full health, take with grains of salt.
bye,
//mirabilos
--
In traditional syntax ' is ignored, but in c99 everything between two ' is
handled as character constant. Therefore you cannot use ' in a preproces-
sing file in c99 mode. -- Ragge
No faith left in ISO C99, undefined behaviour, etc.
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
James Addison dixit: >I'm going to stay involved with this thread, but I think that it is >upon you to develop or provide further guidance towards a patch if >it's something you'd like to have implemented, Thorsten. I actually have looked into that but I don’t understand the nodejs and v8 source code enough to be able. I know C, but not CFrustFrust. I would rather prefer asm… bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
James Addison dixit: >So: a fix here won't achieve stack capacity equality across No. The fix you proposed won’t achieve that but others would improve the situation much more, so that equality across arches won’t need to matter any more. >Or, to put it another way: applying an increase (either static or >dynamic, either ARM-specific or across all architectures) for stack >size determination would move the problem, and another architecture >would take the place of "architecture where RangeError can occur in >code x that doesn't occur on other architectures". Yes, but given the usual ulimit, the new limit would be 4+ times the old one, much much harder to reach. >it, though - and based on their current policy, NodeJS upstream seem >unlikely to accept it since they don't want to modify their vendored >V8. AIUI that’s not necessary because you can already set the stack limit with a nodejs command line option. The patch could just set the limit, using the same facility that CLI option uses, if that option isn’t given (or before it is processed). bye, //mirabilos -- (gnutls can also be used, but if you are compiling lynx for your own use, there is no reason to consider using that package) -- Thomas E. Dickey on the Lynx mailing list, about OpenSSL
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
James Addison dixit: >On Thu, 11 May 2023 at 02:43, Andres Salomon wrote: >> For ARM64, he says that raising the stack limit is not safe for v8 >> *embedded inside WebView*, and therefore not appropriate for upstream >> v8. But then he says it could/should be safe for v8 *embedded inside >> NodeJS*. >> >> Based on that, I suggest patching Debian's NodeJS with the patch to >> adjust armhf/arm64 stack limit size That would be a good thing (huh, wasn’t armhf good?), but… >I have a question: if we apply the patch and begin using the same >constant stack size of 984kb on 32-bit ARM and 64-bit ARM as is >defined for other architectures, then does NodeJS on those platforms >begin supporting exactly the same stack frame capacity (maximum call >depth for any given recursive function, for example) as a build of the >same NodeJS source on x86 and amd64 respectively? … no, because both stack usage and other stuff on stack differ. Which is why I’d rather have the getrlimit-based one for nodejs. That would give us twice to four times the limit. >> (As chromium maintainer, which also embeds v8, I haven't heard of any >> issues and hadn't planned on touching stacks limits. It sure would be Yes, yes, definitely don’t change it outside of nodejs. >> javascript code that is triggering this bug should really be fixed to >> not be so stack-intensive, of course. Perhaps this bug cloned at a >> lower severity, filed against those packages that this bug is affecting? That’s got a dependency chain so long that don’t hold your breath for ALL those to be changed is true. Besides, how would the respective maintainers be aware of this in the first place? Short of failing with an arbitrary nesting limit on all arches, in upstream nodejs, I doubt you’d get half of the upstream code maintainers to care… if they even care about their code any more at all. I am not a friend of such limits either, in addition. bye, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#1034059: marked as pending in zstd-jni-java
On Sun, 9 Apr 2023, Markus Koschany wrote: >maven-compiler-plugin. Usually this just works without changes to the version >number. I don't think a strict plugin dependency is the true solution but it >might help future contributors to remember the RC bug. Also not a real fix but more sustainable might be to just always do an indep build when also doing an archdep build, as that apparently does not have this bug? bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
James Addison dixit: >Based on what I've learned about this bug, I believe that architecture-specific >behaviour related to stack sizes is inherent in the V8 library vendored by >upstream NodeJS. Yes, but the v8 library’s defaults are targetting a browser, and one whose uses are much wider, e.g. inside Android, than NodeJS’s itself. Which is why I believe that NodeJS very much can and certainly should fix this by setting suitable limits. >long time. Individual codebases such as the affected 'src:dygraphs' package >can also be improved to reduce the likelihood of call stack size overflow. It’s babel7 actually which runs into this. And I believe that, rather to the contrary, further evolution of software-written-in-NodeJS will let this error show up *more* and probably on nōn-arm64 as well(!), so I’d rather have NodeJS set proper limits instead of sticking to v8’s given the latter has a different scope and run-time environment than the former. >Given those, and the absence of any sense that this is a regression, I think we >should lower the priority of this bug to below release-critical. I very much disagree, this breaks arch:all packages on some platforms so it causes issues packagers who don’t themselves use arm64 cannot discover in the first place. We need to at least achieve architecture partity in Debian, pending better upstream fixes. bye, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml
Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Jérémy Lal dixit: >I can build nodejs on amhdal.debian.org if you're not comfortable with that. The problem with the DSA porterboxen is that you cannot install your own built packages in the chroot to use them there… unless there’s a solution not yet known to me? bye, //mirabilos -- “ah that reminds me, thanks for the stellar entertainment that you and certain other people provide on the Debian mailing lists │ sole reason I subscribed to them (I'm not using Debian anywhere) is the entertainment factor │ Debian does not strike me as a place for good humour, much less German admin-style humour”
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
James Addison dixit: >Hi - what do you both think of the attached patch, which brings the ARM stack >size into line with almost all other architectures (= 984 KB)? It might do the job unless arm64 for some reason uses more stack elsewhere as well. Can you test it? I don’t have the bandwidth for that right now… Thanks, //mirabilos -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
James Addison dixit: >Maybe it's rare to propose 'do nothing' as a technical suggestion but I think >it is worth considering here, since we are not the arbiters of Node. It’s still a release-critical bug in Debian which impacts arm64 builders including reproducible-builds. I would see this fixed in bookworm, at least by a band-aid (raising these limits by default); the proper fix can be revisited after the release, and in coordination with upstream. We know the default ulimits for users in Debian, and they are higher than the 1 MiB assumed by v8, by quite some factor, so this won’t break things which are not currently broken (by that exception). This will do for the release I think. If a proper, upstream-supported, fix arrives within $time it’s even possible that a bookworm-security update includes that. Still thinking along the line of getrlimit + subtract known arch-specific value for the fix here, whatever makes sense with the v8 setting anyway… bye, //mirabilos -- Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~ (as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Hi James,
(you might wish to Cc <${bugnumber}-submit...@bugs.debian.org> so they
actually get the reply…)
>Are you able to determine whether https://github.com/nodejs/node/issues/41163
>(and/or any of the guidance within that thread) seems relevant to this bug?
It appears so. I commented there, thank you for finding that link.
I guess there is even a… quick patch… to make from this. I admit
I’m very confused by that statement:
“if you set it too high, you risk crashes”
That can’t be right.
Searching through the nodejs source for where this stack size is
set, I see multiple time bombs for all architectures.
deps/v8/src/common/globals.h does set the default stack size to
864/984 KiB in order to achieve an about 1 MiB stack for JS plus
C++ parts combined.
I wonder if this shouldn’t be getrlimit(RLIMIT_STACK) - overhead,
and then define the per-architecture overhead in a suitable way.
That lower 1 MiB total limit seems to be for Windows. The lower
arm64 limit is caused by “allocating MacroAssembler takes 120 [KiB]”
but the total could still be raised I think… at least on unixoid
platforms other than WebView-on-Android. Since the location of these
defaults is in v8, it also applies for browsers and whatnot, but
nodejs could indeed inspect the current ulimit and set a better
default for at least nōn-Windows systems.
I’m not, unfortunately, in the position to provide a quick patch,
being a C developer, not CFrustFrust, and all that. I think that
InitializeNodeWithArgs in src/node.cc, which already has a call
to V8::SetFlagsFromString(NODE_V8_OPTIONS, …), is the likely place
for adding code (suitably platform-ifdef’d) that does:
- get the ulimit
- subtract some arch-specific overhead target
- check that that’s positive (or >= V8_DEFAULT_STACK_SIZE_KB even,
that might be a good idea)
- if so, pass this as synthetic --stack-size (or --stack_size?) to
v8, overriding its default but allowing for a later option given
by the user’s argv[] to override _that_, again
Might need to adjust some tests, too :~
Good luck,
//mirabilos
--
exceptions: a truly awful implementation of quite a nice idea.
just about the worst way you could do something like that, afaic.
it's like anti-design. that too… may I quote you on that?
sure, tho i doubt anyone will listen ;)
Bug#1028375: Accepted xz-utils 5.4.1-0.1 (source) into unstable
Sebastian Andrzej Siewior dixit: >How is this getting to work without manpages-fr contributing to it? By adding a conflict (can’t remember if it has to be Conflicts or Breaks will also work) plus Replaces on manpages-fr (<< 4.17.0-2~bpo11+1) on xz-utils in bookworm. (And the others similarily.) Which is, kinda, what I wrote before. And no, you cannot rely on people upgrading within bpo first, especially as bpo repository signatures expire YEARS before the lifetime of the base release. bye, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#1028375: Accepted xz-utils 5.4.1-0.1 (source) into unstable
Sebastian Andrzej Siewior dixit: >Good. So unless Thorsten disagrees this is done ;) Please also test the upgrade with 4.16.0-1~bpo11+1 installed on bullseye instead of 4.17.0-2~bpo11+1 (since that is a valid upgrade path), without going via 4.17.0-2~bpo11+1. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1030673: klibc: [mips64el] struct stat mismatch
Source: klibc
Version: 2.0.11-1
Severity: serious
Justification: ABI issue on release architecture
Tags: patch
On 64-bit MIPS platforms, struct stat’s members st_{a,m,c}time{,nsec}
and following (st_blksize, st_blocks) are mislayouted. Upstream git
commit 12f259dda1ef59b5f1f2fb67631dcbf94c18c56c fixes this issue, but
I believe this should be in Debian ASAP, as it affects multiple klibc
tools as well as other software (mksh’s regression tests catch this
in bookworm/sid now).
Maybe it’s time for 2.0.12?
Thanks in advance,
//mirabilos
--
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded
Package: nodejs Version: 18.13.0+dfsg1-1 Severity: serious Tags: upstream Justification: breaks on release architecture X-Debbugs-Cc: t...@mirbsd.de Control: affects -1 src:dygraphs During reproducible-builds testing, I found that one of my packages, the one with nodejs used during build, worked on amd64 (which the arch:all packages are built on), i386, armhf(!) but not on arm64. Testing on the porterbox reveals that indeed nodejs fails there. To reproduce, easiest way: $ apt-get source dygraphs # = 2.2.0-4 $ cd dygraphs-2.2.0 $ babeljs --config-file $PWD/babel.config.json --compact false --source-maps inline -d tests5 auto_tests Omitting --compact false and --source-maps inline can also be done, the bug is triggered nevertheless: RangeError: Maximum call stack size exceeded at NodePath.getScope (/usr/share/nodejs/@babel/traverse/lib/path/index.js:84:11) at NodePath.setScope (/usr/share/nodejs/@babel/traverse/lib/path/context.js:115:21) at NodePath.setContext (/usr/share/nodejs/@babel/traverse/lib/path/context.js:128:8) at NodePath.pushContext (/usr/share/nodejs/@babel/traverse/lib/path/context.js:183:8) at TraversalContext.visitQueue (/usr/share/nodejs/@babel/traverse/lib/context.js:78:14) at TraversalContext.visitSingle (/usr/share/nodejs/@babel/traverse/lib/context.js:65:19) at TraversalContext.visit (/usr/share/nodejs/@babel/traverse/lib/context.js:109:19) at traverseNode (/usr/share/nodejs/@babel/traverse/lib/traverse-node.js:18:17) at NodePath.visit (/usr/share/nodejs/@babel/traverse/lib/path/context.js:86:52) at TraversalContext.visitQueue (/usr/share/nodejs/@babel/traverse/lib/context.js:86:16) There are numerous references to nodejs failing in this way on arm64 platforms, normal Linux but even on Android as well, on the internet; h01ger said several other nodejs-using packages FTBFS on arm64 in the same way during reproducible-builds testing. I consider this an architecture-specific release-critical bug. Maybe having a reproducer and access to a porterbox will allow a nodejs maintainer to track this down. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') merged-usr: no Architecture: arm64 (aarch64) Kernel: Linux 5.10.0-21-arm64 (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages nodejs depends on: ii libc6 2.36-8 ii libnode108 18.13.0+dfsg1-1 Versions of packages nodejs recommends: ii ca-certificates 20211016 pn nodejs-doc Versions of packages nodejs suggests: pn npm -- no debconf information
Bug#1028375: Accepted xz-utils 5.4.1-0.1 (source) into unstable
Debian FTP Masters dixit: >Changed-By: Sebastian Andrzej Siewior >Changes: > xz-utils (5.4.1-0.1) unstable; urgency=medium > . > * Non-maintainer upload. > * Update pt_BR translations. > * Add lintian overrides and an override for blhc. This is missing the updated Breaks+Replaces for manpages-l10n though. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Helge Kreutzmann dixit:
>> >odler than stable. It also shipped them in every backport until
>> >4.16.0-3~bpo11+1. It is also in the upcoming 4.17.0-2~bpo11+1.
>> >
>> >But I wonder if I should remove them there.
>>
>> Yes, please. Otherwise it’s impossible to do the package
>Done in the upcoming 4.17.0-2~bpo11+1.
>
>For the three languages where we have a conflict, namely, de, fr and
>uk.
Okay. So, assuming no newer version of manpages-{de,fr,uk} will
bring them in, in either bpo or bookworm/sid, xz-utils now needs
Replaces+Breaks on manpages-{de,fr,uk} (<< 4.17.0-2~bpo11+1) in sid.
(Also assuming 4.17.0-2 does not have them.)
That is, from the xz-utils PoV 4.17.0-2~bpo11+1 and 4.17.0-2
are the first “fixed” (as in, don’t ship conflicting files)
versions and all later ones will not “regress”.
bye,
//mirabilos
--
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Helge Kreutzmann dixit: >odler than stable. It also shipped them in every backport until >4.16.0-3~bpo11+1. It is also in the upcoming 4.17.0-2~bpo11+1. > >But I wonder if I should remove them there. Yes, please. Otherwise it’s impossible to do the package relationships right. This will leave users of xz-utils from stable with manpages-fr from backports without french xz manpages, but it’s the only way to do this that doesn’t cause worse trouble elsewhere. Otherwise, xz-utils will have to add a conflict with 4.17.0-2 *in bookworm/sid*, and that will also carry to the next xz-utils backport (if any) *and* it’ll require an xz-utils upload *in bookworm/sid* for every manpages-fr upload to bpo. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1030000: fontconfig: after upgrade from 2.13.1-4.5 to 2.14.1-3 subpixel is enabled
Hi Andreas, a bit out of order, but easier to respond (I’m a bit under the weather so excuse any issues ahead of time): >By 'disabled' I assume you mean 'Never', right? Uhm, short walkthrough: • Native • Full • Never • Yes >Did it also create 10-no-sub-pixel.conf ? (sid-amd64)root@tglase:/etc # git status On branch master nothing to commit, working tree clean (sid-amd64)root@tglase:/etc # ll fonts/conf.d/10* lrwxrwxrwx 1 root root 53 Jan 31 21:25 fonts/conf.d/10-hinting-full.conf -> /usr/share/fontconfig/conf.avail/10-hinting-full.conf lrwxrwxrwx 1 root root 53 Jan 31 21:25 fonts/conf.d/10-no-sub-pixel.conf -> /usr/share/fontconfig/conf.avail/10-no-sub-pixel.conf lrwxrwxrwx 1 root root 54 Jan 13 21:30 fonts/conf.d/10-yes-antialias.conf -> /usr/share/fontconfig/conf.avail/10-yes-antialias.conf >Have you experienced this problem in previous upgrades? Unsure. My main system runs bullseye now to avoid UsrMove, and this is a sid/amd64 chroot. Maybe. >Can you reproduce the problem at all? Let’s see ☻ (sid-amd64)root@tglase:/etc # dpkg -i /var/cache/apt/archives/fontconfig-config_2.14.1-3_amd64.deb (Reading database ... 330670 files and directories currently installed.) Preparing to unpack .../fontconfig-config_2.14.1-3_amd64.deb ... Unpacking fontconfig-config (2.14.1-3) over (2.14.1-3) ... Setting up fontconfig-config (2.14.1-3) ... Processing triggers for man-db (2.11.2-1) ... (sid-amd64)root@tglase:/etc # git status On branch master Untracked files: (use "git add ..." to include in what will be committed) fonts/conf.d/10-sub-pixel-rgb.conf nothing added to commit but untracked files present (use "git add" to track) So, yes, I can easily reproduce it *and* I end up with *both* 10-no-sub-pixel.conf and 10-sub-pixel-rgb.conf symlinked (ouch). Now here it comes: (sid-amd64)root@tglase:/etc # rm fonts/conf.d/10-sub-pixel-rgb.conf (sid-amd64)root@tglase:/etc # DPKG_MAINTSCRIPT_PACKAGE=fontconfig-config DPKG_MAINTSCRIPT_NAME=postinst sh /var/lib/dpkg/info/fontconfig-config.postinst configure 2.14.1-3 (sid-amd64)root@tglase:/etc # git status On branch master nothing to commit, working tree clean It’s not the postinst alone… (sid-amd64)root@tglase:/etc # DPKG_MAINTSCRIPT_PACKAGE=fontconfig-config DPKG_MAINTSCRIPT_NAME=prerm sh /var/lib/dpkg/info/fontconfig-config.prerm upgrade 2.14.1-3 (sid-amd64)root@tglase:/etc # DPKG_MAINTSCRIPT_PACKAGE=fontconfig-config DPKG_MAINTSCRIPT_NAME=preinst sh /var/lib/dpkg/info/fontconfig-config.preinst upgrade 2.14.1-3 2.14.1-3 It’s also not them, unless I’m calling them wrong? I have another hunch: /var/cache/apt/archives/fontconfig-config_2.14.1-3_amd64.deb/deb://CONTENTS/etc/fonts/conf.d/10-sub-pixel-rgb.conf exists. And indeed, that’s it. While the symlink is shipped in /etc, it is not listed in /var/cache/apt/archives/fontconfig-config_2.14.1-3_amd64.deb/deb://DEBIAN/conffiles and therefore not handled as conffile by dpkg but as regular file that is always extracted when extracting the package, overwriting what was there. (I’m not sure what Policy says to conffile handling for symlinks; I vaguely recall that at some point post etch or so, conffile handling was changed in Policy to mandate inclusion of anything under /etc but I might mis‐ remember that.) This will have to be today’s feedback from me, sorry. Good luck, //mirabilos -- exceptions: a truly awful implementation of quite a nice idea. just about the worst way you could do something like that, afaic. it's like anti-design. that too… may I quote you on that? sure, tho i doubt anyone will listen ;)
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Sebastian Andrzej Siewior dixit: >It is bpo but if you look I'd you look at the files for the same >version in bpo and sid you will see that sid skipped a few man pages >while bpo created them. Ouch! That adds to the problems, of course. That makes fully resolving this in all possible combinations a nightmare. In general, these have to go: stable → next-stable stable → stable+backports stable+backports → next-stable stable+backports → stable+backports+backports-sloppy stable+backports+backports-sloppy → next-stable+backports stable → testing (at any point) stable → unstable (at any point) testing → testing (at any point) testing → unstable (at any point) unstable → unstable (at any point) testing (at any point) → next-stable stable+backports → testing (at any point) stable+backports → unstable (at any point) In addition, partial upgrades that do not span more than a release either way need to work (so you could have, say, manpages-fr from buster and xz-utils from sid(before the bookworm release), or vice versa, on one single bullseye system). Explicit Depends are needed to make all these either work or the package manager not consider them (which forces upgrading a part of the system to match). In addition, Build-Depends need versioning unless present in stable, better oldstable, because buildds are not required to upgrade (only update) before a run, plus packages can be lagging on some architectures. Now backports take from testing at the point of backporting. If the backported packages significantly differ from the package in testing, however, combinatory explosion, as the above holds true for every single package… In particular, I’ve personally held back from backporting packages when I know I had versioned constraints on the package in question but backporting would require bringing the old behaviour back (i.e. the backported package needs to behave like the new one, not the old one, and if that’s not possible in the old distro, then don’t package it). I see why this would be a problem for manpages… but you cannot re-enable manpages in bpo that aren’t in testing meaningfully when there’s also a backport of the package from testing that includes the manpage (and you cannot meaningfully drop the manpage from the backport because then the package relationships aren’t possible any more). Good luck, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Sebastian Andrzej Siewior dixit: >Then I will update the versions as suggested. My understanding was the >problem persists because the bpo version was not yet updated. The >version in sid did not ship the man-pages. The bpo version was once in both sid and testing and this is therefore a problem for people updating incrementally. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Sebastian Andrzej Siewior dixit: >Okay. So I do nothing and just wait for the bpo package to appear which >will then solve the problem? No, you must fix the problem in xz-utils in bookworm/sid as well. It also exists outside of backports. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Helge Kreutzmann dixit: >The problem is that we both upload (conflicting) packages to >backports. I'm not sure a good solution exists here. No, you need to fix the package relationships for incremental and partial upgrades in sid anyway. As far as I can tell, manpages-fr had the first version of xz-utils that ships the pages in its Breaks+Replaces, but xz-utils’ Breaks+Replaces did not cover all versions of manpages-fr that also shipped the pages. bye, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
Sebastian Andrzej Siewior dixit: >> As far as I can tell it must be (<< 4.17.0-1~) instead. >> (Also do note the tilde, it breaks bpo otherwise.) > >Okay. So I add this new suggested version and close 1028375? I think so. 4.17.0-1 was the first version of -fr to not ship it any more (from reading its changelog), and the tilde is to permit 4.17.0-1~bpo* to match. It’d need to update both Breaks and Replaces. (I hope I got this right, too ☺) bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1028375: still conflicting with manpages-fr 4.16.0-3~bpo11+1
reopen 1028375 found 1028375 5.4.1-0.0 thanks Patrice Duroux dixit: >Was this supposed to be closed? Or will it be with another manpages-fr bpo? 5.4.1-0.0 only conflicts with manpages-fr (<< 4.1.0-1) so the upload did not fix the problem. As far as I can tell it must be (<< 4.17.0-1~) instead. (Also do note the tilde, it breaks bpo otherwise.) This is not only needed for bpo but also for incremental updates within sid. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1030000: fontconfig: after upgrade from 2.13.1-4.5 to 2.14.1-3 subpixel is enabled
Package: fontconfig Version: 2.14.1-3 Severity: serious Justification: Policy 10.7.3 X-Debbugs-Cc: t...@mirbsd.de > * local changes must be preserved during a package upgrade, and After an upgrade, etckeeper reports that /etc/fonts/conf.d/10-sub-pixel-rgb.conf shows up again, despite the local admin choice to not have blurry fonts. Running dpkg-reconfigure -plow fontconfig-config shows that the debconf database correctly remembers the admin-provided setting (subpixel disabled was pre-selected), and just pressing Enter on every question makes it remove that file, so I believe that some maintainer script errorneously forcibly creates that file overriding local configuration. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages fontconfig depends on: ii fontconfig-config 2.14.1-3 ii libc6 2.36-8 ii libfontconfig1 2.14.1-3 ii libfreetype6 2.12.1+dfsg-4 fontconfig recommends no packages. fontconfig suggests no packages. -- no debconf information
Bug#1026002: FTBFS gcc: error: LinuxMachineDefines: linker input file not found: No such file or directory
# this is for a nōn-release architecture severity 1026002 important # this is a bug in the imake buildsystem, not xlax which merely uses it reassign 1026002 xutils-dev retitle 1026002 xutils-dev: imake support for riscv64 vanished? affects 1026002 src:xlax thanks sun min dixit: >xlax failed to build from source for architecture riscv64,it complains: >gcc: warning: LinuxMachineDefines: linker input file unused because linking >not done >gcc: error: LinuxMachineDefines: linker input file not found: No such file or >directory This is something done by imake, which is in the xutils-dev package, it merely affects all packages that use imake for building. Please take this up with the xutils-dev maintainers but ideally, first figure out which versions worked and which stopped to work. Thanks, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜ also warum machen die xorg Jungs eigentlich alles kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…
Bug#1017760: linux-image-5.10.0-17-amd64: No space for directory leaf checksum. Please run e2fsck -D.
severity 1017760 normal retitle 1017760 linux: possible data corruption on µSD card, might be the hardware though? thanks Dixi quod… >I have somewhat reason to at least suspect the µSD card this was >installed on. But there was never anything in syslog/dmesg about >it, so the Linux kernel clearly didn’t find fault with it at all. I now have reasonable reason to suspect not the µSD card itself, or, at least, not alone, but the µSD-to-SD adapter. One noname behaved even worse, a different brand to the original one seems to behave better. >Suggestions how I can prove/disprove this welcome; I now swapped Still that. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#930247: bug#36148: Debian Bug#930247: grep: does not handle backreferences correctly, violating POSIX
Paul Eggert dixit: > Although you sent your email to 36...@debbugs.gnu.org / > 930247@bugs.debian.9org, your email is reporting a separate bug Oh OK, I wasn’t aware, it sounded similar enough. > I fixed it in the development version of GNU grep by installing the > attached patch. This patch should appear in the next GNU grep release. Thank you! bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999
Bug#1025229: mksh: flaky autopkgtest on several architectures
Hi Paul, > I looked at the results of the autopkgtest of your package. I noticed that it > regularly fails. Also the failures on arm64 seem consistent now in testing > (but > it has a pass in unstable). thanks for bringing this to my attention. This is a bug in the autopkgtest script in that it doesn’t take those tests whose failure should be ignored into account, combined with these tests failing much more than they used to on build infrastructure (for which I *still* have not been able to find the underlying reason). I’ll fix the scripts (and the repro-builds issue) and upload RSN, to ignore the allowed failures. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1024727: firefox-esr: does not support IPv6
Mike Hommey dixit: >> >Try removing that %eth0 from the ipv6 address. >> >> That would invalidate said address and is therefore impossible. > >Why would it? Is your setup so complex that the network stack can't find >the right interface to send packets through? It’s a link-local address. These do by definition need the interface specified because they aren’t global. Please do read up on IPv6 basics when commenting on IPv6 specifics… bye, //mirabilos -- 21:12⎜ sogar bei opensolaris haben die von der community so ziemlich jeden mist eingebaut │ man sollte unices nich so machen das desktopuser zuviel intresse kriegen │ das macht die code base kaputt 21:13⎜ linux war früher auch mal besser :D
Bug#1024727: firefox-esr: does not support IPv6
Mike Hommey dixit:
>Try removing that %eth0 from the ipv6 address.
That would invalidate said address and is therefore impossible.
It works in lynx, if knowing that helps.
bye,
//mirabilos
--
> emacs als auch vi zum Kotzen finde (joe rules) und pine für den einzig
> bedienbaren textmode-mailclient halte (und ich hab sie alle ausprobiert). ;)
Hallo, ich bin der Holger ("Hallo Holger!"), und ich bin ebenfalls
... pine-User, und das auch noch gewohnheitsmäßig ("Oooohhh"). [aus dasr]
Bug#1024727: firefox-esr: does not support IPv6
Package: firefox-esr Version: 102.5.0esr-1~deb11u1 Severity: serious Justification: violates a Debian Etch release goal X-Debbugs-Cc: t...@mirbsd.de see attached screenshot -- Package-specific info: -- Addons package information -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-19-amd64 (SMP w/2 CPU threads) Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages firefox-esr depends on: ii debianutils 4.11.2 ii fontconfig 2.13.1-4.2 ii libasound2 1.2.4-1.1 ii libatk1.0-0 2.36.0-2 ii libc62.31-13+deb11u5 ii libcairo-gobject21.16.0-5 ii libcairo21.16.0-5 ii libdbus-1-3 1.12.24-0+deb11u1 ii libdbus-glib-1-2 0.110-6 ii libevent-2.1-7 2.1.12-stable-1 ii libffi7 3.3-6 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1+deb11u1 ii libgcc-s110.2.1-6 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1+deb11u1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4+deb11u2 ii libpango-1.0-0 1.46.2-3 ii libstdc++6 10.2.1-6 ii libvpx6 1.9.0-1 ii libx11-6 2:1.7.2-1 ii libx11-xcb1 2:1.7.2-1 ii libxcb-shm0 1.14-3 ii libxcb1 1.14-3 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext6 2:1.3.3-1.1 ii libxfixes3 1:5.0.3-2 ii libxrandr2 2:1.5.1-1 ii libxtst6 2:1.2.3-1 ii procps 2:3.3.17-5 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 Versions of packages firefox-esr recommends: ii libavcodec58 7:4.3.5-0+deb11u1 Versions of packages firefox-esr suggests: pn fonts-lmodern pn fonts-stix | otf-stix pn libcanberra0 ii libgssapi-krb5-2 1.18.3-6+deb11u3 pn pulseaudio -- no debconf information -- debsums errors found: debsums: changed file /usr/lib/firefox-esr/browser/omni.ja (from firefox-esr package) debsums: changed file /usr/lib/firefox-esr/omni.ja (from firefox-esr package)
Bug#1020652: [Pkg-openssl-devel] Bug#1020652: openssl: tls_process_key_exchange:internal error:../ssl/statem/statem_clnt.c:2254:
Also, where’s the NEWS entry apt-listchanges would have mailed me to document this change in behaviour? (Might as well place the documentation I requested in the previous eMail there, so others will also find it.) bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1020652: [Pkg-openssl-devel] Bug#1020652: openssl: tls_process_key_exchange:internal error:../ssl/statem/statem_clnt.c:2254:
Kurt Roeckx dixit: >On Sat, Sep 24, 2022 at 10:34:19PM +0200, Thorsten Glaser wrote: >> $ openssl s_client -CApath /etc/ssl/certs -connect www.mirbsd.org:443 >> -legacy_renegotiation -tls1 > >TLS 1.0 is not supported by default because it's insecure. You need >to change the security level to 0, for instance by using the cipher >string DEFAULT@SECLEVEL=0 ^ +colon Hey, this used to work at @SECLEVEL=2 even, with just MinProtocol changed. Also openssl ciphers shows the same, independent of the number used for @SECLEVEL. How can I find out, for any installed OpenSSL, which settings this mysterious @SECLEVEL influences and which are available? Where is this documented? bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec
Bug#1020652: openssl: tls_process_key_exchange:internal error:../ssl/statem/statem_clnt.c:2254:
Package: openssl Version: 3.0.5-4 Severity: serious Justification: does not work any more X-Debbugs-Cc: t...@mirbsd.de $ openssl s_client -CApath /etc/ssl/certs -connect www.mirbsd.org:443 -legacy_renegotiation -tls1 CONNECTED(0003) depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = R3 verify return:1 depth=0 CN = fish.mirbsd.org verify return:1 00B093C1B27F:error:0A0C0103:SSL routines:tls_process_key_exchange:internal error:../ssl/statem/statem_clnt.c:2254: --- Certificate chain 0 s:CN = fish.mirbsd.org i:C = US, O = Let's Encrypt, CN = R3 a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256 v:NotBefore: Aug 14 07:16:16 2022 GMT; NotAfter: Nov 12 07:16:15 2022 GMT 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256 v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT --- Server certificate -BEGIN CERTIFICATE- MIIGMjCCBRqgAwIBAgISA933/gWwGzwPvGuCEliwTrbPMA0GCSqGSIb3DQEBCwUA MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD EwJSMzAeFw0yMjA4MTQwNzE2MTZaFw0yMjExMTIwNzE2MTVaMBoxGDAWBgNVBAMT D2Zpc2gubWlyYnNkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMZcYzruTphJh0thHN1SrUba1XNcIDWKBytnd1GSEvAyRHPZPrpbBY4kEFRztdZg iIUuRSQffmmEgdCNpstXkPSZkZ7HPveTQV2oXK/T1EaoZP4PKWbO3sKZX2wMEr0x FmDPeQfcfo3UOPWWwQYeV5ac8De9NPnEXuKafoMBNFPVtDwbJuTMmXUFjm6uxCWb g4UIhGCKywMGhTmP6oxYCNBLi6PCZ3jByRLq/nemkKHl/YOsr9r/oP4LeDay6mDJ xWJ9aX1V6PpbV4J4O6F0VWCNjMSV+KK0FUxny1s6w7ILzubSkGisE2cISIr8lWg+ 0NB+M0sDSV4+GAPTH0bq04Yt3j2btnuH0oG0StZZLjNkRl3BFmnGRzTpEOG6SeEN +M9VF+A7mZY/JagSaFfZlfHYFvPO96jbIAa4Bn8RjhhtW8bKWeLaVi0OG9saahCn VXMXeTm3alET3lOGp+diAl2IrbQk80IUy9bM5eie4gluHkirM5xqO1Xv0rZ5jfJ4 1O5xRhkm71ZT8c8abe2/p0YPhGq2tLHXtDjMdJAYleic+c4iOXPTN3VOOl4Iucz5 F8il7edioa0bf/6Wgz61DpeRFjv85cYX5I2UbWOC7D219A8fJrB9NQTresI/BSz9 THRRydxSiLQmVkb6Ao55FuO7TbEvBIeSCE6OT33bZsBPAgMBAAGjggJYMIICVDAO BgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwG A1UdEwEB/wQCMAAwHQYDVR0OBBYEFCQz8IT0s7sJrskFItZ5nrA3XELqMB8GA1Ud IwQYMBaAFBQusxe3WFbLrlAJQOYfr52LFMLGMFUGCCsGAQUFBwEBBEkwRzAhBggr BgEFBQcwAYYVaHR0cDovL3IzLm8ubGVuY3Iub3JnMCIGCCsGAQUFBzAChhZodHRw Oi8vcjMuaS5sZW5jci5vcmcvMCoGA1UdEQQjMCGCD2Zpc2gubWlyYnNkLm9yZ4IO d3d3Lm1pcmJzZC5vcmcwTAYDVR0gBEUwQzAIBgZngQwBAgEwNwYLKwYBBAGC3xMB AQEwKDAmBggrBgEFBQcCARYaaHR0cDovL2Nwcy5sZXRzZW5jcnlwdC5vcmcwggEC BgorBgEEAdZ5AgQCBIHzBIHwAO4AdQApeb7wnjk5IfBWc59jpXflvld9nGAK+PlN XSZcJV3HhYKbbND5AAAEAwBGMEQCIB3PMPGlppnMneCfwDxozkJzKTwhys8Z DhUvU6WDD2KQAiA6sfxnk72LGLxEv7qWjyPBbA9o7/QZKAq34QmMg63KiAB1AEHI yrHfIkZKEMahOglCh15OMYsbA+vrS8do8JBilgb2AAABgpts0wYAAAQDAEYwRAIg Ob+e77xpbe10RPB9sp1IwRc7Bk/Oe1RP5YDmOgk2BVQCIG74jX2VsC6Hhe3hlilr DmlYh3mWRqC/CPKx3N8ymdVxMA0GCSqGSIb3DQEBCwUAA4IBAQCfEGT2fDCjRlTO weYlN8UUc/S2SXHUet+eDQNRBA/+w9HCggLd/Iw0nX+7EEFKP8fXHrYFwTtDwCjG v1qFpEvQFMEfmcRVEQWdvt8VSjBhRxYXFcxWazBfOqo5ZmRVdQChytx7PHwbl1jW CELQ41COfNw9TS8i4VixGxauEIx6YDWuA0cFfe+3UaANosW7y2gPJqGjA1PZaV3E Dn9wTPJGN2F+XkvNxdohqCQLh9N69mR4DMnQ39gd7uhGszobx5u7Y6Ih5zVEqsFF kHrxG9/h69tMCRKhtgmLZwVk/ZZ/dXDKFPDFJbnpwD+FB2O7f+bcBA3uw2809nBo DkHfZ0Rc -END CERTIFICATE- subject=CN = fish.mirbsd.org issuer=C = US, O = Let's Encrypt, CN = R3 --- No client certificate CA names sent Server Temp Key: DH, 2048 bits --- SSL handshake has read 4035 bytes and written 134 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Server public key is 4096 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1 Cipher: Session-ID: 0B21021F7E84628356DF05BD801681058EB87148083C224017E4AA4DEC59B243 Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1664051609 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- $ _ So it opens the connection but cannot use it. (Note that, while -legacy_renegotiation seems to be required now, the server has renegotiation disabled, it just doesn’t have the TLS extension to signal so yet.) -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-10-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages openssl depends on: ii libc62.35-1 ii libssl3 3.0.5-4 openssl recommends no packages. Versions of packages openssl suggests: ii ca-bundle [ca-certificates] 20190604tarent1 -- Configuration Files: /etc/ssl/openssl.cnf changed: HOME= . # Use this in order to automatically load
Bug#1020058: musescore-sftools: FTBFS: ld: CMakeFiles/sf3convert.dir/sfont.cpp.o: undefined reference to symbol 'vorbis_block_clear'
tags 1020058 + pending thanks Hi Lucas, >Relevant part (hopefully): >> /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. >> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time >> -D_FORTIFY_SOURCE=2 -std=c++0x -g -fPIC -fPIE -Wl,-z,relro -Wl,-z,now >> -Wl,--as-needed -rdynamic CMakeFiles/sf3convert.dir/sfconvert.cpp.o >> CMakeFiles/sf3convert.dir/sfont.cpp.o CMakeFiles/sf3convert.dir/xml.cpp.o -o >> sf3convert /usr/lib/x86_64-linux-gnu/libQt5Xml.so.5.15.4 -lvorbisenc >> /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.15.4 >> /usr/bin/ld: CMakeFiles/sf3convert.dir/sfont.cpp.o: undefined reference to >> symbol 'vorbis_block_clear' >> /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libvorbis.so.0: error adding symbols: >> DSO missing from command line this was rather confusing at first, but apparently this message means that an explicit -lvorbis is expected because while -lvorbisenc brings it in (DT_NEEDED) for the symbol, the linker, at some point, switched from GNU to OpenBSD semantics in not following these any more (which is a good thing). The actual cause, however, was that pkg-config is now only Recommends instead of Depends from the -dev B-Ds, so the machinery was unable to find libvorbis. Adding an explicit B-D on a pkg-config implementation (I use pkgconf now, first time) fixes this; upload follows. Maybe this helps others whose packages have similar problems. Thanks, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec
Bug#1017760: linux-image-5.10.0-17-amd64: No space for directory leaf checksum. Please run e2fsck -D.
Thorsten Glaser dixit: >I’ve recently been getting filesystem corruption on this system, which, >incidentally, is a fresh-ish installation since I’ve been hit by the I have somewhat reason to at least suspect the µSD card this was installed on. But there was never anything in syslog/dmesg about it, so the Linux kernel clearly didn’t find fault with it at all. Suggestions how I can prove/disprove this welcome; I now swapped the filesystem contents to a new fs on a new µSD card, so tests that are destructive can be done, but they need to be doable from a Grml live ISO and should be doable overnight (i.e. not block the system for too long). Thanks in advance, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (416 (445) bugs: 0 RC, 282 (302) I, 134 (143) M, 0 F) + 207 ‣ src:dash (94 (109) bugs: 0 RC, 52 (55) I, 42 (54) M, 0 F) + 63 ubu ‣ src:mksh (1 bug: 0 RC, 0 I, 1 M, 0 F) dash has two RC bugs they just closed because they don’t care about quality…
Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations
On Sat, 3 Sep 2022, Helge Kreutzmann wrote: > The upload of manpages-l10n (manpages-fr) was just accepted in > unstable. OK, thanks. AIUI we now need another upload of src:sysvinit in which bin:bootlogd gets a Replaces and Breaks on manpages-fr (<< 4.15.0-9~), correct? I can do that this weekend, ceteris paribus, unless anyone shouts. Where, though, are the other Replaces/Breaks? I cannot find any on the 3.05-1 binary packages? These are needed for upgrade ordering… … oh, the manpages for the other packages are just diverted? That will do, I suppose? bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations
Hi Helge, […] > Yes, that would be the best option. A few days ago I informed all > translation teams about the transfer of translations to sysvinit, so > if the French team could integrate the translation of bootlogd there, > that'll be great. ok, great! > For Debian, as stated above, I can do another upload removing this > file as well. Thanks. Feel free to reassign/close this bug at will then… or do we need another sysvinit upload with updated Replaces/Breaks/… as well, Andreas? bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Bug#1009915: sysvinit: Please align with manpages-l10n and afterwards activate man page translations
On Wed, 31 Aug 2022, Mark Hindley wrote: > > there seems to be one manpage (in bootlogd) missing conflict handling: > > > > /usr/share/man/fr/man8/bootlogd.8.gz > > Thanks. I was under the impression that manpages-i10n had changed to > systemd versions (which doesn't have bootlogd.8) but apparently not. I > think we should continue to use the manpages-i10n version and not have > any more dpkg diversions than are absolutely necessary. > > I am away for a week, but will resolve this once I am back. Perhaps in this time a french speaker can compare the two versions, from sysvinit and manpages-l10n, and see which one is “better”, then contribute that to sysvinit so manpages-l10n can remove theirs as bootlogd isn’t provided with systemd? bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen: ╳ HTML eMail! Also, https://www.tarent.de/newsletter ╱ ╲ header encryption!
Bug#1017537: armel buildd misconfiguration (was Re: Bug#1017537: dietlibc: FTBFS on armel)
outlook 1017537 some armel buildds are misconfigured and lack SWP emulation thanks Dixi quod… ># if __ARM_ARCH__ < 6 > swp r0, r1, [r2] ># else And this, after some research, is it. This is needed for armel, which is v5. Apparently, Linux has SWP emulation for v7/v8 hosts, but at least one buildd listed does not have this enabled, breaking the armel ABI. Please ensure that only hosts with working SWP emulation run armel. (Can I reassign this bugreport to the buildd? Does it have a virtual package in debbugs?) Until then, I guess I’ll keep giveback’ing dietlibc on armel until it builds… bye, //mirabilos -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Bug#1017537: dietlibc: FTBFS on armel
Dixi quod… >In case this makes anyone immediately think of whatever it is: Code looks right enough (with an explanation of why this only fails on armel but not on armhf which is perfectly fine): $ cat arm/__testandset.S #include "arm-features.h" FUNC_START __testandset mov r2, r0 mov r1, #1 # if __ARM_ARCH__ < 6 swp r0, r1, [r2] # else 1: ldrex r0, [r2] strex r3, r1, [r2] cmp r3, #0 bne 1b # endif RET FUNC_END__testandset bye, //mirabilos -- When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication. -- Wouter, about my Debian/m68k revival
Bug#1017537: dietlibc: FTBFS on armel
>but it ALSO fails in a bullseye chroot, so this is possibly not related In case this makes anyone immediately think of whatever it is: (gdb) r Starting program: /home/tg/dietlibc-0.34~cvs20160606-el-11/debian/unittests/ttt Program received signal SIGILL, Illegal instruction. __testandset () at arm/__testandset.S:7 7 swp r0, r1, [r2] (gdb) bt #0 __testandset () at arm/__testandset.S:7 #1 0x000113d4 in __pthread_lock (lock=lock@entry=0x25054 <_main_thread+20>) at libpthread/pthread_spinlock.c:84 #2 0x0001052c in __thread_find_ (pid=) at libpthread/pthread_internal.c:98 #3 0x00010578 in __thread_self () at libpthread/pthread_internal.c:127 #4 0x00010280 in malloc (size=32) at libpthread/pthread_sys_alloc.c:20 #5 0x00010124 in main () (gdb) info r r0 0x25054 151636 r1 0x1 1 r2 0x25054 151636 r3 0x0 0 r4 0x0 0 r5 0x25054 151636 r6 0x0 0 r7 0x1e8481201 r8 0x1016 r9 0xfffef684 4294899332 r100xfffef68c 4294899340 r110xfffef67c 4294899324 r120x1420 sp 0xfffef3c0 0xfffef3c0 lr 0x113d4 70612 pc 0x11480 0x11480 <__testandset+8> cpsr 0x6010 1610612752 fpscr 0x0 0 (gdb) disas Dump of assembler code for function __testandset: 0x00011478 <+0>: mov r2, r0 0x0001147c <+4>: mov r1, #1 => 0x00011480 <+8>: swp r0, r1, [r2] 0x00011484 <+12>:bx lr End of assembler dump.
Bug#1017537: dietlibc: FTBFS on armel
outcome 1017537 fails on porterbox/bullseye as well, suspect 64-bit host to be an issue tags 1017537 + help thanks In contrast to armhf, which works fine on the porterbox (amdahl; abel, which I normally use, is currently down) for me, this one also fails, but it ALSO fails in a bullseye chroot, so this is possibly not related to a toolchain change. I think I’ll have to track down a 32-bit ARM machine and test-build it there. I recently got gifted a Raspbery Pi v1.2 so that’d be running armel anyway, so I guess it’s installing Debian on that thing for me now. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1017538: dietlibc: FTBFS on armhf
tags 1017538 + unreproducible thanks This builds fine in a sid-armhf chroot on amdahl.
Bug#1012214: gradle: unknown option --add-opens breaks OpenJDK 11 packages
Markus Koschany dixit:
>The --add-opens error message was misleading and it turned out the underlying
>root cause for the FTBFS was a different one. Gradle currently fails to build
>because of a different jansi bug.
OK, so keep that one open and close this one?
>There is still some work to do with Gradle 6.x and progress is slow but
>I still think we should focus on that instead of trying to ship Gradle
>4 again.
Ideally fix the RC bugs first though so not only is there a Plan B but also
will the affected r-deps not be autoremoved from testing due to these issues.
bye,
//mirabilos
--
11:56⎜«liwakura:#!/bin/mksh» also, i wanted to add mksh to my own distro │
i was disappointed that there is no makefile │ but somehow the Build.sh is
the least painful built system i've ever seen │ honours CC, {CPP,C,LD}FLAGS
properly │ looks cleary like done by someone who knows what they are doing
Bug#1012214: gradle: unknown option --add-opens breaks OpenJDK 11 packages
Markus Koschany dixit: >The newly added --add-opens option is only valid for OpenJDK 17. I >understand that we switch to it for Debian 12 but it currently breaks >all packages that are built with OpenJDK 11. I am currently in the Is this true? AFAIK --add-opens is for 11+ (probably even 9+). It certainly seems to work on buster for me. bye, //mirabilos -- Beware of ritual lest you forget the meaning behind it. yeah but it means if you really care about something, don't ritualise it, or you will lose it. don't fetishise it, don't obsess. or you'll forget why you love it in the first place.
Bug#1017760: linux-image-5.10.0-17-amd64: No space for directory leaf checksum. Please run e2fsck -D.
Package: src:linux Version: 5.10.136-1 Severity: grave Justification: causes non-serious data loss X-Debbugs-Cc: t...@mirbsd.de I’ve recently been getting filesystem corruption on this system, which, incidentally, is a fresh-ish installation since I’ve been hit by the “forgot LUKS password for the main SSD” problem. This also happened with 5.10.0-14-amd64, but I think not earlier. It occasionally happens after some amount of uptime and hits random directories apparently. -- Package-specific info: ** Version: Linux version 5.10.0-17-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.136-1 (2022-08-13) ** Command line: BOOT_IMAGE=/SDcardBoot/vmlinuz-5.10.0-17-amd64 root=UUID=d7cfc3b2-8733-481c-9fcc-7de4d41a13d6 ro net.ifnames=0 ** Not tainted ** Kernel log: [119729.028638] iwl4965 :03:00.0: FH49_TSSR_TX_ERROR_REG: 0X [119729.030412] iwl4965 :03:00.0: Can't stop Rx DMA. [119729.030518] ieee80211 phy0: Hardware restart was requested [120028.870081] iwl4965 :03:00.0: Microcode SW error detected. Restarting 0x8200. [120028.870091] iwl4965 :03:00.0: Loaded firmware version: 228.61.2.24 [120028.870112] iwl4965 :03:00.0: Start IWL Error Log Dump: [120028.870117] iwl4965 :03:00.0: Status: 0x000213E4, count: 5 [120028.870302] iwl4965 :03:00.0: Desc Time data1 data2 line [120028.870309] iwl4965 :03:00.0: NMI_INTERRUPT_WDG(0x0004) 4055082994 0x0002 0x0243 208 [120028.870314] iwl4965 :03:00.0: pc blink1 blink2 ilink1 ilink2 hcmd [120028.870320] iwl4965 :03:00.0: 0x0046C 0x04BE0 0x004C2 0x006DE 0x04C7C 0x27F001C [120028.870324] iwl4965 :03:00.0: FH register values: [120028.870344] iwl4965 :03:00.0: FH49_RSCSR_CHNL0_STTS_WPTR_REG: 0X10606300 [120028.870364] iwl4965 :03:00.0: FH49_RSCSR_CHNL0_RBDCB_BASE_REG: 0X01060620 [120028.870383] iwl4965 :03:00.0:FH49_RSCSR_CHNL0_WPTR: 0X0008 [120028.870402] iwl4965 :03:00.0: FH49_MEM_RCSR_CHNL0_CONFIG_REG: 0X80809000 [120028.870422] iwl4965 :03:00.0:FH49_MEM_RSSR_SHARED_CTRL_REG: 0X003c [120028.870441] iwl4965 :03:00.0: FH49_MEM_RSSR_RX_STATUS_REG: 0X0243 [120028.870460] iwl4965 :03:00.0: FH49_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X [120028.870479] iwl4965 :03:00.0: FH49_TSSR_TX_STATUS_REG: 0X07ff0002 [120028.870498] iwl4965 :03:00.0: FH49_TSSR_TX_ERROR_REG: 0X [120028.872274] iwl4965 :03:00.0: Can't stop Rx DMA. [120028.872340] ieee80211 phy0: Hardware restart was requested [121081.667715] iwl4965 :03:00.0: Microcode SW error detected. Restarting 0x8200. [121081.667739] iwl4965 :03:00.0: Loaded firmware version: 228.61.2.24 [121081.667951] iwl4965 :03:00.0: Start IWL Error Log Dump: [121081.667959] iwl4965 :03:00.0: Status: 0x000213E4, count: 5 [121081.668140] iwl4965 :03:00.0: Desc Time data1 data2 line [121081.668151] iwl4965 :03:00.0: NMI_INTERRUPT_WDG(0x0004) 0812904774 0x0002 0x0243 208 [121081.668158] iwl4965 :03:00.0: pc blink1 blink2 ilink1 ilink2 hcmd [121081.668166] iwl4965 :03:00.0: 0x0046C 0x04BE0 0x004C2 0x006DE 0x04C7C 0x298001C [121081.668173] iwl4965 :03:00.0: FH register values: [121081.668195] iwl4965 :03:00.0: FH49_RSCSR_CHNL0_STTS_WPTR_REG: 0X10606300 [121081.668218] iwl4965 :03:00.0: FH49_RSCSR_CHNL0_RBDCB_BASE_REG: 0X01060620 [121081.668240] iwl4965 :03:00.0:FH49_RSCSR_CHNL0_WPTR: 0X0020 [121081.668260] iwl4965 :03:00.0: FH49_MEM_RCSR_CHNL0_CONFIG_REG: 0X80809000 [121081.668279] iwl4965 :03:00.0:FH49_MEM_RSSR_SHARED_CTRL_REG: 0X003c [121081.668302] iwl4965 :03:00.0: FH49_MEM_RSSR_RX_STATUS_REG: 0X0243 [121081.668324] iwl4965 :03:00.0: FH49_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X [121081.668347] iwl4965 :03:00.0: FH49_TSSR_TX_STATUS_REG: 0X07ff0002 [121081.668367] iwl4965 :03:00.0: FH49_TSSR_TX_ERROR_REG: 0X [121081.670429] iwl4965 :03:00.0: Can't stop Rx DMA. [121081.670535] ieee80211 phy0: Hardware restart was requested [125434.083155] wlan0: deauthenticating from 38:10:d5:48:ea:c0 by local choice (Reason: 3=DEAUTH_LEAVING) [128369.139128] e1000e :00:19.0 eth0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx [128369.139255] e1000e :00:19.0 eth0: 10/100 speed: disabling TSO [128369.139340] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [135660.818236] e1000e :00:19.0 eth0: NIC Link is Down [135662.403058] e1000e :00:19.0 eth0: NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx [135662.403180] e1000e :00:19.0 eth0: 10/100 speed: disabling TSO
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
Arnd Bergmann dixit: >The way the FPU type gets selected in gcc changed with recent versions, >this was intentional and won't be reverted but it did break packages that >used the old method. Hmph. >In most cases, it's sufficient to pass >-march=armv7-a+fp instead of -march=armv7-a to pick the right >instruction set. There’s no “instead of”, though. So basically, I now need to add -march=… to CFLAGS in the package when compiling for either of armel and armhf. Which value do I use for armel, which for armhf (the one you gave is for armhf, I think)? bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#1017537: Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
Arnd Bergmann dixit: >I tried cross-building it myself now and found the same issue with >an older arm-linux-gnueabihf-gcc-11, which invokes the assembler as > >/usr/lib/gcc-cross/arm-linux-gnueabihf/11/../../../../arm-linux-gnueabihf/bin/as >-v -march=armv7-a -mfloat-abi=hard -meabi=5 -o bin-arm/__longjmp.o >longjmp.s > >where the old one would pass an extra -mfpu=vfpv3-d16. Is my expectation that, for any given platform (armel, armhf, arm64), that a default invocation of the system compiler adds the correct flags not good? >However, with arm-linux-gnueabihf-gcc-12, it appears to work fine again. Sounds like a bug in gcc-11 instead then? (Why has this then not hit more packages?) >I also see that the Makefile attempts to detect the host architecture, but >fails to recognize armv8 hardware as arm. What hardware and toolchain >environment was the failing build on? debian/rules inspects DEB_HOST_ARCH and passes MYARCH to the upstream Makefile so this ought to DTRT…ish — arm64 is passed as aarch64, and all other *arm* are passed as arm (though we don’t carry armeb or the pre-EABI arm any more so that’s probably also fine). Note that #1017537 (on armel) and #1017538 (on armhf) probably are, if not the same thing, at least related. bye, //mirabilos -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc
Bug#1017537: dietlibc: FTBFS on armel: illegal instruction
Sebastian Ramacher dixit: >This is already an issue with 0.34~cvs20160606-12. It’s an incompatible toolchain change that broke this package. I’m trying to find out why, but the ARM porters are not helpful. bye, //mirabilos -- Support mksh as /bin/sh and RoQA dash NOW! ‣ src:bash (406 (433) bugs: 0 RC, 275 (295) I, 131 (138) M, 0 F) + 208 ‣ src:dash (91 (106) bugs: 0 RC, 51 (55) I, 40 (51) M, 0 F) + 63 ubu ‣ src:mksh (1 bug: 0 RC, 0 I, 1 M, 0 F) dash has two RC bugs they just closed because they don’t care about quality…
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
Arnd Bergmann dixit: >-march=armv7-a+fp instead of -march=armv7-a to pick the right “instead of” We pass nothing there, and we need a solution (or two distinct ones) for armel and armhf. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs
Bug#1017538: dietlibc: FTBFS on armhf: selected processor does not support vldm in ARM mode
tags 1017538 + help
forwarded 1017538 https://lists.debian.org/debian-arm/2022/07/msg00041.html
thanks
Hi Sebastian,
instead of filing a bug with the information we already have…
>arm/__longjmp.S: Assembler messages:
>arm/__longjmp.S:9: Error: selected processor does not support `vldm
>ip!,{d0-d15}' in ARM mode
… you could maybe have considered answering the question I posed
on the Debian ARM mailing list about *why* it fails because nothing
related to ARM was changed in the package or code.
So something in the toolchain(?) must have changed since the last
successful build (what?) which we need to locally revert.
Thanks in advance for any help,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#1016129: ipv6toolkit does not work with libpcap > 1.8
Octavio Alvarez dixit: > On 31/07/22 14:57, Thorsten Glaser wrote: >> debdiff (±version) attached. Would you prefer for me to NMU, do a >> maintainer-agreed regular upload (as -2), or handle this yourself, >> Octavio? > > I can handle it. By the way, did the fix work for you? Yes, the debdiff I attached works. >> Will you communicate with the SRM or do you wish for me to handle that? > > I may need help with that. I'll get back to you. OK. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Bug#1016129: (no subject)
tags 1016129 + patch buster bullseye bookworm sid
thanks
Upstream discussion managed to find the precise fix for pcap 1.10
compatibility that’s missing in Debian’s version:
https://github.com/fgont/ipv6toolkit/issues/78#issuecomment-1197453179
debdiff (±version) attached. Would you prefer for me to NMU, do a
maintainer-agreed regular upload (as -2), or handle this yourself,
Octavio?
Tagging bullseye *and* buster because this must be fixed in these
releases as well:
• the bullseye package, as-is, is broken, so this is an RC fix there
• buster “as-is” works but if libpcap0.8 is upgraded, either via
buster-backports or by mixing buster and bullseye packages, it’ll
break (and we cannot retrofit a matching Breaks to libpcap0.8 in
bullseye any more now it’s released) so buster’s will either need
the patch applied or a versioned depends on libpcap0.8 (<< 1.10)
Will you communicate with the SRM or do you wish for me to handle that?
Thanks in advance,
//mirabilos
--
[17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker:
veni, vidi, fixi(t) ;-)diff -Nru ipv6toolkit-2.0+ds.1/debian/changelog
ipv6toolkit-2.0+ds.1/debian/changelog
--- ipv6toolkit-2.0+ds.1/debian/changelog 2020-08-05 06:21:55.0
+0200
+++ ipv6toolkit-2.0+ds.1/debian/changelog 2022-07-31 21:43:23.0
+0200
@@ -1,3 +1,10 @@
+ipv6toolkit (2.0+ds.1-1.1~~) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Add upstream fix for pcap 1.10 compatibility (Closes: #1016129)
+
+ -- Thorsten Glaser Sun, 31 Jul 2022 21:43:23 +0200
+
ipv6toolkit (2.0+ds.1-1) unstable; urgency=medium
* Refreshed patches using gbp pq export. Added:
diff -Nru
ipv6toolkit-2.0+ds.1/debian/patches/03b0fdd42cf36c0070472afbb9b81a9ca62e1109.patch
ipv6toolkit-2.0+ds.1/debian/patches/03b0fdd42cf36c0070472afbb9b81a9ca62e1109.patch
---
ipv6toolkit-2.0+ds.1/debian/patches/03b0fdd42cf36c0070472afbb9b81a9ca62e1109.patch
1970-01-01 01:00:00.0 +0100
+++
ipv6toolkit-2.0+ds.1/debian/patches/03b0fdd42cf36c0070472afbb9b81a9ca62e1109.patch
2022-07-31 21:43:17.0 +0200
@@ -0,0 +1,25 @@
+Applied-Upstream: commit:03b0fdd42cf36c0070472afbb9b81a9ca62e1109
+From: Fernando Gont
+Subject: Set pcap timeout to 1 for all platforms.
+Author: Leonard Marschke (lmm-git)
+
+--- a/tools/libipv6.h
b/tools/libipv6.h
+@@ -123,12 +123,17 @@ struct filters{
+ #define PCAP_NETMASK_UNKNOWN0x
+ #endif
+
++/* XXX:
++At some point we were setting the timeout differently for different
platforms. Should double-check, but doesn't seem to make sense.
++
+ #if defined (__FreeBSD__) || defined(__NetBSD__) || defined (__OpenBSD__) ||
defined(__APPLE__) || defined(__FreeBSD_kernel__) || defined(sun) ||
defined(__sun)
+ #define PCAP_TIMEOUT1
+ #else
+ #define PCAP_TIMEOUT0
+ #endif
++*/
+
++#define PCAP_TIMEOUT1
+
+ #define PCAP_IPV6_FILTER "ip6"
+ #define PCAP_TCPV6_FILTER "ip6 and tcp"
diff -Nru ipv6toolkit-2.0+ds.1/debian/patches/series
ipv6toolkit-2.0+ds.1/debian/patches/series
--- ipv6toolkit-2.0+ds.1/debian/patches/series 2020-08-05 06:21:55.0
+0200
+++ ipv6toolkit-2.0+ds.1/debian/patches/series 2022-07-31 21:42:09.0
+0200
@@ -5,3 +5,4 @@
0005-Silence-compiler-warnings.patch
0006-Silence-misleading-indentation-warnings.patch
0007-strncpy-len-must-include-the-terminating-nul-byte.patch
+03b0fdd42cf36c0070472afbb9b81a9ca62e1109.patch
Bug#1016129: [fgont/ipv6toolkit] Cannot send packets in one direction (other works) (Issue #78)
Cc libpcap maintainers; context is #1016129 on debbugs. From diffing around between a buster and a bullseye system, I could track this bug down: libpcap0.8: 1.10.0-2 500 500 http://deb.debian.org/debian bullseye/main amd64 Packages 1.10.0-2~bpo10+1 100 100 http://deb.debian.org/debian buster-backports/main amd64 Packages 1.8.1-6+deb10u1 500 500 http://deb.debian.org/debian buster/main amd64 Packages Installing 1.10.0-2~bpo10+1 on buster breaks ipv6toolkit. Installing 1.10.0-2~bpo10+1 on bullseye does not fix ipv6toolkit, installing 1.8.1-6+deb10u1 on bullseye (which temporarily breaks tcpdump) does fix ipv6toolkit. So there’s either something in the newer libpcap that breaks ipv6toolkit, or something in ipv6toolkit that’s not yet compatible with newer libpcap. bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec
