| === salem_ is now known as _salem | ||
| 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 | 08:12 |
| === 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 | ||
| jibel | trainguards could anyone have a look at silo 77 and why it is stuck in a 'Preparing Packages' state | 13:33 |
| Mirv | jibel: looking | 13:48 |
| 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:50 |
| 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. | 13:52 |
| sil2100 | Let me wait in that case | 14:00 |
| sil2100 | ;) | 14:00 |
| Mirv | sil2100: well... I'm starting to be impatient too now :) | 14:01 |
| sil2100 | I guess it's officially b0rken | 14:13 |
| jibel | boiko, 57 approved | 14:29 |
| boiko | jibel: great! thanks! | 14:29 |
| === bregma_ is now known as bregma | ||
| === dpm is now known as dpm-afk | ||
| 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. | 14:58 |
| alex-abreu | Mirv, yes there was a race in the review vs approval | 15:01 |
| alex-abreu | Mirv, checking w/ mardy | 15:02 |
| 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:05 |
| 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:19 |
| jibel | alex-abreu, it should be possible to reland today | 15:20 |
| jibel | if it's a trivial change | 15:20 |
| 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:03 |
| alex-abreu | jibel, I approved silo 31, britney still needs to catch up | 16:39 |
| 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:40 |
| 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:42 |
| 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 | 16:43 |
| === dpm-afk is now known as dpm | ||
| === alan_g is now known as alan_g|EOD | ||
| tvoss | robru, which changes do you need? | 17:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:16 |
| 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:19 |
| tvoss | robru, ack and thx | 17:21 |
| tvoss | robru, will review it after dinner | 17:21 |
| === tvoss is now known as tvoss|dinner | ||
| robru | ok | 17:23 |
| 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:57 |
| 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? | 17:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| robru | mterry: is there a way to install build-deps from a local source tree? | 18:03 |
| 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:05 |
| 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:06 |
| robru | mterry: (excuse me while I debootstrap xenial...) | 18:08 |
| 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:10 |
| 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:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| robru | was expecting one would conflict | 18:19 |
| 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:27 |
| robru | mterry: blah, didn't help | 18:49 |
| 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:57 |
| mterry | robru: and examining the diff for oddness didn't yield any clues? | 18:59 |
| 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:00 |
| 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:01 |
| 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:03 |
| 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:04 |
| mterry | robru: the fix for this might be using some -gles version of some new build-depend | 19:05 |
| robru | mterry: indeed, if I take lp:ubuntu-ui-toolkit trunk and apply only the build-dep changes I reproduce the same error | 19:07 |
| 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:13 |
| 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:14 |
| 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:16 |
| robru | mterry: thanks for you help! | 19:21 |
| mterry | robru: yeah sorry it wasn't a slam dunk | 19:21 |
| mterry | good luck | 19:21 |
| robru | thanks | 19:22 |
| tvoss|dinner | robru, the changes done in debia/control should be done in debian/control.in | 19:35 |
| tvoss|dinner | robru, and I actually think you don't need them | 19:36 |
| 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:38 |
| 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:40 |
| tvoss|dinner | robru, as long as the vivid package still installs with an soversion of 2, I'm mostly fine with your changes | 19:42 |
| robru | tvoss|dinner: yeah it should, but i didn't test it | 19:43 |
| robru | Will need a silo at some point to confirm | 19:43 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!