[01:07] <mup> PR snapd#8837 opened: Add an activates-on property to apps to support D-Bus activation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8837>
[03:33] <mup> PR snapd#8838 opened: tests: fix the basic20 test for uc20 on external backend <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8838>
[05:21] <mborzecki> morning
[06:09] <mup> PR snapd#8833 closed: sandbox/cgroup: remove redundant pathOfProcPidCgroup <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8833>
[06:09] <mup> PR snapd#8836 closed: sandbox/cgroup: add tests for ParsePids <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8836>
[06:09] <mup> PR snapd#8838 closed: tests: fix the basic20 test for uc20 on external backend <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8838>
[06:18] <mborzecki> mvo: hey
[06:19] <mup> PR snapd#8828 closed: tests: clean up up the use of configcoreSuite in the configcore tests <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8828>
[06:19] <mvo> good morning mborzecki
[06:19] <mborzecki> mvo: can you cherry pick https://github.com/snapcore/snapd/pull/8827 to 2.45?
[06:19] <mup> PR #8827:  interfaces/builtin/time-control: allow POSIX clock API <Needs security review> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8827>
[06:22] <mvo> mborzecki: sure thing
[06:22] <mborzecki> mvo: and we can probably land https://github.com/snapcore/snapd/pull/8822 the tests failed with `error: cannot get snap sections: cannot sections: got unexpected HTTP status code 403 via GET to "https://api.snapcraft.io/api/v1/snaps/sections"`
[06:22] <mup> PR #8822: release: 2.45.1 <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8822>
[06:24] <mvo> mborzecki: cherry-picked, thank you
[06:24] <mborzecki> mvo: thanks!
[06:26] <mvo> zyga: re the "too early for operation" error, I seem to only see this in the uc20 prepare, did you see tihs on other suites as well?
[06:28] <zyga> Yes, i saw it in Ubuntu 20.04 as well
[06:28] <zyga> Good morning
[06:29] <mup> PR snapd#8822 closed: release: 2.45.1 <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8822>
[06:29] <mborzecki> zyga: hey
[06:30] <zyga> Hey, sorry to be up so late. A bit sleepy still. I could not sleep well
[06:32] <mborzecki> heh, funny, spread discards the node that failed suite level prepare?
[06:35] <zyga> it's day two but my little daughter is still very reluctant to approach me
[06:36] <zyga> I guess I need to find a xmas beard and glue it first :)
[06:40] <mborzecki> oh, and it's not possible to restart old gh action jobs
[06:40] <mborzecki> there's no restart workflow button for the cla check job in https://github.com/snapcore/snapd/pull/8620
[06:40] <mvo> zyga: anything other than 20.04? core20 is also 20.04 based, I wonder if it's only a 20.04 issue for some strnage reason
[06:40] <mup> PR #8620: spdx: add GPL-3.0-or-later license <⛔ Blocked> <Created by prabhu> <https://github.com/snapcore/snapd/pull/8620>
[06:40] <mborzecki> (it las ran more than a month ago tho)
[06:44] <zyga> mvo: no, nothing apart from 20.04 or core20
[06:44] <zyga> mvo: it is weird, because we *wait* for seeding
[06:44] <zyga> so what could it be?
[06:44] <zyga> perhaps seeding "succeeds" with an error
[06:44] <zyga> and then we carry on and hit this
[06:44] <zyga> could we fail seeding due to incorrect time somehow? (but I strongly doubt this)
[06:45] <zyga> mvo: since it always fails on that line
[06:45] <zyga> mvo: perhaps we should add a patch that shows snap changes and other stuff
[06:45] <zyga> mvo: I will send a patch for that shortly
[06:47] <zyga> jamesh: thanks for splitting out https://github.com/snapcore/snapd/pull/8837
[06:47] <mup> PR #8837: snap: add an activates-on property to apps for D-Bus activation <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8837>
[06:48] <jamesh> zyga: no problem.  I think there's more that can be split out on top of that.
[06:48] <mborzecki> zyga: mvo: what if there's a problem talking to the store, does this require poking the store to get some serial number?
[06:48] <zyga> yes, I think this is a good approach to landing large branches, as there's realistically much more review for small branches than there is for large ones
[06:49] <zyga> mborzecki: I don't know what would happen, my expectation is that when wait seed returns you are good to go
[06:49] <zyga> mborzecki: and we don't block installing snaps when you are not registered
[06:49] <jamesh> detecting existing ActivatesOn conflicts with existing snaps could probably be done on top of this PR
[06:50] <zyga> jamesh: small comment https://github.com/snapcore/snapd/pull/8837/files#r437174750
[06:50] <mup> PR #8837: snap: add an activates-on property to apps for D-Bus activation <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8837>
[06:57] <mvo> zyga: I like the idea of showing snap changes and snap tasks --last=seeding
[06:57] <mvo> zyga: I'm looking at the code right now, trying to understand this
[06:58] <mvo> zyga: I will try to write a small reproducer
[06:58] <zyga> mvo: do you want me to send patches or will you?
[06:59] <mvo> zyga: if you have it ready please do, otherwise I can do it. but I try to write a reproducer first I think
[06:59] <zyga> not ready yet, I'll defer to you then
[06:59] <mvo> zyga: ta
[06:59]  * zyga tries to drink coffee then
[07:01] <pedronis> mvo: hi, the strange failures logs in #8832 doesn't seem to tell much,  it doesn't seem to trigger debug logs?  we need to add more logging, I started at the code some more yesterday and still unsure what is happening, it seems 20.04 only
[07:01] <mup> PR #8832: travis.yml: removed, all our checks run in GH actions now <Precious Logs> <Simple 😃> <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8832>
[07:01] <pedronis> s/started/stared/
[07:02] <pedronis> mvo: also afaict this started appearing only last week? I wonder what changed
[07:02] <mvo> pedronis: yeah, it's pretty new
[07:03] <pstolowski> morning
[07:05] <zyga> good morning pedronis, pstolowski
[07:05] <zyga> pedronis: I think it started more than a week ago
[07:05] <zyga> pedronis: at least ~ 2 weeks to be safe
[07:05] <zyga> maybe it increased in frequency, maybe just bad luck
[07:05] <mvo> or !luck :P
[07:06] <zyga> I think we all agree we need more data
[07:08] <zyga> back in 15 min
[07:18] <mvo> hrm, hrm, I wrote a script that does what prepare.sh is doing in a loop and of course it is not failing. depressing
[07:20] <zyga> mvo: are you testing locally?
[07:23] <mvo> zyga: in qemu
[07:24] <mvo> zyga: but yeah, "locally"
[07:24] <mvo> zyga: from my desktop machine
[07:24] <mup> PR snapd#8839 opened: tests: add debug for 20.04 prepare failure <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8839>
[07:25] <mvo> zyga: do you happen to have an example failure on a 20.04 sytem (not core20)? if not, no problem, I will go over the existing failure
[07:25] <zyga> let me look quickly...
[07:26] <mvo> pedronis: are you happy with 8808 in principle (i.e. making the settle timeout a function etc)? if so I can help dimitri to land it (unless it requires design changes)
[07:28] <pedronis> mvo: let me make a precise suggestion
[07:28] <mvo> pedronis: \o/
[07:28] <mvo> pedronis: thank you
[07:30] <pedronis> mvo: https://github.com/snapcore/snapd/pull/8808#issuecomment-641090791
[07:30] <mup> PR #8808: riscv64: bump timeouts <Created by xnox> <https://github.com/snapcore/snapd/pull/8808>
[07:30] <mvo> ta
[07:32] <pedronis> mvo: and https://github.com/snapcore/snapd/pull/8808#issuecomment-641092197
[07:32] <mup> PR #8808: riscv64: bump timeouts <Created by xnox> <https://github.com/snapcore/snapd/pull/8808>
[07:34] <pedronis> mborzecki: hi, +1 to #8830 with some final suggestions
[07:34] <mup> PR #8830: bootloader: introduce bootloarder assets, import grub.cfg with an edition marker <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8830>
[07:34] <mborzecki> pedronis: thanks
[07:34] <mup> PR snapd#8832 closed: travis.yml: removed, all our checks run in GH actions now <Precious Logs> <Simple 😃> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8832>
[08:31] <mborzecki> quick errand, back in 30
[08:39] <mup> PR snapd#8840 opened: tests: move try-related tests to snapstate_try_test.go <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8840>
[08:49] <mup> PR snapd#8839 closed: tests: add debug for 20.04 prepare failure <Test Robustness> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8839>
[09:13] <mborzecki> re
[09:33] <pstolowski> pedronis: i'm working on addressing comments to #8812; moving all this to servicestate means no backend abstraction layer for services and calling wrappers directly, makes sense?
[09:33] <mup> PR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>
[09:35] <pedronis> pstolowski: yes correct, then in the tests in snapstate if needed you do the same thing we do for ifacestate stuff
[09:35] <pedronis> or at least something similar as needed
[09:35] <pedronis> but not sure this will be used immediately in snapstate?
[09:36] <pstolowski> pedronis: i think the tests i've in this PR need to be moved entirely to servicestate
[09:37] <pedronis> yea, I think my comment is relevant only for when we'll move start/stop-snap-services but that's not an immediate issue
[09:37] <pstolowski> pedronis: and changed, because i cannot use fakebackend anymore
[09:38] <pedronis> pstolowski: I really don't have a strong opinion, you an use whatever work best for the tests
[09:40] <pstolowski> pedronis: ok, thanks
[10:09]  * pstolowski lunch
[10:13] <ackk> hi, any idea why snap is reporting error: cannot install "q": invalid instance name: invalid snap name: "q" if I "snap install q" ?
[10:13] <ogra> does anyon know if /dev/shm/snap.$SNAP_NAME/foo can be the endpoint of a content interface (for sharing a crypto function between two snaps)
[10:14] <ackk> (also "snap info q" doesn't find anything)
[10:17] <pedronis> ackk: we don't support single letter snap names
[10:17] <ackk> pedronis, yet the store has them?
[10:17] <ackk> pedronis, (and command-not-found tells you to "snap install q")
[10:17] <ackk> https://snapcraft.io/q
[10:17] <pedronis> you'll need to talk to the store afaik they shouldn't be supported in the store either
[10:18] <pedronis> snapd will never install them
[10:18] <ackk> pedronis, I see, thanks
[10:32] <zyga> ogra: can you explain in more detail please
[10:35] <ogra> zyga, a customer has a snap with a crypto tool that creates /dev/shm/atpkcs11 and puts a mutex inside ... they want to be able to use this from a second snap
[10:36] <zyga> I see
[10:36] <zyga> let me think
[10:36] <ogra> (with snapcraft-prleoad they can indeed re-locate to /dev/shm/snap.$SNAP_NAME ... but i dont know if sharing that location would work)
[10:40] <mup> PR snapd#8840 closed: tests: move try-related tests to snapstate_try_test.go <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8840>
[10:42]  * zyga break to rest
[10:45] <mup> PR snapd#8841 opened: gadget: drop dead code, hide exports that are not used externally <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8841>
[10:45] <mborzecki> pedronis: ^^
[10:45] <mborzecki> was able to hide/remove a bit more
[10:46] <mborzecki> heh 17 files changed, 147 insertions(+), 1414 deletions(-)
[10:48] <mborzecki> heh, hit that too early for operation thing again
[10:56] <zyga> mborzecki: oh
[10:56] <zyga> do you have more logs?
[10:56] <zyga> mvo added debug bits
[10:57] <mborzecki> nope
[10:57] <zyga> you had older masteR?
[10:59] <mborzecki> yeah
[11:00] <mborzecki> but i have another new PR running, let me check whetherh it has the right changes
[11:00] <mborzecki> ehh nope
[11:10] <mvo> xnox: I pushed a small tweak to 8808, should be ok to re-review
[11:17] <mvo> pedronis: hm, I'm testing the uc20 beta right now and there are a bunch of updates since. I get a reboot in the middle of console-conf. I guess we need to think about the user experience for this :/
[11:18] <pedronis> mvo: yes, but it would be the same with uc18 I suppose
[11:18] <mvo> pedronis: yeah, new kernel and snapd while I was in console-conf tryint go set this up
[11:18] <mvo> pedronis: yeah, not a regression
[11:18] <mvo> pedronis: mostly idle wondering
[11:18] <pedronis> mvo: it's ok, it probably relates to trying to control our reboots more
[11:19] <ijohnson> morning folks
[11:19] <ijohnson> mvo: pedronis: also I filed https://bugs.launchpad.net/subiquity/+bug/1880156 about precisely the problem you are mentioning
[11:19] <mup> Bug #1880156: console-conf when run with auto-refresh of core20 will crash and become non-responsive <core20> <uc20> <snapd:Incomplete> <subiquity:Incomplete> <https://launchpad.net/bugs/1880156>
[11:19] <mvo> hey ijohnson
[11:19] <ijohnson> apparently I should respond there
[11:19] <mvo> ijohnson: ha! one step ahead :)
[11:19] <mvo> ijohnson: thank you!
[11:54]  * ijohnson -> afk 
[11:55] <mup> PR snapd#8842 opened: tests: fix bug waiting for snap command to be ready <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8842>
[11:59] <zyga> mvo: lmao
[11:59] <zyga> was that the bug?!
[12:00] <mvo> zyga: yes, well one bug :)
[12:04] <zyga> mvo: do you mean there are more?
[12:06] <mborzecki> https://forum.snapcraft.io/t/snaps-show-squares-instead-of-fonts/18073 hmm does pop os have a different fontconfig version too?
[12:07] <mborzecki> mvo: hmm funny, shellcheck could warn about that
[12:08] <cachio> mvo, hey
[12:08] <zyga> mborzecki: it's based on ubuntu so... unlikely
[12:08] <zyga> but ... dunno, install and check :)
[12:08] <cachio> snapd-vendor-sync running
[12:13] <mborzecki> if i had a penny for every linux distro i ever installed... :)
[12:18] <ogra> stgraber, are there any lxd images anywhere that do not waste the first 5min running cloud-init (read: do we have any minimal images that do not come with it)
[12:21] <stgraber> ogra: all official Ubuntu images have it, but we have unofficial images that don't.
[12:21] <stgraber> ogra: images:ubuntu/20.04
[12:21] <ogra> (i'm running stuff immediately when the container comes up ... and cloud-init just changes the whole config underneah me)
[12:22] <ogra> stgraber, thanks !
[12:28] <pedronis> zyga: I reviewed #8829
[12:28] <mup> PR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>
[12:29] <pedronis> zyga: I also commented yesterday in #8573 as you asked
[12:29] <mup> PR #8573: overlord/snapstate: inhibit startup while unlinked <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>
[12:29] <zyga> thanks!
[12:30] <zyga> pedronis: the "fail" thing is a bit mysterious, thank you for pointing that out
[12:30] <zyga> IIRC nothing in systemd itself uses the other value
[12:30] <zyga> but it can be traced to the source and I think got documented
[12:30] <zyga> I'll go over the rest and adjust it today
[12:31] <zyga> pedronis: I can move the random uuid to randutil in the same branch as I need to make changes anyway
[12:41] <pedronis> as you prefer
[12:42] <zyga> pedronis: I made some progress on the snap tooling fix, I will send a RFC today
[12:50] <ijohnson> zyga: there's now a random uuid function in randutil, see RandomKernelUUID
[12:50] <ijohnson> perhaps that was pedronis' comment
[12:50] <zyga> ah, I didn't know
[12:50] <zyga> perhaps that's all we need
[12:50] <zyga> thanks!
[12:51] <ijohnson> zyga: you might need to adjust it slightly and it's user in cmd_initramfs_mounts I think
[12:51] <ijohnson> but that should be fine
[12:53] <pedronis> ah, I forgot, it's probably there because I made the same comment at the time
[12:59] <mup> PR snapcraft#3166 opened: plugin handler: load legacy plugins prefixed with 'x-' <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3166>
[13:30]  * zyga break from computer
[13:39] <mborzecki> mvo: gdbserver could use some reviews, maybe zyga, ijohnson or pstolowski can take a look there?
[13:44] <zyga> I will look
[13:44] <zyga> It tomorrow morning fine?
[13:44] <zyga> I’m a bit tired by holding my laptop
[13:46] <ogra> zyga, before you go, did you have any idea regarding the /dev/shm ssue above ?
[13:46] <ogra> *issue
[13:46] <zyga> ogra: yes, sorry,
[13:47] <zyga> ogra: /dev/ is shared from host
[13:47] <zyga> ogra: os if one snap puts stuf there and the other consumes they can see the same thing
[13:47] <ogra> right ... but /dev/shm isnt writable
[13:47] <zyga> you need an interface more than content
[13:47] <ogra> (from a snap)
[13:47] <zyga> the interface that will model the relationship
[13:48] <zyga> ogra: content sharing won't work as you cannot share stuff that is not "yours"
[13:48] <zyga> ogra: layouts cannot work either as they are private to a view of a given snap
[13:48] <ogra> well /dev/shm/snap.$SNAP_NAME is mine
[13:49] <zyga> ogra: yours as in $SNAP, $SNAP_DATA
[13:49] <ogra> and they want to share content from /dev/shm/snap.$SNAP_NAME to another snap
[13:49] <zyga> content cannot share anything else
[13:49] <zyga> sure I get that
[13:49] <ogra> ok
[13:49] <ogra> you saying /dev got me confides
[13:49] <ogra> *confused
[13:49]  * ogra glares at his fingers 
[13:50] <zyga> content is not the way to share it IMO, please discuss this as a new interface
[13:51] <ogra> i know jdstrand ws looking at the possibility to have a pcscd (smartcard daemon) interface eventually ... i think that would allow such sharing ... but i dont think any work has happened in that area
[13:51] <zyga> ogra: if this is specific to a given daemon then I sugges pursuing that
[13:51] <ogra> zyga, not the way == impossible ? or just ugly ?
[13:51]  * zyga took the painkiller and tries to rest
[13:52] <zyga> ogra: hmm?
[13:52] <zyga> impossible
[13:52] <zyga> content cannot do that
[13:52] <ogra> ok
[13:52] <ogra> thanks !
[13:52] <jdstrand> not yet, no. if someone else wants to pick it up, that's fine
[13:52] <roadmr> zyga: ouch I hope you get better soon
[13:52] <jdstrand> (re pcsd)
[13:52] <zyga> roadmr: I hope so too
[13:56] <pstolowski> mborzecki: i can take a look
[13:58] <pstolowski> ijohnson: re hotplug & greedy plugs, i think we discussed something a few weeks ago and i replied to a question you had there but i don't remember where.. was there a bug report?
[13:58] <ijohnson> pstolowski: do you remember what it was about
[13:58] <ijohnson> pstolowski: oh if it's about greedy plugs jdstrand fixed it
[13:58] <ijohnson> hotplug + greedy plugs works with the right declaration
[13:59] <pstolowski> ijohnson: right, i think i hinted at declaration being na issue
[14:00] <jdstrand> there was a bug report
[14:00]  * jdstrand tries to find
[14:01] <zyga> mvo: snapd tools via export system https://www.irccloud.com/pastebin/ExcgIlg7/
[14:01] <jdstrand> but yes, it was a bug in the snap decl
[14:01] <jdstrand> https://bugs.launchpad.net/snapd/+bug/1876356
[14:01] <mup> Bug #1876356: greedy auto-connect doesn't work with hotplug <snapd:Fix Released by stolowski> <https://launchpad.net/bugs/1876356>
[14:01] <pstolowski> jdstrand: right, that's the bug, thanks
[14:02] <jdstrand> pstolowski: did you see that I asked you about experimental? if you did and responded, I'll read email (just came online)
[14:02] <pstolowski> jdstrand: sorry i didn't reply to your question there, missed it
[14:02] <pstolowski> jdstrand: on the forum? yes, i replied
[14:03] <jdstrand> yes, thanks
[14:09] <jdstrand> pstolowski: ok, I asked Field to give you some feedback
[14:10] <pstolowski> jdstrand: great, thank you!
[14:53] <zyga> pedronis: I have end-to-end implementation of RFC for exporting snapd tools
[14:53] <zyga> pedronis: I'll send the RFC branch in a moment
[14:53] <zyga> pedronis: the changes are surprisingly short
[15:00] <pedronis> zyga: this is without the snap-confine changes?
[15:00] <zyga> pedronis: with a tiny snap-confine change, snap-confine currently mounts the tools so I changed the path to use the exported tools instead
[15:51] <mborzecki> and back
[15:59] <mborzecki> refresh delta test failing?
[16:00] <mborzecki> 2020-06-09T13:24:50.3724981Z Jun 09 13:24:39 jun091254-105239 snapd[76428]: storehelpers.go:438: cannot refresh snap "test-snapd-delta-refresh": snap has no updates available
[16:03] <zyga> mborzecki: maybe store load?
[16:04] <zyga> mborzecki: I have something cool
[16:04] <mborzecki> zyga: what is that?
[16:04] <zyga> just running one more run of spread to see if I got a tweak right
[16:04] <zyga> mborzecki: exports
[16:04] <zyga> mborzecki: exporting stuff from snaps to host
[16:05] <zyga> mborzecki: use cases are numerous :)
[16:05] <zyga> mborzecki: but 1st use case is to fix this: https://forum.snapcraft.io/t/injecting-snapd-tools-into-base-snaps-and-keeping-them-up-to-date/12139/5
[16:10] <mborzecki> zyga: hm just a sec, bikeshedding on #8823, trying to make iteration smarter
[16:10] <mup> PR #8823: asserts/internal: limit Grouping size switching to a bitset representation <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8823>
[16:10] <zyga> mborzecki: heh sure :)
[16:10] <zyga> I was supposed to EOD anyway but I will be around for 15 more minutes
[16:11] <zyga> mborzecki: btw, do you remember this soundtrack? https://www.youtube.com/watch?v=Kf8j3FYxekk
[16:12] <mborzecki> zyga: staying a bit longer today, got some errands to run during the day tomorrow
[16:12] <zyga> yeah
[16:12] <zyga> my errand was to walk to the loo today :P
[16:12] <mborzecki> zyga: and ofc i remember this, it's even on spotify
[16:12] <zyga> mborzecki: I played some on x240
[16:13] <zyga> wish I could go down to the office to play on a real computer
[16:13] <zyga> but the sound is great (on headphones, not on x240)
[16:14] <mborzecki> hm did some changes and it works, wonder if the test cases are enough
[16:16] <zyga> I have a "macro" ggg
[16:17] <pedronis> mborzecki: what are you trying to do?
[16:20] <mborzecki> pedronis: checking whether i can further limit the number of iterations with bitset having counted leading & trailing zeros
[16:21] <pedronis> mborzecki: are you using math/bits ?
[16:21] <mborzecki> pedronis: yeah
[16:21] <mborzecki> pedronis: does that pull in some crazy dep?
[16:21] <pedronis> no, it's mostly table based
[16:21] <pedronis> I'm not sure it would make me change my mind
[16:21] <pedronis> about keeping the two impls tough
[16:22] <pedronis> the other thing we care about is also Serialize size
[16:23] <mborzecki> pedronis: i was curious to try that out ;)
[16:23] <pedronis> it's ok, I mean abour serialisation again we could be clever but at some point it all gets even more complicated to track
[16:24] <pedronis> than two very distinct paths
[16:31] <pedronis> mborzecki: the leading zero change should be relatively straighforward no?
[16:31] <mborzecki> pedronis: let me show you the diff
[16:32] <mborzecki> pedronis: https://paste.ubuntu.com/p/vxtcGMMRB5/
[16:33] <pedronis> I see
[16:34] <mborzecki> pedronis: trims the loop range a bit
[16:34] <mborzecki> pedronis: i'll post it in a comment
[16:41] <pedronis> mborzecki: I didn't think of this, but we probably don't need to use both functions, instead of shifting bit, we could shift w until its 0
[16:42] <mborzecki> pedronis: ha, yeah, nice idea
[16:53] <mborzecki> mvo: pstolowski left some comments under #8784, i'll address them
[16:53] <mup> PR #8784: snap: add new `snap run --gdbserver` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8784>
[17:39] <zyga> ok, did the change I wanted
[17:39] <zyga> it should now work on fedora as well
[17:40] <zyga> (and arch :)
[17:56] <mborzecki> doesn't look like we'll land anything today
[17:58] <zyga> mborzecki: ?
[17:58] <mborzecki> the delta test is failing
[17:59] <zyga> ah
[17:59] <zyga> did you ask store devs?
[17:59] <mborzecki> actually wanted to run the test myself, but the logs say there's no update for the snap (which is weird i guess?)
[18:00] <zyga> hmm
[18:00] <mborzecki>   latest/beta:      1.0+fake1 2017-05-17 (5) 2MB -
[18:00] <mborzecki>   latest/edge:      1.0+fake1 2017-05-17 (3) 2MB -
[18:00] <mborzecki> edge and beta have different revisions, so the test should work
[18:01] <zyga> mmmm
[18:01] <zyga> maybe store bug?
[18:01] <zyga> if you refresh the snap by name
[18:01] <zyga> does it work?
[18:01] <zyga> sergiusens had this issue with multipass in #snapcraft now
[18:03] <Saviq> So classic -> strict may be a red herring?
[18:03] <zyga> btw
[18:03] <zyga> progress bars are gone
[18:03] <zyga> what happened?
[18:04] <mvo> zyga: what/where?
[18:04] <zyga> mvo: snap install foo
[18:04] <zyga> shows no progress bar
[18:04] <mvo> zyga: I see a lot of failures that progress is missing
[18:04] <mvo> zyga: if it's very fast (the install) you don't see one
[18:04] <zyga> it's gone :)
[18:04] <zyga> it doesn't print
[18:04] <mvo> zyga: iirc that's normal
[18:05] <zyga> why?
[18:05] <zyga> it used to
[18:05] <mvo> zyga: really? I think I noticed this a while ago that it is sometimes missing and iirc it was just too quick
[18:05] <zyga> hmmm
[18:05] <zyga> I installed snapd
[18:05] <zyga> and it took a while
[18:05] <zyga> and there was no progress at all
[18:05] <mvo> zyga: oh, then it might be a bug
[18:05] <zyga> mvo: I implemented the "C" approach today
[18:05] <mvo> zyga: \o/
[18:05] <zyga> and did some manual testing to play around and see how things wokr
[18:05] <zyga> *work
[18:06] <mup> PR snapd#8843 opened: [RFC] many: export tools from core/snapd to mount namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/8843>
[18:07] <zyga> I meant for this to be a draft
[18:07] <zyga> but oh well
[18:08] <zyga> mborzecki: ^ check it out
[18:12]  * zyga EODs and closes IRC
[18:12] <zyga> mvo: tomorrow I will be partially of for the MRI
[18:12] <mvo> zyga: good luck
[18:12] <zyga> thanks
[18:32] <mup> PR snapd#7900 closed: tests: do reset of tests during restore and add checks to validate the fs <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7900>
[18:51] <mborzecki> looking
[18:54] <mborzecki> hmm Jun 09 20:52:21 galeon snapd[28574]: taskrunner.go:439: DEBUG: Running task 4103 on Do: Download snap "test-snapd-delta-refresh" (5) from channel "latest/beta"
[18:54] <mborzecki> Jun 09 20:52:21 galeon snapd[28574]: store_download.go:137: DEBUG: Available deltas returned by store: []
[18:54] <mborzecki> that's why it's failing
[18:54] <mborzecki> cachio__: ijohnson: ^^
[19:03] <cachio> mborzecki, where did you see that?
[19:03] <mborzecki> cachio: all the recent ci runs
[19:03] <cachio> mborzecki, do the store team know about that??
[19:04] <mborzecki> cachio: no, haven't reached out yet, was about to EOD
[19:04] <cachio> mborzecki, ok, np, I can take it
[19:04] <mborzecki> cachio: great, thank you
[19:04] <cachio> enjoy your EOD
[19:04] <cachio> mborzecki,
[19:06] <mborzecki> cachio: https://github.com/snapcore/snapd/runs/754908664
[22:47] <Intruder777> hello, how can I list and install older versions of a particular snap?
[22:48] <Intruder777> snap info <package> seem to show only latest
[22:57] <oerheks> some snaps give stable / candidate /  beta / edge versions.
[22:58] <Intruder777> oerheks: how do I list and install older versions from stable channel?
[22:58] <oerheks> snaps with bugs are likely to be removed
[22:59] <Intruder777> stupid thing did auto update...
[23:00] <Intruder777> oerheks: snap info shows me only latest version for "stable". how do I see and install some older versions?
[23:02] <oerheks> not?
[23:03] <Intruder777> not?
[23:03] <Intruder777> what do you mean?
[23:04] <oerheks> sudo snap revert <package> # but this requires an older available version that you could see with snap info too
[23:04] <oerheks> like; snap list --all vlc
[23:05] <oerheks> https://snapcraft.io/docs/getting-started#heading--revert
[23:05] <Intruder777> revert says "no revision to revert to"
[23:10] <Intruder777> I've tried to do `snap refresh <pckg> --revision=..." by guessing older revision number, but it says "Access by specifying a revision is not allowed for this
[23:10] <Intruder777>  Snap"
[23:11] <Intruder777> how is this situation possible at all??? with the package manager?
[23:11] <oerheks> that happens, when it is prop software..
[23:11] <oerheks> what snap are you talking about?
[23:11] <Intruder777> opensource one
[23:11] <Intruder777> telegram-desktop
[23:12] <Intruder777> I mean how it can be in 2020 that package manager silently upgrades packages without permission?
[23:12] <Intruder777> and then there is no way to revert it back...
[23:12] <Intruder777> that's freaking nonsense
[23:13] <oerheks> no, not if there is a fix for a leak or vulnarability.
[23:13] <oerheks> contact the snap maintainer?
[23:13] <Intruder777> the snap itself have to at least backup previous version before upgrading without permission
[23:14] <Intruder777> so I don't have to contact package maintainer
[23:14] <oerheks> oh, 'edge' got an update today
[23:14] <oerheks> https://snapcraft.io/telegram-desktop
[23:16] <Intruder777> I need previous versions.
[23:17] <oerheks> You can save installed packages using following code; snap save ; And then all the installed packeges will be zipped with data to /var/lib/snapd/snapshots/
[23:17] <Intruder777> oerheks: is there a way to configure snap to always make backup when refreshing to newer version?
[23:18] <oerheks> so, for edge you would do this manually ( from now on) . i see  not way to get older versions back
[23:18] <Intruder777> maybe you know how to fix this: "telegram-desktop: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory"
[23:18] <Intruder777> I've tried to uninstall and reinstall the snap and it doesn't help
[23:22] <Intruder777> oerheks: it was working fine before and now shows this error
[23:23] <oerheks> i find some older posts about this, "snap refresh" fixed the problem.
[23:24] <oerheks> but if you run the latest edge, you might want to file a bugreport to the maintainer.
[23:24] <Intruder777> I run latest stable
[23:24] <Intruder777> 2.1.11
[23:25] <oerheks> removing a snap would also mean removing the settings in ~/snap/<snapname>
[23:25] <Intruder777> so?
[23:25] <Intruder777> what's your point?
[23:25] <oerheks> just saying
[23:25] <Intruder777> I already did it twice
[23:26] <Intruder777> it was not working before I did it. and it still doesn't work now
[23:26] <Intruder777> oerheks: is there a way to remount snap filesystem for read/write?
[23:28] <oerheks> yes, see answer popey https://forum.snapcraft.io/t/mount-snap-with-rw-for-troubleshooting-propose/12264
[23:29] <Intruder777> all my experience with a snap is a story of failures. I use to install rocket-chat from a snap and one day it stopped working because stupid snap is configured to auto update packages by default and the newer version of rocket-chat had a glitch which breaks the mongo-db migration, so it bricked all my local settings. craziness. now I installed telegram-desktop. and again, the auto-update screwed things up
[23:30] <Intruder777> what crazy people set auto updating packages by default??
[23:34] <Intruder777> that link says "You can unsquashfs the snap to a folder then snap try foldername/ which will “install” the snap directly from that folder." - very helpful. an how do I do those steps? can I somehow make changes directly in /var/lib/snapd/snap/kde-frameworks-5-core18/32/usr/lib/x86_64-linux-gnu/?
[23:36] <oerheks> just contact the maintainer, i am not going to write that bugreport for you
[23:42] <Intruder777> oerheks: I don't need to contact maintainer and wait for it to fix it. I wanted to fix it by trying to change Qt lib version directly inside snap
[23:46] <Intruder777> oerheks: ok, I've just downloaded the linux binary from Telegram site and it works. and the snap goes to trash bin