[01:19] can anyone help me fix my dns on ubuntu server ? [02:08] av2156: What's not working, and what have you done to investigate so far? === JanC_ is now known as JanC [18:26] bryyce: around? [18:26] or rbasak [18:29] at this time, probably Bryce should be. [18:29] hi [18:30] teward, what's up? [18:30] bryyce: could use an assist, DMs incoming === oerheks1 is now known as oerheks [20:49] rbasak: i hear you have a question RE: nginx lua module that I poked bryyce about? [20:49] I'm puzzled as to why we need to remove it. Doesn't a dynamically linked module in universe solve our problems? [20:49] rbasak: yes and no [20:49] here's my consideration: [20:49] right now all nginx-lua module errors will present as NGINX errors [20:49] Apart from perhaps that introducing a lua5.1 dependency in the archive now is probably not good because we want to be phasing it out. [20:50] which means anyone having an error in the module will by default file against src:nginx [20:50] which in turn means you, myself, Bryce, and server team will have a plethora of bugs hit our radars that are NOT nginx bugs [20:50] I appreciate that, but I don't think it's a reason to exclude it. We accept dynamic modules in universe in the general case. [20:50] and the only way to really fix those bugs is to upgrade the module and in turn affect additional dependencies [20:51] We can work around that with an apport hook providing a list of enabled modules, for example. [20:51] newer nginx lua module, libluajit2 dependency (means dropping s390x and ppc64el), and additional extra openresty-core module dependencies (not packaged) [20:51] I think the only thing that reason justifies is punting this to the next release because it's close to FF. [20:51] rbasak: i'm not adverse to this being included in the future [20:51] but for now in kinetic i'd rather have it nuked so we (Debian) can focus on what we want to do with the module, updating it, etc. [20:51] and IMO it'salmost like an alpha-state version of the module with its new source / bin packages [20:52] It's the normal state of being for random packages in universe to be missing on some archs or get stuck in proposed, etc. [20:52] so I'm also for keeping it to 'next release' due to Feature Freeze [20:52] bryyce: ^^ awaken [20:52] To be clear, I'm not nacking the removal request. [20:52] I'm just flagging some things that seem a bit odd to me. [20:52] rbasak: i think the primary reason is to keep 'status quo' for the current release and then future add it again [20:52] but there's a plethora of issues that we need to handle for this in Debian too [20:53] and I don't want that spilling over down here and causing problems [20:53] Asking for a stay to next cycle because we're close to FF does make sense IMHO. [20:53] rbasak: agreed. also removing the binary and source currently as well until next cycle makes sense [20:53] but i have to prod the other maintainers for some faster action on their end [20:53] they're slow as sin recently [20:53] (in Debian) [20:54] BTW, ~ubuntu-archive should be subscribed to that bug. [20:54] rbasak, will do [20:54] done [20:55] as aluded to in the bug, it may be worth deeper thought next cycle. [20:56] I'm not concerned so much about having invalid bugs reported about it, more about if it clutters the update-excuses board. I wouldn't want +1'rs wasting time on it. [20:56] That and the gazillion other universe packages that also holds things up :) [20:57] rbasak, of course, but the length of the todo list is not an argument against crossing an item off the todo list ;-) [20:58] anyway, I figure this is sensible followup to the nginx 1.22 remerge [20:58] I think we might differ in opinion on the validity of the different arguments given, but for Kinetic, our conclusion is the same. [20:58] So let's defer the rest to K+1 [20:59] I guess I just wanted to register my concern about some of the reasons given, to avoid mismatched expectations about the future.