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

2020-09-19 Thread Michał Górny
# Michał Górny  (2020-09-20)
# Abandoned upstream, homepage gone.  Last release in 2009.  Uses
# deprecated gnome-base/libgnomeui.  Arch apparently has patches to keep
# it alive, if anyone wants to.
# Removal in 30 days.  Bug #726796.
net-misc/gwget

-- 
Best regards,
Michał Górny



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


[gentoo-dev] Last rites: sys-block/rts5229

2020-09-19 Thread David Seifert
# David Seifert  (2020-09-20)
# EAPI 4, last release in 2012, sandbox violations and
# full of bugs. Mainlined since 3.14, Removal in 30 days.
# Bug #679502, #701406, #701408, #742116.
sys-block/rts5229


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


Re: [gentoo-dev] How to stabilize packages with frequent release cycles?

2020-09-19 Thread Rich Freeman
On Wed, Sep 16, 2020 at 4:08 PM Jonas Stein  wrote:
>
> Hi,
>
> > When the latest release remains 'latest ~arch' for less than 3 days,
> > stabilizing it after 30 days makes little sense.  After all, people with
> > frequent upgrade cycle will test it for no more than that, and people
> > with infrequent upgrade cycle may miss the version entirely.
>
> > Do you have any suggestions how we could improve this?
>
> At first we need a strict definition of "stable" and "testing", then we
> can discuss how to stabilize.
>

Not sure it is a definition issue so much that the concept doesn't fit
with these sorts of packages.  Normally the idea of stable is that
you're willing to trade speed for quality.

The problem is that in these sorts of packages you're often getting
neither.  For example, you're not going to have a more-bug-free
experience with youtube-dl if you run a two month old version, because
the APIs are all changing and you're just losing the cat and mouse
game.

IMO these sorts of packages probably shouldn't have stable versions at
all.  Then users will accept ~arch, and both know what they're getting
into, and also not get stuck with old versions that give them
suboptimal results.

Now, if somebody can come up with a better interface for that which is
cleaner than having to stick foo/bar in accept_keywords that would be
nice.  But that almost suggests another class of keyword entirely.
These packages aren't really "stable" - so much as stable not being an
option.

-- 
Rich



[gentoo-dev] Last rites: sci-mathematics/axiom

2020-09-19 Thread David Seifert
# David Seifert  (2020-09-19)
# EAPI 4, last release in 2008, upstream pretty much dead,
# tons of bugs, broken since at least 2016, lots of weird
# dead/alive/redead forks all over the internet. Use
# sci-mathematics/fricas as spiritual successor fork.
# Removal in 30 days.  Bug #326575, #514762, #532498,
# #574956, #581250, #586402, #587878, #740966.
sci-mathematics/axiom


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


Re: [gentoo-dev] Last rites: next batch of py2 packages

2020-09-19 Thread Martin Dummer

On 2020-09-19 16:36, Azamat Hackimov wrote:
> Hello.
>
> сб, 19 сент. 2020 г. в 15:51, Michał Górny :
>> sys-firmware/nvidia-firmware
>>
> Created PR https://github.com/gentoo/gentoo/pull/17600
>

Excellent! Thats an important firmware package, I would have started a
PR also in a few minutes!



0xCE5F3E9B6DE05D12.asc
Description: application/pgp-keys


Re: [gentoo-dev] Last rites: next batch of py2 packages

2020-09-19 Thread Azamat Hackimov
Hello.

сб, 19 сент. 2020 г. в 15:51, Michał Górny :
> sys-firmware/nvidia-firmware
>
Created PR https://github.com/gentoo/gentoo/pull/17600

-- 
>From Siberia with Love!



[gentoo-dev] Last rites: next batch of py2 packages

2020-09-19 Thread Michał Górny
# Michał Górny  (2020-09-19)
# These packages (or package versions) still require Python 2.7.
# They are either dead upstream, their Python 3 porting efforts are
# not progressing or their maintainers are simply unresponsive.
# Please do not remove any packages from this list unless you actually
# port them to Python 3.
# Removal in 30 days.  Please find relevant bugs on tracker bug #694800.
app-admin/github-backup-utils
app-backup/genbackupdata
app-i18n/pology
app-pda/gtkpod
app-text/pdf2djvu
app-text/sgmltools-lite
dev-util/anjuta
dev-util/gyp
app-i18n/mozc
sci-libs/magma
sys-firmware/nvidia-firmware

-- 
Best regards,
Michał Górny



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


Re: [gentoo-dev] Last rites: dev-java/oracle-{jdk,jre}-bin and revdeps

2020-09-19 Thread Georgy Yakovlev
took a while, removed.

I was able to save jabref-bin, works fine with openjdk:8
geogebra now availabie as geogebra-bin and works with openjdk8 and 11.
sleuthkit was spared.

rest is gone, but if someone wants to restore - patches welcome.


On 4/18/20 9:10 PM, Georgy Yakovlev wrote:
> # Georgy Yakovlev  (2020-04-18)
> # Unmaintained, vulnerable oracle java ebuilds, even fetching distfiles
> # requires agreement to restrictive license
> # Revdeps that still depend on oracle variants require javafx
> # Please use icedtea or openjdk instead.
> # Removal in 30 days.
> # https://bugs.gentoo.org/681828
> dev-java/oracle-jdk-bin
> dev-java/oracle-jre-bin
> app-forensics/sleuthkit
> app-text/jabref-bin
> dev-java/netbeans-platform
> dev-java/netbeans-harness
> games-util/pogo-manager-bin
> net-p2p/bisq
> sci-mathematics/geogebra
> 
> 
> 
> Oracle java has been maintainer-needed since august 2019,
> no one stepped up.
> Removal in 30 days.
> 
> If someone wants to save the javafx revdeps, best way will be
> packaging zulufx community [1], I can provide some guidance
> on packaging it, should not be too hard.
>