=== d1b_ is now known as d1b === pushkarnk1 is now known as pushkarnk [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] 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)? === sem2peie- is now known as sem2peie [09:30] hi, the following packages fail to build on launchpad, but without log, could someone retry them? [09:30] https://launchpad.net/ubuntu/+source/distrobuilder/3.0-1 [09:30] https://launchpad.net/ubuntu/+source/prometheus-alertmanager/0.26.0+ds-1/+build/26904035 [09:30] https://launchpad.net/ubuntu/+source/fscrypt/0.3.4-2/+build/27693287 [09:30] https://launchpad.net/ubuntu/+source/aerc/0.17.0-1/+build/27819417 [09:30] https://launchpad.net/ubuntu/+source/aerc/0.17.0-1/+build/27819419 [09:34] zhsj: done. I think fscrypt had a log but I retried it anyway [09:37] and distrobuilder fails quickly again :( [09:54] paride: looks like fscrypt does fail on ppc64el. probably due to different harden build env with debian. === sem2peie- is now known as sem2peie [10:00] zhsj: ah distrobuilder is in dep-wait now, for golang-goprotobuf-dev? [10:00] rbasak: etcd needs a new merge, which replaces the deps for golang-goprotobuf-dev [10:03] zhsj, strange, as fscrypt 0.3.3 already had TestMakeKey and built fine on ppc64el [10:03] zhsj, and 0.3.4 builds fine in Debian === guiverc2 is now known as guiverc === pushkarnk1 is now known as pushkarnk === pushkarnk1 is now known as pushkarnk [11:47] Eickmeyer, replying here because the ardour/istools issue isn't really a release one [11:47] Eickmeyer, the problem is that https://github.com/Ardour/ardour/blob/83f5d40280f777c188fe156e8a6fc53fab3e4a60/wscript#L1011C36-L1011C53 parses the cmdline output [11:48] but in noble/with python 3.12 [11:48] https://github.com/Ardour/ardour/blob/83f5d40280f777c188fe156e8a6fc53fab3e4a60/wscript#L1011C36-L1011C53 [11:48] ups [11:48] $ itstool --version [11:48] if re.sub('\s+', ' ', text).strip() != '': [11:48] /usr/bin/itstool:239: SyntaxWarning: invalid escape sequence '\s' [11:48] basically it's getting confused by the python warnings [11:49] you have a bunch of ways to fix it, one is to fix itstool (which seems unmaintained upstream unfortunatly) [11:49] another one is to delete that itstool check in ardour with a distro patch since we know our version is recent enough [11:50] 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] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: ginggs === mfo_ is now known as mfo [12:18] 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] its kinda hidden [12:19] any thoughts? [13:42] 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] jamespage: headers are a bit in between, is it actually lots of actual code in headers that is active then? [13:43] jamespage: or is it just the definition of an interface [13:43] jamespage: the latter would be ok, the former would be a hidden variant of how golang and rust work [13:44] having a look ... [13:47] ok, yes jamespage this is active code which is in the final binary we'd support [13:47] so yes, this would need to get special handling [13:47] In an ideal world it would have Built-Using in the metadata [13:47] languages that have this more often are handling that [13:47] automatically [13:47] but here that isn't the case [13:49] 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] 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] 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] cpaelzer: that was my feeling as well - thanks for the perspective [16:00] @pilot out === ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A [16:01] Thank you for flying Ubuntu Air! [16:27] >:D [16:28] 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] 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] 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] > 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] tsimonq2: thanks for pointing out to this change! [16:44] 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] 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] Is that the least worst option? [16:45] 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] ogayot: You're very welcome :D [16:47] 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] 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] LocutusOfBorg: Uhh... you doing me a favor (re: Ardour)? [17:00] I already did upload [17:00] LocutusOfBorg: I saw! Thanks! [17:01] the default in debian is not 3.12 [17:01] Although, armhf looks sad. [17:01] this is why the bug is Ubuntu only right now [17:01] armhf sad due to *sadness* :) [17:01] but will heal [17:01] hehehe [17:17] tsimonq2: thanks, but that doesn't even cover the edge cases dpkg-maintscript-helper covers! [17:20] Eickmeyer, what LocutusOfBorg said about default [17:20] seb128: Indeed. Thanks to you both. [17:20] we should however fix the culprit, that is regex with incorrect escapes [17:21] 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] tsimonq2: +1 [17:22] LocutusOfBorg: Looks like a bug in Ardour's wscripts to me. I can let them know if you'd like. [17:23] yes please [17:23] also please open a debian bug [17:23] but as said, please try itstool --version [17:23] you will see a lot of python deprecation warnings [17:23] they need fixes [17:25] LocutusOfBorg: I see that. itstool is definitely the culpret here. [17:25] well, both are wrong, the tool not ignoring stderr, and the tool not doing correct regex [17:26] if you fix the regex you also fix ardour [17:26] (until next python sadness) [17:26] Oh, Python... breaking with every release when someone coughs since 1989 [17:28] To be fair, they do actually publish what they expect to deprecate each cycle, well before they do it. [17:29] https://docs.python.org/3.13/whatsnew/3.13.html [17:30] Combine that with https://codesearch.debian.net/ and you have a pretty good idea of what is coming next. [17:30] 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] tsimonq2: The average dev doesn't pay attention to that, and they don't care. They just want stuff to work. [17:57] 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] So, I hope *someone* reads that and finds it useful, even if it's a minority of the audience here. [18:23] LocutusOfBorg: Being part of the multimedia team means I got to patch ardour in salsa myself. [18:24] So, your patch is in salsa. [18:24] Bug filed (haven't seen it yet, sadly). [18:56] 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] do we need that change in noble now, before FF? [18:56] rename libsmbclient => libsmbclient0 for 64-bit time_t transition [18:57] Closes: #1064337 [18:57] ahasenack: we don't need it *before* FF but we do need it [18:57] that will trigger a mini transition [18:57] are we waiting for a bunch of them to land together? [18:57] or should I just merge and upload that now? [18:57] ahasenack: now please [18:58] k [18:58] because right now any package that builds against libsmbclient on armhf in noble, for any reason, will be broken [18:58] fsvo broken [19:00] 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] will these be exempt from feature freeze exceptions? [19:00] depends what else is in that upload? [19:01] (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] ahasenack: t64 is not a feature, at this point it's a bug fix [19:01] ok [19:01] because no-change rebuilds will misbuild [19:17] hm, something going on in armhf noble-proposed? [19:18] 66c5b0a9dc7cbe1b398018f11dd76b1ec823f780 [19:18] er [19:18] libapt-pkg6.0t64 : Breaks: libapt-pkg6.0 (< 2.7.12+nmu1) but 2.7.12 is to be installed [19:18] justache: ^ [19:18] eh [19:18] juliank: ^ [19:18] do we have other revdeps of libapt-pkg6.0 in the base system that need no-change uploaded imminently? [19:21] I'll trigger no-change rebuilds for it now anyway [19:21] vorlon: python3-apt and ubuntu-pro-client [19:25] juliank: well excellent, because I have just uploaded those ;) [19:25] vorlon: I'm considering having them binNMUed in Debian too [19:26] well python3-apt [19:26] yeah they would be eventually but seems good to get this one done asap [19:30] vorlon: armhf build is on hold: https://launchpad.net/ubuntu/+source/python-apt/2.7.6build1/+build/27830534 [19:30] sorry about that [19:30] Let me retry the gnupg2 armhf build, it failed [19:30] it timed out [19:37] heh === pushkarnk1 is now known as pushkarnk === pushkarnk1 is now known as pushkarnk [21:06] juliank: does this look healthy? https://launchpad.net/ubuntu/+source/gnupg2/2.4.4-2ubuntu8/+build/27828643 [21:08] no it should take about 10 mins [21:08] I guess this thing is flaky [21:08] and armhf builders too slow today [21:08] I think the log tail didn't change in the past 15 minutes [21:08] kill/restart? [21:08] yes please [21:11] 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] 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] 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] I've seen a bug about that, I think it's being SRUed [21:18] Yes [21:18] Neat, carry on then. Thanks [21:19] 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] ah it did cancel now [21:19] vorlon: re. bringing the time_t changes to Debian, does this apply to the initial batch of uploads made to experimental? [21:20] sergiodj: sorry, does what apply to it? [21:20] vorlon: merging the packages that have been uploaded as part of the time_t transition [21:21] sergiodj: ah - you don't need to merge from experimental, they'll all be in unstable soon [21:21] vorlon: ACK, thanks. [21:21] and I've been told that these changes won't need an FFe [21:22] sergiodj: correct, they're all bugfixes [21:23] OK, thanks [21:25] Broken builder explains it [22:01] thanks Eickmeyer! I hope also upstream will have a look at it [22:01] LocutusOfBorg: They will. I'm friends with the two lead devs. [22:06] nice! === pushkarnk1 is now known as pushkarnk [22:27] juliank: it has stalled again. https://launchpad.net/ubuntu/+source/gnupg2/2.4.4-2ubuntu8/+build/27828643 [22:27] juliank: is gnupg2 just broken? :P [22:27] It works everywhere else [22:28] Maybe it has a time_t bug [22:28] hahaha [22:28] I mean you could try in commenting the last patch again but then my apt feature breaks which is ugh [22:28] let me see what happens locally [23:17] 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] juliank: local build is hung here: https://paste.ubuntu.com/p/jk4kVwv5mD/ [23:43] juliank: if I temporarily roll back gnupg2 from -proposed will that unblock building python-apt and thus other things? [23:43] because I don't want to debug 'gpgconf --kill all' failing to kill things