Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
On 6/6/20 10:11 PM, Aisha Tammy wrote: > On 6/6/20 2:50 PM, Aaron Bauman wrote: >> All, the graphics project has now been disbanded. >> > Is it weird to ask what happened? > > It seems like a lot of the packages listed here should be and are > very popular :O > > Aisha > Hi, floppym's response sums it up. https://archives.gentoo.org/gentoo-dev/message/c0b5e5e1ab4e0ed77725d4366a5232be jstein started a new thread about this subject, https://archives.gentoo.org/gentoo-dev/message/f9fae5f9583e73e6d4dbf4fc521dd559 -- juippis signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?
On Sun, Jun 07, 2020 at 01:49:28AM +0200, Jonas Stein wrote: > Hi, > > our concept of "Projects" (Herds in the past) maintaining packages has > several problems. [snip] Overall, projects work if the members are active. Of course, they don't if not. So, whether a package is assigned to a project, a sole-maintainer, or co-maintainers means others will *unlikely* attempt to fix or bump the package. Of course, we know that some devs will inevitably bump the package when it get's in their way or they use it directly. However, if the package is assigned to maintainer-needed then proxy-maintainers, random contributors, and other Gentoo devs will feel more comfortable touching it. I believe the system works... I will happily revert my change on the graphics project Wiki as you may want to remove the other inactive members or recruit some folks to join the project. Then possibly pick up the stray packages that others haven't taken. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
On Sat, Jun 6, 2020 at 7:05 PM Andreas K. Hüttel wrote: > That said, I think the basic action is in this case pretty unproductive. We > now have a large number of central libraries maintainer-needed (libpng, jpeg, > tiff, ...) which would really merit a team... Seems like one or two devs have been bumping the packages you listed for the last couple of years, and neither of them are actually members of the graphics project. I don't see the value in a project where none of the members actually maintain their packages.
[gentoo-dev] [RFC] Concept of Projects - How to proceed?
Hi, our concept of "Projects" (Herds in the past) maintaining packages has several problems. Which problems do you see? How can we improve the situation? How do we want to organize/cluster packages in the future? I see the following problems: * We have ten thousand packages for few hundred developers. Projects can not heal the lack of resources. If a developer is member in 10 projects, she/he can only contribute a fraction of the "Gentoo-time" to each project. * Someone added the project to a package many years ago and nobody is left in the project who knows/uses the package. I saw this problem for example in Project:Games, where we have games that need a CD, but there is no developer in the project left who has access to the CD. (If you want to help: https://wiki.gentoo.org/wiki/List_of_discs_by_developers) We have the same problem for hardware in Printing, Video, Sound. * Many projects are too heterogeneous Projects should only maintain either a) many similar packages such as libraries (like Perl, Python) or b) very few strong correlated packages (like KDE, Kernel, Xfce) It makes no sense to group packages by usage as in Science, Games, Theology, Sound, Netmon, Video, Electronics... * We need something between one developer per package, who reacts on every bug within days and the package is unmaintained. * The members of a project are not paid by Gentoo or the lead and want to invest their (spare)time only to specific packages. However a project makes only sense, if all members are willing to maintain the packages of the project. Project Graphics was now deleted without discussion. Have a look at https://wiki.gentoo.org/wiki/Category:Gentoo_Projects there are many projects with the same problem of Graphics. I think we should first find a consent about the following questions before someone deletes projects. * How do we want to delete projects? Vote? Decision by a single dev? Based on statistics? Based on inactivity? Based on lack of manpower? Based on useful package selection? * What is a good structure for a project? * Should we group packages by requirements? (Specific hardware needed. Special skills required.) -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
OK so if you really want to go through with this then I'll take these. > media-gfx/album > media-gfx/enblend > media-gfx/exiv2 > media-gfx/gphoto2 > media-gfx/hugin > media-gfx/imagemagick > media-gfx/jpeg2ps > media-gfx/jhead > media-gfx/luminance-hdr > media-gfx/pngquant > media-libs/lensfun > media-libs/libgphoto2 That said, I think the basic action is in this case pretty unproductive. We now have a large number of central libraries maintainer-needed (libpng, jpeg, tiff, ...) which would really merit a team... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Last rites: app-cdr/sync2d
On Fri, 5 Jun 2020 21:39:51 -0400 Aaron Bauman wrote: > Of course, the depgraph is not an issue. If a package is > masked, it will break immediately. Hence, required checks > are run then the package is masked. I meant that if $P is removed, then things that $P depends on could also start getting removed, which makes it ever harder and harder to install $P if you need it. I wasn’t talking about things that depend on $P. -- Christopher Head pgppPDza5h85T.pgp Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-misc/ifp-line
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dfd5b4cbfed70172cbd76d43d7dab2f852f66265 commit dfd5b4cbfed70172cbd76d43d7dab2f852f66265 Author: Jonas Stein AuthorDate: 2020-06-06 22:19:30 + Commit: Jonas Stein CommitDate: 2020-06-06 22:19:30 + profiles: app-misc/ifp-line Last rites Last rites for unusable package. Bug: https://bugs.gentoo.org/727360 -- Best regards, Jonas Stein signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 0/2] multilib.eclass: improve multilib handling of pkg-config
On Sat, 6 Jun 2020 15:24:03 -0400 Mike Gilbert wrote: > These patches are part of a larger change to eliminate MULTILIB_USEDEP > from virtual/pkgconfig dependencies in BDEPEND. > > See https://bugs.gentoo.org/723112 and > https://github.com/gentoo/gentoo/pull/16025. > > Mike Gilbert (2): > multilib.eclass: export PKG_CONFIG_SYSTEM_LIBRARY_PATH in > multilib_toolchain_setup > multilib.eclass: export PKG_CONFIG in multilib_toolchain_setup > > eclass/multilib.eclass | 4 > 1 file changed, 4 insertions(+) > Looks good! -- Sergei
[gentoo-dev] [PATCH 1/2] multilib.eclass: export PKG_CONFIG_SYSTEM_LIBRARY_PATH in multilib_toolchain_setup
This ensures pkg-config --libs will filter -L/usr/lib from its output for
non-native ABIs.
Signed-off-by: Mike Gilbert
---
eclass/multilib.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index ed54568aa2d9..3503ac2ed5b7 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -472,6 +472,7 @@ multilib_toolchain_setup() {
STRIP
PKG_CONFIG_LIBDIR
PKG_CONFIG_PATH
+ PKG_CONFIG_SYSTEM_LIBRARY_PATH
)
# First restore any saved state we have laying around.
@@ -516,6 +517,7 @@ multilib_toolchain_setup() {
export CHOST=$(get_abi_CHOST $1)
export PKG_CONFIG_LIBDIR=${EPREFIX}/usr/$(get_libdir)/pkgconfig
export PKG_CONFIG_PATH=${EPREFIX}/usr/share/pkgconfig
+ export
PKG_CONFIG_SYSTEM_LIBRARY_PATH=${EPREFIX}/usr/$(get_libdir)
fi
}
--
2.27.0.rc2
[gentoo-dev] [PATCH 2/2] multilib.eclass: export PKG_CONFIG in multilib_toolchain_setup
This ensures that autoconf will not try to use a crossdev wrapper for
non-native ABIs. Instead, we always use the native pkg-config, and
override its behavior via PKG_CONFIG_LIBDIR and
PKG_CONFIG_SYSTEM_LIBRARY_PATH.
Signed-off-by: Mike Gilbert
---
eclass/multilib.eclass | 2 ++
1 file changed, 2 insertions(+)
diff --git a/eclass/multilib.eclass b/eclass/multilib.eclass
index 3503ac2ed5b7..54ff1509eada 100644
--- a/eclass/multilib.eclass
+++ b/eclass/multilib.eclass
@@ -467,6 +467,7 @@ multilib_toolchain_setup() {
LD
NM
OBJDUMP
+ PKG_CONFIG
RANLIB
READELF
STRIP
@@ -511,6 +512,7 @@ multilib_toolchain_setup() {
export LD="$(tc-getLD) $(get_abi_LDFLAGS)"
export NM="$(tc-getNM)" # Avoid 'nm', use '${CHOST}-nm'
export OBJDUMP="$(tc-getOBJDUMP)" # Avoid 'objdump', use
'${CHOST}-objdump'
+ export PKG_CONFIG="$(tc-getPKG_CONFIG)"
export RANLIB="$(tc-getRANLIB)" # Avoid 'ranlib', use
'${CHOST}-ranlib'
export READELF="$(tc-getREADELF)" # Avoid 'readelf', use
'${CHOST}-readelf'
export STRIP="$(tc-getSTRIP)" # Avoid 'strip', use
'${CHOST}-strip'
--
2.27.0.rc2
[gentoo-dev] [PATCH 0/2] multilib.eclass: improve multilib handling of pkg-config
These patches are part of a larger change to eliminate MULTILIB_USEDEP from virtual/pkgconfig dependencies in BDEPEND. See https://bugs.gentoo.org/723112 and https://github.com/gentoo/gentoo/pull/16025. Mike Gilbert (2): multilib.eclass: export PKG_CONFIG_SYSTEM_LIBRARY_PATH in multilib_toolchain_setup multilib.eclass: export PKG_CONFIG in multilib_toolchain_setup eclass/multilib.eclass | 4 1 file changed, 4 insertions(+) -- 2.27.0.rc2
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
On 6/6/20 2:50 PM, Aaron Bauman wrote: > All, the graphics project has now been disbanded. > Is it weird to ask what happened? It seems like a lot of the packages listed here should be and are very popular :O Aisha > All packages have been reassigned to maintainer-needed. Bugs will be > reassigned soon. > > Here are a list of the packages that are now up for grabs: > > dev-cpp/pngpp > media-gfx/album > media-gfx/apng2gif > media-gfx/apngasm > media-gfx/apngdis > media-gfx/apngopt > media-gfx/autopano-sift-C > media-gfx/blender > media-gfx/cellwriter > media-gfx/chafa > media-gfx/cptutils > media-gfx/darktable > media-gfx/dcraw > media-gfx/duhdraw > media-gfx/enblend > media-gfx/exact-image > media-gfx/exif > media-gfx/exiv2 > media-gfx/feh > media-gfx/fim > media-gfx/fontypython > media-gfx/fr0st > media-gfx/gif2apng > media-gfx/gif2png > media-gfx/gifsicle > media-gfx/gimageview > media-gfx/gmic > media-gfx/gnofract4d > media-gfx/gphoto2 > media-gfx/gphotofs > media-gfx/gpicview > media-gfx/gqview > media-gfx/graphicsmagick > media-gfx/grub-splashes > media-gfx/gtkam > media-gfx/gtkimageview > media-gfx/hugin > media-gfx/icon-slicer > media-gfx/igal > media-gfx/imagemagick > media-gfx/jhead > media-gfx/jigl > media-gfx/jpeg2ps > media-gfx/jpeginfo > media-gfx/jpegoptim > media-gfx/jpegpixi > media-gfx/jpegtoavi > media-gfx/libimagequant > media-gfx/llgal > media-gfx/luminance-hdr > media-gfx/mandelbulber > media-gfx/mcomix > media-gfx/metapixel > media-gfx/mscgen > media-gfx/nvidia-cg-toolkit > media-gfx/openclipart > media-gfx/panini > media-gfx/pdf2svg > media-gfx/png2ico > media-gfx/pngcheck > media-gfx/pngcrush > media-gfx/pngquant > media-gfx/pngrewrite > media-gfx/pngtools > media-gfx/potrace > media-gfx/povtree > media-gfx/pqiv > media-gfx/pqstego > media-gfx/qiv > media-gfx/qvv > media-gfx/raw-thumbnailer > media-gfx/rawtherapee > media-gfx/rotoscope > media-gfx/scantailor-advanced > media-gfx/scour > media-gfx/scrot > media-gfx/sfftobmp > media-gfx/shotwell > media-gfx/sxiv > media-gfx/tintii > media-gfx/tuxpaint-stamps > media-gfx/tuxpaint > media-gfx/ufraw > media-gfx/uniconvertor > media-gfx/wings > media-gfx/wkhtmltopdf > media-gfx/xli > media-gfx/xloadimage > media-gfx/xsane > media-gfx/xzgv > media-libs/cimg > media-libs/esdl > media-libs/exiftool > media-libs/flickcurl > media-libs/gd > media-libs/giblib > media-libs/giflib > media-libs/icclib > media-libs/imlib > media-libs/jbig2dec > media-libs/jbigkit > media-libs/jpeg > media-libs/lasi > media-libs/lensfun > media-libs/libexif-gtk > media-libs/libexif > media-libs/libfpx > media-libs/libgphoto2 > media-libs/libharu > media-libs/libheif > media-libs/libicns > media-libs/libjpeg-turbo > media-libs/libmng > media-libs/libpano13 > media-libs/libpgf > media-libs/libpqstego > media-libs/libraw > media-libs/libwebp > media-libs/netpbm > media-libs/opencolorio > media-libs/openimageio > media-libs/openjpeg > media-libs/pnglite > media-libs/stimg > media-libs/tiff > media-libs/urt > sci-visualization/grace > virtual/imagemagick-tools > virtual/jpeg-compat > virtual/jpeg > x11-libs/gdk-pixbuf-loader-webp > x11-misc/gromit > x11-misc/shutter > signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
On Sat, Jun 06, 2020 at 02:50:31PM -0400, Aaron Bauman wrote: > All, the graphics project has now been disbanded. > > All packages have been reassigned to maintainer-needed. Bugs will be > reassigned soon. > > Here are a list of the packages that are now up for grabs: > > dev-cpp/pngpp To expound on this, the graphics project has a quite a few bugs assigned to them (169). A few packages have co-maintainers, but these are still reflected in the metadata as required. If anyone else has time to address the bugs or wants to take the package over please do. If you hit a package with a co-maintainer then my apologies. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
On Sat, Jun 06, 2020 at 08:55:38PM +0200, Pacho Ramos wrote: > El sáb, 06-06-2020 a las 14:50 -0400, Aaron Bauman escribió: > > All, the graphics project has now been disbanded. > > > > All packages have been reassigned to maintainer-needed. Bugs will be > > reassigned soon. > > > > Here are a list of the packages that are now up for grabs: > > > [...] > > I have seen that many of them already have maintainers or co-maintainers, > maybe > listing only those that are going to maintainer-needed would be more useful to > catch packages needing attention > > Thanks Pacho, thanks. I did not remove those packages from the email, but the metadata still reflects properly. A cursory look at the packages with more than 1 maintainer seems rather small. -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
El sáb, 06-06-2020 a las 14:50 -0400, Aaron Bauman escribió: > All, the graphics project has now been disbanded. > > All packages have been reassigned to maintainer-needed. Bugs will be > reassigned soon. > > Here are a list of the packages that are now up for grabs: > [...] I have seen that many of them already have maintainers or co-maintainers, maybe listing only those that are going to maintainer-needed would be more useful to catch packages needing attention Thanks signature.asc Description: This is a digitally signed message part
[gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
All, the graphics project has now been disbanded. All packages have been reassigned to maintainer-needed. Bugs will be reassigned soon. Here are a list of the packages that are now up for grabs: dev-cpp/pngpp media-gfx/album media-gfx/apng2gif media-gfx/apngasm media-gfx/apngdis media-gfx/apngopt media-gfx/autopano-sift-C media-gfx/blender media-gfx/cellwriter media-gfx/chafa media-gfx/cptutils media-gfx/darktable media-gfx/dcraw media-gfx/duhdraw media-gfx/enblend media-gfx/exact-image media-gfx/exif media-gfx/exiv2 media-gfx/feh media-gfx/fim media-gfx/fontypython media-gfx/fr0st media-gfx/gif2apng media-gfx/gif2png media-gfx/gifsicle media-gfx/gimageview media-gfx/gmic media-gfx/gnofract4d media-gfx/gphoto2 media-gfx/gphotofs media-gfx/gpicview media-gfx/gqview media-gfx/graphicsmagick media-gfx/grub-splashes media-gfx/gtkam media-gfx/gtkimageview media-gfx/hugin media-gfx/icon-slicer media-gfx/igal media-gfx/imagemagick media-gfx/jhead media-gfx/jigl media-gfx/jpeg2ps media-gfx/jpeginfo media-gfx/jpegoptim media-gfx/jpegpixi media-gfx/jpegtoavi media-gfx/libimagequant media-gfx/llgal media-gfx/luminance-hdr media-gfx/mandelbulber media-gfx/mcomix media-gfx/metapixel media-gfx/mscgen media-gfx/nvidia-cg-toolkit media-gfx/openclipart media-gfx/panini media-gfx/pdf2svg media-gfx/png2ico media-gfx/pngcheck media-gfx/pngcrush media-gfx/pngquant media-gfx/pngrewrite media-gfx/pngtools media-gfx/potrace media-gfx/povtree media-gfx/pqiv media-gfx/pqstego media-gfx/qiv media-gfx/qvv media-gfx/raw-thumbnailer media-gfx/rawtherapee media-gfx/rotoscope media-gfx/scantailor-advanced media-gfx/scour media-gfx/scrot media-gfx/sfftobmp media-gfx/shotwell media-gfx/sxiv media-gfx/tintii media-gfx/tuxpaint-stamps media-gfx/tuxpaint media-gfx/ufraw media-gfx/uniconvertor media-gfx/wings media-gfx/wkhtmltopdf media-gfx/xli media-gfx/xloadimage media-gfx/xsane media-gfx/xzgv media-libs/cimg media-libs/esdl media-libs/exiftool media-libs/flickcurl media-libs/gd media-libs/giblib media-libs/giflib media-libs/icclib media-libs/imlib media-libs/jbig2dec media-libs/jbigkit media-libs/jpeg media-libs/lasi media-libs/lensfun media-libs/libexif-gtk media-libs/libexif media-libs/libfpx media-libs/libgphoto2 media-libs/libharu media-libs/libheif media-libs/libicns media-libs/libjpeg-turbo media-libs/libmng media-libs/libpano13 media-libs/libpgf media-libs/libpqstego media-libs/libraw media-libs/libwebp media-libs/netpbm media-libs/opencolorio media-libs/openimageio media-libs/openjpeg media-libs/pnglite media-libs/stimg media-libs/tiff media-libs/urt sci-visualization/grace virtual/imagemagick-tools virtual/jpeg-compat virtual/jpeg x11-libs/gdk-pixbuf-loader-webp x11-misc/gromit x11-misc/shutter -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: app-cdr/sync2d
Ühel kenal päeval, L, 06.06.2020 kell 03:59, kirjutas Ralph Seichter: > * Christopher Head: > > > Not that I care about this specific case, but isn’t the 30-day time > > period also meant as a nice long warning time for people [...] > > Rules and exceptions. I think that shortening the typical 30-day > period > is acceptable in specific cases, and sync2d is one of them. According > to > Git history, the ebuild for release 1.3 (released 2007) was imported > in > August 2015 and no functional changes have been made since then. > There > were only meta data updates and stabilisations, and it all ended in > 2017. > > sync2d is unmaintained in Gentoo and based on Python 2, which, as we > know, was marked for "end of support 2015" which later was extended > to > January 2020. Upstream had oodles of time to migrate to Python 3 if > they > wanted to. If (!) any Gentoo users are still using sync2d today, they > also had ample time to choose an alternative. From all appearances, > sync2d has gone the way of the dodo. > > Masking will not uninstall the package, and the sooner people can no > longer install sync2d without thought, the better, as far as I am > concerned. Portage does not provide a good mechanism of warning users that some package is going or already went away, other than the package.mask entry triggering such a warning. So if it's removed quickly and p.mask removed with that, users of said package will not be notified for a reasonable amount of time to even notice that they have something unmaintained installed. Until that is working better, I find it good to have a package.mask entry for 30 days or even longer. That does not mean the specific package itself can't go away in 15 days - the package.mask entry could be reworded and kept for a bit longer. Mart signature.asc Description: This is a digitally signed message part
