Package: apache2
Version: 2.4.59-1~deb11u1
Severity: wishlist
Tags: upstream
X-Debbugs-Cc: t...@mirbsd.de
The W3C validator is not quite happy with the default directory indicēs.
Applying the following change to its config…
- IndexOptions FancyIndexing VersionSort HTMLTable NameWidth=*
Package: debian-installer
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.5.0-amd64-netinst.iso
I was booting in expert mode and expecting between the mirror select
and the installing of the base system there to be an option to
have been already deleted, so I
could not have a look myself.
Thorsten
On 29.05.24 23:12, Emanuele Rocca wrote:
> On 2024-05-27 02:31, Thorsten Leemhuis wrote:
>> Would also help a lot to know if this is a 6.8.y only thing, or happens
>> with 6.9 and mainline as well, as 6.8.y will likely be EOLed soon.
>
> I could reproduce the issue wit
On 30.05.24 10:45, Jörn Heusipp wrote:
>
> On 30/05/2024 09:27, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 30.05.24 08:55, Jörn Heusipp wrote:
>>> commit fbf6449f84bf5e4ad09f2c09ee70ed7d629b5ff6 ("x86/sev-es: Set
>>> x86_virt_bits to the c
6 system.
FWIW, not my area of expertise, but there is a patch from Dave with a
Fixes: tag for your culprit up for review:
https://lore.kernel.org/all/20240517200534.8ec5f...@davehans-spike.ostc.intel.com/
Ciao, Thorsten
> Updating a Debian testing system resulted in a hang during boot befor
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: christ...@iwakd.de, t...@mirbsd.de, bastian.germ...@gmx.de
Control: blocks -1 1067946 1069365
Dear ftpmasters,
in #1067946 it was reported that some consider the sunrpc code as
included in dietlibc nōn-free.
Given that the actual wording
know if this is a 6.8.y only thing, or happens
with 6.9 and mainline as well, as 6.8.y will likely be EOLed soon.
Ciao, Thorsten
TWIMC, the problem systemd is facing due to the removal of a obsolete
option (that might or might not lead to the problem this bug is about)
was finally properly reported upstream now – and from the first reply is
sounds like a workaround is likely to be expected:
especially as I'm pretty
sure there are already a lot of btrfs systems with systemd and 6.8
(release upstream 2+ month ago and regularly used in Arch, Fedora and
Tumbleweed for weeks now) out there and working just fine (including the
Fedora machine one I write from).
Thorsten
Bastian Germann dixit:
>> Do you have a link?
>
> No. It is not a public address.
Ah, yes, that is unfortunate. I used to be subscribed and have no
idea why I’m not, but I re-subscribed (though have not yet seen any
traffic in the last couple of days).
>> What did upstream say?
>
> No upstream
Moritz Mühlenhoff dixit:
>Am Fri, May 10, 2024 at 06:39:20PM + schrieb Thorsten Glaser:
>> This is a bit like the limited security support for binutils,
>> I suppose. Could/should we document that in the same places?
>
>Sure thing, this sounds similar to what was done fo
Hi Jonathan,
On 12.05.24 13:13, Jonathan Wiltshire wrote:
Please go ahead.
great, thanks ...
... and done.
Thorsten
Dixi quod…
>Huh. MuseScore (Studio) is a desktop application.
I’ll add a README.Debian note about that fact and that upstream
has never considered crashes on invalid input a bug and that it
hasn’t been designed as a remotely accessible service, but as a
desktop application, and that users should
Moritz Mühlenhoff dixit:
>| MuseScore CAP File Parsing Heap-based Buffer Overflow Remote Code
>| Execution Vulnerability. This vulnerability allows remote attackers
Huh. MuseScore (Studio) is a desktop application.
I will have to investigate whether they mean indeed this
or the musescore.com
there be a unique id for each package?
Thorsten
Dmitry Shachnev dixit:
>Will you be able to forward your patch upstream when you finalize it?
Sort of. I can do the CLA, Gerrit, etc. dance, but I probably cannot
respond well if they want me to test things with vanilla upstream
(instead of the packaging), or if they have requests I as a C (but
Dixi quod…
>Dmitry Shachnev dixit:
>>Now that you dug so deeply, maybe you can try to replace qRound in those
>>three lines that you mentioned with TO_TTF, and check if it fixes the bug
>
>That *and* figure out somehow how to fix the PDF /FontBBox, at
>least… (though I binary-patched the hhea
Dixi quod…
>values). I’ll build it now so I don’t know if it even compiles yet…
font.hhea.ascender = TO_TTF(properties.ascent.toReal());
font.hhea.descender = TO_TTF(-properties.descent.toReal());
font.hhea.lineGap = TO_TTF(properties.leading.toReal());
g/debian/changelog 2024-05-05
23:58:03.0 +0200
@@ -1,3 +1,10 @@
+qtbase-opensource-src (5.15.2+dfsg-9.0.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches/bug1070406.diff
+
+ -- Thorsten Glaser Sun, 05 May 2024 23:58:03 +0200
+
qtbase-opensource-src (5.15.
Hi Dmitry,
(you use Googlemail, which is problematic, I picked your reply
from the BTS; perhaps send to 1070406-submitter@b.d.o instead
which should arrive)
>I checked Qt 4 history [1] and there this code dates back to “Long live Qt!”
>commit from 2009. So it’s unlikely that we can find the
Dixi quod…
>correct… but it only changes the metrics in the head table, not
>in the OS/2 or hhea tables (as can be seen when loading the font
>from the PDF in FontForge). Furthermore, the /FontBBox in the PDF
>is constructed from the values from the original font.
And Atril uses the values from
Dixi quod…
>$ atril moo.pdf
Further debugging reveals the cause:
When Qt5 embeds a font, it scales it to 2048 ppem, no matter if
it was 1000 ppem (PS/CFF) or 1024 ppem (TTF) before. I think this
is because [QTBUG-586] it cannot embed CFF fonts, so it always
converts to TTF (apparently even if
Package: qtbase5-dev
Version: 5.15.10+dfsg-7.2+b1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
Control: found -1 5.15.2+dfsg-9
Control: found -1 5.7.1+dfsg-3+deb9u4
Control: affects -1 musescore
Control: affects -1 musescore3
I’ve received reports that PDFs generated by Mu͒seScore when
viewed in
Hi Bastian,
>I have already informed upstream about it.
did you do that on a mailing list? Do you have a link?
What did upstream say?
Still unconvinced,
//mirabilos
--
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse
buffer overflow in QDnsLookup
+
+ -- Thorsten Alteholz Sun, 28 Apr 2024 22:48:02 +0200
+
qtbase-opensource-src (5.15.2+dfsg-9) unstable; urgency=medium
* Revert adding fix-misplacement-of-placeholder-text-in-QLineEdit.diff.
diff -Nru qtbase-opensource-src-5.15.2+dfsg/debian/patches/CVE-2022
-51714 (Closes: #1060694)
+fix incorrect HPack integer overflow check.
+
+ -- Thorsten Alteholz Sun, 28 Apr 2024 20:48:02 +0200
+
qtbase-opensource-src (5.15.8+dfsg-11+deb12u1) bookworm; urgency=medium
[ Alexander Volkov ]
diff -Nru qtbase-opensource-src-5.15.8+dfsg/debian/patches/CVE-2023
Jay Berkenbilt dixit:
>How's that?
That explains it very well and not ambiguous to nōn-native
speakers (I hope).
Thanks,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
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
Package: ftp.debian.org
Severity: normal
Control: affects -1 + src:gutenprint
Unfortunately this software no longer runs on 32bit architectures. The time to
fix this is better spent on other things.
Thorsten
Hi Jonathan,
On 22.04.24 19:10, Jonathan Wiltshire wrote:
Please go ahead.
great, thanks ...
... and uploaded.
Thorsten
Hi Jonathan,
On 22.04.24 18:59, Jonathan Wiltshire wrote:
Please go ahead.
great, thanks ...
... and uploaded.
Thorsten
...
Thorsten
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
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
-daemon
is not installed.
So, if you don't mind I will close this bug again.
Thorsten
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 @@
Package: libapriltag-dev
Version: 3.3.0-2.1
When using the library with cmake it doesn't work, because the file is placed
one level of directories deeper than are unwinded in the cmake file.
See the patch below that fixes it.
--- /usr/lib/x86_64-linux-gnu/cmake/apriltag/apriltagTargets.cmake
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),
Package: ftp.debian.org
Severity: normal
Control: affects -1 + src:libosmo-netif
Unfortunately this software no longer runs on 32bit architectures. The time to
fix this is better spent on other things.
Thorsten
Package: ftp.debian.org
Severity: normal
Control: affects -1 + src:osmo-mgw
Unfortunately this software no longer runs on 32bit architectures. The time to
fix this is better spent on other things.
Thorsten
Package: ftp.debian.org
Severity: normal
Control: affects -1 + src:osmo-bsc
Unfortunately this software no longer runs on 32bit architectures. The time to
fix this is better spent on other things.
Thorsten
Package: ftp.debian.org
Severity: normal
Control: affects -1 + src:osmo-iuh
Unfortunately this software no longer runs on 32bit architectures. The time to
fix this is better spent on other things.
Thorsten
Package: ftp.debian.org
Severity: normal
Control: affects -1 + src:osmo-msc
Unfortunately this software no longer runs on 32bit architectures. The time to
fix this is better spent on other things.
Thorsten
Package: ftp.debian.org
Severity: normal
Control: affects -1 + src:osmo-sgsn
Unfortunately this software no longer runs on 32bit architectures. The time to
fix this is better spent on other things.
Thorsten
Package: ftp.debian.org
Severity: normal
Control: affects -1 + src:osmo-hlr
Unfortunately this software no longer runs on 32bit architectures. The time to
fix this is better spent on other things.
Thorsten
Package: ftp.debian.org
Severity: normal
Control: affects -1 + src:libosmo-sccp
Unfortunately this software no longer runs on 32bit architectures. The time to
fix this is better spent on other things.
Thorsten
Package: ftp.debian.org
Severity: normal
Control: affects -1 + src:osmo-pcu
Unfortunately this software no longer runs on 32bit architectures. The time to
fix this is better spent on other things.
Thorsten
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
Control: severity -1 normal
Control: forwarded -1 https://github.com/alonbl/gnupg-pkcs11-scd/issues/61
I can reproduce this bug with my card reader and I forwarded the bug
upstream -> https://github.com/alonbl/gnupg-pkcs11-scd/issues/61
As this is just a cosmectic bug, I reduce severity again
this ...
... and accepted.
Thorsten
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
Package: libwireshark-dev
Version: 4.2.2-1.1+b1
Severity: important
X-Debbugs-Cc: contact.thors...@gmail.com
Dear Maintainer,
* What led up to the situation?
Trying to build an external package dissector.
* What exactly did you do (or not do) that was effective (or
ineffective)?
tag once that is done.
Thorsten
ome-remote-desktop: libfuse3-dev (3.9.1 >=)
libvirt: libfuse3-dev
vorta: fuse3
In case they matter, this needs to be addressed first. Please remove the
moreinfo tag once that is done.
Thorsten
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
Not all of them are Arch: all, so in case they matter, this needs to be
addressed first. Please remove the moreinfo tag once that is done.
Thorsten
that is done.
Thorsten
-spark: python3-sahara
sahara-plugin-vanilla: python3-sahara
Dependency problem found.
In case they matter, this needs to be addressed first. Please remove the
moreinfo tag once that is done.
Thorsten
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 hindsig
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
1 - 100 of 5719 matches
Mail list logo
