=== chihchun_afk is now known as chihchun [00:41] PR snapcraft#1765 opened: store: refactor acquirement of attenuated macaroon [05:17] PR snapd#4307 opened: Fix for issues when snad service is canceled and cleanup for snaps [06:02] morning [07:01] good morning [07:18] zyga-ubuntu: hey [07:19] zyga-ubuntu: how's your daughter? better? [07:22] mborzecki: yeah, she's better but will stay one more day at home [07:23] mborzecki: but hopefully I won't have to spend most of my time next to her as she will not (hopefully) stay in bed all day [07:40] PR snapd#4308 opened: packaging/arch: install snap-mgmt tool [07:54] mborzecki: reviewed [07:54] thanks [08:20] pstolowski: hey [08:21] zyga-ubuntu, morning! [08:21] pstolowski: I looked at 4303 and it seems to be really failing [08:29] zyga-ubuntu, indeed, thanks for heads up, will check === __chip__ is now known as Chipaca [09:25] moin moin [09:27] Chipaca: hello [09:27] hey Chipaca, good morning and good morning to pedronis [09:27] pedronis: mvo: hiya :-) [09:28] what's on fire? [09:28] Chipaca: surprisingly little this morning [09:28] Chipaca: the 2.30 branching is immanent but thats hardly a fire :) [09:29] mvo: unless you mean 2.30 branching pervades the universe, i think you mean it's imminent [09:29] mvo: we still have some PRs open for 2.30 right? [09:30] snapd is imanent \o/ nothing more for us to do [09:30] immanent* [09:30] silly english [09:31] s/IOT/immanent computing/ [09:31] Chipaca: haha, indeed, sorry. ENEEDMORETEA [09:31] pedronis: yes, we are still waiting for those [09:36] Chipaca: hey [09:39] zyga-ubuntu: hiya :) [09:45] can anyone see what went wrong in the spread run of #4299? It seems to have just stopped mid-dance [09:45] PR #4299: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") [09:46] Chipaca: yeah, confusing [09:50] mvo: #1734845 sounds like fun [09:50] Bug #1734845: hook (core) configure → exit status 1 cannot create lock directory /run/snapd/lock → Permission denied [09:51] pedronis, where does the firstboot key generation exactly live again ? could you point mvo to it in 4304 ? [09:52] overlord/devicestate/crypto.go using ssh-keygen [09:53] nothing to do with gnupg [09:55] eek ... damn [09:55] mvo, sorry for the noise ... [09:56] i thought we also generate gpg keys there [09:58] so we need openssh-client [09:58] yeah [09:59] but 4304 is about dropping gnupg only ... so thats fine [10:00] that's used only for snap *-key commands [10:00] and the corresponding snapcraft ones [10:00] yeah [10:01] ogra_: no worries, that was my understanding that we don't need it but it does not hurt to double check [10:01] true indeed [10:10] oooh, bug [10:17] pedronis: I like the idea of making Init more Mock-like more and more [10:17] pedronis: would a bare Mock be alright? [10:17] taking nothing? [10:17] pedronis: taking nothing, but returning a restorer func [10:18] pedronis: otherwise every test that calls this would leave the system in a weird state after [10:18] ah [10:18] then yes [10:18] you probably want a function that does the init bit alone though [10:18] to call from init() [10:18] or viceversa [10:18] i could call init by hand from the mock :-) [10:21] zyga-ubuntu: if you have a bunch of distros hanging around, could you do a login.defs zoo? [10:23] Chipaca: haha, sure [10:23] Chipaca: I never looked at that file [10:23] zyga-ubuntu: also: man subuid [10:23] Chipaca: what's interesting about it? [10:24] zyga-ubuntu: for osutil/user, SYS_UID_MAX [10:26] i didn't know about subordinate uids [10:35] Chipaca: I don't think you can call init functions, they are special [10:35] you can have many of them, but not call them [10:35] pedronis: I'll call it innit then [10:35] :-) [11:01] zyga-ubuntu: I don't need the login.defs zoo, fwiw -- i'm reading the file directly [11:07] brb [11:08] PR snapd#4309 opened: snap: fix TestDirAndFileMethods() test to work with gccgo [11:11] mvo: that's weird [11:20] mvo: do we need more special casing now that we are removing configure-snapd to make it so, that snap set core works also before there's core at all ? [11:30] zyga-ubuntu: yes it is - gccgo [11:30] pedronis: maybe, I need to look [11:31] mvo: we do [11:35] pedronis: thank you [12:04] mvo: is not easy to have no core snap in a spread test, right? unless it has its own prepare sequence? [12:04] pedronis: I think so, though some tests just purge snapd [12:04] ah [12:05] pedronis: I'd like to fix some things and change the prepare/restore code so that each test automatically installs snapd and starts from a clean slate otherwise [12:05] pedronis: (the fixes would involve making that operation very cheap) [12:05] pedronis: IMO the prepare/restore code is a bit complex today and optimizes for time rather than clarity while we can have both [12:09] anyway I just need some expedient for today, and now I see indeed some tests start purging snapd [12:17] pedronis: yeah, purging is probably the easiest, or just rm -f /var/lib/snapd/state.json if you need to simulate an empty state === chihchun is now known as chihchun_afk [12:38] there is a source code repository (plugin: qmake) that does not implement "make install". How would I pick up the executable in order to move it in the snap? [12:43] sergiusens: hey, is 'SNAPCRAFT_BUILD_INFO=1 snapcraft cleanbuild' supposd to work? (ie, SNAPCRAFT_BUILD_INFO with cleanbuild) [12:44] PR snapcraft#1766 opened: Enhanced fake store to detect that metadata can't be pushed prior to pushing the binary, and fixed the test [12:44] sergiusens: I have 2.34+17.10 and I don't see a build artifact [12:44] (maybe I am looking in the wrong place?) [12:45] jdstrand it is inside the snap, under the `snap` directory [12:47] sergiusens: yeah. that is where I looked [12:47] not there [12:47] jdstrand: hey, [12:47] hey zyga-ubuntu :) [12:47] jdstrand: do you have some time, I made updates to https://github.com/snapcore/snapd/pull/4224 [12:47] PR #4224: cmd/snap-update-ns: teach update logic to handle synthetic changes [12:47] jdstrand: just comment changes + one function rename [12:48] jdstrand: there's also one other PR that waits for your review: https://github.com/snapcore/snapd/pull/4140 a new interface [12:48] PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service [12:48] jdstrand: and lastly you have some feedback on https://github.com/snapcore/snapd/pull/4100 that looks like low hanging fruit, maybe something I can help with? [12:48] PR #4100: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces [12:48] zyga-ubuntu: all are on my list for this week (I mentioned this yesterday) [12:49] zyga-ubuntu: 4224 is for today [12:49] zyga-ubuntu: 4140 requires some investigating from me. 4100 I need to think through a little bit more [12:50] jdstrand: thank you on all counts :) [12:50] PR snapcraft#1763 closed: Make the pip filtering in the Python plugin more fine-grained [12:50] jdstrand: I'm preparing follow-up for layouts, I'd like to finally finish that and I think we are really close now [12:56] sergiusens: 06:47 < jdstrand> not there [12:56] sergiusens: wait, what snap directory? snap/ during the build or in meta/ of the snap? [12:57] zyga-ubuntu: nice === alan_g is now known as alan_g|lunch [13:00] sergiusens: I have a toplevel snapcraft.yaml. let me put it in snap/ [13:04] oh [13:04] standup [13:04] joining [13:05] sergiusens: ok, I moved snapcraft.yaml to snap/snapcraft.yaml, then ran 'SNAPCRAFT_BUILD_INFO=1 snapcraft cleanbuild'. I now have a snap/ directory in the snap, but no manifest [13:08] jdstrand oh, with cleanbuild you need 2.35, the env var wasn't being passed in before [13:08] jdstrand `snap install snapcraft --classic` :-) [13:09] hmmm, if I do that I need to remember what you said to do about lxd and networking [13:36] sergiusens: yes, that worked. thanks [13:40] cjwatson btw, mind if we work on switching snapcraft to use the snap for lp buidlers? [13:40] sergiusens: I don't mind, but how were you planning to go about it? [13:40] it's a bit involved [13:41] cjwatson oh, then step one would be to get an idea of how involved it is :-) [13:42] I had the impression it would be more about testing that s/apt install snapcraft/snap install snapcraft --classic/ was working as expected on staging [13:43] sergiusens: we need to make it be a switch, not just change it in the code (which is harder to roll back, harder to experiment with on particular snaps, etc.); and probably as part of the same chunk of work we need to add channel control [13:43] sergiusens: which means it needs to be propagated down from the LP buildd-manager, and probably needs data model changes [13:47] cjwatson up to LP or even build.snapcraft.io ? [13:48] I'll write up the proposed set of steps on the forum [13:53] sergiusens: not build.snapcraft.io IMO. We can flip the switch eventually but it needs to be controlled [13:56] sergiusens: IMO the steps are: (1) design data model in LP (possibly taking into account where core is installed from too, at least for the future?) (2) add option to snap build type in launchpad-buildd to cause it to install snapcraft as a snap (3) LP database migration to add whatever new columns we need (4) implement new data model and API changes in LP, and adjust the build args sent to ... [13:56] ... builders (5) possible UI changes [13:57] sergiusens: ordering is important because builders, DB migrations, LP code are all deployed independently so we need to ensure the right kind of compatibility [13:58] cachio: Spread-24 is now a brand new machine [13:58] cachio: Let me know how it goes please [13:58] niemeyer, great, thanks [13:59] niemeyer, I'll put an eye on it === alan_g|lunch is now known as alan_g [14:13] PR snapd#4310 opened: many: allow to configure core before is installed [14:14] mvo: ^ it has conflicts though, what stops merging your PR ? [14:14] zyga-ubuntu: I've not looked at this at all, but fyi https://bugs.launchpad.net/bugs/1734845 [14:14] Bug #1734845: hook (core) configure → exit status 1 cannot create lock directory /run/snapd/lock → Permission denied [14:15] jdstrand: ack [14:15] mvo: your PR is red [14:15] jdstrand: I looked at this when initially made aware of this about a week ago, my best theory is this is in a privileged container without apparmor stacking [14:17] zyga-ubuntu: like I said, I don't know, but there are quite a few issues on errors.u.c: https://errors.ubuntu.com/problem/cf07c2fa3f39a98f0b52aaf20ff82faab7969129 [14:20] zyga-ubuntu: 515 instances in the last week: https://errors.ubuntu.com/?period=week [14:21] pedronis: yes, timeout [14:22] pedronis: interestingly in snap set core prxy.store=fake [14:22] real bug? [14:23] pedronis: maybe but it looks a bit random [14:23] it's never been green afaict [14:23] pedronis: :/ [14:25] pedronis: I debug once I have the nvidia done [14:25] pedronis: if its real it might be some race, I wonder if something with the state lock, that would explain why it times out, but I don't think there is anything racy in there [14:25] mvo: probably something wrong with the lock [14:26] that's my guess as well [14:26] (that we don't see in the unit tests) [14:27] PR snapd#4311 opened: debian: ensure /var/lib/snapd/lib/vulkan is available [14:30] mvo: I see corecfg.Run expects to run without the lock, but the new code in hookmgr locks [14:31] pedronis: heh, that would explain it [14:31] I think we need to think a bit who should be responsible for what [14:34] mvo: we probably shouldn't lock around the hijack, and make it it's problem [14:38] mvo: I need to take my walk break, but I can look in to this afterward [14:38] jdstrand: FYI, after "plan writable mimic" branch lands I'd like to propose this: https://github.com/zyga/snapd/commit/9b4507bdbfd22f858808924fa45c633209d290c1 [14:39] jdstrand: I think it fits into the discussion and I'm just letting you know in case you need context for the other review [14:39] pedronis: sounds good, lets sync when you are back, I'm fighting apparmor right now [14:39] jdstrand: this patch does the execution of the plan and creation of the undo changes [14:45] * zyga-ubuntu jumpst onto the user mount namespace topic [14:48] mvo: is that the include issue or something else? [14:53] PR snapd#4312 opened: snap-confine: create mount target for lib32,vulkan on demand [14:53] jdstrand: I was refering to the include issue earlier, but I think its a non-issue now, we fixed it by using #include now instead of "include" [14:53] jdstrand: well, when I say "we" I mean zyga-ubuntu [14:54] Hi guys, I'm looking forward to more +1 in this alias request: https://forum.snapcraft.io/t/request-automatic-aliases-for-lxi-tools/2956 . Thanks! :) [14:54] * jdstrand nods [14:55] lundmar: you don't need any more [14:56] oh great. Can it move to next step already? [14:56] lundmar: you have two votes. we just need to wait the allotted time to allow others the opportunity to vote against [14:56] ok [14:57] lundmar: then we'll grant the alias. fyi, the voting period is one week, so next monday I'll tally/grant [14:57] ok, parience it is then :) [14:57] patience* [14:58] PR snapd#4313 opened: timeutil: refresh timer take 2 [14:58] jdstrand: btw, I'm the guy who made the feature request for completions scripts support long ago. I recently revisited snap and I'm happy to see it has been added. However, it seems it is not working for aliased commands. [14:59] lundmar: hello [14:59] PR snapd#4314 opened: interfaces: switch to ConnectedPlug/ConnectedSlot API [14:59] lundmar: https://forum.snapcraft.io/t/tab-completion-for-snaps-bash/2261 [14:59] lundmar: 2.30 has support for aliased commands [15:00] Chipaca: Ahh, 2.30 . Got it. Thanks. [15:00] lundmar: let me know how it breaks :-) [15:00] of couse, I expect it to :) [15:00] courseØ [15:00] course* [15:01] lundmar: also note the completion snippet doesn't "see" the alias [15:02] ie if a snap foo has an app called bar that has a snippet, the snippet is always called as if the user had used foo.bar, even if the user aliased foo.bar to quux and used that [15:03] pedronis: nvidia is under control, I will fix the locking now (unless you are already on it) [15:03] Chipaca: I'll look into to the snippet stuff. The less defintion we have to add to get completion scripts working in its traditional form the better. [15:04] lundmar: you should be able to just drop in the snippet you'd usually drop in /usr/share/bash-completion/completions into you snap, set a 'completer' key in the yaml, and things work. At most you need to make it handle foo.bar instead of just bar. [15:04] Chipaca: Like this right? https://github.com/lxi-tools/lxi-tools.snapcraft/blob/master/snap/snapcraft.yaml [15:04] lundmar: like so [15:05] I'm adding the alias manually, however I noticed it does not work. [15:05] mvo: what do you know about the locking issue [15:05] mvo: do you have any theory? [15:06] lundmar: completion, or the alias? [15:06] zyga-ubuntu: none at all currently :( [15:07] mvo: question is 2.29 really open as milestone? are you doing a 2.29.x release? [15:07] Chipaca: completion not working for the lxi-tools.lxi command nor lxi alias (the latter is most important). [15:08] zyga-ubuntu: not sure I understand but yes, 2.29 is still open because its not released yet to stable core and also it looks like there are some warts with the SRU [15:08] lundmar: is it the one in the store? [15:08] PR snapd#4311 closed: debian: ensure /var/lib/snapd/lib/vulkan is available [15:08] Chipaca: yes [15:09] lundmar: complete -o default -F _lxi lxi [15:09] lundmar: glad completion scripts are (finally) getting there for you :) they were a very interesting feature to enable (huge thanks to Chipaca) [15:09] lundmar: that bit in your snippet will only work with "lxi" [15:09] (he did all the heavy lifting) [15:09] lundmar: and that will never get called with 'lxi' because the snap is called lxi-tools [15:09] lundmar: so... you probably ant complete -o default -F _lxi lxi-tools.lxi [15:10] want* [15:10] Chipaca: which is just fine. I'm really only interested in it working for the 'lxi' alias, not lxi-tools.lxi [15:10] lundmar: the snippet doesn't see the alias, as i tried to explain [15:10] the snippet always sees the 'canonical' (heh) app name [15:10] lundmar: (because the user can alias it to _anything_ and still want completion to work) [15:11] jdstrand: yeah, I know getting it working across confiment was interesting. Now, next feture we need to have first class commandline support is support for the 'man' command to view man pages ;) === cachio is now known as cachio_lunch [15:12] lundmar: work on that recently continued, thanks to cjwatson [15:12] once the confinement is working in the man command, then snapd can implement the bits to put man pages from snaps in the right place [15:13] PR snapd#4309 closed: snap: fix TestDirAndFileMethods() test to work with gccgo [15:14] Chipaca: Hmm. Then I will have to create a duplicate completion script just for the sake of snap. [15:14] jdstrand: next after that... devhelp :-D [15:14] Chipaca: heh [15:14] lundmar: aw [15:14] lundmar: or! or [15:14] lundmar: “complete -o default -F _lxi lxi lxi-tools.lxi” [15:15] lundmar: that should work in both places [15:15] Chipaca: yes, and that line belongs in the completion script (that I will have to create specifically for snap) unless I can somehow add the single line in the .yaml? [15:16] lundmar: i mean, you can ship that line in both places, it won't break stuff [15:16] mvo: whenever is convenient, can you take a look at https://dashboard.snapcraft.io/dev/snaps/8748/feedback/ [15:16] mvo: (base-18 issues) [15:17] mvo: I approved it for now, but it would be nice to get it to pass automated review [15:17] jdstrand: sure [15:17] I guess my point is, if possible I want to avoid changing anything in my source to reflects snap support. If possible it would be better to find a way for snap to support standard configurations. [15:17] jdstrand: thank you, it looks really messy :) [15:17] mvo: (note that r950 of the review tools have changes for base-18 but aren't in prod yet) [15:17] jdstrand: but note the version number [15:17] mvo: yes. I like your style :) [15:17] jdstrand: thank you for doing those [15:18] jdstrand: :P I will work on the errors after the other fires are under control [15:18] lundmar: i didn't find a way for that to work, unfortunately [15:18] jdstrand: thanks for the heads up [15:18] Chipaca: I can see how it is tricky to solve. [15:19] lundmar: that is: users can decide not to install your aliases (snap install --unaliased), or to override it with anything else, and we still want completion to work in those cases [15:19] if there's a trick i missed, i'd be happy to learn it [15:23] Chipaca: I'm thinking what if we define “complete -o default -F _lxi lxi lxi-tools.lxi” directly or indirectly (through simple key) and have that be picked up and source by some of the command wrappers. This way we can support standard completion scripts and end users don't have to touch their original completion scripts. [15:23] sourced* [15:24] lundmar: doable but a lot of work, because of how hairy complete can get [15:25] I mean, we could create maybe a completer-alias: lxi-tools.lxi key and support it that way. [15:27] jdstrand: Yeah, I landed the apparmor work in unstable/bionic but I still need to finish the seccomp work [15:27] the have the command wrapper source the completer script in case the _lxi bash function does not already exist (not sourced before). Might be simple to do. [15:27] then* [15:37] Chipaca: either way, users are free to change aliases manually. It seems to me we need to figure out a way to support that. I think changing the command wrapper accordingly might be a way. [15:38] pedronis: my local spread run appears to be happy now, fingers crossed for the spread run [15:42] mvo: thanks, I think the test need some tweaking to fail earlier [15:43] pedronis: the spread test you mean? [15:43] pedronis: or do you mean we need a unit test that tests this particular combination ? [15:43] mvo: no, the unit tests, I think the Mock function in configstate is a bit strange [15:43] it mocks too much [15:43] anyway I'm picking up the branch to work a bit on this [15:43] pedronis: much appreciated, thank you [15:45] lundmar: in all the above you refer to 'command wrappers'. What do you mean? [15:50] mvo: am I confused, or there are no tests for the hijack in configstate itself? [15:50] lundmar: note that if your snap were called just 'lxi' things would just work :-) [15:50] pedronis: iirc only indirect via coreCfgRun mocking [15:51] pedronis: so +1 for adding one, let me know if I should do this. sorry for this [15:51] mvo: no, the mocking is not called in configstate [15:51] it's only used far away (devicestate) [15:52] pedronis: autsch, indeed [15:52] I'll see if I can add one [15:52] Chipaca: Yes, however - that is not an option. We can't name all snaps after the primary tool it includes ;) [15:52] lundmar: one can dream though [15:53] lundmar: (also: why not?) [15:53] pedronis: please let me know if its too annoying, then I will do it :) [15:54] sergiusens, is there a reason we're using mypy 0.540 instead of the newest? [15:54] Chipaca: image a snap package with many tools (apps). You would need aliases for each app to avoid the . prefix. [15:54] imagine* [15:54] If not, mind if I update? [15:55] lundmar: most tools that are parts of a whole do have a common prefix or suffix, though [15:56] Chipaca: I assume the overall goal with aliases is to make it possible for the users to never know they are using a snap. [15:57] that is very aliases become powerfull feature [15:57] where* [15:57] Chipaca: I was looking at this file: /snap/lxi-tools/current/command-lxi.wrapper [15:57] lundmar: ah, that's a snapcraft thing [15:57] not sure what's in there today [15:58] (haven't had to look in a while because it mostly just works) [15:58] Chipaca: oh, it's not used when firing commands? [15:58] lundmar: completion doesn't run the command though [15:59] I thought maybe this file was fired every thing you fire the lxi-tools.lxi command [15:59] lundmar, indeed it is [16:00] lundmar, that's how snapcraft gets the LD_LIBRARY_PATH in there, runs any required setup scripts, etc. [16:01] in which case it would be possible to add a check to see if the e.g. _lxi function (defined via eg. new completer-alias key) and if the _lxi function does not exist it will simply source the completion script. [16:01] jdstrand: I'll resume work on the base snap staleness issue [16:01] Hey zyga-ubuntu, any more progress on the lxd upgrade issue? [16:03] kyrofa: no, not yet === cachio_lunch is now known as cachio [16:16] sergiusens, so, my last commit in the metadata branch failed in travis with "The job exceeded the maximum time limit for jobs, and has been terminated." ... what should I do? [16:16] roadmr, matiasb ^ [16:18] hm.. no idea, trigger it again? :/ [16:18] PR snapcraft#1580 closed: cli: setup gitignore when working from git directory at init [16:18] Facu: I'd trigger it again. Travis is brutal, it takes ages :( [16:18] roadmr, ack [16:19] lundmar: https://forum.snapcraft.io/t/2972?u=chipaca [16:24] sergiusens: I meant to ask before, are snap rebuilds expected to work now? I tried by just copying manifest.yaml over snapcraft.yaml but it didn't work. if it is expected to work, what is the right way to do it? [16:24] jdstrand: hey, we made a proposal on how to solve https://bugs.launchpad.net/snapstore/+bug/1732781, could you check the last comment (mine!) and let me know if that sounds acceptable? if not, I'm happy to find other alternatives [16:24] Bug #1732781: store should detect and reject changing snap types [16:24] roadmr: oh I missed that [16:24] * jdstrand reads [16:25] :D [16:26] roadmr: commented [16:26] thanks1 [16:27] ! [16:27] hehe [16:27] mvo: I noticed that configmanger has still the runner but now is unused [16:28] mvo: I pushed the test and tweaks if you want to look [16:29] roadmr, the github page says "failed", should it say "testing" or something? [16:30] Chipaca: great, let me get back to that thread later. I have a few things to take care of first. [16:30] lundmar: forum is async \o/ [16:30] my brain is async :D [16:32] hello guys, I'm looking forward to get a full dev reference of snapcraft. Can anyone guide me regarding that? [16:33] pdefreitas: hey, did you see snapcraft.io [16:33] pdefreitas: we have a forum, tutorials and other documents [16:33] Facu: let me check [16:35] mborzecki: Btw, I don't know if I ever sent you the link to https://forum.snapcraft.io/t/task-workflow-in-the-forum/206 [16:36] yes, I did, but I am looking for more advanced reference. [16:36] mborzecki: I know we talked about it, but I don't recall if I did send the link or not [16:36] niemeyer: thanks, i'll check it out [16:37] pedronis: re runner> yeah, we can kill that one again I think [16:37] mvo: I pushed the test if you want to look [16:37] mvo: killing the runner, yes, don't know if it's urgent [16:37] pedronis: test is nice, thank you [16:37] mborzecki: I just removed one of your nick tags from a topic because I thought you forgot to drop that when you dropped upcoming or backlog, but now I realize that you were probably not aware of those conventions [16:37] pedronis: probably not urgent, I make a note and fix it in my morning [16:37] pdefreitas: which topic in particular are you interested in? [16:38] niemeyer: yup, i was not [16:38] Facu: checking how to re-trigger the travis run [16:38] roadmr, thanks [16:39] pedronis: nice simplification in your commit, thanks for this [16:39] Facu: I don't think I can trigger a rebuild, you might be able to, I found some advice in https://stackoverflow.com/questions/17606874/trigger-a-travis-ci-rebuild-without-pushing-a-commit [16:40] roadmr, but if I close the PR and reopen it again won't lose all the conversation? [16:41] sergiusens, you have write access to the repo? may re-trigger that travis? [16:41] Facu: yes, that sounds scary :( sounds like the best option is to get someone with write access to retrigger the build [16:51] Issue snapcraft#1767 opened: stage-packages does not respect architectures [16:51] niemeyer: ping [16:51]