=== _salem is now known as salem_ === salem_ is now known as _salem === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [11:25] tvoss: you'll need to include the changelog entries for no-change rebuilds https://launchpad.net/ubuntu/+source/location-service/3.0.0-0ubuntu3 and https://launchpad.net/ubuntu/+source/location-service/3.0.0-0ubuntu4 in your MP:s changelog and have your UNRELEASED changelog entry be ubuntu5 [11:26] Mirv, ack [12:03] jibel, can we mark 68 approved and get it published? [12:04] pmcgowan, we are waiting u-d-f to publish it at the same time [12:04] jibel, is someone working on udf? === tsdgeos_ is now known as tsdgeos === alan_g is now known as alan_g|lunch === _salem is now known as salem_ === alan_g|lunch is now known as alan_g [14:33] mterry, ok can we publish silo 68 now? [14:34] pmcgowan: ah it got QA approval again? sure let me look [14:36] mterry, yep and the u-d-f tool is available now [14:36] pmcgowan: ? I don't remember that [14:37] mterry, they go together [14:37] if you want to flash with new adb setup [14:37] that comes out of the phablet PPA [14:37] pmcgowan: publishing [14:38] great [15:14] Mirv: hey! You still around? :) [15:14] Mirv: we would need someone with ubuntu-sdk-team permissions to do some binary package copies [15:16] huh [15:17] A lot of internal errors in bileto I see [15:17] mterry, seems that silo got stuck maybe [15:18] shake it [15:21] * pmcgowan shakes silo 68 [15:21] sil2100: can we retry? there seems to have been some kind of network blip affecting LP [15:21] but things look OK at the moment [15:21] hm, let me do that [15:22] pmcgowan: well, silo 68 is good, don't worry [15:22] pmcgowan: all the packages are in the overlay, some of the packages are in UNAPPROVED since xenial is frozen [15:23] sil2100, great thanks [15:23] Some release team member will approve those [15:23] jibel, pmcgowan: eh, found the bug that was causing us missing the ubuntu-settings-components translations for the VPN view... [15:23] oh [15:24] jibel, pmcgowan: testing a fix right now, but it seems we weren't merging the mapping files from translation tarballs properly [15:24] So we'll have to re-spin langpacks once I check my fix locally [15:24] Which means we'll have new langpacks in a bit today [15:24] (I'll copy them over to the snapshot later) [15:26] sil2100: o/ [15:27] sil2100: tell me [15:28] Mirv: yay! Soooo, we would need *binary* copies of the https://launchpad.net/~phablet-team/+archive/ubuntu/tools goget-ubuntu-touch package (the one from xenial) into xenial, wily and trusy in the stable SDK ppa (https://launchpad.net/~ubuntu-sdk-team/+archive/ubuntu/ppa) [15:28] Mirv: those have to be *binary* copies [15:28] Mirv: so just taking the xenial package of goget-ubuntu-touch and copying it with binaries to xenial, wily and trusty (yes, using the same versioning and same contents ;p) [15:28] As the package will not build in normal environments [15:29] sil2100: ok [15:29] sil2100: sorry, might take a few mins, need to sort something out [15:30] Mirv: could I also ask you to dput two packages there as well? I'll give you all the source bits [15:31] As my dputs obviously failed as I have no permissions to upload there [15:31] :< [15:31] sil2100: sure just queue them to my "I can type with my laptop's keyboard" queue :) [15:31] Thanks! [15:33] Mirv: the two packages in mention are here http://people.canonical.com/~lzemczak/packaging/ === chihchun is now known as chihchun_afk [15:38] sil2100: hmm weird, it does not allow binary copying xenial package to wily/trusty, see errors https://launchpad.net/~ubuntu-sdk-team/+archive/ubuntu/ppa/+packages - unless it's because as it states "already building" since it's building the armhf version since the other PPA had only x86 [15:38] hmmm [15:39] Mirv: what errors do you get? I guess it might be a strange case here [15:39] Let's wait for it to fail building for those and then try the bin-copy again [15:39] sil2100: look at the top of the page for the errors, I didn't clear them [15:40] Ah, indeed! [15:42] sil2100: I mean, normally I think it has been just fine to have exact same version number, but for a different series [15:42] (in PPA) [15:42] Yeah [15:42] That's what we have in the phablet tools PPA [15:42] One package with the same version for different series [15:43] It's bad practice but this is the only way we can make it work here [15:43] pmcgowan, jibel: new language-packs are building [15:43] sil2100: ah, hmm [15:43] sil2100: let me try copying inside the same PPA the now already copied one [15:43] pmcgowan, jibel: once those finish, how about we kick a new rc-proposed image? [15:43] Mirv: oh [15:43] Mirv: ok, maybe that will somehow work better [15:45] sil2100: well it "worked", I mean I was just trying because that what I've done earlier. but it only worked for wily because the armhf build for xenial had already failed, so indeed I need to wait for the armhf build before I can do the next :) so completing with trusty in 5 mins or so [15:46] sil2100: meanwhile uploaded the two android-tools packages [15:46] sil2100, sounds good [15:49] sil2100: android-tools trusty failed because of missing build dependency libsystemd-dev. wily succeeded. [15:50] Mirv: thanks! Ok, we'll try to solve that somehow, hmmm [15:50] We'll maybe have to tweak the package a bit, not just a brainless copy [15:51] sil2100: this was the tools package, for which you provided a source, not to goget-ubuntu [15:52] Yeah, I know :) [15:52] It was a brainless source copy, just changing the version I did [15:52] sil2100: ah, right :) [15:53] sil2100: I tried changing it to libsystemd-dev | libsystemd-daemon-dev, but the next build problem then is selinux related http://pastebin.ubuntu.com/15577772/ at least locally [15:54] tried uploading that now too but indeed probably needs some small code changes [16:01] sil2100: anyhow, goget-ubuntu-touch is now all done, and the android-tools wily [16:01] Mirv: thank you! [16:38] Mirv: ok, don't worry about android-tools, I got a green light to do a bin-copy - and now I have the powers to do that [16:38] Mirv: thanks again! [16:54] sil2100: anyone who can publish https://requests.ci-train.ubuntu.com/#/ticket/1153 ? === alan_g is now known as alan_g|EOW [17:01] Trevinho: will do in a moment [17:01] sil2100: thanks [20:31] robru, you should rm .pc/ [20:31] *not* [20:31] Saviq: nope, that has to go [20:32] meh, why's it a problem? debhelper/dpkg thinks quilt is in play? [20:32] Saviq: otherwise it gets included in the orig.tar which is horrible and wrong [20:32] Saviq: and then all your packaging diffs are going to start including these huge .pc blobs of horribleness [20:32] meh, just means you can go back when you unpack the tarball [20:33] right, that [20:33] Saviq: why would you want to go back? the -gles is produced in parallel with the regular one, so you always have both [20:33] robru, I rather mean during dev, but mah [20:33] Saviq: you can always bzr revert [20:33] yeah exactly [20:34] Saviq: the .pc dir is an implementation detail that really shouldn't be leaked out of the script [20:34] and find -name '*~' -exec rm {} + :P [20:34] whoever thought it would be a good idea to leave all those *~ files around after a revert... [20:35] robru, did you come up with a way to skip the test on gles? [20:35] Saviq: I just reverse-apply the patch at the start of the test so that -gles and nongles both run the test from the same start point [20:36] Saviq: it seems to have worked but now the tests fail at some other point I don't understand, can you look? https://launchpadlibrarian.net/250718484/buildlog_ubuntu-xenial-amd64.qtmir-gles_0.4.8+16.04.20160401-0ubuntu1_BUILDING.txt.gz [20:36] robru, Gerry replied via email, we'll have to look into it Monday [20:36] oh alright [20:37] robru, TBH I'd rather skip the test in gles rather than reverse-apply - because you end up with a different source tree after testing [20:37] Saviq: right, I'll fix that [20:38] a simple head debian/changelog | grep -q 'gles' or something [20:38] Saviq: but actually, are you sure the test is needed? because if the patch fails to apply then the source package build will fail in the train, you'll find out within a few minutes of clicking build. [20:38] robru, in CI we're not yet building gles [20:39] hmm [20:39] robru, and people running tests locally [20:39] fair [20:46] bbl, lunch === salem_ is now known as _salem [22:37] Goodnight o/