| mup | PR snapd#4471 closed: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4471> | 00:23 |
|---|---|---|
| mup | PR snapcraft#1897 closed: docker: user proper tags in Readme.md <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1897> | 00:32 |
| mup | PR snapcraft#1898 opened: docker: don't rely on snapcraft-classic <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1898> | 00:50 |
| zyga | kyrofa: the fixes are merged, please try edge and report any weird stuff | 00:53 |
| zyga | kyrofa: rc2 tomorrow | 00:53 |
| zyga | kyrofa: (early morning) | 00:53 |
| zyga | so you can be on beta to see it | 00:53 |
| mup | PR snapd#4561 closed: tests: generic detection of gadget and kernel snaps <Created by plars> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4561> | 00:57 |
| kyrofa | zyga, you got it, thanks man :) | 00:58 |
| kyrofa | Yeah looks like RC1 now, when I see RC2 I'll give it a shot | 00:59 |
| zyga | kyrofa: tomorrow morning | 01:04 |
| zyga | I'm baby sitting the last PR | 01:04 |
| mup | PR snapd#4559 closed: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4559> | 01:05 |
| mup | PR snapd#4342 closed: userd: add support for a simple UI that can be used from userd <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4342> | 01:49 |
| mwhudson | i wonder what's going on here https://launchpadlibrarian.net/355232767/buildlog_snap_ubuntu_xenial_armhf_go-tip_BUILDING.txt.gz | 01:52 |
| mwhudson | i bet it's made an arm64 binary for some reason | 01:52 |
| zyga | mwhudson: hey | 02:00 |
| mup | PR snapcraft#1898 closed: docker: don't rely on snapcraft-classic <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1898> | 02:00 |
| mwhudson | zyga: hello | 02:00 |
| zyga | exec format error, never saw that one | 02:00 |
| zyga | yeah, feels like wrong arch | 02:00 |
| zyga | (but how?) | 02:00 |
| mwhudson | no idea | 02:00 |
| zyga | mwhudson: offtopic, can you please look at https://bugs.launchpad.net/snapd/+bug/1745584 - maybe it's just a missing policykit file in packaging? | 02:00 |
| mup | Bug #1745584: pkexec dialog doesn't appear for 'snap install' on Debian <snapd:New> <https://launchpad.net/bugs/1745584> | 02:00 |
| * zyga should go to sleep | 02:01 | |
| mwhudson | zyga: mmm could be | 02:02 |
| Son_Goku | mwhudson, i dunno, it doesn't work in centos even with the polkit file installed | 02:02 |
| mwhudson | yeah, looks like the polkit file is installed in debian too | 02:03 |
| mwhudson | data/polkit/io.snapcraft.snapd.policy /usr/share/polkit-1/actions/ | 02:03 |
| Son_Goku | same goes for Fedora | 02:03 |
| Son_Goku | I've been installing it for a while, no effect | 02:03 |
| Son_Goku | mwhudson: wait, this bug is about "snap install"? | 02:04 |
| Son_Goku | snap install doesn't query polkit at all | 02:04 |
| Son_Goku | like, zilch | 02:04 |
| Son_Goku | only GNOME Software does | 02:04 |
| Son_Goku | if that's supposed to work with "snap install" too, then this is horrifically broken | 02:04 |
| kyrofa | Hey tyhicks, if you're around, what is the status of using errno instead of kill for seccomp denials? | 02:07 |
| Son_Goku | mwhudson: https://src.fedoraproject.org/rpms/snapd/c/98b119302ae0d8d502f20877e0ecbf76a64ac1c9 | 02:07 |
| Son_Goku | yeah, I've been installing it and it doesn't have effect :/ | 02:07 |
| tyhicks | kyrofa: hey - it sounds like it is stuck waiting for a libseccomp-golang release and for other distros to include that release :( | 02:09 |
| tyhicks | kyrofa: https://github.com/snapcore/snapd/pull/3998/#issuecomment-358028579 | 02:09 |
| mup | PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Decaying> <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998> | 02:10 |
| tyhicks | kyrofa: I haven't had a chance to look into falling back to KILL if the available libseccomp-golang isn't new enough | 02:10 |
| tyhicks | all underlying work upstream and in Ubuntu is done | 02:10 |
| kyrofa | tyhicks, excellent, thank you very much :) | 02:11 |
| tyhicks | no problem | 02:11 |
| tyhicks | I wish it was already working but there were a lot of moving parts | 02:12 |
| kyrofa | Oh totally, glad to see it moving along though | 02:12 |
| kyrofa | We were just chatting about it at the sprint and none of us knew where the work stood. So now we do! | 02:13 |
| Son_Goku | kyrofa: either you or zyga could poke the maintainers of libseccomp and golang-github-seccomp-libseccomp-golang about backporting these things to current Fedora releases if it's ready to go | 02:22 |
| Son_Goku | (since both of you have FAS accounts, you're also able to do PRs against the packaging repos for both of these | 02:22 |
| Son_Goku | ) | 02:22 |
| mup | PR snapcraft#1899 opened: elf: readelf dependency <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1899> | 03:00 |
| mborzecki | morning | 06:15 |
| Chipaca | mborzecki: morning | 06:52 |
| mborzecki | Chipaca: hey | 06:52 |
| mborzecki | Chipaca: sorry :) | 07:57 |
| zyga | o/ | 07:59 |
| zyga | drat | 07:59 |
| zyga | I wanted to sleep | 07:59 |
| Chipaca | mborzecki: :-) | 08:00 |
| mborzecki | Chipaca: fwiw will looking at ProcessState be enough? | 08:00 |
| zyga | last night tests were utterly broken on networking | 08:00 |
| zyga | let's see how if today they fare better | 08:01 |
| Chipaca | mborzecki: not really, i think using a flag variable is the only way | 08:01 |
| Chipaca | mborzecki: the command just knows it was killed, not by whom | 08:02 |
| mborzecki | Chipaca: right | 08:02 |
| mborzecki | Chipaca: otoh maybe it's not worth it, unless the caller does something silly with the error the way it's now should be fine | 08:02 |
| * zyga has zero PRs open, that's ... new | 08:03 | |
| Chipaca | mborzecki: that was what I thought when I wrote it, but then I thought maybe we want to behave differently if the Run error is context.Canceled | 08:04 |
| mborzecki | Chipaca: imo adding a comment instead of a flag will be ok too :) | 08:04 |
| pstolowski | good morning | 08:04 |
| zyga | hey paweł! | 08:04 |
| mborzecki | zyga: pstolowski: morning | 08:04 |
| doko | https://launchpad.net/ubuntu/+source/snapd/2.30+18.04 ftbfs on most archs | 08:05 |
| Chipaca | mborzecki: it'd look like https://pastebin.ubuntu.com/26493696/ | 08:08 |
| zyga | doko: thank you for the heads up, we'll look into it | 08:08 |
| kalikiana | mornin' | 08:11 |
| zyga | hey kalikiana | 08:11 |
| doko | zyga: now given back. but seriously, hit the uploader for each day and one arch that this wasn't given back ... | 08:12 |
| mborzecki | Chipaca: right, so there's still a race but at least you'll get ctx.Err() if cancel was called or timeout was hit | 08:17 |
| Chipaca | mborzecki: I _could_ check that if the flag is set, the exec error looks like a 'killed' error | 08:18 |
| * Chipaca bbiab | 08:18 | |
| mup | PR snapd#4570 opened: release: snapd 2.31~rc2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4570> | 09:00 |
| * Chipaca grins as he writes TestRunRace | 09:40 | |
| pedronis | mvo: Chipaca: hi, what's the status of #4459 | 09:41 |
| mup | PR #4459: snap: add support for `snap advise-snap pkgName` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4459> | 09:41 |
| Chipaca | pedronis: what do you mean? | 09:41 |
| * Chipaca looks | 09:42 | |
| pedronis | it seems to be sitting there | 09:42 |
| pedronis | since a while | 09:42 |
| pedronis | but is not blocked | 09:42 |
| Chipaca | huh, i thought this was merged | 09:42 |
| pedronis | see | 09:42 |
| Chipaca | pedronis: the status is it only has one +1 | 09:43 |
| mvo | Chipaca, pedronis I think it should get a ack/nack from gustavo | 09:43 |
| Chipaca | i guess :-) | 09:43 |
| pedronis | mvo: it was not marked as such though | 09:43 |
| pedronis | I suppose I cand do that | 09:43 |
| mvo | Chipaca, pedronis it might be considered as redundant functionality. thanks, if you mark it that would be great, otherwise I will do it | 09:44 |
| pedronis | mvo: I requested a Gustavo reivew on it | 09:44 |
| Chipaca | mvo: redundant with what? | 09:44 |
| pedronis | probably needs a poke also | 09:44 |
| mvo | Chipaca: redundant with snap advice-snap --comand | 09:46 |
| mvo | Chipaca: oh, hold on a sec | 09:47 |
| mvo | Chipaca: I'm looking at the wrong PR, I think this one is uncontroversial mostly | 09:47 |
| pedronis | heh | 09:47 |
| pedronis | too many PRs | 09:47 |
| mvo | sorry, I was looking at the `snap run` one that advises on available commands | 09:47 |
| mvo | pedronis: yes :( | 09:47 |
| pedronis | mvo: I still recommend(very gently) trying to be a bit more agressive about closing PRs, otherwise it gets confusing | 09:48 |
| mvo | pedronis: agreed, let me start right now! | 09:48 |
| pedronis | close as in get merged or close as in close, whatever makes sense | 09:49 |
| mup | PR snapd#4424 closed: corecfg: pam_env can only handle 1024 byte <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4424> | 09:49 |
| pedronis | to be clear | 09:49 |
| mvo | :+1: | 09:50 |
| * Chipaca hugs mvo | 09:50 | |
| mup | PR snapd#4477 closed: snapenv: add SNAP_ARCH_TRIPLET <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4477> | 09:50 |
| zyga | o. | 09:52 |
| zyga | (which is like o/ but with me being more sleepy) | 09:53 |
| zyga | mvo: so I woke up at 7 ... and ... yeah | 09:53 |
| zyga | man | 09:53 |
| mvo | 4521 needs a second review probably an easy win | 09:53 |
| Chipaca | zyga: I woke at 4 | 09:53 |
| Chipaca | zyga: neener neener | 09:53 |
| mvo | zyga: good morning (and you looked at this already) | 09:53 |
| mvo | zyga: good morning | 09:53 |
| zyga | haha :) | 09:53 |
| mvo | zyga: rc2 is branched and uploaded to the ppa, waiting for the build | 09:53 |
| Chipaca | that's what peeking into scary finances does to you | 09:53 |
| zyga | excellent | 09:54 |
| mvo | I wonder if openoffice is building right now, build slots are in short supply it seems :/ | 09:54 |
| zyga | Chipaca: I was merging things at 3am | 09:54 |
| mvo | Chipaca: :( that sounds scary | 09:54 |
| Chipaca | zyga: i saw you restarting things at my 1am, so yeah :-) | 09:55 |
| zyga | Chipaca: yeah, travis and spread didn't love each other last night | 09:55 |
| mvo | very ironc that 2.31~rc2 is only build on powerpc yet (which used to be one of the slowest arches) | 09:56 |
| zyga | ;D | 09:56 |
| Chipaca | mvo: no spectre for ppc | 09:56 |
| mvo | heh, yeah | 09:56 |
| mvo | i was wondering if it is build on a 32bit chroot on ppc64el or something, that would also explain it | 09:56 |
| mvo | anyway | 09:56 |
| zyga | mvo: someone just pressed the "turbo" button | 09:57 |
| mvo | haha | 09:58 |
| * zyga remebmers his 386 now | 09:59 | |
| * Chipaca -> physio | 10:01 | |
| mwhudson | mvo: yes, pretty sure powerpc builds in a chroot on a 64 bit box now | 10:01 |
| mvo | ha! | 10:01 |
| mvo | thanks mwhudson | 10:01 |
| mwhudson | Kernel version: Linux bos02-powerpc-008 4.4.0-103-powerpc64-smp #126-Ubuntu SMP Mon Dec 4 16:57:45 UTC 2017 ppc64 | 10:03 |
| mup | PR #126: Ensure squashfs snaps keep all uid/gid and permissions on build <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/126> | 10:03 |
| ogra_ | ogra@localhost:~$ htop | 10:04 |
| ogra_ | snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks | 10:04 |
| ogra_ | hmm | 10:04 |
| * ogra_ reboots the board | 10:04 | |
| zyga | hmmm? | 10:04 |
| ogra_ | edge ... not sure if i tinkered the istall to death here or if there is actually a prob in the core snap from tonight | 10:05 |
| zyga | ogra_: let me know if it happens, I can look at my boards | 10:05 |
| mvo | Chipaca: hm, silly question. when we run command-not-found (snap advise-snap --command echo) - should we return test-snapd-tools because we have echo in there as a command? even though its not a toplevel? | 10:05 |
| zyga | mvo: btw, doko said that snapd 2.30 builds are failing | 10:07 |
| zyga | 09:05 < doko> https://launchpad.net/ubuntu/+source/snapd/2.30+18.04 ftbfs on | 10:07 |
| zyga | most archs | 10:07 |
| mvo | zyga: checking | 10:07 |
| Chipaca | mvo: no, i don't think so, not unless it's got an alias | 10:08 |
| mvo | zyga: fwiw https://launchpad.net/ubuntu/+source/snapd/2.30+18.04 is all green afaict | 10:08 |
| zyga | indeed | 10:09 |
| zyga | no idea, not very helpful today | 10:09 |
| zyga | (yet) | 10:09 |
| doko | mvo, zyga: yes, given back. you should not upload and run away, but read your build failure messages | 10:10 |
| doko | but maybe snaps don't have those anymore ... | 10:11 |
| * mvo wonders why he did not get those | 10:12 | |
| Chipaca | mborzecki: pushed a tweak to RunWithContext, including a test for the race | 10:12 |
| Chipaca | and now yes, to physio | 10:13 |
| mborzecki | Chipaca: thanks, will take a look | 10:15 |
| mup | PR snapd#4571 opened: data, cmd, packaging: use autotools to generate artifacts under data <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4571> | 10:17 |
| mborzecki | zyga: ^^ | 10:17 |
| ogra_ | zyga, i had temporary disabled the apparmor init script on that device (because apparmor stalls the boot for ~1min), apparently snapd doesnt create the snap-confine (i think on core it simply should do that) | 10:17 |
| ogra_ | *doesnt create the profile for ... | 10:17 |
| ogra_ | that actually seems the only thing this init script is needed for | 10:18 |
| zyga | ogra_: it does and that thing you disabled loads it | 10:19 |
| ogra_ | zyga, well, it seems to be the only profile this is needed for ... IMHO snapd could simply invoke the parser directly on core installs | 10:20 |
| ogra_ | core does not have any other profiles outside of snap apps ... where snapd already takes care correctly | 10:21 |
| zyga | ogra_: it has to be done on boot | 10:21 |
| zyga | ogra_: by that script | 10:21 |
| zyga | that script compiles and loads all the profiles (including snapd generated ones) | 10:21 |
| ogra_ | i understand that it has to be done o boot for classic installs ... | 10:21 |
| zyga | no | 10:21 |
| zyga | on all installs | 10:21 |
| zyga | I mean, snapd doesn't handle that at all | 10:22 |
| ogra_ | but on core there is only one profile that gets generated | 10:22 |
| ogra_ | which is the snap-confine one | 10:22 |
| zyga | no, all the per-snap profiles are handled by that guy | 10:22 |
| zyga | we could remove it but it's ... already doing it | 10:22 |
| ogra_ | hmm, i dont see it doig that | 10:22 |
| zyga | and there's no clear reason why that would help | 10:22 |
| zyga | (look at /var/lib/snapd/apparmor | 10:22 |
| zyga | that's also loaded by the script | 10:22 |
| ogra_ | well, the profiles are generated during snap install | 10:23 |
| ogra_ | just not for snap-confine | 10:23 |
| zyga | yes but on reboot they are not loaded | 10:23 |
| zyga | ogra_: I'm telling you the script does useful work on boot, if we drop that script we have to put some thing on early boot, before _any_ snap can start | 10:23 |
| zyga | ogra_: I'm not sure that should be snapd; it could be but I don't see a clear advantage | 10:24 |
| zyga | ogra_: not on boot speed for sure | 10:24 |
| ogra_ | well, thats different to what i see :) but i belive you :) | 10:24 |
| zyga | ogra_: there's a variable somewhere that makes it look at /var/lib/snapd/apparmor/profiles | 10:24 |
| zyga | ogra_: we also load profiles on startup if they _changed_ | 10:24 |
| ogra_ | (all snaps functioned fine for the last week while the script was off ... only a core refresh made snap-confine fail then) | 10:24 |
| ogra_ | ... but probably the profiles simply never changed in that time despite me randomly installing/removing7refreshing apps | 10:25 |
| ogra_ | anyway, re-enabling the script gets me 3min boots back but also makes snap-confine work again ... so its a user error | 10:26 |
| zyga | ogra_: how slow is it btw? | 10:26 |
| cjwatson | Chipaca: ppc does suffer from Spectre, FWIW (maybe not the actual 32-bit-only chips, I'm not sure, but certainly more modern ones) | 10:26 |
| zyga | maybe there is something wrong? | 10:26 |
| zyga | cjwatson: hey, I still _run_ one :) | 10:26 |
| ogra_ | zyga, lol ... yes ... thats what i'm trying to find :P | 10:26 |
| zyga | ogra_: maybe add a echo to the script (or something like that) | 10:27 |
| zyga | ogra_: so that we know when it starts and when it stops | 10:27 |
| zyga | ogra_: not sure if that's clearly readable from logs | 10:27 |
| ogra_ | (it is a 200-500MHz 256M ram board ... but 3mins are definitely to long even for that) | 10:27 |
| zyga | ogra_: so, there's a cache thing there but maybe it's broken and not used | 10:27 |
| ogra_ | systemd-analyze is usually pretty correct in its timings | 10:27 |
| zyga | ogra_: normally apparmor should read the profile, check with the cache and insert a cached compiled blob if one is recent | 10:27 |
| ogra_ | yeah, the cache is definitely empty on all my boards | 10:28 |
| zyga | ogra_: otherwise it would compile the profile, which is slow, save the cache and load it in the kernel | 10:28 |
| ogra_ | jamie pointed that out before | 10:28 |
| zyga | ogra_: not sure how much of that is done in intrd | 10:28 |
| zyga | ogra_: and how much in early systemd | 10:28 |
| ogra_ | (seems there is some general issue with the cache ) | 10:28 |
| zyga | ogra_: oh? | 10:28 |
| ogra_ | initrd doesnt do any apparmor stuff | 10:28 |
| ogra_ | only the mounting | 10:28 |
| zyga | there are two cache locations | 10:28 |
| zyga | for some historic reason AFAIR | 10:28 |
| zyga | did you check both? | 10:28 |
| ogra_ | well, jamie pointed me to /etc | 10:28 |
| zyga | look at /var/cache/apparmor | 10:29 |
| ogra_ | and that one is definitely empty on all boards i have | 10:29 |
| ogra_ | yeah, there are files | 10:29 |
| zyga | see if it makes any difference | 10:29 |
| zyga | even with a hand watch | 10:29 |
| zyga | if you remove them | 10:29 |
| zyga | if so then the cache works | 10:29 |
| zyga | if not ... well, slow boards are slow | 10:29 |
| ogra_ | well | 10:29 |
| ogra_ | snapd probing mmcblk1rpmb devces for assertions takes quite some time too ;) | 10:30 |
| ogra_ | there are some obvious issues (like this one) ... but they are not enough to get me to a sane boot speed yet | 10:30 |
| zyga | how much? | 10:30 |
| ogra_ | dunno, several tens of seconds | 10:31 |
| ogra_ | 15-20 i'D say ... thats sadly a service that doesnt log anything ... | 10:31 |
| zyga | is that blocking boot or does it happen in parallle? | 10:31 |
| zyga | *parallel | 10:31 |
| ogra_ | (i havent debugged that one yet, its an obvious one) | 10:31 |
| ogra_ | others are 30sec for mounting loop devices | 10:32 |
| ogra_ | thats more worrying | 10:32 |
| ogra_ | console-setup 20sec ... keyboard-setup 15sec ... | 10:32 |
| ogra_ | the device probing is blocking boot | 10:33 |
| mvo | ogra_: could you run systemd-analyize plot and copy the output somewhere? | 10:34 |
| ogra_ | well, the system is havily modified atm ... i'll do that once i flashed it freshly ... here is a top list of blame though https://paste.ubuntu.com/26494246/ | 10:35 |
| zyga | ogra_: the probing issue | 10:35 |
| zyga | ogra_: I honestly think it should not be a toggle | 10:35 |
| zyga | ogra_: but there should be a way to tweak this in the gadget | 10:35 |
| ogra_ | zyga, ? | 10:35 |
| zyga | ogra_: so that you can use udev tagging to blacklist media | 10:36 |
| ogra_ | ah | 10:36 |
| ogra_ | yeah | 10:36 |
| zyga | ogra_: so that certain internal devices are just skipped | 10:36 |
| zyga | ogra_: it's a simple system, extensible to devices and makes sense as a design IMO | 10:36 |
| ogra_ | well, you never ever want to probe mmcblkXrpmb or mmcblkXbootX | 10:36 |
| zyga | ogra_: I don't think that's true, that's absolute and those rarely turn out true | 10:37 |
| ogra_ | but thats also something systemd needs to learn, not only snapd | 10:37 |
| mvo | ogra_: thanks, the plot would be nice at some point but not urgent | 10:37 |
| mup | PR snapd#4572 opened: mir: software clients need access to shared memory /dev/shm/#* <Created by gerboland> <https://github.com/snapcore/snapd/pull/4572> | 10:37 |
| zyga | ogra_: as long as you can set an attribute that makes it skip probing and you can express that in the gadget it feels sufficient | 10:37 |
| ogra_ | zyga, right ... systemd doesnt have such a flag yet ... which is why i ignored that bit for now for snapd as well | 10:38 |
| ogra_ | i'll get to that later ... | 10:38 |
| ogra_ | thats one of the bits that are understood :) | 10:38 |
| zyga | ogra_: it's not a systemd flag | 10:38 |
| zyga | ogra_: it's an udev attribute | 10:38 |
| ogra_ | (i have many in this particular boot process that arent :) ) | 10:38 |
| zyga | ogra_: like MM_SKIP_PROBING (or whatever it was called) | 10:38 |
| ogra_ | zyga, hmm, i only know UDISKS_IGNORE ... but that wouldnt help with systemd fsck or snapd autoimport | 10:41 |
| zyga | ogra_: fsck I cannot speak of, those are separate issues | 10:41 |
| zyga | ogra_: but the job that tries to look for assertions is under our control | 10:41 |
| zyga | ogra_: so it could just skip devics with a given attribute | 10:41 |
| ogra_ | zyga, would be helpful if the autoimport udev rule could mention the variable in the comment somehow ... how would porters know about it ? | 10:43 |
| ogra_ | (without reading snapd's source) | 10:44 |
| zyga | ogra_: sure that's documentation; I'm describing a feature that doesn't exist | 10:44 |
| ogra_ | oh | 10:44 |
| zyga | ogra_: it's just something that we would doucment in device maker's book or similar | 10:44 |
| ogra_ | i thought you said there is "MM_SKIP_PROBING" | 10:45 |
| zyga | ogra_: I'm saying that such an attribute, IMO, makes more sense than a big bool flag for _users_ | 10:45 |
| ogra_ | well | 10:45 |
| zyga | ogra_: that was a reference to existing similar attribute for modem manager and serial ports | 10:45 |
| ogra_ | that flag will only make the udev rule skip | 10:45 |
| ogra_ | it wont prevent the unit fro running | 10:45 |
| ogra_ | *from | 10:45 |
| zyga | yes but we could make that unit run the prober with a device, so that control is reversed | 10:46 |
| zyga | systemd picks the devices, prober probes one | 10:46 |
| ogra_ | most customers i worked with til now want that stuff completely off so people cant tinker with USB sticks | 10:46 |
| zyga | those could then even run faster as they would happen in parllel | 10:46 |
| zyga | ogra_: that's okay, but it should be a gadget decision, not a toggle for users | 10:46 |
| ogra_ | it simply wastes cycles, even if it is a no-op | 10:46 |
| ogra_ | yeah | 10:47 |
| ogra_ | indeed it should be a gadget thing | 10:47 |
| ogra_ | (like rsyslog or disabling ssh access) | 10:47 |
| ogra_ | though here the issue is more of a subsequent thing ... i want the deices to be hidden completely during boot so fsck will ignore them too ... | 10:49 |
| ogra_ | (autoimport is just the next thing in the chain here ... ) | 10:50 |
| * zyga -> physical activities | 10:57 | |
| zyga | ogra_: I'm so mentally tired I will do some house chores to vent my mind | 10:57 |
| zyga | ogra_: I agree on fsck | 10:57 |
| zyga | ogra_: though I would discuss it separately | 10:58 |
| mvo | cachio: good morning! 2.31~rc2 for armhf/arm64 is ready, the other ones are still building | 11:07 |
| cachio | mvo, good morning, already downloading images | 11:11 |
| mvo | cachio: great, I publish the other ones as soon as I can | 11:11 |
| cachio | mvo, great | 11:11 |
| * zyga hopes for one smooth release | 11:17 | |
| mvo | 2.30 was not too bad | 11:17 |
| zyga | mvo: going out with rc2 would be awesome :) | 11:18 |
| mvo | cachio: i386/amd64 ready now as well | 11:19 |
| * zyga refreshes to beta | 11:25 | |
| zyga | mvo: oh | 11:25 |
| zyga | mvo: we didn't do one thing | 11:25 |
| zyga | that piece of code that wrote the snap.mount unit (under proper name | 11:26 |
| zyga | we don't have that | 11:26 |
| zyga | for reexec | 11:26 |
| zyga | but I guess it's okay for now, as long as packages are coming out, not a regression in any way | 11:26 |
| mvo | zyga: yeah, it will only be fixed in lxd hosts with the right snapd version | 11:27 |
| mvo | zyga: eh deb/rpm | 11:27 |
| mvo | zyga, pstolowski there is a bugreport that we should document that hooks use dash - I wonder if we should just switch them to bash. wdyt? | 11:27 |
| ogra_ | oh, please dont | 11:28 |
| mvo | pstolowski: do you think you could check 1745015? | 11:28 |
| mvo | ogra_: why not? | 11:28 |
| ogra_ | (dealing with a 200MHz 256M single core device here ... such a switch would have some impact) | 11:28 |
| zyga | mvo: is there any mandate for the hooks to be anything? they are just executables, could be dash, python or elf | 11:28 |
| ogra_ | bash eats about 5Mb while dash lives in the kilobyte range | 11:29 |
| ogra_ | (and used to be massively slower as well, back when debian did the research ... that might have changed since 2007 though) | 11:29 |
| mvo | zyga: there is no mandate for this | 11:30 |
| ogra_ | mvo, assuming you dont mean live-build hooks here but app hooks | 11:30 |
| pstolowski | mvo, interesting. will look into 1745015 | 11:31 |
| mvo | ogra_: snap hooks, yes. well, fair enough. | 11:31 |
| ogra_ | mvo, most upcoming ubuntu core customers in the near future will be in a similar HW range, every byte of ram counts here | 11:31 |
| pstolowski | mvo, I agree with zyga; i think documenting is enough | 11:32 |
| mvo | pstolowski: ok | 11:32 |
| ogra_ | (and on single core-low-speed cpus also every herz :) ) | 11:32 |
| ogra_ | s/herz/hertz/ | 11:32 |
| ogra_ | mvo, oh, during my debugging i noticed that "systemctl list-dependencies" on core devices shows quite a bunch of red dots, i wonder if we need to handle some units more gracefully or need to disable them | 11:39 |
| ogra_ | i.e. "systemd-machine-id-commit.service" ... completely useless since we set the machine-id from the initrd ... but it gets run nontheless | 11:40 |
| ogra_ | or systemd-hwdb-update.service ... (the hwdb is readonly) | 11:41 |
| cjwatson | mvo: I think the thing that bug reporter is missing is that /bin/sh is the default in normal Ubuntu too | 11:41 |
| cjwatson | mvo: err /bin/sh -> dash | 11:41 |
| cjwatson | they've obviously just configured it differently | 11:42 |
| Chipaca | cjwatson: wrt spectre on ppc, I was thinking exclusively of the pre-2006 chips (have there been 32-bit ppc chips since then?) | 11:46 |
| Chipaca | also I thought powerpc meant 32 bits, and the newer ones were ppc64le or w/e | 11:47 |
| cjwatson | yeah but you said ppc which is a bit ambiguous | 11:48 |
| Chipaca | ah, my bad then (i meant powerpc i think) | 11:49 |
| Chipaca | in my defence my only powerpc machine was a nubus-ppc one | 11:49 |
| cjwatson | there've certainly been embedded 32-bit chips since then, and e.g. the e600 has out-of-order execution, branch prediction, and such; wouldn't surprise me if you could get something like Spectre to work but I don't know if anyone's bothered | 11:49 |
| * zyga starts to see the light at the end of the tunnel :) | 11:51 | |
| zyga | my office gets messy quickly | 11:52 |
| Chipaca | somebody's got to be trying to get spectre to work on a router | 11:52 |
| Chipaca | mborzecki: you around? | 11:52 |
| mborzecki | Chipaca: yeah, trying to go through #4551 | 11:53 |
| mup | PR #4551: ifacestate: do not auto-connect manually disconnected interfaces <Created by stolowski> <https://github.com/snapcore/snapd/pull/4551> | 11:53 |
| Chipaca | mborzecki: just a quick Q: your version of the if in #4569 implies two class assertions, right? | 11:53 |
| mup | PR #4569: osutil: add ContextWriter and RunWithContext helpers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4569> | 11:53 |
| mborzecki | Chipaca: sadly yes | 11:54 |
| Chipaca | ie one to get a ExitError, one to get a WaitStatus; that's why you said more verbose | 11:54 |
| Chipaca | mborzecki: fair enough. I'll rewrite it that way. i had it like that (except I didn't know about Signal() which makes it more readable, and probably worthwhile) | 11:54 |
| mborzecki | Chipaca: didn't know about it either, actually read through the exec code in stdlib :) | 11:55 |
| pstolowski | mborzecki, thanks! | 11:55 |
| mup | PR snapd#4557 closed: osutil: add DirExists and IsDirNotExist <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4557> | 12:02 |
| zyga | ok, one last power strip | 12:05 |
| zyga | and I should be ready | 12:05 |
| niemeyer | Hey hey | 12:08 |
| * ogra_ puts a dollar in zyga's waistband for that power strip ... | 12:09 | |
| Chipaca | ogra_: I did _not_ need that image | 12:09 |
| ogra_ | lol | 12:10 |
| * zyga googles waistband | 12:10 | |
| zyga | oho | 12:10 |
| zyga | *gulp* | 12:10 |
| * zyga hugs ogra_ and Chipaca *together* | 12:11 | |
| ogra_ | no, no ... we didnt order that lapdance !!!s | 12:11 |
| * Chipaca steals the dollar and goes to get lunch | 12:11 | |
| zyga | the dollar is actually a beer bottle cap | 12:12 |
| * zyga looks at unit tests again | 12:22 | |
| === LarreaMikel1 is now known as LarreaMikel | ||
| Chipaca | zyga: guess lunch is roaches then | 12:32 |
| zyga | Chipaca: fry slowly | 12:32 |
| * Chipaca squints at Failed tasks: 1 | 12:33 | |
| Chipaca | - linode:ubuntu-14.04-64:tests/main/server-snap:pythonServer | 12:33 |
| zyga | what's the failure? | 12:34 |
| ogra_ | oh | 12:45 |
| ogra_ | is bpf a hard kernel requirement nowadays ? | 12:45 |
| zyga | ogra_: yes, I think so | 12:48 |
| ogra_ | aha | 12:49 |
| ogra_ | ppisati, seems our default configs in the sample kernels do not enforce bpf ^^^ | 12:49 |
| mup | PR snapd#4573 opened: tests: enable content sharing test for $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4573> | 12:50 |
| zyga | mvo: if this passes please drop it into final release | 12:53 |
| zyga | I forgot about it yesterday | 12:54 |
| * zyga is very excited about content sharing getting a huge boost in 2.31 | 12:54 | |
| zyga | but first let's drop those unit tests :) | 12:54 |
| mvo | zyga: which one, 4573? | 12:57 |
| zyga | yep | 12:57 |
| zyga | it just enables a test that I wrote ahead of time | 12:57 |
| zyga | and rigged to skip one case | 12:57 |
| zyga | now it should all pass | 12:57 |
| mup | PR snapd#4570 closed: release: snapd 2.31~rc2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4570> | 12:59 |
| mup | PR snapd#4569 closed: osutil: add ContextWriter and RunWithContext helpers <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4569> | 13:02 |
| ppisati | ogra_: i'm going to add it to the list of configs in the snapcraft/kernel_plugin | 13:21 |
| zyga | mvo: please merge https://github.com/snapcore/snapd/pull/4573 | 13:24 |
| mup | PR #4573: tests: enable content sharing test for $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4573> | 13:24 |
| zyga | it's green now | 13:24 |
| ppisati | ogra_: which BPF options? i guess the BPF_SYSCALL filtering option | 13:26 |
| ogra_ | ppisati, yeah, i guess so ... all i justz noticed is that on a misbehaving device /proc/filesystems doesnt list bpf ... mnot sure what options are exactly needed ... i know the pi kernels have all of them though | 13:27 |
| ppisati | ogra_: well, when you figure it out, add it to the list of required options here and send a pull req | 13:28 |
| ppisati | ogra_: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/kernel.py | 13:28 |
| ppisati | 'required_snappy' i guess | 13:28 |
| mup | PR snapcraft#1900 opened: Parent relative symlinks <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1900> | 13:32 |
| zyga | jjohansen: o/ | 13:51 |
| jjohansen | hey zyga | 13:51 |
| zyga | jjohansen: long time no see, how are you doing | 13:51 |
| jjohansen | zyga: well I was doing well, but I have a feeling that is about to change | 13:51 |
| jjohansen | :) | 13:51 |
| pstolowski | mvo, so my spread test for that install hook bug just produced 'mesg: ttyname failed: Inappropriate ioctl for device' and hung; waiting to see if the hook gets aborted as it should. | 13:51 |
| zyga | oh? what's going on? | 13:52 |
| mvo | pstolowski: aha, interessting | 13:52 |
| jjohansen | zyga: oh I was just assuming you pinged me because you have a bug for me :) | 13:52 |
| zyga | ah, no :) | 13:52 |
| jjohansen | zyga: ah, well then I am good :D | 13:54 |
| mup | PR snapd#4573 closed: tests: enable content sharing test for $SNAP <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4573> | 13:55 |
| zyga | thank you | 13:55 |
| pstolowski | mvo, ok. puzzling. install hook got killed eventually, install was aborted. all as expected. | 13:57 |
| cachio | mvo, https://paste.ubuntu.com/26495194/ | 13:58 |
| pstolowski | mvo, ah wait, he is not installing, he is using snap try | 13:58 |
| cachio | this is what Ii see in the pi21 | 13:58 |
| cachio | mvo, there is no /snap/core/current | 13:58 |
| cachio | mvo, and many tests failing because of that | 13:58 |
| * kalikiana lunch | 13:58 | |
| cachio | mvo, also the test-snapd-tools snap is not in /snap | 13:59 |
| mvo | cachio: that is strange, what does your state.json look like? i.e. python3 -m json.tool /var/lib/snapd/state.json | 13:59 |
| mvo | mborzecki: just to double check, the license for local snaps is displayed if these snaps have a "license:" field in their snap.yaml? | 13:59 |
| cachio | mvo, https://paste.ubuntu.com/26495214/ | 14:00 |
| mvo | cachio: strange, looks like state.json and content is toally out of sync | 14:03 |
| mvo | cachio: I wonder if this is a fluke or if we somehow broke the testsuite | 14:04 |
| zyga | mvo: maybe backup/restore is messed up | 14:04 |
| zyga | we sometimes see that the state was modified while it was being saved | 14:04 |
| mvo | zyga: yeah, something along these lines | 14:04 |
| cachio | mvo, not sure yet, something similar is happening in dragonboard | 14:04 |
| cachio | pi3 is working fine | 14:04 |
| mvo | strange | 14:04 |
| zyga | it's a race | 14:05 |
| zyga | it doesn't matter where it failed | 14:05 |
| cachio | mvo, same issue with test-snapd-tools | 14:05 |
| mvo | Chipaca: does https://github.com/snapcore/snapd/pull/4531#pullrequestreview-92931228 capture the discussion during the standup? if so I will merge the PR and cherry-pick for 2.31 | 14:05 |
| mup | PR #4531: cmd/snap: display snap license information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4531> | 14:05 |
| mvo | cachio: and its also in the state I assume? so the same out-of-sync issue(?) | 14:06 |
| Chipaca | mvo: except for the very last commit, i think | 14:06 |
| cachio | mvo, checking | 14:06 |
| mborzecki | mvo: it should, there's a /v2/snaps/<name>, as long as the response contains the license it will be shown, i can try and add a quick test case for it | 14:06 |
| mvo | Chipaca: commit or comment? | 14:07 |
| mvo | mborzecki: yeah, I think if we could have a test case that would be best | 14:08 |
| Chipaca | mvo: commit | 14:08 |
| Chipaca | mvo: ie the one that removed the “license: unknown” | 14:08 |
| mvo | mborzecki, Chipaca: indeed, sorry for this. lets just revert 60074f0 and the following one now that we have agreement on that it should be part of the snap | 14:09 |
| cachio | mvo, yes | 14:10 |
| cachio | mvo, also I see in the syslog many of these errors ---> Jan 31 11:15:58 localhost snapd[1369]: 2018/01/31 11:15:58.355309 stateengine.go:101: state ensure error: devicemgr: snap "core" has "install-snap" change in progress | 14:11 |
| mborzecki | mvo: just to be clear, revert the last 2 commits right? | 14:11 |
| mvo | mborzecki: yes | 14:12 |
| mvo | mborzecki: sorry for the confusion about this one, I was under the (wrong) impression that the store should be the authority and I'm happy that its the snap | 14:12 |
| mborzecki | mvo: also the text that was shown there is `(undefined)`, should I change it to unknown instead? | 14:12 |
| mvo | mborzecki: yeah, I think "unkown" is slightly better | 14:13 |
| mvo | niemeyer: for unknown licenses, "license: unknown" in `snap info` output? sounds reasonable? | 14:14 |
| doko | mvo, zyga: snapd has autopkg test regressions | 14:15 |
| zyga | where can we see them? | 14:17 |
| mvo | zyga: I think we have this problem that the store categories changed :( so the searching test fails now | 14:18 |
| * ogra_ scratches head about unlogical kernel config naming | 14:23 | |
| ogra_ | # CONFIG_BPF_JIT is not set | 14:23 |
| ogra_ | CONFIG_HAVE_BPF_JIT=y | 14:23 |
| ogra_ | how can the second one be true if the first one is false ... | 14:24 |
| zyga | you have it (it's supported in arch) but not enabled | 14:24 |
| zyga | that's how I see it | 14:24 |
| ogra_ | hmm | 14:24 |
| ogra_ | so that would mean userspace you think ? | 14:24 |
| zyga | no, I mean the kernel has code to emit jit for bpf on this architecture (that's the HAVE part does) | 14:25 |
| zyga | (just guessing though) | 14:25 |
| ogra_ | ah | 14:25 |
| ogra_ | ok | 14:25 |
| * ogra_ gets it | 14:25 | |
| zyga | but the config option to enable it is off | 14:25 |
| ogra_ | anyway ... just curious ... i'll just enable it anyway | 14:25 |
| Chipaca | pstolowski: I got a panic in config, suspect I'm doing something wrong :-) do you have a moment to take a look? | 14:30 |
| pstolowski | Chipaca, what is it? | 14:31 |
| Chipaca | pstolowski: I'm doing : tr.Set(aSnap, "", aConfig) | 14:32 |
| Chipaca | pstolowski: and overlord/configstate/config/helpers.go:80 throws an 'index out of range' | 14:33 |
| niemeyer | mvo: Yeah, sounds good | 14:33 |
| niemeyer | mvo: I'm half-way through typing out a proposal for custom licenses too | 14:33 |
| mvo | mborzecki: -^ so "license: unknown" is fine, very happy that this gets pulled in :) | 14:34 |
| pstolowski | Chipaca, key cannot be "", I'm sure we prevent it in snap/snapctl set, but apparently not at this level | 14:35 |
| mborzecki | mvo: pushing update in a short while, turns out the biggest issue is forging the data that snapd returns | 14:35 |
| Chipaca | pstolowski: then how do I set the whole config? (because key is "" for get to get the whole config) | 14:35 |
| pstolowski | Chipaca, well, I've implemented "" on the get side for convienience to make it easy to discover config keys. but we don't have an equivalent for setting all at once | 14:41 |
| pstolowski | Chipaca, I mean - not for transaction.Set at least | 14:41 |
| pstolowski | Chipaca, you can of course workaround that by iterating over root elements and calling tr.Set(..) for them manually | 14:43 |
| Chipaca | pstolowski: that sounds very additive | 14:43 |
| pstolowski | Chipaca, or just make tr.Set smarter :} | 14:43 |
| pedronis | well you need also to remove all them | 14:43 |
| pedronis | which we don't quite support either | 14:44 |
| Chipaca | I need to set the config to the thing in the snapshot, not add to it | 14:44 |
| Chipaca | if the config is empty, empty it | 14:44 |
| pedronis | seems you need to bypass transactions | 14:44 |
| pedronis | or teach Set about "" or something like that | 14:44 |
| Chipaca | I don't mind bypassing transactions :-D | 14:44 |
| pedronis | replacing the whole thing is not quite the use case for transaction | 14:45 |
| pedronis | s | 14:45 |
| pedronis | then it's more matter of not breaking too many abstractions | 14:45 |
| pstolowski | ah, I see, yes it's additive that way | 14:45 |
| pedronis | Chipaca: sounds we need configstate.Set or something | 14:45 |
| Chipaca | augh | 14:46 |
| pedronis | for your use case | 14:46 |
| Chipaca | I need to step away for a bit | 14:46 |
| pedronis | well configstate/config.Set | 14:46 |
| pedronis | maybe | 14:46 |
| pstolowski | yes, that should be very straightforward | 14:46 |
| * pedronis doesn't remember the how the code org looks like exactly | 14:47 | |
| mup | PR snapcraft#1896 closed: elf: do not strip rpaths that contain $ORIGIN <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1896> | 14:47 |
| mvo | mborzecki: oh, a spread test is fine, just adding "license: ..:" to one of the test snaps | 14:47 |
| mborzecki | mvo: well, i've updated the unit tests anyway :) | 14:48 |
| mvo | mborzecki: .) ok | 14:48 |
| niemeyer | mvo, mborzecki: https://forum.snapcraft.io/t/support-for-custom-license-text/3671/16 | 14:49 |
| niemeyer | Chipaca: ^ | 14:49 |
| kalikiana | re | 15:07 |
| greyback | it possible for one snap app to call another snap app? Something like a poor-man's socket activation? | 15:12 |
| zyga | greyback: not without an interface | 15:13 |
| greyback | zyga: even inside the same snap? | 15:14 |
| greyback | i.e. appA & appB in the snap, I want appB to call appA | 15:14 |
| zyga | greyback: that's more subtle: if you want to go through the activator then you won't be able to | 15:15 |
| zyga | greyback: if you call the same command as that activator then sure | 15:15 |
| zyga | greyback: but you won't get the permissions of the other app | 15:15 |
| greyback | zyga: yeah, it was the permissions I was hoping to keep separate | 15:16 |
| greyback | so xwayland has tight security, and then my x app has more freedom | 15:16 |
| greyback | guess I'll give that up for now | 15:17 |
| zyga | 10 failures left | 15:19 |
| zyga | 7 failures :) | 15:20 |
| mup | PR snapd#4531 closed: cmd/snap: display snap license information <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4531> | 15:22 |
| mvo | thanks mborzecki | 15:23 |
| zyga | libreoffice 6.0 is out, will the snap be refreshed? | 15:50 |
| zyga | hhh | 16:04 |
| zyga | ah :) | 16:04 |
| zyga | man that was silly | 16:04 |
| zyga | 3 errors left, will be done in a moment | 16:04 |
| Chipaca | pstolowski: pedronis: I think I'm going to add a helper to do just this set/unset to config; should I add it to config, or to configstate? | 16:15 |
| Chipaca | it'll be a separate pr | 16:15 |
| pedronis | Chipaca: config | 16:16 |
| Chipaca | ok | 16:16 |
| Chipaca | pedronis: is config sorta-kinda the 'backend' of configstate? | 16:16 |
| pedronis | otherwise it cannot be used from snapstate | 16:16 |
| Chipaca | this is for use from snapshotstate, but ok | 16:16 |
| pedronis | Chipaca: no, it's mostly the accessor that can be used by any other *state | 16:17 |
| pstolowski | +1 (config) | 16:17 |
| Chipaca | k | 16:17 |
| pedronis | Chipaca: confistate itself imports a bunch of *state | 16:17 |
| pedronis | so that's why config exists | 16:17 |
| pedronis | otherwise circular imports | 16:17 |
| Chipaca | is there any reason a snapshot should save a revision-config? | 16:18 |
| Chipaca | the "what happens if you restore a revision that isn't current" question comes to mind | 16:18 |
| pedronis | those are used one revert I think | 16:18 |
| pedronis | no? | 16:18 |
| pedronis | are you snapshotting a revision? or all of them? | 16:19 |
| Chipaca | pedronis: a single one | 16:19 |
| Chipaca | the current one | 16:19 |
| pedronis | and you restore the current one? | 16:19 |
| pedronis | in that case I don't think revision-config is relevant | 16:20 |
| Chipaca | no, restore restores whatever was snapshot | 16:20 |
| pedronis | but puts it backa as current? | 16:20 |
| Chipaca | no | 16:20 |
| pedronis | then it's complicated | 16:20 |
| Chipaca | yes | 16:20 |
| pstolowski | in that case i think you should restore your snapshot into whatever is current rev | 16:20 |
| pedronis | you need to care about about revision-config | 16:20 |
| pedronis | I think | 16:20 |
| pstolowski | (so,just config) | 16:20 |
| Chipaca | maybe restore should block restore unless the revision is current | 16:20 |
| Chipaca | then the problem goes away :-) | 16:21 |
| Chipaca | at least for now | 16:21 |
| Chipaca | maybe in a followup it can restore to current always, but doing that to a 'live' snap makes me nervous | 16:22 |
| Chipaca | anyway, going with "config" for now | 16:23 |
| mup | PR snapd#4574 opened: tests: add integration for local snap licenses <Created by mvo5> <https://github.com/snapcore/snapd/pull/4574> | 16:28 |
| mup | PR snapd#4575 opened: config: add (Get|Set)SnapConfig to do bulk config e.g. from snapshots <Created by chipaca> <https://github.com/snapcore/snapd/pull/4575> | 16:37 |
| Chipaca | pedronis: pstolowski: ^ a quickie (i hope) | 16:37 |
| pstolowski | looking | 16:37 |
| zyga | 2 lef | 16:39 |
| zyga | 2 left :) | 16:39 |
| Chipaca | zyga: 2 leffe? | 16:41 |
| zyga | Chipaca: two tests failing; almost done :) | 16:42 |
| zyga | 0! | 16:42 |
| pstolowski | Chipaca, +1 | 16:43 |
| Chipaca | why can i edit your review summary | 16:44 |
| mup | PR snapd#4576 opened: cmd/snap-update-ns: large refactor / update of unit tests <Created by zyga> <https://github.com/snapcore/snapd/pull/4576> | 16:48 |
| zyga | big n boring | 16:48 |
| zyga | but had to be done | 16:48 |
| zyga | now I feel good about that code :) | 16:48 |
| zyga | I also tweaked a few strings based on one more patch I had, the error messages are nicer | 16:49 |
| zyga | mvo: ok, I think I can close that chapter for today, I can do code reviews or I can write about the content interface improvements | 16:50 |
| mup | PR snapcraft#1901 opened: elf: check if file exists before checking if ELF <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1901> | 16:50 |
| mvo | zyga: writing sounds good | 16:51 |
| zyga | mvo: okay, let's get that done :) | 16:52 |
| zyga | if you include that PR in ~rc3 (if there is one) that's okay but it's not mandatory, I only added a load of unit tests and tweaked some error strings | 16:53 |
| mvo | zyga: yeah, just looking at it | 16:53 |
| * zyga tries to recall why x.snapd.symlink=foo is not conveyed through Entry.Name, hmm hmm | 16:57 | |
| zyga | maybe it would be nicer to read | 16:57 |
| zyga | but I did that for *some* reason, I remember that much | 16:57 |
| zyga | well, did it the way it is now | 16:57 |
| zyga | those tests took about two days to write in this final form | 16:57 |
| * kalikiana going to wrap up for the day | 17:02 | |
| zyga | o/ | 17:02 |
| zyga | Chipaca: question on 4575 | 17:04 |
| Chipaca | zyga: or is there | 17:05 |
| Chipaca | zyga: (i don't see a question) | 17:05 |
| zyga | Chipaca: hmmmm | 17:05 |
| zyga | it got eaten | 17:05 |
| Chipaca | github is hungry today | 17:05 |
| ogra_ | omnomnom | 17:05 |
| zyga | I was asking why are we returning json.RawMessage by value | 17:05 |
| Chipaca | zyga: it's a []byte; it's already a pointer | 17:06 |
| zyga | and if that is safe actually (shallow copy) | 17:06 |
| zyga | ah, perfect | 17:06 |
| zyga | thanks! LGTM | 17:06 |
| Chipaca | I don't know why config uses *json.RawMessage (and it might, because it does some funky stuff), but these two functions are un-funky | 17:06 |
| Chipaca | might need to* | 17:07 |
| ogra_ | sigh ... | 17:07 |
| zyga | Chipaca: was that related to some bug in json | 17:08 |
| zyga | where you need the pointer to get some methods right | 17:08 |
| zyga | something like that echoes in my head | 17:08 |
| Chipaca | it might be; if it is, pedronis will know :-) | 17:08 |
| zyga | + snap install test-snapd-control-consumer | 17:08 |
| zyga | error: cannot install "test-snapd-control-consumer": cannot get nonce from | 17:08 |
| zyga | store: store server returned status 418 | 17:08 |
| zyga | 418? | 17:08 |
| Chipaca | aw, so close to 419 | 17:08 |
| zyga | is that my bus home? :) | 17:08 |
| Chipaca | ah no | 17:09 |
| Chipaca | 418 is the one | 17:09 |
| zyga | what is it? | 17:09 |
| zyga | should we retry that? | 17:09 |
| Chipaca | 418 I'm a teapot | 17:09 |
| ogra_ | jdstrand, (or any other securiteer ) ... looking at different core kernels i see "bpf" in /proc/filesystems ... the kernel i'm currently working on does not show it and i cant find what Kconfig option would enable the bpf filesystem, do you happen to have any hint (google isnt helpful either) | 17:09 |
| Chipaca | zyga: which in our tests means it is (hopefuly!) not talking to an actual server | 17:09 |
| zyga | haha, cute :) | 17:10 |
| pedronis | it's talking to the fakestore and trying to setup a device session | 17:10 |
| pedronis | or something like that | 17:10 |
| pedronis | why is it doing that though? | 17:10 |
| pedronis | only now | 17:10 |
| zyga | it is in here https://api.travis-ci.org/v3/job/335552657/log.txt | 17:12 |
| zyga | in this PR https://github.com/snapcore/snapd/pull/4562 | 17:12 |
| mup | PR #4562: debian: add a zenity|kdialog suggests <Created by mvo5> <https://github.com/snapcore/snapd/pull/4562> | 17:12 |
| pedronis | it is using the fakestore | 17:15 |
| pedronis | wondering why we never got this kind of error | 17:15 |
| pedronis | it's a while since the situation in which we might try to create a device session have increased | 17:16 |
| ogra_ | mvo, hmm, did the service disabling in the core config hook regress ? (seems to not mask aymore but just disable) | 17:28 |
| ogra_ | lrwxrwxrwx 1 root root 35 Jan 28 11:50 syslog.service -> /lib/systemd/system/rsyslog.service | 17:28 |
| ogra_ | ogra@localhost:~$ snap get core service.rsyslog.disabled | 17:28 |
| ogra_ | true | 17:28 |
| ogra_ | ogra@localhost:~$ ps ax|grep syslog | 17:28 |
| ogra_ | 2195 ? Ssl 0:00 /usr/sbin/rsyslogd -n | 17:28 |
| zyga | mvo: do we need https://github.com/snapcore/snapd/pull/4562 for the final release? | 17:31 |
| mup | PR #4562: debian: add a zenity|kdialog suggests <Created by mvo5> <https://github.com/snapcore/snapd/pull/4562> | 17:31 |
| cachio_ | mvo, well I discovered the problem in dradonboard and pi2 | 17:34 |
| cachio_ | mvo, old core snaps | 17:34 |
| cachio_ | it is weird because I created the images after the cores were uploaded to the store | 17:34 |
| * Chipaca afk for a while | 17:50 | |
| mup | Bug #1746564 opened: snapd should not allow --classic installation for snaps with strict confinment mode <Snappy:New> <https://launchpad.net/bugs/1746564> | 18:01 |
| cachio_ | mvo, this seems to be an issue | 18:11 |
| cachio_ | https://paste.ubuntu.com/26496402/ | 18:11 |
| cachio_ | mvo, it happens in the refresh scenario | 18:11 |
| cachio_ | when we refresh from stable (factory release) | 18:11 |
| cachio_ | I'll debug it once the execution finishes | 18:11 |
| zyga | hmm | 18:11 |
| zyga | in test-snapd-tools expected to have a key 'license' | 18:11 |
| zyga | that looks like the recently added thing | 18:11 |
| cachio_ | mvo, it failed in both 32 and 64 bits | 18:12 |
| zyga | yes, it's not something that's arch dependent | 18:12 |
| cachio_ | zyga, ok, I'll take a look in that case | 18:13 |
| zyga | cachio_: look at the newly merged patches | 18:21 |
| cachio_ | zyga, yes, this issue was not happening in rc1 | 18:22 |
| cachio_ | it is quite new | 18:22 |
| cachio_ | I am debuging | 18:22 |
| cachio_ | zyga, any idea which PR was included the code that could be causing that? | 18:22 |
| mvo | ogra_: hm, I remember code to mask it but I will double check in the morning | 18:33 |
| ogra_ | cyphermox, slangasek, am i correct assuming that the only reason for not using signing for the initrd in secure boot is that we dynamically re-generate it ? or is there any grub-sided restriction as well ? | 18:33 |
| mup | PR snapd#4575 closed: config: add (Get|Set)SnapConfig to do bulk config e.g. from snapshots <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4575> | 18:34 |
| mvo | zyga: 4562 is not super urgent, suggests are weak and in most cases where we will use the UI one of the two (zenity or kdialog) will be installed | 18:34 |
| slangasek | ogra_: what does signing an initrd mean to you? | 18:34 |
| ogra_ | slangasek, well, having a signed img file | 18:34 |
| ogra_ | and grub verifying that | 18:34 |
| mvo | cachio_: meh, I think its my fault :/ | 18:35 |
| mvo | cachio_: I cherry-picked the license display PR into 2.31 | 18:35 |
| mvo | cachio_: so there is a test for it in git | 18:35 |
| mvo | cachio_: but this cherry-pick is not included in ~rc2 | 18:35 |
| mvo | cachio_: that explains the failure | 18:35 |
| slangasek | ogra_: grub verifying it using what code? | 18:36 |
| ogra_ | slangasek, dunno, thats why i ask :) would that be a kernel thing ? | 18:37 |
| slangasek | ogra_: possibly. in practice verification of initrds has consistently been punted to "that's a TPM thing" | 18:37 |
| ogra_ | i assume there is a way to have a signed initrd too ... along with a signed kernel | 18:37 |
| ogra_ | slangasek, the issue is ... we wanted to use u-boot.FIT for secure boot on arm for a project, but it turned out that this only allows a giant blob that contains kernel. initrd and dtb in a single file ... that doesnt go so well with snaps, so i'm looking into the possibility to instead use grub-uboot for that | 18:39 |
| ogra_ | ... in the hope it allows me to have single files i can load | 18:39 |
| ogra_ | (but still keep a secure chain of verified images) | 18:40 |
| ogra_ | aha | 18:47 |
| * ogra_ finds https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd | 18:48 | |
| cachio_ | mvo, I noteced that :) | 18:54 |
| cachio_ | np | 18:54 |
| slangasek | ogra_: right, so initrd is difficult because it's generated outside the archive, and the UEFI signing keys are quite intentionally only in the archive | 18:56 |
| ogra_ | slangasek, right, but thats not the case in snap-land :) | 18:56 |
| slangasek | ogra_: it's still not generated in the Ubuntu archive, AFAIK? | 18:58 |
| cachio_ | mvo, also we need a strace-static snap for i386 | 18:58 |
| cachio_ | mvo, could you please share it to me? | 18:58 |
| ogra_ | slangasek, yeah, but thats the x86 UEFI world ... here we'll have a customer with his own key that gets burned into the trust zone on the arm board ... so all i need to care about is that the snaps get signed with the right key when the customer builds them in-house | 18:59 |
| ogra_ | so no archive key involved | 19:00 |
| slangasek | ogra_: ah, I see. so, then the problem is, the initrd is not a PE object, which means the usual secureboot signature verification code can't do anything with it | 19:02 |
| ogra_ | s/that the snaps/that the binaries in the snaps/ | 19:02 |
| ogra_ | right, but i the case of a custom key that wont matter ... great ... | 19:02 |
| * zyga dinner | 19:08 | |
| jdstrand | ogra_: otoh, I don't... tyhicks *may*, but jjohansen probably would (though he is traveling and may not be available) | 19:42 |
| jdstrand | tyhicks, jjohansen: question from ogra is when does "bpf" show up in /proc/filesystems? | 19:42 |
| zyga | hey jdstrand o/ | 19:44 |
| jamesh | zyga: hi. Is there any particular reason why snap-update-ns only logs failures to mount/unmount file systems rather than treating it as a failure? | 19:45 |
| mup | PR snapcraft#1901 closed: elf: check if file exists before checking if ELF <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1901> | 19:48 |
| tyhicks | ogra_, jdstrand: is there more context? (I don't have backscroll handy) | 19:48 |
| tyhicks | ogra_, jdstrand: filesystem types show up in /proc/filesystems when filesystems of that type are available in the kernel (I doubt that answers your question and that you already know that) | 19:49 |
| tyhicks | s/and that you already know that/and suspect that you already know that/ | 19:49 |
| mvo | cachio_: sure thing, let me fix the strace-static thing | 19:49 |
| jdstrand | hey zyga | 19:49 |
| jdstrand | tyhicks: right. let me give the whole question | 19:50 |
| zyga | jamesh: that's a good question, I think it was decided long ago | 19:50 |
| zyga | jamesh: I'm not super fond of it as we probably don't do things correctly then | 19:50 |
| jdstrand | tyhicks: 11:09 < ogra_> jdstrand, (or any other securiteer ) ... looking at different core kernels i see "bpf" in /proc/filesystems ... the kernel i'm currently working on does not show it and i cant find what Kconfig option would enable the bpf filesystem, do you happen to have any hint (google isnt helpful either) | 19:50 |
| tyhicks | aha | 19:51 |
| tyhicks | I can answer that with some investigation | 19:51 |
| jdstrand | zyga: considering that snap-update-ns tries to do things in order, failing somewhere along the way and continuing as if it succeeded seems incorrect | 19:52 |
| jdstrand | ogra_ (cc zyga): I just looked at 3 different core systems, and none of them have a populated /etc/apparmor.d/cache | 19:53 |
| tyhicks | ogra_: the bpf filesystem was first added in kernel 4.4 with this commit: https://git.kernel.org/linus/b2197755b2633e164a439682fb05a9b5ea48f706 | 19:53 |
| jdstrand | ogra_ (cc zyga): /var/cache/apparmor is correctly populated with snap cache (and nothing else) | 19:54 |
| tyhicks | ogra_: from what I can tell, it is only hidden behind CONFIG_BPF_SYSCALL | 19:54 |
| jdstrand | ogra_ (cc zyga): /etc/apparmor.d/cache is a writable path, so for giggles I unmounted it and /etc/apparmor.d/cache was also empty. if I were to guess, I would say that the ordering of the apparmor unit and the writable-path is wrong and that /etc/apparmor.d/cache is still readonly at the time that the parser is run | 19:56 |
| zyga | jdstrand: oho | 19:57 |
| zyga | jdstrand: nice find | 19:57 |
| mvo | jdstrand: with me "empty-etc" hat on> why is etc used to write a cache? | 19:58 |
| jdstrand | ogra_ (cc zyga): iirc this used to work. I don't know when it would have regressed. we should probably have a spread test to make sure | 19:58 |
| zyga | mvo: your question is spot on | 19:58 |
| jdstrand | mvo: hi! terribly longtime historical reasons | 19:58 |
| mvo | jdstrand: fair enough, just like 80% of etc | 19:59 |
| jdstrand | mvo: right | 19:59 |
| jdstrand | mvo: it predates me. afaik, it was there because alternatives weren't guaranteed to be mounted during early boot (eg, /var) | 19:59 |
| zyga | mvo: you probably know better than I do that /etc used to hold *binaries* | 20:00 |
| jdstrand | mvo: and other places were not lsb compliant (not that /etc/apparmor.d/cache is) | 20:00 |
| jdstrand | mvo: it comes up from time to time on the mailing list. there is a general desire to move it, but it gets complicated wrt to early boot, distros, etc. however for core, there is no reason we couldn't put it somewhere else, but we'd have to be careful about early boot | 20:02 |
| jdstrand | mvo: it comes up from time to time on the mailing list. there is a general desire to move it, but it gets complicated wrt to early boot, distros, etc. however for core, there is no reason we couldn't put it somewhere else, but we'd have to be careful about early boot | 20:02 |
| mvo | jdstrand: ok | 20:02 |
| jdstrand | mvo: I'm not sure how much you saw before you dropped off... | 20:03 |
| mvo | jdstrand: I missed this, thanks for pasting | 20:03 |
| mvo | jdstrand: my machine is a bit unstable recently, I wonder if I need to purge the intel-microcode package :( | 20:03 |
| jdstrand | mvo: here are two more: | 20:03 |
| jdstrand | mvo: it predates me. afaik, it was there because alternatives weren't guaranteed to be mounted during early boot (eg, /var) | 20:04 |
| jdstrand | mvo: and other places were not lsb compliant (not that /etc/apparmor.d/cache is) | 20:04 |
| mvo | jdstrand: ta | 20:04 |
| jdstrand | mvo: maybe-- mine made suspend not work at all | 20:04 |
| jdstrand | well, it would suspend. it wouldn't come out ;) | 20:04 |
| jdstrand | I'm hopeful new microcode will be available | 20:05 |
| mvo | jdstrand: thanks for the apparmor, for core18 we may need to tweak this, but its only one of many potential things we need to tweak :) | 20:05 |
| mvo | jdstrand: I will purge it for now :( | 20:05 |
| jdstrand | mvo: can you think of what might've caused the cache to not be populated? | 20:06 |
| jdstrand | mvo: do you also recall this used to work? | 20:06 |
| mvo | cachio_: I create a proper lp:~snappy-dev/strace-static-snap/trunk project with an auto snap build | 20:06 |
| cachio_ | mvo, awesome, tx | 20:06 |
| jdstrand | ogra_: can you file a bug for /etc/apparmor.d/cache and we can contineu there? | 20:07 |
| mvo | jdstrand: I don't recall this used to work and I think the most plausible is what you said, if this run very early the location might still be read-only | 20:07 |
| mvo | jdstrand: fwiw, I hope we won't have writable-paths for core18 just a plain writable etc | 20:07 |
| jdstrand | it certainly is meant to work, otherwise those poor arm devices are grumpy | 20:07 |
| * jdstrand -> gotta run. bbiab | 20:07 | |
| mup | PR snapd#4574 closed: tests: add integration for local snap licenses <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4574> | 20:18 |
| mup | PR core#80 opened: hooks: c-n-f is expected in /usr/lib/command-not-found <Created by mvo5> <https://github.com/snapcore/core/pull/80> | 20:33 |
| zyga | mvo: +1 | 20:36 |
| mvo | zyga: ta | 20:47 |
| mup | PR core#80 closed: hooks: c-n-f is expected in /usr/lib/command-not-found <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/80> | 20:47 |
| mup | PR snapd#4577 opened: snap: fix command-not-found on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/4577> | 20:47 |
| zyga | mvo: so... it wasn't tested in practice before? | 20:49 |
| zyga | mvo: hmm | 20:50 |
| zyga | mvo: why | 20:50 |
| zyga | +cmd.Positionals.CommandOrPkg = os.Args[2] | 20:50 |
| zyga | I don't get it | 20:50 |
| zyga | you iterate over all args except 0th | 20:50 |
| zyga | and then you can have a chain of -- | 20:51 |
| zyga | and the first one that doesn't will set a _fixed_ answer | 20:51 |
| zyga | is that correct? | 20:51 |
| mvo | zyga: meh, incomplete push | 20:51 |
| mvo | zyga: sorry | 20:51 |
| mvo | zyga: please reload | 20:52 |
| mvo | zyga: originally I wanted to just hardcode os.Args[2] | 20:52 |
| mvo | zyga: but then though checking for "--" would be more robust if the handler that calls c-n-f ever changes | 20:52 |
| mvo | zyga: I guess it shows that I should stop for today :) | 20:53 |
| mvo | zyga: the integration on a real shell on a core device was not tested until today :/ many moving parts | 20:53 |
| geekgonecrazy | Greetings guys. Back with more snap/snapcraft related issues. :) | 21:02 |
| geekgonecrazy | In the rocketchat-server snap we do an npm install. One of the packages seems to always have issues getting properly snapped up | 21:02 |
| geekgonecrazy | So most of the time we can explicitely install it and it'll make it through. But we're running into the issue again. It seems as if for some reason snapcraft decides that the binaries don't need to be included so skips them | 21:03 |
| geekgonecrazy | > Unable to determine library dependencies for b'/build/stable/prime/programs/server/npm/node_modules/grpc/src/node/extension_binary/node-v57-linux-x64-glibc/grpc_node.node' | 21:03 |
| geekgonecrazy | we see this ^ and that exact same file is then complained about being missing when we try to start it | 21:04 |
| geekgonecrazy | does "Unable to determine library dependencies" really mean... "Can't figure out what to do with this so skipping" ? | 21:04 |
| zyga | geekgonecrazy: this is something for sergiusens, kyrofa and kalikiana | 21:12 |
| zyga | though they are sprinting this week so conditions apply | 21:13 |
| geekgonecrazy | zyga: ok fair enough. I'll roll back our armhf build. Typically if there is an error building it errors out. But seems that the skipping of the files isn't an error just a silent thing :( | 21:17 |
| geekgonecrazy | i'd keep digging tonight, but gotta prep to head out to fosdem tomorrow. Do you know if any of the snap/snapcraft team will be attending? | 21:18 |
| zyga | geekgonecrazy: I don't know, sorry | 21:23 |
| zyga | geekgonecrazy: they have a sprint now in US so probably not | 21:24 |
| zyga | though maybe someone else is going | 21:24 |
| geekgonecrazy | zyga: no biggie. Just figured someone around might know :D | 21:35 |
| mup | PR snapcraft#1902 opened: many: use in-snap unsquashfs and readelf if running from snap <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1902> | 21:45 |
| ogra_ | jdstrand, thanks for the investigation, will file it ... | 23:05 |
| ogra_ | tyhicks, thanks for the research ! i have the BPF_SYSCALL option set here but still dont see it in /proc/filesystems ... will dig further myself ... | 23:07 |
| === nacc_ is now known as nacc | ||
| tyhicks | ogra_: kernel version? | 23:20 |
| jdstrand | greyback: hey, you probably saw but I approved your /dev/shm/# pr, but can you add the requested comment? | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!