| ahoneybun | mhall119, do you have that geany snap around? | 00:40 |
|---|---|---|
| ahoneybun | I'm learning python and the book recommends it | 00:40 |
| ahoneybun | I'm trying to snap a lot of things away lol | 00:40 |
| liuxg | is docker supported on 16.04 core? | 03:30 |
| liuxg | does anyone know how to compile a armhf version of a snap? | 04:03 |
| mhall119 | ahoneybun: I have an amd64 binary if you want it | 04:19 |
| firstofthe300 | Hey guys | 05:03 |
| firstofthe300 | I am working on my first snap package | 05:03 |
| firstofthe300 | its a Mono app (please no flame...I didn't pick the language) | 05:03 |
| firstofthe300 | I don't see an xbuild plugin | 05:04 |
| firstofthe300 | anybody have an idea on how to get around that issue? | 05:04 |
| mup | PR snapd#1733 opened: interfaces: add lxd-support interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/1733> | 06:49 |
| mup | PR snapd#1720 closed: interfaces: add lxd-support interface <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1720> | 06:57 |
| mup | PR snapd#1732 closed: many: respect dirs.SnapSnapsDir in tests <Created by zyga> <Conflict> <https://github.com/snapcore/snapd/pull/1732> | 06:57 |
| mup | PR snapd#1734 opened: boot: add missing udevadm mock to fix FTBFS <Created by mvo5> <https://github.com/snapcore/snapd/pull/1734> | 07:14 |
| liuxg | lool, when I run the classic.create command on 16.04 desktop, I get the error like chroot: failed to run command '/var/lib/classic/enable.sh': No such file or directory, what could be the problem for it? http://paste.ubuntu.com/23084232/ | 07:15 |
| lool | liuxg: is this the classic snap from edge? | 07:17 |
| lool | liuxg: also, you need to sudo classic.create | 07:18 |
| liuxg | lool, yes, I installed it by using the command "sudo snap install --devmode --edge classic" on 16.04 | 07:18 |
| lool | liuxg: oh on 16.04 desktop? I'm not sure that's supported; I guess it could work there, but there might be bugs | 07:19 |
| liuxg | lool, in fact, I switched to root user, and I ran the command under root. | 07:19 |
| liuxg | lool, so, do you mean that it only works for arm devices? | 07:20 |
| lool | liuxg: it might only work on Ubuntu Core images | 07:20 |
| liuxg | lool, OK. I got it. thanks. After I run the classic.create, then follow by classic.shell. I can start to install the development env there, right? Sorry, I never did it before. I might need to get an arm device to have a try. | 07:21 |
| lool | liuxg: yes, you basically get a chroot where you can install stuff | 07:22 |
| lool | liuxg: it just wont start any services on boot or such | 07:22 |
| liuxg | lool, nice. I think this could be the easist way to cross compile. Many thanks for your help! | 07:22 |
| lool | liuxg: pleasure | 07:23 |
| mup | PR snapd#1734 closed: boot: add missing udevadm mock to fix FTBFS <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1734> | 07:41 |
| lool | elopio, ysionneau: I tried building a snapweb snap for armhf on a rpi3 running xenial, but I failed with: http://paste.ubuntu.com/23084299/ | 07:52 |
| lool | elopio: How had you built the amd64 one? | 07:52 |
| lool | I followed the README.md instructions | 07:53 |
| dz0ny | lool: phantomjs cannot run under arm | 07:54 |
| dz0ny | you have to manually compile phantomjs with specific patches | 07:55 |
| lool | dz0ny: argh | 07:55 |
| lool | dz0ny: oddly, we used to have builds for this, do you know which change caused this? and do you have a recipe for building phantomjs? O:-) | 07:55 |
| dz0ny | lool: https://github.com/ab77/beastcraft-telemetry/blob/master/grafana-armhf/README.md#build | 07:55 |
| dz0ny | this might help you | 07:55 |
| dz0ny | I was asking in mailing list of how people handle different architectures and building snaps | 07:57 |
| dz0ny | and no one replied | 07:57 |
| dz0ny | the problem is that you need totally different declaration for devices too | 07:57 |
| dz0ny | and snapcraft is not ready for that | 07:57 |
| lool | dz0ny: what do you mean for "declaration for devices"? | 07:58 |
| dz0ny | different paths, libs, patches etc | 07:58 |
| dz0ny | in snapcraft | 07:58 |
| dz0ny | yaml | 07:59 |
| lool | dz0ny: oh you mean for cross-building? | 07:59 |
| dz0ny | mhm | 07:59 |
| dz0ny | aka the snapcraft.yaml for ffmpeg on amd64 wont compile on arm | 07:59 |
| lool | I dont quite get the link with snapcraft; this is with the node plugin pulling deps, I dont believe snapcraft is aware of phantomjs specifically | 07:59 |
| lool | ah there's no way to express build differences between host arches in snapcraft.yaml | 08:00 |
| lool | indeed | 08:00 |
| dz0ny | because environment is different | 08:00 |
| lool | outside of your own plugins / upstream build system | 08:00 |
| dz0ny | mhm | 08:00 |
| lool | justinmcp_: heya | 08:01 |
| lool | justinmcp_: did you by any chance poke at snapweb recently? did you manage to build it for armhf? | 08:02 |
| lool | elopio: nevermind, saw your https://bugs.launchpad.net/snapweb/+bug/1616280 | 08:11 |
| mup | Bug #1616280: building on armhf fails because of phantomjs <snapweb:New> <https://launchpad.net/bugs/1616280> | 08:11 |
| mup | PR snapd#1714 closed: many: hook in start of code to fetch/check assertions when installing snap from store <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1714> | 08:16 |
| lool | dz0ny: unfortunately I couldn't find a corresponding libicui18n.so.48 to run the prebuilt phantomjs binary there :-/ | 08:20 |
| mup | PR snapd#1735 opened: tests: fixes to make the ubuntu-core-16 image usable with -keep/-reuse <Created by mvo5> <https://github.com/snapcore/snapd/pull/1735> | 08:26 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| liuxg | has anyone successfully booted raspberry pi2? I flashhed my raspberry 2 device at the instructions at https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ I cannot see the HDMI output | 09:09 |
| ogra | liuxg, there should definitely be a login prompt after a while ... boot output goes to serial though | 09:10 |
| liuxg | ogra, oh, my godness. I do not have a serial cable for it. | 09:11 |
| liuxg | ogra, so HDMI has no output, right? | 09:11 |
| ogra | HDMI has output | 09:11 |
| ogra | just no boot messages | 09:12 |
| liuxg | ogra, I connect it to my DELL monitor, there is no message at all. do you mean, I need to buy a serial cable for it? | 09:12 |
| ogra | oh, wait, you dont use a snappy image ? | 09:12 |
| * ogra just saw the link | 09:12 | |
| liuxg | ogra, I flashed it at https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ | 09:13 |
| ogra | right, i thought you run a snappy image ... the server image might not enable HDMI, not sure about that | 09:13 |
| liuxg | ogra, is that the ubuntu core image? or it is a just a classic ubuntu? | 09:13 |
| tvoss | niemeyer: o/ | 09:13 |
| ogra | the one described on that page is ubuntu server | 09:14 |
| ogra | http://people.canonical.com/~mvo/all-snaps/16/ has the experimental snappy images | 09:14 |
| liuxg | ogra, so, I can use the same instructions to flash the snappy image? | 09:14 |
| ogra | liuxg, i use: xzcat all-snaps-pi2.img.xz | sudo dd of=/dev/sdc bs=32M | 09:15 |
| ogra | (with sdc being my SD card reader) | 09:15 |
| liuxg | ogra, OK, many thanks for your help on this. I will flash my raspberry 2 device | 09:15 |
| mup | PR snapd#1736 opened: tests: port integration tests to spread <Created by mvo5> <https://github.com/snapcore/snapd/pull/1736> | 09:40 |
| ogra | zyga, if you put that behind something like a commandline option, sure, why not | 09:41 |
| ogra | (the initrd change) | 09:42 |
| mwhudson | mvo, zyga: Uploading snap-confine_1.0.40-1.dsc: done. | 10:04 |
| sergiusens | good morning | 10:05 |
| liuxg | ogra, I just flashed the snappy software, but I still do not see the output | 10:06 |
| mvo | mwhudson: yay, thank you - was the git repo of any help for you? | 10:06 |
| mwhudson | mvo: yes | 10:06 |
| ogra | liuxg, how long did you wait ? the fiirst boot can take a while | 10:06 |
| mwhudson | definitely | 10:06 |
| mwhudson | mvo: i sent a mail with details | 10:07 |
| liuxg | ogra, I waited for more than 10 mins | 10:07 |
| ogra | well, then you should see something (i surely do here) | 10:07 |
| liuxg | ogra, do you see it via the HDMI output? I connect it to the hdmi port of my DELL monitor | 10:08 |
| liuxg | ogra, if that is the case, how can I connect to it? using the ssh? | 10:08 |
| ogra | yes, after the boot is done i get a login prompt | 10:08 |
| ogra | (until that shows up it stays black though, since the boot output goes to serial, as i said) | 10:09 |
| ogra | if you know the IP you can just "ssh ubuntu@$IP" after it booted | 10:10 |
| liuxg | ogra, yeah, that could be problem for it. there is no more ouput, so the screen is black | 10:10 |
| ogra | well, all i can say is that iit works fine with the LG monitor i use here | 10:11 |
| ogra | for both, pi2 and 3 | 10:11 |
| liuxg | ogra, I do not know what is wrong here for the DELL monitor | 10:12 |
| ogra | do you perhaps switch the input via a menu on the monitor ? | 10:12 |
| ogra | *have to switch | 10:12 |
| liuxg | ogra, yes, I did that. it is hdmi 2 port | 10:12 |
| liuxg | ogra, anyway, I am now trying to boot it again. | 10:13 |
| ogra | liuxg, you could try to edit cmdline.txt on the system-boot partition of the SD and add "console=tty1" or some such to the cmdline | 10:14 |
| liuxg | ogra, if I do "console=tty1", I can still see it on the serial link, right? how to get it working on the HDMI port? | 10:15 |
| ogra | no, tty1 should switch it to the HDMI port | 10:16 |
| ogra | (or might be tty0 ... i forgot ... if 1 doesnt work, try 0) | 10:16 |
| liuxg | ogra, thanks. I will try that. | 10:17 |
| liuxg | ogra, I just tried to login using the ssh. I connected it to my router, and it worked for me. | 10:18 |
| ogra | ah, good | 10:19 |
| liuxg | ogra, there is no output yet :) anyway, at least, I can try sth. | 10:19 |
| ogra | liuxg, journalctl -b should show the boot log | 10:21 |
| ogra | there should be a line like: "Started Getty on tty1" | 10:21 |
| ogra | right before "Reached target Login Prompts." | 10:22 |
| ogra | if you see that both, then i'd guess there is a hardware issue (cable, monitor setup etc) | 10:22 |
| zyga | slangasek: hey, thanks :) | 10:23 |
| liuxg | ogra, http://paste.ubuntu.com/23084694/, this is the output. do you mean we need to set it to tty0? | 10:23 |
| ogra | no, it tells you it starts a getty so there is a login promppt ... tty1 should be fine | 10:23 |
| ogra | ubuntu@pi3:~$ ps ax|grep getty | 10:24 |
| ogra | 2920 ttyS0 Ss+ 0:00 /sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt220 | 10:24 |
| ogra | 2921 tty1 Ss+ 0:00 /sbin/agetty --noclear tty1 linux | 10:24 |
| ogra | if you see that, then there is definitely a login prompt ... and i'd say there is something with the cable or monitor | 10:24 |
| liuxg | ogra, OK. I got it. I see it like http://paste.ubuntu.com/23084702/ | 10:25 |
| zyga | slangasek: if you are around, how can I help you to accept latest SRU into xenial-updates? | 10:25 |
| ogra | yeah | 10:25 |
| ogra | check the cable, check the monitor again ... | 10:25 |
| ogra | from a software POV everything is there | 10:25 |
| liuxg | ogra, do you think whether I need to change it to tty0 to have a try? | 10:27 |
| ogra | no, i doubt that will change anything ... (but you can indeed try :) ) | 10:28 |
| === hikiko is now known as hikiko|ln | ||
| zyga | ogra: good, I know a lot of people that could use this | 10:44 |
| zyga | mwhudson: thanks for the release! | 10:44 |
| ogra | zyga, https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial ... make a debdiff against initramfs-tools-ubuntu-core from there and show it to mvo or me | 10:46 |
| ogra | cyphermox, why is there a subiquity in the image build PPA ^^ ? | 10:47 |
| zyga | ogra: thanks, I'll try | 10:47 |
| ogra | (and what is probert ) | 10:48 |
| mwhudson | zyga: np | 10:48 |
| ogra | cyphermox, note that this PPA is for image content ... | 10:48 |
| mwhudson | ogra: src:subiquity builds console-conf | 10:48 |
| ogra | console-conf ? | 10:48 |
| mwhudson | the first boot configurator thing | 10:49 |
| ogra | mwhudson, we dont seed subiquity ... there are more and more packages showing up in that PPA that are not inside the image | 10:49 |
| mwhudson | console-conf and probert will be inside the image soon | 10:49 |
| ogra | ah, k | 10:49 |
| ogra | mwhudson, but they will be SRUed once they are ready ? | 10:50 |
| mwhudson | yeah | 10:50 |
| ogra | (long term plan is to get rid of most stuff in that PPA before GA release= | 10:50 |
| ogra | ) | 10:50 |
| ogra | preferably of everything ... :) | 10:50 |
| mwhudson | new packages so not much chance of regression ;-) | 10:51 |
| ogra | yeah | 10:51 |
| ogra | well, it adds a new feature that replaces an existing one i guess ... so there is chance of regression | 10:51 |
| ogra | but thats fine in the edge channel | 10:51 |
| mwhudson | i'm finding that i can only boot an all-snaps image in qemu once | 10:51 |
| mwhudson | if i boot it again, it can't find partitions | 10:52 |
| ogra | using the vvery latest image from mvo ? | 10:52 |
| mwhudson | no | 10:52 |
| ogra | aha | 10:52 |
| mwhudson | using an image i made from bits i got out of some image from mvo last week i guess | 10:52 |
| ogra | there were some fixes on friday ... | 10:53 |
| mwhudson | ok | 10:55 |
| ogra | (and also a new u-d-f iirc) | 10:56 |
| mup | PR snapd#1737 opened: tests: update listing test for latest stable image <Created by mvo5> <https://github.com/snapcore/snapd/pull/1737> | 10:58 |
| ogra | mwhudson, i just did 5 reboots with that image, no issues here | 10:59 |
| mwhudson | ogra: ok, i'll grab the newest bits tomorrow then | 10:59 |
| ogra | (apart from the known "no eth0" one) | 10:59 |
| mwhudson | still from http://people.canonical.com/~mvo/all-snaps/16/ ? | 11:00 |
| ogra | yep | 11:00 |
| mwhudson | talking of the no eth0 thing... | 11:01 |
| * mwhudson makes some comments on a PR | 11:01 | |
| ogra | :) | 11:01 |
| === hikiko|ln is now known as hikiko | ||
| ogra | i dont see that issue on rpi | 11:01 |
| ogra | it even gets its weird enxb827ebc92b03 device name and still works | 11:01 |
| cyphermox | ogra: right, like mwhudson said | 11:06 |
| ogra | yeah, all fine then | 11:07 |
| mwhudson | oh god cyphermox is awake, time for bed! | 11:07 |
| ogra | haha | 11:07 |
| cyphermox | hehe :) | 11:07 |
| mvo | ogra: do you think you could make /etc/systemd/{user,system}.conf.d/ available via the ubuntu-core snap as writable directories? this is something for the plano people that they really need urgently | 11:14 |
| ogra | mvo, sure, why not | 11:15 |
| ogra | just needs to be added to writagble-paths | 11:15 |
| mvo | ogra: and I think we need to add the dirs to the image via livecd-rootfs, it appears to be missing | 11:19 |
| mup | PR snapd#1737 closed: tests: update listing test for latest stable image <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1737> | 11:19 |
| ogra | mvo, hmm, why does systemd not create them ? | 11:20 |
| ogra | (can it actually handle these dirs if it doesnt actually create them ?) | 11:21 |
| ogra | (i would expect the package to create them if it can process content from there) | 11:21 |
| mup | PR snapd#1738 opened: tests: the stable ubuntu-core snap has snap run support now <Created by mvo5> <https://github.com/snapcore/snapd/pull/1738> | 11:23 |
| * mvo lunch | 11:25 | |
| liuxg | ogra, I just installed hello and hello-world examples into my raspberry pi 2 device, when I run the apps, I get error like "mkdir: cannot create directory '/home/ubuntu/snap/hello': Permission denied". what could be the problem for it? http://paste.ubuntu.com/23084828/ thanks | 11:32 |
| zyga | liuxg: which version of snap-confine that system has? | 11:34 |
| zyga | liuxg: can you see any apparmor denials? | 11:34 |
| liuxg | zyga, if I use "sudo", it is fine http://paste.ubuntu.com/23084831/ | 11:35 |
| ogra | zyga, i guess he uses mvo's image ... so whatever was the snap-confine in the image build PPA on friday | 11:35 |
| ogra | (not sure why that package is still in the PPA) | 11:35 |
| liuxg | zyga, yes, I took the software from http://people.canonical.com/~mvo/all-snaps/16/ | 11:36 |
| liuxg | ogra, to my best understanding, we should not use the "sudo" to get it running, right? | 11:37 |
| ogra | ubuntu@pi3:~$ sudo snap install hello-world | 11:37 |
| ogra | hello-world (stable) 6.3 from 'canonical' installed | 11:37 |
| ogra | ubuntu@pi3:~$ hello-world.env | 11:37 |
| ogra | mkdir: cannot create directory ‘/home/ubuntu/snap/hello-world’: Permission denied | 11:37 |
| ogra | ubuntu@pi3:~$ | 11:37 |
| ogra | i get the same here | 11:37 |
| ogra | ubuntu@pi3:~$ ls -l /home/ubuntu/ | 11:38 |
| ogra | total 4 | 11:38 |
| ogra | drwxr-xr-x 3 root root 4096 Aug 23 11:49 snap | 11:38 |
| ogra | aha | 11:38 |
| ogra | that definitely workd yesterday | 11:38 |
| * zyga looks | 11:39 | |
| liuxg | ogra, is there anything broken? | 11:39 |
| zyga | liuxg: any DAC ownership along the way? | 11:39 |
| zyga | liuxg: I mean anything like a root-owned directory in the way? | 11:39 |
| liuxg | zyga, I do not quite understand what you mean, sorry | 11:40 |
| zyga | liuxg: any apparmor denials? | 11:40 |
| zyga | liuxg: I meant to ask if anything along /home/ubuntu/snap/hello-world is owned by root | 11:40 |
| zyga | liuxg: can you also run the same command without sudo but with SNAP_CONFINE_DEBUG=1 set | 11:40 |
| liuxg | zyga, http://paste.ubuntu.com/23084841/ | 11:41 |
| liuxg | zyga, where should I change that variable? in the command line? | 11:41 |
| zyga | liuxg: just an environment variable | 11:42 |
| zyga | export SNAP_CONFINE_DEBUG=1 should do it | 11:42 |
| zyga | that may be the problem | 11:42 |
| liuxg | zyga, yes, this time, it is right. | 11:42 |
| zyga | chown everything in $HOME/snap | 11:42 |
| zyga | liuxg: and see if this occurs again | 11:42 |
| liuxg | zyga, to "ubuntu" user? | 11:43 |
| zyga | yes | 11:43 |
| liuxg | zyga, do I need to set the SNAP_CONFINE_DEBUG=1 to 0 again? | 11:46 |
| zyga | liuxg: it's just temporary, you can unset it, it doesn't hurt | 11:46 |
| liuxg | zyga, yes, now, it works. | 11:48 |
| ogra | zyga, see my paste above | 11:48 |
| ogra | $HOME/snap is root.root | 11:48 |
| zyga | ogra: that's not correct | 11:48 |
| zyga | ogra: is that reproducible? | 11:48 |
| ogra | zyga, no, and it worked yesterday | 11:48 |
| liuxg | zyga, is this a bug in the image? | 11:49 |
| zyga | I don't know yet | 11:49 |
| zyga | can anyone with an image rm -rf $HOME/snap and run hello world without sudo | 11:49 |
| zyga | and see what happens | 11:49 |
| ogra | i never ran hello-world with sudo | 11:50 |
| ogra | yet the dir is root owned | 11:50 |
| ogra | though i dont know if it was like that before i installed hello-world | 11:50 |
| zyga | ogra: it could be snap-confine itself, it runs as root, | 11:50 |
| zyga | ogra: can you do a quick test as I've described? | 11:50 |
| ogra | zyga, works fine | 11:51 |
| liuxg | ogra, after I use classic to build my snap app, where can I find the .snap file? is it in the $HOME directory somewhere? | 11:51 |
| zyga | ogra: ok, uff, that's not bad then | 11:51 |
| ogra | liuxg, in the dir you ran snapcraft | 11:51 |
| liuxg | ogra, after I exit the class, I need to install it under snap instead of being in classic, right? | 11:52 |
| liuxg | ogra, can I just do installation there like "sudo snap install *.snap" under that folder? | 11:52 |
| ogra | liuxg, the home dir is shared between classic and non-classic ... | 11:52 |
| zyga | liuxg: perhaps it would work from classic, as long as you can access the socket | 11:52 |
| zyga | liuxg: you can give it a try | 11:52 |
| ogra | you should just find your snap in your home if you built it there | 11:52 |
| cpaelzer | trying to transition from copy to dump plugin - I haven't found a single place describing that. I formerly used copy+files to rename-and-install files that the native build system of the project didn't add. Trying to rebuild that function with dump+organize now - are there known examples for that to take a look at? | 11:53 |
| cpaelzer | wow that was more text than I thougth when typing :-/ | 11:53 |
| liuxg | ogra, yes, you are right. thanks | 11:53 |
| cpaelzer | hmm, might even work with nil plugin since I might only need organize ... | 11:56 |
| cpaelzer | anyway I'll trial and error through that, but if one has a nice pointer to a collection of examples using dump (other than the tomcat maven demo) that would be nice | 11:57 |
| ogra | zyga, very weird, i cant get it into that state anymore | 11:58 |
| === chihchun is now known as chihchun_afk | ||
| ogra | cpaelzer, you need to add "source: ." | 12:04 |
| ogra | and rename "files:" to "filesets:" | 12:04 |
| ogra | at keast that worked for me | 12:05 |
| cpaelzer | ogra: I had added source . (and similar things) but it always complained about stuff not being a directory and/or not being around at install stage | 12:05 |
| cpaelzer | ogra: but I'll give it a try once more | 12:05 |
| cpaelzer | and afaik the filesets do not have the renaming part I need | 12:06 |
| cpaelzer | that would be organize and that is what breaks on the "has to be in the install stage" | 12:06 |
| ogra | cpaelzer, https://github.com/ogra1/classic-snap/blob/master/snapcraft.yaml | 12:07 |
| cpaelzer | hrm, really - ok :-) that seems easier | 12:08 |
| ogra | https://github.com/ogra1/classic-snap/commit/f467a6634cdc2e43e496eaaf9d12616aae29bf6c | 12:08 |
| ogra | thats the change i did to go from copy to dump | 12:08 |
| ogra | (ignore architecture and version) | 12:08 |
| cpaelzer | ogra: your example is nice although IMHO it doesn't match filesets as documented in docs/snapcraft-parts.md and docs/snapcraft-syntax.md | 12:14 |
| cpaelzer | my issue really seems to be that the "renaming" has to be done on install stage | 12:14 |
| ogra | well, i was lazy :) | 12:15 |
| cpaelzer | ogra: your example did bin/*: bin | 12:15 |
| ogra | it worked, so i left it as is | 12:15 |
| cpaelzer | bin/* afaik is only the identifier and you never refer to it :-) | 12:15 |
| cpaelzer | I can't use that to rename | 12:15 |
| ogra | yeah, i copy bin/* to bin/ after all | 12:15 |
| ogra | without name changes | 12:15 |
| cpaelzer | if I'm right your line could be "foobar: bin" and still work | 12:16 |
| mup | PR snapd#1732 closed: many: respect dirs.SnapSnapsDir in tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1732> | 12:17 |
| cpaelzer | yep, foo: bin does just the same | 12:17 |
| cpaelzer | fyi that is the way it had to be written for the copy plugin in my case https://gitlab.com/paelzer/ntpsec/blob/snapify-ntpsec/snapcraft.yaml | 12:23 |
| cpaelzer | TL;DR the two copy sections did: "take file from local tree and place in snap under different name" | 12:23 |
| cpaelzer | still struggling to recreate that with dump and/or nil plugin | 12:24 |
| ogra | right, not sure how you do a rename ... ask kyrofa or sergiuens | 12:24 |
| cpaelzer | sergiusens: kyrofa: ^^ | 12:27 |
| kyrofa | cpaelzer, it depends upon the way the filesystem looks when the copy occurs | 12:57 |
| mup | PR snapd#1739 opened: cmd/snap: use UserDataDir and UserCommonDataDir <Created by zyga> <https://github.com/snapcore/snapd/pull/1739> | 12:57 |
| kyrofa | cpaelzer, it was written to try and mimic `cp` as much as possible, with the exception that `foo: bin/` (note the trailing slash) will create the bin/ dir | 12:57 |
| cpaelzer | kyrofa: hi, I just gave up a few minutes ago and filed bug 1616459 which summarizes it much better | 12:58 |
| mup | Bug #1616459: dump plugin not a full super-set to the now deprecated copy plugin <Snapcraft:New> <https://launchpad.net/bugs/1616459> | 12:58 |
| cpaelzer | kyrofa: if you could take a look there and advise that would be great | 12:58 |
| kyrofa | Sure thing | 12:58 |
| mup | PR snapd#1740 opened: many: respect SnapMountDir in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1740> | 13:00 |
| mup | PR snapd#1741 opened: firstboot: do not use absolute /sbin/udevadm in firstboot.go <Created by mvo5> <https://github.com/snapcore/snapd/pull/1741> | 13:01 |
| mup | PR snapd#1741 closed: firstboot: do not use absolute /sbin/udevadm in firstboot.go <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1741> | 13:04 |
| zyga | slangasek: ping, what's the status of snap-confine SRU | 13:16 |
| mup | PR snapd#1739 closed: cmd/snap: use UserDataDir and UserCommonDataDir <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1739> | 13:21 |
| mup | PR snapd#1739 closed: cmd/snap: use UserDataDir and UserCommonDataDir <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1739> | 13:21 |
| mup | PR snapd#1742 opened: firstboot: properly mock udevadm <Created by mvo5> <https://github.com/snapcore/snapd/pull/1742> | 13:23 |
| mup | PR snapd#1742 closed: firstboot: properly mock udevadm <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1742> | 13:28 |
| jcastro | mvo: is snap-confine released into distro at a cadence or ad-hoc? I'm asking because the juju team would like 1.0.40, which has a bugfix for allowing us to use lxd with snapped Juju. | 13:31 |
| kyrofa | jdstrand, hey, remember the new snapd socket we discussed yesterday? | 13:32 |
| kyrofa | jdstrand, through trial and error, it seems these are the profile changes necessary to make use of it: http://pastebin.ubuntu.com/23085069/ . Can you give me your thoughts when you're able? | 13:34 |
| jdstrand | kyrofa: hey, yes | 13:34 |
| jdstrand | kyrofa: looks totally fine except please use @{PROC} instead of /proc | 13:35 |
| kyrofa | jdstrand, ah, wonderful! It was a few more things than I was hoping, so I'm glad it looks okay | 13:36 |
| mup | PR snapd#1743 opened: many: use StripGlobalRootDir and respect SnapMountDir <Created by zyga> <https://github.com/snapcore/snapd/pull/1743> | 13:40 |
| kyrofa | Hey nessita, it looks like https://myapps.developer.ubuntu.com/dev/click-apps/register-name-dispute has been removed? Does it have a replacement by any chance? We try to point people in the right direction from snapcraft | 13:45 |
| kyrofa | But doing it online, it seems all ajaxy | 13:45 |
| nessita | kyrofa, hum, let me check... did you ask sergiusens? I think he had some info | 13:46 |
| nessita | but I can check nevertheless | 13:46 |
| kyrofa | nessita, no, I don't believe he's around just yet | 13:46 |
| nessita | kyrofa, is my understanding that filing a dispute ocurrs now in the same URL as name registration https://myapps.developer.ubuntu.com/dev/click-apps/register-name/ | 13:47 |
| zyga | jdstrand: lately ad-hoc because SRU was bumpy | 13:47 |
| zyga | jdstrand: it is supposed to be co-released with snapd | 13:48 |
| nessita | kyrofa, it requires a submission and then you can file the dispute | 13:48 |
| zyga | jdstrand: the plan is to get current SRU out, then do small SRU with just a few patches for apparmor and then a big SRU with all of 1.0.40 or .41 | 13:48 |
| kyrofa | nessita, hmm. So there's no URL to which we can direct people? What do we envision happening within snapcraft? | 13:49 |
| jdstrand | zyga: I'm not sure what question I asked but glad to hear the answer :) | 13:50 |
| jdstrand | jcastro: see zyga's response to me :) | 13:50 |
| nessita | kyrofa, why do you say we have no URL? the URL is https://myapps.developer.ubuntu.com/dev/click-apps/register-name/ and this was arranged after a bug report, let me find it | 13:51 |
| kyrofa | nessita, ah, so just direct people to that URL and say "try to register it again" essentially? | 13:51 |
| kyrofa | That works | 13:52 |
| nessita | kyrofa, right | 13:52 |
| mup | PR snapd#1744 opened: snap: use "up to date" instead of "up-to-date" <Created by mvo5> <https://github.com/snapcore/snapd/pull/1744> | 13:52 |
| kyrofa | nessita, okay great, thank you! | 13:52 |
| nessita | kyrofa, I will confirm 100% when fgallina is here | 13:52 |
| nessita | kyrofa, he can give you the exact URL | 13:53 |
| kyrofa | nessita, I appreciate it :) | 13:53 |
| morphis | niemeyer, zyga: it would be awesome if you can comment on https://github.com/snapcore/snapd/pull/1669 | 13:54 |
| mup | PR snapd#1669: interface: add usb device support to serial-port <Created by jocave> <https://github.com/snapcore/snapd/pull/1669> | 13:54 |
| morphis | niemeyer, zyga: would like to get that discussion unblocked | 13:54 |
| morphis | jdstrand, joc_: ^^ | 13:55 |
| mup | PR snapd#1745 opened: overlord/snapstate: respect SnapMountDir in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1745> | 13:56 |
| zyga | jdstrand: the one to mvo about snap confine sru | 13:57 |
| zyga | jdstrand: ahh, that was jcastro ! | 13:58 |
| zyga | sorry :) | 13:58 |
| jcastro | zyga: excellent, thanks! | 13:58 |
| zyga | morphis: looking | 13:59 |
| niemeyer | morphis: What's the issue there? | 13:59 |
| morphis | niemeyer, zyga: see jdstrand's comment | 14:00 |
| niemeyer | morphis: I have a meeting soon and cannot go over this whole thread right now, but can discuss a particular aspect quickly if that's helpful | 14:00 |
| morphis | niemeyer, zyga: more or less jdstrand wanted your sign off on this | 14:00 |
| morphis | to make this future ready | 14:00 |
| niemeyer | morphis: What is "this"? | 14:00 |
| morphis | the way we're modifying the serial-port interface | 14:01 |
| morphis | niemeyer: its fine if you comment later today | 14:01 |
| niemeyer | morphis: What is the urgency of this issue? | 14:01 |
| morphis | niemeyer: RTM :-) | 14:02 |
| niemeyer | morphis: I see non-trivial topics being covered there, such as hot-plugging of devices, which we most likely cannot address for RTM | 14:02 |
| niemeyer | or GA, for that matter | 14:02 |
| niemeyer | morphis: Those will indeed require some careful design that we don't have the bandwidth for right now | 14:02 |
| morphis | niemeyer: hotplug etc. isn't supposed to be done with this, but jdstrand wanted the current implementation to no be broken when we add sth like hotplug in the future | 14:02 |
| morphis | niemeyer: we don't want to discuss hotplug, we're ok with a static implementation which joc_ implemented | 14:03 |
| morphis | niemeyer: jdstrand just wants your sign-off on that to make sure what we've implemented is in line with possible thoughts around a future hotplug solution | 14:03 |
| niemeyer | morphis: What is the urgency of this issue? I thought we had sorted a basic serial-port that should work for now? | 14:04 |
| morphis | niemeyer: exactly, we have it sorted and the impl is there | 14:04 |
| sergiusens | kyrofa nessita yes it has been removed and I talked to cprov about it, I silently fixed it without complaining | 14:04 |
| morphis | but still jdstrand wanted you or zyga to comment | 14:04 |
| niemeyer | morphis: Ok, so why do we need the PR? | 14:05 |
| morphis | so, this is the reimplementation of the zigbee interface | 14:05 |
| kyrofa | sergiusens, ah, so is bug #1616471 already fixed? | 14:05 |
| mup | Bug #1616471: URL for name takeover is incorrect <Snapcraft:Triaged> <https://launchpad.net/bugs/1616471> | 14:05 |
| lool | elopio: I've disabled the karma-phantomjs dep and the build proceeds a bit but it fails with: /tmp/tmpc2celh4b: 4: exec: /home/ubuntu/go/src/github.com/snapcore/snapweb/parts/assets/npm/bin/gulp: not found | 14:05 |
| lool | Command '['/bin/sh', '/tmp/tmpc2celh4b', '/home/ubuntu/go/src/github.com/snapcore/snapweb/parts/assets/npm/bin/gulp', 'install']' returned non-zero exit status 127 | 14:05 |
| morphis | niemeyer: which had the approach of assingning a particular device via pid/vid to the device cgroup of the snap | 14:05 |
| lool | elopio: despite gulp being installed for my user | 14:05 |
| sergiusens | kyrofa this just means you need to pay more attention during standups ;-) | 14:05 |
| lool | elopio: would you know how to fix this one? | 14:06 |
| nessita | sergiusens, fabian is about to contact you, he was not aware of the breakage, he is about to add a redirect | 14:06 |
| lool | justinmcp_: around? | 14:06 |
| sergiusens | nessita it is all fine | 14:06 |
| morphis | niemeyer: as in the end it still just allows access to a serial port we agreed in the discussion with jdstrand that this should be added to the serial-port interface | 14:06 |
| sergiusens | nessita 2.15 is in xenial-updates already, don't waste time on this | 14:06 |
| niemeyer | morphis: What we discussed before and is merged uses a path, not pid/vid | 14:06 |
| niemeyer | morphis: This is already landed | 14:06 |
| niemeyer | morphis: Why do we need something else right now? | 14:06 |
| kyrofa | sergiusens, haha, that was days ago! | 14:07 |
| morphis | no, not what we discussed for quite a long time for USB based tty for zigbee support | 14:07 |
| morphis | that is what we want to add here | 14:07 |
| morphis | as there are zigbee usb dongles we need to support with RTM | 14:07 |
| morphis | and as you said, real hotplug support is past RTM/GA we need a interim solution for that | 14:07 |
| morphis | and that is the PID/VID based device-cgroup thing | 14:08 |
| kyrofa | sergiusens, anyway, sorry for not catching that. Thanks for chiming in :) | 14:08 |
| niemeyer | morphis: Yes, and I thougth the interim solution was already merged | 14:09 |
| niemeyer | morphis: Why does it not work? | 14:09 |
| morphis | niemeyer: it works :-) | 14:09 |
| niemeyer | morphis: Ok, so we don't the the PR..? | 14:09 |
| niemeyer | need the | 14:09 |
| morphis | we need it as the iterim solution isn't merged yet | 14:09 |
| morphis | so that PR is the interim solution | 14:09 |
| niemeyer | morphis: We're going in circles.. I'm asking what seems to be like a simple question: we have a serial-port interface today, which we discussed and I assumed it would solve your problems. Why is that code not enough for you what you need for GA? | 14:11 |
| morphis | niemeyer: ok, lets go over it step by step: | 14:12 |
| morphis | we have serial port which allows path based access to serial nodes in the system | 14:12 |
| morphis | all ok, works fine | 14:12 |
| morphis | but it doesn't solves the problem of hotpluged usb devices which create new tty's | 14:12 |
| morphis | that is why we came up with the VID/PID attributes for the interface based approach | 14:13 |
| morphis | we had that first in an interface named 'zigbee' | 14:13 |
| morphis | but then in a discussion with jdstrand and joc_ we came to the conclusion that it makes more sense in the existing serial port interface | 14:13 |
| morphis | that implementation is now what is in https://github.com/snapcore/snapd/pull/1669 | 14:14 |
| mup | PR snapd#1669: interface: add usb device support to serial-port <Blocked> <Created by jocave> <https://github.com/snapcore/snapd/pull/1669> | 14:14 |
| morphis | that is all fine, satisfies our needs for RTM | 14:14 |
| niemeyer | morphis: Why do we need to support hotplugging right now? | 14:15 |
| jdstrand | niemeyer: to be clear. the serial-port as implemented wasn't meeting morphis' and co's needs. they had a meeting with me on how to move forward and we discussed. I said to implement it as a PR but that it would need sign-off from the interfaces team to make sure it fit with future plans. In the PR comment, I tried to give thoughts on reconciling the PR's approach with possible future plans | 14:15 |
| morphis | niemeyer: as we have a specific product which requires this | 14:15 |
| jdstrand | niemeyer: afaic, we don't need to completely flesh out the future plans, but wanted to make sure we thought about where we were going before landing what is in the PR | 14:16 |
| jhobbs | does 'snap' respect http_proxy and https_proxy? | 14:16 |
| niemeyer | morphis: Of course.. many things are being attributed as dependencies of a product, but this is a technical question | 14:17 |
| niemeyer | morphis: We didn't discuss hot-plugging of devices in the last sprint, or anytime recently.. so it's a bit of an issue to have it in the roadmap days before freeze | 14:17 |
| morphis | niemeyer: we're discussing this since beginng of june | 14:19 |
| morphis | niemeyer: see https://github.com/snapcore/snapd/pull/1405 | 14:19 |
| niemeyer | morphis: So I'm trying to get down to the details: the fact you want a specific device to work, which likely has a specific vendor ID and product ID, implies it can also have a specific path in the filesystem | 14:19 |
| mup | PR snapd#1405: interfaces: add zigbee-dongle interface <Reviewed> <Created by jocave> <Closed by jocave> <https://github.com/snapcore/snapd/pull/1405> | 14:19 |
| ahasenack | is "snappy" in ubuntu-core the same as "snap" in ubuntu? | 14:19 |
| ahasenack | or is snappy some older version before a rename took place? | 14:20 |
| niemeyer | morphis: I'm discussing that sort of issue since early last year.. I'm pointing out we do not have hot-plugging of devices in the roadmap, which I hope you can understand and agree | 14:20 |
| zyga | ahasenack: conceptucally yes | 14:20 |
| morphis | niemeyer: absolutely, that is why we all agreed on having the PID/VID approach | 14:20 |
| morphis | to have a interim solution which covers a very specific use case | 14:20 |
| niemeyer | morphis: Yep, so.. VID+PID means a fixed device.. means a fixed path.. means the current serial-port interface works | 14:20 |
| jdstrand | niemeyer: the problem with the zigbee dongle interface was that it was too-specific. morphis can correct me, but this device is not at all common, and there may be other not at all common devices out there for products, so having an interface for every no at all common device that for all intents and purposes is a serial port seemed not the right approach | 14:21 |
| morphis | niemeyer: having a fixed device path requires a udev rule and we need an interface to put that in place .. | 14:21 |
| niemeyer | morphis: The "interim solution" is not a magic thing.. we cannot bolt down such a major feature with no design consideration | 14:21 |
| niemeyer | jdstrand: Yes, what I'm suggesting is not hot-plugging | 14:22 |
| niemeyer | jdstrand: Which is exaclty the point I'm making.. we're not going to have hot-plugging of devices on this GA | 14:22 |
| * jdstrand notes this is why we wanted to have the discussion with the interfaces team before committing :) | 14:23 | |
| morphis | niemeyer: then we can really go back and hardware the vid/pid in the interface code and name that interface 'zigbee' again | 14:23 |
| morphis | s/hardware/hardcode/ | 14:23 |
| jdstrand | well, it sounds like that PR might then be a springboard for a future discussion, but that leaves zigbee | 14:23 |
| niemeyer | morphis: Yes, and we discussed quite a bit those UDEV rules, right? | 14:23 |
| niemeyer | morphis: You changed the approach completely on this PR | 14:24 |
| morphis | sure, we fixed the udev backend especially for this | 14:24 |
| niemeyer | jdstrand: thanks for raising this | 14:24 |
| jdstrand | niemeyer: note that morphis didn't do that on his own. we had a long hangout to come up with this. zigbee is a serial-port | 14:24 |
| niemeyer | jdstrand: zigbee _has_ a serial port | 14:25 |
| jdstrand | I would prefer if we are going to hardcode, perhaps we take a different approach | 14:25 |
| jdstrand | maybe add a different attribute to the serial-port interface. eg, type=zigbee | 14:25 |
| jdstrand | then we hardcode in the interface what that ends up as | 14:26 |
| niemeyer | jdstrand: Not much benefit | 14:26 |
| jdstrand | rather than a new interface called zigbee-dongle | 14:26 |
| jdstrand | I am very wary of interface clutter | 14:26 |
| niemeyer | jdstrand: Well, some benefit actually | 14:26 |
| jdstrand | zigbee just isn't used a lot, aiui (morphis please correct me) | 14:27 |
| niemeyer | jdstrand: It has the benefit of allowing other serial ports to be used, at the cost of not being able to tell whether a particular device is a zigbee dongle or not, and thus connect things that do not work | 14:27 |
| jdstrand | right | 14:27 |
| niemeyer | jdstrand: that's not super important in this case | 14:27 |
| niemeyer | jdstrand: (the fact it's not used a lot) | 14:27 |
| jdstrand | but it also reduces clutter | 14:27 |
| jdstrand | and at least keeps the changes in the interface where hotplugging would happen | 14:27 |
| niemeyer | jdstrand: we shouldn't add or not add interfaces just based on the number of devices shipping with them.. there are other considerations which are more important on that decision making | 14:28 |
| jdstrand | a problem with android for developers has always been that the perms were too confusing | 14:28 |
| jdstrand | I'm not saying it is the only consideration. I'm sayingit is a consideration on where its support lies | 14:28 |
| jdstrand | a new interface is a bigger thing than an attribute in an existing | 14:29 |
| jdstrand | but, most importantly, this zigbee dongle (again, aiui) is a serial port | 14:29 |
| niemeyer | morphis, jdstrand: We have a team meeting now.. | 14:29 |
| jdstrand | and we know we want to hot plug serial ports of all kinds in the future | 14:29 |
| jdstrand | and we can assume there will be other serial ports like zigbee | 14:30 |
| niemeyer | morphis, jdstrand: Thanks for those details.. I'll go through the whole PR today, think about the possibilities given what we just discussed above, and come back to you | 14:30 |
| morphis | niemeyer: thanks! | 14:30 |
| jdstrand | so grouping these serial port things into serial-port interface makes sense to me | 14:30 |
| morphis | niemeyer: I am open to what ever you come up with, as long as we can support the given use case | 14:30 |
| niemeyer | morphis: The use case is a zigbee USB dongle, to be clear, right? | 14:31 |
| morphis | niemeyer: yes | 14:31 |
| niemeyer | morphis: Ack, thanks | 14:31 |
| * ogra shakes fist at googl | 14:33 | |
| ogra | e | 14:33 |
| joc_ | niemeyer: note i also have the hidraw PR open which is (fairly) marked as blocked by the serial-port PR - it uses excatly the same approach just for a different device subsystem | 14:33 |
| joc_ | just in case that provides another angle to the review | 14:34 |
| joc_ | sergiusens: josepht: i notice that using filesets on parts in SPS doesnt work (filed a bug earlier), $variables don't get expanded, is that a known problem? | 14:37 |
| * jdstrand -> errands and lunch | 14:46 | |
| josepht | joc_: not that I'm aware of. We'll take a look. | 14:47 |
| mup | PR snapd#1746 opened: many: have AuthContext expose device store-id, serial and serial-proof signing to the store <Created by pedronis> <https://github.com/snapcore/snapd/pull/1746> | 14:51 |
| mup | PR snapd#1747 opened: Collect attr hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/1747> | 14:54 |
| dbarth | hey there, i'm trying to install a new build of snapweb in a kvm snappy instance, but it fails when looking up the snap package.yaml | 14:56 |
| morphis | niemeyer: please take joc_'s comment in account, the hidraw interface covers exactly the same problem | 14:57 |
| dbarth | the snap has a snap.yaml instead; which component(s) do i need to i need to put in sync? | 14:58 |
| kyrofa | dbarth, try installing snapweb from edge | 14:59 |
| kyrofa | dbarth, oh wait, are you using 15.04? | 14:59 |
| dbarth | yeah, old one | 14:59 |
| dbarth | that's probably the issue | 14:59 |
| jgdx | any way to do a rebuild of one part and have e.g. prime updated with the new build of that part? | 14:59 |
| kyrofa | jgdx, you can use `snapcraft clean <part>` or even `snapcraft clean <part> -s build` if you just want to rebuild that part | 15:00 |
| kyrofa | jgdx, then run `snapcraft` again | 15:00 |
| jgdx | kyrofa, neat, thanks | 15:01 |
| dbarth | kyrofa: i guess i'll go with mvo's latest images | 15:02 |
| kyrofa | dbarth, what device are you using? | 15:02 |
| dbarth | mostly a kvm, i have a pi2 and pi3 around if that's better | 15:02 |
| kyrofa | dbarth, no that's fine, though you know you can use snaps on normal ubuntu as well? | 15:03 |
| kyrofa | dbarth, if you want an all-snap image though, yeah, use mvo's | 15:04 |
| dbarth | kyrofa: sure ;) but i'd rather stay on the kvm for now | 15:04 |
| mup | PR snapcraft#619 closed: Add source-checksum option <Created by tsimonq2> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/619> | 15:05 |
| mup | PR snapcraft#661 closed: Added a test Jenkinsfile <Created by elopio> <https://github.com/snapcore/snapcraft/pull/661> | 15:05 |
| sergiusens | joc_ it is known now ;-) | 15:08 |
| mup | PR snapd#1748 opened: Basic support for validation assertion <Created by ralsina> <Conflict> <https://github.com/snapcore/snapd/pull/1748> | 15:08 |
| joc_ | sergiusens: good :) | 15:09 |
| joc_ | sergiusens: out of interest, are there any tests run which build snaps from parts in sps? | 15:09 |
| sergiusens | joc_ first another question, wth is sps? :-) | 15:10 |
| joc_ | sergiusens: hehe i was told that's the official name of the parts service thingy | 15:10 |
| sergiusens | joc_ oh, I hope it isn't; SPI was a bad name already and it has been killed ;-) | 15:11 |
| natefinch | hey - where do I file bugs on the snap tool itself | 15:13 |
| joc_ | bugs.launchpad.net/snappy | 15:14 |
| natefinch | thanks | 15:14 |
| kyrofa | natefinch, see the room title :) | 15:15 |
| natefinch | kyrofa: doh, sorry :) | 15:15 |
| kyrofa | Err, topic. Whatever it's called | 15:15 |
| * sergiusens goes out for lunch | 15:16 | |
| noise][ | parts service is parts service, please don't call it SPS | 15:18 |
| === sverdy is now known as StephaneVerdy | ||
| icey | why isn't snapcraft installable via snap yet? | 15:21 |
| kyrofa | icey, because it need access to the archives. Eventually it'll build inside lxc containers which will enable its snappification | 15:22 |
| icey | woot kyrofa! | 15:22 |
| mup | Bug #1616508 opened: snap install overwrites its own output <Snappy:New> <https://launchpad.net/bugs/1616508> | 15:25 |
| joc_ | noise][: i stand corrected, will drop the TLA | 15:29 |
| leftyfb | Is there a way to use snapcraft to snap an app that uses an install.sh for it's installation? | 15:32 |
| ppisati_ | my pull requst failed during the autopkgtest snaps with a | 15:33 |
| ppisati_ | FAIL timed out | 15:33 |
| ppisati_ | message repated here and there | 15:33 |
| ppisati_ | http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-snaps-cloud/371/console | 15:33 |
| ppisati_ | do any of you know how to grok this>? | 15:33 |
| slangasek | zyga: I am not around at 3am... :) You might have better luck getting the SRU Team member of the day to accept it? https://wiki.ubuntu.com/StableReleaseUpdates#Publishing | 15:35 |
| kyrofa | leftyfb, yes but you'd need to either wrap it in a build system (e.g. a Makefile that calls the install.sh) or make a local plugin that builds your part | 15:35 |
| ogra | jdstrand, so i talked to niemeyer about the kernel snaps during our meeting, seems your warnings are prefectly right and the snapcraft team actually needs to drop all the lines from the "type: kernel" builds | 15:36 |
| ogra | jdstrand, sergiusens is looking into that, so once it is there the kernels should just auto-land | 15:36 |
| ogra | ppisati_, FYI, i did split the makefile out of the kernel-snap trees, they now all use the same | 15:37 |
| ogra | (from a separate bzr tree) | 15:37 |
| mup | Bug #1616515 opened: warn uploaders and downloaders when a package or deps has CVEs <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1616515> | 15:40 |
| ppisati_ | ogra: nice! | 15:41 |
| icey | is there currently a plugin / method for snapping a go package that uses gdm for dependency management? | 15:45 |
| mhall119 | sergiusens: can you remember me how to make snapcraft look for packages from a PPA? | 15:52 |
| kyrofa | icey, no, you probably need a new plugin for that-- pull requests welcome! | 15:53 |
| kyrofa | icey, note that you can create a local plugin, by the way | 15:53 |
| mup | PR snapd#1749 opened: many: split public snapd REST API into separate socket <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1749> | 15:57 |
| kyrofa | jdstrand, here is that diff in PR form: https://github.com/snapcore/snapd/pull/1749/files#diff-a34e166c5b3016c122430c5884f41e9b . If you have a minute to take another look at give it a +1 I'd really appreciate it | 15:59 |
| mup | PR snapd#1749: many: split public snapd REST API into separate socket <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1749> | 15:59 |
| sergiusens | mhall119 add the ppa to your host | 16:01 |
| sergiusens | joc_ oh, and yes there are tests | 16:01 |
| joc_ | sergiusens: in the snapcraft source? should i try and add one with filesets? | 16:03 |
| mhall119 | sergiusens: that's less than ideal | 16:04 |
| mhall119 | sergiusens: would you be opposed to me submitting a patch to snapcraft to allow additional archive sources to be added via the snapcraft.yaml? | 16:05 |
| mhall119 | at least for stage-packages | 16:05 |
| mhall119 | but build-packages in a cleanbuild environment too perhaps | 16:06 |
| mup | Bug #1616507 opened: app names cannot contain underscores <Canonical Click Reviewers tools:New> <Snapcraft:Opinion> <Snappy:New> <https://launchpad.net/bugs/1616507> | 16:07 |
| mup | PR snapcraft#753 opened: Add the arm64 architecture to the nodejs plugin <Created by elopio> <https://github.com/snapcore/snapcraft/pull/753> | 16:14 |
| mup | PR snapd#1719 closed: firstboot: add firstboot assertions importing <Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1719> | 16:16 |
| zyga | slangasek: noted, tank you | 16:17 |
| zyga | thank you | 16:17 |
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| ahasenack | where can I find snappy logs? I installed the snap I'm developing, the service is not starting, I would like to know why | 16:44 |
| kyrofa | ahasenack, check syslog | 16:46 |
| kyrofa | ahasenack, or use systemctl | 16:46 |
| kyrofa | ahasenack, `systemctl status snap.<snapname>.<servicename>.service` | 16:46 |
| ahasenack | kyrofa: does the snap, when running a service, become a systemd job? | 16:47 |
| ahasenack | hm | 16:47 |
| kyrofa | ahasenack, indeed | 16:47 |
| * ogra taps foot | 16:48 | |
| ahasenack | kyrofa: yeah, ok, got it | 16:49 |
| ahasenack | can't run squid even as root, it still tries some system call that snappy doesn't like | 16:49 |
| ahasenack | Aug 24 13:48:17 nsn7 ubuntu-core-launcher[12191]: /snap/squid-deb-proxy/x3/usr/bin/run-squid.sh: line 24: 12198 Bad system call $SQUID -z -N -f $CONFIG | 16:49 |
| ogra | fchown() most likely | 16:49 |
| ahasenack | kyrofa: is there a way to start it as non-root? | 16:49 |
| kyrofa | ahasenack, are you familiar with snappy-debug? | 16:49 |
| === davmor2_ is now known as davmor2 | ||
| kyrofa | ahasenack, not if it's a service, no | 16:49 |
| ahasenack | I don't really need it to start as root, then switch users, as it binds to a high port | 16:49 |
| ahasenack | it could start as nobody | 16:50 |
| ogra | well, there is currently no way to run it as anything else but root | 16:50 |
| kyrofa | ahasenack, in snappy, services are run as root | 16:50 |
| elopio | lool: are you using cleanbuild? | 16:57 |
| leftyfb | i'm trying to snap rsync. But it doesn't seem to have permissions to write to my home directory | 16:58 |
| leftyfb | " failed: Permission denied (13)" | 16:59 |
| ogra | did you add the home interface ? | 16:59 |
| leftyfb | ogra: not sure what that is | 17:00 |
| ogra | https://github.com/ogra1/jtiledownloader/blob/master/snapcraft.yaml | 17:00 |
| ogra | plugs: [home, x11, network, network-bind] | 17:00 |
| ogra | (allows access to home, x11 and network bits) | 17:00 |
| ogra | add "plugs: [home]" to your app definition | 17:01 |
| leftyfb | ogra: what about it not allowing in /tmp either? Should there be a plugin for every directory/partition/filesystem? | 17:01 |
| ogra | well, a snap has its own /tmp | 17:01 |
| ogra | so /tmp is allowed ... but isnt your /tmp | 17:01 |
| leftyfb | ogra: right, but if I want to rsync something into or from /tmp | 17:02 |
| ogra | thats currently not possible ... you would have to fish it out from the snap dir | 17:02 |
| leftyfb | http://pastebin.com/Tz5ijTyZ | 17:06 |
| ogra | well, check with snap-debug | 17:07 |
| ogra | theer are surely errors in syslog and such | 17:07 |
| leftyfb | adding in the home plug works when rsync'ing to and from my home ... so that's good | 17:08 |
| sergiusens | mhall119 what would the separation of concerns be wrt how launchpad works if ppa's can be added in snapcraft.yaml? wrt allowing ppa's when doing a cleanbuild, there's a bug for that and just waiting implementation | 17:17 |
| sergiusens | mhall119 adding ppa's to the snapcraft.yaml language will get tricky when implementing the source engines as well; I'd rather not do that now regardless of the separation of concerns aspect with launchpad | 17:18 |
| sergiusens | joc_ yes, an integration test would be ideal | 17:18 |
| joc_ | sergiusens: the tests would pull from the real parts service? there isnt a mocked version or something | 17:22 |
| mup | PR snapcraft#754 opened: Use in plugin code to remove bad files <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/754> | 17:35 |
| mup | PR snapcraft#755 opened: Enable the static checks for the integration tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/755> | 17:35 |
| mhall119 | sergiusens: I'm confused, what does launchpad have to do with it? | 17:35 |
| sergiusens | joc_ integration tests use mocks, talk to josepht about the details | 17:35 |
| sergiusens | mhall119 launchpad allows selecting which PPAs to add when building | 17:36 |
| sergiusens | mhall119 as part of the environment setup | 17:36 |
| mhall119 | oh, I didn't realize that | 17:36 |
| mhall119 | but only PPAs? | 17:36 |
| sergiusens | mhall119 yes, well not sure if anything else is allowed, cjwatson would know best | 17:37 |
| mhall119 | sergiusens: my plan was to append sources to whatever snapcraft currently gets | 17:37 |
| sergiusens | mhall119 and gpg keys? | 17:38 |
| mhall119 | if launchpad adds PPAs to the host (chroot, container, whatever it is) that would still be used | 17:38 |
| mhall119 | could be auto-trusted or ignored I suppose.... | 17:38 |
| sergiusens | mhall119 would the language be clean enough for the day we need to support adding rpm sources? | 17:38 |
| sergiusens | mhall119 we fail on unsigned repos today, I don't feel it is a good idea to move away from that | 17:39 |
| mhall119 | it could be, but that would require more work in the existing snapcraft cod | 17:39 |
| mhall119 | e | 17:39 |
| joc_ | josepht: if you could give me some pointers about how to write an integration test for snapcraft to test an aspect of building a remote part that would be great :) | 17:39 |
| mhall119 | sergiusens: so your source of trust is the fact that it's been added to the host? | 17:39 |
| mhall119 | I suppose the packaging could include a trust keyring | 17:40 |
| mhall119 | I wouldn't want to put the keys themselves in the snapcraft.yaml | 17:40 |
| mhall119 | sergiusens: basically I want to get Qt 5.6 dependencies for qupzilla, and there's no way for me to do that without adding those repos to my laptop and potentially breaking lots of stuff | 17:41 |
| sergiusens | mhall119 for now then `lxc launch ubuntu:xenial` | 17:42 |
| sergiusens | and work from there | 17:42 |
| mhall119 | yeah, but that's going to make handing the snap packaging duty over to upstream a more difficult sell | 17:43 |
| sergiusens | mhall119 you could build Qt from sources and provide it as a part | 17:43 |
| sergiusens | mhall119 also, I am not saying no, I am saying no for the time being | 17:44 |
| cjwatson | mhall119: Launchpad itself will only let you configure PPAs, but there's nothing really to stop you adding other sources to snapcraft via the proxy, it's just a bit more manual | 17:44 |
| mhall119 | I've been told that's not easy, they have a non-standard build setup that our current plugins can't handle | 17:44 |
| mhall119 | cjwatson: the proxy? | 17:44 |
| cjwatson | ok, maybe I shouldn't have mentioned mostly-internal details. do you actually need an explanation of the internals at the moment? | 17:44 |
| mhall119 | I'd be happy with a how-to-use-them | 17:45 |
| cjwatson | in that case you don't need any information about that :) | 17:45 |
| josepht | joc_: There's a fake server here: https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/fake_servers.py#L39 | 17:45 |
| mhall119 | so I have an KDE Neon archie I want to pull qt dependencies from | 17:45 |
| mhall119 | archive | 17:45 |
| cjwatson | LP builders can only talk to the outside world via an HTTP proxy (which is only available for snap builds, not other kinds of builds), but that's configured in the http_proxy environment variable and sane stuff (including apt) will honour that | 17:46 |
| cjwatson | I don't really have an opinion on how it's configured in snapcraft.yaml etc. as long as the LP configuration mechanism keeps working | 17:47 |
| sergiusens | mhall119 with what cjwatson says, you could get away with a custom snapcraft plugin that does something similar to what we do with the catkin one | 17:47 |
| mhall119 | okay...but how do I use that to tell snapcraft to get packages from an archive that's not installed in the build environment? | 17:47 |
| sergiusens | you would not be supported in that path forever, but it will get the job done | 17:47 |
| josepht | joc_: we're using something similar for the parser tests here: https://github.com/snapcore/snapcraft/blob/master/snapcraft/tests/test_parser.py#L633 | 17:48 |
| mmcc | Hi folks, I am trying to snap a very simple Makefile based project, with one twist- the Makefile is generated by running perl on a Makefile.PL. Is there an easy existing way to tell snapcraft to do that before running make? Or do I need to add a 'pre-command' to the make plugin or something? | 17:49 |
| sergiusens | tealeg hey, when do we get to see your plugin? :-) | 17:50 |
| nacc | mmcc: i dont' think there is a trivial way; but you could, i think, write your own plugin (pretty easily) that inherits form the make one, and only overrides build() to call perl Makefile.PL first then super.build() ? | 17:50 |
| nacc | mmcc: that plugin would go in parts/plugins/ in your snapcraft directory | 17:51 |
| nacc | mmcc: and then your yaml would just refer to it | 17:51 |
| mmcc | ah ok, that's 'local plugins' then. I saw a reference to that earlier. thanks | 17:51 |
| nacc | mmcc: yeah | 17:51 |
| josepht | joc_: though the fakes might not work in this case, you can also output you're own local copy of parts.yaml to ~/.local/share/snapcraft/parts.yaml and then call build | 17:51 |
| nacc | mmcc: there might be a better way, but that's what i've done in the past when a makefile doesn't quite conform to the generic `make; make install` template | 17:52 |
| mmcc | nacc, thanks! | 17:53 |
| nacc | mmcc: np, i would also consider filing a bug report/feature request. I think there might already be one (so search first), for the notion of -- use this plugin, but do this one step first :) | 17:54 |
| joc_ | josepht: ok thanks, i'll try and put something together based on that tomorrow, the parts.yaml file should be enough as I don't see anything wrong with the contents of that when i've tried this | 17:54 |
| mmcc | nacc: ok, I'll look. TBH I'm a little surprised that there isn't a generic 'shell' plugin, where I could put one command and then have my 'make'-based part run after it. Is that a conscious design decision? | 17:55 |
| nacc | mmcc: probably? i'm not aware of those level of decisions :) the thing is such a plugin doesn't really make sense -- in that it'd have to take parameters which are arbitrary commands. It seems like it would become less useful (and prone for bad c&p and not using of good parts) | 17:56 |
| leftyfb | /snap/bin/rsync-leftyfb.rsync ... how do I get rid of that .rsync at the end? | 17:56 |
| nacc | leftyfb: it's a naming thing, iirc | 17:56 |
| Pharaoh_Atem | zyga: snap-confine is on its way to stable for f24 | 17:57 |
| nacc | leftyfb: if your snap and app name are the same, it magically drops the . naming | 17:57 |
| nacc | leftyfb: but since your snap is called rsync-leftyb, it puts it in a sort-of namespace | 17:57 |
| leftyfb | ah, I see | 17:57 |
| nacc | leftyfb: i think there is a feature open, or something, to allow for specifing the naming, but i don't have bug # handy | 17:57 |
| leftyfb | bingo, got it, thanks | 17:58 |
| Pharaoh_Atem | zyga: also, any luck on the patches for moving /snap? | 17:58 |
| Pharaoh_Atem | and it looks like someone left a comment for you to address in the review for snapd | 17:58 |
| jgrimm | mmcc, nacc: fwiw: https://github.com/snapcore/snapcraft/pull/727 | 17:58 |
| mup | PR snapcraft#727: Add a new build plugin 'shell' that runs arbitrary shell commands <Created by Magical-Chicken> <https://github.com/snapcore/snapcraft/pull/727> | 17:58 |
| nacc | jgrimm: :) thanks! | 17:59 |
| jdstrand | ogra: re kernel and reviews tools> ack | 18:00 |
| nacc | jgrimm: i would almost suggest to Magical-Chicken that perhaps such a plugin should only be available in devmode (based upon e.g. monsterjamp's comment from 7 days ago) | 18:01 |
| nacc | jgrimm: i've been thinking about that more lately, there are some things that are 'sane' in the context of trying to get going, but aren't necessarily sane in a GA/stable version | 18:01 |
| nacc | jgrimm: e.g., testing hooks? maybe the shell app i have a bug filed for (so you can debug by dropping to your snap's environment) | 18:01 |
| leftyfb | ok, so how do I go about publishing a snap of say, rsync so others can find it just by using the name "rsync" and not -leftyfb? Can I just remove -leftyfb from the name or do I have to go through some process? | 18:03 |
| nacc | leftyfb: you probably need to register the name, yeah | 18:05 |
| leftyfb | that's it? | 18:05 |
| leftyfb | bah, it's reserved | 18:05 |
| jdstrand | kyrofa: done | 18:05 |
| nacc | leftyfb: you'd probably need to rename your snap to 'rsync', as well | 18:05 |
| nacc | leftyfb: yeah, i'd expect it to be :) | 18:05 |
| leftyfb | nacc: so we have to wait for all the original developers of applications to publish their own apps? | 18:07 |
| nacc | leftyfb: no, but i think they reserved some common names in order to not let random folks camp on them | 18:12 |
| leftyfb | ok, now this is kinda silly. Everything we upload gets .leftyfb added to the end of it. But I can't just upload "rsync" and have it turn out rsync.leftyfb because "rsync" is already taken. So I have to name it "rsync-leftyfb" which then also puts .leftyfb at the end of it making it "rsync-leftyfb.leftyfb". | 18:13 |
| kyrofa | jdstrand, hey thanks! | 18:15 |
| kyrofa | leftyfb, name the app the same as the snap, and you can just call it rsync-leftyfb | 18:16 |
| mup | PR snapcraft#756 opened: Use block style for multiline YAML values <Created by josepht> <https://github.com/snapcore/snapcraft/pull/756> | 18:17 |
| leftyfb | kyrofa: I had that. But when I uploaded it and tried to publish it it added .leftyfb to the end of rsync-leftyfb | 18:17 |
| kyrofa | leftyfb, then did you try to install it from the store again? It should install as rsync-leftyfb | 18:18 |
| kyrofa | Regardless of the store showing the .leftyfb | 18:18 |
| kyrofa | leftyfb, well wait-- which series are we talking about? | 18:18 |
| ogra | jdstrand, sergiusens with a patched snapcraft in the PPA like http://paste.ubuntu.com/23085847/ i now have end to end kernel snap builds and auto-uploads fully working | 18:19 |
| leftyfb | kyrofa: series? | 18:19 |
| kyrofa | leftyfb, when you upload the snap, which series did you select? 15.04 of 16? | 18:19 |
| kyrofa | or* | 18:19 |
| leftyfb | kyrofa: nowhere during the snapcraft upload process or the web ui publish process did it ask for a series | 18:20 |
| * ogra refreshes to the new pi2-kernel snap ... lets see if it also boots now :) | 18:20 | |
| kyrofa | leftyfb, ah, 16 then. So yeah, did you try actually installing the one you published? | 18:21 |
| leftyfb | about to | 18:21 |
| leftyfb | kyrofa: ok, that worked | 18:21 |
| kyrofa | leftyfb, in 15.04 snaps were snapname.publishername, so what you're seeing there might be a store leftover | 18:22 |
| jgrimm | nacc, snappy-debug mentioned here: http://askubuntu.com/questions/783979/how-do-i-debug-snaps | 18:23 |
| nacc | jgrimm: thanks | 18:24 |
| tealeg | sergiusens: re the plugin - I've not seen any progress on the 32bit kernel calls that would effect SBCL and CCL - I do have a version working with GNU CLisp, but that is slightly less useful because a few key libraries don't play well with CLisp. | 18:26 |
| tealeg | sergiusens: I could certainly bring the current state to the point where I could submit a pull request. | 18:27 |
| natefinch | btw, I can't run any snaps: https://bugs.launchpad.net/snapcraft/+bug/1616586 | 18:30 |
| mup | Bug #1616586: all snaps report "multiple nvidia drivers detected, this is not supported." <Snapcraft:New> <https://launchpad.net/bugs/1616586> | 18:30 |
| newsages | hola | 18:35 |
| ogra | natefinch, duplicated | 18:35 |
| ogra | (check the one i duplicated it against, there is an explanation and a workaround) | 18:35 |
| newsages | como se crea una lib snap para poder reutilizarla entre snaps? | 18:36 |
| natefinch | ogra: lol, bogus indeed. | 18:36 |
| ogra | :) | 18:36 |
| ogra | zyga, is bug 1615248 yours ? | 18:37 |
| mup | Bug #1615248: ubuntu-core-launcher nvidia driver detection is bogus <Snappy:New> <https://launchpad.net/bugs/1615248> | 18:37 |
| ogra | or who maintains ubuntu-core-launcher nowadays | 18:37 |
| mhall119 | sergiusens: I know about $SNAPCRAFT_STAGE, is there another env var I can use to point to parts directories? | 18:39 |
| natefinch | ogra: gotta say, I am not going to fiddle with any nvidia folders by hand. Every time something mucks with my drivers, I end up spending most of a day in a command prompt trying to figure out what broke X. | 18:40 |
| mhall119 | or a way for partA to copy files from partB into the stage/prime area? | 18:41 |
| ogra | natefinch, well ... dpkg -l |grep ^ii| grep nvidia-[0-9] | 18:41 |
| mup | PR snapcraft#755 closed: Enable the static checks for the integration tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/755> | 18:41 |
| ogra | natefinch, thats should be the only drivers in use | 18:41 |
| ogra | (i assume it will only return one) | 18:41 |
| ogra | all other dirs can be deleted | 18:42 |
| natefinch | ogra: yeah, it only returns one, and that is the one with far more files in it (the other one only has two, presumably just cruft) | 18:43 |
| ogra | yeah, you can safely delete them | 18:43 |
| jdstrand | ogra: to be clear, you are talking about this warning: unknown entries in snap.yaml: 'dtbs,firmware,initrd,kernel,modules' lint-snap-v2_unknown_field | 18:45 |
| lazyPower | woo first snap works \o/ | 18:45 |
| ogra | jdstrand, exactly ... i patched the image PPA snapcraft to not add them and the store just auto-approved all my builds | 18:46 |
| jdstrand | nice | 18:46 |
| lazyPower | next question i have, i've seen asked before but not answered, and i fear i know the ansewr. Is there a docker snap with a plug that i can use? I'm cycling towards snapping up kubernetes, and this is going to be a very complex snap | 18:46 |
| jdstrand | I like that solution. I don't have to do anything :) | 18:46 |
| ogra | jdstrand, well, sergiusens does :) | 18:46 |
| newsages | How does one create a library for reuse between snaps ? | 18:48 |
| tvoss | newsages: you create the library and make it accessible via snapcraft parts (see https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-parts/) | 18:52 |
| === caraka_ is now known as caraka | ||
| natefinch | ogra: btw, renaming that spurious nvidia directory does fix the problem | 18:58 |
| ogra | note that in the bug :) | 18:59 |
| natefinch | ogra: I was on my way there :) | 18:59 |
| ogra | :) | 18:59 |
| tuxiano | Hi I installed darktable using snappy. Now I have issues opening files stored outside of my home directory (on a nfs drive). Is it somehow possible to extend the permissions of a snap app so that it can open such files. | 19:01 |
| tuxiano | Same problem with vlc, too. | 19:01 |
| arges | i'm testing snapd 2.13, which has a new interface 'kernel-module-control'. Besides installing the new package what else is required to make this interface visible? 'snap interfaces' doesn't show it, but a strings /usr/lib/snapd/snapd shows it existing in that binary | 19:06 |
| ahoneybun | I had a good idea mhall119 lol | 19:16 |
| kyrofa | arges, a snap that provides the slot, probably | 19:20 |
| === mup_ is now known as mup | ||
| arges | kyrofa: i have this, but I get "has bad plugs or slots: kernel-module-control (unknown interface)" when trying to install the test package | 19:21 |
| lool | elopio: no I'm not | 19:21 |
| kyrofa | arges, it might be re-executing an older snapd from within the core snap | 19:22 |
| mhall119 | ahoneybun: snap find --channel=beta? | 19:22 |
| mhall119 | yeah | 19:22 |
| elopio | lool: I'm having tons of different problems. I get less if I use cleanbuild. | 19:22 |
| lool | elopio: I think the issue is in the gulp plugin; it expects gulp is installed in its own private dir | 19:22 |
| kyrofa | arges, try running both the server and client with SNAP_REEXEC=0 | 19:22 |
| arges | kyrofa: ok i'll try that | 19:22 |
| lool | elopio: I will try this, but lxd is a bit heavy for the rpi | 19:23 |
| elopio | lool: while we solve the problems with snapcraft.yaml and launchpad, I quickly reverted to get the previous multiarchitecture build, so I have the 4 snaps uploaded to the store and waiting for a manual review. | 19:23 |
| lool | it's not heavy in itself, but it's a lot of extra io | 19:23 |
| lool | elopio: oh cool | 19:23 |
| elopio | lool: the problem is now that the snap doesn't start, saying that ubuntu-app-launch failed to execv | 19:24 |
| mup | Bug #1616605 opened: Cannot open files from NFS drive <Snappy:New> <https://launchpad.net/bugs/1616605> | 19:24 |
| elopio | so I have like 3 workarounds, but none of them is easy to get finished. | 19:24 |
| tuxiano | Just added a bug report: https://bugs.launchpad.net/snappy/+bug/1616605 | 19:24 |
| mup | Bug #1616605: Cannot open files from NFS drive <Snappy:New> <https://launchpad.net/bugs/1616605> | 19:24 |
| lool | elopio: OMG | 19:24 |
| elopio | lool: let me upload the snaps to my ftp so you can take a look. | 19:24 |
| arges | kyrofa: still doesn't work | 19:24 |
| lool | elopio: what's the startup issue? | 19:24 |
| kyrofa | tuxiano, yes, we see that ;) | 19:25 |
| kyrofa | arges, dumb question, but you're sure the kernel interface is in 2.13? | 19:25 |
| arges | $ git tag --contains a22b514513c020673b290e3dd723d0bbe9a496ad | 19:27 |
| arges | 2.13 | 19:27 |
| arges | https://github.com/snapcore/snapd/commit/a22b514513c020673b290e3dd723d0bbe9a496ad | 19:27 |
| arges | kyrofa: ^^ yes | 19:27 |
| arges | kyrofa: sudo /lib/systemd/systemd-activate -E SNAPD_DEBUG=1 -E SNAP_REEXEC=0 -l /run/snapd.socket /usr/lib/snapd/snapd | 19:30 |
| arges | that worked ^^ | 19:30 |
| kyrofa | arges, ah, you only ran the client with SNAP_REEXEC? | 19:30 |
| arges | kyrofa: I wasn't passing the enviornment variable correctly into snapd, so I just manually executed like that | 19:31 |
| kyrofa | Ah, okay | 19:31 |
| arges | so will I just need to wait until ubuntu-core is updated with the snapd then? | 19:31 |
| arges | * with snapd 2.13 that is | 19:32 |
| zyga | ogra: perhaps, checking | 19:33 |
| kyrofa | arges, indeed. mvo or ogra might be able to move that along | 19:34 |
| ogra | kyrofa, ? | 19:35 |
| kyrofa | ogra, get the new snapd in a core snap soon | 19:36 |
| mup | Bug #1615248 changed: ubuntu-core-launcher nvidia driver detection is bogus <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1615248> | 19:36 |
| kyrofa | That came out commanding, I meant to just define what "that" was :P | 19:36 |
| kyrofa | But yes, ogra, do as I say | 19:36 |
| ogra | heh | 19:36 |
| elopio | lool: http://paste.ubuntu.com/23086044/ | 19:37 |
| ogra | well, we build the daily snnap from the images PPA | 19:37 |
| kyrofa | ogra, does that automatically go to edge nowadays? | 19:37 |
| ogra | err | 19:37 |
| ogra | the edge PPA | 19:37 |
| elopio | lool: http://people.ubuntu.com/~elopio/snaps/ | 19:37 |
| lool | elopio: is that with --devmode? | 19:37 |
| lool | elopio: thanks | 19:37 |
| elopio | lool: no, without. | 19:37 |
| ogra | yes, every UTC morning :) | 19:37 |
| ogra | kyrofa, seems snapd failed to build https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages | 19:38 |
| kyrofa | elopio, journalctl -u snap.snapweb.snapweb.service might be more helpful | 19:38 |
| lool | elopio: I'll check it out tomorrow, thanks | 19:38 |
| ogra | elopio, why does that only have 2.12 ^^ ? | 19:38 |
| lool | elopio: I'm finishing lxd setup on rpi and kicking a cleanbuild | 19:38 |
| mup | Bug #1616515 changed: warn uploaders and downloaders when a package or deps has CVEs <Snapcraft:Opinion> <Snappy:New> <https://launchpad.net/bugs/1616515> | 19:39 |
| elopio | kyrofa: that's what I pasted. | 19:40 |
| kyrofa | elopio, oh, that looked like status. That's all it gives you? Meh | 19:40 |
| elopio | lool: same error with devmode. | 19:41 |
| ogra | kyrofa, elopio is that bug 1610026 you are talking about ? | 19:41 |
| mup | Bug #1610026: snapweb fails to start after reboot <snapweb:Confirmed> <https://launchpad.net/bugs/1610026> | 19:41 |
| lool | elopio: ok, check dmesg for apparmor denials, if nothing then it's likely a missing +x or an unreadable data file somewhere | 19:41 |
| elopio | ogra: no, that one happens with the one in the store. If I do snap install snapweb --edge, it starts here. | 19:42 |
| lool | ogra: I believe this is another one | 19:42 |
| ogra | ah, k | 19:42 |
| ogra | kyrofa, arges, well, snapd comes from daily builds in https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages ... so as soon as 2.13 will show up there it will be in the ubuntu-core snap | 19:43 |
| elopio | lool: yes, that sounds likely because the snap that I build from master using snapcraft starts. So something that snapcraft does that the build script doesn't. | 19:43 |
| arges | ogra: ok good to know! thanks | 19:43 |
| elopio | I'm just not sure which workaround to pursue now :S | 19:44 |
| kyrofa | ogra, edge only though, right? | 19:44 |
| ogra | kyrofa, well, mvo promotes them currently, we do not re-build | 19:44 |
| ogra | (that will change once the PPAs are cleaned out) | 19:45 |
| mup | PR snapd#1750 opened: store: request device session macaroon from store <Created by matiasb> <https://github.com/snapcore/snapd/pull/1750> | 19:45 |
| ogra | so the edge package also ends up in the stable ubuntu-core currently | 19:45 |
| lool | elopio: I'll poke it more tomorrow; I might have to go through the same pains you did, but I guess there is no alternative to debug this | 19:45 |
| lool | or I could try running your snaps directly | 19:46 |
| * lool EODs & | 19:46 | |
| elopio | lool: oh, it started! | 19:46 |
| * ogra goes afk for a while too | 19:46 | |
| kyrofa | elopio, he's gone, sorry, you failed for today | 19:46 |
| kyrofa | ogra, so they don't go into any channel by default? | 19:48 |
| elopio | :'( | 19:48 |
| elopio | kyrofa: he's gone too. | 19:49 |
| kyrofa | Argh, europeans | 19:49 |
| elopio | they stop working at lunchtime. We should move there :) | 19:50 |
| kyrofa | Yeah that sounds nice | 19:51 |
| elopio | nessita or noise][1: does it make sense for snapweb to require a manual review before I can publish it on edge? | 19:53 |
| mup | PR snapd#1704 closed: snap: add key management commands <Created by cjwatson> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1704> | 19:59 |
| === mup_ is now known as mup | ||
| jdstrand | kyrofa: hey, otoh, if I found a bug in the desktop part, would I file that against snapcraft? | 20:10 |
| sergiusens | jdstrand an issue on the github upstream maybe? | 20:11 |
| nessita | elopio, hi! you mean there was an upload requiring manual review? | 20:13 |
| jdstrand | sergiusens: ok, thanks | 20:13 |
| sergiusens | jdstrand just trying to avoid more bugs :-) | 20:14 |
| elopio | nessita: well, yes, I'm pushing packages there. But the idea is to make an upload for every change in master through launchpad, so that will be a lot of slow manual reviews and breaks the purpose of rapidly changing edge | 20:15 |
| nessita | elopio, what's the error you are having? | 20:16 |
| jdstrand | sergiusens: do you know where that is otoh? | 20:16 |
| elopio | nessita: no error. It uses the snap-control interface which is restricted. | 20:16 |
| nessita | elopio, right, so once we have the proper assertions per snap in place, we will be able to state "privileged interfaces" per snap in said assertion | 20:18 |
| nessita | and that will be fed to c-r-t | 20:18 |
| nessita | so manual review will not be required | 20:18 |
| sergiusens | jdstrand https://github.com/ubuntu/snapcraft-desktop-helpers `snapcraft define <part-name>` should tell you as well iirc | 20:18 |
| nessita | elopio, until then, you will need a +1 from a reviewer | 20:19 |
| nessita | elopio, privileged interfaces is GA, so not far :-) | 20:19 |
| jdstrand | sergiusens: thanks! 'define' tells me cool stuff but not the project or where to report bugs | 20:19 |
| jdstrand | sergiusens: (fyi) | 20:19 |
| elopio | nessita: alright, that sounds good. Could the assertion be only for edge? I think I would need a signature from the security team to push to stable in some cases. | 20:20 |
| nessita | elopio, hummmmmmm good question, I think no, the assertion is per snap. Note that there is no way to restrict a snap revision to be publish in extra channels after approval | 20:23 |
| === mup_ is now known as mup | ||
| mup | PR snapd#1751 opened: tests: add workaround for u-d-f to unblock all-snap image tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1751> | 20:24 |
| sergiusens | jdstrand the 'source' could be an indication; but this is actually a good point, we should expose `origin` there :-) | 20:24 |
| elopio | nessita: it might be fine. I can be trusted to ask for a review before moving the snap, but it would be great if this could be crypto enforced. | 20:25 |
| elopio | nessita: so this means https://bugs.launchpad.net/software-center-agent/+bug/1580371 doesn't make sense anymore, right? | 20:25 |
| jhodapp | I can't figure out why snapcraft can't find the test-client binary after building it, here's my snapcraft.yaml: http://pastebin.ubuntu.com/23086181 | 20:26 |
| nessita | let me check | 20:29 |
| sergiusens | jhodapp might be related to your .pro file there | 20:30 |
| sergiusens | jhodapp is the test-client in stage or prime? | 20:30 |
| sergiusens | or even inside parts/test-client/install ? | 20:30 |
| jhodapp | sergiusens, I only see it under part/test-client/build | 20:31 |
| nessita | elopio, well, it makes sense a request, is just that our solution for it is the one using assertions instead of special-casing inside the source code | 20:31 |
| jhodapp | *parts | 20:31 |
| nessita | elopio, let me add a comment in there | 20:31 |
| elopio | nessita: thanks. It is indeed a lot better than what we discussed before. | 20:32 |
| elopio | nessita: and another question while that gets implemented. I pushed a snap and it's waiting in the manual review queue. Then I pushed a new version. Is there a way to cancel the first review? Or will the reviewers just ignore it? | 20:32 |
| lool | elopio: oh cool, how did it start? | 20:33 |
| lool | elopio: my cleanbuild failed :-( | 20:33 |
| lool | elopio: http://paste.ubuntu.com/23086213/ | 20:33 |
| elopio | lool: the revert was missing a chmod +x, as you suggested. | 20:33 |
| lool | cool | 20:34 |
| elopio | lool: try the snaps from my ftp. | 20:34 |
| nessita | elopio, I don't know for sure, let me check | 20:34 |
| elopio | I will test in rpi2 after lunch. | 20:34 |
| jhodapp | sergiusens, any ideas? | 20:35 |
| mup | PR snapd#1752 opened: tests/main/ack: fix test/style <Created by pedronis> <https://github.com/snapcore/snapd/pull/1752> | 20:36 |
| sergiusens | jhodapp is you `make install` dtrt wrt that PREFIX you set? | 20:37 |
| lool | elopio: awesome, your snaps work fine! | 20:37 |
| jhodapp | sergiusens, dtrt wrt? | 20:38 |
| sergiusens | jhodapp do the right thing with regards to | 20:38 |
| elopio | kyrofa: you see, I won! | 20:38 |
| jhodapp | sergiusens, I believe it does, let me double check that | 20:38 |
| elopio | luckily that means I don't have to solve all the bugs I collected and can get back to testing :) | 20:39 |
| sergiusens | elopio please check the nodejs armhf one though :-) | 20:39 |
| mup | PR snapd#1752 closed: tests/main/ack: fix test/style <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1752> | 20:39 |
| sergiusens | elopio and the proxy one! | 20:39 |
| elopio | sergiusens: the proxy is solved. It's building. | 20:39 |
| jhodapp | sergiusens, do you mean from the parts dir or building test-client manually on its own? | 20:39 |
| sergiusens | elopio +1 it then please :-) | 20:40 |
| elopio | sergiusens: oh wait, you mean the https env var. I had already forgotten about that one. | 20:40 |
| sergiusens | jhodapp does make install DESTDIR=/some-path work for this? | 20:40 |
| sergiusens | for that project | 20:40 |
| elopio | I think I know how to reproduce it without launchpad. Let me see... | 20:40 |
| sergiusens | I am no qmake expert though | 20:41 |
| mup | PR snapd#1728 closed: asserts: add a key-proof assertion <Blocked> <Reviewed> <Created by cjwatson> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1728> | 20:41 |
| sergiusens | lool when are you joining the league of snapcrafters? | 20:42 |
| sergiusens | ;-) | 20:42 |
| jhodapp | sergiusens, let me check | 20:44 |
| jhodapp | sergiusens, hmm, one problem might be that make install doesn't really seem to ever have anything to do | 20:48 |
| mup | Bug #1616629 opened: could not unmarshal state entry "snap-type" <Snappy:New> <https://launchpad.net/bugs/1616629> | 20:54 |
| jhodapp | sergiusens, yeah that's definitely the issue...the install target is messed up...ugg qmake :) | 21:01 |
| nessita | elopio, sorry, I got distracted. I'm looking at snapweb details right now | 21:03 |
| nessita | elopio, many revnos with red exclamation mark | 21:03 |
| nessita | your question was.../ | 21:03 |
| nessita | ? | 21:03 |
| nessita | (I see a warning of " | 21:03 |
| nessita | (NEEDS REVIEW) 'snapd-control' requires approval lint-snap-v2_blacklist (snapweb, snapd-control) | 21:03 |
| nessita | ") | 21:03 |
| elopio | nessita: there are some revisions that I don't need reviewed, because I pushed newer. My question was how to tell about this to the reviewers. | 21:06 |
| nessita | elopio, if you go to a revno detail do you see any button action at the bottom? | 21:06 |
| nessita | like https://myapps.developer.ubuntu.com/dev/click-apps/5455/rev/14/ | 21:06 |
| elopio | nessita: no buttons. | 21:08 |
| nessita | elopio, then no, sorry. I'm happy to reject as many revision as you instruct me | 21:08 |
| elopio | nessita: I just need the last 4. | 21:13 |
| elopio | one per arch. | 21:13 |
| nessita | ok, let me reject 10 and below | 21:13 |
| nessita | elopio, done | 21:15 |
| elopio | thank you | 21:15 |
| nessita | \o/ | 21:15 |
| nessita | jdstrand, so, how can we (store folks) know when is OK to approve some interface usage such as the one requested by elopio? ( | 21:18 |
| nessita | (NEEDS REVIEW) 'snapd-control' requires approval lint-snap-v2_blacklist (snapweb, snapd-control) | 21:18 |
| nessita | ) | 21:18 |
| elopio | sergiusens: I can't test the nodejs thing. It's not what I thought and scalingstack uses only http proxy. | 21:22 |
| elopio | sergiusens: furthermore, I don't understand. If I have an http_proxy=foo and https_proxy=bar, the workaround makes no sense. It will use https through my foo proxy. | 21:23 |
| cmars | just noticed that the copy plugin is deprecated and it recommends "dump". seems to take a different configuration, how do i port it over? | 21:58 |
| josepht | cmars: I've got a basic example here: https://git.launchpad.net/~joetalbott/+git/dump_example/tree/snapcraft.yaml | 22:07 |
| kyrofa | josepht uses too many usernames | 22:07 |
| cmars | josepht, thanks. I was using the files: attribute on the copy plugin to compiled artifacts in my project directory to the snap... how do I do that with dump? | 22:08 |
| kyrofa | I keep trying to type @josepht on github | 22:08 |
| cmars | josepht, is organize: doing the mapping that files: used to? | 22:10 |
| mup | Bug #1616650 opened: snap refresh while command is running may cause issues <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1616650> | 22:10 |
| josepht | cmars: if you just want to get a copy you can include it in 'stage' option (and maybe 'snap') | 22:10 |
| josepht | cmars: I'm using 'organize' to change the name of a file and then 'stage' and 'snap' to copy it into those partws | 22:10 |
| josepht | *parts | 22:11 |
| josepht | kyrofa: I'm 'josepht' on github :) | 22:11 |
| cmars | josepht, ok, got it working, thanks! | 22:12 |
| josepht | cmars: awesome! no problem | 22:12 |
| * josepht -> dinner | 22:13 | |
| kyrofa | josepht, oh yeah, searching for you to assign bugs then :P | 22:17 |
| mup | PR snapcraft#753 closed: Add the arm64 architecture to the nodejs plugin <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/753> | 22:26 |
| sergiusens | elopio have you checked https://github.com/npm/npm/issues/2050 | 22:28 |
| sergiusens | elopio specifically the last comment | 22:28 |
| sergiusens | elopio your suggestion is the same one we had for bzr | 22:28 |
| sergiusens | have something external dtrt | 22:29 |
| mup | Bug #1616657 opened: snapd install removes Unity launcher-compliant entries <Snappy:New> <https://launchpad.net/bugs/1616657> | 22:34 |
| sergiusens | kyrofa want to look at snapcraft#754 | 22:50 |
| mup | PR snapcraft#754: Use in plugin code to remove unwanted files <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/754> | 22:50 |
| sergiusens | ? | 22:50 |
| sergiusens | kyrofa what are your thoughts on LP: #1616656 ? | 22:55 |
| mup | Bug #1616656: intermittent failure to load correct plugin when a local plugin is a subclass of existing plugin <Snapcraft:Triaged> <https://launchpad.net/bugs/1616656> | 22:55 |
| sergiusens | kyrofa hmm, maybe wait for my email reply to make it to the bug :-P | 22:56 |
| kyrofa | Hahaha | 22:56 |
| sergiusens | kyrofa there we go | 22:57 |
| sergiusens | kyrofa but you are distracted reviewing my PR I suppose | 22:57 |
| sergiusens | ;-) | 22:58 |
| kyrofa | sergiusens, yeah I don't really have any good ideas there simply because I don't know python well enough. We need to research it | 23:11 |
| * kyrofa -> dinner break, back in a bit | 23:14 | |
| nacc | kyrofa: sergiusens: have you asked barry about that? he'd be my goto python person :) | 23:15 |
| === Birchy is now known as figment[1000] | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!