| === mirespace_ is now known as mirespace | ||
| ricotz | LocutusOfBorg, hi :) would it be possible to sync wine 6.0.2~repack-3 ? | 15:15 |
|---|---|---|
| LocutusOfBorg | ricotz, I will do it yes | 15:15 |
| LocutusOfBorg | after wine-development clears | 15:15 |
| ricotz | LocutusOfBorg, ack :) | 15:15 |
| LocutusOfBorg | I still don't get why wine development has no openldap fix, while wine has it | 15:21 |
| === genii-core is now known as genii | ||
| LocutusOfBorg | oh its a debian specific patch, nice | 15:21 |
| === mfo_ is now known as mfo | ||
| ahasenack | hi, I'm looking if there is a pattern for this. I have a postinst that might fail, but the service will keep running, but with a different config. I can let it fail, echo some helpful message on how to fix it, or don't fail, but still echo a message that is should be fixed | 18:46 |
| ahasenack | I'm wondering about release upgrades. I thought to use option (b) (not fail, but still echo messages) in the release upgrade case, and (a) if it's a normal upgrade | 18:46 |
| ahasenack | but I fear both cases might have the message ignored | 18:47 |
| ahasenack | just wondering out loud | 18:47 |
| ahasenack | if somebody has ever made a postinst behave differently if it's running under a bigger release upgrade or not | 18:47 |
| rbasak | ahasenack: what's the reason it'd fail? I've heard one argument that it's bad to silently succeed if we know it's broken. | 18:53 |
| ahasenack | rbasak: a bug. It's the nfs configuration script. If it fails, what happens is that local customizations done by the user are not reflected in the new config file, which will be using the defaults of a fresh install in that case | 18:54 |
| ahasenack | the service will be running, but not with the custom options that were being used before | 18:54 |
| ahasenack | emphasis on custom: the migration will not kick in if there were no changes to the default config | 18:55 |
| rbasak | It sounds bad to not fail the upgrade in that case | 18:55 |
| ahasenack | I can see that, yes | 18:55 |
| rbasak | I wonder if a preinst check might help - if it's predictable in advanvce. | 18:55 |
| rbasak | That might help limit the damage perhaps? This'd need testing. | 18:55 |
| ahasenack | but I also wonder about a release upgrade, where failing in the middle of it has worse consequences | 18:55 |
| rbasak | The UX around this kind of case has always been poor :-/ | 18:56 |
| ahasenack | i.e., it's easier to fix this particular config post upgrade, then to recover from a upgrade that failed somewhere in the middle | 18:56 |
| ahasenack | but on a release upgrade the user also won't be seeing these messages (hey, heads up, your config wasn't migrated) | 18:56 |
| rbasak | MySQL packaging disables the daemon but also disables a debconf critical prompt in some cases like this | 18:56 |
| rbasak | *displays a debconf critical prompt | 18:57 |
| ahasenack | hm, should I go with the debconf critical prompt I wonder | 18:58 |
| ahasenack | "hey, I failed to convert your configuration, please see <foo>. Your service is running, but with the defaults" | 18:58 |
| rbasak | It might also be better not to start the daemon at all if you know you couldn't migrate the configuration | 18:58 |
| rbasak | Than to run it but wrong | 18:58 |
| rbasak | (which is why MySQL packaging also disables the daemon in this cae) | 18:58 |
| ahasenack | it's multiple daemons | 18:58 |
| rbasak | Sounds like fun | 18:59 |
| ahasenack | and we know mysql still apports dozens of postinst failures bugs | 18:59 |
| ahasenack | even with this care | 18:59 |
| rbasak | We didn't use it for many cases | 19:02 |
| rbasak | Looking at it now, it's only for the downgrade case (or the unsupported "crossgrade" from MariaDB). There we don't expect the daemon to be able to start at all. | 19:02 |
| rbasak | And attempting to start it may damage data | 19:03 |
| ahasenack | I don't expect data loss | 19:05 |
| ahasenack | at most an unreachable nfs server, if options like custom/fixed ports were used | 19:05 |
| ahasenack | but these are obviously the ones I'm testing a lot | 19:05 |
| ahasenack | still, stuff happens | 19:05 |
| ahasenack | I miss some sort of "notification central" for non-desktop | 19:06 |
| rbasak | "notification central"> I wonder if update-motd could be used for that kind of thing | 19:27 |
| rbasak | It'd need packages to be able to supply some kind of "I'm broken" status | 19:27 |
| ahasenack | yeah, with a limit of course, and "... run get-notifications for the remaining messages" or something like that | 19:28 |
| rbasak | That isn't quite as drastic as "dpkg will refuse to do anything now" | 19:28 |
| ahasenack | I mean, local mail used to be that | 19:28 |
| rbasak | Also things like "files exist in /etc with .dpkg-new or .dpkg-old" could trigger such notices | 19:28 |
| ahasenack | "You have 2 new mails" | 19:29 |
| ahasenack | just bring that to the XXI century | 19:29 |
| rbasak | I'd like it to have a feedback loop - so if the underlying reason goes away before the user notices, then so does the notice. | 19:29 |
| ahasenack | yes, I remember that idea of yours for the .dpkg-* files | 19:29 |
| ahasenack | I think it can be expanded | 19:29 |
| ahasenack | and without becoming annoying | 19:30 |
| melodie | hello | 20:07 |
| melodie | did someone notice that the default swapfile created during install can't work when the fs type chosen is BTRFS? | 20:08 |
| melodie | when having btrfs it needs to be created with specific command lines https://superuser.com/questions/539287/swapon-failed-invalid-argument-on-a-linux-system-with-btrfs-filesystem | 20:09 |
| melodie | should I report a bug? | 20:10 |
| melodie | (I had also followed here : https://btrfs.readthedocs.io/en/latest/Swapfile.html ) | 20:11 |
| ahasenack | melodie: is this on jammy, or existing releases? | 20:17 |
| melodie | hi ahasenack sorry, forgot to mention : in focal | 20:22 |
| ahasenack | have you tried the version released last week? 20.04.4? | 20:23 |
| ahasenack | it might be fixed already | 20:23 |
| melodie | ahasenack, not yet, why have you seen a bug report related to this issue? | 20:23 |
| melodie | I can try a bit later, I have a rebuild ongoing (my remix) which I will test in Virtualbox once done. | 20:24 |
| ahasenack | no, but the topic is not new to me, so it's possible it was addressed already | 20:24 |
| melodie | ahasenack, I will test, thank you | 20:24 |
| ahasenack | thx for testing | 20:24 |
| ahasenack | http://releases.ubuntu.com/focal/ | 20:25 |
| melodie | with pleasure, | 20:25 |
| mwhudson | hmm | 22:01 |
| mwhudson | sarnold: can you think of some way we can use your archive searching abilities to find packages that explicitly list libssl1.1 in Depends in debian/control? | 22:01 |
| * mwhudson sideyes libpython2.7-stdlib | 22:03 | |
| cjwatson | mwhudson: isn't that just grep-dctrl? | 22:08 |
| sarnold | heh, is it? I don't think I've had much success with that | 22:09 |
| cjwatson | I use grep-dctrl all the time, it's great | 22:09 |
| cjwatson | assuming you have the relevant Packages files, but that's easy enough | 22:10 |
| mwhudson | cjwatson: no i need to do it on the source packages | 22:11 |
| mwhudson | cjwatson: i want to find packages that have libssl1.1 in depends from things other than dpkg-shlibdeps | 22:11 |
| mwhudson | because they need to stop doing that | 22:14 |
| sarnold | mwhudson: okay I kicked something I hope will do the trick :) | 22:18 |
| dbungert | codesearch with path:debian/control? | 22:18 |
| mwhudson | dbungert: yeah probably good enough | 22:47 |
| sarnold | mwhudson: https://termbin.com/38rx | 22:54 |
| mwhudson | oh that's not so bad | 22:55 |
| sarnold | way smaller than I expected, heh | 22:58 |
| sarnold | is there a lintian for these things? | 22:58 |
| === genii is now known as genii-core | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!