Re: RFC: New devel project devel:languages:python:pyqt and deal with different SIP versions
Dne 23. 02. 21 v 11:05 Cor Blom napsal(a):
Op 19-02-2021 om 20:48 schreef Ben Greiner:
python-sip, python-qt5 and co. have always been kind of a foreign body to C++ focused KDE:Qt5. May I propose to create devel:languages:python:pyqt and put related packages into that one? Maintainers could be python and QT/KDE people together.
I generally applaud the idea: if somebody wants to enclose away some set of packages I don't have to care about, it is always a great idea to me. Especially, if she pulls away from my reach some packages from d:l:p which I won't have to care about. The question remains however, whether it should be more d:l:p:pyqt or whether it should be KDE:Qt:Python (or something like that). Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 But if we find we have left our bones to bleach in these desert sands for nothing, beware the fury of the legions... -- Centurion in a letter home from North Africa 3rd Century
On 23.02.21 11:57, Matěj Cepl wrote:
Dne 23. 02. 21 v 11:05 Cor Blom napsal(a):
Op 19-02-2021 om 20:48 schreef Ben Greiner:
python-sip, python-qt5 and co. have always been kind of a foreign body to C++ focused KDE:Qt5. May I propose to create devel:languages:python:pyqt and put related packages into that one? Maintainers could be python and QT/KDE people together.
I generally applaud the idea: if somebody wants to enclose away some set of packages I don't have to care about, it is always a great idea to me. Especially, if she pulls away from my reach some packages from d:l:p which I won't have to care about.
The question remains however, whether it should be more d:l:p:pyqt or whether it should be KDE:Qt:Python (or something like that).
Even as d:l:p:pyqt with additional maintainers from KDE your workload is lightened, correct? I personally would prefer that over KDE:Qt:Python because the KDE:* tree is a labyrinth to me.
Hello, Am 23.02.21 um 12:04 schrieb Ben Greiner:
On 23.02.21 11:57, Matěj Cepl wrote:
Op 19-02-2021 om 20:48 schreef Ben Greiner:
python-sip, python-qt5 and co. have always been kind of a foreign body to C++ focused KDE:Qt5. May I propose to create devel:languages:python:pyqt and put related packages into that one? Maintainers could be python and QT/KDE people together.
I generally applaud the idea: if somebody wants to enclose away some set of packages I don't have to care about, it is always a great idea to me. Especially, if she pulls away from my reach some packages from d:l:p which I won't have to care about.
The question remains however, whether it should be more d:l:p:pyqt or whether it should be KDE:Qt:Python (or something like that).
Even as d:l:p:pyqt with additional maintainers from KDE your workload is lightened, correct? I personally would prefer that over KDE:Qt:Python because the KDE:* tree is a labyrinth to me.
If I am not mistaken, everybody seems to be in favor of a new project. The demo home:bnavigator:pyqt has been ready for about 2 months. Could the maintainers of d:l:p and KDE(:Qt) please come to an agreement where to put it and then create the project? 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. Regards, Ben
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
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/...
El dom, 6 jun 2021 a las 11:51, Ben Greiner (<code@bnavigator.de>) 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/
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. 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. Ben
El dom, 6 jun 2021 a las 15:03, Ben Greiner (<code@bnavigator.de>) 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/
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. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Las cosas claras y el chocolate espeso. (Ideas should be clear and chocolate thick.) -- Spanish proverb
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.
On 6/7/21 12:21 AM, Ben Greiner wrote:
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 libraries. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Am 07.06.21 um 12:48 schrieb Simon Lees:
On 6/7/21 12:21 AM, Ben Greiner wrote:
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 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
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. I don't know where SIP should go but it would seem to me that PyQt should go with Qt. -- Jason Craig
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
Hi, On Mon, Jun 7, 2021 at 8:06 PM Ben Greiner <code@bnavigator.de> wrote:
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.
I honestly cannot believe the level of bikeshedding going on in this 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
Am 07.06.21 um 20:12 schrieb İsmail Dönmez:
Hi,
On Mon, Jun 7, 2021 at 8:06 PM Ben Greiner <code@bnavigator.de> wrote:
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 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 Saturday, 3 July 2021 20:33:27 CEST Ben Greiner wrote:
Am 07.06.21 um 20:12 schrieb İsmail Dönmez:
Hi,
On Mon, Jun 7, 2021 at 8:06 PM Ben Greiner <code@bnavigator.de> wrote:
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 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.
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.
- KDE:Qt - The description says it is for Qt4 (sic!)
Looking at the build state, I think I'm going to move everything to KDE:Qt: 4.xx and disable build. Christophe
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
Hello, Am 05.07.21 um 18:47 schrieb Dominique Leuenberger / DimStar:
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.
Done, thank you! I am currently the only listed maintainer. Is it enough for you and the other KDE:Qt maintainers to have the maintainership rights through inheritance from superprojects or would it be better to add yourself explicitly to the project, so that you get the notifications?
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.
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? Thanks, Ben
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
On 6/8/21 3:36 AM, Ben Greiner wrote:
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.
Well in my mind applications generally probably also should not, with the exception of maybe packages that ship both applications and libraries and those libraries are used by a number of other python libraries. Most of the python applications I maintain for example are in multimedia:apps or X11:Enlightenment:Factory because at the end of the day most people care far more about what an application does then which language its written in. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
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
participants (9)
-
Ben Greiner -
Christophe Giboudeaux -
Dominique Leuenberger / DimStar -
İsmail Dönmez -
Jason Craig -
Juan Erbes -
Luca Beltrame -
Matěj Cepl -
Simon Lees