Bug#1069697: lintian: debian-changelog-line-too-short CVEs
Richard Lewis dixit: >would it make a difference if the somewhat ambiguous line "CVEs" was >changed to "Fixes the following CVEs:" ? It’s very much not ambiguous, as the entire entry is a list of fixes, that’d be reducing the signal:noise ratio (besides this part of the changelog is copy-pasted from the upstream release announcement). I find that lintian is overly opinionated here. I could agree, were this just a single line (given the tag’s stated purpose), but not for multi-line or lists. 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#1068024: revert to version that does not contain changes by bad actor
Christoph Anton Mitterer dixit: >So Thorsten, in case you or someone else is aware of any [intermediate] >results from these task forces ([9[) it would be nice to hear about >them or better even in form of some "official" statement from Debian. JFTR I’m not involved in those myself. 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#1069697: lintian: debian-changelog-line-too-short CVEs
Package: lintian Version: 2.117.0 P: openjdk-8-doc: debian-changelog-line-too-short CVEs [usr/share/doc/openjdk-8-doc/changelog.Debian.gz:4] The changelog in question is: * New upstream release * CVEs - CVE-2024-21011 - CVE-2024-21085 - CVE-2024-21068 - CVE-2024-21094 * Security fixes […] I find this a little opinionated anyway, but here not quite appropriate as the changelog “line” spans more than a physical line. Maybe, if you won’t consider the space until the next /^ \* / a “line”, then at least exclude itemisations from that tag? Thanks.
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#1068324: lintian: patch-not-forwarded-upstream for upstream patches
Hi Nilesh, >Right. AFAICS, lintian spews that warning because the header in that patch in >incomplete. It also needs a "From" and "Subject" (which can be same as commit this is not entirely correct. The full patch header is: Description: fix typeset -p confusion between empty and unset Origin: commit:10065BC69BE555D6721 Description is the standard name for Subject (the same way Author is the standard DEP 3 name for From), and it’s present, and when Origin indicates an upstream commit (as shown here), Author does not need to be present, per DEP 3. bye, //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#1068873: openjdk-21: more m68k patches
Dixi quod…
>>I’ll recompile with re-enabled alignment on the missing base
>
>Seems to be only one.
>
>--- src/hotspot/share/memory/allocation.hpp~ 2024-04-12 23:52:54.0
>+
>+++ src/hotspot/share/memory/allocation.hpp2024-04-12 23:52:56.0
>+
>@@ -276,7 +276,7 @@ class CHeapObj {
> void operator delete [] (void* p) {
> CHeapObjBase::operator delete[](p);
> }
>-};
>+} __attribute__ ((aligned (4)));
>
> // Base class for objects allocated on the stack only.
> // Calling new or delete will result in fatal error.
>
>>classes like we have in 17. But if someone has ideas ’til then…
>
Yes, with this, the build gets much further, so I’d be glad if you
could include this in the next -21 upload (and -20 if you do any
more of these, but probably not, and not necessary on my account).
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#1067196: qpdf: contrary to the documentation, fix-qdf aborts on removed objects
Jay Berkenbilt dixit: >As it happens, I am upstream. Oh, nice ☻ in that case, thanks for qpdf. >--- >It is not generally practical to remove objects from QDF files without >messing up object numbering, but if you remove all indirect references >to an object (without removing the object itself), this will leave the >object unreferenced. Then you can run qpdf on the file (after running >:command:`fix-qdf`), and qpdf will omit the now-orphaned object. >--- That fixes the ambiguity but leaves the reader¹ wondering, on two reading passes, what other references than indirect there are. The reader who has not digested the PDF spec in and out, at least. If you s/ indirect//, would it still be correct? That would be less possibly-ambiguous, I think. bye, //mirabilos ① or at least me right now -- 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#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!
Bernhard Übelacker dixit:
> On Thu, 4 Apr 2024 21:00:59 + (UTC) Thorsten Glaser
> wrote:
>> Sometimes, it does not crash with a smashed stack but instead:
>>
>> Setting up sasl2-bin (2.1.28+dfsg1-6+b1) ...
>> BDB0002 __fop_file_setup: Retry limit (100) exceeded
>> saslpasswd2: generic failure
>
> This looks to be a result of the pre-existing /etc/__db.sasldb2.
> If this file gets removed the stack smashing occurs again.
Right, I got there as well but not any further.
> By some experimenting I could convince gdb to load the debug symbols.
Massive detective work, thanks!
> And the stack seems to point into function __os_unique_id from libdb-5.3.so.
>
> Unfortunately I am not sure where the canary gets overwritten.
I had an immediate hunch as I saw this:
> 38 __os_gettime(env, , 1);
And:
> (gdb) ptype /o v
> type = struct {
> /* 0 | 8 */time_t tv_sec;
> /* 8 | 4 */long tv_nsec;
>
> /* total size (bytes): 12 */
> }
This is, in the source:
typedef struct {
time_t tv_sec; /* seconds */
#ifdef HAVE_MIXED_SIZE_ADDRESSING
int32_t tv_nsec;
#else
longtv_nsec;/* nanoseconds */
#endif
} db_timespec;
Compare the newer system header:
struct timespec
{
#ifdef __USE_TIME_BITS64
__time64_t tv_sec;/* Seconds. */
#else
__time_t tv_sec; /* Seconds. */
#endif
#if __WORDSIZE == 64 \
|| (defined __SYSCALL_WORDSIZE && __SYSCALL_WORDSIZE == 64) \
|| (__TIMESIZE == 32 && !defined __USE_TIME_BITS64)
__syscall_slong_t tv_nsec;/* Nanoseconds. */
#else
# if __BYTE_ORDER == __BIG_ENDIAN
int: 32; /* Padding. */
long int tv_nsec; /* Nanoseconds. */
# else
long int tv_nsec; /* Nanoseconds. */
int: 32; /* Padding. */
# endif
#endif
};
This is actually longer and (IMHO) really stupid. But Linux has:
struct __kernel_timespec {
__kernel_time64_t tv_sec; /* seconds */
long long tv_nsec;/* nanoseconds */
};
So this is actually expected. *checks POSIX* which says:
| The header shall declare the timespec structure, which shall
| include at least the following members:
|
| time_t tv_sec Whole seconds.
| long tv_nsec Nanoseconds [0, 999 999 999].
So both the kernel definition (tv_nsec must be long, not long long,
which is incompatible on ILP32 big endian platforms) and the one by
db5.3 (struct timespec may include extra members and be in any order)
actually violate POSIX… *sigh*
And yes, it does cast to struct timespec and passes it
to clock_gettime().
But it does give us a possible fix, which I’ll be testing.
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#1068873: openjdk-21: more m68k patches
Dixi quod…
>I’ll recompile with re-enabled alignment on the missing base
Seems to be only one.
--- src/hotspot/share/memory/allocation.hpp~2024-04-12 23:52:54.0
+
+++ src/hotspot/share/memory/allocation.hpp 2024-04-12 23:52:56.0
+
@@ -276,7 +276,7 @@ class CHeapObj {
void operator delete [] (void* p) {
CHeapObjBase::operator delete[](p);
}
-};
+} __attribute__ ((aligned (4)));
// Base class for objects allocated on the stack only.
// Calling new or delete will result in fatal error.
>classes like we have in 17. But if someone has ideas ’til then…
gn8,
//mirabilos
--
This space for rent.
Bug#1068873: openjdk-21: more m68k patches
Dixi quod…
>>(This is what I found trying to build openjdk-20, but it’ll be
>>needed in 21 as well. Even getting to this point took 13½ days
>>already…)
>
>And turns out that this isn’t the cause.
>
>In 17, we’ve got src/hotspot/share/memory/allocation.hpp to
>align all CHeapObj, StackObj, MetaspaceObj, etc. classes; this
>is gone in 21. So this needs to be brought back instead.
Hmmhmm. Since I’m having to build/debug 20 first…
… in 20, StackObj has its alignment bumped manually,
but CHeapObj doesn’t. MetaspaceObj does, ResourceObj
and ArenaObj don’t, AnyObj does.
So I’m guessing we will want to fix up the allocators instead?
(Though raising the alignment for cases where people allocate
them on the stack may still be useful…)
ArenaObj… is not allocated‽
resource_allocate_bytes uses Thread::current()->resource_area()->allocate_bytes
which uses Amalloc which seems to align well.
AllocateHeap uses os::malloc which uses ::malloc (C function?)
in NMT and normal cases. Huh. MallocHeader is 16 bytes, also okay.
The glibc texinfo docs say…
| The address of a block returned by ‘malloc’ or ‘realloc’ in GNU systems
| is always a multiple of eight (or sixteen on 64-bit systems). If you
… so that should *also* be okay?! Unless that’s not true, anyway…
#define SIZE_SZ (sizeof (INTERNAL_SIZE_T))
#define MALLOC_ALIGNMENT (2 * SIZE_SZ < __alignof__ (long double) \
? __alignof__ (long double) : 2 * SIZE_SZ)
… it should.
So where does the unaligned _futex_barrier member in the
class LinuxWaitBarrier : public CHeapObj come from?
AFAICS, the caller is:
WaitBarrier* SafepointSynchronize::_wait_barrier;
_wait_barrier = new WaitBarrier(vmthread);
With:
typedef LinuxWaitBarrier WaitBarrierDefault;
template
class WaitBarrierType : public CHeapObj {
WaitBarrierImpl _impl;
…
}
typedef WaitBarrierType WaitBarrier;
So the “new WaitBarrier” should call CHeapObj::operator new(size_t size)
TTBOMK (IANAC++Programmer) which calls CHeapObjBase::operator new(size,
mtInternal)
= AllocateHeap(size, mtInternal)…
Hmmm. But, oops, I see something more:
src/hotspot/share/services/mallocTracker.hpp: static const size_t
overhead_per_malloc = sizeof(MallocHeader) + sizeof(uint16_t);
That would dealign things… but MallocTracker::record_malloc
only adds sizeof(MallocHeader) and has an assert (unsure if
NDEBUG though) that checks alignment…
I am lost. I can *see* an under-aligned futex barrier in strace.
19270 futex(0xcf80078a, FUTEX_WAKE_PRIVATE, 2147483647) = -1 EINVAL (Invalid
argument)
I cannot see how, though.
FWIW, /tmp/buildd/openjdk-20-20.0.2+9/build/jdk/bin/java \
-XX:NativeMemoryTracking=summary -version also crashes, same
with an explicit -XX:NativeMemoryTracking=off :/
I’ll recompile with re-enabled alignment on the missing base
classes like we have in 17. But if someone has ideas ’til then…
Mraw,
//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#1068873: openjdk-21: more m68k patches
Dixi quod… >(This is what I found trying to build openjdk-20, but it’ll be >needed in 21 as well. Even getting to this point took 13½ days >already…) And turns out that this isn’t the cause. In 17, we’ve got src/hotspot/share/memory/allocation.hpp to align all CHeapObj, StackObj, MetaspaceObj, etc. classes; this is gone in 21. So this needs to be brought back instead.
Bug#1068629: testng7 backport for bullseye needed for latest Java LTS releases
Hi Vladimir, if you have any suggestions as to what to do best with openjdk-8, feel free to say. In Debian, it’s only relevant in unstable, ELTS stretch and jessie, but for Ubuntu it’s used in more. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1068873: openjdk-21: more m68k patches
Source: openjdk-21
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org
Please add the following patch e.g. to debian/patches/m68k-support.diff
for more making implicit alignment assumptions (here by the futex
syscall) explicit:
--- src/hotspot/os/linux/waitBarrier_linux.hpp~ 2024-04-12 18:24:38.584686322
+0200
+++ src/hotspot/os/linux/waitBarrier_linux.hpp 2024-04-12 18:24:46.768716977
+0200
@@ -29,7 +29,7 @@
#include "utilities/globalDefinitions.hpp"
class LinuxWaitBarrier : public CHeapObj {
- volatile int _futex_barrier;
+ volatile int _futex_barrier __attribute__((__aligned__(4)));
NONCOPYABLE(LinuxWaitBarrier);
Thanks!
(This is what I found trying to build openjdk-20, but it’ll be
needed in 21 as well. Even getting to this point took 13½ days
already…)
Bug#1068615: pbuilder will overwrite LANG/LC_ALL if they are set via config file
Sergio Durigan Junior dixit:
>-export LANG=C
>-export LC_ALL=C
>+export LANG="${LANG:-C}"
>+export LC_ALL="${LC_ALL:-C}"
Ouch, no.
IMHO, they ought to really be unset for sane build environments,
and if the thing to be built needs locales, it can set its own.
Passing environment variables, even “just” the locale, from the
outside into the build environment is a dark path.
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1067196: qpdf: contrary to the documentation, fix-qdf aborts on removed objects
Jay Berkenbilt dixit: >Can you tell me where in the docs it says what you're describing? >Here's a direct quote from the current qpdf documentation: > >It is not generally practical to remove objects from QDF files without >messing up object numbering, but if you remove all references to an >object, you can run qpdf on the file (after running fix-qdf), and qpdf >will omit the now-orphaned object. Yes, I meant that. At least two people assumed that “remove all references” includes the object itself, but now that you point it out, it likely doesn’t, but we are no native speakers, so I don’t know which of the two interpretations is more likely to them or if even both are possible. Maybe, if you have good connections to upstream, suggest to them to add “(but not the object itself)” to behind “all references to an object”, but the bug can then be closed. Thanks for looking into it, //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#1068326: bookworm-pu: package mksh/59c-28+deb12u1
Jonathan Wiltshire dixit: >Please go ahead. Thanks. Do you need a blurb for the point release notes or something? bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Rich Felker dixit: >Is there anything weird about how these objects were declared that >might have caused ld not to resolve them statically like it should? It >seems odd that these data symbols, but not any other ones, would be >left as symbolic relocations. I don’t think so? In I already posted the short version; the actual source is (mirrored): The initcoms array is here: https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/main.c#L77 Tdr is defined at: https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/sh.h#L3055 The u_ops array is declared a few lines above that and defined at: https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/funcs.c#L160 initvsn is defined at… https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/sh.h#L713 … with the EXTERN and E_INIT macros from… https://github.com/MirBSD/mksh/blob/b0219da8e6dfc7b16e923e220dc6933c5ed9b326/sh.h#L657 where main.c defines EXTERN, so the string is embedded into the file using it. Is there perhaps a misunderstanding with the gcc/binutils/glibc developers as to what static-pie is meant to be? bye, //mirabilos -- cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten die nicht noch 3 Jahre warten können? bis dahin gibts google nicht mehr ja, könnte man meinen. wahrscheinlich ist der angekündigte welt- untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum müssen die die doodles vorher noch raushauen
Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Markus Wichmann dixit: >I may not really know what I am talking about, so take this with a grain >of salt, but isn't this missing a -Bsymbolic somewhere? Ironically, that >switch causes ld to not emit symbolic relocations. I seem to remember >reading long ago in Rich's initial -static-pie proposal that that was >one of the switches added to the linker command line. When searching for which architectures support static PIE in the first place (sadly, there doesn’t seem a consistent list), I found one saying it’s no longer necessart after some point, so I didn’t check it. >In any case, the emission of non-relative relocations is the issue here, >and it is coming from the linker. They are present in the glibc static-pie binary as well, though. And tbh they look to me like “just plug the absolute address of the symbol here, please”, which is perfectly fine for things like an array of strings when the actual string has already its own symbol. (Disclaimer: I know… barely anything about Unix relocation types, a bit more about those on DOS and even TOS.) 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#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Markus Wichmann dixit: >can check with readelf -r what the relocation types are. If they are not >relative, they will not be processed. Gotcha! They are all R_390_RELATIVE except for: 00045ff0 00110016 R_390_64 00042c58 u_ops + 70 00045ff8 00110016 R_390_64 00042c58 u_ops + 0 00047020 00110016 R_390_64 00042c58 u_ops + 80 00047088 00110016 R_390_64 00042c58 u_ops + 80 000470a8 00110016 R_390_64 00042c58 u_ops + b8 00047220 00110016 R_390_64 00042c58 u_ops + 80 00046900 00260016 R_390_64 00015af8 c_command + 0 00046940 00070016 R_390_64 00017238 c_exec + 0 00046ab0 00200016 R_390_64 00016a80 c_trap + 0 00047090 00250016 R_390_64 000430ac initvsn + 0 00047278 00550016 R_390_64 00047438 null_string + 2 That’s our missing strings. >Is it possible you are linking in the wrong start file? gcc -v should >output the command line it feeds to the linker. Should be correct: /usr/libexec/gcc/s390x-linux-gnu/13/collect2 -fno-lto -dynamic-linker /lib/ld-musl-s390x.so.1 -nostdlib -static -static -pie --no-dynamic-linker -o mksh /usr/lib/s390x-linux-musl/rcrt1.o /usr/lib/s390x-linux-musl/crti.o /usr/lib/gcc/s390x-linux-gnu/13/crtbeginS.o -L/usr/lib/s390x-linux-musl -L /usr/lib/gcc/s390x-linux-gnu/13/. -z relro -z now --as-needed -z text --eh-frame-hdr lalloc.o edit.o eval.o exec.o expr.o funcs.o histrap.o jobs.o lex.o main.o misc.o shf.o syn.o tree.o var.o ulimit.o --start-group /usr/lib/gcc/s390x-linux-gnu/13/libgcc.a /usr/lib/gcc/s390x-linux-gnu/13/libgcc_eh.a -lc --end-group /usr/lib/gcc/s390x-linux-gnu/13/crtendS.o /usr/lib/s390x-linux-musl/crtn.o HTH & HAND, //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#1067752: anacrontab(5) incorrectly says the only @period is @monthly (@yearly also supported)
Hi, I don’t think a /etc/cron.yearly/ should be created as directory, given that the default /etc/crontab never executes anything in it even if anacron may do. 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#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Dixi quod…
>Now I (or someone) is going to have to reduce that to a testcase, so
No success with that, unfortunately.
>But this does seem to be a toolchain bug: adding -static-pie to the
>glibc dynamic-pie link command and…
>
>(gdb) print initcoms
>$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494 "typeset", 0x0, 0xd942c
>"HOME", 0xda7d8 "PATH",
Wait, what?
(gdb) b main
Breakpoint 1 at 0xd820: file ../../main.c, line 785.
(gdb) print initcoms
$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494 "typeset", 0x0, 0xd942c "HOME",
0xda7d8 "PATH",
[…]
(gdb) r
Starting program: /home/tg/mksh-59c/builddir/full/mksh
Breakpoint 1, main (argc=1, argv=0x3ffa4d8) at ../../main.c:785
785 {
(gdb) print initcoms
$2 = {0x3fff7eda494 "typeset", 0x3fff7ee4548 "-r",
0x3fff7ee4ae0 "KSH_VERSION=@(#)MIRBSD KSH R59 2024/02/01 +Debian",
0x0, 0x3fff7eda494 "typeset",
[…]
While in musl:
(gdb) print initcoms
$1 = {0x414a4 "typeset", 0x0, 0x0, 0x0, 0x414a4 "typeset", 0x0, 0x40478 "HOME",
0x41d42 "PATH",
[…]
(gdb) r
Starting program: /home/tg/mksh-59c/builddir/static-musl/mksh
Breakpoint 1, main (argc=1, argv=0x3ffa498) at ../../main.c:785
785 {
(gdb) print initcoms
$2 = {0x3fff7fc14a4 "typeset", 0x0, 0x0, 0x0, 0x3fff7fc14a4 "typeset", 0x0,
0x3fff7fc0478 "HOME",
[…]
So the existing ones did get relocated, but the nullptrs stayed thusly.
Apparently, it *is* supported on glibc on s390x, mjt (qemu maintainer)
also said so in 2023.
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#1068348: xz-utils: Should activate trigger to force regenerating initramfs
Sebastian Andrzej Siewior dixit: >the older "previous" kernel has it. And that won’t be fixed even with a trigger. Used to be -uk all would, but (#1065698) that doesn’t work any more. Given how widespread the info already is and that it affects sid and a subset of trixie users, maybe go with just a NEWS.Debian entry for that? (I’d be more interested of what other backdoors there might be like joeyh indicated.) 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#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie → seems to be a toolchain bug after all, it does too hit glibc
Dixi quod…
>Hmm, actually… I could… test whether that one fixes static-pie
>on zelenka. Or at least the same approach. I’ll get back with
>report from that.
Having looked at the spec file, the only extra things the stock
specs do that the overriding specs don’t is:
*link:
[…] %{!static|static-pie:--eh-frame-hdr} […] %{static-pie:-static -pie
--no-dynamic-linker -z text} […]
instead of:
[…] %{static-pie:-static -pie --no-dynamic-linker} […]
The -Wl,-z,text makes TEXTRELs an error. Granted.
The -Wl,--eh-frame-hdr is added for anything that’s not a normal
static executable, however adding that to a musl build doesn’t
fix the problem either.
A bit of gdb-ing shows the problem, though: the source code has…
#define Ttypeset "typeset"
#define Tdr "-r"
//… (a variant of this is used for string sharing on ancient Unix)
static const char *initcoms[] = {
Ttypeset, Tdr, initvsn, NULL,
Ttypeset, Tdx, "HOME", TPATH, TSHELL, NULL,
[…]
};
It then iterates over these commands with:
for (wp = initcoms; *wp != NULL; wp++) {
c_builtin(wp);
while (*wp != NULL)
wp++;
}
This is where the extra output happens:
(gdb) print initcoms
$3 = {0x3fff7fc14a4 "typeset", 0x0, 0x0, 0x0, 0x3fff7fc14a4 "typeset", 0x0,
0x3fff7fc0478 "HOME",
[…]
Notice the nullptrs there where string pointers are expected.
It shows the same output when just loading the executable, i.e. this
isn’t a runtime issue.
Linking the exact same .o files with the exact same command minus
-static-pie gives:
(gdb) print initcoms
$1 = {0x103cb34 "typeset", 0x103e368 "-r",
0x103e73c "KSH_VERSION=@(#)MIRBSD KSH R59 2024/02/01 +Debian", 0x0,
0x103cb34 "typeset",
But this does seem to be a toolchain bug: adding -static-pie to the
glibc dynamic-pie link command and…
(gdb) print initcoms
$1 = {0xda494 "typeset", 0x0, 0x0, 0x0, 0xda494 "typeset", 0x0, 0xd942c "HOME",
0xda7d8 "PATH",
Now I (or someone) is going to have to reduce that to a testcase, so
we can detect static-pie viability before it’s committed to being used…
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#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!
Sometimes, it does not crash with a smashed stack but instead: Setting up sasl2-bin (2.1.28+dfsg1-6+b1) ... BDB0002 __fop_file_setup: Retry limit (100) exceeded saslpasswd2: generic failure dpkg: error processing package sasl2-bin (--configure): installed sasl2-bin package post-installation script subprocess returned error exit status 1 (I tried rebuilding it, but that didn’t fix it either.)
Bug#1068350: [musl] Re: Bug#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie
Rich Felker dixit: >I seem to recall the musl-gcc wrapper does not handle static-pie >right. Hmm. Inhowfar? And it does seem to work fine on the other architectures. >A real cross toolchain should. I fear that that’s out of question for Debian. I’ve got a github action test setup for mksh though, which also uses jirutka/setup-alpine to set up chroots of Alpine Linux for various architectures and uses them to build natively under qemu-user. I could use that to check static-pie? IIUC, these use “a real cross toolchain”, if natively; qemu-user adds an extra potential failure dimension though… >If there's an easy fix for the wrapper I'd be happy to merge it. Together with the MIPS fix? Hmm, actually… I could… test whether that one fixes static-pie on zelenka. Or at least the same approach. I’ll get back with report from that. 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#1068350: musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie
Szabolcs Nagy dixit: >the next culprit is gcc (each target can have their own gcc-13_13.2.0-23 >static pie specs) or the way you invoked gcc (not visible As I wrote earlier, though with more flags. Dropping all the -D… and -W… and -I… and other irrelevant ones: musl-gcc -Os -g -fPIE -fno-lto -fno-asynchronous-unwind-tables -fno-strict-aliasing -fstack-protector-strong -fwrapv -c … musl-gcc -Os -g -fPIE -fno-lto -fno-asynchronous-unwind-tables -fno-strict-aliasing -fstack-protector-strong -fwrapv -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -static -static-pie -fno-lto -o mksh *.o Same for both. You can see the full log by activating the [64]Installed and [71]Installed links respectively on https://buildd.debian.org/status/package.php?p=mksh and skipping to 'compilation of mksh in static-musl' to get to the beginning of the configure phase for that. >are you sure static pie works on these targets? No ;-) That’s why I reported this issue. I had just enabled it for the musl builds, as the security people like that more than normal static. Thanks for looking, //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#1068350: musl: miscompiles (runtime problems) on s390x with static-pie
retitle 1068350 musl: miscompiles (runtime problems) on riscv64 and s390x with static-pie thanks Dixi quod… >For some reason, mksh built with static-pie behaves bogus: Exact same behaviour on the riscv64 buildd. bye, //mirabilos -- /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against ╳ HTML eMail! Also, ╱ ╲ header encryption!
Bug#1068350: musl: miscompiles (runtime problems) on s390x with static-pie
Package: musl Version: 1.2.5-1 Severity: normal Tags: upstream X-Debbugs-Cc: t...@debian.org, m...@lists.openwall.com ||/ Name Version Architecture Description +++-==---== ii binutils 2.42-4 s390xGNU assembler, linker and binary utilities ii gcc4:13.2.0-7 s390xGNU C compiler ii gcc-13 13.2.0-23s390xGNU C compiler For some reason, mksh built with static-pie behaves bogus: (sid_s390x-dchroot)tg@zelenka:~/mksh-59c$ env -i ./builddir/static-musl/mksh -c 'echo hi' typeset EPOCHREALTIME typeset IFS typeset PATH typeset PATHSEP typeset PS2 typeset PS3 typeset PS4 typeset PWD typeset -i SECONDS typeset TMOUT hi If I build without static-pie, just static, things work: (sid_s390x-dchroot)tg@zelenka:~/mksh-59c$ env -i ./builddir/static-musl/mksh -c 'echo hi' hi If I replace the -static with -fPIE -pie (and build the .o files with -fPIE): (sid_s390x-dchroot)tg@zelenka:~/mksh-59c/builddir/static-musl$ file mksh mksh: ELF 64-bit MSB pie executable, IBM S/390, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-s390x.so.1, with debug_info, not stripped (sid_s390x-dchroot)tg@zelenka:~/mksh-59c/builddir/static-musl$ ./mksh -c 'echo test' test (it was done in the same subdirectory, ignore the pathname) Unfortunately, this is not easily reduced… it, however, i̲s̲ reproducible on the s390x porterbox. The code works with musl and static-pie on all other Debian architectures on which musl is available and static-pie is not broken (see #1068302). -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: s390x Kernel: Linux 6.1.0-18-s390x (SMP w/2 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect -- no debconf information
Bug#1068326: bookworm-pu: package mksh/59c-28+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm X-Debbugs-Cc: m...@packages.debian.org, t...@mirbsd.de Control: affects -1 + src:mksh User: release.debian@packages.debian.org Usertags: pu I would like to ask for pre-approval to uploading a proposed stable update for mksh. [ Reason ] There was a discussion on d-devel that ended in suggesting that the /etc/shells file should have both aliased paths for shells, not just the canonical paths, since users could have $SHELL set to either, and some software checks that $SHELL is in shells(5) for security reasons. This change landed in sid and is included here. I’ve also fixed the path wildcards for musl on ARM EABI. I’ve also taken liberty to cherry-pick a few upstream bugfixes and their relevant tests and to include two tiny FAQ updates regarding POSIX compliance and future compatibility/directions. [ Impact ] Users of mksh can run into problems with privilege elevation tools if they are on a usrmerge’d system if this is not applied, and shell scripts can fail or even segfault. [ Tests ] The backported fixes have tests covering them, which all pass when I build this in a nōn-usrmerged bookworm cowbuilder chroot (mirroring the buildd setup). I tested the maintainer script changes by installing the resulting .deb in a copy of both the nōn-usrmerged bookworm chroot and a usrmerged sid chroot. [ Risks ] The patches are small and easy to review and have been in use in sid for a while, except the three-line postinst change, which I manually tested (and inspected both dash and bash to ensure that test -ef does the right thing), so the risk is low. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] (see Reason above) [ Other info ] I’ve split the fixes into easier to review individual patches for this upload, as git is “patches-applied” here, but I also verified the resulting trees are identical. While the test if the system is merged could possibly be removed, I decided to leave it in as it’s easier to backport this way. (When merging later, either the next upgrade or dpkg-reconfigure of mksh fixes up /etc/shells next, or the usrmerge utility does so.) diff -Nru mksh-59c/debian/changelog mksh-59c/debian/changelog --- mksh-59c/debian/changelog 2023-04-28 23:34:20.0 +0200 +++ mksh-59c/debian/changelog 2024-04-03 14:19:25.0 +0200 @@ -1,3 +1,15 @@ +mksh (59c-28+deb12u1) bookworm; urgency=low + + * d/p/typeset-p-fix.diff, d/p/dot-args-fix.diff, +d/p/crash-nest-bashism.diff: cherry-pick upstream bugfixes + * d/p/metadata-update.diff: cherry-pick relevant documentation +changes and adjust user-visible version to indicate the +above fixes were applied + * fix paths missing wildcards in lintian overrides, postinst, prerm + * cherry-pick usrmerge /etc/shells change (Closes: #1063905) + + -- Thorsten Glaser Wed, 03 Apr 2024 14:19:25 +0200 + mksh (59c-28) unstable; urgency=medium * Revert 59c-27 changes as mksh is, surprisingly, still a key diff -Nru mksh-59c/debian/mksh.lintian-overrides mksh-59c/debian/mksh.lintian-overrides --- mksh-59c/debian/mksh.lintian-overrides 2023-04-28 23:00:04.0 +0200 +++ mksh-59c/debian/mksh.lintian-overrides 2024-04-03 13:25:50.0 +0200 @@ -17,8 +17,8 @@ # correct placement mksh: executable-in-usr-lib [usr/lib/diet/bin/mksh] mksh: executable-in-usr-lib [usr/lib/klibc/bin/mksh] -mksh: executable-in-usr-lib [usr/lib/*-linux-musl/bin/mksh] +mksh: executable-in-usr-lib [usr/lib/*-linux-musl*/bin/mksh] # these are to clean old add-shell(8) damage, not actually dereferenced -mksh: bin-sbin-mismatch usr/bin/mksh -> bin/mksh [postinst] -mksh: bin-sbin-mismatch usr/bin/mksh -> bin/mksh [prerm] +mksh: bin-sbin-mismatch usr/bin/mksh* -> bin/mksh* [postinst] +mksh: bin-sbin-mismatch usr/bin/mksh* -> bin/mksh* [prerm] diff -Nru mksh-59c/debian/mksh.postinst mksh-59c/debian/mksh.postinst --- mksh-59c/debian/mksh.postinst 2023-04-28 23:00:04.0 +0200 +++ mksh-59c/debian/mksh.postinst 2024-04-03 13:27:52.0 +0200 @@ -151,14 +151,18 @@ test -e /usr/bin/ksh || test -h /usr/bin/ksh || \ ln -s /bin/ksh /usr/bin/ksh + # determine usrmerge status + um=+ + test /usr/bin/mksh -ef /bin/mksh || um=- + # add us to /etc/shells and clean up old add-shell-caused damage # shellcheck disable=SC2046 mogrifyshells + /bin/mksh /bin/mksh-static \ - - /usr/bin/mksh /usr/bin/mksh-static \ - $(for x in \ + $um /usr/bin/mksh /usr/bin/mksh-static \ + - $(for x in \ /usr/lib/klibc/bin \ /usr/lib/diet/bin \ - /usr/lib/*-linux-musl/bin \ + /usr/lib/*-linux-musl*/bin \ ; do echo "$x/mksh"
Bug#1068324: lintian: patch-not-forwarded-upstream for upstream patches
Package: lintian Version: 2.116.3 (at least bookworm’s) lintian complains about… I: mksh source: patch-not-forwarded-upstream [debian/patches/typeset-p-fix.diff] … for patches whose DEP 3 metadata clearly state they are a cherry-pick or backport from upstream. Here (cherry-pick): Origin: commit:10065BC69BE555D6721 DEP 3 says the Forwarded header is only applicable for patches that don’t originate upstream. bye, //mirabilos
Bug#1068024: revert to version that does not contain changes by bad actor
Joey Hess dixit: >--- orig/dpkg-1.22.6/debian/control2024-03-02 21:30:15.0 -0400 >+++ dpkg-1.22.6/debian/control 2024-03-30 13:14:37.746223895 -0400 > # Version needed for multi-threaded decompressor support. >- liblzma-dev (>= 5.4.0), >+ liblzmaunscathed-dev, The comment probably needs adjusting as well. > # Version needed for multi-threaded decompressor support. >- xz-utils (>= 5.4.0) , >+ xz-utils , dito > # Version needed for multi-threaded decompressor support. >- liblzma-dev (>= 5.4.0), >+ liblzmaunscathed-dev, idem > # Version needed for multi-threaded decompressor support. >- xz-utils (>= 5.4.0), >+ xz-utils, el mismo > # Version needed for multi-threaded decompressor support. >- xz-utils (>= 5.4.0), >+ xz-utils, the same >--- orig/dpkg-1.22.6/debian/libdpkg-dev.install2024-02-04 >22:31:16.0 -0400 >+++ dpkg-1.22.6/debian/libdpkg-dev.install 2024-03-30 13:25:27.043840706 >-0400 >@@ -1,4 +1,5 @@ > usr/include/dpkg/*.h >-usr/lib/*/pkgconfig/libdpkg.pc >-usr/lib/*/libdpkg.a >+usr/lib/pkgconfig/libdpkg.pc >+usr/lib/libdpkg.a Why, exactly, does the library move out of the M-A directory here? (Probably a question for guillem though.) >+usr/lib/libdpkg.la IIRC we were not shipping libtool files, were we? Or am I confusing this with some BSD ports/packages now? 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#1068304: lintian: static-pie misdetected as libraries
Package: lintian Version: 2.117.0 Severity: normal X-Debbugs-Cc: t...@mirbsd.de lintian misdetects static-pie binaries such as these which can now be created by musl, but TTBOMK also from glibc: W: mksh: mismatched-override statically-linked-binary [bin/lksh] [usr/share/lintian/overrides/mksh:2] (no longer matches because it’s no longer recognised as statically linked) W: mksh: shared-library-lacks-prerequisites [bin/lksh] static-pie executables look like this: t: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped (bullseye file(1)) t: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, with debug_info, not stripped (sid file(1)) By contrast, nōn-PIE static executables look like this: /bin/lksh: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped (both versions) And shared libraries look like this: t.dll: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, with debug_info, not stripped (both versions) My guess is that lintian looks at 'dynamically linked' either from inspecting file(1) output or by doing the same thing that bullseye’s file(1) did to determine whether an object is shared or not, without taking into account whether the object is an executable or not, which the ELF headers have flags for. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 5.10.0-26-amd64 (SMP w/8 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 /usr/bin/lksh Init: sysvinit (via /sbin/init) Versions of packages lintian depends on: ii binutils2.42-4 ii bzip2 1.0.8-5.1 ii diffstat1.66-1 ii dpkg1.22.6 ii dpkg-dev1.22.6 ii file1:5.45-3 ii gettext 0.21-14+b1 ii gpg 2.2.40-3 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.16.0-1 ii libapt-pkg-perl 0.1.40+b5 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-2+b3 ii libcapture-tiny-perl0.48-2 ii libclass-xsaccessor-perl1.19-4+b3 ii libclone-perl 0.46-1+b2 ii libconfig-tiny-perl 2.30-1 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.37-1+b2 ii libdata-dpath-perl 0.59-1 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-3 ii libdevel-size-perl 0.83-2+b3 pn libdigest-sha-perl ii libdpkg-perl1.22.6 ii libemail-address-xs-perl1.05-1+b3 ii libencode-perl 3.21-1+b1 ii libfile-basedir-perl0.09-2 ii libfile-find-rule-perl 0.34-3 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-3 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.025-1 ii libipc-run3-perl0.049-1 ii libjson-maybexs-perl1.004005-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.144-1 ii libperlio-gzip-perl 0.20-1+b3 ii libperlio-utf8-strict-perl 0.010-1+b2 ii libproc-processtable-perl 0.636-1+b2 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.004+ds-1+b2 ii libsereal-encoder-perl 5.004+ds-1+b2 ii libsort-versions-perl 1.62-3 ii libsyntax-keyword-try-perl 0.29-2 ii libterm-readkey-perl2.38-2+b3 ii libtext-levenshteinxs-perl 0.03-5+b3 ii libtext-markdown-discount-perl 0.16-1+b2 ii libtext-xslate-perl 3.5.9-2 ii libtime-duration-perl 1.21-2 ii libtime-moment-perl 0.44-2+b3 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-2+b2 ii liburi-perl 5.28-1 ii libwww-mechanize-perl 2.18-1 ii libwww-perl 6.77-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b3 ii libyaml-libyaml-perl0.89+ds-1+b1 ii lzip [lzip-decompressor]1.24.1-1 ii lzop1.04-2 ii man-db 2.12.0-4 ii patchutils 0.4.2-1 ii perl
Bug#1068302: musl: static-pie support questionable: segfault on m68k, no ASLR on sh4
Package: musl
Version: 1.2.5-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de, m...@lists.openwall.com
On m68k (ARAnyM Atari TT/Falcon VM):
root@aranym:~ # cat t.c
#include
int main(void) {
printf("main = 0x%lX\n", (unsigned long)main);
return (0);
}
root@aranym:~ # musl-gcc -fPIE -static -static-pie -fno-lto -o t t.c
root@aranym:~ # file t
t: ELF 32-bit MSB pie executable, Motorola m68k, 68020, version 1 (SYSV),
static-pie linked, with debug_info, not stripped
root@aranym:~ # ./t
Segmentation fault
139|root@aranym:~ # musl-gcc -fPIE -static-pie -fno-lto -o t t.c
root@aranym:~ # file t
t: ELF 32-bit MSB pie executable, Motorola m68k, 68020, version 1 (SYSV),
static-pie linked, with debug_info, not stripped
root@aranym:~ # ./t
Segmentation fault
The same test program in a qemu-user-based sh4 buildd:
main = 0x46A4
main = 0x46A4
main = 0x46A4
On amd64, arm64, armel, armhf, i386, loong64, mips64el¹, ppc64el,
riscv64 and s390x, it DTRT.
① with a manual hack due to the still-existing musl-gcc wrapper bug:
muslspec=$topdir/xmusl.spec
case $DEB_HOST_ARCH in
(mipsel) cat /usr/lib/mipsel-linux-musl/musl-gcc.specs ;;
(mips64el) cat /usr/lib/mips64el-linux-musl/musl-gcc.specs ;;
esac >"$muslspec" || exit 255
printf '%s\n' 1a '%rename cc1 old_cc1' . \
'/^[*]cc1:/+1s/^/%(old_cc1) /' w q | \
ed -s "$muslspec" || exit 255
test -s "$muslspec" || exit 255
muslgcc="$CC -specs $muslspec"
-- System Information:
Debian Release: trixie/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: m68k
Kernel: Linux 6.6.15-m68k (UP)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/lksh
Init: sysvinit (via /sbin/init)
-- no debconf information
Bug#1067207: mesa: switch statement too large, might need -mlong-jump-table-offsets
retitle 1067207 mesa: [m68k] switch statement too large, needs -mlong-jump-table-offsets tags 1067207 + patch thanks >Adding the -mlong-jump-table-offsets flag to CFLAGS on m68k should That did it. I built with… APPEND CFLAGS -mlong-jump-table-offsets APPEND CXXFLAGS -mlong-jump-table-offsets … in /etc/dpkg/buildflags.conf in the chroot. An equivalent patch for d/rules would be: --- debian/rules~ 2024-04-01 23:29:11.0 +0200 +++ debian/rules2024-04-01 23:31:39.379936168 +0200 @@ -18,7 +18,11 @@ export DEB_BUILD_MAINT_OPTIONS=optimize=-lto -ifeq (,$(filter $(DEB_HOST_ARCH), armhf ppc64el sh3 sh4)) +ifneq (,$(filter $(DEB_HOST_ARCH), m68k)) +# This library has huge jump tables: Debian #1067207 +buildflags = \ + $(shell DEB_CFLAGS_MAINT_APPEND='-Wall -mlong-jump-table-offsets' DEB_CXXFLAGS_MAINT_APPEND='-Wall -mlong-jump-table-offsets' dpkg-buildflags --export=configure) +else ifeq (,$(filter $(DEB_HOST_ARCH), armhf ppc64el sh3 sh4)) buildflags = \ $(shell DEB_CFLAGS_MAINT_APPEND=-Wall DEB_CXXFLAGS_MAINT_APPEND=-Wall dpkg-buildflags --export=configure) else While there, you might want to consider changing these nested ifs to the new gmake else-if model or perhaps sorting it, or even changing to something like: --- debian/rules~ 2024-04-01 23:29:11.0 +0200 +++ debian/rules2024-04-01 23:36:10.368947470 +0200 @@ -18,20 +18,25 @@ export DEB_BUILD_MAINT_OPTIONS=optimize=-lto -ifeq (,$(filter $(DEB_HOST_ARCH), armhf ppc64el sh3 sh4)) -buildflags = \ - $(shell DEB_CFLAGS_MAINT_APPEND=-Wall DEB_CXXFLAGS_MAINT_APPEND=-Wall dpkg-buildflags --export=configure) -else - ifneq (,$(filter $(DEB_HOST_ARCH), armhf)) - # Workaround for a variant of LP: #725126 - buildflags = \ - $(shell DEB_CFLAGS_MAINT_APPEND="-Wall -fno-optimize-sibling-calls" DEB_CXXFLAGS_MAINT_APPEND="-Wall -fno-optimize-sibling-calls" dpkg-buildflags --export=configure) - else -# Workaround for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143 -buildflags = \ - $(shell DEB_CFLAGS_MAINT_APPEND="-Wall -O1" DEB_CXXFLAGS_MAINT_APPEND="-Wall -O1" dpkg-buildflags --export=configure) - endif +DEB_CFLAGS_MAINT_APPEND := -Wall +DEB_CXXFLAGS_MAINT_APPEND := -Wall +ifneq (,$(filter $(DEB_HOST_ARCH), armhf)) +# Workaround for a variant of LP: #725126 +DEB_CFLAGS_MAINT_APPEND += -fno-optimize-sibling-calls +DEB_CXXFLAGS_MAINT_APPEND += -fno-optimize-sibling-calls +else ifneq (,$(filter $(DEB_HOST_ARCH), m68k)) +# This library has huge jump tables: Debian #1067207 +DEB_CFLAGS_MAINT_APPEND += -mlong-jump-table-offsets +DEB_CXXFLAGS_MAINT_APPEND += -mlong-jump-table-offsets +else ifneq (,$(filter $(DEB_HOST_ARCH), ppc64el sh3 sh4)) +# Workaround for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143 +DEB_CFLAGS_MAINT_APPEND += -O1 +DEB_CXXFLAGS_MAINT_APPEND += -O1 endif +buildflags = $(shell \ + DEB_CFLAGS_MAINT_APPEND='$(DEB_CFLAGS_MAINT_APPEND)' \ + DEB_CXXFLAGS_MAINT_APPEND='$(DEB_CXXFLAGS_MAINT_APPEND)' \ + dpkg-buildflags --export=configure) EGL_PLATFORMS = x11 GALLIUM_DRIVERS = swrast 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#1068163: glade: please do not B-D on webkit on m68k
Source: glade Version: 3.40.0-5 X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org As hinted in another ticket, please extend the exclusion of webkit [not ia64 kfreebsd-any] to also exclude m68k. (You probably can remove kfreebsd-any at the same time.) I’m still looking into the B-D of src:webkit2gtk, but the build logs of that package itself also don’t look promising¹, and glade is in some dependency chains. ① as in, needs lots of manual effort to fix its assumptions that aren’t guaranteed by C/POSIX (and don’t hold true on all architectures, m68k in this case) Thanks, //mirabilos
Bug#1067582: gnuplot: please provide a profile to break B-D cycle
Hi Dima, >- Today leptonlib Build-Depends on gnuplot-nox only if !nocheck. So if > you build leptonlib with testing disabled, there's no dependency on > gnuplot oh, that is maybe new? But I see other packages depending on gnuplot-nox, so this would still be very helpful. >- Today the gnuplot source package has a hard Build-Depends on wxt and > qt. Removing either of those (even in a specific profile) would make > it impossible to build gnuplot-qt and gnuplot-x11 packages with the > same set of functionality they normally have. Yes, I just hacked the package to just not build these two packages, basically by commenting lines from d/rules and removing the paragraphs from d/control (although the -N flag for dh would also do) and I got the expected gnuplot-nox and no -qt/-x11. (m68k only, the other arches will need this as well, so… still needed.) > If a profile was added > to loosen either of these dependencies, but that dramatically changed > the end product, would that be useful? Build profiles are allowed to remove packages from the result, as long as the other packages are not drastically changed. Since gnuplot builds x11, qt and nox separately anyway (and arch:all is also built separately), that would work. It may be best to look at another package where a build profile is used to elide a binary package to have an example of how this can go. If you want, I can search one for you, I’ve worked with several of them during the last few weeks. Thanks, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1068024: Potential solution to your downgrade problem in dpkg
Joshua Hudson dixit: >2) Statically link all the decompressor libraries into dpkg. Yes this means Totally no. Also, at this point in time, I’m pretty sure that new external suggestions are… not very helpful. The situation is being analysed by a cross-team taskforce, please let them do the already-stressing job ☻ bye, //mirabilos -- /⁀\ The UTF-8 Ribbon ╲ ╱ Campaign against ╳ HTML eMail! Also, ╱ ╲ header encryption!
Bug#1068024: revert to version that does not contain changes by bad actor
Christoph Anton Mitterer dixit: >Is anyone on the Debian side trying to figure out how far we've been >practically affected? Yes, a multi-team task force is working on it and will inform users once it is known how to proceed, inclusing how much to throw away and rebuild. bye, //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#1068024: revert to version that does not contain changes by bad actor
Pierre Ynard dixit: >version into the Debian archive, as seen in #1067708. To quote Thorsten >from that thread: > >> Very much *not* a fan of NMUs doing large changes such as >> new upstream versions. > >I can't say why exactly he would not be a fan, but with hindsight that >was an interesting call. It turned out to indeed be related, although I cannot blame Sebastian for not spotting it, as well as it was hidden. I actually wrote about that earlier on Fedi: (Markdown formatting lost here though) | I was considering replying to this comment on the “please update xz | package” bugreport earlier with that the discussion is not irrelevant | and that it’s the maintainer’s responsibility on new upgrades to check | for new legal issues and “other hidden gems”. | | I didn’t because I didn’t want to bother going in with an annoyed | self-righteous “user”. | | Now it turns out all three of the involved ones were “string + number | @ freemailer” #JiaT75 sockpuppets, so it’s probably okay I didn’t | bother. | | Not that I blame Sebastian — it was very well hidden, and even my | usual diffing between old and new version would not have found it. | | I do take away from this to also check the diff between VCS repo at | the time of the release and release tarball. Perhaps also between | branch and tag if they, like Apache Tomcat, introduce extra commits | there. >Is xz-utils going to be maintained? Will we want to keep in the archive >an unmaintained low-level library - low-level as in, susceptible of >getting pulled as a dependency in lots of places - and rely on it for >components such as dpkg? That scenario you describing here would actually be much less of a problem. The problem comes when the library in that state then does get updates that probably are not even necessary but shiny enough people demand them. bye, //mirabilos (also a Debian Developer, despite the From) -- 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#1068024: revert to version that does not contain changes by bad actor
Christoph Anton Mitterer dixit: >Can we be confidently sure that going back to 5.4.5 is enough? No. >The last one, still from Lasse Collin seems to be 5.4.1: In this bugreport, we’re discussing going back to before any contributions by the adversary. To see whether it’s an option at all (and it sounds like a sensible step right now) which joeyh confirmed (thanks). 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#1068024: revert to version that does not contain changes by bad actor
Aurelien Jarno dixit: >Having dpkg in that list means that such downgrade has to be planned >carefully. Right. Not an argument against, though. Instead, this is a very good idea. What symbols are new? Can we somehow stub them, or at least where those are used? Or change the soname, so that the old and new-older versions are coïnstallable for during the upgrade? bye, //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#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#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
Wookey dixit: >And it worked beatifully. Thanks. Nice! >I'll try doing openjdk-20 next. You’ll want 21 as 20 has not got the t64 treatment. gl hf, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
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#1067639: ping Bug#1067639: sasl2-bin: terminates with smashed stack
any idea?
Bug#1067582: ping?
this would help a lot with the t64 transition, as Qt is proving difficult on some architectures
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
Hi Wookey, >OK, got those. but that's just binaries. It was the source changes I >was looking for (or did I misunderstand and you didn't actually make >any of those?), Yes, I did not make any source changes. These were the last binaries from before the t64 transition (I downloaded the .deb files unchanged) with just control.tar.xz/control changed to allow installation given the relevant libraries were already rebuilt for t64. > but actually having an openjdk binaries is very useful >too to satisfy the self-dependency without more faff. Yes, that was their purpose. >I'm no java expert so if anything breaks or it gets more complicated >than 'get the right build-deps in (with care for t64-libs) somehow' I >will indeed be asking questions :-) Right. I’m no expert either, though :/ >> What was the actual problem with uploading the images you built? Just >> not having any corresponding source? Or something more complicated? > >Answering my own question: There have been a couple of new openjdk-17 >uploads (latest is: 17_17.0.11~7ea-1) so Thorsten's bootstrap build >(17.0.10+7-1) is out of date. Yes, exactly: dak lacked the 17.0.10+7.orig.tar.* because sid already moved to 17.0.11~7ea.orig.tar.* >So I now have all the pieces (on armhf, not checked armel yet but >hopefully it matches) Depends, but 'apt install /tmp/*.deb' will tell you ;-) >The build failed: > >An exception has occurred in the compiler (17.0.10). Please file a bug against >the Java compiler via the Java bug reporting page (https://bugreport.java.com) >after checking the Bug Database (https://bugs.java.com) for duplicates. >Include your program, the following diagnostic, and the parameters passed to >the Java compiler in your report. Thank you. >java.io.UncheckedIOException: java.nio.file.FileSystemException: .: Value too >large for defined data type > >Don't worry about this. It's a an issue to do with building for 32 bit >inside qemu on a 64-bit machine. I'll stop doing that and use real >hardware :-/ Ouch. I was just wondering which filesystem you used, but yes, there’s that known combined qemu/kernel/libc issue which cbmuser is also constantly running into. I think switching to… sgixfs I think? also makes it work, but I’m not sure. https://sourceware.org/bugzilla/show_bug.cgi?id=23960#c73 sgixfs and btrfs, yeah, ext4 is problematic. But apparently, LFS should fix this but Java is again special in that it’s still problematic there. Were you using qemu-user? qemu-system has its own kernel and “should” be fine, modulo the usual qemu issues. Real hardware is better (for many architectures even necessary). 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#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On Wed, 27 Mar 2024, Wookey wrote: >I looked at this last week, but got stuck because openjdk-17's >build-deps included graphviz Build-Depends-Indep: graphviz, pandoc You don’t need that. Use dpkg-checkbuilddeps -B, or manual inspection of the .dsc (packages.d.o does show the difference between adep and idep but not the profiles, unfortunately, and these can be key in ordering decisions). >another blocked chain with ghostscript,cups and libgtk2 conflicting >about their t64 status. You do need the t64 versions of all that, and the latest openjdk-17 fixed the issue with libcups2 (Ubuntu initially forgot to move that to t64 while Debian did that early, and openjdk-?? followed the former). > apt : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed You should get that rebuilt, yes. On the other hand, if everything else is falling into place, it’s not a problem for apt to uninstall itself just in that one build chroot ☻ > libasound2t64 : Breaks: libasound2 (< 1.2.11-1) but 1.2.10-3 is to be > installed > libcups2t64 : Breaks: libcups2 (< 2.4.7-1.2) but 2.4.7-1+b1 is to be installed > libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2 is to be > installed These are fine. > libcups2 : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed Force that away; nothing from this is actually used during the openjdk build in a way sufficient to impact the build. >But dose now says there is a solution, unlike last week. Oh, dose… right… here I was checking all of them manually ^^ (which did give me a better impression of where to break the cycles and what to upload earlier). >> openjdk-21 is in a similar situation, build-depending on itself, while >> openjdk-22 and openjdk-23 build-depend on -21 and -22 respectively. >I presume the same, but don't actually know how old a java you can use >to bootstrap each newer java. Is it always just one version? AIUI it’s always just one version; I know it was so until 17, but I don’t think this has loosened (I asked in IRC, but got no answer until I went to sleep). >> Presumably once we have a single OpenJDK version that is installable, >> it would be possible to step through 18,19,20,21 building each version >> with the previous one. You’d have to patch them to both address the t64 issues and make it imply nocheck (or quinn-diff doesn’t pick it up as installable). It’s best to get at least 17 and 21 (which AIUI is the one we’ll want for trixie?) built this way. I think, unless users complain, we can these days go without 8 and probably even without 11. (You’d be surprised at the amount of users wanting 8, so I now provide those in a private repo of mine, but so far amd64/i386-only has sufficed for those. For the purposes for which 8 is still in sid, dropping armel and armhf will _most likely_ also suffice; ELTS still wants them, but rebuilt in jessie and stretch chroots so there is no re‐ bootstrapping to be done.)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On Tue, 26 Mar 2024, Jeffrey Walton wrote: >Nothing beats a native compile in your basement. Yes, definitely. >> Do they run stock Debian armhf? > >So the CubieTruck is embarrassingly down level: Oofff… >The Wandboard is doing better: Right, close enough anyway. >I don't mind shipping to Europe if you don't mind paying the VAT. I >think you will be the fourth or fifth Debian maintainer I've sent >hardware to. So sending from outside the eurozone, that can get tricky fast (depending on the value, they also want import duties on top), I think that might just be overkill for a oneshot helping out. Let’s see if I can get an account on a project box first, or work with someone who has. (I’m not intending to add going into ARM development on top of what I already try to balance… right now, I’m mostly helping m68k through t64, so Adrian does not burn out, he’s also got sh4 and powerpc to do, and the whole rest of d-ports with the mini-dak trouble of keeping old binary packages around.) But I do thank you for that offer. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
Hi Jeffrey, I’m answering back from the $dayjob address because Googlemail cannot communicate with normal mailservers. >I can send you two dev boards, if you want them. The first is >Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second is >CubieTruck 5 (Cortex-A7, ARMv7 with NEON and VFPv4). Both work, but I >don't use them much anymore. I've mostly moved on to Aarch64. That is certainly an option, if you don’t want them any more and want to ship them to .de, although it’ll likely take longer than just getting access on a suitable project machine. RAM is tight on them, but with swap the compiling should work. Both seem to have serial console, good. Do they run stock Debian armhf? Thanks, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi,
>In the -ports world, hppa doesn't have Java anyway, while m68k, powerpc
>and sh4 seem to have had a re-bootstrap at some point; so I think it's
>only the release architectures armel and armhf that have a problem here.
I hacked that, and I tried to do armel and armhf as well but
dak stopped me, whereas mini-dak was not as strict.
I did the observation that doko changed their source packages
to have the binaries Recommend instead of Depend on the libraries
in question. (Unfortunately neither before the transition started
nor coordinated with the openjdk-8 maintainer (me).)
I downloaded the latest binary packages of openjdk-{8,11,17,21},
changed all references to the libraries in question to refer to
their t64 counterparts, bumped the version number, repacked the
.deb files and updated the .changes files as if to do a binNMU.
After uploading, I used wanna-build to set the priority high so
they get rebuilt before someone considers using them.
mini-dak accepted these, but dak requires that the archive has
the corresponding source available, and since new versions (the
part before the Debian hyphen-minus) had already been uploaded,
it did not have them at hand any more either.
The rebuild process succeeded, as openjdk building itself does
indeed not use the libraries in question (or at least those
parts of their interface that are time_t-relevant).
I don’t have access to a fast armel machine (only an RPi 1) and
to no armhf machine, so I’m not in the situation of throwing the
.debs from above into a chroot to rebuild the current sources.
I *was* considering writing to whereever the t64 transition was
coordinated for ARM, we’re using #debian-ports on OFTC for the
d-ports architectures and I couldn’t find out where to write to
for arm{el,hf}, so this mail of yours comes at a good time ;-)
The options for the armel/armhf porters are to either get the
.debs from me, install them in a chroot, and then the other B-D,
and rebuild the packages, or to use dpkg --force-depends to
install the dependencies (which makes it hard to use apt to
install the other ones unless you also edit /var/lib/dpkg/status
by hand first, something I was already used to from my reviving
m68k back in 2012–2015) into the chroot then rebuild there.
I will gladly help if it’s made possible for me to help. This
cannot be done on a porterbox because it’s still impossible to
either install arbitrary .debs into a chroot there or to obtain
root in the chroot to be able to force installation in the absence
of some Depends.
So if you have a fast armhf box or two, ideally with chroots
already made for sid, which you don’t mind temporarily giving
me root on, I’m in, otherwise I’ll answer questions from these
doing that work if needed.
I *think* 8/11/17/21 are the only versions we need to handle.
This does save us from having to rebootstrap this.
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
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (MirBSD)
Comment: ☃ ЦΤℱ—８ ☕☂☄
iQIcBAEBCQAGBQJmA0vXAAoJEHa1NLLpkAfg0ZQQAI7P7qoVfADQrrsuNHAShvTB
lRvuK1br7bHRmqUx89dDwjOG1k0Xji3X3OURZldlhPCk99SJxQP3DLoCX5cmCzIA
IDyq+GoxREjJ/uyb4b6/qTAgSh7ZdRqxEfbVLsukL1i+wRs6dNw2Wg64i/R538jE
+yncg7zMyrWSA+3815i7BRfdMZBEk9E1qgW3hlnhueVfgANuyBLzzJchSstjunqE
0OcIukVQ30HaWaALmAfGcl7lcfM0sUFXL+EVpA8aBsVWNzZHtMIPnmI+yx8X4NOo
BOkfcYbPI928VZ/91meibSb9FXk8ShnO+zv+gU6dX74RlVoqOIeg6UQ/r2Cy+Up9
ssnksqTWTSkw1/n9bRNNiU8/O4kI5xV6FCUk2CaOsk+diQfXpoga50TR6DRM52tp
mjtBetkI1qK9vA0Y1VS+KoPp/FDYwFBKXiU3Jax9L7koaT5wGCurILqNTbDGVe19
2nmnphBUeIFniPByiItSEv7jH9GgxZyrwRvonYYpDXNeXFa0ymTNzKzrIG2ZqMrz
LcELgtIb6OD+WDYajUMOlTRBj2N9rFodruKyMcdUfc4so3OoFnS3cOdBvWBk/NdX
sFRgES39Ak5xgA3f4hP2ba03KZOFH2iIT3M8ZtZhH7eOIdhErKIUG0t6hxpWFdiV
ntE5WUlefRxovhbTOXKa
=KoS1
-END PGP SIGNATURE-
Bug#1067708: new upstream versions as NMU vs. xz maintenance
Very much *not* a fan of NMUs doing large changes such as new upstream versions. But this does give us the question, what’s up with the maintenance of xz-utils? Same as with the lack of security uploads of git, which you also maintain, are you active? Are you well? 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#1067647: google-perftools: FTBFS: #error Could not determine cache line length - unknown architecture
Source: google-perftools Version: 2.15-3 Severity: important X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org In file included from src/common.h:43, from src/common.cc:43: src/base/basictypes.h:390:5: error: #error Could not determine cache line length - unknown architecture 390 | # error Could not determine cache line length - unknown architecture | ^ make[1]: *** [Makefile:4970: src/libtcmalloc_internal_la-common.lo] Error 1
Bug#1067646: llvm-toolchain-17: please enable m68k build
Source: llvm-toolchain-17 Version: 1:17.0.6-9 Severity: important X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org Attempts to build llvm-toolchain-15 (needed for qt6) and 17 (which is apparently what everyone should switch to, but 16 might also need it) fail at configure stage: The target `M68k' is experimental and must be passed via LLVM_EXPERIMENTAL_TARGETS_TO_BUILD. Please do so ;-) I guess.
Bug#1067643: webkit2gtk: please use architecture whitelist for libseccomp-dev B-D
>Please use libseccomp-dev B-D only on architectures where it >actually exists (i.e. is not in state uncompiled). > >webkit2gtk is a B-D for glade, which is depended on by the >Xfce stack, as far as I can tell, whose t64 transition this blocks. Might be useful to consider not depending on webkit2gtk in glade for more architectures, especially these where the ratio of the amount of users of the webkit integration by the chance of the webkit packages being kept up to date is small; I see glade does already have a mechanism to not use webkit on Itanic for example. Feel free to reassign or clone-and-reassign depending on which of these could get implemented. 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#1067644: gcc-12: BD-Uninstallable on m68k due to gnat-11 vs gnat-12
Source: gcc-12 Version: 12.3.0-15 gcc-12 is BD-Uninstallable on m68k due to missing gnat-11 but gnat-12 is present and could probably be used, at least in a “gnat-11 | gnat-12” alternative dependency maybe?
Bug#1067643: webkit2gtk: please use architecture whitelist for libseccomp-dev B-D
Source: webkit2gtk Version: 2.42.5-2 Severity: important Justification: ftbfs on d-ports architectures X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org Please use libseccomp-dev B-D only on architectures where it actually exists (i.e. is not in state uncompiled). webkit2gtk is a B-D for glade, which is depended on by the Xfce stack, as far as I can tell, whose t64 transition this blocks.
Bug#1067639: sasl2-bin: terminates with smashed stack
Dixi quod…
>I was able to strace this:
[…]
>openat(AT_FDCWD, "/etc/__db.sasldb2", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0660)
>= 3
>fcntl64(3, F_GETFD) = 0
>fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
>get_thread_area() = 0xc0501500
>get_thread_area() = 0xc0501500
>get_thread_area() = 0xc0501500
>get_thread_area() = 0xc0501500
>statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH,
>STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0,
>stx_mode=S_IFREG|0640, stx_size=0, ...}) = 0
>statx(AT_FDCWD, "/etc/__db.sasldb2", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT,
>STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0,
>stx_mode=S_IFREG|0640, stx_size=0, ...}) = 0
>clock_gettime64(CLOCK_REALTIME, {tv_sec=1711315870, tv_nsec=459521594}) = 0
>clock_gettime64(CLOCK_REALTIME, {tv_sec=1711315870, tv_nsec=459846799}) = 0
>writev(2, [{iov_base="*** ", iov_len=4}, {iov_base="stack smashing detected",
>iov_len=23}, {iov_base=" ***: terminated\n", iov_len=17}], 3*** stack smashing
>detected ***: terminated
>) = 44
>mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>0xc002
>get_thread_area() = 0xc0501500
>rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
>get_thread_area() = 0xc0501500
>get_thread_area() = 0xc0501500
>gettid()= 32759
>getpid()= 32759
>tgkill(32759, 32759, SIGABRT) = 0
>--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=32759, si_uid=0} ---
>+++ killed by SIGABRT +++
>Aborted
>
>Best guess here is that the clock_gettime64 overwrote something?
This is possibly in db5.3 then.
(pbuild-31733)root@ara2:/# apt-get install gdb-minimal libdb5.3-dbg
sasl2-bin-dbgsym libsasl2-2-dbgsym libc6-dbg
[…]
(pbuild-31733)root@ara2:/# gdb /usr/sbin/saslpasswd2
[…]
(gdb) run -c 'no:such:user' :
Cannot access memory at address 0x10b8
(gdb) b sasl_setpass
Breakpoint 2 at 0xe60
Warning:
Cannot insert breakpoint 2.
Cannot access memory at address 0xe60
I don’t have much ideas how to go further because the
code paths are really hard to follow.
I also am not sure it’s in db5.3 any more, as libsasl2.so.2
isn’t linked against it…
bye,
//mirabilos
--
cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten
die nicht noch 3 Jahre warten können? bis dahin gibts google nicht
mehr ja, könnte man meinen. wahrscheinlich ist der angekündigte welt-
untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum
müssen die die doodles vorher noch raushauen
Bug#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!
Dixi quod…
>OK, it’s not qemu. On ARAnyM (Atari):
I was able to strace this:
(pbuild-31733)root@ara2:/# echo '!' | strace -f saslpasswd2 -c 'no:such:user'
execve("/usr/sbin/saslpasswd2", ["saslpasswd2", "-c", "no:such:user"],
0xefd2a90c /* 52 vars */) = 0
brk(NULL) = 0xd0005000
openat(AT_FDCWD, "/usr/lib/libeatmydata/libeatmydata.so",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/lib/libeatmydata", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT,
STATX_BASIC_STATS, 0xef935c28) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH,
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0,
stx_mode=S_IFREG|0644, stx_size=6940, ...}) = 0
mmap2(NULL, 6940, PROT_READ, MAP_PRIVATE, 3, 0) = 0xc0024000
close(3)= 0
openat(AT_FDCWD, "/lib/m68k-linux-gnu/libeatmydata.so",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\0\0\0\0\0\0004"...,
512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH,
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0,
stx_mode=S_IFREG|0644, stx_size=9460, ...}) = 0
mmap2(NULL, 24584, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc0026000
mmap2(0xc0026000, 16392, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xc0026000
munmap(0xc002b000, 4104)= 0
mprotect(0xc0027000, 8192, PROT_NONE) = 0
mmap2(0xc0029000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0xc0029000
close(3)= 0
openat(AT_FDCWD, "/usr/lib/cowdancer/libcowdancer.so",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\0\34\4\0\0\0004"...,
512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH,
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0,
stx_mode=S_IFREG|0644, stx_size=25936, ...}) = 0
mmap2(NULL, 41044, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc002b000
mmap2(0xc002c000, 32852, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xc002c000
munmap(0xc002b000, 4096)= 0
munmap(0xc0035000, 84) = 0
mprotect(0xc0031000, 8192, PROT_NONE) = 0
mmap2(0xc0033000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5000) = 0xc0033000
close(3)= 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/m68k-linux-gnu/libsasl2.so.2",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\0\0\0\0\0\0004"...,
512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH,
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0,
stx_mode=S_IFREG|0644, stx_size=91752, ...}) = 0
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xc0035000
mmap2(NULL, 98724, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc0037000
mmap2(0xc0038000, 90532, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xc0038000
munmap(0xc0037000, 4096)= 0
munmap(0xc004f000, 420) = 0
mprotect(0xc004c000, 4096, PROT_NONE) = 0
mmap2(0xc004d000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0xc004d000
close(3)= 0
openat(AT_FDCWD, "/lib/m68k-linux-gnu/libc.so.6",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3,
"\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\2\320\210\0\0\0004"..., 512)
= 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH,
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0,
stx_mode=S_IFREG|0755, stx_size=1535504, ...}) = 0
mmap2(NULL, 1585296, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xc004f000
mmap2(0xc005, 1577104, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0xc005
munmap(0xc004f000, 4096)= 0
munmap(0xc01d2000, 144) = 0
mprotect(0xc01c1000, 4096, PROT_NONE) = 0
mmap2(0xc01c2000, 24576, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17) = 0xc01c2000
mmap2(0xc01c8000, 37008, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xc01c8000
close(3)= 0
openat(AT_FDCWD, "/lib/m68k-linux-gnu/libdl.so.2",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\4\0\0\0\1\0\0\0\0\0\0\0004"...,
512) = 512
statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH,
STATX_BASIC_STATS, {stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0,
stx_mode=S_IFREG|0644, stx_size=9528, ...}) = 0
mmap2(NULL, 24636, PROT_NONE,
Bug#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!
Dixi quod… >The openldap build on an m68k qemu-user buildd cannot install sasl2-bin in the >chroot: OK, it’s not qemu. On ARAnyM (Atari): […] Setting up libldap-2.5-0:m68k (2.5.16+dfsg-2+b1) ... Setting up sasl2-bin (2.1.28+dfsg1-5) ... *** stack smashing detected ***: terminated Aborted dpkg: error processing package sasl2-bin (--configure): installed sasl2-bin package post-installation script subprocess returned error exit status 134 Processing triggers for libc-bin (2.37-15.1+b1) ... Processing triggers for man-db (2.12.0-3+b2) ... Not building database; man-db/auto-update is not 'true'. Errors were encountered while processing: sasl2-bin E: Sub-process /usr/bin/dpkg returned an error code (1) 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#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!
Package: sasl2-bin Version: 2.1.28+dfsg1-5 X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org The openldap build on an m68k qemu-user buildd cannot install sasl2-bin in the chroot: […] Setting up pkg-config:m68k (1.8.1-1) ... Setting up libsasl2-2:m68k (2.1.28+dfsg1-5) ... Setting up libsasl2-modules-gssapi-mit:m68k (2.1.28+dfsg1-5) ... Setting up unixodbc-dev:m68k (2.3.12-1+b1) ... Setting up libgnutls28-dev:m68k (3.8.3-1.1+b2) ... Setting up libhcrypto5t64-heimdal:m68k (7.8.git20221117.28daf24+dfsg-5+b2) ... Setting up libotp0t64-heimdal:m68k (7.8.git20221117.28daf24+dfsg-5+b2) ... Setting up db-util (5.3.3) ... Setting up bind9-libs:m68k (1:9.19.21-1+b1) ... Setting up libsl0t64-heimdal:m68k (7.8.git20221117.28daf24+dfsg-5+b2) ... Setting up sasl2-bin (2.1.28+dfsg1-5) ... *** stack smashing detected ***: terminated qemu: uncaught target signal 6 (Aborted) - core dumped Aborted dpkg: error processing package sasl2-bin (--configure): installed sasl2-bin package post-installation script subprocess returned error exit status 134 Setting up libperl-dev:m68k (5.38.2-3.2+b1) ... Setting up libsasl2-dev (2.1.28+dfsg1-5) ... Setting up libgssrpc4t64:m68k (1.20.1-6+b1) ... Setting up libhx509-5t64-heimdal:m68k (7.8.git20221117.28daf24+dfsg-5+b2) ... dpkg: dependency problems prevent configuration of sbuild-build-depends-main-dummy: sbuild-build-depends-main-dummy depends on sasl2-bin; however: Package sasl2-bin is not configured yet. dpkg: error processing package sbuild-build-depends-main-dummy (--configure): dependency problems - leaving unconfigured […] Unpacking sbuild-build-depends-dose3-dummy (0.invalid.0) ... Setting up sasl2-bin (2.1.28+dfsg1-5) ... BDB0002 __fop_file_setup: Retry limit (100) exceeded saslpasswd2: generic failure dpkg: error processing package sasl2-bin (--configure): installed sasl2-bin package post-installation script subprocess returned error exit status 1 […] See: https://buildd.debian.org/status/fetch.php?pkg=openldap=m68k=2.5.16%2Bdfsg-2%2Bb2=1711312418=0 This does not seem to be specific to one buildd. Any idea how this can be debugged?
Bug#1067613: openjdk-11: FTBFS on alpha: d/rules references deleted patch (trivial fix)
Source: openjdk-11 Version: 11.0.19+7-1 Severity: important Justification: FTBFS on d-ports arch debian/rules binary-arch : # apply some architecture specific patches ... patch -p1 < debian/patches/alpha-float-const.diff /bin/bash: line 1: debian/patches/alpha-float-const.diff: No such file or directory make: *** [debian/rules:1016: stamps/unpack] Error 1 The patch got removed (ok, correct) but it needs to be removed from where d/rules adds it to the list of patches, too.
Bug#1067577: sysprof: B-D on libunwind-dev which is not generally available
Simon McVittie dixit: [… detailed analysis …] Thanks for looking into this. I looked at libunwind for a bit, but it requires intricate knowledge of debugging formats and everything. >I've pushed a commit to gtk4 to disable the libsysprof-capture >dependency and integration on architectures where it isn't available, >and I think that's probably a good approach in the 5 other source >packages with a similar dependency. Agreed. >At the time of writing, sysprof is available on all release >architectures, plus powerpc and ppc64. I'm not intending to upload gtk4 >right now, but this change will be in the next gtk4 upload unless >there's a showstopper problem with it. lgtm; m68k successfully built gtk4 as an older version of sysprof was still available and installable, and the other ports architectures except hurd-amd64 will likely have the same. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1067577: sysprof: B-D on libunwind-dev which is not generally available
Simon McVittie dixit: >(Or of course porting libunwind to the remaining architectures would >be another obvious way that porters could address this.) Definitely. All three are valid possibilities. >Another possible way to attack this, particularly if libunwind is >functionally necessary in sysprof (I don't know whether it is), would >be to limit sysprof integration to those architectures where developers >are practically likely to want to carry out profiling/optimization work. I think that this is probably easier to do within sysprof if it has multiple users, unless all users have something like autoconf and check for presence and just don't use it if absent. >In general sysprof is an optional dependency: the purpose of compiling >lower-level libraries like GTK with sysprof integration is to get more >detailed profiling and performance reporting, but that's probably only >interesting on relatively mainstream architectures where a developer >is more likely to be making use of that information. Ah okay, good point. 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#1067582: gnuplot: please provide a profile to break B-D cycle
Source: gnuplot Version: 6.0.0+dfsg1-2 Severity: important Justification: t64 transition roadblock X-Debbugs-Cc: t...@mirbsd.de There’s this cyclic Build-Depends chain: ffmpeg < tesseract < leptonlib < gnuplot < wxwidgets3.2 < opencv < ffmpeg Asides from that, gnuplot also depends on Qt5, which is another heavy thing to tackle. Please provide a profile with which the wxwidgets and Qt GUIs are elided. leptonlib B-D on gnuplot-nox so that should help already. Thanks!
Bug#1067577: sysprof: B-D on libunwind-dev which is not generally available
Source: sysprof Version: 46~rc-1 Severity: important Justification: unbuildable on some d-ports architectures X-Debbugs-Cc: t...@mirbsd.de libunwind-dev is not available for at least alpha, hurd-any, loong64, m68k, sparc64, x32. sysprof is a not unimportant part in the GNOME dependency chain (IIRC seeing it for weston) and part of the t64 transition, so having it generally available (with missed features if needed) is needed.
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#1067243: openssh: please build without -fzero-call-used-regs=used on m68k
Colin Watson dixit: >Could you try the somewhat further reduced patch in The package made from that branch built fine in my cowbuilder, and I have all reason to assume it’ll do so in sbuild/buildd. 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#1067243: openssh: please build without -fzero-call-used-regs=used on m68k
Colin Watson dixit: >Thanks! No rush - I won't be at a proper computer until Sunday or so >anyway. OK sure… no rush is not the reason, the Atari VM I’m using having only 98 MHz is the one here ;-) But I already see: checking if cc supports compile flag -fzero-call-used-regs=used and linking succeeds... no So I guess it should work, but I’ll see tomorrow. 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#1067243: openssh: please build without -fzero-call-used-regs=used on m68k
Colin Watson dixit: >Could you try the somewhat further reduced patch in I’ve started a build and will let you know probably when I get back late tomorrow. 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#1067447: jackd2: patch to fix ftbfs on m68k; jack{1,2}: unneeded libffado-dev B-D on some arches
Source: jackd2
Version: 1.9.21~dfsg-3
Severity: important
Tags: patch
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org
Control: affects -1 src:jack-audio-connection-kit
Hi,
please apply the attached patch for jackd2 and forward it upstream
that makes the implicit alignment assumptions (not supported by the
C and C++ standards) explicit, which allows building on m68k. The
diff won’t change a bit for other architectures.
Please also apply the patches for jackd2 and jack-audio-connection-kit
both to restrict B-D on libffado-dev to these architectures where the
firewire binary package is actually built. The reverse B-D chain of
ffado is… pure hell, and even more cyclic without this.
Thanks!diff -Nru jack-audio-connection-kit-0.126.0/debian/changelog
jack-audio-connection-kit-0.126.0/debian/changelog
--- jack-audio-connection-kit-0.126.0/debian/changelog 2023-01-06
23:02:48.0 +0100
+++ jack-audio-connection-kit-0.126.0/debian/changelog 2024-03-21
02:03:21.0 +0100
@@ -1,3 +1,9 @@
+jack-audio-connection-kit (1:0.126.0-2+m68k) unreleased; urgency=medium
+
+ * Only B-D: libffado-dev if jackd1-firewire is built
+
+ -- Thorsten Glaser Thu, 21 Mar 2024 02:03:21 +0100
+
jack-audio-connection-kit (1:0.126.0-2) unstable; urgency=medium
* Team upload
diff -Nru jack-audio-connection-kit-0.126.0/debian/control
jack-audio-connection-kit-0.126.0/debian/control
--- jack-audio-connection-kit-0.126.0/debian/control2023-01-06
23:02:48.0 +0100
+++ jack-audio-connection-kit-0.126.0/debian/control2024-03-21
01:50:44.0 +0100
@@ -15,7 +15,7 @@
doxygen,
libasound2-dev [linux-any],
libdb-dev,
- libffado-dev [linux-any],
+ libffado-dev [amd64 i386 powerpc],
libraw1394-dev [linux-any],
libreadline-dev,
libsamplerate-dev,
diff -Nru jackd2-1.9.21~dfsg/debian/changelog
jackd2-1.9.21~dfsg/debian/changelog
--- jackd2-1.9.21~dfsg/debian/changelog 2023-05-04 21:29:39.0 +0200
+++ jackd2-1.9.21~dfsg/debian/changelog 2024-03-21 02:20:11.0 +0100
@@ -1,3 +1,10 @@
+jackd2 (1.9.21~dfsg-3+m68k) unreleased; urgency=medium
+
+ * Only B-D: libffado-dev if jackd2-firewire is built
+ * debian/patches/fix-implicit-alignment-assumptions.diff: add
+
+ -- Thorsten Glaser Thu, 21 Mar 2024 02:20:11 +0100
+
jackd2 (1.9.21~dfsg-3) unstable; urgency=medium
* Team upload.
diff -Nru jackd2-1.9.21~dfsg/debian/control jackd2-1.9.21~dfsg/debian/control
--- jackd2-1.9.21~dfsg/debian/control 2023-05-04 21:29:39.0 +0200
+++ jackd2-1.9.21~dfsg/debian/control 2024-03-21 01:54:43.0 +0100
@@ -11,7 +11,7 @@
libdb-dev,
libdbus-1-dev,
libexpat1-dev,
- libffado-dev [linux-any],
+ libffado-dev [amd64 i386 powerpc],
libncurses-dev,
libopus-dev,
libraw1394-dev [linux-any],
diff -Nru
jackd2-1.9.21~dfsg/debian/patches/fix-implicit-alignment-assumptions.diff
jackd2-1.9.21~dfsg/debian/patches/fix-implicit-alignment-assumptions.diff
--- jackd2-1.9.21~dfsg/debian/patches/fix-implicit-alignment-assumptions.diff
1970-01-01 01:00:00.0 +0100
+++ jackd2-1.9.21~dfsg/debian/patches/fix-implicit-alignment-assumptions.diff
2024-03-21 02:20:03.0 +0100
@@ -0,0 +1,93 @@
+Description: fix implicit alignment assumptions
+ The language standard does not guarantee “natural” alignment
+ (i.e. alignment to (at least) the size of the integer type),
+ and on some architectures, int normally is only 16-bit-aligned.
+ Make the assumption explicit to allow compilation on these.
+Author: Thorsten Glaser
+
+--- a/common/JackActivationCount.h
b/common/JackActivationCount.h
+@@ -39,7 +39,7 @@ class JackActivationCount
+
+ private:
+
+-alignas(SInt32) SInt32 fValue;
++alignas(SInt32) alignas(sizeof(SInt32)) SInt32 fValue;
+ SInt32 fCount;
+
+ public:
+--- a/common/JackAtomicArrayState.h
b/common/JackAtomicArrayState.h
+@@ -122,7 +122,7 @@ class JackAtomicArrayState
+ // fState[2] ==> request
+
+ T fState[3];
+-alignas(UInt32) alignas(AtomicArrayCounter) volatile
AtomicArrayCounter fCounter;
++alignas(UInt32) alignas(sizeof(UInt32)) alignas(AtomicArrayCounter)
volatile AtomicArrayCounter fCounter;
+
+ UInt32 WriteNextStateStartAux(int state, bool* result)
+ {
+--- a/common/JackAtomicState.h
b/common/JackAtomicState.h
+@@ -94,7 +94,7 @@ class JackAtomicState
+ protected:
+
+ T fState[2];
+-alignas(UInt32) alignas(AtomicCounter) volatile AtomicCounter
fCounter;
++alignas(UInt32) alignas(sizeof(UInt32)) alignas(AtomicCounter)
volatile AtomicCounter fCounter;
+ SInt32 fCallWriteCounter;
+
+ UInt32 WriteNextStateStartAux()
+--- a/common/JackConnectionManager.h
b/common/JackConnectionManager.h
+@@ -417,7 +417,7 @@ class SERVER_EXPORT JackConnectionManage
+ JackFixedArray1 fInputP
Bug#1067243: openssh: please build without -fzero-call-used-regs=used on m68k
Colin Watson dixit: >I don't love overriding snprintf here, since it seems possible that that Agreed. >could disturb the check on other architectures. Could you try the >somewhat further reduced patch in >https://salsa.debian.org/ssh-team/openssh/-/tree/zero-call-used-regs-m68k, Yes, but not sure I manage it tonight, and I’ll be gone all day tomorrow. >please? I wanted to use the mitchy.debian.net porterbox but I got >ECONNREFUSED. Adrian, do you have an idea about that? >This configure check doesn't use the usual autoconf result caching >arrangements, which makes it a bit more awkward to override from >debian/rules. There are options, but an extended configure check that I >could send upstream would probably be best. oic, yes, that’s definitely easier. For now I’ve built the last upload with the flag manually removed, so this isn’t a transition blocker any more, until the next upload anyway and perhaps not even then… 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#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#1067243: openssh: please build without -fzero-call-used-regs=used on m68k
Source: openssh
Version: 1:9.7p1-2
Severity: important
Justification: FTBFS on d-ports arch
Tags: ftbfs
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org
On m68k, gcc-13 currently ICEs when -fzero-call-used-regs=used is
used (see #1066891) in moduli.c, packet.c, etc. but the configury
detects it and so it gets used. The upstream GCC bug comments say
there is no plan to backport the possible fix to releases, but it
has a short reproducer by doko:
$ cat moduli.i
int snprintf_eta;
double snprintf_time_per_line;
int snprintf(char *, int, char *, ...) {
snprintf_eta = snprintf_time_per_line;
}
$ m68k-linux-gnu-gcc -c -O2 -fzero-call-used-regs=used -fPIE moduli.i
during RTL pass: zero_call_used_regs
moduli.i: In function ‘snprintf’:
moduli.i:5:1: internal compiler error: in change_address_1, at emit-rtl.cc:2287
Maybe this could be used in the configure script?
I can confirm that appending…
int snprintf_eta;
double snprintf_time_per_line;
int snprintf(char *str, size_t size, const char *format, ...) {
snprintf_eta = snprintf_time_per_line;
}
… (lightly changed from the above) to the program from
m4/openssh.m4 OSSH_COMPILER_FLAG_TEST_PROGRAM fails with:
(pbuild-15711)root@ara2:/tmp# gcc -O2 -fPIE -fno-strict-aliasing
-fzero-call-used-regs=used t.c
during RTL pass: zero_call_used_regs
t.c: In function 'snprintf':
t.c:51:1: internal compiler error: in change_address_1, at emit-rtl.cc:2287
51 | }
| ^
[…]
Alternatively, just hardcode disabling this flag on m68k for now,
which we’ll eventually have to revert once GCC is on a fixed release
(14 probably).
Thanks in advance!
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#1067207: mesa: switch statement too large, might need -mlong-jump-table-offsets
Source: mesa Version: 24.0.3-1 Severity: important Justification: FTBFS on d-ports arch X-Debbugs-CC: t...@mirbsd.de, debian-...@lists.debian.org Tags: ftbfs mesa currently FTBFS on m68k with: […] cc -Isrc/nouveau/headers/libnvidia_headers.a.p […] -o src/nouveau/headers/libnvidia_headers.a.p/meson-generated_.._nvk_cla097.c.o -c src/nouveau/headers/nvk_cla097.c /tmp/ccrcAVyk.s: Assembler messages: /tmp/ccrcAVyk.s:15766: Error: Adjusted signed .word (0x8002) overflows: `switch'-statement too large. /tmp/ccrcAVyk.s:15766: Error: Adjusted signed .word (0x8008) overflows: `switch'-statement too large. […] Not sure if it makes sense to exclude building this part of nouveau on m68k (I do know someone who has added a PCI bus to his Atari and runs a Radeon on it) or whether other files in this source package also have huge jump tables. Adding the -mlong-jump-table-offsets flag to CFLAGS on m68k should unbreak this; bonus points if you add it to only the files where it’s needed, if it’s only a few and not expected to change, for example.
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#1067196: qpdf: contrary to the documentation, fix-qdf aborts on removed objects
Package: qpdf Version: 10.1.0-1 Severity: normal Tags: upstream X-Debbugs-Cc: t...@mirbsd.de, n...@naturalnet.de The qpdf documentation states that it is possible to remove an object then run fix-qdf and it should renumber the remaining objects. In an exemplary PDF, I did this: - qpdf --qdf dings.pdf dings.qdf - $EDITOR dings.qdf - remove object '38 0' and the one reference to it - fix-qdf dings.qdf >dings2.qdf It complained about the missing object: dings.qdf:20254: expected object 38 Line 20254 here is exactly the beginning of object '39 0' after the end of object '37 0'. ──┤ Workaround ├ Just removing all the references and letting qpdf clean up the now-unreferenced object seems to have worked here. But this does still not work as documented… -- System Information: Debian Release: 11.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable-proposed-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-27-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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 qpdf depends on: ii libc6 2.31-13+deb11u8 ii libgcc-s1 10.2.1-6 ii libqpdf28 10.1.0-1 ii libstdc++6 10.2.1-6 qpdf recommends no packages. qpdf suggests no packages. -- no debconf information
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#980768: gnupg2: fails to build gpgkeys_ldap, probably due to -Werror=implicit-function-declaration
Hello again, >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. unfortunately, imagemagick/graphicsmagick is still a problem, and bin:gnupg and bin:gnupg-l10n are arch:all packages, making it impossible for architectures where the arch:any parts have not (yet) built to install bin:gnupg which is a frequent B-D. 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#1067026: graphviz: please build without librsvg except on rust platforms
Source: graphviz Version: 2.42.2-9 X-Debbugs-Cc: t...@mirbsd.de, debian-po...@lists.debian.org librsvg has become extremely unportable, and so only a subset of architectures have it: amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x loong64 powerpc ppc64 sparc64 Please whitelist the librsvg usage restricting it to these architectures. This is a ports-only change, release architectures are not affected, but it’ll help tremendously.
Bug#932090: firebird3.0: Please include patch to ensure correct sizes of on-disk structures
John Paul Adrian Glaubitz dixit:
>However, it turns out that my approach is wrong and upstream has already used
>a different approach for firebird4.0 [2], although I haven't tested that on
>m68k yet.
>> [2] https://github.com/FirebirdSQL/firebird/pull/234/commits
(use https://github.com/FirebirdSQL/firebird/pull/234.patch in lynx)
Very much not; firebird3.0 also has that now AFAICT, and now the static
asserts fail.
The alignment assumptions must be made explicit: change something like…
struct foo {
char a;
int b;
};
… to:
struct foo {
char a;
char padding1[3];
int b;
};
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#1067008: qt6-base: please do not use firebird3.0 on m68k
Source: qt6-base
Version: 6.4.2+dfsg-21.1
X-Debbugs-Cc: t...@mirbsd.de, debian-...@lists.debian.org
firebird3.0 is not available on m68k because it invalidly assumes…
struct foo {
char a;
int b;
};
… that b is 32-bit aligned in this struct from implicit padding,
which neither C nor POSIX guarantee (on m68k, it is aligned 16 bit
due to the ABI spec) and this situation is the same as a decade ago.
It would be very helpful if qt6 (and qt5) could just not use this
database on m68k, as it’s hard to keep on top with manually fixing
these:
struct foo {
char a;
char dummy[3];
int b;
};
Thanks in advance!
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#1066891: gcc-13: ICE compiling OpenSSH: in change_address_1
On Sat, 16 Mar 2024, Matthias Klose wrote: > you can work-around that by omitting -fzero-call-used-regs=used Thanks! That will help with the transition. Will you hand this over to upstream for an eventual fix? bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1066882: bash: :: unrecognized history modifier
Package: bash Version: 5.2.21-2 Severity: normal X-Debbugs-Cc: t...@mirbsd.de I knew GNU bash had some issues with the exclamation mark, but it’s even quoted here and still it weirdly fails: bash$ echo "$BUILDUSERNAME:!:::" bash: :: unrecognized history modifier (This is from the pbuilder code to add the build user to shadow, which I had to run by hand in a cowbuilder --login chroot because I needed some manual work before the package build and some packages refuse to be built by root.) -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: m68k Kernel: Linux 6.6.15-m68k (UP) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/bash Init: sysvinit (via /sbin/init) Versions of packages bash depends on: ii base-files 13 ii debianutils 5.17 ii libc62.37-15.1 ii libtinfo66.4+20240113-1 Versions of packages bash recommends: pn bash-completion Versions of packages bash suggests: pn bash-doc -- no debconf information
Bug#1066841: rpm: hard Build-Depends on unportable package pandoc
retitle 1066841 rpm: hard Build-Depends on unportable package pandoc thanks Hi, rpm also exhibits the same portability problem. Please see whether it’s possible to use pandoc only during arch:all builds or otherwise not in arch:any… Thanks, //mirabilos -- This space for rent. https://paypal.me/mirabilos to support my work.
Bug#902240: html-xml-utils: don't Build-Depends: man2html
ping this (s/man2html/man2html-base/) would IMMENSELY help with the current transitions, and I might NMU if no reaction
Bug#1066832: Debian #1066832: [fsverity-utils] hard Build-Depends on unportable package pandoc
Dixi quod… >Please split the package so that the part that requires pandoc is >done in an arch:all build. Normally, pandoc is needed only for >documentation, which is often easy enough to split off in a -doc >binary package, which can then move to B-D-Indep and be built on >amd64 or whatever hosts. Looking at this in some detail, this is *only* ONE manual page. Splitting into a separate package for one file will not go over well with ftpmaster. Dear upstream, please consider keeping the manpage in something else, like mdoc. I would be willing to convert the manpage to semantic, readable mdoc for you, even. (fsverity-utils is a Build-Depends of rpm, some subpackages of which are necessary to build other software even in Debian.) If upstream is not willing, we could: • do this as local patch (effort updating it every time) • hack a script that converts man/fsverity.1.md to mdoc; this doesn’t need to be a full converter, it needs to just be good enough to convert this one page (effort one-time, but probably not much if at all when updating) • as package maintainer, run the pandoc conversion script and put the result into debian/fsverity.1 and install from there and stop B-D’ing on pandoc (needs some, but not much, manual effort on each update, and the package maintainer to have a clean sid system on which to do that) • install a dummy manpage (that maybe summarises the options and points the reader to https://manpages.debian.org/unstable/fsverity/fsverity.1.en.html for the full page) on architectures without pandoc (needs a bit of initial hacking, and to keep a whitelist of arches with pandoc up-to-date) 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#1066832: fsverity-utils: hard Build-Depends on unportable package pandoc
Source: fsverity-utils Version: 1.5-1.1 Severity: important Justification: RC for Debian-Ports X-Debbugs-Cc: t...@mirbsd.de, debian-po...@lists.debian.org Recent versions of fsverity-utils (larger than 1.4-1~exp1 anyway) have a Build-Depends-Arch on pandoc; however, pandoc is an extremely unportable package written in a hard to port language. Please split the package so that the part that requires pandoc is done in an arch:all build. Normally, pandoc is needed only for documentation, which is often easy enough to split off in a -doc binary package, which can then move to B-D-Indep and be built on amd64 or whatever hosts. Thanks, //mirabilos
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#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 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#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#1066143: general/glibc(?): simple IPv6 test program fails on m68k
>The same program works on amd64. I noticed another difference between the amd64 system and the four m68k ones. $ ip a show dev lo 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever vs. # ip a show dev lo 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever /etc/network/interfaces just has… auto lo iface lo inet loopback … on all systems, so something weird is going on. 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#1066145: debootstrap: fails with multiversion repositories, including Debian’s
Package: debootstrap Version: 1.0.134 Severity: important There exist multiversion Packages files, e.g. they can be created by dpkg-scanpackages -m but dak also occasionally seems to create them. I just had multiple attempts at creating a buildd chroot fail. One was with debootstrap --variant=buildd where perl-modules-5.38 failed the bootstrap because the Packages file contains two versions of it (5.38.2-3.2 (the one we want) followed by 5.38.2-3). According to cbmuser, the arch:all part of debian-ports Packages files is an identical embedded copy of binaries-all/Packages from dak for sid, so this is not just a debian-ports or mini-dak problem. Then I tried --variant=minbase which failed the cowbuilder --create as well but only after the debootstrap stage: debootstrap installed libaudit-common 1:3.1.2-2 instead of 1:3.1.2-2.1 so the chroot had libaudit1’s dependency on libaudit-common unfulfilled, which made a later apt-get dist-upgrade fail without manually running an apt-get -f install first (which I thankfully could do in a pbuilder hook script). This is a real problem affecting real-world scenarios (such as buildd maintainers frantically trying to stay on top of t64), and apparently at least arch:all packages can have multiple versions show up in the Packages file in Debian sid. The two failure modes are that debootstrap either results in a chroot in which packages are installed that don’t meet each other’s dependencies (which a real-world dpkg call would need --force-depends) or that debootstrap itself even aborts. The fix is of course to consider all versions of all packages, though this will be very hard; apt seems to normally only consider the latest version (unless another is installed or pinned), so doing that would be another option, which while not being helpful in situations of nōn-arch:all packages lagging would fix this bug just as well. -- System Information: Debian Release: stretch/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: m68k Kernel: Linux 6.6.15-m68k Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages debootstrap depends on: ii wget 1.16.3-3 Versions of packages debootstrap recommends: pn arch-test ii debian-archive-keyring 2014.3 ii gnupg 1.4.19-5 ii mount 2.26.2-9 Versions of packages debootstrap suggests: ii binutils2.25.1-1 pn squid-deb-proxy-client pn ubuntu-archive-keyring ii xz-utils5.1.1alpha+20120614-2.1 pn zstd -- no debconf information
