[00:09] PR snapd#1682 opened: interfaces/hardware-observe.go: re-add /run/udev/data === chihchun_afk is now known as chihchun [04:29] PR snapd#1663 closed: osutil: fix create-user on classic systems === LiX is now known as Guest15496 [06:40] good morning [06:42] so only the gadget or os snap is allowed to use gpio? === ljp is now known as lpotter [06:49] Hi everyone! [06:49] I am getting this Apparmor issue: [06:49] 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] And I am using the plugs: [bluez] on my snapcraft.yaml [06:50] https://github.com/pedrococa/sensortag/blob/master/snapcraft.yaml [06:50] Is there any additional interface that I should use? [06:52] looks like the mir interface can allow seqpacket [06:57] lpotter, so plugs: [mir, bluez] would do the trick? [07:01] lpotter, I am afraid it is not working. [07:01] lpotter: hey [07:02] lpotter: let me check if seqpacket is allowed [07:03] zyga, lpotter, is used by a BTLE device [07:04] zyga, lpotter, otherwise I got the apparmor issue and the snap failed with an error of BTLE addresses. [07:05] it seems not to be [07:06] essentially the apparmor denail you got above said you cannot create a seqpacket socket, try network-bind as a quick workaround [07:07] pstolowski: cześć :) [07:08] zyga, czołem! [07:09] pcoca: let me know if that workaround works for you [07:09] zyga, sure, snapping it up now :) [07:10] :-) [07:11] PR snapd#1683 opened: osutil: fix create-user on classic [07:12] zyga, It does not work :/ [07:12] I still got the same error with Apparmor [07:12] using plugs: [bluez, network-bind] [07:18] pcoca: can you please report the bug and give some background on the library/system calls you are using [07:19] pcoca: please report teh bug on launchpad.net/snappy with snapd-interface tag [07:21] PR snapd#1684 opened: many: drop ubuntu-core-snapd-units package, use release.OnClassic instead [07:26] zyga, here is: https://bugs.launchpad.net/snappy/+bug/1613572 [07:26] Bug #1613572: apparmor denial with sock_type="seqpacket" using a BTLE device [07:28] Bug #1613572 opened: apparmor denial with sock_type="seqpacket" using a BTLE device [07:29] PR snapd#1685 opened: snap-exec: Fix broken `snap run --shell` and add test [07:30] pcoca: I saw, thank you [07:30] mwhudson: good morning [07:31] 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] PR snapd#1686 opened: boot: add support for "devmode: {true,false}" in seed.yaml [07:56] PR snapd#1687 opened: release: Remove "UBUNTU_CODENAME" from the test data [08:35] Bug #1613609 opened: Can't register name for snap package [08:38] 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] Bug #1613609 changed: Can't register name for snap package [08:45] ogra@anubis:~/datengrab/images/snappy$ /snap/bin/vlc [08:45] multiple nvidia drivers detected, this is not supported [08:45] bah ! [08:45] (it isnt really like i need the nvidia drivers for music playback ) [08:45] ogra_: fwiw, I'm testing the fix for the boot problem you noticed on friday right now [08:46] ogra_: zyga maybe able to help with snap-confine [08:46] mvo, awesome, is it in the edge channel already ? [08:46] (i can manually update when setting snap_try_kernel) [08:47] 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] cool, ping me then, i'll do test upgrades without sideloading [08:49] ogra_: pi2 is published now, please let me know how it goes, I'm updating the dragonboard now [08:50] hmpf ... i cant really find the code in vlc that prevents the starting with nvidia drivers ... this is really evil ... [08:50] didrocks, is that check in the launcher code ? [08:51] ogra_: that is snap-confine that shows this message [08:51] bah [08:51] ogra_: no, it's not in the launcher [08:51] on what conditions ? [08:52] didrocks, yeah, seems snap-confine [08:52] yeah ;) [08:52] zyga, on what conditions does snap-confine block executions with nvidia drivers ... [08:52] seems it is rather overzealous [08:55] ogra_: dragonboard is also uploaded, let me know if you notice any issues please [08:56] PR snapd#1687 closed: release: Remove "UBUNTU_CODENAME" from the test data [08:57] mvo, oh [08:57] i got a new gadget too [08:57] ogra_: the fix is entirely in there [08:58] oh [08:58] ogra_: its also in bzr if you want to double check, once sec, I look for the diff [09:00] wow ... seems my pi2 auto upgraded to 254 already [09:00] (not rebooted though) [09:01] mvo, btw, we need some scriptery in the uboot.env to reboot when it cant load the files [09:01] that would have prevebted the hang [09:01] *prevented [09:03] ok, dragonboard is proper at v3 and ubuntu-core v253 [09:03] ogra_: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/revision/45 and 46 [09:03] ogra_: +1 for magic in uboot [09:04] and pi2 at 14 and 254 ... [09:04] but both had snap_try_kernel set [09:05] i guess i should trigger quickly another ubuntu-core to test without it set [09:05] build kicked ... [09:06] cjwatson, i see very often timeouts when triggering a snap buikld through the LP UI ... current one is OOPS-a9d5e8c47cb69641674e12dd57721fc9 [09:06] *build [09:07] (the build gets triggered fine, just the reload after triggering does time out) [09:12] ogra_: Thanks. That one could be fixed with a bit of property caching; please file a bug with the OOPS ID. [09:13] against launchpad itself ? [09:14] ogra_: yes [09:14] thx [09:16] ogra_: regression in r18036, apparently [09:16] aha [09:27] 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] t create-user now works on classic :) === vrruiz_ is now known as rvr [09:32] ** Unable to read file /kernel.img ** [09:32] reading /dtbs/apq8016-sbc.dtb [09:32] ** Unable to read file /dtbs/apq8016-sbc.dtb ** [09:32] reading /initrd.img [09:32] ** Unable to read file /initrd.img ** [09:32] Bad Linux ARM64 Image magic! [09:32] => [09:32] mvo, ^^^ :/ [09:33] (after refresh to the new ubuntu-core that finished a few mins ago) [09:36] 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] PR snapd#1680 closed: overlord/assertstate,daemon: reorg how the assert manager exposes the assertion db and adding to it [09:41] 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] 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] Odd_Bloke: thanks, I'll try that out [09:52] PR snapd#1688 opened: interfaces: add fwupd interface [10:08] mvo, well, md5 is moot after one boot attempt since it saves vars during boot ... but let me try [10:09] ogra_: you could dump the entire text and patebinit and I check [10:09] mvo, yeah, the script line differs ... [10:11] ogra_: meh, ok [10:11] * ogra_ copies manually and transfers all the variables needed [10:12] ok, now it works again [10:16] same for rpi [10:17] so i guess the gadget needs some upgrade hook [10:17] ogra_: yes, I guess short term I need to create new base images [10:17] that too [10:26] mvo, triggering a new ubuntu-core build to test with the new gadget in place now [10:28] ogra_: ta [10:28] * mvo considers lunch [10:30] cjwatson, Bug #1613652 (sorry, took a bit) [10:30] Bug #1613652: timeouts when triggering snap builds [10:34] ta [11:02] Son_Goku: hey, I've updated snap-confine and I'll need another golang package before snapd 2.11 [11:02] Son_Goku: I've uploaded everything to people.fedoraproject.org, I'll start working on the paperwork for this [11:04] 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] zyga, have you made any progress on selinux support in snap-confine? [11:15] Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1367407 [11:15] Son_Goku: some, I'm working on toy version of snap-confine that fiddles with libselinux [11:15] macaroons?! [11:15] Son_Goku: upstream firefighting is over now, I'm just waiting for reviews and I'll do 1.0.40 release [11:16] Son_Goku: I'm back to my regular tasks [11:16] Son_Goku: yeah, part of snapd auth code [11:16] Son_Goku: (I was surprised that macaroon is not "pasta" but instead is "fancy cookie" [11:16] Son_Goku: the polish word for "pasta" is makaron [11:17] oh dear god [11:17] I feel stupid now [11:18] Son_Goku: I'd like to make snap-confine apply selinux context/labels/thing to the mounted snaps [11:18] Son_Goku: haha, why? Did you also think it is about pasta? [11:18] that, and apparently we should have never importing check [11:18] it already exists: http://koji.fedoraproject.org/koji/packageinfo?packageID=19283 [11:18] hmmm [11:18] that's odd [11:18] I did gofed checks [11:19] that's good though [11:19] Son_Goku: wait, that's gopkg.in/check.v1 [11:20] Son_Goku: so there are two packages for the same thing? [11:20] yep [11:20] you just added exactly the same package to Fedora [11:20] http://koji.fedoraproject.org/koji/buildinfo?buildID=785266 [11:20] Son_Goku: I'll email the maintainer, maybe those should be merged [11:20] yeah [11:20] it's clearly an accident [11:21] Son_Goku: yeah, the provides for common name could be a way to find those [11:21] 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] yeah [11:22] well, the biggest problem is because golang is all statically done, there's no easy way to identify everything [11:22] and apparently the provides didn't even exist on that go-check package until Feb of this year [11:22] which shows how difficult golang can get [11:23] yeah, I agree [11:23] I think upstream import path/common name should be the only way to map packages [11:23] everything else is wrong [11:23] including github repo checks (like in this case) [11:24] 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] what I'm surprised about is that gofed didn't catch this [11:24] or did you never run gofed on snapd itself? [11:25] Son_Goku: I think I didn't run it on snapd [11:25] Son_Goku: though at the time the common name import didn't exist [11:25] Son_Goku: or .... perhaps I didn't use the common name then [11:25] you probably didn't use the common name [11:25] Son_Goku: in any case, I'm writing to the maintainer now [11:25] cool [11:26] you might want to ask if his version is up to date, and if you can be comaintainer of the package, too [11:26] you can request the ACLs here: https://admin.fedoraproject.org/pkgdb/package/rpms/golang-gopkg-check/ [11:26] yep, good idea [11:27] Son_Goku: how have you been? [11:27] I've been alright [11:27] Son_Goku: for me the summer is over, it's cold and wet all week [11:27] haha [11:27] it's still hot here [11:27] it's a bit rainy at the moment, but still very hot [11:28] Son_Goku: it was 10C in the morning today [11:28] it's 73F / 23C right now [11:29] the high will be 86F / 30C [11:29] 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] haha [11:36] Son_Goku: sent! [11:36] Son_Goku: you're on CC [11:36] Son_Goku: I'll look at snapd 2.11, I need to fix something in systemd units (seems like upstream change) [11:37] 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] cool [11:38] Son_Goku: https://github.com/snapcore/snap-confine/pull/103/files [11:38] PR snap-confine#103: Use downstream packaging in spread tests [11:38] 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] Son_Goku: I support debian and ubuntu, fedora and arch are up next, I just need to land this first [11:38] it's a RESTful API that emits a JSON form of the RPM XML repodata [11:39] ogra_: that sounds like a bug, it should store the channel, let me double check that [11:39] Son_Goku: I have that bookmarked, I need to spend some time on that cross distro monitoring [11:39] 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] both the Debian guy and myself would really like to see the SELinux integration asap :) [11:42] 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] did you learn anything from selinux guys at flock that could help? [11:42] Son_Goku: yes, I asked a lot of questions over lunch [11:42] Son_Goku: I also got the idea that everything I want to do is doable [11:43] Son_Goku: but most importantly, we just had a good time and exchanged contacts [11:43] that's good [11:46] * zyga away for 45 min [11:50] 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] Bug #1606212: getpwuid is failing on classic image [11:52] mvo, might be related to me manually tinkering with snap_try_kernel before (and according broken boot attempts alongside) [11:56] 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] will do [11:56] ogra_: thanks [12:12] Bug #1613686 opened: Consider allowing access to @{PROC}/@{pid}/limits [12:58] PR snapd#1681 closed: tests: test `snap run --hook` using in-tree snap-exec [12:59] Son_Goku: snap-confine updated again [12:59] Son_Goku: I'd love if you can set the reviewed bit now :) [12:59] haha [12:59] Son_Goku: if you want, all the changes are kept in git for easier review too [13:00] https://github.com/zyga/snapcore-fedora/commits/master [13:02] :) [13:02] package approved [13:03] wooot [13:03] thank you [13:05] macaroon is approved too [13:05] contingent on your fixes [13:06] yep, I saw; I'm on a call now but I'll continue with this as the next thing [13:06] Son_Goku: I'll push my selinux hacks today, maybe at least to get some feedback from others [13:06] cool [13:06] having something is better than nothing, imo === chihchun is now known as chihchun_afk [13:20] * zyga requested snap-confine and the macaroon package in fedora [13:20] next up: snapd :) [13:22] ogra_, who's responsible for the config of the rpi2-kernel snap? [13:22] awe, the config ? [13:23] you mean the build configuration ? [13:23] yup [13:23] looks like there aren't any audio devices configured by default [13:23] (the snap just uses the linux-raspi2 and linux-image-raspi2 packages from the archive) [13:23] which makes testing pulse rather difficult [13:23] ;D [13:23] pfft, excuses :P [13:24] 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] morphis: hi! can you look at https://bugs.launchpad.net/snappy/+bug/1613572/comments/2? [13:43] Bug #1613572: apparmor denial with sock_type="seqpacket" using a BTLE device [13:43] morphis: with the addition of bluetooth-control, I'm not sure where to put the fix [14:02] PR snapd#1682 closed: interfaces/hardware-observe.go: re-add /run/udev/data [14:06] jamiebennett: ping [14:07] pong [14:09] 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] Bug #1606212: getpwuid is failing on classic image [14:15] sborovkov: We keep the code on GitHub, let me see if I can find the branch [14:15] niemeyer: ^ [14:17] thanks [14:17] sborovkov: I don't have anything other than what's described there [14:17] sborovkov: The issue mentioned describes why the problem is likely happening, and what the fix is [14:18] niemeyer: so should I write a similar patch for my app like the one you attached for plymouth [14:18] sborovkov: Not clear if this needs to be in your app or in snapd itself [14:18] 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] Yes, that's why I asked. I though you patched snapd. And it would be in ubuntu-core [14:19] sborovkov: Someone needs to dig down and test this theory out [14:19] didrocks: do you want to hangout to get over with this docker hub thing? [14:19] sborovkov: Can you give it a shot? [14:20] niemeyer: but that patch should work, right? I checked /var/snap/ubuntu-core... and nsswitch.conf was present along with libnss files? [14:20] sborovkov: Even if the fix is in ubuntu-core, having someone verify it would be useful [14:20] 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] Bug #1613572: apparmor denial with sock_type="seqpacket" using a BTLE device [14:20] niemeyer: I'll test the patch on the side of my app then [14:21] sborovkov: Thanks, please let me know how it goes [14:21] sure [14:22] pcoca: /var/lib/snapd/apparmor/profiles/snap.sensortag.sensortag [14:22] pcoca: I left out 'snapd' [14:25] jdstrand, after the line: [14:25] profile "snap.sensortag.sensortag" (attach_disconnected) { [14:26] ? [14:26] pcoca: anywhere in between the {}. I typically add workarounds before the final '}' [14:27] jdstrand, OK [14:30] Odd_Bloke: you bug 1607710 is not prioritized afaict. if you need it escalated, I suggest talking to jamiebennett [14:30] Bug #1607710: Home directories listed in /etc/passwd should be honoured [14:30] your* [14:32] jdstrand, Done it. Thanks Jamie. I got now a different error :/ I just updated the bug info. [14:35] jdstrand: will have a look [14:36] 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] Bug #1607710: Home directories listed in /etc/passwd should be honoured [14:37] Sounds like zyga may know more on this bug [14:41] 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] jdstrand: on the plug side it should only allow dbus api access for bluez [14:42] all low level BT stuff should go into bluetooth-control [14:42] morphis: ok, so we should add network bluetooth to bluetooth-control [14:42] yeah [14:42] gotcha, thanks! [14:42] jdstrand: however its the question if we want to give any app access to that [14:43] a new build app should definitely go with bluez rather than bluetooth-control [14:43] pcoca: do you have time to iterate here? [14:44] morphis: 'a new build app'? [14:45] jdstrand: for those building new Apps especially for Ubuntu Core [14:45] morphis: note that bluetooth-control is not auto-connected [14:45] I see what you mean [14:45] as it stands, both bluez and bluetooth-control do not autoconnect [14:45] 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] PR snapcraft#715 closed: Add artifacts option to make plugin [14:46] that seems to be the case with sensortag [14:47] so this migh have the potential to conflict with a running bluez and also gets privileged access to the whole bluetooth subsystem [14:49] this may need an architects discussion. we've not had a situation where one interface might conflict with a slot implementation [14:55] Bug #1610292 opened: Snap installed with --devmode can't use sudo

[15:04] awe: append "dtparam=audio=on" to config.txt and reboot [15:04] thanks ppisati_!!! [15:04] awe: i tested it rhtough the 3.5jack (and i had to disconnect the hdmi cable) [15:04] or i didn't hear anything [15:04] ubuntu@raspi3:~$ cat /proc/asound/cards [15:04] 0 [ALSA ]: bcm2835 - bcm2835 ALSA [15:04] bcm2835 ALSA [15:04] right, in theory as long as both outputs are available [15:05] after appending that line and rebooting [15:05] you can switch using amixer [15:05] cool [15:05] awe: can you? [15:05] no idea [15:05] i found that, pulled out the hdmi cable, installed mpg123 and played an .mp3 file [15:05] ogra_: FYI ^ [15:05] https://www.raspberrypi.org/documentation/configuration/audio-config.md [15:05] awe: :O [15:08] ppisati_, ah, cool ... is that true for both pi's ? [15:09] ogra_: tested only on the pi3, but i betit works the same on pi2 [15:09] yeah [15:09] so i guess we should ste that by default in our config.txt [15:09] makes sense [15:12] 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] Bug #1610292: Snap installed with --devmode can't use sudo