[08:52] <xnox> slyon:  i don't think there is a way to disable that apart from exporting new DEB_BUILD_OPTIONS in the top of debian/rules. But check with rbalint. When I added implied noudeb, i added support to pass '!noudeb' to negate that. But i don't think there is '!nocheck' (aka if nocheck is in place, drop it).
=== rZr is now known as RzR
[09:16] <slyon> xnox: thanks!
[10:33] <tumbleweed> slyon: RE https://launchpad.net/ubuntu/+source/pycparser/2.20-3ubuntu1 what about pypy/pypy3?
[10:36] <slyon> tumbleweed: IMO pypy is supposed to go away together with python2, no? And I'm looking into pypy3 currently to see if it can be built using python3..
[10:37] <tumbleweed> it can't
[10:37] <tumbleweed> so no, pypy sticks around for the moment, to build pypy3
[10:38] <tumbleweed> upstream is working on this, but I don't think they've got very far
[10:39] <tumbleweed> we can live without python-pycparser, if we stop building pypy with cpython. Which does leave us with a bootstrapping problem
[10:43] <tumbleweed> FWIW the relevant upstream porting work is here https://foss.heptapod.net/pypy/pypy/-/tree/branch/rpython3
[10:59] <slyon> thank you for the heads-up! I need to check that upstream work..
[11:21] <tumbleweed> of course pypy also carries a bundled pycparser, we could hack the build to get that on PATH for translation
[11:22] <tumbleweed> and we could carry a cpython2.7 source in the pypy source if the python2.7 source packgae has to go...
[11:24] <slyon> that sounds like a good approach, to keep pypy/3 as self-contained as possible. That way we can move on with the python2-rm transition, keeping pypy isolated so it can easily be remove as soon as pypy3 is ready for Python3.
[11:26] <slyon> I'm not sure about python2.7... but my understanding was that it is supposed to die, especially as python2 has been deprecated since Jan 2020.
[11:27] <tumbleweed> yes, it does need to die, somehow
[11:28] <tumbleweed> I just haven't gone down those rabbit holes because I haven't needed to, yet
[11:38] <toabctl> bdmurray, any reason why bionic was not uploaded to proposed for https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1926732 ?
[11:38] <ubottu> Launchpad bug 1926732 in livecd-rootfs (Ubuntu Hirsute) "Add ubuntu-oci project for building OCI-ready tarballs with livecd-rootfs" [Undecided,Fix committed]
[13:56] <rbalint> slyon, re: nocheck vs riscv see dpkg changelog entry for 1.20.9ubuntu1
[13:56] <rbalint> DEB_BUILD_OPTIONS := $(filter-out nocheck,$(DEB_BUILD_OPTIONS))
[13:58] <slyon> rbalint: thanks! That's a very good hint, exactly what I was looking for :)
[13:59] <xnox> slyon:  no cpython2.7 and pypy will remain.
[13:59] <xnox> slyon:  even if we remove python2-defaults, we will keep python2.7
[13:59] <xnox> a otherwise there is no way to rebootstrap pypy, to rebootstrap pypy3
[13:59] <xnox> *as
[14:00] <xnox> slyon: tumbleweed: the death of python2.7 is a lot harder than simply death of python2-defaults.
[14:01] <slyon> xnox: ack. we might still want to make use of the already bundled pycparser, to avoid keeping python-pycparser + depends (cc tumbleweed)
[14:01] <tumbleweed> yeah, it's worth a try
[14:02] <tumbleweed> from a quick look at the imports, it should be doable, I try it
[14:04] <xnox> +1
[14:53] <tumbleweed> it'd help if I tested with --profile=stage1. Doh.
[14:57] <Laney> slyon: any idea on https://autopkgtest.ubuntu.com/packages/n/netplan.io/hirsute/armhf btw? do you think I really did break it? :(
[14:59] <slyon> Laney: argh.. that test is flaky and disabled in all other series... I think it would be best to hint netplan.io/armhf/0.102-0ubuntu3 ... I don't think its worth doing a full SRU just for the autopkgtest fix
[14:59] <Laney> ahhhh
[15:00] <slyon> could you do that or do you want me to create an MP?
[15:00] <Laney> I got suspicious by the pattern going from all green to red
[15:00] <Laney> well, maybe I technically could, but I'm a bit wary of touching the SRU hints
[15:00]  * Laney picks on some SRU team members
[15:00] <Laney> apw: rbasak: sil2100: mind if I commit the above ^- ?
[15:01] <slyon> yeah it was working previously... I'm not exactly sure what changed in the build environment
[15:01] <slyon> it is most probably container related, as it only happens in the armhf/LXD test
[15:01] <Laney> I think we moved to focal meanwhile, so updated kernel
[15:03] <Laney> I could do the hint for this exact version only, if the skipping will be included in any future SRU?
[15:05] <slyon> Yes. I will include with the next hirsute SRU
[15:06] <Laney> 👍
[15:06] <Laney> ok, waiting for feedback then
[15:14] <slyon> I staged the fix here, so it can go into the next hirsute upload: https://git.launchpad.net/~ubuntu-core-dev/netplan/+git/ubuntu/log/?h=ubuntu/hirsute
[15:25] <Laney> doko: do you have any idea about automake-1.16/armhf? I see 6 retries from you against bison ;-)
[16:13] <doko> Laney: yeah, retried too often. no, didn't look at it yet, and unlikely before mid next week
[16:14] <Laney> alright
[18:15] <realtime-neil> What is the preseedable `partman-base partman/installation_medium_mounted`, why is it forcing an interactive prompt on my preseeded https://cdimage.ubuntu.com/ubuntu-legacy-server/releases/focal/release/ubuntu-20.04.1-legacy-server-amd64.iso , and how do I quiesce this prompt?
[18:51] <TJ-> realtime-neil: is it this? Bug #1491963
[18:51] <ubottu> bug 1491963 in partman-base (Ubuntu) "preseeding for partman/installation_medium_mounted fails because 'seen' is forced to false" [Undecided,Confirmed] https://launchpad.net/bugs/1491963
[18:53] <realtime-neil> TJ-: yep, that's probably the one blocking me
[19:08] <bryce> if I have a package with a debian version 5.1.20+4.0.11-0+deb11u1 that I want to do a no-change rebuild for, what should the new version be?  5.1.20+4.0.11-0+deb11u1-0build1 ?
[19:09] <bryce> or 5.1.20+4.0.11-0+deb11u1build1?
[19:18] <RzR> bryce, dpkg --compare-versions will tell you which one if it will trigger rebuild
[19:20] <RzR> \dpkg --compare-versions  5.1.20+4.0.11-0+deb11u1 lt  5.1.20+4.0.11-0+deb11u1-0build1 && echo lower
[19:20] <bryce> Rzr thanks for the reminder of that.  They both appear to work
[19:20] <RzR> so this will work
[20:32] <cjwatson> bryce: I think just appending build1 rather than appending -0build1 is more conventional
[20:32] <cjwatson> Partly because there are cases where appending -0build1 does Very Confusing Things (due to converting a native version into a non-native version), which isn't the case for just appending build1
[20:35] <bryce> cjwatson, thanks, I did end up going with just build1.  More than one '-' in a version string feels wrong.
[21:13] <cjwatson> bryce: And in fact now that I think about it there's good reason for it to feel that way; the upstream vs. packaging split in the version takes place on the *last* '-'
[21:13] <cjwatson> bryce: So 5.1.20+4.0.11-0+deb11u1-0build1 means upstream version 5.1.20+4.0.11-0+deb11u1, packaging revision 0build1
[21:13] <cjwatson> bryce: And that can have some very surprising effects
[21:23] <bryce> cjwatson, aha, thanks again!
[22:55] <mwhudson> bryce: i'm on +1 maintenance next week, so please let me know of any turn-the-handle type stuff i can do to keep the php transition moving
[22:55] <bryce> mwhudson, noted thanks.