[00:37] mwhudson, may you click on this one too? :P https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=s390x&package=python-flake8&trigger=pycodestyle/2.10.0-1&trigger=python-flake8/5.0.4-4 [00:38] danilogondolfo: done [00:38] thank you! === cpaelzer_ is now known as cpaelzer === JanC_ is now known as JanC [10:45] hi, I'm preparing an SRU request for anacron and I'd like to know more about staging; the issue to fix is in the anacron.postrm that is used in kinetic and that means the issue happens on package upgrade _from_ this version [10:45] there's a fix for the issue and a work-around for its consequences [10:46] but since it only happens on package update, there is no need to apply this unless you're already updating the package [10:46] is it possible to stage an SRU possibly forever? [10:47] kanashiro[m]: I wonder if the rational for the libtracefs/libtraceevent MIR is strong enough to support promoting them? Especially now that upstream has made those dependencies optional: https://github.com/pmem/ndctl/commit/82884ee (cc @didrocks, this applies to the libtracefs MIR, too) [10:47] -ubottu:#ubuntu-devel- Commit 82884ee in pmem/ndctl "cxl/monitor: Make libtracefs dependency optional" [10:47] Do we really need/want to support this usecase? [10:47] the need is only to have the fixed version before other changes (e.g. security) but there is no requirement of a specific date [10:47] wrt. https://bugs.launchpad.net/ubuntu/+source/libtraceevent/+bug/2009715 [10:47] -ubottu:#ubuntu-devel- Launchpad bug 2009715 in libtraceevent (Ubuntu) "[MIR] Promote libtraceevent as a dependency of libtracefs" [Undecided, New] [10:48] sergiodj: o/ I'll take back the mosh MIR work [12:02] Anybody available for a quick code review for update-notifier? It's a trivial change (code style) just to fix autopkgtests. https://code.launchpad.net/~danilogondolfo/update-notifier/+git/update-notifier/+merge/439294 [12:21] danilogondolfo, hey, thanks for the fix, merged now [12:21] thanks, seb128 [12:22] danilogondolfo, I'm going to upload as well [12:25] slyon: TBH I had not seen this upstream patch when I was working on it... I believe you are right, let's disable it and avoid the promotion. Would you upload your debdiff? [13:02] kanashiro[m]: Thanks for your answer! [13:02] I've marked the MIR a NACK/WONTFIX for now: https://bugs.launchpad.net/ubuntu/+source/libtraceevent/+bug/2009715 [13:02] -ubottu:#ubuntu-devel- Launchpad bug 2009715 in libtraceevent (Ubuntu) "[MIR] Promote libtraceevent as a dependency of libtracefs" [Undecided, Incomplete] [13:02] will upload my debdiff [13:06] slyon: thank you [14:41] rbasak: ACK, thanks [15:36] adrien: there is a block-proposed-$stablerelease tag that does this see https://ubuntu-archive-team.ubuntu.com/pending-sru.html for examples [15:40] bdmurray: thanks! I wasn't expecting so many updates to be blocked that long but that's good for my needs :) [15:42] In an autopkgtest environment I see that $HOME isn't set. [15:42] But things like ssh will look in ~/.ssh etc, and I'd like to find out where that is. [15:42] What's the appropriate way? [15:42] Maybe: getent passwd `whoami`|cut -d: -f6 [15:42] Or is there a better approach? [15:52] hm, this seems like pooor form - i can't build the systemd *source* package on jammy (even with -d)? that's very unfortunate... [15:55] I had a look at what ssh does when HOME isn't set (it actually does the same when it is set) and it's getent so whoami + getent + cut seems to be a good match [15:57] for my anacron SRU, does it sound acceptable to block the update and require a trivial revert to be done if unblocking is needed, or should I craft a version with the revert already included? === sem2peie- is now known as sem2peie [17:09] hallyn: lunar needs dh-sequence-installnss from dh-nss IIRC, which is not in Jammy. You should be able to do the build in a lunar schroot or similar [17:10] Or I can just stage the change for you if you don't feel like messing around with it [17:26] I'm very unsure about the version numbers to use: kinetic has 2.3-33ubuntu1, lunar has 2.3-36ubuntu2 at the moment and that's basically the version I want to SRU, but do I have to use 2.3-33ubuntu2 for the SRU version or can I use something like 2.3-35ubuntu* ? [17:37] adrien: the SRU wiki (https://wiki.ubuntu.com/StableReleaseUpdates) points to another page with some good guidance on SRU version numbering (https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging) [17:42] right, thanks; and I think I need to do more packaging changes than I had hoped for :/ [17:50] enr0n: yeah, i built it in a container then copied it over to debsign it. [17:51] looks like it built successfully in https://launchpad.net/~serge-hallyn/+archive/ubuntu/systemd/+packages (https://launchpadlibrarian.net/656935958/systemd_252.5-2ubuntu3~ppa1_source.changes) [19:22] thanks for git-ubuntu; that took only a couple minutes to do actually (most of the time being spent checking d/changelog) [21:15] who is on +1 maintenance this week? [21:15] if I could suggest a package [21:16] python-flake8 curently broke in lunar due to pycodestyle just having migrated [21:16] we need python-flake8 that is in lunar-proposed [21:17] which is apparently blocked in icdiff: https://autopkgtest.ubuntu.com/packages/i/icdiff/lunar/s390x [21:17] icdiff passed in debian: https://ci.debian.net/packages/i/icdiff/ [21:31] ahasenack: I believe danilogondolfo is on +1 and is currently looking at icdiff [21:31] awesome [21:33] ahasenack, hi there, yeah I already spent a few hours looking at python-flake8 and icdiff today [21:34] I have a dirty fix for icdiff, well I will drop the problem here... [21:34] so, one of icdiff tests will use process substitution to read a file and expects getting the file descriptor 63 to succeed :P [21:35] this would be the first fd provided by bash when using process substitution [21:35] although, for reasons I don't understand yet, in the autopkgtest environment, the bash process running the test script will already have fds 63 and 62 opened as pipes, so the process substitution will get the fd 61 and fail the test [21:35] yeah, I saw the diff in that test failure, 61 vs 63 was the only difference I could spot [21:36] closing these fds when the script starts fix the test [21:36] but it seems dirty and I'm not sure if it's ok [21:37] in debian it's not happening for some reason [21:37] the package is a sync, right? [21:37] I forgot [21:37] yes [21:37] apparently it passes on Debian, but fails for me when I try... [21:37] ahasenack, https://pastebin.ubuntu.com/p/DYzndVDmjt/ [21:38] so it passed in debian back then [21:38] as I said, dirty... [21:38] yeah [21:39] another solution would be changing the test to not rely on the fd number... [21:39] funny, it goes backwards: [21:39] $ echo <(echo one) <(echo two) <(echo three) [21:39] /dev/fd/63 /dev/fd/62 /dev/fd/61 [21:40] yeah hehe [21:40] is a test or func perhaps skipped in debian, but not here? [21:40] like a previous test? [21:40] if you read /proc/self/fd from that script you will see 63 and 62 there [21:41] no, it runs there: check_gold tests/gold-exit-process-sub matches tests/input-1.txt /dev/fd/63 --cols=80 [21:42] I don't understand autopkgtests well enough to understand why those pipes are there... [21:49] can you reproduce it with a local autopkgtest run? And what about just running the script, outsife of autopkgtest? [21:50] it's reproducible with local autopkgtest. Running the same command manually works [21:55] danilogondolfo: autopkgtest keeps some pipes open [21:56] any test that relies on fd numbering needs to be fired into the sun [21:56] agree :D [22:01] ah yes i have had fun with this before https://sourceware.org/bugzilla/show_bug.cgi?id=28260 [22:01] -ubottu:#ubuntu-devel- sourceware.org bug 28260 in glibc "io/tst-closefrom, misc/tst-close_range, posix/tst-spawn5 fail if stray fds are open" [Normal, Resolved: Fixed] [22:01] tbh i think a hint with badtest is appropriate here [22:06] mwhudson, in this case it's a bunch of tests called from a single autopkgtest, a hint would apply to all of them I guess? [22:06] yes [22:06] the hint is at the source package level [22:07] would that still be a good idea? [22:08] it's not great but it's still ok as far as i see, it should be tied to the current version of icdiff [22:08] but it's a release team member (which i am not) who has to decide [22:14] if you file an MP about that, please also include a statement that you tested that version outside of the autopkgtest env, and that the test passed (IIUC, you did that, right) [22:14] mwhudson, can you run this for me please? https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=icdiff&ppa=danilogondolfo/icdiff&trigger=icdiff/2.0.6-1ubuntu1 [22:14] ahasenack, yes, that works [22:15] You submitted an invalid request: icdiff/2.0.6-1ubuntu1 is not published in PPA danilogondolfo/icdiff lunar [22:15] :') I forgot it takes forever to be published... [22:28] yeah it's a real drag [22:29] samba packages: 15min to build, 45min+ to "publish" [22:35] enr0n: I opened https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2012437 . thanks [22:35] -ubottu:#ubuntu-devel- Launchpad bug 2012437 in systemd (Ubuntu) "Ship a static libsystemd.a" [Undecided, New] [23:02] mwhudson, it's published now [23:51] mwhudson, I saw you clicked, but I forgot to add python-flake8 from proposed, sorry... https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=amd64&package=icdiff&ppa=danilogondolfo/icdiff&trigger=icdiff/2.0.6-1ubuntu1&trigger=python-flake8/5.0.4-4