=== cpaelzer_ is now known as cpaelzer
=== ebarretto_ is now known as ebarretto
[07:51] <slyon> hey! Could somebody please drop sway 1.6-1 and wlroots 0.13.0-1 from impish-proposed? I started this transition in coordination with upstream wlroots & phoc developers and in anticipation that they would reach compatibility by feature freeze. But they didn't. So let's stay on old wlroots (and sway) until next cycle, in order not to drop phoc.
[07:51] <slyon> related to: https://bugs.launchpad.net/ubuntu/+source/phoc/+bug/1938404
[07:51] <ubottu> Launchpad bug 1938404 in wlroots (Ubuntu) "Phoc is not (yet) compatible with wlroots >= 0.13" [Undecided, New]
[07:53] <sil2100> slyon: ok, can do that, do we need to rebuild anything after dropping those packages? i.e. since this is a transition, could something have built against the new versions and now being stuck in -proposed?
[07:55] <slyon> sil2100: Thanks! No need to rebuild anything. The only depends are sway and phoc. we drop the sway build from -proposed and phoc was not rebuild against wlroots 0.13.
[07:57] <sil2100> o/
[08:17] <sil2100> Done o/
[08:22] <sil2100> juliank: hey! So I was finally able to release the shim/fwupd that we had in bionic-proposed
[08:22] <sil2100> juliank: can you prepare the new shim for bionic now? The one with the media boot fixes?
[08:23] <juliank> sil2100: hooray, and yes
[08:52] -queuebot:#ubuntu-release- Unapproved: netplan.io (hirsute-proposed/main) [0.102-0ubuntu3 => 0.103-0ubuntu5~21.04.1] (core)
[08:56] -queuebot:#ubuntu-release- Unapproved: netplan.io (focal-proposed/main) [0.102-0ubuntu1~20.04.2 => 0.103-0ubuntu5~20.04.1] (core)
[09:22] -queuebot:#ubuntu-release- Unapproved: debian-installer (bionic-proposed/main) [20101020ubuntu543.17 => 20101020ubuntu543.18] (core)
[09:38] <sil2100> bdmurray: hey! Once you're around, could you take a look at base-files and debian-installer for bionic?
[09:38] <sil2100> This is for .6
[09:38] <sil2100> We'll also need to prep ubiquity with the new d-i, but I want these to first be in -proposed so I can pull them in
[09:41] <sil2100> hm hm
[09:42] <sil2100> Looking at the bionic release notes, it looks like 5 year support was only declared for desktop, server and core, so I don't think we need to refresh other flavors?
[10:01] -queuebot:#ubuntu-release- Unapproved: shim (bionic-proposed/main) [15.4-0ubuntu7 => 15.4-0ubuntu9] (core) (sync)
[10:01] <juliank> sil2100: ^ shim/bionic for the usual approve+approve signing tarballs dance
[10:05] <juliank> sil2100: ^ shim-signed to approve after signing tarballs are published (or well approve early and retry build)
[10:05] -queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.37~18.04.10 => 1.37~18.04.11] (core)
[10:06] <juliank> well more v than ^
[10:06] <juliank> :D
[10:06] <sil2100> ;)
[10:06] <sil2100> Thanks, looking!
[10:17] -queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (bionic-proposed) [15.4-0ubuntu9]
[10:26] <fossfreedom> Are there any release folk around? The last three daily impish preinstalled (raspberry pi) builds have failed.  The logs files are pretty short and I don't see why. Any ideas?
[10:28] <sil2100> Looking
[10:29] <sil2100> fossfreedom: preinstalled desktop or server images?
[10:30] <sil2100> fossfreedom: ok, I see server for instance, hm, this looks like an issue with the gadget tree for raspi images
[10:30] <sil2100> Almost as if the makefile wasn't able to find the dtbs in the raspi kernel
[10:30] <sil2100> I'll look into that once I'm back from an errand
[10:34] <waveform> I can take a look in a mo -- I don't recall any recent changes to the pi-gadget though
[10:36] <fossfreedom> This is the log I was looking at https://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/impish/daily-preinstalled-20210907.log
[10:42] <waveform> I do recall some talk of correcting the location of dtbs in the arm64 raspi kernel (it differs from the armhf raspi in having an extra "broadcom" directory in the path for no particularly good reason), but I wasn't sure whether that had happened yet (and the gadget code *should* be resilient to that change as it uses the same logic for both armhf and arm64 archs)
[10:45] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.37~18.04.11]
[10:46] <sil2100> fossfreedom: the preinstalled logs are usually short like this, the most interesting bits are actually in the livefs build logs for a given subarch
[10:46] <sil2100> fossfreedom: you can get the links from that cd-build-logs log as well
[10:46] <sil2100> waveform: thanks! Might be that or something similar?
[10:47] <waveform> sil2100, possibly -- which log were you looking at for the dtb failure?
[10:50] <sil2100> https://launchpadlibrarian.net/557222617/buildlog_ubuntu_impish_armhf_raspi_cpc_BUILDING.txt.gz
[10:50] <sil2100> For instance here, from the raspi server livefs failure
[10:50] <sil2100> find: '/build/config/livecd.ubuntu-cpc-raspi-gadget/stage/lib/firmware/*/device-tree': No such file or directory
[10:50] <waveform> oh, that's armhf -- interesting
[10:50] <sil2100> arm64 also failed, I expect in the same way?
[10:57] <waveform> yes, it did ... the fact that both of those failed suggests something is either quite broken in the linux-raspi kernel package, or the dtb's been moved somewhere else in *both* archs
[10:58] <waveform> I'll go have a look at the kernel packages it was trying to use
[11:09] <waveform> sil2100, does the image builder use the bootstrap kernels PPA for its kernel? Just wondering as it's grabbing 1006.12, while launchpad's linux-raspi package for impish is still on 1006.7
[11:10] <waveform> sil2100, and the only 1006.12 linux-raspi I can find is in the bootstrap kernels PPA and it appears to be missing linux-modules-raspi (which is where those d-t's come from)
[11:12] <waveform> (but I can't find a mention of that PPA in the build-log so I'm wondering if it's implicit in something else)
[11:17] -queuebot:#ubuntu-release- Unapproved: postfix (focal-proposed/main) [3.4.13-0ubuntu1.1 => 3.4.13-0ubuntu1.2] (core)
[11:17] -queuebot:#ubuntu-release- Unapproved: postfix (hirsute-proposed/main) [3.5.6-1ubuntu0.1 => 3.5.6-1ubuntu0.2] (core)
[12:43] -queuebot:#ubuntu-release- Unapproved: python-os-vif (focal-proposed/main) [2.0.0-0ubuntu1 => 2.0.0-0ubuntu2] (ubuntu-server)
[13:39] -queuebot:#ubuntu-release- Packageset: Added python-os-vif to openstack in bionic
[13:39] -queuebot:#ubuntu-release- Packageset: Added python-os-vif to openstack in focal
[13:48] <jamespage> apologies for the ceph upload to impish that just generated a component mismatch - that was a little unexpected - untangling that now
[13:52] <jamespage> actually that's not quite as awful as I thought it was - pmdk is already in main so its a binary only promotion of the library being used by ceph
[14:14] <sil2100> waveform: ah ha!
[14:14] <sil2100> waveform: found the issue
[14:14] <waveform> sil2100, ooh - pray tell!
[14:19] <sil2100> waveform: so, ok, still trying to see the whole situation, but it probably actually got broken by the recent 5.13 kernel package - so it seems we were staging linux-modules-extra-raspi in the past, which now is provided by linux-meta-raspi instead of, I suppose, linux-raspi itself
[14:19] <sil2100> Now I think linux-modules-extra-raspi is a virtual package
[14:19] <sil2100> Depending on the latest -modules-extra
[14:20] <waveform> hmmm, I think the dtb's are normally in linux-modules-raspi rather than linux-modules-extra-raspi?
[14:20] <waveform> will just check...
[14:20] <sil2100> Well, that's what we were doing last time at least
[14:21] <sil2100> (by last time I mean like always)
[14:22] <waveform> hmm, on a hirsute install here the dtb's are indeed from linux-modules-<version>-raspi (rather than the modules-extra package)
[14:24] <sil2100> Oh, oh, maybe we do some weird * in the stage_packages call?
[14:25] <sil2100> Like, so that now it started matching modules-extra instead of -modules?
[14:25] <sil2100> hah
[14:25] <sil2100> Yes
[14:25] <sil2100> $(call stage_package,linux-modules-*-$(KERNEL_FLAVOR))
[14:26] <sil2100> So after they created a meta package for linux-modules-extra-raspi in linux-raspi, this now matches linux-modules-extra-raspi instead of linux-modules-<version>-raspi probably
[14:26] <sil2100> So you were right, it's just that the build is doing it wrong! Forgot we had this globbing there
[14:28] <waveform> ahhh
[14:28] <waveform> right, I'll look into getting that fixed up -- thanks for the help!
[14:38] <ogra> just out of curiosity, why are the dtbs in a modules package and not in linux-image* ? i.e. what if i wanted a super minimal system without modules and just the bare kernel ?
[14:50] <xnox> historically image one only contained the image and that's it.
[14:50] <xnox> it's ambigious where to put modules/modules-extra/firmware/dtbs
[14:50] <xnox> some think of dtbs more of a firmware than a module, or an image.
[14:53] <ogra> well, dtbs are the hardware definition files and configure and enable pieces of the HW ... i'd argue they are a hard requirement to boot the image
[14:54] <ogra> either way, just curious ... it seems weird to do such a split (not that i'd use the image without modules but i have seen such cases)
[14:56] <xnox> no neceserily a hard requirement. i.e. a suboptimal / incomplete earlier version of dtb may be enough to boot the image. and then one can load a different dtb with matching definitions that match the drivers in the kernel.
[14:57] <xnox> it has not been true for many years that it is just a hardware definition. Due to extensive refactorings, and changes, it is also a bindings of linux-specific drivers, and their settings and customizations tied to a given linux release too.
[14:57] <ogra> heh ... and whete would that "different dtb" come from ?
[14:57] <bdmurray> sil2100: what do we want to do with the basefiles from uh last september :-|
[14:57] <xnox> i.e. on RISC-V we have 3 dtbs at play during boot: u-boot SPL, full u-boot, and kernel.
[14:57] <ogra> yeah, that is sadly true ...
[14:58] <xnox> all of them are slightly similar, but do have slightly different bindings for things that OpenSBI has drivers for, for things that u-boot has drivers for, and things for which linux kernel has drivers for.
[14:58] <sil2100> bdmurray: we'll have to rebase that after .6
[14:58] <xnox> and some portions of the dtb are specific to each stage.
[14:58] <xnox> i.e. whilst the u-boot SPL sets CPU clock speed, it cannot be changed again, hence the linux kernel dtb doesn't even mention that.
[14:58] <xnox> but imho it should.
[14:58] <ogra> but that is expected after all. they apply to differebnt binaries fulfilling different purpose and different tasks
[14:58] <xnox> hence we do have 3 representations of dtbs.
[14:59] <ogra> sure
[14:59] <xnox> for a single set of (hardware, u-boot, linux)
[14:59] <ogra> but you only have one for the actual kerneö
[14:59] <xnox> they do try to keep them consistent with each other, out of obvious reasons.
[14:59] <ogra> *kernel
[14:59] <xnox> not quite, when u-boot loads it, it merges it with it's previous state, and modifies it in flight.
[14:59] <xnox> so what's loaded and used in memory by linux in the last stage, doesn't match the dtb blob on disk.
[14:59] <ogra> uh
[15:00] <xnox> yeah..... ureghgggggh
[15:01] <waveform> heh, no difference to the pi there where the dtb loaded from the boot partition by the pi bootloader is then modified by that same bootloader in a variety of ways before it's passed to the linux kernel (and when u-boot was involved in the mix, that made its own modifications too)
[15:01] <ogra> yeah, thats super ugly ... but it is Pi 😛
[15:01] <xnox> i think a decade ago, the loaded dtb wiped all prior state of things. but yeah, that's not the case anymore.
[15:02] <ogra> on i.e. beaglebone the ram is flushed between dtb loads AFAIK
[15:02] <xnox> it's even done on EFI arm64 bootstages too. and there is work done to implement these UEFI dtb mangling between firmware => uboot => efi-grub => linux and back.
[15:02] <xnox> cause one needs to preserve things that are dynamic / per-board / per-boot environment.
[15:03] <xnox> and it seems like people use dtb as state passing protocol
[15:03] <ogra> oh my
[15:11] <sil2100> bdmurray: let me review u-r-u for bionic in the meantime
[15:11] <sil2100> I forgot about that one
[15:12] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (bionic-proposed) [1:18.04.45]
[15:18] -queuebot:#ubuntu-release- Unapproved: rejected base-files [source] (bionic-proposed) [10.1ubuntu2.11]
[15:26] -queuebot:#ubuntu-release- Unapproved: accepted base-files [source] (bionic-proposed) [10.1ubuntu2.11]
=== hellswor1 is now known as hellswor2
[15:37] -queuebot:#ubuntu-release- Unapproved: accepted debian-installer [source] (bionic-proposed) [20101020ubuntu543.18]
[15:42] -queuebot:#ubuntu-release- Unapproved: netplan.io (bionic-proposed/main) [0.99-0ubuntu3~18.04.4 => 0.99-0ubuntu3~18.04.5] (core)
[16:59] <hellswor2> hey folks.. I think i'm missing some process understanding. I've been operating under the assumpiton that if a vcs-git line points to salsa, then that means ubuntu syncs from debian and there's no ubuntu fork. and in this case we should get all fixes upstream in debian, to avoid forking. but in most cases my PRs in salsa go ignored
[16:59] <hellswor2> (https://salsa.debian.org/debian/libpam-alreadyloggedin/-/merge_requests/1, https://salsa.debian.org/debian/gnucash/-/merge_requests/1). so do we fork in these cases?
[16:59] <ubottu> Merge 1 in debian/libpam-alreadyloggedin "Update patch to no longer define BUG_STAT_MISSING" [Opened]
[16:59] <ubottu> Merge 1 in debian/gnucash "Fix build with glib 2.68 (Closes: #986969)" [Opened]
[17:01] <hellswor2> the libpam-alreadyloggedin patch was picked up and provided in https://launchpad.net/ubuntu/+source/libpam-alreadyloggedin/0.3-9ubuntu1 but i can't find where the source for the forked repo is
[17:01] <bdmurray> hellswor2: the source for libpam-alreadyloggedin in ubuntu?
[17:01] <hellswor2> correct
[17:01] <hellswor2> i can see what was uploaded but i'm looking for a git repo of sorts
[17:02] <hellswor2> and should it have been forked
[17:02] <bdmurray> there isn't one b/c its in universe
[17:02] <hellswor2> i kind of thought it was a pretty hard and fast rule that we fork only when absolutely necessary
[17:02] <bdmurray> git-ubuntu only has packages in main
[17:03] <hellswor2> hmm ok. so if it's in universe, then how does that change the process?
[17:03] <bdmurray> what do you mean by process?
[17:03] <hellswor2> :)
[17:04] <hellswor2> i mean.. if libpam-alreadylogged in was in main, then we are sync'ing from debian up until we really can't for whatever reason. then we fork, push to launchpad somewhere and update the vcs-git line to say hey we're not pulling from debian anymore.
[17:05] <hellswor2> so if libpam-alreadyloggedin is in universe... i see a patch added to the source but looks like it's still being sync'd from debian because the vcs-git line still points to salsa
[17:05] <bdmurray> Oh, I haven't seen vcs-git lines being updated when we fork
[17:05] <bdmurray> sync'ing is done based off the package version string
[17:05] <hellswor2> oh geez then how would you know where to submit a patch?
[17:06] <bdmurray> the patch should go upstream, we are just carrying a diff for a little while
[17:07] <hellswor2> ok so we don't need to fork to carry a diff..
[17:08] <bdmurray> that's correct
[17:08] <hellswor2> so then in the case of gnucash, instead of waiting for debian to merge my PR, i need to just build it and submit for someone to upload it and all is hunky dory..
[17:08] <bdmurray> yes, if the bug is important enough to get fixed for impish
[17:08] <hellswor2> i thought that if there was a diff from debian, then there is a fork with those different changes
[17:09] <bdmurray> there could be but there doesn't have to be
[17:09] <hellswor2> what if the package is in main instead of universe? would that mean there's a fork?
[17:09] <hellswor2> (if there's a diff from debian)
[17:09] <hellswor2> or same rule applies? could be a fork but doesn't have to be
[17:10] <hellswor2> and why wouldn't we update the vcs-git line when we DO fork?
[17:10] <bdmurray> if it was in main it would get imported in git-ubuntu but only the server team can commit to those branches afaik
[17:16] <bdmurray> hellswor2: do you have an updated patch for gnucash so we can get that uploaded for impish?
[17:17] <hellswor2> i do
[17:18] <xnox> vorlon:  re:dwarves SRU => so because there is incomplete regression plan for libbpf in hirsute, you neither accepted nor rejected both focal & hirsute SRUs. I am not sure what I am supposed to do next. Should I upload dwarves-dfsg that uses vendored / statically linked libbpf like it did in focal, as an sru for both focal & hirsute? this way kernel gets new pahole it wants, without any
[17:18] <hellswor2> i updated the salsa PR thinking that that was were the patch went
[17:18] <xnox> potential regression issues for libbpf users in hirsute?
[17:18] <xnox> vorlon:  https://bugs.launchpad.net/ubuntu/focal/+source/libbpf/+bug/1912811
[17:18] <ubottu> Launchpad bug 1912811 in dwarves-dfsg (Ubuntu Focal) "Update dwarves-dfsg in focal to version 1.21 from hirsute" [Medium, Confirmed]
[17:19] <xnox> vorlon:  or given that hirsute will fall off support, can we at least get dwarves-dfsg & libbpf accepted in focal please?
[17:23] <hellswor2> bdmurray: how do you know when it's acceptable to carry a diff from debian for a package? what is the philosophy or hard rules here?
[17:25] <bdmurray> I think about the severity of the issue and where we are in the release cycle. Given that we are past feature freeze we aren't likely to import a new package version from debian and this specific bug seems serious so I'd introduce a diff here.
[17:26] <hellswor2> ok thanks. i'll prepare a gnucash for upload then with this patch right now :)
[17:42] <xnox> vorlon:  may i upload new dwarves to builder-extra ppa which is used when building kernels, cause its blocking us enabling bpf kernel feature, as new dwarves is needed at kernel build time.
[17:42] <xnox> which cloud kernels really need
[17:55] <hellswor2> bdmurray: gnucash 4.4 is what impish has, upstream has a 4.6 and my salsa pr is the glib patch on top of 4.6. should a prepared gnucash for ubuntu contain the 4.6 changes too, in addition to the glib patch?
[17:56] <hellswor2> or maybe it should just be the minimal glib patch on top of 4.4
[17:57] <bdmurray> I'd guess 4.6 has some new features which would require a Feature Freeze Exception.
[17:57] <hellswor2> ok. going for 4.4+patch then. thanks so much :)
[17:57] <bdmurray> no problem, happy to help
[18:16] <rbasak> bdmurray: o/ on request, we can import any package in universe into git-ubuntu and it will be maintained. There are quite a few now. I'm just avoiding bulk importing everything until the applied branches are stable.
[18:17] <rbasak> bdmurray: experimentally anyone can import rich history into any git-ubuntu imported repo now. There's CLI support in the edge snap, but it's not got a stable interface yet (I've received feedback to change it) but it works today, if you're interested. I was going to announce after making the latest suggested changes to the CLI.
[18:18] <rbasak> (if you write your own changes files then the support is stable :-P
[18:38] <hellswor2> bdmurray: I've uploaded a patched 4.4 for gnucash here: https://launchpad.net/~hellsworth/+archive/ubuntu/gnucash that fixes the ftbfs issue
[18:38] -queuebot:#ubuntu-release- New source: python-oslo.metrics (impish-proposed/primary) [0.3.0-0ubuntu1]
[18:39] <hellswor2> could you please upload this for me?
[18:41] <bdmurray> hellswor2: it looks like it failed to build...
[18:43] <hellswor2> gosh darnit! ok i'll come back to this a little later on today then.
[18:44] -queuebot:#ubuntu-release- Unapproved: systemd (hirsute-proposed/main) [247.3-3ubuntu3.5 => 247.3-3ubuntu3.6] (core, i386-whitelist)
[18:47] -queuebot:#ubuntu-release- Unapproved: systemd (focal-proposed/main) [245.4-4ubuntu3.12 => 245.4-4ubuntu3.13] (core, i386-whitelist)
[18:49] <ddstreet> bdmurray i know it's not your sru shift today, but i had to re-upload systemd, only to revert/remove a patch from the OEM team, i'd like to get the respin into -proposed if possible so it doesn't get delayed too far into next week
[18:50] <ddstreet> it's just a minor change from the current upload in -proposed for f/h, to remove a patch
[18:50] <bdmurray> ddstreet: isn't it Tuesday?
[18:50] <ddstreet> ah man the holiday yesterday has me all messed up xD
[18:50] <ddstreet> i keep thinking it's monday
[18:51] <ddstreet> so i guess lucky me, it is your sru shift :)
[18:56] <bdmurray> ddstreet: the diffs are still pending but I'll have a look later today
[18:57] <ddstreet> thanks!
[19:05] <bdmurray> hunh maybe LP is generating diffs
[19:15] <bdmurray> s/is/isn't/
[19:17] -queuebot:#ubuntu-release- Unapproved: accepted google-guest-agent [source] (hirsute-proposed) [20210629.00-0ubuntu1~21.04.0]
[19:20] -queuebot:#ubuntu-release- Unapproved: accepted google-guest-agent [source] (focal-proposed) [20210629.00-0ubuntu1~20.04.0]
[19:26] -queuebot:#ubuntu-release- Unapproved: accepted google-osconfig-agent [source] (hirsute-proposed) [20210608.1-0ubuntu1~21.04.0]
[19:30] -queuebot:#ubuntu-release- Unapproved: accepted google-osconfig-agent [source] (focal-proposed) [20210608.1-0ubuntu1~20.04.0]
[19:40] -queuebot:#ubuntu-release- Unapproved: accepted google-compute-engine-oslogin [source] (hirsute-proposed) [20210728.00-0ubuntu1~21.04.0]
[20:03] -queuebot:#ubuntu-release- Unapproved: accepted google-compute-engine-oslogin [source] (focal-proposed) [20210728.00-0ubuntu1~20.04.0]
[20:15] -queuebot:#ubuntu-release- Unapproved: accepted libtgowt [source] (hirsute-proposed) [0~git20210627.91d836d+dfsg-3ubuntu1~21.04]
[20:31] -queuebot:#ubuntu-release- Unapproved: accepted photofilmstrip [source] (focal-proposed) [3.7.2-1ubuntu0.1]
[20:36] -queuebot:#ubuntu-release- Unapproved: accepted udisks2 [source] (focal-proposed) [2.8.4-1ubuntu2]
[20:38] <vorlon> xnox: hirsute still has 5 months of support, no I won't accept the focal SRUs without a plan for hirsute.  Static bundling with dwarves would be an acceptable option to me
[20:51] -queuebot:#ubuntu-release- Unapproved: systemd (focal-proposed/main) [245.4-4ubuntu3.12 => 245.4-4ubuntu3.13] (core, i386-whitelist)
[20:53] -queuebot:#ubuntu-release- Unapproved: systemd (hirsute-proposed/main) [247.3-3ubuntu3.5 => 247.3-3ubuntu3.6] (core, i386-whitelist)
[20:53] -queuebot:#ubuntu-release- Unapproved: accepted ceph [source] (focal-proposed) [15.2.14-0ubuntu0.20.04.1]
[20:54] -queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (hirsute-proposed) [247.3-3ubuntu3.6]
[20:57] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (hirsute-proposed) [247.3-3ubuntu3.6]
[21:01] -queuebot:#ubuntu-release- Unapproved: rejected systemd [source] (focal-proposed) [245.4-4ubuntu3.13]
[21:06] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (focal-proposed) [245.4-4ubuntu3.13]
[21:22] -queuebot:#ubuntu-release- Unapproved: accepted python-os-vif [source] (focal-proposed) [2.0.0-0ubuntu2]
[21:45] -queuebot:#ubuntu-release- Unapproved: ubiquity (bionic-proposed/main) [18.04.14.15 => 18.04.14.16] (core)
[21:45] <sil2100> bdmurray: hey! Can you take a look at ubiquity as well? ^
[21:47] <bdmurray> yep
[21:57] -queuebot:#ubuntu-release- Unapproved: accepted ubiquity [source] (bionic-proposed) [18.04.14.16]
[22:05] <sil2100> \o/
[23:34] <sil2100> I'll kick some image builds tomorrow, for bionic
[23:34] <sil2100> o/