| === sem2peie- is now known as sem2peie | ||
| === dosaboy_ is now known as dosaboy | ||
| === tarzeau_ is now known as tarzeau | ||
| paravoid | hey - debian maintainer here, not super accustomed to how ubuntu does things | 15:17 |
|---|---|---|
| paravoid | I maintain gdnsd among other things; I've uploaded 3.5.x versions in Debian unstable, which have migrated to bullseye | 15:17 |
| paravoid | they have not migrated to hirsute, because autopkgtests fail | 15:18 |
| paravoid | they did not fail on Debian, just Ubuntu | 15:18 |
| paravoid | I suspect that's because gdnsd, as a DNS server, listens on port 53 (and listens to INADDR_ANY:53, cf. LP #1764327) | 15:18 |
| ubottu | Launchpad bug 1764327 in gdnsd (Ubuntu) "gdnsd fails to start, as it tries to listen to [::]:53" [High,Triaged] https://launchpad.net/bugs/1764327 | 15:18 |
| paravoid | and I suspect that in the Ubuntu autopkgtest runners, that port is occupied by something like systemd-resolved perhaps | 15:19 |
| rbasak | Thank you for checking in with us! | 15:20 |
| paravoid | I could change the autopkgtest config to listen to 5353 or something, but honestly that feels wrong (because what we /really/ want from a CI perspective is to test whether gdnsd works as a DNS server listening on port 53 :) | 15:20 |
| rbasak | I'm not sure what to suggest. Do you have a general plan on how to avoid conflict with systemd-resolved on Debian? | 15:21 |
| === mfo is now known as Guest76149 | ||
| paravoid | plus I don't think there are any guarantees anywhere about which ports are to be left open in autopkgtests? | 15:21 |
| paravoid | I've been in touch with upstream and they pushed this: https://github.com/gdnsd/gdnsd/commit/6958918936d528d3daa6366036fbf44a02cbb234 | 15:22 |
| paravoid | to effectively deprecate the default listen on inaddr-any from some future version | 15:22 |
| paravoid | but that would not solve autopkgtests really, as we'd really want to listen to 53 in some interface as to be able to test that the server functions | 15:23 |
| rbasak | This is on the edge of my knowledge. Since normally you'd expect to listen on a public interface, would you consider it acceptable to autopkgtest listening on port 53 but on a different address? In which case, could you use eg. 127.0.0.2? | 15:24 |
| === mf- is now known as mfo | ||
| rbasak | Although according to the bug 127.0.0.1 should also be free, actually. | 15:26 |
| paravoid | the bug is not about autopkgtest | 15:26 |
| rbasak | Sure, but it explains systemd-resolved's behaviour | 15:26 |
| paravoid | I think the question is really... what is the config in Ubuntu's autopkgtest runners under isolation-container | 15:26 |
| paravoid | and what should it be :) | 15:26 |
| rbasak | I assume that you can expect 127.0.0.53:53 to be occupied :) | 15:27 |
| paravoid | yeah - gdnsd used to use 127.0.0.53 before systemd started using it (cf. https://github.com/gdnsd/gdnsd/issues/128) | 15:28 |
| paravoid | so this has been quite the whack-a-mole ;) | 15:28 |
| paravoid | the "easy" fix would be to add a specific config in autopkgtests that adds a config with listen => 127.0.0.$N, and change all the tests to do e.g. dig @127.0.0.$N | 15:34 |
| paravoid | but that feels... wrong? it would test with the non-default configuration | 15:34 |
| rbasak | It seems to me that the pain here is because the non-default configuration needs fixing, and until then a workaround is unavoidable. | 15:35 |
| rbasak | It seems to me that the pain here is because the *default* configuration needs fixing, and until then a workaround is unavoidable. | 15:35 |
| paravoid | changing the default configuration is not an option right now, that would break setups that rely on it, that suddenly they would find themselves listening only on localhost on upgrades | 15:35 |
| rbasak | Sure, I understand that. | 15:36 |
| rbasak | So in the meantime, I think the workaround in autopkgtest is unavoidable? | 15:36 |
| paravoid | it's arguably not wrong either | 15:36 |
| paravoid | like when you install nginx or apache, you expect them to listen to inaddr_any:80 | 15:36 |
| paravoid | well ok, not necessarily, but lots of daemons do that | 15:36 |
| rbasak | From a Debian vs. Ubuntu perspective, there are some choices. You could apply the workaround to Debian and we could sync it to Ubuntu, or you could add conditional behaviour to Debian using dpkg-vendor, or we could apply a delta in Ubuntu (but that would then have to be maintained). | 15:36 |
| rbasak | like when you install nginx or apache, you expect them to listen to inaddr_any:80> yes, but you also don't expect port 80 to be occupied on a system without that package installed. | 15:37 |
| rbasak | OTOH, on a regular system, nowadays we do expect a stub resolver to be occupying 53 somewhere. | 15:37 |
| paravoid | eh, maybe? :) | 15:37 |
| rbasak | Well sure, you can choose not to | 15:38 |
| rbasak | But it seems reasonable for other packages to expect that possibility | 15:38 |
| paravoid | is it the default on Ubuntu server installs? | 15:40 |
| paravoid | I don't know what's the latest in Debian default installs I admit | 15:40 |
| rbasak | From a quick look, yes it is | 15:44 |
| paravoid | I'd argue that the autopkgtest environment should as "clean" as possible with no ports occupied when none are documented to be etc. | 15:46 |
| paravoid | but I can totally see the flip side of the argument | 15:46 |
| paravoid | that the environment should resemble a clean install | 15:46 |
| dbungert | Is there anything special in unsyncing a currently synced package? lp: #1918848 | 19:14 |
| ubottu | Launchpad bug 1918848 in tuptime (Ubuntu) "regular users can't run tuptime (regression, autopkgtest failure)" [Undecided,In progress] https://launchpad.net/bugs/1918848 | 19:14 |
| cjwatson | Not really, it's just an upload with ubuntu1 on the end of its version number. If at all possible you should forward the patch to Debian though (https://wiki.ubuntu.com/Debian/Bugs) | 19:18 |
| cjwatson | In this case, while the bug is caused by a changed default in Ubuntu, the patch still seems safe in Debian and of course people might have made the same customization locally | 19:19 |
| dbungert | Yes, I concur and intend to upstream the change. Thanks! | 19:26 |
| paravoid | rbasak: regardless, with Debian's hard freeze (as of today) it'd be pretty hard to justify uploading a fix/workaround for this into Debian right now | 19:31 |
| paravoid | I don't know enough about Ubuntu, and I'm not motivated enough to learn how to upload an 1ubuntu1 =) | 19:32 |
| paravoid | so if not possible to ignore the force-migrate by ignoring then autopkgtests, then perhaps the package should be removed from hirsute? | 19:32 |
| rbasak | paravoid: if you give me a debdiff for a -1ubuntu1 I'll happily upload it for you. Package removal is up to the release team, which isn't me. I'm guessing they'd prefer it fixed rather than removed though. | 19:51 |
| rbasak | I think it's fine to just sit in hirsute-proposed and not migrate, unless it's actively blocking something else? | 19:52 |
| teward | have the release notes been started for hirsute yet? | 20:29 |
| teward | need to add some info for NGINX there | 20:29 |
| juliank | teward: Draft started november - https://discourse.ubuntu.com/t/hirsute-hippo-draft-release-notes/19221 | 21:27 |
| teward | E:NOACCESS so i'll have to give Laney what to add | 21:27 |
| juliank | I can add stuff too, but I don't know the ACL | 21:28 |
| teward | do you have the Canonical role next to your name like laney does on discourse? | 21:28 |
| teward | that's probably part of it :P | 21:28 |
| juliank | It's somewhere in the backlog from jan 28 or so | 21:29 |
| juliank | it's possible but it seems unusual | 21:30 |
| teward | oh THAT'S odd apparently I have 'rollback' priv but not edit. Might have to talk to IS about some odd permissions stuff going on. *shrugs* (CC has some elevated perms so we can edit our section... maybe that's why i see some perms) | 21:30 |
| juliank | fwiw, the wiki has forward links so you can find these threads by looking at HirsuteHippo/ReleaseNotes wiki like for pre-discourse releases | 21:32 |
| teward | yeah i discovered the link a few minutes before you linked me. ERR:LAZY | 21:33 |
| teward | :p | 21:33 |
| teward | juliank: long story short is, NGINX in Hirsute continues to ship NGINX 1.18.0, but the Lua module has been removed. This is due to the Lua module (originally from OpenResty) now requiring the resty-core module and us basically becoming OpenResty to continue to support the Lua module. As such, Hirsute no longer ships the Lua module, and those using the Lua module currently will not be able to upgrade to Hirsute without removing their Lua | 21:33 |
| teward | plugin code from their configurations. If users still need Lua support, they will need to compile and install OpenResty instead. (https://openresty.org/en/ is the OpenResty site) | 21:33 |
| teward | reword accordingly to your choice, but the Lua module is gone in Hirsute now | 21:33 |
| teward | not sure whether to put under Known Issues or such | 21:33 |
| juliank | There's some inconsistency in release notes between talking about users as a third party and "you" | 21:34 |
| teward | as i said | 21:34 |
| teward | reword accordingly | 21:34 |
| teward | my brain is fubar right now ;) | 21:35 |
| teward | thank you long week | 21:35 |
| juliank | I meant in the existing draft :DD | 21:35 |
| teward | i just need to tough out another 25 minutes and then i'm gone to gaming land for the weekend | 21:35 |
| teward | ah :) | 21:35 |
| juliank | Heh it's 10:30 pm here, so I'm not really here | 21:35 |
| juliank | :D | 21:35 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!