[08:30] <juliank> tsimonq2: Trying to find hmollercl, you sponsored two software-properties uploads for him, and pushed commits to git, but no tags. I can add some myself, but if possible I'd like to get signed tags from the person who uploaded it.
[08:31]  * juliank just loves signed tags :)
[08:58] <juliank> Wimpress: Why'd you change ubuntu-mate-welcome in bug 1673258 to "Opinion"? Are you committing to keep maintaining aptdaemon? ;)
[08:59] <juliank> "Opinion" being a nicer word for "Won't fix" and all
[09:01] <Wimpress> Well, we are currently implementing PackageKit support in the new version.
[09:02] <juliank> I just don't see how Opinion fits here
[09:03] <Wimpress>  But vorlon made a comment on that bug last night which suggests we have to choose between two unmaintained options.
[09:03] <juliank> Well, that's true-ish
[09:03] <Wimpress> Hence 'Opinion'
[09:03] <juliank> PackageKit is still better supported than aptdaemon
[09:04] <juliank> It just does not really get any features :)
[09:04] <Wimpress> Because I'm not certain which is the right path forward now, even though we're currently working towards PackageKit
[09:04] <juliank> I think the important point is to get rid of aptdaemon for 20.20
[09:05] <juliank> Whether we end up with PackageKit + a new apt daemon, or just a new apt daemon is less worrying
[09:05] <juliank> s/20.20/20.04/
[09:06] <juliank> I gotta do some more speccing on that and some prototyping
[09:07] <juliank> Really I think everything except update-manager can be ported to PackageKit to at least reduce aptdaemon impact
[09:07] <juliank> I don't think the changes are really huge
[09:08]  * juliank just ported software-properties to it
[09:09] <juliank> I think the blocker for update-manager is that PackageKit can essentially only install _or_ remove packages, but you can't specify both in one transaction.
[09:09] <juliank> well, major blocker anyway
[09:10] <juliank> That said: We use a hybrid approach: Use apt.Cache() to calculate the changes, and then apply them using PackageKit.
[09:10] <juliank> It's a bit racy
[09:10] <juliank> But PackageKit's always racy anway
[09:12] <juliank> ugh, my port is not done
[09:12] <juliank> I gotta translate from apt package names to packagekit package-ids
[09:13] <juliank> (which are essentially name;version;arch;repo - I think the flags are optional)
[09:13] <Wimpress> Thanks for the info. We're planning to land the new version of Software Boutique for 19.10 and the current backends are PackageKit and snapd-glib
[09:28] <juliank> Huh, I just realized apt.Package.architecture is a function; but it should be a property.
[09:28] <juliank> ugh.
[11:42] <tsimonq2> juliank: Join #lubuntu-devel and ping him by typing @HMollerCl (via Telegram)
[11:43] <tsimonq2> Our channels are bridged.
[11:45] <juliank> I see
[11:45] <juliank> how odd
[12:36] <tsimonq2> heh
[18:17] <Odd_Bloke> I'm updating a package to install its bash completion scripts in to /usr/share instead of /etc.  What is the right way to clean up the old /etc file on upgrade?
[18:18] <rbasak> Odd_Bloke: rm_conffile? Or are you wondering how to deal with local modifications?
[18:19] <rbasak> If you're looking for rm_conffile, see dh_installdeb(1) on package.maintscript, and also dpkg-maintscript-helper(1), but I'm not sure if that's what you're asking, or already know that and are asking more specifically about the move.
[18:20] <Odd_Bloke> rbasak: It's not something I've had to deal with before, so that is what I was asking. :)  Thanks!
[18:24] <ahasenack> Odd_Bloke: I *think* install the new one in /usr/share, and use rm_conffile on the etc one
[18:24] <ahasenack> there is mv_conffile,
[18:24] <ahasenack> but maybe it's just for renaming
[18:25] <ahasenack> and I'm not sure it supports moving to /usr/share
[18:25] <ahasenack> but I would look into that too
[18:27] <Odd_Bloke> My feeling is that rm_conffile is the right move, because it being in /usr/share is pretty much a declaration that we no longer consider bash completions to be conffiles, right?
[18:27] <ahasenack> right
[18:28] <ahasenack> also moving it from etc to usr/share, and at the same installing the default one in usr/share, looks weird and prone to failure
[18:30] <rbasak> Agreed.
[18:30] <rbasak> The only thing you're losing is that you're not preserving user modifications to the file in /etc, which is normally the intention.
[18:30] <rbasak> s/intention/expectation/
[18:30] <Odd_Bloke> And rm_conffile will leave a backup behind in the unlikely event that someone has felt the need to customise their cloud-init bash completions.
[18:30] <rbasak> Right
[18:31] <rbasak> IMHO that's sufficient if the package is reorganising like that.
[18:32] <Odd_Bloke> Cool, thanks again!
[19:18] <bladernr> was python3-guacamole dropped from Ubuntu for disco, or is it just an oversite that it's missing?
[19:20] <Odd_Bloke> bladernr: https://irclogs.ubuntu.com/2019/04/15/%23ubuntu-devel.html#t12:42
[19:21] <bladernr> Odd_Bloke, thanks!  sigh...
[21:23] <seb128> cyphermox, bug #1825206 claims to be a SRU regression
[21:23] <seb128> bdmurray, SRU team, ^
[21:26] <seb128> also bug #1825402 claims to be an other SRU regression
[21:26] <seb128> ddstreet, ^
[21:27] <seb128> vorlon, ^ unsure if people are still around/if tomorrow is off for them/if we should do something about those SRUs before the long w.e?
[21:27] <bdmurray> seb128: its not a long weekend for people in the US
[21:27] <seb128> k, I was unsure
[21:27] <seb128> bdmurray, thx :)
[21:27] <vorlon> seb128: looking at it; I am skeptical that this is a regression introduced by the netplan SRU
[21:28] <vorlon> oh he says he verified by re-downgrading
[21:28] <vorlon> hmm
[21:28] <seb128> vorlon, the user said that downgrading fixed it though... but yeah
[21:29] <cyphermox> it's odd; I certainly don't expect this to be the case, but I'll have a look
[21:40] <seb128> cyphermox, thx
[21:40] <seb128> on that note calling it a day here, have a good evening/night :)
[21:43] <gaughen> cyphermox, create a card please
[21:43] <gaughen> or i can
[21:43] <gaughen> (just tell me)
[23:26] <vorlon> cyphermox: there's enough here that I am going to roll back the SRU while investigation continues