| === chihchun_afk is now known as chihchun | ||
| mwhudson | mcphail: according to the mailing list it's supposed to be $SNAP_USER_COMMON but it doesn't work right now | 01:47 |
|---|---|---|
| mwhudson | mcphail: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1611063 | 01:48 |
| mup | Bug #1611063: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1611063> | 01:48 |
| notadeveloper | is video acceleration available in snappy | 01:48 |
| mup | Bug #1624963 opened: pulseaudio interface (still) missing permissions <Snappy:New> <https://launchpad.net/bugs/1624963> | 02:06 |
| === JanC is now known as Guest19696 | ||
| === JanC_ is now known as JanC | ||
| mup | PR snapd#1939 opened: Update documentation on testing snapd <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1939> | 03:23 |
| mup | Bug #1602752 changed: Add support for timezone-read interface <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1602752> | 04:19 |
| mup | PR snapd#1939 closed: Update documentation on testing snapd <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1939> | 05:39 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#1937 closed: image: ensure local snaps are put last in seed.yaml <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1937> | 06:32 |
| mcphail | mwhudson: thanks! | 06:37 |
| dholbach | hey hey | 06:50 |
| stub | When I say 'Snap Store' in my documentation, what URL should I be linking to? | 06:58 |
| mup | PR snapd#1938 closed: asserts: check that validation assertions are signed by the publisher of the gating snap <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1938> | 07:28 |
| mup | PR snapd#1940 opened: asserts: define a bit less terse Ref.String <Created by pedronis> <https://github.com/snapcore/snapd/pull/1940> | 07:36 |
| zyga | mwhudson: hey :) | 07:48 |
| zyga | mwhudson: I'll work on release today :) happy to finally reach this point | 07:48 |
| mup | PR snapd#1932 closed: add HACKING.md and move content from README.md over <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1932> | 07:56 |
| zyga | jdstrand, tyhicks: https://github.com/snapcore/snap-confine/pull/147 | 08:17 |
| mup | PR snap-confine#147: Implement secure_getenv(3) if not provided by stdlib <Created by zyga> <https://github.com/snapcore/snap-confine/pull/147> | 08:17 |
| zyga | lool: https://github.com/snapcore/snap-confine/pull/147 | 08:19 |
| mup | PR snap-confine#147: Implement secure_getenv(3) if not provided by stdlib <Created by zyga> <https://github.com/snapcore/snap-confine/pull/147> | 08:19 |
| mwhudson | zyga: oh yeah, you'll need to find a DD to do the thing that lets you upload the package | 08:22 |
| zyga | mwhudson: I need to refresh my memory on the process | 08:23 |
| zyga | mwhudson: I'll do a sdist release without tagging as soon as 147 lands and do a round of packaging and distro testing | 08:23 |
| zyga | mwhudson: then officially tag and start pushing downstream | 08:24 |
| mwhudson | zyga: https://wiki.debian.org/DebianMaintainer#Granting_Permissions | 08:24 |
| mwhudson | zyga: sounds good | 08:24 |
| zyga | thank you! | 08:24 |
| mup | PR snapd#1920 closed: --lazy is only available with -l in trusty <Created by vosst> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1920> | 08:27 |
| mup | PR snapd#1873 closed: interfaces: disable auto-connect in libvirt interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1873> | 08:39 |
| mup | PR snapd#1940 closed: asserts: define a bit less terse Ref.String <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1940> | 08:39 |
| === seb128_ is now known as seb128 | ||
| ogra_ | cjwatson, looks like LP tries to upload the .manifest files now (thanks for publishing them !) ... i got mails from tonights auto-builds: " __all__: The upload does not appear to be a valid package." | 08:53 |
| ogra_ | mvo, could you approve https://myapps.developer.ubuntu.com/dev/click-apps/5912/rev/3/ ? and give me upload access to the beagleblack gadget (i have a working beagle image here) | 08:56 |
| mvo | ogra_: we probably need to republish the beaglblack under a different publisher, e.g. beagleblack.ogra ? or just beagle.ogra or something | 08:59 |
| ogra_ | mvo, ok, i can do that | 09:00 |
| mvo | ogra_: great, thank you | 09:00 |
| === vrruiz_ is now known as rvr | ||
| lool | zyga: thanks for adding secure_getenv; wanted to do it over the week-end but ended up debugging other things | 09:04 |
| zyga | matteo: hey | 09:13 |
| matteo | hi zyga | 09:13 |
| zyga | matteo: would you mind doing a quick test build of snap-confine from this branch https://github.com/snapcore/snap-confine/pull/147/files | 09:13 |
| mup | PR snap-confine#147: Implement secure_getenv(3) if not provided by stdlib <Created by zyga> <https://github.com/snapcore/snap-confine/pull/147> | 09:13 |
| zyga | matteo: I will do a release shortly, I just want to make sure it works outside of glibc | 09:13 |
| matteo | you mean with MUSL? | 09:14 |
| zyga | yes | 09:15 |
| matteo | I'm using glibc on OpenWrt, but I can rebuild the toolchain | 09:19 |
| zyga | matteo: hmm, I thought that openwrt used musl | 09:21 |
| zyga | lool: ^ where did you end up using musl? | 09:21 |
| matteo | sure, by default | 09:21 |
| lool | zyga: I can do a build with musl | 09:21 |
| matteo | but I switched to glibc to be sure that it works | 09:21 |
| lool | after lunch | 09:21 |
| zyga | lool: thanks | 09:22 |
| zyga | matteo: I see, thanks | 09:22 |
| zyga | matteo: I guess lool will do the check | 09:22 |
| matteo | zyga: I didn't want to add extra entropy to the system :D | 09:22 |
| zyga | hehe :) | 09:22 |
| zyga | is openwrt ususally using musl? | 09:22 |
| timothy | openwrt can also use uclibc | 09:24 |
| ogra_ | mwhudson, in bug 1624329 i dont want you to fix firstboot ... thats mvo's job i guess :) but i want the network device to work after i plugged in a cable (it doesnt, even if i cancel console-conf to have it start over from scratch) | 09:24 |
| mup | Bug #1624329: snapd firstboot setup fails constantly when rebooting before console-conf has finished <Snappy:New> <snapd (Ubuntu):New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1624329> | 09:24 |
| mwhudson | ogra_: that's super odd | 09:25 |
| mwhudson | (the device not appearing) | 09:25 |
| matteo | timothy: time ago, now it's dropped it for most architectures | 09:25 |
| timothy | you can still choose it from make menuconfig | 09:25 |
| matteo | it's the default on archs unsupported by MUSL | 09:26 |
| mwhudson | ogra_: to get the devices it just does (roughly) pyudev.Context().list_devices(subsystem='net') | 09:26 |
| ogra_ | it appears but i cant configure it | 09:26 |
| mwhudson | ogra_: there's nothing cached between invocations... | 09:26 |
| matteo | yes, you can choose it if you really like broken C libraries | 09:26 |
| ogra_ | weird | 09:26 |
| mwhudson | ogra_: i finally dug my dragonboard out today so i can experience some of your pain more faithfully tomorrow :) | 09:26 |
| ogra_ | hah, great | 09:27 |
| ogra_ | i'm just playing with a beaglebone image here ... thats even more odd | 09:27 |
| mwhudson | i have a pile of hardware that i think strictly speaking belongs to linaro | 09:27 |
| mwhudson | a panda, beagleboard xm, arndale | 09:27 |
| ogra_ | (beautiful oopses on boot and no network device at all ... ) | 09:27 |
| ogra_ | (on second boot all is fine ... but then firstboot is already in a wonky state) | 09:28 |
| mwhudson | ogra_: how do you connect to dragonboard serial? | 09:29 |
| mwhudson | i have a fdti thing but i never got it to work | 09:29 |
| ogra_ | with the mezzanine board that got shipped along :P | 09:29 |
| mwhudson | ah heh clearly i bought mine too early | 09:29 |
| ogra_ | well, the company bought mine | 09:30 |
| mwhudson | well yes, mine too | 09:30 |
| mwhudson | but it was before that sort of thing was available | 09:30 |
| mwhudson | ogra_: this one? https://www.seeedstudio.com/96Boards-UART-p-2525.html | 09:31 |
| ogra_ | yep | 09:31 |
| zyga | mwhudson: it's fiddly | 09:32 |
| zyga | mwhudson: I had mine but it's easy to make it not work | 09:32 |
| zyga | mwhudson: as a quick test, check if the daughter board works by itself | 09:32 |
| zyga | mwhudson: I also found that the board has to be aligned properly vertically, it can easily bend back and forth and this makes the connection fail | 09:33 |
| mwhudson | zyga: can't possibly be more fiddly than the http://www.digikey.co.nz/product-detail/en/ftdi-future-technology-devices-international-ltd/TTL-232RG-VIP-WE/768-1069-ND/2441358 i was trying to use before | 09:34 |
| ogra_ | mvo, http://paste.ubuntu.com/23202066/ ... could we make the firstboot service run after console-conf somehow ? | 09:34 |
| zyga | mwhudson: heh, well, you can always use those simple ftdi cables with female connectors | 09:35 |
| mwhudson | ogra_: that's netplan segfaulting? | 09:35 |
| mwhudson | zyga: ? | 09:35 |
| ogra_ | mwhudson, thats a kernel oops of the NIC ... my prob is that firstboot is from then on broken, even if i have a boot without oops | 09:38 |
| zyga | mwhudson: a usb serial from ftdi where each connector is a separate cable with female connector, just plug those over and it should work | 09:38 |
| zyga | mwhudson: (just make sure not to fry the board) | 09:38 |
| mwhudson | zyga: huh i didn't see that one when i was looking ~15 months ago | 09:38 |
| mwhudson | anyway i'll try the one i have and order a mezzanine if i can't make it work | 09:38 |
| zyga | mwhudson: http://www.aliexpress.com/store/product/USB-to-TTL-Serial-Cable-Adapter-FTDI-Chipset-PL2303HX-USB-Cable-Computer-Cable/1180713_1889042442.html | 09:38 |
| zyga | mwhudson: something like this | 09:38 |
| mvo | ogra_: hm, that would make sense, this way we have ntp hopefully | 09:38 |
| mwhudson | zyga: the dragonboards connectors are themselves female aren't they? | 09:38 |
| zyga | hmmm, are they? sorry I don't have one in front of me | 09:38 |
| zyga | (there are male variants of the thing as well) | 09:38 |
| ogra_ | mvo, well, i dont care that much about ntp ... more about having network at all | 09:38 |
| ogra_ | ppisati_, http://paste.ubuntu.com/23202086/ ... beaglebone (with linux-generic xenial) | 09:39 |
| ppisati_ | cking: ogra_ :O | 09:42 |
| ppisati_ | ops | 09:42 |
| ppisati_ | ogra_: :O | 09:42 |
| ogra_ | yeah :/ | 09:42 |
| cking | ?! | 09:42 |
| ogra_ | i blame pitti .... netplan tries to start the network :) | 09:42 |
| ppisati_ | ogra_: yeah, put the blame on pitti | 09:42 |
| ogra_ | hehe | 09:42 |
| ogra_ | let me build a public image so you can tinker with it | 09:42 |
| ppisati_ | ogra_: ta | 09:42 |
| ogra_ | (gimme 10-15min) | 09:42 |
| ppisati_ | ogra_: is that a beaglebone black? | 09:42 |
| ogra_ | yep | 09:42 |
| ppisati_ | k | 09:42 |
| ogra_ | with 4.4.0-36-generic | 09:42 |
| ogra_ | it works better on subsequent boots btw ... on first boot i always get the oops, reliably ... on subsequent ones it only happens very random | 09:43 |
| ppisati_ | weird | 09:44 |
| ogra_ | yep | 09:44 |
| ogra_ | ppisati_, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has the beagle image now | 09:56 |
| mup | PR snapd#1941 opened: interfaces/builtin: allow mmaping pulseaudio buffers <Created by zyga> <https://github.com/snapcore/snapd/pull/1941> | 09:58 |
| ppisati_ | ogra_: cool, i'll give it a spin | 10:00 |
| ogra_ | mvo, hmm, looks like it would just help if firstboot.go wouldnt create an empty state.json file when there is no network ... | 10:03 |
| ogra_ | mvo, if i do: "sudo rm /var/lib/snapd/state.json && sudo systemctl restart snapd.firstboot.service && sudo reboot" it works fine | 10:04 |
| cjwatson | ogra_: Hm, that exact message doesn't appear in the LP source tree. URL to the failing build? | 10:04 |
| ogra_ | i have four of them ... one sec ... | 10:05 |
| ogra_ | https://launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/5109 | 10:05 |
| mvo | ogra_: yeah, three are some easy wins here | 10:05 |
| ogra_ | equally 5107, 5108 and 5110 | 10:05 |
| cjwatson | ogra_: Ah, right. Please file a bug against LP itself - we'll need to be more selective about which files we upload to the store | 10:07 |
| ogra_ | cjwatson, yep ... it is blocking all upload apart from ppc64el and s390x now it seems ... i assume these two dont generate manifests | 10:10 |
| ogra_ | *uploads | 10:10 |
| cjwatson | ogra_: Dropping the manifest temporarily will work around it. | 10:10 |
| ogra_ | k | 10:10 |
| cjwatson | ogra_: But I should be able to fix it reasonably quickly. | 10:10 |
| ogra_ | thats good enough :) | 10:11 |
| ogra_ | ok | 10:11 |
| ogra_ | cjwatson, Bug #1625117 for you | 10:26 |
| mup | Bug #1625117: store uploads fail since os snaps publish manifest files <Launchpad itself:New> <https://launchpad.net/bugs/1625117> | 10:26 |
| cjwatson | Ta | 10:27 |
| mup | PR snapd#1942 opened: Initial support for download deltas (via SNAPPY_DELTA_DOWNLOAD_FORMATS) <Created by absoludity> <https://github.com/snapcore/snapd/pull/1942> | 10:33 |
| === hikiko is now known as hikiko|ln | ||
| mup | PR snapd#1943 opened: wrappers: add new X-Snap-Exec=$snap.$app support to .desktop files <Created by mvo5> <https://github.com/snapcore/snapd/pull/1943> | 10:54 |
| mvo | seb128: https://github.com/snapcore/snapd/pull/1943 this is what you asked for last week, right? | 10:55 |
| mup | PR snapd#1943: wrappers: add new X-Snap-Exec=$snap.$app support to .desktop files <Created by mvo5> <https://github.com/snapcore/snapd/pull/1943> | 10:55 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mectors | how do I use the content plug to allow a snap to read the directory /root/.certs/? | 11:42 |
| ogra_ | you would need a snap that provides /root i guess (no, thats not possible) | 11:43 |
| ogra_ | and i doubt you will have any access to "dot" dirs anyway ... | 11:43 |
| mectors | ogra: thanks | 11:52 |
| === hikiko|ln is now known as hikiko | ||
| mectors | ogra: how do I execute a script to change a file so I can rewrite the directories? | 12:06 |
| mectors | basically execute a sed s/root/$SNAP_DATA/ | 12:08 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | mectors, i'D use a wrapper script | 12:13 |
| morphis_ | niemeyer: was about to try the spread snap, how is that supposed to work for local backends like kvm or lxd? | 12:35 |
| morphis_ | getting errors like: 2016/09/19 14:33:36 Cannot allocate qemu:ubuntu-16.04: cannot launch qemu qemu:ubuntu-16.04: exec: "kvm": executable file not found in $PATH | 12:36 |
| mectors | ogra: how does a wrapper script work? | 12:37 |
| tenaciousmv | hi. I'm trying to get the nodejs-plugin-based shout demo working: https://github.com/snapcore/snapcraft/tree/master/demos/shout when I build and install it locally, i don't see anything in /snap/bin afterward | 12:44 |
| tenaciousmv | but when i run `snap install shout` instead it works | 12:44 |
| tenaciousmv | i used --force-dangerous for the local install | 12:45 |
| tenaciousmv | snapcraft v 2.17 | 12:45 |
| ogra_ | mectors, https://github.com/ogra1/laidout ... look at snapcraft.yaml and wrapper.sh there ... thats a very simple wrapper script | 12:46 |
| mectors | ogra: thanks | 12:47 |
| fearing | found this in my history just seeing what this is | 12:57 |
| zyga | jdstrand: hello | 12:58 |
| ogra_ | ppisati_, btw, bug 1625177 | 12:58 |
| mup | Bug #1625177: OOPS on beaglebone on boot of 4.4.0-36-generic under snappy ubuntu core xenial <linux (Ubuntu):New> <https://launchpad.net/bugs/1625177> | 12:58 |
| jdstrand | zyga: hi! | 12:58 |
| zyga | jdstrand: hey, I merged secure_getenv improvement, I noticed your NAK in the morning | 12:59 |
| zyga | jdstrand: I'd appreciate a post-merge review of this 3 line function | 12:59 |
| zyga | jdstrand: just to be on the safe side :) | 12:59 |
| zyga | jdstrand: I'd like to file the bugs for apparmor issues we found last week | 13:00 |
| zyga | jdstrand: do you have a preference? is launchpad oka? | 13:00 |
| sergiusens | can't you just command do `command: desktop-launch $SNAP/usr/bin/laidout "$@"`? | 13:02 |
| sergiusens | err, without the $@ | 13:02 |
| ogra_ | sergiusens, yeah, that snap is super old ... from a time where the desktop-launcher stuff was still in development | 13:03 |
| ogra_ | and it was only a proof of concept to show someone that i can make a snap from an upstream binary in less than 10min | 13:03 |
| jdstrand | zyga: thanks for fixing that. I'll take a look. I filled the apparmor bug already | 13:03 |
| * jdstrand looks for it | 13:03 | |
| ogra_ | sergiusens, effectively the wrapper is nonsense there ... at least nowadays (and i doubt with the new laucnehrs it wouldnt even build anymore) | 13:04 |
| jdstrand | zyga: https://bugs.launchpad.net/apparmor/+bug/1624497 | 13:04 |
| mup | Bug #1624497: complain mode blocks access to nsfs (/proc/self/ns/*) without exec rule <AppArmor:Confirmed> <https://launchpad.net/bugs/1624497> | 13:04 |
| sergiusens | zyga are you aware of any missing interface work to get tray icons to work? My telegram snap has the forbidden icon since forever and I know that kyrofa has some snaps in that state too | 13:09 |
| zyga | sergiusens: no, is there a bug report for this somewhere? | 13:10 |
| zyga | sergiusens: I'll check out your snap later today so that I can perhaps see this myseld | 13:10 |
| sergiusens | zyga hmm, kyrofa or seb128 I guess would know | 13:11 |
| seb128 | sergiusens, zyga, could be bug #1600136 | 13:13 |
| mup | Bug #1600136: App indicator does not show icon for Qt apps <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1600136> | 13:13 |
| seb128 | it's trying to use /tmp to share the icon | 13:13 |
| didrocks | sergiusens: that's what we discussed during the heidelberg sprint (and the bug seb128 referenced). Main issue is this /tmp thing in appmenu-qt | 13:14 |
| zyga | jdstrand: one tiny unrelated issue, the base profile doesn't allow xdg-open | 13:17 |
| zyga | jdstrand: and the executable in the core snap (which is probably out of date anyway) is in /usr/local | 13:17 |
| zyga | jdstrand: I was thinking about adding it to the main template | 13:18 |
| zyga | jdstrand: to /usr/bin/xdg-open xi, | 13:18 |
| jdstrand | zyga: I would think that the unity7 interface would make more sense. it is only for desktop applications, no? | 13:19 |
| zyga | jdstrand: well, I don't know | 13:19 |
| zyga | jdstrand: perhaps | 13:19 |
| zyga | jdstrand: though at the same time, I don't know | 13:19 |
| jdstrand | "xdg-open is for use inside a desktop session only. It is not recommended to use xdg-open as root." | 13:19 |
| jdstrand | from it's man page | 13:20 |
| zyga | jdstrand: in any case we need to have it somewhere and document it | 13:20 |
| jdstrand | please use unity7 for now. we can move it to default if required, but I don't think we will | 13:20 |
| jdstrand | also, yeah, moving out of /usr/local would be good too | 13:20 |
| jdstrand | I'm not sure how that would work on an actual desktop though... | 13:21 |
| zyga | jdstrand: on the desktop there's snapd-xdg-open | 13:21 |
| zyga | jdstrand: we need to keep things in sync as AFAIK they drifted apart now | 13:21 |
| zyga | jdstrand: I'll try to untangle it | 13:21 |
| jdstrand | well, now I'm confused | 13:21 |
| jdstrand | ok, so snapd-xdg-open is what snapd provides, not xdg-open? | 13:22 |
| didrocks | jdstrand: snapd-xdg-open is the service on the desktop side answering to our fake xdg-open requests over dbus | 13:24 |
| didrocks | (and snapd-xdg-open calls the real xdg-open on the desktop) | 13:24 |
| jdstrand | so why is zyga requesting we add xdg-open to the policy? | 13:24 |
| ogra_ | there is one xdg-open *inside* the ubuntu-core snap ... thats the one in /usr/local ... on the desktop side there is /usr/lib/x86_64-linux-gnu/snapd-xdg-open which (as i understand) is supposed to talk to the oone inside the snap | 13:24 |
| ogra_ | and this is all along with the default xdg-open you have installed on a desktop anyway | 13:25 |
| jdstrand | shouldn't the one in /usr/local go away then? | 13:25 |
| jdstrand | (in the all snaps image) | 13:26 |
| ogra_ | well, it should surely move to /usr/bin | 13:26 |
| seb128 | that one is our small wrapper doing the dbus call | 13:26 |
| zyga | jdstrand: yes | 13:26 |
| jdstrand | and people just use snapd-xdg-open? | 13:26 |
| zyga | jdstrand: I don't know how it managed to get there TBH | 13:26 |
| seb128 | snapd-xdg-open is on the host | 13:26 |
| seb128 | not in the snap | 13:26 |
| zyga | jdstrand: no, people use xdg-open | 13:26 |
| jdstrand | man, this is confusing | 13:26 |
| ogra_ | ah, well, i dont know if snapd-xdg-open? doesnt need the one inside the snaps | 13:26 |
| zyga | jdstrand: that talks to snapd-xdg-open in the distro | 13:26 |
| seb128 | that's the service listening to the dbus call | 13:26 |
| jdstrand | so on all snaps, we call it xdg-open, but it is really a wrapper. on desktop it is snapd-xdg-open cause the real xdg-open is not snapd-xdg-open | 13:26 |
| jdstrand | let's back up | 13:27 |
| seb128 | can't parse that | 13:27 |
| jdstrand | what are snaps supposed to use? | 13:27 |
| seb128 | define snaps? | 13:27 |
| zyga | no, it works the same way everywhere | 13:27 |
| zyga | or actually | 13:27 |
| zyga | no | 13:27 |
| jdstrand | a snap of type: app | 13:27 |
| seb128 | you mean what is a desktop snapped app supposed to use? | 13:27 |
| didrocks | jdstrand: you basically have: xdg-open (fake, in /usr/local), called by the snap app <------ dbus --------> snapd-xdg-open (service, activated by fake /usr/local) which execs real xdg-open | 13:27 |
| zyga | on classic the core snap has 'xdg-open' that talks over dbus to snapd-xdg-open | 13:27 |
| didrocks | the first one is inside the snap/ubuntu-core | 13:27 |
| didrocks | the second part of the array is on the destkop | 13:28 |
| ogra_ | zyga, http://paste.ubuntu.com/23202842/ ... its a buuld time hack | 13:28 |
| ogra_ | *build | 13:28 |
| seb128 | didrocks, to be exact that uses gio and doesn't execs the real xdg-open ;-) | 13:28 |
| jdstrand | with didrocks explanation, why do we need to add anything to the policy-- the xdg-open that talks to snapd-xdg-open is in the snap | 13:28 |
| didrocks | seb128: indeed, to keep the service running :) :p | 13:29 |
| seb128 | well apparently snapd denies /usr/local/xdg-open to be exec | 13:29 |
| jdstrand | seb128: what is the system /usr/local/xdg-open supposed to be used by? | 13:29 |
| seb128 | random code | 13:30 |
| jdstrand | to do what? | 13:30 |
| seb128 | open an url | 13:30 |
| ogra_ | /usr/local/bin/xdg-open FWIW :) | 13:30 |
| jdstrand | meh | 13:30 |
| seb128 | random admin script, desktop apps, command line apps do "xdg-open http:...." | 13:30 |
| jdstrand | I'm not trying to be obtuse, I'm trying to be very specific. there are several things called xdg-open. zyga wants to adjust the policy. I want to know how the pieces fit together | 13:31 |
| seb128 | we also associate that wrapper with "http:" | 13:31 |
| didrocks | for instance, Qt openUrl() is wrapping qtsubprocess.call("xdg-open url") (or whatever is the correct syntax) | 13:31 |
| seb128 | jdstrand, http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/ubuntu-core/hooks/500-create-xdg-wrapper.binary | 13:31 |
| jdstrand | seb128: so why wouldn't that snap ship xdg-open like snaps on classic do? | 13:31 |
| seb128 | code might be easier than words | 13:31 |
| jdstrand | but that is on classic | 13:31 |
| ogra_ | that is why i posted it above :P | 13:31 |
| === petevg is now known as petevg_afk | ||
| seb128 | I don't understand that question | 13:31 |
| seb128 | that wrapper is part of the ubuntu-core image | 13:31 |
| seb128 | why would snap need to ship it? | 13:32 |
| jdstrand | look | 13:32 |
| didrocks | seb128: I think jdstrand is asking, why aren't we asking every snap app using xdg-open to ship it as part of the code | 13:32 |
| seb128 | because it's easier to have it in the base image? | 13:32 |
| jdstrand | I understnad what snappy's xdg-open is supposed to do. I'm trying to reconcile classic and all snaps | 13:32 |
| didrocks | jdstrand: am I right on your question? ^ | 13:32 |
| jdstrand | didrocks: you are | 13:32 |
| didrocks | I think shipping it on runtime snaps might make sense | 13:33 |
| jdstrand | and if it is right to be in the base image, why are we doing things different between classic and all snaps? | 13:33 |
| didrocks | as the usage of xdg-open is often by the toolkit | 13:33 |
| didrocks | not directly or in a awareness-way by the app | 13:33 |
| seb128 | that's not true | 13:33 |
| seb128 | if you look on codesearch.debian.net you can see it's used by stack of random command line tools | 13:33 |
| seb128 | like mutt | 13:33 |
| seb128 | or mc | 13:33 |
| seb128 | or backup script things | 13:34 |
| didrocks | yeah, cli ones might do it… | 13:34 |
| jdstrand | what is interesting about xdg-open on all snaps is there is no desktop by default | 13:34 |
| jdstrand | so shipping it is kinda weird | 13:34 |
| seb128 | doesn't need to be a desktop for it to work | 13:34 |
| seb128 | it's just a wrapper to call the appropriate handle | 13:34 |
| seb128 | that could be links | 13:34 |
| jdstrand | the man page for xdg-open says it needs to run in a desktop session | 13:35 |
| seb128 | we are not using xdg-open though | 13:35 |
| jdstrand | but we are meant to replace it | 13:35 |
| seb128 | we are diverting the command to call our handler that opens a browser | 13:35 |
| jdstrand | and a browser isn't on all snaps | 13:35 |
| sergiusens | didrocks seb128 thanks | 13:36 |
| seb128 | how is "open an url" supposed to work on all snaps? | 13:36 |
| jdstrand | that's a great question | 13:36 |
| jdstrand | I don't think anyone defined that | 13:36 |
| ogra_ | yeah, thats future work | 13:36 |
| jdstrand | (which is what I'm really getting at) | 13:36 |
| seb128 | can we get the cheap trick we currently have to work then? | 13:37 |
| seb128 | until that proper job is done | 13:37 |
| jdstrand | how would it work? | 13:37 |
| seb128 | on classic I mean | 13:37 |
| jdstrand | you call xdg-open and nothing happens | 13:37 |
| zyga | jdstrand: (offtopic): https://github.com/snapcore/snapd/pull/1941 | 13:37 |
| mup | PR snapd#1941: interfaces/builtin: allow mmaping pulseaudio buffers <Created by zyga> <https://github.com/snapcore/snapd/pull/1941> | 13:37 |
| seb128 | well what we currently have would make urls work on classic | 13:37 |
| seb128 | if snap-confine wasn't blocking the xdg-open exec | 13:37 |
| jdstrand | seb128: yes, of cousre we want it on classic. which is why I suggested unity7, but then didrocks said that snaps on classic should ship it | 13:38 |
| zyga | (that's snapd, snap-confine just does what it is told to do) | 13:38 |
| jdstrand | seb128: which brings us full circle-- why do we need to allow it in the policy if apps are meant to ship it | 13:38 |
| zyga | jdstrand: we don't want snaps on classic to ship xdg-open | 13:38 |
| seb128 | I disagree with having every app to ship it | 13:38 |
| didrocks | I didn't say that, I said if we don't want to ship it on ubuntu core snap, maybe having it as part of the toolkit makes sense | 13:38 |
| zyga | jdstrand: because then we are stuck with the interface forever | 13:38 |
| didrocks | but seb128 has some good arguments about cli apps | 13:39 |
| * jdstrand doesn't care where it is shipped-- just trying to find the right place | 13:39 | |
| jdstrand | /usr/local is not the right place btw | 13:39 |
| jdstrand | that is for admins, not system installed software | 13:39 |
| didrocks | I think attente shipped it there because he didn't want to conflict in case we have a "personal snap" shipping the system version | 13:40 |
| seb128 | that's also where we have you fake "apt" that tells you that apt is not supported | 13:40 |
| didrocks | but my memory could be skewed :) | 13:40 |
| didrocks | and good point seb128 ;) | 13:40 |
| seb128 | you->our | 13:40 |
| jdstrand | that is an abuse of /usr/local | 13:40 |
| seb128 | but the reason is probably what did said | 13:40 |
| jdstrand | anyway | 13:40 |
| seb128 | I'm not going to discuss that, it was not my doing but mvo's | 13:41 |
| seb128 | I'm happy for it to change location | 13:41 |
| mvo | jdstrand: /usr/local/bin/{apt,xdg-open} should change location? sure | 13:42 |
| jdstrand | that's kinda a side discussion, but it did add to my confusion | 13:43 |
| seb128 | so summary is | 13:44 |
| jdstrand | fyi, nothing in snap-confine mounts /usr/local from the os for classic for that to work anyway (afaics) | 13:44 |
| seb128 | well, that dir is part of ubuntu-core | 13:45 |
| seb128 | I didn't try in recent weeks but the fake "apt" command was in the snaps last time I tried | 13:45 |
| jdstrand | it is. I'm thinking through what should be done | 13:45 |
| seb128 | so the ubuntu-core /usr/local/bin was available inside the snaps | 13:45 |
| ogra_ | but is it in PATH ? | 13:45 |
| seb128 | yes | 13:45 |
| jdstrand | I guess it probably should be in the core snap, but since nothing in all snaps uses it, that makes me slightly uncomfortable, but I guess there is nothing better that can be done | 13:46 |
| jdstrand | especially if there is defined future work for making it work on all snaps | 13:47 |
| jdstrand | so for now, leaving it in the core snap (but please move it to /usr/bin so we are using the correct locations and for avoiding confusion in the future) and add '/usr/bin/xdg-open ixr,' to the unity7 interface makes the most sense. at least that way if someone on all snaps tries to use it we are suggesting that it isn't supported yet | 13:48 |
| jdstrand | that's my opinion. does that make sense to others? ^ (seb128, didrocks, zyga, mvo) | 13:49 |
| seb128 | jdstrand, that wfm, though it's a crossdesktop thing and used by command line tools often so unsure unity7 is the right interface | 13:50 |
| seb128 | jdstrand, like mutt would probably end up using it to open an url | 13:51 |
| seb128 | unsure how much of a big hammer it is to recommend those to use unity7 | 13:51 |
| jdstrand | seb128: because today the thing it is replacing is documented as requiring a desktop session and because we haven't defined what it should look like without a desktop session | 13:51 |
| seb128 | right, it should need one | 13:52 |
| jdstrand | when we do, it can be moved/added to somewhere else, perhaps the default policy | 13:52 |
| seb128 | but unity7 give you quite some things | 13:52 |
| seb128 | but I guess fair enough for now | 13:52 |
| jdstrand | it could be a separate interface | 13:52 |
| jdstrand | I'm uncomfortable adding it to the default policy because it requires dbus | 13:53 |
| mup | PR snapd#1941 closed: interfaces/builtin: allow mmaping pulseaudio buffers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1941> | 13:53 |
| seb128 | I see | 13:53 |
| didrocks | jdstrand: wfm as well | 13:53 |
| seb128 | well unity7 should do for now | 13:53 |
| mup | PR snapd#1944 opened: many: validate refreshes against validation assertions by gating snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/1944> | 13:54 |
| jdstrand | zyga: so, sounds like adding it to unity7 is the way to go for now since we only support it on classic desktop atm (a comment saying as much would be good). it sounds like mvo may move it from /usr/local. not sure if that is something you would want to do as part of this | 13:56 |
| zyga | jdstrand: OK | 13:57 |
| zyga | jdstrand: will do | 13:57 |
| jdstrand | zyga: if it would help, I could do it. I always have a list of miscellaneous updates :) | 13:57 |
| zyga | jdstrand: if you want to, sure go ahead :) | 13:59 |
| zyga | jdstrand: I'm looking at snap-confine SRU paperwork now | 13:59 |
| mvo | jdstrand: I can look into the move to /usr/bin later, probably tomorrow morning | 14:01 |
| jdstrand | mvo: ok, I'll just add the access to /usr/local and mention in the PR it should be adjusted when it is moved | 14:02 |
| mvo | jdstrand: great, thank you | 14:06 |
| tenaciousmv | sergiusens: do you know of a nodejs-based snap that works when locally built and installed? See my comment above about shout working only when installed from snapcraft store | 14:18 |
| sergiusens | tenaciousmv see your comment where? | 14:19 |
| sergiusens | and yes, it works, our tests make sure of that (shout is in demos) | 14:20 |
| kyrofa | sergiusens, zyga I'm not sure where was ever a bug filed since we never really got to the point where we knew what was causing the bug. didrocks said it needed some love from the desktop team. I was planning on starting an email thread once I had enough spare brainpower for it | 14:20 |
| tenaciousmv | sergiusens: repasting comment: hi. I'm trying to get the nodejs-plugin-based shout demo working: https://github.com/snapcore/snapcraft/tree/master/demos/shout when I build and install it locally, i don't see anything in /snap/bin afterward | 14:24 |
| tenaciousmv | sergiusens: i'm glad the tests pass :) i wonder what i could be doing wrong. I just built, installed (with --force-dangerous) and shout is not in /snap/bin | 14:28 |
| seb128 | mvo, sorry I forgot to reply to your ping earlier, unsure that's best, I would rather not have to modify the upstream .desktop, what sergiusens suggested and sounded nicer was to have that snapcraft.yaml define the .desktop name and let you override the exec and do the sed-ing for you | 14:28 |
| kyrofa | tenaciousmv, the app is a service, which means it generates a systemd unit file instead | 14:29 |
| kyrofa | tenaciousmv, it won't put anything in /snap/bin/ | 14:29 |
| mvo | seb128: works for me, just copy/paste this comment in the PR and I will close it | 14:29 |
| tenaciousmv | kyrofa: after snap install shout, i see it in /snap/bin | 14:30 |
| tenaciousmv | though `which snap` return /usr/bin/snap | 14:31 |
| tenaciousmv | is the verion of shout in the store the one built from the snapcraft.yaml in demos? | 14:32 |
| kyrofa | tenaciousmv, no idea. Who is the publisher? | 14:33 |
| seb128 | mvo, k | 14:33 |
| tenaciousmv | kyrofa: sergiusens | 14:34 |
| kyrofa | tenaciousmv, I'm not sure what he has there. All I know is that this: https://github.com/snapcore/snapcraft/blob/master/demos/shout/snapcraft.yaml will not put anything in /snap/bin/ | 14:34 |
| tenaciousmv | kyrofa: right, exactly | 14:36 |
| tenaciousmv | kyrofa: so how would you run the shout from the demos after installing it? | 14:36 |
| kyrofa | tenaciousmv, it should already be running-- it's a daemon | 14:37 |
| kyrofa | (once you install it, obviously) | 14:37 |
| kyrofa | I'm not sure about the port, though | 14:37 |
| tenaciousmv | kyrofa: so i should be able to see it in service --status-all then no? | 14:39 |
| tenaciousmv | kyrofa: thx for helping btw | 14:39 |
| kyrofa | tenaciousmv, now sure what the `service` command does nowadays, but you should be able to see if with `systemctl status snap.shout.server.service` I think | 14:40 |
| kyrofa | s/if/it/ | 14:40 |
| tenaciousmv | kyrofa: indeed, i see it! | 14:41 |
| tenaciousmv | kyrofa: is there an example of a nodejs app (not a daemon)? | 14:44 |
| kyrofa | tenaciousmv, not that I know of off the top of my head, but you could make the shout one an example if you simply remove the `daemon: simple` line | 14:45 |
| tenaciousmv | kyrofa: ah, duh. Thanks! | 14:45 |
| mup | PR snapd#1943 closed: wrappers: add new X-Snap-Exec=$snap.$app support to .desktop files <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1943> | 14:48 |
| sergiusens | tenaciousmv that demo doesn't setup anything to be in snap/bin | 14:53 |
| tenaciousmv | sergiusens: yea, kyrofa explained it to me. I missed the daemon line in the snapcraft.yaml | 14:53 |
| sergiusens | tenaciousmv shout on the store is in my repo, not in the demos | 14:53 |
| tenaciousmv | sergiusens, ok will check it out | 14:54 |
| mup | PR snapd#1945 opened: Spread out to trusty <Created by vosst> <https://github.com/snapcore/snapd/pull/1945> | 14:59 |
| mup | PR snapcraft#811 opened: Support deb files as sources <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/811> | 15:00 |
| sergiusens | ogra_ ^ for you | 15:01 |
| sergiusens | morphis and maybe you too ;-) ^ | 15:01 |
| ogra_ | bug 1604669 | 15:01 |
| mup | Bug #1604669: Support Installing a local deb package in the snapcraft <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1604669> | 15:01 |
| ogra_ | ah | 15:01 |
| sergiusens | ogra_ ;-) | 15:02 |
| ogra_ | :) | 15:02 |
| jdstrand | seb128: fyi, http://paste.ubuntu.com/23203145/. the all snaps one is more justification that this should still be in unity7 for the moment. the second is on my desktop with snapd 2.14.2 | 15:07 |
| seb128 | k, makes sense | 15:08 |
| seb128 | jdstrand, your desktop doesn't have snapd-xdg-open installed right? | 15:08 |
| seb128 | (we don't depends/recommends it afaik) | 15:08 |
| jdstrand | no | 15:08 |
| seb128 | that's something we should change | 15:08 |
| jdstrand | perhaps we should on classic? | 15:08 |
| seb128 | yes | 15:09 |
| seb128 | mvo, ^ would you be the right person to add snapd-xdg-open to the snapd recommends? | 15:09 |
| jdstrand | snapd-xdg-open doesn't appear to be a package in xenial | 15:09 |
| seb128 | it's in universe | 15:10 |
| seb128 | https://launchpad.net/ubuntu/+source/snapd-xdg-open | 15:10 |
| seb128 | oh, in xenial | 15:11 |
| seb128 | it's in xenial-proposed only | 15:11 |
| jdstrand | I see | 15:11 |
| seb128 | the SRU verification relies on having the wrapper in the ubuntu-core image and working | 15:11 |
| mhall119 | lool: did you say there wouldbe RPi3 images of snappy ubuntu core today? | 15:12 |
| tedg | I'm trying to put a slot on a snap, but it doesn't seem to show up in "snap interfaces" list | 15:13 |
| tedg | Does anyone have a snapcraft.yaml of putting a slot on a snap that I could crib from? | 15:13 |
| lool | mhall119: at least pi2; I'd hope pi3 as well | 15:14 |
| lool | zyga: FTBFS with musl: http://paste.ubuntu.com/23203170/ | 15:15 |
| lool | zyga: missing include probably? | 15:16 |
| lool | I'll double check I have the right version pulled from the build | 15:16 |
| jdstrand | pcoca: hi! | 15:18 |
| jdstrand | pcoca: do you have a moment to talk about bug #1613572 ? | 15:18 |
| mup | Bug #1613572: sandbox denials for snaps on BTLE device <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1613572> | 15:18 |
| mup | PR snapcraft#805 closed: Refresh discharge macaroon if necessary <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/805> | 15:19 |
| mhall119 | lool: when and where will those be available? | 15:19 |
| lool | zyga: http://paste.ubuntu.com/23203191/ | 15:20 |
| tedg | Huh, seems that mongo22 doesn't have a slot either. | 15:21 |
| lool | zyga: right, you missed #include secure-getenv.h in sc-main.c | 15:21 |
| ogra_ | mhall119, dailies (built from the edge channel) are at http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ .. and beta releases are just being announced by mvo | 15:22 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ | 15:23 |
| mhall119 | thanks ogra_ | 15:23 |
| tedg | bluez does, cribbing from there | 15:24 |
| lool | zyga: adding the #include is enough to fix build http://paste.ubuntu.com/23203216 | 15:28 |
| lool | it fails in other components later | 15:28 |
| lool | zyga: http://paste.ubuntu.com/23203233/ | 15:31 |
| popey | mhall119: https://lists.ubuntu.com/archives/snapcraft/2016-September/001166.html :) | 15:32 |
| mhall119 | literally 10 minutes ago, that's timing :) | 15:35 |
| zyga | lool: looking | 15:37 |
| zyga | lool: oh, indeed | 15:37 |
| zyga | lool: thanks, I'll put that into the relase | 15:38 |
| zyga | lool: pushed | 15:41 |
| lool | zyga: lovely, thanks | 15:42 |
| lool | updated my openwrt feed to point at it | 15:43 |
| lool | mhall119: http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ | 15:44 |
| lool | ah too late | 15:44 |
| ogra_ | lool, yeah, and lame too ... http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has so many more exciting bugs | 15:47 |
| mhall119 | lol | 15:49 |
| diddledan | I've reordered the list on https://github.com/ubuntu/snappy-playpen/wiki/SandPit to be alphabetical (also added my attempt at corebird to the list) | 15:54 |
| oparoz | Hello, what's the difference between mvo's all-snaps images and the ones available at cdimage? | 16:07 |
| ogra_ | oparoz, the cdimage ones are official beta images | 16:18 |
| ogra_ | the mov all-snaps ones are obsolete | 16:18 |
| ogra_ | *mvo | 16:19 |
| oparoz | Thanks ogra_ . Does that mean that zyga's script to built images can be updated to point to the beta images? https://github.com/zyga/devtools/blob/master/ubuntu-image | 16:19 |
| ogra_ | oparoz, use http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ or if you like to live on the edge use http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ | 16:20 |
| ogra_ | everything else is dead beef and not supported anymore | 16:20 |
| oparoz | :) | 16:20 |
| ogra_ | since they would be using the wrong creation tool | 16:20 |
| oparoz | wrong creation tool? | 16:21 |
| dduffey | hi, I've tried various snappy 16 pi3 images but they all hang at the 4-rasberry screen | 16:21 |
| dduffey | lool, ^^^ what image are you using/ | 16:21 |
| lool | dduffey: http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current is latest | 16:22 |
| lool | dduffey: you want serial console rather than console | 16:22 |
| lool | but I suppose console should work | 16:22 |
| ogra_ | yeah | 16:22 |
| ogra_ | dont use embedded boards without serial | 16:22 |
| ogra_ | general rule of thumb | 16:22 |
| dduffey | lool, okay | 16:23 |
| tbr | +1 for UART | 16:23 |
| tbr | those things are dirt cheap | 16:23 |
| ogra_ | yeah | 16:23 |
| ogra_ | oparoz, sudo snap install ubuntu-image --devmode --edge ... then you need to create a signed model assertion and have a proper new gadget.yaml following the new format | 16:25 |
| dduffey | lool, thanks ... I am using that image ... normal for it not to hit the network until I plug in a serial console and setup networking, correct? | 16:26 |
| ogra_ | dduffey, you need to run through the console-conf tool, yes | 16:26 |
| ogra_ | else you dont have a user either | 16:26 |
| lool | dduffey: yes | 16:26 |
| oparoz | Thanks ogra_ . I think I'll just wait for you guys to provide the pi2 gadget and updated partitioning script to use an external HD :) | 16:29 |
| ogra_ | http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/ is up to date ... regarding the gadget :) | 16:29 |
| * ogra_ calls it a day | 16:32 | |
| oparoz | Thanks ogra_ | 16:32 |
| ogra_ | np | 16:32 |
| mup | PR snapcraft#812 opened: New plugin: jhbuild <Created by attente> <https://github.com/snapcore/snapcraft/pull/812> | 16:39 |
| mup | PR snapd#1926 closed: tests: add https_proxy into environment as well <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1926> | 16:58 |
| === dames is now known as thedac | ||
| mup | Bug #1625279 opened: cmd_run.go:179: WARNING: cannot create user data directory: cannot create "/home/$USER/snap/$SNAP/$VERSION": mkdir /home/$USER/snap/$SNAP: permission-denied <Snappy:New> <https://launchpad.net/bugs/1625279> | 17:12 |
| tyhicks | zyga: congrats on the release :) | 17:17 |
| sergiusens | so jdstrand or zyga is there a plan of action for LP #1600136 ? | 17:23 |
| mup | Bug #1600136: App indicator does not show icon for Qt apps <snap-desktop-issue> <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1600136> | 17:23 |
| jdstrand | sergiusens: not from me. I gave several ideas on how the desktop team/someone familiar with the technologies could pursue | 17:27 |
| jdstrand | sergiusens: but no one responded | 17:27 |
| jdstrand | ultimately, the snaps are putting things in /tmp and that isn't the same /tmp that the system would see | 17:28 |
| sergiusens | jdstrand oh really, it might be a communication breakdown problem then as I suspect the desktop folk were pointing the other way | 17:28 |
| * sergiusens checks the bug report | 17:28 | |
| jdstrand | well, I'm happy to discuss ways forward, but this is basically the same as all the stuff going into the desktop part. trying to make traditional applications that aren't designed for application isolation work | 17:29 |
| jdstrand | I suspect upstreams would be interested in patches because this would affect any sandboxing mechanism that uses a private /tmp (which is all of them afaik) | 17:31 |
| sergiusens | jdstrand I am going to play with my preload part and see what I can do; but patching upstreams would be ideal ;-) | 17:31 |
| sergiusens | in the case of telegram they already fork and patch Qt so I will try and see if they can take one more patch | 17:32 |
| mup | Bug #1625291 opened: ConnectedSlotSnippet not invoked when connecting two snaps <Snappy:New> <https://launchpad.net/bugs/1625291> | 17:33 |
| kyrofa | sergiusens, jdstrand at the sprint we realized the applications were sending icon blobs | 17:36 |
| kyrofa | sergiusens, jdstrand in dbus I mean | 17:36 |
| kyrofa | We couldn't figure out why they weren't showing up | 17:36 |
| === chihchun_afk is now known as chihchun | ||
| jdstrand | kyrofa: I thought they were sending icon urls that were in /tmp. so the app puts it in its /tmp, but the system sees a different /tmp | 17:45 |
| mup | Bug #1623589 opened: No icons anymore <Snappy:New> <snapweb:Confirmed> <https://launchpad.net/bugs/1623589> | 17:45 |
| sergiusens | kyrofa wait, this isn't in the bug report | 18:12 |
| sergiusens | if it's blobs it should just work however inefficient that is | 18:12 |
| sergiusens | doesn't surprise me given other uses of bus I've seen :-P | 18:13 |
| tenaciousmv | sergiusens: another q about the nodejs plugin | 18:23 |
| tenaciousmv | sergiusens: running npm install as root sometimes has issues | 18:23 |
| kyrofa | jdstrand, sergiusens yeah that's what we all thought, but in heidelberg that didn't appear to be what was happening. I personally didn't update the bug because I was incredibly confused at that point :P | 18:24 |
| tenaciousmv | because of the way npm tries to downgrade privileges or sth | 18:24 |
| tenaciousmv | sergiusens: is there a way to run npm install not as root? | 18:24 |
| tenaciousmv | sergiusens: another technique people use is npm install -g --unsafe-perm <package> | 18:24 |
| tenaciousmv | sergiusens: to prevent user/group switching during the installation | 18:25 |
| jdstrand | kyrofa: ah, well, then perhaps more digging simply needs to be done then documented in the bug and we can go from there | 18:32 |
| kyrofa | jdstrand, indeed | 18:35 |
| mhall119 | zyga: is there a way to specify environment variables in snapcraft.yaml yet? | 18:46 |
| tvoss | niemeyer: o/ | 18:46 |
| niemeyer | tvoss: Heya | 18:52 |
| tvoss | niemeyer: hey, welcome back :) | 18:52 |
| niemeyer | tvoss: Glad to see your PRs coming up :) | 18:52 |
| niemeyer | tvoss: Thanks | 18:52 |
| niemeyer | tvoss: A few comments in one of them.. also, would just like to highlight the fact we have a convention on the summary | 18:53 |
| niemeyer | Please have a look at the list here to get an idea: https://github.com/snapcore/snapd/pulls | 18:53 |
| tvoss | niemeyer: yeah, let me rename them | 18:53 |
| dch | I'm packaging couchdb via snappy. It's important we have a migration story for our 1.6.x debian-style packages to a snappy-based one, and often they have very large databases 500GB upwards, so we can't "just" copy files around. | 18:56 |
| tvoss | niemeyer: working through your comments now | 18:56 |
| niemeyer | tvoss: Thanks again | 18:56 |
| dduffey | okay I have pi3 booting and visiable via usb serial ... it seems to be taking some time after "Stated update resolvconf for Networkd DNS." .. but no login prompt, etc. | 18:57 |
| dch | is it possible to allow a snap to access specific parts of the old existing filesystem, like /var/lib/couchdb or /etc/couchdb/*.ini ? | 18:57 |
| dch | I'm also interested in making the snap available for centos & redhat too, this looks very cool | 18:58 |
| mhall119 | sergiusens: snapcraft is stripping quotes out of the "command:" parameter for my daemon, how can I stop that? | 19:06 |
| sergiusens | tenaciousmv don't run snapcraft as root | 19:06 |
| sergiusens | mhall119 it may just be a bug | 19:08 |
| kgunn | jdstrand: hey, so took strace of amd64 and arm64, they are strikingly similar...so i don't quite see why amd64 succeeds confined and arm64 gets a hard denial | 19:17 |
| kgunn | one of the few differences i see is that the system call signatures are similar but not same...e.g. amd64 open is openat on arm64 | 19:18 |
| kgunn | and stat on amd64 is newfstatat on arm64 | 19:18 |
| kgunn | likewise access on amd64 is faccessat on arm64 | 19:19 |
| mup | PR snapd#1879 closed: debian: adjust installation to account for deputy systemd on trusty <Created by vosst> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1879> | 19:25 |
| mup | PR snapd#1927 closed: tests: account for different PWD handling on trusty <Created by vosst> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1927> | 19:27 |
| tenaciousmv | sergiusens: good idea! thanks | 19:28 |
| mup | PR snapd#1923 closed: tests: replace realpath with readlink -f for trusty support <Created by vosst> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1923> | 19:28 |
| mup | PR snapd#1913 closed: daemon,store: move store login user logic to store <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1913> | 19:38 |
| mup | PR snapd#1946 opened: interfaces: allow xdg-open in unity7, unity7 cleanups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1946> | 19:38 |
| jdstrand | kgunn: syscall numbers are architecure-dependent | 19:40 |
| kgunn | jdstrand: yeah, these arent' the numbers, these are the names of the calls listed in the strace | 19:42 |
| kgunn | jdstrand: but i'm kinda lost on what to do next | 19:42 |
| jdstrand | glibc might implement things differently depending on the arch too | 19:43 |
| kgunn | jdstrand: so do i simply need to add "openat" in my list of mirPermanentSlotSecComp | 19:45 |
| kgunn | ? | 19:45 |
| kgunn | in order to cover both archs? | 19:45 |
| jdstrand | kgunn: I suggest comparing /etc/passwd, /etc/group, /var/lib/extrausers, and compare the file and directory ownerships from / to SNAP_DATA, etc, etc | 19:45 |
| jdstrand | kgunn: do you have a seccomp denial? you shouldn't. openat is allowed | 19:46 |
| jdstrand | kgunn: ie, the policy should already cover both archs for common stuff like that | 19:46 |
| kgunn | jdstrand: lemme look again, i have to drag out all my dragonbaord and cables :) | 19:47 |
| jdstrand | kgunn: the 3 you mentioned are already allowed | 19:47 |
| kgunn | ah k | 19:48 |
| kgunn | i'll double check the exact denial again...i forgot to note it down | 19:49 |
| dduffey | if I have xenial snappy installed, how do i search --edge | 19:49 |
| dduffey | 'snap find --edge" | 19:49 |
| zyga | re | 19:53 |
| jdstrand | kgunn: you are still talking about dac_override, no? or did you get new denials? | 19:53 |
| * zyga gets back to work | 19:53 | |
| jdstrand | morphis: fyi, I approved udisks2, but I think you need to press the publish button | 19:53 |
| mhall119 | sergiusens: this is my snapcraft.yaml: http://paste.ubuntu.com/23204318/ | 20:41 |
| mhall119 | but snapcraft snap turns the exec line into: | 20:42 |
| mhall119 | exec "env" ERL_FLAGS="-couch_ini ${SNAP_DATA}/default.ini ${SNAP_DATA}/local.ini" ${SNAP}/bin/couchdb "$@" | 20:42 |
| mhall119 | wait, that's my modified one | 20:42 |
| mhall119 | exec "env" ERL_FLAGS=-couch_ini ${SNAP_DATA}/default.ini ${SNAP_DATA}/local.ini ${SNAP}/bin/couchdb "$@" | 20:42 |
| mhall119 | ^^ that's what it does | 20:42 |
| mhall119 | so ERL_FLAGS=-couch_ini and then it tries to execute ${SNAP_DATA}/default.ini | 20:42 |
| mhall119 | I think i found a way around it | 20:46 |
| kgunn | jdstrand: ok, interesting, i just rebuilt snapd with only the inclusion of the new | 20:51 |
| kgunn | /run/udev/data/c13:[0-9]* r, | 20:52 |
| kgunn | /run/udev/data/+input:input[0-9]* r, | 20:52 |
| kgunn | ...and that seemed to cure the dac_override need | 20:52 |
| kgunn | jdstrand: only other thing i can think, is i got my dragon into a weird state that a reboot cured? | 20:52 |
| kgunn | at any rate... jdstrand you were ok with me adding those to the mir interface right ^? | 20:53 |
| jdstrand | kgunn: yes | 20:53 |
| jdstrand | kgunn: glad that doc_override went away | 20:54 |
| kgunn | will clean up and submit a pr | 20:54 |
| kgunn | ug... jdstrand getting denial now...this is odd... i'll ping back if i get some consistency.... | 21:09 |
| mwhudson | snappy sure makes reading the output of mount to e.g. find your sdcard harder :-) | 21:13 |
| mwhudson | (lxd and schroot, too) | 21:14 |
| mup | PR snapd#1946 closed: interfaces: allow xdg-open in unity7, unity7 cleanups <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1946> | 21:17 |
| mup | PR snapcraft#813 opened: [WIP] "snapcraft validate" and "snapcraft gated" commands <Created by ralsina> <https://github.com/snapcore/snapcraft/pull/813> | 21:19 |
| kgunn | jdstrand: dang i just got it figured out! ... so i got tired of the screen blanking on dragon, so i added a setterm to my bash | 21:21 |
| kgunn | that was screwing with it, so all good now... | 21:21 |
| * kgunn makes note of setterm being a not good idea with mir testing | 21:21 | |
| kgunn | i had kinda forgotten i even added that.... | 21:22 |
| jdstrand | huh | 21:24 |
| jdstrand | nice find! | 21:24 |
| mhall119 | is there any way to pre-populate $SNAP_DATA without resorting to a wrapper script? | 21:36 |
| mhall119 | twice now I've had snaps that don't need a wrapper except for doing the initial $SNAP_DATA setup | 21:40 |
| mup | PR snapd#1858 closed: interfaces: add stub selinux backend <Reviewed> <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1858> | 21:44 |
| mup | PR snapd#1947 opened: interfaces/builtin: add initial docker interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1947> | 22:03 |
| mup | PR snapd#1619 closed: interfaces/builtin: add initial docker interface <Blocked> <Created by tianon> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/1619> | 22:05 |
| tianon | jdstrand: would it be helpful to just put you directly on the collaborators list for https://github.com/docker-snap/docker ? :) | 23:32 |
| === chihchun_afk is now known as chihchun | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!