[00:03] * infinity is finally home. [00:08] infinity: that was a long trip back home [00:09] ogra_: That -lGL bit will fail on powerpc. [00:09] stgraber: The bit where I was in hospital for a day slowed me down. [00:09] infinity: ouch, what happened to you? [00:10] stgraber: Kidney stones. Fun times. [00:13] infinity: ouch :( [00:15] infinity, why ? [00:15] no meas on ppc ? [00:15] *mesa [00:15] ogra_: Err, no, you're only setting -lGL on x86_64 and i686 [00:16] ogra_: Whereas, previously, it was on all arches. [00:16] oh, right, whats the machine string for ppc again ? [00:16] ogra_: You probably want NOT STREQUAL "armv7l" or something. [00:16] ogra_: Since that's what you mean. Listing every GL arch is silly. [00:16] what i want is "else" [00:17] but silly cmake doesnt have that [00:17] ogra_: Better yet, not making it arch qualified at all, don't we already have a magic "using gles" flag we can test? [00:17] or the guarantee that one set overrides a former one [00:18] infinity, looking at the build it actually sets everything properly already i think its not needed at all [00:18] They do override the former, except that it's being done in an additive fashion. [00:18] And dropping -lGL and -lGLU entirely, if the flags are added elsewhere, is an even better option, yeah. [00:19] right, i was waiting for rsalveti's feedback for that one [00:19] my cmake hack is rather thought as a last resort [00:19] if (${CMAKE_SYSTEM_PROCESSOR} STREQUAL "armv7l") [00:19] set (UNITY_STANDALONE_LADD "-lunity-core-${UNITY_API_VERSION} -lm") [00:19] else () [00:19] set (UNITY_STANDALONE_LADD "-lunity-core-${UNITY_API_VERSION} -lm -lGL -lGLU") [00:19] endif () [00:19] ^-- From /CMakeLists.txt [00:19] fun [00:20] Assuming UNITY_STANDALONE_LADD is used for the subproject, you can probably just ditch that bit from dash/previews/CMakeLists.txt [00:20] yeah, i wonder why they define it at all [00:20] Though, it doesn't appear to be.. [00:21] Still this is all silly and fragile to be doing it based on uname and not a config flag. :/ [00:21] It should be based on BUILD_GLES [00:21] yep, but at least its consistently odd :) [00:22] Which is defined. [00:22] yup ... like -fPIC that should be set based on defaults :) [00:22] I'd just move that armv7l bit into the BUILD_GLES stanza that follows. [00:23] but i surely wont rewrite the unity build system tonight [00:23] fPIC should just be the default, period. [00:24] I'm sure the only reason it isn't is because they added it to fix a build failure on amd64, not realising that they really want it on all arches. [00:24] heh, take a look at any of the CMakeList.txt files in the unity tree [00:24] Yeah, I'm looking right now. [00:24] Silly. [00:29] ogra_: http://paste.ubuntu.com/1182617/ [00:29] ogra_: Something like that should do. [00:29] ogra_: (Not fixing the fPIC mess with that, just cargo-culting as you did) [00:30] ogra_: But that should fix the linking issue. [00:32] ogra_: Want me to test and push something along those lines? [00:32] ogra_: It's pretty late for you. :P [00:34] * infinity reapplies against the current version and tests. [00:39] http://paste.ubuntu.com/1182627/ [00:39] ogra_: ^-- Testing that patch right now. [00:51] infinity, my testbuild with the first patch just finished [00:51] so at least there are no subsequent build issues [00:51] ogra_: Alright. well, I'm testing mine on all 5 arches. [00:51] ogra_: If it seems happy, I think I'll upload it. [00:51] great [00:52] thanks so much ... i'll make Łukasz pay us a lot beers at UDS :) [00:55] though probably seb should pay half of it ... he was the actual uploader and signer [00:56] Applying patch disable_standalone-clients.patch [00:56] patching file CMakeLists.txt [00:56] Hunk #1 FAILED at 156. [00:56] 1 out of 1 hunk FAILED -- rejects in file CMakeLists.txt [00:56] Patch disable_standalone-clients.patch does not apply (enforce with -f) [00:56] ^-- Why the heck is that non-fatal?! [00:57] heh [00:57] infinity: because of the hand-hacked rules for coping with arch-specific series files, which should be taken out and shot? [00:58] (but most importantly, taken out) [00:58] on my TODO [00:58] I would suggest it be done now [00:58] Yeah. I suspect that patch isn't even necessary now. [00:58] If this stuff all builds, then it clearly isn't necessary. [00:58] Given that it DIDN'T APPLY ANYWAY. [00:58] yeah [00:59] So, if this pass works everywhere, I'll drop that hunk of sad. [00:59] though it didnt apply because you edited CMakeLists.txt, no ? [00:59] ogra_: No, it had nothing to do with my edits, unless this is the pickiest quilt ever. [00:59] well, either way, the directory referenced by that patch doesn't exist [00:59] so it should be dropped [01:00] and debian/rules sanitized [01:00] Yeah, doing. [01:00] * ogra_ isnt sure we should put that much cleanup worn in [01:00] *work [01:00] It's 5 seconds. [01:00] And I've already done it. :P [01:01] Plus, I'm on drugs. CMake projects make sense right now. [01:01] i mean, the whole thing needs to be repacked from scratch anyway [01:01] non-native ... cleaned up etc [01:01] the non-native issue is orthogonal [01:01] well, if its done already ... *shrug* [01:02] and as infinity has just shown, the existing rules are so broken that they would prevent the package from FTBFS reliably if something comes un-stuck with this current fix. Ripping out the bad code is definitely the right thing to do [01:03] true [01:03] anyway, 3am ... i'll crawl towards my bed ... [01:04] what a weekend ... [01:04] ogra_: 'night... :) === yofel_ is now known as yofel [04:32] infinity: thanks for fixing telepathy qt [04:36] slangasek: I had a bit of an accidental nap while testbuilding, unity's uploaded now. :P [04:36] infinity: I'm testing the same patch now [04:36] infinity: the older one that is part of the specific rules can also be gone [04:36] which helps if you want to remove the hack at rules [04:37] another thing that I just changed as well is removing the dependency on gcc-4.6 [04:37] as it's not needed anymore [04:37] rsalveti: I removed the patch and the arch-specific patch hack completely. [04:37] cool [04:37] rsalveti: I didn't drop the gcc build-dep, I'll let that wait until post-beta. [04:38] rsalveti: My diff: http://launchpadlibrarian.net/114595044/unity_6.4.0-0ubuntu3_6.4.0-0ubuntu4.diff.gz [04:38] infinity: why is this a native package [04:38] ? [04:39] rsalveti: I'm sure more cleanup could be done (like -fPIC for all arches, for instance), but this was a minimal "make it work" thing. [04:39] sure [04:39] rsalveti: No idea why it's native, not going to switch/fix that for them today. :P [04:39] I just dropped the gcc because I was using icecc to build [04:39] and it was forcing gcc-4.6, which was then skipping icecc [04:40] shadeslayer: NP. [04:41] infinity: yup, just installed and it worked fine [04:41] infinity: so this patch is good to get it all working [04:41] and it's quite fast I must say, just missing the kernel fix to avoid the flickering, which we'll try to fix after b1 [04:42] and, built fine with gcc-4.7 for amd64 and armhf [04:42] so we can drop it later on [04:45] * infinity drugs himself up and goes back to bed. [04:58] infinity: Thanks for taking care of telepathy-qt. [05:00] ScottK: Want to review and accept that unity in the queue as compensation? :) [05:00] ScottK: (Test-built it on all 5 arches here, seems good) [05:01] Depends on how long I last before I time out. I've been offline all of today and most of yesterday, so I have a pile of stuff in the queue. [05:07] infinity: accepted [05:08] debdiff looks reasonable and matches what I've read on IRC today. Hoping that one will finally work for everyone... [06:01] hello [06:02] does anyone from the release team happen to be awake? [06:02] I'd like to discuss postgresql-9.1 [06:38] infinity: can you do a merge request of your CMakeLists.txt changes against lp:unity at some point so that the changes don't get forgotten? [07:19] ogra_: unity runs for me now \o/ but it seems to flicker a lot; have you seen this? [08:01] slangasek: got a minute for discussing postgresql-9.1? [08:01] pitti: hmm, I can try :) [08:02] so, I uploaded 9.1.5-2 to unapproved last Friday with two bug fixes that are milestoned for b1 [08:02] I didn't get an IRC response or review, so I re-synced the same thing into quantal-proposed where it built [08:03] slangasek: -2 is still in the unapproved queue and shoudl be rejected, but I kept it to provide the queue diff for the -release review [08:03] slangasek: I'd recommend getting this in, as it fixes upgrades from precise which we hope to get testers for [08:04] so if I get a +1, I can reject the unapproved upload and copy -proposed to quantal [08:06] yay, unity [08:07] Can I accept those syncs from unapproved if I'm happy with them? [08:07] pitti: ah, I reviewed it and accepted before seeing the last comment [08:08] iulian: yeah [08:08] OK. [08:08] using 'queue' is preferred to the web UI, although I forget exactly what the UI does wrong [08:08] slangasek: oh, does that even work? the same versino is already in -proposed, after all? [08:08] pitti: sorry, I meant I copied from -proposed [08:09] slangasek: ah, c'est parfait [08:09] slangasek: merci [08:11] Laney: Yup, I've been teaching myself how to use those tools. Well, just queue and queuediff. [08:13] The only thing the web UI does desperately wrong is that it doesn't present binary overrides sensibly [08:13] It's fine to use it for accepts and such [08:13] one thing I did have to use it for is to reject one copy of the same (source, version) [08:13] how do I do that with queue? [08:13] reject by ID [08:14] queue reject [08:14] which you can get from queue info [08:14] ah, that works, cool [08:14] For the experimental freeze a while back I asked people to use the API client because we were specifically testing that [08:14] But that wasn't a long-term prescription or anything [08:15] That said I personally prefer using the client [08:18] * Laney switches default_milestone [08:22] pitti: will you copy postgres over? [08:22] Laney: slangasek already did [08:22] hm, I don't see it [08:22] https://launchpad.net/ubuntu/+source/postgresql-9.1/+publishinghistory [08:23] oh, +pu [08:23] yeah [08:23] not published yet [08:23] the version page doesn't [08:23] cheers === henrix_ is now known as henrix [08:27] * Laney disables cronned builds [08:34] Hmm, no queuebot? [08:39] Is there a log somewhere I can look at to see who did what? [08:39] not sure how far along queue audit is [08:39] there's certainly been some work on it [08:40] I don't believe there is anything of use right now. [08:40] * iulian nods. [08:41] https://bugs.launchpad.net/launchpad/+bug/885739 [08:41] Ubuntu bug 885739 in launchpad "queue and override manipulations should have an audit trail" [High,In progress] [08:41] * iulian looks. [08:42] StevenK has been working on an auditor interface, much of which has landed, but I have no idea how to get at the audit logs === tjaalton_ is now known as tjaalton [08:44] cyphermox: would it be possible to resolve the evolution-related items on http://people.canonical.com/~ubuntu-archive/nbs.html before beta, at least those in main, preferably without taking a whole new upstream of the evolution stack? I tried rebuilding evolution-exchange but it FTBFS ... [08:44] Nice. [08:56] cyphermox: everything I've tried there so far dies with direct-inclusion errors [08:57] someone was porting -exchange [08:58] perhaps it was cyphermox, but something in my head is telling me chrisccoulson [09:02] it wasn't me :) [09:14] Riddell: ScottK: Should we be building kubuntu active for B1? [09:17] cjwatson, re evo, those are non trivial, the upstream apis had quite some changes [09:17] cjwatson, we should probably drop some of those sources like contacts or dates, stuff that are unmaintained upstream for years [09:21] I don't especially care but I'm not removing anything without audit-trail bugs :-) [09:22] ok, building a set of images [09:22] cjwatson, when do you want that sorted? is end of day today or tomorrow ok? [09:22] cjwatson, I want to talk to cyphermox first before dropping stuff, but he's not up before a few hours [09:23] Laney: yes please, although it needs a bugfix first [09:23] ok, well it'll build but we can spin it again later [09:26] seb128: sure, that's fine, just post-holiday "what's the archive looking like" checks [09:27] cjwatson, sorry about that, part my fault, with Didier on holidays I had to step up to help getting the stuff from #ps landing for ff and I didn't manage to do lot of +1 due to that :-( [09:45] Please accept ubiquity 2.11.27 it fixes bug 1044545 which prevents opening manual partitioning in ubiquity. [09:45] Launchpad bug 1044545 in ubiquity "ubiquity crashed with AttributeError in on_partition_use_combo_changed(): 'PageGtk' object has no attribute 'partition_format_checkbutton'" [Critical,In progress] https://launchpad.net/bugs/1044545 [09:45] Laney: ^^^^ [09:46] xnox: when the diff appears [09:46] Laney: ok thanks. And I guess I owe 14 birdseeds to the release team by now.... [09:47] did you mean to not sponsor it properly for Omer? [09:48] Laney, did you guys consider the stuff I mailed the list about on saturday? [09:49] like indicator-session [09:49] seb128: not yet [09:49] :-( [09:49] I'll look at it in a minute [09:50] you want indicator-session s-c-p indicator-messages considered? [09:54] Laney: no, I did not mean to sponsor it properly for Omer. I did mean to have multi-maintainer changelog. [09:55] ok, well, looks "DOH" enough [09:55] * Laney accepts [09:55] Laney: thanks.... and respin later?! =) [09:55] yes. later. [09:55] after considering these desktop updates [09:56] slangasek, yay, awesome, thanks for testing :) [09:56] also is the release bot asleep? =) [09:56] * Laney wonders how long these guys upstairs need to assemble a desk [09:57] Laney, yes [10:04] slangasek, oh, and yes, i have seen the flickering too, but i think thats post-beta stuff, having a desktop at all was my beta target :) [10:06] xnox: needs stgraber to fix [10:08] ok [10:12] So am I allowed to upload to quantal-proposed for stuff which is not critical for beta1 [10:12] e.g. fix for bug 523896 [10:12] Launchpad bug 523896 in shadow "useradd: cannot lock /etc/passwd; try again later." [High,In progress] https://launchpad.net/bugs/523896 [10:12] ? [10:12] Yeah [10:13] Or you can dump it in the unapproved queue and we can ignore it until later :-) [10:13] (i.e. upload to quantal, if it's relatively unlikely anyone else will need to for that package) [10:14] ok. [10:17] slangasek: Could you review efilinux-signed in NEW? === mmrazik is now known as mmrazik|lunch [10:36] seb128: accepted [10:36] Laney, thanks! [10:36] np, will respin later [10:36] seb128: is bug 1028363 OK? compizconfig-settings-manager and compizconfig-python are obvious, I just wanted to check on whether you're fine with dropping the binary package compiz-fusion-plugins-extra from compiz-plugins-extra [10:36] Launchpad bug 1028363 in compizconfig-settings-manager "Please remove old compiz sources from quantal archive" [Undecided,New] https://launchpad.net/bugs/1028363 [10:39] jdstrand: could you confirm bug 1033107? [10:39] Launchpad bug 1033107 in ubuntu "Please remove python-pyftpdlib from the blacklist and sync from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/1033107 [10:39] cjwatson, yes, they are all fine, we just support "compiz" in quantal, those 3 sources can be dropped [10:39] cjwatson, I commented on the bug saying so [10:39] thanks [10:40] Ah, yes, compiz-plugins-extra exists since natty [10:46] psivaa: hey, do you think you guys could put your nicks on the ReleaseTaskSignup page? I'm not yet familiar with your first names ;-) [10:46] * Laney will edit for the names of the RT [10:47] Laney, could i have the link for the page? [10:47] psivaa: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseTaskSignup [10:47] I'm trying to figure out who to ping when respinning :-) [10:48] Laney, sure ill add my nick [10:48] the others too if you know them [10:48] sorry for being clueless === chrisccoulson_ is now known as chrisccoulson [10:53] Laney, ok no worries, done for the 3 qa contacts [10:53] thank you [10:53] so FYI we're currently looking at some respins as listed on the pad http://pad.ubuntu.com/ubuntu-release [10:53] but the first cut images aren't all done yet, so will be kicked off in a few hours [10:56] Laney: so I'm still kind of coping with piles of post-holiday stuff; for today, maybe best if you lob things in my direction as needed? [10:56] cjwatson: sure, no probs, handling it for now [10:57] the kind gentle folk from across the Atlantic should be along soon too [10:57] mostly trying to clean up archive bugs [10:57] which seem to have got rather behind [10:58] Laney, not sure what people you are talking about but it's labor day in the U.S so those people will not be here today [10:58] ;-) [10:58] oh, really? [10:58] * Laney panics [10:58] yes... [10:58] not really :P [10:58] bit of an unfortunate timing, release people being at plumber on friday and U.S being off on monday [11:02] * cjwatson eyes bug 1011053 [11:02] Launchpad bug 1011053 in glew1.5 "Please remove libglew1.5-dev and libglewmx1.5-dev and the glew1.5 source from quantal" [Wishlist,Confirmed] https://launchpad.net/bugs/1011053 [11:04] I think the simplest fix for this is: remove libglew1.5-dev and libglewmx1.5-dev binaries, *then* rebuild all the reverse-deps (because libglew-dev Provides: libglew1.5-dev), then remove glew1.5 source [11:04] Anyone object to that? [11:07] poor celbalrai [11:07] There are no runtime deps on libglew1.5 [11:08] Sorry, libglew1.5-dev [11:08] Or libglewmx1.5-dev for that matter [11:11] There are three seeded packages involved that I can see: enblend, hugin, and hugin-tools (all Kubuntu daily-preinstalled) [11:18] cjwatson: well. libglew is at 1.8 now. And did a transition tracker and it shows 43 bad packages. [11:19] so my guess is, no rush?! [11:19] Yes [11:19] Well [11:19] I want to clear the archive bug queue [11:19] It's non-urgent +1 work I suppose but it does have to be unstuck at some point === mmrazik|lunch is now known as mmrazik [11:43] no bot for the queue this time? [11:43] it's down [11:45] Riddell: 11:06 xnox: needs stgraber to fix [11:46] perhaps we can run it on some shared machine [11:50] Laney: write a juju charm for it. :) [11:50] Say his name and he shall appear [11:51] Riddell: Is startactive for beta-1? [11:54] cjwatson: yep [11:54] OK, accepted [12:04] Daviey: can you write a juju charm to keep server team MIRs up to date? [12:05] cjwatson: Unlikely. [12:05] I guess that needs more resources than are readily available in the cloud [12:06] Yeah. It might be easier to write a charm to distill flippant people :) [12:07] touché [12:09] though seriously, having horizon uninstallable due to unfiled MIRs three days before beta seems kind of suboptimal [12:10] (well, uninstallable when using only main) [12:10] and something in that stack is trying to pull python-support back in [12:12] cjwatson: it doesn't require a MIR.. It requires work to remove the the C-M [12:12] OK ... is that work in progress? [12:13] cjwatson: we don't want to pull node into Main. It's only needed to compress some CSS.. which should be done at source package creation time IMO. [12:13] cjwatson: yeah, it is. [12:13] OK, good [12:14] cjwatson: well, two approaches are being investigated atm.. Compressing at source package creation time or making less,node/universe a suggests and doing a posh [ -f /usr/bin/node ] compress() at runtime. === henrix is now known as henrix_ === henrix_ is now known as henrix [12:28] Laney, just a smal Q :).. [12:29] Laney, I have just seen a few rebuilding but the pad does not say that in the history, will that be updated later? [12:30] psivaa: it's probably not realistic to rely on the pad having a full history, since it's pretty cumbersome to update [12:31] cjwatson, ahh ok, thanks [12:31] Personally I think adding that to the pad was a bad idea - if history's important, can't we track this some other way that would be more reliable? [12:31] I guess reasons are hard to capture automatically though [12:33] cjwatson, yea thats true, i was just wondering cuz i missed that there is a respin at the moment, but the iso tracker shows it though so that's fine by me [12:33] cjwatson: I agree that pad's suck for this. bzr would be far superior IMO, but at the very least wiki. [12:34] Well [12:34] What I'd actually like to do is complete and land my python rewrite of the cdimage tools, then write something on top which respins an image or set of images and reports the reason to some service [12:35] Any system where we have separate action and tracking-of-action is bound to fail [12:35] oooo, that sounds ideal. [12:55] Laney,QA: So, respin status - how would that be affected by accepting c2esp? [12:56] Will let us fix a problem showing up on http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html [12:56] (Which IMO should be clear before anything is even considered as a candidate, but what do I know ...) [12:56] Binaries from that source package are in nearly all non-core images, though [12:57] cjwatson: horizon isn't shipped.. so no a candidate blocker IMO. [12:57] Right, that's supported-misc-servers so we can get away with that, but it would still help clear noise if it were fixed [12:58] The problem with ignoring noise manually is that we can't just say "it's green, next check" [13:02] Laney or others: above ubiquity fixes the warning label in ubiquity / arm images [13:02] And if we accept that, we'll need to respin most of everything anyway, so I think we should take c2esp too [13:04] psivaa: ^- above ten lines or so, assuming you're current QA contact on duty [13:04] cjwatson, just reading it :) [13:05] I only see five test results posted so far, and those are on netboot [13:10] cjwatson, i do not have any objections in including that on a respin if thats the question is.. [13:11] It is, thanks [13:15] is there any chance we could get libreoffice considered if we respin? [13:15] * ogra_ thought that was already considered anyway [13:15] What's its build status? [13:15] the armel build is running dh_builddeb [13:15] which is the last build to complete [13:15] ogra_: it's not on the pad [13:16] oh, ok [13:16] its just because so many people cared on the weekend that got me this impression [13:16] If it can be copied to -release then sure [13:17] well, we really should get the new one, the current archive one spams dbus appmenu to no end and creates 100% cpu use while lo is running [13:17] psivaa: ^- any objections? don't know if much libreoffice testing has been done yet [13:17] it's spamming so much that unity,dbus keep using 100%cpu for a while after libreoffice is closed [13:17] i should test on arm them with the current one ... sounds liek a good CPU stresstest :) [13:17] *like [13:17] ogra_, ahah [13:17] seb128: ouch [13:18] cjwatson, yeah, they didn't the "update menu" plugged in at ff time and they though that having a "refresh every second" callback would be a good workaround [13:18] didn't have* [13:18] hmm, apart from the fact that we dont seem to ship it currently [13:18] on arm [13:19] thats a histroical change we should probably revert [13:19] why is it like that? [13:19] because we constantly had issues making the milestones due to slow builders [13:19] Laney, I guess it was not working on arm at some point... [13:20] hmm [13:20] or that ;-) [13:20] We've had to do that in the past as an emergency milestone band-aid, yeah [13:20] It's easy to forget to undo it after the milestone [13:20] it always worked (somehow) but it always got in the way during milestones [13:20] should we undo it now? [13:20] cjwatson, we do not do any manual release time libreoffice testing at the production level, so i would say that it does not affect ys [13:20] 8us [13:20] *us [13:20] still have a couple of publishers to wait at a minimum [13:20] * ogra_ greps for arm in the seeds ... [13:20] OK, so as long as it's installable basically [13:20] ... and finds gnucharmap :P [13:21] http://people.canonical.com/~ubuntu-archive/testing/quantal-proposed_probs.html has nothing relevant [13:21] oh, its [i386 amd64] ... not [!armhf] [13:21] so we dont ship it on ppc either [13:29] * ogra_ will revert that but keep that change for after beta so we can test first [13:56] yay, LO finished [13:57] Laney, \o/ [14:01] the -server versions are good I assume since they don't seem to be expected to be impacted by the things causing respins elsewhere? [14:01] right, the respins are all desktoppish so far [14:01] -server ships oem-config which comes from ubiquity [14:02] hmm [14:02] Though it won't actually be affected by the bug in question - it'd just be for the sake of version consistency [14:02] So I'll drop [6] from the pad there [14:05] Riddell: is kubuntu-active-meta for beta-1? [14:05] Looks likely, and you're respinning anyway I believe [14:07] Ah, there goes libcupsdriver1{,-dev} [14:07] So just evolution-exchange and horizon on quantal_probs now [14:11] cjwatson: yep [14:12] OK, accepted [14:17] hey, I'm updating mesa to a newer snapshot, but there are two issues: it requires a newer libdrm (2.4.39 vs. 2.4.38 quantal has), and libglu has been split off from it, requiring a new package [14:17] libglu is packaged, but would need to go through NEW [14:20] libdrm would just need an ack to upload, not much changed there [14:28] I'm removing the whole sync-helper / backport-helper / mass-sync edifice from ubuntu-archive-tools; we haven't had any bugs that required their use for at least a month or two now, and with that flow it's perfectly feasible to just use syncpackage / backportpackage for the odd exceptional case [14:34] Docs updated accordingly [14:34] which reminds me. ScottK: now that we have ubuntu-archive-tools' queue, do you still need dgetlp? [14:39] goodmorning cjwatson, am about to start reading the logs, but anything on the urgent list from QA for today's images? [14:40] not AFAICS but I have mostly been clearing the archive bug queue [14:40] there's a pending respin of $most [14:41] (due mainly to a fairly important ubiquity bug) [14:41] [6] on the pad [14:41] * skaet seeing... [14:42] And I think there was consensus to copy over the new libreoffice [14:42] can I upload the new libdrm? only seven upstream commits on top of the current one http://paste.ubuntu.com/1183673/ [14:42] Laney: ^- did that happen? [14:42] still publishing armel afaics [14:42] tjaalton: You can upload in any event and it'll land in the queue [14:42] armel has no images [14:42] cjwatson: ok [14:42] it still needs to happen for the copy [14:42] tjaalton: We prefer to review things from the queue where possible - better tools for the job [14:42] cjwatson: understood [14:42] ah, k [14:43] Laney: It's publishing at the moment - took it ~20 minutes to think about the attached translation tarball [14:43] Must fix that, that really doesn't have to be done on pepo [14:43] such joy [14:44]