Hey,
On 12/9/19 10:17 AM, Michał Górny wrote:
> Hello,
>
> I think the policies proposed in GLEP 81 [1] were overenthusiastic
> and they don't stand collision with sad Gentoo developer reality.
> Instead of improving the quality of resulting packages, they rather
> hamper their adoption and
On Mon, 2019-12-09 at 13:48 -0800, Alec Warner wrote:
> On Mon, Dec 9, 2019 at 12:17 AM Michał Górny wrote:
>
> > Hello,
> >
> > I think the policies proposed in GLEP 81 [1] were overenthusiastic
> > and they don't stand collision with sad Gentoo developer reality.
> > Instead of improving the
# Aaron Bauman (2019-12-10)
# EAPI=4, dead upstream, can't locate new home
# Removal in 30 days
dev-util/kelbt
--
Cheers,
Aaron
signature.asc
Description: PGP signature
On Mon, Dec 09, 2019 at 07:43:23PM -0500, Aaron Bauman wrote:
> # Aaron Bauman (2019-12-09)
>
> # EAPI=4, unmaintained upstream and Gentoo is versions behind
>
> # Removal in 30 days
# Aaron Bauman (2019-12-10)
# EAPI=4, fails to build
# Removal in 30 days
dev-util/idutils
--
Cheers,
Aaron
signature.asc
Description: PGP signature
# @DEAD
# All consumers are gone. Removal in 14 days
# @DEAD
# All consumers are gone.
# Bug #156882, #574642, #637740. Removal in 14 days.
# David Seifert (2019-12-10)
# Abandoned upstream, broken ncurses linking, last release 8 years ago.
# Bug #677742, #696228. Removal in 30 days.
media-sound/vitunes
# David Seifert (2019-12-10)
# Build broken for over 3 years, GTK 2, quasi-abandoned upstream.
# Bug #490574, #699914. Removal in 30 days.
media-sound/mhwaveedit
# David Seifert (2019-12-10)
# Never keyworded, only worked with specific versions of boost that are
# gone, integrated into boost as dev-libs/boost[python,numpy] nowadays.
# Removal in 7 days.
dev-libs/boost-numpy
# Aaron Bauman (2019-12-09)
# EAPI=4, unmaintained upstream and Gentoo is versions behind
# Removal in 30 days
dev-tex/dvi2tty
--
Cheers,
Aaron
signature.asc
Description: PGP
# Aaron Bauman (2019-12-09)
# EAPI=4, unmaintained upstream, rdep as well
# Removal in 30 days. Open bugs #552934
dev-libs/cityhash
On Mon, Dec 9, 2019 at 12:17 AM Michał Górny wrote:
> Hello,
>
> I think the policies proposed in GLEP 81 [1] were overenthusiastic
> and they don't stand collision with sad Gentoo developer reality.
> Instead of improving the quality of resulting packages, they rather
> hamper their adoption
> On Tue, 03 Dec 2019, Ulrich Mueller wrote:
> There are some DTDs in data/dtd.git which were needed for the old XML
> pages. Apparently the following are no longer used:
>gleps.dtd
>metadoc.dtd
>project.dtd (not to be confused with projects.dtd which is in use)
>userinfo.dtd
On 2019-12-09 19:48, Ulrich Mueller wrote:
>> On Mon, 09 Dec 2019, Thomas Deutschmann wrote:
>
>> Like said, if an ID is already taken for any reason on user's system,
>> that's not a problem. acct-* can handle that... there's nothing like a
>> collision.
>
> You can call it "collision" or
On Montag, 9. Dezember 2019 13:03:02 CET Hanno Böck wrote:
> It's an archive unpacker written in objective C, which makes it
> dependency-heavy (particularly requires gcc compiled with objc).
> I originally got interested because it was the only free unpacker
> capable of handling modern rar
> On Mon, 09 Dec 2019, Thomas Deutschmann wrote:
> Like said, if an ID is already taken for any reason on user's system,
> that's not a problem. acct-* can handle that... there's nothing like a
> collision.
You can call it "collision" or something else, the fact is that in this
scenario, the
On 2019-12-09 18:47, Ulrich Mueller wrote:
> One problem with that is that at some time user.eclass dynamically
> allocated IDs starting at 101 upwards, and later this was changed to 999
> downwards (at different times for UIDs and GIDs). So for existing
> systems you can expect some range above
> On Mon, 09 Dec 2019, Thomas Deutschmann wrote:
> Make complete SYS_UID_MIN - SYS_UID_MAX range available for GLEP 81.
> The only argument/reason I am aware of, "but 501-999 could be used by
> system" (Dynamic allocation by user.eclass), isn't strong enough from my
> POV because system
Hi,
I fully agree with #3. But I would go one step further:
Make complete SYS_UID_MIN - SYS_UID_MAX range available for GLEP 81.
The only argument/reason I am aware of, "but 501-999 could be used by
system" (Dynamic allocation by user.eclass), isn't strong enough from my
POV because system
Hi,
>> What about just checking "${EROOT}/boot" instead?
> For what, existence? There may well be a "boot" directory present under
> EROOT. (And we could check ${EROOT}/etc/fstab, but I don't think we
> should open that can of worms. There's no reliable way to guess the
> user's exact
Hi,
I'm no longer interested in maintaining app-arch/unar.
It's an archive unpacker written in objective C, which makes it
dependency-heavy (particularly requires gcc compiled with objc).
I originally got interested because it was the only free unpacker
capable of handling modern rar archives.
> On Mon, 09 Dec 2019, Jaco Kroon wrote:
> Acked-by: Jaco Kroon
OK, I can add this.
>> + if [[ ${EROOT:-/} != / ]] ; then
>> return 0
>> fi
> I don't use spaces in path names ... but what happens here if ROOT or
> EPREFIX (and by implication EROOT) contains a space?
No
Hi Ulrich,
I'm happy with this "as is", but there may be a few improvements still.
By the way: This improves the situation for mounted ro /boot by moving
the check from preinst to pretend.
For noauto /boot (I believe the default and recommended) this fixes things.
This is the reason I decided
> On Mon, 09 Dec 2019, Ulrich Mueller wrote:
>> a. split the UID/GID range into 'high' (app) and 'low' (system)
>> assignments, 'high' being >=100 and 'low' <100 (matching Apache suEXEC
>> defaults),
> Good, but can we make these ranges more explicit please, like 100..499
> for "high" and
> On Mon, 09 Dec 2019, Michał Górny wrote:
> My proposal would be to:
> a. split the UID/GID range into 'high' (app) and 'low' (system)
> assignments, 'high' being >=100 and 'low' <100 (matching Apache suEXEC
> defaults),
Good, but can we make these ranges more explicit please, like
Hello,
I think the policies proposed in GLEP 81 [1] were overenthusiastic
and they don't stand collision with sad Gentoo developer reality.
Instead of improving the quality of resulting packages, they rather
hamper their adoption and cause growing frustration.
The problems I see today are:
1.
27 matches
Mail list logo
