| === JanC_ is now known as JanC | ||
| schopin | rbasak: fyi I'm looking into the libdbd-mysql-perl build failure this morning at doko's request (telling you since you've apparently worked on this with lena?) | 08:18 |
|---|---|---|
| cpaelzer | thanks schopin - doko said that libdbd-mysql-perl is fixed by now | 08:44 |
| schopin | you're welcome :) | 08:51 |
| paride | Hmm I happened to notice that graphical-session.target is never reached on my (jammy) system | 08:55 |
| paride | and looks like none of /usr/lib/systemd/user/graphical-session-pre.target.wants/* get started | 08:56 |
| paride | reproduces on a clean jammy install | 08:57 |
| paride | I think graphical-session should be reached, systemd.special(7) says "This target is active whenever any graphical session is running. " | 08:58 |
| paride | while for me `systemctl --user is-active graphical-session.target` returns `inactive` | 08:58 |
| ogayot | same here on impish | 08:59 |
| paride | thanks for checking | 08:59 |
| paride | I'm going to file a bug against gnome-session | 09:03 |
| paride | hmm https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1743366 may be related | 09:05 |
| ubottu | Launchpad bug 1743366 in gnome-session (Ubuntu) "Systemd .path units are not working properly in Bionic" [High, Confirmed] | 09:05 |
| paride | I'll follow-up to that onw | 09:12 |
| paride | done, I hope it makes sense :-) | 09:35 |
| cpaelzer | slyon: for the potentially flaky systemd test it seems confirmed to me | 10:38 |
| cpaelzer | slyon: last time it was upstream-1 that failed | 10:38 |
| cpaelzer | slyon: now on retry it is upstream-2 and the other one was fine | 10:38 |
| cpaelzer | TEST-55-OOMD on upstream-2 and TEST-29-PORTABLE on upstream-1 | 10:39 |
| cpaelzer | since they both worked, but not in the same run I think this indeed is flaky :-/ | 10:39 |
| slyon | cpaelzer: 55-OOMD is a new test that was just enabled in the last upload. It works most of the time, but also there have been several improvements to it in the systemd 250 development cycle, so that should get better in the future | 10:40 |
| slyon | 29-PORTABLE has been flaky for a long time and I wonder if we should put it on the denylist | 10:40 |
| cpaelzer | yeah, for now this post was just an FYI that I think I need to keep retrying | 10:40 |
| cpaelzer | and for you to let me know if anything comes up indicating otherwise | 10:41 |
| cpaelzer | I'm a fan of the denylist in that case as restarting systemd tests as you know isn't done in 2 minutes :-) | 10:41 |
| slyon | cpaelzer: unfortunately, retrying is the way forward for now. But I might indeed put 29-PORTABLE on the denylist, I will be doing some more research before that, tho. IIRC there has been a upstream report about it, too. | 10:43 |
| bluca | do you have kernel 5.15? | 10:44 |
| bluca | when running 29-portable | 10:44 |
| bluca | because if so, it should not fail | 10:44 |
| bluca | same for TEST-50-DISSECT | 10:44 |
| cpaelzer | bluca: 5.15.0-18 | 10:45 |
| bluca | the issues there were always due to undeterministic uevents when using loop devices, but that should be fixed on kernel 5.15 plus a patch | 10:45 |
| bluca | oh wait you are on 249, let me quickly check | 10:45 |
| bluca | never mind, on our side it needs a fix in v250 to use the new diskseq stuff | 10:46 |
| cpaelzer | so TEST-29 also will get better with 250 eventually | 10:47 |
| bluca | if you denylist it, please un-list it after updating to v250 - I really need to know if it still doesn't work with kernel 5.15 + systemd v250 | 10:47 |
| cpaelzer | and for now it is retry-mania | 10:47 |
| cpaelzer | slyon: up to you if that will go to denylist as well as long as we stick to 249 | 10:47 |
| bluca | if you denylist that one, you'll want to do the same for test-50-dissect | 10:47 |
| bluca | it has the same issues | 10:47 |
| slyon | bluca: thanks! That's good to know. If I denylist it, I'll add a comment to revert after v250. or maybe we just leave it the way it is for this cycle (as we had last cycle) | 10:47 |
| bluca | cool - and please do let me know if it's still borken afterwards | 10:48 |
| bluca | tangentially related, there's a couple of fixes I'd like to be there for jammy, when is the latest a new 249.x could be tagged that you'd be able to pick up? | 10:49 |
| cpaelzer | slyon: since systemd-autopkgtest-retrying is a continuous reasons to complain I'm sure you'll get some ubuntu-social-credit by eliminating flaky ones | 10:49 |
| cpaelzer | slyon: and since it is an LTS the not happening curses on you will be worth a decade or so :-) | 10:50 |
| slyon | bluca: Ubuntu's feature freeze is on the 24th, so I guess I could pick up a new 249.10 if it is still tagged this week | 10:51 |
| slyon | cpaelzer: ack | 10:52 |
| slyon | juliank: is there any way to get access to the logs of sudo's autopkgtest on the infrastructure? It passes just fine locally in LXD and qemu (`qemu --ram-size=1592 --cpus=1`) in just 3-4 minutes, while it takes several hours on autopkgtest.u.c and is restarted eventually | 10:54 |
| juliank | slyon: which architecture? | 10:55 |
| slyon | any (except armhf/i386) | 10:55 |
| juliank | sudo: ldap_sasl_bind_s(): Can't contact LDAP server | 10:56 |
| juliank | sudo: no valid sudoers sources found, quitting | 10:56 |
| juliank | sudo: error initializing audit plugin sudoers_audit | 10:56 |
| juliank | Could that be the reason they fail? | 10:56 |
| juliank | autopkgtest will need sudo to do its work I think, as it logs in as ubuntu and then sudos to become root | 10:57 |
| slyon | juliank: potentially... One of the tests removes the 'sudo' package, to install 'sudo-ldap'. So that could be the reason? But why would it work locally? | 10:58 |
| juliank | who knows! | 10:58 |
| juliank | slyon: I think qemu VMs are not comparable, they don't use ssh to login as ubuntu and then sudo | 11:00 |
| juliank | but not sure | 11:00 |
| juliank | I think they use serial console? | 11:01 |
| juliank | so hard to figure that out | 11:01 |
| slyon | juliank: alright, thanks! I think I can build a reproducer for that by using the ssh runner locally. And then potentially disable that one test which is removing the sudo package | 11:01 |
| juliank | slyon: I'd rather get the regression fixed rather than the test disabled tbh | 11:03 |
| juliank | slyon: or did it just not have tests before? | 11:03 |
| slyon | it's not really a regression as we didn't have sudo tests before | 11:03 |
| juliank | ah ok | 11:03 |
| slyon | I can keep it on armhf as it works in LXD containers on autopkgtest.u.c | 11:04 |
| juliank | slyon: maybe it's also trying to use http_proxy? | 11:05 |
| juliank | does ldap go over http? | 11:05 |
| slyon | juliank: I don't know. but that's certainly worth a try. I can easily check that locally | 11:05 |
| slyon | but well.. then it would be failing on armhf/LXD as well I guess | 11:06 |
| juliank | hmm | 11:06 |
| juliank | I guess so | 11:06 |
| juliank | it's unclear why it works in containers and VMs but not on "real machines" | 11:07 |
| juliank | (real machines are VMs too but you get the idea) | 11:07 |
| juliank | well container I guess works because it just runs via lxd directly as root instead of using sudo | 11:08 |
| slyon | juliank: is uses the "needs-root" restriction. So I think your explanation from above makes sense. It tries to SSH into that VM and "sudo" to become root. but sudo is not installed anymore | 11:08 |
| juliank | But shouldn't sudo-ldap only *add* LDAP support, and keep existing sudoers working? | 11:09 |
| slyon | right.. | 11:10 |
| waveform | ginggs, I've updated LP: #1959054 with the list of packages that'll need a no-change rebuild after the debhelper fix lands (which is LP: #1960248) to regenerate their maintscripts correctly | 12:10 |
| ubottu | Launchpad bug 1959054 in libvirt (Ubuntu Jammy) "debhelper restarts services marked --no-restart-on-upgrade" [Undecided, Triaged] https://launchpad.net/bugs/1959054 | 12:10 |
| ubottu | Launchpad bug 1960248 in debhelper (Ubuntu) "Please merge debhelper 13.6 from Debian unstable." [Undecided, New] https://launchpad.net/bugs/1960248 | 12:10 |
| cpaelzer | waveform: did I miss anything landing already ? | 12:12 |
| cpaelzer | waveform: as I need to undo my mitigation then ... | 12:12 |
| ginggs | waveform: ack. so i take it we need the debhelper merge first? | 12:13 |
| waveform | cpaelzer, no -- the fix has been merged upstream in Debian (not sure if a release has been done there yet though -- https://salsa.debian.org/debian/debhelper/-/merge_requests/61) and I incorporated the fix into the merge of debhelper the other day | 12:13 |
| ubottu | Merge 61 in debian/debhelper "Fix #994204 (restarting of services marked --no-stop-on-upgrade)" [Merged] | 12:13 |
| waveform | ginggs, that's correct | 12:13 |
| cpaelzer | ok, please give me a ping once it is in jammy-propoed | 12:14 |
| waveform | cpaelzer, okay | 12:14 |
| ahasenack | morning | 12:14 |
| bluca | schopin: w.r.t. https://bugs.launchpad.net/ubuntu/+bug/1959901 FYI the package made it past NEW in Debian, so it's in experimental, which means it should be easily syncable to jammy | 12:18 |
| ubottu | Launchpad bug 1959901 in Ubuntu "[needs-packaging] tpm2-openssl" [Wishlist, New] | 12:18 |
| ginggs | waveform: i'll look at the debhelper merge now | 12:25 |
| waveform | ginggs, excellent - thanks! It's a fairly simple one, and there's a git-ubuntu style split of the diff in the linked repo which may help with any review | 12:26 |
| ahasenack | cpaelzer: do you have 5min to talk about nfs-utils and libnfsidmap-regex? | 12:35 |
| cpaelzer | yes ahasenack | 12:50 |
| cpaelzer | you can find me in the HO call | 12:51 |
| cpaelzer | for standup | 12:51 |
| ahasenack | going | 12:55 |
| rbasak | utkarsh2102: just spent the last hour tracking down an understanding of what is holding up cmark-gfm. Then, just a few minutes ago, it migrated. | 13:11 |
| utkarsh2102 | rbasak: hahahaha, really? Wow! | 13:12 |
| rbasak | I only got as far as deciding that maybe haskell-cmark-gfm needed a no change rebuild to pick up the new soname. | 13:12 |
| rbasak | But you'd already done that ages ago. | 13:13 |
| rbasak | So I was a bit confused by that, but apparently britney noticed my confusion and just JFDI? | 13:13 |
| utkarsh2102 | rbasak: that's weirdly interesting | 13:14 |
| utkarsh2102 | but yay, that's good! | 13:14 |
| ahasenack | rbasak: think about all the haskell you learned in that hour! :) | 13:45 |
| xypron | Where are debian/control fields like XSBC-Original-Maintainer defined? Can't find it in https://wiki.ubuntu.com. | 13:49 |
| ahasenack | xypron: maybe https://wiki.ubuntu.com/DebianMaintainerField | 13:50 |
| ahasenack | I got pointed at that via the update-maintainer(1) manpage | 13:50 |
| xypron | ahasenack: thanks | 13:55 |
| ahasenack | cpaelzer: I will still have to ask for a package removal anyway: src:libnfsidmap (not the regex one) | 14:05 |
| ahasenack | does this change our recent evaluation? "if you are going to remove one, you can remove two"? | 14:05 |
| ahasenack | fun | 14:06 |
| cpaelzer | no, I'd still stick to the choices we made | 14:18 |
| cpaelzer | ahasenack: after all it seems at least for libnfsidmap upstream and debian have already concluded on the way to go | 14:18 |
| ahasenack | yes, there isn't really another option for libnfsidmap, it's in nfs-utils since 2017 | 14:19 |
| ahasenack | ok | 14:19 |
| rbasak | Who had that autopkgtest trigger generator script thing? | 14:20 |
| rbasak | I want to retry according to https://wiki.ubuntu.com/ProposedMigration/#How_to_re-run_autopkgtests_with_dependencies_on_other_packages_in_the_proposed_pocket but IIRC someone had some automation for that? | 14:20 |
| ahasenack | repo ubuntu-helpers? | 14:21 |
| ahasenack | ah, that's archive tools | 14:21 |
| rbasak | I'm looking in there but don't see it | 14:21 |
| rbasak | Ah | 14:21 |
| ahasenack | git://git.launchpad.net/ubuntu-archive-tools | 14:21 |
| ahasenack | rbasak: ^ | 14:21 |
| ahasenack | retry-autopkgtest-regressions rught>? | 14:21 |
| ahasenack | wow, can't type | 14:21 |
| ahasenack | retry-autopkgtest-regressions right? | 14:21 |
| rbasak | That looks like it. Thanks! | 14:21 |
| ahasenack | I liked the log regexp filter, quite handy | 14:22 |
| rbasak | I don't see how to use this to generate the list of "triggers" given I know the list of source packages to use against proposed | 14:24 |
| rbasak | For a single source/arch that I want retried | 14:24 |
| ahasenack | it outputs the urls, you have to wget/curl them iirc | 14:25 |
| ahasenack | via this beautiful command line: ` - retry-autopkgtest-regressions [opts...] | vipe | xargs -rn1 -P10 wget --load-cookies ~/.cache/autopkgtest.cookie -O- | 14:25 |
| ahasenack | ` | 14:25 |
| ahasenack | but maybe it doesn't have triggers, hmm | 14:26 |
| ahasenack | that could have been cpaelzer's script | 14:26 |
| rbasak | Yeah that's what I'm asking | 14:26 |
| rbasak | Is lp-test-ppa just for PPAs? | 14:27 |
| ahasenack | so close | 14:28 |
| rbasak | Let's see what kind of one-liner I can knock up | 14:28 |
| rbasak | I came up with https://pastebin.ubuntu.com/p/rryFWTmYsh/ | 14:53 |
| rbasak | I'll stick that in ubuntu-helpers unless someone tells me there's some thing that already existed that I was missing | 14:54 |
| alexghiti | Hi guys, I have just sent my +1 report to ubuntu-devel mailing list, but it is being held waiting for a moderator approval, can someone moderate it? Thanks! | 15:10 |
| rbasak | Done | 15:10 |
| alexghiti | Thanks again :) | 15:30 |
| schopin | bluca: thanks! I've been a bit swamped, this should make things much easier! | 15:43 |
| bdmurray | rbasak: What is ubuntu-helpers? | 15:46 |
| bluca | np | 15:51 |
| rbasak | bdmurray: the server team have been collecting their personal scripts/hacks in one place. | 15:55 |
| rbasak | bdmurray: https://git.launchpad.net/~ubuntu-server/ubuntu-helpers/ (but the URL is wrong and I intend to move the repo at some point) | 15:55 |
| rbasak | The idea is that there's no code review here, so that there's a low barrier to sharing | 15:55 |
| === genii-core is now known as genii | ||
| xypron | pillow 9.0.0-1ubuntu1 is available for sponsoring to solve LP #1960263 | 16:13 |
| ubottu | Launchpad bug 1960263 in pillow (Ubuntu Jammy) "python-pil-doc fails to build in jammy" [High, New] https://launchpad.net/bugs/1960263 | 16:13 |
| seb128 | xypron, you got a review from jbicha on the bug, the fix is suboptimal, a package shouldn't build-depends on some of its own binaries | 16:51 |
| dima5 | Hi. Do a package have to build successfully for ALL the architectures to be included in jammy? I'm working on this: https://launchpad.net/ubuntu/+source/mrcal/ | 19:44 |
| ahasenack | yes, except for riscv64 iirc | 19:46 |
| dima5 | 2.1-4 built on all except arm64, but launchpad says it's in the "release" bucket, so maybe it's in already? I then fixed the bug and uploaded 2.1-5. Now it fails on ppc64el (with no log or indication about why not), and the bucket is "proposed" | 19:46 |
| ahasenack | yeah, ppc64el is required | 19:46 |
| dima5 | But is arm64? | 19:46 |
| ahasenack | 2.1-5 failed ppc64el | 19:46 |
| dima5 | Did 2.1-4 get in despite that built failure? | 19:46 |
| ahasenack | oh, 2.1-4 failed arm64 as you say | 19:47 |
| dima5 | That arm64 failure was a real bug that I fixed in 2.1-5. I can work on ppc64el, but there's no build log: | 19:47 |
| dima5 | https://launchpad.net/ubuntu/+source/mrcal/2.1-5/+build/23164631 | 19:47 |
| ahasenack | that's not what I would expect, but indeed, it's not published for arm64 in jammy release | 19:47 |
| ahasenack | bummer for the build log | 19:48 |
| ahasenack | let me ask in release | 19:48 |
| dima5 | Thanks | 19:48 |
| dima5 | Should I be asking these questions in another channel? | 19:48 |
| dima5 | And FWIW, this builds on all the arches in Debian/unstable | 19:49 |
| ahasenack | no, it's fine | 19:49 |
| ahasenack | @dima5: I just retried the build, keep an eye on https://launchpad.net/ubuntu/+source/mrcal/2.1-5/+build/23164631 please | 19:50 |
| dima5 | Looks like it succeeded this time. Are we thinking there's some rare bug in the build scripts that I hit? | 19:55 |
| cjwatson | Infrastructure issue probably. There was a backend timeout sending files to the build worker | 19:57 |
| cjwatson | Well, timeout or ... something. It's one of our less informative log messages | 19:58 |
| cjwatson | 2022-02-14 11:20:14+0000 [QueryProtocol,client] Scanning bos02-ppc64el-025 failed with: FirstError[#2, [Failure instance: Traceback: <class 'twisted.internet.error.ConnectionDone'>: Connection was c | 19:58 |
| cjwatson | losed cleanly. | 19:58 |
| cjwatson | (thanks, Twisted) | 19:58 |
| dima5 | odd | 19:58 |
| dima5 | OK. In any case, it looks like I have packages on all the arches now, so this package should be in the release unambiguously. Thanks much, everybody! | 19:58 |
| cjwatson | Should be a 150-second timeout there but it timed out after 86 seconds, so I'm not quite sure | 20:02 |
| cjwatson | s/timed out/failed/ | 20:02 |
| cjwatson | Also I'm really not sure why ConnectionDone is showing up as a failure so we may need to dig. But not now, I need to go and do evening stuff | 20:03 |
| Eickmeyer | xnox: We actually have been given a courtesy certification via Mark that we jus thaven't taken care of due to ongoing cost/benefit analyses. It was recommended to us to use the oem kernel per tjaalton due to some framebuffer issues we were having roughly a year ago on the stock kernel. | 21:38 |
| Eickmeyer | In fact, we did over 120 hours of testing to submit the framebuffer patch to fix that issue. | 21:40 |
| Eickmeyer | We assembled, tested, and submitted the patch. | 21:40 |
| Eickmeyer | So, like it or not, it's a thing. | 21:40 |
| Eickmeyer | At least we're working as part of the community, which is better than a lot of OEMs can say. | 21:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!