danilogondolfomwhudson, 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-400:37
mwhudsondanilogondolfo: done00:38
danilogondolfothank you!00:38
=== cpaelzer_ is now known as cpaelzer
=== JanC_ is now known as JanC
adrienhi, 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 version10:45
adrienthere's a fix for the issue and a work-around for its consequences10:45
adrienbut since it only happens on package update, there is no need to apply this unless you're already updating the package10:46
adrienis it possible to stage an SRU possibly forever?10:46
slyonkanashiro[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
slyonDo we really need/want to support this usecase?10:47
adrienthe need is only to have the fixed version before other changes (e.g. security) but there is no requirement of a specific date10:47
slyonwrt. https://bugs.launchpad.net/ubuntu/+source/libtraceevent/+bug/200971510:47
-ubottu:#ubuntu-devel- Launchpad bug 2009715 in libtraceevent (Ubuntu) "[MIR] Promote libtraceevent as a dependency of libtracefs" [Undecided, New]10:47
rbasaksergiodj: o/ I'll take back the mosh MIR work10:48
danilogondolfoAnybody 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/43929412:02
seb128danilogondolfo, hey, thanks for the fix, merged now12:21
danilogondolfothanks, seb12812:21
seb128danilogondolfo, I'm going to upload as well12:22
kanashiro[m]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?12:25
slyonkanashiro[m]: Thanks for your answer!13:02
slyonI've marked the MIR a NACK/WONTFIX for now: https://bugs.launchpad.net/ubuntu/+source/libtraceevent/+bug/200971513:02
-ubottu:#ubuntu-devel- Launchpad bug 2009715 in libtraceevent (Ubuntu) "[MIR] Promote libtraceevent as a dependency of libtracefs" [Undecided, Incomplete]13:02
slyonwill upload my debdiff13:02
kanashiro[m]slyon: thank you13:06
sergiodjrbasak: ACK, thanks14:41
bdmurrayadrien: there is a block-proposed-$stablerelease tag that does this see https://ubuntu-archive-team.ubuntu.com/pending-sru.html for examples15:36
adrienbdmurray: thanks! I wasn't expecting so many updates to be blocked that long but that's good for my needs :)15:40
rbasakIn an autopkgtest environment I see that $HOME isn't set.15:42
rbasakBut things like ssh will look in ~/.ssh etc, and I'd like to find out where that is.15:42
rbasakWhat's the appropriate way?15:42
rbasakMaybe: getent passwd `whoami`|cut -d: -f615:42
rbasakOr is there a better approach?15:42
hallynhm, this seems like pooor form - i can't build the systemd *source* package on jammy (even with -d)?  that's very unfortunate...15:52
adrienI 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 match15:55
adrienfor 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?15:57
=== sem2peie- is now known as sem2peie
enr0nhallyn: 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 similar17:09
enr0nOr I can just stage the change for you if you don't feel like messing around with it17:10
adrienI'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:26
enr0nadrien: 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:37
adrienright, thanks; and I think I need to do more packaging changes than I had hoped for :/17:42
hallynenr0n: yeah, i built it in a container then copied it over to debsign it.17:50
hallynlooks 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)17:51
adrienthanks for git-ubuntu; that took only a couple minutes to do actually (most of the time being spent checking d/changelog)19:22
ahasenackwho is on +1 maintenance this week?21:15
ahasenackif I could suggest a package21:15
ahasenackpython-flake8 curently broke in lunar due to pycodestyle just having migrated21:16
ahasenackwe need python-flake8 that is in lunar-proposed21:16
ahasenackwhich is apparently blocked in icdiff: https://autopkgtest.ubuntu.com/packages/i/icdiff/lunar/s390x21:17
ahasenackicdiff passed in debian: https://ci.debian.net/packages/i/icdiff/21:17
enr0nahasenack: I believe danilogondolfo is on +1 and is currently looking at icdiff21:31
danilogondolfoahasenack, hi there, yeah I already spent a few hours looking at python-flake8 and icdiff today21:33
danilogondolfoI have a dirty fix for icdiff, well I will drop the problem here...21:34
danilogondolfoso, one of icdiff tests will use process substitution to read a file and expects getting the file descriptor 63 to succeed :P21:34
danilogondolfothis would be the first fd provided by bash when using process substitution21:35
danilogondolfoalthough, 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 test21:35
ahasenackyeah, I saw the diff in that test failure, 61 vs 63 was the only difference I could spot21:35
danilogondolfoclosing these fds when the script starts fix the test21:36
danilogondolfobut it seems dirty and I'm not sure if it's ok21:36
ahasenackin debian it's not happening for some reason21:37
ahasenackthe package is a sync, right?21:37
ahasenackI forgot21:37
danilogondolfoapparently it passes on Debian, but fails for me when I try...21:37
danilogondolfoahasenack, https://pastebin.ubuntu.com/p/DYzndVDmjt/21:37
ahasenackso it passed in debian back then21:38
danilogondolfoas I said, dirty...21:38
danilogondolfoanother solution would be changing the test to not rely on the fd number...21:39
ahasenackfunny, it goes backwards:21:39
ahasenack$ echo <(echo one) <(echo two) <(echo three)21:39
ahasenack /dev/fd/63 /dev/fd/62 /dev/fd/6121:39
danilogondolfoyeah hehe21:40
ahasenackis a test or func perhaps skipped in debian, but not here?21:40
ahasenacklike a previous test?21:40
danilogondolfoif you read /proc/self/fd from that script you will see 63 and 62 there21:40
danilogondolfono, it runs there:     check_gold tests/gold-exit-process-sub matches tests/input-1.txt /dev/fd/63 --cols=8021:41
danilogondolfoI don't understand autopkgtests well enough to understand why those pipes are there...21:42
ahasenackcan you reproduce it with a local autopkgtest run? And what about just running the script, outsife of autopkgtest?21:49
danilogondolfoit's reproducible with local autopkgtest. Running the same command manually works21:50
mwhudsondanilogondolfo: autopkgtest keeps some pipes open21:55
mwhudsonany test that relies on fd numbering needs to be fired into the sun21:56
danilogondolfoagree :D21:56
mwhudsonah yes i have had fun with this before https://sourceware.org/bugzilla/show_bug.cgi?id=2826022: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
mwhudsontbh i think a hint with badtest is appropriate here22:01
danilogondolfomwhudson, 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
mwhudsonthe hint is at the source package level22:06
danilogondolfowould that still be a good idea?22:07
mwhudsonit's not great but it's still ok as far as i see, it should be tied to the current version of icdiff22:08
mwhudsonbut it's a release team member (which i am not) who has to decide22:08
ahasenackif 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
danilogondolfomwhudson, 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-1ubuntu122:14
danilogondolfoahasenack, yes, that works22:14
mwhudsonYou submitted an invalid request: icdiff/2.0.6-1ubuntu1 is not published in PPA danilogondolfo/icdiff lunar22:15
danilogondolfo:') I forgot it takes forever to be published...22:15
mwhudsonyeah it's a real drag22:28
ahasenacksamba packages: 15min to build, 45min+ to "publish"22:29
hallynenr0n: I opened https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2012437 .  thanks22:35
-ubottu:#ubuntu-devel- Launchpad bug 2012437 in systemd (Ubuntu) "Ship a static libsystemd.a" [Undecided, New]22:35
danilogondolfomwhudson, it's published now23:02
danilogondolfomwhudson, 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-423:51

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!