| stgraber | jdstrand: I guess it's fine. I can't really test this until we get the snap moved though :) | 01:40 |
|---|---|---|
| mup | Bug #1615566 changed: snapcraft SDK <Snappy:Invalid> <https://launchpad.net/bugs/1615566> | 02:03 |
| mup | Bug #1615030 changed: Ability to completely remove a snap from the snap store <Snappy:Invalid> <Software Center Agent:Confirmed> <https://launchpad.net/bugs/1615030> | 02:21 |
| mup | Bug #1612909 opened: Unable to install snappy in Fedora <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1612909> | 03:13 |
| === chihchun_afk is now known as chihchun | ||
| === BlueT is now known as BlueT_Lien | ||
| zyga | o/ | 08:12 |
| === ant_ is now known as Guest15611 | ||
| zyga | mwhudson: hey, can you tell me what is your workflow for snap-confine in debian | 08:20 |
| zyga | mwhudson: I have the repo from alioth, I see some work towards 1.0.40 | 08:21 |
| zyga | mwhudson: I'd like to finish that and release it to sid and yakkety | 08:21 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| zyga | jdstrand: dh-apparmor is not in main, yet snap-confine build-depends on it | 09:16 |
| zyga | jdstrand: somehow it never caused issues but isn't this against the policy/ | 09:16 |
| zyga | niemeyer: latest spread (from a snap) gives me this output: 2016/08/23 11:36:40 Allocating &{linode ubuntu-16.04-64-grub ubuntu-16.04-64-grub %!s(int=1) %!s(*spread.Environment=&{<nil> [] map[]}) []}... | 09:37 |
| zyga | niemeyer: similarly the output is very wrong after that | 09:38 |
| autonomouse | Hi folks. General question: I've got a simple one file python2 script that I'd like to snap. I have my snapcraft.yaml in the same folder. was hoping that I'd just be able to do this?: http://paste.ubuntu.com/23080902/ but it doesn't seem to be able to find it in the scripts directory: "[Errno 2] No such file or directory: .../prime/scripts/script.py". Do I need a makefile? | 10:02 |
| mup | Bug #1616006 opened: clean remove of snapd <Snappy:New> <https://launchpad.net/bugs/1616006> | 10:04 |
| zyga | autonomouse: you need setuptools support AFAIK | 10:08 |
| autonomouse | zyga, ok, I'll look into that now. thanks | 10:09 |
| ogra | mvo, urgh ... i guess we didnt update the pi3 gadget along ... http://paste.ubuntu.com/23081105/ | 10:18 |
| lool | davidcalle: heya | 10:18 |
| lool | davidcalle: do we have online references on building kernel snaps? e.g. on snapcraft.io | 10:18 |
| heart | Hello everyone, I do not know if this is the right place to ask. Are there restrictions in running a docker container that needs to access a serial port? I do not know, permits or other? In docker normally just expose the device with --device | 10:19 |
| lool | davidcalle: if not, I have seen various base materials fly around that would be good starting points for a kernel page | 10:19 |
| lool | ysionneau: what was your issue with docker? | 10:20 |
| lool | heart: privileged containers are required for this; it migth work, if it doesn't I'd be interested in the error you're gettig | 10:21 |
| lool | heart: note however that this is basically giving root to anything running in that container | 10:21 |
| mvo | ogra: indeed, looks like this is missing | 10:22 |
| ogra | yeah, just comitted and pushed | 10:22 |
| heart | lool: naturally, I think I have some problem even with privileged mode. I continue to investigate and let you know | 10:22 |
| heart | lool: I'm working with a dell edge gateway | 10:24 |
| ogra | mvo, https://myapps.developer.ubuntu.com/dev/click-apps/5596/rev/2/ ... please approve | 10:25 |
| mvo | ogra: done | 10:28 |
| ogra | thx | 10:28 |
| === hikiko is now known as hikiko|ln | ||
| mup | PR snapd#1721 opened: dependencies: update godeps <Created by mvo5> <https://github.com/snapcore/snapd/pull/1721> | 10:43 |
| ogra | mvo, hmm ... http://paste.ubuntu.com/23081147/ | 10:45 |
| mvo | ogra: hm, no netwokring? | 10:46 |
| ogra | (pi3 with the snappy_boot script chaNGES IN TEH GADGET) | 10:46 |
| ogra | EEK | 10:46 |
| mvo | ogra: ha! CAPSLOCK | 10:46 |
| ogra | geez, i need to rip off that caps key | 10:46 |
| mvo | ogra: I remapped mine - ctrl:nocaps | 10:46 |
| ogra | mvo, deliberately since the pi3 now has wlan support | 10:46 |
| ogra | so the cable is unplugged | 10:46 |
| mvo | ogra: oh, this may be a general image bug | 10:46 |
| ogra | butu before it actually told me that the networking job is waiting | 10:47 |
| ogra | mvo, well, i actually think its a systemd bug (or at least the systemd network bringup part) that it does not sense if a cable is plugged in | 10:47 |
| ogra | pitti, ^^^ | 10:47 |
| ogra | (and it is now about 2years old too ... ) | 10:48 |
| ogra | should not be hard to check for a connected cable really ... | 10:48 |
| mvo | ogra: hm, pi2 without network cable booted ok | 10:48 |
| ogra | i guess you need two NICs ? | 10:49 |
| mvo | ogra: possible, I can see if I find a wlan thing | 10:49 |
| ogra | i'll do a re-flash after my test runs | 10:49 |
| ogra | and will check if plugging it in actually makes a difference (the dragon only has wlan, the pi2 only eth) | 10:50 |
| ogra | sigh ... cloud-init still not finished | 10:50 |
| ogra | thats close to a 5 min firstboot now :/ | 10:50 |
| ogra | ah, now i have the prompt | 10:51 |
| ogra | ubuntu@localhost:~$ cat /etc/network/interfaces.d/enxb827ebc92b03 | 10:51 |
| ogra | allow-hotplug enxb827ebc92b03 | 10:51 |
| ogra | iface enxb827ebc92b03 inet dhcp | 10:51 |
| ogra | ubuntu@localhost:~$ | 10:51 |
| ogra | aha | 10:51 |
| ogra | sdo it created a config for the wired NIC ... regardless if it is in use | 10:52 |
| ogra | (and i remeber we had an additional option in there to wotrk around that bug in 15.04 ) | 10:53 |
| ogra | mvo, hmm, funny, it doesnt hang on the second boot | 10:57 |
| ogra | so it is the combo of firstboot and the allow-hotplug line | 10:57 |
| mvo | ogra: oh, I think I know | 10:57 |
| mvo | ogra: there is a race in the network bringup code | 10:57 |
| ogra | yay | 10:57 |
| ogra | :P | 10:57 |
| mvo | ogra: there is a fix in a PR :) | 10:58 |
| ogra | \o/ | 10:58 |
| mvo | ogra: I will extract it and push a separate pr, its currently part of a big brnach | 10:58 |
| ogra | ok | 10:59 |
| * ogra does a quick ubuntu-core armhf build to check the upgrade mechanism | 11:06 | |
| ogra | mvo, in snapweb, all installed snaps listed after the first boot are marked non-removable, *except* the kernel ... | 11:12 |
| ogra | i guess we dont want users to allow removing the only kernel that is installed ? | 11:12 |
| mvo | ogra: definitely not | 11:13 |
| ogra | is that info from snapd thats wrong or is it a snapweb bug | 11:13 |
| bull | guys see the design , https://github.com/keshavbhatt/snapcraft-gui | 11:13 |
| mvo | ogra: `$ sudo snap remove pi2-kernel | 11:13 |
| mvo | error: cannot remove "pi2-kernel": snap "pi2-kernel" is not removable | 11:13 |
| mvo | ` | 11:13 |
| pitti | ogra, mvo: ifupdown doesn't block boot on allow-hotplug, is that what's hanging? | 11:13 |
| mvo | ogra: so that won't work | 11:13 |
| mvo | ogra: snapweb is buggy | 11:13 |
| pitti | anyway, too little information/context here -- please file a bug with the details if there is any | 11:13 |
| ogra | mvo, right, but it shouldnt even show me the "remove snaüp" button | 11:13 |
| ogra | pitti, seems to be the interaction with snappy firstboot ... still, why is systemd not checking the cable state and just ignore the interface ? | 11:14 |
| mvo | ogra: yes, bug | 11:14 |
| ogra | mvo, right, where ? :) | 11:15 |
| * ogra wants to file it | 11:15 | |
| ogra | is it snapd giving wrong info or is it snapweb not respecting it | 11:15 |
| pitti | ogra: what are you using? ifupdown or networkd? | 11:16 |
| ogra | pitti, ifupdown obviously | 11:16 |
| pitti | ifupdown support for hotplugging/cable state is quite bolted on, but it works in general, so again -> bug | 11:16 |
| pitti | ogra: "obviously" → not really any more :) | 11:17 |
| ogra | (i'm not sure what creates the /e/n/i entry though ... that might be snapd) | 11:17 |
| ogra | pitti, obviously because we have an /e/n/i file after first boot :) | 11:17 |
| ogra | for the NIC | 11:17 |
| mup | PR snapd#1721 closed: dependencies: update godeps <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1721> | 11:17 |
| mup | PR snapd#1715 closed: asserts,overlord/devicestate: simplify private key/key pairs APIs, they take just key ids <Critical> <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1715> | 11:18 |
| bull | mhall119, https://github.com/keshavbhatt/snapcraft-gui | 11:19 |
| === hikiko|ln is now known as hikiko | ||
| mup | PR snapd#1722 opened: many: support install and remove by revision <Created by chipaca> <https://github.com/snapcore/snapd/pull/1722> | 11:32 |
| davidcalle | bull: very cool! | 11:43 |
| bull | davidcalle, ty did you compiled it ?? | 11:45 |
| davidcalle | bull: yes, runs just fine | 11:46 |
| bull | wow :D ty | 11:47 |
| jgdx | ogra, am I doing this the right way? e.g. bug 1616048 and bug 1616045 | 12:24 |
| mup | Bug #1616048: Create interface for ofono <snapd (Ubuntu):New> <https://launchpad.net/bugs/1616048> | 12:24 |
| mup | Bug #1616045: Create interface for the power daemon <snapd (Ubuntu):New> <https://launchpad.net/bugs/1616045> | 12:24 |
| jgdx | I look at snapd/interfaces/builtin and can't find it, then I search for a bug for it in the snapd package on launchpad. | 12:25 |
| ogra | jgdx, yeah, i belive that is right ... there is a tag you should set for interfaces | 12:25 |
| * ogra looks for it | 12:25 | |
| ogra | snapd-interface | 12:26 |
| ogra | set that too, then zyga and jdstrand see it on their lists | 12:26 |
| jgdx | ogra, cool, thanks. I think I'm going to create ~20 of these | 12:26 |
| ogra | :) | 12:27 |
| ysionneau | lool: any news about a build with the bug fix on snapweb for armhf? | 12:35 |
| lool | ysionneau: no, elopio has a solution to provide one, but I +1-ed his pull request yesterday after he EOD-ed | 12:36 |
| lool | ysionneau: he should be up soon; however the fix is merged in snapweb master if you want to rebuild | 12:36 |
| ogra | dooes that include a fix for bug 1610026 ? | 12:38 |
| mup | Bug #1610026: snapweb fails to start after reboot <snapweb:Confirmed> <https://launchpad.net/bugs/1610026> | 12:38 |
| morphis__ | jgdx: are you planing to work on the ofono interface for snapd? | 12:39 |
| jgdx | morphis__, no | 12:40 |
| morphis__ | jgdx: ok | 12:40 |
| ogra | hmm, do we have any example snap that uses a bzr branch in the "source:" option ? | 13:19 |
| sergiusens | ogra https://github.com/snapcore/snapcraft/blob/master/demos/libpipeline/snapcraft.yaml | 13:34 |
| ogra | sergiusens, ah, awesome, thanks ! | 13:36 |
| mup | PR snapcraft#749 closed: Allow registering private packages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/749> | 13:37 |
| lool | wililupy: I had asked for permission to comment/edit on https://docs.google.com/document/d/1mo_Xkg9yBotGRg4qMYYuVn1d35NwGLpCkxE3T_p85P8/edit?ts=57bc4e2f#heading=h.d2h64kdfycq but it seems it's not the latest one | 13:49 |
| lool | wililupy: FYI there were some "mlnx" references in the one you sent to Dell but I guess that's ok | 13:50 |
| lool | wililupy: there were a couple of things I wanted to suggest for simplification | 13:50 |
| lazyPower | ogra - i apologize, i checked my logs and dont have enough history. Can you re-link me to the latest RPI2 images for snappy? | 13:52 |
| lool | lazyPower: https://people.canonical.com/~mvo/all-snaps/16/ | 13:53 |
| lazyPower | s/snappy/ubuntu core/ | 13:53 |
| lazyPower | ah, ta lool | 13:53 |
| ogra | the fast frenchman ! | 13:55 |
| ogra | :) | 13:55 |
| === JanC is now known as Guest58470 | ||
| === JanC_ is now known as JanC | ||
| tyhicks | zyga (cc jdstrand): regarding dh-apparmor, only run time depends need to be in main now | 14:12 |
| tyhicks | zyga: the policy changed during the 16.04 dev cycle | 14:12 |
| ogra | WOAH ! | 14:19 |
| ogra | cjwatson, https://launchpadlibrarian.net/280537082/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz ... i have split the Makefile from the kernel snap branch into its own bzr tree, this is what i get when trying to build now | 14:19 |
| ogra | is that LP, the firwall or actually bzr (as it claims) | 14:20 |
| cjwatson | ogra: we talked about that bug before, I think; https://bugs.launchpad.net/snapcraft/+bug/1606203 | 14:21 |
| mup | Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:New> <https://launchpad.net/bugs/1606203> | 14:21 |
| ogra | oh, i remember .. the huge amount of output confused me | 14:21 |
| cjwatson | I analysed it at the time and was pretty sure it was a bzr bug, but I don't remember the precise chain of reasoning | 14:22 |
| ogra | hmm ... i could perhaps just switch to git, but i exactly wanted to avoid mixing bzr and git for the kernel snaps | 14:23 |
| ogra | kyrofa, sergiusens, ^^ any chance this could be quickly fixed in snapcraft (unsetting http_proxy for bzr source pull) ? | 14:27 |
| ogra | i guess a simple os.putenv('http_proxy'.'') would do ? | 14:36 |
| kgunn | sergiusens: mvo ever seen a bug like this? | 14:36 |
| kgunn | http://pastebin.ubuntu.com/23081827/ | 14:36 |
| kgunn | it says change in progress, but then no change listed? | 14:37 |
| ogra | or "del os.environ['http_proxy']" rather | 14:37 |
| mvo | kgunn: hm, what does "snap change 34" show? | 14:41 |
| mvo | kgunn: but definitely strange | 14:41 |
| kgunn | mvo: http://pastebin.ubuntu.com/23081849/ | 14:43 |
| kgunn | ...it's all ok actually | 14:43 |
| kgunn | now | 14:43 |
| ogra | you were just to impatient :) | 14:43 |
| kgunn | at least, it acted like it had not removed the pkg, but in reality it had | 14:43 |
| kgunn | no it timed out... | 14:44 |
| ogra | snapd works async (super annoying if you ask me) | 14:44 |
| kgunn | but it really was removed | 14:44 |
| jdstrand | mvo: hey, is https://github.com/snapcore/snapd/pull/1720#issuecomment-241602474 something you can help with or should I go to the store? | 14:57 |
| mup | PR snapd#1720: interfaces: add lxd-support interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1720> | 14:57 |
| kalikiana | kgunn: it looks like what I've seen when trying to remove snaps which were still running. I believe there's a bug for that. | 15:04 |
| kyrofa | kgunn, yeah I just recently ran into that as well | 15:07 |
| kyrofa | kgunn, I caused it by restarting services by hand instead of letting systemd do it | 15:07 |
| mup | PR snapd#1723 opened: image: prepare-image: import snap assertions as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/1723> | 15:08 |
| kgunn | kyrofa: i did admittedly kill a process | 15:08 |
| kyrofa | kgunn, which means when the snap was being removed, it asked systemd to stop everything and then tried to unmount, but my service was outside systemd | 15:08 |
| kyrofa | (so the mount was still in use) | 15:08 |
| mup | PR snapd#1724 opened: snap: add `snap download` implementation <Created by mvo5> <https://github.com/snapcore/snapd/pull/1724> | 15:09 |
| mup | PR snapd#1697 closed: interfaces/builtin: allow bind in the network interface <Created by tych0> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1697> | 15:27 |
| mup | PR snapcraft#740 closed: Allow debugging cleanbuild runs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/740> | 15:31 |
| mup | PR snapcraft#750 closed: storeapi: remove dependency on the 'success' attr <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/750> | 15:37 |
| kyrofa | jdstrand, I should be good to go as far as running snaps with an encrypted home is concerned nowadays, right? | 15:41 |
| jdstrand | kyrofa: yes. snap-confine is now in -updates | 15:42 |
| jdstrand | kyrofa: and it has the policy changes needed for that | 15:43 |
| jdstrand | kyrofa: were you seeing a problem? there was a weird ubuntu-image bug related to ecryptfs, but that is different than what you're asking about | 15:43 |
| kyrofa | jdstrand, no, I saw the bug and never bothered to try | 15:44 |
| jdstrand | ah | 15:45 |
| jdstrand | yes, it should all be fixed now | 15:45 |
| kyrofa | jdstrand, my background with bugs relating to ecryptfs is... bad. Last time it just got eaten | 15:45 |
| kyrofa | (the click chroot thing for the SDK) | 15:45 |
| jdstrand | hmm | 15:45 |
| jdstrand | eaten | 15:45 |
| jdstrand | well, if you are seeing issues with policy, feel free to talk to me. if it is misbehaving, you can talk to tyhicks | 15:45 |
| kyrofa | Sounds good, glad to know it should all be fixed now! | 15:46 |
| kyrofa | Thank you :) | 15:46 |
| tyhicks | the click chroot issues were systemd and schroot bugs | 15:48 |
| mup | PR snapd#1725 opened: overlord/hookstate: use snap run posix parameters <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1725> | 15:49 |
| tyhicks | I ended up fixing them because everyone kept calling them ecryptfs bugs but they were both years old schroot bugs that were never fixed | 15:51 |
| lool | jdstrand: heya, around? | 15:51 |
| kyrofa | tyhicks, heh | 15:51 |
| lool | jdstrand: couple of questions related to docker snap | 15:52 |
| === chihchun is now known as chihchun_afk | ||
| lool | jdstrand: currently it uses /var/run/docker.sock | 15:52 |
| joc_ | kyrofa: do you know if any of the snapcraft plugins copy the parts/<name>/src dir to the build dir? | 15:52 |
| lool | jdstrand: I find that problematic for 2 reasons | 15:52 |
| kyrofa | joc_, dump, I believe | 15:52 |
| lool | jdstrand: one is that it conflicts with the .deb, so you can't snap install on classic if you had the deb and vice-versa | 15:52 |
| lool | jdstrand: the other reason is that it kind of breaks the model where one could simply fork the docker snap and rename it, or embed it into another snap (e.g. snap containing docker runtime + docker images) as it's not relocatable anymore | 15:53 |
| lool | jdstrand: tianon suggested you wanted to keep the docker.sock name though | 15:53 |
| lool | I mean the /var/run pathname | 15:53 |
| joc_ | kyrofa: it makes the snapcraft help sources text a bit redundant, particualy for the source-subdir, as nothing seems to do what is described | 15:53 |
| * zyga votes +1 for $SNAP_DATA-based socket | 15:53 | |
| zyga | (and interface attrs and hooks) | 15:54 |
| lool | jdstrand: other question is: do you mind approving the docker 15.04 snap in the review queue? | 15:54 |
| lool | jdstrand: it adds the /home permissions you said were ok to add for 15.04 | 15:54 |
| joc_ | kyrofa: we were just investigating why a python3 part was failing and realised that attribute is ignored by the plugin but it's not mentioned anywhere | 15:54 |
| lool | zyga: yeah, I was thinking like a docker-socket bin to get the socket name for people that want to get it programatically | 15:54 |
| zyga | lool: that will be exposed with the snapctl tool I suspect | 15:55 |
| zyga | lool: you can use it to ask for an attribute easily | 15:55 |
| kyrofa | joc_, I'm not sure I understand where you're coming from, here | 15:56 |
| lool | zyga: so the docker snap would set an attribute and it could be queried? | 15:56 |
| lool | like config, but runtime? | 15:56 |
| zyga | yes | 15:56 |
| zyga | that's the hook a few people are working on | 15:56 |
| zyga | kyrofa, pstolowski | 15:56 |
| jdstrand | lool: I am | 15:56 |
| lool | yeah, that sounds like a good fit when that's avail | 15:56 |
| kyrofa | joc_, so you're having a problem with source-subdir? | 15:57 |
| jdstrand | lool: ideally I would like to see the socket in SNAP_DATA | 15:57 |
| joc_ | kyrofa: basically i'm saying there is a bug that the help text for the python3 plugin doesnt say the source-subdir will not have any effect | 15:57 |
| joc_ | kyrofa: but was also thinking there is bug with "snapcraft help sources" output because almost no plugins do what that says with respect to source-subdir | 15:58 |
| kyrofa | joc_, or just a bug in the python3 plugin. The code looks like it should work fine-- what do you see happening? | 15:58 |
| * kyrofa reads `snapcraft help sources` | 15:59 | |
| jdstrand | lool: renaming it in /run to be /run/snap.docker.sock or something would be ok too. I don't object to it being somewhere else-- I just wanted to make sure that it was understood that if it was moved that might break other tools that expect it in a particular location. if that is understood and people are ok with it, fine (also, there is nothing saying that if it was in SNAP_DATA now that we couldn't change it back) | 15:59 |
| joc_ | kyrofa: all the easy_install commands etc are run in the src dir | 15:59 |
| lool | jdstrand: it's certainly true that it will break existing constructs | 15:59 |
| kyrofa | joc_, yeah that's a bug in python3. Indeed, I agree that there's a bug in `help sources`, but it's because the source-subdir docs are wrong | 15:59 |
| lool | jdstrand: I'm not really sure how to avoid this and move the socket though | 16:00 |
| kyrofa | joc_, this is what SHOULD happen: | 16:00 |
| lool | unless we implement a complex mechanism in the .deb and in the snap to try to take the socket if it's unowned, but that seems broken too | 16:00 |
| lool | or just fail install | 16:00 |
| lool | BTW, most people install the docker .deb from docker inc which we can't change for this | 16:01 |
| zyga | lool: I' | 16:01 |
| jdstrand | lool: I think I heard on the list not to worry about conflicting with debs. that in the fullness of time snap install or something higher would guide the user in some manner | 16:01 |
| kyrofa | joc_, the entire `source` should be copied build, including the subdir. However, the subdir should be the working directory | 16:01 |
| zyga | lool: I've implemented something that lets us poke arbitrary holes as "quirks" for various snaps | 16:01 |
| jdstrand | lool: and that now users can just remove the deb | 16:01 |
| kyrofa | joc_, the docs are how things used to work, but then we realized that projects typically need the rest of the project tree | 16:01 |
| lool | jdstrand: fair enough | 16:01 |
| kyrofa | Looks like that never got updated, though | 16:02 |
| lool | jdstrand: I'll suggest adding an upstream flag so that people don't hardcode the pathname in docker run commands though | 16:02 |
| lool | something like --share-daemon or so | 16:02 |
| joc_ | kyrofa: yeah makes sense | 16:02 |
| jdstrand | cool | 16:02 |
| elopio | mvo: your rpi2 image from the 19th has been trying to boot for 5 minutes. Is that normal? | 16:04 |
| elopio | ah, it was snapweb failing to start. Just what manik said yesterday, probably. | 16:07 |
| * ogra sighs so unsetting http_proxy doesnt survive the selftest in snapcraft when building it :( | 16:09 | |
| ogra | why does the test even care :/ | 16:11 |
| elopio | ogra: tell me more. What do you mean with snapcraft selftest? | 16:11 |
| ogra | elopio, i need to move parts of the kernel snap build int a separate bzr branch ... which resulted in this beautiful error https://launchpadlibrarian.net/280537082/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz | 16:12 |
| ogra | which seems to be bug 1606203 | 16:12 |
| mup | Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:New> <https://launchpad.net/bugs/1606203> | 16:12 |
| ogra | elopio, so i tried a quick hack http://paste.ubuntu.com/23082327/ ... | 16:13 |
| ogra | which results in https://launchpadlibrarian.net/280550295/buildlog_ubuntu-xenial-amd64.snapcraft_2.15.1+ppa1_BUILDING.txt.gz | 16:14 |
| ogra | i dont really get why the bzr test in snapcraft would care about me deleting a (most likely non--existing) env var | 16:14 |
| elopio | ogra: ah, that's a test to make sure that the env var is deleted :) | 16:16 |
| ogra | elopio, not really, see the paste | 16:17 |
| ogra | ii dont touch the test code at all | 16:17 |
| ogra | i only del the var before calling pul | 16:17 |
| ogra | *pull | 16:17 |
| elopio | let me see... | 16:17 |
| ogra | its a super dumb patch | 16:18 |
| elopio | ogra: what the error is saying is that those attributes are not in os.environ. | 16:19 |
| ogra | perhaps i should use os.unsetenv() instead ... | 16:19 |
| ogra | elopio, yes, they indeed wont be unless a build happens in LP | 16:19 |
| ogra | (i mean a snapcraft build, not the build of the snapcraft package) | 16:19 |
| ogra | and i dont really want to set them, since that would actually taint the test | 16:20 |
| ogra | i would like it to just ignore it | 16:20 |
| elopio | ogra: why don't you do os.environ["HTTP_PROXY"] = "" | 16:21 |
| ogra | i can surely try that, do you think the test wont complain then ? | 16:22 |
| * ogra tries | 16:23 | |
| elopio | you will get a different result for sure. That's all I can say :) | 16:23 |
| ogra | lol | 16:23 |
| ogra | well, ppushed to the PPA, lets see | 16:23 |
| ogra | (one day all image bulds will actually work without me hacking up snapcraft ... ) | 16:24 |
| elopio | that would be nice. But this thing of removing the proxy env var from a plugin doesn't seem likely to get upstream. | 16:28 |
| kgunn | kyrofa: hey, got one you might have an idea on.... | 16:28 |
| ogra | elopio, well, it makes building bzr projects oon LP impossible | 16:28 |
| ogra | elopio, and a fix in bzr is very unlikely to happen | 16:29 |
| kgunn | so, i'm needing to run a script as part of my snapcraft step | 16:29 |
| kgunn | using something that will be in stage | 16:29 |
| kgunn | and then make sure the output of that goes into prime | 16:29 |
| elopio | ogra: but isn't that a launchpad problem? snapcraft should just use whatever env vars are set in the system. | 16:29 |
| ogra | elopio, no, it is a bzr bug | 16:30 |
| ogra | see bug 1606203 | 16:30 |
| mup | Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:New> <https://launchpad.net/bugs/1606203> | 16:30 |
| kgunn | kyrofa: so i want it to be a post-step to the first part | 16:30 |
| kgunn | isn't there a "gate on" | 16:30 |
| elopio | kgunn: after: [first-part] | 16:30 |
| kgunn | to make sure the script is in stage | 16:30 |
| kgunn | ah thanks elopio | 16:30 |
| kgunn | after... | 16:30 |
| kgunn | that's what i couldn't recall | 16:31 |
| * ogra hugs elopio ... the snapcraft package built with that change | 16:31 | |
| * ogra taps foot waiting for the PPA publisher so i can try if it actually fixes the kernel snap build | 16:31 | |
| elopio | 5^_^ | 16:32 |
| * elopio goes to swimming lessons. bbl. | 16:32 | |
| ogra | enjoy ! | 16:32 |
| tsimonq2 | ogra: it would be awesome to have a snap that is the Linux kernel | 16:32 |
| tsimonq2 | ogra: with all the different channels too! | 16:32 |
| ogra | tsimonq2, well, the kernel snap i build is far more then the linux kernel (it is more a "hardware enablement snap" ... | 16:33 |
| ogra | we just call it the kernel snap ... for our images | 16:33 |
| ogra | but the kernel team actually has plain linux snaps | 16:33 |
| ogra | talk to ppisati_ :) | 16:33 |
| tsimonq2 | ppisati_: are there kernel snaps I can try? :D | 16:34 |
| mup | PR snapd#1725 closed: overlord/hookstate: use snap run posix parameters <Created by kyrofa> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1725> | 16:41 |
| kyrofa | kgunn, in a meeting at the moment, but I'll take a look in a sec :) | 16:41 |
| zyga | Pharaoh_Atem: hey | 16:43 |
| sergiusens | ogra just use launchpad git | 16:48 |
| sergiusens | bzr is clearly unsupported | 16:48 |
| ogra | sergiusens, well, ut is still the quasi default ... | 16:48 |
| ogra | *it | 16:48 |
| sergiusens | ogra not for kernel stuff ;) | 16:49 |
| ogra | well, i dont do kernel stuff | 16:49 |
| ogra | i do build stuff :P | 16:50 |
| ogra | as a git hater i was surprised to easily find my way around in github ... but that is because for every prob i can find some howto or help doc ... | 16:51 |
| ogra | using LP git means i actually need to be familiar with git at a level i dont trst myself yet | 16:51 |
| ogra | sergiusens, so reading between your lines i guess you agree with elopio that there is no chance to fix bug 1606203 at all in snapcraft ? | 16:53 |
| ysionneau | lool: I was able to build snapweb ... but for amd64, I don't even know how to cross compile it for armhf | 16:53 |
| mup | Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Snapcraft:New> <https://launchpad.net/bugs/1606203> | 16:53 |
| ogra | s/fix/work around/ | 16:54 |
| ogra | (note that your argument works both ways ;) if bzr is dead anyway snapcraft could as well just ship a tivial hack for the workaround) | 16:57 |
| mup | PR snapd#1726 opened: store,tests: have just one envvar SNAPPY_USE_STAGING_STORE to control talking to staging <Created by pedronis> <https://github.com/snapcore/snapd/pull/1726> | 16:59 |
| sergiusens | ogra should be fixed in launchpad or bzr itself | 17:04 |
| ogra | sergiusens, well, neither will happen it seems | 17:04 |
| sergiusens | ogra so you default to bullying snapcraft? ;-) | 17:04 |
| ogra | "bullying" with a two line change, yeah | 17:04 |
| sergiusens | ogra you might as well just disable the proxy in bzr for that matter | 17:05 |
| sergiusens | I am already bitter that we need to do that preload thing to support the g* things, don't make me add more hacks :-) | 17:06 |
| ogra | g* things ? go you mean ? | 17:06 |
| * ogra watches https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/3413 ... | 17:07 | |
| mup | PR snapd#1727 opened: dirs,snap: define methods for SNAP_USER_DATA and SNAP_USER_COMMON <Created by zyga> <https://github.com/snapcore/snapd/pull/1727> | 17:08 |
| ogra | aaand it works \o/ | 17:08 |
| ogra | to bad you wont accept it :/ | 17:09 |
| kyrofa | kgunn, ah, sounds like elopio answered your question | 17:16 |
| kyrofa | kgunn, yeah, I'd do it with after and a Makefile or local plugin | 17:17 |
| === sarnold_ is now known as sarnold | ||
| mup | PR snapd#1728 opened: asserts: Add a key-proof assertion <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1728> | 17:28 |
| Pharaoh_Atem | zyga: hello | 17:37 |
| zyga | Pharaoh_Atem: hey, you pinged me earlier | 17:45 |
| === chihchun_afk is now known as chihchun | ||
| thresh | hello | 18:04 |
| Pharaoh_Atem | zyga: yep | 18:13 |
| Pharaoh_Atem | snapd doesn't seem to work on Fedora at all | 18:13 |
| Pharaoh_Atem | it's throwing errors about communicating to the store API | 18:13 |
| thresh | how do I set LD_LIBRARY_PATH for my snapped application? | 18:17 |
| thresh | I have a .so installed in a non-standard catalogue, and rpath was previously used to point to it. | 18:18 |
| zyga | Pharaoh_Atem: hmmm | 18:20 |
| zyga | Pharaoh_Atem: looking | 18:20 |
| zyga | Pharaoh_Atem: perhaps store is down or something | 18:20 |
| zyga | Pharaoh_Atem: I'm not patching anything related to that | 18:20 |
| Pharaoh_Atem | zyga: works on ubuntu | 18:20 |
| thresh | basically my .so's have: 0x000000000000000f (RPATH) Library rpath: [/lib/vlc] | 18:20 |
| * zyga tries | 18:20 | |
| thresh | which translates to something else under snap | 18:21 |
| zyga | thresh: just move it to /usr/lib in your snap | 18:21 |
| zyga | Pharaoh_Atem: trying with 2.12 from COPR | 18:21 |
| thresh | zyga, it's a private library, no need for it to be in /usr/lib/. | 18:21 |
| zyga | thresh: it's not in usr/lib of the system, just of your snap | 18:22 |
| thresh | zyga, I know, but that still applies | 18:22 |
| thresh | why clutter something? | 18:22 |
| ogra | why do you care | 18:22 |
| thresh | because I like tidy things | 18:22 |
| ogra | $SNAP/usr/lib is already private to your snap | 18:22 |
| ogra | and is automatically in your LD_LIBRARY_PATH when you exec your snap | 18:23 |
| thresh | also because it works under every other Linux distribution without issues, including Ubuntu, without moving it to /usr/lib | 18:23 |
| thresh | not sure why snap must be so different I need to include apparent hacks? | 18:23 |
| zyga | thresh: perhaps use ${ORIGIN} in your rpath | 18:23 |
| ogra | well, then write a wrapper, and hack up LD_LIBRARY_PATH | 18:23 |
| zyga | thresh: though AFAIR we strip rpath in snapcraft | 18:23 |
| zyga | thresh: though a hand-made snap will work | 18:23 |
| ogra | but i think just putting it in the snap owned usr/lib is a way sane move | 18:24 |
| sergiusens | or $SNAP/lib | 18:24 |
| zyga | hmm | 18:25 |
| zyga | Pharaoh_Atem: I see something odd, checking | 18:25 |
| zyga | Pharaoh_Atem: ah, no sorry, after starting and enabling the snapd.socket I can find snaps | 18:25 |
| zyga | Pharaoh_Atem: did you have anything specific that failed that I can try to reproduce? | 18:25 |
| Pharaoh_Atem | snap find . | 18:26 |
| zyga | trying | 18:26 |
| zyga | worked OK | 18:26 |
| zyga | Pharaoh_Atem: which version are you on? | 18:26 |
| zyga | Pharaoh_Atem: also what error do you see? | 18:26 |
| mup | PR snapcraft#705 closed: parser - Remove namespacing and subparts <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/705> | 18:28 |
| zyga | Pharaoh_Atem: unrelated, I have a new package for review | 18:30 |
| zyga | really small and simple too | 18:30 |
| Pharaoh_Atem | zyga: what is it? | 18:30 |
| zyga | the xdg-open thing | 18:30 |
| zyga | let me upload it for review | 18:30 |
| Pharaoh_Atem | snapd-xdg-open? | 18:30 |
| zyga | yep | 18:30 |
| zyga | I'll merge it into snapd later, I've started the work on mering snap-confine into snapd first, this is mostly a time thing for me as test will need to be integrated across the stack | 18:31 |
| Pharaoh_Atem | zyga: the issue occurred with snapd on fedora 23 gnome | 18:31 |
| Pharaoh_Atem | I've not tried snapd on fedora 24 | 18:31 |
| zyga | Pharaoh_Atem: I'm testing on 24 | 18:31 |
| zyga | Pharaoh_Atem: hmm, can you pastebin the error please? | 18:31 |
| Pharaoh_Atem | yeah, give me a sec | 18:32 |
| zyga | thanks | 18:32 |
| Son_Goku | zyga: "error: cannot list snaps: net/http: Client Transport of type *store.LoggedTransport doesn't support CancelRequest; Timeout not supported" | 18:33 |
| zyga | hmm, this looks like a different issue | 18:34 |
| zyga | I guess one of the deps in F23 is out of date in a way that doesn't fail at build time! | 18:34 |
| Son_Goku | zyga: "error: cannot list snaps: net/http: Client Transport of type *store.LoggedTransport doesn't support CancelRequest; Timeout not supported" | 18:34 |
| Son_Goku | zyga: "error: cannot list snaps: net/http: Client Transport of type *store.LoggedTransport doesn't support CancelRequest; Timeout not supported" | 18:34 |
| zyga | can you please file a bug on this (in fedora) | 18:34 |
| Son_Goku | zyga, I get variants of that error on every action with snapd | 18:34 |
| zyga | I'll get this fixed | 18:34 |
| Pharaoh_Atem | well, since snapd isn't in fedora, I'll file it in zyga/snapcore-fedora | 18:34 |
| zyga | I bet this involves other golang packages | 18:35 |
| zyga | Pharaoh_Atem: ah, ok | 18:35 |
| zyga | Pharaoh_Atem: that's fine | 18:35 |
| Pharaoh_Atem | did you see the decision that was made by FESCo? | 18:35 |
| zyga | yes | 18:35 |
| zyga | I didn't read the discussion notes | 18:36 |
| zyga | I plan to do that tomorrow, I was helping with some snap-confine things yesterday and today | 18:36 |
| Pharaoh_Atem | any progress on getting selinux support implemented? | 18:37 |
| mup | PR snapd#1726 closed: store,tests: have just one envvar SNAPPY_USE_STAGING_STORE to control talking to staging <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1726> | 18:37 |
| zyga | Pharaoh_Atem: none, I'm split among many tasks; I'm helping more upstream lately (with different things) and I dind't have any time to make more selinux progress | 18:38 |
| zyga | Pharaoh_Atem: in two weeks from now I should be more free (fingers crossed) | 18:39 |
| zyga | Pharaoh_Atem: we're trying to finish some high-profile features first | 18:39 |
| zyga | (hooks mainly) | 18:39 |
| Pharaoh_Atem | like what? | 18:39 |
| zyga | hooks will finally allow us to have configuration in snaps and richer interaction with interfaces | 18:39 |
| * Pharaoh_Atem shgs | 18:40 | |
| Pharaoh_Atem | *sighs | 18:40 |
| Pharaoh_Atem | zyga: https://github.com/zyga/snapcore-fedora/issues/5 | 18:41 |
| zyga | Pharaoh_Atem: thanks, I'll boot 23 and investigate | 18:41 |
| zyga | Pharaoh_Atem: I bet it's "just" a simple upgrade of another package | 18:41 |
| zyga | (I need to learn how to do those now) | 18:41 |
| Pharaoh_Atem | this is why you need to apply to be comaintainer of the snapd deps | 18:42 |
| zyga | Pharaoh_Atem: that would be a smart idea, I didn't consider this | 18:42 |
| zyga | Pharaoh_Atem: I want to write a tool that gives me the full dep tree in fedora and the git commit of each package | 18:42 |
| Pharaoh_Atem | I suggested it back at the sprint as well | 18:42 |
| elopio | ysionneau: we can roll back to the rev. that wasn't using snapcraft, that could crossbuild. But now I'm trying to get it build with snapcraft in armhf, and publish it. | 18:42 |
| zyga | Pharaoh_Atem: and compare this across distros | 18:42 |
| zyga | Pharaoh_Atem: ah, sorry, I didn't remember that | 18:43 |
| Pharaoh_Atem | zyga: that shouldn't be difficult, since Fedora has APIs for its repositories and when changes occur in the repos | 18:43 |
| Pharaoh_Atem | mdapi and fedmsg will be your best friends there | 18:43 |
| zyga | yep, it's just another TODO item :) | 18:43 |
| zyga | I | 18:43 |
| Pharaoh_Atem | shame that debian never finished their project to adopt fedmsg | 18:44 |
| zyga | I'd love to do it quickly/soon though as it is more and more of an important release blocker | 18:44 |
| Pharaoh_Atem | it would have been awesome to see it in place | 18:44 |
| Pharaoh_Atem | https://wiki.debian.org/FedMsg | 18:44 |
| zyga | Pharaoh_Atem: look at fedora bug 1369560 | 18:45 |
| mup | Bug #1369560: Add "Extract here" to archive manager context menu <amd64> <apport-bug> <freya> <third-party-packages> <elementary OS:Confirmed> <https://launchpad.net/bugs/1369560> | 18:45 |
| zyga | Pharaoh_Atem: just a quick note, there's no upstream release yet so Source0 is dummy/broken | 18:45 |
| zyga | Pharaoh_Atem: I'll polish some quirks and do a release soon (I wasn't touching that project earlier) | 18:45 |
| zyga | Pharaoh_Atem: I wasn't sure if dbus services have a RPM macro or not | 18:45 |
| mup | PR snapcraft#751 opened: python3 plugin: run setup.py in source subdir if such option exists <Created by yphus> <https://github.com/snapcore/snapcraft/pull/751> | 18:46 |
| zyga | Pharaoh_Atem: I also sent an update to snap-confine 1.0.40, some interesting new things and bug-fixes there :) | 18:47 |
| zyga | Pharaoh_Atem: it's already in bodhi | 18:47 |
| Pharaoh_Atem | zyga: why is snapd-xdg-open in ubuntu-core? | 18:47 |
| zyga | Pharaoh_Atem: a quick question, if I add a patch for /snap to snapd, can we progress on the review request? | 18:47 |
| zyga | Pharaoh_Atem: even ahead of FESCo decision? | 18:47 |
| Pharaoh_Atem | zyga: yes | 18:48 |
| zyga | Pharaoh_Atem: just another TODO item to move it | 18:48 |
| zyga | Pharaoh_Atem: I'll probably do that, I sent some pull requests upstream for this but I have a few more to make (mainly tests, I want to ensure it's not broken in any way) | 18:48 |
| Pharaoh_Atem | if you patch it to move to /run/snap or /var/run/snap or anywhere else FHS compliant, I can approve the package | 18:48 |
| zyga | Pharaoh_Atem: I picked /var/lib/snapd/ because it's not ephemeral yet | 18:48 |
| zyga | Pharaoh_Atem: that will be done separately in some future release | 18:48 |
| Pharaoh_Atem | so then /var/lib/snapd/mounts? | 18:48 |
| zyga | Pharaoh_Atem: actually snap/ (mounts is for "mount profiles") | 18:49 |
| Pharaoh_Atem | ah | 18:49 |
| zyga | Pharaoh_Atem: /var/lib/snapd/snap | 18:49 |
| Pharaoh_Atem | okay | 18:49 |
| Pharaoh_Atem | that's going to get confusing | 18:49 |
| zyga | the same "snap" as in /snap | 18:49 |
| Pharaoh_Atem | since there's snaps/ already | 18:49 |
| Pharaoh_Atem | which is where downloaded snaps exist | 18:49 |
| zyga | Pharaoh_Atem: it contains the actual snaps, yeah | 18:49 |
| Pharaoh_Atem | maybe runsnap/? | 18:49 |
| Pharaoh_Atem | something that makes it more obvious | 18:49 |
| zyga | Pharaoh_Atem: well, that's not for users to see (/var/lib/snapd), /snap is different but I just want to carry on | 18:50 |
| Pharaoh_Atem | sure | 18:50 |
| zyga | Pharaoh_Atem: well, the actual directory is trivial to change ;) | 18:50 |
| zyga | Pharaoh_Atem: I was just working on the changes to make that trivial | 18:50 |
| Pharaoh_Atem | but yes, if you patch it, there will be no blockers to the review left | 18:50 |
| zyga | Pharaoh_Atem: I was using FIXME as it was easy to grep for in logs | 18:50 |
| zyga | Pharaoh_Atem: cool, glad to hear that | 18:50 |
| Pharaoh_Atem | your preset request has already been provisionally approved for f24, f25, and rawhide | 18:51 |
| zyga | yep, I saw | 18:51 |
| zyga | just pending on the review | 18:51 |
| zyga | so so close to being generally useful :) | 18:52 |
| Pharaoh_Atem | the only other thing left to make snaps actually worth using is selinux support | 18:52 |
| zyga | I guess F25 is going to be out soon so selinux won't be there on time but F26 looks realistic | 18:52 |
| zyga | and I guess I can update it in earlier releases later | 18:52 |
| mup | PR snapcraft#752 opened: Ant properties, build target, and destination directory options <Created by evandandrea> <https://github.com/snapcore/snapcraft/pull/752> | 18:52 |
| Pharaoh_Atem | remember I said you can ship it as a module subpackage | 18:52 |
| Pharaoh_Atem | for snap-confine | 18:52 |
| Pharaoh_Atem | or snapd | 18:52 |
| Pharaoh_Atem | or wherever it is | 18:53 |
| zyga | Pharaoh_Atem: yep, I mean the whole stack, selinux, policy package, snapd and snap-confine support | 18:53 |
| zyga | (it's everywhere, snap-confine = mechanism, snapd = policy) | 18:53 |
| mup | PR snapd#1698 closed: tests: add all-snap spread image tests <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1698> | 18:58 |
| Son_Goku | zyga, well, I know there are quite a few folks interested in seeing the SELinux integration for snapd | 18:59 |
| zyga | Son_Goku: can you help me to get in touch with them | 18:59 |
| zyga | Son_Goku: together this can be done faster, I bet | 19:00 |
| Son_Goku | well, there are a few fedora-derived distros that may be considering shipping snapd | 19:00 |
| zyga | Son_Goku: like? :) | 19:02 |
| zyga | wa | 19:04 |
| Son_Goku | well, if I'm particularly happy about snapd in fedora, I may recommend that Korora and a few others ship it | 19:04 |
| Son_Goku | along with flatpak | 19:05 |
| zyga | Son_Goku: do you know of any developers that are familiar with selinux that I could work with to speed things up? | 19:05 |
| bull_ | guys snapcraft gui https://files.gitter.im/ubuntu/snappy-playpen/nRqJ/Screenshot-from-2016-08-24-00-34-18.jpg | 19:05 |
| Son_Goku | unfortunately, aside from Dan Walsh and a few other guys in #fedora-selinux, I don't really know anyone | 19:05 |
| zyga | Son_Goku: I met some folks at flock but I'd like to have someone that can work with me closely to design and implement selinux | 19:06 |
| zyga | I realize that Dan might have other priorities | 19:06 |
| mup | PR snapd#1729 opened: tests: spread all-snap test cleanup <Created by mvo5> <https://github.com/snapcore/snapd/pull/1729> | 19:06 |
| zyga | Son_Goku: how about yourself? | 19:09 |
| zyga | Son_Goku: I'm new to selinux, you are new to go (right?) | 19:09 |
| Son_Goku | yep | 19:10 |
| zyga | Son_Goku: together this will at least increse the bus factor :) | 19:10 |
| Son_Goku | haha | 19:10 |
| zyga | Son_Goku: and I bet having another person to work with will improve the design | 19:10 |
| mup | PR snapd#1664 closed: integration-tests: add update-rollback stress tests <Created by fgimenez> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1664> | 19:26 |
| mup | PR snapd#1729 closed: tests: spread all-snap test cleanup <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1729> | 20:14 |
| Pharaoh_Atem | zyga: so do you intend to patch the /snap path for Fedora? | 20:27 |
| zyga | Pharaoh_Atem: yes | 20:28 |
| zyga | Pharaoh_Atem: a few tests fail in weird ways, I'm just chasing that now | 20:28 |
| Pharaoh_Atem | cool | 20:28 |
| Pharaoh_Atem | at least your tests will be hardier :P | 20:28 |
| zyga | it's all good in practice, something that's specific to tests is flaky | 20:30 |
| ssweeny | jdstrand, I'm trying to use snap-confine with your overlayfs suggestion (https://paste.ubuntu.com/23079343/) but I'm getting apparmor denials on snap-confine itself trying to create a tmpfs dir | 20:34 |
| jdstrand | ssweeny: can you paste the denials? | 20:34 |
| ssweeny | jdstrand, https://paste.ubuntu.com/23083124/ | 20:35 |
| jdstrand | ssweeny: are you creating the /tmp/snapd.quirks_* dir in your code or was this already there? | 20:38 |
| ssweeny | jdstrand, that was already there | 20:38 |
| jdstrand | ssweeny: ok, then it sounds like there is a bug. zyga, fyi ^ | 20:38 |
| zyga | jdstrand: hmm | 20:38 |
| zyga | which distro and release is this on? | 20:38 |
| jdstrand | ssweeny: you can copy /etc/apparmor.d/usr.lib.snapd.snap-confine to /tmp and modify it | 20:39 |
| jdstrand | ssweeny: then do: sudo apparmor_parser -r /tmp/usr.lib.snapd.snap-confine | 20:39 |
| ssweeny | zyga this is on a series 16 all-snaps system | 20:39 |
| zyga | jdstrand: I believe upstream is correct here, | 20:39 |
| jdstrand | oh | 20:39 |
| zyga | ssweeny: ssweeny probably a bug in our ppa packaging then | 20:39 |
| jdstrand | maybe ssweeny is using new code but didn't copy the profile over | 20:40 |
| ssweeny | that could be | 20:40 |
| jdstrand | zyga: he is building it himslef | 20:40 |
| zyga | jdstrand: ah, then most likely so | 20:40 |
| zyga | ssweeny: the relevant parts are https://github.com/snapcore/snap-confine/blob/master/src/snap-confine.apparmor.in#L168 | 20:41 |
| jdstrand | ssweeny: ok, then diff what is in /etc/apparmor.d/usr.lib.snapd.snap-confine and ./src/snap-confine.apparmor.in | 20:41 |
| jdstrand | ssweeny: and add the new rules in the manner I described | 20:41 |
| ssweeny | jdstrand, zyga cool, thanks! | 20:41 |
| zyga | ssweeny: note the file is an .in file with @LIBEXECDIR@ that needs to be replaced with /usr/lib/snapd in your case | 20:41 |
| ssweeny | right | 20:41 |
| zyga | I think it would be useful to have a way for devtools to support snap-confine | 20:44 |
| zyga | we actually could, with file bind mounts | 20:45 |
| * zyga has good ideas :) | 20:45 | |
| ssweeny | :) | 20:45 |
| zyga | ogra: could I add a tweak to the initrd that bind mounts snap, snapd, snap-confine and the snap-confine aa profile from /snap/$SOME_RESERVED_NAME/current/ | 20:47 |
| zyga | ogra: this would let us *boot* a custom snapd for testing | 20:48 |
| zyga | and would simplify devtools considerably | 20:48 |
| zyga | down to "no customization required" | 20:48 |
| mup | PR snapd#1727 closed: dirs,snap: define methods for SNAP_USER_DATA and SNAP_USER_COMMON <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1727> | 20:55 |
| ssweeny | jdstrand, I added some code to add MS_SHARED to the mount like you said but I'm still not seeing the mount outside of the snap | 20:56 |
| mup | PR snapd#1730 opened: dirs,snap: handle empty root directory in SetRootDir <Created by zyga> <https://github.com/snapcore/snapd/pull/1730> | 20:56 |
| ssweeny | jdstrand, here's the diff as well as the SecurityMount string being returned in snapd | 21:00 |
| ssweeny | https://paste.ubuntu.com/23083177/ | 21:00 |
| jdstrand | ssweeny: note, I didn't write this portion of the code | 21:10 |
| jdstrand | ssweeny: what does the .fstab file look like? | 21:10 |
| ssweeny | jdstrand, /run /run none bind,rw,shared 0 0 | 21:11 |
| Pharaoh_Atem | zyga: btw, in regards to dbus-1 service location, there's no special macros for it | 21:13 |
| Pharaoh_Atem | so what you have is fine | 21:13 |
| Pharaoh_Atem | zyga: however, I'd be more comfortable with snapd-xdg-open if it had a release and was in the snapcore organization instead of the ubuntu-core one | 21:17 |
| zyga | Pharaoh_Atem: the organization was changed already | 21:17 |
| zyga | Pharaoh_Atem: I will do a release with a few simple upstream tweaks tomorrow | 21:17 |
| zyga | Pharaoh_Atem: (like empty NEWS files and others, this is not a gnu project) | 21:17 |
| Pharaoh_Atem | you don't need those files | 21:17 |
| zyga | Pharaoh_Atem: you can consider that provisionally done :) | 21:17 |
| zyga | Pharaoh_Atem: I know but without a macro in configure.ac they get added | 21:18 |
| Pharaoh_Atem | ah | 21:18 |
| zyga | Pharaoh_Atem: I did it in snap-confine :) | 21:18 |
| jdstrand | ssweeny: did you verify you are entering that part of the code? | 21:21 |
| ssweeny | jdstrand, not directly. let me do some instrumenting real quick | 21:22 |
| jdstrand | ssweeny: did you see if it worked outside of your code? eg, mount --bind /run /run ; mount --make-shared /run | 21:22 |
| * zyga EODs | 21:22 | |
| zyga | take care guys | 21:22 |
| jdstrand | ssweeny: but this is getting into the area where I advised getting zyga's input (zyga, that isn't an invitation to come back from eod :) | 21:23 |
| zyga | haa | 21:23 |
| zyga | I was typing /exit | 21:23 |
| zyga | what's that? | 21:23 |
| jdstrand | zyga: https://paste.ubuntu.com/23083177/ and this in .fstab: /run /run none bind,rw,shared 0 0 | 21:24 |
| zyga | ssweeny: did you try SNAP_CONFINE_DEBUG=1 | 21:24 |
| jdstrand | zyga: I really don't want to keep you from eod though | 21:24 |
| ssweeny | zyga, yeah I can ping you tomorrow | 21:24 |
| zyga | jdstrand: that's not allowd by the snap-confine apparmor profile AFAIR | 21:24 |
| * zyga looks at the pastebin | 21:25 | |
| jdstrand | at this point I'd need to dive in quite deep to debug | 21:25 |
| jdstrand | ssweeny: do you have apparmor denials? | 21:25 |
| ssweeny | I added that to the profile for the time being just to see if it works | 21:25 |
| zyga | ssweeny: can you pastebin the output of whatever you were testing with that variable set please | 21:25 |
| zyga | I can stay for 5 more minutes :) | 21:25 |
| zyga | I'm waiting for a review anyway | 21:25 |
| * jdstrand doesn't have much longer | 21:25 | |
| zyga | I should EOD at 18:00 one day and just have a walk | 21:26 |
| ssweeny | zyga, do I just export that variable on my shell or does it need to be part of the snap command? | 21:29 |
| ssweeny | I'm not seeing additional debug output with it exported | 21:29 |
| mup | PR snapd#1731 opened: firstboot: generate netplan config rather than ifupdown <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1731> | 21:31 |
| zyga | ssweeny: you have to export it | 21:47 |
| zyga | ssweeny: SNAP_CONFINE_DEBUG=1 | 21:47 |
| * zyga really EODs | 21:47 | |
| mup | PR snapd#1730 closed: dirs,snap: handle empty root directory in SetRootDir <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1730> | 21:49 |
| mup | PR snapd#1732 opened: many: respect dirs.SnapSnapsDir in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1732> | 21:51 |
| ssweeny | jdstrand, thanks again for the help. I'll play around a bit more and I'm sure I'll have more questions tomorrow :) | 21:58 |
| jdstrand | ok | 21:59 |
| mhall119 | jdstrand: is there any way for a snap command to call sudo? | 22:01 |
| mhall119 | or does the user have to launch the snap command with sudo? | 22:01 |
| jdstrand | the latter | 22:01 |
| jdstrand | that came up on the list recently-- I gave a very detailed response | 22:02 |
| mhall119 | thanks jdstrand | 22:15 |
| === bschaefer_ is now known as bschaefer | ||
| kyrofa | tyhicks, ping | 23:00 |
| tyhicks | kyrofa: hey | 23:02 |
| === bschaefer_ is now known as bschaefer | ||
| kyrofa | tyhicks, snapd has a section of the daemon's REST API which would ideally be accessible from all apps/hooks. Right now we have snapd-control which opens the thing up completely, but we definitely don't want to make that implicitly available to all apps/hooks, so I'm working on splitting out what I'm calling the "public" bits of the API into a separate socket | 23:05 |
| kyrofa | tyhicks, my question for you is, can we allow access to that socket without implicitly allowing access to other stuff? | 23:05 |
| kyrofa | tyhicks, here are the denials I get without any profile changes: http://pastebin.ubuntu.com/23083538/ | 23:06 |
| tyhicks | kyrofa: do clients connect over a unix domain socket? | 23:06 |
| kyrofa | tyhicks, indeed | 23:06 |
| tyhicks | kyrofa: yes, we can allow all snaps to access the public socket and only allow snaps with snapd-control to access the private socket | 23:08 |
| kyrofa | tyhicks, does that require setsockopt etc. to be in the default templates? Or can we somehow limit that to only that one socket (argument filtering, maybe?) | 23:09 |
| tyhicks | kyrofa: well, the network interface is autoconnect and it already allows setsockopt | 23:11 |
| kyrofa | tyhicks, but it allows a bunch of other stuff, too | 23:11 |
| kyrofa | tyhicks, another potential way to do this: this REST calls in question are coming from a helper binary written by us. Can it somehow be covered by a slightly more lenient profile? | 23:15 |
| kyrofa | (the binary is called by the apps/hooks in question) | 23:15 |
| Birchy | why doesn't OpenAL work in Snappy? | 23:15 |
| tyhicks | kyrofa: that's possible - we'd need to set up a profile transition | 23:15 |
| tyhicks | kyrofa: the CAP_NET_ADMIN denial is worrisome - do you know what is causing that? | 23:16 |
| kyrofa | tyhicks, the helper binary is written in go; looking at the bug, it seems to be a known issue | 23:16 |
| kyrofa | tyhicks, and ignorable, I think? | 23:17 |
| tyhicks | oh, yes | 23:17 |
| kyrofa | Very helpful snappy-debug message, there | 23:17 |
| tyhicks | I fixed that upstream and it hasn't made it back into xenial yet | 23:17 |
| tyhicks | oh, it has made it into xenial but maybe you're using an old kernel | 23:18 |
| kyrofa | Yeah that's possible, this is linode | 23:18 |
| tyhicks | $ git describe --contains 793d301b | 23:18 |
| tyhicks | Ubuntu-4.4.0-25.44~218 | 23:18 |
| kyrofa | tyhicks, would such a transition require snap-confine changes, or is that something we can setup at the profile level? | 23:18 |
| kyrofa | Yeah, 4.4.0-21 here | 23:19 |
| tyhicks | kyrofa: it is something that we could set up at the profile level | 23:19 |
| kyrofa | tyhicks, can that be done for seccomp as well? | 23:19 |
| tyhicks | that explains it, good to know that CAP_NET_ADMIN is definitely not needed | 23:19 |
| tyhicks | kyrofa: it cannot :/ | 23:19 |
| kyrofa | tyhicks, hrm | 23:19 |
| tyhicks | kyrofa: why are inet and inet6 sockets being created? | 23:20 |
| kyrofa | tyhicks, honestly, no idea | 23:20 |
| kyrofa | :P | 23:20 |
| tyhicks | kyrofa: if this is being done over a unix domain socket, AF_UNIX should be used instead of AF_INET or AF_INET6 | 23:21 |
| tyhicks | that would get rid of those 3 denials | 23:21 |
| kyrofa | Yeah I'll investigate that | 23:21 |
| mup | Bug #1465724 changed: net_admin apparmor denial when using Go <verification-done-xenial> <Snappy:Fix Released by tyhicks> <linux (Ubuntu):Fix Released> <linux (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1465724> | 23:21 |
| kyrofa | It might just be the libs reaching out somehow. The setsockopt is probably the bit issue there | 23:22 |
| kyrofa | big* | 23:22 |
| tyhicks | reading somaxconn is something that go does every time a go program is ran | 23:22 |
| tyhicks | so that could safely be allowed | 23:22 |
| kyrofa | In the default profile? | 23:23 |
| kyrofa | I didn't think that seemed too dangerous | 23:23 |
| tyhicks | I think so | 23:23 |
| tyhicks | that leaves the setsockopt | 23:23 |
| Birchy | how would I allow an application access to /run/udev? | 23:23 |
| kyrofa | But apparmor has become a lesser concern for me anyway considering the possible profile transition | 23:23 |
| tyhicks | kyrofa: the default seccomp template has this: | 23:25 |
| tyhicks | # needed by ls -l | 23:25 |
| tyhicks | socket | 23:25 |
| tyhicks | connect | 23:25 |
| tyhicks | kyrofa: we'll need to speak with jd strand about this tomorrow but since socket and connect are already allowed, it seems reasonable to allow setsockopt in the default template, too | 23:25 |
| kyrofa | tyhicks, okay, I'll make a note to speak to him. Thank you, you've been tremendously helpful! I think that covers everything :) | 23:26 |
| tyhicks | kyrofa: it is looking like we won't need a profile transition and some simple changes can be made to the default template to allow what you need | 23:26 |
| tyhicks | kyrofa: have a good one! :) | 23:27 |
| kyrofa | Agreed! | 23:27 |
| kyrofa | You too! | 23:27 |
| kyrofa | tyhicks, hey, missed you at the last sprint. Will you be at the next one you think? | 23:28 |
| tyhicks | kyrofa: I will be - see you there :) | 23:31 |
| kyrofa | Awesome! | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
