[07:29] <seb128> mwhudson, bug #1845571 ... if fixing it properly isn't an option, what about reverting the casper change that created the issue for this cycle?
[07:29] <ubottu> bug 1845571 in partman-auto (Ubuntu Eoan) "ubiquity offers installation media as an install target" [High,Triaged] https://launchpad.net/bugs/1845571
[08:14] <Tuxist> hi i have problem with dak and ubuntu especaily with ddeb packages they seems not to be supported any dak alternative ?
[08:27] <Laney> ddstreet: xnox: do you see any problem if we delete the systemd-upstream autopkgtest results from when it used to use pi_tti's PPA? they are all quite old, right?
[08:35] <seb128> sforshee, hey, how likely are we going to see that tpm kernel bug fixed in 19.10 before release?
=== dwmw2 is now known as dwmw2_gone
[11:35] <ddstreet> Laney i think that's fine; it looks like there are over 3000 test results per arch using the ~upstream-systemd-ci team ppa, so any older than that are unlikely to be needed for anything
[11:35] <Laney> ROOOOOOOOOOOOCK ONNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
[11:36] <ddstreet> Laney and you'll keep the results from ~upstream-systemd-ci, right?
[11:36] <Laney> yeah
[11:36] <ddstreet> awesome.  thnx!
[11:37] <Laney> we just got a note from IS asking us to stop using all the bytes on the planet
[11:53] <sforshee> seb128: the bug is fixed in the eoan-proposed kernel, which should be about ready to promote ...
[11:53] <seb128> sforshee, ah nice, thx
[11:55] <ddstreet> Laney i see you approved freeze exceptions for a couple ubuntu-kylin packages (which I uploaded yesterday), it looks like he has 2 more that need excptions lp: #1847391 and lp #1847101, can he have exceptions for those?  I can upload them if so
[11:55] <ubottu> Launchpad bug 1847391 in kylin-nm (Ubuntu) "[FFe] Please sync kylin-nm 1.0.3-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/1847391
[11:55] <ubottu> Launchpad bug 1847101 in ubuntukylin-theme (Ubuntu) "[UIFe] Please upgrade ubuntukylin-theme to 1.8.3" [Undecided,New] https://launchpad.net/bugs/1847101
[11:56] <ddstreet> he said he is also going to apply for upload rights for his pkgs too, which he definitely needs to do
[11:57] <ddstreet> i'm not asking for myself, so if you have any concerns about giving exceptions i am fine with that
[11:59] <Laney> ddstreet: yep, sounds fine to me (feel free to paste into the bugs)
[11:59] <ddstreet> thanks!
[12:10] <xnox> Laney:  yes old.
[12:11] <xnox> Laney:  imho they should be purged frequently. No idea if we can track if like a PR was closed and delete those. Or like if we can purge things older than 3 months.
=== ricab is now known as ricab|lunch
[13:26] <seb128> doko, do you know if that's a known problem on current e with valgrind?
[13:26] <seb128> --6234-- WARNING: Serious error when reading debug info
[13:26] <seb128> --6234-- When reading debug info from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.0:
[13:26] <seb128> --6234--    debuginfo section duplicates a section in the main ELF file
[13:27] <seb128> same for gtk and some other libs
[13:27] <seb128> and the result is lack of debug symbols
[13:27] <seb128> (that's on amd64)
=== dwmw2_gone is now known as dwmw2
=== hyperair is now known as Guest14896
[13:54] <rbasak> rafaeldtinoco: not sure whose triage it'll come up on next, but the reporter responded to bug 1846714. Since you're our haproxy expert now, could you take a look please to judge importance?
[13:54] <ubottu> bug 1846714 in haproxy (Ubuntu Disco) "Merge "BUG/MEDIUM: server: Also copy "check-sni" for server templates."" [Undecided,New] https://launchpad.net/bugs/1846714
=== DrKranz is now known as DktrKranz
=== tacocat` is now known as tacocat
[13:55] <rafaeldtinoco> rbasak: doing it
[13:57] <rafaeldtinoco> rbasak: you are evil
[13:57] <rafaeldtinoco> its been some time now i dont have to google for 3 acronyms in the same sentence
[13:57] <rafaeldtinoco> lol
[13:57] <rafaeldtinoco> rbasak: let me handle it #)
[13:57] <rbasak> :)
[13:58] <rbasak> rafaeldtinoco: no need to do it right now, we can just tag it and move on
[13:58] <rafaeldtinoco> nah, let it hang there for sometime, ill keep it open and do it by eod then
[13:58] <rbasak> rafaeldtinoco: I'm only asking because I thought you might immediately understand the issue and therefore understand its priority
[13:58] <rbasak> Thanks :)
=== ricab|lunch is now known as ricab
[15:06] <bdmurray> sil2100: bug 1847313 is a duplicate of bug 1813354
[15:06] <ubottu> bug 1847313 in ubuntu-release-upgrader (Ubuntu) "update to 19.04 to 19.10 terminal " [Undecided,New] https://launchpad.net/bugs/1847313
[15:06] <ubottu> bug 1813354 in ubuntu-release-upgrader (Ubuntu) "release-upgrader unable to deal with sources.list entries of "deb mirror://"" [Medium,Confirmed] https://launchpad.net/bugs/1813354
[15:16] <sil2100> bdmurray: good to know, thanks o/
=== infinity1 is now known as infinity
[18:33] <infinity> jibel: Why is zfs a unique snowflake in how we're seeing/installing tools?
[18:34] <infinity> jibel: Everything else (other than ext4, whose tools are essential) ships tools in live-common, not *-desktop, and said tools are removed if unused.
[18:49] <ahasenack> if I *have* to parse text output from a tool, because it doesn't use an exit status for a particular error condition, what's the right way to set the locale to "neutral"?
[18:49] <ahasenack> LC_ALL=C LANG=C <command>?
[18:55] <Faux> Sounds reasonable. TERM=dumb may help sometimes.
[20:35] <infinity> ricotz: Was dropping all the libvala* files from debian/ intentional in this vala upload...?
[20:36] <ricotz> infinity, how do you mean?
[20:37] <infinity> vala-0.44.8/debian/libvala-0.46-0.install
[20:37] <infinity> vala-0.44.8/debian/libvala-0.46-0.symbols
[20:37] <infinity> vala-0.44.8/debian/libvala-0.46-dev.install
[20:37] <infinity> vala-0.44.8/debian/libvaladoc-0.46-0.install
[20:37] <infinity> vala-0.44.8/debian/libvaladoc-0.46-0.lintian-overrides
[20:37] <infinity> vala-0.44.8/debian/libvaladoc-0.46-0.symbols
[20:37] <infinity> vala-0.44.8/debian/libvaladoc-0.46-data.install
[20:37] <infinity> vala-0.44.8/debian/libvaladoc-0.46-dev.install
[20:37] <infinity> vala-0.44.8/debian/vala-0.46-doc.install
[20:37] <infinity> vala-0.44.8/debian/valac-0.46-vapi.install
[20:37] <infinity> ricotz: ^-- All those files got dropped.
[20:38] <infinity> ricotz: That seems suboptimal.
[20:38] <infinity> (debdiff is your friend)
[20:38] <ricotz> huh, where did they came from
[20:38] <ricotz> I didn't built the package, seb128 picked it up from debian salsa
[20:39] <ricotz> I guess something went wrong when building 0.44.8-0ubuntu1
[20:39] <ricotz> infinity, so those files should never have been there
[20:42] <ricotz> infinity, the content of 0.44.9-0ubuntu1 looks good that way
[20:43] <infinity> ricotz: Oh, huh.  I just realised those files are for a future version of vala.  Special.
[20:44] <infinity> ricotz: Maybe the previous upload was an aborted attempt to merge with unstable, and then the uploader decided against it and didn't clean up. :P
[20:46] <ricotz> maybe some gbp hiccup
[22:32] <petersaints> Hi guys! I have a question regarding the inclusion of the NVIDIA proprietary drivers into the Ubuntu 19.10 Eoan Ermine ISO. From what I've read and tested, the Live session still boots using the nouveau drivers by default. The NVIDIA drivers are only enabled after installation. Is there any way to use the NVIDIA proprietary drivers in the Live
[22:32] <petersaints> session before installation?
[22:34] <xnox> petersaints:  actually when the installer selects them, they are installed both for the live session and the target, but i'm not sure there is anyway to "live" switch from one to the other without like killing the desktop.
[22:35] <xnox> petersaints:  i guess in theory, one could switch to tty1 and orchestrate a switch. But by default, no the debs are not "pre-installed" in anyway shape or form to boot live session into them, as the user must agree to EULA to use/install them.
[22:35] <xnox> * any way, shape, or form
[22:35] <petersaints> Ok. I thought that there could be some "nonfree" boot flag that I could enable to directly boot into a Live version with the NVIDIA proprietary drivers.
[22:35] <xnox> petersaints:  no, cannot do from legal reasons, not technical ones.
[22:36] <xnox> petersaints:  we do not pre-link nvidia modules for the users.
[22:36] <petersaints> It's not that the nouveau drivers don't work for me. I just wanted to test the latest GNOME 3.24 didn't leak memory with NVIDIA drivers.
[22:37] <xnox> petersaints:  i agree it would be nice, you might want to open a bug report requesting that against ubiquity (ie. ubuntu-bug ubiquity or over at https://bugs.launchpad.net/ubuntu/+source/ubiquity )
[22:37] <xnox> petersaints:  such that it's not forgotten, and discussed the blockers in doing it. Most likely the bug will stay open, or be closed as wont-fix / opinion.
[22:38] <petersaints> This is not Ubuntu specific, but GNOME Shell has a number of issues when running with the NVIDIA proprietary drivers. For instance, if I snap two windows side by side and move the divider between the two back and forth for a little while GNOME Shell memory usage keeps increasing and even after you stop it's never reclaimed.
[22:39] <petersaints> However, if you use the nouveau drivers or an Intel GPU the problem doesn't occur.
[22:39] <infinity> I'd act surprised, except no, I won't.
[22:40] <petersaints> Ehehe... I've been able to make my PC run out of memory just with this little trick
[22:40] <petersaints> That's why I've been using KDE for the past 2 years or so, but from time to time I check if it has been fixed... but nope!
[22:41] <infinity> Have you tried figuring out how to report it to nvidia?
[22:41] <petersaints> I'm not sure whose fault it is. I commented about it in a GNOME Shell bug report some time ago.
[22:42] <infinity> Granted, it would end up low on their TODO list, which is roughly: 1) Windows gaming performance, 2) Windows desktop stability, 3-97) Count money, 98) Linux gaming performance, 99) Linux desktop stability.
[22:42] <infinity> But it's still worth a shot.
[22:42] <sarnold> maybe linux desktop got shoved off the list when they started making a play for datacenters
[22:42] <petersaints> but considering that the problem doesn't occur with other drivers it's probably their fault
[22:43] <petersaints> there were some GNOME Shell leaks that were not driver specific, but the most sever ones have been fixed by now.
[22:43] <infinity> petersaints: Well, "fault" and "blame" are hard to pinpoint when you're talking the bizarre interaction between renderering applications, OpenGL/Vulkan/etc stacks, low level drivers, kernels, firmware, sketchy hardware.
[22:44] <petersaints> The only thing NVIDIA cares a little bit in Linux is probably CUDA performance for their Quadros and Teslas.
[22:44] <infinity> petersaints: Really, every layer is grudgingly responsible for working around all the bugs in every other layer in both directions.  It's a "fun" space to work in, if you don't value clean solutions and general sanity.
[22:45] <infinity> A large chunk of nvidia/amd 3D drivers are hackish workaround for crap software (mostly games, but desktops too!), like, ridiculously large amounts of code.  And every one of those hacks breaks someone else's equally sort-of-legit non-bug-but-kinda-bug hack elsewhere. :P
[22:47] <petersaints> infinity yeah, I said fault in a broad sense. As in, where do I need to make the smallest change to make the problem go away without blowing stuff for every other scenario. For instance, to fix stuff to work better with the NVIDIA proprietary driver you could end up inadvertently breaking something else.
[22:48] <xnox> petersaints:  so.... you say that nvidia drivers are bad for gnome-shell, we don't use them by default, and you don't want to use them by default, yet want installer to boot into nvidia..... to test things?
[22:48] <infinity> xnox: To test is that combination now works.
[22:48] <infinity> s/is/if/
[22:48] <xnox> petersaints:  i'm just trying to understand the reasoning behind your nvidia ubiquity request.
[22:48] <infinity> To be fair, it's a pretty niche use-case. :)
[22:49] <petersaints> exactly, to test if the problem  still occurs without having to perform an install
[22:49] <petersaints> I was just asking if there was already a process to make it happen
[22:49] <petersaints> it's not worth it to implement it just for my super edge case
[22:49] <sarnold> on the other hand maybe "download this, dd it to usb, reboot, wiggle your mouse for ten minutes" is a decent enough reproducer script that someone would *do* it :)
[22:50] <infinity> petersaints: Sadly, no.  It would have to happen at very early boot (once one driver claims the card, it's basically busted for the other until a pretty hard reset), and at early pre-module boot, it's not really feasible to present you with informed consent sort of "do you want this non-free stuff, and do you bow to your nvidia overlords?"
[22:50] <petersaints> Manjaro has been the distro where I have tried a few times if the problem is still there
[22:51] <petersaints> they have a nonfree boot option for drivers and they bundle the nvidia  proprietary drivers
[22:51] <xnox> petersaints:  you could try with booting 'break=bottom" when you boot installer, and press esc and edit the boot entry.
[22:51] <infinity> Fun.
[22:51] <petersaints> sadly, the last time I tried a couple of months ago still no luck
[22:51] <infinity> Manjaro is a much smaller target than us, and we're trying to be on the right side of the copyright sketch involved.
[22:51] <xnox> petersaints:  then you can bind mount proc, sys, dev, dev/pts, run into /root/* and chroot into there.
[22:52] <xnox> cdrom pool should be configured
[22:52] <xnox> and install nvidia drivers
[22:52] <xnox> i think that might do it.
[22:52] <xnox> exit the shell
[22:52] <infinity> That would do, yes.
[22:52] <petersaints> @xnox thanks for the tips, but it's too much of a hassle for what it is :P
[22:52] <udevbot> Error: "xnox" is not a valid command.
[22:52] <petersaints> @infi
[22:52] <udevbot> Error: "infi" is not a valid command.
[22:52] <xnox> and see if you boot with nvidia sutff, check settings, about this computer to ensure it's nvidia
[22:53] <infinity> This episode of IRC is not Twitter has been brought to you by udevbot.
[22:53] <xnox> petersaints:  well, i'm at release sprint next week with my nvidia capable laptop, i just might try all of that =)
[22:53] <xnox> udevbot well job =)
[22:53] <udevbot> Error: "well" is not a valid command.
[22:54] <petersaints> infinity: sure, I wasn't aware of the legal stuff. I was under the impression that you had struck a deal with NVIDIA for the inclusion of the drivers. If that's not the case, it makes sense to be cautious.
[22:54] <infinity> petersaints: It's less about nvidia and more about how you interpret the linking bits in the GPL.
[22:55] <petersaints> xnox nice, but I believe that it must be an NVIDIA-only laptop like mine. I have a 6700HQ and a GTX 1060. The Intel GPU is completely disabled on my laptop. Only the NVIDIA GPU works and all output comes from it.
[22:55] <infinity> petersaints: We link the drivers at install, with your consent, so it's the end-user (who isn't bound by the license) linking, not Ubuntu/Canonical (who are the distributor, and are bound by it).
[22:56] <infinity> It's a fine line and vaguely sketchy distinction, but there you go.
[22:56] <infinity> The best part about it all is that we *did* link the drivers in our build farm, so we could sign them.  Strip off the sig.  And throw away the binaries that we refuse to ship to you.
[22:56] <infinity> So we can reattach the sig to the identical binary we create with your consent on your system.
[22:58] <xnox> and perform signed secureboot with lockdown
[22:59] <petersaints> infinity: that's quite a loot of hoops you go through to make things work without cross the line.
[22:59] <xnox> petersaints:  NVIDIA-only laptop sounds sketchy. Are you sure you don't have any options in uefi bios menus to enable integrated graphics?
[22:59] <petersaints> * lop of hoops
[22:59] <infinity> An nvidia-only laptop would be the most power-hungry thing known to man.
[23:00] <infinity> But maybe he meant it's nvidia-only because he hard disabled the Intel graphics in the BIOS?
[23:00] <infinity> Which, see point 1:  Power hungry.  But I guess everyone has their reasons.
[23:00] <petersaints> xnox: Nope. This is an ASUS ROG GL502VM and it was built this way in order to allow G-Sync.
[23:00] <infinity> Oh.
[23:01] <petersaints> you can't G-Sync from an Intel GPU and the laptop panel is G-Sync enable (60Hz which is kind of useless for G-Sync but oh well)
[23:01] <infinity> Yeah, "gamer" laptops, all bets are off there.  Heat and power consumption aren't concerns, they're points of pride. :)
[23:01] <infinity> If you can't bake cookies on the bezel, are you really gaming?
[23:01] <petersaints> I've read that later models, such as the GL504 can switch between NVIDIA exclusive mode and hybrid GPU mode.
[23:02] <petersaints> The battery isn't too bad for what it is. I can squeeze 4h out of it on Windows with ThrottleStop.
[23:02] <petersaints> On Linux I get half of that!
[23:02] <infinity> If nvidia would just admit that Freesync is the much saner (and far more widely adoptable strategy), they could standardize, and everyone would have nice things.
[23:03] <petersaints> actually they now support FreeSync
[23:03] <infinity> Do they support it without registry hacks now?
[23:03] <infinity> Cause they used to "support" it in the sense that you could force it. :P
[23:05] <petersaints> I think so. You now have different levels of certification
[23:05] <petersaints> G-Sync, G-Sync Compatible and I think it tries to work with any FreeSync monitor on a best try basis
[23:05] <petersaints> https://www.theverge.com/2019/3/12/18251980/how-to-install-nvidia-g-sync-unsupported-freesync-monitor
[23:06] <petersaints> I have a crappy LG 75Hz FreeSync monitor but I can't use G-Sync with it because it doesn't have DisplayPort. It's HDMI and FreeSync over HDMI only works with some AMD specific extensions to the standard.
[23:07] <petersaints> However, in theory, if I the monitor had a DisplayPort input it could work with my laptop's GTX 1060
[23:08] <infinity> "AMD specific extensions" ... AMD wrote the standard, so I suspect that's okay. :P
[23:09] <infinity> The Display-Port specific protocol is Adaptive Sync.