| === chihchun_afk is now known as chihchun | ||
| === JanC_ is now known as JanC | ||
| === cpaelzer_ is now known as cpaelzer | ||
| zyga | Chipaca: good morning | 07:01 |
|---|---|---|
| Chipaca | zyga: morning | 07:01 |
| zyga | Chipaca: I'm seeing this error all the time: | 07:03 |
| zyga | src/github.com/snapcore/snapd/vendor/golang.org/x/crypto/ssh/test/test_unix_test.go:25:2: cannot find package "golang.org/x/crypto/ssh/testdata" in any of: | 07:03 |
| zyga | does it ring any bells? anything changed in how we vendor stuff? | 07:03 |
| Chipaca | zyga: i have never seen it before | 07:04 |
| morphis | zyga: I've seen this once in a fedora build where we missed to copy testdata into place | 07:04 |
| morphis | but actually that was for one of our packages not the ssh one | 07:05 |
| zyga | Chipaca: ok, separate topic, I asked mvo how we might go ahead with storing more data into sequence but he didn't reply; I was thinking about storing a 2nd sequence like object | 07:05 |
| zyga | hey morphis :) | 07:05 |
| morphis | zyga: hey! | 07:05 |
| zyga | Chipaca: so that we can get away without patching anything in the state | 07:05 |
| zyga | Chipaca: so sequence-ex could store more stuff (flags, path, side info) | 07:05 |
| zyga | Chipaca: wdyt? | 07:05 |
| Chipaca | zyga: type SuperInfo struct { *SideInfo } | 07:06 |
| morphis | zyga: do you have time for another review on https://github.com/snapcore/snapd/pull/3222 ? | 07:06 |
| mup | PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222> | 07:06 |
| zyga | morphis: yes, I'll focus on reviews today (again) | 07:06 |
| zyga | morphis: I was off yesterday (despite being here a little) | 07:06 |
| zyga | Chipaca: super info I like | 07:07 |
| Chipaca | zyga: and make Sequence be []SuperInfo (or []*SuperInfo) | 07:07 |
| zyga | Chipaca: hmm | 07:07 |
| zyga | Chipaca: though | 07:07 |
| zyga | maybe not sure, we risk clashing fields | 07:07 |
| zyga | Chipaca: why not just sequence-ex with dedicated fields? | 07:07 |
| zyga | (we can clean up when patches are live) | 07:07 |
| Chipaca | zyga: because then you have to keep to slices in sync? | 07:08 |
| zyga | yes | 07:08 |
| Chipaca | zyga: and decide how to handle drift | 07:08 |
| zyga | I planned to already | 07:08 |
| zyga | hmm | 07:08 |
| zyga | in case of rollbacks? | 07:09 |
| morphis | zyga: thanks | 07:09 |
| zyga | well, this is already equally hard, there is no required data currently, we'd have to add the data only to the new sequence | 07:09 |
| zyga | and this is only for snap try, it is still broken today in master (from this pov) so it'd not be a regression | 07:09 |
| Chipaca | zyga: i mean, what's the advantage of having a second sequence instead of adding to the existing? | 07:09 |
| Chipaca | zyga: you're seeing something there that I am not | 07:10 |
| zyga | Chipaca: the advantage is that the second sequence would not embed a go type so it cannot clash on field names there; | 07:10 |
| Chipaca | zyga: we could even add SnapPath to SideInfo | 07:10 |
| Chipaca | ogra_: ping? | 07:12 |
| zyga | Chipaca: hmm hmm | 07:12 |
| zyga | Chipaca: the problem is that we may need more than just snap path | 07:12 |
| zyga | Chipaca: what I think we need to capture in this particular case is the fact that it was on encrypted directory | 07:12 |
| zyga | Chipaca: more so than the fact than the actual path (which I would capture anyway) | 07:12 |
| Chipaca | zyga: it being on an encrypted directory is something that should be detected at runtime, fwiw | 07:13 |
| zyga | Chipaca: no, because it may not even be mounted :/ | 07:14 |
| Chipaca | ok, wait | 07:14 |
| Chipaca | if it's not mounted, why do you need to know if it's encrypted? | 07:14 |
| zyga | Chipaca: have a look at the discussion here https://github.com/snapcore/snapd/pull/2837#discussion_r114855843 | 07:14 |
| mup | PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837> | 07:14 |
| zyga | Chipaca: because it was encrypted when the user is logged in | 07:14 |
| zyga | Chipaca: then she logs out | 07:14 |
| zyga | Chipaca: and snapd restarts | 07:14 |
| zyga | Chipaca: and needs to write the apparmor policy | 07:14 |
| zyga | Chipaca: :/ | 07:15 |
| Chipaca | zyga: brb | 07:15 |
| zyga | no worries, I wanted to let you know about this to get you thinking | 07:15 |
| zyga | I'll try to fix it today but I want to agree on direction | 07:15 |
| * zyga -> breakfast | 07:16 | |
| Chipaca | zyga: if the directory of a snap try goes away, the snap is removed | 07:20 |
| Chipaca | zyga: several rough edges here though | 07:28 |
| Chipaca | zyga: one is: if you snap install foo, and then snap try ./foo, you end up with a foo from the store and a foo from try. We don't handle this case well today at all (the whole snap is in "try mode") | 07:29 |
| Chipaca | zyga: and the question is, if the directory goes away in this case, what should happen? should it fall back to the non-try one? | 07:29 |
| Chipaca | i'd suggest we solve this by not allowing mixing try and non-try, at least for now | 07:30 |
| Chipaca | (any mixing of try and non-try can be made explicit with flags, later, where we don't mix them in state but copy config over or whatever) | 07:31 |
| Chipaca | this avoids all the uncomfortable corner cases of mixing the two modes | 07:31 |
| Chipaca | and makes the current approach of having 'trymode' on the snap (instead of the sequence) fine | 07:32 |
| Chipaca | and gives us an easy approach to getting the snap path, whichi is to add it next to trymode | 07:32 |
| Chipaca | the 'patch' code can look in changes for the snapsetup, or at the mount unit | 07:32 |
| Chipaca | (or we could look at the mount unit in runtime, but that feels 15.04ish :-) ) | 07:33 |
| Chipaca | zyga: i'm creating a forum topic about this | 07:40 |
| Chipaca | zyga: https://forum.snapcraft.io/t/disallow-mixing-try-and-non-try-snap-installs/484 | 07:50 |
| ogra_ | Chipaca, yes ? | 08:02 |
| Chipaca | ogra_: two questions for you sah | 08:02 |
| Chipaca | ogra_: we nuke locale support from core, yes? | 08:02 |
| Chipaca | or have we added it back recently | 08:02 |
| Chipaca | ogra_: (good morning! how're you doing today?) | 08:03 |
| ogra_ | Chipaca, nope, actually locale support was nuked everywhere now (ubuntu-base, cloud images etc) | 08:03 |
| Chipaca | ogra_: ok. 2nd question, what is the locale-control interface for, do you know? | 08:04 |
| ogra_ | i guess nothing ... but since we never shipped locales thats fine i guess | 08:05 |
| ogra_ | (thank you i'm fine :) ) | 08:05 |
| Chipaca | ogra_: i mean, we even have a snap to test it works | 08:05 |
| ogra_ | not on core | 08:05 |
| zyga | Chipaca: thank you! | 08:05 |
| ogra_ | we never did to my knowledge | 08:06 |
| Chipaca | so /etc/default/locale is from "outside", on classic? | 08:06 |
| ogra_ | thats a zyga question, not sure if snap-confine mounts it | 08:06 |
| Chipaca | zyga: ^ :-) | 08:07 |
| Chipaca | ogra_: by the way, it looks like core is currently shipping the locales for e2fsprogs | 08:08 |
| Chipaca | ogra_: i assume that's a bug | 08:08 |
| ogra_ | hmm, i wonder how they get there | 08:09 |
| ogra_ | yes | 08:09 |
| zyga | Chipaca: replied on the forum | 08:10 |
| ogra_ | seems fwupdate too | 08:10 |
| zyga | Chipaca: mmm, /etc/default/locale is from classic | 08:10 |
| Chipaca | zyga: ok, good | 08:10 |
| Chipaca | ogra_: and is /etc/default/locale writable in core? | 08:10 |
| zyga | Chipaca: but also (this is an ogra topic :) on core we do some writable path magic I'm not fully versed in | 08:10 |
| * ogra_ hopes /usr/share/locale too | 08:10 | |
| ogra_ | Chipaca, i dont think so ... it should be hardcoded to C.UTF-8 | 08:11 |
| * ogra_ checks | 08:11 | |
| ogra_ | ogra@pi3:~$ mount |grep locale | 08:11 |
| ogra_ | ogra@pi3:~$ cat /etc/default/locale | 08:11 |
| ogra_ | LANG="C.UTF-8" | 08:11 |
| ogra_ | yep | 08:11 |
| Chipaca | if the idea of locale-control is to not work at all on core, we should probably check for that | 08:11 |
| Chipaca | ogra_: and non-writable? | 08:11 |
| ogra_ | see the mount :) | 08:11 |
| ogra_ | (yes, non-writable) | 08:11 |
| Chipaca | ah :-) | 08:12 |
| Chipaca | ok | 08:12 |
| ogra_ | doesnt mean that wont change in case we get langpack snapsd or some such indeed | 08:12 |
| ogra_ | *snaps | 08:12 |
| Chipaca | I'm pretty sure locale-control needs fixing to work on !debianish | 08:13 |
| Chipaca | morphis ^ | 08:13 |
| ogra_ | i'm pretty sure they dont have /etc/default on non-debian | 08:14 |
| zyga | Chipaca: I think the whole /etc design is broken today | 08:15 |
| zyga | Chipaca: we want to entirely stop sharing /etc | 08:15 |
| zyga | Chipaca: and share (or mirror) selective elements | 08:15 |
| Chipaca | all these locale questions are because of https://askubuntu.com/q/910514/711 btw | 08:15 |
| morphis | Chipaca: locale-control happy isn't "broken" on any !debian system today as we don't have confinement anywhere .. | 08:17 |
| Chipaca | morphis: it's broken in that it doesn't do what's intended | 08:17 |
| Chipaca | i.e. it doesn't change the default locale of the system | 08:17 |
| morphis | Chipaca: doesn't it just allow access to /etc/default/locale via AppArmor? | 08:17 |
| Chipaca | morphis: yes | 08:18 |
| Chipaca | exactly | 08:18 |
| Chipaca | that is not a thing in !debian, afaik | 08:18 |
| morphis | sure | 08:18 |
| morphis | but we don't have any AppARmor on anything else than Ubuntu today | 08:18 |
| Chipaca | ah, now i gotcha | 08:18 |
| Chipaca | ok | 08:18 |
| morphis | if we get AppArmor anywhere else I think we can easily add the right paths to the AppARmor snippet | 08:18 |
| ogra_ | you can ship translations inside your snap and use them (not sure if the content interface would work here but i guess with the correct env set in your wrapper it should) | 08:19 |
| ogra_ | there are env variables for this | 08:20 |
| AdamH_ | Hello, is there a work around available for the problems with apt-get update on an arm board when running in classic snap on Ubuntu core? | 08:37 |
| zyga | Chipaca: so quick question about try, is that the current design that if the directory goes away try mode snap should uninstall itself? | 08:39 |
| zyga | AdamH_: hey, do you have some more details about the issue? | 08:39 |
| AdamH_ | zyga: This is the bug I am experiencing https://bugs.launchpad.net/snappy/+bug/1670475 | 08:40 |
| mup | Bug #1670475: apt-secure complaints with classic snap on arm <Snappy:New> <https://launchpad.net/bugs/1670475> | 08:40 |
| zyga | ogra_: ^ I had a look at the bug but I don't know anything about it | 08:42 |
| zyga | ogra_: do you know what the root cause is? | 08:42 |
| zyga | ogra_: ports vs non-ports archive? | 08:42 |
| ogra_ | zyga, something with gnupg, i'm still not sure what ... has nothing to do with any archive servers, thats a local issue with the classic snap | 08:43 |
| zyga | ogra_: any idea why it is specific to arm? | 08:43 |
| zyga | ogra_: could it be some version of gpg that we've seeded into the images due to snappy? | 08:44 |
| zyga | ogra_: gnupg 1 vs 2 | 08:44 |
| ogra_ | zyga, that would be odd, i rather thing we remove to much when wrapping up the tarball for core | 08:45 |
| ogra_ | *think | 08:45 |
| zyga | AdamH_: so there you go, I don't know anything more | 08:47 |
| * zyga reviews https://github.com/snapcore/snapd/pull/3222/files | 08:47 | |
| mup | PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222> | 08:47 |
| AdamH_ | zyga: Thank you | 08:48 |
| ogra_ | AdamH_, the "workaround" is described in the bug though ... (turn off gpg checking) | 08:49 |
| * ogra_ glares at the first line of https://forum.snapcraft.io/t/failed-to-flush-stdout-permission-denied/485 and tries to wrap his head around that command | 08:50 | |
| ogra_ | wondering if he made a typo there or if there is actually a snap that calls apt install | 08:50 |
| Chipaca | zyga: I thought it was, but it isn't | 08:50 |
| Chipaca | zyga: (the current behaviour for snapd to remove a try that vanished) | 08:51 |
| Chipaca | it goes into broken state | 08:51 |
| AdamH_ | zyga: Yes I tried sudo apt-get --allow-unauthenticated upgrade but still get the same error? Is there a better way to disable the check? | 08:52 |
| ogra_ | AdamH_, upgrade ? you mean update, right ? | 08:53 |
| AdamH_ | ogra: Yes sorry I mean update | 08:53 |
| ogra_ | heh, k :) | 08:53 |
| ogra_ | likewise you should be fine just typing Y on the question about unauthenticated packages | 08:54 |
| pachulo | yes kyrofa ! I'm looking at this: https://github.com/nextcloud/nextcloud-snap/issues/60 and was trying to compile the nextcloud-snap for my rbpi3, after hitting the out of RAM issue when compiling mysql I found out your post (https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way) but I the 3 builds I tried all failed: | 08:59 |
| pachulo | https://launchpadlibrarian.net/318427985/buildlog_snap_ubuntu_xenial_armhf_nextcloud-snap-pachulo_BUILDING.txt.gz | 08:59 |
| AdamH_ | ogra: I don't get a prompt when trying to update, only when I am installing a package | 08:59 |
| ogra_ | AdamH_, yeah, thats what i mean | 08:59 |
| ogra_ | it should install afterwards | 09:00 |
| AdamH_ | ogra: Yes it does | 09:00 |
| Chipaca | pachulo: I think it's about 2am for kyrofa; try in a few more hours | 09:14 |
| Chipaca | zyga: where does the decision to include or not include (say) unity7 in the core snap come from? | 09:17 |
| Chipaca | jdstrand: when you're around, i'd like to look at the issue of _filedir | 09:19 |
| zyga | Chipaca: in snap/implicit.go | 09:23 |
| Chipaca | aha, no wonder i couldn't find it in interfaces :-) | 09:24 |
| Chipaca | zyga: I think locale-control needs to move to implicitClassicSlots | 09:24 |
| pachulo | thanks Chipaca ! | 09:24 |
| Chipaca | zyga: ogra_: right? | 09:24 |
| mup | PR snapd#3274 opened: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274> | 09:25 |
| zyga | Chipaca: I think some commercial products use that slot but if you guys say it does nothing on core we need to re-visit thi | 09:25 |
| morphis | Chipaca: if you move it somebody should query the store to see if there are any snaps which use that interface already | 09:26 |
| Chipaca | morphis: zyga: I can confirm that if a snap does use that interface, attempting to actually modify the locale fails | 09:29 |
| Chipaca | in core | 09:29 |
| morphis | Chipaca: yeah, however we need to ensure we don't break existing snaps which are installed on a core system today and use that interface | 09:31 |
| Chipaca | morphis: yep | 09:32 |
| morphis | Chipaca: if snapd handles that already nicely, then I am fine | 09:32 |
| Chipaca | sadly answering that question is harder than it should | 09:32 |
| Chipaca | cannot create lock directory /run/snapd/lock: Permission denied | 09:38 |
| Chipaca | pstolowski: ^ halp? | 09:38 |
| ogra_ | Chipaca, yeah, i guess locale-control being classic only is fine | 09:38 |
| Chipaca | pstolowski: suspect version mismash but i don't know of what :-) | 09:39 |
| morphis | zyga: you got "cannot find package "golang.org/x/crypto/ssh/testdata"" fixed? | 09:40 |
| morphis | seeing that on travis now | 09:40 |
| pstolowski | Chipaca, where do you see that? | 09:41 |
| Chipaca | pstolowski: when trying to run any app | 09:41 |
| Chipaca | pstolowski: but i might have snap-confine from master and snapd from elsewhere | 09:41 |
| pstolowski | uh | 09:41 |
| Chipaca | so it's probably me (but please advise) | 09:42 |
| zyga | morphis: no | 09:42 |
| zyga | morphis: not sure what's going on really | 09:42 |
| pstolowski | Chipaca, how about checking the versions? dpkg -l|grep snap | 09:43 |
| zyga | Chipaca: snap-confine misalinged with profile | 09:43 |
| zyga | Chipaca: seems exactly the same what morphis ran into yesterday | 09:43 |
| Chipaca | pstolowski: i'm not running any of the things from the package at this point | 09:43 |
| zyga | Chipaca: are you playing around with development versions of snap-conifne? | 09:43 |
| Chipaca | snap-confine is from yesterday's master | 09:43 |
| Chipaca | snapd is snapd/2.24+git605.g2eda802.dirty | 09:44 |
| zyga | Chipaca: ok | 09:44 |
| zyga | Chipaca: how did you install it? | 09:44 |
| Chipaca | snap-confine? make hack | 09:44 |
| zyga | Chipaca: in general you need make hack + several bind mounts :/ | 09:44 |
| zyga | Chipaca: one for the binary into core (or disable reexec) | 09:44 |
| zyga | Chipaca: one for the apparmor profile into core | 09:44 |
| Chipaca | snapd, built it by hand and run-snapd-srv | 09:44 |
| pstolowski | ok, i'm glad zyga jumped in, because i'd never have guessed :} | 09:45 |
| Chipaca | ¯\_(ツ)_/¯ | 09:45 |
| zyga | Chipaca: the issue is that snap runs snap-confine from core and then the apparmor profile is in /etc/apparmor.d/snap.core.$number.usr.lib.snapd.snap-confine.real | 09:45 |
| zyga | Chipaca: and then that thing must match the one that was made by make hack | 09:45 |
| Chipaca | zyga: snap only runs snap-confine from core if it reexecs though | 09:45 |
| zyga | Chipaca: except for the paths (revision in core0 | 09:45 |
| Chipaca | so maybe my snap is from package | 09:45 |
| zyga | Chipaca: maybe bug? check if you have snap | 09:45 |
| Chipaca | that might explain that | 09:45 |
| zyga | Chipaca: (built from source) | 09:45 |
| zyga | Chipaca: anyway, a dumb solution is just to bind mount the apparmor profile over that in core and restart snapd | 09:46 |
| Chipaca | zyga: pstolowski: updated snap (manually) and snap-confine (make hack) fixed it | 09:48 |
| Chipaca | no bind mounts needed | 09:48 |
| zyga | morphis: https://github.com/snapcore/snapd/pull/3222#pullrequestreview-36469425 | 09:48 |
| mup | PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222> | 09:48 |
| zyga | morphis: reading rest | 09:48 |
| zyga | Chipaca: yep, this means that snap is honring reexec correctly! | 09:49 |
| mup | PR snapd#3275 opened: snap: move locale-control to only be present on classic <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/3275> | 09:52 |
| * zyga finds code review in gitk better/faster than on github | 10:12 | |
| zyga | :/ | 10:12 |
| ogra_ | trying to debug that apt issue i get the feeling it is related to how we handle /tmp | 10:15 |
| zyga | ogra_: oh? | 10:26 |
| zyga | ogra_: how do we handle /tmp on classic? | 10:26 |
| zyga | it's just the regular tmp, right? | 10:26 |
| zyga | (regular in snap execution environment) | 10:26 |
| ogra_ | we dont do anything at all | 10:26 |
| ogra_ | what i see in the logs is http://paste.ubuntu.com/24516298/ | 10:27 |
| ogra_ | see how it tiresd to use /var/snap/classic/common/classic/tmp/fileutl.message.wopbff | 10:27 |
| zyga | wow | 10:28 |
| zyga | what an insane profile! | 10:28 |
| zyga | ah wait | 10:28 |
| zyga | name="/var/snap/classic/common/classic/tmp/fileutl.message.wopbff" | 10:28 |
| zyga | so /tmp is special! | 10:28 |
| ogra_ | it is --devmode | 10:28 |
| zyga | it's a persistent /tmp in $SNAP_COMMON | 10:28 |
| ogra_ | (classic)ogra@pi3:~$ touch /tmp/foo | 10:29 |
| ogra_ | (classic)ogra@pi3:~$ | 10:29 |
| ogra_ | (in one terminal) | 10:29 |
| ogra_ | ogra@pi3:~$ ls -l /var/snap/classic/common/classic/tmp/ | 10:29 |
| ogra_ | total 0 | 10:29 |
| ogra_ | -rw-r--r-- 1 ogra ogra 0 May 5 10:28 foo | 10:29 |
| ogra_ | (in the other) | 10:29 |
| ogra_ | so it actually writes there | 10:29 |
| ogra_ | permissions and all seem fine too | 10:29 |
| ogra_ | yet, apt prints exactly that line every time it spills the gpg error | 10:30 |
| zyga | ogra_: that? | 10:31 |
| ogra_ | ? | 10:31 |
| zyga | ogra_: "that line", which line is that? | 10:32 |
| ogra_ | the one from the paste above | 10:32 |
| zyga | ogra_: what is ="/var/snap/classic/common/classic/tmp/fileutl.message.wopbff" | 10:35 |
| zyga | is that a socket? | 10:35 |
| zyga | mknod being the thing that is not normally allowed | 10:35 |
| zyga | maybe we can now allow it and use seccomp filtering | 10:35 |
| ogra_ | well, --devmode ... so it is aloowed | 10:35 |
| ogra_ | sigh .... i wish that log output would be somehow readable | 10:37 |
| zyga | ogra_: yeah | 10:37 |
| * zyga would like to understand what that profile name means | 10:37 | |
| zyga | jjohansen: ^ if you can help me out | 10:37 |
| ogra_ | these lines are way to long to even grasp them | 10:37 |
| zyga | to quote so that you don't have to hunt pastebins: | 10:37 |
| zyga | May 5 10:12:22 pi3 kernel: [ 7741.891667] audit: type=1400 audit(1493979142.467:148626): apparmor="ALLOWED" operation="mknod" | 10:37 |
| zyga | profile="snap.classic.classic//null-/usr/bin/systemd-run//null-/usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/script//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common | 10:37 |
| zyga | /classic/usr/bin/apt-get" name="/var/snap/classic/common/classic/tmp/fileutl.message.wopbff" pid=12088 comm="apt-get" requested_mask="c" denied_mask="c" fsuid=0 ouid=0 | 10:38 |
| ogra_ | well, due to the ALLOWED it should technically work | 10:38 |
| zyga | yes | 10:40 |
| zyga | it does work | 10:40 |
| zyga | whatever happens it is something else that's broekn | 10:40 |
| zyga | broken* | 10:40 |
| ogra_ | well, nothing in classic changed when it started to happen | 10:41 |
| ogra_ | it must be releated to the surrounding env | 10:41 |
| ogra_ | i see that /etc/apt/trusted.gpg is intact and contains the right keys ... i can also list them with apt-key list ... | 10:42 |
| ogra_ | gnupg (1) is also installed fine and working otherwise | 10:43 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| ogra_ | (i can also add/remove keys with apt-key just fine) | 10:44 |
| * zyga has a crazy idea | 10:46 | |
| zyga | to have a snapd that lives in an execution environment by itself | 10:46 |
| zyga | so snapd would run in a snapd namespace | 10:46 |
| zyga | that is consistent across distros more than the helper snapd outside | 10:46 |
| zyga | morphis: one more question on that PR | 10:48 |
| zyga | morphis: at the bottom | 10:48 |
| mup | PR snapd#3276 opened: tests: additional setup in docker test for core systems <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3276> | 10:48 |
| zyga | Chipaca: hey | 10:50 |
| zyga | Chipaca: back to that sequence topic | 10:50 |
| zyga | Chipaca: do you think this is something worth tackling today or better next week when gustavo can voice his opinion? | 10:51 |
| Chipaca | zyga: well, there's a bunch of work to be done. Is there any you can tackle without his input? | 10:52 |
| Chipaca | zyga: e.g. the code to grab SnapPath from existing state, for the migration | 10:52 |
| Chipaca | zyga: the code to determine whether a directory is part of an ecrypt-encrypted volume | 10:53 |
| Chipaca | not volume. Tree? path? w/e | 10:53 |
| Chipaca | zyga: i'd start there, and that's probably fiddly enough to take you over to monday | 10:54 |
| zyga | Chipaca: that is actually easy (a simple extension of what I wrote yesterday) but I think it is stuck on a design decision: of how snaps behave when a volume is not mounted | 10:54 |
| Chipaca | zyga: currently, they go to 'broken' state | 10:54 |
| zyga | Chipaca: yeah but what do we _want_ to happen? | 10:55 |
| Chipaca | zyga: yeah, that's design -> involves gustavo | 10:56 |
| zyga | yeah | 10:56 |
| zyga | let's do it next week | 10:56 |
| zyga | ok next branch | 10:56 |
| Chipaca | (worse, it's design i don't have an opinion on myself :-) ) | 10:56 |
| zyga | haha | 10:57 |
| pstolowski | zyga, are you working on a fix for https://forum.snapcraft.io/t/hook-timeout-mechanism-not-working-in-2-24/464/4 ? | 10:58 |
| Chipaca | pstolowski: no, you were | 10:59 |
| pstolowski | Chipaca, I intended to, but then zyga commented in the topic saying he would make it happen ;) | 11:00 |
| Chipaca | pstolowski: (i mean, that's what you said yesterday in the standup? or did i misunderstand?) | 11:00 |
| Chipaca | ahh | 11:00 |
| Chipaca | see, ordering is important :-p | 11:00 |
| Chipaca | ok | 11:00 |
| Chipaca | pstolowski: maybe his intention was to make it happen by bossing you around | 11:00 |
| pstolowski | :D | 11:01 |
| zyga | pstolowski: not at present, I'm doing code reviews again | 11:03 |
| zyga | hahaha | 11:04 |
| zyga | pstolowski: I think I commented on that earlier but perhaps I'm mistaken :) | 11:04 |
| zyga | pstolowski: feel free to take it | 11:04 |
| Chipaca | zyga: With unity 8 going away, does adding online-accounts interface make sense? | 11:07 |
| Chipaca | zyga: should we instead nuke all the unity8 support interfaces? | 11:07 |
| Chipaca | as unity8-in-a-snap is prooobably not going to happen | 11:07 |
| zyga | Chipaca: I'd not nuke anything, people are free to hack on those | 11:08 |
| pstolowski | zyga, ok | 11:08 |
| Chipaca | zyga: but if nothing is using them (and nothing is afaik) then they bitrot | 11:09 |
| pstolowski | Chipaca, yeah, we talked about this some time ago on the standup.. unity8 may be developed by community, there is some interest in continuing the project | 11:09 |
| Chipaca | fair enough | 11:11 |
| Chipaca | brb (rebooting) | 11:11 |
| * zyga thinks that bitroot is an interesting problem | 11:14 | |
| jjohansen | zyga: its a learning/complain mode profile. The name starts with the profile that caused the exec chain | 11:38 |
| jjohansen | snap.classic.classic | 11:38 |
| jjohansen | and then each //null- is a new layer of exec, so what ever was confined by snap.classic.classic did an exec of | 11:38 |
| jjohansen | /usr/bin/systemd-run which called | 11:38 |
| jjohansen | /usr/sbin/chroot which called | 11:38 |
| jjohansen | /var/snap/classic/common/classic/bin/dash which called | 11:38 |
| jjohansen | /var/snap/classic/common/classic/usr/bin/script which called | 11:38 |
| jjohansen | /var/snap/classic/common/classic/bin/bash which called | 11:38 |
| jjohansen | /var/snap/classic/common/classic/usr/bin/sudo which called | 11:38 |
| jjohansen | /var/snap/classic/common/classic/bin/bash which called | 11:38 |
| jjohansen | /var/snap/classic/common/classic/usr/bin/sudo which called | 11:38 |
| jjohansen | /var/snap/classic/common/classic/usr/bin/apt-get | 11:38 |
| jjohansen | that final descendant caused the log message | 11:38 |
| dragly | zyga: What is the status on OpenGL with Intel drivers? Should it work? I'm having trouble getting Qt an OpenGL context. | 11:39 |
| jjohansen | that is quite a call chain, under older versions of apparmor you would have only see null-XXX where XXX is a unique number instead of the actual exec names | 11:39 |
| jjohansen | which was far less useful but did result in smaller names | 11:40 |
| zyga | jjohansen: thank you for the description! | 11:45 |
| zyga | dragly: there's no magic in snapd for opengl on intel, we don't bring any drivers form any other place, whatever the snap ships will run (or not) | 11:46 |
| zyga | dragly: all openGL situation nees love | 11:46 |
| ogra_ | GL surely works on clasic with intel for me | 11:47 |
| zyga | ogra_: sure but my point is that it depends on hardware *and* snap | 11:48 |
| zyga | ogra_: snapd should use opengl indirection helpers and load the right driver | 11:48 |
| ogra_ | well, i only ever try witrh the krita snap | 11:48 |
| zyga | ogra_: but nobody implemented that yet | 11:48 |
| zyga | ogra_: and snaps should not ship drivers | 11:48 |
| zyga | ogra_: (except for driver snaps) | 11:48 |
| zyga | ogra_: but now none of that is true | 11:48 |
| ogra_ | i know that makes havy use of GL ... so if you can install and run that one there is *some GL* | 11:48 |
| ogra_ | (used to work also on my nvidia desktop) | 11:49 |
| zyga | ogra_: as I said, there is whatever the snap author bundles | 11:49 |
| zyga | ogra_: snapd doesn't help | 11:49 |
| ogra_ | yeah | 11:49 |
| ogra_ | yay ... ok, one issue found with the gpg stuff | 11:50 |
| ogra_ | (we dont bundle /var/lib/apt/keyrings in the tarball ...) | 11:51 |
| dragly | zyga: Then I don't understand how it works to build on Travis (in a Docker container) and my own machines and run on Nvidia machines afterwards, but not Intel. | 11:51 |
| ogra_ | but even putting the right thing there doesnt fix apt :/ | 11:51 |
| zyga | dragly: we have some special handling for nvidia | 11:51 |
| zyga | dragly: but it's neither generic nor particularly good | 11:51 |
| dragly | Oh, that explains. Thanks! | 11:52 |
| dragly | Are there any examples that I could look at (Krita?) that solve this manually either in the wrapper or by shipping GL drivers? | 11:52 |
| zyga | dragly: no idea really, I can tell you what we do | 11:52 |
| dragly | I don't mind doing it manually, I just don't know what to look for :) | 11:52 |
| zyga | dragly: but ideally someone should use libglvnd all the way | 11:53 |
| zyga | dragly: a snap that is linked so that it doens't link to particular things but to libglvnd | 11:53 |
| zyga | dragly: and contains all the drivers (as a hack / demo) | 11:53 |
| zyga | dragly: and can find the right one using libglvnd | 11:53 |
| zyga | dragly: later on the drivers can be removed from the demo snap and moved elsewhere (TBD) | 11:53 |
| zyga | dragly: and if connected via content should still work | 11:53 |
| zyga | dragly: (as in, give you the right driver while the snap with the application code has none) | 11:54 |
| dragly | so libglvnd is a wrapper for whichever GL lib is installed? | 11:55 |
| zyga | dragly: libglvnd is an emerging way to do GL in a sane way on linux | 11:56 |
| zyga | dragly: everything else is terrible | 11:56 |
| zyga | dragly: (and deployed) ;-) | 11:56 |
| zyga | dragly: but there are many parts missing | 11:56 |
| zyga | dragly: improvements in snapd for the automatic driver installation, kernel parts, mouting the driver for the snap to see, working with libglvd to do the right thing, etc | 11:57 |
| dragly | I see | 11:57 |
| zyga | dragly: also build system improvements | 11:57 |
| zyga | dragly: so when people build whatever snap they don't have to hand-hold it to do the right thing (not ship drivers but ship glvnd) | 11:58 |
| dragly | we really want to use snaps to package our applications, but it sounds like its going to be a lot of work at the moment. Maybe its better to consider alternatives and wait for an "official" solution? | 11:58 |
| zyga | dragly: on each distro the compiled userspace parts be shipped in blessed snaps | 11:58 |
| zyga | dragly: but the kernel parts are an open problem | 11:58 |
| zyga | dragly: you can just ship it the way everyone does (inside snaps) by bundling the zoo of FOSS userspace drivers | 11:58 |
| zyga | dragly: and relying on the magic ubuntu+nvidia enablement | 11:59 |
| zyga | dragly: we'll improve the situation with time but this is not something we're working on at the time | 11:59 |
| zyga | dragly: what I gave you was the bleak reality about how it must be done to work correctly but what people do is very useful despite not having those things | 11:59 |
| dragly | do you happen to know where I can find the zoo of userspace drivers to bundle? I suppose most of them are available through apt? | 12:01 |
| ogra_ | libgl1-mesa-dri and libgl1-mesa-glx should have them | 12:02 |
| dragly | ogra_: great, and they go in as stage-packages, right? | 12:02 |
| ogra_ | installing into /usr/lib/x86_64-linux-gnu/mesa and /usr/lib/x86_64-linux-gnu/dri | 12:03 |
| ogra_ | (on amd64 that is) | 12:03 |
| ogra_ | zyga, so i clearly verified it is the execution environment causing the gpg error, not something missing in teh tarball ... when unpacking an ubuntu-base tarball over the chroot env for the classic snap the error persists | 12:05 |
| ogra_ | i'm now pretty sure it is related to the mknod | 12:06 |
| zyga | ogra_: how sure? | 12:07 |
| zyga | ogra_: can you replace the apparmor profile for classic | 12:07 |
| zyga | ogra_: to allow everything? | 12:07 |
| pstolowski | zyga, question to the hooks timeout problem - you metnioned https://github.com/zyga/snapd/tree/feature/debian-9-qemu ; why do i need that - because this is an old snapd? | 12:08 |
| ogra_ | gimme a moment ... (just uninstalled it to get a clean env again) | 12:08 |
| zyga | pstolowski: because at that time you have snapd tree where this problem is trivial to reproduce and when you can use the only place that (non-tests) lets it happen easily (debian where we have seccomp but not apparmor) | 12:08 |
| zyga | pstolowski: you can test this with unit tests with greater ease | 12:09 |
| zyga | pstolowski: by just putting stuff into state the way 2.21 would do | 12:09 |
| zyga | pstolowski: and starting the manager | 12:09 |
| pstolowski | zyga, thanks. unit tests are tempting. i'm not sure what 2.21 would do though | 12:10 |
| zyga | pstolowski: just not add the timeout field AFAIR | 12:11 |
| zyga | pstolowski: it is in HookSetup | 12:11 |
| ogra_ | zyga, ok, back in business ... how do i allow everything again ? | 12:19 |
| zyga | ogra_: edit /var/lib/snapd/apparmor/profiles for classic | 12:25 |
| zyga | remove everything there (or set it aside) and place... | 12:25 |
| ogra_ | zyga, yeah, that bit i knowe :) | 12:25 |
| ogra_ | (what do i need to put in, how do i regenerate) | 12:25 |
| zyga | ogra_: you load with "apparmor_parser -r /path/to/that/file" | 12:26 |
| zyga | ogra_: as for the contents | 12:26 |
| jdstrand | that path is already allowed | 12:26 |
| zyga | ogra_: keep the initial part | 12:26 |
| zyga | ogra_: and inside the { } | 12:26 |
| jdstrand | wait | 12:27 |
| zyga | jdstrand: oh :) | 12:27 |
| jdstrand | that path should already be allowed | 12:27 |
| Chipaca | popey: you around? | 12:27 |
| zyga | ogra_: jdstrand can give you better advice | 12:27 |
| * zyga runs for lunch | 12:27 | |
| jdstrand | well, probably not, but I may have more information | 12:27 |
| ogra_ | http://paste.ubuntu.com/24516694/ is the current profile | 12:28 |
| jdstrand | perfect | 12:28 |
| * jdstrand looks | 12:28 | |
| ogra_ | (but i'm also running in --devmode anyway) | 12:29 |
| * jdstrand understands | 12:29 | |
| jdstrand | @{SNAP_NAME}="classic" | 12:30 |
| nothal | jdstrand: No such command! | 12:30 |
| jdstrand | /var/snap/@{SNAP_NAME}/common/** wl, | 12:30 |
| jdstrand | /var/snap/classic/common/classic/tmp/fileutl.message.wopbff | 12:30 |
| jdstrand | right, yes, there is a rule for that | 12:30 |
| ogra_ | well /var/snap/classic/common/classic/tmp/fileutl.message.wopbff is rather dynamically created | 12:31 |
| jdstrand | ogra_: what is the output of 'snap info <the name of the kernel snap>'? | 12:31 |
| ogra_ | http://paste.ubuntu.com/24516706/ | 12:32 |
| ogra_ | jdstrand, this is for Bug #1670475 BTW | 12:32 |
| mup | Bug #1670475: apt-secure complaints with classic snap on arm <Snappy:New> <https://launchpad.net/bugs/1670475> | 12:32 |
| jdstrand | interesting that beta and candidate have newer revisions than edge | 12:33 |
| ogra_ | i verified that nothing is missing in the classic chroot by simply using an ubuntu-base tarball inside that env ... it exposes the same issue | 12:33 |
| jdstrand | ogra_: yes, I read backscroll. thank you for looking into this btw | 12:33 |
| ogra_ | jdstrand, yeah, i need to sync again ... i can swithc the board to beta if that helps ... (i doubt it though) | 12:33 |
| ogra_ | kernel team only releases to beta and candidate ... edge is for tinkering | 12:34 |
| ogra_ | (i.e. manual uploads) | 12:34 |
| jdstrand | ogra_: what are the permissions of /var/snap/classic/common/, /var/snap/classic/common/classic/ and /var/snap/classic/common/classic/tmp/? | 12:34 |
| jdstrand | hmm | 12:34 |
| jdstrand | yes, answer that, but, the fact that this says ALLOWED is wrong because the rule is in the policy | 12:35 |
| jdstrand | I think this is a complain mode denial bug | 12:35 |
| ogra_ | http://paste.ubuntu.com/24516718/ | 12:35 |
| jdstrand | s/is/may be/ | 12:35 |
| jdstrand | ogra_: can you use -ld | 12:35 |
| ogra_ | http://paste.ubuntu.com/24516723/ | 12:36 |
| ogra_ | also a "touch /tmp/foo" from inside the running chroot shows up fine as /var/snap/classic/common/classic/tmp/foo | 12:37 |
| jdstrand | right ok | 12:37 |
| jdstrand | I think this is a complain mode denial bug | 12:37 |
| ogra_ | so the mknod will be denied while it shouldnt ? | 12:38 |
| jdstrand | ogra_: can you boot into the highest revision available? iirc, there were some fixes for this sort of thing | 12:38 |
| ogra_ | sure | 12:38 |
| jdstrand | ogra_: the bug (I suspect) is that even though there is a matching rule in the policy (the one I pasted), there is a bug that the file access isn't matching the rule (which is why we see ALLOWED). there is a second bug (my theory) that even though we are in complain mode, the kernel is still denying it | 12:40 |
| jdstrand | ogra_: the fact that non-dragonboard kernels aren't seeing this gives support to a kernel bug | 12:41 |
| ogra_ | jdstrand, all arm kernels see it now | 12:41 |
| jdstrand | but not amd64/i386? | 12:41 |
| ogra_ | (note i'm on a pi3) | 12:41 |
| ogra_ | i havent tried x86 ... you claimed in the bug i386 works | 12:42 |
| jdstrand | ogra_: well, at the time, but at the time armhf worked too | 12:42 |
| jdstrand | so maybe everything is broken | 12:42 |
| ogra_ | HA! | 12:43 |
| ogra_ | works !!! | 12:43 |
| jdstrand | we are getting into jj territory here, but I'd like to have a simpler reproducer | 12:43 |
| ogra_ | crazy | 12:43 |
| jdstrand | ok, good :) | 12:43 |
| jdstrand | well, no, we had complain mode bugs that jj fixed :) | 12:43 |
| jdstrand | so, it sounds like the pi3 kernel needs those fixes too | 12:43 |
| jdstrand | iirc, pi3 is stuck due to boot image stuff | 12:44 |
| ogra_ | before: http://paste.ubuntu.com/24516746/ ... after: http://paste.ubuntu.com/24516747/ | 12:44 |
| ogra_ | right | 12:44 |
| ogra_ | pi's are all stuck | 12:44 |
| jdstrand | ok | 12:44 |
| jdstrand | so now we have triaged the bug | 12:44 |
| jdstrand | let me add a comment | 12:44 |
| ogra_ | there is another issue (we dont keep the keyring around in the tarball) but i'll fix that one today | 12:45 |
| jdstrand | when the pi's are all updated with latest apparmor (I think I tried on bbb), they should be fixed | 12:45 |
| jdstrand | ogra_: you went to beta? | 12:47 |
| ogra_ | yep | 12:47 |
| jdstrand | ogra_: oh, that is a pi2-kernel. ok | 12:48 |
| mup | PR snapcraft#1223 closed: kernel plugin: check_config() and check_initrd() support <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1223> | 12:48 |
| ogra_ | well, pi kernel | 12:49 |
| ogra_ | (it is identical for 2 and 3 | 12:49 |
| ogra_ | ) | 12:49 |
| jdstrand | ogra_: I thought there was a forum topic on the boot/gadget/kernel issue. can you give it to me or a bug? | 12:56 |
| ogra_ | one sec | 12:57 |
| * jdstrand couldn't find it | 12:57 | |
| ogra_ | https://forum.snapcraft.io/t/updating-bootloader-assets-in-the-gadget-snap/70 | 12:57 |
| ogra_ | just a serach for gadget reveals it | 12:57 |
| jdstrand | oh, I did look at that | 12:57 |
| jdstrand | but I thought that was different. ok thanks | 12:57 |
| zyga | re | 12:57 |
| ogra_ | jdstrand, it is also supposed to be a hot topic at the current sprint | 12:57 |
| mup | PR snapcraft#1294 closed: meson plugin: Add plugin for meson build system <Created by JulianLiu> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1294> | 12:58 |
| zyga | ogra_: standup | 13:03 |
| ogra_ | zyga, yeah | 13:03 |
| zyga | morphis: you are welcome to join us if you have no conflicts | 13:03 |
| mup | PR snapd#3277 opened: cmd/snap, client: add "whoami" command <Created by chipaca> <https://github.com/snapcore/snapd/pull/3277> | 13:06 |
| mup | PR snapcraft#1296 closed: rust snaps can now use source-subdir without failing on pull <Created by roxyd> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1296> | 13:13 |
| mup | Bug #1670475 changed: apt-secure complaints with classic snap on arm <Snappy:Invalid> <https://launchpad.net/bugs/1670475> | 13:13 |
| === grumble is now known as 14WAA001L | ||
| === 14WAA001L is now known as grumble | ||
| === mup_ is now known as mup | ||
| jdstrand | Chipaca: hey, saw in backscroll you needed me, but not sure from backscroll if you still need me (fyi, I commented on locale-control PR) | 13:24 |
| Chipaca | jdstrand: yes! | 13:29 |
| Chipaca | jdstrand: about _filedir | 13:29 |
| Chipaca | jdstrand: I'm pretty sure I addressed the biggest issue already | 13:29 |
| Chipaca | jdstrand: the only place it trips up now is from the outside in | 13:30 |
| Chipaca | (so there's some mis-quoting going on but i'll have to dig) | 13:30 |
| Chipaca | but for example if something has spaces I correctly get back things that backslash the space | 13:30 |
| Chipaca | ie “Screenshot\ from\ ” | 13:31 |
| Chipaca | jdstrand: could you take a poke and see if you see the same? | 13:31 |
| AdamH_ | Gents, I have been watching the comments and can see the issue with apt-get requires a newer kernel. Is there a how-to or guide anywhere on how to update to a new one? | 13:31 |
| Chipaca | AdamH_: I think as long as you can reflash, yes | 13:32 |
| jdstrand | Chipaca: you updated the PR for this? | 13:32 |
| Chipaca | AdamH_: ogra_ knows more | 13:32 |
| Chipaca | jdstrand: 1 sec | 13:32 |
| Chipaca | jdstrand: there was a bug in compopt | 13:33 |
| Chipaca | jdstrand: https://github.com/snapcore/snapd/pull/3150/commits/8a60343a82a23d91284f863d8bff226dccdc21bd | 13:34 |
| mup | PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150> | 13:34 |
| Chipaca | jdstrand: actually https://github.com/snapcore/snapd/pull/3150/commits/8a60343a82a23d91284f863d8bff226dccdc21bd#diff-96d0d48e1bd095153ade81afdb99f7ebR85 | 13:34 |
| AdamH_ | Chipaca: Yes I can reflash if needed | 13:34 |
| jdstrand | Chipaca: ah, cool. ok. gimme a bit and I can take a look later this morning | 13:35 |
| Chipaca | jdstrand: ok lurvely | 13:35 |
| jdstrand | oh, heh | 13:35 |
| * jdstrand just looked at the commit | 13:35 | |
| Chipaca | yeah | 13:35 |
| morphis | zyga: sorry, got back to late from my lunch break | 13:38 |
| zyga | morphis: no worries | 13:39 |
| popey | Chipaca: sorry, was afk | 13:39 |
| popey | Chipaca: if this is about the thread on forum about my sign on being broken, I can't reproduce it, unless IS nukes the password on my store account (that's how you reproduce it) | 13:42 |
| popey | e.g. get your password leaked somewhere and IS pro-actively help you :) | 13:42 |
| === petevg_afk is now known as petevg | ||
| Chipaca | popey: so what's your password? | 13:52 |
| Chipaca | popey: is it ******** | 13:53 |
| spineau | zyga: hi, I'm testing the ability to run other snaps commands from checkbox snap. That's amazing | 13:57 |
| zyga | spineau: hey | 13:57 |
| zyga | spineau: is it working ok? :) | 13:57 |
| spineau | zyga: with core from beta yes, we can call them | 13:58 |
| spineau | zyga: but I'm facing a limitation | 13:58 |
| zyga | yes? | 13:58 |
| spineau | zyga: for example I have a tpm2 command with a -o parameter to save something to a file | 13:58 |
| spineau | zyga: it seems that the only allowed location is SNAP_USER_COMMON | 13:59 |
| spineau | zyga: I'm not sure if there's a way to share data between snaps | 14:00 |
| zyga | spineau: aha, interesting point | 14:00 |
| zyga | spineau: if your test snaps have the home interface then you can connect it and just share data this way | 14:00 |
| spineau | zyga: but SNAP_USER_COMMON which works is the one for the tpm2 snap (not the one fro mcheckbox of course) | 14:00 |
| popey | Chipaca: indeed, hunter2 all the way | 14:01 |
| spineau | zyga: ok, I'll try that. thanks for the tip | 14:01 |
| zyga | spineau: there are other ways but I'd recommend against them until the (dreaded) update-ns feature is finished | 14:01 |
| kyrofa | Oh man, pachulo, you and I are on very different timezones :P . This conversation might be best on a new issue against the snap | 14:08 |
| kyrofa | pachulo, something is weird there: why is the php part pulling in python? Please log a bug against the snap, let me see the changes you're trying to make, and we can troubleshoot asynchronously there :) | 14:11 |
| kyrofa | pachulo, thanks for taking a crack at that bug! | 14:12 |
| AdamH_ | ogra: How did you update the kernel on your rPi3 to resolve the apt-get issue? | 14:16 |
| zyga | AdamH_: you have to rebuild the image and reinstall | 14:17 |
| zyga | AFAIK | 14:17 |
| AdamH_ | zyga: By rebuilding do you mean grabing the latest daily build and re-imaging? | 14:18 |
| zyga | AdamH_: I think so | 14:19 |
| * zyga didn't try | 14:19 | |
| AdamH_ | zyga: Thanks, will give it a go | 14:19 |
| zyga | AdamH_: we're working on fixing the root issue but it will still take a while to plan/schedule | 14:19 |
| AdamH_ | zyga: Yes understood | 14:20 |
| ogra_ | zyga, huh ? | 14:41 |
| ogra_ | AdamH_, if you use a stable image there is no way ... if you use a daily/edge image: snap refresh pi2-kernel --beta | 14:42 |
| ogra_ | that will switch you over to the beta kernel | 14:42 |
| ogra_ | (do not run that on a stable pi image, it wont boot anymore) | 14:43 |
| ogra_ | (well, it will roll back ... but never boot into the new kernel) | 14:43 |
| zyga | ogra_: hm? | 14:46 |
| ogra_ | zyga, why would he need to rebuild | 14:46 |
| zyga | ogra_: I thought because to boot one needs to get a fresh image with edge kernel | 14:48 |
| ogra_ | zyga, if you are on an edge image you can just switch channels for the kernel via refresh | 14:48 |
| ogra_ | i do that all the time ... in fact i usually install a daily and then switch kernel to beta and core to stable after first boot ;) | 14:49 |
| ogra_ | thats the current way to keep a pi up to date | 14:49 |
| zyga | ogra_: wait, I must be missing something; if I start on a stable image, can I use edge kernel/core? | 14:52 |
| ogra_ | zyga, you cant use an edge kernel on stable, no (wont boot and just roll back) ... you can use the edge core on stable ... and you can use edge/beta/candidate or whatever you want to all packages on a daily image | 14:57 |
| ogra_ | so it always depends what image you started from ... rebuilding anything wont gain you anything though | 14:58 |
| ogra_ | (stable gadget only goes with stable kernel ... nothing else will boot) | 14:58 |
| pachulo | ok kyrofa , I will do that! | 15:38 |
| === didrocks1 is now known as didrocks | ||
| mup | Bug #1621745 changed: snapd package is missing dependency on grub-common for grub-editenv <Snappy:Fix Released> <Ubuntu Image:Fix Released> <https://launchpad.net/bugs/1621745> | 15:47 |
| mup | Bug #1534154 changed: BootAssetFiles have new "Dst" key that we should support <Snappy:Invalid> <https://launchpad.net/bugs/1534154> | 15:53 |
| zyga | jdstrand: hey | 15:55 |
| === chihchun is now known as chihchun_afk | ||
| zyga | jdstrand: I have something, an experiment of afternoon friday hacking | 15:55 |
| zyga | jdstrand: I was wondering if snapd could do the resolving on seccomp profiles | 15:55 |
| zyga | jdstrand: so snap-confine could be easier and more portable | 15:55 |
| zyga | jdstrand: so I came up with a way | 15:55 |
| zyga | jdstrand: interested? :-) | 15:56 |
| jdstrand | I'm not sure how it would be more portable. if this is something you are going to be pushing for, yes I definitely want to discuss it. however, my friday is completely booked for non-experimental stuff, so perhaps next week? | 15:59 |
| jdstrand | zyga: ^ | 15:59 |
| zyga | jdstrand: perhaps portable is less iteresting; the point is that it would be smaller and would change less often | 16:02 |
| zyga | jdstrand: yeah, this is a total RFC and idea | 16:02 |
| zyga | jdstrand: I'll catch you next week | 16:02 |
| jdstrand | cool, thanks | 16:02 |
| jdstrand | Chipaca: fyi, I haven't forgot you. I'll get there | 16:02 |
| jdstrand | forgotten* | 16:02 |
| * Chipaca steps back from the ledge | 16:02 | |
| jdstrand | lol :) | 16:03 |
| Chipaca | :-) | 16:03 |
| Chipaca | jdstrand: I'm in a maze of twisted error messages, all different | 16:03 |
| Chipaca | jdstrand: not busy-waiting on you | 16:03 |
| jdstrand | ok cool | 16:03 |
| jdstrand | well | 16:03 |
| Chipaca | (but yeah i could do with landing that branch today, which i will do if you confirm what i found) | 16:03 |
| jdstrand | nice that you aren't waiting on me. not so nice about the twisty maze | 16:04 |
| Chipaca | jdstrand: that's ok, i get to use a type called "stringish" | 16:04 |
| zyga | Chipaca: what are you hacking on? | 16:07 |
| Chipaca | zyga: store | 16:08 |
| Chipaca | zyga: some responses from sso are not what we expect | 16:08 |
| Chipaca | zyga: have you figured out the test breakage | 16:09 |
| zyga | Chipaca: no, I should probably have a look at that ... | 16:12 |
| Chipaca | zyga: only if you haven't EOW'ed | 16:13 |
| zyga | no, not yet, still digging | 16:13 |
| cjwatson | elopio: doesn't look too difficult to sort out a git:// proxy in launchpad-buildd, so I'm working on that | 16:15 |
| cjwatson | among the nineteen thousand other buildd patches I have queued ... | 16:15 |
| zyga | fg | 16:16 |
| Chipaca | zyga: fg: current: no such job | 16:16 |
| zyga | are you saying I'm slacking ;) | 16:18 |
| * zyga runs spread | 16:23 | |
| zyga | I wonder if it fails locally | 16:23 |
| zyga | Chipaca: oddly it built fine locally (in qemu)( | 16:32 |
| zyga | Chipaca: I'll try linode next | 16:32 |
| elopio | cjwatson: thanks! I think for my case I can install phantomjs from the deb, but last time I tried that it ended in a mess. I'll try again. | 16:49 |
| cjwatson | I have a juju tentacled monstrosity on my laptop to make it easier to test this stuff | 16:54 |
| Chipaca | zyga: yeah i tried to say 'it works for me' in the standup but google hated me just then | 17:02 |
| * zyga goes to pick up kids | 17:12 | |
| === cachio is now known as cachio_afk | ||
| Chipaca | zyga: did you kick off the tests on snapd#3275 again? | 17:44 |
| mup | PR snapd#3275: snap: move locale-control to only be present on classic <Created by chipaca> <https://github.com/snapcore/snapd/pull/3275> | 17:44 |
| cjwatson | elopio: OK, I think I have this working locally \o/ | 17:46 |
| cjwatson | just waiting to see exactly how far it gets, since running snap builds behind slow ADSL isn't the quickest of experiences | 17:47 |
| elopio | cjwatson: awesome! | 17:47 |
| elopio | cjwatson: I'm happy you are done with that one, because, I have another one :( https://build.snapcraft.io/user/elopio/ipfs-snap/35231 | 17:48 |
| cjwatson | what the heck is gx | 17:51 |
| elopio | cjwatson: it's a go package manager on top of ipfs. | 17:53 |
| elopio | but I think that when you don't have ipfs, like in this case, it just uses http. | 17:53 |
| cjwatson | elopio: anyway, it's 7pm on Friday, I'm unlikely to get to it today; can you file a bug on launchpad-buildd? | 17:55 |
| cjwatson | I have a bunch of stuff queued up that may help, but I'd need to check it | 17:55 |
| cjwatson | (particularly my local-snap-proxy branch which means we stop having to worry about client-specific support for authenticated proxies) | 17:56 |
| elopio | cjwatson: sure. Thanks a lot, and enjoy the weekend. | 17:57 |
| elopio | https://bugs.launchpad.net/launchpad-buildd/+bug/1688624 | 18:04 |
| mup | Bug #1688624: ipfs fails to build: no such host <launchpad-buildd:New> <https://launchpad.net/bugs/1688624> | 18:04 |
| zyga | re | 18:41 |
| zyga | Chipaca: looking | 18:41 |
| zyga | Chipaca: no, I don't think I did | 18:41 |
| zyga | Chipaca: did you figure anything out? | 18:41 |
| Chipaca | zyga: no, but it came up green | 18:45 |
| Chipaca | zyga: in fact both 3275 and 3277 are green in travis | 18:46 |
| zyga | Chipaca: wasn't me | 18:49 |
| zyga | maybe mvo fixed something? | 18:49 |
| Chipaca | zyga: ogra left for the weekend and turned off his break-everything-inator | 18:51 |
| Chipaca | zyga: ogra's surname is doofenshmirtz | 18:52 |
| zyga | lol :) | 18:52 |
| * zyga runs his locally built snapd | 19:03 | |
| zyga | Chipaca: this is why snapd should not become init ;-) | 19:04 |
| Chipaca | popey: https://github.com/snapcore/snapd/pull/3278 | 19:06 |
| mup | PR snapd#3278: store, daemon, client, cmd/snap: handle PASSWORD_POLICY_ERROR <Created by chipaca> <https://github.com/snapcore/snapd/pull/3278> | 19:06 |
| mup | PR snapd#3278 opened: store, daemon, client, cmd/snap: handle PASSWORD_POLICY_ERROR <Created by chipaca> <https://github.com/snapcore/snapd/pull/3278> | 19:06 |
| zyga | surprisingly nothing explodes! | 19:15 |
| jdstrand | Chipaca: commented | 19:18 |
| jdstrand | Chipaca: I think you are good to go | 19:18 |
| popey | Chipaca: yay | 19:26 |
| cratliff_ | kyrofa: Have you had to do anything with adding rules to rosdep while making a snap? Would any packages pointed to by custom rosdep rules need to be made as a part in the snap? | 19:28 |
| === cachio_afk is now known as cachio | ||
| zyga | some failures on the nice password policy error branch | 19:56 |
| zyga | Chipaca: commented on the PR | 19:58 |
| Chipaca | zyga: my bad, will fix | 21:29 |
| zyga | Chipaca: hard to guess | 21:31 |
| * zyga runs another spread run and EOWs | 21:32 | |
| Chipaca | zyga: guessing is super easy! | 21:32 |
| Chipaca | i do it all the time | 21:32 |
| mup | PR snapd#3150 closed: In-snap bash tab completion <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3150> | 21:33 |
| Chipaca | ladies ^ | 21:33 |
| * zyga claps | 21:33 | |
| zyga | That's some fine work there mate! | 21:33 |
| Chipaca | that was a cow of a thing, glad it's on the other side :-) | 21:33 |
| Chipaca | now i need to write something up to explain it a bit | 21:33 |
| Chipaca | also, chase down bugs i'm sure. But first i've got branches to polish. | 21:34 |
| * mcphail wakes up. Wow. Cheers Chipaca | 21:34 | |
| Chipaca | zyga: jdstrand: thank you :-) | 21:34 |
| zyga | Chipaca: I ended this week with a small experiment, https://github.com/zyga/snapd/tree/feature/typed-syscalls | 21:36 |
| zyga | Chipaca: works OK though not the full potential, the output is still rather ugly, I'll make it sort by interface so that it is nicer to look at | 21:36 |
| Chipaca | huh | 21:37 |
| zyga | ? | 21:37 |
| zyga | anyway | 21:39 |
| zyga | beer time | 21:39 |
| zyga | and tomorrow | 21:39 |
| zyga | farm! | 21:39 |
| Chipaca | zyga: multiple iotas | 21:39 |
| Chipaca | i'd always seen it written as a single thing | 21:39 |
| Chipaca | like, const ( Foo = FooClass(iota); Bar; Baz; Quux ) | 21:39 |
| zyga | Chipaca: yeah, I think I wanted that without the many iotas but it didn't do the thing I expected | 21:40 |
| * zyga tries | 21:40 | |
| zyga | ah, I'm drunk, it works ok | 21:41 |
| Chipaca | as long as the type is on the expression, it works | 21:41 |
| zyga | Chipaca: yep, pushed | 21:42 |
| Chipaca | if instead you do const ( Foo FooClass = iota; Bar; Baz ) | 21:42 |
| Chipaca | then i think just Foo is FooClass, the others are just ints | 21:42 |
| zyga | Chipaca: this branch might arguably fix the dreaded hrsearch_r failed :) | 21:42 |
| zyga | hsearch_r * | 21:42 |
| Chipaca | :-) | 21:42 |
| zyga | as it does the hard work so that snap-confine can be ... dumb | 21:42 |
| Chipaca | zyga: you need to sit down with jdstrand tho | 21:42 |
| zyga | yes, I think he may dislike it | 21:43 |
| Chipaca | zyga: then sit down with him before falling in love with this too much :-D | 21:43 |
| zyga | but I wanted to do it anyway, to show that with some parsing the seccomp profiles can be better (nicer, sorted, de-duplicated, described, etc) | 21:43 |
| zyga | Chipaca: well, it's a friday thing :) | 21:43 |
| zyga | on the slower week | 21:43 |
| Chipaca | yeah | 21:44 |
| Chipaca | maybe i should've worked on the progress bar / terminfo thing | 21:44 |
| Chipaca | :-) | 21:44 |
| zyga | ohh | 21:44 |
| zyga | terminal stuff is my other love | 21:44 |
| zyga | that's for weekend tho | 21:44 |
| Chipaca | proper colour support is _terrible_ | 21:44 |
| zyga | why? | 21:45 |
| zyga | are you kidding me? | 21:45 |
| Chipaca | no, no i'm not | 21:45 |
| zyga | one sec | 21:45 |
| * Chipaca is having a beer as well | 21:45 | |
| zyga | Chipaca: super ancient stuff I never landed https://github.com/zyga/guacamole/pull/15 | 21:45 |
| mup | PR zyga/guacamole#15: Add terminal awareness ingredient <Created by zyga> <https://github.com/zyga/guacamole/pull/15> | 21:45 |
| zyga | Just scroll :D | 21:46 |
| zyga | https://github.com/zyga/guacamole/blob/master/examples/rainbow.py is also fun to look at | 21:46 |
| jdstrand | I'm about to head out but I can say a couple of things, drop the mic, then leave. the hsearch_r things should be fixed now with reexec so long as you build snap-confine and snapd and copy both over. I'm not 100% sure this is going to work the way you want by dropping the snapd binary anywhere. but more importantly, it makes policy development difficult cause the policy writer has to figure out the number to put in the policy | 21:46 |
| jdstrand | most importantly, snap-confine can't be that dumb and will have to parse at least some things | 21:47 |
| jdstrand | eg, the current real and effective user (for the user/groups branch I'm working on) | 21:47 |
| zyga | jdstrand: no, it's still optional; the way I made it it could even fail at build time (loudly) but now just gets forwarded to snap-confine as-is | 21:47 |
| zyga | jdstrand: sure, I know and I agree | 21:47 |
| zyga | jdstrand: I think I wanted to do this to make the generated profiles nicer | 21:48 |
| jdstrand | well, if you are trying to make snap-confine dumb, then it won't be optional | 21:48 |
| zyga | jdstrand: dumber, not fully dumb | 21:48 |
| zyga | jdstrand: it will not need a lot of those maps | 21:48 |
| zyga | jdstrand: but anyway, this is a secondary goal, I really wanted to make profiles more readable | 21:48 |
| zyga | jdstrand: right now they are a bit... well, mashed up | 21:48 |
| jdstrand | I don't like the sort either | 21:49 |
| zyga | jdstrand: (and FYI, I'm not fully happy with the output now, but it is better than before) | 21:49 |
| jdstrand | we want comments inline with the rules that are there | 21:49 |
| jdstrand | plus, the map stuff doesn't really look any prettier to me than then C | 21:49 |
| zyga | jdstrand: those stay | 21:49 |
| zyga | http://paste.ubuntu.com/24519406/ | 21:49 |
| zyga | jdstrand: (this is still with relatively naive output, it can look nicer still) | 21:50 |
| jdstrand | I don't see how that output is any better... I see a bunch of comments explaining what you mapped to | 21:51 |
| zyga | jdstrand: mainly by keeping the flow of snippets, adding headers "# this is what interface FOO added:" etc | 21:51 |
| jdstrand | that is fine | 21:51 |
| zyga | jdstrand: the previou output was worse as it was totally (crappily) sorted on huge multi-line strings | 21:51 |
| jdstrand | but that is supposed to be at the top of the snippets for each interface anyway | 21:51 |
| jdstrand | anyway, I gotta go | 21:51 |
| zyga | jdstrand: oh, and one more thing, I didn't do it in this branch but the # description stuff really should not live in snippets | 21:51 |
| zyga | jdstrand: o/ enjoy the weekend, see you next week :) | 21:52 |
| jdstrand | you too! :) | 21:52 |
| Chipaca | wrt colour support being terrible, there is no good way of detecting whether a terminal supports 16M colours | 21:55 |
| Chipaca | terminfo have said they won't support it at all | 21:55 |
| Chipaca | and of the terminals that support it, they only support it from a certain version on (if compiled with the right flags), and only VTE exposes something you might use to guess (the VTE version) | 21:56 |
| Chipaca | so, you say, no problem, ignore 16M colours and use the paletted 256 colour support | 21:56 |
| Chipaca | which is much more prevalent, and detectable (terminfo knows) | 21:56 |
| Chipaca | but, but, it's a palette, and in some but not all terminals it's a _modifiable_ palette. And some of the terminals that let you modify it let you query it (in a horrible horrible way that involves termios things to read it back), but not all | 21:57 |
| Chipaca | so there's absolutely no sane way of saying "make this text be of colour #c0ffee" | 21:58 |
| Chipaca | you can say "make this be colour #2" | 21:58 |
| Chipaca | which will be something blue, or green, depending, but only if the user hasn't changed it to something else | 21:59 |
| zyga | Chipaca: yeah; hence I did the insane, locally see which terminal emulator is used ;D | 21:59 |
| zyga | Chipaca: but actually most things support the 16M colors fine | 22:00 |
| zyga | Chipaca: and the rest, well, screw that stuff | 22:00 |
| Chipaca | zyga: the problem is that some of the stuff that _doesn't_ is actually important | 22:00 |
| Chipaca | like, screen ant tmux | 22:00 |
| zyga | Chipaca: it's also compound by the fact that multiplexers and even ssh can make stuff crazy | 22:00 |
| zyga | Chipaca: ha, I know :) | 22:00 |
| Chipaca | heh, see :-) | 22:00 |
| zyga | Chipaca: I have a secret plan for that tho :) | 22:00 |
| zyga | Chipaca: long standing desire to fix that properly | 22:01 |
| Chipaca | so, I'm probably going to write something called schmerminfo | 22:01 |
| zyga | what would that do? | 22:01 |
| Chipaca | (it's half written in my head already) | 22:01 |
| Chipaca | zyga: be a very opinionated thing that does the same sort of thing as terminfo does, but just for the stuff i care about | 22:01 |
| Chipaca | alternatively i could make it fall back to terminfo (i mean, i already wrote _that_ one in go :) ) | 22:02 |
| Chipaca | and just sprinkle colour magic on top | 22:02 |
| Chipaca | OTOH, i don't need all terminfo | 22:02 |
| Chipaca | so ... | 22:02 |
| zyga | Chipaca: how would the API look like? | 22:02 |
| Chipaca | it's there at the back of my head percolating | 22:02 |
| Chipaca | zyga: I've tried something like the terminfo api, and it's pretty nasty | 22:03 |
| Chipaca | zyga: so I'll be looking at doing something fmt-ish next, see how that one feels | 22:03 |
| zyga | Chipaca: yeah, I think that's the right intuition | 22:03 |
| zyga | Chipaca: I tried it myself too earlier and anything heavier or more typed was too annoying to use | 22:04 |
| Chipaca | anyway, that's backburner stuff for me | 22:05 |
| zyga | Chipaca: btw, the guacamole thing I linked to has one fun element: colorblind mode | 22:05 |
| Chipaca | and it's got so many branches, it never ends | 22:05 |
| zyga | Chipaca: lets you run your app with color emulation to see how specific kind of colorblindness might be perceived | 22:05 |
| Chipaca | zyga: ah, i'll look at that sometime then, as that was on my mind also | 22:05 |
| Chipaca | zyga: one of the branches of this problem space (i.e., "make progress bars pretty and functional") was progress bar for transformative io | 22:06 |
| zyga | Chipaca: https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py | 22:06 |
| Chipaca | ie a progress bar for decompressing something | 22:06 |
| Chipaca | where it tells you what it's read, and what it's decompressed | 22:06 |
| Chipaca | (or compressed) | 22:06 |
| zyga | Chipaca: I recommend you to look at RHEL 7 bootup | 22:06 |
| zyga | Chipaca: the progress bar is totally pretty | 22:07 |
| Chipaca | zyga: the textmode one? | 22:07 |
| Chipaca | haven't seen that | 22:07 |
| zyga | Chipaca: or any opensuse/fedora thing that boots in text mode | 22:07 |
| zyga | Chipaca: more crazy and fun stuff: https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L404 | 22:07 |
| * zyga loves verbose python | 22:07 | |
| zyga | https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L500 | 22:08 |
| zyga | some more craziness: https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L635 | 22:08 |
| Chipaca | zyga: guacamole seems to ignore the whole "paletted terms change their colours" thing :-) | 22:08 |
| zyga | https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L769 | 22:08 |
| zyga | :D | 22:09 |
| zyga | Chipaca: ah, no | 22:09 |
| zyga | Chipaca: well | 22:09 |
| zyga | Chipaca: there are sets that change | 22:09 |
| zyga | Chipaca: and there are sets that don't change | 22:09 |
| AdamH_ | Gents, I have a mir-kiosk app that builds and runs fine on Ubuntu core running in KVM but I get the following error when built using classic snap on rPi3 - mirserver: Rejected and disconnected a client (Unsupported protocol version) Any idea where the mirserver logs are? Trying to debug | 22:09 |
| zyga | Chipaca: if the programmer asked for a specific color then I use those that don't change | 22:09 |
| zyga | Chipaca: if you asked for symbolic indexed 8 element palette then those change | 22:09 |
| zyga | Chipaca: but... | 22:09 |
| zyga | Chipaca: bare with me :-D | 22:09 |
| zyga | Chipaca: https://github.com/zyga/guacamole/blob/colorblind/guacamole/ingredients/color.py#L302 | 22:10 |
| zyga | Chipaca: I also try to know what they were by default | 22:10 |
| zyga | Chipaca: I also looked at how I can ask the terminal for the real values at runtime | 22:10 |
| Chipaca | AdamH_: looks like your mir server and client have different libmirclients | 22:10 |
| zyga | (guacamole was more of an experiment to explore colors than practical tool) | 22:10 |
| zyga | Chipaca: this is fun because you can use gnome-terminal with guacamole to ask how your application would render on putty (color accurate) or apple's terminal emulator | 22:11 |
| AdamH_ | Chipaca: Thanks, is there a quick way to tell? | 22:11 |
| zyga | Chipaca: using the right color mixer you can get that output | 22:11 |
| zyga | Chipaca: guacamole has one big flaw though, it is a python library, not something universal | 22:11 |
| zyga | Chipaca: slowly, I'm building a universal solution | 22:11 |
| Chipaca | zyga: nice | 22:11 |
| Chipaca | AdamH_: I'm not sure; check the soname? | 22:12 |
| zyga | Chipaca: where it is more like modern graphical stack than terminal stuff, but we'll see :) | 22:12 |
| AdamH_ | Chipaca: Not sure what soname is, but you have given me something to read up on thanks | 22:15 |
| zyga | Chipaca: anyway, I'll think I'll stop typing now, enjoy your weekend :) | 22:16 |
| Chipaca | zyga: way ahead of you :-) | 22:18 |
| mup | PR snapd#3275 closed: snap: move locale-control to only be present on classic <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3275> | 22:38 |
| === bdxbdx is now known as bdx | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!