| mborzecki | morning | 06:47 |
|---|---|---|
| mardy | mborzecki: hi! | 07:10 |
| mborzecki | hey | 07:11 |
| 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:03 |
| pstolowski | morning | 08:07 |
| zyga-mbp | good morning | 08:10 |
| 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:18 |
| 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> | 08:27 |
| mborzecki | mardy: maybe you can take a look ^^ | 09:02 |
| 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:43 |
| 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:48 |
| 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> | 09:58 |
| 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:44 |
| mborzecki | a simple PR ^^ | 11:50 |
| mup | PR snapd#11080 opened: builtin/interfaces: add shared memory interface <Created by mardy> <https://github.com/snapcore/snapd/pull/11080> | 12:54 |
| zyga-mbp | mardy NICE | 13:24 |
| zyga-mbp | mardy left one comment | 13:25 |
| mardy | zyga-mbp: thanks :-) | 13:37 |
| 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:39 |
| zyga-mbp | since the interface allows /dev/shm/$stuff | 13:40 |
| mardy | zyga-mbp: at the moment wildcards are not allowed, so you need to specify a precise name (or list of names) | 13:42 |
| 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:43 |
| zyga-mbp | *handling everthing | 13:44 |
| 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:49 | |
| zyga-mbp | and it's also nothing I disagree with technically | 13:50 |
| mardy | ok, I'll change it then | 13:50 |
| 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:29 |
| pstolowski | mborzecki: need any reviews? | 14:49 |
| 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:51 |
| pstolowski | mvo: sure | 14:57 |
| * 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:14 |
| pstolowski | zyga-mbp: take care! | 16:21 |
| arsenique | zyga: are here in the chat? | 18:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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. | 18:47 |
| 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> | 20:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!