| === JanC is now known as Guest98943 | ||
| === JanC_ is now known as JanC | ||
| === chihchun_afk is now known as chihchun | ||
| frodowiz1 | new here.. gotta sleep at midnight.. anyone understand how to set a tcl library path inside a snap? if it is by using export, i am working on that. probably need to launch a script to export the path then run tclsh. am i anywhere near right? | 04:07 |
|---|---|---|
| pitti | sabdfl: there's plenty of interfaces; journald logs syslog, dmesg, services's stdout/err, so any of those; a direct interface is logger --journald (if you need to fine-tune the property fields), or the C library API; http://0pointer.de/blog/projects/journal-submit.html describes those | 04:48 |
| === ant_ is now known as Guest67209 | ||
| mup | PR snapd#1713 closed: tests: start teaching the fakestore about assertions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1713> | 08:33 |
| zyga | good morning | 09:23 |
| zyga | mhall119: hello | 09:24 |
| zyga | mhall119: I heard you ran into an issue with the content interface on Firday | 09:24 |
| zyga | mhall119: could you please report the issue if you didn't already | 09:25 |
| zyga | mhall119: I talked to mvo and I believe I know what this issue is about, I will fix it no | 09:25 |
| zyga | now* | 09:25 |
| JamieBennett | zyga, there is a bug already I believe | 09:34 |
| morphis_ | ogra: could you put the firmware for pi3 wifi already into the kernel snap? | 09:36 |
| zyga | JamieBennett: do you have a link for that | 09:38 |
| JamieBennett | https://bugs.launchpad.net/bugs/1615113 | 09:40 |
| mup | Bug #1615113: snap-confine prevented from mounting base directory through the "content" interface <Snappy Launcher:New> <https://launchpad.net/bugs/1615113> | 09:40 |
| JamieBennett | zyga, ^ | 09:40 |
| mup | PR snapcraft#747 opened: kernel plugin: vmlinuz -> kernel.img hard link <Created by piso77> <https://github.com/snapcore/snapcraft/pull/747> | 09:41 |
| zyga | JamieBennett: thanks, the bug is fixed now | 09:47 |
| ogra | mvo, mind merging my classic-snap PR ? (then i can move the snap to the beta channel) | 09:47 |
| zyga | hey ogra, how are you :) | 09:48 |
| JamieBennett | zyga, great, and great investigation work from mhall119 | 09:48 |
| ogra | zyga, a bit worn out (busy weekend) but fine beyond that :) | 09:48 |
| === tvoss is now known as tvoss|lunch | ||
| morphis_ | <morphis_> ogra: could you put the firmware for pi3 wifi already into the kernel snap? | 09:53 |
| mup | Bug #1615566 opened: snapcraft SDK <Snappy:New> <https://launchpad.net/bugs/1615566> | 09:53 |
| ogra | Chipaca, so when my system does a secret auto update over night then "snap list" shows the newly installed ubuntu-core despite me not having rebooted yet (so that version isnt in use at all yet) ... isnt that a bug ? | 09:54 |
| ogra | morphis_, well, we need it to go to the archive | 09:54 |
| morphis_ | ogra: sure, but what is the state of that work? | 09:55 |
| ogra | i'll try o get it added to the package via the PPA, but it needs to go in ASAP | 09:55 |
| morphis_ | aye | 09:55 |
| ogra | morphis_, no idea, ppisati_ are you working on getting the Pi3 FW into xenial ? | 09:55 |
| === hikiko is now known as hikiko|ln | ||
| === vrruiz_ is now known as rvr | ||
| ogra | mvo, can you approve https://myapps.developer.ubuntu.com/dev/click-apps/5573/rev/6/ ? that should amke morphis_ happy | 10:45 |
| morphis_ | ogra: yeah!! | 10:45 |
| ogra | *make | 10:45 |
| ogra | (i hope at least ) | 10:46 |
| mup | PR snapd#1709 closed: many: teach prepare-image to copy the model assertion (and prereqs) into the seed area of the image <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1709> | 10:48 |
| mvo | ogra: done | 10:55 |
| ogra | thx ! | 10:55 |
| mvo | ogra: you need to publish it still though | 10:55 |
| ogra | morphis_, tell me if it works for you, then i'll push it to the beta channel too | 10:55 |
| ogra | mvo, yeah | 10:55 |
| morphis_ | ogra: will do | 10:56 |
| morphis_ | matteo: ^^ | 10:56 |
| matteo | ok | 10:56 |
| matteo | by publish you mean in the snap store? | 10:57 |
| ogra | mvo, FYI, i dropped the "raspi2" from the pi2-kernel version string ... (was inconsistent vs the other kernels) | 10:57 |
| ogra | matteo, yes, it is n the edge channel now | 10:57 |
| morphis_ | matteo: yes, in the edge channel | 10:57 |
| === tvoss|lunch is now known as tvoss | ||
| ogra | matteo, if you have a running image on the pi3, just "sudo snap refesh pi2-kernel --edge" and reboot ... then check /proc/net/dev if you have a wlan interface | 10:58 |
| matteo | ok | 10:58 |
| === hikiko|ln is now known as hikiko | ||
| ogra | (i'll have to do another rebuild though, forgot to ship the license file for the FW) | 10:59 |
| matteo | is the firmware like the DHD one? | 10:59 |
| ogra | it is from ppisati_'s package | 11:00 |
| ogra | raspberrypi-wireless-firmware from https://launchpad.net/~p-pisati/+archive/ubuntu/embedded | 11:00 |
| matteo | ok | 11:01 |
| zyga | matteo: o/ | 11:08 |
| matteo | hi | 11:08 |
| ogra | ubuntu@pi2:~$ ifconfig | grep "^[a-z].*Ethernet" | 11:10 |
| ogra | enxb827eb04db1c Link encap:Ethernet HWaddr b8:27:eb:04:db:1c | 11:10 |
| ogra | gotta love the new NIC naming ... | 11:10 |
| morphis_ | ogra: doesn't work here | 11:16 |
| ogra | hmm, any errors in dmesg/syslog/journald ? | 11:16 |
| morphis_ | pi2-kernel 4.4.0-1019-2 is what I have | 11:16 |
| ogra | yeah, thats the right oone | 11:16 |
| morphis_ | I am seeing brcmfmac loaded | 11:16 |
| ogra | did it load before ? | 11:17 |
| morphis_ | ogra: https://paste.ubuntu.com/23078108/ | 11:17 |
| morphis_ | no | 11:17 |
| morphis_ | [ 18.743469] brcmfmac_sdio mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.bin failed with error -2 | 11:17 |
| ogra | brcmfmac_sdio mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.bin failed with error -2 | 11:17 |
| ogra | heh | 11:17 |
| ogra | *snap* | 11:17 |
| morphis_ | hm | 11:17 |
| morphis_ | /lib/firmware/brcm80211/brcm/brcmfmac43430-sdio.bin is present | 11:18 |
| ogra | yes, i guess wrong dir | 11:18 |
| ogra | shoudl go to /lib/firmware/brcm i guess | 11:19 |
| morphis_ | ogra: yeah, looks so | 11:19 |
| ogra | bah, that needs some hackery :( | 11:19 |
| jgdx | when snapping a .deb, what's the best strategy when it comes to hard coded cmake variables passed as -D to a target? | 11:21 |
| jgdx | ogra, maybe you know? ^ | 11:22 |
| jgdx | looks like you can do it at runtime using getenv, or somehow at build time. Or maybe via some magic in snapcraft.yml | 11:24 |
| ogra | jgdx, well, i usuallly snap binaries when snapping debs :) | 11:26 |
| ogra | jgdx, that said ... i have one package that uses the make plugin https://github.com/ogra1/packageproxy | 11:26 |
| ogra | (thats approx, built from latest git) | 11:27 |
| jgdx | ogra, please excuse my lack of proper terminology :p | 11:27 |
| ogra | but usually i just download the deb and run dpkg -x . and then use the copy (now dump) plugin to copy the binaries around | 11:28 |
| ogra | https://github.com/ogra1/laidout is one where i re-use upstreams .deb | 11:29 |
| jgdx | ogra, actually, the binary I snapped works fine, but the binary tries to read from a absolute path based on CMAKE_BINARY_DIR, which doesn't exist. | 11:29 |
| ogra | ah, thats bad | 11:30 |
| ogra | if it douesnt provide a way to overrdie that at runtime i fear you have to patch ... | 11:30 |
| * ogra would make it use getenv() and add an env var from a wrapper script | 11:31 | |
| jgdx | ogra, right, and then the best way would be a configflags: -DSNAPPY=1? | 11:31 |
| ogra | hmm, no idea | 11:31 |
| ogra | thats a kyrofa or sergiusens question ... (or one for the snappy-playpen on gittter) | 11:32 |
| jgdx | ogra, okay, thanks | 11:32 |
| sergiusens | ogra jgdx I think that is an upstream call ;-) RUNTIME_RELOCATION? | 11:34 |
| sergiusens | or even just check for the existence of env vars and use those if defined | 11:35 |
| jgdx | sergiusens, I forgot to mention we're the upstream /cc ogra :) | 11:35 |
| ogra | hah | 11:35 |
| ogra | well, just get the path from an env var then | 11:35 |
| ogra | (as override option) | 11:35 |
| jgdx | okay then :) Thanks sergiusens, og | 11:35 |
| morphis_ | ogra: are you pushing a fixed kernel snap to the store? | 11:46 |
| * zyga released snap-confine 1.0.40 just now | 11:55 | |
| tvoss | zyga, o/ | 12:15 |
| ogra | morphis_, already there but mvo needs to approve it again (https://myapps.developer.ubuntu.com/dev/click-apps/5573/rev/7/) | 12:20 |
| morphis_ | ogra: aye! | 12:20 |
| mvo | ogra: done | 12:23 |
| ogra | mvo, whom do i have to poke to get approval righty myself ... i really dont want to drag you away from your work all the time | 12:24 |
| ogra | *rights | 12:24 |
| jgdx | sergiusens, any way to quickly do a make build, then have those newly built files into prime? | 12:26 |
| morphis_ | ogra, mvo: hm, a snap refresh --edge pi2-kernel does give me any updates | 12:27 |
| morphis_ | ah! | 12:28 |
| ogra | it does here | 12:28 |
| morphis_ | that took a bit to go through | 12:28 |
| ogra | yeah, thats my fault ... forgot to press the publish button immediately | 12:28 |
| morphis_ | :-) | 12:33 |
| morphis_ | ogra: ah, there we go, a wlan0 is present now | 12:34 |
| ogra | yay | 12:34 |
| morphis_ | matteo: ^^ | 12:35 |
| bull | hi everyone :) | 12:45 |
| bull | why our snap cant read files inside it :D | 12:46 |
| ogra | where is "it" in that question ? :) | 12:48 |
| bull | ogra, why my snap cant read $SNAP/etc/xdg/Trolltech.conf | 12:55 |
| bull | ogra, am writing gui for snapcraft plz join and guide me where am wrong :P | 12:56 |
| ogra | bull, what makes you think it cant read the file, do you have any DENIED messages in syslog ? | 12:56 |
| bull | yes | 12:56 |
| ogra | can you put them into paste.ubuntu.com ? | 12:57 |
| bull | ogra, that is the same issue i faced yesterday . i was packaging supercalc and it says DENIED | 12:58 |
| bull | it should able to read $SNAP/etc/xdg/Trolltech.conf , i checked the xdg vars not set or hardcoded in my qt app | 12:58 |
| ogra | wasnt that trying to read another file ? | 12:59 |
| ogra | (i.e. without $SNAP) | 12:59 |
| bull | i copied that file to other location inside $SNAP and it saying denied again | 12:59 |
| bull | you mean outside $SNAP ? | 12:59 |
| ogra | and you fixed your binaty to actually read the file or accept the XDG location ? | 13:00 |
| ogra | *binary | 13:00 |
| ogra | this isnt really a snap problem ... | 13:00 |
| bull | bro why developer will mess with xdg path to pack their apps with snap | 13:00 |
| ogra | if your app does not respect the XDG_CONFIG_DIRS variable then there is a bug in your app (or in whatever loads the file) | 13:00 |
| bull | i mean they will excepting everything okay , cause this is unusual no packaging systems messs with what app looking for ? | 13:01 |
| ogra | these variables have been designed in the freedesktop standard to exactly allow re-location of binaries | 13:01 |
| ogra | so that you can run two versions of the same app alongside from different paths for example | 13:01 |
| ogra | if the app doesnt follow that standard you might need to fix it | 13:02 |
| === nessita_ is now known as nessita | ||
| bull | ogra, my app works fine on ubuntu 12.04 to 16.04 | 13:02 |
| * ogra wonders why there are so many QT apps that do not have such probs | 13:02 | |
| bull | with debian packaging | 13:02 |
| ogra | (we obviously have a good bunch in the store) | 13:02 |
| bull | qt4? | 13:03 |
| ogra | yes, debian packaging has full root access to the whole system ... | 13:03 |
| ogra | (and the according security issues too) | 13:03 |
| bull | ogra it is clear that my app want read $SNAP/etc/xdg/Trolltech.conf | 13:03 |
| jdstrand | sabdfl: hi! re 1615262> yes, I'll take care of it | 13:03 |
| bull | so my question - why snap cant read its ownstructure | 13:03 |
| ogra | bull, i dont understand | 13:04 |
| ogra | can you show the exact DENIED messages please | 13:04 |
| bull | why snap cant read its own structure ( $SNAP/etc/xdg/Trolltech.conf ) | 13:04 |
| bull | wait | 13:04 |
| ogra | (since you start giving contradicting info) | 13:05 |
| bull | http://paste.ubuntu.com/23078316/ | 13:06 |
| bull | its not snappy-debug | 13:06 |
| bull | it comes out directly when i run app | 13:06 |
| ogra | thats not a DENIED message | 13:06 |
| ogra | and doesnt talk about Trolltech.conf at all ! | 13:06 |
| bull | okay wait | 13:06 |
| bull | let me debug | 13:06 |
| bull | ogra, /snap/supercalc/x2/usr/bin/wrapper: /snap/supercalc/x2/trollconf: Permission denied | 13:08 |
| mup | PR snapcraft#747 closed: kernel plugin: vmlinuz -> kernel.img hard link <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/747> | 13:08 |
| ysionneau | Hi, webdm does not work anymore on my target, some xmlhttprequest answers a 500 error code when querying /api/v2/packages/?installed_only=true | 13:08 |
| ysionneau | any idea? | 13:08 |
| ysionneau | I only see a rotating Ubuntu logo | 13:08 |
| ogra | bull, please giv the DENIED messages from syslog ... | 13:08 |
| bull | it not logging anything | 13:09 |
| ogra | bull, when you try to run the app after you installed the snap | 13:09 |
| bull | sudo /snap/bin/snappy-debug.security scanlog | grep supercalc | 13:09 |
| ysionneau | no error in the journalctl -u snap.webdm.snappyd.service | 13:09 |
| ogra | ysionneau, there is a bug in the systemd unit, it doesnt wait for networking | 13:10 |
| jdstrand | bull: fyi, you probably simply want: sudo /snap/bin/snappy-debug.security scanlog supercalc | 13:10 |
| ysionneau | ogra: hmmm but I can browse the page though :o | 13:10 |
| ogra | ysionneau, oh, and it isnt called webdm anymore ;) it is snapweb now | 13:10 |
| bull | ysionneau, okay | 13:10 |
| ysionneau | ogra: well, when I do "snap find webdm" it finds it | 13:10 |
| ogra | oh, we need to unpublish it i guess | 13:10 |
| ysionneau | (and snap find snapweb does not find anything :o am I outdated somehow ?) | 13:10 |
| bull | ogra, i got it | 13:11 |
| ysionneau | I have ubuntu-core 16.04+20160531.12-01 | 13:11 |
| bull | ogra, http://paste.ubuntu.com/23078334/ | 13:11 |
| mup | PR snapcraft#748 opened: kernel plugin: vmlinuz -> kernel.img hard link <Created by piso77> <https://github.com/snapcore/snapcraft/pull/748> | 13:11 |
| ogra | ubuntu@pi2:~$ snap list snapweb | 13:11 |
| ogra | Name Version Rev Developer Notes | 13:11 |
| ogra | snapweb 0.20 4 canonical - | 13:11 |
| ogra | ubuntu@pi2:~$ | 13:11 |
| ogra | hmm, weird | 13:11 |
| ogra | snap find does indeed not find it | 13:12 |
| ysionneau | my version of webdm is 0.20 also :o | 13:12 |
| zyga | jdstrand: hey, how are you doing | 13:12 |
| ogra | ysionneau, thats super ancient | 13:12 |
| zyga | jdstrand: I would like to implement the setns feature | 13:12 |
| ysionneau | I just unsquashfs'ed it and resquashed' it, to fix the wrapper script to run the correct binary | 13:12 |
| zyga | jdstrand: I would appreciate any hints you have, I didn't fully read the converstation around that but I talked with stgraber at the sprint about it so I have an idea | 13:12 |
| ogra | ysionneau, is this on an all-snap image or oon classic ? | 13:13 |
| ysionneau | ogra: hmmm weird, that's on 16 series | 13:13 |
| ysionneau | http://pastebin.com/MXQXxchN <= I'm using this to generate my image | 13:13 |
| ogra | bull, so like i said, your app is broken, fix it to folow general standars for XDG dirs and it will work | 13:13 |
| ogra | there is no way around that | 13:13 |
| bull | daem | 13:14 |
| bull | ogra, should it work normal with debian install ?? | 13:14 |
| ogra | ysionneau, sudo snap install ubuntu-device-flash --devmode --edge | 13:14 |
| bull | i tested it on more then 5 PC | 13:14 |
| bull | of my friends and mine | 13:14 |
| ogra | bull, yes, because debian packages are not running in a sandbox and have full insecure root access | 13:14 |
| ogra | ysionneau, see mvo's mail to the mailing list about new images and how to build them, we now publish updates for u-d-f via a snap package | 13:15 |
| jdstrand | zyga: are you talking about for the shared mount namespace per snap bug? | 13:15 |
| ysionneau | ah nice ogra | 13:15 |
| ysionneau | do you think it's because of my old udf ? :o | 13:15 |
| mup | Bug #1595993 changed: go binaries use bind on startup, requiring network-bind <snapd-interface> <Snappy:Fix Released> <https://launchpad.net/bugs/1595993> | 13:16 |
| ogra | ysionneau, well, mainly because of your old ubuntu-core | 13:16 |
| bull | ogra, why you guys don't want app to read data ?? | 13:16 |
| ogra | but i dont think you can build any working images with the old udf | 13:16 |
| ysionneau | my old udf does not fetch a recent ubuntu-core ? :( | 13:16 |
| ysionneau | hmmm my image kinda work though | 13:16 |
| ysionneau | maybe everything is in the "kinda" | 13:16 |
| ogra | bull, there are plenty apps in the store that read data from various places | 13:16 |
| ogra | bull, they simply follow established standards | 13:16 |
| ogra | yours does not seem to | 13:17 |
| ogra | ysionneau, definitely :) | 13:17 |
| ysionneau | error: unknown flag `edge' <= | 13:17 |
| ysionneau | (I'm on debian testing) | 13:17 |
| bull | its not like that , it simply cant read /snap/supercalc/x1/trollconf | 13:17 |
| ogra | ysionneau, is your snapd up to date ? | 13:17 |
| ysionneau | I just installed it | 13:17 |
| ogra | ogra@anubis:~$ snap --version | 13:17 |
| ogra | snap 2.12+ppa203-1 | 13:17 |
| ogra | snapd 2.12+ppa203-1 | 13:17 |
| ogra | series 16 | 13:17 |
| ogra | ubuntu 16.04 | 13:17 |
| ysionneau | Get:5 http://debian.univ-lorraine.fr/debian unstable/main amd64 snapd amd64 2.0.8+1 [4,352 kB] | 13:17 |
| ogra | i think you need at least 2.11 | 13:17 |
| ysionneau | yann@imperium:~/dev/workspace2$ snap --version | 13:18 |
| ysionneau | snap | 13:18 |
| ysionneau | snapd unknown (series 16) | 13:18 |
| ogra | oh | 13:18 |
| bull | ogra ty | 13:18 |
| ogra | bull, that is not what the DENIED message says | 13:18 |
| ogra | it does not try to reat /snap/supercalc/x1/trollconf there | 13:18 |
| ogra | so what makes you think it cant ? | 13:18 |
| bull | then? | 13:18 |
| bull | ogra, okay i will dig it , | 13:19 |
| bull | ogra, my app can read anything inside $SNAP right >? | 13:19 |
| ogra | bull, yes | 13:19 |
| ysionneau | even in debian unstable it seems to be snapd 2.0.8+1 :/ | 13:19 |
| bull | i have few more question - i have an app which writes data to user's home directory , do snap allow that ? | 13:20 |
| ogra | and it can write to $SNAP_DATA (for daemons/services) and to SNAP_USER_DATA (for user apps) | 13:20 |
| ogra | bull, you can either write to SNAP_USER_DATA or you can use the home interface in your snapcraft.yaml | 13:20 |
| bull | oh $SNAP_DATA ? | 13:21 |
| ogra | note that this does not allow access to "dot" dirs unside home | 13:21 |
| bull | :) | 13:21 |
| ogra | *inside | 13:21 |
| zyga | jdstrand: yes | 13:21 |
| bull | damn | 13:21 |
| bull | what :D | 13:21 |
| ogra | since that would be a security hole | 13:21 |
| ogra | (apps could spy on other apps etc) | 13:21 |
| bull | qt writes app data inside .local/data/yourapp.com/ | 13:21 |
| bull | that mean snap will break qt ?? | 13:22 |
| ogra | so set the right XDG variable to make it write to SNAP__USER_DATA instead | 13:22 |
| ogra | again, there are tons of Qt apps in the store that work fine | 13:22 |
| jdstrand | zyga: I think it would be helpful to read through that bug before we talk about it. I can say, at the highest level you simply give setns the pid and CLONE_NEWNS for the mount you want to go into | 13:23 |
| bull | this is not easy for everyone , so why don't you guys make set these paths since you know snap will write data there only | 13:23 |
| bull | ogra, there should be better documentation in site | 13:23 |
| ogra | the desktop-launcher sets these paths usually | 13:23 |
| jdstrand | zyga: so, 'just' need enter the mount namespace of another command if it is running, otherwise create a new one | 13:24 |
| ogra | but if your app does not respect the XDG variables you have to fiix the app | 13:24 |
| bull | what snap allow and what not !! where user have to fix their apps and everything | 13:24 |
| bull | okay thanks | 13:24 |
| ogra | bull, btw, the guys that do app packaging are in https://gitter.im/ubuntu/snappy-playpen ... perhaps they have some ideas | 13:24 |
| zyga | jdstrand: yes, this is obviously a race, I wanted to think about how to solve this | 13:24 |
| jdstrand | zyga: 'just' is the hard part. I can think of a robust implementation using security labels. I don't yet for cross-distro | 13:24 |
| ogra | bull, i told you what snap allows and obviously other packagers do not have big problems with that | 13:25 |
| zyga | jdstrand: I was thinking that snap-confi e could fork a per-$SNAP_NAME process that just hangs around forever | 13:25 |
| zyga | jdstrand: that sets up a separate mount namespace | 13:25 |
| bull | ogra, what you think of making snapcraft gui ?? will it be a task that can be attained or what ? | 13:25 |
| zyga | jdstrand: but doensn't hold any files open and chdirs to / | 13:25 |
| zyga | jdstrand: with the sole goal of being easy to find | 13:25 |
| zyga | jdstrand: I could use prctl to tweak the process name so that I can find it | 13:25 |
| zyga | jdstrand: and I could use /proc/$pid/exe to find the executable as a confirmation check | 13:26 |
| jdstrand | don't do that | 13:26 |
| jdstrand | not the prctl part anyway | 13:26 |
| ogra | bull, well, why not ... (not that i'd use it ... after all you have to manually edit files, create wrappers etc so in the end you use an editor anyway) | 13:26 |
| jdstrand | since applications can change their command name | 13:26 |
| bull | i mean it will make easy pack snaps and we can help users showing more info , scanlog etc | 13:26 |
| zyga | jdstrand: snap-confine --zygote $SNAP_NAME would not run any apps | 13:26 |
| zyga | jdstrand: it would just sleep forever having unshared the mount namespace | 13:27 |
| bull | ogra, we will having simple buttons to create files , check errors in yaml file | 13:27 |
| bull | :D | 13:27 |
| zyga | jdstrand: each snap-confine that actually wnats to start an app would wait for the zygote or launch one | 13:27 |
| ogra | bull, sure, i wont hold you back ... | 13:27 |
| zyga | jdstrand: (with the usual trickiness on how to make this race-free and reliable) | 13:28 |
| ogra | but for me packaging is mostly a commandline task anyway ... and all the tools i need there are existing already | 13:28 |
| bull | i initiated a github repo plz keep me updated with features and stuffs we can add to it | 13:28 |
| jdstrand | zyga: the security label approach was-- fork, note its PID, create a sumlink from /var/lib/snapd/mountpids/snap.hello-world -> /proc/<pid>/ns (or whatever). then enter that namespace, then verify the security label of that process, if different, die() | 13:28 |
| ogra | so you shoudl try to find someone who wants to use such a tool and have him/her give you feedback | 13:28 |
| jdstrand | zyga: you could do your technique with the symlink approach | 13:28 |
| ogra | https://gitter.im/ubuntu/snappy-playpen is probably the best place for this | 13:28 |
| bull | ogra, you are in deep bro , you know everything so its easy for you , i seen people and myself find it hard to figure things out :D | 13:29 |
| ogra | yes, thats why i'm saying i'm the wrong target audience | 13:29 |
| ogra | i know that bzoltan's team aslo wroks on integration snapcraft into the ubuntu SDK | 13:29 |
| jdstrand | zyga: but don't have --zygote | 13:29 |
| ogra | probably you can help there or give them your tool for integration ot for ideas at least | 13:30 |
| ogra | *integration of | 13:30 |
| bull | all i want from you to guide me like you doing here , if i go wrong with the concept anywhere in the gui version of snapcraft , i need you to guide me | 13:30 |
| bull | i will be asking few more people relating to project for sure | 13:31 |
| ogra | no, you dont | 13:31 |
| bull | :D | 13:31 |
| ogra | there are 282 people in this channel, do you think i'm the only one with knowledge ? | 13:31 |
| jdstrand | zyga: ie, run the app, fork this process that will hang around, note its pid, create the symlink, go into it. on the next app launch the symlink exists, so go into it. on systems with a security label, also verify it | 13:31 |
| bull | no, i mean you are one of them , chill | 13:31 |
| zyga | jdstrand: mmmm | 13:31 |
| ogra | bull, also, the packaging specialists are realy at https://gitter.im/ubuntu/snappy-playpen ... as i said a few times already | 13:32 |
| zyga | jdstrand: and the forked one should just sit around forever? | 13:32 |
| bull | zyga, ty | 13:32 |
| jdstrand | zyga: with this idea, yes | 13:32 |
| zyga | jdstrand: I'll finish my current call and wrap my head around this and get back to you, thank you for the idea | 13:32 |
| jdstrand | zyga: note, niemeyer specifically requested reviewing the design, and I know tyhicks (and maybe ratliff) would as well as me | 13:33 |
| mhall119 | zyga: quick work there, thanks :) | 13:33 |
| bull | mhall119, hi :) | 13:33 |
| mhall119 | hi bull | 13:33 |
| zyga | mhall119: my pleasure, I'm sorry I didn't finish the article on content sharing | 13:34 |
| bull | i snapped supercalc but it running only with devmode for now there is a bug in my app which wont allow it to run , http://paste.ubuntu.com/23078334/ | 13:35 |
| bull | mhall119, https://github.com/keshavbhatt/supercalc | 13:35 |
| ogra | bull, soo ... if you fix the broken line in your wrapper the error will go away ... | 13:36 |
| bull | ogra, and whats that >?? | 13:36 |
| ogra | (you could have poinnted me to that before ... ) | 13:37 |
| ogra | shell vearibles do not allow spaces ... fix your line 3 | 13:37 |
| bull | popey, already checked that | 13:37 |
| bull | ogra, wait | 13:37 |
| bull | ogra, you mean this- XDG_CONFIG_DIRS= $SNAP/trollconf to ---- XDG_CONFIG_DIRS=$SNAP/trollconf | 13:38 |
| bull | ? | 13:38 |
| ogra | yes | 13:38 |
| bull | daem | 13:38 |
| ogra | (not sure if that will help when your app doesnt respect the freedesktop standards though ... but it will fix your error) | 13:38 |
| bull | okay :D let me check | 13:39 |
| ysionneau | hmm doesn't seem it works nicely to run snapd and stuff in docker | 13:39 |
| ogra | i think there is a bug open for that | 13:40 |
| bull | anyone interested in packing a awesome qml music player https://github.com/keshavbhatt/kmusicplay | 13:40 |
| bull | ogra, will the changes will added to stage area automatically when i will run snapcraft after making chnages to wrapper script ? | 13:41 |
| ogra | no. you need to clean | 13:41 |
| ogra | (at least the stage and prime steps i think) | 13:41 |
| bull | this is not good feature snapcraft offering :D | 13:41 |
| bull | cleaning stage will download dependencies again right ?? | 13:42 |
| ogra | no. thats pull | 13:43 |
| bull | okay ty | 13:43 |
| ogra | (as described in detail in "snapcraft --help" ) | 13:45 |
| bull | ty | 13:45 |
| mup | PR snapd#1686 closed: boot: add support for "devmode: {true,false}" in seed.yaml <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1686> | 13:53 |
| mhall119 | well, now I've submitted fixes to snapcraft and snap-confine, I guess snapd is next | 13:55 |
| mhall119 | zyga: are you still going to do a blog post? | 13:56 |
| ysionneau | ogra: on Ubuntu Xenial, I can install webdm but not snapweb is found (on amd64), normal? | 13:57 |
| ysionneau | no* | 13:57 |
| bull | ogra, am not compiling my app from source using snapcraft , am just copying the binary using snapcraft , so do you think compiling with snapcraft qmake plugin will make the difference ?? | 13:57 |
| zyga | mhall119: yes, just swamped with more important things now | 14:03 |
| ogra | ysionneau, yeah, try "sudo snap install snapweb --edge" | 14:19 |
| ogra | (it seems to only be in the edge channel) | 14:20 |
| ogra | bull, no idea, most of the time you dont need to change the apps ... | 14:21 |
| ogra | but yours seems special | 14:21 |
| eldarkg | Hello guys. What about the state of this bug https://bugs.launchpad.net/snappy/+bug/1580740 (xdg-open) | 14:21 |
| mup | Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link <snap-desktop-issue> <verification-needed> <Snappy:Triaged> <snapd-xdg-open (Ubuntu):Confirmed> <snapd-xdg-open (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1580740> | 14:21 |
| ogra | eldarkg, i know that the needed bits in the ubuntu-core package landed last week, not sure which bits of snap-confine are needed additionally for it though, seb128 and zyga might know | 14:25 |
| eldarkg | ogra: thx | 14:26 |
| mhall119 | zyga: I recall you mentioned working on allowing content sharing slots to support multiple plugs (though I assume now that it should be the other way around), is that implemented? | 14:26 |
| eldarkg | zyga: hello. Are u there? | 14:26 |
| eldarkg | seb128: hi. Are u here? | 14:27 |
| zyga | eldarkg: hey | 14:27 |
| zyga | mhall119: no, thre's no bug report either, if you report it please give me a link | 14:28 |
| eldarkg | zyga: what u say about bug https://bugs.launchpad.net/snappy/+bug/1580740 | 14:28 |
| mup | Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link <snap-desktop-issue> <verification-needed> <Snappy:Triaged> <snapd-xdg-open (Ubuntu):Confirmed> <snapd-xdg-open (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1580740> | 14:28 |
| zyga | mhall119: it the way I imagine it is that the current interface will start to refuse connecting more than one item | 14:28 |
| zyga | mhall119: and there will be an attribute a slot can set, like "multi: yes" or similar | 14:28 |
| zyga | mhall119: where the target will be a directory that will now instead contain individual bind mounts | 14:29 |
| zyga | mhall119: e.g. plugins.d/plug-1 plugins.d/plug-2 | 14:29 |
| zyga | mhall119: where plug-1, 2, 3, etc would be maintained by snapd (the actual snap would just contain the empty directory) | 14:29 |
| zyga | mhall119: there's a little feature work to support that but it is well understood | 14:29 |
| eldarkg | zyga: how I can to give permission to snap app to open file with system viewer (like browser or evince)? | 14:30 |
| mhall119 | zyga: cool, though I assume you mean that the plug will have this attribute, since it is the consuming end of the interface | 14:30 |
| zyga | mhall119: er, yeah, the consuming side | 14:31 |
| zyga | eldarkg: that depends, what would the URL look like? | 14:31 |
| zyga | eldarkg: this falls into content hub territory | 14:31 |
| zyga | eldarkg: I agree this should be supported but I'm unsure how | 14:31 |
| ogra | zyga, well, didnt we have some basic xdg-open integration ? i definitely landed a fix from the desktop team in ubuntu-core last week | 14:32 |
| mhall119 | zyga: thre was the snap-xdg-open ->(dbus)->xdg-open bridge that was being worked on | 14:32 |
| zyga | ogra: we do but it is whitelist based | 14:32 |
| ogra | right | 14:32 |
| zyga | mhall119: I'm well aware of it | 14:32 |
| seb128 | eldarkg, hey | 14:32 |
| * zyga has to package that for al the distros next | 14:32 | |
| ogra | i thought that was part fo the snap-confine package (i could be wrong indeed) | 14:32 |
| zyga | though probably along with snapd itself | 14:32 |
| eldarkg | zyga: url like the system path | 14:32 |
| zyga | ogra: nope | 14:32 |
| zyga | ogra: snap-confine will merge with snapd this week | 14:32 |
| ogra | ah | 14:32 |
| ogra | neat | 14:32 |
| mhall119 | zyga: is the whitelist a list of apps, or url schemas? | 14:33 |
| eldarkg | seb128: how I can to give permission to snap app to open file with system viewer (like browser or evince)? | 14:33 |
| seb128 | zyga, ogra, eldarkg, xdg-open is to open urls, it's not going to let you open content, that's content-hub material | 14:33 |
| zyga | eldarkg: system path is not an URL as it lacks he scheme, a file:// url might be something but those may be confusing (due to how snap-confine works) | 14:33 |
| seb128 | eldarkg, browser or evince? those are different usecases | 14:33 |
| zyga | mhall119: schemas | 14:33 |
| zyga | seb128: I agree, hence my earlier comment | 14:33 |
| ogra | seb128, bug 1580740 only talks about browser links | 14:33 |
| mup | Bug #1580740: [SRU] Cannot open a browser link from a snap that provides a link <snap-desktop-issue> <verification-needed> <Snappy:Triaged> <snapd-xdg-open (Ubuntu):Confirmed> <snapd-xdg-open (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1580740> | 14:33 |
| seb128 | ogra, right, but eldarkg seems to ask about evince | 14:33 |
| ogra | and i know we landed the ubuntu-core side of it | 14:33 |
| seb128 | which we don't have addressed yet | 14:34 |
| seb128 | haven't* | 14:34 |
| ogra | right | 14:34 |
| eldarkg | seb128: open pdf with system viewer for example | 14:34 |
| ogra | it also needs the new ubuntu-core promoted to the stable channel | 14:34 |
| seb128 | eldarkg, that needs work, you can't do that today | 14:35 |
| ogra | (i'm running --edge on my desktop machine since last week, seems pretty stable ) | 14:35 |
| eldarkg | seb128: ok. Is it in process? | 14:35 |
| seb128 | eldarkg, not that I know of | 14:35 |
| eldarkg | seb128: what about open url with browser? | 14:35 |
| seb128 | that's being worked on | 14:36 |
| seb128 | it should be working on the edge channel | 14:36 |
| ogra | doesnt | 14:36 |
| ogra | since the desktop side is still missing | 14:36 |
| seb128 | you just need an updated ubuntu-core and snapd-xdg-open installed | 14:36 |
| ogra | right, that latter part isnt automatic | 14:36 |
| seb128 | ogra, install https://launchpad.net/ubuntu/+source/snapd-xdg-open | 14:36 |
| ogra | yeah | 14:36 |
| ogra | doing so now | 14:36 |
| eldarkg | seb128: sudo snap refresh --edge ubuntu-core? | 14:37 |
| seb128 | I guess? | 14:38 |
| seb128 | ogra, ^ that refresh command is right? | 14:38 |
| ogra | yeah | 14:38 |
| ogra | (i always put --edge last ... not sure that mmatters though) | 14:38 |
| ogra | hmm, nope | 14:39 |
| ogra | virtual bool QGenericUnixServices::openUrl(const QUrl&): Unable to detect a web browser to launch 'https://krita.org/' | 14:39 |
| eldarkg | seb128: another snapcraft things? | 14:40 |
| lazyPower | greetings o/ it appears the rpi2 images for snappy-core are in a really inconsistent state. Is this known or should I start crafting a bug? | 14:40 |
| ogra | lazyPower, since they are experimental thats not a surprise ... though last weeks images should be fine now | 14:41 |
| lazyPower | ogra - well, not really. i flashed a couple boards this weekend. I'm unable to install snaps, and if i apt-get upgrade it bricks the board's modules (no networking, et-al) | 14:41 |
| ogra | lazyPower, apt ??? | 14:42 |
| lazyPower | yeah, thats what i said | 14:42 |
| lazyPower | its like it boots in classic mode | 14:42 |
| seb128 | ogra, :-/ | 14:42 |
| seb128 | ogra, does xdg-open https://krita.org works? | 14:42 |
| ogra | lazyPower, where did you get the images ? | 14:42 |
| seb128 | ogra, from hello.bash or something | 14:42 |
| lazyPower | ogra - http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ | 14:42 |
| ogra | seb128, works, yes | 14:43 |
| ogra | lazyPower, eeek ... no ... | 14:43 |
| seb128 | ogra, do you have any gtk app snap? | 14:43 |
| ogra | lazyPower, http://people.canonical.com/~mvo/all-snaps/16/ | 14:43 |
| seb128 | ogra, if so can you try from a about dialog if you can open their website? | 14:43 |
| mup | PR snapd#1699 closed: introduce the "lxd" interface <Blocked> <Created by tych0> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1699> | 14:44 |
| lazyPower | ogra - ack will give this a go and let you know how i make out with it. can i suggest we get some update lovin on the developer portal? its linking aginst the images i posted above, and the rpi2 image is terribly broken rn | 14:44 |
| ogra | trying in my gitter app: | 14:44 |
| ogra | LaunchProcess: failed to execvp: | 14:44 |
| ogra | xdg-open | 14:44 |
| ogra | seb128, ^^ | 14:44 |
| ogra | (thats using electron and is installed in --devmode) | 14:44 |
| ogra | i wonder if snap refresh ubuntu-core doesnt really apply without reboot or restart of snapd | 14:45 |
| ysionneau | ogra: I've installed snapweb --edge in an Ubuntu Xenial. Listing installed snaps does work this time. However, when I click on "Browse store", I get an error 500 | 14:45 |
| seb128 | ogra, :-/ | 14:45 |
| ysionneau | on the /api/v2/packages | 14:45 |
| ogra | ysionneau, yeah, its still buggy | 14:45 |
| ogra | lazyPower, gimme a few, i'll wipe the dir on cdimage | 14:45 |
| ysionneau | is someone actively working on fixing it? | 14:46 |
| ogra | leftyfb, http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/ ... :) | 14:47 |
| leftyfb | ogra: ? | 14:48 |
| ogra | back to the "please use classic" text now ... that they were there was an accident ... we currently dont use cdimage for them | 14:48 |
| ogra | the experimental images are good enough to get an alpha release though ... i guess we can put them there by end of the week | 14:49 |
| ogra | niemeyer, do you happen to have the final kernel.yaml spec handy somehow ? i'm trying to figure out where/how to add daemons and binaries that are required for drivers | 14:54 |
| ogra | (trying to get the rpi graphics driver working, but that needs a bunch of config binaries shipped along) | 14:55 |
| elopio | export BYOBU_CHARMAP=x ; . ~/.bashrc | 14:59 |
| niemeyer | ogra: Daemons and binaries are not part of the kernel spec so far | 15:10 |
| niemeyer | ogra: A daemon would be just like any other snap | 15:11 |
| ogra | niemeyer, well, i have a workitem to get all-snap images ready for graphics for RTM | 15:11 |
| ogra | and these binaryies need to go together with the drivers | 15:11 |
| ogra | inside the kernel snap | 15:11 |
| ogra | and also with udev rules and the like | 15:12 |
| ogra | i was told in heidelberg that the kernel spac was done and would cover evereything :( | 15:12 |
| ogra | niemeyer, many arm drivers actually need daemons to even init the drivers i.e. PVR/SXG ships the whole binary blob inside a userspace daemon, the kernel driver only provides some stubs that attaches to | 15:13 |
| niemeyer | ogra: As I just said, there's nothing special about that | 15:14 |
| ogra | and we cant realyl ship these separated from the kernel module | 15:14 |
| niemeyer | ogra: Just add a daemon to the snap | 15:14 |
| ogra | since they are 100% bound to each others version | 15:14 |
| niemeyer | ogra: the kernel snap is still a snap | 15:14 |
| ogra | niemeyer, right, but if i put something in /usr/bin in the kernel snap it will be ignored | 15:15 |
| niemeyer | mvo: Can you think of any reasons why a daemon wouldn't work in the kernel snap? | 15:15 |
| niemeyer | ogra: You won't put something in /usr/bin.. it's still a snap | 15:15 |
| ogra | if the binary blob in the kernel expects its daemon to be at /usr/bin/foobar and the kernel snap doesnt bind mount it there the driver will not work | 15:15 |
| niemeyer | ogra: Add a daemon just like any other snap | 15:15 |
| ogra | and since it is a binary blob i cant change the path | 15:16 |
| * ogra curses that he had a conflicting meeting in heidelberg when the kernel snap was discussed ... | 15:16 | |
| niemeyer | ogra: THat's not usually how such daemons work | 15:16 |
| ogra | niemeyer, tell that to the vendors :) | 15:17 |
| niemeyer | ogra: Where can I see the code? | 15:17 |
| ogra | you cant ... i.e. the pvr daemon is a binary blob | 15:17 |
| ogra | i can probably get along with your suggestion for the pi for now though | 15:18 |
| ogra | there the daemons just need the device nodes afaik | 15:18 |
| lool | hi all | 15:18 |
| lool | elopio: hey, how is it going? | 15:18 |
| ogra | but i think long term the kernel snap needs some special handling for this ... especially once we go for more exotic arm devices | 15:19 |
| niemeyer | ogra: Where can I find the code for that driver? The binary blob is necessarily not alone or it'd not like against the kernel | 15:19 |
| lool | elopio: before I left for a week you had built a snapweb with a hotfix for the store search issue http://people.ubuntu.com/~elopio/snaps/ | 15:19 |
| niemeyer | ogra: In general it is the deamon that talks to the module, not the other way around | 15:19 |
| lool | elopio: did you end up pushing it in the source code / in the store? is there an armhf build of it? | 15:19 |
| niemeyer | ogra: The module doesn't go looking for daemon paths in the filesystem | 15:20 |
| elopio | lool: no, nothing much other than that. I have the PR here, I will propose it for you to +1. | 15:20 |
| elopio | lool: I worked a little on multiarch with launchpad, but there's a problem in there that makes the import fail: https://bugs.launchpad.net/launchpad/+bug/1084403 | 15:21 |
| mup | Bug #1084403: no support for gpgsig tags <amd64> <apport-bug> <patch> <raring> <running-unity> <Bazaar Git Plugin:Triaged> <One Hundred Papercuts:Invalid> <Launchpad itself:Triaged> <pyMOR:Invalid> <bzr-git (Ubuntu):Triaged> <https://launchpad.net/bugs/1084403> | 15:21 |
| lool | elopio: awesome thanks | 15:21 |
| ogra | niemeyer, i'm pretty sure pvr does that (at lest it used to on the pandaboard and on the maguro phone we had), the pi stuff is on https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+packages ... raspberrypi-vc - 1.20150502.d280099-1 | 15:21 |
| elopio | in the meantime, we can have auto uploads from travis to amd64. | 15:22 |
| lool | elopio: I actually need a fixed armhf | 15:22 |
| lool | and I dont think we can build go under qemu-arm | 15:22 |
| niemeyer | ogra: Do you have a link for the source code repository of the driver? | 15:23 |
| lool | I could build it by hand | 15:23 |
| ogra | niemeyer, sadly not | 15:23 |
| ogra | niemeyer, only the deb src in that PPA | 15:23 |
| niemeyer | ogra: Ok, so I cannot look at that right now, but I suggest investigating more carefully | 15:23 |
| ogra | niemeyer, will do | 15:23 |
| niemeyer | ogra: WIlling to bet the kernel module doesn't fire a daemon in user space | 15:23 |
| ogra | iirc in pvr it was re-execing it with other options | 15:25 |
| ogra | (pvr is the worst here though) | 15:25 |
| ogra | the shiniest hardware you can imagine with the worst driver you can imagine :) | 15:26 |
| niemeyer | ogra: Even there, willing to bet the kernel module doesn't start the daemon in user space | 15:27 |
| bull | ogra, you know ogre ? | 15:27 |
| ogra | bull, you know bill ? | 15:27 |
| bull | haha :D no | 15:28 |
| ogra | same here | 15:28 |
| ali1234 | how do you guys deal with constantly downloading the same deb files over and over? | 15:28 |
| ogra | ali1234, sudo snap install packageproxy ... pint my sources.list to localhost:9999 and be done | 15:28 |
| ogra | *point | 15:28 |
| ali1234 | does that work for foreign repos? | 15:29 |
| ogra | needs config fiddling, but indeed it does ... (packagproxy just uses approx inside) | 15:29 |
| ali1234 | and what about if i do cleanbuild? | 15:29 |
| ogra | thats different | 15:29 |
| ali1234 | how do i get the right sources.list inside it? | 15:29 |
| ali1234 | or multistrap? cdebootstrap? | 15:29 |
| ogra | but there you could create an lxc container that doesnt get wiped | 15:30 |
| bull | ogra, ogre is tekken character , | 15:30 |
| niemeyer | ogra: | 15:30 |
| niemeyer | sudo cp /opt/pvr/pvr /etc/rcS.d/S60pvr.sh | 15:30 |
| niemeyer | sudo chmod +x /etc/rcS.d/S60pvr.sh | 15:30 |
| niemeyer | http://elinux.org/BeagleBoardUbuntuKarmic | 15:31 |
| elopio | lool: I can build it in scalingstack. Do you need it right now? | 15:32 |
| lool | elopio: the sooner the better, but can wait a bit | 15:32 |
| lool | elopio: sharing details in query | 15:33 |
| niemeyer | ogra: I need to be able to trust you to investigate those details carefully, otherwise we'll end up with a kernel snap that makes no sense | 15:33 |
| ogra | niemeyer, yeah, i'm just starting digging here, still we will need GL libs in /lib abnd such ... there need to be bind mounts | 15:34 |
| ogra | niemeyer, where are these described | 15:34 |
| niemeyer | ogra: Have a look at the gl interface in snapd | 15:35 |
| ogra | ok | 15:35 |
| niemeyer | ogra: We may need to evolve it, but we're most of the way there already I think | 15:35 |
| niemeyer | ogra: mvo has more insight than I do there | 15:35 |
| ogra | right, i just need to know what the kenrel snap needs as a first step ... i.e. where and how do i ship them so they end up in the right places ... but i'll dig my way around | 15:36 |
| niemeyer | 👍 | 15:36 |
| * niemeyer => lunch | 15:36 | |
| bull | 👍 | 15:36 |
| bull | :D | 15:37 |
| ogra | btw, that beagle page only copies the start script around, there are a few MB in /opt/pvr it doesnt even mention :) | 15:37 |
| ogra | niemeyer, enjoy your free afternoon :) | 15:37 |
| bull | how to change name here ??? | 15:37 |
| ogra | geez ,... testing the new pi3 image here ... even the pi3 needs 10+ minutes for the first cloud-init run ... so depressing :/ | 15:38 |
| bull | hurrey | 15:38 |
| === bull is now known as bulldog | ||
| qengho | ogra: What's taking the time? | 15:41 |
| bulldog | bull is known as bulldog now :D | 15:41 |
| ogra | qengho, hard to tell ... but i gues python :P | 15:41 |
| ogra | python and arm have never been good friends | 15:41 |
| ogra | yay | 15:43 |
| ogra | pi3 with wlan0 ... | 15:43 |
| * ogra can finally get rid of the wires on his desk | 15:44 | |
| ali1234 | ogra: do you have a touchscreen display on your pi? | 15:44 |
| ogra | nope | 15:44 |
| ali1234 | well, touchscreen is broken in ubuntu... | 15:45 |
| ogra | send me one and i'll make it work :P | 15:45 |
| ali1234 | i assume you have hdmi connected then, if you're testing graphics? | 15:46 |
| ogra | not atm, no | 15:46 |
| lazyPower | are there any snaps using the dump plugin i can reference? i searched and did not find any in the snappy-playpen | 15:46 |
| ogra | currently i'm rolling kernel snaps | 15:46 |
| ogra | *testing* is far out | 15:46 |
| ogra | first of all i'll need to *ship* all bits :) | 15:47 |
| ali1234 | ogra: how do i configure the packageproxy snap then? | 15:48 |
| ogra | ali1234, https://github.com/ogra1/packageproxy | 15:49 |
| lazyPower | nvm found it in the snapcraft repository | 15:49 |
| ali1234 | yes i've seen that | 15:49 |
| ali1234 | config.yaml, how do i change it? do i have to rebuidl the snap? | 15:49 |
| ogra | sudo vi /var/snap/packageproxy/current/config.yaml | 15:49 |
| ogra | edit the repos list | 15:50 |
| ogra | then: sudo systemctl restart snap.packageproxy.approx.service | 15:50 |
| bulldog | we can build daily snap on launchpad too wow | 15:50 |
| ali1234 | okay. and what if i need to mirror two repos that have the same suite name? | 15:50 |
| ali1234 | er, distro name sorry | 15:50 |
| ogra | ali1234, you give them different aliases | 15:50 |
| ogra | you just need to reflect that in your sources.list then | 15:51 |
| ali1234 | okay. and by default this server is accessible on my lan, correct? | 15:52 |
| ogra | if you find it to compilcated you can also just use apt-cacher or a squd based packageproxy | 15:52 |
| ogra | yes, sure ... it listens on 9999 on the machine you install it on | 15:52 |
| ogra | on all interfaces the machine has | 15:52 |
| ali1234 | the main issue for me is that i am trying to make a reproducible build script, but other people aren't going to have a package proxy | 15:53 |
| ali1234 | actually two build scripts, one using multistrap and the other one using debirf | 15:53 |
| ogra | well, but other people probably have gigabit fiber lines ... who knows :) | 15:53 |
| ali1234 | yes but it means i have to maintain two versions of the script... one for me and one for everyone else | 15:53 |
| ali1234 | unless there is an entirely transparent way to do it | 15:54 |
| ogra | i dont thin there is | 15:54 |
| ogra | +k | 15:54 |
| xavi | Hi all!, even though I guess this is not the best channel, any one can point me to some doc in order to mount encrypted partitions with snappy ? | 15:55 |
| xavi | or mailing list | 15:55 |
| ali1234 | the other issue is that since i am doing a bootstrap then the apt config ends up inside the resulting image which i don't want | 15:56 |
| ali1234 | ah i know | 15:58 |
| ali1234 | i can put the hostnames in /etc/hosts | 15:58 |
| ali1234 | to redirect them to my local cache | 15:58 |
| ali1234 | then my config doesn't change | 15:58 |
| ali1234 | does snap see the hosts's /etc/hosts? | 15:59 |
| mvo | ogra: just reading backlog, maybe we should have a call later today (after dinner) or tomorrow morning to catchup on this? and do a strawman proposal | 16:00 |
| ogra | mvo, tomorrow rather ... | 16:00 |
| * ogra feels monadyish and wants to drop out early today | 16:01 | |
| ogra | and i'd also like to collect more info about the pi and dragonboard setups first | 16:01 |
| ogra | one thing that bothers me a bit are namesapces ... if i ship daemons or such in the kernel snap, they won't be callable with their names but only via pi2-kernel.$dameon-name | 16:02 |
| === chihchun is now known as chihchun_afk | ||
| mvo | ogra: ok | 16:03 |
| qengho | 16:08 | |
| eldarkg | I don't know it is a right place or not. But how to create automatic builds in LP one repo (with snapcraft.yaml) when changed another repo (with build app source)? | 16:13 |
| mhall119 | zyga: am I correct to assume that code shared via the content-hub will run under the confinement profile of the consuming snap? | 16:14 |
| ali1234 | there's a snap in the store that looks fishy, what do? | 16:15 |
| bulldog | ali1234, which one ? :D | 16:16 |
| eldarkg | seb128: I don't know it is a right place or not. But how to create automatic builds in LP one repo (with snapcraft.yaml) when changed another repo (with build app source)? | 16:18 |
| seb128 | eldarkg, no idea about that, try asking on #launchpad? | 16:19 |
| eldarkg | seb128: thx | 16:19 |
| seb128 | yw! | 16:19 |
| zyga | mhall119: content hub or the content interface? | 16:20 |
| ali1234 | http://askubuntu.com/q/815431/12435 | 16:24 |
| elopio | lool: here's the pr: https://github.com/snapcore/snapweb/pull/50 | 16:25 |
| mup | PR snapweb#50: Patch getting all the snaps <Created by elopio> <https://github.com/snapcore/snapweb/pull/50> | 16:25 |
| elopio | lool: but now it is failing to build: http://paste.ubuntu.com/23078669/ Do you know grunt? | 16:25 |
| mhall119 | zyga: content interface | 16:26 |
| mhall119 | sorry, not sure why I typed content-hub | 16:26 |
| mhall119 | muscle memory | 16:26 |
| lool | tyhicks, jdstrand: Hi! are abstract sockets connections allowed by default when one has network interface (and connect() etc. are allowed)? | 16:26 |
| lool | elopio: ah crap, I had that myself at some point | 16:26 |
| jdstrand | lool: no. https://bugs.launchpad.net/snappy/+bug/1604967 | 16:27 |
| mup | Bug #1604967: Apparmor denies bind to abstract unix sockets such as @/var/lib/juju/mutex-/store-lock <conjure> <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1604967> | 16:27 |
| mhall119 | seb128: was it you who said the generic dbus name interface was being worked on? | 16:27 |
| lool | elopio: there are super specific installation instructions, perhaps try in a clean chroot? | 16:27 |
| lool | elopio: the deps are a bit ouf of date and hardcoded | 16:27 |
| jdstrand | cc tyhicks ^ | 16:27 |
| lool | jdstrand: ok, I was just told otherwise by someone who had an unconfined daemon but confined client | 16:27 |
| lool | ysionneau: ^ | 16:27 |
| jdstrand | lool: we will, but not for a little while yet (other higher priority items are in front of that) | 16:27 |
| seb128 | mhall119, talk to jdstrand | 16:27 |
| seb128 | mhall119, bug #1590679 | 16:28 |
| mup | Bug #1590679: Apps can't own session bus names (unity7 interface) <snap-desktop-issue> <snapd-interface> <Snappy:In Progress by jdstrand> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1590679> | 16:28 |
| lool | jdstrand: that's fine, I was actually surprized they *could* connect when I was expecting not | 16:28 |
| jdstrand | lool: so, we want snaps to be able to connect to themselves | 16:28 |
| mhall119 | thanks seb128 | 16:28 |
| seb128 | yw | 16:28 |
| lool | jdstrand: these would be 2 separate snaps according to ysionneau | 16:28 |
| jdstrand | I'd be interested in seeing those snaps | 16:29 |
| lool | ysionneau: if that's indeed possible, it sounds like a bug we should plug | 16:29 |
| ysionneau | please don't plug this before 9 september | 16:29 |
| elopio | lool: we are now building with snapcraft, it worked last time I tried. | 16:29 |
| elopio | I'm playing with cleanbuild now. | 16:29 |
| lool | elopio: +1-ed the pull request | 16:30 |
| jdstrand | ysionneau: can you provide the snaps you are using? | 16:30 |
| ysionneau | jdstrand: the unix listener is devmode, the one connecting is not devmode | 16:30 |
| lool | elopio: it's super sensitive to local node modules | 16:30 |
| ysionneau | jdstrand: I'll send it to you in pm, but keep it to yourself please | 16:31 |
| jdstrand | mhall119: there is a PR for that. it needs work. It has gotten deprioritized behind other requests, but we'll get there. if you need to up the priority, please escalate with your manager to talk to ratliff about getting it prioritized over other things | 16:31 |
| mhall119 | ratliff: ^^ we need this dbus interface to support gnome/elementary/kde applications | 16:36 |
| mhall119 | now that the content interface is available, it's the only other blocker that I currently know of | 16:36 |
| jdstrand | mhall119: note, ratliff knows that information. we have a card for it with that in it. the question is if it should be escalated beyond other cards. your manager should use the stakeholder process if you want it prioritized over other items | 16:38 |
| ratliff | ack, mhall119 as jdstrand said, I have that information available, jdstrand has a lot of high priority work on his plate | 16:44 |
| ratliff | if there is a business reason to reprioritize, then please let me know | 16:45 |
| mhall119 | ratliff: winning DE's over to snap is the business reason | 16:46 |
| mhall119 | I can have dpm take it though the stakeholder process | 16:46 |
| jdstrand | mhall119: please escalate with your manager | 16:46 |
| ratliff | yes, please do | 16:46 |
| jdstrand | mhall119, dpm: note that it is high prioirity already, it is just behind several others things. I added you to the card | 16:47 |
| mhall119 | thanks jdstrand | 16:48 |
| bulldog | snapcraft said you missing a file , so i added it now . when i run snapcraft it still cant find file | 16:50 |
| bulldog | how to deal with this | 16:50 |
| bulldog | without cleaning everything , | 16:50 |
| zyga | mhall119: correct, | 16:52 |
| zyga | mhall119: confinement is process-based | 16:53 |
| mhall119 | bulldog: what is the actual error message? | 16:53 |
| bulldog | mhall119, i forgot to copy a file which i mentioned in wrapper script , and ran snapcraft , , i added file now , but snapcraft is not aware | 16:54 |
| bulldog | it is showing same error [Errno 2] No such file or directory | 16:55 |
| ogra | you need to clean | 16:56 |
| mhall119 | bulldog: was the missing file in one of your source parts? | 16:57 |
| bulldog | mhall119, no not in source . it is in the same directory where yaml file is | 16:57 |
| ogra | (either stage or prime if you dont want ti to download everything again) | 16:58 |
| ogra | *it | 16:58 |
| bulldog | ogra, i dont wana download 58 mb again my neetwork is not so fast its 300kbp:( | 16:58 |
| bulldog | okay | 16:58 |
| bulldog | :D | 16:58 |
| ogra | thats why i said that | 16:58 |
| bulldog | i was lil late to get that \ | 16:58 |
| mhall119 | bulldog: snapcraft clean -s stage | 16:59 |
| mhall119 | then snapcraft snap again | 16:59 |
| ogra | it is the same thing as the other few times today or the few times over the weekend ... use clean with the right stage | 16:59 |
| bulldog | mhall119, i will try | 16:59 |
| mhall119 | -s is your friend :) | 17:00 |
| elopio | lool: https://github.com/snapcore/snapweb/pull/51 | 17:00 |
| mup | PR snapweb#51: Add missing dependencies to snapcraft. Build the snap in travis <Created by elopio> <https://github.com/snapcore/snapweb/pull/51> | 17:00 |
| elopio | the grunt thing seems to happen only here. But let's land this first so we notice early if the build is broken. | 17:01 |
| bulldog | :) | 17:01 |
| bulldog | ogra, i wont repeat that :D | 17:01 |
| * ogra will quote you on that :) | 17:01 | |
| bulldog | ogra, mhall119 i cleaned both prime and stage still it says file not in - /home/bull/snap/uweather/parts/glue/build/Trolltech.conf' | 17:04 |
| bulldog | glue is name of part , | 17:04 |
| bulldog | i already cleaned build step too | 17:04 |
| mhall119 | bulldog: Trolltech.conf was the missing file? | 17:04 |
| bulldog | yeah , am having this in my wrapper script | 17:05 |
| mup | PR snapd#1717 opened: daemon,overlord: add subcommand handling to snapctl <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1717> | 17:05 |
| mhall119 | hold up, is it failing to build the "glue" part because it's missing the Trolltech.conf? | 17:05 |
| bulldog | yeah | 17:05 |
| mhall119 | then you need to clean that part | 17:05 |
| mhall119 | to at least the build stage | 17:06 |
| bulldog | snapcraft clean glue ?? | 17:06 |
| mhall119 | yeah | 17:06 |
| bulldog | it iwill delete downloaded stuffs :D | 17:06 |
| ogra | no, thats "pull" | 17:06 |
| ogra | build comes after pull | 17:06 |
| bulldog | i cleaned build already\ | 17:06 |
| ogra | "snapcraft --help" has a very nice description | 17:07 |
| bulldog | i cleaned all three build , stage and prime | 17:07 |
| mhall119 | bulldog: is the file in parts/glue/src/? | 17:07 |
| bulldog | mhall119, wait let me put it on github | 17:07 |
| mhall119 | yes please | 17:07 |
| bulldog | https://github.com/keshavbhatt/uweather-snap | 17:09 |
| bulldog | mhall119, https://github.com/keshavbhatt/uweather-snap | 17:09 |
| bulldog | mhall119, i know this will build in your case , but what am facing is a condition other users can face ! | 17:10 |
| bulldog | if you want emulate the condition , remove trolltech.conf from base dir , then run snapcraft | 17:11 |
| mhall119 | bulldog: in this case you have to clean all the way down to "pull | 17:11 |
| mhall119 | " | 17:11 |
| bulldog | it will end with no such file directory error , then copy trolltech.conf to the place back | 17:12 |
| mhall119 | because Trolltech.conf is in your "glue" part's source, it won't find it until you re-pull that part | 17:12 |
| bulldog | then run snapcraft again | 17:12 |
| === chihchun_afk is now known as chihchun | ||
| bulldog | mhall119, i pulled it with snapcraft pull glue | 17:12 |
| === chihchun is now known as chihchun_afk | ||
| bulldog | but it again do same | 17:12 |
| mhall119 | you need to clean the pull stage before it will re-run it | 17:13 |
| mhall119 | otherwise it sees that it's already been pulled, and won't pull again | 17:13 |
| bulldog | so thats a confirm bug i faced it so many times before thats why ogra noticed me asking same again aand agian | 17:13 |
| mhall119 | bulldog: snapcraft clean -s pull glue | 17:13 |
| mhall119 | then snapcraft snap | 17:13 |
| bulldog | :D | 17:13 |
| mhall119 | but that will, unfortunately, re-pull all of your stage-packages as well | 17:13 |
| bulldog | it will delete downloded stuffs | 17:14 |
| mhall119 | yup | 17:14 |
| bulldog | haha | 17:14 |
| bulldog | daem | 17:14 |
| mhall119 | but you probably don't need all of them, the desktop-qt5 part should pull them into your snap | 17:14 |
| ogra | and thats by design ... not a bug | 17:14 |
| bulldog | so its not logical to add a single file or single change , we need download stuffs which we deleted :D | 17:15 |
| mhall119 | bulldog: only if you are doing both from the same part | 17:15 |
| bulldog | what if our dependencies are sized 1gb ?? | 17:16 |
| bulldog | :D | 17:16 |
| mhall119 | put them in a separate part | 17:16 |
| bulldog | and let we learning snapcraft :D | 17:16 |
| bulldog | mhall119, okay i will try | 17:17 |
| mhall119 | I believe your dependencies are mostly all in desktop/qt5 already, so having them in your "glue" part is redundant | 17:17 |
| ogra | yeah, would just download them twice | 17:17 |
| bulldog | haha , am stupid :D | 17:17 |
| bulldog | i thought you added only some paths in that qt5 launcher | 17:18 |
| bulldog | so dependencies are in there too :D , it was downloading stuffs but i was gone for dineer | 17:18 |
| bulldog | mhall119, i have these dependencies , http://paste.ubuntu.com/23079032/ | 17:20 |
| bulldog | qt5-launcher comes with whole qt dependencies ?? | 17:21 |
| mhall119 | desktop-launch is what you want to use | 17:24 |
| mhall119 | bulldog: look at https://github.com/ubuntu/snappy-playpen/tree/master/qcomicbook for an example | 17:25 |
| bulldog | okay ty | 17:26 |
| bulldog | i cleaned glue :D | 17:26 |
| bulldog | i have not been able to snap anything yet :D , but snappy will be simple one day, and i will be able to make snaps for my applications :D | 17:28 |
| mup | PR snapd#1717 closed: daemon,overlord: add subcommand handling to snapctl <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapd/pull/1717> | 17:30 |
| bulldog | mhall119, i removed dependencies in yaml file , and ran snapcraft clean glue , and then snapcraft - bu it still downloading dependencies wth is this | 17:30 |
| bulldog | downloaded 57mb again :( | 17:31 |
| bulldog | and still the same message | 17:31 |
| bulldog | i should clean it all :3 | 17:31 |
| bulldog | modifications in snapcraft.yaml atleast should be recognosed by snapcraft. | 17:32 |
| ogra | what would "snapcraft clean glue" be or do ? | 17:32 |
| bulldog | i dont understand what is the holy reason behind making this so much complex damn | 17:33 |
| ogra | (i guess since snapcraft doesnt know what you mean it simply ignores the "glue" ) | 17:33 |
| bulldog | ogra, it cleaned it and downloaded , staged and primed glue again | 17:34 |
| ogra | khow would it do that | 17:34 |
| ogra | it doesnt know what glue means ... thats neither a command nor an option | 17:34 |
| bulldog | as i can see it didnt said (skip already done) | 17:34 |
| ogra | (again ... see snapcraft --help) | 17:34 |
| bulldog | glue is part | 17:34 |
| ogra | yes | 17:34 |
| bulldog | so why it downloaded stuffs again if it was useless command and was not recognized | 17:35 |
| bulldog | by snapcraft | 17:36 |
| mhall119 | bulldog: what does your snapcraft.yaml look like now | 17:36 |
| ogra | because you tiold it "after: [desktop/qt5] | 17:36 |
| mhall119 | ah, yes, desktop/qt5 is the part that will download the dependencies now | 17:36 |
| ogra | that cleans desktop/qt5 along i think | 17:36 |
| bulldog | it is getting more then rocket science now :D | 17:36 |
| bulldog | will a normal user able to use snapcraft ?? | 17:37 |
| bulldog | haha :P | 17:37 |
| ali1234 | "snapcraft clean" really doesn't make any sense at all | 17:37 |
| ali1234 | pretty much the only way to use it is to clean everything every time | 17:37 |
| mhall119 | bulldog: a normal user wouldn't have gotten into the situation you're in now, they would start with having desktop/qt5 from the beginning and not have to worry about backtracking | 17:38 |
| bulldog | mhall119, wait | 17:38 |
| mhall119 | ali1234: you can clean by part, by step, or both | 17:38 |
| ali1234 | which makes no sense | 17:39 |
| mhall119 | ali1234: what would you assume it does? | 17:39 |
| bulldog | mhall119, plz plz fix my yaml file - this is old one https://github.com/keshavbhatt/uweather-snap | 17:39 |
| ali1234 | i would assume it cleans by step only | 17:39 |
| ogra | ali1234, i never clean everything | 17:39 |
| bulldog | it clean all i think | 17:40 |
| ogra | (well, i sometimes do, but thats really really rare) | 17:40 |
| bulldog | all steps of all parts | 17:40 |
| ogra | ali1234, "snapcraft clean -s stage" is what i use most | 17:40 |
| ali1234 | how do you clean the built files? | 17:40 |
| ogra | well, then i use -s build ... | 17:41 |
| ali1234 | how do you force to redownload a part? | 17:41 |
| ogra | the majority of my snaps doesnt build anything from source | 17:41 |
| mhall119 | bulldog: where is your new snapcraft? | 17:41 |
| bulldog | okay if am not a normal users then can you make a snap of my qt5 app - https://github.com/keshavbhatt/deskie | 17:41 |
| ogra | ali1234, snapcraft clean <partname> -s pull | 17:42 |
| bulldog | mhall119, http://paste.ubuntu.com/23079116/ | 17:42 |
| mhall119 | ali1234: snapcraft clean -s pull ${part}, then snapcraft pull ${part}, will re-download everything for it | 17:42 |
| * ogra wonders if anyone ever reads "snapcraft --help" ... thi sis all in there | 17:42 | |
| ali1234 | yeah that syntax is terrible | 17:42 |
| mhall119 | bulldog: and that one doesn't work? | 17:42 |
| ali1234 | it should be snapcraft clean pull -p <partname> | 17:42 |
| bulldog | ogra, i been reading that from two or three days :D | 17:42 |
| ogra | ali1234, file a bug and convince sergiusens that this is better ;) | 17:43 |
| ali1234 | 99% of snaps only have one part | 17:43 |
| ogra | but after all it is still logical | 17:43 |
| bulldog | ogra, help is really cool but does not do what a user will except | 17:43 |
| mhall119 | ali1234: -p to specify a partname? that's already assumed | 17:43 |
| ogra | it surely does what i expect | 17:43 |
| bulldog | haha | 17:43 |
| mhall119 | I'd recommend -f to mean "force", or -c to mean "clean first" | 17:43 |
| ali1234 | mhall119: "snapcraft clean foo" "foo" should be assmed as a step, not a part | 17:44 |
| ogra | and it isnt like i had any of my fingers in snapcraft development, i'm just a user like anyone else | 17:44 |
| sergiusens | bulldog that's an interesting contradiction, the help cannot be really good and at the same time not do what you expect | 17:44 |
| ogra | just working my way along based on what snapcraft --help tells me | 17:44 |
| ogra | sergiusens, i have that if i switch my terminal to a chinese locale though | 17:44 |
| bulldog | sergiusens, it looks like other help manuals but , when i use those steps it create situations like i mentioned above | 17:45 |
| mhall119 | sergiusens: would you consider a -c/--clean flag on step commands, that would perform a call to clean on that step (and for a part if specified) before running the step? | 17:45 |
| sergiusens | mhall119 that would break expectations, we cannot do that until snapcraft 3.0 comes along | 17:46 |
| mhall119 | who's expectations? | 17:46 |
| bulldog | sergiusens, i can emulate the conditions which will make that help manual do what you don't expect | 17:46 |
| bulldog | seriously :D | 17:47 |
| ali1234 | ogra: snapcraft --help doesn't tell you anything useful about clean subcommand | 17:47 |
| ogra | ali1234, huh ? | 17:47 |
| ogra | snapcraft [options] clean [<part> ...] [--step <step>] | 17:47 |
| ogra | ... | 17:47 |
| ogra | Options specific to cleaning: | 17:47 |
| ogra | -s <step>, --step <step> only clean the specified step and those | 17:47 |
| ogra | that depend upon it. <step> can be one | 17:47 |
| ogra | of: pull, build, stage or prime. | 17:47 |
| bulldog | ogra, yeah that part is cool | 17:47 |
| ogra | ... | 17:47 |
| ogra | The available lifecycle commands are: | 17:48 |
| ogra | ... | 17:48 |
| ogra | pull Download or retrieve artifacts defined for a part. | 17:48 |
| ogra | build Build artifacts defined for a part. Build systems capable of | 17:48 |
| ogra | running parallel build jobs will do so unless | 17:48 |
| ogra | "--no-parallel-build" is specified. | 17:48 |
| ogra | stage Stage the part's built artifacts into the common staging area. | 17:48 |
| ogra | prime Final copy and preparation for the snap. | 17:48 |
| ogra | snap Create a snap. | 17:48 |
| bulldog | we having a copy haha | 17:48 |
| ogra | thats not clear ? | 17:48 |
| ali1234 | no | 17:48 |
| bulldog | haha | 17:48 |
| ali1234 | wtf is a "lifecycle command"? | 17:48 |
| ali1234 | or an "ecosystem command" for that matter? | 17:48 |
| bulldog | yeah :D | 17:48 |
| ali1234 | these are just nonsense words | 17:49 |
| bulldog | snapcraft lifecycle command | 17:49 |
| ogra | obviously a lifecycle command is one of the steps in the lifecycle towards getting a snap out of a source tree | 17:49 |
| ali1234 | obviously | 17:49 |
| ogra | i'm not natively english speaking, perhaps thats why i understaood it with the first reading, not sure | 17:49 |
| ali1234 | it's written in engineer speak | 17:50 |
| ogra | indeed | 17:50 |
| nacc | ali1234: no, it's written in snap knowledge speak, i would argue | 17:50 |
| ogra | because it is for engineers | 17:50 |
| nacc | ali1234: it assumes (for better or worse) that you know about snaps ahead of time, somewhat | 17:50 |
| ogra | i wouldnt expect non engineers to use snapcraft | 17:50 |
| bulldog | thats why i planned to make a gui and add my own sense to make normal users feel like home, but am kinda not able to snap anything yet | 17:50 |
| nacc | once you do, the 'lifecycle' terminology makes a lot more sense | 17:51 |
| bulldog | ogra, am 19 , and a biology student | 17:51 |
| ogra | beyond perhaps being told by an enginneer to pull that source tree and call "snapcraft" inside | 17:51 |
| ali1234 | here is an example of how the help isn't very helpful. suppose i have a snap that points to a git repository and i push a commit to the repository | 17:51 |
| ali1234 | now i need to somehow make snapcraft download my new commit | 17:51 |
| ogra | then ou hopefully have an LP autobuuild set up :) | 17:51 |
| ali1234 | it isn't clear how i should do this | 17:51 |
| nacc | ali1234: the snap doesn't really point at the git repository in my mind, the yaml does | 17:51 |
| ali1234 | should i snapcraft pull? | 17:51 |
| nacc | ali1234: in which case, just build it again | 17:52 |
| ali1234 | or maybe i should snapcraft clean -p pull? | 17:52 |
| ogra | (which magically will just build your snap if your branch changes) | 17:52 |
| ali1234 | nacc: no, that specifically does not work | 17:52 |
| nacc | ali1234: or set up the autobuild as ogra says | 17:52 |
| ogra | (and even auto-upload it for you) | 17:52 |
| ali1234 | snapcraft says "oh, already pulled that, let's not pull it again" | 17:52 |
| ogra | so let the buildds do it for you | 17:52 |
| ogra | and stop caring ;) | 17:52 |
| nacc | ali1234: or use 'cleanbuild' or a fresh env or whatever | 17:53 |
| ogra | yeah | 17:53 |
| nacc | i've yet to actually run `snapcraft build` on my host system, as it seems ... less than ideal :) | 17:53 |
| ali1234 | nacc: so yeah we are back to "vlean the whole thing every time you make a change" | 17:53 |
| ali1234 | how do you write snapcraft.yaml then? | 17:53 |
| bulldog | ogra, plz do an experiment with my app deskie , its a qt5 app and i was able to pack it and run it on 14.04 to 16.04 of ubuntu https://github.com/keshavbhatt/deskie | 17:53 |
| mup | PR snapd#1718 opened: daemon,overlord: add subcommand handling to snapctl <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1718> | 17:53 |
| ogra | ali1234, because on a bildd that costs you nothing | 17:53 |
| ali1234 | do you just bang it out and then upload it to loaunchpad and see if it works? | 17:53 |
| bulldog | ogra, snap it plz | 17:53 |
| ogra | bulldog, well, you explain my team why i dont work on images then :P | 17:54 |
| nacc | ali1234: well i mean i don't want to pollute my host system with random build deps for things anyways | 17:54 |
| nacc | ali1234: so i always use cleanbuild locally | 17:54 |
| nacc | ali1234: or the lp builders | 17:54 |
| ali1234 | nacc: so you never use clean | 17:54 |
| ogra | ali1234, bzr push ... or git push ... the rest is magic | 17:54 |
| ali1234 | bzr push what? | 17:54 |
| nacc | ali1234: no, not had to at all, as i dont' have anything to clean locally | 17:55 |
| ogra | your tree that you have set up an autobuild for on lp | 17:55 |
| nacc | ogra: is there a wiki page or blog post on setting up the autobuild, by any chance? might be a good reference | 17:55 |
| bulldog | ogra, i like new things comin , snapcraft is one of them but its really pain in @ , i got unexpected error and messages which i never seen in my life after making sanp for https://github.com/keshavbhatt/deskie | 17:55 |
| ali1234 | btw cleanbuild doesn't work for me | 17:56 |
| bulldog | ali1234, bzr push your local bzr repo | 17:56 |
| ogra | nacc, not sure ... i guess i should blog about that ... once i find some time :) | 17:56 |
| bulldog | ogra, after snapping deskie , and running it - it says svg errors lol qml qrc errors i mean what the hack is going on , do qt need to change its coding style if a developer wana pack a snap later for his app ?? | 17:58 |
| ogra | ali1234, so is your branch on LP in giit or bzr ? | 17:58 |
| nacc | bulldog: are you sure you have all the deps in the snap? | 17:58 |
| ali1234 | branch containing what? | 17:58 |
| nacc | ali1234: your snapcraft.yaml and all the parts it refers to (probably) | 17:58 |
| ogra | ali1234, your snapcraft.yaml | 17:58 |
| ali1234 | no | 17:58 |
| nacc | if there are any local ones | 17:58 |
| ali1234 | it's on my harddisk | 17:58 |
| bulldog | nacc , yes i was having em all , even i added qtsvg lib | 17:58 |
| bulldog | yeah its all in it | 17:59 |
| ogra | well, then you cant use LP obviously :) | 17:59 |
| ali1234 | i can push the snapcraft.yaml | 17:59 |
| nacc | ali1234: cleanbuild requires a working lxd setup fwiw (other than i have not see any issues with it) | 17:59 |
| bulldog | ogra i have lp , i know how to push branch :D | 17:59 |
| ogra | you can push it to LP ... the go to the website, click "create snap package" fill the form and have it auto-build for every commit | 17:59 |
| ali1234 | nacc: i have that, apt throws 500 server errors | 17:59 |
| nacc | bulldog: hrm, i'd help but i need to go afk for a bit -- i'll try and ping later and see if i can help out | 17:59 |
| ali1234 | ogra: so if my snapcraft.yaml hasnt changed, how do i make it rebuild? | 18:00 |
| bulldog | nacc, thanks bro :* | 18:00 |
| ali1234 | push an empty commit? | 18:00 |
| ogra | ali1234, you click the "request build" button in the UI or use launchpad-lib to trigger a manual build | 18:00 |
| bulldog | bzr will do it for you | 18:00 |
| ogra | launchpad-lib script | 18:00 |
| nacc | ogra: i think in this case, ali1234 is asking if the autobuild will autobuild rebuild if the underlying part changes? no, that wouldn't make sense, as you'd want it to be controlled by the app owner | 18:01 |
| bulldog | ogra, is very helpful in nature :) he is on all the time :* | 18:01 |
| ogra | nacc, ah, right | 18:01 |
| nacc | ali1234: so in your case, you'd push to your git tree (if you can), and have a git hook that causes a rebuild of the snap, possibly | 18:01 |
| ali1234 | i don't want it to do anything automatically | 18:01 |
| nacc | ali1234: then it's trivial to do manually :) | 18:01 |
| ali1234 | my snapcraft.yaml doesn't even work yet | 18:01 |
| nacc | ok, afk for real now :/ | 18:01 |
| bulldog | bye nacc | 18:02 |
| ali1234 | anyway, i don't think any of this excuses the poor documentation of clean | 18:02 |
| bulldog | nacc, wait , you can find Mut module for deskie in other branch named snap_package_recipe | 18:03 |
| bulldog | clean is really confusing from day one :D | 18:03 |
| bulldog | for a normal user :P | 18:04 |
| bulldog | it would be better if debian team figured out these security , isolating user data , interfaces, and other goals of snap :D in their .deb packaging format | 18:06 |
| ali1234 | oh no please | 18:06 |
| ali1234 | deb packaging is terrible | 18:06 |
| bulldog | haha | 18:06 |
| bulldog | why ?? | 18:06 |
| bulldog | whats wrong there ? | 18:07 |
| ali1234 | because there is literally no correct way to do it | 18:07 |
| bulldog | what do you mean - no correct way to do it | 18:07 |
| bulldog | i simply do dpkg-buildpackage -uc -us | 18:07 |
| ali1234 | i mean that, given any piece of software you can imagine, there is no way to package it in a deb file that matches any of the documentation about how to create a deb file | 18:08 |
| ali1234 | literally everything is a corner case | 18:08 |
| bulldog | hmmm thats true and this seems to happening with snapcraft too | 18:08 |
| ali1234 | at least snapcraft has a clean command | 18:08 |
| bulldog | haha | 18:08 |
| ali1234 | dpkg has a clean command, but it is totally reliant on the packager writing a clean rule that works | 18:09 |
| bulldog | smapcraft is awesome , but what if both powers into one | 18:09 |
| ali1234 | and 99.9% of packagers don't bother | 18:09 |
| bulldog | am fine with debian packaging if you ever need help call me , keshavnrj@gmail.com | 18:09 |
| ali1234 | please fix the Qt package to make dpkg-buildpackage work if you run it twice in the same unpacked source | 18:10 |
| bulldog | debian packaging backed with lp is super cool , just keep the branch updated and it will make sure everything will work | 18:10 |
| bulldog | i dont build from source with dpkg :D | 18:11 |
| bulldog | my way of doing is different | 18:11 |
| bulldog | i have lots of apps in software center , and am not wrong with my style of packaging with dpkg-buildpackage | 18:12 |
| ali1234 | my experience of debian packaging is as follows: apt-get source <package>, enter the directory, make changes, dpkg-commit them, write changelog entry, attempt to build package, doesn't work, delete the source dir and start over | 18:13 |
| bulldog | i mean i dont left out any dependency so my apps works well on 12.04 to 16.04 | 18:13 |
| bulldog | thats official way if you packing for debian :D | 18:13 |
| ali1234 | when building on launchpad it is pretty much the same except there's a half hour upload step and a 4 hour wait for it to build | 18:14 |
| bulldog | yeah , if you want daily build then the way you explained is right | 18:14 |
| ali1234 | i dont want daily build | 18:14 |
| ali1234 | i want to test the change i made | 18:14 |
| bulldog | i mean you can do manual too | 18:14 |
| bulldog | where r u from ? | 18:15 |
| ali1234 | why does it matter? | 18:15 |
| bulldog | just asking :) | 18:16 |
| bulldog | am from India , i don't feel insecure :D revealing this truth :P | 18:18 |
| ssweeny | jdstrand, I wonder if you have some advice on how to make my udisks mounts visible outside of the snap? I talked briefly with zyga about it and he said I could create "specially designed bind mounts" to do it. I tried bind-mounting /run/media/ onto itself and making that shared from a wrapper script in the snap but that doesn't seem to work, and when I try to add the bind-mount in the interface (interfaces.SecurityMount) I get denials for snap-con | 18:18 |
| ssweeny | fine trying to make the mount | 18:18 |
| jdstrand | ssweeny: I'm not sure. udisks2 is running in its own private mount namespace. I think the intent of the udisks2 interface would be to make those mounts in the global mount namespace | 18:24 |
| ssweeny | jdstrand, I agree, but I'm not sure how to go about that | 18:24 |
| jdstrand | you can't at the moment cause once your in the namespace you can't get out | 18:24 |
| jdstrand | otoh the only way I could see doing that is somehow having snap-confine not do a private mount | 18:25 |
| jdstrand | for that interface | 18:25 |
| ogra | hotel california namespace ? | 18:26 |
| ssweeny | you can check out any time you like, but you can never leave :) | 18:27 |
| ogra | ;) | 18:28 |
| ssweeny | jdstrand, would that be a quirk to add to s-c? | 18:28 |
| ssweeny | looks like there's already some custom stuff for lxc in the quirks source file | 18:28 |
| ssweeny | jdstrand, alternatively this could be an argument for udisks being part of the core snap :) | 18:29 |
| jdstrand | heh, yeah | 18:29 |
| jdstrand | hmm | 18:31 |
| jdstrand | this darn mount namespace | 18:31 |
| jdstrand | its causing several problems | 18:31 |
| ali1234 | ogra: so it turns out you can do export http_proxy=http://localhost:9999/" and now packageproxy will cache any repo that you fetch with apt | 18:33 |
| ali1234 | with no config changes | 18:34 |
| bulldog | ogra, i missed something in snapcraft file i added it now what should i do now to make snap out with the new changes | 18:34 |
| jdstrand | ssweeny: I can't really think of anything that would work beyond telling snap-confine to not do it or add an out of process helper for udisks to request it do the mounts on its behalf | 18:36 |
| ssweeny | jdstrand, OK I'll look at quirking snap-confine then. If we're adding a mount helper to core then I'd rather just propose udisks itself go in | 18:36 |
| jdstrand | tyhicks: hey, sorry to interrupt you. so, the udisks2 PR has a problem. basically, it runs as a snap, it mounts things, but those mounts are in its private mount namespace but they should be made in the glabl namespace | 18:37 |
| tyhicks | hey | 18:37 |
| jdstrand | tyhicks: so that something using the pluggable-storage interface has access to the mounts (eg, in /media) | 18:37 |
| jdstrand | tyhicks: I can only think of two ways to deal with this-- snap-confine doesn't do the private mount namespace or an out of process helper that udisks could ask to do the mounts | 18:38 |
| jdstrand | tyhicks: can you think of another option? | 18:40 |
| tyhicks | jdstrand: by "snap-confine doesn't do the private mount namespace" do you mean that it wouldn't set up the private mount namespace for the udisks2 snap but would continue to do so for all the others? | 18:40 |
| jdstrand | tyhicks: that is what I meant | 18:40 |
| tyhicks | ok | 18:40 |
| * tyhicks thinks | 18:40 | |
| jdstrand | somehow, if you say you 'slots: [ udisks2 ]', then you don't get a private mount namespace | 18:40 |
| kyrofa | elopio, any chance you're still setup to test nextcloud? | 18:40 |
| jdstrand | otherwise, you continue to do so | 18:40 |
| kyrofa | elopio, I pushed an update to --beta that changes the HTTPS stuff (more info in the PR description here: https://github.com/nextcloud/nextcloud-snap/pull/23) | 18:41 |
| mup | PR nextcloud/nextcloud-snap#23: Add support for HTTPS <Created by kyrofa> <https://github.com/nextcloud/nextcloud-snap/pull/23> | 18:41 |
| ssweeny | jdstrand, tyhicks, even if I could get ONE shared mount point that would help since mounts under that could also be shared | 18:42 |
| mup | Bug #1615773 opened: Allow for seccomp blacklist rather than whitelisting <lxd> <Snappy:New> <https://launchpad.net/bugs/1615773> | 18:42 |
| tyhicks | jdstrand: in theory, I guess another option would be for udisks2 to use setns() to rejoin the global mount namespace before peforming a mount but that doesn't seem to be an improvement over the other options | 18:43 |
| === tsimonq2alt is now known as tsimonq2 | ||
| tyhicks | (there's also the problem of getting the global mount namespace fd to udisks2) | 18:44 |
| jdstrand | tyhicks: that doesn't seem possible. you get EPERM | 18:46 |
| jdstrand | tyhicks: once you ushare you don't seem to be able to go back | 18:46 |
| tyhicks | "Changing the mount namespace requires that the caller possess both CAP_SYS_CHROOT and CAP_SYS_ADMIN capabilities in its own user namespace and CAP_SYS_ADMIN in the target mount namespace." | 18:47 |
| ogra | ali1234, just dont build go projects ;) | 18:47 |
| tyhicks | jdstrand: ^ (from the setns man page) | 18:47 |
| ali1234 | ogra: why? it passes through requests it doesn't understand | 18:48 |
| ali1234 | turns out it only caches repos that you defined in the config | 18:48 |
| ogra | go builds fall over when proxies are involved afaik | 18:48 |
| ogra | (if you export, that will apply to everything in that shell) | 18:49 |
| jdstrand | tyhicks: I tried doing nsenter on pid 1 with those capabilities and it didn't work | 18:49 |
| jdstrand | tyhicks: I had the same thought over the weekend for the 'ip netns exec' issue | 18:49 |
| ali1234 | so in my shellscript i should do "env http_proxy=... multistrap" ? | 18:50 |
| jdstrand | tyhicks: granted, I wasn't able to exhaustively test it. if you'd like, I can, but I kinda thought the EPERM made sense since the point of this is that that the process is contained | 18:50 |
| tyhicks | jdstrand: EPERM does make sense but I'm confused in that the man pages suggest that it should be possible | 18:52 |
| tyhicks | jdstrand: does the setns() option make for a cleaner design? | 18:53 |
| jdstrand | I'm not sure | 18:53 |
| tyhicks | if it does, I can read through the code to figure out what is going on | 18:54 |
| jdstrand | it might be because I was using nsenter from within the mount namespace | 18:54 |
| jdstrand | and that was why I got an eperm | 18:54 |
| jdstrand | whereas if the fd was passed in, I wouldn't | 18:54 |
| tyhicks | that's possible | 18:55 |
| jdstrand | I guess snap-confine could open() /proc/self/ns/mnt and not close it, then udisks2 could setns on it? | 18:57 |
| jdstrand | tyhicks: is that what you were thinking? | 18:57 |
| ali1234 | ogra: why can't i use bulleted list in config.yaml? | 18:57 |
| tyhicks | jdstrand: that's what I think would have to happen | 18:58 |
| jdstrand | tyhicks: I'm also interested in this re 'ip netns exec' | 18:58 |
| tyhicks | jdstrand: but if snap-confine and udisks2 is going to all of that trouble, why put it into a new namespace to begin with? | 18:58 |
| jdstrand | right. udisks2 could easily deal with not having a mount namespace | 18:59 |
| jdstrand | but, we keep hitting complications with this... | 18:59 |
| tyhicks | with the mount namespace? | 19:00 |
| jdstrand | tyhicks: yes. so, all the really hard stuff about snap-confine and udisks2 is not around avoiding the private mount setup. it is about the interaction between the declared interface influencing snap-confine | 19:01 |
| jdstrand | tyhicks: (ie, whether avoid mount namespace or open(), everything else is the same) | 19:02 |
| jdstrand | meh | 19:02 |
| jdstrand | I was sorta thinking just avoid it, but now I'm thinking the setns may be viable for ip | 19:03 |
| tyhicks | couldn't snapd to tell snap-confine if it should stick the launched process into a new mount namespace or not? | 19:03 |
| tyhicks | s/snapd to tell/snapd tell/ | 19:03 |
| jdstrand | tyhicks: yeah-- that is what I'm saying is the hard part. that needs to be designed, etc. is it part of the .fstab thing that's there, is it a new backend, etc | 19:04 |
| sergiusens | elopio when you have time, can you give #740 another peek? | 19:04 |
| tyhicks | jdstrand: right | 19:05 |
| tyhicks | jdstrand: I now understand what you're saying | 19:05 |
| jdstrand | where I'm conflicted is that if we do the setns approach for ip, maybe we should for udisks2 (trying to avoid two different backends for similar problems) | 19:06 |
| bulldog | good night guys see u tomorrow | 19:06 |
| tyhicks | jdstrand: it seems kludgy to me to stick udisks2 into a new mount namespace, pass it the fd for the global mount namespace, and then expect it to immediately setns() to the global mount namespace | 19:07 |
| jdstrand | tyhicks: that's a fair point | 19:08 |
| tyhicks | jdstrand: also, have you verified if a mount in the global mount namespace is automatically propagated to all the per-command mount namespaces? | 19:09 |
| jdstrand | tyhicks: /media is one of the directories that snap-confine bind mounts | 19:10 |
| tyhicks | oh | 19:10 |
| tyhicks | hmm | 19:10 |
| ssweeny | jdstrand, tyhicks this is more likely to apply to /run/media and all-snaps systems, since a classic system would likely already have udisks, right? | 19:11 |
| jdstrand | tyhicks: it's in setup_snappy_os_mounts() | 19:11 |
| jdstrand | ssweeny: it would | 19:11 |
| mup | PR snapcraft#749 opened: Allow registering private packages <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/749> | 19:11 |
| tyhicks | jdstrand: so that means there's another option... | 19:12 |
| tyhicks | just a sec | 19:12 |
| jdstrand | tyhicks: you thinking about some (r)slave option? | 19:13 |
| tyhicks | jdstrand: well, all snaps get the rslave bind mount of /media today | 19:14 |
| jdstrand | right | 19:14 |
| jdstrand | actually, I can test now | 19:14 |
| tyhicks | jdstrand: I think that if udisks2 received an rshared bind mount of /media, it's mounting activity would be propagated to all the rslave bind mounts | 19:14 |
| jdstrand | all I need to do is see if I can see the mounts in /media if I plug in a usb key from within the snap | 19:15 |
| jdstrand | so the quirk is rshared | 19:15 |
| jdstrand | interesting | 19:15 |
| tyhicks | yes | 19:15 |
| tyhicks | by default, the mount syscall for snaps would be: mount(src, dst, NULL, MS_BIND | MS_REC | MS_SLAVE, NULL) | 19:16 |
| ssweeny | tyhicks, I'm not sure that's true for all-snaps. on my rpi2 /media is read-only | 19:16 |
| tyhicks | udisks2 would get: mount(src, dst, NULL, MS_BIND | MS_REC | MS_SHARED, NULL) | 19:16 |
| ssweeny | zyga told me that was just for snaps-on-classic | 19:16 |
| tyhicks | ssweeny: oh, you're correct | 19:16 |
| tyhicks | jdstrand: ^ | 19:16 |
| tyhicks | if (is_running_on_classic_distribution()) { | 19:17 |
| tyhicks | setup_snappy_os_mounts(); | 19:17 |
| tyhicks | } | 19:17 |
| jdstrand | it would be MS_SHARED for /run then otherwise (/run/media) | 19:17 |
| jdstrand | man, soo many mounts | 19:18 |
| tyhicks | yes, it makes for a lot of confusion | 19:18 |
| jdstrand | fyi, on classic, the private mount doesn't get in the way of /media | 19:20 |
| jdstrand | ssweeny: I like tyhicks idea of using MS_SHARED | 19:21 |
| ssweeny | jdstrand, ok, what do I need to do? | 19:21 |
| tyhicks | jdstrand: what about ssweeny's point that using MS_SHARED would only work on classic? | 19:21 |
| jdstrand | tyhicks: I thought you agreed with my point on /run | 19:22 |
| jdstrand | tyhicks: on all snaps, it is in /run/media. /run is also one of these | 19:22 |
| jdstrand | tyhicks: so with udisks2 on all snaps, mount /run with MS_SHARED, no? | 19:23 |
| tyhicks | jdstrand: where in the snap-confine code is /run getting mounted on non-classic systems? | 19:24 |
| tyhicks | I couldn't see it | 19:24 |
| jdstrand | tyhicks: I'm not being clear. on all-snaps, for udisks, mount /run with MS_SHARED on /run | 19:26 |
| tyhicks | jdstrand: ah, so this would be an entirely new mount that we'd need to set up on all-snaps | 19:26 |
| tyhicks | jdstrand: thanks for clarifying | 19:27 |
| jdstrand | I guess we're back to it is just as easy to skip setup_private_mount() | 19:27 |
| tyhicks | pretty much | 19:27 |
| jdstrand | well | 19:27 |
| tyhicks | snapd needs to let snap-confine know to do something special for this one snap | 19:27 |
| jdstrand | we can't really do that though | 19:27 |
| jdstrand | not your last comment | 19:28 |
| tyhicks | why not? | 19:28 |
| jdstrand | we can't really skip setup_private_mount unless we give up on content sharing | 19:28 |
| jdstrand | for that interface | 19:28 |
| jdstrand | tyhicks: absolutely snapd must do something special for slot implementations of the udisks2 interface | 19:29 |
| jdstrand | ok | 19:29 |
| tyhicks | no matter what, snapd is going to have to do something special | 19:29 |
| jdstrand | yes | 19:29 |
| jdstrand | we were typing at the same time | 19:29 |
| tyhicks | ok | 19:29 |
| tyhicks | MS_SHARED is probably the best implementation when snapd does that special thing :) | 19:30 |
| jdstrand | my comment was supposed to be: | 19:30 |
| jdstrand | "I guess we're back to it is just as easy to skip setup_private_mount() | 19:30 |
| jdstrand | well | 19:30 |
| jdstrand | we can't really do that though" | 19:30 |
| jdstrand | maybe | 19:30 |
| jdstrand | ok | 19:30 |
| tyhicks | MS_SHARED definitely fits well into the fstab backend | 19:31 |
| jdstrand | ssweeny: let's try this: in sc_setup_mount_profiles() parse the .fstab file for shared and mount those with MS_SHARED. then the udisks2 interface uses the SecurityMount backend to mount /run with shared | 19:33 |
| jdstrand | ssweeny: you should bounce that off zyga | 19:33 |
| jdstrand | ssweeny: because today the SecurityMount backend only mounts exports from snaps, not the OS | 19:34 |
| ssweeny | jdstrand, aha, ok | 19:34 |
| jdstrand | let me rephrase for clarity: then the udisks2 interface uses the SecurityMount backend to specify mounting /run with shared | 19:35 |
| jdstrand | or even /run/media | 19:35 |
| ssweeny | ok that makes sense | 19:36 |
| jdstrand | (snapd is obviously not doing the mounting) | 19:36 |
| jdstrand | cool. sorry it took so long. tyhicks, thank you for the MS_SHARED option | 19:36 |
| ssweeny | ok, 1) add SecurityMount entry with shared to udisks interface and 2) patch snap-confine to process that and mount appropriately | 19:37 |
| ssweeny | jdstrand, is there a good way to test my snap-confine patch on an all-snaps system? I don't imagine I can replace the existing binary | 19:37 |
| ssweeny | testing udisks on a classic system seens like asking for pain | 19:38 |
| jdstrand | ssweeny: spread tests allow you to do crazy stuff and I highly advise using those when you are getting close to PR. before that point, you can either generate your own core snap (sudo unsquashfs ./snap ; modify ; snapcraft snap ./squashfs-root) or use overlayfs | 19:40 |
| ssweeny | jdstrand, awesome, thanks! | 19:41 |
| tyhicks | I've got one other way that I test snap-confine changes | 19:41 |
| tyhicks | what I've been doing for testing snap-confine changes on an all-snaps system is building snap-confine, then copying it to the home directory of my all snaps system (you'll need to make root the owner and set the setuid bit), then make a copy of the wrapper script in my home directory, and then modify the copied wrapper script to launch the snap-confine in my home directory | 19:42 |
| tyhicks | kinda kludgy but it allows for pretty quick manual testing | 19:42 |
| jdstrand | that would work, but soon it won't once snap-run is around | 19:42 |
| ssweeny | also awesome, tyhicks! thanks! | 19:42 |
| ssweeny | jdstrand, how long do I have? :) | 19:43 |
| ssweeny | (before that won't work I mean) | 19:43 |
| ssweeny | I'm hoping to get this all wrapped up this week | 19:43 |
| tyhicks | I think you'll be fine this week | 19:43 |
| jdstrand | ssweeny: something along these lines: http://paste.ubuntu.com/23079343/ | 19:44 |
| jdstrand | that is for overlay | 19:44 |
| jdstrand | it is not bad to setup either | 19:44 |
| ssweeny | yeah seems pretty straightforward | 19:44 |
| ssweeny | jdstrand, tyhicks, I need to run out for a bit. thanks so much for the help! | 19:47 |
| jdstrand | yw | 19:47 |
| tyhicks | np | 19:48 |
| ali1234 | ogra: okay approx is actually broken... doesn't do what it claims | 19:49 |
| sergiusens | elopio https://github.com/snapcore/snapcraft/pull/749 | 19:53 |
| mup | PR snapcraft#749: Allow registering private packages <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/749> | 19:53 |
| lool | elopio: looked good, +1 for me | 19:59 |
| ali1234 | ogra: http://paste.ubuntu.com/23079392/ | 20:06 |
| ali1234 | also don't you just love debian software with no upstream, no documentation, and no maintainer? | 20:07 |
| mup | PR snapd#1719 opened: firstboot: add firstboot assertions adding <Created by mvo5> <https://github.com/snapcore/snapd/pull/1719> | 20:36 |
| mup | PR snapcraft#750 opened: storeapi: remove dependency on the 'success' attr <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/750> | 20:47 |
| mup | PR snapd#1720 opened: interfaces: add lxd-support interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1720> | 20:55 |
| jdstrand | stgraber: ^ | 21:00 |
| kyrofa | jdstrand, I've run into an interesting issue | 21:17 |
| kyrofa | jdstrand, I have a service running in-snap. Some user interaction changes the settings for it and the service needs to be restarted. The service saves in PID and includes the ability to stop the previous PID and start a new one | 21:18 |
| kyrofa | jdstrand, problem is, that seems to (logically) remove control from systemd, which means now the snap can't actually be removed because services aren't stopped | 21:18 |
| kyrofa | (the snap can't be unmounted because files are in use) | 21:19 |
| kyrofa | jdstrand, I've done it this way because I assume services can't be controlled via systemctl from within the snap | 21:19 |
| kyrofa | jdstrand, is there a better way for me to be doing that? | 21:21 |
| jdstrand | kyrofa: you're right about services not able to control themselves via systemd from within a snap | 21:23 |
| jdstrand | kyrofa: https://www.freedesktop.org/software/systemd/man/systemd.service.html has interesting things wrt to this | 21:25 |
| kyrofa | jdstrand, hmm... I could kill it and let systemd respawn it I suppose | 21:27 |
| jdstrand | kyrofa: snappy's daemon handling is rather rudimentary at the moment. You might like: restart-condition: always | 21:27 |
| kyrofa | Indeed | 21:28 |
| jdstrand | kyrofa: then you just stop and systemd starts it again | 21:28 |
| jdstrand | kyrofa: see 'Restart' in the aforementioned page | 21:28 |
| kyrofa | jdstrand, alright I'll give that a shot, thanks! | 21:28 |
| jdstrand | np | 21:28 |
| * ahoneybun tries to snap : https://github.com/jamiemcg/remarkable | 21:47 | |
| kyrofa | jdstrand, FYI, that works great | 21:57 |
| kyrofa | jdstrand, though I'm concerned about potential abuse there | 21:58 |
| jdstrand | kyrofa: glad to hear :) | 21:58 |
| jdstrand | kyrofa: what abuse? a snap keeping systemd busy? | 21:58 |
| kyrofa | jdstrand, a snap being unremovable without manual intervention | 21:59 |
| kyrofa | jdstrand, is there a way to determine all pids running within the snap? | 21:59 |
| jdstrand | yes | 22:01 |
| jdstrand | at least on systems with apparmor | 22:01 |
| jdstrand | systemd is supposed to handle that, but I see you found a case where it doesn't | 22:01 |
| jdstrand | you can check what processes are running under snap.${SNAP_NAME}.* | 22:02 |
| jdstrand | I imagine snappy remove should probably try to detect that and say "sorry, please stop all processes from this snap before removing" (obviously that isn't the actual text :) | 22:03 |
| kyrofa | jdstrand, alright, thanks :) | 22:34 |
| kyrofa | jdstrand, another question: I'm setting a PATH in snap run and noticing that it's not set in the app. Any change snap-confine is stripping that? | 22:35 |
| kyrofa | s/change/chance/ | 22:36 |
| kyrofa | jdstrand, ah, it seems so: http://pastebin.ubuntu.com/23079882/ | 22:45 |
| mhall119 | is /usr/lib/x86_64-linux-gnu/ inside a snap's runtime different from the host? | 22:53 |
| kyrofa | mhall119, it's probably the one contained within the core snap | 22:55 |
| ahoneybun | mm travis does not like me mhall119 | 23:26 |
| ahoneybun | https://github.com/ubuntu/snappy-playpen/pull/221 | 23:26 |
| mup | PR ubuntu/snappy-playpen#221: Added otter-browser <Created by ahoneybun> <https://github.com/ubuntu/snappy-playpen/pull/221> | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!