Re: [gentoo-dev] Last rites: multiple unfetchable packages (games-*, net-print/adobeps, sci-chem/xdsstat-bin, sci-libs/{openfoam,parmgridgen})
> sci-libs/openfoam
sci-libs/openfoam is available at https://github.com/OpenFOAM, including
old versions for slots 2.{2,3,4}, each in it's own repository. I haven't
checked whether those ancient version still compile, with the sources from
github, but I've started working on a bump to current version 7, some time
ago, after I noticed that parmgridgen isn't building and I didn't find any
updates for it.
I would consider taking responsibility of the package for the new versions,
once my ebuild is ready and get's accepted into the tree, as it's a package
which can be supported by freecad, on which I'm actively working for almost
a year now.
Thanks all!
Am Sa., 28. Sept. 2019 um 14:35 Uhr schrieb Michał Górny :
> # Michał Górny (2019-09-28)
> # All of the following packages are unfetchable and mirror-restricted.
> #
> # games-fps/enemy-territory-etpro: #638092
> # games-fps/ut2003-bonuspack-cm: #640552
> # games-rpg/runescape-launcher: #625884
> # games-server/bf1942-lnxded: #640576
> # games-server/nwn-ded: #640578
> # games-strategy/mindrover-demo: #640586
> # media-fonts/hkscs-ming: #640590
> # net-print/adobeps: #687000
> # sci-chemistry/xdsstat-bin: #673962
> # sci-libs/parmgridgen (+ revdep sci-libs/openfoam): #633888
> #
> # Removal in 30 days.
> games-fps/enemy-territory-etpro
> games-fps/ut2003-bonuspack-cm
> games-rpg/runescape-launcher
> games-server/bf1942-lnxded
> games-server/nwn-ded
> games-strategy/mindrover-demo
> media-fonts/hkscs-ming
> net-print/adobeps
> sci-chemistry/xdsstat-bin
> sci-libs/openfoam
> sci-libs/parmgridgen
>
> --
> Best regards,
> Michał Górny
>
>
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEKbqdX3+q71mbfP1xLiRqTnFapoMFAlu7OCEACgkQLiRqTnFa
poNFsw//biiEGzWLCUZLsdk1hm2zWrvPlCH877La1bLV/xuqFGs/y4X3Nv4CLX4g
5NWzgWdC1cLDD9hRbY+MM5U1GQjDX1E4rC5c12sA23n4cn0STM97LL4ofYZasBGV
2vIAhkJe+KwFuGhpprjGBqZAbizB2q5ymfNfNUycJxcyadt2Uq52iEheOBNpAIXB
apout3xQlZG+7QRsiqbpOY+UoTPPZJPUNs24YCbBXHUg+8qNnNhvjrleFleWOtOl
U814TOZQSebgUt6IOdVZm3M1tjZSVIgSHvGsWf70zDqLHQW6h5rgp3C6Ie59J9L8
5hPptR01Fu3SiYOQSW1gj1NRZkFZljjWLMGdI21ZA8cQbyqKKo51YLnPETevV17r
OzAE03na0wMxUdXyZMbh5ZykyH9HaSBKSG4Cpbx1ukq2421w8DHgbuW0yN7xyRDY
3KGtBhYPF3P78vhOQONVsCLGq3JWNIHoDWJYaZ9h2Cj1i5RZBN3VoDmMwZq5omdL
Dpbe7y2L2kZRI3qKeg9jQggyjtokyt/usNTAICLDRqWd+Zrqj9HHcgGvKJumGj9m
5JIJeKGl0JwrtvpUHPBh/W27Aium60NylXKxL0biWLHkOLEXVklxEYsdE5s7IZgy
E6ZHEpA55qC64JLkRWh3P+jN4qaLED+QUF856L3+wmhNePMrmSo=
=+sCv
-END PGP SIGNATURE-
Re: [gentoo-dev] Last rites: multiple unfetchable packages (games-*, net-print/adobeps, sci-chem/xdsstat-bin, sci-libs/{openfoam,parmgridgen})
Version 7 doesn't require parmgridgen. I has dependencies on scoth,
paraview and cgal, all of which are available in the tree.
Am Sa., 28. Sept. 2019 um 21:50 Uhr schrieb Michał Górny :
> On Sat, 2019-09-28 at 20:57 +0200, waebbl wrote:
> > > sci-libs/openfoam
> >
> > sci-libs/openfoam is available at https://github.com/OpenFOAM, including
> > old versions for slots 2.{2,3,4}, each in it's own repository. I haven't
> > checked whether those ancient version still compile, with the sources
> from
> > github, but I've started working on a bump to current version 7, some
> time
> > ago, after I noticed that parmgridgen isn't building and I didn't find
> any
> > updates for it.
> > I would consider taking responsibility of the package for the new
> versions,
> > once my ebuild is ready and get's accepted into the tree, as it's a
> package
> > which can be supported by freecad, on which I'm actively working for
> almost
> > a year now.
> >
>
> OpenFOAM is not the problem -- parmgridgen is. OpenFOAM apparently
> requires it unconditionally.
>
> --
> Best regards,
> Michał Górny
>
>
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEKbqdX3+q71mbfP1xLiRqTnFapoMFAlu7OCEACgkQLiRqTnFa
poNFsw//biiEGzWLCUZLsdk1hm2zWrvPlCH877La1bLV/xuqFGs/y4X3Nv4CLX4g
5NWzgWdC1cLDD9hRbY+MM5U1GQjDX1E4rC5c12sA23n4cn0STM97LL4ofYZasBGV
2vIAhkJe+KwFuGhpprjGBqZAbizB2q5ymfNfNUycJxcyadt2Uq52iEheOBNpAIXB
apout3xQlZG+7QRsiqbpOY+UoTPPZJPUNs24YCbBXHUg+8qNnNhvjrleFleWOtOl
U814TOZQSebgUt6IOdVZm3M1tjZSVIgSHvGsWf70zDqLHQW6h5rgp3C6Ie59J9L8
5hPptR01Fu3SiYOQSW1gj1NRZkFZljjWLMGdI21ZA8cQbyqKKo51YLnPETevV17r
OzAE03na0wMxUdXyZMbh5ZykyH9HaSBKSG4Cpbx1ukq2421w8DHgbuW0yN7xyRDY
3KGtBhYPF3P78vhOQONVsCLGq3JWNIHoDWJYaZ9h2Cj1i5RZBN3VoDmMwZq5omdL
Dpbe7y2L2kZRI3qKeg9jQggyjtokyt/usNTAICLDRqWd+Zrqj9HHcgGvKJumGj9m
5JIJeKGl0JwrtvpUHPBh/W27Aium60NylXKxL0biWLHkOLEXVklxEYsdE5s7IZgy
E6ZHEpA55qC64JLkRWh3P+jN4qaLED+QUF856L3+wmhNePMrmSo=
=+sCv
-END PGP SIGNATURE-
Re: [gentoo-dev] Last rites: media-gfx/aoi, media-gfx/exiftags, media-gfx/jpeg2ps
The media-gfx/aoi package looks like it might be worth preserving. I'm currently low on ressources, but I'm going to copy the package over to my overlay, and when I get some time, will bump the package and probably ask for re-adding it. Regards, Bernd Am Mi., 6. Nov. 2019 um 19:53 Uhr schrieb Michał Górny : > # Michał Górny (2019-11-06) > # Old EAPI 0 graphics-related packages. > # > # media-gfx/aoi was last bumped in Nov 2009. It is still actively > # developed upstream, and it's waiting for a bump since Dec 2009. > # It suffers from bundled dependencies (#177026). > # > # media-gfx/exiftags was last bumped in 2007. It did not have any new > # releases since, and does not seem to have any unique features. > # media-gfx/exiv2 seems to be a more commonly installed replacement. > # > # media-gfx/jpeg2ps was last bumped in 2004. The upstream homepage > # is gone. The package is non-free. > # > # Removal in 30 days. Bug #697288. > media-gfx/aoi > media-gfx/exiftags > media-gfx/jpeg2ps > > -- > Best regards, > Michał Górny > > -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEKbqdX3+q71mbfP1xLiRqTnFapoMFAlu7OCEACgkQLiRqTnFa poNFsw//biiEGzWLCUZLsdk1hm2zWrvPlCH877La1bLV/xuqFGs/y4X3Nv4CLX4g 5NWzgWdC1cLDD9hRbY+MM5U1GQjDX1E4rC5c12sA23n4cn0STM97LL4ofYZasBGV 2vIAhkJe+KwFuGhpprjGBqZAbizB2q5ymfNfNUycJxcyadt2Uq52iEheOBNpAIXB apout3xQlZG+7QRsiqbpOY+UoTPPZJPUNs24YCbBXHUg+8qNnNhvjrleFleWOtOl U814TOZQSebgUt6IOdVZm3M1tjZSVIgSHvGsWf70zDqLHQW6h5rgp3C6Ie59J9L8 5hPptR01Fu3SiYOQSW1gj1NRZkFZljjWLMGdI21ZA8cQbyqKKo51YLnPETevV17r OzAE03na0wMxUdXyZMbh5ZykyH9HaSBKSG4Cpbx1ukq2421w8DHgbuW0yN7xyRDY 3KGtBhYPF3P78vhOQONVsCLGq3JWNIHoDWJYaZ9h2Cj1i5RZBN3VoDmMwZq5omdL Dpbe7y2L2kZRI3qKeg9jQggyjtokyt/usNTAICLDRqWd+Zrqj9HHcgGvKJumGj9m 5JIJeKGl0JwrtvpUHPBh/W27Aium60NylXKxL0biWLHkOLEXVklxEYsdE5s7IZgy E6ZHEpA55qC64JLkRWh3P+jN4qaLED+QUF856L3+wmhNePMrmSo= =+sCv -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Anti-spam for goose
Am Do., 21. Mai 2020 um 22:14 Uhr schrieb Viktar Patotski < xp.vit@gmail.com>: I believe that we are all have forgotten about Donald Knuth: Premature > optimisation is the root of all evill. > I won't consider spam protection to be a optimisation. Instead, the occurence of spam is IMO a proper use-case from a developers PoV. Therefore thinking about how to handle it, is a necessary task. -- With Regards Bernd
Re: [gentoo-dev] [RFC] Anti-spam for goose
Am Fr., 22. Mai 2020 um 15:40 Uhr schrieb Gordon Pettey < petteyg...@gmail.com>: > On Fri, May 22, 2020 at 1:18 AM waebbl wrote: > >> Am Do., 21. Mai 2020 um 22:14 Uhr schrieb Viktar Patotski < >> xp.vit@gmail.com>: >> >>> I believe that we are all have forgotten about Donald Knuth: Premature >>> optimisation is the root of all evill. >>> >> I won't consider spam protection to be a optimisation. Instead, the >> occurence of spam is IMO a proper use-case from a developers PoV. Therefore >> thinking about how to handle it, is a necessary task. >> > Abusing Knuth's words as an excuse to avoid any and all good practice is > the root of all evil. > Would you consider not even thinking about it a good practice?
[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-
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-
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] 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 +0000, 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] 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
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 +0000, 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
[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-
