=== Pici is now known as TalkingMuffin
[01:23] <seb128> infinity, bdmurray, slangasek: could somebody review the GTK update in the saucy SRU queue?
[05:47] <Noskcaj> since Qt 5.2 should fix the powerpc issues, do you plan to make an ubuntu powerpc release for 14.04?
[05:49] <infinity> Noskcaj: It should?
[05:49] <infinity> They stopped using v8?
[05:49] <infinity> And actually use something portable?
[05:50] <Noskcaj> infinity, From what i understand, 5.2 will use a custom JS engine
[05:50] <infinity> Anyhow, qt5/v8 isn't the only concern for PPC desktop, the bigger one is if anyone would actually use it at all (I use a lot of PPC machines, and not a single one has a monitor, mouse, or keyboard...)
[05:50] <infinity> Noskcaj: Sure, but does "custom" mean "portable" and "runs on PowerPC"? :P
[05:51] <Noskcaj> I'm pretty sure it works for PPC, although i can't be sure till the release (mid-december)
[05:51] <infinity> Anyhow, if the desktop suddenly becomes buildable, runnable, and testable, I'm sure we can re-evaluate if it's worth reviving the ppc/desktop CD, but not much point talking about it before that.
[05:51] <Noskcaj> makes sense
[05:52] <infinity> 3D drivers are at least as large a concern.
[05:52] <infinity> The non-free drivers (obviously) don't work, as they're x86 binary blobs, and the radeon driver is known-broken on !x86.
[05:53] <infinity> nouveau, as far as I know, works fairly well, but that's less than half of the PPC desktop install base out there, I'd bet, since ATI was the default on all but the last PPC Macs.
[10:58] <xnox> please accept alsa-plugins-extra from trusty/new, it's a reupload of "alsa-plugins" to move libav into universe. This will also resolve libasound2-plugins-extra NBS.
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[15:49] <xnox> cjohnston: why is automake-1.14 not in ubuntu?
[15:50] <cjohnston> xnox: tab complete fail?
[15:50] <xnox> cjwatson: why is automake-1.14 not in ubuntu
[15:50] <cjwatson> because the new source replaces a binary from a source with Ubuntu modifications
[15:51] <cjwatson> needs manual resolution
[15:51] <xnox> cjohnston: i was about to, of course tab complete on automake fails, since 1.14 is not there =))))))
[15:51] <xnox> cjwatson: ack.
=== med_ is now known as med
=== med is now known as med_
[16:11] <cyphermox> I'm noticing icu-devtools is broke, file conflicts with icu-tools (its old name) -- shouldn't britney be catching these things? is that skipped somehow for debian imports?
[16:12] <cjwatson> that's not catchable by proposed-migration, which only looks at the metadata - the problem here is precisely that the metadata was missing
[16:12] <cjwatson> xnox is working on that bug
[16:13] <cjwatson> and no, proposed-migration is certainly not skipped for Debian syncs :-)
[16:13] <cjwatson> bug 1246566
[16:13] <ubot2> Launchpad bug 1246566 in icu (Ubuntu) "package icu-devtools (not installed) failed to install/upgrade: trying to overwrite '/usr/sbin/gensprep', which is also in package icu-tools 4.8.1.1-12ubuntu2" [High,Triaged] https://launchpad.net/bugs/1246566
[16:13] <mdeslaur> ah crud, what'd I break?
[16:13] <cjwatson> 15:10 <cjwatson> xnox: do you think you could sort icu?  Debian did the multiarching with a slightly different package name to your multiarch patch last cycle, so I think we need an Ubuntu-specific patch to add breaks/replaces
[16:14] <cjwatson> 15:10 <cjwatson> and carry that until after trusty
[16:14] <mdeslaur> d'oh :(
[16:14] <cyphermox> alright then, I'll skip right to fixing ust then
[16:15] <cjwatson> right, that one's bug 1246620
[16:15] <ubot2> Launchpad bug 1246620 in ust (Ubuntu) "upgrade failed: trying to overwrite '/usr/lib/x86_64-linux-gnu/liblttng-ust-tracepoint.so.0.0.0', which is also in package liblttng-ust0:amd64 2.1.1-6" [High,Triaged] https://launchpad.net/bugs/1246620
[16:15] <cyphermox> ah, thanks!
[16:18] <xnox> bah, forgot to upload. uploaded now.
[16:18] <mdeslaur> thanks xnox for unborking icu
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== Ursinha_ is now known as Ursinha
=== rsalveti_ is now known as rsalveti
[18:50] <cjwatson> "Not touching package as requested in bug 1246814 on Thu Oct 31 17:32:14 2013"
[18:50] <ubot2> Launchpad bug 1246814 in haskell-src-exts (Ubuntu) "test block-proposed bug" [Undecided,Invalid] https://launchpad.net/bugs/1246814
[18:50] <cjwatson> good enough for now (ubuntu-devel-announce)
[18:52] <Laney> for /your/ uploads - is that enforced?
[18:53] <cjwatson> No, I meant to say - no access control right now but I'll add it if there's abuse
[18:53] <cjwatson> I don
[18:54] <cjwatson> 't expect it to be a major problem given that you can see it right there in excuses
[18:55] <Laney> Hmm, I expect that people will use it to block the uploads of others without thinking that there's a problem policy-wise
[18:55] <Laney> We'll see. Thanks for implementing
[18:57] <slangasek> bdmurray: so, cjwatson just sent an announcement about a new bug tag to use for blocking packages in $devel-proposed for proposed-migration ^^ ...  I think we might want this same tag to feed into the pending-sru report
[18:57] <slangasek> even though we're not using proposed-migration there
[18:58] <kirkland> howdy!  can someone accept promote lxc 1.0.0~alpha1-0ubuntu12 from proposed -> updates?  the verification is "done" at https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1244301 (I've confirmed the fix too)
[18:58] <ubot2> Launchpad bug 1244301 in lxc (Ubuntu Saucy) "lxc-attach stopped working for docker containers" [High,Fix committed]
[18:58] <cjwatson> slangasek: isn't that kind of implicit in it not being v-done yet?
[18:59] <cjwatson> kirkland: No, https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1242913 is still v-needed
[18:59] <ubot2> Launchpad bug 1242913 in lxc (Ubuntu Saucy) "/dev/pts being created with mode=600 by Lxc" [High,Fix committed]
[18:59] <cjwatson> kirkland: And besides it's only 3 days old; usually uploads age for 7 days before going to -updates
[19:00] <cjwatson> (minimum)
[19:00] <slangasek> cjwatson: we are meant to be tracking new bugs filed against SRUs in -proposed; seems like it would be useful to use a consistent bug tag, particularly as people may cargo cult that tag anyway :)
[19:01] <cjwatson> slangasek: Oh, you mean when it has both saucy and trusty tasks
[19:01] <cjwatson> Yeah, maybe
[19:01] <slangasek> yes
[19:08] <infinity> I love how the subject line there reads as "(I'm) Temporarily blocking your uploads..."
[19:09] <cjwatson> Mwahaha
[19:13] <seb128> bdmurray, infinity: ^ would be nice if somebody could review those empathy SRUs for precise and saucy, facebook did server side changes that make empathy unable to connect
[19:14] <infinity> seb128: Doesn't affect libpurple/pidgin?
[19:14] <infinity> Clearly not, I guess, since I'm still connected.
[19:14] <seb128> infinity, I don't think so, empathy was just doing something wrong with libsoup
[19:16] <bdmurray> slangasek: okay, I'll have a look
[19:16] <infinity> seb128: Upload in progress for trusty, or hoping for a forward copy here so you can be lazy?
[19:16] <seb128> infinity, I was going for the copy but I can upload if you prefer
[19:17] <seb128> infinity, starting next week I switch in t-mode and will stop with copies
[19:29] <seb128> infinity, thanks
[19:29] <seb128> lunch time
[19:29] <seb128> bbl
[20:05] <kirkland> cjwatson: aha!  I missed the second bug associated with that upload;  I just verified that fix too
[20:05] <kirkland> cjwatson: as for the 7 days, I'll ask docker's users on their mailing list to be patient
[20:55] <ogra_> bah
[20:55] <ogra_> cyphermox, dont tempt me !
[20:55] <ogra_> (my chromebook worked fine the last 6 months ... and now you upload that ! ... )
[20:56]  * ogra_ tries to resist the urge to tinker ... and upgrade to trusty
[21:05] <cyphermox> heheheh
[21:05] <cyphermox> ogra_: works on trusty... but not unity yet
[21:05] <cyphermox> let me figure out 3D first :)
[21:05] <cyphermox> that is, unless you can live with all the window decorations in xfce being garbld
[21:07] <ogra_> nooo !
[21:07] <ogra_> i have working unity atm ...
[21:08] <ogra_> despite half of the compositing stuff running in mesa (while the actual GLES bits run on the mali lib), it runs very well
[21:09] <ogra_> thats why i didnt upgrae yet ... i cant remember how i got there and really dont want to break it
[21:09] <infinity> cyphermox: Erm, can I vomit and kick and scream over the part where these drivers ship the same binary and conflict with each other?
[21:10] <infinity> cyphermox: Why can't this be one driver that detects what it needs to do and picks the right paths? :/
[21:11]  * ogra_ vanishes into the night again 
[21:11] <cyphermox> infinity: I didn't spend too much time looking at it, partly because I barely understand any of it
[21:11] <cyphermox> infinity:  I was just trying to make it so that I could build it and scratch my itch, while hopefully not breaking the world for everybody else
[21:12] <cyphermox> I'm hoping I didn't do too much damage :)
[21:14] <infinity> cyphermox: Well, there's a complete lack of upgrade path here for people who previously had armsoc installed.
[21:15] <infinity> What hardware was that built for?
[21:15] <cyphermox> samsung chromebook, back then, afaik
[21:15] <cyphermox> so, yeah, doh
=== maxb_ is now known as maxb
[21:15] <cyphermox> (exynos0
[21:16] <infinity> Yeah, looks like exynos.
[21:16] <infinity> So, you need to replace that one.  And probably also provide a transitional package.
[21:16] <cyphermox> yeah
[21:17] <infinity> I'm going to reject your NEW binaries to avoid breakage.
[21:17] <cyphermox> thanks
[21:18] <infinity> So, versioned breaks/replaces from armsoc-exynos to armsoc, and then an empty armsoc that depends on armsoc-exynos.
[21:18] <infinity> That should make it look saner to me.
[21:22] <cyphermox> yeah
[22:07] <seb128> infinity, bdmurray, slangasek: can we reduce a bit the SRU delay for the current saucy SRU of hud? It fixes the most common issues on e.u.c (seems it's currently segfaulting for most users)
[22:07] <infinity> seb128: Let me look.
[22:10] <slangasek> seb128: do you have a pointer to a current error bucket that shows it's not happening with the version in proposed?
[22:11] <infinity> Certainly looks safe enough.
[22:12] <seb128> infinity, slangasek: https://errors.ubuntu.com/problem/a0c6b9dc3bbefa98b1a31a88ed621b181b3a6fbe
[22:13] <seb128> slangasek, ^ that seems to confirm it
[22:14] <infinity> seb128: Is someone working on https://launchpad.net/bugs/1237882 ?
[22:14] <ubot2> infinity: Error: launchpad bug 1237882 not found
[22:14] <infinity> And working on making it not private. :P
[22:15] <seb128> infinity, I was just checking with ted, it's fixed in 13.10 vcs, we are going to upload another SRU when the current one moves to updates
[22:15] <infinity> But yes, that bucket seems to shoe that the #1 crasher is fixed.
[22:15] <infinity> I'm happy to release it.
[22:15] <infinity> (done)
[22:15] <seb128> great
[22:15] <seb128> infinity, thanks!
[23:15] <cyphermox> infinity: http://paste.ubuntu.com/6338329/   better?
[23:47] <infinity> cyphermox: xserver-xorg-video-armsoc-pl111 needs to break/replace armsoc as well, since it also ships overlapping files.
[23:47] <cyphermox> >.<
[23:47] <infinity> cyphermox: And xserver-xorg-video-armsoc-pl111 and xserver-xorg-video-armsoc-exynos don't need to Replace each other, the Conflict is enough.
[23:48] <infinity> Same for the debugs.
[23:49] <infinity> cyphermox: You could also transition armsoc-dbg, but I'm less picky about that, I suppose.
[23:49] <cyphermox> hmm
[23:50] <infinity> cyphermox: Should definitely have the break/replace mojo on the debugs, the transitional package probably less interesting, but no real harm in providing it.
[23:51] <cyphermox> there, done
[23:51] <cyphermox> http://paste.ubuntu.com/6338445/
[23:52] <cyphermox> I know all of this, I just suck at applying it consistently :/
[23:55] <infinity> cyphermox: That looks reasonable.