[06:47] morning [07:10] mborzecki: hi! [07:11] hey [08:03] PR snapd#11075 closed: tests: use --snap instead of --extra-snaps to create the core image [08:07] morning [08:10] good morning [08:18] PR snapd#11076 closed: snapcraft.yaml: fix advanced grammar & 20.04 packaging [08:27] need 2nd review in https://github.com/snapcore/snapd/pull/11071 🙂 should be very easy to test locally too [08:27] PR #11071: data/env: provide profile setup for fish shell [09:02] mardy: maybe you can take a look ^^ [09:43] PR snapd#11077 closed: tests: use ubuntu-image 1.11 from stable channel [09:48] PR snapd#11071 closed: data/env: provide profile setup for fish shell [09:58] PR snapd#11078 opened: tests: disable flaky uc18 tests until systemd is fixed [11:44] PR snapd#11079 opened: packaging: sync with downstream packaging in Fedora and openSUSE [11:50] a simple PR ^^ [12:54] PR snapd#11080 opened: builtin/interfaces: add shared memory interface [13:24] mardy NICE [13:25] mardy left one comment [13:37] zyga-mbp: thanks :-) [13:39] zyga-mbp: what about "allows two snaps to use a named shared memory object"? [13:39] I was mainly going back to original issues with /dev/shm [13:39] like chrome using random files there [13:39] this interface doesn't help there right? [13:39] I'm only looking at docs / usability and not tech here [13:40] since the interface allows /dev/shm/$stuff [13:42] zyga-mbp: at the moment wildcards are not allowed, so you need to specify a precise name (or list of names) [13:43] right [13:43] I'm just trying convey that the summary doesn't convey that the interface is not automatically g related to /dev/shm [13:44] *handling everthing [13:49] zyga-mbp: true. And if I add "redefined"? Like: "allows two snaps to use a predefined shared memory object" [13:49] yeah, that's good [13:49] *predefined [13:49] * zyga-mbp I think it's just about setting expectations, as I said I know why this is like that [13:50] and it's also nothing I disagree with technically [13:50] ok, I'll change it then [14:29] PR snapd#11078 closed: tests: disable flaky uc18 tests until systemd is fixed [14:29] PR snapd#11081 opened: tests: Revert "tests: disable flaky uc18 tests until systemd is fixed" <⛔ Blocked> [14:49] mborzecki: need any reviews? [14:51] pstolowski: https://github.com/snapcore/snapd/pull/11053 is something I would love to see landing soon if you want a review to prioritize :) [14:51] PR #11053: daemon: write formdata file parts to snaps dir [14:57] mvo: sure [16:14] * zyga-mbp slowly eods and looks at the pile of todos left over :) [16:14] oh well [16:14] I wish you all friends some rest [16:21] zyga-mbp: take care! [18:10] zyga: are here in the chat? [18:12] arsenique yes I'm around [18:12] Great [18:12] regarding the issue https://bugs.launchpad.net/snapd/+bug/1830024 [18:12] Bug #1830024: snapd mountinfo parser doesn't handle the special "\040(deleted)" suffix [18:12] nice to meet you btw [18:12] thank you, me too [18:13] i am trying to understand why we are avoiding using the linux mount package API? Isn't it something that is always there? [18:13] yes it is [18:13] I shared the thoughts we had at the time [18:14] you may note that snap-confine is not using most commonly libs either, we only used udev because that was mandatory (and it came from super ancient ubuntu-app-launch from click world) [18:14] Is it still a limitation. [18:14] ? [18:14] but mainly, IIRC, and my memory could be rusty now, we didn't want additional moving parts [18:14] where they move from one distro to another [18:15] and we didn't want the extra permissions libmount required [18:15] well, that's not a question to me [18:15] I retired as a snapd maintainer [18:15] Oh. Yeap, I understand. [18:15] I think the cross distro aspect is very true still [18:15] libmount may have a stable api [18:16] but I would argue that for parsing mountinfo without having one more moving element it is worth paying that price for [18:16] Are you implying that this API is not accessible in some distros? [18:16] no not that [18:16] it's just the version skew [18:16] (Sorry for stupid questions, by the way) [18:16] look at snapd from ubuntu 14.04+ to today [18:16] there are no stupid questions :) [18:16] those are good questions [18:16] snapd tries to be source compatible with a wide range of distros [18:17] and runtime compatible with even pretty old kernels [18:17] there were lots of compromises and gray hair involved to make things work [18:17] there are some things that also don't quite make sense [18:17] libmount has extras that are somewhat meaningless for containers like snap-confine is setting up [18:17] sounds scary and disturbing [18:18] like the extra mount options that are persisted in a file in run somewhere (my memory is rusty now) [18:18] I suspect using libmount surgically to replace some of the mount craze snap-confine has to do _might_ work well but it would be a nice project for someone with ample time on their hands [18:19] the advantage might be access to new mount APIs from the kernel (beyond the plain mount(2) [18:19] I think nowadays mborzecki would know who is maintaining that part, when I stopped working he took over but many people joined since [18:20] anyway, I hope this makes sense [18:20] we tried to be reasonable [18:20] I am not sure I fully understand. So, if I understand correctly libmount comes with price at runtime? Is it true if we only use this API to link with? [18:20] and all mistakes if I misremember are mine [18:20] I don't know, we didn't try to use it, we resorted to naked mount [18:20] we did look at using it for parsing [18:20] and bailed out early at the time [18:21] (Returning a favour. These are not mistakes, but decisions that where mandatory back then) [18:21] exactly my point, if we use it for parsing only, is it okay? [18:21] maybe not [18:21] again [18:21] libmount assumes a normal system [18:21] you'd have to look at what it does [18:22] the extra file for persisting mount flags is referenced [18:22] it may not be appropriate [18:22] you'd have to try it for real to know [18:22] I don't know libmount inside out to tell with authority [18:24] and my personal opinion on this is that kernel developers just don't understand how to make proper interfaces for userspace [18:24] I mean, how many crazy broken non standard custom text formats one has to parse to work there [18:24] Look I still feel like I don't get it. Let's say I isolate the call to the parsing function in a dedicated source. I don't use anything else, just the plain parsing function. Isn't it resolved on the linkage level? [18:24] this is so basic yet entirely broken [18:24] then you have to link to libmount [18:25] Hi mvo. You are right on time. [18:25] one sec [18:25] so [18:25] 0x0000000000000001 (NEEDED) Shared library: [libblkid.so.1] [18:25] 0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1] [18:25] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] [18:25] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] [18:25] 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] [18:25] 0x000000000000000e (SONAME) Library soname: [libmount.so.1] [18:25] I am making full of myself in front of zyga [18:25] this is from my sid system [18:25] libmount links with libblkid [18:26] so now you have one more dependency [18:26] and this has to be captured in selinux and apparmor profiles [18:26] those libs may have init functions [18:26] and indeed they all do [18:26] But if I use a specific function only in link with it only, why would linker bring all other "friends" to the party? [18:26] so before you run any code at all [18:26] just linking to them requires permissions and runs code [18:27] well, that's shared libraries 1-0-1 [18:27] that's how linking works [18:27] elf standard and all that fun [18:27] don't get me wrong [18:27] it may be well all doable [18:27] but [18:27] 1) you have to try [18:27] 2) you have to evaluate what the init code does in both [18:27] you have to take into account if you want to link them statically or dynamically from the host [18:28] and if they link dynamically, the analysis you do is only valid for that one host you did it for [18:28] I thought of static link, not dynamic. [18:28] in the future they may decide to read a new file [18:28] and then your SOL [18:28] okay [18:28] I understand the unwanted perks of dynamic linking [18:29] static linking works the same way for startup functions in practice, no _init elf callback but the static linker will do the equivalent [18:29] Therefore, I assumed that static linking will be the best. [18:29] you should also check if those are supported as static libraries [18:29] more and more parts of the stack refuse to allow static linking [18:29] I'm not saying they do, just that it's another part of the problem [18:30] then, having checked their init functions [18:30] and the source of the particular parse function [18:30] you want to see what happens on errors [18:30] and which files it references [18:30] _anywhere_ [18:30] and then make the call [18:30] I think that's all I can think of as factors right now [18:30] There is a great saying in russian for that: life is like in fairy tail - the further you get, the scarier it becomes. [18:30] hehe [18:30] especially old fairy tales ;) [18:32] Well, I think I will have to take it to the discussion of the elder wolfs here in the tribe. To see what they think of this. [18:32] Many thank. [18:32] good luck [18:32] *thanks [18:32] I think in general it's a good trend though [18:32] as old systems become less and less supported [18:32] but it's very tricky [18:32] for snap-confine in particular sadly [18:33] I understand. Thank you. [18:33] though I still think mount interfaces are broken [18:33] the new syscalls are good [18:33] but so much of the old interface is "well just do what others do" [18:33] which is why using \r in mount name explodes software still [18:33] Would you suggest me something in particular? [18:34] hmm? [18:34] I have to say my engineering senses are really hard on digesting code duplications. [18:34] I am a child on modern trends, like SOLID and clean coding. [18:34] linking is not the only solution [18:35] What would you suggest? [18:35] I'll just say: the fewer deps the better [18:35] reviewing the other implementation [18:35] copying the code [18:35] linking is like marriage [18:36] I know libmount is not left-pad [18:36] But copying the code, will bring us to the same pitfall. We are loosing the ability to get fixes and even are running out of sync. [18:36] but dependencies are quite evil [18:36] arsenique but you get that anyway! [18:36] when you static link [18:36] you link to libmount from xenial [18:36] there's no good solution here IMO [18:37] and the custom impl is not worse than other two (linking statically or dynamically) [18:37] What is xenial (sorry again for a stupid question)? [18:37] ubuntu 16.04 [18:37] when snapd is built it's not built with latest and greatest [18:37] Oh. :-) Ooopsi. Made full of myself again. [18:37] it's built on xenial [18:37] AFAIK [18:37] it could have changed [18:37] but you get *that* version [18:38] assuming it's fixed is good [18:38] but is it? [18:38] it's all a hard problem sadly [18:38] maybe the function you really want to use is later [18:38] I believe that today it's not 16.4, but 18.4 instead. But I need to check it. [18:38] I love deps but here, snap-confine, it's so special I would not recommend it [18:39] (when I say I love deps I mean I love good dependencies when that's the reasonable thing to do) [18:39] The wonders and perks of open source. :-| [18:39] I still think we as a industry have a left-pad problem [18:40] also if you link statically, you get quite a bit of extra size [18:40] unless you start to play tricks and recompile those deps with section-per-function [18:40] and do gc [18:40] but that's not default [18:40] I am not sure this is correct. [18:40] It depends on how you link. [18:40] I'm quite sure but I'm happy to be proven wrong [18:40] I know but this is what you will get without jumping through hoops of fire [18:41] Per my experience linker drops unused pieces of code and data. [18:41] At least I've seen it as my background is embedded [18:41] nope, not by default [18:41] yes [18:42] it's possible to do [18:42] but it's certainly not the default [18:42] I just had a look on my debian sid system and there's no libmoun.a in libmount-dev [18:42] Just a second, for standalone products like snapd????? [18:42] so you may want to check if the static library is offered across the distros at all [18:42] pardon? [18:43] anyway, no libmount.a in Debian [18:43] so also not in Ubuntu [18:43] I mean that it's not a package, where you keep code in binary for linkages in future. [18:43] most likely not in SUSE and Fedora [18:43] I mean that when I compile something like snapd I would link it with flags that throw away everything not needed. [18:44] https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vlasenko.pdf [18:44] have a look at this [18:44] this is basically as much as I know about this topic [18:44] this is quite old so maybe there's new development around [18:44] I surely will. [18:45] anyway, your first problem is you don't have libmount.a [18:45] Wow. Thank you so much. [18:45] and good luck trying to convince Debian to add it back [18:45] at some point [18:45] you will cherish the fact you can just fix that bug in snap-confine [18:45] with one patch [18:45] and one build [18:45] and that's it [18:45] :-D [18:46] Back to the metaphor about old fairy tails. [18:46] I should get out of my office [18:46] Look. You already helped me a lot. I hate to tell it, but I have to drop off. [18:46] good luck [18:46] btw, are you a snapd maintainer? [18:46] NO. [18:46] okay [18:46] I wish. [18:46] good luck :) [18:47] I'm sure the doors are open [18:47] I a total newbie in Canonical. [18:47] Thank you. [18:47] I'll be around if you want to chat some other day [18:47] cool, cheers! [18:47] Sure. [18:47] Cheers. [20:31] PR snapd#11082 opened: gadget: tweaks to DiskStructureDeviceTraits + expand test cases