=== zequence_ is now known as zequence
[09:20] <cjwatson> mlankhorst,tjaalton: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt seems to indicate some parts missing from the current Xorg transition
[09:22] <mlankhorst> cjwatson: yeah just geode was missing it seems
[09:22] <cjwatson> synaptics and wacom too?
[09:22] <mlankhorst> doubt it
[09:22] <cjwatson> and I can't work out what's going on with xpra ...
[09:22] <cjwatson>     * i386: arkose, arkose-gui, arkose-nautilus, boinc-amd-opencl, boinc-nvidia-cuda, edubuntu-desktop, fglrx, fglrx-amdcccle, fglrx-amdcccle-updates, fglrx-dev, fglrx-updates, fglrx-updates-dev, kubuntu-active, kubuntu-desktop, kubuntu-full, kubuntu-netbook, ltsp-client, lubuntu-core, lubuntu-desktop, mythbuntu-desktop, starpu-contrib-examples, ubuntu-desktop, ubuntu-gnome-desktop, ubuntustudio-desktop, ...
[09:23] <cjwatson> ... ubuntustudio-graphics, virtualbox-guest-x11, winswitch, xorg, xpra, xserver-xorg-input-all, xserver-xorg-input-synaptics, xserver-xorg-input-synaptics-dbg, xserver-xorg-input-wacom, xserver-xorg-input-wacom-dbg, xubuntu-desktop, xvba-va-driver
[09:23] <mlankhorst> I'm pretty sure that one ought to be correct
[09:24] <mlankhorst> only reason I didn't notice geode is that support for that was kind of dropped and it's a package in universe
[09:24] <cjwatson> hmm, they are indeed both being upgraded, wtf
[09:24] <cjwatson> it's definitely not just as simple as geode
[09:25] <mlankhorst> maybe the autohinter hates the x stack? :P
[09:25] <cjwatson> the autohinter is doing the right thing
[09:25] <cjwatson> also my experience is overwhelmingly that britney is generally correct, just obtuse :P
[09:25] <seb128> cjwatson, one issue is that it tries libxi and libxfixes in different batches it seems
[09:26] <cjwatson> seb128: that shouldn't be related to the server stack?
[09:26] <seb128> cjwatson, laney tried to put them together, and the only problem that I got with the output from that run was geode
[09:26] <seb128> cjwatson, well, they both breaks old server/unity
[09:26] <cjwatson> same libxi6 dependency from xserver-xorg-input-synaptics in both saucy and saucy-proposed
[09:26] <mlankhorst> I guess a manual hint might need ALL the packages currently in -proposed related to the x stack..
[09:27] <seb128> cjwatson, https://launchpad.net/ubuntu/+source/libxi/2:1.7.1.901-1ubuntu1
[09:27] <seb128> "  * Add a breaks to xorg-server 1.13 and old unity."
[09:27] <seb128> so they should be going in the same run
[09:27] <cjwatson> that doesn't explain why an autohint that doesn't include libxi would show broken input packages
[09:27] <seb128> cjwatson, if you look at the top of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt that's what Laney tried ... and I think geode was the only issue there
[09:28] <seb128> hum, right
[09:28] <cjwatson> I see it but it's sufficiently incomplete that it's impossible to tell if geode is the only issue there
[09:28] <seb128> maybe it's not that easy :/
[09:28] <seb128> well, geode should be published/about to
[09:28] <seb128> so let's see what happens on the next update?
[09:28] <cjwatson> geode is already being autohinted
[09:28] <cjwatson> it is clearly not the problem
[09:28] <seb128> ok
[09:28]  * seb128 starts pbuilder again
[09:29] <mlankhorst> maybe all the package updates needs to be specified, not just xorg-server?
[09:29] <cjwatson> mlankhorst: I'm not looking at Laney's hint
[09:29] <cjwatson> I'm looking at the autohint further down
[09:30] <Laney> look at the massive hint at the end
[09:30] <cjwatson> I haven't yet seen a reason why libxi needs to come with the new server, only why the new server needs to come first
[09:30] <cjwatson> which the autohinter should manage
[09:30] <cjwatson> Search for "Trying easy from autohinter: xorg-server" - that's what I'm looking at
[09:30] <seb128> well, libxi Breaks: old-xserver ... shouldn't that force them to come together?
[09:31] <mlankhorst> cjwatson: yeah and nowhere does the autohinter consider unity, libxfixes, libxi together there..
[09:31] <mlankhorst> (with the new xorg-server)
[09:31] <mlankhorst> so I fear this may need a manual hint
[09:32] <cjwatson> why does that break synaptics?
[09:32] <cjwatson> specifically that, and not e.g. xserver-xorg-core
[09:32] <mlankhorst> synaptics links against libxi, I guess
[09:32] <cjwatson> seb128: that's only a problem if the new libxi is used
[09:32] <cjwatson> which it isn't in this autohint ...
[09:33] <cjwatson> synaptics links against libxi, but its dependency on libxi6 hasn't changed so I don't see why it should've been rendered uninstallable
[09:33] <cjwatson> Ah
[09:33] <cjwatson> xserver-xorg-core Breaks: libxi6, not just the other way round
[09:33] <cjwatson> *That* actually makes sense
[09:34] <cjwatson> Laney: OK, shall I do a massive manual hint and drop yours, now that I understand the problem?
[09:34] <mlankhorst> do itt
[09:34] <seb128> cjwatson, thanks for debugging ;-)
[09:34] <Laney> Go ahead
[09:34] <seb128> in a pbuilder it looks like things should work with the correct hint
[09:34] <seb128> let's see if that's really true ;-)
[09:35] <cjwatson> it seems mostly plausible in chdist
[09:35] <Laney> I found out the same by noticing that synaptics had a bumped depends on -xorg-core
[09:36] <cjwatson> both directly and via xorg-input-abi-19
[09:36] <Laney> indeed
[09:37] <mlankhorst> well the direct bump is added automatically by the build script too
[09:37] <cjwatson> looks like I missed the current p-m run, but they're frequent enough
[09:47] <cjwatson>     * armhf: pvr-omap4, pvr-omap4-dbg, pvr-omap4-dev, xserver-xorg-video-armsoc, xserver-xorg-video-armsoc-dbg, xserver-xorg-video-msm, xserver-xorg-video-msm-dbg
[09:47] <cjwatson> can those be fixed?
[09:49] <seb128> mlankhorst, ^
[09:49] <infinity> That's all meant to be "fixed" by the alternate xserver on armhf.
[09:49] <infinity> Though, I think we should discuss just dropping that and the pvr drivers.
[09:49] <infinity> I'm not sure the maintenance burden is worth having Panda desktop images anymore.
[09:50] <infinity> (I have to run off to a meeting in 5, though, so that discussion can't happen right now)
[09:50] <ogra_> infinity, as i said before... we need *some* armhf desktop image
[09:50]  * ogra_ totally doesnt care what platform that is on, but we need one 
[09:51] <infinity> ogra_: We only need it if someone's actively using it and testing it.  Otherwise, all it's doing is showing that the deps are installable, which britney handles.
[09:51] <ogra_> well, indeed, i expect QA to regulary test the desktop apps on it
[09:51] <ogra_> to make sure they dont regress
[09:52] <mlankhorst> pvr-omap4 cannot be fixed, all the arm crap I don't know
[09:52] <ogra_> mlankhorst, thats whay we decided to not change the x stack on arm, no ?
[09:52] <infinity> mlankhorst: No, it can't be fixed, but britney also shouldn't be whining about it being uninstallable if you have the alternate xserver in place.
[09:52] <cjwatson> what package is this alternate X server in?
[09:52] <mlankhorst> cjwatson: hm it's not in the archive atm, I have it in a ppa
[09:53] <infinity> That would be why. :P
[09:53] <ogra_> LOL
[09:53] <mlankhorst> but I don't think the armhf would pick it up anyway
[09:53] <cjwatson> why not?
[09:53] <mlankhorst> since it requires removing xserver-xorg-core and install xserver-xorg-core-omap-rename
[09:54] <infinity> The latter of which provides the right abi-foo virtual though, right?
[09:54] <mlankhorst> yeah
[09:54] <cjwatson> um, why isn't it packaged such that this alternate package *is* xserver-xorg-core on armhf?
[09:54] <infinity> Although, this also means futzing with ubuntu-desktop.
[09:54] <cjwatson> renaming the package is a mistake
[09:54] <mlankhorst> because that breaks the tegra stuff
[09:54] <mlankhorst> which does have an updated package
[09:54] <cjwatson> you may find this turns out to paint yourself into a corner
[09:55] <infinity> cjwatson: It's for the sake of one driver, doing what you suggest would be declaring that pvr-omap4 is the only armhf driver.
[09:55] <cjwatson> video-all is going to get very confusing ...
[09:55] <infinity> This whole thing is a mess.  And I really think we need to revisit it.
[09:55] <infinity> I'm running off.  Can we pick this up later in the EU afternoon?
[09:55] <mlankhorst> not really, the -omap rename doesn't depend on -video-all or -input-all, it hard depends on evdev renamed only
[09:55] <cjwatson> either way, britney is doing the right thing in holding this out of saucy until it's fixed
[09:56] <mlankhorst> and xf86-video-omap-revert..
[09:58] <cjwatson> it'd be great to at least get this into NEW ...
[09:58] <mlankhorst> tjaalton: can you upload the omap-revert packages?
[10:06] <mlankhorst> oh wait that'd probably fail too, needs some build fixes and a bump
[10:13] <xnox> ogra_: i thought, ubuntu-desktop-nexus7 could have been an "armhf desktop image" which is easier to maintain than pandaboard.... but it looks like ubuntu-desktop-nexus7 is no longer on cdimage at all.
[10:13] <mlankhorst> yeah pandaboard is unmaintainable at this point
[10:13] <ogra_> xnox, it was dropped by management decision
[10:14]  * ogra_ would have preferred to keep n7 over panda
[10:14] <xnox> ogra_: i see.
[10:14] <xnox> ogra_: but even raring/quantal images are gone as well? or are they still archived somewhere?
[10:14] <ogra_> they are on cdimage.ubuntu.com/releases/
[10:15] <xnox> ogra_: thanks, found it.
[10:16] <ogra_> :)
[10:24] <mlankhorst> same, we can't really maintain the pandaboard because upstream dropped support for it :/
[10:25] <ogra_> ?
[10:25] <ogra_> we were talking about tegra3
[10:26] <mlankhorst> ogra_: yeah but I meant that supporting something that's no longer supported will result in these weird solutions..
[10:26] <ogra_> yeah, i think that was clear from the beginning though
[10:26] <ogra_> though the initial word was also that saucy wouldnt see a newer Xserver at all
[10:27] <ogra_> i think the panda decision was based on that back when it was done
[10:27] <mlankhorst> yeah but we need it if we ever want to backport some touch fixes
[10:28] <ogra_> yup, *i* understand that ... (and i wasnt the one making the decision ... i would just have kept the n7 images in maintenance mode, tegra Xserver is the easiest for arm desktop)
[10:28] <mlankhorst> indeed..
[10:29] <ogra_> panda should just stay around for server community tests or so ...  if we want to go on suporting a dead arch
[10:48] <mlankhorst> ok xorg-server-omap-revert seems to build
[11:14] <mlankhorst> enjoy^
[11:15] <infinity> Do I have to?
[11:27] <tjaalton> :)
=== psivaa is now known as psivaa-lunch
[13:04] <jdstrand> zul: hey, what is the status of apache? if I look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html (and I am reading it correctly), it looks like uwsgi is the only thing holding back the migration
[13:04] <zul> jdstrand:  yeah xnox has been doing alot of if it in debian
[13:05] <jdstrand> ok, cool
[13:05] <xnox> jdstrand: i thought uwsgi was fixed....
[13:05] <xnox> ah it ftbfs across the board.
[13:05] <jdstrand> I don't know-- it just says "uwsgi has no up-to-date binaries on any arch "
[13:06] <jdstrand> xnox: I think that is the last one, no?
[13:06] <cjwatson> I already contacted the Debian maintainer about that
[13:06] <cjwatson> jdstrand: read update_output.txt, not update_excuses.html
[13:06] <cjwatson> update_excuses is the first stage
[13:06] <cjwatson> there's a lot of things still to fix
[13:06] <jdstrand> hrmm
[13:07] <jdstrand> this is blocking all our application confinement work on the phone
[13:07] <cjwatson> specifically, search for "Trying easy from autohinter: apache2"
[13:07] <cjwatson> well, (1) help welcome (2) there's always the possibility of building in a devirt PPA with saucy-proposed disabled and then copying in, to bypass this transition
[13:08] <cjwatson> but we need to clear this transition rather than forever messing about with (2), so it's a last resort
[13:08] <jdstrand> we'd like to help, but this is not planned work...
=== cking_ is now known as cking
[13:09] <jdstrand> '2' is somewhat problematic, cause I already did the migratino for apparmor, but yeah, I could back that out I guess
[13:09] <mlankhorst> cjwatson: oh can you add msm/armsoc to your massive list?
=== psivaa-lunch is now known as psivaa
[13:09] <mlankhorst> that should only leave pvr-omap4 as blocker
[13:10] <mlankhorst> no idea how to fix that yet
[13:10] <cjwatson> mlankhorst: done
[13:10] <cjwatson> jdstrand: could be a .1 type version based on what's currently in saucy
[13:12] <mlankhorst> cjwatson: can I force pvr-omap4 somehow? it should be installable when the omap-revert packages get accepted
[13:13] <cjwatson> mlankhorst: no.
[13:13] <cjwatson> I'll work my way through the omap-revert packages (already did the server)
[13:13] <mlankhorst> ok
[13:13] <cjwatson> but I'm not generally prepared to force uninstallability - the guard's there for a reason
[13:14] <mlankhorst> can I give it a manual solution for installability in this case? eg preinstall xserver-xorg-core-omap-revert before installing ubuntu
[13:14] <mlankhorst> ubuntu-desktop*
[13:15] <cjwatson> You shouldn't need to, once it's in the archive
[13:15] <mlankhorst> we'll see
[13:16] <cjwatson> There's only one provider of the relevant video ABI, surely, so britney has no choice anyway
[13:16] <cjwatson> I would not expect that part to be a problem
[13:24] <cjwatson> mlankhorst: britney solves the graph - it will try to see if there is *any* path by which ubuntu-desktop (and indeed any other relevant package) is installable
[13:24] <cjwatson> mlankhorst: so by definition you don't need to (and can't) provide it with manual solutions
[13:25] <mlankhorst> hm lets see
[13:25] <cjwatson> if there's one to find, it will find it
[13:25] <mlankhorst> darn i forgot to update pvr-omap4
[13:26] <cjwatson> didn't you say it just needed the server packages with reverted abi?
[13:26] <mlankhorst> yeah but the versioned depends won't work
[13:27] <cjwatson> I only see a versioned build-depends
[13:27] <cjwatson> which, yes, is worth updating, though technically it won't block proposed-migration
=== cjohnston_ is now known as cjohnston
[13:29] <mlankhorst> hm yeah you're right
[13:29] <cjwatson> (worth updating> assuming that it isn't buildable with the new xserver-xorg-dev, anyway)
[13:31] <mlankhorst> true, seems it comes with omap_pvr_drv precompiled
[13:32] <jdstrand> I don't really understand http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[13:32] <jdstrand> I get why apache2 isn't migrating, but the i386 line lists things which have been fixed
[13:33] <cjwatson> it tries promoting given sets of source packages (with all their binaries) in turn, and either accepts them or tells you which sets of binary packages are broken as a result
[13:33] <cjwatson> jdstrand: example
[13:33] <jdstrand> I see
[13:34] <jdstrand> so, why is http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html not as good to look at? it seems to say what's ready and what isn't from the list of things that failed to migrate
[13:34] <cjwatson> update_excuses is solely package-local checks
[13:34] <jdstrand> eg, on the list, apparmor is a valid candidate
[13:34] <cjwatson> it's the first stage of proposed-migration's processing
[13:34] <cjwatson> it is NOT equivalent to update_output
[13:35] <cjwatson> update_output is the second stage, and actually calculates resulting uninstallability, which is not in general calculated at the update_excuses stage
[13:35] <jdstrand> so, since apparmor is listed in update_output.txt, does that mean it is still broken or that it just isn't migrating?
[13:35] <cjwatson> it isn't listed in the result of the apache2 autohint
[13:36] <cjwatson> it's listed in the set of packages that are trying to be promoted together - so it's not broken in itself, but that group is blocked
[13:36] <jdstrand> I see
[13:36] <cjwatson> you're perhaps making the mistake of looking under "trying: apache2"
[13:37] <cjwatson> that's an automatic attempt to promote apache2 on its own (p-m tries every package on its own, since that's simplest), which is obviously not going to work since this is a complex transition
[13:37] <jdstrand> this is the first time I've looked hard at this report. just getting up to speed on the format
[13:37] <cjwatson> the relevant block is the one that starts "Trying easy from autohinter: apache2/2.4.4-6ubuntu2"
[13:37] <cjwatson> anyway, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661958 is arguably a better place to look for the state of the transition at the moment, since this is mostly being done in Debian
[13:37] <ubot2`> Debian bug 661958 in release.debian.org "transition: apache2 2.4" [Normal,Open]
[13:38] <jdstrand> it isn't clear to me how to see what needs to be fixed from update_output.txt
[13:38] <jdstrand> the parts under the autohinter?
[13:38] <cjwatson> yes
[13:39] <jdstrand> jeez. what a mess
[13:39] <cjwatson> like I say, the Debian bug is a more user-friendly place to look for this
[13:39] <cjwatson> I did warn that it might not be a good idea to start this transition yet, but people didn't listen to me *shrug*
[13:39] <cjwatson> but now it's started we need to finish it
[13:40] <cjwatson> looks like http://wiki.debian.org/Apache/PackagingFor24 is the master set of instructions for porting
[13:41] <jdstrand> yeah-- used that for apparmor
[13:41] <jdstrand> cjwatson: if I build in a ppa, I should pocket copy to -proposed still. correct?
[13:41] <cjwatson> well
[13:41] <mlankhorst> ok with those pvr-omap4 should be installable again
[13:42] <cjwatson> in general yes but it may be difficult in this case
[13:42] <cjwatson> it might be better for somebody else to hand-check that the package's dependencies are unchanged on all arches and copy it directly to saucy
[13:42] <cjwatson> requires a lot of care, but may be easier than fighting with the existing version in -proposed
[13:43] <cjwatson> I'd rather that you didn't have to undo the patches in -proposed
[13:43] <jdstrand> cjwatson: hrm. this likely isn't going to be a one time upload. we have quite a bit of work we are pushing
[13:44] <jdstrand> we could try to minimize the extra uploads
[13:44] <jdstrand> *sigh*
[13:44] <cjwatson> zul: are you still working on porting modules?
[13:44] <zul> cjwatson:  yep
[13:44] <cjwatson> ok, good
[13:45] <cjwatson> in Debian I hope :)
[13:45] <zul> cjwatson: ill be getting them into debian
[13:45] <cjwatson> I'd recommend doing it in Debian first - we don't win anything much by duplicating this work in Ubuntu
[13:46] <cjwatson> we can NMU if need be, but we're not in Debian import freeze yet so the autosyncer will do a bunch of stuff for us and I think we need the review
[13:46] <mlankhorst> heh finally
[13:46] <mlankhorst> SUCCESS (163/0)
[13:46] <cjwatson> ah, good, that's without xf86-video-omap-revert and xserver-xorg-input-evdev-omap-revert even
[13:46] <mlankhorst> lol
[13:47] <mlankhorst> it needs those though
[13:47] <cjwatson> great, that'll make things more readable.  thanks :)
[13:47] <cjwatson> well, no single package is uninstallable without them
[13:47] <cjwatson> anyway, I just accepted them so they should land soon enough
[13:47] <jdstrand> cjwatson: so, currently apparmor is at 2.8.0-0ubuntu19 in saucy, and 2.8.0-0ubuntu21 in saucy-proposed. if I were to try to keep things going smoothe moving forward, I should do two uploads-- ubuntu19.1 to the ppa (without 2.4) and ubuntu22 (keeps 2.4) to -proposed?
[13:47] <cjwatson> jdstrand: yeah
[13:47] <mlankhorst> weird.. I thought xserver-xorg-core-omap-revert should be uninstallable
[13:47] <cjwatson> can't have been
[13:47] <jdstrand> ok, thanks
[13:48] <mlankhorst> hm I wonder why..
[13:48] <cjwatson> it doesn't depend on input-evdev or video-omap
[13:48] <mlankhorst> no but xorg should have
[13:48] <cjwatson> but xorg is installable with xserver-xorg-core
[13:49] <cjwatson> xorg + xserver-xorg-core-omap-revert aren't *co*installable, but proposed-migration doesn't check arbitrary coinstallability (that gets into serious NP-complete territory)
[13:49] <mlankhorst> ah
[13:50] <mlankhorst> I guess it makes sense then
[13:54] <cjwatson> good, new stack publishing now all in one piece
[13:54] <cjwatson> well, aside from the two modules above
[13:54] <mlankhorst> \o/
[13:54] <cjwatson> thanks for the help
[13:54] <mlankhorst> np
[13:57] <mlankhorst> Laney: can you add xf86-video-omap-revert xserver-xorg-input-evdev-omap-revert xorg-server-omap-revert xf86-video-armsoc to xorg pkgset?
[13:58]  * cjwatson decides the most effective use of his time may in fact be trying to hurry along this transition, rather than needing to help with lots of manual checks and copies ...
[13:59] <mlankhorst> and perhaps mesa-demos
[14:04] <Laney> mlankhorst: mail to devel-permissions please
[14:28] <cjwatson> Riddell: I've disabled your amarok force - it's dangerous to do that before it's at least built on i386
[14:28] <cjwatson> please wait a bit longer
[14:29] <cjwatson> Riddell: and in any case isn't the right answer to remove the armhf binaries if they're unsupportable?  force hints are a last resort and need discussion
[14:29] <Riddell> cjwatson: ok yes I'll do that (although upstream says he might be able to add it back now)
[14:29] <cjwatson> need to check reverse-depends
[14:30] <cjwatson> ok, nothing of interest
[14:31] <cjwatson> (remuco-amarok is arch: all so doesn't count)
[14:39] <infinity> Riddell: As a general operating rule, if you really think something needs a force hint, could you discuss it here before doing it?  They're almost always harmful in some way, and cleaning up after them can be painful.
[14:39] <infinity> (And there's usually a better way, like fixing or removing packages)
[14:42] <Riddell> infinity: gotcha, sorry
=== mbarnett` is now known as mbarnett
[15:13] <SpamapS> oh wow.. wading into the SRU queue I expected a 2 page quagmire. It's actually caught up!
[15:18] <infinity> SpamapS: On behalf of everyone who made that happen, we're sorry for ruining your fun.
[15:18] <SpamapS> hahaha
[15:26] <ChrisTownsend> Hi, for the Unity 12.04 SRU, the fix for https://bugs.launchpad.net/unity/+bug/1083186 caused a small regression seen in https://bugs.launchpad.net/unity/+bug/1195730.  I have a fix for the regression, but I feel that we should still move forward with the SRU and target the fix in the next SRU.
[15:26] <ubot2`> Ubuntu bug 1083186 in compiz (Ubuntu Precise) "icaclient windows "dancing" when decorated" [Undecided,New]
[15:26] <ubot2`> Ubuntu bug 1195730 in Unity 5.0 "Maximized windows opened during login not actually maximized (when using 5.20 from -proposed)" [Low,In progress]
[15:27] <infinity> ChrisTownsend: If you have a targetted fix, why not just reupload with that included, and verify quickly?
[15:28] <ChrisTownsend> infinity: I still need to get the MP approved and then pester folks to get the fix in the the package proper and have them upload it.
[15:30] <ChrisTownsend> infinity: People have been waiting on this SRU for quite some time and I'd hate to delay it further.
[15:32] <ScottK> ChrisTownsend: SRUs are supposed to be regression free.
[15:32] <infinity> ChrisTownsend: There's no reason it needs to go upstream first.  Show me the patch, and I'll sponsor it.
[15:32] <ChrisTownsend> ScottK: Yes, I agree. Just wanted to see what can be done here.
[15:32] <ChrisTownsend> infinity: Ok, just a second.
=== plars_ is now known as plars
[15:33] <ChrisTownsend> infinity: Here is my MP: https://code.launchpad.net/~townsend/unity/fix-extra-decorations/+merge/173027 - one line change
[15:34] <ChrisTownsend> infinity: Bug reporter for the regression has verified it works with a build in my PPA and the original bug is still fixed.
[15:34] <infinity> Yeahp, I saw.
[15:34] <ChrisTownsend> infinity: Ok, cool.  Thanks for your help!
[15:38] <infinity> ChrisTownsend: What's your preferred email, while I'm pretending to be you...
[15:39] <ChrisTownsend> infinity: Heh, christopher.townsend@canonical.com is fine.
[15:41] <infinity> ChrisTownsend: http://paste.ubuntu.com/5855722/ <-- Okay with that having your name on it?
[15:42] <ChrisTownsend> infinity: Yep, looks good.
[15:53] <infinity> ChrisTownsend: Alright, re-accpted.  When it builds, please get some light re-verification of the previous bugs, and a solid verification of the regression bug.
[15:54] <ChrisTownsend> infinity: Ok, will do.  Thanks again!
[15:55] <ChrisTownsend> infinity: Could you add Precise to the unity source package for that regression bug?  I don't have the power to do that.
[15:56] <infinity> ChrisTownsend: Oh yeah, sec.
[15:57] <infinity> ChrisTownsend: Done.
[15:58] <ChrisTownsend> infinity: Thanks
[16:02] <infinity> ChrisTownsend: Given the nature of this 1-line fix, if you can re-verify all the other bugs, and make sure this regression's happy with the binaries in -proposed, I can release it without waiting yet another 7 days.
[16:02] <infinity> ChrisTownsend: Just poke me when you know it's good.
[16:03] <ChrisTownsend> infinity: Oh, awesome, will do.
[16:57] <jdstrand> can someone verify that apparmor 2.8.0-0ubuntu19.1 from https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages is ok to pocket copy directly to sauncy?
[16:58] <jdstrand> I can perform the pocket copy, but was asked to ask first
[16:59] <jdstrand> saucy even
[17:04] <cjwatson> jdstrand: checking
[17:08] <bdmurray> cjwatson / slangasek: could one of you merge the phased-updater? https://code.launchpad.net/~brian-murray/ubuntu-archive-tools/phased-updater/+merge/171142
[17:12] <stgraber> cjwatson: xz => real	11m8.745s
[17:12] <stgraber> cjwatson: pxz => real	4m22.247s
[17:12] <stgraber> will make my python code automatically use pxz if it's around as that's a rather nice improvement (that test was on my laptop, so with only 4 threads, nusakan should be even faster)
[17:15] <cjwatson> jdstrand: looks fine dependency-wise
[17:16] <jdstrand> cjwatson: cool. I've tested it and all that. is this an ack for the copy?
[17:16] <cjwatson> jdstrand: yes
[17:17] <cjwatson> jdstrand: though paste the copy command first?
[17:17] <cjwatson> just paranoid
[17:17] <cjwatson> bdmurray: sorry - done now
[17:17] <cjwatson> stgraber: excellent :)  working output as well?
[17:17] <bdmurray> cjwatson: no problem, I guess we are still waiting on your merge proposal anyway
[17:17] <cjwatson> yep :-/
[17:18] <cjwatson> https://code.launchpad.net/launchpad/+activereviews
[17:18] <stgraber> cjwatson: as far as I can tell, it's good, yes
[17:19] <jdstrand> cjwatson: ./copy-package -b --ppa=ubuntu-security-proposed -s saucy --to-primary saucy apparmor
[17:19] <jdstrand> ah, missed something
[17:20] <jdstrand> ./copy-package -b --ppa=ubuntu-security-proposed -s saucy --to-primary --to-suite saucy apparmor
[17:21] <cjwatson> jdstrand: go ahead, just double-check the output has the right version
[17:22]  * jdstrand nods
[17:24] <jdstrand> meh, it failed, but I'm heading into a meeting (http://paste.ubuntu.com/5855972/)
[17:25] <infinity> jdstrand: --ppa is the owner --ppa-name is the name.  You missed the latter.
[17:26] <jdstrand> --ppa=ubuntu-security-proposed --ppa-name=ppa seems to be working
[17:27] <jdstrand> infinity: thanks
[17:27] <jdstrand> y
[17:29] <cjwatson> ah yes
[17:30] <jdstrand> cjwatson: thanks for the review. pushed
[19:17] <ChrisTownsend> infinity: Hey, I've verified all of those Unity bugs and it looks good now.
=== ara is now known as Guest89175
[21:14] <ScottK> I had thought it might be a good idea to document the results on today's TB decision on GPL/openssl exceptions on https://wiki.ubuntu.com/ArchiveAdministration, but I don't see any obvious place to put it.
[21:14] <ScottK> Suggestions?
=== Trevinho_ is now known as Trevinho