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