[01:23] <mup> PR snapd#5926 closed: store: tweak unmatched refresh result error log <Simple 😃> <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5926>
[01:25] <mup> PR snapcraft#2318 closed: meta: add support for the license field <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2318>
[05:02] <mborzecki> morning
[05:26] <zyga> Hey hey
[05:27] <zyga> Time to get to work
[05:39] <mborzecki> zyga: anything interesting happened yday?
[06:10] <zyga> Hmmm
[06:12] <zyga> Some things yeah
[06:12] <zyga> Currently taking the dog out so harder to type
[06:41] <mup> PR snapd#5923 closed: overlord: don't make become-operational interfere with user requests (2.35) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5923>
[06:41] <mup> PR snapd#5924 closed: overlord: don't make become-operational interfere with user requests (2.36) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5924>
[06:44] <mup> PR snapd#5928 closed: cmd: put our manpages in section 8 <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5928>
[06:50] <mborzecki> hm our socket unit files should probably just have `Wants=<mount unit> sockets.target` and we should not use network.target in there
[06:57] <mvo> mborzecki: indeed
[06:58] <mborzecki> i'll open a PR
[06:58] <mvo> ta
[06:58] <mborzecki> i'll be good to have it cherry picked to 2.36 too
[07:01] <mborzecki> 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] <mborzecki> 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] <zyga> mvo: are you tracking all the 2.36 PRs for backports?
[07:06] <mborzecki> good question, mvo should i open backport PRs to 2.36 of #5898 and #5905?
[07:06] <mup> PR #5898: tests: spread tests for aliases with parallel installed snaps <Parallel installs> <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5898>
[07:06] <mup> PR #5905: store: gracefully handle unexpected errors in 'action' response <Simple 😃> <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5905>
[07:09] <pstolowski> mornings
[07:14] <mvo> mborzecki: I think we can ignore the test one but the other one yes please
[07:14] <mvo> mborzecki: if its a single commit I can cherry pick
[07:14] <mborzecki> mvo: please cherry-pick the simple one
[07:15] <mborzecki> 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] <mvo> mborzecki: ok
[07:15] <mvo> mborzecki: cherry-picked
[07:15] <mborzecki> mvo: ta
[07:18] <zyga> mvo: should I prepare a chain of backports?
[07:19] <mup> PR snapd#5234 closed: snap: add `snap list --format=...` option <Decaying> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5234>
[07:19] <mvo> zyga: for what exactly?
[07:19] <zyga> For things I tagged 2.36 and landed in master
[07:20] <mup> PR snapd#5929 opened: overlord/snapstate, tests: code tweaks, spread tests for aliases with parallel installed snaps (2.36) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5929>
[07:20] <mvo> zyga: let me have a look
[07:20] <zyga> Ok, please let me know
[07:22] <mvo> 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] <zyga> Mmmm, interesting
[07:24] <zyga> What is the motivation for 2.35.3?
[07:25] <mvo> zyga: we need a fix for the unionfs issue on the livecd
[07:25] <zyga> Ah
[07:25] <mvo> zyga: without that the snaps on the live media do not start
[07:26] <zyga> Overlayfs
[07:26] <mvo> zyga: which is release criticial for cosmic
[07:26] <zyga> But sure
[07:26] <mborzecki> +1 for ~pre2 from master
[07:27] <mvo> ok, let me prepare 2.35.3 and then I look at this, until then, no more backport PRs please :)
[07:35] <zyga> Ok
[07:38] <ackk> 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] <ackk>  
[07:38] <ackk> (the same happens to a service in the snap)
[07:45] <zyga> ackk: this is fixed in master
[07:45] <zyga> Try beta/edge perhaps
[07:45] <ackk> zyga, of what?
[07:45] <ackk> snapd?
[07:46] <zyga> Yes
[07:46] <zyga> Well, core snap
[07:48] <ackk> yeah that worked.
[07:48] <pedronis> mvo: hi, seems we don't have a 2_35 tag in the forum?
[07:49] <mvo> pedronis: looking
[07:49] <mvo> pedronis: I added one now
[07:49] <pedronis> thanks
[07:49] <mvo> pedronis: and added it to "clarification on seed.loaded"
[07:50] <pedronis> mvo: yes, did the same, added 2.36 as well
[07:50] <pedronis> thank you
[07:51] <pedronis> :)
[07:52] <mvo> :)
[08:25] <Chipaca> morning peeps! welcome to Friday :) how do we close PRs today?
[08:27] <zyga> Wholesale
[08:27] <Chipaca> looking at my own PRs: #5879 can use another review
[08:28] <mup> PR #5879: vendor, cmd/snap: refactor to accommodate the new less buggy go-flags <Created by chipaca> <https://github.com/snapcore/snapd/pull/5879>
[08:28] <Chipaca> and #5888 also
[08:28] <mup> PR #5888: [RFC] use stages to run "cheaper" tests first <Created by chipaca> <https://github.com/snapcore/snapd/pull/5888>
[08:28] <zyga> I’ll help
[08:28] <Chipaca> wheee :)
[08:28] <zyga> Just back hurts somewhat today
[08:28] <Chipaca> zyga: you were fine yesterday before you decided to do this dodge "sleep" thing
[08:29] <Chipaca> dodgy*
[08:29] <Chipaca> also, review stuff or I'll make your browsers crash with emoji overload from looking at the pr page
[08:30] <zyga> Yeah, yesterday was too long
[08:30] <zyga> Not enough walking
[08:31] <Chipaca> ah, yeah, that'd suck
[08:31] <Chipaca> 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] <Chipaca> niemeyer: I got an email telling me you changed the standup meeting, but it looks the same to me. What's different?
[08:35] <Chipaca> niemeyer: (morning!)
[08:36] <niemeyer> Chipaca: moin! If I didn't do anything wrong, I just declined today's event
[08:36] <mvo> niemeyer: he is off today, no?
[08:36] <niemeyer> Yes, in theroy at least :)
[08:36] <mvo> heh
[08:37]  * Chipaca reaches for his get-off-irc-then stick
[08:37] <Chipaca> niemeyer: :) enjoy
[08:37] <Chipaca> google calendar is wacko, but holidays are good
[08:58] <mup> PR snapd#5930 opened: wrappers: do not depend on network.taget in socket units, tweak generated units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5930>
[08:59] <mborzecki> mvo: ^^
[08:59] <mvo> mborzecki: cool! looking
[09:00] <Chipaca> zyga: is #5170 ready for re-review?
[09:00] <mup> PR #5170: interfaces/builtin: add adb interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
[09:00] <mvo> mborzecki: uh, do we need this for 2.35 as well?
[09:00] <mvo> mborzecki: thats not a regression, is it?
[09:00] <mborzecki> hm, i'd say yes
[09:00] <zyga> Chipaca: I think so but let me double check
[09:01] <mborzecki> mvo: let me open a PR for 2.35 so that it gets a full spread run
[09:01] <mvo> mborzecki: uh, ok. that means 2.35.4
[09:01] <Chipaca> zyga: if so, I'd say @-mention the j of the d strand
[09:01] <zyga> yes John, it is ready
[09:01] <zyga> I wanted to get an ack from Gustavo first as s-j is busy lately
[09:02] <zyga> to avoid re-review if we change direction
[09:02] <mborzecki> mvo: while at it, i'd like to get the feedback if the change, once in edge, fixes problems people have observed
[09:05] <mvo> mborzecki: silly question but we remove network-online.target so what did we do that triggered a regression
[09:05] <mvo> mborzecki: hm, I see we just changed it to network.target
[09:06] <mvo> mborzecki: ok, but that is no regression, is it? I mean this was broken before
[09:06] <mvo> 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] <zyga> IMO serious bugs are serious bugs, regression or not
[09:08] <mvo> zyga: we had this serious bug from day one
[09:08] <mvo> zyga: well, since we added socket activation
[09:08] <zyga> let's fix it and move on :)
[09:09] <mvo> zyga: there is a cost, I'm not saying we shouldn't do it just want to understand the details
[09:09] <mvo> mborzecki: you have a review, looks great, just one comment
[09:12] <Chipaca> zyga: #5469 is also blocked on gustavo
[09:12] <mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
[09:12] <Chipaca> zyga: and that one's blocking a customer
[09:12] <mvo> Chipaca: my dotfiles as well
[09:12]  * Chipaca wants mvo's dotfiles
[09:13] <Chipaca> I'll auction them at sotheby's or something
[09:13] <mvo> Chipaca: haha
[09:13] <mvo> mborzecki: I pushed a tiny addition to your PR
[09:14] <mvo> mborzecki: (i.e. resolving my comment)
[09:14] <mvo> mborzecki: after thinking about this I think you (and zyga) are right, this is worth a 2.35.4
[09:18] <niemeyer> 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] <niemeyer> zyga: Flag file could be .experimental-snap-update-ns for example
[09:19] <zyga> 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] <niemeyer> zyga: This file is a trivial one-liner anywhere you want to test for it
[09:19] <zyga> niemeyer: perhaps this can even do away without an experimental flag it if lands after this release
[09:20] <niemeyer> zyga: as long as we're sure it works
[09:20] <zyga> yep
[09:21] <zyga> 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] <zyga> or telling snap-confine what snapd thinks about the distribution directory layout
[09:22] <zyga> but regardless, for user mounts we can unblock
[09:24] <mvo> mborzecki: happy to help with the backport of 5930 to 2.35
[09:29] <Chipaca> 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] <mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
[09:31] <mvo> mborzecki: aha, its there, nice!
[09:31] <mborzecki> 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] <mvo> mborzecki: aha, that makes sense
[09:35] <mup> PR snapd#5931 opened: wrappers: do not depend on network.taget in socket units, tweak generated units (2.35) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5931>
[09:35] <niemeyer> 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] <mborzecki> mvo: full PR to 2.35  ^^
[09:35] <mvo> ta
[09:36] <Chipaca> niemeyer: neat. I'll document this by retracting your PR.
[09:36] <Chipaca> dismissing it even
[09:37] <mvo> Chipaca: is it land-it-friday today :) ?
[09:37] <Chipaca> oh yes
[09:37] <Chipaca> mvo: we hit 50 PRs yesterday
[09:37] <mborzecki> mvo: 5930 needs your +1 too :)
[09:37] <Chipaca> mvo: you know how that affects me :)
[09:38] <mvo> mborzecki: indeed and a second review
[09:38] <mvo> Chipaca: haha, sounds like a good plan
[09:38] <Chipaca> niemeyer: now go away and enjoy yourself doing … whatever it is people do out there
[09:39] <Chipaca> :)
[09:39] <zyga> mvo: merge everything ;)
[09:39] <Chipaca> mvo: I'm even using my gh.go thing (which made me merge a bit too overeagerly yesterday, to pedronis's chagrin)
[09:39] <zyga> Chipaca: wow, the icons on hot plug are ... really nice!
[09:40] <Chipaca> hehe
[09:40] <niemeyer> 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] <Chipaca> niemeyer: ah. Make sure you get the derp eyes just right.
[09:41] <Chipaca> niemeyer: otherwise you might accidentally herobrine
[09:41] <zyga> and we will have to remove him in a point release!
[09:42]  * zyga wonders who gets Minecraft lore references...
[09:42] <ogra> did you guys break core ? my edge images just exploded in my face
[09:42] <zyga> ogra: break core on Friday? what are we, workaholics?
[09:42] <niemeyer> Yeah, we were trying to break it for a while..
[09:43]  * niemeyer steps out quietly..
[09:43] <ogra> avahi cant start anymore https://paste.ubuntu.com/p/RzH4y8TZDm/ and the only snap that got updated on this image was core
[09:43] <ogra> (the image was feshly built from edge yesterday evening)
[09:44] <zyga> ogra: and seriously, no idea, does it work if you switch core to stable?
[09:44] <ogra> on it, waiting for the reboot
[09:44] <zyga> thank you
[09:45] <Chipaca> zyga: #5469 GTG at your discretion
[09:45] <ogra> yes, works fine i can ping the mdns addres again
[09:45] <mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
[09:45] <ogra> *address
[09:46] <ogra> seems whatever landed in edge does not create XDG_RUNTIME_DIR for the app snaps
[09:46] <zyga> Chipaca: thanks, I think it is file to land
[09:46] <Chipaca> cool cool
[09:46] <mvo> ogra: core traveled back in time from edge to 2.35.3
[09:47] <mvo> ogra: now it has traveld back
[09:47] <mvo> ogra: but will soon travel again for 2.35.4
[09:47] <ogra> mvo, well, something broke
[09:47] <mup> PR snapd#5469 closed: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5469>
[09:47] <mvo> ogra: yeah
[09:49] <ogra> btw, is it normal that gadgets never survive delta generation ? all other snaps i push do it fine
[09:49] <zyga> hmm?
[09:49] <ogra> Error generating delta: There has been a problem while processing a snap delta.
[09:49] <ogra>   - Delta service failed to apply delta successfully
[09:49] <ogra> Falling back to pushing full snap...
[09:49] <ogra> with snapcrft push
[09:49] <ogra> *snapcraft
[09:49] <zyga> no idea but I doubt it's desired
[09:50] <ogra> k, because i have only seen it with gadgets
[09:50] <zyga> ogra: look if snap craft leaves a log with the reason for the failure
[09:51] <ogra> nope, doesnt ... (and i would be surprised, i think thats all happening server side after the upload)
[09:52] <zyga> no, the delta is local
[09:52] <zyga> it is a local delta for speeding up the upload
[09:52] <ogra> ah
[09:52] <ogra> indeed
[09:52] <ogra> my brain is kind of friday today :P
[09:56] <axino> hi
[09:56] <zyga> hello axino
[09:56] <axino> o/ zyga
[09:56] <axino> is this the proper place to ask how to get a snap owned by ~snapcrafters ?
[09:57] <zyga> axino: I think the forum is the better place
[09:57] <zyga> perhaps popey can help though
[10:00] <popey> hello
[10:00] <popey> axino: which snap?
[10:00] <axino> popey: a "redis" snap I'm currently building
[10:01] <popey> axino: have you spoken to the upstream redis people? :)
[10:01] <axino> popey: heh, I have not :)
[10:01] <popey> (We'd rather snaps went upstream first, rather than direct to snapcrafters)
[10:02] <axino> indeed, indeed
[10:02] <axino> I'll see what I can do
[10:03] <axino> zyga popey : thanks !
[10:04] <zyga> Chipaca: do you have a second
[10:04] <zyga> i see a failure in something that looks like travis job stages
[10:04] <zyga> would you mind having a look?
[10:04] <zyga> I know nothing about that
[10:04] <zyga> https://travis-ci.org/snapcore/snapd/jobs/437096029
[10:04] <Chipaca> zyga: where?
[10:04]  * Chipaca clicks
[10:05] <Chipaca> zyga: is that the right link?
[10:05] <zyga> twa
[10:05] <zyga> yes
[10:05] <zyga> : /home/travis/.travis/job_stages: eval: line 98: syntax error near unexpected token `newline'
[10:05] <zyga> line 450
[10:06] <Chipaca> huh
[10:06] <mvo> I suspect thats from travis itself, no?
[10:07] <zyga> not sure
[10:08] <zyga> but looks like it's not a fatal but real proble
[10:08] <Chipaca> zyga: whatever it is, it seems to be innocuous
[10:08] <Chipaca> zyga: i see the same error in successful runs
[10:08] <Chipaca> e.g. https://travis-ci.org/snapcore/snapd/jobs/434561439
[10:08] <Chipaca> zyga: with any luck the things it's spewing there aren't parts of any key :-)
[10:09] <Chipaca> i'll dig a little anyway
[10:09] <zyga> yeah, we just name variables with long hexadecimal names ;)
[10:09] <zyga> thanks! just something that caught my eye
[10:10] <Chipaca> zyga: https://github.com/travis-ci/travis-ci/issues/6174
[10:11] <zyga> wow
[10:11] <zyga> we must up our use of bug report images
[10:12] <mup> PR snapd#5929 closed: overlord/snapstate, tests: code tweaks, spread tests for aliases with parallel installed snaps (2.36) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5929>
[10:15] <Chipaca> hmmmmmmmmmmmₘₘₘₘₘₘₘₘₘₘ
[10:15] <mborzecki> little ₘ ?
[10:17] <Chipaca> 𝗡𝗼
[10:18] <Chipaca> 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] <Chipaca> OTOH the tests pass, so _something_ is working :)
[10:18] <Chipaca> I'll try moving them up to the top level later
[10:23] <mvo> hrm, hrm, it looks like opensuse tests are failing again
[10:23] <mvo> didn't we put those on manual? curl error 52 when talking to their repo
[10:26] <mup> PR snapd#5932 opened: spread: put openSUSE to manual <Created by mvo5> <https://github.com/snapcore/snapd/pull/5932>
[10:27] <mborzecki> mvo: yes, in master at least
[10:28] <mvo> 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] <mborzecki> mvo: uh, ok, they were manual in master on wednesday :)
[10:28] <mborzecki> https://status.opensuse.org/ still partial outage of mirroring infra
[10:29] <mborzecki> wonder if the page is actually updated
[10:33] <zyga> mvo: yes but we reverted that
[10:33] <zyga> mborzecki: yeah, I saw changes yesterday
[10:33] <zyga> mvo: sorry about that, I flipped it back after seeing good results on my local machine
[10:37] <zyga> mmm
[10:37] <zyga> pstolowski: about getHotplugSlots
[10:38] <pstolowski> zyga: yes?
[10:38] <zyga> they override any implicit slots
[10:38] <zyga> as in
[10:38] <zyga> actually, any slots
[10:38] <zyga> should we not check that there are no clashes?
[10:39] <mvo> hrm, also travis is handing out slots really slowly
[10:40] <pstolowski> 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] <zyga> unique name among what set?
[10:41] <pstolowski> zyga: but perhaps an extra check + internal error here is a good idea?
[10:42] <mborzecki> 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] <Chipaca> on, in, to
[10:43] <mborzecki> pick one basically?
[10:43] <Chipaca> i don't have a strong reason to pick one over another
[10:43] <pstolowski> zyga: unique among all existing slots in the repo and all remembered slots for currently missing devices
[10:43] <Chipaca> maybe degville does :)
[10:43] <zyga> pstolowski: mm, but here we are presented with _a_ snap
[10:43] <zyga> we don't know what that snap has beforehand
[10:43] <zyga> I'd add a check, similar to implicit slots, that ensure we don't overwrite
[10:46] <pstolowski> zyga: i see what you mean, but this is a system snap, so only implicit + hotplug slots, no?
[10:46] <zyga> + whatever is defined in snap.yaml :)
[10:47] <pstolowski> hmmm do we actually do/support that?
[10:49] <pstolowski> zyga: ok, i'll check that, thanks for the remark!
[10:49] <zyga> thanks, I'm reading the rest
[11:00] <ogra> 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] <ogra> 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] <sil2100> ogra: wait, how is that possible? I checked the manifest and it said 27, as per my e-mail
[11:02] <sil2100> Is the manifest wrong?
[11:03] <sil2100> We build edge images daily btw.
[11:03] <ogra> dunno ... one sec
[11:03] <ogra> http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ubuntu-core-16-armhf+raspi3.img.xz
[11:03] <sil2100> http://cdimage.ubuntu.com/ubuntu-core/16/20181005/ubuntu-core-16-armhf+raspi3.manifest
[11:04] <sil2100> ogra: the images in the 'edge' directory haven't been updated since beginning of the year
[11:04] <sil2100> http://cdimage.ubuntu.com/ubuntu-core/16/current/
[11:04] <sil2100> This is what should be used
[11:04] <ogra> ouch
[11:04] <ogra> we should clean that up then ;)
[11:04] <sil2100> Yeah, not sure why it's so confusing!
[11:04] <sil2100> Need to poke Steve next week why it's like that ;p
[11:05] <sil2100> (maybe there's some purpose for that, or maybe something broke that was supposed to use the edge/ directory)
[11:06] <ogra> sil2100, there was initially ... websites had hardcoded links that needed to persist but i think thats bogus now
[11:07] <ogra> o we hould clean up or at least set proper channel links there
[11:07] <ogra> *so
[11:14] <degville> 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] <zyga> 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] <Chipaca> see, this is why i don't have a preference, i'm still using chrome
[11:20] <cachio> Chipaca, hey
[11:20] <zyga> if you put chrome on your Firefox you may lose warranty
[11:20] <zyga> it makes the fur sticky
[11:20] <cachio> did you ping me yesterday?
[11:20] <degville> The teenage years were tought, but my Firefox seems to be finally past that stage.
[11:20] <degville> s/tought/tough
[11:23] <Chipaca> cachio: I did, but it's no longer relevant
[11:23] <Chipaca> now I'm worried for zyga's kids when they teen
[11:24] <cachio> Chipaca, hehee
[11:25] <cachio> ko
[11:25] <zyga> Chipaca: technically they now are
[11:30] <zyga> Chipaca: wanna be afraid more?
[11:30] <zyga> I may become a grandpa in the next 15 years
[11:31] <Chipaca> zyga: I don't need flags to Unlinkat, fwiw
[11:31] <zyga> no?
[11:31] <Chipaca> nope
[11:32] <zyga> I'm looking forward to one to simplify some code
[11:32] <Chipaca> only flag Unlinkat knows today is AT_REMOVEDIR, which I don't want
[11:32] <zyga> right, that's the one I want
[11:32] <Chipaca> hehe
[11:32] <Chipaca> sys/unix's Unlinkat does have that
[11:32] <Chipaca> fwiw
[11:32] <zyga> go itself has it
[11:33] <zyga> just doesn't expose it
[11:33] <zyga> I really don't like that logic
[11:33] <zyga> it's either sys call or stdlib
[11:33] <zyga> but in golang,it's a bit of both
[11:40] <Chipaca> zyga: #5933
[11:40] <zyga> mmm
[11:40] <mup> PR #5933: osutil, interfaces/apparmor: add and use of osutil.UnlinkMany <Created by chipaca> <https://github.com/snapcore/snapd/pull/5933>
[11:40] <cachio> mborzecki, hey
[11:40] <ogra> zyga, (and probably kenvandine ) https://lists.ubuntu.com/archives/ubuntu-users/2018-October/295405.html
[11:41] <mup> PR snapd#5933 opened: osutil, interfaces/apparmor: add and use of osutil.UnlinkMany <Created by chipaca> <https://github.com/snapcore/snapd/pull/5933>
[11:41] <cachio> I created the arch image with apparmor enabled but ...
[11:41] <mborzecki> cachio: hey
[11:41] <zyga> ogra: feels like interface(s) that fuel the gnome system monitor need improvements
[11:42] <cachio> mborzecki, I am having a problem wiht this machine
[11:42] <zyga>  pstolowski some reviews on hot plug PRs
[11:42] <Chipaca> ogra: is having the journal on disk the default?
[11:42] <cachio> mborzecki, it is not starting the google services
[11:42] <ogra> zyga, yeah ... note that we a) ship it by default and b) default to journald-to-disk logging now
[11:42] <cachio> mborzecki, so it can't be used by spread
[11:42] <ogra> Chipaca, i think so
[11:42] <zyga> meta comment I would prefer a pub-sub model over blind logging
[11:42] <zyga> but that's what we have
[11:43] <ogra> at least with 18.10
[11:43] <mborzecki> cachio: is it possible to access it via ssh?
[11:43] <cachio> mborzecki, it happens when we update the packages on that machine
[11:43] <cachio> mborzecki, no, via seria console
[11:43] <mborzecki> cachio: can i access that?
[11:43] <cachio> mborzecki, let me start one for you
[11:45] <Chipaca> ogra: why isn't it being rotated?
[11:46] <ogra> Chipaca, works differently ... its a ringbuffer and is by default limited to a certain percentage of the rootfs disk
[11:46] <ogra> on a multi terabyte disk 4GB is nothing ;)
[11:47] <mvo> 5930 needs a second review
[11:48]  * Chipaca looks
[11:49] <Chipaca> huh, i thought i'd done this one already
[11:55] <Chipaca> grrr opensuse
[11:55]  * Chipaca ~> lunch-making
[11:56] <zyga> Chipaca: commented
[11:56] <mborzecki> off to pick up the kids
[11:59]  * cachio afk
[11:59] <cachio> ~ 10 mins
[12:08] <Chipaca> zyga: d'oh, fixed
[12:09] <zyga> :D
[12:22] <pstolowski> zyga: thank you!
[12:23] <diddledan> popeycore sounds like an awesome music genre
[12:41] <mup> PR snapd#5931 closed: wrappers: do not depend on network.taget in socket units, tweak generated units (2.35) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5931>
[12:43] <zyga> I'll stop reviewing now
[12:44] <zyga> my back is not great today and it's hard to focus
[12:47] <mup> PR snapd#5932 closed: spread: put openSUSE to manual <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5932>
[12:55] <zyga> Chipaca: hey
[12:55] <zyga> Chipaca: I realized the touch bar is good for one thing for sure :)
[12:56] <zyga> 🐶🐼🐰🐽
[12:56] <zyga> irc was never this 🕷
[12:58]  * diddledan needs to google to find out how well it's supported in Linux
[12:59] <pstolowski> zyga: :D
[13:03] <Chipaca> diddledan: zyga: all you need to do is remember all the unicode code points, and then <ctrl>+<shift>+u1f577 <whitespace> gives you 🕷 tadaa
[13:03] <diddledan> hah
[13:03] <zyga> 😭
[13:04] <zyga> touchbar is useless then
[13:07] <Chipaca> zyga: U+1F631 FACE SCREAMING IN FEAR
[13:11] <Chipaca> brb renaming Hotplug to 🌶🔌
[13:16] <mup> PR snapd#5930 closed: wrappers: do not depend on network.taget in socket units, tweak generated units <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5930>
[13:29] <mup> PR snapd#5888 closed: [RFC] use stages to run "cheaper" tests first <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5888>
[13:31] <axino> popey: do you know a good example of a charm hosted upstream and building automatically ? I'm mostly wondering how to dynamically handle snap versions
[13:40] <mup> PR snapd#5934 opened: release: 2.35.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5934>
[13:41] <Chipaca> hmm, I know how i can speed up this :-D
[13:41]  * Chipaca will do it on Monday
[13:44] <mup> PR snapcraft#2293 closed: build providers: use the new snapcraft: remote for multipass <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2293>
[13:52] <zyga> sigh
[13:52] <zyga> mvo: yeah, I will just rebuild :/
[14:00] <mvo> zyga: rebuild the kernel?
[14:00] <zyga> yep
[14:01] <mvo> cachio: 2.35.4 is in the beta channel now
[14:10] <cachio> mvo, nice
[14:11] <cachio> I'll start
[14:11] <cachio> thanks
[14:14] <mvo> cachio: thank you!
[14:32] <mup> PR snapd#5935 opened: po: sync translations from launchpad <Created by mvo5> <https://github.com/snapcore/snapd/pull/5935>
[14:35]  * zyga uses this moment to build the kernel a few times 
[15:10] <zyga> mvo: you win the PR of the year award
[15:10] <zyga> +42,937, -2,729
[15:10] <zyga> wow
[15:11] <stgraber> mvo: hey there, so for those unix socket problems, (first network-online, then network.target), do we have an ETA for that landing in 18.10?
[15:11] <stgraber> mvo: we've seen a few reports of startup regression in cloud instances and the like ever since we started seeding LXD as a snap and enabled socket activation
[15:22] <mborzecki> stgraber: the 'fix' thing has landed in master, 2.36 and 2.35
[15:22] <mborzecki> would appreciate if you can check it on your end with core from edge (provided it's alreay been published)
[15:31] <mup> PR snapd#5934 closed: release: 2.35.4 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5934>
[15:38] <mvo> stgraber: I uploaded the fix some hours ago into cosmic
[15:38] <mvo> stgraber: let me see
[15:38] <mvo> zyga: haha - this PR is great, isn't it?
[15:38] <stgraber> mvo: ah, is it in the queue?
[15:39] <mvo> stgraber: yes
[15:39] <zyga> mvo: yes but also somewhat worrying, bad i18n can cause issues
[15:39] <mvo> stgraber: waiting for approval
[15:39] <stgraber> mvo: ok, let me review it quickly then
[15:39] <zyga> though go is much safer than C ever was so .. not terrible :)
[15:39] <mvo> zyga: indeed
[15:39] <mvo> stgraber: \o/
[15:40] <stgraber> mvo: accepted
[15:42] <mvo> stgraber: cool, thanks
[15:42] <pstolowski> to whom should i bow for the nice beautification of the hotplug label in github? ;)
[15:43] <mvo> pstolowski: probably Chipaca
[15:43] <Chipaca> lies
[15:43]  * Chipaca reads what he's been accused of
[15:43] <mvo> pstolowski: thats my guess at least
 brb renaming Hotplug to 🌶🔌
[15:44] <Chipaca> :-)
[15:44] <pstolowski> because he loves unicode?
[15:44] <zyga> 🌋
[15:45] <pstolowski> Chipaca: looking forward to parallel installs label ;)
[15:45] <Chipaca> pstolowski: Probably a bit much :) I'll revert it to the older one
[15:45] <mvo> pstolowski: unicode + beautiful sounds very much like Chipaca :)
[15:45] <Chipaca> there
[15:45] <zyga> ⛓
[15:45] <mvo> zyga: haha
[15:45] <Chipaca> #5880
[15:45] <mvo> Chipaca: I think its fine
[15:45] <mup> PR #5880: interfaces/repo: two helper methods for hotplug <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5880>
[15:46] <Chipaca> #5596
[15:46] <mup> PR #5596: [WIP] Parallel installs integration <Parallel installs ⛓> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5596>
[15:46] <Chipaca> zyga: ^ at your command
[15:46] <pstolowski> :)
[15:47] <zyga> Chipaca: please add one for user mounts 🏇
[15:47] <zyga> just because Friday is fun
[15:47] <pstolowski> heh
[15:47] <Chipaca> zyga: that chains thing doesn't work on github though
[15:47] <Chipaca> zyga: no contrast
[15:47] <zyga> btw, I think we could use projects rather than labels (for this)
[15:47] <zyga> mmm
[15:47]  * zyga looks
[15:47] <mborzecki> zyga: Chipaca: you can close it
[15:47] <mborzecki> that parallel installs WIP
[15:47] <Chipaca> zyga: you can create and edit labels too, you know? :)
[15:48] <Chipaca> whoa that was quick
[15:48] <mup> PR snapd#5596 closed: [WIP] Parallel installs integration <Parallel installs ⛓> <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5596>
[15:48] <Chipaca> mborzecki: no more parallel installs label then?
[15:49] <mborzecki> Chipaca: there will be one or two PRs more
[15:49] <Chipaca> ah ok
[15:50] <Chipaca> zyga: projects sounds nice, but I don't think they'll fit without quite a bit of admin on our end
[15:51] <zyga> admin? they are just like labels, just pick and go
[15:51] <mborzecki> heh we have this silly thing in arch in gce: https://paste.ubuntu.com/p/BJKrJ3yp7y/ so ssh starts, and then 10 minutes later actually starts listening on ports, wtf??
[15:51] <mborzecki> network is up way before that
[15:51] <Chipaca> zyga: "automated kanban with pull requests" using issues and stuff to trigger it
[15:51] <mborzecki> sshd is actually After=network.target
[15:52] <zyga> Chipaca: I don't know what you just said but that's fine, it's Friday and I'm booting my kernels
[15:52] <Chipaca> zyga: I think I'm going to go for a friday run, and then i'm going to have friday pizza and friday beer and maybe some friday guitar
[15:52] <zyga> I have a bottle of cider upstairs
[15:53] <zyga> but maybe I will take a ride on a bike before winter strikes
[15:53] <ogra> winter ?
[15:53] <ogra> do you also belive in santa ?
[15:53] <ogra> winter are over ... :P
[15:54] <ogra> *winters
[15:54] <mborzecki> w8, aren't they coming?
[15:54] <ogra> nah, we're letft with endless autumn now until jumping directly into summer in march
[15:57] <zyga> winter is coming, something something
[15:57] <zyga> my office is going to be feezing
[15:58] <zyga> it's not well insulated
[15:58] <mvo> Chipaca: if you do this you miss my review for 5913 ;)
[15:58] <mvo> Chipaca: but +100, run+pizza sounds way more fun
[15:58] <Chipaca> nooooo
[15:58]  * ogra pokes the armhf builders on build.s.io with a pointy stick ... come on your x86 firends have finished the 2min build 30 min ago ... there is no reason to say "Building soon" !
[15:58] <Chipaca> mvo: I've been told I said the run was at 5, so if it's not 5 they're not going yet
[15:58] <zyga> mvo: it's actually slower than the desktop :/
[15:59] <zyga> but well, it's a laptop :)
[16:00] <Chipaca> mvo: _now_ i'm off. But I'll give the review a look before the beer.
[16:02] <mvo> zyga: what is slower than the desktop?
[16:02] <zyga> the laptop
[16:02] <mvo> Chipaca: heh, no need, enjoy your WE
[16:02] <mvo> zyga: aha, ok
[16:06] <pstolowski> Chipaca: any chance for +1 on https://github.com/snapcore/snapd/pull/5497 (i did the rename)?
[16:06] <mup> PR #5497: overlord/patch: patch for static plug/slot attributes <Created by stolowski> <https://github.com/snapcore/snapd/pull/5497>
[16:07] <pstolowski> (nad now as i fixed the trivials in my PRs, travis hates everything again)
[16:08] <pstolowski> Chipaca: ah, you're off. have a good weekend!
[16:08] <pstolowski> good idea, actually
[16:09] <ogra> cjwatson, put away the mop ! (... watching armhf on https://launchpad.net/builders)
[16:10] <cjwatson> ogra: see #launchpad-ops
[16:10] <ogra> (well, in fact watching arm64 but waiting for armhf capacity)
[16:10] <cjwatson> ogra: IS is working on it
[16:10] <ogra> ah, good
[16:11] <ogra> thanks (i just wanted to make a bad friday joke anyway :P )
[16:15] <mvo> Chipaca: added some comments, hope I'm not too annoying, I guess I shouldn't review when hungry
[16:26] <mup> Bug #1796362 opened: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks <Snappy:New> <https://launchpad.net/bugs/1796362>
[17:26] <mup> PR snapd#5933 closed: osutil, interfaces/apparmor: add and use of osutil.UnlinkMany <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5933>
[17:29] <zyga> it's still building...
[17:29] <zyga> I tweaked a few things and restarted the process twice
[17:29] <zyga> mainly to add space to the VM :)
[17:29] <zyga> and to up the thread count
[17:35] <mup> PR snapcraft#2323 opened: go plugin: support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2323>
[17:36] <sergiusens> mvo: that is probably close to your heart in case you want to check ^
[18:02] <Chipaca> EOW
[18:02] <Chipaca> o/
[18:21] <zyga> linux-image-4.18-unsigned from cosmic, dpkg-build in a VM + music + some casual browsing took  76 minutes and wrote over 40GB of data!
[18:41] <Pharaoh_Atem> zyga, mvo: this should be fixed now: https://github.com/snapcore/snapd/commit/79b85c4009032cf61864ced46b97abe3793efbee
[18:41] <mup> PR snapcraft#2324 opened: plugins: remove the ament plugin when using a base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2324>
[18:44] <mup> PR snapd#5936 opened: Revert "spread: put openSUSE to manual" <Created by zyga> <https://github.com/snapcore/snapd/pull/5936>
[18:45] <zyga> thanks Pharaoh_Atem
[19:00] <mup> PR snapcraft#2325 opened: plugins: remove the python2 and python3 plugin when using a base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2325>
[19:07] <pedronis> zyga: do you remember why we validate plug/slot name only when they are added to the repo and not when parsing snap.yaml ?
[19:09] <zyga> mmmmm
[19:10] <zyga> I was hoping we would validate the yams and then each added one
[19:10] <zyga> but I don't remember at this time more
[19:10] <zyga> I mean, we should definitely validate in the yaml
[19:10] <zyga> AFAIK we moved validation there even (the patterns)
[19:11] <pedronis> actually we don't validate them even when adding
[19:11] <pedronis> is done in AddSlot/AddPlug
[19:11] <pedronis> but that is not really used
[19:11] <zyga> mmm
[19:11]  * zyga looks
[19:12] <pedronis> you can have a 22.33 slot afaict
[19:12] <pedronis> (unless I'm missing something)
[19:12] <zyga> correct
[19:12] <zyga> wow, that's bad :/
[19:13] <zyga> AddSnap calls Validate
[19:13] <zyga> but Validate doesn't
[19:13] <zyga> I guess we call sanitise
[19:14] <zyga> in the end
[19:14] <zyga> perhaps that's why?
[19:14] <zyga> but the name validation should be done earlier
[19:14] <pedronis> does sanitize check the name?
[19:15] <zyga> no, it's an optional helper, it used to be different before but not anymore
[19:15] <zyga> looking at this briefly nothing does now
[19:15] <pedronis> yea
[19:15] <pedronis> seems you can have fairly random plug/slot names atm
[19:15] <zyga> I'll fix that
[19:15] <zyga> correct
[19:20] <pedronis> we do have ValidateSlot/PlugName in snap but is not used in validate code
[19:21] <jdstrand> zyga: does opensuse-42.3-64 correspond to tumbleweed?
[19:23] <zyga> pedronis: yep, branch coming up soon
[19:23] <zyga> jdstrand: no, that is LEAP 42.3 (older LEAP, current one is .. 15)
[19:23] <zyga> tumblweed is just that
[19:23] <pedronis> zyga: same for ValidateInterfaceName btw
[19:23] <pedronis> not called
[19:24] <zyga> pedronis: yeah, they are called from interfaces/
[19:24] <zyga> I moved them to snap to de-duplicate the code
[19:24] <zyga> but something got lost along the way
[19:24] <pedronis> but not in all relefvant cases
[19:24] <pedronis> anyway we want to use them in validate code itself
[19:25] <pedronis> wonders if there are weird plug/slot out there
[19:25] <pedronis> given the missing validation
[19:25]  * jdstrand wonders why spread -list doesn't list anything with opensuse any more
[19:25] <pedronis> jdstrand: it might have been set ot manual
[19:25] <pedronis> not sure if that influences -list or not
[19:25] <zyga> jdstrand: opensuse was disabled
[19:25] <zyga> https://travis-ci.org/snapcore/snapd/builds/437765662
[19:25] <jdstrand> I'm looking at an old travis failure
[19:25] <jdstrand> oh, heh, ok
[19:29] <jdstrand> zyga: otoh, if I'm in the code that it setting up a snippet in one interface, can I query if another interface is specified/connected?
[19:29] <zyga> I don't believe so
[19:29] <jdstrand> that's sucky
[19:29] <zyga> what would you like to do?
[19:30] <jdstrand> me fears about 'ix' in the home interface have thus come true
[19:30] <jdstrand> my*
[19:30] <zyga> I see
[19:30] <zyga> well, we _could_ fix that
[19:30] <zyga> the specification could gain a query API
[19:30] <zyga> like spec.IsTypeConnected("home")
[19:30] <zyga> it's not hard to add in our model now
[19:31] <jdstrand> docker-support will need a change-profile unsafe... rule, but docker snaps have home connected. the combination causes a parser error
[19:31] <jdstrand> so I need to strip out the 'ix' there
[19:31] <pedronis> mmh
[19:32] <pedronis> that is not a simple problem
[19:32] <pedronis> we don't connect interfaces as groups
[19:32] <pedronis> they come one by one
[19:32] <pedronis> so we would need to deal with both directions
[19:32] <jdstrand> for this, I really only need to know if docker-support is plugged at all
[19:33] <pedronis> it can get connected later
[19:33] <jdstrand> because in practice, anything using that will have it connected (it is a super privileged interface)
[19:33] <pedronis> jdstrand: you don't know if they will be connected in a given order
[19:33] <pedronis> or the other
[19:33] <jdstrand> so in practice it will always be connected. and I only need this for the docker-support interface
[19:34] <jdstrand> pedronis: that's is what I'm saying. for this very specific case, I don't actually care about connection order because in practice, in the real world, if docker-support is in plugs, it will be connected, because of the nature of how we grant snap declarations for it
[19:35] <pedronis> jdstrand: I'm not understanding, it sounds fragile or I'm missing something
[19:35] <jdstrand> pedronis: so, to unblock the k8s work, I only really need in the home interface to know if docker-support is plugged, not connected. if it is, we just assume it is connected and drop the ix
[19:35] <jdstrand> pedronis: it isn't fragile, it makes a simple assumption
[19:35] <zyga> pedronis: that's fine, I think, because if it is connected later the same method will be called (to compute the policy) and we can just do the right thing
[19:36] <zyga> pedronis: it doesn't have to check both ways, it can just check the current state
[19:36] <jdstrand> in the home interface, behave like normal in all cases unless docker-support happens to be plugged. then drop some ix rules
[19:36] <pedronis> what does plugged mean?
[19:36] <jdstrand> and by plugged, I do *not* mean connected
[19:36] <pedronis> that the snap has a plug?
[19:36] <jdstrand> whether it is connected or not, you don't get ix if your snap plugs docker-support with home
[19:36] <jdstrand> plugs:
[19:37] <jdstrand>   home: null
[19:37] <jdstrand>   docker-support: null
[19:37] <jdstrand> in this case *only*, home drops some ix rules
[19:37] <pedronis> I seee
[19:37] <pedronis> it's kind of a hack and a layering violation tough
[19:37] <jdstrand> yes
[19:38] <jdstrand> but when we added the ix rule to the home interface, we added a potential apparmor conflict
[19:39] <jdstrand> that conflict is here now, because docker-support must have a special rule to fix k8s. it didn't exist before
[19:39] <jdstrand> I warned about this btw
[19:39] <zyga> pedronis: 5937
[19:39] <zyga> jdstrand: another idea
[19:39] <mup> PR snapd#5937 opened: snap: validate plug and slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/5937>
[19:39] <zyga> jdstrand: you can fix this in compose
[19:40] <jdstrand> but I couldn't forsee the use case that would cause the problem
[19:40] <zyga> jdstrand: AddConditinalSnippet("...", func() { ... })
[19:40] <zyga> then at compose level we can decide
[19:40] <zyga> something along those lines
[19:40] <jdstrand> zyga: oh, where is that?
[19:40] <zyga> we don't have that
[19:40] <zyga> but it is another thing we could add
[19:40] <zyga> then interfaces are still "easy"
[19:40] <zyga> and operate at their own layer
[19:41] <zyga> but the backend can do smarter things when combining snippets
[19:41] <zyga> right?
[19:41] <zyga> it's a bit late so I won't jump at implementing that now but I think it is doable
[19:41] <zyga> (both this and exposing connections to the specification, technically, probably one is cleaner than the other)
[19:42] <jdstrand> zyga: well, I could probably do something right before the snippets are written out and do the equivalent of a sed. that would be pretty terrible though
[19:42] <zyga> that's deriveContent
[19:42] <zyga> in apparmor/backend.go
[19:42] <jdstrand> yeah
[19:42] <pedronis> jdstrand: anyway ConnectedPlug has Snap so you should be able to get to the info
[19:43] <jdstrand> I think I will propose something with ConnectedPlug cause the logic would be simple, if a bit of a hack, and easier to remove once there was a proper solution
[19:44] <zyga> hmmm
[19:44] <zyga> jdstrand: can you tell me what you would do?
[19:44] <jdstrand> in the home interface:
[19:44] <zyga> I'm not sure connected plug and the info are enough tell you something is or is not connected
[19:44] <zyga> I hope I'm wrong though :)
[19:44] <jdstrand> use_ix = true
[19:44] <zyga> mmm
[19:44] <jdstrand> if docker-support in plugs:
[19:45] <jdstrand>    use_ix = false
[19:45] <jdstrand> ...
[19:45] <zyga> ah, regardless of connection status?
[19:45] <jdstrand> yes
[19:45] <zyga> ah, that's doable easily
[19:45] <zyga> go for it :)
[19:45] <jdstrand> right
[19:45] <zyga> but my suggestion is
[19:45] <zyga> look at interface type rather than the name
[19:45] <zyga> I'm sure you meant that
[19:45] <zyga> but just wanted to say that just in case :)
[19:45] <zyga> Friday evening and all that
[19:45]  * jdstrand nods
[19:46] <zyga> pedronis: I'll add a spread test for the validation later on, today I just want to see if this passes as-is
[19:46] <zyga> if any tests we have now have invalid plug and slot names by accident
[19:46] <jdstrand> the above is 'wrong' cause technically use_ix is only false if docker-support is connected. but in practice you need an installation constraint for docker-support and so if we grant that you get auto-connect too
[19:47] <jdstrand> and, the type of snap that has docker-support is, well, docker, and it will fall over without it, so disconnecting is infeasible for a working snap
[19:47] <jdstrand> really, we shouldn't have interface combinations that conflict with each other, but alas, we do
[19:47] <pedronis> zyga: wonder if we should validate the interface name in the slots and plugs
[19:47] <pedronis> as well
[19:48] <zyga> perhaps but that one is more or less harmless
[19:48] <pedronis> it it's invalid it will also be a non-existing interface so we will ignore it
[19:48] <pedronis> atm
[19:48] <zyga> and we do validate that at some stage against known interfaces
[19:48] <zyga> we said we would not reject unknown interfaces
[19:48] <zyga> just ignore them
[19:49] <pedronis> yes
[19:49] <zyga> so I think that's the best we can do
[19:49] <zyga> we _could_ validate the actual name but that's a small extra
[19:49] <pedronis> but this is about malformed names, no unknown
[19:49] <pedronis> not unknown
[19:49] <zyga> I mean, I don't oppose it, I think we already do at another level
[19:49] <zyga> but perhaps I'm wrong as with the initial validation
[19:49] <zyga> but all known names are not malformed :)
[19:49] <zyga> so if not known then we don't care
[19:49] <zyga> still, I see your point
[19:50] <zyga> we could just be more aggressive about invalid names in general
[19:51] <pedronis> zyga: I just think it would be more consistent, and given we are adding it for slots and plugs
[19:51] <pedronis> it would be a good idea
[19:51] <pedronis> instead of adding it later
[19:51] <pedronis> again
[19:51] <zyga> yes
[19:51] <zyga> +1
[19:57] <zyga> pedronis: pushed
[20:00] <zyga> pedronis, jdstrand ^ review on that appreciated
[20:00] <zyga> would love to see it in 2.36 for mvo
[20:00] <pedronis> zyga: +1 with a comment
[20:00] <Pharaoh_Atem> zyga: are we looking to have 2.36 soon?
[20:00] <zyga> I hope so
[20:00] <zyga> pedronis: I saw, good point,
[20:00] <Pharaoh_Atem> also...
[20:00]  * Pharaoh_Atem pokes kyrofa
[20:01] <jdstrand> zyga: what pr?
[20:01] <zyga> jdstrand: 5937
[20:02] <zyga> `plug "plug" has invalid interface name "i--face"`
[20:03] <zyga> anyone wants to suggest better wording?
[20:04] <pedronis> invalid inteface name "i--face" for plug "plug"
[20:04] <pedronis> ?
[20:06] <zyga> nicer, thanks
[20:08] <zyga> pushed
[20:09] <zyga> thanks pedronis, that's a very good find for Friday evening
[20:10] <pedronis> zyga: it's actually jdstrand that made me go dig into this, because he noticed that one could happily use numbers
[20:10] <pedronis> in those places (because of our type-directed YAML parsing of some things)
[20:10] <pedronis> 1234 plug anyone
[20:12] <zyga> 1337 plugs FTW
[20:13]  * zyga clones ubuntu kernel and sees that only 12% managed to flow so far :/
[20:13] <zyga> I guess I'll be patching tomorrow
[20:13] <zyga> have a great night everyone!
[20:14] <jdstrand> bye zyga :)
[20:21] <kyrofa> Hey there Pharaoh_Atem
[20:21] <Pharaoh_Atem> kyrofa: how are things coming along with snapcraft?
[20:23] <kyrofa> Pharaoh_Atem, pretty good from my perspective, but it depends on what exactly you're looking for!
[20:25] <Pharaoh_Atem> well, principally being able to reasonably use it to produce Fedora based snaps ;)
[20:27] <kyrofa> Pharaoh_Atem, there are two things I can think of that will be needed. First of all, the way snapcraft will be supporting other bases is by way of VM images for the base, so a fedora one will be required. Second, snapcraft is still missing any sort of dnf backend
[20:30] <kyrofa> Either one of those could be tackled independently from the other
[20:46] <Pharaoh_Atem> kyrofa: the VM images thing is going to be a problem for running snapcraft in a koji build or something
[20:46] <Pharaoh_Atem> since they'll be running in restricted nspawn containers
[20:48] <kyrofa> Pharaoh_Atem, there is a "destructive" mode as well that will run on the host, but that will still require the dnf backend
[20:49] <kyrofa> It also isn't quite as clean
[20:49] <Pharaoh_Atem> that's fine
[20:49] <Pharaoh_Atem> Koji purges the container environments after use4
[20:49] <Pharaoh_Atem> *use
[20:49] <Pharaoh_Atem> it's not stupid enough to reuse them
[20:49] <kyrofa> Yeah similar to what we do
[20:50] <Pharaoh_Atem> there are a few build systems that do reuse chroots, but they're irrelevant since no large distro uses them
[20:50] <Pharaoh_Atem> kyrofa: I tried to write a DNF backend a long time ago, but it was too hard :(
[20:51] <kyrofa> Pharaoh_Atem, the only thing you might consider is, let's say we have a fedora VM image: how different will it be from koji?
[20:51] <Pharaoh_Atem> kyrofa: koji does a mock container setup
[20:51] <Pharaoh_Atem> the main things are: no real devfs, no kernel access, etc.
[20:51] <Pharaoh_Atem> and in the case of Fedora's Koji instance, no internet access
[20:53] <cjwatson> Sounds familiar, though we use throwaway VMs rather than containers.  Sounds like koji might in fact be an even more restrictive environment than Launchpad in some ways from the POV of snapcraft
[20:53] <kyrofa> Indeed
[20:53] <kyrofa> Pharaoh_Atem, sounds like this is all moot without dnf support though, which isn't really on our immediate roadmap
[20:54] <Pharaoh_Atem> cjwatson: SUSE's OBS is equally restrictive, though they default to VMs
[20:54] <cjwatson> Yeah, I'm surprised Fedora doesn't in fact
[20:54] <Pharaoh_Atem> (they support LXC containers as a fallback)
[20:54] <cjwatson> Maybe they have fewer untrusted builds
[20:55] <Pharaoh_Atem> cjwatson: Fedora COPR (where our PPA-like infra is) uses VMs
[20:55] <cjwatson> Right, makes sense
[20:55] <Pharaoh_Atem> since Koji is used _exclusively_ for distro packages, containers work fine
[20:55] <cjwatson> We deliberately share infra between the two uses because it gives us better density
[20:55] <Pharaoh_Atem> if the two systems were to merge (as I hope they will eventually), it'll probably be build VMs
[20:58] <Pharaoh_Atem> kyrofa: if I could get some help from you, I'd like to look at getting snapcraft a DNF backend soon
[20:59] <Pharaoh_Atem> today, every major RPM based distro (and some minor ones) have DNF in a functional state so that their distro repos can be managed with it
[20:59] <Pharaoh_Atem> even Yocto derivatives that use RPM (like Wind River Linux) use DNF now
[21:00] <kyrofa> Pharaoh_Atem, sure thing. Not sure what your schedule is like, but mine will be a little more open after 18.10 ships
[21:00] <Pharaoh_Atem> that's probably a reasonable window for me too
[21:00] <kyrofa> Good deal
[21:01] <Pharaoh_Atem> I did this a while ago, but obviously didnt' get far: https://github.com/Conan-Kudo/snapcraft/blob/repo_rpm/snapcraft/internal/repo/_rpm.py
[21:25] <mup> PR snapd#5937 closed: snap: validate plug and slot names <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5937>
[21:26] <mup> PR snapd#5921 closed: spread-shellcheck: use threads to parallelise <Simple 😃> <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5921>
[21:26] <mup> PR snapd#5936 closed: Revert "spread: put openSUSE to manual" <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5936>
[23:04] <mup> PR snapd#5938 opened: [test] Tweak cla checker <Created by chipaca> <https://github.com/snapcore/snapd/pull/5938>