| ikey | https://lists.debian.org/debian-devel/2017/08/msg00090.html <- thats a lot of words for "we kinda want snapd working." | 01:52 |
|---|---|---|
| === ikey is now known as ikey|zzz | ||
| mup | PR snapcraft#1600 closed: options: fix core-dynamic-linker on ppc64el/s390x <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1600> | 03:27 |
| mup | PR snapcraft#1595 closed: tests: fix the skip of snapd integration tests in armhf <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1595> | 03:30 |
| CreateChange | hello, where can i find an actual list of snap packages | 03:38 |
| CreateChange | i am struggling to that end | 03:38 |
| === JoshStrobl is now known as JoshStrobl|zzz | ||
| zyga-ubuntu | good morning | 06:02 |
| mvo | hey zyga-ubuntu | 06:07 |
| mvo | zyga-ubuntu: hrm, hrm, looks like we need 2.28.2 and pull in #4004 (nice number). I didn't see this pr and I'm not sure I would have spotted the significance. did we improve the validation in 2.28 or why did it start breaking suddenly? | 06:14 |
| mup | PR #4004: interfaces/lxd: lxd slot implementation can also be an app snap <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4004> | 06:14 |
| zyga-ubuntu | mvo: hello, I think this is lxd on core (not classic) and we never touched this | 06:16 |
| zyga-ubuntu | mvo: so lxd-as-a-snap vs lxd slot provided by core | 06:16 |
| zyga-ubuntu | mvo: I think it was never working but perhaps my assumptions are wrong | 06:16 |
| zyga-ubuntu | mvo: and it looks untested, maybe we test it in the nightly "important snaps work" thing but I didn't check yet | 06:17 |
| zyga-ubuntu | mvo: although, the wording "stopped working" in the lxd bug report seems to imply improved validation | 06:18 |
| mvo | zyga-ubuntu: yeah, stgraber indicated it is a regression - anyways, I am fixing now but would love to understand better why we see it now, maybe pawel knows | 06:19 |
| zyga-ubuntu | mvo: as far as I understand it interface validation never prevented snaps from refreshing (we juts logged it) and while this has changed rencently it's not 2.28 material | 06:21 |
| mvo | zyga-ubuntu: yeah, its not the refresh, its the connection that is no longer working for him | 06:22 |
| zyga-ubuntu | mvo: hmm, on Ubuntu 14.04 we only have 2.27.5 available, why is that? | 06:51 |
| zyga-ubuntu | mvo: I was trying to understand a failure in 2.27.6 when installed on 14.04 | 06:51 |
| zyga-ubuntu | mvo: it would fail with Failed to enable unit: File snapd.refresh.timer: No such file or directory | 06:52 |
| mvo | zyga-ubuntu: 2.27.6 should be in proposed, also via core re-exec | 06:54 |
| mvo | zyga-ubuntu: what failure on trusty is that, is there a forum post? | 06:54 |
| zyga-ubuntu | mvo: it's this bug https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1722075 | 07:03 |
| mup | Bug #1722075: package snapd 2.27.6~14.04 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 <amd64> <apport-package> <package-from-proposed> <zesty> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1722075> | 07:03 |
| zyga-ubuntu | mvo: but I think it's weirder than I initially thought | 07:03 |
| === JanC is now known as Guest86327 | ||
| === JanC_ is now known as JanC | ||
| mup | PR snapd#4019 closed: release: snapd 2.28.2 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4019> | 07:05 |
| mvo | zyga-ubuntu: is it 2.28.3 material? i.e. should I hold back this release? | 07:07 |
| zyga-ubuntu | mvo: no, I think it's not meant to work | 07:09 |
| zyga-ubuntu | mvo: but I'm still looking | 07:09 |
| zyga-ubuntu | mvo: 17.04 system (upgrade from 16.10) with 14.04 package | 07:10 |
| mvo | zyga-ubuntu: thanks for investigating | 07:13 |
| mup | PR snapd#4020 opened: tests: add test for lxd interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/4020> | 07:15 |
| mwhudson | __chip__: my snapcraft pr is only about half way down the list, they must be slacker than you guys :) | 07:17 |
| mwhudson | zyga-ubuntu: so um i guess we should package 2.28.2 for debian? | 07:17 |
| zyga-ubuntu | mwhudson: yes, I think so | 07:20 |
| zyga-ubuntu | mwhudson: btw, interesting observation | 07:20 |
| zyga-ubuntu | mwhudson: recent 9.2 stable release of debian had brand new flatpak | 07:20 |
| zyga-ubuntu | mwhudson: perhaps we could do the same | 07:20 |
| mwhudson | zyga-ubuntu: good thing i don't have anything at all to do between now and artful release, eh? | 07:20 |
| mwhudson | zyga-ubuntu: hmm | 07:20 |
| mwhudson | zyga-ubuntu: although 2.28 should work ok via reexec thanks to the graceful apparmor stuff you did | 07:21 |
| zyga-ubuntu | mwhudson: I need to fix my VM box (reinstall the OS on new drive and then copy data over) | 07:21 |
| zyga-ubuntu | mwhudson: yep but we could try to get it into 9.3, if there is one | 07:21 |
| zyga-ubuntu | mwhudson: we could pick the right stable release and go along with it | 07:21 |
| mwhudson | yeah that'd be good | 07:22 |
| zyga-ubuntu | hmm, has the new snap pack landed? | 07:24 |
| * zyga-ubuntu looks | 07:24 | |
| kalikiana | o/ | 07:35 |
| mup | PR snapd#4015 closed: run-checks: use nakedret to check for naked returns on long functions <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4015> | 07:38 |
| mup | Issue snapcraft#1604 opened: Homebrew still on snapcraft 2.33 <Created by jedvardsson> <https://github.com/snapcore/snapcraft/issue/1604> | 07:40 |
| zyga-ubuntu | homebrew? | 07:41 |
| zyga-ubuntu | wow | 07:41 |
| zyga-ubuntu | and mup is still using wrong URLs for github issues | 07:41 |
| __chip__ | zyga-ubuntu: snap pack is on master, if that's your q | 07:42 |
| zyga-ubuntu | yep, that's what I wanted, thank you | 07:45 |
| mup | Issue snapcraft#1605 opened: lib* files in $SNAP/usr/lib/ links to /usr/lib/ <Created by wmmihaa> <https://github.com/snapcore/snapcraft/issue/1605> | 07:55 |
| mvo | cachio: good morning. we have a new 2.28.3 that fixes an issue with the lxd interface in the beta channel | 07:58 |
| mup | PR snapd#4021 opened: release: snapd 2.28.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4021> | 08:00 |
| * zyga-ubuntu -> tea | 08:14 | |
| zyga-ubuntu | spread test for content looks good; I fixed some issues and found one missing case that is now handled (source bind mount) | 08:14 |
| zyga-ubuntu | oh, chipaca is gone? | 08:17 |
| zyga-ubuntu | jdstrand: hello | 08:43 |
| zyga-ubuntu | jdstrand: not sure if you are up yet but I'd like to review and land https://github.com/snapcore/snapd/pull/3965 | 08:44 |
| mup | PR #3965: interfaces/mount: add support for parsing x-snapd.{mode,uid,gid}= <Created by zyga> <https://github.com/snapcore/snapd/pull/3965> | 08:44 |
| zyga-ubuntu | jdstrand: it has one +1 already and I could use a review from you next | 08:44 |
| Chipaca | pedronis: are you really around? | 09:11 |
| Chipaca | i guess it's early even if he were | 09:12 |
| zyga-ubuntu | Chipaca: o/ | 09:22 |
| zyga-ubuntu | thank you for the response on the froum | 09:22 |
| zyga-ubuntu | how are you feeling | 09:22 |
| Chipaca | zyga-ubuntu: better today, thank you | 09:23 |
| Chipaca | i'll be off to physio in a bit, that also helps | 09:24 |
| mup | PR snapcraft#1606 opened: kbuild plugin: if the parts build dir already contains a .config file, use it as the base config <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1606> | 09:28 |
| Chipaca | ok, off to physio | 09:42 |
| mup | Issue snapcraft#1604 closed: Homebrew still on snapcraft 2.33 <Created by jedvardsson> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/issue/1604> | 10:16 |
| ackk | it seems my snap is not able to resolve hostnames, but it has the 'network' interface (and it's connected). how can I debug what's going on? | 10:19 |
| mup | Issue snapcraft#1605 closed: lib* files in $SNAP/usr/lib/ links to /usr/lib/ <Created by wmmihaa> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/issue/1605> | 10:19 |
| kalikiana | ackk: I find running it in devmode helpful in case something's being blocked by apparmor because you'll get log messages | 10:31 |
| ackk | kalikiana, so, it seems it's trying to access stuff under hostfs, like resolv.conf or os-release | 10:31 |
| ackk | but it shouldn't really need that | 10:31 |
| ackk | I mean, having the "network" plug it should have connectivity? | 10:32 |
| popey | As a user, I have a snap which I think broke in 2.28. To confirm, how do I easily go back to core 2.27? | 10:32 |
| kalikiana | popey: `snap revert` gets you back to the previous revision, you can also do `snap revert core --revision=2925` for a specific one, but afair it must be one of the last three you had on your system | 10:35 |
| zyga-ubuntu | popey: can you share more information | 10:35 |
| popey | hiri is broken on my nvidia laptop | 10:35 |
| popey | works on my intel laptop | 10:35 |
| popey | it _used_ to work | 10:35 |
| popey | I am trying to figure out if hiri broke their snap or we did | 10:35 |
| kalikiana | ackk: Yes. Probably something's trying to be smart. Although /etc/os-release should be accessible just fine, other things may be blocked | 10:36 |
| zyga-ubuntu | popey: can you show any apparmor denials | 10:36 |
| zyga-ubuntu | popey: and confirm that it works on 2.27.x | 10:37 |
| popey | uh | 10:37 |
| popey | https://forum.snapcraft.io/t/apparmor-denials-for-hiri-after-updates/2432 | 10:37 |
| zyga-ubuntu | popey: also can you run hiri from command line with SNAP_CONFINE_DEBUG=yes | 10:37 |
| popey | I asked how I can go back to 2.27 :D | 10:37 |
| ackk | kalikiana, I see stuff like Oct 11 10:36:48 snap kernel: [2414545.321369] audit: type=1400 audit(1507718208.501:1586): apparmor="DENIED" operation="open" profile="snap.lxd.lxc" name="/var/lib/snapd/hostfs/etc/nsswitch.conf" pid=5797 comm="lxc" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 | 10:37 |
| zyga-ubuntu | ah, wait | 10:37 |
| popey | Tell me that and I will :) | 10:37 |
| ackk | kalikiana, I doubt lxc is opening that file explicitely | 10:37 |
| zyga-ubuntu | popey: that's all I need | 10:37 |
| zyga-ubuntu | thank you | 10:37 |
| mup | PR snapd#4021 closed: release: snapd 2.28.3 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4021> | 10:39 |
| kalikiana | ackk: does lxd have no network? if that's the case you might want to `snap disable lxd; snap enable lxd`. I've seen it some time ago and that was my work-around | 10:40 |
| zyga-ubuntu | popey: can you please help me out | 10:41 |
| zyga-ubuntu | popey: I need you to do this: | 10:41 |
| kalikiana | ackk: and, put those logs in a bug report ideally | 10:41 |
| zyga-ubuntu | popey: sudo /usr/lib/snapd snap-discard-ns hiri # (correct the snap name if needed) | 10:41 |
| ackk | kalikiana, disable/enable didn't work | 10:42 |
| ackk | kalikiana, the snap has the network plug connected | 10:42 |
| zyga-ubuntu | popey: SNAP_CONFINE_DEBUG=yes snap run --shell hiri | 10:42 |
| ackk | kalikiana, lxd does have network, lxc doesn't seem to | 10:43 |
| popey | alan@hal:~$ sudo /usr/lib/snapd snap-discard-ns hiri | 10:43 |
| popey | sudo: /usr/lib/snapd: command not found | 10:43 |
| zyga-ubuntu | popey: sudo SNAP_NAME=hiri strace /snap/core/current/usr/lib/snapd/snap-confine snap.hiri.hiri -o snap-confine.strace | 10:43 |
| ackk | kalikiana, but lxd runs unconfined | 10:43 |
| zyga-ubuntu | popey: popey sorry, /usr/lib/snapd/snap-discard-ns hiri | 10:43 |
| zyga-ubuntu | (missing /) | 10:43 |
| popey | kk | 10:43 |
| kalikiana | ackk: I'm not following... `lxc` is just the command line tool of lxd. What exactly is not working? | 10:43 |
| ackk | kalikiana, if I run lxc image list ubuntu: | 10:43 |
| zyga-ubuntu | popey: snap-confine should never access /sys/module/nvidia_modeset/uevent so I'm curious what is going on | 10:44 |
| ackk | kalikiana, that fetches the simplestreams index from the image server. that fails | 10:44 |
| zyga-ubuntu | popey: also paste snap version here (I only care about the distrO) | 10:44 |
| ackk | kalikiana, a curl of the same url from cmdline of course works | 10:44 |
| popey | zyga-ubuntu: hang on | 10:44 |
| kalikiana | ackk: Can you tr `lxc image list --debug --verbose ubuntu:` and see if it gives some diagnostics? | 10:45 |
| popey | http://paste.ubuntu.com/25719311/ | 10:45 |
| popey | alan@hal:~$ snap version | 10:46 |
| popey | snap 2.28.1 | 10:46 |
| popey | snapd 2.28.1 | 10:46 |
| popey | series 16 | 10:46 |
| popey | ubuntu 16.04 | 10:46 |
| popey | kernel 4.10.0-35-generic | 10:46 |
| popey | zyga-ubuntu: ^ What next? | 10:49 |
| ackk | kalikiana, just the same error: Get https://cloud-images.ubuntu.com/releases/streams/v1/index.json: lookup cloud-images.ubuntu.com: no such host | 10:49 |
| elopio | snappy-m-o autopkgtest 1603 xenial:amd64 xenial:armhf xenial:arm64 artful:amd64 zesty:arm64 | 10:51 |
| snappy-m-o | elopio: I've just triggered your test. | 10:51 |
| elopio | snappy-m-o autopkgtest 1602 xenial:amd64 xenial:armhf zesty:amd64 | 10:52 |
| snappy-m-o | elopio: I've just triggered your test. | 10:52 |
| zyga-solus | popey: please exit the shell | 10:56 |
| zyga-solus | popey: and run strace command again outside | 10:56 |
| popey | ok | 10:56 |
| zyga-solus | sorry for the confusing input | 10:56 |
| * zyga-solus fixed his T430 just now | 10:56 | |
| popey | zyga-solus: are you expecting an strace file, because I have none, just spat to terminal | 10:57 |
| popey | zyga-solus: http://paste.ubuntu.com/25719391/ | 10:57 |
| zyga-solus | popey: perhaps put -o just after strace | 10:57 |
| zyga-solus | but let me read this | 10:58 |
| kalikiana | ackk: Maybe ask in #lxc-dev I'm running out of ideas | 10:59 |
| ackk | kalikiana, ok, thanks | 10:59 |
| zyga-solus | popey: sudo SNAP_NAME=hiri strace -f -o snap-confine.strace /snap/core/current/usr/lib/snapd/snap-confine snap.hiri.hiri /snap/core/current/usr/lib/snapd/snap-exec hiri.hiri | 11:01 |
| * zyga-solus is walking in the dark here but let's keep our minds open | 11:01 | |
| popey | zyga-solus: http://paste.ubuntu.com/25719424/ | 11:05 |
| zyga-ubuntu | oooh | 11:06 |
| * zyga-ubuntu found a bug | 11:06 | |
| zyga-ubuntu | (elsewhere) | 11:06 |
| zyga-ubuntu | *man* | 11:06 |
| zyga-ubuntu | popey: when you ran this, did you see any denial? | 11:08 |
| popey | zyga-ubuntu: [Wed Oct 11 12:11:09 2017] audit: type=1400 audit(1507720265.562:197783): apparmor="DENIED" operation="file_mmap" profile="snap.hiri.hiri" name="/snap/core/3017/usr/lib/snapd/snap-exec" pid=26893 comm="snap-exec" requested_mask="rm" denied_mask="rm" fsuid=0 ouid=0 | 11:11 |
| popey | thats the only denial when i re-ran your strace above | 11:11 |
| zyga-ubuntu | hmmm, that's weird | 11:11 |
| zyga-ubuntu | it says that the profile disallows running snap-exec | 11:12 |
| zyga-ubuntu | ah | 11:12 |
| zyga-ubuntu | sorry | 11:12 |
| zyga-ubuntu | ok | 11:12 |
| zyga-ubuntu | re-run that with snap-exec path of just /usr/lib/snapd/snap-exec | 11:12 |
| zyga-ubuntu | (so everything the same but with different command at the end | 11:13 |
| popey | cannot snap-exec: cannot parse revision "": invalid snap revision: "" | 11:13 |
| popey | alan@hal:~$ sudo SNAP_NAME=hiri strace -f -o snap-confine.strace /snap/core/current/usr/lib/snapd/snap-confine snap.hiri.hiri /usr/lib/snapd/snap-exec hiri.hiri | 11:13 |
| popey | ^ was the command | 11:13 |
| zyga-ubuntu | right | 11:13 |
| zyga-ubuntu | after sudo add SNAP_REVISION=... where ... is the real revision of hiri | 11:14 |
| zyga-ubuntu | (little by little) | 11:14 |
| popey | ok | 11:14 |
| popey | alan@hal:~$ sudo SNAP_REVISION=15 SNAP_NAME=hiri strace -f -o snap-confine.strace /snap/core/current/usr/lib/snapd/snap-confine snap.hiri.hiri /usr/lib/snapd/snap-exec hiri.hiri | 11:15 |
| popey | seems to be just sat there | 11:15 |
| zyga-ubuntu | look at denials please | 11:15 |
| popey | nothing | 11:15 |
| Chipaca | zyga-ubuntu: what does snap-confine.strace do? | 11:16 |
| zyga-ubuntu | it's just a file name | 11:16 |
| Chipaca | d'oh | 11:17 |
| Chipaca | so, jd.strand shared a magic strace of magics | 11:17 |
| Chipaca | strace -o /tmp/trace -D -f -vv -e '!_newselect,select,clock_gettime' -- /usr/bin/snap run <thing> | 11:17 |
| Chipaca | the filtered-out thing is the important bit imho | 11:18 |
| zyga-ubuntu | popey: ls -ld /sys/module/nvidia/version | 11:18 |
| Chipaca | without that strace gets bamboozled by go | 11:18 |
| Chipaca | (or by our unusual usage of go) | 11:18 |
| popey | -r--r--r-- 1 root root 4096 Oct 2 20:44 /sys/module/nvidia/version | 11:18 |
| zyga-ubuntu | popey: ok | 11:18 |
| zyga-ubuntu | I'm lost | 11:18 |
| zyga-ubuntu | snap list --all | 11:18 |
| zyga-ubuntu | popey: and please revert to one of the older core revisions you have on your system (the previous one) | 11:19 |
| zyga-ubuntu | popey: then discard the namespace and try again | 11:19 |
| popey | https://pastebin.canonical.com/200343/ is my snap list --all | 11:19 |
| popey | (sorry, contains private snaps so not publicly sharing) | 11:20 |
| zyga-ubuntu | kk | 11:20 |
| popey | so core 2898 which is 16-2.27.6 i guess? | 11:20 |
| Chipaca | popey: don't forget to stand on the _left_ side of your _right_ foot while reverting, and the order is: adopt stance, start whistling tune, execute commands, leave stance, stop whistling | 11:20 |
| popey | <3 | 11:21 |
| zyga-ubuntu | popey: core 16-2.27.6 2844 canonical core,disabled | 11:21 |
| zyga-ubuntu | popey: try tihs one | 11:21 |
| zyga-ubuntu | popey: actually | 11:21 |
| zyga-ubuntu | before you do that | 11:21 |
| zyga-ubuntu | popey: try Chipaca's advice on how to strace | 11:22 |
| Chipaca | need i mention that the tune is rms's free software tune, backwards and in a minor key? | 11:22 |
| flexiondotorg | zyga-ubuntu: popey is reverting to 2898. | 11:22 |
| flexiondotorg | His irc client is a snap and froze. Which is why he is not replying right now. | 11:23 |
| popey | phew! | 11:23 |
| * Chipaca ROTBL | 11:23 | |
| * flexiondotorg end popey-proxy mode | 11:23 | |
| popey | ok, interestingly my irc clent (irccloud-desktop) locked up during 'phase 2' whatever that is, but carried on after the rollback which is neat. well done team :) | 11:24 |
| popey | installed: 16-2.27.6 (2898) 85MB core | 11:24 |
| zyga-ubuntu | flexiondotorg: interesting! | 11:25 |
| popey | Ok, hiri now works fine atfer rolling back to 2.27 | 11:25 |
| zyga-ubuntu | popey: try hhir now | 11:25 |
| zyga-ubuntu | popey: ok | 11:25 |
| zyga-ubuntu | popey: please do this: | 11:25 |
| zyga-ubuntu | popey: send me all the apparmor profiles from /etc/apparmor.d/snap.core.*.usr.lib.snapd.snap-confine | 11:25 |
| popey | zyga-ubuntu: sent | 11:27 |
| popey | (email) | 11:28 |
| zyga-solus | thanks | 11:28 |
| zyga-solus | let me look | 11:28 |
| * zyga-solus walks between kitchen and office | 11:28 | |
| zyga-ubuntu | popey: ok so the working one is 2898 | 11:30 |
| * zyga-ubuntu looks | 11:30 | |
| zyga-ubuntu | popey: it makes no sense :/ it looks like the new profile is more forgiving actually | 11:33 |
| popey | zyga-ubuntu: we have confirmed that this is also the case with a completely different snap, on another nvidia machine which is 17.10 | 11:36 |
| popey | reverting to core 2898 made the snap work there too. | 11:36 |
| zyga-solus | popey: it looks like nvidia is affected in general | 11:36 |
| popey | also an opengl snap | 11:36 |
| zyga-solus | not specific to hiri | 11:36 |
| popey | yes | 11:36 |
| zyga-solus | now would be a good time for me to have easy way to use nvidia :/ | 11:36 |
| zyga-solus | (which I don't) | 11:36 |
| popey | This is not the first time this problem has bitten us. | 11:36 |
| zyga-solus | I understand, we don't have any testing of nvidia AFAIK | 11:37 |
| popey | Indeed, wasn't pointed at you. It's common across the company. | 11:37 |
| zyga-solus | I meant me for debugging, I think we need to fix our release process to include simple "works / not works" opengl testing on intel, nvidia and amd GPUs | 11:37 |
| popey | I happen to be lucky enough to have two laptops side by side, nvidia and intel, so pick this stuff up. Not everyone has that luxury | 11:38 |
| zyga-solus | or just nvidia for a start | 11:38 |
| zyga-solus | popey: I have 3 but all intel | 11:38 |
| popey | I understand you can spin up a machine in AWS with a GPU | 11:38 |
| popey | There's your problem :) | 11:38 |
| zyga-solus | popey: with ubuntu kernel? | 11:38 |
| popey | Hm, good question. I am not sure. | 11:38 |
| zyga-solus | probably not | 11:38 |
| * zyga-solus looks on ebay | 11:38 | |
| popey | separately, will I be stuck on rev 2898 now I reverted to it? | 11:39 |
| popey | or will the next update push me forward again? | 11:39 |
| zyga-solus | popey: not sure, I think refresh vs revert but not sure if this is implemented | 11:40 |
| popey | Shall I file a bug in snapd for this? | 11:41 |
| popey | Feels somewhat critical | 11:41 |
| zyga-solus | popey: no, the forum thread is enough | 11:41 |
| popey | ok | 11:41 |
| popey | zyga-solus: do you need remote access to an nvidia machine (I have a desktop here I can slap 16.04 on)? | 11:45 |
| zyga-solus | popey: that wold help | 11:45 |
| popey | lemme dig it out, one mo | 11:46 |
| zyga-solus | popey: thank you | 11:46 |
| zyga-ubuntu | mvo: what is the status of your nvidia box? | 11:47 |
| zyga-ubuntu | mvo: I have a laptop but unused, I could try to boot it from live media or maybe swap HDD and install that way (it's not used by me and has other os) | 11:47 |
| mvo | zyga-ubuntu: I have a nvidia card somewhere I don't use it usually, but I can plug it in | 11:47 |
| zyga-ubuntu | mvo: if that fails I'll try to install ubuntu on mine | 11:48 |
| mvo | zyga-ubuntu: let me try to find it, any opengl game will do? | 11:49 |
| zyga-solus | mvo: yes | 11:49 |
| zyga-solus | mvo: or just try hiri | 11:49 |
| mvo | zyga-ubuntu: what did change in this area recently? could it be snap-confine? | 11:50 |
| zyga-solus | mvo: I was looking at the diff between the snap-confine profiles and we did change various things for how the lib directory is called in solus and elsewhere | 11:50 |
| zyga-solus | mvo: but we never ever touch the file we get the denial on | 11:50 |
| zyga-solus | mvo: so I think something else may be broken | 11:50 |
| zyga-solus | mvo: and we just see the weird side effect | 11:51 |
| mvo | zyga-solus: I see - I wonder how we can test this in an integration test | 11:51 |
| zyga-solus | mvo: modprobe nvidia (maybe) if it sticks | 11:51 |
| mvo | zyga-ubuntu: what file gets the denials | 11:51 |
| zyga-solus | [ 2879.277628] audit: type=1400 audit(1507710260.432:1680): apparmor=“DENIED” operation=“open” profile="/snap/core/3017/usr/lib/snapd/snap-confine" name="/sys/bus/pci/drivers/nvidia/uevent" pid=13789 comm=“snap-confine” requested_mask=“r” denied_mask=“r” fsuid=0 ouid=0 | 11:52 |
| zyga-solus | not sure how this happens | 11:53 |
| zyga-solus | hold on, I think I know | 11:53 |
| zyga-solus | jdstrand said that nvidia is not in sysfs the regular way and added a hack for supporting udev tagging, remember? | 11:54 |
| zyga-solus | one sec | 11:54 |
| zyga-solus | b17d5ba8d46c269dbaba08c0484a13e1e1c9e9e7 | 11:55 |
| zyga-solus | mvo: it is this patch | 11:56 |
| mvo | zyga-solus: strange that denial, I add the card now, bbiab (need to open the machine etc) | 11:56 |
| * Chipaca needs to reboot, brb | 11:56 | |
| zyga-solus | k | 11:56 |
| zyga-solus | mvo: I'm making a patch | 11:57 |
| zyga-solus | popey: still there? | 11:59 |
| zyga-solus | popey: refresh to stable again | 11:59 |
| popey | ok | 11:59 |
| zyga-solus | popey: and edit the profile in /etc/apparmor.d/ | 11:59 |
| zyga-solus | popey: the one for snap-confine on revision 3017 (if I recall correctly) | 12:00 |
| zyga-solus | anyway, the latest one | 12:00 |
| zyga-solus | popey: ls /sys/bus/pci/drivers/nvidia/ | 12:01 |
| zyga-solus | popey: in the file you are editing go to line 6 (so inside the { } spanning the whole file) | 12:02 |
| zyga-solus | popey: and add this line(s) (waiting for your ls output) | 12:02 |
| zyga-solus | popey: /sys/bus/pci/drivers/nvidia/uevent r, | 12:03 |
| zyga-solus | popey: then save the file and use "apparmor_parser -r /etc/apparmor.d/snap.core.3017.usr.lib.snapd.snap-confine" to re-load | 12:03 |
| zyga-solus | popey: then start hiri again | 12:03 |
| popey | ok. took a while to get to refresh core. updated now | 12:03 |
| zyga-ubuntu | popey: thank you | 12:03 |
| popey | alan@hal:~$ ls /sys/bus/pci/drivers/nvidia/ | 12:05 |
| popey | 0000:01:00.0 bind module new_id remove_id uevent unbind | 12:05 |
| zyga-ubuntu | ok | 12:05 |
| zyga-ubuntu | add the uevent line as I said, reload the profile and start hiri | 12:06 |
| zyga-ubuntu | we'll iterate till it works | 12:06 |
| popey | ok | 12:06 |
| popey | so added that one uevent r line | 12:06 |
| popey | hiri still core dumps | 12:07 |
| zyga-solus | denials? | 12:08 |
| popey | [Wed Oct 11 13:09:07 2017] audit: type=1400 audit(1507723743.250:198339): apparmor="DENIED" operation="open" profile="snap.hiri.hiri" name="/proc/17939/mounts" pid=17939 comm="hirimain" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 | 12:09 |
| popey | [Wed Oct 11 13:09:09 2017] audit: type=1400 audit(1507723744.825:198340): apparmor="DENIED" operation="open" profile="snap.hiri.hiri" name="/etc/" pid=17939 comm="hirimain" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 | 12:09 |
| popey | [Wed Oct 11 13:09:09 2017] audit: type=1400 audit(1507723744.833:198341): apparmor="DENIED" operation="open" profile="snap.hiri.hiri" name="/proc/17953/mounts" pid=17953 comm="hirimain" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 | 12:09 |
| popey | [Wed Oct 11 13:09:09 2017] audit: type=1400 audit(1507723744.837:198342): apparmor="DENIED" operation="open" profile="snap.hiri.hiri" name="/proc/17954/mounts" pid=17954 comm="hirimain" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 | 12:09 |
| zyga-solus | nothing else? can you connect the mount interfaces | 12:09 |
| * ogra_ sets +q on popeybot | 12:09 | |
| ogra_ | :P | 12:09 |
| zyga-solus | or try a some simple opengl snap/ | 12:09 |
| popey | i have another gl one that broke | 12:10 |
| popey | https://www.irccloud.com/pastebin/saHHCGu4/ | 12:10 |
| popey | (for ogra) | 12:10 |
| ogra_ | heh | 12:10 |
| popey | https://www.irccloud.com/pastebin/1NEBw33c/ | 12:11 |
| popey | and another | 12:11 |
| ogra_ | you can ignoe inet6 | 12:11 |
| zyga-ubuntu | popey: works? | 12:11 |
| popey | no | 12:11 |
| popey | all broken | 12:11 |
| popey | https://www.irccloud.com/pastebin/FZfuNsJx/ | 12:12 |
| ogra_ | (and we shoudl really quieten it, they should not be printed if there is no v6 network configured) | 12:12 |
| zyga-ubuntu | ok | 12:12 |
| mvo | zyga-solus: \o/ for making a patch, let me know once I can test something | 12:12 |
| zyga-ubuntu | mvo: still at the /o\ stage, I need to wrap my head around this, I assumed a simple tweak would do but I think we tag things incorrectly somewhere and there are devices missing in the namespace | 12:12 |
| zyga-ubuntu | mvo: so no patch yet | 12:13 |
| zyga-solus | popey: can you try a richer patch please | 12:18 |
| zyga-solus | + # See https://github.com/snapcore/snapd/commit/b17d5ba8d46c269dbaba08c0484a13e1e1c9e9e7 | 12:18 |
| zyga-solus | + /sys/bus/pci/drivers/nvidia/uevent r, | 12:18 |
| zyga-solus | + /dev/nvidia[0-9]* r, | 12:18 |
| zyga-solus | + /dev/nvidiactl r, | 12:18 |
| zyga-solus | + /dev/nvidia-uvm r, | 12:18 |
| zyga-solus | popey: reload the profile and watch journalctl -f | 12:19 |
| zyga-solus | popey: then restart hiri | 12:19 |
| Chipaca | what was the generic name, on the phone, of things that mediated access to things? like the file manager | 12:19 |
| zyga-solus | Chipaca: media hub | 12:19 |
| ogra_ | Chipaca, content-hub | 12:19 |
| popey | ok | 12:19 |
| zyga-solus | ah | 12:19 |
| zyga-solus | sorry :) | 12:19 |
| ogra_ | but media-hub was clöose enough ;) (same thing. just for media files) | 12:20 |
| Chipaca | right, the content hub was one of them, wasn't there a name for all of them? | 12:20 |
| zyga-solus | trusted helper? | 12:20 |
| ogra_ | trusted helper was the equivalent to snap intefaces | 12:20 |
| zyga-solus | well, not really | 12:20 |
| zyga-solus | we will use trusted helpers in snapd (we already use some) | 12:21 |
| popey | still broken.. | 12:21 |
| ogra_ | (to allow direct accesds to bits ... like location or so) | 12:21 |
| zyga-solus | anyway, distraction | 12:21 |
| zyga-solus | popey: any denials? | 12:21 |
| zyga-solus | did you reload the profile? | 12:21 |
| zyga-solus | popey: try discarding the namespace (just to be sure, I don't think we need to) | 12:21 |
| popey | http://paste.ubuntu.com/25719780/ | 12:21 |
| popey | i did reload the profile | 12:21 |
| popey | ^ me running hiri, goxel and ohmygiraffe | 12:22 |
| popey | tried discarding namespace too, also fails | 12:23 |
| zyga-solus | popey: go to /sys/fs/cgroup/devices | 12:25 |
| zyga-solus | popey: what do you have there | 12:26 |
| popey | lots of files, anything in particular you're interested in? | 12:27 |
| zyga-solus | popey: snap.* | 12:27 |
| popey | http://paste.ubuntu.com/25719806/ | 12:27 |
| zyga-solus | great | 12:28 |
| zyga-solus | go to hiri | 12:28 |
| zyga-solus | then show devices.allow please | 12:28 |
| popey | it's an empty file | 12:30 |
| popey | --w------- 1 root alan 0 Oct 11 13:23 devices.allow | 12:30 |
| zyga-solus | cat it | 12:30 |
| popey | alan@hal:/sys/fs/cgroup/devices/snap.hiri.hiri$ sudo cat devices.allow | 12:30 |
| popey | cat: devices.allow: Invalid argument | 12:30 |
| zyga-solus | aww, drat | 12:31 |
| zyga-solus | ok, one sec | 12:31 |
| zyga-solus | darn | 12:31 |
| zyga-solus | we don't log that | 12:31 |
| zyga-solus | so | 12:31 |
| zyga-solus | it's the oldest part of snap-confine | 12:31 |
| zyga-solus | and one I barley touched | 12:31 |
| zyga-solus | so it doesn't log anything useful | 12:31 |
| zyga-solus | I'm afraid we need some build/edit cycles | 12:33 |
| Chipaca | is this something breaking in 2.28, or is it broken before that? | 12:34 |
| popey | am installing 17.10 on an nvidia machine here for you if that helps | 12:34 |
| zyga-solus | Chipaca: 2.28 | 12:34 |
| Chipaca | zyga-solus: is it a blocker? | 12:34 |
| zyga-solus | popey: yes, very much | 12:34 |
| zyga-solus | Chipaca: yes | 12:34 |
| Chipaca | zyga-solus: am I sad? | 12:34 |
| * Chipaca is sad | 12:34 | |
| Chipaca | popey: thank you for spotting it though | 12:35 |
| popey | np | 12:35 |
| Chipaca | zyga-solus: what aren't we testing? | 12:35 |
| Chipaca | do we need to have an nvidia 16.04 box as part of qa? | 12:35 |
| zyga-solus | Chipaca: absolutely | 12:36 |
| Chipaca | ok | 12:36 |
| Chipaca | how do we do this? | 12:36 |
| zyga-solus | Chipaca: I'd just make sure that cachio has a nvidia box to test on | 12:38 |
| zyga-solus | Chipaca: and then try external target | 12:39 |
| Chipaca | cachio: you're about to become a gamer dude | 12:39 |
| zyga-solus | Chipaca: and ensure we run opengl snaps as a part of that | 12:39 |
| Chipaca | :-D | 12:39 |
| popey | (don't forget AMD) :) | 12:39 |
| * Chipaca forgets AMD because it sucks | 12:39 | |
| * Chipaca looks for a fight | 12:39 | |
| zyga-solus | popey: we have no amd-specific code | 12:39 |
| popey | shocked emoji | 12:39 |
| * Chipaca stops looking for a fight and starts looking for tea | 12:39 | |
| * zyga-solus is starving, I need to break for food now | 12:39 | |
| mvo | zyga-solus: took a little bit, had to tweaks various things in artful and had the wrong nvidia driver (how is a user supposed to know twhich of nvidia-NNN he/she needs?). anyways, I can test things now too | 12:46 |
| zyga-ubuntu | mvo: I think the driver package makes that | 12:47 |
| zyga-ubuntu | mvo: did you install the proprietary driver? | 12:47 |
| * kalikiana moving to a coffee shop, back in a bit | 12:48 | |
| zyga-ubuntu | mvo: I'd like to know which devices are in the cgroup | 12:48 |
| zyga-ubuntu | popey: can you cat devices.list | 12:49 |
| zyga-ubuntu | popey: on your existing machine | 12:49 |
| popey | yes | 12:49 |
| popey | http://paste.ubuntu.com/25719909/ | 12:49 |
| zyga-ubuntu | popey: so | 12:50 |
| zyga-ubuntu | popey: it looks like we don't do nvidia part correctly | 12:50 |
| zyga-ubuntu | nvidia is 195 | 12:51 |
| zyga-ubuntu | I'll update the forum | 12:51 |
| zyga-ubuntu | popey: what do you have in "ls -l /dev/nvidia*" | 12:55 |
| zyga-ubuntu | popey: we may be able to test a fix on your system with some shell | 12:55 |
| popey | https://www.irccloud.com/pastebin/AindIubf/ | 12:55 |
| popey | i have a desktop machine here ready for you | 12:55 |
| popey | pm... | 12:55 |
| zyga-ubuntu | popey: ok, let me ssh in and play, | 12:58 |
| zyga-ubuntu | popey: but I see what is broken | 12:58 |
| zyga-ubuntu | not sure why yet | 12:58 |
| popey | kk | 12:58 |
| popey | needs an update, so apt dist upgrade while you do other things :) | 12:58 |
| * popey gets quick bite to eat | 13:04 | |
| popey | will listen out for pings | 13:04 |
| tai271828 | hi, question: do we have kernel snap that is corresponding to "proposed kernel"? especially for pi2 kernel. may anyone know and please tell me the answer? (googled "pi2 kernel snap" and I think the answer is "no") | 13:07 |
| ogra_ | tai271828, proposed as in the proposed deb archive ? | 13:08 |
| tai271828 | ogra_: yes, and I just found this https://launchpad.net/pi2-kernel-snap | 13:08 |
| ogra_ | tai271828, the beta and candidate channels get uploads in sync with the proposed deb | 13:08 |
| tai271828 | ogra_: hmmm, cool, then I must misunderstand something, thanks for clarifying | 13:09 |
| tai271828 | ogra_: thanks! | 13:09 |
| ogra_ | tai271828, note that the pi2 kernel in stable is actually stuck due to the missing ability to upgrade gadgets on devices ... typically the snaps woould move on from beta/candidate to stable (but without working gadget upgades they wouldnt boot, the binary blobs are to old in the stable gadget currently) | 13:11 |
| tai271828 | ogra_: got it, thanks for the useful information. | 13:12 |
| ogra_ | :) | 13:12 |
| === ikey|zzz is now known as ikey | ||
| mup | PR snapd#4022 opened: interfaces/opengl: don't udev tag nvidia devices and use snap-confine instead (2.28) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4022> | 13:35 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| slangasek | hi, what has changed between core snap 2898 and core snap 3017? Because this has broken the subiquity server image, /var/lib/snapd/seed doesn't seem to get processed correctly at boot and so subiquity doesn't start | 13:41 |
| mvo | slangasek: there were quite a few changes, do you have more details in what way things break? what can I do to reproduce? | 13:42 |
| slangasek | mvo: you can download and boot http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/artful-live-amd64.iso | 13:43 |
| mvo | slangasek: thanks, downloading now | 13:43 |
| slangasek | mvo: the only thing visible in the systemd journal is that snap-confine can't find libudev.so.1 | 13:43 |
| mvo | slangasek: any denials in dmesg? | 13:45 |
| ogra_ | mvo, systemd from the PPA out of sync with the distro llibudev ? | 13:45 |
| slangasek | mvo: apparmor="DENIED" on /rofs/etc/ld.so.cache | 13:45 |
| ogra_ | wow, where would /rofs come from ? | 13:46 |
| slangasek | it's a live image | 13:46 |
| ogra_ | ah | 13:46 |
| slangasek | so root is an overlayfs + squashfs | 13:46 |
| slangasek | and the real path is not the apparent path | 13:46 |
| slangasek | so I guess one of the changes was to confine snap-confine itself? | 13:46 |
| slangasek | mwhudson: ^^ so, that's what's going on with the latest image | 13:47 |
| mvo | slangasek: we always had snap-confine confined | 13:47 |
| ogra_ | we do have a patch to systemd in the PPA that makes the core snap have a differentlly versioned libudev package thoough | 13:48 |
| ogra_ | mvo, that should have gone into a live-build hook instead i guess | 13:49 |
| ogra_ | (til the actual systemd SRU lands) | 13:50 |
| slangasek | oh | 13:50 |
| ogra_ | https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial | 13:50 |
| slangasek | indeed, there's also a denial for /rofs/lib/x86_64-linux-gnu/libudev.so.1.6.6 | 13:50 |
| slangasek | which is probably the real one | 13:50 |
| slangasek | so, should we be extending the apparmor profile to account for /rofs as a special case? | 13:53 |
| ogra_ | given that the fix is actually something that should rather live in /etc/sysctl.d, we shoulld probably just rework it to come either via a llive-build hook or via ubuntu-coe-config | 13:53 |
| ogra_ | oh | 13:53 |
| ogra_ | that perhaps as well :) | 13:53 |
| slangasek | jdstrand: ^^ ping | 13:53 |
| zyga-ubuntu | popey: I rebooted your machine, let's hope it re-connects | 13:54 |
| popey | i see black screen | 13:54 |
| popey | with a mouse cursor | 13:54 |
| popey | (It could just be slow) | 13:54 |
| popey | it's back, desktop up | 13:55 |
| mvo | ogra_: that systemd package can be removed from the ppa | 13:55 |
| mvo | ogra_: let me kill it now | 13:55 |
| ogra_ | +1 | 13:55 |
| kalikiana | sliff | 13:55 |
| mvo | ogra_: the actual fix is in the core build git | 13:56 |
| mup | PR snapd#4023 opened: tests: fix econnreset scenario when the iptables rule was not created <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4023> | 13:56 |
| ogra_ | ah, right | 13:56 |
| slangasek | mvo, ogra_: does removing this systemd package from the ppa relate to the apparmor denials, or something else? | 13:56 |
| ogra_ | slangasek, just to "out of sync with the archive regarding versioning" ... i think the denial actually requires the addition oof /rofs | 13:57 |
| slangasek | ok | 13:57 |
| slangasek | I'll chase jdstrand in person, thanks :) | 13:57 |
| mvo | slangasek: what I wonder about is why this worked before. we always had an apparmor profile around snap-confine and never allowed /ro | 14:02 |
| ikey | ok further to my slightly skewiff snapcraft forum post, i need to create a snap without a core dependency, and apparently "bare" is the way for this. are any ubuntuisms expected of my snap, and is it possible for me to properly have my /lib64 /usr/lib64 /usr/bin etc directories present in my snap? | 14:03 |
| mup | PR snapcraft#1606 closed: kbuild plugin: if the parts build dir already contains a .config file, use it as the base config <bug> <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1606> | 14:05 |
| jdstrand | mvo: slangasek tracked me down. I suspect that the compiler options changed and libudev isn't being linked in statically | 14:06 |
| ikey | i want to make a decent steam snap and ironically that means not using ubuntu for the base of it, hence the query.. | 14:07 |
| jdstrand | mvo: I have a vague recollection that zyga touched this semi-recently (I could be wrong). We have traditionally statically linked in libseccomp and libcap (and honestly, libudev). not sure why this would've changed... | 14:07 |
| zyga-ubuntu | DEBUG: running snappy-app-dev add snap_snapd-hacker-toolbelt_busybox /dev/nvidia0 195:0 | 14:07 |
| zyga-ubuntu | DEBUG: running snappy-app-dev add snap_snapd-hacker-toolbelt_busybox /dev/nvidiactl 195:255 | 14:08 |
| zyga-ubuntu | DEBUG: running snappy-app-dev add snap_snapd-hacker-toolbelt_busybox /dev/nvidia-uvm 247:0 | 14:08 |
| zyga-ubuntu | DEBUG: running snappy-app-dev add snap_snapd-hacker-toolbelt_busybox /dev/nvidia0 195:0 | 14:08 |
| zyga-ubuntu | DEBUG: running snappy-app-dev add snap_snapd-hacker-toolbelt_busybox /dev/nvidiactl 195:255 | 14:08 |
| zyga-ubuntu | DEBUG: running snappy-app-dev add snap_snapd-hacker-toolbelt_busybox /dev/nvidia-uvm 247:0 | 14:08 |
| zyga-ubuntu | asdadsa | 14:08 |
| ikey | lol | 14:08 |
| zyga-solus | popey: | 14:08 |
| popey | zyga-ubuntu: i see ohmygiraffe | 14:08 |
| zyga-solus | popey: is there a giraffe on your screen? | 14:08 |
| popey | yes | 14:09 |
| zyga-ubuntu | popey: \o/ | 14:10 |
| jdstrand | mvo: slangasek mentioned udev as the denial. I see /rofs/etc/ld.so.cache referenced in backscroll. that might be related-- not sure when ld.so will be used if all libs are statically linked. if so, we need to add that to the profile | 14:10 |
| slangasek | jdstrand: fwiw I just checked, and linkage of snap-confine is not different between the two images | 14:10 |
| slangasek | although, do I need to look at snap-confine within the core snap itself? | 14:11 |
| slangasek | sec, let me nest my loop mounts one level more | 14:11 |
| jdstrand | mvo (cc slangasek): however, I wouldn't expect snaps to work *today* on a live session, so this isn't a regression, is it? | 14:11 |
| jdstrand | slangasek: you would need to look in core, yes | 14:12 |
| jdstrand | (cause eof reexec) | 14:12 |
| slangasek | jdstrand: looked inside core_2898; snap-confine in there is also dynamically linked against libudev | 14:12 |
| zyga-solus | popey: is hiri running? | 14:12 |
| popey | no | 14:12 |
| slangasek | jdstrand: and this is a regression for subiquity specifically, which somehow *did* work before the core update, even if other snaps apparently do not | 14:13 |
| popey | zyga-ubuntu: | 14:13 |
| popey | its slowly loading | 14:13 |
| slangasek | jdstrand: (we had it working in the 17.04 image, and it was working in artful dev until today) | 14:13 |
| zyga-solus | ah | 14:13 |
| popey | yes, i see hiri now | 14:13 |
| zyga-solus | popey: wooot | 14:13 |
| zyga-solus | popey: so we have a fix | 14:13 |
| popey | yay | 14:13 |
| jdstrand | slangasek: I wonder why subiquity is (now?) using a snap... | 14:13 |
| jdstrand | I mean, why is snap-confine running at all? | 14:13 |
| jdstrand | cause, if we fixed this issue and made snap-confine be happy, it'll then launch something that will be sad (if in strict mode) | 14:14 |
| slangasek | jdstrand: that is also not new - it was a) let us move faster with subiquity during release freeze, b) dogfood snaps, c) make subiquity something that anyone can download into a maas ephemeral environment | 14:14 |
| slangasek | it's a classic snap, not strict | 14:15 |
| jdstrand | ok. I find this quite curious. what happens if you allow /rofs/etc/ld.so.cache? | 14:15 |
| jdstrand | I guess you just need read? | 14:15 |
| slangasek | I expect so | 14:16 |
| slangasek | allow it> by editing the apparmor profile in the live env? | 14:16 |
| jdstrand | slangasek: yes | 14:16 |
| jdstrand | grab the profile that corresponds to the core snap | 14:17 |
| jdstrand | slangasek: use snap list to get the revision of core. then edir /etc/apparmor.d/snap.core.<rev>.usr.lib.snapd.snap-confine | 14:18 |
| jdstrand | slangasek: if that is ro, just cp /snap/core/current/etc/apparmod.d/usr.lib.snapd.snap-confine | 14:19 |
| jdstrand | slangasek: then modify and load that copy | 14:20 |
| slangasek | jdstrand: well, thus far 'snap list' says nothing, because things fail early enough that the seed is never fully processed AFAICS. But yeah, I'll dig, thanks | 14:20 |
| jdstrand | zyga-solus: fyi, rofs might actually be a future consideration for snap-confine.d (ie, snapd detects it is in a live image, adds some policy) | 14:21 |
| jdstrand | zyga-solus: all future, nothing to do now | 14:21 |
| zyga-solus | jdstrand: hello | 14:21 |
| zyga-solus | jdstrand: future as in in the next 6 days for artful release? | 14:21 |
| zyga-solus | jdstrand: we need your review on https://github.com/snapcore/snapd/pull/4022 | 14:21 |
| mup | PR #4022: interfaces/opengl: don't udev tag nvidia devices and use snap-confine instead (2.28) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4022> | 14:21 |
| jdstrand | slangasek: you don't need snp listist then, just copy out of current like I said | 14:22 |
| zyga-solus | jdstrand: it's an urgent fix for 2.28.x | 14:22 |
| * jdstrand nods | 14:22 | |
| zyga-solus | mvo, jdstrand: if we need this rofs support for the artful release we should know and do this now so that it's ready | 14:23 |
| zyga-solus | (on time) | 14:23 |
| mup | PR snapcraft#1588 closed: lxd: use SUDO_UID for ID mapping <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1588> | 14:23 |
| zyga-solus | slangasek, jdstrand: if you are sprinting now and make this decision please tell mvo and me ASAP | 14:25 |
| slangasek | zyga-solus: we are sprinting but are in different rooms ;) | 14:25 |
| mup | PR snapcraft#1348 opened: repo: setup a foreign arch and sources <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1348> | 14:26 |
| mup | PR snapcraft#1382 opened: rust plugin: make libc configurable <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1382> | 14:26 |
| slangasek | aaaand now I've booted this image again and the problem did not reproduce. yay? | 14:26 |
| ogra_ | lol | 14:26 |
| slangasek | so possibly racy on top of everything | 14:26 |
| mup | PR snapd#4024 opened: debian: fix replaces/breaks for snap-xdg-open (thanks to apw!) <Created by mvo5> <https://github.com/snapcore/snapd/pull/4024> | 14:27 |
| zyga-solus | slangasek: not yay | 14:27 |
| zyga-solus | slangasek: mvo said it doesn't work for him | 14:27 |
| slangasek | zyga-solus: snapd doesn't work, or reproducing doesn't work? | 14:28 |
| slangasek | I just rebooted and reproduced the failure again | 14:28 |
| mvo | slangasek: I had downloaded the image, booted and it failed | 14:28 |
| mvo | slangasek: let me try again | 14:28 |
| mvo | slangasek: but yeah, looks racy | 14:28 |
| * kalikiana food | 14:29 | |
| mvo | zyga-*: http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/artful-live-amd64.iso | 14:29 |
| jdstrand | mvo, zyga-solus: reviewed 4022 | 14:31 |
| mvo | jdstrand: what shall we do about the /ro issue from slangasek? add support for that too? | 14:32 |
| mvo | jdstrand: I'm still puzzled how this evar worked? | 14:33 |
| slangasek | jdstrand: so if I edit the profile under /etc/apparmor.d, apparmor_parser -r, and systemctl restart snapd, snapd overwrites the profile again and loads the original | 14:33 |
| slangasek | jdstrand: so I'm not sure how I should test the result | 14:34 |
| jdstrand | mvo: fyi, I recommended even better future-proofed rules | 14:35 |
| mvo | jdstrand: in 4022? yeah, +1 for that | 14:35 |
| mvo | slangasek: please don't restart snapd, it should be fine without a restart | 14:35 |
| jdstrand | mvo: re 4022> note, I recommended one set, and 3 seconds ago recommended a better set | 14:35 |
| slangasek | mvo: so what should I do in order to test? | 14:35 |
| mvo | slangasek: and yes, on restart it will rewrite the rules, it is very opionated about that | 14:35 |
| slangasek | all the snaps get unmounted | 14:35 |
| mvo | jdstrand: heh, ok | 14:35 |
| jdstrand | mvo: I'm puzzled too | 14:35 |
| jdstrand | slangasek: the test is, load the profile and don't restart snapd | 14:36 |
| mvo | slangasek: uh, you need to restart snapd so that it applies the seed, right? | 14:36 |
| slangasek | jdstrand: ok but then what? | 14:36 |
| jdstrand | slangasek: then launch whatever subiquty is doing | 14:36 |
| slangasek | what subiquity is doing is running the bits from the snaps, that are not mounted, because snap-confine failed and things were rolled back :) | 14:36 |
| mvo | slangasek: what changes did jdstrand suggest? | 14:36 |
| jdstrand | that is a fun spelling | 14:36 |
| ackk | kalikiana, so it seems that adding the network slot to the lxc app actually makes it not work with network :) | 14:36 |
| ackk | quite odd | 14:36 |
| slangasek | mvo: adding /rofs/etc/ld.so.cache as a test | 14:37 |
| jdstrand | mvo: an r rule for the /rofs/ ld.so.cache | 14:37 |
| jdstrand | (that isnt the full path | 14:37 |
| jdstrand | ) | 14:37 |
| mvo | slangasek: ta, I can try that and snap install /var/lib/snapd/seed/snaps/* manually | 14:37 |
| jdstrand | man, irc is *laggy*... | 14:37 |
| slangasek | ah, testing that here as well | 14:37 |
| jdstrand | yes, snap install a classic snap | 14:38 |
| slangasek | apparmor profile overwritten again | 14:38 |
| jdstrand | then run snap run --shell snap.command | 14:38 |
| jdstrand | that is enough to get snap-confine going | 14:38 |
| slangasek | but this time the core snap has stayed mounted | 14:38 |
| zyga-ubuntu | popey: is the giraffe still around? | 14:38 |
| popey | yes | 14:39 |
| slangasek | jdstrand: I see apparmor denials for both ld.so.cache and libudev | 14:39 |
| zyga-ubuntu | jdstrand: where did you push it? | 14:39 |
| jdstrand | zyga-ubuntu: I haven't pushed anything | 14:39 |
| zyga-ubuntu | ah sorry | 14:39 |
| jdstrand | slangasek: I suggest copying the fileand loading that | 14:40 |
| jdstrand | snapd shouldn't rewrite the file and load it then (and if it does, at least your changes aren't overwritten, you need only reload) | 14:40 |
| slangasek | jdstrand: oh, because the file doesn't have to have the same name as the path? hurr ok | 14:41 |
| jdstrand | yes | 14:41 |
| jdstrand | slangasek: it is the contents of the file that matter. the filename is just convention | 14:42 |
| slangasek | jdstrand: ok. I have to add rofs for both libudev and ld.so.cache, and then I get farther... and then we get the same error for libpthread.so.0 | 14:43 |
| jdstrand | mvo: I'm curious. with 4022, with only the code changes, the apparmor rules are required? | 14:43 |
| slangasek | jdstrand: why are the libs from the rootfs being used instead of those inside the snap? | 14:43 |
| slangasek | isn't that the real issue here? | 14:43 |
| mvo | jdstrand: I am not sure if they are strictly required, I had some denials when testing hiri | 14:43 |
| popey | zyga-ubuntu: giraffe is back! | 14:43 |
| zyga-ubuntu | popey: great | 14:44 |
| zyga-ubuntu | popey: so it works | 14:44 |
| zyga-ubuntu | I'll close the window now, that's all I need | 14:44 |
| zyga-ubuntu | popey: thank you very very much | 14:45 |
| jdstrand | slangasek: I think what was maybe happening before is that snapd was considering the live session as "not Ubuntu' and running snapd in non-restrictive mode | 14:45 |
| jdstrand | mvo: does that sound plausible? ^ | 14:45 |
| popey | zyga-ubuntu: np, shall I shut this down now? | 14:45 |
| mvo | jdstrand: let me check os-release | 14:45 |
| zyga-ubuntu | popey: yes, I think it's good now | 14:45 |
| popey | kk | 14:45 |
| zyga-ubuntu | popey: just label it "zyga" and put it on the shelf ^_^ | 14:46 |
| zyga-ubuntu | (kiddin) | 14:46 |
| popey | was about to ask :D | 14:46 |
| jdstrand | (and snap-cofine's profile wasn't loaded and between the two, things worked cause snap-confine wasn't confined) | 14:46 |
| mvo | jdstrand, slangasek: fwiw, I added /rofs/a-bunch-of-libs, now it fails on /vow/upper/var/lib/snapd/cookie | 14:46 |
| jdstrand | yeah, this is exactly the road I was talking to slangasek about running snaps in t he live image the other day | 14:46 |
| jdstrand | we aren't gong to fix this whack-a-mole | 14:46 |
| jdstrand | we need the previous behavior when on live session | 14:47 |
| jdstrand | snap-cofine should not be confined and snapd needs to be cool with that | 14:47 |
| mvo | jdstrand: well, os-release says ID=ubuntu so previous versions *should* have confined it too | 14:47 |
| mvo | jdstrand: but obviously reality disagrees with me | 14:48 |
| zyga-ubuntu | jdstrand: aha | 14:48 |
| jdstrand | this is indeed puzzling | 14:48 |
| zyga-ubuntu | jdstrand: by sayin "shoud not be confined" do you mean that in live sessions we should unload the profile | 14:48 |
| slangasek | previous working image still available at http://cdimage.ubuntu.com/ubuntu-server/daily-live/20171010.1/artful-live-amd64.iso for comparison | 14:48 |
| zyga-ubuntu | jdstrand: or just disable apparmor in the kernel? | 14:48 |
| jdstrand | oh | 14:48 |
| jdstrand | yes | 14:48 |
| jdstrand | slangasek: I thought for live fs there was something about detecting if apparmor was there and not using it | 14:49 |
| jdstrand | passing apparmor=0 | 14:49 |
| jdstrand | something in the init script | 14:49 |
| slangasek | oh? let me see | 14:49 |
| slangasek | I don't find any references to that in livecd-rootfs | 14:50 |
| jdstrand | something... (I can't recall the details) | 14:50 |
| slangasek | a userspace process is allowed to disable apparmor after boot? | 14:50 |
| mvo | jdstrand: that sounds very plausible to me, if apparmor is disabled we detect that and things should work | 14:51 |
| kalikiana | ackk: Interesting. Not what I would've expected... | 14:53 |
| jdstrand | ah | 14:53 |
| jdstrand | mvo, slangasek: I bet what is happening is that the apparmor initscript is not loading /etc/apparmor.d. *but* snapd is reexcing and loading snap-confine's profile | 14:54 |
| jdstrand | mvo, slangasek: so napd needs to detect if on live session and not do that | 14:54 |
| jdstrand | slangasek: disable apparmor after boot> no. userspace can choose to not load profiles though | 14:55 |
| jdstrand | mvo: fyi, /lib/apparmor/functions /profile-load has: [ -d /rofs/etc/apparmor.d ] && exit 0 # do not load if running liveCD | 14:56 |
| jdstrand | I gotta run | 14:56 |
| slangasek | test -d /rofs/etc/apparmor.d && exit 0 | 14:56 |
| slangasek | that's in the apparmor init script | 14:57 |
| mup | PR snapcraft#1573 closed: WIP project_loader: parse YAML without processing it <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1573> | 14:59 |
| zyga-ubuntu | I wonder how can we detect that | 15:00 |
| zyga-ubuntu | being in live session | 15:00 |
| ogra_ | well, see above ... if /rofs exists ... | 15:00 |
| mvo | slangasek: the old image (based on 2898) fails in the same way for me | 15:00 |
| ogra_ | (there are many other indicators though ... ) | 15:01 |
| kalikiana | kyrofa, sergiusens: Can I get a final review on https://github.com/snapcore/snapcraft/pull/1412 | 15:01 |
| mup | PR snapcraft#1412: lxd: snapcraft refresh in containers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1412> | 15:01 |
| mvo | jdstrand: (see above, the previous 2898 is broken for me as well) | 15:01 |
| mvo | slangasek, jdstrand: on reboot it works now | 15:02 |
| jdstrand | mvo: so, reexec for snap-confine is loading the appropriate profile into the kernel. it shouldn't on livefs (see reference from me and slangasek, above) | 15:03 |
| jdstrand | mvo: in the reexec code, just looke for /rofs/etc/apparmor.d and don't load | 15:04 |
| jdstrand | that should immediately fix this issue | 15:04 |
| zyga-ubuntu | jdstrand: ok | 15:04 |
| jdstrand | I can't comment on when it was first introduced | 15:04 |
| jdstrand | (the regression) | 15:04 |
| jdstrand | . we've had reexec for ages, so not sure what it is showing up only now | 15:05 |
| ogra_ | perhaps it should simply boot completely without reexec in live ? | 15:05 |
| kalikiana | sergiusens: elopio: Also a real review here would be appreciated https://github.com/snapcore/snapcraft/pull/1568 | 15:05 |
| mup | PR snapcraft#1568: lxd: don't re-inject the same snaps <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1568> | 15:05 |
| ogra_ | (given thats a simple env var that might be easier to implement) | 15:05 |
| jdstrand | ogra_: that would be simple. I don't know the requirements for livefs | 15:05 |
| ogra_ | just use the deb until you install | 15:05 |
| jdstrand | that does seem reasonable to me. mvo? ^ | 15:06 |
| elopio | kalikiana: I'm still confused by that one. Aren't we checking the md5 of the .snap file? | 15:06 |
| mvo | jdstrand: yes, working on a patch now | 15:07 |
| ogra_ | mvo, just addint SNAP_REXEC=0 to casper defaults would do | 15:07 |
| kalikiana | elopio: Then let's discuss it :-) Yes, md5sum is used to see if the files are the same | 15:07 |
| ogra_ | (assuming server uses casper for live) | 15:07 |
| mvo | ogra_: interessting - jdstrand, what do you think about about "<ogra_> mvo, just addint SNAP_REXEC=0 to casper defaults would do"? | 15:08 |
| kalikiana | elopio: Did you run it more than once with the same container while testing? If you do a cleanbuild you won't see a difference | 15:09 |
| elopio | kalikiana: so, I don't understand why it knows that the core snap is the same and doesn't reinstall it, but it doesn't work the same way for the snapcraft snap and it is reinstalled? | 15:09 |
| jdstrand | mvo: I think that is very reasonable | 15:10 |
| jdstrand | I suspect you can test that right now | 15:10 |
| elopio | kalikiana: Sergio said it's because core comes from the store, and the snapcraft snap is a --dangerous install. But if we are checking the .snap, I don't understand that difference. | 15:10 |
| jdstrand | I forget how casper works otoh | 15:11 |
| kalikiana | elopio: Was the snapcraft snap the same? From your comment I can't tell | 15:11 |
| mvo | jdstrand: could you pass it to steve, he seems to have dropped from irc. I will wait for his feedback and otherwise I will go ahead with a 2.28.4 with the nvidia fix but without any special subiquity | 15:11 |
| jdstrand | I need to focus on the sprint atm. I'' check back | 15:11 |
| jdstrand | mvo: yes | 15:11 |
| kalikiana | elopio: it should work for x versions as well, as long as the md5sum matches | 15:11 |
| zyga-ubuntu | mvo: please don't fork 2.29 before we backport all the fixes from 2.28 to master | 15:11 |
| mvo | jdstrand: thank you! I will be here waiting for feedback | 15:11 |
| mvo | zyga-ubuntu: +100 | 15:11 |
| elopio | kalikiana: I think so. I built a snapcraft.snap from your branch. Installed it with --dangerous. Ran container builds once, core and snapcraft are installed. Ran it again, only snapcraft is installed. | 15:12 |
| elopio | so it's identifying the repeated core. But as far as I understand, it should also identify the same snapcraft. Unless I'm missing a step or misunderstanding something... | 15:14 |
| kalikiana | elopio: Yeah. It's just the .snap files. | 15:16 |
| kalikiana | elopio: Does the code make sense to you? I don't know if there's a case I'm missing... | 15:21 |
| elopio | I think it makes sense. From reading the code, I got the idea that both store and local snaps would be checked and installed only if needed. kalikiana is there something you want me to try here? | 15:24 |
| elopio | kyrofa: ping. We are getting this in artful and zesty: http://paste.ubuntu.com/25720772/ | 15:26 |
| * kalikiana thinking | 15:26 | |
| kyrofa | elopio, those tests should be tagged as xenial-only | 15:26 |
| kyrofa | elopio, are you moving them around by any chance? | 15:27 |
| kalikiana | sergiusens: btw this is also waiting on your re-review https://github.com/snapcore/snapcraft/pull/1546 | 15:28 |
| mup | PR snapcraft#1546: cli: update parts cache in the container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1546> | 15:28 |
| kalikiana | elopio: I just tried here again, with a new container, works 100% fine... `SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft -d pull` twice, second time I get `Not re-injecting same version of 'snapcraft'` | 15:30 |
| kalikiana | elopio: Did you test this way also? | 15:31 |
| elopio | kyrofa: I don't think I've touched them. And I see no != xenial skip in there. I can add it. | 15:31 |
| elopio | kalikiana: I tried without the `-d pull`. I can try again | 15:31 |
| kalikiana | elopio: The `-d` is just so you see the message, any command is fine | 15:32 |
| kalikiana | pull is just the cheapest operation | 15:32 |
| kyrofa | elopio, hmm. That error isn't really unusual though, I'm surprised we haven't seen it more | 15:33 |
| kyrofa | elopio, we should add a way to ack pubkeys | 15:33 |
| elopio | kyrofa: so, how does it pass on xenial if it can't validate the keys? Could this be caused by a newer apt version or something like that? | 15:36 |
| kyrofa | elopio, yeah maybe. Or sha1 invalidation? | 15:36 |
| kyrofa | We need to investigate | 15:36 |
| kyrofa | Rather: I will investigate :) | 15:36 |
| kyrofa | I've got a few things on my queue though-- can it wait a bit? | 15:37 |
| elopio | kyrofa: do you want me to propose the skip? | 15:37 |
| kyrofa | elopio, it depends on how soon you need those tests to pass | 15:37 |
| elopio | kyrofa: I don't yet have the xenial results yet, but it seems to me that's the last blocker for the release. I'm not sure if sergiusens wanted to release this week, or the next. | 15:39 |
| zyga-solus | /me -> math with son, ping if emergency | 15:39 |
| elopio | kalikiana: so, please confirm the steps I'm running. Checkout your no-reinject branch, build a snap from that branch, install that snap. snapcraft init, and SNAPCRAFT_CONTAINER_BUILDS snapcraft twice. | 15:40 |
| kalikiana | elopio: assuming you have =1 in there like I did above, yes | 15:42 |
| kalikiana | elopio: Do you see log messages about installing or "not re-injecting"? | 15:43 |
| elopio | I will let you know in a few minutes when I have the snap built. | 15:44 |
| elopio | I didn't run with --debug, I will do that this time. | 15:44 |
| kalikiana | elopio: Okay. Thanks a lot! | 15:50 |
| elopio | kalikiana: now it seems to work: http://paste.ubuntu.com/25720936/ | 16:00 |
| elopio | I can't explain how I got the log with only snapcraft reinstall :/ | 16:00 |
| zyga-solus | mvo: re, all good? | 16:01 |
| mup | PR snapcraft#1590 closed: setuptools: conditional Debian-specific deps <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1590> | 16:02 |
| kalikiana | elopio: Interesting. The inherent problem with manual testing I guess... | 16:02 |
| elopio | kalikiana: oh wait, maybe I know! | 16:04 |
| elopio | on my previous log, my snapcraft version was x2. So I reinstalled the snap snap, and ran two container builds from scratch. | 16:05 |
| elopio | kalikiana: http://paste.ubuntu.com/25720968/ same log as before. Any idea how x2 could be different from x1? | 16:06 |
| mvo | zyga-solus: still waiting for slangaseks feedback is seeding SNAP_REEXEC=0 in casper is sufficient | 16:06 |
| jdstrand | mvo: I advised slangasek to use SNAP_REEXEC=0 and he is testing that | 16:08 |
| mvo | jdstrand: cool, thanks | 16:09 |
| slangasek | jdstrand, mvo: I am somewhat contended right now (just pulled into another meeting), I am going to test it as quickly as possible but don't know if I'll get it done before lunch (eta 20m) | 16:10 |
| mvo | slangasek: thank you, keep me updated. I'm preparing a new snapd right now but will wait with the release until you had a chance to test the env string | 16:11 |
| mvo | slangasek: I will just wait for your feedback | 16:12 |
| slangasek | ok | 16:12 |
| slangasek | mvo: does that mean that, once tested, you will be fixing this via snapd and I don't need to change livecd-rootfs? | 16:12 |
| mvo | slangasek: the other way around :) | 16:13 |
| slangasek | mvo: once tested, I will change it in livecd-rootfs and you will make no changes to snapd? :) | 16:13 |
| mvo | slangasek: if the re-exec env does not work for you I can fix in snapd, otherwise I will leave it out of snapd | 16:13 |
| slangasek | ok | 16:13 |
| mvo | slangasek: correct | 16:13 |
| elopio | kalikiana: here's an idea. When snapcraft is x2 in the host, in the container it will be installed as x1 on the first execution. On the second execution it compares x2 with x1, and then reinstalls it on the container. Now both the host and the container have x2, so the third execution will not reinstall it. Would that make sense? | 16:14 |
| mvo | slangasek: I think it makes more sense to customize the env in casper than to hardcode this behaviour in snapd. if you give me a pointer how I can do it I can test it here myself | 16:14 |
| slangasek | mvo: the rootfs is an overlay, so everything is editable; I was going to drop a snippet into /etc/systemd/system/snapd.service.d/ that sets Environment=SNAP_REEXEC=0 | 16:16 |
| slangasek | mvo: file extension must end in .conf, and Environment must be set under a [Service] block | 16:16 |
| mvo | slangasek: ta | 16:19 |
| mvo | slangasek: testing now | 16:19 |
| === JoshStrobl is now known as JoshStrobl|AFK | ||
| slangasek | mvo: tested here also, and it passed | 16:26 |
| jdstrand | mvo: this isn't super-urgent since the apparmor accesses for snap-confine for the nvidia thing are safe, but I'm really puzzled how a stat on a file in /dev is causing those for you. I *think* the root cause was that my original PR was always intended for 2.28, but for some reason didn't make it there (so that is something to consider how to improve) | 16:26 |
| kalikiana | elopio: Ah. Yes. It would be looking for the same x2.snap which wouldn't be there. | 16:27 |
| mvo | slangasek: reliable?that is great | 16:27 |
| kalikiana | elopio: Unfortunately the x is a continuous number, nothing we can do here | 16:27 |
| mvo | jdstrand: I'm not sure either, I think we need to do a proper retrospect on this | 16:28 |
| mvo | jdstrand: when the fires are out of course :) | 16:28 |
| zyga-suse | jdstrand: could it be the snappy-dev-app helper? | 16:28 |
| mvo | jdstrand: so probably post-sprint | 16:28 |
| jdstrand | mvo: sure, that's fine. there were several issues. I want to make sure they are all knownand addressed | 16:29 |
| mvo | jdstrand: yeah, I think we are in agreement | 16:29 |
| mvo | jdstrand: do you think we need more for the .4 release? | 16:29 |
| jdstrand | mvo: for example, I thought I did the initial PR inenough time for it to be in 2.28 (indeed, I worked on it with priority so it would be there), but I must have missed a fork | 16:29 |
| mvo | jdstrand: I can check the exact timing | 16:30 |
| kalikiana | sergiusens: Can this be merged, please? https://github.com/snapcore/snapcraft/pull/1512 | 16:30 |
| mup | PR snapcraft#1512: pluginhandler: clean error for BasePlugin.run{,_output} <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1512> | 16:30 |
| jdstrand | mvo: so, why did I miss that, how can I not miss it in the future, how can snapd team make that easier for me. that sort of thing | 16:30 |
| zyga-suse | jdstrand: was the PR tagged for 2.28? | 16:31 |
| zyga-suse | (tagged as in github milestone) | 16:31 |
| mvo | jdstrand: +1 | 16:31 |
| jdstrand | mvo: obviuosly there is the QA aspect (why didn't QA see that an lxd consuming snap broke, why didn't qa see that opengl failed on nvidia) | 16:31 |
| jdstrand | (I know that last one, the CI tests don't have nv hardware, which is why I mocked it) | 16:31 |
| * jdstrand happens to also not have nvidia hardware | 16:31 | |
| zyga-suse | jdstrand: qa process doesn't involve nvidia unfortunately | 16:31 |
| * jdstrand nods | 16:32 | |
| jdstrand | zyga-suse: right, so we need to figure out how to do that, even if manual, whenever we see changes for nv | 16:32 |
| jdstrand | eg, hey zyga-suse, I patched something with nvidia, can you test real quick? | 16:32 |
| zyga-suse | jdstrand: agreed | 16:32 |
| zyga-suse | jdstrand: we were discussing similar measures | 16:33 |
| jdstrand | niemeyer also said we should all run candidate. | 16:33 |
| zyga-suse | jdstrand: all releases smoke tested on nvidia HW | 16:33 |
| zyga-suse | jdstrand: and also all nvidia-touching code really tested as well | 16:33 |
| jdstrand | anyway, don't have to discucss here. niemeyer and I talked about it. I'd like to participate in the post-mortem to make sure I know all the agreements and can adhere to them | 16:33 |
| zyga-suse | +1 | 16:34 |
| jdstrand | zyga-suse: yeah | 16:34 |
| jdstrand | like, I *knew* nvidia was busted. so I did the PR. unfortunately it didn't hit .28(failing), the fact that I happened to notice nv would fail was a failing. if we actually needed additional apparmor rules, that was also a failing (I'm really curios if they were actually needed) | 16:35 |
| jdstrand | ok, lunch | 16:35 |
| mup | PR snapcraft#1536 closed: repo: implement :target suffix for package names <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1536> | 16:35 |
| zyga-suse | jdstrand: we need apparmor permissions to stat files, right? | 16:36 |
| kalikiana | elopio: Can you please comment on the PR? I'm really trying to get my list of PRs down :-D | 16:38 |
| elopio | uh, sorry, my comment was caught in a network issue. | 16:39 |
| kalikiana | elopio: Ah, I see it now... not to be demanding, but I was thinking *review* comment ;-) | 16:40 |
| mvo | slangasek: for me the journy was slightly more complicated, when I do "printf "[Service]\nEnvironment=NO_REEXEC=0" > /etc/systemd/system/snap.subiquity.started.service.d/no-rexec.conf" (and added the basedir) things work, but it needs to be that because the "snap run" that starts subiquity is indepedent of snapd and will not inherit the environment | 16:40 |
| elopio | kalikiana: you have it. | 16:40 |
| mvo | slangasek: *if* this is a sufficient workaround for now I will go ahead with 2.28.4 | 16:40 |
| mvo | slangasek: and leave the re-exec disable to casper. I can help with the PR if you point me to the right branch once .4 is out :) | 16:41 |
| kalikiana | elopio: Ah, you did it separately. This distinction between "just comment" and proper reviews is really silly... but anyway, thanks a lot! | 16:41 |
| slangasek | mvo: yes, that looks like a sufficient workaround to me | 16:41 |
| slangasek | mvo: I'm going to shove it into livecd-rootfs rather than casper | 16:41 |
| mvo | slangasek: thank you, that sounds good as well, let me know if I can help | 16:41 |
| kalikiana | kyrofa: Can you please check this one again? I addressed your comments https://github.com/snapcore/snapcraft/pull/1577 | 16:43 |
| mup | PR snapcraft#1577: lxd: don't inject local snaps on a different arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1577> | 16:43 |
| kalikiana | also elopio ^^ | 16:43 |
| elopio | kalikiana: I like that distinction. I don't feel good about -1 a PR when I don't understand something. Like in this case. | 16:44 |
| elopio | one could argue that a -1 is the right thing to do, because this behaviour should have been explained in a PR comment somewhere. But still it's not clear if it's my fault because I'm being dumb, until we dig further. | 16:44 |
| kalikiana | elopio: Hmm yeah. To me it would be clearer if you could have a ? icon there, and turn it into a +1 or -1 as needed, like the "approve" and "discmiss" buttons you get at the bottom | 16:46 |
| kalikiana | Really the fact that it splits the work-flow so weirdly is what bugs me | 16:46 |
| mvo | a review for 4024 would be great | 16:47 |
| kalikiana | you missed the # there | 16:47 |
| * zyga-suse looks | 16:52 | |
| mup | PR snapd#4024 closed: debian: fix replaces/breaks for snap-xdg-open (thanks to apw!) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4024> | 16:52 |
| zyga-suse | ah, I just looked from another computer :) | 16:53 |
| mup | PR snapcraft#1348 closed: repo: setup a foreign arch and sources <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1348> | 16:57 |
| zyga-suse | mvo: tests on 4022 are incredibly slow | 16:57 |
| * kalikiana still waiting on #1587 and #1577 wondering if sending European chocolates to his colleagues would help | 17:02 | |
| mup | PR #1587: store: deal with 404 froms the SSO store properly <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1587> | 17:02 |
| mup | PR #1577: daemon, cmd/snap: refresh --devmode <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1577> | 17:02 |
| * zyga-suse -> supper and clenaup | 17:03 | |
| Chipaca | kalikiana: presumably snapcraft#1587 and snapcraft#1577 | 17:03 |
| mup | PR snapcraft#1587: lifecycle: clean after deleting container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1587> | 17:03 |
| mup | PR snapcraft#1577: lxd: don't inject local snaps on a different arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1577> | 17:03 |
| kalikiana | Chipaca: Thanks, yeah. I guess ids are not unique... | 17:04 |
| Chipaca | kalikiana: yeah, and they're similarly small numbers | 17:04 |
| Chipaca | otherwise mup does guess they're something else (e.g. #1688531) | 17:05 |
| mup | Bug #1688531: Remove whitespace line between tracks in 'snap info' <snapd:Fix Committed by chipaca> <https://launchpad.net/bugs/1688531> | 17:05 |
| Chipaca | anyway, EOD for me | 17:06 |
| Chipaca | o/ | 17:06 |
| jdstrand | zyga-suse: you do *not* need apparmor rules for the files to stat them. you need read on the directory the files are in. That is why I am puzzled why the /dev accesses were needed (and why the /sys denials popped up). | 17:13 |
| jdstrand | I suspect the /sys accesses are just noise and that the /dev accesses are not needed at all | 17:13 |
| zyga-suse | aha, interesting | 17:13 |
| zyga-suse | I didn't know that, I agree that some of those are probably not needed in that case | 17:13 |
| jdstrand | this is why the mocked nvidia devices passed the test | 17:14 |
| zyga-suse | I was trying to be conservative in hard situation (time running out, remote access to hardware) | 17:14 |
| jdstrand | spread tests | 17:14 |
| zyga-suse | I'll gladly research why the sys access showed up | 17:14 |
| jdstrand | I'm super-curious on that. also curious if they still show up if they are just noise | 17:14 |
| jdstrand | I suspect they are cause snap-confine isn't going to do anything with any of that. it is just going to stat the files and add them to the cgroup | 17:15 |
| * zyga-suse was hoping to do some updates on snap-update-ns but today turned out different | 17:15 | |
| zyga-suse | I found a bug where snap-update-ns doesn't do what it should, I need to debug that | 17:16 |
| zyga-suse | but now I need a break | 17:16 |
| zyga-suse | o/ | 17:16 |
| jdstrand | I suspect the udev lib calls snap-confine does a little earlier are triggering those, then udev ignores nvidia and moves on. then we stat and are good | 17:16 |
| jdstrand | zyga-suse: my curiosity is certainly not a reason to deprioritize other things :) | 17:16 |
| jdstrand | I would like to remove the /dev rules if possible | 17:17 |
| zyga-suse | no no, it's not your fault, I'm just tired and I want to wrap up that branch before jumping onto other topics | 17:17 |
| zyga-suse | who knows, maybe in .5 :) | 17:17 |
| * zyga-suse knocks on wood | 17:17 | |
| jdstrand | cause access to the devices is more than the setuid snap-confine needs (though, it is just read, but still) | 17:18 |
| zyga-suse | jdstrand: I'm surprised stat is not triggering apparmor checks btw | 17:18 |
| jdstrand | there is a bug on that | 17:18 |
| * jdstrand finds | 17:19 | |
| zyga-suse | jdstrand: it's an information leak via (very) expensive enumeration | 17:19 |
| zyga-suse | aha | 17:19 |
| zyga-suse | so it will be changed eventually? | 17:19 |
| jdstrand | https://bugs.launchpad.net/apparmor/+bug/1655435 | 17:19 |
| mup | Bug #1655435: stat() unconditionally allowed via apparmor_inode_getattr() <AppArmor:Triaged> <https://launchpad.net/bugs/1655435> | 17:19 |
| jdstrand | zyga-suse: not in a way that we wouldn't know about it | 17:20 |
| jdstrand | and also, not any time soon | 17:20 |
| jdstrand | apparmor could conceivably grow a 'stat' perm (as opposed to read and write) | 17:20 |
| jdstrand | but backc in the day that was implemented and it was amazingly annoying. no one is working on it | 17:21 |
| zyga-suse | not a weekend project? | 17:21 |
| mvo | zyga-suse: yeah, I am waiting for two tests right now :/ | 17:38 |
| zyga-solus | I'm assembling furniture | 17:38 |
| mvo | zyga-suse: 4022 is green now | 17:39 |
| zyga-solus | I think we are doing the same thing lately :) | 17:39 |
| mvo | zyga-solus: heh, enjoy, I will do 2.28.4 now - but first I check the forum if there is anything else we need to do | 17:39 |
| zyga-solus | good call | 17:39 |
| mup | PR snapd#4022 closed: interfaces/opengl: don't udev tag nvidia devices and use snap-confine instead (2.28) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4022> | 17:40 |
| === cachio is now known as cachio_afk | ||
| mup | PR snapd#4025 opened: release: merge the snapd 2.28.4 changes back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/4025> | 17:57 |
| mvo | cachio_afk: just a heads-up - we should have a 2.28.4 in beta in ~1h that fixes the opengl issue | 18:22 |
| mup | Bug #1722882 opened: Ubuntu Core 16: Error: cannot refresh "pi2-kernel": snap "pi2-kernel" has changes in progress <Snappy:New> <https://launchpad.net/bugs/1722882> | 18:26 |
| jdstrand | zyga-suse: heh, no, not a weekend project. I mean, the mediation itself wouldn't be bad (iirc), it would be the policy implications. | 18:41 |
| zyga-solus | jdstrand: do you think it's feasible to introduce a change that is backwards compatible? | 18:59 |
| zyga-solus | jdstrand: (stat keeps being allowed in absence of policy but can be controlled) | 19:00 |
| mvo | zyga-solus: just fyi, the world is conspiring against us: https://code.launchpad.net/~snappy-dev/+snap/core/+build/90572 - my fresh core build with 2.28.4 does not upload to the store :/ | 19:19 |
| mvo | a review for 4025 would be great | 19:25 |
| zyga-solus | mvo: :-( | 19:35 |
| zyga-solus | mvo: I'll review it in a sec | 19:35 |
| mup | PR snapd#4025 closed: release: merge the snapd 2.28.4 changes back into master <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4025> | 19:37 |
| mvo | cachio_afk: 2.28.4 is in beta now and ready for testing towards candidate | 19:40 |
| jdstrand | zyga-solus: yes. it is possible to say 'you haven't specified any stat rules, so I'll let you stat. if you add a stat rule, every stat is mediated. that is possible | 19:52 |
| zyga-suse | jdstrand: maybe I could work on that eventually, I'd like to | 19:52 |
| jdstrand | zyga-solus: honestly though, there are a number of info leaks-- I'd prefer to see fixing those. all of a sudden mediating stat is ging to be *painful* for policy | 19:57 |
| zyga-suse | anything small? | 19:57 |
| jdstrand | I would suggest going to #apparmor on OFTC and asking if there is something bitesize | 19:59 |
| zyga-suse | ok | 19:59 |
| jdstrand | the one I want is kernel variable, so @{pid} corresponds to your pid | 19:59 |
| jdstrand | but that is not at all bitesize :) | 19:59 |
| mup | PR snapd#4020 closed: tests: add test for lxd interface <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4020> | 20:02 |
| === cachio_afk is now known as cachio | ||
| mup | PR snapcraft#1607 opened: python plugin: use extracted pip <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1607> | 21:06 |
| JonelethIrenicus | any way to not have snap directories show up as actual drives in applications? | 21:14 |
| JonelethIrenicus | For some reason applications like Firelight pick them up as seperate drives. | 21:15 |
| gouchi | check udisk2 interfaces ? | 21:15 |
| gouchi | https://docs.snapcraft.io/reference/interfaces | 21:15 |
| JonelethIrenicus | thanks I will | 21:16 |
| kyrofa | gouchi, how will that help with hiding the mounted snaps? | 21:20 |
| gouchi | oops sorry I misread | 21:20 |
| gouchi | I understood how to access drives | 21:21 |
| gouchi | sorry my mistake | 21:21 |
| kyrofa | JonelethIrenicus, snaps are simply squashfs images mounted into place | 21:22 |
| kyrofa | JonelethIrenicus, those applications are probably picking them up like any other disk image | 21:23 |
| === JoshStrobl|AFK is now known as JoshStrobl | ||
| mup | PR snapd#4026 opened: overlord/auth: continue for now supporting UBUNTU_STORE_ID if the model is generic-classic <Created by pedronis> <https://github.com/snapcore/snapd/pull/4026> | 22:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!