[gentoo-dev] Packages up for grabs

[gentoo-dev] Packages up for grabs

[Chris Gianelloni]

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

I maintain a few packages where I either no longer have the hardware or
no longer have appropriate access to test the packages.  Because of
this, I am looking to find a maintainer for the following packages.

These three go together, but I don't have the hardware to test them and
SeJo has gone MIA since I put these in the tree.  ;]

sys-auth/tfm-fingerprint
sys-auth/pam_bioapi
sys-auth/bioapi

These two are both Cisco tools requiring Cisco hardware at least on one
end.  I do have a PIX, but I do not have a CCO account, so getting
updated versions of the VPN client has been a pain for me for a while.
The Aironet Client Utilities are simple to maintain, as it is simply a
gtk+-1 application and hasn't had a new version in ages.

net-misc/cisco-aironet-client-utils
net-misc/cisco-vpnclient-3des

I had already asked for someone else to take these, but never got any
response.

net-misc/icaclient
net-misc/tsclient

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

[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 --]

Re: [gentoo-dev] Packages up for grabs

[Mike Frysinger]

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

On Wednesday 05 September 2007, Chris Gianelloni wrote:
> These three go together, but I don't have the hardware to test them and
> SeJo has gone MIA since I put these in the tree.  ;]
>
> sys-auth/tfm-fingerprint
> sys-auth/pam_bioapi
> sys-auth/bioapi

i have a laptop with this cruft and i use it, so i'll take em
-mike

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

Re: [gentoo-dev] Packages up for grabs

[Eldad Zack]

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

On Wednesday 05 September 2007, Chris Gianelloni wrote:
> I maintain a few packages where I either no longer have the hardware or
> no longer have appropriate access to test the packages.  Because of
> this, I am looking to find a maintainer for the following packages.

> These two are both Cisco tools requiring Cisco hardware at least on one
> end.  I do have a PIX, but I do not have a CCO account, so getting
> updated versions of the VPN client has been a pain for me for a while.
> The Aironet Client Utilities are simple to maintain, as it is simply a
> gtk+-1 application and hasn't had a new version in ages.
>
> net-misc/cisco-aironet-client-utils
> net-misc/cisco-vpnclient-3des

I can take net-misc/cisco-vpnclient-3des, I have a CCO account, and I'm 
currently using it.

Though there wasn't a new version out for a long time, so the current package 
is still valid.


-- 
Eldad Zack <eldad@gentoo.org>
Key/Fingerprint at pgp.mit.edu, ID 0x96EA0A93

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

Re: [gentoo-dev] Packages up for grabs

[Chris Gianelloni]

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

On Thu, 2007-09-06 at 23:16 +0300, Eldad Zack wrote:
> On Wednesday 05 September 2007, Chris Gianelloni wrote:
> > I maintain a few packages where I either no longer have the hardware or
> > no longer have appropriate access to test the packages.  Because of
> > this, I am looking to find a maintainer for the following packages.
> 
> > These two are both Cisco tools requiring Cisco hardware at least on one
> > end.  I do have a PIX, but I do not have a CCO account, so getting
> > updated versions of the VPN client has been a pain for me for a while.
> > The Aironet Client Utilities are simple to maintain, as it is simply a
> > gtk+-1 application and hasn't had a new version in ages.
> >
> > net-misc/cisco-aironet-client-utils
> > net-misc/cisco-vpnclient-3des
> 
> I can take net-misc/cisco-vpnclient-3des, I have a CCO account, and I'm 
> currently using it.

Cool.  I switched jobs (twice, actually) since I started maintaining
this and don't have a CCO account anymore.

> Though there wasn't a new version out for a long time, so the current package 
> is still valid.

Yeah, there's no open bugs that need to be fixed.  There's an
enhancement bug, but I'll leave that to you to decide.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Foundation Trustee
Gentoo Foundation

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

Re: [gentoo-dev] Packages up for grabs

[Paul de Vrieze]

On Thu, 6 Sep 2007 03:15:34 Chris Gianelloni wrote:
> net-misc/cisco-vpnclient-3des

While my current employer uses such a router, I find that the vpnc client 
works "better" in that it does not force me to route all traffic through the 
vpn, but allows me to make my own routes. Of course vpnc does not require 
binary kernel modules either.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Packages up for grabs

[Chris Gianelloni]

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

On Sat, 2007-09-08 at 09:41 +1000, Paul de Vrieze wrote:
> On Thu, 6 Sep 2007 03:15:34 Chris Gianelloni wrote:
> > net-misc/cisco-vpnclient-3des
> 
> While my current employer uses such a router, I find that the vpnc client 
> works "better" in that it does not force me to route all traffic through the 
> vpn, but allows me to make my own routes. Of course vpnc does not require 
> binary kernel modules either.

I know about vpnc, but it doesn't support all of the features of the
Cisco official client.  Also, the Cisco VPN Client does *not* use binary
kernel modules.  The *client* is binary, the modules are source-based.
Also, there's a patch in Bugzilla to add local LAN access support to the
client, even if it is denied on the server side.  I haven't decided if I
am going to add the patch or not, since it does allow the client to
perform actions that could violate a company's security policy.  Of
course, if someone else were maintaining it, it would be their decision
to make.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

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

[gentoo-dev] Packages up for grabs

[Christian Heim]

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-admin/chrpath
 - app-admin/fam
 - app-admin/otpcalc
 - app-admin/skey
 - app-admin/sudo
 - app-admin/tripwire
 - app-arch/advancecomp
 - app-arch/lha
 - app-arch/undms
 - app-arch/xdms
 - app-dicts/eblook
 - app-dicts/ebview
 - app-dicts/kannadic
 - app-editors/teco
 - app-emulation/aranym
 - app-emulation/sheepshaver
 - app-emulation/uae
 - app-emulation/x48
 - app-i18n/man-pages-cs
 - app-misc/away
 - app-misc/cadubi
 - app-misc/mvcase
 - app-misc/pwsafe
 - app-misc/sl
 - app-office/magicpoint
 - app-shells/ksh
 - app-shells/zsh-completion
 - app-text/antiword
 - app-text/bact
 - app-text/cmigemo
 - app-text/convertlit
 - app-text/crf++
 - app-text/cwtext
 - app-text/diction
 - app-text/freepwing
 - app-text/pep
 - app-text/rhyme
 - app-text/wscr
 - dev-java/scala-bin
 - dev-lang/stratego
 - dev-libs/aterm
 - dev-libs/eb
 - dev-libs/hashit
 - dev-libs/sdf2-bundle
 - dev-libs/shhopt
 - dev-util/aegis
 - dev-util/ccache
 - dev-util/ccmalloc
 - dev-util/cocom
 - dev-util/cook
 - dev-util/pmk
 - dev-util/pretrace
 - dev-util/rec
 - dev-util/scanmem
 - dev-util/skelgen
 - media-gfx/f-spot
 - media-gfx/optipng
 - media-gfx/potrace
 - media-gfx/w3mimgfb
 - media-gfx/zphoto
 - media-libs/libdc1394
 - media-video/coriander
 - media-video/kdenlive
 - net-dns/resolvconf-gentoo
 - net-firewall/fwipsec
 - net-fs/coda-kernel
 - net-ftp/ftpbase
 - net-ftp/vsftpd
 - net-im/tmsnc
 - net-misc/knock
 - net-misc/ndtpd
 - net-misc/netprofiles-ims
 - net-misc/pump
 - net-misc/putty
 - net-misc/secpanel
 - net-misc/snarf
 - net-misc/wget
 - net-misc/ytalk
 - net-wireless/rt2x00
 - sci-libs/libsvm
 - sys-apps/netplug
 - www-apps/bugport
 - www-client/dillo
 - www-client/surfraw
 - x11-misc/periodic-calendar
 - x11-misc/xdesktopwaves
 - x11-misc/xse
 - x11-terms/rxvt
 - x11-terms/xvt

I'm gonna write a seperate mail regarding packages dumped onto the herds
without a dedicated maintainer remaining.

Regards,

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

Re: [gentoo-dev] Packages up for grabs

[Gilles Dartiguelongue]

Le mardi 25 décembre 2007 à 18:19 +0000, Christian Heim a écrit :
> 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...
> 

if noones wants them, I'll take the following:

>  - app-admin/sudo
 but probably belongs to base-system
>  - dev-util/ccache
 but probably belongs to toolchain

and finally,
>  - 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.

-- 
Gilles Dartiguelongue <eva@gentoo.org>
Gentoo

--
gentoo-dev@gentoo.org mailing list

[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] Packages up for grabs

[Krzysiek Pawlik]

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


There are few packages that could use some more loving:

  * app-editors/scite - easy to maintain, has only one bug open wrt French 
locales & UTF-8
  * media-video/griffith - also easy, pending version bump
  * net-im/jabberd & net-im/jabberd2 - thanks to work from Marko Durkovic both 
are easy to maintain

-- 
Krzysiek Pawlik   <nelchael at gentoo.org>   key id: 0xBC555551
desktop-misc, java, apache, ppc, vim, kernel, python...


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

[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] packages up for grabs

[Mike Frysinger]

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

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.

no herd:
app-admin/durep
app-arch/deltarpm
app-arch/gtk-splitter
app-arch/tardy
app-shells/rssh
app-text/doclifter
dev-lang/cm3-bin
dev-libs/libhash
dev-libs/libmix
dev-libs/libtomcrypt
dev-libs/libtomfloat
dev-libs/libtommath
dev-libs/libtompoly
dev-libs/tomsfastmath
dev-util/elfsh
dev-util/ghh
net-ftp/glftpd
net-ftp/ncftp
net-libs/libvncserver
net-misc/vnc
net-misc/aget
sys-boot/psoload

media-optical herd:
app-cdr/bin2iso
app-cdr/ccd2iso
app-cdr/plextor-tool
app-cdr/pxlinux

base-system herd:
app-arch/unace
app-editors/hexcurse
dev-libs/libedit
dev-util/cpuinfo-collection
net-misc/ntp
sys-apps/lcdsplash
sys-apps/netboot-base

embedded herd:
app-emulation/coldfire
dev-libs/matrixssl
net-misc/dropbear
sys-libs/uclibc

perl herd:
app-misc/gwine

sh herd:
dev-embedded/dc-tool-ip

graphics herd:
media-gfx/feh
media-gfx/wings
media-libs/amanith
media-libs/esdl
media-libs/giblib
media-libs/svgalib

video herd:
media-video/came
media-video/SDLcam

netmon herd:
net-analyzer/cryptcat
net-analyzer/ffp
net-analyzer/mping
net-analyzer/netcat6
net-libs/libnet
net-misc/netpipes
net-misc/pipes

net-dialup herd:
net-dialup/picocom

net-irc herd:
net-irc/bnc

net-mail herd:
net-mail/freepops

mobile herd:
sys-apps/i2c-tools

kernel-misc/toolchain herd:
sys-devel/sparse

m68k herd:
sys-fs/atari-fdisk

base-system/embedded herd:
sys-fs/mtd-utils

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

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

Re: [gentoo-dev] packages up for grabs

[Donnie Berkholz]

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

It would be good if someone took this, because a ton of people use it.

> net-misc/dropbear
> sys-libs/uclibc

I'd really like for someone to pick these up, since they're pretty 
critical for Gentoo on embedded systems.

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

[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

Re: [gentoo-dev] packages up for grabs

[Philip Webb]

080531 Mike Frysinger wrote:
> 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.
...
> net-misc/ntp

This is rather basic, isn't it ?  It keeps your clock accurate.
Is there any alternative ?

> media-gfx/feh

This is an excellent app & seems usually bug-free.
I hope someone keeps an eye on it.

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] packages up for grabs

[Thilo Bangert]

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


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

regards
Thilo

[-- Attachment #2: This is a digitally signed message part. --]
[-- 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

[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

[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] Packages up for grabs

[Christian Faulhammer]

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

Hi,

packages that are in a herd, but could need someone dedicated to it:

  app-portage/elogv, elogviewer, kelogviewer (tools-portage) -- low
maintenance

  dev-lang/erlang (lang-misc) -- a version bump now and then (four
times a year), seldomly but then obscure bugs, cooperative upstream

  mail-client/claws-mail and all plugins (net-mail) -- a version bump is
some work, but low rate of bugs, ken69267 is there to maintain, but he
maybe needs a helping hand

  sci-visualization/gnuplot (sci) -- revamped, not much work left, low
maintenance usually

  sys-apps/mlocate (base-system) -- low maintenance, cooperative
upstream 




Packages that maybe go into maintainer-needed:

  app-admin/hwreport -- just noticed, it needs a version bump, low
maintenance

  app-admin/tmpwatch -- low maintenance

  dev-cpp/libthrowable,
  app-portage/gatt -- very cooperative upstream for both (mlangc for
both)

  app-text/rnv
  sys-apps/einit
  sys-apps/einit-modules-xml
  sys-apps/einit-modules-scheme -- all four are running on proxy, low
maintenance

  media-sound/cmus --  low maintenance

  net-misc/icaclient -- low maintance

  net-misc/vpnc -- low maintenance, cooperative upstream  

  x11-misc/gaia -- low maintenance, has to do with its non-functionality

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

Re: [gentoo-dev] Packages up for grabs

[Alexis Ballier]

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

Hi,

>   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

>   mail-client/claws-mail and all plugins (net-mail) -- a version bump
> is some work, but low rate of bugs, ken69267 is there to maintain,
> but he maybe needs a helping hand

Never had any problem with it, I'm using it as my mail client on
several boxes, if you or Kenneth need any specific help, feel free to
poke me/cc me on bugs.

>   media-sound/cmus --  low maintenance

can probably be dropped to sound


I hope that doesn't mean you're planning to retire ;p

Alexis.

[-- 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: 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 --]

Re: [gentoo-dev] Packages up for grabs

[Thomas Anderson]

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

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

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

[-- Attachment #2: 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] packages up for grabs

[Daniel Drake]

Hi,

I want to devote more time to the kernel project and other things, so 
I'm looking for people or herds to take ebuild maintainership of the 
following packages:

dev-dotnet/gsf-sharp
dev-dotnet/evolution-sharp
dev-util/rej
net-wireless/zd1211-firmware
sys-block/viaideinfo
sys-fs/udftools
x11-misc/touchcal

any volunteers? :)
Otherwise I'll push them towards maintainer-needed in a couple of weeks 
time.

Thanks,
Daniel

[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] Packages up for grabs

[Santiago M. Mola]

Hello,

All my packages are up for grabs. Feel free to add yourself to
metadata.xml and don't hesitate to ask me any doubts about them.

Telepathy stuff
---------------
dev-util/telepathy-inspector (low maintainance)
dev-python/pymsn
net-im/empathy
net-im/telepathy-mission-control
net-irc/telepathy-idle
net-voip/telepathy-butterfly
net-voip/telepathy-haze

Packages that I've been taking care of and could use a maintainer:
net-libs/telepathy-glib (frequent bumps)
net-voip/telepathy-gabble (frequent bumps)

Other stuff
-----------
app-text/xmldiff (maintainance close to zero)
app-vim/exheres-syntax
games-arcade/whichwayisup (low maintainance)
media-tv/w_scan (low maintainance)
media-libs/libdiscid (dep of picard)
media-sound/last-exit
media-sound/picard
media-video/qc-usb-messenger (semi-inactive upstream, users send patches
for new kernels)
net-p2p/lince
net-p2p/museek+
x11-misc/dzen (low maintainance)
x11-misc/lsw (maintainance close to zero)

Packages that I've been taking care of and could use a maintainer:
app-shells/bash-completion
net-p2p/nicotine+

Best regards,
-- 
Santiago M. Mola
Jabber ID: cooldwind@gmail.com

[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] Packages up for grabs

[Markos Chandras]

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

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. 

Thank you
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

[-- Attachment #2: Type: application/pgp-signature, Size: 198 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] Packages up for grabs

[Christian Faulhammer]

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

Hi,

I would like to drop some packages that I do not use or really care for:

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.

app-text/rnv
 Near to no maintenance work.

dev-libs/qof
 Very little maintenance.

net-misc/tor
 A bump here and there (especially security fixes).  Upstream really
nice, there were user requests for beta ebuilds which I have no time to
provide.

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] Packages up for grabs

[Dirkjan Ochtman]

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.

Cheers,

Dirkjan

[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 --]

Re: [gentoo-dev] Packages up for grabs

[Sebastian Pipping]

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.



Sebastian

[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] Packages up for grabs

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

Due to lack of time and motivation, the following packages are up for
grabs:

	app-backup/fsarchiver
	app-cdr/daa2iso
	app-cdr/gaffitter
	app-crypt/md6sum
	app-laptop/batti
	app-laptop/omnibook
	app-laptop/prey
	app-misc/goobook
	app-misc/recoll
	app-misc/utimer
	app-mobilephone/jacksms-desktop
	app-text/antiword
	app-text/chm2pdf
	app-text/odt2txt
	app-text/pdfminer
	app-text/u2ps
	dev-embedded/libdisasm
	dev-lang/jimtcl
	dev-libs/json-c
	dev-libs/libestr
	dev-libs/libmail
	dev-libs/log4shib
	dev-python/hcs-utils
	dev-python/nltk
	dev-python/py-notify
	dev-util/ticpp
	games-misc/xcowsay
	gnome-extra/nautilus-dropbox
	mail-client/nmh
	media-gfx/mypaint
	media-libs/liblqr
	media-libs/libmetalink
	media-sound/fluid-soundfont
	media-sound/musique
	media-sound/wildmidi
	media-video/get_flash_videos
	media-video/griffith
	media-video/imagination
	media-video/rtmpdump
	net-analyzer/arpon
	net-analyzer/bwping
	net-analyzer/ncrack
	net-analyzer/netwatch
	net-misc/gns3
	net-misc/mulk
	net-misc/sitecopy
	net-misc/sshpass
	net-misc/ttytter
	net-misc/wakeonlan
	net-misc/wol
	net-news/canto
	net-p2p/torrentinfo
	sci-electronics/gresistor
	sys-apps/cpuid
	sys-apps/daemonize
	sys-apps/pyrenamer
	sys-apps/stroke
	sys-apps/syslog-notify
	sys-apps/ultracopier
	sys-fs/e4rat
	sys-fs/fuse-zip
	sys-fs/lessfs
	sys-fs/treesize
	sys-kernel/pf-sources
	sys-kernel/zen-sources
	www-servers/lighttpd
	x11-misc/bmpanel
	x11-misc/fpm2
	x11-misc/googsystray
	x11-plugins/qled

The list contains only the packages that are maintained by me but not
co-maintained by another herd. Some of them may be maintained by
multiple people though so double check with them before you add
yourself as maintainer. I will not remove myself from metadata anytime
soon but I want people to help me offload some of my packages.

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iQIcBAEBCgAGBQJPT/VoAAoJEPqDWhW0r/LCadgQAKTu6O5Z+UY/xIzKmyt+4w7A
jME5Cw4o67gHTkuI1QQq7H0C16L4oulsutbC8szcndzm/K5DspOg//bPZfFlN7ov
SmoRbj0Hgadawcm6qzyZOhFJCG7mOZDzmfcBXRHs8iz4NZfs+k2Tx+4m9RnPiCge
57u+36lXGV72twIY907kMXMvi19P3mIIgah6NRwXNiDdYYx/FnjCisFmaJTgmVb0
j0eyvW8mvUZcXgFE3OVdr0xwdBSZc43973/50VUY1zf8Z47E4fUWHXT/CFyB/wbd
eVA1cCg2rmmx2Z8gqssWk2ZSvRTUSjTckWCEld2Q+t+d1aeGeODQiuBfL3MIr6JY
42wI/I5TPtgqQFdp5pnbT7IQLBUt84naUCVv0iyhYjVG3mBOw0H+b2MyRJe8OdSN
98EF1qDljqtxp3owOLRJUthztxgBKysLicX2vHBdGqLV4SezPp00HX66C1XMGcp0
piLF4gSn1lxDK1scMuFPGWQbGrt0WCk9XSBz32qx3t8+3ve0Xj7F8Xy9kk/bLTmv
ySlYMZ7rSVQShlpMuDnKsIZ9bs4KVheszuRyPVZYRt9Y/itji3MYwcoahL429kKz
cEA3sNL+8zv53cr96vbm5mDyOjarjgwRmkk5E2/JYFsZfvKy34zpHKZePkEzox/n
a3Qz2jfKELsBBMlf/yCa
=nwnT
-----END PGP SIGNATURE-----

[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] Packages up for grabs

[Pacho Ramos]

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

Due swegener focusing in less packages until he has more time:
x11-misc/x11vnc -> maybe net-libs/libvncserver could be interested in
this


[-- Attachment #2: This is a digitally signed message part --]
[-- 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 ramereth lack of time:
sys-block/megacli
net-misc/stunnel
app-admin/mcollective

RE: [gentoo-dev] Packages up for grabs

[gmt]

On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped:
> Due ramereth lack of time:
> net-misc/stunnel

Pretty sure my (dead, eventually to be revived) server uses stunnel.  I've never officially maintained anything, is there some documentation somewhere as to what exactly I'm agreeing to, if I take on proxy maintainer-ship?  Also, of how proxy maintainer-ship actually works?  I.e.: would I need some particular person to agree to be my commit-bitch or can I just sign off on patches, somehow, and expect a pool of commit-bitches to magically push commits for me?

-gmt

Re: [gentoo-dev] Packages up for grabs

[Pacho Ramos]

El dom, 16-06-2013 a las 05:19 -0700, gmt@malth.us escribió:
> On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped:
> > Due ramereth lack of time:
> > net-misc/stunnel
> 
> Pretty sure my (dead, eventually to be revived) server uses stunnel.  I've never officially maintained anything, is there some documentation somewhere as to what exactly I'm agreeing to, if I take on proxy maintainer-ship?  Also, of how proxy maintainer-ship actually works?  I.e.: would I need some particular person to agree to be my commit-bitch or can I just sign off on patches, somehow, and expect a pool of commit-bitches to magically push commits for me?
> 
> -gmt
> 

I think you will need to simply contact proxy-maint people (CCing them)
http://www.gentoo.org/proj/en/qa/proxy-maintainers/

RE: [gentoo-dev] Packages up for grabs

[gmt]

On Sun, 16 Jun 2013, at 05:27, Pacho Ramos thusly quipped:

> El dom, 16-06-2013 a las 05:19 -0700, gmt@malth.us escribió:
>> On Sun, 16 Jun 2013, at 02:31, Pacho Ramos thusly quipped:
>>> Due ramereth lack of time:
>>> net-misc/stunnel
>> 
>> Pretty sure my (dead, eventually to be revived) server uses stunnel.  I've never
> officially maintained anything, is there some documentation somewhere as to
> what exactly I'm agreeing to, if I take on proxy maintainer-ship?  Also, of how
> proxy maintainer-ship actually works?  I.e.: would I need some particular person
> to agree to be my commit-bitch or can I just sign off on patches, somehow, and
> expect a pool of commit-bitches to magically push commits for me?
>> 
>> -gmt
>> 
> 
> I think you will need to simply contact proxy-maint people (CCing them)
> http://www.gentoo.org/proj/en/qa/proxy-maintainers/

Maybe I shouldn't do this just yet.  I need to figure out whether the box in question gets its stunnel from gentoo or some other distribution (it has a severe multiple personality disorder).

If I take on maintainer-ship and it turns out I don't actually use the ebuild in-house, dereliction of duty on my part is almost an inevitability.  On the other hand, if I am relying on the ebuild, I'll almost certainly want to proxy-maintain, once I get my hardware issues sorted out.  There'd be no problem resurrecting it from the grave, if need be, would there?

-gmt

[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

[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)

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

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

[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 --]

[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] 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] 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] 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 --]

[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] Packages up for grabs

[Pacho Ramos]

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

[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 

[gentoo-dev] Packages up for grabs

[Pavlos Ratis]

Hello all,

Due to lack of time I'm giving up some packages. Feel free to take them.
I'll remove myself from metadata in the following packages within 10 days:

* app-admin/cronolog
* app-misc/recoll
* app-shells/sash
* dev-vcs/mr
* dev-vcs/vcsh
* net-analyzer/portbunny
* net-libs/udns

Comaintained packages(herds,devs):

*  app-admin/denyhosts
*  dev-python/tweepy
*  kde-misc/kimtoy
*  kde-misc/plasma-network-status
*  net-im/turses

I will also drop myself from the net-proxy herd.

Thanks,
Pavlos Ratis

Re: [gentoo-dev] Packages up for grabs

[Tom Wijsman]

On Tue, 11 Nov 2014 16:59:46 +0200
Pavlos Ratis <dastergon@gentoo.org> wrote:

> I will also drop myself from the net-proxy herd.

Drawing extra attention to this sentence; it looks like the herd is
(once again) going to be empty, as the result of a lack of interest.

If someone does have a real interest in this herd; please step up now,
otherwise this herd is probably going to face a removal in the future.

Re: [gentoo-dev] Packages up for grabs

[Pacho Ramos]

El vie, 14-11-2014 a las 04:02 +0100, Tom Wijsman escribió:
> On Tue, 11 Nov 2014 16:59:46 +0200
> Pavlos Ratis <dastergon@gentoo.org> wrote:
> 
> > I will also drop myself from the net-proxy herd.
> 
> Drawing extra attention to this sentence; it looks like the herd is
> (once again) going to be empty, as the result of a lack of interest.
> 
> If someone does have a real interest in this herd; please step up now,
> otherwise this herd is probably going to face a removal in the future.
> 

I will probably remove it in a week or so as looks like nobody added to
it :/

Re: [gentoo-dev] Packages up for grabs

[Pacho Ramos]

El lun, 01-12-2014 a las 12:00 +0100, Pacho Ramos escribió:
> El vie, 14-11-2014 a las 04:02 +0100, Tom Wijsman escribió:
> > On Tue, 11 Nov 2014 16:59:46 +0200
> > Pavlos Ratis <dastergon@gentoo.org> wrote:
> > 
> > > I will also drop myself from the net-proxy herd.
> > 
> > Drawing extra attention to this sentence; it looks like the herd is
> > (once again) going to be empty, as the result of a lack of interest.
> > 
> > If someone does have a real interest in this herd; please step up now,
> > otherwise this herd is probably going to face a removal in the future.
> > 
> 
> I will probably remove it in a week or so as looks like nobody added to
> it :/
> 
> 

Done, this packages are now up for grabs:
net-analyzer/squidview
net-libs/libecap
net-proxy/3proxy
net-proxy/adzapper
net-proxy/bfilter
net-proxy/c-icap-modules
net-proxy/dansguardian
net-proxy/dante
net-proxy/dnsproxy
net-proxy/havp
net-proxy/http-replicator
net-proxy/httpush
net-proxy/ntlmaps
net-proxy/nylon
net-proxy/oops
net-proxy/pingtunnel
net-proxy/polipo
net-proxy/privoxy
net-proxy/ratproxy
net-proxy/squidguard
net-proxy/squirm
net-proxy/sshproxy 
net-proxy/tinyproxy
net-proxy/tsocks
net-proxy/webscarab

Re: [gentoo-dev] Packages up for grabs

[Andrew Savchenko]

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

Hi,

On Wed, 07 Jan 2015 15:06:08 +0100 Pacho Ramos wrote:
> El lun, 01-12-2014 a las 12:00 +0100, Pacho Ramos escribió:
[...]
> > I will probably remove it in a week or so as looks like nobody added to
> > it :/
> 
> Done, this packages are now up for grabs:

> net-proxy/pingtunnel
> net-proxy/polipo
> net-proxy/privoxy
> net-proxy/tsocks

I'll take them if there are no other people interested.
If you are — feel free to add yourself to maintainers :)

Best regards,
Andrew Savchenko

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

[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] Packages up for grabs

[hasufell]

packages up for grab:

I didn't change metadata.xml, nor bug reports for any of those, because
I was too lazy. If you grab one, please do so yourself.


app-admin/clustershell
app-admin/durep
app-admin/hardinfo
app-backup/qt4-fsarchiver
app-emulation/vboxgtk
app-misc/trash-cli
app-text/keepnote
dev-libs/angelscript
dev-libs/libRocket
dev-libs/mathjax
dev-python/jedi
dev-python/pathlib
dev-python/pyutil
dev-python/simplegui
dev-python/zbase32
dev-python/zfec
dev-util/a8
dev-util/bluej
mail-client/geary
mail-filter/sieve-connect
media-gfx/nvidia-texture-tools
media-gfx/pinta
media-gfx/xpaint
media-sound/tudor-volumed
net-fs/tahoe-lafs
net-im/dianara
net-im/purple-events
net-libs/http-parser
net-misc/dropbox-cli
net-misc/gcap
net-misc/openconnect
net-misc/teamviewer
net-misc/youtube-viewer
net-p2p/pybitmessage
net-p2p/retroshare
sci-astronomy/skychart
sci-geosciences/harmonics-dwf-free
sci-geosciences/harmonics-dwf-free-noncomm
sci-geosciences/libtcd
sci-geosciences/osgearth
sci-geosciences/seawater
sci-geosciences/swmm
sci-geosciences/tappy
sci-geosciences/xtide
sci-libs/fplll
sci-mathematics/rstudio
sci-visualization/paraview
sys-apps/etckeeper
sys-apps/udevil
virtual/python-pathlib
www-apps/hiawatha-monitor
www-misc/profile-sync-daemon
www-servers/hiawatha
x11-misc/idesk-extras
x11-misc/obmenu-generator
x11-misc/spacefm

co-maintained by accessibility <accessibility@gentoo.org>
	app-accessibility/julius
	app-accessibility/pocketsphinx
	app-accessibility/simon

co-maintained by games <games@gentoo.org>
	dev-games/goatee
	dev-games/higan-ananke
	dev-games/mygui
	dev-games/t4k-common
	games-action/armagetronad
	games-action/awesomenauts
	games-action/beathazardultra
	games-action/brutal-legend
	games-action/hotline-miami
	games-action/intrusion2
	games-action/minetest
	games-action/minetest_game
	games-action/openclonk
	games-action/solar2
	games-action/super-hexagon
	games-action/swordandsworcery
	games-action/trine2
	games-action/trosh
	games-arcade/commandergenius
	games-arcade/dynamitejack
	games-arcade/mrrescue
	games-arcade/notpacman
	games-arcade/nottetris2
	games-arcade/opensonic
	games-arcade/retrobattle
	games-board/awale
	games-board/cockatrice
	games-board/goatee-gtk
	games-emulation/gambatte
	games-emulation/higan
	games-engines/odamex
	games-engines/residualvm
	games-engines/solarus
	games-engines/stratagus
	games-fps/duke3d-demodata
	games-fps/eduke32
	games-fps/turtlearena
	games-fps/urbanterror
	games-kids/crayon-physics
	games-misc/dont-starve
	games-misc/katawa-shoujo
	games-misc/little-inferno
	games-misc/lolcat
	games-misc/papers-please
	games-puzzle/larry
	games-puzzle/nightsky
	games-puzzle/splice
	games-puzzle/tiny-and-big
	games-roguelike/FTL
	games-roguelike/mazesofmonad
	games-rpg/bastion
	games-rpg/dear-esther
	games-rpg/dungeon-defenders
	games-rpg/freedink
	games-rpg/freedink-data
	games-rpg/grimrock
	games-rpg/mana
	games-rpg/manaplus
	games-rpg/penumbra-collection
	games-rpg/sumwars
	games-rpg/tmw
	games-rpg/to-the-moon
	games-rpg/valyriatear
	games-rpg/zsdx
	games-rpg/zsxd
	games-sports/dustrac
	games-strategy/dunelegacy
	games-strategy/freesynd
	games-strategy/ja2-stracciatella
	games-strategy/ja2-stracciatella-data
	games-strategy/liquidwar6
	games-strategy/megaglest
	games-strategy/megaglest-data
	games-strategy/s25rttr
	games-strategy/wargus
	games-strategy/wargus-data
	games-util/antimicro
	games-util/dfarc
	games-util/higan-purify
	games-util/lutris

co-maintained by ruby <ruby@gentoo.org>
	app-text/jist
	dev-ruby/paint

co-maintained by perl <perl@gentoo.org>
	dev-perl/Linux-DesktopFiles

co-maintained by sound <sound@gentoo.org>
	media-sound/gmusicbrowser
	media-sound/id3ted

co-maintained with Thomas Sachau <tommy@gentoo.org>
	net-libs/polarssl

co-maintained with Lars Wendler <polynomial-c@gentoo.org>
	media-sound/umurmur

co-maintained by net-im <net-im@gentoo.org>
	net-im/jabberd2

co-maintained with William Hubbs <williamh@gentoo.org>
	net-misc/badvpn

co-maintained with Patrick Lauer <patrick@gentoo.org>
	sci-mathematics/flint

co-maintained by x11 <x11@gentoo.org>
	x11-libs/libXaw3dXft

co-maintained by desktop-misc <desktop-misc@gentoo.org>
	x11-misc/cbatticon
	x11-misc/compton
	x11-misc/devilspie2
	x11-misc/menulibre
	x11-misc/obtheme
	x11-misc/wbar
	x11-misc/wbarconf

proxied for Alex Xu <alex_y_xu@yahoo.ca>
	x11-misc/x11vnc

Re: [gentoo-dev] Packages up for grabs

[Daniel Campbell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/23/2014 07:17 PM, hasufell wrote:
> packages up for grab:
> 
> I didn't change metadata.xml, nor bug reports for any of those,
> because I was too lazy. If you grab one, please do so yourself.
> 
> 
> app-admin/clustershell app-admin/durep app-admin/hardinfo 
> app-backup/qt4-fsarchiver app-emulation/vboxgtk app-misc/trash-cli 
> app-text/keepnote dev-libs/angelscript dev-libs/libRocket 
> dev-libs/mathjax dev-python/jedi dev-python/pathlib 
> dev-python/pyutil dev-python/simplegui dev-python/zbase32 
> dev-python/zfec dev-util/a8 dev-util/bluej mail-client/geary 
> mail-filter/sieve-connect media-gfx/nvidia-texture-tools 
> media-gfx/pinta media-gfx/xpaint media-sound/tudor-volumed 
> net-fs/tahoe-lafs net-im/dianara net-im/purple-events 
> net-libs/http-parser net-misc/dropbox-cli net-misc/gcap 
> net-misc/openconnect net-misc/teamviewer net-misc/youtube-viewer 
> net-p2p/pybitmessage net-p2p/retroshare sci-astronomy/skychart 
> sci-geosciences/harmonics-dwf-free 
> sci-geosciences/harmonics-dwf-free-noncomm sci-geosciences/libtcd 
> sci-geosciences/osgearth sci-geosciences/seawater 
> sci-geosciences/swmm sci-geosciences/tappy sci-geosciences/xtide 
> sci-libs/fplll sci-mathematics/rstudio sci-visualization/paraview 
> sys-apps/etckeeper sys-apps/udevil virtual/python-pathlib 
> www-apps/hiawatha-monitor www-misc/profile-sync-daemon 
> www-servers/hiawatha x11-misc/idesk-extras 
> x11-misc/obmenu-generator x11-misc/spacefm
> 
> co-maintained by accessibility <accessibility@gentoo.org> 
> app-accessibility/julius app-accessibility/pocketsphinx 
> app-accessibility/simon
> 
> co-maintained by games <games@gentoo.org> dev-games/goatee 
> dev-games/higan-ananke dev-games/mygui dev-games/t4k-common 
> games-action/armagetronad games-action/awesomenauts 
> games-action/beathazardultra games-action/brutal-legend 
> games-action/hotline-miami games-action/intrusion2 
> games-action/minetest games-action/minetest_game 
> games-action/openclonk games-action/solar2 
> games-action/super-hexagon games-action/swordandsworcery 
> games-action/trine2 games-action/trosh 
> games-arcade/commandergenius games-arcade/dynamitejack 
> games-arcade/mrrescue games-arcade/notpacman 
> games-arcade/nottetris2 games-arcade/opensonic 
> games-arcade/retrobattle games-board/awale games-board/cockatrice 
> games-board/goatee-gtk games-emulation/gambatte 
> games-emulation/higan games-engines/odamex 
> games-engines/residualvm games-engines/solarus 
> games-engines/stratagus games-fps/duke3d-demodata 
> games-fps/eduke32 games-fps/turtlearena games-fps/urbanterror 
> games-kids/crayon-physics games-misc/dont-starve 
> games-misc/katawa-shoujo games-misc/little-inferno 
> games-misc/lolcat games-misc/papers-please games-puzzle/larry 
> games-puzzle/nightsky games-puzzle/splice 
> games-puzzle/tiny-and-big games-roguelike/FTL 
> games-roguelike/mazesofmonad games-rpg/bastion 
> games-rpg/dear-esther games-rpg/dungeon-defenders 
> games-rpg/freedink games-rpg/freedink-data games-rpg/grimrock 
> games-rpg/mana games-rpg/manaplus games-rpg/penumbra-collection 
> games-rpg/sumwars games-rpg/tmw games-rpg/to-the-moon 
> games-rpg/valyriatear games-rpg/zsdx games-rpg/zsxd 
> games-sports/dustrac games-strategy/dunelegacy 
> games-strategy/freesynd games-strategy/ja2-stracciatella 
> games-strategy/ja2-stracciatella-data games-strategy/liquidwar6 
> games-strategy/megaglest games-strategy/megaglest-data 
> games-strategy/s25rttr games-strategy/wargus 
> games-strategy/wargus-data games-util/antimicro games-util/dfarc 
> games-util/higan-purify games-util/lutris
> 
> co-maintained by ruby <ruby@gentoo.org> app-text/jist 
> dev-ruby/paint
> 
> co-maintained by perl <perl@gentoo.org> 
> dev-perl/Linux-DesktopFiles
> 
> co-maintained by sound <sound@gentoo.org> 
> media-sound/gmusicbrowser media-sound/id3ted
> 
> co-maintained with Thomas Sachau <tommy@gentoo.org> 
> net-libs/polarssl
> 
> co-maintained with Lars Wendler <polynomial-c@gentoo.org> 
> media-sound/umurmur
> 
> co-maintained by net-im <net-im@gentoo.org> net-im/jabberd2
> 
> co-maintained with William Hubbs <williamh@gentoo.org> 
> net-misc/badvpn
> 
> co-maintained with Patrick Lauer <patrick@gentoo.org> 
> sci-mathematics/flint
> 
> co-maintained by x11 <x11@gentoo.org> x11-libs/libXaw3dXft
> 
> co-maintained by desktop-misc <desktop-misc@gentoo.org> 
> x11-misc/cbatticon x11-misc/compton x11-misc/devilspie2 
> x11-misc/menulibre x11-misc/obtheme x11-misc/wbar 
> x11-misc/wbarconf
> 
> proxied for Alex Xu <alex_y_xu@yahoo.ca> x11-misc/x11vnc
> 

I'd like to take x11-misc/spacefm if a developer is willing to allow
me to proxy-maint until I become a developer.
-----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-----

Re: [gentoo-dev] Packages up for grabs

[Yixun Lan]

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

-- 
Yixun Lan (dlan)
Gentoo Linux Developer
GPG Key ID AABEFD55

Re: [gentoo-dev] Packages up for grabs

[Daniel Campbell]

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.

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

Re: [gentoo-dev] Packages up for grabs

[james]

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

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

James

[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

[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

[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

[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

[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

[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

[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: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

[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

[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

[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: 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

[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 --]

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

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

[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

[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

[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

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

[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 --]

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-cdr/uif2iso
app-misc/bgrep
app-text/docbook-xsl-ns-stylesheets
app-text/unpaper
dev-libs/radlib
dev-ruby/ruby-elf
dev-util/google-perftools
dev-util/gource
dev-util/smem
dev-util/vbindiff
media-gfx/esci-interpreter-gt-s80
media-gfx/iscan-plugin-esdip
media-gfx/iscan-plugin-gt-f500
media-gfx/iscan-plugin-gt-f720
media-gfx/iscan-plugin-perfection-v370
net-print/dymo-cups-drivers
net-print/kyocera-mita-ppds
net-proxy/c-icap
net-proxy/ufdbguard
sys-block/hdrecover
sys-block/hpacucli
sys-firmware/iwl6000-ucode
www-apache/mod_security
www-apache/modsec-flameeyes
www-apache/modsecurity-crs
x11-themes/constantine-backgrounds
x11-themes/gentoo10-backgrounds
x11-themes/goddard-backgrounds
x11-themes/laughlin-backgrounds
x11-themes/leonidas-backgrounds
x11-themes/lovelock-backgrounds
x11-themes/solar-backgrounds
x11-themes/verne-backgrounds

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

[gentoo-dev] Packages up for grabs

[aidecoe]

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

Hi,

The following packages are up for grabs:

  app-admin/hddtemp
  app-backup/burp
  app-crypt/md5deep
  dev-python/appdirs
  dev-python/husl
  dev-python/pyro
  dev-python/selectors34
  sys-apps/biosdevname

These packages are quite easy to maintain, so if someone cares about any of
these, don't hesitate! (-:

I will reassign to maintainer-needed if noone will take a package in
a while.

Cheers,
-- Amadeusz Żołnowski

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 980 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] Packages up for grabs

[Dirkjan Ochtman]

The proxy maintainer for syncthing just resigned, anyone want to pick it up?

- net-p2p/syncthing

I also want to drop the following:

- dev-lang/erlang
- dev-vcs/hgsubversion

(All should be in a fairly good state right now.)

Cheers,

Dirkjan

[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] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-portage/repo-commit
dev-libs/libstrl
net-irc/unrealircd

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