[08:38] <sahid> jamespage, coreycb, o/ anychance you provide repo for sqlalchemy-utils, cinder is needing the version 0.31.1?
[09:09] <seb128> vorlon, should http://autopkgtest.ubuntu.com/packages/b/budgie-desktop/focal/i386 be flagged as badtest?
[09:10] <RikMills> tjaalton: ran test against PPA package with all-proposed, and yes that workaround did reduce autotest fails from ~800 to 14
[09:10] <RikMills> still meh though :(
[09:18] <tjaalton> yep
[09:18] <tjaalton> the bad mesa commit is found, but no fix yet
[09:25] <RikMills> tjaalton: this? https://gitlab.freedesktop.org/mesa/mesa/issues/2472
[09:25] <tjaalton> yep
[10:17] <cpaelzer> jamespage: you said you expected masakari could pass without the need for security review
[10:17] <cpaelzer> jamespage: but from my look at it while generally ok and well hadnled I think it needs one
[10:17] <cpaelzer> jamespage: https://git.launchpad.net/~paelzer/+git/MIR/tree/MIR-1815991-masakari-and-masakari-monitors.txt#n37
[10:18] <cpaelzer> would you mind explaining why you tinhk it would not need one before I post my answer to the MIR bug?
[10:19] <jamespage> cpaelzer: mainly because it's patterned to every other openstack service in terms of API
[10:19] <jamespage> that might make it an easy MIR review for the security team
[10:19] <cpaelzer> yeah I agree that is will most likely be a very fast check as it follows the same patterns that were reviewed plenty of times already
[10:20] <cpaelzer> but to have the checker tools run once to be sure I'd still mark it as needs-security now
[10:20] <jamespage> ack - no problem with that approach :)
[10:20] <cpaelzer> thanks jamespage
[10:21] <cpaelzer> jamespage: wit hthat MIR review done, you might satrt to bother seucrity team to get it done in time
[10:21] <cpaelzer> oO characters shift around again :-/
[10:22] <jamespage> I'll ping joe
[10:42] <Laney> tjaalton: ok, so if we hint it, can you track that it gets fixed for the release?
[10:43] <tjaalton> Laney: this one yes, but bisecting mesa test failures on sparc I've noticed that there's always a bunch of big-endian-looking things that have failed at least since 19.0
[10:44] <tjaalton> going further back results in build issues
[10:44] <tjaalton> so I'm just assuming that these tests at least have always been broken on big-endian
[11:30] <jamespage> sahid: doing that noe
[11:33] <jamespage> sahid: er - python-sqlalchemy-utils
[11:34] <jamespage> already exists lp:~ubuntu-server-dev/ubuntu/+source/python-sqlalchemy-utils
[11:34] <jamespage> seems to be up-to-date
[11:34] <jamespage> in distro as well
[11:40] <juliank> Laney: Are we hopeful that mesa will migrate with the hint in place? It depends on libglvnd which is stuck in Valid Candidate phase
[11:40] <juliank> And I can't read update_output.txt to figure out why it's in there, rather than migrating
[11:40] <sahid> jamespage: thanks for the nova merge
[11:40] <sahid> jamespage: hum... sorry about sqlachemy-utils, let me double check
[11:43] <Laney> juliank: Not sure, I didn't look beyond mesa itself atm, let's see
[11:49] <Laney> Looks like it may have something to do with qt / autopilot somehow
[11:49] <sahid> jamespage: ok thanks we still need to bump th version to 0.31.1 I'm doing that and will ping you shortly
[11:59] <Laney> actually it should work: https://paste.ubuntu.com/p/4p4pgV3F2j/
[11:59] <Laney> if it doesn't find that hint by itself we can add it manually
[12:01] <doko> if it's autopilot, then it's the qt4 removal
[12:02] <jamespage> sahid: er its already 0.36.0
[12:08] <juliank> Laney: ack
[12:24] <sahid> jamespage: we want 0.36.*1*
[12:31] <juliank> tjaalton: I'm on proposed kernel now, I did not see it earlier because I was looking at linux source package, and it is in linux-5.4 now
[12:32] <juliank> Should probably remove linux source package from focal?
[12:33] <juliank> Anyway happy to be on 5.4 again
[12:34] <juliank> Being able to go to 95°C instead of 80°C makes stuff compile faster :)
[12:40] <tjaalton> juliank: ah
[12:40] <tjaalton> Laney: did libglvnd move as well?
[12:41] <tjaalton> I assume it did
[12:41] <juliank> Now I just need to get a usable s-tui again
[12:41] <juliank> It started showing information per core, when previously it showed aggregate info
[12:41] <juliank> It's basically useless now
[12:43] <guysoft42>  hey all, I am the creator of CustomPiOS, which lets you build custom distros using a base image. I can see the raspberrypi image of ubuntu is creating the ubuntu user and password on boot, with the password expried. And I want to change that. However, I get: chage: user 'ubuntu' does not exist in /etc/passwd . How do I find someone who knows how this works and how to edit settings for the ubuntu user before creation?
[12:43] <seb128> tjaalton, looks like libglvnd did migrate as well yes
[12:43] <guysoft42> Also it seems like #ubuntu-arm is not responding. And I am not sure who to even ask about this
[12:50] <tjaalton> seb128: right, it was synced so I didn't get an email about it
[13:05] <juliank> guysoft42: lookup cloud-init
[13:05] <juliank> guysoft42: The user is configured on images at first boot by cloud-init, also sets up mirrors and stuff
[13:08] <sahid> jamespage, coreycb, when you have a moment to look at https://code.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/python-sqlalchemy-utils/+git/python-sqlalchemy-utils
[13:08] <cpaelzer> hiho, yesterday I asked why https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.html is updating to slow (seems only at 9pm GMT once a day)
[13:09] <cpaelzer> today I realized the report closes with "Over time" - not sure, it might indicate a timeut of some sort?
[13:09] <guysoft42> juliank, Ok let me have a look, I added wpa-supplicant to my builds so didn't take a long glance there.
[13:17] <cjwatson> "Over time" there refers to a graph of activity over time and does not refer to a timeout
[13:30] <coreycb> sahid: seems like something changed in focal so gbp is failing for sqlalchemy-utils
[13:31] <sahid> coreycb: what is the error?
[13:31] <sahid> https://launchpad.net/~sahid-ferdjaoui/+archive/ubuntu/focal-ussuri/+build/18661474
[13:31] <coreycb> sahid: may just be me fiddling with python3 on my machine
[13:32] <sahid> coreycb: can i help in any ways or i just have to wait?
[13:35] <coreycb> sahid: it's all good, I've uploaded that. thanks.
[13:36] <sahid> coreycb: great thanks, i think after that we will be good for cinder
[13:36] <coreycb> sahid: can you take a look at openstacksdk? it failed to build.
[13:36] <coreycb> sahid: great :)
[13:36] <sahid> coreycb: is that related to a timeout?
[13:36] <sahid> i had that when i was testing the buld in my PPA, i just pushed retry
[13:37] <coreycb> sahid: yes
[13:37] <sahid> coreycb: is that possible for you to make a retry?
[13:39] <coreycb> sahid: seems to be a test failure - https://launchpadlibrarian.net/463528237/buildlog_ubuntu-focal-amd64.python-openstacksdk_0.39.0-0ubuntu1_BUILDING.txt.gz
[13:41] <sahid> coreycb: yes, as mentioned i had similar issue - https://launchpad.net/~sahid-ferdjaoui/+archive/ubuntu/focal-ussuri/+build/18623945
[13:42] <sahid> coreycb: i still could disable the test
[13:46] <Laney> tjaalton: yeh, looks like one required the other or something
[13:46] <Laney> auto hinter figured it out
[13:47] <coreycb> sahid: if it's an intermittent failure, we should get a bug open upstream with some details and we could skip it, or if time permits fix it and submit upstream
[13:52] <sahid> coreycb: yes we could probbly open a bug upstream saying that the test is not passing on "slow" machines - i imagine upstream is running those tests each time a patch is submitted
[13:57] <coreycb> sahid: let me retry it again. the one failure is a timeout but the other isn't so maybe the 2nd is a timeout in disguise.
[14:01] <sahid> coreycb: sure that makes sense, please keep me posted
[14:04] <guysoft42> juliank, ok got it, under /boot/firmware/user-data there is a cloud config file with the line chpasswd expire: true. Thanks!
[14:28] <seb128> bdmurray, hey, https://launchpad.net/ubuntu/+source/automake-1.16/1:1.16.1-4ubuntu4 seems to be a wrong statement, see most recent log on http://autopkgtest.ubuntu.com/packages/a/automake-1.16/focal/armhf (and the one for ubuntu4)
[14:34] <seb128> bdmurray, I'm reverting that change for now because the tests depend on 'python' and now fail due to that which I want to get fixed in focal
[15:36] <juliank> Ugh I forgot to dump GPU state
[15:44] <joelkraehemann> hi all
[15:44] <joelkraehemann> https://launchpad.net/ubuntu/+source/gsequencer/3.0.13-1/+build/18653318
[15:44] <joelkraehemann> ^^ could someone trigger a rebuild?
[15:47] <cjwatson> joelkraehemann: done
[16:04] <Laney> bdmurray: can you point me to the scripts that generate http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html etc please?
[16:04] <vorlon> seb128: budgie-desktop> yes, hinted now
[16:05] <seb128> vorlon, thx
[16:05] <Laney> I'm in lp:ubuntu-reports but it doesn't appear to be any of those
[16:08] <joelkraehemann> cjwatson: thank you
[16:37] <smoser> cpaelzer: tych0 asks is there a ppa for newer qemus somewhere?
[16:44] <smoser> hallyn: interested also ^
[16:46] <hallyn> true story
[16:46]  * hallyn awaits the reasonable "do it yourself" answer
[16:56] <ahasenack> smoser: focal-proposed just got 4.2: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qemu
[16:56] <ahasenack> well,almost :)
[16:59] <smoser> ahasenack: thanks.
[16:59] <smoser> oh... and the cloud archive too for older releases.
[17:11] <ricotz> not so funny when running "requestsync" results in this https://paste.debian.net/plain/1129296
[17:37] <Darkchaos> So building the same package on debian buster produces correct binaries where on Ubuntu (bionic, but also using disco with pbuilder), I get missing elf header parts. The code should be the same
[17:37] <Darkchaos> can someone guide me there?
[17:51] <tkamppeter> Any known problem with the buildds for ppv64el? I have uploaded/synced Ghostscript and it seems so slow that the build does not finish in 150 minutes: https://launchpad.net/ubuntu/+source/ghostscript/9.50~dfsg-5/+build/18661407
[17:51] <tkamppeter> On my laptop it builds in 150 seconds ...
[17:53] <cjwatson> Wouldn't it be more likely to be something to do with the architecture than something to do with the builders?
[17:53] <cjwatson> Assuming your laptop isn't ppc64el, anyway :)
[17:53] <cjwatson> Other packages seem to be building fine on ppc64el, in reasonable time
[17:55] <blackboxsw> I
[17:55] <blackboxsw> I'm seeing very sluggish ppa build queues for any architecture except powerpc as well for smallish projects.
[17:57] <blackboxsw> ppa package build pages saying "in 2 hours (estimated)" for most platforms, i386 and amd64 a bit sooner, but those builds haven't happened yet. So I'm guessing the package build host machines are over subscribed at the moment
[18:00] <cjwatson> blackboxsw: That'll be unrelated to tkamppeter's issue
[18:01] <cjwatson> Only the arm* queues are particularly long at the moment
[18:02]  * blackboxsw misread ppcv64el and build delay question and jumped on a band wagon :). thx cjwatson righto.
[18:02] <blackboxsw> BTW cjwatson for my own info. is there a public site for viewing ppa build queues, or is that internal?
[18:02] <cjwatson> https://launchpad.net/builders/
[18:02] <cjwatson> Much better overview than looking at the (often terrible) estimates on a particular build page
[18:03] <blackboxsw> excellent. that helps a lot thanks cjwatson
[18:05] <blackboxsw> coincidental to this discussion all my current ppa builder jobs just dropped from 2 hrs estimate to to about 30 mins. confirming that build estimates on the PPA build pages are 'wild'
[18:06] <tkamppeter> cjwatson, are there ppc64el laptops? Or is that a server-only architecture like s390x?
[18:06] <cjwatson> I don't know of any
[18:06] <cjwatson> Which is not to say there aren't
[18:06] <cjwatson> blackboxsw: Well, I did do a few quick repairs in passing
[18:07] <blackboxsw> repair: if user == blackboxsw: "make his builders happy"
[18:07] <blackboxsw> heh
[18:07] <tkamppeter> cjwatson, the strange thing of my isue is that there are some files compiled, without any errors or warnings and then suddenly the kill-after-15-min happens.
[18:08] <cjwatson> tkamppeter: OK ... but it doesn't look like an infrastructure problem at present
[18:08] <cjwatson> It looks more like the compiler just taking forever on a particular translation unit
[18:09] <tkamppeter> cjwatson, would this mean that the compiler has a bug?
[18:09] <cjwatson> Since as I say other packages are building fine on ppc64el, so it doesn't look like slow builders in general
[18:09] <cjwatson> Well, only if my guess is correct
[18:09] <cjwatson> All I can say is that I don't see an infrastructure problem here
[18:10] <cjwatson> Have you even tried this more than once as yet?
[18:10] <cjwatson> Or tried any debugging in a PPA?
[18:34] <tkamppeter> cjwatson, I only did a retry of the build and got the same result.
[18:35] <tkamppeter> cjwatson, if a compiler gets stuck (or extremely slow at least) without giving any error message then there must be a bug in the compiler. If there would be something not allowed on ppc64el in the code, there would be an error message.
[18:36] <cjwatson> Well, I would presume so but I'm not a compiler engineer so I can't make any pronouncements about that
[18:36] <tkamppeter> Perhaps best to report a bug on gcc then.
[18:43] <tkamppeter> cjwatson, I reported bug 1862053 now. Thanks anyway.
[19:48] <cpaelzer> smoser: hallyn: for now either focal-proposed or https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3883/+packages
[19:49] <cpaelzer> smoser: hallyn: we had https://launchpad.net/~ubuntu-virt/+archive/ubuntu/virt-daily-upstream but it was absolutely ignored and a waste of time
[19:49] <cpaelzer> so we abandoned it
[19:55] <hallyn> haha, yes
[21:02] <ricotz> LocutusOfBorg, https://bugs.launchpad.net/ubuntu/+source/exiv2/+bug/1715931/comments/12