[01:20] slangasek: Around? [01:21] infinity: hi [01:21] slangasek: Care to lend an eye to http://paste.ubuntu.com/697609/ for sense-making? [01:21] slangasek: Turns out that we went around and around in circles because someone had me convinced we actually used the debconf frontend. Which we really don't. :P [01:22] (except for server) [01:23] ah :) [01:25] infinity: looks good to me [01:25] You counted case/;; agreement, didn't you? I can only assume that was the delay. [01:25] My eyes crossed when I did it. ;) [01:29] yes, I did :) [01:30] Should hit the queue in 2 seconds. [01:30] If you'd like to accept for me. [01:31] * infinity considers exporting VISUAL=vim in cdimage@antimony's bashrc... This nano business offends me. [01:33] 'cepted [01:33] Danke. [01:34] And now I delay the preinstalled dailies, so we actually get something fixed in before another 25 hours passes. [01:46] Are LP automagic bug closures broken, or am I just being impatient? [01:46] (Should happen on ACCEPT, surely?) [03:56] cjwatson: would be nice, yes; usually we have the 7 day maturing period for regressions, but as this doesn't "naturally" get tested by people using -proposed, it would be good to know that regular installs still work [06:24] infinity: still awake? [07:37] I'm reviewing other people's gnome updates, but it would be nice if someone could review my uploads (glib2.0, nautilus (trivial), gnome-online-accounts, eog, gedit-plugins [07:57] pitti: I see two breaks: added for the gdbus ABI change. Is it certain that this is all that's affected, has anyone searched the revdeps for symbol references? And how recently was the API introduced - could conflicting with old versions of nautilus cause more harm than good for upgrades? [07:57] slangasek, I can reply for that [07:57] seb128: heya [07:57] slangasek, the api was added mid-oneiric, I've grepped through main on a dc machine [07:57] upstream grepped through the GNOME git as well [07:58] only nautilus and gnome-online-account showed up [07:58] ok [07:58] I checked with dx as well to make sure they don't use the gfbus generator, they don't yet [07:58] it will only break the current oneiric version of nautilus [07:58] gnome-online-account is a new source in oneiric [07:58] so the breaks are useful for oneiric upgraders during a day or so [07:59] we don't need it for natty->oneiric [08:00] I would go further and say it's important to remove the breaks for natty->oneiric, so we don't make upgrade calculations more difficult than they need to be [08:00] maybe I'm being paranoid, but we've recently seen breaks negatively impacting upgrades, so... [08:00] (gcj-4.4) [08:00] right, i also grepped unity [08:01] slangasek: ok, I'm fine removing them [08:01] I've checked with ted, they didn't have time to use the gdbus generator yet [08:01] slangasek, seb128: I tested nautilus with the new glib, and didn't find any breakage [08:01] g-o-a didn't work, but that could just as well have been the old version [08:01] it's not really a feature change [08:01] just a namespace tweak [08:01] pitti, seb128: well, accepted this version - a further upload later in the week to drop the breaks may be the right thing to do [08:01] I just tested the new g-o-a and new glib, and that works fine [08:01] slangasek, thanks, agreed [08:01] slangasek: I can remove it right now [08:02] slangasek: well, let's say, I'll upload it once that version built, just in case there's some armel trouble again, etc. [08:02] pitti, well, maybe save a glib update for tomorrow in case any post . patch land in git? [08:02] seb128: sounds good [08:02] post 3.2 [08:02] who broke my keypad? ;-) [08:06] slangasek: bah, I suck -- turns out that I forgot a comma, which effectively dropped the two new breaks: :/ [08:07] slangasek: funny retroactive "do what you mean" [08:07] pitti: ah shoot - does that give a build failure due to broken syntax, then/ [08:07] ? [08:07] no, it built fine here [08:08] I actually had expected it to fail on "cannot parse dependency" or so [08:08] yeah [08:08] hm, I built it about three times, but not sure whether i rebuilt the whole package after adding the breaks [08:08] I guess it'll fail then; fixed in bzr, I'll upload again once it does [08:08] sorry about the mess [08:51] slangasek: so, of course it failed to build, sorry; ^ fix [08:51] I mean, I just uploaded the fix [09:03] * pitti accepts glib2.0, we discussed it above, and the diff is quite trivial [09:05] pitti: would you mind acking my debian-installer/natty-proposed upload? [09:05] cjwatson: good morning; sure [09:06] looks fine, accepted === doko_ is now known as doko [11:06] cjwatson: ^ would you mind reviewing ubuntu-defaults-zh-cn? [11:07] I also uploaded gnome-online-accounts (part of gnome 3.2 finals), would be nice if you could ack this as well [11:08] hello [11:09] please could a member of the release team review FFE bug 851659 [11:09] Launchpad bug 851659 in jenkins (Ubuntu) (and 4 other projects) "[FFE] Sync asm3 3.3.2-1 (universe) from Debian unstable (main) (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/851659 [11:09] required to support eclipse 3.7 [11:29] jamespage, commented [11:31] thanks doko; still needs a release team ack if anyone is around [11:35] jamespage: done [11:35] jamespage: want to sync yourself, or need a sponsor? [11:36] pitti, need a sponsor for that one please [11:38] jamespage: asm3 synced [11:38] pitti: thankyou [12:00] pitti, please accept java-common, fixing broken /usr/lib/jvm/default-java symlink [12:05] pitti: done [12:16] cjwatson, pitti: please accept java-common and openjdk-6. java-common isn't really necessary, but will unbreak the dangling symlink faster on all archs [12:24] doko: accepted j-common; still waiting for the diff to appear for openjdk [13:05] uploaded debian-gis and osm2pgsql to fix NBS === shadeslayer is now known as shocklateboy42 === shocklateboy42 is now known as shadeslayer [17:00] bdrung: we were expecting an eclipse FFe for the last month. glad to finally see it. I have no previous experience with the package, and it is rather close to final freeze. Are we pretty confident about wanting this? [17:01] tumbleweed: we had to get some deps updated before we can get eclipse in (that delayed it). [17:02] tumbleweed: 3.5 is very old and it used xulrunner (see the workaround to get rid of xulrunner). eclipse 3.7 uses webkit by default [17:02] bdrung: right. And you are ready to deal with any last-minute issues from it? [17:03] err yeah, I can see why we'd want it with webkit [17:03] bdrung: I highly approve of the xulrunner->webkit thing, but yeah, this is pretty last-minute. Are these packages actually testing? [17:03] tested* [17:03] tumbleweed: eclipse 3.7 lived in experimental for a long time (will be uploaded to unstable soon). [17:04] right, that helps [17:04] infinity: it lives in the ppa. i did some small testing and one user is using the ppa version (and it works for him) [17:04] * bdrung will be afk for two hours. [17:08] * tumbleweed grants the FFe [17:11] * micahg hugs tumbleweed and bdrung [17:12] https://launchpadlibrarian.net/81207327/buildlog_ubuntu-oneiric-armel.xzgv_0.9%2Bsvn40-1ubuntu1_FAILEDTOBUILD.txt.gz [17:12] seb128, pitti: which gtk/gnome libary causes these build failures? [17:12] it's not the only one, and I think it's too late for such changes. please could you consider reverting this? [17:13] skaet, ^^^ repeating here, you're not on #ubuntu-devel [17:13] * skaet goes to edit her auto logins for Freenode, silly reboot. [17:14] did see similiar build failures on some theme packages [17:15] thanks for repeating it here doko. [17:15] doko, no idea [17:16] reverting> no [17:16] we just updated from a .90 in unstable series to stable [17:16] those updates have only a few selected import bug fixes, it doesn't make sense to "revert" [17:16] if there is a bug we should find and fix it [17:18] seb128: I think that's this: http://mail.gnome.org/archives/desktop-devel-list/2011-August/msg00236.html [17:19] that one is not recent though [17:19] it's like a month old [17:21] that build failure is almost 2 weeks old also [17:21] oh, no it isn't... [17:22] seb128: right, but I think it happened after the amd64/i386 rebuild [17:23] and started to manifest in the armel rebuild [17:24] it doesn't really make sense to add bugs back though [17:24] if as-needed is breaking things maybe turn that off for the end of the cycle and back next cycle? [17:25] we did that last time :) [17:25] no. we did fix all known issues [17:25] well apparently not, you just pointed one [17:25] ;-) [17:25] these were introduced between the x86 rebuild and the arm rebuild [17:26] seb128, a FFe for gtk/gnome packages doesn't mean that you don't have to fix regressions [17:26] doko, that's not a regression [17:26] it just expose application which rely on something else to call -lm for them when they use it [17:27] "sources" rather than "application" [17:27] i.e those softwares are buggy, it just happened that the bug was not showing because something else was bringing in an implicit way what they need [17:29] the corresponding commit is http://git.gnome.org/browse/gdk-pixbuf/commit/?id=d430bc4df3314a88cd538474d26ff7764d1f408c [17:29] we could revert it for oneiric as a workaround I guess but still that's not a bug [17:29] those source will need fixing next cycle [17:30] seb128, skaet: it is a regression. the x86 builds did succeed: https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+sourcepub/1865274/+listing-archive-extra [17:30] doko, define regression [17:30] seb128, doesn't build, when it did build before. that's what counts for buildability [17:30] those sources are buggy and instead of declaring the depends they need they happened to work because others were pulling requirement for them [17:31] it's technical neither a bug nor a regression on the gdk side [17:31] then don't change the requirements after feature freeze [17:31] seb128: If they were depending on stuff they only indirectly depended on, that's a bug, IMO. [17:31] that's barely a feature, it's a fix, it was leading softwares to link to libraries they don't need [17:32] ScottK, it's a bug from their source, they use lm and need -lm which gdk happened to bring for them but they can't rely on that [17:32] if they use lm they need to have -lm in their flags [17:32] Sounds right to me. [17:33] I'm fine putting the extra flags in gdk as a workaround for those buggy source [17:33] but I disagree that's a feature freeze break or a regression [17:35] seb128, noted. Thanks. [17:35] doko: there are only ~75 failures in the armel rebuild that aren't depwait and most aren't in a packageset, maybe just put out a call for help fixing them (if it's this issue, it should be easy for almost Ubuntu dev) [17:36] how many of those -lm bugs do we have? just curious [17:36] seb128, the bad thing is that we don't know it [17:36] so let's revert the commit as a workaround, I will do that [17:36] still I will drop it early next cycle ;-) [17:36] three did fail in gtk-engines-*, this is the fourth one [17:37] seb128, right, sounds fine at this stage [17:46] micahg, I think some of these need some planning, like all the OpenGL/Gles issues [17:46] doko: yeah, wasn't sure how many were -lm vs OpenGL/Gles [17:49] micahg, the issue is that somebody has to look at these, maybe better file bug reports. waitung now for weeks on this ... [17:50] doko: if you can file the reports you might get some people's attention [17:50] ARM/Linaro did commit to do that [17:51] There's nothing we can do about GL/GLes in some cases. [17:51] Not without a lot of porting effort, that is. These aren't always "quick FTBFS fixes". [17:53] infinity, micahg these are seen very often: https://launchpadlibrarian.net/81210497/buildlog_ubuntu-oneiric-armel.ratbox-services_1.2.4-1_FAILEDTOBUILD.txt.gz [17:55] doko: That hardly looks arm-specific. [17:55] looks like a toolchain on arm bug ;) [17:56] doko: That header defines the user struct on amd64 too. [17:56] infinity, didn't ftbfs [17:57] doko: That's nice. Maybe the header changed? :P [17:58] Or, maybe something started including it that shouldn't have... [17:58] /* The whole purpose of this file is for GDB and GDB only. Don't read too much into it. Don't use it for anything other than GDB unless you know what you are doing. */ [17:58] ^-- A bit of a scary warning. :P [18:01] doko: If you're seeing that class of failure "often", then user.h is almost certainly being included by some more common/standard header. If so, we should find this and make it stop. :P [18:01] * infinity will have a quick hunt after a smoke and root beer run. [18:11] can an AA nack keystone please. [18:13] Daviey: It's broken? [18:14] Well, it's also a huge diff... [18:16] infinity: being superseeded [18:27] I'm putting the buildds on manual for a bootstrap briefly [18:37] Done, back to auto [18:43] * Daviey reviews ^^ [18:45] slangasek: Do you have thoughts on openssl in queue, related to another c_rehash issue? [18:50] RE: dovecot, have a few questions to ask the sponsor - will follow that up tomorrow, in his TZ. [18:51] Daviey: You might want to reject it if you have concerns to discuss, or someone else might decide to accept when you're not looking. :/ [18:51] (This has happened to me a few too many times) [18:51] We really need a "being looked at, don't touch" queue. [18:51] infinity: Annoyingly, i don't have foo to do that. [18:52] or at least a comment field. [18:52] Daviey: cjwatson briefed me on it earlier, I'll have a look at it [18:53] I'm sure dgetting from the queue used to work.. :/ [18:54] cool [19:01] doko: So, that class of failures is due to sys/ucontext.h on ARM including sys/procfs.h ... [19:09] Can orchestra be accepted please. [19:13] jdstrand: Are you confident your patch for libvirt will be accepted upstream? [19:14] (Silly question, because we need it anyway) [19:14] Daviey: well, I am the upstream author of the security driver. I noticed that someone sent a patch for something else with unidirectional pipes like 5 minutes after I did (not for the apparmor driver) [19:15] Daviey: it's conceivable that they will have me iterate on it-- but the patch is solid as is and acceptable for ubuntu. I can reupload or refactor for 'p' [19:15] if required [19:15] nah, i just wondered really. [19:16] they've accepted everything from me. on occasion they have had me redo something based on some other stuff they were working on [19:16] jdstrand: It was lots more work than i expected it to be.. make sure you collect beer tokens from ubuntu-server at UDS. [19:17] heh [19:17] can libvirt be accepted please. [19:17] depending on what happens with the latest pipe code, I might have to iterate, but that is all 0.9.7 stuff anyway [19:17] reject dovecot for now please [19:18] Happy times. [19:19] Are any AA's around? [19:20] * Daviey launches a big *sigh* [19:21] Daviey: I might be. [19:22] Daviey: libvirt+ dovecot- [19:22] \o/ [19:22] orchestra+ [19:23] reviewing glance [19:23] zul: Does glance need to wait for pending nova upload? [19:23] no it shouldnt [19:29] infinity: thanks [19:29] don't go anywhere! [19:31] nova should be there now [19:34] Can any spare AA accept glance please, looks good. [19:34] * Daviey now looks at nova. [19:52] * Daviey wonders if there is any point in him reviewing stuff. [19:53] Daviey: Just ping me with a list of things that have your +1/-1, I'll get to it when I take breaks from my own work. [19:54] infinity: thanks [19:54] infinity: nova+1 [19:54] infinity: glance+1 [20:02] hey release guys; could someone approve these please? :) https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1&queue_text=ubuntuone [20:07] just pushed a new edubuntu-artwork hiding two entries that we don't want in our menus (nepomuk). I just realized this may have needed a UIFe from edubuntu-docs. As a member of edubuntu-doc and the guy who's going to do the screenshots, I don't have a problem with that change and I know these two entries don't appear in any of our documentation. [20:09] dobey: I'm really not confident in reviewing a new upstream version of ubuntuone*, especially without a changelog of what it does. [20:10] Not to mention it's flippin' huge, looks like artwork changes and strings. [20:10] Does it have an FFe already? [20:12] Daviey: could it be bug 849494 I seem to remember seing this one in my mails recently [20:12] Launchpad bug 849494 in ubuntuone-control-panel (Ubuntu) (and 1 other project) "String freeze exception: still offers Evolution plug-in for contact sync in Oneiric (affects: 3) (dups: 1) (heat: 22)" [Medium,Triaged] https://launchpad.net/bugs/849494 [20:13] Daviey: artwork changes and strings? [20:14] Is there a permanent FFe for ubuntuone, like we have for GOME? [20:14] no [20:14] infinity: no. [20:14] If not, while I'm inclined to review this anyway because it fixes some important bugs, huge diffs like this at this point in the release are pretty unacceptable. :/ [20:15] infinity, well, even with a ffe that's not really a good sign [20:15] At least, for packages that are installed on nearly every ubuntu desktop in the world. [20:15] which huge diff? [20:15] GNOME has a ffe because they don't do such diffs that late ;-) [20:15] seb128: Some of GNOME's late changes can get this large. [20:15] ubuntuone-control-panel? [20:15] dobey: I'm seeing pot translation changes in ubuntuone-control-panel? [20:16] GNOME also doesn't have a bunch of extra code inside the same source tree, to support another platform, independent of linux [20:17] Irrelevant. [20:17] dobey: I wrongly assumed the binary blob in ubuntuone-control-panel-2.0.0/ubuntuone/controlpanel/gui/qt/ui/images_rc.py was an image, what is it? [20:17] Like I said, I'm inclined to spend some time reviewing it anyway, but at this point in a release cycle, we want specific bugfixes (even if that means backporting patches), not large new versions. [20:18] Daviey: compiled qt UI code for the windows port [20:18] Daviey: though not sure why that would be in the diff [20:19] dobey: Ah, ok - i assumed it as a diff representaton of an image. [20:19] Daviey: anything with 'qt' in the filename path can be ignored, because we don't install that on ubuntu; that's the windows stuff [20:19] dobey: http://launchpadlibrarian.net/81223413/ubuntuone-control-panel_1.1.3-0ubuntu1_2.0.0-0ubuntu1.diff.gz in case you're wondering what's in the diff [20:20] dobey: Off Topic, being upstream - does it make sense to ship that in the same orig tarball? [20:21] infinity, https://launchpadlibrarian.net/81225550/buildlog_ubuntu-oneiric-armel.easymp3gain_0.5.0-6_FAILEDTOBUILD.txt.gz looks like an incomplete fpc transition, there are more ... [20:22] Daviey: it doesn't make any sense not to. as an upstream i don't want to maintain a different release for every different platform. ideally there would only be one UI and one set of code, but we are in an odd place with that at the moment, though will improve over the next 6+ months [20:23] Daviey: i really have no idea why exactly the pot file is just a big block of ----- in that diff :-/ [20:23] :( [20:23] doko: The user.h thing is a bug in ARM's ucontext.h, BTW. It's the only arch that includes (and always had included) procfs.h instead of carrying local typedefs like the others. I guess something recently started including ucontext that didn't before, thus the chain reaction explosion. [20:23] Daviey: it gets generated at build time anyway [20:24] doko: I imagine we should rewrite ucontext.h and push it upstream, but I don't see that happening in the next 2 days. [20:24] Daviey: so the pot file itself being there really doesn't make any difference afaik [20:24] dobey: Hmm, doesn't LP pull in the translations from source packages, rather than binary? [20:25] s/translations/template/ [20:25] Daviey: i don't know about launchpad, but the u1 strings get pulled out by the langpacks magic at build-time [20:25] as i understand it [20:25] LP translations are from the build-time tarballs, yes. [20:25] If by "LP", you mean Rosetta. [20:26] (Okay, so it hasn't been called that in 5 years, but "launchpad translations" felt ambiguous) [20:26] langpacks? :) [20:26] the strings for things in the default seed are pulled out by langpacks after the "build" portion of the package building afaik [20:26] Daviey: Pulling translations from source packages would be nearly impossible. [20:27] Daviey: We do it post-binary-build, when the files actually have sane names and locations and such. [20:27] infinity, if you don't know what, then call it multiarch [20:28] doko: I really doubt it... [20:28] infinity: ah, ok - thanks [20:28] something did change in the order of inclusions. at least on i386 where the x86_64 headers are used. not sure on arm [20:28] doko: I can keep tracing it back, but I'm not sure I see the point. There's no harm in including sys/ucontext.h, except on ARM, so it's more likely an ARM bug that's been sleeping for 7 years than something we can blame on others. [20:29] anyway, some more packages fixed in the next cycle [20:32] dovevot [20:32] dovecot [20:32] Yeah. I think I'll put a pin in this *glibc bug, but I should rewrite that header. [20:33] I just love that it's been like this ever since the port started in glibc CVS and, apparently, no one's included it until now. [20:34] Actually, that in itself might be a sign that maybe the bug is that it shouldn't be included at all. Maybe I'll trace back further. The part where it works on other arches may just be a happy accident. [20:34] jamespage: hey [20:34] I should learn to type ctrl-f first [20:34] hmm [20:35] Daviey: you had questions? [20:35] jamespage: Can you expand on reasoning for: [20:35] + - debian/mail-stack-delivery.postinst: drop -n flag from dovecot deliver [20:35] + command in postfix configuration. [20:36] Daviey: -n is not longer a valid flag as far as I can see [20:36] ah, ok [20:36] and: [20:36] - imap_client_workarounds = outlook-idle delay-newmail [20:36] + imap_client_workarounds = delay-newmail [20:36] correct, right? [20:37] OK; so dovecot is actually quite helpful [20:37] I reviewed all of the warnings that where generated by the current configuration [20:37] And it wanred that outlook-idle was deprecated? [20:38] this option is no longer required by which I assume its implicit rather than explicit [20:38] jamespage: The one which concerned me really was, http://pb.daviey.com/gqzT/ [20:38] It looked like a potential typo, wanted to make sure. [20:38] both of the _file options are deprecated [20:39] jamespage: but re-added with "<" there? [20:39] I tested this on a local install to ensure that imaps was working OK with that configuration [20:39] picks up the new config fine [20:40] infinity, the fpc issues track down to the lazarus ftbfs [20:40] jamespage: did the warnings suggest you add a '<'? [20:40] yep - and that is as documented in examples provided in package as well [20:40] jamespage: ah, ok - super! [20:41] jamespage: sorry for doubting you. :) [20:42] Daviey: np - I was quite surprised - I was actually just testing utlemming proposed change to the upstart config and discovered it was all borked [20:42] jamespage: well if you will test stuff, you are more likely to find issues.. best not to test :) [20:43] i wish i could make the diff only show changes relevant to ubuntu, but alas [20:44] Daviey: we should probably have a test for mail-stack-delivery - thats the second time I've discovered it non-functional a few weeks before release... [20:45] :/ [20:45] good thinking. [20:46] infinity: can you un-reject dovecot please, and accept? ;) [20:47] Done. [20:48] dobey: you can provide a filtered diff on a bug or whatever [20:48] filterdiff is your friend [20:48] hmm [20:53] doko: Indeed. Retrying lazarus on armel and powerpc, but I assume they'd fail again. Any idea what's gone wrong there? [20:53] infinity, tell me how to turn on verbose build logs ... [20:55] re the ensemble rename to juju .. which I'm almost done testing.. [20:55] doko: Happy to do a local build, if you have an idea of what to look for. [20:55] Would it be better to keep the source package name ensemble and just introduce juju as a new bin package, or let it come in as a NEW source package? [20:56] SpamapS: NEW source is fine, we'll just have to manually diff it. Not the end of the world. [20:56] SpamapS: I assume the new source still builds ensemble-ish binary packages for transition purposes, though? [20:56] Just thinking about bug tracking, people will likely want to report bugs in juju, not ensemble [20:57] Since it's a new package this cycle, I'd rename the source [20:57] infinity: it builds a transitional package so people with ensemble installed will get juju, and a /usr/bin/ensemble which displays a disclaimer. [20:57] SpamapS: Kay, good enough for me. Yeah, new source makes more sense. [20:57] ack, thx [21:07] filterdiff is not my friend :( [21:07] infinity, got it, multiarch ... [21:09] doko: Is that the answer for everything now? :) [21:09] infinity: not for everything, just the bugs [21:09] infinity, yes I fixed all ld --as-needed issues ;) [21:09] hey, multiarch broke NM, so it can break anything :) [21:10] :P [21:11] Laney: filterdiff -x qt changes.diff seems to not do what --help says it should do :( [21:11] anyway, i need to go now [21:11] add some *s [21:15] Laney: ah, none of the other actual regex stuff i was doing worked either but "*qt*" seems to have done it :P [21:16] :-) [21:18] http://people.freedesktop.org/~dobey/ucp-ubuntu-2.0.0.diff [21:19] much shorter without all the windows code in the way [21:19] anyway, i do have to go :) [21:24] slangasek: You want to review that ca-cert upload from lool, since it seems to be more fallout from your headache? :) [21:24] maaaan [21:25] looking [21:28] powerpc looks messy after the last gnome orgy [21:31] infinity, fpc waiting ... [21:31] doko: When the queueu munger gives me a diff. [21:39] lool: why does ca-certificates add a conflicts: on the old openssl instead of a Depends: on the new one? [21:39] lool: (fwiw I'm inclined to reject this upload for that) [21:47] doko: Is the upstream for foo-plugins @gentoo? :P [21:47] doko: That entire CFLAGS line is pretty suspect, not just the sse. [22:11] keystone looks good, can it be accepted please? [22:39] Daviey: done [22:48] ^^ bugfix-only flashplugin upload, touches up a few spots I missed with the previous one [22:56] * infinity grumbles about file renames making the package one enormous diff. [23:00] slangasek: thanks [23:04] infinity: what package was that? [23:04] slangasek: fp-nonfree [23:05] infinity: there shouldn't have been file renames in the latest - only a directory rename (due to the native package) [23:05] slangasek: Yeah, but the autogenerated diff was against the one in the archive, not the one in the queue. [23:05] Anyhow, reviewed and accepted. [23:08] infinity: oh; I thought 10ubuntu4 was already accepted long enough ago that LP would've gone against that [23:08] but it seems not... something wrong with the publisher? [23:08] slangasek: ubuntu4 was still in unapproved. [23:08] slangasek: I just rejected it. [23:08] oh [23:08] odd, I was sure I saw an accept earlier [23:09] Odd indeed. [23:09] maybe I just imagined it because mdeslaur started talking to me about it :) [23:09] slangasek: I wasn't accepted yet when I looked at it [23:09] s/I/It/ [23:09] yeah :) [23:09] infinity: anyway, by the time I was done gutting the maintainer scripts, might've been shorter to review the whole package than the diff ;) [23:10] slangasek: Which is what I ended up doing. :) [23:10] :D [23:14] * Daviey would accept orc (1:0.4.14-1ubuntu1), if he could. [23:15] Is that a hint? [23:15] builds, and sensible upstream cherrypick, fixes a bug. [23:15] slangasek, infinity: please give back the powerpc builds once gtk-3.0 is in the archive [23:15] * micahg confronts orc with a 12 damage dragon... [23:16] afk now [23:16] * infinity is trying to decide how to feel about that libav upload. [23:17] did siretart upload the 63 patch change? [23:17] Yup. [23:17] And actually, the 63 upstream cherrypicks worry me less than multiarching 2 days before final freeze. [23:18] Unless those m-a changes are well-testing in Debian already? [23:18] yeah... [23:18] tested* [23:18] I think multiarch was only uploaded last week to debian for libav [23:18] reject it. we don't have a chance to test this [23:18] That's my feeling too. Someone needs to re-upload with the CVE fix, though. [23:19] infinity: worse, uploaded Friday :D [23:19] micahg: If it's Friday where you are, I want to be in your timezone. [23:19] infinity: no, libav w/multiarch was uploaded to Debian last Friday [23:19] Ahh. [23:19] debian-gis, uploaded by pitti - postgresql-8.4-postgis -> postgresql-9.1-postgis, change.. Would be good to know if it should be "postgresql-9.1-postgis | postgresql-8.4-postgis", rather than a straight change.. as postgresql-8.4-postgis is still in Oneiric (should it be?). [23:20] infinity: tomorrow is my Friday this week though :D [23:20] infinity: I actually have a multiarching coming yet, but I'm going to rebuild-test the lot of revdeps [23:20] (libjack... the *right* libjack, instead of the wrong one I already converted this cycle but isn't installed by default, feh) [23:21] slangasek: Feel free to unreject libav if you think it's even remotely testable for sanity, but it just seems risky to me. [23:21] nope [23:21] doko is right, multiarching libs needs to come with pre-upload regression testing [23:21] Or with the flood of opening a new release and some random prayer? :P [23:22] with libav that's almost impossible at this point [23:22] Cause you know we'll see this same upload again in 2.5 weeks. ;) [23:23] infinity: anyone running pre-alpha1 shouldn't mind the breakage [23:23] slangasek: So, what you're saying is that when you regression-tested the (wrong) libjack, everything worked smashingly because nothing was linked to it? ;) [23:23] yep! [23:23]