| mcphail | Does snap confinement affect dlopen() calls at all? My library is not getting found despite being in the LD_LIBRARY_PATH directory | 00:18 |
|---|---|---|
| nacc | mcphail: is it in the snap's squashfs? | 00:22 |
| mcphail | nacc: yes. Also trying using "snap try" in uncompressed filesystem | 00:25 |
| mcphail | code as per http://paste.ubuntu.com/23209466/ with the libglide2x.so file within the same directory with all the other libs, as per the LD_LIBRARY_PATH variable. Works OK when I set the same variable but run outside snap confinement | 00:30 |
| mup | PR snapcraft#815 closed: Replacing deprecated API for searching snaps <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/815> | 00:48 |
| mup | PR snapcraft#817 closed: lxd: use built-in image streams <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/817> | 00:48 |
| mup | PR snapcraft#814 closed: Make source-depth a parameter and opt-in <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/814> | 01:00 |
| mdye | "snapcraft keys" reports that my default key is not enabled. I've somehow managed to botch registering it by attempting to register multiple keys. Is there a UI or API I can use to de-register or replace keys registered with the store? | 01:02 |
| mwhudson | zyga: uploaded the thing | 01:08 |
| cjwatson | mdye: Unfortunately not yet, though registering multiple keys should work fine. | 01:08 |
| cjwatson | mdye: 2am here, so maybe send mail to the snapcraft list if you can't disentangle it? | 01:10 |
| mdye | cjwatson: alright; I've tried this "snapcraft -d register-key" after generating a new default key and snapcraft failed to register: snapcraft.storeapi.errors.StoreKeyRegistrationError: Key registration failed: Failed to save account-key-request assertion for account_id JmtGtPclFB8St7FNhFmDZ3ijMqEQIbl8: Unexpected response while processing assertion: {"detail":"could not add assertion (revision 0 is already the current | 01:12 |
| mdye | revision)","error_list":[{"code":"invalid-revision","message":"invalid revision: could not add assertion (revision 0 is already the current revision)"}],"status":409,"title":"invalid revision","type":"assertions:v1:invalid-revision"} | 01:12 |
| mdye | happy to post to the list if that seems like the right place to ask given the time | 01:12 |
| cjwatson | Wow that's an ugly error. Suggests it's already registered, though. | 01:14 |
| mdye | right, 409 conflict; I assumed b/c of the name? (default), not b/c of the GPG key's ID | 01:15 |
| cjwatson | Unless it doesn't like it being called default. | 01:15 |
| mdye | right | 01:15 |
| cjwatson | You could always call it something else. | 01:16 |
| mdye | so can I generate my own key (instead of using snapcraft for it), register that, then still use the snap tools to sign with it? | 01:16 |
| cjwatson | You can just use "snap create-key some-other-name", "snapcraft register-key some-other-name". | 01:17 |
| cjwatson | (from memory) | 01:17 |
| mdye | great, thx | 01:17 |
| mdye | and thx for the tools, guys. (zyga, others) | 01:18 |
| cjwatson | We'll have revocation soonish, but still needs some design work (outside of emergency handling) | 01:18 |
| mup | PR snapd#1953 opened: Pass through screenshots from snap store <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1953> | 03:43 |
| === fginther is now known as fginther|away | ||
| === fginther|away is now known as fginther | ||
| zyga | mwhudson: o/ | 04:31 |
| zyga | mwhudson: thank you, I will work on getting it verified | 04:31 |
| freelock[m] | Hi | 04:52 |
| freelock[m] | I'm wondering if a snap package is a good fit for a problem I'm trying to solve... the problem is, I have a bunch of older PHP (Drupal sites) to manage, and a CLI tool to manage them (drush), but this is not happy on Ubuntu 16.04 | 04:53 |
| freelock[m] | I run the actual sites in Docker containers, with an older version of PHP bundled in that Drupal 6 can handle -- these sites have way too many deprecated function calls that have been removed in PHP 7, which is in 16.04 | 04:53 |
| freelock[m] | that all works great, but when I go use the shell tools, running those under php 7 fails completely. I know I can bundle my shell tools in single-run Docker containers, but I was wondering if a snap package might be a good alternative | 04:54 |
| freelock[m] | can you easily bundle older (or newer) versions of things like PHP (or gtk bindings, for another problem I'm trying to solve) in a snap package? | 04:55 |
| === cpaelzer_ is now known as cpaelzer | ||
| mwhudson | zyga: well you need to get an SRU team member to release it first :) | 05:42 |
| mup | PR snapd#1954 opened: Add store.requestOptions.ExtraHeaders so that individual requests can customise headers <Created by absoludity> <https://github.com/snapcore/snapd/pull/1954> | 05:56 |
| zyga | mwhudson: hmm? I don't fully recall the process but AFAIK it gets into proposed and then is verified to be pushed to updates | 06:05 |
| dholbach | good morning | 06:45 |
| didrocks | good morning dholbach | 06:47 |
| dholbach | salut didrocks | 06:47 |
| mcphail | Does snap confinement affect dlopen() calls at all? My library is not getting found despite being in the LD_LIBRARY_PATH directory | 07:13 |
| dholbach | zyga, is https://github.com/ubuntu/snappy-playpen/pull/205 something you wanted to take a look at or validate? it looks like Cemil pinged you as well. | 07:24 |
| mup | PR ubuntu/snappy-playpen#205: Mesa demos <Created by camako> <https://github.com/ubuntu/snappy-playpen/pull/205> | 07:24 |
| zyga | dholbach: looking | 07:24 |
| dholbach | cool, thanks | 07:26 |
| mup | PR snapd#1955 opened: docs: fix formating of HACKING.md "Testing snapd" <Created by mvo5> <https://github.com/snapcore/snapd/pull/1955> | 07:28 |
| subh94 | I am getting error: cannot find signatures with metadata for snap while installing any snap package build on my system, System Information: Snapcraft Version: 2.17, Ubuntu 16.0.1. Even Demo Snap are also not working. Any help with how to resolve this issue. | 07:30 |
| mvo | subh94: can you please try "sudo snap install --dangerous snap-file.snap" ? | 07:31 |
| mcphail | subh94: you now need to pass the --force-dangerous flag | 07:31 |
| mwhudson | zyga: it doesn't get into proposed immediately, it sits here first: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text= | 07:33 |
| mup | PR snapd#1244 closed: snap: show snapname before the progress download <Decaying> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/1244> | 07:33 |
| techtonik | what is the status of support on fedora? | 07:37 |
| dholbach | zyga, I think it's good to go from a playpen perspective | 07:43 |
| mvo | techtonik: zyga wil know the details but AFAIK its available in the fedora devel series | 07:54 |
| mup | PR snapd#1956 opened: many: show snap name before the download progress bar <Created by mvo5> <https://github.com/snapcore/snapd/pull/1956> | 08:35 |
| fgimenez | hey didrocks :) have a minute? | 08:45 |
| didrocks | fgimenez: I can make a minute :-) | 08:46 |
| fgimenez | didrocks, great :) i'm trying to write a test for the gsettings interface, this is what i have so far https://github.com/snapcore/snapd/compare/master...fgimenez:spread-gsettings?expand=1 | 08:46 |
| mectors | I get the following app armor problem when running an updated version of the nodered snap. Did not have this with the version that did not have nodes installed. What is this? Sep 21 07:56:24 ubuntu ubuntu-core-launcher[17194]: STARTING NODE-RED - /snap/nodered/x1/bin/node-red /snap/nodered/x1/settings.js /root/snap/nodered/x1 | 08:47 |
| mectors | Sep 21 07:56:25 ubuntu kernel: [56451.987557] audit: type=1400 audit(1474444585.481:4450): apparmor="DENIED" operation="open" profile="snap.nodered.red" name="/run/resolvconf/resolv.conf" pid=17199 comm="node" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 | 08:47 |
| fgimenez | didrocks, the idea is to install a test snap declaring a plug on gsettings, try to read/write a value with the plug connected and do the same with the plug disconnected, checking the error in that case | 08:47 |
| didrocks | fgimenez: ok, making sense | 08:48 |
| didrocks | I see that you are aware you need the home interface to be able to read the changed value | 08:48 |
| fgimenez | didrocks, so far no luck however, i'm not sure if the test snap is properly defined, could you please take a look? | 08:48 |
| didrocks | (otherwise, you only get defaults) | 08:48 |
| didrocks | oh? I quickly browsed, and it seems ok… | 08:48 |
| didrocks | what doesn't work? | 08:49 |
| didrocks | you don't need the export in set/get if you are using the desktop-launcher normally | 08:50 |
| fgimenez | didrocks, i'm getting this in the read operation http://paste.ubuntu.com/23210600/, this value seems to come from inside the snap because outside the value of that key is different | 08:50 |
| fgimenez | didrocks, ah ok thanks good to know | 08:50 |
| fgimenez | didrocks, what is worst is that the get operation works with the plug disconnected | 08:51 |
| didrocks | fgimenez: yeah, it's using the default | 08:51 |
| didrocks | ok, let me try to build the snap | 08:52 |
| fgimenez | didrocks, ok thanks a lot | 08:52 |
| joc_ | mvo: hi, do you have any suggestions for how i might validate a snap.yaml file for a gadget snap? | 09:04 |
| ogra_ | mvo, what happened to your pastebinit snap, would be really helpful to have it on images again | 09:04 |
| ogra_ | joc_, you coudl show it to someone how knows them ;) (like me) | 09:04 |
| joc_ | ogra_: ha, the manual approach | 09:05 |
| didrocks | fgimenez: same with glib-compile-schemas, you don't need them, the launcher does it for you on first run | 09:07 |
| fgimenez | didrocks, ok thanks, i was getting "No schemas found" without it, maybe the exports were meesing things up | 09:10 |
| ogra_ | joc_, in general the snap.yaml is pretty empty nowadays http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi2/meta/snap.yaml | 09:12 |
| ogra_ | all valuable info moved to the gadget.yaml | 09:12 |
| joc_ | ogra_: yeah this is really a slots issue i think, but it is tricky to validate the yaml if the slots are for interfaces that are Core or Gadget snap only | 09:13 |
| didrocks | fgimenez: you are missing dconf-gsettings-backend stage package | 09:13 |
| ogra_ | oh, yeah | 09:13 |
| didrocks | fgimenez: I didn't add it by default as I'm unsure about adding it in the glib-only profile, then some people like ogra tells the launcher is pulling too many dependencies :) | 09:13 |
| didrocks | and glib-only is really minimal for that purpose | 09:14 |
| didrocks | the rest is ok | 09:14 |
| ogra_ | didrocks, i didnt say that since agess :P | 09:14 |
| didrocks | ahah, you told it enough for a whole year at least! :) | 09:14 |
| fgimenez | didrocks, ah ok, let me try that | 09:14 |
| ogra_ | well, i still think it is overkill in cases where i only want font support to pull in a whole toolkit :) | 09:15 |
| didrocks | glib isn't a toolkit | 09:16 |
| ogra_ | well or a library stack ... whatever | 09:16 |
| ogra_ | Chipaca, hey | 09:21 |
| ogra_ | you pung ? | 09:21 |
| joc_ | ogra_: on the subject of gadget yaml, if you wanted to add some "content:" to the generic pc gadget (all snaps image) and you wanted the target to be a file under /etc that should be visiable when everything is mounted, how would you modify the gadget.yaml file to do that? | 09:22 |
| ogra_ | joc_, i fear you cant ... the gadget will copy everything under /boot/$bootloader/ currently (thats a bug i think) | 09:23 |
| ogra_ | iirc mvo wanted to bring that up with niemeyer (omeone else had that prob too iirc) | 09:23 |
| ogra_ | +s | 09:23 |
| joc_ | ogra_: it might have been woodrow, i was trying to help workout how to get a watchdog config file in to place | 09:24 |
| joc_ | sounds like content in the gadget yaml won't be able to do that | 09:24 |
| ogra_ | joc_, well, on that one i have to defer to mvo | 09:24 |
| ogra_ | right, but it shoudl | 09:25 |
| joc_ | ack | 09:25 |
| ogra_ | but that means "snap prepare-image" (which ubuntu-image calls) needs to support this | 09:25 |
| joc_ | yeah understood, i was wondering if we needed to add some explicit spec of the writable partition to the gadget.yaml and try copying in to there | 09:28 |
| joc_ | assume the tools dont support that though | 09:28 |
| ogra_ | not sure if you could try a relative path ... like "target: ../../writable/system-data/etc/foobar.conf" | 09:29 |
| mup | PR snapd#1957 opened: many: add support for installing/removing multiple snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/1957> | 09:30 |
| ogra_ | but i guess snap prepare-image will reject that ... | 09:30 |
| fgimenez | didrocks, ok, i've pushed the fixes to the test snap https://github.com/snapcore/snapd/compare/master...fgimenez:spread-gsettings?expand=1, rebuilt and reinstalled, but something seems to be missing yet http://paste.ubuntu.com/23210700/ | 09:33 |
| Chipaca | ogra_, hey, i pung | 09:36 |
| ogra_ | so you did :) | 09:36 |
| Chipaca | ogra_, just idle thoughts to poke at the python slowness on bbb | 09:36 |
| ogra_ | replace it with a small shell script ? | 09:36 |
| ogra_ | :P | 09:36 |
| didrocks | fgimenez: /home/fgimenez/.last_revision -> did you install your snap properly? It seems you are setting $HOME to real user home | 09:39 |
| didrocks | you shouldn't export any variable | 09:39 |
| didrocks | or compile schemas | 09:39 |
| Chipaca | ogra_, yeah :-) no wait it was actually trying to see if running it with -SI made it faster, and having you run it with -vv to see if it was imports slowing it down | 09:40 |
| mcphail | Does anyone know if dlopen() calls get changed or intercepted within snap confinement? I'm trying to work out why a library under LD_LIBRARY_PATH isn't being found | 09:40 |
| ogra_ | Chipaca, ah ... well, the binary and startup scripts are inside the squashfs ... that's some work to set up ... but good idea ... perhaps mwhudson could add it to the package for a while (and drop it before next beta) | 09:41 |
| fgimenez | didrocks, i think so, no more export nor compile schemas, the source is at https://github.com/snapcore/snapd/compare/master...fgimenez:spread-gsettings?expand=1, after "snapcraft clean && snapcraft" i install it with "sudo snap install --dangerous ./test-snapd-gsettings-consumer_1.0_amd64.snap" | 09:41 |
| didrocks | fgimenez: ~/.last_revision, is what the launcher is using | 09:42 |
| didrocks | fgimenez: snap run --shell test-snapd-gsettings-consumer.get | 09:43 |
| didrocks | $ echo $HOME | 09:43 |
| didrocks | /home/didrocks | 09:43 |
| didrocks | -> it seems that $HOME isn't set to SNAP_USER_DATA anymore? | 09:43 |
| didrocks | fgimenez: zyga: do you know about this? ^ | 09:44 |
| Chipaca | ogra_, wrt -vv, is there a better way to timestamp stderr than, from bash, 2> >(while read l; do printf "%s %s\n" "$(date -uIns)" "$l"; done) ? | 09:44 |
| Chipaca | ogra_, you could run it by hand once the system is booted and lets you log in, surely? | 09:44 |
| ogra_ | not sure ... i know it falls over when a user exists .. but only later ... | 09:46 |
| Chipaca | ogra_, answering myself wrt better way: yes, redirect the while loop to /tmp/stderr makes things a lot better | 09:46 |
| Chipaca | i.e, python3 -vv /path/to/thing 2> >(while read l; do printf "%s %s\n" "$(date -uIns)" "$l"; done > /tmp/stderr) | 09:47 |
| Chipaca | tadaa, timestamped import log | 09:47 |
| ogra_ | we have a timestamped log ... but that only starts writing stuff once the app started ... we need omething in the systemd that writes a start timestamp | 09:48 |
| ogra_ | *in the systemd unit | 09:48 |
| * ogra_ hass to dig into the setup of the subiquity package ... i think there is a wrapper script somewhere that replaces getty | 09:48 | |
| joc_ | didrocks: i noticed that $HOME change too, i was confused as to why our checkbox snap was storing .config/.cache folders outside of snap folder suddenly | 09:50 |
| didrocks | yeah, it's weird… I think that's known thanks to our testsuite? :) | 09:50 |
| mup | PR snapd#1958 opened: snap: remove extra newline after progress is done <Created by mvo5> <https://github.com/snapcore/snapd/pull/1958> | 09:51 |
| mvo | joc_: yeah, what ogra_ said, its not possible to populate anything outside of the boot partition currently with gadget.yaml | 09:55 |
| mvo | joc_: if that is something we need it should be raised with niemeyer (just for context for niemeyer, the question is if gadget.yaml could support content outside of the boot partition, e.g. to setup bits in /etc) | 09:56 |
| === jamespag` is now known as jamespage | ||
| mvo | ogra_: re keymap> if the keyboard-configuration package is enough that only adds ~600kb or so to the image (unless there is more missing but it looks ok from a quick glance) | 10:20 |
| ogra_ | mvo, yeah, if thats enough, then i'm fine ... as long as it doesnt pull in megabytes of font encodings and whatnot | 10:20 |
| mvo | ogra_: worth a shoot IMO, if its more than that we can pull it out again | 10:22 |
| joc_ | mvo: thanks for the summary | 10:28 |
| mvo | ogra_: so how am I supposed to add keyboard-configuration now? via the system-image seed ? | 10:29 |
| mvo | ogra_: IOW via bzr ? | 10:30 |
| ogra_ | mvo, we will definitely need to be able to add files ... i.e. some USB NICs (like the onboard one on the beaglebone) require sysctl files that are board specific to make the NIC work right | 10:30 |
| ogra_ | mvo, just grab the ubuntu-core-meta packagefrom the PPA | 10:30 |
| ogra_ | then add it to the different system-image-$arch files | 10:30 |
| mvo | ogra_: oh, manually? ok | 10:31 |
| ogra_ | mvo, yeah, no way to edit the seed | 10:31 |
| mvo | ogra_: I'm not sure that is really progress if I need to add that now N times instead of a single time | 10:31 |
| mvo | ogra_: anyway, uploaded, lets see how bad the resulting size increase is and we can revert if it is too terrible | 10:34 |
| === hikiko is now known as hikiko|ln | ||
| ogra_ | well, it is the only way | 10:35 |
| ogra_ | mvo, we could perhaps do an out-of-distro seed to centralize it and keep it editable, but i dont know if germinate would like that, thats a cjwatson question | 10:35 |
| cjwatson | I don't know what an "out-of-distro seed" would be | 10:36 |
| ogra_ | some random bzr branch under snappy-dev | 10:37 |
| ogra_ | our seed currently lives inside the official ubuntu one | 10:37 |
| ogra_ | as "system-image" | 10:38 |
| cjwatson | You can run germinate (specifically in this case germinate-update-metapackage) from whatever input you like; it doesn't care | 10:40 |
| mvo | ogra_: well, its fine for a one-off edit, but when I need to touch this next I will write some script and a system-image.common thing that includes all the common things so that I only need to touch a single file | 10:40 |
| mvo | (or do something else, but not edit N files again :) | 10:40 |
| ogra_ | well, i'm happy with anything you do, just tell me about it :) | 10:41 |
| mvo | ogra_: heh :) nothing for now until I touch this next time | 10:41 |
| * ogra_ is kind of used to doing it that way, we do it on the phone since years | 10:41 | |
| ogra_ | mvo, but perhaps moving to a separate seed file makes more sense ... | 10:42 |
| mup | PR snapd#1959 opened: many: use unique plug/slot names in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1959> | 10:46 |
| ogra_ | Chipaca, so using -SI makes it fall over with imports ... i guess i need to do a bit more here | 10:51 |
| ogra_ | Chipaca, btw, running 'time python -v -c ""' (i.e. just firing up the interpreter) already takes 2sec | 10:57 |
| Chipaca | ogra_, that's python2, not python3 | 11:06 |
| ogra_ | err, sorry ... wrong paste ... i actually called python3 | 11:07 |
| Chipaca | ogra_, what does 'time python3 -v -c ""' say, and what does 'time python3 -IS -v -c ""' say | 11:07 |
| ogra_ | https://bugs.launchpad.net/snappy/+bug/1625698/comments/5 | 11:07 |
| mup | Bug #1625698: console-conf on beaglebone takes unbearable long <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1625698> | 11:07 |
| Chipaca | ogra_, also, the -v there is skewing your metric | 11:08 |
| ogra_ | Chipaca, -IS cuts it by half | 11:08 |
| Chipaca | ogra_, :-) | 11:08 |
| ogra_ | but if i add it to the shebang in the script it doesnt find any of its imports | 11:08 |
| ogra_ | so i guess there is more needed | 11:08 |
| ogra_ | also ... i'm not sure thiss will help at all,. given the CPU alone is saturated for a min or two still ... working on bg processes while the script tries to start | 11:10 |
| ogra_ | we can surely catch some low hanging fruits here when poking at it on the idle board ... but i guess the boot context will still make it super slow ... we only have one core and that is under high load when it runs in its real context | 11:12 |
| ogra_ | (after ten years of battling with python on arm32 i'm rather pessimistic) | 11:13 |
| * mwhudson hands ogra_ a nickel | 11:15 | |
| mwhudson | buy another core! | 11:15 |
| ogra_ | lend me your soldering iron too ! | 11:16 |
| ogra_ | (and some pliers) | 11:16 |
| mwhudson | heh | 11:17 |
| mwhudson | ogra_: i guess if you boot the bbb and let it sit there for 10 minutes before hitting enter, it all happens much more smoothly? | 11:18 |
| ogra_ | i'll have to try, but i bet so too :) | 11:18 |
| mwhudson | seems like it really is down to the single core | 11:18 |
| mwhudson | hum | 11:18 |
| * mwhudson goes to bed rather than trying to be useful | 11:18 | |
| ogra_ | should we just add a "sleep 6000" ? | 11:18 |
| ogra_ | :) | 11:19 |
| ogra_ | mwhudson, we had similar probs with the old snappy that was written in python ... insstalling a nap with it on the bbb took minutes ... | 11:20 |
| ogra_ | *a snap | 11:20 |
| ogra_ | it went down to seconds with the initial switch to the go binary | 11:20 |
| mwhudson | ogra_: well maybe we'll do that here, i'm not signing up to get it done by GA though! | 11:21 |
| ogra_ | yeah, i know :) | 11:21 |
| mwhudson | ogra_: also snap create-user takes 15 mins and that's written in go | 11:21 |
| ogra_ | true | 11:22 |
| ogra_ | but thats also generating keys, no ? | 11:22 |
| mwhudson | er no, misread | 11:22 |
| mwhudson | several minutes, let's say | 11:22 |
| ogra_ | yes | 11:22 |
| mwhudson | ogra_: no, it's just making an api request and calling adduser & friends | 11:22 |
| ogra_ | the log is a bit tricky regarding the timetamps because it get a new ntp time in the middle | 11:23 |
| ogra_ | oh, i thought it also put a public key in place | 11:23 |
| ogra_ | for the store | 11:23 |
| mwhudson | also the timestamps are at minute resolution ffs | 11:23 |
| mwhudson | ogra_: no, it puts stuff in ~/.ssh/authorized_keys but it's not generating anything | 11:24 |
| ogra_ | ah, k | 11:24 |
| mwhudson | unless that's changed since i last looked but i don't think it has | 11:24 |
| Son_Goku | zyga: ping | 11:30 |
| jdstrand | mectors: you need to 'plugs: [ network ]' in your 'red' command | 11:30 |
| niemeyer | mvo, joc_: That sounds slightly strange, but it'd be good to clarify what these bits are to be sure.. | 11:30 |
| mectors | jdstrand, I have the following: red: | 11:31 |
| mectors | daemon: simple | 11:31 |
| mectors | command: bin/launch | 11:31 |
| mectors | plugs: | 11:31 |
| mectors | - network-bind | 11:31 |
| mectors | - network | 11:31 |
| mectors | - network-observe | 11:31 |
| mectors | - bluez | 11:31 |
| mectors | - bluetooth-control | 11:31 |
| mectors | - pulseaudio | 11:31 |
| ogra_ | niemeyer, typically files in /etc/sysctl.d (we discussed them at the sprint even iirc), additional ystemd job files etc | 11:31 |
| niemeyer | In general, we don't want images to diverge in what they contain based on arbitrary bits inserted into the filesystem out-of-band | 11:31 |
| mectors | jdstrand, https://github.com/mectors/nodered.snap | 11:32 |
| === hikiko|ln is now known as hikiko | ||
| niemeyer | ogra_: Yeah, that sounds like content that should go through official means, inside a snap | 11:32 |
| ogra_ | niemeyer, i wanted to put them into the kernel snap and you said they should rathetr be a gadget thing | 11:32 |
| ogra_ | especially the sysctl bits are very board specifc | 11:32 |
| jdstrand | mectors: does 'snap interfaces' show it as connected? | 11:33 |
| ogra_ | i.e. USB NICs might need per board cache sizes you can manage via a sysctl value | 11:33 |
| ogra_ | (and awfully enough the majority of arm boards uses builtin USB NICs) | 11:33 |
| mectors | jdstrand no | 11:34 |
| niemeyer | ogra_: This might be handled as configuration, which the gadget snap can ship as a default system configuration | 11:34 |
| niemeyer | ogra_: handled as kernel configuration, that is | 11:34 |
| ogra_ | niemeyer, right, i think that were your words at the sprint too ;) | 11:34 |
| niemeyer | or core configuration, actually | 11:34 |
| jdstrand | mectors: ok, so that is your problem. however, I don't know why it wasn't autoconnected, cause it should have been. curious, did you install this via a gadget snap? | 11:34 |
| niemeyer | ogra_: Ah, I'm glad there's agreement between me and myself.. sometimes that's not the case | 11:35 |
| ogra_ | you cant handle that in the kernel if the NIC needs different values per board and you dont want tio maintain a kernel for each board | 11:35 |
| mectors | jdstran, no via snap install --force-dangerous | 11:35 |
| ogra_ | i.e. not via a compile time config | 11:35 |
| mectors | jdstrand, no via snap install --force-dangerous | 11:35 |
| ogra_ | our generic kernel supports something like 20 boards currently ... i'D like us to have gadgets in the store for them in the long term ... using the same kernel snap | 11:36 |
| jdstrand | mectors: I suggest filing a bug. give 'snap list' output, the snapcraft.yaml you used and how you installed it, show snap interfaces output and that you expected it to be autoconnected | 11:36 |
| ogra_ | but for that runtime tweaking needs to be possible | 11:36 |
| ogra_ | niemeyer, where would that core config live ? not in the gadget snap ? | 11:37 |
| niemeyer | ogra_: We can if it's a kernel _config_.. but I think core is better nevertheless | 11:37 |
| niemeyer | ogra_: The configuration option/setting/handling would live in the core | 11:38 |
| ogra_ | but we dont have that today | 11:38 |
| niemeyer | ogra_: The gadget will have the ability to ship default configurations for all snaps in the system | 11:38 |
| ogra_ | ah, k | 11:38 |
| niemeyer | ogra_: Not today, no.. we're working on it | 11:38 |
| ogra_ | well, that doent sound like GA though | 11:38 |
| ogra_ | is that on the plan ? | 11:38 |
| ogra_ | (for GA) | 11:38 |
| niemeyer | ogra_: Yes, I hope it is | 11:39 |
| niemeyer | ogra_: (ready by then..) | 11:39 |
| niemeyer | ogra_: With some luck, in the next two weeks | 11:39 |
| ogra_ | especially that watchdog thing is a requirement i think ... we just talked these guys into using systemd watchdog and dropped the universe watchdog package ... | 11:39 |
| jdstrand | mectors: and indicate if snap connect nodered:network ubuntu-core:network works around the issue | 11:39 |
| ogra_ | ok, then we're fine i guess | 11:40 |
| niemeyer | We're _hopefully_ fine ;) | 11:40 |
| ogra_ | heh | 11:40 |
| ogra_ | niemeyer, mvo, another thing iss the GL stuff ... we need to discuss where that lives and how we handle it in regard to the arm boards | 11:40 |
| ogra_ | i imagine the libs should go into the kernel snap ... but we dont support that today | 11:41 |
| ogra_ | (and some bind mount love to put them into ,... what was it ? /usr/lib/gl ? ) | 11:41 |
| ogra_ | (for later (regarding ubuntu-pd) i guess we also need to ship the android container inside the kernel snap and put the right bits in the right places) | 11:43 |
| ogra_ | (not sure what the exact plans are for that one) | 11:43 |
| ogra_ | but i guess the latter bit is something we can talk about at the sprint ... not that urgent | 11:44 |
| mup | PR snapd#1959 closed: many: use unique plug/slot names in tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1959> | 11:56 |
| mup | PR snapcraft#818 opened: Fix trunk <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/818> | 12:03 |
| Son_Goku | zyga: ping | 12:13 |
| mup | PR snapd#1951 closed: interfaces/builtin: improve testability and add regression test for LP: #1625291 <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1951> | 12:14 |
| mup | PR snapd#1954 closed: store : add requestOptions.ExtraHeaders so that individual requests can customise headers <Created by absoludity> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1954> | 12:23 |
| mup | PR snapd#1960 opened: revert 'allow mmaping pulseaudio buffers' <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1960> | 12:30 |
| jdstrand | zyga: fyi ^ | 12:31 |
| jdstrand | zyga: oh, you are fast :) | 12:31 |
| mup | PR snapd#1961 opened: many: avoid snap.InfoFromSnapYaml in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/1961> | 12:34 |
| popey | trying to install dekko from the store... | 12:47 |
| popey | sudo snap install dekko.dekkoproject --channel=edge | 12:47 |
| popey | error: cannot install "dekko.dekkoproject": snap not found | 12:47 |
| popey | any idea what's going on there? | 12:48 |
| popey | it's published, in the edge channel | 12:48 |
| mup | Bug #1626082 opened: Fedora 24 install fail with snapd 2.14 <Snappy:New> <https://launchpad.net/bugs/1626082> | 12:49 |
| mup | PR snapd#1955 closed: docs: fix formating of HACKING.md "Testing snapd" <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1955> | 12:49 |
| sergiusens | popey maybe snap install dekko --edge | 12:58 |
| sergiusens | popey .<developer> is a store artifact | 12:58 |
| popey | error: cannot install "dekko": snap not found | 12:58 |
| sergiusens | popey do you have the link to the store for the snap? | 12:59 |
| DanChapman | snap install --devmode --edge dekko just worked for me. | 12:59 |
| popey | https://myapps.developer.ubuntu.com/dev/click-apps/5980/review/rev/5/ | 12:59 |
| popey | wat | 12:59 |
| popey | that works here too | 12:59 |
| === petevg_afk is now known as petevg | ||
| popey | i can haz dekko | 13:00 |
| popey | \o/ | 13:00 |
| sergiusens | popey oh right, if it requires devmode it needs to be stated | 13:01 |
| kalikiana | There is a dekko snap? Nice. I can stop fixing my build errors in my snapcraft.yaml then :-P | 13:13 |
| kalikiana | Tho I'd be curious how you got oxide working | 13:14 |
| mup | PR snapd#1962 opened: interfaces: drop ErrUnknownSecurity <Created by zyga> <https://github.com/snapcore/snapd/pull/1962> | 13:14 |
| DanChapman | kalikiana, I just disabled oxide's sandboxing `export OXIDE_NO_SANDBOX=1`. Not ideal but at least there is still some protection from snap confinement | 13:17 |
| kalikiana | Oh, good find | 13:17 |
| jdstrand | pcoca: hi! do you have a moment to work through bug #1613572 ? | 13:19 |
| mup | Bug #1613572: sandbox denials for snaps on BTLE device <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1613572> | 13:19 |
| mup | PR snapd#1960 closed: revert 'allow mmaping pulseaudio buffers' <Created by jdstrand> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1960> | 13:20 |
| pcoca | jdstrand, OTP. Is OK to talk in 40 min? | 13:21 |
| mup | PR snapd#1958 closed: snap: remove extra newline after progress is done <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1958> | 13:22 |
| diddledan | dholbach: (replying from yesterday) corebird snapped by github.com/diddledan/corebird-snap in devmode launches but cannot open browser windows to login to twitter with error: Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files | 13:22 |
| dholbach | diddledan, that's probably https://bugs.launchpad.net/snappy/+bug/1580740 | 13:23 |
| 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> | 13:23 |
| diddledan | dholbach: ok, I'll test the proposed snapd to see if that fixes it | 13:25 |
| dholbach | *cross fingers* | 13:26 |
| diddledan | ok, it still fails after installing snapd. I am going to reboot to ensure the state is updated fully. | 13:32 |
| diddledan | right, it still fails after a reboot. shall I mark the verification-failed tag on the bug or just comment with my attempt? | 13:33 |
| dholbach | diddledan, yeah, best to just comment - let me see who to ping about this | 13:36 |
| dholbach | attente, ^ here's probably a test-case for bug 1580740 | 13:37 |
| 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> | 13:37 |
| diddledan | thanks dholbach | 13:39 |
| dholbach | anytime | 13:39 |
| diddledan | I love our community :-) | 13:39 |
| * diddledan cuddles "the community" | 13:39 | |
| dholbach | haha :-) | 13:39 |
| * dholbach hugs diddledan back :) | 13:39 | |
| diddledan | \o/ | 13:39 |
| Chipaca | dholbach, diddledan, you're aware that we know that's broken in current snapd and is fixed on master? | 13:42 |
| dholbach | Chipaca, I thought that's what diddledan tested(?) | 13:43 |
| Chipaca | dholbach, diddledan, that's what https://lists.ubuntu.com/archives/snapcraft/2016-September/001173.html blathers on about | 13:43 |
| diddledan | Chipaca: I was following the comment in the bug that said xenial proposed had a potential fix to be tested | 13:43 |
| Chipaca | sorry, I might be misunderstanding :-) did a very quick scan of the backlog | 13:43 |
| Chipaca | but it sounded like you were saying that you were going to mark the sru of snapd-xdg-open as verification-failed | 13:44 |
| diddledan | Chipaca: oh, I think I might have tested the wrong package | 13:44 |
| diddledan | Chipaca: thanks for pointing out my mistook :-p | 13:44 |
| diddledan | I installed snapd | 13:45 |
| Chipaca | snapd-xdg-open is the thing that should be providing the dbus service | 13:45 |
| diddledan | not snapd-xdg-open | 13:45 |
| * diddledan tries again | 13:45 | |
| Chipaca | and your snap either needs to be in devmode, or you need to have an unreleased snapd | 13:45 |
| Chipaca | (as it's fixed on master but not in 2.14) | 13:46 |
| diddledan | ok, that's working correctly then. | 13:46 |
| diddledan | I installed snapd-xdg-open (0.0.0~16.04) | 13:46 |
| diddledan | now browser windows open correctly \o/ | 13:46 |
| Chipaca | huzzah | 13:47 |
| diddledan | ok, so corebird in devmode works fine then with that package installed | 13:47 |
| Chipaca | diddledan, excellent. As of 2.15.3 (if we cut that) or 2.16, if the snap uses the unity7 interface, it shouldn't need devmode for this | 13:47 |
| Chipaca | diddledan, are you marking it verification-done then :-D | 13:48 |
| Chipaca | anyway, i need to run. ttfn! | 13:48 |
| diddledan | Chipaca: yes, I can do that :-) | 13:48 |
| === chihchun_afk is now known as chihchun | ||
| sergiusens | jdstrand hey, since the snap-confine thing landed in yakkety all our tests are returning with "Segmentation fault" | 13:58 |
| ogra_ | mvo, FYI, your keymap addition grew the snap by ~1M in average | 13:58 |
| jdstrand | zyga: ^ | 13:58 |
| ogra_ | mvo, i think thats bearable ... now cyphermox and/or mwhudson need to write a UI for that :) | 13:59 |
| sborovkov | pitti: hello | 14:02 |
| pcoca | jdstrand, I am done with the call. Do you have time now? | 14:12 |
| jdstrand | pcoca: let's see if we can get through it, though I have to leave in a bit | 14:13 |
| jdstrand | pcoca: in your snap, can you remove 'plugs: [network-bind]' then start the snap and give me the denial in syslog? | 14:13 |
| pcoca | jdstrand, sure, should I then use just the bluetooth-control plug, right? | 14:16 |
| === chihchun_afk is now known as chihchun | ||
| jdstrand | pcoca: yes | 14:18 |
| mup | PR snapcraft#818 closed: Fix trunk <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/818> | 14:18 |
| mup | PR snapd#1947 closed: interfaces/builtin: add initial docker interface <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1947> | 14:19 |
| pcoca | jdstrand, Sep 21 15:21:56 NUC kernel: [25426.260711] audit: type=1400 audit(1474467716.721:142): apparmor="DENIED" operation="create" profile="snap.sensortagbtle.sensortag" pid=21988 comm="bluepy-helper" family="bluetooth" sock_type="seqpacket" protocol=0 requested_mask="create" denied_mask="create" | 14:22 |
| jdstrand | pcoca: can you add to /var/lib/snapd/apparmor/profiles/snap.sensortagbtle.sensortag: 'network blutetooth,' and then do: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.sensortagbtle.sensortag | 14:24 |
| jdstrand | pcoca: then try again | 14:24 |
| tachyons | Hello | 14:29 |
| tachyons | I am trying to make a snap plugin for ruby | 14:29 |
| pcoca | jdstrand, Is not working either. But now I don't see that DENIAL | 14:30 |
| tachyons | everythings works except downloading script download part | 14:30 |
| niemeyer | jdstrand: For future interfaces, please note the small change in convention in #1962 | 14:30 |
| niemeyer | snapd#1962 | 14:30 |
| mup | PR snapd#1962: interfaces: drop ErrUnknownSecurity <Created by zyga> <https://github.com/snapcore/snapd/pull/1962> | 14:30 |
| jdstrand | pcoca: do you see other denials? perhaps a syscall denial? | 14:31 |
| tachyons | using download() method from file base , But shows value out of range | 14:31 |
| pcoca | jdstrand, I added 'network bluetooth,' (The middle t of bluetetooth is a typo, right? (just in case)) | 14:31 |
| pcoca | jdstrand, I got this on the syslog: http://pastebin.ubuntu.com/23211617/ | 14:33 |
| jdstrand | pcoca: yes, that was a typo | 14:34 |
| jdstrand | pcoca: can you add 'bind' (without the quotes) to /var/lib/snapd/seccomp/profiles/snap.sensortagbtle.sensortag and restart the program, pasting syslog | 14:35 |
| Fl1nt | Hi guys!! | 14:37 |
| pcoca | jdstrand, http://pastebin.ubuntu.com/23211625/ | 14:39 |
| jdstrand | pcoca: can you do the same but with 'getsockopt' | 14:40 |
| jdstrand | pcoca: I'm going to have to leave for an appt. you can continue this process by looking at 'syscall=55' in the denial and running 'scmp_sys_resolver ##' | 14:41 |
| jdstrand | pcoca: and report back what you needed. I'll circle back so don't worry if you get stuck | 14:41 |
| Fl1nt | Guys, I'm thinking of building a snapd scheduler or at least a prototype to be able to manage a swarm of snapd available devices. From what I read, a program can manage the snapd daemon through its REST API (Unix socket for now, I noticed that), but I'm wondering if a snaped apps would be able to do it or if I need this scheduler to be run by an uncontainerized app? | 14:42 |
| pcoca | jdstrand, now it works :) | 14:43 |
| Fl1nt | if a snaps is able to manage the snapd daemon on containerized mode, how am I supposed to bind it to the REST API using a containerized context? I thought to use the interfaces (plugs/slot) but I need this snaps to use the network-bind and network interfaces. Are those interfaces enough? | 14:44 |
| pcoca | jdstrand, I will update the bug info | 14:46 |
| Fl1nt | anyone? | 14:48 |
| joc_ | Fl1nt: i think you are looking for the snapd-control interface | 14:52 |
| Fl1nt | oh, nice, I'll take a look at. | 14:52 |
| Fl1nt | nop, snaps-control is just able to control the snaps, I want my snap to be able to reach the snapd API as in: https://github.com/snapcore/snapd/blob/master/docs/rest.md and so retrieve and manage informations that the snaps-control interface is not able to provide. | 14:54 |
| Fl1nt | %s/snaps-control/snapd-control/ | 14:54 |
| joc_ | it does provide access to the socket | 15:01 |
| Fl1nt | are you sure? because the reference doc on this is not really clear on this: http://snapcraft.io/docs/reference/interfaces | 15:02 |
| mup | PR snapd#1857 closed: snap/snapenv, tests: use root's data dirs when running via sudo <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1857> | 15:02 |
| joc_ | yeah the docs are poor, you might need network-bind too, but then you should have access to the api | 15:04 |
| Fl1nt | joc_: another one, if those interfaces are not auto-connect and that I don't want my users having to proceed manually, is there a way to do that? throught an image provisioning system for example? | 15:04 |
| Fl1nt | joc_: I plan to use Ubuntu Core for information. | 15:06 |
| joc_ | i believe that will be supported that via assertions for particular devices, i don't have any more details right now though | 15:08 |
| === zyga_ is now known as zyga-ontheroad | ||
| Fl1nt | I don't understand what you call "Assertions for particular devices" do you mean building an image with a gadget? | 15:08 |
| zyga-ontheroad | mwhudson: hey, apparently snap-confine on yakkety explodes, I'm looking at why now | 15:09 |
| joc_ | yes you would need a gadget snap built using a model assertion for your devices | 15:12 |
| pstolowski | jdstrand, hey! can you have a look at https://github.com/snapcore/snapd/pull/1832/files when you've a moment? this is a new interface for unity8/system settings | 15:12 |
| mup | PR snapd#1832: interfaces/builtin: time-date-control for org.freedesktop.timedate1 <Created by stolowski> <https://github.com/snapcore/snapd/pull/1832> | 15:12 |
| zyga-ontheroad | jdstrand: hey | 15:13 |
| Fl1nt | joc_: OK, perfect :D Thanks for your informations, helped a lot ^_^ | 15:16 |
| mup | PR snapd#1933 closed: store: add "ready to buy" method <Reviewed> <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1933> | 15:25 |
| mup | PR snapd#1963 opened: daemon, overlord: add ReadyToBuy API to snapd <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1963> | 15:27 |
| zyga-ontheroad | jdstrand: hey, can you please restore sanity to my mind and see if snap-confine crashes on startup on 16.10 | 15:32 |
| zyga-ontheroad | jdstrand: sergiusens reported that all snapcraft tests explode right now, I updated a 16.04 box to 16.10, installed snap-confine from the archive and ... nothing explodes | 15:33 |
| zyga-ontheroad | jdstrand: I also rebooted to use yakkety kernel | 15:33 |
| zyga-ontheroad | Linux ubuntu 4.8.0-11-generic #12-Ubuntu SMP Sat Sep 17 20:00:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux | 15:33 |
| zyga-ontheroad | jdstrand: all with ns sharing and everything; | 15:34 |
| zyga-ontheroad | jdstrand: if it also works for you I'll stop panic mode and look at this carefully at home | 15:34 |
| mcphail | Does anyone know if dlopen() calls get changed or intercepted within snap confinement? I'm trying to work out why a library under LD_LIBRARY_PATH isn't being found | 15:39 |
| zyga-ontheroad | mcphail: they are not affected by snap confinement | 15:55 |
| zyga-ontheroad | mcphail: but ... it depends on what you expect | 15:55 |
| zyga-ontheroad | mcphail: can you tell me more about your setup? | 15:55 |
| zyga-ontheroad | mcphail: note that snap-confine is setuid root; that probably ignores LD_LIBRARY_PATH and LD_PRELOAD AFAIR | 15:56 |
| zyga-ontheroad | mcphail: so if you set that inside the wrapper of your application it will be respected | 15:56 |
| zyga-ontheroad | mcphail: but if you want to set it on the outside that will not take any effect | 15:56 |
| zyga-ontheroad | mcphail: you should also be aware of the "chroot" that snap-confine is using (snap-confine is the thing that helps in starting snap apps) | 15:56 |
| zyga-ontheroad | mcphail: you can read more about it here: http://www.zygoon.pl/2016/08/snap-execution-environment.html | 15:57 |
| mup | PR snapcraft#819 opened: Release changelog for 2.18 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/819> | 15:57 |
| zyga-ontheroad | mcphail: (if I dissappear just keep talking to zyga, I'll check my messages back home) | 15:59 |
| mhall119 | is there a docker image that contains snapcraft and it's dependencies already? | 16:00 |
| kyrofa | mhall119, I seem to remember a mailing list thread about that | 16:00 |
| kyrofa | Don't remember what the outcome was, but you might take a look | 16:01 |
| mhall119 | how about an LXC image? | 16:01 |
| * zyga-ontheroad runs again, ttyl | 16:02 | |
| kyrofa | mhall119, I don't remember hearing about that | 16:02 |
| mcphail | zyga: Thanks for that link. I'll read it and ping you later if I have more questions. I was wondering whether something was running setuid root to stop LD_LIBRARY_PATH being read. Thanks for the info | 16:09 |
| joc_ | sergiusens: i would like some advice related to the new python plugin, i notice it modifies it all the shebangs in scripts | 16:18 |
| joc_ | sergiusens: most of my snaps have multiple parts that have python deps from stage packages with other plugins - particularly plainbox-provider plugin | 16:19 |
| joc_ | sergiusens: so now i have files that are different between parts | 16:20 |
| joc_ | sergiusens: what would you suggest is the best solution? | 16:21 |
| elopio | jdstrand: ping. We have a bug here that zyga says needs your attention. It's with the latest snap-confine in yakkety: https://bugs.launchpad.net/snap-confine/+bug/1626121 | 16:43 |
| mup | Bug #1626121: snap-confine causes Segmentation fault <Snappy Launcher:New> <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1626121> | 16:43 |
| elopio | I can reproduce it, but I'm not sure what other useful information to attach. | 16:44 |
| sergiusens | joc_ the old python plugin also did this fwiw | 16:45 |
| sergiusens | joc_ python deps from stage-packages have this general problem and this may mean we need to move this to the `repo` module | 16:46 |
| sergiusens | joc_ do these stage-packages provide runnables? A quick solution is `command: python3 /usr/bin/my-command`; if they are exec'ed from some other component it might be tricker | 16:47 |
| sergiusens | mhall119 kyrofa snapcore/snapcraft on dockerhub | 16:47 |
| Chipaca | ogra_, what image do you use for bbb, btw? | 16:52 |
| joc_ | sergiusens: i was basically just wondering whether i have to add filesets to all parts to filter out clashes or if they some better way | 16:52 |
| sergiusens | joc_ oh, filesets is the way | 16:55 |
| balloons | zyga, snap-confine is still old on xenial. Any hope of SRU'ing 1.41 now? | 17:07 |
| mcphail | zyga: I'm still having trouble. I set the correct LD_LIBRARY_PATH in my run script in my snap, and all the libraries are seen when my binary runs. However, dlopen() does not see the library it needs to open. I've tried moving the library to $SNAP/lib and $SNAP/usr/lib but it still doesn't work. The code fragment is at http://paste.ubuntu.com/23209466/ . How can I get around this? | 17:08 |
| ogra_ | Chipaca, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ note that you need an USB NIC though ... the onboard NIC cuses a kernel oops currently (and you should plug in the USB one after the boot finished) | 17:09 |
| ogra_ | *cusews | 17:09 |
| ogra_ | bah | 17:09 |
| mhall119 | thanks sergiusens | 17:10 |
| mup | PR snapd#1964 opened: tests: add missing quotes in security-device-cgroups/task.yaml <Created by mvo5> <https://github.com/snapcore/snapd/pull/1964> | 17:37 |
| jdstrand | tyhicks, jjohansen: hey, so yakkety is seeing this denial: audit: type=1400 audit(1474474584.561:68): apparmor="DENIED" operation="file_mmap" profile="snap.mosquitto.subscribe" name="/usr/lib/snapd/snap-exec" pid=4525 comm="snap-exec" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0 | 17:47 |
| jdstrand | oh, jj left | 17:47 |
| jdstrand | tyhicks, jjohansen: hey, so yakkety is seeing this denial: audit: type=1400 audit(1474474584.561:68): apparmor="DENIED" operation="file_mmap" profile="snap.mosquitto.subscribe" name="/usr/lib/snapd/snap-exec" pid=4525 comm="snap-exec" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0 | 17:48 |
| tyhicks | jdstrand: 4.8 kernel? | 17:48 |
| jdstrand | tyhicks, jjohansen: in the 4.8 kernel, when would I expect to see policy needing 'm'? | 17:48 |
| jdstrand | tyhicks: "I can reproduce this in a yakkety machine started by adt-run in scalingstack." | 17:49 |
| jdstrand | I'm guessing "yes" | 17:49 |
| jjohansen | jdstrand: yes, this is the semantic change in the kernel I have been warning about | 17:49 |
| tyhicks | I can't answer this question OTOH - jjohansen maybe has a better idea since he did the 4.8 port | 17:49 |
| jjohansen | the location of the mmap check in the binfmt_elf loader changed, and along with it the cred that is used for the check | 17:50 |
| jjohansen | specifically commit 9f834ec18 | 17:51 |
| jdstrand | jjohansen: ok, thanks | 17:52 |
| tyhicks | jdstrand: also, you'll want to be aware of seccomp bug 1626194 - I'm sending a quick fix to the kteam in a few minutes | 17:52 |
| mup | Bug #1626194: Seccomp actions are not audited in the 4.8 kernel <linux (Ubuntu):In Progress by tyhicks> <https://launchpad.net/bugs/1626194> | 17:52 |
| jjohansen | jdstrand: so basically on the exec, the m is falling under the profile instead of the old | 17:52 |
| jdstrand | jjohansen: I see. ok, thanks | 17:53 |
| jdstrand | this is with a chnage_onexec call | 17:53 |
| jdstrand | tyhicks (cc ratliff): fyi, I'm going to need to chase this bug down | 17:56 |
| tyhicks | jdstrand: shouldn't have much to do with change_onexec() but has more to do with the exec() that snap-confine is doing | 17:56 |
| jdstrand | (ie, adjust the policy in snapd so yakkety tests are clear again) | 17:56 |
| tyhicks | jdstrand: ack | 17:57 |
| jdstrand | sure | 17:57 |
| mup | Bug #1626121 opened: snap-confine causes Segmentation fault <Snappy Launcher:Invalid> <Snappy:New> <snap-confine (Ubuntu):Invalid> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1626121> | 17:57 |
| jdstrand | we have a change_onexec to another profile with the exec being on snap-exec | 17:57 |
| jdstrand | this all is consistent with jjohansen's explanation | 17:57 |
| * tyhicks agrees | 17:57 | |
| jjohansen | jdstrand: yeah, lacking the m does cause a segment fault, basically that part of the elf doesn't get mapped, and the exec starts and blows up immediately | 17:59 |
| ratliff | got it, jdstrand | 18:00 |
| jdstrand | fun! :) | 18:00 |
| jdstrand | zyga, elopio: I've responded in the bug and assigned to me | 18:01 |
| elopio | jdstrand: thank you. | 18:01 |
| jdstrand | pcoca: thanks! | 18:03 |
| pcoca | jdstrand, thank you! :) | 18:13 |
| mup | PR snapd#1965 opened: asserts: support for maps in assertions, <Created by pedronis> <https://github.com/snapcore/snapd/pull/1965> | 18:14 |
| sergiusens | thanks jdstrand | 18:15 |
| csutherl | mhall119, hey. is what you provided the latest version of your snap for tomcat? | 18:17 |
| csutherl | mhall119, i had to chmod run.sh before building the package to get it to work. and i see that it can't find conf/tomcat-users.xml already | 18:17 |
| jdstrand | pcoca: fyi, I responded in comment #11 and am back now | 18:19 |
| popey | ogra_: my pi just auto updated and rebooted and it's now no longer on the network | 18:20 |
| popey | and I can't login because i have no password | 18:20 |
| mhall119 | csutherl: yeah, emailing run.sh stripped the permissions, I didn't even think about that | 18:20 |
| mhall119 | csutherl: is tomcat-users.xml in /snap/tomcat/current/conf/ ? | 18:21 |
| popey | (pi 2, daily image) | 18:21 |
| mhall119 | that should be $CATALINA_HOME/conf/tomcat-users.xml | 18:22 |
| csutherl | mhall119, yeah | 18:23 |
| mhall119 | csutherl: is that where it's looking for it? | 18:23 |
| mhall119 | maybe you need to copy it into $CATALINA_BASE/conf/ | 18:24 |
| mhall119 | which would be /var/snap/tomcat/current/ | 18:24 |
| mhall119 | ./conf/ | 18:24 |
| csutherl | hm | 18:24 |
| csutherl | it isn't in there | 18:24 |
| csutherl | /var/snap/tomcat/current/ | 18:24 |
| csutherl | just the server.xml | 18:24 |
| mhall119 | no, I only have it copying the server.xml | 18:24 |
| mhall119 | that was the minimum needed to make it start | 18:25 |
| csutherl | ohoh. gotcha | 18:25 |
| csutherl | let me try that | 18:25 |
| mhall119 | if you want to copy more in, just duplicate the line in run.sh that copies the server.xml | 18:25 |
| mup | PR snapcraft#820 opened: Fixed bug LP: #1607294 snapcraft search returns results in different order <Created by clobrano> <https://github.com/snapcore/snapcraft/pull/820> | 18:37 |
| mup | PR snapd#1962 closed: interfaces: drop ErrUnknownSecurity <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1962> | 18:42 |
| mup | PR snapd#1966 opened: many: avoid snap.InfoFromSnapYaml in tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/1966> | 18:46 |
| popey | ogra_: nvm, reboot 'fixed' it :) | 18:46 |
| mup | PR snapd#1961 closed: many: avoid snap.InfoFromSnapYaml in tests <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1961> | 18:49 |
| mup | PR snapd#1964 closed: tests: add missing quotes in security-device-cgroups/task.yaml <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1964> | 19:29 |
| mup | PR snapd#1890 closed: tests: add spread test for snap create-key/snap sign <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1890> | 19:50 |
| niemeyer | jdstrand: Heya | 19:51 |
| niemeyer | jdstrand: Do you have a moment for a quick look on this one liner: | 19:51 |
| niemeyer | snapd#1875 | 19:52 |
| mup | PR snapd#1875: interfaces/builtin: allow /dev/net/tun with network-control <Created by cmars> <https://github.com/snapcore/snapd/pull/1875> | 19:52 |
| mup | PR snapd#1875 closed: interfaces/builtin: allow /dev/net/tun with network-control <Created by cmars> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1875> | 19:55 |
| jdstrand | niemeyer: it has been on my list. I've been ambivalent about where this rule should go since the PR came in, but I decided just now and commented in the PR (with a +1) | 20:05 |
| jdstrand | niemeyer: also, I've gotten the other pings and they are also on my list. now that docker landed I can look at them after bug #1626121 | 20:07 |
| mup | Bug #1626121: strict mode snaps crash with Segmentation fault on 16.10 <Snappy Launcher:Invalid> <Snapcraft:New> <Snappy:In Progress by jdstrand> <snap-confine (Ubuntu):Invalid> <snapd (Ubuntu):Triaged by jdstrand> <https://launchpad.net/bugs/1626121> | 20:07 |
| mup | PR snapd#1966 closed: many: avoid snap.InfoFromSnapYaml in tests <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1966> | 20:09 |
| diddledan | has anyone managed to get gstreamer-using apps actually using gstreamer libraries? my corebird seems unable to find the gstreamer plugin libraries | 20:10 |
| diddledan | output from attempting to display a video: http://paste.ubuntu.com/23212993/ | 20:11 |
| mcphail | diddledan: I don't know how gstreamer opens its libraries but I wonder if you're hitting the same problems with dlopen() that I am with my snap? | 20:24 |
| diddledan | aah, yeah, my very limited knowledge of shared objects suggests to my memory banks that dlopen works funky compared to LD? | 20:27 |
| diddledan | might be a case of snap just not having dlopen overrides implemented yet | 20:28 |
| mup | PR snapcraft#819 closed: Release changelog for 2.18 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/819> | 20:31 |
| mcphail | diddledan: I can't seem to put a library anywhere a snapped binary can dlopen() it. I'm trying to find out if this is a bug, an error or my part or a "feature" | 20:32 |
| diddledan | well if we're on the same issue then I hope it's a case of "haven't got that far in implementatino yet" :-D | 20:33 |
| mcphail | :) | 20:33 |
| diddledan | yey for progressive improvements | 20:33 |
| mcphail | iteration rules | 20:33 |
| mup | PR snapd#1967 opened: interfaces: allow 'm' in default policy for /usr/lib/snapd/snap-exec <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1967> | 20:49 |
| grahams | Hi, I'm curious to see how easy it would be to create a snappy package from a Arch AUR package, are there any guides on that? | 21:13 |
| grahams | My package is very simple, 1 python script and 3 dependencies | 21:14 |
| kyrofa | Hey grahams, no guide that I know of, but indeed should be quite simple to snap | 21:29 |
| grahams | Thanks, is snapcraft the way to go? I see it in the Arch Aur | 21:41 |
| kyrofa | grahams, typically snapcraft is used to make snaps, yes, but it's pretty tied to Ubuntu right now | 21:42 |
| kyrofa | (e.g. it'll pull debs for dependencies) | 21:42 |
| kyrofa | You can use it in a VM or container if you want to use it | 21:42 |
| grahams | Yes looks like other ran into issues building snap under Arch. Easy enough to spin up a VM | 21:43 |
| mup | Bug #1625813 changed: hardware-observe does not allow reading temperatures <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1625813> | 21:52 |
| mup | PR snapd#1968 opened: interfaces: adjust bluetooth-control to allow getsockopt (LP: #1613572) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1968> | 21:54 |
| zyga | that moment when you want to double tap to zoom in but you update bug statsu to in-progress | 22:41 |
| oparoz_ | I don't understand how SNAP_USER_COMMON is supposed to work since sudo is required to install snaps | 22:42 |
| nacc | oparoz_: SNAP_USER_COMMON, iirc, is just user-specific data for that snap, e.g. ~/snap/<name>/common | 22:46 |
| oparoz_ | nacc, yes, but since snaps are installed as root, then the path is /root/snap/etc. which isn't accessible to the user installing the snap | 22:47 |
| qengho | SNAP_USER_DATA is a user-writable directory that is versioned across snap versions. You can roll back to previous data too there. SNAP_USER_COMMON is one that persists. | 22:49 |
| nacc | oparoz_: not sure i follow, the snap wrapper is root:root, but you can still run it as your user? | 22:50 |
| oparoz_ | qengho, yes, but SNAP_COMMON is the one that persists within the SNAP. I thought SNAP_USER_COMMON would give the user access to a persistent directory within his home folder | 22:51 |
| nacc | oparoz_: i don't believe SNAP_COMMON is "within the SNAP" | 22:51 |
| nacc | oparoz_: well, in classic, at least it's in /var/snap | 22:51 |
| qengho | It does. Or it should. There's a bug with a recent version of snapd. | 22:51 |
| oparoz_ | nacc, it's in snap/yoursnap/common | 22:52 |
| nacc | oparoz_: on classic, SNAP_COMMON is /var/snap/<name>/common, iirc | 22:53 |
| nacc | oparoz_: in which case, it's not in the squashfs (which is what hte snap itself is, imo) | 22:53 |
| oparoz_ | nacc, in this sense, yes, I meant it's still namespaced, but it also is in the home folder, just a different root | 22:54 |
| qengho | "Within the snap" could only mean "within the execution environment and defined in the environment you receive upon running". | 22:54 |
| nacc | oparoz_: sorry, i'm confused, SNAP_COMMON is not in the "home folder", as home is tied to a user, and SNAP_COMMON is not | 22:55 |
| nacc | oparoz_: unless you meant SNAP_COMMON_USER | 22:55 |
| qengho | nacc: You dropped "USER" when you said "SNAP_COMMON". Don't do that. THey're different. | 22:55 |
| oparoz_ | qengho, so how is the user determined? Is there a USER variable stored at install time? | 22:55 |
| nacc | qengho: i did not, oparoz_ did | 22:55 |
| qengho | oparoz_: At run time, you're handed it in environment. | 22:55 |
| nacc | oparoz_: it's in the wrapper script, afaict, it uses $HOME | 22:56 |
| oparoz_ | qengho, OK, so it must be the bug you mentioned then | 22:56 |
| qengho | I meant the literal letters U, S, E, and R. Not a variable called USER. | 22:56 |
| nacc | qengho: yes, i understand what you meant, I think. oparoz_ said "SNAP_COMMON is the one that persists withinthe SNAP", to which i replied, "i don't believe SNAP_COMMON is "within the SNAP"" | 22:57 |
| qengho | See what your snapd defines. $ hello-world.env |grep _COMMON | 22:57 |
| nacc | qengho: ah perhaps that was not directed at me (the literal letters) | 22:57 |
| oparoz_ | The startup script is using: $SNAP_USER_COMMON/downloads. And the log says: Failed to open directory "/root/snap/snapname/common/downloads | 22:58 |
| nacc | oparoz_: are you running the snap as root? | 22:58 |
| qengho | oparoz_: Then you're running it as root. A recent snapd doesn't let the program create $SNAP_USER_COMMON . | 22:58 |
| oparoz_ | nacc, you have to use sudo to install | 22:59 |
| nacc | oparoz_: install and running are not hte same thing | 22:59 |
| nacc | oparoz_: ie., you use sudo apt-get install <pkgname>; you don't (unless you want to run as root) do `sudo <application from pkgname>` | 22:59 |
| oparoz_ | Hmmm... I thought snapd was a system service | 22:59 |
| qengho | oparoz_: Outside, to work around snapd bug $ sudo mkdir /root/snap/snapname/common | 22:59 |
| nacc | oparoz_: i'm still confused on exactly what the issue is, but it seems like qengho has a better handle on helping you :) | 23:01 |
| oparoz_ | qengho, yes, but then the user doesn't have access to that folder | 23:01 |
| nacc | oparoz_: are you having an issue with snapd or a specific snap? | 23:02 |
| qengho | nacc: snapd as of a few days ago doesn't let the app wrapper create the user common dir. | 23:02 |
| nacc | qengho: ah ha | 23:02 |
| oparoz__ | nacc, I don't remember having done anything special to run snapd, just installed it and it's running as root, which I would expect | 23:02 |
| nacc | qengho: but it shouldn't need to create it for root, unless running the snap as root, right? | 23:02 |
| nacc | oparoz__: right, but snapd isn't any of your snaps, per se | 23:02 |
| qengho | nacc: Right. | 23:02 |
| nacc | qengho: ok, thanks for confirming that, still confused on the root issue here, then :) | 23:03 |
| qengho | oparoz_: Let's back up and find out why you're typing "sudo". Explain that part. | 23:03 |
| oparoz__ | sudo snap install transmission | 23:03 |
| qengho | Yes. That makes sense. | 23:03 |
| qengho | oparoz_: Where else are you typing "sudo"? | 23:04 |
| oparoz__ | qengho, nowhere else | 23:04 |
| nacc | oparoz__: how are you running transmission then? | 23:05 |
| qengho | oparoz__: Okay, so it's installed. How do you run transmission? | 23:05 |
| oparoz__ | I have a start-stop script which launches transmission-daemon | 23:05 |
| qengho | oparoz__: And that runs as root? | 23:05 |
| oparoz__ | Yes, because I was told all scripts in a Snap are run as root | 23:05 |
| oparoz__ | So in the list of arguments, there is $SNAP_USER_COMMON/downloads | 23:06 |
| oparoz__ | But I would expect that variable to be determined at install time | 23:07 |
| qengho | oparoz__: All "daemons" that you tell the snap system to manage are run as root. | 23:07 |
| nacc | oparoz__: $SNAP_USER_COMMON by definition is determined at runtime -- how else would it be tied to a specific user? | 23:07 |
| qengho | oparoz__: Is your start-stop inside the snap, or outside, running a snap app? | 23:08 |
| nacc | ah good question | 23:08 |
| oparoz__ | the start-stop is inside the Snap | 23:08 |
| qengho | oparoz__: Okay, then yes, it's running as root, and there's no way to change it from doing so. And its data will be written to a location that you get when you run your snap app and use a environment variable that does not have _USER_ in the middle. | 23:09 |
| oparoz__ | qengho, snapcraft.yaml https://paste.ubuntu.com/23213684/ | 23:09 |
| qengho | oparoz__: If you're running a daemon, you should only have it use something like SNAP_COMMON, and not SNAP_USER_COMMON. | 23:10 |
| oparoz__ | qengho, OK, so there is no way to store the downloads in an easily accessible location | 23:10 |
| qengho | oparoz__: it is easily accessible, from anything defined in the snap. | 23:11 |
| qengho | oparoz__: Where do you expect the data to be going? | 23:11 |
| mup | PR snapd#1967 closed: interfaces/apparmor: allow 'm' in default policy for snap-exec <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1967> | 23:11 |
| qengho | Or want it to. | 23:11 |
| oparoz__ | I want the data to be accessible outside the Snap, without having to ship Samba in the snap | 23:12 |
| qengho | Where? | 23:12 |
| oparoz__ | qengho, /media per example | 23:13 |
| qengho | oparoz__: There is no way to get that with only "snap install", but you could symlink "/var/snap/yoursnap/common" to "/media". | 23:13 |
| oparoz__ | qengho, the problem is that not all environments are going to be the same, so I thought the /home folder of the user who installs the snap would be a good idea | 23:13 |
| qengho | oparoz__: That's fine too, but you can't make the thing a snap service. You can make it a regular app that the user runs. | 23:14 |
| qengho | ...and then you could ask for plug "home". | 23:14 |
| oparoz__ | qengho, Actually, I think I'll do the opposite and define a slot so that other apps can retrieve the data | 23:15 |
| oparoz__ | I need to look into how to mount the slot I connect to I guess | 23:17 |
| oparoz__ | But at least now I know that $SNAP_USER_COMMON doesn't work in that context. Thanks for you help nacc and qengho | 23:18 |
| qengho | welcome! | 23:19 |
| kyrofa | oparoz__, not "all scripts" in a snap run as root, only services | 23:25 |
| kyrofa | oparoz__, non-service apps run as the user who ran them | 23:25 |
| oparoz__ | kyrofa, do you have an example of a non-service app bundled in a snap? | 23:28 |
| kyrofa | oparoz__, yeah, nextcloud :P | 23:28 |
| kyrofa | oparoz__, the mysql-client or occ apps, for example | 23:28 |
| oparoz__ | Ah, but that's command | 23:29 |
| oparoz__ | Just like in a standard system | 23:29 |
| kyrofa | Right. There are only two things: services and non-services | 23:29 |
| oparoz__ | I just thought the snap env would have some memory about who installed it | 23:29 |
| kyrofa | Nope | 23:29 |
| oparoz__ | ;( | 23:30 |
| kyrofa | Snaps are installed system-wide-- what use would there be in keeping track of who installed it? | 23:30 |
| oparoz__ | I'll just have to mount the slot/folder in Nextcloud | 23:30 |
| oparoz__ | Well, some apps are installed for the current user only, if required | 23:31 |
| kyrofa | oparoz__, "some apps" ? | 23:31 |
| kyrofa | I'm not sure I follow | 23:31 |
| oparoz__ | If I install an app in my home folder, it's only available to me | 23:32 |
| kyrofa | oparoz__, there's no such thing for snaps | 23:32 |
| oparoz__ | I guess it's not much of a problem for desktop snaps, since the user can always define folders for storing information, etc. | 23:33 |
| nacc | oparoz__: do you mean if you 'install locally' in ~/bin/ or something? | 23:35 |
| oparoz__ | Yes nacc | 23:35 |
| nacc | oparoz__: yeah there's nothing like that in snaps, but it should be less necessary, in theory too | 23:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!