[08:12] <Saviq> trainguards, can someone please restart the failed build here https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-033 thanks :)
[08:12] <sil2100> Saviq: on it
[08:12] <sil2100> Rebuilding :)
[08:12] <Saviq> tx
[13:33] <jibel> trainguards could anyone have a look at silo 77 and why it is stuck in a 'Preparing Packages' state
[13:48] <Mirv> jibel: looking
[13:50] <sil2100> hmmm
[13:50] <Mirv> 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] <sil2100> Yeah, I guess it already should, or am I just impatient?
[13:52] <Mirv> sil2100: maybe too impatient, at least I'm often left hoping bileto would update faster after a job is done
[13:52] <Mirv> sil2100: now it's still that only 15 mins or something? for any status update.
[14:00] <sil2100> Let me wait in that case
[14:00] <sil2100> ;)
[14:01] <Mirv> sil2100: well... I'm starting to be impatient too now :)
[14:13] <sil2100> I guess it's officially b0rken
[14:29] <jibel> boiko, 57 approved
[14:29] <boiko> jibel: great! thanks!
[14:58] <Mirv> 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] <alex-abreu> Mirv, yes there was a race in the review vs approval
[15:02] <alex-abreu> Mirv, checking w/ mardy
[15:05] <alex-abreu> 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] <jibel> alex-abreu, what is the diff with what has previously been tested?
[15:19] <Mirv> alex-abreu: thanks for looking into it!
[15:19] <alex-abreu> jibel, small diff, updating the branch in a few mns
[15:20] <jibel> alex-abreu, it should be possible to reland today
[15:20] <jibel> if it's a trivial change
[16:03] <alex-abreu> jibel, the branch have been approved, some small changes associated backed up w/ test updates
[16:03] <alex-abreu> jibel, I am rebuilding the silo to retest
[16:03] <alex-abreu> jibel, https://code.launchpad.net/~abreu-alexandre/webbrowser-app/text-color-for-theme-color-webapps/+merge/287058
[16:39] <alex-abreu> jibel, I approved silo 31, britney still needs to catch up
[16:40] <robru> sil2100: Mirv: jibel: indeed the status job for silo 77 was stuck, killed it, should work now
[16:40] <jibel> robru, too late it landed
[16:42] <robru> jibel: well, no, the status was just stuck at 'publishing' so indeed the status still needs to update to track the migration
[16:42] <jibel> alex-abreu, thanks. It will be retested once the card is created
[16:42] <robru> like that ^
[16:42] <jibel> robru, ah ok, I saw the packges uploaded to the overlay ppa
[16:42] <alex-abreu> jibel, wdym by once the card is recreated? you have "rolling cards" ?
[16:42] <robru> 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] <jibel> 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] <alex-abreu> jibel, ah sorry yeah
[17:07] <tvoss> robru, which changes do you need?
[17:08] <robru> 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] <robru> tvoss: I'm working on a branch
[17:09] <tvoss> robru, can we just put that branch in the silo to be good for landing?
[17:09] <robru> tvoss: once I finish writing it, yeah.
[17:09] <robru> tvoss: please stop copy&pasting gen-debian-files.sh into all your projects, it's the old way
[17:09] <tvoss> robru, what's the new way?
[17:10] <robru> tvoss: bileto_pre_release_hook, I have half a dozen branches fixing this in various projects.
[17:10] <robru> tvoss: this is https://lists.launchpad.net/ubuntu-phone/msg19015.html from two weeks ago
[17:16] <robru> 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] <robru> 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] <tvoss> robru, ack and thx
[17:21] <tvoss> robru, will review it after dinner
[17:23] <robru> ok
[17:57] <robru> 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] <mterry> robru: ok, so qttools5-dev-tools couldn't install
[17:59] <mterry> robru: I don't see the cause there -- can you reproduce locally in a pbuilder or something?
[17:59] <robru> mterry: not sure how to reproduce it even really.
[17:59] <robru> mterry: it's a train package, so what, download the source package from the ppa and try building locally?
[18:00] <robru> 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] <mterry> 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] <robru> 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] <mterry> robru: otherwise you may need to install the silo into your pbuilder
[18:01] <mterry> and then do that
[18:01] <robru> mterry: yeah the archive version of the package is fine, it's just an experimental ppa package that I broke
[18:01] <mterry> k
[18:02] <robru> 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] <robru> mterry: is there a way to install build-deps from a local source tree?
[18:05] <robru> 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] <mterry> robru: from local tree.... pbuilder ships a script to do it...
[18:06] <robru> mterry: better to use sbuild though since that's what the ppa is using, right?
[18:06] <mterry> robru: sure.  I just don't know how sbuild does it  :P
[18:08] <robru> mterry: (excuse me while I debootstrap xenial...)
[18:10] <robru> mterry: ok I reproduced it locally ;-)
[18:10] <mterry> robru: oh nice, that was fast
[18:10] <robru> mterry: I guess I need to enter the schroot and poke around?
[18:13] <mterry> robru: yeah...  trying to manually install the package from inside schroot should give you better error messages
[18:13] <robru> 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] <robru> 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] <mterry> should be as simple as apt-get install qttools5-dev-tools once the schroot is all set up?
[18:15] <robru> 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] <robru> mterry: something else is being installed that conflicts with qttools5-dev-tools I thnk
[18:15] <mterry> k
[18:16] <mterry> 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] <mterry> robru: (I'm not super familiar with sbuild, I'm not sure)
[18:16] <robru> mterry: yeah how do I find that? is there an option to sbuild to not clean up after a failure?
[18:16] <robru> heh
[18:17] <mterry> robru: I'd guess poke around and manually run what sbuild automatically runs -- trick is finding that command line
[18:17] <mterry> robru: or if there is an option to not clean up, that would be good too
[18:17] <mterry> kenvandine: do you know sbuild better than me? ^
[18:17] <kenvandine> mterry, i use it sometimes :)
[18:18] <kenvandine> ah, no idea what does that
[18:18] <kenvandine> i bet that's a flavor/arch issue
[18:18] <robru> 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] <robru> was expecting one would conflict
[18:27] <robru> 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] <robru> mterry: blah, didn't help
[18:57] <robru> 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] <mterry> :(
[18:59] <mterry> robru: and examining the diff for oddness didn't yield any clues?
[19:00] <robru> 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] <robru> 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] <mterry> robru: and the diff between it and non-gless is still tiny?
[19:01] <robru> mterry: look at convert-to-gles.patch in the scrollback, it's small
[19:03] <mterry> 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] <robru> 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] <mterry> 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] <robru> hmm
[19:05] <mterry> robru: the fix for this might be using some -gles version of some new build-depend
[19:07] <robru> mterry: indeed, if I take lp:ubuntu-ui-toolkit trunk and apply only the build-dep changes I reproduce the same error
[19:13] <robru> 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] <mterry> 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] <mterry> robru: someone closer to the gles stuff might know about something we don't
[19:16] <robru> 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] <robru> mterry: thanks for you help!
[19:21] <mterry> robru: yeah sorry it wasn't a slam dunk
[19:21] <mterry> good luck
[19:22] <robru> thanks
[19:35] <tvoss|dinner> robru, the changes done in debia/control should be done in debian/control.in
[19:36] <tvoss|dinner> robru, and I actually think you don't need them
[19:38] <robru> 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] <robru> tvoss|dinner: and you do need them because control should match what's in xenial, not vivid
[19:40] <tvoss|dinner> robru, ack
[19:42] <tvoss|dinner> robru, as long as the vivid package still installs with an soversion of 2, I'm mostly fine with your changes
[19:43] <robru> tvoss|dinner: yeah it should, but i didn't test it
[19:43] <robru> Will need a silo at some point to confirm