[00:00]  * skaet thinks the channel topic is long enough, but is willing to have it added if others feel its important.
[00:01]  * skaet --> EOD
[00:24] <infinity> cjwatson: I'm sure you're asleep by now, but is there any reason why change-override no longer has any output to stdout?
[00:25] <cjwatson> Erm.  It's supposed to.
[00:26] <cjwatson> I wonder if I broke it.
[00:26] <infinity> cjwatson: This just returns without doing anything (AFAICT)
[00:26] <infinity> change-override -c universe cl-speech-dispatcher speech-dispatcher-doc-cs speech-dispatcher-festival speech-dispatcher-flite
[00:26]  * cjwatson experiments.
[00:27] <infinity> (Everything in i386 in that source landed in main, so there's an arch skew, I wonder if that relates?)
[00:27] <micahg> infinity: in the mean time, can you poke precise for backports?
[00:27] <cjwatson> Oh, hahaha
[00:27] <infinity> Also, did someone make the NEW queue override handling worse than it used to be?
[00:28] <cjwatson> Removed a *little* too much when moving stuff to a common module
[00:28] <slangasek> skaet: vanguards> wasn't that supposed to be split out into a new page?
[00:28] <slangasek> (http://wiki.ubuntu.com/SRUTeamProcess)
[00:28] <infinity> Cause, my guess as to how the entire source landed in main is perhaps that someone NEWed its one new arch:all binary to main via the queue.  Which used to only act on the actually "new" binaries.
[00:28] <cjwatson> Not aware that NEW override handling's been changed particularly.
[00:28] <cjwatson> infinity: change-override r496 *cough*
[00:29] <infinity> micahg: Sure.
[00:29] <micahg> thanks
[00:29] <skaet> slangasek,  yes, more to go onto that page though, and the 12.04.1 team was asking for pointers this morning, so I put it there for now.
[00:29]  * skaet will move it.
[00:29] <infinity> micahg: What am I poking?
[00:29] <slangasek> skaet: ok
[00:30] <micahg> infinity: NEW for 2 sources and unapproved for 1 (should all be at the top)
[00:30] <infinity> True for the NEW ones anyway.
[00:30] <micahg> infinity: jquery :)
[00:30] <micahg> right, of course, people have the audacity to do work!
[00:42]  * xnox ponders, how do archive admins 'process' their queue if https://bugs.launchpad.net/~ubuntu-archive/+subscribedbugs timesout
[00:43] <infinity> Try harder until there's a hot cache of all the queries involved.
[00:43] <infinity> And then curse people who write massive(ly inefficient) SQL-driven systems.
[00:43] <cjwatson> xnox: lp-shell
[00:44] <xnox> ok
[00:44] <cjwatson> >>> ua = lp.people["ubuntu-archive"]
[00:44] <cjwatson> >>> for task in ua.searchTasks():
[00:44] <cjwatson> ...     print task.bug.id, task.bug.title
[00:44] <xnox> cjwatson: can you merge aptitude or shall I upload the patch to fix FTBFS-gcc4.7, it's one of the last 7 packages in boost1.49 transition
[00:44] <xnox> let me try that ;-)
[00:45] <cjwatson> I told you, it's waiting for the pristine-tar xz fix
[00:45] <xnox> sorry, forgot.
[00:45] <cjwatson> Feel free to upload a non-merge patch in advance of that if you prefer
[00:45] <xnox> ok. thanks. will do.
[00:46] <infinity> cjwatson: Oh, haha.  I just read your change-override diff.
[00:46] <infinity> cjwatson: Oops.
[00:46] <cjwatson> Yeah, slightly aggressive refactoring
[00:47] <micahg> and last thing keeping boost1.46 in main :)
[00:48] <micahg> xnox: mpi-source can go now FWIW
[00:48] <cjwatson> skaet: I can auto-sync again, yes?
[00:49] <skaet> cjwatson,  auto-sync is good
[00:49] <cjwatson> Cool
[00:49] <xnox> micahg: true. but I wanted one bug and get rid of them together and not bother archive admins to much. or shall I split it...
[00:49] <micahg> xnox: nah, don't need to split
[00:49] <xnox> micahg: ok, one confirmed the other one incomplete?
[00:50] <micahg> yeah, sounds good
[00:51] <infinity> micahg: Can "go" as in "removed", or "to universe"?
[00:51] <infinity> Cause the latter, we get told about without bugs.
[00:51] <infinity> But I'm all for removing stuff. ;)
[00:51] <micahg> infinity: the mpi-source has no more dependencies AFAICT
[00:52] <micahg> the 1.46 mpi source that is :)
[00:52] <infinity> Full source name?
[00:52] <micahg> boost-mpi-source1.46
[00:52] <micahg> bug #1019090
[00:52] <ubot2> Launchpad bug 1019090 in boost-mpi-source1.46 "Please remove boost1.46 from Quantal" [Low,Confirmed] https://launchpad.net/bugs/1019090
[00:55] <infinity> Removed.
[00:56] <xnox> infinity: bug 1019096
[00:56] <ubot2> Launchpad bug 1019096 in mongodb "please remove 1:2.0.4-1ubuntu2 mongodb armel only binaries from quantal" [Undecided,Confirmed] https://launchpad.net/bugs/1019096
[00:56] <micahg> xnox: why would you do that?
[00:57] <infinity> xnox: Erm, are you sure about that?
[00:57] <infinity> xnox: Is this gcc 64-bit atomics?
[00:57] <xnox> discussed with doko and folks from #linaro
[00:57] <infinity> xnox: If so, it's waiting on a buildd kernel upgrade and it'll magically work again.
[00:59] <xnox> current quantal gcc toolchain for armel does not define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
[01:00] <xnox> is that the same?
[01:00] <xnox> i'll check with doko again then.
[01:01] <xnox> infinity: how would I find out about buildd kernel upgrades and things that will magically start working again?
[01:01] <infinity> That should be defined...
[01:02] <infinity> Since GCC uses software-driven atomics on older CPUs.
[01:02] <infinity> I thought.
[01:02] <infinity> Maybe I'm getting two issues confused.
[01:02] <xnox> doko> xnox, pm215, ramana: it's only defined for armv7. armel in quantal is armv5
[01:03] <xnox> <ramana> doko, that's bizarre. The sync primitives should be supported irrespective of the level of the architecture.
[01:03] <xnox> <ramana> doko, on armv5 the sync primitives end up calling the kernel helper functions.
[01:03] <xnox> <xnox> doko: i will leave the said package FTBFS on armel as a hint that it's a TODO item
[01:03] <infinity> Yeah, exactly what ramana said.
[01:03] <infinity> If it's not defined, that's probably a toolchain bug.
[01:04] <xnox> so.... should I file a bug about it... or do you think doko got the hint from ramana?
[01:04] <infinity> File a GCC bug and quote your IRC log there.
[01:04] <infinity> Cause we have full GCC atomic support (with kernel helpers) and all ARM targets.
[01:05] <infinity> Or, all the ones we care about.
[01:05] <infinity> Though they won't *work* on armel until we upgrade the buildd kernels. :P
[01:05] <infinity> But that's only an issue for testsuites and builds that run their own code.
[01:05] <infinity> Since it compiles correctly, and runs in quantal just fine.
[01:06] <xnox> ok
[01:06] <xnox> mongodb does run their own code as smoke test.
[01:06] <xnox> not going to disable the testsuite
[01:06] <infinity> Sure, so it'll fail anyway, even with a fixed compiler, but we know the solution to that, and it's being worked on.
[01:06] <infinity> Removing arches isn't the answer, fixing the bugs is.
[01:08] <xnox> <doko> ramana, but gcc -march=armv5 -E -dM - </dev/null|grep SYNC
[01:08] <xnox> prints nothing
[01:13] <xnox> infinity: filed as bug 1019098
[01:13] <ubot2> Launchpad bug 1019098 in mongodb "armel quantal please define sync primitives" [Undecided,Confirmed] https://launchpad.net/bugs/1019098
[01:13] <xnox> helpful, it is against gcc-4.7 package as well
[01:14] <infinity> xnox: Make sure some Linaro GCC hackers have it on their radar. :P
[01:14] <infinity> xnox: If you've been talking to some.
[01:14] <xnox> ok :P
[01:14] <infinity> Michael Hope would be a good choice, if he's jumped into the conversation.
[01:15] <infinity> He'll probably know straight up if it's a bug or a feature, and what to do about it.
[01:15] <xnox> matthias vs linaro team
[01:15] <infinity> (michaelh on IRC)
[01:15] <xnox> ok, thanks.
[01:15] <xnox> may I name you as a referral?
[01:16] <infinity> Sure. :P
[01:16] <infinity> He can hit me at the next Connect.
[01:16] <infinity> It'll be grand.
[02:20] <xnox> about pyopencl see bug 763457 as well
[02:20] <ubot2> Launchpad bug 763457 in nvidia-graphics-drivers "please provide opencl-icd virtual package" [Medium,Confirmed] https://launchpad.net/bugs/763457
=== cjwatson_ is now known as cjwatson
[09:50] <cjwatson> zul: Rejecting one of the two python-cinderclient uploads in NEW while I look over the other one
[09:51]  * ogra_ wonders if we cant do better than sending mails twice to -changes for every package that moved from $dev-proposed to $dev
[09:51] <ogra_> especially since they are all signed by the same person now
[09:51] <cjwatson> Yes, we probably can
[09:52] <cjwatson> At some point
[09:52] <ogra_> heh
[09:59] <Daviey> ogra_: distributed procmail rules? :)
[10:00] <ogra_> Daviey, well, i think we should fix that at the source :) save bytes !!
[10:29] <ogra_> hmm, are live builds still on manual ?
[10:48] <jibel> stgraber, quantal dailies have not been published to the tracker
=== peterm-ubuntu is now known as peter-lunch
[11:33] <Daviey> jibel: I think i know why that is...
[11:33] <Daviey> Hmm, i do not.
[11:34] <Daviey> they should have been..
[13:55] <stgraber> jibel: let me check quickly
[13:58] <stgraber> /srv/cdimage.ubuntu.com/bin/post-qa: 95: /srv/cdimage.ubuntu.com/ubuntu-archive-tools/post-image-to-iso-tracker.py: not found
[13:58] <stgraber> looks like Colin broke the script ;)
[13:58]  * stgraber fixes
[14:00] <stgraber> jibel: can you manually post them? or balloons? I don't see an easy way for me to rerun that part automatically
[14:02] <stgraber> Daviey: fixed (FYI, that kind of failure typically gets logged at the end of the cd-build-log)
[14:29] <Daviey> stgraber: thanks
[14:36] <stgraber> cjwatson: I update post-qa after the rename of post-image-to-iso-tracker.py to post-image-to-iso-tracker (noticed when we got no daily on the tracker today ;)), are you aware of any other script that should be updated?
[14:37] <stgraber> *updated
[14:37] <jibel> stgraber, thanks you
[14:37] <jibel> balloons, can you do the update ?
[14:38] <cjwatson> stgraber: Oh, thanks, good point
[14:38] <cjwatson> stgraber: I updated all the ones I remembered about ...
[15:43] <ScottK> I just accepted a new SRU for bzr that fixes a regression from their microversion update.  Since this is a targeted change to fix a regression in a previous SRU, how long to we let it bake after verification before copying to -updates?
=== yofel_ is now known as yofel
[15:50] <skaet> ScottK,  good question.   Standard 7 days doesn't quite seem appropriate, since its a fix for a regression on an SRU.   How well validated is it?
[15:51] <ScottK> None yet.  It's still building.  I just accepted it.
[15:51] <xnox> skaet: it's a revert of affending patch. Such that the original 2 bugs that the patch was fixing should now be reopened for an SRU again.
[15:53] <skaet> xnox,  good point,  we don't want to overlook that.
[15:57] <ScottK> jelmer already reopened the original bug.
[15:57] <skaet> ScottK,  once the fix is validated, and the original bugs are reopened,  we should probably get it released rather than waiting for the bake in period.   Only caveat, is with the holiday's approaching next week,  this sort of thing should be on Monday though, since coverage may be light for a good part of next week.
[15:57] <skaet> (since we don't usually do it on Fridays)
=== bjf[afk] is now known as bjf
[16:06] <slangasek> ScottK, skaet: I would publish it as soon as it's been spot-tested and confirmed to fix the stated issue
[16:06] <slangasek> Friday or not
[16:06] <ScottK> Makes sense to me.
[16:06] <skaet> slangasek, ok
[16:08] <ScottK> It's built on i386.  I can test it.
=== davidm` is now known as davidm
[16:18] <ScottK> Works.
[16:20] <ScottK> slangasek: I verified it, so once it finishes building, I'll release it.
[16:20] <slangasek> ScottK: sounds good
[16:40] <Daviey> ScottK: If you accept it today, are you happy to be on point for (unlikely) regressions over the weekend?
[16:41] <ScottK> Daviey: I'm always happy to deal with problems when I'm around.
[16:42] <ScottK> (I don't think SRU team people in particular or developers in general should only worry about such significant issues like release regressions during certain hours).
[16:43] <Daviey> ScottK: right.. the reason i ask is that in previous cycles there have been regressions introduced by SRU's over the weekend.. with nobody with access to deal with it.
[16:43] <Daviey> squid was a good example
[16:44] <Daviey> (Which is why i pushed for no SRU's on Friday's :)
[16:44] <cjwatson> Access should be less of a problem these days
[16:44] <cjwatson> Back then only Canonical employees could publish updates
[17:20] <cjwatson> MIR team folks: would anyone object to me moving fonts-lklug-sinhala, fonts-sil-nuosusil, and fonts-ukij-uyghur to main without MIRs?  They're all installed by language-selector for various languages, and in particular moving fonts-lklug-sinhala to main is required to fix bug 1015483
[17:21] <ubot2> Launchpad bug 1015483 in ubuntu-meta "ubiquity-dm: 2 language names wrongly displayed (missing font?)" [High,In progress] https://launchpad.net/bugs/1015483
[17:28] <slangasek> mksh MIR> wtf
=== rickspencer3_ is now known as rickspencer3
[17:33] <infinity> cjwatson: I don't think anything more than a verbal "yeah, go for it" is required for font packages, as long as they're simple and (hopefully) unmodified from Debian so there's no maintenance burden.
[17:36] <cjwatson> infinity: We have a few that are modified for "squeeze more into desktop" reasons, but these aren't among them.
[17:36] <cjwatson> infinity: So is that a verbal "yeah, go for it"? :-)
[17:36] <infinity> cjwatson: Yeah.  Go for it. :P
[17:37] <cjwatson> Great, thanks.
[17:37] <infinity> If we find a security bug in a font tomorrow, I'll be a sad panda.
[17:37] <cjwatson> Oh, promoted the udebs and transitionals and such by mistake.  I'll demote them later.
[17:37] <cjwatson> (Can't remember if rapid promotions/demotions are still a problem ...)
[17:38] <infinity> I *think* it gets it right now, but I don't remember...
[17:38] <infinity> And I always take the paranoid approach and wait a cycle.
[17:38]  * slangasek works on kicking pdksh out of main
[17:38] <infinity> We probably should sort out, one day, how much of our residual paranoia can go away, and what bugs still need fixing. :P
[17:38] <cjwatson> Kind of what I've been doing :-)
[17:39] <cjwatson> Ish
[17:39] <infinity> slangasek: But, but, I'm sure it's the prefered shell for 1 in 20000 users.
[17:39] <slangasek> infinity: that has nothing to do with why it's in main
[17:39] <infinity> slangasek: rbuild-dep was my assumption, I hadn't looked yet.
[17:40] <slangasek> yep
[17:40] <slangasek> *spurious* rbuild-dep
[17:40] <slangasek> wtf people
[17:41] <cjwatson> You filed bug 180218, but I'm not entirely sure that's it.
[17:41] <ubot2> Launchpad bug 180218 in launchpad "override mismatch race needs to be fixed" [High,Triaged] https://launchpad.net/bugs/180218
[17:42] <cjwatson> stgraber: Testing a fix for livecd-rootfs and -proposed now
[17:42] <cjwatson> I guess I'll need to SRU that in order to get it into the livefs build chroots
[17:42] <cjwatson> infinity: You don't happen to know whether the livefs build chroots can get livecd-rootfs installed from -proposed, do you?
[17:42] <cjwatson> It would save time.
[17:44] <infinity> cjwatson: I'm sure it could be arranged.
[17:44] <cjwatson> Can you do it or do I need to ask some bit of IS?
[17:44] <infinity> cjwatson: But We could also just fast-track an SRU.
[17:44] <cjwatson> I need to get an updated BuildLiveCD put in place anyway.
[17:45] <cjwatson> infinity: Which raises the secondary question of whether the livefs build chroots have -updates switched on :-)
[17:45] <infinity> cjwatson: It's a webops-ish thing.  And be sure to mention the BuildLiveCD thing explicitly, they need to jam that into puppet and let is propagate.
[17:46] <infinity> cjwatson: I *think* we made sure they had updates on a while ago.  But memory's failing in my old age, and maybe that wasn't for precise.
[17:46] <infinity> s/let is/let it/
[17:46] <cjwatson> If this test build looks good then I might see if I can get somebody to do it for me before the week dies.
[17:46] <cjwatson> Assuming I'm not dragged off for evening stuff before then.
[17:47] <cjwatson> (I kind of promised stgraber/jibel it'd be done before EOW)
[17:48] <stgraber> cjwatson: long weekend here, so I won't notice until Tuesday at least ;)
[17:51] <infinity> stgraber: Oh hey, Canada Day is upon us, I hadn't even noticed.
[17:52] <infinity> stgraber: Also, you're in Quebec.  You can't celebrate Canada Day.  Get your own holidays (of which you appear to have many).
[17:52] <stgraber> infinity: well, it's your fault for not having Alberta day ;) I'm quite enjoying having two long weekends in a row, the Edubuntu todo list is getting much shorter thanks to that
[17:53] <highvoltage> it will be my 3rd long weekend in a row.
[17:54] <slangasek> oh bah, of course the things that use pdksh are using it under the name ksh, not pdksh
[17:55] <slangasek> so yeah, not so spurious :(
[17:55] <cjwatson> What on earth do things still need ksh for in this day and age?
[17:55] <cjwatson> And are they all maintained by the mksh maintainer? :-)
[17:56] <infinity> People actually script in ksh?
[17:57] <slangasek> graphviz, shunit2 both reference ksh
[17:57] <ScottK> bzr's out.
[17:57] <slangasek> as to why, well...
[17:57] <slangasek> ScottK: cheers
[17:57] <infinity> Is it 1978?  Did I sleep on the wrong side of my flux capacitor?
[17:58] <slangasek> infinity: so entertainingly, if you don't have pdksh the only part of graphviz that doesn't build is the ruby bindings
[17:58] <infinity> slangasek: That seems like an acceptable sacrifice. :P
[17:59] <infinity> slangasek: (But surely, the offending bit can be rewritten in POSIX sh instead)
[17:59]  * slangasek hands infinity the knife
[17:59] <infinity> slangasek: Like, with nearly zero effort.
[17:59] <slangasek> more effort than I'm putting in today
[17:59] <cjwatson> Riddelll: Hm, so do you know why Kubuntu currently has both kdm and lightdm installed?
[17:59] <slangasek> let the MIR team sort it out :P
[18:00] <infinity> Well, I have no issues with swapping pdksh and mksh in main and letting the status quo continue for Right Now, but fixing the rbuild-deps seems generally sane anyway.
[18:01] <cjwatson> Riddelll: That's what's breaking ubiquity-dm - it's "start on (starting kdm or starting lightdm)" (among other things).  The lightdm job starts but does nothing because it isn't the default DM, but that's enough to let ubiquity start just after kdm starts, and then fail because kdm has already managed to start an X server.
[18:01]  * infinity wonders if the ksh dependency is/was perhaps a bizarre side-effect of Sun's /bin/sh sucking so hard that they had to pick something else to be "cross-platform".
[18:02] <infinity> It's amazing how many things in the UNIX world I can blame on Sun's /bin/sh, if I put my mind to it.
[18:02] <slangasek> lamont: postfix decided to stop resolving names, your package is making my bug reports late for the Debian freeze :P
[18:03] <ScottK> But since you can't report the bug on postfix, it seems like a fine situation for lamont.
[18:05] <ScottK> cjwatson: I was busy with work this week, so I'm not sure, but I suspect Kubuntu is accidentally half-switched.  I believe there's an intent to switch.
[18:06] <slangasek> ScottK: restarting postfix fixed it
[18:07] <slangasek> which seems to imply it's well named
[18:07] <ScottK> Meh.  No fun.
[18:08] <cjwatson> ScottK: Right, if the job gets finished then I think this will stop being a problem.
[18:08] <cjwatson> It's not ideal that it has this result, but it's pretty hard to fix.
[18:09]  * ScottK wonders where Riddelll is today?
[19:00] <cyphermox> hey; I'd like to use quantal-proposed to start the transition of evolution-data-server without making too many things uninstallable; is there any more coordination I should do than letting the release team know? ;)
[19:01] <infinity> cyphermox: That's good enough for me.
[19:01] <infinity> cyphermox: (Didn't we just break e-d-s two weeks ago?)
[19:01] <cyphermox> (yes we did)
[19:01] <cyphermox> infinity: ok. then that's a head's up to not take e-d-s from -proposed to -release just now, once I upload it
[19:02] <micahg> cyphermox: please coordinate with chrisccoulson for thunderbird
[19:02] <cyphermox> micahg: yes
[19:04] <cyphermox> might just end up being monday or tuesday
[19:08] <infinity> cyphermox: If you start it today, helpful community types (like me, with a different coloured hat) just may finish the transition for you.
[19:08] <infinity> cyphermox: Well, with the possible exception of thunderbird.
[19:09] <cyphermox> right, but I'm a little worried about breaking too many things on a friday afternoon
[19:09] <infinity> Breaking things in proposed is entirely acceptable.
[19:09] <infinity> FSVO "break".
[19:09] <cyphermox> and I'm working on setting up the transition tracker locally to see what I'm doing along the way, too
[19:10] <cyphermox> e.g. teaching it clumsily to care about proposed
[19:11] <Laney> We need to teach the deployed instance to do this too. It amounts to catting the Packages/Sources files together and doing away with the in-ben download step, as cyphermox tested. :-)
[19:11] <cyphermox> Laney: I'll have a script for you in a minute
[19:12] <Laney> get cjwatson to give you the cron script and hack it into that :P
[19:13] <cyphermox> I guess
[19:14] <cyphermox> infinity: also, I was trying to ask chrisccoulson about thunderbird, hence why I said monday or tueday, when he's aware of my plan
[19:14] <infinity> cyphermox: Fair enough.
[19:14] <Laney> Looks like ubuntu-archive@lillypilly already has a mirror, so that's easier
[19:14] <infinity> Laney: If by mirror, you mean the real thing.
[19:14] <Laney> it's called mirror.
[19:15] <Laney> /home/ubuntu-archive/mirror/ubuntu/dists/quantal/
[19:15] <infinity> Oh, you mean the mirror of the archive.
[19:15] <infinity> I thought you meant a "mirror" of the tracker.
[19:15] <Laney> a mirror to check it's hair is OK today
[19:15] <Laney> its
[19:16] <Laney> I know the tracker lives there — that's why I was checking for a mirror :-)
[19:17] <infinity> Yeah, yeah.  I'll stop being "helpful". ;)
[19:32] <cyphermox> Laney: so I checked with zlib, it does seem like when you cat -proposed over -release, the -proposed version is the one that gets tracked
[19:40] <Laney> cyphermox: yay