[gentoo-dev] Re: Packages up for grabs

[gentoo-dev] Re: Packages up for grabs

[Christian Faulhammer]

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

Chris Gianelloni <wolf31o2@gentoo.org>:

> I had already asked for someone else to take these, but never got any
> response.
> net-misc/icaclient

 I'll take this.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Packages up for grabs

[Bernd Steinhauser]

Gilles Dartiguelongue schrieb:
>>  - net-wireless/rt2x00
>  I might need this one for work, but it's not set in stone yet so if
> anybody has the hardware, please pick this one up.
> 

rt2x00 will be introduced in kernel 2.6.24, so that package might be
deprecated then.

Bernd
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Packages up for grabs

[Ali Polatel]

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

Christian Heim yazmış:
> Okay, today was another tree-wrecking^Hcleaning day. Find below the
> packages that got assigned to maintainer-needed due to no maintainer
> being available.
> 
> As usual you are free to pick them up, if you'd like to maintain them...
> 
> maintainer-needed@gentoo.org:
>  - app-misc/pwsafe
>  - dev-libs/shhopt
>  - dev-util/ccmalloc
>  - dev-util/cook
>  - dev-util/pmk
>  - dev-util/pretrace
>  - net-misc/knock
>  - net-misc/secpanel
>  - www-client/surfraw

Taking these if nobody else wants them.

-ali

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

[gentoo-dev] Re: packages up for grabs

[Tiziano Müller]

Donnie Berkholz wrote:

> On 01:09 Sat 31 May     , Mike Frysinger wrote:
> 
> I'd like to advocate for interested people to pick up a few of these.
> 
>> net-misc/ntp
might be a candidate for the sysadmin-herd.

Cheers,
Tiziano


-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: packages up for grabs

[Ali Polatel]

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

Mike Frysinger yazmış:
> no herd:
> dev-libs/libtomcrypt
> dev-libs/libtomfloat
> dev-libs/libtommath
> dev-libs/libtompoly
> dev-libs/tomsfastmath

I'll take these if noone else wants them. I use them from time to time
for my studies.

-- 
Regards,
Ali Polatel

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

[gentoo-dev] Re: packages up for grabs

[Ali Polatel]

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

Thilo Bangert yazmış:
> 
> >
> > > net-misc/ntp
> >
> > This is rather basic, isn't it ?  It keeps your clock accurate.
> > Is there any alternative ?
> 
> net-misc/openntpd - by the OpenBSD folks...
> 
> http://openntpd.org/
> http://en.wikipedia.org/wiki/OpenNTPD

Or net-misc/clockspeed :-)


> 
> regards
> Thilo

-- 
Regards,
Ali Polatel

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

[gentoo-dev] Re: packages up for grabs

[Diego 'Flameeyes' Pettenò]

Mike Frysinger <vapier@gentoo.org> writes:

> dev-util/elfsh

I'll take a look, I might have some use for this.

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: packages up for grabs

[Gunnar Wrobel]

Hi,

Mike Frysinger <vapier@gentoo.org> writes:

> many of these are low maintence ... i'd forgotten i was even listed under them 
> as i havent seen a bug report in a long time.  some i added (well probably 
> too many) on a lark, so if they do end up being crappy and no one cares, i 
> guess that's why we have a tree cleaners group.
>
[..snip..]
>
> www-apps herd:
> www-apps/horde-chora
> www-apps/horde-gollem
> www-apps/horde-groupware
> www-apps/horde-imp
> www-apps/horde-ingo
> www-apps/horde-jeta
> www-apps/horde-kronolith
> www-apps/horde
> www-apps/horde-mimp
> www-apps/horde-mnemo
> www-apps/horde-nag
> www-apps/horde-passwd
> www-apps/horde-pear
> www-apps/horde-turba
> www-apps/horde-webmail

I'll take these as I am on www-apps and active Horde developer.

Cheers,

Gunnar

-- 
Gunnar Wrobel                    Gentoo Developer
__________________C_o_n_t_a_c_t__________________

Mail: wrobel@gentoo.org
WWW:  http://www.gunnarwrobel.de
IRC:  #gentoo-web at freenode.org
_________________________________________________
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: packages up for grabs

[Joe Peterson]

Has anyone volunteered to take net-misc/ntp?  I know there are alternatives
(like OpenNTPD), but this one is the "official" one, so I'd hate to see it
slip into substandard quality.  Also, e.g. OpenNTPD is a subset and is less
accurate, so it is not a complete replacement.  I will take it on if no one
else wants it.

						-Thanks, Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: packages up for grabs

[Joe Peterson]

Joe Peterson wrote:
> Has anyone volunteered to take net-misc/ntp?  I know there are alternatives
> (like OpenNTPD), but this one is the "official" one, so I'd hate to see it
> slip into substandard quality.  Also, e.g. OpenNTPD is a subset and is less
> accurate, so it is not a complete replacement.  I will take it on if no one
> else wants it.

Ah, never mind; I see this is now part of the base-system herd.  Cool.  :)

					-Joe
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Packages up for grabs

[Tiziano Müller]

Krzysiek Pawlik wrote:
>   * media-video/griffith - also easy, pending version bump
Took it.

-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] Re: Packages up for grabs

[Christian Faulhammer]

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

Hi,

Alexis Ballier <aballier@gentoo.org>:
> >   dev-lang/erlang (lang-misc) -- a version bump now and then (four
> > times a year), seldomly but then obscure bugs, cooperative upstream
> 
> I would appreciate if you could take care of my fbsd problem ;p

 Done.
 
> >   media-sound/cmus --  low maintenance
> 
> can probably be dropped to sound

 Great.  Done.
 
> I hope that doesn't mean you're planning to retire ;p

 Kind of.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Packages up for grabs

[Christian Faulhammer]

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

Hi,

Thomas Anderson <gentoofan23@gentoo.org>:

> On Sun, Jul 20, 2008 at 08:44:24AM +0200, Christian Faulhammer wrote:
> >   app-admin/tmpwatch -- low maintenance
> > 
> I can take this one.

 Please add yourself and reassing bugs.
 
> >   dev-cpp/libthrowable,
> >   app-portage/gatt -- very cooperative upstream for both (mlangc for
> > both)
> > 
> 
> I can also take these two as well, as I use them for arch testing.

 Also great.  Please see above for actions.

V-Li


-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: packages up for grabs

[Diego 'Flameeyes' Pettenò]

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

Daniel Drake <dsd@gentoo.org> writes:

> dev-dotnet/evolution-sharp

I was going to ask you about this last week, I guess I'll look into it
(although it makes me feel dirty to work with .NET stuff, I've been
working with worse stuff :P).

-- 
Diego "Flameeyes" Pettenò
http://blog.flameeyes.eu/

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

[gentoo-dev] Re: Packages up for grabs

[Ryan Hill]

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

On Wed, 11 Feb 2009 19:02:12 +0100
"Santiago M. Mola" <coldwind@gentoo.org> wrote:

> net-p2p/nicotine+

I can take this one.

-- 
gcc-porting,                                      by design, by neglect
treecleaner,                              for a fact or just for effect
wxwidgets @ gentoo     EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: Packages up for grabs

[Diego Elio Pettenò]

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

Il giorno dom, 10/10/2010 alle 15.45 +0100, Markos Chandras ha scritto:
> 
> app-backup/rsnapshot 

I guess I can (co-)maintain this as I'm using it a few systems already.

-- 
Diego Elio Pettenò — “Flameeyes”
http://blog.flameeyes.eu/

If you found a .asc file in this mail and know not what it is,
it's a GnuPG digital signature: http://www.gnupg.org/


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

Re: [gentoo-dev] Re: Packages up for grabs

[Jeroen Roovers]

On Sun, 10 Oct 2010 18:13:20 +0200
Diego Elio Pettenò <flameeyes@gmail.com> wrote:

> Il giorno dom, 10/10/2010 alle 15.45 +0100, Markos Chandras ha
> scritto:

That message failed to reach me and it isn't on archives.g.o either,
neither in gentoo-dev nor gentoo-dev-announce.


     jer

[gentoo-dev] Re: Packages up for grabs

[Duncan]

Jeroen Roovers posted on Tue, 12 Oct 2010 02:52:23 +0200 as excerpted:

> On Sun, 10 Oct 2010 18:13:20 +0200
> Diego Elio Pettenò <flameeyes@gmail.com> wrote:
> 
>> Il giorno dom, 10/10/2010 alle 15.45 +0100, Markos Chandras ha scritto:
> 
> That message failed to reach me and it isn't on archives.g.o either,
> neither in gentoo-dev nor gentoo-dev-announce.

It's on gmane as

<http://permalink.gmane.org/gmane.linux.gentoo.devel/68325>

"""""

The following packages list me as maintainer. I am gonna remove myself
from them soonish ( 15-20 days ) so feel free to grab them if you want to

app-admin/makepasswd
app-backup/rsnapshot
app-crypt/bsign
dev-util/dissy
media-gfx/viewnior
media-libs/liblqr
sci-biology/biogrep
net-misc/pmsvn
x11-misc/dragbox
sys-apps/pyrenamer
media-gfx/arss

All of them *should* work just fine but I am not quite aware
about the status of upstream development.

I plan to remove myself from many more packages which I co-maintain with
several herds such as qt,kde,desktop-misc and
graphics. Hopefully they will be able to maintain them without me
supervise them.

"""""

These have now been taken (reordered alpha by category):

app-admin/makepasswd		tomk
app-backup/rsnapshot		flameeyes
media-gfx/viewnior		ricmm
sci-biology/biogrep		jlec

Leaving:

app-crypt/bsign
dev-util/dissy
media-gfx/arss
media-libs/liblqr
net-misc/pmsvn
sys-apps/pyrenamer
x11-misc/dragbox

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Packages up for grabs

[Tomás Touceda]

2010/10/12 Duncan <1i5t5.duncan@cox.net>:
> Jeroen Roovers posted on Tue, 12 Oct 2010 02:52:23 +0200 as excerpted:
>
>> On Sun, 10 Oct 2010 18:13:20 +0200
>> Diego Elio Pettenò <flameeyes@gmail.com> wrote:
>>
>>> Il giorno dom, 10/10/2010 alle 15.45 +0100, Markos Chandras ha scritto:
>>
>> That message failed to reach me and it isn't on archives.g.o either,
>> neither in gentoo-dev nor gentoo-dev-announce.
>
> It's on gmane as
>
> <http://permalink.gmane.org/gmane.linux.gentoo.devel/68325>
>
> """""
>
> The following packages list me as maintainer. I am gonna remove myself
> from them soonish ( 15-20 days ) so feel free to grab them if you want to
>
> app-admin/makepasswd
> app-backup/rsnapshot
> app-crypt/bsign
> dev-util/dissy
> media-gfx/viewnior
> media-libs/liblqr
> sci-biology/biogrep
> net-misc/pmsvn
> x11-misc/dragbox
> sys-apps/pyrenamer
> media-gfx/arss
>
> All of them *should* work just fine but I am not quite aware
> about the status of upstream development.
>
> I plan to remove myself from many more packages which I co-maintain with
> several herds such as qt,kde,desktop-misc and
> graphics. Hopefully they will be able to maintain them without me
> supervise them.
>
> """""
>
> These have now been taken (reordered alpha by category):
>
> app-admin/makepasswd            tomk
> app-backup/rsnapshot            flameeyes
> media-gfx/viewnior              ricmm
> sci-biology/biogrep             jlec
>
> Leaving:
>
> app-crypt/bsign

dev-util/dissy

I'll take this one.

Cheers,
Tomas

[gentoo-dev] Re: Packages up for grabs

[Christian Faulhammer]

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

Hi,

Sebastian Pipping <sping@gentoo.org>:

> On 01/06/11 13:17, Christian Faulhammer wrote:
> > app-text/rnv
> >  Near to no maintenance work.
> 
> Besides the bump to 1.7.10... - in tree is 1.7.8-r2.

 Where did you find 1.7.10? http://ftp.davidashen.net/PreTI/RNV/ does
not contain that.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Packages up for grabs

[Sebastian Pipping]

On 01/07/11 09:49, Christian Faulhammer wrote:
>> Besides the bump to 1.7.10... - in tree is 1.7.8-r2.
> 
>  Where did you find 1.7.10? http://ftp.davidashen.net/PreTI/RNV/ does
> not contain that.

http://sourceforge.net/projects/rnv/



sebastian

[gentoo-dev] Re: Packages up for grabs

[Christian Faulhammer]

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

Hi,

Sebastian Pipping <sping@gentoo.org>:

> On 01/07/11 09:49, Christian Faulhammer wrote:
> >> Besides the bump to 1.7.10... - in tree is 1.7.8-r2.
> > 
> >  Where did you find 1.7.10? http://ftp.davidashen.net/PreTI/RNV/
> > does not contain that.
> 
> http://sourceforge.net/projects/rnv/

 Bumped and I dropped maintainership.

V-Li 

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Packages up for grabs

[Christian Faulhammer]

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

Hi,

Dirkjan Ochtman <djc@gentoo.org>:

> On Thu, Jan 6, 2011 at 13:17, Christian Faulhammer <fauli@gentoo.org>
> wrote:
> > dev-lang/erlang
> >  Very little bug inflow, responsive upstream (subscribe to their
> > -patches and -bugs mailing lists), great support from users.
> > lang-misc is still there as herd maintainer, but hardly alive.  One
> > bug open (compile failure in ~arch, upstream informed, package hard
> > masked), which I would like to close on my own.
> 
> I don't really know much about it, but I need this for dev-db/couchdb,
> so if no one else wants it, I'll take it.

 I passed it on to you as the bug seems to be fixed by a PLD Linux
patch.  I forwarded it upstream, so the next release should contain a
fix.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Packages up for grabs

[Ryan Hill]

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

On Thu, 01 Mar 2012 22:17:12 +0000
Markos Chandras <hwoarang@gentoo.org> wrote:

> 	app-text/chm2pdf

I maintain a bunch of chm stuff, so I'll help with this.

> 	sys-apps/cpuid

Got it.


-- 
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Packages up for grabs

[Mike Gilbert]

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

On 01/20/2013 05:30 AM, Pacho Ramos wrote:
> Due swegener focusing in less packages until he has more time:
> x11-misc/x11vnc -> maybe net-libs/libvncserver could be interested in
> this
> 

Yeah, I picked it up. As always, anyone is free to co-maintain if they like.


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

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

Due ferringb retirement the following packages are up for grabs:
app-arch/tarsync
dev-python/snakeoil
dev-util/bsdiff
dev-util/diffball
sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained
and neither has eapi5 support)

[gentoo-dev] Re: Packages up for grabs

[Pacho Ramos]

El dom, 16-06-2013 a las 12:03 +0200, Pacho Ramos escribió:
> Due elvanor lack of time the following packages are up for grabs:
> app-office/openerp-server
> net-print/xerox-drivers
> media-gfx/iscan-plugin-gt-f720 
> net-libs/pjsip
> 

Also:
app-office/openerp-client
app-office/openerp-web 

Re: [gentoo-dev] Packages up for grabs

[Dirkjan Ochtman]

On Sun, Jun 16, 2013 at 11:49 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> Due ferringb retirement the following packages are up for grabs:
> dev-python/snakeoil
> sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained
> and neither has eapi5 support)

Looks like these should go together, with pkgcore-checks (currently
maintained by python, but I'm not sure that makes sense). There's also
app-portage/maintainer-helper, which has a dead HOMEPAGE in jokey's ~
on woodpecker.

Cheers,

Dirkjan

[gentoo-dev] Re: Packages up for grabs

[Michael Palimaka]

On 16/06/2013 23:02, gmt@malth.us wrote:
> There'd be no problem resurrecting it from the grave, if need be, would there?

Please note that being unmaintained does not mean the package will be 
removed. That would only happen if there are long term unresolved issues 
with the package.

Best regards,
Michael

Re: [gentoo-dev] Packages up for grabs

[Brian Dolbec]

On Sun, 2013-06-16 at 14:48 +0200, Dirkjan Ochtman wrote:
> On Sun, Jun 16, 2013 at 11:49 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> > Due ferringb retirement the following packages are up for grabs:
> > dev-python/snakeoil
> > sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained
> > and neither has eapi5 support)
> 
> Looks like these should go together, with pkgcore-checks (currently
> maintained by python, but I'm not sure that makes sense). There's also
> app-portage/maintainer-helper, which has a dead HOMEPAGE in jokey's ~
> on woodpecker.
> 
> Cheers,
> 
> Dirkjan
> 

I'll take pkgcore (if somehow we can get eapi 5 finished.)

I'll take snakeoil.  I'm adding some of it's libs into catalyst

maintainer-helper also did not work for my testing.  I needed to patch
it just to get it to start.

Re: [gentoo-dev] Packages up for grabs

[Tom Wijsman]

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

On Sun, 16 Jun 2013 06:55:23 -0700
Brian Dolbec <dolsen@gentoo.org> wrote:

> I'll take pkgcore (if somehow we can get eapi 5 finished.)

Here's the catch: it's not only about finishing EAPI 5, but also about
implementing the upcoming EAPI 6 changes and fixing any bugs that arise.

For it to be feasible to use it would need an upstream maintainer
for that package; it goes a little further than "let's implement X or
fix Y", the code has to be understood to gain the necessary insight.

If one just hacks in things to make it work, he'll waste efforts.
Think before anyone plans to pick this up, it is quite a commitment.

http://c2.com/cgi/wiki?LegacyCode

http://www.amazon.com/books/dp/0131177052

I sincerely have interest in working on a heavily refactored PM or a PM
from scratch; but, I can't see myself pick up a big Python project as
I'm not really used to anything beyond average Python scripts. Or maybe
I'm afraid of nothing, I can't tell in advance not knowing its code.

I'll take it into consideration though; there is quite a huge choice
between applying software re-engineering practices (mostly reverse
engineering) to pkgcore, applying those practices (mostly refactoring)
to Portage or implementing an all new PM from scratch.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Packages up for grabs

[Brian Dolbec]

On Sun, 2013-06-16 at 16:44 +0200, Tom Wijsman wrote:
> On Sun, 16 Jun 2013 06:55:23 -0700
> Brian Dolbec <dolsen@gentoo.org> wrote:
> 
> > I'll take pkgcore (if somehow we can get eapi 5 finished.)
> 
> Here's the catch: it's not only about finishing EAPI 5, but also about
> implementing the upcoming EAPI 6 changes and fixing any bugs that arise.
> 
> For it to be feasible to use it would need an upstream maintainer
> for that package; it goes a little further than "let's implement X or
> fix Y", the code has to be understood to gain the necessary insight.
> 
> If one just hacks in things to make it work, he'll waste efforts.
> Think before anyone plans to pick this up, it is quite a commitment.
> 
> http://c2.com/cgi/wiki?LegacyCode
> 
> http://www.amazon.com/books/dp/0131177052
> 
> I sincerely have interest in working on a heavily refactored PM or a PM
> from scratch; but, I can't see myself pick up a big Python project as
> I'm not really used to anything beyond average Python scripts. Or maybe
> I'm afraid of nothing, I can't tell in advance not knowing its code.
> 
> I'll take it into consideration though; there is quite a huge choice
> between applying software re-engineering practices (mostly reverse
> engineering) to pkgcore, applying those practices (mostly refactoring)
> to Portage or implementing an all new PM from scratch.
> 

Thank you for considering helping.  I have stayed away form the
intricate details of package management in the past, but I also do not
like how long portage is taking now for dep calculations.  So, I am
going to look into what it needs to be completed. I know there are
others out there that would also like to see pkgcore keep going.  If we
(that means I want help, so please speak up) can get EAPI 5 finished.
Then EAPI 6 will be that much easier when the time comes, which is
hopefully not too soon.

For the record, I have admin capability to pkgcore's repo, so if we can
get things ironed out.  It will be possible to push the changes to the
main repo and release it.  But, I also admit that pkgcore may have to
move to an overlay to get it up to speed with current required
functionality.

Re: [gentoo-dev] Packages up for grabs

[Pacho Ramos]

El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
[...]
> Thank you for considering helping.  I have stayed away form the
> intricate details of package management in the past, but I also do not
> like how long portage is taking now for dep calculations. 

And, cannot that efforts be put in enhancing portage instead?

Re: [gentoo-dev] Packages up for grabs

[hasufell]

On 06/16/2013 07:21 PM, Pacho Ramos wrote:
> El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
> [...]
>> Thank you for considering helping.  I have stayed away form the
>> intricate details of package management in the past, but I also do not
>> like how long portage is taking now for dep calculations. 
> 
> And, cannot that efforts be put in enhancing portage instead?
> 
> 
> 

How many forks do we got now?

And I know of at least another gentoo dev who is working on his own.

Re: [gentoo-dev] Packages up for grabs

[Brian Dolbec]

On Sun, 2013-06-16 at 19:21 +0200, Pacho Ramos wrote:
> El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
> [...]
> > Thank you for considering helping.  I have stayed away form the
> > intricate details of package management in the past, but I also do not
> > like how long portage is taking now for dep calculations. 
> 
> And, cannot that efforts be put in enhancing portage instead?
> 
> 
> 

Many of the speed improvements currently in portage CAME from Brian's
work in pkgcore.  But there comes a time when you can do only so much
with the framework that portage is based upon.  Pkgcore's base framework
is done differently and more efficiently, which is a good deal of why it
is so much faster than portage.

It has been long past due for gentoo to switch to the newer, better base
framework that is pkgcore and enhance it.

But, as you can see in gentoo's package management history for portage
and pkgcore, development tends to be a lonely endeavour, with the brunt
of it lying solely on one developer.  That has currently been the case
for portage for the past many years as well.  Others have chipped in,
including myself, but it is Zac that is doing most of it.  Too many
others have started a PM in c, c++, to replace portage, with only
paludis having come into usable existence.

Re: [gentoo-dev] Packages up for grabs

[Tom Wijsman]

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

On Sun, 16 Jun 2013 19:21:38 +0200
Pacho Ramos <pacho@gentoo.org> wrote:

> El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
> [...]
> > Thank you for considering helping.  I have stayed away form the
> > intricate details of package management in the past, but I also do
> > not like how long portage is taking now for dep calculations. 
> 
> And, cannot that efforts be put in enhancing portage instead?

To make you see the problems and decisions, I'm going to elaborate a
little and would like you to ask yourself some questions.

Is it possible to reasonable enhance the Portage code to improve dep
calculations in a reasonable amount of time?

Let's take a call graph, demonstrating the amount of calls on the
arrows and the amount of ticks spend in the call in the boxes:

http://i.imgur.com/A93CdNR.png

Which part do you think is problematic? What can we do to get an
improvement in time that you can actually benefit from? Which
improvements are reasonable to implement? ...?

Ignoring that call graph, you could look at what has recently been
introduced to increase the amount of time needed to calculate the
dependency graph; you don't have to look far.

http://blogs.gentoo.org/mgorny/2013/05/27/the-pointless-art-of-subslots/

While I don't want point out the contents of that blog post, the title
is relevant; implementing features like subslots on an algorithm that
was not written with subslots in mind introduces a lot of inefficiency.

And it's not just subslots, newer features keep getting added to the
dependency graph calculation and it gets slower and slower over time.
It feels like revdep-rebuild moved into the dependency calculation!

A combination of these two above arguments ("where do we start?" and
"why try to fix something broken by design?") makes me feel that there
is need for a huge refactoring; ask yourself another question, what if
these systems were written from scratch with subslots in mind?

Exactly, if you write a system with the features in mind you can write
it much more efficient and don't have to deal with historical decisions
that you have made in the past; you can continue writing without having
to change half of your code, because you though about it in advance.
But well, this is true in the start; some EAPIs later, history repeats!

So, when we acknowledge that it is useless to waste effort on fixes
that are unlikely to have a huge benefit or rewriting something that
might as well get replaced some years later; we should instead look for
better opportunities to do, there are multiple options:

 1) Spend an awful lot of time refactoring our well known Portage;
    this doesn't only involve moving code around, but also nuking
    legacy code you can't deal with (see my earlier response) as well
    as writing new code where it is needed. It may sound easy, it isn't.

 2) Write a system from scratch that is certain to be future proof;
    it is designed with the current and future specifications in mind,
    not based on specifications that were awesome some time in the past.

 3) Spend time on learning how pkgcore is implemented, then improve it;
    pkgcore can be somewhat seen as a a mix from (1) and (2).

Then, which option would you pick?

I'm not saying Portage or the team behind it is bad; it is just a bit
at the end of its time, I'm afraid of what the future will do to it.

For option (1), I've thinked slightly further than to just generate the
dependency graph, there are two things that came to mind that might be
interesting _if_ we can get it to somehow work:

 A) Multiple threads

    I think the way trees work (branches), threads are a huge benefit.

    Maybe zmedico can elaborate on this again, but there were some
    problems that make it not easy to introduce these threads; there
    was something regarding a global interpreter lock, but I can't
    recall the details and am not that acquainted with Python.

    Besides that, the threads will have to be organized; so properly
    designing the threads, locks and inter-thread interactions might be
    an interesting task that could require some effort.

 B) Additional caching

    Some of the parts of the dependency graph calculation could benefit
    from a bit of caching; implementing caching right might be a tricky
    thing, too small cache is useless and too large cache is overhead.

    Let me take one example part; resolving the USE flags to consider
    which packages are dependencies, this happens again and again.

    For example, let's say you have

        >=dev-libs/glib-2.33:2
        gnome-keyring? ( >=app-crypt/libsecret-0.5 )
        introspection? ( >=dev-libs/gobject-introspection-1 )

    then Portage has to go and turn that into maybe something like

        >=dev-libs/glib-2.33:2

    because the user has neither USE flag set; and it is not only the
    USE flags the user has set, but also the USE flag in profiles, the
    default USE flags, the REQUIRED_USE and sometimes even other USE
    flags like "use1? ( use2? ( ATOM ) )". Heh, complexity!

    So, let's say we want to cache this operation, then we could store
    a pair of the following details in the cache:

    - Checksum of the ebuild.
    - USE flags that the user relevant to the ebuild.
    - Resulting dependency variables.

    So, instead of having to compute the whole thing, it simply can
    look up the checksum and the USE flags the user has set and
    immediately get back the right dependency string. That sounds
    awesome, but how well does the cache function?

    To know that, we would have to look at cache invalidation.

    - How often does the ebuild checksum change?
      --> Not so much, especially not for stable ebuilds.

    - How often do the users USE flags change for a specific ebuild?
      --> Not so much, only when the user explicitly changes it or some
      masking happens in the profile which both don't happen too much.

    That's really great, but now three sad questions:

    - But how big does this cache grow?
      No idea, it requires another study that implements half of this.

    - But how much does this really speed up?
      Hard to tell without trying it.

    - Erm, what about the USE flags the reverse dependencies force?
      Oops, no idea is perfect; can we resolve that?! Heh, no idea...

You can see that it is not hard to come up with ideas like (A) and (B);
but, it is much harder to come up with ideas that actually work, which
is why I think we will not see any beneficial improvement to Portage
tree soon, unless we are going to drop features and write alternatives.

Back to the options...

For option (2) I made a very small start and might continue with this
over the vacation; but before I do that, I'm likely going to evaluate
option (3) if other people are going to jump in as well, perhaps
helping along pkgcore can help me gain knowledge to better write (2)
further in the future when pkgcore is found to be past its time.

Whatever we do, I hope a good educated choice is made...

Until then, I hope I can continue to reasonably use Portage.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Packages up for grabs

[Tom Wijsman]

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

On Sun, 16 Jun 2013 19:27:12 +0200
hasufell <hasufell@gentoo.org> wrote:

> On 06/16/2013 07:21 PM, Pacho Ramos wrote:
> > El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
> > [...]
> >> Thank you for considering helping.  I have stayed away form the
> >> intricate details of package management in the past, but I also do
> >> not like how long portage is taking now for dep calculations. 
> > 
> > And, cannot that efforts be put in enhancing portage instead?
> > 
> 
> How many forks do we got now?

How much longer are we going to hold on to something that suffers from
feature creep and is based on a design invented years ago that doesn't
take into account the new features (eg. subslots) that are added today?

See my reply to Pacho for more insight why we can't enhance Portage.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: Packages up for grabs

[Duncan]

Tom Wijsman posted on Sun, 16 Jun 2013 20:23:24 +0200 as excerpted:

> On Sun, 16 Jun 2013 19:21:38 +0200 Pacho Ramos <pacho@gentoo.org> wrote:
> 
>> El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
>> [...]
>> > Thank you for considering helping.  I have stayed away form the
>> > intricate details of package management in the past, but I also do
>> > not like how long portage is taking now for dep calculations.
>> 
>> And, cannot that efforts be put in enhancing portage instead?
> 
> To make you see the problems and decisions, I'm going to elaborate a
> little and would like you to ask yourself some questions.
> 
> Is it possible to reasonable enhance the Portage code to improve dep
> calculations in a reasonable amount of time?

TL;DR: SSDs help. =:^)

Quite apart from the theory and question of making the existing code 
faster vs. a new from-scratch implementation, there's the practical 
question of what options one can actually use to deal with the problem 
/now/.

FWIW, one solution (particularly for folks who don't claim to have 
reasonable coding skills and thus have limited options in that regard) is 
to throw hardware at the problem.

I recently upgraded my main system to SDD.  As it happens, my primary 
boot didn't speed up much[1], but having both the main system partition 
(bindirs/libdirs/etc) and the portage tree and overlays on SSD 
*DRAMATICALLY* improved portage's update-ask-deep-newuse-@world 
dependency resolution time, both for the cold-tree-cache case, and, 
surprisingly, even (apparently, I've not timed it but I was sometimes 
annoyed by the time before especially for hot-cache case, and it hasn't 
bothered me at all since the upgrade) for the hot-cache case.

Between that and the 6-core bulldozer[3] I upgraded to last year, I'm 
quite happy with portage's current performance, even doing routine 
rebuilds of the perhaps half of kde I have installed, plus some other 
packages with @live-rebuild.[2]

The SSD doesn't have to be particularly big, either, but fast (if you're 
running SATA3 to use it) is nice.  I figured ~64 gig usage here, tho I 
wanted some overprovisioning, so thought I'd do 128 gig or so.  I ended 
up with 256 gig, only ~60%  partitioned (130-some gig) even with 
duplicate backup partitions for everything.  System, tree, /home, etc, on 
SSD, but still doing spinning rust for my media partitions and third-copy 
(second backup) partitions, on demonstrated reliable here reiserfs, while 
the SSD is all still-development-so-keep-your-backups-updated btrfs.

---
[1] I'm running ntp and the initial ntp-client connection and time sync 
takes ~12 seconds a lot of the time, just over the initial 10 seconds 
down, 50 to go, trigger on openrc's 1-minute timeout.

[2] 131 packages in @live-rebuild, with kde-live-branch, currently 
4.10.49.9999, being low 120-some, plus choice bits of of X/mesa/drivers 
and a few other packages including openrc, btrfs-progs and pan.  The 
@live-rebuild typically takes ~20 minutes with ccache, a good portion of 
which is kdelibs, so the whole update including the sync and change/git-
logs check for interesting stuff, @world update, @live-rebuild, etc-
update and revdep-rebuild/depclean, runs ~1 hour, often less, sometimes  
more if there's a new mozilla-overlay firefox build or something in 
addition to the kde-libs long-build update.

[3] Also relevant, 16 gigs RAM, PORTAGETMPDIR on tmpfs.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Packages up for grabs

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1014 bytes --]

Am Sonntag, 16. Juni 2013, 21:33:53 schrieb Duncan:
> Tom Wijsman posted on Sun, 16 Jun 2013 20:23:24 +0200 as excerpted:
> > On Sun, 16 Jun 2013 19:21:38 +0200 Pacho Ramos <pacho@gentoo.org> wrote:
> >> El dom, 16-06-2013 a las 10:09 -0700, Brian Dolbec escribió:
> >> [...]
> >> 
> >> > Thank you for considering helping.  I have stayed away form the
> >> > intricate details of package management in the past, but I also do
> >> > not like how long portage is taking now for dep calculations.
> >> 
> >> And, cannot that efforts be put in enhancing portage instead?
> > 
> > To make you see the problems and decisions, I'm going to elaborate a
> > little and would like you to ask yourself some questions.
> > 
> > Is it possible to reasonable enhance the Portage code to improve dep
> > calculations in a reasonable amount of time?
> 
> TL;DR: SSDs help. =:^)
> 

Some more RAM too.

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


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

Re: [gentoo-dev] Packages up for grabs

[Ciaran McCreesh]

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

On Sun, 16 Jun 2013 20:23:24 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:
> Is it possible to reasonable enhance the Portage code to improve dep
> calculations in a reasonable amount of time?

Before you start looking at speed, you should make it do full, correct
dependency enforcing. Get it right first, and fast later.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Packages up for grabs

[Tim Harder]

On 2013-06-16 06:55, Brian Dolbec wrote:
> > > Due ferringb retirement the following packages are up for grabs:
> > > dev-python/snakeoil
> > > sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained
> > > and neither has eapi5 support)

> I'll take pkgcore (if somehow we can get eapi 5 finished.)

> I'll take snakeoil.  I'm adding some of it's libs into catalyst

I can help with pkgcore, pkgcore-checks, and snakeoil as well. I've got
most of the EAPI 5 resolver work done in a local fork and have been
fixing other bugs I've found along the way.

Tim

Re: [gentoo-dev] Re: Packages up for grabs

[Tom Wijsman]

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

On Sun, 16 Jun 2013 19:33:53 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> TL;DR: SSDs help. =:^)

TL;DR: SSDs help, but they don't solve the underlying problem. =:-(

I have one; it's great to help make my boot short, but it isn't really
a great improvement for the Portage tree. Better I/O isn't a solution
to computational complexity; it doesn't deal with the CPU bottleneck.

Sadly, an improvement to the CPU as good as the switch from HDD to SSD,
I'm yet to see such a hardware improvement. Maybe if we stack the
transistors into the third dimension, something Intel was working on.

> Quite apart from the theory and question of making the existing code 
> faster vs. a new from-scratch implementation, there's the practical 
> question of what options one can actually use to deal with the
> problem /now/.

Don't rush it: Do you know the problem well? Does the solution
properly deal with it? Is it still usable some months / years from now?

> FWIW, one solution (particularly for folks who don't claim to have 
> reasonable coding skills and thus have limited options in that
> regard) is to throw hardware at the problem.

Improvements in algorithmic complexity (exponential) are much bigger
than improvements you can achieve by buying new hardware (linear).

> I recently upgraded my main system to SDD. ... SNIP ... Between that
> and the 6-core bulldozer[3] I upgraded to last year, I'm quite happy
> with portage's current performance, ... SNIP ...

Ironically, you don't even fully use the CPU, but only one core of it;
I'm glad you have a 6-core processor, but to Portage it is a 1-core
during dependency tree calculation.

Portage becomes slower at a faster rate than your hardware get faster;
this will continue to be that way until you make Portage benefit of
it, or failing that you would need to come up with an alternative PM.

I didn't get my short boot from upgrading hardware alone; quite the
opposite, it was rather the results of the efforts spent on it.

> ---
> [1] I'm running ntp and the initial ntp-client connection and time
> sync takes ~12 seconds a lot of the time, just over the initial 10
> seconds down, 50 to go, trigger on openrc's 1-minute timeout.

Why do you make your boot wait for NTP to sync its time?

How could hardware make this time sync go any faster?

> [2] ... SNIP ... runs ~1 hour ... SNIP ...

Sounds great, but the same thing could run in much less time. I have
worse hardware, and it doesn't take much longer than yours do; so, I
don't really see the benefits new hardware bring to the table. And that
HDD to SSD change, that's really a once in a lifetime flood.

> [3] Also relevant, 16 gigs RAM, PORTAGETMPDIR on tmpfs.

Sounds all cool, but think about your CPU again; saturate it...

Building the Linux kernel with `make -j32 -l8` versus `make -j8` is a
huge difference; most people follow the latter instructions, without
really thinking through what actually happens with the underlying data.
The former queues up jobs for your processor; so the moment a job is
done a new job will be ready, so, you don't need to wait on the disk.

Something completely different; look at the history of data mining,
today's algorithms are much much faster than those of years ago.

Just to point out that different implementations and configurations have
much more power in cutting time than the typical hardware change does.

Though, this was pretty much OT; we're talking about the dependency tree
calculation, not about emerging which is rather a result of building
(eg. your compiler) than it has anything to do with the package manager.

PS: A take home thought: What if the hardware designers decided to not
R&D storage, then we wouldn't have a SSD; same story, different level.
Another level higher; we have physics, maybe CERN can improve hardware?
But when will that happen? Can we rely and wait on that to happen?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Re: Packages up for grabs

[Ciaran McCreesh]

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

On Sun, 16 Jun 2013 23:24:27 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:
> I have one; it's great to help make my boot short, but it isn't really
> a great improvement for the Portage tree. Better I/O isn't a solution
> to computational complexity; it doesn't deal with the CPU bottleneck.

If the CPU is your bottleneck, Python won't help you. Python's threads
are fine for making IO easier, but the GIL prevents them from being of
any use for CPU intensive calculations.

Having said that, the CPU isn't your bottleneck.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Packages up for grabs

[Zac Medico]

On 06/16/2013 11:23 AM, Tom Wijsman wrote:
> Ignoring that call graph, you could look at what has recently been
> introduced to increase the amount of time needed to calculate the
> dependency graph; you don't have to look far.
> 
> http://blogs.gentoo.org/mgorny/2013/05/27/the-pointless-art-of-subslots/
> 
> While I don't want point out the contents of that blog post, the title
> is relevant; implementing features like subslots on an algorithm that
> was not written with subslots in mind introduces a lot of inefficiency.

It's actually not bad, since all of the subslot rebuilds are triggered
in a single backtracking run. Anyway, I welcome having people work on
competing package managers, trying to do all of this stuff more
efficiently. :-)

> And it's not just subslots, newer features keep getting added to the
> dependency graph calculation and it gets slower and slower over time.
> It feels like revdep-rebuild moved into the dependency calculation!

I guess the main things that make it slower than it has been
historically would be things like --autounmask, --backtrack,
--complete-graph-if-new-use and --complete-graph-if-new-ver. Note that
you can use EMERGE_DEFAULT_OPTS to disable these things if you would
prefer to live without them. You might use something like --backtrack=2
if you want it to bail out early for all but the simplest backtracking
cases. Use --ignore-built-slot-operator-deps=y if you want to disable
all rebuilds involving subslots and slot-operators.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Packages up for grabs

[Tom Wijsman]

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

On Sun, 16 Jun 2013 22:38:56 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Sun, 16 Jun 2013 23:24:27 +0200
> Tom Wijsman <TomWij@gentoo.org> wrote:
> > I have one; it's great to help make my boot short, but it isn't
> > really a great improvement for the Portage tree. Better I/O isn't a
> > solution to computational complexity; it doesn't deal with the CPU
> > bottleneck.
> 
> If the CPU is your bottleneck, Python won't help you. Python's threads
> are fine for making IO easier, but the GIL prevents them from being of
> any use for CPU intensive calculations.
> 
> Having said that, the CPU isn't your bottleneck.

That's assuming you would go threaded, but you can also aim for lower
algorithmic complexities; the complexity makes the CPU the bottleneck.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] Packages up for grabs

[Ciaran McCreesh]

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

On Sun, 16 Jun 2013 14:57:32 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> It's actually not bad, since all of the subslot rebuilds are triggered
> in a single backtracking run. Anyway, I welcome having people work on
> competing package managers, trying to do all of this stuff more
> efficiently. :-)

I'm starting to think we're all doing this wrong by going for a naive
"single choice then backtrack" model, fully consistent or otherwise.
Perhaps we're going to have to bite the bullet and go for stronger
propagation models and one of the many better alternatives to
backtracking...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Packages up for grabs

[Ciaran McCreesh]

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

On Mon, 17 Jun 2013 00:07:57 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:
> That's assuming you would go threaded, but you can also aim for lower
> algorithmic complexities; the complexity makes the CPU the bottleneck.

Dependency solving is NP-hard in theory and better than quadratic in
practice. The resolution algorithms also aren't the problem in terms of
runtime (and still won't be if we started using more sophisticated
algorithms for better decision making). The problem is simply that the
model is large and messy, and the problem being solved has all kinds
of awful corner cases that have to be considered.

(As one example, every user has somewhere between a hundred and a
thousand packages installed, each of which depends directly or
indirectly upon every other package in this collection.)

There are certainly improvements to be made, both in terms of
efficiency and correctness, but if you're looking for a big leap
forward then the most useful thing we could do is reduce or eliminate
some of the requirements that make dependency resolution such a fiddly
(not hard) problem.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Packages up for grabs

[Rafael Goncalves Martins]

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

On Sun, Jun 16, 2013 at 6:49 AM, Pacho Ramos <pacho@gentoo.org> wrote:

> Due ferringb retirement the following packages are up for grabs:
> ...
> dev-util/diffball
>

I'll take it.

-- 
Rafael Goncalves Martins
Gentoo Linux developer
http://rafaelmartins.eng.br/

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

Re: [gentoo-dev] Packages up for grabs

[Sergey Popov]

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

16.06.2013 13:49, Pacho Ramos пишет:
> Due ferringb retirement the following packages are up for grabs:>
>
> dev-util/bsdiff

I will take care of it...

-- 
Best regards, Sergey Popov
Gentoo developer
Gentoo Desktop-effects project lead
Gentoo Qt project lead


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

Re: [gentoo-dev] Packages up for grabs

[Brian Harring]

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

It's low maintenance; only thing needed is either to rebase to my
libtransform work, or add proper xz support.

Either way, any questions, let me know.
~brian


On Mon, Jun 17, 2013 at 1:16 AM, Sergey Popov <pinkbyte@gentoo.org> wrote:

> 16.06.2013 13:49, Pacho Ramos пишет:
> > Due ferringb retirement the following packages are up for grabs:>
> >
> > dev-util/bsdiff
>
> I will take care of it...
>
> --
> Best regards, Sergey Popov
> Gentoo developer
> Gentoo Desktop-effects project lead
> Gentoo Qt project lead
>
>

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

Re: [gentoo-dev] Packages up for grabs

[vivo75]

On 06/16/13 11:49, Pacho Ramos wrote:
> Due ferringb retirement the following packages are up for grabs:
> app-arch/tarsync
* app-arch/tarsync
     Available versions:  (~)0.2.1 (~)0.2.1-r1
     Homepage:            http://gentooexperimental.org/~ferringb/tarsync/
     Description:         Delta compression suite for using/generating
binary patches

^^^ also this may need a new maintainer, it already need a new homepage
(404)

> dev-python/snakeoil
> dev-util/bsdiff
> dev-util/diffball
> sys-apps/pkgcore (likely to be treecleaned as it's no longer maintained
> and neither has eapi5 support)
>
>
>

[gentoo-dev] Re: Packages up for grabs

[Duncan]

Tom Wijsman posted on Sun, 16 Jun 2013 23:24:27 +0200 as excerpted:

> On Sun, 16 Jun 2013 19:33:53 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> TL;DR: SSDs help. =:^)
> 
> TL;DR: SSDs help, but they don't solve the underlying problem. =:-(

Well, there's the long-term fix to the underlying problem, and there's 
coping strategies to help with where things are at now.  I was simply 
saying that an SSD helps a LOT in dealing with the inefficiencies of the 
current code.  See the "quite apart... practical question of ... dealing 
with the problem /now/" bit quoted below.

> I have one; it's great to help make my boot short, but it isn't really a
> great improvement for the Portage tree. Better I/O isn't a solution to
> computational complexity; it doesn't deal with the CPU bottleneck.

But here, agreed with ciaranm, the cpu's not the bottleneck, at least not 
from cold-cache.  It doesn't even up the cpu clocking from minimum as 
it's mostly filesystem access.  Once the cache is warm, then yes, it ups 
the CPU speed and I see the single-core behavior you mention, but cold-
cache, no way; it's I/O bound.

And with an ssd, the portage tree update (the syncs both of gentoo and 
the overlays) went from a /crawling/ console scroll, to scrolling so fast 
I can't read it.

>> Quite apart from the theory and question of making the existing code
>> faster vs. a new from-scratch implementation, there's the practical
>> question of what options one can actually use to deal with the problem
>> /now/.
> 
> Don't rush it: Do you know the problem well? Does the solution properly
> deal with it? Is it still usable some months / years from now?

Not necessarily.  But first we must /get/ to some months / years from 
now, and that's a lot easier if the best is made of the current 
situation, while a long term fix is being developed.

>> FWIW, one solution (particularly for folks who don't claim to have
>> reasonable coding skills and thus have limited options in that regard)
>> is to throw hardware at the problem.
> 
> Improvements in algorithmic complexity (exponential) are much bigger
> than improvements you can achieve by buying new hardware (linear).

Same song different verse.  Fixing the algorithmic complexity is fine and 
certainly a good idea longer term, but it's not something I can use at my 
next update.  Throwing hardware at the problem is usable now.

>> ---
>> [1] I'm running ntp and the initial ntp-client connection and time sync
>> takes ~12 seconds a lot of the time, just over the initial 10 seconds
>> down, 50 to go, trigger on openrc's 1-minute timeout.
> 
> Why do you make your boot wait for NTP to sync its time?

Well, ntpd is waiting for the initial step so it doesn't have to slew so 
hard for so long if the clock's multiple seconds off.

And ntpd is in my default runlevel, with a few local service tasks that 
are after * and need a good clock time anyway, so...

> How could hardware make this time sync go any faster?

Which is what I said, that as a practical matter, my boot didn't speed up 
much /because/ I'm running (and waiting for) the ntp-client time-
stepper.  Thus, I'd not /expect/ a hardware update (unless it's to a more 
direct net connection) to help much.

>> [2] ... SNIP ... runs ~1 hour ... SNIP ...
> 
> Sounds great, but the same thing could run in much less time. I have
> worse hardware, and it doesn't take much longer than yours do; so, I
> don't really see the benefits new hardware bring to the table. And that
> HDD to SSD change, that's really a once in a lifetime flood.

I expect I'm more particular than most about checking changelogs.  I 
certainly don't read them all, but if there's a revision-bump for 
instance, I like to see what the gentoo devs considered important enough 
to do a revision bump.  And I religiously check portage logs, selecting 
mentioned bug numbers probably about half the time, which pops up a menu 
with a gentoo bug search on the number, from which I check the bug 
details and sometimes the actual git commit code.  For all my overlays I 
check the git whatchanged logs, and I have a helper script that lets me 
fetch and then check git whatchanged for a number of my live packages, 
including openrc (where I switched to live-git precisely /because/ I was 
following it closely enough to find the git whatchanged logs useful, both 
for general information and for troubleshooting when something went wrong 
-- release versions simply didn't have enough resolution, too many things 
changing in each openrc release to easily track down problems and file 
bugs as appropriate), as well.

And you're probably not rebuilding well over a hundred live-packages 
(thank $DEITY and the devs in question for ccache!) at every update, in 
addition to the usual (deep) @world version-bump and newuse updates, are 
you?

Of course maybe you are, but I did specify that, and I didn't see 
anything in your comments indicating anything like an apples to apples 
comparision.

>> [3] Also relevant, 16 gigs RAM, PORTAGETMPDIR on tmpfs.
> 
> Sounds all cool, but think about your CPU again; saturate it...
> 
> Building the Linux kernel with `make -j32 -l8` versus `make -j8` is a
> huge difference; most people follow the latter instructions, without
> really thinking through what actually happens with the underlying data.
> The former queues up jobs for your processor; so the moment a job is
> done a new job will be ready, so, you don't need to wait on the disk.

Truth is, I used to run a plain make -j (no number and no -l at all) on 
my kernel builds, just to watch the system stress and then so elegantly 
recover.  It's an amazing thing to watch, this Linux kernel thing and how 
it deals with cpu oversaturation.  =:^)

But I suppose I've gotten more conservative in my old age. =:^P  
Needlessly oversaturating the CPU (and RAM) only slows things down and 
forces cache dump and swappage.  These days according to my kernel-build-
script configuration I only run -j24, which seems a reasonable balance as 
it keeps the CPUs busy but stays safely enough within a few gigs of RAM 
so I don't dump-cache or hit swap.  Timing a kernel build from make clean 
suggests it's the same sub-seconds range from -j10 or so, up to (from 
memory) -j50 or so, after which build time starts to go up, not down.

> Something completely different; look at the history of data mining,
> today's algorithms are much much faster than those of years ago.
> 
> Just to point out that different implementations and configurations have
> much more power in cutting time than the typical hardware change does.

I agree and am not arguing that.  All I'm saying is that there are 
measures that a sysadmin can take today to at least help work around the 
problem, today, while all those faster algorithms are being developed, 
implemented, tested and deployed. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Packages up for grabs

[Tom Wijsman]

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

On Mon, 24 Jun 2013 15:27:19 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> > I have one; it's great to help make my boot short, but it isn't
> > really a great improvement for the Portage tree. Better I/O isn't a
> > solution to computational complexity; it doesn't deal with the CPU
> > bottleneck.
> 
> But here, agreed with ciaranm, the cpu's not the bottleneck, at least
> not from cold-cache.  It doesn't even up the cpu clocking from
> minimum as it's mostly filesystem access.  Once the cache is warm,
> then yes, it ups the CPU speed and I see the single-core behavior you
> mention, but cold- cache, no way; it's I/O bound.
> 
> And with an ssd, the portage tree update (the syncs both of gentoo
> and the overlays) went from a /crawling/ console scroll, to scrolling
> so fast I can't read it.

We're not talking about the Portage tree update, but about the
dependency tree generation, which relies much more on the CPU than I/O.
A lot of loops inside loops inside loops, comparisons and more data
structure magic is going on; if this were optimized to be of a lower
complexity or be processed by multiple cores, this would speed up a lot.

Take a look at the profiler image and try to get a quick understanding
of the code; after following a few function calls, it will become clear.

Granted, I/O is still a part of the problem which is why I think caches
would help too; but from what I see the time / space complexity is just
too high, so you don't even have to deem this as CPU or I/O bound...

> >> Quite apart from the theory and question of making the existing
> >> code faster vs. a new from-scratch implementation, there's the
> >> practical question of what options one can actually use to deal
> >> with the problem /now/.
> > 
> > Don't rush it: Do you know the problem well? Does the solution
> > properly deal with it? Is it still usable some months / years from
> > now?
> 
> Not necessarily.  But first we must /get/ to some months / years from 
> now, and that's a lot easier if the best is made of the current 
> situation, while a long term fix is being developed.

True, we have make and use the most out of Portage as long as possible.

> >> FWIW, one solution (particularly for folks who don't claim to have
> >> reasonable coding skills and thus have limited options in that
> >> regard) is to throw hardware at the problem.
> > 
> > Improvements in algorithmic complexity (exponential) are much bigger
> > than improvements you can achieve by buying new hardware (linear).
> 
> Same song different verse.  Fixing the algorithmic complexity is fine
> and certainly a good idea longer term, but it's not something I can
> use at my next update.  Throwing hardware at the problem is usable
> now.

If you have the money; yes, that's an option.

Though I think a lot of people see Linux as something you don't need to
throw a lot of money at; it should run on low end systems, and that's
kind of the type of users we shouldn't just neglect going forward.

> >> [2] ... SNIP ... runs ~1 hour ... SNIP ...
> > 
> > Sounds great, but the same thing could run in much less time. I have
> > worse hardware, and it doesn't take much longer than yours do; so, I
> > don't really see the benefits new hardware bring to the table. And
> > that HDD to SSD change, that's really a once in a lifetime flood.
> 
> I expect I'm more particular than most about checking changelogs.  I 
> certainly don't read them all, but if there's a revision-bump for 
> instance, I like to see what the gentoo devs considered important
> enough to do a revision bump.  And I religiously check portage logs,
> selecting mentioned bug numbers probably about half the time, which
> pops up a menu with a gentoo bug search on the number, from which I
> check the bug details and sometimes the actual git commit code.  For
> all my overlays I check the git whatchanged logs, and I have a helper
> script that lets me fetch and then check git whatchanged for a number
> of my live packages, including openrc (where I switched to live-git
> precisely /because/ I was following it closely enough to find the git
> whatchanged logs useful, both for general information and for
> troubleshooting when something went wrong -- release versions simply
> didn't have enough resolution, too many things changing in each
> openrc release to easily track down problems and file bugs as
> appropriate), as well.

I stick more to releases and checking the changes for things where I
want to know the changes for; for the others, they either don't matter
or they shouldn't really hurt as a surprise. If there's something that
would really surprise me then I'd expect some news on that.

> And you're probably not rebuilding well over a hundred live-packages 
> (thank $DEITY and the devs in question for ccache!) at every update,
> in addition to the usual (deep) @world version-bump and newuse
> updates, are you?

Developers rebuild those to see upcoming breakage.

Apart from that, I don't use many -9999 as to not go too unstable.

> >> [3] Also relevant, 16 gigs RAM, PORTAGETMPDIR on tmpfs.
> > 
> > Sounds all cool, but think about your CPU again; saturate it...
> > 
> > Building the Linux kernel with `make -j32 -l8` versus `make -j8` is
> > a huge difference; most people follow the latter instructions,
> > without really thinking through what actually happens with the
> > underlying data. The former queues up jobs for your processor; so
> > the moment a job is done a new job will be ready, so, you don't
> > need to wait on the disk.
> 
> Truth is, I used to run a plain make -j (no number and no -l at all)
> on my kernel builds, just to watch the system stress and then so
> elegantly recover.  It's an amazing thing to watch, this Linux kernel
> thing and how it deals with cpu oversaturation.  =:^)

If you have the memory to pull it off, which involves money again.

> But I suppose I've gotten more conservative in my old age. =:^P  

> Needlessly oversaturating the CPU (and RAM) only slows things down
> and forces cache dump and swappage.

The trick is to set it a bit before the point of oversaturating; low
enough so most packages don't oversaturize, it could be put more
precisely for every package but that time is better spent elsewhere

> > Something completely different; look at the history of data mining,
> > today's algorithms are much much faster than those of years ago.
> > 
> > Just to point out that different implementations and configurations
> > have much more power in cutting time than the typical hardware
> > change does.
> 
> I agree and am not arguing that.  All I'm saying is that there are 
> measures that a sysadmin can take today to at least help work around
> the problem, today, while all those faster algorithms are being
> developed, implemented, tested and deployed. =:^)

Not everyone is a sysadmin with a server; I'm just a student running a
laptop bought some years ago, and I'm kind of the type that doesn't
replace it while it still works fine otherwise. Maybe when I graduate...

I think we can both agree a faster system does a better job at it; but
they won't deal with crux of the problem, the algorithmic complexity.

Dealing with both, as you mention, is the real deal.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[gentoo-dev] Re: Packages up for grabs

[Duncan]

Tom Wijsman posted on Tue, 25 Jun 2013 01:18:07 +0200 as excerpted:

> On Mon, 24 Jun 2013 15:27:19 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Throwing hardware at the problem is usable now.
> 
> If you have the money; yes, that's an option.
> 
> Though I think a lot of people see Linux as something you don't need to
> throw a lot of money at; it should run on low end systems, and that's
> kind of the type of users we shouldn't just neglect going forward.

Well, let's be honest.  Anyone building packages on gentoo isn't likely 
to be doing it on a truly low-end system.  For general linux, yes, 
agreed, but that's what puppy linux and etc are for.  True there's the 
masochistic types that build natively on embedded or a decade plus old 
(and mid-level or lower then!) systems, but most folks with that sort of 
system either have a reasonable build server to build it on, or use a pre-
built binary distro.  And the masochistic types... well, if it takes an 
hour to get the prompt in an emerge --ask and another day or two to 
actually complete, that's simply more masochism for them to revel in. =:^P

Tho you /do/ have a point.

OTOH, some of us used to do MS or Apple or whatever and split our money 
between hardware and software.  Now we pay less for the software, but 
that doesn't mean we /spend/ significantly less on the machines; now it's 
mostly/all hardware.

I've often wondered why the hardware folks aren't all over Linux, given 
the more money available for hardware it can mean, and certainly /does/ 
mean here.

>> Truth is, I used to run a plain make -j (no number and no -l at all) on
>> my kernel builds, just to watch the system stress and then so elegantly
>> recover.  It's an amazing thing to watch, this Linux kernel thing and
>> how it deals with cpu oversaturation.  =:^)
> 
> If you have the memory to pull it off, which involves money again.

What was interesting was doing it without the (real) memory -- letting it 
go into swap and just queue up hundreds and hundreds of jobs as the make 
continued to generate more and more of them, faster than they could even 
fully initialize, particularly since they were packing into swap before 
they even had that chance.

And then with 500-600 jobs or more (custom kernel build, not all-yes/all-
mod config, or it'd likely have been 1200...) stacked up and gigs into 
swap, watch the system finally start to slowly unwind the tangle.  
Obviously the system wasn't usable for anything else during the worst of 
it, but it still rather fascinates me that the kernel scheduling and code 
quality in general is such that it can successfully do that and unwind it 
all, without crashing or whatever.  And the kernel build is one of the 
few projects that's /that/ incredibly parallel, without requiring /too/ 
much memory per individual job, to do it in the first place.

Actually, that's probably the flip side of my getting more conservative.  
The reason I /can/ get more conservative now is that I've enough cores 
and memory that it's actually reasonably practical to do so.  When you're 
always dumping cache and/or swapping anyway, no big deal to do so a bit 
more.  When you have a system big enough to avoid that while still 
getting reasonably large chunks of real work done, and you're no longer 
used to the compromise of /having/ to dump cache, suddenly you're a lot 
more sensitive to doing so at all!

>> Needlessly oversaturating the CPU (and RAM) only slows things down and
>> forces cache dump and swappage.
> 
> The trick is to set it a bit before the point of oversaturating; low
> enough so most packages don't oversaturize, it could be put more
> precisely for every package but that time is better spent elsewhere

Indeed. =:^)

> Not everyone is a sysadmin with a server; I'm just a student running a
> laptop bought some years ago, and I'm kind of the type that doesn't
> replace it while it still works fine otherwise. Maybe when I graduate...

Actually, I use "sysadmin" in the literal sense, the person taking the 
practical responsibility for deciding what goes on a system, when/if/what 
to upgrade (or not), with particular emphasis on RESPONSIBILITY, both for 
security and both keeping the system running and getting it back running 
again when it breaks.  Nothing in that says it has to be commercial, or 
part of some huge farm of systems.  For me, the person taking 
responsibility (or failing to take it) for updating that third-generation 
hand-me-down castoff system is as much of a sysadmin for that system, as 
the guy/gal with 100 or 1000 systems (s)he's responsible for.

My perspective has always been that if all those folks running virus 
infested junk out there actually took the sysadmin responsibility for the 
systems they're running seriously, the virus/malware issue would cease to 
be an issue at all.

Meanwhile, I'll admit my last system was rather better than average when 
I first set it up (dual socket original 3-digit Opteron, that whole 
spending all the money I used to spend on software, on hardware, now, 
thing, my first 64-bit machine and my first and likely last real dual-
CPU... socket); in fact, compared to peers of its time it may well be the 
best system I'll ever own, but that thing lasted me 8+ years.  My goal 
was a decade but I didn't make it as the caps on the mobo were bulging 
and finally popping by the time I got rid of it.  (The last month or so I 
ran it, last summer here in Phoenix, it'd run if I kept it cold enough, 
basically 15C or lower, so I was dressing up in a winter jacket with long 
underwear and a knit hat on, with the AC running to keep it cold enough 
to run the computer inside, while outside it was 40C+!)

But OTOH, that was originally a $400 mobo alone, for quite some time 
worth probably 2-3 grand total as I kept upgrading bits and pieces of it 
as I had the money.  But FTR, I /am/ quite happy with the 6-core 
Bulldozer-1 that replaced it, when I finally really had no other choice.  
And the replacement was *MUCH* cheaper!

But anyway, yeah, I do know a bit about running old hardware, myself, and 
know how to make those dollars strreeettcchh myself. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Packages up for grabs

[Harvey]

If your going to take on spacefm, it would be great if you also handled
udevil since they are both from the same upstream repo and work tightly
together..

I'm an avid user of both, and since upstream is no longer maintained on
either of these their futures are unclear..

H
On 11/27/2014 04:51 AM, Daniel Campbell wrote:
> On 11/26/2014 03:15 AM, Yixun Lan wrote:
>> On 21:08 Sun 23 Nov     , Daniel Campbell wrote:
>>>
>>> I'd like to take x11-misc/spacefm if a developer is willing to allow
>>> me to proxy-maint until I become a developer.
>>
>> update metadata.xml, using your email found in bugzie.
>> and current no bug opened, thanks
>>
>> btw, any particular reason why should we keep so many stable versions?
>> probably start doing by cleaning old versions ;-)
>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v2
>>>
>>> iQEcBAEBAgAGBQJUcqEYAAoJEJUrb08JgYgHJ0IIAK+tguKdL+JxdjKLySOSJaTU
>>> kiU1z2rBqUfPzs8VI3V8JAAL9dbSJel4h3/JdoZFpidC9jED63l5STmGXi6dp63O
>>> 9CKqNQRt4AELfOUpQzxoD4HNHVxaA9hkiiJXgAoF9HIfKBEqczPCBKGnJb5s1WB5
>>> 8eQkn6t6DZMZeRV/dE6pw1RgTj1eHowu2es67V7+bHMiy2ylz5/4ru0dx+1UHvU1
>>> UeBBcB1IesAVxVsfpBLJoi+aZA9CO9EAriaGogzTXQPP5odr4bgIf5acxOPKGxt0
>>> iz62j/XgG3jTExqkP5rNaTVnO9ZZol8XPcLiAIZTEl79XU0ZOcy5LDUsJNY+9cI=
>>> =stIL
>>> -----END PGP SIGNATURE-----
>>
> 
> I'd do that myself, if I was a dev. :P I'd need a developer to help me
> proxy maintain it. I've been meaning to become a developer, but my
> ebuild quiz is out of date and I have a lot of IRL things going on right
> now so I can't really work toward it right now. spacefm's developer is
> on hiatus, so it'd be a good low-traffic package for me to maintain and
> take the load (if only mental) off of other developers.
> 
> 

Re: [gentoo-dev] Re: Packages up for grabs

[Daniel Campbell]

On 12/03/2014 10:34 AM, Harvey wrote:
> If your going to take on spacefm, it would be great if you also handled
> udevil since they are both from the same upstream repo and work tightly
> together..
> 
> I'm an avid user of both, and since upstream is no longer maintained on
> either of these their futures are unclear..
> 
> H
> On 11/27/2014 04:51 AM, Daniel Campbell wrote:
>> On 11/26/2014 03:15 AM, Yixun Lan wrote:
>>> On 21:08 Sun 23 Nov     , Daniel Campbell wrote:
>>>>
>>>> I'd like to take x11-misc/spacefm if a developer is willing to allow
>>>> me to proxy-maint until I become a developer.
>>>
>>> update metadata.xml, using your email found in bugzie.
>>> and current no bug opened, thanks
>>>
>>> btw, any particular reason why should we keep so many stable versions?
>>> probably start doing by cleaning old versions ;-)
>>>
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v2
>>>>
>>>> iQEcBAEBAgAGBQJUcqEYAAoJEJUrb08JgYgHJ0IIAK+tguKdL+JxdjKLySOSJaTU
>>>> kiU1z2rBqUfPzs8VI3V8JAAL9dbSJel4h3/JdoZFpidC9jED63l5STmGXi6dp63O
>>>> 9CKqNQRt4AELfOUpQzxoD4HNHVxaA9hkiiJXgAoF9HIfKBEqczPCBKGnJb5s1WB5
>>>> 8eQkn6t6DZMZeRV/dE6pw1RgTj1eHowu2es67V7+bHMiy2ylz5/4ru0dx+1UHvU1
>>>> UeBBcB1IesAVxVsfpBLJoi+aZA9CO9EAriaGogzTXQPP5odr4bgIf5acxOPKGxt0
>>>> iz62j/XgG3jTExqkP5rNaTVnO9ZZol8XPcLiAIZTEl79XU0ZOcy5LDUsJNY+9cI=
>>>> =stIL
>>>> -----END PGP SIGNATURE-----
>>>
>>
>> I'd do that myself, if I was a dev. :P I'd need a developer to help me
>> proxy maintain it. I've been meaning to become a developer, but my
>> ebuild quiz is out of date and I have a lot of IRL things going on right
>> now so I can't really work toward it right now. spacefm's developer is
>> on hiatus, so it'd be a good low-traffic package for me to maintain and
>> take the load (if only mental) off of other developers.
>>
>>
> 
> 
> 
Sure, I'm down to proxy-maintain udevil as well. I use it with spacefm
to mount things.

[gentoo-dev] Re: Packages up for grabs

[Duncan]

Andrew Savchenko posted on Thu, 08 Jan 2015 04:29:42 +0300 as excerpted:

> On Wed, 07 Jan 2015 15:06:08 +0100 Pacho Ramos wrote:

>> Done, this packages are now up for grabs:
> 
>> net-proxy/privoxy
> 
> I'll take them if there are no other people interested. If you are —
> feel free to add yourself to maintainers :)

Please take a look at privoxy right away, as the herd cleanup appears to 
have removed a wrong version (stable -r2, leaving unstable -r1) there.

Bug #535994


-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Packages up for grabs

[Duncan]

Duncan posted on Thu, 08 Jan 2015 09:28:02 +0000 as excerpted:

> Andrew Savchenko posted on Thu, 08 Jan 2015 04:29:42 +0300 as excerpted:
> 
>> On Wed, 07 Jan 2015 15:06:08 +0100 Pacho Ramos wrote:
> 
>>> Done, this packages are now up for grabs:
>> 
>>> net-proxy/privoxy
>> 
>> I'll take them if there are no other people interested. If you are —
>> feel free to add yourself to maintainers :)
> 
> Please take a look at privoxy right away, as the herd cleanup appears to
> have removed a wrong version (stable -r2, leaving unstable -r1) there.
> 
> Bug #535994

And fixed! =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Re: Packages up for grabs

[Justin Bronder]

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

On 02/06/16 10:42 -0500, james wrote:
> On 06/01/2016 06:20 PM, Justin Bronder wrote:
>  > Due to a lack of time and the fact I don't use any of these packages 
>  > anymore, they are all up for grabs.
>  >
>  >      - media-gfx/openmesh [no project]
>  >      - sys-cluster/ganglia [cluster]
>  >      - sys-cluster/ganglia-web [cluster]
>  >      - sys-cluster/torque [cluster]
>  >      - sys-cluster/munge [cluster] dependency of sys-cluster/torque
>  >      - sys-cluster/mpe2 [cluster]
>  >
>  > Also, if there's anyone out there using the science overlay and empi 
>  > who's feeling motivated, that work still needs a champion to get it
>  > into the main tree.  If not, I'll probably drop it in a few months
>  > and open openmpi and mpich2 to project maintenance as well.  I
>  > haven't been involved in HPC for over a decade now, it's time to
>  > pass the torch.
> 
> 
> Hello Justin,
> 
> I've been working on cluster ebuilds for a while (Apache Mesos, spark, 
> etc). I'm willing to proxy maintain these except torque. Assuming there 
> are no users of torque on gentoo (bgo seems inactive...it's dead; how 
> would I know?).

Looks like Ian got torque already, but he may appreciate some help.  For the
other packages, I'm more then happy to proxy maintain them for you.  Just send
any patches my way (including a first one to add you as a maintainer :)

> 
> My focus is building gentoo centric HPC clusters that do not require 
> systemd as a component, with deployment emphasis on bare-metal and 
> minimized gentoo systems where only the codes absolutely necessary to 
> support the necessary frameworks are dynamically installed. Many of the 
> 'retro' tools in this cluster space, are quite useful for my work.
> 
> The guidexml page for empi is old, so where do I read up on it's 
> projected usage (just not familiar with that empi project/package).

The empi documentation did get moved over to the wiki [1].  However, it's pretty
much the exact same thing you're seeing in the guidexml page.  I know there were
some HPC sites using it in the past, but I haven't heard from anyone lately.
That could mean no one is using it, or that everything is working as expected.

1.  https://wiki.gentoo.org/wiki/Empi

-- 
Justin Bronder

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

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 06/03/2016 12:02 PM, Justin Bronder wrote:
> On 02/06/16 10:42 -0500, james wrote:
>> On 06/01/2016 06:20 PM, Justin Bronder wrote:
>>   > Due to a lack of time and the fact I don't use any of these packages
>>   > anymore, they are all up for grabs.
>>   >
>>   >      - media-gfx/openmesh [no project]
>>   >      - sys-cluster/ganglia [cluster]
>>   >      - sys-cluster/ganglia-web [cluster]
>>   >      - sys-cluster/torque [cluster]
>>   >      - sys-cluster/munge [cluster] dependency of sys-cluster/torque
>>   >      - sys-cluster/mpe2 [cluster]
>>   >
>>   > Also, if there's anyone out there using the science overlay and empi
>>   > who's feeling motivated, that work still needs a champion to get it
>>   > into the main tree.  If not, I'll probably drop it in a few months
>>   > and open openmpi and mpich2 to project maintenance as well.  I
>>   > haven't been involved in HPC for over a decade now, it's time to
>>   > pass the torch.
>>
>>
>> Hello Justin,
>>
>> I've been working on cluster ebuilds for a while (Apache Mesos, spark,
>> etc). I'm willing to proxy maintain these except torque. Assuming there
>> are no users of torque on gentoo (bgo seems inactive...it's dead; how
>> would I know?).
>
> Looks like Ian got torque already, but he may appreciate some help.  For the
> other packages, I'm more then happy to proxy maintain them for you.  Just send
> any patches my way (including a first one to add you as a maintainer :)

OK will do and thanks for the help/sponsorship on these packages.


>> My focus is building gentoo centric HPC clusters that do not require
>> systemd as a component, with deployment emphasis on bare-metal and
>> minimized gentoo systems where only the codes absolutely necessary to
>> support the necessary frameworks are dynamically installed. Many of the
>> 'retro' tools in this cluster space, are quite useful for my work.
>>
>> The guidexml page for empi is old, so where do I read up on it's
>> projected usage (just not familiar with that empi project/package).
>
> The empi documentation did get moved over to the wiki [1].  However, it's pretty
> much the exact same thing you're seeing in the guidexml page.  I know there were
> some HPC sites using it in the past, but I haven't heard from anyone lately.
> That could mean no one is using it, or that everything is working as expected.
>
> 1.  https://wiki.gentoo.org/wiki/Empi

I'll survey and work on the others (checking bgo) and elsewhere for 
issues first. Then I'll poke around on empi an see what's up.

Netflix has posted a neat little (debian) cluster and running their 
framework on arm (rasp. pi) using apache mesos::

http://ispyker.blogspot.com/2016/05/services-with-netflix-titus-and.html

My (ultimate) goal is pretty similar, just using gentoo in lieu of 
debian; so if you run across any other relevant codes, drop me a line.


Thanks again,
James

[gentoo-dev] Re: Packages up for grabs

[Felix Janda]

I'd like become a proxy-maintainer for app-editors/nvi.

--Felix

Re: [gentoo-dev] Re: Packages up for grabs

[Peter Stuge]

Felix Janda wrote:
> I'd like become a proxy-maintainer for app-editors/nvi.

Sweet! If there are some open bugs then please upload patched ebuilds
and other neccessary files to the bugtracker, ideally as output by
git format-patch, and then talk e.g. to #gentoo-proxy-maint on freenode
to get someone to proxy them into the tree for you.

https://anongit.gentoo.org/git/repo/gentoo.git


//Peter

Re: [gentoo-dev] Re: Packages up for grabs

[Michał Górny]

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

On Sat, 6 Aug 2016 16:04:08 +0000
Peter Stuge <peter@stuge.se> wrote:

> Felix Janda wrote:
> > I'd like become a proxy-maintainer for app-editors/nvi.  
> 
> Sweet! If there are some open bugs then please upload patched ebuilds
> and other neccessary files to the bugtracker, ideally as output by
> git format-patch, and then talk e.g. to #gentoo-proxy-maint on freenode
> to get someone to proxy them into the tree for you.
> 
> https://anongit.gentoo.org/git/repo/gentoo.git

Or file a pull request @ https://github.com/gentoo/gentoo/pulls. That's
the most convenient solution for most of proxy-maint team members.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

Re: [gentoo-dev] Re: Packages up for grabs

[Peter Stuge]

Michał Górny wrote:
> Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
> That's the most convenient solution for most of proxy-maint team members.

How can I help improve that problematic situation?

It's not cool to gravitate the project towards GitHub Inc.


//Peter

Re: [gentoo-dev] Re: Packages up for grabs

[Rich Freeman]

On Sat, Aug 6, 2016 at 3:28 PM, Peter Stuge <peter@stuge.se> wrote:
> Michał Górny wrote:
>> Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
>> That's the most convenient solution for most of proxy-maint team members.
>
> How can I help improve that problematic situation?
>
> It's not cool to gravitate the project towards GitHub Inc.
>

I'm sure everybody would love to have a non-github alternative.  The
problem is that they all tend to be Java-based and infra doesn't want
to go near them (that isn't intended to imply anything other than the
state of things).

So, it sounds like we either need a non-Java-based alternative, or a
way to host Java applications.

-- 
Rich

Re: [gentoo-dev] Re: Packages up for grabs

[Michał Górny]

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

On Sat, 6 Aug 2016 16:47:09 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Sat, Aug 6, 2016 at 3:28 PM, Peter Stuge <peter@stuge.se> wrote:
> > Michał Górny wrote:  
> >> Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
> >> That's the most convenient solution for most of proxy-maint team members.  
> >
> > How can I help improve that problematic situation?
> >
> > It's not cool to gravitate the project towards GitHub Inc.
> 
> I'm sure everybody would love to have a non-github alternative.  The
> problem is that they all tend to be Java-based and infra doesn't want
> to go near them (that isn't intended to imply anything other than the
> state of things).
> 
> So, it sounds like we either need a non-Java-based alternative, or a
> way to host Java applications.

No. The problem is that alternatives suggested so far have been crap,
and people focused on preaching and/or implementing random crap-based
solutions without even stopping for a few minutes to consider what we
exactly need.

GitHub works for us. GitHub works for our contributors. GitHub boosts
our productivity, unlike those vain discussions. We don't have time for
all this tin foil hat nonsense.

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>

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

Re: [gentoo-dev] Re: Packages up for grabs

[Peter Stuge]

Peter Stuge wrote:
> How can I help improve ..?

Michał Górny wrote:
> people focused on preaching and/or implementing random crap-based
> solutions without even stopping for a few minutes to consider what
> we exactly need.

You could interpret my question as "what exactly do we need" ?


> GitHub works for us. GitHub works for our contributors. GitHub
> boosts our productivity, unlike those vain discussions.

Windows works for me. Windows works for my customers. Windows
boosts my business, unlike vain discussions about open source
and free software. ;) Maybe you get my point?


> We don't have time for all this tin foil hat nonsense.

I think we have all the time in the world, and I think it's important
for us to innovate also in this field if neccessary, as we have and
continue to do in other distro-development-related fields.


Thanks

//Peter

Re: [gentoo-dev] Re: Packages up for grabs

[Rich Freeman]

On Sat, Aug 6, 2016 at 4:55 PM, Michał Górny <mgorny@gentoo.org> wrote:
>
> GitHub works for us. GitHub works for our contributors. GitHub boosts
> our productivity, unlike those vain discussions. We don't have time for
> all this tin foil hat nonsense.
>

Then just ignore it.  If somebody wants to work on an alternative,
nobody can stop them.  Nobody is suggesting putting the github
solution on hold in the interim.

-- 
Rich

Re: [gentoo-dev] Re: Packages up for grabs

[Kent Fredric]

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

On Sat, 6 Aug 2016 19:28:19 +0000
Peter Stuge <peter@stuge.se> wrote:

> Michał Górny wrote:
> > Or file a pull request @ https://github.com/gentoo/gentoo/pulls.
> > That's the most convenient solution for most of proxy-maint team
> > members.  
> 
> How can I help improve that problematic situation?
> 
> It's not cool to gravitate the project towards GitHub Inc.

I kinda think this missed the point.  ( Though I did entirely expect a
complaint when he suggested it )

One avenue for contribution without Github: Patches by bugzilla, was
stated.

That will work, and is not restricting anyones freedom. It may however,
restrict convenience. But not freedom.

As far as I'm concerned, the statement about Github was a "oh, yeah,
and if you want, Github works too, so if you find that more convenient,
so do we, go right ahead, but you ain't gotta".

Everyone is free to, and encouraged to, create better solutions.

But there's no force to use Github.

If Github dies tomorrow, Gentoo will not drop dead. The convenience
will be lost, but people will still be completely able to send queues
of patches via bugzilla, or email, in the event that web browsers all
spontaneously die and cease to be free by some dark voodoo magic.

`git format-patch` is after all optimised for that latter case somewhat.

Maybe we should look into an Email Based submission service, create a
gentoo mailing list exclusively for 3rd party (proxy-maint) mail patch
queues, optimised for receiving and vetting patch sequences.

You don't need some fancy Java wank for that.

Then all we'd need is some alternative implementation of
dev-perl/Gentoo-App-Pram that can read a local mbox, and select
emails/email threads containing patch series, apply them, push them,
and then auto-reply to the email with a confirmation.

And then people could continue to use Github for their
easy-fast-non-free-workflow, and they could use some email submission
thing for the slightly-less-easy-but-free-as-hell workflow.

And for extra fun, we could support non-patch-queue emails that
contained references to public arbitrary git repositories and
automatically configured itself to pick a patch series from it, like
this example [1]: 

1: https://groups.google.com/forum/#!topic/linux.kernel/w957vpu3PPU

I mean, What do the Linux Kernel use? It would be a shame if they were
happening to use the email based workflow like I suggested([2,3,4]), and
if only there was a Gentoo Staffer who knew how Linux Contributions
worked and had documented it (sarcasm: [5])

2: https://groups.google.com/forum/#!topic/linux.kernel/w957vpu3PPU
3: https://news.ycombinator.com/item?id=3960876
4: https://github.com/torvalds/linux/pull/17#issuecomment-5663780
5:
https://github.com/gregkh/kernel-tutorial/blob/master/walkthrough#L47-L52




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

Re: [gentoo-dev] Re: Packages up for grabs

[Michał Górny]

Dnia 6 sierpnia 2016 23:12:55 CEST, Peter Stuge <peter@stuge.se> napisał(a):
>Peter Stuge wrote:
>> How can I help improve ..?
>
>Michał Górny wrote:
>> people focused on preaching and/or implementing random crap-based
>> solutions without even stopping for a few minutes to consider what
>> we exactly need.
>
>You could interpret my question as "what exactly do we need" ?

If you really want to know...

For a start, something that would satisfy the performance, maintainability and security needs of infra. I haven't heard of anything like that, so you'll probably have to start a new project. I suggest high quality C/C++ since other languages are either completely unreliable, slow and/or designed to be a security nightmare.

Once again, bear performance in mind. Most of the existing tools can't handle big repos. It ain't productive when every small action takes 5 seconds.

Accessibility is also important, but without hurting convenience. Probably accessible web interface with optional ES booster and a reasonably stable API (i.e. not pybugz-style 'XMLRPC is not cool anymore, so we instantly kill all the API you ever used').

That's it for the generic requirements. Now for the specific workflow:

1. Preferably no custom registration. Some kind of SSO via Bugzilla, OpenID or GitHub would work. No additional passwords, thank you.

2. Ability to conveniently post branches for review. Git push is most preferable, but I guess we can live with mails if done sanely).

3. Ability to conveniently get branches for merging. Again, git pull is the best option here. No 'click and download this dozen patches'.

4. No need for remote merge. The thing's not going to push anything directly to git.g.o.

5. Fast review with per-line and general comments. Ability to hide threads as resolved. Lightweight so that people don't have to put multiple remarks in a single comments. Readable so it's easy to note remarks made by others.

6. Good support for updating commits. Preferably being able to reapply (move) comments as appropriate.

7. Some kind of nice assignment/CC system with notifications that covers all developers without explicit signup.

>> GitHub works for us. GitHub works for our contributors. GitHub
>> boosts our productivity, unlike those vain discussions.
>
>Windows works for me. Windows works for my customers. Windows
>boosts my business, unlike vain discussions about open source
>and free software. ;) Maybe you get my point?

Does Microsoft let you use Windows for free? But yes, I generally agree. I regularly use Windows to print after many hours wasted on trying to get printing working on Linux. Having to print three pages a month, my business is much happier with it.

>
>
>> We don't have time for all this tin foil hat nonsense.
>
>I think we have all the time in the world, and I think it's important
>for us to innovate also in this field if neccessary, as we have and
>continue to do in other distro-development-related fields.

Sure we do. In the meantime, nobody uses gentoo anymore because it still can't deal with accepting contributions and in the meantime the few last developers retired, and users long ago switched to the comparatively recent distribution of Debian stable.


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] Re: Packages up for grabs

[Consus]

On 08:48 Sun 07 Aug, Michał Górny wrote:
> Sure we do. In the meantime, nobody uses gentoo anymore because it
> still can't deal with accepting contributions and in the meantime the
> few last developers retired, and users long ago switched to the
> comparatively recent distribution of Debian stable.

Finally the voice of reason.

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 02:38 AM, Consus wrote:
> On 08:48 Sun 07 Aug, Michał Górny wrote:
>> Sure we do. In the meantime, nobody uses gentoo anymore because it
>> still can't deal with accepting contributions and in the meantime the
>> few last developers retired, and users long ago switched to the
>> comparatively recent distribution of Debian stable.
>
> Finally the voice of reason.

Reasonable?  Are you kidding?
<rolling on the floor with laughter, uncontrollably >

In this day and age, quick installs are the mantra, either for VMs or
containers or workstations, particularly for 
application-specific-servers or a variety of security apparatus. 
Although the 'handbook' is an excellent reference guide and noob-filter, 
the simple fact of the matter is most (nix) professionals consider the 
gentoo install system to be arcane and an incredible 'cost barrier to 
entry'. THAT, the lack of a well thought out, smooth, quick/easy install 
which is intentionally not  available, because it  is seen as a satanic 
idea, is the 800 pound gorilla on why folks passionately avoid gentoo.....


As a team, we could have a simple default program for a simple default
disk format, and a variety of 'stage-4' images, maybe updated every 3 
months, to get a gentoo system up, quickly. Not an anything you want it 
to be, but a few, common choices. Perhaps a security apparatus, commonly 
needed, built on the hardened project? (like a bridge or a firewall)?


Then index the noob questions received from  the jentoo-users ML,  into 
the handbook or companion documents, in a hyperlinked FAQ. Folks could 
then work the question/support board of jentoo-user before being 
accepted into jproxy-maint.  JProxy-maint would then need to become a 
collection of docs to read, a half dozen ebuilds to update and then 
bang, junior-dev status where folks can work on non-critical parts of 
the jentoo tree.  And there could be a 'bypass exam' that if you know 
the basics of *nix and shell, you could jump straight into contributing 
on jentoo. Or better yet:: (Fork the tree for the jproxy-maint and 
junior-devs to run themselves. That fork could be limited to a few 
security appliance(s) system, and an embedded jentoo system (rasp. pi) 
and a firewall/bridge. Let them use java* codes, as that is what all the 
universities are teaching and promoting. I agree with gentoo proper on 
severely restricting java*,  on gentoo-proper, but that sort of thing is 
killing gentoo and just appears to the open world as a filter mechanism 
to keep out and go elsewhere, snoot. There are just too many exciting 
and useful codes out there running java.


After 12 years of using gentoo, the gentoo install semantics, still are 
abysmal, imho. I just fundamentally disagree with forcing folks to first 
endure the handbook before getting any gentoo (working gentoo system) 
gratification. That is why 'Debian/buntu' has market share over us. Here 
is a very useful "canned" install that, if emulated, would give gentoo 
reams of "kudos" or "atta-boys" should we publish (provide) something 
like this.[1]

[1] http://blog.securityonion.net/


"Security Onion is a Linux distro for intrusion detection, network 
security monitoring, and log management. It's based on Ubuntu and 
contains Snort, Suricata, Bro, OSSEC, Sguil, Squert, ELSA, Xplico, 
NetworkMiner, and many other security tools. The easy-to-use Setup 
wizard allows you to build an army of distributed sensors for your 
enterprise in minutes!"


We could even call it "jentoo", as it could be labeled to indicate it
is for junior developers to experiment, learn, grow and then become a 
fleeting-gentoo-dev found @ gentoo-dev proper. And yes enjoy the latest 
of from the (insecure) java world.


Restated:: the current (lack) of a slick, simple & quick install 
semantic, is what's killing gentoo, if it is dying. What I run into are 
reams of deeply accomplished technical folks that use gentoo regularly 
and like the current filters that run off the less astute, imho. YMMV.
Most all other rolling distros have a much simpler installation 
semantic, if not a variety of easy install options and ways to participate.

Perhaps a well defined OS model, where gentoo can run (secure) VMs or 
containers from jentoo?   That would expand the model of usage and 
encourage inclusion, provide a pathway to the ultimate gentoo-dev status
and encourage innovation (and failure) all in a secure model?

Heaven forbid that we put up a few dozen (unsupported) jentoo VMs,
container-images or stage-4 (specifically purposed) choices where
folks could only get support from jentoo-user. No sir, we cannot make 
jentoo fun and enjoyable and quick (and sleazy) can we?


And yes allow java, the way it is available on most other distros...
The current process of requiring all the java codes to be broken down 
into 100% discernable codes is a tremendous barrier. After all, most of 
the codes that use that stuff, are full of holes anyway; that's the very 
nature of open, fast, exciting new codes. They only become secure
after years of vetting (fuzzing) anyway. So make the host gentoo image 
very secure and allow jentoo projects to be a VM, or container or such
construct, without all the hassles of gentoo proper. Let the purist 
ensure that gentoo is secure and isolated and let the multitude play 
with java, however they like (in a VM, or a container image or a stage-4).

You have to look at CoreOS and conclude that even folks with deep 
expertise and deep pockets want an easy install (even roll-back) OS.



hth,
James

Re: [gentoo-dev] Re: Packages up for grabs

[Kent Fredric]

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

On Sun, 7 Aug 2016 08:24:51 -0500
james <garftd@verizon.net> wrote:

> 
> As a team, we could have a simple default program for a simple default
> disk format, and a variety of 'stage-4' images, maybe updated every 3 
> months, to get a gentoo system up, quickly. Not an anything you want
> it to be, but a few, common choices. Perhaps a security apparatus,
> commonly needed, built on the hardened project? (like a bridge or a
> firewall)?

I for one miss the days where Stage-1 was the defacto install, and
Stage-3 was "For lazy people who just wanted to use something".

When we transitioned to making Stage 3 the default, it was like, heresy.

Stage 4? :)

I highly encourage people to randomly hurt themselves by attempting an
unsupported Stage 1 install, just to find what breaks.

> Let them use java* codes, as that is what all the universities are
> teaching and promoting. I agree
> with gentoo proper on severely restricting java*,  on gentoo-proper,
> but that sort of thing is killing gentoo and just appears to the open
> world as a filter mechanism to keep out and go elsewhere, snoot.
> There are just too many exciting and useful codes out there running
> java.

"All" ? Some. And the dominance and focus on Java is itself telling of
the quality and type of the education provider.

Some education providers may not touch Java at all, and focus
predominantly on C.

You can't satisfy everyone out of the box.


The rest of your response kinda rotates around a central axiom that
makes other Linux distributions effective, and "Easy":

The lack of choice, a tailored work flow, a target audience, and a
narrow focus on what the vendor delivers.

Gentoo is fundamentally unlike these things, because the Gentoo way has
always been first and foremost about *user choice* and *maximising user
choice*

The reality is a giant hunk of the world are *not interested in choice*

They want something that works and get out of their way.

That's why proprietary systems with deep, vertical architecture and
product lock-in are still incredibly popular.

They understand their market, and they focus on making things work for
that market by tailoring it to a very narrow set of features that
satisfies 95% of its target.

Gentoo's target audience is decidedly that other 5%, the group of
people who don't mind getting their hands dirty, the group who wade up
to their elbows dealing with horrible problems because that's the
consequence of the power of choice.

You can promote pre-boxed Gentoo products if you want, I just think
you're barking up the wrong tree if you think doing that will help
anybody.

As with most open source, it requires volunteer effort to make this
happen, and its a hard sell to try to convince existing staff to spend
more time on producing a thing that exists only to *reduce* user choice
for the sake of convenience.

And I just think most of our devs have more interesting problems to
solve than that, and you'd be simply weakening the core Gentoo
development team by trying to steal existing Gentoo staff to engineer
this carefully designed and polished "Just Works For Noobs" platform.

And even then, I think if you did OK, it would be striving for the
wrong thing.

If you're going to come to a competition that has existing major
players ( such as the "noob friendly" linux desktop market ), you have
to not be simply a "me too!" in order to hope for success.

You have to have something unique that blows all the competition out of
the water in at least one way, that capitalises on an un-tapped need.

Anything else will just be some pathetic copy-cat attempt.

And for Gentoo, our "Unique Edge" *is* our configurability, our
incredibly effective and convenient flexibility.

Sacrificing our primary benefit to chase after some other market
half-assedly ... I can't see that panning out well myself.

Personally, I think we need to double down on what we're good at,
flexibility, and configurability.

Find ways of building systems at the users behest that do exactly what
they want easily, and not assume we know what is best for our users.

Anything else and Gentoo will go in the direction of the sad sorry
state of the Linux Desktop, where neither GTK/Gnome or QT/KDE are very
useable anymore, and they've become encumbered with horribly lethargic
and bloated design, because they were all trying too hard to chase what
they thought people wanted, the standard established by Windows and OSX
for "Easy".




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

Re: [gentoo-dev] Re: Packages up for grabs

[Alan McKinnon]

On 07/08/2016 15:32, Kent Fredric wrote:
>> Let them use java* codes, as that is what all the universities are
>> > teaching and promoting. I agree
>> > with gentoo proper on severely restricting java*,  on gentoo-proper,
>> > but that sort of thing is killing gentoo and just appears to the open
>> > world as a filter mechanism to keep out and go elsewhere, snoot.
>> > There are just too many exciting and useful codes out there running
>> > java.
> "All" ? Some. And the dominance and focus on Java is itself telling of
> the quality and type of the education provider.
> 
> Some education providers may not touch Java at all, and focus
> predominantly on C.
> 
> You can't satisfy everyone out of the box.
> 


I have no idea where James gets his information from, but I suspect it's
a niche market where uni students do "clustering" - whatever that is.

The interesting apps out there are mostly running python, go and
(sometimes) lua. And that's what I observe in my day job -
business/mobile ISP.

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] Re: Packages up for grabs

[Consus]

On 08:24 Sun 07 Aug, james wrote:
> On 08/07/2016 02:38 AM, Consus wrote:
> > On 08:48 Sun 07 Aug, Michał Górny wrote:
> > > Sure we do. In the meantime, nobody uses gentoo anymore because it
> > > still can't deal with accepting contributions and in the meantime the
> > > few last developers retired, and users long ago switched to the
> > > comparatively recent distribution of Debian stable.
> > 
> > Finally the voice of reason.
> 
> Reasonable?  Are you kidding?
> <rolling on the floor with laughter, uncontrollably >
> 
> In this day and age, quick installs are the mantra, either for VMs or
> containers or workstations, particularly for application-specific-servers or
> a variety of security apparatus. Although the 'handbook' is an excellent
> reference guide and noob-filter, the simple fact of the matter is most (nix)
> professionals consider the gentoo install system to be arcane and an
> incredible 'cost barrier to entry'. THAT, the lack of a well thought out,
> smooth, quick/easy install which is intentionally not  available, because it
> is seen as a satanic idea, is the 800 pound gorilla on why folks
> passionately avoid gentoo.....

Err... On that one I agree. How the hell does it change the fact that
GitHub improved contributions?

Re: [gentoo-dev] Re: Packages up for grabs

[Alec Ten Harmsel]

On 8/7/2016 10:06 AM, Alan McKinnon wrote:
> I have no idea where James gets his information from, but I suspect it's
> a niche market where uni students do "clustering" - whatever that is.

Many of the new frameworks/servers that are developed for running or 
managing clusters are written in Java, which is what he's referring to 
as far as I can tell. Hadoop, spark, hive, pig, marathon, cloudstack, 
zookeeper, and many more (see http://www.apache.org for plentiful 
examples) are all JVM-based languages.

University students do not touch on anything related to clustering until 
graduate level courses (I just graduated from the University of 
Michigan), unless they work on that stuff as a job or in their spare time.

> The interesting apps out there are mostly running python, go and
> (sometimes) lua. And that's what I observe in my day job -
> business/mobile ISP.
>

Yes and no, depending on what you find interesting. Plenty of web 
applications are written in python or ruby, but I think it's safe to 
assume that most high-traffic organizations have mounds of Java and 
C/C++ services on the backend for various reasons.

Alec

Re: [gentoo-dev] Re: Packages up for grabs

[Rich Freeman]

On Sun, Aug 7, 2016 at 9:24 AM, james <garftd@verizon.net> wrote:
>
> As a team, we could have a simple default program for a simple default
> disk format, and a variety of 'stage-4' images, maybe updated every 3
> months, to get a gentoo system up, quickly. Not an anything you want it to
> be, but a few, common choices. Perhaps a security apparatus, commonly
> needed, built on the hardened project? (like a bridge or a firewall)?
>

Sounds great.  What's stopping you?

>
> Heaven forbid that we put up a few dozen (unsupported) jentoo VMs,
> container-images or stage-4 (specifically purposed) choices where
> folks could only get support from jentoo-user. No sir, we cannot make jentoo
> fun and enjoyable and quick (and sleazy) can we?
>

Sounds great.  What's stopping you?

>
> And yes allow java, the way it is available on most other distros...
> The current process of requiring all the java codes to be broken down into
> 100% discernable codes is a tremendous barrier. After all, most of the codes
> that use that stuff, are full of holes anyway; that's the very nature of
> open, fast, exciting new codes. They only become secure
> after years of vetting (fuzzing) anyway. So make the host gentoo image very
> secure and allow jentoo projects to be a VM, or container or such
> construct, without all the hassles of gentoo proper. Let the purist ensure
> that gentoo is secure and isolated and let the multitude play with java,
> however they like (in a VM, or a container image or a stage-4).
>

Sounds great.  What's stopping you?

-- 
Rich

[gentoo-dev] Re: Packages up for grabs

[Michael Palimaka]

On 07/08/16 19:26, Pacho Ramos wrote:
> This packages are now up for grabs:
> dev-util/gource

I can take this one.

Re: [gentoo-dev] Re: Packages up for grabs

[Ciaran McCreesh]

On Sun, 7 Aug 2016 12:24:37 -0500
james <garftd@verizon.net> wrote:
> >> Let them use java* codes, as that is what all the universities are
> >> teaching and promoting. I agree
> >> with gentoo proper on severely restricting java*,  on
> >> gentoo-proper, but that sort of thing is killing gentoo and just
> >> appears to the open world as a filter mechanism to keep out and go
> >> elsewhere, snoot. There are just too many exciting and useful
> >> codes out there running java.  
> >
> > "All" ? Some. And the dominance and focus on Java is itself telling
> > of the quality and type of the education provider.
> >
> > Some education providers may not touch Java at all, and focus
> > predominantly on C.  
> 
> Sure, I agree here, but, statistically these "hi level" languages are 
> being taught, in lieu of C; and that is really sad. I'm sure there
> are exceptions, would you have a few CS departments that push C over
> java and the other, newer languages? (I'm curios).

You all appear to be missing the point of education. If you are learning
technologies, your skills will be obsolete in five years. If you are
learning general principles and problem solving, the particular
language being used is much less important.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 08:32 AM, Kent Fredric wrote:
> On Sun, 7 Aug 2016 08:24:51 -0500
> james <garftd@verizon.net> wrote:
>
>>
>> As a team, we could have a simple default program for a simple default
>> disk format, and a variety of 'stage-4' images, maybe updated every 3
>> months, to get a gentoo system up, quickly. Not an anything you want
>> it to be, but a few, common choices. Perhaps a security apparatus,
>> commonly needed, built on the hardened project? (like a bridge or a
>> firewall)?
>
> I for one miss the days where Stage-1 was the defacto install, and
> Stage-3 was "For lazy people who just wanted to use something".
>
> When we transitioned to making Stage 3 the default, it was like, heresy.
>
> Stage 4? :)
>
> I highly encourage people to randomly hurt themselves by attempting an
> unsupported Stage 1 install, just to find what breaks.
>
>> Let them use java* codes, as that is what all the universities are
>> teaching and promoting. I agree
>> with gentoo proper on severely restricting java*,  on gentoo-proper,
>> but that sort of thing is killing gentoo and just appears to the open
>> world as a filter mechanism to keep out and go elsewhere, snoot.
>> There are just too many exciting and useful codes out there running
>> java.
>
> "All" ? Some. And the dominance and focus on Java is itself telling of
> the quality and type of the education provider.
>
> Some education providers may not touch Java at all, and focus
> predominantly on C.

Sure, I agree here, but, statistically these "hi level" languages are 
being taught, in lieu of C; and that is really sad. I'm sure there are 
exceptions, would you have a few CS departments that push C over java
and the other, newer languages? (I'm curios).


>
> You can't satisfy everyone out of the box.
>
>
> The rest of your response kinda rotates around a central axiom that
> makes other Linux distributions effective, and "Easy":
>
> The lack of choice, a tailored work flow, a target audience, and a
> narrow focus on what the vendor delivers.
>
> Gentoo is fundamentally unlike these things, because the Gentoo way has
> always been first and foremost about *user choice* and *maximising user
> choice*

Noting in promoting an easy install semantic for a default, buildable 
system, precludes choice after the system is installed and boot. For 
examle a default install, using Calamares and ending up with KDE, could 
easily then have kde removed and lxqt installed. That would be up to the 
new user to figure out, via the handbook and the wiki....


> The reality is a giant hunk of the world are *not interested in choice*
> They want something that works and get out of their way.

Quite true, but we're talking about increasing gentoo's update amongst 
those linux leaners, not converting windows/mac users that are not 
interested in alternatives....

>
> That's why proprietary systems with deep, vertical architecture and
> product lock-in are still incredibly popular.
> They understand their market, and they focus on making things work for
> that market by tailoring it to a very narrow set of features that
> satisfies 95% of its target.

Support is always a crowd pleaser, imho. So with fresh ideas, the newest 
members support those right behind them in line with user level issues. 
Noobs helping noobs. buntu has proven this works, if nothing else.

>
> Gentoo's target audience is decidedly that other 5%, the group of
> people who don't mind getting their hands dirty, the group who wade up
> to their elbows dealing with horrible problems because that's the
> consequence of the power of choice.

What I proposed, models for easier install and a VM/Container system 
that is secure and allow for experimentation with "jentoo" does not 
limit, but, encourage choice and experimentation.

Let's focus on the easy install. Once folks get a running gentoo system, 
most figure out how to manage it and like the choices, build from 
sources (and bin packages for the larger/complex).

>
> You can promote pre-boxed Gentoo products if you want, I just think
> you're barking up the wrong tree if you think doing that will help
> anybody.

You are misconstruing the message. It's a boxed, quick install that 
would behave going forward, with the same (exact) semantics as a 
grudge-filled traditional install. The only difference is that first 
install is
quick, fast and easy. Nothing else changes, unless this fresh install 
chooses to embrace additional packaging or alternative packages compare 
to the default install. Nobody needs to make that decision. Surely many 
will then go read the handbook and the wiki to move forward.
The install just becomes painless for a few basic or default examples.
We do currently provide an occasional 'liveDVD'. So just image one of 
those, with an  easy install pathway.

>
> As with most open source, it requires volunteer effort to make this
> happen, and its a hard sell to try to convince existing staff to spend
> more time on producing a thing that exists only to *reduce* user choice
> for the sake of convenience.

Again, you are incorrectly suggesting that these easy installs will 
preclude traditional gentoo semantics for adding, modifying, patching,
or any other form of currently available modifications or enhancement 
from occurring. I'm not certain if you are twisting the focus here 
intentionally, or you are just limited in your imagination? Nobody wants 
that (artificial) limitation, so why would it me the semantic going 
forward, after an easy install?

Think of it like sex. All of the traditional would be wonderfully 
available, but we're just adding a quickie (install) as an extra option.
No limitations, just *choice* on the install.



> And I just think most of our devs have more interesting problems to
> solve than that, and you'd be simply weakening the core Gentoo
> development team by trying to steal existing Gentoo staff to engineer
> this carefully designed and polished "Just Works For Noobs" platform.

Agreed. My idea is some encouragement and maybe receive a little bit of 
positive advise. The noobs will help the noobs, and a few will migrate 
down the maintainer--> dev pathway.

On this list and elsewhere gentoo devs have admitted to using quickie 
installs, and liked it. It's just frowned upon to document it and 
encourage it. Like a wiki page on how to convert a calculate or sabayon 
install to a traditional gentoo system.
>
> And even then, I think if you did OK, it would be striving for the
> wrong thing.

An easy install, does not have to be detrimental. Over the years I have 
taught quite a few 'youngsters' how to drive on rural flat land in a big 
4x4 with an automatic transmission and a booster seat. You just put the 
transfer case into low, and they cannot go very fast and the love the 
*power*, spinning tires and slinging mud and riding around. Later on in 
life they all have matured into productive adults.

Face it, gentoo is a power trip, we all know that. Letting folks feel 
that, in a easy, but real, quick install default version, that 
eventually hooks them into gentoo.


>
> If you're going to come to a competition that has existing major
> players ( such as the "noob friendly" linux desktop market ), you have
> to not be simply a "me too!" in order to hope for success.

The power of Gentoo-traditional awaits them, soon after reading and 
learning from the handbook and the wiki. Not all will use this, but,
it sure would put a more attractive face on taking gentoo for a test drive.

>
> You have to have something unique that blows all the competition out of
> the water in at least one way, that capitalises on an un-tapped need.
>
> Anything else will just be some pathetic copy-cat attempt.
>
> And for Gentoo, our "Unique Edge" *is* our configurability, our
> incredibly effective and convenient flexibility.

Again, nothing in this idea inhibits the full power of gentoo from being 
available; nothing. The begging of (their) journey is easier and
more appealing. Many will stay in the valley of the noobs, but other 
will turn to the handbook and the wiki; just as grasshopper became 
shaolin, imho. Monk my words.....


>
> Sacrificing our primary benefit to chase after some other market
> half-assedly ... I can't see that panning out well myself.

You keep with this false choice, that is non-sequitur. The only limiting 
here is your mind.


>
> Personally, I think we need to double down on what we're good at,
> flexibility, and configurability.

No arguments there. Putting an experimental for of gentoo, complete with 
questionable java, into a secure Gentoo hosted VM or Container,
is not flexibility and configurability?


>
> Find ways of building systems at the users behest that do exactly what
> they want easily, and not assume we know what is best for our users.

You should go to any of the progressive job boards (stackoverflow etc). 
Java is everywhere. It should not be mandated but a choice. Sincere the 
are numerous issues java, secure it via a VM or a container, if that can 
be done?



>
> Anything else and Gentoo will go in the direction of the sad sorry
> state of the Linux Desktop, where neither GTK/Gnome or QT/KDE are very
> useable anymore, and they've become encumbered with horribly lethargic
> and bloated design, because they were all trying too hard to chase what
> they thought people wanted, the standard established by Windows and OSX
> for "Easy".
>
Agreed and that is not what I'm proposing, either. I'm proposing an easy 
install for a few types of basic systems (that choice is open to 
discussion). And, if possible, a way to put either a secure VM or a 
secure container on a hardened gentoo system to put an 
insecure/experimental form of jentoo into.

No one but you is talking about any limitations.


hth,
James


>
>

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 09:06 AM, Alan McKinnon wrote:
> On 07/08/2016 15:32, Kent Fredric wrote:
>>> Let them use java* codes, as that is what all the universities are
>>>> teaching and promoting. I agree
>>>> with gentoo proper on severely restricting java*,  on gentoo-proper,
>>>> but that sort of thing is killing gentoo and just appears to the open
>>>> world as a filter mechanism to keep out and go elsewhere, snoot.
>>>> There are just too many exciting and useful codes out there running
>>>> java.
>> "All" ? Some. And the dominance and focus on Java is itself telling of
>> the quality and type of the education provider.
>>
>> Some education providers may not touch Java at all, and focus
>> predominantly on C.
>>
>> You can't satisfy everyone out of the box.
>>
>
>
> I have no idea where James gets his information from, but I suspect it's
> a niche market where uni students do "clustering" - whatever that is.

I spend a lot of time "hooping" with college kids in a variety of 
venues. College kids and adults, from around the world visit the hoop 
venues in Central Florida. Lots of kids who are not CS majors are 
involved in coding, and java reigns supreme, imho, as the most often 
cited programming language they use, because professors and employers 
alike dictate that on them.

Also Just look at the job boards and the new projects springing up on 
github. Sure python is very popular. But, I cannot think of a single 
distro that offer java and precludes python, so why not have both.

Yes java is popular in rich environments where jobs in the cloud or on 
an internal cluster contain java codes. Most kids only use the cloud and 
are not 'full stack' aware or part of the foundation of the resources 
they code for.


> The interesting apps out there are mostly running python, go and
> (sometimes) lua. And that's what I observe in my day job -
> business/mobile ISP.


Look at the job listing on stackoverflow and elsewhere (java) is very 
popular when they list several programming languages to meet the 
requirements. I'm not promoting java, at all, but just stating that it 
is very popular, on new projects (but not all) and it is a large and 
frequent requirement, dictating by employers. Kids coming out of college 
want a job, more than anything, and most are having java crammed down 
their throats. So we should  find a way to robustly
support those that need java. Nothing is precluding other languages
in my message. Personally I avoid java, unless it is critical to
a code or family of codes I need to run.


hth,
James

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 09:09 AM, Consus wrote:
> On 08:24 Sun 07 Aug, james wrote:
>> On 08/07/2016 02:38 AM, Consus wrote:
>>> On 08:48 Sun 07 Aug, Michał Górny wrote:
>>>> Sure we do. In the meantime, nobody uses gentoo anymore because it
>>>> still can't deal with accepting contributions and in the meantime the
>>>> few last developers retired, and users long ago switched to the
>>>> comparatively recent distribution of Debian stable.
>>>
>>> Finally the voice of reason.
>>
>> Reasonable?  Are you kidding?
>> <rolling on the floor with laughter, uncontrollably >
>>
>> In this day and age, quick installs are the mantra, either for VMs or
>> containers or workstations, particularly for application-specific-servers or
>> a variety of security apparatus. Although the 'handbook' is an excellent
>> reference guide and noob-filter, the simple fact of the matter is most (nix)
>> professionals consider the gentoo install system to be arcane and an
>> incredible 'cost barrier to entry'. THAT, the lack of a well thought out,
>> smooth, quick/easy install which is intentionally not  available, because it
>> is seen as a satanic idea, is the 800 pound gorilla on why folks
>> passionately avoid gentoo.....
>
> Err... On that one I agree. How the hell does it change the fact that
> GitHub improved contributions?

Ok, so I should have prune the post to focus my response::

"In the meantime, nobody uses gentoo anymore because"

My response is not about github, the past or the future of the Version 
Control, Contributions or such, espoused by github.

My responses are to why such a mature and wonderful distro, Gentoo 
specifically, is suffering::"nobody uses gentoo anymore". And in fact I 
mildly questioned if that is the case. I think we all agree that there 
is some mistery as to why gentoo is not grower more attractive, to folks 
not using gentoo, at a faster rate with greater uptake on a permanent 
commitment to gentoo (if I may politely be so bold?).

Git hub is fine. Sure, I'd like to see the tree run on something 
opensource, but, github is fine, for now. ymmv. The future, who knows.


hth,
James

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 09:47 AM, Rich Freeman wrote:
> On Sun, Aug 7, 2016 at 9:24 AM, james <garftd@verizon.net> wrote:
>>
>> As a team, we could have a simple default program for a simple default
>> disk format, and a variety of 'stage-4' images, maybe updated every 3
>> months, to get a gentoo system up, quickly. Not an anything you want it to
>> be, but a few, common choices. Perhaps a security apparatus, commonly
>> needed, built on the hardened project? (like a bridge or a firewall)?
>>
>
> Sounds great.  What's stopping you?
>
>>
>> Heaven forbid that we put up a few dozen (unsupported) jentoo VMs,
>> container-images or stage-4 (specifically purposed) choices where
>> folks could only get support from jentoo-user. No sir, we cannot make jentoo
>> fun and enjoyable and quick (and sleazy) can we?
>>
>
> Sounds great.  What's stopping you?
>
>>
>> And yes allow java, the way it is available on most other distros...
>> The current process of requiring all the java codes to be broken down into
>> 100% discernable codes is a tremendous barrier. After all, most of the codes
>> that use that stuff, are full of holes anyway; that's the very nature of
>> open, fast, exciting new codes. They only become secure
>> after years of vetting (fuzzing) anyway. So make the host gentoo image very
>> secure and allow jentoo projects to be a VM, or container or such
>> construct, without all the hassles of gentoo proper. Let the purist ensure
>> that gentoo is secure and isolated and let the multitude play with java,
>> however they like (in a VM, or a container image or a stage-4).
>>
>
> Sounds great.  What's stopping you?
>

Why Rich, thanks for the triple compliments; is that a vote that the 
basic idea(s) have merit, or sarcasm?

We are all part of a village, so feedback is warmly received, regardless
of the nature of the  prose....

As you probably know, I have been working on many of these issues, for a 
variety of reason.


James

Re: [gentoo-dev] Re: Packages up for grabs

[Rich Freeman]

On Sun, Aug 7, 2016 at 1:47 PM, james <garftd@verizon.net> wrote:
> On 08/07/2016 09:47 AM, Rich Freeman wrote:
>>
>> Sounds great.  What's stopping you?
>>
>
> Why Rich, thanks for the triple compliments; is that a vote that the basic
> idea(s) have merit, or sarcasm?
>

I'm just expressing that the typical blocker is somebody willing to
contribute.  I don't think anybody opposes Java support on Gentoo, or
having a canned installation.  It takes way longer than it should to
get a container running/etc.

-- 
Rich

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 11:21 AM, Ciaran McCreesh wrote:
> On Sun, 7 Aug 2016 12:24:37 -0500
> james <garftd@verizon.net> wrote:
>>>> Let them use java* codes, as that is what all the universities are
>>>> teaching and promoting. I agree
>>>> with gentoo proper on severely restricting java*,  on
>>>> gentoo-proper, but that sort of thing is killing gentoo and just
>>>> appears to the open world as a filter mechanism to keep out and go
>>>> elsewhere, snoot. There are just too many exciting and useful
>>>> codes out there running java.
>>>
>>> "All" ? Some. And the dominance and focus on Java is itself telling
>>> of the quality and type of the education provider.
>>>
>>> Some education providers may not touch Java at all, and focus
>>> predominantly on C.
>>
>> Sure, I agree here, but, statistically these "hi level" languages are
>> being taught, in lieu of C; and that is really sad. I'm sure there
>> are exceptions, would you have a few CS departments that push C over
>> java and the other, newer languages? (I'm curios).
>
> You all appear to be missing the point of education. If you are learning
> technologies, your skills will be obsolete in five years. If you are
> learning general principles and problem solving, the particular
> language being used is much less important.
>

I agree, but if you do not know of C and or Assembler, how can you 
comprehend what goes on in firmware or with an embedded system?
The bootstapped state machine, teach grasshoppers to appreciate an RTOS. 
Likewise, the linux kernel become a great thing of beauty, when one has 
spend some time with an Rtos.

If you don not know of those things, how can these kids comprehend that 
illicit codes are in hardware, or the lower layers of the stack and thus 
fuzzing the code they wrote is pointless. I guess you could write 
firmware in Go,  but that would be quite a stretch to the EE that work 
with the CE that builds the basis of a product or a system. They lack 
fundamental understanding  of the fundamentals because these kids are 
being moved further and further away from how hardware and low level 
codes actually work. They are clueless, imho, and that is a fundamental 
fault-line in their education, imho.

I do not know of a single hacker on the gentoo embedded channel that 
struggles to run a basic gentoo server, but the opposite is quite a 
common occurrence,  sysadms that know little of low level issues, imho. 
That's my point; and gentoo is possible part of the solution to change 
this, imho.


hth,
James

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 12:49 PM, Rich Freeman wrote:
> On Sun, Aug 7, 2016 at 1:47 PM, james <garftd@verizon.net> wrote:
>> On 08/07/2016 09:47 AM, Rich Freeman wrote:
>>>
>>> Sounds great.  What's stopping you?
>>>
>>
>> Why Rich, thanks for the triple compliments; is that a vote that the basic
>> idea(s) have merit, or sarcasm?
>>
>
> I'm just expressing that the typical blocker is somebody willing to
> contribute.  I don't think anybody opposes Java support on Gentoo, or
> having a canned installation.  It takes way longer than it should to
> get a container running/etc.
>


I agree with all you have stated, in this entire thread. I have/am 
working on many pieces of this this thread and many more all ready exist
as components, like stage-4 iso for gentoo. They are already in many 
mirrors. Yes they are very specific, but lack some install guidelines in 
the handbook; just exactly how to do a stage 4 install. Instructions do 
exist that are piecemeal or legacy, but not in the handbook, nor the 
wiki for stage-4 installs. One even struggle what docs to believe on how 
to construct a stage-4 file for install. If wisdom from gentoo-devs is 
these stage-4 issues are to be well hidden, at least there should 
likewise be accurate docs with those stage-4 iso, imho.


I agree about secure VM and containers. I still struggle with that too; 
hence the posting here. Today is my response to what ails gentoo; github
is such a minor, miniscule issue on that large question, imho.


My thesis:: github is not the blocker for faster and wider uptake of 
gentoo.  An easy install is the largest issue, followed by a way to 
robustly support/offer java, are about 95% of the blocker issues to 
gentoo update, imho. So I have suggested a variety of mechanism, for 
discussion on gentoo update (which would lead to more gentoo devs and 
contributions) even to the point of in a VM centric, or sister distro, 
as potentially plausible mechanisms to attract new users (and devs) to 
gentoo.


hth,
Jaems

Re: [gentoo-dev] Re: Packages up for grabs

[Alan McKinnon]

On 07/08/2016 19:36, james wrote:
>> The interesting apps out there are mostly running python, go and
>> (sometimes) lua. And that's what I observe in my day job -
>> business/mobile ISP.
> 
> 
> Look at the job listing on stackoverflow and elsewhere (java) is very
> popular when they list several programming languages to meet the
> requirements. I'm not promoting java, at all, but just stating that it
> is very popular, on new projects (but not all) and it is a large and
> frequent requirement, dictating by employers. Kids coming out of college
> want a job, more than anything, and most are having java crammed down
> their throats. So we should  find a way to robustly
> support those that need java. Nothing is precluding other languages
> in my message. Personally I avoid java, unless it is critical to
> a code or family of codes I need to run.


I recommend Java as a teaching language at university level.

You get all the benefits of a C-like syntax without the overhead of
learning to deal with C and/or C++. You don't have to deal with the
toolchain (much), you can easily show correct implementations of OOP
style without getting into generics (or, you can avoid Java generics
altogether at this level and pretend they don't exist).

In short, what's not to like for teaching? All win not much lose.

Well OK some kids come away thinking Java is the one and only, but they
will have that too if Python is the teaching language. Realizing there
are other things out there is part of the learning process.

But, despite all that, Java is not special. It should run on Gentoo for
anyone who wants it, just like things starting with P.

You volunteering to do the grunt work?

-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-dev] Re: Packages up for grabs

[Patrick Lauer]

On 08/07/2016 10:04 PM, Alan McKinnon wrote:
> On 07/08/2016 19:36, james wrote:
>>> The interesting apps out there are mostly running python, go and
>>> (sometimes) lua. And that's what I observe in my day job -
>>> business/mobile ISP.
>>
>>
>> Look at the job listing on stackoverflow and elsewhere (java) is very
>> popular when they list several programming languages to meet the
>> requirements. I'm not promoting java, at all, but just stating that it
>> is very popular, on new projects (but not all) and it is a large and
>> frequent requirement, dictating by employers. Kids coming out of college
>> want a job, more than anything, and most are having java crammed down
>> their throats. So we should  find a way to robustly
>> support those that need java. Nothing is precluding other languages
>> in my message. Personally I avoid java, unless it is critical to
>> a code or family of codes I need to run.
> 
> 
> I recommend Java as a teaching language at university level.

I've seen the fallout from trying to do that.

It's a horribly bad idea ...

> You get all the benefits of a C-like syntax without the overhead of
> learning to deal with C and/or C++. You don't have to deal with the
> toolchain (much), you can easily show correct implementations of OOP
> style without getting into generics (or, you can avoid Java generics
> altogether at this level and pretend they don't exist).

Java and OOP ? If you want to do things right, best to use something
proper like Eiffel or Oberon. And Java will be most excellent at
teaching about pointers (but there are no pointers!) to maximize the
learning curve gradient ...

On the upside your students will learn useless incantations along the
lines of "publicstaticvoidmain!" that they can't explain and copypasta :)

I've found these two a long time ago, and they still amuse me:

http://gentooexperimental.org/~patrick/keywords.java.txt
http://gentooexperimental.org/~patrick/helloworld.java.txt


> In short, what's not to like for teaching? All win not much lose.
> 
> Well OK some kids come away thinking Java is the one and only, but they
> will have that too if Python is the teaching language. Realizing there
> are other things out there is part of the learning process.
> 
> But, despite all that, Java is not special. It should run on Gentoo for
> anyone who wants it, just like things starting with P.
> 
> You volunteering to do the grunt work?
> 

Java works pretty well on Gentoo, I'm not quite sure what needs to be
fixed ... I mean, apart from our insane idea to "build from source"
which doesn't fit with the existing structures in the java ecosystem

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 03:04 PM, Alan McKinnon wrote:
> On 07/08/2016 19:36, james wrote:
>>> The interesting apps out there are mostly running python, go and
>>> (sometimes) lua. And that's what I observe in my day job -
>>> business/mobile ISP.
>>
>>
>> Look at the job listing on stackoverflow and elsewhere (java) is very
>> popular when they list several programming languages to meet the
>> requirements. I'm not promoting java, at all, but just stating that it
>> is very popular, on new projects (but not all) and it is a large and
>> frequent requirement, dictating by employers. Kids coming out of college
>> want a job, more than anything, and most are having java crammed down
>> their throats. So we should  find a way to robustly
>> support those that need java. Nothing is precluding other languages
>> in my message. Personally I avoid java, unless it is critical to
>> a code or family of codes I need to run.
>
>
> I recommend Java as a teaching language at university level.
>
> You get all the benefits of a C-like syntax without the overhead of
> learning to deal with C and/or C++. You don't have to deal with the
> toolchain (much), you can easily show correct implementations of OOP
> style without getting into generics (or, you can avoid Java generics
> altogether at this level and pretend they don't exist).
>
> In short, what's not to like for teaching? All win not much lose.

I guess folks do not prototype new hardware (dev boards) and sit with an 
EE to exercise hardware and peripherals to get them burned in, working 
and basic drive code working, or yall do that is java at your U?

This sort of thing in done on a fpga too, at your U? Are you on the 
engineering side or the business side of the campus? (just curious).


>
> Well OK some kids come away thinking Java is the one and only, but they
> will have that too if Python is the teaching language. Realizing there
> are other things out there is part of the learning process.
>
> But, despite all that, Java is not special. It should run on Gentoo for
> anyone who wants it, just like things starting with P.
>
> You volunteering to do the grunt work?
>

I'm actually too stupid work on java. I need a new java-moral-compass.
Besides,  I'm knee deep into automating a way to put  minimal, hardened 
gentoo onto a variety of platforms, with a few keystrokes (guidance, 
suggestions and leadership are appreciated). Most of the pieces exist, 
but I fear I have installa-dyslexia syndrome.


After that feat is accomplished, then a  similar deployment of a gentoo 
cluster on a those just installed gentoo minimal images, via a few 
keystrokes (I am flexible on the cluster codes that comprise the 
cluster). Then (only after those 2 things are robustly accomplished) I 
do intend to return to my java travails (search out bgo, as I have a 
long love-hate relationship with java on gentoo).....


hth,
James

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 03:48 PM, Patrick Lauer wrote:

> Java works pretty well on Gentoo, I'm not quite sure what needs to be
> fixed ... I mean, apart from our insane idea to "build from source"
> which doesn't fit with the existing structures in the java ecosystem

Wow!. Patrick, you are my hero. I have an old couple of (java-centric) 
bugs in bgo that maybe you could take a quick look at the attached 
ebuilds and either fix them or send me a guildline how to fix them? Both 
have ebuilds attached. But if you can fix them, it'd be trivial to also 
get the latest stable release of those cluster centric java 
nightmares.... I would not even care if they reside in an overlay 
somewhere, as gentoo tree acceptance is often a pilgrimage.

They are very popular codes, just so you know, so you are talking about
becoming gentoo-legend......   I'd even be willing to proxy them after 
they are fixed, or with a mentor that knows more about java than I. 
(that's not difficult at all).


BGO-510912 (Apache-Mesos)   and BGO-523412 (Apache-Spark)

Publicly or privately, you'd get much more than my gratitude...
(seriously).

I also use euscan frequently (just so you know).


curiously,
James

Re: [gentoo-dev] Re: Packages up for grabs

[Kent Fredric]

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

On Sun, 7 Aug 2016 16:49:01 -0500
james <garftd@verizon.net> wrote:

> After that feat is accomplished, then a  similar deployment of a
> gentoo cluster on a those just installed gentoo minimal images, via a
> few keystrokes (I am flexible on the cluster codes that comprise the 
> cluster). Then (only after those 2 things are robustly accomplished)
> I do intend to return to my java travails (search out bgo, as I have
> a long love-hate relationship with java on gentoo).....

I think its probably worth mentioning that there are likely problems
Gentoo faces around Java that are of a legal manner, not merely
technical.

Like for instance, the fact you can't install the official Orcale/Sun
JDK/JRE automatically is due to the fact:

- They prohibit replication/mirroring
- Their website requires a license agreement acceptance to download

And the latter of these is /plausible/ to automate via curl and some
"Set cookies" magic ( apparently arch do this ), but falls into a legal
grey area.


If this is a problem we have simply downloading and installing, I'd
imagine there are other problems we face having it on ready-to-go media.

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

Re: [gentoo-dev] Re: Packages up for grabs

[Kent Fredric]

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

On Mon, 8 Aug 2016 00:26:01 -0500
james <garftd@verizon.net> wrote:

>  so it is paused for a licensed 
> download, as necessary, is not a show stopper

The problem is that download requires a Browser with JavaScript
support, because it requires JavaScript to set a cookie, and that
cookie activates the download working.

Which means if your installer is for instance, Curses based, you're
pretty much out-of-luck.

"Please open browser at this point, but we don't have a working desktop
environment yet to do this" is a bit of a hard problem.

"You need 2 computers to install this" is also a bit of a problem.

So installing Java would have to be done /after/ the install.

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

Re: [gentoo-dev] Re: Packages up for grabs

[james]

On 08/07/2016 10:22 PM, Kent Fredric wrote:
> On Sun, 7 Aug 2016 16:49:01 -0500
> james <garftd@verizon.net> wrote:
>
>> After that feat is accomplished, then a  similar deployment of a
>> gentoo cluster on a those just installed gentoo minimal images, via a
>> few keystrokes (I am flexible on the cluster codes that comprise the
>> cluster). Then (only after those 2 things are robustly accomplished)
>> I do intend to return to my java travails (search out bgo, as I have
>> a long love-hate relationship with java on gentoo).....
>
> I think its probably worth mentioning that there are likely problems
> Gentoo faces around Java that are of a legal manner, not merely
> technical.
>
> Like for instance, the fact you can't install the official Orcale/Sun
> JDK/JRE automatically is due to the fact:
>
> - They prohibit replication/mirroring
> - Their website requires a license agreement acceptance to download
>
> And the latter of these is /plausible/ to automate via curl and some
> "Set cookies" magic ( apparently arch do this ), but falls into a legal
> grey area.
>
>
> If this is a problem we have simply downloading and installing, I'd
> imagine there are other problems we face having it on ready-to-go media.
>

So the minimal default automated installs would not carry java code; OK.
Yep, traversing the install semantics, so it is paused for a licensed 
download, as necessary, is not a show stopper. I'm pretty sure I  used
maven, sbt, icedtea and  curl for these cluster ebuilds in question; 
Apache-Mesos and Apache-Spark. There are hacked ebuilds in BGO. I'm 
pretty sure Mesos was reorganized so all the third party stuff  are 
modular  in such a fashion that the issues you point out have legal 
install solution. In fact Mesos is purported to almost all C++ code
now and the other languages issue are not part ot the core of Mesos,
or something to that effect I read somewhere.


I'm no java expert, so surely a dev with that sort of expertise could 
take a look, and fix them or give me guidance. Mesos installs. My 
Apache-spark ebuild needed some manual fiddling with sbt, during the 
install to get it to install to Spark, so it is a bit broken. 
Apache-Spark is a bit more complex, but it has progressed to version 
2.0, since I hack an ebuild for 1.5. Tons of folks ((big opensource 
projects) use them, so surely there is a way to solve these issues, for 
devs with that sort of knowledge and meet gentoo standards?

BGO-510912 (Apache-Mesos)   and BGO-523412 (Apache-Spark)


Thanks,
James

Re: [gentoo-dev] Re: Packages up for grabs

[Kent Fredric]

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

On Mon, 8 Aug 2016 16:33:15 +1200
Kent Fredric <kentnl@gentoo.org> wrote:

> >  so it is paused for a licensed 
> > download, as necessary, is not a show stopper  
> 
> The problem is that download requires a Browser with JavaScript
> support, because it requires JavaScript to set a cookie, and that
> cookie activates the download working.
> 
> Which means if your installer is for instance, Curses based, you're
> pretty much out-of-luck.
> 
> "Please open browser at this point, but we don't have a working
> desktop environment yet to do this" is a bit of a hard problem.
> 
> "You need 2 computers to install this" is also a bit of a problem.
> 
> So installing Java would have to be done /after/ the install.

Scratch this.

Just use iced-tea JDK by default. People who want oracle can do the
extra work.

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

[gentoo-dev] Re: Packages up for grabs

[Marek Szuba]

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

On 2017-03-26 21:50, aidecoe@gentoo.org wrote:

> app-backup/burp
I'll grab this one unless anyone minds.

-- 
MS


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

[gentoo-dev] Re: Packages up for grabs

[Dirkjan Ochtman]

On Thu, Apr 27, 2017 at 12:58 PM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> I also want to drop the following:
>
> - dev-lang/erlang
> - dev-vcs/hgsubversion

I'll drop these to maintainer-needed by July 1st.

Cheers,

Dirkjan

[gentoo-dev] Re: Packages up for grabs

[Michael Palimaka]

On 03/11/2018 12:12 AM, Pacho Ramos wrote:
> This packages are now up for grabs:
...
> net-irc/unrealircd

I can take this one.