| mup | PR snapd#2037 opened: asserts,interfaces/builtin,overlord/assertstate: introduce base-declaration <Created by pedronis> <https://github.com/snapcore/snapd/pull/2037> | 00:07 |
|---|---|---|
| mup | PR snapd#2038 opened: many: add email to UserState <Created by matiasb> <https://github.com/snapcore/snapd/pull/2038> | 01:02 |
| mwhudson | uh | 01:07 |
| mup | PR snapcraft#843 opened: Add `snapcraft history` and `snapcraft status` <Created by maxiberta> <https://github.com/snapcore/snapcraft/pull/843> | 04:10 |
| === hikiko_ is now known as hikiko | ||
| mup | PR snapd#2039 opened: overlord/configstate: support nested configuration <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2039> | 04:57 |
| mup | PR snapd#2038 closed: many: add email to UserState <Created by matiasb> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2038> | 05:40 |
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| mup | PR snapd#2040 opened: daemon: add support for `snap create-user --known` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2040> | 07:07 |
| dholbach | good morning | 07:07 |
| === longsleep_ is now known as longsleep | ||
| mup | PR snapd#2041 opened: daemon: add `snap create-user --force-managed` support <Created by mvo5> <https://github.com/snapcore/snapd/pull/2041> | 08:00 |
| mup | PR snapd#2042 opened: daemon: add users to the sysInfo data <Created by mvo5> <https://github.com/snapcore/snapd/pull/2042> | 08:10 |
| popey | As a user of a snap, is there a planned way to get in contact with a developer, or leave a review for a broken snap? | 08:48 |
| popey | e.g. htop is broken on the pi, but works on amd64 | 08:48 |
| === ycheng is now known as ycheng-afk | ||
| mup | PR snapd#2036 closed: daemon, store: switch to new store APIs in snapd <Created by pete-woods> <Merged by pete-woods> <https://github.com/snapcore/snapd/pull/2036> | 10:26 |
| ogra_ | popey, htop works here, whats your issue ? | 10:29 |
| ogra_ | (pi3 that is) | 10:29 |
| mup | PR snapd#2043 opened: store: change purchase to order and store clean up first pass <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2043> | 10:29 |
| popey | ogra_: 2016/09/29 14:49:55.859377 cmd_run.go:179: WARNING: cannot create user data directory: cannot create "/home/popey/snap/htop/41": mkdir /home/popey/snap/htop: permission denied | 10:43 |
| popey | failed to create user data directory. errmsg: Permission denied | 10:43 |
| popey | when i try and run it | 10:43 |
| ogra_ | popey, thats not a htop issue .... i assume you have classic installed and ran sudo classic ? | 10:45 |
| popey | yes | 10:45 |
| oparoz | Hello, where do we report issues with the snap store? | 10:45 |
| ogra_ | and you installed that as your first snap ? | 10:45 |
| popey | possibly, yes | 10:46 |
| ogra_ | well, then the sudo caused /home/popey/snap to be created root owned | 10:46 |
| ogra_ | jusz chrown -R popey /home/popey/snap | 10:46 |
| oparoz | Is "Developer registration portal" correct? | 10:46 |
| ogra_ | there is a bug open somewhere about that | 10:46 |
| popey | ok, thanks | 10:46 |
| popey | \o/ fixed | 10:47 |
| ogra_ | oparoz, https://bugs.launchpad.net/software-center-agent/+filebug | 10:49 |
| oparoz | Thanks ogra_ | 10:50 |
| ogra_ | popey, bug 1620592, seems zyga is on it | 10:50 |
| mup | Bug #1620592: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership <Snappy Launcher:Triaged> <Snappy:New> <https://launchpad.net/bugs/1620592> | 10:50 |
| mup | PR snapd#2044 opened: snap: auto-import assertions from block devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/2044> | 10:53 |
| mvo | pitti: hi, quick question - I have a udev rule in https://github.com/snapcore/snapd/pull/2044/files#diff-ae4a6795688426c8798d190872d58f89R1 that ideally triggers when a new block device is mounted. this works fine, however I noticed there is a small race, i.e. I get the udev event when the device is not fully mount (not available in /proc/self/mountinfo yet). a small wait fixes it but that is of course not ideal, do you have a suggestion how to p | 10:54 |
| mvo | roperly fix this? | 10:54 |
| mup | PR snapd#2044: snap: auto-import assertions from block devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/2044> | 10:54 |
| === hikiko is now known as hikiko|ln | ||
| mup | PR snapd#2044 closed: snap: auto-import assertions from block devices <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2044> | 11:12 |
| * cjwatson belatedly uploads a bzr SRU for https://bugs.launchpad.net/bzr/+bug/1606203 (though it'll need SRU team approval) | 11:24 | |
| mup | Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Bazaar:Fix Committed by vila> <Snapcraft:Invalid by sergiusens> <bzr (Ubuntu):Fix Released> <bzr | 11:24 |
| mup | (Ubuntu Xenial):In Progress by cjwatson> <https://launchpad.net/bugs/1606203> | 11:24 |
| ogra_ | cjwatson, whee ! | 11:30 |
| pitti | mvo: err, udev rules do NOT trigger on mounts, at least not in general; they trigger when a device appears or goes away, or gets reformatted | 11:37 |
| pitti | mvo: how do you mount the device? | 11:38 |
| pitti | mvo: sorry, on a conference, 'orribly lagging on IRC | 11:39 |
| pitti | mvo: if "snap auto-import" does the mouting by itself, don't you want to hand it the device name as an argument? | 11:41 |
| mvo | pitti: yeah, I think that is actually what I want | 11:41 |
| pitti | mvo: but if it doesn't, what *does* mount the device? | 11:41 |
| pitti | mvo: do you have some kind of udisks2 and automounter? | 11:42 |
| mvo | pitti: it seems udev+systemd makes this a bit tricky, maybe with%I and the @ thing of systemd? | 11:42 |
| mvo | pitti: I think snapd may need to do the mounting itself (ro mounting) | 11:42 |
| mvo | pitti: to a temp location and all that, we do not have udisks2 in the general case :/ | 11:42 |
| pitti | mvo: yes, you can start snapd.autoimport@%k.service from the udev rule | 11:43 |
| pitti | mvo: so how does this work right now? (aside from the sleep) | 11:44 |
| mvo | pitti: it works only on the desktop currently, next step is to add mounting if no automounter is available | 11:44 |
| pitti | ah | 11:45 |
| pitti | mvo: open a new unshared mount ns and mount it there, to not confuse the host system | 11:46 |
| mvo | pitti: I guess that is also going to be tricky because I don't want to interfere with the existing automounters | 11:46 |
| ogra_ | we have autofs ... couldnt we use systemds automounter ? | 11:46 |
| mvo | pitti: yeah, that was my thinking | 11:46 |
| pitti | ogra_: you can, if you pin down the mount dir | 11:46 |
| pitti | but then you can't easily have more than one at a time | 11:46 |
| pitti | (not sure if that's a thing) | 11:46 |
| pitti | sorry, need to go again, bbl | 11:48 |
| mvo | pitti: thank you! I will do the %k and %I stuff and do the mounting next, thanks for your help | 11:48 |
| === hikiko|ln is now known as hikiko | ||
| mup | PR snapd#2043 closed: store: change purchase to order and store clean up first pass <Created by pete-woods> <Merged by pete-woods> <https://github.com/snapcore/snapd/pull/2043> | 12:09 |
| mup | PR snapd#2045 opened: many: remove all traces of the /v2/buy/methods endpoint <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2045> | 12:22 |
| mup | PR snapd#2046 opened: cmd, disconnect: abbreviated forms of disconnect <Created by stolowski> <https://github.com/snapcore/snapd/pull/2046> | 12:58 |
| oparoz | Is it possible to namespace snaps at install time? In order to have different versions of the same snap installed | 13:03 |
| Mirv | is there a way to provide configflags with spaces to the autotools plugin without it breaking? | 13:03 |
| oparoz | snap install mysnap --prefix=featureX | 13:03 |
| Mirv | if I use different lines, that works but not when same thing needs to be repeated multiple times. on the same line the space character causes error for the configure script | 13:04 |
| Mirv | (multiple times -> non-unique elements error) | 13:05 |
| mup | PR snapd#2044 opened: snap: auto-import assertions from block devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/2044> | 13:16 |
| popey | when packaging an (python) app which tries to write to /etc/init.d/appname, and obviously fails during snappy, what's best practice here? Patch setup.py and install into some $SNAP.. dir and patch the app not to look in global /etc? | 13:18 |
| mvo | ogra_: so - we think about udisks2 as part of ubuntu-core, what do you think? looks like its just 300kb | 13:19 |
| ogra_ | mvo, not thrilled about adding all that stuff lately .. :(( | 13:19 |
| ogra_ | mvo, why cant you use systemd's automount ? | 13:20 |
| mvo | pitti: so while I was working on this auto-impoter I noticed that its tricky to not get in the way of existing auto-mounting, it feels like replying on udisks2 is more reliable, do you think that is an reaonable idea? add it to ubuntu-core | 13:20 |
| mvo | ogra_: because the names are not predicatable - or am I overlooking a way ? | 13:20 |
| mvo | ogra_: i.e. if there is a way to say "mount any block device to /media/" from systemd that would be great | 13:21 |
| ogra_ | https://www.freedesktop.org/software/systemd/man/systemd.automount.html | 13:21 |
| ogra_ | Where= | 13:21 |
| ogra_ | Takes an absolute path of a directory of the automount point. If the automount point does not exist at time that the automount point is installed, it is created. This string must be reflected in the unit filename. (See above.) This option is mandatory. | 13:21 |
| ogra_ | so you make a udev rule that creates the unit on plugin ... with a "Where=/media/$device-label" or some such | 13:22 |
| ogra_ | and a udev rule that removes the dir on unplug | 13:22 |
| ogra_ | super simple | 13:23 |
| abeato | jdstrand, hi, is it possible to define an apparmor rule that allows access to path "/"? it looks like http://paste.ubuntu.com/23255279/ does not work, for instnace | 13:23 |
| mvo | ogra_: that sounds interessting, I'm slightly concerned about when teams like morphis who use udisks2 as a snap that it does not interfere here | 13:24 |
| ogra_ | mvo, my prob with udisks is that along with the diskspace you also add another constantly running daemon | 13:24 |
| ogra_ | we slowly start to grow out of embedded (though the keyboard stuff was worse here than udisks would be ...) | 13:25 |
| ogra_ | i'm not sure if there would be any interference between automounter and udisks ... thats a pitti question ... worst case we'd need some automatism that turns off the automounter stuff dynamically | 13:26 |
| ogra_ | (we could abuse interfaces here ... if a certain interface is used, turn off the global mounting support and hand it over to the in-snap udisks) | 13:29 |
| ogra_ | (or simply tell morphis to use the system level mounting :P ) | 13:30 |
| jdstrand | abeato: yes, we do that in several places. can you show me the denial? | 13:35 |
| abeato | jdstrand, Error org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.95" (uid=0 pid=5079 comm="/snap/ofono/x1/usr/bin/dbus-send --system --type=m") interface="org.ofono.Manager" member="GetModems" error name="(unset)" requested_reply="0" destination="org.ofono" (uid=0 pid=5061 comm="/snap/ofono/x1/sbin/ofonod -d ") | 13:36 |
| jdstrand | abeato: the apparmor denial from syslog | 13:36 |
| abeato | jdstrand, [22568.513731] audit: type=1107 audit(1475242602.796:90): pid=1198 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.ofono.Manager" member="GetModems" name=":1.103" mask="receive" pid=5061 label="snap.ofono.ofono" peer_pid=5141 peer_label="snap.ofono.dbus-send" | 13:36 |
| abeato | exe="/usr/bin/dbus-daemon" sauid=100 hostname=? addr=? terminal=?' | 13:36 |
| jdstrand | abeato: is the interface connected? | 13:38 |
| abeato | jdstrand, yes | 13:38 |
| jdstrand | can you paste /var/lib/snapd/apparmor/profiles/snap.ofono.ofono ? | 13:39 |
| abeato | jdstrand, things go through with path different from "/" , like /sss | 13:39 |
| abeato | sure | 13:39 |
| mvo | ogra_: I poke at it some more, maybe I find a reliable way | 13:40 |
| abeato | jdstrand, http://paste.ubuntu.com/23255346/ | 13:40 |
| ogra_ | well, i think the systemd automounter should be the way to go | 13:40 |
| * ogra_ wonders if systemd doesnt also have a keymap selection for consoles :P | 13:40 | |
| jdstrand | abeato: can you 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.ofono.ofono' and try again? | 13:43 |
| abeato | jdstrand, same error, must be in another profile | 13:45 |
| abeato | jdstrand, is says exe="/usr/bin/dbus-daemon" ? | 13:46 |
| jdstrand | abeato: what do you mean 'must be in another profile'? | 13:46 |
| jdstrand | that doesn't matter | 13:46 |
| abeato | another apparmor file | 13:46 |
| jdstrand | label="snap.ofono.ofono" | 13:46 |
| jdstrand | that is the profile we need to modify ^ | 13:46 |
| jdstrand | abeato: can you paste the new denial? | 13:46 |
| abeato | jdstrand, [23082.209137] audit: type=1107 audit(1475243116.493:101): pid=1198 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.ofono.Manager" member="GetModems" mask="send" name="org.ofono" pid=5614 label="snap.ofono.dbus-send" peer_pid=5566 peer_label="snap.ofono.ofono" | 13:47 |
| abeato | exe="/usr/bin/dbus-daemon" sauid=100 hostname=? addr=? terminal=?' | 13:47 |
| jdstrand | that is a different denial :) | 13:48 |
| jdstrand | label="snap.ofono.dbus-send" | 13:48 |
| jdstrand | so now update /var/lib/snapd/apparmor/profiles/snap.ofono.dbus-send to have: | 13:48 |
| jdstrand | dbus (send) bus=system path=/ interface=org.ofono.* peer=(name=org.ofono, label=snap.ofono.ofono), | 13:49 |
| jdstrand | abeato: ^ | 13:49 |
| jdstrand | abeato: then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.ofono.dbus-send | 13:50 |
| abeato | jdstrand, aha, let me modify the connected interface | 13:50 |
| jdstrand | abeato: it is important to remember that if you change the apparmor profile on disk, to reload it with apparmor_parser -r. it is also important to remember that we mediate both sides of the connection and to keep the label and the peer_labels straight | 13:50 |
| jdstrand | abeato: it easy to miss something unless you're used to looking at denials | 13:51 |
| jdstrand | it's* | 13:51 |
| abeato | jdstrand, that did the trick, thanks a lot | 13:52 |
| abeato | jdstrand, yep, thanks for the hints :) | 13:53 |
| jdstrand | abeato: fyi, the two rules in http://paste.ubuntu.com/23255346/ could be combined into one: dbus (receive, send) bus=system path=/{,**} interface=org.ofono.* peer=(label=###PLUG_SECURITY_TAGS###), | 13:54 |
| jdstrand | abeato: fyi, the two rules in http://paste.ubuntu.com/23255346/ could be combined into one: dbus (receive, send) bus=system path=/{,**} interface=org.ofono.** peer=(label=###PLUG_SECURITY_TAGS###), | 13:55 |
| jdstrand | sorry for the double paste-- the second rule is what I think you would want | 13:55 |
| abeato | jdstrand, sure, will do that | 13:55 |
| jdstrand | abeato: the path=/{,**} in an alternation. the interface=org.ofono.** is for org.ofono.foo.bar. if you only have org.ofono.* then org.ofono.foo matches, but org.ofono.foo.bar doesn't | 13:56 |
| jdstrand | abeato: perhaps the ofono api doesn't need org.ofono.**, but in case it does, there you go | 13:57 |
| abeato | don't think it needs **, but yeah | 13:58 |
| sil2100 | Hey! I just got back to debugging my simple python3 snap again | 14:10 |
| sil2100 | The problem I have is that the script does not work because I get "exec: image-info: not found" (image-info is the script name) | 14:10 |
| sil2100 | So I went into snap run --shell for the snap and started debugging | 14:11 |
| mup | PR snapcraft#813 closed: "snapcraft validate" and "snapcraft gated" commands <Created by ralsina> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/813> | 14:11 |
| sil2100 | And the strange thing my experiments revealed: the command-image-info.wrappercommand-image-info.wrapper only works when I change the interpreter from sh to bash (uh?) | 14:12 |
| ogra_ | are you using any bashisms ? | 14:12 |
| sil2100 | No, this is just a pure python3 script | 14:12 |
| sil2100 | The part that's failing is the wrapper which is autogenerated I guess? | 14:13 |
| ogra_ | yes, it is | 14:13 |
| sil2100 | With it having the default /bin/sh, the PATH doesn't seem to be respected by the final 'exec' call | 14:13 |
| sil2100 | No idea why | 14:13 |
| ogra_ | (and it works for all other snaps without changing to bash) | 14:13 |
| sil2100 | Yeah, it completely makes no sense to me... | 14:13 |
| sil2100 | No one had any issues like that? | 14:14 |
| ogra_ | i havent heard about any | 14:14 |
| ogra_ | though i havent seen anyone call python3 directly from the apps: entry in snapcraft.yaml either | 14:16 |
| ogra_ | which IIRC you are doing | 14:17 |
| sil2100 | I'm not calling it directly per se, I just install the main part in parts: using the python3 plugin, add the image-info app with the image-info command | 14:19 |
| sil2100 | Since my setup.py installs the python3 scripts to the right bin place | 14:20 |
| sil2100 | So in theory it should all just work: scripts are in the right /usr/bin in the snap, the PATH is set to the correct values | 14:20 |
| ogra_ | show me your snapcraft.yaml again | 14:20 |
| sil2100 | But when trying to run the snap, I get exec: image-info: not found | 14:20 |
| sil2100 | http://paste.ubuntu.com/23255543/ | 14:21 |
| sil2100 | Really simple yaml right now | 14:21 |
| ogra_ | and the image-info script ? | 14:21 |
| ogra_ | (the shebang mainly) | 14:21 |
| sil2100 | Well, the image-info script is "#!/usr/bin/python3" and then the rest of the script | 14:22 |
| ogra_ | right, thats wrong | 14:22 |
| sil2100 | What is failing is the command-image-info.wrapper | 14:22 |
| sil2100 | Wrong? | 14:22 |
| sil2100 | I thought it should be the command to call? | 14:22 |
| ogra_ | make it "#! /usr/bin/env python3" | 14:22 |
| sil2100 | Oh | 14:22 |
| sil2100 | hm | 14:23 |
| ogra_ | you are forcefully calling the python3 from ubuntu-core ... not the one you ship | 14:23 |
| sil2100 | Let me try that | 14:23 |
| mup | PR snapd#2047 opened: snap: auto mount block devices and import assertions <Created by mvo5> <https://github.com/snapcore/snapd/pull/2047> | 14:23 |
| ogra_ | the one you ship is in $SNAP/usr/bin/python3 ... which your env points to | 14:23 |
| ogra_ | (through the PATH) | 14:23 |
| ogra_ | though i thought the python plugin actually re-writes the shebang lines at package build | 14:24 |
| sil2100 | ogra_: yeah, it does - but it re-wrote it to something strange | 14:25 |
| sil2100 | When I examine the /snap/landing-team-tools/x1/usr/bin/image-info script, I see the interpreter being set to "<path to my workdir>/parts/landing-team-tools/install/usr/bin/python3" | 14:25 |
| sil2100 | Doesn't look like it's correct | 14:26 |
| ogra_ | yeah | 14:26 |
| ogra_ | even after you changed the line and re-built ? | 14:26 |
| sil2100 | No, didn't try that yet | 14:26 |
| sil2100 | I'm wondering if it'll help though, as currently the exec line in the wrapper is failing | 14:26 |
| sil2100 | It's not even reaching my image-info script | 14:27 |
| sil2100 | Like, at all | 14:27 |
| ogra_ | "exec: image-info: not found" reads to me like it tries to sxec image-info ... | 14:27 |
| ogra_ | but cant exec it because something inside (the interpreter) is not found | 14:28 |
| ogra_ | else i'd expect "exec: not found" | 14:28 |
| verterok | hi, having some issues while trying to snap an app that tries to write to SNAP_COMMON. the app is unable to write there, getting: permission denied. | 14:31 |
| * ogra_ hugs mvo for https://github.com/snapcore/snapd/pull/2047 | 14:32 | |
| mup | PR snapd#2047: snap: auto mount block devices and import assertions <Created by mvo5> <https://github.com/snapcore/snapd/pull/2047> | 14:32 |
| ogra_ | beautiful :) | 14:32 |
| mvo | ogra_: yeah, all without new stuff | 14:33 |
| ogra_ | yep :D | 14:33 |
| * ogra_ loves it | 14:34 | |
| mvo | ogra_: I'm very happy, probably need a look from pitti but I think its good | 14:34 |
| ogra_ | yeah, looks totally fine to me | 14:34 |
| mvo | morphis: all good, looks like we don't need udisks afterall | 14:34 |
| mvo | morphis: sorry for the noise | 14:34 |
| ogra_ | verterok, looks like either Bug 1611063 or Bug 1610149 | 14:35 |
| mup | Bug #1611063: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1611063> | 14:35 |
| mup | Bug #1610149: writing to the "common" directory needs to have sudo right <Snappy:Invalid> <https://launchpad.net/bugs/1610149> | 14:35 |
| ogra_ | verterok, for a user app/executable you need to use SNAP_USER_COMMON ... SNAP_COMMON would be for a daemon or some sudo executed app | 14:36 |
| verterok | ogra_: ok. I was trying to store a file accesible from this app for any user running it, not just for this user | 14:38 |
| verterok | ogra_: but I think I can workaround this by having a file per user | 14:38 |
| ogra_ | well, or you could create some daemon script that handles the file or so | 14:39 |
| sil2100 | ogra_: hah, ok, I upgraded snapd, ubuntu-core-launcher and snapcraft and now things work | 14:39 |
| ogra_ | hah | 14:39 |
| sil2100 | Strangeness | 14:39 |
| sil2100 | ogra_: thanks for the help nevertheless! :) | 14:40 |
| ogra_ | heh | 14:40 |
| verterok | ogra_: thanks | 14:41 |
| ogra_ | :) | 14:41 |
| Croepha | PRO TIP: if you want ubuntu-image to use your kernel snap locally, you have to specify it with --extra-snaps in addition to setting it in the model assertion | 14:55 |
| ogra_ | yep ... that was just discussed on the meiling list recently :) | 14:55 |
| kyrofa | I was just about to say... that sounds familiar | 14:56 |
| ogra_ | *mailing | 14:56 |
| Croepha | huh | 14:56 |
| Croepha | I had to dig into the snapd source to figure it out | 14:56 |
| ogra_ | niemeyer, i got poked about hibernate on snappy images recently ... that made me think ... we kind of didnt define "swap" as a partition type for gadget.yaml, i think we should add that as optional type | 14:57 |
| kyrofa | Croepha, no! Don't look directly at it! | 14:57 |
| Croepha | my snapd is riddled with fmt.Printfs now | 14:57 |
| kyrofa | Hahaha | 14:57 |
| ogra_ | niemeyer, we'll indeed never used it on SD images ... but i can immagine there are plenty use-cases where people want/need it | 14:58 |
| ogra_ | *use it | 14:58 |
| Croepha | it took me a solid 20 minutes to figure out that ubuntu-image doesn't actually do anything, and it just passes most work off to snapd | 14:58 |
| Croepha | I | 14:58 |
| morphis_ | pitti: ping | 15:02 |
| morphis_ | cyphermox: maybe you can help too | 15:04 |
| morphis_ | pitti, cyphermox: is it correct that netplan does not restart networkd/network-manager when the last netplan configuration file was removed and this causes the current configuration not to be disabled and still being active until the next device reboot? | 15:06 |
| oparoz | Is the apparmor issue with ld.so.preload is only created by Launchpad? | 15:07 |
| kyrofa | oparoz, ask jdstrand | 15:16 |
| ogra_ | lool, is there any reason that snapweb is constanly running instead of using socket activation ? it eats from 10MB reserved memory (pi2) to 30MB (dragonboard) just for idling | 15:17 |
| kyrofa | ogra_, does snapd support socket activation? | 15:17 |
| ogra_ | i guess we dont actually need it running all the time, do we ? | 15:17 |
| ogra_ | kyrofa, well, systemd does ... should only be a matter of writing the unit differently | 15:18 |
| ogra_ | having suchh processes run all the time on an IoT device seems very wasteful | 15:18 |
| kyrofa | ogra_, sure, I'm just saying that I think that might be the reason :P | 15:18 |
| ogra_ | ah | 15:18 |
| ogra_ | k | 15:18 |
| * ogra_ has a hard time resisting to suggest to use a three char suffix at https://github.com/snapcore/snapd/pull/2047 | 15:21 | |
| mup | PR snapd#2047: snap: auto mount block devices and import assertions <Created by mvo5> <https://github.com/snapcore/snapd/pull/2047> | 15:21 |
| jdstrand | oparoz: I don't understand the question. if you are talking about https://bugs.launchpad.net/snappy/+bug/1627813, I need to prepare an update for that | 15:22 |
| mup | Bug #1627813: AppArmor denies access to /etc/ld.so.preload on armhf <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1627813> | 15:22 |
| jdstrand | s/update/PR/ | 15:22 |
| oparoz | Thanks jdstrand. It seems to only happen with Snaps built from Launchpad, but maybe I'm wrong and that bug appeared in a snapd update pushed this week | 15:29 |
| mup | PR snapd#2048 opened: interfaces: allow read of /etc/ld.so.preload by default for armhf on series 16 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2048> | 15:40 |
| jdstrand | oparoz: fyi ^ | 15:40 |
| oparoz | Thanks jdstrand can this be patched live? | 15:42 |
| jdstrand | oparoz: yes. add '/etc/ld.so.preload r,' to /var/lib/snapd/apparmor/profiles/snap.your.app, then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.your.app | 15:43 |
| jdstrand | oparoz: you'll have to do that after refresh, install, install/remove, etc | 15:43 |
| oparoz | Thanks jdstrand that will at least tell me if the other error messages I get related to Go6 are related or not :) | 15:44 |
| oparoz | jdstrand, tht didn't work: AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.spreedme in /var/lib/snapd/apparmor/profiles/snap.spreedme at line 1: syntax error, unexpected TOK_MODE, expecting TOK_OPEN | 15:48 |
| jdstrand | oparoz: can you paste the file in paste.ubuntu.com? | 15:48 |
| oparoz | jdstrand, the file contains a single line: /etc/ld.so.preload r, | 15:49 |
| oparoz | jdstrand, my bad... I overwritten it | 15:50 |
| jdstrand | oparoz: did you delete everything out of that file or create a new one? | 15:50 |
| jdstrand | oparoz: you can uninstall the snap then install it (back up your data if it is important) | 15:50 |
| oparoz | jdstrand, looking at the profiles, I got it wrong. It needs to be installed for every single service and I had used the snap name | 15:53 |
| jdstrand | oparoz: yes, sorry if I wasn't clear. that is what I meant with snap.your.app | 15:54 |
| === victorp_ is now known as victorp | ||
| oparoz | jdstrand, that doesn't change anything unfortunately: https://paste.ubuntu.com/23255934/ | 15:59 |
| === dpm is now known as dpm-afk | ||
| Croepha | so, is the current paradigm to have grub mount the kernel snap and load the kernel that way? | 16:29 |
| Croepha | looks to be that way | 16:41 |
| Croepha | thats pretty clever | 16:42 |
| Croepha | lol, ive got the craziest nesting doll of loopback mounts going on right now, ive got a .img mounted, and I have a kernel snap mounted form inside it, then the initrd inside of it | 17:06 |
| mup | PR snapd#2048 closed: interfaces: allow read of /etc/ld.so.preload by default for armhf on series 16 <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2048> | 17:48 |
| zyga | jdstrand: was this breaking arm snaps? | 17:51 |
| jdstrand | zyga: it was as the reporter said, 'spamming the logs' | 17:51 |
| jdstrand | I don't think it would cause them to break outright | 17:52 |
| jdstrand | but I guess it is possible | 17:52 |
| zyga | jdstrand: I recall someone asking about snaps breaking on arm | 17:52 |
| zyga | jdstrand: with some cryptic message about v6 | 17:52 |
| jdstrand | could be this. could be the 4.8 kernel | 17:52 |
| jdstrand | zyga: oh that was different | 17:52 |
| jdstrand | we fixed that a while ago | 17:52 |
| zyga | jdstrand: was that auxv? | 17:53 |
| jdstrand | that was the 'unsafe' rules | 17:53 |
| jdstrand | yeah | 17:53 |
| zyga | ah | 17:53 |
| zyga | so, i spent part of the day away from home, I managed to make spread testing of snap-confine work offline | 17:53 |
| jdstrand | oh neat :) | 17:54 |
| zyga | I need to automate creation of the offline setup (one file left) but it should be ok | 17:55 |
| zyga | jdstrand: I'll get to making all the small branches for everything today and tomorrow | 17:55 |
| jdstrand | a cool next addition to spread would be running snapd in local lxd | 17:55 |
| jdstrand | I might take a look at that at some point if others don't | 17:55 |
| zyga | jdstrand: oh, after some of my experiments I love qemu | 17:56 |
| zyga | jdstrand: I heard that we can now have nested apparmor, lxd just might be a target now | 17:56 |
| zyga | jdstrand: but still, offline apt, offline snap, that's useful regardless of where that works | 17:57 |
| jdstrand | I <3 qemu (with livirt especially) | 17:58 |
| jdstrand | yes, if you have amd64 you should be able to do nested qemu | 17:58 |
| mup | PR snapd#2049 opened: Allow writing DHCP lease files to /run/NetworkManager/dhcp <Created by ssweeny> <https://github.com/snapcore/snapd/pull/2049> | 17:59 |
| jdstrand | I mention lxd cause running the snapd and snap-confine testsuites inside of lxd shipped as a snap would be handy for local tests but also really exercise the apparmor stacking feature | 17:59 |
| jdstrand | and be a great regression test | 18:00 |
| zyga | hmm, I didn't think about the stacking case, that is a good point | 18:01 |
| jdstrand | it's exciting-- all the pieces are in flight fr 16.10 | 18:02 |
| jdstrand | and once there, the SRUs will begin | 18:02 |
| jdstrand | that is some very cutting edge stuff | 18:03 |
| jdstrand | and it'll be great for the lxd project and snappy | 18:03 |
| zyga | jdstrand: any chance this is all also upstream in relevant places? | 18:06 |
| zyga | btw, the complexity of lxd running as a snap on lxd running as a snap is mind boggling | 18:06 |
| zyga | what's the kernel mount namespace layout again? | 18:06 |
| mup | PR snapd#2050 opened: interfaces/policy: start of interface policy checking code based on declarations <Created by pedronis> <https://github.com/snapcore/snapd/pull/2050> | 18:06 |
| jdstrand | zyga: everywhere except the kernel. the kernel bits are still work in progross | 18:06 |
| zyga | do you need kernel devs? :-) | 18:07 |
| jdstrand | zyga: well, that is deep nesting and won't be supported just yet (it's planned). lxd as a snap running snapd is supported | 18:07 |
| jdstrand | zyga: well, the kernel devs that were working on the upstreaming got put on the stacking feature | 18:08 |
| jdstrand | zyga: tyhicks can comment on the progress and next steps | 18:08 |
| jdstrand | tyhicks: context: stacking support and upstreaming | 18:08 |
| oparoz_ | jdstrand, that bug is killing snaps on armhf | 18:09 |
| jdstrand | oparoz_: ack (zyga ^) | 18:09 |
| oparoz_ | It's impossible to install anything. Services all crash | 18:09 |
| zyga | I was joking :) maybe I can re-brand myself as a junior kernel developer | 18:09 |
| jdstrand | oparoz_: it's committed now | 18:09 |
| oparoz_ | Yeah, I saw, thanks :). I can't test if it works because app-confine doesn't seem to have a customizable apparmor profile | 18:10 |
| tyhicks | zyga, jdstrand: the kernel changes needed for stacking are not upstream | 18:10 |
| tyhicks | zyga, jdstrand: now that stacking is just about finished, upstreaming can commence after the bits of work left for gsettings mediation | 18:11 |
| zyga | oparoz_: snap-confine has a profile that you can change (well, perhaps not in a presistent way but still) | 18:15 |
| oparoz_ | zyga where? | 18:15 |
| oparoz_ | Noting in the apparmor folder | 18:15 |
| oparoz_ | Couldn't find doc about it | 18:16 |
| mup | PR snapd#2035 closed: asserts: support parsing the slots stanza i.e. slot rules in snap-declarations <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2035> | 18:16 |
| zyga | oparoz_: anywhere, you can just load the profile | 18:18 |
| zyga | oparoz_: look at /etc/apparmor.d/usr.lib.snapd.snap-confine | 18:18 |
| zyga | oparoz_: you can copy/edit that anywhere | 18:18 |
| zyga | oparoz_: and load the new version with apparmor_parser -r | 18:18 |
| mup | PR snapd#2042 closed: daemon: add users to the sysInfo data <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2042> | 18:19 |
| oparoz_ | zyga, thanks, that eliminated that one error :) Still one left, but I don't know if it's related to the same problem | 18:22 |
| oparoz_ | zyga, | 18:23 |
| oparoz_ | Sep 30 18:21:40 ubuntu-standard snap[22880]: ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. | 18:23 |
| oparoz_ | Another file to whitelist? | 18:23 |
| zyga | oparoz_: looks like something that jdstrand just fixed | 18:25 |
| jdstrand | oparoz_: /usr/lib/arm-linux-gnueabihf/libarmmem.so probably doesn't exist in the core snap | 18:26 |
| jdstrand | maybe it does. do you have apparmor denials? | 18:26 |
| oparoz_ | 20 -rw-r--r-- 1 root root 18920 Jul 8 2015 /usr/lib/arm-linux-gnueabihf/libarmmem.so | 18:27 |
| oparoz_ | No denials, just ERROR | 18:27 |
| zyga | oparoz_: does it work in devmode? | 18:27 |
| oparoz_ | I've added it to both policies and it doesn't fix things | 18:27 |
| jdstrand | oparoz_: what are you adding to snap-confine's policy? | 18:27 |
| oparoz_ | jdstrand, I added /etc/ld.so.preload r, | 18:28 |
| oparoz_ | and then /usr/lib/arm-linux-gnueabihf/libarmmem.so r, | 18:28 |
| jdstrand | oparoz_: did you have denials for those? | 18:29 |
| oparoz_ | I thoght the 2nd error about libarmmem.so was relatedto the apparmor error from the previous line | 18:30 |
| oparoz_ | jdstrand, but apparently it's unrelated | 18:30 |
| jdstrand | oparoz_: you'll see a new denial for that file if it is blocked by apparmor | 18:30 |
| oparoz_ | jdstrand, so probably not related to that | 18:30 |
| oparoz_ | zyga, doesn't load in devmode either | 18:31 |
| oparoz_ | So the logs still look like that: https://paste.ubuntu.com/23255934/ | 18:32 |
| oparoz_ | Minus the apparmor error | 18:32 |
| jdstrand | oparoz_: are you using an up to date image? (core and kernel in particular) | 18:35 |
| oparoz_ | snap refresh says so | 18:35 |
| zyga | oparoz_: did you reload the profile? | 18:35 |
| oparoz_ | ubuntu-core 16.04.1 424 canonical - | 18:35 |
| jdstrand | oparoz_: cat you paste /etc/apparmor.d/usr.lib.snapd.snap-confine ? | 18:36 |
| mup | PR snapd#1918 closed: tests: add external spread backend <Reviewed> <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1918> | 18:37 |
| oparoz_ | jdstrand, https://paste.ubuntu.com/23256723/ | 18:38 |
| jdstrand | oparoz_: that is too old | 18:38 |
| oparoz_ | jdstrand, neither apt, nor snap are giving me anything newer | 18:39 |
| jdstrand | oparoz_: I suggest using 'snap refresh ubuntu-core --channel=edge' | 18:39 |
| jdstrand | I don't upload the core snaps so I don't know why you a newer stable version of the armhf core snap is not available | 18:40 |
| jdstrand | but getting the edge core snap should resolve this | 18:40 |
| mup | PR snapd#2045 closed: many: remove all traces of the /v2/buy/methods endpoint <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2045> | 18:40 |
| oparoz_ | Thanks jdstrand I'm downloading now and will keep you posted | 18:41 |
| oparoz_ | jdstrand, It seems it's stuck, error: cannot refresh "ubuntu-core": snap "ubuntu-core" has changes in progress | 18:44 |
| oparoz_ | jdstrand, any way to restart? | 18:44 |
| jdstrand | I'm not sure how to get you out of that situation. perhaps there was something wrong with it which is why it wasn't refreshing | 18:45 |
| jdstrand | perhaps someone here can help? | 18:45 |
| oparoz_ | jdstrand, It started and I killed it and now I can't refresh... | 18:46 |
| jdstrand | yeah, I don't know how to fix that. I think it will try again in some minutes behind the scenes | 18:46 |
| oparoz_ | OK :) | 18:46 |
| jdstrand | your image is definitely too old and perhaps it isn't able to update. just a guess | 18:47 |
| oparoz_ | abort seemed to have solved it | 18:47 |
| oparoz_ | But I can't connect and retrieve the snap. Connection reset by peer. Weird | 18:49 |
| Croepha | whats the service that setups networking interactively on core? how do you disable/override it? | 18:50 |
| zyga | oparoz_: killing snapd wont change anything | 18:52 |
| zyga | oparoz_: start with snap changes | 18:52 |
| oparoz_ | I did that and it gave me a list of errors and I used the ids | 18:52 |
| oparoz_ | It complained that there was nothing to do and then it worked | 18:52 |
| zyga | oparoz_: you can abort changes | 18:57 |
| oparoz_ | error: cannot abort change 78 with nothing pending | 18:58 |
| Croepha | the answer to my questions was apparently console-conf | 18:58 |
| oparoz_ | 78 Error 2016-09-30T18:40:05Z 2016-09-30T18:45:10Z Refresh "ubuntu-core" snap from "edge" channel | 18:58 |
| oparoz_ | And this one is stuck in abort: 91 Abort 2016-09-30T18:54:26Z - Refresh "ubuntu-core" snap from "edge" channel | 18:59 |
| mup | PR snapcraft#842 closed: Catkin plugin: Support ROS Kinetic <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/842> | 18:59 |
| kyrofa | oparoz_, more info here on what happened there: http://askubuntu.com/a/790975/261753 | 19:00 |
| oparoz_ | Thanks kyrofa :) | 19:01 |
| mup | Bug #1629423 opened: Ordering of command line arguments matters <Snappy:New> <https://launchpad.net/bugs/1629423> | 19:02 |
| oparoz_ | Rebooted and network is still flaky as hell. Impossible to download anything anymore :S | 19:05 |
| oparoz_ | What I find amazing is that older snaps still load, it's just newer ones which can't | 19:07 |
| mup | Bug #1629425 opened: Cannot safely refresh from edge to stable with ubuntu-core <Snappy:New> <https://launchpad.net/bugs/1629425> | 19:08 |
| oparoz_ | Is there a way to download ubuntu-core edge via wget? Snapd just can't handle network connections anymore | 19:14 |
| kyrofa | attente, ping | 19:16 |
| attente | kyrofa: hey | 19:17 |
| kyrofa | attente, hey, I just had a bug logged against nextcloud saying that the description within the software center is terribly unclear. They provided this screenshot: https://cloud.githubusercontent.com/assets/9272078/19003640/131490a4-8752-11e6-80f0-2d811abcf244.png | 19:18 |
| kyrofa | attente, there more data in the store though. Does the software center not have access to that? | 19:18 |
| kyrofa | attente, it also looks like it's grabbing the name out of the YAML or something instead of what's in the store | 19:20 |
| attente | kyrofa: hmm... i can't even seem to find that snap via gnome-software | 19:21 |
| kyrofa | attente, I guess specificaly I'm missing the summary | 19:21 |
| kyrofa | attente, huh, yeah, I don't either. What's happening here? | 19:22 |
| attente | kyrofa: can you kill gnome-software and re-run it with GNOME_SOFTWARE_SNAPPY=debug in the env? | 19:23 |
| kyrofa | attente, huh, lots of 404s | 19:25 |
| attente | kyrofa: yeah, that's what i'm seeing too | 19:26 |
| kyrofa | Temporary store failure? | 19:27 |
| attente | kyrofa: fwiw, this is from the find endpoint: http://paste.debian.net/848827/ | 19:28 |
| kyrofa | attente, huh, okay. Really just adding the summary in there would make me happy | 19:29 |
| kyrofa | attente, is there a reason we're not showing it? | 19:29 |
| Croepha | HAHA! | 19:30 |
| attente | kyrofa: the extra missing data is coming from /v2/snaps/nextcloud usually? and since it's 404'ing that's why the information is so sparse? | 19:30 |
| slangasek | ogra_: hey, so, are you planning to grab any timing of a full console-conf startup on BBB? (+strace) | 19:30 |
| Croepha | PRO TIP #2: if you want the first-boot helper to go away in core, just touch /var/lib/console-conf/complete | 19:30 |
| kyrofa | attente, no, the summary is in the response to the query you just pasted | 19:31 |
| attente | kyrofa: but you said that the store is showing more information in the store | 19:31 |
| attente | kyrofa: so i'm wondering if that's because gnome-software is getting a 404 there | 19:32 |
| kyrofa | attente, I meant to simply say that there is information available that isn't shown in gnome-software | 19:32 |
| kyrofa | Well, that's just not making it show up at all! Haha | 19:32 |
| kyrofa | It must have been working a few minutes ago when the bug was logged | 19:33 |
| kyrofa | (that screenshot was from the bug, not me personally) | 19:33 |
| kyrofa | attente, compare the screenshot to this: http://pasteboard.co/9qPYYft9h.png | 19:34 |
| attente | weird. is a server down or something? | 19:34 |
| kyrofa | There it has a summary above the install, and the longer description below | 19:34 |
| kyrofa | Good question. oparoz_ was just complaining about network issues | 19:34 |
| kyrofa | I'm installing nextcloud... that seems to be working anyway | 19:35 |
| oparoz_ | I can't download anything via snap on armhf, works on amd64 | 19:35 |
| oparoz_ | Same network, but different cable ;) | 19:35 |
| mup | PR snapd#2049 closed: interfaces: builtin: Allow writing DHCP lease files to /run/NetworkManager/dhcp <Created by ssweeny> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2049> | 19:35 |
| oparoz_ | https://uappexplorer.com still shows decriptions, so must not be an API thing | 19:42 |
| elopio | kyrofa: well, it starts now alright: https://gist.github.com/elopio/dffcda326f5b51feedeb09f012ac9a44 | 19:43 |
| elopio | it fails when trying to create a user though | 19:43 |
| attente | kyrofa: ok, i see. so you'd prefer the summary go in the top line, and description to be the blurb below | 19:48 |
| kyrofa | attente, well, the summary isn't shown at all, right? Wouldn't that be more consistent? | 19:48 |
| attente | in the second image, there are three items, name, summary and description, but from the bug report, we show the name and description (which is displayed where the summary would ideally be) | 19:49 |
| kyrofa | Indeed | 19:50 |
| attente | ok, that should be a simple fix | 19:51 |
| attente | still not sure about the 404s though :/ | 19:52 |
| kyrofa | attente, yeah me neither. But yeah, do you think that makes sense? | 20:02 |
| attente | kyrofa: yup, makes sense to me | 20:04 |
| oparoz_ | Is the API serving snaps documented somewhere? | 20:06 |
| attente | kyrofa: i'm not sure what to do about the jhbuild plugin stuff. do you think it's still worth looking into even though you're planning to make all plugins build in a container | 20:08 |
| kyrofa | attente, I'm honestly not sure. I just got back onto snapcraft yesterday, still getting up to speed. Probably a better question for sergiusens | 20:09 |
| kyrofa | oparoz_, nessita can probably help you with that. I think it's on the wiki somewhere | 20:10 |
| oparoz_ | Thanks kyrofa I'm trying to find a link I saw about creating our own app store as that may have some info | 20:11 |
| kyrofa | attente, shall I log a bug about the summary? | 20:11 |
| attente | kyrofa: sure | 20:11 |
| === cosmo_ is now known as cos- | ||
| kyrofa | attente, here? https://bugs.launchpad.net/ubuntu/+source/gnome-software | 20:12 |
| attente | kyrofa: yup | 20:13 |
| kyrofa | attente, bug #1629456 | 20:16 |
| mup | Bug #1629456: Summary isn't shown for snaps <gnome-software (Ubuntu):New> <https://launchpad.net/bugs/1629456> | 20:16 |
| attente | kyrofa: thanks! | 20:17 |
| nessita | kyrofa, hi! what do you need? | 20:19 |
| kyrofa | nessita, where is the store API documented nowadays? oparoz_ was asking | 20:19 |
| oparoz_ | Found this: https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex | 20:20 |
| nessita | oparoz_, hi! that documentation is for the click endpoints only, is not updated to snaps | 20:20 |
| nessita | oparoz_, what's your goal? | 20:20 |
| oparoz_ | Ah :( | 20:20 |
| oparoz_ | I want to download armhf package from an amd64 machine | 20:20 |
| nessita | oparoz_, we don't officially provide public APIs to query the store, ideally you should use snapd to do searches and downloads | 20:21 |
| oparoz_ | There is no arch switch in snappy | 20:21 |
| oparoz_ | snapd doesn't work | 20:21 |
| oparoz_ | I only get this: error: read tcp 1.2.3.4:60014->95.172.71.39:443: read: connection reset by peer | 20:22 |
| zyga | oparoz_: you can use snapd-glib to query snapd | 20:22 |
| lutostag | hey all, when I try to push a snap I get "There has been a problem while analyzing the snap, check the snap and try to push again."... how can I find out what I am doing wrong? | 20:23 |
| zyga | jdstrand: can I get a +1 on https://github.com/snapcore/snap-confine/pull/158 | 20:24 |
| mup | PR snap-confine#158: Constrain SNAP_CONFINE_DEBUG values <Created by zyga> <https://github.com/snapcore/snap-confine/pull/158> | 20:24 |
| oparoz_ | Thanks zyga, that's interesting | 20:26 |
| zyga | jdstrand: and perhaps https://github.com/snapcore/snap-confine/pull/157 | 20:26 |
| mup | PR snap-confine#157: Add support for --version switch <Created by zyga> <https://github.com/snapcore/snap-confine/pull/157> | 20:26 |
| jdstrand | zyga: I feel like I looked at this alreayd | 20:27 |
| zyga | jdstrand: oh? I don't see any comments there | 20:27 |
| jdstrand | no there aren't any | 20:27 |
| jdstrand | maybe I started looking at it | 20:28 |
| jdstrand | I'm looking at something else right now and have a hard stop soon | 20:28 |
| zyga | jdstrand: I wrote a small spread test for the "prefer core" https://github.com/snapcore/snap-confine/pull/161/commits/3e4d839da5efb8e34b5a72a45445abd404d8a627 | 20:28 |
| mup | PR snap-confine#161: Prefer the "core" snap is one is available <Created by zyga> <https://github.com/snapcore/snap-confine/pull/161> | 20:28 |
| zyga | jdstrand: ok, ignore those two | 20:28 |
| jdstrand | I've added it to me todo | 20:28 |
| zyga | hmm, me is silly | 20:28 |
| jdstrand | jeez, I thought I looked at --verson too | 20:28 |
| jdstrand | meh | 20:29 |
| zyga | jdstrand: I'm doing a micro release with the core preference feature | 20:35 |
| mup | PR snapcraft#843 closed: Add `snapcraft history` and `snapcraft status` <Created by maxiberta> <Closed by maxiberta> <https://github.com/snapcore/snapcraft/pull/843> | 20:36 |
| mup | PR snapcraft#844 opened: Add `snapcraft history` <Created by maxiberta> <https://github.com/snapcore/snapcraft/pull/844> | 20:36 |
| mup | PR snapcraft#845 opened: Add `snapcraft status` <Created by maxiberta> <https://github.com/snapcore/snapcraft/pull/845> | 20:36 |
| lutostag | (figured it out, someone else had registered the name I tried to push to, but got it sorted) | 20:38 |
| mup | PR snapcraft#841 closed: Replace SNAPCRAFT_PART_INSTALL in the part attributes <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/841> | 20:39 |
| oparoz_ | jdstrand, usr.lib.snapd.snap-confine is not updated when installing ubuntu-core edge and so nothing changes | 20:42 |
| jdstrand | zyga: I gave a comment on 161 you may want to consider | 20:43 |
| jdstrand | oparoz_: I am about to head out. does usr.lib.snapd.snap-confine contain 'unsafe' in the change_profile rules? | 20:44 |
| zyga | jdstrand: looking | 20:44 |
| oparoz_ | jdstrand, no | 20:45 |
| jdstrand | oparoz_: I suspect that /snap/ubuntu-core/current points to the old one | 20:45 |
| jdstrand | oparoz_: I don't know how convenient it is for you, but you may want to reflash. perhaps others can help debug this | 20:46 |
| oparoz_ | jdstrand, it points to the dev version I just sideloaded | 20:46 |
| jdstrand | oparoz_: what does snap list say? | 20:46 |
| zyga | jdstrand: replied | 20:46 |
| jdstrand | maybe the armhf core snap is out of date | 20:46 |
| oparoz_ | jdstrand, ubuntu-core 16.04.1 x1 - | 20:47 |
| oparoz_ | This is a Nextcloud Box image | 20:47 |
| oparoz_ | Which only had snapcraft installed on to try and build simpler snaps | 20:47 |
| oparoz_ | It used to work find until the preload bug and now all dnaps fail | 20:48 |
| oparoz_ | with that lib error | 20:48 |
| oparoz_ | snap-confine/xenial-updates,now 1.0.38-0ubuntu0.16.04.10 armhf | 20:48 |
| oparoz_ | snapd/xenial-updates,now 2.15.2ubuntu1 armhf | 20:49 |
| oparoz_ | I just hope it's recoverable, because lots of users won't be tech savvy | 20:49 |
| jdstrand | oparoz_: oh, 16.04 still has 1.0.38-0ubuntu0.16.04.10. that doesn't have the necessary changes | 20:50 |
| jdstrand | :( | 20:50 |
| oparoz_ | OK, at least now I know why :) | 20:50 |
| jdstrand | oparoz_: I know zyga was working on landing that. I'm not sure of the status | 20:50 |
| zyga | oparoz_: there's a good version in yakkety, xenial will get the SRU but I need to verify a dozen bugs for that and I'm also doing other things | 20:51 |
| zyga | oparoz_: ~ next week | 20:51 |
| oparoz_ | OK, I'll just be patient and wait for updates to land | 20:51 |
| oparoz_ | Thank you guys | 20:51 |
| sbeattie | How does one get snapcraft to include datadirs in a snap? the autotools plugin installed them into stage/SNAP/installdata, but I can't figure out how to get the stuff under there included in the snap. | 20:52 |
| sbeattie | If I try to use the "stage" part (from http://snapcraft.io/docs/build-snaps/parts) , it looks under stage/SNAP/install/ | 20:54 |
| zyga | jdstrand: my browser froze and I think I just accidentally somehow removed your commend about /media and udisks | 21:02 |
| zyga | jdstrand: my point on this is, perhaps, but it would make devmode vs non-devmode different | 21:02 |
| zyga | in somewhat weird ways | 21:02 |
| oparoz_ | zyga, just to confirm that that yaketi package fixes the problem. The error about the lib is still there but it seems it was a red herring | 21:02 |
| zyga | (well, to phrase this better, right now all you need is devmode and then you can "be udisks" | 21:02 |
| zyga | oh the comment is back, odd | 21:03 |
| zyga | oparoz_: intersting | 21:03 |
| zyga | oparoz_: I'm away from home and my fleet of arm devices | 21:03 |
| zyga | oparoz_: I will be able to look at this in early november | 21:03 |
| oparoz_ | zyga, OK. Hopefully fixed by Ubucon EU | 21:04 |
| zyga | oparoz_: I'm sure we'll get someone with a device to debug it | 21:05 |
| oparoz_ | :) | 21:05 |
| Innokentiy | Hello! Have some questions about using snappy for packaging an application ... Unfortunately can't find answers in tutorial and FAQ | 21:07 |
| zyga | Innokentiy: ask away | 21:09 |
| Innokentiy | Tnx! | 21:11 |
| Innokentiy | I use odroid and beaglebone for about 4 years now, and recently found that Ubuntu core may be an answer to a question what Linux distribution is the best for the IoT, so the question is: :) | 21:12 |
| Innokentiy | naturally it is a set of php scripts ... not a real application ... | 21:14 |
| kyrofa | Innokentiy, no matter, you can run PHP scripts. Is it not a web application, though? | 21:15 |
| sergiusens | attente kyrofa can we take the jhbuild plugin to the sprint? | 21:17 |
| zyga | Innokentiy: this is not a question yet | 21:17 |
| kyrofa | sergiusens, sounds good to me | 21:18 |
| attente | sergiusens: sure | 21:18 |
| sbeattie | sorry, I mis-asked. the snapcraft autotools plugin is installing my snap's data into parts/SNAP/installdata rather than parts/SNAP/install (where it correctly installs the bins). How do I get snapcraft to look at the parts/SNAP/installdata dirs as well? | 21:18 |
| Innokentiy | Something went wrong, looks like messages gone nowhere ... | 21:23 |
| Innokentiy | So i continue ... | 21:23 |
| zyga | Innokentiy: try again :) | 21:23 |
| Innokentiy | Tnx zyga :) | 21:24 |
| Innokentiy | my project is a set of php scrips, so i have one fundamental question ... | 21:24 |
| Innokentiy | Normally, i place all folder structure to /var/www/mpsbox | 21:25 |
| Innokentiy | and then point apache to use this folder as virtual directory | 21:26 |
| Innokentiy | or main site folder ... | 21:26 |
| zyga | right, here you'd want to bundle PHP and use apache (or anything else that runs php apps) | 21:26 |
| zyga | your snap will be installed in a directory that is variable at runtime | 21:26 |
| zyga | but you can find it because it is in environment under the $SNAP name | 21:27 |
| Innokentiy | what should i do when i want to install with snappy? | 21:27 |
| mup | PR snapd#2037 closed: asserts,interfaces/builtin,overlord/assertstate: introduce base-declaration <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2037> | 21:27 |
| zyga | e.g. typically /that would be /snap/yoursnapname/123/ | 21:27 |
| Innokentiy | right | 21:27 |
| zyga | start with a snap (use snapcraft) that can bundle apache2 | 21:27 |
| Innokentiy | and then i will pint apache to this folder | 21:27 |
| zyga | you will need the "network-bind" plug for the application that runs apache | 21:27 |
| zyga | the script you start can alter apache config to point it to the right place | 21:28 |
| zyga | note that you will have to fiddle with apache first | 21:28 |
| zyga | to make it relocatable (might be trivial, might be hard, not sure) | 21:28 |
| zyga | then adding PHP | 21:29 |
| zyga | then adding your app | 21:29 |
| zyga | I think it should be doable but I'm not a php expert | 21:29 |
| Innokentiy | thanks, and how i can define dependances? | 21:29 |
| zyga | (where anything is doable, I mean easily) | 21:29 |
| zyga | Innokentiy: you want to read about how snapcraft works | 21:29 |
| Innokentiy | i need apache snmp mysql and php ... | 21:30 |
| zyga | Innokentiy: there are no dependencies among snaps but you can easily bundle lots of things into one snap | 21:30 |
| zyga | oh, mysql might be another thing you will neee extra time on | 21:30 |
| zyga | I would recommend asking on the mainling list, this seems like something a lot of people can reuse | 21:30 |
| Innokentiy | that what i missed out ... i went through tutorial | 21:30 |
| kyrofa | Innokentiy, the nextcloud snap uses apache mysql and php as well, might be useful for reference: https://github.com/nextcloud/nextcloud-snap | 21:30 |
| Innokentiy | but didn't get how to manage those things :( | 21:31 |
| sbeattie | Also, is there a way to clean just a specific stage of the snapcraft process? I don't want to redo the entire build if I can avoid it. | 21:31 |
| kyrofa | sbeattie, you can `snapcraft clean <part name>` and `snapcraft clean --step=<step>`. You can combine those, too: `snapcraft clean <part name> --step=<step>` | 21:31 |
| Innokentiy | Thanks kyrofa will check it ... | 21:32 |
| zyga | Innokentiy: in the end your snap will bundle apache, mysql, php and anything else you need | 21:32 |
| Innokentiy | zyga - yes that the point, ultimately i just want to automate the installation i do now manually ... | 21:32 |
| zyga | Innokentiy: in the end the snap will be totally self-contained | 21:33 |
| zyga | Innokentiy: and you will have total control over versions of each bit inside | 21:33 |
| sbeattie | kyrofa: thanks. do you have any idea how I can get snapcraft to include the files the autotools plugin installed in parts/SNAP/installdata along with the bins it installed in parts/SNAP/install ? | 21:34 |
| Innokentiy | I really confident on make my stuff bundled as snap, as today, i getting questions mainly how to set everything up :) | 21:34 |
| kyrofa | sbeattie, can I see your YAML? | 21:34 |
| Innokentiy | on a device like odroid or beagle or raspberry :) | 21:35 |
| sbeattie | kyrofa: it's pretty dirt simple: http://paste.ubuntu.com/23257449/ | 21:38 |
| Innokentiy | kyrofa - why you decide to compile everything in snap, and not use packages available in ubuntu? | 21:38 |
| sbeattie | I tried adding a 'source' section to part, but snapcraft looked under parts/SNAP/install/ | 21:38 |
| kyrofa | Innokentiy, this series of blog posts might be a good read, and will answer questions like that: https://kyrofa.com/posts/installing-nextcloud-can-be-a-snap | 21:39 |
| kyrofa | sbeattie, I'm not sure what's going on there, but I suspect the way your project is handling DESTDIR is odd | 21:41 |
| kyrofa | sbeattie, try adding `install-via: prefix` to your autotools part | 21:41 |
| sbeattie | kyrofa: this is how it ended up installing things: http://paste.ubuntu.com/23257470/ | 21:42 |
| sbeattie | kyrofa: I'll give that a go. | 21:42 |
| kyrofa | sbeattie, yeah it might be using ${DESTDIR}data or something dumb like that | 21:42 |
| Innokentiy | kyrofa: Thanks! Already dive in to reading :) | 21:46 |
| CoderEurope | o/ | 21:59 |
| CoderEurope | bbl | 21:59 |
| mup | PR snapcraft#846 opened: Release changelog for 2.19 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/846> | 22:00 |
| Innokentiy | Guys, thanks for help! | 22:19 |
| ogra_ | slangasek, i'll dig on the weekend | 23:01 |
| ogra_ | slangasek, thats not bbb specific ... pi2/3 also take very long | 23:02 |
| tsimonq2 | /or | 23:02 |
| tsimonq2 | whoops | 23:02 |
| slangasek | ogra_: ok. and they still do, after the bytecompile fix? | 23:03 |
| ogra_ | yep | 23:03 |
| slangasek | ogra_: ok. I don't think I have any of those devices here, so strace welcome | 23:03 |
| ogra_ | slangasek, well, was there another fix ? you mentioned subiquity would be missing its .pyc files too | 23:03 |
| slangasek | subiquity's should be insignificant, but maybe a full strace will tell us something more | 23:04 |
| ogra_ | yeah, michael also asked for setting some SNAPD_HTTP_* debug var ... | 23:04 |
| ogra_ | (i have to dig that up ... not at 1am though :) ) | 23:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
