[00:24] <cjwatson> Daviey: accepted mythexport.  you may have to close a bunch of bugs manually as I just noticed John used the wrong format in the changelog.  I don't want to make him go around again just for that.
[00:26] <nhandler> Didn't someone make a script that lets you pass it a list of bug numbers and it takes care of closing them?
[00:26] <Daviey> cjwatson: Doh.. not having a good day here.  Thanks for that.
[00:27] <cjwatson> nhandler: I did a one-off when the auto-closing system was broken
[00:28] <cjwatson> http://paste.ubuntu.com/506066/ - but NOT SUITABLE for running as-is, it doesn't take bug numbers on the command line but fishes them out of the publication records
[00:28] <cjwatson> it's probably not worth it for a handful of bugs
[00:37] <Daviey> done
[00:38]  * Daviey lets John know
[02:04] <ScottK> ^^^ appears to be the one that robbiew already said no to in an FFe.
[02:05] <ScottK> I don't see any new bugs, or approvals, so rejecting.
[02:42] <jdstrand> cjwatson: oh, I forgot to mention the tasks. I installed all tasks. it's a server install, not a UEC install, with all tasks selected
[02:43] <jdstrand> cjwatson: I'm going to try it now
[02:52] <ScottK> Arrrgh!!!
[02:52] <ScottK> I swear I clicked reject, but it's in.  https://launchpad.net/ubuntu/+source/ubuntu-font-family-sources/0.69+ufl-0ubuntu1
[02:53] <ScottK> Unless someone else accepted it ....
[02:53] <ScottK> Urgh.
[02:53]  * ScottK goes to bed.
[03:06] <jdstrand> cjwatson: well, it worked this time. I'll try a few more times in the morning. I think for now forget about it unless I can reproduce
[10:17] <cjwatson> casper> commented on bug
[10:18] <dpm> hi everyone, I realise it's getting late, but I prefer asking in any case:
[10:18] <dpm> While testing the final maverick language packs, I've noticed that the gnome-language-selector translations are missing (bug 654548). Would it be possible to do a new upload of language-selector including an export of LP translations and bypassing pkgbinarymangler's translation-stripping part? It would be a workaround, but this way we'd have a translated language-selector without the need of new language packs.
[10:18] <ubot4> Launchpad bug 654548 in ubuntu-translations "Language selector translation is missing from the final Maverick language packs (affects: 2) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/654548
[10:19] <doko> cjwatson: re-uploaded ffmpeg yesterday. did see that packages like libmesh do fail to build with the current ffmpeg version in maverick. so there is a chance that the packages which we did remove may come back in time for maverick
[10:20] <doko> about opensync: there are already a few plugins built with the new opensync version, so not sure about the best way ...
[10:20] <doko> for audacious, I'd like to remove the plugins which fail to build unless I hear back from bdrung
[10:32] <cjwatson> doko: I was hoping to get a straight answer from siretart on whether it was OK, but he seems to still be labouring under the misapprehension that we're actually using powerpc
[10:32] <cjwatson> so I've just accepted it
[10:32] <doko> ok, thanks
[10:33] <cjwatson> dpm: language-selector is already blacklisted in pkgbinarymangler, so it ought to include its own translations and this is not a workaround
[10:33] <cjwatson> dpm: since language-selector is part of the toolchain that installs language packs ...
[10:33] <cjwatson> it already seems to include quite a few translations
[10:34] <mgunes> cjwatson: is the premature downloading of pre-published images before release a problem in the final release process the same way it is in milestones? If so, I'm inclined to post a notice on the forums until release telling people to check the release blog and/or ubuntu-announce for definitive news, since it seems to be a growing problem recently.
[10:34] <dpm> cjwatson, ah, weird, I don't have any translations in /usr/share/locale for language-selector, either, but let me re-check...
[10:34] <cjwatson> mgunes: yes
[10:34] <cjwatson> mgunes: it inhibits our ability to get things out to mirrors
[10:35] <Laney> can someone make sure the removals ~ubuntu-archive are subscribed to are done before the really final freeze?
[10:36] <mgunes> cjwatson: thanks, will proceed
[10:36] <dpm> cjwatson, it seems that the latest version of language-selector has translations in the source code, but it does not install them
[10:36] <seb128> it does, I just did a local build
[10:37] <dpm> seb128, so do you think the blacklisting perhaps is not working and they got stripped?
[10:37] <seb128> $ dpkg -c language-selector-common_0.6.5_all.deb  | grep language-selector.mo  | wc -l
[10:37] <seb128> 92
[10:37] <seb128> on a local build
[10:37] <seb128> let me check launchpad build logs
[10:39] <dpm> thanks
[10:39] <seb128> skaet, hey
[10:39] <seb128> in London?
[10:39] <skaet> hey seb,
[10:39] <skaet> yup,  just arrived in the office.  :)
[10:40] <seb128> is it your first time in the office?
[10:40] <seb128> dpm, cjwatson: http://launchpadlibrarian.net/56391059/buildlog_ubuntu-maverick-i386.language-selector_0.6.5_FULLYBUILT.txt.gz
[10:40] <skaet> seb128, yup, first time.
[10:41] <seb128> "pkgstriptranslations: language-selector-common does not contain translations, skipping
[10:41] <seb128> pkgstriptranslations: tarball already exists
[10:41] <seb128> "
[10:41] <cjwatson> looks suspiciously like it's stripping translations doesn't it
[10:42] <cjwatson> wait, language-selector was unblacklisted?
[10:42] <cjwatson> bug 570240
[10:42] <ubot4> Launchpad bug 570240 in pkgbinarymangler (Ubuntu) "Wrong language-selector package blacklisted (affects: 1) (heat: 23)" [Low,Fix released] https://launchpad.net/bugs/570240
[10:42] <cjwatson> I'm not sure I follow the reasoning for dropping it from the blacklist, TBH
[10:43] <pitti> hello
[10:43] <cjwatson> but, dpm, you were involved in that bug ...
[10:43] <seb128> pitti, hey
[10:43] <seb128> we are discussing language-selector
[10:43] <seb128> should translations be stripped or not?
[10:43] <seb128> right now they are stripped but not in langpacks
[10:43] <cjwatson> original question:
[10:43] <cjwatson> 10:18 <dpm> While testing the final maverick language packs, I've noticed that the gnome-language-selector translations are missing (bug 654548). Would it be possible to do a new upload of language-selector
[10:43] <ubot4> Launchpad bug 654548 in ubuntu-translations "Language selector translation is missing from the final Maverick language packs (affects: 2) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/654548
[10:43] <cjwatson>             including an export of LP translations and bypassing pkgbinarymangler's translation-stripping part? It would be a workaround, but this way we'd have a translated language-selector without the need
[10:43] <cjwatson>             of new language packs.
[10:44] <cjwatson> I was surprised by language-selector having been dropped from the blacklist; I confess that bug 570240 doesn't make huge amounts of sense to me but maybe I need more coffee
[10:44] <ubot4> Launchpad bug 570240 in pkgbinarymangler (Ubuntu) "Wrong language-selector package blacklisted (affects: 1) (heat: 23)" [Low,Fix released] https://launchpad.net/bugs/570240
[10:44] <pitti> hm, why are they missing in the first place..
[10:44] <seb128> that would be one of the questions for you
[10:44] <seb128> I'm not sure how langpacks are built or where to check for logs
[10:44] <pitti> but yes, I wouldn't mind a reupload of language-selector with translations included
[10:44] <dpm> cjwatson, good catch, I didn't even remember that bug.
[10:44] <pitti> seb128: I can do that
[10:45] <seb128> pitti, thanks
[10:45] <pitti> I need about 15 more minutes to finish my current g-s-d patch, then I can have a look at this
[10:45] <cjwatson> changing language on the live CD I agree is a dodgy unlikely-to-work edge case; but including translations in l-s applies also to the installed system
[10:45] <seb128> ok
[10:45] <cjwatson> so I think the correct fix is to blacklist l-s, but this time do it properly
[10:45] <dpm> pitti, I've requested an export, let me check if I've already got the link and I'll paste it here
[10:46] <seb128>  Installed-Size: 2320
[10:46] <cjwatson> what's Size?
[10:46] <seb128> against
[10:46] <seb128> Installed-Size: 456
[10:46] <seb128> language-selector-common
[10:46] <cjwatson> and which binary package is that?
[10:46] <cjwatson> ok
[10:46] <seb128> once translations are shipped
[10:46] <seb128> the deb is 277k
[10:46] <cjwatson> against Size: 58036
[10:46] <cjwatson> 200K increase in compressed size doesn't seem too bad
[10:47] <seb128> right
[10:47] <seb128> so let's do an upload without stripping translations?
[10:47] <cjwatson> shall I upload pkgbinarymangler then?
[10:48] <cjwatson> or do we just want to override it in language-selector?
[10:48] <seb128> I was going to just override in language-selector
[10:49] <dpm> seb128, yeah, +1 on that. I don't quite understand what's happened here (why the latest langpacks don't contain the translations even if it's in fact not blacklisted), but we can try to figure out after release.
[10:50] <cjwatson> they are there, they're just in the KDE language packs
[10:50] <cjwatson> $ dpkg -c /home/lp_archive/ubuntu/pool/main/l/language-pack-kde-de-base/language-pack-kde-de-base_10.10+20100930_all.deb | grep language-selector
[10:50] <cjwatson> -rw-r--r-- root/root     12969 2010-10-01 18:14 ./usr/share/locale-langpack/de/LC_MESSAGES/language-selector.mo
[10:50] <seb128> urg
[10:50] <cjwatson> bad heuristics somewhere I assume
[10:51] <dpm> ah
[10:51] <cjwatson> presumably because there's a language-selector-qt but the GTK version is just language-selector
[10:52] <cjwatson> I suspect http://paste.ubuntu.com/506372/ would fix it, but if we're re-blacklisting anyway then who cares
[10:54] <pitti> done with my previous patch, /me reads backlog
[10:56] <pitti> dpm: so the rationale for unblacklisting language-selector from stripping seemed and seems reasonable to me; has this changed?
[10:57] <pitti> Copying af/language-selector into package ../maverick/sources-base/language-pack-kde-af-base
[10:57] <pitti> (from the log)
[10:57] <pitti> cjwatson: right
[10:58] <pitti> cjwatson: classificatio override committed, thanks
[10:58] <pitti> I think we should only blacklist it once for this maverick upload
[10:58] <pitti> but in general keep it stripped
[10:58] <seb128> pitti, should we just "export NO_PKG_MANGLE=1" in the l-s rules?
[10:58] <dpm> pitti, the rationale hasn't changed, as far as I'm aware, although I'm getting a bit lost with all the blacklisting
[10:58] <pitti> the next langpack update will fix that then
[10:58] <cjwatson> pitti: the rationale in the bug report for unblacklisting language-selector only considered the live CD case
[10:59] <pitti> seb128: yes
[10:59] <cjwatson> pitti: it didn't, as far as I can tell, consider the case of an installed system where the desired language just isn't installed yet
[10:59] <ScottK> FYI, I'll be off IRC for the next 13 - 15 hours, so don't wait on me for anything ....
[11:00] <pitti> cjwatson: I thought the rationale was that you'd at least see it in a language you can understand -- after all, it's your desktop language
[11:01] <cjwatson> that's not the rationale given in bug 570240
[11:01] <ubot4> Launchpad bug 570240 in pkgbinarymangler (Ubuntu) "Wrong language-selector package blacklisted (affects: 1) (heat: 23)" [Low,Fix released] https://launchpad.net/bugs/570240
[11:01] <cjwatson> and there are several situations where the desktop language might be English for one reason or another - not on CD and no network access during installation, for instance
[11:02] <cjwatson> in which case the OS installer would have been localised, but now you're dropped into a desktop you don't understand, so I think some guidance in language-selector would not be inappropriate
[11:02] <cjwatson> I thought it was a simple rule - anything needed to install language packs should be blacklisted.  no?
[11:03] <pitti> I don't think we ever spelt it out clearly, but it makes sense for the corner case above
[11:05] <seb128> cjwatson, could you review the g-s-d upload pitti just did once it hit the queue?
[11:05] <seb128> it's the fix for bug #640807
[11:05] <ubot4> Launchpad bug 640807 in gnome-settings-daemon (Ubuntu Maverick) (and 2 other projects) "automatic xrandr module misconfigures monitors (affects: 13) (dups: 3) (heat: 54)" [High,Fix committed] https://launchpad.net/bugs/640807
[11:05] <pitti> will still take some 15 minutes until the debdiff appears, though
[11:06] <seb128> it's basically going back to the behaviour we had before GNOME 2.32
[11:06] <pitti> the change was introduced very late (after FF), in 31.91
[11:11] <cjwatson> seb128,pitti: looks reasonable to me.  the only concern I have is future migration.  will we make sure to migrate gconf configuration for this locally-introduced key, even if upstream uses a different name in future?
[11:12] <seb128> cjwatson, we will switch to gsettings next cycle
[11:12] <pitti> cjwatson: that's indeed a concern; however, fortunately they will migrate to gsettings soon anyway
[11:12] <seb128> so upstream will not go for a gconf key
[11:12] <pitti> cjwatson: so if they change the name, we'd only need to change the key name in the migration code
[11:12] <seb128> and gconf -> to gsettings is dropping one line in a file
[11:12] <dpm> cjwatson, pitti, seb128: thanks a lot for looking into the l-s translations issue
[11:12] <seb128> so migration will be easy
[11:12] <pitti> right
[11:13] <cjwatson> hm, ok
[11:14] <seb128> brb
[11:18] <pitti> dpm: so, want me to wait on your export, so that I can update the translations in the package?
[11:20] <dpm> pitti, whatever suits you best. I've just got the export link: http://launchpadlibrarian.net/57123174/launchpad-export.tar.gz If you could include those translations, that would be great. If those are too big a change at this point, just including the existing translations in the package would be a big improvement already
[11:21] <pitti> dpm: I don't see why we shouldn't include them; the current po files in the package weren't tested any more (i. e. not at all) than the ones in the langpacsk
[11:21] <pitti> i. e. the launchpad ones were at least tested in KDE
[11:21] <pitti> or from folks with the KDE langpacks installed
[11:22] <dpm> pitti, +1. They were also tested by ubuntu folks, as the transition to the kde langpack seemed to happen recently (I just noticed it when I reported the bug, before it was translated in Ubuntu)
[11:23] <dpm> or at least that was my impression
[11:25] <pitti> ok, works fine in German; I installed pkgbinarymangler, and -common has the po files now; both the menu entry and the app itself are in German now
[11:25] <dpm> cool
[11:30] <pitti> uploaded
[11:58] <doko> cjwatson: we really need a list of sources which are not yet build in a distribution ...
[11:59] <doko> built even
[12:01] <doko> just found eigenbase-resgen and mondrian
[12:02] <wgrant> doko: You mean things that haven't been rebuilt in maverick, or something else?
[12:03] <ttx> ScottK: looking...
[12:03] <cjwatson> doko: http://people.canonical.com/~ubuntu-archive/testing/maverick_outdate_all.txt
[12:03] <cjwatson> oh, that's only out of date, not never built at all
[12:03] <cjwatson> feel free to extend lp:ubuntu-archive-reporting :-)
[12:04] <doko> heh
[12:04] <cjwatson> actually it's lp:~maxb/+junk/ubuntu-archive-reporting isn't it ...
[12:04] <maxb> heh
[12:04] <maxb> shall we move that?
[12:04] <cjwatson> as you like ...
[12:04] <cjwatson> we have a minor branch deployed anyway
[12:04] <cjwatson> (path, arch, suite changes)
[12:05] <doko> maxb: do you volunteer to extend it?
[12:05] <maxb> uh, possibly :-)  I might need to remind myself how feasible what you suggest is in the current code first
[12:06] <ttx> ScottK: looks reasonable to me.
[12:13] <ttx> ScottK: though we could (should) filter out the non-security changes, they seem quite harmless.
[12:13] <Riddell> ttx: ScottK is away today
[12:16] <ttx> Riddell: ok -- I was just answering a question he had about bug 636482
[12:16] <ubot4> Launchpad bug 636482 in python-django (Debian) (and 1 other project) "Update python-django to 1.2.3 version to fix an XSS vulnerability (affects: 2) (dups: 1) (heat: 26)" [Unknown,Unknown] https://launchpad.net/bugs/636482
[12:57] <bdrung> doko: sorry, i don't have time to work on these. a quick look showed that we are using old versions or the upstream changes don't improve the build failure
[12:57] <cjwatson> could somebody please review lupin?
[12:57] <doko> looking
[13:08] <cjwatson> doko: thanks
[13:14] <doko> bdrung: ok, then I'll remove audacious-dumb and audacious-dumb and disable the plugins for imms, upse and xmp
[13:14] <doko> cjwatson: ^^^ ?
[13:15] <cjwatson> seems like the best option at this point to get rid of the last NBS other than opensync
[13:15] <doko> what do you think about opensync?
[13:16] <cjwatson> I commented on that yesterday
[13:16] <cjwatson> 16:55 <cjwatson> I'm worried about the results but don't see what else we can do really
[13:16] <cjwatson> 16:55 <cjwatson> I do think we should restore it in an SRU if at all possible
[13:16] <cjwatson> 16:57 <cjwatson> the bug needs some better discussion of the problem and why this is the only option - people are going to find it while wondering what happened to opensync
[13:16] <cjwatson> for the audacious stuff - please only remove binaries
[13:16] <cjwatson> no need to remove sources if there are no build-deps involved in NBS
[13:16] <doko> yes
[13:17] <doko> updated the opensync bug report today:
[13:17] <doko> the alternative would be to downgrade to opensync to (< 0.30), and then rebuild/downgrade the following packages too:
[13:17] <doko> osynctool
[13:17] <doko> libopensync-plugin-syncml
[13:17] <doko> libopensync-plugin-file
[13:17] <doko> libopensync-plugin-evolution2
[13:17] <doko> libopensync-plugin-xmlformat
[13:17] <doko> libopensync-plugin-vformat
[13:18] <Riddell> does anything use opensync?  it's dead upstream as far as I know
[13:18] <cjwatson> I guess if that can be done without involving an epoch (and hence breaking merges forever), it would be preferable
[13:18] <cjwatson> Riddell: "dead upstream" doesn't seem compatible with "new upstream versions uploaded quite recently to Debian experimental"?
[13:19] <doko> azeem will join us here in 15min ...
[13:34] <doko> please review upse and xmp
[13:36] <mvo> about this apt upload, it does fix the test case in the changelog (postfix failing to instal if exim is already installed). I did exsessive tests on it and created lp:~mvo/+junk/apt-resolver-regression-tests  to ensure it does nothing bad (plus inspected the code of course), so it should be fine. if you prefer it as a SRU that is fine for me as well
[13:38] <lamont> mvo: what was the issue?  (as in should postfix do something differently?)
[13:39] <ttx> Riddell, cjwatson: do we have a tentative schedule for the final ISO generation yet ?
[13:39] <ttx> (I mean, the first candidates for final)
[13:39] <mvo> lamont: postfix is fine, apt is having a issue in maverick
[13:40] <mvo> lamont: its just a convinient test-case
[13:40] <lamont> ah, ok
[13:41]  * lamont unstresses
[13:42] <mvo> lamont: no worries (and yeah, release week is fun, isn't it?)
[13:44] <lamont> heh
[13:44] <lamont> you keep using that word....
[13:53] <cjwatson> ttx: not before tomorrow
[13:53] <ttx> cjwatson: ok, thanks !
[13:54] <doko> hi azeem_
[13:54] <doko> what do you suggest for the opensync mess?
[13:59] <azeem_> gah, network is really slow here
[14:05] <azeem_> doko: ok, so the file and evolution plugins are the ones which should get reverted I guess, and the syncml one dropped
[14:06] <doko> azeem_: and opensync reverted too? which version number should be used?
[14:07] <doko> epoch, or fake version
[14:08] <cjwatson> please not an epoch
[14:08] <cjwatson> unless Debian uses one too I suppose
[14:09] <azeem_> my preference would be uploading 0.22-4squeeze1 to t-p-u after coordination with the Debian release team, and then merge a fake version to maverick from there
[14:09] <azeem_> if that is possible
[14:10] <cjwatson> we're not likely to have time to wait for t-p-u
[14:10] <cjwatson> the absolute hard deadline for unseeded packages in universe/multiverse is tomorrow noon UTC
[14:10] <cjwatson> actually no
[14:11] <cjwatson> sorry, noon UTC on Oct 9
[14:11] <cjwatson> so I suppose we can wait a day or two for t-p-u review
[14:13] <azeem_> packages against testing are at http://people.debian.org/~mbanck/opensync-squeeze
[14:13] <azeem_> I didn't have much time last night to test them as well though, will do now after checking what else is missing
[14:35] <doko> wgrant: no, packages which are not built at all (and are not built because the build dependencies are missing). these show not up on ubuntuwire.com/ftbfs
[14:39] <micahg> could a member of the release team please look at bug 650601?
[14:39] <ubot4> Launchpad bug 650601 in libfxscintilla (Ubuntu) "[FFe] Please update libfxscintilla to 2.11.0 (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/650601
[14:57] <cjwatson> doko: seems to be a lot of cruft in the debdiff of upse from what's in the archive - is it necessary?
[14:58] <doko> looking ...
[15:00] <azeem_> cjwatson, doko: ok, I asked for tester feedback on opensync-users and debian-user
[15:01] <doko> cjwatson: re-uploaded with the same version number
[15:01] <doko> azeem_: thanks
[15:04] <jdstrand> cjwatson: I'm not keen on cosmic rays. I've tested 4 more installs without incident
[15:05] <jdstrand> so I'm forgetting about it now too
[15:11] <doko> rejected my first upse upload
[15:13] <cjwatson> jdstrand: duly forgotten
[15:32] <Daviey> jdstrand: I tried to reproduce it last night in KVM... and couldn't
[16:01] <Daviey> Hi... been looking at Bug #600174 ... The axis2c code seems really buggy (valgrind), and now the FTBFS seems to have happened because of tool chain changes.  Disabling the test suite produces binary packages... Looking for advice from the RT with what to do.
[16:01] <ubot4> Launchpad bug 600174 in axis2c (Ubuntu Maverick) (and 1 other project) "axis2c fails to build from source on maverick/i386 (affects: 3) (dups: 1) (heat: 22)" [High,Confirmed] https://launchpad.net/bugs/600174
[16:02] <Daviey> there is an i386 package currently in maverick.... which is good...
[16:02] <Daviey> .. but if a security update is needed... it's going to need work
[16:02] <Daviey> (or disabling the test suite)
[16:03] <Daviey> Should we just leave it in FTBFS for now?
[16:07] <doko> Daviey: does it build with gcc-4.5? it's in main too, so could be an alternative. didn't check myself
[16:10] <Daviey> doko: Ah.. good point
[16:10] <doko> Daviey: also trying with -O0/-O1
[16:11] <Daviey> doko: I will try that... but i really wanted to establish if it's worth my time working on it at the moment... rebuilding so close to release scares the crap out of me :)
[16:11] <doko> Daviey: well, target it for maverick-updates and work later on it?
[16:12] <Daviey> doko: Yeah... that takes the pressure off slightly :)
[16:14] <cjwatson> hm, dmraid installations not so happy, grub installed to wrong place
[16:14] <cjwatson> and there's only been a bug open about this for six months or so ...
[16:15] <cjwatson> buggeration.
[16:19] <\sh> ScottK: ping
[16:22] <\sh> ScottK: for universe and bugfix releases (native package which results in a new version) do we need to file a FFe or just follow "Feature Freeze for bugfix only updates" ?
[16:22] <doko> ScottK is offline for a some hours
[16:22] <doko> cjwatson: please could you review the reuploaded upse?
[16:23] <Laney> \sh: no special freeze ATM AFAIK
[16:23] <doko> heh, he didn't like it
[16:26] <\sh> Laney: k..thx
[17:00] <azeem_> doko: I guess the google-calendar plugin needs to be dropped as well, as per LP#244877
[17:01] <doko> azeem_: could you document this in bug #654613 ?
[17:01] <ubot4> Launchpad bug 654613 in multisync0.90 (Ubuntu) (and 10 other projects) "remove packages needing opensync (<< 0.30) in maverick (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/654613
[17:07] <mvo> the aptdaemon upload I just did is not a OMG-this-needs-to-be-in-NOW upload, we can also do it as a SRU on the first day. it collected a bunch of dupes, this is why I uploaded it
[17:07] <mvo> (now)
[17:08] <azeem_> doko: gah, it's still http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg503765.html
[17:08] <azeem_> I've no idea (i) how I came up with that patch (ii) why I thought that patch/upload fixed it
[17:08] <azeem_> but applying it to /usr/share/pyshared/Ft/Xml/XPath/ParsedAxisSpecifier.py fixes it
[18:09] <cjwatson> doko: your binutils-avr upload also removed bug-lpm.c and bug-lpm.o.  was that intentional?
[18:10] <doko> yes
[18:10] <cjwatson> ok
[18:11] <doko> maybe I should have left it there to keep the diff minimal
[18:11] <cjwatson> *shrug* accepted anyway
[18:16] <doko> cjwatson: enblend-enfuse is the last one for today. and I assume that there's enough buildd power to build gcc-snapshot
[18:18] <cjwatson> I'm not entirely sure about that assumption
[18:18] <cjwatson> is it vital we have a new snapshot?
[18:18] <doko> no
[18:18] <doko> fixes the build failure on powerpc
[18:19] <cjwatson> oh, hm, didn't realise it was failing
[18:20] <cjwatson> it takes over two days on armel
[18:20] <cjwatson> I guess it has to be now or not at all ...
[18:21] <cjwatson> could somebody review initramfs-tools?
[18:24] <doko> done
[18:25] <cjwatson> thanks!
[18:25] <cjwatson> oh, urghurgh, queuebot fell over
[18:30] <cjwatson> no longer running on my home machine, so should have a better chance of staying up
[18:30] <doko> interesting, removed the auacious-dev b-d, now ftbfs with missing zlib header ...
[18:31] <cjwatson> hm, spewing lots of stderr, but I guess I can ignore that for now
[18:33] <doko> the enblend-enfuse upload fixes the ftbfs on armel, didn't mention it in the changelog
[18:46] <doko> I don't why we need armel->avr and armel->z80 cross toolchains ...
[20:47] <micahg> I still have 2 FFe bugs that need to be looked at for universe (bug 631221 and bug 650601)
[20:47] <ubot4> Launchpad bug 631221 in calendarserver (Ubuntu Maverick) (and 1 other project) "FFe: Sync calendarserver 2.4.dfsg-2 (universe) from Debian unstable (main) (affects: 10) (dups: 2) (heat: 181)" [Wishlist,Fix released] https://launchpad.net/bugs/631221
[20:47] <ubot4> Launchpad bug 650601 in libfxscintilla (Ubuntu) "[FFe] Please update libfxscintilla to 2.11.0 (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/650601
[20:47] <micahg> oops
[20:47] <micahg> sorry, that first one is wrong, should be bug 651514
[20:47] <ubot4> Launchpad bug 651514 in tortoisehg (Ubuntu) "FFe: Sync tortoisehg 1.1.1-1 (universe) from Debian unstable (main) (affects: 5) (dups: 2) (heat: 34)" [Medium,New] https://launchpad.net/bugs/651514
[21:09] <ogra> someone of the release team please let the x-loader-omap4 package through, it add the missing support for the final omap4 hardware revision, it was tested heavily by ubuntu and TI engineers on that HW
[21:16] <ogra> skaet, i need an official ok for that package i guess
[21:16] <ogra> (the one above my last line)
[21:40] <cjwatson> ogra: done
[21:44] <ogra> cjwatson, thanks a lot
[21:47] <cjwatson> micahg: tortoisehg granted (and sync-helper running), will read through libfxscintilla later
[21:49] <micahg> cjwatson: awesome thanks
[23:08] <cjwatson> micahg: libfxscintilla approved
[23:08] <cjwatson> I'd appreciate somebody looking over grub-installer and debian-installer, if anyone has a moment
[23:09] <micahg> cjwatson: k, I'll finish the update tonight and find someone to upload, thanks
[23:11] <cjwatson> Riddell: I don't hugely care since it's just a debug message, but this chunk http://paste.ubuntu.com/506842/ in the pulseaudio diff looks wrong - the else will bind to the inner if, not the outer one
[23:11] <cjwatson> Riddell: at the very least it's wrongly indented.  might want to let Colin Guthrie know
[23:12] <cjwatson> Riddell: is there a bug associated with this pulseaudio upload, or a mailing list reason or something?
[23:12] <Riddell> mm, that's why I always use curly brackets with if statements
[23:13] <Riddell> cjwatson: http://permalink.gmane.org/gmane.comp.audio.pulseaudio.scm/2725 is the main reference I was given
[23:13] <Riddell> I was hoping crimsun would give me his opinion but he's been silent
[23:13] <Riddell> I can file a bug and get Colin Guthrie to explain his reasoning if you want
[23:14] <cjwatson> well, they all look reasonable enough from the patch descriptions, I'm just wondering about the tradeoff for putting it into maverick at this late point vs. an SRU
[23:14] <cjwatson> I don't know enough about pulseaudio to evaluate how serious any of those things are
[23:14] <cjwatson> happy to accept if they are serious
[23:15] <Riddell> I don't think it matters much either way
[23:20] <cjwatson> Riddell: well, if you can manage to track down crimsun by tomorrow morning, or otherwise find an explanation of seriousness, I'm happy to let it in
[23:20] <cjwatson> pulseaudio just makes me nervous :)
[23:25] <cjwatson> done with reviewing for tonight, early start tomorrow to get to London