| Terces | no idea if I'm right here, but I am trying to install ubuntu core on my raspberrypi 3 and am having problems | 00:54 |
|---|---|---|
| Terces | I go through all the configuration screens, and at the end it tells me I can login through ssh, but it doesn't accept my password | 00:54 |
| Terces | I've gone through the steps several times so far and always the same problem. | 00:58 |
| === StoneTable is now known as aisrael | ||
| mup | PR snapcraft#1030 closed: tests: fix broken delta upload unit test <Created by shawn111> <Closed by shawn111> <https://github.com/snapcore/snapcraft/pull/1030> | 01:17 |
| === psivaa_ is now known as psivaa | ||
| mup | PR snapd#2574 closed: interfaces/docker-support: allow /run/shm/aufs.xeno for 14.04 (LP: #1654590) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2574> | 02:37 |
| mahendrunitin | Hi all... can anybody point to the file which has the function that verifies the signature of a snap downloaded from the store ? | 02:44 |
| mahendrunitin | like when i say snap install <> | 02:45 |
| mahendrunitin | snapd must download the snap from the store and verify the signature before installing it. | 02:45 |
| mup | Bug #1639646 changed: Unable to login for first time <Snappy:Expired> <https://launchpad.net/bugs/1639646> | 04:19 |
| mup | PR snapd#2563 closed: cmd/snap-confine: small tweaks to seccomp support code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2563> | 05:21 |
| mup | PR snapd#2564 closed: cmd/snap-confine: build non-installed libsnap-confine-private.a <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2564> | 05:21 |
| === JanC_ is now known as JanC | ||
| mup | PR snapd#2575 opened: cmd: move snap-discard-ns to dedicated directory <Created by zyga> <https://github.com/snapcore/snapd/pull/2575> | 05:43 |
| mup | Issue snapd#2576 opened: snap-confine cannot be setuid root on openSUSE <Created by zyga> <https://github.com/snapcore/snapd/issue/2576> | 06:15 |
| mup | PR snapd#2577 opened: tests: improve cleanup for c-unit-tests <Created by zyga> <https://github.com/snapcore/snapd/pull/2577> | 06:38 |
| mup | PR snapd#2577 closed: tests: improve cleanup for c-unit-tests <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2577> | 07:15 |
| mup | Issue snapd#2578 opened: race condition when executing interfaceManagerSuite.TestConnectTaskCheckAllowed <Created by zyga> <https://github.com/snapcore/snapd/issue/2578> | 07:56 |
| melvster | hi all in the tour it says to type 'snap info' | 08:04 |
| melvster | but that gives me | 08:04 |
| melvster | error: unknown command "info", see "snap --help" | 08:04 |
| melvster | snapcraft v 2.24 | 08:05 |
| melvster | any ideas if snap info still works? | 08:05 |
| mup | PR snapd#2579 opened: many: auto-connect plugs and slots symmetrically <Created by zyga> <https://github.com/snapcore/snapd/pull/2579> | 08:56 |
| mup | PR snapd#2560 closed: snap: fix missing sizes in `snap info <remote-snap>` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2560> | 09:06 |
| === mac_nibblet is now known as Guest31134 | ||
| mup | PR snapd#2580 opened: cmd/snap: fix internal naming in snap connect <Created by zyga> <https://github.com/snapcore/snapd/pull/2580> | 09:30 |
| mup | PR snapd#2581 opened: debian: remove trusty specific bits <Created by mvo5> <https://github.com/snapcore/snapd/pull/2581> | 09:35 |
| === vigo_ is now known as vigo | ||
| mup | PR snapd#2582 opened: tests: restore the missing initialization of iface manager causing race <Created by stolowski> <https://github.com/snapcore/snapd/pull/2582> | 09:45 |
| longsleep | Hi folks, i need to somwhere store the mac address on first boot of a snappy device. In classic ubuntu i have systemd service writing to uEnv.txt. With snappy now it would be awesonme if there would be an easy way to add a setting to uboot.env from the prepare-device hook. Anyone has a suggestion? | 09:52 |
| longsleep | zyga: Btw i still cannot run any command from a snap because of bind-mount permission denied on current edge. What is the state of the apparmor change you proposed in december to snap-confine? | 09:55 |
| mup | PR snapd#2583 opened: debian: merge feature/clean-rules-14.04 changes back to 14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2583> | 09:57 |
| mup | PR snapd#2584 opened: snap: use "size" as the json tag in snap.ChannelSnapInfo <Created by mvo5> <https://github.com/snapcore/snapd/pull/2584> | 10:19 |
| ogra_ | longsleep, hmm, why do you need to store it ? | 10:25 |
| ogra_ | (no way to get it from ROM ?) | 10:25 |
| longsleep | ogra_: the Kernel usually generates the mac address by md5(serial), but the serial on this particular kernel is always 0, thus i disabled it and always randomize it if a mac address was not passed by kernel commandline | 10:28 |
| ogra_ | hmm, and you have no way to set a persistent serial ? | 10:28 |
| ogra_ | we do something similar on the dragonboard | 10:28 |
| ogra_ | mkdir -p $(DESTDIR)/firmware/wlan; \ | 10:29 |
| ogra_ | ln -s /run/macaddr0 $(DESTDIR)/firmware/wlan/; \ | 10:29 |
| longsleep | ogra_: yeah, sure i could change the kernel to use the serial number from cmdline, but i did what was easiest :) | 10:29 |
| ogra_ | thats from the dragonboard kernel snap | 10:29 |
| longsleep | ogra_: when is that run? | 10:30 |
| ogra_ | at kernel snap build time | 10:30 |
| ogra_ | (there are other bits i'm just looking up, one sec) | 10:31 |
| zyga | longsleep: hmm, can you please refresh my memory | 10:31 |
| ogra_ | longsleep, http://paste.ubuntu.com/23769615/ is the matching initrd bit that reads the serial and turns it into a mac | 10:32 |
| longsleep | zyga: sure, you had some branch on github for snap-confine chaning something how apparmor is used | 10:32 |
| zyga | longsleep: and refer to a bug if you can | 10:32 |
| ogra_ | longsleep, indeed that only works if your firmware can use /lib/firmware/wlan | 10:33 |
| zyga | longsleep: I have plenty of such branches, do you remember the specific one? | 10:33 |
| longsleep | zyga: sure, i have this problem http://paste.ubuntu.com/23769518/ and you had me try a branch on github snap-confine, the branch is gone due to the snapd merge - let me see if i can find the link | 10:33 |
| longsleep | ogra_: yeah, also the mac address is for ethernet, not for wlan | 10:34 |
| zyga | longsleep: hmmm, that's odd | 10:34 |
| zyga | longsleep: which version are you on? | 10:34 |
| longsleep | zyga: the bug i added then is https://bugs.launchpad.net/snap-confine/+bug/1645457 | 10:34 |
| mup | Bug #1645457: cannot bind-mount the mount namespace file on Kernel 3.10 <Snappy Launcher:New> <https://launchpad.net/bugs/1645457> | 10:34 |
| zyga | ah | 10:34 |
| zyga | on 3.10 you say | 10:35 |
| zyga | longsleep: thanks, I'll check what I can do | 10:35 |
| zyga | longsleep: I think it may require 3.10 specific code | 10:35 |
| longsleep | zyga: yeah but i got the aa backported, lxd and stuff works | 10:35 |
| zyga | okay | 10:35 |
| zyga | hmmm | 10:35 |
| zyga | is that the m10? | 10:35 |
| longsleep | zyga: it was this branch https://github.com/snapcore/snap-confine/tree/use-aa-support | 10:35 |
| longsleep | zyga: m10? | 10:36 |
| ogra_ | heh | 10:36 |
| zyga | longsleep: m10 tablet | 10:36 |
| longsleep | zyga: nah, Pine64 | 10:36 |
| zyga | longsleep: ok | 10:36 |
| ogra_ | zyga, m10 is my domain ;) | 10:36 |
| ogra_ | (starting with the image this week) | 10:36 |
| longsleep | zyga: you had my try the use-aa-support branch which worked, but branch is gone now | 10:36 |
| longsleep | s/my/me | 10:36 |
| zyga | longsleep: that branch was merged | 10:37 |
| zyga | longsleep: which version of snapd are you using? | 10:37 |
| longsleep | zyga: root@localhost:~# snap version | 10:37 |
| longsleep | snap 2.20 | 10:37 |
| longsleep | snapd 2.20 | 10:37 |
| longsleep | series 16 | 10:37 |
| zyga | longsleep: ok, let me investigate | 10:38 |
| longsleep | i build a new image yesterday from edge channel | 10:38 |
| longsleep | zyga, ogra_ so the snap-confine issue and the non-persisting ethernet mac are the only two issues - if those are fixed i finally can try to publish pine64 gadget and kernel snap | 10:40 |
| ogra_ | longsleep, i see you mention uEnv.txt above, you are aware that we dropped support for that quite a while ago ? | 10:40 |
| ogra_ | snapd expects uboot.env | 10:41 |
| longsleep | ogra_: sure, i not use it on snappy | 10:41 |
| ogra_ | ah, k | 10:41 |
| ogra_ | (just wanted to make sure) | 10:41 |
| longsleep | ogra_: thats what i asked if there is a way to add additional stuff to uboot.env in some hook | 10:41 |
| longsleep | ogra_: of course i could make it load both, but i would rather avoid that | 10:41 |
| ogra_ | you can add a systemd unit in the gadget ;) | 10:42 |
| ogra_ | calling fw_setenv to set a variable in uboot.env | 10:42 |
| longsleep | ogra_: yeah - something like that - i would prefer it to run it in tge perpare-device hook though | 10:43 |
| longsleep | ogra_: that hook is run on the device on first boot right? | 10:43 |
| ogra_ | i think so ... though thats kind of mvo land | 10:44 |
| longsleep | ogra_: do you know if fw_setenv is atomic? What happens on powerof while it writes? | 10:45 |
| ogra_ | hmm, not sure ... it is designed for mtd devices and just toggles bytes ... moght not be atomic at all since it directly writes on the low level | 10:46 |
| ogra_ | *might | 10:47 |
| zyga | longsleep: where do you plan to publish the gadget? | 10:47 |
| longsleep | ogra_: in any case the file is writting on vfat - so whenever this file changes it might become broken i would guess | 10:47 |
| ogra_ | longsleep, but i think uboot.env itself is handled atomic | 10:48 |
| longsleep | zyga: the gadget snap you mean? Ubuntu store - where else would i publish it? | 10:48 |
| mvo | longsleep: iirc I looked at this and its writing in place | 10:48 |
| ogra_ | due to the "CONFIG_REDUNDANT_ENVIRONMENT" option | 10:48 |
| zyga | longsleep: and the source? | 10:48 |
| longsleep | zyga: well i have it all in my building gear at https://github.com/longsleep/build-pine64-image/tree/master/snappy | 10:49 |
| zyga | longsleep: did you consider splitting those so that the gadget is separate | 10:50 |
| longsleep | mvo: mhm yeah - which is bad - but i guess you so far did not have issues people turning off their devices while that file gets written | 10:50 |
| zyga | longsleep: e.g. look at https://github.com/snapcore/pi3-gadget | 10:50 |
| ogra_ | longsleep, well, no file gets written ... the window in which changes happen is very small since fw_setenv only toggles the byxtes directly | 10:51 |
| longsleep | zyga: no - it needs binary blobs from the general repository - i would have to copy those then too | 10:51 |
| zyga | longsleep: so blobs need to be in two places? | 10:51 |
| ogra_ | longsleep, due to the uboot.env setup the filesystem isnt involved at all | 10:51 |
| zyga | longsleep: (same blobs?) | 10:52 |
| longsleep | zyga: if they are two repos yes | 10:52 |
| zyga | longsleep: which blobs are that? | 10:52 |
| longsleep | zyga: i need those blobs to build classic images as well | 10:52 |
| longsleep | zyga: boot0 and bl31 | 10:52 |
| longsleep | zyga: also u-boot needs to be built first | 10:52 |
| longsleep | zyga: with the building gear in the larger repository | 10:53 |
| zyga | longsleep: too bad, it would be great if we could build a hub (on github) with community gadgets and kernels | 10:53 |
| longsleep | zyga: all the blobs are in https://github.com/longsleep/build-pine64-image/tree/master/blobs | 10:53 |
| ogra_ | longsleep, the worst thing that can happen to you is that the variable holding the mac will contain garbage | 10:53 |
| ogra_ | the env file should stay readable and rthe device should stay bootable | 10:53 |
| longsleep | ogra_: really? so it appends bytes only? | 10:54 |
| ogra_ | it toggles them | 10:54 |
| ogra_ | the file size never changes | 10:54 |
| longsleep | ogra_: ah sure | 10:54 |
| longsleep | ogra_: i remember now | 10:54 |
| longsleep | ogra_: the size is fixed - thanks for remembering me | 10:54 |
| ogra_ | so on that side you should eb safe | 10:54 |
| ogra_ | *be | 10:55 |
| ogra_ | and for the firstboot job... as i said, mvo should be able to help | 10:55 |
| longsleep | zyga: yeah - i am not sure about how feasible that is as the gadget and kernel snaps usually require extra stuff like bootloaders and device trees | 10:56 |
| zyga | longsleep: two ways of doing that: building everything in the repo or commiting binaries into the repo and just using snapcraft to pull it from other places | 10:56 |
| zyga | longsleep: you can build many things in the gadget snap | 10:56 |
| longsleep | zyga: but i agree that a central place to find stuff would be great, but i think the store would be better suited and have meta data to point to the source repo | 10:56 |
| ogra_ | longsleep, our gadgets moved to https://github.com/snapcore/ and are fully built by snapcraft now | 10:57 |
| ogra_ | you can easily add a makefile part to build your upstream uboot | 10:57 |
| zyga | longsleep: yeah but github org to hold this would look nice even if store supports this | 10:57 |
| longsleep | zyga: yes | 10:58 |
| ogra_ | zyga, i think we need an example gadget that builds from upstream uboot trees ... | 10:58 |
| longsleep | ogra_: why only the gadget snaps? what about kernel snaps? | 10:58 |
| * ogra_ adds to TODO | 10:58 | |
| zyga | longsleep: I poked the kernel team about this | 10:58 |
| zyga | longsleep: they were supposed to evaluate this | 10:58 |
| zyga | longsleep: I didn't hear back yet | 10:58 |
| ogra_ | longsleep, the kernel snaps are maintained by the kernel team now | 10:58 |
| ogra_ | longsleep, and they have their own workflow not using github | 10:58 |
| zyga | longsleep: I'd love the kernel team to take this decision and help them along the way | 10:58 |
| longsleep | ogra_: right, thats possible for things which actually have a sane kernel | 10:59 |
| zyga | ogra_: (just keeping a mirror on github would be 100% better though) | 10:59 |
| ogra_ | since they have a centra git server since forever where akll their trees live | 10:59 |
| ogra_ | zyga, sure | 10:59 |
| ogra_ | zyga, but dont forget that the official kernel snaps are always built from debs, so that wont help external users much | 10:59 |
| zyga | ogra_: sure, but it would help in visibility | 11:00 |
| zyga | ogra_: and unofficial snaps won't be this way | 11:00 |
| ogra_ | indeed | 11:00 |
| zyga | ogra_: I bet more and more people will use sources to build the kernel | 11:00 |
| zyga | ogra_: and those examples will be valuable | 11:00 |
| ogra_ | i hope all external people will ;) | 11:00 |
| ogra_ | the use of debs is really a special case | 11:01 |
| zyga | indeed | 11:01 |
| longsleep | zyga: to build everything with snapcraft, it would need to build atf (bl31) from a git tree, u-boot from a git tree, some tools, then combine u-boot a device tree and bl31, and then use blob boot0 and the resulting combined u-boot-with-dtb-and-atf binary | 11:01 |
| zyga | longsleep: you still build those, right? | 11:01 |
| ogra_ | longsleep, well, you can start with a tree with prebuilt binaries | 11:01 |
| ogra_ | and then piece by piece add parts that build the stuff | 11:01 |
| zyga | yes, exactly! | 11:02 |
| longsleep | zyga, ogra_: the rest of my classic ubuntu build gear builds those | 11:02 |
| ogra_ | longsleep, https://github.com/snapcore/pi3-gadget | 11:02 |
| ogra_ | thats what we do here | 11:02 |
| longsleep | ogra_: ah ok, prebuilt folder | 11:02 |
| ogra_ | right | 11:02 |
| longsleep | ogra_: sure i can do that | 11:02 |
| ogra_ | over time this will go away | 11:02 |
| zyga | longsleep: start prebuilt, over time you can use launchpad to build your snap | 11:02 |
| zyga | longsleep: and this lets people report bugs nicely | 11:02 |
| zyga | longsleep: repo == bugs | 11:02 |
| longsleep | zyga: yeah sure i think about it once things start working :) | 11:05 |
| zyga | woot, great :) | 11:05 |
| longsleep | mvo: Quick question, the prepare-device hook of the gadget snap is run on first boot on the device? | 11:05 |
| longsleep | zyga: so any clue about the apparmor issue? | 11:06 |
| zyga | longsleep: not yet | 11:07 |
| longsleep | zyga: just fyi - i compared kernel patches for aa to the ones from roseapple pi and they seem to be the same, not sure if they copied from me or something though :) | 11:08 |
| zyga | longsleep: maybe from the ref 3.10 kernel with ubuntu aa? | 11:08 |
| mvo | longsleep: yes, pedronis implemented the prepare-device hook and its used in production | 11:08 |
| longsleep | zyga: yeah - maybe - so i think the same issue shold be on roseapple pi as well - if not then something else is a miss on my kernel tree | 11:09 |
| ogra_ | i think ondra worked on that one, he might know | 11:10 |
| === hikiko is now known as hikiko|ln | ||
| mup | PR snapd#2585 opened: debian: move systemd files out of ./debian and into ./data/systemd <Created by mvo5> <https://github.com/snapcore/snapd/pull/2585> | 11:29 |
| longsleep | This reminds me, i still cannot register a key with snapcraft: Key registration failed: The account-key-request assertion is not valid. | 11:31 |
| mup | PR snapd#2582 closed: tests: restore the missing initialization of iface manager causing race <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2582> | 11:32 |
| === hikiko|ln is now known as hikiko | ||
| mardy | kyrofa: when running snapcraft from master on a project of mine, I key a KeyError on build-attributes | 12:15 |
| mardy | kyrofa: is this a known bug? | 12:15 |
| mup | PR snapd#2586 opened: daemon: make 201 and 202 responses have a Location header as per doc <Created by chipaca> <https://github.com/snapcore/snapd/pull/2586> | 12:17 |
| shuduo | ppisati: hi | 12:40 |
| mup | PR snapcraft#1034 closed: rust plugin: respect fetch parameters <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1034> | 12:51 |
| mardy | kyrofa: pls ignore my message above, the error was mine (launching snapcraft/main.py instead of the bin/snapcraft wrapper) | 12:57 |
| mup | Issue snapd#2578 closed: race condition when executing interfaceManagerSuite.TestConnectTaskCheckAllowed <Created by zyga> <Closed by stolowski> <https://github.com/snapcore/snapd/issue/2578> | 12:58 |
| longsleep | ogra_: to build the gadget snap with snapcraft.yaml i need hook support which has been merged 4 days ago .. is there a ppa for snapcraft where i can get that / nightly builds or something? | 13:04 |
| ogra_ | longsleep, i think sergiusens has one, yes | 13:04 |
| ogra_ | (now dont ask me where :P) | 13:05 |
| longsleep | ogra_: mhm the one i found has not seen updates since a while | 13:05 |
| ogra_ | well, wait for sergiusens, if there is one he will know where | 13:06 |
| ogra_ | but its python, i bet you could just branch it from github and run ./snapcraft or some such | 13:06 |
| === ben_r_ is now known as ben_r | ||
| mup | PR snapd#2584 closed: snap: use "size" as the json tag in snap.ChannelSnapInfo <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2584> | 13:46 |
| jdstrand | roadmr: hi! one more small commit to support the new 'daemon: notify': can you pull r816? | 14:21 |
| roadmr | jdstrand: sure! btw we haven't really deployed the laste few changes :/ sorry about that, we should have a deployment this week I reckon | 14:21 |
| roadmr | (but hey, they look great on staging ;) | 14:21 |
| jdstrand | hehe | 14:22 |
| jdstrand | thanks! | 14:22 |
| popey | sergiusens: I'm building a python app snap, but it needs a parameter after "python3 setup.py ", I don't think we support that (yet?). Any plan to? Should I file a bug? | 14:26 |
| mup | PR snapd#2587 opened: interfaces/mount: add snippet types <Created by zyga> <https://github.com/snapcore/snapd/pull/2587> | 14:47 |
| mup | PR snapd#2580 closed: cmd/snap: fix internal naming in snap connect <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2580> | 14:51 |
| mup | PR snapd#2588 opened: cmd/snap: add shell completion to connect <Created by zyga> <https://github.com/snapcore/snapd/pull/2588> | 15:00 |
| zyga | Son_Goku: hey | 15:11 |
| Son_Goku | zyga: hi | 15:11 |
| zyga | Son_Goku: I put together a wiki page that describes distro status | 15:11 |
| zyga | Son_Goku: and file a few more bugs describing where we are on blockers | 15:11 |
| Son_Goku | oh? | 15:11 |
| zyga | Son_Goku: I replied to the thread you just replied to | 15:12 |
| Son_Goku | I'm guessing you saw my reply to the email | 15:12 |
| Son_Goku | have you? I don't see it... | 15:12 |
| zyga | yes, though i worked on the wiki for a few days now | 15:12 |
| Son_Goku | ah, apparently it's not in the ML yet | 15:13 |
| zyga | Son_Goku: https://github.com/snapcore/snapd/wiki/Distributions | 15:14 |
| zyga | Son_Goku: can you check if the status describing fedora is accurate? | 15:15 |
| Son_Goku | for CentOS, it's "EPEL7" | 15:15 |
| zyga | ah, can you correct that | 15:16 |
| zyga | sorry, I always get that wrong :) | 15:16 |
| Son_Goku | fixed | 15:17 |
| zyga | thanks :) | 15:19 |
| mup | PR snapd#2589 opened: tests: test for auto-aliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/2589> | 15:21 |
| Son_Goku | playing whack-a-mole with snapd is exhausting though | 15:21 |
| Son_Goku | zyga: oh, and openSUSE supports both apparmor and selinux | 15:22 |
| Son_Goku | apparmor is just the default there | 15:23 |
| Son_Goku | there's also go bindings to libselinux, I think | 15:24 |
| * ogra_ recommends a whack-a-mole script | 15:24 | |
| Son_Goku | you would :P | 15:24 |
| ogra_ | :) | 15:24 |
| zyga | Son_Goku: that field describes what is available in snapd, not the distro | 15:27 |
| Son_Goku | ah | 15:27 |
| Son_Goku | well, you have "dependencies" listed | 15:27 |
| Son_Goku | oh, you already pulled in libselinux go bindings into snapd? | 15:27 |
| Son_Goku | anyway, bbs, have to go to work | 15:30 |
| kyrofa | elopio, are we still publishing daily builds of snapcraft to a PPA? | 15:37 |
| mup | PR snapcraft#1040 opened: [WIP] Run the rust test in armhf <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1040> | 15:48 |
| jdstrand | zyga: hey, looking at https://github.com/snapcore/snapd/wiki/Distributions you list Elementary in 'Linux Distributions' but not under 'Support Matrix'. I'm not sure if 'Support Matrix' is supposed to have everything, but if not, 'Support Matrix' should probably say 'Ubuntu 16.04 LTS and Ubuntu derivatives' (or something) | 15:52 |
| jdstrand | zyga: also, bug #1653487 is addressed (seccomp) for 14.04 | 15:54 |
| mup | Bug #1653487: seccomp argument filtering not working on trusty amd64 <verification-done> <libseccomp (Ubuntu):Fix Released> <libseccomp (Ubuntu Trusty):Fix Committed by jdstrand> <https://launchpad.net/bugs/1653487> | 15:54 |
| jdstrand | I'll update the wiki for that seccomp | 15:55 |
| longsleep | kyrofa: i am looking for daily snapcraft builds too, did you find them? | 15:56 |
| kyrofa | longsleep, heh, I was asking for you | 15:57 |
| kyrofa | But he must not be in just yet | 15:57 |
| kyrofa | longsleep, have you tried running snapcraft from source, as ogra_ suggested? | 15:57 |
| longsleep | kyrofa: no - i have not - thats a bit too cutting edge and i would rather wait before merging my pr to build the gadget snap with snapcraft until there is a package available | 15:58 |
| longsleep | kyrofa: in the past i was using https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily - but that is not updated since a while | 15:59 |
| kyrofa | longsleep, fair enough. I'll continue to look into why that's no longer updated | 15:59 |
| longsleep | kyrofa: nice thanks! | 16:00 |
| longsleep | kyrofa: any chance you know something about snapcraft key registration too? i have an issue there and i cannot register any key with my account | 16:01 |
| kyrofa | longsleep, maybe, what's happening? | 16:01 |
| longsleep | kyrofa: take a look here: http://paste.ubuntu.com/23770867/ | 16:02 |
| longsleep | kyrofa: i looked a bit at the data, and seems that the remote API returns this error message - so i figured there might be a problem with my account or something | 16:03 |
| kyrofa | longsleep, huh, yeah no kidding. cprov, any idea what "Key registration failed: The account-key-request assertion is not valid" might imply? | 16:04 |
| zyga | jdstrand: hey | 16:10 |
| zyga | jdstrand: it's not supposet do have everything (as it says just above the table); I like the derivatives idea, I'll try to do something like that | 16:11 |
| zyga | jdstrand: oh, nice, does it mean 14.04 is good now? | 16:11 |
| zyga | jdstrand: thanks! | 16:11 |
| zyga | jdstrand: btw, long time no see | 16:11 |
| zyga | jdstrand: I was busy with some other things but this and next week my focus is to complete mount namespace mutation for existing mount namespaces | 16:12 |
| zyga | jdstrand: so connect/disconnect will go and change what is there in practice without restarting apps | 16:12 |
| zyga | jdstrand: I've started some work towards that, if you want I can sync with you on this | 16:12 |
| jdstrand | zyga: you'd have to talk to tvoss for the most up to date info, but aiui, installing snapd on 14.04 desktop is fixed in ppa (and likely moving to trusty-proposed), but there remains a cgmanager issue (ie, if it is installed, systemd (and therefore snapd) fails to start | 16:13 |
| jdstrand | zyga: at some point a sync would be good, but I'm still trying to clear my plate to help you with snap-confine testsuite | 16:13 |
| zyga | jdstrand: I see, I'll wait until it is out of proposed | 16:13 |
| tvoss | zyga: let me know if you need anything specifically | 16:14 |
| zyga | jdstrand: thanks!, after your earlier suggestion only i386 is failing | 16:14 |
| jdstrand | cool | 16:14 |
| zyga | jdstrand: I'll try to fix the remaining issue, I think it is well undertood now :) | 16:14 |
| zyga | tvoss: monitor the issue and update the wiki once it is green :) | 16:14 |
| tvoss | zyga: works for me | 16:15 |
| jdstrand | zyga: oh, you don't need me to help for i386? ok, then I'll not plan on looking at it unless you come back | 16:15 |
| zyga | jdstrand: so far no, I just need a second to tweak one more thing and it should land | 16:16 |
| zyga | jdstrand: I will come around to it in a few hours today | 16:16 |
| * zyga documents live modificationto mount namespaces now | 16:16 | |
| === mup_ is now known as mup | ||
| kyrofa | davidcalle, you around? | 16:26 |
| === sarnold_ is now known as sarnold | ||
| mup | Bug #1655060 opened: snapcraft doesn't support the dbus daemon type <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1655060> | 16:39 |
| zyga | jdstrand: my initial idea on how to implement modification of the mount namespace: https://github.com/snapcore/snapd/wiki/Live-Modification-Of-Mount-Namespaces | 17:01 |
| mup | PR snapd#2550 closed: interface hooks: connect plug slot hooks (step 2) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2550> | 17:04 |
| === jkridner|pd is now known as jkridner | ||
| mup | PR snapcraft#1041 opened: Document `notify` daemon type <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1041> | 17:12 |
| jdstrand | zyga: ok, thanks | 17:15 |
| jdstrand | tvoss: fyi, I merged the docker aufs change last night | 17:15 |
| elopio | nessita or ev: could you please allow Matthew from matrix to use the synapse snap name? | 17:18 |
| zyga | jdstrand: what does that bring? | 17:20 |
| zyga | jdstrand: I'm not sure I recall | 17:20 |
| nessita | elopio, checking! | 17:20 |
| nessita | elopio, did he fill name request/dispute? | 17:21 |
| elopio | nessita: he said: i mailed ubuntu-folks for guidance on killing off the previous snap, or getting control of it so i could replace it with the proper one | 17:22 |
| elopio | I'm not sure if it was through the form. Should I tell him to fill it? | 17:22 |
| nessita | elopio, the only snap I see is matrix-synapse owned by kyrofa | 17:22 |
| nessita | well, name, not snap yet | 17:23 |
| elopio | nessita: I think it was reserved because there is a deb binary called synapse | 17:23 |
| nessita | elopio, then can you please ask him to file a name dispute? | 17:23 |
| elopio | yes, I'm trying | 17:23 |
| nessita | thanks! | 17:24 |
| lazyPower | When i declare a bin as a daemon, is snappy creating an intermediary systemd unit file on my snaps behalf? | 17:26 |
| ogra_ | yes | 17:27 |
| lazyPower | ah found it in /etc/systemd/system, thanks | 17:28 |
| lazyPower | say i'm using a snap in a juju charm, I suppose I just stuff the generated config bits I need the snap to read from in /var/snap/$snap/common and inform the systemd service it needs to restart? | 17:30 |
| jdstrand | zyga: what does what bring? the docker fix? it was a trivial policy update to the docker-support interface since trusty mounts shm on /run instead of /dev | 17:31 |
| zyga | jdstrand: ah, I see | 17:31 |
| tvoss | thx for the update | 17:38 |
| BrownMit | Good afternoon folks, I have a kind of weird situation with snap on a couple of my Ubuntu servers. Google has not been helpful so I'm hoping someone here can help me out. On most of my ubuntu servers (16.04.1) I have no issues with snap. However, on two servers, it works but I can only seem to find a subset of the available applications. For example, "snap find vlc" reports error: no snaps found for vlc | 17:58 |
| ogra_ | BrownMit, "snap version" would be interesting ... and "snap list|grep core" ... | 18:00 |
| BrownMit | ~> snap version | 18:01 |
| BrownMit | snap 2.20.1ubuntu1 | 18:01 |
| BrownMit | snapd 2.20.1ubuntu1 | 18:01 |
| BrownMit | series 16 | 18:01 |
| BrownMit | ubuntu 16.04 | 18:01 |
| ogra_ | the same on all servers ? | 18:02 |
| BrownMit | ~> snap list|grep core | 18:02 |
| BrownMit | core 16.04.1 712 canonical - | 18:02 |
| ogra_ | same question ... | 18:02 |
| BrownMit | yes to snap version | 18:02 |
| BrownMit | on one server snap cdore is at rev 714 | 18:02 |
| ogra_ | thats a different arch i guess | 18:03 |
| BrownMit | ahhhhhh | 18:03 |
| ogra_ | i think vlc is only available on amd64 … so that might explain why you dont find it there | 18:03 |
| BrownMit | and that would be it | 18:03 |
| ogra_ | : | 18:04 |
| ogra_ | :) | 18:04 |
| BrownMit | yup, those are my only 32 bit implementations | 18:04 |
| BrownMit | thank you!!! | 18:04 |
| ogra_ | np :) | 18:04 |
| mup | PR snapd#2589 closed: tests: test for auto-aliases <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2589> | 18:21 |
| anewman | Hi all. I'm looking to build a snap that has a user-extensible plugin interface with no build process (so perl scripts for plugins). Is there a good snap in existence I can use as a model for this? | 18:50 |
| anewman | In short, should plugins end up in data or should they be separate snaps? | 18:50 |
| kyrofa | mhall119, I seem to remember you having similar experience with geany and its plugins | 18:51 |
| mhall119 | kyrofa: I did! anewman I have an example that might help you, let me get a link | 18:53 |
| anewman | Thanks! | 18:53 |
| mhall119 | anewman: so here's the snapcraft.yaml for the app (geany): https://github.com/ubuntu/snappy-playpen/blob/geany/geany/snapcraft.yaml | 18:54 |
| mhall119 | it will use a local directory called "plugins" to be the mount-point for the sharing | 18:54 |
| mhall119 | so /snap/geany/current/plugins | 18:55 |
| mhall119 | upstream geany provides the plugins all from one project, so I was able to built a single geany-plugins snap that has them all | 18:55 |
| mhall119 | which is this: https://github.com/ubuntu/snappy-playpen/blob/geany/geany-plugins/snapcraft.yaml | 18:55 |
| anewman | alright, that makes sense to me. | 18:56 |
| mhall119 | so in the first I define a "plug" using the content interface, with the target of ${SNAP}/plugins/ | 18:56 |
| anewman | And one assumes that a less monolithic plugin set could end up with a set of package-plugin-pluginname snaps? | 18:56 |
| kyrofa | mhall119, how would you have done that if the plugins weren't all available in one package? | 18:56 |
| mhall119 | anewman: when I did this work, that wasn't possible, but it might be now | 18:57 |
| anewman | Alright, interesting. Because I wouldn't want to have to whitelist the plugins in the head package. | 18:57 |
| mhall119 | kyrofa: zyga and I discussed it, and the plan was to allow snap-namespaced mount points under the target itself | 18:57 |
| mhall119 | IIRC | 18:57 |
| kyrofa | mhall119, i.e. the plug could be connected to multiple slots? | 18:57 |
| mhall119 | kyrofa: no, the geany snap would provide one plug, that could be connected to multiple slots | 18:58 |
| kyrofa | mhall119, haha, isn't that what I just said? | 18:59 |
| kyrofa | mhall119, do you know of a bug that represents that? | 18:59 |
| mhall119 | I thought you meant multiple slots per snap, so slot-a, slot-b, slot-c, etc | 18:59 |
| kyrofa | Nah, same page | 18:59 |
| * mhall119 checks | 19:00 | |
| mhall119 | kyrofa: I can't find one, I'm not sure we ever made a bug for it | 19:02 |
| kyrofa | mhall119, alright. zyga, did that plan ever progress? | 19:03 |
| mhall119 | we discussed it in den haag | 19:03 |
| mhall119 | is zyga in cape town this week? | 19:04 |
| kyrofa | Probably. You might consider making a bug for him, he has a lot going on | 19:05 |
| kyrofa | mhall119, does bug #1655125 properly describe the issue? | 19:31 |
| mup | Bug #1655125: Missing interface: content sharing in the other direction <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1655125> | 19:31 |
| mup | Bug #1655125 opened: Missing interface: content sharing in the other direction <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1655125> | 19:31 |
| zyga | mhall119: I'm not in cape town | 19:44 |
| zyga | mhall119: there's ongoing work on the "overmount" interface, I'm not sure that's what you were discussing but that helps people with some bits | 19:45 |
| kyrofa | zyga, does that cover bug #1655125? | 19:55 |
| mup | Bug #1655125: Missing interface: content sharing in the other direction <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1655125> | 19:55 |
| zyga | kyrofa: no | 19:57 |
| zyga | kyrofa: this is more store side and assertion work | 19:57 |
| zyga | kyrofa: if feels in scope but not in the list of things I'm going to focus on this week | 19:57 |
| zyga | kyrofa: this week it is https://github.com/snapcore/snapd/wiki/Live-Modification-Of-Mount-Namespaces | 19:57 |
| kyrofa | zyga, ah, excellent | 19:58 |
| === mup_ is now known as mup | ||
| mwhudson | zyga: hey, should we request removal of the snap-confine source package from debian unstable? | 20:06 |
| mwhudson | zyga: it isn't going to get autoremoved because it built on lots of arches where snapd does not | 20:06 |
| mwhudson | aiui | 20:08 |
| mup | PR snapcraft#1042 opened: Add documentation for hooks <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1042> | 20:15 |
| zyga | mwhudson: hey | 20:29 |
| zyga | mwhudson: I think this is sensible, unless mvo disagrees | 20:29 |
| zyga | mwhudson: what does that do to snapd source package, nothing I presume? | 20:29 |
| davidcalle | kyrofa: around now | 21:36 |
| mup | Bug #1607748 changed: Ability to use two registered names for the same snap <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1607748> | 21:41 |
| mup | PR snapd#2590 opened: interfaces: miscellaneous policy updates for network-control, unity7, pulseaudio, default and home <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2590> | 21:41 |
| davidcalle | kyrofa: now that I've seen two examples, it's a bit more clear how to use scriptlets, now I'm mostly curious about 1) when do scriptlets run and if the install one is the only one supported atm 2) dash or bash? 3) any restrictions or notable boundaries on what can happen there? 4) where can I find the list of snapcraft specific env vars ($SNAPCRAFT_*)? | 21:43 |
| mwhudson | zyga: yeah, no impact on anything else i think | 21:43 |
| kyrofa | davidcalle, sure! (1) should be answered by https://github.com/snapcore/snapcraft/blob/master/snapcraft/__init__.py#L228, I think? | 21:46 |
| kyrofa | davidcalle, (2) /bin/sh, so dash in most cases I suspect | 21:47 |
| kyrofa | (3) no known restrictions | 21:47 |
| kyrofa | davidcalle, (4) there's actually no list, but they're SNAPCRAFT_PROJECT_NAME, SNAPCRAFT_PROJECT_VERSION, SNAPCRAFT_STAGE, and SNAPCRAFT_PART_INSTALL | 21:48 |
| jdstrand | diddledan: hi! fyi, https://github.com/snapcore/snapd/pull/2590 has the xdg-open fix | 21:53 |
| mup | PR snapd#2590: interfaces: miscellaneous policy updates for network-control, unity7, pulseaudio, default and home <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2590> | 21:53 |
| davidcalle | kyrofa: do you know the use case for project_version? | 21:55 |
| kyrofa | davidcalle, I assume so that you can use it in `source` URLs | 21:56 |
| davidcalle | kyrofa: got it, thanks | 21:59 |
| Pharaoh_Atem | zyga: why does classic mode depend specifically on /snap? | 22:02 |
| diddledan | thanks jdstrand | 22:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!