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