| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| mborzecki | morning | 06:10 |
|---|---|---|
| mborzecki | hmm https://github.com/snapcore/snapd/pull/6652 travis job is finished (and green), gh status is still pending :/ | 06:28 |
| mup | PR #6652: sanity: use proper SELinux context when mounting squashfs <SELinux> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6652> | 06:28 |
| zyga | good morning | 06:33 |
| zyga | mborzecki: sucky night, my dog is sick, keeps throwing up all night | 06:33 |
| zyga | mborzecki: I'm tired and not sure how the day will unfold | 06:33 |
| mborzecki | zyga: uhh, sucks, make him fast a bit, always helps with my dog pack | 06:37 |
| === cpaelzer__ is now known as cpaelzer | ||
| zyga | back in the office | 07:22 |
| mup | PR snapd#6654 opened: packaging/fedora, tests/upgrade/basic: patch existing mount units with SELinux context on upgrade <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6654> | 07:41 |
| mborzecki | almost there with selinux | 07:42 |
| mborzecki | just one more PR on top of what's already open | 07:42 |
| mborzecki | mvo: morning | 07:49 |
| mvo | hey mborzecki | 07:52 |
| mvo | mborzecki: how are you? how are the tests this morning? | 07:52 |
| mborzecki | mvo: undecided, had to restart a spread job bc ubuntu-16.04-32 was taking too long a hit a kill-timeout:? | 07:53 |
| mborzecki | mvo: maybe a trivial review to start the day? https://github.com/snapcore/snapd/pull/6652 | 07:53 |
| mup | PR #6652: sanity: use proper SELinux context when mounting squashfs <SELinux> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6652> | 07:53 |
| mvo | mborzecki: sounds great | 07:55 |
| mvo | mborzecki: doing that now | 07:55 |
| mborzecki | mvo: thanks! | 07:57 |
| zyga | eh, the dog keeps throwing up | 07:59 |
| zyga | hey mvo | 07:59 |
| zyga | mvo: a quick one please: https://github.com/snapcore/snapd/pull/6650 | 07:59 |
| mup | PR #6650: cmd/libsnap: neuter variables in cleanup functions <Created by zyga> <https://github.com/snapcore/snapd/pull/6650> | 07:59 |
| mvo | zyga: sure, looking | 08:02 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 08:02 |
| zyga | hey pawel | 08:02 |
| mborzecki | pstolowski: hey | 08:03 |
| mup | PR snapd#6650 closed: cmd/libsnap: neuter variables in cleanup functions <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6650> | 08:11 |
| pedronis | mvo: hi, #6602 could use a 2nd review | 08:21 |
| mup | PR #6602: cmd,interfaces: replace local helpers with cmd.InternalToolPath <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6602> | 08:21 |
| mvo | pedronis: looking | 08:26 |
| pedronis | mvo: zyga: it seems you found some kind of agreement in #6410 , is that implemented? is it close to land? | 08:39 |
| mup | PR #6410: release-tools: add debian-package-builder <Created by zyga> <https://github.com/snapcore/snapd/pull/6410> | 08:39 |
| mup | PR snapd#6559 closed: pkg/apparmor: scratch documentation of apparmor <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6559> | 08:42 |
| zyga | pedronis: yes, I will try to get to it today, | 08:47 |
| zyga | 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 |
| zyga | pedronis: so that if it fails, people know how to debug | 08:47 |
| pedronis | zyga: mvo wrote something else at the end | 08:47 |
| pedronis | (so maybe there is not an agreement) | 08:47 |
| zyga | pedronis: looking | 08:50 |
| zyga | ah, that's even easier | 08:50 |
| * zyga goes to do that now | 08:50 | |
| zyga | sorry, today is not great, my dog is sick and makes all kinds of mess :/ | 08:51 |
| pedronis | 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 |
| pedronis | 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:52 |
| zyga | pedronis: I'm okay now, thank you! | 08:53 |
| pedronis | zyga: sorry for the poor dog | 08:54 |
| ppisati | mvo: does the dtb update mechanism work in core18 now? | 09:00 |
| ackk | 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:01 |
| Chipaca | ackk: Recursivity. Call back if it happens again. | 09:02 |
| * Chipaca puts away his BOFH excuse generator again | 09:03 | |
| pedronis | pstolowski: hi, 6491 can be landed | 09:03 |
| pstolowski | pedronis: great, ty! zyga - last chance to have a look | 09:04 |
| ackk | Chipaca, I can reprooduce constantly, I can't seem to build the snap | 09:04 |
| zyga | pstolowski: I looked a little last night and it is ok | 09:05 |
| Chipaca | ackk: it was meant as a joke, sorry | 09:05 |
| zyga | approved just now | 09:05 |
| pedronis | pstolowski: I'm sure we can improve the test over time, but I don't think it should be a blocker | 09:05 |
| Chipaca | ackk: snapcrafters should be alive shortly to help you out | 09:05 |
| ackk | Chipaca, ok, thanks | 09:05 |
| Chipaca | ackk: have you tried with snapcraft from candidate? | 09:05 |
| * ackk tries | 09:05 | |
| pstolowski | pedronis: yep | 09:06 |
| mup | PR snapd#6652 closed: sanity: use proper SELinux context when mounting squashfs <SELinux> <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6652> | 09:06 |
| ackk | Chipaca, same error | 09:07 |
| ackk | Chipaca, does snapcraft need to run under sudo with --destructive-mode? | 09:08 |
| ackk | uhm, it seems so it's trying to do apt stuff | 09:09 |
| Chipaca | ackk: I think when snapcraft runs it, it runs as rot | 09:10 |
| Chipaca | root | 09:10 |
| Chipaca | but i'm not 100% on that | 09:10 |
| zyga | ackk: --destructive-mode mangles your system | 09:12 |
| pstolowski | 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:12 |
| ackk | oh it seems I had some stuff owned by root in ~/.cache/snapcraft | 09:14 |
| pedronis | pstolowski: I'll try to look later today | 09:14 |
| pedronis | thx | 09:14 |
| mup | PR snapd#6491 closed: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug 🔌> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6491> | 09:16 |
| mvo | 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:20 |
| mup | PR snapd#6651 closed: tests: all the systems for google backend with 6 workers <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6651> | 09:28 |
| Chipaca | degville: mo'in! | 09:36 |
| degville | Chipaca: morning! | 09:36 |
| ackk | Chipaca, there's currently no way of having "snapctl set" execute hooks automatically, right? | 09:36 |
| Chipaca | 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:36 |
| Chipaca | ackk: what do you mean? | 09:38 |
| ackk | Chipaca, if I run "snapctl set" from within a snap, it won't run the config hook right? | 09:38 |
| pedronis | correct | 09:38 |
| ppisati | mvo: yes, a bionic/snapdragon update that contains a heavily modified dtb | 09:38 |
| Chipaca | ackk: you're holding it from the wrong end | 09:39 |
| pedronis | mvo: a did a pass on the first and last of the current remodel PRs | 09:39 |
| Chipaca | ackk: if you're inside the snap, call the configure hook and let it call snapctl set | 09:39 |
| ackk | Chipaca, the configure hook reacts to the set, doesn't set things | 09:39 |
| pedronis | Chipaca: ? the configure hook doesn't call snapctl set (usually) | 09:39 |
| ppisati | mvo: but if there's no dtb update mechanism, we can't pull it in | 09:39 |
| Chipaca | (the hook needs to behave differently when not called as a hook tho | 09:39 |
| Chipaca | pedronis: we have tests for that use case | 09:40 |
| Chipaca | pedronis: so i presumed it was a'ight | 09:40 |
| pedronis | it can do that | 09:40 |
| pedronis | is just not typical | 09:40 |
| pedronis | anyway it's not the first time we had that request | 09:40 |
| ackk | 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 |
| pedronis | we cannot really change the default though | 09:40 |
| pedronis | s/default/default mode of operation inside a snap/ | 09:40 |
| ackk | 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:41 |
| pedronis | Chipaca: we could introduce snapctl set --configure (it would need to error if called that way from inside the configure hook itself) | 09:42 |
| Chipaca | ackk: is this from inside a hook inside the snap? | 09:43 |
| ackk | Chipaca, not from a hook, just from a script shipped within the snap | 09:43 |
| ackk | Chipaca, it's basically a "init" script | 09:44 |
| ackk | as in, to initialize the service configuration | 09:44 |
| Chipaca | gotcha | 09:44 |
| degville | Chipaca: I think the squiggly road is a valuable addition. I may have a small question I'll add to the doc. | 09:44 |
| Chipaca | 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:45 |
| degville | thanks Chipaca, that's good to know. | 09:47 |
| Chipaca | pedronis: --configure would have to be async though, right? | 09:47 |
| Chipaca | or weird if already inside a hook | 09:47 |
| ackk | Chipaca, I don't think it should be allowed from a hook | 09:48 |
| ackk | 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 |
| Chipaca | ackk: yes | 09:49 |
| Chipaca | ackk: but 'snap set' kicks off a 'configure-snap' change | 09:50 |
| Chipaca | ackk: if you're in a hook, you're running from a task | 09:51 |
| pedronis | Chipaca: it would need care implementation wise | 09:51 |
| Chipaca | 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:51 |
| Chipaca | pedronis: ye | 09:52 |
| ackk | Chipaca, setting configs in a config hook seems a bit weird to me | 09:53 |
| Chipaca | ackk: agreed, but what about a refresh hook, to set config defaults say? | 09:53 |
| Chipaca | ackk: what about in an install hook to run 'init'? | 09:53 |
| ackk | that's a different hook though, so you could allow that | 09:53 |
| Chipaca | where's the emoji for 'turtles all the way down' | 09:54 |
| ackk | heh | 09:54 |
| ackk | 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 |
| ackk | whereas triggering the config hook from other hooks makes more sense | 09:54 |
| mvo | ppisati: ok, thank, looks like this will be our first test for the new feature then | 09:59 |
| mvo | pedronis: thanks, I will go over them | 09:59 |
| pedronis | degville: Chipaca: let me know when the epoch docs is ready for another pass from me | 10:02 |
| degville | pedronis: will do, thanks! | 10:02 |
| pedronis | thx | 10:03 |
| ppisati | 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:08 |
| mvo | ppisati: right, then we can't push it yet :/ | 10:12 |
| mvo | ppisati: how is it organized on the dragonboard? the dtbs there are part of the gadget? | 10:12 |
| degville | Chipaca: I've just left one quick q in the doc I can't get my head around. | 10:13 |
| Chipaca | degville: that's ok, i can't get my head around the q :-) | 10:13 |
| degville | Chipaca: ahahaha! | 10:13 |
| ppisati | mvo: last time i talked with ogra, when ubuntu-image build an image, it picks them from the kernel snap | 10:13 |
| ppisati | ogra: ^ | 10:13 |
| * ogra reads backlog | 10:14 | |
| Chipaca | degville: let me rephrase the paragraph and see if it helps | 10:14 |
| degville | thank you! | 10:14 |
| mvo | 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:14 |
| ogra | mvo, yeah, as ppisati said, dragonboard uses the kernel snap (as every other board except the pi) | 10:15 |
| ogra | (for dtb's that is) | 10:15 |
| Chipaca | degville: did that help? | 10:16 |
| degville | looking now. | 10:16 |
| degville | Chipaca: yes, thanks! | 10:17 |
| Chipaca | degville: it feels more stuttery now | 10:17 |
| Chipaca | zyga: ooh, ooh, post-merge reviews! | 10:18 |
| Chipaca | is that a song | 10:18 |
| mvo | 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:19 |
| ogra | mvo, well, you wrote that code :P ... but yes, the dtbs dir from the kernel should be copied 1:1 into /boot/uboot/<snapname>/ | 10:20 |
| ogra | IIRC it copoes the whole dir | 10:20 |
| ogra | *copies | 10:21 |
| mvo | ogra: yeah, I can look into the code if its DTRT but it sounds very promising | 10:21 |
| ogra | and uboot.env should be set up tp load it from $snap_kernel/dtbs/ | 10:21 |
| mvo | ogra: cool | 10:21 |
| ogra | only the pi differs | 10:21 |
| ogra | (and some of my dev images where i pull dtbs from linux-next explicitly into the gadget) | 10:22 |
| mvo | 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 |
| mvo | ogra: ok | 10:22 |
| mvo | ogra: that sounds all good, thanks for checking | 10:23 |
| ogra | mvo, ppisati also, ondra is usually surrounded by dragonboards and clones if you need a tester ;) | 10:23 |
| ackk | Chipaca, has $HOME always been set to $SNAP_USER_DATA? | 10:24 |
| Chipaca | ackk: yes | 10:24 |
| ogra | not in 15.04 :P | 10:24 |
| Chipaca | I'm wishing we had a way to say 'no thanks' | 10:24 |
| Chipaca | ogra: yes in 15.04 | 10:24 |
| Chipaca | AFAIR at least | 10:24 |
| ogra | (there the variable was called differently :P ) | 10:24 |
| Chipaca | HOME was set to SNAPPY_USER_DATA_WITH_POTATOES_AND_A_SIDE_OF_WTF | 10:25 |
| ogra | yeah | 10:25 |
| * Chipaca tickles ogra | 10:25 | |
| ogra | a hilariously long name | 10:25 |
| * ogra laughs | 10:25 | |
| Chipaca | to be clear, we've been setting HOME to a-per-revision-place-the-snap-can-write-to since before snapd existed | 10:26 |
| Chipaca | it's just not been called SNAP_USER_DATA all the time | 10:26 |
| ogra | yup | 10:26 |
| Chipaca | it used to be $SNAP_APP_USER_DATA_PATH | 10:26 |
| ogra | and before that s/SNAP/SNAPPY/ | 10:27 |
| ogra | but that was early on | 10:27 |
| ackk | 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 |
| ogra | unless it is a daemon or run by root, yes | 10:29 |
| Chipaca | ackk: what I do in an app where I need to write to the user's home dir, is getent | 10:30 |
| ackk | Chipaca, ah, I see | 10:30 |
| Chipaca | ackk: https://github.com/chipaca/icdiff/blob/master/snap/snapcraft.yaml#L73 | 10:30 |
| Chipaca | export HOME=$(perl -we "print((getpwuid $>)[7])") | 10:30 |
| ogra | hah | 10:30 |
| ogra | perl | 10:31 |
| * Chipaca whistles innocently | 10:31 | |
| pedronis | mvo: when you have time, what's the status of #6594 ? | 10:33 |
| mup | PR #6594: [RFC] tests: run smoke tests on (almost) pristine systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/6594> | 10:33 |
| ogra | HOME="$(getent passwd $USER | cut -d: -f6)" | 10:33 |
| ogra | (for a shell variant) | 10:33 |
| Chipaca | 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 |
| Chipaca | pedronis: wdyt? | 10:34 |
| pedronis | Chipaca: about what? | 10:35 |
| Chipaca | pedronis: having a way of telling snapd not to rewrite HOME | 10:36 |
| Chipaca | per app | 10:36 |
| === chihchun_afk is now known as chihchun | ||
| pedronis | Chipaca: in the snap(craft).yaml ? | 10:36 |
| Chipaca | pedronis: because when your app needs to honestly access the user's home, currently you need to look it up | 10:36 |
| Chipaca | pedronis: yea | 10:36 |
| Chipaca | example is icdiff's git-icdiff app, which needs to read ~/.gitconfig | 10:37 |
| Chipaca | and ~/.config/git/config | 10:37 |
| pedronis | Chipaca: why did we go with the current approach? should it be tied to having a home plug? | 10:37 |
| pedronis | setting the flag but not having the home plug will not do any good | 10:37 |
| Chipaca | pedronis: current approach is because a lot of legacy apps just work if you point home to someplace they can write | 10:37 |
| Chipaca | pedronis: an app could have a personal-files without having home though | 10:38 |
| Chipaca | but maybe personal-files and home are the only two cases | 10:38 |
| mvo | 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 | |
| mvo | ogra: if ondra could test this kernel update, that would be great (cc ppisati) | 10:40 |
| pedronis | 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:40 |
| mvo | pedronis: we can chat so that you don't need to do the digging yourself and then we can chat again | 10:41 |
| mvo | pedronis: but either way is fine | 10:41 |
| mvo | pedronis: its not urgent its just something that nags me | 10:41 |
| pedronis | mvo: let's try to progress a bit on remodel stuff first | 10:43 |
| pedronis | 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 |
| Chipaca | be-all-the-home-you-can-be: <integer> | 10:44 |
| Chipaca | if it's 42, don't overwrite HOME | 10:45 |
| Chipaca | \o/ | 10:45 |
| pedronis | Chipaca: :) | 10:45 |
| * Chipaca reaches consensus and moves on to implement | 10:45 | |
| pedronis | Chipaca: also will people learn about this | 10:45 |
| Chipaca | pedronis: maybe in the forum we should poke popey/wimpress/bad-jokes-igor | 10:46 |
| pedronis | Chipaca: unrelated, what is scope in search? I forgot it seems or never knew | 10:48 |
| Chipaca | pedronis: scope=wide → cross-channel | 10:48 |
| pedronis | ah | 10:48 |
| pedronis | I had forgotten | 10:49 |
| Chipaca | pedronis: snap find --narrow → not wide | 10:49 |
| pedronis | 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 |
| pedronis | Chipaca: anyway while doing that I noticed that this comment seems reversed: https://github.com/snapcore/snapd/blob/master/store/store.go#L1127 | 10:52 |
| pedronis | Chipaca: it's all common-id fault | 10:53 |
| Chipaca | pedronis: I don't think so | 10:53 |
| pedronis | Chipaca: should that comment say public? | 10:53 |
| Chipaca | 1 sec | 10:53 |
| pedronis | it seems if you mix Prefix and Private it fails | 10:54 |
| Chipaca | pedronis: right, you can only do fuzzy search of private | 10:55 |
| Chipaca | pedronis: that is, you can't do name=foo private=true | 10:55 |
| pedronis | ??? | 10:55 |
| pedronis | I'm totally confused | 10:55 |
| Chipaca | 1 sec | 10:56 |
| pedronis | is "name" fuzzy search? is q fuzzy search? | 10:56 |
| Chipaca | pedronis: q is fuzzy | 10:59 |
| Wimpress | Chipaca pedronis What was this regarding? | 10:59 |
| Chipaca | pedronis: name is prefix | 10:59 |
| Wimpress | $HOME? | 10:59 |
| Chipaca | Wimpress: having a way to say 'this app needs the real $HOME, not $SNAP_POTATOES' | 10:59 |
| Wimpress | Interesting. | 10:59 |
| Chipaca | Wimpress: i'll write a topic later | 10:59 |
| Wimpress | Excellent! | 11:00 |
| Chipaca | so we can hash it out if-n-when | 11:00 |
| Chipaca | pedronis: I was trying to show you an easy example, but searching private snaps with names=... is hard :-) | 11:00 |
| pedronis | Chipaca: anyway maybe that comment should say "cannot do private prefix searches" | 11:01 |
| pedronis | or maybe is just me | 11:01 |
| Chipaca | pedronis: it's never just you | 11:01 |
| Chipaca | pedronis: you're one in a million, meaning there's seven thousand of you | 11:01 |
| Chipaca | :-p | 11:02 |
| pedronis | :) | 11:02 |
| pedronis | Chipaca: related to the other nitpicking thought, I wonder if the struct(s) shouldn't look like: https://pastebin.ubuntu.com/p/cYbTtB7fjX/ | 11:11 |
| Chipaca | zyga: did you see https://github.com/snapcore/snapd/pull/6614#pullrequestreview-219370705 ? | 11:14 |
| mup | PR #6614: cmd/snap-confine: use fixed private tmp directory <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6614> | 11:15 |
| zyga | Chipaca: looking | 11:16 |
| zyga | Chipaca: no, I haven't | 11:16 |
| zyga | interesting | 11:16 |
| zyga | neat | 11:20 |
| pedronis | 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 |
| zyga | suse folks are going through the patches I've sent | 11:20 |
| pedronis | Chipaca: heh, s/great/green/ | 11:20 |
| Chipaca | pedronis: ack | 11:20 |
| degville | 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 |
| Chipaca | degville: i'll look in a few | 11:23 |
| degville | thanks! | 11:23 |
| mvo | Chipaca: everybody wants a piece of you today :) | 11:24 |
| Chipaca | mvo: it's my fault for being awesome | 11:24 |
| mvo | Chipaca: it totally is! | 11:24 |
| mvo | Chipaca: also see /msg :) | 11:24 |
| * Chipaca hopes mvo didn't have a mouthful of tea just tehre | 11:25 | |
| === chihchun is now known as chihchun_afk | ||
| mvo | Chipaca: haha | 11:25 |
| === mborzeck1 is now known as mborzecki | ||
| mup | PR snapd#6655 opened: timings: SetTag and SetTagFromChange helpers <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6655> | 11:36 |
| cachio | mvo, hey | 11:38 |
| ogra | ogra@anubis:~$ hello-world.sh | 11:46 |
| ogra | SNAP_INSTANCE_NAME is not set | 11:46 |
| ogra | hmm, whats that ? | 11:46 |
| ogra | did we break the hello-world snap ? | 11:47 |
| cachio | niemeyer, the https://github.com/snapcore/spread/pull/75 is updated, could you please take a look? thanks | 11:47 |
| mup | PR spread#75: Make spread tests for spread project run on google backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/75> | 11:47 |
| mborzecki | ogra: seems to work fine here | 11:50 |
| pstolowski | ogra: works here; what versions do you have? | 11:50 |
| ogra | yeah, weird, works fine on my arm boards too | 11:50 |
| ogra | ogra@anubis:~$ snap list hello-world | 11:50 |
| ogra | Name Version Rev Tracking Publisher Notes | 11:51 |
| ogra | hello-world 6.3 27 stable canonical✓ - | 11:51 |
| ogra | latest stable it seems | 11:51 |
| pstolowski | snap version? | 11:51 |
| ogra | ogra@anubis:~$ snap version | 11:51 |
| ogra | snap 2.37.4 | 11:51 |
| ogra | snapd 2.37.4 | 11:51 |
| ogra | series 16 | 11:51 |
| ogra | ubuntu 16.04 | 11:51 |
| ogra | kernel 4.4.0-141-generic | 11:51 |
| zyga | ogra: is that an ancient instalation | 11:52 |
| zyga | ogra: and hello-world.sh is using the /snap/bin/hello-world.sh shell script? | 11:52 |
| ogra | ogra@anubis:~$ /snap/bin/hello-world.sh | 11:52 |
| ogra | SNAP_INSTANCE_NAME is not set | 11:52 |
| ogra | ogra@anubis:~$ | 11:52 |
| mvo | hey cachio - sorry for the delay, was in a call | 11:52 |
| zyga | ogra: which hello-world.sh | 11:53 |
| ogra | ogra@anubis:~$ which hello-world.sh | 11:53 |
| ogra | bah | 11:53 |
| ogra | ogra@anubis:~$ which hello-world.sh | 11:53 |
| ogra | /snap/bin/hello-world.sh | 11:53 |
| ogra | IRC and slashes ... pfft | 11:54 |
| Chipaca | ogra: snap run --shell hello-world | 11:55 |
| Chipaca | ogra: printenv | grep SNAP | sort | 11:55 |
| Chipaca | ogra: please | 11:55 |
| ogra | https://paste.ubuntu.com/p/CwwHxvqJm7/ | 11:56 |
| ogra | obviously has that var | 11:56 |
| cachio | mvo, no problem | 11:57 |
| cachio | mvo, about core18 | 11:57 |
| cachio | there are several problems with the beta validation | 11:58 |
| cachio | mvo, but most important ones | 11:58 |
| cachio | the core18/snapd-refresh test fails on all the architectures | 11:58 |
| Chipaca | ogra: the 'SNAP_INSTANCE_NAME is not set' error comes from snap-confine | 11:59 |
| cachio | ansd it is because after the revert, the test reboots and when it happens we loose the network configuration on the device | 11:59 |
| zyga | Chipaca: I know | 11:59 |
| Chipaca | ogra: do you have a wonky snap-confine :-) | 11:59 |
| cachio | mvo, basically, the board has ip: 127.0.0.1 | 11:59 |
| cachio | and not way to contact it | 12:00 |
| zyga | Chipaca: but remember how we used to generate launcher scripts | 12:00 |
| zyga | those would set SNAP_NAME | 12:00 |
| zyga | Chipaca: that would be one way of having this issue | 12:00 |
| ogra | Chipaca, dunno, my other snaps seem to work (i'm obviously typing here ... hexchat is from the snap) | 12:00 |
| zyga | ogra: is /snap/bin/hello-world.sh a symlink or a script? | 12:00 |
| cachio | mvo, then I see a similar behaviour | 12:00 |
| mvo | cachio: oh, nasty | 12:00 |
| Chipaca | ogra: ls -l `which hello-world.sh` | 12:00 |
| cachio | mvo, installed the stable and tried to refresh with the core from bet | 12:00 |
| cachio | a | 12:00 |
| ogra | Chipaca, zyga, aha ! its a script !!! | 12:01 |
| cachio | and it fails | 12:01 |
| Chipaca | ogra: you installed hello-world in 1674 | 12:01 |
| mvo | cachio: what is the error message? | 12:01 |
| Chipaca | ogra: :-) | 12:01 |
| zyga | ogra: hahaha | 12:01 |
| zyga | ogra: can you can the script here | 12:01 |
| cachio | mvo, the same, network is list | 12:01 |
| * zyga was right :) | 12:01 | |
| cachio | lost | 12:01 |
| ogra | i installed it whenever ... but yeah, its oooold | 12:01 |
| mvo | cachio: it fails because there is no network anymore? | 12:01 |
| * zyga high-fives | 12:01 | |
| zyga | ogra: I can add a workaround | 12:01 |
| cachio | mvo, mvo yes | 12:01 |
| mvo | cachio: woah | 12:02 |
| zyga | but it would be best if snapd rewrote those things | 12:02 |
| ogra | https://paste.ubuntu.com/p/twdYDGmGk6/ | 12:02 |
| cachio | mvo, in the logs I don't see nothing about errors | 12:02 |
| mvo | cachio: this is on our pc-amd64, right? no network-manager snap or anything like this | 12:02 |
| cachio | also in the chnage everything is ok | 12:02 |
| Chipaca | ogra: snap disable hello-world && snap enable hello-world | 12:02 |
| cachio | mvo, yes | 12:02 |
| ogra | i can just re-move/re-install it, just wondering if there should be an automatic transition | 12:02 |
| Chipaca | not without epochs | 12:03 |
| ogra | ah | 12:03 |
| Chipaca | bah, epochs + revert not reverting to an incompat epoch | 12:03 |
| ogra | Chipaca, thanks, that works | 12:03 |
| mvo | cachio: that is surprising, can you please pastebin the output "snap change <fail-change-id>" and the journalctl output after the refresh failed? but it sounds like I need to try to reproduce this myself ./ | 12:03 |
| cachio | mvo, the good part is that is really easy to reproduce | 12:04 |
| cachio | mvo, just create a vm with the stable image | 12:04 |
| cachio | and refresh core18 | 12:04 |
| cachio | that's it | 12:04 |
| cachio | mvo, I'll give you that info in few minutes | 12:06 |
| cachio | I need to recreate the vm | 12:06 |
| pedronis | Chipaca: #6635 is green | 12:07 |
| mup | PR #6635: client, daemon, store: search by common-id <Created by chipaca> <https://github.com/snapcore/snapd/pull/6635> | 12:07 |
| Chipaca | pedronis: yes. Was wondering whether i should reorder te structs now | 12:07 |
| Chipaca | or just land it and forget about it :-) | 12:07 |
| pedronis | Chipaca: first of all, does that struct restructuring make sense to you as well? | 12:08 |
| Chipaca | pedronis: I like it | 12:08 |
| Chipaca | pedronis: even if it wastes a few bytes :-p | 12:08 |
| Chipaca | (this is not a thing we'd hold hundreds of :) ) | 12:08 |
| pedronis | Chipaca: anyway at this point a follow up is fine | 12:09 |
| pedronis | I'm also double checking something anyway | 12:09 |
| Chipaca | pedronis: double-checking what? | 12:09 |
| pedronis | Chipaca: I wonder if it's true that you cannot mix prefix and private | 12:13 |
| Chipaca | pedronis: easy enough to check | 12:13 |
| Chipaca | gimme a mo' | 12:13 |
| pedronis | Chipaca: I mean I'm sure it was true at some point | 12:13 |
| Chipaca | huh, this is new | 12:14 |
| Chipaca | cannot run daemon: cannot obtain snap-seccomp version information: error: unsupported argument "version-info" | 12:14 |
| niemeyer | cachio: Thanks, will do | 12:15 |
| zyga | Chipaca: that's the new snap-seccomp work from maciej | 12:15 |
| zyga | mborzecki: ^ we run the wrong snap-seccomp? | 12:15 |
| mborzecki | hmmm | 12:16 |
| Chipaca | no probs | 12:16 |
| Chipaca | i just compiled snap-seccomp and dropped it in as well | 12:16 |
| mborzecki | we shouldn't be, it's at the same location as currently executed snapd | 12:16 |
| mborzecki | Chipaca: ah, yes, if it's like a custom build you'll need to drop the updated snap-seccomp too | 12:17 |
| Chipaca | pedronis: it is not true that private + name don't mix, in the store | 12:17 |
| Chipaca | mborzecki: will the new snap-seccomp work with the old snapd? | 12:17 |
| zyga | Chipaca: ahh | 12:17 |
| Chipaca | pedronis: IOW we can drop the restriction, if it's a promise | 12:17 |
| mborzecki | Chipaca: yes, it's just a new command line switch that's added, nothign was removed | 12:17 |
| zyga | Chipaca: try make hack | 12:17 |
| zyga | it's good for things like that | 12:17 |
| Chipaca | every time I try 'make hack' i need to then manually remove a bunch of gromf from cmd/ | 12:18 |
| pedronis | Chipaca: do you remember if we decide that snapd side? my theory it was some restriction from the old elasticsearch backend | 12:18 |
| pedronis | Chipaca: I would drop it, but double check with cprov first | 12:18 |
| pedronis | *decided | 12:18 |
| Chipaca | pedronis: it's from elasto-search days ,yes | 12:19 |
| pedronis | Chipaca: anyway that's also why the comment confused me, it's a weird restriction, if had to have a restriction at all, not allowing query but only allowing exact or prefix for private would make more sense | 12:20 |
| mup | PR snapd#6635 closed: client, daemon, store: search by common-id <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6635> | 12:21 |
| cachio | mvo, https://paste.ubuntu.com/p/dcv8YmFVn2/ | 12:33 |
| cachio | mvo, this is about the changes | 12:33 |
| cachio | I installed stable image and refresh core18 to beta | 12:33 |
| cachio | mvo, log https://paste.ubuntu.com/p/rZh668v8FK/ | 12:34 |
| cachio | mvo, dmesg ourput https://paste.ubuntu.com/p/syvtCK48nN/ | 12:37 |
| === ricab is now known as ricab|lunch | ||
| mvo | cachio: thank you | 12:57 |
| mvo | cachio: out of curiosity, if you restart snapd manually does it have network again? does the entire system is without network or just snapd? | 12:57 |
| joc | cachio: I've just hit the problem you're describing on a device I was testing, network failing to come up | 12:57 |
| pedronis | Chipaca: so sounds we can drop that restriction to simplify that code a bit and do the change to struct(s) | 13:01 |
| pedronis | Chipaca: when you have a moment | 13:01 |
| cachio | mvo, no | 13:01 |
| Chipaca | pedronis: card material? | 13:02 |
| cachio | joc, using core18? | 13:02 |
| pedronis | Chipaca: yessish | 13:02 |
| pedronis | Chipaca: especially if you cannot do it very soon | 13:02 |
| joc | cachio: yes, flashed this morning with 20190327 image | 13:02 |
| cachio | joc, nice, and you refresh the core18 snap? | 13:03 |
| joc | cachio: i dont think i manually requested a refresh at any point | 13:04 |
| Chipaca | pedronis: I could do it right now, but i probably shouldn't :-) | 13:04 |
| cachio | mvo, the whole systems is without network | 13:04 |
| cachio | mvo, ping: google.com: Temporary failure in name resolution | 13:04 |
| mup | PR snapcraft#2517 opened: project: ensure yaml load returns a dictionary <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2517> | 13:12 |
| cachio | joc, in that case, autorefresh happened | 13:20 |
| cachio | joc, this is weird because autorefresh should refresh to stable | 13:20 |
| cachio | joc, do you have access to this board/machine? | 13:21 |
| joc | cachio: do you happen to know easiest way to get back in to this device without network? | 13:21 |
| cachio | joc, serial? | 13:21 |
| cachio | joc, which device is it? | 13:21 |
| joc | cachio: its a thin client pc on my desk so i have physical access | 13:22 |
| joc | is serial console on by default? | 13:22 |
| cachio | joc, but is it core18 systems? | 13:23 |
| cachio | or it is bionic? | 13:23 |
| joc | cachio: core18 | 13:24 |
| mvo | cachio: ta - in a meeting right now, but will look at it after that | 13:25 |
| mvo | cachio: super strange that the network goes down :( | 13:25 |
| cachio | so, and you didnt create a user right? | 13:25 |
| cachio | joc, you just have the one that you used by ssh? | 13:26 |
| joc | cachio: exactly | 13:26 |
| cachio | joc, in that case I don't know | 13:26 |
| cachio | joc, I use to creata another user with pass to be able to connect through the console | 13:27 |
| zyga | Chipaca: what kind of stuff do you have to remove? | 13:27 |
| Chipaca | zyga: barnacles | 13:28 |
| zyga | ? | 13:28 |
| roadmr | https://en.wikipedia.org/wiki/Barnacle | 13:34 |
| Chipaca | pedronis: in health checks, is 'unknown' only when the hook isn't there, or also when it errors out? | 13:48 |
| Chipaca | e.g. if the user does 'snapctl set-health --code=123 blocked', which will fail, is that `unknown`? or is it `error`? | 13:49 |
| mup | PR snapd#6631 closed: tests: split travis spread execution in 2 jobs for ubuntu and non ubuntu systems <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6631> | 13:51 |
| pedronis | Chipaca: so juju charm cannot set error by themselves, but here we allow that | 13:55 |
| pedronis | Chipaca: I would be conservative, if the hook errors/doesn't set the snap we don't really know if the snap overall is healthy or not | 13:56 |
| pedronis | s/the snap/the health status/ | 13:56 |
| pedronis | Chipaca: the question is a bit, would we rollback a snap that has a failing health hook? | 13:58 |
| Chipaca | i would not | 13:59 |
| Chipaca | pedronis: hook errors / doesn't set the snap -> health is unknown | 13:59 |
| Chipaca | pedronis: do we list unknown in notes? only if it's not 'no hook'? | 13:59 |
| pedronis | Chipaca: yea, so we can start with unknown, otherwise we would need to use error with one of the reserved snapd codes | 14:00 |
| pedronis | which we can got to later | 14:00 |
| pedronis | s/got/go/ | 14:00 |
| pedronis | Chipaca: you mean in snap list? | 14:01 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === ricab|lunch is now known as ricab | ||
| mup | PR snapd#6656 opened: tests: split travis spread execution in 2 jobs for ubuntu and non ubuntu systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6656> | 14:27 |
| zyga | cachio: I found a fix for the zypper issue | 14:49 |
| zyga | cachio: --force-resolution | 14:49 |
| cachio | zyga, nice, I'll try that now | 14:50 |
| cachio | thanks | 14:50 |
| mborzecki | zyga: multipass doesn't work too well on arch now :/ | 15:14 |
| zyga | mborzecki: what's wrong? | 15:14 |
| zyga | I had to chmod the socket | 15:14 |
| zyga | but other than that it worked ok | 15:14 |
| zyga | (on tumbleweed) | 15:14 |
| mborzecki | zyga: https://paste.ubuntu.com/p/3yQZXXWm3c/ | 15:14 |
| mborzecki | maybe i'm missing some local libs | 15:15 |
| zyga | wow | 15:15 |
| zyga | multipass is classic | 15:15 |
| zyga | so probably badly linked? | 15:15 |
| zyga | ldd? | 15:15 |
| zyga | and report to Saviq :) | 15:15 |
| Saviq | mborzecki, zyga: yes, we know, https → http, sorry guys | 15:23 |
| mborzecki | ok | 15:24 |
| mborzecki | Saviq: thanks! | 15:24 |
| mborzecki | Saviq: do you know which dep i'm missing locally? | 15:24 |
| Saviq | mborzecki: it's about it being incompatible, not missing, I'm afraid | 15:28 |
| Saviq | classic snaps... | 15:29 |
| Saviq | we'll soon be rid of that ;) | 15:29 |
| mvo | cachio: so for some reason "systemd-networkd" service is dead after the uc18 refresh, its totally unclear why, manually starting it brings network back | 15:29 |
| mup | Bug #1821944 opened: Chromium is unable to start after todays snapd upgrade 1.37.4ubuntu0.1 with 'mkdir: cannot create directory '/run/user/0': Permission denied' <chromium> <directory> <permission> <update> <Snappy:New> <https://launchpad.net/bugs/1821944> | 15:32 |
| cachio | mvo, nice | 15:34 |
| cachio | mvo, I saw the same here | 15:34 |
| cachio | could be related to the systemd change? | 15:34 |
| ondra | mvo ppisati sorry I was with client, what dragonboard do you want to test kernel on? db410c? | 15:35 |
| ondra | and what kernel, 4.15? | 15:35 |
| ogra | ondra, check your mail | 15:35 |
| cachio | zyga, work much better with force-resolution | 15:36 |
| cachio | mvo, thanks for digging | 15:37 |
| * cachio lunch | 15:37 | |
| zyga | cachio: +1, please propose that | 15:51 |
| Chipaca | degville: does the table i created make any sense to you? | 15:54 |
| mborzecki | zyga: some trouble with 6410 on my machine | 15:56 |
| degville | Chipaca: yes, it does. Thank you for doing it! I do think it makes things much clearer by being explicit about what happens, though we may have to hide/fold it so as to not scare too many readers away. | 15:57 |
| Chipaca | https://bugs.launchpad.net/snappy/+bug/1821944 seems bad | 15:57 |
| mup | Bug #1821944: Chromium is unable to start after todays snapd upgrade 1.37.4ubuntu0.1 with 'mkdir: cannot create directory '/run/user/0': Permission denied' <chromium> <directory> <permission> <update> <Snappy:New> <https://launchpad.net/bugs/1821944> | 15:57 |
| cachio | zyga, doesn't work well with tumbleweed https://travis-ci.org/snapcore/spread-cron/builds/510954310#L1952 | 16:03 |
| pedronis | jdstrand: hi, does this ring any bells https://bugs.launchpad.net/snappy/+bug/1821944 ? | 16:04 |
| mup | Bug #1821944: Chromium is unable to start after todays snapd upgrade 1.37.4ubuntu0.1 with 'mkdir: cannot create directory '/run/user/0': Permission denied' <chromium> <directory> <permission> <update> <Snappy:New> <https://launchpad.net/bugs/1821944> | 16:04 |
| mborzecki | cachio: zyga: shouldn't that job be using zypper dup? | 16:04 |
| Chipaca | degville: in that table, is it clear that after the first install the next rows are what happens on refresh? | 16:05 |
| cachio | makes update and then dup | 16:05 |
| cachio | mborzecki, | 16:05 |
| zyga | cachio: update is dup but weaker | 16:07 |
| zyga | it should du dup | 16:07 |
| zyga | just do dup :) | 16:07 |
| mborzecki | du dup | 16:07 |
| cachio | ok | 16:07 |
| * zyga needs to run now | 16:07 | |
| cachio | ehhee | 16:07 |
| cachio | zyga, mborzecki I'll try dup and if it works i'll push to snapd too | 16:08 |
| ondra | mvo ppisati 4.15 test kernel snap booting fine on DB410 device | 16:22 |
| ondra | mvo ppisati for more rigorous testing we would need cwayne's team's run, for which i can share test image | 16:23 |
| cwayne | ondra: core? | 16:24 |
| ondra | cwayne yep | 16:25 |
| degville | Chipaca: yes, I think so. I've tweaked the intro sentence slightly. | 16:25 |
| cwayne | ondra: link me and we'll kick some off | 16:25 |
| ondra | cwayne ah but I have image for emmc and you guys test sdcard, right? | 16:26 |
| Chipaca | degville: ta | 16:26 |
| Chipaca | degville: good for a pedronis read i think | 16:26 |
| cwayne | ondra: yea | 16:26 |
| degville | Chipaca: Yep! | 16:26 |
| ondra | cwayne for sdcard it's almost easier you build it yourself | 16:27 |
| pedronis | Chipaca: degville: I made some comments, suggestions | 16:48 |
| degville | pedronis: thank you! | 16:48 |
| Chipaca | pedronis: lgtm :-) | 16:49 |
| cwayne | ondra: what if I pay you in beer to build it for me | 16:49 |
| pedronis | degville: Chipaca: the table needs a bit more intro, maybe just me but it took me a bit to parse it (maybe because two column have the same header but are different timelines) | 16:51 |
| degville | pedronis: yeah, I completely see what you mean. Trying to tweak it now. | 16:52 |
| pedronis | Chipaca: I did another small suggestion | 16:58 |
| pedronis | degville: answered to your comments | 16:58 |
| ondra | cwayne in beer? How many images do you want? | 16:58 |
| degville | pedronis: great, thanks. | 16:59 |
| cwayne | ondra: 1? | 16:59 |
| ondra | cwayne and how many beers is that? | 17:03 |
| degville | Chipaca: are you ok with me moving the epoch gdoc over to the Discourse topic? We can obviously still make changes there. | 17:06 |
| Chipaca | degville: go for it | 17:06 |
| degville | coolio. | 17:06 |
| zyga | I just realized that not sleeping last night will ruin my the value of studying in the evening:/ | 17:07 |
| mup | PR snapd#6657 opened: tests: enable opensuse 15 and add force-resolution installing packages <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6657> | 17:07 |
| cachio | zyga, PR created | 17:08 |
| zyga | Reviewed | 17:08 |
| zyga | :-) | 17:08 |
| cachio | zyga, thanks :) | 17:08 |
| zyga | Pleasure | 17:09 |
| cwayne | ondra: 3 | 17:10 |
| cwayne | ondra: so this is just a core18 yeah? Since it's only 4.15? | 17:13 |
| ondra | cwayne nah you can do core16 with 4.15 | 17:13 |
| ondra | cwayne this is how I quickly tested here | 17:13 |
| ondra | cwayne http://people.canonical.com/~okubik/ubuntu-core-18-dragonboard-20190327-00.img.xz | 17:14 |
| ondra | cwayne 3 beers pls :P | 17:14 |
| cwayne | lol | 17:15 |
| ondra | cwayne I have not tested this one yet | 17:16 |
| cwayne | What could go wrong | 17:17 |
| zyga | https://forum.snapcraft.io/t/building-applications-for-both-snap-and-flatpak-at-once/10608 <- this | 17:21 |
| mvo | cachio: hey, I tried the following: created a stable image with "ubuntu-image ubuntu-18-amd64.signed", then ran "snap refresh --beta snapd" on that image. when doing that my network stayed up. | 17:43 |
| mvo | cachio: when you did this test you used the current released core18 image, is that correct? | 17:43 |
| mvo | cachio: I need to have dinner but I will keep poking at this, I'm not sure if it is snapd itself or something else causing this, I definitely see if when I upgrade from an older image (that was also using edge) | 17:44 |
| mvo | cachio: I think we need to gather more data | 17:44 |
| mvo | cachio: i.e. create a stable image then update things one by one and see what breaks network | 17:44 |
| cwayne | mvo: for us it was core18 | 17:49 |
| mvo | cwayne: oh, core18 - ok | 17:56 |
| mvo | cwayne: the one in beta | 17:56 |
| cwayne | Yep | 17:56 |
| pedronis | Chipaca: degville: thanks for the work on the epochs docs | 17:59 |
| degville | Chipaca: pedronis: no problem - thanks for your feedback. | 18:01 |
| mvo | cwayne, cachio, pedronis yeah, upgrading snapd in isolation seems to be fine. but upgrading core18 to current beta is not, this looses networking. one of the changes there is indeed systemd | 18:05 |
| jdstrand | pedronis: wrt https://bugs.launchpad.net/snappy/+bug/1821944; yes, this is an old bug where the snap is not allowed to create the parent dirs of XDG_RUNTIME_DIR. normally systemd creates that directory upon session login (eg /run/user/1000/...) but in this case tht command is run under sudo and thus XDG_RUNTIME_DIR is set to /run/user/0/snap...., and /run/user/0 doesn't exist | 18:08 |
| mup | Bug #1821944: Chromium is unable to start after todays snapd upgrade 1.37.4ubuntu0.1 with 'mkdir: cannot create directory '/run/user/0': Permission denied' <chromium> <directory> <permission> <update> <Snappy:New> <https://launchpad.net/bugs/1821944> | 18:08 |
| mup | Bug #1821959 opened: File name breaking go modules <Snappy:New> <https://launchpad.net/bugs/1821959> | 18:09 |
| jdstrand | pedronis: this is why the mir snap has a special rule to create that dir. I've long felt if systemd isn't going to do it, then snapd should | 18:09 |
| jdstrand | s/mir snap/mir interface/ | 18:09 |
| jdstrand | pedronis: there are forum topics and bugs on this | 18:09 |
| jdstrand | https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1751634, https://bugs.launchpad.net/snapd/+bug/1738197, https://bugs.launchpad.net/snappy/+bug/1656340 | 18:11 |
| mup | Bug #1751634: Unable to launch program (installed as snap) as root <apport-bug> <artful> <bionic> <xenial> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1751634> | 18:11 |
| mup | Bug #1738197: Daemons do not have an /run/user/* dir created <snapd:Fix Released> <https://launchpad.net/bugs/1738197> | 18:11 |
| mup | Bug #1656340: XDG_RUNTIME_DIR is not created on app startup <bionic> <cosmic> <eco-team> <xenial> <Snappy:Triaged by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1656340> | 18:11 |
| cwayne | mvo: sounds right | 18:11 |
| mvo | cwayne: ta | 18:12 |
| cachio | mvo, hey, so | 18:15 |
| cachio | mvo, what can I test to help | 18:16 |
| cachio | ? | 18:16 |
| mvo | cachio: if you could just double check my findings that would be great. so an update of snapd itself should be fine with the core18 r782. well, anything with core18 782 should be fine | 18:17 |
| mvo | cachio: but once core18 goes to beta/edge things go bad (no network) | 18:17 |
| cachio | mvo, sure | 18:18 |
| mvo | cachio: once we know its not snapd we are good for core | 18:18 |
| mvo | cachio: and then we need to figure out why core18 is busted :/ | 18:18 |
| mvo | cachio: might involve diff -uNr /snap/core18/782/etc /snap/core18/828/etc | 18:19 |
| mvo | cachio: anyway, some quesitons still :) | 18:19 |
| cachio | mvo, hice, I'll start digging | 18:19 |
| jdstrand | pedronis: there are also references to that topic in the forum | 18:25 |
| pedronis | jdstrand: yea, but then I read the bug closer, is not clear is about sudo, | 18:25 |
| pedronis | seems there's a core dump as well | 18:25 |
| jdstrand | pedronis: I've always asserted that if systemd isn't going to do it, snapd should because snapd is setting up the env var. there was a comment from jamesh somewhere (I can't find it in LP, the forum or github) where he had a differing opinion, but I can't remember what it was. I think he was fine about creating some dir that a snap could use, but didn't think /run/user/0 was correct cause it wasn't a | 18:27 |
| jdstrand | proper session. I can't recall the details | 18:27 |
| pedronis | jdstrand: yes, I don't see how that in particular would help, running sudo chromium is I suspect going to fail in other ways | 18:28 |
| jdstrand | pedronis: the only way I can think of that he'd get that denial is if he ran it under sudo, cause snapd is seeting XDG_RUNTIME_DIR to /run/user/0/... | 18:28 |
| pedronis | jdstrand: it says us much in the bug | 18:29 |
| jdstrand | pedronis: a snap not run with sudo trying to access /run/user/0 would be denied because /run/user is root:root 755 and /run/user/0, when created, would be 700 | 18:29 |
| jdstrand | pedronis: I asked for more info | 18:30 |
| pedronis | I asked the same :) | 18:32 |
| jdstrand | oh, heh | 18:32 |
| jdstrand | I'd love to see someone make a decision on snap-confine doing a mkdir /run/user/0 fwiw | 18:32 |
| jdstrand | unrelated to this bug | 18:33 |
| jdstrand | there is even commented out/ifdef'd out code to do it | 18:33 |
| pedronis | jdstrand: I thought we discussed it in Malta | 18:34 |
| pedronis | jdstrand: in the context of https://github.com/snapcore/snapd/pull/6327 | 18:39 |
| mup | PR #6327: Allowing sockets under /run/user/0/$SNAP_NAME <Created by kubiko> <https://github.com/snapcore/snapd/pull/6327> | 18:39 |
| cachio | mvo, is it any way to refresh the core18 to a specified revision? | 18:41 |
| jdstrand | pedronis: I read that PR and that is different from the point I am making today. we may havev discussed today's point in Malta, but idr an outcome (or that conversation). I do recall reading something from jameh on the subject recently-ish | 18:53 |
| jdstrand | jamesh evevn | 18:53 |
| jdstrand | pedronis: the question in that PR is the yaml declaration of specifying that path explicitly as /run/user/*0*/snap.foo.sock | 18:55 |
| cachio | mvo, updated to core18 rev 798 and worked fine | 18:56 |
| jdstrand | pedronis: my point in that PR is that ondra should instead use $XDG_RUNTIME_DIR/sock (or something) | 18:56 |
| cachio | mvo, trying now with 810 | 18:56 |
| jdstrand | pedronis: in this case, systemd should create all the parent dirs. so this is a different issue than what I describe as a problem | 18:56 |
| jdstrand | pedronis: which is trying to use XDG_RUNTIME_DIR as a root is broken because nothing is creating it | 18:57 |
| jdstrand | pedronis: the snap can create XDG_RUNTIME_DIR, but not dirname XDG_RUNTIME_DIR | 18:58 |
| jdstrand | anyway | 18:58 |
| jdstrand | the bugs describe the issue | 18:58 |
| pedronis | jdstrand: it sounds like we need a forum post to explain the use cases | 19:06 |
| cachio | mvo, http://people.canonical.com/~mvo/core18-changes/html/edge/unknownr818_unknownr821.html | 19:06 |
| pedronis | jdstrand: and your recommendation | 19:06 |
| cachio | mvo, I refresh from 818 to 821 and fails | 19:06 |
| cachio | mvo, I tested refresh to all the revisions from 782 | 19:07 |
| cachio | mvo, 782, 788, 791, 193, 798, 808, 810, 818, 821 | 19:07 |
| cachio | mvo, and with 821 fails | 19:08 |
| jdstrand | there is but one use case that is described by the open bug, https://bugs.launchpad.net/snappy/+bug/1656340 | 19:08 |
| cachio | and in the change log | 19:08 |
| jdstrand | pedronis: ^ | 19:08 |
| mup | Bug #1656340: XDG_RUNTIME_DIR is not created on app startup <bionic> <cosmic> <eco-team> <xenial> <Snappy:Triaged by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1656340> | 19:08 |
| cachio | mvo, we have something interesting | 19:08 |
| jdstrand | pedronis: if you prefer a forum post, I can do that | 19:08 |
| pedronis | jdstrand: yes, for this, I would prefer a forum post | 19:08 |
| jdstrand | pedronis: I have to focus on the 'daemon user' work item for the maas team so I'll add to my todo | 19:09 |
| pedronis | jdstrand: that's fine, to clear I just think it merits some trail and context, even if I will just end up agreeing | 19:10 |
| pedronis | *to be clear | 19:10 |
| pedronis | I feel I am a bit lacking context/full picture atm | 19:10 |
| jdstrand | pedronis: that's fine. the idea is simple but I suspect followups that require some discussion and archaeology that I'll want to have time for so will wait a bit | 19:11 |
| pedronis | jdstrand: it's ok, a daemon user is definitely a priority | 19:12 |
| jdstrand | pedronis: fyi, per joemcmanus, I'm going to be pretty heads down on this for the next little while. I'm mostly caught up on all store reviews (barring anything from last night) and PRs (a couple are in my inbox) | 19:13 |
| jdstrand | pedronis: if there is something that you feel is very urgent, please let me know and I can set the daemon user aside, otherwise I'm going to focus on that for a couple/few days | 19:14 |
| mvo | cachio: that is interessting - the change from 818->821 is glib and systemd | 19:23 |
| mvo | cachio: so that is very interessting | 19:23 |
| cachio | mvo, netplan too | 19:23 |
| mvo | cachio: ohhhhhhh | 19:24 |
| mvo | cachio: netplan sounds super suspicious | 19:24 |
| mvo | cachio: its also a huge update | 19:25 |
| mup | PR snapcraft#2518 opened: snapcraft/extractors/setuppy.py: match setuptools metadata keys <Created by anonymouse64> <https://github.com/snapcore/snapcraft/pull/2518> | 19:25 |
| cachio | mvo, .4 to 0.96 | 19:26 |
| mvo | cyphermox: hey, we noticed that on core18 with the current beta/edge snap we have no network anymore, we pinned it down to a systemd update or a netplan.io update. netplan.io in proposed is a big update so this looks we might want to dig into this a bit more | 19:27 |
| mvo | cyphermox: do you have any hints for us how to debug? | 19:27 |
| pedronis | jdstrand: that's fine, will you write something in the forum about the daemon user design, or is that capture in the old forum post? I remember Gustavo wanted to double check on it | 19:51 |
| jdstrand | pedronis: the old forum post is the complete design. this is I've affectionately called it, phase 0.25 of the design. there is no declaring in the snap yaml or anything. just simply, 'the security policy allows you to drop to/chown/chgrp etc to daemon user/group'. similar to now where we simply allow chown to root. the work I do will also add the implied rule of dropping to the SUDO_USER | 19:55 |
| jdstrand | pedronis: put another way, this is a way to expand security permissions to use the daemon user and group. you don't have to do anything special in the snap | 19:56 |
| jdstrand | pedronis: this is snap-seccomp work primarily | 19:56 |
| pedronis | jdstrand: I had the vague understanding that from how Gustavo talked about it, you would have to declare something in the snap | 19:56 |
| jdstrand | pedronis: actually, you are right, that is in the trello card | 19:58 |
| niemeyer | jdstrand: pedronis is correct.. we need to review the plan as the goal is to have users declared | 19:58 |
| jdstrand | I'm focusing only on the snap-seccomp bits for the moment since those are the hard bits | 19:58 |
| jdstrand | I can create that post after this low level work | 19:58 |
| niemeyer | jdstrand: We'll fake the underlying implementation, but we need to get the overall design right so that we can fake it properly on that initial phase, just for the daemon user | 19:59 |
| zyga | I am going home from classes | 19:59 |
| jdstrand | yes, that is in the card | 19:59 |
| niemeyer | zyga: o/ | 19:59 |
| zyga | I see the chat backlog is interesting | 19:59 |
| niemeyer | jdstrand: Cool, thanks for checking | 19:59 |
| zyga | I will read everything here | 19:59 |
| jdstrand | I forgot about that cause I knew I wanted to focus on seccomp first | 19:59 |
| jdstrand | anyway, that's all fine | 19:59 |
| cyphermox | mvo: I'd start by looking at whether there are files in /run/systemd/network | 20:06 |
| mvo | cyphermox: thanks, yes, there is a file 10-netplan-eth0.network which looks valid | 20:21 |
| mvo | cyphermox: but it looks like systemd-network (the service) is dead - does netplan fiddle with this one? | 20:22 |
| cyphermox | uh, yes, to enable it | 20:53 |
| cyphermox | making a link in /run/systemd/system/network-online.target.wants/systemd-networkd.service from the look of things | 20:54 |
| mvo | cyphermox: ha! I just found this and it seems like the pervious netplan did create the symlink in "multi-user.target.wants" | 20:56 |
| mvo | cyphermox: so it looks like on UC18 in beta network-online.target is also dead for some reason | 20:57 |
| mvo | cyphermox: so it looks like we don't configure this target on UC18 to be enabled, that would explain it, right? | 20:57 |
| cyphermox | oops, yeah that would explain it | 20:58 |
| mvo | cyphermox: silly question (forgive me, its late) - what should we do? should netplan go back to the old target? or should we in UC18 enable network-online.target? and if the later, are there any risks? | 20:59 |
| * cachio afk | 20:59 | |
| mvo | (and if the later, whats the easiest way to do that ?) | 20:59 |
| cyphermox | I don't know how this was handled in UC originally; I moved it to network-online when revising things to remove delays at booting with wifi on raspberry pis | 21:00 |
| cyphermox | let's see | 21:00 |
| cyphermox | AFAICT network-online is the more correct way to handle this; but I'm not certain what the risk is in changing this | 21:04 |
| cyphermox | mvo: you're getting this on bionic right now, right? | 21:06 |
| cyphermox | ie. UC18, so building from bionic, presumably with proposed enabled, otherwise you wouldn't have that change | 21:06 |
| mvo | cyphermox: yeah, this is UC18 | 21:07 |
| mvo | cyphermox: correct | 21:07 |
| mvo | cyphermox: these changes broke it http://people.canonical.com/~mvo/core18-changes/html/beta/unknownr818_unknownr821.html | 21:07 |
| mvo | cyphermox: well "broke" | 21:08 |
| mvo | cyphermox: its just in edge/beta for now | 21:08 |
| cyphermox | mvo: is network-online.target enabled? | 21:09 |
| mvo | cwayne: silly question, can we have some minimal gating for core18 edge->beta to prevent e.g. broken networking from entering beta? or is it too difficult? | 21:09 |
| mvo | cyphermox: it says "static; vendor present: enabled" | 21:09 |
| mvo | cyphermox: but also "Active: inactive (dead)" | 21:09 |
| cwayne | mvo: no reason we couldn't | 21:10 |
| mvo | cwayne: its not urgent but I think this issue here with core18 highlights that a minimum amount of checks (initially "do we have network") would be cool before we allow core18 from edge->beta (cc sil2100) | 21:11 |
| mvo | cyphermox: hm, this is a special target, let me try to figure out if I can enable this at all or if it is … well … special :) | 21:11 |
| mvo | cyphermox: or do you happen to know if/how to enable this? | 21:12 |
| cyphermox | as I recall nothing special need to be done to enable it | 21:12 |
| mvo | cyphermox: :/ it tells me "Active: inactive (dead)" | 21:12 |
| cwayne | mvo: yep, I think cachio already does some similar testing on our devices | 21:13 |
| cyphermox | mvo: check /etc/systemd/system; see if there's a symlink by that name there (network-online.target) | 21:13 |
| mvo | cyphermox: manually running "systemctl start network-online.target" makes things happy | 21:13 |
| cyphermox | that's not a permanent fix though | 21:13 |
| mvo | cyphermox: no symlink | 21:13 |
| cyphermox | AAUI it just gets run... | 21:14 |
| mvo | cyphermox: yeah, not a permanent fix for sure, just another data point | 21:14 |
| mvo | cwayne: thanks, we should sync on this later this week, would love to explore options | 21:14 |
| cwayne | mvo: absolutely | 21:15 |
| cyphermox | mvo: where can I get an image or this particular core snap? | 21:15 |
| mvo | cyphermox: aha - I'm just reading up on network-online.target (in man:systemd.special(7)) and it says here that network-online.target is only pulled in if a unit requires it | 21:16 |
| mvo | cyphermox: but this is a pretty empty system and nothing requires it | 21:16 |
| mvo | cyphermox: from reading the man-page maybe "network.target" might be a better option? | 21:16 |
| cyphermox | no; I'll just revert to what it was before | 21:17 |
| mvo | cachio, pedronis fwiw, it looks like the network issue on core18 is netplan.io related so I think we don't need to block the core snap promotion for uc16 | 21:17 |
| mvo | cyphermox: thats fine as well, thank you! | 21:17 |
| mvo | cyphermox: one last question (sorry for the flurry of questions) - will this revert happen soon or shall we (snapd team) patch netplan ourself in the UC18 edge ppa to unblock uc18 beta/edge snaps? | 21:22 |
| cyphermox | mvo: I need to upload to disco and make new revisions for the SRUs in progress; it can be in tomorrow | 21:23 |
| mvo | cyphermox: thats great, thank you | 21:24 |
| mvo | cyphermox: that time frame is totally fine | 21:24 |
| ondra | pedronis I agree with jdstrand that PR needs to be updated and use $XDG_RUNTIME_DIR instead, so we are not hardcoding path there. I just need to find time to update PR for this. I think if we use XDG_RUNTIME_DIR it needs change in two places, validation check and then using actual XDG_RUNTIME_DIR value when creating systemd socket definition | 22:11 |
| mup | PR snapcraft#2517 closed: project: ensure yaml load returns a dictionary <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2517> | 22:56 |
| Son_Goku | niemeyer, hey is the forum broken? | 23:48 |
| Son_Goku | it seems to time out for me | 23:48 |
| niemeyer | Son_Goku: Heya | 23:50 |
| niemeyer | Son_Goku: Seems okay from here | 23:50 |
| Son_Goku | well, I can't get it to load | 23:50 |
| Son_Goku | so I can't post about the snapd and snapd-glib updates :( | 23:50 |
| Son_Goku | F30: https://bodhi.fedoraproject.org/updates/FEDORA-2019-1a613fbede | 23:50 |
| Son_Goku | F29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-a93e7637d2 | 23:50 |
| Son_Goku | F28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2d75eaae81 | 23:50 |
| Son_Goku | EL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-be55f1a139 | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!