[01:59] <mup> PR snapd#4688 opened: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al - 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4688>
[02:12] <mup> PR snapd#4689 opened: tests: new spread test for kvm interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4689>
[02:23] <crumbles> How does snapcraft decide which library dependencies to include in a snap? I understand that snapcraft excludes libraries that core snap already has. What happens if my app requires other libraries that are not in core snap?
[02:30] <nacc> crumbles: that's up to the plugin, presumably
[05:57] <mborzecki> morning
[06:52] <mborzecki> mvo: morning
[06:53] <mborzecki> mvo: i see that travis jobs on master is passing now
[06:55] <mvo> mborzecki: oh, interessting - its failing badly in 2.31
[06:56] <mborzecki> mvo: afaik it needs this https://github.com/snapcore/snapd/pull/4685
[06:56] <mup> PR #4685: interfaces/time-control,netlink-audit: adjust for util-linux compiled with libaudit - 2.31 <Critical> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4685>
[06:57] <mborzecki> mvo: something weird, master tip built failed with some random store related faiilure, restarted it and waiting for results
[06:58] <mborzecki> mvo: but jdstrand's PR on 2.31 fails for some totally unrelated reasons
[06:58] <mvo> mborzecki: yeah, thats what I mean, 2.31 is in a really unhappy state and its not clear why
[06:59] <mborzecki> mvo: maybe something new in core from edge?
[06:59] <mvo> mborzecki: yeah, must be something external, still super strange
[06:59] <mborzecki> let me run that pr from spread
[07:02] <mvo> mborzecki: yeah, we need to get to the bottom of this, also super strange that master is fine but 2.31 is broken
[07:03] <mborzecki> + test-snapd-timedate-control-consumer.hwclock-time -r -f /dev/rtc
[07:03] <mborzecki> execl failed: No such file or directory
[07:03] <mborzecki> hmm maybe somthing wrong with patht ot snap-confine/snap-exec
[07:04] <mborzecki> mvo: debian does not reexec right?
[07:04] <mvo> mborzecki: it does not currently
[07:04] <mvo> mborzecki: oh, its related to /lib/udev/snappy-app-dev - but that should still be there in 2.31
[07:06] <mvo> mborzecki: aha, I get it - core no longer has /lib/udev/snappy-app-dev
[07:06] <mborzecki> hah
[07:06] <mvo> mborzecki: the core snap - we need to symlink it
[07:06] <mvo> mborzecki: yay, mystery solved!
[07:06] <mborzecki> so many moving parts :)
[07:08] <mvo> mborzecki: indeed
[07:08] <mup> PR snapcraft#1926 closed: Release changelog for 2.39.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1926>
[07:25] <mup> PR snapd#4690 opened: packaging: provide a compat symlink for snappy-app-dev <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4690>
[07:27] <mvo> mborzecki: ^- should fix things.
[07:28] <mborzecki> mvo: missing newline at the end, otherwise +1
[07:30] <zyga> o/
[07:30] <mvo> mborzecki: meh, indeed
[07:30] <mborzecki> zyga: hey
[07:31] <mvo> force-pushed the \n
[07:31] <zyga> hey, sorry for being so late folks, I feel a bit off today
[07:57] <kalikiana> good morning
[07:57] <kalikiana> o/ zyga
[07:57] <zyga> hey kalikiana, how are you doing?
[07:57] <mvo> good morning kalikiana
[07:58]  * zyga has a headache today, pretty unusual for him 
[07:58] <kalikiana> I feel like I'm the conductor of a bug triaging train this week... all I'm missing is the hat
[07:58] <zyga> kalikiana haha, that's awesome :)
[07:59] <kalikiana> zyga: have a hot soup? like, stock in a cup and hot water. makes you feel good
[08:00]  * kalikiana just had a miso soup, nice and salty
[08:00] <zyga> nice :)
[08:01] <zyga> I don't think I have any though, it's sandwich day everyday
[08:06] <mup> PR snapd#4691 opened: cmd/snap: use proper help strings for `snap userd --help` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4691>
[08:06] <mborzecki> mvo: ^^ may be a 2.31 material too
[08:07] <mborzecki> btw. 4691 is trivial review so if anyone could take a look :)
[08:08] <zyga> ack
[08:08] <mborzecki> btw. there's also a file cmd_shell.go, does not appear to be used at all
[08:09] <mborzecki> gometalinter throws: cmd_shell.go:33:1⚠️ cmdShell is unused (deadcode)
[08:09] <zyga> mborzecki let's remove it
[08:10] <zyga> mborzecki can you also fire that tool on osutil
[08:10] <mborzecki> zyga: is it something that predates snap run --shell?
[08:10] <zyga> I suspect there are some unused bits for mounting related tasks
[08:11] <mvo> mborzecki: aha, thanks
[08:11] <mvo> mborzecki: great job
[08:44] <zyga> hmm, tests are not in a happy place
[08:44] <mup> PR snapd#4692 opened: cmd/snap: linter cleanups <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4692>
[08:44] <mborzecki> trivial PR ^^
[08:45] <zyga> mvo do we need https://github.com/snapcore/snapd/pull/4690 for 2.31?
[08:45] <mup> PR #4690: packaging: provide a compat symlink for snappy-app-dev <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4690>
[08:46] <mvo> mborzecki: thanks for the cleanups
[08:46] <mvo> zyga: we don't need it in 2.31, just in master
[08:46] <zyga> ok
[08:46] <mvo> zyga: 2.31 still has the old path
[08:46] <mvo> zyga: and we need travis slots :/
[08:46] <zyga> let's hold on with new PRs
[08:46] <zyga> until that one lands
[08:46] <mvo> yeah
[08:48] <mborzecki> uhh, sorry, i've take a couple of slots recently
[08:58] <mborzecki> zyga: have you looked at https://github.com/snapcore/snapd/pull/4682 ? wonder what will happen if you poke that address
[08:58] <mup> PR #4682: tests: new spread test for physical-memory-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4682>
[09:00] <zyga> woah
[09:00] <zyga> nothing good will happen
[09:00] <zyga> that's a weird address to poke
[09:00] <zyga> I don't understand that test TBH
[09:01] <Chipaca> moin
[09:01] <mborzecki> Chipaca: morning
[09:02] <mborzecki> Chipaca: how are you keyboardio typing skills today?
[09:03] <Chipaca> I'm only typing a few minutes a day on it until I get used to it
[09:03] <Chipaca> Hella slow
[09:05] <Chipaca> That was all typed on the butterfly as was this
[09:05] <Chipaca> but this is top speed
[09:05] <mborzecki> i can imagine, remember using one of the 'ergonomic' keyboards from MS for the first time, the one where the middle was a bit higher than the sides, you had a feeling that you're using an orb not a keyboard :)
[09:07] <mborzecki> keyboardio must be a whole new level
[09:08] <Chipaca> the thing that most catches me out is space being only on one side
[09:09] <Chipaca> when I think "space", the nearest thumb twitches
[09:09] <Chipaca> man t
[09:09] <Chipaca> man those quotes were hell to type :-)
[09:09] <mborzecki> you can remap the keys though, right?
[09:10] <Chipaca> ah, yes, probably? but that's not my problem, just that i have never trained to use my pinkies
[09:10] <Chipaca> my typing is self taught
[09:10] <Chipaca> and, mostly two fingers (maybe 2.5) and thumbs,
[09:11] <Chipaca> so using my whole hand is going to need some time
[09:11] <Chipaca> (i'm now back on the regular qwerty)
[09:11] <Chipaca> in my defense, there was no way my 12-year-old pinkies could move the commodore's keys
[09:12] <Chipaca> mvo: morning sah
[09:12] <mvo> Chipaca: good morning
[09:12] <Chipaca> mvo: tell me more about this magic realism^W^W ast thing
[09:13] <Chipaca> mvo: should I add a comment about what it's doing, from a higher leverl than the step-oriented comments I put in there (that are mostly to help future me)
[09:13] <Chipaca> mvo: I _could_ make it a general thing, move it to testutils and add tests
[09:14] <mvo> Chipaca: I think the code and comments are fine, I just wonder if we should have a test for the test itself, i mean, how do we know it works :) ?
[09:14] <Chipaca> mvo: if you think it's worth it :-)
[09:14] <mvo> Chipaca: maybe not
[09:14] <mvo> Chipaca: I was mostly wondering
[09:14] <Chipaca> mvo: well, we'll find out it isn't working easier than we find out it is
[09:14] <Chipaca> er
[09:15] <Chipaca> i mean it counts only one way we could be adding commands, if we ever add them a different way it'll fail
[09:15] <Chipaca> it's very restrictive
[09:15] <mvo> Chipaca: ok, that sounds good then
[09:15] <Chipaca> if we create a function that returns *Commands and use that it'll fail for example
[09:16] <mvo> Chipaca: ok, thats all right then, I was not aware of this property. no need for an extra test in this case I think
[09:16] <niemeyer> Hello snapping people
[09:16] <Chipaca> mvo: should I add a high-level comment with this? otherwise we'll forget why it was ok :-)
[09:16] <Chipaca> niemeyer: go to bed niemeyer you're asleep
[09:17] <mvo> hey niemeyer ! you are up early!
[09:17] <mborzecki> niemeyer: hello, you're up early
[09:17] <niemeyer> Heya!
[09:17] <mborzecki> Chipaca: hah found a diy one https://docs.keeb.io/iris-build-guide.html
[09:17] <niemeyer> I've been awake for about 6h now.. sleep is indeed catching up a bit by now
[09:18] <Chipaca> mborzecki: heh. Give keyboard.io's blog a read sometime, it's fun
[09:18] <niemeyer> The good news is we have a working spread in GCE
[09:21]  * Chipaca hugs niemeyer 
[09:21] <Chipaca> running spread against qemu on my old laptop that no longer likes having 8gigs is torture
[09:24] <niemeyer> Chipaca: Aw..
[09:24] <niemeyer> Chipaca: Although I haven't managed to run anything realistic yet, I can already tell that the networking does make a difference
[09:25] <mvo> niemeyer: \o/
[09:25] <niemeyer> I have secret hopes of pushing the suite below 20 minutes soon, but it's a bit early to tell yet
[09:27] <mup> PR snapd#4690 closed: packaging: provide a compat symlink for snappy-app-dev <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4690>
[09:30] <zyga> whee, thank you mvo
[09:30] <mvo> zyga: yw, I build a new core now, then things should be normal again
[09:38]  * kalikiana coffee
[09:40] <Chipaca> github, you so broken
[09:40] <niemeyer> mvo: Do we actually have snappy-app-dev inside /lib/snapd now?
[09:41] <mvo> niemeyer: yes
[09:41] <mvo> niemeyer: that PR got merged a couple of days ago so that bases work correctly there
[09:42] <niemeyer> mvo: I was just hoping for a better name on the transition, but probably too late
[09:42] <niemeyer> snappy-app-dev is bad on every token.. :)
[09:43] <mvo> niemeyer: uh, sorry, was not aware of this desire. we can still do this
[09:43] <niemeyer> mvo: I probably never mentioned because it was a legacy piece
[09:43] <mvo> niemeyer: if you have a good name I am happy to make it happen
[09:43] <mvo> niemeyer: there is also a desire to rewrite it or integrate it into snap but that is orthogonal to some extend
[09:45] <niemeyer> mvo: I was just hoping to get it somewhat closer to its purpose, and less enigmatic
[09:46] <mup> PR snapd#4691 closed: cmd/snap: use proper help strings for `snap userd --help` <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4691>
[09:47] <mvo> niemeyer: happy about suggesitons - snap-udev-helper?
[09:47] <mvo> niemeyer: should be easy enough and best to do it now instead of having yet another transition
[09:49] <niemeyer> mvo: That sounds good
[09:49] <niemeyer> mvo: How is that tool called?  From within a udev rules file?
[09:49] <mvo> niemeyer: yes, also from snap-confine
[09:51] <niemeyer> mvo: Cool, sounds good
[09:52] <niemeyer> mvo: The current functionality might lean itself to something around cgroups instead of udev, but I guess that udev might need something else in the future and we'd still want to put it around the same place
[09:54] <mvo> niemeyer: we could also use "snap-devices-helper" to be more generic
[09:55] <niemeyer> mvo: Ah, even better! +1!
[09:55] <niemeyer> mvo: Perhaps singular: snap-device-helper
[09:55] <mvo> niemeyer: sounds good, I work on this now
[09:57] <niemeyer> mvo: Perhaps even just "snap-device".. in theory most of the things inside lib/snapd are helpers
[10:08] <mup> PR snapd#4673 closed: interfaces/mount: generate per-user mount profiles <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4673>
[10:09] <mup> PR snapd#4692 closed: cmd/snap: linter cleanups <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4692>
[10:13] <Chipaca> mvo: when I can't imagine how to do something, it usually indicates a failure of my imagination. Remind me of this more often.
[10:13]  * Chipaca fixing stuff
[10:15] <mup> PR snapd#4687 closed: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4687>
[10:17] <zyga_> mborzecki question about --timer=... on commands
[10:17] <zyga_> are such commands exported in /snap/bin?
[10:17] <zyga_> and what is the --timer=%q part for (in LauncherCommand)
[10:17] <mborzecki> yes
[10:18] <zyga_> mborzecki hmm, what is that for?
[10:18] <zyga_> why would the user wish to have a timer on their path
[10:18] <mborzecki> zyga_: --timer is the schedule given service runs with;, eg --timer="mon,10:00~12:00,,fri,13:00"
[10:20] <zyga_> what I don't understand is why do we want to put a command on path
[10:20] <mborzecki> the way it works, is that we have a *.timer and a *.service, the *.service uses `snap run --timer ..`, when the timer activates the service it will call snap run --timer, then when 'time.Now()' matches the scedule, the service will be ran, otherwise it exits
[10:20] <mup> PR snapd#4693 opened: many: rename snappy-app-dev to snap-device-helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4693>
[10:20] <mvo> Chipaca: heh :) I'm not sure what happend but I'm glad you are fixing stuff
[10:20] <zyga_> mborzecki are we doing that because our timer syntax is richer than that of systemd?
[10:21] <mup> PR snapcraft#1929 opened: sources: proper errors for invalid handlers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1929>
[10:21] <Chipaca> mvo: found a way of making the current implementation give a false negative, fixed it and adding tests
[10:21] <mborzecki> zyga_: yes, at least the --timer part is for this
[10:21]  * Chipaca bows before mvo's greater wisdom
[10:21] <zyga_> mborzecki would that still work if the command was not on path (not in /snap/bin)
[10:22] <mvo> Chipaca: lol - I just like asking silly questions
[10:22] <Chipaca> suuure
[10:22] <mborzecki> zyga_: yeah, probably if i tweak snap run it would, but why would you do that?
[10:24] <zyga> mborzecki mainly because I don't see why I would like to have timers on path
[10:24] <zyga> it's an implementation detail (typically)
[10:24] <zyga> and since the timer unit can just say "snap run ... "
[10:24] <zyga> there's no real need for that command to be exposed
[10:26] <mborzecki> zyga: hmm ok, i need to how to invoke it, can you leave a comment in the PR?
[10:26] <zyga> sure
[10:26] <zyga> I'm going through that now
[10:26] <mborzecki> thanks
[10:27] <mup> PR snapd#4679 closed: systemd: add default target for timers <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4679>
[11:06] <Chipaca> niemeyer: are you still amongst us?
[11:06] <niemeyer> Chipaca: I shall be
[11:07] <Chipaca> niemeyer: as pressure continues to mount to add things to 'snap list' and 'snap find', how do you feel about making it single-line-per-entry only if stdout is a tty?
[11:07] <Chipaca> i.e. wrap some of the columns if the thing is too wide, but only if a user is looking at it
[11:07] <Chipaca> (i have a change request that will make it wider)
[11:10] <niemeyer> Chipaca: The output we have right now is quite nice.. what else do we need there at the moment?
[11:10] <Chipaca> niemeyer: remember 'Tracking'?
[11:11] <niemeyer> Chipaca: Without further details, my temptation would be to argue to keep it nimble instead of making it larger
[11:11] <Chipaca> I'd say the output of 'snap find' is _not_ nice today, already (but Tracking is for snap list, which isn't there yet)
[11:14] <zyga> mborzecki can you look at https://github.com/snapcore/snapd/pull/4675#pullrequestreview-97145880 please
[11:14] <mup> PR #4675: timeutil: fix scheduling on nth weekday of the month <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4675>
[11:15] <mup> PR snapd#4693 closed: many: rename snappy-app-dev to snap-device-helper <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4693>
[11:16] <zyga> mvo do you know what is going on in 2.31 release branch
[11:17] <mvo> zyga: the symlink was not enough, I need to pick my daugther up in some minutes, but right now I'm a bit uncertain why the symlink did not help
[11:17] <zyga> mvo I was looking at a PR from jamie and it looks like all kinds of weird stuff is going on with interfaces
[11:18] <mvo> zyga: its failing because snap-confine cannot execl /usr/lib/udev/snappy-app-dev
[11:18] <mvo> zyga: which appears to happen inside the core snap
[11:19] <mvo> zyga: but its strange because our tests modify the core snap so maybe soemthing there
[11:19] <zyga> mmmm, is is perhaps related to the stale apparmor profile bug
[11:19] <mvo> zyga: probably not, its not a eaccess, its a not-found
[11:19] <zyga> aha
[11:19] <zyga> ok
[11:20] <mvo> zyga: I will need to leave in 2min but will think over it, ideas welcome, definitely related to the snappy-app-dev rename
[11:20] <zyga> kk
[11:42] <koza> im not on this mtg
[11:42]  * koza hates focus follows mouse
[11:44] <mup> PR snapd#4694 opened: cmd/snap-update-ns: small refactor for upcoming per-user mounts <Created by zyga> <https://github.com/snapcore/snapd/pull/4694>
[11:46] <zyga> Chipaca *nice* testing helpers
[11:47] <Chipaca> zyga: ik,r?
[11:47] <mvo> zyga: yeah, he rocks
[11:47] <zyga> and also for making them useful across the tree!
[11:55] <zyga> Chipaca review on 4681
[11:55] <Gnjurac> can i build snaps form github
[11:55] <zyga> great work there
[11:55] <Gnjurac> cuz atm on page it says failing
[11:55] <Gnjurac> https://github.com/snapcore/snapd
[11:55] <zyga> Gnjurac hey, sure you can, have you seen snapcraft.io?
[11:56] <Gnjurac> yep
[11:56] <Gnjurac> but i am on voidlinux
[11:56] <Gnjurac> so no snap in repo
[11:56] <ogra_> you are building snapd, not a snap package ?
[11:56] <zyga> you can hook up your github repository to snapcraft.io and have it built automatically
[11:57] <Chipaca> Gnjurac: are you trying to build snapd, or a snap?
[11:57]  * zyga won't repeat that now but this is a valid question
[11:58] <Gnjurac> i want snapd so i can install snaps
[11:58] <Gnjurac> apps
[11:58] <zyga> ah. ok
[11:58] <zyga> you will need the golang stack, a C compiler and some basic libraries,
[11:59] <zyga> at runtime you will likely need systemd
[11:59] <zyga> what kind of issues are you running into now?
[11:59] <ogra_> zyga, void uses "runit" not systemd ...
[11:59] <zyga> yes, I read
[11:59] <ogra_> that might be a bit more work :)
[12:00] <zyga> Gnjurac I can help you out
[12:00] <Gnjurac> hmm meybe too much work for newbie like me, guess i will post request for it on github
[12:00] <zyga> Gnjurac but you have to do the work :)
[12:01] <Gnjurac> zyga: really?
[12:01] <zyga> I can just offer help and ideas
[12:01] <Gnjurac> i am willing
[12:01] <zyga> I think not having systemd is a major issue though
[12:01] <Gnjurac> have time
[12:01] <zyga> is systemd an option or is it just not packaged?
[12:01] <Gnjurac> no systemd
[12:01] <Gnjurac> at all
[12:02] <Gnjurac> void use runit
[12:02] <zyga> does runit provide systemd-like shim so that software written for system can run on top?
[12:03] <Gnjurac> hmm duno like i say am newb , i know i can just add services in runit and thats all
[12:04] <zyga> Gnjurac this may be a little bit of a steep learning curve, you may want to try a systemd-enabled distribution to play with snaps first
[12:05] <Gnjurac> http://smarden.org/runit/
[12:05] <Gnjurac> hmm ye i am thinking that same
[12:05] <Gnjurac> anyway do you maybe have dotnet installed?
[12:05] <Gnjurac> or mono
[12:05] <Gnjurac> i need msbuild binary
[12:07] <zyga> Gnjurac I see some chatter about dotnet snaps on the forum (forum.snapcraft.io)
[12:07] <zyga> and I see there si a dotnet-sdk snap currently in the edge channel
[12:08] <zyga> you may want to check with the people interacting with those forum topics
[12:15] <mup> PR snapcraft#1928 closed: tests: remove duplicate tests <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1928>
[12:18] <mup> PR snapd#4695 opened: wrappers: generator for systemd OnCalendar schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4695>
[12:23] <zyga_> mborzecki quick feedback done
[12:23] <mborzecki> thanks
[12:41] <andyrock> mvo: hey so regarding ubiquity and the store login, using the chroot is not possible
[12:41] <zyga_> https://github.com/snapcore/snapd/pull/4694/files needs a trivial review
[12:41] <mup> PR #4694: cmd/snap-update-ns: small refactor for upcoming per-user mounts <Created by zyga> <https://github.com/snapcore/snapd/pull/4694>
[12:42] <andyrock> mvo: the problem is that when we show the login page it could be possible that snapd is not yet installed in the chroot
[12:43] <andyrock> mvo: would be possible to add a way to seed login keys in some way?
[12:48] <Chipaca> zyga_: can you point me at a test where you'd use a FileState checker if it existed?
[12:48] <Chipaca> i might as well add it while i'm there, but not without a concrete use case
[12:48] <zyga_> I don't use any such checker yet
[12:48] <Chipaca> otherwise it's just wankery :-)
[12:48] <zyga_> nah, ignore me
[12:48] <zyga_> I will try that myself and see if it's sensible
[12:48] <Chipaca> zyga_: let me push a little refactor that should make it trivial
[12:48] <zyga_> but I think some tests could compute the file state and check if it was applied this way
[12:49] <zyga_> an interface maybe?
[12:50] <mup> PR snapd#4696 opened: wrappers: timer services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4696>
[12:52] <mborzecki> hmm wish github had like a topic under which you could open PRs, there's a couple of PRs related to timer services and no way of telling that they are in the same 'group' unless it's in the comments
[12:54] <Chipaca> zyga: https://github.com/snapcore/snapd/pull/4697
[12:54] <mup> PR #4697: osutil: refactor EnsureFileState to separate out the comparator <Created by chipaca> <https://github.com/snapcore/snapd/pull/4697>
[12:54] <zyga> mmm
[12:54] <Chipaca> mmm, or hmmm?
[12:54] <mup> PR snapd#4697 opened: osutil: refactor EnsureFileState to separate out the comparator <Created by chipaca> <https://github.com/snapcore/snapd/pull/4697>
[12:55] <zyga> +1 nice
[12:55] <zyga> it was just "mmm, looking"
[12:56] <zyga> this made me realise we could improve the case where content matches but mode doesn't
[12:56] <Chipaca> there is, of course, a problem with os.IsNotExist
[12:56] <Chipaca> :-)
[12:57] <Chipaca> I don't know what it says about me that I drill in to the silly corner cases
[12:57] <Chipaca> but if foo/bar is a file, and you ask it about foo/bar/baz, you get an error that is not IsNotExist
[12:57] <zyga> yeah, that's fine
[12:58] <Chipaca> ok :-)
[13:18] <jdstrand> mvo: you siad /usr/lib/udev/snappy-app-dev. did you mean /usr/lib/snapd/snappy-app-dev?
[13:19] <zyga_> jdstrand can you give me a quick +1 on trivial 4694 please
[13:19] <jdstrand> let me look
[13:20] <zyga> jdstrand thanks, I'm working on the next chunk there but I'm still playing with some experiments to make things better than what we had before
[13:23] <jdstrand> zyga: how does this relate to the one check I requested that was keeping 3963 from landing?
[13:24] <zyga> jdstrand it's related, I'll implement the check
[13:24] <jdstrand> I think you said something about being able to be race free?
[13:24] <zyga> I'm just shrinking the original branch so that it's easier for people to actually see the code and to make progress
[13:24] <jdstrand> but maybe that was for something else
[13:24] <zyga> it was for that, I'm experimenting (still)
[13:24] <zyga> it would be a one trick pony
[13:24]  * jdstrand wasn't sure how to prevent that race so was curious what you came up with :)
[13:24] <zyga> but might work for the thing we want here
[13:24]  * jdstrand nods
[13:25]  * jdstrand knew it was related, just wasn't sure how
[13:25] <jdstrand> I'll be patient and wait for the big reveal :)
[13:25] <zyga> if it works you'll see, if it fails I'll tell you the idea
[13:25] <jdstrand> hehe ok :)
[13:26] <zyga> holly crap, some of this rocks :-)
[13:26] <zyga> jdstrand i think the linux kernel is amazing and so full of weird features I'm really afraid
[13:27] <jdstrand> heh
[13:27] <mup> PR snapd#4694 closed: cmd/snap-update-ns: small refactor for upcoming per-user mounts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4694>
[13:27] <mup> PR snapcraft#1930 opened: lxd: friendly errror with suggestions if network is broken <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1930>
[13:28] <zyga> jdstrand so, I wasn't aware you can reach across mount namespaces
[13:28] <zyga> this easily
[13:28] <zyga> without setns
[13:28] <zyga> you can go to /proc/pid/root and lo and belhod, it's there
[13:28] <zyga> so
[13:35] <jdstrand> zyga: hmm
[13:36] <jdstrand> that seems like it might go against a design constraint
[13:36] <jdstrand> (of ours)
[13:36] <zyga> it behaves oddly though
[13:37] <jdstrand> yeah, with mount namespaces and pivot_root...
[13:39] <jdstrand> this is what I was thinking of: https://github.com/snapcore/snapd/pull/4329/commits/7824fb1d4001e94121b5efd1644aa1af7599b906#r154192314
[13:39] <mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4329>
[13:41] <jdstrand> that doesn't say to not use /proc/pid/root specifically, but it wouldn't surprise me at all if it doesn't work. if it does work, we should consult with jj
[13:42] <zyga> yeah, it's certainly possible
[13:43] <jdstrand> yeah, it looks like it is just a symlink
[13:44] <jdstrand> root -> /
[13:44] <zyga> jdstrand it's not a real symlink
[13:44] <zyga> it's actually a gateway to that namespace, it's all weird
[13:44] <zyga> you can see what's mounted there
[13:44] <zyga> even if that doesn't show up in your mountinfo
[13:45] <jdstrand> hmm
[13:45] <zyga> for instance I can use it to write to a tmpfs mounted in a namespace I don't inhabit
[13:45] <zyga> over a mount point that doesn't exist
[13:45] <jdstrand> wow
[13:45] <zyga> I think it was meant for chroot
[13:45] <jdstrand> that sounds like a bug
[13:45] <zyga> and pivot root and mount namespaces
[13:45] <zyga> made it worse
[13:45] <jdstrand> oh you are still in the shared mount
[13:45] <zyga> yeah, I'm checking the sources
[13:46] <zyga> I mounted tmpfs in a slave mount namespace
[13:46] <zyga> unshared from the main one
[13:47] <zyga> it really feels like /proc/pid/root is a magic gateway that feels like traversing setns
[13:47] <zyga> I wonder how far this goes
[13:48] <jdstrand> that does sound like a breakout and not one I would think would be allowed. stgraber did a lot of work checking out different things in /proc. perhaps he has more details on /proc/pid/root
[13:48] <zyga> nsenter -m/proc/1/root/run/snapd/ns/hello.mnt
[13:48]  * jdstrand is thankful for strict mode
[13:49] <zyga> we can jump across this
[13:49] <jdstrand> ftr, that does break our design contraints ;)
[13:49] <jdstrand> but I realize you are just playing here
[13:49] <zyga> yeah, I'm checking how deep this thing goes
[13:49] <zyga> and if it has useful properties for what we need to do
[13:50] <jdstrand> perhaps it is working as designed and container managers are expected to mount over that so the contained process doesn't have access to it?
[13:50] <zyga> that when it ges weird
[13:50] <jdstrand> the alternative would be frightening
[13:50] <zyga> it doesn't seem to work that way
[13:51] <zyga> I wonder if I can chroot there
[13:52] <jdstrand> https://www.kernel.org/doc/Documentation/filesystems/proc.txt has very little info
[13:52] <zyga> yeah, it feels like it's from chroot era
[13:52] <zyga> and hasn't been touched since
[14:15] <mup> PR snapd#4649 closed: many: record if snap was installed with --dangerous, snow relevant annotation in `snap info` and `snap list` <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4649>
[14:39] <kalikiana> re
[14:57] <stgraber> jdstrand, zyga: /proc/PID/root is indeed a great way to cross mntns boundaries and one we actually make use of very often as a way to access the container's filesystem from the host, or in the case of our snap, to access the host filesystem with the right view of all mounts (though we've mostly switched to /var/lib/snapd/hostfs for that these days)
[14:58] <stgraber> in real containers, we make sure to always use a pid namespace and always use a new instance of /proc, which prevents the container from seeing any pids from the host and so preventing access to /proc/PID/root
[15:00] <zyga> thank you for sharing that
[15:00] <zyga> I wish it was more documented and that one could do mounts in that "place"
[15:00] <zyga> it seems that mounts traverse symlinks (as expected) and then end up in the current namespace
[15:06] <stgraber> zyga: the kernel actually has logic specifically preventing passing mounts through that
[15:06] <jdstrand> zyga: I'm not sure what apparmor is going to do wrt /proc/pid/root. if planning on using it, we need jjohansen to weigh in
[15:06] <zyga> stgraber what is the motivation for that logic? can you point it to me?
[15:07] <stgraber> zyga: we tried a number of trick to send mounts through /proc/PID/root in the past, using things like dirfd + bind-mount from /proc/self/fd and the like, but we kept hitting the cross mntns security check that's in the kernel
[15:07] <zyga> haha
[15:07] <zyga> I was thinking about using something like that :)
[15:08] <zyga> and I'm reading kernel source code to see what's going on
[15:08] <stgraber> zyga: there is a check in the mount code that makes sure the source and target mntns are the same, that was added as a security check a long time ago and nobody seems quite sure what that was for
[15:08] <jdstrand> ok, so maybe no need to bring jjohansen in if even unconfined won't work
[15:08] <stgraber> zyga: but also nobody wants to remove it
[15:09] <zyga> jdstrand yeah, I think it's premature now, let jjohansen have his focus
[15:09] <zyga> stgraber it would really be nice if that would work though, given enough permissions, could simplify mount management in containers
[15:09] <zyga> but I'd give that away if mount handled fd's better instead :)
[15:10] <mborzecki> off to pick up the kids
[15:28] <mup> PR snapcraft#1931 opened: No plainbox <Created by yphus> <https://github.com/snapcore/snapcraft/pull/1931>
[15:32] <jdstrand> mvo, zyga: just as an fyi which you are probably aware of, Monday is a US holiday
[15:32] <jdstrand> (so I'm off)
[15:40]  * cachio_ lunch
[15:43] <mvo> jdstrand: thanks for letting us know
[15:46] <mup> PR snapd#4685 closed: interfaces/time-control,netlink-audit: adjust for util-linux compiled with libaudit - 2.31 <Critical> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4685>
[15:49] <jdstrand> mvo: thanks for fixing up 4685 and getting it in! :)
[15:49]  * jdstrand merges master for the 2.31 policy updates PR
[15:49] <jdstrand> err
[15:49] <jdstrand> merges release/2.31
[15:49] <mvo> jdstrand: yeah, please do! thank you
[15:52] <jdstrand> mvo: and sorry for the go fmt. /me slaps wrist
[15:52] <mvo> jdstrand: no problem
[15:52] <mvo> jdstrand: it tells more about the (sad) state of the tests than about you
[15:53] <mvo> jdstrand: but we will make them better again
[15:53] <mvo> actually we will make them great again!
[15:53] <jdstrand> I fiddle with the policy so much which isn't affected by that and I typically run the unit test and sometimes forget the full ./run-checks
[15:53] <jdstrand> I think it says something about me :)
[15:53] <mvo> jdstrand: np - its an easy fix
[15:53] <jdstrand> and you for fixing it for me :)
[15:53]  * mvo hugs jdstrand 
[15:53]  * jdstrand hugs mvo :)
[15:54] <jdstrand> that AF_CONN commit was interesting
[15:54] <jdstrand> socket(0x7b, ...)
[15:54] <mvo> jdstrand: yeah, that looked interessting
[15:54] <jdstrand> 0x7b?
[15:54] <jdstrand> :)
[15:54] <jdstrand> but then it all made sense when I realized it was encapsulated
[15:55] <jdstrand> and why it would never be the kernel
[15:57]  * mvo nods
[15:58] <jdstrand> bi in*
[15:58] <jdstrand> man
[15:58] <jdstrand> be in*
[15:58] <jdstrand> I think I am ready for the weekend :)
[15:58] <mvo> jdstrand: lol - I know exactly what you mean :-D
[15:59] <diddledan> https://www.youtube.com/watch?v=kfVsfOSbJY0
[15:59]  * diddledan hides
[16:00] <jdstrand> diddledan: hahaha
[16:00] <jdstrand> that is *terrible* :P
[16:00] <diddledan> :-p
[16:00] <diddledan> I aim to please
[16:00]  * jdstrand is still chuckling
[16:03] <zyga> bibi bop
[16:04] <mborzecki> diddledan: https://distrowatch.com/table.php?distribution=rebeccablackos
[16:05] <diddledan> IIRC that was the first distro to ship wayland ootb
[16:06] <mborzecki> omg https://sourceforge.net/p/rebeccablackos/activity/?page=0&limit=100#5a86d2213241d2526d18ca96 last commit 3 hours ago
[16:06] <zyga> on sourceforge!?!
[16:07] <diddledan> does anyone actually use sourceforge these days?
[16:07] <mborzecki> rebeccablackos guys do apparently :)
[16:07] <diddledan> (actually supertuxkart does - as I discovered while trying to get downloads for the snap)
[16:09] <diddledan> you can't point snapcraft at a sourceforge download url. it will download an html page instead even if you used the "direct link" url, because omg adverts
[16:10] <mborzecki> dl.sourceforge.net does not work anymore?
[16:12] <diddledan> I couldn't get anything to work, and there wasn't much information on other people getting automated downloads working
[16:13] <mvo> jdstrand: are you merging 2.31 into policy-updates-xxv-2.31 or shall I ? sorry for being a bit pushy, I want to do a bionic upload before my EOD :)
[16:13] <diddledan> I saw anecdotal statements that suggest that sf does user-agent sniffing so if snapcraft pretends to be wget it might work
[16:14] <mborzecki> diddledan: yocto uses a weird mix: https://paste.ubuntu.com/p/Nds4R5T3d6/ but I don't recall if the downloader teaks user-agent string, probably not (it used to be wget in the past btw)
[16:24] <mcphail> diddledan: the nextcloud snap uses sourceforge for the boost source code
[16:24] <diddledan> hmm
[16:24] <diddledan> what was I doing wrong then?
[16:25] <mcphail> maybe it has changed. My nextcloud snap repo is very very stale. But it built when I last tried it
[16:25] <jdstrand> mvo: I am. I was running run-checks :)
[16:25] <jdstrand> and then got pinged
[16:25] <jdstrand> and asked to look at something
[16:25] <jdstrand> etc
[16:25] <jdstrand> etc
[16:25]  * jdstrand is on it :)
[16:28] <mvo> jdstrand: cough - already done
[16:28] <mvo> jdstrand: sorry for being (yet again) too impatient
[16:30] <jdstrand> mvo: oh heh. well, I repushed after pulling
[16:30] <mvo> jdstrand: thats fine, no worries
[16:30] <mvo> jdstrand: travis is handing out slots slowly today anway :/
[16:32] <jdstrand> mvo: so, other than nursing that PR, I don't have anything planned for 2.31.1
[16:32] <jdstrand> (fyi)
[16:33] <jdstrand> I picked up a new item in the forum today, but not worth respsinning everything
[16:34] <mvo> jdstrand: sounds good, if anything last minute comes up please just ping me - the plan is to have 2.31.1 on monday for beta and 2.31 (.0) in stable monday
[16:34] <mvo> (and 2.31.1 a week later in stable)
[16:39] <jdstrand> mvo: right. trying not to interfere with any of that, and ack
[16:39] <mvo> jdstrand: :) ta
[17:05]  * zyga goes to do taxes, ttyl
[17:06] <zyga> (and enjoy your weekends!)
[17:06] <Chipaca> zyga: you too
[17:06] <Chipaca> enjoy your taxes!
[17:06] <Chipaca> :-p
[17:16]  * kalikiana wrapping up for the week
[17:33]  * Chipaca whacks spread on the head with some stale bread
[17:36] <diddledan> in bed
[17:36] <diddledan> with a disembodied head
[17:36] <diddledan> dammit, I used head a second time
[17:37] <diddledan> how about "with a lump of lead"
[17:40] <Chipaca> diddledan: that's leadership
[17:42] <Chipaca> zyga: when you've whacked your taxes enough, I was wondering why findUid in snap-seccomp returns a uint64
[17:42] <Chipaca> (when uids are uint32)
[17:42] <Chipaca> (but only if you're doing things right)
[17:56] <mup> Issue snapcraft#1932 opened: Revamp tests that verify correct utility is being used (deb/snap/docker) <Created by kyrofa> <https://github.com/snapcore/snapcraft/issue/1932>
[17:56] <mup> PR snapcraft#1910 closed: tests: expect in-snap unsquashfs when using docker <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1910>
[17:58] <Chipaca> mwhudson: go in 1.10/beta is older than 1.10/candidate, which is a little surprising; is this on purpose?
[18:12]  * mvo is slightly sad that the two 2.31 PRs still did not get a travis slot :(
[18:16]  * Chipaca pushes more PR to make mvo sadder
[18:17] <Chipaca> or I could grab a beer
[18:19]  * mvo considers tea
[18:20]  * Chipaca hugs mvo
[18:22]  * mvo hugs Chipaca 
[18:33] <brunosfer> Hi guys! I'm building a snap that needs access to bluetooth sdp however I can't figure out what configs I have to make in the snapcraft.conf to make /var/run/sdp appears on the system.
[18:34] <brunosfer> I mean snapcraft.yaml file
[18:36] <Chipaca> brunosfer: that sounds like a topic for the forum, to me
[18:43] <brunosfer> chipaca: true! I've done that Dec 17th and I'm still struggling here... https://forum.snapcraft.io/t/failed-to-connect-to-sdp-server-permission-problem/3085
[18:47] <Chipaca> brunosfer: huh, looks like nobody saw that
[18:48] <Chipaca> niemeyer: is there a way to 'bump' a post that got no replies, so it's close to the top again? without just answering gibberish on it i mean
[18:48] <Chipaca> ah he's probably asleep
[18:48] <Chipaca> brunosfer: man, you've waited two months
[18:50] <Chipaca> brunosfer: is there any more info you can add to that? this'll serve the double purpose of bringing it to the top so people see it, and adding more context for people that know thiss tuff
[18:50] <Chipaca> brunosfer: (OTOH it's friday and europe and large chunks of asia have mostly checked out for the weekend already)
[18:52] <niemeyer> Chipaca: I'm afraid not, on both counts
[18:52] <niemeyer> Chipaca: The traditional way is indeed to ping
[18:53] <Chipaca> niemeyer: np
[18:53] <Chipaca> i feel bad that that's sat unanswered for two months :-(
[18:53] <Chipaca> but i don't know the answer (i can barely understand the question :-) )
[18:53] <Chipaca> ogra_: you gone?
[18:55] <brunosfer> chipaca: I've been developing my snap from scratch but I knew that was a problem when I was trying to set up a regular connection using bluetooth. But now I hava everything done and I'm stuck on that problem.
[18:56] <Chipaca> brunosfer: do you see any denials in the logs?
[18:56] <brunosfer> chipaca: I'm going to add more information on the forum, hoping to get some solution, I'm on a 2 week streak trying to get this up and I can't figure it out...
[18:57] <diddledan> if you don't have them try adding network and/or network-bind
[18:58] <diddledan> although being a bluetooth specific thing I am not expecting that'll help
[18:58] <Chipaca> jdstrand: is there a forum post about figuring out denials? i thought there was but i can't find it now
[18:59] <diddledan> `snappy-debug.security scanlog`
[18:59] <jdstrand> yeah
[19:00] <diddledan> brunosfer: did you add and connect either or bluetooth-control or bluez?
[19:00] <diddledan> of*
[19:00] <jdstrand> Chipaca: https://forum.snapcraft.io/t/security-policy-and-sandboxing/554
[19:02] <Chipaca> jdstrand: thanks
[19:02] <jdstrand> Chipaca: I suspect Debugging and Tips are what you're after
[19:02] <jdstrand> (two different sections)
[19:02] <brunosfer> diddledan: I created a slot that is connected to both services you mentioned
[19:03] <diddledan> no, a plug
[19:03] <diddledan> the slots for those two are provided by core
[19:10] <brunosfer> diddledan: could you give an example of how would you connect a plug to those slots?
[19:11] <diddledan> in your `apps:` section for an app add to `plugs:` an entry for each, e.g. `plugs: [bluetooth-control, bluez]`
[19:12] <diddledan> then it's just a case of rebuilding the snap and running `snap connect your-snap:bluetooth-control` and `snap connect your-snap:bluez` (once you've installed the new build)
[19:14] <diddledan> bluetooth-control is for kernel interactions with the bluetooth device(s) where bluez is a library/daemon which marshalls communication, so depending on which method your app uses to interact you'll only need one of them
[19:15] <diddledan> their descriptions, what little there is of them, is at https://docs.snapcraft.io/reference/interfaces
[19:15] <diddledan> there's not much more than I've already stated though
[19:15] <brunosfer> diddledan: thanks for the help. I'm going to try that ;)
[19:19] <diddledan> there can only be one `plugs` list per app in the `apps:` block, so you might (read: are likely to) need to merge with the one already there
[19:49] <mup> PR snapd#4675 closed: timeutil: fix scheduling on nth weekday of the month <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4675>
[19:49] <mup> PR snapd#4688 closed: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al - 2.31 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4688>
[19:52] <jdstrand> mvo: thanks! :)
[19:52] <mvo> jdstrand: thank you!
[19:53] <jdstrand> :)
[19:54] <kyrofa> Chipaca, you still around?
[20:10] <brunosfer> diddledan: Yes I just did that, however when I do `snapname.sdptool browse local` it shows that sdp is missing permissions.
[20:11] <diddledan> hmm
[20:11] <diddledan> I wonder what permissions it wants
[20:11] <brunosfer> diddledan: sdp file /var/run/sdp file doesn't exist.
[20:12] <diddledan> it might be possible to configure that to go to $SNAP_DATA or $SNAP_USER_DATA
[20:12] <diddledan> it'll need sdptool to play ball though
[20:13] <brunosfer> diddledan: To solve this issue on Ubuntu Artfull I do chmod 777 /var/run/sdp
[20:13] <brunosfer> diddledan: However here that file doesn't exist.
[20:31] <Chipaca> cachio__: you around?
[20:31] <Chipaca> kyrofa: I am still around (now)
[20:32] <Chipaca> (was having dinner and watching steven universe with the boys)
[20:32] <cachio__> Chipaca, yes
[20:32] <kyrofa> Chipaca, you answered me in the forum, no problem :)
[20:32] <Chipaca> cachio__: do you know, during sru validation, whether core is from stable or edge?
[20:32] <Chipaca> kyrofa: i am awesome, i am
[20:32] <kyrofa> Indeed you are
[20:32] <cachio__> Chipaca, we update from stable
[20:33] <cachio__> Chipaca, and use the stable which is in proposed
[20:33] <cachio__> Chipaca, why?
[20:33] <Chipaca> cachio__: proposed isn't a channel though, you mean candidate?
[20:34] <Chipaca> cachio__: the core snap, not snapd
[20:34] <cachio__> Chipaca, the core snap is the one in stable
[20:34] <Chipaca> I could always leave it as is, and know it'll break the first time you do sru validation :-)
[20:34] <Chipaca> cachio__: ah, perfect, i'll set it to test that then
[20:35] <cachio__> Chipaca, nice, just ping me if you need any help
[20:38] <Chipaca> kyrofa: I'll also be updating the forum post once the PR's in
[20:38] <Chipaca> (currently running tests on a different PR, then i'll do that one, and one further, and then i'll call it a month)
[20:38] <mup> PR snapcraft#1933 opened: schema: remove underscore from version pattern <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1933>
[20:40] <kyrofa> Chipaca, you're out for a few weeks? Nice
[20:40] <kyrofa> Anything fun?
[20:40] <mup> PR snapd#4697 closed: osutil: refactor EnsureFileState to separate out the comparator <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4697>
[20:45] <Chipaca> kyrofa: no, i'm just wishing we were at eom already
[20:45] <kyrofa> Hahaha
[20:50] <mup> PR snapd#4698 opened: snap: remove underscore from version validator regexp <Created by chipaca> <https://github.com/snapcore/snapd/pull/4698>
[20:53] <zyga_> Chipaca I don't remember, we probably fished that code from future golang and that was the type that was used but perhaps I'm mistaken
[20:55] <Chipaca> niemeyer: are you _still_ here ?
[21:00] <zyga_> Chipaca taxes done
[21:00] <zyga_> now dinner time
[21:00] <Chipaca> zyga_: :-)
[21:00] <zyga_> how's stuff ?
[21:00] <zyga_> Chipaca ohhh
[21:00] <zyga_> underscores
[21:00]  * zyga_ has horror memories from 15.04
[21:01]  * Chipaca nods
[21:01]  * Chipaca __nods__
[21:01] <__chip__> oh know what have you done
[21:01] <zyga_> Chipaca remember when I joined and there was some obscure part of data that was only conveyed through a filename that used undesrcore encoding
[21:01] <zyga_> *underscore
[21:02] <zyga_> when we were just starting with interfaces I had issues with switching the whole code over to that
[21:03] <zyga_> because of this obscure thing that was used as a way to communicate
[21:03] <zyga_> I think it was services and udev related
[21:03] <zyga_> it was soooooo weird back then
[21:03] <zyga_> man, I don't want to remember that code anymore
[21:05] <zyga> jdstrand I see you
[21:05] <zyga> http://blog.dustinkirkland.com/2018/02/10-amazing-years.html
[21:06] <__chip__> zyga: developer namespace
[21:06] <zyga> is that you on the right there?
[21:18] <mup> PR snapcraft#1934 opened: catkin plugin: support recursive rosinstall files <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1934>
[21:46] <Chipaca> man, if I'd gotten a second +1 on #4659 i could land it and deconflict the smaller, easier one
[21:46] <mup> PR #4659: snap: improve the version validator's error messages <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/4659>
[21:53] <zyga> doing
[21:53] <zyga> aww, I already looked
[21:53] <zyga> Chipaca I can give you +1
[21:53] <Chipaca> zyga: you already did
[21:54] <zyga> merge it :)
[21:54] <zyga> it's easier to ask for forgiveness
[21:54] <mup> PR snapcraft#1935 opened: elf: contemplate more patching scenarios <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1935>
[21:54] <zyga> especially on fun and good features
[21:55] <Chipaca> zyga: :-)
[21:55] <Chipaca> we should change it to "2 +1s or 1 +1 from all those awake"
[21:56] <jdstrand> zyga: oh, hehe
[21:56] <zyga> Chipaca jdstrand will give you a +1
[21:56] <zyga> ;-)
[21:56] <Chipaca> oooohhhh
[21:56] <Chipaca> the most secure error messages! \o/
[21:58] <Chipaca> zyga: OTOH RFC PRs don't make much sense if I'm not going to wait for comments
[21:59] <zyga> true
[21:59] <zyga> maybe time to EOD? :-)
[22:00] <pedronis> Chipaca: that sort of detailed errors would make more sense if snapcraft used this for validation
[22:00] <Chipaca> pedronis: I hope to get us there soon
[22:00] <niemeyer> Chipaca: Sort of :)
[22:01] <niemeyer> Chipaca: Anything I can help with?
[22:01] <Chipaca> i mean, that's the plan, right? have 'snap pack' be its own standalone tool (that works cross-platform)? and it might as well validate as well
[22:01] <niemeyer> Yeah, that's indeed the plan
[22:01] <Chipaca> niemeyer: it was about snap info alignment, but it wasn't important or I'd remember more
[22:02] <niemeyer> Chipaca: Ack :)
[22:02] <Chipaca> I'd like to get that working soon, fwiw
[22:02] <Chipaca> but not today :-)
[22:02] <niemeyer> The good news is that Spread just managed to allocate 50 machines in a blast
[22:02] <niemeyer> The bad news is that it allocated 28 more too :P
[22:03] <zyga> wow, we're all heere
[22:03] <zyga> on friday
[22:03] <kyrofa> Here's mvo?
[22:03] <kyrofa> Where's*
[22:05] <niemeyer> Sleeping or enjoying his family, I hope!
[22:05] <jdstrand> Chipaca: done
[22:06] <jdstrand> and with that
[22:06] <jdstrand> see you Tuesday :)
[22:06] <Chipaca> jdstrand: thank you :-)
[22:06] <Chipaca> jdstrand: have a good one
[22:06] <jdstrand> you too :)
[22:07] <niemeyer> Okay, I have a good case to debug when I'm back, but now I really need to do something else for a while..
[22:07] <niemeyer> Have a good weekend all
[22:07] <Chipaca> niemeyer: you too dude, get some sleep
[22:08] <jdstrand> bye niemeyer :)
[22:08] <mup> PR snapd#4659 closed: snap: improve the version validator's error messages <Blocked> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4659>
[22:52] <mup> PR snapd#4699 opened: cmd/snap: tweaks to 'snap info' output <Created by chipaca> <https://github.com/snapcore/snapd/pull/4699>
[23:19] <nacc> niemeyer: c-n-f on bionic now emits a snap related warning
[23:19] <nacc> error: unknown command "advise-snap", see "snap --help"
[23:19] <nacc> fix already in progress/available/
[23:19] <nacc> ?
[23:20] <nacc> not sure if anyone else from snappy is around, oh well
[23:21] <mup> PR snapcraft#1936 opened: storeapi: handle errors even for >400 responses <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1936>
[23:39] <mup> PR snapd#4681 closed:  testutil: add File{Matches,Equals,Contains} checkers <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4681>
[23:41] <mup> PR snapd#4698 closed: snap: remove underscore from version validator regexp <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4698>
[23:41] <Chipaca> nacc: huh
[23:41] <Chipaca> nacc: how're you getting that?
[23:42] <nacc> Chipaca: wheneve c-n-f tries to run
[23:42] <Chipaca> how, not when :-)
[23:42] <Chipaca> nacc: do you have any snaps installed?
[23:42] <nacc> Chipaca: typing any not existing command i mean
[23:42] <nacc> Chipaca: sure
[23:42] <nacc> core git-ubuntu
[23:42] <Chipaca> nacc: what version is your core ?
[23:42] <nacc> 16-2.30
[23:43] <Chipaca> (beyond that, it's obviously a bug because the idea was to c-n-f to skip it if it failed)
[23:43] <nacc> Chipaca: i can file one if you like; perhaps i'm due for a reboot?
[23:43] <Chipaca> nacc: nah, can you try using 'candidate'?
[23:43] <nacc> Chipaca: for core?
[23:43] <Chipaca> nacc: snap refresh core --candidate
[23:43] <Chipaca> yes
[23:43] <nacc> one sec
[23:46] <nacc> Chipaca: fixed
[23:47] <nacc> Chipaca: will that roll out soon? i'd rather not track candidate unless i need to
[23:47] <Chipaca> nacc: yes
[23:47] <nacc> Chipaca: ok, thanks!