[00:25] <valorie> hey all, after creating your login on libera, remember to update your LP profile
[00:25] <valorie> so the ubuntu-ops team can snag us all with the right permissions
[00:26] <valorie> I just did it now and it takes only a sec
 I haven't yet though I need to.
 Haven't done it in so long lol.
 Seems that the GNOME IRC client doesn't work with it?
 Will sort out libera later today 😁
 @ahoneybun, what is the 'gnome' IRC client?
 hexchat works
 @ahoneybun @Sick_Rimmit do you want a #kubuntu-podcast IRC on libra?
 No, that is not used anymore
 Ok. We have all the channels we need set up then
 (Document) https://irc-attachments.kde.org/BJuZzQG3/file_44045.mp4
[21:11] <valorie> no what?
 "Last I heard the new freenode OPs were from 4chan"
 That explains a lot
[21:16] <valorie> it appears that all is proceeding according to (their) plan
[21:17] <valorie> and I assume that most of the server space that was donated to FN will now be donated to libera instead
[21:17] <valorie> bye bye


[00:53] -queuebot:#ubuntu-release- New binary: mutter [riscv64] (groovy-proposed/main) [3.37.91-1ubuntu1] (desktop-core, desktop-extra)
[01:21] <RAOF> blackboxsw_: Presumably you didn't mean to have `* <TODO: Create list with LP: # included>` in the SRU bug?
[01:22] <RAOF> (And all the rest of the un-filled-in cloud-init SRU template?)
[01:53] <blackboxsw_> RAOF: hiya. the rest of that template should be filled in shortly as it was a placeholder for the process bug.
[01:54] <blackboxsw_> all of those TODOs are ones that we will in generally during validation and verification, but I'll fill in that top section now.
[02:07] <blackboxsw_> sorry RAOF updated that top-level list of ubuntu-related items in this SRU
[02:08] <blackboxsw_> I suppose we should have had that up there to aid the initial -proposed acceptance of the uploads. I'll tweak our SRU process to make sure we have that filled in before pinging next SRU
[02:09] <blackboxsw_> I put packaging related changes up at the top to inform about deb-specific alterations beyond just syncing tip functionality from cloud-init master
[02:10] -queuebot:#ubuntu-release- New binary: mutter [arm64] (groovy-proposed/main) [3.37.91-1ubuntu1] (desktop-core, desktop-extra)
[02:11] <blackboxsw_> The rest if theTODOs we remove as we perform and attach verification logs for each section to the bug
[02:23] <RAOF> Cool, thanks.
[04:33] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (focal-proposed) [20.3-2-g371b392c-0ubuntu1~20.04.1]
[04:40] <RAOF> blackboxsw_: It looks like the changes to bionic/ec2-dont-apply-full-imds-network-config.patch and renderer-do-not-prefer-netplan.patch only change nonfunctional lines; is there a good reason for those changes to exist?
[04:42] <blackboxsw_> RAOF, good question. /me checks.
[04:42] <blackboxsw_> RAOF the ec2 patch changes the default
[04:42] <blackboxsw_> +                    self.ds_cfg, 'apply_full_imds_network_config', False))
[04:42] <blackboxsw_> from True to False
[04:43] <blackboxsw_> so it makes sure we only setup dhcp on eth0 on ec2 in bionic
[04:43] <blackboxsw_> instead of full network config from imds
[04:43] <blackboxsw_> so image creators have to explicitly from ec2 datasource config in the image to apply_full_imds_network_config: true to get full net config.
[04:44] <blackboxsw_> checking the renderer patch
[04:44] <RAOF> blackboxsw_: Ah, sorry. I mean, why, in the SRU debdiff, are the changes to those patches only in nonfunctional lines.
[04:44] <blackboxsw_> ohh checking the debdiff
[04:47] <RAOF> This also applies to the xenial patch refreshes, other than the ubuntu-advantage patch.
[04:49] <blackboxsw_> RAOF: my brain is broken, how do I get to the debdiff ... n/m found it http://launchpadlibrarian.net/495289918/cloud-init_20.2-45-g5f7825e2-0ubuntu1~18.04.1_20.3-2-g371b392c-0ubuntu1~18.04.1.diff.gz
[04:51] <blackboxsw_> hrm when we pulled a new upstream snapshot with our tooling quilt patches couldn't apply so we quilt push -f; quilt refresh'd (with a minor ubuntu-advantage tweak for backward compatible behavior.
[04:51] <blackboxsw_> I'll probably have to look at this with fresh eyes tomorrow to be sure
[04:58] <RAOF> Ah. Yeah, you probably only needed to refresh a single patch.
[05:00] <blackboxsw_> yeah, probably so, just wondering why the diff paths would have changed across quilt refresh .... a/b prefix vs  cloud-init.orig/ cloud-init
[05:01] <blackboxsw_> makes sense RAOF we can wrap that up tomorrow
[05:02] <blackboxsw_> do you prefer a reject and reupload of 20.3-2-g371b392c-0ubuntu1~18.04.1.diff.gz   or do you think that is worth  bumping the upload ver to 20.3-2-g371b392c-0ubuntu2
[05:02] <RAOF> I can just reject, and you can use the same version.
[05:03] <RAOF> It's nitpicky, but we've had weirder bugs in SRUs :)
[05:05] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (bionic-proposed) [20.3-2-g371b392c-0ubuntu1~18.04.1]
[05:05] -queuebot:#ubuntu-release- Unapproved: rejected cloud-init [source] (xenial-proposed) [20.3-2-g371b392c-0ubuntu1~16.04.1]
[05:06] <blackboxsw_> it's good, we should get to the bottom of why, or at least avoid non-functional quilt patch changes
[05:06] <blackboxsw_> thanks for this, do you prefer I ping you if we can get this fairly early US-time tomorrow, or just roll over to next SRU vanguard friday
[05:17] <RAOF> blackboxsw_: If it's before about 0530 UTC pinging me is fine, otherwise the next SRU vanguard.
[05:18] <RAOF> Ahem. 0730 UTC.
[05:18]  * RAOF fails at timezones.
[05:30] -queuebot:#ubuntu-release- Unapproved: cloud-init (xenial-proposed/main) [20.2-45-g5f7825e2-0ubuntu1~16.04.1 => 20.3-2-g371b392c-0ubuntu1~16.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[05:31] <blackboxsw_> RAOF: meh n/m about tomorrow. I couldn't help it. I fixed it manually on the current branches and re-uploaded bionic and xenial redacting those diffs. We'll have to sort tomorrow how our tooling, release process ended up adding empty quilt patch refreshes.
[05:32] <RAOF> Sorry to keep you up!
[05:33] <blackboxsw_> my own fault, if I weren't at the screen trying to figure out how to care for an aquarium, I wouldn't have made myself avail :)
[05:33] -queuebot:#ubuntu-release- Unapproved: cloud-init (bionic-proposed/main) [20.2-45-g5f7825e2-0ubuntu1~18.04.1 => 20.3-2-g371b392c-0ubuntu1~18.04.1] (edubuntu, ubuntu-cloud, ubuntu-server)
[05:34] <blackboxsw_> ok have a good day RAOF thanks for the reviews
[05:46] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (bionic-proposed) [20.3-2-g371b392c-0ubuntu1~18.04.1]
[05:49] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (xenial-proposed) [20.3-2-g371b392c-0ubuntu1~16.04.1]
[05:50] <cpaelzer> I didn't get hold of a release team member yesterday to consider https://code.launchpad.net/~paelzer/britney/hints-ubuntu-groovy-vagrant-libvirt/+merge/389888 - is now someone around?
[08:29] <rbalint> sil2100, as we discussed i'd like to upload an almost bugfix only glibc which i planned for yesterday but testing took longer. the builds are here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4234/+packages
[08:30] <rbalint> sil2100, the only notable non-bugfix is LP: #188798 to unblock focal sru
[08:30] <rbalint> i mean LP: #1887989 :-)
[08:31] <rbalint> sil2100, i hope it is still ok to upload that
[08:55] <sil2100> rbalint: yeah, proceed - although I see the package FTBFS on riscv in bileto?
[10:44] <rbalint> sil2100, riscv64, lovely, it only took 8.5 hours :-\. luckily it is flaky and will pass after a few tries or we can land LP: #1891686
[10:44] <rbalint> sil2100, thank, going ahead, it will be fine (famous last word)
[13:38] <xnox> doko: vorlon: so python3.9 on riscv64, imho is going into infinite loop. b5 built in like 16h
[13:38] <xnox> but current build is going for 3days now
[13:38] <xnox> 3 days, 5:33:59 load avg: 0.00 running: test_compileall (77 hour 10 min)
[13:38] <xnox> and this doesn't looks like it's going to complete ever.
[13:41] <xnox> 0:39:05 load avg: 1.06 [ 74/407] test_compileall passed (2 min 48 sec)
[13:41] <xnox> is what it should be (from b5 logs)
[13:47] <rbasak> sil2100: could I have an additional SRU hat review on https://bugs.launchpad.net/ubuntu/+source/sup-mail/+bug/1888749 please? Also this will need an AA hat review/accept as it's in NEW.
[13:49] <xnox> restarted python3.9 on riscv64, if it gets stuck on test_compileall again, will skip it somehow, and try again.
[14:03] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-450-server (focal-proposed/restricted) [450.51.06-0ubuntu<IP_ADDRESS> => 450.51.06-0ubuntu<IP_ADDRESS>] (i386-whitelist)
[14:04] -queuebot:#ubuntu-release- Unapproved: nvidia-graphics-drivers-450-server (bionic-proposed/restricted) [450.51.06-0ubuntu<IP_ADDRESS> => 450.51.06-0ubuntu<IP_ADDRESS>] (no packageset)
[14:12] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-450-server [source] (focal-proposed) [450.51.06-0ubuntu<IP_ADDRESS>]
[14:20] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-450-server [source] (bionic-proposed) [450.51.06-0ubuntu<IP_ADDRESS>]
[14:41] <sil2100> rbasak: will try to comment on the bug later today
[14:50] <rbasak> Thanks!
[15:08] -queuebot:#ubuntu-release- Unapproved: rejected zfcpdump-kernel [source] (focal-proposed) [5.4-0ubuntu1]
[15:35] <vorlon> xnox: am I missing something where https://people.canonical.com/~ubuntu-archive/transitions/html/libffi8.html is needed vs https://people.canonical.com/~ubuntu-archive/transitions/html/auto-libffi.html ?
[15:35] <xnox> vorlon:  i updated libffi in bzr, to catch things that reference 8.1.0 & 7 abi as abad. yet it's not updating online.
[15:35] <xnox> vorlon:  i am working off auto-libffi only now.
[15:35] <vorlon> ok
[15:35] <xnox> vorlon:  i don't know why libffi8 is "stuck"
[15:38] <xnox> RAOF:  you accepted source-new microcode-initrd, will you also review/accept the binary it produces? https://launchpad.net/ubuntu/groovy/+queue?queue_state=0&queue_text=microcode-initrd or is it bad in some way?
[15:50] <xnox> vorlon:  you accepted source-new shim-canonical, and then in v2 upload i fixed spelling/typpos pointed out, will you also review/accept the binary NEW it produces? https://launchpad.net/ubuntu/groovy/+queue?queue_state=0&queue_text=shim-canonical or is it bad in some way?
[16:30] <vorlon> cat: 'does not exist': No such file or directory
[16:30] <vorlon> >_><
[16:30] <vorlon> (https://launchpad.net/ubuntu/+source/haskell-conduit-extra/1.3.5-1build3/+build/19885708)
[18:12] -queuebot:#ubuntu-release- New binary: linux-signed-azure [amd64] (groovy-proposed/main) [5.8.0-1004.4] (core, kernel)
[18:12] -queuebot:#ubuntu-release- New binary: linux-signed-gcp [amd64] (groovy-proposed/main) [5.8.0-1002.2] (core, kernel)
[20:45] -queuebot:#ubuntu-release- Packageset: 86 entries have been added or removed
[20:45] -queuebot:#ubuntu-release- Unapproved: cinder (bionic-proposed/main) [2:12.0.9-0ubuntu1.2 => 2:12.0.10-0ubuntu1] (openstack, ubuntu-server)
[20:45] -queuebot:#ubuntu-release- Unapproved: horizon (bionic-proposed/main) [3:13.0.2-0ubuntu3 => 3:13.0.3-0ubuntu1] (openstack, ubuntu-server)
[20:48] -queuebot:#ubuntu-release- Unapproved: neutron (bionic-proposed/main) [2:12.1.0-0ubuntu1 => 2:12.1.1-0ubuntu1] (openstack, ubuntu-server)
[20:49] -queuebot:#ubuntu-release- Unapproved: neutron-fwaas (bionic-proposed/main) [1:12.0.1-0ubuntu1 => 1:12.0.2-0ubuntu1] (openstack, ubuntu-server)
[22:00] -queuebot:#ubuntu-release- New source: dragonfly-reverb (groovy-proposed/primary) [3.2.1-0ubuntu1]
[22:18] <teward> vorlon: dragonfly-reverb uploaded because upstream got off their lazy butts and switched fonts.  Guess they don't like "oops you're doing illegal stuff" as their tagline so :p
[22:18] <teward> that should be good when you review it
[22:38] <valorie> nice


[10:37] <fling> How do I extract shiftfs from this 15M patch? -> https://kernel.ubuntu.com/~kernel-ppa/mainline/v4.19.63/0001-base-packaging.patch
[10:39] <lotuspsychje> tjaalton: i updated my flickering bug a bit with some different ubuntu releases/kernels and seems like lubuntu 19.04 with kernel <IP_ADDRESS> works bug #1838644
[10:46] <TJ-> fling: don't; use the git repo
[10:47] <fling> TJ-: I have no idea in which repo to get a shiftfs patch for the specific version
[10:47] <TJ-> fling: the index page gives the repo URL and branch to pull from
[10:48] <fling> thanks
[10:50] <tjaalton> lotuspsychje: ok, I'm building 5.0.0-23 with one revert
[10:51] <lotuspsychje> tnx
[11:24] <lotuspsychje> tjaalton: ill be afk for a while, ill find your ping later ok
[11:25] <tjaalton> ok, should be ready any minute now
[11:26] <lotuspsychje> oh all wait up then
[11:26] <tjaalton> silly kernel build is mostly serial
[11:26] <tjaalton> at least with >64 cores
[11:26] <lotuspsychje> :p
[11:27] <lotuspsychje> tjaalton: we are looking for a working one this time right?
[11:27] <tjaalton> maybe
[11:27] <tjaalton> hopefully
[11:27] <lotuspsychje> kk
[11:27] <tjaalton> only seven commits to i915 since 5.0.0-13, and one looks suspicious
[11:28] <lotuspsychje> tjaalton: i saw that underrun error on lubuntu too, but it didnt flicker
[11:29] <tjaalton> ah
[11:29] <tjaalton> didn't try ubuntu 19.04?
[11:29] <lotuspsychje> yes in a live
[11:29] <lotuspsychje> those gave me flickering
[11:30] <tjaalton> 19.04 live with 5.0.0-23? how's that possible
[11:30] <tjaalton> it shipped with -13
[11:30] <lotuspsychje> oh i might be wrong about that perhaps
[11:30] <lotuspsychje> but 19.04 desktop surely flickered
[11:31] <tjaalton> then this test build is likely pointless
[11:32] <lotuspsychje> well if both have -13 and one works and the other not?
[11:32] <lotuspsychje> its an ubuntu-desktop related issue then?
[11:32] <tjaalton> no
[11:32] <tjaalton> it just manifests in a different way
[11:32] <tjaalton> you still get underruns
[11:32] <lotuspsychje> ah
[11:33] <tjaalton> did you look for bios updates?
[11:33] <lotuspsychje> not yet no, i found the clevo updates link
[11:34] <lotuspsychje> tjaalton: also weird is, i didnt get calls yet from any other clevo customer
[11:35] <lotuspsychje> and they the other guy from my bug, its also a clevo with a different bios version
[11:35] <lotuspsychje> anyway, need to bbl first
[11:35] <lotuspsychje> ill test it when im back
[11:35] <tjaalton> copying to the repo
[11:39] <tjaalton> done
[11:41] <TJ-> we really ought to have an automated tool for this :)
[11:41] <TJ-> self-service
[16:19] <lotuspsychje> tjaalton: no dice : (
[17:01] <tjaalton> not surprised
[17:17] <fling> TJ-: is there a tool for getting the shiftfs patch off there?
[17:18] <fling> git is way too slow
[18:24] <fling> I cloned deep enough but I only found shifts in the log in commit fea6d2a610c899bb7fd8e95fcbf46900b886e5a3 vfs: Use upper filesystem inode in bprm_fill_uid()
[18:24] <fling> This does not look like a shiftfs patch
[18:24] <fling> So how do I get it exactly?


[02:11] <utkarsh2102> ahasenack: yo, thanks, I didn't see that. Re-triggered the build and it's all good now. \o/
[14:21] <enr0n> Can a core dev please trigger these PPA autopkgtests?
[14:21] <enr0n> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=arm64&package=systemd&ppa=enr0n/systemd&trigger=systemd/252.1-1ubuntu1~ppa20&trigger=policykit-1/122-1
[14:21] <enr0n> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=armhf&package=systemd&ppa=enr0n/systemd&trigger=systemd/252.1-1ubuntu1~ppa20&trigger=policykit-1/122-1
[14:21] <enr0n> https://autopkgtest.ubuntu.com/request.cgi?release=lunar&arch=s390x&package=systemd&ppa=enr0n/systemd&trigger=systemd/252.1-1ubuntu1~ppa20&trigger=policykit-1/122-1
[14:30] <cengiz_io> enr0n done. for all three
[14:39] <enr0n> cengiz_io: thanks!
[14:54] <cengiz_io> can't track them though. dashboard is super slow for some reason
[14:55] <KBar> did something change in gcc? before, i could declare my own functions, e.g. getline(), and thus shadow the ones provided by the standard library but now gcc fails with "conflicting types"
[14:59] <cengiz_io> KBar, why do you want to use standard function names in your code?