[00:10] slangasek: please consider llvm/clang before the final. basically disabling --with-oprofile [01:40] 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] ScottK: LP: #568744 for reference [01:42] Launchpad bug 568744 in selinux "Lucid SELinux Policy Update" [Medium,Fix committed] https://launchpad.net/bugs/568744 [01:51] kees: Accepted. [01:52] ScottK: okay, thanks. I'm still working on refpolicy-ubuntu; LP surprise-rejected it. not sure why [01:52] Because it can .... [01:52] OK [01:53] it's a src-format-3 package, so I assume I did something wrong. though local builds are fine. [05:54] you have got to be kidding. is oo.o going to finish ? only time will tell. [05:55] but that 4 hour timeout idea? not a win [05:56] given that the dpkg-deb run started _8_ hours of output-free-lzma HELL ago [06:07] yeesh [06:08] slangasek: what if we didn't lzma oo.o? [06:09] buildd 27090 10.5 58.4 381060 279672 ? D Apr22 52:55 | \_ lzma -9c [06:09] only need another 102MB of ram or so [06:10] so wait. 8 hours runtime, 53 minutes of CPU... my brain hurts now [06:10] swaptastic [06:10] lamont: valid on armel since it's not on ISOs... can't do it for i386/amd64 [06:10] 163MB of swap used [06:11] 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] as in -ubuntu4, which is already pending [06:11] anyway, faceplanting with some decorum before I do it without. [06:11] g'night [07:25] Good morning [07:28] Good morning [07:29] urgh, OO.o armel build still not finished, but looking good now [07:29] (purging chroot) [07:29] was a good time to wake up :) [07:32] yay, it finished! [07:32] asac, ogra ^ [07:36] morning pitti :) [07:36] 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] hi ajmitch [07:41] * ajmitch obviously needs a faster computer & better cooling [07:42] pitti, yeah, 36h+ fpr OO.o on armel [07:42] *for [07:42] *ouch* [07:42] however, it seems that someone rejected the latest OO.o from the queue again, so I can't accept it [07:42] waiting for mvo, I guess [07:42] 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] pitti, i think it timed out from the queue [07:43] the queue doesn't time out [07:43] oh, k [07:43] i thought i heard scott say something like that [07:44] 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] ah, mvo mailed about it [07:49] 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] 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] I hope I got them early enough for queuebot to not freak out [08:00] hmm [08:01] i cant nominate a bug for lucid anymore [08:01] is that on purpose or did my LP account break ? [08:01] certainly not on purpose [08:02] well, clicking the nominate link doesnt list lucid [08:02] https://bugs.edge.launchpad.net/ubuntu/+source/netbook-meta/+bug/568736 [08:02] Ubuntu bug 568736 in netbook-meta "Having Evolution installed along with Desktop-Email is pointlessly redundant" [High,Triaged] [08:02] lol [08:02] i'm blind, persia already nominated it [08:02] * ogra clicks approve [08:03] yay, package almost finished building [08:11] fix from debian for bug 568670 uploaded to the queue [08:11] Launchpad bug 568670 in perl "upgrade to lucid breaks completely when safe-rm is installed" [High,Confirmed] https://launchpad.net/bugs/568670 [08:18] 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:18] Ubuntu bug 568619 in gorm.app "FFe: Sync gorm.app 1.2.10-1 (universe) from Debian sid (main)" [Wishlist,New] [08:21] argh, sorry; I was too late in this round [08:21] pitti: your accept whack-a-mole wasn't quite quick enough [08:22] ok, I cleaned up components-mismatches now; AFAICS, the only real thing left is mod-wsgi [08:23] oh, and gnugo/kigo [08:31] thanks ajmitch [08:37] pitti: GEMLeak - did lool follow through on his CPU usage regression? I agree it seems we should take that for final, anyway [08:37] pitti: OOo was rejected per mvo's mail [08:37] slangasek: yes, it was determined to be unrelated to the update [08:37] pitti: ok, good [09:06] * slangasek grunts sourly at the need for a perl upload [09:07] my first reaction reading that bug wasn't "we should accept perl", it was "we should remove safe-rm from the archive"... [09:07] slangasek: sorry [09:07] but from what I read, removing safe-rm wouldn't have fixed it [09:07] true [09:08] OTOH, do people actually install safe-rm? [09:08] it was the safe-rm debian maintainer who filed the bug & poked me about it [09:13] slangasek, bug 563618 has a branch linked now for review [09:13] Launchpad bug 563618 in util-linux "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Triaged] https://launchpad.net/bugs/563618 [09:13] ogra: ack [09:16] 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] 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] ogra: ok, great :) [09:16] oh, geeez ! [09:17] it *does* reboot if i remove the SD [09:17] tsk [09:17] how could i know it actually *means* what it writes on the screen [09:18] 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] yay [09:45] pitti: nice [09:46] slangasek: you consider seed change intrusive/risky? [09:46] asac: post-RC, for a low-priority bug? Yes. [09:46] especially when you're *un*seeding things [09:46] because that may uncover bugs caused by missing dependencies [09:47] slangasek: yeah. was an oversight before. too bad. [09:47] evolution-indicator might have given us a few more M more ram ;) ... but ok. [09:49] yep, would've been nice, but not the week before release [09:50] 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] 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] (except universe fixes that may run after candidate generation ?) [10:08] ttx: "buildd situation" - are you referring to something other than the queue of langpacks? [10:09] no, the queue of langpack :) [10:09] ttx: but yes, everything that can be done as SRU should be pushed to lucid-proposed instead [10:09] ttx: langpacks are quick, and don't block other builds (they have a low build scoree) [10:09] (just FTR) [10:09] pitti: OTOH, we absolutely have to get the langpacks built before Monday :) [10:09] pitti: right, but they still need to complete ;) [10:09] heh [10:10] 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] oh, and we got another i386 buildd, nice! [10:10] pitti: was it you that accepted openoffice.org-hyphenation for bug #568514, btw? [10:10] Launchpad bug 568514 in openoffice.org-hyphenation "package openoffice.org-hyphenation-de 1:3.2.0-2ubuntu2 failed to install/upgrade: trying to overwrite '/usr/share/myspell/dicts/hyph_de_CH.dic', which is also in package openoffice.org-hyphenation ..." [High,Fix released] https://launchpad.net/bugs/568514 [10:11] slangasek: no, I didn't touch it [10:11] ok [10:11] I saw it in the queue yesterday night, but this morning both oo.o and -hyphenation were gone [10:11] whoever did, overlooked another part to the bug [10:12] I'll upload the fix shortly; no sense waiting for ccheney to be awake again [10:13] slangasek: ok, FTR, at this point we (server) don't have anything ready that would *need* to go in before release. [10:13] emphasis being on /ready/, as we certainly have some annoying bugs. [10:14] ttx: the cloud-init bugs, or other stuff? [10:14] slangasek: i'm updtaing the status page, just a sec [10:15] slangasek: https://wiki.ubuntu.com/ServerTeam/ReleaseStatus [10:15] see "under investigation" [10:15] At that point I don't see how any of those might make release, except maybe the olcAccess (openldap) one [10:16] the others we either don't have a solution yet for, or they are good SRU candidates [10:16] will sync with team on all those before the meeting today [10:16] (we are having a meeting today, right ?) [10:17] 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:17] Launchpad bug 533029 in autofs5 "[FFE] autofs5-ldap doesn't work immediately after bootup" [High,Triaged] https://launchpad.net/bugs/533029 [10:21] 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] GAR [10:22] ttx: yes, meeting today [10:23] thanks for the quick approval on ubiqutiy [10:27] 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] slangasek, hey, yes [10:28] slangasek, I pinged you about that saying if you wanted the debian update or if I should just fix the french .install [10:28] 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] slangasek, but I didn't read your reply if you replied [10:28] urg, sorry about that [10:28] well, someone accepted it and it's broken :) [10:29] file conflict between what and what? [10:29] just curious [10:29] 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] agh, why do people try to optimise away setting the correct fields [10:29] slangasek, the changes I cared about are to use the right names in openoffice.org-thesaurus-fr* [10:29] it never saves time in the long run [10:30] slangasek, ie th_fr to thes_fr [10:30] $ 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] text/hunspell-de-at,universe/text/myspell-de-at,universe/text/hunspell-de-at-frami [10:30] text/hunspell-de-ch,universe/text/myspell-de-ch,universe/text/hunspell-de-ch-frami [10:30] text/hunspell-de-de,universe/text/myspell-de-de,universe/text/hunspell-de-de-frami [10:31] text/hunspell-de-de,universe/text/myspell-de-de,universe/text/hunspell-de-de-frami,text/myspell-de-de-oldspell [10:31] text/hunspell-en-us,universe/text/myspell-en-us [10:31] seb128: ^^ those are the conflicts in lucid with the packages whose install files were touched in this upload, according to Contents [10:31] cjwatson: if by "correct fields" you mean "Conflicts/Replaces", I don't think optimization was the problem :) [10:32] 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] though it's possible those packages already have conflicts with one another; lessee [10:35] ok, the remaining file conflicts are actually all declared [10:36] 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] so the easiest way out is forward [10:36] seb128: the actual bug for this is bug #568514 [10:36] Launchpad bug 568514 in openoffice.org-hyphenation "package openoffice.org-hyphenation-de 1:3.2.0-2ubuntu2 failed to install/upgrade: trying to overwrite '/usr/share/myspell/dicts/hyph_de_CH.dic', which is also in package openoffice.org-hyphenation ..." [High,Fix released] https://launchpad.net/bugs/568514 [10:38] seb128: so the reason the Debian maintainer didn't handle it is openoffice.org-hyphenation is Ubuntu-only [10:38] oh, makes sense now [10:42] slangasek, sorry again about those [10:43] slangasek: ok for me to sync the new tzdata 2010i into lucid? [10:43] 'sok, we'll get it fixed :) [10:43] * pitti thought that the DST change crazy period was over, but apparently not so [10:43] pitti: yes, go ahead [10:44] (three DST rule changes, no structural differences) [10:44] pitti, can we sync shotwell too? [10:44] seb128: no idea, haven't looked at it; is there a bug/changelog/etc.? [10:44] pitti, http://packages.qa.debian.org/s/shotwell/news/20100420T220717Z.html [10:44] pitti, basically nmu to build with vala 0.8 [10:45] which we have in lucid [10:45] to fix FTBFS? [10:45] yes, that seems fine [10:45] pitti, can you do it if you are doing syncs? thanks [10:45] seb128: yep, doing [10:56] pitti, cjwatson: base-files, openoffice.org-dictionaries uploaded; please review [11:07] base-files looks fine, accepted [11:07] slangasek: oh heck, I need to update postgresql-common for this ^ [11:08] for base-files? [11:08] ah, no [11:08] it checks lsb_release -rs [11:08] which is still 10.04, not "LTS" [11:09] right, things checking that field is exactly why I didn't put LTS in it :-) [11:12] review> you lot are too fast for me [11:19] looks like somebody rejected landscape-client last night, but it's in the queue again. What's the background on that? [11:24] wasn't me [11:25] 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] langscape> me neither [11:26] cjwatson: hm, it says it's in the queue for 20 hours? [11:26] i. e. doesn't look like "rejected"? [11:27] 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] 22:48 -queuebot:#ubuntu-release- Removed package: landscape-client [11:27] 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] which looks like "somebody discussed some flaw with the uploader, then rejected so that they could reupload" [11:28] so presumably only whoever had that discussion can effectively review it [11:28] 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] oh, I suppose it could be [11:28] it's odd for it to explicitly say "Removed" unless it really is, that's all [11:29] repeated "New" is a different matter [11:38] stgraber, highvoltage: how are we on final edubuntu-artwork? [11:41] I haven't done the CD stuff yet, but I have the material from highvoltage [11:42] 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] cjwatson: if you think that's smart then I can make the change [11:53] if you could, yes please [11:53] just want to play safe at this point [11:57] ScottK: somewhere between 8.5 and 9.5 hours into dpkg-deb, we got to pkgstriptranslations and output resumed. [11:58] 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] ++ [11:59] I don't think a bug has been opened for this yet, though [11:59] slangasek: thank you. [11:59] and no, I didn't file a bug [12:00] ^ rejected [12:00] slangasek: IIRC it's still on KNR armel, but that image isn't size constrained so no lzma is fine. [12:10] slangasek: yeah, I agree [12:17] slangasek: OO.o> ack [12:18] * pitti reviewes partman-* [12:22] cjwatson: bug #530027 still not deferred, does that mean it needs fixing before release? [12:22] Launchpad bug 530027 in ubiquity "nested progress bars don't work outside debconffilter" [High,Triaged] https://launchpad.net/bugs/530027 [12:29] ScottK, Riddell: is anyone working on bug #551456? [12:29] Launchpad bug 551456 in kcm-touchpad "systemsettings crashes when clicking "Keyboard & Mouse"" [High,Triaged] https://launchpad.net/bugs/551456 [12:30] (if not, should probably be deferred to SRU now) [12:32] slangasek: not that I know of, I'll ping Jonathan Thomas to check [12:32] slangasek: did you reject the kdeplasma-addons upload this week? [12:32] Riddell: yes [12:33] https://bugs.launchpad.net/ubuntu/+source/kdeplasma-addons/+bug/566127 [12:33] Ubuntu bug 566127 in kdeplasma-addons "Picture of the day does not work" [Undecided,Fix committed] [12:33] oh aye [12:34] slangasek: and I'm assuming someone else is doing the oo.o mod for armel [12:34] lamont: sure? [12:34] I think it's "whoever gets to it" [12:34] as in I'm not preparing an upload [12:35] lamont: it's diff.gz only, really lightweight ;) [12:37] for oo.o, yeah. my dayjob tasks are interferring with my dev stuff [12:38] ^^ that one's mine, if someone could review [12:38] * cjwatson looks [12:39] cjwatson: you already fixed the other half of that bug, so if you don't like it, don't hesitate to reject [12:40] no, I'm fine with it, I see many more risks than benefits in applying it on upgrade [12:41] accepted [12:41] ok, thanks [12:41] err, wait! [12:41] shouldn't that be --no-start? [12:41] sorry, only spotted this after accept [12:42] possibly -r as well, I forget the exact semantics [12:42] but surely we *do* want to modify the postinst/postrm/prerm scripts [12:42] to call update-rc.d [12:44] ah, quite [12:44] sorry, will fix [12:57] https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/568940 [12:57] Ubuntu bug 568940 in openoffice.org "drop lzma from armel for lucid" [Undecided,New] [12:57] and targeted to 10.04 [13:00] lamont: can't this wait until the first update? [13:01] doko_: dropping lzma? not if we want the *pending* update to build on armel in a sane amount of time [13:01] ahh, wasn't aware of *another* update [13:02] another ooo update?!? [13:02] then please, please merge my changes in as well [13:02] slangasek: do you do that, or should I? [13:02] mvo: weren't we waiting for *you* to send us one? :) [13:03] mvo: even better, take over! =) [13:03] and I am waiting on my machine to finish building it, even debuild -b -nc takes ages [13:03] mvo: the "pending update" I meant was the one with your changes - we should get the lzma change added on to that [13:03] yeah [13:03] cool [13:04] is it just "use_lzma_compress=n" ? [13:04] in debian/rules ? [13:04] I'll look [13:04] thanks doko_ [13:05] 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] mvo: but on armel only [13:05] the upgrade stuff is automatic and relatively fast, I just need to review the logs [13:05] we certainly want to keep lzma for i386/amd64 [13:06] aha, ok [13:06] Riddell: there's an unanswered question for you from ev on bug #567243 [13:06] Launchpad bug 567243 in ubiquity "error during OEM setup in French" [Undecided,New] https://launchpad.net/bugs/567243 [13:06] slangasek, arm enhanced the hack on bug 563618 (branch with tested changes linked) [13:06] Launchpad bug 563618 in util-linux "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem" [High,Triaged] https://launchpad.net/bugs/563618 [13:06] slangasek: I still don't get this - -r alone only prevents the prerm running init.d stop [13:06] (yes, i know i'm annoying, sorry for that) [13:07] looks like we want --no-start (which includes -r, looking at dh_installinit) [13:07] with -r, the init script will still be run on postinst configure [13:07] cjwatson: mm, yes [13:07] cjwatson: reject, I'll reupload [13:08] done [13:10] cjwatson: thanks for the scrutiny; I clearly don't have dh_installinit internalized as well as intended [13:10] slangasek, ev: bug 567243 answered [13:10] Launchpad bug 567243 in ubiquity "error during OEM setup in French" [Medium,New] https://launchpad.net/bugs/567243 [13:14] 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] 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] so I'm inclined to just ignore those [13:14] auctex is also just a glitch AFAICS [13:15] slangasek, ok, thanks [13:15] 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] right, same FTBFS reason like plasma-widget-networkmanagement [13:16] pitti: and faure gives an unfriendly error instead of useful debugging output :/ [13:18] cjwatson: ^^ take 3 [13:20] pitti: last I checked, auctex was ultimately a result of emacs23 failing to build on ia64 [13:20] 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] cjwatson: aah, thanks [13:21] cjwatson: given that c-m considers ports, it's in a surprisingly good shape :) [13:26] ogra: not that I know of, our main testers are ncommander and gruemaster's son [13:26] ah, k [13:50] slangasek: ok, accepted now, thanks [13:50] slangasek: we received the new artwork yesterday \o/ [13:50] slangasek: I made the changes and uploaded the new package [13:51] cjwatson: did you get my link yesterday with the new boot logos? [13:55] 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] 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] 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] 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] ScottK: ok; since it doesn't seem realistic to verify correctness by eyeballing the debdiff, this should rather be tested extensively then [13:58] pitti: Yes. I think it has been tested fairly extensively in Debian already. [13:59] 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] That's why it's coming so late. [13:59] ok, thanks [14:01] 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] 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] highvoltage: I did, thanks, will process it today [14:20] cjwatson: and thank you! [14:41] ^ weirdest patch to remove scroll bars EVAR [14:41] (discussing in #u-desktop right now) [14:48] 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] so it works and is consistent with existing documentation. [14:53] highvoltage: committed and deployed; should be on the next CD [15:01] cjwatson: great! I'll test it with the next build [15:03] 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] stgraber, manual [15:05] ogra: ok, thanks [15:05] ogra: how's ARM going btw ? [15:06] stgraber, see planet :) [15:12] slangasek: any reason to not retry oo.o on sparc? [15:12] other than the "newer one coming" reason? [15:13] and I wonder how many more glib2.0-caused failures we have out there [15:14] oh right we probably want a respin of edubuntu when the artwork package hits the archive :) [15:24] ogra: how's ARM going btw ? [15:24] stgraber, see planet :) [16:00] slangasek: for the record, alternates have tons of space, I'll add back some langpacks (there are none except -en right now) [16:26] 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] lamont: OOo on sparc> new one's coming, and there's other stuff in the build queue on sparc? [16:32] pitti: alternates> doh! thanks [16:32] slangasek: right. [16:32] IOW, no. [16:33] slangasek: I expect that there are other glib2.0-induced failures that we should throw back in for sparc [16:33] but nfc which ones [16:33] and my level of caring is completely academic [16:34] ScottK: one security fix and 6 bug fixes [16:35] slangasek: Can you trigger a rebuild of Edubuntu once 0.1.0-69 is in the archive ? [16:35] edubuntu-artwork 0.1.0-69 that's [16:35] stgraber: trigger set [16:35] cool [17:33] pitti: ok, I don't actually find the discussion of the extra xorg patch in my scrollback that I thought was there [17:37] pitti: but the patch itself looks straightforward and important - did you have specific concerns with it? [17:38] slangasek, he was concerned about the other change in the upload I think [17:38] 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] slangasek, the confusion was about the 0ubuntu6 entry [17:52] 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] slangasek, bryce confirmed it's targetted to lucid [17:53] slangasek, so feel free to accept the upload if you want [17:53] slangasek, when have time to review it ;-) [18:00] seb128: great, thanks [18:26] stgraber: got a build failure on edubuntu, probably due to langpacks [18:28] 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] mvo: ok - you want me to wait for that test too before accepting [18:29] ? [18:29] stgraber: sure enough, there's the mail - langpacks [18:30] slangasek: it should be finishing in ~30 min or so, so I would say yes [18:30] slangasek: unless you think its too urgent to wait [18:30] nope [18:31] ok, i let you know when its there [18:35] doh, which one is broken this time ? [18:36] 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] stgraber: nope, sorry - the logs will be synced soon [18:43] stgraber: it's not something you can fix anyway, the langpacks just need to finish building :) [18:45] i.e., the build failure is simply due to mid-langpack-build skew, not a source bug that needs fixed [18:51] slangasek: ok [19:00] looks like langpacks are progressing at about 50/hr, so roughly 7 more hours to completion [19:01] 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] 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] ScottK: will those universe packages land ahead of the langpacks in the queue? [19:02] slangasek: They will. [19:03] 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] OK. I'll wait. [19:03] ScottK: ok, thanks [19:10] mvo: are we there yet? :) [19:12] 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] ScottK: yes, let's take it [19:13] OK. Thanks. [19:28] slangasek: the log looks good, components show as registered, upgrade almost finished, all looks well [19:28] slangasek: I think we have a winner! [19:37] 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] slangasek: both work now when they before failed [19:40] mvo: ok, accepted [19:40] mvo: thanks for taking care of this! [19:42] slangasek: kdenetwork was the dial up networking fix I mentioned. I reviewed and accepted, so it's done. [19:45] ScottK: ok, cool [19:54] slangasek: thank you! I'm happy that this is resolved now [19:54] * mvo sends the updated diff to debian [19:54] so now everything upgrades perfectly, right? :-) [19:55] everything that I tested … [19:55] :) [19:55] want to test mysql server? [19:55]