[05:12] morning [05:18] hey mborzecki [05:21] PR snapd#7443 closed: timeutil: fix schedules with ambiguous nth weekday spans [05:31] hey [05:34] mvo: this is the bug fix from Friday https://github.com/snapcore/snapd/pull/7632 [05:34] PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules [05:34] mvo: at least the first patch can be reviewed and landed in separation [05:35] mvo: namely https://github.com/snapcore/snapd/pull/7632/commits/02ba1f863776d4d4c27bcfc3edccfebe30a11ef2 [05:37] I'll iterate on https://github.com/snapcore/snapd/pull/7547 [05:37] zyga: cool, thank you. I have a look [05:37] zyga: just making a cup of tea :) [05:37] PR #7547: many: use a dedicated named cgroup hierarchy for tracking [05:58] uh [05:58] my dog needs help [06:17] mvo: https://github.com/snapcore/snapd/pull/7613#discussion_r336850453 does sfdisk poke kernel to rescan the partition table too? [06:17] PR #7613: snap-recovery: add minimal binary so that we can use spread on it [06:20] hm actually wonder what blockdev does, whether it creates the nodes itself or what [06:27] mvo: looked a bit at blockdev, looks like it's a single ioctl actually, even if sfdisk doesn't call it, and we don't want a dependency on blockdev, we can issue it ourselves from snap-recovery [06:33] mborzecki: sfdisk does, I think the code comment referes to the line in the code even [06:33] mvo: ah, good then [06:33] mborzecki: yeah, its a single ioctl, let me quickly check [06:34] mborzecki: disk-utils/sfdisk.c:write_changes() [06:35] mvo: thanks, see that now [06:35] mvo: we should be good then [06:35] mborzecki: great, that runs fdisk_reread_partition_table which runs i = ioctl(cxt->dev_fd, BLKRRPART); [06:35] which is AIUI all that is needed [06:36] mborzecki: its also smart enough to not call it on a non-blockdev (unlike blockdev :) [06:37] mborzecki: fwiw, Iremoved the blockdev call because it apparently raced with udev, I got an error that BLKRRPART failed because the deivce was already in use which seems to indicate that blockdev and udev tried to to the same thing (this happend in the spread test) [06:43] mvo: duh, /o\ [06:43] mborzecki: no, its fine, it only happens with blockdev which we don't really need, was just a bit annoying to find it but spread tests ftw! [06:59] re [06:59] dog back home, got steroids, need to observe [07:02] sorry, need to focus on coding again === pstolowski|afk is now known as pstolowski [07:03] morning [07:04] pstolowski: hey [07:42] PR snapd#7509 closed: gadget, snap/pack: perform extended validation of gadget metadata and contents [07:42] zyga: 7613 is rady for a second review, should address all the points you raied in the other review [07:43] mvo: ack [07:45] mvo: note: it has conflicts [07:47] zyga: aha, I did not notice, fixing now [07:47] Lost power [07:47] Checking [07:48] External fault [07:49] Checking outdoors [07:52] on phone thether [07:52] well, that thing [07:52] anyway [07:52] last thing I heard before silence was neighbors drilling [07:54] pro tip: one way to check if you lost power or if street lost power: check how many APs are around [07:54] if there are none it's not just you [07:57] zyga: smart [07:59] it's not that I have a noisy environment [07:59] but when power goes out [07:59] everything is so silent it is almost uncomfortable [08:00] zyga: zombie apocalypse? [08:00] mborzecki: that's when hordes of mindless users look for open wifi? [08:00] zyga: yeah, zombie walk with your phone looking for wifi :P [08:55] pedronis: hey, will you have a moment to talk about system-key today? [08:55] mborzecki: still no power [08:57] pstolowski: I have a meeting now, seems more likely that we should chat tomorrow morning [08:58] zyga: btw, if you are with ENEA, then on https://www.wylaczenia-eneaoperator.pl you can subscribe to be notified about outages in your region [08:58] pedronis: okay, sure (btw i'm off this afternoon) [08:58] pstolowski: yes, saw that, that's why I said tomorrow [08:58] pedronis: good, ty [09:25] mvo: can you take a look at #7630? [09:25] PR #7630: overlord/devicestate: check snap handler for gadget remodel compatibility [09:25] mborzecki: aha, yes, sorry, I have one more meeting and then we are good === ricab is now known as ricab|bbl [09:42] mborzecki: now! [09:42] hah [10:37] mvo: btw a question came up in a pull request, 14.04 support [10:37] zyga: a few comments to #7632 [10:37] mvo: is 14.04 maintained? [10:37] PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules [10:38] Chipaca: in your comment on https://github.com/snapcore/snapd/pull/7589, was there any particular reason you thought individual subcommands should also be hidden? [10:38] PR #7589: cmd/snap: add ability to register "snap internal" commands <⛔ Blocked> [10:38] jamesh: because otherwise they're not actually hidden? [10:39] Chipaca: they won't show up in the "snap --help" output. [10:39] what is the benefit of hiding commands in "snap debug --help" or "snap internal --help" output? [10:40] jamesh: we hide commands that aren't meant for human consumption [10:41] jamesh: and all 'internal' commands are like this, aren't they? [10:41] jamesh: all internal commands right now are hidden, in particular [10:42] jamesh: why would you make 'internal' commands _not_ hidden? [10:42] pstolowski: thank you, replied to each one [10:42] Chipaca: I understand preventing them from being discovered from "snap --help". But if you're specifically asking for information about debug or internal commands, why wouldn't you show them? [10:43] pstolowski: please let me know how you feel about Index [10:43] er [10:43] about Items [10:43] I'll gladly make the change [10:43] folks, I have 11% of battery left, there's something wonky in the wiring outside my house, I can flip on a switch and I get power for a second but then fuses back home pop [10:44] I tried fiddling with it for a while but something new must be shorting the circuit [10:44] I need to either debug it or go and find another place to work and debug it later [10:44] if I don't respond it's likely that my laptop has discharged or that I'm in the fuse box in the basement [10:44] please telegram me for thing that need my attention [10:46] macos builds are failing on timeouts? [10:49] zyga: yup, since friday i think [10:49] it's random though [10:50] mborzecki, zyga, do you have logs? [10:50] yes [10:50] one sec [10:51] https://travis-ci.org/snapcore/snapd/builds/600667289 [10:51] Chipaca: https://travis-ci.org/snapcore/snapd/jobs/600643173 ;) [10:51] would't call them logs tbf [10:52] ah, not us [10:54] jamesh: I don't have a good answer, I'd raise it with the team later [10:56] brb quick errand [11:01] zyga: re 14.04> we keep it alive [11:08] re, heh, quicker than i thought [11:17] PR snapd#7613 closed: snap-recovery: add minimal binary so that we can use spread on it [11:22] pstolowski: https://github.com/snapcore/snapd/pull/7632 updated and responded [11:22] PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules [11:22] power is back :) [11:23] amurray: hey [11:23] amurray: are you able to do some reviews for us this week? [11:23] amurray: ideally before Jamie is back later this week [11:29] zyga: ty === pstolowski is now known as pstolowski|afk [11:52] mvo: small remark about snap-recovery here v [11:52] https://github.com/snapcore/snapd/pull/7629#pullrequestreview-304503890 [11:52] PR #7629: snap-recovery: create filesystems as defined in the gadget [11:53] mvo: about this part, https://github.com/snapcore/snapd/pull/7629#discussion_r336617913 -- do you know what I meant about that comment - I'm fine if you just don't want to do it but I wanted to make sure we understand each other [11:53] PR #7629: snap-recovery: create filesystems as defined in the gadget [12:42] mvo: this line seems wrong: https://github.com/snapcore/snapd/blob/master/overlord/managers_test.go#L3625 shouldn't that brand-kernel [12:43] *that be === ricab|bbl is now known as ricab [12:56] morning y'all [12:57] hello ijohnson :) [12:59] zyga, the correct answer to "y'all" is "howdy" ;) [12:59] ijohnson, howdy [13:00] ogra is well versed in american responses [13:00] thanks zyga and mborzecki for 7629 review [13:00] haha [13:08] ijohnson, cachio, mvo: another spread PR https://github.com/snapcore/spread/pull/90 [13:08] PR spread#90: runner: remove filterDir, default include to "." [13:09] zyga ack will look today [13:09] thank you :) [13:13] Eighth_Doctor: ack, I'll look === ricab is now known as ricab|lunch [13:20] mborzecki: how much work will it to get golang.org/x/xerrors from 31 to f30? we may need it for 7622 (looks like we go with xerrors eventually) [13:21] mvo: looked rather easy last time i checked [13:25] Eighth_Doctor: hmm, that's valgrind [13:26] Eighth_Doctor: perhaps we should just not use valgrind on ppc64el [13:26] that single arch that nobody ever needed [13:26] Eighth_Doctor: if it persists we should file a bug on valgrind and remove the check on ppc64el [13:27] Eighth_Doctor: let me know if that works for you [13:31] should I break out OrderedSet out of https://github.com/snapcore/snapd/pull/7632 [13:32] PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules [13:32] it's totally standalone and could land separately [13:42] zyga: yes :) [13:42] Chipaca: sure, one moment [13:42] zyga: then i can ask silly questions about it without feeling like i'm stalling _important_ work [13:42] haha [13:42] zyga: :-p [13:42] as long as you review it :) [13:43] PR snapd#7633 opened: strutil: add OrderedSet [13:43] Chipaca: please ask away :) === charles_ is now known as charles [13:55] zyga: I updated 7629 based on your suggestions (and maciej) [13:56] mvo: looking [13:58] mvo: reviewed [13:58] zyga: Chipaca beat me to submitting a review but I think I won because I found a bug [13:59] ijohnson: totes [13:59] isn't that how this works? whenever you find a bug you win? [13:59] ijohnson: yes [14:00] * ijohnson waits for my trophy [14:00] ijohnson: you can now take the day off, find a fair, and ride a rollercoaster [14:00] weeeeeee [14:00] ijohnson: also, you can expense up to 3 candy apples [14:00] to zyga [14:00] he wrote the bug, he pays the candy apples [14:03] it's just weird, since this has worked for literally years on ppc64le... === ricab|lunch is now known as ricab [14:05] thank you for the review guys [14:05] ijohnson: you win [14:06] you're welcome zyga [14:07] * ijohnson goes back to foruming up a forum post [14:07] zyga: silly question: do you actually delete things, in your use of this? [14:07] nope [14:08] zyga: then don't offer a Del() at all [14:08] easy enough to add (maybe leave a comment so we don't write the bug again) [14:08] yeah [14:09] less code -> less bugs [14:09] * Chipaca deletes all of overlord/ [14:09] \o/ [14:12] I found a bug and Chipaca deleted the overlord, and the rise of skywalker tickets go on sale tonight! feels like the start to a great day already :-) [14:13] as long as you aren't runing ppc64le, apparently [14:15] ijohnson, Chipaca: updated https://github.com/snapcore/snapd/pull/7633 [14:15] PR #7633: strutil: add OrderedSet [14:15] PR snapd#6666 closed: Change file names that are breaking go modules [14:24] PR pc-amd64-gadget#21 opened: Xnox closing uc20 branch [14:29] thank you guys [14:29] I'll brak for lunch now [14:29] and be back after that [14:30] don't brak too hard tho [14:31] PR snapd#7634 opened: Add empty go.mod file to ignore directories [14:31] awww, #6666 was an awesome PR number [14:31] PR #6666: Change file names that are breaking go modules [14:51] zyga: reviewed #7632, I'm a bit concerned about the de-duplication by just splitting by newlines since apparmor does support some multi-line rules AFAICT [14:51] PR #7632: interfaces/apparmor: avoid excessive repetition of snap-update-ns mount rules [14:53] ijohnson: yes but there are no rules that are multi-line there [14:53] ijohnson: in any case, I can remove the split entirely, along with the buffer [14:53] ijohnson: it's just verbose [14:54] ijohnson: as the patch will affect more code [14:54] zyga: but what I'm concerned about is if we are de-duping based on newlines, then we need to be sure this de-dup code doesn't ever get run on anything other than s-u-n completely auto-generated code [14:57] ijohnson: I replied in the PR, [14:57] looking [14:57] ijohnson: your concern is based in truth but it's not immediately affecting this branch; we can remove the buffer and the split but it will make the diff somewhat larger as it's spanning more areas [14:57] ijohnson: but we can totally do that [14:57] ijohnson: it's just a cheap-way out of the bug for now, so that tests can be understood [14:58] ijohnson: I can look at that as the ordered set lands and we can again focus on the essence of the bug [14:58] zyga: do we get the same performance gains if we don't split and de-dup based on the strings passed in directly? [14:59] ijohnson: no, because we really add huge chunks that contain unique comments [14:59] ijohnson: just look at what the buffer contains [14:59] ijohnson: it used to be one add before [14:59] ijohnson: I was thinking about changing this some more, as follows [14:59] ijohnson: keep an ordered set of rules like now [14:59] ijohnson: and separately, a set of comments that go along with each rule [15:00] ijohnson: the comments will refer to where this is used [15:00] ijohnson: we de-duplicate the rules but collect the comments [15:00] ijohnson: and when we emit the profiles we see short code and longer usage explanation [15:04] hmm that could work [15:05] another option is that when we go to de-dup the rules, we just replace a rule with a comment that says "// duplicated" - this would keep it simple to understand and still de-dup real rules, just keep the profile at 17k lines or whatever [15:05] * ijohnson quick coffee break [15:07] ijohnson: I proposed that but it was NACKed by jdstrand [15:08] I'll ponder some on ordered set while having tea [15:09] hi jdstrand would it be possible to get a review on https://dashboard.snapcraft.io/snaps/microk8s/revisions/988/ and https://dashboard.snapcraft.io/snaps/microk8s/revisions/992/ to get the work I have on microk8s strict confinemnt so far into a branch? [15:10] thanks [15:11] kjackal_v2: jdstrand is off until Wed [15:13] zyga: any chance someone else can give a +1 in the review queue [15:14] I don’t know [15:16] zyga: who is normally reviewing snaps that need manual reviews? [15:16] There must be a process somewhere documented [15:17] roadmr: do you still do revision review, etc.? see kjackal_v2's request: ^ [15:19] PR snapcraft#2757 opened: Drop build_base check from make plugin. It is universal [15:29] jacekn: let's see [15:29] sorry ijohnson I mean you [15:30] thanks roadmr [15:33] ijohnson, kjackal_v2 : do you need manual approval of these two revs only, or would you need allowance of personal-files use? [15:36] roadmr: with "personal-files use" you mean autoconnecting the home interface? For now I am interested in just getting the snap on the latest/edge/strict channel branch, nothing more [15:37] I am ok with manualy connecting the interfaces [15:37] kjackal_v2: right, I can just approve these two revisions so you can publish them; subsequent ones would still need manual approval and manual connection [15:38] That is fine roadmr, we will need a few iterations before we consider this ready for releasing to the users [15:38] ok [15:38] thank you [15:39] kjackal_v2: 988 is approved, 992 is waiting for auto-review, I'll approve as well if done [15:41] kjackal_v2: I need to afk for a bit, will look at any stuck revisions when I'm back [15:42] * cachio lunch [15:51] degville, pedronis: do we still not have seed.yaml (or seeding as a process) documentation? [15:52] Chipaca: we don't, seed.yaml is still an internal details btw (abuses and uses not with standing), also it will not exist in core20 [15:52] pedronis, Chipaca: do we support seeding with a developer's credentials i.e. from `snapcraft export-login`? I've never seed a core image with credentials like that [15:53] ijohnson: you mean building an image? or actual seeding? [15:54] pedronis: yes building an image, can you put the credentials in the image/seed such that it will automatically login and refresh private snaps when booted up and running [15:54] or maybe this already happens, I haven't ever tried this [15:54] ijohnson: that is officially not supported [15:54] it's an anti-pattern [15:54] pedronis: ack, that makes sense [15:55] just curious as it seems like that's what this user is requesting if Chipaca is referring to https://forum.snapcraft.io/t/snap-login-without-password-prompt/13762/6 [15:58] private snaps exists mainly to support private early development of snaps [16:00] Chipaca: to be clear we do need life cycle docs, just not sure how much seed.yaml details are important [16:11] kjackal_v2: hey, all available microk8s revisions are now approved, let me know if anything else is needed [16:22] awesome roadmr, thank you [18:26] mvo: thank you for review on the ordered set [18:27] mvo: I pushed the extra test changes and simplified some of the code as pointed out :) [18:27] mvo: I'll merge when green but if there is something more to change I'm happy to do so in a follow up [18:29] cachio: are spread tests for spread expected to pass? I got a failure in the ad-hoc test [18:29] cachio: specifically on https://github.com/snapcore/spread/pull/90 (restarted since) [18:29] ijohnson: ^ replied there, thank you for the review\ [18:29] PR spread#90: runner: remove filterDir, default include to "." [18:29] zyga, let me take a lok [18:30] look [18:30] cachio: no, sorry, no more logs [18:30] zyga, this one started failing a time ago [18:30] cachio: just wanted to ask you if you know some tests are known broken [18:30] cachio: can we fix or disable it [18:30] zyga, I'yes [18:30] i'll fix it [18:31] it is in my todo [18:33] cachio: súper, thank you [18:33] zyga, the problem is this + ADHOC_ADDRESS='10.214.87.197 [18:33] localhost:59387' [18:36] zyga: cool, thanks for clarifying [19:24] hey folks, is core considered a "base" snap technically? [19:31] PR snapcraft#2758 opened: Appstream desktop suffix [19:33] roadmr: no, not yet [19:33] roadmr: core is special [19:33] roadmr: it's a base but it's not of type base [19:33] interesting :) ok zyga thanks [19:34] which are the most common/used bases at this point? [19:40] zyga, adhoc test fixed [19:40] PR 91 [19:40] cachio: cool, looking [19:40] PR #91: [15.04] Default to SocketMode=0660 if no socket mode option is given [19:41] cachio: how can we land it? [19:41] zyga, you cant [19:41] zyga, niemeyer is the only one [19:41] I know, I mean what can we do to get it merged? [19:41] just ping him [19:42] Yeah, that should work [19:42] hey :) [19:42] niemeyer: you are sometimes hard to find :) [19:42] Even more if that's done during working hours instead of at sleep time ;D [19:43] cachio fixed a bug in a test, do you think you could have a look? [19:43] zyga: Yeah, sorry.. I haven't managed to not sleep yet [19:43] doesn't have to be now :) [19:43] tomorrow is a good day to do more work [19:44] Yes, I'm just non-ironically saying that I don't think you've been pinging me during working hours [19:44] So "hard to find" is.. hmm.. strange? for a remote team [19:45] I'm here if you need.. just ping [19:45] niemeyer: I meant that usually you are extremely busy so we plan our sync bursts with you carefully [19:46] Have you actually been trying to talk to me? [19:47] niemeyer: not today, no === sergiusens_ is now known as sergiusens [19:48] niemeyer: if you have some time tomorrow I have a PR for spread as well but I think it would be best to discuss that during your working hours [19:48] Not today, not recently.. I got one ping from you recently I think, and that was very late at night [19:48] I'm just saying, don't use my busyness (?) as an excuse to not talk to me :) [19:48] niemeyer: noted :) [19:48] Thanks for your interest.. I can only help if I'm in the loop [20:28] PR snapd#7633 closed: strutil: add OrderedSet [20:34] PR snapcraft#2759 opened: remote-build: rebase on master and include https token support [22:57] zyga: sure (re reviews) - I have had a couple on my list to do already but have been sidetracked with other things - since Jamie is out I am also taking the load of store reviews etc too - but please tag me (@alexmurray) and I will do my best