[02:21] <tomreyn> So apparently there are no kernels nor initrd's on the live cds according to bug 1860495
[03:23] <lotuspsychje> good morning
[03:37] <peepsalot> I'm curious about how bug fixes are handled in older LTS releases such as 16.04, when the packages they use are considered not supported by their maintainers?  (for example Qt which seems to have a very aggressive end of support schedule https://en.wikipedia.org/wiki/Qt_version_history#Qt_5 )
[04:08] <lotuspsychje> !info software-properties-gtk eoan
[04:53] <guiverc> peepsalot, your question about fixes in older LTS releases will likely vary on packages; most of 16.04 LTS packages found in universe are no longer supported; so don't get fixes (eg. Kubuntu 16.04 LTS had 3 years of support as it was a flavor, it's eol like mate, lubuntu, xubuntu etc...)
[04:54] <guiverc> peepsalot, for 'main' packages, the fixes are backported to the package already in the older release; unless it's more work to backport than provide newer version...
[04:57] <peepsalot> guiverc: i'm specifically concerned about this issue: https://bugreports.qt.io/browse/QTBUG-55245#  kinda wondering if there's any chance it would get fixed in Qt 5.5.1 which is used by 16.04
[04:58] <peepsalot> or if I would have any better luck reporting through ubuntu than Qt directly?
[04:58] <guiverc> Kubuntu 16.04 LTS is EOL & thus doesn't get support; as I recall a single package was fixed post-EOL date (by a few days); but it was an exception.
[05:00] <guiverc> Kubuntu 16.04 LTS was released on 21st April 2016, and was supported for Kubuntu for a period of year 3 years.* Kubuntu 16.04 LTS support therefore ends 21st April 2019  https://kubuntu.org/news/trusty-14-04-lts-end-of-life-and-end-of-kubuntu-support-for-xenial-16-04-lts/
[05:00] <guiverc> I'm not aware of any Qt packages for 16.04 in 'main' (thus with 5 years of support)
[05:00] <peepsalot> guiverc: but qt5-default is part of xenial main as far as I understand, not just Kubuntu, and its supposed to be supported until Apr 2021?
[05:01] <guiverc> https://packages.ubuntu.com/xenial/qt5-default == universe
[05:01] <peepsalot> oh, oops
[05:02] <guiverc> if it's on your system, use `ubuntu-support-status` to inspect for packages installed on your system
[05:03] <peepsalot> i'm on mint 19.2, which is 18.04 based.  i'm just concerned because I work on a project which supports Ubuntu 16.04, and would really like that bug fix
[05:04] <peepsalot> hell, i'd really like it for 18.04 too, which isn't even out of support for Qt yet
[05:04] <peepsalot> Qt 5.9.5
[05:12] <peepsalot> guiverc: do you know what is policy for updating packages in universe then?  is there any chance it could be fixed for Qt 5.9.5, backported by ubuntu or something?
[05:13] <peepsalot> looks like ubuntu-support-status is part of update-manager-core package, not sure if installing that will interfere with default mint updater though, so not too keen on testing it
[05:19] <guiverc> I can't help with mint; I have no idea.
[05:24] <lotuspsychje> peepsalot: you should mention you are using mint at the beginning of your questions
[05:24] <lotuspsychje> peepsalot: mint has another support channel/server
[05:25] <peepsalot> i contribute to an open source packaage that supports ubuntu 16.04.  this isn't specifically about what my system is running
[05:25] <lotuspsychje> peepsalot: discussing here is allowed for everyone of course, but details 'can' matter when asking questions so volunteers can aid better
[05:26] <peepsalot> our CI servers run Ubuntu 16.04 and 18.04, among other OS
[05:26] <lotuspsychje> cool
[07:17] <ducasse> good morning
[07:25] <lordievader> Good morning
[12:32] <tomreyn> i spent 30 minutes yesterday ebcause i didn't remember what is the exact kernel command line option to boot into non-graphical multi-user mode. i was certain it'd start with either "systemd.target", "systemd-target", "x-systemd.target" or "x-systemd-target", and would be followed by one of "multi-user" or "multi-user.target"
[12:32] <tomreyn> turns out it is actually "systemd.unit=multi-user.target" :-/ we might want a factoid for this
[12:33] <lotuspsychje> !systemd
[12:33] <tomreyn> i haven't found the kernel parameters to be documented anywhere
[12:34] <tomreyn> or initrd parameters rather
[12:35] <lotuspsychje> tomreyn: alinea Adjusting the System State (Runlevel) with Targets is related?
[12:36] <tomreyn> lotuspsychje: where do you see this?
[12:36] <lotuspsychje> the digitalocean one
[12:38] <tomreyn> well, it explains targets in systemd, but not how to boot to them overriding the default target by using kernel command line parameters
[12:38] <lotuspsychje> ah
[12:38] <lotuspsychje> !kernelparm
[12:39] <tomreyn> we should have a list or explain how to get a list of initrd supported kernel command line parameters
[12:40] <tomreyn> having it is more user friendly - until it gets outdated.
[12:41]  * pragmaticenigma is obsolete :-P
[12:47] <tomreyn> aaaah crap there is actually kernel-command-line(7)
[12:48] <lotuspsychje> where did you find tomreyn
[12:49] <tomreyn> i knew about bootparm(7) which doesn't discuss this, and while searchign the web for it stumbled into http://man7.org/linux/man-pages/man7/bootparam.7.html where, on the footer, it says:   Pages that refer to this page: reboot(2),  boot(7),  kernel-command-line(7)
[12:50] <tomreyn> so we should mention bootparm(7) and kernel-command-line(7) on https://wiki.ubuntu.com/Kernel/KernelBootParameters
[12:50] <lotuspsychje> i know someone that likes editing wiki's :p
[12:50] <tomreyn> i don't
[12:50] <lotuspsychje> me neither :p
[13:02] <tomreyn> okay, done
[14:35] <pragmaticenigma> leftyfb: -X always results in an error message being displayed... -Y doesn't... that's why I use -Y... I've not looked in to -G before and I don't know what it does and I don't setup my SSH clients to automatically any forwarding
[14:38] <pragmaticenigma> leftyfb: Also, -X is mapped to forwardx11, -Y is mapped to fowardx11trusted
[14:38] <pragmaticenigma> so I'm not understanding your point
[18:27] <sarnold> pragmaticenigma: I'm pretty sure debian and ubuntu -X and -Y mean the same thing https://sources.debian.org/src/openssh/1:8.1p1-5/debian/patches/debian-config.patch/?hl=47#L47
[18:42] <dps> :wave:
[18:42] <dps> afternoon everyon!
[18:42] <dps> everyone*
[18:45] <sarnold> hey dps
[18:45] <pragmaticenigma> sarnold: Yeah, I tried it and found that is the case from debian to debian system. With cygwin, it always throws a warning message if I try to use -X... that was the basis of my original thought pattern
[18:45] <pragmaticenigma> It would appear in debian, -X and -Y might be interchangable then?
[18:57] <dps> this may be a dumb question, but isnt it a bit unsafe for my IP address to be shown to everyone when i join a channel? lol
[18:58] <sarnold> dps: you can connect via Tor if you wish to hide it
[18:59] <pragmaticenigma> dps: You can also ask in #freenode for a "cloak"
[18:59] <dps> yeah, i guess i could. im just wondering exactly what someone could do with that info. Maybe try gaining access to my rig you think?
[18:59] <dps> oh ok, thanks! ill look into that
[19:00] <pragmaticenigma> dps: If you're on a dynamically changing IP the risk is lower. If someone was actively trying to target you for something, that would be the only risk.
[19:00] <pragmaticenigma> Personally I did it because I tansfer between a few locations, and I didn't like that those IPs don't change often enough, such that if someone were to be paying attention, they could determine if I were home or not
[19:01] <pragmaticenigma> but the reality is, you're more likely to get targetted by someone doing a full sweep of the IPv4 address space, then someone from here.
[19:02] <sarnold> dps: if your firewall is so poorly configured and you've got open services running that can be abused, you'd have already been abused due to just being on the internet; being on irc doesn't drastically change things there
[19:03] <sarnold> dps: the usual risk of being on irc with an IP address visible is saying something to someone who then aims a ddos booter at you and destroys your ISP's connection. I haven't seen that in years, and those kids normally try to take down entire irc networks rather than individual users..
[19:07] <daftykins> don't get suckered into these VPN services and other nonsense, all you need is to register with nickserv and get a cloak and then make sure you SASL auth at login prior to hopping in channels
[19:08] <sarnold> yeah that's like 99% good enough
[19:12] <pragmaticenigma> yup