=== dreaded_ is now known as dreaded
[06:23] <cpaelzer> doko_: hi, an update on one of the tasks by security reminded my of https://bugs.launchpad.net/ubuntu/+source/mdevctl/+bug/1889248 - I wanted to ping to check if this is still on your todo list?
[06:23] <ubottu> Launchpad bug 1889248 in libonig (Ubuntu) "[MIR] mdevctl, jq, libonig" [Undecided,In progress]
[07:13] <cpaelzer> Laney: do you happen to now which tool/automation submits the retests that you can e.g. see in https://autopkgtest.ubuntu.com/packages/s/systemd/groovy/s390x
[07:13] <cpaelzer> the long lists of pacakges that is  combines as trigger seems too long
[07:14] <cpaelzer> many of those tried already migrated
[07:14] <cpaelzer> not that the test would not be broken - it is - but how does it get to this particular list of triggers?
[07:15] <rbalint> Laney, cpaelzer i'm wondering about that, too, somehow the previous upload of glibc had a similarly long list of triggers
[07:19] <cpaelzer> in 1895576 (the systemd s390x fail that remains) I tried to chck this a bit
[07:19] <cpaelzer> some packages magically (so it seems to me) migrated
[07:19] <cpaelzer> and while they are shown as in -release, some tooling considers it not yet - and hence keeps them in this list
[07:19] <cpaelzer> well - all assumptions so far
[07:20] <cpaelzer> rbalint: btw the test on s390x really seems still broken
[07:20] <cpaelzer> we need either a fix or a test hint
[07:24] <rbalint> cpaelzer, i'm ok with the hint and i've retriggered the tests with cryptsetup and glibc to see if they still help
[07:25] <cpaelzer> ok rbalint, given you are the maintainer and you agree I think I'll prep a hint and once you ack there (for an audit trail) we can push it
[07:27] <rbalint> cpaelzer, thanks, i'm also working on the next systemd point release but it shows regressions so it will take a few days
[07:32] <cpaelzer> rbalint: here for you to +1 and merge https://code.launchpad.net/~paelzer/britney/hints-ubuntu-groovy-systemd-s390x-fails/+merge/390809
[07:55] <rbalint> cpaelzer, +1'd
[08:07] <Laney> cpaelzer: rbalint: Probably from proposed-migration itself. The code to do that is in the autopkgtest policy there, if you want to read it and see exactly what it does. But unless you know of an actual problem... ;)
[08:15] <rbalint> Laney, what i'm observing is that the glibc upload generated a long list of triggers, while i coud just use glibc/2.32-0ubuntu2, like in https://autopkgtest.ubuntu.com/packages/a/assimp/groovy/arm64
[08:24] <Laney> It's trying to work out what needs to be grouped together
[08:24] <Laney> what's the real problem here?
[08:27] <xnox> i have a few armhf tests that are /uknown and claim to have broken pipes and what not.
[08:27] <xnox> are armhf workers up? and is it safe for me to retry armhf failures that affect my uploads?
[08:28] <Laney> I'm retrying those weird ones daily
[08:28] <rbalint> Laney, the triggers may pull in more packages than needed, for example in last run of https://autopkgtest.ubuntu.com/packages/g/gst-omx/groovy/amd64 libglib is pulled from proposed while i believe glibc could migrate without it
[08:28] <Laney> bos02's network
[08:31] <rbalint> Laney, also it lists systemd/246.4-1ubuntu1 among the triggers while it is already in the release pocket for some time
[08:32] <rbalint> Laney, not terrible, but this seems new and makes it harded a bit to read the results
[08:34] <Laney> It is new(ish), but new isn't always bad. Previously we had many more packages which fell back to using all-proposed. It's right for proposed-migration to try to work out the groups and trigger those together.
[08:34] <Laney> If there's actual bugs, feel free to file those of course.
[08:36] <Laney> (upstream ideally :p)
[08:44] <xnox> rbalint:  having trigger on something in release is a no-op, no? so more or less, mostly harmless?
[08:46] <Laney> Yeah, but "too much" from -proposed could be a problem
[08:48] <Laney> I've retried all those "unknown" tests, and taken the dead nodes out of the rotation
[08:49] <Laney> Oh Boston, you used to be so reliable
=== doko_ is now known as doko
[09:07] <cpaelzer> xnox: I have seen the "armhf broken pipe tests as well
[09:08] <cpaelzer> thanks for bringin it up here
[09:08] <cpaelzer> xnox: on which release did you see those?
[09:09] <cpaelzer> well - reading the backlog it seems it might be unrelated to the actual target release
[09:09] <cpaelzer> Thanks Laney, I'll probably just recheck results somewhen later today then
[09:13]  * Laney weeps
[09:13] <Laney> lxc just somehow broke on the worker machine
[09:14] <Laney> ubuntu@juju-prod-ues-proposed-migration-machine-12:~$ lxc list
[09:14] <Laney> error: Unable to decode the configuration: yaml: line 58: did not find expected key
[09:14] <Laney> all commands do this now
[09:14] <cpaelzer> outch
[09:24] <Laney> odd, the yaml got slightly corrupted
[09:24] <Laney> race condition?
[09:25] <Laney> but st_graber would tell me to stop using the xenial-updates version :-)
[09:46] <xnox> cpaelzer:  groovy.
[09:47] <Laney> TIL that vim's autopkgtests take 6 hours to run
[09:47] <Laney> that is one well exercised editor
[09:52] <xnox> it also tests embedding every single language for plugin bindings, no?
[09:52] <xnox> like vim-ruby, vim-python, etc/
[09:54] <Laney> I didn't click and look inside :>
[10:03] <paride> Laney, hi! I think probert-network should be included in main, as it's a direct dependency of probert, which is now seeded. See https://people.canonical.com/~ubuntu-archive/component-mismatches.html and https://bugs.launchpad.net/ubuntu/+source/probert/+bug/1830347
[10:03] <ubottu> Launchpad bug 1830347 in probert (Ubuntu) "[MIR] probert as dependency of curtin and subiquity" [Undecided,New]
[10:03] <paride> are you the right person to ask? :)
[10:03] <paride> this will also unblock the probert migration
[10:07] <paride> https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=fb93501a65eef2e90192d7a16845c6bdee4f99cc <- probert seed inclusion
[10:11] <Laney> paride: yeah, that's from the probert source package which is already in main, I can do that
[10:11] <paride> Laney, thanks!
[10:13] <Laney> done
[10:20] <cpaelzer> waveform: hiho, can you tell me something about rpi-eeprom in Debian?
[10:21] <cpaelzer> waveform: it seems to be non-existant - but the changelog of the package has Debian history
[10:22] <waveform> cpaelzer, I don't believe it's upstream in debian; we take it directly from raspbian
[10:22] <cpaelzer> waveform: so the changelog I see with Debian release entries is actually from raspbian
[10:22] <waveform> cpaelzer, correct
[10:22] <cpaelzer> ok, now what I see makes sense
[10:22] <cpaelzer> thanks waveform
[10:22] <waveform> np :)
[10:23] <cpaelzer> and also I see https://github.com/raspberrypi/rpi-eeprom has debian branches
[10:24] <cpaelzer> waveform: wow https://github.com/raspberrypi/rpi-eeprom/blob/debian/buster/debian/changelog moves from 7.11 to 9.0 in two weeks
[10:24] <cpaelzer> version number proliferation ...
[10:25] <cpaelzer> waveform: so to confirm you'll be syncing that avery no and then from there to Ubuntu
[10:25] <cpaelzer> so 7.8 in groovy now and (if the version bumps continue) 128.4 somewhen in 21.04 then
[10:26] <cpaelzer> waveform: final question the delta you add, does that make sense to upstream to that project?
[10:26] <cpaelzer> or will we carry all of that forever "just for us"
[10:43] <waveform> cpaelzer, correct - I'll be trying to keep up with it, but as you noted 9.0's just been released - I figured I'd hold off on that until the MIR was done for some vague stability during that process :)
[10:43] <waveform> cpaelzer, let me just refresh my memory on the delta...
[10:49] <waveform> cpaelzer, the only delta we've got is the python3 patch and there was quite a bit of discussion of that upstream (https://github.com/raspberrypi/rpi-eeprom/issues/43, https://github.com/raspberrypi/rpi-eeprom/issues/94, https://github.com/raspberrypi/rpi-eeprom/pull/199, https://github.com/raspberrypi/rpi-eeprom/pull/203) - the upshot is that they're sticking with their /usr/bin/env shebang but modifying it to /usr/bin/env python3 instead of /
[10:49] <waveform> usr/bin/env python - so I'm assuming we should continue patching that to /usr/bin/python3
[11:00] <doko> waveform: yes, python must not be called from packages
[11:03] <waveform> doko, yes - at the moment (7.8 and 8.0), the shebang they're using is #!/usr/bin/env python - in future (9.0+) they're going to use #!/usr/bin/env python3 - however, despite that calling python3, I'm assuming we don't want the /usr/bin/env portion either (I can't recall the reason /usr/bin/env is considered bad off the top of my head, but I'm reasonably sure there is one :)
[11:15] <cjwatson> The issue with /usr/bin/env is that it means that the package will end up using a stray Python installation from elsewhere on $PATH (e.g. /usr/local/bin) if it exists.  Whether you think that it should be possible for the sysadmin to override the packaged version in this way is to some extent a philosophical question, but it mostly seems to end up being a footgun in practice
[11:59] <gpiccoli> hey xnox, do you think it's possible to get systemd released with the patch in https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746 ? That would fix the PPA memlock issues
[11:59] <ubottu> Launchpad bug 1830746 in systemd (Ubuntu Bionic) "memlock setting in systemd (pid 1) too low for containers (bionic)" [High,In progress]
[11:59] <gpiccoli> cjwatson ^
[11:59] <gpiccoli> we wouldn't even need to mess with PAM stuff, etc
[12:13] <rbalint> gpiccoli, SRUs are usually prepared and coordinated by ddstreet
[12:15] <xnox> gpiccoli:  normally we package systemd out of git tree mentioned in Vcs header. and yeah normally ddstreet uploads bionic srus. do check with him if there is anything in flight or not.
[12:15] <gpiccoli> ok rbalint/xnox, I was considering something a bit more agile just for one fix, in order to resolve our PPA builder stuff
[12:16] <gpiccoli> But certainly I can check with Dan, likely this fix can be merged in his next cycle
[12:16] <xnox> gpiccoli:  to quickly rebuild pid1 that runs on hundreds of millions of machines?
[12:16] <xnox> it's not like we have ability to push out optional updates
[12:17] <xnox> gpiccoli:  merge proposal of the patch alone to https://code.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/+git/systemd/+ref/ubuntu-bionic would be preffered.
[12:17] <gpiccoli> xnox, I understand that the PPA bootstraps a new cloud image when available
[12:18] <gpiccoli> So, getting the fix to systemd is the 1st step..then the image builder will consume that and "soon" PPAs will be using the new systemd
[12:19] <xnox> gpiccoli:  yes lead time on getting this out is 3-5 weeks. but also it's not critical, apart from just the one build that trips it up at the moment?
[12:19] <xnox> (which should just have an upload to ignore that test case for now, or run it as autopkgtest)
[12:20] <gpiccoli> xnox, I antecipated that it'd take some time, so I manage to get another "fix" into the package (the alternative (b) in my email)
[12:20] <gpiccoli> So for cryptsetup it's not critical, indeed
[12:21] <xnox> gpiccoli:  this is not a risk free change either.
[12:22] <Laney> LocutusOfBorg: I purged your armhf requests out of the queue, a lot of them duplicated ones I already submitted, see above
[12:29] <gpiccoli> xnox, what change, systemd's or cryptsetup's?
[12:29] <gpiccoli> The cryptsetup change mimics the build process we've been following forever before August
[12:31] <LocutusOfBorg> thanks!
[14:33] <juliank> tjaalton: seeing graphics corruption on i195 again on the T480s, anything known?
[14:33] <juliank> Don't know when it started
[14:33] <juliank> but it's latest groovy
[14:33] <juliank> I see a kernel error with i915 trace
[14:33] <juliank> Sep 16 13:21:48 jak-t480s kernel: workqueue: PF_MEMALLOC task 131(kswapd0) is flushing !WQ_MEM_RECLAIM events_unbound:active_work [i915]
[14:34] <tjaalton> juliank: what is it like?
[14:34] <juliank> tjaalton: Red lines, white blocks around typed characters
[14:35] <tjaalton> which app?
[14:35] <juliank> tjaalton: system wide
[14:35] <juliank> it worked fine this morning
[14:35] <tjaalton> ah, not here
[14:35] <juliank> i left it alone for an hour to go cycling, then it got the error I suppose and stopped working
[14:36] <juliank> I have videos
[14:37] <juliank> I'll go reboot and guess it's gone then
[14:39] <juliank> Post reboot is good
[14:39] <juliank> I shall report a kernel bug for the kernel issue
[14:40] <tjaalton> which exact kernel version?
[14:40] <juliank> tjaalton: Ubuntu 5.8.0-18.19-generic 5.8.4
[14:41] <tjaalton> proposed has -19
[14:41] <tjaalton> which is also what I'm using
[14:42] <tjaalton> since it cuts power consumption by 40% or so
[14:42] <juliank> sweet
[14:42] <juliank> I'm docked all the time
[14:42] <juliank> It does not really matter much :D
[14:42] <tjaalton> well it was a regression
[14:42] <tjaalton> so back to normal now
[14:44] <juliank> Rebooting into it now
[14:47] <tjaalton> so you use an external monitor then?
[14:47] <tjaalton> if docked
[14:59] <juliank> tjaalton: I do, but I cross-check on internal monitor :)
[15:00] <juliank> It's docked to ThinkVision P24h-10 via USB, which offers charging, USB hub, and 1440p display
[15:00] <juliank> All via one neat USB-C cable
[15:03] <bdmurray> rbalint: I tested bug 1891657 some more and as I mention in comment #17 I think it is a systemd issue
[15:03] <ubottu> bug 1891657 in apport (Ubuntu Groovy) "systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit'" [Undecided,Confirmed] https://launchpad.net/bugs/1891657
[15:04] <rbalint> bdmurray, thanks, getting to that shortly
[15:09] <tjaalton> juliank: yeah, but having both is probably what triggers your bugs
=== ijohnson is now known as ijohnson|lunch
=== mitya57_ is now known as mitya57
[18:01] <arnatious> arnatious
[18:02] <arnatious> ^ ignore that command got stripped
=== ijohnson|lunch is now known as ijohnson
[19:04] <wbn> could I bug someone to rebuild this package from `tags/2.26`? https://packages.ubuntu.com/focal/libpam-yubico
[19:05] <wbn> (ah. nevermind... i need to wait for them to cut 2.27)
[21:22] <abyssangel> hello
[21:27] <sarnold> wb abyssangel
[21:28] <abyssangel> hello sarnold
[22:52] <Unit193> BTW, thanks to whoever re-tried limnoria before I could! :)