[00:10] <Eickmeyer[m]> Ohboy, here we go.
[00:10] <arraybolt3[m]> Anything I need to be prepped for?
[00:10] <Eickmeyer[m]> arraybolt3: Not yet, glibc just kicks-off every autopkgtest on the planet.
[00:11] <sarnold> heh
[00:11] <Eickmeyer[m]> Might be an understatement.
[00:12] <arraybolt3[m]> Oh man. That's like one of those "mess with this and Ubuntu will kill you" libraries, right?
[00:12] <sarnold> "you *will* introduce regressions"
[00:12] <Eickmeyer[m]> It's the library upon which everything is built. Quite literally.
[00:15] <sarnold> here's a regression from a glibc update that took ten months to sort out https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1926379
[00:15] <ubottu> Launchpad bug 1926379 in glibc (Ubuntu) "stack smashing attack detected in bash host tab completion" [Undecided, Confirmed]
[00:15] <sarnold> "here be dragons"
[00:16] <Eickmeyer[m]> Those were some firey dragons, iirc, and I should rc since it was recent.
[00:17] <Eickmeyer[m]> This glibc upload isn't supposed to be so bad, but you never know.
[00:18] <sarnold> this one was similar but different https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1674532
[00:18] <ubottu> Launchpad bug 1674532 in glibc (Ubuntu Xenial) "glibc update caused NSS ABI break" [Critical, Fix Released]
[00:23] <Eickmeyer[m]> This is a fun one that rears its head every now and then and was prevalent on Impish that people blame on glibc in Jammy when it's really developers not updating their Electron version in their apps: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1944468
[00:23] <ubottu> Launchpad bug 1944468 in glibc (Ubuntu Impish) "Electron applications all crash upon launch" [High, Fix Released]
[00:25] <sarnold> argh clone3
[00:47] <Eickmeyer[m]> clone3 was the source of a lot of pain.
[09:38] <greybored> Is it possible to specify what the hostname should be set to via the kernel params with autoinstall instead of specifying it in user-data?
[11:43] <ogayot> greybored: it has go to through user-data, I'm afraid
[17:35] <Eickmeyer[m]> vorlon: Not sure if you're around, but I have a successful build of a git snapshot of digikam 8.0. They have a new binary for audio/video playback.
[17:36] <Eickmeyer[m]> Would you like me to upload?
[17:36] <Eickmeyer[m]> New binary has no manpage yet, but I might be able to fix that this weekend.
[18:25] <vorlon> Eickmeyer[m]: I think it'd be swell if you did
[18:27] <Eickmeyer[m]> vorlon: Ok, I'll get it up if you wouldn't mind reviewing the new binary.
[18:39] <vorlon> rbasak: sorry, wrt the isc-dhcp uploads, I missed that there was a previous upload in the queue.  And given that my upload is for a bug that's still incomplete because it lacks a well-defined test case, I think we should give slyon's upload precedence
[18:40] <vorlon> Eickmeyer[m]: oh, why does this need a new binary package?
[18:41] <Eickmeyer[m]> vorlon: They included a new stand-alone binary to be an audio/video player in addition to being the backend for the audio/video of the main application.
[18:41] <vorlon> but why does the stand-alone binary imply a new binary package?
[18:42] <Eickmeyer[m]> Because it can be installed separately, similar to the showfoto package digikam produces.
[18:42] <vorlon> It can only be installed separately if you package it that way
[18:42] <vorlon> and I'm questioning why it's necessary to package it that way
[18:42] <vorlon> and has this already been discussed with the Debian maintainers?
[18:43] <Eickmeyer[m]> This has not been discussed with the Debian maintainers, but it seemed like the right thing to do as intended by the upstream developers.
[18:44] <Eickmeyer[m]> https://invent.kde.org/graphics/digikam/-/commit/e88cd0d16135b558c55cc4c3bc5bf5e334a861ae
[18:44] <ubottu> Commit e88cd0d in graphics/digikam "export qtav player as new plublic stand alone tool named avplayer"
[18:44] <vorlon> well, we share a package namespace with Debian and if they package it as part of the same binary package we potentially have Ubuntu-specific upgrade issues.  Please discuss with Debian maintainer before uploading with a binary package split
[18:47] <Eickmeyer[m]> That might not be an issue, but I'll give them the heads-up. You'll notice that I used ~git[iso-date] for the archive name in this case as they don't exactly have a release archive since this is a git snapshot. Debian is not likely to pack a git snapshot anytime soon, and we can easily sync whatever they come up with.
[18:51] <Eickmeyer[m]> vorlon: I'm emailing the Debian maintainer directly, who also contributes directly to the Digikam project, and is likely already aware.
[19:06] <Eickmeyer[m]> vorlon: CC'd you.
[19:41] <vorlon> Eickmeyer[m]: cheers
[19:48] <vorlon> Eickmeyer[m]: also, to bypass this in the short term, you could upload the package such that it simply does not ship the new binary at all (if it's not required for operation of the other packages) and add it later once there's agreement about which binary package to put it in
[19:49] <Eickmeyer[m]> vorlon: Too late unless you can reject the binary.
[19:49] <vorlon> Eickmeyer[m]: I certainly can do that ;)
[19:50] <Eickmeyer[m]> Works for me.
[19:50] <vorlon> Eickmeyer[m]: you will need to use a different source version number to reupload
[19:50] <Eickmeyer[m]> Easy enough.
[19:50] <tsimonq2> "Version numbers are relatively cheap"
=== smoser2 is now known as smoser
[21:17] <vorlon> arraybolt3[m], tsimonq2: hi, reviewing lubuntu-installer-prompt in the NEW queue just now; fwiw I'm willing to accept the package in its current state, but 'Lubuntu Developers' is not a correct copyright holder for this software; it was written by someone and that someone(s) is(are) the copyright holder, not a mailing list
[21:18] <vorlon> arraybolt3[m], tsimonq2: I would also suggest putting these binaries under /usr/lib instead of adding lintian overrides about the lack of manpage; and for completeness, has there been any discussion about whether ubiquity-dm could be modified for use on lubuntu rather than having an entirely separate codebase to maintain?
[21:19] <arraybolt3[m]> vorlon: Lubuntu doesn't use Ubiquity, so I'm not sure trying to mix parts of Ubiquity into the system is going to work well (just my initial thought). As for the copyright holder, I can fix that and set the copyright holder as Simon since he's the one who wrote it.
[21:22] <arraybolt3[m]> (The program is dirt-simple, so maintaining it separate from Ubiquity shouldn't be too difficult. Also, just so I get a better understanding here, since lubuntu-installer-prompt is a program and not a library, and it isn't used by any other program, I don't think it qualifies for going in /usr/lib, but this might be because I'm misunderstanding something. Is there a reason why putting the program in what seems like the wrong spot
[21:22] <arraybolt3[m]> would be more preferable to putting it in the right spot and using a Lintian override?)
[22:09] <vorlon> arraybolt3[m]: perhaps /usr/libexec would be better than /usr/lib, and make it clearer why I'm advocating for not having it on the system path?  But the argument for not having a manpage is that it's not meant to be invoked by users, so it stands to reason it shouldn't be on the user path
[22:11] <vorlon> arraybolt3[m]: as for whether it makes sense to maintain it as part of ubiquity, I can say that we've had any number of bugs over the history of Ubuntu related to the equally-small ubiquity-dm, having to do with sessions being set up with the correct permissions, etc., impacting everything from proper keyboard localization to integration with accessibility libraries.  Something worth considering IMHO
[23:09] <arraybolt3[m]> vorlon: Hmm, I see what you're saying about ubiquity-dm. However, looking at some of the ubiquity-dm code, it is far larger than lubuntu-installer-prompt, and appears to rely on Ubiquity by default. With Lubuntu's Calamares-based setup, we've so far not had horrible trouble with keyboard localization or things like that (AFAIK). All lubuntu-installer-prompt does is either drop the user to a desktop or launch Calamares, everything
[23:09] <arraybolt3[m]> else is already set up. ubiquity-dm might break what's already there and working. (This is just my thoughts on the matter, Simon Quigley is probably much more well-equipped for this particular discussion.)
[23:09] <arraybolt3[m]> Also, your logic about putting the prompt under /usr/libexec makes good sense, I'll see if I can get that implemented.
[23:18] <vorlon> arraybolt3[m]: ubiquity-dm> fair enough.  I'm also skeptical of the decision to use calamares instead of collaborating on ubiquity, but that's neither here nor there :)
[23:29] <arraybolt3[m]> vorlon: It's been like that for at least since Focal. :) (Calamares wasn't feature-rich enough.)
[23:30] <arraybolt3[m]> (Er, Ubiquity wasn't feature rich enough... wow what a typo)
[23:30] <Unit193> Calamares has downsides too, don't worry! ;)
[23:31] <arraybolt3[m]> Unit193: LOL Oh you ain't jokin'. It has been a fun ride.
[23:32] <arraybolt3[m]> OK, I'm going to get to work on fixing that one bit of packaging and then we'll see what happens from there.