[00:10] kyrofa: regrettably yes [00:12] kyrofa: but afk for a bit, so I'll reply async if you ask a followup question :) [00:14] pity it wasn't pre-followed-up :) [00:22] can someone remind how dput > launchpad PPA does auth? I have it working here but its been so long since I configured it I'm struggling to figure out where the client gets the auth? is 'sftp' method using the SSH local id_rsa ? [00:26] TJ-: that's correct [00:29] tyhicks: thanks; can't find that spelled out anywhere on the LP Help PPA pages :) [00:29] tyhicks: needing to move the config/keys to another system and didn't know what is needed [00:52] TJ-: Although, the only reasons to use the sftp method are either Very Broken Networks, or because you're uploading Very Private Bits. [00:52] (or cause you're weird and like things to be slow, I guess) [00:54] I never found ftp package uploads to be all that quick :) [00:55] infinity: I'm just moving a config that I've had for years [01:42] vorlon, just installed 18.04 on a new XPS 13, checking the "please install updates" box. It surprised me by asking for a password, but nicely explained that it was because I had secure boot enabled and it would be required on the next boot to ensure components were authorized. Sure enough, mokmanager showed up on the next boot, but it was entire unclear what I was supposed to do. There were a few options, the first being "boot now" and the [01:42] second being something like "enroll a key". The others looked less valid. I wasn't interested in enrolling a key, so I said "boot now" and no password was prompted. I later found https://wiki.ubuntu.com/UEFI/SecureBoot which implies that I should have enrolled a key [01:42] I don't seem to be missing functionality, but now it's nagging at me. Rod filled me in on how it works, but he wasn't sure how the installer was getting the key into mokmanager so he wasn't sure if it was recoverable [01:44] The way the installer made it sound, I was just expecting a simple "Hey yo, you installed new stuff, enter the password you used" and I'd be off to the races. Is there a reason it needs to be more complicated than that? [05:27] kyrofa: The reason it needs to be more complicated is because userspace can't write to your firmware's key databases, all it can do it queue up a request to enroll a key and let mokmanager DTRT on reboot. [05:27] kyrofa: There's no reason, however, for it to be as confusing as it is, except that mokmanager's UX was designed by someone who lives in 1972, apparently. [06:24] I don't want to ask this in the main channel cause it's somewhat sensitive. I accidentally pastbinned a file that contains some perosonal info I dont' want out. Address, phone number, etc. Is there any way to remove a pastbinit once it's been created? [06:25] Is this information still relevant? https://askubuntu.com/a/406279 [06:40] I've gone ahead and changed the ip of the compromised mahcine and reconfigured. I would still like to see if I can get that paste deleted. Thanks [11:48] hi folks [11:49] anyone know why libleveldb1v5 was removed from repos ??? [11:53] https://packages.ubuntu.com/search?keywords=libleveldb1v5 https://packages.debian.org/search?keywords=libleveldb1v5 [11:53] tenplus1: what version of Ubuntu? [11:53] soryr, am on 19.10 and wondering why it was missing... couldn't install something [11:54] I had to download it from an earlier release to get things working... just found it weird... (was installing Minetest 5.0.1, repo is outdated with 0.4.16) [11:55] https://flossexperiences.wordpress.com/2018/04/19/getting-libleveldb1v5-fixed/ -> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877773 [11:55] Debian bug 877773 in src:leveldb "libleveldb1v5: breaks ABI without SONAME bump" [Grave,Fixed] [11:56] fixed by removal, ouch! [11:57] 19.10 is not out yet. https://launchpad.net/ubuntu/disco/+package/libleveldb1v5 it is in 19.04 [11:58] true, am testing it out for now... was hoping someone in here would have an answer :P [12:01] thanks for the help :P [12:12] The newest version of the source package builds libleveldb1d instead, and packages that depend on it should migrate [12:13] Not fixed by removal, fixed by rename === ricab is now known as ricab|lunch === tmhoang_ is now known as tmhoang === ricab|lunch is now known as ricab [20:55] is it ok to use this style of globbing in postrm to remove the logs when purging the package? rm -f /var/log/foo.log* [20:55] I expect it to purge foo.log, foo.log.1, foo.log.2.gz, etc [20:55] or even just foo.log.2, if the admin changed the config to not gzip [20:55] but I wonder if someone would ever save backups there like /var/log/foo.1.bak and expect them to remain [20:57] I'm not sure there's a strong precedent one way or the other [21:05] I checked some packages, heimdal-kdc does that. Many others have their own log directory, but also just remove everything [21:05] I'll do it this way for now [21:11] ahasenack: certainly sounds ok to me [21:11] cool