=== cpaelzer__ is now known as cpaelzer
[08:58] <jibel> vorlon, I downgraded debhelper to 13.2.1ubuntu1 and hw-detect builds
[09:06] <seb128> xnox, ^
[09:36] <cpaelzer> doko: FYI I'm still on +1 this week (dragging over from last week to reach the time we committed :-) )
[09:36] <cpaelzer> doko: so you are not alone today :-)
[09:36] <cpaelzer> doko: but I'd have a question, and on another case need some ubuntu-aa help
[09:37] <cpaelzer> I'll ask for the second and once I see you around we could talk about the other as well then
[09:37] <cpaelzer> I've seen spyder -> 4.2.1 in proposed, that was blocked on tests of spyde-memory-profiler (that I fixed by testing vs the right version)
[09:38] <cpaelzer> but what is left is that spyder-reports still fails to test against this, yet in Debian it was removed for the very same reason
[09:38] <cpaelzer> https://tracker.debian.org/news/1235339/spyder-reports-removed-from-testing/
[09:38] <cpaelzer> I wanted to ask if you could remove spyder-reports from Hirsute as well (for he same reason) which would make the other spyder-* packages migrate
[09:39] <cpaelzer> let me know what you think when you are around ...
[09:54] <cpaelzer> doko: let me know if you'd need a LP bug for removing spyder-reports and I'll file one
[09:55] <franks2> Hi, I just published this bug report: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1918935
[09:55] <ubot5> Ubuntu bug 1918935 in imagemagick (Ubuntu) "convert(1) segfault" [Undecided,New]
[10:11] <doko> jibel, seb128, xnox, vorlon: hw-detect only builds udeb's.
[10:13] <seb128> doko, I didn't follow the details but the issue there is ubiquity failing to build I think
[10:13] <doko> which are not built anymore. so either make the required package a normal package, or clear the noudeb profile in hw-detect
[10:18] <seb128> franks2, hey, that doesn't sound a release issue, the bug report should be enough, no need to mention it on IRC
[10:19] <doko> and there seem to be more udeb's that ubiquity is implicitly relying on
[10:21] <seb128> something for you guys to fix I guess, ubiquity is in the foundations set
[10:43] -queuebot:#ubuntu-release- Unapproved: python-rtslib-fb (groovy-proposed/main) [2.1.73-1ubuntu4 => 2.1.73-1ubuntu4.1] (no packageset)
=== cpaelzer__ is now known as cpaelzer
[10:58] <cpaelzer> doko: Hi - I saw you answering other pngs by now, have you seen my ping/question around 10:40 today?
[11:08] <cpaelzer> doko: seb128: after resolving openscad on thu and mysql-8 FTFBS over the weekend I've now uploaded a php-easyrdf fix and rekicked tests. That should (tm) be the last step for libzip to migrate.
[11:08] <cpaelzer> we'll know in a few hours once britney had time for a full new run
[11:08] <cpaelzer> now looking at freecad
[11:11] <cpaelzer> xnox: while reading through excuses I'Ve seen that https://launchpad.net/ubuntu/+source/wireshark/3.4.3-1ubuntu1 is an FTFBS on all arches
[11:11] <cpaelzer> was there any follow up since the upload?
[11:14] <cpaelzer> seems like your upload is part of the glib2.0 party => https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1916705/comments/9
[11:14] <ubot5> Ubuntu bug 1916705 in ukui-control-center (Ubuntu) "glib2.0 >=2.67.3 breaks include from an extern C context" [Undecided,Triaged]
[11:15] <cpaelzer> so maybe you could try this suggestion out to re-nuild it with that and maybe get it out of proposed?
[11:16] <cpaelzer> And Debian got 3.4.4 in the meantime https://tracker.debian.org/news/1235902/accepted-wireshark-344-1-source-into-unstable/
[11:16] <cpaelzer> so maybe rebase?
[11:16] <cpaelzer> doko: pkgconf is also unblocked, that was a flaky test on libthai
[11:26] <LocutusOfBorg> cpaelzer, freecad looks like an "hey new release failing stuff, kick this out from proposed pocket, no change rebuild the previous one, restore the new one in proposed pocket"
[11:26] <cpaelzer> That is in bug https://bugs.launchpad.net/ubuntu/+source/freecad/+bug/1918474
[11:26] <ubot5> Ubuntu bug 1918474 in freecad (Ubuntu) "femtest.app.test_open.TestObjectOpen test fails on s390x in hirsute" [Medium,Confirmed]
[11:26] <cpaelzer> which is an OOM
[11:26] <LocutusOfBorg> fixing the big endian issue is preferred
[11:26] <cpaelzer> is there something going deeper that found this is big-endian issue already?
[11:27] <LocutusOfBorg> I didn't deep into it, sorry
[11:27] <LocutusOfBorg> I was just saying that restoring and rebuilding previous version might speed up the migration
[11:30] <cpaelzer> yeah it seems to always consume all-memory, no matter how big the guest is sized
[16:13] <xnox> cpaelzer:  wireshark ftbfs is related to glib2.0 fiasco at the time. If glib2.0 is resolved, it should be ftbfs with test suite error. There was no follow up yet.
[16:14] <xnox> seb128: jibel:  why are you trying to build hw-detect ?! =)
[16:15] <xnox> jibel:  i am working on getting ubiquity to build again, but please do not revert debhelper. We do not want udebs in the archive. But yes, ubiquity does want udebs.
[16:15] <seb128> xnox, I don't think we want, that's just on what ubiquity is failing
[16:16] <seb128> xnox, thanks for fixing the ubiquity build!
[16:16] <jibel> jibel, I am trying to build ubiquity not hw-detect
[16:30] <vorlon> jibel: btw are you aware of LP: #1918929 ? seems desktop images are not passing tests
[16:30] <ubot5> Launchpad bug 1918929 in Ubuntu CD Images "hirsute-desktop-amd64.iso not updated" [Undecided,New] https://launchpad.net/bugs/1918929
[16:34] <cpaelzer> xnox: I know it was glib2.0 in the link I've posted this morning was a suggested fix that would need to be uploaded
[16:35] <cpaelzer> as this won't be finally fixed in glib, but in the B-D packages to it
[16:35] <cpaelzer> Laney: put some help there and has added examples on the bug
[16:35] <cpaelzer> xnox: hence I pinged you to consider re-uploading wireshark with that applied
[16:38] <jibel> vorlon, yes, I didn't have time to check today but I'll do it first thing tomorrow
[16:38] <vorlon> jibel: ok cheers
[17:06] <xnox> cpaelzer:  i see. that workaround is not nice though =/ cause eventually glib will drop support for that define too. But i guess maybe only when they break the abi.
[17:08] <Laney> It's not a workaround, and no.
[17:09] <xnox> ok
[17:10] <Laney> 🤘
[17:11] <Laney> I wouldn't do it like that person suggested though, there are some nice constants, see my comment(s) on the bug
=== ebarretto_ is now known as ebarretto
[17:20] <xnox> Laney:  actually most of the wireshark code is correct. and includes glib.h headers outside of extern C blocks. I'm trying to figure out how much needs to be patched such that I don't need to use the MIN/MAX thing.
[17:21] <Laney> That's a good thing to use anyway
[17:21] <Laney> It's not a workaround, it's good practice. Really both fixes should be done :-)
[17:21] <xnox> oh
[17:21] <xnox> how come?
[17:22] <xnox> how do we track and upgrade to newer glib then?
[17:22] -queuebot:#ubuntu-release- Packageset: Removed lowdown from i386-whitelist in focal
[17:22] -queuebot:#ubuntu-release- Packageset: Added llvm-toolchain-11 to i386-whitelist in focal
[17:22] -queuebot:#ubuntu-release- Packageset: Added autoconf2.64 to i386-whitelist in hirsute
[17:22] -queuebot:#ubuntu-release- Packageset: Added lowdown to i386-whitelist in hirsute
[17:22] -queuebot:#ubuntu-release- Packageset: Added unifont to i386-whitelist in hirsute
[17:23] <xnox> oh, as in i can request the min 2.35 or whatever and fix all the things to match that?
[17:23] <xnox> or even higher than that.
[17:23] <Laney> It's supposed to control when breaking changes happen, so projects can opt into them
[17:23] <Laney> Or the visibility of deprecations and stuff
[17:24] <Laney> So you can bump it and then get the cool new C++ typesafe thing but maybe have to fix your externs, or not and don't
=== ijohnson is now known as ijohnson|lunch
[17:26] <xnox> hm.
[17:27] <xnox> from what i can tell, wireshark codebase almost always has glib.h include outside of extern "C" {}, and only a few places inside it. which has always been wrong. And i'd rather fix that properly.
[17:27] <Laney> You can set the defines to the current version then :-)
[17:27] <Laney> Then you don't get the *next* breakage
[17:27] <xnox> people do backport wireshark a lot, so i wouldn't want to lock them onto too high of an abi.
[17:27] <xnox> hm.
[17:28] <xnox> oh, i will not set min, but only max.
[17:28] <xnox> i think i am still under the weather and brain is still mushy.
[17:32] <xnox> Laney:  does glib emit a warning if glib.h is included inside c++ translation unit, inside extern "C" block?
[17:33] <xnox> cause i think with latest traits fix, wireshark no longer highlights all the places were it does include glib.h inside extern c block.
[17:33] <Laney> don't think so, iirc something fails to build
[17:33] <Laney> if you use one of the bad things
[17:38] <klebers> hi! could someone please re-trigger this failed riscv64 build for xtables-addons? https://launchpad.net/ubuntu/+source/xtables-addons/3.9-1ubuntu0.2~20.04.1/+build/21136816
=== mfo_ is now known as mfo
[19:47] <xnox> vorlon:  responded to https://code.launchpad.net/~xnox/ubuntu-cdimage/add-unmatched/+merge/399498