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