[12:22] Other than the strange behavior of discover on the live session, the three test cases look good to me, but I saw: [12:23] sil2100: look at the end of the syslog, there's a plugininstall.py crash that doesn't occur in 22.04.0 [12:23] Anyway, this warrants a respin in case we find the fix [12:23] Those were not visible to me as an end-user. [13:02] Hi all [14:23] mparillo: I was seeing those yesterday in my testing, and was looking through the logs trying to figure out what was happening. At Kubuntu Focus, we rely on that OEM mode heavily. [17:38] -queuebot:#kubuntu-devel- Builds: Kubuntu Desktop amd64 [Jammy 22.04.1] has been updated (20220809.1) [17:39] I'm on this one. Specifically, retest for Nvidia and OEM installation issues. [18:25] Hi, I hope someone of you has good contact to Qt upstreams or is even a Qt upstream. [18:25] It is about Qt's print dialog which urgently needs some love. [18:26] Just to add to the discussion on the installer, on Kubuntu this happens every time. A few things we tried: disk encryption vs. no disk encryption. OEM install vs. end-user install. Safe graphics mode vs. standard. modprobe.blacklist=nouveau kernel option. All crashed at the end. [18:31] I am leading the OpenPrinting project and I am participating in the Google Summer of code mentoring 7 contributors for OpenPrinting. One of them is working on adding support for the Common Print Dialog Backends (CPDB, https://openprinting.github.io/achievements/#common-print-dialog-backends, https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4930) into print dialogs. He completed the GTK dialog and wants to do the same for other [18:31] print dialogs, especially also the Qt dialog. [18:31] Merge 4930 in GNOME/gtk "Draft: New CPDB print backend for GTK Print Dialog" [Opened] [18:35] tillkamppeter: maybe repeat the qt things in #ubuntu-qt here on libera, and/or in #debian-qt-ke on OFTC [18:35] debian/ubuntu Qt maintainers will then be able to see [18:37] Probably we will somehow get the coding done to arrive at a working dialog but the most important for us is that this dialog gets accepted upstream and so it is assured that printing from KDE and Qt apps will work with future changes in CUPS, especially the current effort of the New Architecture of all-IPP printing without having PPD files and classic drivers any more (https://linuxplumbersconf.org/event/11/contributions/1023/atta [18:37] chments/737/1443/lpc-cups-2021.pdf) [18:37] @RikMills, thanks, will do ... [18:38] tillkamppeter: This is KDE specific, right? [18:39] In other words, the print dialog will need to be updated for all KDE apps, right? [18:39] Both KDE and Qt. Am I right that when I print from a KDE app that I will see the Qt print dialog? [18:45] Yes, and possibly others. I think, for example, that libreoffice plugs into the KDE printing subsystem at some level through the libreoffice-plasma package or similar. [18:51] Yes, the KDE/Qt print dialog makes the impression for me as it did not get any change/maintenance/update since its introduction ~20 years ago when I made all the distros using CUPS and the GUI toolkits had to support CUPS. [18:52] CUPS got some changes in these 20 years, especially virtual queues (queue for IPP printer is created temporarily when one accesses it and removed 1 minute after the last access). [18:53] Now we have the next cjhange, the switch to all-IPP without PPDs, see above. [18:54] As I have expoerienced in both GTK and Qt that the effort put into maintaining the print dialogs and to keep pace with the upstream development of CUPS. [18:56] I have created the concept of the Common Print Dialog Backends (CPDB see link above) to overcome this, Here the code which does the communication with CUPS is in a separate backend which connects to the dialog via D-Bus, the backend is maintained by the maintainer of CUPS, the OpenPrinting project. [18:58] Another advantage is that if someone creates another print technology, like a cloud printing service, they can simply provide the CPDB backend for their service and so that service apears also in the print dialogs. [18:58] The backends are independent of the GUI, the one CUPS backend will work with all CPDB frontends: GTK, Qt, LibreOffice, ... dialogs. [18:59] My GSoC contributor wants to add CPDB support to the Qt print dialog, and I need a contact to help him with the correct coding and upstream submission. [19:00] @mmikowski_, WDYT? [19:02] @mmikowski_, I tried also #qt-labs, but there no one has answered yet. [19:05] This all sounds like upstream kde stuff to me, probably best to check with #kde-devel. [19:09] @Eickmeyer[m], will try ... Thanks. [20:13] -queuebot:#kubuntu-devel- Builds: Kubuntu Desktop amd64 [Jammy 22.04.1] has been marked as ready [20:27] tillkamppeter: Sorry, I got pulled into other stuff. [20:30] Just read your description, and it sounds very like a welcome improvement. [20:31] I don't have the qualifications to either help directly with Qt or even advise where to seek help with it, and would defer to advice provided by @RikMills. Sorry I can't be of more help. [20:32] I would defer to the Qt debian team to be fair, and they have been pinged ;) [20:34] Indeed Rik [21:35] Eickmeyer[m]: Could you tell me how you were able to pass all the test cases so quickly? Do you have a script? Do you have enough HW to do 7 VMs simultaneously? [21:38] mparillo: The test cases were rather simple since I merely built on the previous testing. Also, the ISO was evolutionary rather than revolutionary. The goal in this case was to make sure it installed without crashing, particularily offline with Nvidia graphics. So, it passed, and it needed to pass quickly. This was a test case as required by sil2100. [21:38] And my machine is a Kubuntu Focus M1. [21:39] mparillo: You have no clue how fast Eickmeyer's machine is. Like, holy smoke. [21:40] It's mind-boggling to me too. [21:40] TY === NotEickmeyer is now known as Eickmeyer