=== tds5 is now known as tds
[02:20] <lotuspsychje> good morning
[06:17] <ducasse> good morning
[13:20] <lotuspsychje> hey eddvrs
[13:21] <eddvrs> hey
[13:21] <lotuspsychje> ubuntulog2: 16.04 is still cared off, think ESM will also be a fact after eol so..
[13:21] <lotuspsychje> ubusr: ^
[13:22] <ubusr> lotuspsychje: https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1864766
[13:22] <ubusr> that bit me hard on my 16.04 CI servers.... the bug it already 4 month old (altough the report + fix isn't)
[13:23] <lotuspsychje> ubusr: bug shows fixed and it isnt?
[13:24] <ubusr> where do you see it's fixed ? It says xenial - in progress
[13:24] <lotuspsychje> right
[13:25] <ubusr> maybe, one day... It cause me and others to move to 18.04
[13:26] <tomreyn> ubusr: so most of the people in #ubuntu and here, too, are volunteers. it's quite unlikley that one of us is involved with SRUs.
[13:26] <ubusr> and to think about not depending on system python for our stuff
[13:26] <tomreyn> as such, there's nothing any of us can do about it
[13:27] <lotuspsychje> unless find more users to get the bug affected, and turn up the heat on it a bit
[13:27] <ubusr> it's ok, it's nothing personal, just hope that people see that LTS isn't always mean supported
[13:27] <tomreyn> i *assume* that if yo have a commercial support contract already you may have a better leverage on increasing its priority.
[13:27] <lotuspsychje> ubusr: we cant generalize statements like 1 bug affecting = the same as 'not supported'
[13:28] <lotuspsychje> the community and the devs do what they can, but you as user can also influence your own bug
[13:29] <tomreyn> well in this case i don't think the reporter could do more than they already did really
[13:29] <lotuspsychje> he could talk to people about it, find other users affected?
[13:29] <lotuspsychje> maybe rbasak might know more after poking around?
[13:29] <tomreyn> yes, this is true. shouldn't be neede,d though
[13:30] <tomreyn> patches were provided, SRU process initiated, it's probably just a matter of "when someone gets to it"
[13:30] <tomreyn> and they'll have been busy with the release
[13:30] <lotuspsychje> agree
[13:31] <daftykins> there must always be things that slip between the dates of development
[13:31] <daftykins> what makes more sense, the easier path of moving to a release where things work, or fighting for change? :)
[13:34] <lotuspsychje> xenial still goes a while though, and when the user would choose to esm, things might still be worth to solve
[13:35] <ubusr> I am really intrigued by how come not so many people have complaint on this
[13:36] <lotuspsychje> thats why i think you should find more heat on your bug
[13:37] <tomreyn> i guess in long term support environments they don't use pip to manage libraries but install (and craft, if needed) debian packages
[13:38] <ubusr> tried, but besides people I know who got it too (and they all moved to 18.04 cause of it)...
[13:38] <tomreyn> if you manage libraries with pip you're basically outside of the supported area
[13:38] <ubusr> tomreyn: this is for using virtualenv so you aren't depnent on debian packages
[13:38] <ubusr> tomreyn: in python people usually do a virtualenv, and there they update pip
[13:38] <ubusr> but you can't setup a virtualenv anymore on system 16.04 ...
[13:40] <tomreyn> so you're saying that if you installed a fresh ubuntu 16.04 release, never used pip, and installed virtualenv and started it it would fail?
[13:40] <ubusr> isn't that whats written tehre ?
[13:40] <tomreyn> hmm i guess there is no "python-virtualenv" package in 16.04
[13:41] <ubusr> ofcourse there is
[13:41] <tomreyn> i see, "virtualenv"
[13:43] <tomreyn> hmm the "virtualenv" package in xenial depends on "python3-virtualenv" though
[13:44] <ubusr> tomreyn: check the docker output there https://github.com/pypa/packaging-problems/issues/325
[13:44] <ubusr> there is (or was) a python-virtualenv package
[13:44] <tomreyn> and there actually is "python-virtualenv" in xenial (not sure why rmadison wouldn't show this earlier): https://packages.ubuntu.com/xenial-updates/python-virtualenv
[13:46] <tomreyn> but this does not provide the "virtualenv" command
[13:46] <lotuspsychje> ubusr: could you also apport-collect 1864766 on your bug please?
[13:46] <tomreyn> just *suggests* "virtualenv", which is python 3 virtualenv
[13:47] <tomreyn> so i guess python 2 virtualenv can't be run on xubuntu in a supported way at this time (but it probably was possible in the past, although i'm not 100% certian there).
[13:48] <tomreyn> all of these packages are in universe, though, which means they got nothing other than coimmunity support anyways
[13:48] <tomreyn> ubusr: ^ might be relevant
[13:48] <tomreyn> "all of those" -> https://packages.ubuntu.com/search?keywords=virtualenv
[13:49] <tomreyn> it probably also explains the turnaround time for your SRU
[13:50] <daftykins> lotuspsychje: ESM is for those with £££ so a bit different :P
[13:51] <lotuspsychje> daftykins: i know, i just kind of understand his point of being an LTS and not working
[13:54] <tomreyn> not a valid point for universe, esm has no universe anyways
[13:55] <daftykins> ah ha
[13:55] <daftykins> i don't do anything with python really, so can't comment on this one
[13:56] <lotuspsychje> ah
[13:57] <lotuspsychje> ok so this might be a case then as daftykins points, the time this bug gets solved, its time to move to a working version?
[14:02] <tomreyn> https://wiki.ubuntu.com/SecurityTeam/ESM/14.04#Maintained_Packages
[14:03] <tomreyn> therE's no list for 16.04, yes, but i guess it'll be missing (python-)virtualenv and python-pip as well
[14:03] <tomreyn> *yeT
[14:18] <bertand> guys can anyone tell me what is this chanserv and whats its purpose? I can understand why nickserv is there but not chanserve
[14:19] <lotuspsychje> bertand: chanserv is a service running to handle things on the ircd network
[14:20] <lotuspsychje> bertand: /query chanserv and type help to know more of it
[14:20] <daftykins> that'd be a topic for #freenode
[14:20] <bertand> lotuspsychje: thanks for letting me know that
=== kostkon_ is now known as kostkon
[17:08] <lotuspsychje> there are 5 known nvidia bugs for 20.04 on the releasenotes, ive added 1 bug #1845801 to the ubuntu-discuss bug team https://bugs.launchpad.net/~ubuntu-discuss
[17:09] <lotuspsychje> the nvidia/autologin bug
[19:01] <ubusr> didn't nvidia promise open source linux drivers @ start of 2020 ?
[19:11] <daftykins> couldn't care less, theirs at least work - AMD have amdgpu but it's far from functional
[19:15] <joelcrump> i'm reluctant to blame NVIDIA for wanting to keep their official drivers proprietary, certainly it's not ideal in the abstract, but in practice they may have their reasons.. i bought an NVIDIA card because at the time i'd been led to believe they were better for linux, and i knew the day might come when i'd want to run it.. nearly a decade later the situation seems a bit different,
[19:15] <joelcrump> but like you said at least it works
[19:17] <daftykins> i'd say it's still well and truly the best for use, i don't see any drama with use
[19:17] <joelcrump> cool, i feel good about what i chose then
[19:20] <daftykins> really depends what you use it for and which it is
[19:21] <joelcrump> GTX 460
[19:21] <daftykins> ok that's quite the museum piece
[19:21] <joelcrump> still works great
[19:23] <daftykins> for drawing the desktop i suppose
[19:23] <joelcrump> if you're talking about gaming i don't do that
[19:25] <daftykins> that doesn't really leave anything left for why to have a discrete card
[19:25] <joelcrump> well my motherboard doesn't actually have integrated video
[19:25] <joelcrump> and i wanted all the outputs that this zotac implementation had
[19:27] <daftykins> yeah probably more a sign of the time, pretty much anything can do triple head output now
[19:27] <daftykins> something that old probably even works fine from nouveau though :D
[19:29] <joelcrump> oh it does, i ran a different distro for a while last year that didn't offer the proprietary driver, but the problem was i couldn't watch youtube with firefox, i had to install chrome for that one site
[19:31] <daftykins> that doesn't make an awful lot of sense
[19:32] <daftykins> what distro can't use their binary package?
[19:32] <joelcrump> it was fedora
[19:33] <daftykins> yeah so that absolutely does have support
[19:37] <joelcrump> i guess i missed it if so
[19:38] <joelcrump> i seem to remember trying to use it and running into some issue but my memory is fuzzy on that
[19:40] <daftykins> it's a bit of a joke as you have to add this rpm repo to do it the easiest way
[19:40] <daftykins> rpmfusion i think they call it
[19:40] <joelcrump> ahh
[19:41] <daftykins> getting the nvidia binary leads you to this funny situation where you have to boot with nouveau blacklisted to install, else it won't run - but often you can't even get a shell when booted without nouveau on an unsupported modern card, so you're blocked xD
[19:42] <joelcrump> ouch
[19:53] <tomreyn> daftykins: i've been using amdgpu with an rx580 for ~ 2 years without any issues now. but i agree there are problems with the recent ones, and those chips when they switch from radeon to amdgpu.
[19:54] <tomreyn> *switched
[19:56] <daftykins> weren't they struggling with quite the basic of HDMI audio for a very long time?
[19:58] <tomreyn> hmm, i think this was a lacking feature in all open source drivers for a while. to me this never was a required feature for a graphis card. but i think DP worked earlier, and that's what i'm using there.
[19:59] <daftykins> audio via displayport? weird one :D
[20:00] <tomreyn> i rarely use it, my monitors' audio is not very good.
[20:00] <daftykins> i was gonna say :)
[20:02] <tomreyn> :)
=== akem_ is now known as akem
=== katnip is now known as yarddog
=== yarddog is now known as Guest20677
=== Guest20677 is now known as katnip