| RAOF | Wimpress: Hey, re the MATE 1.24.1 SRU - it looks like mate-screensaver includes a UI change and feature addition? | 02:16 |
|---|---|---|
| slyon | Hey, could somebody please trigger this test for me? Apparently there was a problem with the autopkgtest infra for the amd64 machine (only): https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=amd64&package=swift&trigger=dnspython/2.0.0-1ubuntu2 | 09:56 |
| seb128 | slyon, triggered | 09:58 |
| slyon | thank you! | 09:59 |
| ahasenack | rbasak: hi, I'm "consulting" on a cifs-utils sru | 12:10 |
| ahasenack | rbalint: they want to backport a feature to bionic | 12:10 |
| ahasenack | rbalint: sorry | 12:10 |
| ahasenack | rbasak: thing is, that feature is only available in 5.x kernels, and bionic's is 4.15. But the bionic hwe kernel is recent enough | 12:10 |
| ahasenack | rbasak: cifs-utils won't break if running on an old (4.15) kernel, it's just this feature that won't be available and it will error if the user tries to use it | 12:11 |
| rbasak | As long as the behaviour and documentation is sane then I don't see that being a problem. | 12:29 |
| rbasak | From that perspective anyway. | 12:29 |
| rbasak | Adding a feature in an SRU is a separate matter of course. | 12:29 |
| rbasak | ahasenack: ^ sorry looks like I didn't see this ping for a while | 12:30 |
| ahasenack | rbasak: I think the feature is quite isolated, I was more wondering about the fact it would only be usable if you were running the hwe kernel | 12:45 |
| rbasak | ahasenack: I think that's OK provided that the behaviour for people not running the necessary kernel is sane | 12:47 |
| ahasenack | it is, they would only see if if they tried the new subcommand | 12:48 |
| ahasenack | it's like <command> <subcommand> [args] | 12:48 |
| ahasenack | <command> already exists, takes multiple <subcommands>, and the SRU is adding one new <subcommand> | 12:48 |
| ahasenack | which will fail with a sane error message if the kernel is too old for it | 12:48 |
| cpaelzer | Hi, I'm puzzled by the germinate handling of alternatives like Depends A|B and virtual-packages defined via provides | 12:58 |
| cpaelzer | it triggers a false positive as component mismatch | 12:58 |
| cpaelzer | I ahve collected the state of affairs about it here https://paste.ubuntu.com/p/HxCFjhxSWV/ as it is way too much to throw everything into IRC | 12:58 |
| cpaelzer | cjwatson: ^^ I was told by Laney that you might be a good candidate to help me undertstand it - therefore a gentle ping ^^ | 13:00 |
| xnox | cpaelzer: postfix is in main on 6 out 7 architectures. | 13:00 |
| xnox | cpaelzer: on the one and only, our most favourite architecture, it needs to pick something else. | 13:01 |
| cjwatson | cpaelzer: send me mail if you want me to look at it - it would take a while and I'll forget an IRC ping | 13:01 |
| cpaelzer | cjwatson: sure, thanks for the offer | 13:01 |
| cpaelzer | xnox: isn't that what lsb-invalid-mta should solve? | 13:02 |
| * xnox looks | 13:02 | |
| cpaelzer | maybe we need invalid-default-mta as well | 13:02 |
| xnox | cpaelzer: probably, because normally, germinate from "A | B" it picks A and expands. | 13:03 |
| cjwatson | cpaelzer: no promises - germinate is not really a priority for me at the moment | 13:03 |
| cpaelzer | I understand | 13:03 |
| cpaelzer | xnox: yes that is what I expected | 13:03 |
| cpaelzer | thanks for the hint xnox I'll try if I can lock this down to i386 | 13:03 |
| xnox | cpaelzer: i think we could try seeding '* lsb-invalid-mta [i386]' before logcheck line. | 13:03 |
| cjwatson | in general germinate looks to see if one of the alternatives is already explicitly listed in the seed it's looking at, or in the expansion of an inner seed, and if so uses that; otherwise picks the first that exists | 13:04 |
| cjwatson | xnox: doesn't need to be before | 13:04 |
| cpaelzer | yeah I tried ordering | 13:04 |
| xnox | cpaelzer: that should cause germinate to think that "A | B" is satisfied via B. | 13:04 |
| cjwatson | all the entries in a seed are "planted" first and then expanded after that | 13:04 |
| xnox | yes, i keep forgetting that germinate is multi-pass like LaTeX. | 13:04 |
| cjwatson | also like apt, more relevantly :) | 13:04 |
| xnox | ah | 13:05 |
| xnox | =) | 13:05 |
| xnox | cpaelzer: shall we try adding '* lsb-invalid-mta [i386]' and see what happens? | 13:05 |
| ahasenack | tjaalton: hi, what do you think about https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/thread/JC3N3DBSMHZSA66IPLGAMBSXLCTYXWJR/ ? We have this bug in ubuntu, and I suppose debian too: https://bugs.launchpad.net/ubuntu/+source/realmd/+bug/1880157 | 13:05 |
| ubottu | Launchpad bug 1880157 in realmd (Ubuntu) "realmd generates wrong 'services' section in sssd.conf during joining to AD" [Low,In progress] | 13:05 |
| cpaelzer | xnox: it surely was the right hint --arch amd64 makes it behave as one would expect | 13:09 |
| cpaelzer | I wonder if (i386 being mostly gone) that should be set for the germinate run that we do for the archive? | 13:09 |
| cpaelzer | yes https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.groovy/_germinate_output is i386 as well | 13:10 |
| cpaelzer | That explains the zillion of "Unkown ..." log entries that I've seen | 13:11 |
| cpaelzer | thanks xnox I can go down that route for a bit to see how far I can get | 13:11 |
| Laney | AH | 13:12 |
| Laney | cpaelzer: I think a good improvement to germinate would be to add the arch to that "Unknown" output | 13:12 |
| Laney | I think that would have made it waaaaaaaaaaaaaaayyyyy more obvious | 13:12 |
| cpaelzer | true | 13:13 |
| Laney | if you're looking to make improvements :-) | 13:13 |
| Laney | also if that could be on component-mismatches too somehow, that would have made the gnome-software thing much more obvious | 13:14 |
| cpaelzer | can't we just cahnge that it runs for amd64 | 13:15 |
| cpaelzer | IMHO i386 is no more what we should base our dependency resolution on | 13:15 |
| cpaelzer | I'll prep a mail to ubuntu-devel summing up what I've found askig to run it against amd64 if that really turns out to look better in my tests | 13:16 |
| cjwatson | Uh, I thought it did run for amd64 on >=focal | 13:17 |
| Laney | Well, it would probably be more correct here, yes | 13:17 |
| Laney | But component-mismatches germinates for *all* arches so it wouldn't actually help | 13:17 |
| cjwatson | Oh, you mean germinate's own defaults as opposed to the run on people.c.c | 13:17 |
| cpaelzer | yes | 13:17 |
| cjwatson | It would certainly be possible to change that - file a bug please? | 13:17 |
| cpaelzer | umm no | 13:17 |
| cpaelzer | I meant whatever drives https://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.groovy/_germinate_output | 13:18 |
| cjwatson | Oh | 13:18 |
| cpaelzer | which is people.c.c | 13:18 |
| cjwatson | The problem is that that has this code: | 13:18 |
| cjwatson | https://paste.ubuntu.com/p/DbF2R9hK82/ | 13:18 |
| cjwatson | Except that -a i386 is already the default, so that's completely ineffective | 13:18 |
| cpaelzer | correct | 13:18 |
| cpaelzer | and there I'd want -a amd64 | 13:18 |
| cjwatson | I'll fix that now | 13:18 |
| cpaelzer | ok, that safes me a mail to ubuntu-devel then and will resolve a bunch of false positives we looked at | 13:19 |
| Laney | (My point still stands) | 13:19 |
| cjwatson | Yes | 13:20 |
| cjwatson | Fixed the sample run anyway | 13:20 |
| Laney | For component-mismatches looking at https://people.canonical.com/~ubuntu-archive/extra-germinate-output would likely be more helpful | 13:20 |
| Laney | I just created that symlink, so you wouldn't have been able to find it before | 13:21 |
| cpaelzer | Laney: yeah here I'd clearly have seen that just i386 is the one it is dying on | 13:22 |
| Laney | and in there is where having the arch available when germinate emits that warning would save you having to scroll up and down | 13:22 |
| cpaelzer | like https://paste.ubuntu.com/p/hNMRVByrTy/ | 13:23 |
| Laney | right, it's possible to work it out from that but a bit cryptic still IMO | 13:23 |
| Laney | if you put 'Germinating for' in your grep, it should be even more clear | 13:24 |
| cpaelzer | indeed | 13:25 |
| Laney | waveform: Wimpress: xnox: https://lists.ubuntu.com/archives/ubuntu-release/2020-September/005086.html woot! | 13:30 |
| waveform | Laney, yay! I'll get on the MIRs | 13:31 |
| Odd_Bloke | xnox: slyon: So it looks like we have a path forward for a backportable fix for the dynamic config generation issue; do we think that this is also the path going forward, or do we still need to be pursuing the two-phase boot ideas? | 13:40 |
| tjaalton | ahasenack: yeah debian is affected as well.. but I'm not the realmd maintainer there ;) | 13:47 |
| ahasenack | tjaalton: sure, was just wondering how you felt about an sssd with no services= line | 13:47 |
| tjaalton | well I've dropped it from the freeipa setup script | 13:47 |
| ahasenack | cool | 13:47 |
| tjaalton | but if what james says on sssd-users@ is right, there could be an issue with the socket activation as shipped by debian/ubuntu | 13:48 |
| ahasenack | do you know him? He is not RH, is he? | 13:49 |
| ahasenack | maybe the issue is it could take a while to start the service (ms), and that's enough to have something get flaky? | 13:49 |
| tjaalton | don't think so | 13:50 |
| tjaalton | that he is | 13:50 |
| ahasenack | tjaalton: we use the upstream systemd service files, right? | 13:53 |
| tjaalton | I think so | 13:53 |
| tjaalton | yep | 13:54 |
| cpaelzer | Laney: I have opened a MP for germinate and set you as reviewer (works fine in local runs to indicate the arch of these warnings) | 14:20 |
| ahasenack | doko: hi, where is your latest ftbfs report for groovy? | 14:21 |
| doko | hmm, didn't I announce that on u-d? | 14:22 |
| Laney | cpaelzer: Thanks, I'll try to look today, but I'm not sure if cjwatson considers me a competent reviewer for germinate or would prefer to do it :-) | 14:22 |
| doko | https://people.canonical.com/~doko/ftbfs-report/test-rebuild-20200728-groovy-groovy.html | 14:22 |
| cpaelzer | added a second review slot for cjwatson | 14:23 |
| ahasenack | doko: maybe, I'm lazy :) | 14:23 |
| ahasenack | thanks | 14:23 |
| cpaelzer | Laney: cjwatson: xnox: now that we have the sample run on amd64 as one woudl expect and down the road the warnings state the architecture I'm still missing how to best avoid the false positive | 14:27 |
| cpaelzer | due to default-mta being from postfix whicih isn't on i386 | 14:28 |
| cpaelzer | could that be doen via extending the lsb-invalid-mta (https://git.launchpad.net/~paelzer/ubuntu/+source/lsb/commit/?id=777bb89a) or what else would be the best way | 14:28 |
| cpaelzer | I mean after all, even once it falls through "default-mta | mail-transport-agent" I'd expect "mail-transport-agent" to resolve to "lsb-invalid-mta" which already is in main | 14:34 |
| Laney | Don't think that can be it, because it already had mail-transport-agent | 14:34 |
| cpaelzer | but it isn't and instead picks a random element of the providers for that virtual package | 14:34 |
| Laney | Indeed | 14:34 |
| cpaelzer | If there is no immediate hint I can sum the things of today up and leave that in cjwatson inbox for once he has time for it (or would a bug be better?) | 14:35 |
| Laney | cpaelzer: One possible hint | 14:40 |
| Laney | Resolving supported-sysadmin-server dependencies ... | 14:40 |
| Laney | * Chose postfix out of default-mta to satisfy logcheck | 14:40 |
| cpaelzer | Laney: from where is that? | 14:40 |
| Laney | checksecurity in supported-sysadmin-server is pulling in logcheck too, so perhaps the invalid-mta thing needs to be there as well, or in a common ancestor | 14:40 |
| Laney | from https://people.canonical.com/~ubuntu-archive/extra-germinate-output | 14:40 |
| cpaelzer | I just found that ordering seems to be involved, if I put lsb-invalid-mta in front of logcheck it works | 14:41 |
| cpaelzer | and I'd have thought ordering should not be important | 14:41 |
| cpaelzer | Laney: yeah the reverse-or-random nature plus the recent carry over from server-ship to supported-sysadmin-server made this show up | 14:53 |
| cpaelzer | Laney: checksecurity is earlier now than the hint in supproted-misc-server that dragged in lsb-invalid-mta | 14:54 |
| cpaelzer | moving that over resolves the false positive | 14:54 |
| cpaelzer | so ordering is important | 14:54 |
| cpaelzer | :-/ | 14:54 |
| Laney | I'm not sure if that's exactly right, but probably moving checksecurity to misc would be a solution | 14:55 |
| cpaelzer | well, I did it the other way around and it works | 14:56 |
| cpaelzer | (moved lsb-invalid-mta) | 14:56 |
| Laney | don't see that commit and don't understand why that would work, but cool! | 15:09 |
| Laney | TFW you run `date` in en_US | 15:46 |
| Laney | 03:45, that makes no sense... oh | 15:46 |
| seb128 | LocutusOfBorg, hey, just as a fyi, I synced gstreamer yesterday so you should be able to upload your merges now | 16:03 |
| LocutusOfBorg | seb128, I'm doing the merge right now, SOOOOOOOOO painful | 16:16 |
| LocutusOfBorg | they switched to meson, and my meson foo is nil | 16:16 |
| seb128 | :( | 16:16 |
| rbasak | cpaelzer, sergiodj: in bug 1761096, did you ever find out why >=Bionic are unaffected, or did you decide it wasn't worth investigating further? | 16:29 |
| ubottu | bug 1761096 in squid (Ubuntu Xenial) "dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed" [High,Confirmed] https://launchpad.net/bugs/1761096 | 16:29 |
| rbasak | Oh - is the change you're proposing already made there? | 16:31 |
| rbasak | I don't see it in Bionic but it is in Focal. So I guess my question is for Bionic only. | 16:32 |
| rbasak | Sorry for the confusion. Let me restate: | 16:32 |
| rbasak | cpaelzer, sergiodj: in bug 1761096, did you ever find out why Bionic are unaffected, or did you decide it wasn't worth investigating further? | 16:32 |
| ubottu | bug 1761096 in squid (Ubuntu Xenial) "dnsmasq starts with error on Ubuntu Xenial amd64 when squid installed" [High,Confirmed] https://launchpad.net/bugs/1761096 | 16:32 |
| rbasak | *is* | 16:32 |
| sergiodj | rbasak: we could not find exactly why Bionic is not affected. my hypothesis is that between Xenial and Bionic there was a fix on systemd which addressed this issue, but I could not pinpoint exactly what was done | 16:38 |
| rbasak | OK thanks | 16:39 |
| sergiodj | arguably, the best scenario would be to backport this fix to Xenial's systemd, but since we had already spent a non-trivial amount of time investigating this (without finding anything concrete on systemd's side), I opted for the second best thing to do, which is to use --no-block to workaround this bug | 16:39 |
| rbasak | I think that's the right decision but we should document what and why. I can do that. | 16:40 |
| rbasak | Just in case someone later finds themselves affected on Bionic for example | 16:40 |
| sergiodj | thanks, robie | 16:40 |
| rbasak | sergiodj: mind if I copy and paste the above? | 16:41 |
| sergiodj | rbasak: not at all | 16:41 |
| rbasak | Thank you! | 16:42 |
| sergiodj | rbasak: thank *you* for reviewing the SRU :) | 16:43 |
| === jdstrand_ is now known as jdstrand | ||
| === ahayzen_ is now known as ahayzen | ||
| ahasenack | do we have a pattern somewhere for all the incompatible sphinx changes that landed with 3.2.1 in groovy? | 21:11 |
| ahasenack | I fix one and another one bites me right after, I'm on the third patch now | 21:12 |
| xnox | Odd_Bloke: correct, just straight up netplan.io change only. without any changes to cloud-init or systemd or default.target | 22:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!