[01:59] PR snapd#4688 opened: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al - 2.31 [02:12] PR snapd#4689 opened: tests: new spread test for kvm interface [02:23] 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] crumbles: that's up to the plugin, presumably [05:57] morning [06:52] mvo: morning [06:53] mvo: i see that travis jobs on master is passing now [06:55] mborzecki: oh, interessting - its failing badly in 2.31 [06:56] mvo: afaik it needs this https://github.com/snapcore/snapd/pull/4685 [06:56] PR #4685: interfaces/time-control,netlink-audit: adjust for util-linux compiled with libaudit - 2.31 [06:57] mvo: something weird, master tip built failed with some random store related faiilure, restarted it and waiting for results [06:58] mvo: but jdstrand's PR on 2.31 fails for some totally unrelated reasons [06:58] mborzecki: yeah, thats what I mean, 2.31 is in a really unhappy state and its not clear why [06:59] mvo: maybe something new in core from edge? [06:59] mborzecki: yeah, must be something external, still super strange [06:59] let me run that pr from spread [07:02] 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] + test-snapd-timedate-control-consumer.hwclock-time -r -f /dev/rtc [07:03] execl failed: No such file or directory [07:03] hmm maybe somthing wrong with patht ot snap-confine/snap-exec [07:04] mvo: debian does not reexec right? [07:04] mborzecki: it does not currently [07:04] mborzecki: oh, its related to /lib/udev/snappy-app-dev - but that should still be there in 2.31 [07:06] mborzecki: aha, I get it - core no longer has /lib/udev/snappy-app-dev [07:06] hah [07:06] mborzecki: the core snap - we need to symlink it [07:06] mborzecki: yay, mystery solved! [07:06] so many moving parts :) [07:08] mborzecki: indeed [07:08] PR snapcraft#1926 closed: Release changelog for 2.39.1 [07:25] PR snapd#4690 opened: packaging: provide a compat symlink for snappy-app-dev [07:27] mborzecki: ^- should fix things. [07:28] mvo: missing newline at the end, otherwise +1 [07:30] o/ [07:30] mborzecki: meh, indeed [07:30] zyga: hey [07:31] force-pushed the \n [07:31] hey, sorry for being so late folks, I feel a bit off today [07:57] good morning [07:57] o/ zyga [07:57] hey kalikiana, how are you doing? [07:57] good morning kalikiana [07:58] * zyga has a headache today, pretty unusual for him [07:58] I feel like I'm the conductor of a bug triaging train this week... all I'm missing is the hat [07:58] kalikiana haha, that's awesome :) [07:59] 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] nice :) [08:01] I don't think I have any though, it's sandwich day everyday [08:06] PR snapd#4691 opened: cmd/snap: use proper help strings for `snap userd --help` [08:06] mvo: ^^ may be a 2.31 material too [08:07] btw. 4691 is trivial review so if anyone could take a look :) [08:08] ack [08:08] btw. there's also a file cmd_shell.go, does not appear to be used at all [08:09] gometalinter throws: cmd_shell.go:33:1⚠️ cmdShell is unused (deadcode) [08:09] mborzecki let's remove it [08:10] mborzecki can you also fire that tool on osutil [08:10] zyga: is it something that predates snap run --shell? [08:10] I suspect there are some unused bits for mounting related tasks [08:11] mborzecki: aha, thanks [08:11] mborzecki: great job [08:44] hmm, tests are not in a happy place [08:44] PR snapd#4692 opened: cmd/snap: linter cleanups [08:44] trivial PR ^^ [08:45] mvo do we need https://github.com/snapcore/snapd/pull/4690 for 2.31? [08:45] PR #4690: packaging: provide a compat symlink for snappy-app-dev [08:46] mborzecki: thanks for the cleanups [08:46] zyga: we don't need it in 2.31, just in master [08:46] ok [08:46] zyga: 2.31 still has the old path [08:46] zyga: and we need travis slots :/ [08:46] let's hold on with new PRs [08:46] until that one lands [08:46] yeah [08:48] uhh, sorry, i've take a couple of slots recently [08:58] zyga: have you looked at https://github.com/snapcore/snapd/pull/4682 ? wonder what will happen if you poke that address [08:58] PR #4682: tests: new spread test for physical-memory-control interface [09:00] woah [09:00] nothing good will happen [09:00] that's a weird address to poke [09:00] I don't understand that test TBH [09:01] moin [09:01] Chipaca: morning [09:02] Chipaca: how are you keyboardio typing skills today? [09:03] I'm only typing a few minutes a day on it until I get used to it [09:03] Hella slow [09:05] That was all typed on the butterfly as was this [09:05] but this is top speed [09:05] 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] keyboardio must be a whole new level [09:08] the thing that most catches me out is space being only on one side [09:09] when I think "space", the nearest thumb twitches [09:09] man t [09:09] man those quotes were hell to type :-) [09:09] you can remap the keys though, right? [09:10] ah, yes, probably? but that's not my problem, just that i have never trained to use my pinkies [09:10] my typing is self taught [09:10] and, mostly two fingers (maybe 2.5) and thumbs, [09:11] so using my whole hand is going to need some time [09:11] (i'm now back on the regular qwerty) [09:11] in my defense, there was no way my 12-year-old pinkies could move the commodore's keys [09:12] mvo: morning sah [09:12] Chipaca: good morning [09:12] mvo: tell me more about this magic realism^W^W ast thing [09:13] 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] mvo: I _could_ make it a general thing, move it to testutils and add tests [09:14] 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] mvo: if you think it's worth it :-) [09:14] Chipaca: maybe not [09:14] Chipaca: I was mostly wondering [09:14] mvo: well, we'll find out it isn't working easier than we find out it is [09:14] er [09:15] 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] it's very restrictive [09:15] Chipaca: ok, that sounds good then [09:15] if we create a function that returns *Commands and use that it'll fail for example [09:16] 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] Hello snapping people [09:16] mvo: should I add a high-level comment with this? otherwise we'll forget why it was ok :-) [09:16] niemeyer: go to bed niemeyer you're asleep [09:17] hey niemeyer ! you are up early! [09:17] niemeyer: hello, you're up early [09:17] Heya! [09:17] Chipaca: hah found a diy one https://docs.keeb.io/iris-build-guide.html [09:17] I've been awake for about 6h now.. sleep is indeed catching up a bit by now [09:18] mborzecki: heh. Give keyboard.io's blog a read sometime, it's fun [09:18] The good news is we have a working spread in GCE [09:21] * Chipaca hugs niemeyer [09:21] running spread against qemu on my old laptop that no longer likes having 8gigs is torture [09:24] Chipaca: Aw.. [09:24] Chipaca: Although I haven't managed to run anything realistic yet, I can already tell that the networking does make a difference [09:25] niemeyer: \o/ [09:25] I have secret hopes of pushing the suite below 20 minutes soon, but it's a bit early to tell yet [09:27] PR snapd#4690 closed: packaging: provide a compat symlink for snappy-app-dev [09:30] whee, thank you mvo [09:30] zyga: yw, I build a new core now, then things should be normal again [09:38] * kalikiana coffee [09:40] github, you so broken [09:40] mvo: Do we actually have snappy-app-dev inside /lib/snapd now? [09:41] niemeyer: yes [09:41] niemeyer: that PR got merged a couple of days ago so that bases work correctly there [09:42] mvo: I was just hoping for a better name on the transition, but probably too late [09:42] snappy-app-dev is bad on every token.. :) [09:43] niemeyer: uh, sorry, was not aware of this desire. we can still do this [09:43] mvo: I probably never mentioned because it was a legacy piece [09:43] niemeyer: if you have a good name I am happy to make it happen [09:43] niemeyer: there is also a desire to rewrite it or integrate it into snap but that is orthogonal to some extend [09:45] mvo: I was just hoping to get it somewhat closer to its purpose, and less enigmatic [09:46] PR snapd#4691 closed: cmd/snap: use proper help strings for `snap userd --help` [09:47] niemeyer: happy about suggesitons - snap-udev-helper? [09:47] niemeyer: should be easy enough and best to do it now instead of having yet another transition [09:49] mvo: That sounds good [09:49] mvo: How is that tool called? From within a udev rules file? [09:49] niemeyer: yes, also from snap-confine [09:51] mvo: Cool, sounds good [09:52] 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] niemeyer: we could also use "snap-devices-helper" to be more generic [09:55] mvo: Ah, even better! +1! [09:55] mvo: Perhaps singular: snap-device-helper [09:55] niemeyer: sounds good, I work on this now [09:57] mvo: Perhaps even just "snap-device".. in theory most of the things inside lib/snapd are helpers [10:08] PR snapd#4673 closed: interfaces/mount: generate per-user mount profiles [10:09] PR snapd#4692 closed: cmd/snap: linter cleanups [10:13] 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] PR snapd#4687 closed: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al [10:17] mborzecki question about --timer=... on commands [10:17] are such commands exported in /snap/bin? [10:17] and what is the --timer=%q part for (in LauncherCommand) [10:17] yes [10:18] mborzecki hmm, what is that for? [10:18] why would the user wish to have a timer on their path [10:18] zyga_: --timer is the schedule given service runs with;, eg --timer="mon,10:00~12:00,,fri,13:00" [10:20] what I don't understand is why do we want to put a command on path [10:20] 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] PR snapd#4693 opened: many: rename snappy-app-dev to snap-device-helper [10:20] Chipaca: heh :) I'm not sure what happend but I'm glad you are fixing stuff [10:20] mborzecki are we doing that because our timer syntax is richer than that of systemd? [10:21] PR snapcraft#1929 opened: sources: proper errors for invalid handlers [10:21] mvo: found a way of making the current implementation give a false negative, fixed it and adding tests [10:21] zyga_: yes, at least the --timer part is for this [10:21] * Chipaca bows before mvo's greater wisdom [10:21] mborzecki would that still work if the command was not on path (not in /snap/bin) === zyga_ is now known as zyga [10:22] Chipaca: lol - I just like asking silly questions [10:22] suuure [10:22] zyga_: yeah, probably if i tweak snap run it would, but why would you do that? [10:24] mborzecki mainly because I don't see why I would like to have timers on path [10:24] it's an implementation detail (typically) [10:24] and since the timer unit can just say "snap run ... " [10:24] there's no real need for that command to be exposed [10:26] zyga: hmm ok, i need to how to invoke it, can you leave a comment in the PR? [10:26] sure [10:26] I'm going through that now [10:26] thanks [10:27] PR snapd#4679 closed: systemd: add default target for timers [11:06] niemeyer: are you still amongst us? [11:06] Chipaca: I shall be [11:07] 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] i.e. wrap some of the columns if the thing is too wide, but only if a user is looking at it [11:07] (i have a change request that will make it wider) [11:10] Chipaca: The output we have right now is quite nice.. what else do we need there at the moment? [11:10] niemeyer: remember 'Tracking'? [11:11] Chipaca: Without further details, my temptation would be to argue to keep it nimble instead of making it larger [11:11] 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] mborzecki can you look at https://github.com/snapcore/snapd/pull/4675#pullrequestreview-97145880 please [11:14] PR #4675: timeutil: fix scheduling on nth weekday of the month [11:15] PR snapd#4693 closed: many: rename snappy-app-dev to snap-device-helper [11:16] mvo do you know what is going on in 2.31 release branch [11:17] 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] 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] zyga: its failing because snap-confine cannot execl /usr/lib/udev/snappy-app-dev [11:18] zyga: which appears to happen inside the core snap [11:19] zyga: but its strange because our tests modify the core snap so maybe soemthing there [11:19] mmmm, is is perhaps related to the stale apparmor profile bug [11:19] zyga: probably not, its not a eaccess, its a not-found [11:19] aha [11:19] ok [11:20] 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] kk [11:42] im not on this mtg [11:42] * koza hates focus follows mouse [11:44] PR snapd#4694 opened: cmd/snap-update-ns: small refactor for upcoming per-user mounts [11:46] Chipaca *nice* testing helpers [11:47] zyga: ik,r? [11:47] zyga: yeah, he rocks [11:47] and also for making them useful across the tree! [11:55] Chipaca review on 4681 [11:55] can i build snaps form github [11:55] great work there [11:55] cuz atm on page it says failing [11:55] https://github.com/snapcore/snapd [11:55] Gnjurac hey, sure you can, have you seen snapcraft.io? [11:56] yep [11:56] but i am on voidlinux [11:56] so no snap in repo [11:56] you are building snapd, not a snap package ? [11:56] you can hook up your github repository to snapcraft.io and have it built automatically [11:57] 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] i want snapd so i can install snaps [11:58] apps [11:58] ah. ok [11:58] you will need the golang stack, a C compiler and some basic libraries, [11:59] at runtime you will likely need systemd [11:59] what kind of issues are you running into now? [11:59] zyga, void uses "runit" not systemd ... [11:59] yes, I read [11:59] that might be a bit more work :) [12:00] Gnjurac I can help you out [12:00] hmm meybe too much work for newbie like me, guess i will post request for it on github [12:00] Gnjurac but you have to do the work :) [12:01] zyga: really? [12:01] I can just offer help and ideas [12:01] i am willing [12:01] I think not having systemd is a major issue though [12:01] have time [12:01] is systemd an option or is it just not packaged? [12:01] no systemd [12:01] at all [12:02] void use runit [12:02] does runit provide systemd-like shim so that software written for system can run on top? [12:03] hmm duno like i say am newb , i know i can just add services in runit and thats all [12:04] 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] http://smarden.org/runit/ [12:05] hmm ye i am thinking that same [12:05] anyway do you maybe have dotnet installed? [12:05] or mono [12:05] i need msbuild binary [12:07] Gnjurac I see some chatter about dotnet snaps on the forum (forum.snapcraft.io) [12:07] and I see there si a dotnet-sdk snap currently in the edge channel [12:08] you may want to check with the people interacting with those forum topics [12:15] PR snapcraft#1928 closed: tests: remove duplicate tests [12:18] PR snapd#4695 opened: wrappers: generator for systemd OnCalendar schedules [12:23] mborzecki quick feedback done [12:23] thanks [12:41] mvo: hey so regarding ubiquity and the store login, using the chroot is not possible [12:41] https://github.com/snapcore/snapd/pull/4694/files needs a trivial review [12:41] PR #4694: cmd/snap-update-ns: small refactor for upcoming per-user mounts [12:42] 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] mvo: would be possible to add a way to seed login keys in some way? [12:48] zyga_: can you point me at a test where you'd use a FileState checker if it existed? [12:48] i might as well add it while i'm there, but not without a concrete use case [12:48] I don't use any such checker yet [12:48] otherwise it's just wankery :-) [12:48] nah, ignore me [12:48] I will try that myself and see if it's sensible [12:48] zyga_: let me push a little refactor that should make it trivial [12:48] but I think some tests could compute the file state and check if it was applied this way [12:49] an interface maybe? === zyga_ is now known as zyga [12:50] PR snapd#4696 opened: wrappers: timer services [12:52] 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] zyga: https://github.com/snapcore/snapd/pull/4697 [12:54] PR #4697: osutil: refactor EnsureFileState to separate out the comparator [12:54] mmm [12:54] mmm, or hmmm? [12:54] PR snapd#4697 opened: osutil: refactor EnsureFileState to separate out the comparator [12:55] +1 nice [12:55] it was just "mmm, looking" [12:56] this made me realise we could improve the case where content matches but mode doesn't [12:56] there is, of course, a problem with os.IsNotExist [12:56] :-) [12:57] I don't know what it says about me that I drill in to the silly corner cases [12:57] 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] yeah, that's fine [12:58] ok :-) [13:18] mvo: you siad /usr/lib/udev/snappy-app-dev. did you mean /usr/lib/snapd/snappy-app-dev? [13:19] jdstrand can you give me a quick +1 on trivial 4694 please === zyga_ is now known as zyga [13:19] let me look [13:20] 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] zyga: how does this relate to the one check I requested that was keeping 3963 from landing? [13:24] jdstrand it's related, I'll implement the check [13:24] I think you said something about being able to be race free? [13:24] 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] but maybe that was for something else [13:24] it was for that, I'm experimenting (still) [13:24] 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] 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] I'll be patient and wait for the big reveal :) [13:25] if it works you'll see, if it fails I'll tell you the idea [13:25] hehe ok :) [13:26] holly crap, some of this rocks :-) [13:26] jdstrand i think the linux kernel is amazing and so full of weird features I'm really afraid [13:27] heh [13:27] PR snapd#4694 closed: cmd/snap-update-ns: small refactor for upcoming per-user mounts [13:27] PR snapcraft#1930 opened: lxd: friendly errror with suggestions if network is broken [13:28] jdstrand so, I wasn't aware you can reach across mount namespaces [13:28] this easily [13:28] without setns [13:28] you can go to /proc/pid/root and lo and belhod, it's there [13:28] so [13:35] zyga: hmm [13:36] that seems like it might go against a design constraint [13:36] (of ours) [13:36] it behaves oddly though [13:37] yeah, with mount namespaces and pivot_root... [13:39] this is what I was thinking of: https://github.com/snapcore/snapd/pull/4329/commits/7824fb1d4001e94121b5efd1644aa1af7599b906#r154192314 [13:39] PR #4329: cmd/snap-confine: discard stale mount namespaces (v2)