mupPR snapd#1682 opened: interfaces/hardware-observe.go: re-add /run/udev/data <Created by cwayne18> <https://github.com/snapcore/snapd/pull/1682>00:09
=== chihchun_afk is now known as chihchun
mupPR snapd#1663 closed: osutil: fix create-user on classic systems <Created by jaymell> <Closed by jaymell> <https://github.com/snapcore/snapd/pull/1663>04:29
=== LiX is now known as Guest15496
zygagood morning06:40
ljpso only the gadget or os snap is allowed to use gpio?06:42
=== ljp is now known as lpotter
pcocaHi everyone!06:49
pcocaI am getting this Apparmor issue:06:49
pcocaAug 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
pcocaAnd I am using the  plugs: [bluez] on my snapcraft.yaml06:49
pcocaIs there any additional interface that I should use?06:50
lpotterlooks like the mir interface can allow seqpacket06:52
pcocalpotter,  so plugs: [mir, bluez] would do the trick?06:57
pcocalpotter, I am afraid it is not working.07:01
zygalpotter: hey07:01
zygalpotter: let me check if seqpacket is allowed07:02
pcocazyga, lpotter, is used by a BTLE device07:03
pcocazyga, lpotter, otherwise I got the apparmor issue and the snap failed with an error of BTLE addresses.07:04
zygait seems not to be07:05
zygaessentially the apparmor denail you got above said you cannot create a seqpacket socket, try network-bind as a quick workaround07:06
zygapstolowski: cześć :)07:07
pstolowskizyga, czołem!07:08
zygapcoca: let me know if that workaround works for you07:09
pcocazyga, sure, snapping it up now :)07:09
mupPR snapd#1683 opened: osutil: fix create-user on classic <Created by jaymell> <https://github.com/snapcore/snapd/pull/1683>07:11
pcocazyga, It does not work :/07:12
pcocaI still got the same error with Apparmor07:12
pcocausing    plugs: [bluez, network-bind]07:12
zygapcoca: can you please report the bug and give some background on the library/system calls you are using07:18
zygapcoca: please report teh bug on launchpad.net/snappy with snapd-interface tag07:19
mupPR 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:21
pcocazyga, here is: https://bugs.launchpad.net/snappy/+bug/161357207:26
mupBug #1613572:  apparmor denial with sock_type="seqpacket" using a BTLE device <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1613572>07:26
mupBug #1613572 opened:  apparmor denial with sock_type="seqpacket" using a BTLE device <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1613572>07:28
mupPR snapd#1685 opened: snap-exec: Fix broken `snap run --shell` and add test <Created by mvo5> <https://github.com/snapcore/snapd/pull/1685>07:29
zygapcoca: I saw, thank you07:30
zygamwhudson: good morning07:30
zygamwhudson: 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/advocate07:31
mupPR snapd#1686 opened: boot: add support for "devmode: {true,false}" in seed.yaml <Created by mvo5> <https://github.com/snapcore/snapd/pull/1686>07:44
mupPR snapd#1687 opened: release: Remove "UBUNTU_CODENAME" from the test data <Created by mvo5> <https://github.com/snapcore/snapd/pull/1687>07:56
mupBug #1613609 opened: Can't register name for snap package <Snappy:New> <https://launchpad.net/bugs/1613609>08:35
rtsisykhi. I created my first snappy package: https://github.com/tarantool/tarantool/blob/snappy/snapcraft.yaml How I can register "tarantool" name for it?08:38
mupBug #1613609 changed: Can't register name for snap package <Snapcraft:New> <https://launchpad.net/bugs/1613609>08:44
ogra_ogra@anubis:~/datengrab/images/snappy$ /snap/bin/vlc08:45
ogra_multiple nvidia drivers detected, this is not supported08:45
ogra_bah !08:45
ogra_(it isnt really like i need the nvidia drivers for music playback )08:45
mvoogra_: fwiw, I'm testing the fix for the boot problem you noticed on friday right now08:45
mvoogra_: zyga maybe able to help with snap-confine08:46
ogra_mvo, awesome, is it in the edge channel already ?08:46
ogra_(i can manually update when setting snap_try_kernel)08:46
mvoogra_: not yet, I sideloaded for now to double check that I did not mess up uboot.env but if it boots I will upload08:47
ogra_cool, ping me then, i'll do test upgrades without sideloading08:48
mvoogra_: pi2 is published now, please let me know how it goes, I'm updating the dragonboard now08:49
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:50
mvoogra_: that is snap-confine that shows this message08:51
didrocksogra_: no, it's not in the launcher08:51
ogra_on what conditions ?08:51
ogra_didrocks, yeah, seems snap-confine08:52
didrocksyeah ;)08:52
ogra_zyga, on what conditions does snap-confine block executions with nvidia drivers ...08:52
ogra_seems it is rather overzealous08:52
mvoogra_: dragonboard is also uploaded, let me know if you notice any issues please08:55
mupPR 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:56
ogra_mvo, oh08:57
ogra_i got a new gadget too08:57
mvoogra_: the fix is entirely in there08:57
mvoogra_: its also in bzr if you want to double check, once sec, I look for the diff08:58
ogra_wow ... seems my pi2 auto upgraded to 254 already09:00
ogra_(not rebooted though)09:00
ogra_mvo, btw, we need some scriptery in the uboot.env to reboot when it cant load the files09:01
ogra_that would have prevebted the hang09:01
ogra_ok, dragonboard is proper at v3 and ubuntu-core v25309:03
mvoogra_: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/revision/45 and 4609:03
mvoogra_: +1 for magic in uboot09:03
ogra_and pi2 at 14 and 254 ...09:04
ogra_but both had snap_try_kernel set09:04
ogra_i guess i should trigger quickly another ubuntu-core to test without it set09:05
ogra_build kicked ...09:05
ogra_cjwatson, i see very often timeouts when triggering a snap buikld through the LP UI ... current one is OOPS-a9d5e8c47cb69641674e12dd57721fc909:06
ogra_(the build gets triggered fine, just the reload after triggering does time out)09:07
cjwatsonogra_: Thanks.  That one could be fixed with a bit of property caching; please file a bug with the OOPS ID.09:12
ogra_against launchpad itself ?09:13
cjwatsonogra_: yes09:14
cjwatsonogra_: regression in r18036, apparently09:16
mvojaymell: 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 tha09:27
mvot create-user now works on classic :)09:27
=== vrruiz_ is now known as rvr
ogra_** Unable to read file /kernel.img **09:32
ogra_reading /dtbs/apq8016-sbc.dtb09:32
ogra_** Unable to read file /dtbs/apq8016-sbc.dtb **09:32
ogra_reading /initrd.img09:32
ogra_** Unable to read file /initrd.img **09:32
ogra_Bad Linux ARM64 Image magic!09:32
ogra_mvo, ^^^ :/09:32
ogra_(after refresh to the new ubuntu-core that finished a few mins ago)09:33
mvoogra_: 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
mupPR 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:36
draglyis 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_Blokedragly: 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:41
draglyOdd_Bloke: thanks, I'll try that out09:42
mupPR snapd#1688 opened: interfaces: add fwupd interface <Created by timchen119> <https://github.com/snapcore/snapd/pull/1688>09:52
ogra_mvo, well, md5 is moot after one boot attempt since it saves vars during boot ... but let me try10:08
mvoogra_: you could dump the entire text and patebinit and I check10:09
ogra_mvo, yeah, the script line differs ...10:09
mvoogra_: meh, ok10:11
* ogra_ copies manually and transfers all the variables needed10:11
ogra_ok, now it works again10:12
ogra_same for rpi10:16
ogra_so i guess the gadget needs some upgrade hook10:17
mvoogra_: yes, I guess short term I need to create new base images10:17
ogra_that too10:17
ogra_mvo, triggering a new ubuntu-core build to test with the new gadget in place now10:26
mvoogra_: ta10:28
* mvo considers lunch10:28
ogra_cjwatson, Bug #1613652 (sorry, took a bit)10:30
mupBug #1613652: timeouts when triggering snap builds <Launchpad itself:New> <https://launchpad.net/bugs/1613652>10:30
zygaSon_Goku: hey, I've updated snap-confine and I'll need another golang package before snapd 2.1111:02
zygaSon_Goku: I've uploaded everything to people.fedoraproject.org, I'll start working on the paperwork for this11:02
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:04
Son_Gokuzyga, have you made any progress on selinux support in snap-confine?11:10
zygaSon_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=136740711:15
zygaSon_Goku: some, I'm working on toy version of snap-confine that fiddles with libselinux11:15
zygaSon_Goku: upstream firefighting is over now, I'm just waiting for reviews and I'll do 1.0.40 release11:15
zygaSon_Goku: I'm back to my regular tasks11:16
zygaSon_Goku: yeah, part of snapd auth code11:16
zygaSon_Goku: (I was surprised that macaroon is not "pasta" but instead is "fancy cookie"11:16
zygaSon_Goku: the polish word for "pasta" is makaron11:16
Son_Gokuoh dear god11:17
Son_GokuI feel stupid now11:17
zygaSon_Goku: I'd like to make snap-confine apply selinux context/labels/thing to the mounted snaps11:18
zygaSon_Goku: haha, why? Did you also think it is about pasta?11:18
Son_Gokuthat, and apparently we should have never importing check11:18
Son_Gokuit already exists: http://koji.fedoraproject.org/koji/packageinfo?packageID=1928311:18
zygathat's odd11:18
zygaI did gofed checks11:18
zygathat's good though11:19
zygaSon_Goku: wait, that's gopkg.in/check.v111:19
zygaSon_Goku: so there are two packages for the same thing?11:20
Son_Gokuyou just added exactly the same package to Fedora11:20
zygaSon_Goku: I'll email the maintainer, maybe those should be merged11:20
Son_Gokuit's clearly an accident11:20
zygaSon_Goku: yeah, the provides for common name could be a way to find those11:21
zygaSon_Goku: golang is still young and packaging guidelines are incomplete and weak, the package I added follows the more strict naming convention11:21
Son_Gokuwell, the biggest problem is because golang is all statically done, there's no easy way to identify everything11:22
Son_Gokuand apparently the provides didn't even exist on that go-check package until Feb of this year11:22
Son_Gokuwhich shows how difficult golang can get11:22
zygayeah, I agree11:23
zygaI think upstream import path/common name should be the only way to map packages11:23
zygaeverything else is wrong11:23
zygaincluding github repo checks (like in this case)11:23
tdrHello, 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_Gokuwhat I'm surprised about is that gofed didn't catch this11:24
Son_Gokuor did you never run gofed on snapd itself?11:24
zygaSon_Goku: I think I didn't run it on snapd11:25
zygaSon_Goku: though at the time the common name import didn't exist11:25
zygaSon_Goku: or .... perhaps I didn't use the common name then11:25
Son_Gokuyou probably didn't use the common name11:25
zygaSon_Goku: in any case, I'm writing to the maintainer now11:25
Son_Gokuyou might want to ask if his version is up to date, and if you can be comaintainer of the package, too11:26
Son_Gokuyou can request the ACLs here: https://admin.fedoraproject.org/pkgdb/package/rpms/golang-gopkg-check/11:26
zygayep, good idea11:26
zygaSon_Goku: how have you been?11:27
Son_GokuI've been alright11:27
zygaSon_Goku: for me the summer is over, it's cold and wet all week11:27
Son_Gokuit's still hot here11:27
Son_Gokuit's a bit rainy at the moment, but still very hot11:27
zygaSon_Goku: it was 10C in the morning today11:28
Son_Gokuit's 73F / 23C right now11:28
Son_Gokuthe high will be 86F / 30C11:29
zygaI 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 north11:29
zygaSon_Goku: sent!11:36
zygaSon_Goku: you're on CC11:36
zygaSon_Goku: I'll look at snapd 2.11, I need to fix something in systemd units (seems like upstream change)11:36
zygaSon_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 soon11:37
zygaSon_Goku: https://github.com/snapcore/snap-confine/pull/103/files11:38
mupPR snap-confine#103: Use downstream packaging in spread tests <Created by zyga> <https://github.com/snapcore/snap-confine/pull/103>11:38
Son_Gokubtw, 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/mdapi11:38
zygaSon_Goku: I support debian and ubuntu, fedora and arch are up next, I just need to land this first11:38
Son_Gokuit's a RESTful API that emits a JSON form of the RPM XML repodata11:38
mvoogra_: that sounds like a bug, it should store the channel, let me double check that11:39
zygaSon_Goku: I have that bookmarked, I need to spend some time on that cross distro monitoring11:39
zygaSon_Goku: I'm really glad most of snap-confine firefighting is over and I can pick up stuff form my backlog again11:39
Son_Gokuboth the Debian guy and myself would really like to see the SELinux integration asap :)11:40
zygaSon_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 lot11:42
Son_Gokudid you learn anything from selinux guys at flock that could help?11:42
zygaSon_Goku: yes, I asked a lot of questions over lunch11:42
zygaSon_Goku: I also got the idea that everything I want to do is doable11:42
zygaSon_Goku: but most importantly, we just had a good time and exchanged contacts11:43
Son_Gokuthat's good11:43
* zyga away for 45 min11:46
sborovkovniemeyer: 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
mupBug #1606212: getpwuid is failing on classic image <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1606212>11:50
ogra_mvo, might be related to me manually tinkering with snap_try_kernel before (and according broken boot attempts alongside)11:52
mvoogra_: maybe, smeels like a bug, if you mail me (privately) /var/lib/snapd/state.json I can check if the DB is correct about it11:56
ogra_will do11:56
mvoogra_: thanks11:56
mupBug #1613686 opened: Consider allowing access to @{PROC}/@{pid}/limits <Snappy:New> <https://launchpad.net/bugs/1613686>12:12
mupPR 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:58
zygaSon_Goku: snap-confine updated again12:59
zygaSon_Goku: I'd love if you can set the reviewed bit now :)12:59
zygaSon_Goku: if you want, all the changes are kept in git for easier review too12:59
Son_Gokupackage approved13:02
zygathank you13:03
Son_Gokumacaroon is approved too13:05
Son_Gokucontingent on your fixes13:05
zygayep, I saw; I'm on a call now but I'll continue with this as the next thing13:06
zygaSon_Goku: I'll push my selinux hacks today, maybe at least to get some feedback from others13:06
Son_Gokuhaving something is better than nothing, imo13:06
=== chihchun is now known as chihchun_afk
* zyga requested snap-confine and the macaroon package in fedora13:20
zyganext up: snapd :)13:20
aweogra_, who's responsible for the config of the rpi2-kernel snap?13:22
ogra_awe, the config ?13:22
ogra_you mean the build configuration ?13:23
awelooks like there aren't any audio devices configured by default13:23
ogra_(the snap just uses the linux-raspi2 and linux-image-raspi2 packages from the archive)13:23
awewhich makes testing pulse rather difficult13:23
ogra_pfft, excuses :P13:23
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:24
* ppisati_ checks13:25
jdstrandmorphis: hi! can you look at https://bugs.launchpad.net/snappy/+bug/1613572/comments/2?13:43
mupBug #1613572:  apparmor denial with sock_type="seqpacket" using a BTLE device <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1613572>13:43
jdstrandmorphis: with the addition of bluetooth-control, I'm not sure where to put the fix13:43
mupPR 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:02
sborovkovjamiebennett: ping14:06
sborovkovjamiebennett: 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
mupBug #1606212: getpwuid is failing on classic image <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1606212>14:09
jamiebennettsborovkov: We keep the code on GitHub, let me see if I can find the branch14:15
jamiebennettniemeyer: ^14:15
niemeyersborovkov: I don't have anything other than what's described there14:17
niemeyersborovkov: The issue mentioned describes why the problem is likely happening, and what the fix is14:17
sborovkovniemeyer: so should I write a similar patch for my app like the one you attached for plymouth14:18
niemeyersborovkov: Not clear if this needs to be in your app or in snapd itself14:18
niemeyersborovkov: It might be a file that we're not shipping in /etc that we could ship and would solve all similar issues14:18
sborovkovYes, that's why I asked. I though you patched snapd. And it would be in ubuntu-core14:18
niemeyersborovkov: Someone needs to dig down and test this theory out14:19
elopiodidrocks: do you want to hangout to get over with this docker hub thing?14:19
niemeyersborovkov: Can you give it a shot?14:19
sborovkovniemeyer: but that patch should work, right? I checked /var/snap/ubuntu-core... and nsswitch.conf was present along with libnss files?14:20
niemeyersborovkov: Even if the fix is in ubuntu-core, having someone verify it would be useful14:20
pcocajdstrand, 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
mupBug #1613572:  apparmor denial with sock_type="seqpacket" using a BTLE device <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1613572>14:20
sborovkovniemeyer: I'll test the patch on the side of my app then14:20
niemeyersborovkov: Thanks, please let me know how it goes14:21
jdstrandpcoca: /var/lib/snapd/apparmor/profiles/snap.sensortag.sensortag14:22
jdstrandpcoca: I left out 'snapd'14:22
pcocajdstrand,  after the line:14:25
pcocaprofile "snap.sensortag.sensortag" (attach_disconnected) {14:25
jdstrandpcoca: anywhere in between the {}. I typically add workarounds before the final '}'14:26
pcocajdstrand, OK14:27
jdstrandOdd_Bloke: you bug 1607710 is not prioritized afaict. if you need it escalated, I suggest talking to jamiebennett14:30
mupBug #1607710: Home directories listed in /etc/passwd should be honoured <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>14:30
pcocajdstrand, Done it. Thanks Jamie. I got now a different error :/ I just updated the bug info.14:32
morphisjdstrand: will have a look14:35
Odd_Blokejamiebennett: 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
mupBug #1607710: Home directories listed in /etc/passwd should be honoured <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>14:36
jamiebennettSounds like zyga may know more on this bug14:37
jdstrandmorphis: basically I wondering about the intent of the bluez interface-- is that only for talking to bluez now or should it give network bluetooth14:41
morphisjdstrand: on the plug side it should only allow dbus api access for bluez14:42
morphisall low level BT stuff should go into bluetooth-control14:42
jdstrandmorphis: ok, so we should add network bluetooth to bluetooth-control14:42
jdstrandgotcha, thanks!14:42
morphisjdstrand: however its the question if we want to give any app access to that14:42
morphisa new build app should definitely go with bluez rather than bluetooth-control14:43
jdstrandpcoca: do you have time to iterate here?14:43
jdstrandmorphis: 'a new build app'?14:44
morphisjdstrand: for those building new Apps especially for Ubuntu Core14:45
jdstrandmorphis: note that bluetooth-control is not auto-connected14:45
jdstrandI see what you mean14:45
jdstrandas it stands, both bluez and bluetooth-control do not autoconnect14:45
morphisjdstrand: 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 time14:45
mupPR snapcraft#715 closed: Add artifacts option to make plugin <Created by jhobbs> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/715>14:46
jdstrandthat seems to be the case with sensortag14:46
morphisso this migh have the potential to conflict with a running bluez and also gets privileged access to the whole bluetooth subsystem14:47
jdstrandthis may need an architects discussion. we've not had a situation where one interface might conflict with a slot implementation14:49
mupBug #1610292 opened: Snap installed with --devmode can't use sudo <amd64> <apport-bug> <yakkety> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1610292>14:55
ppisati_awe: append "dtparam=audio=on" to config.txt and reboot15:04
awethanks 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 anything15:04
ppisati_ubuntu@raspi3:~$ cat /proc/asound/cards15:04
ppisati_ 0 [ALSA           ]: bcm2835 - bcm2835 ALSA15:04
ppisati_                      bcm2835 ALSA15:04
aweright, in theory as long as both outputs are available15:04
ppisati_after appending that line and rebooting15:05
aweyou can switch using amixer15:05
ppisati_awe: can you?15:05
ppisati_no idea15:05
ppisati_i found that, pulled out the hdmi cable, installed mpg123 and played an .mp3 file15:05
ppisati_ogra_: FYI ^15:05
ppisati_awe: :O15:05
ogra_ppisati_, ah, cool ... is that true for both pi's ?15:08
ppisati_ogra_: tested only on the pi3, but i betit works the same on pi215:09
ogra_so i guess we should ste that by default in our config.txt15:09
ppisati_makes sense15:09
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
mupBug #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 snippets15:12
jdstrandogra_: what do you mean be 'any idea'?15:12
ogra_how to solve it in a secure way15:12
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 example15:13
jdstrandotoh it is really thorny15:14
jdstrandthat service would be attacked like crazy15:14
ogra_i find the whole idea of a sudo interface a bit horrid TBH15:14
ogra_would it ? if it only allows connections from within the snap ?15:14
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
didrockselopio: 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 anyway15:15
jdstrandwhat are you referring to?15:15
ogra_daemons run as root ...15:15
jdstrandwhat we allow in interfaces is talking to services that do certain things15: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 sudo15:16
jdstrandwe don't have any services that run arbitrary commands as root15:16
jdstrandyou don't need sudo to talk to the service, but the service doesn't just do what you want15:16
jdstrandthis service is "connect to me and I'll do anything you ask"15:17
ogra_well, in devmode it would15:17
elopiodidrocks: 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:17
jdstrandis it though? as soon as devmode works people will want it for strict15:18
jdstrandI 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:18
ogra_that was from august 8th15:19
jdstrandmy opinion is that it is very thorny and it needs to be thought through extremely carefully15:20
ogra_yeah, i'm not a fan of it at all15: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 it15:20
jdstrandin strict mode15:20
jdstrandlet 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 too15:21
ogra_"Using sudo from within a snap" refers to two bugs ... one is the above one15:21
ogra_the other is the secure_path fix that mvo landed yesterday15:22
jdstrandI 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 messy15:23
jdstrandI see zyga's response on the 8th but I don't see where he is suggesting a sudo service15:24
jdstrandoh, I think I see what you mean15:24
jdstrandan app could ship a root daemon that the cli could talk to15:24
mvozyga: hm, bug #1607710 is interessting,15:24
mupBug #1607710: Home directories listed in /etc/passwd should be honoured <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>15:24
jdstrandthat isn't sudo. sudo is 'let me run this outside of confinement'15:25
cwaynejdstrand: ogra_ would using pkexec be preferable to sudo?15:25
jdstrandpkexec isn't allowed either, so not at this time15:25
cwaynethe impetus for sending out that mail is that checkbox runs some tests as root, and its currently trying to just use sudo and failing15:25
jdstrandthis is a fundamental issue15:25
jdstrandsnaps are by definition tightly confined15:25
jdstrandallowing them to use sudo to break out of confinement as root doesn't really work15:26
cwaynewell its not necessarily trying to break out of confinement, some confined things need root (like bluez-tests)15:26
jdstrandthat is different15:27
jdstrandsnap commands should be able to talk to their daemons15:27
jdstrandwe shouldn't block that (but that is largely up to the snap daemon to set up things in a way for that to happen15:28
sborovkovniemeyer: that plymouth patch works, thanks!15:28
jdstrandbut the example in the bug is checkbox. checkbox wants to run things outside of itself15:28
jdstrandit really wants to have an unconfined interface15:29
jdstrandI suppose an argument could be made that devmode snaps should be able to use sudo. but the mailing doesn't say that15:29
jdstrandmailing list*15:30
jdstrandand reading the bug more closely-- it should work15:30
jdstrandthe problem in the bug is "Any call to sudo fails with the error "pkexec must be setuid root""15:31
jdstrandwhy is sudo calling pkexec?15:31
jdstrandthe problem here is that pkexec is not installed in the core snap15:31
ogra_jdstrand, well, it seesm to be shipped with the checkbox snap ...15:33
cwaynespineau: ^ for context15:33
ogra_else it wouldnt print the error15:33
ogra_(unless the sudo error is simply misleading)15:34
jdstrandogra_: yes, but as the bug said, the setuid bit is stripped15:35
ogra_as always in snaps :)15:35
jdstrandI guess what is happening is sudo pkexec ...15:35
ogra_kind of overzealous :)15:35
jdstrandor sudo wrapper.that.calls.pkexec ...15:35
ogra_cwayne, is pkexec inside your snap ?15:36
jdstrandcause sudo itself won't call pkexec15:36
* jdstrand just grep the sudo source code15:36
ogra_i wonder if they could just ship gksudo instead15:37
ogra_iirc that only acts as frontend ... so wont need to be suid root15:37
spineaucwayne: do you have the bug id jdstrand is referring to?15:39
ogra_ Bug #161029215:39
mupBug #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
jdstrandwell, gksudo pkexec won't work either :)15:40
ogra_note that most of the discussion around it was on the mailing list though15:40
ogra_jdstrand, heh ... no, but gksudo /path/to/binary will15:40
ogra_as long as it has access to sudo15:40
spineauI 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 snap15:41
jdstrandI commented in the bug15:41
* jdstrand suspects that sudo /path/to/binary will too15:42
zygamvo: I saw that bug, it is the evolution of the jenkins-cannot-run-snaps-bug15:42
zygajdstrand: checkbox is a different thing15:43
zygajdstrand: it's not about running unconfined15:43
cwayneogra_: it seems to, not sure where its from though15:43
zygajdstrand: the idea is to precisely run confined because the tests will exercise the interface15:43
zygajdstrand: root or user is another angle, it's not the unconfined root that is needed15:43
jdstrandzyga: the bug very clearly references 'checkbox-snappy'15:43
mupBug #1613775 opened: Symlinks in home directory doesn't work with snap home plugin <Snappy:New> <https://launchpad.net/bugs/1613775>15:44
zygajdstrand: checkbox also wants to do profile transitions so tha checkbox can run two tests, each with different plugs (for example) but this is another story15:44
jdstrandI know15:44
zygajdstrand: I think we should let checkbox use sudo-to-be-confined-root15:44
jdstrandI decided to focus on the devmode not working angle15:44
zygajdstrand: oh!15:45
zygajdstrand: that's the glibc bug, right?15:45
jdstrandinstead of trying to shove checkbox into a strict mode snap or to let arbitrary snaps run sudo15:45
joc_cwayne: https://git.launchpad.net/~checkbox-dev/checkbox/+git/checkbox-parts/tree/snapcraft.yaml#n2215:45
jdstrandit is that pkexec is not in the core snap and that pkexec in the app snap gets its setuid bit stripped15:45
jdstrandand something in the snap ends up calling pkexec15:46
zygajdstrand: ah, I see15:46
jdstrandbut the error makes it look like sudo is complaing15:46
zygaI know, I wrote that code15:46
zygajoc_, spineau: I know exactly what calls pkexec15:46
joc_i have no doubt :)15:46
spineauzyga: the warmup?15:47
zygathere's a execution controller for pkexec and sudo, if sudo doesn't work we do use pkexed15:47
zygaspineau: not even warmup, any tests that wants to run as root15:47
jdstrandsudo not able to work right in devmode is something that can be worked through15:48
jdstrandwould just need more details (and to be assigned to look at it)15:48
cwaynespineau: ^ would you be able to provide those details (as in what plainbox is actually trying to do when it gets denied)15:49
spineauzyga: we have two controllers which should return a negative score then, RootViaPTL1ExecutionController and RootViaPkexecExecutionController15:49
spineauif both return -1 then only sudo remains possible15:50
spineaucwayne: I'd like first to remove pkexec from the problem to have plainbox running jobs as root only with sudo and see what breaks exactly15:52
spineaucwayne: context here is devmode + sudo, not our second issue with sudo + confinement15:53
cwaynewe have so many issues :)15:54
* spineau should turn sentences is in a more positive way15:54
zygaspineau: we have so many issues but we used to have more and we are healthy!15:56
spineaucwayne: 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
spineauI don't want to bother our snappy experts with plainbox internals15:57
spineauif we can make sure that we are no longer call pkexec internally it will help diagnosing the problem15:58
mupPR 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:07
marcoceppiI need help with Python2 plugin, getting this error16:36
marcoceppi/usr/bin/env: 'python2': No such file or directory16:36
marcoceppiwhen running python scripts from inside my snap16:37
kyrofamarcoceppi, are you actually exporting the scripts using the `apps` in the YAML?16:41
marcoceppikyrofa: I guess so?16:41
kyrofamarcoceppi, or are you calling them directly?16:41
marcoceppikyrofa: http://paste.ubuntu.com/23062172/16:42
marcoceppithere's a golang tool that uses $PATH to find plugins16:42
marcoceppicharm-tools, provides a suite of plugins in Python16:42
kyrofamarcoceppi, hmm... and bin/charm seems to be provided by the go part, not python?16:48
marcoceppikyrofa: yes, and that works16:48
marcoceppibut running any of the subcommands which are pythjon result in the aforementioned error16:48
kyrofamarcoceppi, can you pastebin the contents of /snap/charm/current/charm.command (I think)?16:49
kyrofaOr charm-command... something like that16:49
marcoceppikyrofa: /snap/charm/current/command-charm.wrapper: http://paste.ubuntu.com/23062186/16:50
kyrofamarcoceppi, ohhhhhh16:51
kyrofaI know what's happening16:51
marcoceppiI am so ready for thsi16:51
kyrofamarcoceppi, your use of the `snap` keyword on the charm-tools part is a whitelist16:51
kyrofamarcoceppi, you're not actually including python :P16:51
kyrofamarcoceppi, perhaps you want to turn it into a blacklist instead?16:51
marcoceppino, I want those included16:52
marcoceppithey weren't being included before16:52
marcoceppiwell I want like EVERYTHING included16:52
marcoceppieverything I need to make this work16:52
mupPR snapcraft#732 opened: Remove store dispute logic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/732>16:52
marcoceppikyrofa: so I need to inlucde like $SNAP/usr/lib/python2.7/* in my whitelist?16:53
kyrofamarcoceppi, hmm... it should include everything placed by the setup.py16:54
kyrofamarcoceppi, in addition to python and other prereqs of the plugin16:54
marcoceppikyrofa: redherring, I found the issue16:55
mupPR snapcraft#730 closed: Clarification of make plugin help text <Created by mikemccracken> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/730>16:58
kyrofamarcoceppi, okay, good deal17:00
mupPR 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:10
=== JanC is now known as Guest86015
stokachuhow can i make snap refresh keep the --devmode flag?17:58
marcoceppiI'm an upstream developer, and my project name isn't available18:01
marcoceppino one has answered my dispute yet18:01
kyrofamarcoceppi, talk to nessita18:02
nessitamarcoceppi, hi! what's your project name?18:04
marcoceppinessita: charm18:12
mupPR snapd#1681 opened: tests: test `snap run --hook` using in-tree snap-exec <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1681>18:22
mupPR snapd#1689 opened: spread: disable re-exec to always test development tree <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1689>18:28
balloonsjdstrand, did the new snap-confine restrict things further? I can't seem to use lxd with the juju snap anymore, despite --devmode18:29
jdstrandballoons: it switched how bind mounts are applied, which might break devmode for you. can you file a bug against snap-confine? zyga, fyi ^18:34
balloonsjdstrand, I certainly can. I was just going a bit crazy feeling like I'd done something wrong. Good to know18:35
marcoceppinessita: is there anything else I need to do?18:36
balloonszyga, 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 broken18:40
nessitamarcoceppi, checking the status18:41
nessitamarcoceppi, I only see charm-tools and not charm18:41
nessitamarcoceppi, and the comment you added sounds like is a temporary name? you still need it?18:41
marcoceppinessita: I see this:18:42
nessitamarcoceppi, hum, sorry, found charm in another queue18:42
jdstrandballoons: https://bugs.launchpad.net/snap-confine/+filebug18:42
marcoceppinessita: charm Pending name dispute review18:42
nessitamarcoceppi, yeah, dispute review was a different queue, checking now18:42
marcoceppicharm-tools was my attempt to register a name while waiting for charm to be reviewed18:42
jdstrandballoons: as for a regression, probably, and I would expect it to be fixed reasonably soon18:43
jdstrandballoons: 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:43
balloonsjdstrand, 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.gz18:45
nessitamarcoceppi, see u1-internal please18:46
jdstrandballoons: 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 bug18:52
bladernrare 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:53
bladernrIt is building successfully, but then tries to do a make install and fails changing permissions:  http://paste.ubuntu.com/23062496/18:57
stokachuare there any snap examples where it tries to create it's own network bridge?19:00
kyrofabladernr, why does it need root:root there?19:01
stokachubasically this https://lists.ubuntu.com/archives/snappy-app-devel/2015-November/000477.html19:01
kyrofaThat doesn't seem like a normal thing19:01
bladernrkyrofa, 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:02
bladernrI have a feeling it's because on a regular system, its make install copies to /bin, which does need root permissions to copy into19:03
bladernrthanks, I didn't notice that before though, I'll play with that some more19:03
zygaballoons: do you have more details19:10
balloonszyga, hey. I can play with the setup as much as you'd like right now. What are you curious about?19:11
zygaballoons: what broke19:12
zygaballoons: is there a bug report?19:12
balloonszyga, basically as the bug says my old juju snaps don't bootstrap with LXD anymore. Essentially the socket isn't found I gues19:12
balloonszyga, https://bugs.launchpad.net/snap-confine/+bug/1613845.19:12
mupBug #1613845: Juju snap can no longer interact with LXD in devmode <conjure> <Snappy Launcher:New> <https://launchpad.net/bugs/1613845>19:12
zygaballoons: where is the lxd socket?19:13
balloonszyga, 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 break19:13
balloonszyga, /var/lib/lxd/unix.socket19:15
zygaballoons: thank you19:15
zygaballoons: /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
balloonszyga, and this presumably has changed from before right?19:23
zygaballoons: services should use /run or for sockets AFAIR (sadly we cannot support arbitrary locations)19:23
zygaballoons: 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 fs19:23
zygaballoons: now we chroot to the core snap and bind mount some things from there19:24
zygaballoons: this is consistent with all-snap images and works on any distribution19:24
zygaballoons: can lxd use another location for the socket?19:24
zygaslangasek, mwhudson; https://github.com/snapcore/snap-confine/pull/108/files19:26
mupPR snap-confine#108: Remove packaging <Created by zyga> <https://github.com/snapcore/snap-confine/pull/108>19:26
balloonszyga, 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 was19:27
zygaballoons: looking at the core snap, I don't see /var/lib/lxd there, we'd have to bind-mount all of /var/lib19:27
zygaballoons: but it cannot be there because that's a read only location for the core snap19:27
zygaballoons: even in devmode19:28
stokachuzyga: but it worked before19:28
zygaballoons: 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 snap19:28
stokachuzyga: and since snap is GA this is considered a regression, no?19:28
zygastokachu: 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 systems19:29
zygastokachu: I don't think so19:29
stokachuzyga: except it breaks our ability to use lxd inside a snap19:29
stokachuwhere we could before19:29
balloonszyga, I think the is part of the crux of the matter. It kills the story if we can't fix it19:29
zygastokachu: it breaks lxd as a snap in all-snap systems, it would never work there :/19:29
zygaballoons: it's all software, we can fix it19:30
zygaballoons: the question is how19:30
stokachuzyga: right but it *worked* before19:30
stokachujuju could access lxd inside a snap19:30
zygastokachu: but other things did not19:30
balloonszyga, right. I'm saying insomuch as stokachu points out, you've SRU'd this and broken existing snaps19:30
stokachuright so you've introduced a regression19:30
balloonsso I don't think you can make this change until you've fixed it -- if that means in LXD or wherever19:30
zygaballoons: 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 feature19:31
zygaballoons: if we revert the chroot we'll break every other distribution and a few things on ubuntu19:31
stokachuzyga: uhm no19:31
balloonszyga, right. And I feel like for xenial the right thing to do is let it stay the same. Is that not possible?19:31
zygaballoons: no19:32
zygaballoons: can we talk to stgraber to find a solution please19:32
stokachuzyga: you can't just introduce a regression in a LTS release19:32
zygastokachu: even if something worked because it relied on a bug?19:32
stokachuzyga: you introduced a regression in a LTS release19:32
stokachubottom line19:32
zygastokachu: lets not spin this this way, let's find a way for lxd ot work19:32
balloonszyga, 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 reasons19:33
balloonsalso thinking about https://bugs.launchpad.net/snappy/+bug/160496719:33
mupBug #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
zygastokachu: 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 possible19:33
stokachuzyga: how can you call this GA then?19:33
stokachuyou give us no guarantee19:34
zygastokachu: does GA say "it is not changing ever"?19:34
stokachuLTS does19:34
stokachudont introduce regressions in an LTS release19:34
zygathis is not a constructive discussion, let's find a way to fix the problem19:34
zyganot discuss acronyms19:34
zygastokachu:  is https://bugs.launchpad.net/snappy/+bug/1604967 a regression?19:35
mupBug #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
stokachuthat never worked in strict mode19:35
stokachuso no.. it's not a regression19:35
zygastokachu: ok19:35
stokachuyou've broken things that run in --devmode19:36
zygastokachu: as for /var/lib/lxd, I need to investigate options19:36
balloonszyga, 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 /run19:36
zygastokachu: 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 solutions19:36
stokachuzyga: thank you19:37
zygaballoons: 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
stokachuzyga: you seem to be forgetting about people who needs to run snaps on servers19:37
balloonszyga, 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 towards19:38
balloonsif you go down that path too early for --devmode, we can't begin adoption19:38
zygastokachu: 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 general19:39
stokachuzyga: then break it in yakkety19:39
stokachunot in xenial19:39
balloonszyga, can we not differentiate breaking it under --strict mode, but not under --devmode?19:39
zygastokachu: that's not as simple as that, this is a fundamental way that in which snaps work19:39
zygaballoons: snap-confine doesn't do anything differntly in devmode19:40
zygastokachu, balloons: FYI: http://www.zygoon.pl/2016/08/snap-execution-environment.html19:40
zygaI 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 change19:41
zygaI'll stop arguing because it seems to lead nowhere19:41
zygaI will look for solutions19:41
balloonszyga, 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 possible19:42
zygaballoons: 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 again19:43
zygaballoons: let me discuss this with the team and get back to you with solutions19:43
balloonszyga, ok. And presumably everything must change at the same time -- xenial cannot be treated differently?19:43
zygaballoons: that's another story, we can explore that19:44
balloonszyga, so it sounds like there may be solutions on your end. Good. It's worth thinking very carefully about raising the barrier for --devmode19:45
balloonszyga, please do keep me in the loop -- I'm happy to talk about it19:45
zygaballoons: note that before there were also read-only locations19:45
zygaballoons: devmode never affected that19:45
zygastokachu: 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
stokachuk thanks19:52
zygaogra_: ping19:57
ogra_zyga, moop19:57
bladernrOk... so I built a snap... put it in the store, and published.  How do I find it?20:18
bladernrHow do I install it?20:18
bladernrsnap find returns nothing, even after logging into the store20:18
qenghobladernr: How did you upload?20:19
bladernruhhh... snapcraft upload <snap>20:19
bladernrhttp://snapcraft.io/docs/build-snaps/publish following this20:20
bladernrOh wait... why is it listed as a click app?20:21
qenghobladernr: 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
bladernrhttps://myapps.developer.ubuntu.com/dev/click-apps/5728/rev/1/  or do both click apps and snaps go into the clic-apps dir20:21
zygabladernr: did you publish it into the stable channel20:21
bladernrit is now20:22
bladernrI thought I did that before, but its targeted to all20:23
bladernrahhh, ok.  there she be20:23
marcoceppiso I have a snap in the edge channel, but when I got to install it20:26
marcoceppierror: 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
marcoceppiI get a 401? the item is public and published20:26
marcoceppihad to log into the store, that error is super unhelpful20:29
qengho4nn is client-side error, asserted from the server. Doesn't sound like your package is the problem.20:30
qenghomarcoceppi: Oh, did it work then?20:31
marcoceppiqengho: yes20:32
qengho$ ubuntu-bug snapd   #file a bug report!20:32
=== mup_ is now known as mup
zygastokachu: I talked to jdstrand and we have a plan for the fix that can be rolled out quickly; I'm working on the fix now20:50
zygaballoons: ^^20:50
balloonszyga, ty!20:51
marcoceppiI've got a problem with temp directories in Python not being created? within a snap20:53
zygamarcoceppi: can you report a bug with some more details (tracebacks, denials, etc)20:54
marcoceppiI wonder if this is just an issue with git in snaps? has anyone had any problems with athat?20:54
zygamarcoceppi: remmeber that /tmp is a fresh tmpfs when you start a snap application20:55
marcoceppizyga: where do aarmor messages pop up?20:55
marcoceppizyga: sure, which is fine(?) or should be for this20:55
zygamarcoceppi: I think so20:55
zygamarcoceppi: try journalctl -f20:55
zygamarcoceppi: and run your app again20:56
zygamarcoceppi: FYI: http://www.zygoon.pl/2016/08/snap-execution-environment.html (and grep for /tmp)20:56
zygamarcoceppi: nothing new but perhaps you'll get an idea why it failed20:56
marcoceppizyga: 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 attempt20:57
zygaI agree20:58
marcoceppizyga: 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
zygamarcoceppi: yes, per process20:59
zygamarcoceppi: ah, not per per process21:00
zygamarcoceppi: per top-level snap application21:00
marcoceppicool, so that should be fine21:00
zygait is per invocation of /snap/bin/charm21:00
marcoceppiso, maybe it's really git that's failing, it seems to complain about /usr/share/git-core/templates even though that's in the prime21:01
ali1234when do they get cleaned up?21:07
zygamarcoceppi: is it reading it from /snap/$SNAP_NAME/current/usr/share/git-core/templates or from /usr/share/git-core/templates21:10
zygamarcoceppi: the prime directory is not the root filesystem21:10
zygamarcoceppi: if it opens /usr/share/git-core/tempates those are not going to be there21:11
marcoceppizyga: well, considering aa hasn't yelled at me, I assume it's from $SNAP21:11
zygajdstrand: ^^ another thing we could actually map with the quirk code21:11
zygamarcoceppi: I doubt it is from $SNAP21:11
zygamarcoceppi: unless git is configured to do so in some way21:11
marcoceppizyga: well, isn't it all chrooted?21:12
marcoceppigit is installed in my snap, etc21:12
marcoceppi/snap/charm/current/usr/share/git-core/templates exists21:12
zygamarcoceppi: no the way you think IMHO21:12
zygamarcoceppi: please read my blog post (the one I linked to)21:12
mupPR 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:16
marcoceppiso how do I troubleshoot this21:19
marcoceppibecause aa isn't complaining, the software isn't working, and I'm left without a real clear way to poke things21:20
zygamarcoceppi: 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 snap21:21
marcoceppiso, 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:21
mwhudsonzyga: i don't think i can advocate you as a DM21:25
zygamwhudson: that's okay, thanks21:36
zygamarcoceppi: yes21:37
marcoceppiwell,that's really unfortuantely.21:38
marcoceppithis seems ridiculous that I have to compile git to get it to work in my snap21:43
marcoceppiI'm not a git expert, I just depend on the damn thing, and my stabs at getting it to compile have failed thus far21:43
jdstrandzyga: interesting21:46
zygastokachu: 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)22:36
zygaballoons, stokachu: https://bugs.launchpad.net/snap-confine/+bug/1613845 is now fixed23:57
mupBug #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
zygaI will work on the SRU process tomorrow23:57
zygagood night :)23:57

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!