=== JanC_ is now known as JanC [00:36] PR snapd#2928 closed: tests: 2 workers on 14.04 and core 64, drop fixme system [00:52] Bug #1667493 opened: Please update Ubuntu Core "snappy" 16.04 LTS with libusb-1.0 [01:14] kyrofa, zyga: I got it to work, I think... at least it hasn't timed out yet. So that's promising. Will submit a patch after it's confirmed. [01:15] This device is quite a bit slower than the project was designed for, it seems. === JanC_ is now known as JanC === markusfluer1 is now known as markusfluer [05:11] cool [05:17] PR snapd#2929 opened: Added storage-framework interface === lazyPwr is now known as lazyPower [07:28] Bug #1667493 changed: Please update Ubuntu Core "snappy" 16.04 LTS with libusb-1.0 === chihchun_afk is now known as chihchun === mup_ is now known as mup === rumble is now known as grumble [09:31] hi there! do you guys know where I can find the revision history of 'desktop-gtk3'? [09:32] jlorenzo, hey, https://github.com/ubuntu/snapcraft-desktop-helpers/commits/master [09:32] seb128: thank you :) [09:32] yw! [09:32] do you have a problem with some recent change/update? [09:34] seb128: yes, but I'm not sure where's the issue. I'm building Firefox 52.0b9 with the same snap yaml file as 4 days ago. And now I get this error: [09:34] Issue while loading plugin: properties failed to load for desktop-gtk3: Additional properties are not allowed ('prime' was unexpected) [09:35] did you snap version change? [09:35] could it be that change? https://github.com/ubuntu/snapcraft-desktop-helpers/pull/54/files#diff-184032a532406b07009403e26f4fc62fR86 [09:35] PR ubuntu/snapcraft-desktop-helpers#54: Support mir-libs content snap [09:35] I don't believe so, let me check [09:36] could be I guess [09:36] didrocks is out today though [09:38] seb128: I'm not too familiar with snap. Is there a way to pinpoint a revision in "after" (like here https://dxr.mozilla.org/mozilla-beta/source/release/docker/firefox-snap/snapcraft.yaml.in#37 ) ? [09:39] jlorenzo, no there isn't afaik [09:39] the situation is a bit unfortunate :-/ [09:40] Trevinho, flexiondotorg, you use the desktop helper for your snaps, did you hit that error recently^? [09:40] * flexiondotorg reads backlog... [09:43] Hello jlorenzo :-) [09:43] flexiondotorg: hi! [09:43] To answer seb128's question, I do use the desktop helpers. [09:44] I've not encountered the issue: Issue while loading plugin: properties failed to load for desktop-gtk3: Additional properties are not allowed ('prime' was unexpected) [09:44] PR snapd#2930 opened: tests: add systemd dependency loop failover test scenario [09:44] jlorenzo You're working at Mozilla? [09:44] flexiondotorg: good to know :) [09:45] flexiondotorg: that's right [09:45] OK, I was chatting to Rail Aliiev and Mike Kaply about snap Firefox yesterday :-) [09:46] great :D I'm on duty while Rail is still sleeping ;) [09:46] Is the CI system building the snap on Ubuntu 16.04? [09:46] I believe so. Let me double check [09:48] flexiondotorg, that change was made on wednesday it looks like, did you rebuild some snaps since? [09:48] well I guess I can try a desktop-gtk3 example here [09:48] jlorenzo Can you also make sure you have snapd 2.22.3 and snapcraft 2.27.1 installed on the build server. [09:49] * seb128 does that [09:49] * jlorenzo does it as well [09:49] flexiondotorg, you think old versions would not handle some new syntax? [09:49] it that helps, we have a docker image that helps repro [09:49] jlorenzo I understanding there are some patches for AppMenu integration that are being merged to Firefox, is the snap building a branch that has those patches? [09:50] yeah, I can confirm the issue here [09:51] flexiondotorg: no, that's the regular firefox beta. For the record, 4 days ago, the previous beta (52.0b8) was correctly built. I rebuilt the same changeset, in the same condition, and it failed with the "prime" error [09:51] on my simple ghex example [09:51] jlorenzo Thanks. [09:51] works after updating snapcraft to current [09:52] okay, I'll try updating [09:52] jlorenzo, flexiondotorg, ^ I could reproduce on an non uptodate system, fixed for me after updating snapcraft to the xenial-updates version [09:53] seb128 Yeah. I've not seen this issue myself but saw mention of something similar and that an update resolved it. [09:54] the last time our docker image got update was 5 months ago. It looks like the non-update is the cause [09:54] got updated* [09:54] jlorenzo Once you have a snap building again you might want to do this following: [09:55] after: [09:55] - desktop-gtk3 [09:55] - indicator-gtk3 [09:55] Change the after stanza as above. [09:56] The indicator-gtk3 helper will pull in all the libraries to support AppMenu. [09:56] So when those patches land, you'll have the required support in the snap. [09:57] with indicator-gtk3 you get the support before the patches have landed (to ubuntu, upstream is already fine) :-) [10:00] awesome! thank you guys for the leads [10:00] I'll tell you if the thing worked [10:01] flexiondotorg: do you have any experience with classic confinement (defined in 'snapcraft.yaml' itself?) === jamiebe__ is now known as JamieBennett [10:05] Trevinho I do. [10:06] flexiondotorg: as... it seems that with latest snapcraft, PATH and LD_LIBRARY_PATH's aren't set by snepcraft itself, isn't it? [10:06] o/ [10:06] Trevinho I hadn't noticed. I'll have to check that. [10:07] flexiondotorg: as that causes th desktop-launch not to work anymore... [10:07] OK, I'll test. [10:07] flexiondotorg: although things such as themes and stuff, shouldn't be embedded when classic is set... [10:07] I'm making a new classic snap PoC later. [10:07] seb128: ^ .... [10:07] ok [10:08] So I'll be sure to test that. Thanks for the heads up. [10:08] Trevinho, is that a reported bug/regression? [10:08] if so it should be flagged as important [10:08] I didn't look for that, as I though it was somewhat a wanted thing? [10:08] jlorenzo Other than upstreaming the AppMenu patches, are there any blockers for Firefox? [10:08] maybe is the core handling that now? I don't know if the environment: stanza would do that [10:10] seb128: i was also wondering if we should remove some things in the desktop-* parts when classic is used... as they access to global themes and such, so maybe... we don't have to embed those? [10:10] a question for didier too [10:11] flexiondotorg: not that I know of, but I'm not too aware of the snap integration. I'll ask Rail later today about it. [10:15] jlorenzo Thanks. [10:16] jlorenzo I'm out of the office next week, but I'd like to catch up with you and Rail the following week. [10:16] PR snapd#2931 opened: vet: fix vet error on mount test [10:16] flexiondotorg: sounds good to me [10:17] Great. [10:19] Trevinho, yeah, I guess we could [10:35] PR snapd#2932 opened: snap yaml: validate slot/plug names [10:39] jlorenzo Ping us here when you have good news from CI ;-) [10:41] flexiondotorg: sure! It may take several hours. We're still figuring if we need to respin a new build of not. [10:44] (we freeze every hash at the first step of the build, including the docker images) [10:56] PR snapd#2931 closed: vet: fix vet error on mount test [11:28] PR snapd#2926 closed: cmd/snap-update-ns: move test data and helpers to new module === chihchun is now known as chihchun_afk [12:36] PR snapd#2933 opened: overlord/hookstate: don't report a run hook output error without any context === hikiko is now known as hikiko|ln === hikiko|ln is now known as hikiko === jamespage_ is now known as jamespage [14:35] <_prasen_> I have 2 apps inside the yaml [14:36] <_prasen_> where one is a regular app and the other is a daemon [14:36] <_prasen_> both of them are shell scripts [14:37] <_prasen_> a variable created by the app script is used by the daemon script to launch a go server [14:37] <_prasen_> so I want to understand the context in which all of this happens [14:38] John Lenton around? I have the install stuck at 'Run configure hook of "core" snap if present' [14:38] <_prasen_> the go server thingy is another part [14:38] (Martin here) [14:38] <_prasen_> how do daemons inside the snap run [14:38] <_prasen_> ? [14:39] <_prasen_> is there a way to see the currently running daemons [14:42] glimcoil— o/ [14:42] glimcoil— hello! [14:42] Hello. [14:42] glimcoil— I've got to go on a school run in ~10 minutes but will be back after that [14:42] Send me an email with a SSH public key and I can get you access to play around on one of them [14:43] glimcoil— ooh! that's more access than I expected to get, but I'll take it [14:43] They are all VMs and I can rebuild them trivially [14:43] glimcoil— https://launchpad.net/~chipaca/+sshkeys [14:43] So you can experiment on them - and I can get them again into the bad shape :-) [14:44] <_prasen_> sum1 tell me how do i see the running daemons [14:44] Ok, I'll send you email. I hope you can access over IPv6. no IPv4 inbound access.... [14:44] glimcoil— i'm john.lenton@canonical.com [14:44] Noticed. [14:44] I hope so too :-) [14:44] ah, d'oh, you had my email from the list [14:44] Just wanted to make clear that you don't need to worry about breaking things... [14:45] <_prasen_> glimcoil : how do i see running daemons? [14:45] glimcoil— i'm on a&a here and they do give me ipv6 but i've never needed it i think [14:45] _prasen_— in what? [14:45] <_prasen_> i am using the awsiot snap [14:45] _prasen_— systemctl | grep awsiot [14:46] <_prasen_> i did not find it there [14:46] <_prasen_> wait [14:46] _prasen_— then systemctl status snap.awsiot-yadda [14:46] <_prasen_> gimme 2 [14:48] <_prasen_> you familiar with the awsiot snap? [14:48] looks like the service is snap.awsiot.run [14:48] _prasen_— i am not [14:48] also it did not work here [14:48] <_prasen_> it = ? [14:48] _prasen_— reach out to the author? [14:48] the service in the snap failed to start [14:48] <_prasen_> i will [14:49] <_prasen_> but i am very much not clear on how different parts are aligned to work together [14:49] <_prasen_> the daemon's command is a shell script [14:49] <_prasen_> that launches a go server [14:49] I've got to go [14:50] <_prasen_> okaaay [14:50] glimcoil— looking forward to that email [14:50] _prasen_— reach out to mectors; he should be around [14:50] <_prasen_> thanks for the help [14:50] ttfn [14:58] <_prasen_> marteen ectors ? [15:00] _prasen_: If you look for example (for a server written in C), see https://github.com/freerangerouting/frr.git (Look for the snapcraft subdirectory). This is a Fork of Quagga with multiple routing daemons [15:02] <_prasen_> glimcoil : hahahahhahahahaha [15:02] <_prasen_> this is a pretty heavy example [15:03] <_prasen_> ty [15:03] <_prasen_> will try to get my head around it [15:03] <_prasen_> though the task i am at [15:03] <_prasen_> it just has a single daemon [15:04] <_prasen_> launching a pretty basic go server [15:04] <_prasen_> ty! [15:05] <_prasen_> well its fri night here..getting off for now [15:05] <_prasen_> gg [15:07] hey. does anyone know how snappy gets the profiles into aa? [15:07] for some reason my aa-status has nothing, and my snaps are running unconfined === stranger is now known as Guest15626 [15:11] elopio: are you the test guy for snapcraft? [15:23] ppisati, i think he is on vacation this week [15:32] ogra_: :( [15:33] PR snapd#2933 closed: overlord/hookstate: don't report a run hook output error without any context [16:05] flexiondotorg: seb128: hey guys! so, the version upgrade fixed our pipeline! Thank you very much for your help and the context :D [16:05] jlorenzo Great! :-) [16:05] jlorenzo, hey, glad you got it resolved and yw! :-) [16:28] *interesting* [16:29] zyga, pedronis: I'm seeing the configure script stuck starting from *no snaps* [16:33] zyga, pedronis, this is 2.22.3 [16:35] Chipaca: I cannot even parse that? [16:35] what does from no snaps mean? [16:36] pedronis— snap list core -> "try hello world" [16:36] i mean snap list [16:36] Chipaca: on, what? [16:36] # snap list [16:36] No snaps are installed yet. Try "snap install hello-world". [16:36] starting from what version of snapd? [16:36] root@ci-comp11-dut:~# snap install core [16:36] [|] Run configure hook of "core" snap if present [16:37] ouch, shouldn't've pasted that, sorry [16:37] pedronis— 2.22.3 [16:38] pedronis— nothing in debug logs either [16:39] Hi. how can I run bash from inside the snap environment? There was command, something like snap try but I don't remember exact syntax [16:39] sborovkov— snap run --shell snap.app [16:40] pedronis— anything you want me to try, or should i wait for zyga? :-) [16:41] Chipaca: so it's very easy to reproduce? [16:41] pedronis— apparently! [16:41] good and bad [16:41] pedronis— but I'm not sure [16:41] pedronis— i mean, every test suite we run starts from no state [16:41] right? [16:42] Chipaca: thanks [16:42] sborovkov— np; good luck [16:49] Hi there ! [16:50] pedronis— so, yes: reset-state, snap install core -> hanging conf hook [16:50] do we know where it hangs? [16:50] pedronis— how can i know? [16:50] strace? [16:51] pedronis— i've got root on the machine (because glimcoil is awesome like that) [16:51] Chipaca: anyway the issue might well be that we restart core but don't stop [16:51] ah, strace. Give me a bit. [16:51] early [16:51] enough [16:51] so no snapd to talk to ? [16:51] or something like that [16:56] pedronis— https://private-fileshare.canonical.com/~john/trace [16:56] pedronis— that's post-restart [16:59] Chipaca: re [16:59] jjohansen: hey [17:00] jjohansen: I'm about to add a new apparmor rule to 2.22.7 release [17:00] jjohansen: can I use the one you gave in the bug report verbatim or do you have any last wishes? [17:00] zyga— o/ [17:01] zyga— in your sea of VMs :-) do you have one that's pristine-ish (or pristinable), running stock snapd from the archive? [17:03] Chipaca: I have a xenial VM that is snapshotted at 2.0.14 or something like that [17:03] Discovering ubuntu core ... tried it in a VM, and now on a pi 3... I wanted to launch a simple gui app (ubuntu-calculator-app) ... it asks me to install "ubuntu-app-platform" which seems not to be available ... :/ [17:03] zyga— can you take it to 2.22.3 or thereabouts without installing snaps? [17:03] zyga— and then try to install core? [17:03] Is there some dirty-work-manual-package-installation to enable gui on rpi3 ? [17:04] Chipaca: I did that all monday I think trying to reproduce the issue lool reported (ErrNoState), it was OK then [17:04] Chipaca: but I tried with different core revision [17:04] Chipaca: I'll try in a sec, let me push one thing first [17:04] (Not affraid to do so, I'm just evaluating if ubuntu-core could fit our needs for an iot-project :) ) [17:04] Tryum: the answer is yes! [17:04] Tryum: and we can help you out [17:05] ogra_, today, on stable core, is there no way to disable auto-updates, then? [17:05] Tryum: it's a snap? [17:05] Tryum: at least snap find, here, shows it exists [17:06] Tryum— did you check 'snap info ubuntu-app-platform'? maybe it's not a stable snap yet [17:06] nacc— that's on amd64; armhf might be different [17:06] (i'm assuming) [17:06] jjohansen, jdstrand: should we add the extra rule for libc to all snaps or just those that use classic confinement in jailmode? [17:06] Chipaca: good point [17:06] * nacc is not certain how to see other archs from `snap` [17:07] nacc: you need to run native AFAIR [17:07] zyga: ah ok [17:07] yeah. Not added a --arch option. [17:07] Chipaca, that would be handy! [17:07] hush you [17:07] :-p [17:07] Chop chop [17:08] aww! but i wanted a weekend! [17:08] heh [17:08] Ok snap info returns me something ! [17:08] Haha, yeah you're about there eh? [17:08] Tryum— also depending on your iot needs there are people poking at the framebuffer directly from qt i think? [17:09] kyrofa— close [17:09] Chipaca: yes that's something I'm doing on raspbian [17:09] I only know because we recently landed that interface (so the snap could be confined) [17:09] so the snap is available as candidate/beta/edge ! [17:09] (on master; not released yet afaik) [17:10] I guess that's why it does not install directly ;) [17:10] Tryum— as i understand it if you use e.g. --candidate for the app snap, the other one will come automatically [17:10] but i could be wrong; i haven't worked on that [17:10] PR snapd#2934 opened: errtacker,overlord/snapstate: more info in errtracker reports [17:12] kyrofa, yeah, i dont think you can disable updates currently [17:13] ogra_, yeah I saw that PR you referred to was closed [17:14] Chipaca: --candidate did the trick ! thanks ;) [17:14] Tryum, i dont think ubuntu-app-platform will help much [17:14] PR snapd#2935 opened: interfaces/apparmor: compensate for kernel behavior change [17:14] PR snapd#2936 opened: interfaces/apparmor: compensate for kernel behavior change [17:15] ogra_: it's not providing the required interface ? [17:16] is there a way to list packages providing interfaces ? [17:16] Tryum, you can install mir-kiosk and mir-libs to get a display server up, but the app wont integrate with it (it would have to be specifically developed to run in kiosk mode) ... alternatively you can install unity8-session but that is also not helping with any additional apps since it wont allow execution in the UI [17:16] Tryum, we are simply not there yet [17:16] oki doki ;) [17:17] bits and pieces exist and run ... i.e. the mir kiosk demos do ... as well as the unity8-session snap [17:17] but integration is still lacking [17:18] (teh session can only run apps shipped inside the session snap ... (which is ... well... system-settings ...) [17:18] ) [17:18] well my current app is a qt/eglfs app ... I should try to package it and try it on ubunt-core instead of poking around :D [17:18] well, your app might be able to run in kiosk mode then [17:19] you would have to a) make it use mir ... and b) make it use the mir interface on a snap level [17:19] I think maybe without mir-kiosk even ... as I did not compiled with wayland support [17:21] ogra_— there's things talking to the framebuffer directly [17:21] ogra_— not sure of the details though :-) [17:22] we dont have an interface for that (yet) [17:22] the mir-kiosk snap definitely works for Qt apps though [17:23] (i also have an experimental (VERY experimental) kodi snap that uses mir-kiosk just fine) === JanC is now known as Guest36981 === JanC_ is now known as JanC [17:24] PR snapd#2937 opened: errtracker,overlord/snapstate: more info in errtracker reports [17:26] zyga— did you get that vm up? or are you otherwise busy? [17:26] hi there -- is there a snap for Google Chrome [17:29] ogra_: oh if you want testers for the kodi snap, I'm here ! I need a kodi running for a future product ;) [17:29] Tryum, once it is usable i'll remember you :) [17:30] (the mir patches are in kodi 18 only ... i had a backport into the just released kodi17 tree that worked but then i moved forward and everything is broken atm) [17:30] so it is kind of a matter of waiting for the kodi development release to be fixed [17:31] and there is no sound support at all yet [17:32] in any case, if you want graphical output on one of the arm boards, Qt and mir-kiosk are your best bets currently [17:33] https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ has some info [17:33] (slightly outdated i think though ... ) [17:35] Hey davidcalle, the dragonboard image link on developer.ubuntu.com is hard-coded to 20161102 instead of using the current symlink [17:37] kyrofa: hey, can fix tonight, not sure about deploying before monday, though, will check with webteam/is [17:37] davidcalle, yeah no rush, just wanted to see if that was intentional or should be fixed [17:37] ogra_: thanks for the link [17:38] Must have been, at some point [17:38] Clearly not ideal now [17:38] Thanks Kyrofa ! [17:38] davidcalle, sure thing! [17:39] well I guess it will be hard to quickly port our app to ubuntu-core then : currently we use omxplayer for the video playback, as we did not manage to get hardware video decoding throug QtMultimedia. [17:46] glimcoil— you around [17:46] ? === mup_ is now known as mup [17:57] PR snapd#2935 closed: interfaces/apparmor: compensate for kernel behavior change [17:59] PR snapd#2937 closed: errtracker,overlord/snapstate: more info in errtracker reports === mup_ is now known as mup [19:08] ogra_, which channel do I need to use if I want the core snap including xenial's /etc/os-release for classic? [19:08] kyrofa, what arch ? [19:08] an x86 one ? [19:09] i just released something to candidate for amd64 and i386 ... all others ... edge [19:09] ogra_, arm64 [19:09] ogra_, ah, okay thanks :) [19:09] arm64 classic ? [19:09] where did you get the classic install from ? [19:09] ogra_, to clarify, I meant the classic snap [19:10] ogra_, and edge [19:10] oh [19:10] yeah, classic -> edge [19:21] kyrofa, hey, sorry another quick question about configuration values & hooks [19:22] kyrofa, what characters are allowed for config keys? [19:23] snapctl is not very explicit about it, and when you have an error it is a bit hard to debug [19:26] alex-abreu, good question [19:27] alex-abreu, let me look [19:30] I get "invalid option name", the errors are a bit cryptic [19:43] alex-abreu, yeah: ^(?:[a-z0-9]+-?)*[a-z](?:-?[a-z0-9])*$ [19:43] alex-abreu, regex errors are tough to make friendly [19:44] kyrofa, yeah in the meantime I found this bug by Pawel https://bugs.launchpad.net/snapd/+bug/1658140 [19:44] Bug #1658140: More strict key check in snap/snapctl get/set broke existing snap [19:44] kyrofa, well yeah ... [19:44] kyrofa, thank you for looking that up [19:47] alex-abreu, no problem [19:54] ogra_, on arm64, I refreshed core to edge, uninstalled classic, reinstalled, and I still have "Ubuntu Core" in my /etc/os-release [19:54] (in the classic shell) [19:54] This is new, too. Now we have the HOME_URL and BUG_REPORT_URL [20:03] zyga: just use the suggested rule and go with classic confinement at least for now === E-werd is now known as JollyRgrz === JollyRgrz is now known as E-werd [20:24] kyrofa, hmm, when freshly creating the core chroot ? [20:24] err [20:24] the classic chroot [20:25] ogra_, yep [20:25] ogra_, I refreshed core to edge, the removed classic and re-installed it. That should do it, right? [20:25] you should actually see it creating os-release and lsb-release at the end of the creation when "sudo classic" creates the new chroot [20:25] I don't, actually [20:25] i definitely saw it during my presentation yesterday [20:25] I did too! [20:26] and there i also had snap removed classic first ... [20:26] ogra_, this is what I see: http://pastebin.ubuntu.com/24060776/ [20:26] and your core is also on edge ? [20:27] Yeah, rev 1316 [20:27] very weird [20:36] ogra_, happy to try anything to debug it further, if you like [20:36] well, let me try again [20:36] i'm just in some other emergency thing atm so i cant constantly focus on that [20:37] ogra_, understood, no problem [20:43] kyrofa, crap, yeah, there is something broken [20:43] kyrofa, switch your core to stable ... that should still have the bits [20:44] ogra_, that what I used initially-- it didn't have the bits, which is when I asked you what I should be using instead [20:44] ogra_, I'm not blocked, that file is writable. But yeah, something broke [20:44] snap refresh core --stable ....reboot ... then: snap remove classic ... snap install classic --devmode --edge [20:45] that should give you exactly what i used in the presentation [20:45] ogra_, ah, I was using the initial image. I was probably not up-to-date core-wise [20:46] ah, yeah [20:46] you really want to be on the latest stable core [20:46] * kyrofa goes back to stable [20:46] but that edge doesnt work is worrying [21:01] kyrofa, urgh [21:01] so when moving the build scripts a lot of stuff was missed by me ... https://github.com/snapcore/core/pull/10/files ... [21:01] PR core#10: sync up-to-date hooks (how did that happen?) [21:01] kyrofa, thanks for pointing it out, we were about to release a new core [21:03] ogra_, sure thing, glad I didn't think to update my stable core :P [21:04] well, we didnt release yet [21:04] ogra_, nah, I mean, I would have been perfectly happy [21:04] And not talked to you at all [21:19] ogra_, which by the way I can confirm works [21:19] yeah [22:21] Oh my gosh.... someone remind me why I decided to build this on-device instead of using LP [22:23] kyrofa: you don't like flagellation but need punishment? [22:23] Yeah that sounds about right [22:24] davmor2, I finally slapped myself the fourth or fifth time I pressed the arrow keys to make sure it didn't freeze [22:25] Alright, it's at the `staging` step. I'm going to spin up an LP build and I bet it'll finish first [22:37] Bug #1667829 opened: console-conf v0.0.5 crashes if no config needed [22:39] So, will snaps that have the home interface ever be able to access symlink folders? [22:40] or is that by design excluded? [22:40] Blu2, what do you mean? [22:40] symlink folders? [22:40] Blu2, you mean symlinks that point outside of the home directory? [22:41] yes [22:41] on another HDD [22:41] Blu2, I believe that's by design. There's the removable-media interface that covers that use-cas [22:41] e [22:45] ok [22:45] thanks for the answer [22:45] I wish I could give programs specific folders that they can access [23:10] PR snapcraft#1084 closed: make: add support for cwd path to make() function [23:10] PR snapcraft#1116 closed: Changed "snappy try" to "snap try" [23:13] Bug #1667841 opened: core snap should clean up /run after build [23:31] Bug #1667844 opened: r1325 core snap candidate rebooting every 7 min without iTCO_wdt module loaded [23:53] plars, sorry, 1337 fixes the blacklist stuff again [23:53] ogra_: awesome! good to hear :) [23:53] * ogra_ just noticed the bug ... two image builds badly regressed not processing some build hooks