[02:04] <imgbot> [03:54] <imgbot> [03:54] <imgbot> [07:57] <pstolowski> trainguards hello, can landing 012 get landed? is there still a problem with this silo?
[08:07] <ev> In case that wasn't enough to catch your eye, the CI Lab is being moved today at 1300 UTC. Expect no tests to run at this time, but no action needed on your part once services are restored. See Larry's email for the full details.
[08:16] <pstolowski> ev, ack. thanks
[08:22] <sil2100> pstolowski: let me take a look at it in the meantime
[08:24] <Mirv> pstolowski: it is landed already, it's just stuck in proposed
[08:24] <Mirv> sil2100: I asked you or robru to try to take the Oxide silo to finish on Friday, but that is essentially what's blocking 012 and others
[08:24] <Mirv> I don't now have upstream approval but I do have core dev approval
[08:25] <sil2100> Mirv: sadly, I wasn't able to take care of that, I wanted after the evening meeting but then some personal matters appeared
[08:26] <Mirv> sil2100: yeah, no problem, I just would have wanted for someone to catch up with Chris. but I think I can now land that soon with raof's ack on it.
[08:26] <Mirv> sil2100: in the morning I realized he could have noticed it better if I'd have proposed a branch in addition to just filing the bug.. but earlier I didn't even know where the Oxide packaging branch is.
[08:27] <sil2100> I actually thought this was a revert, but I see it's actually a fix
[08:27] <Mirv> sil2100: the revert would have been easy to push, but then it would have (again) broken all Click cross-compilation for vivid
[08:27] <Mirv> so that's why at the last minute I made that zoltan's suggested fix/workaround for the problem
[08:30] <Mirv> ... which then took the usual 5h to build :)
[08:30] <sil2100> ...;)
[08:36] <pstolowski> Mirv, sil2100 thanks
[09:25] <sil2100> brendand: hey! How many QA people do we have for silo testing today in the EU tz?
[09:26] <brendand> sil2100, all of them :)
[09:26] <sil2100> Good, since I see silo 007 has a fix for one of the criticals
[09:26] <sil2100> Would be nice to have this one handled
[09:28] <jibel> sil2100, I guess there is no discussion about silo 16? it's a major change and risk is very high.
[09:28] <davmor2> brendand: the correct answer then would of been None we have all gone on strike
[09:29] <sil2100> jibel: silo 16 is very important to land - very risky, but required
[09:30] <jibel> sil2100, okay, so we test it and build a separate image with just this fix?
[09:30] <jibel> s/fix/new version/
[09:30] <sil2100> For sure we'll build an image once this lands
[09:31] <sil2100> I remember on Friday someone mentioning some issues with the silo installing cleanly, but I don't remember what that was
[09:31] <jibel> sil2100, right, but just with upower 0.99?
[09:31] <sil2100> jibel, brendand, Mirv: I'll be right there on the HO
[09:31] <sil2100> Need to restart the browser
[09:32] <sil2100> hmm, no ogra on the channel!
[09:48] <mzanetti> sil2100: hi. when you have a minute, could you please assign me a silo for row 32
[09:49] <sil2100> mzanetti: sure, looking
[09:49] <sil2100> mzanetti: ah, sorry, can't do that - still waiting for silo 12 to migrate...
[09:50] <mzanetti> sil2100: ah ok. no prob.
[09:50] <sil2100> mzanetti: but the good news is: it will migrate soon!
[09:52] <davmor2> sil2100: hmmm I wonder unity-plugin-scopes:armhf from 0.5.4+15.04.20141128-0ubuntu1 to 0.5.4+15.04.20141205-0ubuntu1 in image 45 :)
[09:57]  * sil2100 checks the commitlog
[09:58] <davmor2> sil2100: http://people.canonical.com/~davmor2/scopes-all-v44.png image 44 scopes are there moving onto 45
[10:03] <sil2100> robru: hm, did you change anything in the train that made the released package versions not appear?
[10:05] <sil2100> robru: yeah, I see pkgversionlist gone from the JSON blobs
[10:05] <sil2100> robru: this breaks commitlogs...
[10:06] <sil2100> Now we can't keep track of what landed in what image ;/
[10:06] <seb128> time for revert!
[10:10] <sil2100> seb128: if you meant the train, it's not so easy anymore! ;) I would need IS to do it for me..!
[10:10] <seb128> oh?
[10:10]  * sil2100 has absolutely no control over the train deployments anymore
[10:10] <seb128> "great"
[10:11] <seb128> so you can get stuff broken but not fixed
[10:11] <sil2100> But I won't be ranting about this, did enought of that last week
[10:11] <seb128> improvements?
[10:14] <davmor2> Saviq: y u break the scopes
[10:15] <Saviq> davmor2, no me, pstolowski!
[10:16] <bzoltan> sil2100:  may I ask for a reconf - silo9
[10:16] <davmor2> Saviq: I don't care I'm blaming you, you probably told him to land it ;)  I've just confirmed though that it is definitely 45 that broken 44 works fine :)
[10:17] <sil2100> bzoltan: sure!
[10:17] <sil2100> bzoltan: what changed? :)
[10:17] <Saviq> davmor2, ah right, sorry, yes, my fault
[10:17] <sil2100> Ah, gles
[10:17] <sil2100> bzoltan: reconfiguring
[10:34]  * Mirv rerunning autopkgtests
[10:36]  * Mirv was apparently too early, tries again later
[11:14] <sil2100> Mirv: any luck? ;)
[11:15] <sil2100> davmor2: are you also doing silo sign-off today?
[11:16] <Mirv> sil2100: ^ qtdeclarative already migrated. the other autopkgtest now also finished so I expect the rest to follow inside 30 mins or so!
[11:16] <davmor2> No I'm reviewing the sanity suite adding a testcase for the scopes issue and testing the latest images
[11:16] <sil2100> davmor2: ACK, since all should be fixed once we have the new unity8
[11:16] <Mirv> sil2100: the bad news was that chrisccoulson informed the change is not wanted, and I filed bug #1400275 to summarize the whole situation. my error was also that I thought Chris was in US...
[11:16] <ubot5`> bug 1400275 in oxide-qt (Ubuntu Vivid) "Fix oxide-qt codecs dependencies (continued)" [Critical,New] https://launchpad.net/bugs/1400275
[11:17] <sil2100> He's not?
[11:17] <sil2100> Oh
[11:17] <Mirv> :)
[11:17] <davmor2> sil2100: indeed but it is still a good testcase for the future :)
[11:17] <sil2100> Damn, we should have checked
[11:18] <davmor2> sil2100, Mirv: no chrisccoulson is about 25 miles from me, if you'd of asked I could of told you that :P
[11:18] <chrisccoulson> hi :)
[11:19] <Mirv> davmor2: it's probably by luck that I didn't use the phrase "because Chris is in the US" during the meeting..
[11:19] <Mirv> chrisccoulson: hi :)
[11:19] <davmor2> chrisccoulson: hey there how is Solihull :)
[11:20] <Mirv> chrisccoulson: my next idea would be to revert the ordering change but try that RAOF's guess of using arch specific Replaces lines.. otherwise I'm out of ideas though.
[11:29] <Mirv> Saviq pstolowski: vivid 012 now migrated to release pocket too, feel free to go ahead with next landings ^
[11:29] <Saviq> Mirv, thanks
[11:29] <Saviq> Mirv, can you assign line 32 a silo please
[11:30] <Mirv> Saviq: yep, although it seems pstolowski would also want to grab unity8 again (on the last line), I wonder if it could be merged into yours or if he needs to just wait
[11:30] <Saviq> Mirv, ah indeed, merge
[11:31] <Mirv> Saviq: wow, indicator-power in silo 4
[11:31] <Saviq> um
[11:32] <Mirv> Saviq: seems pretty inactive though
[11:32] <Saviq> Mirv, indeed, I hope to land before charles and tedg wake up ;)
[11:33] <Saviq> Mirv, ok, line 32 has it all
[11:34] <Mirv> Saviq: assigned, but reconfiguring still since you added the new one
[11:34] <Saviq> Mirv, thanks
[11:35] <Mirv> Saviq: ready now
[11:35] <Saviq> Mirv, thanks
[11:41] <jibel> sil2100, nothing landed in RTM since 173?
[11:43] <sil2100> jibel: nothing, just checked the changes list
[11:44] <sil2100> Mirv, Saviq: what do you guys say for building a new vivid image to get rid of some of the breakages?
[11:44] <Saviq> sil2100, definitely
[11:44] <pstolowski> Mirv, thanks!
[11:45] <Saviq> pstolowski, actually, I left your silo request be, there's some doubts on Albert's MP
[11:45] <Mirv> sil2100: sounds like a good idea with all that migrated now
[11:45] <Saviq> pstolowski, but Mirv, feel free to assign a silo for pstolowski if you have the space
[11:45] <pstolowski> Saviq, i was going to say exactly that..
[11:45] <Saviq> we'll make sure to coordinate
[11:45] <Mirv> even my qtdeclarative crasher fixes might be happily received by some
[11:45] <pstolowski> Saviq, my silo may take a bit longer to get green light, i need tsdgeos tomorrow
[11:46] <Saviq> pstolowski, yup, I gathered as much
[11:46] <Mirv> Saviq: pstolowski: yes sure, I forgot about it. we've plenty of silos nowadays, I wonder if people are having golden image hangover...
[11:47] <Mirv> or well rtm has many silos, maybe then for vivid not all teams have a feature roadmap of what to actually implement in addition to just fixing ota-1 bugs.
[11:48] <Mirv> hmm, how did that https://code.launchpad.net/~aacid/unity8/deparment_jumping/+merge/243639 come back to the line 42... removing
[11:49] <Mirv> Saviq: I don't see it anymore on your line either
[11:49] <Saviq> Mirv, waait
[11:49] <Mirv> did the spreadsheet revert itself?
[11:49] <Saviq> Mirv, no
[11:49] <Saviq> Mirv, I split the silo up after all
[11:49] <Saviq> Mirv, as pstolowski's not gonna be ready until tomorrow at least
[11:50] <Mirv> Saviq: oh.. ok, makes sense. so, assining by ignoring conflicts.
[11:50] <Saviq> Mirv, yes please
[11:50] <Saviq> thanks and sorry for the confusion :)
[11:50] <Mirv> and pstolowski will rebuild unity8 tomorrow
[11:50] <Mirv> no problem
[11:51] <pstolowski> yup, thanks
[12:25] <brendand> sil2100, silo 16 ready to go
[12:30] <Mirv> brendand: \o/
[12:31] <Mirv> sil2100: publishing
[12:32] <Mirv> and acking a core-dev's own packaging change
[12:33] <davmor2> Saviq: for when you fix it unless there is one already https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1400296
[12:33] <ubot5`> Launchpad bug 1400296 in unity8 (Ubuntu) "No scopes are visible in the all page of the manage scopes page" [Critical,New]
[12:34] <Saviq> davmor2, it is
[12:34] <Saviq> davmor2, fixed I mean
[12:34] <davmor2> Saviq: yeah I had assumed it was :)
[12:35] <Saviq> pstolowski, can you please set the correct task statuses ↑?
[12:45] <davmor2> Saviq: thanks for updating it :)
[12:46] <pstolowski> Saviq, done
[12:51] <Saviq> pstolowski, << 8.02!
[12:53] <pstolowski> Saviq, grr. ok, fixed
[13:11] <jibel> sil2100, can you build an image with the changes to support new upower only (upower, powerd, system-settings, indicator-power) ?
[13:12] <sil2100> jibel: let me check if anything else landed
[13:12] <jibel> I didn't see anything
[13:13] <sil2100> Ok, it seems only this landed
[13:13] <sil2100> Mirv: don't publish anything for now
[13:13] <jibel> sil2100, so then we can continue landing stuff and have a build with upower 0.99 isolated.
[13:15] <sil2100> jibel: ok, ogra will kick it off in a minute
[13:16] <sil2100> We don't have imgbot so we won't get any notification though
[13:16] <jibel> sil2100, thanks
[13:29] <Mirv> sil2100: ok
[13:29] <sil2100> Mirv: once the rootfs for the new image is ready, we'll resume landings
[13:29] <sil2100> jibel, brendand: just in case, please continue with silo testing btw. - we'll simply not publish
[13:30] <sil2100> jibel, brendand: although I would recommend skipping any system-settings silos from sign-off
[13:30] <sil2100> Since we need to rebuild those now that silo 16 landed
[13:37] <davmor2> sil2100, Saviq: the fix for the scopes issue is there anyway to get that landed and in an image today, that way we could look at another promotion for vivid tomorrow image 47 is way better that anything to date :)
[13:45] <sil2100> davmor2: so all the previous issues with media playback and such are gone? :)
[13:46] <davmor2> sil2100: indeed :)
[13:46] <sil2100> \o/
[13:47] <davmor2> sil2100: it's not rebooting constantly either?
[13:48] <pstolowski> Mirv, hey, silo 12 landed but libunity-api from that silo still not in vivid?
[13:49] <Mirv> pstolowski: yes it is? https://launchpad.net/ubuntu/+source/unity-api/7.94+15.04.20141205-0ubuntu1
[13:50] <pstolowski> Mirv, ah, ok that version looks good.. somehow I still can't update to it.. mirror not up to date I guess
[13:56] <Mirv> pstolowski: probably so. I've given up mirrors to get 30min faster updates ;)
[14:33] <brendand> Mirv, what do i need to install as a minimum to build qt packages?
[14:34] <brendand> Mirv, i need to build that test app from lorn
[14:40] <Mirv> brendand: I built it on my mako from a fresh flash. let me summarize it as: apt install qtbase5-dev build-essential , export QT_SELECT=qt5 , qmake , make , ./InternetCheckercmd ( I didn't test it for real yet other than launching )
[14:55] <rsalveti> Mirv: sil2100: are you guys planning another rtm build soon?
[14:55] <rsalveti> just because of the latest upower related changes
[14:56] <sil2100> rsalveti: we had one already
[14:56] <rsalveti> hm, guess the bot is dead then
[14:56] <rsalveti> let me try downloading it
[14:56] <sil2100> rsalveti: we built a new image when these migrated, but from what ogra mentioned all platforms got imported besides krillin
[14:56] <sil2100> And we're not sure why
[14:56] <rsalveti> haha, right
[14:57] <rsalveti> that's it then
[14:57]  * sil2100 waits for stgraber to pop up
[14:57] <sil2100> ;)
[15:08] <sil2100> Ursinha: hey! I just remembered something that we need in the spreadsheet replacement that we missed most probably during all the discussions previously
[15:10] <Ursinha> sil2100: go ahead
[15:10] <Ursinha> I
[15:10] <Ursinha> I'm "listening"
[15:11] <Ursinha> :)
[15:11] <sil2100> Ursinha: we have a column in the spreadsheet, column 'S', which includes information about which packages and versions have been released with the given landing
[15:11] <sil2100> Ursinha: this is being used by many tools to get information on what landing did what
[15:12] <sil2100> (like the commitlogs)
[15:12] <sil2100> Ursinha: once a package is published from the silo, it gets included there in the format "source_name=1.2.3"
[15:12] <sil2100> Currently it's space separated
[15:16] <sil2100> plars: btw. the full lab move is not happening today, right?
[15:17] <plars> sil2100: no, it IS happening today
[15:18] <sil2100> plars: oh, ok, since I saw an e-mail from psivaa_ mentioning it was postponed
[15:18] <plars> sil2100: postponed from last week
[15:18] <sil2100> Aaaaah, crap, ok
[15:18] <sil2100> I think I was really sleepy when I read that
[15:25] <Ursinha> sil2100: so you're saying that is information about the sources that were published to the main archive?
[15:25] <Ursinha> just so I can understand when is that information used
[15:26] <sil2100> Ursinha: yes, information about what version of which package this silo has released to the archive after publishing
[15:27] <Ursinha> sil2100: and that's used after the landing is completed and the silo is gone
[15:27] <sil2100> Basically yes
[15:30] <Ursinha> sil2100: so that is already part of the ticket information, if a package in a silo was published I can say for sure that it was the latest version of that package in the silo PPA, right?
[15:32] <sil2100> Ursinha: yes - if this information is persistent even after the silo is freed and accessible by some API, then I have all we need
[15:32] <sil2100> kenvandine: hey!
[15:32] <kenvandine> hey sil2100
[15:33] <sil2100> kenvandine: since silo 16 landed, I think we need to rebuild one of the 2 silos with system-settings
[15:33] <sil2100> kenvandine: which one would you like to land first?
[15:33] <kenvandine> cool!
[15:33] <kenvandine> 4
[15:33] <kenvandine> i'll do a rebuild
[15:33] <sil2100> Let's set the other one to untested then, to make sure we don't pick it up by accident
[15:34] <sil2100> Done
[15:34] <sil2100> kenvandine: thanks :)
[15:34] <Ursinha> sil2100: :) can you have a look at the spreadsheet and tell me if there are any other cases like that? just so we can avoid surprises on missing features we overlooked
[15:36] <sil2100> Sure, I suppose those are all the cases from my side, need to think about if anyone else was using it as well
[15:38] <kenvandine> sil2100, oh... it hasn't been merged yet
[15:38] <kenvandine> i'll need to rebuild again
[15:39] <sil2100> huh?
[15:39] <sil2100> silo 16?
[15:39] <sil2100> hmmm
[15:39] <kenvandine> sil2100, yeah, it's still in proposed and not merged
[15:40] <sil2100> CRAP
[15:40]  * sil2100 checks that
[15:41] <sil2100> kenvandine: so there seems to be a problem with it, looking at update_output.txt now
[15:42] <kenvandine> uh oh
[15:42] <sil2100> popey: what issues did you have with installing silo 16?
[15:42] <sil2100> popey: you mentioned it was 'non-trivial'
[15:42] <kenvandine> i think you have to install it in the chroot from recovery or something
[15:43] <sil2100> leading: upower,ubuntu-system-settings
[15:43] <sil2100>     * armhf: account-plugin-ubuntuone, firefox-testsuite, gnome-control-center, gnome-session-bin, gnome-settings-daemon, indicator-bluetooth, libonline-accounts-plugin-dev, powerd, ubuntu-desktop-next, ubuntu-push-autopilot, ubuntu-system-settings, ubuntu-system-settings-online-accounts, ubuntu-system-settings-wizard, ubuntu-touch, unity-control-center, unity-control-center-signon, unity-scope-click, unity-settings-daemon
[15:44] <sil2100> hmmm
[15:44] <sil2100> Mirv, robru: ^ don't publish anything for now
[15:47] <kenvandine> sil2100, ok, now silo 4 won't build because it needs the merge of the upower branch
[15:47] <kenvandine> i'll just sit tight and rebuild after i see that is sorted out
[15:49] <sil2100> I wonder what's going on
[15:54] <popey> sil2100: pmcgowan has a guide
[16:00] <brendand_> Mirv, 22 does seem to makes things better but there's still some curious behaviour i'm unsure of
[16:00] <brendand_> lpotter, are you around?
[16:00] <pmcgowan> silo 16 landed?
[16:01] <brendand_> pmcgowan, yes
[16:01] <pmcgowan> kenvandine, did you see my comment, it all worked fine and helps greatly but settigns till processes events on wakeup, just many fewer it seems
[16:01] <pmcgowan> brendand_, good
[16:02] <pmcgowan> kenvandine, I wonder if we need to also filer those events in settings, throw all but the last one out or something
[16:02] <pmcgowan> filter
[16:03] <sil2100> pmcgowan: actually it didn't land yet
[16:04] <sil2100> It's released, but blocked in -proposed
[16:04] <pmcgowan> ok
[16:06] <sil2100> kenvandine: I think it might be related to libupower-glib3 :|
[16:06] <kenvandine> pmcgowan, yeah, not sure what's happening there
[16:06] <sil2100> kenvandine: libupower-glib1 changed to libupower-glib3 and all the rdeps weren't rebuilt
[16:06] <kenvandine> we can debug that further, it might not be related
[16:06] <kenvandine> sil2100, yeah
[16:06] <pmcgowan> kenvandine, I suspect we get some set of power events, just a reasonable number
[16:06] <sil2100> So those might now be uninstallable on rtm
[16:06] <kenvandine> but there shouldn't be many in rtm?
[16:08] <kenvandine> sil2100, my build failure is because to build with the new upower, it needs that branch that hasn't merged yet
[16:08] <sil2100> account-plugin-ubuntuone, firefox-testsuite, gnome-control-center, gnome-session, gnome-session-bin, gnome-settings-daemon, indicator-bluetooth, libonline-accounts-plugin-dev, powerd, ubuntu-desktop-next, ubuntu-push-autopilot, ubuntu-session, ubuntu-system-settings, ubuntu-system-settings-autopilot, ubuntu-system-settings-online-accounts, ubuntu-system-settings-online-accounts-autopilot, ubuntu-system-settings-wizard, ubuntu-touc
[16:08] <kenvandine> so it's trying to build silo 4 with upower 0.99
[16:09] <kenvandine> but without the fix to build with upower 0.99
[16:10] <seb128> sil2100, kenvandine, there is gnome-session gnome-control-center gnome-settings-daemon unity-settings-daemon unity-control-center which are using -glib1 in the rtm serie
[16:10] <kenvandine> why are those even in the rtm series?
[16:10] <seb128> dependencies
[16:11] <seb128> like unity8 uses unity-schemas which comes from unity7 which depends on u-c-c
[16:11] <seb128> well, making that one up
[16:11] <seb128> but it's things like that
[16:11] <kenvandine> understood
[16:11] <kenvandine> surprised about gnome-session and gnome-control-center
[16:11] <seb128> well
[16:12] <kenvandine> i guess when we checked the rdepends, we checked it from an rtm device
[16:12] <kenvandine> maybe we don't have all of those for armhf?
[16:12] <seb128> we do
[16:12] <seb128> I just built the list I gave you by running rdepends on my krillin rtm
[16:18] <om26er> renato___, Hi!
[16:18] <om26er> renato___, I am testing silo for bug 1390128
[16:18] <ubot5`> bug 1390128 in Canonical System Image "[address-book] is stuck on contacts sync dialog & becomes unusable" [Critical,Confirmed] https://launchpad.net/bugs/1390128
[16:19] <om26er> renato___, with the bug fixing silo step 7 is a bit different. Now the sync dialog does not appear at all. Is that expected ?
[16:24] <sil2100> kenvandine: we need the all i386 dependencies resolved as well
[16:24] <sil2100> kenvandine: will you take care of pushing all package rebuilds to the rtm archive?
[16:26] <sil2100> kenvandine: I can give you a silo, but I suppose we can just push that directly to the archive
[16:30] <kenvandine> sil2100, isn't there a way to create a silo just to trigger rebuilds?
[16:31] <sil2100> kenvandine: sadly, you would have to dput those to the silo PPA directly, or submit no-change merges etc.
[16:31] <kenvandine> i need to step away for a few, bbs
[16:32] <sil2100> kenvandine: so I guess it's faster to just dput to the archive, since you're a core-dev :)
[16:38] <renato___> om26er, the dialog only apppear at the first time if there is no contacts
[16:38] <renato___> om26er, if you create a contact the dialog will not appear anymore
[16:39] <om26er> renato___, aah, ok.
[16:47] <sil2100> Ok, maybe in the meantime I'll try resolving those
[16:49] <seb128> ^ how do I talk to "QA" about testing that one?
[16:49] <seb128> it's not really something that can be tested
[16:50] <seb128> the change makes the package build generate a .pot for launchpad to import
[16:50] <seb128> so you can't really "test" that on the device
[16:50] <seb128> I tried to explain that in the test plan column, but feel free to ping me if you have questions
[17:04] <seb128> om26er, ^ do you know?
[17:07] <kenvandine> sil2100, so no udd branches for 14.09?  i need to fetch sources the old fashion way?
[17:07] <om26er> seb128, no, not really, however brendand_ may know
[17:08] <brendand_> seb128, i think it's clear
[17:08] <seb128> brendand_, ok, thanks
[17:16] <sil2100> kenvandine: I would do apt-get source normally, and deal with bzr later ;)
[17:16] <sil2100> (if needed)
[17:16] <kenvandine> yeah, figured
[17:17] <kenvandine> but then i have to add rtm to my sources :)
[17:17] <kenvandine> i'll figure it out :)
[17:18] <sil2100> You mean, to dput.cf?
[17:18] <kenvandine> i bet we have a script for this sort of thing
[17:18] <kenvandine> no...
[17:18] <kenvandine> to checkout the source
[17:18] <kenvandine> not checkout, download :)
[17:19] <kenvandine> i wonder if any of those needed changes when they did the transition in vivid
[17:19] <sil2100> We can try building this in a silo PPA first then
[17:19] <sil2100> To make sure
[17:19] <kenvandine> yeah, lets do that
[17:19] <kenvandine> can you create me a silo?
[17:20] <sil2100> kenvandine: sure, doing :)
[17:20] <kenvandine> thx
[17:21] <sil2100> kenvandine: assigned!
[17:22] <kenvandine> thx
[17:35] <boiko> trainguards, can I get rtm silo 003 reconfigured? I added a new component there
[17:35] <robru> boiko: on it
[17:39] <boiko> robru: thanks!
[17:39] <robru> boiko: you're welcome!
[17:46] <sil2100> kenvandine: any luck? :)
[17:47] <kenvandine> well, i just had my first upload to the ppa rejected :/
[17:47]  * sil2100 doesn't see any packages in teh silo
[17:47] <kenvandine> bad distro series 14.09?
[17:47] <kenvandine> should i just set that to utopic?
[17:47] <sil2100> kenvandine: remember to suffix the version with rtm
[17:47] <sil2100> hm, should work
[17:47] <sil2100> Are you pushing to the ubuntu-rtm PPA for sure?
[17:48] <kenvandine> well, i was versioning it like an SRU... since there are updates in utopic that are later
[17:48] <kenvandine> oh... i copied the dput line from LP
[17:48] <kenvandine> forgot those are wrong
[17:48] <sil2100> kenvandine: yeah ;)
[17:48] <sil2100> kenvandine: well, I usually do it like this:
[17:48] <kenvandine> what should it look like?
[17:48] <sil2100> kenvandine: if the ubuntu version is 0ubuntu3, I change it to 0ubuntu3rtm1
[17:48] <sil2100> Not sure if that's super correct though :)
[17:48] <kenvandine> ok
[17:49] <kenvandine> i did 3.9.90-0ubuntu13.1
[17:49] <kenvandine> i can change it though
[17:50] <kenvandine> sil2100,  how do i specify the rtm ppa?
[17:52] <sil2100> kenvandine: well, I would be afraid with such a version number when in utopic we make an SRU or somewhere else, there's risk that we can get the same version number
[17:52] <sil2100> kenvandine: usually using ppa:team-name/ubuntu-rtm/ppa-name should be enough
[17:53] <kenvandine> true, i changed the version
[17:55] <kenvandine> ppa:ci-train-ppa-service/ubuntu-rtm/landing-014
[17:55] <kenvandine> sil2100, ^^
[17:55] <kenvandine> sil2100, also failed, this time can't find suite 'ubuntu'
[17:56] <kenvandine> maybe i need to tweak my dput.cf
[17:59] <sil2100> hmmm
[17:59] <sil2100> kenvandine: how does your global dput.cf look like in the [ppa] section?
[18:00] <kenvandine> sil2100, i had that in my own .dput.cf
[18:01] <kenvandine> old stuff
[18:01] <kenvandine> i removed mine... lets see if that helps
[18:06] <sil2100> kenvandine: did it help?
[18:07] <kenvandine> yeah, all uploaded now
[18:07] <robru> sil2100: so I got that set_package_version_list in trunk, just waiting to get ahold of IS to deploy that for us
[18:09] <kenvandine> sil2100, so once all these build, i need to do a watch only build on the silo right?
[18:09] <sil2100> robru: thanks :)
[18:09] <sil2100> kenvandine: yes
[18:09] <robru> sil2100: you're welcome
[18:09] <sil2100> kenvandine: if! We don't get any failures ;p
[18:11] <kenvandine> sil2100, have confidence :)
[18:25] <robru> sil2100: hey I just got the publish fix in production, do you have anything publishable to test with?
[18:25] <robru> (I mean it totally is guaranteed to work, I just like to see it working while I have the IS guy's attention...)
[18:26] <sil2100> robru: not yet, since we have some ubuntu-rtm stuff ready but we're waiting for unblocking -proposed and getting an image ;/
[18:27] <robru> sil2100: ok well when you do finally publish something just keep an eye out for the published version list thing working and if not, ping me and I'll investigate why it didn't work (but it really has to work since it's just a single function call to a tested function, so i can't imagine anything going wron)
[18:27] <sil2100> robru: I just hope it'll serialize to JSON nicely
[18:27] <sil2100> And in this case we'll have to modify the spreadsheet scripts
[18:28] <sil2100> Since they're not expecting a list of versions (probably)
[18:29] <robru> sil2100: funny because the function was named set_package_version_list all along ;-)
[18:30] <robru> sil2100: ah so indeed set() isn't valid json
[18:30] <robru> sil2100: good call
[18:30] <robru> ;-)
[18:30] <robru> what could go wrong?
[18:30] <sil2100> robru: that's why I changed it to a dictionary originally, since I didn't know about the usage of a set there - and I was worried it won't JSONize
[18:31] <robru> sil2100: ok I'll fix that
[18:31] <sil2100> (by usage of a set I mean I didn't know about the dual-landing requirements of that ;) )
[18:38] <sil2100> kenvandine: we have failures :|
[18:39] <kenvandine> bugger!
[18:39] <sil2100> :|
[18:40] <kenvandine> sigh... we'll need to pull in some utopic fixes :/
[18:40] <kenvandine> or vivid actually
[18:40] <sil2100> https://launchpadlibrarian.net/188684555/gnome-control-center_1%3A3.12.1-5ubuntu2_1%3A3.12.1-5ubuntu3.diff.gz
[18:41] <sil2100> This seems to help for g-c-c
[18:44] <kenvandine> sil2100, no, g-c-c in rtm is 3.8.6
[18:44] <kenvandine> not 3.12.1
[18:44] <alexabreu> trainguards can you reconfigure RTM silo 13 (L39) ?
[18:44] <robru> sil2100: right. defaultdict json-izes into a dict but you're right that set() doesn't json-ize. just pushed a fix for that
[18:44] <sil2100> :<
[18:44] <kenvandine> none of the packages are in the touch images, maybe we could just sync them from vivid?
[18:45] <robru> alexabreu: one sec
[18:45] <sil2100> kenvandine: might be a good idea, but... I hope they won't require any new deps
[18:45] <sil2100> kenvandine: let's try that, give me a moment to prepare the sync line
[18:46] <kenvandine> sil2100, thanks... i appreciate that
[18:46] <robru> alexabreu: done
[18:46] <alexabreu> robru, thx
[18:46] <robru> alexabreu: you're welcome
[18:46] <robru> sil2100: ok try publishing something now ;-)
[18:47] <sil2100> robru: we'll have something soon (I hope!)
[18:47] <sil2100> kenvandine: ok, syncing
[18:47] <sil2100> Damn it ;/
[18:48] <sil2100> kenvandine: ok, huston, we might have a problem
[18:48] <sil2100> kenvandine: sync silos won't work here :<
[18:50] <sil2100> kenvandine: need to wait for the silo to stop preparing packages, but we'll have to prepare those packages manually
[18:50] <sil2100> kenvandine: CI Train, when doing synces, appends ~rtm to the upstream version number by default, so now we'll have b0rken package numbers in the silo
[18:51] <sil2100> Check out the PPA later and tell me if you think we can use those
[18:54] <sil2100> Grrrrr
[18:54] <sil2100> Why so many problems?!
[18:54] <robru> sil2100: ok I'm gonna grab some food quickly, brb. I promise nothing can go wrong with the publish job (both hotfixes had tests) ;-)
[18:55] <kenvandine> sil2100, so i bet some of these gnome bumps will be missing deps :/
[18:55] <sil2100> robru: ok, have fun!
[18:55] <sil2100> kenvandine: ;/
[18:55] <kenvandine> what a mess...
[18:55] <sil2100> kenvandine: let's see how these ugly-versioned syncs build, we'll be prepared for that at least
[19:03] <sil2100> kenvandine: ok, they're in the PPA - take a look at those broken version numbers, so sad :<
[19:03] <sil2100> But we'll see if new deps will be needed
[19:09] <kenvandine> Missing build dependencies: libgrilo-0.2-dev
[19:09] <kenvandine> sil2100, ^^
[19:09] <kenvandine> Missing build dependencies: libgnome-desktop-3-dev (>= 3.9.91)
[19:10] <sil2100> ...
[19:10] <kenvandine> sil2100,  does that ppa not pull from -proposed?
[19:11] <kenvandine> Missing build dependencies: libupower-glib-dev (>= 0.99.1)
[19:11] <sil2100> It should
[19:11] <sil2100> Yeah, it's says it uses proposed
[19:13] <sil2100> hmmmm
[19:13] <sil2100> kenvandine: ok...
[19:13] <sil2100> kenvandine: I see another thing :<
[19:13] <sil2100> kenvandine: the reason for this is that the version we have in -proposed is 0.99.1~rtm-3
[19:13] <sil2100> kenvandine: since it was a sync from vivid
[19:14] <sil2100> And 0.99.1~rtm is smaller than 0.99.1
[19:14] <kenvandine> yeah
[19:14] <sil2100> kenvandine: all in all, I must say that silo 16 is a catastrophy right now ;p And it has nothing to do with any of your changes ;p
[19:14] <sil2100> We're doing everything wrong!
[19:15] <kenvandine> yeah... i really wasn't prepared to try to land that transition :-/
[19:16] <sil2100> Same here...
[19:17] <sil2100> I think we might want to re-publish upower with a proper version number
[19:17] <kenvandine> that's only part of the problem though
[19:18] <sil2100> Yeah
[19:18] <sil2100> And then, we need to decide if we want to continue this big transition, or we'll just fix the packages to build
[19:18] <sil2100> With hacky patches
[19:18] <kenvandine> all of the desktop stuff, is going to be like peeling an onion
[19:19] <sil2100> So maybe we can simply fix the FTBFS?
[19:19] <kenvandine> or... maybe change the build depends binary to libupower-glib3-dev ?
[19:20] <kenvandine> so the packages that haven't been ported can still build against the old
[19:20] <kenvandine> that's different than vivid though
[19:20] <sil2100> Which ones?
[19:21] <kenvandine> change the binary from libupower-glib-dev to libupower-glib3-dev
[19:21] <kenvandine> then change the build depends for indicator-power, settings, etc
[19:21] <kenvandine> but leave all the desktop packages alone
[19:22] <sil2100> uuuh
[19:22] <sil2100> Sounds hacky! ;)
[19:22] <kenvandine> yeah :)
[19:22] <kenvandine> shortest road to fixing the rtm archive though
[19:23] <kenvandine> i still hate it
[19:23] <sil2100> Are you sure that would help though?
[19:23] <kenvandine> sure, if the other packages still depend on the old binary
[19:23] <kenvandine> that binary is still in the archive
[19:23] <kenvandine> and doesn't conflict
[19:23] <kenvandine> they depend on libupower-glib1
[19:24] <kenvandine> they shouldn't even need to be rebuilt
[19:24] <kenvandine> but if they were to be rebuilt, they would need to build against the old upower
[19:24] <sil2100> But this does seem to reveal a certain risk, that even with the new upower in the rtm archive, all non-modified packages would depend on the old one
[19:24] <sil2100> And this would potentially mean that we're unsyncable for those components as well, hmm
[19:24] <kenvandine> yeah, the version they are linked with
[19:24] <kenvandine> yeah
[19:25] <kenvandine> none of which are in the image though
[19:25] <kenvandine> we didn't see any problems with those installing upower from the silo
[19:26] <kenvandine> and actually, if we sync those packages, they will come from vivid anyway
[19:26] <sil2100> kenvandine: right!
[19:27] <kenvandine> the rename of the build depends blows
[19:27] <sil2100> kenvandine: ok, so if you feel brave enough, please proceed! I suppose that you as a core-dev have more feeling of what's appropriate as well :)
[19:27] <kenvandine> but without it those desktop packages will FTBFS if we ever tried rebuilding
[19:27] <sil2100> kenvandine: in the meantime, I'll prepare a different silo for you
[19:27] <kenvandine> well... why exactly is it held in proposed?
[19:27] <sil2100> kenvandine: since this one is blown anyway, since we cannot push versions lower than what's in there
[19:28] <kenvandine> since we aren't removing the old lib
[19:28] <kenvandine> i'm just wondering if we have a hard breaks there keeping you from installing the 2 versions
[19:28] <sil2100> kenvandine: I didn't see that in the package, hm, right
[19:29] <kenvandine> do we have an excuses page for ubuntu-rtm?
[19:34] <sil2100> kenvandine: yeah
[19:35] <sil2100> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
[19:35] <sil2100> Wait, no
[19:35] <sil2100> Wrong paste
[19:35] <sil2100> http://people.canonical.com/~ubuntu-archive/proposed-migration/ubuntu-rtm/update_output.txt
[19:45] <sil2100> kenvandine: any leads?
[19:52] <kenvandine> sil2100, not really... according to rmadison there is no libupower-glib1 in 14.09-proposed
[19:52] <kenvandine> oh... of course there isn't :)
[19:53] <kenvandine> the update tests should be able to resolve that from 14.09 though
[19:54] <sil2100> jibel: let's postpone the announcement of the new rules until tomorrow, ok?
[19:54] <jibel> sil2100, okay
[19:59] <kenvandine> sil2100, ok... this isn't good
[19:59] <kenvandine> powerd and indicator-power was promoted to release
[19:59] <kenvandine> but they should have been built against the new upower
[20:00] <kenvandine> so those will be uninstallable
[20:01] <sil2100> Wait, they weren't built against the new upower? They were in the same silo?
[20:01] <sil2100> Ah, no deps for 0.99?
[20:01] <kenvandine> yes, in the same silo
[20:02] <kenvandine> ah, they depend on upower
[20:02] <kenvandine> not libupower-glib3
[20:03] <kenvandine> so i guess they will be installable
[20:03] <kenvandine> but... probably blow up
[20:03] <kenvandine> probably really depends on the dbus interface
[20:07] <kenvandine> sil2100, i don't know what to do... since those went to release we're pretty committed to getting the other 2 to release asap
[20:07] <kenvandine> it'll break the images
[20:07] <kenvandine> but then that causes some sort of update issue for those desktop packages in rtm
[20:07] <kenvandine> none of which should affect the image
[20:08] <kenvandine> sil2100, i guess we just don't know if powerd and indicator-power gracefully falls back to the old dbus API or not
[20:08] <kenvandine> i know we needed updates to those to handle the dbus api changes, but never looked at them
[20:11] <sil2100> kenvandine: so maybe we'll revert the upower+powerd landing for now?
[20:12] <sil2100> And re-release once all is clear?
[20:13] <kenvandine> sil2100, well half of the landing is in release already
[20:13] <kenvandine> harder to revert
[20:13] <sil2100> kenvandine: no no, since we'd revert those exactly, just use the reverter and push directly to the archive :)
[20:14] <sil2100> You know, reverts should instantly pop up in the archive I suppose
[20:14] <kenvandine> fine with me, just need someone who can sort out the transition
[20:14] <sil2100> But hm, the version numbers would be ugly
[20:14] <kenvandine> i hadn't planned any time for that
[20:14] <sil2100> But bleh
[20:14] <sil2100> Yeah, ok, let me revert today or tomorrow (at max) and we'll take care of this tomorrow
[20:14] <kenvandine> we don't want broken images, that's more important than version numbers
[20:14] <kenvandine> :)
[20:16] <kenvandine> i suspect images created now would be pretty broken
[20:18] <kenvandine> sil2100, so if we're reverting, could i just publish what's in silo 4 and squash what went to -proposed?
[20:18] <kenvandine> assuming QA gives it an ack
[20:22] <sil2100> kenvandine: I suppose that might be a good idea, but let me first revert - will do that once I'm back from a quick errand
[20:22] <kenvandine> ok, thanks
[20:23]  * kenvandine tries to remember what he was fixing before all hell broke loose :-D
[21:07] <Saviq> Ursinha, hey, looks like I can't get rid of the Resync trunk commits after all https://code.launchpad.net/~mir-team/qtmir/trunk :/
[21:19] <sil2100> Saviq: that's still happening?
[21:19] <sil2100> robru: ^
[21:20] <robru> what?
[21:20] <Saviq> sil2100, well, there's two things - a) the 5 before previous release got brought back somehow
[21:20] <sil2100> robru: check the qtmir trunk above, it seems CI Train is again pushing 'Resync trunk' commits there all the time
[21:20] <Saviq> sil2100, and b) there's an empty "Resync trunk" at the tip as well
[21:21] <sil2100> I need to revert the breakage now and finally EOD
[21:21] <robru> sil2100: Saviq: the qtmir silo isn't even published? merge&clean job can't be running to cause this
[21:21] <sil2100> Saviq: yeah, the last thing is worrying...
[21:23] <sil2100> kenvandine: what we'll do is, I'll ask some archive admin to remove the 2 packages from proposed, and revert the other two back with our reverter
[21:23] <sil2100> And everything will be super clean
[21:23] <kenvandine> sil2100, ok
[21:26] <Saviq> robru, that's vivid
[21:26] <Saviq> robru, the silo just got published some time ago
[21:26] <robru> Saviq: 2 hours ago?
[21:26] <Saviq> robru, possibly, row 29
[21:27] <robru> Saviq: I mean if this problem was back, there'd be a new resync trunk commit every 5 minutes, as that's how often it tries to merge & clean
[21:27] <Saviq> robru, https://ci-train.ubuntu.com/job/check-publication-migration/72793/console
[21:27] <robru> since there's only one resync trunk commit, this must be some different but similar issue
[21:27] <Saviq> robru, I'm not saying it's the same problem
[21:28] <Saviq> robru, similar result, yes (and I don't know where it took the previous 5 empty commits, too
[21:28] <Saviq> does it keep a cache of the trunk between landings or something?
[21:28] <robru> Saviq: oh right, so what happens is, citrain checks the revno of trunk when the silo is prepared. you deleted a bunch of commits and citrain was like 'hey, revno at trunk is different, let's merge what we have with what they have'
[21:28] <robru> Saviq: yes, the silo keeps a copy of the branch locally which it then pushes later
[21:28] <Saviq> robru, but not *between* silos
[21:29] <robru> Saviq: so now that the silo is free you should be able to delete those commits and --overwrite the branch, next silo will honor that
[21:29] <robru> Saviq: not between silos no... only inside the silo itself
[21:29] <Saviq> robru, if only bzr allowed deleting commits...
[21:30] <Saviq> robru, I'll have a think about what to do
[21:30] <robru> Saviq: I'm pretty sure you can branch the trunk, check out an earlier revision, cherry pick a couple commits that are real, and then `bzr push --overwrite` to get those ugly commits out of the trunk
[21:31] <Saviq> robru, sure I can, not the cleanest way to do things, though...
[21:33] <robru> Saviq: the only other option I'm aware of is to just leave those commits in place. ¯\_(ツ)_/¯
[21:34] <Saviq> robru, yeah, /me hates, overwritten
[21:36] <robru> Saviq: not that this matters to you, but amusingly this issue wasn't caused by my recent refactorings... when I implemented automatic merge&clean, I didn't make any changes to the merge&clean job for that... so merge&clean always had this bug, just exacerbated by the creds explosion and running the script automatically every 5 minutes...
[21:36] <Saviq> robru, yup
[21:51] <sil2100> kenvandine: hey, maybe you're willing to do a dput for me? :)
[21:51] <sil2100> kenvandine: http://people.canonical.com/~lzemczak/packaging/ <- the powerd* files there
[21:51] <brendand> lpotter, need a quick chat about silo 22 if that's ok
[21:51] <kenvandine> sure
[21:51] <sil2100> kenvandine: (nothing else needs reverting, the indicator-power landing only touched translations, so it's safe)
[21:51] <sil2100> kenvandine: thanks!
[21:51]  * sil2100 needs to really EOD now
[22:02] <kenvandine> what's the secret sauce to dput directly to 14.09?
[22:03] <kenvandine> robru, do you have any idea? ^^
[22:05] <robru> kenvandine: dput to a ppa or the archive?
[22:05] <kenvandine> archive
[22:05] <robru> kenvandine: sorry I only know how to dput to the ppas.
[22:05] <kenvandine> trying to upload the package from sil2100 for that revert
[22:05] <kenvandine> he said to dput it directly to 14.09... then ran off :)
[22:05] <robru> kenvandine: I guess use copy-package?
[22:07] <kenvandine> he said dput...
[22:07] <kenvandine> and gave me the sources for his package
[22:07] <kenvandine> sigh...
[22:08] <robru> kenvandine: I've never dput'ed to archives. usually when the train has problems publishing I hear core-devs talk about using copy-package from the PPAs to the archive.
[22:08] <kenvandine> yeah
[22:13] <kenvandine> whew... figured it out :)
[22:14]  * kenvandine heads out too
[23:04] <tedg> trainguards, Can I get a silo for line 46 please?
[23:07] <robru> tedg: ah, you have silo 0 ;-)
[23:07] <tedg> robru, Hah, now I'm curious if zero is the non-silo ;-)
[23:07] <tedg> robru, Thanks!
[23:08] <robru> tedg: you're welcome
[23:08] <tedg> robru, I think that vivid silo 4 fell off the spreadsheet…
[23:09] <tedg> robru, It's tested, can you just publish it?
[23:09] <robru> tedg: ok
[23:10] <charles> ted, robru, thanks :)
[23:10] <charles> s/ted/tedg/
[23:11] <robru> charles: you're welcome
[23:11]  * tedg curses the person who has "ted" of freenode!
[23:11] <tedg> on…
[23:11] <charles> ted kulp
[23:11] <tedg> Yeah, don't know who that is. Clearly a bad person because he took my nick.
[23:12] <robru> tedg: heh
[23:12] <charles> apparently, he wrote this: http://www.cmsmadesimple.org/
[23:15] <tedg> Bet it's written in PHP, the devil's language.
[23:15] <tedg> :-)
[23:31] <robru> cjwatson: ping
[23:31] <cjwatson> robru: Please tell me what you want and I'll reply when I'm around.
[23:31] <robru> heh
[23:32] <robru> cjwatson: if it's possible can you install python-six on snakefruit? http://people.canonical.com/~ubuntu-archive/cicopy.log
[23:33] <cjwatson> robru: Could you RT that, please?  It'd make more sense to have IS install it than for me to unpack another thing in our home directory.
[23:33] <cjwatson> (And chase with IS directly, assuming you need this to get the train running properly.)
[23:33] <robru> cjwatson: ah ok. yeah publications are blocked on this right now
[23:33] <robru> cjwatson: it is snakefruit right?
[23:33] <cjwatson> Yes.
[23:33] <robru> cjwatson: thanks
[23:34] <cjwatson> I've unpacked a few things in ~ubuntu-archive, but only when they're newer than what's available in packaged form for snakefruit's current release, or similar.
[23:34] <cjwatson> But six.iteritems should be available in 1.1.0-2 IIRC which is what's available.
[23:35] <cjwatson> Yeah, looks like it.
[23:35] <robru> cjwatson: oh jeez. yeah I've hit a few spots where python-six 1.1 wasn't new enough
[23:35] <robru> cjwatson: but if it has iteritems it should be good for this
[23:36] <cjwatson> It does, I checked my git history.
[23:36] <robru> cjwatson: ok thanks
[23:44] <robru> cjwatson: no, wait
[23:44] <robru> cjwatson: the line preceding the failing import is 'from six.moves import range as gen_range'
[23:44] <robru> cjwatson: so python-six is installed, but six.iteritems isn't available
[23:46] <cjwatson> Oh, so it is.
[23:46] <robru> cjwatson: can you pull in a newer version then? I guess 1.5 would have it, 1.8 is latest.
[23:47] <cjwatson> Yeah, working on it.
[23:47] <robru> cjwatson: thanks
[23:51] <robru> cjwatson: actually, looking at that traceback there's a sort of funny import chain going on there. if I were to shuffle around where some functions and classes are defined, I could probably avoid copy2distro needing to import silomanager at all, avoiding that import. does that sound like a better solution to you? or is that just kicking the can down the road
[23:51] <robru> until the next time a file grows a dep on six?
[23:53] <cjwatson> robru: *shrug* it should have six 1.8.0 there now
[23:54] <cjwatson> (I just cloned the Debian packaging branch, symlinked six.py into $HOME/python/ which is used for other things, and set PYTHONPATH="$HOME/python" in ~/cu2d/run.sh
[23:54] <robru> cjwatson: alright thanks.
[23:54] <cjwatson> )
[23:54] <robru> cjwatson: we'll see in a minute if it worked ;-)
[23:55] <cjwatson> Apparently not.
[23:55] <robru> cjwatson: no? the traceback disappeared
[23:55] <cjwatson> Reload.
[23:55] <robru> i... what?
[23:55] <robru> cjwatson: I swear I reloaded and the traceback was gone. how is it back?
[23:56] <cjwatson> Because it was still busy writing the file when you reloaded first.
[23:56] <robru> ah
[23:57] <cjwatson> Weird, that sequence of imports works when I run it by hand at a python prompt.
[23:57] <robru> cjwatson: so why didn't that work if you set pythonpath? citrain files append to sys.path but don't overwrite it
[23:57] <cjwatson> I don't know, kind of on vacation here. :P
[23:57] <robru> cjwatson: bah, python import magic
[23:57] <robru> barry!!
[23:58] <robru> cjwatson: ok well I'll do a branch where I shuffle things.
[23:59] <cjwatson> (Pdb) sys.modules['six']
[23:59] <cjwatson> <module 'six' from '/home/ubuntu-archive/cu2d/cupstream2distro/six.pyc'>
[23:59] <cjwatson> Nuked that .pyc, should be better in a moment.
[23:59] <robru> cjwatson: oh right, leftover from when I'd committed a stub to trunk...