[gentoo-dev] Last rites: php-ext-source-r2.eclass

2020-06-07 Thread Joonas Niilola
No ebuilds in the tree use this eclass anymore, since php-ext-source-r3
exists. Removal in ~30 days. Bug #727472.

-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2020-06-07 23:59 UTC

2020-06-07 Thread Robin H. Johnson
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2020-06-07 23:59 UTC.

Removals:
media-plugins/gimp-lensfun 20200601-22:18 asturm 63cf8d6f236
x11-drivers/xf86-input-keyboard20200606-10:57 slashbeast 0e6b1d8cf0d
x11-drivers/xf86-input-mouse   20200606-10:57 slashbeast 0e6b1d8cf0d

Additions:
acct-group/motion  20200604-07:04 juippis8d6281579d9
acct-user/motion   20200604-07:05 juippis1d0f7143e0c
app-backup/kup 20200602-14:09 asturm fd92483d159
dev-libs/libucl20200426-16:09 bman   effe59a4a91
dev-python/asteval 20200607-10:36 pacho  d5712a4e760
dev-python/black   20200602-22:15 chutzpah   17e0e5f755f
dev-python/klein   20200601-04:06 dolsen 5e038299cef
dev-python/lmfit   20200607-10:38 pacho  474620d5b9d
dev-python/python-dotenv   20200603-16:02 sping  b0200d1528d
dev-python/tubes   20200601-00:54 dolsen 2b487afce49
dev-ruby/sys-uname 20200607-08:34 graaff 9c8c5ead1d7
dev-util/buildbot-badges   20200601-20:30 dolsen 961c3974a74
dev-util/cucumber-cucumber-expressions 20200607-09:06 graaff 7970871b5c0
dev-util/cucumber-tag-expressions  20200607-08:58 graaff 78ffd36be3b
gui-apps/lavalauncher  20200518-02:15 bman   d9417ccd322
gui-wm/hikari  20200426-16:15 bman   10ac27bddb6
kde-plasma/kwayland-server 20200604-14:21 asturm 9931cc419a3
mail-mta/notqmail  20200521-08:57 mgorny d331eb76b16
sci-libs/volk  20200529-16:02 zerochaos  07401ce1325

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
x11-drivers/xf86-input-keyboard,removed,slashbeast,20200606-10:57,0e6b1d8cf0d
x11-drivers/xf86-input-mouse,removed,slashbeast,20200606-10:57,0e6b1d8cf0d
media-plugins/gimp-lensfun,removed,asturm,20200601-22:18,63cf8d6f236
Added Packages:
dev-python/lmfit,added,pacho,20200607-10:38,474620d5b9d
dev-python/asteval,added,pacho,20200607-10:36,d5712a4e760
dev-util/cucumber-cucumber-expressions,added,graaff,20200607-09:06,7970871b5c0
dev-util/cucumber-tag-expressions,added,graaff,20200607-08:58,78ffd36be3b
dev-ruby/sys-uname,added,graaff,20200607-08:34,9c8c5ead1d7
gui-apps/lavalauncher,added,bman,20200518-02:15,d9417ccd322
gui-wm/hikari,added,bman,20200426-16:15,10ac27bddb6
dev-libs/libucl,added,bman,20200426-16:09,effe59a4a91
mail-mta/notqmail,added,mgorny,20200521-08:57,d331eb76b16
kde-plasma/kwayland-server,added,asturm,20200604-14:21,9931cc419a3
acct-user/motion,added,juippis,20200604-07:05,1d0f7143e0c
acct-group/motion,added,juippis,20200604-07:04,8d6281579d9
dev-python/python-dotenv,added,sping,20200603-16:02,b0200d1528d
dev-python/black,added,chutzpah,20200602-22:15,17e0e5f755f
app-backup/kup,added,asturm,20200602-14:09,fd92483d159
dev-util/buildbot-badges,added,dolsen,20200601-20:30,961c3974a74
dev-python/klein,added,dolsen,20200601-04:06,5e038299cef
dev-python/tubes,added,dolsen,20200601-00:54,2b487afce49
sci-libs/volk,added,zerochaos,20200529-16:02,07401ce1325

Done.

Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

2020-06-07 Thread Rich Freeman
On Sun, Jun 7, 2020 at 7:22 PM Philip Webb  wrote:
>
> 200607 Pacho Ramos wrote:
> > I think this is the list of completely unmaintained packages now,
> > indeed most of them, around 100.
>
> -- extract from list --
>
> > media-gfx/imagemagick : 200516
> > media-libs/giflib : 200312
> > media-libs/libjpeg-turbo : 200328
> > media-libs/openjpeg : 200328
> > virtual/jpeg : 200606
>
> There have been upgrades of all these in recent months :
> dates when I upgraded on my desktop system are added (the last yesterday).
> Surely, that means someone is maintaining them.
> Perhaps the culprits could own up (smile).
>
> As a long-time user, I find it disturbing
> that a huge list of packages should suddenly be declared unmaintained,
> esp as some of them -- eg above -- are likely needed by most users.

They were not maintained by identified developers before - that is the
point.  The only thing that is changing is that metadata is being
updated to reflect reality.  Now these packages will get more notice
and developers can set up and maintain them as needed.

The packages aren't being removed - just the project.

If any of the packages assigned to the graphics projects already had
individual maintainers then those would still remain after the project
is removed.

Put it this way - suppose we created a project called "dummy" with no
developers in it, and we assigned that project to all the packages
that are maintaner-needed.  Would that actually change anything?  XML
tags in metadata files don't maintain packages - people do.

This sort of thing has happened many times in the past.  Sometimes it
does result in packages getting treecleaned, but mainly when they have
other serious issues.  Popular packages aren't likely to get removed
this way - certainly not something like libjpeg or imagemagick and so
on.

-- 
Rich



Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

2020-06-07 Thread Sam James



> On 8 Jun 2020, at 00:22, Philip Webb  wrote:
> 
> 200607 Pacho Ramos wrote:
>> I think this is the list of completely unmaintained packages now,
>> indeed most of them, around 100.
> 
> -- extract from list --
> 
>> media-gfx/imagemagick : 200516
>> media-libs/giflib : 200312
>> media-libs/libjpeg-turbo : 200328
>> media-libs/openjpeg : 200328
>> virtual/jpeg : 200606
> 
> There have been upgrades of all these in recent months :
> dates when I upgraded on my desktop system are added (the last yesterday).

Basically all of these get done by us in security@ because they tend to have 
vulnerabilities and they are core packages.

> Surely, that means someone is maintaining them.
> Perhaps the culprits could own up (smile).

Maybe. If nobody else does, I will, but it’s easier if someone with +w does for 
now.

> 
> As a long-time user, I find it disturbing
> that a huge list of packages should suddenly be declared unmaintained,
> esp as some of them -- eg above -- are likely needed by most users.

They’re declared to not have a named maintainer — I promise you, they are not 
going anywhere,
even though this appears concerning. With graphics@, it was an “open secret” 
that they were
unmaintained, now it’s clear that anyone is welcome to help.

I hope this helps reassure you a bit — the gist is, they’re not going anywhere, 
and
nobody would let these packages leave the tree.

This is essentially just making the formalities reflect reality — to be clear 
we’re welcome
to touch these packages and help.

> 
> -- 
> ,,
> SUPPORT ___//___,   Philip Webb
> ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
> TRANSIT`-O--O---'   purslowatcadotinterdotnet
> 
> 




Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

2020-06-07 Thread Philip Webb
200607 Pacho Ramos wrote:
> I think this is the list of completely unmaintained packages now,
> indeed most of them, around 100.
 
-- extract from list --

> media-gfx/imagemagick : 200516
> media-libs/giflib : 200312
> media-libs/libjpeg-turbo : 200328
> media-libs/openjpeg : 200328
> virtual/jpeg : 200606

There have been upgrades of all these in recent months :
dates when I upgraded on my desktop system are added (the last yesterday).
Surely, that means someone is maintaining them.
Perhaps the culprits could own up (smile).

As a long-time user, I find it disturbing
that a huge list of packages should suddenly be declared unmaintained,
esp as some of them -- eg above -- are likely needed by most users.

-- 
,,
SUPPORT ___//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT`-O--O---'   purslowatcadotinterdotnet




[gentoo-dev] net-p2p/nicotine+: No maintainer, depends on dev-python/pygtk

2020-06-07 Thread Andreas Sturmlechner
Package has been slow to port away from pygtk [1] and python2 and is one of 
the last remaining blockers. [2]

Meanwhile, upstream actually managed to port to gtk3 and recently merged that 
work to master. [3] A new release is imminent [4] so now is the time to start 
work on an ebuild.

If you are using this package, consider stepping up as maintainer *now*.
Otherwise, last-rites and removal from tree will happen soon.

[1] https://bugs.gentoo.org/708162
[2] https://bugs.gentoo.org/706462
[3] https://github.com/Nicotine-Plus/nicotine-plus/pull/106
[4] https://github.com/Nicotine-Plus/nicotine-plus/issues/99

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Last rites: sys-cluster/polysh

2020-06-07 Thread Aaron Bauman
# Aaron Bauman  (2020-06-07)
# py2 only. dead upstream. m-n. rdep.
# Masked for removal in 15 days
sys-cluster/polysh

-- 
Cheers,
Aaron


signature.asc
Description: PGP signature


[gentoo-dev] Last rites: net-misc/charm

2020-06-07 Thread Aaron Bauman
# Aaron Bauman  (2020-06-07)
# py2 only. dead upstream. m-n. rdep.
# Masked for removal in 15 days
net-misc/charm

-- 
Cheers,
Aaron


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?

2020-06-07 Thread Andreas K . Hüttel
> Project Graphics was now deleted 

Inofficially a graphics@ maintainership of a package meant "fix the bugs 
yourself" for quite some time already. So I doubt the current state got worse 
via the removal of the project. 

That said, this is actually for a subset of the packages one of the cases 
where a project would really make sense. We have a lot of central libraries 
here that are used by many other software. libpng, jpeg, tiff, ... These are 
definitely worth a team of maintainers.

-- 
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] [RFC] Concept of Projects - How to proceed?

2020-06-07 Thread Andreas K . Hüttel
> Now for the future, I wouldn't mind having a "last rite: XYV Project" or
> similar e-mail sent to gentoo-dev{-announce} before action to ebuilds is
> taken, so the project members/lead has one final chance to stop it.

Good plan.

-- 
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.


[gentoo-dev] Looking for a co-maintainer: games-fps/gzdoom

2020-06-07 Thread William Breathitt Gray
I am looking for a co-maintainer for the games-fps/gzdoom package.
GZDoom version 4.4.0 was just released and GZDoom has been refactored to
move its audio code to a new external library called ZMusic:
https://bugs.gentoo.org/727448

A games-fps/gzdoom-4.4.0 version bump will require the introduction of a
new zmusic ebuild. Since GZDoom is one of the larger DOOM source ports,
I figure it'll be good to have more than one person looking after these
packages.

If anyone is interested in helping out, please let me know.

Thanks,

William Breathitt Gray


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?

2020-06-07 Thread Joonas Niilola

On 6/7/20 9:14 PM, Jonas Stein wrote:
>
> Glad to read your offer. Yes, please do so.
>
> I think it would hurt the Gentoo project if single developers delete
> projects
>
> - without without informing the project members
> - without prior discussion (on gentoo-dev for example),
> - without vote/consent
> - without an organized shutdown (reassign bugs, archive things...).
>
> However we should continue to find a general solution for the problems
> discussed in this thread and find a general consent.
>
> Thank you.
>
The "voting" and "discussion" happened in #gentoo-dev IRC channel. Every
participant was unhappy with the state of graphics project, and even
after pinging the project, no members responded. This "discussion" has
been ongoing for a while now. While I agree the outcome wasn't clean, in
my eyes attempts to contact project has been made.

Now for the future, I wouldn't mind having a "last rite: XYV Project" or
similar e-mail sent to gentoo-dev{-announce} before action to ebuilds is
taken, so the project members/lead has one final chance to stop it.
Maybe this even encourages us to go through some of the more inactive
projects currently?

-- juippis




signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Thank you & Vote for the next Bugday (2020-07-04)

2020-06-07 Thread Jonas Stein
Hi,

the Bugday had a nice revival on 2020-06-06.
Over the time there were several people, who worked on the fine Bug
selection. And we had good discussions about package testing and the
bugs. Support was provided by experienced Gentoo users and developers.

A big "thank you" to everyone who joined. We had a great time and I
learned a lot too.

You (literally everybody) can vote for the topics of the next Bugday.
https://dudle.inf.tu-dresden.de/Bugday_2020-07-04/

Stay informed on: https://wiki.gentoo.org/wiki/Bugday

-- 
Best,
Jonas



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?

2020-06-07 Thread Rich Freeman
On Sun, Jun 7, 2020 at 2:14 PM Jonas Stein  wrote:
>
> On 07/06/2020 03.43, Aaron Bauman wrote:
> > On Sun, Jun 07, 2020 at 01:49:28AM +0200, Jonas Stein wrote:
>
> > I will happily revert my change on the graphics project Wiki [..]
>
> Glad to read your offer. Yes, please do so.
>
> I think it would hurt the Gentoo project if single developers delete
> projects
>
> - without without informing the project members
> - without prior discussion (on gentoo-dev for example),
> - without vote/consent
> - without an organized shutdown (reassign bugs, archive things...).
>
> However we should continue to find a general solution for the problems
> discussed in this thread and find a general consent.

While I get what you're saying, I think it would also be helpful if we
just let people who feel they are actually impacted by changes like
this speak up for themselves, instead of assuming that they must exist
and that it is our duty to speak up for them.

Are you, directly, impacted in any negative way by this change?  If so
it would probably be helpful if you just explained the issue.

This really seems like a fairly uneventful change.  I do think it is
better to pre-announce changes.  However, I suspect that most of the
fuss is because a lot of people assume that a change like this must
have some kind of big impact, and for whatever reason all the people
who are being harmed by it are just afraid to speak up so we must do
so on their behalf.

I say this as somebody who used to raise a lot more hypothetical
objections to changes in the past.  I've since learned that it is easy
to over-react, and that when others are actually impacted by a change
they will tend to speak up.

I'm pretty sure in this case there was an organized shutdown - I doubt
they just removed the project without reassigning packages or bugs.
They were effectively already assigned to nobody as it was, since the
project was inactive.

I guess my point is that while this probably could be done in a better
way, I think it is likely to end up happening either way, so all
undoing it is going to do is send a lot of people two more rounds of
bugspam at best.  Or, it will result in one more round of bugspam and
then these packages continue to be unmaintained because nobody is
going to bother doing all the steps you're suggesting to get rid of it
in the future.  Easier to just leave the dead project around and let
users wonder why nobody pays attention to the bugs they open.

-- 
Rich



Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?

2020-06-07 Thread Jonas Stein
On 07/06/2020 03.43, Aaron Bauman wrote:
> On Sun, Jun 07, 2020 at 01:49:28AM +0200, Jonas Stein wrote:

> I will happily revert my change on the graphics project Wiki [..]

Glad to read your offer. Yes, please do so.

I think it would hurt the Gentoo project if single developers delete
projects

- without without informing the project members
- without prior discussion (on gentoo-dev for example),
- without vote/consent
- without an organized shutdown (reassign bugs, archive things...).

However we should continue to find a general solution for the problems
discussed in this thread and find a general consent.

Thank you.

-- 
Best,
Jonas



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

2020-06-07 Thread Aisha Tammy
On 6/7/20 2:28 AM, Joonas Niilola wrote:
> 
> 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
> 
Indeed, thanks a lot.
I should have anticipated that there would be further discussion on this, before
prematurely asking simple question >.<
Nonetheless, an interesting situation. I never knew too much about projects.

Aisha

> -- juippis
> 
> 




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?

2020-06-07 Thread Kent Fredric
On Sun, 7 Jun 2020 06:43:19 -0400
Rich Freeman  wrote:

> Historically a lot of projects worked more like "tags" as an
> alternative way of grouping packages other than categories.  While
> tags are a great idea projects are a terrible way to implement them.

I was thinking perhaps instead of "group membership" oriented things,
we could instead have a "developer proficiency" oriented system.

Developers could choose skills from a defined list (like projects, but
finely grained)

Maybe with some WOT based proficiency rating thing.

Then maybe the project system becomes used mostly for "primary
ownership" of well maintained sets of things with great team structure,
and the proficiency system becomes a defacto fallback for everything
else.

Packages are tagged with the sort of skills required to maintain them
effectively, and people who have registered with said proficiencies get
CC'd into the bug (somehow) and similar things.

Like, for instance, when a package uses perl stuff, but isn't
inherently owned by perl@, I still care, but registering that I care is
tricky.

And then potentially packages with above "good maintainer-ship" could
indicate some sort of maintainer-ship grant to 
"people with proficiency > X in Y".

Yes, I'm likely over-thinking everything here too much, but I suspect
somebody could get some inspiration from something here :)


pgpGDBplJU7XL.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] Concept of Projects - How to proceed?

2020-06-07 Thread Rich Freeman
On Sat, Jun 6, 2020 at 7:49 PM Jonas Stein  wrote:
>
> our concept of "Projects" (Herds in the past) maintaining packages has
> several problems.

You might want to search the list archives as many of the issues
you've raised have been discussed extensively.  There was never a
complete push to fix things, but most project removals/etc have been
along the lines of what has been discussed.

While tangential, I'll point out that there have been similar
discussions around appropriate uses of eclasses and there are some
loose parallels for when eclasses make sense.

> * 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...

...graphics...

This is the gist of the outcome of previous discussions.  Projects
make sense when developers actually work TOGETHER to maintain things.
Nobody who works on qt is going to just upgrade one component of qt
without talking to the other maintainers.  It makes sense for those
packages to be managed by a project.

Historically a lot of projects worked more like "tags" as an
alternative way of grouping packages other than categories.  While
tags are a great idea projects are a terrible way to implement them.

> I think we should first find a consent about the following questions
> before someone deletes projects.

In general I'm a fan of announcing things like this BEFORE doing them.
However, I don't think they need pre-approval when they make sense.
If anything we haven't been doing it often enough.

I don't see any point in bringing back graphics though - if somebody
who actually intends to lead such a project wants to speak up on that
they should certainly do so, but it sounds like it is just a vestige
of an old herd that probably never worked as an actual team.

People reading the thread shouldn't think that this has anything to do
with the importance of the individual packages.  This is purely about
how devs are organized around them.

Some of what you wrote was more about our larger meta-structure and
how devs maintain packages in general.  That has also been discussed
quite a bit, like having a core group of devs who don't maintain any
individual packages and all they do is QA pull requests from a much
larger pool of individuals who do care about packages.  There are a
lot of pros and cons to that and I won't rehash the previous
discussions here.  That isn't to discourage anybody from doing so - I
mainly just want to point out that this stuff is in the archives.

-- 
Rich



Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

2020-06-07 Thread Alexey Sokolov
вс, 7 июн. 2020 г. в 09:10, Pacho Ramos :
>
>
> I think this is the list of completely unmaintained packages now (indeed most 
> of
> them, around 100) :)
>
> x11-misc/shutter

I'm updating this one right now



Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

2020-06-07 Thread Pacho Ramos
El sáb, 06-06-2020 a las 15:09 -0400, Aaron Bauman escribió:
> 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.
> 

I think this is the list of completely unmaintained packages now (indeed most of
them, around 100) :)

dev-cpp/pngpp
media-gfx/apng2gif
media-gfx/apngasm
media-gfx/apngdis
media-gfx/apngopt
media-gfx/autopano-sift-C
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/fim
media-gfx/fr0st
media-gfx/gif2apng
media-gfx/gif2png
media-gfx/gifsicle
media-gfx/gimageview
media-gfx/gmic
media-gfx/gnofract4d
media-gfx/graphicsmagick
media-gfx/grub-splashes
media-gfx/gtkimageview
media-gfx/hugin
media-gfx/icon-slicer
media-gfx/igal
media-gfx/imagemagick
media-gfx/jhead
media-gfx/jigl
media-gfx/jpeginfo
media-gfx/jpegoptim
media-gfx/jpegpixi
media-gfx/libimagequant
media-gfx/luminance-hdr
media-gfx/mandelbulber
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/povtree
media-gfx/pqiv
media-gfx/pqstego
media-gfx/qiv
media-gfx/qvv
media-gfx/raw-thumbnailer
media-gfx/rotoscope
media-gfx/scantailor-advanced
media-gfx/scour
media-gfx/sfftobmp
media-gfx/sxiv
media-gfx/tintii
media-gfx/tuxpaint-stamps
media-gfx/tuxpaint
media-gfx/ufraw
media-gfx/uniconvertor
media-gfx/wkhtmltopdf
media-gfx/xli
media-gfx/xloadimage
media-gfx/xzgv
media-libs/cimg
media-libs/esdl
media-libs/flickcurl
media-libs/gd
media-libs/giblib
media-libs/giflib
media-libs/imlib
media-libs/jbigkit
media-libs/jpeg
media-libs/lensfun
media-libs/libexif-gtk
media-libs/libexif
media-libs/libfpx
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/netpbm
media-libs/opencolorio
media-libs/openimageio
media-libs/openjpeg
media-libs/pnglite
media-libs/stimg
media-libs/tiff
media-libs/urt
virtual/imagemagick-tools
virtual/jpeg-compat
virtual/jpeg
x11-misc/gromit
x11-misc/shutter


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

2020-06-07 Thread Joonas Niilola

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