[00:26] <mup> PR snapd#1860 opened: misc fixes/tweaks/cleanups <Created by chipaca> <https://github.com/snapcore/snapd/pull/1860>
[00:56] <nhaines> kyrofa: Nextcloud 9 feels like it came out 7 years ago!
[00:57] <nhaines> kyrofa: in any case, your first ownCloud snap was a really cool proof-of-concept, the Nextcloud snap that got SSL support is amazing, and being able to say "Huh, wonder how this is looking now," run "snap install nextcloud" on my laptop, play with it, then delete the snap and not have 200 server packages installed and running is just amazing!
[00:58] <nhaines> kyrofa: but I'm glad Nextcloud embraced it (despite constantly saying they're not packaging Nextcloud for distros) and I'm looking forward to migrating my cloud server to the snap.  :)
[00:59] <nhaines> Also, I tried to snappify the client but failed because of some missing directory and don't have the knowledge to proceed, but for a while it looked promising, hehe.
[02:16] <sabdfl> what's the best python standard library for dealing with --opts ?
[02:37] <mup> PR snapd#1855 closed: overlord/boot: have firstboot support assertion files with multiple assertions <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1855>
[02:40] <sergiusens> sabdfl argparse is in stdlib https://docs.python.org/3/library/argparse.html
[02:41] <sergiusens> so no extras needed
[02:41] <sabdfl> thanks sergiusens, i've so far just copied docopt into my snap, is that considered a bad option?
[02:41] <sabdfl> i can easily fall back to argparse
[02:42] <sergiusens> sabdfl docopts is great for simple CLIs, it has gotten out of control for snapcraft and its ever growing options
[02:42] <sabdfl> i can believe that
[02:42] <sabdfl> my cli is super simle so i will stick to it for a quick fix
[02:43] <sergiusens> sabdfl for snapcraft itself I've been pondering on click http://click.pocoo.org/5/why/ ; played with it a bit and felt like a good match
[02:44] <sergiusens> yeah, docopt solve the simple cli's just great
[02:44] <sergiusens> it get's tricky when adding too many differing subcommands
[02:45] <sabdfl> i bet
[03:22] <kyrofa> nhaines, yeah, I've got the client snapped but I
[03:22] <kyrofa> nhaines, I'm waiting to publish for indicators to work
[03:22] <kyrofa> (indicators in snaps are broken right now)
[03:25] <kyrofa> kgunn, indeed, that's the current state of the art as far as I know, but I've lost track of a bit of the most recent snapcraft features-- it may have gotten better there recently
[06:14] <mup> PR snapd#1861 opened: tests: fixes to actually run the spread tests inside autopkgtest <Created by mvo5> <https://github.com/snapcore/snapd/pull/1861>
[07:59] <mvo> ogra_: small bugreport around classic, it seems like running it twice gives a ugly message that dev/pts is already mounted
[07:59] <mup> PR snapd#1862 opened: tests: add tests for the classic dimension <Created by mvo5> <https://github.com/snapcore/snapd/pull/1862>
[08:00] <ogra_> mvo, hmm, weird, shouldnt systemd unmount it ?
[08:01] <morphis> zyga: ping
[08:07] <mvo> ogra_: it seems not
[08:07] <morphis> mvo: can we already do sth like a factory-reset these days?
[08:15] <mvo> morphis: well, sort of, but you need to be careful
[08:15] <mvo> morphis: do you need a script to do that? how far do you want to go? reset everything ? including kernel/os and remove all data ?
[08:16] <mvo> ogra_: I have not really investigated, more important stuff is still going on, its just cosmetic but I noticed while writing automatic tests for classic
[08:16] <ogra_> morphis, can you bring that up in the filesystem layout thread i started on the ML, we will need a partiton that holds the original snaps for this i think
[08:17] <morphis> ogra_: can do that
[08:17] <ogra_> thanks
[08:17] <morphis> mvo: thanks, was just wondering
[08:18] <mvo> morphis: so essentially if you keep the stuff that firstboot puts on the image you can wipe everything else
[08:21] <morphis> mvo: ok, I think tim already has something for this in place with his recovery work, but was more thinking about what we're offering for other devices
[08:21] <mvo> morphis: this is probably something for the next sprint, we need a more generalized solution.
[08:21] <morphis> ok
[08:32] <mvo> ogra_: so I debugged why firstboot fails with ubuntu-image. it puts the grub.cfg into a different place than before. i.e. /boot/efi/EFI/ubuntu/grub.cfg (now) vs /boot/efi/EFI/ubuntu/grub/grub.cfg (before). there is a bind mount in the initramfs that assumes the grub/ location, do you know more aobut this change? I can update the initramfs code to use the other location I think, I'm just a bit puzzled
[08:36] <ogra_> mvo, that was james code, not really sure why its there ... drop it and lets have some test images ?
[08:37] <ogra_> (thats was also in system-ab times)
[08:38] <mvo> ogra_: http://paste.ubuntu.com/23144982/
[08:38] <mvo> ogra_: its stuff we still need. well, we could avoid the entire bind mount
[08:38] <mvo> ogra_: but that would require changes in the snapd code too, maybe not unreasonable but a bit late
[08:40] <mvo> ogra_: if the debdiff looks correct I will upload and hopefully this unblocks u-i
[08:40] <mvo> u-i generated images
[08:43] <ogra_> mvo, looks fine
[08:44] <mup> PR snapd#1863 opened: image: have prepare-image set devmode correctly <Created by pedronis> <https://github.com/snapcore/snapd/pull/1863>
[09:18] <mup> PR snapd#1863 closed: image: have prepare-image set devmode correctly <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1863>
[09:26] <didrocks> pstolowski: hey! any leads on bug #1620560? (reminder that we need a fix to demo to consumer next week the revert functionality ;))
[09:26] <mup> Bug #1620560: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1620560>
[09:28] <Chipaca> sergiusens, when you're around, http://paste.ubuntu.com/23145076/
[09:29] <Chipaca> didrocks, you're demo'ing a snap in devmode?
[09:32] <Chipaca> sergiusens, the issue there more than anything else is the '401 None' and not-too-helpful error message
[09:32] <Chipaca> sergiusens, dholbach knows more
[09:33] <didrocks> Chipaca: has to, the interfaces fixes are in trunk, (and one not done)
[09:34] <didrocks> Chipaca: if you have any other way around, I'll gladly take it :)
[09:37] <pstolowski> didrocks, i've discussed the fix with Chipaca, looks simple, just did it and about to build and test
[09:41] <didrocks> pstolowski: excellent! you think it's going to be in this week's release?
[09:41] <ysionneau> in which context is executed the post-stop-command?
[09:42] <ysionneau> do I have access to /usr/bin and /bin ? (for instance : ps/awk/grep/kill)
[09:43] <liuxg> I compile my go project on my raspberry pi 3, and when I run it on the pi 3 device, I get "runtime: this CPU has no floating point hardware, so it cannot run this GOARM=6 binary. Recompile using GOARM=5." it is a golang project. how to correct this problem. it works well on pi 2 device. thanks
[09:43] <pstolowski> didrocks, I should have MP ready today, what happens next is not in my hands, but I'll make sure everyone knows it's important
[09:45] <didrocks> mvo: FYI ^
[09:45] <didrocks> thanks pstolowski
[09:45] <liuxg> how to configure go to compile my go project using GOARM=5. currently on my board, the version of snapcraft is 2.15.1
[09:56] <mvo> didrocks: if its straightforward, happy to make sure its in, thank you
[09:56] <nhaines> kyrofa: Hmm, indicators seemed to mostly work in the Telegram snap, but I haven't used that for a while because it was always out of date, too.  In any case, I'm glad you're working on that, too.  It will be good to get Nextcloud-branded stuff into Ubuntu 16.04 LTS.
[10:00] <Chipaca> ysionneau, in the same context as everything else in the snap
[10:03] <Chipaca> ysionneau, try "snap run --shell yoursnap" and then you can dig around yourself
[10:04] <ogra_> mvo, whats with all these .moved files i always see in bzr branches after you touched them ? do you have some special bzr setup that keeps backups this way ?
[10:07] <mvo> ogra_: eh, no idea, what files are those?
[10:07] <ogra_> ogra@anubis:~/datengrab/devel/branches/snappy-systems/dragonboard$ ls -lh|grep moved
[10:07] <ogra_> lrwxrwxrwx 1 ogra ogra    9 Sep  6 16:30 uboot.conf.moved -> uboot.env
[10:07] <ogra_> -rw-rw-r-- 1 ogra ogra 128K Sep  6 16:30 uboot.env.moved
[10:07] <ogra_> ogra@anubis:~/datengrab/devel/branches/snappy-systems/dragonboard$
[10:07] <ogra_> before there also was a pi2.moved that i recently deleted
[10:08] <ogra_> i only notice them showing up after you touched the branch ...
[10:10] <ogra_> hmm, funnily this time the files dont show up in the LP UI ... the pi2.moved one did
[10:30] <ysionneau> Chipaca: thanks, how can I find the snap name syntax? i've tried the name in the 1st column of "snap list" and it does not work, I guess I need to append/prepend something
[10:50] <liuxg> ogra_, when I try to run "sudo classic.create" on pi 3, it gives me the error like "runtime: this CPU has no floating point hardware, so it cannot run this GOARM=6 binary. Recompile using GOARM=5."  how to correct this problem? thanks
[10:53] <ogra_> liuxg, no idea ... thats definitely not related to classic ... classic is a shellscript
[10:54] <ogra_> (and classic.create is long gone ... "sudo classic" is all you need)
[10:54] <liuxg> ogra_, but I need to run classic.create first, then I run then sudo classic, right? I got this from one your email replies.
[10:55] <ogra_> nope
[10:55] <ogra_> just sudo classic
[10:55] <ogra_> the creation is automatic nowadays
[10:55] <liuxg> ogra_, but the "classic         classic.create  classic.reset" all 3 commands are there..
[10:55] <ogra_> where did you get that classic snap from ?
[10:55] <ogra_> you need --devmode --edge
[10:56] <liuxg> ogra_, http://paste.ubuntu.com/23145383/, this is what happens here.
[10:56]  * mwhudson blinks
[10:57] <mwhudson> pretty sure the pi3 has a FPU :-)
[10:57] <ogra_> liuxg, well, no idea what that is ,... there is no go in classic
[10:57] <liuxg> ogra_, yes, that is exactly what I got here http://paste.ubuntu.com/23145387/
[10:57] <ogra_> liuxg, --beta != --edge
[10:58] <liuxg> ogra_,  sorry, I might get wrong. I will try the edge one.
[10:58] <ogra_> hmm, trhough looking at the store beta and edge are the same
[10:58] <mwhudson> liuxg, ogra_: fwiw, go is looking at the AT_HWCAP auxv entry wrt that message
[10:59] <liuxg> ogra_, mwhudson, for pi 2, it works well for the "--beta" channel.
[10:59] <ogra_> mwhudson, the tty prob is mainly that even if you have it print the issue file, it will not clear the screen and the line will appear somewhere in the middle of the boot messages that are still in the terminal
[10:59] <mwhudson> ogra_: ah
[11:00] <ogra_> we need to find out how to clear the screen i think
[11:00] <ogra_> (which is hard ... but i know there are serial apps that can do it)
[11:00] <mwhudson> ogra_: agetty claims to do it by default :/
[11:01] <liuxg> ogra_, I tried to change to use "edge" channel, and it is the same thing for me http://paste.ubuntu.com/23145394/
[11:01] <mwhudson> i guess putting 24 newlines in the issue file would not be considered elegant
[11:01] <ogra_> liuxg, yes, as i said, checking the store revealed they are the same
[11:03] <ogra_> mwhudson, and pointless if your terminal window is bigger (like mine)
[11:04] <mwhudson> ogra_: 1 million newlines?
[11:04] <mup> PR snapd#1864 opened: Apply flags (devmode) on revert <Created by stolowski> <https://github.com/snapcore/snapd/pull/1864>
[11:04]  * mwhudson should just go to bed
[11:04] <ogra_> that might work ... even on hidpi displays :P
[11:05] <mwhudson> i guess it would be a bit of a waste of precious storage space in the embedded case
[11:05]  * mwhudson zzz
[11:05] <ogra_> adding a loop that counts from 1 to 1mio ? nah
[11:06] <ogra_> and given how long it takes for python to come up it would also not siginificantly slow it down on arm :P
[11:14] <mup> PR snapd#1860 closed: overlord/snapstate: misc fixes/tweaks/cleanups <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1860>
[11:27] <ogra_> slangasek, so i fixed the sizes in the dragonboard gadget yaml ... using -w ./workdir to keep the content i see part0-part7.img files under .images/ in there ... all at the right size ... but looking at the resulting image there is only one partition, so i suspect however you invoke sgdisk doesnt do the right thing
[11:32] <mup> PR snapd#1852 closed: asserts: update trusted account-key asserts with names <Created by emgee> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1852>
[11:42] <JamieBennett> ogra_, elopio, have you tried a usb eth adaptor with the Dragonboard, does that work for console-conf?
[11:43] <ogra_> JamieBennett, nope, havent tried that yet ... i guess it depends if you have one that is supported by the mainline kernel without extra firmware
[11:47] <ogra_> JamieBennett, there is a console-conf that supports wlan setup from mwhudson that i havent found the time to try yet ...
[11:49] <JamieBennett> ogra_, OK, I don't think it is too much of an issue
[11:51] <ogra_> JamieBennett, well, apart from the fact that you cant create a user, yeah
[11:52] <ogra_> (no wifi support in console-conf ... no wired nic)
[11:52] <JamieBennett> ogra_, I bet that is possible with USB eth but yes, if is an issue but not for our RTM image
[11:53] <ogra_> if you have a supported USB eth key, yes ... else the image is completely unusable since you cant have a user to log in
[11:53]  * JamieBennett nods
[11:55] <ogra_> but all of this is moot ... we dont have a booting image at all yet
[11:56] <ogra_> mvo, gave me one that was created with a hacked up u-d-f that doesnt boot ... and the one i'm trying to create with ubuntu-image ends up with only one partition
[11:57] <JamieBennett> I saw Leo had something booting this morning, was that a different image?
[11:58] <ogra_> no idea what leo had
[11:58] <ogra_> all i got is unbootable stuff
[12:03] <ogra_> hmpf ... and for some reason ubuntu-image doesnt pull the latest gadget
[12:03] <ogra_> ah, now it does
[12:17] <ogra_> slangasek, hmm, i dont see any sgdisk call in ubuntu-image that would set the alignment ... the dragonboard needs an alignem,nt of 1 byte ... (i.e. the -a 1 option) if i remember that right ... http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/partitioner.sh and http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/parts.txt create a properly working GPT
[12:17] <jgdx> where's the "plugs" docs? I'm looking at https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/
[12:23] <JamieBennett> jgdx, http://snapcraft.io/docs/core/interfaces
[12:24] <ogra_> whee !
[12:24] <ogra_> Number  Start (sector)    End (sector)  Size       Code  Name
[12:24] <ogra_>    1            2048            4095   1024.0 KiB  FFFF  sbl1
[12:24] <ogra_>    2            4096            6143   1024.0 KiB  FFFF  rpm
[12:24] <ogra_>    3            6144            8191   1024.0 KiB  FFFF  tz
[12:24] <ogra_>    4            8192           10239   1024.0 KiB  FFFF  hyp
[12:24] <ogra_>    5           10240         7812466   3.7 GiB     FFFF  sec
[12:24] <ogra_> getting better :)
[12:24] <JamieBennett> nice
[12:24] <ogra_> (far from ggood but i end up with more than one partition)
[12:24] <jgdx> JamieBennett, sorry, more specifically, the plugs snapcraft.yml syntax docs
[12:24] <JamieBennett> hey, its progress ;)
[12:24] <jgdx> JamieBennett, and thanks!
[12:24] <ogra_> yeah :)
[12:25] <ogra_> but i still think the way u-image calls sgdisk is completely wrong
[12:25] <JamieBennett> jgdx, you mean the available interfaces i.e. plug and slots available to snapcraft?
[12:26] <JamieBennett> jgdx, that would be the interfaces that snapd exposes so in the snapd docs at `http://snapcraft.io/docs/reference/interfaces
[12:27] <jgdx> JamieBennett, right. Thanks
[12:27] <JamieBennett> jgdx, np
[12:28] <jgdx> JamieBennett, to insert one into the snapcraft.yml I guess I'll use http://pastebin.ubuntu.com/23145601/ ?
[12:30] <JamieBennett> jgdx, There are lots of examples in the playpen, let me pick one with plugs for you
[12:31] <JamieBennett> jgdx, https://github.com/ubuntu/snappy-playpen/blob/master/hexchat/snapcraft.yaml
[12:34] <jgdx> JamieBennett, cool, I'll look through those as well. Thank you
[12:41] <mup> PR snapd#1864 closed: overlord/snapstate: apply flags (devmode) on revert <Created by stolowski> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1864>
[12:45] <bull_> guys can we set source field in snapcraft file a launchpad branch ??
[12:48] <bulldog> can we set bzr branch as source in snapcraft ??
[13:16] <ogra_> SUCCESS !!! (nearly ... one little glitch left)
[13:16]  * ogra_ is looking at console-conf on an ubuntu-image built dragonboard image
[13:17] <ogra_> sadly no wlan config ... so i cant really test it ...
[13:17]  * ogra_ tries to find an USB NIC
[13:20] <abeato_> ogra_, I am seeing this error when executing apps in RPi3, I think caused by upgrading ubuntu-core today:
[13:21] <abeato_> runtime: this CPU has no floating point hardware, so it cannot run
[13:21] <abeato_> this GOARM=6 binary. Recompile using GOARM=5.
[13:21] <abeato_> ogra_, any idea why is this? afaik rpi3 has vfp unit
[13:21] <ogra_> abeato_, hmm, liuxg reported the same above ... weird
[13:21] <ogra_> abeato_, sounds like an issue with snapd ?
[13:21] <ogra_> mvo, ^^^^ any idea ?
[13:21] <abeato_> ogra_, probably, snapd is running though
[13:22] <ogra_> did you guys switch tio a newer go or some such ?
[13:22] <mvo> ogra_: uh
[13:22] <ogra_> abeato_, where diod you get that image ?
[13:22] <abeato_> ogra_, your image, refreshed
[13:22] <ogra_> (we dont really have any working pi3 image atm ... its all in flux this week)
[13:23] <ogra_> ooooh, i'm so happy !
[13:23] <ogra_> ogra@localhost:~$ uname -a
[13:23] <ogra_> Linux localhost.localdomain 4.4.0-1024-snapdragon #27-Ubuntu SMP Fri Aug 12 11:45:29 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux
[13:23] <ogra_> ogra@localhost:~$ snap list
[13:23] <ogra_> Name                Version       Rev  Developer  Notes
[13:23] <ogra_> dragonboard         16.04-0.15    18   canonical  -
[13:23] <ogra_> dragonboard-kernel  4.4.0-1024-2  8    canonical  -
[13:23] <ogra_> ubuntu-core         16.04.1       511  canonical  -
[13:24] <ogra_> ogra@localhost:~$
[13:24] <ogra_> JamieBennett, ^^^ getting there ;)
[13:24] <JamieBennett> :)
[13:24] <ogra_> (but needed an USB NIC indeed)
[13:28] <bulldog> ogra_, i need help
[13:29] <bulldog> plz check this snpcraft http://paste.ubuntu.com/23145789/
[13:30] <liuxg> ogra_, abeato_ yes, exactly, I do not know how to resolve the problem.
[13:34] <mvo> JamieBennett: who is building snapweb snaps currently? I get "runtime: this CPU has no floating point hardware, so it cannot run
[13:34] <mvo> this GOARM=6 binary. Recompile using GOARM=5."
[13:34] <mvo> JamieBennett: when I try to run it
[13:35] <jgdx> when ubuntu is upstream, what's the best way to manage the code so that it can be built as both deb and snap?
[13:35] <JamieBennett> mvo, did Steve used to get you to do them?
[13:36] <mvo> JamieBennett: he did but I think I did not do the latest, I figure it out, no worries
[13:37] <JamieBennett> mvo, we have justinmcp_ working on it now but I do not believe he has built the project or made any changes yet
[13:43] <tedg> So I have a snap that is in the store and says it is published on the edge channel, but it seems my local snapd can't install it.
[13:43] <tedg> I tried refreshing the login.
[13:43] <abeato_> ogra_, mvo, liuxg found a way to workaround the issue:
[13:43] <tedg> Not sure where to go next.
[13:43] <abeato_> sudo snap revert ubuntu-core
[13:43] <abeato_> sudo snap remove <snap>
[13:43] <abeato_> sudo snap install <snap>
[13:44] <abeato_> the interesting thing is that I found that when I was seeing the error I saw links in /snap/bin like
[13:44] <abeato_> lrwxrwxrwx 1 root root 13 Sep  7 13:04 command -> /usr/bin/snap
[13:44] <abeato_> and now I get the usual script defining all $SNAP env
[13:45] <abeato_> it looks like something goes wrong when installing with latest snap command?
[13:49] <sergiusens> Chipaca dholbach we have plenty of bugs for this, the store only recently started to support finer grained messages which we need to support
[13:49] <dholbach> ok, I see
[13:50] <mvo> cjwatson: we get errors for some snaps like "runtime: this CPU has no floating point hardware, so it cannot run
[13:50] <mvo> this GOARM=6 binary. Recompile using GOARM=5." has anything changed in LP recently when auto-building snaps?
[13:53] <cjwatson> mvo: https://lists.ubuntu.com/archives/ubuntu-devel/2016-July/039458.html would be the most obvious recent change
[13:54] <abeato_> mvo, cjwatson I do not think it is auto-building, it happens with my locally built snap
[13:54] <mvo> abeato_: oh, hm
[13:55] <abeato_> in my case the issue was triggered -I think- when ubuntu-core snap refreshed
[13:55] <abeato_> it is an error on installation
[13:55] <abeato_> weird links appear in /snap/bin instead of the usual scripts
[13:56] <cjwatson> mvo: maybe it's failing to read hwcap properly?
[13:56] <mvo> abeato_: the links are ok, that is a planned change
[13:56] <abeato_> hm.. but those just point to /usr/bin/snap
[13:57] <mvo> abeato_: yeah, `snap run hello-world` is the equivalent to /snap/bin/hello-world -> /usr/bin/snapd
[13:57] <abeato_> got it
[13:57] <mvo> cjwatson: hm, could be
[13:57] <mvo> abeato_: but it could still be releated to that change
[14:00] <mup> PR snapd#1865 opened: overlord/devicestate: POC to parametrise serial-request content/sending <Blocked> <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1865>
[14:06] <mvo> cjwatson: yeah, it looks like the hwcap set lacks HWCAP_VFP when it is running inside the confinement
[14:10] <cjwatson> missing apparmor access to /proc/self/auxv or something maybe?
[14:10] <cjwatson> (not sure if that makes sense)
[14:10] <mvo> cjwatson: it sounds very plausible, let me try
[14:13] <ogra_> JamieBennett, http://people.canonical.com/~ogra/snappy/all-snaps/all-snaps-dragonboard.img.xz in case you want to test
[14:13] <JamieBennett> ogra_, my dragonboard is with iftika now
[14:14] <mvo> jdstrand: help, we have a bit of a showstopper on the pi2 image: snap run snapweb
[14:14] <mvo> runtime: this CPU has no floating point hardware, so it cannot run
[14:14] <mvo> this GOARM=6 binary. Recompile using GOARM=5.
[14:15] <mvo> jdstrand: however - apparmor_parser -R /etc/apparmor.d/usr.lib.snapd.snap-confine
[14:15] <mvo> jdstrand: and its all working
[14:15] <ogra_> JamieBennett, excuses :P
[14:15] <mvo> jdstrand: I see no denials in the logs
[14:15] <mvo> jdstrand: I tried the suggestion from cjwatson to make /proc/self/auxv readable that seems to not have cut it :/
[14:16] <mvo> JamieBennett: -^ pi2 showstopper
[14:18] <shuduo> hello, i am working on pack a qml to be snap. I need add liboxideqtcore0 in stage-packages to support webview in qml. but my snap will exit since /snap/.../oxide-qt/chrome-sandbox is not owned by root but normal user same as my host. how i can install it with root?
[14:19] <ogra_> slangasek, so i have everything working with the dragonboard using ubuntu-image, but the partitioning is pretty wasteful, for the next release we should go over how sgdisk is used in ubuntu-image and see if we can not make that more elegant
[14:22] <roadmr> hey folks, has anybody tried the rocketchat-server snap? I installed it and get a 404 when going to http://localhost:3000, sure I'm doing something wrong but there aren't many knobs to tweak
[14:23] <jdstrand> mvo: this sounds familiar... tyhicks, does that ring a bell? ^
[14:24] <jdstrand> mvo: did you disable rate limiting?
[14:24] <jdstrand> mvo: sudo sysctl -w kernel.printk_ratelimit=0
[14:26] <jdstrand> mvo: can you show me the rule you added?
[14:27] <mvo> jdstrand: I added     /proc/self/auxv r,
[14:27] <jdstrand> mvo: this is the rule you want: @{PROC}/@{pid}/auxv r,
[14:28] <jdstrand> mvo: /proc/self is a symlink
[14:28] <jdstrand> tyhicks: if it doesn't ring a bell, that is fine
[14:29] <jdstrand> I think we saw this with java...
[14:29] <mvo> jdstrand: http://paste.ubuntu.com/23146014/ - not quite it seems
[14:29] <jdstrand> mvo: is this for wnapweb or snap-confine?
[14:29] <mvo> jdstrand: all golang apps it seems
[14:30] <sergiusens> nap-web, I like that
[14:30] <ogra_> +1 !
[14:30] <jdstrand> snap-confine is not golang
[14:30] <jdstrand> mvo: let's backup
[14:30] <mvo> jdstrand: actually I'm not really sure what is going on
[14:30] <mvo> jdstrand: yeah
[14:30] <mvo> jdstrand: so - since very recently we have this issue that when I run a golang app on the pi2 I get the above error
[14:30] <jdstrand> mvo: can you do 'sudo sysctl -w kernel.printk_ratelimit=0'
[14:30] <ogra_> sergiusens, nap-web but only after snap-confect !
[14:31] <mvo> jdstrand: I did that when you put it in
[14:31] <jdstrand> mvo: then, can you tell me if hello-world works
[14:31] <jdstrand> ok
[14:31] <mvo> jdstrand: eh, when you wrote it some minutes ago
[14:31] <shuduo> kyrofa, ping
[14:31] <mvo> jdstrand: http://paste.ubuntu.com/23146021/
[14:32] <mvo> jdstrand: the sequence is now: "snap run" (unconfined) -> "snap-confine" -> snap-exec (golang!)
[14:32] <jdstrand> mvo: ok. so, snap run is not confined
[14:32] <tyhicks> jdstrand: hmm... that doesn't ring any bells for me
[14:32] <jdstrand> mvo: isn't snap run also golang?
[14:32] <mvo> jdstrand: so it might be that this is a bug we had for a longer time but now because we use snap-exec (golang) to actually launch its manifesting itself more
[14:32] <mvo> jdstrand: it is, snap run is golang but unconfined
[14:32] <mvo> jdstrand: and the snap-exec step is then confined
[14:33] <jdstrand> mvo: can you paste syslog?
[14:33] <mvo> jdstrand: http://paste.ubuntu.com/23146025/ is strace
[14:33] <jdstrand> ok, so it is snap-exec
[14:34] <kyrofa> shuduo, pong
[14:34] <jdstrand> oh I think I remember what this is
[14:34] <jdstrand> I think there is an env var that is getting stripped out
[14:34] <shuduo> hello kyrofa, i am working on pack a qml to be snap. I need add liboxideqtcore0 in stage-packages to support webview in qml. but my snap will exit since /snap/.../oxide-qt/chrome-sandbox is not owned by root but normal user same as my host. how i can install it with root?
[14:34] <jdstrand> mvo: can you paste me the updated snap-confine profile?
[14:35] <mvo> jdstrand: http://paste.ubuntu.com/23146034/
[14:35] <kyrofa> shuduo, jdstrand might have some suggestions for working with that sandbox. I suspect it will be to disable it
[14:35] <zyga> hey
[14:35] <zyga> anything I can help with?
[14:35] <kyrofa> shuduo, and use snappy's instead
[14:35] <zyga> jdstrand, mvo: anything at all?
[14:36] <jdstrand> kyrofa, shuduo: morphis just brought this up in another channel
[14:36] <jdstrand> shuduo: are you part of an email thread on that?
[14:37] <tyhicks> jdstrand: I don't know exactly when the env var would be getting stripped out but I should you remind you that the non-secureexec change_profile syntax was backported to xenial - let me know if/when you want details on that
[14:37] <shuduo> jdstrand: hi, i don't think i'm in th thread since I just search my email and lp to look for if someone meet this issue
[14:37] <shuduo> jdstrand: does that mean no solution right now?
[14:37] <jdstrand> shuduo: the short answer is that you need to disable using the setuid sandbox
[14:38] <tyhicks> (the non-secureexec change_profile syntax is bug 1584069)
[14:38] <mup> Bug #1584069: change_profile rules need a modifier to allow non-secureexec transitions <aa-parser> <aa-tools> <verification-done> <AppArmor:Fix Committed by tyhicks> <apparmor (Ubuntu):Fix Released by tyhicks> <apparmor (Ubuntu Xenial):Fix Committed by tyhicks> <https://launchpad.net/bugs/1584069>
[14:38] <jdstrand> shuduo: I'm not sure how to do that in oxide. chrisccoulson, is there an env var to set?
[14:38] <shuduo> jdstrand: hmm, how? sorry i don't have many knowledge here.
[14:39] <jdstrand> shuduo: chrisccoulson should be able to say
[14:40] <chrisccoulson> jdstrand, OXIDE_NO_SANDBOX=1, but this shouldn't be used by production code (and environment variables aren't considered to be part of the stable API either - they're only really there for testing purposes)
[14:41] <jdstrand> mvo: can you get the apparmor for xenial-proposed, then do: 's/change_profile/change_profile unsafe/' in snap-confine's profile?
[14:41] <jdstrand> mvo: that is to test my hypothesis about it being a stripped variable
[14:42] <jdstrand> mvo: I'm not sure that is the fix though
[14:42] <mvo> jdstrand: so a new apparmor? from xenial-proposed? sure
[14:42] <jdstrand> mvo: 2.10.95-0ubuntu2.2 in xenial-proposed
[14:43] <shuduo> chrisccoulson: so will "command: OXIDE_NO_SANDBOX=1 desktop-launch $SNAP/usr/lib/*/qt5/bin/qmlscene $SNAP/Main.qml" work?
[14:43] <zyga> jdstrand, mvo: please ensure that the patch ends up in snap-confine master too
[14:44] <jdstrand> chrisccoulson: so, the problem is that we can't safely support the setuid sandbox due to the issues you already know about
[14:44] <jdstrand> chrisccoulson: ie, all the capabilities, etc
[14:44] <chrisccoulson> shuduo, yes, although it means you get no renderer sandbox
[14:44] <jdstrand> chrisccoulson, shuduo: but the application is already sandboxed
[14:44] <jdstrand> via snappy
[14:45] <jdstrand> electron apps for example don't use the renderer sandbox
[14:46] <mvo> jdstrand: this is actually a bit tricky, this is on an all-snap image on the pi2, so installing a snap is tricky, but I can unpack the deb and scp it
[14:46] <jdstrand> I don't think oxide apps should either while we are in the state we are in wrt snappy policy and oxide sandboxing
[14:46] <shuduo> chrisccoulson: sorry what means "get no rendere sandbox"? i need webview to draw a webpage with webgl objects...
[14:46] <jdstrand> shuduo: it will work. he is saying this disables an internal sandboxing technique
[14:47] <shuduo> jdstrand: great. my snap is for demo purpose only. :)
[14:47] <jdstrand> shuduo: I'm not sure where in the 'command' line you should put the env var, but so long as it is set, oxide should work in strict mode
[14:48] <jdstrand> mvo: I suspect you will need libapparmor and apparmor
[14:49] <tyhicks> mvo, jdstrand: you don't need apparmor from -proposed
[14:49] <jdstrand> actually, yes, I was just going to say that
[14:49] <jdstrand> this was in 2.2 which is in updates now
[14:49] <tyhicks> mvo, jdstrand: 2.10.95-0ubuntu2.2  from -updates is good enough
[14:49] <tyhicks> ok
[14:49]  * jdstrand was confused by the bug being Fix Committed still
[14:49] <kgunn> dpm: hey is this still the only/preferred way to pick arch in snaps
[14:49] <kgunn> http://pastebin.ubuntu.com/23146088/
[14:50] <jdstrand> mvo: right, so, skip getting a new apparmor and just add 'unsafe' as I described
[14:51]  * jdstrand is also wondering why there isn't a 'snap-exec' rule in the snap-confine policy. is it just forked and not execd?
[14:51] <mvo> jdstrand: its execed
[14:51] <tyhicks> (not sure why the bug status didn't update automatically - I've fixed it)
[14:52] <jdstrand> I have to look at how snap-exec is doing its thing again, clearly
[14:52] <mvo> jdstrand: AppArmor parser error for /tmp/usr.lib.snapd.snap-confine in /tmp/usr.lib.snapd.snap-confine at line 60: Exec condition is required when unsafe or safe keywords are present
[14:52] <mvo> jdstrand: am I doing something wrong?
[14:52] <dpm> kgunn, it's still the only way afaik, yes
[14:53] <kgunn> cool
[14:55] <tyhicks> mvo, jdstrand: you want 's/change_profile/change_profile unsafe \/**/'
[14:55] <zyga> mvo: can I help in any way?
[14:55] <jdstrand> mvo: perhaps not. I think use 'change_profile unsafe /** -> ...'
[14:55] <jdstrand> tyhicks: is /** needed with the change_profile rule?
[14:55] <mvo> jdstrand: \o/ works
[14:55] <mvo> zyga: maybe, not yet
[14:55] <mvo> zyga: looks like jdstrand found the right magic
[14:55] <mvo> jdstrand: I guess this is not a permanent solution :) please help me understand what magic you are doing
[14:55] <zyga> mvo: I understand we landed the run/exec branch now
[14:55] <zyga> and this is the fallout?
[14:55] <jdstrand> tyhicks: yes, we got there. the question I had was if '/**' was needed (and curious why)
[14:55] <mvo> jdstrand, tyhicks: http://paste.ubuntu.com/23146105/ works
[14:56] <tyhicks> jdstrand: it is needed but I'll have to dig through the mailing list archive to remember exactly why
[14:56] <jdstrand> mvo: right, so this rule works because we are ensuring the secure exec bit is not set which makes sure the env var I was talking about that go runtime needs isn't cleared
[14:56] <jdstrand> tyhicks: it isn't important
[14:56] <zyga> FYI, I'm tracking this as https://bugs.launchpad.net/snap-confine/+bug/1621127
[14:56] <mup> Bug #1621127: snap-confine doesn't work with new snap-run/snap-exec flow <Snappy Launcher:In Progress> <https://launchpad.net/bugs/1621127>
[14:57] <shuduo> jdstrand, chrisccoulson i add OXIDE_NO_SANDBOX=1 before desktop-launch but snapcraft will report error "The specified command 'OXIDE_NO_SANDBOX=1' defined in the app 'Remote3DP' does not exist or is not executable                                                            1
[14:58] <mvo> jdstrand: aha, I remember this one too now, we had this issue before
[14:58] <jdstrand> shuduo: right, maybe add it after desktop-launch? I'm not really sure on that part. perhaps kyrofa or another snapcrafter can advise how to set arbitrary env vars
[14:58] <jdstrand> mvo: iirc, it came up wrt webdm, but memory is hazy
[14:58] <tyhicks> mvo: yes, I implemented this at your request :)
[14:58] <kyrofa> shuduo, yeah we're working on adding environment keys to the YAML, but until then really your only option is to create a wrapper to use for your app
[14:58] <mvo> tyhicks: ha!
[14:58] <kyrofa> (that sets the variable)
[14:59] <tyhicks> mvo: you ended up not needing it but I was stubborn and saw it through upstreaming and SRU'ing
[14:59] <tyhicks> mvo: good thing I'm stubborn :)
[14:59] <jdstrand> indeed
[14:59] <mvo> jdstrand, tyhicks: so that is the answer? we change the profile in the way described in the pastebin?
[14:59] <shuduo> kyrofa: understood. i will do it. thanks.
[14:59] <mvo> tyhicks: yeah, you are a HERO
[14:59] <mvo> tyhicks: (no kidding!)
[14:59] <jdstrand> mvo: possibly. I want to investigate
[14:59] <mvo> tyhicks: this was a serious last-minute showstopper
[14:59] <jdstrand> tyhicks: I will likely need to run something by you after I investigate
[15:00] <tyhicks> jdstrand: ack
[15:00] <jdstrand> mvo: apply it now if it is blocking the world
[15:00] <mvo> jdstrand: thanks
[15:00] <mvo> and thanks to tyhicks
[15:00] <cjwatson> sergiusens: re https://github.com/snapcore/snapcraft/pull/726, cprov and I were thinking that perhaps the integration test for register-key should just skip if a sufficient version of snapd isn't available (e.g. for distributions without snapd).  Do you think that's reasonable and safe, or would you rather that it failed?
[15:00] <mup> PR snapcraft#726: Implement basic form of `snapcraft register-key` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/726>
[15:00] <tyhicks> np!
[15:00] <mvo> jdstrand: in a meeting right now, but will do after the meeting
[15:00] <jdstrand> mvo: but can you point me at how how snap run/confine/exec is working?
[15:00] <jdstrand> mvo: source code is fine
[15:01] <mvo> jdstrand: you can play with the latest image, code is cmd/snap/cmd_run.go
[15:01] <jdstrand> (and even preferred :)
[15:01] <sergiusens> cjwatson I will defer that to elopio
[15:01] <mvo> jdstrand: but its essentially just snap run reads all the yaml, calls snap-confine with the right security-tag which runs snap-exec
[15:02] <jdstrand> mvo: it's that last bit that is throwing me
[15:02] <sergiusens> cjwatson is it just to avoid bit rot on your branch?
[15:02] <elopio> cjwatson: seems ok. We can make sure that snapd is in jenkins, so it will run for us.
[15:02] <mvo> jdstrand: and cmd/snap-exec/main.go
[15:02] <mvo> jdstrand: what last bit? snap-exec?
[15:02] <jdstrand> because I don't see an 'x' rule for snap-exec
[15:02] <jdstrand> I want to understand that
[15:02] <mvo> jdstrand: oh, ok. is http://paste.ubuntu.com/23146025/ helpful? shows the full flow
[15:03] <jdstrand> mvo: will this get me the 'latest image' you are referring to? sudo /snap/bin/ubuntu-device-flash core --size=8 --enable-ssh --channel=edge --output=snappy-20160831-amd64.img --gadget pc --kernel pc-kernel --os ubuntu-core 16
[15:03]  * jdstrand would use a different date of course
[15:03] <sergiusens> cjwatson merging this would make us unreleasable though as snapd might be stuck there forever so maybe a runtime check instead of a packaging dependency would help a lot
[15:04] <jdstrand> mvo: that paste will be handy, yes
[15:04] <zyga> mvo: one question: the pastebin flow above shows that we run ubuntu-core-launcher first, didn't we want to run snap-confine directly and remove u-c-l executable?
[15:04] <jdstrand> mvo: as for after your meeting, please add a comment on why we are using 'unsafe' and please ping me for the review
[15:04] <mvo> jdstrand: uploading you the latest image to https://people.canonical.com/~mvo/all-snaps/16, will take ~5min or so
[15:04] <mvo> jdstrand: u-d-f is currently a bit outdated
[15:05] <mvo> zyga: yes, we just need to do that
[15:05] <jdstrand> mvo: I'll want all-snaps-pc.img.xz?
[15:05] <zyga> mvo: noted, I was just unsure if anything changed mid-way
[15:06] <mvo> zyga: if you want to help, you can prepare a new snap-confine for the ppa with http://paste.ubuntu.com/23146105/ and a comment why its needed
[15:06] <zyga> mvo: already on it
[15:06] <mvo> jdstrand: yes, its still uploading, ~4min eta
[15:06] <mvo> zyga: \o/
[15:06] <jdstrand> zyga: please ping me for the PR
[15:07] <zyga> jdstrand: sure
[15:08] <cjwatson> sergiusens: well, if the integration test skipped dynamically if it didn't have a new enough snapd, then it wouldn't block you, it's just that register-key wouldn't be guaranteed to work
[15:09] <ackk> hi, when trying to install a snap I created with snapcraft I get the following error: "cannot find signatures with metadata for snap", am I missing something?
[15:12] <mup> Bug #1621132 opened: Porting guide is out of date <Snappy:New> <https://launchpad.net/bugs/1621132>
[15:12] <mvo> jdstrand: its there now
[15:13] <sergiusens> cjwatson snapd is being unblocked now; my worries is for when I was going to dput and then get stuck on -proposed :-)
[15:13] <mvo> slangasek: is there a way to trigger an autopkgtest to run asap? I had a failure on yakkety because of a git clone gateway timeout :/ and would love to retrigger asap to see results
[15:13] <slangasek> mvo: the update_execuses.html page has a 'retry' button for failed tests if that's what you need
[15:14] <slangasek> mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd the 'recycle' icon :)
[15:15] <slangasek> ogra_: what's currently "not great" with console-conf on serial? are there open bug reports about this?
[15:15] <jdstrand> mvo: thanks
[15:17] <mvo> slangasek: \o/
[15:17] <slangasek> mvo, ogra_: wrt signed model assertions, where are we going to get these for the reference images we're building on cdimage infra?
[15:17] <ogra_> slangasek, mvo should be able to give them to you
[15:17] <mvo> slangasek: they will be available from the assertion "store", but I can forward you the ones we have
[15:17] <mvo> slangasek: once we have news, the pc one is currently re-done
[15:18] <zyga> mvo: how do you want the snap-confine change? debdiff? dput to the repo?
[15:18] <zyga> jdstrand: ^^ along how do you want the review
[15:18] <slangasek> "assertion store"> I guess that's not something I have a good interface for querying right now as part of image builds
[15:18] <zyga> jdstrand: I think debdiff is easiest here unless there's a repo that I don't know about
[15:18] <mvo> zyga: debdiff for final review from jdstrand and then dput I think
[15:19] <mvo> zyga: but debdiff is fine, I can do the rest
[15:19] <mvo> zyga: thank you, that helped me a lot
[15:19] <ogra_> slangasek, i thought i had filed one ... but seems i'm wrong
[15:19] <zyga> http://paste.ubuntu.com/23146292/
[15:19] <shuduo> chrisccoulson: after i export OXIDE_NO_SANDBOX=1 in wrapper script and repack my snap. now it reports "[0907/231547:ERROR:browser_main_loop.cc(231)] Running without the SUID sandbox! See https://chromium.googlesource.com/chromium/src/+/master/docs/linux_suid_sandbox_development.md for more information on developing with the sandbox on.
[15:19] <slangasek> ogra_: ok, please file so we know what we're asked to fix :)
[15:19] <zyga> that's the debdiff
[15:19] <zyga> mvo, jdstrand: ^^
[15:19] <chrisccoulson> shuduo, yes, that's expected
[15:20] <shuduo> chrisccoulson: and no app window show up...
[15:20] <chrisccoulson> that's a separate issue
[15:20] <chrisccoulson> Oxide won't be responsible for an app window not showing up
[15:21] <slangasek> mvo: OOI, why is extra-snaps an option to prep-image rather than part of the model assertion?
[15:22] <ogra_> slangasek, it would help ifr LP knew about the subiquity package :)
[15:22] <ogra_> "subiquity" does not exist in Ubuntu. Please choose a different package. If you're unsure, please select "I don't know"
[15:22] <mvo> slangasek: its fine to add extra snaps that are not strictly needed by the model assertion, i.e. we install snapweb on our images but its fine to build a image without it
[15:23] <ogra_> (i clicked the "report a bug" link on https://bugs.launchpad.net/ubuntu/+source/subiquity
[15:23] <ogra_> )
[15:23] <slangasek> ogra_: <blink> I know subiquity is no longer in the NEW queue, I assumed somebody had accepted it rather than rejecting it...
[15:25] <mvo> jdstrand: does http://paste.ubuntu.com/23146292/ look ok? I guess the first @{PROC}/@{pid}/auxv r, is not really needed (?)
[15:25] <slangasek> cyphermox: do you know why subiquity 0.0.9 was rejected?  can't find the reject comment in the history in LP
[15:25] <slangasek> cyphermox: and if there was a valid reason for rejecting, can you upload a new version so we can put this "no package in Ubuntu" thing to bed
[15:31] <zyga> jdstrand, mvo: please ping me if you need me to dput this into the PPA
[15:38] <ogra_> slangasek, it works if i file it against snappy and open a task for subiquity ... bug 1621142
[15:38] <mup> Bug #1621142: no "please press enter" message shown on serial console <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621142>
[15:38] <Fl1nt> Hi folks!
[15:38] <jdstrand> mvo: I don't know if the auxv is needed any more. I don't think so cause snap-confine shouldn't need it itself, but not sure of how snap-exec is working yet
[15:38] <eul0gy^> hi
[15:39] <cjwatson> ogra_: don't assume that that hack will keep on working
[15:39] <mup> Bug #1621142 opened: no "please press enter" message shown on serial console <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621142>
[15:39] <ogra_> cjwatson, i assume that subiquity will be known by LP before it stops working :)
[15:39] <cjwatson> ogra_: we'll probably be closing the weird partial loophole where you can sometimes open tasks against packages that only exist in PPAs as part of a project to close a security hole
[15:40] <ogra_> cjwatson, today ?
[15:40] <cjwatson> no
[15:40] <ogra_> good :)
[15:40] <cjwatson> when I finish the complicated code :P
[15:40] <jdstrand> zyga (cc mvo): there is no comment in there. Please use: # NOTE: use 'unsafe /**' to disable secure exec environment scrubbing
[15:41] <jdstrand> zyga (cc mvo): # This is currently required by snap-exec
[15:41] <slangasek> ogra_: yes, that indeed works :/
[15:41] <cjwatson> ogra_: just taking the opportunity to warn people occasionally since I suspect it may cause some consternation when we start disallowing this
[15:41] <mvo> jdstrand, zyga: will do and (re)upload
[15:42] <mup> Bug #1621144 opened: serial console is not cleared before console-conf runs <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621144>
[15:42] <cyphermox> slangasek: it had various issues; I'll reupload
[15:42] <slangasek> cyphermox: thanks
[15:42] <ogra_> cjwatson, well, as long as it works right now i'm fine ... i normally dont use that :)
[15:44] <mvo> jdstrand, zyga: added and uploaded
[15:44] <bulldog> hey , i have a question
[15:44] <bulldog> can an application packed in snap make call to /usr/bin ??
[15:45] <jdstrand> mvo: did you remove the auxv access?
[15:45] <Fl1nt> I don't think so as snaps are self contained apps isolated, but I'm far from being an expert bulldog
[15:45] <bulldog> like if my program want to call other program installed on user system,
[15:46] <bulldog> Fl1nt, it should but it is not calling
[15:46] <ogra_> slangasek, three new bugs for you :)
[15:47] <bulldog> if snap apps wont able to do that, that will break lots of apps and wont allow programs to call other programs and utils which some apps may use
[15:47] <zyga> jdstrand: ack, do you want me to remove the auxv line while I'm at it, I noticed that mvo asked about
[15:47] <zyga> ah, I see that mvo already picked it up
[15:48] <mup> Bug #1621147 opened: no way to configure wifi SSID and passphrase <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1621147>
[15:48] <bulldog> guys fox example my app want call gsetting to change wallpaper or theme of users system how can a snap app can call gsetting ???
[15:48] <kyrofa> bulldog, no blanket access to /usr/bin, but there are some utilities available there
[15:48] <mvo> zyga: yeah, but if you could ensure this all goes into upstream git, that would rock
[15:49] <Fl1nt> bulldog: oh, I see you call an unsnapped app ?
[15:49] <bulldog> kyrofa, what you mean by   but there are some utilities available there?
[15:49] <bulldog> Fl1nt, yes lots of apps do this
[15:50] <kyrofa> bulldog, there's an explicit whitelist of things you can call, e.g. awk and so on
[15:50] <kyrofa> bulldog, gsettings is unknown territory for me though, so I'll let someone else answer that
[15:50] <bulldog> how you use grep, ls , bash, or anything which a developer can  use in their app to extend functionality
[15:50] <kyrofa> didrocks maybe
[15:50] <zyga> mvo: I will, I'm tracking this
[15:51] <kyrofa> bulldog, yeah, those are also whitelisted
[15:51] <mvo> zyga: thanks again!
[15:51] <zyga> kyrofa, bulldog: apparmor will soon be able to control gsettings but the precise value of soon is unknown to me
[15:51] <bulldog> kyrofa, this should not be just few list of apps
[15:51] <Fl1nt> bulldog: well, in this case I'm sorry, I'm trying to be 100% committed on snaps and so using the plugs :D
[15:51] <didrocks> bulldog: there are some example of wallpaper changing using gsettings even!
[15:52] <slangasek> ogra_: thank you!
[15:52] <ogra_> and two for ubuntu-image
[15:52] <shuduo> chrisccoulson, jdstrand, kyrofa add env var in wrapper, install with devmode, it works now. its snapcraft.yaml is refer to 2048 of playgen. i guess still need other plug to run in strict mode.
[15:52] <bulldog> didrocks, all wallaper changing apps do this by calling gsetting
[15:52] <bulldog> didrocks, all wallaper changing apps do this by calling gsettings
[15:53] <didrocks> here is an example for an icon theme changing https://github.com/ubuntu/snappy-playpen/tree/master/ubuntukylin-icon-theme
[15:53] <didrocks> using the desktop-launcher, it's quite easy to get it working
[15:53] <bulldog> Qprocess in qt look into /usr/bin to exec apps under linux
[15:54] <bulldog> didrocks, that's different thing ,
[15:54] <didrocks> bulldog: it's not, you ship some files, then call gsettings
[15:54] <bulldog> didrocks, do you want programmers to program their app snap way ??
[15:54] <mup> Bug #1619729 changed: ubuntu-image (or snapd) does not set snap_kernel and snap_core anymore in created images <Snappy:Invalid by mvo> <Ubuntu Image:Invalid> <https://launchpad.net/bugs/1619729>
[15:54] <didrocks> see the "set" command
[15:54] <bulldog> thousands of developers will not do that by taking snap in mind
[15:54] <didrocks> bulldog: gsettings wasn't prommed "snappy way"
[15:55] <didrocks> programmed*
[15:55] <didrocks> AFAIK
[15:55] <zyga> bulldog: you should be able to use gsettings in dev mode, all writes go over dbus AFAIK
[15:55] <zyga> bulldog: reading is done by mmaping the file, this might be a different story
[15:55] <didrocks> even in non devmode, it's working in the above example ^
[15:55] <bulldog> didrocks, i have app deskie which uses qt standards , and work fine on normal .deb install
[15:55] <zyga> bulldog: the long story short is that gsettings support is in progress but it's not available yet
[15:56] <didrocks> for both reading and writing
[15:56] <bulldog> while , with snap it look for gsettings which i stagged to be available in $SNAP but it wont do anything
[15:57] <didrocks> bulldog: I give you an example above with the correct wrapper and plugs to have it working even in non devmode
[15:57] <didrocks> please give it a try
[15:57] <bulldog> zyga, my concerns are not only about gsettings man'\
[15:57] <ogra_> slangasek, to create an i386 pc gadget, can i just copy the content from generic-amd64 ? or will that explode ?
[15:57] <bulldog> my question is why /usr/bin access is blocked ??
[15:57] <ogra_> i suspect we need a different binary and no shim ?
[15:58] <zyga> bulldog: because the content of that is unpredictable and it may not be universally available
[15:58] <bulldog> if user want program do things why a packing format want him to stop him ?
[15:58] <slangasek> ogra_: not different binary, pc grub is pc grub.  Copy, strike the UEFI, and done.  Do we care about non-GPT-friendly i386 BIOSes? probably not
[15:58] <zyga> bulldog: so the snap you create will not work everywhere which is the idea with snaps
[15:58] <zyga> bulldog: don't depend on stuff in /usr/bin, ship it
[15:59] <bulldog> zyga, oh
[15:59] <mvo> slangasek: fgimenez verfied #1618095 now, so if we could get an unblock even though autopkgtest is unahppy, that would be much appreciated
[15:59] <mup> Bug #1618095: [SRU] 2.14.2 <verification-done> <Snappy:New> <snapd (Ubuntu):New> <snapd (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1618095>
[15:59] <bulldog> didrocks, plz explain your way to access gsettings
[16:00] <ogra_> slangasek, i heard about uboot i386 requirements in the past ... not sure thats still a thing ... and surely not for now :)
[16:02] <bulldog> zyga, gsettings should be directly connected to system bus, right now if you will pack unity tweak tool in snap format it will not work :D
[16:02] <zyga> bulldog: gsettings is an application linked to glib, it uses a certain "protocol" or "interface" to read and to write key/values; as long as the protocol is stable you can bundle the required library and do the exact same thing (or even implement it in a compatible way separately)
[16:02] <ackk> hi, what can be causing snap install to fail with "cannot find signatures with metadata for snap"?
[16:02] <zyga> bulldog: gsettings, AFAIK (I could be wrong) uses mmap to read and dbus to write values
[16:02] <bulldog> zyga, it will write and read data but wont change anything in real world
[16:02] <slangasek> ogra_: uboot i386 would be separate from the i386 pc gadget
[16:03] <ogra_> yeah, definitely
[16:03] <zyga> bulldog: dbus traffic to the session bus is controlled by apparmor, the file that gsettings tries to read is derived from $HOME which is remapped by snappy
[16:03] <zyga> bulldog: I don't know more details but this might explain why things don't work the way you expect
[16:04] <zyga> bulldog: the short term story is that gsettigns cannot be "allowed" because of how the API looks like (the decision if something is safe or not is not at an API level but at an argument level); we are working with gsettings upstream to add mediation points so that apparmor can be used to say "this application can read this gsettings value/tree" or "that application can change the background by writing to
[16:04] <bulldog> zyga, when app is not packed with snap , it simply calls /usr/bin/gsettings with args to do things , same happen with snap pack but it changes settings within the container , and do not affect ubuntu desktop
[16:04] <zyga> this gsettings path"
[16:05] <zyga> bulldog: snaps run under confinement, this means that certain things are not allowed without an appropriate interface
[16:05] <ogra_> slangasek, hmm, if i kill the EFI,i still want to keep a system-boot vfat to carry grub.cfg, should that be named not EFI then ?
[16:05] <bulldog> zyga, is there any interface yet to allow call gsettings ?
[16:05] <zyga> bulldog: when the gsettings improvement is in place applications will be able to use it as they did before, assuming the desired interactions are safe, for other interactions appropriate interfaces will have to be created
[16:06] <zyga> bulldog: no, because it requires upstream work in gsettings itself and that has not been finished yet
[16:06] <zyga> bulldog: people are working on this
[16:06] <bulldog> okay
[16:06] <bulldog> ty
[16:06] <slangasek> mvo: snapd> promoting, thanks!
[16:06] <bulldog> zyga, wait i have one more question
[16:06] <zyga> bulldog: interface creation is easy but right now there's no language to control which part of gsettings tree can be accessed
[16:06]  * jdstrand notes there is a gsettings interface. it allows access to the global database. iirc one of the desktop parts makes that work right
[16:07]  * zyga has deep desire to have a snap that can change backgrounds :)
[16:07] <zyga> jdstrand: oh, I didn't remember this; thanks
[16:07] <jdstrand> this interface is one of the transitional ones
[16:07] <jdstrand> but you are right, proper app-isolated gsettings mediation is coming
[16:08] <slangasek> mvo: wrt the snapd autopkgtest failures, I've only overridden with a 'force-skiptest' hint; that means other packages which snapd depends on (snap-confine), and which trigger failing autopkgtest runs, will also need to be manually resolved for now
[16:08] <bulldog> zyga, i developed gui for snapcraft , which normally call /usr/bin/snapcraft , usr/bin/snap to do tasks , will it work after packaging in snap format ???
[16:08] <jdstrand> and when it is available we will encourage people to use it instead of the global one
[16:08] <bulldog> zyga, check out deskie wallpaper changer app :)
[16:09] <zyga> bulldog: no, for the reason I outlined above, please talk to sergiusens about a possible content interface or a "snapcraft part" or another idea that would let you do this reliably and predictably
[16:09] <bulldog> zyga, www.ktechpit.com/deskie-wallpaper-changer-ubuntu-linux/‎
[16:09] <zyga> bulldog: thanks, I will - I have some photos I took I want to release as a content snap
[16:10] <bulldog> zyga, deskie get thousands of images online and let you set them as wallpaper on your request
[16:11] <bulldog> https://github.com/keshavbhatt/Deskie
[16:11] <zyga> I need to get back to snap-confine
[16:11] <zyga> bulldog: if you have any questions feel free to ask here or on the mailing list
[16:11] <roasted> possibly a dumb question, but I'm curious -- say you have a .deb built for 14.04. When attempting to install on 16.04, it cites 5 missing deps (not in repos). The .deb in question is not open source. In theory, if one really wanted, could you (somehow) take that .deb, add the missing deps, and somehow snap it? Or is that crazy talk?
[16:12] <bulldog> it is powerful then variety and uses less ram :D
[16:12] <zyga> roasted: yes, though some things may require extra work because of the snap filesystem layout
[16:12] <bulldog> roasted, yes
[16:12] <cjwatson> sergiusens: OK, yeah, with snapd released to -updates now, maybe the integration test hack isn't necessary
[16:13] <bulldog> zyga, plz check this out my 14 days work :) https://github.com/keshavbhatt/snapcraft-gui
[16:13] <ogra_> slangasek, http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/revision/90 please take a look ... if you think thats ok i'll roll a gadget and push to the store
[16:38] <kyrofa> bulldog, is it really ppa:keshavnrj/snpacraft-gui ?
[16:41] <bulldog> kyrofa, yes
[16:41] <bulldog> no :D
[16:41] <bulldog> wait
[16:41] <kyrofa> ;)
[16:41] <kyrofa> Sorry, couldn't resist
[16:42] <bulldog> damn
[16:43] <bulldog> kyrofa, i misspelled it :(
[16:43] <bulldog> yes it is  ppa:keshavnrj/snpacraft-gui
[16:43] <bulldog> you can get it from there , i have to fix it now :D
[17:00] <cjwatson> sergiusens: could you rerun the travis test in https://github.com/snapcore/snapcraft/pull/726 ?
[17:00] <mup> PR snapcraft#726: Implement basic form of `snapcraft register-key` <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/726>
[17:01] <josepht> cjwatson: you can do it as well by typing a comment with "retest this please" in it
[17:02] <cjwatson> josepht: oh, that works for anyone?  thanks
[17:02] <cjwatson> done
[17:02] <cjwatson> sergiusens: ^- never mind
[17:02] <josepht> cjwatson: I'm not sure about everyone, but it does for the PR author
[17:04] <kyrofa> josepht, I thought that just was the jenkins stuff
[17:06] <cjwatson> I'm not seeing a fresh build on https://travis-ci.org/snapcore/snapcraft/pull_requests as yet
[17:10] <josepht> elopio: do you know what's going on here?  ^
[17:16] <sergiusens> josepht cjwatson retest is just for jenkins, I'll trigger the retest of travis
[17:19] <josepht> sergiusens: oh, sorry cjwatson.  Ignore me
[17:21] <mup> PR snapd#1828 closed: cmd/snap,client: add snap set and snap get commands <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1828>
[17:22] <bulldog> tarvis is like launchpad remote building system ??
[17:22] <bulldog> wow
[17:22] <bulldog> :D
[17:23] <bulldog> *travis
[17:24] <bulldog> made in Germany :)
[17:36] <arges> hi. upgraded to snapd 2.14.2~16.04 and now when trying to install my local snap I get 'error: cannot find signatures with metadata for snap' any suggestions?
[17:43] <zyga> arges: try snap install --dangerous
[17:43] <zyga>           --dangerous  Install the given snap file even if there are no pre-acknowledged signatures for it, meaning it was
[17:43] <zyga>                        not verified and could be dangerous (--devmode implies this)
[17:45] <bulldog> zyga, how we sign a snap ??
[17:46] <bulldog> i mean what  signatures we talking about ?
[17:51] <arges> zyga: thanks
[17:51] <arges> zyga: that doesn't work on xenial
[17:53] <arges> zyga: --force-dangerous
[17:53] <zyga> hhh
[17:54] <zyga> arges: hmm, it does for me but perhaps I just ran master without checking
[17:54] <zyga> bulldog: just by uploading it to the store
[17:54] <bulldog> oh :) but he is trying local snaps he said
[17:56] <zyga> bulldog: then you have to use that option
[17:56] <bulldog> okay :) thanks
[18:00] <bulldog> am learning travis-ci :D
[18:28] <bulldog> guys snapcraft-gui build passed on travis-ci :D see here https://travis-ci.org/keshavbhatt/snapcraft-gui/builds/158252620
[18:28] <mvo> slangasek: thank you! will work to make sure we have fully working autopkgtest again
[18:42] <arges> jdstrand: i'm packaging up a daemon program that has a socket. I'd like that socket to have root:adm ownership, but seems like fchownat is not whitelisted for seccomp. Whats the snap way to do somethign like this?
[18:53] <bulldog> kyrofa, i updated the ppa plz check it out now :)
[18:55] <bulldog> mhall119, you should allow old deb store back :(
[18:57] <jdstrand> arges: devmode currently
[18:58] <jdstrand> arges: or alter how you think about it and do root:root 660 (or whatever)
[18:58] <arges> jdstrand: hmm.
[18:59] <jdstrand> users and groups aren't spec'd out yet. there are ideas
[19:00] <arges> jdstrand: (reading interfaces/seccomp/template.go) why do we need per-app UID/GIDs esp. if we have something like a daemon that users in the classic dimension can interact with
[19:00] <arges> jdstrand: i found bug 1446748, is there something else worth following?
[19:00] <mup> Bug #1446748: implement seccomp filtering by argument <application-confinement> <ubuntu-core-launcher (Ubuntu):In Progress by jdstrand> <https://launchpad.net/bugs/1446748>
[19:03] <jdstrand> arges: this is a complicated problem. snap-confine can now filter by argument. what remains is adding policy for that (which I plan to add some to allow using (perhaps the) daemon user but that is after rtm stuff
[19:03] <jdstrand> arges: and then for arbitrary groups like you just suggested, exposing that in snap.yaml, figuring out what that means with classic vs all snaps, etc
[19:04] <arges> jdstrand: ok
[19:04] <jdstrand> arges: and then opt-in per-snap uid/groups come in later so something like postgres can drop privs to a user it wants to instead of say, 'daemon'
[19:04] <bulldog> we package .deb with travis-ci too . wow
[19:07] <jdstrand> arges: once I add the logic to snap-confine to map user and group names to uids and gids and then update the policy accordingly, it becomes possible to say 'allow this snap to chown to 'adm'. but figuring out what that means in terms of policy, etc is not as simple
[19:08] <jdstrand> snappy interfaces mediate access to things already
[19:08] <arges> jdstrand: would the application be able to do the same 'chown root:adm /thing' or would they need to use something else?
[19:09] <jdstrand> arges: an application would be able to do that, sure. we'd say 'you can chown to your own uid and this other one'
[19:09] <jdstrand> that type of thing
[19:09] <arges> ok
[19:09] <jdstrand> arges: but, what is it that you are trying to solve today? I may be able to suggest an alternative
[19:10] <arges> jdstrand: ok
[19:33] <mvo> pitti: still around?
[19:33] <pitti> mvo: o/
[19:34] <mvo> pitti: a bit of a emergency on the snappy candidate image http://paste.ubuntu.com/23147237/
[19:34] <pitti> mvo: -ish
[19:34] <mvo> pitti: or can someone with a more us-ish timezone help with that too?
[19:34] <mvo> pitti: the resolv.conf looks strange and I have no DNS on the images currently
[19:34] <pitti> mvo: uh, that looks like a sed gone wrong?
[19:35] <pitti> mvo: what's the Exec= line in your /lib/systemd/system/systemd-networkd-resolvconf-update.service ?
[19:35] <mvo> pitti: https://launchpadlibrarian.net/282933728/livecd-rootfs_2.420+ppa33_2.420+ppa34.diff.gz
[19:35] <mvo> pitti: thats the sed
[19:35] <mvo> pitti: let me look, one sec
[19:36] <mvo> pitti: http://paste.ubuntu.com/23147248/
[19:37] <pitti> mvo: that's obviously being applied twice
[19:37] <pitti> mvo: that, or you have systemd 229-4ubuntu8 from xenial-proposed, which already contains this fix
[19:38] <pitti> mvo: if you build from x-proposed, you can drop the livecd-rootfs workaround
[19:38] <mvo> pitti: oh, let me check. that would explain why it suddentdly broke
[19:38] <pitti> mvo: or replace it with something more robust, i. e. turn
[19:38] <pitti> +sed -i '/^ExecStart=/ s!netif/state!& /run/systemd/netif/leases/* | sort -u!' /lib/systemd/system/systemd-networkd-resolvconf-update.service
[19:38] <pitti> into
[19:38] <mvo> pitti: yes we do
[19:38] <pitti> +grep -q netif/leases /lib/systemd/system/systemd-networkd-resolvconf-update.service || sed -i '/^ExecStart=/ s!netif/state!& /run/systemd/netif/leases/* | sort -u!' /lib/systemd/system/systemd-networkd-resolvconf-update.service
[19:38] <mvo> pitti: so I drop the workaround I think
[19:39] <pitti> mvo: ah, then kill the workaround with fire, I say :)
[19:39] <mvo> pitti: yeah, that sounds reasonable
[19:39]  * pitti updates his arithmetic: fix + fix == boom
[19:40]  * mvo hugs pitti
[19:40]  * zyga is in awe of mvo 
[19:40] <mvo> pitti: thanks, you saved me, I would have spend ages on this
[19:40] <mvo> zyga: be in awe for pitti :)
[19:40] <zyga> mvo: pitti deserves his own slice of awe but you are saving snappy today :)
[19:42] <ogra_> what do you guys have with the poor awe
[19:42] <awe> ;)-
[19:42] <ogra_> stop slicing him :)
[19:42] <zyga> lol
[19:43] <pitti> yummy
[19:44] <pitti> sorry for the sloppy workaround :)
[19:44]  * zyga returns to gtest 
[19:48] <mvo> pitti: all good, you saved the day
[20:02] <mup> PR # opened: snapcraft#652, snapcraft#661, snapcraft#671, snapcraft#674, snapcraft#716, snapcraft#726, snapcraft#727, snapcraft#736, snapcraft#742, snapcraft#751, snapcraft#758, snapcraft#761, snapcraft#772, snapcraft#773, snapcraft#776
[20:33] <cjwatson> sergiusens: thanks
[20:33] <cjwatson> elopio: please use format> why?  % isn't deprecated
[20:34] <elopio> cjwatson: for consistency, we use format everywhere.
[20:34] <cjwatson> seems like a waste of typing, but whatever ...
[20:35] <cjwatson> (will fix things up later, thanks)
[20:37] <pitti> I think I'll jump from % directly to python 3.6's fstrings once these become available :)
[20:38] <jcastro> zyga: heya, it looks like xenial-proposed has snap-confine 1.0.38-0ubuntu0.16.04.10
[20:39] <jcastro> will xenial get 1.0.40 like what is in yakkety?
[20:42] <cjwatson> yeah, f-strings look like actually a nice improvement, .format just feels clumsy unless you're substituting the same thing more than once
[20:45] <mvo> jdstrand: did something change wit the review scripts? it looks like the ubuntu-core uploads are no longer automatically accepted in the store
[20:45] <mvo> jdstrand: I see "manual review pending" now
[20:46] <jdstrand> mvo: they did but they shouldn't block. can you give me the store url?
[20:47] <mvo> jdstrand: https://myapps.developer.ubuntu.com/dev/click-apps/4142/
[20:47] <mvo> jdstrand: I manually approved to unblock me
[20:47] <jdstrand> mvo: 'grade' should not be used with 'type: os' lint-snap-v2_grade_valid
[20:47] <jdstrand> mvo: I was told grade made no sense with 'type: os'
[20:48] <mvo> jdstrand: fair enough, something for ogra_ to sort tomorrow I guess, but it might be snapcraft adding that
[20:49] <jdstrand> that wouldn't surprise me
[20:53] <jdstrand> mvo: so, I downloaded your image but I don't seem to be using snap-exec
[20:53] <jdstrand> mvo: I don't have 'unsafe' in the policy and it all seems to work fine
[20:54] <mvo> jdstrand: yes, it is all fine on pc, its only an issue on pi2 and I have not pushed a new image for that yet
[20:54] <mvo> jdstrand: it literally build just 5min ago
[20:54] <ogra_> jdstrand, yeah, thats new
[20:55] <jdstrand> oh hrm
[20:55] <ogra_> nothing on our side ...
[20:55] <jdstrand> well, I don't need the bug to look at this I guess
[20:56] <jdstrand> ogra_: grade with os snap? sounds like a snapcraft bug then. cprov provided the 'grade' branch and said that it didn't make sense with the os snap
[20:56] <ogra_> jdstrand, right, new snapcraft landed today i think
[20:57] <ogra_> mvo, oh, do you need to build another kernel today ?
[20:58] <cprov> jdstrand: perhaps it was a mistake
[20:58] <ogra_> then we need to push a new PPA snapcraft with the hhtp_proxy fix for bzr
[20:58] <jdstrand> kyrofa, sergiusens: fyi, the review tools and snapcraft don't agree about 'grade' with 'type: os'. I'm told by cprov that 'grade' doesn't make sense with 'type: os'. can you guys sort that out so core uploads aren't blocked? let me know if the tools need to change
[20:59] <mvo> ogra_: could be
[20:59] <kyrofa> jdstrand, sergiusens cprov might be a question for ogra_ and mvo. Do you ever have core snaps that are in-development and shouldn't be in a stable channel?
[20:59] <kyrofa> Honestly I don't feel like _anyone_ needs grade
[21:00] <ogra_> kyrofa, sure, the dailies go to edge
[21:00] <kyrofa> But if it makes sense for app snaps, then I feel like it probably makes sense for all snaps
[21:00]  * ogra_ points to https://wiki.ubuntu.com/QATeam/OSSnapPromotion
[21:00] <kyrofa> ogra_, are you familiar with the "grade" stuff?
[21:00] <ogra_> nope, never heard of it
[21:00] <jdstrand> ogra_: doesn't grade prevent promotion to stable?
[21:00]  * jdstrand is not super-familiar with the grade stuff either
[21:01] <cprov> Stable and candidates
[21:01] <kyrofa> jdstrand, indeed, at least that's my understanding as well
[21:01] <kyrofa> Yeah
[21:01] <kyrofa> I guess just to prevent a mistake?
[21:01] <jdstrand> ls
[21:01] <jdstrand> meh
[21:01] <ogra_> well, then we definitely never want grade
[21:01] <kyrofa> Because you promote?
[21:01] <kyrofa> Rather than create new revs?
[21:01] <ogra_> because until the OSSnapPromotion is implemented we need to migrate through the channels
[21:02] <kyrofa> Yeah, makes sense
[21:02] <ogra_> we wont anymore by GA ...
[21:02] <kyrofa> But would anyone ever want to use that feature? I feel like it adds more complication making core snaps special cases here
[21:02] <sergiusens> ogra_ so you don't need it now is different than you don't need it ever
[21:02] <ogra_> but til then we need to be able to migrate
[21:02] <sergiusens> I suggest a bug report and get some architect/master designer to comment
[21:03] <ogra_> sergiusens, well, given that this kills the image that mvo needs to release *now* ... i'm not so sure
[21:03] <sergiusens> ogra_ just add `grade: stable`
[21:03] <jdstrand> that won't fix the tools
[21:03] <jdstrand> the review tools don't like grade with type: os
[21:03] <jdstrand> I can change that. I just don't know if I should
[21:03] <ogra_> sergiusens, since i can not use the pfficial snapcraft anyway, where do i need to patch ?
[21:03] <ogra_> *official
[21:04] <sergiusens> jdstrand we also are just considering Ubuntu's use case, but other `type: os` builders might need it
[21:04] <sergiusens> ogra_ in `snapcraft/internal/meta.py`; pop `grade` if `type` == `os`
[21:04] <ogra_> (i need a hacked snapcraft in any case because bug 1606203 wont be fixed)
[21:04] <mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:Incomplete> <https://launchpad.net/bugs/1606203>
[21:04] <jdstrand> sergiusens: I was not part of the discussion or design. If it is supposed to make sense for type: os, that's fine
[21:05] <sergiusens> jdstrand I don't know; that is the thing :-)
[21:05] <jdstrand> sergiusens: yeah, me either
[21:05] <sergiusens> jdstrand we seldom discriminate if a feature should NOT affect the os snap
[21:05] <sergiusens> or gadget or kernel
[21:06] <jdstrand> cprov: you seem closest to this. what is your opinion considering the possibility of non-ubuntu os snaps?
[21:06] <cprov> jdstrand: I think it was a mistake to discriminate os-snap on CRT
[21:07] <cprov> my *mistake*
[21:07] <jdstrand> ok
[21:07] <jdstrand> I can fix that real quick then
[21:08] <jdstrand> ogra_: you should probably still patch snapcraft since it won't land immediately
[21:08] <cprov> jdstrand: can't the current os-snap be manually approved until the next SCA rollout ?
[21:08] <ogra_> sergiusens, in write_snap_yaml ?
[21:09] <ogra_> cprov, if it cant go to stable that doesnt help
[21:09] <jdstrand> cprov: yes. he would only be patching his local copy of snapcraft so he wouldn't have to do that
[21:09] <cprov> ogra_: if you use "grade: stable" they can go to stable channel
[21:10] <ogra_> cprov, and to all others too ?
[21:10] <cprov> yup
[21:10] <ogra_> it needs to start in edge and migrate up
[21:10] <ogra_> hmm, then i'll add just that to snapcraft.yaml
[21:13] <jdstrand> fyi, this is fixed in review tools r739
[21:14] <cprov> jdstrand: thanks, I will deploy it in staging, will be in prod ~ tomorrow noon. Is it okay to approve os-snap uploads manually until then ?
[21:15] <jdstrand> cprov: if that is the only warning, yes
[21:18] <ogra_> mvo, patched snapcraft uploaded to the PPA ... if you need a kernel build, wait til it promoted please (else the world will explode) and ubuntu-core snapcraft.yaml with added "grade: stable" is in the ubuntu-core build branch
[21:18] <mvo> ogra_: aha, nice
[21:19]  * ogra_ goes back to TV ... i'll check here occasionally though in case there is something else
[21:25] <mvo> ogra_: just mild panic,
[21:55] <mvo> jdstrand: the pi2 with the unsafe bit in the apparmor profile are available at http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/
[21:55] <mvo> jdstrand: I verified that the fix works
[23:40] <mup> PR snapd#1866 opened: many: add snap configuration to REST API <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1866>