[06:10] <mborzecki> morning
[06:28] <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:33] <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:37] <mborzecki> zyga: uhh, sucks, make him fast a bit, always helps with my dog pack
[07:22] <zyga> back in the office
[07:41] <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:42] <mborzecki> almost there with selinux
[07:42] <mborzecki> just one more PR on top of what's already open
[07:49] <mborzecki> mvo: morning
[07:52] <mvo> hey mborzecki
[07:52] <mvo> mborzecki: how are you? how are the tests this morning?
[07:53] <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:55] <mvo> mborzecki: sounds great
[07:55] <mvo> mborzecki: doing that now
[07:57] <mborzecki> mvo: thanks!
[07:59] <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>
[08:02] <mvo> zyga: sure, looking
[08:02] <pstolowski> morning
[08:02] <zyga> hey pawel
[08:03] <mborzecki> pstolowski: hey
[08:11] <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:21] <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:26] <mvo> pedronis: looking
[08:39] <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:42] <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:47] <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:50] <zyga> pedronis: looking
[08:50] <zyga> ah, that's even easier
[08:50]  * zyga goes to do that now
[08:51] <zyga> sorry, today is not great, my dog is sick and makes all kinds of mess :/
[08:52] <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:53] <zyga> pedronis: I'm okay now, thank you!
[08:54] <pedronis> zyga: sorry for the poor dog
[09:00] <ppisati> mvo: does the dtb update mechanism work in core18 now?
[09:01] <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:02] <Chipaca> ackk: Recursivity.  Call back if it happens again.
[09:03]  * Chipaca puts away his BOFH excuse generator again
[09:03] <pedronis> pstolowski: hi, 6491  can be landed
[09:04] <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:05] <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:06] <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:07] <ackk> Chipaca, same error
[09:08] <ackk> Chipaca, does snapcraft need to run under sudo with --destructive-mode?
[09:09] <ackk> uhm, it seems so it's trying to do apt stuff
[09:10] <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:12] <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:14] <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:16] <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:20] <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:28] <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:36] <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:38] <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:39] <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:40] <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:41] <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:42] <pedronis> Chipaca: we could introduce snapctl set --configure  (it would need to error if called that way from inside the configure hook itself)
[09:43] <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:44] <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:45] <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:47] <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:48] <ackk> Chipaca, I don't think it should be allowed from a hook
[09:49] <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:50] <Chipaca> ackk: but 'snap set' kicks off a 'configure-snap' change
[09:51] <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:52] <Chipaca> pedronis: ye
[09:53] <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:54] <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:59] <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
[10:02] <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:03] <pedronis> thx
[10:08] <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:12] <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:13] <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:14]  * 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:15] <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:16] <Chipaca> degville: did that help?
[10:16] <degville> looking now.
[10:17] <degville> Chipaca: yes, thanks!
[10:17] <Chipaca> degville: it feels more stuttery now
[10:18] <Chipaca> zyga: ooh, ooh, post-merge reviews!
[10:18] <Chipaca> is that a song
[10:19] <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:20] <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:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:27] <ogra> and before that s/SNAP/SNAPPY/
[10:27] <ogra> but that was early on
[10:29] <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:30] <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:31] <ogra> perl
[10:31]  * Chipaca whistles innocently
[10:33] <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:34] <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:35] <pedronis> Chipaca: about what?
[10:36] <Chipaca> pedronis: having a way of telling snapd not to rewrite HOME
[10:36] <Chipaca> per app
[10:36] <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:37] <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:38] <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:40] <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:41] <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:43] <pedronis> mvo: let's try to progress a bit on remodel stuff first
[10:44] <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:45] <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:46] <Chipaca> pedronis: maybe in the forum we should poke popey/wimpress/bad-jokes-igor
[10:48] <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:49] <pedronis> I had forgotten
[10:49] <Chipaca> pedronis: snap find --narrow → not wide
[10:52] <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:53] <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:54] <pedronis> it seems if you mix Prefix and Private it fails
[10:55] <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:56] <Chipaca> 1 sec
[10:56] <pedronis> is "name" fuzzy search?  is q fuzzy search?
[10:59] <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
[11:00] <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:01] <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:02] <Chipaca> :-p
[11:02] <pedronis> :)
[11:11] <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:14] <Chipaca> zyga: did you see https://github.com/snapcore/snapd/pull/6614#pullrequestreview-219370705 ?
[11:15] <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:16] <zyga> Chipaca: looking
[11:16] <zyga> Chipaca: no, I haven't
[11:16] <zyga> interesting
[11:20] <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:23] <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:24] <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:25]  * Chipaca hopes mvo didn't have a mouthful of tea just tehre
[11:25] <mvo> Chipaca: haha
[11:36] <mup> PR snapd#6655 opened: timings: SetTag and SetTagFromChange helpers <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6655>
[11:38] <cachio> mvo, hey
[11:46] <ogra> ogra@anubis:~$ hello-world.sh
[11:46] <ogra> SNAP_INSTANCE_NAME is not set
[11:46] <ogra> hmm, whats that ?
[11:47] <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:50] <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:51] <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:52] <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:53] <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:54] <ogra> IRC and slashes ... pfft
[11:55] <Chipaca> ogra: snap run --shell hello-world
[11:55] <Chipaca> ogra: printenv | grep SNAP | sort
[11:55] <Chipaca> ogra: please
[11:56] <ogra> https://paste.ubuntu.com/p/CwwHxvqJm7/
[11:56] <ogra> obviously has that var
[11:57] <cachio> mvo, no problem
[11:57] <cachio> mvo, about core18
[11:58] <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:59] <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: <IP_ADDRESS>
[12:00] <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:01] <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:02] <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:03] <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:04] <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:06] <cachio> mvo, I'll give you that info in few minutes
[12:06] <cachio> I need to recreate the vm
[12:07] <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:08] <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:09] <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:13] <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:14] <Chipaca> huh, this is new
[12:14] <Chipaca> cannot run daemon: cannot obtain snap-seccomp version information: error: unsupported argument "version-info"
[12:15] <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:16] <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:17] <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:18] <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:19] <Chipaca> pedronis: it's from elasto-search days ,yes
[12:20] <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:21] <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:33] <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:34] <cachio> mvo, log https://paste.ubuntu.com/p/rZh668v8FK/
[12:37] <cachio> mvo, dmesg ourput https://paste.ubuntu.com/p/syvtCK48nN/
[12:57] <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
[13:01] <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:02] <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:03] <cachio> joc, nice, and you refresh the core18 snap?
[13:04] <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:12] <mup> PR snapcraft#2517 opened: project: ensure yaml load returns a dictionary <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2517>
[13:20] <cachio> joc, in that case, autorefresh happened
[13:20] <cachio> joc, this is weird because autorefresh should refresh to stable
[13:21] <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:22] <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:23] <cachio> joc, but is it core18 systems?
[13:23] <cachio> or it is bionic?
[13:24] <joc> cachio: core18
[13:25] <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:26] <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:27] <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:28] <Chipaca> zyga: barnacles
[13:28] <zyga> ?
[13:34] <roadmr> https://en.wikipedia.org/wiki/Barnacle
[13:48] <Chipaca> pedronis: in health checks, is 'unknown' only when the hook isn't there, or also when it errors out?
[13:49] <Chipaca> e.g. if the user does 'snapctl set-health --code=123 blocked', which will fail, is that `unknown`? or is it `error`?
[13:51] <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:55] <pedronis> Chipaca: so juju charm cannot set error by themselves, but here we allow that
[13:56] <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:58] <pedronis> Chipaca: the question is a bit, would we rollback a snap that has  a failing health hook?
[13:59] <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'?
[14:00] <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:01] <pedronis> Chipaca: you mean in snap list?
[14:27] <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:49] <zyga> cachio: I found a fix for the zypper issue
[14:49] <zyga> cachio: --force-resolution
[14:50] <cachio> zyga, nice, I'll try that now
[14:50] <cachio> thanks
[15:14] <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:15] <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:23] <Saviq> mborzecki, zyga: yes, we know, https → http, sorry guys
[15:24] <mborzecki> ok
[15:24] <mborzecki> Saviq: thanks!
[15:24] <mborzecki> Saviq: do you know which dep i'm missing locally?
[15:28] <Saviq> mborzecki: it's about it being incompatible, not missing, I'm afraid
[15:29] <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:32] <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:34] <cachio> mvo, nice
[15:34] <cachio> mvo, I saw the same here
[15:34] <cachio> could be related to the systemd change?
[15:35] <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:36] <cachio> zyga, work much better with force-resolution
[15:37] <cachio> mvo, thanks for digging
[15:37]  * cachio lunch
[15:51] <zyga> cachio: +1, please propose that
[15:54] <Chipaca> degville: does the table i created make any sense to you?
[15:56] <mborzecki> zyga: some trouble with 6410 on my machine
[15:57] <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>
[16:03] <cachio> zyga, doesn't work well with tumbleweed https://travis-ci.org/snapcore/spread-cron/builds/510954310#L1952
[16:04] <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:05] <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:07] <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:08] <cachio> zyga, mborzecki I'll try dup and if it works i'll push to snapd too
[16:22] <ondra> mvo ppisati 4.15 test kernel snap booting fine on DB410 device
[16:23] <ondra> mvo ppisati for more rigorous testing we would need cwayne's team's run, for which i can share test image
[16:24] <cwayne> ondra: core?
[16:25] <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:26] <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:27] <ondra> cwayne for sdcard it's almost easier you build it yourself
[16:48] <pedronis> Chipaca: degville: I made some comments, suggestions
[16:48] <degville> pedronis: thank you!
[16:49] <Chipaca> pedronis: lgtm :-)
[16:49] <cwayne> ondra: what if I pay you in beer to build it for me
[16:51] <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:52] <degville> pedronis: yeah, I completely see what you mean. Trying to tweak it now.
[16:58] <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:59] <degville> pedronis: great, thanks.
[16:59] <cwayne> ondra: 1?
[17:03] <ondra> cwayne and how many beers is that?
[17:06] <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:07] <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:08] <cachio> zyga, PR created
[17:08] <zyga> Reviewed
[17:08] <zyga> :-)
[17:08] <cachio> zyga, thanks :)
[17:09] <zyga> Pleasure
[17:10] <cwayne> ondra: 3
[17:13] <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:14] <ondra> cwayne http://people.canonical.com/~okubik/ubuntu-core-18-dragonboard-20190327-00.img.xz
[17:14] <ondra> cwayne 3 beers pls :P
[17:15] <cwayne> lol
[17:16] <ondra> cwayne I have not tested this one yet
[17:17] <cwayne> What could go wrong
[17:21] <zyga> https://forum.snapcraft.io/t/building-applications-for-both-snap-and-flatpak-at-once/10608 <- this
[17:43] <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:44] <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:49] <cwayne> mvo: for us it was core18
[17:56] <mvo> cwayne: oh, core18 - ok
[17:56] <mvo> cwayne: the one in beta
[17:56] <cwayne> Yep
[17:59] <pedronis> Chipaca: degville: thanks for the work on the epochs docs
[18:01] <degville> Chipaca: pedronis: no problem - thanks for your feedback.
[18:05] <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:08] <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:09] <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:11] <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:12] <mvo> cwayne: ta
[18:15] <cachio> mvo, hey, so
[18:16] <cachio> mvo, what can I test to help
[18:16] <cachio> ?
[18:17] <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:18] <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:19] <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:25] <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:27] <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:28] <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:29] <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:30] <jdstrand> pedronis: I asked for more info
[18:32] <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:33] <jdstrand> unrelated to this bug
[18:33] <jdstrand> there is even commented out/ifdef'd out code to do it
[18:34] <pedronis> jdstrand: I thought we discussed it in Malta
[18:39] <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:41] <cachio> mvo, is it any way to refresh the core18 to a specified revision?
[18:53] <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:55] <jdstrand> pedronis: the question in that PR is the yaml declaration of specifying that path explicitly as /run/user/*0*/snap.foo.sock
[18:56] <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:57] <jdstrand> pedronis: which is trying to use XDG_RUNTIME_DIR as a root is broken because nothing is creating it
[18:58] <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
[19:06] <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:07] <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:08] <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:09] <jdstrand> pedronis: I have to focus on the 'daemon user' work item for the maas team so I'll add to my todo
[19:10] <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:11] <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:12] <pedronis> jdstrand: it's ok,  a daemon user is definitely a priority
[19:13] <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:14] <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:23] <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:24] <mvo> cachio: ohhhhhhh
[19:24] <mvo> cachio: netplan sounds super suspicious
[19:25] <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:26] <cachio> mvo, .4 to 0.96
[19:27] <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:51] <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:55] <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:56] <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:58] <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:59] <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
[20:06] <cyphermox> mvo: I'd start by looking at whether there are files in /run/systemd/network
[20:21] <mvo> cyphermox: thanks, yes, there is a file 10-netplan-eth0.network which looks valid
[20:22] <mvo> cyphermox: but it looks like systemd-network (the service) is dead - does netplan fiddle with this one?
[20:53] <cyphermox> uh, yes, to enable it
[20:54] <cyphermox> making a link in /run/systemd/system/network-online.target.wants/systemd-networkd.service from the look of things
[20:56] <mvo> cyphermox: ha! I just found this and it seems like the pervious netplan did create the symlink in "multi-user.target.wants"
[20:57] <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:58] <cyphermox> oops, yeah that would explain it
[20:59] <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 ?)
[21:00] <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:04] <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:06] <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:07] <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:08] <mvo> cyphermox: well "broke"
[21:08] <mvo> cyphermox: its just in edge/beta for now
[21:09] <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:10] <cwayne> mvo: no reason we couldn't
[21:11] <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:12] <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:13] <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:14] <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:15] <cwayne> mvo: absolutely
[21:15] <cyphermox> mvo: where can I get an image or this particular core snap?
[21:16] <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:17] <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:22] <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:23] <cyphermox> mvo: I need to upload to disco and make new revisions for the SRUs in progress; it can be in tomorrow
[21:24] <mvo> cyphermox: thats great, thank you
[21:24] <mvo> cyphermox: that time frame is totally fine
[22:11] <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:56] <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>
[23:48] <Son_Goku> niemeyer, hey is the forum broken?
[23:48] <Son_Goku> it seems to time out for me
[23:50] <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:51] <Son_Goku> EL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-be55f1a139


[01:23] <StupidDanbo> I got it working. Thanks.
[01:24] <mup> PR snapd#10151 opened: wrappers/services.go: refactor helper lambda function to separate function <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10151>
[02:24] <mup> PR snapd#10152 opened:  quota: new package for managing resource groups  <Needs Samuele review> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10152>
[02:40] <mup> PR snapd#10153 opened: [RFC] wrappers, quota: implement quota groups slice generation <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10153>
[05:51] <mborzecki> morning
[07:01] <pstolowski> morning
[07:06] <mborzecki> pstolowski: hey
[07:30] <mborzecki> hmm hmm dropped console=ttyS0 from cmdline.full and spent a while wondering why my qemu serial is so silent
[07:35] <mup> PR snapd#10154 opened: cmd/snap, boot: add snapd_full_cmdline_args to dumped boot vars <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10154>
[07:39] <zyga> mborzecki uh oh
[07:40] <zyga> mborzecki approved
[08:21] <mborzecki> thx
[09:11] <mup> PR snapd#10151 closed: wrappers/services.go: refactor helper lambda function to separate function <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10151>
[09:16] <mup> PR snapd#10154 closed: cmd/snap, boot: add snapd_full_cmdline_args to dumped boot vars <Simple 😃> <Skip spread> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/10154>
[09:22] <ogra> zyga, omg, krakow is attacked by the french ?!?! https://www.todayonline.com/world/is-it-bird-is-it-iguana-no-its-croissant
[09:26] <mup> PR snapd#10155 opened: [RFC] o/snapstate: handle refresh hints <Refresh control> <Skip spread> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10155>
[09:32] <zyga> ogra I'm wearing a krakow t-shirt today ;-)
[09:32] <ogra> does it have a croissant on it ?
[09:32] <zyga> ogra only if we have some left upstairs
[09:33] <zyga> (I'm afraid not)
[09:35] <mborzecki> and runing a spread test with cmdline.full & secure boot
[09:46] <mborzecki> hm when running nested tests we compress the images using xz -k0 <image-path>
[09:46] <mborzecki> wonder if using bzip/gz/zstd would speed this up a bit
[09:47] <mborzecki> also when we repack the kernel snap, we use xz again, we could use zstd there right?
[09:48] <mborzecki> duh, s/zstd/lzo/ for the snap
[09:51] <mborzecki> huh, how is that possible? ` Mount snap "snapd" (11588) (snap is unusable due to missing files; contact developer)`
[09:51] <mvo> mborzecki: gzip is probably fastest
[09:51] <mvo> mborzecki: uh, I never saw this message
[09:51] <mborzecki> mvo: that's from Adio's log
[09:53] <mvo> mborzecki: there should be more details from snap.ValidateContainer for this error
[09:54] <mvo> mborzecki: I have a meeting in 5 unfortunately, what PR fails like this?
[09:55] <mborzecki> mvo: that's not from a PR
[09:56] <mborzecki> Adio: can you `snap changes` and paste the output to some pastebin?
[09:58] <mvo> mborzecki: aha, sorry, missed that because I joined late
[10:02] <mborzecki> Adio: can you collec the output of `snap tasks 6` ?
[10:03] <pstolowski> pedronis: hi, i've proposed #10155 for early feedback re the direction taken
[10:03] <mup> Bug #10155: System reboots after halt <linux-source-2.6.15 (Ubuntu):Fix Released by fabbione> <https://launchpad.net/bugs/10155>
[10:03] <mup> PR #10155: [RFC] o/snapstate: handle refresh hints <Refresh control> <Skip spread> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10155>
[10:04] <mborzecki> Adio: hm interesting, can you collect the journal? `sudo journalctl -u snapd --since 15:36`
[10:11] <mborzecki> thanks
[10:11] <mborzecki> Adio: does /snap/snapd exist in your system? if so what does /snap/snapd/current point to (`ls -l /snap/snapd` will show that)
[10:16] <pedronis> pstolowski: I'll try to look at it after lunch, I have few older PRs still in my review queue
[10:17] <pedronis> pstolowski: thanks
[10:17] <mborzecki> hm no clue what's happening, it's as if the snapd snap file is corrupted? but that would probably give a different error
[10:17] <pstolowski> pedronis: sure. as i said naming TBD, tests are missing and existing tests will fail atm
[10:29] <mborzecki> Adio: can you try running `snap install --beta snapd` ?
[10:29] <mborzecki> Adio: what system is it anwyay? what does `snap version` show?
[10:55] <mborzecki> Adio: hm probably something changed in unsquashfs, what's the old and the new version?
[11:23] <mborzecki> Adio: thanks, does the new version even work at all? can you try `unsquashfs -l /var/lib/snapd/snaps/snapd_<some-rev>.snap`?
[11:51] <mup> PR snapd#10156 opened: boot, bootloader, bootloader/assets: support for full command line override from gadget <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10156>
[11:56] <cachio_> mborzecki, hi
[11:56] <mborzecki> cachio_: hey
[11:56] <cachio_> any idea if this is a new error? https://github.com/snapcore/snapd/pull/10135#issuecomment-819955829
[11:56] <mup> PR #10135: tests/lib/nested: proper status return for tpm/secure boot checks <Run nested> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10135>
[11:57] <cachio_> it is failing because of memory problems
[11:57] <cachio_> this is the only test failing
[12:00] <mborzecki> cachio_: not really, that's the minimal test in https://github.com/snapcore/snapd/pull/10135 which means we were not executing that test with secure boot enabled, and maybe it jsut doesn't work with 384MB of ram
[12:00] <mup> PR #10135: tests/lib/nested: proper status return for tpm/secure boot checks <Run nested> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10135>
[12:00] <mborzecki> mvo: ^^ that's probably interesting to note too
[12:01] <mvo> mborzecki: in a meeting will have a look
[12:01] <mborzecki> let me add that to the standup notes so that we don't forget
[12:03] <cachio_> mborzecki, but we were not using secure boot during the last 20 days
[12:04] <cachio_> after we merged core and core20 suites
[12:04] <cachio_> before we were using it
[12:05] <cachio_> not sure if any change we did lastly could affect that test
[12:05] <mborzecki> cachio_: afaiu the change in 10135 and your last commit there, make it used by default now on ubuntu-20.04
[12:06] <cachio_> mborzecki, you are  right
[12:06] <cachio_> manual tests were not using sec boot
[12:07] <cachio_> mborzecki, should that test run with sec boot?
[12:07] <cachio_> or it is ok to run without?
[12:11] <cachio_> mborzecki, I can add environment:
[12:11] <cachio_>     NESTED_ENABLE_TPM: false
[12:11] <cachio_>     NESTED_ENABLE_SECURE_BOOT: false
[12:11] <cachio_> to the test
[12:11] <mborzecki> cachio_: that's a good question and the answer depends on what we promise ;), let's discuss it during the standup
[12:11] <cachio_> mborzecki, sure
[12:55] <pedronis> pstolowski: thanks for https://github.com/snapcore/snapd/pull/10155 , left a bunch of comments and some worries, let me know
[12:55] <mup> PR #10155: [RFC] o/snapstate: handle refresh hints <Refresh control> <Skip spread> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10155>
[14:12] <cachio_> mborzecki, I have tested minimal smoke with 512MB and works
[14:12] <mborzecki> cachio_: with secure boot enabled right?
[14:12] <cachio_> yes
[14:13] <mborzecki> cachio_: can you also try to run it with 384MB like before, but with disabled tpm/secure boot?
[14:13] <cachio_> sure
[14:13] <mborzecki> eventually maybe we should keep both variants of the test
[14:13] <mborzecki> mvo: ^^
[14:14] <mvo> mborzecki: +1 (but in a meeting right now)
[14:19] <ijohnson> pedronis: sorry I think I forgot to look at the frankfurt notes to see that it was decided to _not_ allow having different quota groups for services in a single snap, that does simplify things I suppose, but to be clear that's the implementation we want for now ?
[14:19] <ijohnson> to have a single group for all services in a snap ?
[14:20] <pedronis> yes
[14:20] <ijohnson> that does go a bit against our recommendation that we give to customers to bundle services into a single snap, since now all the services in a single snap would be subject to the same resource quota
[14:21] <cachio_> mborzecki, you mean to run with 384 and not secboot and with 512 and secboot right?
[14:21] <mborzecki> cachio_: yeah
[14:21] <cachio_> mborzecki, I can try that
[14:24] <pedronis> ijohnson: I was not even aware of this reccommendation
[14:24] <pedronis> is that just because then it's easier to make them talk to each other?
[14:25] <ijohnson> pedronis yes, at least that's what was the recommendation when I was on the field team
[14:25] <ijohnson> The other reason is due to refreshes etc and keeping different services in sync
[14:27] <pedronis> either way, we can't start doing services as first step, it gets pretty convoluted quickly state wise
[14:29] <ijohnson> ok, I thought it was fairly straight forward to just put a quota on an appinfo like I showed, but as mentioned I have not finished plumbing everything together
[14:29] <pedronis> ijohnson: but we don't really keep app infos around like that
[14:29] <pedronis> that's why as I said there's need some thinking about what we actually stick into the state
[14:30] <ijohnson> oh I see, I didn't realize we don't serialize app-infos like that
[14:30] <pedronis> ijohnson: SnapState doesn't contain a snap.Info nor snap.AppInfos
[14:30] <pedronis> we read them always from disk combined with SideInfo data from SnapState
[14:31] <ijohnson> mmm right
[14:31] <pedronis> so not even clear that putting the group in snap.Info is useful or confusing
[14:32] <ijohnson> Okay, I'll have a look today
[14:32] <pedronis> at the wrappers level it could come via SnapServicesOptions
[14:32] <pedronis> but not sure
[14:33] <pedronis> there is more than one way to do this, but ultimately we need to keep what we did/need to do in state
[14:33] <ijohnson> Right
[14:46] <mborzecki> pedronis: ijohnson: i've updated #10148
[14:46] <mup> Bug #10148: xfree86: new changes from Debian require merging <Ubuntu:Invalid by fabbione> <https://launchpad.net/bugs/10148>
[14:46] <mup> PR #10148: overlord/devicestate, overlord/snapstate: add task for updating kernel command lines from gadget <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10148>
[14:53] <ijohnson> ack
[15:29] <pedronis> mborzecki: I re-reviewed it, I'm looking at the full one next. OTOH that one probably can use as many eyes as possible
[15:29] <pedronis> I mean the task one
[15:30] <mborzecki> pedronis: understood, thanks for the review
[15:57] <mup> PR snapd#10157 opened: o/snapstate: remove unused DeviceCtx argument of ensureInstallPreconditions <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10157>
[15:59]  * cachio_ lunch
[16:20] <zyga> mborzecki around?
[16:20] <pedronis> I reviewed https://github.com/snapcore/snapd/pull/10156 thanks
[16:20] <mup> PR #10156: boot, bootloader, bootloader/assets: support for full command line override from gadget <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10156>
[16:32] <mup> PR snapd#10158 opened: packaging: build without dwarf debugging data <Created by zyga> <https://github.com/snapcore/snapd/pull/10158>
[18:17] <mup> PR snapd#10135 closed: tests/lib/nested: proper status return for tpm/secure boot checks <Run nested> <Simple 😃> <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10135>
[18:28]  * cachio_ afk
[19:10] <mup> PR snapcraft#3503 opened: deb: do not filter python3 packages on core20 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3503>
[19:37] <mup> PR snapd#10159 opened: secboot: use secboot.{ActivateVolumeWithKeyData,SnapModelChecker} <Run nested> <Created by mvo5> <https://github.com/snapcore/snapd/pull/10159>
[23:15] <mup> PR snapcraft#3495 closed: conda v2 plugin: support for more architectures <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3495>


[00:03] <ejat> hi .. how to get juju-gui inside horizon?
[00:25] <rick_h_> ejat: it's something that is in an alpha stage and not available for download at this time as it's not complete.
[00:25] <rick_h_> ejat: you can reach out to<EMAIL_ADDRESS>to express interest about it was a product going forward.
[00:25] <ejat> rick_h_: owh okie thanks for the info.
[00:26] <ejat> bcoz i see someone presenting it at the openstack event
[00:27] <rick_h_> ejat: yes, it's been presented to gauge interest and demonstrate Juju in an openstack setup
[13:26] <fabrice> ccdlntlttbcilufrjijkhbftkkettgnuechlnvcd


[12:15] <BluesKaj> hiyas all
[16:32] <BLZbubba> oh my god what will it take to get plymouth & upstart removed from 12.10?
[16:34] <jtaylor> pymouth no idea, but upstart will stay
[16:44] <wilee-nilee> BLZbubba, nice nic that is funny. :)
[16:49] <bjsnider> they aren't going to use systemd at this point, so upstart stays, and plymouth was added a couple of releases ago, no reason to remove it
[16:54] <jbicha> BLZbubba: you're welcome to try Fedora 17 if you need systemd
[17:44] <BLZbubba> wilee-nilee: :) thanks
[17:44] <wilee-nilee> ;)
[17:45] <BLZbubba> jbicha: even a big list of commands in rc.local would be preferable to upstart, upstart is junk


[11:15] <jtv> flacoste: say, would you mind having a look at this suggested change?  https://code.edge.launchpad.net/~jtv/launchpad/decruft-test-template/+merge/30080
[11:34] <lifeless> jtv: its huge
[11:34] <lifeless> jtv: huger than your description implies.
[11:35] <jtv> lifeless: whoops...  forgot to select "devel" instead of "launchpad"
[11:35] <jtv> I'll re-do.  Thanks for noticing.
[11:38] <jtv> lifeless, flacoste: better diff here... https://code.edge.launchpad.net/~jtv/launchpad/decruft-test-template/+merge/30083
[11:55] <gary_poster> salgado: Looks good generally.  I have some small naming niggles.  "orig_interface" -> "callable"? or "interface"? or "adaptation"?  "orig" doesn't make much sense to me inherently.
[11:55] <gary_poster> Similar naming concern: "class Adapter(object):"  Maybe name should be "Adaptable"?  or just "Demo" or "Example"?
[11:55] <gary_poster> Also...will come by. :-)
[13:12] <james_w> Hello friendly launchpad reviewers, could someone take a look at my branches?
[13:12] <james_w> https://code.edge.launchpad.net/~james-w/launchpadlib/fix-default-version-in-test/+merge/29943
[13:12] <james_w> https://code.edge.launchpad.net/~james-w/launchpad/expose-blueprints/+merge/30026
[13:13] <james_w> sinzui: I export a whiteboard in the latter, and I believe you may have an opinion on that?
[14:39] <james_w> thanks for the review leonardr, I have replied with some questions
[14:39] <leonardr> james_w, great
[14:42] <leonardr> james_w: some of your questions i can answer right away. others i will need to get feedback from someoen who knows more about launchpad
[14:43] <james_w> ok
[14:49] <leonardr> sinzui, i'm going to refer some of the questions about james_w's blueprint web service branch to you.
[14:49] <leonardr> if you think someone else can do it, let me know
[14:49] <leonardr> https://code.edge.launchpad.net/~james-w/launchpad/expose-blueprints/+merge/30026
[14:49] <leonardr> i'll reply to his most recent comments specifically calling out some questions to you
[15:30] <leonardr> poolie, i requested one review from you which you said 'needs fixing' (and i've responded to your comments). the other two i hadn't requested a review, but i have now
[15:51] <deryck> mrevell, incoming.... https://code.edge.launchpad.net/~deryck/launchpad/fix-heat-help-link/+merge/29856
[15:51] <deryck> sinzui, see ^^ for a code review ack :-)  Thanks!
[17:35] <jtv> danilos: https://code.edge.launchpad.net/~jtv/launchpad/translationtemplatescollection-test/+merge/30114