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

[Michael Orlitzky]

On 12/07/2016 03:59 PM, Andreas K. Huettel wrote:
> 
> Hi Doug, 
> 
> I like it, actually more than my version- with one exception... if we do a 
> step with EAPI, we should be able to get this done without the -r1 mess. 
> 
> I'll try to whip up something reasonably elegant based on your patch...
> 

While you're poking around, please change the location of APXS, because
it was moved in apache a while ago:

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

That and the other path variables might benefit from $EPREFIX as well.

Re: Thread moving to -nfp LIST [Re: [gentoo-dev] Gentooo 501(c) accounting]

[Robin H. Johnson]

On Wed, Dec 07, 2016 at 04:01:53PM -0500, james wrote:
> Can you cross post to gentoo-dev? I'm not subscribed to that list.
> Should not a wider community, particularly devs be part of the discussion?
Please DO subscribe.

The long response I just sent is significantly off-topic for the -dev
list. It may be almost on-topic for the -project list, but certainly not
-dev.

The council agenda this month includes getting more off-topic stuff out
of -project, so keeping the lists to their intended function should be
done.

> At least a quick link for folk, who are interested can read what is
> discussed via the list? I'm sure I'm not the only one interested in
> our goals and management infrastructures.
https://archives.gentoo.org/gentoo-nfp/message/ca4fd8c98b9649bb060d48b466927c82

For a slightly older piece, also see the talk I gave about the
Foundation, at this year's Gentoo miniconference:
https://www.youtube.com/playlist?list=PLICDJo0onMRJFwAD3V7KGZWgnkxQaELeh

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


signature.asc
Description: Digital signature

Re: Thread moving to -nfp LIST [Re: [gentoo-dev] Gentooo 501(c) accounting]

[james]

On 12/07/2016 03:02 PM, Robin H. Johnson wrote:

I'm going to respond to this thread on the NFP list.



Hey Robin,


Can you cross post to gentoo-dev? I'm not subscribed to that list.
Should not a wider community, particularly devs be part of the discussion?

At least a quick link for folk, who are interested can read what is
discussed via the list? I'm sure I'm not the only one interested in
our goals and management infrastructures.


James

Re: [gentoo-dev] Request for help: distributed pull request CI (pkgcheck)

[nado]

December 7, 2016 7:57 PM, "Michał Górny"  wrote:

> Can you think of any tools that could help me get the task done easily
> and with as little of reinventing the wheel as possible? Right now, I
> have just a lot of trivial shell script that checks pull request for
> changes, checks them out, runs 'pmaint regen', pkgcheck, publishes all
> kinds of results and statuses, and also compares QA results to
> determine new failures created by the PR [1].

If this is already shell based, why not going for something like an ansible 
automated task or alike ? This way, helper would almost only need to give an 
ssh key to setup everything. Of course for managing the load it would need some 
more tinkering, and I’m not sure it would be totally flexible and expandable.

--
Corentin “Nado” Pazdera

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

[Andreas K. Huettel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mittwoch, 7. Dezember 2016, 04:10:26 schrieb Doug Freed:
> This also fixes various other code smells.  I wrote this back in the start
> of October, and never got around to sending it to the list for review.  A
> note: given how extensively this patch changes the eclass, it is suggested
> that it actually become depend.apache-r1 and only support EAPI=6, and the
> EAPI=6 ebuilds that presently inherit depend.apache can inherit this
> instead. ---
>  eclass/depend.apache.eclass | 156
> ++-- 1 file changed, 93
> insertions(+), 63 deletions(-)


Hi Doug, 

I like it, actually more than my version- with one exception... if we do a 
step with EAPI, we should be able to get this done without the -r1 mess. 

I'll try to whip up something reasonably elegant based on your patch...

Cheers, Andreas

- -- 

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

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQKTBAEBCgB9FiEEwo/LD3vtE3qssC2JpEzzc+fumeQFAlhIeDJfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMy
OEZDQjBGN0JFRDEzN0FBQ0IwMkQ4OUE0NENGMzczRTdFRTk5RTQACgkQpEzzc+fu
meRCdw//cK3kgJ7sW93RF2jjiOX62H5pdlwwnL/dF5l+s8QZzdvyG/E91g6Oc+OA
cLX7xX+EWi3fAkezWtpbQaFxDPpjbaLOWGwtv1+Y4OLra26AbSD5zbfWHyEgT5oC
yfBgPlFfc7BB81T6j7/dhiI8whzjBCieHDNs4Qbyviid6lm/PlGUwxf4sVp/IztM
+iiAJPjBxpuVmv/CHMU6JPHVGbBmriVTQg/xK2maBMFaaJ2JDZREjXQi4KOQpPwH
3jMJ4ve+wf7dOHhXKH8YpkTyOBOkiJZ2epJDCb2Y+0K87Gr5mAWS/0scgURSS+C/
lAyN+7ryGcb98F0VyOGzLNsZKWQWpioWT07fhLh0sUTSHDb286ZuyBMh2omcnxzS
nfkX4tTE8dScf04HyGnBEgO+/6BloDqBfPMRTZnMr61mlk3GPj2kVJX2lbRAM6Q6
mKFCsUxGV3WQE+XHRmyv8Wlx2iQezI2zV0/coHfZty3ECbBqddTElifsYiMdTOLz
3i/mfNuMSfHX+n79XMBZ6wf3kE0CJh1MJxO5m8PHoqQJAdV0j86ruCDjVBErYvlf
JMtxeYyykHqObg7zS2P7Ki/Ok6yvEJkXeDK/xuxexShHCGStEbE29Ocfs1epkPlW
4tD73WcRgOEgGMjj1ja6700KoKa1gPy3XkpsuYc8vA/13o2ShHw=
=pxVu
-END PGP SIGNATURE-

Re: [gentoo-dev] Gentooo 501(c) accounting

[james]

On 12/07/2016 01:53 PM, Jigme Datse Rasku wrote:

I have been using LedgerSMB as when I was looking everything except
SQL-Ledger (which got forked to LedgerSMB) was either too expensive
(commercial, and a lot didn't run on Linux) or more pain than writing in
a ledger book (easier to screw up, and harder to remember what I was
doing anyway).

As I haven't looked at options for ages, due to feeling LedgerSMB
continues to be a good fit (I switched to them soon after the fork), and
mostly fails for me in terms of multiple features I don't really need,
or so far haven't even found a use case that works for me, but many over
time which I thought I wouldn't use, I do now.  don't need to, but it works.

I expressed recently that *if* they created a "only new code" version
which only had basic accounting features, I could, and would work with
it, if that worked mostly like that is currently working.

For me, as the interface (web based) is a huge plus over anything I
looked at in the past.

On Dec 7, 2016 10:32, "james" > wrote:



Hey Jigme,

I think gentoo is under a social contract limits our use options to
FOSS accounting packages. Perhaps someone more knowledgable with itemize 
the restrictions gentoo is under for it's 501(c)3 needs.



Here's a shocker from an IRS doc::

"The organization must not be organized or operated for the benefit of 
private interests" [1] That basically is a very general statement, open 
to vast interpretation; whether it's a problem for gentoo, remains to be 
seen.


I think someone more knowledgeable than myself should post the 
restrictions and guidance document reference, if any, that constrain and 
guide gentoo in matter of GAAP, 501(c)3 and it foundational 
organization, before an accounting packages is agreed up. Perhaps this 
just a good idea to vet


 how these critical charity records are maintained and disseminated. 
Some states may have additional statues and rules.   The corporation 
papers were filed in Maryland, right? If not, what state where the 
papers filed in?



[1] 
https://www.irs.gov/charities-non-profits/charitable-organizations/exemption-requirements-section-501-c-3-organizations




hth,
James

Re: [gentoo-dev] Request for help: distributed pull request CI (pkgcheck)

[Mathy Vanvoorden]

Hi,

I have some experience with CI and am willing to help out, I'll talk to you
on IRC.

Mathy

On Dec 7, 2016 19:57, "Michał Górny"  wrote:

> Hello, everyone.
>
> TL;DR: I'm looking for some help to get pull-request CI running
> distributed, i.e. on multiple hosts.
>
>
> Quick history
> -
>
> The repo-mirror-ci project pretty much started as a simple cronjob
> running on hardware contributed to the purpose by Todd Goodman
> (considering how much this hardware has done for Gentoo, I'd suggest
> giving him a honorary citizenship of Gentoo or something like
> that ;-)). I can't say they were terrible but they weren't perfect
> either. Due to lack of time, I mostly focused on improving them
> moderately and adding new features.
>
> Today, everything is still running on the same hardware. While
> the hardware is real good, and I'm doing some effort to improve
> the performance of the tools, I think it's quite close to its limits.
>
> Right now, it is running three tasks every 20 minutes: updating repo
> mirrors, running pkgcheck on Gentoo and processing one pull request.
> However, if those tasks delay beyond those 20 minutes, the poor man's
> scheduling based on cron + lockfiles may cause some of the executions
> to be skipped.
>
> In other words, the best case is processing 3 pull requests / h. This
> is starting to be no longer sufficient, and causing significant delays
> during periods of high contributor activity -- while my goal would be to
> provide the results ASAP -- 10-20 minutes would be perfect.
>
>
> The goal and needs
> --
>
> I think the best way forward would be to start distributing tasks
> between more systems. While I don't really have time to make whole
> repo-mirror-ci distributed, I think it should be feasible to start
> splitting pull request processing out of it.
>
> I would use some help to achieve that, esp. wrt distributed task
> scheduling.
>
> Can you think of any tools that could help me get the task done easily
> and with as little of reinventing the wheel as possible? Right now, I
> have just a lot of trivial shell script that checks pull request for
> changes, checks them out, runs 'pmaint regen', pkgcheck, publishes all
> kinds of results and statuses, and also compares QA results to
> determine new failures created by the PR [1].
>
> As I see it, checking for changes and submitting the results should
> stay on the current host. However, it should be able to run all
> the actual work on slaves and retrieve the results from them. I would
> appreciate all the help with implementing that, plus possibly some
> degree of control to make it possible to update pkgcheck on slaves
> easily.
>
> Please let me know if you're interested in helping. Thanks.
>
> [1]:https://bitbucket.org/mgorny/repo-mirror-ci/src/
> master/pull-requests.job
>
> --
> Best regards,
> Michał Górny
>

Thread moving to -nfp LIST [Re: [gentoo-dev] Gentooo 501(c) accounting]

[Robin H. Johnson]

I'm going to respond to this thread on the NFP list.

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


signature.asc
Description: Digital signature

Re: [gentoo-dev] Cross Post due to technical component - Thanks for all the fish

[james]

On 12/07/2016 04:22 AM, Kristian Fiskerstrand wrote:

On 12/07/2016 06:07 AM, Robin H. Johnson wrote:


So I just now sent email to :
proxy-maint+subscr...@gentoo.org


You likely want to check out [gentoo-proxy-ma...@lists.gentoo.org]
instead of the project alias. The latter is restricted to Gentoo developers.

References:
[gentoo-proxy-ma...@lists.gentoo.org]
https://archives.gentoo.org/gentoo-proxy-maint/



Thanks Robin. All good to know. Maybe these details and the other
aforementioned details can be clarified and documented in the wiki,
for the benefit of all to know.

hth,
James

[gentoo-dev] Request for help: distributed pull request CI (pkgcheck)

[Michał Górny]

Hello, everyone.

TL;DR: I'm looking for some help to get pull-request CI running
distributed, i.e. on multiple hosts.


Quick history
-

The repo-mirror-ci project pretty much started as a simple cronjob
running on hardware contributed to the purpose by Todd Goodman
(considering how much this hardware has done for Gentoo, I'd suggest
giving him a honorary citizenship of Gentoo or something like
that ;-)). I can't say they were terrible but they weren't perfect
either. Due to lack of time, I mostly focused on improving them
moderately and adding new features.

Today, everything is still running on the same hardware. While
the hardware is real good, and I'm doing some effort to improve
the performance of the tools, I think it's quite close to its limits.

Right now, it is running three tasks every 20 minutes: updating repo
mirrors, running pkgcheck on Gentoo and processing one pull request.
However, if those tasks delay beyond those 20 minutes, the poor man's
scheduling based on cron + lockfiles may cause some of the executions
to be skipped.

In other words, the best case is processing 3 pull requests / h. This
is starting to be no longer sufficient, and causing significant delays
during periods of high contributor activity -- while my goal would be to
provide the results ASAP -- 10-20 minutes would be perfect.


The goal and needs
--

I think the best way forward would be to start distributing tasks
between more systems. While I don't really have time to make whole
repo-mirror-ci distributed, I think it should be feasible to start
splitting pull request processing out of it.

I would use some help to achieve that, esp. wrt distributed task
scheduling.

Can you think of any tools that could help me get the task done easily
and with as little of reinventing the wheel as possible? Right now, I
have just a lot of trivial shell script that checks pull request for
changes, checks them out, runs 'pmaint regen', pkgcheck, publishes all
kinds of results and statuses, and also compares QA results to
determine new failures created by the PR [1].

As I see it, checking for changes and submitting the results should
stay on the current host. However, it should be able to run all
the actual work on slaves and retrieve the results from them. I would
appreciate all the help with implementing that, plus possibly some
degree of control to make it possible to update pkgcheck on slaves
easily.

Please let me know if you're interested in helping. Thanks.

[1]:https://bitbucket.org/mgorny/repo-mirror-ci/src/master/pull-requests.job

-- 
Best regards,
Michał Górny


pgpU8Dli2RywM.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentooo 501(c) accounting

[Jigme Datse Rasku]

I have been using LedgerSMB as when I was looking everything except
SQL-Ledger (which got forked to LedgerSMB) was either too expensive
(commercial, and a lot didn't run on Linux) or more pain than writing in a
ledger book (easier to screw up, and harder to remember what I was doing
anyway).

As I haven't looked at options for ages, due to feeling LedgerSMB continues
to be a good fit (I switched to them soon after the fork), and mostly fails
for me in terms of multiple features I don't really need, or so far haven't
even found a use case that works for me, but many over time which I thought
I wouldn't use, I do now.  don't need to, but it works.

I expressed recently that *if* they created a "only new code" version which
only had basic accounting features, I could, and would work with it, if
that worked mostly like that is currently working.

For me, as the interface (web based) is a huge plus over anything I looked
at in the past.

On Dec 7, 2016 10:32, "james"  wrote:

> Hello,
>
>
> There was some discussion before about the software used for gentoo the
> charity (501)(c). It seems to have perked up a bit of discussion on
> gnucash, where all of the posting I have read suggest that gnucash is a
> wonderful accounting system for  charity organizations. There also appears
> to be lots of experience and help to. I thought this issue need a separate
> thread on gentoo-dev, a robust decision, and a team based solution, if  not
> a council item.
>
> Here is the latest posting I have received on the 501(c) subject matter,
> I thought I share and formally open up a discussion on the subject:
>
>
>
> Here's my original post::
>
> 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
> 
>
> The the most recent reply:
>
> >
> > [1] http://www.ledger-cli.org/
>
> I regard cli accounting as a friend of GnuCash rather than the
> competition, there isn't anything one can do that the other can't in
> accounting terms, also notice that cli accounting is becoming less so as
> time passes, there are UIs and SQL type reports and so on being added
> all the time, the principle is that compared to commercial products you
> can, if you really want to, see a stream of transactions in ordinary ABC
> and 123 terms, gnc can be dumped to cli and vice versa.
>
> I'm not saying you or someone else should choose one or the other, I'm
> asking you to thunk which is most likely to get people keeping good
> records for the benefit of their non-profit.  I know that for one
> non-profit I help out with a basic cli would be a non-starter, no UI and
> the tx simply wouldn't get entered.
>
> > [2] http://www.accountingcoach.com/nonprofit-accounting/explanation/1
>
> worth reading, note the bits about restricted funds, that is what people
> that are familiar with for-profit orgs usually struggle with conceptually
>
> > [3] https://sfconservancy.org/npoacct/
>
> that's been updated since I read it last but seems to be more face lift
> than new content
>
> James, you've got some good links there but don't actually say what the
> imperatives for your correspondent are.
>
> I, and I am sure others, are happy to espouse GnuCash, *if we think it
> is right* for your org.  I don't have enough to go on.  There is little
> harm in trying it, however, as it is easy enough to get your tx in and
> out if cli accounting is your alternative.
>
> Happy helping and non-profiteering (if that is even a concept in merka
> post Trump)
> --
> Wm
>
> 
> .
>
>
> Surely our code of conduct, evidence by principled and publish documents
> and the records of expenditures over the years, are quintessential
> documents and should experience governance in the sunshine, or no?
>
> hth,
> James
>
>

[gentoo-dev] Re: Gentooo 501(c) accounting

[james]

On 12/07/2016 01:31 PM, james wrote:

Hello,


There was some discussion before about the software used for gentoo the
charity (501)(c). It seems to have perked up a bit of discussion on
gnucash, where all of the posting I have read suggest that gnucash is a
wonderful accounting system for  charity organizations. There also
appears to be lots of experience and help to. I thought this issue need
a separate thread on gentoo-dev, a robust decision, and a team based
solution, if  not a council item.

Here is the latest posting I have received on the 501(c) subject matter,
I thought I share and formally open up a discussion on the subject:



Here's my original post::

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


The the most recent reply:



[1] http://www.ledger-cli.org/


I regard cli accounting as a friend of GnuCash rather than the
competition, there isn't anything one can do that the other can't in
accounting terms, also notice that cli accounting is becoming less so as
time passes, there are UIs and SQL type reports and so on being added
all the time, the principle is that compared to commercial products you
can, if you really want to, see a stream of transactions in ordinary ABC
and 123 terms, gnc can be dumped to cli and vice versa.

I'm not saying you or someone else should choose one or the other, I'm
asking you to thunk which is most likely to get people keeping good
records for the benefit of their non-profit.  I know that for one
non-profit I help out with a basic cli would be a non-starter, no UI and
the tx simply wouldn't get entered.


[2] http://www.accountingcoach.com/nonprofit-accounting/explanation/1


worth reading, note the bits about restricted funds, that is what people
that are familiar with for-profit orgs usually struggle with conceptually


[3] https://sfconservancy.org/npoacct/


that's been updated since I read it last but seems to be more face lift
than new content

James, you've got some good links there but don't actually say what the
imperatives for your correspondent are.

I, and I am sure others, are happy to espouse GnuCash, *if we think it
is right* for your org.  I don't have enough to go on.  There is little
harm in trying it, however, as it is easy enough to get your tx in and
out if cli accounting is your alternative.

Happy helping and non-profiteering (if that is even a concept in merka
post Trump)



Why thank you James for helping us focus on charity and organizational 
commitment. Here is an IRS online document, that is just exciting to 
read, when one puts on the filter of gentoo_behavior and reads the 
requirements to be a 501(c)3  [1]




[1] 
https://www.irs.gov/publications/p557/ch03.html#en_US_201602_publink1000200036



So which category is Gentoo under?


Where are the public records?


Can we get complete historical ledger of the organization published?


Are we (gentoo, council and foundation) in compliance?

Audit Records?


Let's get cracking on which FOSS package we want to use, as a community 
decision. I suggest preparation and a public vote.



Other ideas?


hth,
James

[gentoo-dev] Gentooo 501(c) accounting

[james]

Hello,


There was some discussion before about the software used for gentoo the 
charity (501)(c). It seems to have perked up a bit of discussion on 
gnucash, where all of the posting I have read suggest that gnucash is a 
wonderful accounting system for  charity organizations. There also 
appears to be lots of experience and help to. I thought this issue need 
a separate thread on gentoo-dev, a robust decision, and a team based 
solution, if  not a council item.


Here is the latest posting I have received on the 501(c) subject matter,
I thought I share and formally open up a discussion on the subject:



Here's my original post::

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


The the most recent reply:

>
> [1] http://www.ledger-cli.org/

I regard cli accounting as a friend of GnuCash rather than the
competition, there isn't anything one can do that the other can't in
accounting terms, also notice that cli accounting is becoming less so as
time passes, there are UIs and SQL type reports and so on being added
all the time, the principle is that compared to commercial products you
can, if you really want to, see a stream of transactions in ordinary ABC
and 123 terms, gnc can be dumped to cli and vice versa.

I'm not saying you or someone else should choose one or the other, I'm
asking you to thunk which is most likely to get people keeping good
records for the benefit of their non-profit.  I know that for one
non-profit I help out with a basic cli would be a non-starter, no UI and
the tx simply wouldn't get entered.

> [2] http://www.accountingcoach.com/nonprofit-accounting/explanation/1

worth reading, note the bits about restricted funds, that is what people
that are familiar with for-profit orgs usually struggle with conceptually

> [3] https://sfconservancy.org/npoacct/

that's been updated since I read it last but seems to be more face lift
than new content

James, you've got some good links there but don't actually say what the
imperatives for your correspondent are.

I, and I am sure others, are happy to espouse GnuCash, *if we think it
is right* for your org.  I don't have enough to go on.  There is little
harm in trying it, however, as it is easy enough to get your tx in and
out if cli accounting is your alternative.

Happy helping and non-profiteering (if that is even a concept in merka
post Trump)
--
Wm

.


Surely our code of conduct, evidence by principled and publish documents 
and the records of expenditures over the years, are quintessential 
documents and should experience governance in the sunshine, or no?


hth,
James

Re: [gentoo-dev] tinfo flag

[Pacho Ramos]

El mié, 07-12-2016 a las 10:27 -0500, Ian Stakenvicius escribió:
> 
[...]
> There is only one instance of a dependency atom that requires the
> tinfo flag to be disabled, and that package is an old game whos build
> system and ebuild is flawed in this regard.  All others are fine with
> the flag being enabled so far as I can tell (and if they're not then
> it's a bug that needs to be addressed anyhow).
> 

Looking to this tracker bug there would be more packages needing to be
fixed (and probably a more recent tinderbox would be needed)
https://bugs.gentoo.org/show_bug.cgi?id=457530

But looking more deeply to Fedora and openSuSE, they seem to not face
this breakage even enabling tinfo :/, but, at least on openSuSE, they
seem to play some "black magic" in the ncurses .pc files to probably
not cause this issue as I see in their .spec file:
http://download.opensuse.org/tumbleweed/repo/src-oss/suse/src/ncurses-6
.0-16.1.src.rpm

Re: [gentoo-dev] tinfo flag

[Alexis Ballier]

On Wed, 7 Dec 2016 10:16:47 +0100
Michał Górny  wrote:
> > Basically you're suggesting to drop either of those modes.  Now I'm
> > asking, would one of those (likely tinfo mode) be workable in all
> > packages?  Do you find that it would cause less issues than this
> > solution?  And I'm talking about end-user issues, not ebuild
> > implementation issues.  
> 
> Yes. If I recall correctly, libncurses links to libtinfo, so packages
> already built continue to work. Of course, new packages (including
> deps of the libraries already linked to libncurses) may fail to build.


So ncurses -> ncurses[tinfo] is not breaking.
ncurses[tinfo] -> ncurses breaks ABI all apart.

Still a bad idea to have this randomly switchable.

Having the useflag around is not wrong, but we should definitely force
one state by pacakge.use.mask/force. People that want to experiment
should know what they're doing. Remember libcxx on fbsd, right ?


Alexis.

Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish

[james]

On 12/07/2016 02:44 AM, Duncan wrote:

james posted on Tue, 06 Dec 2016 22:10:16 -0500 as excerpted:


Really, for someone like me, it is just best to avoid irc.


FWIW, some 12 years ago now, in 2004, I started using gentoo, with the
intent of contributing and potentially eventually becoming a dev.

Somewhere along the line but rather early in the process, I read that IRC
was absolutely required at least for the final interview, and given that
I too strongly prefer email (or for group communications better yet
newsgroups, with gmane being that bridge for most mailing lists), I
decided my contributions, such as they are, can be better made either
elsewhere, or to gentoo, but without becoming a dev.

Put it this way.  There's a lot of FLOSS projects out there hurting for
devs, and if some of them throw up entirely artificial barriers that some
have problems with to the direct repo contribution level when there are
so many other options that don't, fine, it's their prerogative, but they
obviously aren't hurting for devs as much as they might claim, if they
have the luxury of throwing up such artificial barriers to filter some
potential contributors out.

Much later, likely after some recruiters project changes, someone from
recruiters clarified that IRC on the final interview isn't actually
/required/, there might be ways around it in individual cases.
Apparently it does need to be real-time synchronous for some reason, but
he suggested that a (VoIP?) phone call or the like could be arranged as
an alternative.  In theory I could do that.

But by then, while I continued then and continue now to use gentoo as it
really does seem the best and most flexible scripted build-it-yourself
distro out there, my enthusiasm for becoming a dev had burned off due to
finding it simply wasn't an option for so long, and given all the work
involved, I decided I could simply remain as I was and as I have for now
over a decade, a gentoo user and contributor on various lists, bugzilla,
etc, as well as a generally non-coder contributor to a few selected
upstreams.

Now it seems to be IRC hard-required again.  

I do find it a bit ironic, tho, since literally generations of devs have
come and gone since I started, always with the intent to contribute to
the best of my ability, back in 2004.  From my perspective, that's a lot
of additional contributions missed in the decade-plus since then.
Furthermore, I see little reason I'll not still be gentooing in another
decade, even three, by which time I'd be turning 80 (I'm turning 50 in
January), if both gentoo and I are still around by then.  That's a
lifetime of additional contributions from my perspective needlessly
missed, but I guess they must not be so desperately needed after all,
apparently because the quality of contributions from people that don't
IRC are of significantly enough lower quality that it's simply not worth
bothering to recruit those folks.  



I want to get  the quizes done to the current version, mostly to prove I 
have the knowledge and work on my ebuild and bring them up to EAPI 6
or possible EAPI-7 (is it reasonably formulated yet?). Maybe I could 
just ask Duncan to grade those quizes; I certainly trust his judgment.



I do not need to be a formalized as a gentoo dev. But with over a decade 
of gentoo experience, a bachelor in EE, a professional engineering 
registration and a Masters in CS (yes from an ABETT university), decades 
of coding,  and I've had significant issue with the process, you'd think 
that this effort to become qualified as a gentoo dev, is maybe a bit too 
socially subjective and more of a cruel social filter to folks that they 
(then existing gentoo devs) just do not want in the clubhouse. Thanks 
Duncan for stating my case too. (Actually more eloquently that I ever 
could).  If I've been rude or abusive, I apologize, but it's a very 
small fraction, at most,
compared to the angst folks experience, as they look, covetously at the 
gentoo tree. Are there any shareable apples ?



I also really  like  the Anna W. idea of using a GLEP to formalize 
methods to fork Gentoo, very straightforward and very easy. From an 'old 
fart's'  gentoo distro, folks could even work on core codes (think 
bootstrap, profiles, compilers and such) and test their ideas before 
submitting ideas/ebuild to gentoo_irc_proper. Someone might just 
experiment for a replacement/enhancement to Bugzilla or such? I know 
that 'fork' scenario will work for me.  In fact with a repo that is 
visible and usable via layman, folks could just try ebuilds or groups of 
ebuilds from a repo. Seems like we had this discussion, with another 
young coder on gentoo-dev less than a year ago?



However, when I start pushing a 'bare-metal' provisioning systems, not 
dissimilar to CoreOS's 'ignition' then a separate gentoo-hack-distro
would be very useful. My research (on bench-marking thousands of 
different clusters/codes) on identical hardware configurations, the 
installation has to 

Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish

[Jorge Manuel B. S. Vicetto]

On Wed, 7 Dec 2016, Jorge Manuel B. S. Vicetto wrote:



I'm asking recuiters directly, but unless someone changed the rules and I was 
distracted, irc is not mandatory.


I've got confirmation that nothing has changed, so irc is not mandatory.
I hope this clears any misunderstandings and puts an end to any 
speculation.


Best regards,
Jorge Manuel B. S. Vicetto
Gentoo Developer

Re: [gentoo-dev] tinfo flag

[Ian Stakenvicius]

On 07/12/16 05:40 AM, konsolebox wrote:
> On Wed, Dec 7, 2016 at 5:16 PM, Michał Górny  wrote:
>> On Wed, 7 Dec 2016 16:16:45 +0800
>> konsolebox  wrote:
>>
>>> On Wed, Dec 7, 2016 at 1:23 PM, Michał Górny  wrote:
 On Tue, 6 Dec 2016 20:11:34 -0600
 William Hubbs  wrote:

> On Tue, Dec 06, 2016 at 05:26:19PM -0500, Mike Gilbert wrote:
>> On Tue, Dec 6, 2016 at 4:15 PM, Michał Górny  wrote:
>>> On Tue, 6 Dec 2016 12:54:26 -0500
>>> Mike Gilbert  wrote:
>>>
 On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  
 wrote:
> Please consider promoting the use of tinfo flag in packages that
> depend on sys-libs/ncurses so that they would synchronize properly
> with sys-libs/ncurses[tinfo].

 I would rather see the tinfo USE flag removed from ncurses.
>>>
>>> vapier doesn't consider this QA violation a QA violation.
>>>
>>> https://bugs.gentoo.org/487844
>>
>> Perhaps QA could take some action then?
>>
>> Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor 
>> solution.
>
> 
> Our policies are in the dev manual, so please cite the violation there.
> If you can't, this is not a qa violation, so please don't call it one.
> 
>
> I don't see a problem with the use flag and suggest updating the other 
> ebuilds.

 The flag randomly changes ABI, breaking all reverse dependencies.
 Please tell me this is a good practice.
>>>
>>> And there you had just proven that the ncurses package is installed in
>>> two modes, showing that a flag like tinfo is needed to represent them.
>>> It's not the ncurses package's fault.  It's the depending packages'
>>> responsibility to properly adapt to it.
>>
>> Packages are not intelligent beings, so they can't have responsibility.
> 
> Of course.
> 
>> Package maintainers have. You can't expect people to spend a lot of
>> time updating a lot of packages every time a new ABI-breaking flag is
>> suddenly introduced in a core package, if it's not even clear if it
>> going to stay long-term.
> 
> So you're suggesting to wait and keep things [partly] broken until
> then.  Why not fix things first then remove the [-tinfo] feature when
> everything no longer needs it instead.  This is even just a one-time
> solution, and is not much different with the massive number of
> pkg-config patches currently being implemented among ebuilds.  (Again,
> I'm not exactly liking the use of pkg-config.   I'd rather have a
> simple export since it's good enough, easier to implement, less
> compromising with the source, and is more universal.)
> 

Here's the thing -- ncurses provides all functionality regardless of
whether it's split into two libs (libncurses+libtinfo) or not.  So
what this flag is really doing is providing the capability of linking
to just part of ncurses instead of all of it, if a project desires.
And projects(binary ones at that) are doing this, which is why we have
some deps that require the tinfo flag to be enabled currently.

There is only one instance of a dependency atom that requires the
tinfo flag to be disabled, and that package is an old game whos build
system and ebuild is flawed in this regard.  All others are fine with
the flag being enabled so far as I can tell (and if they're not then
it's a bug that needs to be addressed anyhow).

SO, in summary, it would seem to make sense (since anything prebuilt
will work as-is, and anything compiled will be built to work with it)
to remove the tinfo flag but force libtinfo to be built and installed
-- simply make it non-optional.  Additionally, we can set
SLOT="0/6tinfo" which will trigger subslot rebuilds to ensure anything
that may need to be rebuilt to link to both libncurses and libtinfo
will be rebuilt when the tinfo-IUSE-less version gets installed.

We not only have a solution that'll address the
ABI-break-on-USE-change issue, but also a migration path that will be
transparent to users via a -uDN @world.  I call that a win-win.  The
only thing we lose is the easy ability to build an all-in-one
libncurses.  So if there is an actual need for that which we have yet
to find, this is an official request for comments to let us know.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Cross Post due to technical component - Thanks for all the fish

[Jorge Manuel B. S. Vicetto]

On Wed, 7 Dec 2016, Duncan wrote:


james posted on Tue, 06 Dec 2016 22:10:16 -0500 as excerpted:


Really, for someone like me, it is just best to avoid irc.


FWIW, some 12 years ago now, in 2004, I started using gentoo, with the
intent of contributing and potentially eventually becoming a dev.

Somewhere along the line but rather early in the process, I read that IRC
was absolutely required at least for the final interview, and given that
I too strongly prefer email (or for group communications better yet
newsgroups, with gmane being that bridge for most mailing lists), I
decided my contributions, such as they are, can be better made either
elsewhere, or to gentoo, but without becoming a dev.





Much later, likely after some recruiters project changes, someone from
recruiters clarified that IRC on the final interview isn't actually
/required/, there might be ways around it in individual cases.
Apparently it does need to be real-time synchronous for some reason, but
he suggested that a (VoIP?) phone call or the like could be arranged as
an alternative.  In theory I could do that.



Now it seems to be IRC hard-required again.  




I'm asking recuiters directly, but unless someone changed the rules and I 
was distracted, irc is not mandatory.
More important than an irc review session though, we have several 
developers that rarely, if ever, do irc, so it's certainly possible to be 
a Gentoo Developer and not maintain a regular irc presence.
To be clear, irc is a good a way to be part of the team and to quickly 
talk to others, so we should encourage its use. But encouraging something 
is not the same as making it mandatory.


About not really wanting contribution and making up "barriers", the 
"barriers" we've put are in our view required to make sure people have a 
real interest in being in this community and know enough to be able to 
maintain packages (for those applying for ::gentoo access).


Best regards,
Jorge Manuel B. S. Vicetto
Gentoo Developer


PS - Let's please move all this discussion to the project ml as this 
clearly doesn't belong in the gentoo-dev ml.

Re: [gentoo-dev] tinfo flag

[Pacho Ramos]

El mar, 06-12-2016 a las 22:15 +0100, Michał Górny escribió:
> On Tue, 6 Dec 2016 12:54:26 -0500
> Mike Gilbert  wrote:
> 
> > 
> > On Mon, Dec 5, 2016 at 6:13 AM, konsolebox 
> > wrote:
> > > 
> > > Please consider promoting the use of tinfo flag in packages that
> > > depend on sys-libs/ncurses so that they would synchronize
> > > properly
> > > with sys-libs/ncurses[tinfo].  
> > 
> > I would rather see the tinfo USE flag removed from ncurses.
> 
> vapier doesn't consider this QA violation a QA violation.
> 
> https://bugs.gentoo.org/487844
> 

Well, I think I have seen other packages with this similar behavior...
perl[ithreads] I think is one of them :/ Then, I wouldn't focus this in
a fight between QA violations or not :| Otherwise we will end up with
endless arguments focusing on this fights instead of trying to handle
the concrete issue.

I agree that this is really ugly... but probably we would need to
handle each case in particular. The problem is that I don't know what
is the correct approach for this case... I would think about enabling
tinfo always... but probably it breaks reverse deps badly :/ Anyway, I
think Fedora is enabling it always, then, it shouldn't be too hard. 

What people from base-system think about this? What is the advantage of
allowing people to switch this behavior?

Re: [gentoo-dev] tinfo flag

[konsolebox]

On Wed, Dec 7, 2016 at 5:16 PM, Michał Górny  wrote:
> On Wed, 7 Dec 2016 16:16:45 +0800
> konsolebox  wrote:
>
>> On Wed, Dec 7, 2016 at 1:23 PM, Michał Górny  wrote:
>> > On Tue, 6 Dec 2016 20:11:34 -0600
>> > William Hubbs  wrote:
>> >
>> >> On Tue, Dec 06, 2016 at 05:26:19PM -0500, Mike Gilbert wrote:
>> >> > On Tue, Dec 6, 2016 at 4:15 PM, Michał Górny  wrote:
>> >> > > On Tue, 6 Dec 2016 12:54:26 -0500
>> >> > > Mike Gilbert  wrote:
>> >> > >
>> >> > >> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  
>> >> > >> wrote:
>> >> > >> > Please consider promoting the use of tinfo flag in packages that
>> >> > >> > depend on sys-libs/ncurses so that they would synchronize properly
>> >> > >> > with sys-libs/ncurses[tinfo].
>> >> > >>
>> >> > >> I would rather see the tinfo USE flag removed from ncurses.
>> >> > >
>> >> > > vapier doesn't consider this QA violation a QA violation.
>> >> > >
>> >> > > https://bugs.gentoo.org/487844
>> >> >
>> >> > Perhaps QA could take some action then?
>> >> >
>> >> > Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor 
>> >> > solution.
>> >>
>> >> 
>> >> Our policies are in the dev manual, so please cite the violation there.
>> >> If you can't, this is not a qa violation, so please don't call it one.
>> >> 
>> >>
>> >> I don't see a problem with the use flag and suggest updating the other 
>> >> ebuilds.
>> >
>> > The flag randomly changes ABI, breaking all reverse dependencies.
>> > Please tell me this is a good practice.
>>
>> And there you had just proven that the ncurses package is installed in
>> two modes, showing that a flag like tinfo is needed to represent them.
>> It's not the ncurses package's fault.  It's the depending packages'
>> responsibility to properly adapt to it.
>
> Packages are not intelligent beings, so they can't have responsibility.

Of course.

> Package maintainers have. You can't expect people to spend a lot of
> time updating a lot of packages every time a new ABI-breaking flag is
> suddenly introduced in a core package, if it's not even clear if it
> going to stay long-term.

So you're suggesting to wait and keep things [partly] broken until
then.  Why not fix things first then remove the [-tinfo] feature when
everything no longer needs it instead.  This is even just a one-time
solution, and is not much different with the massive number of
pkg-config patches currently being implemented among ebuilds.  (Again,
I'm not exactly liking the use of pkg-config.   I'd rather have a
simple export since it's good enough, easier to implement, less
compromising with the source, and is more universal.)

> Not to mention the USE flag will be a true PITA for our users. Just
> imagine all the conflicts when one package doesn't support
> ncurses[tinfo], or the other way around...

Better show the conflicts than allow users to "shoot themselves in the
foot" without even knowing it.  I'd rather solve those issues than
"trust" that everything would just work without knowing it, or fix a
package everytime I see a breakage.  Consistency comes first before
anything else, otherwise you're applying an incomplete solution or a
workaround.

>> Basically you're suggesting to drop either of those modes.  Now I'm
>> asking, would one of those (likely tinfo mode) be workable in all
>> packages?  Do you find that it would cause less issues than this
>> solution?  And I'm talking about end-user issues, not ebuild
>> implementation issues.
>
> Yes. If I recall correctly, libncurses links to libtinfo, so packages
> already built continue to work. Of course, new packages (including deps
> of the libraries already linked to libncurses) may fail to build.
>
> Remember that binary distros have to make a choice.

This is Gentoo.  Consider reading the first two lines in
https://gentoo.org/get-started/about/.

> I can understand
> keeping the flag to help people migrate more gracefully when building
> from source. But it's not a way to run things long-term.

Long-term about?

>> I find that forcing depending packages to follow that mode sounds
>> worse than what you claim a QA violation.
>
> Really? Because 'choice' or do you have a better argument than that?

I didn't get that.  Please be less ambiguous.

Note that I didn't imply there that I agree with your idea.  The use
of tinfo in ncurses is a correct uncompromising solution.  The one
questionable is forcing packages to work with [tinfo], because there
may be cases where it could resort to too much patching that it
already becomes a hack.

-- 
konsolebox

Re: [gentoo-dev] Cross Post due to technical component - Thanks for all the fish

[Kristian Fiskerstrand]

On 12/07/2016 06:07 AM, Robin H. Johnson wrote:

>> So I just now sent email to :
>> proxy-maint+subscr...@gentoo.org

You likely want to check out [gentoo-proxy-ma...@lists.gentoo.org]
instead of the project alias. The latter is restricted to Gentoo developers.

References:
[gentoo-proxy-ma...@lists.gentoo.org]
https://archives.gentoo.org/gentoo-proxy-maint/

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] tinfo flag

[Michał Górny]

On Wed, 7 Dec 2016 16:16:45 +0800
konsolebox  wrote:

> On Wed, Dec 7, 2016 at 1:23 PM, Michał Górny  wrote:
> > On Tue, 6 Dec 2016 20:11:34 -0600
> > William Hubbs  wrote:
> >  
> >> On Tue, Dec 06, 2016 at 05:26:19PM -0500, Mike Gilbert wrote:  
> >> > On Tue, Dec 6, 2016 at 4:15 PM, Michał Górny  wrote:  
> >> > > On Tue, 6 Dec 2016 12:54:26 -0500
> >> > > Mike Gilbert  wrote:
> >> > >  
> >> > >> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  
> >> > >> wrote:  
> >> > >> > Please consider promoting the use of tinfo flag in packages that
> >> > >> > depend on sys-libs/ncurses so that they would synchronize properly
> >> > >> > with sys-libs/ncurses[tinfo].  
> >> > >>
> >> > >> I would rather see the tinfo USE flag removed from ncurses.  
> >> > >
> >> > > vapier doesn't consider this QA violation a QA violation.
> >> > >
> >> > > https://bugs.gentoo.org/487844  
> >> >
> >> > Perhaps QA could take some action then?
> >> >
> >> > Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor 
> >> > solution.  
> >>
> >> 
> >> Our policies are in the dev manual, so please cite the violation there.
> >> If you can't, this is not a qa violation, so please don't call it one.
> >> 
> >>
> >> I don't see a problem with the use flag and suggest updating the other 
> >> ebuilds.  
> >
> > The flag randomly changes ABI, breaking all reverse dependencies.
> > Please tell me this is a good practice.  
> 
> And there you had just proven that the ncurses package is installed in
> two modes, showing that a flag like tinfo is needed to represent them.
> It's not the ncurses package's fault.  It's the depending packages'
> responsibility to properly adapt to it.

Packages are not intelligent beings, so they can't have responsibility.
Package maintainers have. You can't expect people to spend a lot of
time updating a lot of packages every time a new ABI-breaking flag is
suddenly introduced in a core package, if it's not even clear if it
going to stay long-term.

Not to mention the USE flag will be a true PITA for our users. Just
imagine all the conflicts when one package doesn't support
ncurses[tinfo], or the other way around...

> Basically you're suggesting to drop either of those modes.  Now I'm
> asking, would one of those (likely tinfo mode) be workable in all
> packages?  Do you find that it would cause less issues than this
> solution?  And I'm talking about end-user issues, not ebuild
> implementation issues.

Yes. If I recall correctly, libncurses links to libtinfo, so packages
already built continue to work. Of course, new packages (including deps
of the libraries already linked to libncurses) may fail to build.

Remember that binary distros have to make a choice. I can understand
keeping the flag to help people migrate more gracefully when building
from source. But it's not a way to run things long-term.

> I find that forcing depending packages to follow that mode sounds
> worse than what you claim a QA violation.

Really? Because 'choice' or do you have a better argument than that?

-- 
Best regards,
Michał Górny


pgpsE1ywyNM1i.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] tinfo flag

[konsolebox]

On Wed, Dec 7, 2016 at 1:23 PM, Michał Górny  wrote:
> On Tue, 6 Dec 2016 20:11:34 -0600
> William Hubbs  wrote:
>
>> On Tue, Dec 06, 2016 at 05:26:19PM -0500, Mike Gilbert wrote:
>> > On Tue, Dec 6, 2016 at 4:15 PM, Michał Górny  wrote:
>> > > On Tue, 6 Dec 2016 12:54:26 -0500
>> > > Mike Gilbert  wrote:
>> > >
>> > >> On Mon, Dec 5, 2016 at 6:13 AM, konsolebox  wrote:
>> > >> > Please consider promoting the use of tinfo flag in packages that
>> > >> > depend on sys-libs/ncurses so that they would synchronize properly
>> > >> > with sys-libs/ncurses[tinfo].
>> > >>
>> > >> I would rather see the tinfo USE flag removed from ncurses.
>> > >
>> > > vapier doesn't consider this QA violation a QA violation.
>> > >
>> > > https://bugs.gentoo.org/487844
>> >
>> > Perhaps QA could take some action then?
>> >
>> > Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor solution.
>>
>> 
>> Our policies are in the dev manual, so please cite the violation there.
>> If you can't, this is not a qa violation, so please don't call it one.
>> 
>>
>> I don't see a problem with the use flag and suggest updating the other 
>> ebuilds.
>
> The flag randomly changes ABI, breaking all reverse dependencies.
> Please tell me this is a good practice.

And there you had just proven that the ncurses package is installed in
two modes, showing that a flag like tinfo is needed to represent them.
It's not the ncurses package's fault.  It's the depending packages'
responsibility to properly adapt to it.

Basically you're suggesting to drop either of those modes.  Now I'm
asking, would one of those (likely tinfo mode) be workable in all
packages?  Do you find that it would cause less issues than this
solution?  And I'm talking about end-user issues, not ebuild
implementation issues.

I find that forcing depending packages to follow that mode sounds
worse than what you claim a QA violation.

-- 
konsolebox

Re: [gentoo-dev] tinfo flag

[konsolebox]

On Wed, Dec 7, 2016 at 6:26 AM, Mike Gilbert  wrote:
> Updating ~1500 ebuilds with a [tinfo=] use-dep seems like a poor solution.

If it's the only consistent solution, either you go for it,
compromise, or be contented that it's half-broken.  I'm not a fan of
the latter 2.  Or maybe we can /hopefully/ wait for a non-workaround
solution in the future EAPI, which I doubt could be provided.

I'm not a developer, but I can volunteer to make some of the changes.
I'll just place the packages in a public repo.  Just promise me my
effort won't go to waste.

Doing gradual changes only for every ebuild version bump is not a bad
thing either, since that's even what is happening right now.

Maybe we can create an eclass to make some changes easier (if
applicable and useful), and/or debate whether the use of pkg-config
over a simple `use tinfo` test and an `export` is effectively better
in this context.

-- 
konsolebox