[00:10] <doko_> slangasek: please consider llvm/clang before the final. basically disabling --with-oprofile
[01:40] <kees> ScottK: okay, a refresh of the selinux refpolicy thanks to TreSys (and additional fixes for the upstart bits) have been uploaded in "refpolicy-ubuntu" and "selinux".  tests out well with vastly reduced warnings in selinux mode.  regression potential is low, since it doesn't actually work very well without this upload.  ;)
[01:42] <kees> ScottK: LP: #568744 for reference
[01:51] <ScottK> kees: Accepted.
[01:52] <kees> ScottK: okay, thanks.  I'm still working on refpolicy-ubuntu; LP surprise-rejected it.  not sure why
[01:52] <ScottK> Because it can ....
[01:52] <ScottK> OK
[01:53] <kees> it's a src-format-3 package, so I assume I did something wrong.  though local builds are fine.
[05:54] <lamont> you have got to be kidding.  is oo.o going to finish ?  only time will tell.
[05:55] <lamont> but that 4 hour timeout idea?  not a win
[05:56] <lamont> given that the dpkg-deb run started _8_ hours of output-free-lzma HELL ago
[06:07] <slangasek> yeesh
[06:08] <lamont> slangasek: what if we didn't lzma oo.o?
[06:09] <lamont> buildd   27090 10.5 58.4 381060 279672 ?       D    Apr22  52:55      |                           \_ lzma -9c
[06:09] <lamont> only need another 102MB of ram or so
[06:10] <lamont> so wait. 8 hours runtime, 53 minutes of CPU...  my brain hurts now
[06:10] <lamont> swaptastic
[06:10] <slangasek> lamont: valid on armel since it's not on ISOs... can't do it for i386/amd64
[06:10] <lamont> 163MB of swap used
[06:11] <lamont> if we're doing another upload and we want it to finish before release, we probably want to turn of lzma for armel
[06:11] <lamont> as in -ubuntu4, which is already pending
[06:11] <lamont> anyway, faceplanting with some decorum before I do it without.
[06:11] <lamont> g'night
[07:25] <ttx> Good morning
[07:28] <pitti> Good morning
[07:29] <pitti> urgh, OO.o armel build still not finished, but looking good now
[07:29] <pitti> (purging chroot)
[07:29] <pitti> was a good time to wake up :)
[07:32] <pitti> yay, it finished!
[07:32] <pitti> asac, ogra ^
[07:36] <ajmitch> morning pitti :)
[07:36] <slangasek> ScottK, pitti: I'm not comfortable with that nautilus-share change, no; changing the default sharing ACL to allow the owner remote write access is not a clear bugfix, another option is changing the *description* of the option to say "remote users" instead of "other users"
[07:37] <pitti> hi ajmitch
[07:41]  * ajmitch obviously needs a faster computer & better cooling
[07:42] <ogra> pitti, yeah, 36h+ fpr OO.o on armel
[07:42] <ogra> *for
[07:42] <ajmitch> *ouch*
[07:42] <pitti> however, it seems that someone rejected the latest OO.o from the queue again, so I can't accept it
[07:42] <pitti> waiting for mvo, I guess
[07:42] <ogra> with 10.10 we'll get faster buildds (i think)
[07:42]  * ajmitch has a perl upload to put in the queue (don't hurt me)
[07:42] <ogra> pitti, i think it timed out from the queue
[07:43] <pitti> the queue doesn't time out
[07:43] <ogra> oh, k
[07:43] <ogra> i thought i heard scott say something like that
[07:44] <slangasek> ScottK: I think sparc being behind will influence what I'm willing to accept or not, but shouldn't be a blocker outright
[07:46] <pitti> ah, mvo mailed about it
[07:49] <slangasek> lool: apt-listchanges isn't used by default on Ubuntu; rejecting, you can always clean up the noise in SRU if you think that's necessary and still benefit most users
[07:51] <pitti> slangasek: quick heads up: the xorg-server glx rollback got tremendous testing feedback on https://wiki.ubuntu.com/X/Testing/GEMLeak, so I'd really like to see this in final; but the current  upload fixes another bug which I'm not sure about, so I didn't accept it yet; I pinged bryce and will discuss first
[07:55]  * pitti plays langpack accept whack-a-mole
[07:56] <pitti> I hope I got them early enough for queuebot to not freak out
[08:00] <ogra> hmm
[08:01] <ogra> i cant nominate a bug for lucid anymore
[08:01] <ogra> is that on purpose or did my LP account break ?
[08:01] <pitti> certainly not on purpose
[08:02] <ogra> well, clicking the nominate link doesnt list lucid
[08:02] <ogra> https://bugs.edge.launchpad.net/ubuntu/+source/netbook-meta/+bug/568736
[08:02] <ogra> lol
[08:02] <ogra> i'm blind, persia already nominated it
[08:02]  * ogra clicks approve
[08:03] <ajmitch> yay, package almost finished building
[08:11] <ajmitch> fix from debian for bug 568670 uploaded to the queue
[08:18] <fabrice_sp> Hi. Is this sync acceptable? (https://bugs.launchpad.net/ubuntu/+source/gorm.app/+bug/568619) It fixes a FTBFS and make 2 packages installables
[08:21] <pitti> argh, sorry; I was too late in this round
[08:21] <ajmitch> pitti: your accept whack-a-mole wasn't quite quick enough
[08:22] <pitti> ok, I cleaned up components-mismatches now; AFAICS, the only real thing left is mod-wsgi
[08:23] <pitti> oh, and gnugo/kigo
[08:31] <pitti> thanks ajmitch
[08:37] <slangasek> pitti: GEMLeak - did lool follow through on his CPU usage regression?  I agree it seems we should take that for final, anyway
[08:37] <slangasek> pitti: OOo was rejected per mvo's mail
[08:37] <pitti> slangasek: yes, it was determined to be unrelated to the update
[08:37] <slangasek> pitti: ok, good
[09:06]  * slangasek grunts sourly at the need for a perl upload
[09:07] <slangasek> my first reaction reading that bug wasn't "we should accept perl", it was "we should remove safe-rm from the archive"...
[09:07] <ajmitch> slangasek: sorry
[09:07] <ajmitch> but from what I read, removing safe-rm wouldn't have fixed it
[09:07] <slangasek> true
[09:08] <slangasek> OTOH, do people actually install safe-rm?
[09:08] <ajmitch> it was the safe-rm debian maintainer who filed the bug & poked me about it
[09:13] <ogra> slangasek, bug 563618 has a branch linked now for review
[09:13] <slangasek> ogra: ack
[09:16] <lool> pitti: FTR, couldn't reproduce the Xorg CPU consumption since; perhaps it was just bad timing that these two things happened the same day
[09:16] <ogra> slangasek, and on a sidenote, omap netbook installs fine now (beyond a bug that it doesnt properly reboot at the end sitting at plymouth but the board has a reset button :) )
[09:16] <slangasek> ogra: ok, great :)
[09:16] <ogra> oh, geeez !
[09:17] <ogra> it *does* reboot if i remove the SD
[09:17] <ogra> tsk
[09:17] <ogra> how could i know it actually *means* what it writes on the screen
[09:18] <slangasek> anyone know offhand why kdebase-workspace-bin is uninstallable on sparc?
[09:19]  * slangasek is failing to perceive the dependency order on http://people.canonical.com/~ubuntu-archive/testing-ports/lucid_probs.html
[09:29] <ogra_beagle> yay
[09:45] <asac> pitti: nice
[09:46] <asac> slangasek: you consider seed change intrusive/risky?
[09:46] <slangasek> asac: post-RC, for a low-priority bug? Yes.
[09:46] <slangasek> especially when you're *un*seeding things
[09:46] <slangasek> because that may uncover bugs caused by missing dependencies
[09:47] <asac> slangasek: yeah. was an oversight before. too bad.
[09:47] <asac> evolution-indicator might have given us a few more M  more ram ;) ... but ok.
[09:49] <slangasek> yep, would've been nice, but not the week before release
[09:50] <kees> ScottK: got another universe one for you... rng-tools in TPM mode wasn't starting at system boot, making that mode rather non-functional.  this upload fixes it.
[10:08] <ttx> slangasek: given the buildd situation, am I right in assuming we should postpone everything that can be done as SRU to lucid-updates, to make room for things that /need/ to happen pre-release ?
[10:08] <ttx> (except universe fixes that may run after candidate generation ?)
[10:08] <slangasek> ttx: "buildd situation" - are you referring to something other than the queue of langpacks?
[10:09] <ttx> no, the queue of langpack :)
[10:09] <slangasek> ttx: but yes, everything that can be done as SRU should be pushed to lucid-proposed instead
[10:09] <pitti> ttx: langpacks are quick, and don't block other builds (they have a low build scoree)
[10:09] <pitti> (just FTR)
[10:09] <slangasek> pitti: OTOH, we absolutely have to get the langpacks built before Monday :)
[10:09] <ttx> pitti: right, but they still need to complete ;)
[10:09] <ttx> heh
[10:10] <pitti> right, was just saying that they don't completely block the lucid final queue at this point
[10:10]  * pitti eyes the ubiquity upload in the queue
[10:10] <pitti> oh, and we got another i386 buildd, nice!
[10:10] <slangasek> pitti: was it you that accepted openoffice.org-hyphenation for bug #568514, btw?
[10:11] <pitti> slangasek: no, I didn't touch it
[10:11] <slangasek> ok
[10:11] <pitti> I saw it in the queue yesterday night, but this morning both oo.o and -hyphenation were gone
[10:11] <slangasek> whoever did, overlooked another part to the bug
[10:12] <slangasek> I'll upload the fix shortly; no sense waiting for ccheney to be awake again
[10:13] <ttx> slangasek: ok, FTR, at this point we (server) don't have anything ready that would *need* to go in before release.
[10:13] <ttx> emphasis being on /ready/, as we certainly have some annoying bugs.
[10:14] <slangasek> ttx: the cloud-init bugs, or other stuff?
[10:14] <ttx> slangasek: i'm updtaing the status page, just a sec
[10:15] <ttx> slangasek: https://wiki.ubuntu.com/ServerTeam/ReleaseStatus
[10:15] <ttx> see "under investigation"
[10:15] <ttx> At that point I don't see how any of those might make release, except maybe the olcAccess (openldap) one
[10:16] <ttx> the others we either don't have a solution yet for, or they are good SRU candidates
[10:16] <ttx> will sync with team on all those before the meeting today
[10:16] <ttx> (we are having a meeting today, right ?)
[10:17] <ttx> another candidate would be bug 533029 -- if any of you have time to review chuck's latest proposal. Though it sounds like very late to change that now.
[10:21] <slangasek> usr/share/hunspell/de_DE.aff                                text/hunspell-de-de,universe/text/myspell-de-de,universe/text/hunspell-de-de-frami,text/myspell-de-de-oldspell
[10:21] <slangasek> GAR
[10:22] <slangasek> ttx: yes, meeting today
[10:23] <ev> thanks for the quick approval on ubiqutiy
[10:27] <slangasek> seb128: hi!  which part of this openoffice.org-dictionaries change was the rationale for the post-freeze upload?  Just the French changes, right?
[10:27] <seb128> slangasek, hey, yes
[10:28] <seb128> slangasek, I pinged you about that saying if you wanted the debian update or if I should just fix the french .install
[10:28] <slangasek> seb128: ok; then I'm reverting the rest, because it's caused a buttload of file conflicts that we don't have time to sort out
[10:28] <seb128> slangasek, but I didn't read your reply if you replied
[10:28] <seb128> urg, sorry about that
[10:28] <slangasek> well, someone accepted it and it's broken :)
[10:29] <seb128> file conflict between what and what?
[10:29] <seb128> just curious
[10:29] <slangasek> and ccheney compounded the damage by uploading openoffice.org-hyphenation, dropping some of the conflicting files without setting Replaces/Conflicts - so I get to revert two packages, sigh
[10:29] <cjwatson> agh, why do people try to optimise away setting the correct fields
[10:29] <seb128> slangasek, the changes I cared about are to use the right names in openoffice.org-thesaurus-fr*
[10:29] <cjwatson> it never saves time in the long run
[10:30] <seb128> slangasek, ie th_fr to thes_fr
[10:30] <slangasek> $ for pkg in myspell-th hunspell-de-at-frami openoffice.org-hyphenation-de myspell-it myspell-en-gb hunspell-de-ch-frami myspell-en-us openoffice.org-thesaurus-fr hunspell-de-de-frami; do zgrep $pkg /home/lp_archive/ubuntu/dists/lucid/Contents-i386.gz |grep , ; done | awk '{ print $2 }' | sort -u
[10:30] <slangasek> text/hunspell-de-at,universe/text/myspell-de-at,universe/text/hunspell-de-at-frami
[10:30] <slangasek> text/hunspell-de-ch,universe/text/myspell-de-ch,universe/text/hunspell-de-ch-frami
[10:30] <slangasek> text/hunspell-de-de,universe/text/myspell-de-de,universe/text/hunspell-de-de-frami
[10:31] <slangasek> text/hunspell-de-de,universe/text/myspell-de-de,universe/text/hunspell-de-de-frami,text/myspell-de-de-oldspell
[10:31] <slangasek> text/hunspell-en-us,universe/text/myspell-en-us
[10:31] <slangasek> seb128: ^^ those are the conflicts in lucid with the packages whose install files were touched in this upload, according to Contents
[10:31] <slangasek> cjwatson: if by "correct fields" you mean "Conflicts/Replaces", I don't think optimization was the problem :)
[10:32] <seb128> slangasek, hum ok, again sorry about that I sort of trusted debian on the change and I didn't notice the issue there since I don't have -de installed
[10:32] <slangasek> though it's possible those packages already have conflicts with one another; lessee
[10:35] <slangasek> ok, the remaining file conflicts are actually all declared
[10:36] <slangasek> the only problem conflicts were the ones between openoffice.org-hyphenation-de and openoffice.org-hyphenation, which were fixed before the last Contents generation
[10:36] <slangasek> so the easiest way out is forward
[10:36] <slangasek> seb128: the actual bug for this is bug #568514
[10:38] <slangasek> seb128: so the reason the Debian maintainer didn't handle it is openoffice.org-hyphenation is Ubuntu-only
[10:38] <seb128> oh, makes sense now
[10:42] <seb128> slangasek, sorry again about those
[10:43] <pitti> slangasek: ok for me to sync the new tzdata 2010i into lucid?
[10:43] <slangasek> 'sok, we'll get it fixed :)
[10:43]  * pitti thought that the DST change crazy period was over, but apparently not so
[10:43] <slangasek> pitti: yes, go ahead
[10:44] <pitti> (three DST rule changes, no structural differences)
[10:44] <seb128> pitti, can we sync shotwell too?
[10:44] <pitti> seb128: no idea, haven't looked at it; is there a bug/changelog/etc.?
[10:44] <seb128> pitti, http://packages.qa.debian.org/s/shotwell/news/20100420T220717Z.html
[10:44] <seb128> pitti, basically nmu to build with vala 0.8
[10:45] <seb128> which we have in lucid
[10:45] <pitti> to fix FTBFS?
[10:45] <pitti> yes, that seems fine
[10:45] <seb128> pitti, can you do it if you are doing syncs? thanks
[10:45] <pitti> seb128: yep, doing
[10:56] <slangasek> pitti, cjwatson: base-files, openoffice.org-dictionaries uploaded; please review
[11:07] <pitti> base-files looks fine, accepted
[11:07] <pitti> slangasek: oh heck, I need to update postgresql-common for this ^
[11:08] <slangasek> for base-files?
[11:08] <pitti> ah, no
[11:08] <pitti> it checks lsb_release -rs
[11:08] <pitti> which is still 10.04, not "LTS"
[11:09] <slangasek> right, things checking that field is exactly why I didn't put LTS in it :-)
[11:12] <cjwatson> review> you lot are too fast for me
[11:19] <cjwatson> looks like somebody rejected landscape-client last night, but it's in the queue again.  What's the background on that?
[11:24] <slangasek> wasn't me
[11:25] <cjwatson> james_w: checksecurity: in the past, we've had the odd bug due to it being impossible to set I/O priorities in weird corner cases such as some virtualisation containers and the like.  Would it make sense to add the -t option, by way of being conservative?  That would require a dependency on util-linux (>= 2.15~rc1-1)
[11:25] <pitti> langscape> me neither
[11:26] <pitti> cjwatson: hm, it says it's in the queue for 20 hours?
[11:26] <pitti>  i. e. doesn't look like "rejected"?
[11:27] <cjwatson> 16:04 -queuebot:#ubuntu-release- New package: landscape-client (main) [1.5.0-0ubuntu0.10.04.0 → 1.5.0.1-0ubuntu0.10.04.0]
[11:27] <cjwatson> 22:48 -queuebot:#ubuntu-release- Removed package: landscape-client
[11:27] <cjwatson> 22:52 -queuebot:#ubuntu-release- New package: landscape-client (main) [1.5.0-0ubuntu0.10.04.0 → 1.5.0.1-0ubuntu0.10.04.0]
[11:27] <cjwatson> which looks like "somebody discussed some flaw with the uploader, then rejected so that they could reupload"
[11:28] <cjwatson> so presumably only whoever had that discussion can effectively review it
[11:28] <slangasek> I don't see anything in rejected, I think that was just bot flapping
[11:28]  * cjwatson once again wishes for better logging
[11:28] <cjwatson> oh, I suppose it could be
[11:28] <cjwatson> it's odd for it to explicitly say "Removed" unless it really is, that's all
[11:29] <cjwatson> repeated "New" is a different matter
[11:38] <slangasek> stgraber, highvoltage: how are we on final edubuntu-artwork?
[11:41] <cjwatson> I haven't done the CD stuff yet, but I have the material from highvoltage
[11:42] <slangasek> AIUI we also still need an upload of the package
[11:52]  * ScottK notes OOo built on armel and congradulates lamont on the power of his special magic.
[11:53] <james_w> cjwatson: if you think that's smart then I can make the change
[11:53] <cjwatson> if you could, yes please
[11:53] <cjwatson> just want to play safe at this point
[11:57] <lamont> ScottK: somewhere between 8.5 and 9.5 hours into dpkg-deb, we got to pkgstriptranslations and output resumed.
[11:58] <slangasek> ScottK, cjwatson, pitti: wrt OOo, I think lamont is right that we should fix the package to not use lzma on armel before accepting a new one; the tradeoff of lzma just doesn't make sense on armel, so long as we don't include it on release images
[11:58] <ogra> ++
[11:59] <slangasek> I don't think a bug has been opened for this yet, though
[11:59] <lamont> slangasek: thank you.
[11:59] <lamont> and no, I didn't file a bug
[12:00] <james_w> ^ rejected
[12:00] <ScottK> slangasek: IIRC it's still on KNR armel, but that image isn't size constrained so no lzma is fine.
[12:10] <cjwatson> slangasek: yeah, I agree
[12:17] <pitti> slangasek: OO.o> ack
[12:18]  * pitti reviewes partman-*
[12:22] <slangasek> cjwatson: bug #530027 still not deferred, does that mean it needs fixing before release?
[12:29] <slangasek> ScottK, Riddell: is anyone working on bug #551456?
[12:30] <slangasek> (if not, should probably be deferred to SRU now)
[12:32] <Riddell> slangasek: not that I know of, I'll ping Jonathan Thomas to check
[12:32] <Riddell> slangasek: did you reject the kdeplasma-addons upload this week?
[12:32] <slangasek> Riddell: yes
[12:33] <slangasek> https://bugs.launchpad.net/ubuntu/+source/kdeplasma-addons/+bug/566127
[12:33] <Riddell> oh aye
[12:34] <lamont> slangasek: and I'm assuming someone else is doing the oo.o mod for armel
[12:34] <slangasek> lamont: sure?
[12:34] <slangasek> I think it's "whoever gets to it"
[12:34] <lamont> as in I'm not preparing an upload
[12:35] <slangasek> lamont: it's diff.gz only, really lightweight ;)
[12:37] <lamont> for oo.o, yeah.  my dayjob tasks are interferring with my dev stuff
[12:38] <slangasek> ^^ that one's mine, if someone could review
[12:38]  * cjwatson looks
[12:39] <slangasek> cjwatson: you already fixed the other half of that bug, so if you don't like it, don't hesitate to reject
[12:40] <cjwatson> no, I'm fine with it, I see many more risks than benefits in applying it on upgrade
[12:41] <cjwatson> accepted
[12:41] <slangasek> ok, thanks
[12:41] <cjwatson> err, wait!
[12:41] <cjwatson> shouldn't that be --no-start?
[12:41] <cjwatson> sorry, only spotted this after accept
[12:42] <cjwatson> possibly -r as well, I forget the exact semantics
[12:42] <cjwatson> but surely we *do* want to modify the postinst/postrm/prerm scripts
[12:42] <cjwatson> to call update-rc.d
[12:44] <slangasek> ah, quite
[12:44] <slangasek> sorry, will fix
[12:57] <lamont> https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/568940
[12:57] <lamont> and targeted to 10.04
[13:00] <doko_> lamont: can't this wait until the first update?
[13:01] <slangasek> doko_: dropping lzma?  not if we want the *pending* update to build on armel in a sane amount of time
[13:01] <doko_> ahh, wasn't aware of *another* update
[13:02] <mvo> another ooo update?!?
[13:02] <mvo> then please, please merge my changes in as well
[13:02] <doko_> slangasek: do you do that, or should I?
[13:02] <slangasek> mvo: weren't we waiting for *you* to send us one? :)
[13:03] <doko_> mvo: even better, take over! =)
[13:03] <mvo> and I am waiting on my machine to finish building it, even debuild -b -nc takes ages
[13:03] <slangasek> mvo: the "pending update" I meant was the one with your changes - we should get the lzma change added on to that
[13:03] <mvo> yeah
[13:03] <mvo> cool
[13:04] <mvo> is it just "use_lzma_compress=n" ?
[13:04] <mvo> in debian/rules ?
[13:04] <doko_> I'll look
[13:04] <mvo> thanks doko_
[13:05] <mvo> so my plan is/was to upload to my ppa first (build etc ~4h), run a battery of upgrade tests against it and then upload to the main archive
[13:05] <pitti> mvo: but on armel only
[13:05] <mvo> the upgrade stuff is automatic and relatively fast, I just need to review the logs
[13:05] <pitti> we certainly want to keep lzma for i386/amd64
[13:06] <mvo> aha, ok
[13:06] <slangasek> Riddell: there's an unanswered question for you from ev on bug #567243
[13:06] <ogra> slangasek, arm enhanced the hack on bug 563618 (branch with tested changes linked)
[13:06] <cjwatson> slangasek: I still don't get this - -r alone only prevents the prerm running init.d stop
[13:06] <ogra> (yes, i know i'm annoying, sorry for that)
[13:07] <cjwatson> looks like we want --no-start (which includes -r, looking at dh_installinit)
[13:07] <cjwatson> with -r, the init script will still be run on postinst configure
[13:07] <slangasek> cjwatson: mm, yes
[13:07] <slangasek> cjwatson: reject, I'll reupload
[13:08] <cjwatson> done
[13:10] <slangasek> cjwatson: thanks for the scrutiny; I clearly don't have dh_installinit internalized as well as intended
[13:10] <Riddell> slangasek, ev: bug 567243 answered
[13:14] <slangasek> ogra: I'm afraid I'm going to have to take off again for a couple of hours; I'll be back for the release meeting, and will review the branch afterwards
[13:14] <pitti> slangasek: so, it seems that all the vpnc faff on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt is really just due to KDE failing to build on sparc
[13:14] <pitti> so I'm inclined to just ignore those
[13:14] <pitti> auctex is also just a glitch AFAICS
[13:15] <ogra> slangasek, ok, thanks
[13:15] <slangasek> pitti: I tried to give KDE a kick start on sparc, but I can't figure out why kdebase-workspace-bin is uninstallable there
[13:15] <pitti> right, same FTBFS reason like plasma-widget-networkmanagement
[13:16] <slangasek> pitti: and faure gives an unfriendly error instead of useful debugging output :/
[13:18] <slangasek> cjwatson: ^^ take 3
[13:20] <cjwatson> pitti: last I checked, auctex was ultimately a result of emacs23 failing to build on ia64
[13:20] <ogra> ScottK, do you have any beagleboard users in the kubuntu community ? if you have an armel build that was rolled after 22nd there might be value in knowing if kubuntu-netbook omap works ... (https://wiki.ubuntu.com/ARM/Beagle)
[13:20] <pitti> cjwatson: aah, thanks
[13:21] <pitti> cjwatson: given that c-m considers ports, it's in a surprisingly good shape :)
[13:26] <Riddell> ogra: not that I know of, our main testers are ncommander and gruemaster's son
[13:26] <ogra> ah, k
[13:50] <cjwatson> slangasek: ok, accepted now, thanks
[13:50] <highvoltage> slangasek: we received the new artwork yesterday \o/
[13:50] <highvoltage> slangasek: I made the changes and uploaded the new package
[13:51] <highvoltage> cjwatson: did you get my link yesterday with the new boot logos?
[13:55] <pitti> ScottK: TBH, clamav has so many changes that I don't have the guts to accept it; was that discussed before with someone else?
[13:56] <ScottK> pitti: slangasek was scared too.  All I can say is that this is based off the first revision the Debain maintainer was willing to upload to Volatile for Lenny users.
[13:56] <ScottK> I know there are a number of sub-par things in the current debconf handling and I think it's unlikely this will be worse.
[13:57] <ScottK> Based on the testing done with the Debian people and what I've reviewed  of the changes I think the risk of regression is low, but not non-existent.
[13:58] <pitti> ScottK: ok; since it doesn't seem realistic to verify correctness by eyeballing the debdiff, this should rather be tested extensively then
[13:58] <ScottK> pitti: Yes.  I think it has been tested fairly extensively in Debian already.
[13:59] <ScottK> The two DDs most active on their clamav team beat in it pretty hard and stared at it for several days before uploading.
[13:59] <ScottK> That's why it's coming so late.
[13:59] <pitti> ok, thanks
[14:01] <mvo> new OOo is uploaded, but please do not accept it just yet, I want to test the build from the PPA in a real upgrade secenario (I did test a local upgrade, but only ooo, not the full thing)
[14:01] <mvo> and let me know if you see anything odd in the diff (I looked at it and it looks fine, but more eyes will not hurt :)
[14:07] <cjwatson> highvoltage: I did, thanks, will process it today
[14:20] <highvoltage> cjwatson: and thank you!
[14:41] <pitti> ^ weirdest patch to remove scroll bars EVAR
[14:41] <pitti> (discussing in #u-desktop right now)
[14:48] <ttx> pitti: moin uploaded. I triplechecked by installing that package that following the existing instructions in Debian readme are sufficient to make it work.
[14:48] <ttx> so it works and is consistent with existing documentation.
[14:53] <cjwatson> highvoltage: committed and deployed; should be on the next CD
[15:01] <highvoltage> cjwatson: great! I'll test it with the next build
[15:03] <stgraber> slangasek: are we back to daily build until Tuesday or do we have to ask for a respin every time we want one ?
[15:05] <ogra> stgraber, manual
[15:05] <stgraber> ogra: ok, thanks
[15:05] <stgraber> ogra: how's ARM going btw ?
[15:06] <ogra> stgraber, see planet :)
[15:12] <lamont> slangasek: any reason to not retry oo.o on sparc?
[15:12] <lamont> other than  the "newer one coming" reason?
[15:13] <lamont> and I wonder how many more glib2.0-caused failures we have out there
[15:14] <highvoltage> oh right we probably want a respin of edubuntu when the artwork package hits the archive :)
[15:24] <stgraber> ogra: how's ARM going btw ?
[15:24] <ogra> stgraber, see planet :)
[16:00] <pitti> slangasek: for the record, alternates have tons of space, I'll add back some langpacks (there are none except -en right now)
[16:26] <ScottK> vlc is an interesting one as there are security fixes in there and I'm not confident at all we'll get them any other way than to accept the entire mess.
[16:32] <slangasek> lamont: OOo on sparc> new one's coming, and there's other stuff in the build queue on sparc?
[16:32] <slangasek> pitti: alternates> doh! thanks
[16:32] <lamont> slangasek: right.
[16:32] <lamont> IOW, no.
[16:33] <lamont> slangasek: I expect that there are other glib2.0-induced failures that we should throw back in for sparc
[16:33] <lamont> but nfc which ones
[16:33] <lamont> and my level of caring is completely academic
[16:34] <bdrung> ScottK: one security fix and 6 bug fixes
[16:35] <stgraber> slangasek: Can you trigger a rebuild of Edubuntu once 0.1.0-69 is in the archive ?
[16:35] <stgraber> edubuntu-artwork 0.1.0-69 that's
[16:35] <slangasek> stgraber: trigger set
[16:35] <stgraber> cool
[17:33] <slangasek> pitti: ok, I don't actually find the discussion of the extra xorg patch in my scrollback that I thought was there
[17:37] <slangasek> pitti: but the patch itself looks straightforward and important - did you have specific concerns with it?
[17:38] <seb128> slangasek, he was concerned about the other change in the upload I think
[17:38] <seb128> slangasek, he said there was 2 changes, the glx issue one + another one he was not sure if that was an intended change or an error
[17:52] <seb128> slangasek, the confusion was about the 0ubuntu6 entry
[17:52] <seb128> slangasek, it's not in the .changes and pitti was not sure it was meant to be in the upload or an error
[17:52] <seb128> slangasek, bryce confirmed it's targetted to lucid
[17:53] <seb128> slangasek, so feel free to accept the upload if you want
[17:53] <seb128> slangasek, when have time to review it ;-)
[18:00] <slangasek> seb128: great, thanks
[18:26] <slangasek> stgraber: got a build failure on edubuntu, probably due to langpacks
[18:28] <mvo> slangasek: the dapper->hardy->lucid with OOo from the PPA upgrade tests is successful, registering works, upgrade does no longer explodes. the karmic->lucid is still running though
[18:29] <slangasek> mvo: ok - you want me to wait for that test too before accepting
[18:29] <slangasek> ?
[18:29] <slangasek> stgraber: sure enough, there's the mail - langpacks
[18:30] <mvo> slangasek: it should be finishing in ~30 min or so, so I would say yes
[18:30] <mvo> slangasek: unless you think its too urgent to wait
[18:30] <slangasek> nope
[18:31] <mvo> ok, i let you know when its there
[18:35] <stgraber> doh, which one is broken this time ?
[18:36] <stgraber> slangasek: can't see the build failure on people.c.c/~ubuntu-archive and didn't receive a build fail mail, do you have a link to that ?
[18:43] <slangasek> stgraber: nope, sorry - the logs will be synced soon
[18:43] <slangasek> stgraber: it's not something you can fix anyway, the langpacks just need to finish building :)
[18:45] <slangasek> i.e., the build failure is simply due to mid-langpack-build skew, not a source bug that needs fixed
[18:51] <stgraber> slangasek: ok
[19:00] <slangasek> looks like langpacks are progressing at about 50/hr, so roughly 7 more hours to completion
[19:01] <ScottK> slangasek: Does that mean it's OK to accept some Universe stuff now (since 7 hours isn't so long) or would you rather I waited?
[19:02] <slangasek> doko, mvo: fwiw, it would've been more idiomatic to change the value of USE_LZMA_COMPRESS based on the architecture; especially since the DPKG_DEPENDS value is also redundant when we don't use lzma
[19:02] <slangasek> ScottK: will those universe packages land ahead of the langpacks in the queue?
[19:02] <ScottK> slangasek: They will.
[19:03] <slangasek> ScottK: would be nice if the langpack build didn't stretch out too much longer, if it goes too late I won't be able to get stgraber his edubuntu respin until I land in London
[19:03] <ScottK> OK.  I'll wait.
[19:03] <slangasek> ScottK: ok, thanks
[19:10] <slangasek> mvo: are we there yet? :)
[19:12] <ScottK> slangasek: Currently on Kubuntu dial up networking is broken due to a permissions issue.  It's an easy fix and it's in kdenetworking so it's not a multi-hour build.  Since no network could interfere with the ability to get update, can this go in or SRU?
[19:13] <slangasek> ScottK: yes, let's take it
[19:13] <ScottK> OK.  Thanks.
[19:28] <mvo> slangasek: the log looks good, components show as registered, upgrade almost finished, all looks well
[19:28] <mvo> slangasek: I think we have a winner!
[19:37] <mvo> slangasek: ok, OOo runs fine, still has evo as a datasource and the binfilters, logs look fine. I tested both hardy->lucid and karmic->lucid
[19:37] <mvo> slangasek: both work now when they before failed
[19:40] <slangasek> mvo: ok, accepted
[19:40] <slangasek> mvo: thanks for taking care of this!
[19:42] <ScottK> slangasek: kdenetwork was the dial up networking fix I mentioned.  I reviewed and accepted, so it's done.
[19:45] <slangasek> ScottK: ok, cool
[19:54] <mvo> slangasek: thank you! I'm happy that this is resolved now
[19:54]  * mvo sends the updated diff to debian
[19:54] <slangasek> so now everything upgrades perfectly, right? :-)
[19:55] <mvo> everything that I tested …
[19:55] <mvo> :)
[19:55] <slangasek> want to test mysql server?
[19:55] <slangasek> (hardy->lucid)
[19:55] <mvo> bä
[19:55] <slangasek> :-)
[19:56] <mvo> I think matthias pointed me to a new bug about it the other day
[20:02] <mvo> slangasek: I commited (and will test) a update-manager quirk, I don't think I will manage to debug the root cause tonight, but the quirk will ensure that it works when using u-m
[20:03] <slangasek> mvo: ah; what's the bug?
[20:06] <mvo> slangasek: I don't know yet, I think its something with the cluster package and the dependencies
[20:06] <slangasek> right, unsurprising - is there a bug number or log, though?
[20:06] <mvo> oh, yes
[20:06] <mvo> sorry
[20:06] <mvo> its bug #568606
[20:06] <slangasek> (I'm poking about this because mysql upgrade path is already in the release notes)
[20:06] <mvo> and the logs are good
[20:06] <slangasek> great, thansk
[20:07] <mvo> its trivial to add a quirks handler in u-m for it, I doubt it happens for all people, I don't see it in the server-tasks upgade profile (that is a server install with all tasks installed)
[20:08] <mvo> I test the quirks thing now (more out of paranoia, its just a config file entry) and if its fine I will upload a new u-m with it
[20:08] <mvo> will take ~45min or so
[20:09] <slangasek> ok
[20:20]  * mvo can reproduce the bug
[20:31] <mvo> slangasek: uploaded new version, fixes this bug and a upgrade failure with gobuntu (pretty trivial and obvious)
[21:05] <ScottK> Kubuntu powerpc images finally got a thumbs up for at least Live CD testing.
[21:05] <ScottK> (the RC ones)
[21:35] <ScottK> slangasek: FYI Bug #565294.  I don't think there's any imminent release team action required, but it bears watching.
[21:35] <slangasek> alright
[21:38] <ScottK> The only possible pre-release solution would be to remove language-pack-kde-lt  and upload the KDE language pack to Universe where it won't get stripped.
[21:39] <ScottK> I'm ~sure we don't want to do that.
[21:54] <cjwatson> could somebody review hw-detect?  I'd like to upload a more-or-less-final debian-installer tonight, and hw-detect is in the initrd
[22:04] <ScottK> ^^^ was a rejection, fyi.  It will be back.
[22:20] <cjwatson> (review of partman-iscsi wouldn't hurt either but less urgent)
[22:22] <slangasek> cjwatson: grabbing
[22:23] <cjwatson> thanks
[22:24] <slangasek> cjwatson: no bug ref in the changelog - why is backup support significant here?
[22:31] <pitti> slangasek: ok, so xorg sorted out? great
[22:31] <slangasek> pitti: yeppers
[22:32] <pitti> slangasek, cjwatson: so I think we can consider http://people.canonical.com/~ubuntu-archive/component-mismatches.txt as "empty and done" now, right?
[22:32] <pitti> unless someone is eager to untangle the KDE mess on sparc
[22:33] <slangasek> it resisted me; as a last resort I was going to untangle it with a binary removal
[22:34] <ScottK> No objections here to binary removal on sparc here.
[22:55] <slangasek> ogra: ok, patch for bug #563618 reviewed and my lunch is staying down, so I guess it's ok for upload
[23:03] <slangasek> cjwatson: partman-iscsi accepted - still looking for clarification on hw-detect before accepting
[23:06] <slangasek> oh, har
[23:06] <slangasek> W: initramfs-tools: script-not-executable ./usr/share/initramfs-tools/scripts/panic/keymap
[23:06] <slangasek> no wonder that wasn't working for me
[23:08] <slangasek> ScottK, cjwatson: ^^ initramfs-tools needs an upload anyway for 563618, mind if I fix the perms on that script in the process?
[23:08]  * ScottK defers to cjwatson.
[23:08] <slangasek> ok
[23:08] <slangasek> cjwatson: and btw, same bug exists in console-setup's panic script :/
[23:09] <bdrung> will vlc be accepted?
[23:10] <ScottK> bdrung: We aren't doing any Universe accepts until after the language pack run is done.
[23:10] <ScottK> It hasn't been reviewed yet, AFAIK.
[23:10] <bdrung> aha
[23:11] <cjwatson> slangasek: ok, the reason I added backup support there was while investigating the various iscsi UI bugs ara reported, and realising that backup behaviour was inconsistent - it depended on whether you'd seen an error message yet or not.  (furthermore, the lack of backup support on the hw-detect path was getting in my way when testing)
[23:12] <cjwatson> it's probably borderline, I won't fret too badly if you say no, it was just a "god, this UI actually kind of sucks"
[23:13] <cjwatson> slangasek: perms OK by me - want me to upload console-setup to fix its perms too?
[23:14] <cjwatson> (that's strictly an error path so I don't see how fixing it in initramfs-tools while you're there could cause a problem)
[23:15] <slangasek> cjwatson: ok, hw-detect in; uploading initramfs-tools now; console-setup> actually, I dunno, if console-setup's code is broken could that cause a regression in users' ability to break into the initramfs for recovery?
[23:15]  * slangasek looks at what the script does
[23:16] <cjwatson> if it hung, I guess it could
[23:16] <slangasek> looks safe enough
[23:17] <slangasek> hmm
[23:17] <slangasek> is it likely to hang?
[23:17] <slangasek> there seems to be some duplication between keymap and console_setup, huh
[23:17] <cjwatson> I shouldn't think so
[23:17] <cjwatson> it's basically the same code as in initramfs-top
[23:17] <cjwatson> in fact
[23:17] <cjwatson>         sed -e "/^OPTION=/d" \
[23:17] <cjwatson>                 < debian/console-setup.initramfs-top \
[23:17] <cjwatson>                 > debian/console-setup/usr/share/initramfs-tools/scripts/panic/console_setup
[23:18] <cjwatson> so if it breaks, then an initramfs with the framebuffer option would break in the same way
[23:18] <slangasek> yeah, one difference I see is that top runs before plymouth, panic runs after
[23:19] <cjwatson> keymap looks like a superseded strict subset of console_setup
[23:19] <slangasek> with a different path to the keymap
[23:19] <cjwatson> which doesn't exist in my initramfs
[23:20]  * slangasek nods
[23:20] <cjwatson> I think the kbd_mode call is all it actually does in practice
[23:20] <cjwatson> but probably best resist cleaning it up right now
[23:20] <slangasek> ok, so I'll not bother fixing those perms on initramfs-tools upload, since it wouldn't actually help
[23:21] <slangasek> and console-setup... if you want to prep it, I'll put it through its paces before accepting, since I know my system's a good test case
[23:22] <cjwatson> you want a binary?
[23:22] <slangasek> nah, can grab from the queue
[23:22] <slangasek> (if that's ok)
[23:22] <cjwatson> or you could just 'chmod +x /usr/share/initramfs-tools/scripts/panic/console_setup'
[23:22] <slangasek> true
[23:22] <cjwatson> and update-initramfs -u
[23:23] <cjwatson> since that's all I'm going to do
[23:24] <slangasek> cjwatson: should the last change mentioned in the partman-iscsi changelog have fixed bug #568312? (no bugref)
[23:25] <cjwatson> I'm not sure
[23:25] <cjwatson> it fixed one problem I encountered while attacking that bug
[23:25] <cjwatson> but I ran into problems described in a comment on that bug, which I'm not sure are representative of real-world situations since it's ages since I had this set up properly
[23:25] <stgraber> slangasek: we just found a small issue in edubuntu-artwork with our plymouth theme, so another upload of that one is to be expected in the next hour or so to fix it (changing font color on the cryptsetup prompt so it's readable).
[23:26] <cjwatson> I decided that I wasn't making any more progress and would be best off drawing a line for now
[23:26] <slangasek> stgraber: ok
[23:27] <slangasek> initramfs-tools uploaded
[23:27] <cjwatson> console-setup on its way
[23:38] <ScottK> slangasek: I'm heading out for a while.  Once the language packs are sufficiently drained, I think mythtv and xchat would be priorities for Universe.  Both looked sensible to me, but more review never hurts.
[23:39] <slangasek> ScottK: sounds good
[23:42] <ScottK> quickly is ~32K lines of almost all po/pot file changes.
[23:44] <ScottK> vlc would be a priority too.  I wonder if anyone told kees he'd volunteered to review it.
[23:48]  * kees knows, but is slow