=== rcj` is now known as rcj
[08:47] <mlankhorst> arges: I've re-uploaded mesa unmodified, see bug report. :-)
[09:14] <jamespage> please could the oslo.vmware in the review queue be looked at - I need the version bump for glance and nova rc1's
[09:46] <Laney> mlankhorst: what is that mesa?
[09:47] <mlankhorst> Laney: oh mesa in trusty for https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1365490
[09:47] <ubot2> Launchpad bug 1365490 in mesa (Ubuntu Trusty) "ubuntu 12.04.5 broken on VMware" [High,Incomplete]
[09:47] <Laney> in the utopic queue
[09:47] <mlankhorst> er oops?
[09:48] <Laney> kind of surprised it didn't get rejected outright
[09:48] <mlankhorst> that one's already in main
[09:48] <mlankhorst> weird that it didn't get rejected..
[09:48] <Laney> release
[09:48] <Laney> and if you want it in trusty then you need to fix the version number and upload with -v, etc
[09:48]  * Laney kills it
[09:52] <mlankhorst> but mesa trusty is accidentally messed up slightly, it won't generate a debdiff against 10.1.3-0ubuntu0.1 which is in the archive. instead against a snapshot that was uploaded by accident and already deleted.
=== doko_ is now known as doko
=== Sweetsha1k is now known as Sweetshark
[11:27] <jamespage> ^^ that's basically a no-change rebuild (a2 -> 1.0.0) to deal with internal version checking for entry points via pbr in glance
[12:02] <arges> mlankhorst: ah thanks, i should have done a manual diff. that looks much more sane.
[12:05] <mlankhorst> yeah :)
[13:10] <jamespage> ^^ those last two oslo* uploads are final releases to resolve internal version checking issues in glance
[13:10] <jamespage> I really hope they are the last two...
[13:57] <apw> ^ fixes brown-paper-bag failure to install in the previous upload, sigh
[14:03] <jamespage> ^^ an another minor fix for pbr version mismatches
[14:04]  * jamespage sighs 
[14:04] <jamespage> that really should be it now
[14:04]  * ScottK wonders how reasonable pbr really is.
[14:04] <jamespage> ScottK, its doing what it says on the tin, but I don't want to put 25k diff version bumps into eventlent and boto
[14:04] <zul> not reasonable
[14:05] <jamespage> even if most of that is py3 work
=== henrix_ is now known as henrix
=== lan3y is now known as Laney
=== wxl_ is now known as wxl
=== Pici` is now known as Pici
[17:54] <pfsmorigo> apw, infinity: is there some progress in the recent kernel bug? (#1375452)
[18:00] <apw> pfsmorigo, the latest kernel upload should have the fix for that applied
[18:01] <pfsmorigo> apw: good! and how can we have this new kernel in the daily image?
[18:03] <infinity> pfsmorigo: It needs to work its way through the sausage factory and get built on all arches, etc, but I'll hand-spin a new daily when it's done, probably in ~9h or so?
[18:03] <infinity> Actual times may vary, but "by tonight (north american time)" is a reasonable estimate.
[18:04] <pfsmorigo> infinity: hehe
[18:04] <pfsmorigo> infinity: ok nice
[18:17] <infinity> cjwatson: Did you reject all the -19 binary NEW linux stuff, or NBS clean it from -proposed already, or am I just blind and can't find it?
[18:18] <infinity> I'm just blind.
[18:19] <infinity> Must have been looking at an old version of the queue.
[18:20] <infinity> apw: ^-- That should make our lives easier, no NBS mess.
[18:32] <infinity> cjwatson: If "make test" passes on here, is that good enough, or should I be looking to make sure it ran specific things, etc?
[18:32] <cjwatson> I think "make test" is probably fine
[18:33] <infinity> cjwatson: Alright, then it passed on a POWER8 system.
[18:33] <cjwatson> Also, 9h is about when the daily would build all by itself anyway
[18:33] <cjwatson> Woo
[18:33] <infinity> cjwatson: Yeah, we might be racing cron with armhf build times + d-i + britney, but if I miss the daily, I'll just spin another.
[18:34] <cjwatson> Yep
[19:04] <jdstrand> is the publisher off or something wrong? I did two uploads but don't see them mentioned here or in https://launchpad.net/ubuntu/utopic/+queue?queue_state=1&queue_text=
[19:05] <jdstrand> ah, ok, there we go
[20:36] <stgraber> just filed a FFe for the latest LXC milestone, would be nice if a release team member could look at bug 1376437
[20:36] <ubot2> bug 1376437 in lxc (Ubuntu) "[FFe] LXC 1.1~alpha2" [Undecided,New] https://launchpad.net/bugs/1376437
[20:37] <stgraber> I know it's kinda late for this, but it took us a long time to get the init scripts/systemd mess in a reasonable shape before we could tag that milestone...
[20:38] <stgraber> if we don't get the FFe (which I'd understand), then I'd like to know ASAP because I'd then have to cherry-pick about 10-20 commits from alpha2 into our already patched alpha1 so that LXC works at least reasonably in utopic
[20:40] <ScottK> stgraber: what fraction of the update are those 10 - 20 commits?
[20:40] <infinity> stgraber: Is the end goal to ship 1.1final in utopic, or will things not align for that?
[20:40] <stgraber> infinity: not, alpha2 would be what we release utopic with
[20:40] <infinity> Shame.
[20:41] <infinity> stgraber: So, I guess you're going to commit to support alpha2 for 9mo so the security team doesn't hate you? :)
[20:42] <infinity>  - lxc-start now defaults to backgrounded mode (I will revert that change prior to upload to avoid potential last minute breakages)
[20:42] <stgraber> ScottK: we need at least the few changes to unbreak things on the current kernel, I'd still push for the openvswitch changes to unbreak nova-compute-flex, we need the apparmor bits and the initscript/systemd bits to unbreak LXC on systemd.
[20:42] <infinity> ^-- You mean you *will* revert it, period, or you intend to revert it if we argue?
[20:42] <stgraber> ScottK: there are a bunch more that'd be worth taking if only as nice to have but those bits are the ones I've been nagged about the most
[20:42] <stgraber> infinity: yeah, I'll deal with any security issue that may show up during the support period.
[20:43] <stgraber> infinity: I'll revert it in the initial alpha2 upload to the archive because I don't want to break ubuntu touch (which is the main case I can think of). I'll un-revert it in utopic+1 though.
[20:43] <apw> stgraber, i think the question there is if the bits you need are 10-20 commits, how many are in ~alpha2
[20:43] <stgraber> and then just fix lxc-android-config to pass -F instead of assuming lxc-start keeps the container attached to the foreground
[20:43] <infinity> stgraber: The lxc-start thing is interesting to me.  I'm all for not breaking things, but also would find it confusing if my 1.1~alpha on utopic and my 1.1final on v-series behaved differently, despite being "the same version".
[20:45] <stgraber> apw: I tagged alpha2 about an hour ago, so all the bits we need are in there (nothing's been committed upstream since).
[20:45]  * ScottK tosses http://www.bartleby.com/100/420.47.html at infinity.
[20:45] <infinity> stgraber: He (and Scott) were asking for ratios.
[20:45] <infinity> stgraber: You need 20 commits, but how may commits are there between alpha1 and alpha2
[20:45] <apw> stgraber, assumed that, it that 1000 commits or 25 commits more than we have
[20:45] <infinity> stgraber: Is that 20/30 or 20/100 or...
[20:45] <stgraber> infinity: 143
[20:46] <infinity> ScottK: I'm not sure if I should laugh or be insulted. :)
[20:47] <ScottK> I was going for laugh.
[20:47] <infinity> stgraber: And the followup question, how likely is a backport of those 20 "necessary" commits to be broken?
[20:47] <infinity> stgraber: As in, will you have to iterate a few times (realistically here, not pie-in-the-sky hope) before you make sure you isolate all the right bits?
[20:50] <stgraber> infinity: doing some stats now
[20:51] <infinity> stgraber: This decision would be easier if you told me this was a final release, with some upstream stability statements attached to that.
[20:51] <infinity> Cause I'm allergic to shipping alphas.
[20:51] <infinity> But alpha2 is probably better than alpha1. :P
[20:51] <ScottK> Version number is higher.  Has to be better.
[20:52] <doko> please accept the gcc-4.9 in -proposed. it has the gccgo fixes for arm64 to make relocations work for cgo, and again a bunch of powerpc updates/fixes
[20:52] <infinity> ScottK: In the case of an upstream alpha/beta versus a final release, I'm okay with backing that statement (well, depending on the upstream).
[20:52] <stgraber> infinity: so basically alpha1 was aligned with 1.0.5 bugfix wise, 1.0.6 is now in trusty so if we don't want to regress we should get all those fixes into our alpha1. That's 85 commits according to git. On top of those (which should be mostly straight cherry-picks), openvswitch is 3 commits and systemd is one giant commit which will blow up in my face (that thing would fail to rebase pretty much daily while I was working on it...).
[20:53] <ScottK> Yeah.  Depending.
[20:53] <infinity> stgraber: Right, I'm leaning to a "yes" right now, for both the bugfix parity with trusty and the needed features to not suck in utopic.
[20:54] <stgraber> infinity: I also agree it'd have be nice to get 1.1 in utopic and indeed that was my plan at the beginning of the cycle, then I ran into internal politics and we had fun with that thing called systemd so the whole thing got delayed a bit...
[20:55] <infinity> stgraber: Right.  So, no 1.1 final (unless we argue to SRU it later), but that does leave the open question of behavioural differences between 1.1alpha and 1.1final, which is vaguely unintuitive.
[20:55] <infinity> stgraber: What in the distro will break with that lxc-start change?  Just touch container setup?
[20:55] <stgraber> alpha2 (really a bad name but I didn't feel like calling it an rc yet) is basically feature complete for 1.1 because what we wanted for 1.1 was checkpoint/restart, now the only missing bits are some template tricks to make systemd based distros suck less (and that doesn't apply to Ubuntu yet).
[20:56] <stgraber> infinity: last archive grep I did, it's just touch, everyone else passes -d because they don't like LXC messing up with their terminal
[20:56] <infinity> stgraber: Okay, so can we either upload an RTM-specific build for them, or just fix the bit that would break?
[20:56] <stgraber> I'm happy to upload lxc-android-config adding the one char fix and bumping the versioned depend on LXC
[20:57] <infinity> stgraber: I think that would actually be better than the safe-but-confusing revert.
[20:57] <stgraber> I'm fine with that
[20:57] <infinity> stgraber: Since docs will likely say "if you use 1.0, do X, if you use 1.1, do Y", but no one will think to mention "hey, if you're on Ubuntu utopic, which is a unique snowflake with 1.1alpha2, pretend it's 1.0, except when not".
[20:58] <stgraber> I really hope docs instruct you to either do -d or -F and reserve the default behavior for a regular user who's not trying to script his way around lxc-start, but yeah, I get your point :)
[20:59] <infinity> stgraber: So, yeah, copy and paste to bugs as necessary, but this is me saying if you can fix things that depend on the old lxc-start behaviour, please don't revert it, and you're okay for the alpha2 upload.
[20:59] <stgraber> infinity: thanks
[20:59] <infinity> stgraber: And if we find you were wrong, you can follow up with an upload that reverts the behaviour, making my inner pedant a bit sad. ;)
[21:12]  * ScottK thought it was your inner hobgoblin
[21:23] <darkxst> anyone able to take a quick look at bug 1376184, I'm about to do a gnome-shell upload to fix things with g-s-d 3.12 and would be good to include that
[21:23] <ubot2> bug 1376184 in gnome-shell (Ubuntu) "[UIFe] Re-enable brightness widget" [Undecided,New] https://launchpad.net/bugs/1376184
[22:20] <bdmurray> arges: if you are still about could you have a look at apport in the trusty SRU queue?
[22:21] <arges> bdmurray: i can, can you reject kexec-tools in the utopic queue for me? I may need to add additional patches
[22:22] <arges> bdmurray: ok done
[22:22] <bdmurray> arges: I'm not an AA so can't help with that.
[22:22] <arges> infinity: ^^ can you reject kexec-tools in the utopic unapproved queue. I'll be updating that tomorrow with additional patches. Thanks
[22:22] <arges> bdmurray: ah sorry: ) thanks anyway
[22:28] <infinity> arges: Done.
[22:32] <arges> thanks
[22:34] <bdmurray> infinity: sru-report is failing to run - https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/fix-401-traceback/+merge/236794 fixes that
[22:35] <infinity> bdmurray: Erm, wat?
[22:35] <infinity> bdmurray: How do we have things in proposed where the build records aren't public?
[22:37] <infinity> I assume this was linux-keystone.
[22:37] <bdmurray> Copied from ubuntu trusty in Private PPA for Canonical ARM Developers by Chris J Arges
[22:37] <bdmurray> right
[22:37] <infinity> bdmurray: I submit that the code is doing something wrong here.
[22:37] <infinity> bdmurray: And skipping the 401 isn't the right answer.
[22:37] <arges> infinity: what did i screw up?
[22:37] <infinity> bdmurray: Cause the archive copy of that is clearly public: https://launchpad.net/ubuntu/+source/linux-keystone/3.13.0-14.24
[22:37] <infinity> arges: Nothing. :)
[22:40] <infinity> wgrant: Is this an lpapi bug?
[22:41] <infinity> wgrant: It seems that when bdmurray is asking for getBuilds() on a package that was copied from a private PPA, it's going back to the PPA to get that info, which it then can't.  Despite the info being entirely public, if you look it up via the distro (say, in the web UI).
[22:42] <wgrant> infinity: It's not an LP API bug so much as a moronic model which I haven't fixed yet.
[22:42] <wgrant> It's trying to generate a link to the build, which crashes because it's in a private PPA that bdmurray can't see.
[22:42] <infinity> wgrant: A data model bug, kay.
[22:42] <wgrant> Yes.
[22:43] <wgrant> Fix is partially done.
[22:43] <infinity> wgrant: So the "correct" solution for now is, indeed, to just trap and skip the 401? :/
[22:53] <apw> bjf, ^^ i think this discussion is the same issue shanky was having with the linux-keystone copy
[22:54] <wgrant> infinity: I think so. The current model is broken in a way that can't easily be worked around.
[22:55] <infinity> wgrant: Fun.  Kay.  Merged Brian's fix, then.
[22:55] <infinity> apw: If shanky was vomiting on trying to determine if builds were complete, then yes.
[22:56] <infinity> apw: I hadn't been expecting Ike to build in a private PPA and copy it to yours. :/
[22:56] <infinity> But oh well.
[22:56] <infinity> That also shouldn't break as amazingly as it does.
[22:57] <wgrant> (the solution that I need to finish off is to partially copy builds when their binaries are copied, so the references are always intra-archive, preventing crossing of privacy domains)
[22:57] <infinity> stgraber: Ooo, more apparmor changes AGAIN too.  Right after jdstrand uploaded a bunch of things with apparmor changes that said "match lxc apparmor" ;
[22:59] <infinity> stgraber: Can you check and see if, for instance, the latest docker.io upload matches lxc alpha1 or alpha2, and if it needs changing again? :)
[23:00] <doko> rejecting the binutils, gdb and gcc-4.9 uploads. building these in a ppa, and then copying the binaries, so that test results are available
[23:02] <infinity> doko: "So that test results are available"?
[23:02] <infinity> doko: Or do you mean so you can test before you're satisfied with copying?
[23:03] <infinity> (Which makes sense)
[23:03] <stgraber> infinity: I think it's all fine. We had a chat with jdstrand a few days back, as a result of that he uploaded some profile changes to LXC which I then pushed upstream, so what's upstream in alpha-2 matches what he pushed as patches a few days earlier to the archive.
[23:04] <infinity> stgraber: That's not what the diff in the queue says.
[23:04] <stgraber> infinity: and he re-used those same patches for docker.io now, so I believe we've got the same thing everywhere (the same also applied to libvirt).
[23:04] <stgraber> infinity: ah?
[23:05] <infinity> stgraber: I don't speak fluent apparmor, so maybe it's functionally the same, but it's definitely not identical.
[23:05] <infinity> The signal and ptrace stuff changed a bit, and you deny an extra mount option.
[23:06] <infinity> stgraber: First three files in http://launchpadlibrarian.net/186338094/lxc_1.1.0~alpha1-0ubuntu5_1.1.0~alpha2-0ubuntu1.diff.gz
[23:06] <doko> infinity, well, I tested locally, but having the test results available without regressions is the testing I need for all archs
[23:07] <doko> fuck
[23:07] <infinity> doko: Sure, I just was curious what you meant by "available", since an archive or PPA build is identical in its ability to produce test results.
[23:07] <doko> sorry, I accepted :-/
[23:07] <infinity> doko: If you meant you want test results before you copy to the archive, so you can opt not to, that's entirely sane.
[23:08] <infinity> Of course, you'd have to be able to actually use the queue correctly. :P
[23:08] <stgraber> infinity: indeed, what he pushed for docker.io looks like the kind of profile LXC had a while back. I have however no idea exactly what docker does nowadays so it may very well be right.
[23:08] <doko> pff, shouldn't accept something with a non-empty reject field
[23:08]  * infinity cancels the powerpc build before it kills the VM.
[23:09] <infinity> stgraber: Perhaps you and he should sync on that to be sure. :)
[23:09] <stgraber> infinity: the docker.io profile isn't wrong though and should be safe too, what jdstrand pushed to LXC those past few days are extra restrictions that are there for the unlikely case where the kernel doesn't do its job.
[23:09] <stgraber> jdstrand: here is one more ping for you :)
[23:10] <infinity> stgraber: Right, what I was driving at was that your lxc upload wasn't identical to his.
[23:10] <stgraber> infinity: so I'm pretty sure LXC's version of those profiles is right since we talked about them at length with jdstrand and I included them as-is, it could be that docker.io and libvirt-bin should also be using that new version, or not, I don't know.
[23:10] <infinity> stgraber: So, wondering if things got weirdly out of sync again, or if yours is more correct, or if they're functionally the same despite being syntactically different.
[23:11] <infinity> stgraber: Discounting docker and libvirt entirely here, just the lxc bits are different.
[23:11] <doko> cancelled the other gcc-4.9 builds for now
[23:11] <infinity> stgraber: Oh.
[23:12] <infinity> stgraber: Derp, I'm missing that in the previous uploads those were patched in debian/patches.
[23:12] <stgraber> infinity: right, was about to point that out :)
[23:12] <stgraber> infinity: old LXC + debian/patches == new LXC
[23:13] <stgraber> if not, then cp is broken and decided to corrupt the profile in a valid way when I copied them upstream two days ago :)
[23:13] <stgraber> so sounds like we all agree then. Got to run, have a good evening!
[23:13] <infinity> stgraber: In that case, only the "+  mount options=(rw, slave) -> /," addition to start-container looks new.
[23:13] <infinity> stgraber: Unless that's from a previous patchset. :P