=== chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [06:10] morning [06:28] hmm https://github.com/snapcore/snapd/pull/6652 travis job is finished (and green), gh status is still pending :/ [06:28] PR #6652: sanity: use proper SELinux context when mounting squashfs [06:33] good morning [06:33] mborzecki: sucky night, my dog is sick, keeps throwing up all night [06:33] mborzecki: I'm tired and not sure how the day will unfold [06:37] zyga: uhh, sucks, make him fast a bit, always helps with my dog pack === cpaelzer__ is now known as cpaelzer [07:22] back in the office [07:41] PR snapd#6654 opened: packaging/fedora, tests/upgrade/basic: patch existing mount units with SELinux context on upgrade [07:42] almost there with selinux [07:42] just one more PR on top of what's already open [07:49] mvo: morning [07:52] hey mborzecki [07:52] mborzecki: how are you? how are the tests this morning? [07:53] mvo: undecided, had to restart a spread job bc ubuntu-16.04-32 was taking too long a hit a kill-timeout:? [07:53] mvo: maybe a trivial review to start the day? https://github.com/snapcore/snapd/pull/6652 [07:53] PR #6652: sanity: use proper SELinux context when mounting squashfs [07:55] mborzecki: sounds great [07:55] mborzecki: doing that now [07:57] mvo: thanks! [07:59] eh, the dog keeps throwing up [07:59] hey mvo [07:59] mvo: a quick one please: https://github.com/snapcore/snapd/pull/6650 [07:59] PR #6650: cmd/libsnap: neuter variables in cleanup functions [08:02] zyga: sure, looking === pstolowski|afk is now known as pstolowski [08:02] morning [08:02] hey pawel [08:03] pstolowski: hey [08:11] PR snapd#6650 closed: cmd/libsnap: neuter variables in cleanup functions [08:21] mvo: hi, #6602 could use a 2nd review [08:21] PR #6602: cmd,interfaces: replace local helpers with cmd.InternalToolPath [08:26] pedronis: looking [08:39] mvo: zyga: it seems you found some kind of agreement in #6410 , is that implemented? is it close to land? [08:39] PR #6410: release-tools: add debian-package-builder [08:42] PR snapd#6559 closed: pkg/apparmor: scratch documentation of apparmor [08:47] pedronis: yes, I will try to get to it today, [08:47] pedronis: the agreement is that we simply take the script's essential part and add it as a debug section in the sid task [08:47] pedronis: so that if it fails, people know how to debug [08:47] zyga: mvo wrote something else at the end [08:47] (so maybe there is not an agreement) [08:50] pedronis: looking [08:50] ah, that's even easier [08:50] * zyga goes to do that now [08:51] sorry, today is not great, my dog is sick and makes all kinds of mess :/ [08:52] zyga: it's fine, I was just trying to understand if there was a bit of clarity there, otherwise at this point I would have close it [08:52] zyga: I don't think you are particularly blocked by me anymore right this moment, I need to go back to mvo's remodel PRs [08:53] pedronis: I'm okay now, thank you! [08:54] zyga: sorry for the poor dog [09:00] mvo: does the dtb update mechanism work in core18 now? [09:01] hi, I'm hitting this error since yesterday when trying to build with snapcraft in bionic containers: https://paste.ubuntu.com/p/bhYGfpj8Rc/ anyone could advise? [09:02] ackk: Recursivity. Call back if it happens again. [09:03] * Chipaca puts away his BOFH excuse generator again [09:03] pstolowski: hi, 6491 can be landed [09:04] pedronis: great, ty! zyga - last chance to have a look [09:04] Chipaca, I can reprooduce constantly, I can't seem to build the snap [09:05] pstolowski: I looked a little last night and it is ok [09:05] ackk: it was meant as a joke, sorry [09:05] approved just now [09:05] pstolowski: I'm sure we can improve the test over time, but I don't think it should be a blocker [09:05] ackk: snapcrafters should be alive shortly to help you out [09:05] Chipaca, ok, thanks [09:05] ackk: have you tried with snapcraft from candidate? [09:05] * ackk tries [09:06] pedronis: yep [09:06] PR snapd#6652 closed: sanity: use proper SELinux context when mounting squashfs [09:07] Chipaca, same error [09:08] Chipaca, does snapcraft need to run under sudo with --destructive-mode? [09:09] uhm, it seems so it's trying to do apt stuff [09:10] ackk: I think when snapcraft runs it, it runs as rot [09:10] root [09:10] but i'm not 100% on that [09:12] ackk: --destructive-mode mangles your system [09:12] pedronis: i've sent hotplug docs to you & Graham; i've deliberately omitted HotplugKey method that the interfaces could implement due to the slightly undefined story with versioning of keys that we talked about [09:14] oh it seems I had some stuff owned by root in ~/.cache/snapcraft [09:14] pstolowski: I'll try to look later today [09:14] thx [09:16] PR snapd#6491 closed: interfaces: hotplug nested vm test, updated serial-port interface [09:20] ppisati: we are working on the firmware update mechanism, but its not done yet, do you have a use-case where you need it? [09:28] PR snapd#6651 closed: tests: all the systems for google backend with 6 workers [09:36] degville: mo'in! [09:36] Chipaca: morning! [09:36] Chipaca, there's currently no way of having "snapctl set" execute hooks automatically, right? [09:36] degville: the 'squiggly road' paragraph i added, i added it to clarify what i thought was maybe confusing, but not sure how successful i was [09:38] ackk: what do you mean? [09:38] Chipaca, if I run "snapctl set" from within a snap, it won't run the config hook right? [09:38] correct [09:38] mvo: yes, a bionic/snapdragon update that contains a heavily modified dtb [09:39] ackk: you're holding it from the wrong end [09:39] mvo: a did a pass on the first and last of the current remodel PRs [09:39] ackk: if you're inside the snap, call the configure hook and let it call snapctl set [09:39] Chipaca, the configure hook reacts to the set, doesn't set things [09:39] Chipaca: ? the configure hook doesn't call snapctl set (usually) [09:39] mvo: but if there's no dtb update mechanism, we can't pull it in [09:39] (the hook needs to behave differently when not called as a hook tho [09:40] pedronis: we have tests for that use case [09:40] pedronis: so i presumed it was a'ight [09:40] it can do that [09:40] is just not typical [09:40] anyway it's not the first time we had that request [09:40] Chipaca, in my case the config hook reads the config and generates some config files, I don't want/need it to set snap configs [09:40] we cannot really change the default though [09:40] s/default/default mode of operation inside a snap/ [09:41] Chipaca, pedronis, I have a case where a script in the snap would need to set setuff via "snapctl set", and trigger the hook. I can call it manually, I was just wondering if there was a way to have snapctl do it [09:42] Chipaca: we could introduce snapctl set --configure (it would need to error if called that way from inside the configure hook itself) [09:43] ackk: is this from inside a hook inside the snap? [09:43] Chipaca, not from a hook, just from a script shipped within the snap [09:44] Chipaca, it's basically a "init" script [09:44] as in, to initialize the service configuration [09:44] gotcha [09:44] Chipaca: I think the squiggly road is a valuable addition. I may have a small question I'll add to the doc. [09:45] degville: it's definitely advanced usage, but needs to be documented (and an attempt at explaining it) somewhere because people will butt against this at some point (and it will make their heads wobble) [09:47] thanks Chipaca, that's good to know. [09:47] pedronis: --configure would have to be async though, right? [09:47] or weird if already inside a hook [09:48] Chipaca, I don't think it should be allowed from a hook [09:49] Chipaca, what I'm talking about is calling snapctl set from within the snap, but not in a hook, like from a app in the snap [09:49] ackk: yes [09:50] ackk: but 'snap set' kicks off a 'configure-snap' change [09:51] ackk: if you're in a hook, you're running from a task [09:51] Chipaca: it would need care implementation wise [09:51] ackk: so either it's weird because it will work in a snap and not a hook (surprising developers trying to do it), or needs extra care [09:52] pedronis: ye [09:53] Chipaca, setting configs in a config hook seems a bit weird to me [09:53] ackk: agreed, but what about a refresh hook, to set config defaults say? [09:53] ackk: what about in an install hook to run 'init'? [09:53] that's a different hook though, so you could allow that [09:54] where's the emoji for 'turtles all the way down' [09:54] heh [09:54] I agree it's tricky, I'm just saying I don't think it would be really surprising if config hook doesn't trigger itself [09:54] whereas triggering the config hook from other hooks makes more sense [09:59] ppisati: ok, thank, looks like this will be our first test for the new feature then [09:59] pedronis: thanks, I will go over them [10:02] degville: Chipaca: let me know when the epoch docs is ready for another pass from me [10:02] pedronis: will do, thanks! [10:03] thx [10:08] mvo: well, but if we push the kernel now and the mechanism is not working yet, we are going to break people's installation [10:12] ppisati: right, then we can't push it yet :/ [10:12] ppisati: how is it organized on the dragonboard? the dtbs there are part of the gadget? [10:13] Chipaca: I've just left one quick q in the doc I can't get my head around. [10:13] degville: that's ok, i can't get my head around the q :-) [10:13] Chipaca: ahahaha! [10:13] mvo: last time i talked with ogra, when ubuntu-image build an image, it picks them from the kernel snap [10:13] ogra: ^ [10:14] * ogra reads backlog [10:14] degville: let me rephrase the paragraph and see if it helps [10:14] thank you! [10:14] ppisati: kernel snap sounds promising - if they get loaded from /boot/dragonboard-kernel_121/foo.dtb we would be good but I doubt somehow this is the case [10:15] mvo, yeah, as ppisati said, dragonboard uses the kernel snap (as every other board except the pi) [10:15] (for dtb's that is) [10:16] degville: did that help? [10:16] looking now. [10:17] Chipaca: yes, thanks! [10:17] degville: it feels more stuttery now [10:18] zyga: ooh, ooh, post-merge reviews! [10:18] is that a song [10:19] ogra: does that mean the dtb gets unpacked from the kernel snap to /boot/$kernel/foo.dtb already? if so we should be good, no? [10:20] mvo, well, you wrote that code :P ... but yes, the dtbs dir from the kernel should be copied 1:1 into /boot/uboot// [10:20] IIRC it copoes the whole dir [10:21] *copies [10:21] ogra: yeah, I can look into the code if its DTRT but it sounds very promising [10:21] and uboot.env should be set up tp load it from $snap_kernel/dtbs/ [10:21] ogra: cool [10:21] only the pi differs [10:22] (and some of my dev images where i pull dtbs from linux-next explicitly into the gadget) [10:22] ppisati: so given what ogra wrote we should be good because the dtb is part of the kernel snap and the kernel extraction etc, this needs double checking, unfortunately I don't have a dragonboard myself but if you hvae the updated kernel, you could make it available in a store branch and I can ask our QA team to test [10:22] ogra: ok [10:23] ogra: that sounds all good, thanks for checking [10:23] mvo, ppisati also, ondra is usually surrounded by dragonboards and clones if you need a tester ;) [10:24] Chipaca, has $HOME always been set to $SNAP_USER_DATA? [10:24] ackk: yes [10:24] not in 15.04 :P [10:24] I'm wishing we had a way to say 'no thanks' [10:24] ogra: yes in 15.04 [10:24] AFAIR at least [10:24] (there the variable was called differently :P ) [10:25] HOME was set to SNAPPY_USER_DATA_WITH_POTATOES_AND_A_SIDE_OF_WTF [10:25] yeah [10:25] * Chipaca tickles ogra [10:25] a hilariously long name [10:25] * ogra laughs [10:26] to be clear, we've been setting HOME to a-per-revision-place-the-snap-can-write-to since before snapd existed [10:26] it's just not been called SNAP_USER_DATA all the time [10:26] yup [10:26] it used to be $SNAP_APP_USER_DATA_PATH [10:27] and before that s/SNAP/SNAPPY/ [10:27] but that was early on [10:29] Chipaca, ogra so if an app with :home plug wants to refer to the actual user home, it would have to assume it's /home/$USER (or /root) right? [10:29] unless it is a daemon or run by root, yes [10:30] ackk: what I do in an app where I need to write to the user's home dir, is getent [10:30] Chipaca, ah, I see [10:30] ackk: https://github.com/chipaca/icdiff/blob/master/snap/snapcraft.yaml#L73 [10:30] export HOME=$(perl -we "print((getpwuid $>)[7])") [10:30] hah [10:31] perl [10:31] * Chipaca whistles innocently [10:33] mvo: when you have time, what's the status of #6594 ? [10:33] PR #6594: [RFC] tests: run smoke tests on (almost) pristine systems [10:33] HOME="$(getent passwd $USER | cut -d: -f6)" [10:33] (for a shell variant) [10:34] but, i was tempted to offer some sort of a no-home-squash flag for apps, because it is a bit silly in those cases [10:34] pedronis: wdyt? [10:35] Chipaca: about what? [10:36] pedronis: having a way of telling snapd not to rewrite HOME [10:36] per app === chihchun_afk is now known as chihchun [10:36] Chipaca: in the snap(craft).yaml ? [10:36] pedronis: because when your app needs to honestly access the user's home, currently you need to look it up [10:36] pedronis: yea [10:37] example is icdiff's git-icdiff app, which needs to read ~/.gitconfig [10:37] and ~/.config/git/config [10:37] Chipaca: why did we go with the current approach? should it be tied to having a home plug? [10:37] setting the flag but not having the home plug will not do any good [10:37] pedronis: current approach is because a lot of legacy apps just work if you point home to someplace they can write [10:38] pedronis: an app could have a personal-files without having home though [10:38] but maybe personal-files and home are the only two cases [10:40] pedronis: 6594 is on hold, I need a good idea basicly, we can have a HO about the issue if you want or I can write something up, in a nutshell I want to ensure that the smoke tests are still run at every spread run but also that they run reliable in adt without surprises when I upload, so they should be as close as possible [10:40] * dot-tobias says hi [10:40] ogra: if ondra could test this kernel update, that would be great (cc ppisati) [10:40] mvo: ok, I need to look at this carefully then before it makes sense to chat, worst case we'll chat next week about it [10:41] pedronis: we can chat so that you don't need to do the digging yourself and then we can chat again [10:41] pedronis: but either way is fine [10:41] pedronis: its not urgent its just something that nags me [10:43] mvo: let's try to progress a bit on remodel stuff first [10:44] Chipaca: sounds it needs a forum post, I'm not against , at the moment I'm unsure how to spell it sensibly in the yaml. [10:44] be-all-the-home-you-can-be: [10:45] if it's 42, don't overwrite HOME [10:45] \o/ [10:45] Chipaca: :) [10:45] * Chipaca reaches consensus and moves on to implement [10:45] Chipaca: also will people learn about this [10:46] pedronis: maybe in the forum we should poke popey/wimpress/bad-jokes-igor [10:48] Chipaca: unrelated, what is scope in search? I forgot it seems or never knew [10:48] pedronis: scope=wide → cross-channel [10:48] ah [10:49] I had forgotten [10:49] pedronis: snap find --narrow → not wide [10:52] Chipaca: I'm staring at this https://github.com/snapcore/snapd/blob/master/store/store.go#L1094 and wondering if Prefix is in a good position in the struct or not, totally nitpicky state of mind [10:52] Chipaca: anyway while doing that I noticed that this comment seems reversed: https://github.com/snapcore/snapd/blob/master/store/store.go#L1127 [10:53] Chipaca: it's all common-id fault [10:53] pedronis: I don't think so [10:53] Chipaca: should that comment say public? [10:53] 1 sec [10:54] it seems if you mix Prefix and Private it fails [10:55] pedronis: right, you can only do fuzzy search of private [10:55] pedronis: that is, you can't do name=foo private=true [10:55] ??? [10:55] I'm totally confused [10:56] 1 sec [10:56] is "name" fuzzy search? is q fuzzy search? [10:59] pedronis: q is fuzzy [10:59] Chipaca pedronis What was this regarding? [10:59] pedronis: name is prefix [10:59] $HOME? [10:59] Wimpress: having a way to say 'this app needs the real $HOME, not $SNAP_POTATOES' [10:59] Interesting. [10:59] Wimpress: i'll write a topic later [11:00] Excellent! [11:00] so we can hash it out if-n-when [11:00] pedronis: I was trying to show you an easy example, but searching private snaps with names=... is hard :-) [11:01] Chipaca: anyway maybe that comment should say "cannot do private prefix searches" [11:01] or maybe is just me [11:01] pedronis: it's never just you [11:01] pedronis: you're one in a million, meaning there's seven thousand of you [11:02] :-p [11:02] :) [11:11] Chipaca: related to the other nitpicking thought, I wonder if the struct(s) shouldn't look like: https://pastebin.ubuntu.com/p/cYbTtB7fjX/ [11:14] zyga: did you see https://github.com/snapcore/snapd/pull/6614#pullrequestreview-219370705 ? [11:15] PR #6614: cmd/snap-confine: use fixed private tmp directory [11:16] Chipaca: looking [11:16] Chipaca: no, I haven't [11:16] interesting [11:20] neat [11:20] Chipaca: need to go for lunch, that struct(s) suggestion and maybe changing that comment could be in a follow up, if the common-id one turns great [11:20] suse folks are going through the patches I've sent [11:20] Chipaca: heh, s/great/green/ [11:20] pedronis: ack [11:23] Chipaca: when you get a moment, I've tried to replicate that squiggly road para into a table, which I hope is easier to parse (if accurate). [11:23] degville: i'll look in a few [11:23] thanks! [11:24] Chipaca: everybody wants a piece of you today :) [11:24] mvo: it's my fault for being awesome [11:24] Chipaca: it totally is! [11:24] Chipaca: also see /msg :) [11:25] * Chipaca hopes mvo didn't have a mouthful of tea just tehre === chihchun is now known as chihchun_afk [11:25] Chipaca: haha === mborzeck1 is now known as mborzecki [11:36] PR snapd#6655 opened: timings: SetTag and SetTagFromChange helpers [11:38] mvo, hey [11:46] ogra@anubis:~$ hello-world.sh [11:46] SNAP_INSTANCE_NAME is not set [11:46] hmm, whats that ? [11:47] did we break the hello-world snap ? [11:47] niemeyer, the https://github.com/snapcore/spread/pull/75 is updated, could you please take a look? thanks [11:47] PR spread#75: Make spread tests for spread project run on google backend [11:50] ogra: seems to work fine here [11:50] ogra: works here; what versions do you have? [11:50] yeah, weird, works fine on my arm boards too [11:50] ogra@anubis:~$ snap list hello-world [11:51] Name Version Rev Tracking Publisher Notes [11:51] hello-world 6.3 27 stable canonical✓ - [11:51] latest stable it seems [11:51] snap version? [11:51] ogra@anubis:~$ snap version [11:51] snap 2.37.4 [11:51] snapd 2.37.4 [11:51] series 16 [11:51] ubuntu 16.04 [11:51] kernel 4.4.0-141-generic [11:52] ogra: is that an ancient instalation [11:52] ogra: and hello-world.sh is using the /snap/bin/hello-world.sh shell script? [11:52] ogra@anubis:~$ /snap/bin/hello-world.sh [11:52] SNAP_INSTANCE_NAME is not set [11:52] ogra@anubis:~$ [11:52] hey cachio - sorry for the delay, was in a call [11:53] ogra: which hello-world.sh [11:53] ogra@anubis:~$ which hello-world.sh [11:53] bah [11:53] ogra@anubis:~$ which hello-world.sh [11:53] /snap/bin/hello-world.sh [11:54] IRC and slashes ... pfft [11:55] ogra: snap run --shell hello-world [11:55] ogra: printenv | grep SNAP | sort [11:55] ogra: please [11:56] https://paste.ubuntu.com/p/CwwHxvqJm7/ [11:56] obviously has that var [11:57] mvo, no problem [11:57] mvo, about core18 [11:58] there are several problems with the beta validation [11:58] mvo, but most important ones [11:58] the core18/snapd-refresh test fails on all the architectures [11:59] ogra: the 'SNAP_INSTANCE_NAME is not set' error comes from snap-confine [11:59] ansd it is because after the revert, the test reboots and when it happens we loose the network configuration on the device [11:59] Chipaca: I know [11:59] ogra: do you have a wonky snap-confine :-) [11:59] mvo, basically, the board has ip: 127.0.0.1 [12:00] and not way to contact it [12:00] Chipaca: but remember how we used to generate launcher scripts [12:00] those would set SNAP_NAME [12:00] Chipaca: that would be one way of having this issue [12:00] Chipaca, dunno, my other snaps seem to work (i'm obviously typing here ... hexchat is from the snap) [12:00] ogra: is /snap/bin/hello-world.sh a symlink or a script? [12:00] mvo, then I see a similar behaviour [12:00] cachio: oh, nasty [12:00] ogra: ls -l `which hello-world.sh` [12:00] mvo, installed the stable and tried to refresh with the core from bet [12:00] a [12:01] Chipaca, zyga, aha ! its a script !!! [12:01] and it fails [12:01] ogra: you installed hello-world in 1674 [12:01] cachio: what is the error message? [12:01] ogra: :-) [12:01] ogra: hahaha [12:01] ogra: can you can the script here [12:01] mvo, the same, network is list [12:01] * zyga was right :) [12:01] lost [12:01] i installed it whenever ... but yeah, its oooold [12:01] cachio: it fails because there is no network anymore? [12:01] * zyga high-fives [12:01] ogra: I can add a workaround [12:01] mvo, mvo yes [12:02] cachio: woah [12:02] but it would be best if snapd rewrote those things [12:02] https://paste.ubuntu.com/p/twdYDGmGk6/ [12:02] mvo, in the logs I don't see nothing about errors [12:02] cachio: this is on our pc-amd64, right? no network-manager snap or anything like this [12:02] also in the chnage everything is ok [12:02]