Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Michał Górny]

On Sun, 4 Dec 2016 21:13:23 -0600
"A. Wilcox"  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 04/12/16 20:58, Mike Gilbert wrote:
> > On Sun, Dec 4, 2016 at 6:31 PM, A. Wilcox 
> > wrote:  
> >> Roadmap - ---
> >> 
> >> Since the shell environment is flexible, this change can be 
> >> implemented almost immediately; the defaults specified in the
> >> Gentoo base profile ensure that at worst nothing will immediately
> >> change.  As forks, derivatives, and other organisations change
> >> the environment variables in their profiles or ``make.conf``
> >> files, all updated ebuilds will immediately reflect the changes.
> >> 
> >> During this, the variables can be added to the EAPI=7
> >> specification, and may eventually be added to PMS §11.1.  
> > 
> > It's not clear to me why this should be defined in PMS, especially
> > if this is going to be a profile variable in make.defaults.  
> 
> > 
> > I think we would only need to add it to PMS if you need to package 
> > manager to compute the value based on the running system. Is that
> > what you had in mind here? If so, you will need to include that
> > algorithm in your patch.
> >   
> 
> Thinking on it a little more, that wouldn't be a good way to go.  We
> can't really rely on lsb_release being present, especially if Portage
> is being run on FreeBSD or a more exotic prefix; sys-apps/lsb-release
> isn't even installed on my relatively 'normal' amd64 Gentoo Linux
> machine.  Additionally, it wouldn't have the bug URL even if it were
> present.

Strictly speaking, it could use $EPREFIX/etc/os-release which has all
the info you need, is installed by baselayout and doesn't require
special wrappers to print it.

Benefits of os-release approach:

- distros don't have to override profiles (which can get problematic if
  a distro uses pretty-much standard Gentoo profiles),

- works for people with custom profiles.

Drawbacks of os-release approach:

- can't do it via profiles,

- doesn't work before baselayout is installed.

The other alternative is to provide an eclass that reads data from
$EPREFIX/os-release and supplies it to the packages that need it.

-- 
Best regards,
Michał Górny



pgpwZXyLYTvXm.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Ulrich Mueller]

> On Sun, 4 Dec 2016, A Wilcox wrote:

> Roadmap
> - ---

> Since the shell environment is flexible, this change can be
> implemented almost immediately; the defaults specified in the Gentoo
> base profile ensure that at worst nothing will immediately change.
> As forks, derivatives, and other organisations change the
> environment variables in their profiles or ``make.conf`` files, all
> updated ebuilds will immediately reflect the changes.

I think that the base profile is the right place where you would
define such variables. As you note, you could do that immediately
without any EAPI change.

> During this, the variables can be added to the EAPI=7 specification,
> and may eventually be added to PMS §11.1.

What would be the advantage if the package manager would define such
variables, instead of them being defined in profiles? Package
managers are not specific to any distribution.

Ulrich


pgpUuKnRVarsk.pgp
Description: PGP signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[A. Wilcox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/12/16 21:21, Daniel Campbell wrote:
> How would we ensure (or encourage) that other distros based on
> Gentoo would follow this practice? Adding things to PMS isn't a
> panacea, sure, but from what I can tell it seems the goal here is
> to allow distros based on us to correctly *show* that without
> changing hundreds of lines in the package tree. Maybe that's
> outside of PMS; if so, where does this belong?

I would hope people would consult base/make.defaults and write their
own, which would lead them towards the variables they need to set.
However, there was a fair amount of legwork I had to do and find out
with good old trial-by-error when I was writing one.


> Of course, this solution requires action/patching on our behalf as
> well, but it seems like a long-term goal that, when completed, may
> be suitable for addition in some sort of standard document, even if
> it's a wiki page on how to roll your own distro based on us.

I have plenty of experience with that and I would be more than willing
to help write such a page if that is desired.


> It didn't seem to me that there was any intention to automatically
> guess which distro it is; the people in charge of each distro's
> package tree should be setting those variables to the correct
> value, and it should be accessible throughout the tree(s).

The original intention wasn't to guess, but I see how PMS is more for
things that are determined at run-time by the package manager rather
than static variables.


> As OP mentioned, at worst it does nothing until it 'spreads'
> throughout the tree. The end result is anyone could fork us, change
> DISTRO and DISTRO_BUG_URL, and instantly have a starting point for
> their new distro. I'm not aware of any other distro that would make
> forking or spinning off _this_ easy. That could turn into renewed
> interest in Gentoo or possibly even better inter-distro relations,
> since bugs would be going to the correct places.

That is one of the main goals of the proposal.  I feel that Gentoo is
missing out on major contributions because it's so difficult for
people in other distros to provide the patches they write.  Making
spins easier is a definite bonus, and results in more contributions.


> To OP: This idea looks good to me; do you have any proofs of
> concept for use in common places like ebuilds, metadata.xml (if you
> intend for it to be used there), etc? If we had a more visual idea
> of how it worked, maybe more people would understand and have an
> idea of where to put it if it doesn't fit in with PMS's scope.

I have some basic stuff that showed this idea was feasible before I
sent it on, but I don't have anything public yet.  I can start with a
branch (as mentioned in thread) and go from there.

Best,
- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYROwTAAoJEMspy1GSK50U6ZEP/2fFOOc1TsABI0lMjE8RFbgM
Jl6c9GGfQJokCQHTTHVOGyUhtDzRztcj3RSOtC5Xopshhj73kPZ+uLkMAhL5jl+6
hQbC6tTYdu6Jqw6ompvqNuaWONnyYfEY8j/fkkop+8YCKZ12rOXD/LtLwaXUMANr
OZP5RDX889q7ZYuel8P7TuyYWK4/F+oVc3T7AOzlPNy68sEAi/L4sGMLupr/geR/
dhPYrC/OSAx2A5zhKfpZCbmm+7fHm0tS3r2SpirTJz2+2fYzbrNbVIE2k5TvMUK3
/dJFzw41W1S8xhebqJoHxslXW5NU6Sj1i7rTMPRHD1jEeuN/nhh29eVt33XIOexi
8G957fie/g5EM3+zcxUCgn+8CSzcCmfgAwUA4MmXgMhqBibk9ZXt7ZlA85WjCQFP
fojVOCgWaNJn9RZjIL9V3UiN4Qjv5kv/m8wjfsH7vwb6DlZ4Kc9NUOVhe2wogNyw
W6WOmnOepolhOlmtB8j9fgKRui9aTU9NO6fhSOXqwvTDn0RzHrELsiGUUNFqjvr2
LE74uJcy7qDtVgCHS6ZRV6YMm9V3L2jPmafS3JfOcY9mA7sZHqR9cW1EF4wpMIAC
eUKDRAG6SwyshZzDJL7V2RmQt64M51diujOQn5M12U8ByQhA5aFnpddIBo+Vbk01
Vg2w69y3HcV4HLU5/2zC
=g8bj
-END PGP SIGNATURE-

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Michael Orlitzky]

On 12/04/2016 10:13 PM, A. Wilcox wrote:
> 
> If there are no other objections to this proposal, would a PR that
> implements this against the Gentoo tree be the best way forward?  If
> so, I can start work on that now while giving more people the chance
> to read over it.  (Would it be more desirable to have all changes in a
> single large commit, or one commit per package?)
> 

Maybe a GLEP with the contents of your first mail? If there's consensus
for the premise and the implementation, it's easy to add the variables.
Then it's only a matter of updating ebuilds.

Since the change is essentially a no-op for Gentoo, I don't think it
will be hard to get maintainers to accept the changes. We do however
have to worry about editing stable ebuilds in-place, and maintainers who
are picky about their packages being modified.

You may wind up having to file bugs for a lot of packages that need a
new revision.

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Daniel Campbell]

On 12/04/2016 07:20 PM, Sam Jorna wrote:
> On Sun, Dec 04, 2016 at 09:13:23PM -0600, A. Wilcox wrote:
>> to read over it.  (Would it be more desirable to have all changes in a
>> single large commit, or one commit per package?)
> 
> I'd think this is one of those cases best suited to a branch and merge 
> commit - best of both worlds.
> 
> But that's just my two cents. :)
> 
Yeah. Small, but numerous changes in many different locations aren't
really suited to our usual one-commit-per-logical change bit. It might
be better to branch off, run the sed call or whatever will be used to
update the entire tree, then submit a PR.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Daniel Campbell]

On 12/04/2016 06:58 PM, Mike Gilbert wrote:
> On Sun, Dec 4, 2016 at 6:31 PM, A. Wilcox  wrote:
>> Roadmap
>> - ---
>>
>> Since the shell environment is flexible, this change can be
>> implemented almost immediately; the defaults specified in the Gentoo
>> base profile ensure that at worst nothing will immediately change.  As
>> forks, derivatives, and other organisations change the environment
>> variables in their profiles or ``make.conf`` files, all updated
>> ebuilds will immediately reflect the changes.
>>
>> During this, the variables can be added to the EAPI=7 specification,
>> and may eventually be added to PMS §11.1.
> 
> It's not clear to me why this should be defined in PMS, especially if
> this is going to be a profile variable in make.defaults.
> 
> I think we would only need to add it to PMS if you need to package
> manager to compute the value based on the running system. Is that what
> you had in mind here? If so, you will need to include that algorithm
> in your patch.
> 
How would we ensure (or encourage) that other distros based on Gentoo
would follow this practice? Adding things to PMS isn't a panacea, sure,
but from what I can tell it seems the goal here is to allow distros
based on us to correctly *show* that without changing hundreds of lines
in the package tree. Maybe that's outside of PMS; if so, where does this
belong?

Of course, this solution requires action/patching on our behalf as well,
but it seems like a long-term goal that, when completed, may be suitable
for addition in some sort of standard document, even if it's a wiki page
on how to roll your own distro based on us.

It didn't seem to me that there was any intention to automatically guess
which distro it is; the people in charge of each distro's package tree
should be setting those variables to the correct value, and it should be
accessible throughout the tree(s).

As OP mentioned, at worst it does nothing until it 'spreads' throughout
the tree. The end result is anyone could fork us, change DISTRO and
DISTRO_BUG_URL, and instantly have a starting point for their new
distro. I'm not aware of any other distro that would make forking or
spinning off _this_ easy. That could turn into renewed interest in
Gentoo or possibly even better inter-distro relations, since bugs would
be going to the correct places.

To OP: This idea looks good to me; do you have any proofs of concept for
use in common places like ebuilds, metadata.xml (if you intend for it to
be used there), etc? If we had a more visual idea of how it worked,
maybe more people would understand and have an idea of where to put it
if it doesn't fit in with PMS's scope.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Sam Jorna]

On Sun, Dec 04, 2016 at 09:13:23PM -0600, A. Wilcox wrote:
> to read over it.  (Would it be more desirable to have all changes in a
> single large commit, or one commit per package?)

I'd think this is one of those cases best suited to a branch and merge 
commit - best of both worlds.

But that's just my two cents. :)

-- 
Sam Jorna (wraeth)
GnuPG Key: D6180C26


signature.asc
Description: Digital signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[A. Wilcox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/12/16 20:58, Mike Gilbert wrote:
> On Sun, Dec 4, 2016 at 6:31 PM, A. Wilcox 
> wrote:
>> Roadmap - ---
>> 
>> Since the shell environment is flexible, this change can be 
>> implemented almost immediately; the defaults specified in the
>> Gentoo base profile ensure that at worst nothing will immediately
>> change.  As forks, derivatives, and other organisations change
>> the environment variables in their profiles or ``make.conf``
>> files, all updated ebuilds will immediately reflect the changes.
>> 
>> During this, the variables can be added to the EAPI=7
>> specification, and may eventually be added to PMS §11.1.
> 
> It's not clear to me why this should be defined in PMS, especially
> if this is going to be a profile variable in make.defaults.

> 
> I think we would only need to add it to PMS if you need to package 
> manager to compute the value based on the running system. Is that
> what you had in mind here? If so, you will need to include that
> algorithm in your patch.
> 

Thinking on it a little more, that wouldn't be a good way to go.  We
can't really rely on lsb_release being present, especially if Portage
is being run on FreeBSD or a more exotic prefix; sys-apps/lsb-release
isn't even installed on my relatively 'normal' amd64 Gentoo Linux
machine.  Additionally, it wouldn't have the bug URL even if it were
present.

We can therefore strike the PMS bits and the patch from the proposal.


If there are no other objections to this proposal, would a PR that
implements this against the Gentoo tree be the best way forward?  If
so, I can start work on that now while giving more people the chance
to read over it.  (Would it be more desirable to have all changes in a
single large commit, or one commit per package?)

Best,
- --arw

- -- 
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYRNtLAAoJEMspy1GSK50UyUAQAJy7whGkLxhjnUR04hT/k0uY
B69MCu3do0TqlAYkpQU/DiCuseeD0UUpXwcUS30RGVUBd6gKsq9vTzAMhvVFEqVM
9wZ+4Gs2yWkMbQ9tOy8rK29fW7M7M4yLcZet6q+7UyieaxFqgpbxGBOZzZC7mlKj
RKDFZdVrE9gMv+zPvKT/MZtYHJouwHcnOC8DD5HN7hvq6HQ5fRdvpd2pIoAKIw9U
d+s8/rIPi2xnFetrF1A3qndHyGhRGqqhXdmff7PIAlZoimVRMXL3jyV+f/W0crDs
J5sq3uzcwqa5Q5ZU9fvRdHGeBVLJQeoej6vtN5uBKinHT9zlCaiJ8kTAt+N7kjz/
QahHh4vrsotBT70/IIIXNRaX5UFoIA9HWQEb84HJROcqj1qodvd3oIoZk18e4HIK
mg+1v0lKuBF9HLPYHjwqUMEgoiMlikCHcTqVUqNsyPRSNnTMz3aPISUwaGVIkVBQ
sQVllCOBEfKp2THbg3OrZfoMpp8nXlJMZBwhElDFUK8leDth8riB4WRw2pdJQYlT
nR1WMimCoUwKxMvsl9RA2O/oix7dmZiAzui3Fe7eoqxVkvL9jWlPXYi0f9acrJmz
uwq4Q/k5bt8WwI9uUlxe5SqR6LTUG0tVfZYk7RB7qZD+yPwwrXA0VLZ8PVm/yJ7j
Qxm6u41m9Ru67XBk49a3
=507s
-END PGP SIGNATURE-

Re: [gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash

[M. J. Everitt]

On 05/12/16 03:06, james wrote:
> On 12/04/2016 06:49 PM, Robin H. Johnson wrote:
>> On Sun, Dec 04, 2016 at 11:07:59PM +, M. J. Everitt wrote:
>>> I gather both Quickbooks and Sage have a more modular approach to
>>> "proper" accounting software applicable to small and large
>>> businesses. I
>>> know my mother used Quickbooks in the past with good success and the
>>> support of her accountant, but Sage is known to be equally
>>> accessible. I
>>> would imagine there is an appropriate version for not-for-profit or
>>> charities, perhaps you can seek advice with the person(s) already
>>> contacted for accounting/finance purposes?!
>> Our CPA (Yes, we do have one) only recommends QuickBooks, but has used a
>> variety of other proprietary systems (none of which he recommends at
>> all!).
>>
>> The catch is that either Quickbooks or Sage would be a violation of the
>> social contract's libre-licence dependence clause.
>>
>> Ledger HAS filled most of our needs thus far, but lacks in reporting and
>> some automation:
>> - I'd love to automatically generate lots of depreciation
>>   entries, but can't yet.
>> - Something to anonymize private information in some entries, so that
>>   the actual Ledgers can be published for transparency.
>>
>
> All of that is routine and easy with GNUcash
>
>
> hth,
> James
>
>
>
Grabbing the bull by the horns here, any willing/able volunteers to aid
robbat2 getting ledger ported to gnucash and up-to-speed maybe? I can't
really volunteer as I'm not good with finance esp. not US and have one
too many pans in the fire right now...! :)

For zlg's benefit .. I wasn't advocating re-writing the social contract
(yet) just questioning whether that may be an unhelpful constraint in
quite an important process, but I sit corrected in that there are libre
solutions to this issue in use in similar environments .. so we just
need to transition ..

2c50 !



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash

[james]

On 12/04/2016 06:49 PM, Robin H. Johnson wrote:

On Sun, Dec 04, 2016 at 11:07:59PM +, M. J. Everitt wrote:

I gather both Quickbooks and Sage have a more modular approach to
"proper" accounting software applicable to small and large businesses. I
know my mother used Quickbooks in the past with good success and the
support of her accountant, but Sage is known to be equally accessible. I
would imagine there is an appropriate version for not-for-profit or
charities, perhaps you can seek advice with the person(s) already
contacted for accounting/finance purposes?!

Our CPA (Yes, we do have one) only recommends QuickBooks, but has used a
variety of other proprietary systems (none of which he recommends at
all!).

The catch is that either Quickbooks or Sage would be a violation of the
social contract's libre-licence dependence clause.

Ledger HAS filled most of our needs thus far, but lacks in reporting and
some automation:
- I'd love to automatically generate lots of depreciation
  entries, but can't yet.
- Something to anonymize private information in some entries, so that
  the actual Ledgers can be published for transparency.



All of that is routine and easy with GNUcash


hth,
James

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Mike Gilbert]

On Sun, Dec 4, 2016 at 6:31 PM, A. Wilcox  wrote:
> Roadmap
> - ---
>
> Since the shell environment is flexible, this change can be
> implemented almost immediately; the defaults specified in the Gentoo
> base profile ensure that at worst nothing will immediately change.  As
> forks, derivatives, and other organisations change the environment
> variables in their profiles or ``make.conf`` files, all updated
> ebuilds will immediately reflect the changes.
>
> During this, the variables can be added to the EAPI=7 specification,
> and may eventually be added to PMS §11.1.

It's not clear to me why this should be defined in PMS, especially if
this is going to be a profile variable in make.defaults.

I think we would only need to add it to PMS if you need to package
manager to compute the value based on the running system. Is that what
you had in mind here? If so, you will need to include that algorithm
in your patch.

Re: [gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash

[Daniel Campbell]

On 12/04/2016 04:03 PM, M. J. Everitt wrote:
> On 04/12/16 23:49, Robin H. Johnson wrote:
>> On Sun, Dec 04, 2016 at 11:07:59PM +, M. J. Everitt wrote:
>>> I gather both Quickbooks and Sage have a more modular approach to
>>> "proper" accounting software applicable to small and large businesses. I
>>> know my mother used Quickbooks in the past with good success and the
>>> support of her accountant, but Sage is known to be equally accessible. I
>>> would imagine there is an appropriate version for not-for-profit or
>>> charities, perhaps you can seek advice with the person(s) already
>>> contacted for accounting/finance purposes?!
>> Our CPA (Yes, we do have one) only recommends QuickBooks, but has used a
>> variety of other proprietary systems (none of which he recommends at
>> all!).
>>
>> The catch is that either Quickbooks or Sage would be a violation of the
>> social contract's libre-licence dependence clause.
>>
>> Ledger HAS filled most of our needs thus far, but lacks in reporting and
>> some automation:
>> - I'd love to automatically generate lots of depreciation
>>   entries, but can't yet.
>> - Something to anonymize private information in some entries, so that
>>   the actual Ledgers can be published for transparency.
>>
> Thanks for the clarification, Robin. It may be worth reviewing that
> social contract to allow us better compliance if deemed worthwhile!
> 
> :]
> 
Compliance with what? If others desire Quickbook support, they can make
a tool to convert from ledger. There's no good reason for a non-profit,
libre software organization to use and depend on proprietary software.
Did nobody learn a lesson from BitKeeper?

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass

[Daniel Campbell]

On 12/04/2016 10:10 AM, james wrote:
> On 12/04/2016 02:22 AM, Robin H. Johnson wrote:
>> On Sat, Dec 03, 2016 at 06:30:29PM -0500, William L. Thomson Jr. wrote:
 
 Net Total: $50,924.19
 
>>> So from 09-16 avg of ~$4.6k per year over 11 years.
>> 10 years of participation, 9 of which we got paid for. So ~$5.7k/year.
>> If we got paid for 2013: ~$5.4k/year over 10 years.
>>
>>> With that really being earned by people doing GSoC. Not the same as if
>>> Google donated a lump sum of money to further development per say the
>>> Councils plans. Only 1 hardware donation.
>> That's the payment to the organization for mentoring and managing the
>> students, separate from what the students doing GSoC earned.
>>
>> If the student's work was of use to Gentoo, then it's ALSO $5000-$5500
>> per student that we've had in man-hours. I do use that disclaimer,
>> because I know the integration rate for Gentoo students much lower than
>> it should be.
>>
>> 2006: 10 students
>> 2007: 8 students
>> 2008: 5 students
>> 2009: 6 students
>> 2010: 16 students
>> 2011: 14 students
>> 2012: 8 students
>> 2013: 6 students
>> 2014: 3 students
>> 2016: 5 students
>>
>> Total: 81 students.
>> Assuming $5k/student: $405,000 in student payments, over 11 years.
>>
>> I don't know how many students we've failed: I do know it's been at
>> least one (I failed them. Their original mentor had medical issues, I
>> took over, and they provided a mocked video of their work and no code by
>> midterm).
>>
>>> I believe past sponsors such as GNi incurred costs in the ~$5k range
>>> monthly.
>>> I would assume some hosting sponsors to be averaging a few thousand
>>> at minimum
>>> per year.
>> The cost to GNi was much closer to $1k/month, mostly in potential lost
>> revenue if the hardware COULD be used for income (it was already a sunk
>> cost, and didn't have other users). For our present major hosting
>> sponsors, I believe we're more in line with $250-$400/month, but again
>> mostly older hardware that isn't of much other salable use.
>>
>>> Just as an example. FreeBSD is seeking $1.25 Million in a fundraiser
>>> with
>>> $882k thus far.
>>> https://www.freebsdfoundation.org/
>> $1.25M is their annual fund-raising target for this year and last. Not a
>> specific fund-raiser, but their annual target.
>> For 2016 Q1-Q3, on the $1.25M, they report $293k in contributions.
>> For 2015, on a $1.25M target, they reported $657k in contributions.
>> For 2014, on a $1M target, they reported $2.4M in contributions.
>>
>>> They seem to average in the hundreds of thousands every year in
>>> contributions
>>> https://www.freebsdfoundation.org/about/financials/
>> They're also got a good few years on us (as do Apache).
>>
>>> Always looked at FreeBSD when I was a Gentoo Trustee. Great
>>> foundation! Passed
>>> the 5 year probation period with IRS, and other stuff.
>> The Apache Foundation was very beneficial to look at I found, because
>> they kept superb public records, but also were not hampered by some of
>> our restrictions about depending on non-open software (they & the perl
>> foundation BOTH use QuickBooks on Windows for their accounting).
> 
> 
> GNUcash is superior to Quickbooks, as it is a 'double entry' accounting
> system. Last time I check Quickbooks was not 'double entry' and that is
> a big deal in accounting.  There is a module that allows entries via
> Android now with GNUcash, but is not an official part of GNUcash.org. I
> use GNUcash with my company, but not the Android smartphone module.
> 
> 
> http://gnucash.org
> 
> http://www.techrepublic.com/article/gnucash-a-powerful-mobile-financial-tool-for-android/
> 
> 
> 
> Serious inquires could be directed to 'gnucash-u...@gnucash.org' as this
> accounting software is robust, under active development and even the
> devs 'chime in' on  routine basis.  All in all, gnucash is an
> outstanding piece of FOSS software; much better than Quickbooks as many
> on the discussion lists attest to on a routine basis. It is in portage
> and it runs on windows and other platforms.
> 
> 
> hth,
> James
> 
> 
>> https://www.apache.org/foundation/records/
>>
>> I draw your attention to their last 990 filing:
>> https://www.apache.org/foundation/records/990-2014.pdf
>> - $1.2M in annual income
>> - $858k spend on infrastructure,
>>   of which >$400k was marked directly as IT spending.
>> - $1.8M in net assets
>>
> 
> 
iirc, we're using Ledger (http://ledger-cli.org), which is also
double-entry accounting. It uses a text file for its information, and
has a ton of reporting features that make it trivial to produce reports.
I use it to manage my personal finances, as well.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Proposal for addition of distribution variables

[Brian Dolbec]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Sun, 4 Dec 2016 17:31:30 -0600
"A. Wilcox"  wrote:

> ===
> Proposal for addition of distribution variables
> ===
> 
> :Author:
>   A. Wilcox (Adélie Linux)
> :Date:
>   2016-12-04
> :Status:
>   Request for Comment
> 
> 
> 
> 
> Introduction
> - 
> 
> This proposal outlines the addition of environment variables to a
> future EAPI for the purposes of identifying the builder of packages,
> and a route for their more immediate addition to the Gentoo package
> tree before the next EAPI is published.
> 
> 
> Background
> - --
> 
> The Gentoo package repository is used not only by thousands of users,
> but also used by other distributions and organisations, such as
> Funtoo, CoreOS, and Google ChromeOS.  From the Gentoo Foundation's own
> charter, it self-describes in the following way: "Gentoo is a
> metadistribution".  That allows users to make their own flavours of
> Gentoo themselves.  Several forks already exist, including Exherbo,
> Funtoo, Sabayon, Galapagos, Vida, and Calculate.  Google also
> maintains a fork, ChromeOS, for their Chromebook laptops.  CoreOS also
> uses Gentoo's repository for their distribution.  In addition, there
> are also binary distributions such as Pentoo and Adélie that provide
> additional value but are not, in so many words, a 'fork' of Gentoo.
> 
> 
> Current Situation
> - -
> 
> Currently, forks and derivatives of Gentoo are required to choose one
> of only two options.  They can either use the tree as is, which causes
> packages to identify as being built for Gentoo and causes most
> autoconf -based packages (and some CMake packages in KDE) to have
> their bug report URLs to point to bugs.g.o.  Alternatively, they can
> fork the Git repository, requiring the need of manual merges when
> conflicts arise, and additional wasted effort when upstreams release
> new versions of software.
> 
> 
> Deficiencies
> - 
> 
> If a fork or derivative of Gentoo does not have the manpower or
> resources to modify all ebuilds that mention the Gentoo name / bug URL
> (about 1500 at my last count), then both distributions suffer.  Users
> of the fork will file bugs with Gentoo that are not bugs in Gentoo.
> Developers of the fork will not know about said bugs, and be unable to
> fix them.  Gentoo bug-wranglers and devs will have to waste time and
> resources testing bugs, finding out they are not even Gentoo bugs, and
> closing them as WONTFIX or WORKSFORME.
> 
> If they choose the alternative of forking the repository and changing
> these parameters in ebuilds, then it makes upstreaming their
> improvements much more difficult.  Sabayon has a repository on GitHub
> specifically for this, and Adélie wastes continual effort applying
> patches against the tree as it evolves.
> 
> 
> Solution Objectives
> - ---
> 
> * Protect Gentoo's name, trademark, and reputation by avoiding any
>   appearance that derivative distributions are associated with Gentoo.
> 
> * Lessen number of inappropriate bugs filed on bugs.g.o due to forks
> and derivatives.
> 
> * Foster better collaboration and sharing of improvements between
>   Gentoo and its forks/derivatives.
> 
> * Future potential changes to the bug report URL, while exceedingly
>   unlikely, is additionally made easier.
> 
> 
> Solution Vision
> - ---
> 
> I hereby propose adding the following two variables to the src_*
> phases.  None of these variables will have a default specified in PMS
> if they are added.
> 
> :``${DISTRO}``:
>   The name of the distribution.  This would be set in
>   ``profiles/base/make.defaults`` on Gentoo to "Gentoo".
> 
> :``${DISTRO_BUG_URL}``:
>   The URL to use to report bugs with software on the distribution.
>   This would be set to "https://bugs.gentoo.org/"; on Gentoo.
> 
> By replacing references to 'Gentoo' passed to ./configure, make, etc
> with ``${DISTRO}``, distributions like Sabayon, Calculate, and Adélie
> will be able to notate their name as the distributor on packages.
> This will affect packages such as LibreOffice, OpenRC, X.Org, and KDE,
> which are all compiled with the name of the distribution internally.
> They use this for bug information, and having the proper distribution
> name will allow for more proper bug handling and ensure less
> inappropriate blame is assigned to Gentoo.  This also ensures that the
> fork or derivative's own mailing lists, forums, and so on are searched
> and contacted before Gentoo's.
> 
> By replacing references to 'bugs.gentoo.org' passed to ./configure
> with ``${DISTRO_BUG_URL}``, the Gentoo project will have a significant
> reduction in wasted effort handling inappropriately filed bugs when
> the issues are caused by changes by the forks and derivatives.
> 
> 
> Roadmap
> - ---
> 
> Since the shell environment is flexible, this change can be
> implement

Re: [gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash

[james]

On 12/04/2016 05:55 PM, Robin H. Johnson wrote:

(OT accounting systems)



If there is a good GNUCash support for non-profit accounting (which does
differ from small-business accounting, see [2]), and matching
documentation for it, I'm VERY interested to know about it.


Robin,

I posted on on the gnucash list and got some responses. You should join 
that list and get your detailed questions answered. Gnucash has a 
wonderful collection of expertise on that list and they appear to be

many 'non-profits' using gnucash and they are quiet helpful::

I posted this::


On Sun, Dec 4, 2016 at 6:18 PM james  wrote:
Hello gnucash users.
I use gnucash for my small business, for years and I'm quite happy 
with it. Recently, I was ask if Gnucash has as good of support for 
501(c)3 non-profits as does ledger (www.ledger-cli.org)?

Any and all comments are warmly received.

James


And the private response was::

"At its heart, anything you can do with a pen-and-paper system Double 
Entry Accounting system, you can also do with GnuCash. This includes 
keeping books for a 501(c)(3). Several of us do so.


There are a few things you might want to customize: the "Profit/Loss" 
report is misnamed for a non-profit organization, for instance, and the 
standard business chart of accounts does not match the categories that 
the IRS wants things to be in for the annual tax filing. But those are 
all easy to change."



So just join gnucash-user and get a solution you are happy with.

hth,
James

Re: [gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash

[james]

On 12/04/2016 05:55 PM, Robin H. Johnson wrote:

(OT accounting systems)

On Sun, Dec 04, 2016 at 01:10:16PM -0500, james wrote:

GNUcash is superior to Quickbooks, as it is a 'double entry' accounting
system. Last time I check Quickbooks was not 'double entry' and that is
a big deal in accounting.

QuickBooks is double-entry, and has been for a very long time; It did
used to obscure the fact before, to make accounting 'easier' for
non-accounting people to understand.

For the Foundation, I'm presently using Ledger-CLI [1], but this is a
hurdle for any third-party financial auditing (we should be prepared at
all times for a real financial audit), because they want data in
quickbooks format.


GNUcash can import/export  any number of common/proprietary formats
including quickbooks. Quickbooks serves as the largest base of 
frustrated users that migrate (routinely) to gnucash, particularly

for custom and unique and open needs. Gnucash, found in the protage tree
has these flags:: chipcard debug doc gnome-keyring hbci mysql ofx 
postgres python quotes sqlite


So it looks like you have a choice of sql mechanisms to aid your 
customization needs. Combine that with the Android terminal feature and 
that means that lots of fiduciary oriented folks at gentoo could file 
reports and make/parse entry data, so you have a responsible team of 
folks in the 'accountability-matrix' at the gentoo foundation.




If there is a good GNUCash support for non-profit accounting (which does
differ from small-business accounting, see [2]), and matching
documentation for it, I'm VERY interested to know about it.



GNUcash is very open and I've read about all sorts of custom reports and 
modules for a plethora of varied needs (gnucash-user). My company needs 
are very modest, so I have not ventured into customizing gnucash. When I 
take my annual reports to my tax accountant (mid sized Accounting firm) 
they are always impressed with the quality of the reports and the fact I 
can at anytime print a complete ledger, or specify to/from dates, with 
detailed annotations of all events/transactions/anomalies.


In 27 year of having fiduciary responsibilities at a variety of 
organizations, none of my teams/companies have been audited by the IRS. 
Squeaky, tight-assed accounting and knowing your business, is reflected 
in the team and the documents you send to the IRS; it's just that 
simple, regardless of organizational structure. A 'tight-ass' is a 
tight-ass, reflected in your documents and 2 minutes of browsing by a 
seasoned CPA/auditor and they know more about you than you do. In 
(tax)accounting, there are only A+ and F participants, imho.



Here are a few links you can ponder, before joining the mailing list and
formulating specific questions as to what you want(need) in an 
accounting package for a non-profit.


http://wiki.gnucash.org/wiki/Custom_Reports#Get_to_know_Scheme

http://wiki.gnucash.org/wiki/Custom_Reports_Using_Eguile

In your second reference, I do not see any thing that gnucash is not 
able to do; mostly with a judicious naming and organization of your 
'chart of accounts'. In fact the only report that does not have a 
functional equivalent is the 'Statement of Functional Expenses'. But 
that should not be too difficult to create; but maybe not to your standards?



Standard reports required for example "Net assets" have a gnucash 
equivalent, which could be further customized to your liking.


Things like "Nonprofit expenses are reported by these functions::
Program, management and general, and fundraising", would be handled
structurally as your 'chart of accounts' where you define the structure. 
Perhaps you need an accountant to help you define your 'chart of accounts'?


Surely Gentoo has as specific CPA advising the organization?
If you are in  So. Calif, I know a cranky old vet, that worked for the 
IRS and is brilliant. He's a bit of an 'old bastard', but he has a soft 
touch.  He's not too computer literate, but he know the IRS inside and 
out. He might help you out in exchange for putting gentoo on an old 
lappy? In fact, he can show you how to read 'Title 26' of the IRS code 
for goodies not found in those little pamphlets that are publish by the 
IRS, should you need a 'deep dive', or ever experience an audit.

But that is no substitute for an extended relationship with a practicing
CPA over the long term. The aforementioned expert can get you where you 
need to be, for little in the way of compensation. If you take a mess to 
a CPA, it's going to cost theGentoo Foundation (GF) a bundle to sort 
out. If you clean it up, first, and walk in with pristine reports and 
documentation and the 'old bastard' the CPA will not be able to rape you 
(financially). Caveat emptor.



Link (3) looks like a fine organization, but, I'd make sure there is 
some real experience on that team, as the pres_elect is prolly going
to smack lots of tech endeavers, centric to Calif. around a bit once in 
office; just 

Re: [gentoo-dev] [PATCH] depend.apache.eclass EAPI=6 support

[Mike Gilbert]

On Sun, Dec 4, 2016 at 6:18 PM, Andreas K. Huettel  wrote:
>
> Please review. Given that I'm only tangentially involved with Apache myself, I
> would like to keep the changes to the eclass minimal...
>
> [The last nontrivial changes to the eclass were made in 2012 and 2008.]

For future patches, please use git send-email if possible. Makes it
easier to review in an email client.

> +   declare -f -F get_libdir > /dev/null ||

Nit: the -F option implies -f; passing both is unnecessary.

Otherwise, the changes seem fine.

Re: [gentoo-dev] [PATCH] depend.apache.eclass EAPI=6 support

[Michael Orlitzky]

On 12/04/2016 06:18 PM, Andreas K. Huettel wrote:
> Starting with EAPI=6, the variables APACHE_BASEDIR and APACHE_MODULESDIR
> are not exported in global scope anymore.

Currently, we emit a warning when using depend.apache with EAPI=6. How
many packages are triggering that warning? If we stop exporting those
two variables, then EAPI=6 users of apache-module.eclass are going to
start installing modules into the root.

[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2016-12-04 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-12-04 23:59 UTC.

Removals:
games-action/awesomenauts20161204-19:02 chewi6b134b7

Additions:
app-admin/mtail  20161129-08:36 zmedico  eac7a87
dev-libs/caliper 20161130-18:15 junghans c7800fe
dev-ml/topkg 20161128-15:33 aballier f453a83
dev-perl/BSON20161204-20:38 kentnl   922ea78
dev-perl/IO-Socket-Multicast 20161201-20:42 dilfridgea591271
dev-python/astroplan 20161130-23:22 bicatali b6cca3c
dev-python/mmh3  20161130-00:44 williamh 2fcfbbd
dev-python/pytest-pep8   20161130-14:23 polynomial-c d0e539e
dev-python/regions   20161130-23:23 bicatali 6b3419c
dev-python/xarray20161202-20:32 jlec 41d064a
dev-util/rustfmt 20160711-13:45 cardoe   4719aa4
net-libs/ignition-msgs   20161129-09:49 aballier 8713448
sci-libs/h5part  20161202-00:32 junghans 8c97cd4
sys-apps/highway 20161201-17:21 alicef   83e646e
sys-devel/slibtool   20161204-00:51 monsieurpde29b98
virtual/python-cffi  20161130-15:10 mgorny   32a430d
virtual/tmpfiles 20161201-22:05 williamh 8d0d6b0
x11-misc/xiccd   20161129-10:26 marecki  c0723da

--
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:
games-action/awesomenauts,removed,chewi,20161204-19:02,6b134b7
Added Packages:
sys-devel/slibtool,added,monsieurp,20161204-00:51,de29b98
dev-perl/BSON,added,kentnl,20161204-20:38,922ea78
dev-python/xarray,added,jlec,20161202-20:32,41d064a
sci-libs/h5part,added,junghans,20161202-00:32,8c97cd4
virtual/tmpfiles,added,williamh,20161201-22:05,8d0d6b0
dev-perl/IO-Socket-Multicast,added,dilfridge,20161201-20:42,a591271
sys-apps/highway,added,alicef,20161201-17:21,83e646e
dev-python/regions,added,bicatali,20161130-23:23,6b3419c
dev-python/astroplan,added,bicatali,20161130-23:22,b6cca3c
dev-libs/caliper,added,junghans,20161130-18:15,c7800fe
virtual/python-cffi,added,mgorny,20161130-15:10,32a430d
dev-util/rustfmt,added,cardoe,20160711-13:45,4719aa4
dev-python/pytest-pep8,added,polynomial-c,20161130-14:23,d0e539e
dev-python/mmh3,added,williamh,20161130-00:44,2fcfbbd
net-libs/ignition-msgs,added,aballier,20161129-09:49,8713448
x11-misc/xiccd,added,marecki,20161129-10:26,c0723da
app-admin/mtail,added,zmedico,20161129-08:36,eac7a87
dev-ml/topkg,added,aballier,20161128-15:33,f453a83

Done.

Re: [gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash

[M. J. Everitt]

On 04/12/16 23:49, Robin H. Johnson wrote:
> On Sun, Dec 04, 2016 at 11:07:59PM +, M. J. Everitt wrote:
>> I gather both Quickbooks and Sage have a more modular approach to
>> "proper" accounting software applicable to small and large businesses. I
>> know my mother used Quickbooks in the past with good success and the
>> support of her accountant, but Sage is known to be equally accessible. I
>> would imagine there is an appropriate version for not-for-profit or
>> charities, perhaps you can seek advice with the person(s) already
>> contacted for accounting/finance purposes?!
> Our CPA (Yes, we do have one) only recommends QuickBooks, but has used a
> variety of other proprietary systems (none of which he recommends at
> all!).
>
> The catch is that either Quickbooks or Sage would be a violation of the
> social contract's libre-licence dependence clause.
>
> Ledger HAS filled most of our needs thus far, but lacks in reporting and
> some automation:
> - I'd love to automatically generate lots of depreciation
>   entries, but can't yet.
> - Something to anonymize private information in some entries, so that
>   the actual Ledgers can be published for transparency.
>
Thanks for the clarification, Robin. It may be worth reviewing that
social contract to allow us better compliance if deemed worthwhile!

:]



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash

[Robin H. Johnson]

On Sun, Dec 04, 2016 at 11:07:59PM +, M. J. Everitt wrote:
> I gather both Quickbooks and Sage have a more modular approach to
> "proper" accounting software applicable to small and large businesses. I
> know my mother used Quickbooks in the past with good success and the
> support of her accountant, but Sage is known to be equally accessible. I
> would imagine there is an appropriate version for not-for-profit or
> charities, perhaps you can seek advice with the person(s) already
> contacted for accounting/finance purposes?!
Our CPA (Yes, we do have one) only recommends QuickBooks, but has used a
variety of other proprietary systems (none of which he recommends at
all!).

The catch is that either Quickbooks or Sage would be a violation of the
social contract's libre-licence dependence clause.

Ledger HAS filled most of our needs thus far, but lacks in reporting and
some automation:
- I'd love to automatically generate lots of depreciation
  entries, but can't yet.
- Something to anonymize private information in some entries, so that
  the actual Ledgers can be published for transparency.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[gentoo-dev] RFC: Proposal for addition of distribution variables

[A. Wilcox]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

===
Proposal for addition of distribution variables
===

:Author:
  A. Wilcox (Adélie Linux)
:Date:
  2016-12-04
:Status:
  Request for Comment




Introduction
- 

This proposal outlines the addition of environment variables to a
future EAPI for the purposes of identifying the builder of packages,
and a route for their more immediate addition to the Gentoo package
tree before the next EAPI is published.


Background
- --

The Gentoo package repository is used not only by thousands of users,
but also used by other distributions and organisations, such as
Funtoo, CoreOS, and Google ChromeOS.  From the Gentoo Foundation's own
charter, it self-describes in the following way: "Gentoo is a
metadistribution".  That allows users to make their own flavours of
Gentoo themselves.  Several forks already exist, including Exherbo,
Funtoo, Sabayon, Galapagos, Vida, and Calculate.  Google also
maintains a fork, ChromeOS, for their Chromebook laptops.  CoreOS also
uses Gentoo's repository for their distribution.  In addition, there
are also binary distributions such as Pentoo and Adélie that provide
additional value but are not, in so many words, a 'fork' of Gentoo.


Current Situation
- -

Currently, forks and derivatives of Gentoo are required to choose one
of only two options.  They can either use the tree as is, which causes
packages to identify as being built for Gentoo and causes most
autoconf -based packages (and some CMake packages in KDE) to have
their bug report URLs to point to bugs.g.o.  Alternatively, they can
fork the Git repository, requiring the need of manual merges when
conflicts arise, and additional wasted effort when upstreams release
new versions of software.


Deficiencies
- 

If a fork or derivative of Gentoo does not have the manpower or
resources to modify all ebuilds that mention the Gentoo name / bug URL
(about 1500 at my last count), then both distributions suffer.  Users
of the fork will file bugs with Gentoo that are not bugs in Gentoo.
Developers of the fork will not know about said bugs, and be unable to
fix them.  Gentoo bug-wranglers and devs will have to waste time and
resources testing bugs, finding out they are not even Gentoo bugs, and
closing them as WONTFIX or WORKSFORME.

If they choose the alternative of forking the repository and changing
these parameters in ebuilds, then it makes upstreaming their
improvements much more difficult.  Sabayon has a repository on GitHub
specifically for this, and Adélie wastes continual effort applying
patches against the tree as it evolves.


Solution Objectives
- ---

* Protect Gentoo's name, trademark, and reputation by avoiding any
  appearance that derivative distributions are associated with Gentoo.

* Lessen number of inappropriate bugs filed on bugs.g.o due to forks and
  derivatives.

* Foster better collaboration and sharing of improvements between
  Gentoo and its forks/derivatives.

* Future potential changes to the bug report URL, while exceedingly
  unlikely, is additionally made easier.


Solution Vision
- ---

I hereby propose adding the following two variables to the src_*
phases.  None of these variables will have a default specified in PMS
if they are added.

:``${DISTRO}``:
  The name of the distribution.  This would be set in
  ``profiles/base/make.defaults`` on Gentoo to "Gentoo".

:``${DISTRO_BUG_URL}``:
  The URL to use to report bugs with software on the distribution.
  This would be set to "https://bugs.gentoo.org/"; on Gentoo.

By replacing references to 'Gentoo' passed to ./configure, make, etc
with ``${DISTRO}``, distributions like Sabayon, Calculate, and Adélie
will be able to notate their name as the distributor on packages.
This will affect packages such as LibreOffice, OpenRC, X.Org, and KDE,
which are all compiled with the name of the distribution internally.
They use this for bug information, and having the proper distribution
name will allow for more proper bug handling and ensure less
inappropriate blame is assigned to Gentoo.  This also ensures that the
fork or derivative's own mailing lists, forums, and so on are searched
and contacted before Gentoo's.

By replacing references to 'bugs.gentoo.org' passed to ./configure with
``${DISTRO_BUG_URL}``, the Gentoo project will have a significant
reduction in wasted effort handling inappropriately filed bugs when
the issues are caused by changes by the forks and derivatives.


Roadmap
- ---

Since the shell environment is flexible, this change can be
implemented almost immediately; the defaults specified in the Gentoo
base profile ensure that at worst nothing will immediately change.  As
forks, derivatives, and other organisations change the environment
variables in their profiles or ``make.conf`` files, all updated
ebuilds will immediately reflect the ch

[gentoo-dev] [PATCH] depend.apache.eclass EAPI=6 support

[Andreas K. Huettel]

Please review. Given that I'm only tangentially involved with Apache myself, I 
would like to keep the changes to the eclass minimal... 

[The last nontrivial changes to the eclass were made in 2012 and 2008.]

-- 

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

From 895b4776d7ebad2bcafb7ab0e1023c4115075dc0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20K=2E=20H=C3=BCttel?= 
Date: Mon, 5 Dec 2016 00:11:00 +0100
Subject: [PATCH] depend.apache.eclass: Make it work with EAPI=6; see below for
 details.

Starting with EAPI=6, the variables APACHE_BASEDIR and APACHE_MODULESDIR
are not exported in global scope anymore. Instead, ebuilds can use
get_apache_basedir and get_apache_modulesdir. Usage and applicable
restrictions are the same as for get_libdir.
---
 eclass/depend.apache.eclass | 44 +++-
 1 file changed, 35 insertions(+), 9 deletions(-)

diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass
index b69c2ec..51fdde2 100644
--- a/eclass/depend.apache.eclass
+++ b/eclass/depend.apache.eclass
@@ -40,17 +40,11 @@
 # }
 # @CODE
 
-inherit multilib
-
 case ${EAPI:-0} in
 	0|1|2|3|4|5)
+		inherit multilib
 		;;
 	6)
-		ewarn
-		ewarn "EAPI=${EAPI} is not supported by depend.apache.eclass."
-		ewarn "This means that ${CATEGORY}/${PF} is most likely buggy."
-		ewarn "Please file a report on https://bugs.gentoo.org/";
-		ewarn
 		;;
 	*)
 		die "EAPI=${EAPI} is not supported by depend.apache.eclass"
@@ -85,6 +79,8 @@ esac
 # @DESCRIPTION:
 # Path to the server root directory.
 # This variable is set by the want/need_apache functions.
+# Only available in EAPIs 0 through 5. For later EAPIs, please
+# use get_apache_basedir.
 
 # @ECLASS-VARIABLE: APACHE_CONFDIR
 # @DESCRIPTION:
@@ -105,6 +101,8 @@ esac
 # @DESCRIPTION:
 # Path where we install modules.
 # This variable is set by the want/need_apache functions.
+# Only available in EAPIs 0 through 5. For later EAPIs, please
+# use get_apache_modulesdir.
 
 # @ECLASS-VARIABLE: APACHE_DEPEND
 # @DESCRIPTION:
@@ -141,11 +139,16 @@ _init_apache2() {
 	APACHE_BIN="/usr/sbin/apache2"
 	APACHE_CTL="/usr/sbin/apache2ctl"
 	APACHE_INCLUDEDIR="/usr/include/apache2"
-	APACHE_BASEDIR="/usr/$(get_libdir)/apache2"
 	APACHE_CONFDIR="/etc/apache2"
 	APACHE_MODULES_CONFDIR="${APACHE_CONFDIR}/modules.d"
 	APACHE_VHOSTS_CONFDIR="${APACHE_CONFDIR}/vhosts.d"
-	APACHE_MODULESDIR="${APACHE_BASEDIR}/modules"
+
+	case ${EAPI:-0} in
+		0|1|2|3|4|5)
+			APACHE_BASEDIR="/usr/$(get_libdir)/apache2"
+			APACHE_MODULESDIR="${APACHE_BASEDIR}/modules"
+			;;
+	esac
 }
 
 _init_no_apache() {
@@ -329,4 +332,27 @@ has_apache_threads_in() {
 	fi
 }
 
+# @FUNCTION: get_apache_basedir
+# @USAGE: get_apache_basedir
+# @DESCRIPTION:
+# EAPI=6 or later: prints out the apache basedir, e.g., /usr/lib64/apache2
+# Can only be called in src_* phases, and in particular NOT in global scope.
+# Replacement for the APACHE_BASEDIR variable.
+get_apache_basedir() {
+	declare -f -F get_libdir > /dev/null || 
+		die "depend.apache.eclass: get_apache_basedir can only be called in phase functions of EAPI=6 and later"
+	echo -n "/usr/$(get_libdir)/apache2"
+}
+
+# @FUNCTION: get_apache_modulesdir
+# @USAGE: get_apache_modulesdir
+# @DESCRIPTION:
+# EAPI=6 or later: prints out the apache module installation directory, e.g.,
+# /usr/lib64/apache2/modules
+# Can only be called in src_* phases, and in particular NOT in global scope.
+# Replacement for the APACHE_MODULESDIR variable.
+get_apache_modulesdir() {
+	echo -n "$(get_apache_basedir)/modules"
+}
+
 EXPORT_FUNCTIONS pkg_setup
-- 
2.11.0.rc2

Re: [gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash

[M. J. Everitt]

On 04/12/16 22:55, Robin H. Johnson wrote:
> (OT accounting systems)
>
> On Sun, Dec 04, 2016 at 01:10:16PM -0500, james wrote:
>> GNUcash is superior to Quickbooks, as it is a 'double entry' accounting 
>> system. Last time I check Quickbooks was not 'double entry' and that is 
>> a big deal in accounting. 
> QuickBooks is double-entry, and has been for a very long time; It did
> used to obscure the fact before, to make accounting 'easier' for
> non-accounting people to understand.
>
> For the Foundation, I'm presently using Ledger-CLI [1], but this is a
> hurdle for any third-party financial auditing (we should be prepared at
> all times for a real financial audit), because they want data in
> quickbooks format.
>
> If there is a good GNUCash support for non-profit accounting (which does
> differ from small-business accounting, see [2]), and matching
> documentation for it, I'm VERY interested to know about it.
>
> Why Ledger? The Software Freedom Conservancy started a project aimed at
> Non-Profit accounting [3], wrapped around Ledger, which covers far more
> of the non-profit nuances than GNUCash does.
>
> They included enough documentation in how to specifically configure
> Ledger for non-profit usage, so it was easy to get going since I already
> used Ledger for my personal accounting.
>
> Ledger being plain-text based does work very well with version control,
> even for multiple parties (I enlisted help to convert old bank
> statements).
>
> [1] http://www.ledger-cli.org/
> [2] http://www.accountingcoach.com/nonprofit-accounting/explanation/1
> [3] https://sfconservancy.org/npoacct/
>
I gather both Quickbooks and Sage have a more modular approach to
"proper" accounting software applicable to small and large businesses. I
know my mother used Quickbooks in the past with good success and the
support of her accountant, but Sage is known to be equally accessible. I
would imagine there is an appropriate version for not-for-profit or
charities, perhaps you can seek advice with the person(s) already
contacted for accounting/finance purposes?!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Robin H. Johnson]

On Sun, Dec 04, 2016 at 10:26:11PM +, M. J. Everitt wrote:
> Is it worth the Foundation dropping a few $ for that hardware to *get*
> transported to its rightful destination, or shall we wait a few more
> years for something to happen!? :)
The costs of shipping it was already approved, we're just waiting for
Alec to actually do it.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

[gentoo-dev] (OT) Accounting systems: Ledger-CLI vs GNUcash

[Robin H. Johnson]

(OT accounting systems)

On Sun, Dec 04, 2016 at 01:10:16PM -0500, james wrote:
> GNUcash is superior to Quickbooks, as it is a 'double entry' accounting 
> system. Last time I check Quickbooks was not 'double entry' and that is 
> a big deal in accounting. 
QuickBooks is double-entry, and has been for a very long time; It did
used to obscure the fact before, to make accounting 'easier' for
non-accounting people to understand.

For the Foundation, I'm presently using Ledger-CLI [1], but this is a
hurdle for any third-party financial auditing (we should be prepared at
all times for a real financial audit), because they want data in
quickbooks format.

If there is a good GNUCash support for non-profit accounting (which does
differ from small-business accounting, see [2]), and matching
documentation for it, I'm VERY interested to know about it.

Why Ledger? The Software Freedom Conservancy started a project aimed at
Non-Profit accounting [3], wrapped around Ledger, which covers far more
of the non-profit nuances than GNUCash does.

They included enough documentation in how to specifically configure
Ledger for non-profit usage, so it was easy to get going since I already
used Ledger for my personal accounting.

Ledger being plain-text based does work very well with version control,
even for multiple parties (I enlisted help to convert old bank
statements).

[1] http://www.ledger-cli.org/
[2] http://www.accountingcoach.com/nonprofit-accounting/explanation/1
[3] https://sfconservancy.org/npoacct/

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[William L. Thomson Jr.]

On Sunday, December 4, 2016 2:15:59 PM EST Alec Warner wrote:
> On Fri, Dec 2, 2016 at 10:33 PM, Robin H. Johnson 
> >
> > Flameeyes donated his tinderbox hardware, but it's still sitting at
> > antarus's desk in Mountain View, waiting for him to ship it to OSUOSL
> > (hopefully before it's even more obsolete).
> > 
> > It's not a matter of cost even, it's just waiting for him to physically
> > take the hardware to somewhere that ships it.
> 
> It is in fact, still chillin' next to my desk at work.

Why reply and not just go ship it? Can even print labels from your chair. 
Could even schedule a FedEx/USPS/UPS pickup and they will come get it...

I imagine this will get shipped this week, hopefully!

P.S.
Could also look to move to more cloud type usage, and less physical servers. 
Less to deal with physically. Would think long term that be more ideal. Not 
sure Gentoo has the need to be on metal.

-- 
William L. Thomson Jr.


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

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[M. J. Everitt]

On 04/12/16 22:15, Alec Warner wrote:
>
> On Fri, Dec 2, 2016 at 10:33 PM, Robin H. Johnson  > wrote:
>
> On Fri, Dec 02, 2016 at 02:10:27PM +0100, Michał Górny wrote:
> > Hi, everyone.
> >
> > I've heard multiple times about various tinderbox projects being
> > started by individuals in Gentoo. In fact, so many different
> projects
> > that I've forgotten who was working on most of them.
> Flameeyes donated his tinderbox hardware, but it's still sitting at
> antarus's desk in Mountain View, waiting for him to ship it to OSUOSL
> (hopefully before it's even more obsolete).
>
> It's not a matter of cost even, it's just waiting for him to
> physically
> take the hardware to somewhere that ships it.
>
>
>
> It is in fact, still chillin' next to my desk at work.
>
> -A 
>
>
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
> E-Mail   : robb...@gentoo.org 
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
>
>
Is it worth the Foundation dropping a few $ for that hardware to *get*
transported to its rightful destination, or shall we wait a few more
years for something to happen!? :)

Just my 2c50 ... :D

MJE


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Alec Warner]

On Fri, Dec 2, 2016 at 10:33 PM, Robin H. Johnson 
wrote:

> On Fri, Dec 02, 2016 at 02:10:27PM +0100, Michał Górny wrote:
> > Hi, everyone.
> >
> > I've heard multiple times about various tinderbox projects being
> > started by individuals in Gentoo. In fact, so many different projects
> > that I've forgotten who was working on most of them.
> Flameeyes donated his tinderbox hardware, but it's still sitting at
> antarus's desk in Mountain View, waiting for him to ship it to OSUOSL
> (hopefully before it's even more obsolete).
>
> It's not a matter of cost even, it's just waiting for him to physically
> take the hardware to somewhere that ships it.
>


It is in fact, still chillin' next to my desk at work.

-A

>
>
> --
> Robin Hugh Johnson
> Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
> E-Mail   : robb...@gentoo.org
> GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
> GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
>
>

Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Convert eclass to use documentation standards.

[Mike Pagano]

On 12/03/2016 04:47 PM, Mike Pagano wrote:
> This patch modifies, removes and adds comments only. No code was harmed
> in the creation of this patch.
> This is to conform with ECLASS documentation standards.
> 
> ---
>  eclass



Committed


-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead
E-Mail : mpag...@gentoo.org
GnuPG FP   : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137
Public Key :
http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137&op=index




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass

[Ulrich Mueller]

> On Sun, 04 Dec 2016, William L Thomson wrote:

> I hope that is still possible, and I am not sure if it was even in
> 07-08. I am not tax expert, not a CPA or anything close. Likely need
> to retain and speak to one. May have to refile and start over not
> sure.

> [...]

Can you please move this discussion elsewhere, e.g. to the gentoo-nfp
or the gentoo-project list? It certainly is of non-technical nature
and therefore doesn't belong in gentoo-dev.

Ulrich


pgphA6M9tGxg3.pgp
Description: PGP signature

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Michał Górny]

On Sun, 4 Dec 2016 18:22:33 +
Markos Chandras  wrote:

> On 12/04/2016 05:47 PM, Michał Górny wrote:
> > On Sun, 4 Dec 2016 16:58:26 +
> > Markos Chandras  wrote:
> >   
> >> On 12/03/2016 05:31 PM, Michał Górny wrote:  
> >>> On Sat, 3 Dec 2016 13:13:36 +
> >>> Markos Chandras  wrote:
> >>> 
>  On 12/03/2016 10:41 AM, Michał Górny wrote:
> > On Sat, 3 Dec 2016 10:35:32 +0100
> > Patrice Clement  wrote:
> >   
> >> Friday 02 Dec 2016 14:10:27, Michał Górny wrote :  
> >>> Hi, everyone.
> >>>
> >>> I've heard multiple times about various tinderbox projects being
> >>> started by individuals in Gentoo. In fact, so many different projects
> >>> that I've forgotten who was working on most of them.
> >>>
> >>> I know that Toralf is doing tinderboxing for most of the stuff.
> >>> What other projects do we have there? What is their status?
> >>>
> >>> Is there anything we could try to integrate with pull requests to get
> >>> a better testing?
> >>>
> >>> -- 
> >>> Best regards,
> >>> Michał Górny
> >>> 
> >>
> >> Continuous integration is all the rage these days and tinderboxing is 
> >> the
> >> obvious way to go concerning Gentoo. AFAIK, Toralf is the only 
> >> contributor
> >> doing tinderboxing out of his own will. In reality, we should have a 
> >> team of
> >> devs looking after our own tinderboxes instead of relying on the 
> >> community.
> >>
> >> I'm wondering if we could start a donation campain for this project 
> >> and ask
> >> people if they've got spare machines laying around. I know a lot of 
> >> folks are
> >> reading this mailing list so maybe asking on gentoo-dev first for a 
> >> start would
> >> be appropriate.  
> >
> > Hardware is not the problem. Lack of software is.
> >   
> 
>  Have you considered using openQA[1] like openSUSE[2] and Fedora[3] do
>  instead of reinventing the wheel?
> 
>  [1] http://open.qa/
>  [2] https://openqa.opensuse.org/
>  [3] https://openqa.fedoraproject.org/
> >>>
> >>> Do you by any chance happen to know how it maps to our needs?
> >>> At a first glance it seems quite tangential.
> >>> 
> >>
> >> Depends on what you want to test. I guess openQA would be a very good
> >> solution if you want to test a snapshot of the tree against the most
> >> common scenarios for example
> >>
> >> - todays snapshot with plasma5
> >> - todays snapshot with gnome3
> >> - todays snapsnot with lxqt
> >> - ...
> >> - todays snapshot with a few tests against popular console packages
> >>   * can gcc build small C test files?
> >>   * does bash work?
> >>   * does coreutils popular tools work as expected?
> >>
> >>
> >> Having such scenarios in place is probably a more realistic testing
> >> approach than simply build everything with random USE flags just for the
> >> sake of build coverage.  
> > 
> > I'm looking for something I could tell 'build this package on this
> > commit (pull request)', optionally with some USE flags adjustment.
> > And I'd like it to be fast, i.e. don't bother rebuilding whole KDE
> > libraries every time a pull request requiring them is updated.
> >   
> 
> I think that both approaches are valuable then. We may need different
> set of software solutions though. Wouldn't, for example, Jenkins or
> buildbot do what you want on the per-package PR testing? And then you
> could use openQA to test the entire tree as a whole.

In case I didn't made it clear enough: I'm looking for something that's
adjusted for Gentoo already, and can do whatever needs to be done using
Gentoo package managers. I'm not looking to reinvent the wheel. I don't
have the time for that.

-- 
Best regards,
Michał Górny



pgpzmW72Gihth.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New version constraints: variant one

[konsolebox]

On Mon, Dec 5, 2016 at 1:41 AM, Kent Fredric  wrote:
> On Mon, 5 Dec 2016 01:21:34 +0800
> konsolebox  wrote:
>
>> Well that's just it: ease of use and simplicity vs. portability with
>> possible new parameter types in the future; your pick.  I'll
>> personally go for the former this time.
>>
>> Also, what kind of added type of parameters would you expect that
>> would be conflicting with USE flags, or other operators?  Wouldn't
>> adding another operator be enough, and not an identifying key?
>>
>> I also find that the current features are already mature enough; we're
>> just enhancing it to have better control.  I don't expect anything big
>> to be added further.
>
> Its just frustrating for me, because its not the first time I've had this
> conversation.
>
> I have some vague memory of the last time we changed dependency syntax,
> and I said then something along the lines of "hey, why not get this right so
> we don't have to have this again later"
>
> And here we are, bike shedding, debating new syntax classes without forsight.

I would love to prove this with a proof-of-concept, but I don't have
the motivation yet.  I also did it once, it wasn't helpful.

>> would be conflicting with USE flags, or other operators?  Wouldn't
>> adding another operator be enough, and not an identifying key?
>
> The difference between an "operator" and an "identifier" is one of the two
> hails from a limited set of punctuation marks, and sometimes the order is
> important.
>
> For example: 5 + 6 and  add( 5, 6 ), are functionally equivalent, however,
> the former hailed from a narrow supply of characters which people saw fit
> to use for everything, and now you have fun problems in JavaScript where
> "+" does more than one thing depending on conditions.
>
> Punctuation is powerful, but its a limited resource that serves itself
> best when used sparingly.

I agree with that, but we have to consider balancing it a bit sometimes.

-- 
konsolebox

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Markos Chandras]

On 12/04/2016 05:47 PM, Michał Górny wrote:
> On Sun, 4 Dec 2016 16:58:26 +
> Markos Chandras  wrote:
> 
>> On 12/03/2016 05:31 PM, Michał Górny wrote:
>>> On Sat, 3 Dec 2016 13:13:36 +
>>> Markos Chandras  wrote:
>>>   
 On 12/03/2016 10:41 AM, Michał Górny wrote:  
> On Sat, 3 Dec 2016 10:35:32 +0100
> Patrice Clement  wrote:
> 
>> Friday 02 Dec 2016 14:10:27, Michał Górny wrote :
>>> Hi, everyone.
>>>
>>> I've heard multiple times about various tinderbox projects being
>>> started by individuals in Gentoo. In fact, so many different projects
>>> that I've forgotten who was working on most of them.
>>>
>>> I know that Toralf is doing tinderboxing for most of the stuff.
>>> What other projects do we have there? What is their status?
>>>
>>> Is there anything we could try to integrate with pull requests to get
>>> a better testing?
>>>
>>> -- 
>>> Best regards,
>>> Michał Górny
>>>   
>>
>> Continuous integration is all the rage these days and tinderboxing is the
>> obvious way to go concerning Gentoo. AFAIK, Toralf is the only 
>> contributor
>> doing tinderboxing out of his own will. In reality, we should have a 
>> team of
>> devs looking after our own tinderboxes instead of relying on the 
>> community.
>>
>> I'm wondering if we could start a donation campain for this project and 
>> ask
>> people if they've got spare machines laying around. I know a lot of 
>> folks are
>> reading this mailing list so maybe asking on gentoo-dev first for a 
>> start would
>> be appropriate.
>
> Hardware is not the problem. Lack of software is.
> 

 Have you considered using openQA[1] like openSUSE[2] and Fedora[3] do
 instead of reinventing the wheel?

 [1] http://open.qa/
 [2] https://openqa.opensuse.org/
 [3] https://openqa.fedoraproject.org/  
>>>
>>> Do you by any chance happen to know how it maps to our needs?
>>> At a first glance it seems quite tangential.
>>>   
>>
>> Depends on what you want to test. I guess openQA would be a very good
>> solution if you want to test a snapshot of the tree against the most
>> common scenarios for example
>>
>> - todays snapshot with plasma5
>> - todays snapshot with gnome3
>> - todays snapsnot with lxqt
>> - ...
>> - todays snapshot with a few tests against popular console packages
>>   * can gcc build small C test files?
>>   * does bash work?
>>   * does coreutils popular tools work as expected?
>>
>>
>> Having such scenarios in place is probably a more realistic testing
>> approach than simply build everything with random USE flags just for the
>> sake of build coverage.
> 
> I'm looking for something I could tell 'build this package on this
> commit (pull request)', optionally with some USE flags adjustment.
> And I'd like it to be fast, i.e. don't bother rebuilding whole KDE
> libraries every time a pull request requiring them is updated.
> 

I think that both approaches are valuable then. We may need different
set of software solutions though. Wouldn't, for example, Jenkins or
buildbot do what you want on the per-package PR testing? And then you
could use openQA to test the entire tree as a whole.

-- 
Regards,
Markos Chandras

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[james]

On 12/04/2016 12:47 PM, Michał Górny wrote:

On Sun, 4 Dec 2016 16:58:26 +
Markos Chandras  wrote:


On 12/03/2016 05:31 PM, Michał Górny wrote:

On Sat, 3 Dec 2016 13:13:36 +
Markos Chandras  wrote:


On 12/03/2016 10:41 AM, Michał Górny wrote:

On Sat, 3 Dec 2016 10:35:32 +0100
Patrice Clement  wrote:


Friday 02 Dec 2016 14:10:27, Michał Górny wrote :

Hi, everyone.

I've heard multiple times about various tinderbox projects being
started by individuals in Gentoo. In fact, so many different projects
that I've forgotten who was working on most of them.

I know that Toralf is doing tinderboxing for most of the stuff.
What other projects do we have there? What is their status?

Is there anything we could try to integrate with pull requests to get
a better testing?

--
Best regards,
Michał Górny



Continuous integration is all the rage these days and tinderboxing is the
obvious way to go concerning Gentoo. AFAIK, Toralf is the only contributor
doing tinderboxing out of his own will. In reality, we should have a team of
devs looking after our own tinderboxes instead of relying on the community.

I'm wondering if we could start a donation campain for this project and ask
people if they've got spare machines laying around. I know a lot of folks are
reading this mailing list so maybe asking on gentoo-dev first for a start would
be appropriate.


Hardware is not the problem. Lack of software is.



Have you considered using openQA[1] like openSUSE[2] and Fedora[3] do
instead of reinventing the wheel?

[1] http://open.qa/
[2] https://openqa.opensuse.org/
[3] https://openqa.fedoraproject.org/


Do you by any chance happen to know how it maps to our needs?
At a first glance it seems quite tangential.



Depends on what you want to test. I guess openQA would be a very good
solution if you want to test a snapshot of the tree against the most
common scenarios for example

- todays snapshot with plasma5
- todays snapshot with gnome3
- todays snapsnot with lxqt
- ...
- todays snapshot with a few tests against popular console packages
  * can gcc build small C test files?
  * does bash work?
  * does coreutils popular tools work as expected?


Having such scenarios in place is probably a more realistic testing
approach than simply build everything with random USE flags just for the
sake of build coverage.


I'm looking for something I could tell 'build this package on this
commit (pull request)', optionally with some USE flags adjustment.
And I'd like it to be fast, i.e. don't bother rebuilding whole KDE
libraries every time a pull request requiring them is updated.


FAST?   have you read about 'tup'?
http://gittup.org/tup/

I'm not sure you are interested in a streamlined build system, just for 
CI/tinderbox, but tup is as smart/fast as it gets.


hth,
James

Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass

[james]

On 12/04/2016 02:22 AM, Robin H. Johnson wrote:

On Sat, Dec 03, 2016 at 06:30:29PM -0500, William L. Thomson Jr. wrote:


Net Total: $50,924.19


So from 09-16 avg of ~$4.6k per year over 11 years.

10 years of participation, 9 of which we got paid for. So ~$5.7k/year.
If we got paid for 2013: ~$5.4k/year over 10 years.


With that really being earned by people doing GSoC. Not the same as if
Google donated a lump sum of money to further development per say the
Councils plans. Only 1 hardware donation.

That's the payment to the organization for mentoring and managing the
students, separate from what the students doing GSoC earned.

If the student's work was of use to Gentoo, then it's ALSO $5000-$5500
per student that we've had in man-hours. I do use that disclaimer,
because I know the integration rate for Gentoo students much lower than
it should be.

2006: 10 students
2007: 8 students
2008: 5 students
2009: 6 students
2010: 16 students
2011: 14 students
2012: 8 students
2013: 6 students
2014: 3 students
2016: 5 students

Total: 81 students.
Assuming $5k/student: $405,000 in student payments, over 11 years.

I don't know how many students we've failed: I do know it's been at
least one (I failed them. Their original mentor had medical issues, I
took over, and they provided a mocked video of their work and no code by
midterm).


I believe past sponsors such as GNi incurred costs in the ~$5k range monthly.
I would assume some hosting sponsors to be averaging a few thousand at minimum
per year.

The cost to GNi was much closer to $1k/month, mostly in potential lost
revenue if the hardware COULD be used for income (it was already a sunk
cost, and didn't have other users). For our present major hosting
sponsors, I believe we're more in line with $250-$400/month, but again
mostly older hardware that isn't of much other salable use.


Just as an example. FreeBSD is seeking $1.25 Million in a fundraiser with
$882k thus far.
https://www.freebsdfoundation.org/

$1.25M is their annual fund-raising target for this year and last. Not a
specific fund-raiser, but their annual target.
For 2016 Q1-Q3, on the $1.25M, they report $293k in contributions.
For 2015, on a $1.25M target, they reported $657k in contributions.
For 2014, on a $1M target, they reported $2.4M in contributions.


They seem to average in the hundreds of thousands every year in contributions
https://www.freebsdfoundation.org/about/financials/

They're also got a good few years on us (as do Apache).


Always looked at FreeBSD when I was a Gentoo Trustee. Great foundation! Passed
the 5 year probation period with IRS, and other stuff.

The Apache Foundation was very beneficial to look at I found, because
they kept superb public records, but also were not hampered by some of
our restrictions about depending on non-open software (they & the perl
foundation BOTH use QuickBooks on Windows for their accounting).



GNUcash is superior to Quickbooks, as it is a 'double entry' accounting 
system. Last time I check Quickbooks was not 'double entry' and that is 
a big deal in accounting.  There is a module that allows entries via 
Android now with GNUcash, but is not an official part of GNUcash.org. I 
use GNUcash with my company, but not the Android smartphone module.



http://gnucash.org

http://www.techrepublic.com/article/gnucash-a-powerful-mobile-financial-tool-for-android/


Serious inquires could be directed to 'gnucash-u...@gnucash.org' as this 
accounting software is robust, under active development and even the 
devs 'chime in' on  routine basis.  All in all, gnucash is an 
outstanding piece of FOSS software; much better than Quickbooks as many 
on the discussion lists attest to on a routine basis. It is in portage 
and it runs on windows and other platforms.



hth,
James



https://www.apache.org/foundation/records/

I draw your attention to their last 990 filing:
https://www.apache.org/foundation/records/990-2014.pdf
- $1.2M in annual income
- $858k spend on infrastructure,
  of which >$400k was marked directly as IT spending.
- $1.8M in net assets

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Michał Górny]

On Sun, 4 Dec 2016 16:58:26 +
Markos Chandras  wrote:

> On 12/03/2016 05:31 PM, Michał Górny wrote:
> > On Sat, 3 Dec 2016 13:13:36 +
> > Markos Chandras  wrote:
> >   
> >> On 12/03/2016 10:41 AM, Michał Górny wrote:  
> >>> On Sat, 3 Dec 2016 10:35:32 +0100
> >>> Patrice Clement  wrote:
> >>> 
>  Friday 02 Dec 2016 14:10:27, Michał Górny wrote :
> > Hi, everyone.
> >
> > I've heard multiple times about various tinderbox projects being
> > started by individuals in Gentoo. In fact, so many different projects
> > that I've forgotten who was working on most of them.
> >
> > I know that Toralf is doing tinderboxing for most of the stuff.
> > What other projects do we have there? What is their status?
> >
> > Is there anything we could try to integrate with pull requests to get
> > a better testing?
> >
> > -- 
> > Best regards,
> > Michał Górny
> >   
> 
>  Continuous integration is all the rage these days and tinderboxing is the
>  obvious way to go concerning Gentoo. AFAIK, Toralf is the only 
>  contributor
>  doing tinderboxing out of his own will. In reality, we should have a 
>  team of
>  devs looking after our own tinderboxes instead of relying on the 
>  community.
> 
>  I'm wondering if we could start a donation campain for this project and 
>  ask
>  people if they've got spare machines laying around. I know a lot of 
>  folks are
>  reading this mailing list so maybe asking on gentoo-dev first for a 
>  start would
>  be appropriate.
> >>>
> >>> Hardware is not the problem. Lack of software is.
> >>> 
> >>
> >> Have you considered using openQA[1] like openSUSE[2] and Fedora[3] do
> >> instead of reinventing the wheel?
> >>
> >> [1] http://open.qa/
> >> [2] https://openqa.opensuse.org/
> >> [3] https://openqa.fedoraproject.org/  
> > 
> > Do you by any chance happen to know how it maps to our needs?
> > At a first glance it seems quite tangential.
> >   
> 
> Depends on what you want to test. I guess openQA would be a very good
> solution if you want to test a snapshot of the tree against the most
> common scenarios for example
> 
> - todays snapshot with plasma5
> - todays snapshot with gnome3
> - todays snapsnot with lxqt
> - ...
> - todays snapshot with a few tests against popular console packages
>   * can gcc build small C test files?
>   * does bash work?
>   * does coreutils popular tools work as expected?
> 
> 
> Having such scenarios in place is probably a more realistic testing
> approach than simply build everything with random USE flags just for the
> sake of build coverage.

I'm looking for something I could tell 'build this package on this
commit (pull request)', optionally with some USE flags adjustment.
And I'd like it to be fast, i.e. don't bother rebuilding whole KDE
libraries every time a pull request requiring them is updated.

-- 
Best regards,
Michał Górny



pgpjTqFyGAcH4.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New version constraints: variant one

[Kent Fredric]

On Mon, 5 Dec 2016 01:21:34 +0800
konsolebox  wrote:

> Well that's just it: ease of use and simplicity vs. portability with
> possible new parameter types in the future; your pick.  I'll
> personally go for the former this time.
> 
> Also, what kind of added type of parameters would you expect that
> would be conflicting with USE flags, or other operators?  Wouldn't
> adding another operator be enough, and not an identifying key?
> 
> I also find that the current features are already mature enough; we're
> just enhancing it to have better control.  I don't expect anything big
> to be added further.

Its just frustrating for me, because its not the first time I've had this
conversation.

I have some vague memory of the last time we changed dependency syntax,
and I said then something along the lines of "hey, why not get this right so
we don't have to have this again later"

And here we are, bike shedding, debating new syntax classes without forsight.

> would be conflicting with USE flags, or other operators?  Wouldn't
> adding another operator be enough, and not an identifying key?

The difference between an "operator" and an "identifier" is one of the two
hails from a limited set of punctuation marks, and sometimes the order is
important.

For example: 5 + 6 and  add( 5, 6 ), are functionally equivalent, however,
the former hailed from a narrow supply of characters which people saw fit
to use for everything, and now you have fun problems in JavaScript where
"+" does more than one thing depending on conditions.

Punctuation is powerful, but its a limited resource that serves itself
best when used sparingly.


pgpYBkbFhyT7n.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New version constraints: variant one

[konsolebox]

On Sun, Dec 4, 2016 at 11:22 PM, Kent Fredric  wrote:
> On Thu, 1 Dec 2016 14:53:51 +0800
> konsolebox  wrote:
>
>> I got similar idea here, but my version is that you don't have to use
>> u: or v:
>
> The entire point of defining it as a prefix-space was to avoid ambiguity,
> and leave plenty of room for other such selector prefixes.
>
> Relying on properties like "is it a number" or "is it text" is a shoddy
> heuristic.
>
> A heuristic that will fail us as soon as we want to add new features in
> our matcher syntax.
>
> Hence,
>
>[(,...)]
>
>CONSTRAINT: :(,...)
>
>
> Then instead of debates about how we can invent some "new" syntax
> where we have to constantly reinvent existing syntax to allow space
> for the new syntax, we can just define new identifiers, because we thought
> ahead about this problem and gave us wiggle room to add features.

Well that's just it: ease of use and simplicity vs. portability with
possible new parameter types in the future; your pick.  I'll
personally go for the former this time.

Also, what kind of added type of parameters would you expect that
would be conflicting with USE flags, or other operators?  Wouldn't
adding another operator be enough, and not an identifying key?

I also find that the current features are already mature enough; we're
just enhancing it to have better control.  I don't expect anything big
to be added further.

And come to think of it, a parameter with a key can be distinguished
differently from a USE flag, because a USE flag wouldn't have a colon,
so a parameter with an identifier that defines its class can still be
added if with would need it in the future.

-- 
konsolebox

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Markos Chandras]

On 12/03/2016 05:31 PM, Michał Górny wrote:
> On Sat, 3 Dec 2016 13:13:36 +
> Markos Chandras  wrote:
> 
>> On 12/03/2016 10:41 AM, Michał Górny wrote:
>>> On Sat, 3 Dec 2016 10:35:32 +0100
>>> Patrice Clement  wrote:
>>>   
 Friday 02 Dec 2016 14:10:27, Michał Górny wrote :  
> Hi, everyone.
>
> I've heard multiple times about various tinderbox projects being
> started by individuals in Gentoo. In fact, so many different projects
> that I've forgotten who was working on most of them.
>
> I know that Toralf is doing tinderboxing for most of the stuff.
> What other projects do we have there? What is their status?
>
> Is there anything we could try to integrate with pull requests to get
> a better testing?
>
> -- 
> Best regards,
> Michał Górny
> 

 Continuous integration is all the rage these days and tinderboxing is the
 obvious way to go concerning Gentoo. AFAIK, Toralf is the only contributor
 doing tinderboxing out of his own will. In reality, we should have a team 
 of
 devs looking after our own tinderboxes instead of relying on the community.

 I'm wondering if we could start a donation campain for this project and ask
 people if they've got spare machines laying around. I know a lot of folks 
 are
 reading this mailing list so maybe asking on gentoo-dev first for a start 
 would
 be appropriate.  
>>>
>>> Hardware is not the problem. Lack of software is.
>>>   
>>
>> Have you considered using openQA[1] like openSUSE[2] and Fedora[3] do
>> instead of reinventing the wheel?
>>
>> [1] http://open.qa/
>> [2] https://openqa.opensuse.org/
>> [3] https://openqa.fedoraproject.org/
> 
> Do you by any chance happen to know how it maps to our needs?
> At a first glance it seems quite tangential.
> 

Depends on what you want to test. I guess openQA would be a very good
solution if you want to test a snapshot of the tree against the most
common scenarios for example

- todays snapshot with plasma5
- todays snapshot with gnome3
- todays snapsnot with lxqt
- ...
- todays snapshot with a few tests against popular console packages
  * can gcc build small C test files?
  * does bash work?
  * does coreutils popular tools work as expected?


Having such scenarios in place is probably a more realistic testing
approach than simply build everything with random USE flags just for the
sake of build coverage.

-- 
Regards,
Markos Chandras

Re: [gentoo-dev] [RFC] New version constraints: variant one

[Kent Fredric]

On Thu, 1 Dec 2016 14:53:51 +0800
konsolebox  wrote:

> I got similar idea here, but my version is that you don't have to use
> u: or v:

The entire point of defining it as a prefix-space was to avoid ambiguity,
and leave plenty of room for other such selector prefixes.

Relying on properties like "is it a number" or "is it text" is a shoddy
heuristic.

A heuristic that will fail us as soon as we want to add new features in
our matcher syntax.

Hence, 

   [(,...)]

   CONSTRAINT: :(,...)


Then instead of debates about how we can invent some "new" syntax
where we have to constantly reinvent existing syntax to allow space
for the new syntax, we can just define new identifiers, because we thought
ahead about this problem and gave us wiggle room to add features.



pgpPjQN0_eTZ1.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[M. J. Everitt]

On 04/12/16 14:03, Jorge Manuel B. S. Vicetto wrote:
>
> I recall some discussion about tinderboxing suggesting that more
> important than testing all possible use flag combinations, would be to
> test:
>
>  * all use flags disabled (some packages fail miserabily if you don't
> enable at least one use flag)
>  * all use flags enabled (good to detect conflicts)
>  * default use flags (rely on IUSE defaults - even better if you test
> it on different profiles to see the impact)
>  * a set of use flags defined by maintainer (mysql ebuilds have a set
> of USE flags for maintainers to test them)
>
> Regards,
> Jorge Manuel B. S. Vicetto
> Gentoo Developer
>
Which is broadly what the -stable WG have settled on, and kensington is
working with for his updates/work on tatt and associated scripts afaik.
You may be interested in the #g-wg-stable channel has a bit more about
formalising some of the processes that have been going on 'in the
background' so-to-speak!



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass

[William L. Thomson Jr.]

On Saturday, December 3, 2016 11:42:14 PM EST Daniel Campbell wrote:
>
> I just wanted to point this e-mail out and thank you for the effort
> spent to share information like this. This is a great step, and once we
> get the books in order, sharing this information using automated means
> could get us part of the way to 501(c)3 status.

I hope that is still possible, and I am not sure if it was even in 07-08. I am 
not tax expert, not a CPA or anything close. Likely need to retain and speak 
to one. May have to refile and start over not sure.

There is basically a 5 year "probation qualification" period that starts with 
the first year of the NPO applying for 501c status.
https://www.irs.gov/publications/p557/ch03.html#en_US_201602_publink1000246837

Info on the tests and qualification requirements
https://www.irs.gov/publications/p557/ch03.html#en_US_201602_publink1000200142

I have no clue what happens if you do not meet the requirements in the 5 
years. Not sure if you can re-apply or what. Thus need to hire and speak to 
someone, if not have them help to get things in order.

There are presently larger issues. I will let others speak on that, as I am 
not sure how much has been released on such. Though hiring a CPA or other may 
be able to help with that, and can determine the direction of the rest.

-- 
William L. Thomson Jr.


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

Re: [gentoo-dev] OT Who runs Gentoo was -> RFC: Userkit.eclass

[William L. Thomson Jr.]

On Sunday, December 4, 2016 7:22:51 AM EST Robin H. Johnson wrote:
> On Sat, Dec 03, 2016 at 06:30:29PM -0500, William L. Thomson Jr. wrote:
> > > 
> > > Net Total: $50,924.19
> > > 
> > 
> > So from 09-16 avg of ~$4.6k per year over 11 years.
> 
> 10 years of participation, 9 of which we got paid for. So ~$5.7k/year.
> If we got paid for 2013: ~$5.4k/year over 10 years.

I still think it is relatively low.

> > With that really being earned by people doing GSoC. Not the same as if
> > Google donated a lump sum of money to further development per say the
> > Councils plans. Only 1 hardware donation.
> 
> That's the payment to the organization for mentoring and managing the
> students, separate from what the students doing GSoC earned.
> 
> If the student's work was of use to Gentoo, then it's ALSO $5000-$5500
> per student that we've had in man-hours. I do use that disclaimer,
> because I know the integration rate for Gentoo students much lower than
> it should be.

My only point was without someone doing work. Google does not give Gentoo the 
money. It is not like a normal person or business donating to or sponsoring 
Gentoo. That is their specialized program. I have to think they have their own 
interest in it as well.

I would almost say the donation from both the person in time and google is 
from the person not Google. Also including the mentor or what ever that is 
called. Those 2 people put in their time, to make sure that money is paid to 
the student and organization.

> The cost to GNi was much closer to $1k/month, mostly in potential lost
> revenue if the hardware COULD be used for income (it was already a sunk
> cost, and didn't have other users). For our present major hosting
> sponsors, I believe we're more in line with $250-$400/month, but again
> mostly older hardware that isn't of much other salable use.

That would ruffly put GNi ~$12k a year. How many hosting sponsors?
Even on the low side $250 x 12 = $3k, $400 is $4800. I doubt any have the 
revenue of Google. Or shipping products like ChromeOS or OnHub router using 
Gentoo build system.

I just do not see GSoC in the same light as others and over all from Google is 
pretty minimal IMHO. Relative to their benefit, revenue derived from such, and 
over all revenue of the company.

They could provide cloud resources and other that would likely not cost them 
much in overhead.

> > Just as an example. FreeBSD is seeking $1.25 Million in a fundraiser with
> > $882k thus far.
> > https://www.freebsdfoundation.org/
> 
> $1.25M is their annual fund-raising target for this year and last. Not a
> specific fund-raiser, but their annual target.
> For 2016 Q1-Q3, on the $1.25M, they report $293k in contributions.
> For 2015, on a $1.25M target, they reported $657k in contributions.
> For 2014, on a $1M target, they reported $2.4M in contributions.

Still far beyond Gentoo.

> > They seem to average in the hundreds of thousands every year in
> > contributions https://www.freebsdfoundation.org/about/financials/
> 
> They're also got a good few years on us (as do Apache).

Yes for sure, but Gentoo has set itself back needlessly. Things that should 
have been done haven't. Much less other things that could have happened. 
Funding for events per se, Gentoo Conference

> > Always looked at FreeBSD when I was a Gentoo Trustee. Great foundation!
> > Passed the 5 year probation period with IRS, and other stuff.
> 
> The Apache Foundation was very beneficial to look at I found, because
> they kept superb public records, but also were not hampered by some of
> our restrictions about depending on non-open software (they & the perl
> foundation BOTH use QuickBooks on Windows for their accounting).
> 
> https://www.apache.org/foundation/records/
> 
> I draw your attention to their last 990 filing:
> https://www.apache.org/foundation/records/990-2014.pdf
> - $1.2M in annual income
> - $858k spend on infrastructure,
>   of which >$400k was marked directly as IT spending.
> - $1.8M in net assets

See they are spending the money. That is something I proposed long ago. To pay 
some hosting sponsors, rather than rely on free hosting sponsors. Which at the 
time were given ad space on g.o. That has since changed, but still goes back 
to if you do not have a plan to spend and use the money to further. Not likely 
to get it.

Sure not all reach their fund raising goals, but at least making such efforts. 
No clue what would happen if Gentoo set out to raise funds. But without plans 
to use, not sure what Gentoo would do with any raised money or donations.

-- 
William L. Thomson Jr.


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

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Jorge Manuel B. S. Vicetto]

On Sat, 3 Dec 2016, Michał Górny wrote:


On Sat, 3 Dec 2016 13:13:36 +
Markos Chandras  wrote:


On 12/03/2016 10:41 AM, Michał Górny wrote:

On Sat, 3 Dec 2016 10:35:32 +0100
Patrice Clement  wrote:


Friday 02 Dec 2016 14:10:27, Michał Górny wrote :

Hi, everyone.

I've heard multiple times about various tinderbox projects being
started by individuals in Gentoo. In fact, so many different projects
that I've forgotten who was working on most of them.

I know that Toralf is doing tinderboxing for most of the stuff.
What other projects do we have there? What is their status?

Is there anything we could try to integrate with pull requests to get
a better testing?

--
Best regards,
Michał Górny



Continuous integration is all the rage these days and tinderboxing is the
obvious way to go concerning Gentoo. AFAIK, Toralf is the only contributor
doing tinderboxing out of his own will. In reality, we should have a team of
devs looking after our own tinderboxes instead of relying on the community.

I'm wondering if we could start a donation campain for this project and ask
people if they've got spare machines laying around. I know a lot of folks are
reading this mailing list so maybe asking on gentoo-dev first for a start would
be appropriate.


Hardware is not the problem. Lack of software is.



Have you considered using openQA[1] like openSUSE[2] and Fedora[3] do
instead of reinventing the wheel?

[1] http://open.qa/
[2] https://openqa.opensuse.org/
[3] https://openqa.fedoraproject.org/


Do you by any chance happen to know how it maps to our needs?
At a first glance it seems quite tangential.


Last time I looked at it, a few years ago at FOSDEM, one issue to me, at 
least for testing release builds, was that it relied on fingerprint of 
images and time delays. To me it would make more sense to get a "console" 
and grep the output for relevant strings.

I don't know if / how it evolved, so this might no longer be true.

Regards,
Jorge Manuel B. S. Vicetto
Gentoo Developer

Re: [gentoo-dev] Tinderboxing efforts in Gentoo

[Jorge Manuel B. S. Vicetto]

On Sat, 3 Dec 2016, Rich Freeman wrote:


On Sat, Dec 3, 2016 at 9:47 AM, William L. Thomson Jr.
 wrote:

On Saturday, December 3, 2016 9:33:00 AM EST Michael Orlitzky wrote:

On 12/03/2016 09:25 AM, William L. Thomson Jr. wrote:

This is generally considered infeasible:

I would not think such, just need a wrapper to run around each package
that
would get its USE flags and re-emerge it a few times.


If a package has 10 USE flags, and if each can be set on/off with no
constraints, then that gives you 2^10 different ways to emerge it.


May make the requirements of the host system larger or take more time.  I am
sure processing power could handle that load.

Would be nice if someone like Google would sponsor such efforts. They have
enough hardware and cloud services to make such feasible.



Have you given thought to how long it would take the largest
supercomputer in the world to rebuild libreoffice once for each of the
2^28 USE flag combinations it has (not including USE_EXPAND)?

It is certainly possible, but I doubt that you're going to get it
dedicated to Gentoo for a few weeks whenever one of its deps changes.

This is not a reason to give up on tinderboxing.  This is just a
reason to be realistic about just what it will do.


I recall some discussion about tinderboxing suggesting that more important 
than testing all possible use flag combinations, would be to test:


 * all use flags disabled (some packages fail miserabily if you don't 
enable at least one use flag)

 * all use flags enabled (good to detect conflicts)
 * default use flags (rely on IUSE defaults - even better if you test it 
on different profiles to see the impact)
 * a set of use flags defined by maintainer (mysql ebuilds have a set of 
USE flags for maintainers to test them)


Regards,
Jorge Manuel B. S. Vicetto
Gentoo Developer

Re: [gentoo-dev] Review request: Ruby 2.0 removal news item

[Matthias Hanft]

Hans de Graaff wrote:
> 
> Ruby MRI 2.0 has been retired by upstream in February 2016.[1]
> We remove Ruby MRI 2.0 support from the tree now. Ruby MRI 2.1 remains
> activated in base profile's RUBY_TARGETS variable by default.

Hmmm... what about dependencies?

home01 ~ # eshowkw ruby
Keywords for dev-lang/ruby:
  | | u |
  | a a   a n   p r s   | n |
  | l m   r h i m m i   p i s   p   | u s   | r
  | p d a m p a 6 i o p c s 3   a x | s l   | e
  | h 6 r 6 p 6 8 p s p 6 c 9 s r 8 | e o   | p
  | a 4 m 4 a 4 k s 2 c 4 v 0 h c 6 | d t   | o
--+-+---+---
[I]2.0.0_p648 | + + + o + + o ~ o + + o ~ ~ + + | o 2.0 | gentoo
--+-+---+---
 [I]2.1.9 | + + + o + + o ~ o + + o ~ ~ + + | o 2.1 | gentoo

home01 ~ # eselect ruby list
Available Ruby profiles:
  [1]   ruby20 (with Rubygems)
  [2]   ruby21 (with Rubygems) *

home01 ~ # emerge -pvc =ruby-2.0.0_p648
Calculating dependencies... done!
  dev-lang/ruby-2.0.0_p648 pulled in by:
dev-ruby/json-1.8.2-r1 requires dev-lang/ruby:2.0
dev-ruby/racc-1.4.11 requires dev-lang/ruby:2.0
dev-ruby/rake-10.5.0 requires dev-lang/ruby:2.0
dev-ruby/rdoc-4.2.0 requires dev-lang/ruby:2.0
dev-ruby/rubygems-2.5.2 requires dev-lang/ruby:2.0
virtual/rubygems-10 requires dev-lang/ruby:2.0
>>> No packages selected for removal by depclean

Are they obsolete, too? Should I just "emerge -C =ruby-2.0.0_p648"?
Or is there some kind of "ruby-cleaner" (like "perl-cleaner") to
switch all that to ruby 2.1? How to proceed in order to get a
consistent 2.1 installation? As a normal user, I'd get stuck at
this point without further instructions...

-Matt

Re: [gentoo-dev] Review request: Ruby 2.0 removal news item

[Daniel Campbell]

On 12/03/2016 11:51 PM, Hans de Graaff wrote:
> Title: Ruby 2.0 removal; Ruby 2.1 default
> Author: Hans de Graaff 
> Content-Type: text/plain
> Posted: 2016-12-04
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed:  
> Ruby MRI 2.0 has been retired by upstream in February 2016.[1]
> We remove Ruby MRI 2.0 support from the tree now. Ruby MRI 2.1 remains
> activated in base profile's RUBY_TARGETS variable by default.
> 
> If your currently eselected Ruby interpreter is ruby20, our
> recommendation is to change it to ruby21. At the moment Ruby MRI 2.1
> delivers the best possible support of all Ruby interpreters in tree.
> 
> Check the current setting via:
> 
>   eselect ruby show
> 
> Change the current setting to Ruby MRI 2.1 via:
> 
>   eselect ruby set ruby21
> 
> [1] https://www.ruby-lang.org/en/news/2016/02/24/support-plan-of-ruby-2
> -0-0-and-2-1/
> 

1. Do users need to know about MRI? I had to search the Web to figure
out that it's referring to Matz's Ruby Interpreter (or CRuby), which is
the reference implementation. This information (if important) may be
useful to include, like "Ruby MRI (Matz's Ruby Interpreter) 2.1 ...".

2. Grammar and tone seems a little off. Here's my attempt at a rewrite,
if you don't mind:

~~~

Ruby MRI (Matz's Ruby Interpreter) 2.0 was retired by upstream in
February 2016. [1] Following this, Ruby MRI 2.0 support will be removed
from Gentoo in favor of Ruby MRI 2.1. We recommend updating to the
'ruby21' target as soon as possible.

[insert eselect guide here]

~~~

I wrote my edit trying to stay close to the original writing style. I
hope it's satisfactory.

The eselect part reads well. We could remove the "MRI" part, but as a
non-Rubyist I don't feel qualified to determine whether it's important
or not.

I felt that the base profile variable mention and the bit about MRI
being the best interpreter were better left out, but it also doesn't
actively hurt it.

Someone more experienced in news-writing should clarify that. Overall I
thought it was a good initial draft.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature