Re: [gentoo-dev] Call for help: python3.5 testing

[Jason Zaman]

On Sun, Aug 07, 2016 at 03:46:40PM -0500, R0b0t1 wrote:
> On Sun, Aug 7, 2016 at 12:27 PM, Mike Gilbert  wrote:
> > Hi all,
> >
> > I would like to make a push to get python3.5 stable in the next few
> > months. There are a couple things that need to happen first.
> >
> > 1. Add python3_5 to PYTHON_COMPAT for current ~arch packages. A list
> > of packages that need to be tested and marked compatible with
> > python3.5 is producted daily.
> >
> > https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt
> >
> > 2. Stabilize any packages necessary to support python3.5. A list is
> > also produced daily. For this step, I imagine we will create one giant
> > stablereq bug for the sake of arch testing efficiency, but feel free
> > to stabilize them ahead of that.
> >
> > https://qa-reports.gentoo.org/output/gpyutils/34-to-35-stablereq.txt
> >
> > If you have some time, please do some testing on packages from the
> > first list. For packages that have a working test phase, don't
> > necessarily expect all tests to pass; just look for regressions from
> > python3.4. For packages that have no test phase, a compile and basic
> > import test (python3.5 -c "import foo") is generally the best we can
> > do.
> >
> 
> I have been using in VMs since near it came out. Main incompatibility
> is with SELinux markings.

I just sent a whole bunch of patches upstream to fix all the outstanding
issues for selinux on python3. If you want to help test, that'd be
awesome. ping me on IRC and i'll give you the stuff.

-- Jason

Re: [gentoo-dev] Packages up for grabs

[Jason Zaman]

On Sun, Aug 07, 2016 at 10:24:08AM +0200, Pacho Ramos wrote:
> This packages are now up for grabs:
> sys-block/zram-init
I'll take this, i use it on my laptops

-- Jason

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

[james]

On 08/07/2016 10:22 PM, Kent Fredric wrote:

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.



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

now and the other languages issue are not part ot the core of Mesos,
or something to that effect I read somewhere.


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


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


Thanks,
James

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

[Kent Fredric]

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

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-08-07 23:59 UTC

[Robin H. Johnson]

The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2016-08-07 23:59 UTC.

Removals:
app-admin/mate-system-tools 20160326-00:51 NP-Hardass927c8d1
app-mobilephone/freesmee20160807-17:21 mgorny41fe748
app-office/lotus-notes  20160802-14:31 mgorny0e3e6ce
app-portage/layman-dbtools  20160802-14:26 mgorny20c46d0
app-portage/pms-test-suite  20160802-14:23 mgorny157553a
dev-haskell/filesystem-conduit  20160802-14:26 mgorny35b08f7
dev-libs/guiloader  20160802-14:25 mgorny3ae6009
dev-libs/guiloader-c++  20160802-14:24 mgorny8464569
dev-perl/regexp-common  20160802-11:29 kentnlfdd766a
dev-python/charade  20160807-17:23 mgorny3a3dc9e
dev-ruby/mongoid20160807-18:17 mgorny7c5b1cb
dev-util/rootstrap  20160807-17:23 mgornyf61c51d
kde-apps/kdebindings-meta   20160806-10:38 johu  25a48d8
kde-base/kimono 20160806-10:39 johu  c958918
kde-base/korundum   20160806-10:39 johu  34c8a9f
kde-base/krossjava  20160806-10:40 johu  62cd6a0
kde-base/krossruby  20160806-10:41 johu  60dca98
kde-base/perlkde20160806-10:42 johu  2785305
kde-base/perlqt 20160806-10:42 johu  11915cb
kde-base/qtruby 20160806-10:43 johu  40ceb4e
kde-base/qyoto  20160806-10:44 johu  5180e69
kde-base/smokegen   20160806-10:44 johu  ba4b837
kde-base/smokekde   20160806-10:45 johu  0d4cf1c
kde-base/smokeqt20160806-10:46 johu  fe7fda6
kde-misc/katelatexplugin20160806-10:48 johu  973a9ca
kde-misc/kosd   20160806-10:48 johu  5703c9a
mate-extra/mate-calc20160806-01:32 NP-Hardass4e8399f
mate-extra/mate-dialogs 20160806-01:34 NP-Hardass7ea5430
media-video/istanbul20160802-14:30 mgorny4b9e90c
net-misc/mknbi  20160802-14:28 mgorny2bf6eff
net-p2p/syncthing-relaysrv  20160807-17:22 mgorny1618ebe

Additions:
app-admin/mate-system-tools 20160807-01:50 NP-Hardass2d37df5
app-admin/prelude-manager   20160717-13:12 gokturk   e7deb2a
app-i18n/fcitx-m17n 20160805-11:19 floppym   5da22d2
app-i18n/fcitx-sayura   20160805-11:21 floppym   a24f369
dev-db/percona-xtrabackup   20160802-11:32 monsieurp 9f553b1
dev-java/javax-mail 20160803-20:56 wizardedite3b3222
dev-libs/libprelude 20160717-13:09 gokturk   a390b60
dev-libs/libpreludedb   20160717-13:11 gokturk   4bb9ebc
dev-perl/Regexp-Common  20160802-11:12 kentnl95b9669
dev-python/flake8-polyfill  20160806-14:48 alunduil  50e5870
dev-python/python-ethtool   20160806-20:55 rafaelmartins 6009c41
dev-ruby/forwardable-extended   20160806-15:38 mrueg 9b08a27
dev-ruby/pathutil   20160806-18:05 mrueg 7ae6ecc
dev-util/meson  20160806-06:47 pacho 288a728
mate-extra/mate-calc20160807-01:43 NP-Hardass097f859
mate-extra/mate-dialogs 20160807-01:58 NP-Hardass72fac36
media-plugins/gst-transcoder20160806-06:52 pacho 8d87d55
net-analyzer/prelude-correlator 20160717-13:14 gokturk   241b67a
net-analyzer/prelude-lml20160717-13:13 gokturk   3a233c7
net-analyzer/prelude-lml-rules  20160717-13:13 gokturk   36c991e
sys-libs/llvm-libunwind 20160719-06:57 mgorny10067c4
www-apps/prewikka   20160717-13:14 gokturk   12bb330

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : robb...@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
dev-ruby/mongoid,removed,mgorny,20160807-18:17,7c5b1cb
dev-util/rootstrap,removed,mgorny,20160807-17:23,f61c51d
dev-python/charade,removed,mgorny,20160807-17:23,3a3dc9e
net-p2p/syncthing-relaysrv,removed,mgorny,20160807-17:22,1618ebe
app-mobilephone/freesmee,removed,mgorny,20160807-17:21,41fe748
kde-misc/katelatexplugin,removed,johu,20160806-10:48,973a9ca
kde-misc/kosd,removed,johu,20160806-10:48,5703c9a
kde-base/smokeqt,removed,johu,20160806-10:46,fe7fda6
kde-base/smokekde,removed,johu,20160806-10:45,0d4cf1c
kde-base/smokegen,removed,johu,20160806-10:44,ba4b837
kde-base/qyoto,removed,johu,20160806-10:44,5180e69
kde-base/qtruby,removed,johu,20160806-10:43,40ceb4e
kde-base/perlqt,removed,johu,20160806-10:42,11915cb
kde-base/perlkde,removed,johu,20160806-10:42,2785305
kde-base/krossruby,removed,johu,20160806-10:41,60dca98
kde-base/krossjava,removed,johu,20160806-10:40,62cd6a0
kde-base/korundum,removed,johu,20160806-10:39,34c8a9f
kde-base/kimono,removed,johu,20160806-10:39,c958918
kde-apps/kdebindings-meta,removed

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] Status of Lua in Gentoo

[William Hubbs]

Hi,

I spoke with rafaelmartins today, and I have joined him as a
co-maintainer for dev-lang/lua. We use it at the office, so I have an
interest in taking it forward.

My first plan is to find the latest version of Lua and look at the
upstream build system to find out what we are doing that they aren't; I
see we do quite a lot of patching which I would rather avoid if
possible.

On Wed, Aug 03, 2016 at 07:59:19PM +0700, Vadim A. Misbakh-Soloviov wrote:
> And, talking on lua.eclass: I already posted it here for review, and mgorny 
> said "kill it with fire" (because eclass was based on ruby-ng with some magic 
> additions from python eclasses, perl ones and php. Well, it really is a bunch 
> of black magic. And it definitelly need to be rewriten, but it takes much 
> time, so I'd like to take some help.

I'll help you out when I can. :-)

> And, talking on lua project, in the times of herds there was lua herd with 
> mabi and rafaelmartins. But both of them looks inactive atm.
> 
> // maybe we can talk about that in jabber?

I'm available mostly on irc, as WilliamH or from the office, whubbs. :-)

Thanks,

William

 


signature.asc
Description: Digital signature

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] Call for help: python3.5 testing

[R0b0t1]

On Sun, Aug 7, 2016 at 12:27 PM, Mike Gilbert  wrote:
> Hi all,
>
> I would like to make a push to get python3.5 stable in the next few
> months. There are a couple things that need to happen first.
>
> 1. Add python3_5 to PYTHON_COMPAT for current ~arch packages. A list
> of packages that need to be tested and marked compatible with
> python3.5 is producted daily.
>
> https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt
>
> 2. Stabilize any packages necessary to support python3.5. A list is
> also produced daily. For this step, I imagine we will create one giant
> stablereq bug for the sake of arch testing efficiency, but feel free
> to stabilize them ahead of that.
>
> https://qa-reports.gentoo.org/output/gpyutils/34-to-35-stablereq.txt
>
> If you have some time, please do some testing on packages from the
> first list. For packages that have a working test phase, don't
> necessarily expect all tests to pass; just look for regressions from
> python3.4. For packages that have no test phase, a compile and basic
> import test (python3.5 -c "import foo") is generally the best we can
> do.
>

I have been using in VMs since near it came out. Main incompatibility
is with SELinux markings.

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

[james]

On 08/07/2016 03:04 PM, Alan McKinnon wrote:

On 07/08/2016 19:36, james wrote:

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



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



I recommend Java as a teaching language at university level.

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

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


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


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





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

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

You volunteering to do the grunt work?



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



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



hth,
James

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

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

[Andrew Savchenko]

On Sun, 07 Aug 2016 10:05:06 +0200 Pacho Ramos wrote:
> This packages are now up for grabs:
> app-admin/cpulimit

Nice tool, I use it sometimes, so I'll take it.

Best regards,
Andrew Savchenko


pgpO3kRrhnkEw.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: turning off grub2 multislot use flag

[William Hubbs]

On Sun, Aug 07, 2016 at 08:28:32PM +0200, Kristian Fiskerstrand wrote:
> It will require a lot of documentation updates (wiki, handbook etc) so I
> wonder if you don't need symlinks for the grub2* names for a while even
> so to ensure compatibility for a deprecation period. New users aren't
> expected to have seen all the news items, so that alone isn't enough
> until the documentation is updated, and docs can't be updated until the
> change has happened itself as itself would be a mismatch.
 
If I were to put symlinks in place keeping the grub2 names, people
would still see the documentation as correct, and more documentation
could be created using the grub2 names, so the symlinks would have to be
kept, so no, I don't see the value in symlinks in this case.

> What is the expected gain from such a change?

The expected gain is one less gentoo-ism. Upstream calls the commands
grub-foo, so we should do the same by default.

William



signature.asc
Description: Digital signature

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 traditional gentoo semantics f

Re: [gentoo-dev] rfc: turning off grub2 multislot use flag

[James Le Cuirot]

On Sun, 7 Aug 2016 12:39:28 -0500
William Hubbs  wrote:
> 
> I feel that new installs don't need multislot since they won't be
> migrating from grub legasy, so I want to turn the multislot flag off
> in the grub2 ebuilds.
> 
> Thoughts?

Fine by me. The difference between us and Debian kept catching me out.
Fedora still calls it grub2 but hey, so what. ;)

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpfE4B6GehpZ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] rfc: turning off grub2 multislot use flag

[Kristian Fiskerstrand]

On 08/07/2016 07:39 PM, William Hubbs wrote:
> All,
> 
> I have spoken with floppym about this (he is the primary maintainer of
> grub2), and he told me to go for it if I want to take on the project, so
> I want some thoughts.
> 

..

> 
> So, again, this would affect new installs, but users can stop it from
> happening on their systems if they want to do so.

It will require a lot of documentation updates (wiki, handbook etc) so I
wonder if you don't need symlinks for the grub2* names for a while even
so to ensure compatibility for a deprecation period. New users aren't
expected to have seen all the news items, so that alone isn't enough
until the documentation is updated, and docs can't be updated until the
change has happened itself as itself would be a mismatch.

What is the expected gain from such a change?

-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[gentoo-dev] rfc: turning off grub2 multislot use flag

[William Hubbs]

All,

I have spoken with floppym about this (he is the primary maintainer of
grub2), and he told me to go for it if I want to take on the project, so
I want some thoughts.

Currently, grub2 defaults, with the multislot use flag on, to renaming
things away from upstream -- for example, grub2-install vs grub-install.

With the multislot use flag off, grub2 doesn't mess with the binary
names; it leaves them the way upstream names them.

I feel that new installs don't need multislot since they won't be
migrating from grub legasy, so I want to turn the multislot flag off in
the grub2 ebuilds.

This would be done along with publishing a news item explaining that if
you want to keep the multislot names, you should add
"sys-boot/grub multislot" to /etc/portage/package.use.

So, again, this would affect new installs, but users can stop it from
happening on their systems if they want to do so.

Thoughts?

William



signature.asc
Description: Digital signature

[gentoo-dev] Call for help: python3.5 testing

[Mike Gilbert]

Hi all,

I would like to make a push to get python3.5 stable in the next few
months. There are a couple things that need to happen first.

1. Add python3_5 to PYTHON_COMPAT for current ~arch packages. A list
of packages that need to be tested and marked compatible with
python3.5 is producted daily.

https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt

2. Stabilize any packages necessary to support python3.5. A list is
also produced daily. For this step, I imagine we will create one giant
stablereq bug for the sake of arch testing efficiency, but feel free
to stabilize them ahead of that.

https://qa-reports.gentoo.org/output/gpyutils/34-to-35-stablereq.txt

If you have some time, please do some testing on packages from the
first list. For packages that have a working test phase, don't
necessarily expect all tests to pass; just look for regressions from
python3.4. For packages that have no test phase, a compile and basic
import test (python3.5 -c "import foo") is generally the best we can
do.

Re: [gentoo-dev] Packages up for grabs

[Michał Górny]

On Sun, 07 Aug 2016 11:44:35 +0200
Michał Górny  wrote:

> Dnia 7 sierpnia 2016 09:16:17 CEST, Pacho Ramos  napisał(a):
> >This packages are now up for grabs:
> >app-arch/lzop
> >dev-libs/check
> >dev-libs/lzo  
> 
> I'll take those three. LZO fits nicely with my other compression tools, and I 
> think check is needed by one of my packages.

I'm sorry, I was wrong about dev-libs/check. I'd prefer if someone else
took it.

-- 
Best regards,
Michał Górny



pgpR9BJeuFBPt.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

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 can't satisfy everyone out of the box.
> >
> >
> > The rest of your response kinda rotates around a central axiom that
> > makes other Linux distributions effective, and "Easy":
> >
> > The lack of choice, a tailored work flow, a target audience, and a
> > narrow focus on what the vendor delivers.
> >
> > Gentoo is fundamentally unlike these things, because the Gentoo way
> > has always been first and foremost about *user choice* and
> > *maximising user choice*  
> 
> Noting in promoting an easy install semantic for a default, buildable 
> system, precludes choice after the system is installed and boot. For 
> examle a default install, using Calamares and ending up with KDE,
> could easily then have kde removed and lxqt installed. That would be
> up to the new user to figure out, via the handbook and the wiki
> 
> 
> > The reality is a giant hunk of the world are *not interested in
> > choice* They want something that works and get out of their way.  
> 
> Quite true, but we're talking about increasing gentoo's update
> amongst those linux leaners, not converting windows/mac users that
> are not interested in alternatives
> 
> >
> > That's why proprietary systems with deep, vertical architecture and
> > product lock-in are still incredibly popular.
> > They understand their market, and they focus on making things work
> > for that market by tailoring it to a very narrow set of features
> > that satisfies 95% of its target.  
> 
> Support is always a crowd pleaser, imho. So with fresh ideas, the
> newest members support those right behind them in line with user
> level issues. Noobs helping noobs. buntu has proven this works, if
> nothing else.
> 
> >
> > Gentoo's target audience is decidedly that other 5%, the group of
> > people who don't mind getting their hands dirty, the group who wade
> > up to their elbows dealing with horrible problems because that's the
> > consequence of the power of choice.  
> 
> What I proposed, models for easier install and a VM/Container system 
> that is secure and allow for experimentation with "jentoo" does not 
> limit, but, encourage choice and experimentation.
> 
> Let's focus on the easy install. Once folks get a running gentoo
> system, most figure out how to manage it and like the choices, build
> from sources (and bin packages for the larger/complex).
> 
> >
> > You can promote pre-boxed Gentoo products if you want, I just think
> > you're barking up the wrong tree if you think doing that will help
> > anybody.  
> 
> You are misconstruing the message. It's a boxed, quick install that 
> would behave going forward, with the same (exact) semantics as a 
> grudge-filled traditional install. The only difference is that first 
> install is
> quick, fast and easy. Nothing else changes, unless this fresh install 
> chooses to embrace additional packaging or alternative packages
> compare to the default install. Nobody needs to make that decision.
> Surely many will then go read the handbook and the wiki to move
> forward. The install just becomes painless for a few basic or default
> examples. We do currently provide an occasional 'liveDVD'. So just
> image one of those, with an  easy install pathway.
> 
> >
> > As with most open source, it requires volunteer effort to make this
> > happen, and its a hard sell to try to convince existing staff to
> > spend more time on producing a thing that exists only to *reduce*
> > user choice for the sake of convenience.  
> 
> Again, you are incorrectly suggesting that these easy installs will 
> preclude traditional gentoo semantics for adding, modif

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 these easy installs wil

[gentoo-dev] Re: Packages up for grabs

[Michael Palimaka]

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

I can take this one.

[gentoo-dev] Re: Empty project: Desktop

[Michael Palimaka]

On 08/08/16 00:37, Pacho Ramos wrote:
> El dom, 07-08-2016 a las 09:07 -0400, NP-Hardass escribió:
>>  [...]
>> Well, that's easily remedied with an alias for the project that
>> contains
>> all the subprojects, no?
>>
> 
> But I don't know if the projects will like to behave in that way...
> because freedesktop-bugs was behaving exactly in that way and, during
> the transition, it was agreed to stop using that and simply CC the
> right projects when needed :/
> 
> From my point of view we should simply kill that "Desktop" project as
> it serves no purpose and CC the relevant projects when needed, as I
> don't recall many cases of the old freedesktop-bugs behaving in the way
> you are suggesting (involving *all* desktop related projects in the bug
> reports). On the other hand it was ending up with most people under the
> subprojects simply ignoring the bug reports assigned to freedesktop-
> bugs
> 
> 
I agree with removing it. Having an empty project doesn't serve any purpose.

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] Empty project: Desktop

[Pacho Ramos]

El dom, 07-08-2016 a las 09:07 -0400, NP-Hardass escribió:
> [...]
> Well, that's easily remedied with an alias for the project that
> contains
> all the subprojects, no?
> 

But I don't know if the projects will like to behave in that way...
because freedesktop-bugs was behaving exactly in that way and, during
the transition, it was agreed to stop using that and simply CC the
right projects when needed :/

>From my point of view we should simply kill that "Desktop" project as
it serves no purpose and CC the relevant projects when needed, as I
don't recall many cases of the old freedesktop-bugs behaving in the way
you are suggesting (involving *all* desktop related projects in the bug
reports). On the other hand it was ending up with most people under the
subprojects simply ignoring the bug reports assigned to freedesktop-
bugs

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] Empty project: Desktop

[NP-Hardass]

On 08/07/2016 06:34 AM, Pacho Ramos wrote:
> El sáb, 06-08-2016 a las 10:29 -0400, NP-Hardass escribió:
>> On 08/06/2016 04:31 AM, Pacho Ramos wrote:
>>>
>>> Now https://wiki.gentoo.org/wiki/Project:Desktop
>>>
>>> Well, it seems that it's only "containing" other subprojects... but
>>> I
>>> am unsure if we really need it. Anyway, he is now empty
>>>
>>>
>>>
>>
>> I think it makes sense to keep desktop environments in a logical
>> grouping.  There isn't a need for an overarching control structure
>> right
>> now, but if there needs to be coordination of efforts, I think
>> keeping
>> it in its current structure allows that to happen more easily than if
>> we
>> didn't have all the DEs in a project together.
>>
> 
> Well, in the past (when herds existed) that was handled by freedesktop-
> bugs project... but now it's different:
> https://wiki.gentoo.org/wiki/Project:Freedesktop
> 
> Anyway, the current desktop project won't either fulfill your
> suggestion as, instead of being a general alias for all the projects
> under it (like freedesktop-bugs herd was), it will simply end up with
> nobody listening as nobody is a member of it :/
> 

Well, that's easily remedied with an alias for the project that contains
all the subprojects, no?

-- 
NP-Hardass



signature.asc
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 ye

Re: [gentoo-dev] Packages up for grabs

[Peter Stuge]

Pacho Ramos wrote:
> x11-libs/xosd

I'll proxy this. I'll look over the bugs.


//Peter

Re: [gentoo-dev] Empty project: Desktop

[Pacho Ramos]

El sáb, 06-08-2016 a las 09:07 -0700, Raymond Jennings escribió:
> If an empty project has subprojects, I think that violates the
> definition of empty.
> 

Empty in the terms of previously having a maintainer taking care of it
and now being "maintainer-needed"... I didn't think I would need to
explain it so deeply :|

Re: [gentoo-dev] Empty project: Desktop

[Pacho Ramos]

El sáb, 06-08-2016 a las 10:29 -0400, NP-Hardass escribió:
> On 08/06/2016 04:31 AM, Pacho Ramos wrote:
> > 
> > Now https://wiki.gentoo.org/wiki/Project:Desktop
> > 
> > Well, it seems that it's only "containing" other subprojects... but
> > I
> > am unsure if we really need it. Anyway, he is now empty
> > 
> > 
> > 
> 
> I think it makes sense to keep desktop environments in a logical
> grouping.  There isn't a need for an overarching control structure
> right
> now, but if there needs to be coordination of efforts, I think
> keeping
> it in its current structure allows that to happen more easily than if
> we
> didn't have all the DEs in a project together.
> 

Well, in the past (when herds existed) that was handled by freedesktop-
bugs project... but now it's different:
https://wiki.gentoo.org/wiki/Project:Freedesktop

Anyway, the current desktop project won't either fulfill your
suggestion as, instead of being a general alias for all the projects
under it (like freedesktop-bugs herd was), it will simply end up with
nobody listening as nobody is a member of it :/

Re: [gentoo-dev] Packages up for grabs

[Pacho Ramos]

El sáb, 06-08-2016 a las 17:09 +0300, Andrew Savchenko escribió:
> On Sat, 6 Aug 2016 13:37:19 + Peter Stuge wrote:
> > 
> > Hi Pacho, many thanks for your work, but..
> > 
> > Pacho Ramos wrote:
> > Pacho Ramos wrote:
> > Pacho Ramos wrote:
> > Pacho Ramos wrote:
> > Pacho Ramos wrote:
> > Pacho Ramos wrote:
> > Pacho Ramos wrote:
> > Pacho Ramos wrote:
> > Pacho Ramos wrote:
> > Pacho Ramos wrote:
> > Pacho Ramos wrote:
> > Pacho Ramos wrote:
> > Pacho Ramos wrote:
> > Pacho Ramos wrote:
> > > 
> > > Date: Sat, 06 Aug 2016 15:22:22 +0200
> > 
> > ..do you think you can arrange to post everything in one mail,
> > instead of 14 different ones in a single day?
> 
> I suppose these posts are automated (at least partially), since each
> of them is linked to a different retirement bug. So you shouldn't
> blame Pacho for his work.
> 
> Best regards,
> Andrew Savchenko

No, sadly all the work is manual... and that is the reason I do every
step per person, because as it takes lots of time, I want to finish one
person completely before either jumping to the next or going to do
other things. 

The reason is that I cannot predict if I will be able to handle all the
remaining cases or, maybe, I will need to do 3 today, 5 tomorrow...
maybe 10 in two months when I have time again. This way at least I let
people to start getting the packages as soon as I finish a person and
other can start to work as soon as possible on the bug reports without
needing to wait for me finishing all.

Then, it's a bit a consequence of the workflow (paradoxically, I have a
different workflow when treecleaning that ends up usually with me
sending a big mail with the packages I am able to hardmask on a day...
and some people complained because they wanted one mail per package
^_^)

Re: [gentoo-dev] Packages up for grabs

[Michał Górny]

Dnia 7 sierpnia 2016 09:16:17 CEST, Pacho Ramos  napisał(a):
>This packages are now up for grabs:
>app-arch/lzop
>dev-libs/check
>dev-libs/lzo

I'll take those three. LZO fits nicely with my other compression tools, and I 
think check is needed by one of my packages.

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

Re: [gentoo-dev] Packages up for grabs

[Patrick Lauer]

On 08/07/2016 10:12 AM, Dirkjan Ochtman wrote:
> On Sun, Aug 7, 2016 at 9:51 AM, Pacho Ramos  wrote:
>> This packages are now up for grabs:
>> app-portage/euscan
> 
> Patrick,
> 
> Are you still keeping euscan running?
> 

Yes. It's not in the best shape, but for now it works well enough to
keep it around.

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

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

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
net-p2p/dogecoin-qt 

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-portage/g-sorcery
app-portage/gs-elpa
app-portage/gs-pypi
app-shells/rust-zshcomp
app-vim/rust-mode
dev-db/cppdb
dev-db/soci
sys-block/zram-init

[gentoo-dev] Empty project: LXDE

[Pacho Ramos]

Now https://wiki.gentoo.org/wiki/Project:LXDE is empty

Feel free to join, anyway, if I don't misremember, LXDE is dead for a
long time in favor of LXQT... in that case treecleaning the packages
would also be an option

Thanks

Re: [gentoo-dev] Packages up for grabs

[Dirkjan Ochtman]

On Sun, Aug 7, 2016 at 9:51 AM, Pacho Ramos  wrote:
> This packages are now up for grabs:
> app-portage/euscan

Patrick,

Are you still keeping euscan running?

Cheers,

Dirkjan

Re: [gentoo-dev] Packages up for grabs

[Dirkjan Ochtman]

On Sun, Aug 7, 2016 at 9:56 AM, Deven Lahoti  wrote:
> What's the policy on maintaining a package if I'm not (yet, hopefully) an
> official dev? I'd like to take on transmission-remote-gtk since I use it
> fairly often.

That would be great!

I think you want to start by looking at proxy maintenance:

https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers

Cheers,

Dirkjan

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-admin/cpulimit
net-misc/htpdate

Re: [gentoo-dev] Packages up for grabs

[Deven Lahoti]

What's the policy on maintaining a package if I'm not (yet, hopefully) an
official dev? I'd like to take on transmission-remote-gtk since I use it
fairly often.

On Aug 7, 2016 03:41, "Pacho Ramos"  wrote:

> This packages are now up for grabs:
> app-misc/sl
> app-portage/epkg
> dev-libs/libmcs
> dev-libs/libmowgli-glib
> dev-libs/libmowgli
> media-sound/guimup
> media-video/miro
> net-irc/atheme-services
> net-irc/charybdis
> net-irc/shadowircd
> net-irc/unrealircd
> net-misc/quickshare
> net-p2p/transmission-remote-gtk
> x11-plugins/prpltwtr
>
>

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-portage/euscan

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-misc/sl
app-portage/epkg
dev-libs/libmcs
dev-libs/libmowgli-glib
dev-libs/libmowgli
media-sound/guimup
media-video/miro
net-irc/atheme-services
net-irc/charybdis
net-irc/shadowircd
net-irc/unrealircd
net-misc/quickshare
net-p2p/transmission-remote-gtk
x11-plugins/prpltwtr

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.

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
dev-util/ketchup

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
app-arch/lzop
app-portage/repo-commit
app-text/discount
dev-lang/squirrel
dev-libs/check
dev-libs/liblist
dev-libs/libstrl
dev-libs/lzo
dev-php/securimage
dev-util/bin_replace_string
dev-util/difffilter
dev-util/geany-plugins
dev-vcs/veracity
net-irc/ultimate
sys-apps/pacman
sys-devel/boost-m4
www-misc/reflector

[gentoo-dev] Packages up for grabs

[Pacho Ramos]

This packages are now up for grabs:
dev-util/rpmdevtools
sys-fs/simple-mtpfs