[02:52] <veebers> Huh, looks like I got  that wrong :-
[05:10] <Mirv> morning
[05:12] <veebers> Hi Mirv, how are you?
[05:13] <veebers> Mirv: when you have a moment I'm hoping you can help me sort out a couple of things.
[05:16] <Mirv> veebers: would you like to have lp:xpathselect properly synced from archivess?
[05:17] <Mirv> veebers: and fine thank you, it was a great weekend!
[05:17] <veebers> Mirv: right, that's one of the things :-) Looks like I may have misunderstood something, but at any rate xpathselect needs rebuilt under gcc5 in wily. The silo request I have there may be wrong as I see it was done somewhere else
[05:18] <veebers> Mirv: Excellent, that's good to hear :-)
[05:19] <Mirv> veebers: ok lp:xpathselect is now up-to-date and tagged, but it already has a gcc5 rebuild, it's just stuck in -proposed https://launchpad.net/ubuntu/+source/xpathselect/1.4+15.10.20150817.1-0ubuntu1 - anyway, if wanted, now another rebuild would be possible (or anything else against lp:xpathselect)
[05:19] <Mirv> veebers: it's the autopilot-gtk autopkgtest problem already noticed last week
[05:19] <Mirv> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#xpathselect
[05:21] <veebers> Mirv: ah right, so those autopkgtest failures are because it needs xpathelect to be rebuilt with gcc5.
[05:21] <veebers> with xpathselect rebuilt, building autopilot-gtk works and passes.
[05:24] <veebers> Mirv: I'm not sure how to proceed from here, autopilot-gtk failures shouldn't hold up the autopilot release that's in proposed nor the xpathselect in this case either
[05:24] <Mirv> veebers: yes, but this https://launchpad.net/ubuntu/+source/xpathselect/1.4+15.10.20150817.1-0ubuntu1 from last week's Thursday already claims to be the rebuild
[05:25] <Mirv> and the tests have failed with that too
[05:25] <Mirv> veebers: anything out of ordinary regarding the tests should be brought to cihelp team, but I'm afraid no-one at this hour is reading the highlights
[05:27] <veebers> Mirv: out of interest, where can I see which version of xpathselect was used when building autopilot-gtk?
[05:30] <veebers> ah nvm, looks like I found what I want
[05:30] <Mirv> veebers: in the test log link from http://autopkgtest.ubuntu.com/packages/a/autopilot-gtk/wily/amd64/ - but doesn't it seem it's using the old version if though new one was in -proposed already? maybe the test is to blame, not using proposed
[05:31] <Mirv> oh, no
[05:31] <Mirv> no, it isn't, it's the new one
[05:32] <thomi> Hi Evan,
[05:32] <thomi> damn, wrong channel
[05:36] <veebers> Mirv: hmm, ok now I'm a little confused. On my wily machine I attempt to build autopiliot-gtk and the tests fail as per the log. I then build and install the debs for xpathselect and the build (and tests) of autopilot-gtk work fine
[05:36] <veebers> I know why the tests are failing, because they are getting nothing back from the call to the xpathselect lib
[05:43] <Mirv> veebers: confirming, works also for me after installing the libxpathselect 15.10.20150817.1 on wily. I don't know why it's then failing in the autopkgtest.. we need the cihelp
[05:44] <veebers> Mirv: ah cool, thanks for confirming (I was worried I had missed something obvious :-) ). Would you know an approx ETA for cihelp?
[05:44] <Mirv> veebers: I can try to ping them today but if nothing happens you should reping at the start of your tomorrow's shift when the US folks might be still around. they respond to the 'cihelp' word
[05:44] <Mirv> veebers: usually in 3h from now or so :(
[05:45] <veebers> Mirv: aha, I see :-) I'll probably jump back online later tonight and see what's happening, I would love to unblock the previous autopilot release so I can get this next one progressing too.
[05:46] <Mirv> I can understand that
[05:46] <veebers> Mirv: Thanks for your help, it would be awesome if you would ping when cihelp comes on online to hopefully get the ball rolling
[05:52] <Mirv> you're welcome! I will.
[07:36] <pstolowski> sil2100, hey! is silo 31 good to land now after michi's fix to changelog?
[07:38] <sil2100> pstolowski: looking :)
[07:40] <sil2100> bfiller: hello! You around at this hour? ;)
[07:41] <bfiller> sil2100: in london for sprint :)
[09:10] <veebers> Hi Mirv :-) Any luck that cihelp might be around now?
[09:38] <Mirv> veebers: it'd look to me unfortunately not :(
[09:38] <Mirv> cihelp?
[09:39] <Mirv> I thought there'd be during UK hours
[09:51] <sil2100> They usually have someone around in the EU timezone
[10:06] <sil2100> mandel: any ETA on the pulseaudio translation-ability?
[10:06] <mandel> sil2100, I'm getting the patch for that and several other issues and will create a silo with it, max an hour from now and I'll ask kenvandine to help me create a silo and dput the package
[10:16] <sil2100> Ok, thanks
[10:30] <veebers> Mirv: ah ok. I've spoken with jibel and nuclearbob hopefully they can help get the ball rolling and I'll check back in in my morning. Thanks again :-)
[10:30] <Mirv> veebers: thanks!
[10:30] <Mirv> great to hear
[11:26] <jibel> sil2100, do you know what is this changed that landed into the overlay https://lists.launchpad.net/landing-team-changes/msg00639.html ?
[11:26] <jibel> change*
[11:29] <sil2100> jibel: it's a no-change upload
[11:29] <sil2100> I'm resolving translation issues
[11:33] <jibel> sil2100, ah ok, I was wondering why a change from March would be copied only just now
[11:49] <jibel> mandel, any news on the pulseaudio silo to enable translations?
[12:36] <mandel> jibel, well, it just not only translates the string it also provides a fix for the timeout and the trust store so.. I've got a local build, I'm going to test it and will ask kenvandine to dput to a silo if I confirm it is ok
[12:38] <jibel> mandel, okay, keep me posted so someone from QA can review
[12:42] <morphis> sil2100 / Mirv: can one of you upload me a package to silo 43?
[12:42] <mandel> jibel, sure
[12:44] <Mirv> morphis: sure
[13:01] <john-mcaleely> sil2100, jibel (maybe  repeat, my irc is screwy
[13:01] <john-mcaleely> )
[13:01] <john-mcaleely> is now a god time to push the device tarballs
[13:03] <jibel> john-mcaleely, go ahead. there are still several hours until we have the latest fixes and a final build
[13:03] <john-mcaleely> jibel, ack
[13:05] <john-mcaleely> jibel, sil2100 pushed. thank you!
[13:06] <sil2100> Yes
[13:06] <sil2100> \o/
[13:20] <sil2100> rvr: ping! Could you maybe propose a translation for the string here? https://translations.launchpad.net/ubuntu-rtm/15.04/+source/trust-store/+pots/trust-store/es/+translate
[13:21] <rvr> elopio, this is urgent, can you approve it? ^
[13:21] <rvr> sil2100: I must request higher translation powers
[13:22] <sil2100> Yeah, looking for someone to approve the chinese version too since dpm is on holidays (and generally prefers not to approve other's stuff)
[13:23] <rvr> sil2100: Yup
[14:25] <nuclearbob> Mirv, cihelp: I'd like to pick up where veebers left off on the autopilot-gtk landing. Can we figure out why the wrong xpathselect is installing?
[14:29] <Mirv> nuclearbob: it'd look like the correct xpathselect is there, and the problem being that locally upgrading to that same -proposed xpathselect version does solve all autopilot-gtk test issues
[14:29] <Mirv> so the question is why the same does not happen in the automated tests
[14:29] <nuclearbob> that is a good question
[14:30] <Mirv> I tested on bzr bd of autopilot-gtk on wily, first it failed and after upgrading to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-019/+build/7808513/+files/libxpathselect1.4_1.4%2B15.10.20150817.1-0ubuntu1_amd64.deb everything was good
[14:30] <nuclearbob> Mirv: the queuebot says it's preparing an xpathselect landing. Could that have anything to do with it?
[14:31] <Mirv> nuclearbob: no, I think that's some sort of miscommunication between bregma / Trevinho / veebers since the same version that is in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-019/+packages is already in wily-proposed https://launchpad.net/ubuntu/+source/xpathselect/1.4+15.10.20150817.1-0ubuntu1
[14:31] <Mirv> and it was even published from that silo
[14:31] <nuclearbob> Mirv: ah, okay. weird
[14:32] <Mirv> actually, same for unity itself, the whole silo was alredy published
[14:32] <Mirv> but now being rebuilt by... Laney it seems
[14:32] <Laney> hi, yes, that version is broken
[14:32] <Laney> just talked about it in ubuntu-release
[14:33] <Mirv> ah
[14:33] <Mirv> the plot thickens/resolves
[14:33] <Laney> it has an abi change with g++5 so you need to rebuild it
[14:33] <Laney> this is why ap-gtk broke
[14:33] <Laney> s/rebuild/rename/
[14:34] <Mirv> funny how ap-gtk works after upgrading to the current wily-proposed version of xpathselect, but good that there's a solution
[14:34] <Laney> it sure didn't work for me
[14:34] <Laney> nor on autopkgtest.u.c
[14:34] <Mirv> yeah, it did for me + veebers, upgrading to this rebuilt one https://launchpad.net/ubuntu/+source/xpathselect/1.4+15.10.20150817.1-0ubuntu1
[14:34] <Laney> only once I did a rebuild of autopilot-gtk did it work again
[14:35] <Mirv> riiight, so that's what we tested locally, rebuilding autopilot-gtk. that worked with that ^ and didn't without
[14:35] <Laney> if you rebuild ap-gtk then you resolve the abi breakage of course
[14:36] <Laney> nuclearbob: are you an autopilot person btw?
[14:37] <nuclearbob> Laney: yeah
[14:37] <Laney> if so, is there a standard workaround for missing Eventually(raises(...?
[14:37] <Laney> I want to fix<EMAIL_ADDRESS>[14:38] <Laney> I can instead make this test wait for 'visible = False' on the dialog
[14:38] <Laney> oh, veebers fixed this
[14:39] <Laney> not sure I believe that fix
[14:39]  * Laney experiments
[14:45] <mandel> jibel, sil2100 I need to request a silo for pulse and kenvandine will do the dput, is that ok with you?
[14:46] <sil2100> mandel: sure :)
[14:46] <jibel> mandel, that's fine
[14:48] <mandel> sil2100, he, I think I'm outdated.. we don't longer have a spreadsheet, is that correct?
[14:48] <sil2100> mandel: yeah, there's the requests site :)
[14:48] <sil2100> https://requests.ci-train.ubuntu.com
[14:49] <Laney> nuclearbob: can you check https://code.launchpad.net/~laney/autopilot-gtk/tests-wait-not-visible/+merge/268928 for me please?
[14:50] <nuclearbob> Laney: I'll take a look
[14:51] <Laney> thanks
[14:52] <mandel> sil2100, let me know if I screw it up :-/
[14:52] <mandel> sil2100, but I think I requested it correctly
[14:52] <sil2100> mandel: you can now assign it yourself too :)
[14:53] <sil2100> mandel: just press 'Assign'
[14:53] <nuclearbob> Laney: that looks reasonable to me
[14:54] <Laney> nuclearbob: ok, I think it supersedes https://code.launchpad.net/~canonical-platform-qa/autopilot-gtk/fix-failing-mouse-test_1483815/+merge/268869
[14:54] <Laney> would like to upload this with the new xpathselect
[14:55] <Laney> and abandon the silo 041
[14:55] <nuclearbob> Laney: that makes sense to me
[14:55] <Laney> cool, thanks, will pull the right levers then
[14:56] <nuclearbob> awesome!
[14:56] <Laney> oh man, xpathselect got an empty changelog
[14:56]  * Laney cries
[15:00] <Laney> wait
[15:00] <Laney> it didn't get my change?
[15:01] <Trevinho> Laney: in what silo was supposed to be? Since I don't see it in landing-019
[15:01] <Laney> 019
[15:01] <Laney> Mirv: can you help?
[15:01] <Trevinho> mh, I don't see the MP listed there
[15:01] <Laney> I edited on the requests thing
[15:01] <Laney> is there another step?
[15:01] <Laney> do I need to 'assign' again?
[15:02] <sil2100> Laney: did you add/modify the merges you want to build?
[15:02] <sil2100> I mean, the links? In that case you need to reconfigure through the Assign button
[15:02] <sil2100> But not if you only pushed code changes to the branches
[15:02] <sil2100> Any change in the request itself requires an reconfigure, besides the Testing status of course
[15:03] <Laney> I changed the list of merges yes
[15:03] <Laney> ok, and do I have to unmangle the MERGE_PROPOSALS thing?
[15:04] <sil2100> No no
[15:04] <sil2100> It's being done by the train itself... there are some bugs in various places that make the fields urlencoded, so robru is decoding those on the train side
[15:05] <Laney> so I can just press Build and leave it encoded
[15:05] <sil2100> Yep
[15:05] <Laney> let me try this then
[15:05] <Laney> seems to be understanding it
[15:07] <Laney> yes, and now it gets the right one
[15:07] <Laney> thanks sil2100!
[15:07] <sil2100> \o/
[15:07]  * Laney gets to wait for build+publish again
[15:07] <sil2100> yw!
[15:08] <sil2100> mandel: ...ok, I'll assign the silo for you in this case
[15:09] <sil2100> kenvandine: could you upload the pulseaudio packages to ubuntu/landing-028 for mandel ?
[15:09] <kenvandine> sil2100, yes, doing it now
[15:09] <kenvandine> just building sources
[15:09] <sil2100> kenvandine: thanks!
[15:10] <mandel> kenvandine, sil2100 \o/
[15:11] <sil2100> mandel: just remember that with the new CI Train requests you can assign your own silos basically
[15:11] <kenvandine> mandel, sil2100: uploaded and it's building now
[15:11] <mandel> sil2100, can I?? cojonudo
[15:19] <jibel> mandel, does the silo includes the fix for the timeout too?
[15:20] <Trevinho> Laney: I still don't see your branch listed...
[15:20] <nuclearbob> cihelp: I'm looking for the jenkins instance that runs ubiquity tests. Maybe plars knows where that is?
[15:20] <Laney> listed where/
[15:20] <elopio> rvr: approved
[15:20] <mandel> jibel, no, that will be the next step, is a little more complicated, I'm getting the review for that patch and will get to that one
[15:20] <rvr> elopio: Thanks!
[15:20] <plars> nuclearbob: yeah, I know where it is, but you can't get to it very easily directly
[15:21] <plars> nuclearbob: the results should be mirrored on jenkins.ubuntu.com though, but afaik it's been a failing test since before we set it up
[15:21] <nuclearbob> plars: if there's information on how to get to it, whether indirectly or in a difficult manner, I can probably deal with that. I'm used to arcane access methods from my last job
[15:21] <nuclearbob> plars: yeah, I'd like to make it not a failing test anymore
[15:21] <plars> nuclearbob: awesome
[15:23] <kenvandine> bzoltan_, silo 41 is not happy
[15:23] <bzoltan_> kenvandine:  I know
[15:23] <kenvandine> bzoltan_, ok... just making sure :)
[15:24] <bzoltan_> kenvandine: I wonder where the citrain got the idea of  doing that...
[15:30] <bzoltan_> kenvandine:  LOL... citrain does things differently when it is doing doal landing :) single vivid landing messed up the versioning... dual seem to work fine. Strange beast...
[15:34] <sil2100> hmm
[15:35] <sil2100> jibel, rvr, ogra_, popey: let's skip the meeting today, we have a blocker sync up at the same time with pmcgowan
[15:35] <rvr> sil2100: Ack
[15:35] <ogra_> +1
[15:35] <sil2100> robru: hey! We'll be skipping the landing meeting, I'll update you on the status through e-mail
[15:38] <bzoltan_> sil2100: jibel: btw, the warning opting UITK fix is being processed in the silo41 ... Hopefully I can validate it during the night
[15:39] <jibel> bzoltan_, it must land before that, we'll retest the image tonight.
[15:41] <bzoltan_> jibel: I do it as fast as possible. The build need to be done :) first. I promise I will not EOD before the slo41 is tested from the UITK side.
[15:42] <jibel> bzoltan_, np thanks. We all do our best for the best OTA :)
[15:43] <bzoltan_> jibel:  :) that is something I am sure about.... also the silo9 has the emulator fix... at least the UITK part of it.
[15:44] <jibel> bzoltan_, yeah but we wanted to test 25 and 33 with 9 and there are still issues
[15:44] <jibel> bzoltan_, we'll land the 3 silos together
[15:44] <bzoltan_> jibel: Yes, that is how I understood that. Please tell me if you need anything from me
[16:00] <Laney> Trevinho: can I do a unity rebuild in that silo?
[16:01] <Trevinho> Laney: sure, it's just that one build has been landed in distro (not sure if that counts)...
[16:01] <Laney> oh, no, you have a hardcoded depends
[16:02] <Trevinho> yeah, that's because it's not a real code dependency...
[16:03] <Trevinho> want me to prepare a branch fixing it or you care about that?
[16:04] <Laney> Trevinho: https://code.launchpad.net/~laney/unity/xpathselect-v5/+merge/268939
[16:05] <Trevinho> done
[16:05] <Laney> thx
[16:17] <robru> bzoltan_: nothing strange about that. You simply are not allowed to go backwards in your versioning, so if you release to wily, you cannot later release to vivid without branching your trunk for vivid. That has always been the case. But dual silos are a special case that tack vivid on top so it gets through.
[16:18] <bzoltan_> robru:  precisely :) so the trunk gets 15.10 but vivid is on 15.04 ... so when I tried to single land the to vivid the train freaked out :) now it is better
[16:18] <robru> Laney: i have a fix for the empty changelog thing that I'll roll out shortly
[16:18] <robru> bzoltan_: yeah
[16:18] <Laney> robru: In this case I had built the wrong branch anyway :)
[16:19] <robru> Laney: true, but soon it'll say "no change rebuild" rather than having a changelog with an empty bullet point ;-)
[16:48] <robru> slangasek: sil2100: are we on for the meeting in ~1 hour? I'd like to talk to slangasek even if sil2100 can't make it
[16:51] <slangasek> robru: yes
[16:51] <robru> great
[17:05] <sil2100> Sure
[17:06] <Laney> Bah
[17:07] <Laney> I don't know why that happened - I merged the proposed branch into mine
[17:07] <Laney> It doesn't appear in https://ci-train.ubuntu.com/job/ubuntu-landing-019-1-build/205/console
[17:07] <Laney> but https://ci-train.ubuntu.com/job/prepare-silo/5899/console shows that I reconfigured it
[17:08] <Laney> nuclearbob: any chance you can check the test failures https://code.launchpad.net/~laney/autopilot-qt/no-hardcode-xpathselect/+merge/268943 - or ask whoever might know about them?
[17:08] <nuclearbob> Laney: I'
[17:08] <nuclearbob> ll take a look
[17:08] <Laney> thanks
[17:09] <Laney> I've got to go but I'll look again in the morning and try to shove the rest of it through
[17:09] <Laney> see you!
[17:09] <nuclearbob> all right!
[17:42] <robru> Laney: what doesn't appear?
[17:47] <robru> Laney: did you perhaps reconfigure while the build job was still running? the silo config is a file on a disk that also lives in memory of the any running jobs, so it's possible you reconfigured while a build was still going and then when the build completed it saved the old config without your changes.
[17:47] <robru> Laney: which is the only explanation I can think of because indeed your prepare job shows your MPs but the silo dashboard doesn't show your MPs at all.
[17:57] <rvr> jibel: bzoltan_: Approving silo 41
[17:57] <bzoltan_> rvr:  nice .. i have the logs from the UITK too
[17:58] <rvr> bzoltan_: Is all right?
[18:00] <bzoltan_> rvr: I have not seen any unusual
[18:00] <robru> mandel: hiya, what's going on with https://requests.ci-train.ubuntu.com/static/dashboard.html#?q=ubuntu%2Flanding-007 ? Silo has been ready to build since July 31st, was never built, no packages in PPA.
[18:03] <rvr> bzoltan_: To me is a go, then
[18:04] <bzoltan_> rvr: \o/
[18:04] <rvr> bzoltan_: I checked deprecation warnings in gallery app and unity8, and they were gone with the silo.
[18:05] <bzoltan_> rvr:  Yeps :) That is the point of this fix
[18:05] <rvr> bzoltan_: Also did some exploratory testing and everything seems to be fine.
[18:06] <rvr> bzoltan_: Approved
[18:45] <robru> michi: sil2100: slangasek: https://bugs.launchpad.net/cupstream2distro/+bug/1488211
[18:50] <robru> sil2100: slangasek: also https://bugs.launchpad.net/cupstream2distro/+bug/1488213
[18:51] <robru> ok I'm off for lunch, bbl
[19:41] <sil2100> jibel, robru, john-mcaleely: I need to AFK now, I'll be back in around 2-3 hours
[19:41] <sil2100> o/
[19:41] <davmor2> noooooooo so close to finishing too
[19:47] <robru> davmor2: alright, so should I publish 25, 33, and 9 all together then? not sure how you managed to coordinate 3 silos together, jeez ;-)
[19:49] <davmor2> robru: manually hacking the crap out of the upgrade system and dist-upgrading :(  not a fun day :)  But got there in the end the 3 combined give us a functional (not perfect) emulator but at least it is running :)
[19:49] <robru> davmor2: cool, thanks for your efforts
[19:49] <robru> will publish
[20:21] <kenvandine> bzoltan_, now that silo 9 was published, 41 is dirty
[20:22] <kenvandine> :(
[20:28] <kenvandine> bzoltan_, but silo 9 needs merging before 41 can be rebuilt, so i guess we are in a holding pattern
[20:40] <michi> robru: Thanks heaps!
[20:41] <robru> michi: you're welcome
[20:41] <michi> That’s awesome!
[20:42] <michi> So, by the looks of things, I don’t need to do anything extra. It should just start working once your change lands.
[20:42] <michi> (Need to make sure that my script actually does the right things, of course.)
[20:42] <robru> michi: it was easier than i thought. Fortunately an the dark magic is in your packaging and the train side stays innocent enough just running a cleaning of the package
[20:43] <michi> Yes, people will soon have to refer to me as the Dark Lord...
[20:43] <robru> michi: yep should land shortly, i asked slangasek to review, shouldn't take long
[20:43] <michi> This is very cool.
[20:43] <michi> Thanks again!
[20:43] <michi> I’ll report back once I kick another bulid of the silo.
[20:43] <michi> It should behave differently then.
[20:43] <robru> michi: you're welcome! Hopefully this reduces the workload for you a lot ;-)
[20:44] <michi> Man, if this works, it’ll make a big difference.
[20:44] <michi> I owe you a beer at the next sprint!
[20:44] <robru> Haha for sure
[20:51] <kenvandine> bzoltan_, we merged 9 and kicked a 41 rebuild
[22:32] <sil2100> mandel, kenvandine, robru, jibel: did the pulseaudio translation thing land?
[22:32] <kenvandine> sil2100, no...
[22:32] <robru> sil2100: I have no knowledge of this
[22:32] <kenvandine> mandel is still working on it
[22:32] <kenvandine> he's iterating on the patch now, it's in silo 9
[22:32] <sil2100> I thought the idea was to split it into 2 silos
[22:32] <kenvandine> but will have another iteration
[22:32] <kenvandine> i don't know about that
[22:32] <sil2100> Like, one for translations, one for the bugfix
[22:33] <sil2100> That's what I heard from pmcgowan on the meeting we had
[22:33] <sil2100> Damn...
[22:33] <mandel> sil2100, bug fix, we do have a small patch for the translation that is separated
[22:33] <kenvandine> not in  a separate silo
[22:33] <mandel> sil2100, but the translation is "minor" compared with the security implcations
[22:33] <kenvandine> sil2100, the problem with separate landings is we'll need to rebuild the second one after the first one is published
[22:34] <mandel> correct
[22:34] <kenvandine> so imo, since we are blocking on the bug fix, we just keep them together
[22:34] <sil2100> Right, but we need to give time translation admins to approve new translations
[22:34] <mandel> kenvandine, sil2100 if I see that fixing the trust store + system settings is really hard, we can land the translation and interate over the other bug fix
[22:34] <kenvandine> it'll speedd up landing
[22:34] <sil2100> Once those get imported
[22:34] <kenvandine> mandel, nothing needs to be fixed in settings
[22:34] <sil2100> I was supposed to build a new image with translations now, but it seems that's not possible
[22:34] <sil2100> jibel: ^
[22:34] <kenvandine> it's just showing what's stored in the trust db
[22:35] <mandel> kenvandine, yes, I ment, make sure that the stored app armor profile is correct
[22:35] <kenvandine> mandel, so when you fix that, settings is good
[22:35] <kenvandine> ah
[22:35] <kenvandine> yeah
[22:35] <mandel> kenvandine, I mentioned settings as a reference to the bug
[22:35] <mandel> kenvandine, we also have timeout issues
[22:35] <mandel> fun fun fun
[22:35]  * mandel is master of the "fun" projects
[22:35] <kenvandine> sil2100, maybe upload the template from the silo build?
[22:35] <kenvandine> manually
[22:36] <sil2100> I have no power to do so sadly
[22:36] <sil2100> Not enough permissions
[22:36] <kenvandine> me either
[22:36] <kenvandine> sil2100, seb128 has powers to do that
[22:37] <sil2100> I see the emulator fixes landed to the overlay as well... I thought we decided not to land those before we have all blockers for OTA-6 out of the way
[22:37] <kenvandine> no idea, i was surprised
[22:37] <kenvandine> but i rebuilt silo 41 after merging that
[22:37] <sil2100> Now I'll have to include it along with the UITK blocker fix ;/
[22:38] <kenvandine> we decided to force merging 9
[22:38] <sil2100> kenvandine: thanks
[22:38] <kenvandine> but only after we say it was published
[22:38] <sil2100> That was the right thing to do
[22:38] <kenvandine> yeah, kgunn and i discussed it
[22:38] <sil2100> Still, publishing it was not the right thing to do IMO
[22:38] <kenvandine> didn't want that to sit until morning
[22:38] <kenvandine> not sure who did that
[22:38] <kenvandine> 41 was verified by qa already
[22:39] <kenvandine> i wanted that in!
[22:39] <seb128> kenvandine, what power do you need?
[22:39] <kenvandine> that's breaking the settings CI :)
[22:39] <sil2100> QA had to sign it off, I thought they would have waited with switching it on bileto
[22:39] <kenvandine> seb128, uploading a template manually
[22:39] <kenvandine> sil2100, right?  upload the fixed template in silo 9 manually to wily, right?
[22:39] <kenvandine> pulseaudio template
[22:40] <sil2100> kenvandine: to ubuntu-rtm/15.04
[22:40] <kenvandine> so the translators can get started on it
[22:40] <kenvandine> or that
[22:40] <seb128> kenvandine, can do if you want
[22:40] <kenvandine> cool
[22:40] <kenvandine> let me get you the template
[22:40] <seb128> thanks
[22:41] <sil2100> bzoltan_: hey! https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/optInDeprecationWarningsTrunk/+merge/268909 is unapproved
[22:41] <sil2100> seb128: thanks!
[22:41] <sil2100> This should give translators some time to get things done
[22:50] <sil2100> kenvandine: did you give seb128 the pot file?
[22:50] <kenvandine> not yet
[22:50] <kenvandine> i think something's wrong here
[22:50] <kenvandine> mandel, ping
[22:50] <mandel> kenvandine, yes?
[22:50] <kenvandine>     bool result = pa_trust_store_check(pc->userdata->ts, pc->appname, pc->uid, pc->pid,
[22:50] <kenvandine>         "%1% wants to record audio.");
[22:50] <kenvandine> is that what should get translated?
[22:51] <kenvandine> mandel, there are no strings from that file in the generated pot file
[22:51] <mandel> kenvandine, yes it should, I'll update that
[22:51] <kenvandine> and if that's the string, it's not getting picked up
[22:51] <seb128> of course it's not, it's not under _() or any equivalent
[22:51] <kenvandine> mandel, so a new 0416 patch?
[22:51] <mandel> kenvandine, correct
[22:51] <kenvandine> seb128, exactly :)
[22:52] <mandel> kenvandine, but let me first test the silo 09
[22:54] <kenvandine> mandel, i have a fix already
[22:55] <mandel> kenvandine, awesome, thx.. I've got the trust store working again and getting the logs
[22:57] <kenvandine> seb128, http://people.canonical.com/~kenvandine/pulseaudio.pot
[23:02] <seb128> kenvandine, to what serie do you need that?
[23:02] <kenvandine> ubuntu-rtm/15.04
[23:03] <seb128> hum
[23:03] <seb128> https://translations.launchpad.net/ubuntu-rtm/15.04/+source/pulseaudio
[23:03] <seb128> no template there atm
[23:03] <seb128> that feels wrong?
[23:04] <sil2100> The templates need approval, no one approved them it seems
[23:04] <sil2100> https://translations.launchpad.net/ubuntu-rtm/15.04/+source/pulseaudio/+imports
[23:05] <seb128> right, but where are we taking our export from then atm?
[23:05] <seb128> or at we shipping no pulseaudio translations?
[23:06] <sil2100> From vivid IIRC, pitti merged vivid and the overlay for the langpack-o-matic upload
[23:06] <sil2100> Since that's basically what we should be doing
[23:07] <michi> trainguards: I need QA for silo 11. Could someone help with that please?
[23:07] <seb128> k, translations approved and new template uploaded
[23:07] <sil2100> seb128: \o/ thanks!
[23:07] <kenvandine> mandel, i  had to refresh the patches
[23:07]  * sil2100 hugs seb128
[23:07] <kenvandine> see your email
[23:07] <seb128> yw
[23:07] <sil2100> Isn't it late for you as well?
[23:07] <kenvandine> so it includes the i18n stuff in the first patch
[23:07] <seb128> :-)
[23:07] <seb128> hug to kenvandine as well for working on those issues
[23:07] <robru> michi: you are in the queue: https://trello.com/c/iwFs6IHg/2212-204-ubuntu-landing-011-persistent-cache-cpp-michi
[23:07]  * sil2100 hugs kenvandine too
[23:07] <kenvandine> :)
[23:08] <michi> robru: Cool, thank you!
[23:08]  * sil2100 preps the e-mail to the translators
[23:08] <kenvandine> mandel, it did cause a conflict in the 0417 branch
[23:08] <kenvandine> mandel, because i wanted to keep the i18n change along with the POTFILES.in fix
[23:08] <robru> michi: you're welcome. how's silo 10 going? I'm ready to test it in staging
[23:09] <michi> robru: Trying to figure out how to merge it correctly.
[23:09] <kenvandine> mandel, can you please rebase your 0417 patch over my refreshed one?
[23:09] <robru> fun times
[23:09] <kenvandine> i know that a pita with quilt
[23:09] <michi> When I merged trunk into my branch, I didn’t get an merge conflicts.
[23:09] <mandel> kenvandine, don't worry, is not such a huge PITA
[23:09] <mandel> kenvandine, I'll do that
[23:09] <michi> do you have a link to the actual conflict it reported?
[23:09] <kenvandine> mandel, thx
[23:09] <mandel> kenvandine, nah, thx for taking a look at the translations
[23:10] <kenvandine> no worries
[23:10] <kenvandine> that was an easy fix :)
[23:10] <seb128> kenvandine, https://translations.launchpad.net/ubuntu-rtm/15.04/+source/pulseaudio/+pots/pulseaudio/fr/167/+translate
[23:10] <seb128> there you go ;-)
[23:10] <kenvandine> seb128, thx!
[23:10] <seb128> yw!
[23:10] <kenvandine> sil2100, ^^ there you go :)
[23:10] <kenvandine> see how i passed that buck to seb128?
[23:10] <kenvandine> :-D
[23:11] <seb128> lol
[23:11] <seb128> cross team work!
[23:11] <seb128> ;-)
[23:13] <kenvandine> indeed :)
[23:20] <sil2100> Thanks guys, I sent out a request to translators :)
[23:20] <sil2100> Anyway, I guess I go take a shower and sleep, see you tomorrow o.
[23:20] <sil2100> o/
[23:25] <michi> robru: Just pushed the branch with the conflict resolved.
[23:25] <robru> michi: great
[23:25] <michi> building with bzr bd locally now to see whether at least that much works.
[23:26] <michi> robru: At what stage and by what tool is the changelog parsing done?
[23:26] <robru> michi: https://ci-train.staging.ubuntu.com/job/ubuntu-landing-008-1-build/2/console running your build in staging here, we'll see what happens!
[23:26] <michi> It looks like that’s where the version number comes from for the build
[23:26] <robru> michi: what do you mean by changelog parsing?
[23:27] <michi> So, very early during the build, before any of the debian/rules targets runs, something decides what the version number is.
[23:27] <robru> michi: are you talking about the version number that the train generates and then puts into the changelog?
[23:27] <michi> Yes
[23:27] <robru> michi: yeah
[23:27] <michi> So, I need different numbers here, it seems, for vivid and wily.
[23:27] <michi> 0.6.x for vivid, and 1.0.x for wily
[23:28] <robru> michi: uh
[23:28] <robru> michi: no
[23:28] <michi> If that is used just temporarily for the build, I’m cool with that.
[23:28] <michi> As long as the packages that get built have the right version in the end.
[23:28] <robru> michi: the train will already generate different versions for vivid and wily, but it can't handle different upstream versions for that
[23:29] <michi> I’m sorry, you lost me there.
[23:29] <michi> So, the goal here is that, for vivid, we need packages with a 0.6.x version number and, for wily, with a 1.0.x version number.
[23:29] <robru> michi: the train will generate upstream+15.10.YYYYMMDD for the wily version, and then the vivid version will get upstream+15.04.YYYYMMDD when that is uploaded. you can't force your own version number there
[23:30] <michi> So, how can I force different package names for vivid and wily?
[23:30] <robru> michi: when the train runs the clean target, your script will run that generates your control file.
[23:30] <robru> michi: you can't have different version numbers though, the train picks your version numbers for you.
[23:31] <robru> michi: you better just use 1.0.x and then when you're setting your dependencies, they go like "<1.0.0+15.04" for vivid and ">1.0.0+15.10" for wily
[23:31] <michi> sec phone…
[23:32] <robru> michi: it has to be the same upstream version because you're building from the same source tree... I don't think it's a good idea to have different numbers representing the same codebase.
[23:34] <michi> Hmmm...
[23:34] <michi> OK
[23:35] <robru> michi: also I'm seeing this in the build log: http://paste.ubuntu.com/12188664/ so you probably need to add a build-dep on lsb-release
[23:35] <michi> Let me see how the build goes. There iare obviouslly things I don’t undestand yet.
[23:35] <michi> Ah, cool
[23:35] <michi> Do you happen to know what package that’s in?
[23:35] <michi> Never mind, I’ll find it.
[23:35] <robru> michi: lsb-release ;-)
[23:36] <michi> Oh.
[23:36] <michi> For once, the package matches the command.
[23:36] <michi> :)
[23:36] <robru> yeah, we need more of those
[23:36] <michi> Of course, it would have been even more excellent to call it “lsb_release” instead of “lsb-release” :(
[23:36] <robru> michi: underscore is illegal in debian package names because of reasons. so better if the command was "lsb-release"
[23:37] <michi> Or that, yes
[23:45] <michi> robru: Just pushed again with lsb-release added to the build deps. Also fixed a problem in the symbols file.
[23:46] <robru> michi: great, will retry in a sec, just working on something on my end as well
[23:46] <michi> Sure, no rush!
[23:47] <robru> michi: here we gooooo! https://ci-train.staging.ubuntu.com/job/ubuntu-landing-008-1-build/3/console
[23:47] <michi> Watching...
[23:48] <robru> oh god, that dch list
[23:49] <robru> michi: I need you to tag a revision to prevent that happening...
[23:49] <michi> What do I need to do?
[23:50] <robru> michi: I dunno how you guys do releases, but I need you to find the most recent revision in your merge target that represents something that's actually released in ubuntu, and then 'bzr tag' it with the released ubuntu version number.
[23:51] <robru> michi: that'll stop it from trying to generate a changelog that goes all the way back to the beginning of the known universe.
[23:51] <michi> Looking...
[23:53] <robru> michi: when the train generates changelogs it goes back through the commit history until it finds a tagged commit (any tag at all really, doesn't matter what version number), so it looks like you guys never used tags so it's trying to make a changelog entry with every commit ever.
[23:53] <michi> Yes, I don’t think we use tags.
[23:55] <michi> So, on vivid, the latest released version would be 0.6.19+15.10.20150724.3-0ubuntu1
[23:55] <robru> michi: so if you could do something like "bzr tag 1.0.0+15.10.20150821.3-0ubuntu1 -r 621" and then push that tag to trunk
[23:55] <michi> On wily, it’ll be different
[23:55] <robru> michi: yeah wily is better for dual silos
[23:55] <michi> Following your advice… :)
[23:56] <robru> michi: and make sure that tag gets into ~unity-team/unity-scopes-api/devel
[23:56] <michi> If we manage to merge this branch of mine, that’ll happen automatically, won’t it?
[23:57] <michi> The tag should be merged with the branch, or do I have that wrong?
[23:57] <michi> robru: Where did you get the 621 revision from?
[23:57] <michi> In my branch, the latest one is in the 3-hundreds...
[23:58] <robru> michi: I was looking here: https://code.launchpad.net/~unity-team/unity-scopes-api/devel and 621 says 'merged trunk', when I clicked through to see 621 it shows debian/changelog change with a version number mentioned.
[23:58] <michi> OK, double-checking...


[09:57] <macjl> Hello
[09:57] <macjl> I'm trying to install Unbuntu in LPAR
[09:57] <macjl> But facing problems with VLAN tagging
[09:58] <macjl> The installer don't ask me if I use VLAN, so the network does'nt work...
[09:59] <macjl> Anyone know how to net install ubuntu on s390x arch with VLAN tagging?
[10:07] <xnox> macjl, you have two options
[10:07] <xnox> macjl, return to main menu ("<")
[10:07] <xnox> change debconf priority to medium
[10:07] <xnox> then it should ask you to use vlan, but that may or may not work.
[10:08] <xnox> i typically "go through the motions up to ssh client password setup"
[10:08] <xnox> then return to main menu
[10:08] <xnox> drop to shell
[10:08] <xnox> and bring up vlan network by hand, e.g.
[10:08] <xnox> ip link set dev encc000 up
[10:08] <xnox> ip link add link encc000 name encc000.2654 type vlan id 2654
[10:08] <xnox> ip addr add <IP_ADDRESS>/24 brd <IP_ADDRESS> dev encc000.2654
[10:08] <xnox> ip link set dev encc000.2654 up
[10:09] <xnox> ip route add default via <IP_ADDRESS>
[10:09] <xnox> echo nameserver <IP_ADDRESS> >> /etc/resolv.conf
[10:09] <xnox> ..
[10:09] <xnox> adjust as needed.
[10:09] <xnox> you would then have to bring up network by hand again in the installed system, and adjust /etc/network/interfaces
[10:10] <xnox> work is in progress to improve vlan network support. Do let me know your experience with debconf medium priority that does ask for vlan network tag.
[10:13] <macjl> Thans, I'll try!
[10:13] <xnox> macjl, no problem. =)
[11:55] <Bercik> It's good to see people alive on s390* channels :)
[12:18] <xnox> Bercik, yeah =) slowly picking up.
[12:19] <Bercik> I remember idling +/- 9 months on hercules channel. Not even one word :)
[12:19] <xnox> hehe
[12:19] <xnox> honestly i have tried hercules, but did not manage to boot anything in it =(
[12:19] <Bercik> I did
[12:19] <Bercik> but not with ubuntu ;(
[12:20] <Bercik> nor modern distros (RHEL 7, SLES 12).
[12:20] <xnox> yeah, cause ubuntu needs transactional memory and like zEC12 or better cpu
[12:20] <xnox> i don't think hercules has emulation for that
[12:20] <Bercik> I tried newest 4.0
[12:20] <xnox> i wish qemu had system emulation on other platforms, but that's not in for same reasons arm64 foreign emulation is not there
[12:21] <xnox> hm, i did not try 4.0 from github, right?
[12:22] <Bercik> yup,
[12:22] <Bercik> It runs debian 8 with no problems. Same for my rusty z/OS 1.10
[12:23] <xnox> https://github.com/hercules-390/hyperion/issues/39
[12:23] <xnox> we need that for ubuntu
[12:24] <Bercik> Depends on my CPU config. After IPL it ends up with "you need more recent hardware" or Wait State
[12:35] <Bercik> xnox,   --enable-interlocked-access-facility-2=yes|no
[12:35] <Bercik>                           enable/disable Interlocked Access Facility 2
[12:35] <Bercik>                           (default yes)
[12:35] <Bercik> this is mentioned multiple times, when talking about Linux IPL, and this new version seems to has it.
[12:36] <xnox> no idea. i just know that both kernel and glibc use transactional memory on ubuntu (and other modern distros too)
[12:36] <xnox> and that needs transactiona-execution facility
[12:36] <xnox> i don't know what this interlocked access facility is, and/or if transactional memory/execution is implemented using above in hercules
[14:36] <macjl> For infomation, with debconf priority set to medium, I was able to choose a VLAN ID
[14:37] <macjl> But after installation, the configuration was not ste in /etc/network/interfaces
[14:37] <macjl> I had to set it up manually
[14:58] <xnox> macjl, ack. thanks.
[14:58] <xnox> will investigate and will try to fix that up.
[14:59] <xnox> macjl, if you wish you can open a bug report about that with $ ubuntu-bug debian-installer
[14:59] <xnox> or open one on launchpad manually against ubuntu project, debian-installer package, and attach logs from /var/log/installer
[14:59] <xnox> if you can/allowed to share those.
[15:04] <macjl> I'll see if I can
[15:04] <macjl> Now I'm trying to make bonding work with vlan....
[15:08] <xnox> macjl, =))))) it should work, i try to avoid fiddling with things like that, and just defer it to infrastructure team =)
[15:55] <macjl> It worked with VLAN + bonding. I've just moved a VM from IBM KVM to Ubuntu (offline) with no problems :)
[15:57] <macjl> It doesn't seem to work with live migration because of a SELinux problem :
[15:57] <macjl> error: unsupported configuration: Unable to find security driver for model selinux
[16:11] <xnox> macjl, right. in ubuntu we support live migration among our hypervisors (e.g. lxd to lxd, qemu to qemu)
[16:11] <xnox> i don't know if it's possible to move things form z/KVM to Ubuntu live.
[16:12] <xnox> macjl, could you open a bug report about that? because surely we should be able to translate selinux model to apparmor (which is what used to protect qemu on ubuntu) and/or give option to ignore selinux context for migration (sub-optimal, but better than failing outright)
[16:12] <xnox> maybe we can enable selinux in relevant parts of the stack to make migrations work too.
[16:13] <xnox> if you add tag "s390x" to the bug report, I will notice it and can route it appropriately to the right ubuntu teams


[01:51] <bkerensa> jbicha / godbyk : I am going to build the ubuntu docs package now and have someone sponsor its upload
[01:52] <bkerensa> I have a few people I can nag for sponsorship :P
[02:23] <godbyk> bkerensa: Great!
[02:23] <godbyk> bkerensa: Let me know if I can do anything to help.
[02:23] <bkerensa> godbyk: did he tell you what version for the changelog
[02:23] <godbyk> bkerensa: And please try to document the procedure as you go along.
[02:23] <bkerensa> godbyk: I assume 13.04.1?
[02:23] <godbyk> bkerensa: That's what I assumed, as well.
[02:24] <godbyk> bkerensa: I used the following three lines for the changelog entry:
[02:24] <godbyk>   * Merged updated gnome-docs
[02:24] <godbyk>   * Capitalized Dash and Launcher consistently
[02:24] <godbyk>   * Bumped version numbers on the "What's new in Ubuntu 13.04?"  Also, you'll need to take all the screenshots for the html/ stuff to build properly.
[02:40] <godbyk> bkerensa: I'm not sure that the html/ dir is required for the system docs package, however. That might be solely for the website.
[02:40] <jbicha> bkerensa: you should wait until at least Monday evening for the actual upload to give the translators as much time as possible
[02:42] <godbyk> jbicha, bkerensa: which means you'll want to download the latest translations from launchpad a the last moment.
[02:44] <bkerensa> jbicha: make: Nothing to be done for `html'.
[02:44] <bkerensa> jbicha: ok well I will grab the tarball again tomorrow and rebuild again tomorrow
[02:45] <bkerensa> but the build was clean anyways
[02:45] <godbyk> bkerensa: cd html; make
[02:45] <godbyk> bkerensa: it has its own Makefile.
[02:56] <Fudge> hi guys, I have been trying to figure out how to get our documentation for vinuxproject.org into .md files and authored as malard so that we can include on our images to work with Yelp. If anyone may have blogged about this how to achieve I would love to read as my current efforts are not being very successful :D thanks
[03:01] <bkerensa> jbicha: Were you expecting the build to fail btw? Because I got a successful build ;o
[03:05] <godbyk> bkerensa: Since there haven't been many changes this cycle, I would expect the build to succeed since it presumably succeeded for 12.10.
[03:06] <godbyk> bkerensa: There may be some failures in the translations, though. (Though again, there haven't been too many changes there either.)
[03:16] <jbicha> bkerensa: if you didn't include updated translations then the build shouldn't have failed; it's the translations that cause the problems
[03:17] <bkerensa> jbicha: i introduced the current tarball into the branch.... Maybe no changes were made? I havent really looked at translations
[03:17] <bkerensa> jbicha: there were some warnings during the build for some translations saying they couldn't be merged (not sute what thats about) but the build succeeded
[03:18] <jbicha> did you rename the .po files?
[03:18] <bkerensa> jbicha: yeah :)
[03:19] <jbicha> yes the translations tend to have lots of warnings, it's the errors that stop the build that are of high priority
[03:19] <jbicha> maybe yelp-xsl and the other tools are more resilient to broken translations these days too
[03:19] <bkerensa> hmm
[03:19] <bkerensa> well thats good :)
[03:19] <bkerensa> jbicha: you must be busy with a gnomebuntu
[03:19] <bkerensa> ;)
[12:21] <shaunm> Fudge: you author in markdown and want to convert to mallard?
[12:22] <shaunm> bkerensa: regarding the warnings you get when merging translations for documents, those kinds of warnings happen when translators write something that isn't a well-formed xml fragment
[12:23] <shaunm> itstool parses when merging. if it can't parse, it can't merge.
[12:45] <Fudge> shaunm  thanks so much for replying, yes I am hopeful.  Am using this p
[12:45] <Fudge> h
[12:46] <Fudge> whoops url didnt paste: http://www.jpfleury.net/en/software/gedit-markdown.php
[12:47] <Fudge> shaunm  it's very possible I am screwing something simple up, I feel like I need some hand holding at this stage loL
[12:51] <shaunm> Fudge: markdown and mallard are both syntaxes. to write in one and distribute another, you need a converter
[12:51] <shaunm> and now I wish I'd stuck with my work on getting mallard support into pandoc
[12:52] <shaunm> I just don't know of a markdown->mallard converter right now. I'd like to know of one, if somebody has one
[12:56] <Fudge> Oh right, sounds like it would be useful. May I clarify what you ahve said? If I write our stuff in Malard then I can call it with Yelp for our specific documentation to ship on images?
[13:14] <shaunm> correct. Yelp has native support for Mallard, DocBook, HTML, man pages, and info pages. For anything else, you have to convert it into a format Yelp supports.
[13:23] <Fudge> that is very cool mate
[16:31] <bkerensa> jbicha:  Hey so slangasek will sponsor my build but I could just push the final stuff to a branch and MP it right?
[16:31] <bkerensa> like do the make html and make sure the latest translations are imported and then just push that to a branch?
[16:40] <jbicha> there's several different branches, if you're talking about sponsorship I'd just ask slangasek what format he'd prefer to sponsor
[16:41] <jbicha> for the lp:ubuntu-docs branch, yes we need a merge proposal with the updated translations and changelog (and he could possibly just use that to sponsor from)
[18:14] <bkerensa> jbicha: ok
[23:19] <bkerensa-ODS> preparing final MP for raring docs
[23:19] <bkerensa-ODS> sponsorship will occur tonight
[23:21] <godbyk> bkerensa: Great! Thanks for your help!


[00:03] <xnox> stgraber: is lxd on github / linuxcontainers.org yet?
[00:03] <xnox> =)
[00:05] <stgraber> xnox: github.com/lxc/lxd all 0 bytes of it :)
[00:07] <xnox> stgraber: =) cool.
[00:11] <xnox> stgraber: pleaora of people are talking about it, sounds exiting and people are undecided whether it's an NIH or indeed something cooler than docker.
[00:11] <xnox> stgraber: however with lack of public source code for inspection it's hard to tell what it is.
[00:14] <stgraber> well, currently there's very little code available, we've got a python prototype and a Go prototype which each do different things. The plan is to have the Go one be split into pieces and contributed upstream through the usual review process bit by bit rather than have a single massive code dump that nobody can seriously review.
[00:18] <xnox> stgraber: i take it, the go code is/was not written by you?!
[00:18] <hallyn> chuckle
[00:19] <hallyn> xnox: I wrote some of it.
[00:20] <xnox> hallyn: i did bits of gocode for phablet gogotools. How do you like golang so far?
[00:20] <hallyn> xnox: i have issues with the dogmatic refusal to allow me to control goroutines.
[00:20] <hallyn> aside from that, it's a lot of fun
[00:21] <hallyn> i love the multile return values
[00:21] <hallyn> i appreciate the way you build 'classes', basically feels like the way the vfs in the kernel does it
[00:21] <xnox> hallyn: i don't think i've used goroutines correctly (especially asynchronously feeding a channel and synchronising that / calling golang select across them and all that)
[00:22] <xnox> i don't quite like how error handling is done, but i guess that will not change (essentially everything must return an error as one of the multiple return values, and everything must check/bubble it up)
[00:22] <hallyn> right, my problem was i was doing io.Copy() inside goroutines to pass data from console to a socket, then on the other end from a socket to a pty which was hooked to a container using attach,
[00:22] <hallyn> and my problem was that i couldn't find a good way to select(0 so that i  could add a second channel with which to interrupt
[00:23] <hallyn> but it worked out ok with how the attach happens through the lxc go bindings.
[00:23] <hallyn> so yeah, i like it :)
[00:23] <hallyn> better than i thought i would
[00:23] <hallyn> anyway, it's 1:30am here and i should really get to bed - gnight
[00:39] <xnox> night.
[03:57] <RAOF> !regression-alert
[03:57] <RAOF> openjdk security update - https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/1389493
[04:00] <cyphermox> xnox: I see now why you were happy not to touch ppp :)
[04:02] <infinity> doko: ^
[04:26] <slangasek> RAOF: I'm puzzled by that description.  Projects show as broken in eclipse even if they don't use pulse-java.jar?
[04:26] <RAOF> slangasek: Apparently eclipse keeps a list of all the files in the JRE it's got registered and complains if any of them disappear.
[04:27] <slangasek> RAOF: fwiw my understanding from watching from the sidelines was that pulse-java.jar had been superseded by icedtea-sound.jar; I'm not sure how it's anything other than a bug in eclipse that it behaves this way though
[04:27] <RAOF> slangasek: I agree that it does seem to be profoundly stupid behaviour from Eclipse.
[04:27] <slangasek> (of course, we may be stuck working around it in openjdk-7, but I'd like to know why eclipse does this)
[04:28] <slangasek> anyway, no quick rollbacks on this one; I'll assign it to doko for further investigation
[04:28] <RAOF> I have no idea why Eclipse would choose to do this, but my knowledge of Java development is pretty much restricted to “there was a dude on IRC complaining that we broke Eclipse”.
[04:28] <RAOF> Yeah, that was my assessment of the situation.
[07:25] <pitti> Good morning
[07:37] <MasterPiece> pitti, moin :)
[07:48] <pitti> infinity: https://jenkins.qa.ubuntu.com/job/vivid-adt-glibc/7/ARCH=i386,label=adt/console -> looks like fallout from new dpkg?
[07:48] <pitti> dpkg-source: error: binary package stanza libc-bin is using an obsolete Build-Profiles field syntax
[07:49] <Tribaal> guys, how can I help with https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1386455 ? It is a little scary that some potentially serious vulnerabilities have been addressed and not yet packaged...
[07:55] <Mirv> would some core dev be available to review (ack) bregma's first vivid compiz release packaging changes? seems like ok cleanup https://ci-train.ubuntu.com/job/ubuntu-landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A<IP_ADDRESS>+15.04.20141104-0ubuntu1.diff
[07:55] <Mirv> compiz-gnome seemingly got python dependencies since it already had the migration scripts in python, but missed the explicit dependencies
[07:57] <infinity> pitti: Whee.  Probably already fixed in Debian, I'll have a look and either merge or fix and merge.
[07:58] <pitti> infinity: thanks; it's probably trivial, but I haven't looked into that field at all
[08:00] <infinity> Mirv: I assume the removal of debian/patches/99_valid_ccsm_desktop_file.patch coincides with upstream fixing that?
[08:00] <infinity> Mirv: It would be (really) nice if the Debian changelog actually logged the debian changes. :/
[08:02] <infinity> Mirv: The changes (except that patch dropping, which I can't audit on a partial diff) all look sane to me, but I'm going to NACK it based on being sick and tired of changelogs without changes logged.
[08:02] <infinity> Mirv: Which means there's no rationale for the new python dep or the patch being dropped.
[08:03] <Mirv> infinity: yes, the MP states it was moved into the source
[08:03] <infinity> Mirv: The rules, copyright, and language cleanup changes look fine though.
[08:03] <infinity> Mirv: That's lovely that the MP says that, why isn't it in the changelog?  Seriously.
[08:03] <Mirv> bregma: ^ infinity would want better changelogs
[08:04] <infinity> Mirv: Is this a process failure that MP changes should be getting jammed into the changelogs, or an upstream failure that the changelog should be hand-edited to be more verbose?
[08:05] <Mirv> infinity: that's a common problem. it's a process failure that the MP commit messages for the branch are kept shorter than for example the actual accumulated commit messages that were made to the branch.
[08:05] <Mirv> for example here https://code.launchpad.net/~bregma/compiz/fix-lintian-warnings/+merge/240298 it only says "fixed numerous minor Lintian warnings in the Ubuntu packaging" (this gets into debian/changelog), while the description is a lot more verbose and the branch has later commits which say eg "ccsm.desktop: removed deprecated attributes (moved patch inline)" that should have been added to the branch's commit message
[08:06] <infinity> Mirv: Maybe we should get Linus up in here to tell people (with his usual "friendly" style) what good changelogs look like. ;)
[08:07] <infinity> Though, I'm pretty sure that Linus and the Ubuntu CoC are fundamentally incompatible.
[08:14] <Mirv> I see that all around canonical upstreams that the MP:s are well thought out and tested, but the branch commit message is there often just "fixes important bugs" or such
[08:14] <Mirv> infinity: this is also an usability issue in LP. I find it cumbersome that when proposing a branch, only description is asked for, while the commit message is what gets used here. so commit message more naturally always comes as an afterthought "oh right I should fill in something here"
[08:15] <Mirv> instead of it being thoughtfully written at the time of proposing the branch
[08:17] <infinity> Mirv: Well, a branch commit message is often just "pull random crap from George" anyway.  It's the next level down that's interesting.
[08:29] <mardy> Mirv: hi! I added you to this review, I guess it should be pretty familiar changes for you :-) https://code.launchpad.net/~online-accounts/accounts-qml-module/packaging/+merge/240688
[08:34] <smb> Question, I have a package that uses .xz for the orig tarball in Vivid. Now I want to do minor release updates for Utopic and Trusty (where I previously still used .gz). Is it ok to change the compression type of the orig tarball in a MRE upload?
[08:47] <Mirv> mardy: thanks, looking
[09:39] <apachelogger> stgraber: remember the ip problems I had when starting multiple containers at the same time? http://paste.ubuntu.com/8833121/ <- I am no specialist but that output looks rather weird (:
[09:52] <LocutusOfBorg1> Laney, gdcm accepted, can you please rebuild insighttoolkit and insighttoolkit4?
[09:52] <LocutusOfBorg1> (nifti2dicom should wait for them)
[09:52] <mlankhorst> arges: ok re-uploaded mesa. :P
[09:54] <Laney> LocutusOfBorg1: will do later
[09:54] <LocutusOfBorg1> thanks :)
[09:54] <Laney> yw!
[10:01] <infinity> smb: An MRE implies it's a new upstream version, right?
[10:01] <infinity> smb: And thus, a new orig.
[10:02] <infinity> smb: So, sure, compression type really doesn't matter, as long as the tools in the target distro support it (and trusty supports .xz just fine).
[10:02] <smb> infinity, right. 4.4.0 -> 4.4.1
[10:03] <smb> infinity, Ok, then I go forward and use the same orig for all of them. thanks
[10:26] <ochosi> hey folks, if this is the wrong channel, sorry in advance (and please feel free to point me in the right direction), i just quickly wanted to know whether there is a plan on when status.ubuntu.com will be activated for V
[10:39] <doko> pitti, do you understand the marble autopkg test failure?
[11:27] <cjwatson> arges: on vac / conf leave this week, hopefully somebody else can advise
[11:31] <doko> Riddell, ScottK, jibel, pitti: the marble autopkg tests fail very often. any hint on that? for now it's blocking gcc-4.9
[11:31] <pitti> doko: looking now (sorry, had a long doctor appointment, just back)
[11:32] <pitti>   8 - MarbleRunnerManagerTest (Failed)
[11:32] <pitti> that doesn't look like an infrastructure problem, but a real failure?
[11:32] <pitti> it's also holding back qt4-x11
[11:33] <pitti> doko: ah, Riddell already overrode the test
[11:34] <pitti> doko: gcc-4.9 is blocked on gamera; that regressed because apparently distutils is unhappy about parsing the "2.0rc1" version number from pygments (?)
[11:34] <doko> fixed, it's testing for a strict version
[11:34] <pitti> https://jenkins.qa.ubuntu.com/job/vivid-adt-gamera/6/ARCH=amd64,label=adt/console
[11:37] <pitti> infinity, cjwatson: can you make any sense of this? http://paste.ubuntu.com/8834547/
[11:37] <pitti> i. e. why don't the -proposed binaries get cleaned up?
[11:38] <Riddell> doko: upstream says it fails often anyway because it tries to download stuff so I overrode it
[11:38] <pitti> doko: "fixed" -> i. e. there's a new upload of pygments/distutils/whatever in -proposed which resolves this? or does this need further investigation?
[11:38] <Riddell> pitti: ↑
[11:39] <pitti> tests can downlaod stuff now (through the proxy), but that's apparently not what marble stumbled over
[12:01] <brainwash_> mdeslaur: isn't bug 1312219 a critical one? I'm somewhat surprised that there is still no official or ubuntu-only fix
[12:02] <mdeslaur> brainwash_: it's a hard problem to solve, we can't redistribute it like we do with the ordinary flash, so we can't rely on a version being available somewhere as when new chrome versions come out, they remove the old ones
[12:03] <mdeslaur> brainwash_: if you have a good idea on how to solve that, feel free to comment in the bug
[12:05] <brainwash_> recommending google chrome is the only solution as of now I guess
[12:05] <brainwash_> also, chromium-browser updates are delayed most of time
[12:06] <brainwash_> which makes chromium-browser + pepperflashplugin-nonfree a dangerous combination
[12:07] <mdeslaur> brainwash_: yep, which is why they are both in universe still
[12:07] <Tribaal> brainwash_: mdeslaur: any news on chromimu 38? 37 has quite a few secuirty problems...
[12:07] <Tribaal> I am glad to help if I can
[12:08] <brainwash_> bug 1386455
[12:08] <mdeslaur> Tribaal: it's being worked on, as usual, it refuses to compile on some of our archs, so chad is working hard on getting it fixed
[12:08] <mdeslaur> we have someone full-time on getting chromium built
[12:09] <Tribaal> mdeslaur: ahhh I understand the problem now. I didn't realize it was a compilation problem.
[12:09] <Tribaal> mdeslaur: thanks for the answer
[12:10] <mdeslaur> you can monitor progress here: https://launchpad.net/~canonical-chromium-builds/+archive/ubuntu/stage/+packages
[12:10] <mdeslaur> also, upstream switched to requiring llvm to compile it, so chad has been working on getting llvm built for older releases, etc.
[12:11] <brainwash_> sadly I cannot help with fixing those issue
[12:12] <brainwash_> but I assume that chromium and the pepperflashplugin are quite popular
[12:13] <brainwash_> maybe the update policy for both packages should be discussed (somewhere)
[12:19] <ypwong> xnox, cjwatson: could you take a look at bug 1330410? not sure what wrong, but from the package I built myself, the bug does not exist.
[12:20] <ypwong> thanks
[12:27] <Riddell> mdeslaur: further security update in bug 1389665 goes public tomorrow
[12:28] <mdeslaur> Riddell: ack, subscribed ubuntu-security-sponsors
[12:28] <mdeslaur> Riddell: thanks
[12:31] <didrocks> Riddell: hey, not sure if you saw my ping the other day, but I plan to have a bluez5 session at UOS. Would be nice to have some kubuntu guys to sync up (from what I read, everything is ready from the KDE-front to work with bluez5)
[12:32] <Riddell> didrocks: oh yes, I asked a bit and didn't get any answer, I'll ask louder
[12:34] <didrocks> thanks :)
[12:34] <cjwatson> pitti: they need to migrate but have unsatisfiable dependencies; see near top of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[12:35] <cjwatson> ypwong: not until next week at least, on vacation / conference leave
[12:35] <pitti> cjwatson: right, but why is britney migrating the version at all? I thought it should wait for all arches?
[12:37] <cjwatson> pitti: it only waits for things that are out-of-date
[12:37] <cjwatson> pitti: so if only those first four architectures had ever been built first time round, it wouldn't have considered that it needed to wait for the remaining two
[12:37] <pitti> ah
[12:37] <pitti> jibel: ^ FYI
[12:38] <infinity> cjwatson: Although, it's broken anyway, since it copied armhf, which has the same problem.
[12:38] <infinity> cjwatson: I presume because it's just a source-with-binary copy, and the armhf build raced in under the wire.
[12:38] <infinity> (Though, how ppc64el didn't, I don't know...)
[12:39] <cjwatson> Could be, haven't gone back to analyse
[12:41] <infinity> Seems to come down to libfftw3 being broken on some arches.
[12:46] <infinity> Oh, not broken, just missing longdouble support on some.
[12:46] <infinity> Retrying arm64 and ppc64el should work, armhf will still fail.
[13:28] <mardy> Mirv: I updated https://code.launchpad.net/~online-accounts/accounts-qml-module/packaging/+merge/240688
[14:24] <stgraber> apachelogger: hmm, yeah, that looks like a lxc-info bug :) Can you report that?
[14:36] <ypwong> cjwatson, ok, no hurry, perhaps xnox will be able to check the bug since he did the last upload of that package
[14:45] <xnox> ypwong: highly unlikely. Maybe stgraber or infinity would step in to do it =)
[15:52] <bdmurray> seb128: the file-roller retraces fail due to missing debug symbol packages for file-roller
[15:52] <bdmurray> seb128: http://ddebs.ubuntu.com/pool/main/f/file-roller/ notice no amd64 / i386 for the utopic package version
[15:53] <seb128> bdmurray, hum, do we know why?
[15:53] <seb128> bdmurray, I guess we need a no change rebuild to fix that?
[15:54] <bdmurray> seb128: yeah, I did a few uploads during the sprint before release didn't get to file-roller
[15:55] <bdmurray> pitti: is there some way to get utopic amd64 and i386 ddebs for file-roller?
[15:55] <bdmurray> pitti: we have them for every other arch...
[16:03] <seb128> bdmurray, if we need an upload I'm just going for a bugfix worth SRUing so we don't do an upload for nothing
[16:04] <bdmurray> seb128: alright, sounds good
[16:21] <Laney> LocutusOfBorg1: okay, got some time now
[16:21] <Laney> what's the first level?
[16:30] <LocutusOfBorg1> Laney, I would say insighttoolkit and insighttoolkit4
[16:31] <LocutusOfBorg1> the second/last level should be nifti2dicom, but itk4 takes almost 10 hours to build...
[16:33] <Laney> I made a transition tracker entry
[16:33] <Laney> let's see what it says
[16:47] <LocutusOfBorg1> Laney, http://people.canonical.com/~ubuntu-archive/transitions/
[16:47] <LocutusOfBorg1> I don't see it...
[16:48] <Laney> you need to wait for it to update
[16:48] <Laney> see the time at the bottom
[16:48] <LocutusOfBorg1> oh yes ;)
[16:48] <LocutusOfBorg1> I don't know how much time takes ben to update :)
[17:10] <Laney> LocutusOfBorg1: there
[17:14] <LocutusOfBorg1> mmm strange, so nifti2dicom doesn't need a rebuild=
[17:14] <LocutusOfBorg1> seems legit
[17:16] <Laney> no it only depends on libinsighttoolkit4.6
[17:17] <LocutusOfBorg1> yep, I though it was a level2, but yes, doesn't need a rebuild
[17:21] <eto> hello i would like to know if it is possible to run systemd on current ubuntu server LTS
[17:21] <eto> and if yes how hard it would be to switch to it?
[17:23] <eto> does such switch require compiling it from source?
[17:24] <LocutusOfBorg1> ubuntu 14.04 LTS has systemd in the repository
[17:24] <LocutusOfBorg1> switching to it from an existing installation might be hard, because I got some upgrades (mainly in debian testing) that didn't boot up after the reboot
[17:26] <Quintasan> LocutusOfBorg1: Trusty has no candidate for systemd package if I'm not mistaken
[17:26] <LocutusOfBorg1> https://launchpad.net/ubuntu/+source/systemd
[17:26] <LocutusOfBorg1> the package seems built for trusty
[17:27] <Quintasan> LocutusOfBorg1: I believe it is crippled as in it's lacking systemd binary
[17:27] <LocutusOfBorg1> https://wiki.ubuntu.com/systemd
[17:27] <LocutusOfBorg1> Quintasan, don't know honestly
[17:27] <LocutusOfBorg1> :)
[17:28] <LocutusOfBorg1> I think pitti has the correct answer ;)(
[17:28] <Quintasan> Yeah, it's crippled in Trusty
[17:28] <LocutusOfBorg1> I won't install that think unless forced to :)
[17:28] <Quintasan> I believe I wanted to give it a go before the whole Debian stuff happened and I no packages provide the binary
[17:34] <Bluefoxicy> Sometimes, I really wonder if it's a waste of effort to respond to the mailing list with a logical, well-thought argument; or if I should just hit REPLY ALL and type "Your mom."
[17:38] <eto> LocutusOfBorg1: well i am not really familiar with ubuntu-server per se but given it's linux and systemd is inevitable i would like to use it at least
[17:38] <eto> LocutusOfBorg1: as external admins use ubu-server i was thinking maybe i could at least get some systemd features just by replacing init
[17:39] <LocutusOfBorg1> eto, I don't know what to say, I would like to give a try with debian jessie, with systemd by default
[17:39] <LocutusOfBorg1> maybe you can test your system, and when ubuntu switch you can go back
[17:39] <eto> LocutusOfBorg1: actually our requirements are minimal
[17:40] <eto> LocutusOfBorg1: i mean we probably don't neet everything included in ubu-server - so maybe it would be wiser to interview admins if they would be okay with debian jessie?
[17:40] <Bluefoxicy> jessie?  is Debian using Pokemon for names now?
[17:41] <eto> LocutusOfBorg1: are there big differences between debian and ubuntu-server ? besides extra tooling i guess
[17:42] <LocutusOfBorg1> Bluefoxicy, https://www.google.it/search?q=Jessie+toy+story&safe=off&client=ubuntu&hs=F7Q&channel=fs&tbm=isch&imgil=dNwnIGUOfxNI4M%253A%253B8TFYPGjXPwr_0M%253Bhttp%25253A%25252F%25252Fdisney.wikia.com%25252Fwiki%25252FFile%25253AJessie_from_toy_story_2.png&source=iu&pf=m&fir=dNwnIGUOfxNI4M%253A%252C8TFYPGjXPwr_0M%252C_&usg=__N8VW64Q0nKA4RjuvlHcNS9WT7cU%3D&biw=1920&bih=954&ved=0CDMQyjc&ei=bmFaVP3AF4eR7Abm8YCwBQ#facrc=_&img
[17:42] <LocutusOfBorg1> dii=_&imgrc=dNwnIGUOfxNI4M%253A%3B8TFYPGjXPwr_0M%3Bhttp%253A%252F%252Fimg4.wikia.nocookie.net%252F__cb20130718165011%252Fdisney%252Fimages%252Fd%252Fdf%252FJessie_from_toy_story_2.png%3Bhttp%253A%252F%252Fdisney.wikia.com%252Fwiki%252FFile%253AJessie_from_toy_story_2.png%3B1200%3B1052
[17:42] <LocutusOfBorg1> oops http://img4.wikia.nocookie.net/__cb20130718165011/disney/images/d/df/Jessie_from_toy_story_2.png
[17:42] <LocutusOfBorg1> jessie is from toy story, like all the other debian names
[17:42] <LocutusOfBorg1> (excluding rc-buggy lol)
[17:43] <Bluefoxicy> o.o
[17:43] <Bluefoxicy> that URL is amazing
[17:46] <LocutusOfBorg1> bdrung_work, do you plan to merge this? https://code.launchpad.net/~uwelk/vlc/daily-packaging/+merge/240758
[17:46] <LocutusOfBorg1> adding protobuf-compiler should fix the building issues
[17:47] <LocutusOfBorg1> https://code.launchpad.net/~uwelk/vlc/daily-packaging/+merge/240759 this one
[17:48] <Bluefoxicy> so, I work at a major media company
[17:48] <eto> so basically from quick search jessie seems like lighter alternative to ubuntu server is that right?
[17:48] <Bluefoxicy> we've found that the ffmpeg precompiled, static-linked binary is like... it takes 5 seconds to encode a video that takes 35-45 seconds on the same version out of the repos in Fedora or Ubuntu
[17:49] <Bluefoxicy> H.264 with AAC
[17:49] <eto> Bluefoxicy: with static buld all filters are included into single binary?
[17:49] <eto> build
[17:49] <Bluefoxicy> eto:  Yes, but that only affects dynamic linking; it doesn't affect runtime speed
[17:50] <Bluefoxicy> a static built Openoffice.org would load immediately, instead of in 17 seconds; but it would operate all runtime functions at the same speed as the dynamic binary
[17:50] <eto> Bluefoxicy: but if you use lot of execs from external script it might affect processing right? ffmpeg
[17:50] <Bluefoxicy> no
[17:50] <Bluefoxicy> the single binary runs for the full encoding period, one run.
[17:50] <Bluefoxicy> we're talking about bulk mathematics processing, not large amounts of shell script invocation
[17:51] <eto> yes but it starts in 5 seconds without linking stage right?
[17:51] <Bluefoxicy> no
[17:51] <eto> roger
[17:51] <Bluefoxicy> it completes the full task of encoding the video in 5 seconds
[17:51] <eto> how come?
[17:51] <Bluefoxicy> that's what I want to know.
[17:52] <Bluefoxicy> There was a point in time when Ubuntu's firefox was slow as living hell, and the static build of Firefox was snappy; it was so bad that nearly everyone had installed the Firefox downloaded from mozilla.org at the time
[17:52] <eto> Bluefoxicy: are you using ubuntu server in your stack?
[17:52] <ogra_> Bluefoxicy, likely because you only build it for one arch and dont need to take ppc, ppc64, arm64 or whatever into account ... which might add other code paths and patches to generalize the code a bit more
[17:52] <Bluefoxicy> I've tested with multiple
[17:52] <Bluefoxicy> ogra_:  those are defined with conditional compilation
[17:52] <ogra_> some are, some arent
[17:53] <Bluefoxicy> also, code existing and code being run are two different things.  You can compile in as much code as you want without making a program slower, if you don't ever call that code
[17:53] <ogra_> also are you sure you use the exact same toolchain with exactly the same options ? (which are also a selection to make it work on as many arches as possible)
[17:53] <Bluefoxicy> ppc and ARM patches tend to provide an alternate code path, often hand-optimized assembly.  Similarly, mmx and sse patches use wrapper functions or direct assembly
[17:54] <Bluefoxicy> ogra_:  regardless, none of that should cause one compilation of an application to run 5-10 times faster than another.
[17:54] <Bluefoxicy> as well, libav is different than ffmpeg in many ways, but it's not clearly ridiculously slow; and the ffmpeg in fedora is also slow.
[17:55] <ogra_> you are heavily using math ... it will definitely make a difference if you have your code adjusted for generic usage vs very specific optimization for just one arch
[17:55] <Bluefoxicy> yeah, but the generic one is the one that's fast.
[17:55] <ogra_> you said the archive one isnt fast
[17:55] <ogra_> while your personally compiled one is
[17:58] <Bluefoxicy> ogra_: https://www.ffmpeg.org/download.html these are fast (particularly, the linux static build)
[17:58] <eto> ty guys
[17:59] <Bluefoxicy> ogra_:  anyway, my point is there should be some investigation about why libav in Ubuntu is ridiculously slow compared to the release provided; it's investigation I don't know how to do
[17:59] <Bluefoxicy> and I am now in webinar for negotiation for 5 hours, sorry later.
[17:59] <ogra_> well, i would start comparing the patch sets vs the source that static package was built from
[18:00] <ogra_> if you are sure you use the same toolchain for both, it can only be patches
[18:08] <Bluefoxicy> wow
[18:08] <Bluefoxicy> that guy responded to the list with "fuck you", and then called me a femenist and talked about Tim Cook ruining the world for "regular men" o.o
[18:08] <Bluefoxicy> just wow.
[18:09] <Bluefoxicy> and... now he's advocating murder.
[18:09] <Bluefoxicy> Somebody please check the lists.
[18:11] <Bluefoxicy> mhall119:  Thanks.
[18:11] <mhall119> yeah, trolling troll is trolling, I'm working on it
[18:28] <rickspencer3> slangasek, around at all?
[18:28] <slangasek> rickspencer3: hi
[18:28] <rickspencer3> slangasek, there seems to be some unfortunate exchange going on on @ubuntu-devel-discuss
[18:28] <slangasek> mmm
[18:28] <ogra_> rickspencer3, mhall119 is on it
[18:28] <rickspencer3> it doesn't seem to really have any value to the community, I was wondering if there options to stop it?
[18:28] <rickspencer3> ogra_, thanks
[18:29] <rickspencer3> slangasek, nm
[18:29] <rickspencer3> :)
[18:29] <slangasek> ok
[18:29] <ogra_> though we might need a list admin to block the troll
[18:29] <slangasek> I'm sure there are options, but I don't know who the list admins are - I'm not
[18:29] <rickspencer3> ok
[18:29] <rickspencer3> I think if mhall119 is on it, then it will be handled professionally and quickly
[18:29] <ogra_> ubuntu-devel-announce list run by cjwatson at ubuntu.com, steve.langasek at ubuntu.com, adconrad at ubuntu.com
[18:29]  * rickspencer3 backs away slowly
[18:30] <ogra_> slangasek, the list disagrees :)
[18:30] <rickspencer3> boom
[18:30] <rickspencer3> :)
[18:30] <slangasek> ogra_: you may notice that -announce != -discuss
[18:30] <slangasek> ;)
[18:30] <ogra_> oh, wait
[18:30] <ogra_> sorry ...
[18:30]  * ogra_ blames evulotion :P
[18:30] <slangasek> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss/ says it's mhall119's problem!
[18:30]  * slangasek wipes his hands
[18:30] <ogra_> haha
[18:30]  * rickspencer3 exercises mute feature on thread
[18:30] <mhall119> slangasek: it is now
[18:32] <ogra_> argh
[18:32] <ogra_> he moved to ubuntu-users
[18:36] <mitya57> systemd threads — now on every mailing list near you
[18:41] <dobey> multiprocessing via email
[18:44] <mitya57> (as usual, incorrectly capitalized)
[19:13] <Bluefoxicy> man this is ridiculous.  I'm trying to update a printer firmware, but it uses a windows software program instead of giving me a firmware update file to upload to the printer
[19:13] <Bluefoxicy> so I tried to install the printer on windows.
[19:14] <Bluefoxicy> ... ... ... yeah uh.  Why does hardware just plug in and work on Ubuntu, but require some arcane incantation to make work on Windows?
[19:15] <sarnold> "arcane incantation"? what could be simpler than googling for "<printer model number> download drivers", clicking on the first 438 megabyte file you can find, double-clicking it to start an installer, clicking "next" nine times, uninstalling the three browser toolbars you get, and then rebooting?
[19:19] <mdeslaur> sarnold: you forgot the step where you run the weird registry cleaner tool because you *gasp* plugged the printer in _before_ installing the driver
[19:19] <sarnold> mdeslaur: haha you don't make that mistake twice! :)
[19:20] <teward> is there a way to see what udev rules get installed on a Vivid system by default...?
[19:21] <teward> i'm trying to figure out a hardware support problem i've observed in Trusty and Utopic with certain equipment, and checking the udev rules accordingly
[19:41] <Bluefoxicy> sarnold:  the problem is I installed the print driver on Windows, and it says it doesn't know what to do with it.  I downloaded the print driver software package, and it says it can't find the printer.  And so on and so forth.  "What's this funky USB device?"  "Here's the driver"  "I don't know how to talk to it to see if the driver works"  "Okay, here's the software the manufacturer sent"  "Where's the printer?  I can't i
[19:41] <Bluefoxicy> nstall the drivers if I can't see the printer!"
[19:41] <Bluefoxicy> sarnold:  plug it into an Ubuntu box.    o.o
[19:42] <Bluefoxicy> and yet people still mock me about the strange shell commands supposedly required to get a sound card working on Linux.  :|
[19:42]  * Bluefoxicy is frustrated today.
[19:43] <sarnold> Bluefoxicy: we haven't even had to edit modelines in a decade.. sheesh :)
[19:45] <dobey> sarnold: go buy a 4k monitor and try to get it working on displayport :)
[19:46] <dobey> sarnold: if you don't need to edit modelines, you just need better hardware ;)
[19:47] <sarnold> dobey: hahaha :)
[19:47] <sarnold> actually, I've got the 4k tv.. I doubt this intel graphics in my laptop could actually drive it at that resolution, but it might be fun to see how far it can get
[19:48] <dobey> is it ivybridge or haswell?
[19:48] <sarnold> "Intel(R) Core(TM) i7-3520M CPU"
[19:48] <sarnold> not haswell but I also don't know about ivybridge :)
[19:49] <dobey> you might be able to do it on hdmi
[19:50] <dobey> it's ivybridge
[19:50] <Bluefoxicy> i plugged my computer into a 39 inch TV from LG
[19:50] <Bluefoxicy> HDMI on my computer
[19:50] <dobey> ivybridge doesn't do displayport 1.2 i don't think, which is required for the multi stream transport used by 4K monitors
[19:51] <dobey> eh 39" is way too big to use at a desk
[19:51] <ogra_> depends on the thickness of your glasses
[19:52] <sarnold> dobey: oh, cool, though all I've got for outputs is minidisplay port and VGA
[19:53] <dobey> ogra_: would depend more on the curvature than the thickness. you'd need fisheye lens to be able to see the whole screen from so close :)
[19:53] <ogra_> :)
[20:24] <pitti> desrt: hey Ryan!
[20:24] <desrt> hihi
[20:25] <pitti> desrt: would you mind doing another systemd-shim upstream release?
[20:25] <desrt> no problem
[20:25] <desrt> for the security policy thing?
[20:25] <pitti> desrt: I fixed several bugs, amongst them the grave Debian RC one
[20:25] <desrt> there was an RC bug?
[20:25] <pitti> desrt: yeah, see git log
[20:25] <pitti> desrt: I was also looking into bug 1359439
[20:25] <desrt> thanks :)
[20:26] <pitti> desrt: but despite looking really simple, it's a can of worms
[20:26] <desrt> ...like most things here
[20:26] <shirgall> Yeah, I saw that one this morning.
[20:26] <pitti> desrt: I have a patch which "fakes" those units, but then this requires implementing even more properties/API, etc.
[20:26] <pitti> desrt: so I think it's better to do a release now, calm down the debian folks a bit, and tackle this for release 10
[20:26] <desrt> pitti: sounds like you were in the same area of pain that i was
[20:27] <desrt> pitti: will roll a release right now... i have a few minutes :)
[20:27] <pitti> desrt: if you have some mins to cross-check my commits to see that I don't anything profoundly stupid, that'd be welcome of course
[20:27] <desrt> you in fact fixed what i had been working on before (before i got distracted to other things)
[20:27] <pitti> desrt: otherwise, I tested it pretty thoroughly on my workstation and in a VM with various scenarios, and the logind session cleanup works really nicely now
[20:27] <desrt> pitti: isn't the usual pattern to ask for this before committing? :)
[20:28] <pitti> desrt: *shrug*, github allows push -f :) but yeah, if you prefer that I can also work in a branch
[20:28] <desrt> pitti: i'm sure this is all quite fine
[20:28] <desrt> don't overestimate how much i care about this project
[20:28] <desrt> which is: not much :)
[20:29] <pitti> desrt: oh, were you working on the notify_on_release stuff, too?
[20:29] <desrt> ya
[20:29] <desrt> i'm happy that you beat me to it though
[20:29] <pitti> desrt: care> well, this is mostly for Debian's benefit at this point, jessie freeze is today
[20:29] <desrt> it was getting can-of-wormsy as well
[20:29] <xnox> stgraber: Montreal folks are so vicious, it's been a year now, and the bug reporters cannot get used to the fact that America/Toronto & America/Montreal got merged into a single timezone in zone.tab - "America/Toronto - Ontario & Quebec - most locations"
[20:29] <pitti> desrt: yeah, took me a while to fully understand what systemd/logind are doing there
[20:29]  * xnox closed 3 bug reports now.
[20:30] <pitti> slangasek: ^ on that note, do you want to package systemd-shim 9 (bug refs are in the git changelog), or want me to?
[20:30] <pitti> Maintainer: and all that
[20:30] <desrt> pitti: looks like there are some compiler warnings here
[20:30] <slangasek> pitti: you can probably get to it sooner than me, I'm happy for you to and also add yourself as an uploader ;-)
[20:30] <pitti> oha? I didn't spot any, sorry
[20:30] <pitti> slangasek: ack
[20:30] <slangasek> pitti: and thanks for sorting out these bugs!
[20:30] <desrt> implicit declarations of g_access and perror
[20:30] <desrt> i'll clean them up
[20:30] <pitti> slangasek: cheers
[20:31] <pitti> desrt: whoops
[20:31] <desrt> pitti: fwiw, don't use g_access()
[20:31] <desrt> this is only useful if your program is intended to be portable to windows
[20:31] <pitti> desrt: EAFP instead of LBYL?
[20:31] <desrt> since otherwise it is just an alias for access()
[20:31] <pitti> ah
[20:32] <pitti> desrt: I got into a habit of using that for glib-y stuff, fewer includes etc.
[20:32] <pitti> is there any downside to it?
[20:32] <desrt> pitti: you need to include gstdio.h for this one :)
[20:32] <desrt> since it is only a #define alias for the standard library function
[20:32] <desrt> (so you still need the system headers)
[20:32] <pitti> desrt: I just built it again, and get zero warnings; but I just ./configure'd with the defaults, so maybe I'm missing some extra warning opts that you specified?
[20:33] <desrt> pitti: i did the same, but i'm on fedora
[20:33] <desrt> so maybe my gcc is stricter by default
[20:33] <pitti> desrt: ah, I'm on vivid
[20:33] <stgraber> xnox: well, it'd help if clicking on Montreal on the map would actually do something rather than give you an empty timezone :)
[20:33] <stgraber> xnox: so yeah, the two were merged, but badly so :)
[20:33] <desrt> pitti: diversity win, i guess
[20:33] <pitti> heh
[20:34] <pitti> desrt: oh, and we don't install the d-bus policy any more, so perhaps we should remove it upstream as well?
[20:35] <pitti> desrt: it was only really useful for a split systemd-services build, but nobody does that any more
[20:35] <xnox> stgraber: our plan (b) was to ship 10'000 top locations on the cd and pick from them. Because we also have a persistent request to "add Beijing" instead of "Shanghai". Man, politics are hard - google maps have three maps for ukraine at the moment.
[20:35] <pitti> desrt: if you want to, I can commit that cleanup for 9 still (it's trivial)
[20:35] <desrt> pitti: sure
[20:35] <desrt> i just pushed the warnings fixes
[20:39] <pitti> desrt: policy drop fixed
[20:39] <pitti> desrt: err, what a grammar -- policy dropping committed
[20:40] <pitti> desrt: peux-tu préparer la nouvelle version neuf maintenant ? :-)
[20:40] <desrt> uh... oui!
[20:40] <desrt> (i hope)
[20:43] <desrt> so we have an interesting problem
[20:44] <desrt> my homedir on gnome.org has mysteriously vanished
[20:45] <pitti> WT...H?
[20:46] <desrt> #sysadmin says they know about it and are investigating
[20:46] <desrt> want me to email you the tarball or something? :)
[20:46] <pitti> desrt: WFM, or people.c.c. or whatever
[20:47] <desrt> first let's get this out of the way:
[20:47] <desrt> f1d69073037cc48562dd25d10ba069ff92f759381fa79042c5be4248b9c56e78  systemd-shim-9.tar.xz
[20:51] <pitti> desrt: cheers! got it
[20:57] <pitti> desrt, slangasek: uploaded
[20:57]  * pitti waves good night, take II
[20:57] <sarnold> night pitti :)
[20:59] <bdmurray> slangasek: any ideas about bug 1384946?
[21:07] <desrt> pitti: cheers
[22:14] <infinity> hallyn: Why is there no qemu-kvm on arm64 and ppc64el?
[22:38] <hallyn> infinity: does 'qemu-system-ppc64 --enable-kvm' work?
[22:39] <hallyn> if so, then it's just bc we need to add those arches to the qemu-kvm pkg, so i should see if we can do that straight in debian
[22:45] <infinity> hallyn: Yes, it does.
[22:46] <infinity> hallyn: (Only on a subset of machines, but that's no different from x86, their subset is just larger)
[22:48] <infinity> hallyn: The description for qemu-kvm is also a lie. :P
[22:48] <infinity> hallyn: Or does that get arch-specific mangling at build time?
[22:49] <hallyn> which part is a lie?  it is in fact currently a wrapper script only around qemu-system-x86
[22:49] <infinity> hallyn: Oh.  So, that's entirely wrong, then, that it's built on arm, powerpc, and sparc.
[22:50] <infinity> hallyn: I would have epxected it to depend on qemu-system-${native} and then wrap appropriately.
[22:50] <infinity> hallyn: So we have a one-stop shop to tell people "if you want qemu w/ kvm capabilites on any arch, just apt-get install qemu-kvm" instead of having the end user map machine arch and qemu-system-arch.
[22:51] <mwhudson> oh hai
[22:52] <mwhudson> fwiw, devstack needs to do exactly this
[22:52] <mwhudson> it currently installs qemu-kvm
[22:53] <mwhudson> for my arm64 patches i install qemu-system but that's overkill
[22:53] <mwhudson> i wonder what the nova packaging does...
[22:53] <infinity> mwhudson: So, the short term solution is a local mapping of arch:arch.
[22:54] <mwhudson> oh right, installing nova doesn't get you a hypervisor, you get to decide
[22:54] <infinity> mwhudson: So on arm64, you install qemu-system-arm, on ppc64el, you install qemu-system-ppc, etc.  But fixing qemu-kvm is the right answer, IMO.
[22:54] <mwhudson> infinity: ack
[22:54] <mwhudson> infinity: shall i file a bug on +source/qemu
[22:54] <mwhudson> ?
[22:54] <infinity> Plus, installing qemu-system-foo doesn't tell you what command you need to run to make it work.
[22:54] <infinity> Which the kvm wrapper fixes.
[22:55] <infinity> mwhudson: If you want to summarize the above and file a bug, that would be great.
[22:55] <mwhudson> i guess libvirt has that knowledge somehow?
[22:55] <infinity> mwhudson: Yeah, if you're running through libvirt, it's supposed to know.
[22:55] <hallyn> infinity: agreed, it'd be good to generalize that
[22:55] <hallyn> yeah libvirt just round qemu-system$arch --enable-kvm
[22:56] <hallyn> really qemu-kvm just providses a wrapper script for the lazy
[22:56] <hallyn> like me
[22:56] <infinity> hallyn: The wrapper script is less interesting to me (though we should fix it at the same time), it's the packaging shortcut that's nice.
[22:56] <infinity> hallyn: I'd rather depend on "qemu-kvm" for native support than "qemu-system-foo [foo bar], qemu-system-quux [quux baz], etc"
[22:58] <hallyn> true
[22:58] <hallyn> yeah mwhudson pls file the bug and while i have scant days left in 2014 i'll try to get that fixed in vivid
[23:00] <infinity> hallyn: And, FWIW, if we fix it sanely in vivid, I'd happily accept (and even encourage) an SRU to trusty and utopic with the same change.
[23:01] <infinity> Would be great if HOWTOs can just say "Step 1: install qemu-kvm" and it works on all arches.
[23:01] <infinity> Well, all arches with KVM support, but that happens to be all the ones we ship (plus sparc, apparently).
[23:02] <mwhudson> infinity, hallyn: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1389897
[23:04] <mwhudson> i think even my packaging skills might be up to fixing this
[23:04] <mwhudson> it's just a matter of sprinkling []s in qemu-kvm's Depends: line, right?
[23:06] <hallyn> "plus psarc, apparently" - wut?
[23:06] <hallyn> mwhudson: i'm abroad this week so if you don't mind then by al lmeans please do
[23:08] <slangasek> bdmurray: 1384946> doesn't that show that the user has an old, pre-trusty version of gnuplot installed?  trusty has 4.6.4-2, not 4.4.3-0ubuntu3
[23:09] <slangasek> ah
[23:09] <slangasek> you noted this already
[23:09] <slangasek> so, hmm, no specific ideas here, but I guess we should fix the precise->trusty dist-upgrade path for it if possible
[23:14] <infinity> mwhudson: That, and fixing the description to be arch-agnostic.  And, the harder part, fixing the wrapper to DTRT (perhaps generating it at build time, rather than having complex case statements)
[23:15] <mwhudson> oh right, the wrapper
[23:17] <infinity> mwhudson: And dropping /usr/bin/qemu-system-x86_64-spice and /usr/bin/kvm-spice from !x86
[23:17] <mwhudson> fetching git://anonscm.debian.org/pkg-qemu/qemu.git is taking aaages
[23:18] <infinity> mwhudson: Oh, I'd just work from the vivid sources, throw a patch at hallyn, and let him resolve it with git. :P
[23:18] <infinity> mwhudson: But I'm lazy that way.
[23:20] <mwhudson> ehh the kvm wrapper is only installed on x86 it seems
[23:20] <mwhudson> even though the package is built on various arches
[23:21] <infinity> mwhudson: So, a first cut could just be to change the deps, but the right answer is to make the wrapper work everywhere, IMO.
[23:22] <hallyn> infinity: mwhudson: yeah the ubuntu-devel branch of git://anonscm.debian.org/pkg-qemu/qemu.git should be identical to the vivid sources, so if you want to jus tpost a debdiff to the bug i'll work out the git bits and try to convince mjt it's a good idea for debian too :)
[23:22]  * hallyn out - gnight
[23:22] <mwhudson> the clone has finished now
[23:25] <mwhudson> er
[23:26] <mwhudson> is there a reason why it depends on qemu-system-x86 (>= 1.7.0+dfsg-2~) rather than (= ${binary:Version}) ?
[23:26] <doko> great, now gcc-4.9 migration is blocked by some r-cran stuff ... https://jenkins.qa.ubuntu.com/job/vivid-adt-r-cran-surveillance/lastBuild/ARCH=amd64,label=adt/console
[23:27] <doko> pitti, jibel: ^^^ this definitely doesn't scale ....
[23:30] <mwhudson> infinity: does qemu-system-ppc cover ppc64el?
[23:30] <infinity> mwhudson: Yeahp.
[23:31] <infinity> mwhudson: For powerpc, ppc64, and ppc64el, it should all be 'qemu-system-ppc64 --enable-kvm' in the wrapper.
[23:31] <infinity> mwhudson: If there are 32-bit systems with KVM support, they're outliers, and I'll let BenC whine about them. :P
[23:32] <BenC> infinity: They’re far from outliers
[23:32] <infinity> mwhudson: I assume that dep was originally because of the Breaks/Replaces there too (as files moved around), but (= ${binary:Version}) would probably make more sense if the intent is to use qemu-kvm to install the right qemu-system.
[23:32] <BenC> But I can’t get Canonical to bother with anything I’m doing so, have at it
[23:32] <infinity> BenC: Well, I'm not regressing anything here, this already doesn't work right.  But if we can come up with a way to make the wrapper DTRT, do let's.
[23:33] <infinity> BenC: We could key off 'uname -m' on powerpc, and call the right qemu.
[23:34] <BenC> infinity: Check CPU type in /proc/cpuinfo. If it’s e500mc, use qemu-system-ppcemb
[23:34] <infinity> BenC: Oh, there's a special build for emb?
[23:34] <BenC> If if’s `uname -m` == ppc and not e500mc, then use whatever else
[23:34] <infinity> So there is.
[23:34] <BenC> infinity: It has all the right mojo to emulate a n E500 machine and connect to the right kvm bits
[23:35] <BenC> e500 or e500mc that is
[23:35] <infinity> BenC: Want to pastebin a cpuinfo from such a machine?
[23:36] <mwhudson> so if feels like mv debian/kvm debian/kvm.x86, vim debian/kvm.aarch64 etc etc and install the right one?
[23:36] <mwhudson> *it
[23:36] <mwhudson> or is ppc the only snowflake and we can do the others with sed?
[23:37] <infinity> mwhudson: Others may be snowflaky in Debian (like mips*, perhaps)
[23:37] <BenC> infinity: http://pastebin.ubuntu.com/8842972/
[23:37] <infinity> mwhudson: So, having one file per arch, and mangling as needed seems the right path.
[23:37] <BenC> That other would show cpu: e500v2"
[23:38] <BenC> Which would use the same binary
[23:38] <infinity> mwhudson: For most, it should look identical to the current x86 one, for ppc, it'll be a bit more involved.
[23:38] <BenC> It’s self detecting for the host
[23:38] <infinity> BenC: Are there any e500* that wouldn't want this, or can we just wildcard it?
[23:39] <BenC> infinity: e500v1, but that wont have a /dev/kvm, so wouldn’t much matter
[23:39] <infinity> Right, kay.
[23:39] <BenC> e500mc and e500v2 are the kvm enabled ones
[23:39] <infinity> So, we can just wildcard a case, probably.   I think it may need to use ppcemb as well
[23:46] <BenC> proc cpuinfo would show e6500
[23:47] <BenC> infinity: Confirmed
[23:47] <BenC> so e500* and e6500
[23:47] <BenC> processor	: 20
[23:47] <BenC> cpu		: e6500, altivec supported
[23:47] <BenC> clock		: 1666.666650MHz
[23:47] <BenC> revision	: 1.0 (pvr 8040 0010)
[23:47] <BenC> That’s the relevant cpu stanza
[23:49] <BenC> Both platforms are BookE, hence the ppcemb usage
[23:49] <infinity> BenC: So, something like this: http://paste.ubuntu.com/8843119/
[23:49] <infinity> mwhudson: ^
[23:50] <mwhudson> good timing, i'm typing my commit message for the other wrappers now
[23:50] <infinity> Err, missing a trailing ;; on the last outer case.
[23:50] <BenC> infinity: The awk statement works on both systems, so passes a cursory check
[23:50] <infinity> That was obviously written blind. :P
[23:51] <BenC> It atleast passes the the correct output on my boxes :)
[23:52] <mwhudson> infinity: is there a reason to handle power64 in this same file, particularly?
[23:53] <infinity> mwhudson: Most 32-bit powerpc installs are on 64-bit kernels.
[23:53] <BenC> mwhudson: 32-bit userspace can run on 64-bit platforms
[23:53] <mwhudson> ok
[23:54] <infinity> http://paste.ubuntu.com/8843150/ <--- that one looks like more correct shell.
[23:55] <infinity> BenC: Can you run that with sh -x on your machines and make sure it's trying to run the right binary?
[23:55] <infinity> Passes on a ppc64, ppc64el and ppc machine here.
[23:56] <BenC> infinity: If you’re going to use $(…) notation, should it not use bash?
[23:56] <BenC> Or am I behind the times
[23:56] <infinity> $() is POSIX.
[23:57] <infinity> Could be backticks, doesn't really matter.  I just use $() more these days to avoid confusing myself when nesting.
[23:57] <BenC> infinity: Works on both, thanks
[23:57] <infinity> BenC: Ta.
[23:58] <infinity> mwhudson: So, that last pastebin with the quoting and ;; fixes should DTRT for qemu-kvm:powerpc
[23:58] <mwhudson> infinity: thanks
[23:58] <infinity> mwhudson: You could reuse it for :ppc64 and ppc64el too, though it's mostly a no-op for them, it simplifies the packaging to just symlink. :P
[23:59] <mwhudson> infinity: i just attached some patches to the bug https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1389897


[16:34] <bcurtiswx> mthaddon, hi :)
[16:35] <mthaddon> bcurtiswx: hi there - did you see my last reply to the ticket?
[16:35] <bcurtiswx> The one mentioning that you wanted to allow my IP so I can check out the site?
[16:35] <mthaddon> yep
[16:35] <bcurtiswx> yes, lol
[16:35] <mthaddon> I guess that's a yes :)
[16:37] <mthaddon> see pm