[05:57] morning [06:06] PR snapd#4269 closed: timeutil: new refresh timer parser [06:45] mvo: morning [06:47] hey mborzecki, good morning! [06:48] mvo: did you have your morning coffee? because I need some help right here https://github.com/snapcore/snapd/pull/4296#discussion_r153116179 [06:48] PR #4296: packaging/arch: pre-create snapd directories when packaging [06:49] mborzecki: sure, let me have a look. I had my cup of morning tea (Hainan Bai Cha Lu which I can hightly recommend ;) [06:50] mborzecki: haha, yeah, its confusing because snapd creates dirs on demand so if we don't update the dirs files we don't notice [06:50] mborzecki: I think you are on the right track, i.e. lets make sure we get it right at least once [06:50] haha [06:51] are any of the directories listed specific for ubuntu package only? [06:53] umm, and /var/snap, it holds SNAP_DATA or SNAP_USER_COMMON? [06:55] mborzecki: yeah, we want this too [06:55] mborzecki: the dirs/dirs.go is the best source I think [06:55] mborzecki: because we use it for mocking in the tests pretty much everything is listed there [06:56] ok, i'll update the list for arch then along with some other fixes [06:56] mborzecki: sounds good, bonus points for a PR that also updates the other packaging :) [06:56] spread tests actually caught stuff like a missing manpage for snap, some missing dirs in /var/lib/snap [06:58] mborzecki: nice! [06:58] mborzecki: thanks again for doing those new arch tests [07:16] PR snapd#4300 opened: packaging/arch: install missing directories, manpages and version info [08:06] cjwatson, does LP snap building have a network prob ? https://launchpad.net/~snappy-hwe-team/+snap/wifi-connect-daily (seems there are proxy errors for git.lp.net) [08:07] pushed another set of fixes for spread with Arch, let's see how far we get this time [08:11] pstolowski: morning [08:11] mborzecki, hey! [08:16] hello [08:16] mvo: sorry for being late, my daughter is sick and I'm the parent that says at home [08:16] things are under control now so I'll get to work [08:22] zyga-solus: hey, sorry to hear about your daughter, hope she recovers quickly [08:23] mborzecki: just some fever [08:23] mborzecki: she wasn't sick in years so it's an event :) [08:24] mborzecki: it started (obviously) on Friday after the swimming pool, she's much better now [08:24] i suppose one of the downsices of coming back to polish climate [08:24] indeed [08:24] but they'd love to see some snow again [08:25] so the mood is very good [08:25] i remember i used to like playing in snow when i was a child [08:26] PR snapd#4300 closed: packaging/arch: install missing directories, manpages and version info [08:26] then i grew up and had to commute to work in the morning, in the snow:/ [08:26] mborzecki: she saw snow when she was maybe 6 or 5 [08:27] mborzecki: we went to a valley in the pyrenees :) [08:27] hahah [08:27] she cut her arm on some sharp ice [08:28] and keeps recalling that whenever we mention winter again :) [08:28] ouch [08:28] PR snapd#4294 closed: Mount with x-gdu.hide option [08:28] man, we're rocking at 20 PRs [08:28] and many more to land soon [08:28] https://github.com/snapcore/snapd/pull/4281 needs a 2nd review and is green [08:28] PR #4281: snapstate: support for pre-refresh hook [08:28] * ikey will be sending more once he's alive again.. [08:29] ikey: hey, thank you :) [08:29] your PRs are always welcome :) [08:29] merci :] [08:29] gotta work out how to get fedora nvidia happy [08:29] the new glvnd stuff [08:30] mvo: I wonder what to do about https://github.com/snapcore/snapd/pull/4140 -- I'll ask jdstrand for a look but it "feels" ready otherwise [08:30] PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service [08:30] ikey: I think (fortunately) everyone will use it eventually [08:31] (much better than dpkg alternatives or other voodoo) [08:31] yeah we have an open issue in solus for it too [08:31] we also have to do similar levels of magic filesystem butchery to make GL work [08:31] i.e. /usr/lib64/libGL.so.1: symbolic link to /usr/lib64/glx-provider/nvidia/libGL.so.384.98 [08:32] but we live in a post update-alternatives world :p [08:32] speaking of jdstrand - around today? [08:33] ikey: I cannot say, let me check [08:33] merci [08:36] ikey: he seems to be around today [08:36] ah cool [08:36] there is light at the end of the tunnel then ^^ [08:38] ikey: and it says "choooo chooo" [08:38] lol yeah [08:39] zyga-solus: yeah, I think we need a security review but I would love to merge it [08:39] mvo: indeed, I would like to wait for jdstrand [08:39] zyga-solus: re late> no worrie [08:39] s [08:42] * ikey blinks at the external repos forum thread [08:42] nitrux reasoning is uh, off, to say the least [08:43] they're insinuating that snapd-glib{,qt} isnt maintained [08:45] ikey: which thread is that? [08:46] https://forum.snapcraft.io/t/external-repositories/1760/144 [08:47] interesting, anyone used nitrux? what's special about this one? [08:47] it uses not-a-budgie [08:47] (the desktop looks like a qt/kde budgie) [08:47] and i think they do hardware stuff? [08:47] interesting [08:48] their page has some issues in ff through :( [09:27] mvo: do you know what is the status of https://github.com/snapcore/snapd/pull/3998 -- it feels like that's something on our plate now [09:27] PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features [09:28] mvo: let's talk about that at the standup perhaps? [09:28] mvo: and on the same vein: https://github.com/snapcore/snapd/pull/4049 -- this is clearly our game but I'd like to know your plans for it [09:28] PR #4049: debian,vendor: import github.com/snapcore/squashfs and use [09:29] zyga-solus: iirc one blocker is that the downstreams need an updated seccomp golang [09:29] zyga-solus: but yeah, we need to talk about it [09:29] zyga-solus: iirc the code itself (without our libseccomp etc) is fine now, I updated the tests ages ago [09:30] ogra_: Thanks, something does seem to be badly wrong with the snap-proxy. Investigating [09:30] thx [09:57] ogra_: Should be fine now [09:57] (restarted squid) [10:01] cjwatson, thanks a lot [10:03] PR snapd#4301 opened: interfaces: small helpers === chihchun is now known as chihchun_afk [10:04] PR snapd#4302 opened: timeutil, overlod/snapstate: cleanup remaining pieces of timeutil weekday support [10:07] pstolowski: reviewed [10:08] zyga-solus, that was quick, thanks! will move the test into separate method [10:08] thanks [10:08] mborzecki: same, though asked a small uncomfortable question === chihchun_afk is now known as chihchun [10:16] zyga-solus, done [10:20] zyga-solus: thanks, and mvo thanks for addressing zyga's comment :) [10:21] yw [10:54] pstolowski: added some reflect magic in the comments to your PR [10:59] mborzecki, I saw that, thanks! i like that, let's see if anyone opposes it, if not this is going to simplify some of the changes i'm doing right now, actually [11:00] pstolowski: i'm quite sure it works for simple assignable types, haven't checked slices or functions [11:03] mborzecki: I think we try to avoid reflection in non-test code [11:05] meh, tests are hitting the timeouts pretty consistently currently :( [11:05] ah, here you go [11:05] zyga-solus: you mean hand written reflection? because json de/encoding does the same (just in more horrid way) [11:07] mborzecki: 4285 has conflicts (in case you haven't seen that already) [11:09] mvo: thaks, i'll take a look later, hopefully nothing too complicated [11:12] mborzecki: I mean "import reflect" in general, that was my experience at least [11:12] mborzecki: but we'll see, I'm don't know :-) [11:12] mvo: store woes or things we're not re-trying? [11:16] zyga-solus: not sure [11:16] mborzecki: yeah, probably small stuff, I also added some comments, a bit drive-by, sorry for that, will do a more systematic one too [11:28] PR snapd#4303 opened: interfaces: use ConnectedPlug/ConnectedSlot types (step 1) [11:29] mvo: hi, I did a final pass on a couple of your open PRs [11:29] now lunch [11:35] pedronis: \o/ thank you [11:35] pedronis: I check it out === chihchun is now known as chihchun_afk [11:50] mvo, hey, I'll be 5 minutes late for the standup [11:50] cachio: no problem [11:50] mvo, tx [11:50] Hellos [11:50] pstolowski: woah, 4303 looks like you had a lot of work with that one [11:50] Good mondays [11:51] good morning niemeyer, happy monday! [11:51] mvo, it was a pleasure [11:51] mvo, just kidding ;) [11:51] pstolowski: rotfl [11:52] pstolowski: it looks impressive in any case :) [11:56] hey niemeyer! any thoughts on the suggestion from mborzecki here in the comments: https://github.com/snapcore/snapd/pull/4301 ? [11:56] PR #4301: interfaces: small helpers [12:00] pstolowski: OMG 4303 is monumental [12:01] zyga-solus, it would be 2x more if I didn't artificially split it (with the hack mentiond in the desc) [12:01] yeah, these kind of changes are pain.. [12:02] pstolowski: Looking [12:03] niemeyer, zyga-solus was saying we don't want to use reflection in the code? [12:04] pstolowski, mborzecki: That's quite nice [12:04] pstolowski: I don't see why.. we're using reflection like this all the time because we use json [12:04] good [12:36] jdstrand: ping [12:37] niemeyer: hi, could you look at #4281 it looks sane to me, but I wasn't there when the details of it where discussed [12:37] PR #4281: snapstate: support for pre-refresh hook [12:38] pedronis: On it [12:40] PR snapd#4302 closed: timeutil, overlod/snapstate: cleanup remaining pieces of timeutil weekday support [12:46] pedronis, pstolowski: Sent some questions about the details there [12:50] mborzecki: trivial conflict on 4285 [13:02] zyga-solus: Coming? [13:02] zyga-solus remind me again, when using a non ubuntu kernel on ubuntu, but having confinement enabled, how do I tell snap-confine to behave? http://pastebin.ubuntu.com/26057979/ [13:02] niemeyer: yes, just 2fa woes [13:04] sergiusens: I think this is fixed in master now [13:06] mpt hey there, mind reviewing the wording on this PR? https://github.com/snapcore/snapcraft/pull/1634/files [13:06] PR snapcraft#1634: Push metadata to the Store [13:06] sure [13:06] mpt thanks! [13:07] mpt if you think of a better "command name" don't hesitate to bring it up :-) [13:07] mpt, sergiusens, thanks [13:08] zyga-solus to use master, do I just bring it in? As in, is snap-confine going to be executed host side or from "core/base" if I build a package from master and install? [13:09] sergiusens: you just use edge, hopefully that should be enough [13:09] zyga-solus ah, that's risky business :-P [13:09] zyga-solus might it be in beta or candidate? [13:10] * sergiusens refreshes to edge [13:11] I hope that going to candidate eventually (to a past revision) won't ruin up all the apparmor or seccomp profiles created [13:11] * lundmar looks around pondering how to speed up his alias request for lxi-tools :) [13:18] zyga-solus do I need to reboot? [13:18] if the answer is no, the fix does not seem to be in master [13:18] Hmm, I've granted build.snapcraft.io access to the repositories in one of my organizations. However, now I need to grant access to other repositories in a different organization but I can't find or reopen the interface for doing that at build.snapcraft.io ? [13:19] Oh never mind, I've found it. [13:20] sergiusens, I think it would take a long time for me to learn enough to have a useful opinion on that PR, so I’ll stay out of it. Sorry. :-) [13:22] mpt how about if I just ask you to look at this https://forum.snapcraft.io/t/mechanisms-for-converging-store-and-snap-metadata/2200 ? [13:22] mpt oh, you already have [13:24] mpt Facu instead of `snapcraft update-metadata` what about `snapcraft push-metadata` which has a more consistent feel to the default `push` or do we want to keep the word "update" in there? [13:25] sergiusens, that seems reasonable to me [13:25] no more update, upload, just push please :) [13:40] sergiusens, not following you... currenct command is `snapcraft push --only-metadata` [13:40] sergiusens, no "update" at all [13:43] mpt Facu sorry my head works in mysterious ways... I don't know where I got my references from; but starting from scratch, does `snapcraft push-metadata` feel more straightforward and understandable than `snapcraft push --only-metadata`? [13:43] sergiusens, to me, yes [13:45] thanks for the feedback mpt [13:47] sergiusens, `snapcraft push-metadata [--force]` ? [13:47] yes [13:50] mvo zyga-solus help, I cannot come back to stable after going to edge it seems http://pastebin.ubuntu.com/26058202/ [13:50] it is stuck there [13:50] sergiusens: yes, its a known issue, the fix is in an open PR. in the meantime, please run `snap changes` and check the change in "do" start and `snap abort ` it [13:51] sergiusens: that should unbreak you [13:51] sergiusens: this https://github.com/snapcore/snapd/pull/4298 is the fix [13:51] PR #4298: many: remove configure-snapd task again and handle internally [13:51] sergiusens: once it lands things are good again [13:51] mvo ok, thanks [13:52] so I get to stay on edge until this gets there :-P [13:52] sergiusens: :) yes [13:52] sergiusens: hopefully this lands today [13:52] if I become unresponsive everyone should know why ;-) [13:52] great [13:53] sergiusens: heh [13:53] mvo I kid thought, I have my wifes computer close by ;-) [13:54] zyga-solus bottom line, edge does not have the fix which makes me boot with `apparmor=0` and I am totally confused as why that would be more secure :-/ [14:02] sergiusens: to the best of my knowledge, yes [14:02] sergiusens: what are you getting? [14:05] * zyga-solus lunches [14:34] zyga-solus same message as before and snap-confine going dead [14:41] sergiusens: hmm, "not confined but should be"? [14:41] Question, why is it that some use "description: |" and some simply "description:" ? It seems to make no difference. [14:42] lundmar multiline is easier with `description: |` [14:42] PR snapd#4304 opened: debian: demote gnupg from dependencies to recommends [14:42] e.g.; for writing paragraphs [14:43] sergiusens: But even without | paragraphs seems to work just fine [14:43] zyga-solus yes [14:43] sergiusens: what does `aa-enabled` say? [14:43] lundmar I'd have to check the yaml spec to get a better answer to this one [14:44] sergiusens: fyi - this works fine: https://github.com/lxi/lxi-tools.snapcraft/blob/master/snap/snapcraft.yaml [14:44] zyga-solus exactly what I shared on the first pastebin; I am now running disabled to get work done [14:44] hmm hmm [14:44] (that's not good) [14:45] zyga-solus exactly, I am about to "distro patch" that check out of the code base to be able to enable apparmor again [14:45] sergiusens: how do I run a mailine kernel like you do? [14:46] sergiusens: If it is perfectly fine to not use | then I think it should not be encouraged to use it - it simply becomes noise/clutter. [14:47] lundmar can you check the spec and make sure that is the case? It might as well be, but we initially had problems when we didn't [14:47] perhaps it has been improved since [14:47] zyga-solus you can use the one the kernel team provides or use https://github.com/jakeday/linux-surface which is what I have [14:49] zyga-solus https://wiki.ubuntu.com/Kernel/MainlineBuilds [14:49] sergiusens: let me try those and get back to you [14:51] the only place I can find a doc reference to | is https://docs.snapcraft.io/build-snaps/your-first-snap [14:52] However, it seems to work just fine without so I guess recent snapd supports not using the odd | [14:52] *snapcraft === cachio is now known as cachio_LUNCH === cachio_LUNCH is now known as cachio_lunch [15:21] kyrofa are you up and about? How was the weekend? [15:27] PR snapd#4305 opened: snapd.dirs: add var/lib/snapd/lib/gl32 [15:28] sergiusens, I am, good morning [15:28] kyrofa good afternoon then :-P [15:29] Yeah, good weekend. The rest of the hardware for my series arrived, so I took some of my intro footage before I needed to poke holes in the box [15:30] You? [15:34] niemeyer, the question you raised on 4281 wrt running pre-refresh hook if snap is not active is an interesting problem. the short answer is no, I should prevent this, because it won't work. but the question is what's the right thing to do. the fact that we will not execute this hook on refresh just because the user has disabled the snap seems a but questionable [15:39] pstolowski: let me check something [15:41] pstolowski: we don't refresh inactive snaps atm (we said it the past that we should reconsider that decision, but that's the current status) [15:42] pedronis, hmm how is it the case? we do have logic around isActive in doInstall (update)? or do we cut this off somewhere else? [15:42] pstolowski: look at Update and refreshCandidates [15:43] pedronis, aha! [15:43] // FIXME: snaps that are not active are skipped for now [15:43] // until we know what we want to do [15:43] if !snapst.Active { [15:43] pedronis, thanks! [15:43] that answers it [15:45] pstolowski: Yeah, I don't quite understand the question, probably based on pedronis' feedback [15:45] pstolowski: Inactive snaps are equivalent to not being there at all in many senses [15:45] pstolowski: We definitely don't want logic running on them [15:46] yea, I think the current decision is probably right in retrospect, and will be even saner with epoch support [15:47] niemeyer, yes. but the bottom line (as far as I understand this) is the logic wouldn't be fired anyway in this case. i'm adding isActive check anyway [15:48] pstolowski: I don't understand the point.. the check there which was omitted is meant to check for exactly this, right? [15:50] pstolowski: notice that that check about Active in doInstall is probably just a historical spelling of IsInstalled I think [15:51] it would also support refreshing an inactive snap (which we don't do though) [15:55] okay, not doing anything about that then. the problem of running after stop-services is fixed now. the post-refresh hook already runs before start-snap-services, so nothing to fix there [15:55] niemeyer, ^ [15:56] pstolowski: Sounds good, let me know when it's ready for another round please [15:58] kyrofa did you catch my comment on the `init` PR? [16:00] niemeyer, it is now [16:00] sergiusens, init? Are you talking about the tuple one? === cachio_lunch is now known as cachio} === cachio} is now known as cachio [16:01] kyrofa yeah [16:04] sergiusens, I did, and you're right, considering that's on our roadmap anyway implementing the SNAPCRAFT_ARCH_TRIPLET seems the proper fix. However, do we want to add gcc as a required build-package for everything? [16:05] We could go the other way and use the map we already have [16:07] sergiusens, note that I'm working on the macaroon at the moment. Would you like me to give this priority? [16:08] kyrofa yeah, use the map; macaroon stuff can go first too [16:08] You got it [16:16] I assume it is still the correct procedure to request aliases in the snapcraft forum or has procedure changed? (alias vs declarations?) [16:19] lundmar, indeed, that's correct [16:24] kyrofa: ok, so I just have to be patient :) [16:24] fyi - I've put an alias request in the "store" forum channel. [16:32] lundmar, can you provide a link here? [16:32] lundmar, oh, found it [16:32] ok thanks [16:33] the lxi-tools one [16:35] lundmar, note that there's a waiting period for comments (a week I think) [16:35] There was a document about the process, but I think the forum swallowed it [16:35] A topic, rather [16:37] oh. Wau thats quite some time :/ [16:38] Wouldn't it be easier for everyone if you guys only have to address and vote to solve alias conflicts instead of voting all alias requests? [16:43] kyrofa a final ack on snapcraft#1759 would be nice :-) [16:43] PR snapcraft#1759: many: ensure classic confined binaries use the correct interpreter [16:43] Ah, the docs were updated, nice [16:45] sergiusens, yep, excellent [16:45] sergiusens, I suppose I need to make a forum proposal if I actually want to write a command to save the macaroon, huh? [16:46] lundmar, yes, agreed, we just don't quite have the infrastructure for that in place just yet [16:47] kyrofa a forum post would be ideal, yes [16:48] Okay I've got this mostly done, that's the last step. Let me write it up [16:48] Issue snapcraft#1662 closed: patchelf with ld-linux [16:48] PR snapcraft#1759 closed: many: ensure classic confined binaries use the correct interpreter [16:50] kyrofa great [16:50] kyrofa, btw it is just me and you this week [16:50] sergiusens, oh good to know [16:50] I knew elopio was out [16:50] * sergiusens starts getting ready for physiotherapy [16:56] zyga-solus: still slogging through holiday backlog. PR 4100 added to list [16:56] PR #4100: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces [16:57] zyga-solus: err, it was always on the list. I mean it is on my list for this week, assuming it doesn't get preempted [17:01] zyga-solus: pr 4140 is also on the list. that requires some investigating from me [17:01] PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service [17:02] niemeyer: hey, pong [17:03] jdstrand: Heya [17:03] jdstrand: Have you seen the follow ups on ikey's thread re. the base image? [17:03] Erm [17:03] base snap [17:04] niemeyer: I saw them in my inbox but put them to the side until I could review them more carefully. I'm about to go back to them (various pings/meetings/etc this morning) [17:05] jdstrand: Ack, just wanted to make sure it was back on your upcoming list, thanks! [17:05] yep [17:05] np [17:07] niemeyer: and sorry I missed the hongout last week, was on holiday and missed the emails/etc [17:07] jdstrand: np, and sorry for pinging while you were on holiday, it was not intended to take you out of them :) [17:07] kyrofa: I've put a forum post regarding the alias vote suggestion: https://forum.snapcraft.io/t/suggestion-only-vote-to-resolve-alias-conflicts/2966 [17:13] pstolowski, pedronis: Shouldn't the pre-refresh hook also be gated by isActive? [17:14] niemeyer: I think we talked past each other, yes to be correct if we allow refreshing inactive snaps, but we don't do that atm. we have a similar check already in doInstall, we probably need to decide one way or another at some point [17:15] I think we want to keep things as they are (no refreshes for inactive snaps) and then probably checks in doInstall would need to be different [17:15] but I suppose for this PR the most consistent thing is to add an isActive guard [17:15] indeed, i wanted it for clarity but afaiu it's not going to be effective atm, since refresh will not be performed [17:16] pstolowski, pedronis: The logic there just tastes wrong in either of those cases [17:17] We *are* checking if the snap is active before performing certain things [17:17] So we need to make up our minds: do we assume that never happens, and really fail upfront if that does happen, or we continue to be mindful of the fact it might not be active [17:18] What makes no sense to me unless I'm missing something, is to pretend it can happen, and code the logic incorrectly for that situation [17:18] I think we should fail upfront (the more things can happen when refreshing a snap the less it makes sense to support for refreshing inactive ones) [17:19] niemeyer: I think the current code is just a result of history, we never committed one way or another so far [17:20] pedronis: That's fine.. I just don't want to have logic in place that is clearly wrong and we do know it's wrong [17:20] pedronis: I would like to eventually support that use case, so one can install something without having it enabled right off [17:20] pedronis: But there's no pressure to do that now [17:21] that's a bit different though [17:21] I mean the check I would add wouldn't involve that case directly [17:22] pedronis: Actually, it does sound a bit awkward to *not* support it [17:22] snapst.IsInstalled && !snapst.Active => error [17:23] pedronis: Just considering the case: there's something wrong with the current version, we disable it so it stops creating havoc [17:23] pedronis: We want to enable it, but update it first [17:23] pedronis: That's exactly that situation, I think [17:24] pedronis: Unfortunately, that means the pre-hook could not run, which might be a real issue [17:24] we need custom logic [17:24] consider that pre-refresh could explode [17:24] pedronis: So +1 on simply forbidding for now [17:24] pstolowski: Are you with us? [17:25] niemeyer, yes. so that's the kind of doubts I had with my original question way above, although phrased in a different way. [17:25] let me check quickly if I'm off and lots of tests explode [17:25] if we do that [17:25] which probably means it needs to be its own PR [17:25] pstolowski: Sure, we're exploring and discussing.. [17:26]