[06:33] -queuebot:#ubuntu-release- Unapproved: php7.0 (xenial-proposed/main) [7.0.33-0ubuntu<IP_ADDRESS> => 7.0.33-0ubuntu<IP_ADDRESS>] (kubuntu, ubuntu-desktop, ubuntu-server)
[08:39] -queuebot:#ubuntu-release- New binary: leaflet-markercluster [amd64] (disco-proposed/universe) [1.4.1~dfsg-6] (no packageset)
[08:59] <apw> anyone know anything about the set of android tools (android-platform-development) which have managed to get into cosmic-proposed with a lower version than cosmic-release ?
[08:59] <apw> likely binary copy forwards from bionic done in error ?
[09:17] <LocutusOfBorg> apw, I think this has been done by vorlon in effort to backport https://bugs.launchpad.net/ubuntu/+source/android-platform-libcore/+bug/1819448 to bionic (and also cosmic) to ensure smooth upgrades path?
[09:18] <LocutusOfBorg> but of course some of them already have higher version in release, so they should be just removed from the proposed pocket?
[09:18] <apw> yeah that is what my reports are telling me to do :)
[09:36] <LocutusOfBorg> hello, can anybody please update debci hint to 2.0 too?
[09:45] <LocutusOfBorg> please also hint octave-image/2.10.0-2 on ppc64el, regressed in release
[09:46] <LocutusOfBorg> (its already ignored on amd64 and i386, same OOM)
[09:46] <LocutusOfBorg> apw, ^^
[10:24] -queuebot:#ubuntu-release- Unapproved: systemd (bionic-proposed/main) [237-3ubuntu10.15 => 237-3ubuntu10.16] (core)
[10:39] -queuebot:#ubuntu-release- Unapproved: virtualbox-lts-xenial (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu<IP_ADDRESS>~14.04.6 => 4.3.40-dfsg-0ubuntu<IP_ADDRESS>~14.04.1] (no packageset)
[10:39] -queuebot:#ubuntu-release- Unapproved: virtualbox (trusty-proposed/multiverse) [4.3.36-dfsg-1+deb8u1ubuntu<IP_ADDRESS> => 4.3.40-dfsg-0ubuntu14.04.1] (ubuntu-cloud)
[10:47] <LocutusOfBorg> can anybody please reject from trusty queue the below?
[10:47] <LocutusOfBorg>
[10:47] <LocutusOfBorg> [Source] virtualbox (source)
[10:47] <LocutusOfBorg> 4.3.36-dfsg-1+deb8u1ubuntu<IP_ADDRESS>	multiverse	misc	medium	ubuntu-cloud	Proposed	2019-03-11
[10:47] <LocutusOfBorg>
[10:48] <LocutusOfBorg> [Source] virtualbox (source)
[10:48] <LocutusOfBorg> 4.3.40-dfsg-0ubuntu14.04.1	multiverse	misc	medium	ubuntu-cloud	Proposed	2019-03-01
[10:48] <LocutusOfBorg>
[10:48] <LocutusOfBorg> [Source] virtualbox (source)
[10:48] <LocutusOfBorg> 4.3.40-0ubuntu14.04.1	multiverse	misc	medium	ubuntu-cloud	Proposed	2019-01-21
[10:48] <LocutusOfBorg> I rebased the upload on top of the proposed version
[11:26] <doko> apw: please could you look at the linux autopkg test failure triggered by binutils?
[11:40] <doko> vorlon: where did you copy these packages from: android-platform-development android-platform-external-boringssl android-platform-external-libunwind  android-platform-frameworks-native android-platform-system-tools-aidl
[11:42] <doko> these are *not* in the ppa:android-tools for cosmic
[11:44] -queuebot:#ubuntu-release- New source: nvidia-graphics-drivers-418 (disco-proposed/primary) [418.43-0ubuntu1]
[11:45] <doko> vorlon: now removed
[11:45] <doko> apw: ^^^
[12:14] <apw> doko, will get it checked
[12:17] -queuebot:#ubuntu-release- Unapproved: openjfx (cosmic-proposed/universe) [11.0.2+1-1~18.04.2 => 11.0.2+1-1~18.10] (no packageset) (sync)
[12:18] -queuebot:#ubuntu-release- Unapproved: scilab (cosmic-proposed/universe) [6.0.1-7~18.04.1 => 6.0.1-7~18.10] (no packageset) (sync)
[12:20] -queuebot:#ubuntu-release- New sync: equinox-bundles (bionic-proposed/primary) [4.9-2~18.04]
[12:21] -queuebot:#ubuntu-release- Unapproved: accepted openjfx [sync] (cosmic-proposed) [11.0.2+1-1~18.10]
[12:21] -queuebot:#ubuntu-release- New sync: equinox-framework (bionic-proposed/primary) [4.9-1~18.04]
[12:21] -queuebot:#ubuntu-release- New sync: equinox-p2 (bionic-proposed/primary) [4.9-1~18.04]
[12:22] -queuebot:#ubuntu-release- New: accepted equinox-bundles [sync] (bionic-proposed) [4.9-2~18.04]
[12:22] -queuebot:#ubuntu-release- New: accepted equinox-p2 [sync] (bionic-proposed) [4.9-1~18.04]
[12:22] -queuebot:#ubuntu-release- New: accepted equinox-framework [sync] (bionic-proposed) [4.9-1~18.04]
[12:23] -queuebot:#ubuntu-release- Unapproved: accepted scilab [sync] (cosmic-proposed) [6.0.1-7~18.10]
[12:45] <doko> vorlon: also removed apktool and enjarify
[13:12] -queuebot:#ubuntu-release- Unapproved: android-sdk-meta (bionic-proposed/universe) [25.0.0+8 => 25.0.0+10~18.04.2] (no packageset) (sync)
[13:12] -queuebot:#ubuntu-release- Unapproved: android-sdk-meta (cosmic-proposed/universe) [25.0.0+8 => 25.0.0+10~18.04.2] (no packageset) (sync)
[13:14] -queuebot:#ubuntu-release- Unapproved: accepted android-sdk-meta [sync] (cosmic-proposed) [25.0.0+10~18.04.2]
[13:15] -queuebot:#ubuntu-release- Unapproved: accepted android-sdk-meta [sync] (bionic-proposed) [25.0.0+10~18.04.2]
[14:19] <tjaalton> fwupdate is in bionic NEW, could someone ack the packages
[14:20] <seb128> tjaalton, https://launchpad.net/ubuntu/bionic/+queue?queue_state=0&queue_text= is empty?
[14:20] <tjaalton> hmm
[14:21] <tjaalton> binaries
[14:21] <tjaalton> not src
[14:21] <seb128> ah
[14:22] <tjaalton> https://launchpad.net/ubuntu/+source/fwupdate/12-3bionic2
[14:22] <tjaalton> unapproved?
[14:23] <seb128> indeed
[14:24] <seb128> I let it though, I think fwupdate is somewhat special and vorlon had issues with the previous upload
[14:33] <tjaalton> yes, those issues got fixed
[14:43] <apw> bionic2 .... didnt we stop with the names years back
[14:45] -queuebot:#ubuntu-release- New sync: wlroots (disco-proposed/primary) [0.3-1]
[15:07] <vorlon> doko: when yesterday you listed android-tools ppa as one of the ppas to copy from for cosmic, I pointed out that ppa had no packages in cosmic at the time so I would copy forward directly from bionic
[15:17] <doko> hmm, I'm pretty sure I copied everything there, and then removed the ones which were not needed
[15:18] -queuebot:#ubuntu-release- New: accepted wlroots [sync] (disco-proposed) [0.3-1]
[15:20] -queuebot:#ubuntu-release- New binary: wlroots [amd64] (disco-proposed/none) [0.3-1] (no packageset)
[15:20] -queuebot:#ubuntu-release- New binary: wlroots [s390x] (disco-proposed/none) [0.3-1] (no packageset)
[15:21] -queuebot:#ubuntu-release- New binary: wlroots [ppc64el] (disco-proposed/none) [0.3-1] (no packageset)
[15:22] -queuebot:#ubuntu-release- New binary: wlroots [arm64] (disco-proposed/none) [0.3-1] (no packageset)
[15:22] -queuebot:#ubuntu-release- New binary: wlroots [i386] (disco-proposed/none) [0.3-1] (no packageset)
[15:22] -queuebot:#ubuntu-release- New binary: wlroots [armhf] (disco-proposed/none) [0.3-1] (no packageset)
[15:23] <Eickmeyer> Anybody up for looking at carla again now that I fixed its copyright issues? (vorlon, cyphermox)?
[15:24] <mdeslaur> how to I retrigger the ghostscript autopkgtest now that there's a new ocrmypdf version in disco?
[15:27] -queuebot:#ubuntu-release- New: accepted wlroots [amd64] (disco-proposed) [0.3-1]
[15:27] -queuebot:#ubuntu-release- New: accepted wlroots [armhf] (disco-proposed) [0.3-1]
[15:27] -queuebot:#ubuntu-release- New: accepted wlroots [ppc64el] (disco-proposed) [0.3-1]
[15:27] -queuebot:#ubuntu-release- New: accepted wlroots [arm64] (disco-proposed) [0.3-1]
[15:27] -queuebot:#ubuntu-release- New: accepted wlroots [s390x] (disco-proposed) [0.3-1]
[15:27] -queuebot:#ubuntu-release- New: accepted wlroots [i386] (disco-proposed) [0.3-1]
[15:30] -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [amd64] (bionic-proposed) [12-3bionic2]
[15:30] -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [armhf] (bionic-proposed) [12-3bionic2]
[15:30] -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [arm64] (bionic-proposed) [12-3bionic2]
[15:30] -queuebot:#ubuntu-release- Unapproved: accepted fwupdate [i386] (bionic-proposed) [12-3bionic2]
[15:44] <vorlon> Eickmeyer: it needs an archive admin now to review it as it's been reuploaded to the NEW queue (so not cyphermox).  I am not looking at it currently, but it's on my list to come back to; I was currently prioritizing trying to get the image builds working again, since my os-prober fix was ineffective
[15:45] <Eickmeyer> vorlon: Okay, let me know if I need to reinstate that update-grub exists check.
[15:45] <vorlon> Eickmeyer: that won't help.  update-grub DOES exist, and is failing in the livecd-rootfs build environment.
[15:46] <Eickmeyer> vorlon: ack
[15:56] <cyphermox> that would need some livecd-rootfs change (os-prober)
[15:57] <vorlon> cyphermox: that's what I changed and it apparently isn't os-prober that was failing
[15:57] <cyphermox> vorlon: need more eyes?
[15:57] <vorlon> I /assumed/ it was but it's actually failing due to grub-probe
[15:57] <vorlon> (which, granted, was in the error message in the build log)
[15:58] <cyphermox> is it a similar issue to what we've seen in cloud images?
[15:58] <vorlon> so I really don't understand how this has wound up an ubuntustudio-specific problem, I would have expected more things to be calling update-grub before now, and we have no diversions
[15:58] <vorlon> which issue?
[15:58] <cyphermox> some time ago, livecd-rootfs hooks were confusing grub / grub-probe a bit re: UUIDs and whatnot
[15:58] <cyphermox> I haven't looked at the build logs yet
[16:05] -queuebot:#ubuntu-release- Unapproved: systemd (xenial-proposed/main) [229-4ubuntu21.17 => 229-4ubuntu21.18] (core)
[16:07] -queuebot:#ubuntu-release- Unapproved: gvfs (bionic-proposed/main) [1.36.1-0ubuntu1.3 => 1.36.1-0ubuntu1.3.1] (desktop-core)
[16:11] <Eickmeyer> vorlon: If there's anything I can do to help, let me know.
[17:15] <Trevinho> sil2100: hey, maybe you can review this https://code.launchpad.net/~3v1n0/ubuntu-archive-tools/sru-review-bileto-support/+merge/364193 ?
[17:18] <sil2100> Trevinho: hey! I can, yes! But not sure if we actually want this feature ;p
[17:19] <Trevinho> sil2100: well, people is complaining about not being able to review the SRUs quickly... so...
[17:19] <Trevinho> I should have done it probably 3 years ago, but...
[17:20] <sil2100> Well, it's not that we couldn't do it, it's mostly because no one wanted to
[17:20] -queuebot:#ubuntu-release- Unapproved: unity (xenial-proposed/main) [7.4.5+16.04.20180221-0ubuntu1 => 7.4.5+16.04.20190312-0ubuntu1] (ubuntu-desktop) (sync)
[17:21] <sil2100> Thanks for the branch, let me take a look at it and at least do a code-review
[17:22] <Laney> IMO you might as well have it while bileto is still alive, to make the SRU review experience easier - currently those reviews seem to be quite painful
[17:26] <Trevinho> also dont' kill bileto! :)
[17:27] <Trevinho> at least not everything, you can get rid of autopkg stuff, but it makes many things less annoying. So, get rid of what is broken and even a simple way to have a PPA setup and publishing is enough.
[17:27] <Laney> doing that is work in itself, and why would you hate on the testing integration?
[17:27]  * Laney sulks
[17:28] <Trevinho> Laney: I was mentioend that was the part causing troubles.
[17:29] <cjwatson> Landing mvo's command-not-found publisher integration for the primary archive (only >= disco)
[17:30] <cjwatson> I'm just watching a couple of publisher runs to make sure it doesn't break
[17:35] <cjwatson> Hm, not quite right, fixing
[17:46] -queuebot:#ubuntu-release- Unapproved: python-ldappool (cosmic-proposed/universe) [2.2.0-3ubuntu1 => 2.2.0-3ubuntu2] (no packageset)
[17:53] -queuebot:#ubuntu-release- Unapproved: keystone (cosmic-proposed/main) [2:14.0.1-0ubuntu1 => 2:14.0.1-0ubuntu2] (openstack, ubuntu-server)
[18:50] -queuebot:#ubuntu-release- New binary: linux-signed [amd64] (disco-proposed/main) [5.0.0-8.9] (core, kernel)
[18:50] -queuebot:#ubuntu-release- New binary: linux-signed [ppc64el] (disco-proposed/main) [5.0.0-8.9] (core, kernel)
[18:52] -queuebot:#ubuntu-release- New binary: linux-signed [arm64] (disco-proposed/main) [5.0.0-8.9] (core, kernel)
[19:00] -queuebot:#ubuntu-release- New source: intel-mediasdk (disco-proposed/primary) [18.4.1-0ubuntu1]
[20:05] -queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (cosmic-proposed) [5.1.2-4ubuntu1.1]
[20:10] -queuebot:#ubuntu-release- Unapproved: accepted knockd [source] (cosmic-proposed) [0.7-1ubuntu<IP_ADDRESS>]
[20:12] -queuebot:#ubuntu-release- Unapproved: accepted knockd [source] (bionic-proposed) [0.7-1ubuntu<IP_ADDRESS>]
[20:14] -queuebot:#ubuntu-release- Unapproved: accepted autofs [source] (bionic-proposed) [5.1.2-1ubuntu3.1]
[20:40] <vorlon> ddstreet: for awareness: LP: #1819625
[20:41] <vorlon> I've seen a problem myself with DNS on cosmic after upgrade, which I'm working to reproduce under controlled circumstances that don't involve me being locked out of my desktop
[20:42] <ddstreet> vorlon you use resolvconf on cosmic?
[20:42] <vorlon> ddstreet: yes, because I upgrade and dogfood
[20:42] <ddstreet> and it doesn't work?
[20:42] <vorlon> ddstreet: post SRU, it stopped working because all of the upstream DNS servers got blatted into /run/resolvconf/resolv.conf instead of the system pointing at systemd-resolved which dtrt
[20:42] <ddstreet> vorlon to be clear - you use resolvconf but not ifupdown?
[20:43] <vorlon> resolvconf plus NM - this is on my laptop locally
[20:43] <ddstreet> and you can't directly access your upstream ns?  only thru resolved?
[20:44] <ddstreet> anyway, do put more info into the bug when you have time
[20:44] <vorlon> ddstreet: I was on the corporate VPN and the VPN dropped and resolvconf didn't notice
[20:44] <vorlon> yeah I'm going to chase this shortly
[20:44] <ddstreet> ah ok
[21:18] -queuebot:#ubuntu-release- Unapproved: resolvconf (cosmic-proposed/universe) [1.79ubuntu<IP_ADDRESS> => 1.79ubuntu<IP_ADDRESS>] (no packageset)
[21:21] <ddstreet> vorlon if you simply revert it then you place things back into edns0-to-upstream-dns server land, which isn't good either
[21:22] <ddstreet> but of course, your call ;-)
[21:22] <ddstreet> depends on whose dns resolution you want to break
[21:23] <ddstreet> personally, i'd recommend rejecting your revert upload so we can try to figure out what the problem is and fix it
[21:25] <vorlon> ddstreet: https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/1819625/comments/6
[21:25] <vorlon> as far as I'm concerned, the root cause is that we failed to kick resolvconf to the curb prior to 18.04 release
[21:27] <vorlon> and my /run/resolvconf/resolv.conf prior to the SRU did not have the configuration described in 2) of https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1817903 - I have the local stub resolver and not the upstream name servers, which is what we should be aiming for
[21:29] <ddstreet> vorlon well, this is how things worked pre-bionic, with resolvconf you don't get per-interface dns resolution
[21:30] <vorlon> yes, and we switched to resolved in bionic because it was the pre-bionic behavior was broken
[21:30] <ddstreet> it seems, based on my (time-)limited testing, that the problem is resolved doesn't remove nameservers once routes go away
[21:30] <vorlon> that is also a problem
[21:30] <ddstreet> e.g. i connectd to vpn, /run/systemd/resolve/resolv.conf added the vpn nameserver, i disconnected, but it's still there
[21:30] <vorlon> but round-robining the VPN dns servers by exposing them in /etc/resolv.conf is also a problem, and a regression introduced by this SRU
[21:30] <ddstreet> maybe resolved magically knows not to talk to it, but it has to remove it for resolvconf to knwo that and update /etc/resolv.conf
[21:31] <ddstreet> ok...well if you're rejecting the pre-bionic behavior of resolvconf, then we'll have to figure out a better way to have it use resolved than pull the stub-resolver
[21:32] <ddstreet> because in that case, with ifupdown/resolvconf and systemd now including edns0, dns will definitely break unless all nameservers in the world start supporting edns0
[21:33] <ddstreet> we could revert systemd including edns0 but that breaks from upstream, and we would then need to backport systemd resolved tcp pipelining from upstream, which is significantly more headache
[21:33] <ddstreet> anyway, it's complex
[21:33] -queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (cosmic-proposed) [1.79ubuntu<IP_ADDRESS>]
[21:33] <ddstreet> go for the revert if you think that's best - once it's changed, i'll figure out how to best fix the entire situation (since it's still broken, but now just for other people)
[21:35] <ddstreet> vorlon you may want to note in lp #1817903 that everyone affected will see breakage again with your reversion
[21:37] <vorlon> ddstreet: xnox has some ideas about a proper fix
[21:38] <xnox> ddstreet, hey
[21:38] <xnox> ddstreet, let's use this channel.
[21:39] <xnox> ddstreet, switching from stub-resolv.conf to resolv.conf is broken and should not have been ever done. As we have created stub-resolv.conf to specifically address integration on ubuntu, we want to use resolved's resolver all the time, as that's the only way to get correct split dns resolution.
[21:39] <xnox> ddstreet, i do understand that options ends0 (with the systemd's sru) started to leak into /etc/resolv.conf with unintended consequences.
[21:39] <xnox> ddstreet, the answer to that is to filter that option out as in:
[21:39] <xnox> i was expecting to diff be:
[21:40] <xnox> -ExecStart=+-/bin/sh -c 'cat /run/systemd/resolve/stub-resolv.conf | /sbin/resolvconf -a systemd-resolved'
[21:40] <xnox> +ExecStart=+-/bin/sh -c 'cat /run/systemd/resolve/stub-resolv.conf | grep -v edns0 | /sbin/resolvconf -a systemd-resolved'
[21:40] <ddstreet> xnox er, without edns0, the bug *that* fixed isn't fixed at all
[21:40] <ddstreet> so people iwth resolvconf installed shouldn't get that fix?
[21:40] <xnox> ddstreet, now that is sort of a majority fix, as we do kind of need ends0 when talking to resolved, but that's life for those that upgrade to bionic.
[21:40] <xnox> ddstreet, yes.
[21:41] <ddstreet> er...
[21:41] <ddstreet> ok...
[21:41] -queuebot:#ubuntu-release- Unapproved: resolvconf (bionic-proposed/universe) [1.79ubuntu<IP_ADDRESS> => 1.79ubuntu<IP_ADDRESS>] (no packageset)
[21:41] <xnox> ddstreet, now to fix this further, for everyone. we would need to reverse the flow of nameservers.
[21:41] <xnox> ddstreet, instead of adding resolved' to resolvconf, we'd need to feed all the resolvconf entries into resolved.
[21:41] <ddstreet> xnox so systems with resolvconf should definitely *not* be able to successfuly resolve dns if the reply is > 512 bytes?
[21:42] <xnox> ddstreet, they will over TCP, won't they?
[21:42] <xnox> ddstreet, you did SRU back listing on TCP, in addition to UDP?
[21:42] <ddstreet> hopefully!  that was the entire problem tho
[21:42] <xnox> *listening
[21:42] <ddstreet> no i didn't backport tcp pipelining
[21:42] <xnox> ddstreet, i just don't understand how you tested http://launchpadlibrarian.net/413182599/resolvconf_1.79ubuntu10_1.79ubuntu<IP_ADDRESS>.diff.gz this
[21:43] <xnox> ddstreet, and why did you think that switching to raw nameservers would ever work, when ubuntu has never used those, in any of the releases.
[21:43] <xnox> ddstreet, that's not a cherrypick from any release, is it?
[21:43] <ddstreet> xnox that's how things were x and earlier
[21:43] <ddstreet> with ifupdown/resolvconf
[21:43] <xnox> ddstreet, which didn't have resolved by default.
[21:43] <ddstreet> right...
[21:43] <xnox> ddstreet, and also broken.
[21:43] <xnox> (differently)
[21:43] <ddstreet> what, x and earlier were broken?
[21:44] <vorlon> yes
[21:44] <xnox> it leaked dns, failed at split-dns, etc.
[21:44] <ddstreet> ok :)
[21:44] <xnox> all the things that were fixed in bionic.
[21:44] <vorlon> we introduced systemd-resolved by design to fix architecture issues
[21:44] <xnox> and now regressed.
[21:44] -queuebot:#ubuntu-release- Unapproved: accepted resolvconf [source] (bionic-proposed) [1.79ubuntu<IP_ADDRESS>]
[21:44] <xnox> not just systemd-resolved, but stub-resolv.conf usage of systemd-resolved.
[21:45]  * vorlon nods
[21:45] <ddstreet> got it.  so b+ should *always* use resolved under all circumstances, period.
[21:45] <xnox> ddstreet, note that people who have resolvconf installed on bionic; are upgrade peopel; and i'm ok with keeping them not as good as default install of bionic with resolved.
[21:45] <ddstreet> well, except with ifupdown
[21:45] <xnox> or upgraders
[21:45] <xnox> (from ifupdown)
[21:45] <ddstreet> xnox note that default installers of bionic don't get resolvconf
[21:45] <ddstreet> ;-)
[21:45] <vorlon> right
[21:46] <xnox> hence it's ok to keep them without options ends0
[21:46] <vorlon> and without resolvconf, things work better
[21:46] <ddstreet> i will say that upgraders from xenial are likely a large number of users
[21:46] <ddstreet> and that's *future* upgraders too - lots still on t/x
[21:46] <xnox> ddstreet, that's subjective of the users you are exposed to ;-)
[21:46] <vorlon> yeah; and I think xnox's | grep -v edns0 helps there
[21:46] <ddstreet> yep, we can do that
[21:46] <ddstreet> hopefully upstream nameservers will behave better than resolved-stub
[21:47] <xnox> ddstreet, long term solution is to remove resolvconf from the archive, and make systemd provide /sbin/resolvconf that feeds into resolved (most things)
[21:47] <ddstreet> (probably they will, i think dnsmasq and bind handle tcp pipelining ok, but i haven't specificalyl checked)
[21:47] <xnox> ddstreet, then we can finally put all of the mess behind us.
[21:47] <ddstreet> xnox yep i look forward to that day in 2050 xD
[21:47] <xnox> ddstreet, it's usually the crappy home router between machine and the real internet that is shit.
[21:48] <ddstreet> so xnox you want to update resolvconf with grep -v edns0, or should i?  or vorlon?
[21:48] <xnox> ddstreet, vast majority of our users are fresh launches of cloud-images/containers btw ;-)
[21:49] <xnox> irrespective of the bug volumes that we see.
[21:49] <ddstreet> also one additional thought for vorlon - x upgraders who still use ifupdown with dhcp (and resolvconf), will have upstream nameservers in /etc/resolv.conf
[21:50] <xnox> ddstreet, no.
[21:50] <xnox> ddstreet, dhcp from ifupdown feeds into resolved via my resolved hook to isc-dhcp
[21:50] <xnox> ddstreet, and feeds nothing into resolvconf
[21:50] <ddstreet> ah right, resolved is lexically after resolvconf
[21:50] <ddstreet> i'm thinking of ifupdown static ip/dns
[21:50] <xnox> static bits feed into resolv.conf
[21:51] <ddstreet> that is what gets into /etc/resolv.conf via the /etc/network/if-up.d/resolvconf script
[21:51] <vorlon> yes; this is still broken
[21:51] <vorlon> but we need to fix that local bug locally, not revert the architecture
[21:51] <ddstreet> ok, as long as you're aware it's broken :)
[21:51] <xnox> oh yes we are.
[21:51] <ddstreet> well remove/fix the if-up script, shoudl be easy.
[21:52] <ddstreet> xnox re: majority of our users, that's probably true, tho not with UA, but that's not really imporant
[21:53] <ddstreet> xnox so should i update and reupload resolvconf with the grep -v?
[21:53] <ddstreet> not sure if you or vorlon are doing it now
[21:53] <vorlon> not me
[21:54] <vorlon> I'm doing a straight revert which is under my SRU team purview
[21:54] <ddstreet> xnox also while i have you, there's a bug where dhcp doesn't work for bionic+ guests inside libguestfs because dhcp calls the systemd hook, and systemd isn't init in the libguestfs appliance :(  not sure if you have any quick thoughts on that
[21:55] <ddstreet> vorlon ack i'll do a follow up to add grep per xnox's comment above
[21:55] <xnox> vorlon, ddstreet - we can do more heuristics, like if there are no nameservers apart from the stub-resolver in the end, we can append the ends0 option back in safely.
[21:55] <ddstreet> vorlon do you want me to wait for your revert to get to -updates or just upload when i have it ready
[21:55] <vorlon> ddstreet: feel free to upload when ready
[21:55] <vorlon> I'll make sure the revert gets published first regardless
[21:55] <ddstreet> thnx will do (probably tomrorow, it's late here)
[21:55] <xnox> vorlon, ddstreet - cause that should be another common case with ifupdown+dhcp+resolvconf+resolved
[23:38] <Ukikie> I hear in order for other things to get past -proposed golang-golang-x-sys needs hinting.


[04:36] <davido_> I need to file a bug report regarding a TB3 issue, but I'm not sure what information to provide. Since upgrading to 20.10 the Lenovo X1 carbon, 6th gen exhibits bad behavior with the lenovo tb3 dock; the dock's NIC drops out, the /var/log/syslog shows constant polling against the nic, and bringing the laptop back from a screen lock can take up to three minutes just to get the password
[04:37] <davido_> prompt. Without the dock, no problem. Same laptop running 20.04, no problem. Same laptop running centos7, no problem.
[09:06] <apw> Eickmeyer[m], it looks like the chatter on the bug say this is actually fixed in the already prepared -proposed kernel
[16:08] <Eickmeyer[m]> apw: Yeah, saw that. Thanks! :)


[17:14] <AlanBell> charlie-tca: Bug #828356
[17:14] <ubot2> Launchpad bug 828356 in libunity "Support X-GNOME-Keywords" [High,Fix released] https://launchpad.net/bugs/828356
[17:15] <charlie-tca> Thanks
[17:16] <charlie-tca> Added to my tracking list
[17:38] <AlanBell> it is fix released
[17:39] <charlie-tca> Got an item for P-series though
[17:39] <AlanBell> and that is the one about searching for "accessibility" in the dash, it should now find it
[17:39] <charlie-tca> Maybe to insure it doesn't get broken for the LTS?
[17:39] <charlie-tca> Oh, good!
[17:39] <AlanBell> hmm, invalid for p-series
[17:40] <AlanBell> oh, in for unity-lens-applications for p-series. I think that is a mistake
[17:52] <AlanBell> bug 851694 remains the biggie, and didrocks is on the case of what is apparently the root cause
[17:52] <ubot2> Launchpad bug 851694 in unity-2d "application icons in apps lens are all called "button" (dup-of: 854516)" [Undecided,Confirmed] https://launchpad.net/bugs/851694
[17:52] <ubot2> Launchpad bug 854516 in unity-2d "[launcher] LauncherItem's accessibilityName is only evaluated on runtime" [High,In progress] https://launchpad.net/bugs/854516
[17:58] <charlie-tca> Okay, and ev said the change to names in ubiquity was pushed, but the build failed and they are working on it
[17:59] <AlanBell> ok, I think we can be fairly sure that they will get ubiquity to build before release :)
[18:00] <charlie-tca> yup, I just want to make sure the names got fixed in it
[18:36] <maco> AlanBell: skaet put it in for both O and P in case unity folks were too busy fixing crashers to fix in O then itd be deferred to P. since didier got to it in O, its invalid for P (since now its fixed already)
[18:36] <maco> charlie-tca: they arent necessarily *fixed* exactly...theyre just not variable names anymore. real usable names probably need to be set manually though
[18:37] <maco> hmm unless i can figure a way to make add_widget set accessible_name = the text of the label...
[18:37] <charlie-tca> Okay, Thanks for explaining that, maco
[18:37] <maco> tbh, im not sure whats going to happen with translations for them if they have to be set manually :-/
[18:38] <charlie-tca> valid point
[20:05] <charlie-tca> bug 855123 seems to be gaining in popularity
[20:05] <ubot2> Launchpad bug 855123 in at-spi2-core "at-spi2-registryd crashed with signal 5 in g_type_create_instance()" [Medium,Triaged] https://launchpad.net/bugs/855123
[20:06] <charlie-tca> I don't see what effect it has, other than at-spi2 crashes
[22:59] <AlanBell> charlie-tca: Pendulum: DBO just told me that onboard can now type into the unity 3d dash, they got it in just before final freeze
[23:00] <charlie-tca> That's great!
[23:02] <AlanBell> bug 854516 seems like they have the code that will hopefully do it (orca not reading the 2d dash right) hope that makes the freeze or is an exception
[23:02] <ubot2> Launchpad bug 854516 in unity-2d "[launcher] LauncherItem's accessibilityName is only evaluated on runtime" [High,In progress] https://launchpad.net/bugs/854516
[23:03] <AlanBell> and the patch for orca reading the 3d dash didn't make feature freeze, but will be packaged as a PPA so we can test during the cycle
[23:06] <charlie-tca> They could ask for FFe for orca. They do it for anything the normal person needs. One more symptom of the lowered importance for a11y
[23:07] <Fudge> busy busy guys
[23:15] <pleia2> wow, Fix Committed for bug 739812
[23:15] <ubot2> Launchpad bug 739812 in unity "Must use hardware keyboard to perform search for applications in Unity" [High,Fix committed] https://launchpad.net/bugs/739812


[02:21] <Zanehood_> Can I please ask for some help
[02:21] <Zanehood_> Is anyone available?
[02:32] <Zane> Hey I can only boot my ubuntu laptop up with running generic mode
[02:32] <Zane> any idea as to why?
[02:32] <Zane> if i let it run normally the screen gets static all over the screen once i log on and i can not see anythingf
[05:17] <mapps> morning
[07:08] <popey> http://www.jonobacon.org/2014/05/19/goodbye-canonical-hello-xprize/
[07:08] <MartijnVdS> end of an era
[07:08] <popey> ya
[07:08] <nigelb> wow.
[07:15] <ali1234> popey for new community manager?
[07:16] <MartijnVdS> he doesn't say 'community' nearly enough
[07:17] <popey> Yeah, I don't have that skill on my CV
[07:18] <MartijnVdS> popey: can you say "community?
[07:18] <MartijnVdS> "
[07:20] <nigelb> popey: Did Ahmed leave Canonical or is he working on something else?
[07:20] <popey> he left years ago
[07:20] <popey> he wasn't at the company long
[07:21] <nigelb> ahh
[07:21] <nigelb> and jcastro, I guess is doing Juju stuff?
[07:21] <jussi> ACHMED...Silence... err, wait, thats something else :P
[07:22] <jussi> actually, I could so see that...
[07:23] <popey> yeah, jorge is rocking juju
[07:23] <nigelb> :)
[07:23] <jussi> Im calling Mark, to put in my recommendation for popey to be new community manager
[07:24] <nigelb> he'll shut everything down! (sorry popey :P)
[07:27] <jussi> alternately we could have AlanBell as community manager, and everything would have a hencam theme :P
[07:31] <SuperMatt> I'll do it
[07:32] <jussi> SuperMatt: what would your "signature" be? :D
[07:33] <SuperMatt> how do you mean?
[07:33] <SuperMatt> do I have to have hen webcams?
[07:34] <jussi> SuperMatt: no, you need to have $your_thing
[07:34] <jussi> or else you are boring!
[07:35] <SuperMatt> I dance a lot
[07:35] <SuperMatt> is that enough?
[07:38] <jussi> SuperMatt... the dancing community manager! :D
[07:39] <diplo> Morning all
[07:42] <SuperMatt> jussi: I'm not going to be dancing around for the enjoyment of the community
[07:42] <jussi> SuperMatt: you just lost the job...
[07:42] <jussi> :P
[07:43] <SuperMatt> nooooooo
[07:47] <TwistedLucidity> jussi: Ooh, I'd love to see the changelog expressed an interpretive dance.
[07:48] <TwistedLucidity> Aaaaaaand DuckDuckGo re-skinned themselves to look like Windows 8. :-(
[07:48] <TwistedLucidity> Just like KDE
[07:48] <TwistedLucidity> :-((
[07:51] <jussi> yay, yesterday's pizza for lunch
[07:53] <jussi> TwistedLucidity: that could be fun...
[07:53] <jussi> a very different changelog
[08:53] <TwistedLucidity> Pet Peeve #6984: Software that won't work unless the keyboard and regional settings are US English.
[08:54] <TwistedLucidity> Pet Peeve #6985: Server software that requires the server to run X in order to go through installations.
[08:55] <MartijnVdS> .. Oracle?
[08:55] <TwistedLucidity> Close, but not the one I was thinking of
[08:57] <TwistedLucidity> Pet Peeve #1432: Software which requires authentication/licensing before it can be used for more than a trial period (despite us being partners with the vendor)
[08:57] <TwistedLucidity> Pet Peeve #1433: People who consistently forget #1432 when creating VMs and then wonder why things don't work a year later.
[09:00] <MartijnVdS> they're like the Rules of Acquisition
[09:00] <MartijnVdS> but for sysadmins
[09:05] <awilkins> #1434: Software that requires online authentication with a limited number of activations per license, but no sunset date on those activations. Chance of hitting the activation limit for a given user after years of Windows reinstalls = ~ 100%
[09:06] <MartijnVdS> DRM F yeah!
[09:07] <awilkins> #1435: When a third party buys the company who controls the activation server for your software but doesn't carry over the accounts from their support system so you have to navigate the maze of support yet again.
[09:07] <MartijnVdS> at least we don't have dongles anymore.. right?
[09:08] <awilkins> #1436: When you have to develop against the API for a piece of software but they've run an obfuscator over most of it so you are confronted with things like Class A with method b()
[09:08] <awilkins> You might think all three of those apply to the same piece of software, I couldn't possibly comment.
[09:08] <awilkins> People still do dongles
[09:09] <jussi> yeah, ive seen those. CAD software is really bad for dongles
[09:10] <MartijnVdS> awilkins: at least they're not parallel-port ones anymore I hope?
[09:12] <awilkins> MartijnVdS, You can still <get> them : http://www.keylok.com/products
[09:14] <awilkins> The "Fortress" model sounds like the only one worth using
[09:14] <awilkins> It's the one that runs application code on a secure processor in the dongle
[09:25] <TwistedLucidity> awilkins: #1436 should be a non-issue, the API docs should suffice. LOL!  My wife & her mum do something similar either crochet or knitting and stitch them together to make baby blankets, they've done so much of it their fingers & hands are knackered
[11:31] <Myrtti> DJones: I don't do that much crochet, and I knit Continental style. continental is quicker and easier on hands than the english method
[11:32] <Myrtti> someone even recommended it to people with arthritis, but I don't know if it really is better, but I assume it is
[11:32] <DJones> I'll have to suggest that to them
[11:34] <Myrtti> https://www.youtube.com/watch?v=XuRLFl36tDY
[11:34] <DJones> Knowing how long they spend making squares, i'm impressed with number you've done
[11:35] <DJones> More so if you've spun the the wool as well
[11:35] <Myrtti> granny squares are so easy to make it took me about three nights to do those
[11:36] <Myrtti> had to order more wool though, I can't finish these with the yarn I've got
[11:36] <DJones> Sheesh, thats quick
[11:38] <Myrtti> the purling is taught totally weirdly on that video
[11:43] <diplo> I've written a backup script in python, works fairly well.. mounts a usb drive, copies files from src to dest in <day>/srcdir/files etc
[11:43] <diplo> Always has run as root
[11:43] <diplo> I've been asked to be able to manually run it
[11:43] <diplo> as a standard user
[11:44] <diplo> Thus I'm guessing using sudoers to allow them to do things
[11:44] <diplo> Set NOPASSWD should stop prompt of password if my script does sudo python  path/to/script
[11:44] <diplo> ?
[11:45] <diplo> I've never played with sudo and it seems straight forward but still getting prompted for password
[11:47] <Myrtti> that sounds like a road to hell, is it for personal/family use or something more nefarious?
[11:48] <diplo> Work, very old systems
[11:48] <diplo> Basically want to backup cisam db to usb drive before running updates
[11:48] <diplo> Customer wants to back up himself to save calling
[11:48] <diplo> Open to any other ways of doing it :)
[11:52] <awilkins> setuid
[11:53] <awilkins> But very evil
[11:53] <awilkins> But less evil that sudo with no passwd
[11:56] <Myrtti> indeed
[11:56] <awilkins> Hang on, c-isam DB?
[11:56] <awilkins> Does the DB process have access? Is it root?
[12:03] <Myrtti> I tried to make a video of how fast I crochet but I couldn't keep the camera steady enough under my chin :-(
[12:05] <diplo> cisam db, but it needs to be run as a user awilkins
[12:05] <diplo> Basically need to mount a usb drive and create/delete directories
[12:05] <awilkins> Does the DB have a "dump" utility or are you backing up the raw storage files?
[12:06] <awilkins> Or are the elevated permissions more about mounting a USB drive than accessing the data?
[12:06] <diplo> Raw storage files
[12:07] <diplo> Yeah it's about mounting/creating dirs/ deleting dirs
[12:08] <diplo> And no dump util, very old version.. all we do is install drivers and thats it
[12:08] <awilkins> So.. should be able to stick the volume you are mounting to into /etc/fstab with option noauto
[12:09] <diplo> I have debated doing that, but the only downside is the customer has 6 seperate drives so I guess I'd just have to stick all five UUID's in
[12:11] <awilkins> no FUSE for this system?
[12:12] <diplo> yeah should have thought so, am I overthinking stuff ? :)
[12:13] <awilkins> Dunno, I have root on everything I use so I just use sudo :-)
[12:13] <diplo> I do normally, my colleages have implemented this all over ( I don't think it has worked on any site and they haven't checked I'm guessing )
[12:14] <diplo> As the script runs as root normally they just expected it to work, I looked at one of the sites this morning and asked how do you expect this to work
[12:14] <awilkins> Any backup is only as successful as your last restore
[12:14] <diplo> "Dunno, just thought it would"
[12:14] <diplo> awilkins, exactly what I've been trying to say to them
[12:43] <MooDoo> howdy all
[12:43] <MartijnVdS>  \o
[12:44] <MooDoo> Just read about Jono....wow ace move
[12:46] <MooDoo> wonder if they will have another UCM?
[12:54] <DJones> I nominate MooDoo a UCM
[12:54] <DJones> Or maybe cz[Tab]
[12:56] <MooDoo> DJones: don't be silly :)
[12:57] <MooDoo> DJones: now jono has left, I've installed fedora ;) lol
[12:57] <DJones> Heh
[13:00]  * davmor2 slaps MooDoo till he reinstalls Ubuntu that or windows as he knows that is really MooDoo 's favourite distro
[13:02] <awilkins> Whoa, http://www.muktware.com/2014/02/valve-offers-free-games-ubuntu-developers/20827 : (found that in the hops away from the Jono Bacon article)
[13:02] <awilkins> Wonder if a couple of patches in Bazaar counts :-P
[13:03] <awilkins>  Bah, "people who can upload to Ubuntu central archive"
[13:03] <MooDoo> davmor2: sir, don't be silly DOS is my fave distro :p
[13:04] <awilkins> CP/M is my favourite distro!
[13:04] <awilkins> The Epson PX-8 is my favourite laptop that runs my favourite distro
[15:19] <ali1234> question: if a colo company goes bust with my hardware, what can i do?
[15:21] <awilkins> Take it back? Not like they own it, they are just renting it a rack
[15:21] <ali1234> how?
[15:21] <awilkins> I presume you could send someone round to collect it
[15:21] <awilkins> Or go around yourself
[15:22] <awilkins> Baliff?
[15:22] <ali1234> yeah so i go to the datacenter and say "hi, i'm a customer of this hosting provider that no longer exists. please let me in to collect my stuff"?
[15:23] <awilkins> You can't be the only person to be doing it
[15:23] <ali1234> we don't even know what data center it is in
[15:23] <ali1234> the company has completely cut off all contact
[15:23] <awilkins> That makes things somewhat more awkward
[15:24] <awilkins> This a UK company?
[15:24] <ali1234> yes
[15:24] <awilkins> So they hold data on where your hardware is located, so under the data protection act you are entitled to know that stuff
[15:25] <TwistedLucidity> ali1234: Contact the receivers
[15:26] <ali1234> here's the twist: they went bankrupt 2 years ago
[15:26] <ali1234> the server was sitting in the data center for 2 years
[15:26] <ali1234> the first we found out about it was a week ago when it went offline
[15:34] <Myrtti> wow
[15:34] <Myrtti> that's harsh
[15:45] <SuperEngineer> hmmm... htop gave me an "uptime" of just under 4 days. considering I turned the pooter off last night that might just make me more of Dr. Who than Dr. Who.
[15:45] <SuperEngineer> [following a full bleachbit & restart - it is now accurate....  double hmmmm
[15:46] <awilkins> Maybe the CMOS clock was empty
[15:46] <awilkins> Or slow
[15:48] <SuperEngineer> awilkins: so sys time is correct but it got lazz overnight?  darn! remid me to put more petrol in it next time ;)
[15:48] <SuperEngineer> lazz=lazy
[16:46] <dvrr> how to configure ldap+samba windows client centos 6.x   please help me
[16:47] <daftykins> we don't support CentOS.
[16:47] <daftykins> the clue's in the topic and channel name
[16:51] <dvrr> in ubuntu 12.10  please guide me
[16:51] <daftykins> 12.10 is EOL
[16:52] <daftykins> !eol
[16:53] <diddledan_> bbl
[16:58] <dvrr> i updated all packages
[17:00] <dvrr> daftykins:
[17:00] <daftykins> dvrr: 12.10 is EOL, you'll need to be running 12.04.4, 13.10 or 14.04
[17:04] <TwistedLucidity> dvvr: "sudo apt-get do-release-upgrade" and get on to 13.10 or 14.04
[17:05] <TwistedLucidity> Then worry about ldap+samba
[17:05] <TwistedLucidity> If this is a server, I don't think the "official" server version (14.04.1) is out yet.
[17:05] <TwistedLucidity> Someone please correct me if I'm wrong
[17:05] <daftykins> 14.04 server is still server, .1 is just the first release update
[17:06] <daftykins> that's just the point when LTS -> LTS upgrade becomes available
[17:06] <TwistedLucidity> Yeah, that's what I meant
[17:06] <TwistedLucidity> daftykins: Thanks for making it clear
[17:06] <daftykins> np :)
[17:08] <dvrr> thank you very much given support i will do now
[17:19] <Myrtti> awwwww kittens
[17:19] <Myrtti> http://new.livestream.com/tinykittens/dancing
[17:22] <daftykins> zomg
[17:25] <daftykins> omw, a minimal 14.04 install uses 933MB disk space
[17:25] <daftykins> what's going on with that?!
[17:28] <daftykins> Myrtti: heh mama kitty's face when one of them started climbing over her
[17:28] <daftykins> "WAT!"
[17:49] <diddledan> morning
[17:52] <daftykins> diddledan: o/
[17:52] <daftykins> diddledan: https://www.dropbox.com/s/mns8dwhrj0w6e3g/IMG_20140520_183905.jpg
[17:53] <diddledan> yummy
[17:54] <daftykins> :D
[17:56] <diddledan> that tiny kittens is compulsive
[18:01] <MartijnVdS> hey man thanks for defining the word “many” for me. it means a lot
[18:02] <daftykins> err
[18:02] <daftykins> MartijnVdS: hmm? :)
[18:02] <MartijnVdS> daftykins: read it again
[18:02] <MartijnVdS> slowly
[18:02] <daftykins> nope, drawing a blank
[18:02] <MartijnVdS> what does 'many' mean?
[18:03] <daftykins> more than one
[18:03] <MartijnVdS> or.. "a lot"
[18:03] <daftykins> yeah still fails with me out of context as it is :(
[18:03] <MartijnVdS> it's a joke, there is no context?
[18:03] <diddledan> I think it's self-contained
[18:04] <diddledan> it means a lot vs it means "a lot"
[18:04] <daftykins> diddledan: you need to weigh-in in #ubuntu, there are guys talking about gentoo being great for servers ;)
[18:05] <diddledan> ooh
[18:05] <daftykins> well they actually stopped thankfully
[18:05] <MartijnVdS> weirdos
[18:05] <daftykins> as it's off topic
[18:05] <diddledan> aww I misseded it
[18:06] <ali1234> yeah so apparently this server is now co-located in the cloud :(
[18:06] <diddledan> ali1234, :-(
[18:06] <MartijnVdS> so.. it went to heaven?
[18:06] <diddledan> ali1234, do you at least have any backups?
[18:06] <ali1234> MartijnVdS: exactly
[18:07] <ali1234> diddledan: it was a google mini, there's nothing to back up, it just indexes another server
[18:07] <diddledan> totally sucks that the colo co didn't even tell you they were shutting shop
[18:08] <ali1234> well they didn't have to
[18:08] <ali1234> see, the thing is...
[18:08] <ali1234> there's the web dev company, the colo company, and the data center
[18:08] <ali1234> the web devs had a contract to host the mini at the data center
[18:09] <ali1234> the web devs knew that the colo company was shutting down but didn't do anything
[18:09] <diddledan> >.<
[18:09] <ali1234> so apparently last week the datacenter did some kind of audit and found a server that nobody was paying for
[18:09] <ali1234> and then disconnected it
[18:09] <ali1234> but we don't even know which datacenter is it in
[18:10] <daftykins> damn
[18:10] <directhex> IP?
[18:10] <ali1234> directhex: pm'd
[18:13] <directhex> alentus?
[18:13] <ali1234> right, that's the colo company which seems to no longer be trading
[18:14] <directhex> hm, they have(had?) 8 different colo sites
[18:14] <directhex> more than
[18:17] <ali1234> the IP is now pointing at a different server, which is really weird
[18:17] <ali1234> and the UK subsidiary appears to have done a runner and is now just an unmaintained website and a telephone answering service that goes nowhere
[18:29] <shauno> so we can expect to find a cheap google mini on ebay?
[18:30] <ali1234> probably
[19:33] <daftykins> ooh my
[19:34] <daftykins> i could buy 8GB DDR3 1600, a haswell i3-4130 and an Asus H81-M motherboard for £142.48
[20:53] <diddledan> http://www.youtube.com/watch?v=6lVH3ogPE0w
[23:34] <lazarus_> what is the correct way to use zenity --progress because i dont think im doing it right unless you assign the % values manually which isnt accurate


[10:34] <shazzr> is there a CD-iso available for Edubuntu, or do we have to use the DVD-iso?
[10:46] <alkisg> DVD. Or install the edubuntu package over a plain ubuntu (CD) installation
[19:36] <highvoltage> stgraber: so... will we release that image you tested as edubuntu α1?
[19:59] <stgraber> highvoltage: yes, it's been approved for alpha1


[06:12] <tjaalton> RAOF: I'm prepping xserver 1.20 for a ppa upload, and dropped xmir as IIRC we discussed
[06:14] <RAOF> tjaalton: Rad. Make it so!
[06:14] <tjaalton> :)
[06:15] <tjaalton> I also need to worry about 16.04.5 and 18.04.1, and wondering if mesa 18.0.x can be backported but so that upgrades to 18.04 with glvnd still works.. safest would be not to backport
[06:34] <RAOF> The glvnd transition seems a pretty risky backport :)
[06:35] <tjaalton> well I'd just merge 18.0.x with the old packaging and not backport glvnd, but right now things depend on package Breaks/Replaces to work on upgrade, and those would need to be bumped in lockstep
[06:37] <tjaalton> hum, maybe get last 18.0.x in bionic and bump B/R on libglvnd, then push new mesa with slightly older pkg version to xenial.. could work
[08:56] <tjaalton> RAOF: btw, is mir from bionic getting backported to xenial? if not, I wouldn't be able to drop the mir bits from mesa for a backport
[09:07] <tjaalton> hmm looks like they were there still when 18.0.0 was started, should probably still work
[10:07] <tjaalton> tseliot: can you think of issues if the bionic xserver is backported to xenial as-is?
[10:07] <tjaalton> for .5 hwe refresh
[10:10] <tseliot> tjaalton: I think you dropped some patches in bionic
[10:10] <tjaalton> because they became obsolete
[10:11] <tjaalton> so maybe revert the patch changes, including adding outputclass support?
[10:13] <tseliot> outputclass would actually help
[10:13] <tjaalton> would you need to change all the drivers then?
[10:13] <tjaalton> nvidia-*
[10:14] <tseliot> I am going to either way, but things aren't that clear yet
[10:15] <tjaalton> ok, I'll push stuff to the staging ppa first anyway
[10:15] <tseliot> sounds good
[10:28] <RAOF> tjaalton: We continue to use Mir-trunk on xenial, but we don't use the hwe stack there anyway!
[10:29] <tjaalton> RAOF: ah.. well mesa isn't renamed so you'd get the backport anyway ;)
[10:29] <tjaalton> but that's fine, once this is ready on a ppa I'll give you a shout to give it a go
[10:29] <tjaalton> should work
[11:05] <tseliot> tjaalton: are we getting mesa with or without GLVND in xenial?
[11:06] <tjaalton> tseliot: without
[11:06] <tseliot> ok