=== genii is now known as genii-meeting
[03:22] <mwhudson> uhh how can setting LC_ALL have a different impact to setting all the other LC_* variables?
[03:22] <mwhudson> glibc 2.35 makes rrdtool fail a test, in a very strange way
=== genii-meeting is now known as genii-core
[07:27] <gombara> hello. I have been trying to automate install of Ubuntu 21.10 desktop. All the information I could found online points to modifying grub.cfg to provide command line options to kernel. but for some reason I could not get it working. after the boot it lands in live session desktop instead of starting the install. any ideas?
[07:30] <utkarsh2102> teward: hey, whenever time allows, could you quickly skim through LP: #1952614, please?
[07:30] <ubottu> Launchpad bug 1952614 in nginx (Ubuntu) "nginx crashes with dump because of segfault" [Undecided, Incomplete] https://launchpad.net/bugs/1952614
[07:55] <alkisg> https://motd.ubuntu.com/ seems down and slows the update-motd service, should I report this somewhere or is it a known, temporary server downtime?
[07:56] <alkisg> Connecting to motd.ubuntu.com (motd.ubuntu.com)|34.243.160.129|:443... failed: Connection timed out.
[07:56] <alkisg> Connecting to motd.ubuntu.com (motd.ubuntu.com)|54.171.230.55|:443... connected.
[07:56] <alkisg> HTTP request sent, awaiting response... 200 OK
[07:56] <alkisg> I guess the problem is on one of the servers in the pool...
=== allen is now known as allenA
=== sem2peie- is now known as sem2peie
=== unixlab is now known as nicozdeb
[10:37] <schopin> Looking for a sponsor for my Lintian merge: LP: #1957100 (pinging cpaelzer as it impacts LP: #1951065)
[10:37] <ubottu> Launchpad bug 1957100 in lintian (Ubuntu) "Merge lintian 2.114.0 from Debian unstable" [Wishlist, New] https://launchpad.net/bugs/1957100
[10:37] <ubottu> Launchpad bug 1951065 in libio-prompt-tiny-perl (Ubuntu) "[MIR] libio-prompt-tiny-perl" [Undecided, Incomplete] https://launchpad.net/bugs/1951065
[10:42] <cpaelzer> schopin: I have never dealt with the inner details of lintian and for a 2.9MB debdiff somone knowing it better might be a better sponsor?
[10:43] <schopin> Indeed, it was mostly a heads-up as there's a new delta impacting the MIR.
[11:09] <athos> hi schopin! I haven't pushed anything new in there for python-debian because I could not work on a better solution for the file sizes issue yet. I will get back to it this week and update the MR with the better approach if that works for you
[11:23] <schopin> great, thanks!
=== unixlab is now known as nicoz-
[12:16] <slyon> schopin: I'll be reviewing your lintian merge in a bit!
[12:17] <slyon> IIUC the libio-prompt-tiny-perl MIR isn't actually needed after the merge, as it's only used in internal scripts?
[12:27] <schopin> slyon: yes, those scripts will be part of the actual bin package only in a latter version, so this is only temporary, but hopefully the -prompt-tiny vs -prompter debate will be resolved by then.
[13:21] <teward> utkarsh2102: what do you need me to look at it for that cpaelzer hasnt already done to id as "e:norepro" and set as incomplete?
[13:24] <teward> utkarsh2102: the crash is in libperl under the hood and not exactly something I myself can debug.  I also have been unable to reproduce it in any environment
[13:38] <slyon> schopin: wrt. lintian merge: did you choose the "LP #..." syntax (without colon) on purpose? I think it would actually make sense to close those bugs from the changelog, no? Also, I like your approach of resolving the libio-prompt-tiny-perl MIR (for now)! But it looks like this upload would introduce two new MIRs (libdata-validate-uri-perl & libsyntax-keyword-try-perl). Other than that I like the debdiff!
[13:38] <schopin> Oh FFS!
[13:38] <slyon> Is there any way to avoid the new MIRs? Or could you alternatively create the corresponding MIR bugs/templates for those two packages and tag them "update-excuse' so that we don't lose track?
[13:38] <slyon> If we have the template bugs, I could fixup the changelog and sponsor the upload
[13:39] <schopin> I'm on it.
[13:39] <slyon> thanks!
[13:40] <schopin> How did you notice the MIR need? Did I miss a warning somewhere or did you have the foresight of checking for that?
[13:48] <slyon> schopin: yeah, I just checked the new runtime dependencies manually (wearing my MIR hat) and found that they're in universe
[13:49] <schopin> pulling on that thread, there's a bunch of transitive dependencies in universe
[13:51] <slyon> well, I didn't check that. But it means more MIRs I guess... unless we can somehow work around it in the packaging by avoiding the new dependencies?
[13:54] <schopin> slyon: the first package is used in some systemd unit file checks, and the second one is used all over the place (26 occurrences)
[14:07] <slyon> schopin: IMO the first package is useful and needed. we should probably MIR it. but for the 2nd one, I wonder if we should rather revert https://salsa.debian.org/lintian/lintian/-/commit/6528e60c214aa5c4b0c723a6f28cb2645123fa8e for now? Until that syntax is actually included in perl 5.34? To avoid MIRing the intermediary libsyntax-keyword-try-perl.
[14:07] <ubottu> Commit 6528e60 in lintian/lintian "Use Syntax::Keyword::Try instead of Try::Tiny, except in one instance."
[14:12] <schopin> slyon: I'm considering a two-tiered solution: first, uploading 2.111.0ubuntu3 with the prompt-tiny removal to get some progress on the package (I've just asked for lintian-brush removal, so that'd make lintian migrate), and then try and upgrade to 2.114. Otherwise, I'm afraid the MIRs will take too much time
[14:13] <slyon> schopin: ACK. I can help with sponsoring that
[14:15] <utkarsh2102> teward: ah cool, it just came up in my triage that the reporter dropped the last comment asking if it's actually a bug or something.
[14:24] <teward> utkarsh2102: i'm subscribed to all nginx bugs.  they are asking if the bug lies in nginx or libperl under the hood.  PROBLEM is theres no Minimum Reproducible Examples for it
[14:25] <teward> other than "eventually logrotate and other signal driven tasks cause a crash" with no clear repro steps
[14:26] <teward> i believe this was reported in debian and upstream too with no resolutions
[14:39] <schopin> slyon: LP: #1959004
[14:39] <ubottu> Launchpad bug 1959004 in lintian (Ubuntu) "lintian: remove unused non-main dependency libio-prompt-tiny-perl" [High, New] https://launchpad.net/bugs/1959004
[15:30] <slyon> done!
=== genii-core is now known as genii
[16:46] <bdmurray> sil2100: Are you working on a ubiquity upload right now or can I merge https://code.launchpad.net/~rikmills/ubiquity/+git/ubiquity/+merge/414563 ?
[17:47] <sbraz> hello, is there any chance someone could look into https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/1948669 before jammy is officially released? having to include linux-firmware in our Ubuntu images adds several hundred MiBs which is problematic for us in some cases
[17:47] <ubottu> Launchpad bug 1948669 in linux-meta (Ubuntu) "linux-image-generic should suggest linux-firmware instead of depending on it" [Undecided, Confirmed]
[17:48] <sbraz> maybe it is already too late for jammy, i don't realise if such a change would be considered highly breaking
[18:49] <sarnold> sbraz: in the meantime, you can use the equivs package to help fake up a package to satisfy dependencies
[19:00] <vorlon> ddstreet, slyon: either of you know anything about RH IP conflict detection?  Is it using RFC 5227 via networkd DuplicateAddressDetection, or something else? https://askubuntu.com/questions/1388238/how-to-setup-netplan-networkd-to-detect-an-ip-conflict-being-putting-networking
[19:52] <sbraz> sarnold: i skimmed over the man but it's a bit abstract, would i have to maintain it myself? i.e. change the package every time there's a new kernel version?
[19:54] <sarnold> Depends: linux-image-5.4.0-26-generic, linux-modules-extra-5.4.0-26-generic, linux-firmware, intel-microcode, amd64-microcode
[19:54] <sarnold> sbraz: it looks like an unversioned dependency
[20:07] <sbraz> sarnold: i don't really understand what this means: if i were to creae such a package via equivs, would i have to maintain it or just create it once and it'd stay up-to-date on its own?
[20:08] <sbraz> linux-modules-extra-5.4.0-26-generic → maybe that 5.4.0-26-generic is not the "version" of the package but then it's still a dependency that is likely to change
[20:10] <sarnold> sbraz: your bug report is about the linux-image-generic dependency on linux-firmware, right? there's no version number in that dependency, at least on my focal system, so you'd just have to make the one package, once, and then you'd never get firmwares
[20:20] <sbraz> sarnold: the dependency on linux-firmware is the problem because i want to keep up-to-date linux-modules-extra-xxx packages on my systems; i thought equivs would help me create a "fake" package that would depend on another
[20:20] <sbraz> what you're saying is that i could use equivs to prevent installation of linux-firmware?
[20:21] <sarnold> sbraz: yes, you would make a fake linux-firmware that would satisfy apt
[20:22] <sbraz> sarnold: but if a user (the image i'm building is meant to be used by customers) wanted to install the actual linux-firmware package, would that be confusing/difficult for them?
[20:23] <sarnold> sbraz: yes
[20:23] <sbraz> ok in that case that's not ideal; we try to deviate as little as possible from "upstream"
[20:23] <sbraz> but thanks for the suggestion anyway, i might test it :)
[20:25] <sarnold> yeah if you've got users who aren't you, it's not great :) normally it's used by folks who have dozens or thousands of machines all under their control
[20:25] <sarnold> or if you were making standalone devices and ubuntu core or fedora silverblue etc stuff didn't work for you
[20:26] <sbraz> right; well we will have thousands of installs but not for the same customer
[20:27] <sbraz> if we didn't have that many installs i wouldn't even worry about the size of the image
[22:56] <mwhudson> vorlon: around?
[23:23] <vorlon> mwhudson: hi
[23:23] <mwhudson> vorlon: so glibc 2.35 removes a binary that was until recently part of libc-bin
[23:23]  * vorlon nods
[23:23] <mwhudson> ("catchsegv", it's fairly obscure but used by a few testsuites at least)
[23:23] <mwhudson> it's here now: https://github.com/zatrazz/glibc-tools
[23:24] <mwhudson> i see two (maybe three) options: 1) patch it back into libc-bin 2) package glibc-tools and have libc-bin depend on it (with some fun replaces/conflicts stuff i guess) and 3) just drop the binary and fix the packages that use it
[23:25] <mwhudson> not sure 3) is really an option
[23:25] <mwhudson> vorlon: i think 2) is the Right Thing (tm) but do you see any mines we could step on with this? (it should be easier than the libxcrypt mess at least!)
[23:27] <vorlon> not sure that depends is warranted here, vs versioned Breaks of the old versions of the reverse-dependencies
[23:29] <vorlon> modulo that, I agree 2) is right and I don't see any landmines
[23:30] <mwhudson> vorlon: ah so glibc-tools would Breaks: libc-bin (<< 2.35) and we'd add build-depends on glibc-tools to packages that need it?
[23:30] <vorlon> mwhudson: is it only used at build time?
[23:31] <vorlon> if there are no runtime deps at all then I really don't care about breaks or depends
[23:31] <mwhudson> vorlon: i didn't read all of https://codesearch.debian.net/search?q=catchsegv&literal=1 but afaict yes, just build time
[23:31] <mwhudson> i guess we should get sarnold to wind up his archive source search too
[23:31] <mwhudson> (at least it's a pretty unambiguous name!)
[23:35] <sarnold> mwhudson: impish only?
[23:35] <mwhudson> sarnold: jammy only
[23:36] <sarnold> d'oh
[23:36] <sarnold> don't mind me, just living in the past here..