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