=== chihchun is now known as chihchun_afk [01:23] PR snapd#5926 closed: store: tweak unmatched refresh result error log [01:25] PR snapcraft#2318 closed: meta: add support for the license field === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === JanC_ is now known as JanC === JanC is now known as Guest80969 === chihchun_afk is now known as chihchun [05:02] morning [05:26] Hey hey [05:27] Time to get to work [05:39] zyga: anything interesting happened yday? [06:10] Hmmm [06:12] Some things yeah [06:12] Currently taking the dog out so harder to type [06:41] PR snapd#5923 closed: overlord: don't make become-operational interfere with user requests (2.35) [06:41] PR snapd#5924 closed: overlord: don't make become-operational interfere with user requests (2.36) [06:44] PR snapd#5928 closed: cmd: put our manpages in section 8 [06:50] hm our socket unit files should probably just have `Wants= sockets.target` and we should not use network.target in there [06:57] mborzecki: indeed [06:58] i'll open a PR [06:58] ta [06:58] i'll be good to have it cherry picked to 2.36 too [07:01] from what i found in systemd source code, when there's a cycle it'll drop/delete the job(s) that is/are not directly required by the anchor job (the main job that's at the top of transaction chain?) [07:02] i guess if stars align and you're unlucky enough some target may be dropped (network.target maybe?) or nm service/start job, then you'd end up without wifi/eth whatever [07:03] mvo: are you tracking all the 2.36 PRs for backports? [07:06] good question, mvo should i open backport PRs to 2.36 of #5898 and #5905? [07:06] PR #5898: tests: spread tests for aliases with parallel installed snaps [07:06] PR #5905: store: gracefully handle unexpected errors in 'action' response [07:09] mornings [07:14] mborzecki: I think we can ignore the test one but the other one yes please [07:14] mborzecki: if its a single commit I can cherry pick [07:14] mvo: please cherry-pick the simple one [07:15] mvo: as for the test one, it has some tweaks/cleanups in the code, so it'd still be useful, i"ll open a PR for that [07:15] mborzecki: ok [07:15] mborzecki: cherry-picked [07:15] mvo: ta [07:18] mvo: should I prepare a chain of backports? [07:19] PR snapd#5234 closed: snap: add `snap list --format=...` option [07:19] zyga: for what exactly? [07:19] For things I tagged 2.36 and landed in master [07:20] PR snapd#5929 opened: overlord/snapstate, tests: code tweaks, spread tests for aliases with parallel installed snaps (2.36) [07:20] zyga: let me have a look [07:20] Ok, please let me know [07:22] zyga: given a) we need to do a 2.35.3 and b) how much 2.36 prs are tagged I wonder if we should simply take master for ~pre2, we didn't merge anything scary iirc [07:24] Mmmm, interesting [07:24] What is the motivation for 2.35.3? [07:25] zyga: we need a fix for the unionfs issue on the livecd [07:25] Ah [07:25] zyga: without that the snaps on the live media do not start [07:26] Overlayfs [07:26] zyga: which is release criticial for cosmic [07:26] But sure [07:26] +1 for ~pre2 from master [07:27] ok, let me prepare 2.35.3 and then I look at this, until then, no more backport PRs please :) [07:35] Ok [07:38] hi, I'm getting the following error when trying to run a command from a snap: cannot perform operation: mount --rbind /lib/modules /tmp/snap.rootfs_zr48qw//lib/modules: No such file or directory [07:38] [07:38] (the same happens to a service in the snap) [07:45] ackk: this is fixed in master [07:45] Try beta/edge perhaps [07:45] zyga, of what? [07:45] snapd? [07:46] Yes [07:46] Well, core snap [07:48] yeah that worked. [07:48] mvo: hi, seems we don't have a 2_35 tag in the forum? [07:49] pedronis: looking [07:49] pedronis: I added one now [07:49] thanks [07:49] pedronis: and added it to "clarification on seed.loaded" [07:50] mvo: yes, did the same, added 2.36 as well [07:50] thank you [07:51] :) [07:52] :) [08:25] morning peeps! welcome to Friday :) how do we close PRs today? [08:27] Wholesale [08:27] looking at my own PRs: #5879 can use another review [08:28] PR #5879: vendor, cmd/snap: refactor to accommodate the new less buggy go-flags [08:28] and #5888 also [08:28] PR #5888: [RFC] use stages to run "cheaper" tests first [08:28] I’ll help [08:28] wheee :) [08:28] Just back hurts somewhat today [08:28] zyga: you were fine yesterday before you decided to do this dodge "sleep" thing [08:29] dodgy* [08:29] also, review stuff or I'll make your browsers crash with emoji overload from looking at the pr page [08:30] Yeah, yesterday was too long [08:30] Not enough walking [08:31] ah, yeah, that'd suck [08:31] yesterday I went to the gym and thought I'd had a bad day, turns out i was just pushing myself too hard (still got through 600kcal in an hour) [08:35] niemeyer: I got an email telling me you changed the standup meeting, but it looks the same to me. What's different? [08:35] niemeyer: (morning!) [08:36] Chipaca: moin! If I didn't do anything wrong, I just declined today's event [08:36] niemeyer: he is off today, no? [08:36] Yes, in theroy at least :) [08:36] heh [08:37] * Chipaca reaches for his get-off-irc-then stick [08:37] niemeyer: :) enjoy [08:37] google calendar is wacko, but holidays are good [08:58] PR snapd#5930 opened: wrappers: do not depend on network.taget in socket units, tweak generated units [08:59] mvo: ^^ [08:59] mborzecki: cool! looking [09:00] zyga: is #5170 ready for re-review? [09:00] PR #5170: interfaces/builtin: add adb interface [09:00] mborzecki: uh, do we need this for 2.35 as well? [09:00] mborzecki: thats not a regression, is it? [09:00] hm, i'd say yes [09:00] Chipaca: I think so but let me double check [09:01] mvo: let me open a PR for 2.35 so that it gets a full spread run [09:01] mborzecki: uh, ok. that means 2.35.4 [09:01] zyga: if so, I'd say @-mention the j of the d strand [09:01] yes John, it is ready [09:01] I wanted to get an ack from Gustavo first as s-j is busy lately [09:02] to avoid re-review if we change direction [09:02] mvo: while at it, i'd like to get the feedback if the change, once in edge, fixes problems people have observed [09:05] mborzecki: silly question but we remove network-online.target so what did we do that triggered a regression [09:05] mborzecki: hm, I see we just changed it to network.target [09:06] mborzecki: ok, but that is no regression, is it? I mean this was broken before [09:06] mborzecki: (may still be a good idea to do a .4 for this but I want to figure out if we have to because of regression or if its "optional") [09:06] IMO serious bugs are serious bugs, regression or not [09:08] zyga: we had this serious bug from day one [09:08] zyga: well, since we added socket activation [09:08] let's fix it and move on :) [09:09] zyga: there is a cost, I'm not saying we shouldn't do it just want to understand the details [09:09] mborzecki: you have a review, looks great, just one comment [09:12] zyga: #5469 is also blocked on gustavo [09:12] PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call [09:12] zyga: and that one's blocking a customer [09:12] Chipaca: my dotfiles as well [09:12] * Chipaca wants mvo's dotfiles [09:13] I'll auction them at sotheby's or something [09:13] Chipaca: haha [09:13] mborzecki: I pushed a tiny addition to your PR [09:14] mborzecki: (i.e. resolving my comment) [09:14] mborzecki: after thinking about this I think you (and zyga) are right, this is worth a 2.35.4 [09:18] zyga: BTW, to unblock the snap-update-ns work, I suggest simply looking for the presence of a flag file on a good location that only root can write [09:19] zyga: Flag file could be .experimental-snap-update-ns for example [09:19] niemeyer: yeah, I can just assume it's set for now. It's good enough to move the rest forward. We can discuss the details next week [09:19] zyga: This file is a trivial one-liner anywhere you want to test for it [09:19] niemeyer: perhaps this can even do away without an experimental flag it if lands after this release [09:20] zyga: as long as we're sure it works [09:20] yep [09:21] something like facts could be useful later on though for things we kind of abuse facts for today (like telling snap-confine that a given snap is in classic mode without any way to abuse it) [09:21] or telling snap-confine what snapd thinks about the distribution directory layout [09:22] but regardless, for user mounts we can unblock [09:24] mborzecki: happy to help with the backport of 5930 to 2.35 [09:29] niemeyer: if you're not not here, #5469 is the 4th-oldest PR, waiting for your re-review, blocking a customer. Not flagged as urgent though so if you _are_ not here, go away already [09:29] PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call [09:31] mborzecki: aha, its there, nice! [09:31] mvo: from what i understand, adding network.target and being wanted by sockets.target made us move the network target to be reached before 'basic', with defautl dependencies being basic and sysinit, NM which ash Before=network.target + defaults made a cycle [09:32] mborzecki: aha, that makes sense [09:35] PR snapd#5931 opened: wrappers: do not depend on network.taget in socket units, tweak generated units (2.35) [09:35] Chipaca: There's no relevant internal or external design changes in there which would greatly benefit from my input (I think?).. if you and the team are comfortable that the change in behavior is correct, I suggest just going ahead [09:35] mvo: full PR to 2.35 ^^ [09:35] ta [09:36] niemeyer: neat. I'll document this by retracting your PR. [09:36] dismissing it even [09:37] Chipaca: is it land-it-friday today :) ? [09:37] oh yes [09:37] mvo: we hit 50 PRs yesterday [09:37] mvo: 5930 needs your +1 too :) [09:37] mvo: you know how that affects me :) [09:38] mborzecki: indeed and a second review [09:38] Chipaca: haha, sounds like a good plan [09:38] niemeyer: now go away and enjoy yourself doing … whatever it is people do out there [09:39] :) [09:39] mvo: merge everything ;) [09:39] mvo: I'm even using my gh.go thing (which made me merge a bit too overeagerly yesterday, to pedronis's chagrin) [09:39] Chipaca: wow, the icons on hot plug are ... really nice! [09:40] hehe [09:40] Yes, I'm doing something very important right now by constructing a Minecraft head out of a cardboard box.. lots of focus required :P [09:40] niemeyer: ah. Make sure you get the derp eyes just right. [09:41] niemeyer: otherwise you might accidentally herobrine [09:41] and we will have to remove him in a point release! [09:42] * zyga wonders who gets Minecraft lore references... [09:42] did you guys break core ? my edge images just exploded in my face [09:42] ogra: break core on Friday? what are we, workaholics? [09:42] Yeah, we were trying to break it for a while.. [09:43] * niemeyer steps out quietly.. [09:43] avahi cant start anymore https://paste.ubuntu.com/p/RzH4y8TZDm/ and the only snap that got updated on this image was core [09:43] (the image was feshly built from edge yesterday evening) [09:44] ogra: and seriously, no idea, does it work if you switch core to stable? [09:44] on it, waiting for the reboot [09:44] thank you [09:45] zyga: #5469 GTG at your discretion [09:45] yes, works fine i can ping the mdns addres again [09:45] PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call [09:45] *address [09:46] seems whatever landed in edge does not create XDG_RUNTIME_DIR for the app snaps [09:46] Chipaca: thanks, I think it is file to land [09:46] cool cool [09:46] ogra: core traveled back in time from edge to 2.35.3 [09:47] ogra: now it has traveld back [09:47] ogra: but will soon travel again for 2.35.4 [09:47] mvo, well, something broke [09:47] PR snapd#5469 closed: interfaces/apparmor: (un)load profiles in one apparmor_parser call [09:47] ogra: yeah [09:49] btw, is it normal that gadgets never survive delta generation ? all other snaps i push do it fine [09:49] hmm? [09:49] Error generating delta: There has been a problem while processing a snap delta. [09:49] - Delta service failed to apply delta successfully [09:49] Falling back to pushing full snap... [09:49] with snapcrft push [09:49] *snapcraft [09:49] no idea but I doubt it's desired [09:50] k, because i have only seen it with gadgets [09:50] ogra: look if snap craft leaves a log with the reason for the failure [09:51] nope, doesnt ... (and i would be surprised, i think thats all happening server side after the upload) [09:52] no, the delta is local [09:52] it is a local delta for speeding up the upload [09:52] ah [09:52] indeed [09:52] my brain is kind of friday today :P [09:56] hi [09:56] hello axino [09:56] o/ zyga [09:56] is this the proper place to ask how to get a snap owned by ~snapcrafters ? [09:57] axino: I think the forum is the better place [09:57] perhaps popey can help though [10:00] hello [10:00] axino: which snap? [10:00] popey: a "redis" snap I'm currently building [10:01] axino: have you spoken to the upstream redis people? :) [10:01] popey: heh, I have not :) [10:01] (We'd rather snaps went upstream first, rather than direct to snapcrafters) [10:02] indeed, indeed [10:02] I'll see what I can do [10:03] zyga popey : thanks ! [10:04] Chipaca: do you have a second [10:04] i see a failure in something that looks like travis job stages [10:04] would you mind having a look? [10:04] I know nothing about that [10:04] https://travis-ci.org/snapcore/snapd/jobs/437096029 [10:04] zyga: where? [10:04] * Chipaca clicks [10:05] zyga: is that the right link? [10:05] twa [10:05] yes [10:05] : /home/travis/.travis/job_stages: eval: line 98: syntax error near unexpected token `newline' [10:05] line 450 [10:06] huh [10:06] I suspect thats from travis itself, no? [10:07] not sure [10:08] but looks like it's not a fatal but real proble [10:08] zyga: whatever it is, it seems to be innocuous [10:08] zyga: i see the same error in successful runs [10:08] e.g. https://travis-ci.org/snapcore/snapd/jobs/434561439 [10:08] zyga: with any luck the things it's spewing there aren't parts of any key :-) [10:09] i'll dig a little anyway [10:09] yeah, we just name variables with long hexadecimal names ;) [10:09] thanks! just something that caught my eye [10:10] zyga: https://github.com/travis-ci/travis-ci/issues/6174 [10:11] wow [10:11] we must up our use of bug report images [10:12] PR snapd#5929 closed: overlord/snapstate, tests: code tweaks, spread tests for aliases with parallel installed snaps (2.36) [10:15] hmmmmmmmmmmmₘₘₘₘₘₘₘₘₘₘ [10:15] little ₘ ? [10:17] 𝗡𝗼 [10:18] I wonder if the secure: encoding is brittle in that it needs to be in the exact same place in the yaml for it to work [10:18] OTOH the tests pass, so _something_ is working :) [10:18] I'll try moving them up to the top level later [10:23] hrm, hrm, it looks like opensuse tests are failing again [10:23] didn't we put those on manual? curl error 52 when talking to their repo [10:26] PR snapd#5932 opened: spread: put openSUSE to manual [10:27] mvo: yes, in master at least [10:28] it looks like it got reverted, I think we need it again, right now things are failing and I want to release 2.35.4 :/ [10:28] mvo: uh, ok, they were manual in master on wednesday :) [10:28] https://status.opensuse.org/ still partial outage of mirroring infra [10:29] wonder if the page is actually updated [10:33] mvo: yes but we reverted that [10:33] mborzecki: yeah, I saw changes yesterday [10:33] mvo: sorry about that, I flipped it back after seeing good results on my local machine [10:37] mmm [10:37] pstolowski: about getHotplugSlots [10:38] zyga: yes? [10:38] they override any implicit slots [10:38] as in [10:38] actually, any slots [10:38] should we not check that there are no clashes? [10:39] hrm, also travis is handing out slots really slowly [10:40] zyga: they won't, it's not visible in this PR, but when they are generated i ensure they have unique name (by appending a number if neccessary etc) [10:41] unique name among what set? [10:41] zyga: but perhaps an extra check + internal error here is a good idea? [10:42] hmm Chipaca degville you install snaps 'on' the system or 'in' the system? because the long and short help message disagree on this [10:43] on, in, to [10:43] pick one basically? [10:43] i don't have a strong reason to pick one over another [10:43] zyga: unique among all existing slots in the repo and all remembered slots for currently missing devices [10:43] maybe degville does :) [10:43] pstolowski: mm, but here we are presented with _a_ snap [10:43] we don't know what that snap has beforehand [10:43] I'd add a check, similar to implicit slots, that ensure we don't overwrite [10:46] zyga: i see what you mean, but this is a system snap, so only implicit + hotplug slots, no? [10:46] + whatever is defined in snap.yaml :) [10:47] hmmm do we actually do/support that? [10:49] zyga: ok, i'll check that, thanks for the remark! [10:49] thanks, I'm reading the rest [11:00] sil2100, your latest edge image seem to not have the latest pi3 gadget (i can sadly currently not check the gadget in the sstore atm, there was an issue when mvo tried to switch me over from @ubuntu.com to @canonical.com) can you re-build the edge image and make sure at least rev 27 of the gadget is in ? [11:01] sil2100, ondra tested on the b+ and a locally built image works fine, but the one on cdimage seems to still have rev 22 [11:02] ogra: wait, how is that possible? I checked the manifest and it said 27, as per my e-mail [11:02] Is the manifest wrong? [11:03] We build edge images daily btw. [11:03] dunno ... one sec [11:03] http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ubuntu-core-16-armhf+raspi3.img.xz [11:03] http://cdimage.ubuntu.com/ubuntu-core/16/20181005/ubuntu-core-16-armhf+raspi3.manifest [11:04] ogra: the images in the 'edge' directory haven't been updated since beginning of the year [11:04] http://cdimage.ubuntu.com/ubuntu-core/16/current/ [11:04] This is what should be used [11:04] ouch [11:04] we should clean that up then ;) [11:04] Yeah, not sure why it's so confusing! [11:04] Need to poke Steve next week why it's like that ;p [11:05] (maybe there's some purpose for that, or maybe something broke that was supposed to use the edge/ directory) [11:06] sil2100, there was initially ... websites had hardcoded links that needed to persist but i think thats bogus now [11:07] o we hould clean up or at least set proper channel links there [11:07] *so === chihchun is now known as chihchun_afk [11:14] mborzecki, Chipaca: sorry, only just seen this. I think I have a slight preference for *on* - but no strong feelings. You usually say 'I put Firefox on the computer' so it kind of makes sense that we keep to that casual usage. [11:19] it depends if the Firefox is quiet and doesn't move much, in that case you really have to put it in the computer and screw the side door tightly [11:19] see, this is why i don't have a preference, i'm still using chrome [11:20] Chipaca, hey [11:20] if you put chrome on your Firefox you may lose warranty [11:20] it makes the fur sticky [11:20] did you ping me yesterday? [11:20] The teenage years were tought, but my Firefox seems to be finally past that stage. [11:20] s/tought/tough [11:23] cachio: I did, but it's no longer relevant [11:23] now I'm worried for zyga's kids when they teen [11:24] Chipaca, hehee [11:25] ko [11:25] Chipaca: technically they now are [11:30] Chipaca: wanna be afraid more? [11:30] I may become a grandpa in the next 15 years [11:31] zyga: I don't need flags to Unlinkat, fwiw [11:31] no? [11:31] nope [11:32] I'm looking forward to one to simplify some code [11:32] only flag Unlinkat knows today is AT_REMOVEDIR, which I don't want [11:32] right, that's the one I want [11:32] hehe [11:32] sys/unix's Unlinkat does have that [11:32] fwiw [11:32] go itself has it [11:33] just doesn't expose it [11:33] I really don't like that logic [11:33] it's either sys call or stdlib [11:33] but in golang,it's a bit of both [11:40] zyga: #5933 [11:40] mmm [11:40] PR #5933: osutil, interfaces/apparmor: add and use of osutil.UnlinkMany [11:40] mborzecki, hey [11:40] zyga, (and probably kenvandine ) https://lists.ubuntu.com/archives/ubuntu-users/2018-October/295405.html [11:41] PR snapd#5933 opened: osutil, interfaces/apparmor: add and use of osutil.UnlinkMany