[04:37] <mup> PR snapd#7512 closed: interfaces/docker-support,kubernetes-support: misc updates for strict k8s <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7512>
[04:39] <mup> PR snapd#7513 closed: interfaces/docker-support,kubernetes-support: misc updates for strict k8s - 2.42 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7513>
[05:02] <mborzecki> morning
[05:19] <mup> PR snapd#7514 opened: cmd: add `snap debug bootvars` that dumps the current bootvars <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7514>
[05:19] <mvo> hey mborzecki
[05:19] <mborzecki> mvo: hey
[05:20] <mborzecki> mvo: should we allow dumping of all bootvars too?
[05:21] <mborzecki> mvo: since we've taken away all the tools to inspect them
[05:22] <mvo> mborzecki: we don't have an interface in our bootloaders to say "give-me-all"
[05:23] <mvo> mborzecki: plus uboot will have a whole lot of unrelated stuff
[05:23] <mvo> mborzecki: but yeah, it could be useful but I am not sure how to do it?
[05:26] <mborzecki> mvo: i see, teh Bootloader interface would need to be extended
[05:27] <mborzecki> mvo: otoh, we build a map of all bootarg=value anyway, at least for grub and uboot
[05:27] <mvo> mborzecki: yeah and its a bit unclear how this would apply to e.g. lk
[05:29] <mborzecki> mvo: i suppose for lk it'd be ok to return just snap_*, reboot_reason and bootimg_file_name, there does not seem to be a genereic environment mechanism like uboot has
[05:30] <mvo> mborzecki: right
[05:32] <mborzecki> mvo: can you take a look at #7509? i still need to address the panics in the tests, we have helpers for packing snap files in the test but the test data is incomplet witht he checks i added
[05:32] <mup> PR #7509: gadget, snap/pack: perform extended validation of gadget metadata and contents <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7509>
[05:33] <mvo> mborzecki: sure
[05:33] <mborzecki> mvo: thanks!
[05:51] <mvo> mborzecki: is the test failing for silly reasons in that pr, i.e. does it just need a restart?
[05:51] <mvo> mborzecki: I had some green runs this morning :)
[06:10] <mborzecki> mvo: it's failing bc of the PR, i need to push one more fix there
[06:14] <mvo> mborzecki: ok
[06:51] <mborzecki> mvo: the checks have failed in #7514, something about a cmd/snap-seccomp/s.c in the tree
[06:51] <mup> PR #7514: cmd: add `snap debug bootvars` that dumps the current bootvars <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7514>
[06:51] <mvo> mborzecki: oh, woah
[06:51] <mvo> mborzecki: I did not touch this, let me look at the failure
[06:53] <mvo> mborzecki: this test failure is bizare
[07:05] <mvo> mborzecki: looks like 7166 can almost land (just two small comments from samuele). thanks again for picking this one up!
[07:05] <pstolowski> morning
[07:05] <mvo> hey pstolowski
[07:05] <mborzecki> mvo: yup will address those soonish
[07:05] <mborzecki> pstolowski: hey
[07:12] <mup> PR snapd#7515 opened: daemon: return "snapname_rev.snap" style when using /v2/download <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7515>
[07:15] <mvo> thanks for your review pedronis \o/
[07:18] <zyga> Hey guys. I will file today off, if feel much worse than yesterday.
[07:19] <zyga> Time to really get better
[07:20] <mvo> zyga: uh, get some rest
[07:20] <pstolowski> hi, get well zyga!
[07:24] <pedronis> mvo: hi, made some initial comments asking for changes also in #7510
[07:24] <mup> PR #7510: daemon: make /v2/download take snapDownloadOptions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7510>
[07:25] <mvo> pedronis: thanks
[07:27] <pedronis> zyga: get well!
[07:46] <mup> PR snapd#7434 closed: seed/seedwriter: implement WriteMeta and tree16 corresponding code <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7434>
[07:53] <pedronis> #7441 and #7467 are ready for review
[07:53] <mup> PR #7441: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7441>
[07:53] <mup> PR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7467>
[08:00] <pedronis> mvo: couple more comment in 7514, I missed the Bootvars the first time around
[08:02] <mvo> pedronis: thanks, fixing that now as well
[08:19] <mborzecki> mvo:  are you planning to pick bootvars into 2.42?
[08:22] <mvo> mborzecki: not really, why?
[08:23] <pedronis> mvo: is John swapping today?
[08:23] <mborzecki> mvo: #7508 is tagged for 2.42, wondering whether to land it now or wait for bootvars to land first, 7508 get updated and have both cherry-picked to 2.42
[08:23] <mup> PR #7508: tests: skip the ubuntu-core-upgrade on arm devices on core18 <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7508>
[08:24] <mvo> pedronis: let me check, iirc no but I could be wrong
[08:24] <mvo> mborzecki: yeah, should be ok to skip on 2.42 as long as we fix master
[08:25] <mborzecki> mvo:  ok, landing 2.42 then
[08:25] <mborzecki> duh, landing 7508
[08:25] <mvo> mborzecki: heh, ok
[08:25] <mvo> mborzecki: I was worried for a moment
[08:25] <mvo> pedronis: nothing in the calendar
[08:25] <mvo> pedronis: maybe just a bit late?
[08:26] <mup> PR snapd#7508 closed: tests: skip the ubuntu-core-upgrade on arm devices on core18 <Simple 😃> <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7508>
[08:26] <mborzecki> mvo: on that note, can you cherry-pick bb963563d0a8a1ad406a512c539072ca24ba8336 from that PR into 2.42 ?
[08:27] <mvo> mborzecki: sure thing
[09:01] <popey> zyga: friend of mine noticed snaps seem a broken on 19.10 - and found this bug https://bugs.launchpad.net/snappy/+bug/1656340  - any ideas?
[09:01] <mup> Bug #1656340: XDG_RUNTIME_DIR is not created on app startup <bionic> <cosmic> <eco-team> <xenial> <Snappy:Triaged by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1656340>
[09:04] <Chipaca> stgraber: is running nested snapped lxds supported? asking because #1777017 so either there are more steps needed, or we're doing something wrong
[09:04] <mup> Bug #1777017: snap install lxd doesn't work within a container <AppArmor:Invalid> <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1777017>
[09:32] <mup> Bug #1622336 changed: [DOC] snappy on KVM recommends cmd line that warns about RAW devices <Snappy:Fix Released> <https://launchpad.net/bugs/1622336>
[09:35] <mup> Bug #1621769 changed: impossible to create a model assertion compatible with both snapd 2.13 and 2.14 <Snappy:Won't Fix by mvo> <https://launchpad.net/bugs/1621769>
[09:39] <mup> PR snapd#7516 opened: daemon: allow /v2/assertions/{assertType} to query store <Created by mvo5> <https://github.com/snapcore/snapd/pull/7516>
[10:14] <Chipaca> pedronis: #1662534 is interesting, passphrases can't end in whitespace because of how we use gpg
[10:14] <mup> Bug #1662534: snap create-key misses space at end of passphrase <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1662534>
[10:14] <Chipaca> or because gpg :-)
[10:14] <mborzecki> wow, whitespace in passwords
[10:17] <pedronis> Chipaca: sounds strange, I don't think we are in charge of the i/o there
[10:18] <pedronis> but maybe I'm missing something
[10:18] <Chipaca> pedronis: as I say there, gpg strips whitespace from the batch mode thing
[10:19] <Chipaca> it's documented under "unattended gpg key generation" in the info pages
[10:19] <pedronis> Chipaca: ok, sounds low to me
[10:19] <Chipaca> totes :-)
[10:20] <Chipaca> but it's the sort of thing that can have you lose a lot of time if you don't know about it
[10:20] <Chipaca> and as we are in control of _reading_ the passphrase, maybe we could warn?
[10:20] <pedronis> sounds still low
[10:21] <pedronis> Chipaca: are you asking me if you should had a warning today
[10:21] <pedronis> ?
[10:21] <pedronis> s/had/add/
[10:21] <Chipaca> pedronis: no
[10:21] <Chipaca> i agree it's low
[10:21] <Chipaca> i'd say the low thing is to warn / block a passphrase we know is not going to work
[10:21] <Chipaca> somehow fixing it so it works would be a "nah" :)
[10:22] <pedronis> that can be even medium
[10:22] <pedronis> Chipaca: I'm just a bit missing what input you need from me right now?
[10:22] <Chipaca> pedronis: nothing, just sharing an obscure bit of info
[10:22] <Chipaca> otherwise it's just me that knows this :)
[10:22] <Chipaca> me and launchpad
[10:23] <pedronis> ok, maybe I will retain it, or not :)
[10:23] <Chipaca> heh
[10:23] <Chipaca> i forget not everybody's brain is a sponge for stupid trivia
[10:25] <Chipaca> pstolowski: https://paste.ubuntu.com/p/qy4Y3mgm2h/
[10:26] <Chipaca> pstolowski: you're probably the most comfortable in that bit of code (configstate), care to look and see if that panic could still happen today?
[10:27] <pstolowski> Chipaca: ah, you got me nervous for a second, it is a very old bug isn't it?
[10:28] <Chipaca> pstolowski: yes :-)
[10:28] <pstolowski> Chipaca: bug# for more context? i'll check it
[10:28] <Chipaca> pstolowski: #1670501
[10:28] <mup> Bug #1670501: invalid memory address or nil pointer dereference in transaction.go <snapd (Ubuntu):New> <https://launchpad.net/bugs/1670501>
[10:29] <pstolowski> Chipaca: ty
[10:29] <Chipaca> pstolowski: if you answer, start by apologising for us being bad at bugs
[10:29] <Chipaca> please :-)
[10:31] <pstolowski> Chipaca: i'll be very humble
[10:34] <cjwatson> white space> TIL
[10:34] <Chipaca> zyga: #1681068 is all yours
[10:34] <mup> Bug #1681068: Unable to use content interface with read-write source paths bind mounted over read-only targets <snapd (Ubuntu):New> <https://launchpad.net/bugs/1681068>
[10:35] <Chipaca> zyga: and #1681099 i guess
[10:35] <mup> Bug #1681099: Bind mounting is not performed when a directory created in a config hook is used with the content interface <snapd (Ubuntu):New> <https://launchpad.net/bugs/1681099>
[10:43] <Chipaca> pstolowski: another one, looks to be the same thing: #1699768
[10:43] <mup> Bug #1699768: "snap set" causes snapd crash <snapd:Fix Released by stolowski> <snapd (Ubuntu):New> <snapd (Ubuntu Xenial):New> <https://launchpad.net/bugs/1699768>
[10:47] <pedronis> Chipaca: zygmunt is off sick today
[10:48]  * Chipaca assigns all the bugs to him
[10:52] <pstolowski> Chipaca: thanks, i'll double check and mark as dupe if needed
[10:54] <mup> PR snapd#7514 closed: cmd: add `snap debug boot-vars` that dumps the current bootvars <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7514>
[11:19] <mup> PR snapd#7517 opened: run-checks: allow overriding gofmt binary, show gofmt diff <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7517>
[11:20] <mup> PR snapd#7499 closed: many: move AppArmor probing code under sandbox/apparmor <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7499>
[11:36] <mup> PR snapcraft#2731 closed: meta: take no command-chain being prepended into account <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2731>
[12:10] <stgraber> Chipaca: that user is attempting to run a nested container without having set security.nesting to true, so that's not going to work
[12:10] <Chipaca> stgraber: is that something we can detect to point them in the right direction?
[12:11] <stgraber> Chipaca: not particularly easily as for security reasons one normally cannot inspect their own apparmor policy
[12:12] <Chipaca> stgraber: thank you (for the explanation, and the update on the bug)
[12:13] <pstolowski> hmm anyone having issues with github not offering just pushed branch for a PR?
[12:38] <pstolowski> nvm, it suddenly decided to show them.. must have been a temporary hiccup
[12:45] <Chipaca> yeah github was broken for a bit
[12:54] <mup> PR snapd#7518 opened: cmd/snap: sort tasks in snap debug timings output <Created by stolowski> <https://github.com/snapcore/snapd/pull/7518>
[12:59] <mup> PR snapd#7519 opened: tests: use `snap debug boot-vars` in "ubuntu-core-upgrade" test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7519>
[13:00] <Chipaca> huh, getting "this meeting has been updated to use Hangouts Meet" from the standup
[13:00] <pstolowski> Chipaca: same
[13:00] <degville> ^ me too!
[13:00] <Chipaca> and the organizer is probably mvo :-|
[13:00] <mborzecki> duh
[13:01] <ijohnson> it had to happen sooner or later
[13:01] <mvo> Chipaca: meh
[13:01] <mborzecki> am i the only one there?
[13:01] <ijohnson> hangouts actually died
[13:01] <Chipaca> so, let's just use https://meet.google.com/rne-gzqm-kgg?authuser=1&pli=1
[13:01] <mborzecki> hmmm, that's different link than i have
[13:01] <Chipaca> mborzecki: you have a link?
[13:01] <mvo> Chipaca: I updated the inviite
[13:01] <mborzecki> Chipaca: typed in snappy-devel like i always did
[13:02] <Chipaca> cachio: https://meet.google.com/agi-vdpd-myw?authuser=1
[13:05] <mup> PR snapd#7511 closed: tests: when the backend is external skip the loop waiting for snap version <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7511>
[13:06] <mvo> 7515 needs a second review
[13:08] <Chipaca> mborzecki: which is the one that i need to review?
[13:08] <mborzecki> Chipaca: https://github.com/snapcore/snapd/pull/7166
[13:08] <mup> PR #7166: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
[13:33] <mborzecki> much fun when the schedule is crossing the month boundary and the current day is on the other month
[13:34] <Chipaca> mborzecki: let's talk about ISO week numbers
[13:34] <mborzecki> hahah
[13:34] <Chipaca> just not today
[13:35] <mvo> Chipaca: if you want to get something fun to start reviews with, pick 7515
[13:35] <mvo> Chipaca: shouldn't be more than 5min of work
[13:35] <Chipaca> mvo: my bias detector just exploded in a cloud of sparks
[13:35] <Chipaca> mvo: *but* i had that one open already so eh
[13:41] <mborzecki> and gnome-shell spamming the logs every second, wtf
[13:52] <Chipaca> mborzecki: but it has all this information you need to know about!
[13:53] <mborzecki> Chipaca: repeated every second :/
[13:54] <mborzecki> obviously there's no way to have journald drop those messages, now i can enjoy all of my journal history filled with that crap
[13:58] <mup> PR snapd#7515 closed: daemon: return "snapname_rev.snap" style when using /v2/download <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7515>
[14:00] <mup> PR snapd#7348 closed: snapstate,store: check assumes early before downloading the snap <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7348>
[14:06] <asymptotically> hi all, i am trying to install microk8s via snap and it explodes while trying to make some certificates, here is the log: http://paste.debian.net/1102701/
[14:06] <asymptotically> i have tried the stable and edge channels but both fail, and now i'm not sure what else to try
[14:07] <asymptotically> and sorry if this is the wrong place. i couldn't find a channel for microk8s and guessed that this would be the next best place :)
[14:08] <Chipaca> asymptotically: whoa, that's not good
[14:09] <Chipaca> kjackal: is that something you know about? ^^
[14:09] <asymptotically> whoops, forgot to add that i am using snap 2.41 on debian 10
[14:09] <ogra> asymptotically, did you try --stable instaed of --edge ?
[14:10] <ogra> typically the edge channel is for active development
[14:10] <kjackal> reading
[14:10] <asymptotically> yeah, it gets the same error :( - i had a quick search through github issues and google, but it doesn't seem like anything similar has been reported (or my google-fu is weak)
[14:11] <kjackal> asymptotically: can you try --channel=1.15/stable?
[14:12] <kjackal> 187471
[14:12] <kjackal> sorry
[14:13] <asymptotically> thanks kjackal, seems like 1.15 installs and runs fine
[14:13] <kjackal> I hope these library issues will go away when we go to strict confinement
[14:13] <asymptotically> should i just report this as a bug on the microk8s issue page? or would it be a problem with my system
[14:13] <kjackal> asymptotically: can you please open an issue at: https://github.com/ubuntu/microk8s/issues
[14:14] <kjackal> asymptotically: I need to try it out
[14:16] <asymptotically> https://github.com/ubuntu/microk8s/issues/679
[14:17] <kjackal> great thank you
[14:23] <ogra> jdstrand, did you forget about my "/sys/firmware/devicetree/base/soc/ranges" and "/sys/firmware/devicetree/base/system/linux,revision" addition to hardware-observe, or am i just to impatient (just making your it didnt get forgotten)
[14:25] <jdstrand> ogra: not forgotten, just not done yet
[14:25] <jdstrand> (it is in trello with other updates that are accumulating)
[14:26] <ogra> ah, ok ... if there is a trello card i dont need to nag ... sorry then :)
[14:27] <jdstrand> ogra: I added you to it
[14:27] <ogra> thanks !
[14:28] <cwayne> Now ogras gonna write a nagbot that comments on a Trello card every hour :p
[14:28] <ogra> haha
[14:28] <ogra> automation FTW !!!
[14:29] <cwayne> We literally have a nagbot for open MPs
[14:30] <ogra> roadmr, yo ... i tried to register a snap with "core-*" in the name today and got a "this name is reserved" ... after dropping the prefix (and calling my snap just ldap-server which is rather a bit too generic ... ) it worked fine ... do we have a global catchall thigie for anything prefixed with "core" ?
[14:30] <roadmr> ogra: we do ;)
[14:30] <ogra> ouch, k
[14:31] <roadmr> ogra: if you really want core-whatevs we can grant it, you just need to request the name
[14:31]  * ogra makes a mental note for next time
[14:31] <roadmr> (well if you really want it and have a good justification for it :) I want many things but...
[14:31] <ogra> yeah, i was to lazy for buerocracy :P
[14:31] <roadmr> askocracy works better :)
[14:31] <ogra> hahaha
[14:32] <ogra> anyway, its ldap-server for now ... if i get people using it oout of context i'll probably have to rename
[14:32] <cwayne> I prefer ircocracy
[14:32] <ogra> but i expect people to complain then
[14:34] <Chipaca> hmm, i should probably have breakfast
[14:35]  * Chipaca goes
[14:44] <joedborg> hey all, could anyone let me know how to remove interfaces with the network-control plug (if possible)?
[14:44] <joedborg> `ip link delete` doesn't seem to work
[14:47] <pedronis> #7441 needs a second review (it's very small)
[14:47] <mup> PR #7441: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7441>
[14:47] <pstolowski> pedronis: done
[14:48] <pedronis> pstolowski: thank you
[14:48] <mup> PR snapd#7441 closed: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings <Simple 😃> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7441>
[14:50] <pstolowski> fun fact, new spread test in my branch was failing on 14.04 on journalctl match, because without "-a" flag journalctl would cut off one of the critical log lines
[14:52] <pstolowski> pedronis: which of your PRs is next?
[14:52] <pedronis> #7467
[14:53] <mup> PR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7467>
[14:53] <pstolowski> k
[14:54] <mup> PR snapd#7520 opened: tests: moving opensuse to unstable due to catastrofic issue on the repo <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7520>
[14:56] <mup> PR snapd#7517 closed: run-checks: allow overriding gofmt binary, show gofmt diff <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7517>
[15:02] <Chipaca> joedborg: why doesn't it work?
[15:08] <ogra> or better "how" doesnt it work (whats the error ?)
[15:09] <joedborg> Chipaca ogra
[15:09] <joedborg> so the issue is that it doesn't appear to be deleting the interfaces, not thowing any errors
[15:09] <ogra> did you monitor journalctl ?
[15:10] <ogra> i cant imagine it just quietly fails
[15:10] <pedronis> Chipaca: I asked for a review for https://github.com/snapcore/snapd/pull/7467 mostly because with default track/channel normalisation that code will need some care again, it has +2 though so I'm going to land it, you can look at it anyway
[15:10] <mup> PR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7467>
[15:10] <Chipaca> pedronis: ta
[15:12] <mup> PR snapd#7467 closed: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7467>
[15:18] <pedronis> mvo: pstolowski: I rebased the next one #7468 , this one is a bit more substantial given it add support for local snaps
[15:19] <mup> PR #7468: seed/seedwriter: support local snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7468>
[15:19] <pstolowski> ty
[15:19] <mvo> pedronis: looking
[15:26] <Chipaca> pedronis: given snap.MountFile(foo, 5) gives us "/path/to/foo_5.snap", what would be a good name for something that returned just foo_5.snap given those args?
[15:27] <pedronis> Chipaca: we have also a lot of code that does filepath.Base(info.MountFile()) fwiw
[15:27] <Chipaca> it's a silly thing but i'm itching to do this; we've got %s_%s.snap in two different non-test places, and filepath.Base(snap.MountFile(...)) in something like 12
[15:27] <Chipaca> pedronis: quite
[15:27] <pedronis> Chipaca: my worry here is that the surface of these things is already quite big
[15:28] <pedronis> the next person will likely do "%s_%s.snap" again
[15:28] <Chipaca> not for the first time i wish go had some sort of a path interface that would hide this sort of stuff :-)
[15:28] <Chipaca> pedronis: yeah
[15:28] <Chipaca> it's already hard to figure out what you need, there
[15:28] <Chipaca> fair point
[15:31] <pedronis> Chipaca: which is the other place doing %s_%s.snap, I'm not finding it
[15:31] <pedronis> I just see one in info
[15:31] <pedronis> .go
[15:40] <Chipaca> hmm, didn't m vo just add one?
[15:41] <mvo> cyphermox: hey, I'm curious about the status of the netplan.io SRU. when do you think it will hit xenial-updates? mostly wondering because we prepare a new core stable release currently and it would be great if this fix would be part of it (cc ijohnson)
[15:43] <pstolowski> cachio: have you seen ijohnson's question to #7520?
[15:43] <mup> PR #7520: tests: moving opensuse to unstable due to catastrofic issue on the repo <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7520>
[15:44] <cyphermox> mvo: gah, I wish I could tell you better news but tbh it slipped my mind -- the SRU was uploaded to the unapproved queue but never reviewed
[15:45] <cyphermox> mvo: I'll try to get that in -proposed today and then we can see what we can do about this
[15:45] <cyphermox> mvo: ETA for your stable release?
[15:45] <Chipaca> pedronis: looks like i broke something in the latest policy change :-) i'm digging into that
[15:47] <mvo> cyphermox: in a meeting right now will get back to you. rough eta is early next week so probably a bit too early for you
[15:56] <pedronis> Chipaca: as in spread test break but not unit tests?
[15:56] <Chipaca> pedronis: yeap
[15:56] <Chipaca> pedronis: broke google:ubuntu-core-16-64:tests/main/ubuntu-core-upgrade
[15:57] <Chipaca> can't remove core:x3 despite it being not current and not in use
[15:57] <pedronis> ok
[15:57] <pedronis> seems we are missing unit tests then
[15:57] <Chipaca> yeap :-)
[16:03] <ogra> is there any particular reason why on many systems snap version doesn't list the kernel version ?
[16:03] <ogra> it feels like every second/third time i ask someone on the forum to provide snap version i get no kernel line returned
[16:04] <Chipaca> ogra: people remove it because they consider it sensitive information
[16:04] <Chipaca> ogra: or, maybe it's too old?
[16:05] <Chipaca> ogra: but it has been there since forever
[16:05] <ogra> yes, i know
[16:06] <ogra> it just feels like it is missing more often recently
[16:06] <Chipaca> ogra: since 2.23 at least
[16:06] <Chipaca> ogra: but this is 2.21 :-/
[16:06] <ogra> yeah
[16:07] <ogra> since he cant install core he has the deb version
[16:07] <pstolowski> yay, #7355 finally green \o/
[16:07] <mup> PR #7355: interfaces/apparmor: load multiple profiles in a single batch <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7355>
[16:08] <Chipaca> ogra: looks like no squashfs supportfs
[16:08] <Chipaca> ffs
[16:09] <ijohnson> pstolowski: yay do you need a review on that ?
[16:09] <ogra> Chipaca, yep, like all pixelbooks/chromebooks
[16:09] <ogra> seems there are more and more users of these devices though :(
[16:10] <ogra> and the archive all these debian VMs use doesnt have squashfuse either
[16:10] <mvo> cyphermox: meeting over. just read backlog. thanks for the update, would be great to have it in -proposed soon(ish). I will ponder a bit over this, we *might* upload it to our image ppa to get it even if its not in -updates yet but that would be a bit of a last-resort kind of thing
[16:11] <mvo> cyphermox: please keep me updated on this one (and I will poke you again gently early next week :)
[16:11] <pstolowski> ijohnson: yes please, thanks!
[16:11] <ijohnson> ack will do today, probably after your EOD
[16:11]  * Chipaca adds 220V to mvo's stick-of-poking
[16:13]  * ijohnson adds US compatible 120V inverter on top
[16:13]  * mvo hugs Chipaca and his enchanted +5 stick-of-management
[16:14] <Chipaca> mvo: you forgot *glowing*
[16:14] <cachio> pstolowski, answered
[16:14] <cachio> was in a meeting
[16:14] <cachio> thanks for the heads up
[16:15]  * cachio out to get kids from school
[16:15] <cachio> I'll be back in 20
[16:15] <pstolowski> cachio: ty. fwtw i just had green run of spread on one of my PRs
[16:16] <cachio> pstolowski, the error is not happenning in 100% of the runs but is still happening
[16:16] <cachio> perhaps we need to wait today
[16:16] <cachio> does it makes sense?
[16:17] <jdstrand> zyga: hey, afaics, opensuse still has 2.39.1. I can never remember, it doesn't reexec, correct?
[16:17] <ijohnson> jdstrand: zyga is off sick today
[16:17] <jdstrand> zyga: nm. feel better
[16:17] <Chipaca> siiigh
[16:18] <Chipaca> i'm going to go for a run, maybe everything will be better when i get back
[16:18] <jdstrand> does anyone remember if opensuse reexecs?
[16:18] <ijohnson> cachio: yes that makes sense, I'll check in with you before EOD to see if opensuse repos are still not working
[16:18] <ogra> Chipaca, like ... bojo the clown stepped down ?
[16:18] <jdstrand> fedora is still on 2.39.2
[16:18] <jdstrand> I know it doesn't reexec
[16:19] <Chipaca> jdstrand: https://github.com/snapcore/snapd/blob/master/cmd/cmd_linux.go#L69
[16:20] <stgraber> yeah, suse & fedora is what's holding LXD on core16
[16:20] <stgraber> (we need 2.40 for the fix of base handling)
[16:20] <jdstrand> Chipaca: I thought manjaro reexec'd...
[16:20]  * jdstrand shrugs
[16:20] <jdstrand> Chipaca: thanks :)
[16:21]  * jdstrand is curious about when audio-playback will be everywhere
[16:22] <jdstrand> Wimpress, popey: hey, do you have an in with electron? could you poke someone on https://github.com/electron-userland/electron-builder/issues/4234?
[16:23] <jdstrand> kenvandine: would you mind looking at https://github.com/ubuntu/snapcraft-desktop-helpers/pull/197 ?
[16:23] <mup> PR ubuntu/snapcraft-desktop-helpers#197: snapcraft.yaml: add audio-playback for audio <Created by jdstrand> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/197>
[16:25] <jdstrand> Chipaca: btw, thanks for https://forum.snapcraft.io/t/show-interfaces-of-snap-before-installation/13252/3
[16:25] <jdstrand> Chipaca: that is quite handy for the time being
[16:26] <Chipaca> jdstrand: note for really old snaps it won't work (they'll have an empty snap-yaml)
[16:26] <Chipaca> but, yeah
[16:27] <jdstrand> Chipaca: it was a nice advertisement for the 'http' snap as well ;)
[16:27] <jdstrand> Chipaca: cunning
[16:27] <Chipaca> jdstrand: that's probably the only big caveat (the other is to note that it is per revision and the code i posted just grabs the first one)
[16:27] <Chipaca> jdstrand: nah, regular http (via apt install httpie) can do that as well; if I plug the http snap it's using snapd:///... :-p
[16:28] <Chipaca> but yes :-D
[16:30] <roadmr> jdstrand: review-tools  20190924-2239UTC is now in production \o/
[16:33] <ijohnson> pstolowski, any idea why systemd.Stop uses s.systemctl("stop",...) but everything else seems to use s.systemctl("--root",s.rootDir,...) ?
[16:34] <ijohnson> should stop (and also start I guess) use the --root opt as well
[16:35] <pstolowski> ijohnson: let me check the code.. i probably touched this long time ago is that right?
[16:37] <ijohnson> pstolowski: well not sure if you touched this particular bit of code, but I think you had to do the same thing for snapctl stop , etc.
[16:38] <ijohnson> just not sure if there's ever a reason we need to _not_ use --root when we talk to systemctl
[16:38] <ijohnson> seems like we should always use --root
[16:38] <pstolowski> ijohnson: i definately touched services wrt snapctl, yes, was long time ago
[16:38] <om26er> Did I report the bug at the correct place https://bugs.launchpad.net/snapd/+bug/1845533 ? Or should that be reported for the distro package ?
[16:38] <mup> Bug #1845533: snap info gets confused if there is a directory of the same name <snapd:New> <https://launchpad.net/bugs/1845533>
[16:39] <pstolowski> ijohnson: yes i agree it looks suspicious, should probably be consistent, i'm not sure if there is a reason for that
[16:39] <pstolowski> probably an omission
[16:40] <pstolowski> eod for me
[16:40] <pstolowski> o/
[16:40] <ijohnson> ack, thanks pstolowski
[16:45] <om26er> Is snapcraft autobuild trigger broken ? I made a code change to the master of a project that has autobuilds enabled but it didn't trigger even after 15 minutes, I now triggered the build manually.
[16:56] <kenvandine> jdstrand, done
[17:03] <pedronis> Chipaca: I think you fixed this recently https://launchpad.net/bugs/1845533 ?
[17:03] <mup> Bug #1845533: snap info gets confused if there is a directory of the same name <snapd:New> <https://launchpad.net/bugs/1845533>
[17:10] <jdstrand> kenvandine: thanks!
[17:15] <cwayne> kenvandine: yo, your jobs should be fixed and running now
[17:16] <kenvandine> cwayne: thanks
[18:22] <Chipaca> pedronis: yep, fixed in master
[18:29] <Chipaca> pedronis: actually, no
[18:29] <Chipaca> pedronis: the bug that's fixed in master is a different one
[18:29] <Chipaca> pedronis: the one in that report is not a bug at all
[18:31] <Chipaca> "when I do snap info to a directory that isn't a snap, snap info gets confused: it says the directory isn't a snap!"
[18:31] <Chipaca> er...
[18:31] <Chipaca> ...what's the bug again?
[18:32] <Chipaca> om26er: ^^ that's you i'm talking about :-)
[18:33] <om26er> Chipaca you only need to run snap info for a snap that is not installed currently and have a directory of that name created
[18:34] <om26er> cd ~; mkdir slow-snap; snap info slow-snap
[18:34] <Chipaca> om26er: is 'slow-snap' a snap that exists
[18:34] <om26er> slow-snap is a snap that I publish but you will get the complain that `error: no snap found for "slow-snap/"`
[18:35] <om26er> Chipaca, yes it exists and you can repeat that issue with any snap that is currently not installed
[18:35] <Chipaca> holy regressions batman
[18:35] <Chipaca> when did this break
[18:36] <Chipaca> om26er: thank you. I need to figure out what's going on. I'll update the bug with this information.
[18:36] <om26er> great, you are welcome :-)
[18:37] <om26er> Shall I change the bug to confirmed ?
[18:47] <om26er> jdstrand this got rejected in a funny way (after first getting manual approval) https://dashboard.snapcraft.io/snaps/deskconnd/revisions/49/
[18:47] <om26er> context: https://forum.snapcraft.io/t/auto-connection-request-for-deskconnd/13364
[18:55] <Chipaca> hmmmmmmmmm
[18:57] <Chipaca> om26er: could you confirm for me please that if you 'snap refresh core --beta' (or --edge), such that 'snap version' tells you you are on 2.42 pre, then the issue goes away?
[18:58] <Chipaca> i think i might have fixed this without meaning to :-)
[18:58]  * Chipaca will still create a PR with a test for this
[18:58] <om26er> I assume you meant core18 instead
[18:59] <Chipaca> you assume wrong :-)
[18:59] <om26er> hah, ok, core it is then
[18:59] <Chipaca> om26er: unless you have the 'snapd' snap, in which case that is the one to refresh
[18:59] <Chipaca> but you'd have to turn that on with an experimental flag afaik
[18:59] <Chipaca> so probably not
[18:59] <Chipaca> (i think the change to it not being experimental is in .42)
[19:02] <om26er> Chipaca yes, seems to be fixed with core from beta channel
[19:03] <Chipaca> huzzah
[19:07] <Chipaca> om26er: that's going out to candidate and then stable as soon as a couple of integration ducks get in line, hopefully it's not inconveniencing you too much until then
[19:08] <om26er> yeah, its a v.small issue, compared to others that my softwares are facing right now ;-)
[19:09]  * Chipaca hugs om26er 
[19:09]  * om26er hugs Chipaca back
[19:11] <om26er> its been a while since my last IRC hug
[19:16] <om26er> roadmr are you around ? I am kind of blocked as all my snaps got auto-rejected (piconn, deskconn and deskconnd) :-)
[19:16] <roadmr> om26er: omg that's horrible :(
[19:16] <roadmr> om26er: let's have a look
[19:17] <om26er> ```declaration malformed (unknown constraint key 'plug-publisher-id') declaration-snap-v2_valid_plugs (content, allow-auto-connection_plug-publisher-id)```
[19:17] <roadmr> right - it was jdstrand who wrangled those declarations
[19:17] <roadmr> let's see if I can figure out what the issue is
[19:18] <roadmr> remember I said cross-publisher autoconnects were tricky? :)
[19:19] <om26er> roadmr indeed, you said that ;-)
[19:30] <roadmr> om26er: I think we'll need jdstrand to have a look - I can't spot anything wrong :/ he should be around in a bit
[19:31] <om26er> roadmr no problem, thanks for looking into it. I'll be on for a while so I hope I'll catch Jamie then
[19:31] <roadmr> sure; I see you posted on the forum so worst case, he'll see that later
[19:41] <jdstrand> om26er, roadmr: looking
[19:43] <jdstrand> I know the problem
[19:43] <om26er> I guess that's a good thing ?
[19:44] <jdstrand> yes
[19:44] <jdstrand> gimme a sec
[19:46] <jdstrand> om26er: ok r49 is fixed. let me fix the other revisions and snaps
[19:46] <om26er> wohoo! you are a life saver
[19:47] <jdstrand> roadmr: there was a typo in the wiki (https://wiki.canonical.com/AppStore/Reviews?action=diff&rev2=247&rev1=246)
[19:47] <jdstrand> (that's an internal url, sorry)
[19:48] <roadmr> jdstrand: oh! let's see!
[19:48] <roadmr> jdstrand: I checked that but I guess if the typo was on the *reference* document I was never going to spot that :)
[19:48] <roadmr> ah, that makes sense :) thanks
[19:51] <jdstrand> om26er: ok, deskconnd is done. let me adjust the others
[19:53] <jdstrand> om26er: deskconn fixed and r133 approved
[19:54] <jdstrand> om26er: piconn fixed and r4 approved
[19:55] <om26er> jdstrand is it normal that auto-connection no longer works ?
[19:56] <jdstrand> om26er: gpiod fixed (nothing to approve, but next upload will auto-approve)
[19:56] <jdstrand> om26er: the bug in the snap decl would've caused that
[19:56] <jdstrand> om26er: with what I just fixed, it should work
[19:56] <jdstrand> om26er: sorry for the hiccup. these snap declarations can be rather delicate
[19:57] <jdstrand> om26er: please test to verify it is working as expected
[19:58] <om26er> jdstrand my snaps are not auto connecting to crossbar snap now
[19:59] <om26er> to reporduce `snap install crossbar --edge; snap install deskconnd --edge`
[20:02]  * jdstrand is looking
[20:05] <jdstrand> om26er: there is an interplay here since you are wanting two different content slots auto-connected from two different publishers while the snap is providing a content interface itself
[20:05] <jdstrand> gimme a sec
[20:06] <om26er> yeah, here is the outlook
[20:07] <om26er> crossbar: provides runtime environmentdeskconnd: connects to crossbar, provides its own unix domain socket as welldeskconn: connects to crossbar and uses unix domain socket provided by deskconndpicon: connects to crossbar and uses unix domain socket provided by deskconnd
[20:07] <jdstrand> om26er: I'm going to be fiddling with the snap declaration for deskconnd for a minute. if you get emails, don't worry about it
[20:08] <om26er> jdstrand sure, no problem
[20:08] <om26er> sorry for those pastes above, I am a little too used to Slack and didn't realize, IRC doesn't support much formatting
[20:09] <jdstrand> oh
[20:09] <jdstrand> om26er: slots:
[20:09] <jdstrand>   runtime-dir:
[20:09] <jdstrand>     content: executables
[20:09] <mup> Bug #1845555 opened: snap refresh leaves behind old .mount files in /etc/systemd/system/ <Snappy:New> <https://launchpad.net/bugs/1845555>
[20:09] <jdstrand> om26er: 'executables' is what is needed, not 'runtime-dir'
[20:09] <jdstrand> om26er: did you change that? I didn't notice it before
[20:10] <om26er> no, didn't change that, its been like that from the beginning
[20:10] <jdstrand> om26er: ok, adjusting
[20:11] <jdstrand> crossbar:runtime-dir                       deskconnd:crossbar-runtime-dir
[20:11] <jdstrand> let me adjust the others
[20:14] <Chipaca> could somebody on 18.04 check the 'wallstreet' snap (and deb) and confirm whether it works there?
[20:15] <jdstrand> om26er: should be fixed: https://paste.ubuntu.com/p/zPqQ4cvz6P/
[20:15] <jdstrand> om26er: I adjusted piconn and gpiod too, but didn't test as they are armhf
[20:15] <om26er> jdstrand thank you, I tested deskconnd and deskconn they work great now. Will test piconn on the raspberry Pi
[20:16] <jdstrand> om26er: cool, you're welcome and sorry it wasn't a totally smooth experience. the docs are updated for next time
[20:18] <jdstrand> Chipaca: I happened to be ssh'd into a bionic vm, so snap installed wallstreet (eek, --classic!) and it just hangs
[20:18] <Chipaca> jdstrand: does it then OOM?
[20:18] <jdstrand> I don't know what it is supposed to do, but it seems that probably isn't it
[20:19] <Chipaca> jdstrand: https://mobile.twitter.com/DustinKirkland/status/1177311322813403147
[20:19] <jdstrand> jeez, first --classic, now twitter?
[20:19] <jdstrand> :)
[20:19] <Chipaca> not sure why that needs classic TBcmfH
[20:20] <jdstrand> Chipaca: the deb does things that look like the tweet
[20:20]  * jdstrand removes that and tries the snap again
[20:21] <jdstrand> ok, the snap continues to not do anything
[20:22] <jdstrand> it doesn't seem to be leaking memory
[20:22] <Chipaca> thank you
[20:23] <Chipaca> I wonder if that can be strictly confined
[20:23] <Chipaca> I don't see why not
[20:23] <Chipaca> I mean, it ships tmux
[20:23] <jdstrand> it seems to be using screen and/or tmux
[20:23] <Chipaca> but that's not necessarily classic, right?
[20:23] <jdstrand> so, 'no'
[20:23] <jdstrand> it is classic
[20:24] <Chipaca> jdstrand: right, but it has tmux inside of itself
[20:24] <jdstrand> I mean, it must today be classic
[20:24] <Chipaca> jdstrand: and uses them to run things from itself
[20:24] <jdstrand> yes but tmux does stuff that the sandbox disallows
[20:24] <Chipaca> jdstrand: that works, surely?
[20:24] <Chipaca> ahh
[20:24] <Chipaca> ohhh
[20:24] <jdstrand> you cannot run tumx in a snap
[20:24] <Chipaca> booooh tmux boooooh
[20:24] <jdstrand> or screen
[20:24] <om26er> jdstrand tested on the pi, things are fixed. Thank you again :)
[20:24] <jdstrand> there are setuid/setgid bits and other things
[20:24] <jdstrand> om26er: woohoo! :)
[20:26]  * om26er has a small home automation project that has UbuntuCore18 running and controls GPIO pins on the RPi for a few months
[20:28] <jdstrand> om26er: neat :)
[20:28] <jdstrand> Chipaca: super terse notes detailing my recent exploration of a 'tmux-support' interface: https://paste.ubuntu.com/p/Rnf6Pfz85y/
[20:29] <Chipaca> jdstrand: :-(
[20:29] <jdstrand> Chipaca: I time-boxed it and found that there were a number of issues with the terminal in that env that would have to be debugged
[20:32] <jdstrand> Chipaca: I was able to get some stuff going though. if I looked really hard at 'script' and learned some pty/tty fu, maybe...
[20:33] <Chipaca> :)
[20:33]  * jdstrand maintains that screen and/or tmux should be in the core snap (which doesn't help wallstreet one bit)
[20:33] <Chipaca> jdstrand: i thought we'd agreed on that already?
[20:33] <mup> Bug #1845555 changed: snap refresh leaves behind old .mount files in /etc/systemd/system/ <snapd:Invalid> <https://launchpad.net/bugs/1845555>
[20:33] <jdstrand> Chipaca: I thought the 'agreement' was 'no' :P
[20:34] <jdstrand> if it was 'yes', then yay!
[20:34] <Chipaca> it wouldn't be the first time i got those two words mixed up
[20:34] <Chipaca> pedronis will know more
[20:34] <Chipaca> i'll try to bug him about it
[20:34] <jdstrand> cool, thanks :)
[20:35] <jdstrand> oh I left wallstreet running this whole time. still no OOM
[20:35]  * jdstrand kills it and tears down the vm
[20:37] <Chipaca> jdstrand: you commie you
[20:37] <Chipaca> tearing down wallstreet
[20:38]  * roadmr is now known as GordonGekko
[20:39] <Chipaca> roadmr: i expect you to update your profile picture accordingly
[20:39] <jdstrand> hehe
[20:40]  * roadmr visits gravatar.com
[20:41] <roadmr> https://bit.ly/1KwjXmW <- whatcha think about this? not sure about the suspenders
[20:46] <Chipaca> roadmr: https://www.mirror.co.uk/news/uk-news/boris-johnson-vs-gordon-gekko-2860801
[20:46] <roadmr> oh hahaha what
[20:47] <Chipaca> roadmr: also https://wallstreet.fandom.com/wiki/Gordon_Gekko?file=Gordon_Gekko.jpg
[20:48] <Chipaca> anyway, i'm out of here
[20:48] <Chipaca> 👋
[20:48] <roadmr> o/ enjoy
[20:49]  * roadmr scored 9/10 in the quiz \o/
[21:05] <jdstrand> roadmr: thanks for pushing 20190924-2239UTC :)
[21:05] <jdstrand> joedborg: fyi, ^ has the override you need for your snap to pass automated review
[21:06] <joedborg> ah awesome, thanks jdstrand roadmr
[21:06] <joedborg> I'm just removing all the unnecessary layout rules and I'll push again
[21:06] <roadmr> 👍
[21:06] <jdstrand> joedborg: yep, cool :)
[21:33] <mup> PR snapd#7521 opened: [RFC] many: use --root as first arg to systemctl everywhere <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7521>
[21:38] <joedborg> roadmr: jdstrand: managed to clear out alot of the layout https://github.com/charmed-kubernetes/snap-kubernetes-worker/commit/0d9548f866ae5114c64e99f039640553d60d804a
[21:38] <roadmr> \o/
[21:39] <joedborg> the snap is uploading rn
[21:53] <joedborg> roadmr jdstrand rev 2 pushed
[22:14] <jdstrand> joedborg: that's excellent!
[22:15] <jdstrand> joedborg: I see it passed automated review too :)
[22:20] <joedborg> jdstrand: yeah :D
[22:20] <joedborg> Just need Snapcraft io to work now so I can schedule automated builds
[22:28] <mup> PR snapcraft#2732 opened: project: use os.sched_getaffinity instead of multiprocessing.cpu_count <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2732>
[22:52] <mup> PR snapcraft#2733 opened: cmake plugin: support disable-parallel option <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2733>
[23:02] <mup> PR snapd#7522 opened: httputil: set user agent for CONNECT <Created by chipaca> <https://github.com/snapcore/snapd/pull/7522>