| mup | Bug #1610025 opened: snapd fails to start after installing snaps <Snappy:New> <https://launchpad.net/bugs/1610025> | 00:23 |
|---|---|---|
| b-yeezi | Hi all. I'm trying to snappify an electron app that I'm a fan of. I'm following the SimpleNote example, but get an error | 01:28 |
| b-yeezi | ~/.../parts/.../build/wrapper so such file. | 01:28 |
| b-yeezi | no such file | 01:28 |
| b-yeezi | my wrapper file is in the $SNAP directory before I run snapcraft | 01:29 |
| b-yeezi | any suggestions? | 01:30 |
| b-yeezi | The only difference is that I'm pulling the tar.gz from the internet instead of untarring it locally | 01:46 |
| b-yeezi | hi | 01:47 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| ahoneybun | just did a popey and made a script for running snapcraft on a linode server | 03:54 |
| dholbach | hey hey | 05:13 |
| morphis | zyga: ping | 07:28 |
| morphis | does someone know how to fix this issue https://travis-ci.org/snapcore/snapd/jobs/149977843 with the spread tests running on linode? | 07:33 |
| morphis | looks like they broken with the now landed snapd 2.0.11 in xenial | 07:33 |
| mup | PR snapd#1638 opened: interfaces: add uefi-manager interface <Created by timchen119> <https://github.com/snapcore/snapd/pull/1638> | 08:14 |
| popey | ahoneybun: yay | 08:17 |
| popey | dholbach: lemme know if/when you get a chance to try my silly script :) | 08:19 |
| dholbach | popey, probably not today :-/ | 08:22 |
| dholbach | I looked at the team option already though and it looks like what we want :) | 08:23 |
| popey | well that's good news! | 08:23 |
| lucalar | hi guys | 08:43 |
| lucalar | I would like to ask you something on IoT project development on Ubuntu Snappy | 08:44 |
| lucalar | if someone could answer I appreciate | 08:44 |
| lucalar | I'm a newbie on Ubuntu Snappy, and I have to develop a project using a gateway (where snappy is installed) and sensors connected to it | 08:46 |
| lucalar | which is the best way, the language that I have to use, etc.. ??? | 08:47 |
| dholbach | you can build your software whichever language you are most comfortable using | 08:48 |
| dholbach | snapcraft (the tool to turn your software into a snap) has a lot of different build plugins, so building it should be easy | 08:48 |
| dholbach | http://snapcraft.io has more info about it | 08:49 |
| lucalar | yes, i've read something on snapcraft | 08:50 |
| lucalar | but in this context, I would like to know if I can test the software during the developing | 08:50 |
| lucalar | I mean, my Ubuntu Snappy is installed on a gateway, so I have no GUI | 08:51 |
| lucalar | and I'm not sure if I can install snapcraft on it | 08:51 |
| dholbach | I'm not sure how you would debug or interact with your software - is it a service you can reach over the network? | 08:52 |
| dholbach | or do you mean building it on an ARM machine while you're on x86? | 08:52 |
| lucalar | nop | 08:52 |
| lucalar | yes, something like that | 08:53 |
| lucalar | i have to build it for a different machine | 08:53 |
| mup | PR snapd#1639 opened: tests: allow-downgrades on upgrade test to prevent version errors <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1639> | 08:53 |
| dholbach | I'm not quite sure what the best way to do this is... I'll leave the question for somebody else | 08:54 |
| dholbach | if nobody responds in time, maybe best send an email snapcraft@lists.snapcraft.io and explain your setup | 08:55 |
| dholbach | I'm sure you're not the only one looking for this :) | 08:55 |
| lucalar | thank you guys | 08:55 |
| Odd_Bloke | Launchpad supports building snaps on multiple architectures; there are some restrictions on what architectures are generally available, so I don't know if that helps. | 08:55 |
| dholbach | ah, nice one - of course | 08:56 |
| * dholbach clearly needs some more mate tea | 08:56 | |
| Odd_Bloke | Alternatively, you could try running snapcraft inside a $arch KVM, if you can get one running. | 08:56 |
| lucalar | I see | 08:57 |
| Odd_Bloke | I haven't actually done either of these things though (as I lead a blessedly amd64 life ;), so I can't promise they'll work for you. :) | 08:57 |
| dholbach | https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way | 08:59 |
| dholbach | lucalar, ^ | 08:59 |
| Odd_Bloke | Hmm, update-alternatives not running when you stage-packages is irritating. | 09:01 |
| lucalar | cool, I will give it a look ;) | 09:01 |
| Odd_Bloke | Just spent several iterations of snap/upload/install trying to work out why awk wasn't in my path after installing gawk. >.< | 09:01 |
| lucalar | wow, cool...launchpad is very interesting. Thanks a lot dholbach and Odd_Bloke | 09:12 |
| mup | PR snapd#1639 closed: tests: allow-downgrades on upgrade test to prevent version errors <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1639> | 09:13 |
| lucalar | another question, do you know the existance of a Java API to work with sensors on an OS Ubuntu Snappy installed on an architecture amd64? | 09:14 |
| dholbach | I don't, but I'd recommend just using the java api your sensors work with and bundling that in the snap (snapcraft will help you do that) | 09:18 |
| beowulf | Odd_Bloke: hey, did you figure out the browserify step? | 09:20 |
| Odd_Bloke | beowulf: I haven't, no. | 09:21 |
| beowulf | Odd_Bloke: let me know what you come up with :) I think using npm's package.json to define that steps pre and post installing some modules via snapcraft's node plugin is worth exploring, but i haven't had time | 09:25 |
| Odd_Bloke | beowulf: I don't really know enough about npm/node to really dig in to it; I was hoping it would Just Work (TM). ;) | 09:26 |
| beowulf | Odd_Bloke: let me try something simple and if it works it might help you :) | 09:27 |
| mup | Bug #1610149 opened: writing to the "common" directory needs to have sudo right <Snappy:New> <https://launchpad.net/bugs/1610149> | 09:27 |
| Odd_Bloke | beowulf: :) Thanks! | 09:28 |
| willcooke | ogra_, I assume the answer is yes, but.. does your Pi3 core image include drivers for BT and Wifi? | 09:28 |
| ogra_ | willcooke, the answer is no currently | 09:28 |
| ogra_ | :) | 09:29 |
| ogra_ | sorry ... they will land soon | 09:29 |
| willcooke | ogra_, ah :) Glad I asked then. What about wired ethernet? | 09:29 |
| ogra_ | (it includes the drivers, but not the additional firmware) | 09:29 |
| ogra_ | wired works fine | 09:29 |
| willcooke | perfect, thanks! | 09:29 |
| * willcooke ponders netbooting a pi3 in to core | 09:29 | |
| ogra_ | unlikely to work ... but try it | 09:30 |
| willcooke | will try and carve out some time to play this afternoon | 09:30 |
| ogra_ | (the initrd searches for labels on partitions for the whole system setup ... if the label isnt there or the snaps arent in the right place on the labeled partition it will fall flat on its face) | 09:31 |
| willcooke | Ah, I see | 09:31 |
| ogra_ | for netbooting we'd need to add some bits to the scriptery | 09:32 |
| willcooke | Not worth it atm I expect. | 09:33 |
| ogra_ | well, there was some desire to do netbooting at some point, i thinnk lool worked on that ... though i also think that was via a special system that puts bits into place first | 09:33 |
| lool | I have not but I'd like it too :-) | 09:34 |
| lool | in Heidelberg we noted it would be a quite desirable thing ot have | 09:35 |
| willcooke | Is this made any easier by the recent Pi annoncement of netbooting? | 09:35 |
| ogra_ | nope | 09:35 |
| willcooke | darn | 09:36 |
| ogra_ | in all cases you need an SD to boot the pi ... | 09:36 |
| ogra_ | since we default to using uboot for booting, a generic solution would kick in on that level, not in the first stage bootloader | 09:36 |
| ogra_ | i.e. you would have an SD with the binary blob plus the uboot binary and config | 09:37 |
| ogra_ | (in general the pi isnt realyl a great target given you will always need an SD due to a missing eMMC boot) | 09:37 |
| willcooke | yeah | 09:38 |
| ogra_ | (if you need an SD anyway, you could as well do a local boot) | 09:38 |
| willcooke | only use case for netbooting I have is that SD cards don't like getting hot, so industrial applications might want to boot from SD card and load everything else over the network | 09:38 |
| willcooke | plus, people like me who like to play | 09:39 |
| ogra_ | well, it is definitely a valid target ... (i guess also for cloud stuff) | 09:39 |
| willcooke | This confuses me: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net.md | 09:41 |
| willcooke | It says that the boot ROM is "One Time Programmable" | 09:42 |
| willcooke | and then it talks about setting bits in there | 09:42 |
| willcooke | But does suggest that it might be possible to boot without an SD card | 09:43 |
| ogra_ | ah, well, try it if you like | 09:44 |
| willcooke | I'll see what I can get working, and then bother you about it next time we meet | 09:45 |
| lool | willcooke: prompted by your remark about netbooting, I landed on the exact same page and I have been diving into it; seems quite useful | 09:58 |
| lool | willcooke: the OTP seems indeed to be write once; my understanding is that the firmware supports USB netboot and USB mass storage, but that's disabled by default because potentially buggy or unsecure | 09:58 |
| lool | so we flip a bit once to enable it forever | 09:58 |
| lool | can't disable it | 09:58 |
| lool | Hmm https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md says if you remove it it's turned off | 09:59 |
| willcooke | lool, I think there are a few typos in those docs. | 10:00 |
| lool | can't find much about this flash except that it holds a bunch of device specific stuff like serial | 10:00 |
| willcooke | https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md | 10:02 |
| lool | http://www.elinux.org/RPI_vcgencmd_usage is where I found the info on the otp contents | 10:03 |
| === hikiko is now known as hikiko|ln | ||
| lool | willcooke: ah well the net tutorial page is consistent with the hardware behavior I suspect: program_usb_boot_mode=1 is only needed to be present once, and then it's enabled forever | 10:06 |
| willcooke | lool, this page talks about getting involved in the beta of netbooting: https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bootmodes/README.md | 10:06 |
| mup | Bug #1591664 changed: 'snap install' should support --beta, --candidate and --edge options <Snappy:Fix Released> <https://launchpad.net/bugs/1591664> | 10:06 |
| willcooke | lool, @ program_usb_boot_mode - yeah, I think so too | 10:06 |
| lool | https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bootmodes/bootflow.md is pretty nice | 10:07 |
| * willcooke reads | 10:08 | |
| lool | willcooke: if I read the bottom correctly ("By default the USB device boot mode is enabled at manufacture time [...]"), once you switch to netboot you can't ever go back to device mode | 10:09 |
| willcooke | erk | 10:09 |
| willcooke | maybe you can change that with pulling the GPIOs up? | 10:10 |
| willcooke | or down | 10:10 |
| ogra_ | or with pliers and a soldering iron :P | 10:10 |
| willcooke | :) | 10:10 |
| mup | Bug #1602154 changed: "snap find" command cannot find ubuntu-calculator-app. However, it can be installed on 16.04 <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1602154> | 10:18 |
| mup | Bug #1605471 changed: Cannot refresh a devmode snap <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1605471> | 10:21 |
| mup | Bug #1606100 changed: "snap revert" command cannot be found <Snappy:Fix Released> <https://launchpad.net/bugs/1606100> | 10:24 |
| mup | Bug #1607717 changed: no snaps installed error <Snappy:Fix Committed by chipaca> <https://launchpad.net/bugs/1607717> | 10:36 |
| beowulf | Odd_Bloke: so, the nodejs plugin would probably need a few changes to make my suggestion work :( | 10:37 |
| mup | Bug #1590704 changed: "snap interfaces" command doesn't filter by snap <verification-done> <Snappy:Fix Released by chipaca> <https://launchpad.net/bugs/1590704> | 10:39 |
| === hikiko|ln is now known as hikiko | ||
| === LarreaMikel1 is now known as LarreaMikel | ||
| === vrruiz_ is now known as rvr | ||
| cpaelzer | on a minor note on http://snapcraft.io/create/ "... the two highlighted files ...", but there is only one highlighted - prime/command-hello-service.wrapper should be bold as well I think | 11:34 |
| cpaelzer | link https://myapps.developer.ubuntu.com/dev/click-apps/register-name-dispute/ as referred by http://snapcraft.io/create/ is broken as well | 11:42 |
| mup | Bug #1610211 opened: Interface to manage block devices <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1610211> | 11:43 |
| === LarreaMikel1 is now known as LarreaMikel | ||
| === JanC is now known as Guest20161 | ||
| === JanC_ is now known as JanC | ||
| ali1234 | popey, didrocks: i am currently getting this exact error http://askubuntu.com/q/787258/12435 | 12:16 |
| ali1234 | even to the extent that one day later the error changed from failing on the package lists to the deb files | 12:17 |
| popey | erk | 12:17 |
| popey | i have no idea what I did to fix it | 12:18 |
| popey | I think I nuked my lxd config and started again | 12:18 |
| ali1234 | i started with a fresh lxd config | 12:18 |
| didrocks | I guess the issue is Err:5 http://archive.ubuntu.com/ubuntu xenial-updates/main Translation-en | 12:18 |
| didrocks | 500 Internal Server Error | 12:18 |
| popey | oh, also, I had an apt-cacher-ng which I removed | 12:18 |
| ali1234 | installed it yesterday for this purpose | 12:18 |
| popey | oh | 12:18 |
| didrocks | it can't update that repo | 12:18 |
| ali1234 | no cachers here | 12:18 |
| popey | ok | 12:18 |
| ali1234 | actually | 12:18 |
| ali1234 | yesterday it failed on a en translation file | 12:19 |
| ali1234 | today it didn't even try to download that | 12:19 |
| ali1234 | http://paste.ubuntu.com/22306053/ is today's error | 12:19 |
| ali1234 | didrocks: yes, yesterday that was the error. today the error is different ^ | 12:20 |
| ali1234 | i have changed nothing on my end. just gave up yesterday and went to bed... | 12:20 |
| didrocks | weird, and no issue from your host at all? | 12:20 |
| ali1234 | apt works fine on the host afaik | 12:20 |
| didrocks | maybe ask stgraber if there is some lxd cache? | 12:21 |
| mup | PR snapd#1640 opened: tests: add gsettings interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1640> | 12:50 |
| mup | PR snapd#1628 closed: store: refactor newRequest/doRequest to take requestOptions <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1628> | 13:21 |
| jdstrand | kyrofa: hey, now for me to ask you a couple questions :) 1) if I run 'snapcraft' which directory is mksquashfs run on? 2) Let's suppose that I stage-packages and all the debs are unpacked but I want to add/tweak something that was unpacked. is it possible to insert a command at sometime after unpack but before mksquash? | 13:23 |
| morphis | niemeyer: are you looking at https://github.com/snapcore/snapd/pull/1432 today? jhodapp is waiting already for some days | 13:42 |
| mup | PR snapd#1432: interfaces/builtin: improve pulseaudio interface <Reviewed> <Created by jhodapp> <https://github.com/snapcore/snapd/pull/1432> | 13:42 |
| niemeyer | morphis: I've been actively going through the queue in the last few days.. will get to it | 13:42 |
| morphis | aye | 13:43 |
| jhodapp | thanks niemeyer | 13:43 |
| niemeyer | jhodapp: np, sorry for the delay.. it's obviously been a little hectic after the sprints | 13:45 |
| jhodapp | niemeyer, yeah understood | 13:46 |
| jhodapp | niemeyer, this PR has been reviewed many times, so it should just be ready to go...an easy merge | 13:47 |
| niemeyer | jhodapp: Yeah, this is an epic branch | 13:51 |
| niemeyer | jhodapp: What is that line 217 on manual-tests.md? | 13:51 |
| jhodapp | niemeyer, that shouldn't be there...slipped through in my conflict resolution | 13:52 |
| mup | PR snapd#1641 opened: interfaces: implement systemd-control <Created by morphis> <https://github.com/snapcore/snapd/pull/1641> | 13:52 |
| jhodapp | niemeyer, let me get rid of that quickly | 13:52 |
| niemeyer | jhodapp: Can you please also take this chance to fix the tab indentation on the yaml snippets? | 13:53 |
| niemeyer | jhodapp: It's being improperly tagged red there for good reasons.. yaml can't take tabs | 13:53 |
| niemeyer | (not your fault) | 13:53 |
| niemeyer | jhodapp: 4 spaces on all of them please | 13:53 |
| niemeyer | I mean, four spaces indents | 13:53 |
| jhodapp | niemeyer, I can change it but those tabs are not from me | 13:53 |
| jhodapp | oh you said that | 13:54 |
| niemeyer | jhodapp: You've marked it as yaml in the branch, though (correctly) | 13:54 |
| jhodapp | sure I can fix that | 13:54 |
| jhodapp | it was bugging me too | 13:54 |
| niemeyer | jhodapp: Thanks, the indentation is also pretty broken in that one snippet you touched at least.. it has 8 spaces and 4 spaces, interchangeably | 13:55 |
| niemeyer | and then next one has 2 spaces.. indentation party | 13:55 |
| jhodapp | niemeyer, fixed that section | 13:58 |
| niemeyer | jhodapp: Why were the consts changed to vars on all snippets? | 14:01 |
| jhodapp | niemeyer, at least pulseaudioConnectedPlugAppArmor is modified in the code later | 14:02 |
| kgunn | jdstrand: ok, i'm getting a seccomp denial for sendto and it's clearly in my connectedplug snippet | 14:03 |
| niemeyer | jhodapp: It's actually not, I think | 14:03 |
| jdstrand | kgunn: is it in the resulting policy in /var/lib/snapd/seccomp/snap.your.thing.that.is.failing | 14:05 |
| jhodapp | niemeyer, oh you're right it isn't...sorry brand new to Go | 14:07 |
| jhodapp | niemeyer, so am I able to just slap "const" back on the front of those? | 14:07 |
| === Tristit1a is now known as Tristitia | ||
| jhodapp | even as byte slices | 14:07 |
| niemeyer | jhodapp: No, unfortunately not.. you'll need to move them back to being strings, and use []byte in place | 14:10 |
| niemeyer | jhodapp: I'd prefer that in general, as a guideline.. it means those strings are in unchangeable memory, and won't be mutated behind our back | 14:11 |
| niemeyer | jhodapp: A bit of paranoia, arguably, but not too crazy given the context | 14:11 |
| jhodapp | niemeyer, using []byte in place is a cast, yes? | 14:11 |
| niemeyer | jhodapp: Type conversion, not a cast | 14:11 |
| niemeyer | jhodapp: Cast means something else if we're pedantic enough | 14:11 |
| jhodapp | niemeyer, so it's not the same thing as in C/C++ | 14:12 |
| niemeyer | jhodapp: No, it's not.. in those languages you can actually tell the compiler you want to look at that memory under different eyes, whethere that's correct or not | 14:12 |
| niemeyer | jhodapp: That's casting | 14:13 |
| jhodapp | niemeyer, yeah ok, so this is safer | 14:13 |
| niemeyer | jhodapp: On b := []byte(s) you're allocating new memory, copying data over, and converting the type.. | 14:14 |
| jhodapp | yeah | 14:14 |
| === matiasb1 is now known as matiasb | ||
| kyrofa | Hey jdstrand!Sorry, I had to switch work locations | 14:20 |
| kyrofa | jdstrand, (1) snapcraft (which defaults to snapcraft snap) runs mksquashfs on the prime/ directory | 14:20 |
| mup | PR snapd#1642 opened: many: pass device to store <Created by matiasb> <https://github.com/snapcore/snapd/pull/1642> | 14:22 |
| kyrofa | jdstrand, (2) not by utilizing the default plugins, but you have a few options. You can either write your own plugin that does stuff right after the pull step, or write a Makefile that does stuff in the all: rule (which is run during build, right after pull | 14:23 |
| kyrofa | jdstrand, you can ship a local plugin alongside the snapcraft.yaml | 14:25 |
| jhodapp | niemeyer, fixed | 14:25 |
| niemeyer | jdstrand: This is an interesting point to keep an eye on for future reviews.. the snippets should ideally live as consts rather than var []byte | 14:27 |
| liuxg | kyrofa, ping | 14:28 |
| kyrofa | liuxg, pong | 14:31 |
| liuxg | kyrofa, if I want to write to the common directory, do I need to have the root previlege? thanks | 14:32 |
| kyrofa | liuxg, there are two common directories: SNAP_COMMON and SNAP_USER_COMMON. Yes, SNAP_COMMON (like SNAP_DATA) is owned by root | 14:33 |
| jdstrand | niemeyer: noted | 14:33 |
| kyrofa | SNAP_USER_COMMON though is owned by the user. Note however that it's not currently usable as nothing creates it. niemeyer, speaking of that, did you see the email thread about that? | 14:34 |
| niemeyer | jhodapp: Just waiting for it to go green | 14:34 |
| jhodapp | niemeyer, cool | 14:34 |
| liuxg | kyrofa, I mean the directory SNAP_COMMON | 14:34 |
| niemeyer | kyrofa: Nope | 14:34 |
| kyrofa | liuxg, then yes | 14:34 |
| jdstrand | kyrofa: great, thanks! | 14:34 |
| kyrofa | jdstrand, let me know what path you decide to follow and I can give you a few more hints | 14:34 |
| liuxg | kyrofa, do you mean it needs have the root previlege? it is like /home/<user_name>/snap/hello/common | 14:35 |
| kyrofa | liuxg, that's SNAP_USER_COMMON | 14:35 |
| kyrofa | liuxg, SNAP_COMMON is in /var/snap/<snapname>/common | 14:35 |
| kyrofa | But yes | 14:35 |
| niemeyer | kyrofa: My vague memories are that with snap run creating that directory becomes trivial | 14:36 |
| niemeyer | kyrofa: Not sure what changed since we last discussed this, though | 14:36 |
| kyrofa | niemeyer, indeed, that's true. But snap run is taking a while to land and people are starting to get confused by the behavior of not creating them | 14:37 |
| liuxg | kyrofa, right. so, the one SNAP_USER_COMMON a user right is fine, right? | 14:37 |
| kyrofa | niemeyer, will that land soon you think? Or should we add that logic back to snap-confine? | 14:37 |
| kyrofa | liuxg, right | 14:37 |
| liuxg | kyrofa, thanks for your clarification. By the way, I have shared you a document about core, would you please help to review it, thanks. | 14:38 |
| * kgunn has more fun with network | 14:38 | |
| kyrofa | kgunn, I share your pain | 14:38 |
| kyrofa | liuxg, sure! | 14:38 |
| kgunn | jdstrand: sorry had to re-run and yes it is listed in /var/lib/snapd/seccomp/profiles/snap.mir-client.client-start | 14:38 |
| kgunn | the denial signature in syslog appears as | 14:39 |
| kgunn | Aug 5 14:34:56 localhost kernel: [ 267.421706] audit: type=1326 audit(1470407696.839:12): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1383 comm="clocks" exe="/snap/mir-client/x1/clocks" sig=31 arch=c000003e syscall=44 compat=0 ip=0x7fcdea268b7f code=0x0 | 14:39 |
| niemeyer | kyrofa: The only blocker for snap run is snap-confine, which I believe is now about to be in updates | 14:39 |
| liuxg | kyrofa, by the way, another developer yesterday met a same problem, and he confirmed it.. https://bugs.launchpad.net/snapcraft/+bug/1601834 | 14:39 |
| mup | Bug #1601834: Error "[Errno 21] Is a directory" when building a snap package for a qmake project <Snapcraft:Confirmed> <https://launchpad.net/bugs/1601834> | 14:39 |
| niemeyer | kyrofa: So *maybe* next week | 14:40 |
| kyrofa | niemeyer, ah, good deal. Okay, we'll just live with it then | 14:43 |
| jdstrand | kgunn: is clocks running under snap.mir-client.client-start? | 14:43 |
| jdstrand | kgunn: and it this on amd64? | 14:43 |
| niemeyer | kyrofa: Did I miss something else in that conversation? | 14:44 |
| kyrofa | niemeyer, no, people seemed to think snap run was already used. I tried to clarify, but asked you and mvo about timeline. It would be great if you could quickly respond just to close the thread, if you have a minute | 14:45 |
| ali1234 | what's snap run? test the current snap without installing it? | 14:50 |
| niemeyer | kyrofa: Where's the thread? | 14:51 |
| mup | PR snapd#1643 opened: many: support interactive payments in snapd, filter from command line <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1643> | 14:51 |
| niemeyer | ali1234: Any app may be run via "snap run snap[.app]" | 14:51 |
| niemeyer | ali1234: Instead of /snap/bin/snap[.app] | 14:52 |
| ali1234 | oh right, i was thinking of "snapcraft run" | 14:52 |
| niemeyer | ali1234: The latter will become just a symlink to /usr/bin/snap | 14:52 |
| niemeyer | ali1234: So it's a much nicer pipeline for how things get executed | 14:53 |
| mup | Bug #1610149 changed: writing to the "common" directory needs to have sudo right <Snappy:Invalid> <https://launchpad.net/bugs/1610149> | 14:53 |
| ali1234 | yeah, i see. i was thinking of something else entirely | 14:53 |
| niemeyer | ali1234: It's coming for a while, but there were several moving parts, so it took a while to get to this point | 14:53 |
| * ogra_ grumbles about not being able to use sidloaded kernel snaps anymore with latest u-d-f | 14:54 | |
| mup | PR snapd#1625 closed: asserts: make account-key's `until` optional to represent a never-expiring key <Created by emgee> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1625> | 14:57 |
| jhodapp | niemeyer, looks like CI completed successfully | 15:07 |
| kgunn | jdstrand: sorry, network killing me....not sure if you saw i do have sendto in the seccomp profile for the client | 15:12 |
| jdstrand | kgunn: is clocks running under snap.mir-client.client-start? | 15:13 |
| jdstrand | kgunn: and it this on amd64? | 15:13 |
| jdstrand | is* | 15:13 |
| kgunn | jdstrand: yes, this is on amd64 and clocks is the exe launched by client-start | 15:16 |
| kgunn | http://bazaar.launchpad.net/~mir-team/+junk/snapcraft-mir-client/view/head:/client-start | 15:16 |
| jdstrand | kgunn: and you are 100% sure that sendto is listed in /var/lib/snapd/seccomp/snap.mir-client.client-start ? | 15:17 |
| jdstrand | kgunn: grep sendto /var/lib/snapd/seccomp/snap.mir-client.client-start | 15:18 |
| jdstrand | kgunn: and you are seeing the denial by launching mir-client.client-start ? | 15:19 |
| kgunn | jdstrand: it is literally on line 469 of /var/lib/snapd/seccomp/profiles/snap.mir-client.client-start | 15:19 |
| jdstrand | kgunn: is the interface connected? | 15:19 |
| kgunn | jdstrand: the interface is connected manunally | 15:19 |
| jdstrand | meh, if it is in there it should be | 15:19 |
| kgunn | jdstrand: so i put a sleep at the top of client-start, then manually connect | 15:20 |
| jdstrand | kgunn: can you tail -f /var/log/syslog in one terminal, then sudo systemctl stop your.unit ; sudo systemctl start your.unit | 15:21 |
| jdstrand | kgunn: then tell me if you see a new denial in syslog? | 15:21 |
| kgunn | jdstrand: sure will try | 15:22 |
| kgunn | jdstrand: when i call sysctl on snap.mir-client.client-start.service | 15:28 |
| kgunn | it fails with | 15:28 |
| kgunn | Failed to stop snap.mir-client.client-start.service: The name org.freedesktop.PolicyKit1 was not provided by any .service files | 15:28 |
| kgunn | See system logs and 'systemctl status snap.mir-client.client-start.service' for details. | 15:28 |
| jhodapp | niemeyer, are you still around? | 15:30 |
| ysionneau | hmm I have two snaps that must communicate through unix socket | 15:36 |
| ysionneau | where do I put the socket ? | 15:36 |
| ysionneau | in /tmp one won't be able to open it | 15:36 |
| ysionneau | in home, the home interface isn't autoplug I think ... | 15:37 |
| ysionneau | (and I guess I won't be in devmode since I install the snap through webdm) | 15:44 |
| jdstrand | kgunn: did you run that with sudo? | 15:45 |
| kgunn | jdstrand: i can try | 15:45 |
| ysionneau | so what's the way to communicate between two snaps via unix socket without devmode ? | 15:45 |
| jdstrand | kgunn: basically, I don't understand how the sendto denial is being logged. it shouldn't be. I think it is either an old denial or it happens on install before the connection. I'd like to see confirm that a sudo sysctemctl stop ... followed by start triggers it | 15:46 |
| jdstrand | kgunn: if it wasn't working, there would be people screaming left and right about it being broken... | 15:46 |
| didrocks | ysionneau: I would recommend using SNAP_DATA if both are running as root, until we get a better answer from jdstrand or niemeyer :) | 15:50 |
| ysionneau | hmmm i'm running as root yes | 15:52 |
| ysionneau | but I guess one snap does not have access to another snap's SNAP_DATA, right ? | 15:52 |
| didrocks | ah, it's 2 snaps, sorry, I read 2 apps | 15:52 |
| didrocks | so, yeah, question for jdstrand & niemeyer in that case (maybe ask on the ML so that they can catch up later on?) | 15:53 |
| ysionneau | I have lool helping me out in fact at the moment :) | 15:54 |
| ysionneau | thanks ! | 15:54 |
| didrocks | lool: ysionneau: do you mind keep us posted on the ML? That would be interesting to quite a lot of people I think | 15:55 |
| lool | didrocks: at the moment it's a bit hackish with a devmode snap | 15:55 |
| lool | didrocks: the docker snap is a good example of how to do this properly, but it requires landing an interface in snapd | 15:55 |
| lool | didrocks: https://github.com/snapcore/snapd/pull/1619/files has the interface | 15:55 |
| mup | PR snapd#1619: Add initial "docker" interface based on some of 15.04's privileges <Created by tianon> <https://github.com/snapcore/snapd/pull/1619> | 15:55 |
| lool | you can see it gives access to /run/docker.sock | 15:55 |
| didrocks | lool: hard for 3rd party apps to land an interface for their specific socket though… | 15:56 |
| ysionneau | yep I would prefer to not have to modify snapd, for now at least, even if it's a bit hackish like reusing some interface | 15:56 |
| lool | didrocks: well it's the otherway around here | 15:56 |
| lool | didrocks: they have a first (devmode) snap with a socket somewhere, and another snap (confined) accessing it, I'm not sure which dir is accessible by default to all snaps though, checking default policy | 15:57 |
| ysionneau | yes it would be for out autopilot, that Parrot should land an interface to allow 3rd party apps to connect to our unix ocket | 15:57 |
| ysionneau | socket* | 15:57 |
| lool | ysionneau: BTW I wanted to tell you about shm | 15:57 |
| ysionneau | ah! | 15:57 |
| lool | ysionneau: not sure if you saw the exchange on the ML, but shm is open by default with snap.XXX prefix | 15:57 |
| lool | ysionneau: https://lists.ubuntu.com/archives/snapcraft/2016-August/000611.html | 15:57 |
| lool | /{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix, | 15:58 |
| ysionneau | !! | 15:58 |
| ysionneau | ah this is for shm, ok thanks! | 15:58 |
| lool | ysionneau: damn, I'm out of time, but I think this is the default policy: https://github.com/snapcore/snap-confine/blob/master/debian/usr.bin.snap-confine | 16:00 |
| lool | ysionneau: I have to run to a meeting, perhaps you'll find a dir in there | 16:00 |
| lool | ah no I still have :30 | 16:01 |
| ysionneau | I have updated my fw btw | 16:02 |
| ysionneau | I'm using ubuntu-core_148.snap | 16:02 |
| ysionneau | usr.bin.ubuntu-core-launcher -> usr.lib.snapd.snap-confine | 16:03 |
| ysionneau | I'm not very fluent in apparmor profiles though, where to look for "unix socket rights"? | 16:03 |
| kgunn | jdstrand: sorry otp, but sudo systemctl stop/start worked...and now i get a different denial so that's good | 16:04 |
| ysionneau | does not seem to be any unix socket stuff related in the default profile :/ | 16:04 |
| lool | ysionneau: I think it's just about read on the socket | 16:04 |
| lool | ysionneau: to do open() | 16:04 |
| ysionneau | hmmm no special rights for connect listen bind send recv sendmsg ? | 16:05 |
| ysionneau | hmm maybe I can use the shm related exception ? | 16:06 |
| lool | I think you get these from network | 16:06 |
| lool | which is autopluggable | 16:06 |
| lool | ysionneau: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network.go | 16:06 |
| lool | ysionneau: so | 16:06 |
| lool | ysionneau: just say plugs: [network] | 16:06 |
| ysionneau | I already have it | 16:07 |
| === davidcalle is now known as davidcalle|afk | ||
| cholcombe | hey snappy peeps! I'm looking at the snapcraft-daily ppa and it looks like it hasn't been built in a week | 16:11 |
| cholcombe | i need the latest so i can try out the rust plugin | 16:11 |
| ysionneau | lool: question is, where do I put it (the socket :p) | 16:12 |
| lool | ysionneau: ah I was wrong, the default perms are in https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/template.go | 16:12 |
| ysionneau | thx | 16:13 |
| lool | ysionneau: unfortunately the 3 rw locations seem to be /tmp which is diverted to a per snap tmp, shm, and ptmx | 16:13 |
| lool | ysionneau: is this a rw socket you need? | 16:13 |
| ysionneau | hmmm | 16:14 |
| lool | well you'll need to send messages I guess | 16:14 |
| ysionneau | yes | 16:14 |
| ysionneau | send and receive | 16:14 |
| ysionneau | both sides are going to send/recv | 16:14 |
| lool | ysionneau: so I guess your best bet is to use a snap specific location, but avoiding the version; perhaps /snap/<snap name>/common/foo.socket | 16:15 |
| lool | that way the confined snap has rw access | 16:15 |
| lool | and the dir wont be removed if you ever create it | 16:15 |
| ysionneau | hmm so, autopilot snap, would create the socket in /snap/facedetect/common/ so that facedetect snap can open it ? | 16:15 |
| jdstrand | didrocks, lool, ysionneau: different snaps aren't allowed to talk to each other. the canonical answer is that the snap that is providing a service should provide a slot implementation of a new interface, then the other snap plugs [ the-new-interface ] | 16:15 |
| lool | jdstrand: right, this is just for doing a PoC without rebuilding snapd | 16:16 |
| ysionneau | jdstrand: that's the "clean" way, I agree with that (except that I'm not very happy to have to submit a pull request to snapd), but I would need a hackish temporary solution | 16:16 |
| lool | ysionneau: that's what I was thinking, haven't tested | 16:16 |
| ysionneau | lool: ok let's try that | 16:16 |
| didrocks | lool: I doubt the autopilot snap will be able to create in /snap/facedetect/common (confined), right? | 16:17 |
| lool | didrocks: autopilot isn't confined | 16:17 |
| jdstrand | ysionneau, lool: I think it might be possible to use the content intreface to export a rw path and then use a named socket | 16:18 |
| jdstrand | in that path | 16:18 |
| kyrofa | elopio, is snapcraft not building daily? | 16:18 |
| kyrofa | (saw cholcombe's question above) | 16:18 |
| jdstrand | caused named sockets don't need a unix rule, only a file rule, which is provided by the content interface | 16:18 |
| lool | jdstrand: is there a pointer on using content interface and is it landed? I saw it in master but have never used it | 16:18 |
| didrocks | jdstrand: content inteface doesn't enable to expose anything which isn't in $SNAP if I'm right, though? | 16:18 |
| kyrofa | elopio, is that only snapd? | 16:19 |
| didrocks | lool: I guess that's not going to fix it for you (as per ^) | 16:19 |
| lool | didrocks: not sure what you mean | 16:19 |
| jdstrand | lool: you need snapd 2.0.11 and snap-confine from xenial-proposed | 16:19 |
| lool | didrocks: sounds like exactly what we'd need: autopilot shares its socket as the contents to the facedetect snap | 16:19 |
| didrocks | you can only expose /snap/<snap_name>/<version>/ | 16:19 |
| didrocks | so the ro path | 16:19 |
| jdstrand | lool: this PR has doc updates that better document the content interface: https://github.com/snapcore/snapd/pull/1409/files | 16:20 |
| mup | PR snapd#1409: docs/interfaces.md: improve interfaces documentation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1409> | 16:20 |
| ysionneau | hmmm maybe I can create the socket in the $SNAP at build time | 16:20 |
| didrocks | no SNAP*_DATA or anything like this | 16:20 |
| didrocks | ah, if you create it at build time, that could work | 16:20 |
| jdstrand | didrocks: the exported dir is bind mounted into one of the SNAP dirs | 16:20 |
| didrocks | jdstrand: indeed, but the snap exposing the content interface requires (from the examples I saw) a path under it's $SNAP/ | 16:20 |
| lool | jdstrand: +* Auto-Connect: yes for snaps from same publisher, no otherwise | 16:21 |
| lool | jdstrand: will it work with a devmode local snap? | 16:21 |
| jdstrand | didrocks: suppose the service snap exports a rw path via content interface. that snap then creates a named socket in that rw path. then the plugging snap imports that rw path into its area and accessing that named socket | 16:22 |
| jdstrand | lool: I think you can force a manual connection. I didn't implement this feature, not sure without reading the code | 16:22 |
| didrocks | jdstrand: my point is that content interface only expose ro path (under it's $SNAP), you can't export rw path | 16:23 |
| jdstrand | no, you can | 16:23 |
| didrocks | that's what zyga told though at the heidelberg sprint | 16:23 |
| jdstrand | write (slot): read-write paths from providing snap to expose to the consuming snap | 16:23 |
| didrocks | he was going to remove the write keyword as it didn't work | 16:23 |
| jdstrand | oh, well, this is pre-Heidelberg | 16:23 |
| ysionneau | hmmm not sure in fact a socket can be created at build time and bind() to at runtime :/ | 16:24 |
| ysionneau | maybe the server *has* to create it :/ | 16:24 |
| lool | jdstrand: so providing snap would say slot [content:write: [foo.socket]] and consumer [content:target: [foo.socket]] | 16:24 |
| jdstrand | if he couldn't get that to work then this technique won't work | 16:24 |
| lool | jdstrand: how do you specify autoconnect to a fixed name snap? | 16:24 |
| lool | ysionneau: you can probably ship a socket file in the squashfs of the snap and bind it at runtime | 16:25 |
| ysionneau | well, that's the thing I'm not sure if it's possible | 16:25 |
| jdstrand | lool: I think it needs to be a dir, but yes, that is the idea. as for autoconnect, aiui it is part of snapd's interaction with the store-- if from same publisher it just does it | 16:25 |
| ysionneau | there is high chance bind()ing an already existing socket file will say "address already in use" | 16:25 |
| jdstrand | lool: note that didrocks said that zyga said that 'write' doesn't work | 16:25 |
| lool | jdstrand: but I dont see where one says which snap to connect to | 16:25 |
| lool | yeah, write is needed too | 16:25 |
| jdstrand | lool: you don't say what can connect, it just does it | 16:26 |
| jdstrand | ie, I upload a content snap, so any plugging snap I upload will autoconnect. if you plugged my content, it would not | 16:26 |
| lool | jdstrand: how do I say which content I want to autoconnect to? | 16:26 |
| didrocks | lool: http://paste.ubuntu.com/22328522/ | 16:26 |
| pmp | lool: ysionneau: maybe related?! There seems to be a env-variable called $SNAP_USER_COMMON (which currently not working according to the mailing list's discussion) | 16:26 |
| ysionneau | ok let's try the "autopilot creates the socket in /var/snap/facedetect/common" trick then | 16:26 |
| didrocks | for a content slot example | 16:26 |
| jdstrand | you get all the exports | 16:26 |
| lool | didrocks: ah great | 16:27 |
| lool | jdstrand: got it with didrocks' example | 16:27 |
| didrocks | lool: see that you only say "/foo", and this is intended as /snap/content-slot/current/foo (so relative to $SNAP) | 16:27 |
| jdstrand | ok | 16:27 |
| mup | PR snapcraft#689 closed: kernel plugin: kernel targets depending on debarch <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/689> | 16:27 |
| jdstrand | it's too bad that write doesn't work | 16:27 |
| lool | pmp: There's SNAP_COMMON as well; this is the one you want | 16:27 |
| didrocks | lool: the other side is http://paste.ubuntu.com/22328645/ | 16:27 |
| lool | pmp: USER_COMMON is per user (in home), a bit ugly IMO | 16:28 |
| didrocks | (you need to ship an empty import/ dir in $SNAP in that case ^) | 16:28 |
| jdstrand | I wonder what the issue would be. seems if you picked 'write' you'd look at the slotting snaps SNAP_DATA and if read the slotting snap's SNAP | 16:28 |
| didrocks | jdstrand: that's when I told him that all paths were related to $SNAP, and so, write won't work if you can't specify which env variable you want to be relative to that he told me write is going to be removed | 16:28 |
| lool | ----(= (..)----- | 16:29 |
| didrocks | but yeah, write would be relative to SNAP_DATA (if it worked) | 16:29 |
| jdstrand | didrocks: sure, but I don't understand why all paths must be relative to SNAP. why not SNAP_DATA? | 16:29 |
| didrocks | jdstrand: that was my question to him when this discussion happened :) | 16:29 |
| didrocks | maybe he or I was jetlag and there is a clear answer and write is going to work | 16:30 |
| lool | yeah, I think everything related to SNAP_DATA is more logical | 16:30 |
| jdstrand | didrocks: I mean, snapd could even be super smart and create the dir and everything... | 16:30 |
| lool | even read-only | 16:30 |
| lool | don't know if symlinks would work, but that's much more useful | 16:30 |
| lool | e.g. to share read-only view on live files | 16:30 |
| didrocks | lool: not really, read relative to SNAP is great for sharing libs | 16:30 |
| lool | you can always expose static contents by copy or symlink | 16:30 |
| lool | didrocks: but you can still do it | 16:30 |
| didrocks | jdstrand: +1 (yeah, creating it in the mount namespace) | 16:30 |
| lool | from SNAP_DATA | 16:30 |
| didrocks | yeah, so rather read: [SNAP_DATA/foo, SNAP/bar] | 16:31 |
| didrocks | that would be the best | 16:31 |
| jdstrand | my takeaway is that today write is probably broken, but that it is probably supportable | 16:31 |
| didrocks | and same for write: (of course, relative to SNAP, that would fail…) | 16:31 |
| didrocks | that would fix a lot of use case and avoid blocking on interface creation | 16:31 |
| ysionneau | arggggg | 16:32 |
| ysionneau | I forgot something | 16:32 |
| jdstrand | tyhicks: so, I think I may have discovered a bug | 16:32 |
| ysionneau | boxinit( autopilot snap) is sandboxed (chroot) ... it cannot easily create a socket in another snap's SNAP_DATA | 16:32 |
| ysionneau | well, I can still create a mount bind before chrooting | 16:32 |
| ysionneau | grrrrr | 16:32 |
| jdstrand | tyhicks: just so you have code to look at, https://code.launchpad.net/~jdstrand/+git/snap-userns-test | 16:33 |
| jdstrand | tyhicks: the issue is that I can't use clone(CLONE_NEWUSER) inside the sandbox. it doesn't seem related to nnp | 16:33 |
| lool | ysionneau: just bind mount when starting your chroot | 16:33 |
| lool | ysionneau: ah you've said that already | 16:33 |
| jdstrand | tyhicks: I get EPERM and no denials. I'm starting to think it might have something to do with the namespace patches | 16:34 |
| lool | ysionneau: or use shm! :-) | 16:34 |
| ysionneau | shm ? | 16:34 |
| lool | shm_open() etc. | 16:34 |
| ysionneau | I'm passing file descriptors via unix sockets etc | 16:34 |
| lool | I mean stop using real sockets and files | 16:34 |
| ysionneau | to do dmabuf (mmap) | 16:34 |
| lool | ah yeah, dont think you can pass fds over shm | 16:34 |
| jdstrand | shm_open() paths are mediated between snaps | 16:34 |
| ysionneau | to send video buffers | 16:34 |
| jdstrand | it seems like you are trying to find a hole in the sandbox (which is great, but if you find it, I will plug it :) | 16:35 |
| jdstrand | snaps are by definition isolated from each other except though defined interfaces | 16:36 |
| pmp | with jdstrand supporting us like this we will need to do a real interface in snapd for our needs | 16:36 |
| lool | jdstrand: one of them is unconfined here though | 16:36 |
| jdstrand | if all you need it a demo, then drop a rule in /var/lib/snapd/apparmor/profiles/... and run apparmor_parser -r on it after install | 16:36 |
| lool | pmp: I can hear you branching github.com/snapcore/snapd already | 16:36 |
| jdstrand | oh, well, if you use devmode your fine | 16:37 |
| jdstrand | you're | 16:37 |
| ysionneau | jdstrand: so far I found no hole, I'm using the help of a devmode snap to create the hole =) | 16:37 |
| pmp | couldn't we add an shared-files-interfaces, or shared unix-socket interfaces - where the providing snap defines a filename and users of this snap can get this filename somehow | 16:37 |
| jdstrand | put the file in SNAP_DATA on one and the then one in devmode can access it | 16:37 |
| pmp | an alternative for us would be to load the snap via the market in devmode | 16:38 |
| jdstrand | pmp: technically, sure, we could code that, however niemeyer won't approve generic interfaces like that because they are by definition not well-defined and interfaces should be well-defined | 16:39 |
| pmp | jdstrand: ack | 16:39 |
| lool | jdstrand: yes, SNAP_DATA is exactly what I suggest, but with COMMON to have a stable nam | 16:39 |
| lool | name | 16:39 |
| lool | and also a place you can use even if the snap is being removed/added | 16:40 |
| kgunn | jdstrand: any thots on why the sendto denial happens on the first start attempt? | 16:40 |
| pmp | jdstrand: another alternative would be to have snap implement/provide new interfaces | 16:41 |
| pmp | jdstrand: custom ones | 16:41 |
| pmp | jdstrand: but this won't help us for the POC | 16:41 |
| jdstrand | kgunn: presumably because the interface isn't connected yet | 16:41 |
| pmp | really, can't we convince webdm to load all snaps with --devmode? | 16:42 |
| jdstrand | pmp: I'm curious what the service is-- is it public? | 16:42 |
| jdstrand | pmp: is it webdm? | 16:42 |
| cholcombe | how do you list which plugs are available? | 16:43 |
| pmp | jdstrand: for the poc it is just that we'd like to have a snap insert something into our gstreamer-video-pipeline | 16:43 |
| jdstrand | cholcombe: snap interfaces | 16:43 |
| cholcombe | jdstrand, thanks. i get no interfaces found :( | 16:43 |
| pmp | jdstrand: we decided to do a face-detection | 16:43 |
| jdstrand | pmp: this is for webdm? | 16:43 |
| pmp | jdstrand: no | 16:43 |
| jdstrand | hmm | 16:44 |
| jdstrand | inserting something into a gstreamer pipeline, that sounds tricky | 16:44 |
| pmp | so, ehm, yes, well, how to explain?... | 16:44 |
| jdstrand | anyway, for a demo, I think one in --devmode is your best shot | 16:45 |
| pmp | we have 2 snaps, one which contains "everything" - including a video-processing-pipeline | 16:45 |
| pmp | we want to install the second snap, which modifies the video-stream, via the market | 16:45 |
| jdstrand | this is essentially the plugin problem | 16:46 |
| pmp | the market installed is done via webdm and webdm is not installing snap in devmode | 16:46 |
| pmp | yes, I wasn't aware, but the "plugin-problem" sounds like it | 16:46 |
| tyhicks | jdstrand: does it work in devmode? | 16:47 |
| jdstrand | anyway, I don't mean to distract you. we won't solve the problem now | 16:47 |
| jdstrand | tyhicks: oh, it works if I launch directly but not in strict mode. let me try devmode (silly me) | 16:47 |
| pmp | jdstrand: every input is welcome | 16:47 |
| pmp | just thinking, how is webdm installing snaps, if itself is a snap? | 16:48 |
| jdstrand | well, I can promise you I will be a part of the conversation as these things are submitted :) | 16:48 |
| jdstrand | pmp: it has access to snapd-control | 16:48 |
| jdstrand | the snapd-control interface | 16:49 |
| pmp | ok, logic, could it request an install in devmode? | 16:49 |
| jdstrand | I don't see why not | 16:49 |
| * jdstrand is not a webdm developer | 16:49 | |
| jdstrand | tyhicks: huh, it doesn't seem to work in devmode either. let me test something. gimme a sec | 16:50 |
| mup | PR snapd#1644 opened: A gpio interface for os and gadget snap <Created by jocave> <https://github.com/snapcore/snapd/pull/1644> | 16:50 |
| ysionneau | ok I made progress but it still does not work, I will have a look on monday, thanks guys for the help ! | 16:50 |
| ysionneau | see you ! | 16:50 |
| ysionneau | see you on monday pmp | 16:50 |
| pmp | ysionneau: yep, bon week-end | 16:50 |
| ysionneau | thx | 16:51 |
| tyhicks | jdstrand: ok, I'm going to step away for a short bit and will check in when I get back | 16:52 |
| jdstrand | tyhicks: ok, I confirmed the security policy is in complain mode and it doesn't work | 16:53 |
| jdstrand | tyhicks: guessing it is something with snap-confine and the bind mounts then | 16:54 |
| jdstrand | tyhicks: let me play with it | 16:54 |
| jdstrand | tyhicks: thanks for that idea | 16:54 |
| tyhicks | jdstrand: sounds good but don't rule out the possibility of a bug that affects complain mode, as well | 16:58 |
| jdstrand | tyhicks: yes, but I don't want to distract you while I (dis)prove that | 17:02 |
| mup | PR snapd#1432 closed: interfaces/builtin: improve pulseaudio interface <Reviewed> <Created by jhodapp> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1432> | 17:03 |
| mup | PR snapd#1642 closed: many: pass device to store <Created by matiasb> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1642> | 17:05 |
| niemeyer | jhodapp, morphis: ^^^ | 17:06 |
| morphis | niemeyer: what a weekend present :-D | 17:06 |
| niemeyer | morphis: Just in time! ;) | 17:06 |
| jhodapp | is it approved? :) | 17:07 |
| morphis | jhodapp: better, merged :-) | 17:08 |
| cholcombe | silly question but how do i give my snap a configuration file? I'm looking through the docs and I don't see where that's mentioned | 17:24 |
| kyrofa | cholcombe, what do you mean? | 17:27 |
| cholcombe | kyrofa, i need to give my daemon a config file to start up properly. where do i put that in that snap? | 17:27 |
| sergiusens | kyrofa I think cholcombe is talking about configuration hooks ;-) | 17:27 |
| kyrofa | cholcombe, you mean how do you get a config file into the snap itself using snapcraft? Or provide it at runtime? | 17:27 |
| * sergiusens goes for lunch | 17:28 | |
| kyrofa | cholcombe, does the config file need to be altered at runtime, or is it something you can distribute in the snap yourself? | 17:28 |
| cholcombe | kyrofa, well ideally it should be user provided. i don't know the credentials to their database, etc | 17:28 |
| cholcombe | kyrofa, no i can't distribute it | 17:28 |
| kyrofa | cholcombe, ah, indeed, then sergiusens is right | 17:28 |
| cholcombe | kyrofa, are there docs for the config hooks? :) | 17:28 |
| kyrofa | cholcombe, heh, they don't exist yet. I'm writing them right now :P | 17:29 |
| cholcombe | haha | 17:29 |
| kyrofa | cholcombe, the hooks themselves, I mean | 17:29 |
| kyrofa | cholcombe, but, you said something a little concerning | 17:29 |
| cholcombe | oh yeah? | 17:30 |
| kyrofa | cholcombe, snaps are supposed to bundle their dependencies. But it sounds like you haven't-- what database are you connecting to? | 17:30 |
| cholcombe | i'm connecting to influxdb | 17:30 |
| cholcombe | i assume that will be provided by the end user | 17:30 |
| cholcombe | is that a bad thing to assume? | 17:30 |
| cholcombe | i don't want influxdb to live on the same host as i'm installing this snap on | 17:30 |
| kyrofa | cholcombe, no, that sounds reasonable | 17:31 |
| cholcombe | this snap i'm building collects metrics and sends them off | 17:31 |
| elopio | kyrofa: no, it seems we lost the daily snapcraft job in one of the reboots. | 17:32 |
| kyrofa | cholcombe, actually, before we go anything further-- are you using 15.04, or the in-progress 16 series? | 17:32 |
| elopio | kyrofa: do you need it? It's really easy to set up. | 17:32 |
| cholcombe | kyrofa, i'm on 16.04 | 17:32 |
| kyrofa | elopio, cholcombe wanted to try out the rust plugin | 17:32 |
| cholcombe | kyrofa, yeah the rust plugin works great | 17:32 |
| cholcombe | that's all fine. i built snapcraft from the source tree and i'm using that | 17:32 |
| cholcombe | it's the config file business i'm stuck on now | 17:33 |
| kyrofa | cholcombe, okay, so you know snapd is still being developed for 16, right? Obviously you're free to use it, but you'll run into this type of thing (e.g. config not being completed) | 17:33 |
| kyrofa | cholcombe, if you're okay with that, you have a few options | 17:33 |
| cholcombe | kyrofa, oh i didn't know that | 17:33 |
| cholcombe | i mean i'm fine using whatever | 17:33 |
| kyrofa | cholcombe, you're on the cutting edge! | 17:33 |
| cholcombe | i can back off to 15.10. that's no problem | 17:34 |
| kyrofa | cholcombe, it's up to you. If you can deal with the current limitations you might be happier sticking with 16 since 15 is pretty much end-of-life | 17:34 |
| cholcombe | kyrofa, i just thought 16.04 was the stable one to use. | 17:34 |
| kyrofa | cholcombe, 16.04 desktop, definitely. But the snap side is still being developed | 17:35 |
| cholcombe | kyrofa, that's fine | 17:35 |
| kyrofa | Okay, so here's what you can do | 17:35 |
| cholcombe | i'm basically just kicking the tires here. | 17:35 |
| kyrofa | Rather, let's talk about how this WILL work real quick | 17:35 |
| cholcombe | sure | 17:36 |
| kyrofa | cholcombe, when I'm done, your users will be able to call `snap set <yoursnap> username=<username> password=<password>` | 17:36 |
| cholcombe | interesting | 17:36 |
| kyrofa | That will end up calling an executable contained within your snap located at meta/hooks/apply-config | 17:36 |
| kyrofa | That's all snapd will do for you. The apply-config executable you provide will need to handle those parameters and write them to the config file you intend | 17:37 |
| cholcombe | ok that's no problem | 17:38 |
| elopio | hum, all the slaves died. How lucky. | 17:38 |
| kyrofa | cholcombe, so: that doesn't exist yet. What I suggest you do is write something that fits similar logic though, and expose it via the apps: keyword like everything else | 17:38 |
| cholcombe | kyrofa, ok | 17:38 |
| kyrofa | Then your users can just call it directly for the time-being, and once config hooks land, the amount of work you have to do is minimal | 17:38 |
| cholcombe | kyrofa, cool. that sounds fine | 17:39 |
| kyrofa | cholcombe, remember the snap only has a few places it can write (I'm not sure how long you've been kicking the tires) | 17:40 |
| cholcombe | kyrofa, for about a week :) | 17:40 |
| kyrofa | cholcombe, so you know about SNAP_DATA, SNAP_USER_DATA, etc.? | 17:41 |
| cholcombe | kyrofa, i do yeah | 17:41 |
| kyrofa | cholcombe, you're set then. Let me know if I can help any more! | 17:42 |
| cholcombe | kyrofa, thanks :) | 17:42 |
| lool | ogra_: do you have a reliable rpi3 classic image? | 17:42 |
| lool | ogra_: I used a community one a while back, but it had misinstalled .debs and such, and relied on a PPA | 17:42 |
| ali1234 | lool: the official rpi2 classic image has misinstalled debs and relies on a ppa, so i doubt you'll find anything for the rpi3 | 17:45 |
| lool | ali1234: oh wow really? I don't remember hitting this with our official rpi2 server image | 17:45 |
| ali1234 | lool: yeah, it's broken | 17:46 |
| ali1234 | lool: dist-upgrade breaks networking | 17:46 |
| ali1234 | you can't use hats because the dt overlays are missing | 17:46 |
| lool | ali1234: crap, is there a workaround for the dist-upgrade? | 17:46 |
| ali1234 | and you need a ppa to do anything with opengl | 17:46 |
| lool | I dont care about hats that much | 17:46 |
| lool | nor opengl | 17:46 |
| ali1234 | lool: yes, hack the /etc/netowkr/interfaces manually until it works | 17:47 |
| ali1234 | the issue is systemd persistent interface names | 17:47 |
| lool | Ah | 17:47 |
| ali1234 | the base image expects that disabled. after dist-upgrade you cant disable them | 17:48 |
| ali1234 | and yes i reported these bugs on launchpad | 17:48 |
| elopio | kyrofa: cholcombe: https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily it's enabled again. | 17:59 |
| kyrofa | Thanks elopio! | 17:59 |
| cholcombe | elopio, nice :) | 18:00 |
| JamesTait | I can't help thinking this is a question that must have been asked before, but I haven't found an answer: I'm pretty sure my (cuberite) snap is hitting some seccomp constraint when running confined which results in the process being killed. How can I trace the call that's causing that? | 18:00 |
| jdstrand | JamesTait: look in /var/log/syslog. easiest is to install snappy-debug then do: sudo /snap/bin/snappy-debug.security scanlog | 18:01 |
| JamesTait | Ah - I thought that only gave output for apparmor-related stuff? | 18:02 |
| jdstrand | JamesTait: if you look just in /var/log/syslog, you'll need to use scmp_sys_resolver NN to resolve the syscall number | 18:02 |
| jdstrand | JamesTait: nope, seccomp too (it will resolve syscalls for you) | 18:02 |
| JamesTait | Then I think it's the fchown call, which I think comes from libsqlite3. 🙁 | 18:02 |
| JamesTait | But armed with the knowledge, I'll have a more thorough dig into the problem this evening. Thanks jdstrand! | 18:03 |
| jdstrand | once the snap-confine in xenial-proposed finally lands, I'll be able to make some changes to allow fchown to your own uid | 18:04 |
| kgunn | jdstrand: success! fully confined....will do final clean ups | 18:04 |
| JamesTait | jdstrand, that sounds great, can't wait! | 18:05 |
| jdstrand | kgunn: nice! | 18:05 |
| JamesTait | Have a great weekend, folks! | 18:05 |
| * JamesTait waves | 18:05 | |
| tsimonq2 | sergiusens: when's the next release planned? | 18:35 |
| sergiusens | tsimonq2 almost today | 18:39 |
| sergiusens | why? | 18:39 |
| tsimonq2 | just curious | 18:39 |
| tsimonq2 | and what does almost mean? | 18:40 |
| tsimonq2 | :P | 18:40 |
| tsimonq2 | I guess my question is, do I have a chance of getting stuff in before the next release? | 18:40 |
| ogra_ | lool only a snappy one from yesterady, no classic ... | 18:42 |
| ogra_ | lool, http://people.canonical.com/~ogra/snappy/all-snaps/all-snaps-pi3.img.xz in case that helps in any way ("sudo snap install classi --devmode --edge" works fine as well in case you need a classic env ... (use "sudo classic.create" and classic.shell with it ) | 18:44 |
| * ogra_ vanishes back into the hight | 18:45 | |
| kyrofa | Hight. Must be a German word | 18:46 |
| ssweeny | pretty short for a German word | 18:46 |
| kyrofa | tsimonq2, probably not | 18:46 |
| kyrofa | ssweeny, haha, no kidding! | 18:46 |
| tsimonq2 | kyrofa: alright thanks | 18:47 |
| tsimonq2 | kyrofa: nice catch re: bug 1586423 | 18:55 |
| mup | Bug #1586423: File-based sources (.tar, .zip, etc.) should show a progress bar when downloading <Snapcraft:In Progress by tsimonq2> <https://launchpad.net/bugs/1586423> | 18:55 |
| Guy1524 | how does snap contain programs? | 18:55 |
| Guy1524 | nvm | 18:56 |
| kgunn | sergiusens: i just thot of an interesting feature for snap ...remove-all, or has someone already asked for this ? | 19:08 |
| sergiusens | kgunn I am totally out of context | 19:08 |
| kgunn | sergiusens: was just thinking, as developers may pull down a clean core...then install a bunch of snaps, they may want to take it back to a clean core | 19:09 |
| kgunn | e.g. i've got 2 snaps...now and was just thinking it'd be nice to have one shot wipe them both | 19:09 |
| kgunn | and i suspect over time people will load more than 2 and have the same feelig | 19:09 |
| kyrofa | kgunn, https://github.com/zyga/devtools/blob/master/reset-state ? | 19:13 |
| kgunn | kyrofa: ah nice...does that work with vm's? or just local | 19:15 |
| kyrofa | kgunn, I've only run it local | 19:15 |
| Guy1524 | I have a question, why does snap need to duplicate libraries, couldn't libraries be isolated separately from applications so duplicates of the same library version don't exist | 19:18 |
| mup | PR snapcraft#712 opened: New plugin: dump <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/712> | 19:36 |
| kgunn | jdstrand: just letting you know, i'm trying to go back through all the confinement one more time...i'm noticing there's a variety of denials that occur BUT i can still launch my app | 19:57 |
| kgunn | so i'm guessing those are errant | 19:57 |
| mup | PR snapd#1645 opened: interface: add transitional browser interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1645> | 20:01 |
| jdstrand | kgunn: if you collect them in a paste, I can have a look | 20:04 |
| niemeyer | jdstrand: ping | 20:30 |
| jdstrand | niemeyer: hey | 20:34 |
| niemeyer | jdstrand: Heya | 20:34 |
| niemeyer | jdstrand: Trying to get to some quick agreements on the browser interface so we can land it | 20:34 |
| jdstrand | tyhicks: fyi, the CLONE_NEWUSER is resolved if I use the ubuntu-core-launcher in the archive. seems like a problem with snap-confine | 20:35 |
| jdstrand | niemeyer: ok | 20:35 |
| niemeyer | jdstrand: We need a new suffix for interfaces which say "this is what I need from the system to work" | 20:35 |
| jdstrand | yeah. it's weird cause that is kinda true for all of them | 20:35 |
| jdstrand | access... but that doesn't really cut it | 20:37 |
| jdstrand | tbh, I picked browser cause it was sorta like 'home' | 20:38 |
| jdstrand | in that it was a pure perm | 20:38 |
| === evanmeag_ is now known as evanmeagher | ||
| niemeyer | Yeah.. harness, although not quite.. hmm | 20:40 |
| niemeyer | -support! | 20:42 |
| jdstrand | oh | 20:42 |
| jdstrand | that is pretty good | 20:42 |
| jdstrand | niemeyer: I think that is good | 20:43 |
| niemeyer | Let's do it | 20:44 |
| jdstrand | ok | 20:44 |
| niemeyer | About hte sandbox option | 20:44 |
| jdstrand | niemeyer: thoughts on allow-browser-sandbox vs sandbox? | 20:44 |
| jdstrand | heh | 20:44 |
| niemeyer | jdstrand: How does chrome call the feature internally? | 20:44 |
| niemeyer | Is it "sandbox" simply? | 20:44 |
| jdstrand | sandbox | 20:44 |
| jdstrand | they have different sandboxes | 20:44 |
| jdstrand | setuid, usernamespace, seccomp | 20:45 |
| jdstrand | but I didn't want to expose all that | 20:45 |
| jdstrand | firefox also calls it a sandbox | 20:45 |
| jdstrand | use-internal-sandbox? | 20:45 |
| niemeyer | Ok, so we can't avoid the term.. hmm | 20:45 |
| niemeyer | Seems too much like the sandbox is about snapd | 20:46 |
| jdstrand | yeah | 20:46 |
| jdstrand | use-browser-sandbox? | 20:46 |
| jdstrand | we're pretty close to what I initially suggested :) | 20:46 |
| jdstrand | browser-sandbox? | 20:46 |
| niemeyer | can-sandbox feels okayish, I think | 20:47 |
| niemeyer | browser-support... can-sandbox.. | 20:47 |
| niemeyer | allow-sandbox isn't bad either | 20:47 |
| niemeyer | (which was your first term suggestion) | 20:48 |
| niemeyer | Alternatively, we might break that down | 20:48 |
| niemeyer | jdstrand: How specific to browser are those bits? | 20:48 |
| niemeyer | jdstrand: Would sandbox-support make sense on its own? | 20:49 |
| ahoneybun | mm wonder about that dbus-bind | 20:49 |
| niemeyer | ahoneybun: What are your wonders? :) | 20:49 |
| jdstrand | in this transitional interface, right this second, not very. but I'd like to use a child profile at some point that would be | 20:49 |
| ahoneybun | when it's coming | 20:50 |
| niemeyer | Soon! | 20:50 |
| niemeyer | ahoneybun: What are your needs? | 20:50 |
| ahoneybun | Pithos can't run without a service | 20:50 |
| jdstrand | niemeyer: so, I was trying to avoid a general sandbox-support right now, cause I don't yet understand how we can make it general | 20:50 |
| jdstrand | I know what the browsers need, right this second, so was trying to just do it all there with an attribute | 20:51 |
| jdstrand | of course, I guess there is nothing saying the attribute itself can't be 'sandbox-support' | 20:51 |
| ahoneybun | niemeyer: http://pastebin.ubuntu.com/21338511/ | 20:51 |
| jdstrand | that would look slightly weird | 20:52 |
| jdstrand | niemeyer: I could just use 'sandbox: true' and handle it in the documentation | 20:52 |
| camako | trying to run 'snapcraft cleanbuild' on my snap, but I'm getting "500 Internal Server Error"... here's the log ---> http://pastebin.ubuntu.com/22354532/ | 20:52 |
| niemeyer | jdstrand: If browsers need it and we know they need it, why is it behind an attribute, considering the only purpose of said interface is the browsers who need it? | 20:52 |
| jdstrand | this is really only meant for the major vendors in the short-medium term, not everyone in the world and not forever | 20:52 |
| jdstrand | niemeyer: well, not all browsers need it. did you see my rather long description? | 20:53 |
| camako | my lxd otherwise appears sane... anyone have an idea? | 20:53 |
| jdstrand | eg, electron doesn't need that | 20:53 |
| jdstrand | niemeyer: in other words, I expect only google and mozilla to use (and be able to use) sandbox: true. people just embedding webviews don't need it | 20:55 |
| niemeyer | jdstrand: I see.. let met review the sandbox-specific code once more | 20:55 |
| jdstrand | niemeyer: do read my (I know its lengthy) description though-- it gives justification for the implementation, talks about the store, etc | 20:56 |
| niemeyer | jdstrand: I skimmed through it all, but need to re-read enough to understand it | 20:57 |
| jdstrand | niemeyer: this also isn't the 'forever interface'. this is the 'today interface'. as we implement more and more we can move stuff out of the browser-support interface into non-transitional interfaces. I suspect one of those is user-namespace-support | 20:58 |
| jdstrand | (for example) | 20:58 |
| niemeyer | jdstrand: I have a feeling we'll live with this interface for a long time :) | 20:58 |
| jdstrand | but I was asked to unblock all this with a transitional interface | 20:58 |
| jdstrand | eh | 20:59 |
| niemeyer | jdstrand: It's responable, not complaining.. just being realistic | 20:59 |
| jdstrand | I don't know. we can get rid of all but oom_score_adj in the medium term for 'sandbox: false'. then most of sandbox: true is in 'user-namespace-support' | 20:59 |
| niemeyer | reasonable | 21:00 |
| niemeyer | jdstrand: Reading through the code, I'm not sure.. it feels like there's a lot of stuff that is there just because the browser happens to do it rather than being specific to sandboxes | 21:00 |
| jdstrand | yes | 21:00 |
| jdstrand | but we can fix that with various things | 21:00 |
| jdstrand | like the preload library | 21:01 |
| niemeyer | jdstrand: It seems better to be honest and have a wildcard browser interface that fixes the problem at hand than to generalize it poorly with unclear settings | 21:01 |
| jdstrand | or a kernel patch to allow safe use of ptrace | 21:01 |
| niemeyer | (which is exactly what you're doing there) | 21:01 |
| niemeyer | (the being honest part :) | 21:01 |
| niemeyer | jdstrand: Okay, let's go with browser-support + allow-sandbox | 21:02 |
| jdstrand | right, I didn't want to generalize poorly, which is why user-namespace-support is not a thing yet | 21:02 |
| jdstrand | ok | 21:02 |
| niemeyer | jdstrand: Hold fire, let me add a couple more comments and we can try to merge the next push | 21:04 |
| jdstrand | niemeyer: note that zyga once dinged my for your suggestion of 'allowSandbox, _ := plug.Attrs["allow-sandbox"].(bool)' | 21:12 |
| jdstrand | s/my/me/ | 21:12 |
| jdstrand | niemeyer: he said I should use the method I am since I want to test for the presence of the attribute first and then test if the bool or not | 21:12 |
| jdstrand | well | 21:12 |
| jdstrand | I already did that in SanitizePlug | 21:12 |
| jdstrand | niemeyer: ok, nm | 21:12 |
| niemeyer | jdstrand: Ok, done | 21:13 |
| niemeyer | jdstrand: Just trivials.. | 21:14 |
| jdstrand | niemeyer: the unity7 change was in fact needed for chrome. do you want another PR? | 21:21 |
| niemeyer | jdstrand: If it's related it's fine | 21:21 |
| niemeyer | jdstrand: Let me know when you're done | 21:21 |
| jdstrand | just running ./run-tests | 21:22 |
| jdstrand | github has a much nicer way of showing the changes after a git mv than 'git show' | 21:24 |
| jdstrand | ok, pushed but let me double check twith real snaps | 21:28 |
| niemeyer | jdstrand: Thanks! | 21:31 |
| niemeyer | jdstrand: renames in git are a bit weird | 21:31 |
| niemeyer | jdstrand: It's all detection based | 21:31 |
| niemeyer | Sometimes github shows really awkward "renames", when files are too small.. it thinks it's a move as the license header remains the same | 21:32 |
| niemeyer | jdstrand: One of the trivial code improvement suggestions didn't land.. no biggie though | 21:34 |
| mup | PR snapd#1637 closed: cmd/snap,cmd/snap-exec: support hooks again <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1637> | 21:37 |
| niemeyer | ahoneybun: Sorry for the trouble there.. will try to get the dbus iface in sooner rather than later | 21:39 |
| niemeyer | jdstrand: On those topics, we need to find a good name for that general dbus interface | 21:40 |
| * jdstrand notes running 5 snapcraft's in parallel on big snaps is probably not the best idea | 21:42 | |
| kyrofa | jdstrand, pshh. Half the time is pulling anyway | 21:44 |
| kyrofa | jdstrand, perhaps you should start them staggered, though | 21:45 |
| jdstrand | not on these snaps :) | 21:45 |
| kyrofa | Oh :P | 21:45 |
| kyrofa | jdstrand, what is a big snap that doesn't involve pulling? | 21:45 |
| kyrofa | jdstrand, also, why aren't you using launchpad to build them? | 21:46 |
| jdstrand | it involves pulling | 21:46 |
| jdstrand | it is just the other bits take a long time too | 21:46 |
| sergiusens | jdstrand snap try! | 21:46 |
| jdstrand | chrome, chromium, firefox, electron and vscode all in parallel | 21:46 |
| jdstrand | no, I needed real snaps | 21:46 |
| jdstrand | anyway | 21:46 |
| kyrofa | Ah, very nice | 21:46 |
| jdstrand | it's done | 21:47 |
| jdstrand | niemeyer: ok, I pushed the simplification. things are good on my end | 21:47 |
| niemeyer | jdstrand: Cool, will just wait for tests | 21:53 |
| niemeyer | jdstrand: dbus-object is an interesting candidate for that other interface | 21:53 |
| jdstrand | niemeyer: hmm, it is. I've got a hard stop in 4 minutes. I'll think about that and maybe we can pick up on Monday? | 21:57 |
| * jdstrand used dbus-app since it had mild acceptance on the list, but is happy to change it | 21:57 | |
| niemeyer | jdstrand: Yeah, let's talk on Monday | 21:58 |
| niemeyer | jdstrand: Have a good weekend | 22:01 |
| jdstrand | niemeyer: have a nice weekend :) | 22:01 |
| jdstrand | heh | 22:01 |
| niemeyer | ! | 22:01 |
| niemeyer | :) | 22:01 |
| niemeyer | Thanks | 22:01 |
| jdstrand | niemeyer: something with freedesktop in the name might be interesting too (it is af.d.o spec) | 22:01 |
| jdstrand | thank you | 22:01 |
| jdstrand | too :) | 22:01 |
| jdstrand | gotta run! :) | 22:01 |
| mup | PR snapd#1636 closed: snap: don't load unsupported implicit hooks <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1636> | 22:19 |
| mup | PR snapd#1645 closed: interface: add transitional browser-support interface <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1645> | 22:24 |
| mup | PR snapd#1646 opened: cmd/snap,overlord/hookstate: support hook data transfer <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1646> | 23:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!