mupPR 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
mupPR 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
mupPR snapcraft#1898 opened: docker: don't rely on snapcraft-classic <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1898>00:50
zygakyrofa: the fixes are merged, please try edge and report any weird stuff00:53
zygakyrofa: rc2 tomorrow00:53
zygakyrofa: (early morning)00:53
zygaso you can be on beta to see it00:53
mupPR 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
kyrofazyga, you got it, thanks man :)00:58
kyrofaYeah looks like RC1 now, when I see RC2 I'll give it a shot00:59
zygakyrofa: tomorrow morning01:04
zygaI'm baby sitting the last PR01:04
mupPR 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
mupPR 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
mwhudsoni wonder what's going on here https://launchpadlibrarian.net/355232767/buildlog_snap_ubuntu_xenial_armhf_go-tip_BUILDING.txt.gz01:52
mwhudsoni bet it's made an arm64 binary for some reason01:52
zygamwhudson: hey02:00
mupPR 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
mwhudsonzyga: hello02:00
zygaexec format error, never saw that one02:00
zygayeah, feels like wrong arch02:00
zyga(but how?)02:00
mwhudsonno idea02:00
zygamwhudson: 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
mupBug #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
mwhudsonzyga: mmm could be02:02
Son_Gokumwhudson, i dunno, it doesn't work in centos even with the polkit file installed02:02
mwhudsonyeah, looks like the polkit file is installed in debian too02:03
mwhudsondata/polkit/io.snapcraft.snapd.policy /usr/share/polkit-1/actions/02:03
Son_Gokusame goes for Fedora02:03
Son_GokuI've been installing it for a while, no effect02:03
Son_Gokumwhudson: wait, this bug is about "snap install"?02:04
Son_Gokusnap install doesn't query polkit at all02:04
Son_Gokulike, zilch02:04
Son_Gokuonly GNOME Software does02:04
Son_Gokuif that's supposed to work with "snap install" too, then this is horrifically broken02:04
kyrofaHey tyhicks, if you're around, what is the status of using errno instead of kill for seccomp denials?02:07
Son_Gokumwhudson: https://src.fedoraproject.org/rpms/snapd/c/98b119302ae0d8d502f20877e0ecbf76a64ac1c902:07
Son_Gokuyeah, I've been installing it and it doesn't have effect :/02:07
tyhickskyrofa: hey - it sounds like it is stuck waiting for a libseccomp-golang release and for other distros to include that release :(02:09
tyhickskyrofa: https://github.com/snapcore/snapd/pull/3998/#issuecomment-35802857902:09
mupPR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Decaying> <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>02:10
tyhickskyrofa: I haven't had a chance to look into falling back to KILL if the available libseccomp-golang isn't new enough02:10
tyhicksall underlying work upstream and in Ubuntu is done02:10
kyrofatyhicks, excellent, thank you very much :)02:11
tyhicksno problem02:11
tyhicksI wish it was already working but there were a lot of moving parts02:12
kyrofaOh totally, glad to see it moving along though02:12
kyrofaWe were just chatting about it at the sprint and none of us knew where the work stood. So now we do!02:13
Son_Gokukyrofa: 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 go02:22
Son_Goku(since both of you have FAS accounts, you're also able to do PRs against the packaging repos for both of these02:22
mupPR snapcraft#1899 opened: elf: readelf dependency <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1899>03:00
Chipacamborzecki: morning06:52
mborzeckiChipaca: hey06:52
mborzeckiChipaca: sorry :)07:57
zygaI wanted to sleep07:59
Chipacamborzecki: :-)08:00
mborzeckiChipaca: fwiw will looking at ProcessState be enough?08:00
zygalast night tests were utterly broken on networking08:00
zygalet's see how if today they fare better08:01
Chipacamborzecki: not really, i think using a flag variable is the only way08:01
Chipacamborzecki: the command just knows it was killed, not by whom08:02
mborzeckiChipaca: right08:02
mborzeckiChipaca: otoh maybe it's not worth it, unless the caller does something silly with the error the way it's now should be fine08:02
* zyga has zero PRs open, that's ... new08:03
Chipacamborzecki: 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.Canceled08:04
mborzeckiChipaca: imo adding a comment instead of a flag will be ok too :)08:04
pstolowskigood morning08:04
zygahey paweł!08:04
mborzeckizyga: pstolowski: morning08:04
dokohttps://launchpad.net/ubuntu/+source/snapd/2.30+18.04 ftbfs on most archs08:05
Chipacamborzecki: it'd look like https://pastebin.ubuntu.com/26493696/08:08
zygadoko: thank you for the heads up, we'll look into it08:08
zygahey kalikiana08:11
dokozyga: now given back. but seriously, hit the uploader for each day and one arch that this wasn't given back ...08:12
mborzeckiChipaca: right, so there's still a race but at least you'll get ctx.Err() if cancel was called or timeout was hit08:17
Chipacamborzecki: I _could_ check that if the flag is set, the exec error looks like a 'killed' error08:18
* Chipaca bbiab08:18
mupPR 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 TestRunRace09:40
pedronismvo: Chipaca: hi, what's the status of #445909:41
mupPR #4459: snap: add support for `snap advise-snap pkgName` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4459>09:41
Chipacapedronis: what do you mean?09:41
* Chipaca looks09:42
pedronisit seems to be sitting there09:42
pedronissince a while09:42
pedronisbut is not blocked09:42
Chipacahuh, i thought this was merged09:42
Chipacapedronis: the status is it only has one +109:43
mvoChipaca, pedronis I think it should get a ack/nack from gustavo09:43
Chipacai guess :-)09:43
pedronismvo: it was not marked as such though09:43
pedronisI suppose I cand do that09:43
mvoChipaca, pedronis it might be considered as redundant functionality. thanks, if you mark it that would be great, otherwise I will do it09:44
pedronismvo: I requested a Gustavo reivew on it09:44
Chipacamvo: redundant with what?09:44
pedronisprobably needs a poke also09:44
mvoChipaca: redundant with snap advice-snap --comand09:46
mvoChipaca: oh, hold on a sec09:47
mvoChipaca: I'm looking at the wrong PR, I think this one is uncontroversial mostly09:47
pedronistoo many PRs09:47
mvosorry, I was looking at the `snap run` one that advises on available commands09:47
mvopedronis: yes :(09:47
pedronismvo: I still recommend(very gently) trying to be a bit more agressive about closing PRs, otherwise it gets confusing09:48
mvopedronis: agreed, let me start right now!09:48
pedronisclose as in get merged or close as in close, whatever makes sense09:49
mupPR 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
pedronisto be clear09:49
* Chipaca hugs mvo09:50
mupPR 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(which is like o/ but with me being more sleepy)09:53
zygamvo: so I woke up at 7 ... and ... yeah09:53
mvo4521 needs a second review probably an easy win09:53
Chipacazyga: I woke at 409:53
Chipacazyga: neener neener09:53
mvozyga: good morning (and you looked at this already)09:53
mvozyga: good morning09:53
zygahaha :)09:53
mvozyga: rc2 is branched and uploaded to the ppa, waiting for the build09:53
Chipacathat's what peeking into scary finances does to you09:53
mvoI wonder if openoffice is building right now, build slots are in short supply it seems :/09:54
zygaChipaca: I was merging things at 3am09:54
mvoChipaca: :( that sounds scary09:54
Chipacazyga: i saw you restarting things at my 1am, so yeah :-)09:55
zygaChipaca: yeah, travis and spread didn't love each other last night09:55
mvovery ironc that 2.31~rc2 is only build on powerpc yet (which used to be one of the slowest arches)09:56
Chipacamvo: no spectre for ppc09:56
mvoheh, yeah09:56
mvoi was wondering if it is build on a 32bit chroot on ppc64el or something, that would also explain it09:56
zygamvo: someone just pressed the "turbo" button09:57
* zyga remebmers his 386 now09:59
* Chipaca -> physio10:01
mwhudsonmvo: yes, pretty sure powerpc builds in a chroot on a 64 bit box now10:01
mvothanks mwhudson10:01
mwhudsonKernel version: Linux bos02-powerpc-008 4.4.0-103-powerpc64-smp #126-Ubuntu SMP Mon Dec 4 16:57:45 UTC 2017 ppc6410:03
mupPR #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:~$ htop10:04
ogra_snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks10:04
* ogra_ reboots the board10: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 tonight10:05
zygaogra_: let me know if it happens, I can look at my boards10:05
mvoChipaca: 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
zygamvo: btw, doko said that snapd 2.30 builds are failing10:07
zyga09:05 < doko> https://launchpad.net/ubuntu/+source/snapd/2.30+18.04 ftbfs on10:07
zyga              most archs10:07
mvozyga: checking10:07
Chipacamvo: no, i don't think so, not unless it's got an alias10:08
mvozyga: fwiw https://launchpad.net/ubuntu/+source/snapd/2.30+18.04 is all green afaict10:08
zygano idea, not very helpful today10:09
dokomvo, zyga: yes, given back.  you should not upload and run away, but read your build failure messages10:10
dokobut maybe snaps don't have those anymore ...10:11
* mvo wonders why he did not get those10:12
Chipacamborzecki: pushed a tweak to RunWithContext, including a test for the race10:12
Chipacaand now yes, to physio10:13
mborzeckiChipaca: thanks, will take a look10:15
mupPR 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
mborzeckizyga: ^^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 for10:18
zygaogra_: it does and that thing you disabled loads it10: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 installs10:20
ogra_core does not have any other profiles outside of snap apps ... where snapd already takes care correctly10:21
zygaogra_: it has to be done on boot10:21
zygaogra_: by that script10:21
zygathat 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
zygaon all installs10:21
zygaI mean, snapd doesn't handle that at all10:22
ogra_but on core there is only one profile that gets generated10:22
ogra_which is the snap-confine one10:22
zygano, all the per-snap profiles are handled by that guy10:22
zygawe could remove it but it's ... already doing it10:22
ogra_hmm, i dont see it doig that10:22
zygaand there's no clear reason why that would help10:22
zyga(look at /var/lib/snapd/apparmor10:22
zygathat's also loaded by the script10:22
ogra_well, the profiles are generated during snap install10:23
ogra_just not for snap-confine10:23
zygayes but on reboot they are not loaded10:23
zygaogra_: 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 start10:23
zygaogra_: I'm not sure that should be snapd; it could be but I don't see a clear advantage10:24
zygaogra_: not on boot speed for sure10:24
ogra_well, thats different to what i see :) but i belive you :)10:24
zygaogra_: there's a variable somewhere that makes it look at /var/lib/snapd/apparmor/profiles10:24
zygaogra_: 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 apps10:25
ogra_anyway, re-enabling the script gets me 3min boots back but also makes snap-confine work again ... so its a user error10:26
zygaogra_: how slow is it btw?10:26
cjwatsonChipaca: 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
zygamaybe there is something wrong?10:26
zygacjwatson: hey, I still _run_ one :)10:26
ogra_zyga, lol ... yes ... thats what i'm trying to find :P10:26
zygaogra_: maybe add a echo to the script (or something like that)10:27
zygaogra_: so that we know when it starts and when it stops10:27
zygaogra_: not sure if that's clearly readable from logs10:27
ogra_(it is a 200-500MHz 256M ram board ... but 3mins are definitely to long even for that)10:27
zygaogra_: so, there's a cache thing there but maybe it's broken and not used10:27
ogra_systemd-analyze is usually pretty correct in its timings10:27
zygaogra_: normally apparmor should read the profile, check with the cache and insert a cached compiled blob if one is recent10:27
ogra_yeah, the cache is definitely empty on all my boards10:28
zygaogra_: otherwise it would compile the profile, which is slow, save the cache and load it in the kernel10:28
ogra_jamie pointed that out before10:28
zygaogra_: not sure how much of that is done in intrd10:28
zygaogra_: and how much in early systemd10:28
ogra_(seems there is some general issue with the cache )10:28
zygaogra_: oh?10:28
ogra_initrd doesnt do any apparmor stuff10:28
ogra_only the mounting10:28
zygathere are two cache locations10:28
zygafor some historic reason AFAIR10:28
zygadid you check both?10:28
ogra_well, jamie pointed me to /etc10:28
zygalook at /var/cache/apparmor10:29
ogra_and that one is definitely empty on all boards i have10:29
ogra_yeah, there are files10:29
zygasee if it makes any difference10:29
zygaeven with a hand watch10:29
zygaif you remove them10:29
zygaif so then the cache works10:29
zygaif not ... well, slow boards are slow10: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 yet10:30
zygahow much?10:30
ogra_dunno, several tens of seconds10:31
ogra_15-20 i'D say ... thats sadly a service that doesnt log anything ...10:31
zygais that blocking boot or does it happen in parallle?10:31
ogra_(i havent debugged that one yet, its an obvious one)10:31
ogra_others are 30sec for mounting loop devices10:32
ogra_thats more worrying10:32
ogra_console-setup 20sec ... keyboard-setup 15sec ...10:32
ogra_the device probing is blocking boot10:33
mvoogra_: 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
zygaogra_: the probing issue10:35
zygaogra_: I honestly think it should not be a toggle10:35
zygaogra_: but there should be a way to tweak this in the gadget10:35
ogra_zyga, ?10:35
zygaogra_: so that you can use udev tagging to blacklist media10:36
zygaogra_: so that certain internal devices are just skipped10:36
zygaogra_: it's a simple system, extensible to devices and makes sense as a design IMO10:36
ogra_well, you never ever want to probe mmcblkXrpmb or mmcblkXbootX10:36
zygaogra_: I don't think that's true, that's absolute and those rarely turn out true10:37
ogra_but thats also something systemd needs to learn, not only snapd10:37
mvoogra_: thanks, the plot would be nice at some point but not urgent10:37
mupPR 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
zygaogra_: as long as you can set an attribute that makes it skip probing and you can express that in the gadget it feels sufficient10:37
ogra_zyga, right ... systemd doesnt have such a flag yet ... which is why i ignored that bit for now for snapd as well10:38
ogra_i'll get to that later ...10:38
ogra_thats one of the bits that are understood :)10:38
zygaogra_: it's not a systemd flag10:38
zygaogra_: it's an udev attribute10:38
ogra_(i have many in this particular boot process that arent :) )10:38
zygaogra_: 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 autoimport10:41
zygaogra_: fsck I cannot speak of, those are separate issues10:41
zygaogra_: but the job that tries to look for assertions is under our control10:41
zygaogra_: so it could just skip devics with a given attribute10: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
zygaogra_: sure that's documentation; I'm describing a feature that doesn't exist10:44
zygaogra_: it's just something that we would doucment in device maker's book or similar10:44
ogra_i thought you said there is "MM_SKIP_PROBING"10:45
zygaogra_: I'm saying that such an attribute, IMO, makes more sense than a big bool flag for _users_10:45
zygaogra_: that was a reference to existing similar attribute for modem manager and serial ports10:45
ogra_that flag will only make the udev rule skip10:45
ogra_it wont prevent the unit fro running10:45
zygayes but we could make that unit run the prober with a device, so that control is reversed10:46
zygasystemd picks the devices, prober probes one10:46
ogra_most customers i worked with til now want that stuff completely off so people cant tinker with USB sticks10:46
zygathose could then even run faster as they would happen in parllel10:46
zygaogra_: that's okay, but it should be a gadget decision, not a toggle for users10:46
ogra_it simply wastes cycles, even if it is a no-op10:46
ogra_indeed it should be a gadget thing10: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 activities10:57
zygaogra_: I'm so mentally tired I will do some house chores to vent my mind10:57
zygaogra_: I agree on fsck10:57
zygaogra_: though I would discuss it separately10:58
mvocachio: good morning! 2.31~rc2 for armhf/arm64 is ready, the other ones are still building11:07
cachiomvo, good morning, already downloading images11:11
mvocachio: great, I publish the other ones as soon as I can11:11
cachiomvo, great11:11
* zyga hopes for one smooth release 11:17
mvo2.30 was not too bad11:17
zygamvo: going out with rc2 would be awesome :)11:18
mvocachio: i386/amd64 ready now as well11:19
* zyga refreshes to beta11:25
zygamvo: oh11:25
zygamvo: we didn't do one thing11:25
zygathat piece of code that wrote the snap.mount unit (under proper name11:26
zygawe don't have that11:26
zygafor reexec11:26
zygabut I guess it's okay for now, as long as packages are coming out, not a regression in any way11:26
mvozyga: yeah, it will only be fixed in lxd hosts with the right snapd version11:27
mvozyga: eh deb/rpm11:27
mvozyga, 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 dont11:28
mvopstolowski: do you think you could check 1745015?11:28
mvoogra_: why not?11:28
ogra_(dealing with a 200MHz 256M single core device here ... such a switch would have some impact)11:28
zygamvo: is there any mandate for the hooks to be anything? they are just executables, could be dash, python or elf11:28
ogra_bash eats about 5Mb while dash lives in the kilobyte range11: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
mvozyga: there is no mandate for this11:30
ogra_mvo, assuming you dont mean live-build hooks here but app hooks11:30
pstolowskimvo, interesting. will look into 174501511:31
mvoogra_: 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 here11:31
pstolowskimvo, I agree with zyga; i think documenting is enough11:32
mvopstolowski: ok11:32
ogra_(and on single core-low-speed cpus also every herz :) )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 them11:39
ogra_i.e. "systemd-machine-id-commit.service" ... completely useless since we set the machine-id from the initrd ... but it gets run nontheless11:40
ogra_or systemd-hwdb-update.service ... (the hwdb is readonly)11:41
cjwatsonmvo: I think the thing that bug reporter is missing is that /bin/sh is the default in normal Ubuntu too11:41
cjwatsonmvo: err /bin/sh -> dash11:41
cjwatsonthey've obviously just configured it differently11:42
Chipacacjwatson: wrt spectre on ppc, I was thinking exclusively of the pre-2006 chips (have there been 32-bit ppc chips since then?)11:46
Chipacaalso I thought powerpc meant 32 bits, and the newer ones were ppc64le or w/e11:47
cjwatsonyeah but you said ppc which is a bit ambiguous11:48
Chipacaah, my bad then (i meant powerpc i think)11:49
Chipacain my defence my only powerpc machine was a nubus-ppc one11:49
cjwatsonthere'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 bothered11:49
* zyga starts to see the light at the end of the tunnel :)11:51
zygamy office gets messy quickly11:52
Chipacasomebody's got to be trying to get spectre to work on a router11:52
Chipacamborzecki: you around?11:52
mborzeckiChipaca: yeah, trying to go through #455111:53
mupPR #4551: ifacestate: do not auto-connect manually disconnected interfaces <Created by stolowski> <https://github.com/snapcore/snapd/pull/4551>11:53
Chipacamborzecki: just a quick Q: your version of the if in #4569 implies two class assertions, right?11:53
mupPR #4569: osutil: add ContextWriter and RunWithContext helpers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4569>11:53
mborzeckiChipaca: sadly yes11:54
Chipacaie one to get a ExitError, one to get a WaitStatus; that's why you said more verbose11:54
Chipacamborzecki: 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
mborzeckiChipaca: didn't know about it either, actually read through the exec code in stdlib :)11:55
pstolowskimborzecki, thanks!11:55
mupPR snapd#4557 closed: osutil: add DirExists and IsDirNotExist <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4557>12:02
zygaok, one last power strip12:05
zygaand I should be ready12:05
niemeyerHey hey12:08
* ogra_ puts a dollar in zyga's waistband for that power strip ...12:09
Chipacaogra_: I did _not_ need that image12:09
* zyga googles waistband12:10
* zyga hugs ogra_ and Chipaca *together*12:11
ogra_no, no ... we didnt order that lapdance !!!s12:11
* Chipaca steals the dollar and goes to get lunch12:11
zygathe dollar is actually a beer bottle cap12:12
* zyga looks at unit tests again12:22
=== LarreaMikel1 is now known as LarreaMikel
Chipacazyga: guess lunch is roaches then12:32
zygaChipaca: fry slowly12:32
* Chipaca squints at Failed tasks: 112:33
Chipaca    - linode:ubuntu-14.04-64:tests/main/server-snap:pythonServer12:33
zygawhat's the failure?12:34
ogra_is bpf a hard kernel requirement nowadays ?12:45
zygaogra_: yes, I think so12:48
ogra_ppisati, seems our default configs in the sample kernels do not enforce bpf ^^^12:49
mupPR snapd#4573 opened: tests: enable content sharing test for $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4573>12:50
zygamvo: if this passes please drop it into final release12:53
zygaI forgot about it yesterday12:54
* zyga is very excited about content sharing getting a huge boost in 2.3112:54
zygabut first let's drop those unit tests :)12:54
mvozyga: which one, 4573?12:57
zygait just enables a test that I wrote ahead of time12:57
zygaand rigged to skip one case12:57
zyganow it should all pass12:57
mupPR snapd#4570 closed: release: snapd 2.31~rc2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4570>12:59
mupPR snapd#4569 closed: osutil: add ContextWriter and RunWithContext helpers <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4569>13:02
ppisatiogra_: i'm going to add it to the list of configs in the snapcraft/kernel_plugin13:21
zygamvo: please merge https://github.com/snapcore/snapd/pull/457313:24
mupPR #4573: tests: enable content sharing test for $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4573>13:24
zygait's green now13:24
ppisatiogra_: which BPF options? i guess the BPF_SYSCALL filtering option13: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 though13:27
ppisatiogra_: well, when you figure it out, add it to the list of required options here and send a pull req13:28
ppisatiogra_: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/kernel.py13:28
ppisati'required_snappy' i guess13:28
mupPR snapcraft#1900 opened: Parent relative symlinks <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1900>13:32
zygajjohansen: o/13:51
jjohansenhey zyga13:51
zygajjohansen: long time no see, how are you doing13:51
jjohansenzyga: well I was doing well, but I have a feeling that is about to change13:51
pstolowskimvo, 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
zygaoh? what's going on?13:52
mvopstolowski: aha, interessting13:52
jjohansenzyga: oh I was just assuming you pinged me because you have a bug for me :)13:52
zygaah, no :)13:52
jjohansenzyga: ah, well then I am good :D13:54
mupPR 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
zygathank you13:55
pstolowskimvo, ok. puzzling. install hook got killed eventually, install was aborted. all as expected.13:57
cachiomvo, https://paste.ubuntu.com/26495194/13:58
pstolowskimvo, ah wait, he is not installing, he is using snap try13:58
cachiothis is what Ii see in the pi2113:58
cachiomvo, there is no /snap/core/current13:58
cachiomvo, and many tests failing because of that13:58
* kalikiana lunch13:58
cachiomvo, also the test-snapd-tools snap is not in /snap13:59
mvocachio: that is strange, what does your state.json look like? i.e. python3 -m json.tool /var/lib/snapd/state.json13:59
mvomborzecki: just to double check, the license for local snaps is displayed if these snaps have a "license:" field in their snap.yaml?13:59
cachiomvo, https://paste.ubuntu.com/26495214/14:00
mvocachio: strange, looks like state.json and content is toally out of sync14:03
mvocachio: I wonder if this is a fluke or if we somehow broke the testsuite14:04
zygamvo: maybe backup/restore is messed up14:04
zygawe sometimes see that the state was modified while it was being saved14:04
mvozyga: yeah, something along these lines14:04
cachiomvo, not sure yet, something similar is happening in dragonboard14:04
cachiopi3 is working fine14:04
zygait's a race14:05
zygait doesn't matter where it failed14:05
cachiomvo, same issue with test-snapd-tools14:05
mvoChipaca: 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.3114:05
mupPR #4531: cmd/snap: display snap license information <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4531>14:05
mvocachio: and its also in the state I assume? so the same out-of-sync issue(?)14:06
Chipacamvo: except for the very last commit, i think14:06
cachiomvo, checking14:06
mborzeckimvo: 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 it14:06
mvoChipaca: commit or comment?14:07
mvomborzecki: yeah, I think if we could have a test case that would be best14:08
Chipacamvo: commit14:08
Chipacamvo: ie the one that removed the “license: unknown”14:08
mvomborzecki, 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 snap14:09
cachiomvo, yes14:10
cachiomvo, 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 progress14:11
mborzeckimvo: just to be clear, revert the last 2 commits right?14:11
mvomborzecki: yes14:12
mvomborzecki: 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 snap14:12
mborzeckimvo: also the text that was shown there is `(undefined)`, should I change it to unknown instead?14:12
mvomborzecki: yeah, I think "unkown" is slightly better14:13
mvoniemeyer: for unknown licenses, "license: unknown" in `snap info` output? sounds reasonable?14:14
dokomvo, zyga: snapd has autopkg test regressions14:15
zygawhere can we see them?14:17
mvozyga: I think we have this problem that the store categories changed :( so the searching test fails now14:18
* ogra_ scratches head about unlogical kernel config naming 14:23
ogra_# CONFIG_BPF_JIT is not set14:23
ogra_how can the second one be true if the first one is false ...14:24
zygayou have it (it's supported in arch) but not enabled14:24
zygathat's how I see it14:24
ogra_so that would mean userspace you think ?14:24
zygano, 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_ gets it14:25
zygabut the config option to enable it is off14:25
ogra_anyway ... just curious ... i'll just enable it anyway14:25
Chipacapstolowski: I got a panic in config, suspect I'm doing something wrong :-) do you have a moment to take a look?14:30
pstolowskiChipaca, what is it?14:31
Chipacapstolowski: I'm doing : tr.Set(aSnap, "", aConfig)14:32
Chipacapstolowski: and overlord/configstate/config/helpers.go:80 throws an 'index out of range'14:33
niemeyermvo: Yeah, sounds good14:33
niemeyermvo: I'm half-way through typing out a proposal for custom licenses too14:33
mvomborzecki: -^ so "license: unknown" is fine, very happy that this gets pulled in :)14:34
pstolowskiChipaca, key cannot be "", I'm sure we prevent it in snap/snapctl set, but apparently not at this level14:35
mborzeckimvo: pushing update in a short while, turns out the biggest issue is forging the data that snapd returns14:35
Chipacapstolowski: then how do I set the whole config? (because key is "" for get to get the whole config)14:35
pstolowskiChipaca, 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 once14:41
pstolowskiChipaca, I mean - not for transaction.Set at least14:41
pstolowskiChipaca, you can of course workaround that by iterating over root elements and calling tr.Set(..) for them manually14:43
Chipacapstolowski: that sounds very additive14:43
pstolowskiChipaca, or just make tr.Set smarter :}14:43
pedroniswell you need also to remove all them14:43
pedroniswhich we don't quite support either14:44
ChipacaI need to set the config to the thing in the snapshot, not add to it14:44
Chipacaif the config is empty, empty it14:44
pedronisseems you need to bypass transactions14:44
pedronisor teach Set about "" or something like that14:44
ChipacaI don't mind bypassing transactions :-D14:44
pedronisreplacing the whole thing is not quite the use case for transaction14:45
pedronisthen it's more  matter of not breaking too many abstractions14:45
pstolowskiah, I see, yes it's additive that way14:45
pedronisChipaca: sounds we need configstate.Set or something14:45
pedronisfor your use case14:46
ChipacaI need to step away for a bit14:46
pedroniswell configstate/config.Set14:46
pstolowskiyes, that should be very straightforward14:46
* pedronis doesn't remember the how the code org looks like exactly14:47
mupPR 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
mvomborzecki: oh, a spread test is fine, just adding "license: ..:" to one of the test snaps14:47
mborzeckimvo: well, i've updated the unit tests anyway :)14:48
mvomborzecki: .) ok14:48
niemeyermvo, mborzecki: https://forum.snapcraft.io/t/support-for-custom-license-text/3671/1614:49
niemeyerChipaca: ^14:49
greybackit possible for one snap app to call another snap app? Something like a poor-man's socket activation?15:12
zygagreyback: not without an interface15:13
greybackzyga: even inside the same snap?15:14
greybacki.e. appA & appB in the snap, I want appB to call appA15:14
zygagreyback: that's more subtle: if you want to go through the activator then you won't be able to15:15
zygagreyback: if you call the same command as that activator then sure15:15
zygagreyback: but you won't get the permissions of the other app15:15
greybackzyga: yeah, it was the permissions I was hoping to keep separate15:16
greybackso xwayland has tight security, and then my x app has more freedom15:16
greybackguess I'll give that up for now15:17
zyga10 failures left15:19
zyga7 failures :)15:20
mupPR snapd#4531 closed: cmd/snap: display snap license information <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4531>15:22
mvothanks mborzecki15:23
zygalibreoffice 6.0 is out, will the snap be refreshed?15:50
zygaah :)16:04
zygaman that was silly16:04
zyga3 errors left, will be done in a moment16:04
Chipacapstolowski: 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
Chipacait'll be a separate pr16:15
pedronisChipaca: config16:16
Chipacapedronis: is config sorta-kinda the 'backend' of configstate?16:16
pedronisotherwise it cannot be used from snapstate16:16
Chipacathis is for use from snapshotstate, but ok16:16
pedronisChipaca: no, it's mostly the accessor that can be used by any other *state16:17
pstolowski+1 (config)16:17
pedronisChipaca: confistate itself imports a bunch of *state16:17
pedronisso that's why config exists16:17
pedronisotherwise circular imports16:17
Chipacais there any reason a snapshot should save a revision-config?16:18
Chipacathe "what happens if you restore a revision that isn't current" question comes to mind16:18
pedronisthose are used one revert I think16:18
pedronisare you snapshotting a revision? or all of them?16:19
Chipacapedronis: a single one16:19
Chipacathe current one16:19
pedronisand you restore the current one?16:19
pedronisin that case I don't think revision-config is relevant16:20
Chipacano, restore restores whatever was snapshot16:20
pedronisbut puts it backa as current?16:20
pedronisthen it's complicated16:20
pstolowskiin that case i think you should restore your snapshot into whatever is current rev16:20
pedronisyou need to care about about revision-config16:20
pedronisI think16:20
pstolowski(so,just config)16:20
Chipacamaybe restore should block restore unless the revision is current16:20
Chipacathen the problem goes away :-)16:21
Chipacaat least for now16:21
Chipacamaybe in a followup it can restore to current always, but doing that to a 'live' snap makes me nervous16:22
Chipacaanyway, going with "config" for now16:23
mupPR snapd#4574 opened: tests: add integration for local snap licenses <Created by mvo5> <https://github.com/snapcore/snapd/pull/4574>16:28
mupPR 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
Chipacapedronis: pstolowski: ^ a quickie  (i hope)16:37
zyga2 lef16:39
zyga2 left :)16:39
Chipacazyga: 2 leffe?16:41
zygaChipaca: two tests failing; almost done :)16:42
pstolowskiChipaca, +116:43
Chipacawhy can i edit your review summary16:44
mupPR 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
zygabig n boring16:48
zygabut had to be done16:48
zyganow I feel good about that code :)16:48
zygaI also tweaked a few strings based on one more patch I had, the error messages are nicer16:49
zygamvo: ok, I think I can close that chapter for today, I can do code reviews or I can write about the content interface improvements16:50
mupPR 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
mvozyga: writing sounds good16:51
zygamvo: okay, let's get that done :)16:52
zygaif 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 strings16:53
mvozyga: yeah, just looking at it16:53
* zyga tries to recall why x.snapd.symlink=foo is not conveyed through Entry.Name, hmm hmm16:57
zygamaybe it would be nicer to read16:57
zygabut I did that for *some* reason, I remember that much16:57
zygawell, did it the way it is now16:57
zygathose tests took about two days to write in this final form16:57
* kalikiana going to wrap up for the day17:02
zygaChipaca: question on 457517:04
Chipacazyga: or is there17:05
Chipacazyga: (i don't see a question)17:05
zygaChipaca: hmmmm17:05
zygait got eaten17:05
Chipacagithub is hungry today17:05
zygaI was asking why are we returning json.RawMessage by value17:05
Chipacazyga: it's a []byte; it's already a pointer17:06
zygaand if that is safe actually (shallow copy)17:06
zygaah, perfect17:06
zygathanks! LGTM17:06
ChipacaI don't know why config uses *json.RawMessage (and it might, because it does some funky stuff), but these two functions are un-funky17:06
Chipacamight need to*17:07
ogra_sigh ...17:07
zygaChipaca: was that related to some bug in json17:08
zygawhere you need the pointer to get some methods right17:08
zygasomething like that echoes in my head17:08
Chipacait might be; if it is, pedronis will know :-)17:08
zyga+ snap install test-snapd-control-consumer17:08
zygaerror: cannot install "test-snapd-control-consumer": cannot get nonce from17:08
zyga       store: store server returned status 41817:08
Chipacaaw, so close to 41917:08
zygais that my bus home? :)17:08
Chipacaah no17:09
Chipaca418 is the one17:09
zygawhat is it?17:09
zygashould we retry that?17:09
Chipaca418 I'm a teapot17: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
Chipacazyga: which in our tests means it is (hopefuly!) not talking to an actual server17:09
zygahaha, cute :)17:10
pedronisit's talking to the fakestore and trying to setup a device session17:10
pedronisor something like that17:10
pedroniswhy is it doing that though?17:10
pedronisonly now17:10
zygait is in here https://api.travis-ci.org/v3/job/335552657/log.txt17:12
zygain this PR https://github.com/snapcore/snapd/pull/456217:12
mupPR #4562: debian: add a zenity|kdialog suggests <Created by mvo5> <https://github.com/snapcore/snapd/pull/4562>17:12
pedronisit is using the fakestore17:15
pedroniswondering why we never got this kind of error17:15
pedronisit's a while since the situation in which we might try to create a device session have increased17: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.service17:28
ogra_ogra@localhost:~$ snap get core service.rsyslog.disabled17:28
ogra_ogra@localhost:~$ ps ax|grep syslog17:28
ogra_ 2195 ?        Ssl    0:00 /usr/sbin/rsyslogd -n17:28
zygamvo: do we need https://github.com/snapcore/snapd/pull/4562 for the final release?17:31
mupPR #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 pi217:34
cachio_mvo, old core snaps17:34
cachio_it is weird because I  created the images after the cores were uploaded to the store17:34
* Chipaca afk for a while17:50
mupBug #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 issue18:11
cachio_mvo, it happens in the refresh scenario18:11
cachio_when we refresh from stable (factory release)18:11
cachio_I'll debug it once the execution finishes18:11
zygain test-snapd-tools expected to have a key 'license'18:11
zygathat looks like the recently added thing18:11
cachio_mvo, it failed in both 32 and 64 bits18:12
zygayes, it's not something that's arch dependent18:12
cachio_zyga, ok, I'll take a look in that case18:13
zygacachio_: look at the newly merged patches18:21
cachio_zyga, yes, this issue was not happening in rc118:22
cachio_it is quite new18:22
cachio_I am debuging18:22
cachio_zyga, any idea which PR was included the code that could be causing that?18:22
mvoogra_: hm, I remember code to mask it but I will double check in the morning18: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
mupPR 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
mvozyga: 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 installed18:34
slangasekogra_: what does signing an initrd mean to you?18:34
ogra_slangasek, well, having a signed img file18:34
ogra_and grub verifying that18:34
mvocachio_: meh, I think its my fault :/18:35
mvocachio_: I cherry-picked the license display PR into 2.3118:35
mvocachio_: so there is a test for it in git18:35
mvocachio_: but this cherry-pick is not included in ~rc218:35
mvocachio_: that explains the failure18:35
slangasekogra_: grub verifying it using what code?18:36
ogra_slangasek, dunno, thats why i ask :) would that be a kernel thing ?18:37
slangasekogra_: 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 kernel18: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 that18:39
ogra_... in the hope it allows me to have single files i can load18:39
ogra_(but still keep a secure chain of verified images)18:40
* ogra_ finds https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd18:48
cachio_mvo, I noteced that :)18:54
slangasekogra_: right, so initrd is difficult because it's generated outside the archive, and the UEFI signing keys are quite intentionally only in the archive18:56
ogra_slangasek, right, but thats not the case in snap-land :)18:56
slangasekogra_: it's still not generated in the Ubuntu archive, AFAIK?18:58
cachio_mvo, also we need a strace-static snap for i38618: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-house18:59
ogra_so no archive key involved19:00
slangasekogra_: 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 it19: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 dinner19:08
jdstrandogra_: otoh, I don't... tyhicks *may*, but jjohansen probably would (though he is traveling and may not be available)19:42
jdstrandtyhicks, jjohansen: question from ogra is when does "bpf" show up in /proc/filesystems?19:42
zygahey jdstrand o/19:44
jameshzyga: 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
mupPR 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
tyhicksogra_, jdstrand: is there more context? (I don't have backscroll handy)19:48
tyhicksogra_, 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
tyhickss/and that you already know that/and suspect that you already know that/19:49
mvocachio_: sure thing, let me fix the strace-static thing19:49
jdstrandhey zyga19:49
jdstrandtyhicks: right. let me give the whole question19:50
zygajamesh: that's a good question, I think it was decided long ago19:50
zygajamesh: I'm not super fond of it as we probably don't do things correctly then19:50
jdstrandtyhicks: 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
tyhicksI can answer that with some investigation19:51
jdstrandzyga: considering that snap-update-ns tries to do things in order, failing somewhere along the way and continuing as if it succeeded seems incorrect19:52
jdstrandogra_ (cc zyga): I just looked at 3 different core systems, and none of them have a populated /etc/apparmor.d/cache19:53
tyhicksogra_: the bpf filesystem was first added in kernel 4.4 with this commit: https://git.kernel.org/linus/b2197755b2633e164a439682fb05a9b5ea48f70619:53
jdstrandogra_ (cc zyga): /var/cache/apparmor is correctly populated with snap cache (and nothing else)19:54
tyhicksogra_: from what I can tell, it is only hidden behind CONFIG_BPF_SYSCALL19:54
jdstrandogra_ (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 run19:56
zygajdstrand: oho19:57
zygajdstrand: nice find19:57
mvojdstrand: with me "empty-etc" hat on> why is etc used to write a cache?19:58
jdstrandogra_ (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 sure19:58
zygamvo: your question is spot on19:58
jdstrandmvo: hi! terribly longtime historical reasons19:58
mvojdstrand: fair enough, just like 80% of etc19:59
jdstrandmvo: right19:59
jdstrandmvo: it predates me. afaik, it was there because alternatives weren't guaranteed to be mounted during early boot (eg, /var)19:59
zygamvo: you probably know better than I do that /etc used to hold *binaries*20:00
jdstrandmvo: and other places were not lsb compliant (not that /etc/apparmor.d/cache is)20:00
jdstrandmvo: 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 boot20:02
jdstrandmvo: 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 boot20:02
mvojdstrand: ok20:02
jdstrandmvo: I'm not sure how much you saw before you dropped off...20:03
mvojdstrand: I missed this, thanks for pasting20:03
mvojdstrand: my machine is a bit unstable recently, I wonder if I need to purge the intel-microcode package :(20:03
jdstrandmvo: here are two more:20:03
jdstrandmvo: it predates me. afaik, it was there because alternatives weren't guaranteed to be mounted during early boot (eg, /var)20:04
jdstrandmvo: and other places were not lsb compliant (not that /etc/apparmor.d/cache is)20:04
mvojdstrand: ta20:04
jdstrandmvo: maybe-- mine made suspend not work at all20:04
jdstrandwell, it would suspend. it wouldn't come out ;)20:04
jdstrandI'm hopeful new microcode will be available20:05
mvojdstrand: 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
mvojdstrand: I will purge it for now :(20:05
jdstrandmvo: can you think of what might've caused the cache to not be populated?20:06
jdstrandmvo: do you also recall this used to work?20:06
mvocachio_: I create a proper lp:~snappy-dev/strace-static-snap/trunk project with an auto snap build20:06
cachio_mvo, awesome, tx20:06
jdstrandogra_: can you file a bug for /etc/apparmor.d/cache and we can contineu there?20:07
mvojdstrand: 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-only20:07
mvojdstrand: fwiw, I hope we won't have writable-paths for core18 just a plain writable etc20:07
jdstrandit certainly is meant to work, otherwise those poor arm devices are grumpy20:07
* jdstrand -> gotta run. bbiab20:07
mupPR 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
mupPR 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
zygamvo: +120:36
mvozyga: ta20:47
mupPR 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
mupPR snapd#4577 opened: snap: fix command-not-found on core devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/4577>20:47
zygamvo: so... it wasn't tested in practice before?20:49
zygamvo: hmm20:50
zygamvo: why20:50
zyga +cmd.Positionals.CommandOrPkg = os.Args[2]20:50
zygaI don't get it20:50
zygayou iterate over all args except 0th20:50
zygaand then you can have a chain of --20:51
zygaand the first one that doesn't will set a _fixed_ answer20:51
zygais that correct?20:51
mvozyga: meh, incomplete push20:51
mvozyga: sorry20:51
mvozyga: please reload20:52
mvozyga: originally I wanted to just hardcode os.Args[2]20:52
mvozyga: but then though checking for "--" would be more robust if the handler that calls c-n-f ever changes20:52
mvozyga: I guess it shows that I should stop for today :)20:53
mvozyga: the integration on a real shell on a core device was not tested until today :/ many moving parts20:53
geekgonecrazyGreetings guys.  Back with more snap/snapcraft related issues. :)21:02
geekgonecrazyIn the rocketchat-server snap we do an npm install.  One of the packages seems to always have issues getting properly snapped up21:02
geekgonecrazySo 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 them21: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
geekgonecrazywe see this ^ and that exact same file is then complained about being missing when we try to start it21:04
geekgonecrazydoes "Unable to determine library dependencies" really mean... "Can't figure out what to do with this so skipping" ?21:04
zygageekgonecrazy: this is something for sergiusens, kyrofa and kalikiana21:12
zygathough they are sprinting this week so conditions apply21:13
geekgonecrazyzyga: 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
geekgonecrazyi'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
zygageekgonecrazy: I don't know, sorry21:23
zygageekgonecrazy: they have a sprint now in US so probably not21:24
zygathough maybe someone else is going21:24
geekgonecrazyzyga: no biggie.  Just figured someone around might know :D21:35
mupPR 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
tyhicksogra_: kernel version?23:20
jdstrandgreyback: 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!