[gentoo-dev] Last rites: media-libs/ilmbase
# Bernd Waibel (2023-01-28) # Possible security issues, obsolete. Use OpenEXR-3 / Imath instead. # No revdeps and consumers left in ::gentoo # Removal in 30 days. Bug #892375 media-libs/ilmbase -BEGIN PGP SIGNATURE- iQGTBAEBCgB9FiEExIg3+Emk70nqAQ2ybb4K1Uo7McYFAmJOvDBfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM0 ODgzN0Y4NDlBNEVGNDlFQTAxMERCMjZEQkUwQUQ1NEEzQjMxQzYACgkQbb4K1Uo7 McbyjggA40un5MrP8DyyVmJXRUTSrxNHbCFck/7vCRHuHfync2bCFYk3JqvfFcu3 D5ms7sH+3ZBxGgUtCG7LwWOQZ89pSkQFXPCu+4Pb0LlVgz6x+lFyGNXdT1g4RyXu 1TzqQlok5gOmlxJ+aK+C6CmzN7e+0Mfe8lGHVLfcukzjlCglochavIXuiG7KNiTB 4rUSeVLJ6OaLkeqYQ4EYrhU8gkiA8nsH4TqXWxmB6cFhfy0e1wOGlkK31Q9jmmZp R4qpRF2QwH7CAKlIW9TT8fZ0kw06UVoGosm8lxMA2wQ2WycTnPp7kbRaTvdENEqb UggCF7hh2g7Y6LSh33f2l6TNlxH0tA== =G4KG -END PGP SIGNATURE-
Re: [gentoo-dev] Up for grabs: dev-python/pyside2
Am 13.08.2022 11:51 schrieb Andrew Ammerlaan: On 13/08/2022 11:10, waebbl-gen...@posteo.net wrote: Thanks Andrew for taking care of these packages. Like I said, I'd be happy to comaintain the packages and keep an additional two eyes on them. Great! Would you like me to add you to the metadata.xml files so you'll get CC'ed on the bugs? Best regards, Andrew You're welcome to do so. Don't forget that I'm a proxy-maintainer. Regards, Bernd
Re: [gentoo-dev] Up for grabs: dev-python/pyside2
On Fri, 12 Aug 2022 17:28:49 +0200 Andrew Ammerlaan wrote: > On 29/07/2022 13:06, Ionen Wolkens wrote: > > On Fri, Jul 29, 2022 at 10:30:20AM +, waebbl-gen...@posteo.net wrote: > >> On Sun, 17 Jul 2022 23:11:08 +0100 > >> Sam James wrote: > >> > >>> Up for grabs because of inactivity. > >>> > >>> dev-python/pyside2 has several open bugs and a version bump pending. > >>> > >>> Needs some real love to tidy it up. > >>> > >>> Best, > >>> sam > >> > >> Wouldn't it be applicable to put these packages under the umbrella of > >> the Gentoo Qt project? > > > > It still need someone to maintain it either way, qt@ is rather small > > and Qt6 is likely to use up people's time already. Being m-n at least > > make its current state clear (up to qt@ though). > > > >> They're developed, published and hosted by the The Qt Company (in > >> contrast for example to PyQt5 or QtPy) and are only python > >> bindings for the Qt framework, although they're currently distributed > >> in a separate tarball and not with the Qt tarball. > > > > On a side-note I'll be adding PyQt6 to the tree once I can[1], but I > > don't use pyside for anything and probably won't be looking at pyside6. > > > > [1] https://github.com/gentoo/gentoo/pull/26504 > > I've added myself as the maintainer of shiboken2 and pyside2(-tools). I > also added shiboken6 and pyside6(-tools) (masked for testing). > Unfortunately the latter is stuck on python3_10 only at the moment, > adding python3_11 to this is a whole new can of worms. > > Help with these packages is most welcome. They are notoriously difficult > and fragile. > > Best regards, > Andrew > Thanks Andrew for taking care of these packages. Like I said, I'd be happy to comaintain the packages and keep an additional two eyes on them. In my draft[1] for pyside6, I've also found the python 3.11 incompatibility and removed it for further investigation. However, what I noticed, is, that upstream only has compatibility for python3 up to 3.10. Closing my draft, now that the package has been merged into the tree. [1] https://github.com/gentoo/gentoo/pull/26782 Best, Bernd
Re: [gentoo-dev] USE=ninja to compile by ninja, otherwise by make
On Sat, 30 Jul 2022 00:38:54 +0800 Fabulous Zhang Zheng wrote: > Dear everyone, > > > While gentoo-devhelp is a better place for questions, it's been inactive > for years so I sent an email here. Apologies if this is solely for gentoo > developers. There's #gentoo-dev-help > > After trying to read cmake.eclass source code, I think separately denoting > ninja/make in src_compile and src_install might be possible. But > cmake_build still automatically detects the build type so I am confused. > Take a look at CMAKE_MAKEFILE_GENERATOR variable used in cmake.eclass. You want to change this from the default to emake if you want to use make instead of ninja.
Re: [gentoo-dev] Up for grabs: dev-python/pyside2
On Fri, 29 Jul 2022 07:06:06 -0400 Ionen Wolkens wrote: > On Fri, Jul 29, 2022 at 10:30:20AM +, waebbl-gen...@posteo.net wrote: > > On Sun, 17 Jul 2022 23:11:08 +0100 > > Sam James wrote: > > > > > Up for grabs because of inactivity. > > > > > > dev-python/pyside2 has several open bugs and a version bump pending. > > > > > > Needs some real love to tidy it up. > > > > > > Best, > > > sam > > > > Wouldn't it be applicable to put these packages under the umbrella of > > the Gentoo Qt project? > > It still need someone to maintain it either way, qt@ is rather small > and Qt6 is likely to use up people's time already. Being m-n at least > make its current state clear (up to qt@ though). > I can think of co-maintaining the packages, but it exceeds my resources to being primary maintainer. > > They're developed, published and hosted by the The Qt Company (in > > contrast for example to PyQt5 or QtPy) and are only python > > bindings for the Qt framework, although they're currently distributed > > in a separate tarball and not with the Qt tarball. > > On a side-note I'll be adding PyQt6 to the tree once I can[1], but I > don't use pyside for anything and probably won't be looking at pyside6. > I'm slowly working towards shiboken6 / pyside6. Pyside is needed for the Qt6 move of FreeCAD, at it's current state at least. There are discussion on completely moving to pybind11 instead of pyside, but that's not yet decided. So I will probably need pyside6 for the sake of FreeCAD. > [1] https://github.com/gentoo/gentoo/pull/26504 pgpAfI8Ibfe_d.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Up for grabs: dev-python/pyside2
On Sun, 17 Jul 2022 23:11:08 +0100 Sam James wrote: > Up for grabs because of inactivity. > > dev-python/pyside2 has several open bugs and a version bump pending. > > Needs some real love to tidy it up. > > Best, > sam Wouldn't it be applicable to put these packages under the umbrella of the Gentoo Qt project? They're developed, published and hosted by the The Qt Company (in contrast for example to PyQt5 or QtPy) and are only python bindings for the Qt framework, although they're currently distributed in a separate tarball and not with the Qt tarball. Resending due to wrong sender being used. Regards, Bernd pgpN6407DJvvo.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] proposal
On Mon, 4 Jul 2022 22:49:25 -0400 Ionen Wolkens wrote: On Mon, Jul 04, 2022 at 04:19:12PM +0200, Florian Schmaus wrote: > I'd like to propose a new metadata XML element for packages: > > > > Maintainers can signal to other developers (and of course contributors > in general) that they are happy with others to make changes to the > ebuilds without prior consultation of the maintainer. > > Of course, this is not a free ticket to always make changes to packages > that you do not maintain without prior consultation of the maintainer. I > would expect people to use their common sense to decide if a change may > require maintainer attention or not. In general, it is always a good > idea to communicate changes in every case. > > The absence of the flag does not automatically allow the conclusion that > the maintainer is opposed to non-maintainer commits. It just means that > the maintainer's stance is not known. I do not believe that we need a > flag, but if the need arises, we > could always consider adding one. Although, in my experience, people > mostly like to communicate the "non-maintainer commits welcome" policy > with others. > > WDYT? Personally I think something per-maintainer rather than per package would be simpler, and allow to say more as needed. Think like devaway instructions, but something more permanent and not for being away, e.g. "feel free to touch my packages except this big important one, and or do or do not do this to them" I think it would be more efficient if we use a flag on a per-maintainer basis. But it adds extra overhead, if the maintainer doesn't want some special packages to be touched, or if special cases, like bumps need to be avoided. We could add a central file, something like the metadata/AUTHORS file with this information. Possibly in a structured format like xml or json to make it machine readable as well and the information can be extracted and shown e.g. on the wiki or p.g.o site. Something like the devaway instructions could lock out proxy maintainers, which don't have access to the Gentoo infrastructure. > > - Flow > -BEGIN PGP SIGNATURE- iQGTBAEBCgB9FiEExIg3+Emk70nqAQ2ybb4K1Uo7McYFAmJOvDBfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM0 ODgzN0Y4NDlBNEVGNDlFQTAxMERCMjZEQkUwQUQ1NEEzQjMxQzYACgkQbb4K1Uo7 McbyjggA40un5MrP8DyyVmJXRUTSrxNHbCFck/7vCRHuHfync2bCFYk3JqvfFcu3 D5ms7sH+3ZBxGgUtCG7LwWOQZ89pSkQFXPCu+4Pb0LlVgz6x+lFyGNXdT1g4RyXu 1TzqQlok5gOmlxJ+aK+C6CmzN7e+0Mfe8lGHVLfcukzjlCglochavIXuiG7KNiTB 4rUSeVLJ6OaLkeqYQ4EYrhU8gkiA8nsH4TqXWxmB6cFhfy0e1wOGlkK31Q9jmmZp R4qpRF2QwH7CAKlIW9TT8fZ0kw06UVoGosm8lxMA2wQ2WycTnPp7kbRaTvdENEqb UggCF7hh2g7Y6LSh33f2l6TNlxH0tA== =G4KG -END PGP SIGNATURE-
[gentoo-dev] Last rites: dev-python/pyilmbase: 2.5.7{,-r1}
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Bernd Waibel (2022-04-07) # No consumers left. Superseded by dev-libs/imath[python] # Removal in 30 days. dev-python/pyilmbase -BEGIN PGP SIGNATURE- iQGTBAEBCgB9FiEExIg3+Emk70nqAQ2ybb4K1Uo7McYFAmJOvDBfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM0 ODgzN0Y4NDlBNEVGNDlFQTAxMERCMjZEQkUwQUQ1NEEzQjMxQzYACgkQbb4K1Uo7 McbyjggA40un5MrP8DyyVmJXRUTSrxNHbCFck/7vCRHuHfync2bCFYk3JqvfFcu3 D5ms7sH+3ZBxGgUtCG7LwWOQZ89pSkQFXPCu+4Pb0LlVgz6x+lFyGNXdT1g4RyXu 1TzqQlok5gOmlxJ+aK+C6CmzN7e+0Mfe8lGHVLfcukzjlCglochavIXuiG7KNiTB 4rUSeVLJ6OaLkeqYQ4EYrhU8gkiA8nsH4TqXWxmB6cFhfy0e1wOGlkK31Q9jmmZp R4qpRF2QwH7CAKlIW9TT8fZ0kw06UVoGosm8lxMA2wQ2WycTnPp7kbRaTvdENEqb UggCF7hh2g7Y6LSh33f2l6TNlxH0tA== =G4KG -END PGP SIGNATURE-
