/srv/irclogs.ubuntu.com/2020/09/16/#ubuntu-devel.txt

=== dreaded_ is now known as dreaded
cpaelzerdoko_: 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
ubottuLaunchpad bug 1889248 in libonig (Ubuntu) "[MIR] mdevctl, jq, libonig" [Undecided,In progress]06:23
cpaelzerLaney: 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/s390x07:13
cpaelzerthe long lists of pacakges that is  combines as trigger seems too long07:13
cpaelzermany of those tried already migrated07:14
cpaelzernot that the test would not be broken - it is - but how does it get to this particular list of triggers?07:14
rbalintLaney, cpaelzer i'm wondering about that, too, somehow the previous upload of glibc had a similarly long list of triggers07:15
cpaelzerin 1895576 (the systemd s390x fail that remains) I tried to chck this a bit07:19
cpaelzersome packages magically (so it seems to me) migrated07:19
cpaelzerand while they are shown as in -release, some tooling considers it not yet - and hence keeps them in this list07:19
cpaelzerwell - all assumptions so far07:19
cpaelzerrbalint: btw the test on s390x really seems still broken07:20
cpaelzerwe need either a fix or a test hint07:20
rbalintcpaelzer, i'm ok with the hint and i've retriggered the tests with cryptsetup and glibc to see if they still help07:24
cpaelzerok 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 it07:25
rbalintcpaelzer, thanks, i'm also working on the next systemd point release but it shows regressions so it will take a few days07:27
cpaelzerrbalint: here for you to +1 and merge https://code.launchpad.net/~paelzer/britney/hints-ubuntu-groovy-systemd-s390x-fails/+merge/39080907:32
rbalintcpaelzer, +1'd07:55
Laneycpaelzer: 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:07
rbalintLaney, 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/arm6408:15
LaneyIt's trying to work out what needs to be grouped together08:24
Laneywhat's the real problem here?08:24
xnoxi have a few armhf tests that are /uknown and claim to have broken pipes and what not.08:27
xnoxare armhf workers up? and is it safe for me to retry armhf failures that affect my uploads?08:27
LaneyI'm retrying those weird ones daily08:28
rbalintLaney, 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 it08:28
Laneybos02's network08:28
rbalintLaney, also it lists systemd/246.4-1ubuntu1 among the triggers while it is already in the release pocket for some time08:31
rbalintLaney, not terrible, but this seems new and makes it harded a bit to read the results08:32
LaneyIt 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
LaneyIf there's actual bugs, feel free to file those of course.08:34
Laney(upstream ideally :p)08:36
xnoxrbalint:  having trigger on something in release is a no-op, no? so more or less, mostly harmless?08:44
LaneyYeah, but "too much" from -proposed could be a problem08:46
LaneyI've retried all those "unknown" tests, and taken the dead nodes out of the rotation08:48
LaneyOh Boston, you used to be so reliable08:49
=== doko_ is now known as doko
cpaelzerxnox: I have seen the "armhf broken pipe tests as well09:07
cpaelzerthanks for bringin it up here09:08
cpaelzerxnox: on which release did you see those?09:08
cpaelzerwell - reading the backlog it seems it might be unrelated to the actual target release09:09
cpaelzerThanks Laney, I'll probably just recheck results somewhen later today then09:09
* Laney weeps09:13
Laneylxc just somehow broke on the worker machine09:13
Laneyubuntu@juju-prod-ues-proposed-migration-machine-12:~$ lxc list09:14
Laneyerror: Unable to decode the configuration: yaml: line 58: did not find expected key09:14
Laneyall commands do this now09:14
cpaelzeroutch09:14
Laneyodd, the yaml got slightly corrupted09:24
Laneyrace condition?09:24
Laneybut st_graber would tell me to stop using the xenial-updates version :-)09:25
xnoxcpaelzer:  groovy.09:46
LaneyTIL that vim's autopkgtests take 6 hours to run09:47
Laneythat is one well exercised editor09:47
xnoxit also tests embedding every single language for plugin bindings, no?09:52
xnoxlike vim-ruby, vim-python, etc/09:52
LaneyI didn't click and look inside :>09:54
parideLaney, 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/183034710:03
ubottuLaunchpad bug 1830347 in probert (Ubuntu) "[MIR] probert as dependency of curtin and subiquity" [Undecided,New]10:03
parideare you the right person to ask? :)10:03
paridethis will also unblock the probert migration10:03
paridehttps://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=fb93501a65eef2e90192d7a16845c6bdee4f99cc <- probert seed inclusion10:07
Laneyparide: yeah, that's from the probert source package which is already in main, I can do that10:11
parideLaney, thanks!10:11
Laneydone10:13
cpaelzerwaveform: hiho, can you tell me something about rpi-eeprom in Debian?10:20
cpaelzerwaveform: it seems to be non-existant - but the changelog of the package has Debian history10:21
waveformcpaelzer, I don't believe it's upstream in debian; we take it directly from raspbian10:22
cpaelzerwaveform: so the changelog I see with Debian release entries is actually from raspbian10:22
waveformcpaelzer, correct10:22
cpaelzerok, now what I see makes sense10:22
cpaelzerthanks waveform10:22
waveformnp :)10:22
cpaelzerand also I see https://github.com/raspberrypi/rpi-eeprom has debian branches10:23
cpaelzerwaveform: wow https://github.com/raspberrypi/rpi-eeprom/blob/debian/buster/debian/changelog moves from 7.11 to 9.0 in two weeks10:24
cpaelzerversion number proliferation ...10:24
cpaelzerwaveform: so to confirm you'll be syncing that avery no and then from there to Ubuntu10:25
cpaelzerso 7.8 in groovy now and (if the version bumps continue) 128.4 somewhen in 21.04 then10:25
cpaelzerwaveform: final question the delta you add, does that make sense to upstream to that project?10:26
cpaelzeror will we carry all of that forever "just for us"10:26
waveformcpaelzer, 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
waveformcpaelzer, let me just refresh my memory on the delta...10:43
waveformcpaelzer, 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
waveformusr/bin/env python - so I'm assuming we should continue patching that to /usr/bin/python310:49
dokowaveform: yes, python must not be called from packages11:00
waveformdoko, 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:03
cjwatsonThe 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 practice11:15
gpiccolihey 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 issues11:59
ubottuLaunchpad bug 1830746 in systemd (Ubuntu Bionic) "memlock setting in systemd (pid 1) too low for containers (bionic)" [High,In progress]11:59
gpiccolicjwatson ^11:59
gpiccoliwe wouldn't even need to mess with PAM stuff, etc11:59
rbalintgpiccoli, SRUs are usually prepared and coordinated by ddstreet12:13
xnoxgpiccoli:  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
gpiccoliok rbalint/xnox, I was considering something a bit more agile just for one fix, in order to resolve our PPA builder stuff12:15
gpiccoliBut certainly I can check with Dan, likely this fix can be merged in his next cycle12:16
xnoxgpiccoli:  to quickly rebuild pid1 that runs on hundreds of millions of machines?12:16
xnoxit's not like we have ability to push out optional updates12:16
xnoxgpiccoli:  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
gpiccolixnox, I understand that the PPA bootstraps a new cloud image when available12:17
gpiccoliSo, getting the fix to systemd is the 1st step..then the image builder will consume that and "soon" PPAs will be using the new systemd12:18
xnoxgpiccoli:  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:19
gpiccolixnox, 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
gpiccoliSo for cryptsetup it's not critical, indeed12:20
xnoxgpiccoli:  this is not a risk free change either.12:21
LaneyLocutusOfBorg: I purged your armhf requests out of the queue, a lot of them duplicated ones I already submitted, see above12:22
gpiccolixnox, what change, systemd's or cryptsetup's?12:29
gpiccoliThe cryptsetup change mimics the build process we've been following forever before August12:29
LocutusOfBorgthanks!12:31
julianktjaalton: seeing graphics corruption on i195 again on the T480s, anything known?14:33
juliankDon't know when it started14:33
juliankbut it's latest groovy14:33
juliankI see a kernel error with i915 trace14:33
juliankSep 16 13:21:48 jak-t480s kernel: workqueue: PF_MEMALLOC task 131(kswapd0) is flushing !WQ_MEM_RECLAIM events_unbound:active_work [i915]14:33
tjaaltonjuliank: what is it like?14:34
julianktjaalton: Red lines, white blocks around typed characters14:34
tjaaltonwhich app?14:35
julianktjaalton: system wide14:35
juliankit worked fine this morning14:35
tjaaltonah, not here14:35
julianki left it alone for an hour to go cycling, then it got the error I suppose and stopped working14:35
juliankI have videos14:36
juliankI'll go reboot and guess it's gone then14:37
juliankPost reboot is good14:39
juliankI shall report a kernel bug for the kernel issue14:39
tjaaltonwhich exact kernel version?14:40
julianktjaalton: Ubuntu 5.8.0-18.19-generic 5.8.414:40
tjaaltonproposed has -1914:41
tjaaltonwhich is also what I'm using14:41
tjaaltonsince it cuts power consumption by 40% or so14:42
julianksweet14:42
juliankI'm docked all the time14:42
juliankIt does not really matter much :D14:42
tjaaltonwell it was a regression14:42
tjaaltonso back to normal now14:42
juliankRebooting into it now14:44
tjaaltonso you use an external monitor then?14:47
tjaaltonif docked14:47
julianktjaalton: I do, but I cross-check on internal monitor :)14:59
juliankIt's docked to ThinkVision P24h-10 via USB, which offers charging, USB hub, and 1440p display15:00
juliankAll via one neat USB-C cable15:00
bdmurrayrbalint: I tested bug 1891657 some more and as I mention in comment #17 I think it is a systemd issue15:03
ubottubug 1891657 in apport (Ubuntu Groovy) "systemd 100% cpu usage apport-autoreport.service: Failed with result 'start-limit-hit'" [Undecided,Confirmed] https://launchpad.net/bugs/189165715:03
rbalintbdmurray, thanks, getting to that shortly15:04
tjaaltonjuliank: yeah, but having both is probably what triggers your bugs15:09
=== ijohnson is now known as ijohnson|lunch
=== mitya57_ is now known as mitya57
arnatiousarnatious18:01
arnatious^ ignore that command got stripped18:02
=== ijohnson|lunch is now known as ijohnson
wbncould I bug someone to rebuild this package from `tags/2.26`? https://packages.ubuntu.com/focal/libpam-yubico19:04
wbn(ah. nevermind... i need to wait for them to cut 2.27)19:05
abyssangelhello21:22
sarnoldwb abyssangel21:27
abyssangelhello sarnold21:28
Unit193BTW, thanks to whoever re-tried limnoria before I could! :)22:52

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