av2156 | can anyone help me fix my dns on ubuntu server ? | 01:19 |
---|---|---|
blahdeblah | av2156: What's not working, and what have you done to investigate so far? | 02:08 |
=== JanC_ is now known as JanC | ||
teward | bryyce: around? | 18:26 |
teward | or rbasak | 18:26 |
utkarsh2102 | at this time, probably Bryce should be. | 18:29 |
bryyce | hi | 18:29 |
bryyce | teward, what's up? | 18:30 |
teward | bryyce: could use an assist, DMs incoming | 18:30 |
=== oerheks1 is now known as oerheks | ||
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
rbasak | BTW, ~ubuntu-archive should be subscribed to that bug. | 20:54 |
bryyce | rbasak, will do | 20:54 |
bryyce | done | 20:54 |
bryyce | as aluded to in the bug, it may be worth deeper thought next cycle. | 20:55 |
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:56 |
bryyce | rbasak, of course, but the length of the todo list is not an argument against crossing an item off the todo list ;-) | 20:57 |
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:58 |
rbasak | I guess I just wanted to register my concern about some of the reasons given, to avoid mismatched expectations about the future. | 20:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!