[08:44] <Max[m]123456> Is there a specific reason, why Ubuntu choose to use dracut?
[10:02] <gcds> Hi, maybe someone could help me with ubuntu server netplan stuff, I am going bald from trying to figure out what is wrong. Context: I have network 10.93.0.0/16 the server has a bridge with one interface and static IP address of 10.93.2.2/16, everything generates and works but for some reason I can't access anything higher than 10.93.127.254, I
[10:02] <gcds> tried adding a static route for 10.93.0.0/16 via 10.93.0.1 but didn't help, but then I removed default generated route which looked suspicious to me (the 10.93.0.0/16 via 10.93.2.2 in the paste) and it worked then, I would consider it's done but I know it's not permanent so maybe can help me figure out whats wrong with netplan so I would not need
[10:03] <gcds> to make changes after each reboot? https://paste.ubuntu.com/p/kPrPBwPQBx/
[10:15] <athos> morning! Could anyone please import php-cache-integration-tests into git ubuntu? :)
[10:16] <athos> Cc rbasak sergiodj ^
[10:44] <rbasak> Max[m]123456: Ubuntu doesn't use dracut?
[10:47] <rbasak> athos: done
[10:48] <athos> rbasak: thanks!
 "Max: Ubuntu doesn't use dracut?" <- The initrd of the installer sure looks like it does
[10:53] <rbasak> Max[m]123456: AIUI Ubuntu uses update-initramfs which isn't dracut. Are you really asking why Ubuntu uses an initramfs at all?
[11:02] <Max[m]123456> Well, I know it needs to use one. But what I see inside the installer does not look similar to the initramfs, Ubuntu creates after the installation.
[11:02] <Max[m]123456> I'm just asking about inconsistencies
[12:41] <ahasenack> sergiodj: kanashiro hey, are you on debconf-discuss@? Did you see the yubikey email?
[14:21] <utkarsh2102> ahasenack: you need one? :)
[14:21] <ahasenack> I expensed one
[14:22] <ahasenack> so I'm good
[14:22] <ahasenack> but you guys should take the opportunity and get one if possible, and if you are going to debconf
[14:23] <utkarsh2102> yes! 
[14:23] <utkarsh2102> I got one in 2019. 
[16:46] <blackboxsw> hi folks, packaging opinion question for apt purge behavior: for packages whose runtime emits configuration :wq
[16:46] <blackboxsw> wow, sorry. will try again
[16:47] <patdk-lap> irc isn't vi :)
[16:48] <blackboxsw> :) hi folks, packaging opinion for apt purge behavior: for packages where the runtime emits unpackaged config files into other service config directories, should apt purge remove these runtime artifacts or leave the vestigial config content around?
[16:49] <rbasak> It depends :-P
[16:49] <blackboxsw> I ask as cloud-init emits network configuration potentially into /etc/netplan or /etc/network/interfaces.* parts directories which it doesn't package itself.
[16:49] <rbasak> As an extreme example, consider vi. I use it to adjust system configuration in /etc, and when (if!) I purge vi, I don't expect those changes to be reverted.
[16:50] <rbasak> So assuming you're asking about ua, similarly if the user asks ua to make a system change, I'd expect the change to remain after it is purged, I think. Where that makes sense under the circumstances.
[16:50] <blackboxsw> but runtime will decide to dump those conf files into those directories depending on what version of a distro you are running.
[16:51] <blackboxsw> in the event that someone wants to purge cloud-init, should the cloud-init package care about augemented configuration that dynamically got created by the initial runtime.
[16:51] <rbasak> Right, so for cloud-init, I think it's much the same. Its task is to set up networking, and so perhaps the networking it set up should remain if it's gone.
[16:51] <ahasenack> agreed
[16:51] <blackboxsw> These network config artifacts would be known to cloud-init
[16:51] <ahasenack> it's not cloud-init configuration, it just was done by cloud-init
[16:51] <rbasak> OTOH, if its *presence* is supposed to keep networking going, then removing the package might be expected to remove it. 
[16:52] <rbasak> So it's a question of which of those two cases fits.
[16:52] <blackboxsw> ahasenack: right. it's an artifact of cloud-init running. it's not a static config file that cloud-init delivers in the cloud-init.dev
[16:52] <blackboxsw> ahasenack: right. it's an artifact of cloud-init running. it's not a static config file that cloud-init delivers in the cloud-init.deb
[16:53] <blackboxsw> and right, I'm concerned in this particular case that removing such a config file could lead to unexpected results if someone restarts the network service after the purge
[16:54] <blackboxsw> But it just raised a general quesiton in my mind: should a deb package that emits config content to other services generally cleanup anything it knows it could have emitted? And I guess the answer is case-by-case
[16:54] <rbasak> I think it's case-by-case to work out which of these two categories the case fits into.
[16:54] <ahasenack> here is another consideration: if that other package (that got its config from cloud-init) is removed, will it remove this config file that cloud-init emitted?
[16:55] <rbasak> User expectation of package presence vs. the package as a tool to enact configuration changes.
[16:55] <ahasenack> consider .d directories
[16:55] <rbasak> For most packages it's package presence, but cloud-init, ua and vim are all special cases.
[16:56] <blackboxsw> andreas: `dpkg: warning: while removing netplan.io, directory '/etc/netplan' not empty so -
[16:56] <blackboxsw> not removed `
[16:56] <blackboxsw> yeah unexpected config files left around :)
[16:56] <ahasenack> was that a purge?
[16:56] <blackboxsw> ahasenack: yep
[16:57] <ahasenack> but that doesn't break a system
[16:57] <ahasenack> removing the netplan config generated by cloud-init just because cloud-init was removed might break the system
[16:57] <blackboxsw> rbasak: and right cloud-init is a tool to provide config changes. the use-case for using it, and then purging it is "interesting" to say the least
[16:57] <ahasenack> this is the exercise to be made
[16:59] <rbasak> It's also pretty rare to want to purge cloud-init
[17:00] <rbasak> I have seen some packages debconf prompt at purge time to ask the question if associated data (eg. in /var) should be deleted also.
[17:00] <rbasak> So that's a pattern you could use - and maybe default it to the safe option of not deleting those files.
[17:01] <rbasak> But I suppose it all depends on why you're asking the question :)
[17:02] <sdeziel> I've often purged cloud-init... I was being lazy and wanted my edits to files created by cloud-init to persist through reboots without having cloud-init resetting them
[17:02] <blackboxsw> Right, my thoughts are I don't want cloud-init to do this by default because it's risky from the standpoint of someone using a system, and purging cloud-init, and expecting it to keep working. The removal of something as critical as the current network configuration is more likely to lead people down a path than leaving it in place.
[17:03] <blackboxsw> sdeziel: ok that is a good perspective to have here, thanks. As someone can certainly be sure if cloud-init is purged it's not going to do anything funky on later boots.
[17:04] <sdeziel> blackboxsw: and in those cases, I appreciated the fact that artifacts stayed after the purge ;)
[18:23] <blackboxsw> .... and it's hard to discover the  `sudo touch /etc/cloud/cloud-init.disabled` or other mechanisms to disable cloud-init across reboots. So someone would certainly be sure if cloud-init was no longer there.
[18:58] <kanashiro> ahasenack, thanks for the reminder about the yubikey, I just sent an email requesting that
[18:58] <ahasenack> \o/
[18:59] <kanashiro> ahasenack, the one you got is Yubikey version 4, USB A ?
[19:00] <patdk-lap> I have v4 and v5, really like v5 a lot
[19:00] <ahasenack> no, version 5, NFC, usb-c
[19:00] <ahasenack> yeah, grab v5
[19:00] <patdk-lap> if you don't need nfc/cellphone usage of it, v4 is fine
[19:00] <ahasenack> v4 has no FIDO2 support
[19:00] <ahasenack> nfc is not needed, I think there are 5s without nfc
[19:00] <patdk-lap> oh? I must have forgot about fido2
[19:00] <ahasenack> fido (1) is supported by 4
[19:01] <ahasenack> here in Brazil the 5C/NFC costed me about €90
[19:01] <patdk-lap> no idea about brazil, but I know india has some insane import taxes around well, importing anything, expecially IT
[19:02] <ahasenack> yeah, here it's 60%, including shipping costs
[19:03] <ahasenack> so if the key costs, say, U$ 50, and U$ 20 for shipping, amounting to U$ 70, you pay 70*1.6
[19:05] <sarnold> *ouch*
[19:06] <andol> https://www.yubico.com/support/shipping-and-buying-information/resellers/ might be an option, in regards to shipping costs, etc.
[19:08] <ahasenack> oh, good to know, https://kriptobr.com/ actually has good prices
[19:09] <patdk-lap> hmm, that is worse than india, 42% including shipping
[19:09] <ahasenack> about the same price I got mine from somewhere else, via amazon.com.br
[19:09] <patdk-lap> don't really get why shipping is included, other than the ovious one
[19:09] <ahasenack> https://kriptobr.com/produto/yubikey-5cnfc-2fa-fido-fido2/ is the one I got, I paid R$ 464,00
[19:10] <patdk-lap> https://kriptobr.com/produto/yubikey5c/
[19:10] <patdk-lap> the ones I use
[21:10] <sergiodj> ahasenack: thanks for the pointer.  today's been crazy, but I will send an email about the yubikeys for sure