| === dennwc_ is now known as dennwc | ||
| zyga | good morning | 06:32 |
|---|---|---|
| mborzecki | morning | 07:16 |
| zyga | hello | 07:59 |
| mvo | hey zyga ! good morning | 08:07 |
| zyga | mvo, hey | 08:08 |
| zyga | mvo, I collected my three git trees for ian | 08:08 |
| pstolowski | morning | 08:11 |
| zyga | hey pstolowski | 08:11 |
| mvo | zyga: remind me what these trees are? | 08:14 |
| mvo | pstolowski: good morning! | 08:15 |
| zyga | mvo, he asked me about copies of my snapd tree | 08:17 |
| zyga | mvo, to pick up things I abandoned | 08:17 |
| zyga | mvo, I have three tarballs of my workstations | 08:17 |
| zyga | (of snapd.git that is) | 08:17 |
| mborzecki | pstolowski: mvo: hey | 08:26 |
| mvo | good morning mborzecki ! how are you? | 08:28 |
| mborzecki | mvo: bit disappointed it's not friday again ;) | 08:30 |
| mvo | mborzecki: hahaha | 08:33 |
| mvo | mborzecki: we have snow here, it's great | 08:33 |
| zyga | mvo, zmk is in Debian and Ubuntu now, I have an update going out this week that adds a lot of static analysis support | 09:10 |
| mvo | zyga: nice | 09:17 |
| zyga | mvo, I would like to do an experiment and build snap-confine with zmk, to see what shows up | 09:25 |
| zyga | there are bits missing though, I did not finish the compile-time probing support, that would allow us to get conditional apparmor/selinux support, for example | 09:26 |
| zyga | mvo, I have a few more packages but I will sponsor them through the debian python team | 09:26 |
| zyga | mvo, as for qemu, I think I will ask you to sponsor but depenencies should go through the go team | 09:27 |
| zyga | mvo, er, not qemu, spread :) | 09:27 |
| mvo | zyga: yeah, spread should be in the team maintained repo | 09:40 |
| mup | PR snapd#9859 opened: overlord: addd manager gadget refresh test <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9859> | 10:10 |
| zyga | mvo, but should it be the generic go team or the specifc people that effectively use and participate in spread development? | 10:10 |
| mvo | zyga: I would just use the generic go team repo at least for now | 10:26 |
| mvo | zyga: until there is a real community around it that drive things | 10:26 |
| ijohnson | morning folks | 12:33 |
| mvo | ijohnson: good morning! hope you had a nice weekend | 12:33 |
| ijohnson | yes I did, it snowed a bit here and things look white again instead of the gray mush it was before :-) | 12:34 |
| mborzecki | ijohnson: hey | 12:34 |
| ijohnson | hey mborzecki | 12:34 |
| zyga | ijohnson, hey | 12:45 |
| ijohnson | hey zyga | 12:45 |
| ijohnson | zyga: did you get all your fosdem prep done? | 12:45 |
| zyga | ijohnson, yes, all done now | 12:47 |
| ijohnson | nice | 12:47 |
| zyga | ijohnson, I've collected my three snapd trees | 12:48 |
| zyga | ijohnson, I'll share the link via a private message | 12:48 |
| ijohnson | awesome, thank you! | 12:48 |
| zyga | have a look | 12:48 |
| zyga | it's rather messy but that's what I managed to find on my three mainly used environments | 12:48 |
| zyga | (blame me for myriad of VMs and systems) | 12:48 |
| ogra | hrm | 12:53 |
| ogra | ijohnson, remember the snap-exec denial i saw with teh confogure hook on pi ? ... i removed the configure hook ... but i still get: | 12:54 |
| ogra | apparmor="ALLOWED" operation="capable" info="optional: no audit" error=-1 profile="snap.kodi-pi-standalone.hook.configure" pid=13237 comm="snap-exec" capability=12 capname="net_admin" | 12:54 |
| ijohnson | ogra: did you ever file a bug for that like I asked :-) | 12:54 |
| ogra | which is really confising ... | 12:54 |
| ogra | *confusing | 12:54 |
| ogra | ijohnson, not yet ... since i wanted to llok into it a bit deeper first ... the snap is a multi snap, armhf binaries but run on arm64, so i was assuming this might have something to do with it that i wanted to research first | 12:55 |
| ijohnson | well sure, just saying that I didn't look into it anymore and planned on looking into it when you filed a bug | 12:56 |
| ogra | but now i moved the config code to a oneshot daemon ... so there is no cionfigure hook since a few revisions now | 12:56 |
| ogra | yet snapd still seems to execute something here ... | 12:56 |
| ijohnson | cachio: hey could you take a look at tests/lib/tools/suite/tests.pkgs when you get a chance? it seems to be failing on centos-8 consistently i.e. https://github.com/snapcore/snapd/pull/9852/checks?check_run_id=1751095796 | 13:03 |
| mup | PR #9852: gadget: enable multi-volume uc20 gadgets in LaidOutVolumeFromGadget; rename too <Bug> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9852> | 13:03 |
| cachio | ijohnson, hi, sure | 13:05 |
| ijohnson | thanks cachio | 13:08 |
| * ijohnson afk a bit | 13:09 | |
| * pstolowski lunch | 13:13 | |
| zyga | cachio, hey, I sent a review for the test log scanner | 13:39 |
| cachio | zyga, yes, thanks | 13:40 |
| cachio | I'll take a look today | 13:41 |
| mup | PR snapd#9860 opened: tests: update test pkg for fedora and centos <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9860> | 13:51 |
| mup | PR snapcraft#3428 opened: pip 21 dropped support for python 3.5 and python 2 <Created by philroche> <https://github.com/snapcore/snapcraft/pull/3428> | 14:10 |
| StyXman_ | ok, no answer, so I'll just ask. with snap changes [snap] I can see the _last_ time a snap was changed. can I see *all* the times the snap whas changed? | 15:26 |
| mup | PR snapd#9860 closed: tests: update test pkg for fedora and centos <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9860> | 15:26 |
| ogra | snap changes do generally only go back 72h ... | 15:27 |
| ogra | (its a ringbuffer ... kind of) | 15:27 |
| ijohnson | StyXman_: unfortunately snapd will garbage collect old tasks/changes from the the state so no there is not a way to see all times that a snap was changed like that | 15:27 |
| ogra | as a packager you can see all revisions ever done in the store UI though ... but that does indeed not help you as a user | 15:28 |
| StyXman_ | so everytime a (few) new versions introduce a bug I should figure out myself which version did it? this is for software that I don't use daily... of course, I should find a version that works for me a folow that, right? | 15:30 |
| ijohnson | mborzecki: hey have you seen mounting snaps returning "Operation not permitted" on arch lately? I am trying to reproduce another spread failure on arch and ran into this where I can't mount any squashfs due to EPERM | 15:54 |
| ijohnson | interestingly, it seems like there are no available loop devices: | 15:55 |
| ijohnson | ``` | 15:55 |
| ijohnson | $ losetup -f | 15:55 |
| ijohnson | losetup: cannot find an unused loop device: No such device | 15:55 |
| ijohnson | ``` | 15:55 |
| zyga | ijohnson, I think there is a limit to the number of loop devices | 16:19 |
| zyga | we increased it to something higher but it's not arbitrarily high | 16:20 |
| ijohnson | hmm, but on that system I don't think there was any loop devices | 16:20 |
| ogra | the kernel has 256 by default nowadays IIRC | 16:20 |
| ogra | but can dynamically assign more ... | 16:20 |
| zyga | ogra, 256 snaps should be enough for ... wait all the revisions... | 16:20 |
| zyga | yeah | 16:20 |
| ogra | (i tink the limit is sizeof_int) | 16:21 |
| * ijohnson has 313 snap files and no problem on his desktop | 16:21 | |
| ogra | right | 16:21 |
| ogra | the pre-created loop devices are mainly for speeding up boot on UC | 16:21 |
| ogra | because creating the devices takes a split second or so ... which sums up | 16:21 |
| zyga | ogra, I'm proud of myself, managed to run zephyr tests through bitbake today | 16:22 |
| ogra | haha ... the wonderful world of microcontollers | 16:22 |
| ogra | there is a pi for that now ! | 16:22 |
| ogra | (though sadly without networking/bt by default) | 16:23 |
| zyga | ogra, I know, I bought a handful of those | 16:25 |
| ogra | ha | 16:25 |
| zyga | yeah, I'm sure pi pico 2 will have something RF | 16:26 |
| zyga | for now I'm just doing qemu runs | 16:26 |
| ogra | i'm waiting for the adafruit spinoff ... need wlan/BT | 16:26 |
| ogra | (they are supposed to have it) | 16:26 |
| zyga | I plan to use them as signal generators | 16:26 |
| ogra | the only place where i could use non-networked would be as a keyboard controller for one of my handmade kbd'S | 16:27 |
| ogra | but for that they are physically too big | 16:27 |
| mup | PR snapcraft#3429 opened: plugins: Pin pip to supported versions <Created by philroche> <https://github.com/snapcore/snapcraft/pull/3429> | 17:00 |
| === pedronis_ is now known as pedronis | ||
| pedronis | mvo: we probably want #9820 in 2.49 ? it needs second reviews | 17:03 |
| mup | PR #9820: o/snapshotstate: handle conflicts between snapshot forget, export and import <Created by stolowski> <https://github.com/snapcore/snapd/pull/9820> | 17:03 |
| pedronis | mvo: #9817 is also desired | 17:05 |
| mup | PR #9817: cmd/snapd-generator: don't create mount overrides for snap-try snaps inside lxc <Bug> <Needs security review> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9817> | 17:05 |
| pedronis | pstolowski: I forgot about these or thought the latter was landed already ^ | 17:07 |
| mup | PR snapd#9780 closed: many: use ResolvedSource() from gadget content when writing boot assets <Run nested> <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/9780> | 17:07 |
| pedronis | #9837 needs a 2nd review | 17:07 |
| mup | PR #9837: cmd/snap-repair: filter repair assertions based on bases + modes <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9837> | 17:07 |
| pstolowski | pedronis: oh indeed | 17:07 |
| pstolowski | but it needs security.. | 17:08 |
| pstolowski | also some tweaks suggested by mborzecki | 17:08 |
| pedronis | does it? mmh, mvo added it | 17:08 |
| pedronis | ah, because we changed the library? | 17:09 |
| pstolowski | pedronis: yes | 17:09 |
| pedronis | bit of :/ | 17:10 |
| pstolowski | i'll address Maciej's comments but not sure it can get reviews | 17:10 |
| mvo | pedronis: 9817> yes! | 17:10 |
| ijohnson | pedronis: I figured out the issue with needing the Label and the Role check in my gadget pr, should I file a separate PR to fix handling the SystemBoot role/label like you intended ? | 17:10 |
| ijohnson | or just fix it in the pr | 17:11 |
| pedronis | ijohnson: is it broken? | 17:11 |
| pedronis | bit surprised | 17:11 |
| ijohnson | pedronis: yes we don't handle the implicitness of `filesystem-label: system-boot` being the same as `role: system-boot` | 17:11 |
| pedronis | we do | 17:11 |
| pedronis | but you need to be sure to be on UC16/18 | 17:12 |
| ijohnson | err rather we don't _change_ the volumes to set Role in that case | 17:12 |
| pedronis | which maybe some test isn't | 17:12 |
| ijohnson | we don't fail in that case | 17:12 |
| ijohnson | but we don't modify the volume structure's Role to have SystemBoot | 17:12 |
| ijohnson | maybe I'm wrong but I just added that code and it made the tests pass again so I'm like 95% confident we don't have that code right now | 17:12 |
| pedronis | ijohnson: https://github.com/snapcore/snapd/blob/master/gadget/gadget.go#L420 | 17:13 |
| pedronis | maybe the test you care about is not hitting it | 17:13 |
| ijohnson | huh yeah it seems the test it not hitting that codebase at all | 17:14 |
| pedronis | then the test is off | 17:14 |
| pedronis | that code is at it should be afaik | 17:14 |
| pedronis | s/at/as/ | 17:14 |
| ijohnson | the test is just calling `gadget.LaidOutSystemVolumeFromGadget` | 17:14 |
| pedronis | passing what? | 17:15 |
| ijohnson | so it seems that gadget.LaidOutSystemVolumeFromGadget needs to do more | 17:15 |
| ijohnson | pedronis: the test is TestLaidOutSystemVolumeFromGadgetHappy | 17:15 |
| ijohnson | in gadget_test.go | 17:15 |
| pedronis | ijohnson: you need to pass a model | 17:16 |
| ijohnson | :-/ | 17:16 |
| ijohnson | but okay | 17:16 |
| pedronis | it doesn't make sense to use LaidOutSytemVoumeFromGadget without a real model | 17:16 |
| pedronis | well model, one of our mocks is fine | 17:17 |
| pedronis | anyway the point stand | 17:17 |
| mup | PR snapd#9861 opened: gadget: run resolveContentPaths() when laying out a volume <Run nested> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9861> | 17:17 |
| pedronis | the actual prod code will have a model as it should | 17:17 |
| pedronis | ijohnson: I mean, nothing to :-/ about here :) | 17:18 |
| ijohnson | I guess I'm just :-/ because there are a lot of unit tests from before my pr that are passing nil as the model | 17:18 |
| ijohnson | and while yes the only place that uses it in production will always have a model, that's not clear from looking at all the tests that pass in nil | 17:19 |
| ijohnson | anyways yes I can fix this up | 17:19 |
| pedronis | ijohnson: yea, sorry, but what I said is true, it's also true that it's hard to fix tests that don't fail when you make a change | 17:20 |
| ijohnson | indeed it is | 17:20 |
| * ijohnson shakes fists at tests that aren't failing | 17:20 | |
| mvo | cachio: snapd/core in beta should be ready later today | 17:20 |
| mvo | cachio: 2.49~rc1 are building right now | 17:21 |
| pedronis | ijohnson: I suggest making that fuction error if model is nil | 17:21 |
| ijohnson | yeah I saw that suggestion I like that suggestion | 17:21 |
| pedronis | it's what we want anyway, just a bit annoying | 17:21 |
| mvo | pedronis: I made another attempt to make the resolving of the content paths for the gadget updates easier to review in 9861. no rush but high level feedback welcome, hope this time it's less distracting (a followup will then cleanup the todos or I can do them right in this pr but then it will grow a bit) | 17:22 |
| pedronis | I queued it | 17:25 |
| === hggdh_ is now known as hggdh | ||
| === ijohnson is now known as ijohnson|lunch | ||
| === ijohnson|lunch is now known as ijohnson | ||
| === tai271828_ is now known as tai271828 | ||
| === cjp256_ is now known as cjp256 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!