[gentoo-dev] Idea for a new project: gentoo-libs

[gentoo-dev] Idea for a new project: gentoo-libs

[Marty E. Plummer]

So, as you may be aware I've been doing some work on moving bzip2 to an
autotools based build. Recently I've ran into app-crypt/mhash, which is
in a semi-abandoned state (talking with the maintainer on twitter atm),
and I was thinking it may be a good idea to set up a project for keeping
these semi-abandoned and really-abandoned libraries and projects up to
date and such.

Basically, an upstream for packages who's upstream is either
uncontactable or is otherwise not accepting bug fixes and patches. So
far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
there are others in this state.

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Marty E. Plummer]

On Fri, Jun 22, 2018 at 09:50:50PM -0500, Marty E. Plummer wrote:
> So, as you may be aware I've been doing some work on moving bzip2 to an
> autotools based build. Recently I've ran into app-crypt/mhash, which is
> in a semi-abandoned state (talking with the maintainer on twitter atm),
> and I was thinking it may be a good idea to set up a project for keeping
> these semi-abandoned and really-abandoned libraries and projects up to
> date and such.
> 
> Basically, an upstream for packages who's upstream is either
> uncontactable or is otherwise not accepting bug fixes and patches. So
> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> there are others in this state.
> 
Or... call it proxy-upstream, to be in line with the current proxy-maint
setup?

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]

W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
Plummer napisał:
> So, as you may be aware I've been doing some work on moving bzip2 to an
> autotools based build. Recently I've ran into app-crypt/mhash, which is
> in a semi-abandoned state (talking with the maintainer on twitter atm),
> and I was thinking it may be a good idea to set up a project for keeping
> these semi-abandoned and really-abandoned libraries and projects up to
> date and such.
> 
> Basically, an upstream for packages who's upstream is either
> uncontactable or is otherwise not accepting bug fixes and patches. So
> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> there are others in this state.
> 

So in order to fix problem of semi-abandoned packages, you're creating
an indirect herd-like entity that will soon be semi-abandoned itself
because people will be dumping random packages into it and afterwards
nobody will claim responsibility for them.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Marty E. Plummer]

On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote:
> W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
> Plummer napisał:
> > So, as you may be aware I've been doing some work on moving bzip2 to an
> > autotools based build. Recently I've ran into app-crypt/mhash, which is
> > in a semi-abandoned state (talking with the maintainer on twitter atm),
> > and I was thinking it may be a good idea to set up a project for keeping
> > these semi-abandoned and really-abandoned libraries and projects up to
> > date and such.
> > 
> > Basically, an upstream for packages who's upstream is either
> > uncontactable or is otherwise not accepting bug fixes and patches. So
> > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> > there are others in this state.
> > 
> 
> So in order to fix problem of semi-abandoned packages, you're creating
> an indirect herd-like entity that will soon be semi-abandoned itself
> because people will be dumping random packages into it and afterwards
> nobody will claim responsibility for them.
> 
> -- 
> Best regards,
> Michał Górny

No, I mean for packages which are important enough in gentoo to warrant
such treatment. For instance, every email I've tried for bzip2's
upstream bounced or recieved no reply. That, I assume, is important
enough to actually maintain and improve. Any other library which may be
as important which are as inactive would be added.

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

W dniu sob, 23.06.2018 o godzinie 02∶30 -0500, użytkownik Marty E.
Plummer napisał:
> On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote:
> > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
> > Plummer napisał:
> > > So, as you may be aware I've been doing some work on moving bzip2 to an
> > > autotools based build. Recently I've ran into app-crypt/mhash, which is
> > > in a semi-abandoned state (talking with the maintainer on twitter atm),
> > > and I was thinking it may be a good idea to set up a project for keeping
> > > these semi-abandoned and really-abandoned libraries and projects up to
> > > date and such.
> > > 
> > > Basically, an upstream for packages who's upstream is either
> > > uncontactable or is otherwise not accepting bug fixes and patches. So
> > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> > > there are others in this state.
> > > 
> > 
> > So in order to fix problem of semi-abandoned packages, you're creating
> > an indirect herd-like entity that will soon be semi-abandoned itself
> > because people will be dumping random packages into it and afterwards
> > nobody will claim responsibility for them.
> > 
> > -- 
> > Best regards,
> > Michał Górny
> 
> No, I mean for packages which are important enough in gentoo to warrant
> such treatment. For instance, every email I've tried for bzip2's
> upstream bounced or recieved no reply. That, I assume, is important
> enough to actually maintain and improve. Any other library which may be
> as important which are as inactive would be added.

Sounds like you're going to take over half of base-system ;-).

I really prefer having single dedicated individuals for that kind of
stuff.  Projects just blur the responsibility.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Mikle Kolyada]

[-- Attachment #1.1: Type: text/plain, Size: 941 bytes --]



On 23.06.2018 05:50, Marty E. Plummer wrote:
> So, as you may be aware I've been doing some work on moving bzip2 to an
> autotools based build. Recently I've ran into app-crypt/mhash, which is
> in a semi-abandoned state (talking with the maintainer on twitter atm),
> and I was thinking it may be a good idea to set up a project for keeping
> these semi-abandoned and really-abandoned libraries and projects up to
> date and such.

But how would it serve gentoo itself? Lots of packages in the distro
have dead upstream but still work.
Why would you want to make gentoo an upstream area rather than moving a
dead project itself, say,
to github and do the job there?
>
> Basically, an upstream for packages who's upstream is either
> uncontactable or is otherwise not accepting bug fixes and patches. So
> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> there are others in this state.
>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 313 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Paweł Hajdan, Jr.]

[-- Attachment #1.1: Type: text/plain, Size: 767 bytes --]

On 23/06/2018 09:43, Mikle Kolyada wrote:
> But how would it serve gentoo itself? Lots of packages in the distro
> have dead upstream but still work.
> Why would you want to make gentoo an upstream area rather than moving a
> dead project itself, say,
> to github and do the job there?

+1

I like the idea of taking responsibility for the abandoned packages that
are still useful.

It's probably not Gentoo-specific, so a distro-neutral way of handling
that seems most appropriate.

It may even be worth it to coordinate with other distros (and maybe
downstreams) so that the new version becomes a standard.

Finally, having more than one person on this (to help continuity), and a
common platform like GitHub also seem very helpful.

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Marty E. Plummer]

On Sat, Jun 23, 2018 at 10:15:06AM +0200, Paweł Hajdan, Jr. wrote:
> On 23/06/2018 09:43, Mikle Kolyada wrote:
> > But how would it serve gentoo itself? Lots of packages in the distro
> > have dead upstream but still work.
> > Why would you want to make gentoo an upstream area rather than moving a
> > dead project itself, say,
> > to github and do the job there?
> 
> +1
> 
> I like the idea of taking responsibility for the abandoned packages that
> are still useful.
> 
> It's probably not Gentoo-specific, so a distro-neutral way of handling
> that seems most appropriate.
> 
> It may even be worth it to coordinate with other distros (and maybe
> downstreams) so that the new version becomes a standard.
> 
> Finally, having more than one person on this (to help continuity), and a
> common platform like GitHub also seem very helpful.
> 
> Paweł
> 
Agreed in general; the problem is getting it started at all; difficult
to get other distros to join if there is nothing to join.

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer <hanetzer@startmail.com>
wrote:

> On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote:
> > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
> > Plummer napisał:
> > > So, as you may be aware I've been doing some work on moving bzip2 to an
> > > autotools based build. Recently I've ran into app-crypt/mhash, which is
> > > in a semi-abandoned state (talking with the maintainer on twitter atm),
> > > and I was thinking it may be a good idea to set up a project for
> keeping
> > > these semi-abandoned and really-abandoned libraries and projects up to
> > > date and such.
> > >
> > > Basically, an upstream for packages who's upstream is either
> > > uncontactable or is otherwise not accepting bug fixes and patches. So
> > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> > > there are others in this state.
> > >
> >
> > So in order to fix problem of semi-abandoned packages, you're creating
> > an indirect herd-like entity that will soon be semi-abandoned itself
> > because people will be dumping random packages into it and afterwards
> > nobody will claim responsibility for them.
> >
> > --
> > Best regards,
> > Michał Górny
>
> No, I mean for packages which are important enough in gentoo to warrant
> such treatment. For instance, every email I've tried for bzip2's
> upstream bounced or recieved no reply. That, I assume, is important
> enough to actually maintain and improve. Any other library which may be
> as important which are as inactive would be added.
>
>
I suspect this might be better done in the Linux foundation itself as they
have staffing for core components that everyone is using.

-A

[-- Attachment #2: Type: text/html, Size: 2513 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Roy Bamford]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

On 2018.06.23 09:55, Marty E. Plummer wrote:
> On Sat, Jun 23, 2018 at 10:15:06AM +0200, Paweł Hajdan, Jr. wrote:
> > On 23/06/2018 09:43, Mikle Kolyada wrote:
> > > But how would it serve gentoo itself? Lots of packages in the
> distro
> > > have dead upstream but still work.
> > > Why would you want to make gentoo an upstream area rather than
> moving a
> > > dead project itself, say,
> > > to github and do the job there?
> > 
> > +1
> > 
> > I like the idea of taking responsibility for the abandoned packages
> that
> > are still useful.
> > 
> > It's probably not Gentoo-specific, so a distro-neutral way of
> handling
> > that seems most appropriate.
> > 
> > It may even be worth it to coordinate with other distros (and maybe
> > downstreams) so that the new version becomes a standard.
> > 
> > Finally, having more than one person on this (to help continuity),
> and a
> > common platform like GitHub also seem very helpful.
> > 
> > Paweł
> > 
> Agreed in general; the problem is getting it started at all; difficult
> to get other distros to join if there is nothing to join.
> 
> 
> 

A couple of generalisations.

The first solution to unmaintained packages should be to move to an 
alternative, if that's possible. Gentoo does not have the resource
to be upstream for very much for the entire Linux community, a point
already made by others.

In volunteer groups things get done by those who want to do them.
Others join later. I think the quote I'm looking for is "Build it and they 
will come".

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Jonas Stein]

[-- Attachment #1.1: Type: text/plain, Size: 2020 bytes --]

On 2018-06-23 04:57, Marty E. Plummer wrote:
> On Fri, Jun 22, 2018 at 09:50:50PM -0500, Marty E. Plummer wrote:
>> So, as you may be aware I've been doing some work on moving bzip2 to an
>> autotools based build. Recently I've ran into app-crypt/mhash, which is
>> in a semi-abandoned state (talking with the maintainer on twitter atm),
>> and I was thinking it may be a good idea to set up a project for keeping
>> these semi-abandoned and really-abandoned libraries and projects up to
>> date and such.
>>
>> Basically, an upstream for packages who's upstream is either
>> uncontactable or is otherwise not accepting bug fixes and patches. So
>> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
>> there are others in this state.
>>
> Or... call it proxy-upstream, to be in line with the current proxy-maint
> setup?

Please do not call it proxy-*.
The invented word proxymaintainer and proxiedmaintainer are not usefull.
They get always mixed, and are not understood outside of Gentoo.
assistant developer or trainee developer would have been much more useful.

Beside the naming I like the idea, that you want to take care for all
abandoned libs.

Please note, that you can not generate more manpower by creating a
project. In 2015 I calculated

=====================================================

 (Number of developers) / (Number of Projects) < 1.4

=====================================================

Which explains, why most projects today are run by mostly one active person.

If you find an important library, where upstream is dead, fork it and
take responsibility for it.

It makes no sense to make a pool of dead and important software and
delegate the responsibility to a team where nobody really knows the
software.

Better pick a library, communicate with maintainers of the other
distributions and fork it. Keep the library alive in the fork.

It is important for the security to let dead projects die.

-- 
Best,
Jonas


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

On Fri, 22 Jun 2018 21:50:50 -0500
"Marty E. Plummer" <hanetzer@startmail.com> wrote:

> So, as you may be aware I've been doing some work on moving bzip2 to an
> autotools based build. Recently I've ran into app-crypt/mhash, which is
> in a semi-abandoned state (talking with the maintainer on twitter atm),
> and I was thinking it may be a good idea to set up a project for keeping
> these semi-abandoned and really-abandoned libraries and projects up to
> date and such.
> 
> Basically, an upstream for packages who's upstream is either
> uncontactable or is otherwise not accepting bug fixes and patches. So
> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
> there are others in this state.

It may be worth mentioning that myself and a handful of others are
kicking around the idea of creating a "vendorised upstream", which
essentially treats all upstreams as unmaintained, and acts as a middle
ground between upstream and linux distributions/end users, by
re-shipping upstreams code with fixes, in a format similar to
upstreams, but with the mentality of a Linux Vendor.

Changes to this project would of course be made under the assumption
that upstream would one day wake up, and may be interested in adopting
some or all of our fixes ( and for upstreams that are currently not
actually dead, this may happen sooner than later )

Presently, this is limited in scope to vendorizing CPAN, but it may
grow.

In concept, this is of course much more work than your idea, but it has
a few advantages, particularly with regards to integrating various
vendors patches in a single place.

But obviously, such a project is somewhat gargantuan, and getting the
working concept off the ground is going to take a while :)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Hanno Böck]

On Fri, 22 Jun 2018 21:50:50 -0500
"Marty E. Plummer" <hanetzer@startmail.com> wrote:

> So, as you may be aware I've been doing some work on moving bzip2 to
> an autotools based build. Recently I've ran into app-crypt/mhash,
> which is in a semi-abandoned state (talking with the maintainer on
> twitter atm), and I was thinking it may be a good idea to set up a
> project for keeping these semi-abandoned and really-abandoned
> libraries and projects up to date and such.

This is a common problem, however if you want to make this reasonable
you wouldn't make it a gentoo thing, but a cross-distro effort. The
idea has been tossed around a lot, but noone yet started implementing
it.

However keeping things alive may not always be the right option.
There's a reason mcrypt is abandoned. It's an ancient crypto library,
crypto is moving forward, there are better options. THe main user of
mcrypt was PHP, and PHP is abandoning it with 7.2. (There are 2 other
users in the gentoo tree of libmcrypt, which are both rather obscure
packages - nsca and elettra.)

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Marty E. Plummer]

On Mon, Jun 25, 2018 at 07:59:47AM +0200, Hanno Böck wrote:
> On Fri, 22 Jun 2018 21:50:50 -0500
> "Marty E. Plummer" <hanetzer@startmail.com> wrote:
> 
> > So, as you may be aware I've been doing some work on moving bzip2 to
> > an autotools based build. Recently I've ran into app-crypt/mhash,
> > which is in a semi-abandoned state (talking with the maintainer on
> > twitter atm), and I was thinking it may be a good idea to set up a
> > project for keeping these semi-abandoned and really-abandoned
> > libraries and projects up to date and such.
> 
> This is a common problem, however if you want to make this reasonable
> you wouldn't make it a gentoo thing, but a cross-distro effort. The
> idea has been tossed around a lot, but noone yet started implementing
> it.
> 
> However keeping things alive may not always be the right option.
> There's a reason mcrypt is abandoned. It's an ancient crypto library,
mhash, not mcrypt. I've not loked at mcrypt at all yet, so I have no
ideas as to its status.
> crypto is moving forward, there are better options. THe main user of
> mcrypt was PHP, and PHP is abandoning it with 7.2. (There are 2 other
> users in the gentoo tree of libmcrypt, which are both rather obscure
> packages - nsca and elettra.)
> 
> -- 
> Hanno Böck
> https://hboeck.de/
> 
> mail/jabber: hanno@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
> 

mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

On Mon, 25 Jun 2018 07:59:47 +0200 Hanno Böck wrote:
> On Fri, 22 Jun 2018 21:50:50 -0500
> "Marty E. Plummer" <hanetzer@startmail.com> wrote:
> 
> > So, as you may be aware I've been doing some work on moving bzip2 to
> > an autotools based build. Recently I've ran into app-crypt/mhash,
> > which is in a semi-abandoned state (talking with the maintainer on
> > twitter atm), and I was thinking it may be a good idea to set up a
> > project for keeping these semi-abandoned and really-abandoned
> > libraries and projects up to date and such.
> 
> This is a common problem, however if you want to make this reasonable
> you wouldn't make it a gentoo thing, but a cross-distro effort. The
> idea has been tossed around a lot, but noone yet started implementing
> it.
> 
> However keeping things alive may not always be the right option.
> There's a reason mcrypt is abandoned. It's an ancient crypto library,
> crypto is moving forward, there are better options.

Do you have any evidence that mcrypt should not be used?

Symmetric cryptography is quite conservative and it took years and
even decades for algorithms and their implementations to become
trusted, so there is nothing wrong in using good old verified
software.

Actually for local symmetric encryption this is the best tool I
know.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-dev] Re: mcrypt status

[Martin Vaeth]

Andrew Savchenko <bircoph@gentoo.org> wrote:
>
> Actually for local symmetric encryption this is the best tool I
> know.

What is the advantage over gpg --symmetric?

Re: [gentoo-dev] Re: mcrypt status

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

On Sat, 4 Aug 2018 09:51:14 +0000 (UTC) Martin Vaeth wrote:
> Andrew Savchenko <bircoph@gentoo.org> wrote:
> >
> > Actually for local symmetric encryption this is the best tool I
> > know.
> 
> What is the advantage over gpg --symmetric?

1) mcrypt has wider range of algorithms, including gost which I
need.
2) gpg-agent sometimes causes too much trouble (by being enforced
in gpg2) and I like it more to enter passphares without any agents.
xterm can grab screen and that is sufficient for my needs.

Other than that gpg -s in nice and good tool.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

[Hanno Böck]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

Hi,

On Sat, 4 Aug 2018 11:43:28 +0300
Andrew Savchenko <bircoph@gentoo.org> wrote:

> Do you have any evidence that mcrypt should not be used?

Well, PHP was as far as I'm aware its main user and PHP has declared
mcrypt support to be deprecated a while ago.

> Symmetric cryptography is quite conservative and it took years and
> even decades for algorithms and their implementations to become
> trusted, so there is nothing wrong in using good old verified
> software.

When it comes to cipher modes the fact that people use decades old
modes is a problem. See efail for a prominent example, but there
are many less prominent ones.

Look at the mcrypt webpage:
http://mcrypt.sourceforge.net/

Modes of Operation:

CBC
CFB
CTR
ECB
OFB
NCFB

That is a mixture of very insecure (ECB), insecure in most situations
(all others) and totally obscure modes. It doesn't include any
authenticated encryption modes, which in most situations is what you
want to use.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 944 bytes --]

On 2018-08-04 16:29, Hanno Böck wrote:
>> Do you have any evidence that mcrypt should not be used?
> Well, PHP was as far as I'm aware its main user and PHP has declared
> mcrypt support to be deprecated a while ago.

In all fairness:

Yes, PHP project has removed ext/mcrypt from core, but they only
moved it into an own PECL extension. My point here is, that they
did not drop and prune mcrypt from universe due to security
vulnerabilities.

Anyone interested in this should read the following posting [1].

tl;dr
Like most crypto libs, mcrypt isn't easy to use and you will
likely do something wrong. In favor of a better solutions which
should prevent such a misuse, mcrypt was deprecated.


See also:
=========
[1] https://why-cant-we-have-nice-things.mwl.be/requests/deprecate-then-remove-mcrypt.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

[Marty E. Plummer]

On Sat, Aug 04, 2018 at 11:43:28AM +0300, Andrew Savchenko wrote:
> On Mon, 25 Jun 2018 07:59:47 +0200 Hanno Böck wrote:
> > On Fri, 22 Jun 2018 21:50:50 -0500
> > "Marty E. Plummer" <hanetzer@startmail.com> wrote:
> > 
> > > So, as you may be aware I've been doing some work on moving bzip2 to
> > > an autotools based build. Recently I've ran into app-crypt/mhash,
> > > which is in a semi-abandoned state (talking with the maintainer on
> > > twitter atm), and I was thinking it may be a good idea to set up a
> > > project for keeping these semi-abandoned and really-abandoned
> > > libraries and projects up to date and such.
> > 
> > This is a common problem, however if you want to make this reasonable
> > you wouldn't make it a gentoo thing, but a cross-distro effort. The
> > idea has been tossed around a lot, but noone yet started implementing
> > it.
> > 
> > However keeping things alive may not always be the right option.
> > There's a reason mcrypt is abandoned. It's an ancient crypto library,
> > crypto is moving forward, there are better options.
> 
> Do you have any evidence that mcrypt should not be used?
> 
> Symmetric cryptography is quite conservative and it took years and
> even decades for algorithms and their implementations to become
> trusted, so there is nothing wrong in using good old verified
> software.
> 
> Actually for local symmetric encryption this is the best tool I
> know.
> 
> Best regards,
> Andrew Savchenko
It seems that every last person commenting on this is talking mcrypt,
not mhash, which is what I mentioned in the first place. As far as I can
tell, these are entirely differnt projects which just happen to have a
similar name.

Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 487 bytes --]

On Sat, 4 Aug 2018 13:05:56 -0500 Marty E. Plummer wrote:
[...]
> It seems that every last person commenting on this is talking mcrypt,
> not mhash, which is what I mentioned in the first place. As far as I can
> tell, these are entirely differnt projects which just happen to have a
> similar name.

Yes, they are. But it this very case I'm interested in mcrypt
status, not mhash, that's why I changed the subject field of this
discussion. 

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

Hi,

On Sat, 4 Aug 2018 07:29:47 -0700 Hanno Böck wrote:
> > Symmetric cryptography is quite conservative and it took years and
> > even decades for algorithms and their implementations to become
> > trusted, so there is nothing wrong in using good old verified
> > software.
> 
> When it comes to cipher modes the fact that people use decades old
> modes is a problem. See efail for a prominent example, but there
> are many less prominent ones.
> 
> Look at the mcrypt webpage:
> http://mcrypt.sourceforge.net/
> 
> Modes of Operation:
> 
> CBC
> CFB
> CTR
> ECB
> OFB
> NCFB
> 
> That is a mixture of very insecure (ECB), insecure in most situations
> (all others) and totally obscure modes. It doesn't include any
> authenticated encryption modes, which in most situations is what you
> want to use.

I want to use mcrypt for local encryption only, therefore I don't
really care about MACs. In my use cases modification tampering is
easy to detect by other means.

ECB is indeed unsafe and must be avoided (hey, openssl supports ECB
as well, let's ban it!).

CBC is better, but vulnerable to PODDLE, so I agree on avoiding it
as well.

As for CTR, (N)CFB, (N)OFB there is nothing obscure about them:
they are known for decades and are well studied. There are no
direct attacks on these modes known aside from detectable tampering
possibility.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 2633 bytes --]



> On Jun 23, 2018, at 6:59 AM, Alec Warner <antarus@gentoo.org> wrote:
> 
> 
> 
>> On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer <hanetzer@startmail.com> wrote:
>> On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote:
>> > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
>> > Plummer napisał:
>> > > So, as you may be aware I've been doing some work on moving bzip2 to an
>> > > autotools based build. Recently I've ran into app-crypt/mhash, which is
>> > > in a semi-abandoned state (talking with the maintainer on twitter atm),
>> > > and I was thinking it may be a good idea to set up a project for keeping
>> > > these semi-abandoned and really-abandoned libraries and projects up to
>> > > date and such.
>> > > 
>> > > Basically, an upstream for packages who's upstream is either
>> > > uncontactable or is otherwise not accepting bug fixes and patches. So
>> > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
>> > > there are others in this state.
>> > > 
>> > 
>> > So in order to fix problem of semi-abandoned packages, you're creating
>> > an indirect herd-like entity that will soon be semi-abandoned itself
>> > because people will be dumping random packages into it and afterwards
>> > nobody will claim responsibility for them.
>> > 
>> > -- 
>> > Best regards,
>> > Michał Górny
>> 
>> No, I mean for packages which are important enough in gentoo to warrant
>> such treatment. For instance, every email I've tried for bzip2's
>> upstream bounced or recieved no reply. That, I assume, is important
>> enough to actually maintain and improve. Any other library which may be
>> as important which are as inactive would be added.
>> 
> 
> I suspect this might be better done in the Linux foundation itself as they have staffing for core components that everyone is using.
This would put decision making power into the hands of bureaucrats. I would rather it remain in a community of volunteers.

I consider upstream development efforts by Gentoo developers to be beneficial to Gentoo. Nothing makes fixing an issue in Gentoo at upstream a priority quite like it affecting a key upstream developer in his day to day life.

Also, the Linux Foundation is not embarking on such a project and we clearly have someone willing to try, so I say that we should go for it. Having people that wish to take a more active role in upstream development would not make us any worse off. It is their time to volunteer, so it is not like they will volunteer it for something else if we discourage them.
> 
> -A
> 
> 
> 

[-- Attachment #2: Type: text/html, Size: 3731 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

> On Jun 23, 2018, at 9:05 AM, Jonas Stein <jstein@gentoo.org> wrote:
> 
>> On 2018-06-23 04:57, Marty E. Plummer wrote:
>>> On Fri, Jun 22, 2018 at 09:50:50PM -0500, Marty E. Plummer wrote:
>>> So, as you may be aware I've been doing some work on moving bzip2 to an
>>> autotools based build. Recently I've ran into app-crypt/mhash, which is
>>> in a semi-abandoned state (talking with the maintainer on twitter atm),
>>> and I was thinking it may be a good idea to set up a project for keeping
>>> these semi-abandoned and really-abandoned libraries and projects up to
>>> date and such.
>>> 
>>> Basically, an upstream for packages who's upstream is either
>>> uncontactable or is otherwise not accepting bug fixes and patches. So
>>> far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
>>> there are others in this state.
>>> 
>> Or... call it proxy-upstream, to be in line with the current proxy-maint
>> setup?
> 
> Please do not call it proxy-*.
> The invented word proxymaintainer and proxiedmaintainer are not usefull.
> They get always mixed, and are not understood outside of Gentoo.
> assistant developer or trainee developer would have been much more useful.

Until we have a better name, why not call it the GPL project? GPL meaning:

Gentoo
POSIX
Libraries

Misunderstandings from the obvious acronym collision aside, I think the name GPL Project would be more appealing to outsiders than “proxy-libs”, which I agree would be misunderstood in the worst possible ways.
> 
> Beside the naming I like the idea, that you want to take care for all
> abandoned libs.
> 
> Please note, that you can not generate more manpower by creating a
> project. In 2015 I calculated
In the case of creating a new upstream for key libraries shared by distributions, I disagree. As long as other distribution maintainers get on board, the deduplication of effort will result in more man power.
> 
> =====================================================
> 
> (Number of developers) / (Number of Projects) < 1.4
> 
> =====================================================
> 
> Which explains, why most projects today are run by mostly one active person.
> 
> If you find an important library, where upstream is dead, fork it and
> take responsibility for it.
I will call this point 1 of yours.

That sounds like what this project is intended to do.
> 
> It makes no sense to make a pool of dead and important software and
> delegate the responsibility to a team where nobody really knows the
> software.
I will call this point 2 of yours.

It depends on the importance of the software.
> 
> Better pick a library, communicate with maintainers of the other
> distributions and fork it. Keep the library alive in the fork.
I feel like this is the same as 1.
> 
> It is important for the security to let dead projects die.
I feel like this is 2, and that it contradicts 1.
> 
> -- 
> Best,
> Jonas
> 

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]

On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao <ryao@gentoo.org> wrote:

>
>
> On Jun 23, 2018, at 6:59 AM, Alec Warner <antarus@gentoo.org> wrote:
>
>
>
> On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer <hanetzer@startmail.com>
> wrote:
>
>> On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote:
>> > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
>> > Plummer napisał:
>> > > So, as you may be aware I've been doing some work on moving bzip2 to
>> an
>> > > autotools based build. Recently I've ran into app-crypt/mhash, which
>> is
>> > > in a semi-abandoned state (talking with the maintainer on twitter
>> atm),
>> > > and I was thinking it may be a good idea to set up a project for
>> keeping
>> > > these semi-abandoned and really-abandoned libraries and projects up to
>> > > date and such.
>> > >
>> > > Basically, an upstream for packages who's upstream is either
>> > > uncontactable or is otherwise not accepting bug fixes and patches. So
>> > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm
>> sure
>> > > there are others in this state.
>> > >
>> >
>> > So in order to fix problem of semi-abandoned packages, you're creating
>> > an indirect herd-like entity that will soon be semi-abandoned itself
>> > because people will be dumping random packages into it and afterwards
>> > nobody will claim responsibility for them.
>> >
>> > --
>> > Best regards,
>> > Michał Górny
>>
>> No, I mean for packages which are important enough in gentoo to warrant
>> such treatment. For instance, every email I've tried for bzip2's
>> upstream bounced or recieved no reply. That, I assume, is important
>> enough to actually maintain and improve. Any other library which may be
>> as important which are as inactive would be added.
>>
>>
> I suspect this might be better done in the Linux foundation itself as they
> have staffing for core components that everyone is using.
>
> This would put decision making power into the hands of bureaucrats. I
> would rather it remain in a community of volunteers.
>

Meh, it doesn't hurt to ask there about interest (they certainly fund
development of other components.) Its not like they have to accept, or that
declining somehow inhibits this development.

Part of my frustration is that seemingly "anything open source related can
be held in Gentoo" and I'm somewhat against that as I feel it dilutes the
Gentoo mission. We are here to make a distribution, not maintain random
libraries. If you want to do that feel free; but I don't see a need for
that work to be associated with Gentoo.


>
> I consider upstream development efforts by Gentoo developers to be
> beneficial to Gentoo. Nothing makes fixing an issue in Gentoo at upstream a
> priority quite like it affecting a key upstream developer in his day to day
> life.
>

>
> Also, the Linux Foundation is not embarking on such a project and we
> clearly have someone willing to try, so I say that we should go for it.
> Having people that wish to take a more active role in upstream development
> would not make us any worse off. It is their time to volunteer, so it is
> not like they will volunteer it for something else if we discourage them.
>

[-- Attachment #2: Type: text/html, Size: 4743 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[M. J. Everitt]

[-- Attachment #1.1.1: Type: text/plain, Size: 1894 bytes --]

On 05/08/18 18:01, Alec Warner wrote [excerpted]:
>
>
> On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao <ryao@gentoo.org
> <mailto:ryao@gentoo.org>> wrote:
>
>
>
>     On Jun 23, 2018, at 6:59 AM, Alec Warner <antarus@gentoo.org
>     <mailto:antarus@gentoo.org>> wrote:
>
>>
>>     I suspect this might be better done in the Linux foundation
>>     itself as they have staffing for core components that everyone is
>>     using.
>     This would put decision making power into the hands of
>     bureaucrats. I would rather it remain in a community of volunteers.
>
>
> Meh, it doesn't hurt to ask there about interest (they certainly fund
> development of other components.) Its not like they have to accept, or
> that declining somehow inhibits this development.
>
> Part of my frustration is that seemingly "anything open source related
> can be held in Gentoo" and I'm somewhat against that as I feel it
> dilutes the Gentoo mission. We are here to make a distribution, not
> maintain random libraries. If you want to do that feel free; but I
> don't see a need for that work to be associated with Gentoo.
>  
Maintaining a distro is increasingly becoming more a case of fixing
upstream's shortcomings, as they move towards completely-bundled
packages instead of thorough testing. Creating distribution packages,
especially in a source-based distro like Gentoo, requires quite a lot of
testing, and a lot of collating user feedback (in terms of bugs) to make
sure that the packages built do actually *work*.

So no, whilst it does seem on the surface to be a dilution of effort, if
it reduces the overall effort to generate robust packages, and
distributes it across multiple distros and developers, whilst
co-ordination and communication may prove a new challenge, I think this
is complementary to what everyone is trying to achieve.

</my2cents>

[-- Attachment #1.1.2: Type: text/html, Size: 3777 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Rich Freeman]

On Sun, Aug 5, 2018 at 1:01 PM Alec Warner <antarus@gentoo.org> wrote:
>
>
> Part of my frustration is that seemingly "anything open source related
> can be held in Gentoo" and I'm somewhat against that as I feel it
> dilutes the Gentoo mission. We are here to make a distribution, not
> maintain random libraries. If you want to do that feel free; but I
> don't see a need for that work to be associated with Gentoo.
>

Honestly, other than maybe some prestige I don't really get the point
of hosting random software in Gentoo either.  These days getting a
repo on github or any of its 47 competitors is a few clicks.  You have
zero overhead from a governance standpoint, and a dev can of course
stick ebuilds in the main repository with zero interference.  It seems
a lot cleaner from a copyright/etc standpoint as well.

Even openrc is hosted outside of Gentoo these days, which makes perfect sense.

With the distro as a whole it is a bit more complex, though honestly
I'd love to see us get to a point where the whole thing can be
SECURELY hosted entirely off-infra as well, even if we still chose to
run our own infra.  I just see it as a way to both provide options to
our users and ourselves.  For the latter, being able to host anything
on an outside service means that if some component of infra goes down
we could have mirrors already running and pulling from infra, or if
for some reason somebody sues us or roots us or whatever we can pick
up and move without much fuss.

Running your own wiki/bugzilla/lists/etc was about the only way to do
things in the 90s/etc, but these days there are other options...

-- 
Rich

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 1825 bytes --]

On 05/08/18 18:24, Rich Freeman wrote:
> On Sun, Aug 5, 2018 at 1:01 PM Alec Warner <antarus@gentoo.org> wrote:
>>
>> Part of my frustration is that seemingly "anything open source related
>> can be held in Gentoo" and I'm somewhat against that as I feel it
>> dilutes the Gentoo mission. We are here to make a distribution, not
>> maintain random libraries. If you want to do that feel free; but I
>> don't see a need for that work to be associated with Gentoo.
>>
> Honestly, other than maybe some prestige I don't really get the point
> of hosting random software in Gentoo either.  These days getting a
> repo on github or any of its 47 competitors is a few clicks.  You have
> zero overhead from a governance standpoint, and a dev can of course
> stick ebuilds in the main repository with zero interference.  It seems
> a lot cleaner from a copyright/etc standpoint as well.
>
> Even openrc is hosted outside of Gentoo these days, which makes perfect sense.
>
> With the distro as a whole it is a bit more complex, though honestly
> I'd love to see us get to a point where the whole thing can be
> SECURELY hosted entirely off-infra as well, even if we still chose to
> run our own infra.  I just see it as a way to both provide options to
> our users and ourselves.  For the latter, being able to host anything
> on an outside service means that if some component of infra goes down
> we could have mirrors already running and pulling from infra, or if
> for some reason somebody sues us or roots us or whatever we can pick
> up and move without much fuss.
>
> Running your own wiki/bugzilla/lists/etc was about the only way to do
> things in the 90s/etc, but these days there are other options...
>
"Cloud-based Gentoo" - yeah I see *absolutely no issues* with this ...

</sarcasm>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

[-- Attachment #1: Type: text/plain, Size: 3642 bytes --]



> On Aug 5, 2018, at 1:01 PM, Alec Warner <antarus@gentoo.org> wrote:
> 
> 
> 
>> On Sun, Aug 5, 2018 at 12:45 PM, Richard Yao <ryao@gentoo.org> wrote:
>> 
>> 
>>> On Jun 23, 2018, at 6:59 AM, Alec Warner <antarus@gentoo.org> wrote:
>>> 
>>> 
>>> 
>>>> On Sat, Jun 23, 2018 at 3:30 AM, Marty E. Plummer <hanetzer@startmail.com> wrote:
>>>> On Sat, Jun 23, 2018 at 09:22:00AM +0200, Michał Górny wrote:
>>>> > W dniu pią, 22.06.2018 o godzinie 21∶50 -0500, użytkownik Marty E.
>>>> > Plummer napisał:
>>>> > > So, as you may be aware I've been doing some work on moving bzip2 to an
>>>> > > autotools based build. Recently I've ran into app-crypt/mhash, which is
>>>> > > in a semi-abandoned state (talking with the maintainer on twitter atm),
>>>> > > and I was thinking it may be a good idea to set up a project for keeping
>>>> > > these semi-abandoned and really-abandoned libraries and projects up to
>>>> > > date and such.
>>>> > > 
>>>> > > Basically, an upstream for packages who's upstream is either
>>>> > > uncontactable or is otherwise not accepting bug fixes and patches. So
>>>> > > far I can only think of app-crypt/mhash and app-arch/bzip2 but I'm sure
>>>> > > there are others in this state.
>>>> > > 
>>>> > 
>>>> > So in order to fix problem of semi-abandoned packages, you're creating
>>>> > an indirect herd-like entity that will soon be semi-abandoned itself
>>>> > because people will be dumping random packages into it and afterwards
>>>> > nobody will claim responsibility for them.
>>>> > 
>>>> > -- 
>>>> > Best regards,
>>>> > Michał Górny
>>>> 
>>>> No, I mean for packages which are important enough in gentoo to warrant
>>>> such treatment. For instance, every email I've tried for bzip2's
>>>> upstream bounced or recieved no reply. That, I assume, is important
>>>> enough to actually maintain and improve. Any other library which may be
>>>> as important which are as inactive would be added.
>>>> 
>>> 
>>> I suspect this might be better done in the Linux foundation itself as they have staffing for core components that everyone is using.
>> This would put decision making power into the hands of bureaucrats. I would rather it remain in a community of volunteers.
> 
> Meh, it doesn't hurt to ask there about interest (they certainly fund development of other components.) Its not like they have to accept, or that declining somehow inhibits this development.
> 
> Part of my frustration is that seemingly "anything open source related can be held in Gentoo" and I'm somewhat against that as I feel it dilutes the Gentoo mission. We are here to make a distribution, not maintain random libraries. If you want to do that feel free; but I don't see a need for that work to be associated with Gentoo.

This could just be done as a downstream effort that carries patches without a subproject, but structuring it as a subproject would be a call for collaboration with other distributions, which would ultimately benefit us.

>  
>> 
>> I consider upstream development efforts by Gentoo developers to be beneficial to Gentoo. Nothing makes fixing an issue in Gentoo at upstream a priority quite like it affecting a key upstream developer in his day to day life.
>> 
>> 
>> Also, the Linux Foundation is not embarking on such a project and we clearly have someone willing to try, so I say that we should go for it. Having people that wish to take a more active role in upstream development would not make us any worse off. It is their time to volunteer, so it is not like they will volunteer it for something else if we discourage them.

[-- Attachment #2: Type: text/html, Size: 5426 bytes --]

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

> On Aug 5, 2018, at 1:24 PM, Rich Freeman <rich0@gentoo.org> wrote:
> 
>> On Sun, Aug 5, 2018 at 1:01 PM Alec Warner <antarus@gentoo.org> wrote:
>> 
>> 
>> Part of my frustration is that seemingly "anything open source related
>> can be held in Gentoo" and I'm somewhat against that as I feel it
>> dilutes the Gentoo mission. We are here to make a distribution, not
>> maintain random libraries. If you want to do that feel free; but I
>> don't see a need for that work to be associated with Gentoo.
>> 
> 
> Honestly, other than maybe some prestige I don't really get the point
> of hosting random software in Gentoo either.  These days getting a
> repo on github or any of its 47 competitors is a few clicks.  You have
> zero overhead from a governance standpoint, and a dev can of course
> stick ebuilds in the main repository with zero interference.  It seems
> a lot cleaner from a copyright/etc standpoint as well.

Prestige is good. We have prestige from our (myself and a few others) work in upstream ZFS and Gentoo is well respected there. You will not hear binary package zealots bashing Gentoo in ZFS circles. If a sub-project that touches the entire OSS community can be even a tenth as effective as the efforts in ZFS have been in eliminating binary package zealotry, it would be well worth it.
> 
> Even openrc is hosted outside of Gentoo these days, which makes perfect sense.
> 
> With the distro as a whole it is a bit more complex, though honestly
> I'd love to see us get to a point where the whole thing can be
> SECURELY hosted entirely off-infra as well, even if we still chose to
> run our own infra.  I just see it as a way to both provide options to
> our users and ourselves.  For the latter, being able to host anything
> on an outside service means that if some component of infra goes down
> we could have mirrors already running and pulling from infra, or if
> for some reason somebody sues us or roots us or whatever we can pick
> up and move without much fuss.
> 
> Running your own wiki/bugzilla/lists/etc was about the only way to do
> things in the 90s/etc, but these days there are other options...
> 
> -- 
> Rich
> 

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Rich Freeman]

On Sun, Aug 5, 2018 at 2:12 PM Richard Yao <ryao@gentoo.org> wrote:
>
>
> Prestige is good. We have prestige from our (myself and a few others) work in upstream ZFS and Gentoo is well respected there.

Sure, but ZFS on Linux isn't a Gentoo project.

I'm not saying people who are Gentoo devs can't also do other things.
Lots of Gentoo devs are involved in lots of stuff that gets a fair bit
of respect. OpenRC is a big example of this.  From time to time I bump
into signs of Gentoo on upstream projects (just today that included
SoapySDRPlay).

Also, this gives us an opportunity to set an example, in helping to
ensure the upstream project is maintained in a distro-friendly manner
where Gentoo is a first class citizen.

I'm not saying that stuff like this should be banned from infra.  It
just seems like an unnecessary constraint all-around.  It means that
the project has to generally follow Gentoo policies/etc, and is
limited to the tools we provide.  Just something to think about...


-- 
Rich

Re: [gentoo-dev] Idea for a new project: gentoo-libs

[Richard Yao]

> On Aug 5, 2018, at 2:35 PM, Rich Freeman <rich0@gentoo.org> wrote:
> 
>> On Sun, Aug 5, 2018 at 2:12 PM Richard Yao <ryao@gentoo.org> wrote:
>> 
>> 
>> Prestige is good. We have prestige from our (myself and a few others) work in upstream ZFS and Gentoo is well respected there.
> 
> Sure, but ZFS on Linux isn't a Gentoo project.
> 
> I'm not saying people who are Gentoo devs can't also do other things.
> Lots of Gentoo devs are involved in lots of stuff that gets a fair bit
> of respect. OpenRC is a big example of this.  From time to time I bump
> into signs of Gentoo on upstream projects (just today that included
> SoapySDRPlay).
> 
> Also, this gives us an opportunity to set an example, in helping to
> ensure the upstream project is maintained in a distro-friendly manner
> where Gentoo is a first class citizen.
> 
> I'm not saying that stuff like this should be banned from infra.  It
> just seems like an unnecessary constraint all-around.  It means that
> the project has to generally follow Gentoo policies/etc, and is
> limited to the tools we provide.  Just something to think about...
Which policies would those be? The upstream projects that we do have as Gentoo sub-projects seem to have plenty of freedom.
> 
> 
> -- 
> Rich
>