| === genii is now known as genii-meeting | ||
| 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 | 03:22 |
| === genii-meeting is now known as genii-core | ||
| 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:27 |
| 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:30 |
| 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:55 |
| 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... | 07:56 |
| === allen is now known as allenA | ||
| === sem2peie- is now known as sem2peie | ||
| === unixlab is now known as nicozdeb | ||
| 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:37 |
| 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:42 |
| schopin | Indeed, it was mostly a heads-up as there's a new delta impacting the MIR. | 10:43 |
| 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:09 |
| schopin | great, thanks! | 11:23 |
| === unixlab is now known as nicoz- | ||
| slyon | schopin: I'll be reviewing your lintian merge in a bit! | 12:16 |
| slyon | IIUC the libio-prompt-tiny-perl MIR isn't actually needed after the merge, as it's only used in internal scripts? | 12:17 |
| 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. | 12:27 |
| 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:21 |
| 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:24 |
| 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:38 |
| schopin | I'm on it. | 13:39 |
| slyon | thanks! | 13:39 |
| 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:40 |
| slyon | schopin: yeah, I just checked the new runtime dependencies manually (wearing my MIR hat) and found that they're in universe | 13:48 |
| schopin | pulling on that thread, there's a bunch of transitive dependencies in universe | 13:49 |
| 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:51 |
| 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) | 13:54 |
| 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:07 |
| 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:12 |
| slyon | schopin: ACK. I can help with sponsoring that | 14:13 |
| 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:15 |
| 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:24 |
| teward | other than "eventually logrotate and other signal driven tasks cause a crash" with no clear repro steps | 14:25 |
| teward | i believe this was reported in debian and upstream too with no resolutions | 14:26 |
| 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 | 14:39 |
| slyon | done! | 15:30 |
| === genii-core is now known as genii | ||
| 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 ? | 16:46 |
| 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:47 |
| sbraz | maybe it is already too late for jammy, i don't realise if such a change would be considered highly breaking | 17:48 |
| sarnold | sbraz: in the meantime, you can use the equivs package to help fake up a package to satisfy dependencies | 18:49 |
| 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:00 |
| 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:52 |
| 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 | 19:54 |
| 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:07 |
| 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:08 |
| 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:10 |
| 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:20 |
| sarnold | sbraz: yes, you would make a fake linux-firmware that would satisfy apt | 20:21 |
| 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:22 |
| 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:23 |
| 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:25 |
| sbraz | right; well we will have thousands of installs but not for the same customer | 20:26 |
| sbraz | if we didn't have that many installs i wouldn't even worry about the size of the image | 20:27 |
| mwhudson | vorlon: around? | 22:56 |
| 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:23 |
| 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:24 |
| 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:25 |
| vorlon | not sure that depends is warranted here, vs versioned Breaks of the old versions of the reverse-dependencies | 23:27 |
| vorlon | modulo that, I agree 2) is right and I don't see any landmines | 23:29 |
| 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:30 |
| 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:31 |
| sarnold | mwhudson: impish only? | 23:35 |
| mwhudson | sarnold: jammy only | 23:35 |
| sarnold | d'oh | 23:36 |
| sarnold | don't mind me, just living in the past here.. | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!