Re: [gentoo-dev] RFC: dropping support for uclibc-ng

2021-01-05 Thread Anthony G. Basile
On 1/5/21 8:43 AM, Jaco Kroon wrote:
> Hi Thomas,
> 
> On 2021/01/05 13:08, Thomas Mueller wrote:
>>> I'd like feedback from people about the possibility of dropping support
>>> for uclibc-ng.  If you are unfamiliar, its the successor to uclibc as a
>>> C Standard Library for embedded systems, ie a replacement for glibc
>>> bloat.  However, it is inferior to musl which serves the same purpose
>>> and which has now well supported in Gentoo.
>>> I know people want musl support, but does anyone even care about
>>> uclibc-ng?  If not, I can work towards deprecating it and putting what
>>> little time I have towards musl.
>>> Anthony G. Basile, Ph.D.
>>> Gentoo Linux Developer [Hardened]
>> Are you the only Gentoo developer working on musl and uclibc-ng?

I'm the only one working on uclibc-ng.  There are some people helping
with musl, especially the overlay.

>>
>> One thing I might try with a Gentoo uclibc-ng system is convert to musl or 
>> glibc using crossdev.
>>
>> From what I see on the internet, there is more support for musl than 
>> uclibc-ng, and more people working with musl than with uclibc-ng.

It does seem that musl is winning the embedded libc race.

>>
>> There is a musl-cross-make cross-toolchain that can be built from non-musl 
>> or even non-Linux.
>>
>> https://github.com/richfelker/musl-cross-make
> 
> I've used crossdev in the past.  It was a nasty experience, but I
> believe crossdev in Gentoo is getting better and better, and it supports
> many more targets.

Yes it is, which is why I'm preparing pre-build stage3's on several
arches so you don't have to x-compile.  I've done the nasty part for you.

> 
>> From what I have seen, musl looks more promising than uclibc-ng, and more 
>> user- and developer-friendly.
>>
>> Unless somebody wants to take over uclibc-ng for Gentoo, I say better for 
>> you, with your limited time, to drop uclibc-ng in favor of musl.


Correct, if I had the time, I'd continue to support both.  But my time
is limited, so I need to concentrate.  I'm just looking for anyone to
scream if I'm destroying their world by dropping uclibc-ng.  If no one
does, then I'll begin the process of removing it from the tree.

> 
> Not doing embedded work at the moment, but just out of hand as of right
> now if I had to make a choice I'd definitely look at MUSL as first
> choice.  So +1 for that suggestion.
> 
> Kind Regards,
> Jaco
> 

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] RFC: dropping support for uclibc-ng

2021-01-04 Thread Anthony G. Basile
Hi everyone,

I'd like feedback from people about the possibility of dropping support
for uclibc-ng.  If you are unfamiliar, its the successor to uclibc as a
C Standard Library for embedded systems, ie a replacement for glibc
bloat.  However, it is inferior to musl which serves the same purpose
and which has now well supported in Gentoo.

I know people want musl support, but does anyone even care about
uclibc-ng?  If not, I can work towards deprecating it and putting what
little time I have towards musl.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-30 Thread Anthony G. Basile
On 12/29/20 6:06 PM, David Seifert wrote:
> 
> If you want to provide an alternative, you have to subsume the API, not
> make it superficially compatible, only to find out that the you need to
> mask out a ton of stuff with macros. 

Agreed.  If libressl hadn't failed on this point, we would not be having
this conversation.  They promised it would be API compatible and it
started that way, but not anymore.  This became annoying even to me with
my other packages like stunnel, where with every bump I had to create a
new patch with macros based on versions.  This is not something we want
to saddle the rest of Gentoo with.  Nor do we want to burden upstream
teams to have to follow libressl's insanity.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-30 Thread Anthony G. Basile
On 12/29/20 5:41 PM, Peter Stuge wrote:
> Michał Górny wrote:
>>> I would be happier if some other developers were able and willing to
>>> participate actively in the LibreSSL project.
>>
>> But why would they do that?  What I'm really missing in all the replies
>> is a single reason why LibreSSL would be better for anyone.
> 
> Maybe because it is so well-known that monoculture is harmful per se,
> which is why the commitment to choice in Gentoo is very valuable.
> 
> Further, LibreSSL comes out of the OpenBSD project, which has a good
> reputation on code quality.
> 

I am sympathetic to not degrading into a monoculture.  If I would
characterize my contribution to Gentoo over the years it would be
"alt-everything".  The reason being that competition between
alternatives is a good thing and time will tell which way is best.

But <- here's the "but"

At some point a particular path may have to be dropped because it just
doesn't provide any clear advantages.  There was nothing wrong with
adding libressl as an alternative in 2014 since it had promise.  And
now, years later, I see nothing wrong with removing it.  It hasn't
delivered.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-28 Thread Anthony G. Basile
On 12/28/20 3:56 AM, Michał Górny wrote:
> Hello, developers and Gentoo LibreSSL team.
> 
> TL;DR: is there really a point in continuing the never-ending always-
> regressing struggle towards supporting LibreSSL in Gentoo?
> 
> 
> I would like to discuss the possibility of discontinuing LibreSSL
> support in Gentoo in favor of sticking with OpenSSL.  Similarly how we
> ended up deciding that fighting for libav was unpractical and the vast
> majority of users are using ffmpeg (because they didn't really have
> a choice), today it seems that LibreSSL is suffering the same fate.
> 
> LibreSSL users, does LibreSSL today have any benefit over OpenSSL?
> To be honest, I don't think so.  In 2014, it might have represented
> a new quality.  But today, OpenSSL is alive and kicking, and LibreSSL
> finds it hard to keep up.
> 
> The vast majority of software is not tested against LibreSSL.  While
> patches are usually trivial and we have people that submit them,
> I find many of them short-sighted.  Just look at [1].  Sure, it fixes
> the build today but it disabled the feature for all foreseeable future.
> How likely is it that somebody will submit another patch reenabling it
> with a future LibreSSL version?
> 
> While normally I strongly prefer submitting such patches upstream, that
> makes things even worse.  I mean, I wouldn't be surprised if there were
> dozens of packages today that are crippled with LibreSSL just because
> somebody fixed the build in the past and never revisited the problem.
> 
> This somewhat resembles running in circles.  Packages kept being broken
> with LibreSSL because rarely anyone is using it.  And rarely anyone is
> using LibreSSL because the apparent benefit (or lack thereof) does not
> justify the constant breakage (plus invisible regressions).
> 
> All this considered, provided that nobody is able to find a good reason
> to use LibreSSL, I would like to propose that we stop patching
> packages, discontinue support for it and last rite it.
> 
> 
> [1] https://761981.bugs.gentoo.org/attachment.cgi?id=679892
> 

I'm the current project lead.  I inherited it back in the day from
hasufel.  It originally had promise of being better than openssl with
100% compatibility.  I hung on because I trusted that team but it has
become more of a hassle than its worth.  I am in favor of removing it.
If we decide to do so, how should we proceed?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] musl doesn't provide execinfo.h

2020-03-27 Thread Anthony G. Basile
On 3/27/20 3:17 PM, Alexis Ballier wrote:
> On Fri, 2020-03-27 at 08:03 -0400, Anthony G. Basile wrote:
>> On 3/26/20 9:25 PM, Joshua Kinard wrote:
>>> On 3/23/2020 04:21, Jaco Kroon wrote:
>>>> Hi,
>>>>
>>>> https://bugs.gentoo.org/713668 relates.
>>>>
>>>>  * Searching for /usr/include/execinfo.h ...
>>>> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h)
>>>>
>>>> As I see I can either add an explicit depend on glibc which I'd
>>>> prefer
>>>> not to.  Or someone from the musl team could possibly assist on
>>>> how to
>>>> get the backtrace() set of calls on musl please?
>>>>
>>>> Alternatively I need to add a test and simply path debug.c to
>>>> only
>>>> provide stub function for print_backtrace(FILE *fp) that just
>>>> does
>>>> fprintf(fp, "No backtrace() available to print a backtrace.\n");
>>>>
>>>> Suggestions?
>>>>
>>>> Kind Regards,
>>>> Jaco
>>>
>>> Some quick searching on google, it looks like the cleanest fix for
>>> that bug
>>> is dahdi-tools needs to be patched to only include execinfo.h or
>>> only use
>>> backtrace() on glibc-based systems, and that patch then sent to the
>>> dahdi-tools upstream developers for inclusion in a future
>>> release.  That
>>> way, we're not dragging that patch around forever in the tree or in
>>> the musl
>>> overlay.
>>>
>>> It also doesn't look like musl itself will ever implement
>>> execinfo.h or
>>> backtrace(), per this message in 2015 from the lead musl developer:
>>> https://www.openwall.com/lists/musl/2015/04/09/3
>>>
>>
>> Correct.  I've been adding -standalone packages to provide for
>> features
>> like fts, obstack, argp,etc. which are bundled into glibc but not
>> really
>> under the POSIX standard.
>>
>> So either we patch packages to turn off backtrace() or we add
>> libunwind-standalone to the tree.
>>
> 
> 
> BTW, we had libexecinfo for fbsd, which seems also present in alpine:
> https://pkgs.alpinelinux.org/package/edge/main/x86/libexecinfo
> 
> 


Had?  Is it in the tree now or should I look into adding it?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] musl doesn't provide execinfo.h

2020-03-27 Thread Anthony G. Basile
On 3/26/20 9:25 PM, Joshua Kinard wrote:
> On 3/23/2020 04:21, Jaco Kroon wrote:
>> Hi,
>>
>> https://bugs.gentoo.org/713668 relates.
>>
>>  * Searching for /usr/include/execinfo.h ...
>> sys-libs/glibc-2.29-r7 (/usr/include/execinfo.h)
>>
>> As I see I can either add an explicit depend on glibc which I'd prefer
>> not to.  Or someone from the musl team could possibly assist on how to
>> get the backtrace() set of calls on musl please?
>>
>> Alternatively I need to add a test and simply path debug.c to only
>> provide stub function for print_backtrace(FILE *fp) that just does
>> fprintf(fp, "No backtrace() available to print a backtrace.\n");
>>
>> Suggestions?
>>
>> Kind Regards,
>> Jaco
> 
> Some quick searching on google, it looks like the cleanest fix for that bug
> is dahdi-tools needs to be patched to only include execinfo.h or only use
> backtrace() on glibc-based systems, and that patch then sent to the
> dahdi-tools upstream developers for inclusion in a future release.  That
> way, we're not dragging that patch around forever in the tree or in the musl
> overlay.
> 
> It also doesn't look like musl itself will ever implement execinfo.h or
> backtrace(), per this message in 2015 from the lead musl developer:
> https://www.openwall.com/lists/musl/2015/04/09/3
> 

Correct.  I've been adding -standalone packages to provide for features
like fts, obstack, argp,etc. which are bundled into glibc but not really
under the POSIX standard.

So either we patch packages to turn off backtrace() or we add
libunwind-standalone to the tree.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] RFC: request uid/gid for net-misc/stunnel

2019-12-08 Thread Anthony G. Basile
On 12/8/19 2:59 PM, Ulrich Mueller wrote:
>>>>>> On Sun, 08 Dec 2019, Anthony G Basile wrote:
> 
>> Okay, I'm requesting UID/GID = 492/492.  I'm committing in a sec.
> 
> That's the ID used by arch for oprofile, so it's a bad choice.
> 
> Ulrich
> 

I give up!  How am I supposed to know what to choose if it isn't
requested in the uid-git.txt file?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] RFC: request uid/gid for net-misc/stunnel

2019-12-08 Thread Anthony G. Basile
On 12/8/19 2:53 PM, Michał Górny wrote:
> On Sun, 2019-12-08 at 14:48 -0500, Anthony G. Basile wrote:
>> Hi everyone,
>>
>> I know that is my third time requesting a uid/gid for stunnel, but it
>> seems that my previous request was already taken but not added to the
>> uid-gid.txt file, so I didn't know about the collision.
>>
>> Speaking with mgorny on #gentoo-dev, he suggested that we start simply
>> making a request, and he'll assign the highest free value(s) at the time.
>>
>> So @mgorny, can i please have a UID and GID pair for stunnel.
>>
> 
> You misunderstood me.
> 
> I meant that if you don't care about the specific number, you just make
> a request saying you'll take the highest free UID/GID pair at the time
> (that said, please try to use matching UID/GID for convenience's sake). 
> That is, unless you want to take a specific lower number.
> 
> Since there's no point in waiting again, just look at uid-gid.txt, find
> highest free UID/GID, verify that nobody else used or requested it. 
> Then commit it, and make sure to update uid-gid.txt.
> 

Okay so when you said "i'll take highest free at the time" you meant
that's what the requester would say.  Sorry for the misunderstanding.

Okay, I'm requesting UID/GID = 492/492.  I'm committing in a sec.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] RFC: request uid/gid for net-misc/stunnel

2019-12-08 Thread Anthony G. Basile
Hi everyone,

I know that is my third time requesting a uid/gid for stunnel, but it
seems that my previous request was already taken but not added to the
uid-gid.txt file, so I didn't know about the collision.

Speaking with mgorny on #gentoo-dev, he suggested that we start simply
making a request, and he'll assign the highest free value(s) at the time.

So @mgorny, can i please have a UID and GID pair for stunnel.

Thanks!

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] RFC acct-{user,group} for net-dns/avahi, net-vpn/tor, net-misc/stunnel

2019-11-27 Thread Anthony G. Basile
On 11/27/19 1:47 PM, Ulrich Mueller wrote:
>>>>>> On Wed, 27 Nov 2019, Anthony G Basile wrote:
> 
> 
> I'd suggest UID and GID 43 for tor (following Archlinux).
> 
> Ulrich
> 

Thanks Ulrich.  Works for me.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] RFC acct-{user,group} for net-dns/avahi, net-vpn/tor, net-misc/stunnel

2019-11-27 Thread Anthony G. Basile
On 11/27/19 11:52 AM, Anthony G. Basile wrote:
> Hi everyone,
> 
> I'm requesting
> 
> 1) uid/gid = 70/70 for net-dns/avahi
> 
> 2) uid/gid = 997/995 for net-vpn/tor
> 
> 3) uid/gid = 485/485 for net-misc/stunnel
> 
> Both avahi and tor follow fedora.  The values for stunnel were the
> highest available values below 500.
> 

Sorry but I didn't know about the list of already requested numbers at

   https://gitweb.gentoo.org/data/api.git/tree/files/uid-gid.txt

So I need to revise the above request.  Here's my new numbers:

1) For net-dns/avahi

avahi uid = 61
avahi gid = 61

avahi-autoipd uid = 62
avahi-autoipd gid = 62

netdev gid = 64


2) For net-vpn/tor

tor uid = 493
tor gid = 493


3) For net-misc/stunnel

stunnel uid = 478
stunnel gid = 478



Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] RFC acct-{user,group} for net-dns/avahi, net-vpn/tor, net-misc/stunnel

2019-11-27 Thread Anthony G. Basile
On 11/27/19 1:04 PM, Joonas Niilola wrote:
> Hey,
> 
> 
> On 11/27/19 6:52 PM, Anthony G. Basile wrote:
>> 3) uid/gid = 485/485 for net-misc/stunnel
>>
>> Both avahi and tor follow fedora.  The values for stunnel were the
>> highest available values below 500.
>>
> 485 has been requested for bedrock though.
> 
> https://gitweb.gentoo.org/data/api.git/tree/files/uid-gid.txt
> 
> 
> -- juippis
> 
> 

Thanks.  I didn't know about that list.  I'm going to have to update my
numbers.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] RFC acct-{user,group} for net-dns/avahi, net-vpn/tor, net-misc/stunnel

2019-11-27 Thread Anthony G. Basile
On 11/27/19 11:52 AM, Anthony G. Basile wrote:
> 
> 1) uid/gid = 70/70 for net-dns/avahi
> 

Actually I need to expand this for avahi.  I need a netdev group and
avahi-autoipd user/group.  So, in addition to the above, I'm also requesting

netdev gid = 479

avahi-autoipd uid/gid = 170/170


The avahi-autoipd values were obtained from fedora.  The netdev was
obtained from the highest available gid below 500.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] RFC acct-{user,group} for net-dns/avahi, net-vpn/tor, net-misc/stunnel

2019-11-27 Thread Anthony G. Basile
Hi everyone,

I'm requesting

1) uid/gid = 70/70 for net-dns/avahi

2) uid/gid = 997/995 for net-vpn/tor

3) uid/gid = 485/485 for net-misc/stunnel

Both avahi and tor follow fedora.  The values for stunnel were the
highest available values below 500.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] PSA: 13.0 profiles will be removed in a week

2019-06-21 Thread Anthony G. Basile
On 6/21/19 2:54 AM, Sergei Trofimovich wrote:
> On Wed, 19 Jun 2019 15:29:33 -0400
> "Anthony G. Basile"  wrote:
> 
>> On 6/19/19 3:19 AM, Sergei Trofimovich wrote:
>>>
>>> This is now tracked as https://bugs.gentoo.org/688342. I hope to get
>>> at least some followup there.
>>>   
>>
>> When I try to look at that bug, it says I'm not authorized.  I'm
>> concerned about two remaining mips profiles (uclibc and musl) which I'm
>> working to migrate to 17.0.  I don't think that the removal of the 13.0
>> profiles will affect them, but I'd like to know.
>>
>> The reason this is taking so long is 1) mips is a ~arch profile so
>> there's a lot of blockers and 2) my mips equipment is slow.
> 
> Those don't seem to inherit releases/13.0.
> 
> I've dropped releases/13.0 again:
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d40fdcf1e4bdd370a13800e73a383537beef365a
> 
> It it happens to break other profiles missing from profiles.desc please
> shout and we'll reinstate those until they are sorted.
> 

They don't.  I'm hoping over the weekend to move the remaining mips
uclibc and musl profiles over to the 17.0 and then I'll clean up after
myself.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] PSA: 13.0 profiles will be removed in a week

2019-06-19 Thread Anthony G. Basile
On 6/19/19 3:19 AM, Sergei Trofimovich wrote:
> 
> This is now tracked as https://bugs.gentoo.org/688342. I hope to get
> at least some followup there.
> 

When I try to look at that bug, it says I'm not authorized.  I'm
concerned about two remaining mips profiles (uclibc and musl) which I'm
working to migrate to 17.0.  I don't think that the removal of the 13.0
profiles will affect them, but I'd like to know.

The reason this is taking so long is 1) mips is a ~arch profile so
there's a lot of blockers and 2) my mips equipment is slow.

--Tony

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Re: EAPI 2 must die

2019-06-06 Thread Anthony G. Basile
On 6/6/19 3:34 AM, Luca Barbato wrote:
> On 06/06/2019 09:05, Matt Turner wrote:
>> On Wed, Jun 5, 2019 at 11:39 PM Agostino Sarubbo  wrote:
>>>
>>> On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote:
>>>> Anybody has hardware to test it?
>>>
>>> I can do it on timberdoodle.
>>
>> The issue is that the package is for "OldWorld" Macs (like 20+ years
>> old). We recently dropped the bootloader, sys-boot/quik, so I think
>> we'd be fine to drop sys-apps/powerpc-utils as well.
>>
> 
> Exactly :)
> 
> I'm fine with treecleaning it.
> 
> lu
> 

Lol! I still have some OldWorld Macs, but I'm okay with tree cleaning
it.  Didn't we have some "archive" for old ebuilds?  Maybe we can move
it there.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Packages up for grabs from xmw@g.o

2018-11-25 Thread Anthony G. Basile
On 11/25/18 5:04 AM, Michał Górny wrote:

> net-misc/arpd

This is an important package.  I can take care of it.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] [PATCH 3/4] toolchain.eclass: Transition deps to x11-base/xorg-proto

2018-04-27 Thread Anthony G. Basile
On 4/27/18 2:31 AM, Matt Turner wrote:
> ---
>  eclass/toolchain.eclass | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index 2da455ad4e3b..df76dc4feb8c 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -206,11 +206,10 @@ DEPEND="${RDEPEND}
>  if in_iuse gcj ; then
>   GCJ_DEPS=">=media-libs/libart_lgpl-2.1"
>   GCJ_GTK_DEPS="
> + x11-base/xorg-proto
>   x11-libs/libXt
>   x11-libs/libX11
>   x11-libs/libXtst
> - x11-proto/xproto
> - x11-proto/xextproto
>   =x11-libs/gtk+-2*
>   virtual/pkgconfig
>   "
> 

These patches should be fine.  It looks like you just finished
stabilizing x11-base/xorg-proto for all arches so the transition won't
cause any problems.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Regarding the State of PaX in the tree

2018-04-16 Thread Anthony G. Basile
On 4/16/18 5:14 AM, Hanno Böck wrote:
> Hi,
> 
> I honestly don't see how it would be feasible to maintain a feature
> that the developers maintaining it have access to.

I think you're missing a negation in there.  Point well taken though.


> 
> I get that this whole pax-thing embodies a huge part of Gentoo history
> and it may feel hard for some to let it go. But things are how they are.

I agree, and we'll have it in our history if hardened-sources ever comes
back.  The only machinery we should keep is install-xattrs which grew
out of the integration of xattr PaX markings but is useful beyond just PaX.

> 
> Regarding the fork states: I followed up on minipli's fork, which
> tried to maintain newer patches of grsec for LTS kernels, but that
> essentially stopped after KPTI/meltdown/retpoline. From what I know
> there's no public grsec patch with kpti or any spectre fixes, thus I
> would very much say you're safer these days with an upstream kernel.
> 

Correct.  I would not use the old hardened-sources or minipli's fork on
any production server.

> I think the only realistic way this support can be upheld would be if
> some people who have access to the grsec sources commit to making sure
> that it is maintained.

Upstream has never responded to any email I sent them.  I had a brief
discussion with spender when the decision came down, and he gave me what
I interpreted as an "I'm sorry this is going to adversely affect you but
it has to be this way."

> 
> 
> There's also another question related to this: What's the future for
> Gentoo hardened?
> From what I can tell hardened consists of:
> * the things that try to make it compatible with grsec/pax
>   (more or less obsolete).
> * things that are now in default profiles anyway (aslr, stack
>   protector).
> * things that probably should be in default profiles (relro, now linker
>   flags)
> * -fstack-check, which should eventually be replaced with
>   -fstack-clash-protection (only available in future gcc's) and that
>   should probably also go into default profiles.
> * Furthermore hardened disables some useful features due to their
>   incompatibility with pax (e.g. sanitizers).
> 
> So it's stuff that either is obsolete or probably should be a candidate
> for main profiles. Maybe we should strive for "hardened-by-default".
> 

You're forgetting selinux.  Most of Zorry's work has made it into gcc
and is now being enabled by our default toolchain.  Some kernel features
have also been improved upstream.  With upstream carrying a lot of the
work we did, I think 'hardened-by-default' minus selinux should be the
goal of Gentoo.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Regarding the State of PaX in the tree

2018-04-16 Thread Anthony G. Basile
On 4/16/18 3:22 AM, Ulrich Mueller wrote:
>>>>>> On Mon, 16 Apr 2018, Michał Górny wrote:
> 
>> W dniu nie, 15.04.2018 o godzinie 20∶04 -0400, użytkownik
>> Anthony G. Basile napisał:
>>> The question then is, do we remove all this code? As thing stands,
>>> its just lint that serves no current purpose, so removing it would
>>> clean things up. The disadvantage is it would be a pita to ever
>>> restore it if we ever wanted it back. While upstream doesn't
>>> provide their patch for free, some users/companies can purchase the
>>> grsecurity patches and still use a custom hardened-sources kernel
>>> with Gentoo. But since we haven't been able to test the pax
>>> markings/custom patches in about a year, its hard to say how useful
>>> that code might still be.
> 
> For Emacs, hardened support was quite a headache in the past, due to
> its unexec mechanism; see bugs 285778, 411439, 426394, 456970, 497498,
> 515122, 529172, their duplicates, and the upstream bugs linked from
> them. We cannot safely assume that any new (hardened kernel, or Emacs)
> version will work out of the box. Therefore, I am inclined to either
> remove the pax_kernel flag from my ebuilds, or to package.use.mask it
> at least, in order to make clear that this is no longer a supported
> configuration.
> 

I was thinking particularly of emacs when I wrote this.  So now not only
do we have those headaches, but no way to maintain them properly.  For
emacs, I would just remove the pax stuff entirely and if
hardened-sources ever comes back, we would then deal accordingly.

>> One thing Hardened project should do is make a clear statement to
>> other developers -- i.e. indicate whether I should CC hardened@ when
>> someone has PaX problems and doesn't provide a patch, or just close
>> the bug saying that we can't solve it without a patch.
> 
> I would even go one step further and tell people to sort things out
> with upstream. First, because I cannot reasonably upstream patches for
> an unsupported configuration that I cannot test. Second, since they
> have purchased the grsecurity patches, they should also ask grsecurity
> for support. Why should I as an unpaid volunteer spend my time on it?
> 

This pretty much sums up my sentiment.  I want to add here that I'm
upset with upstream's decision.  For years we fixed many userland
programs that would otherwise have remained useless with their
hardening.  I also worked to move the PaX flags from the elf program
headers (where it sometimes broke stuff) to the much safer xattrs.
grsecurity.net benefited from all this work and then threw us under the
bus in their fight with whoever was abusing the license.  Most unfair.

> Ulrich
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Regarding the State of PaX in the tree

2018-04-16 Thread Anthony G. Basile
On 4/16/18 4:05 AM, Marc Schiffbauer wrote:
> * Anthony G. Basile schrieb am 16.04.18 um 02:04 Uhr:
>> Hi everyone,
> 
> Hi Anthony,
> 
> I vote for keeping PaX Support as I am still using it and might be doing 
> so in the future.
> 
> Thanks ;)
> -Marc
> 

How are you able to test?  Do you have your hands on the latest grsec
patches or are you using an old kernel.  Old at this point means one
year old.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] Regarding the State of PaX in the tree

2018-04-15 Thread Anthony G. Basile
Hi everyone,

Magnus (aka Zorry) and I have been talking about what to do with PaX in
the Gentoo tree.  A year ago, grsecurity.net upstream stopped providing
open versions of their patches to the community and this basically
brought an end to sys-kernel/hardened-sources.  I waited a while before
masking the package in the hope that upstream might reconsider.  There
were also some forks but I didn't have much confidence in them.  I'm not
sure that any of these forks have been able to keep up past
meltdown/specter.

It may be time to remove sys-kernel/hardened-sources completely from the
tree.  Removing the package is easy, but the issue is there is a lot of
machinery in the tree that revolves around supporting a PaX kernel.
This involves things like setting PaX flags on some executables either
by touching the ELF program headers or the file's extended attributes,
or applying custom patches.

The question then is, do we remove all this code?  As thing stands, its
just lint that serves no current purpose, so removing it would clean
things up.  The disadvantage is it would be a pita to ever restore it if
we ever wanted it back.  While upstream doesn't provide their patch for
free, some users/companies can purchase the grsecurity patches and still
use a custom hardened-sources kernel with Gentoo.  But since we haven't
been able to test the pax markings/custom patches in about a year, its
hard to say how useful that code might still be.

I'm just emailing everyone to get advice.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Re: [gentoo-mips] Monthly mips@ project status for April 2018

2018-04-02 Thread Anthony G. Basile
On 4/2/18 3:39 AM, Joshua Kinard wrote:
> On 4/2/2018 3:37 AM, Joshua Kinard wrote:
>> On 4/1/2018 11:40 PM, Matt Turner wrote:
>>> I'd like to start giving ~monthly updates on the status of mips@ in
>>> Gentoo.
>>>
>>> Recently I received a Loongson 3A system (quad-core 1.35GHz, 16GB RAM,
>>> AMD graphics) which is significantly faster and more stable than any
>>> other mips system I have.
>>
>> Big or little endian?  If little,
> 
> Helps to finish my sentences.  Except I don't remember where I was going to go
> with this bit.
> 

Its little endian.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Its time to mask sys-libs/uclibc

2018-02-23 Thread Anthony G. Basile
On 2/23/18 11:22 AM, Matthias Maier wrote:
> 
> On Fri, Feb 23, 2018, at 10:01 CST, "Anthony G. Basile" <bluen...@gentoo.org> 
> wrote:
> 
>> [...]
> 
>> I'm not even sure a news item is needed here.  What do people think?  If
>> you think so, who do I even direct it at?
> 
> If there is no action needed on user side and an upgrade and migration
> from uclibc to uclibc-ng happens automatically, I'd say no news item is
> necessary.
> 
> Further, seeing "uclibc-ng" being emerged and "uclibc" unmerged should
> be pretty self explanatory.
> 
> Best,
> Matthias
> 

I already sent a news item for migrating uclibc -> uclibc-ng some years
ago.  After 6 years, anyone still on uclibc has a seriously broken
system.  I doubt migration is even possible at this point.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] Its time to mask sys-libs/uclibc

2018-02-23 Thread Anthony G. Basile
Hi everyone,

So if anyone has been following uclibc, you know that its development
stalled with its last official release in 2012 (https://uclibc.org/).
It was forked into uclibc-ng (https://uclibc-ng.org/) which has been
actively maintained since.  All my uclibc work has been done using
sys-libs/uclibc-ng although the profile names still retain /uclibc/ in them.

Its time to mask and remove sys-libs/uclibc in favor of
sys-libs/uclibc-ng.  This email is just an alert to the community that
I'm going to do that soon.

I'm not even sure a news item is needed here.  What do people think?  If
you think so, who do I even direct it at?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] EAPI 7 in Portage needs YOU!

2018-02-19 Thread Anthony G. Basile
On 2/19/18 5:49 AM, Michał Górny wrote:

> 1. Runtime-switchable USE flags,

I need to understand this.  Where are the specs?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Cleaning up the uclibc and musl profiles

2018-01-22 Thread Anthony G. Basile
On 1/20/18 2:35 PM, Anthony G. Basile wrote:
> I'm working on a multi-step plan to clean up the uclibc and musl
> profiles to make repoman (and arch testers) happy.  It will take a while
> because I have to make sure I don't seriously break things for people
> using them.  As a first step, I think its time to clear out the ancient
> uclibc profiles found at `profiles/uclibc'.  They have been unused for
> years.  I have a PR on github if anyone wants to review:
> 
> https://github.com/gentoo/gentoo/pull/6918
> 
> I'll commit it after feedback.
> 

Okay, no feedback so I'm going to assume people are okay with this.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] Cleaning up the uclibc and musl profiles

2018-01-20 Thread Anthony G. Basile
I'm working on a multi-step plan to clean up the uclibc and musl
profiles to make repoman (and arch testers) happy.  It will take a while
because I have to make sure I don't seriously break things for people
using them.  As a first step, I think its time to clear out the ancient
uclibc profiles found at `profiles/uclibc'.  They have been unused for
years.  I have a PR on github if anyone wants to review:

https://github.com/gentoo/gentoo/pull/6918

I'll commit it after feedback.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Re: Managing updates on many identical Gentoo systems

2018-01-20 Thread Anthony G. Basile
On 1/19/18 10:03 AM, Anthony G. Basile wrote:
> On 1/19/18 9:45 AM, Alec Warner wrote:
>> On Thu, Jan 18, 2018 at 5:13 PM, Bill Kenworthy <bi...@iinet.net.au> wrote:
>>
>>> On 18/01/18 23:36, Duncan wrote:
>>>> Anthony G. Basile posted on Thu, 18 Jan 2018 06:46:53 -0500 as excerpted:
>>>>
>>>>> I'm trying to design an update system for many identical Gentoo systems.
>>>>>  Using a binhost is obvious, but there are still problems with this
>>>>> approach.
>>>>>
>>>
>>> I'd suggest go for a semi diskless OS - boot them from one central image
>>> with an individual overlay filesystem with local customisations.  NFS
>>> mount the common directories.
>>>
>>> you just have a one central host to build for and don't need to worry
>>> about portage everywhere.
>>>
>>> Worked ok with a small number of mythtv frontends.
>>>
>>
>> It doesn't work if you have a WAN; NFS needs low latencies between the NFS
>> server and the client or you will have a bad time.
>>
>>
> 
> Zac pretty much nailed the requirements in bug #644990.  You should not
> need the portage tree at all, neither locally nor via any network
> filesystem.  He mentions there that it is currently possible via "a
> dummy profile", but I'm not sure what he means by that yet or how to set
> one up.  I'll read his bug #640318 and try to figure it out.
> 
> Thanks guys, I'm glad people at least recognized the usefulness of such
> a possibility.
> 

Okay, I have a workable solution to my question.  I was able to get
binhost working with a portage tree containing ONLY /profiles and
/eclass.  That's 12MB and 2.8MB in size, respectively, and I can
probably dump a bunch of the unused profile directories slimming that
down.  With just those two directories in PORTDIR, emerge -K pulls down
the update packages from BINHOST and installs them.

@zac any comments about this approach?  Is it likely to break?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Re: Managing updates on many identical Gentoo systems

2018-01-19 Thread Anthony G. Basile
On 1/19/18 9:45 AM, Alec Warner wrote:
> On Thu, Jan 18, 2018 at 5:13 PM, Bill Kenworthy <bi...@iinet.net.au> wrote:
> 
>> On 18/01/18 23:36, Duncan wrote:
>>> Anthony G. Basile posted on Thu, 18 Jan 2018 06:46:53 -0500 as excerpted:
>>>
>>>> I'm trying to design an update system for many identical Gentoo systems.
>>>>  Using a binhost is obvious, but there are still problems with this
>>>> approach.
>>>>
>>
>> I'd suggest go for a semi diskless OS - boot them from one central image
>> with an individual overlay filesystem with local customisations.  NFS
>> mount the common directories.
>>
>> you just have a one central host to build for and don't need to worry
>> about portage everywhere.
>>
>> Worked ok with a small number of mythtv frontends.
>>
> 
> It doesn't work if you have a WAN; NFS needs low latencies between the NFS
> server and the client or you will have a bad time.
> 
> 

Zac pretty much nailed the requirements in bug #644990.  You should not
need the portage tree at all, neither locally nor via any network
filesystem.  He mentions there that it is currently possible via "a
dummy profile", but I'm not sure what he means by that yet or how to set
one up.  I'll read his bug #640318 and try to figure it out.

Thanks guys, I'm glad people at least recognized the usefulness of such
a possibility.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] Managing updates on many identical Gentoo systems

2018-01-18 Thread Anthony G. Basile
Hi everyone,

I'm trying to design an update system for many identical Gentoo systems.
 Using a binhost is obvious, but there are still problems with this
approach.

Unless there's some magic I don't know about (and this is why I'm
sending this email) each machine still needs to have the portage tree
installed locally (1.5 GB) or somehow mounted by a network filesystem
(which is not practical if the machines are not on a local network).
Furthermore, each machine would have to run emerge locally to do the
calculation of what packages need updating.

This procedure is redundant because each machine is housing the same
data and doing the same dependence-tree calculation.  It should be
possible to do this calculation on a centralized binhost and simply
communicate the update information to the remote machines.  They would
then only have to download the .tbz2's and install them, keeping a tidy
/var/db/pkg.  Thus they avoid having to house the portage tree and
burning cpu cycles that just calculate redundant information.

I'm inspired here by OpenBSD's pkg_add which doesn't require all of
ports to be installed, and mender which is a

Any ideas?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] [PATCH v3] profiles.desc: Lower some profiles with broken depgraph from dev to exp

2018-01-11 Thread Anthony G. Basile
On 1/11/18 4:47 PM, Michał Górny wrote:
> 
> I withdraw this since everyone obviously has his special workflow and we
> can't touch anything. Now the CI report is 3.5M large and lists over 900
> broken packages. Please start looking into fixing your profiles. Thank
> you.
> 

Now that you explained the issue to me on IRC, I'm going to work towards
restructuring the uclibc and musl profiles so that they inherit in a
manner similar to hardened.  I suspect this will clear out a lot of the
issues reported at [1].  It should also give those profiles more
longevity.  Its a fair bit of work, so I'll ask for some patience.

[1] https://qa-reports.gentoo.org/output/gentoo-ci/output.html

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] [PATCH v2] profiles.desc: Lower profiles with broken depgraph from dev to exp

2018-01-11 Thread Anthony G. Basile
/multilib/n64 exp
>  
>  # Nios II Profiles
> @@ -240,22 +240,22 @@ x86 default/linux/x86/17.0/developer
> stable
>  x86  default/linux/x86/17.0/systemd  stable
>  
>  # Gentoo/FreeBSD Profiles
> -amd64-fbsd   default/bsd/fbsd/amd64/9.1  dev
> -amd64-fbsd   default/bsd/fbsd/amd64/11.1 dev
> +amd64-fbsd   default/bsd/fbsd/amd64/9.1  exp
> +amd64-fbsd   default/bsd/fbsd/amd64/11.1 exp
>  amd64-fbsd   default/bsd/fbsd/amd64/9.1/clangexp
>  amd64-fbsd   default/bsd/fbsd/amd64/11.1/clang   exp
>  sparc-fbsd  default/bsd/fbsd/sparc/8.2  exp
> -x86-fbsd default/bsd/fbsd/x86/9.1dev
> -x86-fbsd default/bsd/fbsd/x86/11.1   dev
> +x86-fbsd default/bsd/fbsd/x86/9.1exp
> +x86-fbsd default/bsd/fbsd/x86/11.1   exp
>  


>  
> @@ -290,37 +290,37 @@ x86 default/linux/musl/x86  
> exp
>  x86  hardened/linux/musl/x86 exp
>  
>  # Non-embedded uclibc profiles
> -amd64default/linux/uclibc/amd64  
> dev
> -amd64hardened/linux/uclibc/amd64 
> dev
> -arm  default/linux/uclibc/arm/armv7a dev
> -arm  hardened/linux/uclibc/arm/armv7adev
> -mips default/linux/uclibc/mips   dev
> -mips hardened/linux/uclibc/mips  dev
> -mips default/linux/uclibc/mips/mipseldev
> -mips hardened/linux/uclibc/mips/mipsel   dev
> -ppc  default/linux/uclibc/ppcdev
> -ppc  hardened/linux/uclibc/ppc   dev
> -x86  default/linux/uclibc/x86dev
> -x86  hardened/linux/uclibc/x86   dev
> +amd64default/linux/uclibc/amd64  
> exp
> +amd64hardened/linux/uclibc/amd64 
> exp
> +arm  default/linux/uclibc/arm/armv7a exp
> +arm  hardened/linux/uclibc/arm/armv7aexp
> +mips default/linux/uclibc/mips   exp
> +mips hardened/linux/uclibc/mips  exp
> +mips default/linux/uclibc/mips/mipselexp
> +mips hardened/linux/uclibc/mips/mipsel   exp
> +ppc  default/linux/uclibc/ppcexp
> +ppc  hardened/linux/uclibc/ppc   exp
> +x86  default/linux/uclibc/x86exp
> +x86  hardened/linux/uclibc/x86   exp
>  

Dropping the uclibc and musl profiles to exp will seriously break things
for me.  I'm going to say no to this.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

2017-12-30 Thread Anthony G. Basile
On 12/30/17 12:18 PM, Andreas K. Huettel wrote:
> Am Samstag, 30. Dezember 2017, 13:22:52 CET schrieb Anthony G. Basile:
>> Hi everyone,
>>
>> We've been stuck on EAPI=4 with toolchain.eclass for a while.  This is
>> causing problems with subslotting libraries like mpfr, mpc, gmp and isl
>> that gcc depend on (see bug #642316).  I went through and made the
>> changes necessary to get the eclass up to EAPI=5 and compile tested
>> across the board (ie all dependent ebuilds) for amd64.  Everything looks
>> good, so please review and I'll commit if we're okay.
> 
> - confgcc+=( $(use_enable altivec) )
> + in_iuse altivec && confgcc+=( $(use_enable altivec) )
> 
> ^ Just as an example, such a construct may change the "default setting" when 
> no altivec useflag exists...
> 
> Imagine that upstream enables altivec by default (?). In earlier eapis, 
> use_enable with a non-existing useflag returned --disable-altivec (?). Now, 
> without the useflag, no setting is passed to configure, and it's enabled.
> 
> So, while this all works in principle, it may need careful per-flag review.
> 

Okay so I tested and found that there is no change in the default
settings due to the above construct (and there are a few).  The way I
did it was I built >=gcc-4.9.4 with and without the toolchain.eclass
patch and compared the config.log's (there's about 33 per version of
gcc).  There were no substantial differences.  If there would have been
a change in the default behavior, then lines like following would have
shown a difference.


  $ /var/tmp/portage/sys-devel/gcc-7.2.0/work/gcc-7.2.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/7.2.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/include/g++-v7
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.2.0/python
--enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls
--without-included-gettext --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 7.2.0
p1.1 --disable-esp --enable-libstdcxx-time --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-altivec
--disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp
--disable-libcilkrts --disable-libmpx --enable-vtable-verify
--enable-libvtv --enable-lto --without-isl --enable-libsanitizer
--disable-default-pie --enable-default-ssp


I didn't test earlier gcc versions because they're masked.  I tested
only on amd64 but I think that's oaky.  The only flag my tests don't
cover is the altivec flag (which is for ppc/ppc64), but it defaults off
on all gcc versions.

I think this puts your concern to rest.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

2017-12-30 Thread Anthony G. Basile
On 12/30/17 9:13 AM, Anthony G. Basile wrote:
> On 12/30/17 9:08 AM, Michael Orlitzky wrote:
>> On 12/30/2017 07:22 AM, Anthony G. Basile wrote:
>>> use_if_iuse !nopie && return 0
>>
>> Does this work? The "use" function supports negation (undocumented, but
>> it's in the PMS), but I don't think use_if_iuse does.
>>
> 
> Okay I'll read the code and test.  You're right that I just assumed it
> worked liked "use" wrt negation so the semantics need to be checked.
> 
> Thanks for looking this over carefully.
> 

It looks like it would not work as expected because eutils.eclass has

in_iuse() {
debug-print-function ${FUNCNAME} "${@}"
[[ ${#} -eq 1 ]] || die "Invalid args to ${FUNCNAME}()"

local flag=${1}
local liuse=( ${IUSE} )

has "${flag}" "${liuse[@]#[+-]}"
}

use_if_iuse() {
in_iuse $1 || return 1
use $1
}

So $1 in use_if_iuse binds to "!nopie" and then in in_iuse again to
"!nopie" which then messes up the has line, looking for a flag named
"!nopie" in IUSE which will always be true.

I'll change that line to

use_if_iuse nopie || return 0

Grepping the tree, I see only instances of

if ! use_if_iuse X ...

which is good.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Patches to update toolchain.eclass to EAPI=5

2017-12-30 Thread Anthony G. Basile
On 12/30/17 9:08 AM, Michael Orlitzky wrote:
> On 12/30/2017 07:22 AM, Anthony G. Basile wrote:
>> use_if_iuse !nopie && return 0
> 
> Does this work? The "use" function supports negation (undocumented, but
> it's in the PMS), but I don't think use_if_iuse does.
> 

Okay I'll read the code and test.  You're right that I just assumed it
worked liked "use" wrt negation so the semantics need to be checked.

Thanks for looking this over carefully.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA




[gentoo-dev] Patches to update toolchain.eclass to EAPI=5

2017-12-30 Thread Anthony G. Basile
Hi everyone,

We've been stuck on EAPI=4 with toolchain.eclass for a while.  This is
causing problems with subslotting libraries like mpfr, mpc, gmp and isl
that gcc depend on (see bug #642316).  I went through and made the
changes necessary to get the eclass up to EAPI=5 and compile tested
across the board (ie all dependent ebuilds) for amd64.  Everything looks
good, so please review and I'll commit if we're okay.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA
From b4a707673b7a3e36959a071292807945b07fd018 Mon Sep 17 00:00:00 2001
From: "Anthony G. Basile" <bluen...@gentoo.org>
Date: Sat, 30 Dec 2017 06:56:29 -0500
Subject: [PATCH 1/2] toolchain.eclass: update to EAPI=5 standards

This eclass is inherited by ebuilds in sys-devel/{gcc,kgcc64,gcc-apple},
each which make use of different IUSE flags.   This causes problems with
`use X` construcitons when X is not in the IUSE flags.  At EAPI=4 this
simply emitted a warning, while at EAPI=5 this is an error.  We update
the eclass to make use of use_if_iuse and similar constructions where
necessary to bring the eclass into compliance with EAPI=5.

Signed-off-by: Anthony G. Basile <bluen...@gentoo.org>
---
 eclass/toolchain.eclass | 69 ++---
 1 file changed, 36 insertions(+), 33 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index a038303ec7f..bf6aa89e2fb 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -496,7 +496,7 @@ toolchain_src_prepare() {
do_gcc_PIE_patches
epatch_user
 
-   if ( tc_version_is_at_least 4.8.2 || use hardened ) && ! use vanilla ; 
then
+   if ( tc_version_is_at_least 4.8.2 || use_if_iuse hardened ) && ! use 
vanilla ; then
make_gcc_hard
fi
 
@@ -538,7 +538,7 @@ toolchain_src_prepare() {
fi
 
# >= gcc-4.3 doesn't bundle ecj.jar, so copy it
-   if tc_version_is_at_least 4.3 && use gcj ; then
+   if tc_version_is_at_least 4.3 && use_if_iuse gcj ; then
if tc_version_is_at_least 4.5 ; then
einfo "Copying ecj-4.5.jar"
cp -pPR "${DISTDIR}/ecj-4.5.jar" "${S}/ecj.jar" || die
@@ -648,20 +648,20 @@ make_gcc_hard() {
 
# Gcc >= 6.X we can use configurations options to turn pie/ssp on as 
default
if tc_version_is_at_least 6.0 ; then
-   if use pie ; then
+   if use_if_iuse pie ; then
einfo "Updating gcc to use automatic PIE building ..."
fi
-   if use ssp ; then
+   if use_if_iuse ssp ; then
einfo "Updating gcc to use automatic SSP building ..."
fi
-   if use hardened ; then
+   if use_if_iuse hardened ; then
# Will add some optimatizion as default.
gcc_hard_flags+=" -DEXTRA_OPTIONS"
# rebrand to make bug reports easier

BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
fi
else
-   if use hardened ; then
+   if use_if_iuse hardened ; then
# rebrand to make bug reports easier

BRANDING_GCC_PKGVERSION=${BRANDING_GCC_PKGVERSION/Gentoo/Gentoo Hardened}
if hardened_gcc_works ; then
@@ -909,7 +909,7 @@ toolchain_src_configure() {
 
# Use the default ("release") checking because upstream usually neglects
# to test "disabled" so it has a history of breaking. #317217
-   if tc_version_is_at_least 3.4 ; then
+   if tc_version_is_at_least 3.4 && in_iuse debug ; then
# The "release" keyword is new to 4.0. #551636
local off=$(tc_version_is_at_least 4.0 && echo release || echo 
no)
confgcc+=( --enable-checking="${GCC_CHECKS_LIST:-$(usex debug 
yes ${off})}" )
@@ -922,7 +922,7 @@ toolchain_src_configure() {
)
 
# If we want hardened support with the newer piepatchset for >=gcc 4.4
-   if tc_version_is_at_least 4.4 && want_minispecs ; then
+   if tc_version_is_at_least 4.4 && want_minispecs && in_iuse hardened ; 
then
confgcc+=( $(use_enable hardened esp) )
fi
 
@@ -934,7 +934,7 @@ toolchain_src_configure() {
fi
 
# Support to disable pch when building libstdcxx
-   if tc_version_is_at_least 6.0 && ! use pch ; then
+   if tc_version_is_at_least 6.0 && ! use_if_iuse pch ; then
confgcc+=( --disable-libstdcxx-pch )
fi
 
@@ -1058,12 +105

Re: [gentoo-dev] Projects up for grabs: cron, m68k

2017-12-21 Thread Anthony G. Basile
On 12/21/17 12:19 AM, Jason Zaman wrote:
> On Wed, Dec 20, 2017 at 06:29:57PM +0100, Hans de Graaff wrote:
>> On Wed, 2017-12-20 at 18:02 +0100, Michał Górny wrote:
>>>
>>>   sys-process/vixie-cron
>>
>> My understanding is that vixie-cron is no longer maintained and sys-
>> process/cronie is the drop-in replacement that is now also suggested as
>> the default cron in the handbook.
>>
>> https://archives.gentoo.org/gentoo-dev/message/d898f86f805909eb72aba61d
>> 2dca8523
>>
>> I seem to recall a more recent discussion about this as well, but can't
>> find it at the moment.
>>
>> Perhaps it is time to mask vixie-cron for removal?
> 
> I just updated the SELinux patch on vixie-cron and stabilized it a while
> ago, it works fine and doesnt need all that much maintenance. I vote
> keep it, i'll look after it. If it has some big architectural issues
> later then we can last-rite it but its been reliable so far.
> 
> I added myself to the Cron project with blueness.
> 
> -- Jason
> 
> 

Jason, much appreciated.  Also thanks Michal for noticing that cron
needed love.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] Package up for grab

2017-12-20 Thread Anthony G. Basile
Hi everyone,

I was maintaining the following package

net-p2p/tribler

but I just dropped it to maintainer-needed.  Someone asked me for it,
but it needs work on bumping and its not that interesting/important to me.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Projects up for grabs: cron, m68k

2017-12-20 Thread Anthony G. Basile
On 12/20/17 12:07 PM, Anthony G. Basile wrote:
> On 12/20/17 12:02 PM, Michał Górny wrote:
>> Hello, everyone.
>>
>> Due to prolonged inactivity of Mike Frysinger (vapier), the following
>> projects have had effectively no members for 6 months already:
>>
>> https://wiki.gentoo.org/wiki/Project:Cron
>>
>>   sys-process/anacron [m]
>>   sys-process/at
>>   sys-process/bcron
>>   sys-process/cronbase
>>   sys-process/cronie [m]
>>   sys-process/dcron
>>   sys-process/fcron [m]
>>   sys-process/vixie-cron
>>   virtual/cron
>>
>> https://wiki.gentoo.org/wiki/Project:M68k
>>
>>   sys-apps/zorroutils [m]
>>   sys-fs/atari-fdisk
>>
>> The packages listed with '[m]' have other maintainers. The remaining
>> packages are solely maintained by the listed projects.
>>
>> If you are interested in helping out with some of those packages, please
>> consider joining the appropriate project and/or co-maintaining the
>> individual packages.
>>
>> If the projects see no activity within the next month, I will disband
>> them and move the appropriate packages to maintainer-needed.
>>
> 
> Those are very important packages.  I use fcron and at and I can help
> take care of those.  I should probably take a look a t cronbase and
> virtual/cron too.
> 

Okay a followup on my last email, I added myself to the project and will
try to take care of all cron packages.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Projects up for grabs: cron, m68k

2017-12-20 Thread Anthony G. Basile
On 12/20/17 12:02 PM, Michał Górny wrote:
> Hello, everyone.
> 
> Due to prolonged inactivity of Mike Frysinger (vapier), the following
> projects have had effectively no members for 6 months already:
> 
> https://wiki.gentoo.org/wiki/Project:Cron
> 
>   sys-process/anacron [m]
>   sys-process/at
>   sys-process/bcron
>   sys-process/cronbase
>   sys-process/cronie [m]
>   sys-process/dcron
>   sys-process/fcron [m]
>   sys-process/vixie-cron
>   virtual/cron
> 
> https://wiki.gentoo.org/wiki/Project:M68k
> 
>   sys-apps/zorroutils [m]
>   sys-fs/atari-fdisk
> 
> The packages listed with '[m]' have other maintainers. The remaining
> packages are solely maintained by the listed projects.
> 
> If you are interested in helping out with some of those packages, please
> consider joining the appropriate project and/or co-maintaining the
> individual packages.
> 
> If the projects see no activity within the next month, I will disband
> them and move the appropriate packages to maintainer-needed.
> 

Those are very important packages.  I use fcron and at and I can help
take care of those.  I should probably take a look a t cronbase and
virtual/cron too.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Patch for toolchain.eclass for uclibc-ng

2017-11-26 Thread Anthony G. Basile
On 11/26/17 10:50 AM, Andreas K. Huettel wrote:
> Am Samstag, 25. November 2017, 15:01:20 CET schrieb Anthony G. Basile:
>> Hi everyone,
>>
>> With the stabilization of gcc-6.4.0, the uclibc build broke because the
>> eclass requires UCLIBC_VER to be define on uclibc systems else it will
>> die().  Since uclibc specific patches are no longer needed in gcc-6 and
>> above, we don't want to error out in the eclass when the patchset is not
>> found.
>>
> 
> I'd guard this so it only applies to gcc-6 and later... for the simple reason 
> that 
> otherwise people will try to emerge some historical gcc versions and fail..

I don't think that's necessary because the ebuild is supposed to provide
a value of UCLIBC_VER if and only if a patchset is needed, and writing
the ebuild is up to us toolchain folks.  I can see the possibility of
upstream porting the fix to versions of gcc previous to 6 and then we'd
have to go back and hack away at the toolchain.eclass.

I'm planning to use the same logic for musl specific patches:  if
MUSL_VER is provided in the gcc ebuild, then there is a musl patchset to
be applied, otherwise there isn't.

This seems to be the cleanest approach without littering the eclass with
tc_version_is_at_least.

Comment?

> 
> Otherwise WFM
> 
> diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
> index 503f7dbe94f..58d859dfaf3 100644
> --- a/eclass/toolchain.eclass
> +++ b/eclass/toolchain.eclass
> @@ -378,9 +378,6 @@ toolchain_pkg_pretend() {
>   "in your make.conf if you want to use this 
> version."
>   fi
>  
> - [[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
> - die "Sorry, this version does not support uClibc"
> -
>   if ! use_if_iuse cxx ; then
>   use_if_iuse go && ewarn 'Go requires a C++ compiler, 
> disabled due to USE="-cxx"'
>   use_if_iuse objc++ && ewarn 'Obj-C++ requires a C++ 
> compiler, disabled due to USE="-cxx"'
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] Patch for toolchain.eclass for uclibc-ng

2017-11-25 Thread Anthony G. Basile
Hi everyone,

With the stabilization of gcc-6.4.0, the uclibc build broke because the
eclass requires UCLIBC_VER to be define on uclibc systems else it will
die().  Since uclibc specific patches are no longer needed in gcc-6 and
above, we don't want to error out in the eclass when the patchset is not
found.

Note that there are some musl specific patches which I would like to
migrate out of the overlay and into the tree.  In a future patch, I'd
like to duplicate the uclibc code for musl in toolchain.eclass.

Feedback welcome.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA
From 909298f47c98f698923c834f67e53bed3bc6ab25 Mon Sep 17 00:00:00 2001
From: "Anthony G. Basile" <bluen...@gentoo.org>
Date: Sat, 25 Nov 2017 08:47:41 -0500
Subject: [PATCH] eclass/toolchain.eclass: do not die if uclibc patches are not
 available

gcc-6 and above no longer needs uclibc specific patches, so we don't die if
the patchset is not available.  We do, however, still apply it if UCLIBC_VER
is defined in the ebuild to future proof the code in case we need to reintroduce
the patchset in the future.
---
 eclass/toolchain.eclass | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 503f7dbe94f..58d859dfaf3 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -378,9 +378,6 @@ toolchain_pkg_pretend() {
"in your make.conf if you want to use this version."
fi
 
-   [[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
-   die "Sorry, this version does not support uClibc"
-
if ! use_if_iuse cxx ; then
use_if_iuse go && ewarn 'Go requires a C++ compiler, disabled 
due to USE="-cxx"'
use_if_iuse objc++ && ewarn 'Obj-C++ requires a C++ compiler, 
disabled due to USE="-cxx"'
-- 
2.13.6



[gentoo-dev] Patch for toolchain.eclass for uclibc-ng

2017-11-25 Thread Anthony G. Basile

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA
From 909298f47c98f698923c834f67e53bed3bc6ab25 Mon Sep 17 00:00:00 2001
From: "Anthony G. Basile" <bluen...@gentoo.org>
Date: Sat, 25 Nov 2017 08:47:41 -0500
Subject: [PATCH] eclass/toolchain.eclass: do not die if uclibc patches are not
 available

gcc-6 and above no longer needs uclibc specific patches, so we don't die if
the patchset is not available.  We do, however, still apply it if UCLIBC_VER
is defined in the ebuild to future proof the code in case we need to reintroduce
the patchset in the future.
---
 eclass/toolchain.eclass | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 503f7dbe94f..58d859dfaf3 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -378,9 +378,6 @@ toolchain_pkg_pretend() {
"in your make.conf if you want to use this version."
fi
 
-   [[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
-   die "Sorry, this version does not support uClibc"
-
if ! use_if_iuse cxx ; then
use_if_iuse go && ewarn 'Go requires a C++ compiler, disabled 
due to USE="-cxx"'
use_if_iuse objc++ && ewarn 'Obj-C++ requires a C++ compiler, 
disabled due to USE="-cxx"'
-- 
2.13.6



Re: [gentoo-dev] PowerPC Resources at OSU

2017-09-12 Thread Anthony G. Basile
On 9/12/17 4:30 PM, James Le Cuirot wrote:
> On Mon, 11 Sep 2017 23:29:10 -0500
> R0b0t1 <r03...@gmail.com> wrote:
> 
>> 1) May I have access to a/the POWER server, or some other suitable
>> POWER resource? If not,
>> 2) is anyone available to verify that I am associated with the project
>> or that I will use the resources for project related work?
>>
>> My intent is to experiment with the PowerPC architecture, specifically
>> features found on newer POWER processors and servers. It is unlikely I
>> will ever get to do this on my own as the machines run $10k-$30k. I
>> requested services from OSU because GCC was not able to accommodate my
>> request for hypervisor access on their system.
>>
>> However, having finally found the resources I've been looking for this
>> whole time, it looks like OSU's nodes are virtualized and won't be
>> able to do exactly what I want anyway (i.e. the GCC sysadmin was
>> misinformed), so I may have accidentally wasted people's time and
>> potentially tarnished Gentoo's reputation. I will make amends as best
>> I can.
> 
> As of a few months ago, we have two POWER8 guests, one big endian
> (timberdoodle) and one little endian (bogsucker). We would just have
> one but you can't mix big and little endian on the same system.
> 
> After the old POWER7 timberdoodle died, I was responsible for creating
> these new instances with some help from prometheanfire. Replacing
> CentOS systems that had tied up all the storage from the other side of
> the world with no direct raw access was an interesting challenge!
> 
> I didn't intend to manage the systems long term though as I only use
> them for building and testing Java stuff. I consider prometheanfire,
> blueness, and vapier to be in charge though you may struggle getting
> hold of the latter two.
> 
> We generally only give access to devs but I am aware of one exception
> we made for gnu_andrew, who works for Red Hat and provides our icedtea
> ebuilds. Unfortunately I've only seen you on this list but hopefully
> someone can vouch for you. I don't know whether these guests will be
> suitable for your needs though.
> 

I've been using timberdoodle, but not bogsucker.  I haven't been
following this thread, but if its a question of maintaining those
machines, I can help out with that.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] [RFC] Update toolchain.eclass to deal with .xz compressed tarball for gcc-6.4.0

2017-08-02 Thread Anthony G. Basile
On 8/2/17 5:00 PM, Mike Gilbert wrote:
> On Wed, Aug 2, 2017 at 4:52 PM, Anthony G. Basile <bluen...@gentoo.org> wrote:
>> Hi everyone,
>>
>> Upstream gnu.org used to provide .gz and .bz2 compressed tarballs for
>> gcc's source code.  With gcc-6.4.0 however, they only provide .gz and
>> .xz.  Our toolchain.eclass is written only for .bz2.  I'd like to commit
>> the attached patch to deal with this change.  A better fix would
>> autodetect whether upstream has .bz2 or .xz but I'm not sure how to
>> proceed with that.
> 
> Another option would be to move the SRC_URI setting code into the
> individual ebuilds, instead of setting it in the eclass.
> 

I would still have problems with the unpack which I can't override.



Also, [Arfrever] on IRC suggested that instead of

if tc_version_is_between 6.4.0 7 ;  then

I use

if tc_version_is_between 5.5 6 || tc_version_is_between 6.4 7 ||
tc_version_is_at_least 7.2 ; then

to better future proof the code.  The assumption here being that gnu.org
will continue using .xz instead of .bz2 going forward which seems
reasonable.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] [RFC] Update toolchain.eclass to deal with .xz compressed tarball for gcc-6.4.0

2017-08-02 Thread Anthony G. Basile
Hi everyone,

Upstream gnu.org used to provide .gz and .bz2 compressed tarballs for
gcc's source code.  With gcc-6.4.0 however, they only provide .gz and
.xz.  Our toolchain.eclass is written only for .bz2.  I'd like to commit
the attached patch to deal with this change.  A better fix would
autodetect whether upstream has .bz2 or .xz but I'm not sure how to
proceed with that.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index db6e643148c..3114bd85832 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -320,7 +320,11 @@ get_gcc_src_uri() {
elif [[ -n ${SNAPSHOT} ]] ; then

GCC_SRC_URI="ftp://gcc.gnu.org/pub/gcc/snapshots/${SNAPSHOT}/gcc-${SNAPSHOT}.tar.bz2;
else
-   
GCC_SRC_URI="mirror://gnu/gcc/gcc-${GCC_PV}/gcc-${GCC_RELEASE_VER}.tar.bz2"
+   if tc_version_is_between 6.4.0 7 ;  then
+   
GCC_SRC_URI="mirror://gnu/gcc/gcc-${GCC_PV}/gcc-${GCC_RELEASE_VER}.tar.xz"
+   else
+   
GCC_SRC_URI="mirror://gnu/gcc/gcc-${GCC_PV}/gcc-${GCC_RELEASE_VER}.tar.bz2"
+   fi
# we want all branch updates to be against the main release
[[ -n ${BRANCH_UPDATE} ]] && \
GCC_SRC_URI+=" $(gentoo_urls 
gcc-${GCC_RELEASE_VER}-branch-update-${BRANCH_UPDATE}.patch.bz2)"
@@ -424,7 +428,11 @@ gcc_quick_unpack() {
elif [[ -n ${SNAPSHOT} ]] ; then
unpack gcc-${SNAPSHOT}.tar.bz2
elif [[ ${PV} != ** ]] ; then
-   unpack gcc-${GCC_RELEASE_VER}.tar.bz2
+   if tc_version_is_between 6.4.0 7 ;  then
+   unpack gcc-${GCC_RELEASE_VER}.tar.xz
+   else
+   unpack gcc-${GCC_RELEASE_VER}.tar.bz2
+   fi
# We want branch updates to be against a release tarball
if [[ -n ${BRANCH_UPDATE} ]] ; then
pushd "${S}" > /dev/null

Re: [gentoo-dev] The status of grsecurity upstream and hardened-sources downstream

2017-06-24 Thread Anthony G. Basile
On 6/24/17 6:04 AM, Alexis Ballier wrote:
> On Fri, 23 Jun 2017 12:28:27 -0400
> "Anthony G. Basile" <bluen...@gentoo.org> wrote:
> 
>> Hardened Gentoo has two sides to it, kernel hardening (done via
>> hardened-sources) and toolchain/executable hardening.  The two are
>> interrelated but independent enough that toolchain hardening can
>> continue on its own.  The hardened kernel, however, provided PaX
>> protection for executables and this will be lost.  We did a lot of
>> work to properly maintain PaX markings in our package management
>> system and there was no part of Gentoo that wasn't touched by issues
>> stemming from PaX support.
> 
> 
> Good luck to them at providing a complete userland ecosystem for using
> pax protection. Good luck at getting people accept and review their
> often crashing asm patches at upstream projects that won't even be able
> to test their benefits.
> 
> Maybe we should start a business for this ? :)
> http://static.sstic.org/videos2015/SSTIC_2015-06-03_P08_CLIP.mp4
> (This is for Patrice)

Correct.  Zorry, myself and others on the hardened team did a lot to
make userland play nice with the hardened-kernel.  It represents most of
my effort in Gentoo.

> 
> 
> 
> We'll need to decide what to do with things like USE=pic. For media
> packages this is not something you usually want to enable as you can
> bear the 10Mb relocations at startup to have 10% or more performance
> improvement when reading your 2hours long movie.

It will be a mess going forward.  We will necessarily have to start
dropping pax related stuff, if for no other reason than we can't support
making a package work under pax if we have no pax enabled kernel to test
on.  Once this is gone, such bugs will float upstream to pipacs and
spender.  "Good luck" is right.

> 
> 
> Alexis.
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] The status of grsecurity upstream and hardened-sources downstream

2017-06-23 Thread Anthony G. Basile
Hi everyone,

Since late April, grsecurity upstream has stop making their patches
available publicly.  Without going into details, the reason for their
decision revolves around disputes about how their patches were being
(ab)used.

Since the grsecurity patch formed the main core of our hardened-sources
kernel, their decision has serious repercussions for the Hardened Gentoo
project.  I will no longer be able to support hardened-sources and will
have to eventually mask and remove it from the tree.

Hardened Gentoo has two sides to it, kernel hardening (done via
hardened-sources) and toolchain/executable hardening.  The two are
interrelated but independent enough that toolchain hardening can
continue on its own.  The hardened kernel, however, provided PaX
protection for executables and this will be lost.  We did a lot of work
to properly maintain PaX markings in our package management system and
there was no part of Gentoo that wasn't touched by issues stemming from
PaX support.

I waited two months before saying anything because the reasons were more
of a political nature than some technical issue.  At this point, I think
its time to let the community know about the state of affairs with
hardened-sources.

I can no longer get into the #grsecurity/OFTC channel (nothing personal,
they kicked everyone), and so I have not spoken to spengler or pipacs.
I don't know if they will ever release grsecurity patches again.

My plan then is as follows.  I'll wait one more month and then send out
a news item and later mask hardened-sources for removal.  I don't
recommend we remove any of the machinery from Gentoo that deals with PaX
markings.

I welcome feedback.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Hardening a default profile

2017-06-15 Thread Anthony G. Basile
On 6/15/17 11:20 AM, Matthias Maier wrote:
> Hi Michael,
> 
> On Sun, Jun 11, 2017, at 16:39 CDT, Michael Brinkman 
> <thygreatswagged...@gmail.com> wrote:
> 
>> So I was just wondering if ~arch is ready for more secure defaults on
>> the 17.0 profiles in the linker flags.  There are several
>> distributions which ship RELRO by default and I am not aware of any
>> performance issues regarding this.
> 
> We (i.e. toolchain) are in the process of enabling quite a number of
> security hardening features on default profiles. In particular
> 
>  - (force) +pie +ssp for gcc-6 onwards in 17.0 profiles
> 

there should be a way of turning these off systematically.  the
advantage of the current hardened gcc specs is that one can switch
between them using gcc-config.  if these are forced on for the default
profile then there will be no easy way to systematically turn them off.

for those who don't used hardened, gcc-config -l on hardened profile gives:

 [1] x86_64-pc-linux-gnu-5.4.0 *
 [2] x86_64-pc-linux-gnu-5.4.0-hardenednopie
 [3] x86_64-pc-linux-gnu-5.4.0-hardenednopiessp
 [4] x86_64-pc-linux-gnu-5.4.0-hardenednossp
 [5] x86_64-pc-linux-gnu-5.4.0-vanilla

while on the default profiles it gives:

 [1] x86_64-pc-linux-gnu-5.4.0 *

[5] on the hardened profile is equivalent to [1] on the vanilla.

maybe we should consider merging the hardened and default profiles?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] Update to news item 2014-10-26-gcc_4_7_introduced_new_c++11_abi/2014-10-26-gcc_4_7_introduced_new_c++11_abi.en.txt

2017-06-04 Thread Anthony G. Basile
Hi everyone,

Kensington suggested updating the news item on the new c++11 abi for
gcc.  Since this news item now appears for all new installations of gcc
it can be annoying.  I'm proposing to change it as below, but I have one
concern.  It is important for anyone upgrading from gcc-4 to gcc-5.  But
if an upgrade to gcc-5 removes gcc-4, then the message won't show up
while it is still relevant.

Any suggestions on how to proceed?

index d074dbe..25f1712 100644
---
a/2014-10-26-gcc_4_7_introduced_new_c++11_abi/2014-10-26-gcc_4_7_introduced_new_c++11_abi.en.txt
+++
b/2014-10-26-gcc_4_7_introduced_new_c++11_abi/2014-10-26-gcc_4_7_introduced_new_c++11_abi.en.txt
@@ -2,9 +2,9 @@ Title: GCC 4.7 Introduced the New C++11 ABI
 Author: Anthony G. Basile <bluen...@gentoo.org>
 Content-Type: text/plain
 Posted: 2014-10-26
-Revision: 1
+Revision: 2
 News-Item-Format: 1.0
-Display-If-Installed: >=sys-devel/gcc-4.7.0
+Display-If-Installed: <=sys-devel/gcc-5
 Display-If-Keyword: amd64
 Display-If-Keyword: arm
 Display-If-Keyword: mips

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] Items for Council Agenda, June 11

2017-05-31 Thread Anthony G. Basile
Hi everyone,

The Gentoo Council will be meeting in two weeks.  If anyone has any
issues we need to discuss, please let me know and I'll put it on the
agenda.  Thanks.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-14 Thread Anthony G. Basile
On 5/14/17 6:38 AM, Michael Weber wrote:
> On 05/08/2017 09:13 PM, David Seifert wrote:
>> If all of this ends in one big bikeshedding fest again, I will start
>> dekeywording packages. Fortunately for me, I won't get any complaints
>> (because the arch teams are dead).
> formal complaint, powerpc team is alive, and I'm lead.
> 

I defer to the ppc lead's decision on this.  While I am okay with
dekeywording everything *but* @system for ppc, I prefer keeping ppc
keywords.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-11 Thread Anthony G. Basile
On 5/11/17 3:17 AM, Yury German wrote:
> David,
> 
> I never said anything about stablizing. But that is fine, thank you for
> the answers.
> 
> Blueness,
> 
> When are you proposing to making the changes. As we are about to drop
> sparc from security supported arches, so we might as well add PPC to the
> list.
> 
> On 5/10/17 11:50 PM, David Seifert wrote:
>> If there really is a dedicated team up
>> to the task and demonstrably active in keywording/stablereq'ing, we can
>> reconsider.
> 

Soap is working on the dekeywording.  I just jumped in because I wanted
to make sure we didn't break the catalyst runs for stage3's and he came
up with the dekeywording solution which I like.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-10 Thread Anthony G. Basile
On 5/10/17 3:29 PM, David Seifert wrote:
> On Wed, 2017-05-10 at 22:24 +0300, Mart Raudsepp wrote:
>> Ühel kenal päeval, K, 10.05.2017 kell 15:01, kirjutas Anthony G.
>> Basile:
>>> On 5/10/17 11:08 AM, William Hubbs wrote:
>>>> On Wed, May 10, 2017 at 10:04:54AM +0200, Dirkjan Ochtman wrote:
>>>>> On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile <blueness@gen
>>>>> to
>>>>> o.org> wrote:
>>>>>> I maintain quite a few ppc stage3's for uclibc and musl.  I
>>>>>> would
>>>>>> appreciate keeping ppc as is.  It is still a useful arch for
>>>>>> many
>>>>>> devices today, eg. some high end Mikrotik routers.
>>>>>
>>>>> So are you willing to do the work? There are currently 68 open
>>>>> keyword
>>>>> requests (oldest one reported in 2011) and 48 open stable
>>>>> requests
>>>>> (oldest one reported in November).
>>>>
>>>> +1000
>>>>
>>>> If we are going to keep ppc as a stable profile, someone needs to
>>>> do the
>>>> keywording and stabilization for it.
>>>>
>>>> William
>>>>
>>>
>>> the current plan by Soap et al is to drop all keywords except for
>>> @system and leave the profiles stable.  this works for me and
>>> addresses
>>> your concern.
>>
>> Are we talking about dropping all keywords besides @system things
>> from
>> ppc to ~ppc or completely?
>> I guess the latter as the former doesn't solve keywording lag?
>>
>>
>> Mart
>>
> 
> The latter, as that is the only way to restore sanity. I will be
> preparing a list.
> 

So let's make sure we're on the same page -- here's my understanding.

1) For @system packages, we will have KEYWORDS="ppc" for the stable
versions and KEYWORDS="~ppc" for the rest.

2) For non @system packages we will remove both ppc and ~ppc keywords.

3) If for some reason I need to add back a package to build/maintain
stage3/4, I will rekeyword myself, but other than that, we will *not*
balloon the keywords.

4) I will take on the responsibility of stabilizing ppc @system packages
if need be.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-10 Thread Anthony G. Basile
On 5/10/17 11:08 AM, William Hubbs wrote:
> On Wed, May 10, 2017 at 10:04:54AM +0200, Dirkjan Ochtman wrote:
>> On Tue, May 9, 2017 at 2:20 PM, Anthony G. Basile <bluen...@gentoo.org> 
>> wrote:
>>> I maintain quite a few ppc stage3's for uclibc and musl.  I would
>>> appreciate keeping ppc as is.  It is still a useful arch for many
>>> devices today, eg. some high end Mikrotik routers.
>>
>> So are you willing to do the work? There are currently 68 open keyword
>> requests (oldest one reported in 2011) and 48 open stable requests
>> (oldest one reported in November).
> 
> +1000
> 
> If we are going to keep ppc as a stable profile, someone needs to do the
> keywording and stabilization for it.
> 
> William
> 

the current plan by Soap et al is to drop all keywords except for
@system and leave the profiles stable.  this works for me and addresses
your concern.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-09 Thread Anthony G. Basile
On 5/9/17 8:33 AM, Michael Orlitzky wrote:
> On 05/09/2017 04:12 AM, Rich Freeman wrote:
>> On Tue, May 9, 2017 at 12:23 AM, Yury German <bluekni...@gentoo.org> wrote:
>>>
>>> we can not call for cleanup or release the GLSA,
>>> waiting for a stabilization of a non-core package, while the actual
>>> package has been in a tree in ~arch status for weeks or months.
>>
>> Why not?  If an arch is considered a non-security-supported arch then
>> you would just ignore it in a security bug.
>>
> 
> For example, I can't remove the ancient and vulnerable nagios-3.5.1
> because an alternative is missing keywords:
> 
>   https://bugs.gentoo.org/show_bug.cgi?id=605724
> 
> If I drop nagios-3.5.1 without the keywords, pnp4nagios breaks.
> 
> 

Perhaps I'm missing the issue, but can you just follow the dependencies
and drop keywords accordingly so the tree remains consistent.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

2017-05-09 Thread Anthony G. Basile
On 5/9/17 8:01 AM, Thomas Deutschmann wrote:
> On 2017-05-09 10:12, Rich Freeman wrote:
>> Why not?  If an arch is considered a non-security-supported arch
>> then you would just ignore it in a security bug.
> 
> We dropped security coverage already for ia64 and are in the process to
> drop it for sparc as well.
> 
> So how do you want to cleanup a package which is the last ebuild of the
> package and still marked stabled for ia64/sparc? You cannot. If you are
> lucky you would only remove a package without any rdeps. But in most
> cases you are breaking the tree.
> 
> 
>> Otherwise a revbump could break stage3 on those arches.
> 
> Is this really a problem? What could happen:
> 
> Worst case: Existing stage3 for this specific dev/exp architecture will
> be very old because any attempt to refresh the stage3 image will fail
> with a build error. However, the last working stage3 image won't go away
> until it was replaced by a newer working one...
> 

I maintain quite a few ppc stage3's for uclibc and musl.  I would
appreciate keeping ppc as is.  It is still a useful arch for many
devices today, eg. some high end Mikrotik routers.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-portage-dev] [PATCH] file_copy: replace loff_t with off_t for portability (bug 617778)

2017-05-08 Thread Anthony G. Basile
On 5/7/17 7:50 PM, Zac Medico wrote:
> The loff_t type is a GNU extension, so use the portable off_t
> type instead. Also, enable Large File Support macros in setup.py,
> for 64-bit offsets.
>
> Reported-by: Patrick Steinhardt <p...@pks.im>
> X-Gentoo-bug: 617778
> X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=617778
> ---
>  setup.py   | 5 -
>  src/portage_util_file_copy_reflink_linux.c | 6 +++---
>  2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/setup.py b/setup.py
> index e993177..1ba6f87 100755
> --- a/setup.py
> +++ b/setup.py
> @@ -676,7 +676,10 @@ setup(
>   ['$sysconfdir/portage/repo.postsync.d', 
> ['cnf/repo.postsync.d/example']],
>   ],
>  
> - ext_modules = [Extension(name=n, sources=m) for n, m in 
> x_c_helpers.items()],
> + ext_modules = [Extension(name=n, sources=m,
> + extra_compile_args=['-D_FILE_OFFSET_BITS=64',
> + '-D_LARGEFILE_SOURCE', '-D_LARGEFILE64_SOURCE'])
> + for n, m in x_c_helpers.items()],
>  
>   cmdclass = {
>   'build': x_build,
> diff --git a/src/portage_util_file_copy_reflink_linux.c 
> b/src/portage_util_file_copy_reflink_linux.c
> index b031d96..2fb17a0 100644
> --- a/src/portage_util_file_copy_reflink_linux.c
> +++ b/src/portage_util_file_copy_reflink_linux.c
> @@ -66,7 +66,7 @@ initreflink_linux(void)
>   * (errno is set appropriately).
>   */
>  static ssize_t
> -cfr_wrapper(int fd_out, int fd_in, loff_t *off_out, size_t len)
> +cfr_wrapper(int fd_out, int fd_in, off_t *off_out, size_t len)
>  {
>  #ifdef __NR_copy_file_range
>  return syscall(__NR_copy_file_range, fd_in, NULL, fd_out,
> @@ -96,7 +96,7 @@ cfr_wrapper(int fd_out, int fd_in, loff_t *off_out, size_t 
> len)
>   * reaches EOF.
>   */
>  static off_t
> -do_lseek_data(int fd_out, int fd_in, loff_t *off_out) {
> +do_lseek_data(int fd_out, int fd_in, off_t *off_out) {
>  #ifdef SEEK_DATA
>  /* Use lseek SEEK_DATA/SEEK_HOLE for sparse file support,
>   * as suggested in the copy_file_range man page.
> @@ -189,7 +189,7 @@ _reflink_linux_file_copy(PyObject *self, PyObject *args)
>  ssize_t buf_bytes, buf_offset, copyfunc_ret;
>  struct stat stat_in, stat_out;
>  char* buf;
> -ssize_t (*copyfunc)(int, int, loff_t *, size_t);
> +ssize_t (*copyfunc)(int, int, off_t *, size_t);
>  
>  if (!PyArg_ParseTuple(args, "ii", _in, _out))
>  return NULL;

This looks good to me.  I tested it on amd64 and it works fine.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bas...@freeharbor.net
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA




Re: [gentoo-dev] Packages up for grabs

2017-03-26 Thread Anthony G. Basile
On 3/26/17 3:50 PM, aide...@gentoo.org wrote:

>   app-crypt/md5deep

I'll take this.  I use it in hashing stage3's and tar'ed systems I push out.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

2017-03-11 Thread Anthony G. Basile
On 3/11/17 3:13 PM, Peter Stuge wrote:
> 
> All lines containing +knots should say knots instead.
> 

Done.


I'm getting increasingly unsatisfied with where bitcoins* is going.  I
think I'd like to take full ownership of it and remove all unnecessary
patches.  If there's anyone that wants to co-maintain it with me, I'd
welcome the help.  I'm busy until summer at which time I revisit the
issue and try to clean up the eclass and ebuilds.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

2017-03-08 Thread Anthony G. Basile
On 3/7/17 12:18 PM, Peter Stuge wrote:
> Anthony G. Basile wrote:
>> I proxy maintain bitcoins for luke-jr.  He wants to propose a patch
>> against the bitcoin eclass.  The following is his proposed change.
>> I'll commit it after review.
> 
> Please do not do that, Anthony.
> 

I don't have time nor the familiarity to properly maintain bitcoins
myself.  Every time Luke wants to make a change, I get nothing but
negative advice - what not to do, but not what to do.  If there were an
unpopular package I would just drop it to maintainer-needed.  But do we
really want a distro that doesn't provide bitcoins?

I will ignore all negative advice regarding this package unless it is
balanced with positive advice.  Please point out what lines of the patch
should be changed and what they should be changed to, else I will commit
the patch as provided.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] RFC: Update bitcoin eclass to default to knots

2017-03-06 Thread Anthony G. Basile
Hi everyone,

I proxy maintain bitcoins for luke-jr.  He wants to propose a patch
against the bitcoin eclass.  The following is his proposed change.  I'll
commit it after review.

--Tony


Bitcoin Knots includes a number of enhancements users may find useful. I
think  it would be a good idea to make it the default for Bitcoin
ebuilds (net-p2p/bitcoin-qt, net-p2p/bitcoind, and dev-util/bitcoin-tx).

Note that:
- The USE flag is being renamed from the old "ljr" to "knots" to reflect
the current naming.
- This does NOT enable the historically-controversial spamfilte 
BITCOIN_POLICY.
- Knots has since 0.12 (over a year old) included a clearly different
splash   screen and branding, so even if the user somehow misses the USE
flag change   and explicit src_prepare warning, it is clear upfront at
startup and runtime   that they are running Knots rather than Core.
- Old ebuilds are not being updated to minimise impact.

A patch against the current Portage tree is attached.

A bug tracker for this has been open for 2 months with no objections:
https://bugs.gentoo.org/show_bug.cgi?id=604520

If there are no objections in the next week, we will move forward with 
deploying this change to the main Portage tree.

Please CC me on any replies, as I am not presently subscribed to the
mailing  list.

Thanks,

Luke

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bas...@freeharbor.net
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

diff --git a/dev-util/bitcoin-tx/bitcoin-tx-0.13.2.ebuild 
b/dev-util/bitcoin-tx/bitcoin-tx-0.13.2.ebuild
index ea538a2..1d56874 100644
--- a/dev-util/bitcoin-tx/bitcoin-tx-0.13.2.ebuild
+++ b/dev-util/bitcoin-tx/bitcoin-tx-0.13.2.ebuild
@@ -5,7 +5,7 @@ EAPI=5
 
 BITCOINCORE_COMMITHASH="0d719145b018e28d48d35c2646a5962b87c60436"
 BITCOINCORE_LJR_DATE="20170102"
-BITCOINCORE_IUSE="ljr"
+BITCOINCORE_IUSE="+knots"
 BITCOINCORE_NEED_LIBSECP256K1=1
 BITCOINCORE_NO_DEPEND="libevent"
 inherit bitcoincore
diff --git a/dev-util/bitcoin-tx/metadata.xml b/dev-util/bitcoin-tx/metadata.xml
index a686a21..16e544a 100644
--- a/dev-util/bitcoin-tx/metadata.xml
+++ b/dev-util/bitcoin-tx/metadata.xml
@@ -10,6 +10,7 @@
Luke Dashjr


+   Build enhanced Bitcoin Knots version, rather 
than Bitcoin Core
Enable Luke Dashjr's patches


diff --git a/eclass/bitcoincore.eclass b/eclass/bitcoincore.eclass
index 74cb2a3..6144fb8 100644
--- a/eclass/bitcoincore.eclass
+++ b/eclass/bitcoincore.eclass
@@ -37,7 +37,7 @@ fi
 
 EXPORT_FUNCTIONS src_prepare src_test src_install
 
-if in_bcc_iuse ljr || in_bcc_iuse 1stclassmsg || in_bcc_iuse zeromq || [ -n 
"$BITCOINCORE_POLICY_PATCHES" ]; then
+if in_bcc_iuse ljr || in_bcc_iuse knots || in_bcc_iuse 1stclassmsg || 
in_bcc_iuse zeromq || [ -n "$BITCOINCORE_POLICY_PATCHES" ]; then
EXPORT_FUNCTIONS pkg_pretend
 fi
 
@@ -53,7 +53,7 @@ if [[ ! ${_BITCOINCORE_ECLASS} ]]; then
 
 # @ECLASS-VARIABLE: BITCOINCORE_LJR_DATE
 # @DESCRIPTION:
-# Set this variable before the inherit line, to the datestamp of the ljr
+# Set this variable before the inherit line, to the datestamp of the Knots
 # patchset.
 
 # @ECLASS-VARIABLE: BITCOINCORE_POLICY_PATCHES
@@ -72,6 +72,7 @@ WALLET_DEPEND="sys-libs/db:$(db_ver_to_slot "${DB_VER}")[cxx]"
 LIBEVENT_DEPEND=""
 UNIVALUE_DEPEND=""
 BITCOINCORE_LJR_NAME=ljr
+BITCOINCORE_KNOTS_USE=knots
 [ -n "${BITCOINCORE_LJR_PV}" ] || BITCOINCORE_LJR_PV="${PV}"
 
 case "${PV}" in
@@ -87,8 +88,11 @@ case "${PV}" in
LIBSECP256K1_DEPEND="=dev-libs/libsecp256k1-0.0.0_pre20151118[recovery]"
UNIVALUE_DEPEND="dev-libs/univalue"
BITCOINCORE_LJR_NAME=knots
+   if in_bcc_iuse ljr; then
+   BITCOINCORE_KNOTS_USE=ljr
+   fi
if in_bcc_policy spamfilter; then
-   REQUIRED_USE="${REQUIRED_USE} bitcoin_policy_spamfilter? ( ljr 
)"
+   REQUIRED_USE="${REQUIRED_USE} bitcoin_policy_spamfilter? ( 
${BITCOINCORE_KNOTS_USE} )"
fi
;;
 *)
@@ -201,9 +205,9 @@ DEPEND="${DEPEND} ${BITCOINCORE_COMMON_DEPEND}
 if [ "${BITCOINCORE_NEED_LEVELDB}" = "1" ]; then
RDEPEND="${RDEPEND} virtual/bitcoin-leveldb"
 fi
-if in_bcc_iuse ljr; then
+if in_bcc_iuse ${BITCOINCORE_KNOTS_USE}; then
if [ "${BITCOINCORE_LJR_NAME}" = "knots" ]; then
-   DEPEND="${DEPEND} ljr? ( dev-lang/perl )"
+   DEPEND="${DEPEND} ${BITCOINCORE_KNOTS_USE}? ( dev-lang/perl )"
fi
 fi
 
@@ -220,7 +224,7 @@ bitcoincore_policymsg() {
 
 bitcoincore_pkg_pretend() {
bitcoincore_policymsg_flag=false
-   if use_if_iuse ljr || use_if_iuse 1stclassmsg || use_i

Re: [gentoo-dev] News item for uclibc-ng

2017-02-08 Thread Anthony G. Basile
On 2/8/17 3:23 PM, Andrey Utkin wrote:
> On Wed, Feb 08, 2017 at 02:37:52PM -0500, Anthony G. Basile wrote:
>> Hi everyone,
>>
>> Attached you'll find a news item for uclibc-ng.  I'd like to push it out
>> in a few days.
>>
> 
>> This will make sure all executables link directly against libc.so.0 (as
>> reported by `readelf -d`) rather than via sym links like libdl.so.0 ->
>> libc.so.0.  Then upgrade from 1.0.19 to 1.0.20 without symlink-combat:
>>
>> USE=“-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20
> 
> First quote sign is non-ascii so command doesn't work when copy-pasted
> to terminal.
> 

Thanks, I wrote this on my mac which does things like that.  Is there a
good utility for catching non-ascii chars?

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] News item for uclibc-ng

2017-02-08 Thread Anthony G. Basile
Hi everyone,

Attached you'll find a news item for uclibc-ng.  I'd like to push it out
in a few days.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA
Title: Upgrade to =sys-libs/uclibc-ng-1.0.22
Author: Anthony G. Basile <bluen...@gentoo.org>
Content-Type: text/plain
Posted: 2017-02-10
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-libs/uclibc-ng
Display-If-Profile: default/linux/uclibc/amd64
Display-If-Profile: hardened/linux/uclibc/amd64
Display-If-Profile: default/linux/uclibc/arm/armv7a
Display-If-Profile: hardened/linux/uclibc/arm/armv7a
Display-If-Profile: default/linux/uclibc/mips
Display-If-Profile: hardened/linux/uclibc/mips
Display-If-Profile: default/linux/uclibc/mips/mipsel
Display-If-Profile: hardened/linux/uclibc/mips/mipsel
Display-If-Profile: default/linux/uclibc/ppc
Display-If-Profile: hardened/linux/uclibc/ppc
Display-If-Profile: default/linux/uclibc/x86
Display-If-Profile: hardened/linux/uclibc/x86

There have been two major changes in uclibc-ng which need special
attention when upgrading. Version 1.0.19 restructured the breakout
libraries, libcrypt.so.0, libdl.so.0, and friends.  The functions in
those libraries are now included in libuClibc-0.1.0.19.so.  Version
1.0.21 and above removed libc support for obstack, expecting packages to
use their bundled GNU lib code. Both changes require special upgrade
procedures which we outline below: 

0. Because of changes in the library structure in previous versions,
make sure you are working with 1.0.19 and rebuild world using

emerge -evq @world

This will make sure all executables link directly against libc.so.0 (as
reported by `readelf -d`) rather than via sym links like libdl.so.0 ->
libc.so.0.  Then upgrade from 1.0.19 to 1.0.20 without symlink-combat:

USE=“-symlink-compat" emerge =sys-libs/uclibc-ng-1.0.20

1. Get rid of the obstack.h header since its used by configure scripts
to look for function prototypes and macros.

mv /usr/include/obstack.h ~

2. We also need to force the use of any bundled gnu lib code.  We can do
this by removing the definition of _GNU_OBSTACK_INTERFACE_VERSION from
gnu-version.h

cp /usr/include/gnu-versions.h ~
sed -i -e '/#define _GNU_OBSTACK/d' /usr/include/gnu-versions.h

3. We need to tell stdio.h that __UCLIBC_HAS_OBSTACK__ is false.  We do
this via the uClibc_config.h file.

cp /usr/include/bits/uClibc_config.h ~
sed -i -e '/__UCLIBC_HAS_OBSTACK__/ s/1/0/' \
 /usr/include/bits/uClibc_config.h

4. To be safe, you may want to back up your entire /lib directory so
you can fall back should something go wrong:

cp -a /lib /lib.bak

5. Now when we rebuild @world, all packages will use their bundled
obstack code rather than depending on libc to provide it.

ac_cv_func_obstack_vprintf=no emerge --keep-going --exclude \
 sys-libs/uclibc-ng -evq @world

6. Finally updated uclibc-ng to the latest

emerge =sys-libs/uclibc-ng-1.0.22

7. For good measure, rebuild the entire system

emerge —evq @world



Re: [gentoo-dev] Unused profiles

2017-01-22 Thread Anthony G. Basile
On 1/22/17 3:41 PM, Michał Górny wrote:
>
>>>> uclibc/amd64
>>>> uclibc/arm/2.4
>>>> uclibc/mips/hardened
>>>> uclibc/ppc/2.4
>>>> uclibc/ppc/hardened/2.4
>>>> uclibc/sh/2.4
>>>> uclibc/x86/2.4
>>>> uclibc/x86/2005.1/2.4
>>>> uclibc/x86/hardened/2.4  
>> I'm still not sure if anyone uses these.  I'm thinking maybe its time
>> for the whole lot of profiles/uclibc/* to go.
> If you need me to, I can look into inlining them into
> default/linux/uclibc.
>

I don't know what you mean by "inlining" them but I'd rather not mix
them in.  I'd rather they were just removed or whoever is using them
take care of them.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bas...@freeharbor.net
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA




Re: [gentoo-dev] Unused profiles

2017-01-22 Thread Anthony G. Basile
On 1/19/17 8:25 PM, Anthony G. Basile wrote:
> Michal,

I had a chance to look over this carefully and here's what I got:

>> default/linux/mips/13.0/desktop
>> default/linux/mips/13.0/developer
>> default/linux/mips/13.0/mipsel/desktop
>> default/linux/mips/13.0/mipsel/developer
>> default/linux/mips/13.0/mipsel/multilib
>> default/linux/mips/13.0/mipsel/n32/desktop
>> default/linux/mips/13.0/mipsel/n32/developer
>> default/linux/mips/13.0/mipsel/n64/desktop
>> default/linux/mips/13.0/mipsel/n64/developer
>> default/linux/mips/13.0/mipsel/o32/desktop
>> default/linux/mips/13.0/mipsel/o32/developer
>> default/linux/mips/13.0/multilib
>> default/linux/mips/13.0/n32/desktop
>> default/linux/mips/13.0/n32/developer
>> default/linux/mips/13.0/n64/desktop
>> default/linux/mips/13.0/n64/developer
>> default/linux/mips/13.0/o32/desktop
>> default/linux/mips/13.0/o32/developer

These can all go. Do you want to drop a deprecated notice in them?  Or
shall I?

> 
>> default/linux/powerpc/ppc64/13.0/desktop/gnome/systemd
>> default/linux/powerpc/ppc64/13.0/desktop/kde/systemd
>> default/linux/powerpc/ppc64/13.0/developer
> 
> I think these can go.

The systemd folks added the */systemd.  I don't care to keep them but
they might.  */developer can definitely go.

>> hardened/linux/arm/armv4
>> hardened/linux/arm/armv4t
>> hardened/linux/arm/armv5te
>> hardened/linux/arm/armv7a/selinux

These can go.

>> hardened/linux/mips/mipsel/multilib/n32
>> hardened/linux/mips/mipsel/multilib/n64
>> hardened/linux/mips/mipsel/n32
>> hardened/linux/mips/mipsel/n64
>> hardened/linux/mips/multilib/n32
>> hardened/linux/mips/multilib/n64
>> hardened/linux/mips/n32
>> hardened/linux/mips/n64

These are the only ones I had to add to profiles.desc.  I need them for
the lemote support.

>> hardened/linux/uclibc/arm/armv6j

This can go.

>> uclibc/amd64
>> uclibc/arm/2.4
>> uclibc/mips/hardened
>> uclibc/ppc/2.4
>> uclibc/ppc/hardened/2.4
>> uclibc/sh/2.4
>> uclibc/x86/2.4
>> uclibc/x86/2005.1/2.4
>> uclibc/x86/hardened/2.4

I'm still not sure if anyone uses these.  I'm thinking maybe its time
for the whole lot of profiles/uclibc/* to go.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Unused profiles

2017-01-19 Thread Anthony G. Basile
Michal,

I'll look at all of the following ones over the weekend and get back to
you but here's my 2 cents:

> default/linux/mips/13.0/desktop
> default/linux/mips/13.0/developer
> default/linux/mips/13.0/mipsel/desktop
> default/linux/mips/13.0/mipsel/developer
> default/linux/mips/13.0/mipsel/multilib
> default/linux/mips/13.0/mipsel/n32/desktop
> default/linux/mips/13.0/mipsel/n32/developer
> default/linux/mips/13.0/mipsel/n64/desktop
> default/linux/mips/13.0/mipsel/n64/developer
> default/linux/mips/13.0/mipsel/o32/desktop
> default/linux/mips/13.0/mipsel/o32/developer
> default/linux/mips/13.0/multilib
> default/linux/mips/13.0/n32/desktop
> default/linux/mips/13.0/n32/developer
> default/linux/mips/13.0/n64/desktop
> default/linux/mips/13.0/n64/developer
> default/linux/mips/13.0/o32/desktop
> default/linux/mips/13.0/o32/developer

I think all of these can go except the multilib ones which can go into
profiles.desc.

> default/linux/powerpc/ppc64/13.0/desktop/gnome/systemd
> default/linux/powerpc/ppc64/13.0/desktop/kde/systemd
> default/linux/powerpc/ppc64/13.0/developer

I think these can go.


> hardened/linux/arm/armv4
> hardened/linux/arm/armv4t
> hardened/linux/arm/armv5te
> hardened/linux/arm/armv7a/selinux
> hardened/linux/mips/mipsel/multilib/n32
> hardened/linux/mips/mipsel/multilib/n64
> hardened/linux/mips/mipsel/n32
> hardened/linux/mips/mipsel/n64
> hardened/linux/mips/multilib/n32
> hardened/linux/mips/multilib/n64
> hardened/linux/mips/n32
> hardened/linux/mips/n64
> hardened/linux/uclibc/arm/armv6j

I think the arm can go but not the mips.  I'll verify and add those to
profiles.desc.


> uclibc/amd64
> uclibc/arm/2.4
> uclibc/mips/hardened
> uclibc/ppc/2.4
> uclibc/ppc/hardened/2.4
> uclibc/sh/2.4
> uclibc/x86/2.4
> uclibc/x86/2005.1/2.4
> uclibc/x86/hardened/2.4
> 

These can go except maybe uclibc/amd64.  FYI, I do not use
profiles/uclibc for my stuff but profiles/default/linux/uclibc.  However
there may be some people still using these older profiles, else I'd say
kill all of profiles/uclibc.

Also, we should just drop a deprecated file into these profiles for now
and wait a year before removing them from the tree.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] RFC: global USE c++11

2017-01-03 Thread Anthony G. Basile
On 1/3/17 4:08 AM, Justin  wrote:
> On 03/01/2017 08:51, Kristian Fiskerstrand wrote:
>> On 01/02/2017 10:34 PM, Justin  wrote:
>>>
>>> Seems to be very consistent in usage.
>>
>> But I'm not convinced it is a correct approach to have use flag changing
>> this. First thing that springs to mind is if introducing something like
>> that it should be done consistently across Gentoo, so a GLEP. But
>> presumably a lot of packages are already built using C++11 without a use
>> flag given Qt5.7 requiring it etc.
>>
>> If using C++11 enables different features the feature should be the use
>> flag rather than C++11. Couldn't this just be determined using Autotools
>> etc? What is the gain of the use flag? Immediately it sounds like it
>> adds complexity without much gain.
>>
> 
> I tried to find some example usages from upstream. Two things I found
> 
> * Most upstreams dropped the flag in recent versions
> * If present, it is used to append -std=c++11
> 
> Probably we should keep it local and wait until it is gone everywhere
> upstream.
> 
> Justin
> 

Agreed.  Keep it local.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] RFC: global USE c++11

2017-01-02 Thread Anthony G. Basile
On 1/2/17 4:34 PM, Justin  wrote:
> Hi all
> 
> How about making USE="c++11" a global USE?
> 
> Description: Build using the C++11 standard.
> 
> Current situation:
> sci-libs/dealii: Compile the library with -std=c++11
> sci-physics/herwig++: Build Herwig++ using the C++11 standard.
> sci-astronomy/casacore: Build casacore using the C++11 standard
> sci-libs/ceres-solver: Build ceres-solver using the C++11 standard
> sci-physics/herwig++: Build Herwig++ using the C++11 standard.
> sci-physics/root: Build ROOT using the C++11 standard
> sci-physics/thepeg: Build ThePEG using the C++11 standard.
> sci-physics/yoda: Build using the C++11 standard
> 
> 
> Seems to be very consistent in usage.
> 
> Best,
> Justin
> 

You really shouldn't start mixing different c++ abis, that's just asking
for trouble.  Since I'm not sure why the flag is there in those pkgs, I
feel uneasy about making it a global flag.  See

https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Changes in toolchain.eclass to enable Ada

2016-12-22 Thread Anthony G. Basile
On 12/22/16 3:11 PM, Michał Górny wrote:
> On Thu, 22 Dec 2016 14:55:05 +0100
> Alfredo Tupone <tup...@gentoo.org> wrote:
> 
>>>> I would like to start including, in the gentoo tree, GNAT-GPL
>>>> built in the same way as sys-devel-gcc and selectable with gcc-config  
>>>
>>> 1. Does this mean that GNAT-GPL build will include building a C
>>> compiler? If yes, will the C compiler be installed?  
>> Yes, a C and a C++ compiler, and they will be installed
>>>
>>> 2. Will it be possible to combine GNAT-GPL with a different version of
>>> regular gcc C/C++ compilers?  
>> No, not easily
> 
> To be honest, I don't like this at all. This sounds like doubling
> the effort on maintaining gcc, and it sounds like people using GNAT-GPL
> would end up being forced to use old versions of GCC (also possibly
> missing patches).
> 
> If the Ada compiler requires Ada to boostrap anyway, can't you just
> make it build the Ada compiler alone?
> 

Yeah, I agree.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] For review: News item "Deprecation of sys-libs/uclibc and migration to sys-libs/uclibc-ng"

2016-09-24 Thread Anthony G. Basile
On 9/24/16 1:34 PM, waltd...@waltdnes.org wrote:
> On Sat, Sep 24, 2016 at 10:42:27AM -0400, Anthony G. Basile wrote
>> Hi everyone,
>>
>> I'd like to commit the following news item in a couple of days.
>> I'm sending it as an attachment so hopefully it'll come across
>> exactly as I will commit it.
>>
>> Please review. Thanks.
> 
>   Glad to hear.  Which mailing list(s) should users subscribe to for
> questions, etc?
> 

gentoo-embed...@lists.gentoo.org

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] For review: News item "Deprecation of sys-libs/uclibc and migration to sys-libs/uclibc-ng"

2016-09-24 Thread Anthony G. Basile
On 9/24/16 11:45 AM, Mike Gilbert wrote:
> On Sat, Sep 24, 2016 at 10:42 AM, Anthony G. Basile <bluen...@gentoo.org> 
> wrote:
>> Hi everyone,
>>
>> I'd like to commit the following news item in a couple of days.  I'm
>> sending it as an attachment so hopefully it'll come across exactly as I
>> will commit it.
>>
>> Please review. Thanks.
> 
> GLEP 42 says Title should be 50 characters or less, and the body
> should be wrapped at 72 characters.
> 

Thanks, I did title < 72 and body wrapping at 80.  Let me get other
critiques first and I'll post an updated version.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] For review: News item "Deprecation of sys-libs/uclibc and migration to sys-libs/uclibc-ng"

2016-09-24 Thread Anthony G. Basile
Hi everyone,

I'd like to commit the following news item in a couple of days.  I'm
sending it as an attachment so hopefully it'll come across exactly as I
will commit it.

Please review. Thanks.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA
Title: Deprecation of sys-libs/uclibc and migration to sys-libs/uclibc-ng
Author: Anthony G. Basile <bluen...@gentoo.org>
Content-Type: text/plain
Posted: 2016-09-26
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: sys-libs/uclibc
Display-If-Profile: default/linux/uclibc/amd64
Display-If-Profile: hardened/linux/uclibc/amd64
Display-If-Profile: default/linux/uclibc/arm/armv7a
Display-If-Profile: hardened/linux/uclibc/arm/armv7a
Display-If-Profile: default/linux/uclibc/mips
Display-If-Profile: hardened/linux/uclibc/mips
Display-If-Profile: default/linux/uclibc/mips/mipsel
Display-If-Profile: hardened/linux/uclibc/mips/mipsel
Display-If-Profile: default/linux/uclibc/ppc
Display-If-Profile: hardened/linux/uclibc/ppc
Display-If-Profile: default/linux/uclibc/x86
Display-If-Profile: hardened/linux/uclibc/x86

Upstream development of uClibc has been stalled since July 2015 and there hasn't
been a proper release since May 2012 [1].  New patches addressing important
issues have been submitted but these have not been reviewed nor have they been
committed to the master branch.  Furthermore, backporting even those patches
which have been committed to master is now impractical as too many intermediate
layers of patches conflict.  For all intents and purposes, upstream uClibc is
dead.

Fortunately, a fork called uClibc-ng [2] was begun by Waldemar Brodkorb in
February 2015 and is actively being maintained.  Accordingly, Gentoo's Hardened
uClibc project will be migrating to uClibc-ng as its libc provider.  Currently
stage3 tarballs based on sys-libs/uclibc-ng are available for all supported
arches at [3] and these will become the default after October 5, 2016.  Older
stage3s based on sys-libs/uclibc will be removed.

Unfortunately, migrating a production system from uclibc to uclibc-ng is not
straightforward owing to the central role played by libc.  A migration guide
is provided at [4].  This has been tested on live systems with success, but
the user is cautioned to plan a backup and recovery plan should something go
wrong.

Refs.
[1] https://git.uclibc.org/uClibc/log/
[2] http://uclibc-ng.org/
[3] http://distfiles.gentoo.org/experimental/
[4] https://wiki.gentoo.org/wiki/Project:Hardened_uClibc#Migration_to_uClibc-ng


[gentoo-portage-dev] Resending patchset for C module to help check locale

2016-09-14 Thread Anthony G. Basile
As per Brian's request on IRC, here's the patchset for adding a C module
to help check locales.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197
From 76131d44e1731c876840e7925ccff2468ea157a7 Mon Sep 17 00:00:00 2001
From: "Anthony G. Basile" <bluen...@gentoo.org>
Date: Wed, 25 May 2016 08:48:32 -0400
Subject: [PATCH 1/3] pym/portage/util/locale.py: fix decoding for python2 plus
 some locales

When using python2 with some locales, like turkish, chr() is passed values not 
in
range(128) which cannot be decoded as ASCII, thus throwing a UnicodeDecodeError
exception.  We use _unicode_decode() from portage.util to address this.

Signed-off-by: Anthony G. Basile <bluen...@gentoo.org>
---
 pym/portage/util/locale.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/pym/portage/util/locale.py b/pym/portage/util/locale.py
index 2a15ea1..093eb86 100644
--- a/pym/portage/util/locale.py
+++ b/pym/portage/util/locale.py
@@ -15,7 +15,7 @@ import textwrap
 import traceback
 
 import portage
-from portage.util import writemsg_level
+from portage.util import _unicode_decode, writemsg_level
 from portage.util._ctypes import find_library, LoadLibrary
 
 
@@ -62,7 +62,7 @@ def _check_locale(silent):
"as LC_CTYPE in make.conf.")
msg = [l for l in textwrap.wrap(msg, 70)]
msg.append("")
-   chars = lambda l: ''.join(chr(x) for x in l)
+   chars = lambda l: ''.join(_unicode_decode(chr(x)) for x in l)
if uc != ruc:
msg.extend([
"  %s -> %s" % (chars(lc), chars(ruc)),
-- 
2.7.3

From 831af672827380a928e8e07c3fb5ecd01545e3c9 Mon Sep 17 00:00:00 2001
From: "Anthony G. Basile" <bluen...@gentoo.org>
Date: Thu, 19 May 2016 06:52:43 -0400
Subject: [PATCH 2/3] setup.py: add stub for building custom modules in C/C++

Currently portage doesn't include any custom modules written in C/C++.
This commit introduces stub code for building such modules in setup.py.

Signed-off-by: Anthony G. Basile <bluen...@gentoo.org>
---
 setup.py | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/setup.py b/setup.py
index 2220d23..8d20355 100755
--- a/setup.py
+++ b/setup.py
@@ -4,7 +4,7 @@
 
 from __future__ import print_function
 
-from distutils.core import setup, Command
+from distutils.core import setup, Command, Extension
 from distutils.command.build import build
 from distutils.command.build_scripts import build_scripts
 from distutils.command.clean import clean
@@ -30,6 +30,9 @@ import sys
 # TODO:
 # - smarter rebuilds of docs w/ 'install_docbook' and 'install_epydoc'.
 
+# Dictionary of scripts.  The structure is
+#   key   = location in filesystem to install the scripts
+#   value = list of scripts, path relative to top source directory
 x_scripts = {
'bin': [
'bin/ebuild', 'bin/egencache', 'bin/emerge', 
'bin/emerge-webrsync',
@@ -41,6 +44,10 @@ x_scripts = {
],
 }
 
+# Dictionary custom modules written in C/C++ here.  The structure is
+#   key   = module name
+#   value = list of C/C++ source code, path relative to top source directory
+x_c_helpers = {}
 
 class x_build(build):
""" Build command with extra build_man call. """
@@ -636,6 +643,8 @@ setup(
['$sysconfdir/portage/repo.postsync.d', 
['cnf/repo.postsync.d/example']],
],
 
+   ext_modules = [Extension(name=n, sources=m) for n, m in 
x_c_helpers.items()],
+
cmdclass = {
'build': x_build,
'build_man': build_man,
-- 
2.7.3

From ee31675efc06d1df6806cfcdfc4102271e596c96 Mon Sep 17 00:00:00 2001
From: "Anthony G. Basile" <bluen...@gentoo.org>
Date: Fri, 27 May 2016 09:47:34 -0400
Subject: [PATCH 3/3] pym/portage/util/locale.py: add a C module to help check
 locale

The current method to check for a sane system locale is to use python's
ctypes.util.find_library() to construct a full library path to the
system libc.so and pass that path to ctypes.CDLL() so we can call
toupper() and tolower() directly.  However, this gets bogged down in
implementation details and fails with musl.

We work around this design flaw in ctypes with a small python module
written in C which provides thin wrappers to toupper() and tolower(),
and only fall back on the current ctypes-based check when this module
is not available.

This has been tested on glibc, uClibc and musl systems.

X-Gentoo-bug: 571444
X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=571444

Signed-off-by: Anthony G. Basile <bluen...@gentoo.org>
---
 pym/portage/util/locale.py | 16 ++-
 setup.py   |  6 +++-
 src/portage_util_libc.c| 68 ++
 3 files changed, 82 insertions(+),

Re: [gentoo-dev] base-system needs developers who care

2016-08-23 Thread Anthony G. Basile
On 8/23/16 8:03 PM, Lars Wendler wrote:
> I have some kind of interest for these packages:

Lars, maybe once we get some names we should get a meeting of
base-system together and coordinate our efforts.  In particular, I
mostly have interest in those packages that make up @system for the
stages I build.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] base-system needs developers who care

2016-08-23 Thread Anthony G. Basile
On 8/23/16 7:17 PM, Robin H. Johnson wrote:
> Over the years, the base-system package herd has grown in size. Today

I've been doing some base-system related stuff because of uclibc/-ng and
musl on minor arches, building stage3's for those.  My involvement has
been marginal because my emphasis is not mainstream, but I can start
giving some of those packages love.  I'm spread a bit thin, but I'm
going to give away some of my less important packages.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] New Working Group established to evaluate the stable tree

2016-08-14 Thread Anthony G. Basile
On 8/14/16 5:45 PM, Ciaran McCreesh wrote:
> On Sun, 14 Aug 2016 23:35:58 +0200
> Kristian Fiskerstrand <k...@gentoo.org> wrote:
>> During the latest Council meeting it was determined to set up a new
>> Working Group to come up with recommendations for improving the state
>> of the stable tree at a later Council meeting.
> 
> What's a Working Group, and how is it related to a Project? Shouldn't
> there be a GLEP to define what a Working Group is first?
> 

Seriously?!  You mean a group of devs can't just get together to
brainstorm a problem across projects?

Anyhow, Kristian, I'm in.  Put me on the cc list.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] Lastrites: www-client/midori

2016-07-31 Thread Anthony G. Basile
On 7/31/16 7:19 AM, Pacho Ramos wrote:
> # Pacho Ramos <pa...@gentoo.org> (31 Jul 2016)
> # Upstream looks completely dead for a long time, doesn't reply to any
> bug
> # we report to them. This relies on obsolete software like (#587448)
> and
> # other bugs are being accumulated without any fix/attention. Removal
> in a
> # month if nobody comes with the fixes.
> www-client/midori
> 

I like midori.  Let me take a look and see if its worthy the effort and
get back to you.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] RFC: migration from uclibc to uclibc-ng

2016-07-16 Thread Anthony G. Basile
Hi everyone,

Most of you know that uclibc upstream is pretty much dead.  There hasn't
been a official release since 2012 and there hasn't been a commit to
their master branch for over a year.  The situation has become
impossible since important fixes really can't be backported without
layers of intermediated fixes being backported first.  This has lead to
a fork at http://uclibc-ng.org/ which is actively maintained and has all
of the fixes we need in the latest release.

Since I don't want to just give up on Gentoo + uclibc, I'm going to
migrate to uclibc-ng.  (Parenthetically let me add that I think the real
future of embedded will be musl, but still I don't want to just give up
on uclibc.)

After migrating, I will pretty much abandon uclibc itself and continue
exclusively with uclibc-ng.  The supported arches are and will continue
to be amd64, armv7a (hard/soft float), mips32r2 (big endian), mipsel3
(little endian), ppc and i686.  The process will be as follows:

1. Build experimental stage3's with customize /etc/portage.  This is
just for testing since the final stage3's should not have anything in
/etc/portage.  This must be completed for all arches before the next step.

2. Migrate the customized /etc/portage to profiles/default/linux/uclibc
for all arches, and switch the priority in virtual/libc/libc-0.ebuild.
Currently it reads:

elibc_uclibc? ( || ( sys-libs/uclibc sys-libs/uclibc-ng ) )


3. Update https://wiki.gentoo.org/wiki/Project:Hardened_uClibc with
instructions on how to upgrade.

4. Start pushing out uclibc-ng base stages
https://www.gentoo.org/downloads/ for amd64 and i686.

I'm at step 1 for amd64 and i686.

I welcome comment on any of the above.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] masking and removing *coin packages

2016-07-08 Thread Anthony G. Basile
On 7/8/16 10:42 AM, Rich Freeman wrote:
> On Fri, Jul 8, 2016 at 10:30 AM, Anthony G. Basile <bluen...@gentoo.org> 
> wrote:
>>
>> Also there's some debate in IRC about whether or not these packages
>> should be lastrited or dropped to maintainer-needed.  These forks are
>> not in good shape upstream, so I think it makes better sense to
>> p.mask/lastrite and then move them to the graveyard overlay when I
>> remove them from the tree in 30 days.
>>
> 
> IMO the criteria should be whether they work or not.  Not whether
> upstream is more or less active.

There is a QA against the current version of namecoin* and upstreams
newest packages are no good.

> 
> If they're blockers on other work, by all means cull them.  However,
> if the biggest problem with them is that they're using a few inodes in
> the repo, then they should probably stay.
> 

I have no strong feeling here, but I do want to get rid of them.  So I'm
okay with maintainer-needed@  I'll let the discussion continue for a bit
and then do whatever the consensus is.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Fwd: Re: [gentoo-dev] masking and removing *coin packages

2016-07-08 Thread Anthony G. Basile
Okay,  I'll set the metadata.xml for both net-p2p/litecoin* and
sys-process/nmon to the following:


http://www.gentoo.org/dtd/metadata.dtd;>


marc.p...@sunny-computing.de
Marc Popp
Maintainer. Assign bugs to him


proxy-ma...@gentoo.org
Proxy Maintainers




Also there's some debate in IRC about whether or not these packages
should be lastrited or dropped to maintainer-needed.  These forks are
not in good shape upstream, so I think it makes better sense to
p.mask/lastrite and then move them to the graveyard overlay when I
remove them from the tree in 30 days.

I haven't acted yet, so there's still time to bikeshed ;)


On 7/8/16 4:32 AM, Marc Popp wrote:
> Hi Anthony,
> 
> I would take over the litecoin* packages, but my last (and first) request
> to take over nmon was not even approved it answered yet. I guess, I wasn't
> following the right process.
> 
> Thanks
> Marc
> 
> 
> 
> On Friday, 8 July 2016, Anthony G. Basile <bluen...@gentoo.org> wrote:
> 
>> Hi everyone,
>>
>> I emailed the list some time ago about giving away a bunch of bitcoin
>> forks to see if anyone was interested in taking them.  I didn't get any
>> feedback so as of tomorrow I'll be masking the following for removal in
>> 30 days.
>>
>> net-dns/namecoind
>> net-dns/namecoin-qt
>>
>> net-p2p/bitcoinxtd
>> net-p2p/bitcoinxt-qt
>>
>> net-p2p/litecoind
>> net-p2p/litecoin-qt
>>
>> net-p2p/ppcoind
>> net-p2p/ppcoin-qt
>>
>> net-p2p/primecoind
>> net-p2p/primecoin-qt
>>
>> --
>> Anthony G. Basile, Ph.D.
>> Gentoo Linux Developer [Hardened]
>> E-Mail: bluen...@gentoo.org <javascript:;>
>> GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
>> GnuPG ID  : F52D4BBA
>>
>>
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] masking and removing *coin packages

2016-07-07 Thread Anthony G. Basile
Hi everyone,

I emailed the list some time ago about giving away a bunch of bitcoin
forks to see if anyone was interested in taking them.  I didn't get any
feedback so as of tomorrow I'll be masking the following for removal in
30 days.

net-dns/namecoind
net-dns/namecoin-qt

net-p2p/bitcoinxtd
net-p2p/bitcoinxt-qt

net-p2p/litecoind
net-p2p/litecoin-qt

net-p2p/ppcoind
net-p2p/ppcoin-qt

net-p2p/primecoind
net-p2p/primecoin-qt

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-06 Thread Anthony G. Basile
On 7/6/16 8:11 AM, Rich Freeman wrote:
> Like I said, one mistake doesn't make a trend, and we shouldn't
> over-react to a mistake.  However, the way to handle a mistake is for
> everybody to say "this was a mistake," not "you're the only person who
> has a problem with this."  Let's just fix whatever broke (if it isn't
> already fixed) and move on.  We don't need to defend mistakes.

+1

So what we don't want happening again moving forward is where a
developer (me in this case) thinks he's provided the information needed
for security, then the bug goes dormant 3 years, and then out of the
blue a p.mask with 30 days notice until removal.  Especially if it the
security issue is minor.

The security@g.o list has 500+ open bugs going back years.  We don't
want this uncertainty to loom over all developers heads.  A reasonable
policy here would help create clear expectations for security and other
developers.

I don't think I need to add more to this since K_F appears to be working
on something that will address this.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-06 Thread Anthony G. Basile
On 7/6/16 7:30 AM, Kristian Fiskerstrand wrote:
> On 07/06/2016 01:15 PM, Anthony G. Basile wrote:
>> I'm also disappointed that no one else in the security team has
>> recommended any internal policing in response to this.  I maintain that
>> forced p.masking and version bumping should not be done by the security
>> team but passed to QA for review.  Only QA is mandated with such powers
>> by GLEP 48.
> 
> We're discussing this in another thread already (i.e possibly a GLEP for
> Security project), I'm discussing that as a member of security.
> 
> As for any internal policing outside of public policies it is done
> within the team and not on a public mailing list. The relevant public
> policies are:
> https://wiki.gentoo.org/wiki/Project:Security/GLSA_Coordinator_Guide
> https://www.gentoo.org/support/security/vulnerability-treatment-policy.html
> 
> But I agree these needs reviewing and codification in the form of a
> GLEP, but as said in the other thread, need to discuss that within the
> project first (I'm not lead, but have requested a team meeting already)
> 


I like this.  So let's make sure we have clear expectations and an
escalation process with review before we pull the p.mask with 30 days
till poof.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-06 Thread Anthony G. Basile
On 7/6/16 7:23 AM, Aaron Bauman wrote:
> On Wednesday, July 6, 2016 8:15:24 PM JST, Anthony G. Basile wrote:
>> On 7/6/16 6:54 AM, Aaron Bauman wrote:
>>> On Wednesday, July 6, 2016 5:10:25 PM JST, Anthony G. Basile wrote: ...
>>
>> Except that I state such facts BEFORE the p.mask and you ignored it.
>> Referring to bug #473770:
>>
>> 
>>
>> (In reply to Anthony Basile from comment #1)
>>> The CVE for this has gone nowhere.  See
>>>
>>> http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-2183
>>>
>>> There are no references and I can't get at the upstream bug report
>>> anymore
>>> since they moved to github.
>>
>> Actually, I found it.  Its fixed:
>>
>> https://github.com/monkey/monkey/issues/93
>>
>> 
>>
>> 
>>
>> Aaron Bauman gentoo-dev Security 2016-07-01 01:39:40 UTC
>>
>> # Aaron Bauman <b...@gentoo.org> (1 Jul 2016)
>> # Unpatched security vulnerabilities and dead upstream
>> # per bugs #459274 and #473770  Removal in 30 days
>> www-servers/monkeyd
>>
>> 
>>
>>
>> People reading following this can clearly see the problem here.
>>
>> I'm also disappointed that no one else in the security team has
>> recommended any internal policing in response to this.  I maintain that
>> forced p.masking and version bumping should not be done by the security
>> team but passed to QA for review.  Only QA is mandated with such powers
>> by GLEP 48.
>>
> 
> What kind of policing would you like to see councilman? 

Policing also has the meaning of policy-ing.  I'd like to see better
policies within the security team for escalation of security bugs.  I'm
suggesting passing the review onto QA, but it looks like K_F (from his
other email) has other ideas which may better for a workflow.


> Would you like
> to see me removed from the project, because your precious package was
> p.masked?

I never said anything to that effect.  I'm arguing a point for better
policy-ing and I'm not satisfied by your solution that developers need
to just better document when a security issue is fixed.

monkeyd is an important package.

>  You have ignored every thing I have said regarding your
> inability to work with the security team.  Even after an apology from me
> and a request to work with us you continue on with the rhetoric of
> powers.  It displays a lot about your inability to work with others.

The problem is not an apology which I appreciate.  The problem is we
need better expectations of when a package is going to get p.masked on
you.  p.masking a package which a notice of 30 days until removal sends
a very bad message to users who depend on it.  Proceeding as the
security team has, there is no way for a developer to know what's about
to happen.  Consider, I thought I'd answered the issue with bug #473770
with comment #2.

> 
> No other developer is complaining... it is *literally* only you. 
> NP-Hardass's case was not even a security bug nor handled by the
> security team.  One of the bugs for monkeyd led to additional discovery
> of insecurities regarding log files, but it took a p.mask to get your
> attention.  Quit pushing an agenda and work with others to make Gentoo
> more secure.  Everyone else is.
> 
>>

It doesn't matter, there is a problem here which needs to be addressed.
I'm complaining because we need to fix a problem in our workflow.  It
sounds like K_F is working on a glep for that, which I applaud.

> 
> 


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-06 Thread Anthony G. Basile
On 7/6/16 6:54 AM, Aaron Bauman wrote:
> On Wednesday, July 6, 2016 5:10:25 PM JST, Anthony G. Basile wrote:
>> On 7/5/16 10:52 PM, NP-Hardass wrote:
>>> I think it is a little bit of a stretch to say that he's the only one to
>>> have an issue.  Now, I've spoken with the parties involved, so my issue
>>> is resolved, but I had a package of mine bumped in the name of security
>>> without being pinged/consulted at all.  I'm not attempting to point
>>> blame at anyone, but merely show that there are others who have been ...
>>
>> I agree that a ping is the necessary first step, but I'm afraid of a
>> dispute between the maintainer and the security team.  Bug #459274,
>> which I discussed in my previous email, should never have been file and
>> should never have been acted on.  If the security team feels they must
>> touch a package, I'd like to have QA review it.  The QA leadership is
>> ratified by the council and has a long history of dealing with these
>> sorts of issues which are tried and true.
>>
>>
> 
> So just state such facts, as you did following the p.mask, and all would
> be well.  It really has been and continues to be that simple.
> 

Except that I state such facts BEFORE the p.mask and you ignored it.
Referring to bug #473770:



(In reply to Anthony Basile from comment #1)
> The CVE for this has gone nowhere.  See
>
> http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2013-2183
>
> There are no references and I can't get at the upstream bug report anymore
> since they moved to github.

Actually, I found it.  Its fixed:

https://github.com/monkey/monkey/issues/93





Aaron Bauman gentoo-dev Security 2016-07-01 01:39:40 UTC

# Aaron Bauman <b...@gentoo.org> (1 Jul 2016)
# Unpatched security vulnerabilities and dead upstream
# per bugs #459274 and #473770  Removal in 30 days
www-servers/monkeyd




People reading following this can clearly see the problem here.

I'm also disappointed that no one else in the security team has
recommended any internal policing in response to this.  I maintain that
forced p.masking and version bumping should not be done by the security
team but passed to QA for review.  Only QA is mandated with such powers
by GLEP 48.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-06 Thread Anthony G. Basile
On 7/6/16 4:25 AM, Kristian Fiskerstrand wrote:
> 
> That said, the reason the mask is questionable in this case is the low
> severity of the bug, but that isn't a general case.

Bug #582240 - sys-devel/gcc: multiple vulnerabilities

If the security team proceeded with gcc as it did with monkeyd, it would
be masking it now.  It doesn't have to be a general case.  Looking
through the security bugs there's so much link, its hard to tell what's
good and what's not.

> 
> If council approval of special projects as lead is an important factor,
> maybe we should rather also approve security leads?
> 

Approving a security lead is not sufficient.  QA is governed by GLEP 48.
 The very procedure of producing a glep means scrutiny by the community
as to its scope, mandate, procedure and powers.  By the security team
simply thinking it has the powers to p.mask and bump packages, its is
essentially circumventing Gentoo governance.  If it needs these powers,
it should go through QA.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-06 Thread Anthony G. Basile
On 7/5/16 10:52 PM, NP-Hardass wrote:
> 
> I think it is a little bit of a stretch to say that he's the only one to
> have an issue.  Now, I've spoken with the parties involved, so my issue
> is resolved, but I had a package of mine bumped in the name of security
> without being pinged/consulted at all.  I'm not attempting to point
> blame at anyone, but merely show that there are others who have been
> affected by security workflow sometimes going around the maintainer.  I
> don't think there should be any harm in acknowledging that, and striving
> to make sure it doesn't happen in the future, where possible.
> 

I agree that a ping is the necessary first step, but I'm afraid of a
dispute between the maintainer and the security team.  Bug #459274,
which I discussed in my previous email, should never have been file and
should never have been acted on.  If the security team feels they must
touch a package, I'd like to have QA review it.  The QA leadership is
ratified by the council and has a long history of dealing with these
sorts of issues which are tried and true.


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197



Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-06 Thread Anthony G. Basile
On 7/5/16 10:43 PM, Aaron Bauman wrote:
> 
> That CVE request was not from Ago.  It was from the respective OSS ML
> referenced in the URL field of the bug report.  Not to mention, you as a
> maintainer were able to discover another issue with that package and fix
> it.
> 

You never bothered to follow that OSS ML link.  For others reading this
email, here is the link:

http://www.openwall.com/lists/oss-security/2013/02/24/5

Here's a copy of that entire email:



Date: Sun, 24 Feb 2013 20:00:57 +0100
From: Agostino Sarubbo <a...@...too.org>
To: oss-secur...@...ts.openwall.com
Subject: CVE request: monkeyd world-readable logdir

Monkeyd, a small, fast, and scalable web server, produces, at least on
gentoo a world-readable log.

# ls /var/log/monkeyd/master.log -la
-rw-r--r-- 1 root root 0 Feb 24 19:56 /var/log/monkeyd/master.log

Upstream site: http://www.monkey-project.com/

-- 
Agostino Sarubbo
Gentoo Linux Developer




That is what you p.masked on.  That's it.  Neither you nor Ago really
understood the issue with monkeyd's logging.  There were no followup
emails and no CVE was assigned.  Its junk.

By both initiating and following through on such low quality bugs, you
are damaging the reputation of the security project.


>> I personally would like to see only QA oversee any forced p.maskings and
>> have the security team pass that task over to QA for review.  By forced
>> I mean without the cooperation of the maintainer.
>>
> 
> Again, no one else has had an issue with this except you.  The one who
> doesn't want to cooperate.  

Having people review your work is a good idea, no?  So in cases where
security wants to touch a packages, why not ping the maintainer first
and in case of a dispute or no response, escalate the issue to QA who
will review the problem and act.

Are you okay with this change in procedure?


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197



Re: [gentoo-dev] why is the security team running around p.masking packages

2016-07-05 Thread Anthony G. Basile
On 7/4/16 11:26 PM, Aaron Bauman wrote:

> 
> Finally, that does not dissolve the developer of providing usable,
> substantiated, and verifiable information regarding the
> vulnerabilities.  The idea that a developer gets to choose whether or
> not they do so should not be considered.  Anthony's verbiage on Freenode
> was very frank, in that if he chose to do so he would.  We ask for all
> developers to assist and work together with us to fix these issues.  You
> can see the fruits of such information from the developer following Alex
> Legler's comments on the bug and my follow up actions.
> 
> -Aaron
> 

1) In bug #473770 upstream gave sufficient information.  I stated so in
comments #1 and #2 with links.  You ignored this fact and proceeded to
p.mask in comment #3.  This CVE should never have been filed.  Its junk.

2) Bug #459274 is not a security bug.  A CVE request was filed by Ago
which, as far as I can tell, went no where.  The log file in question
does not disclose much more than one could obtain with just ps and
netstat.  I fixed a related issue with access.log in bug #459274.

3) My point on IRC is that you are acting on junk CVEs and I question
your judgment.  You can't produce "substantiated and verifiable
information" on junk.  Your above paragraph eclipses that side of my
argument and strawmans me.

I personally would like to see only QA oversee any forced p.maskings and
have the security team pass that task over to QA for review.  By forced
I mean without the cooperation of the maintainer.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197



[gentoo-dev] why is the security team running around p.masking packages

2016-06-30 Thread Anthony G. Basile
I'm going to ask the security team to please stop running around
p.masking packages without acknowledgement from the maintainers.  I'm
referring in particular to commit
135b94c85950254f559f290f4865bce8b349a917 regarding monkeyd.  Both of the
cited "security bugs" were long fixed, and even if the were not, they do
not merit masking because they were at best some information leakage
with minor impact.  I have reverted that commit and would ask that
security stop this practice.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] packages up for grabs

2016-06-28 Thread Anthony G. Basile
Hi everyone,

I've been proxy-maintaining (or maintaining) bitcoins and a bunch of
forks and I'd like to give those packages away.  I got involved because
I believe in the principles behind bitcoins and decentralized services
on the internet that resist censorship and promote freedom and all that
good stuff.  However, these forks live in their own world and I'm not
following them as well as I should.

If anyone is interested, please go ahead and take any.  Note that
net-p2p/bitcoin{d,-qt,-cli} and dev-util/bitcoin-tx are maintained by
luke-jr and he's doing a good job.  I don't want to see these taken off
the tree so if no one wants them I'll continue to proxy, but my
preference is to let them all go.

dev-util/bitcoin-tx
net-dns/namecoind
net-dns/namecoin-qt
net-p2p/bitcoin-cli
net-p2p/bitcoind
net-p2p/bitcoin-qt
net-p2p/bitcoinxtd
net-p2p/bitcoinxt-qt
net-p2p/datacoin-hp
net-p2p/litecoind
net-p2p/litecoin-qt
net-p2p/ppcoind
net-p2p/ppcoin-qt
net-p2p/primecoind
net-p2p/primecoin-qt

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev][ppc64le][PATCH 01/12] sys-devel/libtool: add m4/libtool.m4 patch for ppc64le #581314

2016-06-28 Thread Anthony G. Basile
On 6/28/16 10:31 AM, Leno Hou wrote:
> Reference Bug:
> Gentoo Bug: https://bugs.gentoo.org/show_bug.cgi?id=581314
> GNU Bug: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348
> 

Leno,

Thanks.  Just so other devs know, I'm helping Leno port gentoo to
ppc64le.  We need these 12 patches to get build systems to recognize
CHOST=powerpc64le-unknown-linux-gnu plus fix up some other pkgs.  I'm
going to set up an overlay to house these fixes until they land in the
tree, but if you can review them it'll save the effort of the
intermediate overlay.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] The future of the Sunrise project

2016-06-07 Thread Anthony G. Basile
On 6/7/16 11:37 AM, Michał Górny wrote:
> On Tue, 07 Jun 2016 15:56:16 +0100
> "M. J. Everitt" <m.j.ever...@iee.org> wrote:
> 
>> On 07/06/16 16:44, james wrote:
>>> On 06/07/2016 09:25 AM, Michał Górny wrote:  
>>>> Wouldn't removing it from repositories.xml have pretty much the same
>>>> effect?
>>>>
>>>> Also, i think we should make the unreviewed repo public then, so
>>>> people can get the newest ebuilds.  
>>>
>>> Perhaps a deprecation period of a year, with a gentoo wiki page that
>>> lists the packages found @sunrise, is a good idea?
>>>
>>>  
>> A year is a very short time in software terms .. maybe 5 years ... !!
>> But freezing it, with the intention of removing from repos.xml in 5
>> years time seems reasonable to me.
> 
> I'm against keeping it in repos.xml for more than a month, considering
> the current (huge) state of breakage it is in. Other repositories with
> similar breakage were already removed.
> 

It should not be used as an overlay.  It has not been updated for nearly
a year and if its frozen as an archive then all the more reason.  There
should also be huge warnings in the README.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



Re: [gentoo-dev] The future of the Sunrise project

2016-06-07 Thread Anthony G. Basile
On 6/6/16 5:23 PM, Michał Górny wrote:
> Hello, everyone.
> 
> It has recently came to my attention that things are quite bad with
> the Sunrise project [1] lately. Most of the developers have left
> the project, and it seems that the contributors have done the same.
> The public reviewed repository has major QA issues and hasn't been
> updated since mid-2015. The last non-developer commit to the private
> repo also seems to come from mid-2015, followed only by a number of
> removals and fixes done by Gentoo developers.
> 
> Therefore, I'd like to ask the following question: is it time to
> announce the project dead, or do some developers want to revive it?
> If the former, could someone try to contact last active contributors
> and ask them if they'd like to move their ebuilds to ::gentoo
> via proxy-maint?
> 
> I should point out that Sunrise has lost a lot of popularity to
> proxy-maint, then also to GitHub pull requests (and the two combined).
> The developers involved with those provide quite a good review
> workflow, with the extra advantage of getting packages straight
> into ::gentoo. I don't know how many users would be interested
> in keeping them in ::sunrise if they could have them straight
> in ::gentoo with similar (if not less...) effort.
> 
> Your thoughts?
> 
> [1]:https://wiki.gentoo.org/wiki/Project:Sunrise
> 

Its time to retire the project.  Put out a last call for anyone to adopt
it.  If not, then freeze commits but leave the repo open as an archive.
Anyone who wants to scavenge ebuilds from it can do so.

sunrise was a great idea.  Debian has a similar project (I forget the
name).  But projects that depend on a particular workflow are going to
go the way of the dinosaurs when the next vcs comes around.  Today its
github, tomorrow its ???.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-dev] Council Council: call for agenda items for June 12 meeting

2016-06-03 Thread Anthony G. Basile
Hi everyone,

The Council will be meeting on Sunday June 12.  This is a call for any
agenda items.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA



[gentoo-portage-dev] [PATCH 3/3] pym/portage/util/locale.py: add a C module to help check locale

2016-05-30 Thread Anthony G. Basile
From: "Anthony G. Basile" <bluen...@gentoo.org>

The current method to check for a sane system locale is to use python's
ctypes.util.find_library() to construct a full library path to the
system libc.so and pass that path to ctypes.CDLL() so we can call
toupper() and tolower() directly.  However, this gets bogged down in
implementation details and fails with musl.

We work around this design flaw in ctypes with a small python module
written in C which provides thin wrappers to toupper() and tolower(),
and only fall back on the current ctypes-based check when this module
is not available.

This has been tested on glibc, uClibc and musl systems.

X-Gentoo-bug: 571444
X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=571444

Signed-off-by: Anthony G. Basile <bluen...@gentoo.org>
---
 pym/portage/util/locale.py | 16 ++-
 setup.py   |  6 +++-
 src/portage_util_libc.c| 68 ++
 3 files changed, 82 insertions(+), 8 deletions(-)
 create mode 100644 src/portage_util_libc.c

diff --git a/pym/portage/util/locale.py b/pym/portage/util/locale.py
index 093eb86..5b09945 100644
--- a/pym/portage/util/locale.py
+++ b/pym/portage/util/locale.py
@@ -34,13 +34,15 @@ def _check_locale(silent):
"""
The inner locale check function.
"""
-
-   libc_fn = find_library("c")
-   if libc_fn is None:
-   return None
-   libc = LoadLibrary(libc_fn)
-   if libc is None:
-   return None
+   try:
+   from portage.util import libc
+   except ImportError:
+   libc_fn = find_library("c")
+   if libc_fn is None:
+   return None
+   libc = LoadLibrary(libc_fn)
+   if libc is None:
+   return None
 
lc = list(range(ord('a'), ord('z')+1))
uc = list(range(ord('A'), ord('Z')+1))
diff --git a/setup.py b/setup.py
index 25429bc..5ca8156 100755
--- a/setup.py
+++ b/setup.py
@@ -47,7 +47,11 @@ x_scripts = {
 # Dictionary custom modules written in C/C++ here.  The structure is
 #   key   = module name
 #   value = list of C/C++ source code, path relative to top source directory
-x_c_helpers = {}
+x_c_helpers = {
+   'portage.util.libc' : [
+   'src/portage_util_libc.c',
+   ],
+}
 
 class x_build(build):
""" Build command with extra build_man call. """
diff --git a/src/portage_util_libc.c b/src/portage_util_libc.c
new file mode 100644
index 000..977b954
--- /dev/null
+++ b/src/portage_util_libc.c
@@ -0,0 +1,68 @@
+/* Copyright 2005-2016 Gentoo Foundation
+ * Distributed under the terms of the GNU General Public License v2
+ */
+
+#include 
+#include 
+#include 
+
+static PyObject * _libc_tolower(PyObject *, PyObject *);
+static PyObject * _libc_toupper(PyObject *, PyObject *);
+
+static PyMethodDef LibcMethods[] = {
+   {"tolower", _libc_tolower, METH_VARARGS, "Convert to lower case using 
system locale."},
+   {"toupper", _libc_toupper, METH_VARARGS, "Convert to upper case using 
system locale."},
+   {NULL, NULL, 0, NULL}
+};
+
+#if PY_MAJOR_VERSION >= 3
+static struct PyModuleDef moduledef = {
+   PyModuleDef_HEAD_INIT,
+   "libc", /* 
m_name */
+   "Module for converting case using the system locale",   /* 
m_doc */
+   -1, /* 
m_size */
+   LibcMethods,/* 
m_methods */
+   NULL,   /* 
m_reload */
+   NULL,   /* 
m_traverse */
+   NULL,   /* 
m_clear */
+   NULL,   /* 
m_free */
+};
+
+PyMODINIT_FUNC
+PyInit_libc(void)
+{
+   PyObject *m;
+   m = PyModule_Create();
+   return m;
+}
+#else
+PyMODINIT_FUNC
+initlibc(void)
+{
+   Py_InitModule("libc", LibcMethods);
+}
+#endif
+
+
+static PyObject *
+_libc_tolower(PyObject *self, PyObject *args)
+{
+   int c;
+
+   if (!PyArg_ParseTuple(args, "i", ))
+   return NULL;
+
+   return Py_BuildValue("i", tolower(c));
+}
+
+
+static PyObject *
+_libc_toupper(PyObject *self, PyObject *args)
+{
+   int c;
+
+   if (!PyArg_ParseTuple(args, "i", ))
+   return NULL;
+
+   return Py_BuildValue("i", toupper(c));
+}
-- 
2.7.3




  1   2   3   4   5   6   >