[01:36] <xnox> cjwatson: /me ponders where did I miss it.
[01:36] <xnox> checking.
[01:42] <xnox> yes.
[01:43]  * xnox had a strange feeling something is wrong when plymouth migrated without dri-tools.
[02:06] <xnox> please accept colord-gtk, split of libcolord-gtk library from the colord source package.
[02:20] <infinity> xnox: Why the split?
[02:21] <xnox> infinity: ask the uploader. /me has no clue, but as far as I can see something to do with not liking gtk portion of it.
[02:22] <infinity> I thought you had some insight, since you were demanding it be accepted. :P
[02:22]  * xnox just wants empty britney
[02:22] <infinity> +commit fca4196ed897e086fd917f489c38d95278e4b1df
[02:22] <infinity> +Author: Richard Hughes <richard@hughsie.com>
[02:22] <infinity> +Date:	2012-06-18
[02:22] <infinity> +
[02:22] <infinity> +    Split out colord-gtk to a new sub-project to prevent a dep loop
[02:22] <infinity> +
[02:22] <infinity> +    At the moment GTK requires colord to build, but colord-gtk needs
[02:22] <infinity> +    GTK to build.
[02:22] <infinity> +    This makes bootstrapping a distro (or using jhbuild) harder than it
[02:22] <infinity> +    needs to be.
[02:22] <infinity> That seems to answer it.
[02:23] <xnox> =)))
[02:23] <xnox> colord: - Remove colord-gtk packages that are now in a different source package
[02:23] <infinity> Yeah, your paste doesn't answer anything. :P
[02:23] <infinity> As I'd still ask "and why are they in a different source package?"
[02:24]  * infinity grabs the source to get all reviewy on its ass.
[02:24] <xnox> =)))))
[02:24] <xnox> ack, ack.
[02:28] <xnox> thanks a lot =)
[03:38] <xnox> why does britney not consider glew for transition?
[06:27] <slangasek> xnox: because there are binaries in raring-proposed that are out-of-date (because they're NBS), and those need removed first; fixing
[09:08] <xnox> slangasek: interesting. thanks.
[09:34] <psivaa> xnox: Just wondering about the ETA of the fix for bug 1068178 :)
[09:34] <ubot2> Launchpad bug 1068178 in ubiquity (Ubuntu Precise) "ubi-usersetup failed with exit code 1 on preseeded - encrypted-home installations on precise" [Undecided,Confirmed] https://launchpad.net/bugs/1068178
[09:35] <xnox> psivaa: let me check.
[09:36] <psivaa> Also i take precise desktop images being oversized is a known issue.
[09:58] <xnox> cjwatson: I have cherrypicked the fix for the ^^^^^ ubiquity issue for precise. Are you planning to make a new upload of ubiquity to precise again soon or should the current upload pass verification first?
[09:59] <infinity> xnox: Let the secure boot crap all pass and get promoted first, unless this bug's a showstopper.
[09:59] <infinity> xnox: Pretty please.
[10:01] <xnox> infinity: ack. It's a show-stopper for one test-case: automatic pre-seeding of default install with ecryptfs enabled.
[10:01] <xnox> infinity: targetted for 12.04.2 to make sure we include it.
[10:02] <infinity> xnox: Well, I'm sure it won't be the only bug we're trying to squeeze into .2 ;)
[10:02] <infinity> xnox: (or bugfix rather)
[10:02] <infinity> xnox: But yeah, the SB stuff kinda all needs to land in a big (hopefully working) group.
[10:04] <xnox> psivaa: right. we currently have sru for ubiquity with 7 bugs to verify and I am sorry this bug did not make it into this sru. http://people.canonical.com/~ubuntu-archive/pending-sru.html After those are verified, I'll upload the fix for the encrypted-home bug. Sorry for the delay.
[10:08] <psivaa> xnox: ok, hope it gets included in the next batch. thank you.
[10:08] <xnox> it will.
[11:48] <cjwatson> bdrung: In case you were wondering, I'm working on the reason that gworkspace didn't get copied to the release pocket (bug 1083131).
[11:48] <ubot2> Launchpad bug 1083131 in Launchpad itself "Closing bugs OOPSes on invalid UTF-8" [Critical,New] https://launchpad.net/bugs/1083131
[11:49] <bdrung> cjwatson: i haven't noticed it yet :)
[11:55]  * ogra-cb__ wonders why he didnt see the plymouth issue when upgrading his nexus7 
[11:56] <cjwatson> (I've confirmed that gworkspace is currently the only case where a publication was deleted from proposed without a successful copy to release and without having already been superseded by a later upload.)
[12:08] <xnox> ogra-cb: btw. should there not be libdrm-omap?
[12:08] <ogra-cb> i think its called libdrm2-omap (not sure, would need to check)
[12:09] <ogra-cb> and yeas, theer shoulld eb the omap one and the radeon and nvidia ones shoud go away on arm :)
[12:09] <ogra-cb> (as well as intel)
[12:10] <xnox> ogra-cb: for the debs in plymouth. Ah.. it's libdrm-omap1
[12:10] <ogra-cb> ah, right
[12:10] <ogra-cb> i knew there was a number in the name
[12:12] <ogra-cb> hmm, the nexus7 is really unhappy with the raring kernel :(
[12:18] <bdrung> cjwatson: FYI, a fixed gworkspace is uploaded (the changelog had ISO-88... and UTF-8 mixed)
[12:19] <cjwatson> I kind of wish you hadn't
[12:19] <cjwatson> I was going to use it as a test case for the fix
[12:19] <cjwatson> I guess I can still do that on dogfood
[12:19] <cjwatson> But it wouldn't have been necessary if you'd asked ;-)
[12:21] <bdrung> cjwatson: sorry. feel free to reject that upload
[12:22] <cjwatson> Can't
[13:42] <ogra-cb> hmm, the nexus7 build still fails on the plymouth issue
[13:43] <ogra-cb> is something stuck in NEW by chance ?
[13:45] <ogra-cb> http://paste.ubuntu.com/1389006/
[13:45] <seb128> ogra-cb, NEW is https://launchpad.net/ubuntu/raring/+queue?queue_state=0
[13:46] <xnox> ogra-cb: well I didn't add libdrm-omap1 dep on armhf, yet. I guess you need it like _now_
[13:46] <ogra-cb> yeah, nothing there
[13:46]  * xnox didn't understand the urgency earlier.
[13:46] <ogra-cb> xnox, no hurry
[13:46] <xnox> ogra-cb: did it work before?
[13:47] <seb128> ogra-cb, try to sudo apt-get install libdrm-intel1 libdrm-radeon1 libdrm-nouveau2 plymouth-theme
[13:47] <seb128> ogra-cb, to see what is the issue
[13:47] <ogra-cb> 0.8.8-0ubuntu1
[13:47] <ogra-cb> i have that one installed on the last nexus7 image
[13:47] <ogra-cb> didnt cause build issues
[13:48] <xnox> ogra-cb: and what is the current plymouth version?
[13:49] <ogra-cb> hmm, i dont get that
[13:49] <xnox> (for you / in that log failing to install)
[13:49] <ogra-cb> so the build from the 24th failed
[13:49] <ogra-cb> err
[13:49] <ogra-cb> 25th
[13:49] <ogra-cb> and todays too
[13:50] <ogra-cb> bur the one from the 24th worked with the same plymouth version
[13:51] <ogra-cb> http://cdimage.ubuntu.com/daily-preinstalled/20121124/raring-preinstalled-desktop-armhf+nexus7.manifest
[13:51] <xnox> I see only 24th log here: http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/raring/
[13:51] <ogra-cb> libplymouth2	0.8.8-0ubuntu1
[13:51] <xnox> where are the 25/26th logs?
[13:51] <ogra-cb> failed
[13:52] <ogra-cb> not sure why they arent copied, i got them by mail
[13:52] <ogra-cb> both have the above pastebin error
[13:52] <xnox> ogra-cb: can you forward them to xnox@u.c ?
[13:53] <xnox> well it should be 0.8.8-0ubuntu2 across the board
[13:54] <ogra-cb> ubuntu2 was only uploaded this night
[13:55] <ogra-cb> 3am according to raring-changes
[13:55]  * xnox was awake....
[13:55] <xnox> ogra-cb: so libdrm-intel1 is not built for armhf since quantal and up.
[13:55] <ogra-cb> well, i would assume a libdrm issue
[13:55] <ogra-cb> doesnt smell like plymouth
[13:55] <xnox> ogra-cb: but the later two are available, so why does the resolver tries to use the first one instead of any of the other two.
[13:56] <ogra-cb> well, why does it use them at all :P
[13:56] <ogra-cb> you will never find any compatible HW for either of these libs on arm
[13:57] <ogra-cb> but iirc the prob was that the initrd stuff needs to be rewritten to be able to drop them
[14:13] <cjwatson> ogra-cb: Hmm.  I assumed that that was due to needing s/libdrm-nouveau1a/libdrm-nouveau2/, which is why I asked xnox about that yesterday; but that isn't the problem any more.
[14:13] <cjwatson> xnox: The resolver message indicates that none of the three are installable.
[14:14]  * cjwatson sets up some raring-only chdist environments
[14:14] <ogra-cb> yeah, whats really so confusing is that i got one successfull built on the 24th with the accused to be broken plymouth version
[14:16] <ogra-cb> there was a libdrm upload on thesday it seems
[14:16] <ogra-cb> *tuesday
[14:17] <xnox> ogra-cb: and that was stuck in proposed until plymouth and dri-utils got rebuilt/fixed.
[14:18] <cjwatson> Hmm, can't seem to reproduce in chdist
[14:19]  * ogra-cb tries a dist-upgrade on the 20121124 image
[14:19] <cjwatson> Wonder if I can run a test build on my Nexus 7 :-)
[14:20] <cjwatson> It only really has to manage debootstrap, which should be fine ...
[14:20] <ogra-cb> you surely can, but i would suggest using a USB key/disk via the otg cable ... might be faster
[14:20] <cjwatson> Meh, debootstrap output isn't that large
[14:21] <ogra-cb> well, yes, and it wont be eath shattering faster either
[14:21] <ogra-cb> *earth
[14:21] <cjwatson> I'll give it a try in a few minutes once I've upgraded it sufficiently
[14:21] <hggdh> just a question -- are we now shipping kernel 3.5 by default on Precise?
[14:22] <ogra-cb> everything but GLES stuff should be buildable just fine on the nexus
[14:22] <cjwatson> hggdh: Yes, the quantal enablement stack
[14:22] <ogra-cb> and i bet even way faster than on any panda
[14:22] <hggdh> cjwatson: thanks
[14:22] <ogra-cb> (just disk io isnt thrilling)
[14:22] <cjwatson> ogra-cb: Once it has overlayfs support it should be a nice enough sbuild machin
[14:22] <cjwatson> e
[14:22] <ogra-cb> heh
[14:23] <ogra-cb> if you could charge while having a HDD attached we could use a stack of them as buildd farm :)
[14:23] <cjwatson> hggdh: For new installs, at any rate; nothing auto-upgrades existing installs
[14:24] <hggdh> cjwatson: yes, makes sense. We were just surprised to see new installs with 3.5 in QA. I do not remember receiving any notice it would be done now
[14:25] <cjwatson> ogra-cb: Are you running nexus7 builds by hand?  I don't see them in nusakan's crontab
[14:25] <ogra-cb> dist-upgrade seems to work fine here btw
[14:26] <cjwatson> hggdh: I probably assumed the kernel team would tell you :)
[14:26] <ogra-cb> cjwatson, i added them for 13:32
[14:26] <ogra-cb> right next to the lubuntu preinstalled ones
[14:26] <cjwatson> ogra-cb: Oh, never mind, failure to read default-arches
[14:26] <cjwatson> I was grepping crontab for nexus :)
[14:26] <ogra-cb> heh
[14:27] <Daviey> cjwatson: Hey, psivaa said they our precise daily images have quantal kernel?
[14:29] <cjwatson> Daviey: Scroll up :)
[14:29] <ogra-cb> aha
[14:29] <ogra-cb> https://launchpad.net/ubuntu/raring/+source/libdrm/2.4.40-1 says it was only published at 24th
[14:29] <ogra-cb> sad that it doesnt tell the time
[14:29] <cjwatson> Hover
[14:29] <ogra-cb> but i would guess its libdrm then
[14:30] <cjwatson> As in, if you mouseover the date, you'll get a tooltip
[14:30] <ogra-cb> since the image build of the 25th was the first that failed
[14:30] <cjwatson> Or whatever you call it
[14:30] <ogra-cb> hmm
[14:30] <Daviey> cjwatson: I understood that this would not impact server.
[14:30] <ogra-cb> 03:33 CET
[14:30] <ogra-cb> os that would mean it was available on the 20121124 image
[14:30] <ogra-cb> *so
[14:31] <ogra-cb> (thanks btw, didnt know about the tooltip)
[14:32] <ogra-cb> ARGH
[14:32] <ogra-cb> that dist-upgrade made my initrd go from 1.5M to 3M
[14:35] <cjwatson> Daviey: Perhaps it would make sense if all the people involved talked to each other.  It will be very very inconvenient to accommodate your request.
[14:35] <cjwatson> Daviey: What is the reason behind your request?
[14:39] <Daviey> cjwatson: I did just send a mail to those involved checking.. I thought that was what was agreed.
[14:39] <Daviey> cjwatson: Having a higher reliance on dkms and other stuff that reaches into kernel spae, concerns me that we are doing this.
[14:39] <Daviey> I thought server was purely sticking with the LTS kernel.. But i am checking for details now.
[14:41] <cjwatson> Then y'all need to tell me very clearly what you actually need.
[14:42] <cjwatson> And you won't get reliable secure boot support.  (You probably don't care, but I should be absolutely clear about this.)
[14:42] <ogra-cb> cjwatson, could it be that there is some issue with the mirror used to build the images ? i cant really figure out whats wrong, manual dist-upgrade just works
[14:42] <ogra-cb> as well as installing in a chroot
[14:42] <cjwatson> ogra-cb: No, it's reproducible in a local build here
[14:42] <ogra-cb> ah, good
[14:43] <cjwatson> Just working on debugging it now.
[14:43] <Daviey> cjwatson: Okay, yeah.. I'll stay shum until we have clarification.  Thanks
[14:44] <cjwatson> Daviey: It may not be too horrible to fix, I guess, but I need total clarity or else there'll be chaos as we go back and forth.
[14:45] <Daviey> cjwatson: yeah, just hold out.  It might be what was expected all along, but it wasn't what i heard.  So lemme get clarification
[14:46] <cjwatson> (Since I did go to the effort of making it parameterised by a variable in CONF.sh, so I could make that project-specific.)
[14:59] <cjwatson> ogra-cb: Ah.  I demoted libdrm-radeon1 from Priority: required to optional a bit too enthusiastically, apparently.
[14:59] <ogra-cb> oh, hard to catch
[14:59] <cjwatson> ogra-cb: The effect of this is that debootstrap's output has unsatisfied dependencies.
[14:59] <cjwatson> Fixed in the archive now, for the next publisher run
[14:59] <ogra-cb> k, i'll trigger a manual build in a few hours
[15:00] <cjwatson> That was the cause of the powerpc image build failures too.
[15:01] <ogra-cb> we really need to clean that up in an arch specific way some day ... on arm none of these libs make sense (apart from omap1)
[15:05] <ScottK> ogra-cb: Start your list now for the UDS-S spec of "stuff I wish I'd had time for in Raring."
[15:05] <ScottK> ;-)
[15:05] <ogra-cb> heh
[15:06] <ogra-cb> thats from the "list of things i wish i had had time for in natty"
[15:08] <ogra-cb> its not like thats a new issue ... just rather complex due to the initramfs involvement
[16:19] <GunnarHj> infinity: ping
[17:14] <xnox> cjwatson: I think rsyncable is broken on the desktop iso's. Over the past week right now I have hit with zsync "no relevent local data found" will redownload the whole file.
[17:14] <cjwatson> Don't know, I'm afraid; depends rather on squashfs-tools' behaviour
[17:14] <xnox> cjwatson: and when ogra-cb & infinity were poking (one of the cd building softwares) they may have mentioned lack of gzip --rsyncable options.
[17:14] <cjwatson> I don't recall there being a special option for it or anything
[17:15] <cjwatson> But gzip isn't used ...
[17:15] <xnox> hmmm
[17:15] <cjwatson> At least not anywhere that matters much
[17:15] <xnox> (it may have been something for nexus7)
[17:15] <cjwatson> Anyway, AFAICS --rsyncable just isn't documented, but exists
[17:15] <cjwatson> Compare the output of 'gzip --rsyncable' and 'gzip --garbage'
[17:16] <ScottK> Shortly (once digikam is updated) we'll be in a position where only two packages block getting all of KDE 4.10 beta 1 (4.9.80) from raring-proposed to raring.  Those both need upstream porting due to API changes, so I think we don't want to wait.  Would the preferred approach be to force everything in despite those packages or to remove their binaries and then everything should migrate naturally?
[17:17] <cjwatson> Hmm
[17:17] <cjwatson> It screws users of those packages either way
[17:17] <cjwatson> Are the packages on your images?
[17:18] <ScottK> One of them is.
[17:19] <ScottK> The part I don't understand though is why the impact isn't just two versions of the library for awhile?
[17:19] <cjwatson> Then it's probably best to remove the binaries so that images can keep building, and file an RC bug as a reminder.  I'm concerned that this approach undermines the message about raring being continuously usable, though.
[17:19] <cjwatson> Oh
[17:19] <xnox> cjwatson: I do wonder how I can debug my zsync problem.
[17:19] <cjwatson> ScottK: If that's all it is, it should be OK to force it
[17:19] <ogra-cb> xnox, cjwatson, --rsycable isnt set fr tarballs inside live-build
[17:19] <cjwatson> britney considers the situation as if all NBS were removed
[17:19] <ScottK> Ah.
[17:19] <ogra-cb> debian-cd uses it
[17:19] <ScottK> Now I understand better.
[17:19] <cjwatson> Or all NBS from the new source anyway
[17:19] <ogra-cb> for the images themselves
[17:20] <ScottK> Who can force stuff?
[17:20]  * xnox adds a todo item.
[17:21] <cjwatson> ScottK: ~ubuntu-release
[17:22] <ScottK> Is there an ubuntu-archive-tools script for that or more properly, what wiki page or some such should I be reading instead of harassing you?
[17:22] <cjwatson> ScottK: First time, you need to edit britney.conf in ~ubuntu-release/britney/britney2-ubuntu to add a hint permission for yourself (just follow the pattern)
[17:22] <ScottK> OK.
[17:22] <cjwatson> er with lp: on front
[17:22] <ScottK> Gathered that bit.
[17:22] <cjwatson> ScottK: Then create a file for yourself in lp:~ubuntu-release/britney/hints-ubuntu with the hints you want
[17:23] <cjwatson> http://ftp-master.debian.org/testing/hints/README has the syntax
[17:23] <ScottK> Thanks.
[17:23] <cjwatson> I should probably wikify this at some point
[17:26] <ScottK> Then once the packages move, the hint can be removed ....
[17:29] <cjwatson> At your leisure, yes
[17:29] <ScottK> Thanks.  I think I'm all set up now.
[17:31] <ogra-cb> SHRIEK !!
[17:31] <ogra-cb> http://paste.ubuntu.com/1389492/
[17:32] <ogra-cb> so that build obviously failed
[17:48] <ogra-cb> grmbl
[17:48] <ogra-cb> there was no upload that could have caused live/build to break that way i think
[17:49] <xnox> ogra-cb: well, seb128 did upload pyxdg
[17:49] <ogra-cb> oh
[17:50] <xnox> ogra-cb: and I wonder which file it's processing & fails on.
[17:50] <ogra-cb> seb128, seems that broke update-apt-xapian-index somehow
[17:50] <ogra-cb> obviously a kde one
[17:51] <ogra-cb> but we dont log anything from subprocesses called in hooks during build it seems
[17:51] <xnox> ... and there were plently of kde uploads lately migrating.
[17:51] <ogra-cb> so its hard to get more info beyond the tracback
[17:51] <seb128> ogra-cb, urg, sorry about that ... I was unsure how to test it so I mostly relied on the upstream test suit, seems that was not enough ... looks like a good case to add regression tests
[17:51] <cjwatson> Run it locally and then you can just chroot in and try again
[17:53] <seb128> ogra-cb, it traceback on /usr/share/app-install/desktop/spout:spout.desktop
[17:54] <seb128> Categories:Application:Game:ArcadeGame
[17:54] <seb128> it doesn't like that syntax error
[17:55] <ogra-cb> bah, silly games
[17:55] <seb128> that's the only issue
[17:55] <seb128> if you move that .desktop away it works
[17:57] <seb128> ogra-cb, want to fix app-install-data?
[17:58] <seb128> ogra-cb, I need to run for ~1 hour but I can have a look later if needed, I will look at making pyxdg robust to those parsing errors but the easy fix is to update spout:spout.desktop to use "Categories=...;...;..;"
[17:58] <seb128> that's the lack of "=" that makes the parser unhappy
[17:59] <cjwatson> I'll fix the spout source package now
[18:00] <seb128> cjwatson, thanks
[18:05] <seb128> the pyxdg "bug" was introduced in http://cgit.freedesktop.org/xdg/pyxdg/commit/xdg/IniFile.py?id=39407c25769dd90ab9d5e8ee4c49b08f2d3f7089
[18:05] <seb128> - index = line.find("=")
[18:05] <seb128> - key = line[0:index].strip()
[18:05] <seb128> - value = line[index+1:].strip()
[18:05] <seb128> + key, value = line.split("=", 1)
[18:05] <seb128> well it was probably buggy before but not hitting an exception
[18:05] <cjwatson> uploaded; it'll need somebody to refresh app-install-data-ubuntu once that's in place
[18:05] <cjwatson> Heh, upstream filed a bug on Ubuntu's spout package, even
[18:05] <seb128> do we need/want a pyxdg workaround upload? like revert that diff?
[18:06] <seb128> or is that ok to wait for app-install-data-ubuntu to be refreshed?
[18:06] <cjwatson> Meh, it was busted, let's just fix a-i-d-u
[18:06] <seb128> works for me
[18:06] <cjwatson> I can poke it after dinner
[18:07] <cjwatson> (i.e. manual refresh if necessary)
[18:07] <seb128> thanks
[18:07] <seb128> need to run, bbl
[18:48] <infinity> GunnarHj: ?
[18:51] <GunnarHj> infinity: Hi Adam, I was about to ask for your help to publish a few im-switch SRUs. ScottK seems to have done it already, though. Possibly he missed the quantal one. Maybe you can check if that's still in some queue?
[18:52] <infinity> GunnarHj: I see nothing named im-* in the quantal queues.
[18:53] <ScottK> I think I got that one.
[18:53]  * ScottK looks
[18:53] <infinity> Oh, unless by "queue", you mean "archive".
[18:53] <ScottK> GunnarHj ...
[18:53] <ScottK> --- Releasing im-switch ---
[18:53] <ScottK> Proposed: 1.22ubuntu2.1
[18:53] <ScottK> Release:  1.22ubuntu2
[18:53] <ScottK> Copied to quantal-updates
[18:54] <GunnarHj> infinity, ScottK: I don't see it yet at https://launchpad.net/ubuntu/+source/im-switch, but I just got an email, so it's probably in the archive soon. Thanks!
[18:54] <infinity> GunnarHj: You want /$version/+publishinghistory on the end of that.
[18:54] <infinity> GunnarHj: It should show you the pending records.
[18:55] <GunnarHj> infinity: Aha, thanks for the tip.
[18:55] <infinity> https://launchpad.net/ubuntu/+source/im-switch/1.22ubuntu2.1/+publishinghistory <-- For example.
[18:55]  * ScottK went through and released all the verified SRUs within the last hour.
[18:56] <infinity> ScottK: Thanks.  Now I get to flood proposed with a bunch of queue reviews today.
[18:56] <ScottK> Yes.  Please.
[18:56] <infinity> And the cycles continues...
[18:57] <seb128> infinity, thanks in advance for doing queue reviews ;-)
[19:02] <ogra-cb> cycling keeps you fit :)
[19:03] <seb128> great, one of the two powerpc building just picked up libreoffice to build
[19:04] <seb128> building->builders
[19:05] <infinity> Yes, fat software needs building too.
[19:06] <seb128> infinity, I'm more annoyed by the n_builder = 2 and the fact that nothing will move out of proposed to raring until the powerpc backlog is cleared :p
[19:07] <ScottK> I've scored down builds on powerpc that I knew would fail to keep them from blocking up stuff until the queue is empty.
[19:07] <seb128> oh, great, it failed
[19:07] <ogra-cb> heh
[19:08] <seb128> well, everything graphical is failing due to the out-of-sync-between-arch of fontconfig
[19:08] <seb128> ok, dinner time, bbl
[19:09] <ScottK> seb128: I just scored fontconfig up then.
[19:10] <infinity> seb128: You can be annoyed about it all you want, but I'm not sure what good it will do. ;)
[19:11] <mdeslaur> FYI, powerpc delay annoys the heck out of me too :P
[19:13] <ogra-cb> arent we supposed to be over that soon ?
[19:13] <ScottK> All it takes is a DCE to go revive sulfur.
[19:13] <ScottK> Tomorrow apparently.
[19:15] <infinity> Yeah, that's "all it's needed" for a while now.  Just a bit light on staff in London right now. :/
[19:57] <seb128> infinity, well, the issue is that there is always a good reason and a solution "soon" but the fact is that powerpc is an issue again and again and again every cycle
[19:57] <seb128> ScottK, thanks
[19:57] <ScottK> At least there's a third builder down and down one = 2 and not =1.
[19:57] <seb128> infinity, it's blocking SRUs, delaying normal work for 99% of users for the benefit of 1% etc
[19:59] <ScottK> That last Main builds in the quantal backlog are building now.
[21:20] <ScottK> Of course fontconfig becomes installable on powerpc just as the digikam build that I know will fail half way through starts ...
[21:26] <infinity> Timig: iz everything.
[21:26] <infinity> Timing, too.
[21:27] <ScottK> You shouldn't have corrected yourself.  I thought that was some new lolcat dialect with which I was not familiar.
[21:29] <cjwatson> Uploading that app-install-data-ubuntu update now.
[21:40] <jamespage> please could the NEW packages for walinuxagent be accepted for raring; start of the SRU process for a critical fix....
[21:48] <infinity> jamespage: Reading that bug and the fix kinda made me die a little inside.
[21:51] <jbicha> please reject the previous gnome-shell upload and I hope I don't lose my place in the SRU line :|
[21:52] <infinity> jbicha: Old one rejected, review rescheduled for January 3rd.
[21:53] <infinity> jbicha: (I'm working on a bunch of reviews this afternoon/evening, we'll so how many I can get through)
[21:53] <infinity> s/so/see/
[21:53] <jbicha> infinity: yay! I should be able to get the paperwork done by January
[23:49] <ScottK> OK.  Now that I retried everything that failed due to fontconfig uninstallibity, the powerpc build queue is looking suitably crappy again.