| mborzecki | morning | 05:26 |
|---|---|---|
| pstolowski | morning | 06:19 |
| mborzecki | pstolowski: hey | 06:21 |
| mborzecki | pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/10567 ? | 06:22 |
| pstolowski | sure | 06:30 |
| mborzecki | pstolowski: thanks! | 06:41 |
| mborzecki | hmm i was checking something with refresh and saw this in snap refresh --time: `next: yesterday at 19:27 CEST` | 06:41 |
| mborzecki | something isn't right there | 06:41 |
| pstolowski | mborzecki: that's sounds like the issue i'm investigating | 06:42 |
| mborzecki | pstolowski: do you want anything? logs? state? | 06:43 |
| pstolowski | mborzecki: yes, also run snapd with SNAPD_DEBUG till auto refresh logic kicks in. I got this on the bug report but it won't hurt to collect more | 06:44 |
| mborzecki | pstolowski: https://paste.ubuntu.com/p/9JgDktNKvg/ | 06:49 |
| mvo | good morning mborzecki and pstolowski | 06:51 |
| mborzecki | pstolowski: btw. i'm thinkign that the refresh was scheduled for 5:30pm yday, but then i suspended the system before that so that the refresh didn't run, that's why it's showing yesterday in next refresh time, but it should have been triggered during the usual 5 minute ensure cycle, shouldn't it? | 06:51 |
| mborzecki | mvo: hey | 06:51 |
| pstolowski | hey mvo | 06:51 |
| * _moep_ waves… | 06:53 | |
| pstolowski | mborzecki: reviewed | 06:56 |
| zyga | goood morning :) | 07:12 |
| mborzecki | mvo: can you take a look at https://github.com/snapcore/snapd/pull/10540 ? | 07:14 |
| zyga | mborzecki, how about weakly linked symbol instead? | 07:17 |
| zyga | no dlopen hassle | 07:17 |
| zyga | same semantics | 07:17 |
| zyga | you can just check if it's null | 07:17 |
| zyga | we link to libudev dynamically anyway, because it is required | 07:18 |
| mborzecki | zyga: hm that might work | 07:19 |
| zyga | mborzecki, give it a try :) | 07:20 |
| zyga | __attribute__((weak)) IIRC | 07:20 |
| pstolowski | mborzecki: is next-refresh still bogus on your system? | 07:24 |
| pstolowski | hey zyga | 07:24 |
| zyga | hey pstolowski :) | 07:24 |
| mborzecki | pstolowski: no it's correct now, it ran at 8:42 and calculated next time to be 2021-07-28T15:08:04+02:00, which is reported by snap refresh --time too | 07:25 |
| mborzecki | so right at the time i was collecting the logs | 07:26 |
| pstolowski | mborzecki: right. and before you restarted snapd was it running long enough for ensure to kick in right? | 07:32 |
| zyga | pstolowski, maybe suspend and stale time or something? | 07:32 |
| mborzecki | pstolowski: yeah, i'm around since ~730 so it shoudl have more than enough time to execute ensure a couple of times | 07:33 |
| pstolowski | zyga: could be, although we have a vaguely similar issue from the field where suspend isn't the case | 07:33 |
| zyga | hmm | 07:34 |
| zyga | would it happen if the state lock was held for a long time? | 07:34 |
| zyga | I guess so | 07:34 |
| pstolowski | yes, probably, but no evidence of this atm | 07:36 |
| mborzecki | mvo: pstolowski: https://paste.ubuntu.com/p/pWFnT6yKfK/ snap changes | 13:10 |
| mvo | mborzecki: \o/ | 13:10 |
| ijohnson[m] | zyga: around by any chance ? | 14:11 |
| ijohnson[m] | wondering if you have any drive by thoughts on https://forum.snapcraft.io/t/egl-using-snaps-on-impish-seem-to-be-broken-when-using-the-nvidia-proprietary-driver/25715 | 14:12 |
| ijohnson[m] | seems pretty problematic for our nvidia story | 14:12 |
| * cachio afk | 14:51 | |
| zyga-mbp | ijohnson[m] re | 15:20 |
| zyga-mbp | ijohnson[m] yes | 15:20 |
| zyga-mbp | looking | 15:20 |
| zyga-mbp | ijohnson[m] can we just add the new .so files and keep the current setup going? | 15:21 |
| ijohnson[m] | problem is new .so files need libc6 that is not compatible with the base snap | 15:21 |
| zyga-mbp | ohhh | 15:22 |
| zyga-mbp | wait | 15:22 |
| zyga-mbp | wait | 15:22 |
| zyga-mbp | is it? | 15:22 |
| zyga-mbp | ijohnson[m] all the .so files come from nv | 15:22 |
| zyga-mbp | we have no way to rebuild them | 15:22 |
| zyga-mbp | and traditionally nv has been using very old libc as build base | 15:23 |
| zyga-mbp | has that changed? | 15:23 |
| ijohnson[m] | I dunno | 15:23 |
| ijohnson[m] | this is on impish, so something could have changed | 15:23 |
| zyga-mbp | did you check that you need new libc or is that something you've deduced out of the output | 15:23 |
| zyga-mbp | because seeing ldd there is not conclusive | 15:23 |
| ijohnson[m] | although I'm not sure that specific lib that laney saw is nvidia specific | 15:23 |
| zyga-mbp | ijohnson[m] which specific one? | 15:24 |
| zyga-mbp | libgnv0? | 15:24 |
| zyga-mbp | *libglvnd0 | 15:24 |
| ijohnson[m] | libEGL.so.1 | 15:24 |
| zyga-mbp | no, that's not specific | 15:25 |
| zyga-mbp | it's just a version from nvidia that they provide | 15:25 |
| ijohnson[m] | zyga-mbp: right but if that library has a dependency on a new libc, and a snap depends on that library, then doesn't the problem still exist ? | 15:44 |
| zyga-mbp | ijohnson[m] sure but I want to confirm that the dependency is real | 15:44 |
| zyga-mbp | is the old libc from (whatever the base is) able to resolve all the symbols in that set of nv libs? | 15:44 |
| zyga-mbp | ijohnson[m] I'll be rebooting for updates in 5 minutes | 15:45 |
| ijohnson[m] | zyga-mbp: I don't know, I would need to look, but that's a good point | 15:45 |
| ijohnson[m] | it may be an artificial dependency | 15:45 |
| zyga-mbp | it's just resolved with host libc | 15:46 |
| zyga-mbp | that's harmless | 15:46 |
| ijohnson[m] | well it's not harmless cause snaps don't work on impish due to this | 15:46 |
| zyga-mbp | wait | 15:47 |
| zyga-mbp | that's backwards | 15:47 |
| zyga-mbp | the problem is new nvidia libs | 15:47 |
| ijohnson[m] | yeah let me ask laney to confirm if the new nvidia libs also need new libc6 | 15:50 |
| ijohnson[m] | cause that would be a larger problem | 15:50 |
| ijohnson[m] | yeah it seems libe libEGL.so.1 does indeed depend on symbols from glibc 2.33, it uses fstat64 | 16:32 |
| ijohnson[m] | this could be a large problem :-/ | 16:33 |
| zyga-mbp | ijohnson[m] ouch | 20:14 |
| zyga-mbp | ijohnson[m] what's the affected base? | 20:14 |
| ijohnson[m] | zyga-mbp: core18 I think, but core20 would also be affected, the host OS is 21.10 (dev) | 20:15 |
| zyga-mbp | hmm | 20:15 |
| zyga-mbp | right | 20:15 |
| zyga-mbp | but | 20:15 |
| zyga-mbp | fstat64 is ancient | 20:15 |
| zyga-mbp | I'm sure it's in older libc | 20:15 |
| zyga-mbp | perhaps the symbol version is different | 20:15 |
| ijohnson[m] | Hmm, why is it marked as being necessary from glibc 2.33 | 20:16 |
| zyga-mbp | but the syscall is not by any chance new | 20:16 |
| zyga-mbp | glibc is famously versioning symbols | 20:16 |
| zyga-mbp | so it's not foo | 20:16 |
| zyga-mbp | it's foo@1.23 | 20:16 |
| ijohnson[m] | ah right | 20:16 |
| zyga-mbp | anyway, I'm sure it's solvable | 20:16 |
| zyga-mbp | may require something mildly hacky | 20:16 |
| ijohnson[m] | well as @laney pointed out that particular lib could be rebuilt with an older base distro, but that's not something that snapd can do, that has to be done to the archive and/or the host system | 20:17 |
| zyga-mbp | is that libEGL.so? | 20:17 |
| zyga-mbp | if that's the nv version then it cannot be rebuilt | 20:17 |
| zyga-mbp | remember that nvidia provides several interfaces, some have a "common" name | 20:18 |
| zyga-mbp | like libEGL perhaps | 20:18 |
| zyga-mbp | there are many files with that name, | 20:18 |
| zyga-mbp | I need to run | 20:18 |
| ijohnson[m] | yes that's from the archive, I think that can be rebuilt easily, but the nv specific libs yes you're right I don't think we can re-compile those | 20:18 |
| zyga-mbp | rain is coming and I'm only here to close windows | 20:18 |
| ijohnson[m] | thanks for your insight! | 20:18 |
| ijohnson[m] | ttyl | 20:18 |
| zyga-mbp | those get dpkg-diverted IIRC | 20:18 |
| zyga-mbp | or something equivalent | 20:18 |
| zyga-mbp | I'm running impish | 20:18 |
| zyga-mbp | _and_ i have nv on that laptop | 20:19 |
| zyga-mbp | what's the snap name that lanely mentioned? | 20:19 |
| ijohnson[m] | ah, you should try to see if flokk-contacts works on your machine I assume it will not | 20:19 |
| zyga-mbp | thanks | 20:19 |
| zyga-mbp | I'll try | 20:19 |
| zyga-mbp | gotta close other windows | 20:19 |
| zyga-mbp | looks like nightly thunderstorm | 20:19 |
| zyga-mbp | o/ | 20:19 |
| === diddledan is now known as diddledani | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!