| huwshimi | Hello. I have a snap that installs, but doesn't expose the command. I can see the file for the command in places like stage/usr/bin, but once the snap is installed the command does not exist. Snap here: http://paste.ubuntu.com/23105293/ | 00:30 |
|---|---|---|
| huwshimi | Any guidance appreciated! | 00:30 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#1772 opened: cmd: enable SNAP_REEXEC only if it is set to SNAP_REEXEC=1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/1772> | 05:48 |
| mup | Bug #1617890 opened: 2.12 crashes with latest ubuntu-core snap due to re-exec <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1617890> | 05:51 |
| mup | PR snapd#1773 opened: firstboot: disable firstboot on classic for now <Created by mvo5> <https://github.com/snapcore/snapd/pull/1773> | 05:57 |
| mup | PR snapd#1774 opened: tests: add test for current snapd with ubuntu-core/edge interactions <Created by mvo5> <https://github.com/snapcore/snapd/pull/1774> | 06:27 |
| dholbach | hey hey | 06:37 |
| liuxg | I have python as plugin in both parts, when building the projects, some files are copying to the same locatiton, resulting conflicts like http://paste.ubuntu.com/23106210/. how can I avoid this issue? | 06:38 |
| tvoss | good morning :) | 06:43 |
| dholbach | liuxg, maybe file a bug report on snapcraft? | 07:05 |
| liuxg | dholbach, yeah, I think so. I will do that, thanks | 07:05 |
| dholbach | thanks | 07:05 |
| liuxg | dholbach, I have reported it at https://bugs.launchpad.net/snapcraft/+bug/1617907 | 07:13 |
| mup | Bug #1617907: Two python parts in the same snapcraft.yaml result in not installing the python correctly <Snapcraft:New> <https://launchpad.net/bugs/1617907> | 07:14 |
| dholbach | great | 07:14 |
| mvo | pitti: hi, quick question - we have the netplan config in snapd now, its great. its also static, so I would like to ship it just in the ubuntu-core-config (which is only installed on ubuntu-core devices) package as a static /etc/netplan/00-default.yaml package | 07:16 |
| mvo | pitti: eh, static file of course. any reason not to do that? | 07:17 |
| pitti | mvo: what does it contain? | 08:03 |
| zyga | good morning | 08:03 |
| pitti | mvo: I'm not a big fan of constant config files in /etc, I must say | 08:03 |
| pitti | mvo: if we start doing that, I'd rather add support for /lib/netplan/*.yaml | 08:03 |
| mup | PR snapd#1769 closed: snap: add export-key --account= option <Created by cjwatson> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1769> | 08:16 |
| === JanC is now known as Guest45177 | ||
| === JanC_ is now known as JanC | ||
| tvoss | mvo: hey, did you have a chance to raise the topic of vendorizing go build deps for snapd? | 08:33 |
| === carlo is now known as Guest67116 | ||
| mvo | pitti: support for /lib/netplan/*.yaml sounds great, if its not too much work, I can also look at it if you are too busy | 08:50 |
| pitti | mvo: already at it | 08:50 |
| mvo | tvoss: not explicitely, we talked about it in the team recently and the concensus was that we want to do it | 08:50 |
| mvo | pitti: cool, thanks! for context: https://github.com/snapcore/snapd/pull/1765/files#diff-7c06ac92ab14c8f3ece674037573ceddR14 is the config we want to ship by default | 08:51 |
| mup | PR snapd#1765: many: move network initialization to a separate service <Created by mwhudson> <Conflict> <https://github.com/snapcore/snapd/pull/1765> | 08:51 |
| pitti | mvo:/url 2 | 08:51 |
| pitti | mvo: oh - DON'T ever ship that in a package | 08:51 |
| pitti | mvo: this means that you cannot ever reconfigure any device, as 00-* is always the first match | 08:52 |
| tvoss | mvo: ack, will join your standup today then (if I can make it) | 08:52 |
| mvo | pitti: ok, so this needs to be 99-ubuntu-core-defaults if we move it to a package? | 08:53 |
| pitti | mvo: mwhudson discussed that with slangasek and me recently; AFAIR the idea was to only create that file in /run/ if there is no actual config (i. e. before running console-conf), and as soon as there is some /etc/netplan/* then not generate it any more | 08:53 |
| mvo | pitti: and it would be in a package that is only installed on core systems, is that ok? | 08:53 |
| mvo | pitti: oh, I see /run - hm | 08:53 |
| pitti | mvo: actually, the name of the *.yaml is not that relevant | 08:54 |
| pitti | there is no natural order in the yaml definitions | 08:54 |
| pitti | other than that later definitions override previous ones | 08:55 |
| mvo | pitti: hmhm, ok, let me ponder a bit if we only want this in /run under these conditions that changes the picture a little bit | 08:55 |
| pitti | mvo: I suggest talking to mwhudson, he is also working on this and it seems that there is a lot of overlap and not enough coordination | 08:55 |
| mvo | pitti: yeah, I started talking to him and he directed me to you :) thanks, I think I know all I need to know for now | 08:56 |
| pitti | mvo: anyway, suport for /lib/netplan/ committed, it would also be useful for things like lxc (bridge configs) | 09:04 |
| mvo | pitti: \o/ | 09:08 |
| * ogra_ grins about https://github.com/snapcore/snapd/pull/1573 | 09:13 | |
| mup | PR snapd#1573: asserts/tool,cmd/snap: introduce hidden "snap sign" <Created by pedronis> <https://github.com/snapcore/snapd/pull/1573> | 09:13 |
| ogra_ | we have a secret handshake ! | 09:14 |
| ogra_ | cjwatson, is there any known way for me to find out a revision number for a snap that was auto-uploaded by LP ? | 09:16 |
| ogra_ | (would be nice to be able to map a revision to a build number and log) | 09:17 |
| ogra_ | i see i get a "manage this package in the store" link after successful upload on the UI page, but i dont see anything in the LP api that would map to this | 09:29 |
| zyga | ogra_: do you have a 3.4 based kernel around on any device? | 10:04 |
| pitti | ogra_: manual wifi bringup with wpasupplicant and networkd works fine; now it's a SMOP :) | 10:04 |
| zyga | ogra_: would you mind doing ls -ld /proc/$$/ns/mnt for me? | 10:04 |
| ogra_ | zyga, snappy device ? no, i dont | 10:04 |
| pitti | ogra_: (and SMOWTC) | 10:04 |
| zyga | ogra_: no, any device | 10:05 |
| zyga | ogra_: (phone is good) | 10:05 |
| * ogra_ hugs pitti and looks up acronyms :) | 10:05 | |
| pitti | ogra_: I just made it up -- SMO writing test cases :) | 10:05 |
| ogra_ | :) | 10:05 |
| pitti | ogra_: oh, "simple matter of programming" (but that's rather common) | 10:06 |
| zyga | hah | 10:06 |
| zyga | it's all doable, it's all software ;) | 10:06 |
| ogra_ | zyga, i only have 3.10 :/ | 10:07 |
| cpaelzer | Hi, I was asked by elopio to move some bits out of my waf integration test belonging to PR 716 to be an external part | 10:08 |
| zyga | ogra_: that's actually good, is that ubuntu phone? | 10:08 |
| ogra_ | yes | 10:08 |
| cpaelzer | I thought I updated https://wiki.ubuntu.com/snapcraft/parts the right way, but something is missing | 10:08 |
| ogra_ | ooh ... | 10:08 |
| zyga | ogra_: thanks, I was worried that older kernels are still around | 10:08 |
| cpaelzer | is there any update cycle or anything I have to wait until I can discover a part there? | 10:08 |
| * ogra_ just found one machine in his network running 2.6.37 | 10:08 | |
| ogra_ | i guess its time to upgrade that one | 10:09 |
| ogra_ | zyga, they are ... u just dont have any active phone with them anymore | 10:09 |
| ogra_ | s/u/i/ | 10:09 |
| ogra_ | zyga, only the last two devices had 3.10 | 10:09 |
| ogra_ | nexus and the bq phones are all 3.4 | 10:10 |
| cpaelzer | no matter if the part is already right yet (not sure on that part) I'd have expected that "snapcraft update && snapcraft search wafdemo" gets me something, but it doesn't | 10:10 |
| mup | PR snapd#1775 opened: Add thumbnailer interface <Created by fkaleo> <https://github.com/snapcore/snapd/pull/1775> | 10:17 |
| === hikiko is now known as hikiko|ln | ||
| ogra_ | cjwatson, there is an update on bug 1608432 for you | 10:59 |
| zyga | mwhudson: around? | 10:59 |
| mup | Bug #1608432: snaps with type: os should allow publishing of .manifest files <launchpad-buildd:New> <Snapcraft:Incomplete> <https://launchpad.net/bugs/1608432> | 10:59 |
| mup | PR snapd#1773 closed: firstboot: disable firstboot on classic for now <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1773> | 11:08 |
| Son_Goku | morning | 11:20 |
| zyga | Son_Goku: hey | 11:22 |
| Son_Goku | hello | 11:23 |
| === hikiko|ln is now known as hikiko | ||
| Son_Goku | zyga, so, did you get anywhere on the path relocation? | 11:33 |
| zyga | Son_Goku: yes, it basically works now, I need to work on selinux support in systemd to let the service start now | 11:43 |
| ogra_ | mvo, btw, not sure you have seen https://github.com/snapcore/classic-snap/pull/4 | 11:55 |
| mup | PR classic-snap#4: merge recent changes that are in the store, improve bin/classic <Created by ogra1> <https://github.com/snapcore/classic-snap/pull/4> | 11:55 |
| ogra_ | (sorry for the ping in the wrong channel before) | 11:55 |
| Son_Goku | zyga, you might want to look at the abrt service policy as an example | 12:05 |
| Son_Goku | https://github.com/fedora-selinux/selinux-policy/tree/rawhide-contrib | 12:05 |
| mvo | ogra_: checking | 12:22 |
| mup | Bug #1618004 opened: Need a classic-bin interface to see classic binaries <Snappy:New> <https://launchpad.net/bugs/1618004> | 12:23 |
| mvo | ogra_: thanks, nice one, merge - I assume you alrady pushed it? | 12:23 |
| ogra_ | mvo, not yet, doing so now (i didnt know how you wanted to handle the missing bits) | 12:24 |
| mvo | ogra_: I think its was a forgoten push on my side, sorry for that | 12:25 |
| ogra_ | NP | 12:25 |
| mup | PR snapd#1683 closed: osutil: fix create-user on classic <Reviewed> <Created by jaymell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1683> | 12:42 |
| mup | PR snapcraft#763 opened: Include /sbin and usr/sbin in wrappers <Created by lool> <https://github.com/snapcore/snapcraft/pull/763> | 12:42 |
| arges | elopio: I see bug 1616157 has been verified, should I tag it 'verification-done'? And mvo is it ready for release into xenial? | 12:51 |
| mup | Bug #1616157: [SRU] 2.13 <verification-needed> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1616157> | 12:51 |
| mup | PR snapd#1776 opened: image: snap assertions into image <Created by pedronis> <https://github.com/snapcore/snapd/pull/1776> | 12:56 |
| mup | PR snapd#1723 closed: image: prepare-image: import snap assertions as well <Created by mvo5> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1723> | 12:57 |
| mup | PR snapd#1777 opened: osutil: tweak the createUserTests a bit and extract common code <Created by mvo5> <https://github.com/snapcore/snapd/pull/1777> | 12:57 |
| === dpm is now known as dpm-afk | ||
| mvo | arges: I have a look, in a meeting right now | 13:03 |
| Kaleo | zyga, hey :) thanks for the review | 13:03 |
| Kaleo | zyga, looks like I forgot a commit :) | 13:04 |
| ogra_ | hmm, no sergio today ? | 13:05 |
| Kaleo | zyga, please ignore the entire PR until I add that commit :) | 13:05 |
| Kaleo | zyga, and voila | 13:06 |
| Kaleo | zyga, I'm sorry I wasted your time | 13:06 |
| Kaleo | zyga, about the snap/implicit.go, is there some documentation of what it means? | 13:08 |
| zyga | Kaleo: I'll check it after the meeting | 13:11 |
| Kaleo | thanks | 13:11 |
| zyga | Kaleo: look at snap/implicit.go and look what's there, there's no docs but I have a blog post about it on zygoon.pl (the lastest one) | 13:11 |
| zyga | Kaleo: please check it out | 13:11 |
| Kaleo | cheers | 13:12 |
| jdstrand | lool, tianon: hey I read lool's status on the docker PR progress. I thought there were still some open questions that needed to be addressed before another review and I got the impression one of you would be working on the kernel modules backend. | 13:14 |
| lool | jdstrand: I actually got the impression you would be coming back to the review after a while | 13:15 |
| lool | jdstrand: :-) | 13:15 |
| jdstrand | well, I planned to come back to the review, but thought people were working on the kernel modules backend | 13:16 |
| lool | jdstrand: I'm not sure who if anyone has time to work on the kernel module backend | 13:16 |
| jdstrand | if it makes sense for me to do another round of reviews, I can | 13:16 |
| jdstrand | hrmm | 13:16 |
| lool | I dont know if I can ask tianon to work on this, if he can't I imagined I'd end up doing it | 13:16 |
| lool | but I was hoping someone from the core team would come to it first | 13:17 |
| jdstrand | lool: this might be a question to have with JamieBennett | 13:17 |
| jdstrand | err | 13:17 |
| jdstrand | a conversation to have with him | 13:17 |
| lool | Yes | 13:17 |
| lool | jdstrand: it would be helpful to know how much other things are needed for this to get in | 13:17 |
| lool | how many / how much work | 13:18 |
| jdstrand | I was assigned some high priority (snappy) work a week and half ago so I've been trying to get through all that while (I thought) the other issues with docker were being worked on. if you're saying you're blocked on me, I can try to get through that review today | 13:20 |
| lool | jdstrand: I think we're blocked on your next review + this kernel module feature which isn't docker specific but that docker seems to need first | 13:21 |
| lool | jdstrand: I dont know of other work on the snap / interface that was requested in the pull request and wasn't done | 13:21 |
| jdstrand | lool: fwiw, that feature is needed by firewall-control for the GA release for a customer requirement. it's also needed by ppp interface | 13:22 |
| jdstrand | I guess I'll take a look at that. I'll try to get to that today | 13:22 |
| lool | jdstrand: cool; I'm currently debugging other issues with the docker snap on classic (works on core but not on classic with weird errosr) | 13:22 |
| zyga | jdstrand: before 3.8 /proc/$PID/ns/mnt did not exist | 13:22 |
| jdstrand | zyga: sounds like that is a patch to add to the list. I wonder how intrusive it is. I suspect very-- we've said in the past 3.4 kernels can't be used to run lxd/docker | 13:24 |
| * jdstrand is recalling from memory. ogasawara would probably have the definitive answer | 13:25 | |
| lool | I thought 3.10 was needed for systemd anyway? | 13:25 |
| zyga | jdstrand: we have a few options for that | 13:27 |
| zyga | jdstrand: one easy one is that this feature is not supported on 3.4 | 13:27 |
| zyga | jdstrand: a more complex one could usee a zygote process | 13:27 |
| zyga | jdstrand: and a backport for this patch could be a third approach | 13:27 |
| zyga | lool: I'm not sure | 13:27 |
| zyga | lool: if so, then this discussion is moot, I guess this is about defining a baseline kernel for snappy | 13:28 |
| tedg | Is there a recommended way to get $HOME back to the correct value? | 13:28 |
| tedg | Tried with getent, but don't have permissions. | 13:28 |
| zyga | tedg: I don't believe there is | 13:28 |
| lool | I believe the oldest we provide for apparmor patches is 3.10 | 13:28 |
| tedg | Uhg, it makes the open/close dialog in Inkscape mostly unusable :-( | 13:29 |
| lool | we probably had older patchsets, but we haven't updated them | 13:29 |
| jdstrand | zyga: I really don't like the zygote approach in general. it depends on how it is implemented | 13:29 |
| zyga | tedg: snappy could easily set a variable like SNAPPY_OLD_HOME | 13:29 |
| stokachu | im trying to get my systemd bridge service working and not able to get an ip assigned to it, https://paste.ubuntu.com/23107318/ | 13:29 |
| lool | actually systemd requires >= 3.4 | 13:29 |
| zyga | jdstrand: I think we agree on this | 13:29 |
| jdstrand | lool: apparmor isn't the probelm-- we have patches for 3.4 kernel for touch | 13:29 |
| jdstrand | I'm not sure how up to date they are as of this second, but that is certainly possible. | 13:29 |
| lool | jdstrand: in the snappy kernel templates, we only offer 3.10 and onwards | 13:30 |
| mvo | arges: yeah 2.13 looks good, the issues that elopio mentioned with gnome-software is a bug in 2.12, we are working on a fix | 13:30 |
| jdstrand | lool: ogasawara maintins a list somewhere | 13:30 |
| Son_Goku | lool, afaik, newest systemd requires kernel >= 3.14, iirc | 13:30 |
| tedg | zyga: Sure, but then I'd need a specific version of ubuntu-core, which I can't depend on. | 13:30 |
| jdstrand | lool: that may be because other things have made them say that 3.4 is not possible, so we said "well, then we don't have to produce apparmor backports" | 13:30 |
| lool | jdstrand: https://docs.google.com/document/d/1LOqrSty2yTsUtQ4nFehaisZc4XmKKsK_E_tz-O1hU-M/edit | 13:30 |
| jdstrand | sure, it is a cause and effect thing | 13:31 |
| jdstrand | the effect of not supporting snappy on 3.4 is that it causes the security team to not provide backports to 3.4 :) | 13:31 |
| lool | jdstrand: yup; I'm just trying to be realistic; I believe the oldest we consider maintainable is 3.10, but of course everything is possible :-) | 13:32 |
| ogra_ | tedg, just use /home/$USER ? | 13:32 |
| jdstrand | sure. I'm just saying that *apparmor* is not why it isn't maintainable | 13:32 |
| lool | jdstrand: sorry it's just the first thing we're missing when we're applying the ubuntu patches | 13:33 |
| lool | (over vanilla / bsp kernels) | 13:33 |
| zyga | tedg: you can, there's a mechanism for that | 13:33 |
| tedg | ogra_: Yeah, can try that as a work around. Good idea. | 13:33 |
| lool | didn't | 13:33 |
| lool | didn't mean to pick on these patches specifically | 13:33 |
| lool | it's all our ubuntu sauce | 13:33 |
| zyga | tedg: assume (or somethng like that) you can put this into your snapcraft.yaml | 13:33 |
| lool | jdstrand: this was an earlier effort of mine to capture the reqs https://docs.google.com/document/d/1W9TJDTWevnxARYaE3w7fahXeCgjv_9xJ2RTZ6nN0Va4/edit | 13:33 |
| zyga | tedg: in general it feels like a bug to fix | 13:33 |
| lool | which was after internal consultation | 13:34 |
| ogra_ | zyga, but rarher in the desktop launcher than in snapcraft | 13:34 |
| ogra_ | err | 13:34 |
| ogra_ | snapd | 13:34 |
| ogra_ | after all it is the launcher wrapper script that forces $HOME | 13:34 |
| tedg | zyga: Hmm, I see that in the snapcraft schema, but I don't see what the string needs to look like. "ubuntu-core>x.y.z" ? | 13:35 |
| === dpm-afk is now known as dpm | ||
| zyga | tedg: it's a list of strings | 13:43 |
| zyga | tedg: each string is a feature flag you can request from snapd | 13:43 |
| zyga | tedg: e.g. old-home-env | 13:43 |
| zyga | tedg: snapd knows which flags it supports | 13:43 |
| zyga | ogra_: no, that's actually in snapd itself | 13:44 |
| tedg | zyga: Oh, so it's not requesting a specific version as much as a set of features. | 13:44 |
| zyga | ogra_: the launcher doesn't change home AFAIR | 13:44 |
| zyga | tedg: exactly | 13:44 |
| zyga | ogra_: the wrapper script is made by snapd | 13:44 |
| ogra_ | i thought it has HOME="$SNAP_USER_DATA" | 13:44 |
| zyga | ogra_: and since 2.14 those are gone | 13:44 |
| zyga | ogra_: so this is all managed internally in snapd | 13:44 |
| zyga | ogra_: (no more wrappers! | 13:44 |
| ogra_ | (talking about the desktop wrapper here) | 13:45 |
| zyga | ogra_: that's all snapd | 13:45 |
| zyga | ogra_: snapd can now set environment in the started app processes | 13:45 |
| tedg | Wait, so how is snapd launching the process? Spawning from its own then? | 13:47 |
| ogra_ | zyga, yeah, i just checked, it doesnt touch HOME ... only creates a ton for XDG dirs in SNAP_USER_DATA | 13:48 |
| tedg | Or is the CLI starting the application. | 13:48 |
| ogra_ | s/for/of/ | 13:48 |
| zyga | tedg: it's complex, the app name, say "foo", is a symlink to snap-run | 13:48 |
| zyga | tedg: snap-run does some stuff, run snap-confine, which does some more and runs snap-exec which does some more and exec's the command associated with the snap | 13:48 |
| tedg | zyga: So for starting apps I should be calling that symlink still? Or calling snap-run? | 13:49 |
| zyga | tedg: nothing changes for the user | 13:49 |
| zyga | tedg: this is all an internal change | 13:49 |
| zyga | tedg: and snap-run is not on PATH AFAIK | 13:49 |
| tedg | zyga: Well, I'm kinda a special user here :-) | 13:49 |
| zyga | tedg: why? | 13:50 |
| zyga | tedg: I mean, this should not be visible to anyone in practice | 13:50 |
| tedg | zyga: Becuase we're setting up the exec in Upstart for desktop apps | 13:50 |
| zyga | tedg: it's just an optimization that gives us some more control | 13:50 |
| zyga | tedg: that should just run the command as it in the desktop file | 13:50 |
| tedg | zyga: Ideally, but the desktop files aren't that useful. | 13:51 |
| tedg | (the ones generated by snapd) | 13:51 |
| zyga | tedg: perhaps what you want to do should be managed by snapd itself | 13:51 |
| zyga | tedg: I'm not sure what this is exactly, feel free to ask for more information if that helps you | 13:51 |
| tedg | zyga: I am :-) | 13:52 |
| * ogra_ thought we are drooping Üpstart this cycle from desktop | 13:52 | |
| stokachu | when i install a snap it runs both command and stop-command via oneshot | 13:52 |
| stokachu | https://paste.ubuntu.com/23107384/ | 13:52 |
| tedg | zyga: Seems like the symlink should work fine for now. | 13:52 |
| stokachu | i just need it to run the start command and then the stop command on uninstall | 13:52 |
| tedg | ogra_: Trying for Unity7, not for Unity8. | 13:52 |
| stokachu | not at once | 13:52 |
| ogra_ | ah | 13:52 |
| zyga | anyone, what's the glib-way to rm -rf a directory? | 13:52 |
| zyga | (this is for unit test code) | 13:52 |
| ogra_ | stokachu, i would imaggine running stop-command on install is a bug ... but nontheless your script should check if what it wants to stop is actually running | 13:54 |
| stokachu | ogra_, huh? there is nothing running | 13:54 |
| stokachu | the start command runs some ip/iptables commands | 13:54 |
| ogra_ | so it should exit gracefully | 13:54 |
| ogra_ | hmm, actuall running the stop command makes indeed sense on upgrades | 13:56 |
| ogra_ | so iits probably not a bug at all | 13:56 |
| stokachu | it runs the start command then stop-command right after | 13:56 |
| stokachu | running the stop-command before the command makes sense | 13:56 |
| zyga | stokachu: note, this is all systemd stuff | 13:57 |
| zyga | stokachu: nothing is done by snapd here | 13:57 |
| zyga | stokachu: whatever you are experiencing is systemd related | 13:57 |
| zyga | stokachu: we just start/stop units | 13:57 |
| zyga | stokachu: (we do stop and start the units on upgrades) | 13:57 |
| stokachu | you call stop-command after the start command? | 13:57 |
| ogra_ | zyga, well, you can define stop-command for a daemon | 13:57 |
| ogra_ | snapd should make sure what it generates can be run in the desired order | 13:58 |
| lool | elopio: are the snapcraft integration tests usually passing? I get an error on snapcraft-parser | 13:58 |
| ogra_ | stop-command should be only run on shutdown or uninstall of the package ... or before an upgrade wants to start the daemon newly | 13:58 |
| stokachu | which it's not doing now | 13:59 |
| ogra_ | right | 13:59 |
| zyga | ogra_: snapd just generates a systemd unit file, all the running is done by systemd | 14:00 |
| ogra_ | zyga, well, but if snapd allows us to define a stop-command for a daemon it should not "just run" | 14:00 |
| ogra_ | only for stopping the daemon | 14:00 |
| ogra_ | so imho something is generated wrongly | 14:01 |
| ogra_ | probably a Chipaca topic | 14:01 |
| zyga | ogra_: check the systemd unit, does it look good or bad? | 14:02 |
| ogra_ | no idea ... its stokachu's unit :) | 14:02 |
| stokachu | where is that located | 14:02 |
| ogra_ | but it is clear that tthe two units run in the wrong oorder on package install | 14:03 |
| stokachu | ogra_, zyga https://paste.ubuntu.com/23107454/ | 14:06 |
| stokachu | so my oneshot daemon runs command, then stop-command directly after | 14:07 |
| lool | elopio: well they are passing on travis; not sure why it fails here | 14:07 |
| zyga | stokachu: looking now | 14:08 |
| zyga | stokachu: can you pastebin the snap.conjure-up.bridge.service file | 14:08 |
| zyga | stokachu: it should be easy to find in /etc | 14:09 |
| stokachu | zyga, https://paste.ubuntu.com/23107463/ | 14:09 |
| stub | Given I can do both, should I create my daemon simple or forking? | 14:18 |
| lool | kyrofa: travis completed on the /sbin branch | 14:18 |
| stub | Any advantages of one over the other? | 14:18 |
| lool | (successfully) | 14:18 |
| ogra_ | zyga, stokachu, hmm, i wonder if it should actually be oneshot if it has a stop command defined | 14:19 |
| lool | kyrofa: I couldn't open the autopkgtests links | 14:19 |
| cmars | zyga, hi, i was following your blog post on writing an interface. i'd like to write one for libvirt, so that snaps can control it on a classic host | 14:19 |
| mup | PR snapd#1772 closed: cmd: enable SNAP_REEXEC only if it is set to SNAP_REEXEC=1 <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1772> | 14:19 |
| stokachu | ogra_, should i just put the tear down of iptables etc in the same start script | 14:19 |
| stokachu | and handle it logically | 14:19 |
| cmars | zyga, i got the socket part working, but the snap i'm working on wants to see stuff in /var/lib/libvirt, such as dnsmasq | 14:20 |
| ogra_ | you could indeed do that ... | 14:20 |
| cmars | zyga, how would i expose that through the interface? (or is this even a good idea?) | 14:20 |
| stokachu | ogra_, what about snap remove? | 14:20 |
| ogra_ | that would call stop | 14:21 |
| stokachu | so maybe just a bridge script that'll accept an argument | 14:21 |
| cmars | zyga, i tried adding /var/lib/libvirt/** to the aa profile, but the plugged-in snap doesn't seem to see it. is there some mounting that would need to happen? | 14:21 |
| mvo | a new ubuntu-core stable got just released, it is based on 2.13, please do let me know if you notice any issues | 14:24 |
| sergiusens | good morning | 14:24 |
| mvo | arges: there was some talk about command not found hanlding? do you have some details for me? | 14:24 |
| josepht | good morning sergiusens | 14:26 |
| zyga | cmars: if you explore the environment you will see that /var/lib/libvirt just doesn't exist in the core snap | 14:26 |
| zyga | cmars: as a easy workaround please look at snap-confine and at quirks.c therein (look for lxd quirk) | 14:26 |
| zyga | cmars: note that this is only for a devmode snap as no interface allows any snap to use /var/lib/lxd | 14:27 |
| zyga | cmars: I would recommend you to create an interface that bind mounts /var/lib/lxd from the host into a snap-specifc directory | 14:27 |
| zyga | cmars: I'm not familar with libvirt, does it need just a socket or the whole directory tree | 14:28 |
| cmars | zyga, the socket, but also parts of the tree, such as /var/lib/libvirt/dnsmasq, if you want to read the IP addresses of VMs for example | 14:29 |
| zyga | cmars: I would recommend you to also report a bug tagged with snapd-interface and ask jdstrand for advice | 14:29 |
| zyga | cmars: I see | 14:29 |
| cmars | zyga, ok, will do | 14:29 |
| zyga | cmars: we can use the mount backend to bind mount /var/lib/lxd to a directory in the snap (relative to $SNAP_DATA) | 14:30 |
| stokachu | i thought interfaces was a last resort and that we should be packaging every requirement in the same snap | 14:30 |
| zyga | cmars: then you can patch or config libvirt inside the snap to assume that libvirt is in that directory | 14:30 |
| zyga | stokachu: interfaces allow to shape the sandbox in which apps execute | 14:30 |
| zyga | stokachu: if you want to have a snap that talks to something in the classic world or talks to another snap you can use an interface for this | 14:31 |
| stokachu | snaps have no notion of dependencies though | 14:31 |
| zyga | stokachu: it feels perfectly fine to have a snap with libvirt or libvirt installed on classic and an interface that allows another snap to talk to libvirt (wherever it is) | 14:31 |
| stokachu | how would someone know that libvirt is a requirement for cmars snap? | 14:33 |
| zyga | stokachu: the snap would declare a plug of type 'libvirt' | 14:35 |
| zyga | stokachu: we have no syntax for this but plugs will have a way to say "I have to be connected before this snap can be used" | 14:35 |
| mhall119 | zyga: is somebody working on adding the content interface details to the existing docs? | 14:36 |
| elopio | lool: hello. What error are you getting locally? | 14:36 |
| zyga | stokachu: then however that libvirt is provided (could be from the core snap, could be from another snap) | 14:36 |
| cmars | i imagine it's a similar situation for snaps that need to plug into mir & x11 | 14:36 |
| zyga | mhall119: not that I'm aware of, I'll do this after snap-confine features for 1.0.41 are implemented | 14:36 |
| zyga | cmars: yes | 14:36 |
| stokachu | cmars, read the docs for now? | 14:36 |
| elopio | cpaelzer: maybe josepht can help you with the wiki entry. I get no parsing errors, but I also don't get the new part. | 14:37 |
| === kirkland` is now known as kirkland | ||
| cpaelzer | elopio: ok, thanks for the update | 14:39 |
| cpaelzer | elopio: that is why I opened the bug on LP to give people some time to really look at it | 14:39 |
| lool | elopio: I couldn't reproduce it after rerunning; here's the one I get locally right now: | 14:39 |
| lool | elopio: http://paste.ubuntu.com/23107571/ | 14:39 |
| cmars | zyga, thanks for the advice, snap-confine sources are clearing things up for me :) | 14:42 |
| jdstrand | zyga (cc cmars): fyi, a libvirt interface is going to be super-privileged, like docker and lxd | 14:42 |
| zyga | jdstrand: I agree, note that it seems that it is just the plug-side of libvirt for now | 14:42 |
| jdstrand | session:/// wouldn't need to be. but no one uses session:/// | 14:42 |
| lool | elopio: python3 -m unittest -b integration_tests.test_parser is passing for me now, sorry; it failed a couple of times even when rerunning manually | 14:44 |
| lool | perhaps wiki issue or something | 14:44 |
| camako | I think snappy-playpen CI is having infrastructure issues ("No CMAKE_C_COMPILER could be found") on more than one PRs. Does anyone know why it's failing? Is there anyway to re-kick it (without updating the branch)? | 14:44 |
| lool | elopio: ah I know what's going on | 14:46 |
| lool | elopio: install: error writing '/tmp/tmpe3p0e0r9/simple-rust/parts/simple-rust/rust/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc | 14:46 |
| lool | _llvm-39b92f95.so': No space left on device | 14:46 |
| lool | elopio: /tmp is in memory, the vm has 2G and that's apparently not enough | 14:46 |
| josepht | cpaelzer: it looks like it's because your part is named 'waf-project' in your snapcraft.yaml and 'wafdemo' in the wiki. The wiki entry needs to use the part name, not the project name. | 14:47 |
| arges | mvo: not sure what you mean exactly | 14:48 |
| elopio | lool: oh, that makes sense. The tests use tmp a lot, the real build doesn't. | 14:48 |
| lool | elopio: yeah | 14:48 |
| mup | PR snapcraft#764 opened: add support for snap-build grade parameter in snapcraft.yaml <Created by caio1982> <Conflict> <https://github.com/snapcore/snapcraft/pull/764> | 14:48 |
| lool | elopio: this also explains why it transients (running other things took memory / disk space) | 14:49 |
| lool | *was | 14:49 |
| mvo | arges: sorry, if you don't know about command-not-found that is fine, it was in a google doc and I was referenced | 14:49 |
| mvo | arges: I will find out, I thought the context was kernel stuff | 14:49 |
| mvo | arges: in any case 2.13 should be good to go | 14:49 |
| arges | mvo: i see it now, it was to ensure /snap/bin is in $PATH, that should probably be filed as a bug if it isn't already | 14:50 |
| josepht | cpaelzer: fyi, the wiki is processed once an hour. | 14:50 |
| lool | Error: Node Sass does not yet support your current environment: Linux Unsupported architecture (arm) with Node.js 4.x | 14:50 |
| lool | damn it | 14:50 |
| arges | mvo: and shouldn't block 2.13 regardless so I'm happy to release if there aren't any other issues | 14:50 |
| elopio | josepht: shouldn't that print a warning on parse? | 14:50 |
| mvo | arges: cool, no other issues | 14:51 |
| cpaelzer | josepht: thanks a lot, trying that then | 14:51 |
| josepht | elopio: yes, I'll update the bug so we can fix that | 14:51 |
| mvo | arges: we pushed a fix for /snap/bin, let me search for the bug reference, one sec | 14:51 |
| josepht | cpaelzer: I already updated the wiki | 14:51 |
| mvo | arges: https://launchpad.net/ubuntu/+source/sudo/1.8.16-0ubuntu1.2 | 14:51 |
| arges | mvo: awesome thanks | 14:52 |
| elopio | josepht: thank you. | 14:52 |
| ogra_ | mvo, any idea when this will land ? that must sit in -propsed since a month now | 14:53 |
| ogra_ | ah, well, 11 days ... my sense of time seems to be off :P | 14:54 |
| mvo | ogra_: someone *cough* needs to do the verification, could be anone expect me (as I uploaded it) | 14:56 |
| mvo | ogra_: help appreciated :) | 14:56 |
| ogra_ | on it | 14:56 |
| mvo | \o/ | 14:57 |
| mvo | I'm sure arges will let it in once its verified | 14:57 |
| arges | which package? | 14:57 |
| mup | Bug #1618085 opened: snap run fails to run, cannot find app "me" in "me" <Snappy:New> <https://launchpad.net/bugs/1618085> | 14:57 |
| ogra_ | done | 14:58 |
| mvo | arges: sudo itself | 14:58 |
| ogra_ | that wasnt actually hard :) | 14:58 |
| mvo | arges: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1595558 | 14:58 |
| mup | Bug #1595558: sudo doesn't have /snap/bin in PATH <verification-done> <snapd (Ubuntu):Won't Fix> <sudo (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Won't Fix> <sudo (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1595558> | 14:59 |
| mvo | ogra_: :) | 14:59 |
| ogra_ | mvo, what about shadow ? we still have it sitting in the PPA | 14:59 |
| ogra_ | did you plan to push the fixes to debian ? | 14:59 |
| mvo | ogra_: thats the --extrausers fixes? | 15:00 |
| ogra_ | yeah | 15:00 |
| ogra_ | i cant remember if sergiusens pushed the former changes to debian or if we did a distro patch for that | 15:00 |
| mvo | ogra_: I don't remember :/ I think I did send some patches some time ago and vaguely remember them sitting in the bts forever, but I may be wrong | 15:00 |
| ogra_ | we should get the PPA empty for RTM ... or at least between RTM and GA | 15:00 |
| ogra_ | so that we dont release any ubuntu-core into stable that cant be built from the archhive | 15:01 |
| ogra_ | (/me has already worked a bit on the cleanup, but there is still a lot to do) | 15:02 |
| === jcastro_ is now known as jcastro | ||
| mup | Bug #1618095 opened: [SRU] 2.0.14 <Snappy:New> <https://launchpad.net/bugs/1618095> | 15:06 |
| zyga | slangasek: around? | 15:09 |
| ogra_ | sergiusens, bug 1618019 seems like an easy fix | 15:09 |
| mup | Bug #1618019: builds of "type: kernel" add obsolete options to snap.yaml <Snapcraft:New> <https://launchpad.net/bugs/1618019> | 15:09 |
| ogra_ | (or kyrofa ^^) | 15:16 |
| kyrofa | ogra_, why are those keys no longer required? | 15:18 |
| ogra_ | kyrofa, because the kernel snap now is defined ... bits need to sit in the right paths inside it so you dont need any meta info anymore | 15:19 |
| kyrofa | ogra_, "don't need" and "fail review because" seem slightly different. Everything is always so out of sync :( | 15:19 |
| ogra_ | kyrofa, i cant find the link to the final kernel.yaml doc anymore (as usual with gdoc ...) but all options except "type: kernel" and "version:" are gone | 15:20 |
| ogra_ | the snapcraft.yaml can indeed still use them for the kernel plugin ... but the snap.yaml should not have any of these anymore since the content is in pre-defined paths now | 15:21 |
| ogra_ | s/is in/has to be in/ | 15:21 |
| kyrofa | ogra_, isn't that the stuff that was just recently finalized? | 15:21 |
| ogra_ | (and dont blame me, i didnt define the kernel yaml :P ) | 15:21 |
| ogra_ | afaik it was finalized in heidelberd | 15:22 |
| ogra_ | *heidelberg | 15:22 |
| kyrofa | Oh I don't blame you, but I'd like to start doing this stuff with cross-project bugs instead of each project changing independently and making the others sprint to catch up | 15:22 |
| ogra_ | kyrofa, see pm | 15:23 |
| sergiusens | ogra_ there is a really old card for extra users where mvo was supposed to add it to debian | 15:26 |
| mvo | I think I did | 15:26 |
| sergiusens | kyrofa ogra_ wrt kernel plugin, I asked for the spec on Wednesday, didn't get it | 15:26 |
| * sergiusens is being short on words as he has a feverish kid up in arms | 15:26 | |
| ogra_ | sergiusens, there is a gdoc from heidelberg that defines that only type and version are needed in snap.yaml | 15:27 |
| ogra_ | the rest is defined via pre-defined paths the binary stuff needs to be | 15:27 |
| sergiusens | ogra_ link it to the bug please so I can check if everything required is being done | 15:28 |
| sergiusens | ogra_ does this include the init chainloading? | 15:28 |
| kyrofa | sergiusens, huh, mine has a fever this morning too | 15:28 |
| ogra_ | sergiusens, chainloading ? | 15:28 |
| sergiusens | ogra_ initrd from os and kernel snap | 15:28 |
| sergiusens | chainloading, munging, aggregation, ... whatever it is called | 15:29 |
| ogra_ | sergiusens, not defined anywhere ... but also not relevant | 15:29 |
| ogra_ | there will be an initrd in the kernel snap ... that wont change | 15:29 |
| sergiusens | ok, just wondering if I can kill the logic that downloads the kernel snap | 15:29 |
| ogra_ | the changes are in gadget then | 15:29 |
| sergiusens | the os snap | 15:29 |
| ogra_ | ah, not yet | 15:29 |
| ogra_ | i'll ping you ... | 15:29 |
| ogra_ | but thats for between RTM and GA | 15:30 |
| ogra_ | the logic will sit in the bootloader scripts and in the initrd build scripts ... neither needs anything from the kernel snap or from snapcraft atm | 15:31 |
| ogra_ | sergiusens, doc link added to the bug | 15:37 |
| mup | PR snapcraft#756 closed: Use block style for multiline YAML values <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/756> | 16:00 |
| === chihchun is now known as chihchun_afk | ||
| stokachu | is the lxd interface auto connect? | 16:07 |
| eldarkg | kyrofa: hello | 16:12 |
| kyrofa | eldarkg, hey, welcome! | 16:12 |
| eldarkg | kyrofa: I was talking with about kicad-snap | 16:13 |
| cmars | that new snapd 2.13 release.. does that enable snaps to be installed in a lxd container? | 16:14 |
| kyrofa | eldarkg, so I dug into this issue a bit, but not quite as much as I would have liked. It does actually seem to find your lib, but when it comes time to link it can't find the lib. I suspect the Findngspice.cmake is looking in an odd place | 16:14 |
| kyrofa | Rather, it seems to find the includes, but not the lib | 16:14 |
| kyrofa | eldarkg, but my lack of familiarity with the project started to get in the way at that point | 16:14 |
| eldarkg | kyrofa: mmm | 16:15 |
| la_juyis` | hi, question. i have an app installed as a deb in my system. I built a snap, installed it, but when I call the app by the name it still calls the deb in /usr/bin - in this case to try if the snap runs ok I should call it by the /snap/ bin, right? | 16:15 |
| eldarkg | kyrofa: Is it bug of Findngspice.cmake script? | 16:15 |
| kyrofa | eldarkg, maybe, but I'm not sure. It requires some digging into it, the time for which I'm afraid I don't have right now. I'd definitely start there with further investigation, though | 16:16 |
| kyrofa | la_juyis`, yeah, /snap/bin comes later in the path | 16:17 |
| la_juyis` | kyrofa roger, thanks! | 16:17 |
| eldarkg | kyrofa: ok. how I can to simulate LP building on my PC? | 16:18 |
| kyrofa | eldarkg, I'd fire up a clean container for it (I use lxc) | 16:19 |
| eldarkg | kyrofa: thank you. I'll try digging | 16:20 |
| mup | PR snapd#1778 opened: daemon: make socket split backward-compatible <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1778> | 16:20 |
| stub | Where does my daemon send its logs? Or do I need to log to $SNAP_COMMON or similar and handle log rotation myself? | 16:33 |
| eldarkg | stub: check cat /var/log/syslog | 16:38 |
| eldarkg | stub: good tail -f /var/log/syslog | 16:38 |
| stub | eldarkg: I mean where should it send its logs. I guess I could dump them all to syslog and let the operator work it out from there. | 16:39 |
| eldarkg | stub: sorry I'm new | 16:40 |
| stub | I'm at the point I'm dealing with the rough edges. Currently also trying to figure out locale handling. I only seem to have the C locale available. | 16:42 |
| eldarkg | stub: Look at my try to work with i18n https://github.com/eldarkg/kicad-snap/blob/master/kicad.wrapper#L10 | 16:43 |
| stub | eldarkg: I see. So you are generating the locales yourself, rather than relying on locales-all or something to have then embedded in the snap. | 16:46 |
| eldarkg | stub: I found only this solve maybe exist the right one | 16:48 |
| eldarkg | stub: ping me if you find the right way | 16:48 |
| derjasper | What is the state of Ubuntu Snappi on the Raspberry Pi 3 ? Is there a development or inofficial build available? | 16:57 |
| mup | PR snapd#1669 closed: interface: add usb device support to serial-port <Blocked> <Critical> <Created by jocave> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1669> | 17:00 |
| ogra_ | derjasper, http://people.canonical.com/~ogra/snappy/all-snaps/ | 17:02 |
| ogra_ | arges, do you plan to do raspi2 and dragonboard kernel SRUs too today ? | 17:03 |
| ogra_ | (just asking because i need to make the snap packages pick that up then) | 17:04 |
| elopio | nessita: I've just requested a reserved name, cf. Can you please approve it? | 17:04 |
| derjasper | Thanks! Is this already 64 bit? And does it receive updates? | 17:04 |
| mup | PR snapd#1696 closed: interfaces: add hidraw-device interface <Blocked> <Critical> <Created by jocave> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1696> | 17:04 |
| ogra_ | derjasper, no, not 64bit (and i'm not sure we'll do 64bit before the pi foundation doesnt announce all firmware blobs are ready for that) | 17:06 |
| ogra_ | but it receives updates indeed | 17:06 |
| derjasper | thanks! | 17:07 |
| ogra_ | (nopte also that binaries for 64bit eat about 2/3 extra ram, they are a lot bigger) | 17:07 |
| stub | eldarkg: It seems to be working if I have locales-all in my stage-packages, and set the LOCPATH environment variable to $SNAP/usr/lib/locale | 17:07 |
| stub | eldarkg: I need all locales available (the user can choose at runtime), so this might not be appropriate for your use case | 17:08 |
| eldarkg | stub: thank you | 17:09 |
| ogra_ | ubuntu@pi3:~$ ps ax -o rss,cmd |grep snapd | 17:10 |
| ogra_ | 12864 /usr/lib/snapd/snapd | 17:10 |
| ogra_ | ubuntu@dragonboard:~$ ps ax -o rss,cmd |grep snapd | 17:10 |
| ogra_ | 27248 /usr/lib/snapd/snapd | 17:10 |
| ogra_ | derjasper, ^^^ | 17:10 |
| ogra_ | same binary from the same source ... | 17:10 |
| ogra_ | (teh pi3 is armhf ... the dragonboard is arm64) | 17:10 |
| alextn | Hello all. I've been working with Snappy Core on the Samsung ARTIK 10 and I was wondering if the "gadget snap" or anything that I might use to produce a custom image is available. | 17:11 |
| ogra_ | the only real advantage you get with arm64 is on systems with a lot of ram | 17:11 |
| ogra_ | which the pi3 really isnt | 17:11 |
| derjasper | okay, didn't thought about that ^^ | 17:13 |
| ogra_ | :) | 17:13 |
| tbr | as if ARMv7 couldn't do LPAE... | 17:14 |
| mup | PR snapcraft#757 closed: Export important project variables <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/757> | 17:15 |
| ogra_ | tbr, does LPAE help gimp to use a 64bit address space ? :) | 17:18 |
| tbr | sure, if you want to run Chrome or Firefox with more than two tabs or anything else, you'll need 64bit address space :) | 17:24 |
| ogra_ | heh, well ... | 17:24 |
| alextn | What if you want to virtualize something... ARMv8.x is better for virtualization.. | 17:26 |
| ogra_ | what i meant is that the larger 64bit binaries can actually have a benefit ... but that will only make sense if their functions can actually also address 64bit blocks and have enough ram for that | 17:26 |
| arges | ogra_: re: rpi/snapdragon kernels that's something ppisati handles | 17:27 |
| ogra_ | but yeah, in general armhf is the better choice and LPAE will allow you to use more than 3GB | 17:27 |
| ogra_ | arges, i have no idea, i only noticed you spammed my changes mailboxes everywhere with these other kernels (new pc-kernel snap with your SRU is already in the store btw) :) | 17:28 |
| arges | ogra_: yup its kernel release day today | 17:28 |
| ogra_ | and i try to be fast with the snaps when an ABI bump happens | 17:28 |
| ogra_ | (i'll soon automate that so a script can notice a new meta in -updates/-security and it re-builds teh snap automatically) | 17:29 |
| ogra_ | (maintenance free = win :) ) | 17:30 |
| jdstrand | roadmr: hey, can you pull r726? | 17:39 |
| nessita | elopio, hi! so transfering a snap name is not trivial, and will not be for some time until that is scheduled and added to our roadmap. We usually recommend to not take the upstream names and use suffixes like cf-elopio. Have you consider that? | 17:46 |
| elopio | nessita: yes, but then less people will install it and it will get worse stats. My hope is that by the time upstream is ready to take ownership, all the issues in the transfer would be solved. | 17:48 |
| elopio | 3 months from now maybe? | 17:48 |
| nessita | elopio, ok, I will try to have it approved by EOD today (need to confirm a few things first). Is that ok? | 17:49 |
| elopio | nessita: yes it is. Thank you :) | 17:52 |
| jdstrand | ogra_: hey, I see a bunch of kernels in the store. do you have an updated list of kernel and gadget snaps that should not be blocked? | 17:59 |
| ogra_ | jdstrand, heh, nothing changed, no ... all kernels we use auto-land fine | 18:01 |
| jdstrand | maybe these are old names | 18:01 |
| jdstrand | one has canonical-* at the beginning | 18:01 |
| ogra_ | they likely are ... i wish i could delete packages | 18:01 |
| ogra_ | yeah, thats alll dead beef | 18:01 |
| ogra_ | only pc-kernel, pi2-kernel and dragonboard-kernel are relevant ... | 18:02 |
| ogra_ | the rest is old cruft | 18:02 |
| ogra_ | (and these three are fine) | 18:02 |
| jdstrand | ok, those are the ones I have | 18:02 |
| jdstrand | ogra_: is there a list of gadget snaps? | 18:02 |
| ogra_ | pc, pi2, pi3 and dragonboard | 18:03 |
| ogra_ | but we are updating them rarely enough that manual approval is fine | 18:04 |
| ogra_ | especially since it is always a manual process ... we dont have any snapcraft integration for our gadgets yet | 18:04 |
| jdstrand | ogra_: ok, thank you | 18:08 |
| jdstrand | roadmr: if you are so inclined, r728 instead (whitelists a few gadget snaps). if you already pulled r726, it can wait | 18:10 |
| roadmr | jdstrand: will do. I'd just pulled r721 :) | 18:32 |
| wililupy | is there an example of how to use the dump plugin? Not urgent since copy is still working, but would like to learn it. ;) | 18:32 |
| roadmr | jdstrand: (but not deployed yet, so it's a good time) | 18:32 |
| jdstrand | great, thanks! | 18:32 |
| mup | PR snapcraft#765 opened: Use a recursive iglob for filesets <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/765> | 18:33 |
| mup | PR snapcraft#754 closed: Use in plugin code to remove unwanted files <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/754> | 18:36 |
| dobey | how does one start the snapd service inside an lxc container? | 18:59 |
| dobey | error: daemon does not handle 0 listeners right now, just one | 18:59 |
| dobey | ^^ i get this if i try to just run "sudo /usr/lib/snapd/snapd" | 19:00 |
| dobey | and i can't seem to use systemctl | 19:00 |
| sergiusens | dobey it doesn't work in a container; there are bugs that I don't have handy related to the kernel/apparmor that the security team is working on for this | 19:08 |
| sergiusens | I think it was jjohansen | 19:08 |
| dobey | sergiusens: oh right. is there no way to run it completely unconfined? | 19:11 |
| sergiusens | dobey the container itself? Maybe with profiles and such, but that is outside my area of expertise | 19:12 |
| dobey | sergiusens: snapd | 19:14 |
| dobey | hrmm, maybe i can just bind mount /run/snapd.socket instead | 19:15 |
| dobey | err, i guess not because /run is tmpfs | 19:17 |
| jjohansen | sergiusens: can you try the xenial proposed kernel? Ubuntu-4.4.0-37.56 has more than a dozen apparmor fixes in it | 19:32 |
| sergiusens | jjohansen that would be for dobey ^ | 19:33 |
| dobey | installed in host or container? | 19:34 |
| kyrofa | dobey, container uses host, no? | 19:35 |
| dobey | kyrofa: well, the running kernel is on the host of course, but the container doesn't necessarily use other files from the host | 19:39 |
| === aisrael is now known as StoneTable | ||
| dobey | if i could just bind mount the socket though, that'd be best | 19:39 |
| jjohansen | dobey: host | 19:48 |
| === StoneTable is now known as aisrael | ||
| kgunn | stgraber: hey there, i discovered this means "image not found" ...but shouldn;t there be an arm64 xenial image? | 20:03 |
| kgunn | kg@kg-MacBookPro:~$ sudo lxc launch images:ubuntu/xenial/aarch64 xen-arm64 | 20:03 |
| kgunn | error: not found (not a fingerprint, partial fingerprint (first 12 chars) or valid alias) | 20:03 |
| kgunn | or am i doing it wrong? | 20:04 |
| ogra_ | kgunn, as a fallback (if you cant get lxc to work) https://github.com/snapcore/classic-snap ... | 20:06 |
| kgunn | ogra_: :-P | 20:06 |
| ogra_ | :) | 20:06 |
| kgunn | how do you know i want to cross compile ? | 20:07 |
| ogra_ | mindwaves ;) | 20:07 |
| kgunn | lol | 20:07 |
| stgraber | kgunn: lxc launch images:ubuntu/xenial/arm64 | 20:08 |
| stgraber | kgunn: though based on your hostname, that's not going to work as it will only run on an arm64 system | 20:08 |
| === drizztbsd is now known as timothy | ||
| dobey | why can't i bind mount anything in tmp/ or run/ in an lxc any more? :( | 20:18 |
| mup | PR snapd#1779 opened: miscellaneous policy updates: <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1779> | 21:02 |
| tvoss | jdstrand: o/ | 21:10 |
| jdstrand | hey tvoss :) | 21:11 |
| mup | PR snapd#1778 closed: daemon: make socket split backward-compatible <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1778> | 21:11 |
| tvoss | jdstrand: would you find a few to review the very recent locationd upload? | 21:11 |
| jdstrand | tvoss: sure-- though I did approve a bunch earlier today | 21:11 |
| jdstrand | I see you uploaded a few more | 21:12 |
| tvoss | jdstrand: yup, thanks for that -- I had to correct a minor issue for two of the commands | 21:12 |
| jdstrand | tvoss: ok done | 21:15 |
| tvoss | jdstrand: ack and thx | 21:15 |
| mup | PR snapcraft#766 opened: Better file conflict message <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/766> | 21:18 |
| jcastro | What would cause this error: error: cannot communicate with server: Post http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused | 21:21 |
| tvoss | jcastro: running in container or chroot? | 21:21 |
| jcastro | no, normal xenial desktop | 21:22 |
| jcastro | I did a refresh to ubuntu-core --edge earlier today, but that wouldn't be related I think? | 21:22 |
| tvoss | wouldn't think so, I usually ran into the issue in a chroot or container | 21:23 |
| tvoss | nessita: o/ I'm running into a publishing problem with locationd. packages are auto-uploaded from launchpad, and even after review, there does not seem to be a way to publish the new packages except for unpublishing/publishing. Wondering if I'm missing something | 21:31 |
| jdstrand | jcastro: sabdfl mentioned a bug in edge's core snap | 21:31 |
| jdstrand | jcastro: I think SNAP_REEXEC=0 in /etc/environment was the workaround | 21:31 |
| jdstrand | yes | 21:32 |
| jdstrand | https://lists.ubuntu.com/archives/snapcraft/2016-August/000862.html | 21:32 |
| jdstrand | jcastro: ^ | 21:33 |
| kyrofa | jdstrand, jcastro should be fixed with today's daily build, whenever that happens | 21:34 |
| jcastro | ah thanks for that guys, missed that post | 21:34 |
| nessita | elopio, cf name approved! | 21:36 |
| nessita | tvoss, checking | 21:36 |
| elopio | nessita: :) thanks! | 21:36 |
| nessita | tvoss, if you go to a revision page, like https://myapps.developer.ubuntu.com/dev/click-apps/5666/rev/11/, scroll down to the bottom | 21:37 |
| nessita | tvoss, there is a "Publish" button which is per revision | 21:37 |
| nessita | tvoss, the one at the top is "package wide", the one at the bottom is "per revision" (yes, we have a bug to improve the UX there_ | 21:38 |
| nessita | ) | 21:38 |
| tvoss | nessita: ack, let me see | 21:47 |
| mup | Bug #1618239 opened: console-conf uses 20+MB memory at rest on embedded systems <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1618239> | 22:16 |
| ahoneybun | popey: it built now! | 22:56 |
| ahoneybun | \o/ | 22:56 |
| popey | ahoneybun: yay | 23:10 |
| ahoneybun | thanks to you lol | 23:12 |
| popey | np | 23:14 |
| popey | glad i could help | 23:14 |
| popey | it's way more fun when stuff works :) | 23:14 |
| ahoneybun | it is lol | 23:15 |
| ahoneybun | can LP builds run like Travis CI? | 23:15 |
| ahoneybun | auto refreshing the page | 23:15 |
| popey | lp can build snaps | 23:16 |
| popey | and autobuild too | 23:16 |
| ahoneybun | no | 23:46 |
| ahoneybun | the way Travis auto loads the new state of the build | 23:46 |
| ahoneybun | showing the progress without a refresh of the page like LP does | 23:47 |
| ahoneybun | or needs | 23:47 |
| mup | PR snapcraft#764 closed: Implementing 'grade' support in snapcraft.yaml <Created by caio1982> <Closed by caio1982> <https://github.com/snapcore/snapcraft/pull/764> | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!