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> | 01:07 |
---|---|---|
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> | 03:33 |
=== KindTwo is now known as KindOne | ||
mborzecki | morning | 05:21 |
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:09 |
mborzecki | mvo: hey | 06:18 |
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:19 |
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:22 |
mvo | mborzecki: cherry-picked, thank you | 06:24 |
mborzecki | mvo: thanks! | 06:24 |
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:26 |
zyga | Yes, i saw it in Ubuntu 20.04 as well | 06:28 |
zyga | Good morning | 06:28 |
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:29 |
zyga | Hey, sorry to be up so late. A bit sleepy still. I could not sleep well | 06:30 |
mborzecki | heh, funny, spread discards the node that failed suite level prepare? | 06:32 |
zyga | it's day two but my little daughter is still very reluctant to approach me | 06:35 |
zyga | I guess I need to find a xmas beard and glue it first :) | 06:36 |
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:40 |
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:44 |
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:45 |
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:47 |
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:48 |
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:49 |
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:50 |
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:57 |
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:58 |
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 | 06:59 | |
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:01 |
pedronis | mvo: also afaict this started appearing only last week? I wonder what changed | 07:02 |
mvo | pedronis: yeah, it's pretty new | 07:02 |
pstolowski | morning | 07:03 |
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:05 |
zyga | I think we all agree we need more data | 07:06 |
zyga | back in 15 min | 07:08 |
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:18 |
zyga | mvo: are you testing locally? | 07:20 |
mvo | zyga: in qemu | 07:23 |
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:24 |
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:25 |
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:26 |
pedronis | mvo: let me make a precise suggestion | 07:28 |
mvo | pedronis: \o/ | 07:28 |
mvo | pedronis: thank you | 07:28 |
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:30 |
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:32 |
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> | 07:34 |
mborzecki | quick errand, back in 30 | 08:31 |
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:39 |
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> | 08:49 |
mborzecki | re | 09:13 |
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:33 |
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:35 |
pstolowski | pedronis: i think the tests i've in this PR need to be moved entirely to servicestate | 09:36 |
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:37 |
pedronis | pstolowski: I really don't have a strong opinion, you an use whatever work best for the tests | 09:38 |
pstolowski | pedronis: ok, thanks | 09:40 |
* pstolowski lunch | 10:09 | |
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:13 |
ackk | (also "snap info q" doesn't find anything) | 10:14 |
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:17 |
pedronis | snapd will never install them | 10:18 |
ackk | pedronis, I see, thanks | 10:18 |
zyga | ogra: can you explain in more detail please | 10:32 |
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:35 |
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:36 |
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:40 |
* zyga break to rest | 10:42 | |
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:45 |
mborzecki | heh 17 files changed, 147 insertions(+), 1414 deletions(-) | 10:46 |
mborzecki | heh, hit that too early for operation thing again | 10:48 |
zyga | mborzecki: oh | 10:56 |
zyga | do you have more logs? | 10:56 |
zyga | mvo added debug bits | 10:56 |
mborzecki | nope | 10:57 |
zyga | you had older masteR? | 10:57 |
mborzecki | yeah | 10:59 |
mborzecki | but i have another new PR running, let me check whetherh it has the right changes | 11:00 |
mborzecki | ehh nope | 11:00 |
mvo | xnox: I pushed a small tweak to 8808, should be ok to re-review | 11:10 |
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:17 |
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:18 |
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:19 |
* ijohnson -> afk | 11:54 | |
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:55 |
zyga | mvo: lmao | 11:59 |
zyga | was that the bug?! | 11:59 |
mvo | zyga: yes, well one bug :) | 12:00 |
zyga | mvo: do you mean there are more? | 12:04 |
mborzecki | https://forum.snapcraft.io/t/snaps-show-squares-instead-of-fonts/18073 hmm does pop os have a different fontconfig version too? | 12:06 |
mborzecki | mvo: hmm funny, shellcheck could warn about that | 12:07 |
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:08 |
mborzecki | if i had a penny for every linux distro i ever installed... :) | 12:13 |
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:18 |
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:21 |
ogra | stgraber, thanks ! | 12:22 |
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:28 |
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:29 |
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:30 |
zyga | pedronis: I can move the random uuid to randutil in the same branch as I need to make changes anyway | 12:31 |
pedronis | as you prefer | 12:41 |
zyga | pedronis: I made some progress on the snap tooling fix, I will send a RFC today | 12:42 |
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:50 |
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:51 |
pedronis | ah, I forgot, it's probably there because I made the same comment at the time | 12:53 |
mup | PR snapcraft#3166 opened: plugin handler: load legacy plugins prefixed with 'x-' <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3166> | 12:59 |
=== Eighth_Doctor is now known as Conan_Kudo | ||
=== Conan_Kudo is now known as Eighth_Doctor | ||
=== Eighth_Doctor is now known as Eleventh_Doctor | ||
=== Eleventh_Doctor is now known as Eighth_Doctor | ||
* zyga break from computer | 13:30 | |
mborzecki | mvo: gdbserver could use some reviews, maybe zyga, ijohnson or pstolowski can take a look there? | 13:39 |
zyga | I will look | 13:44 |
zyga | It tomorrow morning fine? | 13:44 |
zyga | Iβm a bit tired by holding my laptop | 13:44 |
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:46 |
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:47 |
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:48 |
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:49 | |
zyga | content is not the way to share it IMO, please discuss this as a new interface | 13:50 |
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:51 | |
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:52 |
pstolowski | mborzecki: i can take a look | 13:56 |
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:58 |
pstolowski | ijohnson: right, i think i hinted at declaration being na issue | 13:59 |
jdstrand | there was a bug report | 14:00 |
* jdstrand tries to find | 14:00 | |
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:01 |
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:02 |
jdstrand | yes, thanks | 14:03 |
jdstrand | pstolowski: ok, I asked Field to give you some feedback | 14:09 |
pstolowski | jdstrand: great, thank you! | 14:10 |
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 | 14:53 |
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:00 |
mborzecki | and back | 15:51 |
mborzecki | refresh delta test failing? | 15:59 |
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:00 |
zyga | mborzecki: maybe store load? | 16:03 |
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:04 |
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:05 |
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:10 |
zyga | mborzecki: btw, do you remember this soundtrack? https://www.youtube.com/watch?v=Kf8j3FYxekk | 16:11 |
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:12 |
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:13 |
mborzecki | hm did some changes and it works, wonder if the test cases are enough | 16:14 |
zyga | I have a "macro" ggg | 16:16 |
pedronis | mborzecki: what are you trying to do? | 16:17 |
mborzecki | pedronis: checking whether i can further limit the number of iterations with bitset having counted leading & trailing zeros | 16:20 |
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:21 |
pedronis | the other thing we care about is also Serialize size | 16:22 |
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:23 |
pedronis | than two very distinct paths | 16:24 |
pedronis | mborzecki: the leading zero change should be relatively straighforward no? | 16:31 |
mborzecki | pedronis: let me show you the diff | 16:31 |
mborzecki | pedronis: https://paste.ubuntu.com/p/vxtcGMMRB5/ | 16:32 |
pedronis | I see | 16:33 |
mborzecki | pedronis: trims the loop range a bit | 16:34 |
mborzecki | pedronis: i'll post it in a comment | 16:34 |
=== KindTwo is now known as KindOne | ||
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:41 |
mborzecki | pedronis: ha, yeah, nice idea | 16:42 |
=== ijohnson is now known as ijohnson|lunch | ||
=== msalvatore_ is now known as msalvatore | ||
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> | 16:53 |
zyga | ok, did the change I wanted | 17:39 |
zyga | it should now work on fedora as well | 17:39 |
zyga | (and arch :) | 17:40 |
mborzecki | doesn't look like we'll land anything today | 17:56 |
=== ijohnson|lunch is now known as ijohnson | ||
zyga | mborzecki: ? | 17:58 |
mborzecki | the delta test is failing | 17:58 |
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?) | 17:59 |
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:00 |
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:01 |
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:03 |
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:04 |
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:05 |
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:06 |
zyga | I meant for this to be a draft | 18:07 |
zyga | but oh well | 18:07 |
zyga | mborzecki: ^ check it out | 18:08 |
* 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:12 |
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:32 |
mborzecki | looking | 18:51 |
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: ^^ | 18:54 |
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:03 |
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:04 |
mborzecki | cachio: https://github.com/snapcore/snapd/runs/754908664 | 19:06 |
Intruder777 | hello, how can I list and install older versions of a particular snap? | 22:47 |
Intruder777 | snap info <package> seem to show only latest | 22:48 |
oerheks | some snaps give stable / candidate / beta / edge versions. | 22:57 |
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:58 |
Intruder777 | stupid thing did auto update... | 22:59 |
Intruder777 | oerheks: snap info shows me only latest version for "stable". how do I see and install some older versions? | 23:00 |
oerheks | not? | 23:02 |
Intruder777 | not? | 23:03 |
Intruder777 | what do you mean? | 23:03 |
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:04 |
oerheks | https://snapcraft.io/docs/getting-started#heading--revert | 23:05 |
Intruder777 | revert says "no revision to revert to" | 23:05 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
Intruder777 | I need previous versions. | 23:16 |
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:17 |
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:18 |
Intruder777 | oerheks: it was working fine before and now shows this error | 23:22 |
oerheks | i find some older posts about this, "snap refresh" fixed the problem. | 23:23 |
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:24 |
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:25 |
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:26 |
oerheks | yes, see answer popey https://forum.snapcraft.io/t/mount-snap-with-rw-for-troubleshooting-propose/12264 | 23:28 |
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:29 |
Intruder777 | what crazy people set auto updating packages by default?? | 23:30 |
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:34 |
oerheks | just contact the maintainer, i am not going to write that bugreport for you | 23:36 |
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:42 |
Intruder777 | oerheks: ok, I've just downloaded the linux binary from Telegram site and it works. and the snap goes to trash bin | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!