[gentoo-portage-dev] [PATCH] multilib-strict: disable recursion into subdirectories (bug 424423)

[Zac Medico]

Disable recursion into subdirectories, in order to avoid false-positives.
The MULTILIB_STRICT_EXEMPT variable only served to filter false-positives
that were triggered by recursion, so it will no longer be needed.

X-Gentoo-bug: 424423
X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=424423
---
 bin/install-qa-check.d/80multilib-strict | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/bin/install-qa-check.d/80multilib-strict 
b/bin/install-qa-check.d/80multilib-strict
index f944be9e6..21fe93d4b 100644
--- a/bin/install-qa-check.d/80multilib-strict
+++ b/bin/install-qa-check.d/80multilib-strict
@@ -6,14 +6,13 @@ multilib_strict_check() {
then
rm -f "${T}/multilib-strict.log"
local abort=no dir file
-   MULTILIB_STRICT_EXEMPT=$(echo ${MULTILIB_STRICT_EXEMPT} | sed 
-e 's:\([(|)]\):\\\1:g')
for dir in ${MULTILIB_STRICT_DIRS} ; do
[[ -d ${ED}/${dir} ]] || continue
-   for file in $(find ${ED}/${dir} -type f | grep -v 
"^${ED}/${dir}/${MULTILIB_STRICT_EXEMPT}"); do
-   if file ${file} | egrep -q 
"${MULTILIB_STRICT_DENY}" ; then
+   while read -r -d '' file; do
+   if file "${file}" | egrep -q 
"${MULTILIB_STRICT_DENY}" ; then
echo "${file#${ED}//}" >> 
"${T}/multilib-strict.log"
fi
-   done
+   done < <(find "${ED}/${dir}" -maxdepth 1 -type f 
-print0)
done
 
if [[ -s ${T}/multilib-strict.log ]] ; then
-- 
2.13.0

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Duncan]

Rich Freeman posted on Mon, 31 Jul 2017 20:55:05 -0400 as excerpted:

> On Mon, Jul 31, 2017 at 8:24 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> Rich Freeman posted on Mon, 31 Jul 2017 11:11:24 -0400 as excerpted:
>>
>>> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner 
>>> wrote:

 [T]he conclusion I was hoping to draw is that one
 has 2 repos instead of 1.

 1) Rolling.
 2) Stable.

>>> This seems like it would be fairly painful to maintain.
>>
>> FWIW, the gentoo/kde team effectively do this right now
>>
> The difficulty isn't in moving the ebuilds around.
> 
> The difficulty is in knowing WHICH ebuilds to move around.
> 
> In the case of KDE it is the maintainers doing the maintaining,

Very good point.  Thanks.

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

Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Mon, Jul 31, 2017 at 8:24 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Rich Freeman posted on Mon, 31 Jul 2017 11:11:24 -0400 as excerpted:
>
>> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner 
>> wrote:
>>>
>>>
>>> Sorry, to be clear the conclusion I was hoping to draw is that one has
>>> 2 repos instead of 1.
>>>
>>> 1) Rolling.
>>> 2) Stable.
>>>
>>> Rolling is typical ~arch Gentoo. People in rolling can do whatever they
>>> want; they can't affect stable at all.
>>>
>>> Stable is an entirely separate repo, a fork, where CPVs are pulled from
>>> Rolling into Stable. If Stable wants to keep a gnarly old version of
>>> some package around; great! But the rolling people don't have to care.
>>>
>>>
>> This seems like it would be fairly painful to maintain.  You'd need to
>> constantly pull in new packages, and prune out old ones.  It would
>> duplicate many of the functions maintainers already do.  I doubt anybody
>> would go to the trouble to make this happen.
>
> FWIW, the gentoo/kde team effectively do this right now, tho only with kde
> packages and some of their deps, and it's live/prerelease/release-staging
> vs ~arch/stable, not ~arch vs stable.  But the amount of work is surely
> similar, and they've been doing it now for a number of years and over a
> major kde version bump, an upstream svn/git upgrade and general upstream
> remodularization.
>

The difficulty isn't in moving the ebuilds around.

The difficulty is in knowing WHICH ebuilds to move around.

In the case of KDE it is the maintainers doing the maintaining, so
they already understand which versions should move.  They've all been
tested, so I suspect it is likely a lift and place of the entire
thing.

In the proposed multi-repository approach the maintainers would not be
the ones doing the moving.

Now, I guess you could have a snapshot/release-based approach.  Take a
snapshot of the ENTIRE ~arch tree.  Then do whatever level of QA, and
after a delay move the ENTIRE ~arch tree to stable.  The problem with
this is that you'll probably pick that oddball version of some package
that is about to be replaced and isn't a good stable candidate, and so
on.  It also would be difficult to actually test it all.

And if you're going to get the maintainers to move all their own
stuff, then you're just giving them extra work compared to just using
the KEYWORDS variable.

In the current state the maintainer is at the heart of the
stabilization process, so the person who already needs to understand
the individual package is the one deciding which versions go stable.
Duplicating this level of knowledge would not be straightforward.

-- 
Rich

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Duncan]

Rich Freeman posted on Mon, 31 Jul 2017 11:11:24 -0400 as excerpted:

> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner 
> wrote:
>>
>>
>> Sorry, to be clear the conclusion I was hoping to draw is that one has
>> 2 repos instead of 1.
>>
>> 1) Rolling.
>> 2) Stable.
>>
>> Rolling is typical ~arch Gentoo. People in rolling can do whatever they
>> want; they can't affect stable at all.
>>
>> Stable is an entirely separate repo, a fork, where CPVs are pulled from
>> Rolling into Stable. If Stable wants to keep a gnarly old version of
>> some package around; great! But the rolling people don't have to care.
>>
>>
> This seems like it would be fairly painful to maintain.  You'd need to
> constantly pull in new packages, and prune out old ones.  It would
> duplicate many of the functions maintainers already do.  I doubt anybody
> would go to the trouble to make this happen.

FWIW, the gentoo/kde team effectively do this right now, tho only with kde 
packages and some of their deps, and it's live/prerelease/release-staging 
vs ~arch/stable, not ~arch vs stable.  But the amount of work is surely 
similar, and they've been doing it now for a number of years and over a 
major kde version bump, an upstream svn/git upgrade and general upstream 
remodularization.

They seem to have the method and routine /down/, and I'm sure many of the 
lessons they've learned could be used were such a main repo split to be 
undertaken, but I honestly have no idea whether they'd consider the 
effort huge or "painful to maintain", only that they do it -- pretty  
effectively if I might add from my own consumption of both the main tree 
and kde overlay.

And to address the concern over users with mixed ~arch/stable usage, as a 
user effectively doing it but with mixed ~arch-main/live-kde usage, the 
trouble of having to pull and update from both trees, managing masks, 
etc, isn't actually that bad at all, particularly given the fact that the 
main mask/unmask sets are maintained (automatically via project script) 
in the kde repo so all I have to do is symlink appropriately and add an 
occasionally temporarily overlooked one to my local exception file.


For gentoo/kde it would seem to have been worth it, but you'd have to ask 
them if it's "painful" for them.

So it's certainly doable, maintainable over years and major changes, and 
consumable, as gentoo/kde devs and their users have been and continues to 
demonstrate. =:^)  The /big/ question then is only whether that model's 
actually a good fit for the wider gentoo culture, and I still have my 
doubts on that one.

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

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Peter Volkov]

On Mon, Jul 31, 2017 at 6:11 PM, Rich Freeman  wrote:

> On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner  wrote:
> > Sorry, to be clear the conclusion I was hoping to draw is that one has 2
> > repos instead of 1.
> >
> > 1) Rolling.
> > 2) Stable.
> >
> > Rolling is typical ~arch Gentoo. People in rolling can do whatever they
> > want; they can't affect stable at all.
> >
> > Stable is an entirely separate repo, a fork, where CPVs are pulled from
> > Rolling into Stable. If Stable wants to keep a gnarly old version of some
> > package around; great! But the rolling people don't have to care.
> >
>
> This seems like it would be fairly painful to maintain.  You'd need to
> constantly pull in new packages, and prune out old ones.  It would
> duplicate many of the functions maintainers already do.  I doubt
> anybody would go to the trouble to make this happen.
>

Long time ago releng team did something similar. We defined stable as
tested distribution that has all security updates merged back. From my
experience what made that efforts very tedious was that there were packages
that do not specify minimum required versions for dependencies. Thus we had
to duplicate maintainer's work and check lot's of dependencies again.

Also when we speak about stable tree we first should define what stability
are we talking about? What do we guarantee? ABI/API compatibility or that
it is expected "just work" (whatever this means)?

--
Peter.

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michał Górny]

On pon, 2017-07-31 at 10:52 -0400, Alec Warner wrote:
> On Fri, Jul 28, 2017 at 9:05 PM, Rich Freeman  wrote:
> 
> > On Fri, Jul 28, 2017 at 3:44 PM, Alec Warner  wrote:
> > > 
> > > On Fri, Jul 28, 2017 at 3:44 AM, Andreas K. Huettel <
> > 
> > dilfri...@gentoo.org>
> > > wrote:
> > > > 
> > > > Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
> > > > > 
> > > > > I hold a perhaps radical view: I would like to simply remove stable.
> > > > > 
> > > > > I continue to feel that maintaining two worlds (stable+unstable)
> > > > > carries with it an unneccessary cost.
> > > > > 
> > > > 
> > > > That's not feasible. It would kill off any semi-professional or
> > > > professional
> > > > Gentoo use, where a minimum of stability is required.
> > > 
> > > 
> > > So my argument (for years) has been that this is the right thing all
> > 
> > along.
> > > 
> > > If people want a stable Gentoo, fork it and maintain it downstream of the
> > > rambunctious rolling distro.
> > > 
> > 
> > What is the difference between forking the repository, and just
> > maintaining a keyword inside the same repository, besides the former
> > being easier to integrate into QA/etc?
> > 
> > People who are interested in working on stable already do so, and
> > people who are not for the most part shouldn't be bothered by it.  In
> > the cases where stable has caused issues with maintainers the council
> > has generally dropped arches from stable support so that repoman won't
> > complain when packages are removed.
> > 
> 
> Sorry, to be clear the conclusion I was hoping to draw is that one has 2
> repos instead of 1.
> 
> 1) Rolling.
> 2) Stable.
> 
> Rolling is typical ~arch Gentoo. People in rolling can do whatever they
> want; they can't affect stable at all.
> 
> Stable is an entirely separate repo, a fork, where CPVs are pulled from
> Rolling into Stable. If Stable wants to keep a gnarly old version of some
> package around; great! But the rolling people don't have to care.

I was considering this but it won't work for users who mix stable
and ~arch. While we don't officially support this, they're a significant
portion of our user base and they usually have good reasons for doing
that.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-portage-dev] [PATCH] emerge --getbinpkg: https support for If-Modified-Since

[Zac Medico]

On Mon, Jul 31, 2017 at 8:10 AM, Brian Dolbec  wrote:
> On Mon, 31 Jul 2017 00:11:09 -0700
> Zac Medico  wrote:
>
>> When https certificate and hostname verification is enabled for
>> stdlib http clients (PEP 476), use python for If-Modified-Since
>> header support. When python lacks PEP 476 support, continue to
>> use FETCHCOMMAND for https certificate and hostname verification
>> (see security bug 469888).
>>
>> X-Gentoo-bug: 625246
>> X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=625246
>> ---
>>  pym/portage/dbapi/bintree.py | 10 ++
>>  pym/portage/util/_urlopen.py | 12 
>>  2 files changed, 18 insertions(+), 4 deletions(-)
>>
>
> looks fine

Thanks, pushed:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=1d821469d6b72ce051b02908f17302c500945788

-- 
Thanks,
Zac

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Rich Freeman]

On Mon, Jul 31, 2017 at 10:52 AM, Alec Warner  wrote:
>
>
> Sorry, to be clear the conclusion I was hoping to draw is that one has 2
> repos instead of 1.
>
> 1) Rolling.
> 2) Stable.
>
> Rolling is typical ~arch Gentoo. People in rolling can do whatever they
> want; they can't affect stable at all.
>
> Stable is an entirely separate repo, a fork, where CPVs are pulled from
> Rolling into Stable. If Stable wants to keep a gnarly old version of some
> package around; great! But the rolling people don't have to care.
>

This seems like it would be fairly painful to maintain.  You'd need to
constantly pull in new packages, and prune out old ones.  It would
duplicate many of the functions maintainers already do.  I doubt
anybody would go to the trouble to make this happen.

>
> Nothing stops Gentoo (the organization / community) from housing the above
> scheme in one organization. I mean, nothing but political will right? :)
>

That, and the fact that it will take a ton of effort to maintain.
Most likely if the tree is split stable will just be abandoned.
Anybody who is unsatisfied with the unstable tree would just quit
entirely, making their unstable packages unmaintained as well.

You need a critical mass to maintain a distro.  IMO having the stable
tree does not add all that much work for those who don't care about
it, but it gets us quite a few contributors.  Maybe we can afford to
lose them, or maybe enough will just move to unstable.  I'm not sure
it is easy to predict what the outcome of removing stable will be.

I'm all for looking for ways to make stable less of a burden on those
who aren't interested in it.  As far as I can tell the main one is not
being able to remove old packages without getting reverse deps
keyworded.  I think that all this would take is a script that would
drop the stable keywords on the reverse deps, which the council has
basically already approved (after a waiting period).

-- 
Rich

Re: [gentoo-portage-dev] [PATCH] emerge --getbinpkg: https support for If-Modified-Since

[Brian Dolbec]

On Mon, 31 Jul 2017 00:11:09 -0700
Zac Medico  wrote:

> When https certificate and hostname verification is enabled for
> stdlib http clients (PEP 476), use python for If-Modified-Since
> header support. When python lacks PEP 476 support, continue to
> use FETCHCOMMAND for https certificate and hostname verification
> (see security bug 469888).
> 
> X-Gentoo-bug: 625246
> X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=625246
> ---
>  pym/portage/dbapi/bintree.py | 10 ++
>  pym/portage/util/_urlopen.py | 12 
>  2 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/pym/portage/dbapi/bintree.py
> b/pym/portage/dbapi/bintree.py index c833968c2..95bd5dbf8 100644
> --- a/pym/portage/dbapi/bintree.py
> +++ b/pym/portage/dbapi/bintree.py
> @@ -18,7 +18,7 @@ portage.proxy.lazyimport.lazyimport(globals(),
>   'portage.util:atomic_ofstream,ensure_dirs,normalize_path,' +
> \ 'writemsg,writemsg_stdout',
>   'portage.util.path:first_existing',
> - 'portage.util._urlopen:urlopen@_urlopen',
> + 'portage.util._urlopen:urlopen@_urlopen,have_pep_476@_have_pep_476',
>   'portage.versions:best,catpkgsplit,catsplit,_pkg_str',
>  )
>  
> @@ -851,9 +851,9 @@ class binarytree(object):
>   download_timestamp +
> ttl > time.time(): raise UseCachedCopyOfRemoteIndex()
>  
> - # Don't use urlopen for https, since
> it doesn't support
> - # certificate/hostname verification
> (bug #469888).
> - if parsed_url.scheme not in
> ('https',):
> + # Don't use urlopen for https, unless
> + # PEP 476 is supported (bug #469888).
> + if parsed_url.scheme not in
> ('https',) or _have_pep_476(): try:
>   f = _urlopen(url,
> if_modified_since=local_timestamp) if hasattr(f, 'headers') and
> f.headers.get('timestamp', ''): @@ -965,6 +965,8 @@ class
> binarytree(object): "\n")
>   rmt_idx = pkgindex
>   except EnvironmentError as e:
> + # This includes URLError which is
> raised for SSL
> + # certificate errors when PEP 476 is
> supported. writemsg(_("\n\n!!! Error fetching binhost package" \
>   " info from '%s'\n") %
> _hide_url_passwd(base_url)) # With Python 2, the EnvironmentError
> message may diff --git a/pym/portage/util/_urlopen.py
> b/pym/portage/util/_urlopen.py index 4cfe183b1..fc9db74a0 100644
> --- a/pym/portage/util/_urlopen.py
> +++ b/pym/portage/util/_urlopen.py
> @@ -26,6 +26,18 @@ if sys.hexversion >= 0x300:
>  #  and the file-'mtime'
>  TIMESTAMP_TOLERANCE = 5
>  
> +
> +def have_pep_476():
> + """
> + Test whether ssl certificate verification is enabled by
> default for
> + stdlib http clients (PEP 476).
> +
> + @returns: bool, True if ssl certificate verification is
> enabled by
> + default
> + """
> + return hasattr(__import__('ssl'),
> '_create_unverified_context') +
> +
>  def urlopen(url, if_modified_since=None):
>   parse_result = urllib_parse.urlparse(url)
>   if parse_result.scheme not in ("http", "https"):

looks fine

-- 
Brian Dolbec 

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[William L. Thomson Jr.]

On Mon, 31 Jul 2017 12:56:18 +1000
Sam Jorna  wrote:
> 
> Sorry, I thought this thread was about whether to keep or discontinue
> the separation between stable and testing branches.

Yes and it was others that said lack of stable would effect
enterprise/professional usage. I simply said that argument was moot as
there are other objections beyond not having stable.

Most I know would say Gentoo as a whole is not stable, regardless of
any stable packages, branch, etc. They do not consider Gentoo stable.

FYI, I have always run Gentoo for professional usage. I have a
business. My business has always run Gentoo on all servers, desktops,
workstations etc. Those locally who have worked for me and in my LUG
know this fact. I have also interviewed with many companies in the US
who either did run Gentoo or still do. Thus I have some directly
knowledge on that shrinking market.

Beyond my opinion, gentoo -debian - suse -redhat
https://www.indeed.com/jobs?q=gentoo+-debian+-suse+-redhat=

Very few if any are after Gentoo skills. Change that to any other
distro and see the difference. Of course Gentoo is always mentioned
with others, but are they running Gentoo is the question. Seeking
Gentoo skills and companies running Gentoo are not the same.

gentoo
https://www.indeed.com/jobs?q=gentoo+=

It is always lumped in with others, rarely by itself.

-- 
William L. Thomson Jr.


pgpHPsz2_7Qux.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Alec Warner]

On Fri, Jul 28, 2017 at 9:05 PM, Rich Freeman  wrote:

> On Fri, Jul 28, 2017 at 3:44 PM, Alec Warner  wrote:
> >
> > On Fri, Jul 28, 2017 at 3:44 AM, Andreas K. Huettel <
> dilfri...@gentoo.org>
> > wrote:
> >>
> >> Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge:
> >> >
> >> > I hold a perhaps radical view: I would like to simply remove stable.
> >> >
> >> > I continue to feel that maintaining two worlds (stable+unstable)
> >> > carries with it an unneccessary cost.
> >> >
> >>
> >> That's not feasible. It would kill off any semi-professional or
> >> professional
> >> Gentoo use, where a minimum of stability is required.
> >
> >
> > So my argument (for years) has been that this is the right thing all
> along.
> >
> > If people want a stable Gentoo, fork it and maintain it downstream of the
> > rambunctious rolling distro.
> >
>
> What is the difference between forking the repository, and just
> maintaining a keyword inside the same repository, besides the former
> being easier to integrate into QA/etc?
>

> People who are interested in working on stable already do so, and
> people who are not for the most part shouldn't be bothered by it.  In
> the cases where stable has caused issues with maintainers the council
> has generally dropped arches from stable support so that repoman won't
> complain when packages are removed.
>

Sorry, to be clear the conclusion I was hoping to draw is that one has 2
repos instead of 1.

1) Rolling.
2) Stable.

Rolling is typical ~arch Gentoo. People in rolling can do whatever they
want; they can't affect stable at all.

Stable is an entirely separate repo, a fork, where CPVs are pulled from
Rolling into Stable. If Stable wants to keep a gnarly old version of some
package around; great! But the rolling people don't have to care.


>
> I won't say that having stable costs us nothing, but I think the cost
> is pretty low.  Asking people who want stable to leave isn't going to
> make things any better.
>

Nothing stops Gentoo (the organization / community) from housing the above
scheme in one organization. I mean, nothing but political will right? :)

-A


>
> --
> Rich
>
>

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[David Seifert]

On Mon, 2017-07-31 at 10:43 -0400, William L. Thomson Jr. wrote:
> On Mon, 31 Jul 2017 14:59:25 +0200
> "Andreas K. Huettel"  wrote:
> 
> > Am Montag, 31. Juli 2017, 04:44:58 CEST schrieb William L. Thomson
> > Jr.:
> > > 
> > > How about no foundation. Not even a legal entity. No
> > > certifications
> > > from vendors, nor for employees. No one to hire for official
> > > support. There are so many things far beyond anything having to
> > > do
> > > with a stable tree or not.  
> > 
> > I was *this* close to nominaing you for Trustee, until I realized
> > you're not even a foundation member...
> 
> Wait what? You blocked me from returning as a developer. Based on my
> human relation skills, or in your opinion lack there of
> https://bugs.gentoo.org/show_bug.cgi?id=135927#c43
> 
> How would you think I be fit for foundation Trustee? Which is a
> liason
> type role, at least with outside entities. That makes  little to no
> sense. A developer need technical skills more than personal. A
> Trustee
> needs personal and not so much technical Great logic!
> 
> It seems that foundation membership been messed up pretty bad. This
> seems to be the list of members. Which seems to only be developers.
> https://wiki.gentoo.org/wiki/Foundation:Member_List
> 
> Per the by laws, one is only removed from membership via voluntary
> request, and/or majority vote of the trustees to remove a member.
> https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.4._Continuat
> ion_of_Membership
> https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.8._Voluntary
> _Withdrawal_from_Membership
> https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.9._Terminati
> on_from_Membership
> 
> I may have requested removal, I seem to recall such. Though I am not
> sure others have. Seems the foundation is missing many members.
> Unless
> the trustees voted to remove many others.
> 
> Also developers are not automatically added per bylaws. They must
> apply for such.
> https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.3._Admission
> _of_Members
> 

https://en.wiktionary.org/wiki/sarcasm

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[William L. Thomson Jr.]

On Mon, 31 Jul 2017 14:59:25 +0200
"Andreas K. Huettel"  wrote:

> Am Montag, 31. Juli 2017, 04:44:58 CEST schrieb William L. Thomson
> Jr.:
> > 
> > How about no foundation. Not even a legal entity. No certifications
> > from vendors, nor for employees. No one to hire for official
> > support. There are so many things far beyond anything having to do
> > with a stable tree or not.  
> 
> I was *this* close to nominaing you for Trustee, until I realized
> you're not even a foundation member...

Wait what? You blocked me from returning as a developer. Based on my
human relation skills, or in your opinion lack there of
https://bugs.gentoo.org/show_bug.cgi?id=135927#c43

How would you think I be fit for foundation Trustee? Which is a liason
type role, at least with outside entities. That makes  little to no
sense. A developer need technical skills more than personal. A Trustee
needs personal and not so much technical Great logic!

It seems that foundation membership been messed up pretty bad. This
seems to be the list of members. Which seems to only be developers.
https://wiki.gentoo.org/wiki/Foundation:Member_List

Per the by laws, one is only removed from membership via voluntary
request, and/or majority vote of the trustees to remove a member.
https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.4._Continuation_of_Membership
https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.8._Voluntary_Withdrawal_from_Membership
https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.9._Termination_from_Membership

I may have requested removal, I seem to recall such. Though I am not
sure others have. Seems the foundation is missing many members. Unless
the trustees voted to remove many others.

Also developers are not automatically added per bylaws. They must
apply for such.
https://wiki.gentoo.org/wiki/Foundation:Bylaws#Section_4.3._Admission_of_Members

-- 
William L. Thomson Jr.


pgpEXLpdyOfib.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Andreas K. Huettel]

Am Montag, 31. Juli 2017, 04:44:58 CEST schrieb William L. Thomson Jr.:
> 
> How about no foundation. Not even a legal entity. No certifications
> from vendors, nor for employees. No one to hire for official support.
> There are so many things far beyond anything having to do with a stable
> tree or not.

I was *this* close to nominaing you for Trustee, until I realized you're not 
even a foundation member...

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

Re: [gentoo-dev] New package neomutt

[Floyd Anderson]

Hi Nicolas,

below just some remarks from me.

On Mo, 31 Jul 09:23:51 +0200
Nicolas Bock  wrote:

On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote:

Hi,

I would like to add neomutt to the tree. This new package is meant 
as an alternative and not a replacement of the existing mutt 
package.


+1 Very nice idea, I appreciate that.


From 63f5d569aec514d67645b1c2e891e51810bb7ab5 Mon Sep 17 00:00:00 2001
From: Nicolas Bock 
Date: Mon, 31 Jul 2017 09:06:07 +0200
Subject: [PATCH] mail-client/neomutt: New package mail-client/neomutt-20170714

Package-Manager: Portage-2.3.6, Repoman-2.3.1
---
mail-client/neomutt/Manifest|   1 +
mail-client/neomutt/metadata.xml|  24 +
mail-client/neomutt/neomutt-20170714.ebuild | 161 
3 files changed, 186 insertions(+)
create mode 100644 mail-client/neomutt/Manifest
create mode 100644 mail-client/neomutt/metadata.xml
create mode 100644 mail-client/neomutt/neomutt-20170714.ebuild

diff --git a/mail-client/neomutt/Manifest b/mail-client/neomutt/Manifest


[…]


diff --git a/mail-client/neomutt/metadata.xml b/mail-client/neomutt/metadata.xml


[…]


diff --git a/mail-client/neomutt/neomutt-20170714.ebuild 
b/mail-client/neomutt/neomutt-20170714.ebuild
new file mode 100644
index 000..9bcf72e7479
--- /dev/null
+++ b/mail-client/neomutt/neomutt-20170714.ebuild
@@ -0,0 +1,161 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$


Drop $Id$ per council decision in bug #611234.

[1] 


+
+EAPI=6
+
+inherit autotools eutils flag-o-matic
+
+DESCRIPTION="A small but very powerful text-based mail client"


Why not assimilate upstream (NeoMutt) motto? Mutt upstream has no objects on
this, see [2].

[2] 


+HOMEPAGE="https://www.neomutt.org/;
+SRC_URI="https://github.com/${PN}/${PN}/archive/${P}.tar.gz;
+
+LICENSE="GPL-2"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+IUSE="berkdb crypt debug doc gdbm gnutls gpg idn kerberos libressl mbox nls
+   notmuch qdbm sasl selinux slang smime ssl tokyocabinet vanilla"
+


[…]


+
+src_install() {
+   emake DESTDIR="${D}" install || die "install failed"
+   if use mbox; then
+   insinto /etc/neomutt
+   newins "${FILESDIR}"/Muttrc.mbox Muttrc
+   else
+   insinto /etc/neomutt
+   doins "${FILESDIR}"/Muttrc
+   fi
+
+   # A newer file is provided by app-misc/mime-types. So we link it.
+   rm "${ED}"/etc/${PN}/mime.types
+   dosym /etc/mime.types /etc/${PN}/mime.types
+
+   # A man-page is always handy, so fake one
+   if use !doc; then
+   emake -C doc DESTDIR="${D}" muttrc.man || die
+   # make the fake slightly better, bug #413405
+   sed -e 
's#@docdir@/manual.txt#http://www.mutt.org/doc/devel/manual.html#' \
+   -e 's#in @docdir@,#at http://www.mutt.org/,#' \
+   -e "s#@sysconfdir@#${EPREFIX}/etc/${PN}#" \
+   -e "s#@bindir@#${EPREFIX}/usr/bin#" \
+   doc/mutt.man > mutt.1
+   cp doc/muttrc.man muttrc.5
+   doman mutt.1 muttrc.5
+   else
+   # nuke manpages that should be provided by an MTA, bug #177605
+   rm "${ED}"/usr/share/man/man5/{mbox,mmdf}.5 \
+   || ewarn "failed to remove files, please file a bug"
+   fi

The *devel* manual is located here [3] and release manual here [4].

[3] 
[4] 


+
+   dodoc COPYRIGHT ChangeLog.md OPS* README*
+}
--
2.13.0


--
Nicolas Bock 


In the end it would be nice if Lua would also be integrated.

In the case you haven’t noticed that, have a look at [5]. But note the link [6]
for the faked manual page is dead if you consider to use this one. Also it
seems the documentation will be restructured in the future [7][8].

[5] 
[6] 
[7] 

[8] 


--
Regards,
floyd

Re: [gentoo-dev] New package neomutt

[Fabian Groffen]

On 31-07-2017 04:55:58 -0500, Matthew Thode wrote:
> On 17-07-31 09:11:19, Nicolas Bock wrote:
> > Hi,
> > 
> > I would like to add neomutt to the tree. This new package is meant 
> > as an alternative and not a replacement of the existing mutt 
> > package.
> > 
> > Thanks,
> > 
> > Nick
> > 
> > -- 
> > Nicolas Bock 
> 
> It was my understanding that neomutt was mainly mutt with a bunch of
> patches added on, from what I can see, those patches are already handled
> by use flags in the mutt package itself.
>
> https://www.neomutt.org/about.html describes itself as a large set of
> feature patches and not a fork as well.  Are there missing patches that
> need to be added to the mutt package?

These days NeoMutt really is a fork, with a complete code-re-indent,
function name changes, etc.[1]  They move fast, deviating from Mutt and
no longer submit patches to Mutt.  It remains to be seen where both
projects end up, IMO.  It is no longer feasible to add features from
NeoMutt to Mutt, and Mutt moves along its own path (with
features/improvements) as well.

For now it seems useful to me to have both mutt and neomutt around.  I
sent my detailed comments on the neomutt ebuild to Nicholas off-list
already.  The changes suggested should show even more how the two are
different.

Thanks,
Fabian

[1] 
http://mailman.neomutt.org/pipermail/neomutt-devel-neomutt.org/2017-April/000364.html

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature

Re: [gentoo-portage-dev] [PATCH] make.globals: Enable FEATURES=multilib-strict by default

[Michał Górny]

Dnia 31 lipca 2017 10:17:56 CEST, Zac Medico  napisał(a):
>On Wed, Jul 26, 2017 at 1:44 PM, Michał Górny 
>wrote:
>> On śro, 2017-07-26 at 11:29 -0700, Zac Medico wrote:
>>> You might think that, but I just checked our profiles and the only
>one
>>> that currently has it enabled is profiles/arch/sparc/make.defaults.
>In
>>> profiles/targets/developer/make.defaults there's a reference to this
>>> bug that's been open for 5 years now:
>>>
>>> https://bugs.gentoo.org/show_bug.cgi?id=424423
>>
>> To be honest, I started rewriting multilib-strict to be sane but lost
>> motivation pretty early. Feel free to take it up, it shouldn't be
>hard.
>> Just horribly boring.
>>
>> Basically, it should iterate over all ABIs, get libdirs for them
>> and look for libraries *directly* in those libdirs. Anything below
>first
>> level can be ignored as unclear with a good hit rate anyway.
>
>Assuming that MULTILIB_STRICT_DIRS contains a reasonable list of
>libdirs for the profile, can't we get that behavior by adding
>-maxdepth 1 to the find call inside
>bin/install-qa-check.d/80multilib-strict? If so, then why haven't we
>done this already?

Probably because nobody touched it. But yeah, killing the exempt first would be 
a reasonable first step.


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

Re: [gentoo-dev] New package neomutt

[Matthew Thode]

On 17-07-31 09:11:19, Nicolas Bock wrote:
> Hi,
> 
> I would like to add neomutt to the tree. This new package is meant 
> as an alternative and not a replacement of the existing mutt 
> package.
> 
> Thanks,
> 
> Nick
> 
> -- 
> Nicolas Bock 

It was my understanding that neomutt was mainly mutt with a bunch of
patches added on, from what I can see, those patches are already handled
by use flags in the mutt package itself.

https://www.neomutt.org/about.html describes itself as a large set of
feature patches and not a fork as well.  Are there missing patches that
need to be added to the mutt package?

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature

Re: [gentoo-dev] New package neomutt

[Patrice Clement]

Hi Nicolas

See my comments inline.

Monday 31 Jul 2017 09:23:51, Nicolas Bock wrote :
> On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote:
> >Hi,
> >
> >I would like to add neomutt to the tree. This new package is meant as 
> >an alternative and not a replacement of the existing mutt package.
> 
> I should have inlined the patch. Sorry.
> 
> 
> 
> From 63f5d569aec514d67645b1c2e891e51810bb7ab5 Mon Sep 17 00:00:00 2001
> From: Nicolas Bock 
> Date: Mon, 31 Jul 2017 09:06:07 +0200
> Subject: [PATCH] mail-client/neomutt: New package mail-client/neomutt-20170714
> 
> Package-Manager: Portage-2.3.6, Repoman-2.3.1
> ---
>  mail-client/neomutt/Manifest|   1 +
>  mail-client/neomutt/metadata.xml|  24 +
>  mail-client/neomutt/neomutt-20170714.ebuild | 161 
> 
>  3 files changed, 186 insertions(+)
>  create mode 100644 mail-client/neomutt/Manifest
>  create mode 100644 mail-client/neomutt/metadata.xml
>  create mode 100644 mail-client/neomutt/neomutt-20170714.ebuild
> 
> diff --git a/mail-client/neomutt/Manifest b/mail-client/neomutt/Manifest
> new file mode 100644
> index 000..2b38484e24d
> --- /dev/null
> +++ b/mail-client/neomutt/Manifest
> @@ -0,0 +1 @@
> +DIST neomutt-20170714.tar.gz 2509160 SHA256 
> 40d48920f95ca49ab96eb109b658f5cf6e1c222320c58bdd03769c1355d7a383 SHA512 
> eb31d2f23b7211904cd66ba293c008f953778b37f13fd09d4db571d013f1c8e6449fccd827872f3ad0a2c8e62555f92b3f9591a1f0f4ac37ab362a4681abaaa0
>  WHIRLPOOL 
> 455495501a2ab1989d5f3bfa75aa2370896956cdfd7d2e852e225c96aa23a1abdaf2dbb9d886d1d96486d19b2b38c225e8263f268ebafcef8cbd0024885189f3
> diff --git a/mail-client/neomutt/metadata.xml 
> b/mail-client/neomutt/metadata.xml
> new file mode 100644
> index 000..081f253b3a1
> --- /dev/null
> +++ b/mail-client/neomutt/metadata.xml
> @@ -0,0 +1,24 @@
> +
> +http://www.gentoo.org/dtd/metadata.dtd;>
> +
> + 
> + nicolasb...@gentoo.org
> + Nicolas Bock
> + 
> + 
> + net-m...@gentoo.org
> + Net-Mail
> + 
> + 
> + Enable support for 
> app-crypt/gpgme
> + Enable support for 
> net-mail/notmuch
> + Enable support for S/MIME
> + Enable dev-db/tokyocabinet
> + database backend for header caching
> + 
> + 
> + 
> + 
> + neomutt/neomutt
> + 
> +
> diff --git a/mail-client/neomutt/neomutt-20170714.ebuild 
> b/mail-client/neomutt/neomutt-20170714.ebuild
> new file mode 100644
> index 000..9bcf72e7479
> --- /dev/null
> +++ b/mail-client/neomutt/neomutt-20170714.ebuild
> @@ -0,0 +1,161 @@
> +# Copyright 1999-2017 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Id$
> +
> +EAPI=6
> +
> +inherit autotools eutils flag-o-matic
> +
> +DESCRIPTION="A small but very powerful text-based mail client"
> +HOMEPAGE="https://www.neomutt.org/;
> +SRC_URI="https://github.com/${PN}/${PN}/archive/${P}.tar.gz;
> +
> +LICENSE="GPL-2"
> +SLOT="0"
> +KEYWORDS="~amd64 ~x86"
> +IUSE="berkdb crypt debug doc gdbm gnutls gpg idn kerberos libressl mbox nls
> + notmuch qdbm sasl selinux slang smime ssl tokyocabinet vanilla"
> +
> +CDEPEND="
> + !mail-client/mutt
> + app-misc/mime-types
> + nls? ( virtual/libintl )
> + tokyocabinet?  ( dev-db/tokyocabinet )
> + !tokyocabinet? (
> + qdbm?  ( dev-db/qdbm )
> + !qdbm? (
> + gdbm?  ( sys-libs/gdbm )
> + !gdbm? ( berkdb? ( >=sys-libs/db-4:= ) )
> + )
> + )
> + gnutls?  ( >=net-libs/gnutls-1.0.17 )
> + !gnutls? (
> + ssl? (
> + !libressl? ( >=dev-libs/openssl-0.9.6:0 )
> + libressl? ( dev-libs/libressl )
> + )
> + )
> + sasl?( >=dev-libs/cyrus-sasl-2 )
> + kerberos? ( virtual/krb5 )
> + idn? ( net-dns/libidn )
> + gpg? ( >=app-crypt/gpgme-0.9.0 )
> + smime?   (
> + !libressl? ( >=dev-libs/openssl-0.9.6:0 )
> + libressl? ( dev-libs/libressl )
> + )
> + notmuch? ( net-mail/notmuch )
> + slang? ( sys-libs/slang )
> + !slang? ( >=sys-libs/ncurses-5.2:0 )
> +"
> +DEPEND="${CDEPEND}
> + net-mail/mailbase
> + doc? (
> + dev-libs/libxml2
> + dev-libs/libxslt
> + app-text/docbook-xsl-stylesheets
> + || ( www-client/lynx www-client/w3m www-client/elinks )
> + )"
> +RDEPEND="${CDEPEND}
> + selinux? ( sec-policy/selinux-mutt )
> +"
> +
> +S="${WORKDIR}/${PN}-${P}"
> +
> +src_prepare() {
> + eapply_user
> + eautoreconf
> +}
> +
> +src_configure() {
> + local myconf=(
> + "$(use_enable crypt pgp)"
> + "$(use_enable debug)"
> + "$(use_enable doc)"
> + "$(use_enable gpg gpgme)"
> + "$(use_enable nls)"
> + 

Re: [gentoo-portage-dev] [PATCH] make.globals: Enable FEATURES=multilib-strict by default

[Zac Medico]

On Wed, Jul 26, 2017 at 1:44 PM, Michał Górny  wrote:
> On śro, 2017-07-26 at 11:29 -0700, Zac Medico wrote:
>> You might think that, but I just checked our profiles and the only one
>> that currently has it enabled is profiles/arch/sparc/make.defaults. In
>> profiles/targets/developer/make.defaults there's a reference to this
>> bug that's been open for 5 years now:
>>
>> https://bugs.gentoo.org/show_bug.cgi?id=424423
>
> To be honest, I started rewriting multilib-strict to be sane but lost
> motivation pretty early. Feel free to take it up, it shouldn't be hard.
> Just horribly boring.
>
> Basically, it should iterate over all ABIs, get libdirs for them
> and look for libraries *directly* in those libdirs. Anything below first
> level can be ignored as unclear with a good hit rate anyway.

Assuming that MULTILIB_STRICT_DIRS contains a reasonable list of
libdirs for the profile, can't we get that behavior by adding
-maxdepth 1 to the find call inside
bin/install-qa-check.d/80multilib-strict? If so, then why haven't we
done this already?
-- 
Thanks,
Zac

Re: [gentoo-dev] New package neomutt

[Nicolas Bock]

On Mon, Jul 31, 2017 at 09:44:55AM +0200, Michał Górny wrote:

Dnia 31 lipca 2017 09:11:19 CEST, Nicolas Bock  
napisał(a):

Hi,

I would like to add neomutt to the tree. This new package is meant
as an alternative and not a replacement of the existing mutt
package.


Aren't you looking for gentoo-proxy-maint ml?


No, I was looking for comments on the package. I will maintain it 
once I add it to the tree. I should have stated that more clearly.


Best,

Nick

--
Nicolas Bock 


signature.asc
Description: PGP signature

Re: [gentoo-dev] New package neomutt

[Michał Górny]

Dnia 31 lipca 2017 09:11:19 CEST, Nicolas Bock  
napisał(a):
>Hi,
>
>I would like to add neomutt to the tree. This new package is meant 
>as an alternative and not a replacement of the existing mutt 
>package.

Aren't you looking for gentoo-proxy-maint ml? 

>
>Thanks,
>
>Nick


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

Re: [gentoo-dev] New package neomutt

[Nicolas Bock]

On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote:

Hi,

I would like to add neomutt to the tree. This new package is meant as 
an alternative and not a replacement of the existing mutt package.


I should have inlined the patch. Sorry.



From 63f5d569aec514d67645b1c2e891e51810bb7ab5 Mon Sep 17 00:00:00 2001
From: Nicolas Bock 
Date: Mon, 31 Jul 2017 09:06:07 +0200
Subject: [PATCH] mail-client/neomutt: New package mail-client/neomutt-20170714

Package-Manager: Portage-2.3.6, Repoman-2.3.1
---
mail-client/neomutt/Manifest|   1 +
mail-client/neomutt/metadata.xml|  24 +
mail-client/neomutt/neomutt-20170714.ebuild | 161 
3 files changed, 186 insertions(+)
create mode 100644 mail-client/neomutt/Manifest
create mode 100644 mail-client/neomutt/metadata.xml
create mode 100644 mail-client/neomutt/neomutt-20170714.ebuild

diff --git a/mail-client/neomutt/Manifest b/mail-client/neomutt/Manifest
new file mode 100644
index 000..2b38484e24d
--- /dev/null
+++ b/mail-client/neomutt/Manifest
@@ -0,0 +1 @@
+DIST neomutt-20170714.tar.gz 2509160 SHA256 
40d48920f95ca49ab96eb109b658f5cf6e1c222320c58bdd03769c1355d7a383 SHA512 
eb31d2f23b7211904cd66ba293c008f953778b37f13fd09d4db571d013f1c8e6449fccd827872f3ad0a2c8e62555f92b3f9591a1f0f4ac37ab362a4681abaaa0
 WHIRLPOOL 
455495501a2ab1989d5f3bfa75aa2370896956cdfd7d2e852e225c96aa23a1abdaf2dbb9d886d1d96486d19b2b38c225e8263f268ebafcef8cbd0024885189f3
diff --git a/mail-client/neomutt/metadata.xml b/mail-client/neomutt/metadata.xml
new file mode 100644
index 000..081f253b3a1
--- /dev/null
+++ b/mail-client/neomutt/metadata.xml
@@ -0,0 +1,24 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   nicolasb...@gentoo.org
+   Nicolas Bock
+   
+   
+   net-m...@gentoo.org
+   Net-Mail
+   
+   
+   Enable support for 
app-crypt/gpgme
+   Enable support for 
net-mail/notmuch
+   Enable support for S/MIME
+   Enable dev-db/tokyocabinet
+   database backend for header caching
+   
+   
+   
+   
+   neomutt/neomutt
+   
+
diff --git a/mail-client/neomutt/neomutt-20170714.ebuild 
b/mail-client/neomutt/neomutt-20170714.ebuild
new file mode 100644
index 000..9bcf72e7479
--- /dev/null
+++ b/mail-client/neomutt/neomutt-20170714.ebuild
@@ -0,0 +1,161 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$
+
+EAPI=6
+
+inherit autotools eutils flag-o-matic
+
+DESCRIPTION="A small but very powerful text-based mail client"
+HOMEPAGE="https://www.neomutt.org/;
+SRC_URI="https://github.com/${PN}/${PN}/archive/${P}.tar.gz;
+
+LICENSE="GPL-2"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+IUSE="berkdb crypt debug doc gdbm gnutls gpg idn kerberos libressl mbox nls
+   notmuch qdbm sasl selinux slang smime ssl tokyocabinet vanilla"
+
+CDEPEND="
+   !mail-client/mutt
+   app-misc/mime-types
+   nls? ( virtual/libintl )
+   tokyocabinet?  ( dev-db/tokyocabinet )
+   !tokyocabinet? (
+   qdbm?  ( dev-db/qdbm )
+   !qdbm? (
+   gdbm?  ( sys-libs/gdbm )
+   !gdbm? ( berkdb? ( >=sys-libs/db-4:= ) )
+   )
+   )
+   gnutls?  ( >=net-libs/gnutls-1.0.17 )
+   !gnutls? (
+   ssl? (
+   !libressl? ( >=dev-libs/openssl-0.9.6:0 )
+   libressl? ( dev-libs/libressl )
+   )
+   )
+   sasl?( >=dev-libs/cyrus-sasl-2 )
+   kerberos? ( virtual/krb5 )
+   idn? ( net-dns/libidn )
+   gpg? ( >=app-crypt/gpgme-0.9.0 )
+   smime?   (
+   !libressl? ( >=dev-libs/openssl-0.9.6:0 )
+   libressl? ( dev-libs/libressl )
+   )
+   notmuch? ( net-mail/notmuch )
+   slang? ( sys-libs/slang )
+   !slang? ( >=sys-libs/ncurses-5.2:0 )
+"
+DEPEND="${CDEPEND}
+   net-mail/mailbase
+   doc? (
+   dev-libs/libxml2
+   dev-libs/libxslt
+   app-text/docbook-xsl-stylesheets
+   || ( www-client/lynx www-client/w3m www-client/elinks )
+   )"
+RDEPEND="${CDEPEND}
+   selinux? ( sec-policy/selinux-mutt )
+"
+
+S="${WORKDIR}/${PN}-${P}"
+
+src_prepare() {
+   eapply_user
+   eautoreconf
+}
+
+src_configure() {
+   local myconf=(
+   "$(use_enable crypt pgp)"
+   "$(use_enable debug)"
+   "$(use_enable doc)"
+   "$(use_enable gpg gpgme)"
+   "$(use_enable nls)"
+   "$(use_enable smime)"
+   "$(use_enable notmuch)"
+   "$(use_with idn)"
+   "$(use_with kerberos gss)"
+   "--with-$(use slang && echo slang || echo 
curses)=${EPREFIX}/usr"
+   

[gentoo-portage-dev] [PATCH] emerge --getbinpkg: https support for If-Modified-Since

[Zac Medico]

When https certificate and hostname verification is enabled for
stdlib http clients (PEP 476), use python for If-Modified-Since
header support. When python lacks PEP 476 support, continue to
use FETCHCOMMAND for https certificate and hostname verification
(see security bug 469888).

X-Gentoo-bug: 625246
X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=625246
---
 pym/portage/dbapi/bintree.py | 10 ++
 pym/portage/util/_urlopen.py | 12 
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/pym/portage/dbapi/bintree.py b/pym/portage/dbapi/bintree.py
index c833968c2..95bd5dbf8 100644
--- a/pym/portage/dbapi/bintree.py
+++ b/pym/portage/dbapi/bintree.py
@@ -18,7 +18,7 @@ portage.proxy.lazyimport.lazyimport(globals(),
'portage.util:atomic_ofstream,ensure_dirs,normalize_path,' + \
'writemsg,writemsg_stdout',
'portage.util.path:first_existing',
-   'portage.util._urlopen:urlopen@_urlopen',
+   'portage.util._urlopen:urlopen@_urlopen,have_pep_476@_have_pep_476',
'portage.versions:best,catpkgsplit,catsplit,_pkg_str',
 )
 
@@ -851,9 +851,9 @@ class binarytree(object):
download_timestamp + ttl > 
time.time():
raise 
UseCachedCopyOfRemoteIndex()
 
-   # Don't use urlopen for https, since it doesn't 
support
-   # certificate/hostname verification (bug 
#469888).
-   if parsed_url.scheme not in ('https',):
+   # Don't use urlopen for https, unless
+   # PEP 476 is supported (bug #469888).
+   if parsed_url.scheme not in ('https',) or 
_have_pep_476():
try:
f = _urlopen(url, 
if_modified_since=local_timestamp)
if hasattr(f, 'headers') and 
f.headers.get('timestamp', ''):
@@ -965,6 +965,8 @@ class binarytree(object):
"\n")
rmt_idx = pkgindex
except EnvironmentError as e:
+   # This includes URLError which is raised for SSL
+   # certificate errors when PEP 476 is supported.
writemsg(_("\n\n!!! Error fetching binhost 
package" \
" info from '%s'\n") % 
_hide_url_passwd(base_url))
# With Python 2, the EnvironmentError message 
may
diff --git a/pym/portage/util/_urlopen.py b/pym/portage/util/_urlopen.py
index 4cfe183b1..fc9db74a0 100644
--- a/pym/portage/util/_urlopen.py
+++ b/pym/portage/util/_urlopen.py
@@ -26,6 +26,18 @@ if sys.hexversion >= 0x300:
 #  and the file-'mtime'
 TIMESTAMP_TOLERANCE = 5
 
+
+def have_pep_476():
+   """
+   Test whether ssl certificate verification is enabled by default for
+   stdlib http clients (PEP 476).
+
+   @returns: bool, True if ssl certificate verification is enabled by
+   default
+   """
+   return hasattr(__import__('ssl'), '_create_unverified_context')
+
+
 def urlopen(url, if_modified_since=None):
parse_result = urllib_parse.urlparse(url)
if parse_result.scheme not in ("http", "https"):
-- 
2.13.0

[gentoo-dev] New package neomutt

[Nicolas Bock]

Hi,

I would like to add neomutt to the tree. This new package is meant 
as an alternative and not a replacement of the existing mutt 
package.


Thanks,

Nick

--
Nicolas Bock 
From 63f5d569aec514d67645b1c2e891e51810bb7ab5 Mon Sep 17 00:00:00 2001
From: Nicolas Bock 
Date: Mon, 31 Jul 2017 09:06:07 +0200
Subject: [PATCH] mail-client/neomutt: New package mail-client/neomutt-20170714

Package-Manager: Portage-2.3.6, Repoman-2.3.1
---
 mail-client/neomutt/Manifest|   1 +
 mail-client/neomutt/metadata.xml|  24 +
 mail-client/neomutt/neomutt-20170714.ebuild | 161 
 3 files changed, 186 insertions(+)
 create mode 100644 mail-client/neomutt/Manifest
 create mode 100644 mail-client/neomutt/metadata.xml
 create mode 100644 mail-client/neomutt/neomutt-20170714.ebuild

diff --git a/mail-client/neomutt/Manifest b/mail-client/neomutt/Manifest
new file mode 100644
index 000..2b38484e24d
--- /dev/null
+++ b/mail-client/neomutt/Manifest
@@ -0,0 +1 @@
+DIST neomutt-20170714.tar.gz 2509160 SHA256 40d48920f95ca49ab96eb109b658f5cf6e1c222320c58bdd03769c1355d7a383 SHA512 eb31d2f23b7211904cd66ba293c008f953778b37f13fd09d4db571d013f1c8e6449fccd827872f3ad0a2c8e62555f92b3f9591a1f0f4ac37ab362a4681abaaa0 WHIRLPOOL 455495501a2ab1989d5f3bfa75aa2370896956cdfd7d2e852e225c96aa23a1abdaf2dbb9d886d1d96486d19b2b38c225e8263f268ebafcef8cbd0024885189f3
diff --git a/mail-client/neomutt/metadata.xml b/mail-client/neomutt/metadata.xml
new file mode 100644
index 000..081f253b3a1
--- /dev/null
+++ b/mail-client/neomutt/metadata.xml
@@ -0,0 +1,24 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+	
+		nicolasb...@gentoo.org
+		Nicolas Bock
+	
+	
+		net-m...@gentoo.org
+		Net-Mail
+	
+	
+		Enable support for app-crypt/gpgme
+		Enable support for net-mail/notmuch
+		Enable support for S/MIME
+		Enable dev-db/tokyocabinet
+			database backend for header caching
+	
+	
+	
+	
+		neomutt/neomutt
+	
+
diff --git a/mail-client/neomutt/neomutt-20170714.ebuild b/mail-client/neomutt/neomutt-20170714.ebuild
new file mode 100644
index 000..9bcf72e7479
--- /dev/null
+++ b/mail-client/neomutt/neomutt-20170714.ebuild
@@ -0,0 +1,161 @@
+# Copyright 1999-2017 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Id$
+
+EAPI=6
+
+inherit autotools eutils flag-o-matic
+
+DESCRIPTION="A small but very powerful text-based mail client"
+HOMEPAGE="https://www.neomutt.org/;
+SRC_URI="https://github.com/${PN}/${PN}/archive/${P}.tar.gz;
+
+LICENSE="GPL-2"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+IUSE="berkdb crypt debug doc gdbm gnutls gpg idn kerberos libressl mbox nls
+	notmuch qdbm sasl selinux slang smime ssl tokyocabinet vanilla"
+
+CDEPEND="
+	!mail-client/mutt
+	app-misc/mime-types
+	nls? ( virtual/libintl )
+	tokyocabinet?  ( dev-db/tokyocabinet )
+	!tokyocabinet? (
+		qdbm?  ( dev-db/qdbm )
+		!qdbm? (
+			gdbm?  ( sys-libs/gdbm )
+			!gdbm? ( berkdb? ( >=sys-libs/db-4:= ) )
+		)
+	)
+	gnutls?  ( >=net-libs/gnutls-1.0.17 )
+	!gnutls? (
+		ssl? (
+			!libressl? ( >=dev-libs/openssl-0.9.6:0 )
+			libressl? ( dev-libs/libressl )
+		)
+	)
+	sasl?( >=dev-libs/cyrus-sasl-2 )
+	kerberos? ( virtual/krb5 )
+	idn? ( net-dns/libidn )
+	gpg? ( >=app-crypt/gpgme-0.9.0 )
+	smime?   (
+		!libressl? ( >=dev-libs/openssl-0.9.6:0 )
+		libressl? ( dev-libs/libressl )
+	)
+	notmuch? ( net-mail/notmuch )
+	slang? ( sys-libs/slang )
+	!slang? ( >=sys-libs/ncurses-5.2:0 )
+"
+DEPEND="${CDEPEND}
+	net-mail/mailbase
+	doc? (
+		dev-libs/libxml2
+		dev-libs/libxslt
+		app-text/docbook-xsl-stylesheets
+		|| ( www-client/lynx www-client/w3m www-client/elinks )
+	)"
+RDEPEND="${CDEPEND}
+	selinux? ( sec-policy/selinux-mutt )
+"
+
+S="${WORKDIR}/${PN}-${P}"
+
+src_prepare() {
+	eapply_user
+	eautoreconf
+}
+
+src_configure() {
+	local myconf=(
+		"$(use_enable crypt pgp)"
+		"$(use_enable debug)"
+		"$(use_enable doc)"
+		"$(use_enable gpg gpgme)"
+		"$(use_enable nls)"
+		"$(use_enable smime)"
+		"$(use_enable notmuch)"
+		"$(use_with idn)"
+		"$(use_with kerberos gss)"
+		"--with-$(use slang && echo slang || echo curses)=${EPREFIX}/usr"
+		"--sysconfdir=${EPREFIX}/etc/${PN}"
+		"--with-docdir=${EPREFIX}/usr/share/doc/${PN}-${PVR}"
+	)
+
+	if [[ ${CHOST} == *-solaris* ]] ; then
+		# arrows in index view do not show when using wchar_t
+		myconf+=( "--without-wc-funcs" )
+	fi
+
+	# mutt prioritizes gdbm over bdb, so we will too.
+	# hcache feature requires at least one database is in USE.
+	local hcaches=(
+		"tokyocabinet"
+		"qdbm"
+		"gdbm"
+		"berkdb:bdb"
+	)
+	local ucache hcache lcache
+	for hcache in "${hcaches[@]}" ; do
+		if use ${hcache%%:*} ; then
+			ucache=${hcache}
+			break
+		fi
+	done
+	for hcache in "${hcaches[@]}" ; do
+		[[ ${hcache} == ${ucache} ]] \
+			&& myconf+=( "--with-${hcache#*:}" ) \
+			|| myconf+=( "--without-${hcache#*:}" )
+	done
+
+	# there's no need for gnutls, ssl or sasl without socket 

Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[R0b0t1]

It seems like there has been a lot of discussion here that indicates
people are happy with the way it is. There seems to be differences in
how packages are updated based on their purpose - desktop packages
move very fast, a lot of server infrastructure moves more slowly. It
seems like the "best" solution is already in place for the different
usecases.

If you hadn't noticed this, you may want to go look. I'm not sure if
it's more due to choices made upstream or choices the maintainers
make.


On Sat, Jul 29, 2017 at 1:08 PM, Christopher Head  wrote:
> I’m a stable user when I can be. I use Gentoo for the configurability,
> not for instant access to the newest versions of things.
>

It seems to be understood in this discussion why some people use ~arch
exclusively, but I would like to explain that it is a pattern I have
seen very well myself; typically it's possible to solve bugs by
keywording in the unstable package and being done with it. When
problems related to unstable keywording arise it's usually because a
system isn't completely unstable, which despite the name is very
stable on Gentoo.

It needs to be pointed out that all software in Portage is very new
compared to other distributions. Stable and unstable packages work
well together because they're closer in time to each other than other
distributions respective categories. In fact, stable packages are *so
new* compared to other distributions I think a more constructive
question to ask is whether or not Gentoo should start retaining older
packages for better interoperability with projects whose developers
use non-Gentoo distributions.[1]

On a distribution like Ubuntu or Debian a developer working for a
software firm might wish to use, say, the very latest version of Ruby
and Rails. To do this they might pull down the source release and then
try to compile it themselves. This used to be the same as opening a
portal to dependency hell,[2] but it's gotten better, and we assume
the developer gets it installed to their home directory. They spin up
a website with the new features and are done with it. The rest of
their stack is whatever was in the package manager and might be,
comparatively, very old. If they do this for more pieces of software -
like if it is done on a developer's workstation, and not a single
purpose server - eventually packages will start conflicting and things
like containers and single purpose virtual machines start making
sense.

On Gentoo, the newest software is just there, and it's updated
frequently enough that you never have to jump through breaking
changes. Most people I have met that use Gentoo use it because they
need lots of new software, or need to customize things in ways that
are hard to do on other distributions. These people tend to realize
that even if they run stable, those stable packages would probably be
considered unstable on another distribution.

R0b0t1.


[1] Personally I don't think that would be a useful thing to do, I
just install it in an Ubuntu or Debian VM if I want to play with that
project. A lot of issues that exist in this regard are hardcoded paths
and other things that come from the design of Ubuntu and Debian.

[2] Ubuntu seems to keep their packages more up to date than they used
to, because I remember having to compile 2-3 intermediate packages to
get something to the newest version a couple of times. Debian still
typically has very old software in their package repository.