Bug#1070860: musescore3: CVE-2023-44428
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 confine suitably. The Capella import is a vast minority feature and incomplete anyway, so I douby many users use it directly. It’ll also document that these versions receive no support (security or otherwise) from upstream any more (they’ve gone open-core, proprietary-extension, version 4, which I don’t intend to package), though there’s a 3.x community effort whose initiator I know, which I’ve been intending to package as musescore-snapshot (it’s “tip of the git branch” without releases to avoid looking official due to the use of the well-known name) and with whom I’ll cooperate. This is a bit like the limited security support for binutils, I suppose. Could/should we document that in the same places? >I will have to investigate whether they mean indeed this >or the musescore.com site or mobile äpps or something. Given the lack of further information, I’ve contacted the ZDI to get some; otherwise I can run it with valgrind a bit, but without a reproducer testcase it’s not very likely to find it. I’ll keep the bugreport informed. 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#1070860: musescore3: CVE-2023-44428
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 site or mobile äpps or something. But if there’s a fix for a parsing issue, I’ll backport it (also to musescore2 if applicable). Thanks for noticing, //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#1070406: Qt5: badly clips some fonts when rendering to PDFs
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 not C++) developer don’t understand. (The other half of fixing things is even more challenging. I got a confirmation that Mu͒seScore Evolution upstream cannot upgrade their Qt versions so they’ll need a different fix subclassing and overriding the library functions for some cases. If anyone sufficiently proficient in C++ is interested in helping with that, once we got the fix for Qt itself going, ping me. Alternatively, helping to figure out how to patch and rebuild the exact versions they use for Win/Mac or upgrade their versions without losing Win7 and qtwebengine, IIUC — AIUI their Mac OSX builds are still at Qt 5.9 for that reason…) >> +static inline int roundForBbox(qreal v) >> +{ >> +return (v < 0) ? floor(v) : ceil(v); >> +} > >I see you are passing negated values to this function, e.g. roundForBbox(-x). Not only them. And roundForBbox is basically just the canonical “round away from zero / towards ±infinity for integer results”. The negation in the callers is to convert *some* Qt coordinates to PS/PDF coordinates, but only for the Y axis, as the X axis is the same for them. >I see why you moved properties to the top, but is moving postscriptName >needed? Maybe leave it where it was to minimize the diff? It’s not. I moved the whole block to make it easier to read, but good point. >You are passing scalep pointer here only to multiply it by this value? Yes. >It looks like fontEngine is a public member of QFontSubset, so you can >do it in the calling code. Yes, except it’s the callee that determines the scaling factor, not the caller. By passing it back like this, nothing would have to change in the caller should the callee ever decide to not scale. Sune Stolborg Vuorela dixit: >I can't find any references to something that look like a "OS/2" table >in the pdf spec. That’s because we’re talking about OTF/TTF-format tables here. The problem exists at two different layers. One is that, when embedding and subsetting a font, Qt generates a PDF font descriptor whose bounding box is wrong. The other is that, when embedding and subsetting a font, Qt converts it to quadratic-spline TTF and scales it to 2048 ppem, then embedding the resulting TTF in the data object corresponding to the above-mentioned font descriptor (the data object itself, when extracted, is a fully functional .ttf font file). The OTF/TTF file format has description tables, and Qt does not correctly adjust all values in all tables it includes when scaling the font itself. >Just to help me double check, how is is the OS/2 table described in the >font in the pdf ? The references I’ve been using are: PDF: https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.0.pdf TTF: https://learn.microsoft.com/en-us/typography/opentype/spec/ The OS/2 table specifically is documented at: https://learn.microsoft.com/en-us/typography/opentype/spec/os2 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#1070406: Qt5: badly clips some fonts when rendering to PDFs
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 ascender in the PDF and >it made Atril happy, so it “should”, despite the still-wrong OS/2 >table values some of which are notably used in clipping by some >softwares…) Yes, that worked. I’m attaching the final patch in entirety again for your convenience. >I’m trying this (attached). That does both (by letting toTruetype() >adjust the already-existing scaling factor in the caller) and >applies suitable rounding (normal for normal values, away from zero >for the bounding box so it’s guaranteed to encompass all possible >values). I’ll build it now so I don’t know if it even compiles yet… It still does not address the OS/2 table, but it does manage to fix both the PDF-side and font-side hhea table metrics, which is enough for Atril at least. (Not sure whether it’s enough for my gf’s printer, I’ll have to test. Or extend the patch to fix the OS/2 table as well, which I probably should anyway; I have to find the time for that sometime within the next few days.) bye, //mirabilos -- > Hi, does anyone sell openbsd stickers by themselves and not packaged > with other products? No, the only way I've seen them sold is for $40 with a free OpenBSD CD. -- Haroon Khalid and Steve Shockley in gmane.os.openbsd.miscDescription: scale /FontBBox and hhea table when scaling fonts for embedding (the OS/2 table needs handling XXX TODO) Author: mirabilos Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070406 --- a/src/gui/painting/qpdf.cpp +++ b/src/gui/painting/qpdf.cpp @@ -1870,11 +1870,20 @@ void QPdfEnginePrivate::writeAttachmentR "endobj\n"); } +static inline int roundForBbox(qreal v) +{ +return (v < 0) ? floor(v) : ceil(v); +} + void QPdfEnginePrivate::embedFont(QFontSubset *font) { +QFontEngine::Properties properties = font->fontEngine->properties(); +QByteArray postscriptName = properties.postscriptName.replace(' ', '_'); +qreal scale = 1000/properties.emSquare.toReal(); + //qDebug() << "embedFont" << font->object_id; int fontObject = font->object_id; -QByteArray fontData = font->toTruetype(); +QByteArray fontData = font->toTruetype(); #ifdef FONT_DUMP static int i = 0; QString fileName("font%1.ttf"); @@ -1891,11 +1900,7 @@ void QPdfEnginePrivate::embedFont(QFontS int toUnicode = requestObject(); int cidset = requestObject(); -QFontEngine::Properties properties = font->fontEngine->properties(); -QByteArray postscriptName = properties.postscriptName.replace(' ', '_'); - { -qreal scale = 1000/properties.emSquare.toReal(); addXrefEntry(fontDescriptor); QByteArray descriptor; QPdf::ByteStream s(); @@ -1909,15 +1914,15 @@ void QPdfEnginePrivate::embedFont(QFontS s << '+' << postscriptName << "\n" "/Flags " << 4 << "\n" "/FontBBox [" - << properties.boundingBox.x()*scale - << -(properties.boundingBox.y() + properties.boundingBox.height())*scale - << (properties.boundingBox.x() + properties.boundingBox.width())*scale - << -properties.boundingBox.y()*scale << "]\n" + << roundForBbox(properties.boundingBox.x()*scale) + << roundForBbox(-(properties.boundingBox.y() + properties.boundingBox.height())*scale) + << roundForBbox((properties.boundingBox.x() + properties.boundingBox.width())*scale) + << roundForBbox(-properties.boundingBox.y()*scale) << "]\n" "/ItalicAngle " << properties.italicAngle.toReal() << "\n" -"/Ascent " << properties.ascent.toReal()*scale << "\n" -"/Descent " << -properties.descent.toReal()*scale << "\n" -"/CapHeight " << properties.capHeight.toReal()*scale << "\n" -"/StemV " << properties.lineWidth.toReal()*scale << "\n" +"/Ascent " << qRound(properties.ascent.toReal()*scale) << "\n" +"/Descent " << qRound(-properties.descent.toReal()*scale) << "\n" +"/CapHeight " << qRound(properties.capHeight.toReal()*scale) << "\n" +"/StemV " << qRound(properties.lineWidth.toReal()*scale) << "\n" "/FontFile2 " << fontstream << "0 R\n" "/CIDSet " << cidset << "0 R\n" ">>\nendobj\n"; --- a/src/gui/text/qfontsubset.cpp +++ b/src/gui/text/qfontsubset.cpp @@ -1162,13 +1162,14 @@ static QByteArray bindFont(const QVector if really required. */ -QByteArray QFontSubset::toTruetype() const +QByteArray QFontSubset::toTruetype(qreal *scalep) const { qttf_font_tables font; memset(, 0, sizeof(qttf_font_tables)); qreal ppem = fontEngine->fontDef.pixelSize; #define TO_TTF(x) qRound(x * 2048. / ppem) +*scalep *=
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
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());
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
Dixi quod… >>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 I’m trying this (attached). That does both (by letting toTruetype() adjust the already-existing scaling factor in the caller) and applies suitable rounding (normal for normal values, away from zero for the bounding box so it’s guaranteed to encompass all possible values). I’ll build it now so I don’t know if it even compiles yet… bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)diff -Nru qtbase-opensource-src-5.15.2+dfsg/debian/changelog qtbase-opensource-src-5.15.2+dfsg/debian/changelog --- qtbase-opensource-src-5.15.2+dfsg/debian/changelog 2021-07-02 17:58:04.0 +0200 +++ qtbase-opensource-src-5.15.2+dfsg/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.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/bug1070406.diff qtbase-opensource-src-5.15.2+dfsg/debian/patches/bug1070406.diff --- qtbase-opensource-src-5.15.2+dfsg/debian/patches/bug1070406.diff 1970-01-01 01:00:00.0 +0100 +++ qtbase-opensource-src-5.15.2+dfsg/debian/patches/bug1070406.diff 2024-05-05 23:57:53.0 +0200 @@ -0,0 +1,107 @@ +Description: scale /FontBBox and hhea table when scaling fonts + for embedding (the OS/2 table needs handling XXX TODO) +Author: mirabilos +Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070406 + +--- a/src/gui/painting/qpdf.cpp b/src/gui/painting/qpdf.cpp +@@ -1870,11 +1870,20 @@ void QPdfEnginePrivate::writeAttachmentR + "endobj\n"); + } + ++static inline int roundForBbox(qreal v) ++{ ++return (v < 0) ? floor(v) : ceil(v); ++} ++ + void QPdfEnginePrivate::embedFont(QFontSubset *font) + { ++QFontEngine::Properties properties = font->fontEngine->properties(); ++QByteArray postscriptName = properties.postscriptName.replace(' ', '_'); ++qreal scale = 1000/properties.emSquare.toReal(); ++ + //qDebug() << "embedFont" << font->object_id; + int fontObject = font->object_id; +-QByteArray fontData = font->toTruetype(); ++QByteArray fontData = font->toTruetype(); + #ifdef FONT_DUMP + static int i = 0; + QString fileName("font%1.ttf"); +@@ -1891,11 +1900,7 @@ void QPdfEnginePrivate::embedFont(QFontS + int toUnicode = requestObject(); + int cidset = requestObject(); + +-QFontEngine::Properties properties = font->fontEngine->properties(); +-QByteArray postscriptName = properties.postscriptName.replace(' ', '_'); +- + { +-qreal scale = 1000/properties.emSquare.toReal(); + addXrefEntry(fontDescriptor); + QByteArray descriptor; + QPdf::ByteStream s(); +@@ -1909,15 +1914,15 @@ void QPdfEnginePrivate::embedFont(QFontS + s << '+' << postscriptName << "\n" + "/Flags " << 4 << "\n" + "/FontBBox [" +- << properties.boundingBox.x()*scale +- << -(properties.boundingBox.y() + properties.boundingBox.height())*scale +- << (properties.boundingBox.x() + properties.boundingBox.width())*scale +- << -properties.boundingBox.y()*scale << "]\n" ++ << roundForBbox(properties.boundingBox.x()*scale) ++ << roundForBbox(-(properties.boundingBox.y() + properties.boundingBox.height())*scale) ++ << roundForBbox((properties.boundingBox.x() + properties.boundingBox.width())*scale) ++ << roundForBbox(-properties.boundingBox.y()*scale) << "]\n" + "/ItalicAngle " << properties.italicAngle.toReal() << "\n" +-"/Ascent " << properties.ascent.toReal()*scale << "\n" +-"/Descent " << -properties.descent.toReal()*scale << "\n" +-"/CapHeight " << properties.capHeight.toReal()*scale << "\n" +-"/StemV " << properties.lineWidth.toReal()*scale << "\n" ++"/Ascent " << qRound(properties.ascent.toReal()*scale) << "\n" ++"/Descent " << qRound(-properties.descent.toReal()*scale) << "\n" ++"/CapHeight " << qRound(properties.capHe
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
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 original developer Thanks for checking. >and ask why it is like that and whether we actually need the OS/2 table. Yeah. Some renderers might benefit from it in some cases probably. It contains about 17 or so values that need to be scaled, and it has multiple versions… I could probably write something… >(and does not break anything else)? Chances are extremely slim that fixing the metrics will break anything ;-) >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 ascender in the PDF and it made Atril happy, so it “should”, despite the still-wrong OS/2 table values some of which are notably used in clipping by some softwares…) I think I can try that, though my weekend’s about up by now. I’d try it with one of the versions (most likely bullseye’s) if that is okay for you. For the Mu͒seScore side, things get trickier though as they likely won’t be able to obtain fixed Qt builds for all platforms. I wonder whether it would be possible to subclass and just override the faulty code (or do post-fixups somehow) and patch it to just do that (if the bug is still present in the used Qt version)… I’m not even a C++ programmer… *sigh* 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#1070406: Qt5: badly clips some fonts when rendering to PDFs
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 the hhea table (found by hexediting). #define TO_TTF(x) qRound(x * 2048. / ppem) This is used in things like… font.hhea.maxAdvanceWidth = TO_TTF(fontEngine->maxCharWidth()); … but not in… font.hhea.ascender = qRound(properties.ascent); font.hhea.descender = -qRound(properties.descent); font.hhea.lineGap = qRound(properties.leading); … and of course not when the OS/2 table is copied: if (!noEmbed) { QTtfTable os2; os2.tag = MAKE_TAG('O', 'S', '/', '2'); os2.data = fontEngine->getSfntTable(os2.tag); if (!os2.data.isEmpty()) tables.append(os2); } (all examples from stretch’s Qt, as the oldest I had at hand) bye, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜ also warum machen die xorg Jungs eigentlich alles kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…
Bug#1070406: Qt5: badly clips some fonts when rendering to PDFs
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 it was TTF already). The conversion is done not incompetently, the new metrics are 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. I can confirm that if I prescale the font to 2048 ppem, ceteris paribus, the bug no longer appears. QPdfEnginePrivate::embedFont calls font->toTruetype() but later uses font->fontEngine->properties() for metrics. QFontSubset::toTruetype does the conversion to 2048 ppem and others, saying it does not need to add an OS/2 table, only to later copy the one from the original font if present without adjusting its values. 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#1070406: Qt5: badly clips some fonts when rendering to PDFs
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 Atril (but not in Okular or mupdf!) have the top of the treble clef cut off. I found that the same happens for glyphs of the font I use for URLs and copyright notices (attached), but only from Mu͒seScore, not from LibreOffice. I first reported this to Atril both because I couldn’t find anything wrong with the font metrics (or after fixing what could have been, I tried multiple variants) upstream at https://github.com/mate-desktop/atril/issues/610 where a helpful soul found that there’s some clip path in the PDFs which Atril honours that clips off the rendering but that under that the glyphs are fully present. Then I dug into the Mu͒seScore Studio source code, but could not find anything suspicious, so I extracted an MWE from its source code (under GPLv2 though I doubt the example below is actually nōntrivial enough to be copyrightable) to generate a PDF and, voilà, the top of the text is cut off in Atril but not in mupdf. I’m attaching the MWE (qex.pro + qex.cc) and the font file (SIL OFL, currently the .otf is the source) so you can reproduce this. It reproduces for me on stretch, bullseye and sid, probably universally. (Make sure $DISPLAY is set. Put the .otf into ~/.local/share/fonts/ to test.) $ QT_SELECT=5 qmake qex.pro && make && ./qex $ mupdf moo.pdf $ atril moo.pdf Please forward this bug upstream as suitable. Thanks in advance! (I don’t have the means to test with upstream’s versions.) -- 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 qtbase5-dev depends on: ii libegl-dev 1.7.0-1+b1 ii libgl-dev 1.7.0-1+b1 ii libglu1-mesa-dev [libglu-dev] 9.0.2-1.1+b1 ii libqt5concurrent5t64 5.15.10+dfsg-7.2+b1 ii libqt5core5t64 5.15.10+dfsg-7.2+b1 ii libqt5dbus5t64 5.15.10+dfsg-7.2+b1 ii libqt5gui5t64 5.15.10+dfsg-7.2+b1 ii libqt5network5t64 5.15.10+dfsg-7.2+b1 ii libqt5printsupport5t64 5.15.10+dfsg-7.2+b1 ii libqt5sql5t64 5.15.10+dfsg-7.2+b1 ii libqt5test5t64 5.15.10+dfsg-7.2+b1 ii libqt5widgets5t64 5.15.10+dfsg-7.2+b1 ii libqt5xml5t64 5.15.10+dfsg-7.2+b1 ii libvulkan-dev 1.3.280.0-1 ii libxext-dev2:1.3.4-1+b1 ii qt5-qmake 5.15.10+dfsg-7.2+b1 ii qtbase5-dev-tools 5.15.10+dfsg-7.2+b1 ii qtchooser 66-2 Versions of packages qtbase5-dev recommends: pn libqt5opengl5-dev Versions of packages qtbase5-dev suggests: pn default-libmysqlclient-dev pn firebird-dev pn libpq-dev pn libsqlite3-dev pn unixodbc-dev -- no debconf information #include #include #include #include #include #include #include #define ensure(what) if (!(what)) errx(1, "%s", #what) int main(int argc, char *argv[]) { QGuiApplication MyApp(argc, argv); QPdfWriter printerDev("moo.pdf"); QPainter p; ensure(p.begin()); p.setRenderHint(QPainter::Antialiasing, true); p.setRenderHint(QPainter::TextAntialiasing, true); QPointF ofs(100, 1000); QFont font("Inconsolatazi4varl_qu", 72); p.setFont(font); p.drawText(ofs, "foi Test 0'l"); p.end(); errx(0, "done"); } CONFIG += debug SOURCES += qex.cc TARGET = qex Inconsolatazi4varl_qu-Regular.otf Description: application/vnd.ms-opentype
Bug#1067946: dietlibc: Includes non-free Sun RPC
Hi Bastian, >I have already informed upstream about it. did you do that on a mailing list? Do you have a link? What did upstream say? Still unconvinced, //mirabilos -- If Harry Potter gets a splitting headache in his scar when he’s near Tom Riddle (aka Voldemort), does Tom get pain in the arse when Harry is near him? -- me, wondering why it’s not Jerry Potter………
Bug#1067196: qpdf: contrary to the documentation, fix-qdf aborts on removed objects
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 :-)
Bug#789401: Proposed patch to solve the issue.
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 initscripts are not run. In addition, I often do use the access to the /tmp in the chroot for debugging and bootstrapping, so maybe create a new system group, chown 0:_pbuilder /var/cache/pbuilder/build; chmod 0750 that directory, and good is? (Untested.) Then, I could add my user to that group and continue doing so. 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#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: ☃ ЦΤℱ—8 ☕☂☄ 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 :-)