[07:08] <doko> seb128: your (sponsored?) libraw ftbfs on ppc64el. dropped smbols diff?
[07:36] <seb128> doko, hey, we didn't have symbols changes, http://launchpadlibrarian.net/470511040/libraw_0.19.5-1build1_0.19.5-1ubuntu1.diff.gz was our delta and it got merged in Debian ... do you understand why you toolchain is producing symbols different from Debian now?
[07:36] <seb128> why our toolchain*
[07:39] <doko> seb128: GCC 9 -> GCC 10, the package was last updated in April. "now"? Ubuntu is building with -O3 on ppc64el from the start
[07:41] <seb128> doko, well, that package was in sync and there was no issue previous cycles so 'now' yes
[07:41] <seb128> I'm unsure how to properly handle those cases
[07:41] <seb128> having to diverge the packages for cpp symbols difference on some archs is really annoying
[08:10] <doko> seb128: mark them as optional, forward the patch to Debian. you should be able to reproduce on amd64 with -O3 as well
[08:44] <seb128> doko, I'm not going to be able to work on that this week with feature freeze, I will poke at it next week if it's still unresolved
[15:11] <seb128> hum, I did a bunch of retries of https://autopkgtest.ubuntu.com/request.cgi?release=hirsute&arch=ppc64el&package=netplan.io&trigger=network-manager/1.28.0-2ubuntu2 this week but nothing is showing up on https://autopkgtest.ubuntu.com/packages/n/netplan.io/hirsute/ppc64el
[15:11] <seb128> which is the last blocker for network-manager to migrate
[15:12] <seb128> does anyone know what's going on there?
[15:13] <Laney> It usually means they are considered to be infrastructure failures but aren't and should be recorded as real failures
[15:13] <Laney> You can see them running on /running so the retries weren't really necessary
[15:13] <Laney> let me see if there's a log
[15:14] <seb128> thx
[15:14] <Laney> they are always failing like:
[15:14] <Laney>                                                                                                                  Err:1 http://ftpmaster.internal/ubuntu hirsute/universe ppc64el wireguard-tools ppc64el 1.0.20200827-1ubuntu1
[15:14] <Laney>                                                                                                                    Temporary failure resolving 'ftpmaster.internal'
[15:15] <Laney>                                                                                                                  E: Failed to fetch http://ftpmaster.internal/ubuntu/pool/universe/w/wireguard/wireguard-tools_1.0.20200827-1ubuntu1
[15:15] <Laney>                                                                                                                  E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
[15:15] <Laney> so I guess one of the earlier tests is breaking the system somehow
[15:15] <Laney> let's see, maybe I can tweak things so it fails, it is going to be a failure though
[15:15] <seb128> that log is dns resolving error?
[15:15] <seb128> is that something to raise to IS ?
[15:16] <Laney> https://paste.ubuntu.com/p/dbnM4MgVxc/
[15:16] <Laney> I doubt it, not if it happens 100% of the time
[15:16] <Laney> that says to me that something breaks the testbed, it's highly likely to be guest side
[15:18] <ed_> speculation is that there's something added in rust-libc in proposed that isn't in sid, would anyone mind taking a look and see what the difference is please?
[15:19] <seb128> Laney, any idea who would be the right person to flag the issue to?
[15:20] <Laney> seb128: no idea, maybe slyo_n could try to reproduce as a first thing?
[15:20] <seb128> xnox? slyon ?
[15:20] <seb128> k, thanks!
[15:20] <Laney> hopefully happens with canonistack too
[15:20] <seb128> Laney, could you make network-manager migrate meanwhile? ;)
[15:21] <seb128> I would like to upload another one before ff but ideally after that one migrates
[15:21] <slyon> seb128: currently in a meeting. Will have a look soon!
[15:21] <seb128> slyon, thanks!
[15:22] <xnox> seb128:  sorry, not sure about the context, what is your question to me in this channel?
[15:23] <seb128> xnox, some update is causing 'Temporary failure resolving 'ftpmaster.internal' errors for netplan.io/ppc64el/hirsute tests
[15:23] <seb128> I'm trying to figure out who would be the right person to have an idea about that
[15:23] <Laney> seb128: I dunno, how do we know it's not broken, did you confirm that the same bug happens with netplan in release without the new n-m?
[15:24] <seb128> Laney, no, I guess there is no being lazy there? !:-(
[15:24] <xnox> seb128:  i thought, that networking is funny on that arch, i thought you would not be able to get to ftpmaster.internal there.... but i guess it was working before?
[15:24] <seb128> I can't squeeze debugging of that before ff though, I will just upload the new n-m without waiting for that one to migration I guess
[15:25] <seb128> xnox, https://autopkgtest.ubuntu.com/packages/n/netplan.io/hirsute/ppc64el has some successful tests yes, also now retries don't even make it to the webpage as failing
[15:25] <seb128> see backlog here just before my ping
[15:25] <Laney> Just wait a bit for the logs to show up
[15:25] <Laney> Once I fix it it will fail and then you might be able to see that
[15:27] <xnox> seb128:  systemd	247.1-4ubuntu1 is last successful run; and now systemd is at 247.3-1ubuntu2
[15:27] <seb128> Laney, ah ok, thanks
[15:27] <xnox> seb128:  i would like casually mention rbalint and like mention maybe resolved is b0rked on ppc64el in hirsute-release.....
[15:28] <Laney> hahah
[15:28]  * xnox !myteam
[15:28] <Laney> everyone just pings each other until all developers are involved
[15:28] <rbalint> xnox, eh :-)
[15:28] <seb128> :-)
[15:28] <Laney> then we'll be like "wait"
[15:28] <Laney> "did someone try running the bloody thing yet?"
[15:36] <Laney> k, well after those run again they should fail now, might be a little while
[15:36] <rbalint> Laney, are systemd test running on big VMs? asking for a friend in https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1915126/comments/12
[15:40] <Laney> rbalint: nope (you can see the flavor at the top of autopkgtest logs); last I tried it the fsckd test was still failing most of the time so it wouldn't have helped
[15:40] <Laney> comment #10 in that same bug
[15:46] <Laney> is this better now with ubuntu2?
[15:50] <slyon> xnox: rbalint: so is resolved kaputt on hirsute-release/ppc64el? Do I need to investigate further, like reproducing on canonistack or is the problem already known?
[15:51] <xnox> slyon:  i wash my hands of all of that. =) i'm busy doing merges for the Freeze Eve =)
[15:51] <Laney> I think someone needs to reproduce it yeah
[15:52] <slyon> okay
[15:52]  * slyon spinning up canonistack
[15:53] <Laney> slyon: It looks like resolving works for a bit
[15:53] <Laney> and then it fails later on, so I dunno what happens which makes it break
[15:53] <slyon> yeah.. And the same tests work on all other architectures :-/
[15:54] <Laney> it's ok, this is the kind of thing that keeps food on the table :>
[15:54] <Laney> (software engineering, a giant money making scam!)
[15:54] <slyon> hehe
[16:02] <ItzSwirlz> bdmurray: hello
[16:02] <ItzSwirlz> yes i got your email about the regression
[16:02] <ItzSwirlz> It would help if how about because i'm the person who made the patch I could like.. be able to view the errors lol
[16:02] <ItzSwirlz> i'm trying to apply for a packageset but can't without sponsors and i don't have perms to view errors, i just submitted the form, can someone help lol
[16:07] <bdmurray> I've added you
[16:08] <rbalint> Laney, i've also left a comment on LP: #1915126 reviewing the last runs
[16:09] <rbalint> Laney, i can revisit LP: #1915126 on Monday
[16:09] <Laney> rbalint: Cheers, flaky is good enough for me. I just don't want to use big instances if it still fails all the time, hope that makes sense
[16:09] <Laney> If they actually help it *pass*, that is all good with me
[16:10] <ItzSwirlz> tysm
[16:15] <rbalint> slyon, xnox, seb128 i've retried netplan.io/hirsute/ppc64el with hello only, to see if there is really a regression in the release pocket
[16:15] <seb128> rbalint, thx
[16:18] <Laney> I think you'd have seen that in the results once they got posted
[16:29] <ItzSwirlz> i'll have to try to reproduce it later
[16:30] <ItzSwirlz> (cinn-screensaver)
[17:55] <ItzSwirlz> So about the cinnamon-screensaver regression: I'm not getting any crashes
[17:56] <ItzSwirlz> Maybe the end user is using deb spotify and it's a spotify problem?
[18:02] <ItzSwirlz> I can't seem to find it at all.
[18:15] <ItzSwirlz> Okay. 1) Why are we stopping phasing a package if theres only *one* occurrence of a regression? I know there is four that appears in the recent SRU but it is just one case. I'm thinking the best I can to try and replicate this but I just can't.
[18:15] <ItzSwirlz> I opened LP 1916789 for now?
[22:50] <Paddy_NI> Quick question, is "TestDrive" no longer recommended in favour or "MultiPass" now?
[22:53] <sarnold> Paddy_NI: heh, this is the first I'm hearing of testdrive -- it looks like it doesn't exist beyond 18.04 https://launchpad.net/ubuntu/+source/testdrive
[22:54] <Paddy_NI> sarnold: Ah, I had thought it went pretty quiet :-)
[22:55] <Paddy_NI> I was just wondering what the "officially blessed" way to get a clean environment for testing, debugging etc was these days.  I had noticed Martin Wimpress uses his own solution "quick-emu" and I was wondering why.
[22:55] <sarnold> wow.. it hasn't been updated since 2014 https://launchpad.net/ubuntu/+source/testdrive/+changelog
[22:55] <Paddy_NI> I guess his use case(s) are much more particular :-)
[22:56] <Paddy_NI> sarnold: I always remembered it being fast and easy