=== blr_ is now known as blr [08:15] Mirv, is https://code.launchpad.net/~timo-jyrinki/webbrowser-app/no-change-rebuild-qt551/+merge/278928 still needed? [08:16] oSoMoN: sure not, it was even landed but Train/LP doesn't really know how to merge that empty MP [08:17] (or maybe I did a manual upload in December, I don't remember) [08:17] Mirv, should the branch just be deleted? [08:18] oSoMoN: I marked it as merged for the revision it did get merged to, it seems http://bazaar.launchpad.net/~phablet-team/webbrowser-app/trunk/revision/1293 [08:18] Mirv, perfect, thanks! [08:18] so train handles everything but not marking the branch as merged [08:23] trainguards: hey, could anybody look at [1]? Nothing changed in trunk since last successful landing, so it's a bit puzzling why it ftbfs. [1] https://ci-train.ubuntu.com/job/ubuntu-landing-058-1-build/53/console [08:32] I guess no landing meeting today as sil away [08:35] Mirv, no, the only tihng to discuss is rootfs build and silo 58 landing [08:35] jibel: ok [08:35] Mirv, for 1 we need sil or ogra_ and 2 is in progress [08:44] jgdx: ok I've found something now that I'm a bit healthier. the lp:ubuntu-push/automatic branch is not based on the trunk and that's the likely cause for the problems. it at least misses all train changelog entries since last August [08:45] jgdx: so maybe it's just something that needs merging once in a while [08:45] jgdx: that's the only thing I've found so far, but I'm trying to make various hacks in the branch to see what could lead to success... the old changelog entry might lead it to fetch some old tarball from somewhere instead of creating new orig tarball or something [08:47] Mirv, I think the proper fix for that is to deprecate automatic in favor of running CI on trunk. [08:48] jgdx: ok it'd seem like syncing the changelog entries would fix the issue https://ci-train.ubuntu.com/job/ubuntu-landing-023-1-build/31/console [08:49] Mirv, okay, let's do that [08:49] jgdx: whatever works the best for you, but if you start to run in to too many problems you could consider that. SDK team for example does use a staging branch from where they land single MP to trunk. [08:49] so it's not like you'd be the only one [08:51] Mirv, this is the change? https://code.launchpad.net/~jonas-drange/ubuntu-push/sync-chlog/+merge/293514 [08:53] Mirv, and then I'll need to merge that into silo 58, right? [08:56] jgdx: yes, that looks correct [08:57] jgdx: note that I did try two other things first but I doubt they mattered, so let's try with just that [08:57] Mirv, I don't understand the status of https://requests.ci-train.ubuntu.com/#/ticket/1241 . It has been approved and published and half landed [08:58] Mirv, could you give me a +1 on https://code.launchpad.net/~jonas-drange/ubuntu-push/sync-chlog/+merge/293514 ? [09:01] jibel: it looks like both were published (https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/1/console) but account-polld was rebuilt after that [09:04] Mirv, so should we reapprove? [09:05] jibel: seems so, and train wise this kind of method works just fine, republishing works [09:16] Mirv, jibel: do we got an image build over the weekend? [09:17] morphis, no, the rootfs fails to build because the password file changed [09:17] oh [09:17] jibel: which password file? [09:17] morphis, and we should get bug 1575184 fixed first [09:17] bug 1575184 in Ubuntu Push Notifications "ubuntu-push is flooding dbus with NameOwnerChanged signals" [High,In progress] https://launchpad.net/bugs/1575184 [09:18] jibel: afaik that just landed [09:18] morphis, it didn't the silo didn't even build [09:18] hm, I saw a mail from citrain [09:19] it's empty https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-058 [09:19] jibel: do we know why its not building? [09:20] morphis, Mirv and jgdx are on it, some unmerged changes in trunk apparently [09:20] I see [09:20] morphis, and for the rootfs https://launchpadlibrarian.net/257185922/buildlog_ubuntu_vivid_armhf_ubuntu-touch_BUILDING.txt.gz [09:20] scroll down to the bottom [09:20] There were changes to the password database, [09:20] please adjust the values in the livecd-rootfs source in the file: [09:20] ah [09:20] live-build/ubuntu-touch/hooks/00-uid-gid-fix.chroot_early [09:21] looks like we got dhcpd as new one [09:21] Mirv, do you know where tarmac runs, and does it have a web view of some kind? I get nervous when it takes > 20 mins to merge automatic. [09:21] trainguards: when will we have triple-landings? [09:22] jibel: so the dhcpd addition is fine as that is coming with us having ics-dhcp now installed [09:32] jibel, Mirv: does any of you know if the livecd-rootfs fix from awe landed? [09:33] morphis, it didn't [09:33] hm [09:33] morphis, we decided to wait until sil is back [09:33] ok [09:33] morphis, but it could land today [09:34] morphis, didn't want to land on a Friday evening [09:34] jibel: so what are we doing with the cahnge password file? [09:34] morphis, we need sil or ogra_ or slangasek [09:34] ok [09:34] morphis, we could land the livecd rootfs change at the same time [09:35] morphis, Lukasz is on vacations until Wed, ogra_ seems to be offline [09:36] perfect .. [09:40] jibel, i'm around, sorry, didnt have time to check yet [09:41] ogra_, np we need another silo before building a new image anyway. Otherwise the phone is barely usable [09:41] k [09:42] ogra_, you usually respond instantaneously. Since you didn't I assumed you were offline :) [09:43] heh [10:13] jgdx: did it merge yet? but no, no direct view to tarmac. [10:14] Mirv, no, it didn't [10:14] oSoMoN: later (a few weeks), we start with vivid+xenial and get xenial in better shape. [10:15] Mirv, ok [10:15] Mirv, and last time tarmac failed, it took two days to report back. Not sure we have that kind of time. [10:15] jgdx: what do you know about your CI system? I'm unfamiliar with the one that adds these [r=morphis] tags. I mean I could just merge it manually. [10:15] jgdx: if it doesn't break anything [10:16] Mirv, I know nothing about it. [10:16] jgdx: :) [10:17] jgdx: well, let's revert the automatic branch to rev 426 if there's any problem, but I doubt there is [10:17] Mirv, okay dokay [10:18] jgdx: ok, just try to rebuild your silo now [10:19] Mirv, building… [10:19] jgdx: same error I see [10:20] jibel, so looking at https://launchpadlibrarian.net/257185922/buildlog_ubuntu_vivid_armhf_ubuntu-touch_BUILDING.txt.gz ... the dhcpd user is wanted in the images ? [10:20] morphis, ^ [10:20] (seems like some postinst creates it) [10:20] ogra_: yes, we're installing ics-dhcp now [10:20] ok [10:20] to have dhclient and dhcpd [10:20] the daemon ? [10:21] interesting [10:21] yes [10:22] we need it for WiFi Direct support [10:22] ogra_: but we're only running it on demand so the upstart job is set to manual [10:22] heh, wihle we'Re at at ... i somehow broke my wifi on the M10 ... by making a BLE mouse work [10:22] Mirv, --exclude=.bzr* --exclude=.git* and then “the modified files are:ubuntu-push/docs/example-server/.bzrignore […]”? [10:23] ogra_: hah :-) [10:23] ogra_: but the BLE mouse works now? [10:23] (as soon as i enable BT now i cant get any data through) [10:23] do you know any ways to reset that ? [10:24] morphis, i cant "unpair" it anymore ... [10:24] ogra_: you can erase the BT state with rm -rf /var/lib/bluetooth/* [10:24] then reboot [10:25] but that will remove all stored state information for BT [10:25] jgdx: ok, iterating, please rebuild again [10:25] building… [10:26] jgdx: I was again able to start a build with my own branch, so it seems 2/3 of the changes I did were actually needed.. [10:26] jgdx: it's working! [10:27] Mirv, don't jinx it!!11 [10:27] as soon as BT is enabled and the mouse is powered it connects ... [10:27] ah, thanks ! [10:27] /bin/echo -e 'scan on\ndiscoverable on\nagent on\ndefault-agent\npairable on\npair E2:5D:E0:E7:46:00\nquit'|bluetoothctl [10:27] thats what i used ... [10:27] microsoft designer mouse ... [10:27] jibel, hmm, did sil not upload the livecd-rootfs change for NM last week ? [10:27] ogra_, he didn't [10:28] * ogra_ still sees the olf livecd-rootfs in the overlay [10:28] *old [10:28] ogra_, we could merge it today, it's in silo 52 or you prefer to wait for lukasz? [10:29] silo 42* [10:29] I'll approve it, there is not much to test [10:30] jgdx: it's building. BUT. the build is failing on vivid. [10:31] jgdx: succeeding on xenial. [10:32] jgdx: and over there you have something that unfortunately doesn't look any less mysterious at first sight than your previous problem... what on earth is that "cp: cannot stat ‘debian/tmp/=>’: No such file or directory" [10:32] Mirv, where do you see that? What's the failure [10:32] jgdx: in your silo, expanding the lines https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-058/+packages [10:33] jgdx: some test failures also on xenial. it's like the world would have exploded between your last landing in March and now. since your new landing is as simple as it is... [10:36] Mirv, some of the tests have always been flaky [10:36] but yeah, this is worse than usual === ogra_` is now known as ogra_ [11:04] Mirv, Samuele, who previously worked on u-p, will take a look later today. I'm no deb packaging expert, so I can't effectively debug the debian/tmp issue, but will take a look at making the tests less flaky. [11:05] … will also try to escalate this issue a bit [11:05] jgdx: it's as if a file named "=>" would be tried to be installed [11:06] jgdx: well, it seems in ubuntu-push-client.install there is a line "usr/bin/ubuntu-push => /usr/lib/ubuntu-push-client/ubuntu-push-client" which is then probably erronous or some new feature that was not available in vivid [11:06] jgdx: I just have zero idea how the 0310.2 was able to build and publish in March with all that stuff [11:08] Mirv, yeah, how to rationally explain that? [11:13] jgdx: well, I guess it's not wrong then but maybe there's a new hidden problem elsewhere so that after build the files are not where they should be. I mean, checking the source https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/6201985/+listing-archive-extra it also had ">=" lines in .install files and the overlay can't regress like that to not support the synta [11:13] x so it must be something else [11:23] Mirv, builds fine on xenial+stable overlay btw [11:26] scratch that for now, I have pending updates. [12:01] Mirv, xenial+overlay builds fine. Are there any special parameters to those LP builds? If only I could reproduce locally [12:03] renatu, silo 1 re-approved [12:03] jgdx: the only special ones are the custom lines in debian/rules [12:03] jibel, thanks [12:04] jgdx: override_dh_auto_build for building and override_dh_auto_test for running the tests [12:04] jgdx: usually you can think of dh_auto_build as "make" and dh_auto_test as "make check", but there might be more to it [12:04] especially as build system golang is used [12:06] Mirv, so it's substantially different from my running $ bzr bd [12:08] jgdx: no, not of couse since bzr bd runs the debian packaging so it's exactly the same. then the differences only come down to system environment between builders (only install compiler and minimum amount of build dependencies) and your machine (full desktop machine) [12:09] trainguards could you publish silo 29? I am not authorized bc of package changes [12:09] Mirv, okay, thx. Will set up a lxc and do some digging [12:09] jibel: i just uploaded http://paste.ubuntu.com/16188132/ to the overlay ... tell me if there are still issues with the next build [12:10] s/lxc/schroot [12:13] alexabreu: done. [12:13] Mirv, thank you :) === _salem is now known as salem_ [13:04] Mirv, u-p builds fine on a minimal xenial chroot. Is this infra? [13:22] trainguards: hey, could the build env in silo 58 be bad? Is there a way to reset it? [13:26] jgdx: does your chroot use -proposed? [13:27] jgdx: and why does it fail on all archs on vivid? [13:28] dobey, hey i'm asking the questions here [13:28] chroot does not use proposed [13:28] dobey, that's what we're trying to figure out [13:29] jgdx: silo has proposed, and the stable-phone-ovrlay ppa [13:29] but i'm not sure proposed is the issue here, given all the archs fail on vivid [13:30] dobey, on vivid there's that funky cp: cannot stat ‘debian/tmp/=>’: No such file or directory error [13:30] I'm building a vivid chroot to repro [13:31] jgdx: oh that looks like a bug in debian/*.install or something [13:31] or maybe in debian/rules [13:39] trainguards Hi! I see there are 147 updates since last upgrade. Can we make an exception and publish a new image today ? [13:40] (rc-proposed) [13:41] ondra, any news on https://trello.com/c/gzf3hdwh/3111-1299-ubuntu-landing-035-indicator-display-charles-ondra ? [13:43] om26er, it doesn't build and don't want to build one before silo 58 lands [13:45] jibel, silo 58, hmm, I have that on my desktop as well. Probably related to Libertine ? [13:45] om26er, I doubt you have silo 58 on your desktop it fails to build. [13:46] om26er, https://requests.ci-train.ubuntu.com/#/silo/058 [13:47] jibel, I added it a week ago following[1] and at that time it had libertine in it. I see now it has ubuntu-push.[1] https://wiki.ubuntu.com/Touch/Libertine [13:49] ChrisTownsend, ^you might want to update https://wiki.ubuntu.com/Touch/Libertine the ppa part is obsolete now. [13:50] om26er: Ok, thanks for the reminder. [13:53] dobey, right, how would I create a proposed chroot? I can't get the build to fail on vivid+overlay [14:01] jgdx: just edit /etc/apt/sources.list and for all the xenial-updates entries, copy them and replace xenial-updates with xenial-proposed [14:02] jgdx: 058 seems normal by all accounts. if you were testing xenial, note that amd64 did pass but armhf and i386 failed (could be retried). if you were testing vivid-proposed, then that's still a big question mark. [14:02] om26er: there's a problem with image build, that's why there are many updates since last image build that was last week [14:03] Mirv, thanks, I will wait for things to settle, for now 'apt upgrade' will do :) [14:05] jgdx: also the same failures happened in my test silo 023 [14:15] jgdx: ok you should probably really consult the packager of the package but if you take the two changes at the bottom: https://code.launchpad.net/~timo-jyrinki/ubuntu-push/test_ignore_file_removal/+merge/293511 (.install files) also vivid seems to compile. it seems the usr/bin/ubuntu-push and usr/bin/dev files are already there so they can be just "included". I don't know if they the intended symlinks [14:15] or what, and what exactly got broken but the ">= /usr/bin/..." parts seem unneeded. [14:15] jgdx: and the xenial errors seem a bit flaky at least. [14:16] Mirv, they are flaky and I've asked Samuele to look at why those test fail like that. IIRC he fixed them once, maybe he can fix them twice. [14:17] Mirv, and as for consulting the packager, I'm trying but no one's answering right now. [14:18] jibel: sorry, you highlighted me but I don't have the context. what do you need? "change password file"? [14:18] jgdx: ok, then just take the two .install files changes from my MP and include them in your silo, build and check the end results after a hopefully successful build(s) [14:18] slangasek, that's fine, ogra_ took care of it. touch image faied to build because the password file changed. [14:18] o [14:18] ok [14:21] Mirv, okay, let's try that [14:23] Mirv, from r430 and r429, right? [14:23] jgdx: yes, but maybe easier just staring at the bottom of the MP page and apply manually just those two [14:24] and ignore the debian/rules changes [14:24] ondra, any news on https://trello.com/c/gzf3hdwh/3111-1299-ubuntu-landing-035-indicator-display-charles-ondra ? [14:25] Mirv, yeah, will do it manually [14:25] jgdx: you just need to remove the "=>" in the .install files [14:25] jgdx: i think you still want "dev" to be installed as ubuntu-push-dev-server and "ubuntu-push" to be installed as /usr/lib/ubuntu-push-client/ubuntu-push-client [14:26] err [14:26] Mirv: ^^ [14:27] dobey: the thing is that something is already installed as those two files even after removing the >=, so maybe it's the build environment handling that manually. I'm just debugging by staring at vivid PPA error messages. [14:27] Mirv: that MP of yours is just all wrong :) [14:27] dobey: it's not MP but a hack testing ground [14:27] to get vivid building [14:28] dobey: I was wondering what was wrong with the ">=" syntax and tested making the symlink manually, then noticed I couldn't create symlinks because the files were already there, etc [14:28] i don't understand why => is there at all [14:29] dobey: and source/format is supposed to not be included in train packages so that was needed to be removed too to fix the earlier build failure we got before getting these [14:29] dobey: yes, and apparently the packager is not reachable for comment right now [14:29] the source/format is fine [14:29] dobey: it's not, since it failed to build before removing it due to train failing to create the source package [14:30] https://ci-train.ubuntu.com/job/ubuntu-landing-058-1-build/54/console [14:31] Mirv: but it's impossible to see the output file from /tmp/ in jenkins [14:32] Mirv: that sounds to me like the source/format is a scapegoat :) [14:33] renatu, https://code.launchpad.net/~renatofilho/indicator-datetime/notify-missing-alarm/+merge/292270 is still failing after adding the overlay ppa. However, this project is being built against wily, should it be vivid instead? [14:34] dobey: if you want to delay the release further feel free to uncommit the source/format removal and find the real cause for train not being able to upload packages to the PPA :) [14:34] dobey: sure I'd be interested in knowing what an earth suddenly start the complaints about .bzrignore/.gitignore under a subdir while it just used to work before [14:34] charles, tedg ^^^ [14:34] Mirv: well when did it get added? there have clearly been releases of ubuntu-push before [14:35] fginther, I am not the maintainer of this project, but I believe that charles or tedg cal answer that [14:35] dobey: there's 0 delta between successful March release of ubuntu-push and this that failed today in multiple ways, including train not being able to build a source package and install phase failing on vivid [14:42] Mirv, should I continue with the changes to .install files? Do we know what creates the correctly named binaries? [14:44] jgdx: I'd build them, install the vivid versions and check manually what the ls -l /usr/bin/ubuntu-push is [14:44] jgdx: no idea, it's not the packaging doing anything, it's the ubuntu-push's own build system [14:45] when the packaging comes into the picture the files are already there [14:45] (...nowadays?) [14:45] okay :) [14:46] jgdx: the whole problem set of ubuntu-push you've faced today is... weird. since vivid is stale, nothing changes there and now multiple problems. I could see train having changed mandating the source build issues, but no idea about this last problem. [14:48] Mirv, go/nogo? https://code.launchpad.net/~jonas-drange/ubuntu-push/fix-dot-install/+merge/293538 [14:49] jgdx: the automatic branch already has the format removal, otherwise ok [14:49] and probably it doesn't hurt [14:49] merges cleanly locally, so let's try [14:49] ok [14:50] Mirv, thanks for everything so far. Goes for you too dobey [14:56] Mirv, built on vivid now [14:56] and on xenial, at least for amd64 [14:57] :( [14:58] the .install changes are wrong [15:03] jgdx: maybe it needs to be "debian/tmp/usr/bin/ubuntu-push /usr/lib/ubuntu-push-client/ubuntu-push-client" [15:03] and similarly for the dev thing [15:03] "debian/tmp/dev /usr/bin/ubuntu-push-dev-server" [15:06] dobey, so the binary's going to be installed incorrectly/not at all [15:06] jgdx: incorrectly according to that MP [15:10] confirmed, okay, let's try dropping the => ? === chihchunl is now known as chihchun [15:10] jgdx: that might work, but i'm not entirely sure [15:11] if not, i think you need to prefix each line with debian/tmp/ [15:22] dobey, it moves the binary to the correct folder, but does not rename it [15:24] ah, maybe that's why the => was needed. hmm [15:25] maybe it would be better to mv things in debian/rules instead then. hmm === Trevinho_ is now known as Trevinho [15:47] jgdx, dobey you guys have the push thing under control? [17:15] slangasek, can you disable automated builds of ubuntu-touch/vivid ? Next image will be broken. [17:15] pmcgowan, ^ until we have a fix for ubuntu-push [17:15] indeed [17:15] jibel, no solution yet I guess then [17:16] pmcgowan, there is a solution, but there are still issues with the packaging in vivid [17:16] jibel, ? [17:17] pmcgowan, whne I install the silo I've files installed under /usr/lib/${DEB_HOST_MULTIARCH}/ubuntu-app-launch/push-helper [17:17] it doesn't look right [17:18] this is the whole name of the directory, like a variable substitution didn't happen [17:18] thats odd and seem unrelated to the changes [17:19] pmcgowan, I compared to previous version and it is definitely not there. [17:19] so something changed in the build [17:21] maybe kenvandine can look at it [17:21] odd [17:22] that is a common convention, and should work [17:22] oh... wait is that in the .install file? [17:22] jibel, ^^ [17:23] i guess that's before the .install actually [17:23] something is setting the install path without evaluating the variable [17:24] jibel, got a link to the build? [17:24] this? https://requests.ci-train.ubuntu.com/#/ticket/1343 [17:26] kenvandine, this silo https://requests.ci-train.ubuntu.com/#/silo/058 [17:26] -rw-r--r-- root/root 47 2016-05-02 15:20 ./usr/lib/${DEB_HOST_MULTIARCH}/ubuntu-app-launch/push-helper/exec-tool [17:26] ugh [17:32] jibel: ubuntu-touch/vivid> disabled... though that really shouldn't be necessary? [17:34] jibel: next image will be broken how? [17:34] jibel: it's already broken in the overlay ppa? [17:35] dobey, yes if you update all the packages. dbus flooded with NameOwnerChanged signals [17:36] the device becomes unresponsive, and lot a things start crashing (scopes, unity8, ...) [17:36] slangasek, thanks [17:36] jibel: all signals for the same dbus name? [17:36] dobey, this is bug 1575184 [17:36] bug 1575184 in Ubuntu Push Notifications "ubuntu-push is flooding dbus with NameOwnerChanged signals" [High,In progress] https://launchpad.net/bugs/1575184 [17:37] jibel: so why turning the build on and off instead of just letting it build and be broken? We're not hurting for build capacity, and broken images should be trapped farther down the line because we don't always know in advance they're broken [17:37] oh hmm [17:37] slangasek, it'll also break CI [17:38] and be a major problem for everyone trying to land something [17:38] why does the CI depend on the latest image being good, instead of the CI *blocking* an image that isn't good? [17:38] well the package shouldn't have landed [17:39] right, and we have nothing to block an rc-proposed image [17:39] so i guess the real question is, why did QA not block it? [17:42] exactly, I'll have an answer. [17:44] the other option is to revert nm 1.2 ... [17:49] if your build fails it wont end up in rc-proposed [17:50] (obviously) [17:52] uhm [17:52] oh, nm 1.2 is what broke the world [17:55] err, or gdbus [17:55] is that due to the missing changes in livecd-rootfs ? [17:56] (the dropping of the pkcon and NM hacks) [17:57] not sure what hack you mean, but i don't think so [17:58] appears dbus-glib was happy with lowercase "state" but gdbus (which nm 1.2 uses) isn't [17:58] but that doesn't explain the build issues [18:12] dobey: there are some hacks in livecd-rootfs that put a policykit file in place for NM and also mangle NMs dbus config [18:12] they were supposed to be removed when the new nm lands [18:13] ogra_: ah. that could be related, but if the string case on the property matters here, i guess it won't fix things [18:13] ogra_: since new nm is landed though, perhaps we could first drop those bits and test to see if it helps? [18:14] http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-touch/hooks/45-add-sudo-group-nm.chroot [18:15] hmm, i guess not having those changes won't fix the issue at hand [18:29] ogra_: the property case is relevant [18:29] the integration of gdbus in nm got more strict [18:39] jgdx: do you got the silo setup for the ubuntu-push fix? [18:40] morphis, yeah, but it's not building [18:41] why that? [18:42] dh-exec fails to move a file on vivid [18:43] jgdx: in the silo it looks like it has builded [18:44] morphis, it built when we dropped the dh_exec rename, but we then had binaries in the wrong locations [18:44] with the wrong names [18:44] jgdx: any idea why this all happened? how did you land ubuntu-push before? [18:45] morphis, absolutely no idea and when we landed u-p in march there was nothing to it [18:45] morphis, jgdx it worked when built locally by kenvandine and dobey [18:45] seems something wrong in the overlay? [18:45] pmcgowan, I've built u-p locally in every configuration (vivid-proposed, vivid, xenial, xenial-proposed) without issue [18:45] i've built it on vivid+overlay too [18:45] maybe the train's outta whack [18:46] i'm working on setting up sbuild for vivid-armhf + overlay [18:46] to try it in sbuild [18:46] kenvandine, thx [18:47] jgdx, why did you need to change the install file? [18:47] pmcgowan: no, not the overlay [18:48] dobey, oh sorry whats the theory? [18:48] pmcgowan, to test a theory of Mirv's [18:49] pmcgowan, i don't think we have a theory yet [18:49] pmcgowan: solar flares? [18:49] i'm trying to match the build env of the ppa with sbuild [18:49] to see [18:49] kenvandine, here's the vivid build failure from 2 secs ago: https://launchpadlibrarian.net/257565248/buildlog_ubuntu-vivid-amd64.ubuntu-push_0.68+15.04.20160502.4-0ubuntu1_BUILDING.txt.gz [18:49] cjwatson: ^^ did anything change in launchpad builder configs recently that would screw with dh-exec on vivid silo builds perhaps? [18:49] i haven't seen that failure yet [18:50] cp -a debian/tmp/=> debian/ubuntu-push-client//usr/lib/ubuntu-push-client/ubuntu-push-client/ [18:50] jgdx: you dropped the dotinstall mp? [18:50] dobey, yeah, didn't get anywhere [18:50] jgdx, earlier the package was building in the ppa just installing the helper in the wrong path [18:50] yeah, when i built locally i realized that was unrelated to whatever is going on [18:50] kenvandine, not just the helper, the u-p binary as well [18:51] and since we shouldn't land things direct to trunk there, figured i'd comment and disapprove it :) [18:51] so this isn't right? /usr/lib/ubuntu-push-client/ubuntu-push-client/ubuntu-push [18:51] kenvandine: no [18:51] no, needs to be …/ubuntu-push-client [18:51] ok, i'm not even thinking about that yet [18:51] this is what has me freaking out /usr/lib/${DEB_HOST_MULTIARCH}/ubuntu-app-launch/push-helper/exec-tool [18:52] kenvandine: don't freak out about that [18:52] kenvandine: it's the same issue [18:52] lets hope :) [18:52] ie, a problem with dh-exec [18:52] ./usr/lib/ubuntu-push-client/ubuntu-push-client [18:52] is what i get locally [18:52] so both are good locally [18:52] yes [18:53] but dh-exec with sbuild for arch=armhf [18:53] i think specifically [18:53] no [18:53] it's failing on all archs [18:53] the amd64 build was fine [18:53] no [18:53] in the ppa [18:53] on vivid all arch, Ken [18:53] the amd64 build is the fialure that jgdx just linked :) [18:54] failure [18:54] oh... right [18:54] ignore me :) [18:54] i had downloaded the deb to check earlier [18:54] yeah, that was when the hack MP was also in the silo, and had the wrong paths [18:54] so reading [1] makes me think that the .install file is altered or misinterpreted somehow [1] http://manpages.ubuntu.com/manpages/trusty/man1/dh-exec-install.1.html [18:55] cp -a debian/tmp/=> should really be cp -a debian/temp/ubuntu-push [18:55] s/temp/tmp [18:56] well, and usr/bin/ubuntu-push [18:56] not just ubuntu-push [18:56] right [18:56] the issue is that it seems dh-exec is not being run at all [18:56] but why, i have no idea [18:56] according to the doc, this is dh-exec's internal implementation of => at work [18:57] it uses debian/tmp as a temporary folder to do the rename [18:57] so, we should try to build some deb on vivid that utilizes => [18:57] jgdx: debian/tmp/ is where files are installed to when you have multiple binary packages defined [18:57] hm okay [18:58] jgdx: add "export DH_VERBOSE=1" to debian/rules in a second MP, and rebuild with that, to test. should spew a lot more info in the log [18:59] maybe then we can see what is (or rather, is not) happening [19:00] i'm really off now, can you possibly do it? [19:00] or kenvandine ^? [19:00] kenvandine: ^^ can you do that? [19:02] sure [19:09] dobey, jgdx: building [19:09] i'm busy trying to fix purchasing stuffs :) [19:36] dobey, jgdx: i have a workaround (hack) that i think will fix it [19:36] building in the ppa now [19:36] kenvandine: what hack? [19:37] + mkdir -p debian/tmp/usr/lib/ubuntu-push-client/ [19:37] + mv debian/tmp/usr/bin/ubuntu-push debian/tmp/usr/lib/ubuntu-push-client/ubuntu-push-client [19:37] in debian/rules [19:37] these hacks used to be pretty common back in the day :) [19:37] kenvandine: that doesn't fix the problem though [19:37] i think it does [19:37] that and a change to the .install file [19:37] kenvandine: well, you can drop the => and just list the file, but then you have the ${DEB_HOST_MULTIARCH} issue because dh-exec isn't running [19:38] no, that still runs [19:38] really?! [19:39] just wait 5 minutes for the ppa build :) [19:39] * dobey looks for a bottle of rum and finds a barren shelf [19:39] kenvandine: i doubt it'll work :) [19:39] so little faith [19:40] https://code.launchpad.net/~ken-vandine/ubuntu-push/verbose/+merge/293562 [19:40] one faith is enough. [19:42] dobey, i think it worked... now we need the same fix for ubuntu-push-dev-server [19:42] it got further :) [19:42] well sure it got further [19:42] but i was right :) [19:43] cp -a ./debian/exec-tool debian/ubuntu-push-client//usr/lib/\${DEB_HOST_MULTIARCH}/ubuntu-app-launch/push-helper/ [19:43] let it be known that kenvandine owes me rum [19:44] wtf! [19:44] but it was still using dh-exec [19:45] maybe we should kill dh-exec in here :) [19:47] well it's not using dh-exec, obviously [19:47] but why [19:47] well if golang wasn't insane, we wouldn't need dh-exec there i guess [19:48] that was my next question... why are we using it [19:48] but yeah, either need dh-exec, or scripting in override_dh_install [19:48] all my years of packaging and i've never needed it [19:48] kenvandine: you're used to build syztems that make sense for system integration [19:48] indeed [19:49] golang is the hipster kid sitting on a front porch of an abandoned house in detroit, shouting at pigeons to get off the lawn [19:50] lol === kalikiana_ is now known as kalikiana === FourDollars_ is now known as FourDollars === blr_ is now known as blr [21:25] dobey: basically any time people blame the builders, they're wrong, and it's not a builder change here :) [21:26] cjwatson: wasn't blaming. just trying to figure wtf is going on that would cause a package with no changes to debian/ which built fine 6 weeks ago, to not build fine today [21:26] dobey: the problem is that this source package uses format 1.0, and that source format doesn't preserve the executable bit on files added by the .diff.gz. The two possible fixes are (a) switch to source format 3.0 (quilt) or (b) add chmod +x debian/whatever.install in debian/rules before dh_install is called [21:27] dobey: I bet the previous version of the package came out as 3.0 (quilt), i.e. with a .debian.tar.gz or similar [21:27] oh [21:27] yeah, ok that makes sense [21:27] so it's the removal of debian/source which broke it [21:27] kenvandine, Mirv: ^^ [21:27] it was removed? er, yeah, that would very much do it :) [21:28] that sounds like pointing gun at own foot territory [21:28] yeah, something about "packages in ci train shouldn't do that" [21:28] sigh [21:28] which to me is wrong [21:28] I agree with you; that is a ridiculous policy :) [21:29] perfectly reasonable to use features of 3.0 (quilt), even if you aren't actually using any quilt patches [21:29] but anyway, it's quite late for you, and high time for me to go to the pub :) [21:29] indeed === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ === lan3y is now known as Laney === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [22:56] Allah is doing [22:57] sun is not doing Allah is doing [22:57] moon is not doing Allah is doing [23:00] stars are not doing Allah is doing [23:00] planets are not doing Allah is doing