In data mercoledì 14 aprile 2021 14:46:24 CEST, Ben Greiner ha scritto:

As mentioned before, I would favor devel:languages:python:pyqt. I volunteer to participate in maintaining the project, but of course it is at the discretion of the existing maintainers.

I'm not sure if I worded it correctly, but I was in agreement with d:l:p:pyqt. -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B

El dom, 6 jun 2021 a las 11:51, Ben Greiner () escribió:

Am 14.04.21 um 22:16 schrieb Luca Beltrame:

...

In data mercoledì 14 aprile 2021 14:46:24 CEST, Ben Greiner ha scritto:

...

As mentioned before, I would favor devel:languages:python:pyqt. I volunteer to participate in maintaining the project, but of course it is at the discretion of the existing maintainers. I'm not sure if I worded it correctly, but I was in agreement with d:l:p:pyqt.

Despite repeated inquiries, Matej is still vetoing d:l:p:pyqt. [1]

* SIP and PyQt[56] are not from the same developers as Qt or KDE * SIP (python-sip) has nothing to do with KDE:Qt* * PyQt[56] is the main but not the only consumer of SIP - Thus, following Simon's argument [2], python-qt5*, python-PyQt6* and python-sip* should be in the same devel project. * Qt Libraries are packaged into separate projects for each minor version. * The most recent version of PyQt5 compiles with any Qt5 version. The most recent version of PyQt6 compiles with any Qt6 version. - Thus, putting python-PyQt6 into a KDE:Qt6.X project would be wrong

With the bullet points above, one could argue to put everything into devel:languages:python, but that collides with Matej's veto and Simon's argument. If we can't get d:l:p:pyqt, IMHO the next best thing would be KDE:Qt:PyQt.

Ben

[1] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/... (which is a reply to an off-list message) [2] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/...

Remember Ben, one of the affected packages is Openshot-qt, with libopenshot and libopenshot-audio. https://build.opensuse.org/package/show/multimedia%3Aapps/openshot-qt The latest Openshot-qt build has about 1 year, but from this time in Tumbleweed Qwebkit was replaced with QWebEngine, the same that happens with Openshot-qt : https://github.com/OpenShot/openshot-qt/pull/2512 You have builded the webkit package, and with this package the application starts again, but the exported videos have no audio. https://download.opensuse.org/repositories/home:/bnavigator:/pyqt:/webkit/Fa... Regards, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/

El dom, 6 jun 2021 a las 15:03, Ben Greiner () escribió:

Juan,

Am 06.06.21 um 18:21 schrieb Juan Erbes:

...

Remember Ben, one of the affected packages is Openshot-qt, with libopenshot and libopenshot-audio. https://build.opensuse.org/package/show/multimedia%3Aapps/openshot-qt

Whether the pure python package openshot-qt "builds" in multimedia:apps and whether it works on a live Tumbleweed system is unrelated to the fact which devel project python-qt5 comes from.

You don't even need to use multimedia:apps. The normal Tumbleweed repository has an openshot-qt package with identical content. The openshot-qt rpm is just a collection of pure python scripts put into the right directories, which contain "from PyQt5.QtWebKitWidgets import QWebView". Not even the officially published PyQt5 wheels with their bundled Qt5 libraries contain the QtWebKit bindings. So your only hope is that the openshot-qt authors finally release a new version, or that someone backports the QtWebKit to QtWebEngine replacement to v2.5.1.

I doubt that PyQt5 does have anything to do with your audio export problem.

The problem with NO AUDIO on the exported videos appeared after Opensuse dropped QtWebKit from PyQt5 and You builded QtWebKit again. You are encouraged to file a bug report on the opensuse

bugzilla and/or the openshot-qt Github repo about it. Or that you nicely ask on one of the user support channels. (The factory mailinglist is not one of those places). Your repo configuration including packman where you get your codec libraries from would be relevant.

I claimed to the maintainers of openshot-qt to build a new version with the current sources of Github, but I have no response. I tried to build myself on my pc, but I couldn't resolve a problem with libopenshot: CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) Call Stack (most recent call first): /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake/Modules/FindOpenMP.cmake:542 (find_package_handle_standard_args) src/CMakeLists.txt:318 (find_package) I have installed all the related packages to OpenMP: cmake-full libgomp1 libgomp1-32bit openmpi4 openmpi4-config openmpi4-libs python38-h5py-openmpi4 vtk-openmpi1-qt hdf5-openmpi4 If I try to use the AppImage of daily builds for Linux X86-64, anytime I get the error "Could not create hardware device" when I Try to export a video. I claimed for that problem on Reddit, and the response was: "This is a problem with unixes devices" Thanks, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/

On Monday, 7 June 2021 11:20:01 CEST Matěj Cepl wrote:

Dne 06. 06. 21 v 16:51 Ben Greiner napsal(a):

...

With the bullet points above, one could argue to put everything into devel:languages:python, but that collides with Matej's veto and Simon's argument. If we can't get d:l:p:pyqt, IMHO the next best thing would be KDE:Qt:PyQt.

Which is exactly what I was suggesting from the beginning. Notice also how your whole discussion is about webkit and libqt versions, which indicates that the issues are more KDE:Qt related than anything Python.

It's not because a user is hijacking a thread to mention qtwebkit that's it's related in any way.

Am 07.06.21 um 12:48 schrieb Simon Lees:

...

Am 14.04.21 um 22:16 schrieb Luca Beltrame:

...

In data mercoledì 14 aprile 2021 14:46:24 CEST, Ben Greiner ha scritto:

...

As mentioned before, I would favor devel:languages:python:pyqt. I volunteer to participate in maintaining the project, but of course it is at the discretion of the existing maintainers. I'm not sure if I worded it correctly, but I was in agreement with d:l:p:pyqt.

Despite repeated inquiries, Matej is still vetoing d:l:p:pyqt. [1]

* SIP and PyQt[56] are not from the same developers as Qt or KDE * SIP (python-sip) has nothing to do with KDE:Qt* * PyQt[56] is the main but not the only consumer of SIP   - Thus, following Simon's argument [2], python-qt5*, python-PyQt6* and python-sip* should be in the same devel project. * Qt Libraries are packaged into separate projects for each minor version. * The most recent version of PyQt5 compiles with any Qt5 version. The most recent version of PyQt6 compiles with any Qt6 version.   - Thus, putting python-PyQt6 into a KDE:Qt6.X project would be wrong

With the bullet points above, one could argue to put everything into devel:languages:python, but that collides with Matej's veto and Simon's argument. If we can't get d:l:p:pyqt, IMHO the next best thing would be KDE:Qt:PyQt. To me this probably makes slightly more sense then d:l:p:pyqt, d:l:p has never contained all our python packages, packages that are mostly bindings of C / C++ libraries have always tended to live with those

On 6/7/21 12:21 AM, Ben Greiner wrote: libraries.

That's true. It makes sense when the bindings are closely connected to the library. Especially for python-foo subpackages which are built within the same foo.spec as the libfoo.so.* C/C++ library. However: * SIP is a "generic" tool to generate Python bindings for arbitrary C/C++ libraries. E.g. Qt, some Cura libraries, Poppler-Qt5, Calibre. Admittetly they are all *somehow* related to Qt or at least use Qt, but that is not a natural law. * On the other hand, whenever there is a new release of PyQt6, it is very likely that it comes wit a new release of SIP --> they should be in the same devel project. * PyQt[56] does not follow the same release cycles as Qt [56].* --> we need a separate subproject. * The name of the devel subproject is independent of the repository path where the outside packages come from. Unless they are in the same subproject, all python packages with a GUI and importing PyQt5 get their python-qt5 from Factory in any of the discussed scenarios. * Why do we have d:l:p:aws, d:l:p:azure, d:l:p:mailman, d:l:p:numeric and so on? With your reasoning, their complete content should go to Cloud:Tools, server:mail, science, etc. Ben

Am 07.06.21 um 19:50 schrieb Jason Craig:

On 6/7/2021 11:24, Ben Greiner wrote:

...

Am 07.06.21 um 12:48 schrieb Simon Lees:

...

To me this probably makes slightly more sense then d:l:p:pyqt, d:l:p has never contained all our python packages, packages that are mostly bindings of C / C++ libraries have always tended to live with those libraries.

...

* Why do we have d:l:p:aws, d:l:p:azure, d:l:p:mailman, d:l:p:numeric and so on? With your reasoning, their complete content should go to Cloud:Tools, server:mail, science, etc.

Correct me if I'm wrong but these subprojects contain Python applications not, as Simon specifically talked about, Python bindings to C/C++ libraries. Yes you are correct. But I see no resonable argument why applications should go into DEVEL:languages:python:* but bindings should not.

I don't know where SIP should go but it would seem to me that PyQt should go with Qt.

Apparently I am alone with the reasoning laid out in this thread back in February and March, why these packages fit better with Python than with Qt, but I can accept that. As I said, IMHO the next best thing would be KDE:Qt:PyQt.

-- Jason Craig

Ben

Am 07.06.21 um 20:12 schrieb İsmail Dönmez:

Hi,

...

Am 07.06.21 um 19:50 schrieb Jason Craig:

...

I don't know where SIP should go but it would seem to me that PyQt should go with Qt. Apparently I am alone with the reasoning laid out in this thread back in February and March, why these packages fit better with Python than with Qt, but I can accept that. As I said, IMHO the next best thing would be KDE:Qt:PyQt. I honestly cannot believe the level of bikeshedding going on in this

On Mon, Jun 7, 2021 at 8:06 PM Ben Greiner wrote: thread, it's just a piece of string, doesn't matter under d:l:p (rightly so, because these are available from PyPi) or KDE:Qt. Just let people do work, instead of blocking them for no good reason.

ismail

In the meantime, PyQt6.1.1 and qscintilla 2.13.0 have been released. It would be really great to finally get a place where I can submit them. Including their build dependencies, such as python-sip6, python-pyqt-builder. From existing candidate projects where to submit to, nothing fits: - devel:languages:python -  well, just read the thread. - KDE:Qt5 - python-sip and python-sip4 are currently in there, but we need it for PyQt6 and a bunch of other packages too. - KDE:Qt - The description says it is for Qt4 (sic!) - KDE:Qt6 - I am inclined to submit PyQt6 there due to the lack of other option. But python-sip6 is not specific to Qt at all, qscintilla is now a multibuild for Qt5 and Qt6. So where should I submit the packages from https://build.opensuse.org/project/show/home:bnavigator:pyqt to? Ben

On Mon, 2021-07-05 at 16:55 +0200, Christophe Giboudeaux wrote:

I created KDE:Qt:PyQt where you can build PyQt for Leap 15.2, 15.3 and Tumbleweed.

When everything will be built, please ping an openSUSE Factory maintainer to add this repo to the devel projects then create changedevel requests.

No need - a chgdevelreq can be done without whitelisting any prj. The whitelisting is only needed when creating SRs from new projects.

Cheers, Dominique

On Mon, 2021-07-05 at 20:16 +0200, Ben Greiner wrote:

...

...

No need - a chgdevelreq can be done without whitelisting any prj. The whitelisting is only needed when creating SRs from new projects.

sr#904244 to sr#904253 for existing packages. Will the acceptance of one of them promote KDE:Qt:PyQt to a regular whitelisted project so that the new and renamed packages can be submitted afterwards?

Correct; with the first package accepted, the entire project becomes automatically whitelisted as a devel project. Otherwise I'd have to maintain a way too long list manually. Cheers, Dominique

Dne 07. 06. 21 v 19:24 Ben Greiner napsal(a):

* Why do we have d:l:p:aws, d:l:p:azure, d:l:p:mailman, d:l:p:numeric and so on? With your reasoning, their complete content should go to Cloud:Tools, server:mail, science, etc.

Yes, they should. It is mostly for historical reasons, and I am not happy about it, but I don’t have the opportunity (and a reason strong enough) to do anything about it. At least, I am trying not to spread this disease of dumping everything into d:l:p:* further. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Blessed be the God […] who comforts us in all our affliction, so that we may be able to comfort those who are in any affliction, with the comfort with which we ourselves are comforted by God. -- 2. Corinthians 1:3-4