[00:43] <TheMuso> pitti: I'm happy to take care of the brltty merge if you haven't already started it.
[05:44] <pitti> Good morning
[05:44] <pitti> TheMuso: I didn't start yet; thanks!
[05:50] <TheMuso> pitti: np
[06:20] <pitti> cyphermox: FYI, new isc-dhcp is held in -proposed by regresssing NetworkManager test
[06:21] <pitti> cyphermox: it seems something is now spilling "Killed old client process" to stderr -- leftover debug message which shoudl be quiesced again?
[06:21] <pitti> or something which we need to ignore in the tests?
[07:38] <dholbach> good morning
[08:23] <Saviq> pitti, hey, I wanted to confirm something... now that we have separate rtm branches/series in some projects (like unity8 and friends), what happens to the translations/langpacks? should we bring the translation updates from trunk into the rtm branches? or should we enable translations for the rtm series and rely on the translations being shared?
[08:49] <pitti> Saviq: yes, translations for RTM need to be enabled, but they are at the distro level (not project)
[08:49] <pitti> Saviq: through message sharing that works, we build RTM specific langpacks
[08:49] <pitti> Saviq: the main (and crucial!) thing to do is that a package build builds an up-to-date .pot
[08:49] <Saviq> pitti, of course
[08:50] <Saviq> pitti, so, in the case of unity8, we only have project-level translations right now
[08:50] <Saviq> pitti, what should we do to make this happen for rtm?
[08:52] <pitti> Saviq: seems quite alright? https://translations.launchpad.net/ubuntu-rtm/14.09/+source/unity8/+pots/unity8
[08:53] <Noskcaj> dholbach, Fixing webtest now, sorry for screwup
[08:53] <Saviq> pitti, hmm, right, but nothing syncs to the series http://bazaar.launchpad.net/~unity-team/unity8/rtm-14.09/changes
[08:54] <pitti> Saviq: I'm confused -- what do you need synced to the RTM branch?
[08:54] <Saviq> pitti, the .po file changes?
[08:55] <Saviq> pitti, like in trunk we're getting http://bazaar.launchpad.net/~unity-team/unity8/trunk/revision/1431
[08:56] <pitti> Saviq: well, you can import them if you like, but they don't get into the .deb anyway
[08:56] <pitti> Saviq: as I said, the crucial thing is an up to date .pot, then LP message sharing will DTRT
[08:56] <Saviq> pitti, ah so the actual langpacks get generated straight out of LP?
[08:56] <pitti> right
[08:56] <Saviq> ok, that's what I was missing
[08:56] <Saviq> pitti, thanks, that explains things then
[08:57] <pitti> Saviq: did you spot anything wrong/missing there?
[08:57] <Saviq> pitti, no, just got scared we're not doing something we should be doing
[09:05] <tvoss> pitti, good morning
[09:07] <pitti> hey tvoss
[11:17] <ogra_> dpm, how do i get my http://summit.ubuntu.com/uos-1411/ogra/meetings onto the schedule ?
[11:24] <dpm> ogra_, track leads should be approving the sessions. You might need to ping them. For the development track, they are: Will Cooke, Łukasz Zemczak, Steve Langasek, Antonio Rosales, and Rohan Garg
[11:25] <ogra_> ok
[12:05] <ogra_> willcooke, ^^^ could you approve my sessions ?
[12:06] <willcooke> ogra_, there's something wrong with my set up in summit, waiting on mhall119 to come online and fix it
[12:06] <ogra_> oki
[13:40] <mhall119> willcooke: let me check
[13:40] <willcooke> mhall119, thx
[13:41] <mhall119> willcooke: there's nothing waiting to be scheduled on the Ubuntu Development track
[13:41] <willcooke> ogra_, ^^^
[13:41] <mhall119> willcooke: you have some you can review on http://summit.ubuntu.com/uos-1411/review/
[13:42] <willcooke> mhall119, that URL doesn't show me anything to review
[13:42] <ogra_> mhall119, so how do i get http://summit.ubuntu.com/uos-1411/ogra/meetings into some review/approval queue
[13:42] <mhall119> willcooke: then there might be something wrong with your account
[13:43] <mhall119> willcooke: at the top, where is says "Logged in as:" what username is displayed?
[13:43] <willcooke> mhall119, logged in as willcooke (and that links to my LP page)
[13:44] <mhall119> hmmm....
[13:44] <mhall119> ogra_: they're already in one, but something's wrong with will's account
[13:45] <ogra_> ah, its all willcooke's fault then, ok
[13:45]  * ogra_ knew it 
[13:45] <mdeslaur> bdmurray: mind if I steal your curl merge?
[13:45] <willcooke> ogra_, :)  typical
[13:45] <ogra_> :)
[13:52] <mhall119> shadeslayer: can you see any session pending review on http://summit.ubuntu.com/uos-1411/review/ ?
[13:59] <mhall119> willcooke: well popey can he stuff for his track, so it must be just you that's broken, try logging out and back in
[14:00] <willcooke> mhall119, ok :)
[14:00] <willcooke> mhall119, sam,e
[14:00] <willcooke> same
[14:01] <shadeslayer> mhall119: looking
[14:01] <shadeslayer> mhall119: there's a few
[14:03] <mhall119> well willcooke....what have you done to summit?
[14:03] <mhall119> oh, wait.....
[14:04] <mhall119> I did it :)
[14:04] <willcooke> mhall119, erm - it was like that when I got here?
[14:04] <mhall119> willcooke: try that page again
[14:05] <willcooke> mhall119, ooooooohhhh  - suddenly everything is different
[14:06] <mhall119> now you can approve ogra_'s sessions :)
[14:06] <cyphermox> pitti: perhaps. I'll take a look
[14:06] <ogra_> \o/
[14:06] <willcooke> I'll have to re-read the instructions
[14:08] <cjwatson> doko: I think gluegen2 can be synced; your diff to it was to build with the zero VM on arm64 because it previously failed to build, but the latest version of gluegen2 built cleanly on Debian arm64 so it looks likely to be fine now.  Are you OK with that?
[14:08] <ogra_> mdeslaur, pitti, i remember there was a reason why we didnt include dbus 1.6,.18 but kept .16 in rtm ...
[14:09] <ogra_> mdeslaur, pitti do you guys remember what that was ? ricmm thinnks this could be related to our multiple hangs and CPU at 100% thins
[14:09] <ogra_> *thigs
[14:09] <mdeslaur> ogra_: bug 1362469
[14:10] <pitti> ogra_: I'm afraid I wasn't involved in that discussion
[14:10] <pitti> ah, there we go, thanks mdeslaur
[14:10] <ogra_> pitti, yeah, i just remembered one of you two was
[14:11] <mdeslaur> ogra_: perhaps tyhicks made some progress investigating that
[14:12] <mdeslaur> tyhicks: pingy ping ping
[14:39] <mdeslaur> bdmurray: too late :P
[14:55] <cjwatson> doko: Went ahead and synced gluegen2, since it's blocking something else I need.  We can always put back the diff if it's a problem.
[15:22] <tyhicks> ogra_: the 1.6.18 merge came in pretty late for utopic so I didn't push to include it in rtm and then we found bug 1362469 so we decided to definitely not push for it in rtm
[15:23] <tyhicks> ogra_: I've looked at that bug quite a bit but haven't been able to make good progress
[15:23] <tyhicks> ogra_: it is about as difficult to debug as the cpu pinning bug that others are trying to solve :/
[15:26] <ogra_> thywell, ricmm suspects the CPU peging is caused by us being behind in dbus versions on rtm
[15:26] <ogra_> tyhicks, ^^^^
[15:28] <tyhicks> ogra_: has anyone been able to verify that 1.6.18 fixes the cpu peging?
[15:28] <ogra_> i doubt that ... talk to ricmm (who is in a meetign atm)
[15:29] <tyhicks> ok
[15:29] <xnox> lamont: it's all in ubiquity/frontend/gtk_ui.py the vte bits, it shouldn't be that many.
[15:29] <xnox> lamont: unping
[15:29] <xnox> Laney: ^
[15:29] <Laney> xnox: I see it - that's for the debugging mode?
[15:30] <xnox> Laney: it's present and running at all times, on all gtk frontends, however most of the time it's invisible. But widget is initiated as is there.
[15:30] <tyhicks> ogra_, ricmm: at this point in the rtm schedule, I'd be far more comfortable backporting the specific fix for the cpu pegging bug from 1.6.18 to 1.6.16 and I'll work on fixing bug 1362469 in the meantime
[15:31] <xnox> Laney: UI wise, it's accessible after one starts the installation (after clicking next in partitioning), however progress dots are in the way to actually expand it to show it.
[15:31] <ogra_> tyhicks, right, i think ricmm also meant he had seen only some specific things in the changelog that could be related, but we indeed need to make out if thats actually helping
[15:31] <xnox> Laney: what's changed in vte? it's only one vte specific command and the rest are regular gtk+ calls/functions.
[15:34] <Laney> xnox: so this /is/ the expandered vte?
[15:35] <Laney> I misremembered that this showed the usual debug output like update-manager does
[15:35] <Laney> there's some random API cleanups
[15:36] <xnox> Laney: yes. and there is nothing else vte in ubiquity.
[15:37] <Laney> cool
[15:37] <Laney> I thought there were two things when you talked about debug-ubiquity
[15:37] <xnox> Laney: ctl-alt-t thing in debug mode simply launches the default terminal, as in it launches gnome-terminal
[15:37] <Laney> Right, nothing to worry about here then
[15:37] <xnox> Laney: so ubiquity vte code is just this: http://paste.ubuntu.com/8921321/
[15:38] <Laney> yep
[15:38] <xnox> Laney: which is stand-alone, just run that on your desktop with new vte and you know that vte in ubiquity will work.
[15:59] <LocutusOfBorg1> hi Laney finally thanks to someone retrying itk4 have been successful
[15:59] <LocutusOfBorg1> I'm trying to parse update_output to understand what is missing
[16:00] <cjwatson> LocutusOfBorg1: I'm working on it, it's a complicated set of intertwined transitions
[16:00] <LocutusOfBorg1> thanks!
[16:00] <cjwatson> gdcm, hdf5, vdr, etc.
[16:00] <LocutusOfBorg1> hdf5
[16:00] <LocutusOfBorg1> ok so I'm parsing it correctly :)
[16:00] <LocutusOfBorg1> I wasn't sure about the file syntax, is not so much friendly :)
[16:00] <Laney> AFAICS think gdcm is done in itself, but the entagled transitions need work
[16:00] <cjwatson> No, gdcm isn't
[16:01] <Laney> s/think//
[16:01] <Laney> why
[16:01] <cjwatson> Given that I just made three uploads for that earlier
[16:01] <cjwatson> nifti2dicom, plastimatch, vmtk
[16:01] <LocutusOfBorg1> why nifti2dicom hasn't been picked up in the transition file?
[16:02] <LocutusOfBorg1> I was mostly sure about it, but ben says otherwise
[16:02] <cjwatson> no idea, don't care
[16:02] <cjwatson> probably the build-depends field is wrong
[16:02] <cjwatson> i.e. it picks up the libgdcm2.[24] dep despite not having a direct build-dep on libgdcm2-dev
[16:02] <cjwatson> so shrug, sorting it out anyway, the transition tracker isn't important at this point
[16:03] <cjwatson> something's up with plastimatch if you want to have a look at that - FTBFS on amd64 and i386 so far
[16:03] <LocutusOfBorg1> wilco
[16:03] <Laney> I mostly stayed out of the way once I saw that other people were looking at it, so whatever, go wild
[16:04] <cjwatson> I'm also working my way up to scilab (hence the gluegen2 stuff above)
[16:06] <LocutusOfBorg1> cjwatson, plastimatch is (almost) tracked here on debian #768769
[16:07] <pitti> mitya57: just in case you wonder why your lintian merge doesn't land: it breaks current lintian4python; a simple dep bump of the latter isn't sufficient, I filed a Debian bug
[16:07] <LocutusOfBorg1> on amd64 there are some more tests failing
[16:14] <cjwatson> LocutusOfBorg1: I'd be tempted to demote that to -proposed if we get to the point where it's the last remaining blocker
[16:14] <LocutusOfBorg1> the popcon is rather low... so i agree :)
[16:15] <LocutusOfBorg1> in the meanwhile it will either disappear from jessie/get fixed
[16:56] <seb128> whoever changes the urls on the -changes emails to not include the +serie, thanks!
[16:57] <seb128> changed even
[16:58] <seb128> nice to be able to click and have the diff on the page without having the mangle the url manually in the webbrowser
[16:58] <ogra_> OOOH !
[16:59] <ogra_> i'll pay all the drinks for one evening at the bar at the next sprint for whomever did that !!!!
[16:59] <ogra_> this is AWESOME !!
[16:59] <seb128> :-)
[16:59] <seb128> count me in for buying $drinks for whoever did that
[16:59] <ogra_> :)
[17:00] <ogra_> you can take the next evening :)
[17:02] <stgraber> that'd be wgrant: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/revision/17235
[17:02] <ogra_> oh, he will get sooo drunk next sprint :)
[17:02] <stgraber> well, next sprint for him is next week :)
[17:02] <ogra_> well, the next one we all meet :)
[17:13] <slangasek> cyphermox: hi, do you understand the autopkgtest failures at https://jenkins.qa.ubuntu.com/job/vivid-adt-network-manager/lastBuild for network-manager?  I don't see anything failing except a message about qemu processes being killed; not sure if that's an issue with the NM test suite or with the infrastructure
[17:14] <cyphermox> yes, I know what it is
[17:15] <cyphermox> new isc-dhcp has an extra message on stderr
[17:15] <cyphermox> slangasek: the test is trapping this stderr line: wpa-dhclient         FAIL stderr: Killed old client process
[17:16] <cyphermox> I'll fix it shortly, but I was hoping to fix it as I was uploading the new NM
[17:28] <Mirv> pitti: if you can, please find out what's wrong with calibre powerpc. this time it doesn't seem to be just "succeeds on certain machines". (I'll need a rebuild of it done for Qt 5.3.2 landing)
[17:28] <Mirv> so it fails similarly in vivid archives and in my PPA now
[17:48] <slangasek> cyphermox: ok, so it's safe to skip that failure for any migrations it's blocking?
[17:59] <cyphermox> slangasek: yes
[18:06] <doko> cjwatson, ok, there was still an ftbfs issue open, now closed
[18:38] <bdmurray> slangasek: would our missing ddebs for qtcontact5-galera (on amd64, i386, armhf)  have anything to do with address-book-service being copied from a PPA?
[18:38] <slangasek> bdmurray: could, but should not
[18:39] <slangasek> bdmurray: you could ask pitti if there are any remaining known problems with the ddebs handling for ppa copies
[18:45] <bdmurray> slangasek: its odd that if you look here https://launchpad.net/ubuntu/+source/address-book-service/0.1.1+14.10.20140930-0ubuntu1 the utopic builds are for arm64, powerpc, and ppc64el which is what we have ddebs for.
[18:47] <slangasek> bdmurray: ah... so this package was built in an *ubuntu-rtm* ppa, and then binary-copied to utopic
[18:47] <slangasek> bdmurray: that could certainly be a factor
[18:47] <infinity> binary copied to a utopic silo, even.
[18:47] <infinity> Strange workflow.
[18:48] <infinity> So, both sets of builds were in a PPA, but different PPAs.
[18:48]  * slangasek nods
[18:48] <slangasek> so it's probably a case where the ddeb-retriever doesn't know where to retrieve from
[18:48] <infinity> Or, rather, how to reconcile the refs.
[18:48] <infinity> Since the ddebs themselves all come from the same big tarball regardless.
[18:49] <infinity> Of all the temporary hacks I've been party to over the years, this is the one I feel the worst about. :P
[18:55] <tedg> bdmurray, So seb128 convinced me we should move bugs from being on the project to being on the Ubuntu package. I was trying to write a script that would move them. But I can't seem to figure out which tasks are package and which are project. Do you have a script I can steal from?
[18:56] <bdmurray> tedg: I don't know but off the top of my head if "(Ubuntu)" in task then its a package one.
[18:57] <tedg> bdmurray, Do you know what property "(Ubuntu)" would be in? Just parse the title?
[18:58] <bdmurray> tedg: bug_target_name
[19:00]  * tedg tries
[19:10] <bdmurray> tedg: and?
[19:12] <tedg> bdmurray, Nope, looking at other props. Those are all "ubuntu-app-launch"
[19:13] <bdmurray> tedg: Can I see your script?
[19:13] <tedg> bdmurray, http://paste.ubuntu.com/8924781/
[19:14] <bdmurray> tedg: and what project are you using?
[19:15] <tedg> bdmurray, ubuntu-app-launch
[19:16] <bdmurray> tedg: in the for btask loop you are using task
[19:16] <bdmurray> tedg: lines 38 through 41
[19:17] <tedg> bdmurray, Oh, man. Thanks!
[19:17] <bdmurray> no problem
[20:38] <ScottK> infinity: Since you TIL, any objections to adding no-human-maintainers to the tests ignored in the Ubuntu profile.  Seems highly irrelevant for Ubuntu.
[20:41] <infinity> ScottK: You failed to mention a package name there...
[20:42] <infinity> ScottK: lintian?
[20:42] <ScottK> infinity: yes.  sorry
[20:42] <infinity> ScottK: Yeah, that sounds like a reasonable change.
[20:42] <ScottK> Thanks.
[20:43] <infinity> ScottK: Were you asking me to make it, or to +1 you making it? :)
[20:43] <infinity> ScottK: If you do the change, can you forward to Debian, that stuff is all in sync.
[20:43] <infinity> (Our only delta is a nodejs build-dep avoidance thing that I'm trying to convince Debian is sort of okayish)
[20:43] <ScottK> I was asking for you to +1 me making it and I'd forward to Debian, but if for some reason you want to, don't let me stop you.
[20:44] <infinity> ScottK: No, no.  By all means, go nuts.  Do away!
[20:53] <ScottK> Of, of course it needs merging too.
[20:57] <infinity> ScottK: It was *just* merged...
[20:57] <ScottK> OK.  Or I got the old version.
[20:57] <infinity> https://launchpad.net/ubuntu/+source/lintian/2.5.30ubuntu1
[20:58] <infinity> Seems to have made lintian4python unhappy.
[20:58] <ScottK> lintian4python is dead.
[20:58] <infinity> It was also never in unstable even.
[20:59] <infinity> I wonder who synced that from experimental, and why.
[20:59] <ScottK> Dunno.  It was handy when it was maintained, so I guess that's why, but now that it's orphaned, no point in it.
[21:00] <infinity> Right, let's just remove it, then.
[21:00] <ScottK> Please.
[21:00] <infinity> If it ever makes it into sid, it'll come back on its own.
[21:00] <ScottK> Yep.
[21:01] <infinity> ScottK: Done.
[21:01] <ScottK> Excellent.
[21:05] <ScottK> Turns out it's easy to get confused about the current version of something when you just set up a new LTS system and forgot to point the deb-src lines at the devel release.