=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [05:23] anpok: did you get what you needed to the 053? [05:23] anpok: answer seems to be no, so copying. also, reconfiguring the silo the claim all of them are manual uploads, since it used to be dual landing for all and you want to continue doing dual landings (you can't now use the same MP:s for the vivid landing) === ev_ is now known as ev [05:24] anpok: or hmm, maybe that current line in there is good enough, but it was not reconfigured after the line was changed === salem_ is now known as _salem [05:50] michi: hey! you could test on wily too, silo 021 has the same accessibility fix for wily. I think it'd be nice to see how it behaves in the exact thumbnailer scenario. [05:50] Mirv: OK, I’ll have a look. [05:50] Unfortunately, I don’t know how to install the new thumbnailer from a Jenkins build. [05:51] Jenkins devel-ci still builds with the old version number. [05:51] I’ll talk to James about it later today. [05:53] michi: so the build from the silo 10 workarounds the issue ie is not good for testing it? can you give me the jenkins url? I believe if you can download the .deb:s from there and push them to device, you can dpkg -i *.deb them [05:54] michi: I'm not otherwise in a hurry, but I'll be away for two weeks after today so if you want it in, I'd rather do it sooner than later today ;) [05:54] I've already autopilot tested the vivid silo to have no regressions otherwise [05:54] Mirv: No, I added our own work-around for the time being. [05:54] To test whether it’ll work with the new network access manager, I need to build a new thumbnailer with the work-around removed and some extra trace. === chihchun_afk is now known as chihchun [05:55] michi: ok [05:55] But I can’t get the package that Jenkins builds for Arm onto the device right now because of the version going backwards. [05:55] michi: dpkg -i forces even a downgrade [05:56] Cool, I’ll try that, thanks! [05:56] just adb push each .deb to the /home/phablet , then adb shell and dpkg -i *.deb [05:58] you're welcome [06:30] Mirv: yeah I wasnt sure yesterday then ended my day.. [06:30] Mirv: because of gtk+3.0 [06:31] we are on 3.14 on vivd, and 3.16 on wily, I wasnt sure how to configure sync for all the others, but manual upload for gtk+3.14 === chihchun is now known as chihchun_afk [06:44] anpok: I'm actually not 100% sure either how it should be done :) but it's now all "manual" uploads, and the watch_only build is running so hopefully it should soon be ready to test [07:08] Mirv: nice :) [07:33] tsdgeos: you're welcome :) [07:34] anpok: ah, 053 would need qtmir-gles and qtubuntu-gles still.. [07:34] anpok: I can handle those too [07:35] anpok: or, hmm, they are outdated in 053, should they be the same version as wily has in 004? they don't seem to have vivid specific branches? [07:36] anpok: correction, qtubuntu is up-to-date, qtmir in 004 only has your comment change so it does not matter [07:38] anpok: -gles packages building for vivid now, watch https://ci-train.ubuntu.com/job/ubuntu-landing-053-1-build/11/console [07:39] hum [07:41] did people notice that the mir update is blocked in wily-proposed due to boottest regressions? [07:41] https://jenkins.qa.ubuntu.com/job/wily-boottest-mir/lastBuild/console [07:41] the logs don't have much details [07:44] I'm not sure if the boottest is deemed to be trustworthy nowadays or not, but I can rerun it now to see if it persists [07:45] yeah [07:46] the thing is that it failed for all the packages in the set [07:46] e.g [07:46] https://jenkins.qa.ubuntu.com/job/wily-boottest-qtmir/lastBuild/console [07:46] that one has a "ERROR: timed out waiting for Unity greeter" [07:47] anpok: ^ you should probably be interested in that wily mir problem, whether there's a real problem [07:47] anpok: you could probably update to wily-proposed on device to see [07:51] seb128, actually there are lot of boottest failures http://paste.ubuntu.com/11891679/ is anyone looking at the results? [07:52] for exmaple lxc-android-config should be whitelisted, it cannot be installed directly === marcusto_ is now known as marcustomlinson [07:53] seb128, and when tests fail the log are not useful to do any diagnostics, eg. ubunut-system-settings-online-account ... Killed without further info [07:54] like mir [07:57] jibel, yeah, that's what I said "it failed for all the packages in the set" [07:58] that "lot" is just the new mir landing [08:02] Mirv: will have a look [08:24] Mirv, I re-ran all non-mir or qt boottest failures ie. pay-service platform-api thumbnailer trust-store ubuntu-app-launch ubuntu-system-settings-online-accounts [08:24] Mirv, lxc-android-config must be whitelisted, it must be installed from recovery [08:25] Mirv, and the thumbnailer seems to be a real dependency issue in Wily [08:25] jamesh, ^ [08:28] jibel: what do you mean by "a real dependency"? [08:28] jibel: ok [08:28] so the boot test fails because it attempts to upgrade lxc? [08:28] real dependency issue. Sorry [08:29] if this is libleveldb1, won't that be fixed when the next image gets rolled? [08:29] jibel: btw pay-service ubuntu-app-launch ubuntu-system-settings-online-accounts are all part of the mir update. [08:29] jamesh, in the log of https://jenkins.qa.ubuntu.com/job/wily-boottest-thumbnailer/lastBuild/ there is this error at the end [08:29] The following packages have unmet dependencies: [08:29] thumbnailer-service : Conflicts: libthumbnailer0 but 1.3+15.04.20150312-0ubuntu1 is to be installed [08:29] anpok, ok [08:30] jibel: we shouldn't have any libthumbnailer0 now. That package was removed [08:31] Mirv: just read the logs above.. thanks for cleaning up my mess. [08:31] anpok: yes, the 053 seems to be intact for testing now. you're welcome. [08:31] jibel: I believe the conflicts/replaces headers are correct (I applied the fixes infinity gave me) [08:31] oh, I noticed only now that sil2100 had cancelled the hangou [08:31] t [08:31] is there a way to manually upgrade without touching lxc-android-config? [08:32] Mirv: yeah, not much to discuss [08:32] anpok: what I do usually is just to dist-upgrade, then when it fails run sudo dpkg --configure -a [08:36] hmpf [08:37] none of the buttons in my indicators work on arale ... [08:37] (i.e. tapping on battery settings in the indicator doesnt open anything) [08:37] is anyone else seeing that ? [08:38] * ogra_ is on r52 on rc-proposed [08:38] err [08:38] r62 [08:38] updated 1h ago [08:38] ogra_, it works on r62 [08:38] hmpf [08:39] i wonder whats wrong with my device then [08:39] they all work [08:40] Mirv: so it boots here after dist-upgrading.. so this was really just thumbnailer and lxc? [08:41] * ogra_ reboots, my spread also only shows shadows instead of app screenshots again [08:45] jibel: I'm still not sure what that build log is trying to do. [08:45] anpok: well if you're dist-upgrading after flashing today morning's image, there's only so much new there is [08:46] Mirv, can you help on the thumbnailer boottest failure, I am not sure either how boottest installs packages. [08:49] cihelp ^ [08:49] jibel: let me take a look [08:58] sil2100, seems i386 failed to build for the last vivid image build [09:07] * sil2100 checks the logs [09:09] hm, dep issues, unity8 couldn't be installed [09:19] jibel: I don't find anything that would depend on the libthumbnailer0 with the new packages [09:23] but maybe psivaa can find something more out [09:23] still digging, all devices being occupied does not help speed up :) [09:30] ogra_, how do you reproduce the "shadow effect"? I never saw it [09:30] jibel, i simply use the device [09:31] it starts happening after a few hours ... and gets worse over time [09:31] ogra_, me too :) any specific use of the device? [09:31] hm [09:32] jibel, no, i have my usual 5 apps open, nothing fancy [09:32] seems it is worse if the browser is open alongside === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [09:44] Oh [10:01] jibel: Mirv: i don't think we could make libthumbnailer0 work with boottest as it's currently setup, [10:02] this is due to the fact that its ubuntu-touch/devel-proposed/krillin.en vivid being the base image where the boottests are run [10:03] and the fact that we're trying to install wily version of thumbnailer-service as part of the testrun, which conflicts with libthumbnailer0 [10:03] http://paste.ubuntu.com/11892053/ [10:04] So, thumbnailer(wily) -> installs thumbnailer-service(wily) on vivid base which already has thumbnailer0, which is conflicting [10:05] s/thubnailer0/libthumbnailer0 [10:07] psivaa: thumbnailer-service should be replacing everything we had in libthumbnailer0, and there are no further dependencies [10:07] further dependencies on that package [10:11] Mirv: interesting... I'm looking into the reason why our last i386 image didn't build correctly [10:11] psivaa: if the test is actively trying to install libthumbnailer0, then that sounds like a problem with the test. [10:13] Mirv: and this might also be related to the thumbnailer landing, but hm, the error is a bit strange [10:14] Mirv: the shlibs:Depends on thumbnailer generated something really strange [10:15] Mirv: qtdeclarative5-ubuntu-thumbnailer0.1 has such a dep currently: libqt5quick5 (>= 5.4.1-1ubuntu7) | libqt5quick5-gles (>= 5.4.1-1ubuntu7) <- first, not sure why shlibs is suddenly depping on the exact version number, and why did it mark requiring 5.4.1-1ubuntu7 for -gles if gles is currently one rev behind (5.4.1-1ubuntu6) [10:18] 5.4.1-1ubuntu7 does not and never existed for the -gles version [10:25] sil2100: eh.. [10:26] sil2100: is the i386 image an emulator image? that could mean that we should not allow the versions to go out of sync, since the .symbols file might declare the dependency like that [10:26] Ah... right, yeah [10:26] sil2100: oh, oh... this is the first time ever this is happening, and the reason is that in ubuntu7 we added backported feature from Qt 5.6 which the new thumbnailer is using [10:26] I thought we generally avioided depping on particular -0ubuntu versions [10:27] sil2100: this is packaging automagically doing the correct thing... well, almost, the gles should not be like that [10:27] Ok, that explains it [10:27] sil2100: so I think we need to do no-op gles build bumping the version nuumber [10:27] sil2100: siloing [10:27] Mirv: yes, certainly [10:27] Thanks :) [10:27] Generally I hate depping on ubuntu versions, but in the case of Qt well... I guess there's nothing better one can do [10:30] sil2100: heya [10:30] cwayne: hey! [10:30] sil2100: that's not happening in general - but here it is since ubuntu7 version specifically added new symbols that thumbnailer is now using [10:31] sil2100: any idea whats going on with importing images? the last arale custom tar that was built still hasn't shown up in meizu.en-proposed [10:31] cwayne: oh? Still? Let me check the config and the s-i server [10:31] One moment [10:32] sil2100: generally packages don't add new features in ubuntuX versions :) [10:36] Mirv: yeah, that's what I expected and scratched my head about ;) [10:37] But yeah, this is a special case [10:45] hmmm [10:45] Ah! [10:45] I see a typo in the config [10:45] cwayne: ^ [10:46] huh, how did it ever work then i wonder [10:46] cwayne: not sure, it shouldn't have worked in the past, not for meizu.en-proposed [10:48] lol [10:49] Strange that the jenkins job urls are different there [10:49] cwayne: anyway fixed now [10:49] Let's wait for another importer run [10:54] sil2100: ^ 008 built, is it possible to test it with the image similar to how you debugged it [10:55] Mirv: I can try, I debugged it on my chroot, still have it open [10:55] I'll just add your PPA to sources [10:55] sil2100: hmm, the publisher didn't yet run though. build finished 6 minutes ago so 4-9 to go. [10:55] sil2100: thanks [10:56] Ok, I'll prepare everything in the meantime [10:58] sil2100: ok now it should be done [11:03] uh [11:03] Mirv: still a problem [11:03] Mirv: it needs to be 5.4.1-1ubuntu7 not 5.4.1-0ubuntu7 [11:04] It looks like the non-gles version was a debian -1, so the -gles one needs that too [11:04] So, not -0ubuntu7 but -1ubuntu7 (didn't notice that originally) [11:08] jamesh: The test does try to install libthumbnailer0, qtdeclarative5-ubuntu-thumbnailer0.1, thumbnailer-common and thumbnailer-service [11:08] jamesh: this is because libthumbnailer0 is already an installed package due to the base image being vivid [11:09] jamesh: please take a look at lines 155,162 and 163 in http://bazaar.launchpad.net/~canonical-ci-engineering/ubuntu-touch-boottest/trunk/view/head:/boottest.sh [11:18] Mirv: regarding silo 006 - we need to make sure it's also released to wily [11:20] sil2100: ouch... so I must lie about the package being in Debian while it isn't [11:20] :< [11:20] ok then [11:23] psivaa: so that test has no chance of ever succeeding if we ever merge two binary packages (like we did for thumbnailer) [11:24] jamesh: right, with this way we wont have thumbnailer passing :/ [11:37] Mirv: jibel: not sure if you noticed, the majority of the boottest failures (other than thumbnaier) are due to ''ERROR: timed out waiting for Unity greeter' [11:38] one possible cause as pitti suspected could be the new Mir [11:39] psivaa: I understood anpok tried testing it already (or well, at least he did test the silo that landed last night) [11:40] psivaa: I took todays devel-proposed image and upgrade to wily-proposed [11:40] *upgraded [11:40] boots fine [11:42] anpok: is this the base image that you used, just to confirm, http://paste.ubuntu.com/11892361/ [11:43] i used mako version 258 [11:44] version_detail: ubuntu=20150717,device=20150708,custom=20150717,version=258 [11:47] psivaa: ok comparing to boottest - I bootstrapped but then just I dist-upgraded [11:47] & updated.. [11:48] Mirv: testing! [11:48] sil2100: ok, try again, silo is ready [11:48] sil2100: heh [11:48] good timing [11:48] ping trainguards -- I wanted to make you aware that last thumbnailer changes have broken Telegram, and the app will not start in rc-proposed [11:48] I've contacted #unity-api team [11:48] We dynamically link with libthumbnailer.so, which seems to be gone from the system [11:49] jamesh: ^ [11:49] http://paste.ubuntu.com/11892354/ [11:49] Mirv: works! [11:49] sil2100: \o/ [11:49] yes, I've pinged jamesh about it [11:49] sil2100: publishing [11:49] waiting for his response [11:50] anpok: ack, but i'd do a test on krillin to confirm, the fact that mako successfully booting does not confirm that it will boot with krillin [11:50] psivaa: yup switching devices now.. [11:51] sil2100: Hi. In silo 7, dashboard says "caught signal 15, aborting". What does it mean? [11:52] rvr: it means I cancelled the build [11:52] greyback: So, is it ready for testing or not? [11:52] rvr: sadly no, I need to rebuild it and test it once mir in silo 4 lands [11:53] greyback: uh, remember that cancelling a job before it finished preparing the packages is VERY risky [11:53] By risky I mean in certain cases it can lead to the silo being broken [11:53] Only abort when packages are prepared [11:54] greyback: Ok, removing the trello card [11:54] sil2100: it was a pretty quick cancel === tvoss is now known as tvoss|test [11:54] *sigh* that has been sitting there for days === tvoss|test is now known as tovss === tovss is now known as tvoss [11:55] sil2100: but noted, I shall avoid doing so in future [12:02] hum [12:02] Mirv, jibel, so that mir update/boottest regression, I think it's real [12:02] I tried to install the new mir here on my n7 which is on wily [12:03] and it has the ubuntu log with 4 dots splash (new, looks nice!) but unity8 never shows and apport triggers on boot for unity8-dash [12:05] anpok, ^ [12:06] yes seeing that.. do we have startup logs from unity8-dash/ [12:06] seb128, good that boottest caught it. Thanks for the verification. [12:06] yw! [12:06] also the mir transition is incomplete [12:07] url-dispatcher : Depends: libmirclient8 (>= 0.13.2+15.10.20150605) but it is not going to be installed [12:08] ubuntu-push-client as well [12:09] ciborium === psivaa is now known as psivaa-lunch [12:52] trainguards: I just added another branch (same project) to my spreadsheet item. Do I need to do anything else to get that new branch into my silo? [12:55] kyrofa: the silo needs to be reconfigured to include it [12:56] kyrofa: since I'm not sure if you can do it, I just reconfigured it for you. now it should work/build fine. === tedg is now known as ted [12:57] seb128: there was an update to gtk-3.0 - in the mean time - do we have to upload a new source package to silo-004? [12:57] Okay, thanks Mirv! [12:57] anpok, no, the silo landed in wily-proposed it's not needed anymore, right? [13:00] seb128: ah ok so gtk+3.0 3.16.5.-1ubuntu2 was built again libmirclient9 and contains the deprecation free mir platform patches [13:00] +? [13:01] seb128: silo-004 now has url-dispatcher [13:01] anpok, updating the silo doesn't make sense since it landed to distro already, no? [13:01] anpok, and yes, the gtk upload was to fix an issue with the silo version [13:04] seb128: the silo can be republished to fix proposed migrations, since it's only emptied if the migration succeeds [13:04] seb128: just thought we need a rebuilt url-dispatcher package to resolve the problem.. [13:04] but in this case one might to fix archives manually since the fixes are also manual uploads to the silo [13:04] Mirv, wouldn't it be more efficient to just upload the extra rebuild directly to the archive? [13:04] seb128: yes, exactly [13:05] but if they are built in the silo, one can also copy-package those to the archives [13:05] (and there is silo-053 which needs it too) === _salem is now known as salem_ === ted is now known as tedg [13:30] sil2100: heh you were right, I screwed up silo7 by cancelling a build. Do I need to clean & start again? [13:31] greyback: might be the easiest way, if that's not a problem for you [13:33] sil2100: looks like nothing is easy https://ci-train.ubuntu.com/job/ubuntu-landing-007-3-merge-clean/42/console [13:33] Yeah, that's normal... it's freed now, this is normal when the config file got erased/corrupted [13:33] Re-assign and it should be good [13:34] sil2100: cool, ta === psivaa-lunch is now known as psivaa [13:48] can silo 2 be marked as passed [13:48] trainguards: dh-exec .install files aren't getting multiarch variables in my silo, but it works in my local pbuilder. What's wrong? [13:48] pmcgowan: did QA sign it off? [13:48] they did [13:48] acc to trello yesterday [13:49] hm, someone forgot to switch it then [13:49] jibel, davmor2: setting the silo as passed [13:59] sil2100: anyone in qa available to help test the latest arale custom + silo 35? [13:59] i broke my arale at the worst possible time :( [14:00] jibel, davmor2: ^ do you have anyone that could help? ^ [14:02] jibel: I can take it [14:03] jibel: that way cwayne only owes one person drinks for the rest of their lives ;) [14:03] :) [14:05] davmor2: so, the steps to test: 1) install rc rev 2 on arale [14:05] 2) favorite/unfavorite some scopes [14:05] 3) switch channel to ubuntu-touch/rc-proposed/meizu.en-proposed [14:05] 4) install ubuntu-touch-customization-hooks from silo 35 [14:06] cwayne: sure on it [14:06] davmor2: <3 [14:07] cwayne: that's fine I never have to buy a drink again eva ;) [14:07] davmor2: that is correct [14:07] although penk will owe those to me since this isn't my tarball anymore :P [14:08] cwayne: who requested the testing, Didn't see penk nick there once :P [14:08] davmor2: lol [14:10] sil2100, silo 6 can publish [14:10] pmcgowan: I know, need to discuss that first [14:10] pmcgowan: it's a direct upload to vivid, need to make sure those changes are staged for wily too [14:10] It was a request from slangasek and awe_ mentioned he can start doing that post-OTA-5 [14:11] sil2100, ok [14:11] Will publish once I have the situation cleared out [14:12] sil2100, I don't really see the context in the scrollback? [14:13] awe_, silo 6 is network manager change [14:14] but its vivid only? [14:14] awe_: you weren't around when it got ready for publish - waiting for Steve's comment on if I can simply push it normally to vivid [14:14] because (a) we forked NM due to the desktop routing change which I didn't want to accept [14:15] Since there's no silo/request with the same change in wily [14:15] and (b) I focused on getting everything landed for the phone first [14:15] pmcgowan, sil2100 and I discussed this. I'm currently working on landing all of the changes in wily now [14:15] as separate landings [14:15] * awe_ is editing .patch files as we speak [14:16] awe_: ok, so you want this to still go in and then you'll land it with all the others for wily, right? [14:16] yes [14:16] but go into the overlay PPA [14:16] not vivid itself [14:16] did I get the citrain fields wrong? [14:17] awe_: I suppose it's fine, remember our kind request to at least get the silo for wily with each vivid-overlay landing once you sync it up [14:17] The release team doesn't like when we land things in overlay first, it introduces the risk of the delta between devel and stable [14:18] sil2100, I don't like shipping phones with unstable code [14:18] I put my efforts on supporting devices we'd shipped, and explained myself in depth [14:19] this should have zero impact on desktop [14:20] Right, and we're thankful for that, but we need to make sure that everything that lands to the stable devices also lands to the devel ones [14:21] Otherwise, once we finally switch sometime in the future to the new series, we don't miss any fixes - and this already happened the last time for multiple projects [14:21] So the release team is really cautious here [14:25] trainguards: I'm having some trouble in silo 11. My dh-exec .install files aren't getting $DEB_HOST_MULTIARCH defined... and I'm not sure why. It works locally [14:26] awe_: did cyphermox take a look at those changes? Asking since this would mean it's already been reviewed from the packaging POV [14:26] kyrofa: hm, let me take a look if it's something we can help with [14:27] sil2100, thanks. I can do it in override_dh_auto_install, but the debian wiki suggested dh-exec (https://wiki.debian.org/Multiarch/Implementation#Dynamic_debian.2F.2A_files) [14:28] sil2100, it was approved by abeato_ only [14:30] sil2100, as for the packaging, as NM is a packaging only branch, that's all I modified. I added a new patch, and corresponding changelog entries [14:30] awe_: yeah, thinking how to proceed with that, last time I just published it as it's nothing more than like publishing a code-only-change, but... [14:30] Our agreement with the release team is strange [14:31] Ok, I'll take it on me then [14:32] sil2100, what should I have done differently? [14:32] awe_: everything fine from your side, although I would prefer cyphermox to be aware of the changes, it was more of if I should find a core-dev to approve it first or not... [14:32] if I always get a core-dev to review, would that smooth this out next time? That seems odd, given that I'm landing in the overlay PPA, but if that's the requirement, so be it [14:57] cwayne: should that of fixed the issues with only seeing 6 icons if so fail, Does it need to be installed during the install of the upgrade? [14:58] oh shit i think i forgot to rebuild the package with scott's latest fix [15:00] sorry davmor2, ill ping you once i get it rebuilt [15:15] sil2100, have you had a change to take a look at the dh-exec stuff in silo 11 yet? [15:16] kyrofa: looking, but in a meeting still so it's hard to concentrate [15:17] But I see what you mean [15:17] sil2100, heh, no problem :) [15:18] sil2100, it's not some sort of security thing, is it? Since the .install files are executable? [15:30] robru: so, anpok (who's missing from irc atm) updated silo4 due to getting stuck in proposed....has now seemed to correct the silo, can you attempt to pub again? [15:30] camako: ^ [15:31] mzanetti: ping [15:35] hi victor [15:35] rvr, ^ [15:36] mzanetti: Hey [15:36] mzanetti: I'm testing silo 48 [15:36] mzanetti: I have a problem with the "start" gesture/Launcher button [15:37] hmm [15:37] what issue= [15:37] ? [15:37] mzanetti: Without the silo, when I'm on the news scope, pressing the "start" makes the Dash go back to the first scope [15:37] e.g. Today [15:37] mzanetti: With the silo, doesn't do anything [15:38] I did think there's something weird when I tested it... but tsdgeos convinced me it was good as it is :) [15:38] let me verify [15:38] rvr: mzanetti: ok that's bad and should not have regressed [15:38] indeed [15:39] it seems to behave differently [15:39] yeah... bug... I guess that means failing the silo :/ [15:39] Yup [15:39] meh :/ [15:39] sorry rvr [15:39] throw away that branch [15:39] and create unittest [15:40] karni: is there a bug for broken telegram / thumbnailer wencan point people to? [15:40] yes, 1 sec [15:41] popey: https://bugs.launchpad.net/libqtelegram/+bug/1475691 [15:41] Ubuntu bug 1475691 in libqtelegram "Telegram broken, old thumbnailer library discarded" [Critical,Triaged] [15:41] rvr, I'll drop that branch from the silo and rebuild the rest as it is, ok? [15:41] mzanetti: Ok [15:44] karni: thanks [15:51] cwayne: relocating to the caravan back in 40 minutes-ish [15:54] davmor2, ack [16:07] kyrofa: hm, I wouldn't do it in this way for sure [16:09] sil2100, how come? [16:13] One moment [16:17] kyrofa: so generally the recommended way is to make the build system take care of building/installing the binaries in the right multiarch directory and then just ask packaging to install them to their respective ones in the system [16:19] sil2100, dh-golang doesn't do that. The go idioms have no way to do that. I have to do it by hand, one way or another [16:19] kyrofa: ouch, ok, this changes the situation - ok, we can do it differently [16:20] Sadly I'm a bit overloaded with work right now [16:20] sil2100, I can add a Makefile rule to copy binaries around, but that's really the same thing [16:20] Could you try poking some core-devs for advice here? [16:20] davmor2, so package should be ready whenever youre back [16:20] sil2100, I'd be happy to-- any recommendations? [16:22] kyrofa: I would say poking slangasek, ogra_, seb128 or infinity - not sure which one of them would have some free cycles :) [16:22] sil2100, alright, thanks! [16:32] sil2100, kyrofa: I would not expect there to be any multiarch directories that are relevant to golang. this is silo 11? [16:33] * sil2100 has no experience with golang [16:33] slangasek, indeed it is. I'm just trying to place a unity scope in the right multiarch place [16:34] slangasek, but the go tools don't support installing anywhere other than $GOPATH/bin, and dh-golang straight-up copies binaries to /usr/bin, so I wrote .install files to move them to the right spot [16:36] kyrofa: what's the right multiarch place, in this context? [16:37] slangasek, /usr/lib/${DEB_HOST_MULTIARCH}/unity-scopes [16:37] ok [16:38] so I think it's fine to use dh-exec for this, and move the file from /usr/bin to /usr/lib/${DEB_HOST_MULTIARCH}/unity-scopes in the .install [16:38] slangasek, it works fine on my local pbuilder, but in the silo it creates a directory named literally "${DEB_HOST_MULTIARCH}" [16:39] ah [16:39] kyrofa: is the executable bit of the .install file represented in your branch? [16:39] or is this a source upload? [16:41] slangasek, indeed it is represented [16:41] slangasek, I was wondering if it was some kind of protection in the silo that disallowed execution [16:42] not "protection", just "bug" [16:42] slangasek, if you're curious: lp:~kyrofa/unity-scope-snappy/improve_debs [16:42] slangasek, heh :) [16:43] slangasek, so I can obviously do this in debian/rules, just not nearly as slickly [16:43] kyrofa: actually, the problem is that the package doesn't declare itself to be source format 3.0 [16:43] so there's no way to represent this executable bit on a round trip into a .dsc and back [16:44] slangasek, hmm. I was specifically asked to remove that :P [16:44] by whom? :) [16:45] kyrofa: you'll want to create debian/source/format with contents '3.0 (quilt)', build a source package, unpack it again, and test the build - that should let you verify that the source package is being generated correctly [16:46] slangasek, robru asked me to drop debian/source entirely [16:47] kyrofa: ok; robru is mistaken on this :) [16:47] slangasek, okay, initially I had 3.0 (native) with a version number of 0.1.0 (no -0ubuntu1). I should do quilt instead? [16:48] kyrofa: ah - yes, 3.0 (native) is wrong because this isn't a native package (native == no separate upstream and Ubuntu parts) [16:48] kyrofa: 3.0 (quilt) is the right thing here [16:49] slangasek, alright. I'm a bit confused by that though. This is a Canonical project, for Ubuntu Personal. Can you explain how the upstream and Ubuntu parts are separate in this case? [16:50] no but I can handwave furiously [16:50] slangasek, (I'm not a packaging pro, as you may have gathered :) [16:51] kyrofa: the fact is, we use non-native version numbers for all of these packages, and the train autogenerates the upstream tarballs; so they're non-native packages in that sense, and also in the sense that any Ubuntu developer can upload a -0ubuntu2 revision to the archive using the same tarball [16:51] slangasek, ohhhh [16:51] slangasek, okay, I've gotcha :) [16:51] so we just want to be consistent with that, even if the distinction between native and non-native is somewhat arbitrary [16:52] slangasek, fixing now! [16:52] slangasek, thank you very much [16:53] kyrofa: no prob [17:00] slangasek, in order to test that out locally then, I'll need to create an upstream tarball? [17:01] kyrofa: you should be able to download the existing one from the ppa [17:01]