[00:01] <charlie-tca__> hmm, Xubuntu desktop 64 is still oversize. It is now 712MB, which won't a cd.
[00:01] <charlie-tca__> (after the respin, too)
[00:05] <charlie-tca__> pitti: ^ ^  ^ still need to trim more
[00:09] <slangasek> charlie-tca__: what should be trimmed?  That's a decision for the xubuntu devs rather than the release team, isn't it?
[00:11] <charlie-tca__> mr_pouit told me pitti was trimming it. I will go back to him and see what he can do.
[00:15] <slangasek> well, I can trim things, but the decisions about what should go are really for the xubuntu team to make
[00:16] <slangasek> I guess language packs are the first choice :)
[00:16] <charlie-tca__> okay. I will try to get mr_pouit on it. pitti was going to do something agreed by him and lionel already.
[00:17] <charlie-tca__> I asked pitti before the respin, since there was no reason to respin if it wasn't gonna fit yet, and he said he trimmed it already
[00:17] <slangasek> it's 1am in Germany, so I think pitti is safely away
[00:18] <charlie-tca__> Oh, yeah. France too, I guess.
[00:18] <charlie-tca__> I guess it will have to wait for one of them
[00:19] <stgraber> same timezone, so they should be back in 7-8 hours
[00:21] <slangasek> charlie-tca__: nah, if they're both out, no need to lose the time; if they don't like the changes I make they can revert and no harm done
[00:22] <charlie-tca__> Works for me. If you need me say okay as team lead, go for it
[00:22] <slangasek> in fact, from what I see the changes didn't take because we haven't done a task regeneration run in the archive since the seeds were changed
[00:22] <slangasek> so I may just need to kick the archive harder and respin
[00:23] <charlie-tca__> Well, let's do that then. We need those changes to happen
[00:27] <slangasek> ScottK: accepting ubuntu-sugar-remix-meta
[00:30] <GrueMaster> slangasek: Respin?  What for?
[00:30] <slangasek> GrueMaster: xubuntu oversize, nothing to worry about
[00:30] <GrueMaster> Ok.  I haveenough to panic about here.
[00:50] <slangasek> kubuntu arm seems to be done some time ago; posting to the tracker
[00:50] <charlie-tca__> Thank you, slangasek
[00:54] <slangasek> oh, well, good thing we have another package that was just accepted, because apparently we were a full two publisher cycles behind having the xubuntu tasks in sync - sigh
[00:54] <slangasek> hmm, or did that get accepted at just the wrong moment
[00:54] <slangasek> yah, it did
[00:55] <charlie-tca__> heh, I been complaining about the oversize for two spins now
[00:56] <slangasek> well, the current respin is smaller than the preceding
[00:56] <slangasek> but there were no publisher runs after the seed change, to make them effective
[00:56] <slangasek> no non-empty publisher runs, that is
[01:46] <slangasek> right, found the runes for forcing the publisher
[01:46] <slangasek> running now; and I'm running out the door, so will have to respin xubuntu a bit later
[03:58] <ScottK> slangasek: I thought I saw a note from you that syncing python-django wouldn't affect the server ISO.  If that's true, I recommend we do it.
[03:59] <ScottK> See Bug 636482
[03:59] <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
[04:08] <ScottK> Actually now that i read the bug again, I remember why we can't sync it yet.
[04:08] <ScottK> Nevermine.
[04:08] <ScottK> e/d
[04:33] <FireCrotch> Hi. I have a question pertaining to getting a bug-fix included in Maverick before release, not quite sure about how to go about the process
[04:35] <FireCrotch> The fix is for this bug: https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/619663  and the fixed packages are contained in a ppa linked to in the comments
[04:35] <ubot4> Launchpad bug 619663 in libdrm (Ubuntu) (and 2 other projects) "[maverick] Non-mirrored dual-screen gives narrow display on secondary monitor (affects: 22) (dups: 6) (heat: 134)" [High,Fix committed]
[05:39] <ScottK> FireCrotch: Unless it's worth delaying the whole release for, it's too late.
[05:43] <FireCrotch> ScottK: Well, I guess that depends on what is considered worth delaying the whole release for. :) Maybe it's a bug that we can at least get mentioned in the release notes and upload a fixed package for updates, for those who do need the functionality?
[05:44] <ScottK> That would be a better approach.
[05:47] <FireCrotch> Is there someone specific that I can contact to coordinate that?
[05:50] <RAOF> FireCrotch: Sarvatt is already on it.
[05:56] <FireCrotch> RAOF: Oh, thank you
[06:21] <ScottK> slangasek, cjwatson, etc: I'm leaving ninvaders in the queue if you need to stimulate a publisher run.  It should be good to accept if you need it.
[06:27] <slangasek> ScottK: yes, python-django isn't on the server - I figured that one had been done already, grabbing it now
[06:37] <slangasek> ok, the xubuntu-live task is starting to make me angry
[06:37] <slangasek> ScottK: ah, read the rest of scrollback before committing the change; good :)
[06:39] <ScottK> I'll leave you both gjs and ninvaders then for more publisher runs.
[06:39] <slangasek> thanks
[06:39] <slangasek> I need to figure out why the preceding publisher runs didn't already do the job, first :/
[06:40] <wgrant> I'm confused. Are the publisher's careful flags not enough? Why do you need uploads?
[06:40] <slangasek> wgrant: the what flags?
[06:40] <wgrant> You can tell the publisher to publish indices for a suite, and only that suite.
[06:40] <wgrant> Regardless of if there are uploads to be dealt with.
[06:41] <slangasek> wgrant: you know that our interface to this is "look at the crontab; hunt down the publisher cron job; find the magic line; edit until it does what we want"? :)
[06:41] <wgrant> Heh.
[06:42] <slangasek> anyway, what's going wrong now is germinate, somehow
[07:04] <ara> good morning all
[07:11] <pitti> Good morning
[07:11] <pitti> charlie-tca, slangasek: yes, indeed I trimmed some langpacks (since I added some a week ago)
[07:11] <slangasek> hey there
[07:12] <slangasek> so I'm rerunning germinate by hand, but I don't have high hopes; it's not picking up the latest xubuntu seed changes you made
[07:12] <slangasek> I don't know why yet
[07:12] <pitti> ah, seems that was sorted out now, *phew*; I was already afraid I couldn't count until 12 any more..
[07:13] <pitti> uh, darn
[07:14] <slangasek> http://people.canonical.com/~ubuntu-archive/seeds/xubuntu.maverick/live is out-of-date
[07:18] <slangasek> trying to run the cronjob manually now
[07:41] <slangasek> well, ok, how did platform.maverick wind up getting its bzr branch upgraded to a format incompatible with what was being used on people.c.c... within two days of me commenting that now is perhaps not the time in the release cycle to make such a change
[07:41] <slangasek> sorted now
[07:44] <pitti> wasn't me, promised (bzr upgrade)
[07:44] <pitti> thanks
[07:45] <slangasek> pitti: sure, more likely me than you, I've hit a few 'upgrade' buttons on the website in the past few days... I just can't imagine why I would've done that
[07:47] <slangasek> ok, publisher running
[09:06] <doko> do we still run fdupes during live CD builds?
[09:08] <mvo> doko: I think we do (last I looked at the builder script)
[09:10] <doko> mvo, don't see it in http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu/
[09:19] <cjwatson> wgrant: two things in response to that: (1) the fundamental problem is that cron.germinate doesn't mark suites dirty when its output changes (or possibly that cron.germinate isn't more internal to the publisher, but that's harder); (2) using publish-distro.py's -A flag means that you have to unpick cron.publish-ftpmaster, which is really quite tedious
[09:20] <cjwatson> slangasek: apologies, that was my fault while trying to make bzr not crash for skaet checking out the seeds - I forgot that it would require work on people.c.c too
[09:20] <wgrant> cjwatson: You can't dirty a pocket from outside the publisher (it's in-process state). But we want to fix that for other reasons.
[09:20] <ara> skaet, good morning
[09:21] <ara> skaet, any reason why the upgrades are not yet in the tracker?
[09:21] <cjwatson> wgrant: maybe I should put it differently: when publish-distro.py starts up it considers whether there are any uploads in queues but not whether cron.germinate has changed
[09:21] <cjwatson> (that's not entirely in-process)
[09:21] <wgrant> cjwatson: Right.
[09:21] <wgrant> It purely calculates the dirtyness from the state of the DB, which cron.germinate is not in.
[09:22] <skaet> ara, looking into it...
[09:24] <cjwatson> slangasek: of course, this means that I'm now having trouble running 'bzr up' because the repository is in the wrong format *sigh*
[09:25] <cjwatson> I may just have to go round and upgrade everything, but I guess I should wait for a little while
[09:26]  * cjwatson does 'bzr reconfigure --standalone' in the meantime
[09:26] <skaet> ara,  they're there now.
[09:26] <ara> skaet, ok, thanks
[09:48] <didrocks> ara: was it really slow for you for bug #656713? I wasn't paying really attention, but when I looked again, the installation was finished on my box without internet connexion and one selected French.
[09:48] <ubot4> Launchpad bug 656713 in ubiquity (Ubuntu) "Ubiquity tries to get lang packs from Internet, even though there is no connection (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/656713
[09:49] <ara> didrocks, well, it tried to download about 60-something packages, and it fails one by one, so, yes, it makes it slower
[09:50] <ara> I guess it can be solved in a SRU, as it does not fail, but as it should know that there is no internet connection, my guess is that it should skip that part
[09:50] <didrocks> ara: ok, I probably didn't pay attention to that, it was an acceptable time when not looking at it. Thanks :-)
[09:50] <didrocks> ara: I just tried to trick it and try "install mp3 support and updates". Was pretty slow when clicking on next, not sure it's related, I will try without that
[09:51] <didrocks> (like a min here to go to next screen)
[09:51] <didrocks> and with dummy partition table (just 2 tables, no lvm, no raid, nothing fancy)
[09:52] <ara> so how's the conversation going in the release sprint?
[09:53] <cjwatson> quiet
[09:53] <ara> :)
[09:59] <ttx> ara: as in "completely silent" quiet
[10:03] <cjwatson> ttx: as in "god I need coffee" quiet.  speaking of which ...
[10:19] <cjwatson> ara: 656165> hm, can you check your /etc/apt/sources.list after installation?  does it have (es.)archive.ubuntu.com entries?
[10:19] <cjwatson> 'cos the logs suggest it might not and that would be bad
[10:20] <ara> cjwatson, mmm, I don't have access to it anymore. I will try again as soon as I finish the installation I¡m doing now, and will let you know
[10:20] <cjwatson> as in respin bad
[10:21]  * cjwatson burns a test image
[10:21] <ara> cjwatson, but I think it did have it, because I remember checking that (to see if the bug with the source list was solved)
[10:24]  * ara listens to Bowie's Space Oddity as perfect OST for release testing
[10:24] <nigelb> heh
[10:26] <ara> Riddell, rekonq keeps crashing for me under KVM, have you tried that?
[10:28] <ara> bug 650934
[10:28] <ubot4> Launchpad bug 650934 in rekonq (Ubuntu) "Rekonq crashes in a KVM with 800MB ram (affects: 1) (heat: 487)" [Undecided,New] https://launchpad.net/bugs/650934
[10:29] <Riddell> ara: i've never used kvm
[10:32] <ara> I love the retro use of the stereo on that song :)
[10:32] <ara> cjwatson, I am testing again bug 656165
[10:32] <ubot4> Launchpad bug 656165 in ubiquity (Ubuntu) "Language support incomplete after installation (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/656165
[10:33] <cjwatson> as am I
[10:33] <cjwatson> and ev apparently ...
[10:34] <ev> it's a party bug :)
[10:55] <ara> cjwatson, I cannot reproduce it now, so it seems that it was a transitional network problem, or something like that
[11:00] <cjwatson> ara: I think it is very probable that it depends on latency to the archive mirror.  that said there does seem to be something odd
[11:05] <ev> didrocks: was your removal of the note about not being able to use Startup Disk creator to create 10.04 images from Ubuntu 10.10 intentional?
[11:05] <ev> in: https://wiki.ubuntu.com/MaverickMeerkat/TechnicalOverview?action=diff&rev1=96&rev2=95
[11:06] <didrocks> ev: hum, no I read probably the other way around (creating 10.10 disk from lucid). Fixing it then, sorry
[11:07] <ev> no worries
[11:07] <ev> I just wanted to be sure you didn't know something that I was unaware of :)
[11:07] <didrocks> ev: that would we weird on usb creator :-)
[11:07] <didrocks> I'm updating the unity part as well
[11:07] <ev> heh
[11:07] <ev> cool, thanks
[11:20] <ara> cjwatson, how is the investigation on the OEM issue (respin-wise)?
[11:25] <cjwatson> ara: could you be more specific, please?
[11:27] <ara> cjwatson, bug 650703
[11:27] <ubot4> Launchpad bug 650703 in ubiquity (Ubuntu Maverick) (and 1 other project) "oem-config-prepare works, but oem-config fails to start after reboot (affects: 2) (heat: 10)" [High,Incomplete] https://launchpad.net/bugs/650703
[11:41] <ev> ara: we need someone who can reproduce it to provide us with upstart debugging information
[11:41] <ev> so --debug on the kernel command line
[11:42] <cjwatson> ara: and since we can't reproduce, it's hard to consider it a respin candidate at the moment
[11:43] <cjwatson> ara: also, as Rick pointed out, the primary audience of oem-config is OEMs, who aren't constrained to using just the release image, so this can be fixed post-release if need be
[11:43] <ara> cjwatson, sure thing, thanks for the update
[11:43] <cjwatson> but indeed, what ev said
[12:01] <ara> cjwatson, ev, Riddell: Kubuntu amd64 OEM (DVD) just crashed for me
[12:01] <ara> bug 656819
[12:01] <ubot4> Launchpad bug 656819 in ubiquity (Ubuntu) "Ubiquity crashed while installing Kubuntu DVD amd64 OEM mode (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/656819
[12:02]  * Riddell still downloading amd64 dvd
[12:04] <Riddell> hum, that doesn't look too good
[12:05] <cjwatson> Oct  8 10:28:19 ubuntu in-target: Failed to fetch http://extras.ubuntu.com/ubuntu/dists/maverick/main/source/Sources.bz2  Hash Sum mismatch
[12:05] <cjwatson> the consequence is obviously bad
[12:06] <cjwatson> but I think that's why it's happening
[12:06] <cjwatson> (this is essentially web cache skew - you have a "transparent" proxy between you and the internet, probably)
[12:08] <cjwatson> wonder why it's causing sources.list to be completely missing though; that's bizarre
[12:11]  * pitti yays at the empty "Daily CD health checks" email
[12:12] <cjwatson> in fact, that failure ought to be entirely ignored
[12:57] <robbiew> cjwatson: working through issues documented in Lucid's release notes for any carry over....was bug 345126 fixed for Maverick?
[12:57] <ubot4> Launchpad bug 345126 in partman-auto (Ubuntu Lucid) (and 3 other projects) "Installer creates too small swap partition (hibernation fails) (affects: 6) (heat: 19)" [High,Won't fix] https://launchpad.net/bugs/345126
[13:02] <robbiew> ev: ^ ?
[13:04] <ev> robbiew: doesn't appear to have been.
[13:04] <robbiew> ack...release noting
[13:05] <ev> robbiew: best to check with cjwatson though.  Perhaps I'm looking in the wrong place for the change.
[13:06] <robbiew> ev: fair'nuf
[13:08] <cjwatson> shouldn't think so, given the won't fix
[13:08] <cjwatson> oh, that was for lucid.  but no, it wasn't
[13:10] <robbiew> skaet: ^^^ fyi,  another reason why we need to be able to have 2 distros open for development in launchpad :/
[13:12] <wgrant> We can technically create natty now, but we can't have it accepting uploads.
[13:14] <robbiew> wgrant: ah..so we could target bugs?
[13:15] <ScottL> was anyone wondering about a ubuntu studio respin for ia32-libs?
[13:15] <wgrant> robbiew: Right. The publisher will no longer combust if it sees an uninitialised series.
[13:15] <wgrant> But it's probably a bit late to be considering that now.
[13:16] <wgrant> (this has only been possible for a month or two)
[13:16] <robbiew> wgrant: ah...cool...and yes, no need to rock the boat ;)
[13:16] <wgrant> But for next time we should probably test and do that.
[13:21] <ScottK> ScottL: Do you want to respin for ia32-libs?
[13:23] <cjwatson> wgrant: what would the status of the new distroseries be?
[13:24] <wgrant> cjwatson: Probably Experimental.
[13:24] <wgrant> Since it can't be Development.
[13:24] <ScottL> ScottK, i believe YokoZar would like the respin and i do not object and can support it
[13:24] <cjwatson> indeed, can only have one of those
[13:24] <ScottK> cjwatson: Do you have any objections to an Ubuntu Studio respin?
[13:29] <ScottL> ScottK, i'm about to leave to take kids to school and go to work, i will be back on as scott-work in about 1.5 hours
[13:29] <ScottK> ScottL: OK.  I'll accept it if cjwatson thinks it's OK.
[13:32] <doko> hmm, I think I should reject the just uploaded libapache2-mod-python, because it's on the server cd
[13:34] <ScottK> doko: I was just about to suggest that.
[13:40] <cjwatson> ScottK: no objections
[13:40] <ScottK> OK.  Thanks.
[13:48] <ScottK> cjwatson: ia-32libs is built, so would you please respin Ubuntu Studio amd64 in an hour?
[13:48] <ScottK> ScottL: ^^^
[14:01]  * ara goes for a late lunch
[14:17] <cjwatson> ScottK: ack
[14:40] <scott-work> ScottK:  i read the logs, thank you (and cjwatson ) for your assistance
[14:44] <robbiew> skaet: I pruned the resolved Lucid issues from https://wiki.ubuntu.com/MaverickMeerkat/ReleaseNotes
[14:50] <skaet> robbiew:  thanks!
[15:01] <cjwatson> scott-work: respin running
[15:27] <cjwatson> ScottK,GrueMaster: do either of you know what the story is with Kubuntu arm preinstalled-desktop (not mobile) images?  They were published for RC, but there's only one entry in the ISO tracker, which is "Kubuntu Desktop Arm (omap)" (presumably omap3?) with a wrong link in its info
[15:27]  * ScottK looks at GrueMaster
[15:28]  * ScottK recalls he tested something ....
[15:28] <cjwatson> ScottK,GrueMaster: so I don't know how the omap4 one got tested, and it's going to make it difficult to automatically emit publication commands for omap4
[15:29] <cjwatson> scott-work: ubuntustudio reposted
[15:36] <Riddell> cjwatson: for RC the Kubuntu arm preinstalled-desktop images were on the ISO tracker as Kubuntu Netbook Arm (omap)
[15:38] <GrueMaster> cjwatson: I have not tested the final release for kubuntu, and am not in a position to test them this week.
[15:44] <scott-work> cjwatson: thank you
[15:48] <cjwatson> Riddell: *blink* ok, that's even more confusing, but is no help anyway as that's still only one image not omap(3) + omap4?
[15:49] <cjwatson> there's only Kubuntu Desktop Arm (omap) there now rather than Kubuntu Netbook Arm (omap), which I think is probably an improvement in terms of accuracy, but ...
[16:06] <didrocks> ev: does my proposal to bug #656777 make sense? (well, too late for maverick in any case, but it can help for natty)
[16:06] <ubot4> Launchpad bug 656777 in ubiquity (Ubuntu) "Wrong keyboard selection with starting directly ubiquity (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/656777
[16:08]  * ev ponders
[16:12] <Riddell> cjwatson: unfortunately I don't know how the iso testing site works enough to fix it
[16:15] <ev> didrocks: an inidicator that opens a dialog of options is, I think, going to be the best solution in Natty.  I talked to cjwatson about it, and trying to guess the keyboard on language alone has been attempted before and had to be quickly reverted.
[16:16] <didrocks> ev: sure, but setting it as default can also be interesting. My point is that you already select "fr oss" in the keyboard layout selection dialog when you choose "French" in the first dialog. So, you are already making an assumption. Making the same assumption from the start will make more sense, isn't it?
[16:18] <cjwatson> Riddell: it's more a question of what we should be doing.  if we should be publishing both omap and omap4, I can work around it
[16:19] <cjwatson> didrocks: it's quite subtle for different languages
[16:19] <cjwatson> and in gfxboot, there's a menu so you get to change the assumption if it's wrong
[16:19] <cjwatson> anyway, I just discussed this with ev in person
[16:20] <didrocks> cjwatson: if I understand correctly, you are afraid of false positive and think it's better to only set a default on a screen when you can change the layout if it doesn't fit, right?
[16:21] <cjwatson> I'm not afraid of false positives, I *know* we will get it wrong a significant percentage of the time :)
[16:21] <cjwatson> we could fiddle with default assumptions, certainly, but we have to have an indicator anyway so that you can override
[16:21] <Riddell> cjwatson: we should publish both
[16:21] <didrocks> cjwatson: fair enough then :)
[16:22] <didrocks> and that will enable changing for setting a passphrase with the correct layout too, so fine with me
[16:22] <cjwatson> us
[16:22] <cjwatson> uh
[16:22] <cjwatson> didrocks: the keyboard layout is asked properly before passphrase
[16:22] <cjwatson> so that really isn't an issue already, as far as I know
[16:23] <cjwatson> unless you mean network passphrase
[16:23] <didrocks> cjwatson: sorry, do you mean, in network manager for wifi key?
[16:23] <didrocks> yeah
[16:23] <cjwatson> best be specific about these things :)
[16:23] <didrocks> cjwatson: sorry, I should have been, right :-)
[16:24] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-users/2004-September/001405.html  https://lists.ubuntu.com/archives/ubuntu-users/2004-September/002211.html
[16:24] <cjwatson> ^- from last time we tried to infer keyboard layout from language and not provide a way to override :)
[16:24] <GrueMaster> Ok,I am starting on the Ubuntu Dove netbook image.  Live is booting fine, no glaring issues.  Starting installer then off to a meeting.  Will update tracker info when I get back.
[16:25] <Riddell> talking about meetings, do we have a release team meeting today?
[16:25] <didrocks> cjwatson: again, I understand the rational and it's better to play it safe, right :-) In any case, the french loco team have its own respin, so it was more a "for natty" thing
[16:26] <didrocks> cjwatson: I just know now that the rationale is "propose a default on a screen you can override the option"
[16:26] <cjwatson> Riddell: not afaik ...
[16:33] <doko> ScottK, cjwatson: universe still open?
[16:33] <doko> about bug #656926
[16:33] <ubot4> Launchpad bug 656926 in openocd (Ubuntu) "ftbfs - on maverick fails on armel - sync openocd from debian unstable to universe (affects: 1) (heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/656926
[16:34] <cjwatson> just about
[16:34] <cjwatson> for a bit over 18 more hours
[16:34] <cjwatson> please don't do anything that will take past end of Saturday to build, though
[16:35]  * doko disables the testsuite in gcc-snapshot ...
[16:35] <doko> ;)
[16:56] <doko> hmm, there are now cairo-dock-plugins *and* cairo-dock-plug-ins in maverick ...
[16:58] <slangasek> cjwatson: oh good, it wasn't me then :-)
[17:04] <ScottK> doko: cairo-doc-plugins as no binaries so the duplication doesn't hurt anything.
[17:05] <doko> ScottK: why not remove it and blacklist?
[17:06] <doko> ScottK: didrocks will ask/clearify with upstream
[17:06] <ScottK> OK
[17:07] <ScottK> doko: cairo-dock-plug-ins was never in Debian.  Now that cairo-dock-plugins is in Debian we should probably follow Debian.
[17:10] <doko> cjwatson: I just see that libgpiv3 still depends on libhdf5-serial-1.6.6-0 | libhdf5-1.6.6-0 on armel, but it's not shown in NBS
[17:11] <cjwatson> which one of those packages should be in NBS?
[17:12] <doko> libhdf5-serial-1.6.6-0, there's only libhdf5-serial-1.8.4
[17:13] <doko> or maybe I did remove it?
[17:13] <cjwatson> it's already removed
[17:13] <cjwatson> so that would just be libgpiv3 being uninstallable on armel, presumably?
[17:13] <cjwatson> there's no uninstallability report for universe because it takes too long to run :(
[17:13] <doko> yes, currently preparing a no change upload
[17:14] <didrocks> doko: I think the upstream package doesn't agree with the debian maintainer or something like that, I'll try to clarify the situation with them
[17:14] <doko> fun ...
[17:16] <doko> cjwatson: would it be possible to run it manually once a few weeks before release?
[17:19] <cjwatson> doko: I'm not sure.  The last time I tried to run it I got bored after six hours, so I don't actually know how long it would take
[17:29] <ScottK> doko: Will leaving libgpiv in queue for a while block any further work of yours?
[17:29] <doko> ScottK: if you can give back pygpiv later, no
[17:30] <doko> I'll be away soon
[17:32] <ScottK> I'll go ahead and accept it then.
[17:32] <jdstrand> skaet: is there anything more I need to do with bug #656173 in terms of making sure it gets a release note?
[17:32] <ubot4> Launchpad bug 656173 in libvirt (Ubuntu) (and 1 other project) "libvirt no longer probes chained backing stores (affects: 1) (heat: 8)" [Undecided,Won't fix] https://launchpad.net/bugs/656173
[17:33] <jdstrand> (I just updated the bug)
[17:33] <ScottK> (that way I'm not required to remember one more thing for later)
[17:34] <jdstrand> skaet: hi btw :)
[17:59] <cjwatson> hm, kubuntu oem breaks
[18:00] <cjwatson> I think we'll need to fix that in an SRU
[18:00] <cjwatson> (this is different from ara's report, which I couldn't reproduce)
[18:00] <cjwatson> oh, wait - I bet this is only if you have no net access
[18:01] <cjwatson> ... no
[18:01] <ScottK> Doesn't oem need to work on the ISO?
[18:02] <cjwatson> no, because it's typically used by OEMs who are free to apply updates
[18:02] <cjwatson> it's obviously very nice if it does but it's not entirely critical
[18:02] <ScottK> Right.  OK.
[18:03] <cjwatson> http://paste.ubuntu.com/508934/ <- patch
[18:03] <ScottK> Oops.
[19:25] <kees> I'd like to upload a fix for bug 632206. it seems only ubuntustudio ships anything from the wine1.2 package. is this okay to upload?
[19:25] <ubot4> Launchpad bug 632206 in wine1.2 (Ubuntu) "Wine (& Crossover) cannot activate Securom modules after upgrading to Maverick (heat: 6)" [Medium,Triaged] https://launchpad.net/bugs/632206
[19:26] <ScottK> kees: I think we're in zero day SRU territory for Ubuntu Studio.
[19:26] <kees> ScottK: as in, it's okay to upload wine1.2 now, or that I should wait?
[19:26] <ScottK> kees: You can upload it to -proposed now.
[19:27] <kees> okay, I will rebuild for -proposed. thanks!
[20:04] <kees> ScottK: okay, it's in proposed. what's the 0-day SRU procedure? (obviously no 7-day delay...)
[20:23] <kees> ScottK: oh, and it seems that Yokozar may have another upload for a full micro release bump. ah, well, either will fix the issue.
[21:13] <slangasek> ^^ apologies for xdeb, this is very late in the coming but it's a needed bugfix to make one of the core features of xdeb introduced this cycle usable for non-trivial cases.  So if someone could review (and hopefully approve) that last minute universe package, I would be grateful
[21:14] <slangasek> ScottK: ^^ you may be the only one around at this hour?
[21:29] <pitti> slangasek: looking
[21:29] <slangasek> pitti: thanks!
[21:29]  * pitti boggles at the debdiff
[21:31] <pitti> slangasek: do you build these sources on linaro, somewhere that doesn't add X-Launchpad-Bugs-Fixed:?
[21:31] <slangasek> pitti: Linaro would add it; I built on Ubuntu; I think the missing X-Launchpad-Bugs-Fixed: is because of the lack of whitespace after the "LP:"
[21:31] <pitti> ok, so launchpad's debdiff isn't lying, the changelog really is that strange
[21:31] <pitti> ah
[21:32] <slangasek> I wasn't sure if that was going to be an issue and didn't check the .changes before upload
[21:32] <pitti> slangasek: just asking because recently I found several uploads in SRUs which didn't have it
[21:32] <pitti> slangasek: we can just close it manually, no big deal; I just wondered if that was due to a different lsb_release or so
[21:32] <slangasek> not in this case
[21:32] <slangasek> I have from time to time been known to accidentally build my source packages in Debian instead of Ubuntu, but not this time :)
[21:34] <pitti> slangasek: in the aptutils.py there might be a missing "if options.debug:", FYI
[21:35] <slangasek> pitti: I know that message is being printed out in non-debug mode, and didn't consider it a problem
[21:35] <slangasek> (it's not my code, or I'd be a bit more decisive with my answer)
[21:37] <pitti> 'k, accepted
[21:37] <slangasek> thanks!
[21:37] <pitti> ah, my wife returs home, which means -> good night!
[21:37] <slangasek> 'night :)
[21:37] <pitti> will get online tomorrow morning, in case we need more help
[21:37]  * slangasek goes back to evil hacks to allow cross-bootstrapping under qemu-arm-static
[21:38] <slangasek> incidentally, there are two uploads in the queue, dkms and edubuntu-artwork, that obviously imply respins... anyone know if those are meant to be accepted/rejected?
[21:45] <ara> night pitti!
[23:39] <ScottK> slangasek or cjwatson: I've been leaving two Universe packages in the queue in case you need to stimulate a publisher run.  I've been ~offline most of the day, so don't have any state about where we are WRT potential respins.  Please let me know when you think we're past that so I can go ahead and accept them.
[23:40] <slangasek> ScottK: I think you should go ahead and accept them; there shouldn't be any more seed/task changes now
[23:40] <ScottK> slangasek: Thanks.  Will do.
[23:41] <ScottK> Done.
[23:52] <ScottK> slangasek: I think we should also get rid of the release pocket version of edubuntu-artwork in queue and assume it's the -proposed one that will get used.
[23:52] <ScottK> Queue is all -proposed now.