[02:52] Huh, looks like I got that wrong :- [05:10] morning [05:12] Hi Mirv, how are you? [05:13] Mirv: when you have a moment I'm hoping you can help me sort out a couple of things. [05:16] veebers: would you like to have lp:xpathselect properly synced from archivess? [05:17] veebers: and fine thank you, it was a great weekend! [05:17] 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] Mirv: Excellent, that's good to hear :-) [05:19] 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] veebers: it's the autopilot-gtk autopkgtest problem already noticed last week [05:19] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#xpathselect [05:21] Mirv: ah right, so those autopkgtest failures are because it needs xpathelect to be rebuilt with gcc5. [05:21] with xpathselect rebuilt, building autopilot-gtk works and passes. [05:24] 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] 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] and the tests have failed with that too [05:25] 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] Mirv: out of interest, where can I see which version of xpathselect was used when building autopilot-gtk? [05:30] ah nvm, looks like I found what I want [05:30] 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] oh, no [05:31] no, it isn't, it's the new one [05:32] Hi Evan, [05:32] damn, wrong channel [05:36] 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] I know why the tests are failing, because they are getting nothing back from the call to the xpathselect lib [05:43] 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] Mirv: ah cool, thanks for confirming (I was worried I had missed something obvious :-) ). Would you know an approx ETA for cihelp? [05:44] 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] veebers: usually in 3h from now or so :( [05:45] 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] I can understand that [05:46] 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] you're welcome! I will. === dbarth_ is now known as dbarth [07:36] sil2100, hey! is silo 31 good to land now after michi's fix to changelog? [07:38] pstolowski: looking :) [07:40] bfiller: hello! You around at this hour? ;) [07:41] sil2100: in london for sprint :) === joc|away is now known as joc_ === marcusto_ is now known as marcustomlinson [09:10] Hi Mirv :-) Any luck that cihelp might be around now? [09:38] veebers: it'd look to me unfortunately not :( [09:38] cihelp? [09:39] I thought there'd be during UK hours [09:51] They usually have someone around in the EU timezone === _salem is now known as salem_ [10:06] mandel: any ETA on the pulseaudio translation-ability? [10:06] 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] Ok, thanks [10:30] 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] veebers: thanks! [10:30] great to hear === Laney is now known as Guest65212 === Guest65212 is now known as Laney [11:26] sil2100, do you know what is this changed that landed into the overlay https://lists.launchpad.net/landing-team-changes/msg00639.html ? [11:26] change* [11:29] jibel: it's a no-change upload [11:29] I'm resolving translation issues [11:33] sil2100, ah ok, I was wondering why a change from March would be copied only just now [11:49] mandel, any news on the pulseaudio silo to enable translations? === salem_ is now known as _salem [12:36] 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] mandel, okay, keep me posted so someone from QA can review [12:42] sil2100 / Mirv: can one of you upload me a package to silo 43? [12:42] jibel, sure [12:44] morphis: sure [13:01] sil2100, jibel (maybe repeat, my irc is screwy [13:01] ) [13:01] is now a god time to push the device tarballs [13:03] john-mcaleely, go ahead. there are still several hours until we have the latest fixes and a final build [13:03] jibel, ack [13:05] jibel, sil2100 pushed. thank you! === _salem is now known as salem_ [13:06] Yes [13:06] \o/ [13:20] 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] elopio, this is urgent, can you approve it? ^ [13:21] sil2100: I must request higher translation powers [13:22] 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] sil2100: Yup [14:25] 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] 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] so the question is why the same does not happen in the automated tests [14:29] that is a good question [14:30] 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] Mirv: the queuebot says it's preparing an xpathselect landing. Could that have anything to do with it? [14:31] 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] and it was even published from that silo [14:31] Mirv: ah, okay. weird [14:32] actually, same for unity itself, the whole silo was alredy published [14:32] but now being rebuilt by... Laney it seems [14:32] hi, yes, that version is broken [14:32] just talked about it in ubuntu-release [14:33] ah [14:33] the plot thickens/resolves [14:33] it has an abi change with g++5 so you need to rebuild it [14:33] this is why ap-gtk broke [14:33] s/rebuild/rename/ [14:34] funny how ap-gtk works after upgrading to the current wily-proposed version of xpathselect, but good that there's a solution [14:34] it sure didn't work for me [14:34] nor on autopkgtest.u.c [14:34] 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] only once I did a rebuild of autopilot-gtk did it work again [14:35] riiight, so that's what we tested locally, rebuilding autopilot-gtk. that worked with that ^ and didn't without [14:35] if you rebuild ap-gtk then you resolve the abi breakage of course [14:36] nuclearbob: are you an autopilot person btw? [14:37] Laney: yeah [14:37] if so, is there a standard workaround for missing Eventually(raises(...? [14:37] I want to fix https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/amd64/a/autopilot-gtk/20150819_132411@/log.gz [14:38] I can instead make this test wait for 'visible = False' on the dialog [14:38] oh, veebers fixed this [14:39] not sure I believe that fix [14:39] * Laney experiments [14:45] jibel, sil2100 I need to request a silo for pulse and kenvandine will do the dput, is that ok with you? [14:46] mandel: sure :) [14:46] mandel, that's fine [14:48] sil2100, he, I think I'm outdated.. we don't longer have a spreadsheet, is that correct? [14:48] mandel: yeah, there's the requests site :) [14:48] https://requests.ci-train.ubuntu.com [14:49] nuclearbob: can you check https://code.launchpad.net/~laney/autopilot-gtk/tests-wait-not-visible/+merge/268928 for me please? [14:50] Laney: I'll take a look [14:51] thanks [14:52] sil2100, let me know if I screw it up :-/ [14:52] sil2100, but I think I requested it correctly [14:52] mandel: you can now assign it yourself too :) [14:53] mandel: just press 'Assign' [14:53] Laney: that looks reasonable to me [14:54] nuclearbob: ok, I think it supersedes https://code.launchpad.net/~canonical-platform-qa/autopilot-gtk/fix-failing-mouse-test_1483815/+merge/268869 [14:54] would like to upload this with the new xpathselect [14:55] and abandon the silo 041 [14:55] Laney: that makes sense to me [14:55] cool, thanks, will pull the right levers then [14:56] awesome! [14:56] oh man, xpathselect got an empty changelog [14:56] * Laney cries [15:00] wait [15:00] it didn't get my change? [15:01] Laney: in what silo was supposed to be? Since I don't see it in landing-019 [15:01] 019 [15:01] Mirv: can you help? [15:01] mh, I don't see the MP listed there [15:01] I edited on the requests thing [15:01] is there another step? [15:01] do I need to 'assign' again? [15:02] Laney: did you add/modify the merges you want to build? [15:02] I mean, the links? In that case you need to reconfigure through the Assign button [15:02] But not if you only pushed code changes to the branches [15:02] Any change in the request itself requires an reconfigure, besides the Testing status of course [15:03] I changed the list of merges yes [15:03] ok, and do I have to unmangle the MERGE_PROPOSALS thing? [15:04] No no [15:04] 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] so I can just press Build and leave it encoded [15:05] Yep [15:05] let me try this then [15:05] seems to be understanding it [15:07] yes, and now it gets the right one [15:07] thanks sil2100! [15:07] \o/ [15:07] * Laney gets to wait for build+publish again [15:07] yw! [15:08] mandel: ...ok, I'll assign the silo for you in this case [15:09] kenvandine: could you upload the pulseaudio packages to ubuntu/landing-028 for mandel ? [15:09] sil2100, yes, doing it now [15:09] just building sources [15:09] kenvandine: thanks! [15:10] kenvandine, sil2100 \o/ [15:11] mandel: just remember that with the new CI Train requests you can assign your own silos basically [15:11] mandel, sil2100: uploaded and it's building now [15:11] sil2100, can I?? cojonudo [15:19] mandel, does the silo includes the fix for the timeout too? [15:20] Laney: I still don't see your branch listed... [15:20] cihelp: I'm looking for the jenkins instance that runs ubiquity tests. Maybe plars knows where that is? [15:20] listed where/ [15:20] rvr: approved [15:20] 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] elopio: Thanks! [15:20] nuclearbob: yeah, I know where it is, but you can't get to it very easily directly [15:21] 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] 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] plars: yeah, I'd like to make it not a failing test anymore [15:21] nuclearbob: awesome [15:23] bzoltan_, silo 41 is not happy [15:23] kenvandine: I know [15:23] bzoltan_, ok... just making sure :) [15:24] kenvandine: I wonder where the citrain got the idea of doing that... [15:30] 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] hmm [15:35] jibel, rvr, ogra_, popey: let's skip the meeting today, we have a blocker sync up at the same time with pmcgowan [15:35] sil2100: Ack [15:35] +1 [15:35] robru: hey! We'll be skipping the landing meeting, I'll update you on the status through e-mail [15:38] sil2100: jibel: btw, the warning opting UITK fix is being processed in the silo41 ... Hopefully I can validate it during the night [15:39] bzoltan_, it must land before that, we'll retest the image tonight. [15:41] 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] bzoltan_, np thanks. We all do our best for the best OTA :) [15:43] jibel: :) that is something I am sure about.... also the silo9 has the emulator fix... at least the UITK part of it. [15:44] bzoltan_, yeah but we wanted to test 25 and 33 with 9 and there are still issues [15:44] bzoltan_, we'll land the 3 silos together [15:44] jibel: Yes, that is how I understood that. Please tell me if you need anything from me [16:00] Trevinho: can I do a unity rebuild in that silo? [16:01] Laney: sure, it's just that one build has been landed in distro (not sure if that counts)... [16:01] oh, no, you have a hardcoded depends [16:02] yeah, that's because it's not a real code dependency... [16:03] want me to prepare a branch fixing it or you care about that? [16:04] Trevinho: https://code.launchpad.net/~laney/unity/xpathselect-v5/+merge/268939 [16:05] done [16:05] thx [16:17] 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] 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] Laney: i have a fix for the empty changelog thing that I'll roll out shortly [16:18] bzoltan_: yeah [16:18] robru: In this case I had built the wrong branch anyway :) [16:19] Laney: true, but soon it'll say "no change rebuild" rather than having a changelog with an empty bullet point ;-) [16:48] 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] robru: yes [16:51] great [17:05] Sure [17:06] Bah [17:07] I don't know why that happened - I merged the proposed branch into mine [17:07] It doesn't appear in https://ci-train.ubuntu.com/job/ubuntu-landing-019-1-build/205/console [17:07] but https://ci-train.ubuntu.com/job/prepare-silo/5899/console shows that I reconfigured it [17:08] 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] Laney: I' [17:08] ll take a look [17:08] thanks [17:09] I've got to go but I'll look again in the morning and try to shove the rest of it through [17:09] see you! [17:09] all right! [17:42] Laney: what doesn't appear? [17:47] 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] 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] jibel: bzoltan_: Approving silo 41 [17:57] rvr: nice .. i have the logs from the UITK too [17:58] bzoltan_: Is all right? [18:00] rvr: I have not seen any unusual [18:00] 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. === salem_ is now known as _salem [18:03] bzoltan_: To me is a go, then [18:04] rvr: \o/ [18:04] bzoltan_: I checked deprecation warnings in gallery app and unity8, and they were gone with the silo. [18:05] rvr: Yeps :) That is the point of this fix [18:05] bzoltan_: Also did some exploratory testing and everything seems to be fine. [18:06] bzoltan_: Approved [18:45] michi: sil2100: slangasek: https://bugs.launchpad.net/cupstream2distro/+bug/1488211 [18:45] Ubuntu bug 1488211 in CI Train [cu2d] "Train should clean source tree before building." [Undecided,Triaged] [18:50] sil2100: slangasek: also https://bugs.launchpad.net/cupstream2distro/+bug/1488213 [18:50] Ubuntu bug 1488213 in CI Train [cu2d] "Train should reconfigure at the start of every build job." [Undecided,Triaged] [18:51] ok I'm off for lunch, bbl [19:41] jibel, robru, john-mcaleely: I need to AFK now, I'll be back in around 2-3 hours [19:41] o/ [19:41] noooooooo so close to finishing too [19:47] 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] 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] davmor2: cool, thanks for your efforts [19:49] will publish [20:21] bzoltan_, now that silo 9 was published, 41 is dirty [20:22] :( [20:28] bzoltan_, but silo 9 needs merging before 41 can be rebuilt, so i guess we are in a holding pattern [20:40] robru: Thanks heaps! [20:41] michi: you're welcome [20:41] That’s awesome! [20:42] 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] (Need to make sure that my script actually does the right things, of course.) [20:42] 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] Yes, people will soon have to refer to me as the Dark Lord... [20:43] michi: yep should land shortly, i asked slangasek to review, shouldn't take long [20:43] This is very cool. [20:43] Thanks again! [20:43] I’ll report back once I kick another bulid of the silo. [20:43] It should behave differently then. [20:43] michi: you're welcome! Hopefully this reduces the workload for you a lot ;-) [20:44] Man, if this works, it’ll make a big difference. [20:44] I owe you a beer at the next sprint! [20:44] Haha for sure [20:51] bzoltan_, we merged 9 and kicked a 41 rebuild [22:32] mandel, kenvandine, robru, jibel: did the pulseaudio translation thing land? [22:32] sil2100, no... [22:32] sil2100: I have no knowledge of this [22:32] mandel is still working on it [22:32] he's iterating on the patch now, it's in silo 9 [22:32] I thought the idea was to split it into 2 silos [22:32] but will have another iteration [22:32] i don't know about that [22:32] Like, one for translations, one for the bugfix [22:33] That's what I heard from pmcgowan on the meeting we had [22:33] Damn... [22:33] sil2100, bug fix, we do have a small patch for the translation that is separated [22:33] not in a separate silo [22:33] sil2100, but the translation is "minor" compared with the security implcations [22:33] sil2100, the problem with separate landings is we'll need to rebuild the second one after the first one is published [22:34] correct [22:34] so imo, since we are blocking on the bug fix, we just keep them together [22:34] Right, but we need to give time translation admins to approve new translations [22:34] 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] it'll speedd up landing [22:34] Once those get imported [22:34] mandel, nothing needs to be fixed in settings [22:34] I was supposed to build a new image with translations now, but it seems that's not possible [22:34] jibel: ^ [22:34] it's just showing what's stored in the trust db [22:35] kenvandine, yes, I ment, make sure that the stored app armor profile is correct [22:35] mandel, so when you fix that, settings is good [22:35] ah [22:35] yeah [22:35] kenvandine, I mentioned settings as a reference to the bug [22:35] kenvandine, we also have timeout issues [22:35] fun fun fun [22:35] * mandel is master of the "fun" projects [22:35] sil2100, maybe upload the template from the silo build? [22:35] manually [22:36] I have no power to do so sadly [22:36] Not enough permissions [22:36] me either [22:36] sil2100, seb128 has powers to do that [22:37] 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] no idea, i was surprised [22:37] but i rebuilt silo 41 after merging that [22:37] Now I'll have to include it along with the UITK blocker fix ;/ [22:38] we decided to force merging 9 [22:38] kenvandine: thanks [22:38] but only after we say it was published [22:38] That was the right thing to do [22:38] yeah, kgunn and i discussed it [22:38] Still, publishing it was not the right thing to do IMO [22:38] didn't want that to sit until morning [22:38] not sure who did that [22:38] 41 was verified by qa already [22:39] i wanted that in! [22:39] kenvandine, what power do you need? [22:39] that's breaking the settings CI :) [22:39] QA had to sign it off, I thought they would have waited with switching it on bileto [22:39] seb128, uploading a template manually [22:39] sil2100, right? upload the fixed template in silo 9 manually to wily, right? [22:39] pulseaudio template [22:40] kenvandine: to ubuntu-rtm/15.04 [22:40] so the translators can get started on it [22:40] or that [22:40] kenvandine, can do if you want [22:40] cool [22:40] let me get you the template [22:40] thanks [22:41] bzoltan_: hey! https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/optInDeprecationWarningsTrunk/+merge/268909 is unapproved [22:41] seb128: thanks! [22:41] This should give translators some time to get things done [22:50] kenvandine: did you give seb128 the pot file? [22:50] not yet [22:50] i think something's wrong here [22:50] mandel, ping [22:50] kenvandine, yes? [22:50] bool result = pa_trust_store_check(pc->userdata->ts, pc->appname, pc->uid, pc->pid, [22:50] "%1% wants to record audio."); [22:50] is that what should get translated? [22:51] mandel, there are no strings from that file in the generated pot file [22:51] kenvandine, yes it should, I'll update that [22:51] and if that's the string, it's not getting picked up [22:51] of course it's not, it's not under _() or any equivalent [22:51] mandel, so a new 0416 patch? [22:51] kenvandine, correct [22:51] seb128, exactly :) [22:52] kenvandine, but let me first test the silo 09 [22:54] mandel, i have a fix already [22:55] kenvandine, awesome, thx.. I've got the trust store working again and getting the logs [22:57] seb128, http://people.canonical.com/~kenvandine/pulseaudio.pot [23:02] kenvandine, to what serie do you need that? [23:02] ubuntu-rtm/15.04 [23:03] hum [23:03] https://translations.launchpad.net/ubuntu-rtm/15.04/+source/pulseaudio [23:03] no template there atm [23:03] that feels wrong? [23:04] The templates need approval, no one approved them it seems [23:04] https://translations.launchpad.net/ubuntu-rtm/15.04/+source/pulseaudio/+imports [23:05] right, but where are we taking our export from then atm? [23:05] or at we shipping no pulseaudio translations? [23:06] From vivid IIRC, pitti merged vivid and the overlay for the langpack-o-matic upload [23:06] Since that's basically what we should be doing [23:07] trainguards: I need QA for silo 11. Could someone help with that please? [23:07] k, translations approved and new template uploaded [23:07] seb128: \o/ thanks! [23:07] mandel, i had to refresh the patches [23:07] * sil2100 hugs seb128 [23:07] see your email [23:07] yw [23:07] Isn't it late for you as well? [23:07] so it includes the i18n stuff in the first patch [23:07] :-) [23:07] hug to kenvandine as well for working on those issues [23:07] 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] :) [23:08] robru: Cool, thank you! [23:08] * sil2100 preps the e-mail to the translators [23:08] mandel, it did cause a conflict in the 0417 branch [23:08] mandel, because i wanted to keep the i18n change along with the POTFILES.in fix [23:08] michi: you're welcome. how's silo 10 going? I'm ready to test it in staging [23:09] robru: Trying to figure out how to merge it correctly. [23:09] mandel, can you please rebase your 0417 patch over my refreshed one? [23:09] fun times [23:09] i know that a pita with quilt [23:09] When I merged trunk into my branch, I didn’t get an merge conflicts. [23:09] kenvandine, don't worry, is not such a huge PITA [23:09] kenvandine, I'll do that [23:09] do you have a link to the actual conflict it reported? [23:09] mandel, thx [23:09] kenvandine, nah, thx for taking a look at the translations [23:10] no worries [23:10] that was an easy fix :) [23:10] kenvandine, https://translations.launchpad.net/ubuntu-rtm/15.04/+source/pulseaudio/+pots/pulseaudio/fr/167/+translate [23:10] there you go ;-) [23:10] seb128, thx! [23:10] yw! [23:10] sil2100, ^^ there you go :) [23:10] see how i passed that buck to seb128? [23:10] :-D [23:11] lol [23:11] cross team work! [23:11] ;-) [23:13] indeed :) [23:20] Thanks guys, I sent out a request to translators :) [23:20] Anyway, I guess I go take a shower and sleep, see you tomorrow o. [23:20] o/ [23:25] robru: Just pushed the branch with the conflict resolved. [23:25] michi: great [23:25] building with bzr bd locally now to see whether at least that much works. [23:26] robru: At what stage and by what tool is the changelog parsing done? [23:26] 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] It looks like that’s where the version number comes from for the build [23:26] michi: what do you mean by changelog parsing? [23:27] So, very early during the build, before any of the debian/rules targets runs, something decides what the version number is. [23:27] michi: are you talking about the version number that the train generates and then puts into the changelog? [23:27] Yes [23:27] michi: yeah [23:27] So, I need different numbers here, it seems, for vivid and wily. [23:27] 0.6.x for vivid, and 1.0.x for wily [23:28] michi: uh [23:28] michi: no [23:28] If that is used just temporarily for the build, I’m cool with that. [23:28] As long as the packages that get built have the right version in the end. [23:28] michi: the train will already generate different versions for vivid and wily, but it can't handle different upstream versions for that [23:29] I’m sorry, you lost me there. [23:29] 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] 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] So, how can I force different package names for vivid and wily? [23:30] michi: when the train runs the clean target, your script will run that generates your control file. [23:30] michi: you can't have different version numbers though, the train picks your version numbers for you. [23:31] 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] sec phone… [23:32] 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] Hmmm... [23:34] OK [23:35] 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] Let me see how the build goes. There iare obviouslly things I don’t undestand yet. [23:35] Ah, cool [23:35] Do you happen to know what package that’s in? [23:35] Never mind, I’ll find it. [23:35] michi: lsb-release ;-) [23:36] Oh. [23:36] For once, the package matches the command. [23:36] :) [23:36] yeah, we need more of those [23:36] Of course, it would have been even more excellent to call it “lsb_release” instead of “lsb-release” :( [23:36] michi: underscore is illegal in debian package names because of reasons. so better if the command was "lsb-release" [23:37] Or that, yes [23:45] robru: Just pushed again with lsb-release added to the build deps. Also fixed a problem in the symbols file. [23:46] michi: great, will retry in a sec, just working on something on my end as well [23:46] Sure, no rush! [23:47] michi: here we gooooo! https://ci-train.staging.ubuntu.com/job/ubuntu-landing-008-1-build/3/console [23:47] Watching... [23:48] oh god, that dch list [23:49] michi: I need you to tag a revision to prevent that happening... [23:49] What do I need to do? [23:50] 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] 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] Looking... [23:53] 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] Yes, I don’t think we use tags. [23:55] So, on vivid, the latest released version would be 0.6.19+15.10.20150724.3-0ubuntu1 [23:55] 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] On wily, it’ll be different [23:55] michi: yeah wily is better for dual silos [23:55] Following your advice… :) [23:56] michi: and make sure that tag gets into ~unity-team/unity-scopes-api/devel [23:56] If we manage to merge this branch of mine, that’ll happen automatically, won’t it? [23:57] The tag should be merged with the branch, or do I have that wrong? [23:57] robru: Where did you get the 621 revision from? [23:57] In my branch, the latest one is in the 3-hundreds... [23:58] 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] OK, double-checking...