January 2023 - openSUSE Support - openSUSE Mailing Lists

Printer driver HP Color Laser 178nw
by Jogchum Reitsma 17 Feb '23

17 Feb '23

Hi, I am trying to install a HP Color Laser 178nw Cups (and also lsusb) sees the printer, but I can't find a driver for it. The list of printer cups, and also the HP support website, is long, but I no Color Laser 178nw. On the HP support site no driver can be found at all, regardless the choice of OS. The openprinting.org site also shows no Color Laser 178nw. It was bought very recently, so I wouldn't think it's a too old model. Anyone an idea how to get this beast to work? Thanks i advance, Jogchum

8 16

[support] wiki page watching
by Felix Miata 30 Jan '23

30 Jan '23

I started new page https://en.opensuse.org/SDB:InstallNewerKernel on 27 Jan. I don't recall doing anything to cause it to not be watched, yet none the several edits by Svyatko that followed ever caused an email notification. Is this a normal result of creating a new page? When I went back to work it, the watch this page box was always checked. Is there a simple way to check whether watching is enabled on the individual article or talk pages, without having to find the watchlist page and edit it? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

1 0

Intel Ideapad i915 backlight broke after latest TW updates
by Marco Calistri 27 Jan '23

27 Jan '23

[ 4.686103] i915 0000:00:02.0: [drm] Skipping intel_backlight registration [ 23.876210] ideapad_acpi VPC2004:00: Keyboard backlight control not available Hello, After latest Tumbleweed updates my backlight/brightness has messed up. I used to lean on an "after.local" script in order to set brightness for my Lenovo Z470 at startup: #!/bin/sh echo -n 700 > /sys/class/backlight/intel_backlight/brightness Now this script is useless because the brightness doen't get adjusted anymore. Is there someone which already faced/resolved same issue? Thanks and regards, -- Marco Calistri Build: openSUSE Tumbleweed 20230125 Kernel: 6.1.8-1-default - XFCE: (4.18.0)

1 1

Including Shutter into the main repo(?)
by Marco Calistri 21 Jan '23

21 Jan '23

Hi, I was needing a snipping tool with the ability to record the "mouse-over tool-tips" into the screenshot and so far I couldn't find nothing with this feature. At least until today, when I read about and have installed Shutter by the community repo rievan. Repository : home:rievan (openSUSE_Tumbleweed) Nome : shutter Versione : 0.98-30.7 Arch. : noarch Fornitore : obs://build.opensuse.org/home:rievan Dimensione installata : 13,9 MiB installato : Sì Stato : aggiornato Pacchetto sorgente : shutter-0.98-30.7.src URL upstream : http://shutter-project.org/ Sommario : The feature-rich screenshot tool Descrizione : Shutter is a feature-rich screenshot program for Linux based operating systems such as Ubuntu. You can take a screenshot of a specific area, window, your whole screen, or even of a website – apply different effects to it, draw on it to highlight points, and then upload to an image hosting site, all within one window. Shutter is free, open-source, and licensed under GPL v3. I think that Shutter is so far the best snipping tool that I never used (IMHO), and I'm asking if you could include it into the main Tumbleweed repository. Thanks for your kindest attention! Regards, -- Marco Calistri Build: openSUSE Tumbleweed 20230118 Kernel: 6.1.6-1-default - XFCE: (4.18.0)

2 3

Sending document from Libreoffice crashes Kontact
by Axel Braun 20 Jan '23

20 Jan '23

Hi, since month I have the reproducible case that, when sending a document from LO (File -> Sent -> Email Document) Kontact/KMail crashes when hitting the send button (and not sending the mail). After restarting Kontact at least the mail is still availabe, and as the document is then attached to the mail the mail can be sent. In the respective KDE bug report https://bugs.kde.org/show_bug.cgi?id=456082 the developer cant reproduce this. Can anyone reproduce the bug? If so, it might be oS specific? Tumbleweed Cheers Axel

3 2

Re: Leap 15.4 - Installing Python 3.10 alongside Python 3.9
by Glen Barney 14 Jan '23

14 Jan '23

On Thu, 12 Jan 2023 17:24:34 +1030, Simon Lees wrote: > Don't shoot the messenger, that's just the content of the bugreport. No shooting intended from here for sure! I'm very grateful for your sharing the contents of the bug report, and the history. > At a guess i'd say its related to the way someone would like it to be > implemented for package hub as they are probably using the same package. So I guess same question: What options do I, as a lowly user, have to somehow move this along, and/or get it changed, and/or get some kind of workaround? I know I can build from source, but I really prefer the advantages of distro-provided packages if at all possible, not to mention the nice /etc/alternatives and related support that OpenSuse provides. Would it make sense, for example, to raise this on the opensuse-python list? Or is there some other action I could take to help facilitate? Apologies that I lack the organizational/political knowledge here - I've been a fan of OpenSuse from the v7 days and have always used it as my primary, but that confers zero knowledge about the people behind the decisions! Thanks for any insight or pointers anyone can provide! Glen

3 4

Re: Leap 15.4 - Installing Python 3.10 alongside Python 3.9
by Glen Barney 12 Jan '23

12 Jan '23

On Thu, 12 Jan 2023 17:35:47 +1030, Simon Lees wrote: > Most developers are using openSUSE Tumbleweed where Python 3.8, 3.9 and > 3.10 are all co install-able and there is a different mechanism to set > the default python and handle migrations. This was done post the release > of Leap 15, so it was never implemented there and 3.6 will remain the > default because that is what we promised SUSE customers. I expect that > ALP will have a similar setup to tumbleweed and handling multiple python > versions will be easier. Okay, understood. > Python 3.9 and 3.10 have never been officially supported in Leap 15.4 (I > believe there are plans to have atleast one for 15.5) so if this was > done to make package hub work properly for SUSE it will be hard to > convince them to change it again. Okay, I think I understand that. If you think it would be worth asking anyway, and can provide a point of contact, I'm happy to write an email. Let me know. > On the other hand branching the package and removing the conflicts and > building a version for yourself is not hard. I can probably help walk > you through the process a little later. I would be SUPER GRATEFUL for that. I of course know that you must be super busy and would never expect it, but, absolutely, if you'd be willing to tell me how, I'd love to learn the technique(s) and do the work. Please do email me directly whenever you have time, that would be a huge help for me, and my users. THANK YOU THANK YOU! And now crashing for real, thank you all! Glen

1 0

Leap 15.4 - Installing Python 3.10 alongside Python 3.9
by Glen Barney 12 Jan '23

12 Jan '23

I have a number of 15.4 servers, which have been upgraded from previous recent Leap versions. These servers have the legacy Python 2.7, the current Python 3.6, and the newer Python 3.9 package groups all installed, side by side, and all working properly. However.... attempts to install Python 3.10 fail, with what appear to be dependency conflicts against Python 3.9, as shown: # zypper install python310 Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the installed python39-setuptools-44.1.1-7.3.1.noarch requires 'python39', but this requirement cannot be provided not installable providers: python39-3.9.10-150300.4.8.2.x86_64[repo-oss] python39-3.9.10-150300.4.8.2.x86_64[repo-sle-update] python39-3.9.13-150300.4.13.1.x86_64[repo-sle-update] python39-3.9.14-150300.4.16.1.x86_64[repo-sle-update] Solution 1: Following actions will be done: deinstallation of python39-setuptools-44.1.1-7.3.1.noarch deinstallation of python39-pip-20.2.4-7.8.1.noarch deinstallation of libpython3_9-1_0-3.9.15-150300.4.21.1.x86_64 Solution 2: do not install python310-3.10.8-150400.4.15.1.x86_64 Solution 3: break python39-setuptools-44.1.1-7.3.1.noarch by ignoring some of its dependencies I have even tried downloading the 8 "main" Python310 packages and installing via rpm... libpython3_10-1_0-3.10.8-150400.4.15.1.x86_64.rpm python310-3.10.8-150400.4.15.1.x86_64.rpm python310-base-3.10.8-150400.4.15.1.x86_64.rpm python310-curses-3.10.8-150400.4.15.1.x86_64.rpm python310-dbm-3.10.8-150400.4.15.1.x86_64.rpm python310-devel-3.10.8-150400.4.15.1.x86_64.rpm python310-pip-22.0.4-150400.3.3.1.noarch.rpm python310-setuptools-57.4.0-150400.2.14.noarch.rpm # rpm -Uvh [lp]* error: Failed dependencies: python39 is needed by (installed) python39-setuptools-44.1.1-7.3.1.noarch python39 = 3.9.15 is needed by (installed) python39-tk-3.9.15-150300.4.21.1.x86_64 python39 = 3.9.15 is needed by (installed) python39-testsuite-3.9.15-150300.4.21.1.x86_64 python(abi) = 3.9 is needed by (installed) python39-setuptools-44.1.1-7.3.1.noarch python(abi) = 3.9 is needed by (installed) python39-pip-20.2.4-7.8.1.noarch python(abi) = 3.9 is needed by (installed) python39-tools-3.9.15-150300.4.21.1.x86_64 python(abi) = 3.9 is needed by (installed) python39-tk-3.9.15-150300.4.21.1.x86_64 python(abi) = 3.9 is needed by (installed) python39-testsuite-3.9.15-150300.4.21.1.x86_64 python39-base >= 3.9.15 is needed by (installed) libpython3_9-1_0-3.9.15-150300.4.21.1.x86_64 python39-base = 3.9.15 is needed by (installed) python39-tools-3.9.15-150300.4.21.1.x86_64 /usr/bin/python3.9 is needed by (installed) python39-setuptools-44.1.1-7.3.1.noarch /usr/bin/python3.9 is needed by (installed) python39-pip-20.2.4-7.8.1.noarch /usr/bin/python3.9 is needed by (installed) python39-tools-3.9.15-150300.4.21.1.x86_64 I've listed out the contents of the existing Python3.9 packages, as well as the manually-downloaded Python3.10 packages. All seem to be properly structured, in that they all install with separate names and/or in separate directories, just as expected. Nevertheless it appears that any attempts to install Python3.10 make the servers try to uninstall Python3.9, which implies that, despite the separate layouts and structures, the two versions cannot be installed side-by-side. I'm sure I am missing something obvious. Can anyone please help me get Python 3.10 deployed alongside Python 3.9 (and the other versions) on Leap 15.4? Thank you! Glen

5 20

Re: Leap 15.4 - Installing Python 3.10 alongside Python 3.9
by Glen Barney 12 Jan '23

12 Jan '23

Hi Simon - I sent my other email and then saw this: On Thu, 12 Jan 2023 16:26:48 +1030 , Simon Lees wrote: >Bug 1195831 - python310 doesn't offer a migration path >With the submitted python310 in Staging there is no submission path >offered to do a removal of python39 and replace it with the newer >version. This would lead to an orphaned package on migrations and >customers not receiving the newer python310. >I don't think that python310 can follow the guidelines and do a Provides >and Obsoletes. An alternative might be to introduce a meta package for >this development interpreter like it is done for rust: >https://build.suse.de/package/view_file/SUSE:SLE-15-SP4:GA/rust/rust.spec?e… >or introducing a python39-obsolete, which Recommends the installation of >python310. >There might be other solutions to this as well, but we definitely >require some fix for this migration/orphaned package issue. >------------------------------------------------------------------- >An obsolete is not a conflict however, so this change doesn't explain >them not being co install-able. So it seems that this bug is the same problem I'm having? I read and appreciated your explanation about the bug system. Is it possible to perhaps add me to that bug, or at least add the information I've sent to the bug to help the maintainers fix this? >As with many fun things in life, its a Legacy software issue. Currently >we are still using a bugzilla instance from the Novell era. It has some >unfortunate settings that are very hard to change, many that any bug >thats listed for SUSE Partners becomes closed. That bugzilla instance >has so many patches that its very hard to work on or update. I fell afoul of this type of thing on the list system as well. When the change to the list system was made, my primary address somehow ended up banned systemwide (and no, I had not offended anyone ever or even come close to it as far as I know!) but I was unable to subscribe myself to or remove myself from ANY OpenSuse lists - and I had no idea who to contact to fix that. I ended up just creating a new freemail address just so I could get these support requests through - but there are certainly problems in the Mailman3 system as well, FWIW... Thanks again for any information or assistance! Glen

1 0

Re: Leap 15.4 - Installing Python 3.10 alongside Python 3.9
by Glen Barney 12 Jan '23

12 Jan '23

Hi Simon - Thank you for your reply... On Thu, 12 Jan 2023 16:43:20 +1030, Simon Lees wrote: >On 1/10/23 09:08, Glen Barney wrote: >> I have a number of 15.4 servers, which have been upgraded from previous >> recent Leap versions. These servers have the legacy Python 2.7, the >> current Python 3.6, and the newer Python 3.9 package groups all >> installed, side by side, and all working properly. >> However.... attempts to install Python 3.10 fail, with what appear to be >> dependency conflicts against Python 3.9. >It seems more like there is a conflict in something like python-tools or >python-setuptools, maybe you can remove the 3.9 version manually and >that will make the resolver happier. On my tumbleweed system I certainly >still have both installed but that is setup differently. Alas, I've tried various combinations without luck. And this is an operational development server on Leap 15.4, so I can't switch to TW in this case. To try to narrow this down further, I just created a freshly-loaded default install of 15.4 on a brand new (virtual) machine. The default install loaded Python 3.6, as expected. I then tried this: # zypper in python39 python310 And got this: Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the to be installed python310-3.10.8-150400.4.15.1.x86_64 obsoletes 'python39' provided by the to be installed python39-3.9.15-150300.4.21.1.x86_64 Solution 1: do not install python39-3.9.15-150300.4.21.1.x86_64 Solution 2: do not install python310-3.10.8-150400.4.15.1.x86_64 Choose from above solutions by number or cancel [1/2/c/d/?] (c): This doesn't make sense to me, because if I download the RPMs and list them out, everything seems co-compatible: # rpm -q -l python39-3.9.15-150300.4.21.1.x86_64.rpm /usr/lib64/python3.9 /usr/lib64/python3.9/lib-dynload /usr/lib64/python3.9/lib-dynload/_sqlite3.cpython-39-x86_64-linux-gnu.so /usr/lib64/python3.9/lib-dynload/nis.cpython-39-x86_64-linux-gnu.so /usr/lib64/python3.9/lib-dynload/readline.cpython-39-x86_64-linux-gnu.so /usr/lib64/python3.9/sqlite3 /usr/lib64/python3.9/sqlite3/__init__.py /usr/lib64/python3.9/sqlite3/__pycache__ /usr/lib64/python3.9/sqlite3/__pycache__/__init__.cpython-39.opt-1.pyc /usr/lib64/python3.9/sqlite3/__pycache__/__init__.cpython-39.opt-2.pyc /usr/lib64/python3.9/sqlite3/__pycache__/__init__.cpython-39.pyc /usr/lib64/python3.9/sqlite3/__pycache__/dbapi2.cpython-39.opt-1.pyc /usr/lib64/python3.9/sqlite3/__pycache__/dbapi2.cpython-39.opt-2.pyc /usr/lib64/python3.9/sqlite3/__pycache__/dbapi2.cpython-39.pyc /usr/lib64/python3.9/sqlite3/__pycache__/dump.cpython-39.opt-1.pyc /usr/lib64/python3.9/sqlite3/__pycache__/dump.cpython-39.opt-2.pyc /usr/lib64/python3.9/sqlite3/__pycache__/dump.cpython-39.pyc /usr/lib64/python3.9/sqlite3/dbapi2.py /usr/lib64/python3.9/sqlite3/dump.py # rpm -q -l python310-3.10.8-150400.4.15.1.x86_64.rpm /usr/lib64/python3.10 /usr/lib64/python3.10/lib-dynload /usr/lib64/python3.10/lib-dynload/_sqlite3.cpython-310-x86_64-linux-gnu.so /usr/lib64/python3.10/lib-dynload/nis.cpython-310-x86_64-linux-gnu.so /usr/lib64/python3.10/lib-dynload/readline.cpython-310-x86_64-linux-gnu.so /usr/lib64/python3.10/sqlite3 /usr/lib64/python3.10/sqlite3/__init__.py /usr/lib64/python3.10/sqlite3/__pycache__ /usr/lib64/python3.10/sqlite3/__pycache__/__init__.cpython-310.opt-1.pyc /usr/lib64/python3.10/sqlite3/__pycache__/__init__.cpython-310.opt-2.pyc /usr/lib64/python3.10/sqlite3/__pycache__/__init__.cpython-310.pyc /usr/lib64/python3.10/sqlite3/__pycache__/dbapi2.cpython-310.opt-1.pyc /usr/lib64/python3.10/sqlite3/__pycache__/dbapi2.cpython-310.opt-2.pyc /usr/lib64/python3.10/sqlite3/__pycache__/dbapi2.cpython-310.pyc /usr/lib64/python3.10/sqlite3/__pycache__/dump.cpython-310.opt-1.pyc /usr/lib64/python3.10/sqlite3/__pycache__/dump.cpython-310.opt-2.pyc /usr/lib64/python3.10/sqlite3/__pycache__/dump.cpython-310.pyc /usr/lib64/python3.10/sqlite3/dbapi2.py /usr/lib64/python3.10/sqlite3/dump.py Simiarly for pip... # rpm -q -l python39-pip-20.2.4-7.8.1.noarch.rpm | grep -v -e 3.9 -e 39 /etc/alternatives/pip # rpm -q -l python310-pip-20.2.4-150400.1.19.noarch.rpm | grep -v 10 /etc/alternatives/pip /etc/alternatives/pip3 /usr/bin/pip /usr/bin/pip3 And setuptools... # rpm -q -l python39-setuptools-44.1.1-7.3.1.noarch.rpm | grep -v -e 3.9 -e 39 /etc/alternatives/easy_install /usr/bin/easy_install /usr/bin/easy_install- # rpm -q -l python310-setuptools-57.4.0-150400.2.14.noarch.rpm | grep -v 10 (no output at all, everything in a 3.10 subdirectory) And python-tools... # rpm -q -l python39-tools-3.9.15-150300.4.21.1.x86_64.rpm | grep -v -e 3.9 -e 39 (no output) # rpm -q -l python310-tools-3.10.8-150400.4.15.1.x86_64.rpm | grep -v 10 (no output) My goal here is to have Python 3.10 installed alongside 3.9, so that developer users can migrate their code having both platforms available. It seems like the packages should co-exist nicely - Python seems built to allow versions to co-exist nicely - and yet even the basic packages here refuse to be installed together. This is what I'm trying to understand and work around. Thank you for any insight you can provide! Glen

1 0