=== bladernr_ is now known as bladernr_afk
[05:03] <pitti> micahg: still need copying, or did someone else get to tit?
[05:04] <micahg> pitti: infinity got to it, thanks
[09:02] <jamespage> morning all
[09:02] <jamespage> please could the libv8 binary packages in NEW be accepted into precise - FFe bug 892034
[09:02] <ubot2> Launchpad bug 892034 in libv8 "[FFe] Please merge nodejs (0.6.12~dfsg1-1) from Debian unstable" [Medium,Fix released] https://launchpad.net/bugs/892034
[10:47] <doko_> jamespage, accepted
[10:49] <jamespage> thanks doko_
[11:24]  * Riddell wonders what hamster-indicator is in new
=== bladernr_afk is now known as bladernr_
[13:23] <jbicha> hi, so I guess I decided to try the "ask forgiveness instead of permissions" strategy with my accidental tracker upload
[13:23] <jbicha> I was thinking dput ppa:gnome3-team/gnome3 but my fingers typed dput ubuntu, I was going to ask for a FFe today for it anyway
[13:27] <jbicha> here's the rdepends http://paste.ubuntu.com/913005/
[13:28] <Laney> jbicha: it needs a transition?
[13:31] <jbicha> Laney: yes, but it's smallish, I can handle gnome-documents (we were stuck at a development snapshot any way because newer versions required new tracker), and we should just be able to sync bognor-regis & grilo-plugins from wheezy
[13:31] <Laney> OK, and is tracker itself a sync?
[13:32] <Laney> I suggest now that it's done that we get someone to deNEW it and you handle the transition ASAP (looks small anyway)
[13:33] <jbicha> Laney: our evolution packaging is a bit broken, evolution-dev should depend on libevolution, I explicitly added that to tracker's build-depends
[13:33] <Laney> evolution just got an upload ...
[13:34] <Laney> anyway, I believe that if there's a diff that the version needs an ubuntu substring to make the autosyncer not clobber it.
[13:34] <jbicha> yeah, there's the fix :)
[13:35] <jbicha> it's fine if the autosyncer clobbers it, the diff won't be needed any more
[13:35] <Laney> ok, well it's in NEW for all arches now.
=== x4 is now known as init
=== init is now known as x4
[14:02] <cjwatson> I posted an analysis to -devel of all the remaining build failures in main.
=== x4 is now known as init
[14:12] <skaet> thanks cjswatson.  :0
[14:12] <skaet> :) even
[14:24] <gema> skaet, cjwatson: is there a website where we can see build failures in any understandable fashion?
[14:24] <gema> like a summary of builds or so
[14:25] <cjwatson> gema: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20120328-precise.html
[14:26] <cjwatson> that's of the "rebuild everything based on current archive" run going on at the moment
[14:26] <gema> cjwatson: thanks
[14:26] <cjwatson> doko_: is it OK to sync gdc-4.4 and gdc-4.6 from unstable to fix their test rebuild failures?
[14:27] <stgraber> would probably be a good idea to update the link to the ftbfs in #ubuntu-devel's topic, can someone with access do that?
[14:27] <doko_> cjwatson, ohh yes. forgot that
[14:27] <cjwatson> shall I do that?
[14:27] <doko_> sure
[14:28] <cjwatson> done
[14:37] <cjwatson> doko_: Is the python2.7/amd64 failure one you've seen before?
[14:39] <doko_> cjwatson, yes, not able to reproduce here. and failing on some other debian archs too. will disable the test with the final 2.7.3 release
[14:40] <cjwatson> ok
[14:42] <doko_> I have to recheck mpfr4, but that one wasn't reproducible either :-/
=== bladernr_ is now known as bladernr_afk
[14:51] <doko_> cjwatson, do you have a reference for the genshi upstream report?
=== doko_ is now known as doko
[14:57] <cjwatson> doko: they're linked from bug 935516
[14:57] <ubot2> Launchpad bug 935516 in genshi "genshi version 0.6-2 FTBFS on i386 in precise" [Unknown,Confirmed] https://launchpad.net/bugs/935516
[14:57] <cjwatson> comment 1
[15:05] <Laney> stgraber: anyone can
[15:06] <stgraber> Laney: oh, right, I thought the channel was +t
[15:06] <Laney> thankfully not :-)
=== lool- is now known as lool
=== init is now known as x4
[15:58] <nessita> hello all! just wanted for confirm archive is open for uploads
[15:58] <nessita> sorry, typo: if* the archive is open...
[16:00] <cjwatson> yes
[16:00] <cjwatson> subject to feature/ui freezes
[16:01] <nessita> cjwatson: right, thanks1
[16:01] <skaet> nessita,  should be bug fixes or approved feature freeze exceptions only at this point.
[16:02] <nessita> skaet: yes, thanks
=== bladernr_afk is now known as bladernr_
[16:51] <micahg> could someone please copy thunderbird/oneiric from ubuntu-mozilla-security to oneiric-security
[17:14] <micahg> any archive admins aroundopy for a copy?
[17:18] <micahg> slangasek: could you please copy thunderbird/oneiric from ubuntu-mozilla-security to oneiric-security
[17:28] <slangasek> micahg: looking
=== fabo__ is now known as fabo
[17:56] <slangasek> micahg: done, sorry for the delay
[17:56] <micahg> slangasek: thanks
[18:12] <broder> could i get someone to accept the mosh packages in binNEW? they've been sitting there for a while now
[18:18] <phillw> Hi, just as a heads up to bug that is getting hotter as a regression, has bug 972285 hit your radar yet?
[18:18] <ubot2> Launchpad bug 972285 in linux "segmentation fault when start on linux 3.0.0-18-generic" [Undecided,Confirmed] https://launchpad.net/bugs/972285
[18:35] <knome> can somebody from the release team look at bug 972402? also, are we still in a mode where just uploading is okay after ACK, or do i need to do something else?
[18:35] <ubot2> Launchpad bug 972402 in xubuntu-meta "FFe: include xfce4-datetime-plugin in Xubuntu's default install" [Undecided,New] https://launchpad.net/bugs/972402
[18:39] <knome> btw, note that this FFe is actually three bugs... (links in the bug)
[18:43] <cyphermox> hi, could someone please give back evolution-exchange and evolution-indicator in test-rebuild-20120328 ?
[18:50] <stgraber> cyphermox: done
[18:50] <cyphermox> stgraber: thanks
[18:59] <micahg> who has rights on the copy archive?
[19:00] <slangasek> for build retries, it looks like it might be buildd admins only
[19:00] <micahg> ah, ok
[19:08] <stgraber> jibel: ouch, for a moment I thought my upgrade testing environment was broken (after 2 days of edubuntu upgrade failing) but checking jenkins I see that Ubuntu is broken too for the same reason (compiz/unity/... failing to upgrade) ;)
[19:56] <infinity> knome: I'm a bit biased, since I already use xfce4-datetime-plugin.
[19:57] <infinity> knome: Is there a migration strategy at all for upgrades, or will panels just be different between new and upgraded installs?
[19:57] <knome> infinity, just different
[19:57] <knome> infinity, the looks is the same afaik though
[19:57] <infinity> knome: (Either way, I think moving to the new datetime is the right thing to do, and it's mostly your call, not ours, as long as you don't break the world)
[19:58] <knome> hehe, we won't
[19:58] <knome> so if you can add ACK for the bug (and the others too), i'll tell our uploaded to do his thing
[19:59] <infinity> Sure.
[19:59] <knome> thanks
[19:59] <infinity> I'll just ACK the meta bug.
[19:59] <knome> btw, release team is not subscribed to the other bugs, if that matters
[20:01] <infinity> S'all good.
[20:01] <infinity> Like I said, I just acked the FFe one, just do your thing and close them all as you upload.
[20:01] <knome> k, will do. thanks! :)
[20:03] <infinity> knome: This is largely based on the fact that I run the new datetime every day, and I know it's not broken.  So, please don't break it now. ;)
[20:03] <knome> hehe
[20:03] <knome> won't, we promise
[20:07] <infinity> broder: No plans to fix the arm* FTBFS first?
[20:08] <infinity> broder: (And I assume you mean binNEW for the backports?)
[20:09]  * infinity accepts, given that it's backports anyway...
[20:14] <broder> infinity: arm fix is coming in a few days, but yes, was referring to backports. thanks
[20:15] <infinity> broder: arm fix(es), perhaps.  The failure in lucid didn't look the same as the one in precise, though I didn't look closely, could be the same root cause.
[20:16] <broder> it's probably not. the precise failure was due to thumb-2-by-default
[20:16] <broder> i'll look into lucid
[20:17] <infinity> Yeah, the precise one was definitely thumb.
[20:17] <infinity> The lucid one was whining about a no-op comparison, which at first geuss, I would has assumed a signedness error, but then powerpc would have failed (which it didn't).
[20:17] <infinity> s/would had/would have/
[20:18] <micahg> would it be a problem if a -backports package is only built against -security? (no reverse dependencies)
[20:19] <infinity> micahg: What do you mean?
[20:19] <micahg> infinity: after the thunderbird 11 migration I want to backport lightning-extension (been meaning to do this for 2 years now), the first one will be a real backport, but I'd want to keep it updated when I push out security updates
[20:20] <micahg> so, I'd like to build the backport in the security PPA with everything else
[20:20] <infinity> And then have it copied to backports manually?
[20:20] <micahg> yep
[20:20] <micahg> I'd do it as an actual backport of whatever release I end up backporting from (probably precise)
[20:20] <infinity> Does it help to realise that -backports already builds against security?
[20:21] <micahg> infinity: it's about timing, nothing else
[20:21] <infinity> backports is a superset of updates (and security).
[20:21] <micahg> yes
[20:21] <infinity> But I guess if it's just a timing issue, sure, it can be done, there's nothing magical about the backports pocket.
[20:21] <infinity> But make sure the people who do backport approvals are aware that you'll be end-running around the process.
[20:22] <micahg> infinity: that's me :)
[20:22] <infinity> Well, talk to yourself, then.
[20:22] <micahg> and I"ll open a backport tasks when I do this so people are aware
[20:23] <infinity> Just make sure the AA who get to do this for you is very clear on what you're doing, so no one copies it to security by accident. :P
[20:23] <micahg> infinity: right
[20:23] <infinity> But yeah, like I said, nothing magical about the pocket, so no technical reason we can't do it.
[20:24] <micahg> ScottK: ^^ FYI
[20:26] <ScottK> OK
[20:27] <ScottK> micahg: That's fine.
=== ajmitch_ is now known as ajmitch