[00:15] <infinity> tsimonq2: I see no queued builds for kubuntu.  Of course, you might not have permissions to build it.
[00:15] <tsimonq2> infinity: Hmmmmmmm
[00:16] <tsimonq2> infinity: I can for Kubuntu and people like f l o c c u l a n t have rebuilt Lubuntu before, so I'm not sure
[00:16] <tsimonq2> infinity: But either way rebuild Kubuntu Beta 1 images please ;)
[00:16] <wxl> weird i was able to rebuild
[00:17] <tsimonq2> wxl: You in Kubuntu Product Managers?
[00:17] <wxl> ummm i think so? :)
[00:18] <infinity> Yeahp, I see wxl's request.
[00:19] <tsimonq2> infinity: So while you're here, why did Lubuntu Alternate break? O__o
[00:19] <infinity> tsimonq2: The first time, or the second time?
[00:19] <tsimonq2> Uhhhh what? ;)
[00:19] <tsimonq2> Since I asked you last night
[00:20] <tsimonq2> What's changed and why? :)
[00:20] <infinity> tsimonq2: The first time, it was because slangasek dropped net-tools from minimal, but didn't change the priority override in the archive, and debootstrap broke.
[00:20] <infinity> tsimonq2: After I fixed that, I found that my HWE changes for 16.04.2 (which I'd forward-ported to 17.04 for sanity's sake) broke exactly one image -- lubuntu alternate. :P
[00:21] <tsimonq2> infinity: Hahahahaha :P
[00:21] <tsimonq2> infinity: Well thanks for taking the time to fix it. :)
[00:21] <wxl> surprise, surprise, surprise
[00:23] <infinity> lubuntu alternate really is the oddball these days.  I really think we need to figure out a way to get the desktop image "good enough" for the things you need alternate for (is "low resource machines" the only remaining valid argument?) so we can ditch the alternates.
[00:23] <infinity> This'll become even more urgent when we eventually move our server images away from using d-i, as we'll want to get rid of all that d-i/debian-cd infrastructure, which only lubuntu will be relying on.
[00:23] <tsimonq2> Eek.
[00:24] <lynorian> infinity, is there a timeframe for that?
[00:24] <tsimonq2> lynorian: Ultimately, unless the archive admins decide to just be inconsiderate and axe it, it's up to us.
[00:25] <infinity> lynorian: There's a handwavy roadmap goal of 18.04 being a non-d-i server image.  It may or may not happen.  But even without that happening, lubuntu being the only d-i desktop image makes it sufficiently "weird" that it causes us headaches.
[00:25] <tsimonq2> infinity: What makes Lubuntu Alternate different from Ubuntu Server images?
[00:25] <wxl> tsimonq2: the GUI
[00:25] <wxl> infinity: so what will it be replaced with in server/
[00:25] <tsimonq2> wxl: But Ubuntu Server uses d-i?
[00:26] <lynorian> tsimonq2, yes
[00:26] <infinity> In theory, not much.  In reality, quite a bit, since a desktop alternate image has a lot more moving parts.
[00:26] <tsimonq2> wxl: Lubuntu *Alternate* so one of us is not reading right ;)
[00:26] <infinity> Lots of special casing in the code, lots more that can go wrong.
[00:27] <infinity> Plus, an alternate install and a live-based install almost never produce the same results.
[00:27] <infinity> Which is a bit of a nightmare that I assume you guys just handwave past. :)
[00:27] <tsimonq2> infinity: The individual who originally vouched for Lubuntu Alternate images is now...gone. I would be happy to reassess the situation and see if it's still worth it, what our community thinks, etc.
[00:28] <infinity> wxl: In server, the plan is to switch to more of a preimaging-and-first-boot-config style installer (currently known, confusingly, as subiquity, despite having nothing in common with ubiquity).
[00:29] <infinity> tsimonq2: Ultimately, it comes down to making a solid case for there being a reasonably large number of users who actually *can't* run ubiquity.
[00:29] <infinity> tsimonq2: If that set of users is very small, then preseeding a d-i netboot (ie: mini.iso) to install lubuntu is a fine workaround for them.
[00:29] <infinity> tsimonq2: If that set is nonexistant (which might be true by now), then it's even more of a no-brainer.
[00:30] <infinity> tsimonq2: If 40% of your users have 64MB of RAM, then we need to assess options. :P
[00:31] <wxl> i look forward to this frankly
[00:31] <wxl> i mean there's always SOMEONE who will complain, but we don't need to support every edge case
[00:31] <tsimonq2> +1 wxl
[00:31] <wxl> usually the contention with netboot is that it requires internet access
[00:32] <wxl> of course you need internet access to get the iso
[00:32] <infinity> wxl: Indeed.  And we forced the issue pretty decisively when we dropped non-pae kernels.  I'm having a hard time imagining the intersection of people with PAE-capable CPUs and not enough RAM to run ubiquity is more than about 5 people.
[00:32] <wxl> or you need someone to get you physical media
[00:32] <tsimonq2> And I absolutely don't want to paint this as, "Since Simon took over as release manager, he's axing PPC and he's axing alternate images and what now, i386? *grumble*"
[00:32] <wxl> in which case, with ubiquity,l you have everything anyways
[00:32] <tsimonq2> s/took over/was given the position of/
[00:32] <wxl> tsimonq2: ppc was axed because we were forced to
[00:32] <tsimonq2> (painted in mind of angry person)
[00:32] <wxl> tsimonq2: and frankly, it would be the same with d-i
[00:33] <infinity> tsimonq2: PPC is basically out of your hands.
[00:33] <wxl> the benefit to all this, though, is that we would have our attention divided less and could better support a tighter core
[00:33] <infinity> d-i will always be in the archive (well, probably always?), but building d-i-based *CDs* for only one flavour is a fairly large maintenance burden on us, so we'd prefer to move away from it if we can, that's all.
[00:34] <infinity> The infrastructure required to build d-i-based CD images makes shoestring and bubblegum look like steel girders on concrete foundations.
[00:35] <tsimonq2> wxl, infinity: I would totally be on board with making 17.04 the last release providing the alternate images, provided that we have sufficient documentation for preseeding images and there's not a huge userbase that *absolutely* *needs* the images.
[00:35] <tsimonq2> You guys +1?
[00:35] <tsimonq2> I just personally think it's too far in the cycle to make a big change like this.
[00:35] <infinity> tsimonq2: Sure, I wasn't looking to force a decision today or anything.
[00:35] <infinity> tsimonq2: Just to seed ideas.
[00:36] <infinity> tsimonq2: I think a sane first order of business for you would be to float it with your community and get informal polls about how many people use alternate, WHY they use it, and why they THINK they NEED to use it.
[00:36] <lynorian> infinity, +1
[00:36] <infinity> tsimonq2: Even if it turns out that all their arguments are bunk, it helps inform contributions that could be made to make ubiquity better, etc.
[00:37] <tsimonq2> infinity: Totally, I get it, but I'd eventually like to be supporting less images (less overhead etc.), and if the alternate images have a really small userbase, then there's no need to procrastinate.
[00:37] <tsimonq2> infinity: Absolutely. :)
[00:37] <infinity> And, yes, "supporting only one image type" was Canonical's driver for dropping the Ubuntu alternates.
[00:37] <infinity> We had a checklist of things ubiquity had to support before we could do it, we fixed those things, and then bye-bye alternate.
[00:37] <infinity> QA on two different types of images is costly.
[00:38] <tsimonq2> For sure.
[00:38] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Zesty Beta 1] has been marked as ready
[00:38] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop i386 [Zesty Beta 1] has been marked as ready
[00:38] <infinity> And, to be fair, ubiquity will probably never be as flexible as d-i is for the expert user, but expert people who leverage all of d-i's power do so with netboot and preseeds anyway, not with CD ISOs.
[00:39] <infinity> I mean, if there's a sysadmin out there who carries CDs around between 1000 corporate desktops, and pops in a floppy with a preseed, I'd like to meet them.  And just stare at them in wonder for a bit.
[00:40] <tsimonq2> infinity: It would be great if I could get started hacking on Ubiquity, with all of this going on, Kubuntu people have some feature requests, if Lubuntu ever goes LXQt (:P) we'd need to get a Qt but non-KDE Frameworks dependent frontend, etc.
[00:41] <tsimonq2> infinity: If you have specialized people in Canonical that work on Ubiquity and/or some nice docs, it would be very helpful if you could point me in the right direction. :)
[00:41] <wxl> tsimonq2: suffice it to say, you should probably start sending out an email to the lubuntu community
[00:42] <tsimonq2> wxl: Sure, I got it. :)
[00:42] <wxl> infinity: where is the discussion about this new installer going on at?
[00:42] <wxl> "new installer"
[00:43] <tsimonq2> wxl: New installer?
[00:43] <wxl> tsimonq2: for server
[00:43] <tsimonq2> Huh?
[00:44] <infinity> wxl: subiquity stuff is still mostly Canonical-internal, I think, but I've been out of that loop for a while while working on other stuff.
[00:44] <wxl> tsimonq2: 1628 < infinity:#ubuntu-release> wxl: In server, the plan is to switch to more of a preimaging-and-first-boot-config style installer
[00:44] <infinity> wxl: If there's a public git and/or docs, slangasek might have a pointer.
[00:44] <wxl> infinity: um sub-iquity is not a very encouraging name XD
[00:44] <tsimonq2> ^ lol
[00:44] <wxl> infinity: i thought you were joking about that :)
[00:44] <infinity> tsimonq2: cyphermox is the point of contact for all/most things ubiquity right now, try not to drive him insane with questions.
[00:45] <wxl> welp gotta jet. talk later. thanks for all the info, infinity
[00:45] <infinity> wxl: It's meant to be short for ServerUbiquity.  You can blame Mark. :P
[00:45] <wxl> infinity: yeah, well, there be dragons and all XD
[00:45] <tsimonq2> o/ wxl
[00:46] <tsimonq2> infinity: I can only try so hard... :P
[01:05] -queuebot:#ubuntu-release- Unapproved: accepted network-manager [source] (xenial-proposed) [1.2.6-0ubuntu0.16.04.1]
[01:26] -queuebot:#ubuntu-release- Unapproved: thunar (yakkety-proposed/universe) [1.6.10-2ubuntu2 => 1.6.11-0ubuntu1.16.10.1] (mythbuntu, xubuntu)
[01:42] <robru> question about http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#libseccomp , it was uploaded before freeze but stuck by autopkgtests. those are resolved but now it's blocked by freeze. worth waving through?
[02:18] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Zesty Beta 1] has been updated (20170222)
[02:18] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop i386 [Zesty Beta 1] has been updated (20170222)
[02:45] <cyphermox> tsimonq2: it's nowhere near complete enough to spend time testing with more people right now, that's why we haven't really mentioned it -- for now, we're only testing it with a few dozen people, and maybe in a couple weeks we'll announce a way to further test this on ubuntu-devel@ or something
[02:46] <tsimonq2> wxl: ^^^^^^^^^^^^^
[02:46] <tsimonq2> cyphermox: Ok :)
[02:46] <cyphermox> tsimonq2: for now, for your own sanity, I suggest you wait for the announcement. even the images for it are a pain to generate for now >.<
[02:46] <tsimonq2> cyphermox: Ok, it's just that wxl asked so he's the one who gets an answer. :P
[02:46] <cyphermox> but if you're really curious, I think things are trivial to find online ;)
[02:46] <tsimonq2> cyphermox: And are you talking about Ubiquity?
[02:47] -queuebot:#ubuntu-release- Unapproved: thunar (xenial-proposed/universe) [1.6.10-2ubuntu1 => 1.6.11-0ubuntu1.16.04.1] (mythbuntu, xubuntu)
[02:47] <cyphermox> *s*ubiquity
[02:47] <tsimonq2> Ohhhhh ok
[02:47] <cyphermox> ubiquity is the desktop installer, and it's not likely to change in deep ways soon.
[02:47] <tsimonq2> cyphermox: How about Ubiquity? How can I start contributing there?
[02:48] <cyphermox> (unless wxl has some fun KDE improvements -- the Qt version of ubiquity needs lovin')
[02:48] <cyphermox> tsimonq2: the code in at lp:ubiquity. it basically just wraps enough d-i to be useful in the desktop case, and supports preseeding.
[02:50] <tsimonq2> cyphermox: Hm ok, I'll take a look :P
[02:50] <cyphermox> not sure what else to tell you about it unless you have questions ;)
[02:50] <tsimonq2> cyphermox: And yeah, I hope once I can take a look around the ubiquity sources (and if you have any docs for me) I want to help make things better.
[02:51] <cyphermox> it's python, there are a few gotchas in how things are called, but for most intents and purposes you can add things quickly enough, and fix bugs, etc.
[02:51] <cyphermox> the doc is mostly from the wiki here: https://wiki.ubuntu.com/Ubiquity
[02:51] <tsimonq2>  Got something trivial I can start with? :)
[02:53] <cyphermox> nothing I can think of right now; but I suggest you read at least https://wiki.ubuntu.com/Ubiquity/Testing and maybe https://wiki.ubuntu.com/Installer/Development; those are helpful for how to do the testing and debugging
[02:54] <cyphermox> tsimonq2: one thing that was reported recently was the "press enter" message not showing up at the end of desktop installs
[02:54] <cyphermox> I thought we had fixed that, hopefully it hasn't resurfaced.
[02:56] <cyphermox> that would be more in testing and telling if it's a problem again (probably still is on VMWare, but shouldn't be on qemu or real hardware)
[02:56] <cyphermox> it's not really ubiquity though
[02:56] <tsimonq2> Ok
[02:57] <tsimonq2> cyphermox: I have Saturday completely open, if you have anything I can look at and spend some time on, let me know, otherwise I'll play with that.
[02:58] <cyphermox> here:
[02:58] <cyphermox> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bugs?field.tag=bitesize
[02:59] <cyphermox> pick any of those, they should be simple (but they might be already fixed or not applicable anymore)
[03:00] <cyphermox> on Saturday my wife abandons me again, I was planning on working in the garage, but I could have a laptop around ;)
[03:00] <tsimonq2> :)
[03:00] <tsimonq2> cyphermox: My time zone is CST fwiw
[03:01] <cyphermox> ok
[03:02] <tsimonq2> I need sleep, have a nice night!
[03:48] <slangasek> wxl, infinity: I think https://github.com/CanonicalLtd/subiquity might now be public
[03:54] <lynorian> slangasek, it is
[06:28] <handsome_feng> Hi, members of ubuntu-release,  I'm a member of UbuntuKylin,I understand that you are occupied, but could anyone do me a favor to deal with this FFe request(Bug #1663477) ?  Thank you in advance!
[07:37] <sergiusens> slangasek: I'll look into the snapd CDN option since you mentioned it
[07:47] <flocculant> Laney: what are the chances of lightdm coming out of -proposed so I can respin? bug 1656399
[07:48]  * flocculant is not sure how long things are likely to sit in there - I grab things piecemeal when I need to test something locally ...
[08:36] <slangasek> infinity: so, we should do something about disabling powerpc, I think.  Any objection to me marking the architecture in proposed-migration as non-blocking?
[09:13] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Zesty Beta 1] has been marked as ready
[09:13] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop i386 [Zesty Beta 1] has been marked as ready
[09:25] -queuebot:#ubuntu-release- Unapproved: libvirt (trusty-proposed/main) [1.2.2-0ubuntu13.1.17 => 1.2.2-0ubuntu13.1.20] (kubuntu, ubuntu-desktop, ubuntu-server, virt)
[09:41] -queuebot:#ubuntu-release- Unapproved: accepted fglrx-installer [source] (trusty-proposed) [2:15.201-0ubuntu0.14.04.2]
[09:42] -queuebot:#ubuntu-release- Unapproved: accepted fglrx-installer-updates [source] (trusty-proposed) [2:15.201-0ubuntu0.14.04.2]
[10:21] <Laney> flocculant: ok
[10:23] <Laney> done
[10:23] <Laney> flocculant: Would be nice if you could get people to chill out over the dates too
[10:24] <Laney> If anyone wants a respin, just do it, it's meant to be self service
[10:24] <Laney> You get whatever was latest when the crons were stopped, that's all
[11:22] <clivejo> does anyone know what is going on with https://launchpad.net/ubuntu/+source/gcc-6/6.3.0-8ubuntu1 ?
[11:23] <clivejo> arm64 been building for 18 hours now :/
[11:30] <apw> clivejo, looks to be failing a number of tests, each one in a timeout
[11:31] <apw> clivejo, it is making progress of a sort
[11:31] <apw> doko, don't know if this is expected behaviour ^^
[11:32] <clivejo> it seems to be holiding back calligra
[11:32] <clivejo> am I right or wrong in that assumption?
[11:33] <clivejo> not sure why there is a hard dep on gcc like that
[11:33] <clivejo> :/
[11:37] <apw> clivejo, i presume it has built against that version of gcc
[11:37] <apw> clivejo, on the architectures that gcc was complete for
[11:45] <clivejo> apw: is there any way to poke calligra on?
[11:46] <acheronuk> hmm.. I see no versioned depends on a particular 1:6.3.0-x version. It build against a previous one anyway
[11:46] <clivejo> or a nice square kick up the backside with a steal toed boot?
[11:47]  * acheronuk ponders......
[11:47] <clivejo> narf
[11:47] <acheronuk> W: calligra source: intra-source-package-circular-dependency calligra-libs calligrasheets calligrastage calligrawords
[11:48] <clivejo> time to take over the world?
[11:48] <acheronuk> maybe that is confusing britney?
[11:48] <acheronuk> clivejo: that is the plans for tonight!
[11:48] <acheronuk> same as every night.....
[11:59] <flocculant> Laney: ack on light dm - and I tried to get people to chill over the date thing yesterday :)
[12:00] <flocculant> and yea - I knew I could respin - didn't know if lightdm would turn up in time is all :)
[12:00] <Laney> flocculant: ya, if you need a package from proposed then you have to wait for an unblock
[12:01] <flocculant> Laney: I see it landed in release 52 minutes ago :)
[12:03] <Laney> double check with rmadison, then go for the respni
[12:04] <flocculant> yep - only nipped home for a cuppa - I expect all will be fine when I'm properly home
[12:04] <flocculant> thanks for the help :)
[12:04] <Laney> apw: clivejo: acheronuk: On s390x: Depends [...] libgcc1 (>= 1:6.3.0-5ubuntu1)
[12:05] <Laney> flocculant: only if someone clicks the button
[12:05] <apw> Laney, as suspected then
[12:05] <Laney> yep
[12:05] <apw> s390x must have built relativly recently
[12:06] <flocculant> Laney: if you mean respin button - I'm totally ok with how that all works :)
[12:06] <Laney> or it uses a new symbol or something
[12:06] <apw> don't those shared libarary dependancies get built at package build time, from what we used
[12:06] <apw> so it is just saying "what i was built with or later"
[12:07] <Laney> often it finds the maximum version that provides all the used symbols
[12:07] <Laney> err, minimum
[12:07] <Laney> flocculant: ok, that's fine, it just sounded a little bit like you were expecting something to happen automatically
[12:08]  * Laney goes to make a coffee
[12:08]  * acheronuk plots to kill s390x
[12:09] <acheronuk> Laney: thx. s390x. grr.
[12:22] <acheronuk> Laney apw: looking at previous calligra builds, s390x builds do seem to be making a versioned dep against the libgcc1 it was built against each time. whereas other archs seem to be ok with a lower one that obviously is the minimum to provide the symbols on that
[12:23] <Laney> I don't think it's worth getting overly concerned about
[12:23] <acheronuk> Laney: no, I guess not. it's just mildly frustrating when GCC is stuck for a bit
[12:25] <acheronuk> I just prefer when things are stuck to understand why
[12:25] <acheronuk> Laney: anyway. thanks for spotting that :)
[12:29] <Laney> np!
[12:41] <xnox> acheronuk, we maybe missing precise symbols in e.g. libgcc1 itself; hence versioned deps on everything =(
[12:52] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Zesty Beta 1] has been updated (20170222)
[13:53] <clivejo> what is hold back http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gpgme1.0 ?
[13:53] <clivejo> the block request?
[14:05] <rbasak> clivejo: beta 1 freeze + seeded?
[14:25] -queuebot:#ubuntu-release- Unapproved: rejected vlc [source] (xenial-proposed) [2.2.2-5ubuntu0.16.04.1]
[14:25] -queuebot:#ubuntu-release- Unapproved: vlc (xenial-proposed/universe) [2.2.2-5 => 2.2.2-5ubuntu0.16.04.1] (mozilla, mythbuntu)
[14:29] -queuebot:#ubuntu-release- Unapproved: rejected ebtables [source] (trusty-proposed) [2.0.10.4-3ubuntu1.1]
[14:35] <rbasak> Can another ~ubuntu-sru give a second opinion on bug 1313311 please?
[14:42] <apw> rbasak, that is a tricky one, things not linking to the static binary is much better for security clearly, do we know if we have had any updates to that library in the life of the release?
[14:43] <apw> rbasak, as if so, i would be inclinded to say we would want to take it and to want to rebuild the reverse-depends if we can
[14:44] <rbasak> There have been upstream updates.
[14:44] <rbasak> I don't know if any of those are security critical.
[14:44] <apw> yeah but has say the security team updated it in 14.04
[14:44] <rbasak> But as the uploader points out, we don't know which the reverse depends are.
[14:44] <rbasak> That'd take some research to figure out, which nobody has done.
[14:45] <apw> we can likely intuit it from the reverse-depends in the later releases
[14:45] <rbasak> No. It's in universe.
[14:45] <rbasak> Good idea.
[14:45] <rbasak> No previous updates of any form.
[14:45] <apw> as an approximation obviously
[14:45] <rbasak> I'm tempted to say "yes, if you sort the reverse depends, but otherwise, no point".
[14:45] <apw> so ... it being built-in to everything isn't a huge issue, as it hasn't changed
[14:46] <rbasak> "Yes, once somethingi changes and if you sort the reverse depends, but otherwise, no point".
[14:46] <rbasak> >
[14:46] <rbasak> ?
[14:46] <rbasak> I accept users consuming the library may be impacted. But so might they be if we start shipping the shared library when previously we didn't.
[14:47] <apw> well they arn't impacted if we are not changing the library anyhow
[14:47] <rbasak> They don't have a shared library to link against AIUI.
[14:47] <rbasak> So they're impacted in that they have to worry about rebuilding their own stuff if there's a future security update.
[14:48] <apw> but yes, i think we need a commitement to research and fix the reverse-depends for this to have any meaning
[14:48] <rbasak> OK thanks.
[14:48] <apw> so i think i am agreeing with your middle ground :)
[14:48] <apw> and feel free to name and shame me in the bug
[15:00] -queuebot:#ubuntu-release- Unapproved: accepted vlc [source] (xenial-proposed) [2.2.2-5ubuntu0.16.04.1]
[15:04] -queuebot:#ubuntu-release- Unapproved: accepted mdadm [sync] (xenial-proposed) [3.3-2ubuntu7.2]
[15:10] -queuebot:#ubuntu-release- Unapproved: rejected libscrypt [source] (trusty-proposed) [1-2ubuntu2.14.04.1]
[15:12] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (trusty-proposed) [1.2.2-0ubuntu13.1.20]
[15:15] <jbicha> stgraber: are you able to accept new packages into trusty, xenial? I'm looking for someone to accept bug 1652537
[16:13] -queuebot:#ubuntu-release- Unapproved: pg-repack (yakkety-proposed/universe) [1.3.4-1 => 1.3.4-1ubuntu0.1] (no packageset)
[16:36] <flocculant> Laney: rebuilt xubuntu ~3 hours ago - lp places show me 64built, 32 bit apparently failed "W: Unable to read /srv/cdimage.ubuntu.com/scratch/xubuntu/zesty/daily-live/apt/zesty-i386/apt/preferences.d/ - DirectoryExists (2: No such file or directory)" not sure where or if I can poke that or needs canonical fingers :)
[16:37] <Ukikie> Retry the retry, but retry the retry the retry.
[16:40] <Laney> flocculant: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/zesty/xubuntu/+build/91000/+files/livecd.xubuntu.kernel-generic:
[16:40] <Laney> 2017-02-22 12:48:43 ERROR 503: Service Temporarily Unavailable.
[16:40] <Laney> that thing you pasted is a warning, the error is after that
[16:41] <flocculant> Laney: been a long day ... if I hit rebuild - will it - or is it half stuck?
[16:41] <Laney> second
[16:42] <Laney> might just be able to run the last bit
[16:43] <flocculant> might be too late ...
[16:46]  * Laney zapped it
[16:46] <flocculant> ninja :)
[16:51] <Laney> cjwatson: Do you know if something happened to make Launchpad (librarian?) more likely to give 503s lately? I feel like I've been seeing them more often - I implemented some backoff/retry logic in a couple of places for it. Maybe it's always been like that and I only just noticed?
[16:53] <flocculant> Laney: I assume I can hit rebuild for my 32 bit now?
[16:53] <Laney> no
[16:53] <Laney> just wait
[16:53] <cjwatson> Laney: not that I know of, but I haven't been able to pay a great deal of attention lately
[16:53] <wxl> Laney: might want to check with sysadmin.
[16:54] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop i386 [Zesty Beta 1] has been updated (20170222.1)
[16:54] <flocculant> Laney: awesome see 22nd on tracker now - thanks :)
[16:55] <Laney> so if you see that in future, a retry will fix it but a Canonical person can also just rerun the cd-build bit
[16:55] <Laney> save some CO2 and time
[16:55] <flocculant> Laney: ack thanks for the help
[17:02] <Laney> cjwatson: Righto, never mind, thanks for the reply
[17:25] -queuebot:#ubuntu-release- Unapproved: linux-meta-snapdragon (yakkety-proposed/universe) [4.4.0.1047.39 => 4.4.0.1048.40] (kernel) (sync)
[17:25] -queuebot:#ubuntu-release- Unapproved: linux-snapdragon (yakkety-proposed/universe) [4.4.0-1047.51 => 4.4.0-1048.52] (kernel) (sync)
[17:37] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta-snapdragon [sync] (yakkety-proposed) [4.4.0.1048.40]
[17:37] -queuebot:#ubuntu-release- Unapproved: accepted linux-snapdragon [sync] (yakkety-proposed) [4.4.0-1048.52]
[18:54] <infinity> slangasek: Yes, I object to that.  We need to remove it, not mangle the archive.
[18:55] <infinity> slangasek: (Marking an arch broken in britney implies that you think it might become broken and raise the uninstallable count, which then leads to weird side effect of uninstallable trading on subsequent migrations, and a degradation of the archive as a whole)
[18:57] <infinity> slangasek: So, the correct conversation to be had isn't with ubuntu-archive or ubuntu-release about how to work around the arch, it's with wgrant and cjwatson about SQL surgery and steps required to make it so powerpc never existed in zesty.
[19:27] <slangasek> infinity: that's not true; britney doesn't trade uninstallables across architectures.
[19:27] <slangasek> the only degradation would be limited to powerpc
[19:27] <infinity> slangasek: Are you sure?  I thought we'd seen it do so in the past.
[19:28] <slangasek> not in the past decade
[19:28] <infinity> slangasek: On the other hand, given that we don't deal with binaries ANYWAY (unlike Debian), we could just literally remove powerpc from britney, rather than marking it in some degraded state.
[19:28] <slangasek> sure, that's also fine with me
[19:29] <infinity> We'd end up with the occasional orphaned PPC binary in -proposed when it lags, but those would be removed with the surgery that removes all PPC stuff.
[19:29] <slangasek> I agree we need to have the LP discussion with wgrant or cjwatson or someone about removing powerpc there, but this is a quick change I can make directly to remove some friction in -proposed
[19:30] <slangasek> (I was prompted to ask the question precisely because I had a package FTBFS only on powerpc)
[19:30] <infinity> So, yeah.  I'd prefer to just stop examining binary-powerpc/Packages entirely if your goal is to make britney pretend PPC isn't a thing anymore.
[19:30] <slangasek> yep, I'm good with that
[19:32] <infinity> I can just commit that now.
[19:32] <infinity> Feel like communicating to the world that we're about to completely bugger PPC?
[19:33] <infinity> Hrm, and by "commit", I mean "edit the config files on snakefruit that aren't in version control".
[19:33] <infinity> Apparently.
[19:34] <slangasek> I think the masters are in version control but in a different branch/project
[19:35] <slangasek> britney1 vs. britney2?
[19:35] <slangasek> britney1/britney: make_b2_config() ?
[19:35] <infinity> It sits in b2 in prod.  And definitely isn't a checkout.
[19:35] <slangasek> yes, but I believe it's generated by the scripts in britney1
[19:36] <slangasek> actually, it's from suite_arches() in britney1/britney, now to remember where it reads that from
[19:36] <slangasek> hahaha it trusts LP
[19:36]  * slangasek whistles and hides under some paperwork
[19:37] -queuebot:#ubuntu-release- Unapproved: linux-meta-snapdragon (yakkety-security/universe) [4.4.0.1048.40 => 4.4.0.1048.40] (kernel) (sync)
[19:37] <infinity> Oh, well.  That code already has some "if thing, sed 's///'" stuff.
[19:37] <infinity> Add more!
[19:38] <slangasek> can do
[19:38] <slangasek> hmm my britney1 checkout here is bzr, there's a git one now right?
[19:39] <infinity> Should be.  My b2 checkout is git, my b1 is bzr, which probably means I haven't had a need to fiz b1 in a while.
[19:39]  * slangasek nods
[19:39] <infinity> origin	git+ssh://git.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu (fetch)
[19:39] <infinity> Going to assume that, with s/britney2/britney2/
[19:40] <infinity> Or not.
[19:40] <infinity> Maybe b1 wasn't migrated. :P
[19:40] <infinity> slangasek: b1 on snakefruit is still bzr.
[19:40] <infinity> So, I think that answers that.
[19:41] <slangasek> ok
[19:42] <infinity> slangasek: Happy to pastebin review a pseudo-MP if you want, but I figure tacking it in in the one place where "precise" appears in the file should be self-evident.
[19:44] <infinity> s/precise/zesty/; s/ADT_ARCHES/ARCHITECTURES/; s/ppc64el/powerpc/
[19:44] <slangasek> infinity: JFDI
[19:45] <infinity> slangasek: Oh, me?  Sure.
[19:46] <slangasek> infinity: oh
[19:46] <slangasek> infinity: sorry, I misread - if you haven't already started, I'll do it
[19:46] <infinity> slangasek: Done now.
[19:46] <slangasek> ok ;)
[19:46] <infinity> (Minus comment)
[19:46] <slangasek> wgrant, cjwatson: so, britney mangling now done, how do we book some time to get powerpc yoinked out of LP for zesty?
[19:47] <infinity> slangasek: Done.
[20:25] <infinity> slangasek: Looks like that did the trick.  A bunch of stuff migrated just now without PPC bits.
[20:26] <infinity> Apparently successful
[20:26] <infinity> final: ffcall,fnordmetric,gauche,gauche-c-wrapper,gauche-gl,gauche-gtk,golang-github-appc-docker2aci,kodi-pvr-njoy,kodiplatform,libblocksruntime,libc++,libinline-java-perl,mpqc3,oclgrind,open-coarrays,pdns,quantlib-swig,yt
[20:26] <slangasek> infinity: wunderbar
[20:28] <infinity> slangasek: So, yeah, can I get you to follow up (well, maybe not literally, I hate losing thread followups when they attach to a mail from months ago) to your original announcement with something about "the breakage has begun, expect PPC to become progressively more broken in zesty until we remove it entirely"?
[20:28] <slangasek> yes
[20:28] <infinity> Ta.
[20:28] <jbicha> thanks, dropping ppc should unlock the libraw transition once the beta freeze is lifted
[20:29] <slangasek> will do it by EOD tomorrow
[20:29] <jbicha> (libraw had been stuck because of openimageio not building on ppc)
[20:29] <infinity> Now I need a new port.
[20:30] <infinity> mips64el anyone?
[20:30] <infinity> I guess powerpc had a good run, given the original motivation was "a few Canonical employees have Powerbooks".
[20:31] <slangasek> let me also disable all powerpc image builds now in the crontab
[20:31]  * wxl plays taps
[20:31] <infinity> slangasek: s/crontab/arches/?
[20:31] <slangasek> infinity: yes
[20:31] <infinity> slangasek: I thought I hit them all, but lemme have another pass.
[20:32] <slangasek> infinity: did you?  I don't see it committed to trunk
[20:32] <slangasek> if you cowboyed it...
[20:33] <infinity> slangasek: Hah.  Yes.  I did that on purpose.  Let me review my cowboy and commit. ;)
[20:33] <slangasek> or I can commit this and you can deal with the conflicts
[20:33] <infinity> Cause I can already see I missed a few cases.
[20:33] <infinity> Like base needs a new line for zesty-
[20:33] <wgrant> Hmmm, it's a while since we've done that, but it's not technically hugely difficult.
[20:34] <wgrant> We're both rather busy atm, but I suppose there's no real urgency?
[20:34] <infinity> wgrant: Not hugely difficult sounds nice.  I assume it's a tiny bit of SQL surgery to pretend the series doesn't have a DAS for powerpc at all?
[20:34] <infinity> wgrant: Urgency is "within the next week or two", probably.  Unless we discover that we blow something up by working around it, then "sooner". :P
[20:34] <infinity> wgrant: But I don't see how we'd break anything right now.
[20:35] <wgrant> infinity: Not quite. We unset DAS.enabled, then set all the pubs to Deleted.
[20:35] -queuebot:#ubuntu-release- Unapproved: zypper (xenial-proposed/universe) [1.12.4-1 => 1.12.4-1build0.1] (no packageset)
[20:35] <wgrant> It's very difficult to actually delete a DAS due to copies etc.
[20:35] <infinity> wgrant: Well, I guess I'm describing what I want at the UI level, but using (incorrect) DB terms.
[20:36] <infinity> wgrant: At the UI level, I don't want zesty to claim to have powerpc at all.
[20:36] <infinity> And, yes, all the pubs deleted.
[20:36] <infinity> And then I assume I'll need to manually neuter dists after that, which is fine.
[20:36] <slangasek> infinity: pushed my change, feel free to reconcile with your cowboy :)
[20:36] <wgrant> Right, that's a fairly similar effect. The same thing we did with maverick's two deaths.
[20:36] <wgrant> (DAS.enabled was in fact added for maverick)
[20:37] <infinity> slangasek: Conflicts assume you did something differently. :P
[20:37]  * infinity looks.
[20:37] <infinity> Ahh.
[20:37] <infinity> Yeah, I dropped powerpc entirely from mate because they also don't build it for point releases.
[20:38] <infinity> Ditto for the * entry.
[20:39] <infinity> So, I'll revert to my version here, plus other fixes I'm spotting.
[20:40] <slangasek> well if we're not going to keep it historically accurate, there's a /lot/ of cleanup that could be done
[20:40] <slangasek> :)
[20:40] <Laney> Why ARCHITECTURES and not OUTOFSYNC_ARCHES or whatever it was called, OOI?
[20:40] <infinity> This isn't so much about history as it is about xenial *not* building powerpc anymore for non-server/base.
[20:41] <infinity> Laney: Because I want to completely ignore it, not make a mess in excuses.
[20:41] <slangasek> infinity: hmm, it doesn't seem a given to me that they wouldn't build it for point releases just because they didn't do so yet, if you see what I mean
[20:42] <slangasek> infinity: but, well, if I were doing this from scratch I would drop all the EOLed releases from that file
[20:42] <Laney> 'k
[20:42] <slangasek> rather than being a permanent record of "here's a list of architectures you could fail to build jaunty images for"
[20:44] <infinity> slangasek: Sure, I don't disagree that removing EOL stuff might be a solid plan.
[20:44] <infinity> slangasek: Just saying that it documents current runtime desire, so the xenial entries should reflect that. :)
[20:44] <infinity> slangasek: (And the reason for not doing powerpc desktop point releases is that we don't have a powerpc HWE kernel there)
[20:46] <infinity> slangasek: I suppose from the historical POV, it would be most accurate to list a yakkety line with powerpc, but xenial and zesty- without, but meh.  I'd rather drop all the cruft in a follow up instead.  This isn't Colin's toy anymore, so we can break his data-retention policy if we want. :P
[20:46] <infinity> (Also, a VCS has history, weird)
[20:47] <slangasek> :-)
[20:51] <infinity> slangasek: I suspect dropping everything pre-trusty would reduce us to entries for server, base, mate, lubuntu, and star (and a only a few series ranges).  Which would be nice.  And much more compact.
[20:51] <infinity> Maybe I'll do that now. :P
[20:52] <infinity> (Could realistically drop everything pre-xenial, but then I know someone will pay us bazillions to do a 14.04.6 we hadn't planned on, just to spite me)
[20:57] <sbeattie> can someone accept the linux-meta-snapdragon in the yakkety-security unapproved queue so that my cron job about kernel ABI breakages will stop bugging people?
[21:02] <infinity> How or why did it end up in unapproved in the first place?
[21:02] <infinity> But looking/fixing.
[21:03] <infinity> sbeattie: Done.
[21:03] <sbeattie> infinity: thanks
[21:03] <infinity> apw: ^-- That was you, BTW.  Manual copy instead of sru-release, and no --auto-approve means manual love.
[21:03] -queuebot:#ubuntu-release- Unapproved: accepted linux-meta-snapdragon [sync] (yakkety-security) [4.4.0.1048.40]
[21:08] <slangasek> kernel-sru-release is good for this :)
[21:08] <infinity> slangasek: I doubt it.
[21:09] <infinity> slangasek: This was a xenial SRU that needed to be copied forward to yakkety and zesty.
[21:09] <infinity> slangasek: The copy forward is where one copy went wrong.
[21:12] -queuebot:#ubuntu-release- Unapproved: accepted zypper [source] (xenial-proposed) [1.12.4-1build0.1]
[21:13] <slangasek> infinity: ahh ok
[21:17] <apw> infinity, yeah that _was_ me, and i forgot to accpet it the second time after launchapd had a nice little internal error paddy over it the first time
[21:17] <slangasek> top
[21:18] <slangasek> that... did not give me the feedback I was looking for kthx
[21:18] <infinity> apw: All good.  That's why the security team has their nag script. :P
[21:19] <apw> infinity: they have their uses!
[21:54] <barry> rbasak, clivejo i'm hoping we can still get gpgme1.0 1.8.0 into zesty after beta 1 freeze
[21:54] <clivejo> hope so
[21:55] <barry> took a long while to get the ftbfs fixed, but it appears now to be, and this one's holding up a few other promotions
[22:10] <wxl> Laney: et al do you know where Lubuntu Desktop's image went? all thee is is 20170219 http://cdimage.ubuntu.com/lubuntu/daily-live/
[22:12] <wxl> Laney: to be clear the tracker says the version is 20170220. maybe someone screwed up naming it correctly on the tracker. i'll assume that for now
[22:14] -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop amd64 [Zesty Beta 1] has been marked as ready
[22:14] -queuebot:#ubuntu-release- Builds: Ubuntu GNOME Desktop i386 [Zesty Beta 1] has been marked as ready
[22:23] <Laney> wxl: dunno, but it's easy to fix
[22:23] <wxl> Laney: i just want to make sure the image we're testing is the right image :)
[22:24] <Laney> there
[22:25] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Zesty Beta 1] has been updated (20170219)
[22:25] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop i386 [Zesty Beta 1] has been updated (20170219)
[22:25] <wxl> thx
[22:25] <wxl> now i just need to figure out where synaptics went
[22:26] <wxl> didn't realize it but it wasn't there in zesty either
[22:26] <wxl> alpha 1 i mean
[22:28] <wxl> doesn't seem xserver-xorg-input-synaptics has changed any since yakkety
[22:28] <wxl> was there something that has changed about the ubuntu seed?
[22:34] <wxl> i can't find any changes in the seed that would have resulted in this
[22:37] <flocculant> wxl: we still have it
[22:37] <wxl> that's uncanny
[22:38] <flocculant> wxl: re oem - working fine here - at least using kvm
[22:38] <wxl> we do use * Feature: no-follow-recommends
[22:38] <wxl> (and have for a long time)
[22:38] <wxl> is synaptics now in recommended?
[22:38] <wxl> flocculant: yeah that's been our experience here. vbox only it seems.
[22:40] <flocculant> wxl: apt-cache show blah-blah-synaptic doesn't show as a task for Lubuntu
[22:50] <wxl> i think the no recommends is our problem
[22:50] <wxl> compare http://packages.ubuntu.com/yakkety/xserver-xorg-input-all with http://packages.ubuntu.com/zesty/xserver-xorg-input-all
[23:11] <nacc> could someone take a look at perl in z-p? the tests finally are all passing
[23:12] <nacc> and it's holding up a few other migrations
[23:18] <nacc> slangasek: --^ fyi
[23:47] <slangasek> nacc: so this is blocked for the beta freeze; how high risk is it to those images? if there are significant behavior changes we might want to hold it until the beta image prep is done