[08:55] <[a]> Good day to all. I'm having trouble stopping or pausing at the Ubuntu 22.04 boot menu to select single-user mode for resetting the root password. The issue is that the boot process is too fast for me to interrupt GRUB2 and navigate through my options. I'm using a VM managed/booted via VMWare vShere. I've tried adjusting the Boot Delay in VM Options
[08:55] <[a]> -> Boot tools, but it hasn't helped. Any advice would be greatly appreciated. Thanks in advance.
[09:12] <fheimes> Hi #archive-admins AA - the s390-tools v2.31 s390x package needs special approval and is currently in noble's unapproved queue (also visible here: https://launchpad.net/ubuntu/+source/s390-tools/2.31.0-0ubuntu1/ or in britney). I'm kindly asking for an approval (well, maybe sil2100)?
[09:30] <zhsj> hi, the following packages fail to build on launchpad, but without log, could someone retry them?
[09:30] <zhsj> https://launchpad.net/ubuntu/+source/distrobuilder/3.0-1
[09:30] <zhsj> https://launchpad.net/ubuntu/+source/prometheus-alertmanager/0.26.0+ds-1/+build/26904035
[09:30] <zhsj> https://launchpad.net/ubuntu/+source/fscrypt/0.3.4-2/+build/27693287
[09:30] <zhsj> https://launchpad.net/ubuntu/+source/aerc/0.17.0-1/+build/27819417
[09:30] <zhsj> https://launchpad.net/ubuntu/+source/aerc/0.17.0-1/+build/27819419
[09:34] <rbasak> zhsj: done. I think fscrypt had a log but I retried it anyway
[09:37] <zhsj> and distrobuilder fails quickly again :(
[09:54] <zhsj> paride: looks like fscrypt does fail on ppc64el. probably due to different harden build env with debian.
[10:00] <rbasak> zhsj: ah distrobuilder is in dep-wait now, for golang-goprotobuf-dev?
[10:00] <zhsj> rbasak: etcd needs a new merge, which replaces the deps for golang-goprotobuf-dev
[10:03] <paride> zhsj, strange, as fscrypt 0.3.3 already had TestMakeKey and built fine on ppc64el
[10:03] <paride> zhsj,  and 0.3.4 builds fine in Debian
[11:47] <seb128> Eickmeyer, replying here because the ardour/istools issue isn't really a release one
[11:47] <seb128> Eickmeyer, the problem is that https://github.com/Ardour/ardour/blob/83f5d40280f777c188fe156e8a6fc53fab3e4a60/wscript#L1011C36-L1011C53 parses the cmdline output
[11:48] <seb128> but in noble/with python 3.12
[11:48] <seb128> https://github.com/Ardour/ardour/blob/83f5d40280f777c188fe156e8a6fc53fab3e4a60/wscript#L1011C36-L1011C53
[11:48] <seb128> ups
[11:48] <seb128> $ itstool --version
[11:48] <seb128>   if re.sub('\s+', ' ', text).strip() != '':
[11:48] <seb128> /usr/bin/itstool:239: SyntaxWarning: invalid escape sequence '\s'
[11:48] <seb128> basically it's getting confused by the python warnings
[11:49] <seb128> you have a bunch of ways to fix it, one is to fix itstool (which seems unmaintained upstream unfortunatly)
[11:49] <seb128> another one is to delete that itstool check in ardour with a distro patch since we know our version is recent enough
[11:50] <seb128> another one is to make the parsing smart enough to get the version anyway, or to call the cmd with 2>/dev/null
[12:01] <ginggs> @pilot in
[12:18] <jamespage> cpaelzer: hey - I had a question for the MIR team yesterday but completely forgot to ask it! When I was reviewing bpftrace I noted it used libcereal-dev which is a headers only library - this made be consider whether that actually needed special handling as there is no linker generated runtime binary depends to pull its function into main as well
[12:18] <jamespage> its kinda hidden
[12:19] <jamespage> any thoughts?
[13:42] <cpaelzer> jamespage: since Trusty or so, if it is "only" a build-dependency but not ending up in the final code it does not need to be in main
[13:42] <cpaelzer> jamespage: headers are a bit in between, is it actually lots of actual code in headers that is active then?
[13:43] <cpaelzer> jamespage: or is it just the definition of an interface
[13:43] <cpaelzer> jamespage: the latter would be ok, the former would be a hidden variant of how golang and rust work
[13:44] <cpaelzer> having a look ...
[13:47] <cpaelzer> ok, yes jamespage this is active code which is in the final binary we'd support
[13:47] <cpaelzer> so yes, this would need to get special handling
[13:47] <cpaelzer> In an ideal world it would have Built-Using in the metadata
[13:47] <cpaelzer> languages that have this more often are handling that
[13:47] <cpaelzer> automatically
[13:47] <cpaelzer> but here that isn't the case
[13:49] <cpaelzer> not fully what https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using was meant for, but which is why those other languages migrated over time to more specific entries
[13:50] <cpaelzer> TL;DR: yes it is a special case and it should be in main, and actually we'D need to discuss with security how such would need to be expressed so trackign works well
[13:54] <cpaelzer> There seems to be a whole ecosystem of those with libseqan3-dev and libmlpack-dev appearing similar, but not yet used in main as build-dependency
[14:48] <jamespage> cpaelzer: that was my feeling as well - thanks for the perspective
[16:00] <ginggs> @pilot out
[16:01] <ginggs> Thank you for flying Ubuntu Air!
[16:27] <tsimonq2> >:D
[16:28] <tsimonq2> ogayot, dbungert(, etc.): o/ in case you all still leverage ssh-import-id in Subiquity, here ya go: https://bugs.launchpad.net/ssh-import-id/+bug/1745538
[16:28] -ubottu:#ubuntu-devel- Launchpad bug 1745538 in ssh-import-id "Support for Launchpad teams should be added" [Wishlist, Fix Committed]
[16:29] <tsimonq2> Please ping me directly and loudly if https://launchpad.net/ubuntu/+source/ssh-import-id/5.11-0ubuntu2 causes *any* issues. I tested it very thoroughly and did get a second set of eyes.
[16:29] <tsimonq2> Anyone from ssh-import-id upstream is welcome to grab my quilt patch if you get to it before I can submit an updated MP. ;)
[16:31] <tsimonq2> > devel is used so that 'account_status' attribute can be respected. - at that point I'd be happy to debate whether adding that is a Feature or a Bug. :)
[16:39] <ogayot> tsimonq2: thanks for pointing out to this change!
[16:44] <rbasak> If a binary package is being renamed, and both the old and new binary package shipped a conffile that is to remain, then what's the correct way of doing that?
[16:44] <rbasak> If just start shipping the conffile from the new package, then dpkg treats the old conffile from the old package as "obsolete" (since it no longer ships it)
[16:44] <rbasak> Is that the least worst option?
[16:45] <rbasak> I don't see anything for this case in dpkg-maintscript-helper(1) unless mv_conffile is supposed to do it, but that doesn't seem likely to me.
[16:46] <tsimonq2> ogayot: You're very welcome :D
[16:47] <tsimonq2> rbasak: Not saying this is a full answer, but if you haven't yet, I'd take a peek at this, which may point you in the right direction: https://www.debian.org/doc/debian-policy/ap-pkg-conffiles.html#automatic-handling-of-configuration-files-by-dpkg
[16:50] <Eickmeyer> seb128: re ardour: I guess the part that's confusing to me is that I understood that unstable is also using python 3.12 and, therefore, should act the same?
[16:59] <Eickmeyer> LocutusOfBorg: Uhh... you doing me a favor (re: Ardour)?
[17:00] <LocutusOfBorg> I already did upload
[17:00] <Eickmeyer> LocutusOfBorg: I saw! Thanks!
[17:01] <LocutusOfBorg> the default in debian is not 3.12
[17:01] <Eickmeyer> Although, armhf looks sad.
[17:01] <LocutusOfBorg> this is why the bug is Ubuntu only right now
[17:01] <LocutusOfBorg> armhf sad due to *sadness* :)
[17:01] <LocutusOfBorg> but will heal
[17:01] <Eickmeyer> hehehe
[17:17] <rbasak> tsimonq2: thanks, but that doesn't even cover the edge cases dpkg-maintscript-helper covers!
[17:20] <seb128> Eickmeyer, what LocutusOfBorg said about default
[17:20] <Eickmeyer> seb128: Indeed. Thanks to you both.
[17:20] <LocutusOfBorg> we should however fix the culprit, that is regex with incorrect escapes
[17:21] <LocutusOfBorg> I just fixed the parsing of the tool output
[17:21]  * tsimonq2 would be curious to hear about the efforts to start that transition Debian-side so we have Less Deltas ;)
[17:21] <Eickmeyer> tsimonq2: +1
[17:22] <Eickmeyer> LocutusOfBorg: Looks like a bug in Ardour's wscripts to me. I can let them know if you'd like.
[17:23] <LocutusOfBorg> yes please
[17:23] <LocutusOfBorg> also please open a debian bug
[17:23] <LocutusOfBorg> but as said, please try itstool --version
[17:23] <LocutusOfBorg> you will see a lot of python deprecation warnings
[17:23] <LocutusOfBorg> they need fixes
[17:25] <Eickmeyer> LocutusOfBorg: I see that. itstool is definitely the culpret here.
[17:25] <LocutusOfBorg> well, both are wrong, the tool not ignoring stderr, and the tool not doing correct regex
[17:26] <LocutusOfBorg> if you fix the regex you also fix ardour
[17:26] <LocutusOfBorg> (until next python sadness)
[17:26] <Eickmeyer> Oh, Python... breaking with every release when someone coughs since 1989
[17:28] <tsimonq2> To be fair, they do actually publish what they expect to deprecate each cycle, well before they do it.
[17:29] <tsimonq2> https://docs.python.org/3.13/whatsnew/3.13.html
[17:30] <tsimonq2> Combine that with https://codesearch.debian.net/ and you have a pretty good idea of what is coming next.
[17:30] <tsimonq2> For example, I knew about distutils well before we were having the conversation about "why did Python do this" thanks to this page: https://docs.python.org/3.13/whatsnew/3.12.html
[17:31] <Eickmeyer> tsimonq2: The average dev doesn't pay attention to that, and they don't care. They just want stuff to work.
[17:57] <tsimonq2> Eickmeyer: That may be true about the average dev, but some people (like me) just get too curious not to look every once in a while. ;)
[17:57] <tsimonq2> So, I hope *someone* reads that and finds it useful, even if it's a minority of the audience here.
[18:23] <Eickmeyer> LocutusOfBorg: Being part of the multimedia team means I got to patch ardour in salsa myself.
[18:24] <Eickmeyer> So, your patch is in salsa.
[18:24] <Eickmeyer> Bug filed (haven't seen it yet, sadly).
[18:56] <ahasenack> vorlon: I'm just watching the time_t transition from afar, but just saw this: https://tracker.debian.org/news/1507767/accepted-samba-24195dfsg-2-source-into-unstable/
[18:56] <ahasenack> do we need that change in noble now, before FF?
[18:56] <ahasenack>  rename libsmbclient => libsmbclient0 for 64-bit time_t transition
[18:57] <ahasenack>      Closes: #1064337
[18:57] <vorlon> ahasenack: we don't need it *before* FF but we do need it
[18:57] <ahasenack> that will trigger a mini transition
[18:57] <ahasenack> are we waiting for a bunch of them to land together?
[18:57] <ahasenack> or should I just merge and upload that now?
[18:57] <vorlon> ahasenack: now please
[18:58] <ahasenack> k
[18:58] <vorlon> because right now any package that builds against libsmbclient on armhf in noble, for any reason, will be broken
[18:58] <vorlon> fsvo broken
[19:00] <vorlon> ahasenack: basically, right now we're focused on getting all the NMUs to unstable done as quickly as possible and let them autosync where possible; then the next step is we have to identify all the libs that need merged.  So you can jump to the next step for packages you care about :)
[19:00] <ahasenack> will these be exempt from feature freeze exceptions?
[19:00] <ahasenack> depends what else is in that upload?
[19:01] <vorlon> (step 3 is fix any Ubuntu-specific libraries affected; step 4 is upload libraries that are LFS-sensitive but not entangled with time_t so that they DON'T break ABI)
[19:01] <vorlon> ahasenack: t64 is not a feature, at this point it's a bug fix
[19:01] <ahasenack> ok
[19:01] <vorlon> because no-change rebuilds will misbuild
[19:17] <ahasenack> hm, something going on in armhf noble-proposed?
[19:18] <ahasenack> 66c5b0a9dc7cbe1b398018f11dd76b1ec823f780
[19:18] <ahasenack> er
[19:18] <ahasenack>  libapt-pkg6.0t64 : Breaks: libapt-pkg6.0 (< 2.7.12+nmu1) but 2.7.12 is to be installed
[19:18] <vorlon> justache: ^
[19:18] <vorlon> eh
[19:18] <vorlon> juliank: ^
[19:18] <vorlon> do we have other revdeps of libapt-pkg6.0 in the base system that need no-change uploaded imminently?
[19:21] <vorlon> I'll trigger no-change rebuilds for it now anyway
[19:21] <juliank> vorlon: python3-apt and ubuntu-pro-client
[19:25] <vorlon> juliank: well excellent, because I have just uploaded those ;)
[19:25] <juliank> vorlon: I'm considering having them binNMUed in Debian too
[19:26] <juliank> well python3-apt
[19:26] <vorlon> yeah they would be eventually but seems good to get this one done asap
[19:30] <ahasenack> vorlon: armhf build is on hold: https://launchpad.net/ubuntu/+source/python-apt/2.7.6build1/+build/27830534
[19:30] <juliank> sorry about that
[19:30] <juliank> Let me retry the gnupg2 armhf build, it failed
[19:30] <juliank> it timed out
[19:37] <vorlon> heh
[21:06] <vorlon> juliank: does this look healthy? https://launchpad.net/ubuntu/+source/gnupg2/2.4.4-2ubuntu8/+build/27828643
[21:08] <juliank> no it should take about 10 mins
[21:08] <juliank> I guess this thing is flaky
[21:08] <juliank> and armhf builders too slow today
[21:08] <vorlon> I think the log tail didn't change in the past 15 minutes
[21:08] <vorlon> kill/restart?
[21:08] <juliank> yes please
[21:11] <juliank> If it continues hanging, might as well make gnupg binary Arch: any so that it doesn't get updated ahead of the others in Packages files
[21:12] <juliank> Really should probably get this solved in launchpad, retention of odl Architecture: all and pushing the Architecture: all into the binary-X that matches the Architecture: X versions
[21:18] <UnivrslSuprBox> Is it known that it's currently impossible to debootstrap noble on jammy? unpacking base-files fails due to `tar: ./bin: Cannot create symlink to 'usr/bin': File exists` and similar. I can debootstrap noble using an existing noble or mantic host, and I can bootstrap mantic from jammy.
[21:18] <ahasenack> I've seen a bug about that, I think it's being SRUed
[21:18] <juliank> Yes
[21:18] <UnivrslSuprBox> Neat, carry on then. Thanks
[21:19] <vorlon> juliank: cancelled but I think the builder died so launchpad is taking a long time to actually cancel, I've escalated to the team
[21:19] <vorlon> ah it did cancel now
[21:19] <sergiodj> vorlon: re. bringing the time_t changes to Debian, does this apply to the initial batch of uploads made to experimental?
[21:20] <vorlon> sergiodj: sorry, does what apply to it?
[21:20] <sergiodj> vorlon: merging the packages that have been uploaded as part of the time_t transition
[21:21] <vorlon> sergiodj: ah - you don't need to merge from experimental, they'll all be in unstable soon
[21:21] <sergiodj> vorlon: ACK, thanks.
[21:21] <sergiodj> and I've been told that these changes won't need an FFe
[21:22] <vorlon> sergiodj: correct, they're all bugfixes
[21:23] <sergiodj> OK, thanks
[21:25] <juliank> Broken builder explains it
[22:01] <LocutusOfBorg> thanks Eickmeyer! I hope also upstream will have a look at it
[22:01] <Eickmeyer> LocutusOfBorg: They will. I'm friends with the two lead devs.
[22:06] <LocutusOfBorg> nice!
[22:27] <vorlon> juliank: it has stalled again. https://launchpad.net/ubuntu/+source/gnupg2/2.4.4-2ubuntu8/+build/27828643
[22:27] <vorlon> juliank: is gnupg2 just broken? :P
[22:27] <juliank> It works everywhere else
[22:28] <juliank> Maybe it has a time_t bug
[22:28] <vorlon> hahaha
[22:28] <juliank> I mean you could try in commenting the last patch again but then my apt feature breaks which is ugh
[22:28] <vorlon> let me see what happens locally
[23:17] <vorlon> juliank: still working on my local build, my armhf system is much slower than the launchpad builders (I guess I should've put this on my canonistack instance)
[23:42] <vorlon> juliank: local build is hung here: https://paste.ubuntu.com/p/jk4kVwv5mD/
[23:43] <vorlon> juliank: if I temporarily roll back gnupg2 from -proposed will that unblock building python-apt and thus other things?
[23:43] <vorlon> because I don't want to debug 'gpgconf --kill all' failing to kill things