[03:27] <mup> PR snapd#8086 opened: daemon: Allow clients to call /v2/logout via Polkit <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/8086>
[06:08] <mborzecki> morning
[06:21] <mborzecki> brb, new kernel
[06:22] <mborzecki> and back
[07:36] <zyga> Hey
[07:36] <zyga> Janek’s fever got me
[07:36] <zyga> Working but sick
[07:40] <mborzecki> zyga: hey, maybe take some time off?
[07:42] <mborzecki> mvo: hey
[07:43] <mvo> hey mborzecki
[07:44] <mborzecki> mvo: came up with this to trigger the failure in linking https://paste.ubuntu.com/p/MHYXNkvJzZ/ that could brick the device
[07:49] <mvo> mborzecki: uh, woah
[07:49] <mvo> mborzecki: this is where the generator will help?
[07:51] <mborzecki> mvo: yes, the generator would ensure that the units are there and snapd.service is enabled
[07:56] <mborzecki> mvo: can you cherry pick https://github.com/snapcore/snapd/pull/8082 to 2.43?
[07:56] <mup> PR #8082: data, packaging: Add sudoers snippet to allow snaps to be run with sudo <Created by Conan-Kudo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8082>
[07:57] <pedronis> do we need a .3 ?
[08:05] <mborzecki> quick errand at school, back in 30 or so
[08:10] <mvo> pedronis: I hope not, did I miss something this morning that may require a .3
[08:10] <mvo> mborzecki: will cherry pick it
[08:11] <pedronis> mvo: I just wondered why mborzecki asked you to cherry pick
[08:11] <pedronis> if there's no .3
[08:16] <mvo> pedronis: I think just in case we do
[08:17] <pedronis> ah
[08:32] <mborzecki> re
[08:32] <mup> PR snapd#8080 closed: dirs: manjaro-arm is like manjaro <Bug> <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8080>
[08:33] <mborzecki> pedronis: mvo: yes, just in case we do a .3
[08:45] <mup> PR snapd#8087 opened: dirs: variable with distros using alternate snap mount <Created by zyga> <https://github.com/snapcore/snapd/pull/8087>
[08:46] <pstolowski> pedronis: +2 on #8084 (but travis is unhappy)
[08:46] <mup> PR #8084: many,randutil: centralize and streamline our random value generation <Created by pedronis> <https://github.com/snapcore/snapd/pull/8084>
[08:46] <mborzecki> btw #7972 needs a 2nd review
[08:46] <mup> PR #7972: overlord/snapstate, wrappers: undo of snapd on core <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7972>
[08:51] <pedronis> pstolowski: yes, timeout on ubuntu tests :/
[08:51] <pedronis> pstolowski: thx for the review
[08:51] <pstolowski> yw
[08:57] <mup> PR snapd#8086 closed: daemon: Allow clients to call /v2/logout via Polkit <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8086>
[09:24] <kbroulik> Hi, I noticed the Telegram Snap reports an incorrect desktop file name in its BAMF_DESKTOP_FILE_HINT. The name it reports is telegram-desktop_telegramdesktop whereas the actual desktop file is telegram-desktop_telegram-desktop - is that a snap bug or an issue on Telegram's side? I recall snap building meddling with desktop file names?
[09:40] <zyga> Lucy has fever too
[09:41] <zyga> kbroulik: it could be split between the two, but I don't recall how we generate that line
[09:41] <zyga> kbroulik: let me check
[09:41] <pstolowski> i've just checked
[09:41] <zyga> pstolowski: thanks!
[09:41] <zyga> mvo: I may need to take today off, I also feel sick today :/
[09:41] <zyga> (Janek, me and now Lucy too)
[09:43] <zyga> mvo: gadget bugs don't have a launchpad presence, or do they?
[09:43] <pstolowski> the exec line is 'Exec=env BAMF_DESKTOP_FILE_HINT=/var/lib/snapd/desktop/applications/telegram-desktop_telegram-desktop.desktop /snap/bin/telegram-desktop -- %u'
[09:43] <mvo> zyga: in a meeting, will get back to you
[09:43] <zyga> ok
[09:43] <pstolowski> and the file under /var/lib/snapd/desktop/applications is telegram-desktop_telegram-desktop.desktop
[09:44] <pstolowski> ^ kbroulik
[09:44] <pstolowski> kbroulik: so looks fine here. where are you seeing that wrong hint? also, what versions of snapd and telegram snap do you have?
[09:48] <zyga> mvo: all good, no need
[09:53] <kbroulik> pstolowski: oh, possibly the desktop file I have in my autostart is outdated then
[09:53] <kbroulik> yup. my autostart desktop file is outdated/wrong
[09:53] <kbroulik> that explains why I was randomly seeing this phenomenon, typically in the morning ;)
[09:54] <kbroulik> when i start telegram manually it is correct. Oh well, sorry for the noise then
[09:55] <mborzecki> kbroulik: it should be enough to have a symlink to /var/lib/snapd/desktop/telegram-desktop_telegra-desktop.desktop
[09:55] <kbroulik> yeah, I was wondering that. However, the file also had a different name, so that wouldnt have helped
[09:55] <kbroulik> it probably was telegram-desktop_telegramdesktop a few months ago
[09:56] <mborzecki> right, there might have been some fixes for the autogenerated destop file naming
[09:56] <pstolowski> kbroulik: great
[09:58] <kbroulik> I'll see what we can do on the KDE side of things, maybe use a symlink and then show a "could not autostart all programs [configure autostart]" so we fail gracefully rather than silently starting an ever-so-slightly broken version
[10:03] <mup> PR snapd#8088 opened: tests/lib/prepare-restore: Revert "Continue on errors updating or installing dependencies" <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8088>
[10:03] <mborzecki> our project prepare is flaky ^^ looks like this was masking some errors
[10:12] <zyga> mborzecki: can you git blame and see what's the reason for the original code?
[10:12] <zyga> ah
[10:12] <zyga> I see
[10:12] <mborzecki> zyga: that's from before we had *-unstable systems
[10:17] <zyga> we should land or close https://github.com/snapcore/snapd/pull/8047
[10:18] <mup> PR #8047: tests: detect LXD launching i386 containers <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8047>
[10:30] <mborzecki> zyga: do you recall why we have mock in spread suite package dependencies on fedora?
[10:31] <zyga> perhaps we used to build with mock?
[10:31] <zyga> but otherwise no, it should not be there
[10:37] <mborzecki> can i get some reviews of #8081?
[10:37] <mup> PR #8081: tests/main/user-session-env: add test verifying environment variables inside the user session <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8081>
[10:37] <mborzecki> zyga: ^^ maybe?
[10:38] <zyga> yeah
[10:38] <mborzecki> it's super simple
[10:44] <zyga> mborzecki: does su -l or sudo -l setup a session?
[10:45] <zyga> mborzecki: approved
[10:46] <zyga> mvo: I'm off, going upstairs to the other sick folks
[10:46] <pedronis> mvo: I reviewed #8063 and made a slightly annoying comment, sorry
[10:46] <zyga> I'll be back later to check upon things, if I feel better
[10:46] <mborzecki> zyga: no, it's weird but they do not, in this sense, afaiu the genrators, /lib/environment.d handling is only done when there's systemd --user involved, something that does not happen with su/sudo
[10:46] <zyga> I'll skip standup
[10:46] <mup> PR #8063: cmd/snap: implement 'snap remove-user' <Created by chipaca> <https://github.com/snapcore/snapd/pull/8063>
[10:47] <mvo> pedronis: thank you, it's fine
[10:47] <mvo> zyga: get well!
[10:47] <mup> PR snapd#8089 opened: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089>
[10:52] <ijohnson> Morning folks
[11:03] <mborzecki> ijohnson: hey, you're up early ;)
[11:04] <ijohnson> mborzecki: indeed!
[11:09] <pstolowski> hi ijohnson!
[11:09] <ijohnson> o/ pstolowski
=== mup_ is now known as mup
=== pfsmorigo is now known as Guest84982
[11:30] <Chipaca> zyga: WRT #core18/89, I talked with xnox at the sprint and was told it would be fixed Soon™
[11:30] <Chipaca> core18#89
[11:31] <mup> Issue core18#89: bash completion not installed if "core" snap is not installed <Created by albertodonato> <https://github.com/snapcore/core18/issue/89>
[11:31] <xnox> Chipaca:  but did I do it? Not yet!
[11:32] <Chipaca> xnox: so you're saying it should be Soon℠, not Soon™?
[11:33] <xnox> hahhaha
[11:45] <pedronis> mvo: this is a possible smoking gun on the running too long suites:  https://pastebin.ubuntu.com/p/m7cJKkjGjp/
[11:45] <pedronis> I got a timeout again
[11:45] <mvo> pedronis: is this just 20.04? or all over the place?
[11:45] <ijohnson> pedronis: I've seen that before a week or two ago, but wasn't able to find the cause of that
[11:46] <pedronis> mvo: only 20.04 afaict in my run
[11:46] <ijohnson> mvo: pedronis: I saw it on 19.10 too https://pastebin.ubuntu.com/p/4Kqpj2CnPb/
[11:47] <pedronis> mvo: the full log is here: https://api.travis-ci.org/v3/job/645874351/log.txt
[11:47] <pedronis> anyway it would be good if we made it fail at least
[11:47] <pedronis> vs hanging
[11:47] <pedronis> and timeout the whole suite
[11:47] <ijohnson> hmm actually my failure had a different pulseaudio error
[11:48] <pedronis> in this one btw afaict the test never finishes
[11:50]  * mvo scratches head
[11:50] <pstolowski> pedronis: hey, looking at you comment re #7705: "we should think how to avoid these changes, probably by having a *firstBootBaseTest .."; do you mean having makeSeedChange) in a new firstBootBaseTest?
[11:50] <mup> PR #7705: o/devicestate: handle preseed in firstboot <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7705>
[11:52] <pedronis> pstolowski: no, I mean structuring nesting the suite setup a bit differently
[11:54] <pedronis> pstolowski: let me try to see if I can sketch something to be clearer
[11:55] <pstolowski> pedronis: thanks
[11:57] <mborzecki> hm why would it ping bluez in a vm on gcp?
[11:58] <mborzecki> pedronis: any chance this test was running after one that installs bluez?
[12:03] <pedronis> pstolowski: this https://github.com/snapcore/snapd/pull/7705/files#r374630332 if it makes any sense
[12:03] <mup> PR #7705: o/devicestate: handle preseed in firstboot <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7705>
[12:06] <pstolowski> pedronis: thanks, will play with it
[12:11] <ijohnson> pedronis: 8077 is ready again, note that it's gotten rather large again, if you'd prefer I can close this and we can land the smaller bits from the PR individually now?
[12:11] <mborzecki> 8075 and 8076 would be a good start
[12:11] <pedronis> ijohnson: thx, I'll look and decide, trying to finish something else ATM
[12:12] <ijohnson> pedronis: no rush, thanks
[12:20] <mup> PR snapd#7965 closed: DRAFT - tests: enabling main and regression test suites for core20 <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7965>
[12:37] <mborzecki> ijohnson: some comments in 8076
[12:37] <ijohnson> mborzecki: thanks looking now
[12:38] <mborzecki> ijohnson: the part that mounts the kernel tries to use the current kernel as fallback, we should probably do the same for base, and use one that's listed in base= in modeenv (does that make sense?)
[12:38] <ijohnson> yes that makes sense, I will implement that now
[12:48] <ijohnson> afk for a little bit
[12:51] <pedronis> ijohnson: it's a bit hard to judge because of the prereq but it might make sense to try to split out the initramfs bits
[12:51] <ijohnson> pedronis: the initramfs is already split out - that's 8076
[12:52] <pedronis> ah
[12:52] <pedronis> we really need to solve the test snap-bootstrap issue
[12:59] <mborzecki> pedronis: can we ask nicely for relevant packages and snaps to be rebuilt? :)
[12:59] <mborzecki> ijohnson probably did that already
[12:59] <pedronis> not really, this is about the kernel
[12:59] <pedronis> it cannot be rebuilt that often
[12:59] <pedronis> we really need to inject in our tests
[13:03] <mborzecki> pedronis: ah, i see what you mean, we coudl try repacking it in prepare, i can look into that
[13:04] <pedronis> mborzecki: I think ijohnson has a PR, but is building things and is too slow (5m)
[13:04] <pedronis> mborzecki: you should sync with mvo on this
[13:04] <mborzecki> ack
[13:07] <ijohnson> mborzecki yes the PR is open but it is slow and I had an issue where sometimes it fails to reboot for reasons I don't understand, same thing works locally outside of spread
[13:07] <mborzecki> ijohnson: ok, let me look at it
[13:08] <pstolowski> cachio: hey, i've replied to one of your comments under  my new nested vm nests; let me know if you need more info about how preseeding works
[13:09] <cachio> pstolowski, nice, I'll take a look
=== ricab is now known as ricab|lunch
[13:45] <cachio> pstolowski, hey, images created
[13:45] <cachio> I added the info to the PR
[13:45] <pstolowski> cachio: oh wow, that was fast, thank you!
[13:46] <cachio> I can test them on my afternoon if you need help on that
[13:46] <cachio> after I finish snapd validation
[13:51] <cachio> pstolowski, if you want I can update the spread.yaml with the new info
[13:52] <pstolowski> cachio: that would be great, ty
[14:40] <pstolowski> cachio: are you going to push any spread.yaml changes to my PR, or a separate one?
[14:41] <cachio> pstolowski, in yours, give me 1 minutes
[14:41] <pstolowski> cachio: awesome, np
[14:44] <jdstrand_> pedronis: hey, what kind of coordination needs to happen with the store re plug-names/slot-names (ignoring the review-tools for a moment)? eg, if I issued a snap decl with plugs-names, today, what would happen?
=== jdstrand_ is now known as jdstrand
[14:45] <pedronis> jdstrand: the version they use of the assertion library need to be updated
[14:45] <jdstrand> pedronis: ok, so it will give version 4. and what happens if the store gives version 4 and snapd still only supports version 3?
[14:46] <pedronis> jdstrand: it gets the old format answer
[14:46] <pedronis> it gets the assertion with the highest revision with the old format
[14:46] <cachio> pstolowski, cant push to your branch
[14:46] <jdstrand> pedronis: so the store knows to strip out the version 4-only bits?
[14:46] <cachio> pstolowski, do you want the diff?
[14:46] <pedronis> jdstrand: so it uses the old value
[14:46] <pedronis> it uses the old assertion
[14:47] <pedronis> it doesn't strip things
[14:47] <jdstrand> pedronis: ah. ok
[14:47] <pedronis> jdstrand: it filters on format the known revisions
[14:48] <jdstrand> pedronis: so, in order to start issuing plug-names, we need to make sure that snapd 2.44 has gone to stable (for reexec) and all distros without reexec have 2.44
[14:48] <pstolowski> cachio: sure you can give me the diff; perhaps you added my git remote with https:// instead of ssh?
[14:48] <jdstrand> pedronis: (and the assertion library needs updating of course)
[14:48] <pedronis> jdstrand: yes, we do need 2.44 to be widely released
[14:49] <jdstrand> pedronis: has the assertion library been updated?
[14:49] <pedronis> not yet
[14:49] <pedronis> they were going through a previous update yesterday
[14:49] <pedronis> I will ask them to, so it's done before 2.44
[14:50] <jdstrand> pedronis: and in terms of cross distro, it seems that sometimes we don't update everywhere. are you planning to for 2.44?
[14:50] <jdstrand> (for distros without reexec)
[14:52] <pedronis> jdstrand: we should try, do you have something particular in mind?
[14:52] <pedronis> I mean some particular distro?
[14:53] <jdstrand> pedronis: I'm just trying to document when we can cut over to plug-names for personal-files/system-files and trying to get a feel for the timing
[14:58] <pedronis> jdstrand: ok, we'll need probably a slightly slow approach to that
[14:58] <jdstrand> pedronis: I was also wondering if you had plans or thought about updating the base decl policy for this. eg, snapd-control with plug-names: $INTERFACE
[14:58] <pedronis> jdstrand: yes, but we need to go check how many snaps wouldn't need changes
[14:58] <cachio> pstolowski, https://paste.ubuntu.com/p/tW7K2pcQ4B/
[14:58] <jdstrand> pedronis: yes, that is what I've gathered
[14:59] <pstolowski> cachio: ty
[14:59] <pedronis> jdstrand: also to be honest changing the base decl is not that useful
[14:59] <cachio> sorry, my network failed
[14:59] <pedronis> it mostly says you cannot have those interfaces
[15:00] <jdstrand> pedronis: oh, yeah. I didn't ask about personal-files because it has an installation contraint, but then, so does snapd-control :)
[15:00] <pedronis> all the superpriviledge ones says no
[15:00] <pedronis> so it would be a matter to change the snap-declaration
[15:00] <jdstrand> pedronis: yes
[15:00] <pedronis> but we need to check the snaps
[15:00] <jdstrand> yes
[15:00] <pedronis> also change the UI
[15:00] <pedronis> backend
=== ricab|lunch is now known as ricab
[15:01] <pedronis> to produce different patterns
[15:01] <pedronis> that needs store work
[15:01] <jdstrand> it becomes a process thing
[15:01] <jdstrand> yes
[15:01] <jdstrand> ok, thanks
[15:24] <mborzecki> mvo: ijohnson: this is what i've got so far
[15:24] <mborzecki> https://paste.ubuntu.com/p/FgcGBHdZkB/
[15:25] <ijohnson> mborzecki: you can also filter dirs to use when extracting with unsquashfs so you could just do all of them except firmware IIUC
[15:25] <mborzecki> right, that's the next step :)
[15:26] <ijohnson> mborzecki: but that all looks good to me, excited to see it work :-)
[15:30] <mvo> mborzecki: woah, that is pretty far, nice job
[16:07] <pedronis> ijohnson: thank you, I did a pass on 8077, couple minor things in basestate20.go, we need with mborzecki to unblock the prereqs before getting this one in, also as I mentioned in the standup it probably needs 2 other reviewers as well
[16:07]  * cachio lunch
[16:07] <ijohnson> pedronis: ack makes sense
[16:11] <pedronis> pstolowski: are you blocked on me reviewing something ATM?
[16:14] <mborzecki> hmm same method of unpacking, but on focal unmkinitramfs works fine but on bionic it says premature end of archive and does not extract the rest of initrd
[16:19] <pedronis> can't we now make the core 20 based on a focal image ?
[16:19] <pedronis> sorry, I mean the core 20 tests
[16:19] <pedronis> it starts with a bionic one
[16:19] <pedronis> but not sure is needed anymore?
[16:20] <pstolowski> pedronis: not for today. i've addressed your latest comment to #7705, will need your re-review, and after that a review of #8046 (which i'm currently updating based on feedback from Sergio). but tomorrow i may look at doing something new & wait for reviews. i may start adressing known TODOs for firstboot, but i'm not sure about stacking more stuff on top of the two existing PRs
[16:20] <mup> PR #7705: o/devicestate: handle preseed in firstboot <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7705>
[16:20] <mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
[16:20] <pedronis> pstolowski: ok, want to eod a bit earlier than yesterday
[16:21] <pstolowski> sure
[16:23] <ijohnson> pedronis: we can't make it based on focal unless cachio creates a uefi image based on focal, not sure how doable that is or not
[16:24] <ijohnson> mborzecki: that's not surprising, perhaps we could make a simple snap based on core20 with the things we need from focal and install it during the build to prep the image ?
[16:25] <ijohnson> mborzecki: I did manage to successfully build a snap based on core20 so I could do that if that is necessary/useful
[16:26] <pstolowski> cachio: the new nested vm tests wotk with 19.10 and 20.04 images \o/
[16:26] <ijohnson> pstolowski: do you have a second to chat about the disconnect --forget PR? I'm trying to test it locally but whenever I use the --forget option I get "error: invalid empty plug name"
[16:28] <jdstrand> pedronis: one last question (I'm documenting this for reviewers): suppose the assertion library is updated in the store to support v4. now suppose a reviewer issues a snap decl that only uses v3 and lower items. does the store save that as v3 or v4?
[16:31] <mborzecki> ijohnson: mvo: need to step out with the kids soonish, i've pushed what i have to ian's branch in #8069
[16:31] <mup> PR #8069: tests: build the initramfs + kernel snap for UC20 spread tests <Precious Logs> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8069>
[16:31] <ijohnson> mborzecki: I'll take a look in my PM
[16:31] <mvo> mborzecki: thank you
[16:31] <ijohnson> thanks mborzecki !
[16:32] <pstolowski> ijohnson: sure
[16:32] <ijohnson> pstolowski: so it seems that whenever the plug is missing and I use the --forget flag the only error message I get is `error: invalid empty plug name`, even though the plug name is there
[16:32] <jdstrand> pedronis: put another way, does the store save to the lowest format that supports the snap decl or to the highest version the assertion library supports?
[16:33] <pedronis> jdstrand: the former, v3
[16:33] <ijohnson> https://www.irccloud.com/pastebin/6WZ4nec3/
[16:33] <ijohnson> pstolowski: ^
[16:33] <jdstrand> pedronis: ok, cool. thanks!
[16:34] <ijohnson> that seems wrong but I can't tell where in the code the issue is from?
[16:34] <pstolowski> ijohnson: hmm interesting. maybe i missed something, need to check
[16:35] <pedronis> jdstrand: asserts has feature detection to pick the lowest format
[16:39] <ijohnson> pstolowski: ok, it's possible I'm doing something wrong to test too, but it seems that error message always shows up for me, no matter the plug name if I use --forget
=== ijohnson is now known as ijohnson|lunchd
=== ijohnson|lunchd is now known as ijohnson|lunch
[16:40] <pstolowski> ijohnson|lunch: it's possible you are onto something.. cmd disconnect (client side) does something with arg swapping. i'm investigating
[16:41] <pstolowski> will update my spread test
[16:42] <jdstrand> pedronis: yeah, cool. that is smart. it allows us the ability to issue an updated v3 and a new v4 declaration (for example) in the store. For reviewers, that is error prone and not particularly transparent (so not recommended in normal work flows), but having the ability just in case is nice
[16:44] <jdstrand> pedronis: I was doing a thought experiment on 'what if we started using plug-names ahead of good snapd field penetration' and then had questions on how the store does things (fyi, landed on 'just wait' in case you were wondering)
[16:44] <pedronis> jdstrand: to really to that nicely we would like to put them in the assertion store atomically together
[16:44] <pedronis> s/to that/do that/
[16:45] <ackk> hi, I have a prime dir which I previously had "snap try"'d. the snap (maas) requires maas-cli via content interface. after removing both snaps, I can't seem to be able to remove the maas-cli/lib inside the prime dir, not even as root
[16:45] <ackk> how can I debug what's preventing it?
[16:45] <ackk> (I get permission denied)
[16:46] <jdstrand> pedronis: yeah. with different forms or something, I guess. the store can't really guess the intent of the decl though, so I also think it is smart we aren't auto-filtering down
[16:46] <pedronis> jdstrand: yes, auto-filtering could have strange security implications that are hard to predict
[16:47]  * pedronis mostly eods
[16:48] <jdstrand> pedronis: oh, sorry to keep you! enjoy your eod :)
[16:52] <ijohnson|lunch> pstolowski: cool glad I helped you find a bug :-)
[16:53] <pstolowski> ijohnson|lunch: just confirmed with a spread test, thanks for catching! something is off with shortened syntax
[16:53] <cachio> pstolowski, nice, great news
[16:54] <cachio> ijohnson|lunch, I can update the ubuntu  19.10  created for nested execution and enable uefi in case it is needed
[16:55] <cachio> ijohnson|lunch, just confirm if you need that and I'll make the change
[16:55] <ijohnson|lunch> cachio I don't know yet, I'll look after my lunch to see if it's needed and let you know but to confirm you can't do 20.04 yet correct?
[16:56] <cachio> ijohnson|lunch, good, just ping me in case you need it
[17:24] <pstolowski> ijohnson|lunch: ok, I think I see the problem. the existing ResolveDisconnect code in repo is very tolerant (specifically, the connected() method). with just 1 argument (the plug side) the client swaps args around (so it becomes a slot and empty plug). this is later "corrected" by the flexibility of ResolveDisconnect/connected, which tries to match by treating the arg as plug-or-slot. it gets very confusing along the way
[17:24] <pstolowski>  because for most of the time we use plugName, slotName as variables, while sometimes they become plug-or-slot really. i haven't reflected this fuzzyness in my variant of ResolveDisconnect with forget
[17:24] <pstolowski> i will look at fixing it tomorrow, eod for now
=== ijohnson|lunch is now known as ijohnson
=== Guest84982 is now known as pfsmorigo
[17:46] <mup> PR snapd#8088 closed: tests/lib/prepare-restore: Revert "Continue on errors updating or installing dependencies" <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8088>
[18:26] <mup> PR snapcraft#2909 opened: elf: search for host libraries within search paths <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2909>
[18:34] <mup> PR snapd#8084 closed: many,randutil: centralize and streamline our random value generation <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8084>
[18:45] <mup> PR snapd#8090 opened: randutil,o/snapstate,-mkauthors.sh: follow ups to randutil introduction <Created by pedronis> <https://github.com/snapcore/snapd/pull/8090>
[19:08] <mup> PR snapd#8087 closed: dirs: variable with distros using alternate snap mount <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8087>
=== sergiusens_ is now known as sergiusens