=== ledeni_ is now known as ledeni
[08:06] <LocutusOfBorg> seb128, I might have some patch soon for xpdf, I would appreciate if you can just review it
[08:08] <seb128> LocutusOfBorg, k
[08:17] <LocutusOfBorg> patch mostly finished
=== msmarcal|eod is now known as msmarcal
=== ricab is now known as ricab|lunch
[12:57] <juliank> I extended bug #1825972 to cover some more old gnome 2 packages without reverse deps (gnome-vfs, libbonobo, libbonoboui, libgnome, orbit2)
[12:57] <ubottu> bug 1825972 in libgnome-keyring (Ubuntu) "Remove gnome 2 stack + linsmith from eoan" [Undecided,Incomplete] https://launchpad.net/bugs/1825972
[12:58] <juliank> Initially filed only to get libgnome-keyring out, I today realized that the whole gang can go
=== ricab|lunch is now known as ricab
[17:29] <GunnarHj> Hi bdmurray, would you have time to look at bug #1825733 again? I submitted a couple of debdiffs.
[17:29] <ubottu> bug 1825733 in ubuntu-release-upgrader (Ubuntu Disco) "ubuntu-release-upgrader-core shows upgrading from 18.10 to 18.10" [High,In progress] https://launchpad.net/bugs/1825733
[17:35] <bdmurray> GunnarHj: Do you want to fix bug 1727472 at the same time?
[17:35] <ubottu> bug 1727472 in ubuntu-release-upgrader (Ubuntu Eoan) "[RFE] Automatically update the Ubuntu version string in ubuntu-release-upgrader" [Medium,Triaged] https://launchpad.net/bugs/1727472
[17:41] <GunnarHj> bdmurray: I'm afraid that I don't know enough about gtk and qt to do that, sorry. I suppose the strings would need to me moved from respective .ui file to python. So I think it would be good if the qt oversight could be fixed separately.
[17:44] <bdmurray> GunnarHj: okay, I'll get the eoan change uploaded the disco one might be a bit as there is a current SRU
[17:46] <GunnarHj> bdmurray: That would be a good first step. As I stated in the bug report, I'm not 100% sure that the change is sufficient. But having it in eoan will make it possible to test Kubuntu 19.04->19.10 upgrades at least.
[21:10] <GunnarHj> bdmurray: autopkgtest complaint for update-manager:
[21:10] <GunnarHj> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-release-upgrader
[21:38] <ddstreet> vorlon you might not remember, but it looks like you added a patch to sudo to keep HOME in the keep_env list, way back in 2011 (so that running 'sudo' doesn't change $HOME by default, without -i or -H)...do you remember what the reason for setting that as default was?  I'm just curious as to why
[21:38] <vorlon> ddstreet: I only know that the changelog points to LP: #760140
[21:38] <ubottu> Launchpad bug 760140 in sudo (Ubuntu Natty) "HOME environmental variable no long preserved with sudo by default" [Medium,Fix released] https://launchpad.net/bugs/760140
[21:39] <ddstreet> ah! thnx, i was git blaming the patch to see how far back it was added, should have checked the changelog for that release
[21:40] <ddstreet> vorlon do you still agree with that decision?  it has some unfortunate side effects, like sudo-run applications creating root-owned files/dirs in $HOME
[21:41] <vorlon> ddstreet: I will not attempt to defend that decision 8 years later :)
[21:41] <ddstreet> lol
[21:41] <vorlon> things have moved on and there's certainly a new normal in terms of sudo expected behavior elsewhere
[21:41] <ddstreet> vorlon i suppose an email to ubuntu-devel would be best if i wanted to revive the discussion
[21:42] <vorlon> sounds good to me
[21:58] <connor_k> How can I increment a package version in just an older release (backporting something to Bionic) such that if they were to upgrade to Cosmic they wouldn't be forced to remain on the Bionic version (because it's now technically greater than the one in Cosmic)?
[21:59] <connor_k> Otherwise before the change, both packages are the same version number in Bionic and in Cosmic
[22:00] <tyhicks> I was talking with connor_k about this previously and don't have any good ideas myself
[22:01] <tyhicks> to give a specific example, he needs to SRU some patches that back to Bionic's ndiswrapper, but not Cosmic's, in order to let the module build with hwe kernels
[22:02] <tyhicks> the problem is that Bionic and Cosmic ndiswrapper are both at 1.60-6
[22:06] <tyhicks> bah... s/SRU some patches that back to/SRU some patches back to/
[22:07] <tyhicks> infinity, bdmurray: I feel like one of you two might have some solid advice here for connor_k ^
[22:07] <infinity> Without backporting to both releases, you can't achieve what you want.
[22:07] <infinity> (Well, uploading to both, at least)
[22:07] <infinity> Is there harm in cosmic having the same fixes?
[22:07] <tyhicks> I didn't think so but is it acceptable to only upload to Bionic in this case?
[22:08] <tyhicks> infinity: no harm other than needless risk of regression
[22:08] <infinity> It wouldn't particularly hurt anything to upload just to bionic either.
[22:08] <tyhicks> that was my feeling, too
[22:08] <infinity> Or, upload to bionic, verify, then binary copy forward to cosmic too, if one really cares about the version oops.
[22:09] <infinity> Once cosmic goes EOL, these sorts of version disparities happen all the time anyway.
[22:09] <tyhicks> exactly and cosmic EOL isn't far away
[22:09] <infinity> Cause someone will backport $pkg from $devel to bionic and disco, but cosmic is closed.
[22:10] <infinity> It's 2.5 months out.  That's far enough. :P
[22:10] <infinity> But if the patches are useless in cosmic anyway, it's all a bit of a meh.
[22:10] <tyhicks> after talking it over, I feel comfy enough sponsoring connor_k's upload only to bionic as this is a pretty harmless version oops (I wouldn't want to do it to an LTS release)
[22:11] <tyhicks> thanks
[22:11] <connor_k> infinity, tyhicks thanks!