[00:09] <mup> PR snapd#1682 opened: interfaces/hardware-observe.go: re-add /run/udev/data <Created by cwayne18> <https://github.com/snapcore/snapd/pull/1682>
[04:29] <mup> PR snapd#1663 closed: osutil: fix create-user on classic systems <Created by jaymell> <Closed by jaymell> <https://github.com/snapcore/snapd/pull/1663>
[06:40] <zyga> good morning
[06:42] <ljp> so only the gadget or os snap is allowed to use gpio?
[06:49] <pcoca> Hi everyone!
[06:49] <pcoca> I am getting this Apparmor issue:
[06:49] <pcoca> Aug 15 23:44:25 haswell16 kernel: [18612.885097] audit: type=1400 audit(1471329865.428:185): apparmor="DENIED" operation="create" profile="snap.sensortag.sensortag" pid=24904 comm="bluepy-helper" family="bluetooth" sock_type="seqpacket" protocol=0 requested_mask="create" denied_mask="create"
[06:49] <pcoca> And I am using the  plugs: [bluez] on my snapcraft.yaml
[06:50] <pcoca> https://github.com/pedrococa/sensortag/blob/master/snapcraft.yaml
[06:50] <pcoca> Is there any additional interface that I should use?
[06:52] <lpotter> looks like the mir interface can allow seqpacket
[06:57] <pcoca> lpotter,  so plugs: [mir, bluez] would do the trick?
[07:01] <pcoca> lpotter, I am afraid it is not working.
[07:01] <zyga> lpotter: hey
[07:02] <zyga> lpotter: let me check if seqpacket is allowed
[07:03] <pcoca> zyga, lpotter, is used by a BTLE device
[07:04] <pcoca> zyga, lpotter, otherwise I got the apparmor issue and the snap failed with an error of BTLE addresses.
[07:05] <zyga> it seems not to be
[07:06] <zyga> essentially the apparmor denail you got above said you cannot create a seqpacket socket, try network-bind as a quick workaround
[07:07] <zyga> pstolowski: cześć :)
[07:08] <pstolowski> zyga, czołem!
[07:09] <zyga> pcoca: let me know if that workaround works for you
[07:09] <pcoca> zyga, sure, snapping it up now :)
[07:10] <zyga> :-)
[07:11] <mup> PR snapd#1683 opened: osutil: fix create-user on classic <Created by jaymell> <https://github.com/snapcore/snapd/pull/1683>
[07:12] <pcoca> zyga, It does not work :/
[07:12] <pcoca> I still got the same error with Apparmor
[07:12] <pcoca> using    plugs: [bluez, network-bind]
[07:18] <zyga> pcoca: can you please report the bug and give some background on the library/system calls you are using
[07:19] <zyga> pcoca: please report teh bug on launchpad.net/snappy with snapd-interface tag
[07:21] <mup> PR snapd#1684 opened: many: drop ubuntu-core-snapd-units package, use release.OnClassic instead <Created by mvo5> <https://github.com/snapcore/snapd/pull/1684>
[07:26] <pcoca> zyga, here is: https://bugs.launchpad.net/snappy/+bug/1613572
[07:26] <mup> Bug #1613572:  apparmor denial with sock_type="seqpacket" using a BTLE device <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1613572>
[07:28] <mup> Bug #1613572 opened:  apparmor denial with sock_type="seqpacket" using a BTLE device <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1613572>
[07:29] <mup> PR snapd#1685 opened: snap-exec: Fix broken `snap run --shell` and add test <Created by mvo5> <https://github.com/snapcore/snapd/pull/1685>
[07:30] <zyga> pcoca: I saw, thank you
[07:30] <zyga> mwhudson: good morning
[07:31] <zyga> mwhudson: I've applied to be a DM, if you'd like you can consider adding your advocacy for me: https://nm.debian.org/process/74/advocate
[07:44] <mup> PR snapd#1686 opened: boot: add support for "devmode: {true,false}" in seed.yaml <Created by mvo5> <https://github.com/snapcore/snapd/pull/1686>
[07:56] <mup> PR snapd#1687 opened: release: Remove "UBUNTU_CODENAME" from the test data <Created by mvo5> <https://github.com/snapcore/snapd/pull/1687>
[08:35] <mup> Bug #1613609 opened: Can't register name for snap package <Snappy:New> <https://launchpad.net/bugs/1613609>
[08:38] <rtsisyk> hi. I created my first snappy package: https://github.com/tarantool/tarantool/blob/snappy/snapcraft.yaml How I can register "tarantool" name for it?
[08:44] <mup> Bug #1613609 changed: Can't register name for snap package <Snapcraft:New> <https://launchpad.net/bugs/1613609>
[08:45] <ogra_> ogra@anubis:~/datengrab/images/snappy$ /snap/bin/vlc
[08:45] <ogra_> multiple nvidia drivers detected, this is not supported
[08:45] <ogra_> bah !
[08:45] <ogra_> (it isnt really like i need the nvidia drivers for music playback )
[08:45] <mvo> ogra_: fwiw, I'm testing the fix for the boot problem you noticed on friday right now
[08:46] <mvo> ogra_: zyga maybe able to help with snap-confine
[08:46] <ogra_> mvo, awesome, is it in the edge channel already ?
[08:46] <ogra_> (i can manually update when setting snap_try_kernel)
[08:47] <mvo> ogra_: not yet, I sideloaded for now to double check that I did not mess up uboot.env but if it boots I will upload
[08:48] <ogra_> cool, ping me then, i'll do test upgrades without sideloading
[08:49] <mvo> ogra_: pi2 is published now, please let me know how it goes, I'm updating the dragonboard now
[08:50] <ogra_> hmpf ... i cant really find the code in vlc that prevents the starting with nvidia drivers ... this is really evil ...
[08:50] <ogra_> didrocks, is that check in the launcher code ?
[08:51] <mvo> ogra_: that is snap-confine that shows this message
[08:51] <ogra_> bah
[08:51] <didrocks> ogra_: no, it's not in the launcher
[08:51] <ogra_> on what conditions ?
[08:52] <ogra_> didrocks, yeah, seems snap-confine
[08:52] <didrocks> yeah ;)
[08:52] <ogra_> zyga, on what conditions does snap-confine block executions with nvidia drivers ...
[08:52] <ogra_> seems it is rather overzealous
[08:55] <mvo> ogra_: dragonboard is also uploaded, let me know if you notice any issues please
[08:56] <mup> PR snapd#1687 closed: release: Remove "UBUNTU_CODENAME" from the test data <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1687>
[08:57] <ogra_> mvo, oh
[08:57] <ogra_> i got a new gadget too
[08:57] <mvo> ogra_: the fix is entirely in there
[08:58] <ogra_> oh
[08:58] <mvo> ogra_: its also in bzr if you want to double check, once sec, I look for the diff
[09:00] <ogra_> wow ... seems my pi2 auto upgraded to 254 already
[09:00] <ogra_> (not rebooted though)
[09:01] <ogra_> mvo, btw, we need some scriptery in the uboot.env to reboot when it cant load the files
[09:01] <ogra_> that would have prevebted the hang
[09:01] <ogra_> *prevented
[09:03] <ogra_> ok, dragonboard is proper at v3 and ubuntu-core v253
[09:03] <mvo> ogra_: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/revision/45 and 46
[09:03] <mvo> ogra_: +1 for magic in uboot
[09:04] <ogra_> and pi2 at 14 and 254 ...
[09:04] <ogra_> but both had snap_try_kernel set
[09:05] <ogra_> i guess i should trigger quickly another ubuntu-core to test without it set
[09:05] <ogra_> build kicked ...
[09:06] <ogra_> cjwatson, i see very often timeouts when triggering a snap buikld through the LP UI ... current one is OOPS-a9d5e8c47cb69641674e12dd57721fc9
[09:06] <ogra_> *build
[09:07] <ogra_> (the build gets triggered fine, just the reload after triggering does time out)
[09:12] <cjwatson> ogra_: Thanks.  That one could be fixed with a bit of property caching; please file a bug with the OOPS ID.
[09:13] <ogra_> against launchpad itself ?
[09:14] <cjwatson> ogra_: yes
[09:14] <ogra_> thx
[09:16] <cjwatson> ogra_: regression in r18036, apparently
[09:16] <ogra_> aha
[09:27] <mvo> jaymell: hey, thank a bunch for your nice branch jaymell:createUserOnClassic, really cool that you are working on this! I got a bit carried away while reviewing and created a small tweaks commit https://github.com/mvo5/snappy/commit/52a572a90a3979b37eb7bcda73db1d61cef6b735 - would you mind reviewing and merging into your branch? it addresses the bits that zyga mentioned. I hope you like it and don't mind me doing this, but I was quite excited tha
[09:27] <mvo> t create-user now works on classic :)
[09:32] <ogra_> ** Unable to read file /kernel.img **
[09:32] <ogra_> reading /dtbs/apq8016-sbc.dtb
[09:32] <ogra_> ** Unable to read file /dtbs/apq8016-sbc.dtb **
[09:32] <ogra_> reading /initrd.img
[09:32] <ogra_> ** Unable to read file /initrd.img **
[09:32] <ogra_> Bad Linux ARM64 Image magic!
[09:32] <ogra_> =>
[09:32] <ogra_> mvo, ^^^ :/
[09:33] <ogra_> (after refresh to the new ubuntu-core that finished a few mins ago)
[09:36] <mvo> ogra_: hm, dragonboard? if it is not a fresh flash you will need to manually copy uboot.env to /boot/uboot, its not happening automatically iirc (but please double check using md5sum, maybe I misremember)
[09:36] <mup> PR snapd#1680 closed: overlord/assertstate,daemon: reorg how the assert manager exposes the assertion db and adding to it <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1680>
[09:41] <dragly> is it possible to have snapcraft put the parts/prime/stage folders in a different place? I'm currently building a project that I have stored inside a Dropbox folder, and this appears to be a Bad Idea™
[09:41] <Odd_Bloke> dragly: A temporary workaround might be to use `snapcraft cleanbuild`, which builds inside a lxd container (though this does mean that you can't easily examine each of the stages).
[09:42] <dragly> Odd_Bloke: thanks, I'll try that out
[09:52] <mup> PR snapd#1688 opened: interfaces: add fwupd interface <Created by timchen119> <https://github.com/snapcore/snapd/pull/1688>
[10:08] <ogra_> mvo, well, md5 is moot after one boot attempt since it saves vars during boot ... but let me try
[10:09] <mvo> ogra_: you could dump the entire text and patebinit and I check
[10:09] <ogra_> mvo, yeah, the script line differs ...
[10:11] <mvo> ogra_: meh, ok
[10:11]  * ogra_ copies manually and transfers all the variables needed
[10:12] <ogra_> ok, now it works again
[10:16] <ogra_> same for rpi
[10:17] <ogra_> so i guess the gadget needs some upgrade hook
[10:17] <mvo> ogra_: yes, I guess short term I need to create new base images
[10:17] <ogra_> that too
[10:26] <ogra_> mvo, triggering a new ubuntu-core build to test with the new gadget in place now
[10:28] <mvo> ogra_: ta
[10:28]  * mvo considers lunch
[10:30] <ogra_> cjwatson, Bug #1613652 (sorry, took a bit)
[10:30] <mup> Bug #1613652: timeouts when triggering snap builds <Launchpad itself:New> <https://launchpad.net/bugs/1613652>
[10:34] <cjwatson> ta
[11:02] <zyga> Son_Goku: hey, I've updated snap-confine and I'll need another golang package before snapd 2.11
[11:02] <zyga> Son_Goku: I've uploaded everything to people.fedoraproject.org, I'll start working on the paperwork for this
[11:04] <ogra_> mvo, upgrade works now \o/ ... what i dont get though ... the image should have been built from the edge channel .. but snap refresh always tries to get ubuntu-core from stable, i have to explicitly call "sudo snap refresh ubuntu-core --edge" ... dont we store the default channel in the image config anywhere ?
[11:10] <Son_Goku> zyga, have you made any progress on selinux support in snap-confine?
[11:15] <zyga> Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1367407
[11:15] <zyga> Son_Goku: some, I'm working on toy version of snap-confine that fiddles with libselinux
[11:15] <Son_Goku> macaroons?!
[11:15] <zyga> Son_Goku: upstream firefighting is over now, I'm just waiting for reviews and I'll do 1.0.40 release
[11:16] <zyga> Son_Goku: I'm back to my regular tasks
[11:16] <zyga> Son_Goku: yeah, part of snapd auth code
[11:16] <zyga> Son_Goku: (I was surprised that macaroon is not "pasta" but instead is "fancy cookie"
[11:16] <zyga> Son_Goku: the polish word for "pasta" is makaron
[11:17] <Son_Goku> oh dear god
[11:17] <Son_Goku> I feel stupid now
[11:18] <zyga> Son_Goku: I'd like to make snap-confine apply selinux context/labels/thing to the mounted snaps
[11:18] <zyga> Son_Goku: haha, why? Did you also think it is about pasta?
[11:18] <Son_Goku> that, and apparently we should have never importing check
[11:18] <Son_Goku> it already exists: http://koji.fedoraproject.org/koji/packageinfo?packageID=19283
[11:18] <zyga> hmmm
[11:18] <zyga> that's odd
[11:18] <zyga> I did gofed checks
[11:19] <zyga> that's good though
[11:19] <zyga> Son_Goku: wait, that's gopkg.in/check.v1
[11:20] <zyga> Son_Goku: so there are two packages for the same thing?
[11:20] <Son_Goku> yep
[11:20] <Son_Goku> you just added exactly the same package to Fedora
[11:20] <Son_Goku> http://koji.fedoraproject.org/koji/buildinfo?buildID=785266
[11:20] <zyga> Son_Goku: I'll email the maintainer, maybe those should be merged
[11:20] <Son_Goku> yeah
[11:20] <Son_Goku> it's clearly an accident
[11:21] <zyga> Son_Goku: yeah, the provides for common name could be a way to find those
[11:21] <zyga> Son_Goku: golang is still young and packaging guidelines are incomplete and weak, the package I added follows the more strict naming convention
[11:21] <Son_Goku> yeah
[11:22] <Son_Goku> well, the biggest problem is because golang is all statically done, there's no easy way to identify everything
[11:22] <Son_Goku> and apparently the provides didn't even exist on that go-check package until Feb of this year
[11:22] <Son_Goku> which shows how difficult golang can get
[11:23] <zyga> yeah, I agree
[11:23] <zyga> I think upstream import path/common name should be the only way to map packages
[11:23] <zyga> everything else is wrong
[11:23] <zyga> including github repo checks (like in this case)
[11:24] <tdr> Hello, I'm trying to build a snap, but I'm getting this error: "Can't convert 'float' object to str implicitly" anyone know what that means?
[11:24] <Son_Goku> what I'm surprised about is that gofed didn't catch this
[11:24] <Son_Goku> or did you never run gofed on snapd itself?
[11:25] <zyga> Son_Goku: I think I didn't run it on snapd
[11:25] <zyga> Son_Goku: though at the time the common name import didn't exist
[11:25] <zyga> Son_Goku: or .... perhaps I didn't use the common name then
[11:25] <Son_Goku> you probably didn't use the common name
[11:25] <zyga> Son_Goku: in any case, I'm writing to the maintainer now
[11:25] <Son_Goku> cool
[11:26] <Son_Goku> you might want to ask if his version is up to date, and if you can be comaintainer of the package, too
[11:26] <Son_Goku> you can request the ACLs here: https://admin.fedoraproject.org/pkgdb/package/rpms/golang-gopkg-check/
[11:26] <zyga> yep, good idea
[11:27] <zyga> Son_Goku: how have you been?
[11:27] <Son_Goku> I've been alright
[11:27] <zyga> Son_Goku: for me the summer is over, it's cold and wet all week
[11:27] <Son_Goku> haha
[11:27] <Son_Goku> it's still hot here
[11:27] <Son_Goku> it's a bit rainy at the moment, but still very hot
[11:28] <zyga> Son_Goku: it was 10C in the morning today
[11:28] <Son_Goku> it's 73F / 23C right now
[11:29] <Son_Goku> the high will be 86F / 30C
[11:29] <zyga> I really envy you, I sometimes question the logic of moving away from spain *for summer* so that we can spend it in a cold forest in the north
[11:30] <Son_Goku> haha
[11:36] <zyga> Son_Goku: sent!
[11:36] <zyga> Son_Goku: you're on CC
[11:36] <zyga> Son_Goku: I'll look at snapd 2.11, I need to fix something in systemd units (seems like upstream change)
[11:37] <zyga> Son_Goku: oh, btw, I'm almost done removing snap-confine debian packaging from the upstream tree, I will be able to run end-to-end integration tests, made against fedora packaging, on each pull request soon
[11:37] <Son_Goku> cool
[11:38] <zyga> Son_Goku: https://github.com/snapcore/snap-confine/pull/103/files
[11:38] <mup> PR snap-confine#103: Use downstream packaging in spread tests <Created by zyga> <https://github.com/snapcore/snap-confine/pull/103>
[11:38] <Son_Goku> btw, if you wanted to set up some kind of thing to monitor snapd, snap-confine, and its deps in fedora, you can use this: https://apps.fedoraproject.org/mdapi
[11:38] <zyga> Son_Goku: I support debian and ubuntu, fedora and arch are up next, I just need to land this first
[11:38] <Son_Goku> it's a RESTful API that emits a JSON form of the RPM XML repodata
[11:39] <mvo> ogra_: that sounds like a bug, it should store the channel, let me double check that
[11:39] <zyga> Son_Goku: I have that bookmarked, I need to spend some time on that cross distro monitoring
[11:39] <zyga> Son_Goku: I'm really glad most of snap-confine firefighting is over and I can pick up stuff form my backlog again
[11:40] <Son_Goku> both the Debian guy and myself would really like to see the SELinux integration asap :)
[11:42] <zyga> Son_Goku: it is capped by my capacity to learn selinux and spend time on it; if you know anyone who'd like to hack on this with me that would help a lot
[11:42] <Son_Goku> did you learn anything from selinux guys at flock that could help?
[11:42] <zyga> Son_Goku: yes, I asked a lot of questions over lunch
[11:42] <zyga> Son_Goku: I also got the idea that everything I want to do is doable
[11:43] <zyga> Son_Goku: but most importantly, we just had a good time and exchanged contacts
[11:43] <Son_Goku> that's good
[11:46]  * zyga away for 45 min
[11:50] <sborovkov> niemeyer: Hi. I saw that you wrote that you published patched version for this bug in your ppa https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1606212 - is it possible to use your ppa?
[11:50] <mup> Bug #1606212: getpwuid is failing on classic image <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1606212>
[11:52] <ogra_> mvo, might be related to me manually tinkering with snap_try_kernel before (and according broken boot attempts alongside)
[11:56] <mvo> ogra_: maybe, smeels like a bug, if you mail me (privately) /var/lib/snapd/state.json I can check if the DB is correct about it
[11:56] <ogra_> will do
[11:56] <mvo> ogra_: thanks
[12:12] <mup> Bug #1613686 opened: Consider allowing access to @{PROC}/@{pid}/limits <Snappy:New> <https://launchpad.net/bugs/1613686>
[12:58] <mup> PR snapd#1681 closed: tests: test `snap run --hook` using in-tree snap-exec <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1681>
[12:59] <zyga> Son_Goku: snap-confine updated again
[12:59] <zyga> Son_Goku: I'd love if you can set the reviewed bit now :)
[12:59] <Son_Goku> haha
[12:59] <zyga> Son_Goku: if you want, all the changes are kept in git for easier review too
[13:00] <zyga> https://github.com/zyga/snapcore-fedora/commits/master
[13:02] <Son_Goku> :)
[13:02] <Son_Goku> package approved
[13:03] <zyga> wooot
[13:03] <zyga> thank you
[13:05] <Son_Goku> macaroon is approved too
[13:05] <Son_Goku> contingent on your fixes
[13:06] <zyga> yep, I saw; I'm on a call now but I'll continue with this as the next thing
[13:06] <zyga> Son_Goku: I'll push my selinux hacks today, maybe at least to get some feedback from others
[13:06] <Son_Goku> cool
[13:06] <Son_Goku> having something is better than nothing, imo
[13:20]  * zyga requested snap-confine and the macaroon package in fedora
[13:20] <zyga> next up: snapd :)
[13:22] <awe> ogra_, who's responsible for the config of the rpi2-kernel snap?
[13:22] <ogra_> awe, the config ?
[13:23] <ogra_> you mean the build configuration ?
[13:23] <awe> yup
[13:23] <awe> looks like there aren't any audio devices configured by default
[13:23] <ogra_> (the snap just uses the linux-raspi2 and linux-image-raspi2 packages from the archive)
[13:23] <awe> which makes testing pulse rather difficult
[13:23] <awe> ;D
[13:23] <ogra_> pfft, excuses :P
[13:24] <ogra_> ppisati_, ^^^ can we have audio devices on the pi's ?
[13:24]  * ogra_ has no idea which config options we need though)
[13:24]  * awe has never toyed with rpi audio before, but the doc says there are two output devices ( HDMI, and headphone out )
[13:25]  * ppisati_ checks
[13:43] <jdstrand> morphis: hi! can you look at https://bugs.launchpad.net/snappy/+bug/1613572/comments/2?
[13:43] <mup> Bug #1613572:  apparmor denial with sock_type="seqpacket" using a BTLE device <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1613572>
[13:43] <jdstrand> morphis: with the addition of bluetooth-control, I'm not sure where to put the fix
[14:02] <mup> PR snapd#1682 closed: interfaces/hardware-observe.go: re-add /run/udev/data <Created by cwayne18> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1682>
[14:06] <sborovkov> jamiebennett: ping
[14:07] <jamiebennett> pong
[14:09] <sborovkov> jamiebennett: question about this bug - https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1606212 So Manik asked us if we could use what's described in this bug to workaround our issue. From what I read it seems niemeyer has some kind of build with patch for this? Can we use that ppa with the built ubuntu-core? I checked out his user profile and ppa there has last update from 270 weeks ago )
[14:09] <mup> Bug #1606212: getpwuid is failing on classic image <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1606212>
[14:15] <jamiebennett> sborovkov: We keep the code on GitHub, let me see if I can find the branch
[14:15] <jamiebennett> niemeyer: ^
[14:17] <sborovkov> thanks
[14:17] <niemeyer> sborovkov: I don't have anything other than what's described there
[14:17] <niemeyer> sborovkov: The issue mentioned describes why the problem is likely happening, and what the fix is
[14:18] <sborovkov> niemeyer: so should I write a similar patch for my app like the one you attached for plymouth
[14:18] <niemeyer> sborovkov: Not clear if this needs to be in your app or in snapd itself
[14:18] <niemeyer> sborovkov: It might be a file that we're not shipping in /etc that we could ship and would solve all similar issues
[14:18] <sborovkov> Yes, that's why I asked. I though you patched snapd. And it would be in ubuntu-core
[14:19] <niemeyer> sborovkov: Someone needs to dig down and test this theory out
[14:19] <elopio> didrocks: do you want to hangout to get over with this docker hub thing?
[14:19] <niemeyer> sborovkov: Can you give it a shot?
[14:20] <sborovkov> niemeyer: but that patch should work, right? I checked /var/snap/ubuntu-core... and nsswitch.conf was present along with libnss files?
[14:20] <niemeyer> sborovkov: Even if the fix is in ubuntu-core, having someone verify it would be useful
[14:20] <pcoca> jdstrand, Hi Jamie! Just updated https://bugs.launchpad.net/snappy/+bug/1613572. Is the path different in the classic subsystem? I cannot do the workaround.
[14:20] <mup> Bug #1613572:  apparmor denial with sock_type="seqpacket" using a BTLE device <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1613572>
[14:20] <sborovkov> niemeyer: I'll test the patch on the side of my app then
[14:21] <niemeyer> sborovkov: Thanks, please let me know how it goes
[14:21] <sborovkov> sure
[14:22] <jdstrand> pcoca: /var/lib/snapd/apparmor/profiles/snap.sensortag.sensortag
[14:22] <jdstrand> pcoca: I left out 'snapd'
[14:25] <pcoca> jdstrand,  after the line:
[14:25] <pcoca> profile "snap.sensortag.sensortag" (attach_disconnected) {
[14:26] <pcoca> ?
[14:26] <jdstrand> pcoca: anywhere in between the {}. I typically add workarounds before the final '}'
[14:27] <pcoca> jdstrand, OK
[14:30] <jdstrand> Odd_Bloke: you bug 1607710 is not prioritized afaict. if you need it escalated, I suggest talking to jamiebennett
[14:30] <mup> Bug #1607710: Home directories listed in /etc/passwd should be honoured <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
[14:30] <jdstrand> your*
[14:32] <pcoca> jdstrand, Done it. Thanks Jamie. I got now a different error :/ I just updated the bug info.
[14:35] <morphis> jdstrand: will have a look
[14:36] <Odd_Bloke> jamiebennett: Getting https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1607710 fixed would be super-cool, because then we could start snapping up tools we use in Jenkins. :)
[14:36] <mup> Bug #1607710: Home directories listed in /etc/passwd should be honoured <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
[14:37] <jamiebennett> Sounds like zyga may know more on this bug
[14:41] <jdstrand> morphis: basically I wondering about the intent of the bluez interface-- is that only for talking to bluez now or should it give network bluetooth
[14:42] <morphis> jdstrand: on the plug side it should only allow dbus api access for bluez
[14:42] <morphis> all low level BT stuff should go into bluetooth-control
[14:42] <jdstrand> morphis: ok, so we should add network bluetooth to bluetooth-control
[14:42] <morphis> yeah
[14:42] <jdstrand> gotcha, thanks!
[14:42] <morphis> jdstrand: however its the question if we want to give any app access to that
[14:43] <morphis> a new build app should definitely go with bluez rather than bluetooth-control
[14:43] <jdstrand> pcoca: do you have time to iterate here?
[14:44] <jdstrand> morphis: 'a new build app'?
[14:45] <morphis> jdstrand: for those building new Apps especially for Ubuntu Core
[14:45] <jdstrand> morphis: note that bluetooth-control is not auto-connected
[14:45] <jdstrand> I see what you mean
[14:45] <jdstrand> as it stands, both bluez and bluetooth-control do not autoconnect
[14:45] <morphis> jdstrand: especially for bluetooth low energy a lot people tend to use the raw kernel APIs today because bluez had it api just experimental for a long time
[14:46] <mup> PR snapcraft#715 closed: Add artifacts option to make plugin <Created by jhobbs> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/715>
[14:46] <jdstrand> that seems to be the case with sensortag
[14:47] <morphis> so this migh have the potential to conflict with a running bluez and also gets privileged access to the whole bluetooth subsystem
[14:49] <jdstrand> this may need an architects discussion. we've not had a situation where one interface might conflict with a slot implementation
[14:55] <mup> Bug #1610292 opened: Snap installed with --devmode can't use sudo <amd64> <apport-bug> <yakkety> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1610292>
[15:04] <ppisati_> awe: append "dtparam=audio=on" to config.txt and reboot
[15:04] <awe> thanks ppisati_!!!
[15:04] <ppisati_> awe: i tested it rhtough the 3.5jack (and i had to disconnect the hdmi cable)
[15:04] <ppisati_> or i didn't hear anything
[15:04] <ppisati_> ubuntu@raspi3:~$ cat /proc/asound/cards
[15:04] <ppisati_>  0 [ALSA           ]: bcm2835 - bcm2835 ALSA
[15:04] <ppisati_>                       bcm2835 ALSA
[15:04] <awe> right, in theory as long as both outputs are available
[15:05] <ppisati_> after appending that line and rebooting
[15:05] <awe> you can switch using amixer
[15:05] <awe> cool
[15:05] <ppisati_> awe: can you?
[15:05] <ppisati_> no idea
[15:05] <ppisati_> i found that, pulled out the hdmi cable, installed mpg123 and played an .mp3 file
[15:05] <ppisati_> ogra_: FYI ^
[15:05] <awe> https://www.raspberrypi.org/documentation/configuration/audio-config.md
[15:05] <ppisati_> awe: :O
[15:08] <ogra_> ppisati_, ah, cool ... is that true for both pi's ?
[15:09] <ppisati_> ogra_: tested only on the pi3, but i betit works the same on pi2
[15:09] <ogra_> yeah
[15:09] <ogra_> so i guess we should ste that by default in our config.txt
[15:09] <ppisati_> makes sense
[15:12] <ogra_> jdstrand, do you have any idea about bug #1610292 (there is also  https://lists.ubuntu.com/archives/snapcraft/2016-August/000655.html discussing that)
[15:12] <mup> Bug #1610292: Snap installed with --devmode can't use sudo <amd64> <apport-bug> <yakkety> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1610292>
[15:12] <ogra_> i'm not sure we want snaps to randomly ship /etc/sudoers.d snippets
[15:12] <jdstrand> ogra_: what do you mean be 'any idea'?
[15:12] <ogra_> how to solve it in a secure way
[15:13] <ogra_> in the ML discussion zyga proposed to have a service that runs as root that the user driven app can attach to instead of using sudo for example
[15:14] <jdstrand> otoh it is really thorny
[15:14] <jdstrand> that service would be attacked like crazy
[15:14] <ogra_> i find the whole idea of a sudo interface a bit horrid TBH
[15:14] <ogra_> would it ? if it only allows connections from within the snap ?
[15:15] <jdstrand> yes
[15:15] <ogra_> (so only the shiped user app can attach to it)
[15:15] <jdstrand> "here, I'll run things for you as root"
[15:15] <didrocks> elopio: I'm quite busy (focusing on finishing some things for a demo before going on holidays tomorrow), so maybe once I'm back?
[15:15] <ogra_> well, but every service does that anyway
[15:15] <jdstrand> what are you referring to?
[15:15] <ogra_> daemons run as root ...
[15:16] <jdstrand> what we allow in interfaces is talking to services that do certain things
[15:16] <ogra_> if i ship a daemon that only allows a shipped enduser app from the same snap to attach to it, i effectively dont need sudo
[15:16] <jdstrand> we don't have any services that run arbitrary commands as root
[15:16] <jdstrand> you don't need sudo to talk to the service, but the service doesn't just do what you want
[15:17] <jdstrand> this service is "connect to me and I'll do anything you ask"
[15:17] <ogra_> well, in devmode it would
[15:17] <elopio> didrocks: sure, ping me when you have the time.
[15:17] <ogra_> the bug is about using sudo with devmode snaps (which currently doesnt work)
[15:18] <jdstrand> is it though? as soon as devmode works people will want it for strict
[15:18] <ogra_> hah
[15:18] <jdstrand> I also don't see his response in my inbox...
[15:18] <ogra_> so your opinion is "no sudo at all" ?
[15:18] <ogra_> whose ? zyga's ?
[15:19] <ogra_> that was from august 8th
[15:20] <jdstrand> my opinion is that it is very thorny and it needs to be thought through extremely carefully
[15:20] <ogra_> yeah, i'm not a fan of it at all
[15:20]  * jdstrand notes that the subject is "Using sudo from within a snap" -- there is no mention of devmode in that snap. mark my words, people will immediately ask for it
[15:20] <jdstrand> in strict mode
[15:21] <jdstrand> let me read zyga's response'
[15:21] <ogra_> especially since we will get into awful situations with the passwd db  and libnss-extrausers inside the core snap too
[15:21] <ogra_> "Using sudo from within a snap" refers to two bugs ... one is the above one
[15:21] <jdstrand> yes
[15:22] <ogra_> the other is the secure_path fix that mvo landed yesterday
[15:23] <jdstrand> I suppose something along the lines of gksudo that works more like pkexec could possibly work. ie, you have a service that can pop up a dialog. but how does that work with cli? it is very messy
[15:24] <jdstrand> I see zyga's response on the 8th but I don't see where he is suggesting a sudo service
[15:24] <jdstrand> oh, I think I see what you mean
[15:24] <jdstrand> an app could ship a root daemon that the cli could talk to
[15:24] <mvo> zyga: hm, bug #1607710 is interessting,
[15:24] <mup> Bug #1607710: Home directories listed in /etc/passwd should be honoured <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
[15:25] <jdstrand> that isn't sudo. sudo is 'let me run this outside of confinement'
[15:25] <cwayne> jdstrand: ogra_ would using pkexec be preferable to sudo?
[15:25] <jdstrand> pkexec isn't allowed either, so not at this time
[15:25] <cwayne> the impetus for sending out that mail is that checkbox runs some tests as root, and its currently trying to just use sudo and failing
[15:25] <jdstrand> this is a fundamental issue
[15:25] <jdstrand> snaps are by definition tightly confined
[15:25] <ogra_> yyeah
[15:26] <jdstrand> allowing them to use sudo to break out of confinement as root doesn't really work
[15:26] <cwayne> well its not necessarily trying to break out of confinement, some confined things need root (like bluez-tests)
[15:27] <jdstrand> that is different
[15:27] <jdstrand> snap commands should be able to talk to their daemons
[15:28] <jdstrand> we shouldn't block that (but that is largely up to the snap daemon to set up things in a way for that to happen
[15:28] <sborovkov> niemeyer: that plymouth patch works, thanks!
[15:28] <jdstrand> )
[15:28] <jdstrand> but the example in the bug is checkbox. checkbox wants to run things outside of itself
[15:29] <jdstrand> it really wants to have an unconfined interface
[15:29] <jdstrand> I suppose an argument could be made that devmode snaps should be able to use sudo. but the mailing doesn't say that
[15:30] <jdstrand> mailing list*
[15:30] <jdstrand> and reading the bug more closely-- it should work
[15:31] <jdstrand> the problem in the bug is "Any call to sudo fails with the error "pkexec must be setuid root""
[15:31] <jdstrand> why is sudo calling pkexec?
[15:31] <jdstrand> the problem here is that pkexec is not installed in the core snap
[15:33] <cwayne> https://www.irccloud.com/pastebin/8j0nZM46/
[15:33] <ogra_> jdstrand, well, it seesm to be shipped with the checkbox snap ...
[15:33] <cwayne> spineau: ^ for context
[15:33] <ogra_> else it wouldnt print the error
[15:34] <ogra_> (unless the sudo error is simply misleading)
[15:35] <jdstrand> ogra_: yes, but as the bug said, the setuid bit is stripped
[15:35] <ogra_> as always in snaps :)
[15:35] <jdstrand> I guess what is happening is sudo pkexec ...
[15:35] <ogra_> uuuh
[15:35] <ogra_> kind of overzealous :)
[15:35] <jdstrand> or sudo wrapper.that.calls.pkexec ...
[15:36] <ogra_> cwayne, is pkexec inside your snap ?
[15:36] <jdstrand> cause sudo itself won't call pkexec
[15:36]  * jdstrand just grep the sudo source code
[15:37] <jdstrand> grepped*
[15:37] <ogra_> i wonder if they could just ship gksudo instead
[15:37] <ogra_> iirc that only acts as frontend ... so wont need to be suid root
[15:39] <spineau> cwayne: do you have the bug id jdstrand is referring to?
[15:39] <ogra_>  Bug #1610292
[15:39] <mup> Bug #1610292: Snap installed with --devmode can't use sudo <amd64> <apport-bug> <yakkety> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1610292>
[15:39] <spineau> thx
[15:40] <jdstrand> well, gksudo pkexec won't work either :)
[15:40] <ogra_> note that most of the discussion around it was on the mailing list though
[15:40] <ogra_> jdstrand, heh ... no, but gksudo /path/to/binary will
[15:40] <ogra_> as long as it has access to sudo
[15:41] <spineau> I know that plainbox as the deb package depends on pkexec/policykit but since we're now pulling it from pypi I'm wondering which parts pulls in pkexec into the snap
[15:41] <jdstrand> I commented in the bug
[15:42]  * jdstrand suspects that sudo /path/to/binary will too
[15:42] <zyga> mvo: I saw that bug, it is the evolution of the jenkins-cannot-run-snaps-bug
[15:43] <zyga> jdstrand: checkbox is a different thing
[15:43] <zyga> jdstrand: it's not about running unconfined
[15:43] <cwayne> ogra_: it seems to, not sure where its from though
[15:43] <zyga> jdstrand: the idea is to precisely run confined because the tests will exercise the interface
[15:43] <zyga> jdstrand: root or user is another angle, it's not the unconfined root that is needed
[15:43] <jdstrand> zyga: the bug very clearly references 'checkbox-snappy'
[15:44] <mup> Bug #1613775 opened: Symlinks in home directory doesn't work with snap home plugin <Snappy:New> <https://launchpad.net/bugs/1613775>
[15:44] <zyga> jdstrand: checkbox also wants to do profile transitions so tha checkbox can run two tests, each with different plugs (for example) but this is another story
[15:44] <jdstrand> I know
[15:44] <zyga> jdstrand: I think we should let checkbox use sudo-to-be-confined-root
[15:44] <jdstrand> I decided to focus on the devmode not working angle
[15:45] <zyga> jdstrand: oh!
[15:45] <zyga> jdstrand: that's the glibc bug, right?
[15:45] <jdstrand> instead of trying to shove checkbox into a strict mode snap or to let arbitrary snaps run sudo
[15:45] <jdstrand> no
[15:45] <joc_> cwayne: https://git.launchpad.net/~checkbox-dev/checkbox/+git/checkbox-parts/tree/snapcraft.yaml#n22
[15:45] <jdstrand> it is that pkexec is not in the core snap and that pkexec in the app snap gets its setuid bit stripped
[15:46] <jdstrand> and something in the snap ends up calling pkexec
[15:46] <zyga> jdstrand: ah, I see
[15:46] <jdstrand> but the error makes it look like sudo is complaing
[15:46] <zyga> yes
[15:46] <zyga> I know, I wrote that code
[15:46] <zyga> joc_, spineau: I know exactly what calls pkexec
[15:46] <joc_> i have no doubt :)
[15:47] <spineau> zyga: the warmup?
[15:47] <zyga> there's a execution controller for pkexec and sudo, if sudo doesn't work we do use pkexed
[15:47] <zyga> pkexec
[15:47] <zyga> spineau: not even warmup, any tests that wants to run as root
[15:48] <jdstrand> sudo not able to work right in devmode is something that can be worked through
[15:48] <jdstrand> would just need more details (and to be assigned to look at it)
[15:49] <cwayne> spineau: ^ would you be able to provide those details (as in what plainbox is actually trying to do when it gets denied)
[15:49] <spineau> zyga: we have two controllers which should return a negative score then, RootViaPTL1ExecutionController and RootViaPkexecExecutionController
[15:50] <spineau> if both return -1 then only sudo remains possible
[15:52] <spineau> cwayne: I'd like first to remove pkexec from the problem to have plainbox running jobs as root only with sudo and see what breaks exactly
[15:53] <spineau> cwayne: context here is devmode + sudo, not our second issue with sudo + confinement
[15:54] <cwayne> right
[15:54] <cwayne> we have so many issues :)
[15:54]  * spineau should turn sentences is in a more positive way
[15:56] <zyga> spineau: we have so many issues but we used to have more and we are healthy!
[15:57] <spineau> cwayne: zyga: I can update plainbox to return -1 for the two controllers using pkexec as a backend. Once merged I can update plainbox on pypi so that future snap builds can just use sudo. From there we will be able to iterate.
[15:57] <spineau> I don't want to bother our snappy experts with plainbox internals
[15:58] <spineau> if we can make sure that we are no longer call pkexec internally it will help diagnosing the problem
[16:06] <cwayne> +1
[16:07] <mup> PR snapcraft#725 closed: Support having the snapcraft.yaml in a subdir <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/725>
[16:36] <marcoceppi> I need help with Python2 plugin, getting this error
[16:36] <marcoceppi> /usr/bin/env: 'python2': No such file or directory
[16:37] <marcoceppi> when running python scripts from inside my snap
[16:41] <kyrofa> marcoceppi, are you actually exporting the scripts using the `apps` in the YAML?
[16:41] <marcoceppi> kyrofa: I guess so?
[16:41] <kyrofa> marcoceppi, or are you calling them directly?
[16:42] <marcoceppi> kyrofa: http://paste.ubuntu.com/23062172/
[16:42] <marcoceppi> there's a golang tool that uses $PATH to find plugins
[16:42] <marcoceppi> charm-tools, provides a suite of plugins in Python
[16:48] <kyrofa> marcoceppi, hmm... and bin/charm seems to be provided by the go part, not python?
[16:48] <marcoceppi> kyrofa: yes, and that works
[16:48] <marcoceppi> but running any of the subcommands which are pythjon result in the aforementioned error
[16:49] <kyrofa> marcoceppi, can you pastebin the contents of /snap/charm/current/charm.command (I think)?
[16:49] <kyrofa> Or charm-command... something like that
[16:50] <marcoceppi> kyrofa: /snap/charm/current/command-charm.wrapper: http://paste.ubuntu.com/23062186/
[16:51] <kyrofa> marcoceppi, ohhhhhh
[16:51] <kyrofa> I know what's happening
[16:51] <marcoceppi> I am so ready for thsi
[16:51] <kyrofa> marcoceppi, your use of the `snap` keyword on the charm-tools part is a whitelist
[16:51] <kyrofa> marcoceppi, you're not actually including python :P
[16:51] <kyrofa> marcoceppi, perhaps you want to turn it into a blacklist instead?
[16:52] <marcoceppi> no, I want those included
[16:52] <marcoceppi> they weren't being included before
[16:52] <marcoceppi> well I want like EVERYTHING included
[16:52] <marcoceppi> everything I need to make this work
[16:52] <mup> PR snapcraft#732 opened: Remove store dispute logic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/732>
[16:53] <marcoceppi> kyrofa: so I need to inlucde like $SNAP/usr/lib/python2.7/* in my whitelist?
[16:54] <kyrofa> marcoceppi, hmm... it should include everything placed by the setup.py
[16:54] <kyrofa> marcoceppi, in addition to python and other prereqs of the plugin
[16:55] <marcoceppi> kyrofa: redherring, I found the issue
[16:58] <mup> PR snapcraft#730 closed: Clarification of make plugin help text <Created by mikemccracken> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/730>
[17:00] <kyrofa> marcoceppi, okay, good deal
[17:10] <mup> PR snapcraft#658 closed: parser - Return non-zero code for wiki errors <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/658>
[17:58] <stokachu> how can i make snap refresh keep the --devmode flag?
[18:01] <marcoceppi> I'm an upstream developer, and my project name isn't available
[18:01] <marcoceppi> no one has answered my dispute yet
[18:02] <kyrofa> marcoceppi, talk to nessita
[18:04] <nessita> marcoceppi, hi! what's your project name?
[18:12] <marcoceppi> nessita: charm
[18:22] <mup> PR snapd#1681 opened: tests: test `snap run --hook` using in-tree snap-exec <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1681>
[18:28] <mup> PR snapd#1689 opened: spread: disable re-exec to always test development tree <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1689>
[18:29] <balloons> jdstrand, did the new snap-confine restrict things further? I can't seem to use lxd with the juju snap anymore, despite --devmode
[18:34] <jdstrand> balloons: it switched how bind mounts are applied, which might break devmode for you. can you file a bug against snap-confine? zyga, fyi ^
[18:35] <balloons> jdstrand, I certainly can. I was just going a bit crazy feeling like I'd done something wrong. Good to know
[18:36] <marcoceppi> nessita: is there anything else I need to do?
[18:40] <balloons> zyga, jdstrand, file here https://github.com/snapcore/snap-confine/issues? Also as a side note, would we consider this a regression? I'm curious how long the package will be broken
[18:41] <nessita> marcoceppi, checking the status
[18:41] <nessita> marcoceppi, I only see charm-tools and not charm
[18:41] <nessita> marcoceppi, and the comment you added sounds like is a temporary name? you still need it?
[18:42] <marcoceppi> nessita: I see this:
[18:42] <nessita> marcoceppi, hum, sorry, found charm in another queue
[18:42] <jdstrand> balloons: https://bugs.launchpad.net/snap-confine/+filebug
[18:42] <marcoceppi> nessita: charm Pending name dispute review
[18:42] <nessita> marcoceppi, yeah, dispute review was a different queue, checking now
[18:42] <marcoceppi> charm-tools was my attempt to register a name while waiting for charm to be reviewed
[18:43] <jdstrand> balloons: as for a regression, probably, and I would expect it to be fixed reasonably soon
[18:43] <jdstrand> balloons: but when would be up to zyga (he is preparing a new release now and may or may not want to include this fix in it)
[18:45] <balloons> jdstrand, interesting.. small diff that broke things; https://launchpadlibrarian.net/276007118/snap-confine_1.0.38-0ubuntu0.16.04.3_1.0.38-0ubuntu0.16.04.4.diff.gz
[18:46] <nessita> marcoceppi, see u1-internal please
[18:52] <jdstrand> balloons: that's curious. 1.0.38-0ubuntu0.16.04.3 worked for you and 1.0.38-0ubuntu0.16.04.4 does not? Definitely worth mentioning in the bug
[18:53] <bladernr> are there any docs or pointers floating around with info on how to get around "make install" needing root permissions when using the autotools plugin?
[18:57] <bladernr> It is building successfully, but then tries to do a make install and fails changing permissions:  http://paste.ubuntu.com/23062496/
[19:00] <stokachu> are there any snap examples where it tries to create it's own network bridge?
[19:01] <kyrofa> bladernr, why does it need root:root there?
[19:01] <stokachu> basically this https://lists.ubuntu.com/archives/snappy-app-devel/2015-November/000477.html
[19:01] <kyrofa> That doesn't seem like a normal thing
[19:02] <bladernr> kyrofa, no idea... (*I'm not a C guy, I can basically read makefiles, but am not an expert.  I see what you're talking about now, I didn't notice that before).
[19:03] <bladernr> I have a feeling it's because on a regular system, its make install copies to /bin, which does need root permissions to copy into
[19:03] <bladernr> thanks, I didn't notice that before though, I'll play with that some more
[19:10] <zyga> balloons: do you have more details
[19:11] <balloons> zyga, hey. I can play with the setup as much as you'd like right now. What are you curious about?
[19:12] <zyga> balloons: what broke
[19:12] <zyga> balloons: is there a bug report?
[19:12] <balloons> zyga, basically as the bug says my old juju snaps don't bootstrap with LXD anymore. Essentially the socket isn't found I gues
[19:12] <balloons> zyga, https://bugs.launchpad.net/snap-confine/+bug/1613845.
[19:12] <mup> Bug #1613845: Juju snap can no longer interact with LXD in devmode <conjure> <Snappy Launcher:New> <https://launchpad.net/bugs/1613845>
[19:13] <zyga> balloons: where is the lxd socket?
[19:13] <balloons> zyga, I was starting to play with versions to try and pinpoint which exact version broke it. My initial description highlighted a version, but I'm not positive it was the first one to break
[19:15] <balloons> zyga, /var/lib/lxd/unix.socket
[19:15] <zyga> balloons: thank you
[19:23] <zyga> balloons: /var/lib is not bind mounted so you get what you'd get in an all-snap system (read only content of the core snap)
[19:23] <balloons> zyga, and this presumably has changed from before right?
[19:23] <zyga> balloons: services should use /run or for sockets AFAIR (sadly we cannot support arbitrary locations)
[19:23] <zyga> balloons: not directly, the change is the use of chroot, in the past we bind mounted a few directories from the core snap to the root fs
[19:24] <zyga> balloons: now we chroot to the core snap and bind mount some things from there
[19:24] <zyga> balloons: this is consistent with all-snap images and works on any distribution
[19:24] <zyga> balloons: can lxd use another location for the socket?
[19:26] <zyga> slangasek, mwhudson; https://github.com/snapcore/snap-confine/pull/108/files
[19:26] <mup> PR snap-confine#108: Remove packaging <Created by zyga> <https://github.com/snapcore/snap-confine/pull/108>
[19:27] <balloons> zyga, in theory yes. In practice, I've no real idea. But I can't imagine it would be a quick or even desirable change. LXD is stable now and the socket is where I told you it was
[19:27] <zyga> balloons: looking at the core snap, I don't see /var/lib/lxd there, we'd have to bind-mount all of /var/lib
[19:27] <zyga> balloons: but it cannot be there because that's a read only location for the core snap
[19:28] <zyga> balloons: even in devmode
[19:28] <stokachu> zyga: but it worked before
[19:28] <zyga> balloons: while it may be stable snapd cannot support random locations that particular package can wish because there's no way to do that without adding all those locations to hte core snap
[19:28] <stokachu> zyga: and since snap is GA this is considered a regression, no?
[19:29] <zyga> stokachu: read what I said above, that didn't work on all snap images and the way we worked on classic was problematic for other reasons, there's no good change but I believe that this change is better as it is consistent in behavior across systems
[19:29] <zyga> stokachu: I don't think so
[19:29] <stokachu> zyga: except it breaks our ability to use lxd inside a snap
[19:29] <stokachu> where we could before
[19:29] <balloons> zyga, I think the is part of the crux of the matter. It kills the story if we can't fix it
[19:29] <zyga> stokachu: it breaks lxd as a snap in all-snap systems, it would never work there :/
[19:30] <zyga> balloons: it's all software, we can fix it
[19:30] <zyga> balloons: the question is how
[19:30] <stokachu> zyga: right but it *worked* before
[19:30] <stokachu> juju could access lxd inside a snap
[19:30] <zyga> stokachu: but other things did not
[19:30] <balloons> zyga, right. I'm saying insomuch as stokachu points out, you've SRU'd this and broken existing snaps
[19:30] <stokachu> right so you've introduced a regression
[19:30] <balloons> so I don't think you can make this change until you've fixed it -- if that means in LXD or wherever
[19:31] <zyga> balloons: I understand that; I'm saying that we cannot always keep things working, in this case lxd worked beause it relied on something that is not a feature
[19:31] <zyga> balloons: if we revert the chroot we'll break every other distribution and a few things on ubuntu
[19:31] <stokachu> zyga: uhm no
[19:31] <balloons> zyga, right. And I feel like for xenial the right thing to do is let it stay the same. Is that not possible?
[19:32] <zyga> balloons: no
[19:32] <zyga> balloons: can we talk to stgraber to find a solution please
[19:32] <stokachu> zyga: you can't just introduce a regression in a LTS release
[19:32] <zyga> stokachu: even if something worked because it relied on a bug?
[19:32] <stokachu> zyga: you introduced a regression in a LTS release
[19:32] <stokachu> bottom line
[19:32] <zyga> stokachu: lets not spin this this way, let's find a way for lxd ot work
[19:33] <balloons> zyga, yes finding a more permanent solution with LXD is a good idea. However, I'm worried about other snaps that may be broken for similar reasons
[19:33] <balloons> also thinking about https://bugs.launchpad.net/snappy/+bug/1604967
[19:33] <mup> Bug #1604967: Apparmor denies bind to abstract unix sockets such as @/var/lib/juju/mutex-/store-lock <conjure> <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1604967>
[19:33] <zyga> stokachu: fixing a bug regresses software that relied on the bug, we're making many changes to snapd, we're hoping to keep software compatible but it's not always possible
[19:33] <stokachu> zyga: how can you call this GA then?
[19:34] <stokachu> you give us no guarantee
[19:34] <zyga> stokachu: does GA say "it is not changing ever"?
[19:34] <stokachu> LTS does
[19:34] <stokachu> dont introduce regressions in an LTS release
[19:34] <zyga> this is not a constructive discussion, let's find a way to fix the problem
[19:34] <zyga> not discuss acronyms
[19:35] <zyga> stokachu:  is https://bugs.launchpad.net/snappy/+bug/1604967 a regression?
[19:35] <mup> Bug #1604967: Apparmor denies bind to abstract unix sockets such as @/var/lib/juju/mutex-/store-lock <conjure> <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1604967>
[19:35] <stokachu> that never worked in strict mode
[19:35] <stokachu> so no.. it's not a regression
[19:35] <zyga> stokachu: ok
[19:36] <stokachu> you've broken things that run in --devmode
[19:36] <zyga> stokachu: as for /var/lib/lxd, I need to investigate options
[19:36] <balloons> zyga, that bug is talking about strict mode indeed. But the idea is, lxd is hardly the only bit of software to use an abstract socket. And they are not going to be in /run
[19:36] <zyga> stokachu: the old way to run snaps was not sustainable, this was done many releases ago, it was never released via SRU becasue of other issues, I'm sorry that it broke lxd and I will look for solutions
[19:37] <stokachu> zyga: thank you
[19:37] <zyga> balloons: how would that snap work in all-snap device where that location is read only?
[19:37] <zyga> (worse, that location doesn't exist)
[19:37] <stokachu> zyga: you seem to be forgetting about people who needs to run snaps on servers
[19:38] <balloons> zyga, the way I see it is that, that problem of everything running under strict mode and with a read-only core is something to work towards
[19:38] <balloons> if you go down that path too early for --devmode, we can't begin adoption
[19:39] <zyga> stokachu: I'm saying that yes, the snap was running in a particular distribution with a particual layout but would not work elsewhere, that's not hte promise of snaps, while I don't want to break anything the change was made to improve support in general
[19:39] <stokachu> zyga: then break it in yakkety
[19:39] <stokachu> not in xenial
[19:39] <balloons> zyga, can we not differentiate breaking it under --strict mode, but not under --devmode?
[19:39] <zyga> stokachu: that's not as simple as that, this is a fundamental way that in which snaps work
[19:40] <zyga> balloons: snap-confine doesn't do anything differntly in devmode
[19:40] <zyga> stokachu, balloons: FYI: http://www.zygoon.pl/2016/08/snap-execution-environment.html
[19:41] <zyga> I know this change is somehing that you don't like because it broke the software you want to use but I'm saying that we had to make the change
[19:41] <zyga> I'll stop arguing because it seems to lead nowhere
[19:41] <zyga> I will look for solutions
[19:42] <balloons> zyga, I'm asking for snap-confine to treat dev-mode differently. To allow it to make poor choices so that all the other good parts of snappy can be used. It's about keeping the initial adoption barrier as low as possible
[19:43] <zyga> balloons: read my blog post first, what you are asking for is not something that can be done, if we go back to the old way of constructing the filesystem we will just break other things again
[19:43] <zyga> balloons: let me discuss this with the team and get back to you with solutions
[19:43] <balloons> zyga, ok. And presumably everything must change at the same time -- xenial cannot be treated differently?
[19:44] <zyga> balloons: that's another story, we can explore that
[19:45] <balloons> zyga, so it sounds like there may be solutions on your end. Good. It's worth thinking very carefully about raising the barrier for --devmode
[19:45] <balloons> zyga, please do keep me in the loop -- I'm happy to talk about it
[19:45] <zyga> balloons: note that before there were also read-only locations
[19:45] <zyga> balloons: devmode never affected that
[19:52] <zyga> stokachu: FYI, yakkety uses 'series 16' so it shares the same snap and snapd as xenial, in fact they are exactly the same and share the same core snap which contains snapd and snap-confine (so while we might want to do something special in xenial only the design of snap makes it really tricky). I'm looking at a solution that will fix it everywhere (including on all the other supported distributions)
[19:52] <stokachu> k thanks
[19:57] <zyga> ogra_: ping
[19:57] <ogra_> zyga, moop
[20:18] <bladernr> Ok... so I built a snap... put it in the store, and published.  How do I find it?
[20:18] <bladernr> How do I install it?
[20:18] <bladernr> snap find returns nothing, even after logging into the store
[20:19] <qengho> bladernr: How did you upload?
[20:19] <bladernr> uhhh... snapcraft upload <snap>
[20:20] <bladernr> https://myapps.developer.ubuntu.com/dev/click-apps/
[20:20] <bladernr> http://snapcraft.io/docs/build-snaps/publish following this
[20:21] <bladernr> Oh wait... why is it listed as a click app?
[20:21] <qengho> bladernr: So, at myapps, you see your app? If you click on a release, do you see "Status: Published" and "Channels: ...Stable" and "Supported releases: 16"?
[20:21] <bladernr> https://myapps.developer.ubuntu.com/dev/click-apps/5728/rev/1/  or do both click apps and snaps go into the clic-apps dir
[20:21] <zyga> bladernr: did you publish it into the stable channel
[20:22] <bladernr> it is now
[20:23] <bladernr> I thought I did that before, but its targeted to all
[20:23] <bladernr> ahhh, ok.  there she be
[20:26] <marcoceppi> so I have a snap in the edge channel, but when I got to install it
[20:26] <marcoceppi> error: cannot perform the following tasks:
[20:26] <marcoceppi> - Download snap "charm" (1) from channel "edge" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/2Rryoc2ylScfbFl4eQtpntHD9iuZuMvt_1.snap)
[20:26] <marcoceppi> I get a 401? the item is public and published
[20:29] <marcoceppi> had to log into the store, that error is super unhelpful
[20:30] <qengho> 4nn is client-side error, asserted from the server. Doesn't sound like your package is the problem.
[20:31] <qengho> marcoceppi: Oh, did it work then?
[20:32] <marcoceppi> qengho: yes
[20:32] <qengho> $ ubuntu-bug snapd   #file a bug report!
[20:50] <zyga> stokachu: I talked to jdstrand and we have a plan for the fix that can be rolled out quickly; I'm working on the fix now
[20:50] <zyga> balloons: ^^
[20:51] <balloons> zyga, ty!
[20:53] <marcoceppi> I've got a problem with temp directories in Python not being created? within a snap
[20:54] <marcoceppi> http://paste.ubuntu.com/23062754/
[20:54] <zyga> marcoceppi: can you report a bug with some more details (tracebacks, denials, etc)
[20:54] <marcoceppi> I wonder if this is just an issue with git in snaps? has anyone had any problems with athat?
[20:55] <zyga> marcoceppi: remmeber that /tmp is a fresh tmpfs when you start a snap application
[20:55] <marcoceppi> zyga: where do aarmor messages pop up?
[20:55] <marcoceppi> zyga: sure, which is fine(?) or should be for this
[20:55] <zyga> marcoceppi: I think so
[20:55] <zyga> marcoceppi: try journalctl -f
[20:56] <zyga> marcoceppi: and run your app again
[20:56] <zyga> marcoceppi: FYI: http://www.zygoon.pl/2016/08/snap-execution-environment.html (and grep for /tmp)
[20:56] <zyga> marcoceppi: nothing new but perhaps you'll get an idea why it failed
[20:57] <marcoceppi> zyga: so I'm getting a denial, but for /etc/apt/apt.conf.d which is for an apt look up, but it hsouldn't affect this git clone attempt
[20:58] <zyga> I agree
[20:59] <marcoceppi> zyga: per process? so if I run a command, /snap/bin/charm create, for example, which then has a few subprocess calls, one being git clone to /tmp - does that mean that subsequent subprocess calls or file operations during the execution of /snap/bin/charm would get fresh tmp? or is it per invocation of /snap/bin/charm ?
[20:59] <zyga> marcoceppi: yes, per process
[21:00] <zyga> marcoceppi: ah, not per per process
[21:00] <zyga> marcoceppi: per top-level snap application
[21:00] <marcoceppi> cool, so that should be fine
[21:00] <zyga> (process)
[21:00] <zyga> it is per invocation of /snap/bin/charm
[21:01] <marcoceppi> so, maybe it's really git that's failing, it seems to complain about /usr/share/git-core/templates even though that's in the prime
[21:07] <ali1234> when do they get cleaned up?
[21:10] <zyga> marcoceppi: is it reading it from /snap/$SNAP_NAME/current/usr/share/git-core/templates or from /usr/share/git-core/templates
[21:10] <zyga> marcoceppi: the prime directory is not the root filesystem
[21:11] <zyga> marcoceppi: if it opens /usr/share/git-core/tempates those are not going to be there
[21:11] <marcoceppi> zyga: well, considering aa hasn't yelled at me, I assume it's from $SNAP
[21:11] <zyga> jdstrand: ^^ another thing we could actually map with the quirk code
[21:11] <zyga> marcoceppi: I doubt it is from $SNAP
[21:11] <zyga> marcoceppi: unless git is configured to do so in some way
[21:12] <marcoceppi> zyga: well, isn't it all chrooted?
[21:12] <marcoceppi> git is installed in my snap, etc
[21:12] <marcoceppi> /snap/charm/current/usr/share/git-core/templates exists
[21:12] <zyga> marcoceppi: no the way you think IMHO
[21:12] <zyga> marcoceppi: please read my blog post (the one I linked to)
[21:16] <mup> PR snapd#1322 closed: daemon, overlord/auth: refactor auth in preparation for other credential types <Reviewed> <Created by wgrant> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1322>
[21:19] <marcoceppi> okay
[21:19] <marcoceppi> so how do I troubleshoot this
[21:20] <marcoceppi> because aa isn't complaining, the software isn't working, and I'm left without a real clear way to poke things
[21:21] <zyga> marcoceppi: I bet that what I said above is true, if git can be configured in some way then as a trick, use --prefix of /snap/$SNAP_NAME/current/usr and then use organize so that the prime directory has just the final /usr directory in the snap
[21:21] <marcoceppi> so, the snap has the /usr directory it needs already in there, what you seem to suggest is that I will have to compile git from source to get this t work?
[21:25] <mwhudson> zyga: i don't think i can advocate you as a DM
[21:36] <zyga> mwhudson: that's okay, thanks
[21:37] <zyga> marcoceppi: yes
[21:38] <marcoceppi> well,that's really unfortuantely.
[21:43] <marcoceppi> this seems ridiculous that I have to compile git to get it to work in my snap
[21:43] <marcoceppi> I'm not a git expert, I just depend on the damn thing, and my stabs at getting it to compile have failed thus far
[21:46] <jdstrand> zyga: interesting
[22:36] <zyga> stokachu: i have a patch that fixes it locally (I didn't try with lxd yet but /var/lib/lxd is now writable in devmode and shows my real hostfs /var/lib/lxd)
[23:57] <zyga> balloons, stokachu: https://bugs.launchpad.net/snap-confine/+bug/1613845 is now fixed
[23:57] <mup> Bug #1613845: Juju snap can no longer interact with LXD in devmode <conjure> <Snappy Launcher:Fix Committed by zyga> <https://launchpad.net/bugs/1613845>
[23:57] <zyga> I will work on the SRU process tomorrow
[23:57] <zyga> good night :)