=== salem_ is now known as _salem [08:12] trainguards, can someone please restart the failed build here https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-033 thanks :) [08:12] Saviq: on it [08:12] Rebuilding :) [08:12] tx === tsdgeos_ is now known as tsdgeos === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === _salem is now known as salem_ === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g === chihchunl is now known as chihchun [13:33] trainguards could anyone have a look at silo 77 and why it is stuck in a 'Preparing Packages' state [13:48] jibel: looking [13:50] hmmm [13:50] jibel: looks normal now, sil just ran a diff_only build job, the packages are built ok and bileto should probably update with "Packages built" soon [13:50] Yeah, I guess it already should, or am I just impatient? [13:52] sil2100: maybe too impatient, at least I'm often left hoping bileto would update faster after a job is done [13:52] sil2100: now it's still that only 15 mins or something? for any status update. [14:00] Let me wait in that case [14:00] ;) [14:01] sil2100: well... I'm starting to be impatient too now :) [14:13] I guess it's officially b0rken [14:29] boiko, 57 approved [14:29] jibel: great! thanks! === bregma_ is now known as bregma === dpm is now known as dpm-afk [14:58] alex-abreu: QA already went through 31, but https://code.launchpad.net/~abreu-alexandre/webbrowser-app/text-color-for-theme-color-webapps/+merge/287058 was not top-approved and it seems mardy has some comments there too. please do not mark a silo ready for QA if all branches are not (top)approved. [15:01] Mirv, yes there was a race in the review vs approval [15:02] Mirv, checking w/ mardy [15:05] jibel, I have to re-push some small updates (minor) to a branch in silo 31, ... I have to mark it as non approved in the meantime, would you mind going QA again on it as soon as it is britney approved? [15:19] alex-abreu, what is the diff with what has previously been tested? [15:19] alex-abreu: thanks for looking into it! [15:19] jibel, small diff, updating the branch in a few mns [15:20] alex-abreu, it should be possible to reland today [15:20] if it's a trivial change [16:03] jibel, the branch have been approved, some small changes associated backed up w/ test updates [16:03] jibel, I am rebuilding the silo to retest [16:03] jibel, https://code.launchpad.net/~abreu-alexandre/webbrowser-app/text-color-for-theme-color-webapps/+merge/287058 [16:39] jibel, I approved silo 31, britney still needs to catch up [16:40] sil2100: Mirv: jibel: indeed the status job for silo 77 was stuck, killed it, should work now [16:40] robru, too late it landed [16:42] jibel: well, no, the status was just stuck at 'publishing' so indeed the status still needs to update to track the migration [16:42] alex-abreu, thanks. It will be retested once the card is created [16:42] like that ^ [16:42] robru, ah ok, I saw the packges uploaded to the overlay ppa [16:42] jibel, wdym by once the card is recreated? you have "rolling cards" ? [16:42] tvoss: jibel: of course this location-service in silo 77 is using the old way of generating debian/control that doesn't work anymore. [16:43] alex-abreu, when automated tests will pass, the silo will be marked ready for QA and a card will be created on the trello board [16:43] jibel, ah sorry yeah === dpm-afk is now known as dpm === alan_g is now known as alan_g|EOD [17:07] robru, which changes do you need? [17:08] tvoss: you're not using bileto_pre_release_hook which means your script is only run at binary package build time, not at source package build time [17:08] tvoss: I'm working on a branch [17:09] robru, can we just put that branch in the silo to be good for landing? [17:09] tvoss: once I finish writing it, yeah. [17:09] tvoss: please stop copy&pasting gen-debian-files.sh into all your projects, it's the old way [17:09] robru, what's the new way? [17:10] tvoss: bileto_pre_release_hook, I have half a dozen branches fixing this in various projects. [17:10] tvoss: this is https://lists.launchpad.net/ubuntu-phone/msg19015.html from two weeks ago [17:16] tvoss: I dunno, your silo was published already, probably easiest to just let it migrate and include my branch in your next silo. [17:19] tvoss: anyway, here's a new branch: https://code.launchpad.net/~robru/location-service/pre_release_hook/+merge/291017 based on top of yours [17:21] robru, ack and thx [17:21] robru, will review it after dinner === tvoss is now known as tvoss|dinner [17:23] ok [17:57] mterry: kenvandine: either of you around to help me with some packaging stuff? https://launchpadlibrarian.net/251771383/buildlog_ubuntu-xenial-amd64.ubuntu-ui-toolkit-gles_1.3.1872+16.04.20160405.1-0ubuntu1_BUILDING.txt.gz I forget how to troubleshoot this [17:59] robru: ok, so qttools5-dev-tools couldn't install [17:59] robru: I don't see the cause there -- can you reproduce locally in a pbuilder or something? [17:59] mterry: not sure how to reproduce it even really. [17:59] mterry: it's a train package, so what, download the source package from the ppa and try building locally? [18:00] mterry: the weird thing is that this package was built by taking a different source package and applying a patch and uploading that, the original one also build-deps on qttools5-dev-tools and that installed ok there [18:00] robru: Yeah... If the package doesn't change build-depends and there are none of the build-depends in the ppa with it, you can just try in any old pbuilder to do: "apt-get build-dep ubuntu-ui-toolkit-gles" [18:00] mterry: so presumably something the patch did brought in a new build dep that conflicts with qttools5-dev-tools but I'm not sure which one [18:01] robru: otherwise you may need to install the silo into your pbuilder [18:01] and then do that [18:01] mterry: yeah the archive version of the package is fine, it's just an experimental ppa package that I broke [18:01] k [18:02] mterry: I'm also trying to review the diff between my experiment and the archive version but it's hard because I ran wrap-and-sort so there's a lot of diff noise [18:03] mterry: is there a way to install build-deps from a local source tree? [18:05] mterry: urgh, builds fine locally after 'sudo apt-get build-dep ubuntu-ui-toolkit-gles; sudo apt-get install qttools5-dev-tools', I'll try again in sbuild. [18:05] robru: from local tree.... pbuilder ships a script to do it... [18:06] mterry: better to use sbuild though since that's what the ppa is using, right? [18:06] robru: sure. I just don't know how sbuild does it :P [18:08] mterry: (excuse me while I debootstrap xenial...) [18:10] mterry: ok I reproduced it locally ;-) [18:10] robru: oh nice, that was fast [18:10] mterry: I guess I need to enter the schroot and poke around? [18:13] robru: yeah... trying to manually install the package from inside schroot should give you better error messages [18:13] mterry: yeah I dunno this is where I get lost. I can run 'sbuild' in the source tree and reproduce the error, but if I enter the schroot manually I'm not sure what commands to run to reproduce it. [18:13] mterry: like the log only says it's trying to install sbuild-build-depends-ubuntu-ui-toolkit-gles-dummy so I don't actually know what packages to try to install to reproduce this [18:13] should be as simple as apt-get install qttools5-dev-tools once the schroot is all set up? [18:15] mterry: no that's not it, that installs fine, also the ubuntu-ui-toolkit (no -gles) from the same PPA also build-deps on that and installs fine. [18:15] mterry: something else is being installed that conflicts with qttools5-dev-tools I thnk [18:15] k [18:16] robru: so this is where I guess you try to figure out the sbuild call that generates and tries to install the sbuild-build-depends-ubuntu-ui-toolkit-gles-dummy metapackage. And try to find out what that metapackage is actually depending on [18:16] robru: (I'm not super familiar with sbuild, I'm not sure) [18:16] mterry: yeah how do I find that? is there an option to sbuild to not clean up after a failure? [18:16] heh [18:17] robru: I'd guess poke around and manually run what sbuild automatically runs -- trick is finding that command line [18:17] robru: or if there is an option to not clean up, that would be good too [18:17] kenvandine: do you know sbuild better than me? ^ [18:17] mterry, i use it sometimes :) [18:18] ah, no idea what does that [18:18] i bet that's a flavor/arch issue [18:18] mterry: erk, so eg here's the patch I'm applying: http://bazaar.launchpad.net/~robru/ubuntu-ui-toolkit/inline-gles-quilt/view/head:/debian/gles-patches/convert-to-gles.patch so I just tried 'apt-get install qttools5-dev-tools [all the new build-deps added by the patch]' and it worked. so that's really weird. [18:19] was expecting one would conflict [18:27] mterry: hrm, found one thing build-dep'ing on a package that doesn't exist, not sure if that's related. will try rebuilding it in the ppa, brb [18:49] mterry: blah, didn't help [18:57] mterry: ok I'm officially stumped, I tried installing the full list of build deps in a schroot and it worked. I can only reproduce it with sbuild on the source tree, not with apt-get in a schroot [18:57] :( [18:59] robru: and examining the diff for oddness didn't yield any clues? [19:00] mterry: it's difficult because the -gles package has drifted significantly from the non-gles trunk that it's supposed to track, so I'm seeing this huge diff and I can't tell what's there because I've updated it to match the trunk and what's there because I've made a mistake [19:00] mterry: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_363fe1b4bfe34b0295bc243be24dfbf1/bileto-1166/2016-04-05_18:30:03/xenial/ubuntu-ui-toolkit-gles/packaging_changes.diff [19:01] robru: and the diff between it and non-gless is still tiny? [19:01] mterry: look at convert-to-gles.patch in the scrollback, it's small [19:03] robru: yup. But does at least muck with the build-deps so that's comforting. Explains why we might die with -gles but not the other way [19:03] mterry: yeah, but like I said, I tried a manual apt-get install of the complete list of build deps with that patch applied and it worked. [19:04] robru: as a sanity experiment, I'm assuming if you take just the Build-Dep changes and port them to to the non-gles version, you'd die locally on the same error (obvi it would ftbfs too later, but we wouldn't see that) [19:04] hmm [19:05] robru: the fix for this might be using some -gles version of some new build-depend [19:07] mterry: indeed, if I take lp:ubuntu-ui-toolkit trunk and apply only the build-dep changes I reproduce the same error [19:13] mterry: I think I need to declare bankruptcy and start over, this is holding up a major rollout I need to do sooner rather than later. [19:14] robru: might be worth asking Mirv or someone about that convert-to-gles patch and if there are other -gles changes needed these days [19:14] robru: someone closer to the gles stuff might know about something we don't [19:16] mterry: yeah that's a good idea. For now just to get things moving I'll try a different approach where I just verbatim copy the known-working current debian/control from the gles package and then leave the packaging-drift-cleanup to the toolkit people. [19:21] mterry: thanks for you help! [19:21] robru: yeah sorry it wasn't a slam dunk [19:21] good luck [19:22] thanks [19:35] robru, the changes done in debia/control should be done in debian/control.in [19:36] robru, and I actually think you don't need them [19:38] tvoss|dinner: i just ran the script and committed the results, so it's updating control to match what's already in control.in [19:40] tvoss|dinner: and you do need them because control should match what's in xenial, not vivid [19:40] robru, ack [19:42] robru, as long as the vivid package still installs with an soversion of 2, I'm mostly fine with your changes [19:43] tvoss|dinner: yeah it should, but i didn't test it [19:43] Will need a silo at some point to confirm === salem_ is now known as _salem