[00:00] -queuebot:#ubuntu-release- Unapproved: accepted imagemagick [source] (zesty-proposed) [8:6.9.7.4+dfsg-2ubuntu3]
[00:06] <slangasek> tumbleweed: it seems you uploaded an SRU of pollinate to trusty 71 days ago which references a wrong bug number in the changelog... I guess arges overlooked the wrong bug number in the trusty upload since yakkety and xenial were fine.  I'm going to remove-package it now and either you or I can reupload (1656484 vs. 1456484)
[00:08] <slangasek> tumbleweed: hmm nevermind I'll just reupload, it's not worth the mental effort /not/ to ;P
[00:21] <slangasek> cyphermox: do you recall where things were left with golang-go.crypto and LP: #1634609?  Did you try to rebuild the revdeps?
[00:26] <slangasek> mm. where does the blacklist of xenial/s390x/akonadi live, given that it does not appear to be in lp:~ubuntu-release/+git/autopkgtest-cloud ?
[00:27] <slangasek> it is... outside the VCS on wendigo
[00:30] <slangasek> Laney: ^^ do you know why the s390x worker.conf isn't in the VCS?
[00:37] <tumbleweed> slangasek: err, yeah, sorry I know I left some SRUs hanging
[01:25] <cyphermox> slangasek: not done yet, xenial's crypto in proposed doesn't need to build revdeps (but I had tried some, things were building properly). In yakkety, we removed crypto because it broke other things, plus it needed the rebuilding of half the golang world; if we still want to go with the SRU it would need to be started again
[02:27] <handsome_feng> Hi, could someone in archive admin team apporve the ubuntukylin-theme and ubuntukylin-wallpapers? It's just some updates of theme and wallpapers, Thanks!
[03:17] <slangasek> cyphermox: why do you say we don't need to rebuild revdeps for xenial?  nothing in the SRU bug says there is a different test case here for xenial than yakkety
[03:30] -queuebot:#ubuntu-release- Unapproved: showq (zesty-proposed/universe) [0.4.1+git20161215~dfsg0-2 => 0.4.1+git20161215~dfsg0-2ubuntu1] (no packageset)
[03:31] -queuebot:#ubuntu-release- Unapproved: accepted showq [source] (zesty-proposed) [0.4.1+git20161215~dfsg0-2ubuntu1]
[04:48] <tjaalton> infinity: so, what's the verdict on xserver? i'd like to have some time to react in case there are some bugs actual users would hit
[04:54] -queuebot:#ubuntu-release- Unapproved: pollinate (trusty-proposed/main) [4.23-0ubuntu1~14.04 => 4.23-0ubuntu1~14.04.2] (no packageset)
[05:14] <slangasek> apw, cpaelzer: libvirt 2.1.0-1ubuntu9.3 was accepted into yakkety-proposed built with a wrong -v option; the change from 2.1.0-1ubuntu9.2 is not linked from the .changes file and no one has verified this bug.  This should really get reuploaded with a bumped version number and a fixed .changes file
[05:14] <slangasek> that bug is LP: #1672367
[05:14] <apw> slangasek, bah did i do that, bad on me
[05:15] <slangasek> apw: oh - no, you didn't, you accepted nova and arges accepted libvirt
[05:15] <apw> well i will take it as a timely reminder to check because it creates work none the less
[05:15] <slangasek> :)
[05:16] <slangasek> cpaelzer: also the test case in the description of LP: #1665698 (the bug that is linked) makes no sense to me, so I'm not sure how jamespage verified it...
[05:16]  * slangasek highlights all the people
[05:24] -queuebot:#ubuntu-release- Unapproved: accepted pollinate [source] (trusty-proposed) [4.23-0ubuntu1~14.04.2]
[05:37] <cpaelzer> slangasek: apw: trying to sort out what you mean there - is the -v something I forgot or something that was missed when accepting it?
[05:38] <cpaelzer> slangasek: apw: the upload does 9.2 and 9.3 and I assume that the -v would have been to link up the changes of 9.2 as well?
[05:40] <apw> cpaelzer, the -v should always point to the current version in -updates so that the tools know that all the ones since then are new
[05:40] <cpaelzer> apw: ok so my assumption was right at least on that
[05:41] <cpaelzer> apw: I wonder what I should/could do now
[05:41] <cpaelzer> apw: the upload itself is correct
[05:41] <cpaelzer> apw: the tests are correct, although I understand the descriptions can be misleading - I'm currently updating as good as possible in the bugs
[05:41] <cpaelzer> apw: yet I assume there is no way to "link" the bug that was forgotten after the fact
[05:41] <apw> cpaelzer, steve is suggesting a no-change rebuild with version +1 (ie no changes) and the right -v
[05:42] <apw> cpaelzer, accepting that over the top will let the tooling sort itself out and the resulting bits will be basically the same
[05:42] <cpaelzer> ah thanks I didn't get the no change - I thought I should even worse mess up the changelog, but a no-change makes sense to me
[05:43] <cpaelzer> apw: thanks, I'll prepare something and if it is ok for you contact you once it is in unaccepted
[05:43] <apw> cpaelzer, i assume it would be *9.4 with a 'no change rebuild' as the changelog entry
[05:43] <apw> cpaelzer, let us know here you have done that, and we can get it sorted
[05:49] <cpaelzer> apw: does the following make sense as a changelog entry then: "no change rebuild to properly pick up all the changes since the last release to yakkety-updates." ?
[05:56] <cpaelzer> ah that is genchanges, so it is me who should have wrapped that, good that I checked before the upload
[05:57] <cpaelzer> yeah, that looks much better
[05:57] <apw> cpaelzer, yeah that sounds fine to me
[05:58] <cpaelzer> I must admit I never realized so far (shame on me) this was an upload side thing, I thought the bug linking would be done due to the tooling when accepted
[05:58] <cpaelzer> +1 to the (almost) secret packaging knowledge count
[05:58] <apw> cpaelzer, it is the tooling which works out which bugs to play with, but it does so from the changes file
[05:59] <cpaelzer> apw: I expected the tooling to distrust .changes anyway and debdiff vs -updates or such anyway
[06:00] <cpaelzer> apw: it is in yakkety-unapproved now, could you give it a double check?
[06:01] -queuebot:#ubuntu-release- Unapproved: libvirt (yakkety-proposed/main) [2.1.0-1ubuntu9.3 => 2.1.0-1ubuntu9.4] (ubuntu-server, virt)
[06:15] <apw> cpaelzer, looks better indeed
[06:30] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (yakkety-proposed) [2.1.0-1ubuntu9.4]
[07:29] <flexiondotorg> Can I request reviews for ubuntu-mate-artwork, brisk-menu, mate-menu, mate-control-center and mate-themes please.
[07:55] -queuebot:#ubuntu-release- Unapproved: stress-ng (zesty-proposed/universe) [0.07.27-1 => 0.07.28-1] (no packageset) (sync)
[08:01] -queuebot:#ubuntu-release- Unapproved: accepted stress-ng [sync] (zesty-proposed) [0.07.28-1]
[08:08] <Laney> slangasek: s390x conf> I'm not sure I even knew that detail (or if I once did, I've forgotten), so nope - ask pitti?
[08:11] <jamespage> cpaelzer, slangasek: I may have not commented on the right bug for that libvirt issue - apologies (had a few in the air last week)
[08:13] <cpaelzer> jamespage: I think we are fine now, although it is a no-change-rebuild if you could spin off another tempest for the rbd bug that would be kind
[08:13] <cpaelzer> jamespage: I'm planning to the other (qemu/ifup) test for libvirt somewhen later today against proposed
[08:13] <jamespage> cpaelzer: great
[08:14] <cpaelzer> since it is a no-change if you feel bold enough just say it works (as before), but I'm always a coward and will retest
[08:14] <jamespage> bdmurray: btw the nova autopkgtest failure cleared itself for the libvirt in proposed (although we now have new libvirt again)
[08:14] <jamespage> cpaelzer: I can run the verification testing in the lab - takes time but not really mine
[08:15] <cpaelzer> perfect, machines are there to serve us
[08:25] -queuebot:#ubuntu-release- Unapproved: youtube-dl (zesty-proposed/universe) [2017.03.07-1 => 2017.03.26-1] (lubuntu, ubuntukylin) (sync)
[08:28] -queuebot:#ubuntu-release- Unapproved: libosl (zesty-proposed/universe) [0.8.0-1 => 0.8.0-1.1] (no packageset) (sync)
[08:29] -queuebot:#ubuntu-release- Unapproved: accepted libosl [sync] (zesty-proposed) [0.8.0-1.1]
[08:46] -queuebot:#ubuntu-release- New binary: libosl [amd64] (zesty-proposed/universe) [0.8.0-1.1] (no packageset)
[08:48] <tjaalton> could someone ack libdrm which adds amd vega support, eventually needed by mesa
[09:09] -queuebot:#ubuntu-release- Unapproved: accepted less [source] (zesty-proposed) [481-2.1ubuntu2]
[09:12] -queuebot:#ubuntu-release- Unapproved: ubuntu-kylin-docs (zesty-proposed/universe) [16.10.1 => 17.04.1] (ubuntukylin)
[09:21] <apw> tjaalton, that is a fair sized update with "new upstream release" as the entire documentation
[09:24] -queuebot:#ubuntu-release- New sync: telegram-desktop (zesty-proposed/primary) [1.0.14-1]
[09:24] <tjaalton> apw: these are backported to lts as-is
[09:24] <tjaalton> nothing ever broke
[09:26] <apw> tjaalton, oh am i reviewing the wrong one then, i was looking at zesty
[09:26] <tjaalton> no
[09:26] <tjaalton> zesty
[09:27] <tjaalton> this would be backported to xenial
[09:27] <tjaalton> after release
[09:27] -queuebot:#ubuntu-release- Unapproved: accepted crash [source] (zesty-proposed) [7.1.8-1ubuntu1]
[09:27] -queuebot:#ubuntu-release- Unapproved: accepted gnupg2 [source] (zesty-proposed) [2.1.15-1ubuntu7]
[09:27] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-artwork [source] (zesty-proposed) [17.04.9]
[09:27] -queuebot:#ubuntu-release- Unapproved: accepted eject [sync] (zesty-proposed) [2.1.5+deb1+cvs20081104-13.2]
[09:27] -queuebot:#ubuntu-release- Unapproved: accepted xkeyboard-config [source] (zesty-proposed) [2.19-1ubuntu1]
[09:27] -queuebot:#ubuntu-release- Unapproved: accepted rawtherapee [source] (zesty-proposed) [5.0-1ubuntu1]
[09:27] <tjaalton> https://pastebin.com/ag81nMQX
[09:27] <tjaalton> git log diff
[09:30] <apw> tjaalton, thanks, whoever does those in debian should include some of that info in the package
[09:33] <tjaalton> some packages have the git log diff as upstream ChangeLog
[09:33] <tjaalton> pkg-xorg packages i mean
[09:33] <apw> that would be nice
[09:33] <apw> ok that does look to be essentially bug fixes anyhow
[09:34] <ogra> it seems like the live-build SRU into xenial broke core snap builds ...
[09:34] <ogra> (tries to remove systemd and install upstart during build)
[09:34] <apw> ogra, it is a good job that snaps are in the archive and can trigger adt tests to prevent those kinds of regressions
[09:35] -queuebot:#ubuntu-release- Unapproved: accepted libdrm [sync] (zesty-proposed) [2.4.76-1]
[09:35] <ogra> apw, well, the core snap has a travis hook, not sure if you can pull that into adt
[09:35] <apw> tjaalton, ^
[09:35] <tjaalton> apw: cool, thanks!
[09:36] -queuebot:#ubuntu-release- Unapproved: accepted gtksourceview2 [source] (zesty-proposed) [2.10.5-2ubuntu3]
[09:36] -queuebot:#ubuntu-release- Unapproved: accepted python-django [source] (zesty-proposed) [1.8.7-1ubuntu10]
[09:36] -queuebot:#ubuntu-release- Unapproved: accepted kombu [sync] (zesty-proposed) [3.0.35+dfsg-2]
[09:36] -queuebot:#ubuntu-release- Unapproved: accepted screen [source] (zesty-proposed) [4.5.0-4ubuntu1]
[09:37] <apw> ogra, i doubt we can easily do that, but ... you could test the -proposed versions when they appear perhaps to catch this for next time
[09:37] <ogra> not easily
[09:37] <ogra> i'ÄD have to set up anopther github branch just for pointing to proposed i fear
[09:38] <apw> oh well, i guess we just get to break when it hits updates then
[09:39] <ogra> it didnt break for 2 years :P
[09:40] <ogra> has it been tested with xenial --minbase builds at all ?
[09:41] <ogra> iirc we had special handling of upstart packages there
[09:41] <apw> ogra, so the change there is to purge packages which are no longer marked essential in the updates pocket
[09:41] <ogra> ++# remove all installed packages that are Prio: required in the release
[09:41] <ogra> ++# pocket but something else in the latest version
[09:41] <ogra> "something else"
[09:41] <ogra> and yes, i have the diff in front of me
[09:42] <apw> anything else is probabally a better wording
[09:42] <ogra> as i said, i belive there was some special handling of init systems in xenial that pitti implemented
[09:42] <apw> got a log for what yours did ?
[09:43] <ogra> here is the last working build (search for lb_chroot_install): https://launchpadlibrarian.net/313520770/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz
[09:43] <ogra> and here is a current build https://launchpadlibrarian.net/313704330/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz
[09:43] <apw> as it rmeoving upstart sounds more believable than it removing systemd from those words ... very odd
[09:44] <ogra> yes
[09:44] <ogra> but as i said, iirc pitti did something special there (for the phone ? cant remember)
[09:47] <ogra> looking at the bottom of the live-build diff, just another env var to make it skip that step should be enough, i can easily export that
[09:50] <apw> ogra, i am not sure that is the right approach
[09:51]  * apw tries to grok the effect of this code accuratly
[09:54] <apw> ogra, so if i read this code right it looks to see all things marked required at release pocket versions, it checks the current version of just those to see how they are marked, if they are not still required it simulates remove them, if only they are removed in that simulation they are removed for real
[09:54] <apw> ogra, so its not at all clear how that would trigger your extra installs
[09:54] <ogra> it removes systemd-sysv
[09:56] <apw> which looks right in the sense it was required and is now only important
[09:56] <ogra> i dont see why though, it is still prio required here
[09:56] <ogra> oh ?
[09:56] <ogra> why does my desktop not thing so
[09:57] <apw> sorry my check was zesty
[10:00] <ogra> what i dont get in that code is that the first run uses the version, the second doesnt and it is expected that the Prio filed changed between these two ...
[10:00] <ogra> ... but i'm building an image so i will always have the latest version of the package anyway
[10:01] -queuebot:#ubuntu-release- Unapproved: ubuntu-kylin-wizard (zesty-proposed/universe) [16.10.0 => 17.04.0] (ubuntukylin)
[10:07] <apw> ogra, so apt-cache shows you all the ones available to you not just the most recent
[10:08] <ogra> well, for the release i'm currently building for only ...
[10:08] <ogra> and since i build from scratch i should already have the latest version
[10:09] <apw> ogra, so ... i canont acount for why it thinks systemd-sysv wants to be removed in xenial
[10:09] <ogra> me neither ... but it surely happens :)
[10:09] <apw> you odn't have systemd in your PPA do you ?
[10:10] <ogra> hmm, there is an obsolete version idling around
[10:10] <ogra> https://launchpad.net/~snappy-dev/+archive/ubuntu/image?field.series_filter=xenial
[10:11] <ogra> argh
[10:11] <ogra> not as obsolete as LP wants to make me think
[10:11] <apw> well it might show up on the list, me tries
[10:11] <apw> adding that here
[10:11] <ogra> seems the "newer version" it points to is only in -proposed
[10:12] <apw> i also think there is a separate bug here, that if the removal causes an install it should not be implemented
[10:12] <apw> ogra, would you file a bug for me on live-build, so i have somewhere to vomit my analysis ?
[10:12] -queuebot:#ubuntu-release- Unapproved: less (xenial-proposed/main) [481-2.1ubuntu0.1 => 481-2.1ubuntu0.2] (core)
[10:12] -queuebot:#ubuntu-release- Unapproved: less (yakkety-proposed/main) [481-2.1ubuntu1 => 481-2.1ubuntu1.1] (core)
[10:12] <ogra> on it
[10:13] <apw> ogra, your ppa version seems newer than everything in the archive, not that i am sure we take version into account
[10:13] <ogra> the build takes version into account indeed
[10:14] <ogra> LP actually points to https://launchpad.net/ubuntu/+source/systemd/229-4ubuntu17 as newer version ... but doesnt take into account this is only proposed
[10:14] <ogra> i got cheated by the LP UI
[10:15] <apw> ogra, ahh ok, but regardless of that it is not clear that if -updates was really newer we would notice that if your PPA is present, any of them not being required is enough
[10:15] <apw> to my reading of the code
[10:15] <ogra> right
[10:17] <apw> but in your case it is right to want to remove it, it is wrong (separatly imo) to actually remove it because it causes installations
[10:17] -queuebot:#ubuntu-release- Unapproved: accepted kdevelop [source] (zesty-proposed) [4:5.0.4-0ubuntu2]
[10:17] -queuebot:#ubuntu-release- Unapproved: accepted mate-control-center [source] (zesty-proposed) [1.18.0-0ubuntu2]
[10:17] <apw> and that is "too much"
[10:18] -queuebot:#ubuntu-release- Unapproved: accepted brisk-menu [source] (zesty-proposed) [0.3.5-0ubuntu1]
[10:20] -queuebot:#ubuntu-release- Unapproved: rejected ubuntukylin-wallpapers [source] (zesty-proposed) [17.04.0]
[10:20] -queuebot:#ubuntu-release- Unapproved: accepted mate-themes [source] (zesty-proposed) [3.22.8-0ubuntu1]
[10:21] -queuebot:#ubuntu-release- Unapproved: accepted unity-greeter-session-broadcast [source] (zesty-proposed) [0.1+14.10.20140601-0ubuntu5]
[10:22] <ogra> Bug #1678042
[10:24] <apw> ogra, thanks, will propose a fix for that ... is that something you can test ?
[10:24] <ogra> i could push live-build into the PPA i guess
[10:24] <ogra> that would override the archive if the version is picked high enough
[10:28] <apw> ogra, really?  isn't the PPA only used within the build ?
[10:28] <apw> anyhow we can try it i guess
[10:28] <ogra> apw, so running the script snippet in a classic shell on the core install on a pi here actually agrees that systemd-sysv isnt required
[10:28] <apw> let me actually fix this bug :)
[10:29] <ogra> no, we pull livecd-rootfs from there
[10:29] <ogra> so it is also used for the outer build chroot
[10:29] <apw> ogra, yeah i can see that in a xenial vm too so with your PPA addded , so i can at least test a bit
[10:29] <apw> ok good
[10:29] <ogra> it seems it is pulled in from init by default now
[10:30] <ogra> (which itself is actually required but has a "Pre-Depends: systemd-sysv | upstart-sysv" )
[10:30] <ogra> i think that was the trick that pitti implemented to make it possible to have phone builds with upstart still working in xenial or some such
[10:32] -queuebot:#ubuntu-release- Unapproved: ubuntu-mate-settings (zesty-proposed/universe) [17.04.5 => 17.04.6] (ubuntu-mate)
[10:51] -queuebot:#ubuntu-release- Unapproved: choose-mirror (zesty-proposed/main) [2.77ubuntu1 => 2.78ubuntu1] (core)
[10:54] -queuebot:#ubuntu-release- Unapproved: openssh (zesty-proposed/main) [1:7.4p1-9 => 1:7.4p1-10] (core) (sync)
[10:57] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [0.7.9-82-g0e2030ca-0ubuntu1]
[10:57] -queuebot:#ubuntu-release- Unapproved: accepted mate-menu [source] (zesty-proposed) [17.04.3-0ubuntu1]
[10:57] -queuebot:#ubuntu-release- Unapproved: accepted cloud-init [source] (zesty-proposed) [0.7.9-87-gd23543eb-0ubuntu1]
[10:57] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-docs [source] (zesty-proposed) [17.04.3]
[10:59] -queuebot:#ubuntu-release- Unapproved: accepted clutter-gst-3.0 [sync] (zesty-proposed) [3.0.24-1]
[11:01] -queuebot:#ubuntu-release- Unapproved: accepted youtube-dl [sync] (zesty-proposed) [2017.03.26-1]
[11:02] <apw> ogra, see the bug for my write up and a potential fix, if you can test that all the better
[11:02] <apw> ogra, it is obviously untested as a whole though the various bits are tested by hand
[11:04] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-kylin-docs [source] (zesty-proposed) [17.04.1]
[11:04] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-settings [source] (zesty-proposed) [17.04.6]
[11:04] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-kylin-wizard [source] (zesty-proposed) [17.04.0]
[11:08] <ogra> apw, pushed to the PPA ... lets see
[11:09] <apw> slangasek, see bug #1678042
[11:13] <apw> ogra, separatly we need to consider if you are able to change the priority of systemd in that ppa to match what it should be
[11:14] <cjwatson> In theory change-override should work on PPAs, though I'm not sure I've ever tested it.
[11:14] <cjwatson> -A ppa:OWNER/ubuntu/NAME
[11:15] -queuebot:#ubuntu-release- Unapproved: ubuntukylin-wallpapers (zesty-proposed/universe) [16.10.1 => 17.04.0] (ubuntukylin)
[11:16] <ogra> apw, yeah, seems the debian/control file actually has "Priority: important" ... i can fix that after testign your change
[11:17] <ogra> apw, https://launchpad.net/~snappy-dev/+snap/core if you want to watch it
[11:18] <ogra> oh, that failed fast
[11:18] <ogra> err, or not ... the UI cheated me (once again)
[11:21] <infinity> We should just revert to the much simpler and less error-prone "Remove locales and tzdata after debootstrap" method I had proposed.
[11:22] <infinity> This attempting to detect downgrades thing is madness.
[11:22] <ogra> funnitly we even remove locales in our image with a live-build hook at the end :)
[11:23] <ogra> so for me the gain of that change is perfectly at zero
[11:23] -queuebot:#ubuntu-release- Unapproved: kylin-greeter (zesty-proposed/universe) [16.10.1 => 17.04.0] (ubuntukylin)
[11:23] <infinity> Not all changes are for you? :P
[11:23] <ogra> damn ...
[11:23] <ogra> :)
[11:24] <ogra> apw, looks like that build got past the breakage ... but waitign for the full log to actually see it also ended up as it should be
[11:25] <ogra> hmm
[11:26] <ogra> it works but i dont see it remove locales after deboostrap
[11:26]  * ogra wonders if he missed something when applying the diff
[11:26] <ogra> this looks exactly like before the breakage, i would at least expect locales to be removed
[11:27] <ogra> oh
[11:27] <ogra> /usr/lib/live/build/lb_chroot_archives: 64: [: Illegal number:
[11:27] <apw> oh ?
[11:27] <apw> oh what a fool i am
[11:27]  * apw fixes
[11:28] <apw> ogra, i assume you can see the obvious error s/-eq/=/
[11:29] <apw> ogra, but for clarity i will update the debdiff in the bug
[11:29] <ogra> yeah
[11:30] <apw> ogra, ok updated, see if that works better
[11:31] <ogra> pushed
[11:32] <infinity> http://paste.ubuntu.com/24287455/
[11:32] <infinity> I'd prefer this.
[11:33] <infinity> It'll need another upload after we demote tzdata, though maybe I can just do that right now.
[11:33]  * ogra ponders to drop all that building for core and instead use ubuntu-base in the future and add/remove there instead
[11:34] <infinity> Err, "add/remove there"?
[11:34] <ogra> well, that is what we do when building core
[11:34] <apw> infinity, i would argue you should still check that the removal is clean and installs nothing
[11:34] <infinity> No, you don't get to repurpose base.
[11:34] <ogra> debootstrap --minbase ...
[11:34] <apw> infinity, in case some other package has bee modified
[11:34] <ogra> then add a few packages and then mangle the hell out of it
[11:35] <apw> infinity, and added a dep or whatever
[11:35] <infinity> apw: Why?  We know we want to remove locales at that stage on xenial.  If that fails, there's a bug that needs investigating, and a failed build is better than a silent misbuild.
[11:35] <ogra> infinity, i dont want to re-purpose, i just want to base on it
[11:35] <apw> infinity, but do we not explicitly allow us to add random PPAs to the build and they are allowed to make changes
[11:36] <infinity> ogra: Oh.  Yes, it should perhaps be a minbase variant + stuff.
[11:36] <ogra> right
[11:36] <infinity> apw: They're not allowed to make changes to the debootstrap set.
[11:36] <infinity> apw: Simply because debootstrap doesn't allow that.
[11:36] <ogra> the team wants a rootfs tarball that they only add snapd bits to ... so i have to re-think how i build anyway
[11:36] <infinity> apw: We control everything up to the point I patched.
[11:37] <ogra> (to have better snapshot abilities ti roll back snapd on an unchanged rootfs)
[11:37] <apw> infinity, they could change systemd in that set to depend on locales, and then you would force remove both no ?
[11:37] <infinity> apw: Which is why my 1-line patch is much safer than Steve's 30.
[11:37] <infinity> apw: No.  I remove RIGHT AFTER DEBOOTSTRAP.
[11:37] <infinity> apw: Unlike Steve's patch, which removes when the apt archives are all set up.
[11:38] <ogra> well, for his setup he needs the archives set up
[11:38] -queuebot:#ubuntu-release- Unapproved: indicator-china-weather (zesty-proposed/universe) [2.1.5-0ubuntu1 => 2.2.1-0ubuntu1] (ubuntukylin)
[11:38] <infinity> Right, he does.
[11:38] <apw> right but it is at the same point we would have installed the versions from a PPA in your form too no ?
[11:38] <infinity> apw: In my scenario, you have exactly one source.  ubuntu/xenial-release/main.
[11:38] <ogra> for yours you should add the ability to have a list (via LB_ vars or so)
[11:38] <infinity> apw: debootstrap can't use multiple archives.
[11:38] <apw> ok
[11:39] <ogra> instead of just hardcoding locales
[11:39] <apw> so i f we have a PPA we would later upgrade and reinstall locales
[11:39] <apw> and all is well
[11:39] <infinity> ogra: No, I shouldn't.  This isn't meant to be an extensible thing.  This is a one-time slimming retroactively.
[11:39] <ogra> ah, well, steves explanation sounds like thats a broader meant thing
[11:39] <ogra> (in the patch description)
[11:39] <infinity> Another reason I wish Steve hadn't implemented it as if it were an ongoing thing to be abused.
[11:40] <ogra> if it is solely locales thats indeed better
[11:40] <infinity> It'll be locales and tzdata, AFAIK.
[11:40] <ogra> ah, that one we "seed" i think
[11:41] <infinity> You do.
[11:41] <infinity> And both are in minimal, so they get installed later for all variants except base.
[11:41] <infinity> So, y'know what, I'll amend this patch to include tzdata too.
[11:41] <ogra> we dont install minimal
[11:41] <infinity> The archive demotion isn't actually relevant.
[11:41] <ogra> core is smaller :)
[11:41] <ogra> but we have a metapackage that depends on tzdata
[11:41] <infinity> I know.
[11:41] <apw> infinity, not with your approach :)
[11:41] <infinity> core-libs.
[11:41] <infinity> Which is gross.
[11:41] <infinity> Anyhow.
[11:42] <apw> so i assuem for ogra we will remove it and he will put it back and not notice
[11:42] <ogra> we have another core-meta (that i need to merge eventually)
[11:42] <apw> infinity, so ... i assume i can just give you this bug :)
[11:42] <ogra> apw, right
[11:42] -queuebot:#ubuntu-release- Unapproved: ubuntu-mate-welcome (zesty-proposed/universe) [17.04.9 => 17.04.10] (ubuntu-mate)
[11:43] <infinity> apw: No, you get to review my 1-line upload. ;)
[11:43] <infinity> apw: After ogra tests it for me.
[11:44] <ogra> well, once the test of apw's last change finished ...
[11:44] <infinity> Heh.
[11:44] <ogra> the core build only takes a few mins anyway ... it is quick :)
[11:47] <infinity> ogra: dget http://lucifer.0c3.net/~adconrad/live-build_3.0~a57-1ubuntu25.3~adam1_source.changes
[11:53] <infinity> And even simpler fix (just drop the patch altogether) uploaded to zesty.
[11:54] -queuebot:#ubuntu-release- Unapproved: live-build (zesty-proposed/main) [3.0~a57-1ubuntu28 => 3.0~a57-1ubuntu29] (desktop-core)
[11:55] <infinity> ogra: Ima play some video games while you test that ~adam1 version for me.  If the logs look sane to me, we'll bounce it at the queue and expedite it.
[11:55] <ogra> ok
[12:21] <ogra> infinity, just FYI seems steves change with apw's fix actually runs but adds 20min build time now :P
[12:21]  * ogra ponders to just kill all the builds 
[12:21] <infinity> ogra: That seems... Bizarre.
[12:21] <infinity> ogra: Did Andy accidentally write an infinite awk loop?
[12:22] <ogra> it goes over dplg -l and then loops over all packages with apt
[12:22] <infinity> ogra: Anyhow, please test mine.  I'm not really interested in investing more time in the complex solution.
[12:22] <ogra> it removed locales just fine but seesm to still loop over packages
[12:22] <infinity> Sunk cost fallacies and such.
[12:22] <ogra> https://launchpad.net/~snappy-dev/+snap/core/+build/30634
[12:22] <ogra> Purging configuration files for locales (2.23-0ubuntu3) ...
[12:22] <infinity> Yeah, that's hung.
[12:22] <ogra> sits there since a while
[12:22] -queuebot:#ubuntu-release- Unapproved: appstream (xenial-proposed/main) [0.10.6-1~ubuntu16.04.2 => 0.9.4-1ubuntu3] (kubuntu, ubuntu-desktop)
[12:22] <infinity> I killed it.
[12:22] <ogra> ok
[12:23] <infinity> The only "downside" of my patch is that if people want to demote more packages, they need another SRU.  And, honestly, I think that's a feature, not a bug.
[12:24] <infinity> I'm not keen on stable image builds suddenly changing randomly because someone's working on a minimal cloud image and messing with things.
[12:24] <ogra> well, worst case you can always make it an LB_REMOVE_DEMOTED list or so
[12:24] <infinity> No.
[12:24] <infinity> Also, no.
[12:24] <ogra> in case someone freaks out about having to SRU
[12:24] <infinity> This is not a feature.  It's a hack.  Hacks should not be configurable, or they become features.
[12:25] <infinity> The first moment someone relies on this being extensible is when it breaks.
[12:25] <infinity> As it did.
[12:25] <infinity> Because it was written to be extensible. :P
[12:27] <ogra> well, it broke because of a PPA package in the end
[12:27] <ogra> but yeah
[12:29] <infinity> Sure.  But it was still overengineered and bound to have corner cases.
[12:29] -queuebot:#ubuntu-release- Unapproved: rejected live-build [source] (zesty-proposed) [3.0~a57-1ubuntu29]
[12:29] -queuebot:#ubuntu-release- Unapproved: live-build (zesty-proposed/main) [3.0~a57-1ubuntu28 => 3.0~a57-1ubuntu29] (desktop-core)
[12:29] <ogra> yup
[12:29] <infinity> When the intent is "remove two packages", the patch should be "remove two packages".
[12:30]  * infinity shrugs.
[12:31] <ogra> i still dont get why this is in live-build and not in livecd-rootfs though
[12:31] <infinity> Because I told Steve to put it in live-build, because my patch was the fix I envisioned.
[12:31] <infinity> Then he went and found an entirely different part of live-build to do it in. :P
[12:31] <ogra> we seem to start to spread distro changes across ...
[12:31] <infinity> For mine, live-build is the obvious place for it.
[12:32] <ogra> (though it probably doesnt matter much given live-build is already at -ubuntu25)
[12:32] <infinity> livecd-rootfs has no really good place to put it.
[12:32] <infinity> But also, this is a xenial-only hack.
[12:32] <infinity> Hack, hack, hack.  Remember? :)
[12:33] <infinity> The goal for stable patches should be efficiency and readability, not future extensibility.
[12:33] <ogra> yeah, translates to hook in my head since i work on core and phones :P
[12:34] <estan> hi folks. would be great if someone could have a look at the qtbase-opensource-src 5.5.1+dfsg-16ubuntu7.4 currently in the xenial upload queue (result of my bug https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1598173).
[12:34] <ogra> (i lately use live-build/hooks inb livecd-rootfs for nearly everything ... has the advantage of having all hacks in one place)
[12:35] <ogra> though as i said, we might move away completely from that build infra and just use some scripts on top of -base
[12:36] <ogra> ah, looks ... ppc64el is already done building
[12:36]  * ogra chacks the log
[12:36] <ogra> I: Base system installed successfully.
[12:36] <ogra> (Reading database ... 7247 files and directories currently installed.)
[12:36] <ogra> Removing locales (2.23-0ubuntu3) ...
[12:36] <ogra> Purging configuration files for locales (2.23-0ubuntu3) ...
[12:36] <ogra> Removing tzdata (2016d-0ubuntu0.16.04) ...
[12:36] <ogra> looks good !
[12:37] <infinity> And tzdata gets correctly re-added later.
[12:37] <infinity> So, success.
[12:37] <ogra> yup and all the locales hackery is still there and working as well
[12:37] <ogra> (we do some extra stuff with the package later)
[12:38] <ogra> infinity, so upload it then :)
[12:39] <infinity> apw: Fixed in the xenial and zesty queues for that bug.
[12:40] <infinity> s/Fixed/Fixes/
[12:40] <infinity> apw: Please review/accept.
[12:40] -queuebot:#ubuntu-release- Unapproved: live-build (xenial-proposed/main) [3.0~a57-1ubuntu25.2 => 3.0~a57-1ubuntu25.3] (desktop-core)
[12:41] -queuebot:#ubuntu-release- Unapproved: accepted choose-mirror [source] (zesty-proposed) [2.78ubuntu1]
[12:41] -queuebot:#ubuntu-release- Unapproved: accepted kylin-greeter [source] (zesty-proposed) [17.04.0]
[12:41] -queuebot:#ubuntu-release- Unapproved: accepted ubuntukylin-wallpapers [source] (zesty-proposed) [17.04.0]
[12:42] -queuebot:#ubuntu-release- Unapproved: accepted indicator-china-weather [source] (zesty-proposed) [2.2.1-0ubuntu1]
[12:42] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-mate-welcome [source] (zesty-proposed) [17.04.10]
[12:42] -queuebot:#ubuntu-release- Unapproved: rejected live-build [source] (xenial-proposed) [3.0~a57-1ubuntu25.3]
[12:43] -queuebot:#ubuntu-release- Unapproved: live-build (xenial-proposed/main) [3.0~a57-1ubuntu25.2 => 3.0~a57-1ubuntu25.3] (desktop-core)
[12:48] -queuebot:#ubuntu-release- New binary: ubuntukylin-wallpapers [amd64] (zesty-proposed/universe) [17.04.0] (ubuntukylin)
[13:20] -queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (zesty-proposed) [3.0~a57-1ubuntu29]
[13:23] -queuebot:#ubuntu-release- Unapproved: accepted live-build [source] (xenial-proposed) [3.0~a57-1ubuntu25.3]
[14:18] -queuebot:#ubuntu-release- Unapproved: skiboot (zesty-proposed/universe) [5.3.3-1ubuntu1 => 5.4.3-1] (no packageset) (sync)
[14:18] -queuebot:#ubuntu-release- Unapproved: accepted skiboot [sync] (zesty-proposed) [5.4.3-1]
[14:45] <slangasek> apw, cpaelzer: I wouldn't normally do 'no-change rebuild' for an SRU, I would just increment the version number of the upload in the changelog, build with the right -v option, and reupload
[14:45] <apw> slangasek, i can see that, will recommend that in future
[14:46] <slangasek> Laney: s390x conf> ok, if you're not making changes to that file then I should just log a bug about us needing to get it into the VCS
[14:55] <slangasek> infinity: 1678042> err, you've dropped this from zesty? so if we ever have a similar stable demotion in the future we will need to do archaeology on live-build's code?
[14:57] <slangasek> apw, infinity, ogra: so did someone fix the priority of systemd-sysv in the ppa, to unblock those core builds?
[14:58] <ogra> slangasek, no, i'll do that before EOD though
[14:59] <slangasek> ok
[14:59] <slangasek> why do you have systemd in the ppa?
[14:59] <ogra> i'd have to ask mvo who is off today ... some network thing it seems
[14:59] <ogra> slangasek, bug 1678042 btw
[15:00] <slangasek> ah, the network thing, right :/
[15:00] <slangasek> ogra: yeah, a highlight from apw on the bug was what prompted my question :)
[15:29] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (xenial-proposed) [2.23.6]
[15:30] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.23.1 => 2.23.6] (desktop-core, ubuntu-server)
[15:32] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (yakkety-proposed) [2.23.6+16.10]
[15:33] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.23.1+16.10 => 2.23.6+16.10] (desktop-core, ubuntu-server)
[15:33] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (trusty-proposed) [2.23.6~14.04]
[15:34] -queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.23.1~14.04 => 2.23.6~14.04] (no packageset)
[15:59] -queuebot:#ubuntu-release- Unapproved: epiphany-browser (yakkety-proposed/universe) [3.22.6-0ubuntu1 => 3.22.7-0ubuntu1] (desktop-extra)
[16:27] <ChrisTownsend> Hi!  Should I be concerned that libertine and ubuntu-app-launch haven't migrated out of zesty-proposed yet?
[16:28] <nacc> ChrisTownsend: libertine seems to break ubuntu-touch (per update_output.txt)
[16:28] <nacc> ChrisTownsend: same for the other, i tink?
[16:28] <nacc> *think
[16:28] <ChrisTownsend> nacc: Grr, ok, I wonder how.
[16:29] <ChrisTownsend> nacc: Thanks.  I saw the raw output, but I'm learning how to decipher it:)
[16:30] <apw> ChrisTownsend, yeah as nacc says either of those causes ubuntu-touch to be deinstalled
[16:30] <nacc> ChrisTownsend: http://paste.ubuntu.com/24288801/
[16:30] <nacc> ChrisTownsend: from `chdist apt-get zesty-proposed install libertine ubuntu-app-launch ubuntu-touch`
[16:31] <nacc> ChrisTownsend: so there must be some dependencies down that hole :)
[16:31] <ChrisTownsend> nacc: Great, this will be fun to figure out what is is:/
[16:31] <apw> ubuntu-touch seems to dep: on both directly if i am reading reverse-depends output right
[16:32] <apw> have we lost some arches or something ?
[16:32] <ChrisTownsend> It definitely deps on ubunu-app-launch, but only deps on libertine-tools.
[16:32] <apw> * ubuntu-touch [amd64 arm64 armhf i386]  (for python3-libertine-chroot)
[16:32] <apw> * ubuntu-touch [amd64 arm64 armhf i386]  (for libertine-tools)
[16:32] <ChrisTownsend> apw: Ohhhh, yeah, I bet that is what it is.  We are now having to restrict some archs due to Xmir only being built on amd64, i386, arm64, and armhf.
[16:32] <apw> both of those
[16:33] <ChrisTownsend> frick
[16:33] <ChrisTownsend> apw: thanks
[16:39] -queuebot:#ubuntu-release- Unapproved: tomcat7 (trusty-proposed/main) [7.0.52-1ubuntu0.10 => 7.0.52-1ubuntu0.11] (ubuntu-server)
[16:39] -queuebot:#ubuntu-release- Unapproved: tomcat7 (yakkety-proposed/universe) [7.0.72-1 => 7.0.72-1ubuntu0.1] (ubuntu-server)
[16:39] <dobey> ChrisTownsend: huh. why is xmir not built on all the same archs that mir and xorg are built on?
[16:39] -queuebot:#ubuntu-release- Unapproved: tomcat7 (xenial-proposed/universe) [7.0.68-1ubuntu0.1 => 7.0.68-1ubuntu0.2] (ubuntu-server)
[16:40] <ChrisTownsend> dobey: Good question
[16:40] <ChrisTownsend> dobey: Basically as I understand it, it's poor support or immediate crashes when running in the other archs.
[16:41] <ChrisTownsend> dobey: But I'm about ready to throw down to get someone to fix xmir so it'll build on the other archs so this damned song and dance will end!
[16:42]  * apw likes the sound of that
[16:42] <dobey> ChrisTownsend: well if it builds and just doesn't work, i think that's ok for now
[16:42] <ChrisTownsend> dobey: I'm not 100% sure it will build.
[16:42] <dobey> ChrisTownsend: when you find someone that wants to run unity8 on an ibm mainframe, let me know :)
[16:42] <ChrisTownsend> dobey: hah, yeah, really
[16:43] <dobey> hmm, well unless it's doing something absurd, there's no reason it shouldn't at least build, i would think
[16:43] <ChrisTownsend> dobey: I really don't know what the true rationale is.
[16:43] <dobey> if it's just the tests, you can do like content-hub and just disable them on those archs
[16:45] <ChrisTownsend> dobey: I'm going to get to the bottom of this.
[16:46] <bregma> dobey, ChrisTownsend, you'd have to ask tjaalton why Xmir is build for only that subset of architectures, there is not reason I'm aware of why it is so restricted
[16:48] <ChrisTownsend> bregma: Ok
[16:56] <ChrisTownsend> bregma: dobey:  This seems to be the commit where the initial restriction occurred: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/xorg-server/vivid/revision/282
[16:56] <ChrisTownsend> We've since added arm64 in there.
[16:56] <dobey> oh
[16:56] <dobey> hmm
[16:57] <ChrisTownsend> So it's really not clear what the "real" reasons are.
[16:57] <dobey> well, looks like the previous changelog entry restricted xmir to !powerpc
[16:57] <ChrisTownsend> But it might be due to old Mir restrictions that have since been removed and xmir never caught up???
[16:58] <dobey> no idea
[16:58] <ChrisTownsend> Me neither
[16:58] <Laney> There's some weird stuff here
[16:58] <bregma> we need an adult to tell us
[16:58] <Laney> ubuntu-touch is uninstallable in zesty?
[16:58] <Laney> without proposed
[16:58] <ChrisTownsend> Eh?
[16:58] <Laney> try it
[16:59] <bregma> I'm not why we care about ubuntu-touch in Zesty
[16:59]  * ChrisTownsend tries it
[16:59] <dobey> bregma: because it's there and a seed
[16:59] <dobey> bregma: we could get the seed updated to not depend on the libertine/xmir stuff that causes the breakage
[16:59] <ChrisTownsend> Laney: yep
[16:59] <dobey> which we should probably do now
[17:00] <dobey> sil2100: ^^ are you still around?
[17:01] <dobey> Laney, ChrisTownsend: how is it uninstallable exactly?
[17:01] <Laney> dunno atm
[17:01] <Laney> something to do with -gles stuff
[17:01] <dobey> ah conflicts with the non-gles packages?
[17:01] <ChrisTownsend> http://pastebin.ubuntu.com/24288959/
[17:02] <dobey> oh yeah, some of that stuff needs to definitely be removed from the ubuntu-touch seed
[17:02] <Laney> right, but then add one of the uninstallable packages to the commandline
[17:02] <dobey> and actually i thought a few of those were removed
[17:02] <Laney> and you can eventually find out what the final reason is
[17:03] <ChrisTownsend> Seems ubuntu-touch is stale and needs fixing any ways.
[17:03] <dobey> indeed
[17:03] <dobey> well, i guess installing qtubuntu-android on a laptop is also a bad idea anyway too
[17:04] <ChrisTownsend> I think ubuntu-touch itself should be restricted to armhf and arm64.
[17:04] <tjaalton> bregma: probably set by someone else before me
[17:05] <ChrisTownsend> tjaalton: Yeah, it was:)
[17:05] <ChrisTownsend> We can blame RAOF:)
[17:07] <tjaalton> was my guess as well :)
[17:07] <bregma> ah, RAOF who is conveniently disappearing on parental leave, he has obviously been planning this for some time
[17:08]  * bregma digs a good conspiracy
[17:08] <ChrisTownsend> How dare he?!?!?!
[17:13] <Laney> yeah can't find out quickly what the problem(s) are, and I've got to go now, sorry
[17:14] <Laney> hopefully someone gets there :-)
[17:17] -queuebot:#ubuntu-release- Unapproved: nama (zesty-proposed/universe) [1.208-1 => 1.208-2] (no packageset) (sync)
[17:19] -queuebot:#ubuntu-release- Unapproved: accepted nama [sync] (zesty-proposed) [1.208-2]
[17:19] <ChrisTownsend> Is there a requirement that a seed has to support all archs?
[17:22] <dobey> ChrisTownsend: well it's a metapackage, and metapackages tend to be arch: all
[17:23] <dobey> don't know if there's a precident for any seeds not being arch: all
[17:23] <ChrisTownsend> dobey: Sure, just wondering if there is a hard requirement.  ubuntu-touch makes 0 sense on anything besides armhf/arm64.
[17:23] <dobey> precedent even
[17:23] <dobey> ChrisTownsend: well that's not entirely true
[17:23] <ChrisTownsend> Oh
[17:24] <ChrisTownsend> dobey: Maybe i386 based devices?
[17:24] <dobey> ChrisTownsend: it makes no sense on anything that's not android based; it would make perfect sense on an x86 android device that had ubuntu ported to it
[17:24] <ChrisTownsend> dobey: Right
[17:25] <dobey> i'm pretty sure android doesn't support any ppc or s390x devices though
[17:25] <ChrisTownsend> dobey: yeah, that is kind of what I meant.  I didn't think about the x86 version, but you get where I'm coming from.
[17:26] <dobey> though, without building phone/tablet images, and future ones going to be snaps anyway, i would say ubuntu-touch doesn't make sense as a seed any more at all
[17:27] <ChrisTownsend> dobey: Yeah, maybe it should just be removed from zesty???
[17:27] <dobey> ie, it doesn't really make sense in the snaps world. it only makes sense for the .tar.gz preinstalled images for phone/tablet, really
[17:27] <dobey> well i guess it's probably a bit late to just outright remove it?
[17:29] <ChrisTownsend> dobey: I guess.  But it needs fixing if it's not removed.  I'm not sure what we can do w/ the restriction in libertine/u-a-l unless someone gets xmir built for those missing archs.
[17:29] <dobey> slangasek: ^^ you probably have a little more knowledge in the realm of phone/tablet image building process than me, but does it make sense to you to just get rid of ubuntu-touch-meta at this point?
[17:30] <slangasek> dobey: what is the argument for getting rid of it?
[17:30] <slangasek> dropping it on archs where it's unsupported is fine, that's a change to the source package
[17:31] <slangasek> if something else has superseded the metapackage as a definition of the product, please point out what that is
[17:32] <dobey> slangasek: it doesn't make sense in the realm of snap based images, or general armhf/arm64 builds really. are we still building zesty images in devel-proposed for phone/tablet as a sanity check?
[17:32] <slangasek> if you're arguing for dropping it because we have no phone product based on zesty and the definition of future phone products is uncertain, that's ok, but then I think we would want a bug report against the package and confirmation from stakeholders
[17:33] <dobey> slangasek: i think the definition of that product will probably be snapcraft.yaml files in the future, and there's no definition of what a complete "image" for a device would look like at this point afaik
[17:33] <dobey> hmm, ok
[17:33] <slangasek> snap based images> is there one of these today, and how are we enforcing the MIR requirements around their contents?
[17:33] <ChrisTownsend> At the very least, restricting it to amd64/i386/armhf/arm64 would make my life better:)
[17:33] <dobey> i don't think there are any snap based images yet for phones/tablets
[17:34] <dobey> we don't enforce the MIR requirements for the current system-image images either, though
[17:34] <slangasek> yes, and that's a glaring, gaping bug
[17:34] <slangasek> we got 90% of the way there last cycle when unity8 went on the desktop image
[17:34] <slangasek> ubuntu-touch should also be required to be in main
[17:34] <slangasek> thus requiring MIR review for all new dependencies
[17:35] -queuebot:#ubuntu-release- Unapproved: chameleon-cursor-theme (zesty-proposed/universe) [0.5-5 => 0.5-6] (no packageset) (sync)
[17:35] <dobey> yeah, i'm not disagreeing with that ideology, just stating how things are today :)
[17:35] <dobey> oh
[17:35] -queuebot:#ubuntu-release- Unapproved: accepted chameleon-cursor-theme [sync] (zesty-proposed) [0.5-6]
[17:35] <dobey> https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1619468
[17:36] <dobey> ChrisTownsend: ^^ re: earlier issue of it being uninstallable
[17:36] -queuebot:#ubuntu-release- Unapproved: ginga (zesty-proposed/universe) [2.6.1-1ubuntu1 => 2.6.1-2] (no packageset) (sync)
[17:36] <ChrisTownsend> slangasek: Is restricting it to the aforementioned archs something reasonable?
[17:36] <ChrisTownsend> dobey: Ah, ok.
[17:36] <dobey> man someone really needs to triage the bugs filed against ubuntu-touch-meta
[17:37] -queuebot:#ubuntu-release- Unapproved: accepted ginga [sync] (zesty-proposed) [2.6.1-2]
[17:38] <slangasek> ChrisTownsend: of course; having the metapackage on an arch where it can't possibly work is not required
[17:38] -queuebot:#ubuntu-release- Unapproved: cvs (zesty-proposed/main) [2:1.12.13+real-21 => 2:1.12.13+real-22] (ubuntu-desktop) (sync)
[17:38] <slangasek> ChrisTownsend: however, I already see ubuntu-touch-meta only on the archs listed, so what changed?
[17:38] <slangasek> and *where* did it change
[17:38] <slangasek>  ubuntu-touch          | 1.287   | zesty/universe          | amd64, arm64, armhf, i386
[17:39] -queuebot:#ubuntu-release- Unapproved: mariadb-10.1 (zesty-proposed/universe) [10.1.21-5 => 10.1.22-3] (no packageset) (sync)
[17:39] <ChrisTownsend> slangasek: Errr, so the current libertine and ubuntu-app-launch landing is stuck because of ubuntu-touch.  I figured it was due to now restricting some libertine compnenets to those archs.
[17:39] <slangasek> ChrisTownsend: link?
[17:40] <ChrisTownsend> slangasek: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt <- search 'libertine'
[17:40] <dobey> just says amd64: ubuntu-touch now
[17:40] -queuebot:#ubuntu-release- Unapproved: accepted mariadb-10.1 [sync] (zesty-proposed) [10.1.22-3]
[17:40] -queuebot:#ubuntu-release- Unapproved: rpm (zesty-proposed/universe) [4.12.0.2+dfsg1-1 => 4.12.0.2+dfsg1-2] (no packageset) (sync)
[17:41] <ChrisTownsend> Ok, and that is busted even before our landing.
[17:41] <slangasek> yes, and it says amd64 :)
[17:41] <dobey> not sure why it says that though :)
[17:42] <ChrisTownsend> So our landing is caught up in a bigger issue?
[17:42] <slangasek> no
[17:42] -queuebot:#ubuntu-release- Unapproved: accepted rpm [sync] (zesty-proposed) [4.12.0.2+dfsg1-2]
[17:42] <dobey> ubuntu-touch has has installability issues for a long time
[17:42] <slangasek> no, it hasn't
[17:42] <slangasek> the very fact that it's listed by name in update_output means this is a regression
[17:43] <nacc> slangasek: i *think* ubuntu-touch is uninstallable in zesty-proposed period
[17:43] <dobey> https://bugs.launchpad.net/ubuntu/+source/ubuntu-touch-meta/+bug/1619468 <- well this bug has been open for 7 months now
[17:43] <slangasek> nacc: this shows that it would be /made/ uninstallable in zesty (not -proposed) by updating libertine
[17:44] <ChrisTownsend>  But only on amd64?
[17:44] <dobey> hmm
[17:44] <nacc> slangasek: i think it's uninstallable in zesty itself too, i meant, sorry
[17:44] <slangasek> nacc: update_output disagrees with you
[17:44] <nacc> slangasek: i agree, but try it :)
[17:45] <nacc> slangasek: i just did on my zesty and i get: http://paste.ubuntu.com/24289195/
[17:45] <ChrisTownsend> On zesty without proposed: http://pastebin.ubuntu.com/24288959/
[17:45] <slangasek> intriguing
[17:45] <nacc> slangasek: i 100% agree that update_output says it's a regression
[17:45] <nacc> slangasek: and i think it's an *additional* failure now, which is maybe the regression
[17:46] <nacc> as the conflicts in z-p are much longer, afaict
[17:46] <slangasek> p-m really shouldn't care about 'additional' failures
[17:46] <nacc> ok, i wasn't sure
[17:46] <slangasek> it cares about whether a given package is installable or not
[17:46] <nacc> yep
[17:47] <slangasek>  ubuntu-touch : Depends: qml-module-ubuntu-components-gles but it is not going to be installed
[17:47] <slangasek> that's the root of the problem, dependencies in the tree on both qml-module-ubuntu-components-gles and qml-module-ubuntu-components
[17:47] <slangasek> so which of those should be used on amd64?
[17:48] <dobey> the latter
[17:48] <slangasek> ok, so that's a quick seed fix, let me do that
[17:48] <ChrisTownsend> In theory, that should fix my issue?
[17:49] <slangasek> dobey: actually, what I currently see in the seed is:  * qml-module-ubuntu-components-gles [amd64 i386]
[17:49] <slangasek> dobey: so someone explicitly seeded these for amd64
[17:49] <slangasek> ChrisTownsend: nope, at the moment I still don't know why update_output is reporting that
[17:49] <ChrisTownsend> slangasek: lol, ok
[17:49] <slangasek> basically, it means p-m thinks ubuntu-touch is installable on amd64 currently when it actually isn't
[17:49] <dobey> slangasek: odd
[17:50] <dobey> i wonder why that is
[17:50] <slangasek> dobey: I think it's because the touch metapackage is expected to be usable on goldfish, which is gles-only
[17:51] <slangasek> dobey: url-dispatcher depends on qtdeclarative5-ubuntu-ui-toolkit-plugin instead of qtdeclarative5-ubuntu-ui-toolkit-plugin | qtdeclarative5-ubuntu-ui-toolkit-plugin-gles, as one example of the breakage
[17:52] <dobey> hmm
[17:52] <slangasek> ah - no, it *is* installable, if I hint it as: apt install ubuntu-touch webbrowser-app qml-module-ubuntu-components-gles
[17:52] <dobey> fun
[17:55] <slangasek> and what has changed in the new libertine is libertine-tools adds a dep on libertine-xmir-tools -> libqt5gui5 which conflicts with libqt5gui5-gles
[17:56] <slangasek> why is there a hard-coded dep on libqt5gui5 in libertine?
[17:57] <bregma> ChrisTownsend, is that pasted? ^^
[17:57] <larryprice> yes
[17:57] <ChrisTownsend> slangasek: Because we have a utility called 'pasted' that is a Qt app that is invisible for supporting cut and paste between X applications running on Xmir and native U8 Qt apps.
[17:58] <slangasek> ChrisTownsend: http://pastebin.ubuntu.com/24289256/ <-- don't hard-code dependencies on libraries?
[17:58] <slangasek> ChrisTownsend: the question is why is it a *hard-coded* dep.  dh_shlibdeps will automatically pick up ELF dependencies for you
[17:58] <slangasek> and had already correctly mapped this to libqt5gui5 | libqt5gui5-gles
[17:58] <bregma> sounds like a easy fix, except for all the paperwork
[17:59] <ChrisTownsend> slangasek: Oh, well, I didn't know that.
[17:59] <slangasek> next questions
[17:59] <slangasek> how did this pass sponsorship review?
[17:59] <slangasek> because this was a packaging change that someone had to ack
[17:59] <slangasek> and
[17:59] <ChrisTownsend> slangasek: Thanks for educating me.
[17:59] <slangasek> how did this get out of the silo like this without proposed-migration already complaining?
[18:00] <ChrisTownsend> slangasek: Not sure.
[18:01] <ChrisTownsend> slangasek: There were no complaints by anything until that ubuntu-touch clue.
[18:01] <slangasek> yes, but we run p-m on silos so that should have already told us about this problem
[18:01] <ChrisTownsend> slangasek: nope, it didn't
[18:01] <slangasek> and whoever acked this packaging should know better than to hard-code library dependencies
[18:02] <slangasek> i.e. I should not be the first person to have asked you these questions
[18:02] <ChrisTownsend> slangasek: So you're saying the packages prepended w/ 'lib' there should not be there?
[18:02] <slangasek> generally speaking, yes
[18:02] <slangasek> there may be exceptions
[18:03] <ChrisTownsend> slangasek: Ok, so don't put them there unless they need to be there:)
[18:03] <ChrisTownsend> slangasek: But maybe some changes to bileto could help catch this before it gets to this point?
[18:03] <slangasek> kenvandine: ^^ this appears to be your publication
[18:04] <slangasek> ChrisTownsend: well, I don't know why it didn't already show up as an error via proposed-migration; but the ultimate safeguard here is supposed to be that people who ack packaging changes are sure of its correctness before they publish
[18:05]  * kenvandine reads back
[18:05] <ChrisTownsend> slangasek: Ok
[18:06] <slangasek> however, I'm now confused because I'm looking at https://bileto.ubuntu.com/#/ticket/2576 and the packaging diff there does not show this as a new add
[18:06] <ChrisTownsend> slangasek: It's not a new package, it's just a change in dependencies.
[18:06] <slangasek> yes, that's what I mean - this new dep does not show up as new in the diff
[18:06] <slangasek> oh
[18:07] <ChrisTownsend> slangasek: In u-a-l?
[18:07] <slangasek> right, it's the libertine-tools -> libertine-xmir-tools dep that is new, not the libertine-xmir-tools -> libqt5gui5 dep
[18:07] <slangasek> so that was pre-existing, and I'll never succeed in tracking down who acked that ;)
[18:07] <ChrisTownsend> slangasek: Right
[18:07] <slangasek> kenvandine: so you can ignore me, sorry
[18:07] <kenvandine> slangasek, yeah, that's what i looked at :)
[18:07] <kenvandine> slangasek, i'll never ignore you
[18:07] <kenvandine> :-D
[18:08] <ChrisTownsend> slangasek: Well, at any rate, I'll fix this up and thanks for the lesson (no sarcasm).  I learned a ton in this little foray.
[18:09] <slangasek> ChrisTownsend: anyway, yes, I can confirm that all of the hard-coded libqt* deps are redundant with autogenerated deps that are already there, so you can drop those, re-publish, and it'll sail through
[18:09] <slangasek> (I can't tell at a glance if libcontent-hub0 needs to be hard-coded or not)
[18:11] <ChrisTownsend> slangasek: Ok, the only way to tell if it needs to be hard-coded is to try to install in a pristine system?
[18:11] <ChrisTownsend> ie, some chroot?
[18:12] <slangasek> ChrisTownsend: the way to tell would be to build it locally, then look at the contents of debian/libertine-xmir-tools.substvars and see if libcontent-hub0 got added there
[18:12] <ChrisTownsend> slangasek: Ok, thanks again.
[18:22] -queuebot:#ubuntu-release- Unapproved: evolution-data-server (yakkety-proposed/main) [3.22.3-0ubuntu0.1 => 3.22.7-0ubuntu0.1] (ubuntu-desktop)
[18:28] -queuebot:#ubuntu-release- Unapproved: evolution (yakkety-proposed/universe) [3.22.3-0ubuntu0.1 => 3.22.6-0ubuntu0.1] (ubuntugnome, ubuntukylin)
[19:00] <dobey> yeah you definitely shouldn't need hard-coded deps on libfooN packages except for things like libfoo-dev having versioned dep on libfooN or something like that, or you're doing runtime dlopen() and want to Recommends: a libfooN, which dh_shlibdeps couldn't handle directly
[19:26] <infinity> slangasek: I don't think "removing things from the debootstrap set post-release" should be a feature we want to "support".  The xenial bits were originally described to me as a one-time hack to slim things down retroactively, but preparing for a future where we intend to do this over and over again is preparing for a future I'm not sure we want.
[19:26] <slangasek> infinity: fair enough
[19:26] <infinity> slangasek: Or, to put another way, the required seed has changed 19 times in 10 years, two of those were post-release, both just now.
[19:27] <ogra> just wait til the extended support for 12.04 kicks in fully in 1-2 years :P
[19:28] <ogra> (and you have to shuffle all the default package sets )
[19:28] <infinity> slangasek: Although, as I was falling over from being up all night, an entirely different thing occurred to me.  For >= zesty, this change has changed the outcomes for d-i netboot installs, unless they have the minimal task preseeded.
[19:28] <infinity> slangasek: Which, sure, maybe they "should", but I bet many don't.
[19:29] <infinity> ogra: And I have to what?  Why would extending support change packagesets?
[19:29] <ogra> dunno, because things get completely unsupported or some such ...
[19:29] <slangasek> infinity: well, that's a major bug in d-i then, which should always have been including minimal by default under our previous definitions of how things are supposed to work
[19:30] <slangasek> and there may be a bug report open about this, cyphermox may recall it
[19:30] <slangasek> or xnox
[19:30] <slangasek> some x
[19:31]  * slangasek creates a new lp team, ubuntu-nasal-vowel-palatal-sibilant
[19:32] <infinity> I may have to go back and double-check that, but I don't think we *force* minimal on people.
[19:32] <infinity> But, indeed, we're also not released, so we have all the time in the next 13 days to figure it out. ;)
[19:32] <ogra> i think debootstrap defaults to it if you dont use --minbase
[19:32] <ogra> (or has that changed ? i havent looked for a while)
[19:33] <slangasek> I'm not saying it needs to be forced, but I do think it should require explicitly opting out of minimal to not have it, not as a side effect of e.g. preseeding other tasks
[19:33] <infinity> ogra: Oh.  You're sort of right.
[19:34] <infinity> Non-minbase debootstrap includes Prio: important, of course.  So this change is a no-op there.
[19:34] <infinity> Right, nevermind. :P
[19:34] <infinity> slangasek: Well, that's not really how tasksel works, though.  And changing the syntax won't help anyone.
[19:35] <infinity> slangasek: You get one preseed line to select tasks.  So either we make some mandatory, or they get exactly the ones they asked for.
[19:35] <slangasek> xnox, cyphermox: congratulations, you're the only two members of ubuntu-nasal-vowel-palatal-sibilant on this channel; only ginggs comes close, but he would have to be ubuntu-vowel-nasal-palatal-sibilant
[19:35] <infinity> (But nevermind this in context of tzdata and locales, I'm too tired to think straight, debootstrap will still pull those in)
[19:36] <slangasek> infinity: "one preseed line to select tasks" - that's the part of the design which I think is flawed; I think you should have a default set that you can both add to or remove from
[19:36] <infinity> It might indeed be that minimal == important, based on how we lay out seeds and priority-mismatches, and the longstanding bug was that we don't force *standard*.
[19:36] <slangasek> right
[19:37] <slangasek> I believe that to be true
[19:37] <infinity> In my defense, I kinda just fell over this morning, and only 3 hours sleep resulted.
[19:37] <infinity> Which is more than the not-nap I hadn't planned.
[19:37] <infinity> But less than seems reasonable.
[19:50] -queuebot:#ubuntu-release- Unapproved: nagios3 (zesty-proposed/main) [3.5.1.dfsg-2.1ubuntu4 => 3.5.1.dfsg-2.1ubuntu5] (ubuntu-server)
[20:08] <ginggs> slangasek: are you bored? :)
[20:09] <slangasek> ginggs: no, I'm clearly entertained
[20:10] <ginggs> I have some universe packages to be removed - could be entertaining :)
[20:13] <slangasek> ginggs: nothing from you at https://bugs.launchpad.net/~ubuntu-archive/+assignedbugs ?
[20:14] <ginggs> slangasek: I didn't think of assigning them to myself seeing I can't actually remove them
[20:14] <slangasek> ginggs: I mean that I see no bugs assigned to ~ubuntu-archive that you filed
[20:15] <ginggs> oh, I've been subscribing ~ubuntu-archive, not assigning
[20:16] <ginggs> assigning now...
[20:18] <cjwatson> used to be that subscribing was preferred ...
[20:19] <jbicha> slangasek: https://wiki.ubuntu.com/ArchiveAdministration says ubuntu-archive should be subscribed not assigned
[20:19] <slangasek> ah, well then :)
[20:20] <ginggs> in my experience, subscribing doesn't seem to work :)
[20:20] <cjwatson> I don't think there's any likely mechanism by which assigning would work better
[20:21] <slangasek> perhaps it works better only in the sense that https://bugs.launchpad.net/~ubuntu-archive/+subscribedbugs currently gives me a timeout that +assignedbugs did not :D
[20:22] <cjwatson> I was hoping nobody was going to mention that
[20:22] <cjwatson> I tend to use http://paste.ubuntu.com/24290050/ as a workaround
[20:24] <slangasek> other workaround: https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=ubuntu-archive
[20:25] <cjwatson> hey, lp-subscribed-bugs times out too, sigh.  not going to go delve into lib/lp/bugs/ right now because I like my sanity
[21:05] <cyphermox> slangasek: there was a relevant tasksel issue with server before not including "standard"
[21:07] -queuebot:#ubuntu-release- Unapproved: cloud-init (zesty-proposed/main) [0.7.9-87-gd23543eb-0ubuntu1 => 0.7.9-89-gbf7723e8-0ubuntu1] (edubuntu, ubuntu-cloud, ubuntu-server)