[02:53] <cjwatson> shadeslayer: you could unstick a chunk of KDE from utopic-proposed by making kdepimlibs b-d on libboost-graph1.55-dev rather than libboost1.55-graph-dev, I think
[03:05] <infinity> cjwatson: Build-depending on packages that actually exist is so last year.
[03:06] <infinity> cjwatson: Erm, I also don't see that issue?
[03:06] <infinity> cjwatson: It seems to build-dep on libboost-graph1.55-dev and then FTBFS.
[03:06] <infinity> Oh.
[03:06] <infinity> I'm looking at kdepim, not pimlibs.
[03:07] <infinity> I'll just fix that for them.
[03:28] <infinity> shadeslayer: Nevermind cjwatson above, I uploaded the fix.
[03:35] <ScottK> shadeslayer can still fix it in bzr (unless you did that too).
[03:36] <infinity> ScottK: I did.
[03:36] <ScottK> Great.  Thanks.
[03:37] <infinity> ScottK: I try to be a good little kubuntu member when I touch your packages. :P
[03:37] <ScottK> Appreciated.
[03:37] <infinity> Even if I haven't actually booted or looked at the UI in a couple of years...
[03:37] <ScottK> ;-)
[03:38] <ScottK> We're going to give having our branches integrated with Debian's on alioth a shot.
[03:38] <ScottK> That'll make it slightly more fun.
[03:39] <infinity> Hrm.  That could be interesting for any Ubuntu people without Alioth accounts.
[03:39] <infinity> In practice, I suspect not a big deal, as very few (core-)devs touch your packages, and those that do probably have at least alioth guest accounts.
[03:40] <infinity> And, of course, if you're careful to make sure out-of-band uploads don't get dropped, it's a moot point.
[03:40] <ScottK> It's not like they're hard to get.
[03:40] <ScottK> Besides, if Canonical's moving stuff like juju off of LP, I don't feel bad about experimenting with going as far as Debian.
[03:41] <RAOF> Oh, are we moving juju off LP?
[03:42] <ScottK> Already did.
[03:42] <ScottK> See Jorge's blog post.
=== plars is now known as plars-away
[05:57] <rbasak> infinity, ScottK: so what's the best way for an infrequent uploader to notice when a particular package has a maintained external VCS tree? Just the Vcs-* headers, or something else?
[05:57] <rbasak> (since the Vcs-* headers are often inherited from Debian and not replaced)
[05:58] <ScottK> rbasak: If there's a separate VCS you ought to worry about, then they should be replaced.
[05:58] <ScottK> If they aren't, I think it's not your problem.
[05:58] <rbasak> ScottK: so if I see alioth, I might assume that they're not replaced. If you use alioth that's a problem though right?
[05:59] <ScottK> Good point.
[06:01] <rbasak> I wonder if there's any possibility for tooling to detect the field and warn me somehow. As it'd be an unusual case for me, I'm worried that I'll forget to even look, since the majority of cases when I do look I won't need to do anything. It'd be an easy mistake to make.
[06:01] <rbasak> (assuming that I apply/get core dev eventually, which I don't have now)
[06:02] <rbasak> I'm thinking of something like a central srcpackage->bool mapping, with yes-uses-vcs or no-does-not-use-vcs, and some kind of pre-dput hook which forces me to say --yes-i-know-about-the-vcs when my ~/.something tells it to require that, that I might turn on.
[06:11] <ScottK> If you apt-get source, you get a warning.
[08:37] <shadeslayer> rbasak: ScottK tbh infrequent uploaders frequently tend to forget to update bzr when doing KDE packages, so it's not something new, we'll keep syncing the packaging to git, should we move to alioth
[08:37] <Laney> shadeslayer: can you make it writable by Debian at least? :-)
[08:59] <infinity> rbasak: To be honest, while I try to be a good VCS citizen where and when I can, it's still the case that source packages are authoritative and it's the responsibility of VCS users to make sure they check for unmerged uploads.
[09:00] <infinity> rbasak: So, while it's good to do as you do and try to play nicely, it's also not strictly speaking your responsibility to do so when doing a one-shot fix for something someone else broke. :P
=== doko_ is now known as doko
[09:21] <seb128> hey there, I've a SRU question
[09:22] <seb128> the unity trusty SRU has one of its bugs (the ones listed on the changelog and on http://people.canonical.com/~ubuntu-archive/pending-sru.html) which was wrongly listed
[09:22] <seb128> is there a way to drop it/make it obvious to the SRU team that it shouldn't block the SRU?
[09:22] <seb128> everything else got verified/is green on the report
[09:23] <seb128> that one just happen to be listed in the changelog but not have the actual diff included, so it's not going to be either verified or failed
[09:42] <xnox> mark it verified-done & later reopen saying "above doesn't actually fix above bug #"
[09:42] <xnox> or fork the bug, and close the one mentioned in the changelog or some-such.
[09:42] <xnox> i think i did reopens a few times in the past.
[09:43] <seb128> k, let's do that
[09:43] <seb128> xnox, thanks
[09:43] <infinity> seb128: Is this 1313280?
[09:44] <seb128> infinity, yes
[09:44] <infinity> seb128: Right, how about I just release the package, and you can reset the tasks and tags. :P
[09:45] <seb128> infinity, +1
[09:45] <seb128> thanks
[09:45] <infinity> seb128: And please get them to retroactively repair the old changelog entry in bzr so that version no longer claims it fixes that bug after they upload the next.
[09:45] <seb128> can't change history!
[09:46] <infinity> You can when history is wrong!
[09:46] <seb128> so you can ... ;-)
[09:48] <shadeslayer> infinity: cjwatson: thx
[09:48]  * shadeslayer points out that kdepimlibs shouldn't have been uploaded btw
[09:48] <infinity> shadeslayer: Hrm?
[09:48] <infinity> shadeslayer: A bit late now, I guess. :P
[09:48] <shadeslayer> yeah
[09:49] <shadeslayer> it's 4.13.1
[09:49] <shadeslayer> everything else is still 4.13.0
[09:49] <shadeslayer> or well, should be
[09:49] <infinity> kdepim is 4.13.1 too.
[09:49] <shadeslayer> shouldn't have been uploaded then
[09:49] <infinity> Though it's also FTBFS.
[09:49] <shadeslayer> oh
[09:49]  * shadeslayer checks
[09:50] <shadeslayer> quite weird, I always build packages locally before commiting to bzr
[09:50] <shadeslayer> ah grammar
[09:50] <infinity> seb128: Oh, wait, that bug isn't referenced in the current SRU anyway...
[09:51]  * infinity scratches his head.
[09:51] <seb128> infinity, it's on http://people.canonical.com/~ubuntu-archive/pending-sru.html
[09:51] <infinity> seb128: Yeah, I know.  But not in the current changelog entry.  Maybe there was one preceding it.
[09:51] <seb128> infinity, yeah, https://launchpad.net/ubuntu/+source/unity/7.2.1+14.04.20140513-0ubuntu1
[09:51] <seb128> which was superseeded by ubuntu2 the next day
[09:51] <infinity> seb128: Right.  So, that's already fixed.  Good deal.
[09:52] <seb128> so seems they fixed history :p
[09:52] <infinity> http://launchpadlibrarian.net/176537122/unity_7.2.1%2B14.04.20140513-0ubuntu1_7.2.1%2B14.04.20140513-0ubuntu2.diff.gz
[09:52] <infinity> Yeah, the fixed history.
[09:52] <infinity> Lovely.
[09:52] <infinity> SRU released.
[09:52] <seb128> thanks
[09:52] <infinity> Bug not autoclosed.
[09:52] <infinity> Life is good.
[09:52] <seb128> how come the tracker still had it?
[09:52] <infinity> I guess it tries to be clever by parsing all versions between A and B.
[09:52] <infinity> Rather than a diff between A and B.
[09:52] <seb128> that makes sense
=== jhodapp|afk is now known as jhodapp
[11:51] <psivaa> xnox: hey, i see bug 1309617 is assigned to you and i have an install which behaves somewhat the same way as described  in it. this also affects the server smoke tests,
[11:51] <psivaa> just fyi, i should be able to reproduce fairly reliably if you'd need any more information on it
=== pete-woods is now known as pete-woods-lunch
=== pete-woods-lunch is now known as pete-woods
=== oSoMoN_ is now known as oSoMoN
[13:59] <pitti> I'm about to upload the first set of utopic langpacks; is there any reason why this is a bad time?
[13:59] <pitti> cjwatson, infinity, ogra_ ^
[14:01] <cjwatson> I know of nothing that should stop you
[14:05] <pitti> I don't see anything either (no test rebuild planned, over-busy buildds, etc.), but I thought I'd check
[14:17] <ogra_> pitti, unlikely to break anything in touch i guess
[14:18] <pitti> ogra_: right, I meant more in terms of general traincon-0 or diff noise, etc.
[14:20] <ogra_> thats all fine, its non intrusive and we can ignore langpacks in the diff
[14:20] <pitti> ogra_: ack, thanks for confirming
[15:33] <cjwatson> stgraber: could you add an appropriate cunit task to bug 1275656?
[15:33] <stgraber> cjwatson: oh right, sure
[15:35] <stgraber> cjwatson: thanks!
[15:35] <cjwatson> np
[15:36] <stgraber> cjwatson: did you accept it in main directly?
[15:37] <cjwatson> no, I just used sru-review
[15:37] <cjwatson> feel free to override once published
[15:37] <stgraber> ok, will do that then, thanks
[15:37] <stgraber> rcj: ^ so hopefully in a couple of hours open-vm-tools-lts-trusty will finally build :)
[15:38] <rcj> stgraber, cjwatson: thank you both
[17:17] <slangasek> barry: so discussing with sil2100, while the autopilot test .debs now correctly depend on python-autopilot if needed, it seems there's some fragility there because people aren't paying close attention to that stack (leading to u-a-l problems)
[17:18] <slangasek> barry: are the TODOs from https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap still on the radar?
[17:23] <barry> slangasek: well, i'm happy to keep helping with those, but they aren't on my radar.  dialer-app is a good example.  my branch works for me locally but so far hasn't passed jenkins.  i haven't touched the other todos (address-book actually was merged afaik)
[17:25] <slangasek> barry: ok; seems like it would be a good idea to follow through on these
[17:26] <barry> slangasek: it should be easier now (hopefully) to figure out the long tail of ports needed, i.e. dependency on autopilot-legacy
[17:26] <barry> slangasek: i'll carve out some time to take a look
[17:35] <cjwatson> I just noticed that colord/i386 didn't build due to B-D-I: argyll; perhaps somebody should revisit bug 821883?
[17:43] <infinity> RAOF: Care to champion 821883?
[17:43] <infinity> RAOF: (Or make colord not need it, your call)
[17:45] <rcj> stgraber, with cunit built, when would open-vm-tools-lts-trusty build?  Just don't know how to tell if it's waiting or when it's stuck.
[17:46] <jdstrand> fyi, I changed the override for ninja-build prior to oxide Build-Depends hitting the archive
[17:46] <jdstrand> (MIR was accepted alread)
[17:46] <jdstrand> oxide is building in the security team ppa, once it is copied over, the mismatch should go away
[19:10] <stgraber> rcj: open-vm-tools-lts-trusty built and accepted, should appear on archive.ubuntu.com in the next 30min
[19:12] <rcj> stgraber, thanks
[19:50] <bdmurray> has anybody looked at the mythtv SRU for trusty? it seems more like an MRE to me.
[19:50] <bdmurray> bug 1323391
[19:55] <infinity> bdmurray: One doesn't need an MRE to do a new microversion, just to do one without extensive pain and review. :P
[19:56] <infinity> If this is bugfix only and one of us is willing to review it, there's nothing wrong with it, in theory.
[19:56] <infinity> (And if they have a testing strategy, etc)
[19:58] <bdmurray> infinity: got it
[20:00] <infinity> bdmurray: Plus, being LTS only, and mythtv being pretty much the raison d'être of mythbuntu, I can see the argument that they should perhaps be allowed to keep the flagship piece of software in a good state. ;)
[20:00] <infinity> (Again, if they have a good testing strategy, blah blah)
[20:54] <superm1> if our testing strategy needs some improvement we're happy to add something more thorough.  a majority of the validation for it has been happening upstream on an individual branch that wasn't merged until it got enough "works for me, no regressions"
[20:57] <tgm4883> infinity: bdmurray I'd like to add that we keep a daily builds PPA that pulls from that fixes branch so users can be up to date/test our packages. We suggest using the PPA, but there is still a large portion of users that install and only do updates from the "official" repos. Anything that we try to SRU would have gone to that PPA first for testing
[21:00] <tgm4883> so as superm1 said, it's tested upstream by the mythtv developers in a separate branch before getting merged to their "fixes" branch, then we pull that fixes branch (daily) and build for release on our PPA, and this SRU is to ensure that the users that only update from the official repos will still get an updated build of mythtv. I'd expect we'll do another
[21:00] <tgm4883> SRU for the 0.27 fixes branch for 14.04.2. As a policy, we will NOT do an SRU for a major mythtv version (eg. we won't do an SRU for 0.28 for 14.04.x)
[23:55] <RAOF> infinity: That would require adopting it in Debian, which I'm considering. For the moment I'll drop the argyll requirement for colord, though.
[23:56] <RAOF> infinity: ...once I work through the transition in Debian :)