[02:48] good morning [03:35] lotuspsychje: Your call made it into UWN: https://docs.google.com/document/d/18ZbtFHQq6uMj7iuRLd11VH8V5Uc_FA0IfgiRUcbMbQk/edit :) Good as is ? [03:38] looking great Bashing-om thank you, and tnx to guiverc perfectizing it, go for it! [03:40] lotuspsychje: We spread our word :P [03:41] +1 [04:19] i just refined that summary (I was distracted when written by wanting to refine the source (2nd time that issue!)) [07:04] good morning [11:18] hey TJ- [11:20] g'morning (just) [11:37] mgedmin: i reworked my dock bug a bit; bug #1902367 [11:37] bug 1902367 in gnome-shell-extension-ubuntu-dock (Ubuntu) "Dock does not allow icons drag on free space" [Undecided,New] https://launchpad.net/bugs/1902367 [11:40] TJ-: checkout the nice wiki daniel edited for us, pre bug team in #ubuntu-bugs-announce https://wiki.ubuntu.com/Bugs/Responses [11:41] I alreayd see a bug in the bug responses :D [11:42] "1. Hold Right-Shift during Grub boot delay to access the boot menu. " --- not on UEFI [11:42] lol, shoot [11:43] yeah [11:43] Also, just noticed a GDPR issue [11:44] what about [11:44] "Missing a crash report or having a .crash attachment" --> "...content of file /var/lib/whoopsie/whoopsie-id ..." -> on mine includes my name@hostname [11:45] but, so far as I've seen, there is no GDPR notice on submitting bugs using ubuntu-bug or others [11:45] it's definitely PII [11:46] gdpr is such a cashmule TJ- [11:46] not really; it's just about respecting and informing people and getting their permission [11:46] during corona a lot of restaurant & pubs have an oopen book register, where any customer can just browse all the previous users [11:47] how does that fit in gdpr [11:47] User jack@somedomain might report bugs in a series of programs and upload crash reports that, combined, can easily identify both him and the things he does and uses [11:47] lotuspsychje: here in the UK the law was amended to allow it [11:48] TJ-: allow open registers? [11:48] TJ-: agree on crash bugs can reveal sensitive info [11:49] thought ive readed something in the future would be edited in dmesg to not reveal sensitive info [11:51] https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-20.10-dmesg-Needs-Root [11:51] didnt test it yet on 20.10 [11:53] i've rarely seen sensitive info in kernel log [11:54] that's usually in system service logs, like NetworkManager [11:56] yeah [11:59] I got the impression the "sensitive info" is kernel addresses that could help malware defat KASLR [12:01] that'd make more sense [15:13] join #ubuntu-offtopic [15:24] the trolls methods, hunt old askubuntu threads and ask them in #ubuntu :p [15:28] Sounds like spammers on ubuntuforums.org === WanderingLich is now known as Wanderer [17:26] hi I solved my problem.. [17:26] A divorce fixed it? [17:27] I found my March 2020 backup [17:27] I divorced from my fresh install [17:27] unpacked my tar.xz file and did an upgrade to 20.04 [17:29] now I have my unmerged lib+bin usr/lib+bin folders [17:35] what was your problem with the merged /usr? [19:53] that's a secret, and it will always remain that. [19:53] right, lapion? [19:55] The binaries and libraries in the root fs meant for system maintenance and should be universal for the platform [19:56] One should be able to create a root filesystem that has a remote /usr mount that only gets mounted upon necessity [19:57] lol [19:58] ah, arbitrary abstract principles rather than an actual problem [19:58] so upgrades don't go too well when you break the OS to begin huh? who knew!? [19:58] (initramfs should be able to mount both / and /usr) [20:03] Besides athat a system running in maintenance mode should be able to be limited to maintenance binaries [20:04] it's not possible to do that if all binaries are linked into the same dirs as the root bin/lib dirs [20:13] the recovery system works fine, as far as i know [20:13] busybox, too