Hi Georgios,
why not just ensure the parent directory of the chroot is not
traversable for just any normal user?
That would allow preserving /tmp/buildd as build place as well
as retaining stuff under /run which packages create and which
is, in practice, often needed for chroots where
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
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,
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
*
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
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:
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 @@
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),
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) ex
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
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,
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,
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 :-)
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
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,
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
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 :-)
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
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
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
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
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,
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
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:
[…]
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
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
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
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!
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
: #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
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:
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
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]
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
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
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
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
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
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
--
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
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
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
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,
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 :-)
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:
any idea?
this would help a lot with the t64 transition,
as Qt is proving difficult on some architectures
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
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
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
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
-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
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
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
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
>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
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?
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
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()
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)
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:
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
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
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
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
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
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
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
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
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
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
: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
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
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.
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?
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
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
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
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
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 (>=
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
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
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
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
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
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
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,
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 :-)
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
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.
ping
this (s/man2html/man2html-base/) would IMMENSELY help with
the current transitions, and I might NMU if no reaction
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
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
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
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
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 |
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
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
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
>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
1 - 100 of 4543 matches
Mail list logo
