Re: [gentoo-dev] Re: Packages up for grabs due to developer inactivity

[Andreas Schürch]

On 2/17/24 21:39, Holger Hoffstätte wrote:

On 2024-02-14 10:49, Michał Górny wrote:


net-dns/dnsdist


I can proxymaint this since I occasionally report bugs/contribute to 
upstream.

Will open a maintainer PR and version bump soon-ish.



Thanks Holger, but I'm not retired and will retake maintainership of 
dnsdist.


I'm already working on the 1.9 release...

Feel free to contact me if you have any enhancements for it.


Br

Andreas

[gentoo-dev] Re: Packages up for grabs due to developer inactivity

[Holger Hoffstätte]

On 2024-02-14 10:49, Michał Górny wrote:


net-dns/dnsdist


I can proxymaint this since I occasionally report bugs/contribute to upstream.
Will open a maintainer PR and version bump soon-ish.

cheers
Holger

[gentoo-dev] Re: Packages up for grabs: media-gfx/rawtherapee media-libs/libiptcdata

[Ben Kohler]

On 2/24/23 04:58, Marek Szuba wrote:


In light of the current (proxied) maintainer having stated they no 
longer have a Linux desktop and therefore expect difficulties in 
continuing to maintain their packages,


media-gfx/rawtherapee


I will take this one unless anyone else is really passionate about it.  
It's related to one of my other packages (fotoxx) and I've done the last 
bump and a few minor fixes on it already.


-Ben

Re: [gentoo-dev] Re: Packages up for grabs: sys-apps/bat, app-misc/physlock, dev-lang/crystal, dev-util/shards

[Maciej Barć]

dev-lang/crystal
dev-util/shards


Added myself as maint to both of those (and bumped them).

On 2/11/23 22:48, Maciej Barć wrote:

These packages are only used in ::guru, so they could be moved there.


I think regular mask-remove process should apply.

I am interested in crystal and might pick it up. Co-maints welcome! :^)

On 2/11/23 20:01, Anna (cybertailor) Vyalkova wrote:

dev-lang/crystal
dev-util/shards


These packages are only used in ::guru, so they could be moved there.





--
Have a great day!

~ Maciej XGQT Barć


OpenPGP_0x14D74A1F43A6AC3C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Packages up for grabs: sys-apps/bat, app-misc/physlock, dev-lang/crystal, dev-util/shards

[Maciej Barć]

These packages are only used in ::guru, so they could be moved there.


I think regular mask-remove process should apply.

I am interested in crystal and might pick it up. Co-maints welcome! :^)

On 2/11/23 20:01, Anna (cybertailor) Vyalkova wrote:

dev-lang/crystal
dev-util/shards


These packages are only used in ::guru, so they could be moved there.



--
Have a great day!

~ Maciej XGQT Barć


OpenPGP_0x14D74A1F43A6AC3C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[gentoo-dev] Re: Packages up for grabs: sys-apps/bat, app-misc/physlock, dev-lang/crystal, dev-util/shards

[Anna (cybertailor) Vyalkova]

> dev-lang/crystal
> dev-util/shards

These packages are only used in ::guru, so they could be moved there.

[gentoo-dev] Re: Packages up for grabs: app-eselect/eselect-wine, gui-libs/gtk-layer-shell ...

[Conrad Kostecki]

Hi!

Am 24.07.2022 um 10:34 schrieb Joonas Niilola:

net-libs/libcapi


I will take this package.

Conrad

[gentoo-dev] Re: Packages up for grabs: x11-misc/lightdm, sys-apps/fwupd, net-im/pidgin, media-sound/mumble, app-emulation/virtualbox, app-editors/nano, app-shells/zsh and more

[Marek Szuba]

On 2022-06-29 08:15, Joonas Niilola wrote:


acct-group/lightdm
acct-user/lightdm
app-admin/keepassxc
mail-mta/msmtp
sys-apps/gptfdisk
sys-apps/lm-sensors
sys-fs/ddrescue
x11-misc/lightdm
x11-misc/lightdm-gtk-greeter


I'll take these.

--
Marecki


OpenPGP_signature
Description: OpenPGP digital signature

[gentoo-dev] Re: Packages up for grabs: x11-misc/lightdm, sys-apps/fwupd, net-im/pidgin, media-sound/mumble, app-emulation/virtualbox, app-editors/nano, app-shells/zsh and more

[Florian Schmaus]

On 29/06/2022 09.15, Joonas Niilola wrote:

Packages up for grabs:
…
sys-libs/liburing


I'd take this one. Co-maintainers welcome :)

- Flow

[gentoo-dev] Re: Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...

[Marek Szuba]

On 2022-06-05 09:28, Joonas Niilola wrote:


sys-process/incron


I'll take this one, with Infra as fallback maintainers.

--
Marecki


OpenPGP_signature
Description: OpenPGP digital signature

[gentoo-dev] Re: Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...

[Conrad Kostecki]

Hi!

Am 05.06.2022 um 10:28 schrieb Joonas Niilola:

Full list:
net-libs/liboping


Will also take that package, as it's a direct dep for collectd.

Conrad

[gentoo-dev] Re: Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...

[Jakov Smolić]

On 6/5/22 10:28, Joonas Niilola wrote:


sys-fs/ncdu


I will take this one.

--
Jakov

[gentoo-dev] Re: Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...

[Florian Schmaus]

On 05/06/2022 10.28, Joonas Niilola wrote:

sys-block/hpssacli


I grabbed this one.

- Flow

[gentoo-dev] Re: Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...

[Maciej Barć]

dev-libs/libestr
dev-libs/libfastjson


I will probably take dev-libs/libestr & dev-libs/libfastjson which are 
(mainly) deps of app-admin/rsyslog.



app-admin/rsyslog


I could take app-admin/rsyslog but I fee like this might a bit too much 
for me, so for now only first two deps.



On 6/5/22 10:28, Joonas Niilola wrote:

Full list:
acct-group/collectd
acct-group/fritzbox_smarthome_exporter
acct-group/mysqld_exporter
acct-group/nginx
acct-group/sabnzbd
acct-user/collectd
acct-user/fritzbox_smarthome_exporter
acct-user/mysqld_exporter
acct-user/nginx
acct-user/sabnzbd
app-admin/cli53
app-admin/rsyslog
app-arch/rar
app-backup/tarsnap
app-metrics/collectd
app-metrics/fritzbox_smarthome_exporter
app-metrics/mysqld_exporter
app-portage/elicense
app-portage/golop
app-text/vgrep
dev-libs/libee
dev-libs/libestr
dev-libs/libfastjson
dev-libs/liblognorm
dev-libs/librdkafka
dev-libs/librelp
dev-python/PyRSS2Gen
dev-python/sabyenc
dev-python/ws4py
net-irc/znc-clientbuffer
net-irc/znc-igloo-push
net-irc/znc-playback
net-libs/liboping
net-libs/zeromq
net-misc/httpstat
net-nntp/sabnzbd
sys-apps/hponcfg
sys-block/f3
sys-block/hpacucli
sys-block/hpssacli
sys-block/storcli
sys-fs/ncdu
sys-libs/libfaketime
sys-process/incron
www-apps/nextcloud-notify_push
www-apps/nikola
www-servers/nginx

The usual stuff. Outdated packages, open pull requests, bugs, security
bugs. Lots of pkgcheck issues too, so fix those if interested in taking
over some of these while at it.

-- juippis


--
Have a great day!

~ Maciej XGQT Barć


OpenPGP_0x14D74A1F43A6AC3C.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[gentoo-dev] Re: Packages up for grabs: e.g. www-servers/nginx, www-apps/nikola, app-admin/rsyslog, ...

[Conrad Kostecki]

Hi!

Am 05.06.2022 um 10:28 schrieb Joonas Niilola:

acct-group/collectd
acct-group/nginx
acct-user/collectd
acct-user/nginx
app-arch/rar
app-metrics/collectd
www-servers/nginx


I could image of taking/helping with collectd, rar and nginx, as I am using 
those packages.
As for nginx, we would really need someone, who has experience with nginx, as 
it's a complex package.
I don't think, I will be able to maintain alone that.

Conrad

[gentoo-dev] Re: Packages up for grabs: innoextract, emech, tigervnc, urxvtconfig

[Joonas Niilola]

On 2/21/21 3:54 PM, Joonas Niilola wrote:
> Hey,
>
> here are some packages up-for-grabs due to retirement of their maintainers.
> b = bugs open, v = version bump available.
>
> app-arch/innoextract
> net-irc/emech (b)
> net-misc/tigervnc (b)
> x11-misc/urxvtconfig (b)
>
In addition,

app-text/diction
www-client/surfraw (stabilization bug open)

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature

[gentoo-dev] Re: Packages up for grabs: innoextract, emech, tigervnc, urxvtconfig

[Joonas Niilola]

On 2/21/21 3:54 PM, Joonas Niilola wrote:
> Hey,
>
> here are some packages up-for-grabs due to retirement of their maintainers.
> b = bugs open, v = version bump available.
>
> app-arch/innoextract
> net-irc/emech (b)
> net-misc/tigervnc (b)
> x11-misc/urxvtconfig (b)
>
In addition, media-video/webcamoid is also up for grabs. It has 3 bugs
open, and a version bump available.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature

[gentoo-dev] Re: Packages up for grabs: innoextract, emech, tigervnc, urxvtconfig

[John Helmert III]

On Sun, Feb 21, 2021 at 03:54:39PM +0200, Joonas Niilola wrote:
> Hey,
> 
> here are some packages up-for-grabs due to retirement of their maintainers.
> b = bugs open, v = version bump available.
> 
> app-arch/innoextract
> net-irc/emech (b)
> net-misc/tigervnc (b)

Note that this one has a pretty serious bug in Gentoo (it's masked) [0]
and that seems to be blocked by an upstream bug [1].

[0] https://bugs.gentoo.org/746227
[1] https://github.com/TigerVNC/tigervnc/issues/1208

> x11-misc/urxvtconfig (b)
> 


signature.asc
Description: PGP signature

[gentoo-dev] Re: Packages up for grabs: dev-erlang/*

[Amadeusz Żołnowski]

I have removed myself from maintainers and dev-erlang has no more
maintainers. I removed myself from ejabberd maintainers as well, but
that is still maintained by Hanno.

Hanno, given that you are the only maintainer of ejabberd now, you may
need to look at dev-erlang/* packages. I'm happy to help get you
started. :-) It would be ideal if someone with any interest in Erlang
would take those over.


Thanks,
-- aidecoe


aide...@gentoo.org writes:

> Hi,
>
> I'm finding hard to get time and enough interest in maintaing
> net-im/ejabberd and its deps at dev-erlang/*.
>
> Please feel free to take over. I'm happy to help to get anyone started.
>
> Thanks,
> -- aidecoe


signature.asc
Description: PGP signature

[gentoo-dev] Re: Packages up for grabs: net-news/rssguard,...

[Johannes Huber]

Am 18.07.2018 um 23:38 schrieb Jonas Stein:
> ...
> app-crypt/zulucrypt
> app-admin/profile-cleaner
> ...

Took those two.

Best regards,
Johannes



signature.asc
Description: OpenPGP digital signature

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

[gentoo-dev] Re: Packages up for grabs: app-misc/jail (perl)

[Felix Janda]

> https://packages.gentoo.org/packages/app-misc/jail
> 
> The proxied maintainer was also upstream.
> 
> Jail is a Perl tool that builds a chroot and configures all the required
> files, directories and libraries
> https://github.com/spiculator/jail
> 
> I do not understand why we need so many patches for the package, if
> the proxied maintainer was also upstream.

https://bugs.gentoo.org/514892

should explain this.

> Upstream is silent since many years. I have no idea what the tool is worth.
> Proxied maintainer Felix (https://bugs.gentoo.org/632752) forked the
> upstram on github and can probably help us with this package. Please
> contact proxy maintainer project, if you are interested.
> I think, Felix plus a gentoo developer with perl experience would make a
> good team.

I do not really have interest in this package. The fork was just in
order to be able to make a drive-by musl fix. (It was a low-hanging
fruit from the list of musl build failures from blueness' tinderbox.)
(Fixing https://bugs.gentoo.org/580326 would actually also fix the
musl issue.)

Since the upstream project has only 4 commits of which the last was in
2014, and there is no other github activity apart from my pull request,
the interest in this package seems to be rather low, and I would suggest
considering last-riting it.

Felix

[gentoo-dev] Re: Packages up for grabs

[Dirkjan Ochtman]

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

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

Cheers,

Dirkjan

[gentoo-dev] Re: Packages up for grabs

[Marek Szuba]

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

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

-- 
MS



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Packages up for grabs due to retirement

[Thomas Kahle]

On 01/01/2017 10:48, David Seifert wrote:
> On Sat, 2016-12-31 at 22:54 +0100, Thomas Kahle wrote:
>> Hi,
>>
>> I will retire, so here are my remaining packages.  Feel free to
>> e-mail me any questions re this.  sci-math is in CC because there
>> are quite a few math packages.
>>
>> app-emacs/undo-tree
>> app-misc/anki
>> app-portage/tatt
>> app-text/tesseract
>> app-text/pdfsandwich
>> dev-cpp/gtest
>> dev-python/python-wpactrl
>> dev-python/python-iwscan
>> media-sound/gmtp
>> net-misc/wicd
>> sci-libs/bliss
>> sci-libs/mpir
>> sci-libs/lrslib
>> sci-mathematics/gfan
>> sci-mathematics/nauty
>> sci-mathematics/singular
>> sci-mathematics/frobby
>> sci-mathematics/normaliz
>> sci-mathematics/polymake
>> sci-mathematics/4ti2
>> sci-mathematics/bertini
>> sci-mathematics/topcom
>> sci-mathematics/gimps
>> sci-mathematics/xmds
>> sci-mathematics/Macaulay2
>> sci-misc/flashdot
>> www-apps/tt-rss
>>
>> Cheers,
>> Thomas
>>
>>
> 
> Sad to see you go Thomas. As a finalising act, could you please assign
> 
>   sci-{libs,misc}/* -> sci project
>   sci-mathematics/* -> sci-mathematics project
> 
> We will then maintain those packages as part of the project.

Done.  They all had the relevant projects as maintainers listed, so I
just removed myself.  sci-libs/bliss also has ottxor as a maintainer.

Cheers,
Thomas


-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Packages up for grabs due to retirement

[David Seifert]

On Sat, 2016-12-31 at 22:54 +0100, Thomas Kahle wrote:
> Hi,
> 
> I will retire, so here are my remaining packages.  Feel free to
> e-mail me any questions re this.  sci-math is in CC because there
> are quite a few math packages.
> 
> app-emacs/undo-tree
> app-misc/anki
> app-portage/tatt
> app-text/tesseract
> app-text/pdfsandwich
> dev-cpp/gtest
> dev-python/python-wpactrl
> dev-python/python-iwscan
> media-sound/gmtp
> net-misc/wicd
> sci-libs/bliss
> sci-libs/mpir
> sci-libs/lrslib
> sci-mathematics/gfan
> sci-mathematics/nauty
> sci-mathematics/singular
> sci-mathematics/frobby
> sci-mathematics/normaliz
> sci-mathematics/polymake
> sci-mathematics/4ti2
> sci-mathematics/bertini
> sci-mathematics/topcom
> sci-mathematics/gimps
> sci-mathematics/xmds
> sci-mathematics/Macaulay2
> sci-misc/flashdot
> www-apps/tt-rss
> 
> Cheers,
> Thomas
> 
> 

Sad to see you go Thomas. As a finalising act, could you please assign

  sci-{libs,misc}/* -> sci project
  sci-mathematics/* -> sci-mathematics project

We will then maintain those packages as part of the project.

Regards
David

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

[Kent Fredric]

On Mon, 8 Aug 2016 16:33:15 +1200
Kent Fredric  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.


pgpzbtyQLMjqD.pgp
Description: OpenPGP digital signature

Re: Easy Installs / Stage 4 ( Was: Re: [gentoo-dev] Re: Packages up for grabs )

[Jason Zaman]

On Sun, Aug 07, 2016 at 02:57:14PM -0500, james wrote:

You should take a look at Blueness' Gentoo Reference stuff
https://wiki.gentoo.org/wiki/Project:RelEng_GRS
https://blogs.gentoo.org/blueness/2015/07/31/the-gentoo-reference-system-suite-a-new-release-engineering-tool/

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

[Kent Fredric]

On Mon, 8 Aug 2016 00:26:01 -0500
james  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.


pgpG08JdyUy3X.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

On Sun, 7 Aug 2016 16:49:01 -0500
james  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.


pgpGlxpk7zSIT.pgp
Description: OpenPGP digital signature

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

[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

[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.mckin...@gmail.com

Re: Easy Installs / Stage 4 ( Was: Re: [gentoo-dev] Re: Packages up for grabs )

[james]

On 08/07/2016 11:55 AM, Kent Fredric wrote:

Moving this to a higher visibility thread because I don't know how many
people think such an intense discussion is happening in the tail of a
package assignment . :P

Most of my negativity/limitations are more about making sure we define
where we aught to go.

They're less "Limits", more "guides", often enough.

On Sun, 7 Aug 2016 12:24:37 -0500
james  wrote:

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



Here, the "Limitation" as such is that once you realise that "C" is not
the only target, nor is Java, you realise there are going to be end
users who want "easy mode" and have no intent on doing any immediate
development work.

Or we might have user bases who want ready-to-go media for python
development.

This is not a "limitation", because if you think about customization,
we can very much provide all the choices.

And theoretically, we can provide named sets of default good choices
that are "reasonably good for the purpose they describe", and then
people can pick and choose what they want, and then if they want to
expert-mode it, they can hand craft their own "choice set", or progress
to installing their base system like the rest of us.


You are diverging onto a very minor issue, about kids and college 
educations. But, we do have "sets" and they are very useful for a 
variety of goals with portage. Thanks for pointing that fact out.









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 

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

[Rich Freeman]

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

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

-- 
Rich

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

[james]

On 08/07/2016 11:21 AM, Ciaran McCreesh wrote:

On Sun, 7 Aug 2016 12:24:37 -0500
james  wrote:

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


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

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


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


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



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


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


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



hth,
James

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

[james]

On 08/07/2016 09:47 AM, Rich Freeman wrote:

On Sun, Aug 7, 2016 at 9:24 AM, james  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

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


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


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


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

"In the meantime, nobody uses gentoo anymore because"

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


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


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



hth,
James

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

[james]

On 08/07/2016 09: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

[Ciaran McCreesh]

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

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

-- 
Ciaran McCreesh

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

[james]

On 08/07/2016 08:32 AM, Kent Fredric wrote:

On Sun, 7 Aug 2016 08:24:51 -0500
james  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 

[gentoo-dev] Re: Packages up for grabs

[Michael Palimaka]

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

I can take this one.

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

[Rich Freeman]

On Sun, Aug 7, 2016 at 9:24 AM, james  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

[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

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

[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.mckin...@gmail.com

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

[Kent Fredric]

On Sun, 7 Aug 2016 08:24:51 -0500
james  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".





pgpbskXbmWbY2.pgp
Description: OpenPGP digital signature

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?


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 

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

[Michał Górny]

Dnia 6 sierpnia 2016 23:12:55 CEST, Peter Stuge  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

[Kent Fredric]

On Sat, 6 Aug 2016 19:28:19 +
Peter Stuge  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





pgpXCz1SbaYHQ.pgp
Description: OpenPGP digital signature

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

[Rich Freeman]

On Sat, Aug 6, 2016 at 4:55 PM, Michał Górny  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]

On Sat, 6 Aug 2016 16:47:09 -0400
Rich Freeman  wrote:

> On Sat, Aug 6, 2016 at 3:28 PM, Peter Stuge  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



pgpoGSVyIg2Qc.pgp
Description: OpenPGP digital signature

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

[Rich Freeman]

On Sat, Aug 6, 2016 at 3:28 PM, Peter Stuge  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

[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

[Michał Górny]

On Sat, 6 Aug 2016 16:04:08 +
Peter Stuge  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



pgpiwbluX7Nnk.pgp
Description: OpenPGP digital signature

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

[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

[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

[Justin Bronder]

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


signature.asc
Description: Digital signature

[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 + as excerpted:

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

And fixed! =:^)

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

[gentoo-dev] Re: Packages up for grabs

[Harvey]

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

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

H
On 11/27/2014 04:51 AM, Daniel Campbell wrote:
 On 11/26/2014 03:15 AM, Yixun Lan wrote:
 On 21:08 Sun 23 Nov , Daniel Campbell wrote:

 I'd like to take x11-misc/spacefm if a developer is willing to allow
 me to proxy-maint until I become a developer.

 update metadata.xml, using your email found in bugzie.
 and current no bug opened, thanks

 btw, any particular reason why should we keep so many stable versions?
 probably start doing by cleaning old versions ;-)

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBAgAGBQJUcqEYAAoJEJUrb08JgYgHJ0IIAK+tguKdL+JxdjKLySOSJaTU
 kiU1z2rBqUfPzs8VI3V8JAAL9dbSJel4h3/JdoZFpidC9jED63l5STmGXi6dp63O
 9CKqNQRt4AELfOUpQzxoD4HNHVxaA9hkiiJXgAoF9HIfKBEqczPCBKGnJb5s1WB5
 8eQkn6t6DZMZeRV/dE6pw1RgTj1eHowu2es67V7+bHMiy2ylz5/4ru0dx+1UHvU1
 UeBBcB1IesAVxVsfpBLJoi+aZA9CO9EAriaGogzTXQPP5odr4bgIf5acxOPKGxt0
 iz62j/XgG3jTExqkP5rNaTVnO9ZZol8XPcLiAIZTEl79XU0ZOcy5LDUsJNY+9cI=
 =stIL
 -END PGP SIGNATURE-

 
 I'd do that myself, if I was a dev. :P I'd need a developer to help me
 proxy maintain it. I've been meaning to become a developer, but my
 ebuild quiz is out of date and I have a lot of IRL things going on right
 now so I can't really work toward it right now. spacefm's developer is
 on hiatus, so it'd be a good low-traffic package for me to maintain and
 take the load (if only mental) off of other developers.
 
 

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

[Daniel Campbell]

On 12/03/2014 10:34 AM, Harvey wrote:
 If your going to take on spacefm, it would be great if you also handled
 udevil since they are both from the same upstream repo and work tightly
 together..
 
 I'm an avid user of both, and since upstream is no longer maintained on
 either of these their futures are unclear..
 
 H
 On 11/27/2014 04:51 AM, Daniel Campbell wrote:
 On 11/26/2014 03:15 AM, Yixun Lan wrote:
 On 21:08 Sun 23 Nov , Daniel Campbell wrote:

 I'd like to take x11-misc/spacefm if a developer is willing to allow
 me to proxy-maint until I become a developer.

 update metadata.xml, using your email found in bugzie.
 and current no bug opened, thanks

 btw, any particular reason why should we keep so many stable versions?
 probably start doing by cleaning old versions ;-)

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBAgAGBQJUcqEYAAoJEJUrb08JgYgHJ0IIAK+tguKdL+JxdjKLySOSJaTU
 kiU1z2rBqUfPzs8VI3V8JAAL9dbSJel4h3/JdoZFpidC9jED63l5STmGXi6dp63O
 9CKqNQRt4AELfOUpQzxoD4HNHVxaA9hkiiJXgAoF9HIfKBEqczPCBKGnJb5s1WB5
 8eQkn6t6DZMZeRV/dE6pw1RgTj1eHowu2es67V7+bHMiy2ylz5/4ru0dx+1UHvU1
 UeBBcB1IesAVxVsfpBLJoi+aZA9CO9EAriaGogzTXQPP5odr4bgIf5acxOPKGxt0
 iz62j/XgG3jTExqkP5rNaTVnO9ZZol8XPcLiAIZTEl79XU0ZOcy5LDUsJNY+9cI=
 =stIL
 -END PGP SIGNATURE-


 I'd do that myself, if I was a dev. :P I'd need a developer to help me
 proxy maintain it. I've been meaning to become a developer, but my
 ebuild quiz is out of date and I have a lot of IRL things going on right
 now so I can't really work toward it right now. spacefm's developer is
 on hiatus, so it'd be a good low-traffic package for me to maintain and
 take the load (if only mental) off of other developers.


 
 
 
Sure, I'm down to proxy-maintain udevil as well. I use it with spacefm
to mount things.

[gentoo-dev] Re: Packages up for grabs

[Duncan]

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

 On Mon, 24 Jun 2013 15:27:19 + (UTC)
 Duncan 1i5t5.dun...@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 

[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 + (UTC)
 Duncan 1i5t5.dun...@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.
 
 

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

[Tom Wijsman]

On Mon, 24 Jun 2013 15:27:19 + (UTC)
Duncan 1i5t5.dun...@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 - as to not go too unstable.

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

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

[Michael Palimaka]

On 16/06/2013 23:02, g...@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] 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 pa...@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., 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]

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 pa...@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 
dilfri...@gentoo.org
http://www.akhuettel.de/



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

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

[Tom Wijsman]

On Sun, 16 Jun 2013 19:33:53 + (UTC)
Duncan 1i5t5.dun...@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
RD 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  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

On Sun, 16 Jun 2013 23:24:27 +0200
Tom Wijsman tom...@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


signature.asc
Description: PGP signature

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

[Tom Wijsman]

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

 On Sun, 16 Jun 2013 23:24:27 +0200
 Tom Wijsman tom...@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  : tom...@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D


signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

On Mon, 17 Jun 2013 00:07:57 +0200
Tom Wijsman tom...@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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Packages up for grabs due lack of time

[Maxim Kammerer]

On Mon, Feb 18, 2013 at 6:47 AM, Ryan Hill dirtye...@gentoo.org wrote:
 He means that until you install the package with all firmware enabled you 
 don't
 know what lines you need to put into the savedconfig file.

I have posted a snippet previously — you basically search for
firmware=... in kernel modules. It's doesn't always work, though —
e.g., it won't with DVB firmware, I think.

 Even after you do that it's hard to figure out what firmware files you 
 actually
 need.  I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but
 linux-firmware contains:

 iwlwifi-6000-4.ucode
 iwlwifi-6000g2a-5.ucode
 iwlwifi-6000g2a-6.ucode
 iwlwifi-6000g2b-5.ucode
 iwlwifi-6000g2b-6.ucode

 Are these different versions?  Different cards?  Which do I need?  I had to
 go back and reinstall sys-firmware/iwl6000-ucode to see which file was the
 right one.

iwlwifi is somewhat special, with its multiple versions and
subversions. In this case, 6000{,g2{a,b}} are different cards, and
-[456] are different firmware APIs, with multiple APIs supported by a
given kernel. See, e.g.,
/usr/src/linux/drivers/net/wireless/iwlwifi/iwl-6000.c.

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] Re: Packages up for grabs due lack of time

[Chí-Thanh Christopher Nguyễn]

Ryan Hill schrieb:
 He means that until you install the package with all firmware enabled you 
 don't
 know what lines you need to put into the savedconfig file.

 Even after you do that it's hard to figure out what firmware files you 
 actually
 need.  I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but
 linux-firmware contains:

Sometimes it can be inferred from dmesg output, where the driver outputs
which firmware it requested.

 Are these different versions?  Different cards?  Which do I need?  I had to
 go back and reinstall sys-firmware/iwl6000-ucode to see which file was the
 right one.

Which exact firmware file you need also depends on your kernel version.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: Packages up for grabs due lack of time

[Rémi Cardona]

Le dimanche 17 février 2013 à 22:47 -0600, Ryan Hill a écrit :
 Even after you do that it's hard to figure out what firmware files you 
 actually
 need.  I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but
 linux-firmware contains:
 
 iwlwifi-6000-4.ucode
 iwlwifi-6000g2a-5.ucode
 iwlwifi-6000g2a-6.ucode
 iwlwifi-6000g2b-5.ucode
 iwlwifi-6000g2b-6.ucode
 
 Are these different versions?  Different cards?  Which do I need?

Good kernel modules *should* export needed firmwares as module
parameters. You *should* then be able to query it with modinfo:

modinfo module -F firmware

Note however that *lots* of modules (especially DVB, in my experience)
don't properly set those parameters and you're left grepping the source
code or dmesg to find which firmware you'll need...

Cheers,

Rémi

[gentoo-dev] Re: Packages up for grabs due lack of time

[Ryan Hill]

On Sun, 17 Feb 2013 18:40:10 +0100
Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote:

 Peter Stuge schrieb:
  linux-firmware is okey but not great. The high resolution is there, which
  was my main concern, but
 it's not so easy to know how to create a savedconfig without installing
 the package.
 
 Just create a text file
 /etc/portage/savedconfig/sys-kernel/linux-firmware with the desired
 filename(s) and emerge linux-firmware with USE=savedconfig enabled.

He means that until you install the package with all firmware enabled you don't
know what lines you need to put into the savedconfig file.

Even after you do that it's hard to figure out what firmware files you actually
need.  I know I need iwl6000 firmware for Intel Ultimate-N 6300 wifi, but
linux-firmware contains:

iwlwifi-6000-4.ucode
iwlwifi-6000g2a-5.ucode
iwlwifi-6000g2a-6.ucode
iwlwifi-6000g2b-5.ucode
iwlwifi-6000g2b-6.ucode

Are these different versions?  Different cards?  Which do I need?  I had to
go back and reinstall sys-firmware/iwl6000-ucode to see which file was the
right one.


-- 
gcc-porting
toolchain, wxwidgetslearn a language baby, it's that kind of place
@ gentoo.org   where low card is hunger and high card is taste


signature.asc
Description: PGP signature

[gentoo-dev] Re: Packages up for grabs due lack of time

[Ryan Hill]

On Sun, 17 Feb 2013 12:42:11 +0100
Michał Górny mgo...@gentoo.org wrote:

 I would justify it through keeping things split and bit-exact clean,
 instead of tightly integrated.
 
 Separate ebuilds mean that:
 
 - each firmware has proper license,
 
 - each firmware can be installed separately and it is _clean_ which
   firmwares are actually installed (think of binpkgs),
 
 - each firmware can be upgraded when it needs to be (alternatively: all
   firmwares are re-installed over and over again when new firmware is
   added).
 
 And I wouldn't mind having even 200 sys-firmware/ packages. And don't
 tell me that firmwares change every month, these are particularly
 maintenance-free packages.
 
 And I don't mind having meta-packages for lazy people.
 
 Although I believe that having a few 'group' packages for firmwares
 will be 'acceptable'. Assuming those firmwares share a common license.

I very much agree with all of this.  It would be nice if we could keep the
individual firmware packages but just have them be a wrapper that depends on
linux-firmware and ensures that the required files get installed (maybe by
adding them to the savedconfig if it finds they aren't there).  Yes, there are
several problems with that idea, I know.


-- 
gcc-porting
toolchain, wxwidgetslearn a language baby, it's that kind of place
@ gentoo.org   where low card is hunger and high card is taste


signature.asc
Description: PGP signature

[gentoo-dev] Re: Packages up for grabs

[Mike Gilbert]

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.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Packages up for grabs: prosody + lua deps

[Dirkjan Ochtman]

On Mon, Nov 26, 2012 at 2:40 PM, Dirkjan Ochtman d...@gentoo.org wrote:
 dev-lua/lua-zlib: no other maintainers/herd
 dev-lua/luadbi: no other maintainers/herd
 dev-lua/luaevent: blueness, rafaelmartins
 dev-lua/luaexpat: rafaelmartins
 dev-lua/luasec: rafaelmartins
 net-im/prosody: klausman, rafaelmartins

I've removed myself from all of these packages. They're mostly in good
shape, though it would be great if someone takes a look at
https://bugs.gentoo.org/show_bug.cgi?id=436652.

Cheers,

Dirkjan

Re: [gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Jeroen Roovers]

On Sat, 1 Dec 2012 21:41:35 -0500
Rich Freeman ri...@gentoo.org wrote:

 On Sat, Dec 1, 2012 at 9:37 PM, Alec Warner anta...@gentoo.org
 wrote:
  Look, if you want to make a policy about the stuff, then make a
  policy, get council approval, and write it down.
  Don't make up silly half-solutions.
 
 Sure, but I'm not aware of any policy at all concerning packages that
 contain bundled libraries.

https://bugs.gentoo.org/show_bug.cgi?id=251464


 jer

Re: [gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Michał Górny]

On Sun, 2 Dec 2012 02:20:07 + (UTC)
Duncan 1i5t5.dun...@cox.net wrote:

 Rich Freeman posted on Sat, 01 Dec 2012 08:46:34 -0500 as excerpted:
 
  And if we force some types of packages to be masked all the time, then
  what do we do if we actually need to mask them for removal or security. 
  Users won't even realize they have a known flaw, because they had to
  unmask the package just to install it.  I think there is a big
  difference between bundles libs and therefore might have a security
  issue and has a known security issue.
 
 Very good point.
 
 Being a (somewhat pragmatic) security emphasis person by default, as well 
 as a freedomware person, I had been leaning toward the mask it and let 
 the user decide viewpoint, but this question changed my mind entirely.
 
 What about this for a reasonable but still somewhat strict compromise?
 
 a) A pkg_pretend phase that checks for a set variable (like 
 I_KNOW_THE_SECURITY_ISSUES), and dies with an appropriate warning if it's 
 not set.
 
 b) With (a) in place, keeping the package unmasked (unless (c)) but 
 forever ~arch, no stable.

You just requested us to have a package which intentionally fails
to build by default. And we're not supposed to fix this nor mask it...

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

[gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Duncan]

Michał Górny posted on Sun, 02 Dec 2012 09:35:45 +0100 as excerpted:

 On Sun, 2 Dec 2012 02:20:07 + (UTC)
 Duncan 1i5t5.dun...@cox.net wrote:
 
 Rich Freeman posted on Sat, 01 Dec 2012 08:46:34 -0500 as excerpted:
 
  And if we force some types of packages to be masked all the time,
  then what do we do if we actually need to mask them for removal or
  security.

 Very good point.

 What about this for a reasonable but still somewhat strict compromise?
 
 a) A pkg_pretend phase that checks for a set variable (like
 I_KNOW_THE_SECURITY_ISSUES), and dies with an appropriate warning if
 it's not set.
 
 b) With (a) in place, keeping the package unmasked (unless (c)) but
 forever ~arch, no stable.
 
 You just requested us to have a package which intentionally fails to
 build by default. And we're not supposed to fix this nor mask it...

That's what pkg_pretend is FOR, to notify users about seriously out of 
the ordinary situations such as incredibly resource-intensive builds, or 
unusual packages that might place their system in danger, that need some 
manual attention in the pretend phase, before the actual build gets under 
way.

They'll deal with it once, before the install starts, either deciding to 
set the variable, or deciding the risk is too great and that they don't 
need the package /that/ much after all.  Either way, they'll be informed 
about the risks and won't have to worry about it again during routine use 
and updates, but if they do choose to install, will still be informed by 
the usual security mask mechanism if there's an actual known 
vulnerability.

I actually have some experience with such variables as I've set the 
I_KNOW_WHAT_I_AM_DOING var for glibc so I can downgrade back to the very 
same binpkg I was using just minutes before, when I find a problem with 
an upgrade.  I understand why the variable test is there for glibc, but 
it was irritating non-the-less, especially since simply setting it when I 
had the problem wouldn't work, since it wasn't set in the binpkg.  I have 
similar var settings for grub, so it doesn't try to mount /boot.  But 
setting a variable for a single package via /etc/portage/env/* and 
rebuilding just works and must be done only once.  No further worries 
about it after that.

Basically it's the same thing as having to accept a license before first 
install, only in this case it's effectively that they have to accept a 
gentoo warning, due to even more out of the ordinary conditions for a 
gentoo package.

A fetch-restrict is far worse since it requires jumping thru the hoops 
for every upgrade.  Yet we do that on a number of packages.  Are they all 
masked?  (For all I know they might be as I don't use any such packages.)

-- 
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 due lavajoe retirement

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/12/12 03:35 AM, Michał Górny wrote:
 On Sun, 2 Dec 2012 02:20:07 + (UTC) Duncan
 1i5t5.dun...@cox.net wrote:
 
 Rich Freeman posted on Sat, 01 Dec 2012 08:46:34 -0500 as
 excerpted:
 
 And if we force some types of packages to be masked all the
 time, then what do we do if we actually need to mask them for
 removal or security. Users won't even realize they have a known
 flaw, because they had to unmask the package just to install
 it.  I think there is a big difference between bundles libs
 and therefore might have a security issue and has a known
 security issue.
 
 Very good point.
 
 Being a (somewhat pragmatic) security emphasis person by default,
 as well as a freedomware person, I had been leaning toward the
 mask it and let the user decide viewpoint, but this question
 changed my mind entirely.
 
 What about this for a reasonable but still somewhat strict
 compromise?
 
 a) A pkg_pretend phase that checks for a set variable (like 
 I_KNOW_THE_SECURITY_ISSUES), and dies with an appropriate warning
 if it's not set.
 
 b) With (a) in place, keeping the package unmasked (unless (c))
 but forever ~arch, no stable.
 
 You just requested us to have a package which intentionally fails 
 to build by default. And we're not supposed to fix this nor mask
 it...
 

...  a die in pkg_pretend is fails to be permitted to emerge, not
fails to build.  And this would be essentially a p.mask but without
it using the portage p.mask (and its various connotations).

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlC7qWsACgkQ2ugaI38ACPCh9gEAsBPiECtphA9/H33ucTrfHpQd
2j0dNDOxVxsX+BjOXqQA/2PS3sMy1X8G8+pvj6p7lRsbm0a8IuT1jWNE0pu5TrfC
=Z0nu
-END PGP SIGNATURE-

[gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Duncan]

Ian Stakenvicius posted on Sun, 02 Dec 2012 14:18:04 -0500 as excerpted:

 ...  a die in pkg_pretend is fails to be permitted to emerge, not
 fails to build.  And this would be essentially a p.mask but without it
 using the portage p.mask (and its various connotations).

Exactly.  =:^)

-- 
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 due lavajoe retirement

[Duncan]

Rich Freeman posted on Sat, 01 Dec 2012 08:46:34 -0500 as excerpted:

 And if we force some types of packages to be masked all the time, then
 what do we do if we actually need to mask them for removal or security. 
 Users won't even realize they have a known flaw, because they had to
 unmask the package just to install it.  I think there is a big
 difference between bundles libs and therefore might have a security
 issue and has a known security issue.

Very good point.

Being a (somewhat pragmatic) security emphasis person by default, as well 
as a freedomware person, I had been leaning toward the mask it and let 
the user decide viewpoint, but this question changed my mind entirely.

What about this for a reasonable but still somewhat strict compromise?

a) A pkg_pretend phase that checks for a set variable (like 
I_KNOW_THE_SECURITY_ISSUES), and dies with an appropriate warning if it's 
not set.

b) With (a) in place, keeping the package unmasked (unless (c)) but 
forever ~arch, no stable.

c) Deal with known security issues as normal, that is, mask the package, 
with possible eventual removal.


It seems to me that this is a reasonable compromise giving both sides 
what they want.  (a) forces the user into a hard opt-in to actually 
install the package, (b) keeps the package at least visible to ordinary 
users (those willing to deal with ~arch at least), and (c) means we can 
still notify users that have opted-in when there's a known security issue.

If this proves to be a reasonable compromise, it's possible there's other 
packages for which it can be used as well.

-- 
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 due lavajoe retirement

[Alec Warner]

On Sat, Dec 1, 2012 at 6:20 PM, Duncan 1i5t5.dun...@cox.net wrote:
 Rich Freeman posted on Sat, 01 Dec 2012 08:46:34 -0500 as excerpted:

 And if we force some types of packages to be masked all the time, then
 what do we do if we actually need to mask them for removal or security.
 Users won't even realize they have a known flaw, because they had to
 unmask the package just to install it.  I think there is a big
 difference between bundles libs and therefore might have a security
 issue and has a known security issue.

 Very good point.

 Being a (somewhat pragmatic) security emphasis person by default, as well
 as a freedomware person, I had been leaning toward the mask it and let
 the user decide viewpoint, but this question changed my mind entirely.

 What about this for a reasonable but still somewhat strict compromise?

 a) A pkg_pretend phase that checks for a set variable (like
 I_KNOW_THE_SECURITY_ISSUES), and dies with an appropriate warning if it's
 not set.

 b) With (a) in place, keeping the package unmasked (unless (c)) but
 forever ~arch, no stable.

 c) Deal with known security issues as normal, that is, mask the package,
 with possible eventual removal.


 It seems to me that this is a reasonable compromise giving both sides
 what they want.  (a) forces the user into a hard opt-in to actually
 install the package, (b) keeps the package at least visible to ordinary
 users (those willing to deal with ~arch at least), and (c) means we can
 still notify users that have opted-in when there's a known security issue.

Look, if you want to make a policy about the stuff, then make a
policy, get council approval, and write it down.
Don't make up silly half-solutions.

-A


 If this proves to be a reasonable compromise, it's possible there's other
 packages for which it can be used as well.

 --
 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 due lavajoe retirement

[Rich Freeman]

On Sat, Dec 1, 2012 at 9:37 PM, Alec Warner anta...@gentoo.org wrote:
 Look, if you want to make a policy about the stuff, then make a
 policy, get council approval, and write it down.
 Don't make up silly half-solutions.

Sure, but I'm not aware of any policy at all concerning packages that
contain bundled libraries.

Rich

Re: [gentoo-dev] Re: Packages up for grabs due lavajoe retirement

[Alec Warner]

On Sat, Dec 1, 2012 at 6:41 PM, Rich Freeman ri...@gentoo.org wrote:
 On Sat, Dec 1, 2012 at 9:37 PM, Alec Warner anta...@gentoo.org wrote:
 Look, if you want to make a policy about the stuff, then make a
 policy, get council approval, and write it down.
 Don't make up silly half-solutions.

 Sure, but I'm not aware of any policy at all concerning packages that
 contain bundled libraries.

 Rich


I know, but some people seem to think Gentoo should have one. Hence my
request to write one down, and get it approved. The point of the
council is to be the decider here; to say 'oh this policy is
reasonable' or 'oh this policy is silly.' I think we are far past the
point where we can reach consensus on the list; that is why we have a
set of people to make these decisions.

-A

[gentoo-dev] Re: Packages up for grabs: prosody + lua deps

[Rafael Goncalves Martins]

On Mon, Nov 26, 2012 at 11:40 AM, Dirkjan Ochtman d...@gentoo.org wrote:

 I'd like to retire from these sometime soon:

 dev-lua/lua-zlib: no other maintainers/herd
 dev-lua/luadbi: no other maintainers/herd
 dev-lua/luaevent: blueness, rafaelmartins
 dev-lua/luaexpat: rafaelmartins
 dev-lua/luasec: rafaelmartins
 net-im/prosody: klausman, rafaelmartins

 AFAICT Rafael isn't very active these days. There shouldn't be that
 much immediate work except for bug 436648. Someone willing to take
 these off my hands?


Yeah, help is very appreciated! Feel free to add yourself as co-maintainer
of any of these packages that I'm listed as maintainer, and to ask
questions related to lua on IRC. I should be around, even if not very
active on package maintenance.

BR,

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

[gentoo-dev] Re: Packages up for grabs due mrness retirement

[Ryan Hill]

On Sat, 07 Apr 2012 00:02:17 +0200
Pacho Ramos pa...@gentoo.org wrote:

 dev-util/dialogblocks
 dev-util/helpblocks

wxwidgets will take these.


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


signature.asc
Description: PGP signature

[gentoo-dev] Re: Packages up for grabs due bass retirement

[Ryan Hill]

On Tue, 03 Apr 2012 00:09:39 +0200
Pacho Ramos pa...@gentoo.org wrote:

 El lun, 19-03-2012 a las 21:20 -0600, Ryan Hill escribió:
  On Mon, 19 Mar 2012 09:34:22 +0100
  Pacho Ramos pa...@gentoo.org wrote:
  
   El dom, 18-03-2012 a las 23:56 -0600, Ryan Hill escribió:
On Sun, 18 Mar 2012 20:25:58 +0100
Pacho Ramos pa...@gentoo.org wrote:

 Due his retirement the following packages need a new maintainer:

 app-doc/ebookmerge

This is something bass wrote that grabs html manuals from
http://htmlhelp.berlios.de (which doesn't exist anymore - it moved to
http://code.google.com/p/htmlhelp/).  I don't really see the usefulness 
of it
since almost all of the content is just html versions of standard 
info/man
pages.  Anyways, it's completely broken as-is.


   
   I also though it could be treecleaned until I saw patches to fix that
   issues are included in:
   https://bugs.gentoo.org/show_bug.cgi?id=388927
  
  Okay, I suppose people do use it.  I'd like to start an app-doc herd (I 
  think
  vapier and me have half of app-doc/* covered anyways).  This would fit in
  there.  In the meantime I'll take it.
  
  
 
 Any news on this herd creation? Looks like that package is still in
 maintainer-needed domain, for now I have fixed all his bugs I think, but
 better create that one for this and other packages that could benefit
 from active maintainers :)

Oops, forgot.  Added myself now.


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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Re: Packages up for grabs due bass retirement

[Pacho Ramos]

El lun, 19-03-2012 a las 21:20 -0600, Ryan Hill escribió:
 On Mon, 19 Mar 2012 09:34:22 +0100
 Pacho Ramos pa...@gentoo.org wrote:
 
  El dom, 18-03-2012 a las 23:56 -0600, Ryan Hill escribió:
   On Sun, 18 Mar 2012 20:25:58 +0100
   Pacho Ramos pa...@gentoo.org wrote:
   
Due his retirement the following packages need a new maintainer:
   
app-doc/ebookmerge
   
   This is something bass wrote that grabs html manuals from
   http://htmlhelp.berlios.de (which doesn't exist anymore - it moved to
   http://code.google.com/p/htmlhelp/).  I don't really see the usefulness 
   of it
   since almost all of the content is just html versions of standard info/man
   pages.  Anyways, it's completely broken as-is.
   
   
  
  I also though it could be treecleaned until I saw patches to fix that
  issues are included in:
  https://bugs.gentoo.org/show_bug.cgi?id=388927
 
 Okay, I suppose people do use it.  I'd like to start an app-doc herd (I think
 vapier and me have half of app-doc/* covered anyways).  This would fit in
 there.  In the meantime I'll take it.
 
 

Any news on this herd creation? Looks like that package is still in
maintainer-needed domain, for now I have fixed all his bugs I think, but
better create that one for this and other packages that could benefit
from active maintainers :)

Thanks



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

[gentoo-dev] Re: Packages up for grabs due www-server herd removal

[Pacho Ramos]

El mié, 21-03-2012 a las 12:26 +0100, Pacho Ramos escribió:
 As discussed in [gentoo-dev] www-servers herd is empty thread,
 we agreed with dropping this herd and let people get what they want
 to maintain. This is the list of orphan packages:
[...]
 www-servers/bozohttpd
[...]

This is a false positive: it already has a maintainer


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

[gentoo-dev] Re: Packages up for grabs due www-server herd removal

[Pacho Ramos]

El mié, 21-03-2012 a las 12:28 +0100, Pacho Ramos escribió:
 El mié, 21-03-2012 a las 12:26 +0100, Pacho Ramos escribió:
  As discussed in [gentoo-dev] www-servers herd is empty thread,
  we agreed with dropping this herd and let people get what they want
  to maintain. This is the list of orphan packages:
 [...]
  www-servers/bozohttpd
 [...]
 
 This is a false positive: it already has a maintainer

The same for:
www-servers/lighttpd
www-servers/pshs


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

[gentoo-dev] Re: Packages up for grabs due bass retirement

[Ryan Hill]

On Mon, 19 Mar 2012 09:34:22 +0100
Pacho Ramos pa...@gentoo.org wrote:

 El dom, 18-03-2012 a las 23:56 -0600, Ryan Hill escribió:
  On Sun, 18 Mar 2012 20:25:58 +0100
  Pacho Ramos pa...@gentoo.org wrote:
  
   Due his retirement the following packages need a new maintainer:
  
   app-doc/ebookmerge
  
  This is something bass wrote that grabs html manuals from
  http://htmlhelp.berlios.de (which doesn't exist anymore - it moved to
  http://code.google.com/p/htmlhelp/).  I don't really see the usefulness of 
  it
  since almost all of the content is just html versions of standard info/man
  pages.  Anyways, it's completely broken as-is.
  
  
 
 I also though it could be treecleaned until I saw patches to fix that
 issues are included in:
 https://bugs.gentoo.org/show_bug.cgi?id=388927

Okay, I suppose people do use it.  I'd like to start an app-doc herd (I think
vapier and me have half of app-doc/* covered anyways).  This would fit in
there.  In the meantime I'll take it.


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


signature.asc
Description: PGP signature