[00:08] <Guma> Ok looks good. Was able to boot and login fine. Is it recommended to install guest tools or some specific packages at this stage to have higher resolution?
[00:39] <Guma> Ok guest tools installed fine and everything so far look ok.
[00:51] <Guma> Also I had to give 128M Video RAM to run full desktop window. Anything smaller it creates black screen. As soon resize smaller video does come back
[00:52] <Guma> I have also 16.04 and 18.04 and and I did not had to allocate that much
[00:52] <Guma> I can pastebin dmsg
[02:13] <AlexMax> tomreyn: I can _see_ the setting for fractional scaling in desktop settings, it's just that it doesn't actually do anything
[02:13] <AlexMax> in wayland
[03:01] <lotuspsychje> good morning
[06:25] <CarlFK> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1873526  
[06:25] <CarlFK> syslog shows [    0.933729] r8169 0000:01:00.0: realtek.ko not loaded, maybe it needs to be added to initramfs?
[06:30] <CarlFK> lsmod | grep realtek ... realtek                24576  0
[06:31] <CarlFK> lsmod | grep r8169 ... r8169                  90112  0
[06:31] <CarlFK> anyone wanna take a shot at getting my wireed nic up?
[09:34] <tomreyn> CarlFK: most likely unrelated, but you should consider a bios upgrade (may require windows): https://support.hp.com/gb-en/drivers/selfservice/swdetails/hp-15-ay000-notebook-pc-series/10862300/model/11926583/swItemId/ob-245386-1?sku=X0S24UA
[09:35] <tomreyn> you're currently on F.36 from 12/18/2014
[09:36] <tomreyn> hmm, this doesn't match the revision history. maybe i looked up the wrong model / series? "HP Notebook - 15-ay012dx" (X0S24UA)
[09:38] <tomreyn> actually you're on F.04 from 04/14/2016 - i mixed it up with the other report on this issue.
[09:38] <tomreyn> and that matches the dates. and the link i posted should be correct
[09:39] <tomreyn> about the kernel module not loading, check whether or not it's included in the initrd using the lsinitramfs command
[09:40] <tomreyn> (or unmkinitramfs for further inspection)
[09:41] <tomreyn> AlexMax: hmm, well, that's all i could think of really... i assume you don't have nvidia graphics since then i shouldn't have worked on fedora either.
[09:44] <CarlFK> tomreyn: welp, this isn't it: lsinitramfs /boot/initrd.img-5.4.0-24-generic | grep realtek ... usr/lib/modules/5.4.0-24-generic/kernel/drivers/net/phy/realtek.ko
[09:45] <mifritscher> öh, why is bower packaged as a snap, while it is not sandboxed?!
[09:46] <tomreyn> CarlFK: and what happens when you try to modprobe it?
[09:46] <tomreyn> modprobe -v
[09:49] <CarlFK> tomreyn:  sudo modprobe -v realtek ... nothing. 
[09:49] <CarlFK> tomreyn: but somehow it is already loaded:
[09:49] <CarlFK> lsmod | grep realtek ... realtek                24576  0
[09:49] <nonix4> "The following package was automatically installed and is no longer required: ubuntu-system-service" <-- what was that?
[09:52] <tomreyn> r8169 would be the relevant module
[09:52] <tomreyn> does it say "Possible missing firmware" on your dmesg / journal / syslog?
[09:56] <tomreyn> hmm no probably not a firmware issue, this is an old nic
[10:03] <CarlFK> lsmod | grep r8169 ... r8169                  90112  0
[10:03] <CarlFK> worked in cosmic 
[10:04] <CarlFK> still does - box duel boots cosmic/focal
[10:04] <CarlFK> oh this the wired problem.  which only stoppled working in focal in the last few days 
[10:05] <CarlFK> worked in 5.4.0-21
[10:08] <AlexC> hi
[10:08] <AlexC> Do you guys have any news regarding zfs on root install with 20.04 yet?
[10:08] <AlexC> i was trying to install focal fossa server but didn't find the option in the installer
[10:20] <tomreyn> CarlFK: if you search the web for linux 5.4 and r8169 you'll note it appears to be a generic issue with the later 5.4.x kernel versions. likely a regression.
[10:39] <CarlFK> tomreyn: if you found any good links, URLs in the bug report please 
[11:56] <lotuspsychje> skookum: toggle 'natural scrolling'
[11:56] <skookum> on or off ?
[11:56] <lotuspsychje> skookum: the setting suits you
[11:58] <skookum> I guess that was it. That must be a new default setting though because I don't recall changing that on any other LTS
[11:58] <skookum> It was like driving on the wrong side of the street :)
[11:59] <lotuspsychje> i always scroll at the side, dont like that 2 finger scrolling
[12:01] <skookum> My work laptop that I am using while WFH has neither I have to click and drag the scroll bar, what a pain!
[14:00] <pavlushka> https://unix.stackexchange.com/questions/579472/apt-cacher-ng-is-having-some-issues-with-replying-to-sudo-apt-update-from-ubun
[14:00] <pavlushka> on 20.04
[14:22] <Ussat> So, I am either really doin something wrong, or well, doing something wrong. I was planning to do some testing this am of 20.04 and installed it in a VMware Fusion VM, 50G HD, and when I chose entire disk LVM, it went on to install, but a reboot and login only showed 5G.... did I miss something obvious ? This has never happened before on 16.04, 18.04 
[14:24] <oerheks> vmware .. does it gave the option auto-grow or something like that?
[14:24] <oerheks> maybe that does not work well with lvm
[14:26] <Ussat> Never had this issue before
[14:26] <Ussat> I mean it doesnt need to grow, I tell it it is 50g
[14:27] <oerheks> write a file of 1gb to it, what happens?
[14:29] <Ussat> it creats a 1GB file
[14:30] <Ussat> this is, weird
[14:30] <oerheks> :)
[14:30] <Ussat> Yup, as I thought, try to create a 6G file and not enough space
[14:30] <Ussat> it did not put all 50GB in the VG
[14:31] <Ussat> doesnt even see it
[14:33] <Ussat> https://pastebin.com/j5i78zT7
[14:40] <Ussat> I am trying with pre-allocating, but, if this works, this is a problem, I cant pre-allocate everything
[14:45] <Ussat> OK, interesting it doesnt automatically assign the space, need to manually assign it....huh
[14:54] <Ussat> if you choose NOT to set it up as a LV it seems to work correct, assigning space as it should
[15:22] <tomreyn> Allocating just 4 GB to / (on top of a larger LVM VG) has been a default for ubuntu server since 18.04 LTS. It's on prupose and makes sense since growing is always possible, even online (with ext4), whereas shrinking can be more cumbersome.
[15:53] <tomreyn> https://wiki.ubuntu.com/FocalFossa/ReleaseSchedule does say "April 16th" "ReleaseCandidate"
[15:54] <oerheks> ohhh, that is why i could not spot them..
[15:54] <oerheks> During the week leading up to the final release, the images produced are all considered release candidates
[15:54] <oerheks> confusing
[17:19] <pavlushka> does anyone can hint me what is happening here, https://unix.stackexchange.com/questions/579472/apt-cacher-ng-is-having-some-issues-with-replying-to-sudo-apt-update-from-ubun
[17:19] <pavlushka> *can anyone
[17:21] <oerheks> pavlushka, installed auto-apt-proxy and squid-deb-proxy-client too ??
[17:21] <oerheks> https://wiki.debian.org/AptCacherNg
[17:22] <pavlushka> oerheks: not auto-apt-proxy, only squid-deb-proxy-client
[17:25] <Ussat> So, earlier today I ran into an issue that I thought was fairly.....unique. Normally, like in 18.04 when I selected use entire disk as LVM, It would auto set up partitio0ns etc, but it would use the whole disk. When I chosew that same option in 20.04 RC, it did NOT. after a few more install runs to see what was going on, I determined if I chose NOT to use a LVM it would use the entire disk, but not in a LVM, is this the new expected behavior ?
[17:25] <Ussat> if its not expected....its...a issue
[17:25] <oerheks> Ussat, on vmware, right?
[17:26] <Ussat> Correct
[17:26] <Ussat> butit DID work as expected in 16.04 and 18.04
[17:26] <oerheks> i cannot test this here :-(
[17:27] <Ussat> ok
[17:27] <Ussat> It was reproduceable every time
[17:27] <Ussat> I do not know it is isolated to a vmware hypervisor
[17:28] <Ussat> also, this was under fusion on my mac, I could test it under player on my pc, but I expect the same thing
[17:28] <Ussat> They use the same hypervisor engine
[17:33] <Ussat> I am going to build in vmware player to test it there
[17:52] <iconoclasthero> hello, the low-latency kernel that was installed by default will not boot.  should I file this as a bug?
[18:07] <Ussat> I am building a VM in player now to check if it still happens
[18:20] <Ussat> same issue on vmware player, guess I will try in vbox, I suspect the same
[18:33] <Ussat> Well, cionfirmed, this happens on every hypervisor I have tested, I dont have a physical system to test with here
[18:46] <oerheks> iconoclasthero, on what ubuntu version, studio?
[18:46] <iconoclasthero> no...  just yesterday's daily.
[18:46] <iconoclasthero> the date on it is 2020.01.17 @ 08:22
[18:47] <iconoclasthero> "focal-desktop-amd64.iso"
[18:48] <Ussat> so I am trying to dig up an old system to try this on a physical system, but I dont think it happens there
[18:49] <Ussat> This is the server iso dfrom http://releases.ubuntu.com/20.04/
[18:49] <Ussat> Is there a more recent iso I can test this on ?
[18:49] <oerheks> oh, ii knew ubuntu-studio uses the lowlatencey kernel, not regular gnome desktop
[18:50] <oerheks> Ussat, daily http://cdimage.ubuntu.com/daily-live/current/
[18:51] <Ussat> I looked there but all I see are desktop
[18:51] <Ussat> and they have a GUI based installer
[18:52] <Ussat> I suspect they may work, but I want to test the server iso's
[18:52] <oerheks> oops, wrong url > http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/
[18:52] <chudak> hi all, this must be easy, but I lost the option to "Always on Visible Workspace" on windows located on 2d and 3d screen, any clues appreciated
[18:52] <chudak> where can it be set ?  I am on 20.04
[18:52] <chudak> I used to have this available on all monitors and now only on primary :(
[18:52] <Ussat> Thanks :)
[18:54] <Ussat> I will give yesterdays spin a test
[18:54] <iconoclasthero> well in the advanced options for focal, it has 
[18:54] <iconoclasthero> ubuntu
[18:54] <iconoclasthero> ubuntu low-latency
[18:54] <iconoclasthero> ubuntu low-latency recovery
[18:54] <iconoclasthero> ubuntu whatever the normal kernel is
[18:55] <iconoclasthero> and then the recovery for that one.  the first two do not boot.  i assume the 3rd doesn't.  the 4th does, the 5th does not.
[18:55] <iconoclasthero> i.e., the 5th being the recovery for whatever kernel i'm in now
[18:55] <iconoclasthero> 5.4.0-24-generic #28-Ubuntu
[19:20] <howarth> Woohoo
[19:20] <howarth> Solved the nvidia/autologin hangs on my machine
[19:20] <Ussat> looks like yesterdays server spin also has the same issue
[19:20] <howarth> https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1845801/comments/69
[19:20] <Ussat> I wonder if the desktop spins have it also
[19:21] <Ussat> guess I will try than next
[19:21] <howarth> Preventing the nvidia module from loading too earlier via initrd.img is the trick to getting autologin to work under those drivers
[19:22] <Ussat> sigh
[19:22] <howarth> I am pretty sure the folks who didn't have the removal of 'splash' from grub.cfg's GRUB_CMDLINE_LINUX_DEFAULT working for them just failed to rebuild the initrd.img
[19:23] <albert23> Ussat: did you see this? (05:22:07 PM) tom reyn: Allocating just 4 GB to / (on top of a larger LVM VG) has been a default for ubuntu server since 18.04 LTS. It's on prupose and makes sense since growing is always possible, even online (with ext4), whereas shrinking can be more cumbersome.
[19:23] <howarth> Ubuntu just needs to enhance the nvidia packaging to automatically prune 'splash' from  GRUB_CMDLINE_LINUX_DEFAULT prior to rebuilding the nvidia kernel modules
[19:27] <Ussat> albert23, um......when I build a 18.04 and tell it to use everything, it does, not the default 4
[19:27] <Ussat> I have a fresh 18.04 here
[19:28] <Ussat> and it allocated everything, not just 4G
[19:29] <albert23> Is it the same installer? new live server versus old debian installer?
[19:30] <Ussat> the 18.04 is the installer it comes with, there was no "new or old"
[19:30] <Ussat> the 20.04 it happens with both
[19:31] <Ussat> I mean I can spin a new 18.04 now and I know it will allocate all of it
[19:43] <Ussat> albert23,   https://imgur.com/a/CAAx65S
[19:43] <Ussat> brand new spin up just now
[19:43] <tomreyn> maybe a misunderstanding - the major part of the storage media should be assigned to the LVM PV, but only 4 GB should be assigned to the LV which contains / by subiquity, using automated partitioning.
[19:43] <tomreyn> loading screenshot
[19:44] <Ussat> Let me now spin a 20.04 and post the screen
[19:45] <tomreyn> so the screenshot shows a different behaviour than i described above.
[19:45] <Ussat> Yes, that is a brand new 18.04
[19:45] <tomreyn> all available space was assigned to /
[19:45] <Ussat> all I did was choose lvm, full disk, guided
[19:45] <albert23> I just tried a bionic live installer from January 2019, that creates a 4GB LV by default
[19:46] <Ussat> Right
[19:46] <tomreyn> hmm, maybe the behaviour was changed in recent subiquity builds due to users ywlling "you ate my space!"
[19:47] <Ussat> but IMHO, requesting a FULL disk use on a LVM, should use the full disk
[19:47] <Ussat> I mean...full ?
[19:48] <tomreyn> is the disk larger than 50 GB then?
[19:48] <Ussat> No, I choose a 50GB disk in vmware
[19:49] <Ussat> https://imgur.com/a/YvKN0xS
[19:49] <tomreyn> and all of its partitionable space was assigned to a partition, then all of that space usable by an LVM PV was assigned to an LVM PV, and then all space usable by an LV was assigned to an LV, and then a file system using as much space as it could was created on top of that.
[19:50] <tomreyn> so, looks fine to me
[19:50] <Ussat> Right, I agree, but 20.04 does not do that
[19:50] <tomreyn> i see, trying to load this screenshot but level 3 is broken tonight apparently
[19:51] <TJ-> isn't it more nuanced? it depends on how larger the target device is? below a certain size it uses 100% ?
[19:51] <tomreyn> i don't see a problem on your screenshot, what are oyu trying to say?
[19:52] <Ussat> That screenshot is fine, BUT 20.04 doesnt allocate that way, it only allocates 4G
[19:52] <Ussat> That was an example of 18.04, which is correc t
[19:52] <TJ-> Ussat: what size is the underlying block device?
[19:52] <Ussat> Let me spin a fresh 20.04 and post them also
[19:52] <Ussat> 50GB on both
[19:52] <Ussat> I used the exact same virtual HW on both
[19:53] <chudak> retrying - hi all, this must be easy, but I lost the option to "Always on Visible Workspace" on windows located on 2d and 3d screen, any clues appreciated
[20:10] <Ussat> OK, here is the difference:  https://imgur.com/a/9EOi2Xh
[20:11] <Ussat> the top image is 18.04, bottom 20.04. Exact same virtual HW,
[20:11] <Ussat> See the difference /
[20:12] <Ussat> If thats the default behavior in 20.04, thats fine, but I then think that saying full disk is a bit incorrect and should be changed
[20:13] <tomreyn> so this 20.04 behaves like what i expected 18.04 to behave like
[20:13] <tomreyn> but then you were using 18.04.1
[20:13] <tomreyn> not .4
[20:14] <Ussat> OK, so I am willing to bet 18.04 does the same, shall I get an 18.04 ?
[20:14] <tomreyn> i imagine this changed in between those two, likely between 18.04.2 and .3
[20:14] <Ussat> if it did, it was no where in the release notes
[20:15] <Ussat> because I have looked
[20:15] <tomreyn> in subiquity's?
[20:15] <Ussat> The other point I am making is that saying its a full disk guided install on a LVM when it isnt is...lacking
[20:16] <Ussat> When It says full, I dont know about you, but I expect full.
[20:16] <Ussat> if thats the default behavior NOW, thats finer
[20:16] <tomreyn> i mean snaps are not bound to releases, they can update randomly , so if you downloaded 18.04.4 and ran it weeka ago it may have behaved differently than yesterday
[20:16] <Ussat> what ? I would expect 18.04 to behave as 18.04
[20:17] <Ussat> who said anything about a snap ?
[20:17] <tomreyn> me, because we talked about subiquity
[20:17] <albert23> This is what bionic Jan 2019 says. I think that's quite clear. https://pasteboard.co/J4qsjQY.png
[20:18] <Ussat> so youre saying if I install a vanilla 18.04 today, no uupdates and in a month install a 18.04 to verify something,  they may be different ?
[20:19] <Ussat> so, the behavior changed
[20:19] <Ussat> thats fine
[20:19] <Ussat> I honestly dont remember seeing that screen in my latest run, I will look again
[20:20] <tomreyn> so subiquity is a snap, and snaps refresh by themselves, wehn they want, by default.
[20:21] <Ussat> On a production server, something refreshing itself......you dont have a problem with that ?
[20:21] <tomreyn> in some releases, subiquity has a mechanism allowing you to choose which version of it you want to run, and then it self-updates to that on demand. but it might (at least theoretically, not sure if practically) also update automatically when snapd does the refresh.
[20:21] <tomreyn> yes i have a problem with that.
[20:21] <Ussat> ok, whew
[20:22] <Ussat> Thats REALL unnerving to me, considering the environment I run these in
[20:22] <tomreyn> but then i'm not an ubuntu developer
[20:22] <Ussat> fair point
[20:22] <Ussat> Thats, just...wow
[20:22] <Ussat> ok, thank you for clarification
[20:22] <Ussat> is there anyway to default back to the sane, not have to use snaps
[20:23] <tomreyn> and just to make sure you're aware i'm possibly just spreading partial FUD: i have no knowledge of the above scenario i made up actually occurring.
[20:23] <tomreyn> you can install ubuntu 16.04 LTS
[20:23] <Ussat> or 18 :)
[20:24] <tomreyn> 18.04 LTS on a server if you purge snapd and don't need any of the snaps, such as lxd, yes
[20:25] <Ussat> Yes, I normally purge snaps
[20:25] <Ussat> and granted, the possibility of that happening is enough to make me really pause
[20:26] <tomreyn> pause... working with computers?
[20:26] <tomreyn> or this VM
[20:27] <Ussat> this VM
[20:27] <tomreyn> that should be safe :)
[20:27] <Ussat> The thought of something possibly self updating when it wants to, is not acceptable in this env
[20:27] <Ussat> not without me pounding it in test first
[20:28] <tomreyn> i haven't followed snapd developments lately, maybe they gave in to the demand to have it change its default behaviour there, yet
[20:29] <tomreyn> or, more likely, to allow to deviate from the default
[20:30] <tomreyn> but i haven't heard of that being possible as of yet
[20:31] <Ussat> well....hmm
[20:31] <Ussat> ok, well, thank you
[20:32] <tomreyn> https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707
[20:32] <tomreyn> if this reminds you of windows 10, then we have something in common
[20:38] <Ussat> um....well, I actually like windows 10, because it asks to reboot, that basically says, here we are restarting. and with that, I think I need to start reccomending something different than Ubuntu
[20:39] <Ussat> I manage a Unix team, a LOT of my systems run critical hardware, and well, hey here is an update, restarting...is NOT acceptable
[20:40] <Ussat> In healthcare that is NOT acceptable
[20:41] <TJ-> in healthcare, don't connect them to the Internet!
[20:43] <Ussat> I just cant imagine any server admin being ok with that, anywhere
[20:43] <TJ-> Don't we just love DevOps where Dev priorities overrule Ops?
[20:44] <Ussat> I mean in 18.04.X I currently rip out snaps post install
[20:44] <Ussat> I guess I cant test that in 20.04
[20:44] <Ussat> see what bitches at me
[20:45] <Ussat> TJ-, no, no we dont (OK I dont)
[20:46] <TJ-> Ussat: agree entirely; I rant about it constantly in the office; trying to make my people understand WE should have control not be dictated to by devs
[20:47] <Ussat> My fear...dev pushes a "change" to his snap to "fix" something, and breaks other shit....badly
[20:47] <Ussat> Welp, this is good info to know
[20:47] <Ussat> and gives me something to drink over....
[20:48] <TJ-> As time goes in I'm more inclined to think Ubuntu has been Borged --- I reported 2 bugs in weechat this week, added patches to fix them prior to release, one ia regression in python support, the other CVEs. Got a cryptic message I don't understand about Python and so far the CVE hasn't been acted on
[20:49] <TJ-> this is the response I don't get, from doko: ug #1866065
[20:49] <TJ-> this is the response I don't get, from doko: bug #1866065
[20:50] <Ussat> I dont know what is worse....RH *'s modukles or Ubuntu 20.04 and snaps
[20:50] <Ussat> RH 8's
 in healthcare, don't connect them to the Internet! <<-- If it were all that simple :)
[20:55] <TJ-> Ussat: I firewall/proxy ours so they cannot make unsolicited outgoing connections
[20:55] <Ussat> Yea..
[20:55] <TJ-> Ussat: I work with UK NHS systems
[20:56] <Ussat> ahh
[20:56] <Ussat> Guess this gives me something to think about :)
[20:57] <TJ-> Ussat: we have a local DNS resolver that redirects stuff like snap store to our own host which returns 404s
[20:57] <Ussat> NIce...
[20:57] <Ussat> Ya I guess me and network need to have a chat
[20:57] <housecat> ... am i reading correctly that the python plugin won't load on weechat in 20.04
[20:58] <housecat> because if so that's laughable and basically makes weechat unusable for moderately-advanced users
[20:58] <TJ-> housecat: Yes, and therefore no python scripts load
[20:58]  * housecat facepalms
[20:58] <TJ-> housecat: right - I can't make head nor tale of Doko's response either
[20:58] <housecat> i guess i'll need to recommend https://weechat.org/download/debian/ to people even more than i already do
[20:58] <TJ-> housecat: I backported FlashCode's fix for the python3.8 issue too
[20:59] <TJ-> housecat: right, it make 20.04 useless from the start
[20:59] <housecat> yep
[21:01] <tomreyn> it's in universe ;-)
[21:01] <tomreyn> (no i don't think this should cause patches not to be merged.)
[21:02] <TJ-> tomreyn: precisely; but its the reply I do not understand -- what does it mean!?
[21:02] <TJ-> makes no sense to me what was written
[21:02] <housecat> have you poked him about it?
[21:03] <Ussat> I am going to test doing sudo apt-get -y  autoremove --purge snapd on 20.04 and see what screams
[21:04] <tomreyn> i assume doko's statement is meant to provide some more understanding on the difficulties faced in packaging the software. i'm not sure it's meant to be a statement on how things will or should be handled.
[21:05] <TJ-> housecat: I've not crossed paths with him on IRC so far, but I posted a follow-up but no reply
[21:06] <TJ-> tomreyn: I don't know about that - he seems to be saying that weechat shouldn't be linking, or should, due to interpreters... but I have no idea
[21:06] <TJ-> i mean, I simply cherry-picked the upstream patch!
[21:17] <tomreyn> hmm, yes, it seems contradictory. but i don't know python3 or weechat well enough to comment.
[21:18] <TJ-> tomreyn: it cannot work without being linked to libpython3 ... the symbols aren't available as per the bug.
[21:19] <tomreyn> okay then their statement doesn't make sense to me either
[21:19] <TJ-> this stuff seems to be a creeping problem... I'm having to carry so many custom packages now (since 16.04) because they're not patching/fixing stuff
[21:19] <TJ-> annoying moreso because I spend the time debugging and creating a patch
[21:21] <TJ-> did you know apt-offline has been removed, too? i wonder if there's a replacement
[21:21] <tomreyn> offline is no longer relevant, we got the cloud nowadays!
[21:22] <tomreyn> i don't know of a replacement
[21:22] <TJ-> well, i saw it mentioned in xubuntu-devel but it still shows on my 20.04 system
[21:22] <tomreyn> so it's still there?
[21:23] <TJ-> Bug #1855621
[21:23] <DalekSec> Before, Xubuntu seeded it but now it does not.
[21:24] <TJ-> oh, is it Xubuntu specific? the texty makes it sound like its distro wide!
[21:24] <tomreyn> not installed by default on gnome or server, i think
[21:24] <oerheks> it is in universe? https://launchpad.net/ubuntu/focal/+source/apt-offline
[21:25] <TJ-> 'offline package management is pretty much broken as a paradigm ..."
[21:25] <TJ-> Guess these folks don't work in restricted networks or romaing in rural areas with lots of not-spots
[21:25] <tomreyn> see, i predicted so 4 minutes ago
[21:25] <DalekSec> Pretty sure before 1.8.2-1 it was rather broken, but now it works-ish.
[21:26] <TJ-> I've not seen any issues with it,I'll look at the bug report
[21:26] <TJ-> s
[21:26] <tomreyn> debian testing has 1.8.2, buster has none, but 1.8.2 is in buster-backports
[21:27] <tomreyn> so this seems to second what DalekSec says
[21:27] <DalekSec> There's a bug in Ubuntu too about it being entirely broken, which is pretty much why Xubuntu dropped it.
[21:27] <TJ-> ahhh my favourite python3 person! Bug #1848755
[21:31] <tomreyn> well this took 3.5 years to get fixed in debian. maybe it's just not so well supported upstream.
[21:32] <DalekSec> TJ-: FWIW, you'll see doko a lot since he does a lot of core lib stuff, eg gcc and did a lot of the python 3.7 → 3.8 migration.
[21:32] <TJ-> DalekSec: I'm aware
[21:32] <DalekSec> OK. :)
[21:32] <TJ-> DalekSec: I'm just wishing for less cryptic responses!
[21:32] <TJ-> it's not like python 2.7 has been dropped from 20.04 
[21:33] <DalekSec> 3.7 was
[21:33] <TJ-> right... for 3.8 :)
[21:34] <DalekSec> There was a fair amount to fix for that one too.
[21:35] <DalekSec> TJ-: You can thank housecat for https://launchpad.net/ubuntu/+source/weechat/2.6-2ubuntu2 too! :)
[21:36]  * housecat blush
[21:36] <TJ-> I had a weird issue with failing to bring up display on resume this week, had to hard reset a few times to recover. Did a diagnostic and discoaved a RAM issue. I'd installed 32GB when the laptop arrived. Looks like it had not quite seated and a few knocks had upset it. Opened it up and reseated Friday morning and so far so good... I was starting to suspect the Ryzen 7/Vega drivers
[21:36] <housecat> all i did was get out the poking stick :P
[21:36] <TJ-> housecat: those come in very handy!
[21:37] <TJ-> housecat: although I use a treadmill! when my folks aren't getting on with things I allocate them 15 minutes running on it to focus them!
[21:40] <DalekSec> (That might have been the latest upload I've ever done in a cycle..)
[21:43] <brunonzanette> Hello, folks! Did someone manage to make Nvidia driver to work on 20.04? My system is fully updated (including proposed) and the driver is listed as installed in driver manager, but it seems that it is not working
[21:44] <brunonzanette> I can't access nvidia full settings, on "about ubuntu" shows that it is using Intel's Mesa, and "nvidia-smi" doesn't work