[01:27] <SpamapS> Can I get a quick IRC FFE for git-review 1.21 ? (unseeded leaf package)
[01:38] <SpamapS> debdiff is here: http://paste.ubuntu.com/5694217/
[01:56] <ScottK> SpamapS: You've tested this?
[01:58] <SpamapS> ScottK: have done 3 review submits with it to openstack projects. Not 100% code coverage .. but itI don't smell any smoke.
[01:58] <ScottK> SpamapS: OK. Got for it.
[01:59] <ScottK> Got/Go
[01:59] <SpamapS> ScottK: cool thanks :)
[01:59] <ScottK> You're welcome.
[01:59] <SpamapS> ugh, what a wonderful time for my home cable connection to die
[02:00] <bkerensa> heh
[03:12] <SpamapS> ScottK: finally got internet back on in my build box, so if you're still around git-review is uploaded now.
[03:13] <ScottK> OK.  I'll have a look when it appears.
[03:19] <ScottK> SpamapS: Accepted.
[03:21] <SpamapS> ScottK: ^5
[10:31] <jamespage> please could the rtslib update be accepted into raring-proposed
[11:45] <ScottK> doko: I absolutely don't have time to deal with this today because I need to leave for $work meetings soon, but ypur python3-defaults SRU moves py3versions from python3-minimal to python3 and causes Bug 1167183 and some dupes.
[11:45] <ubot2> Launchpad bug 1167183 in python3-defaults (Ubuntu) "package python3 3.2.3-5ubuntu1 failed to install/upgrade: trying to overwrite '/usr/bin/py3versions', which is also in package python3-minimal 3.2.3-5ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/1167183
[11:45] <ScottK> Anyone who's in the SRU team ^^^^
[11:45] <doko> ScottK, ok, looking ...
[11:46] <ScottK> I didn't check if anything else changed.
[12:20] <doko> ScottK, hmm, there is more ... looking to fix it for raring first
[13:14] <xnox> dobey: slangasek: Old U1 music store screenshot is removed from the slideshow in raring images the day before UI freeze, and replaced with my rhythmbox playing Adele =)
[13:15] <xnox> not sure if we want to fix 12.04.3 slideshow as well.
[13:26] <dobey> xnox: i think we'll want to fix the slideshow for 12.04, once the rhythmbox-ubuntuone changes land in 12.04 updates, i think
[13:27] <xnox> dobey: ok. i will check if we can reuse the raring slide image & change the screenshot to have e.g. precise theme on the window decorators.
[13:28] <xnox> dobey: what was the bug number such that I can assign it to myself.
[13:29] <dobey> bug #1166356
[13:29] <ubot2> Launchpad bug 1166356 in ubiquity-slideshow-ubuntu (Ubuntu Raring) "[UIFe] Old music store interface going away on server" [Undecided,New] https://launchpad.net/bugs/1166356
[14:23] <rtg_> infinity, I think linux-ti-omap4 should be removed from raring-proposed. I think armhf generic should supersede that kernel. That will also get it off the FTBS list.
[14:23] <ogra_> rtg_, err, nope
[14:23] <ogra_> panda will stay with the quantal kernel
[14:24] <rtg_> why?
[14:24] <ogra_> becauase we will keep the desktop image
[14:24] <ogra_> (dont ask )
[14:24] <ogra_> and we have no way in i.e. flash-kernel to easily handle both
[14:24] <rtg_> so, should the Raring mainline kernel still be supplying omap4-panda-es.dtb ?
[14:24] <ogra_> so the quantal one has to stay for server too
[14:25] <ogra_> optionally for the brave i'd say
[14:25] <ogra_> and in 13.10 we actually want to drop that mess
[14:25] <rtg_> ogra_, ah, we talked about this a week or so ago, didn't we.
[14:25] <ogra_> yeah
[14:25] <rtg_> doh!
[14:25]  * ogra_ would have happily dropped desktop panda
[14:26] <ogra_> as woulld infinity i think
[14:26] <rtg_> this was the case where infinity was going to re-sync from Quantal if that kernel ever changed.
[14:26] <ogra_> right
[14:27] <ogra_> in 13.10 server we should actually use generic ... so i dont think it makes sense to artificially rip it out now
[14:27] <rtg_> yeah, there is no harm in carrying the DTB.
[14:28] <rtg_> so I guess at the very least linux-ti-omap4 should get promoted to release ?
[14:29] <ogra_> yeah
[14:42] <doko> RAOF, ^^^
[15:24] <kenvandine> can someone please look at friends?
[15:25] <didrocks> kenvandine: finally having a changelog content from what I saw? ;)
[15:26] <seb128> slangasek, infinity, cjwatson: do we have any work in progress/release notes for raring somewhere?
[15:26] <kenvandine> yes, we are going to make sure that always happens :)
[15:26] <didrocks> \o/
[15:29] <seb128> Laney, do you do approval in freeze times? ;-)
[15:29] <seb128> it seems a bit suboptimal that almost nothing from the main/desktop goes through on european hours atm
[15:29] <Laney> yeah, I can do
[15:29] <Laney> will do some in a bit
[15:29] <seb128> Laney, thanks
[15:29] <Laney> slangasek was looking at friends though wasn't he?
[15:30] <seb128> I think so
[15:30] <seb128> but I see -intel s-c rhythmbox glib etc in the queue
[15:30] <seb128> im-config
[15:30] <seb128> sessioninstaller
[15:30] <seb128> note, I uploaded some of those, but still would be good to have stuff going during the european day ;-)
[15:34] <kenvandine> Laney, last i saw slangasek said he was going to leave friends, so not sure if he still is
[15:34] <kenvandine> i am mostly anxious for a fix that landed on friday to make it in, people keep bugging me about it :)
[15:35] <doko> seb128, I'm not -release, and only doing the ftbfs fixes
[15:36] <seb128> doko, thanks for approving the build fixing, that's useful ;-)
[15:36] <seb128> we just need a release team member as well to approve the other uploads...
[15:44] <Laney> well, my ported indicator-session seems to mostly work so I'll do some queue reviews now and tidy that up tomorrow
[15:45] <seb128> Laney, thanks
[15:45]  * Laney rejects 3 of the 4(!) friends in the queue
[15:45] <seb128> joys of daily landing :p
[15:46] <ogra_> poor friends
[15:46]  * Laney the loner
[15:46] <ogra_> you kept one at least :)
[15:47] <kenvandine> :)
[15:52] <skellat> Hello.  I've got a Fix Committed flag on Launchpad Bug #1158431 and haven't seen yet if the new package has built and hit the queue to fix this bug for Xubuntu.
[15:52] <ubot2> Launchpad bug 1158431 in shimmer-themes (Ubuntu) "lightdm graybird login issues on raring" [Undecided,Fix committed] https://launchpad.net/bugs/1158431
[15:55] <ochosi> skellat: i set it to "fix committed" because the fix is in git (this is what mr_pouit and i settled on for bug management)
[15:56] <ochosi> skellat: so i guess the bug status should be changed to whatever the "general public" here sees as fit
[15:56] <skellat> Crud
[15:56] <skellat> ochosi: Let us take this back to #xubuntu-devel
[15:56] <ochosi> skellat: sure
[15:57] <cjwatson> fix committed for "fix is in version control" is generally fine
[15:57] <cjwatson> at least for development releases.  rules are different for stable updates
[15:57] <skellat> Okay
[15:58] <skellat> Since our developers are tied up it looks we need a sponsor too to navigate this in
[15:58] <ochosi> yes, please
[15:58] <ochosi> it's a bit unfortunate that i'm only the artwork lead and can't update my own packages...
[16:05] <ogra_> bdmurray, the seed change and upload for g-c-c-u happened i didnt edit the changelog, can you close the bug by hand ?
[16:05] <bdmurray> ogra_: will do
[16:05] <ogra_> thx
[16:07] <slangasek> seb128: release notes> https://wiki.ubuntu.com/RaringRingtail/TechnicalOverview, unfortunately it went out very bare for the desktop at beta time...
[16:07] <slangasek> Laney: I was no longer looking at friends; happy for someone else to take it
[16:08] <seb128> slangasek, hum, yeah, not a lot of desktop there ... is that the right page to edit toward release?
[16:08] <doko> slangasek, could you look at the two python3-defaults uploads? RAOF doesn't seem to be there
[16:08] <slangasek> seb128: "joys of daily landing" - well, I think there's a bug in how the autolanding code handles the unapproved queue, it seems to think that because it hasn't reached the archive yet it needs to upload *again* with no other changes
[16:09] <seb128> slangasek, that's another side effect of "can't get content of the syncs in the queue" :-(
[16:09] <slangasek> seb128: for the moment, yes - we usually refactor between beta and release, but we haven't started that yet so anything you put there now will be ported over
[16:09] <seb128> slangasek, but yeah, agreed it's a bug
[16:09] <slangasek> doko: I'm about to step away from the keyboard for a bit, but can look when I return.  This is for precise/quantal?
[16:11] <doko> slangasek, yes
[16:13] <antarus_> slangasek: wow this nvidia thing is really screwed up ;)
[16:20] <cjwatson> seb128: you can't get the content but you can get their versions easily enough
[16:20] <cjwatson> seb128: after all, the queue tool shows that
[16:21] <Laney> all of the friends had genuine changes
[16:22] <seb128> cjwatson, the version doesn't tell us if there is an actual diff between the version in the queue and the current daily though :-(
[16:23] <seb128> or we would need to add special logic to reconstruct the version of the queue from the vcs to debdiff it
[16:23] <Laney> can't you map from that back to a vcs tag?
[16:24] <Laney> Have you seen this behaviour though? I don't believe friends to be a case of it, like I just said
[16:25] <seb128> Laney, we could, but same, we would move from a standard workflow to a special logic that needs to trace back to the vcs used and do diffs in there
[16:25] <Laney> or you know which PPA you uploaded to and the package name so you can easily download from that
[16:25] <seb128> the version is not in the ppa anymore
[16:25] <seb128> it got replaced by the new daily
[16:25] <seb128> since that's a daily ppa
[16:25] <seb128> and ppas don't keep deprecated versions
[16:25] <Laney> you're deciding whether to push a new daily at this point aren't you?
[16:26] <Laney> so this is before the upload
[16:26] <seb128> no
[16:26] <seb128> we always push dailies in the ppa
[16:26] <Laney> even if there's no change?
[16:26] <seb128> even if we don't copy to distro
[16:26] <seb128> yes
[16:26] <seb128> because that's part of ensuring that things keep building
[16:26] <didrocks> hum, what do you mean?
[16:26] <seb128> no?
[16:26] <didrocks> that's not the case at all
[16:26] <seb128> ok
[16:27] <didrocks> only component which have a diff between the vcs and latest published version in distro are rebuilt
[16:27] <didrocks> components*
[16:27] <seb128> didrocks, what was the reason you couldn't avoid queuing new versions in freeze time when there is no diff?
[16:27] <Laney> I'm not sure I believe that does happen
[16:27] <didrocks> seb128: I told "published version"
[16:27] <Laney> do you have evidence?
[16:27] <didrocks> seb128: if I want to support the "things in the queue", there is a little bit of logic needed
[16:28] <didrocks> from launchpad api to get what's in the unapproved queue
[16:28] <didrocks> then, trace back to something downloadable
[16:28] <Laney> we'd see it for every component every day if it was, surely?
[16:28] <didrocks> because as it's a sync, you can't download the source
[16:28] <Laney> and we don't, at least AFAIK ...
[16:28] <didrocks> so trace that back to the ppa
[16:28] <didrocks> and download from it
[16:28] <didrocks> and making a second diff against it
[16:28] <didrocks> so quite a little bit of work, but doable as told
[16:29] <seb128> didrocks, right, that's exactly what I was saying (the sync, can't download the source, need extra logic, bits)
[16:29] <didrocks> when we evocated the idea with seb128, we decided it didn't worth the pain as the queue is normally reviewed within 24 hours
[16:29] <didrocks> (and this is only for things having stalled changes)
[16:30] <didrocks> 18:26:18     seb128 | we always push dailies in the ppa
[16:30] <didrocks> 18:26:24      Laney | even if there's no change?
[16:30] <didrocks> 18:26:26     seb128 | even if we don't copy to distro
[16:30] <didrocks> 18:26:31     seb128 | yes
[16:30] <didrocks> seb128: I think people would think from that that we are rebuilding everything ^
[16:30] <didrocks> which is not the case ;)
[16:30] <didrocks> only the things not published in distro
[16:30] <didrocks> (which has a change)
[16:31] <Laney> so you could have <daily release> <change> <daily release stuck in queue> <daily release> <daily release ...> ?
[16:31] <seb128> yeah, that was not really clearly written
[16:34] <didrocks> so yeah, it's possible to skip it, but the launchpad api with sync will make it quite some extra work
[16:34] <Laney> If it's like ^, you might be able to get away with just comparing versions
[16:34] <didrocks> so I think we just need to assess if reviewed in freeze period not being in 24 hours is that annoying compared to "reject olds"
[16:34] <didrocks> Laney: what version do you want to compare?
[16:35] <seb128> Laney, comparing versions don't tell you if you have actual content change between daily_stuck_in_queue and new_daily
[16:35] <didrocks> right
[16:35] <Laney> if there are changes then you don't need to check the queue
[16:35] <didrocks> as we don't require debian/changelog change
[16:35] <seb128> Laney, how do you determine if there are changes?
[16:36] <Laney> a commit since the last daily release
[16:36] <didrocks> Laney: doesn't work
[16:36] <didrocks> Laney: that was the old logic I removed
[16:36] <Laney> how the bot decides whether to do a daily release or not
[16:36] <didrocks> like, you can have a manual upload
[16:36] <didrocks> then backport that to the vcs
[16:36] <seb128> Laney, it compares/diff to the archive version
[16:36] <didrocks> so comparing commit revisions is way more complex than it sounds
[16:36] <didrocks> comparing the diff from the archive is version 2
[16:37] <didrocks> and the only reliable way
[16:37] <Laney> I thought that stuff put it into manual mode
[16:37] <seb128> Laney, which is the "canonical" version
[16:37] <didrocks> Laney: it's in manual if the version in distro is more advanced than the release
[16:37] <didrocks> (well, it doesn't put it manual, it skips it + got the component hilighted)
[16:38] <didrocks> basically, as seb128 told, the reference version is always what is published in distro
[16:38] <didrocks> that's the gold rule to ensure we don't loose anything
[16:38] <didrocks> (and yeah, it's way more complicated than just comparing commits, the whole code being 3000 lines prooves it ;))
[16:39] <Laney> I thought it was something like "if there's something in the distro that I didn't upload, then a human needs to take a look"
[16:39] <didrocks> Laney: yeah, it's hilighed and need to be ported back to the vcs
[16:39] <didrocks> but if you wanted to compare commits numbers to know that "something is new" or not
[16:40] <didrocks> you need to count the number of potential manual uploads
[16:40] <didrocks> (sometimes, there is more than one in a raw…)
[16:40] <didrocks> and rely on the fact there is one commit per backport
[16:40] <didrocks> which doesn't always happened as per experience ;)
[16:40] <didrocks> so reliable on just commits to think "there is something new to consider for release" doesn't work
[16:41] <Laney> so what's the issue? that manual uploads which get stuck in the queue can mess up the machinery?
[16:42] <didrocks> Laney: I meant that if there has been 3 manual uploads in a raw
[16:42] <didrocks> and you expect then 3 backport commits
[16:42] <didrocks> + 1 commit for the release
[16:42] <didrocks> so, you are telling "only if the diff is 5 commits, there is something to release"
[16:43] <didrocks> now, imagine the 3 manual uploads were done in a short time
[16:43] <didrocks> and someone only backport those 3 manual uploads in one commit
[16:43] <didrocks> you are waiting for 2 additional commits to tell "there is something to release", even if it's not true
[16:43] <didrocks> as the 3rd commit had something significative
[16:43] <Laney> I don't know why we're counting commits or diffing - isn't that all done by a human when they reconcile it and manually kick a daily release?
[16:43] <didrocks> that's why counting commits doesn't work
[16:44] <didrocks> Laney: you proposed counting commits
[16:44] <didrocks> that's what I did for a while
[16:44] <didrocks> and it doesn't work, hence the diff today :)
[16:44] <infinity> rtg_: It'll migrate its way out of proposed when I do the next d-i upload.
[16:44] <Laney> no, I proposed seeing if there were /any/ commits
[16:44] <didrocks> and I explain you why it doesn't work :p
[16:44] <didrocks> Laney: so, if there is any commits
[16:44] <didrocks> Laney: imagine, you have a manual upload
[16:44] <rtg_> infinity, ack
[16:44] <didrocks> then, you have to put that back in the vcs, right?
[16:45] <didrocks> so you have /any/ commits, being one
[16:45] <didrocks> and you daily release exactly the same content
[16:45] <didrocks> than the manual upload
[16:46] <cjwatson> you know I'm not totally certain you can't get hold of the source by URL hacking
[16:46] <cjwatson> it must still be in the librarian
[16:47] <didrocks> cjwatson: that would help to not hack around to get a version from the ppa as a source
[16:48] <Laney> yeah that's right --- I had a working assumption that this doesn't happen often enough to make it a big problem ;-)
[16:48] <didrocks> Laney: you will notice that -V is using latest version published in distro so that we don't miss anything :)
[16:49] <didrocks> Laney: it did happen and it's not right that we reupload if someone did a manual upload, that's when I introduce diff as a source of truth
[16:50] <didrocks> (which makes more sense, it's authorative)
[16:50] <Laney> anyway, if this does indeed happen before you upload again to the PPA then you can trace back because you know which PPA it came from
[16:50] <didrocks> Laney: yeah, the question is "it's adding quite a bunch of logic, is it something which should be supported?" (as it uploads with the right -V and we don't miss anything)
[16:51] <didrocks> the other day, we went to the "no" conclusion with seb128, I'm happy to look at it back
[16:51] <Laney> like I said earlier I haven't personally seen repeated uploads with the same content, so I'm not convinced it happens very often
[16:52] <didrocks> Laney: btw, the commit I removed the "count commits" check is at http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/276
[16:52] <seb128> Laney, right, the conclusion was "we don't have so many hard freezes, and the issue only happen if reviews take over 1 day in hard freeze time"
[16:52] <seb128> and the "issue" is small, we just have outdated versions in the queue
[16:52] <seb128> the most recent one will be published when accepted
[16:52] <seb128> so it's just a small annoyance
[16:53] <Laney> in the friends case you'd have pushed them all anyway because there were commits every day
[16:53] <didrocks> I think there was one since start of the hard freeze
[16:54] <didrocks> one indicator thing
[16:55] <Laney> seb128: that glib patch is funny
[16:55] <seb128> Laney, talk to desrt :p
[16:55] <didrocks> desrt is funny ;)
[16:56] <seb128> Laney, they went "no, you can't do that anymore" but it broke bindings so desrt agreed to put an exception for the bindings until they are fixed
[17:05] <cjwatson> Laney: your agda and agda-stdlib uploads should be available for syncing now
[17:05] <Laney> woot
[17:12]  * Laney retires to the climbing centre
[17:16] <seb128> Laney, thanks for the reviews, have fun!
[17:23] <cjwatson> Laney: oh, we'll need geniplate, of course ...
[17:23] <cjwatson> oh, it's in raring-proposed already
[17:23] <cjwatson> fine
[17:36] <zul> can someone reject the horizon upload please?
[17:37] <ScottK> zul: Done
[17:38] <zul> thanks
[17:57] <rbasak> I don't understand why the armhf binary for samba4 was rejected. Help? https://launchpad.net/ubuntu/+source/samba4/4.0.0+dfsg1-1ubuntu1/+build/4482847
[18:02] <ogra_> rbasak, looks like a launchpad bug ... (iirc there is one open thatr cjwatson opened for a similar issue i once had years ago)
[18:02] <ogra_> https://launchpadlibrarian.net/136881857/upload_4482847_log.txt
[18:02] <ogra_> INFO Rejection during accept. Aborting partial accept.
[18:03] <ogra_> oh, wait, binary you said ... mine was source
[18:04] <rbasak> Thanks. But does someone need to do something? :)
[18:04] <ogra_> i would ask an LP person in #launchpad
[18:05] <ogra_> it looks definitely buggy
[18:05] <ogra_> (if the other bianries just got accepted)
[18:05] <ogra_> *binaries
[18:14] <infinity> rbasak: It's an LP oops, retrying is the simplest way forward.
[18:15] <ogra_> infinity, retrying for a binary ?
[18:15] <ogra_> how would he do that
[18:15] <infinity> Retrying the build...
[18:15] <infinity> Which I did.
[18:15] <ogra_> ah
[18:31] <rbasak> infinity: thanks!
[18:39] <rtg_> can I get some love for Raring linux-firmware and pciutils ?
[18:44] <slangasek> antarus_: nvidia> you mean the fact that we have to ship a billion upstream versions of the driver to make sure everybody has one that works?
[18:46] <antarus> slangasek: no, 295 => 300
[18:46] <antarus> slangasek: not saying there was anything else you could have done
[18:46] <antarus> slangasek: just that we had a fun morning ;_)
[18:47] <mdeslaur> antarus: what happened?
[18:48] <antarus> mdeslaur: well 295 doesn't support RANR, 304 does
[18:48] <antarus> we have some bits that need to be flipped to migrate
[18:48] <antarus> been plannign the migration for about 6 weeks ;)
[18:49] <mdeslaur> antarus: ah, I see...yeah, quite unfortunate, but we didn't have much of a choice
[18:52] <antarus> I know ;)
[18:59] <slangasek> doko: why does this python3-defaults upload include so much reordering of debian/rules?
[18:59] <slangasek> doko: AFAICS, the only bit related to the bug is a one-line change, and all the rest should be omitted from the SRU:
[18:59] <slangasek> -       dh_link -ppython3 /usr/share/python3/py3versions.py /usr/bin/py3versions
[19:00] <slangasek> +       dh_link -ppython3-minimal /usr/share/python3/py3versions.py /usr/bin/py3versions
[19:26] <Laney> cjwatson: yeah, I uploaded that one straight away
[21:06] <doko> rejected and reuploaded python3.3 to fix the testsuite-dbg autopkg test
[22:41] <doko> whoever did accept the python2.7 upload yesterday, could you accept the python3.3 upload too?
[23:12] <infinity> doko: That was me, I'll look at it tonight.
[23:13] <doko> infinity, thanks, afk now