Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer

2017-08-08 Thread Matthew Thode
On 17-08-04 17:17:05, Mart Raudsepp wrote:
> On K, 2017-07-26 at 11:56 +0200, Pacho Ramos wrote:
> > sys-boot/plymouth is orphan for a long time. Its old 0.8.x versions
> > where having
> > important bugs that were fixed in 0.9.x, but 0.9 is also plenty of
> > issues. Then,
> > either this is adopted by someone able to handle all that issues or
> > we will need
> > to finally treeclean (and drop its support for dependant packages)
> 
> So despite this thread, this got suddenly p.masked.
> 
> It seems most issues are related to usage with OpenRC, plus some
> stopping issue with sddm.
> 
> I can soon look into the systemd aspects, but are there anyone
> interested in the openrc use case, to help out there?
> 
> 
> Mart
> 

I've reverted the p.mask commit and added myself to the metadata for
plymouth (not the openrc plugin).  I've also poked upstream for a new
tag since it's been a while and they are active...

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread Sam Jorna (wraeth)
On 09/08/17 10:43, William L. Thomson Jr. wrote:
> On Wed, 9 Aug 2017 10:29:40 +1000
> "Sam Jorna (wraeth)"  wrote:
> 
>> On 09/08/17 04:20, William L. Thomson Jr. wrote:
>>> On Tue, 8 Aug 2017 19:32:48 +0200
>>> Kristian Fiskerstrand  wrote:  
  - You might be applying local patches through /etc/portage/patches
 that are distributed to all clients  
>>>
>>> This might be the strongest reason. Though would only apply to stuff
>>> like say kernel sources. Not sure what patches could be applied to a
>>> binary ebuild, -bin. A patch would not effect src_install per my
>>> understanding.  
>>
>> There's also the fact that binpkgs may be manually installed exactly
>> as the package manager would have installed it, rather than extracting
>> whatever upstream supplies verbatim. 
> 
> What then is the benefit? If what is installed is the same from
> package manager or binpkg. Also your redistributing another's package
> in binary format which may not be legally allowed.

The difference is that how the package manager/ebuild installs the
package may be better suited to the environment than what upstream
expects (such as upstreams that install through a .run file)

>> This includes things like any wrappers, desktop files or symlinks
>> created by the ebuild, or other such downstream-isms.
> 
> If it was made via package manager. If it was made via quickpkg, it
> maybe different than if made by package manager.

Using quickpkg can create different binaries depending on your options,
but otherwise it should package any installed files as recorded by the
package manager - provided you use inclusive options, there should be no
appreciable difference as far as I'm aware.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread William L. Thomson Jr.
On Wed, 9 Aug 2017 10:29:40 +1000
"Sam Jorna (wraeth)"  wrote:

> On 09/08/17 04:20, William L. Thomson Jr. wrote:
> > On Tue, 8 Aug 2017 19:32:48 +0200
> > Kristian Fiskerstrand  wrote:  
> >>  - You might be applying local patches through /etc/portage/patches
> >> that are distributed to all clients  
> > 
> > This might be the strongest reason. Though would only apply to stuff
> > like say kernel sources. Not sure what patches could be applied to a
> > binary ebuild, -bin. A patch would not effect src_install per my
> > understanding.  
> 
> There's also the fact that binpkgs may be manually installed exactly
> as the package manager would have installed it, rather than extracting
> whatever upstream supplies verbatim. 

What then is the benefit? If what is installed is the same from
package manager or binpkg. Also your redistributing another's package
in binary format which may not be legally allowed.

> This includes things like any wrappers, desktop files or symlinks
> created by the ebuild, or other such downstream-isms.

If it was made via package manager. If it was made via quickpkg, it
maybe different than if made by package manager.

-- 
William L. Thomson Jr.


pgpM0WgebH6wT.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread Sam Jorna (wraeth)
On 09/08/17 04:20, William L. Thomson Jr. wrote:
> On Tue, 8 Aug 2017 19:32:48 +0200
> Kristian Fiskerstrand  wrote:
>>  - You might be applying local patches through /etc/portage/patches
>> that are distributed to all clients
> 
> This might be the strongest reason. Though would only apply to stuff
> like say kernel sources. Not sure what patches could be applied to a
> binary ebuild, -bin. A patch would not effect src_install per my
> understanding.

There's also the fact that binpkgs may be manually installed exactly as
the package manager would have installed it, rather than extracting
whatever upstream supplies verbatim. This includes things like any
wrappers, desktop files or symlinks created by the ebuild, or other such
downstream-isms.

-- 
Sam Jorna (wraeth)
GnuPG ID: D6180C26



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Perl 5.26 Unmasking Warning [affects all users]

2017-08-08 Thread Andreas K. Huettel
Am Dienstag, 8. August 2017, 20:55:41 CEST schrieb Andrew Savchenko:
> On Wed, 9 Aug 2017 04:20:18 +1200 Kent Fredric wrote:
> > We're finally at a point where we're nearing the unmasking[1] of Perl
> > 5.26 and making it visible to ~arch users, and a "news item" on this
> > matter will appear shortly.
> > 
> > Due to a collection of various problems faced in this version,
> > extensive amounts of work has been needed to simply deliver an ~arch
> > release that isn't incredibly visibly broken [1][2].
> 
> [1] indicates there are unfixed problems with core system packages:
> gcc (620164) and autoconf (625576). Having them broken even in
> ~arch is no fun. Are you going to fix these issues before perl-5.26
> will be unmasked?

The gcc breakage is harmless (it fails to build some documentation files, but 
ignores that and continues the build); we have a patch, which will be bumped 
to stable after some "just to be safe" testing. (The unkeyworded versions of 
5.4 and 4.9.4.) gcc-6 and later is already fixed upstream.

Autoconf is not so harmless, but the current newest ~arch version contains the 
fix already.


-- 
Dr. Andreas K. Hüttel
tel. +49 151 241 67748 (mobile)
e-mail m...@akhuettel.de
http://www.akhuettel.de/



Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: Strip LDFLAGS unsupported by the C compiler, #621274

2017-08-08 Thread Michał Górny
On sob, 2017-07-01 at 18:22 +0200, Michał Górny wrote:
> Include LDFLAGS in the variables stripped by strip-unsupported-flags.
> The code reuses the current functions for testing CC, and so only remove
> LDFLAGS that are rejected by the C compiler and not the linker. This
> solves the case of bug #621274 where LDFLAGS contained GCC-specific
> -flto flag.
> ---
>  eclass/flag-o-matic.eclass   | 3 +++
>  eclass/tests/flag-o-matic.sh | 2 +-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 

Merged.

-- 
Best regards,
Michał Górny


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


Re: [gentoo-dev] Perl 5.26 Unmasking Warning [affects all users]

2017-08-08 Thread Andrew Savchenko
On Wed, 9 Aug 2017 04:20:18 +1200 Kent Fredric wrote:
> We're finally at a point where we're nearing the unmasking[1] of Perl
> 5.26 and making it visible to ~arch users, and a "news item" on this
> matter will appear shortly.
> 
> Due to a collection of various problems faced in this version,
> extensive amounts of work has been needed to simply deliver an ~arch
> release that isn't incredibly visibly broken [1][2].

[1] indicates there are unfixed problems with core system packages:
gcc (620164) and autoconf (625576). Having them broken even in
~arch is no fun. Are you going to fix these issues before perl-5.26
will be unmasked?

[1] https://bugs.gentoo.org/show_bug.cgi?id=perl-5.26-unmask


Best regards,
Andrew Savchenko


pgpR_Hf6cX9QF.pgp
Description: PGP signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread William L. Thomson Jr.
> > On 08/08/2017 07:23 PM, William L. Thomson Jr. wrote:  
> > >> it can already be controlled through env files.
> > > I was thinking it might, but having used them to skip other
> > > hooks. I was thinking they could not be used as such for binary
> > > packages. Have you confirmed such is possible?  Could you provide
> > > a link or example? Thanks!
> > 
> > try something like:
> > /etc/portage/env/nobin:
> > FEATURES="-buildpkg"
> > 
> > /etc/portage/package.env/nobin:
> > sys-kernel/gentoo-sources nobin  
> 
> That may work, I was not thinking to negate.  Trying it out now. But
> may lead me to another need... :)

My other need is that it does not seem you can use env files or patches
in profiles. I think I can do the env stuff via other means. Like
package.use. I do not want it in make.defaults, as this is per package.

The problem with env files is managing them per system. I want to do
things like that in profiles. It is to much work to manage that stuff
on each system. Even using things like ansible. Which is why I have
moved to custom profiles rather than per system stuff.

I will need to experiment a bit more. But IMHO a variable that can be
set in an ebuild, and bypassed if needed by operator at emerge time is
the simplest approach.

-- 
William L. Thomson Jr.


pgp_WKOlHcPmv.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread William L. Thomson Jr.
On Tue, 8 Aug 2017 20:15:07 +0200
Kristian Fiskerstrand  wrote:

> On 08/08/2017 08:10 PM, William L. Thomson Jr. wrote:
> >> I'm not sure explicitly about environment files, but it's an
> >> option to emerge.  For instance, I've added this to my
> >> EMERGE_DEFAULT_OPTS to ensure none of the following are built:
> >>
> >> --buildpkg-exclude "virtual/* sys-kernel/*-sources dev-perl/*
> >> perl-core/*"  
> > Something like this would NOT be desirable. It would have to be
> > done on every system.   
> It would have to be set on every binhost, not every client system..
> that said, I prefer env approach as it is easier to track changes
> properly in a CVS

That is assuming clients do not have FEATURES="buildpkg". I have that
set just in case I merge some package directly on a system. I have the
binary ready for others. I am trying out the env route now, but may
need some changes there.

Most are made on the binhost, but not all. Also I am not necessarily
using a binhost per se. I have portage on shared NFS. I also rsync some
binaries between NFS servers.

-- 
William L. Thomson Jr.


pgpzyH21mFLVx.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread William L. Thomson Jr.
On Tue, 8 Aug 2017 19:32:48 +0200
Kristian Fiskerstrand  wrote:

> On 08/08/2017 07:23 PM, William L. Thomson Jr. wrote:
> > Can you think of any? I cannot see any operator wanting a binary of
> > a binary, or a package of sources. When they already have a
> > sources  
> 
>  - The machine you're installing it on might not have internet access
> so you want to have the files stored in a single location for
> wrapping it up.

Not sure that would be any different between distfiles and packages.

>  - You might want an audit trail of installed packages, so using the
> binary files on specific media ensures same copy is installed
> everywhere

Doesn't the manifest/hash aspect of ebuilds ensure that for the
tarballs already? If installing same version, same tarball, Its all the
same already.

>  - You might be applying local patches through /etc/portage/patches
> that are distributed to all clients

This might be the strongest reason. Though would only apply to stuff
like say kernel sources. Not sure what patches could be applied to a
binary ebuild, -bin. A patch would not effect src_install per my
understanding.

> On 08/08/2017 07:23 PM, William L. Thomson Jr. wrote:
> >> it can already be controlled through env files.  
> > I was thinking it might, but having used them to skip other hooks. I
> > was thinking they could not be used as such for binary packages.
> > Have you confirmed such is possible?  Could you provide a link or
> > example? Thanks!  
> 
> try something like:
> /etc/portage/env/nobin:
> FEATURES="-buildpkg"
> 
> /etc/portage/package.env/nobin:
> sys-kernel/gentoo-sources nobin

That may work, I was not thinking to negate.  Trying it out now. But
may lead me to another need... :)

-- 
William L. Thomson Jr.


pgp09Sx3bV7Cd.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread Kristian Fiskerstrand
On 08/08/2017 08:10 PM, William L. Thomson Jr. wrote:
>> I'm not sure explicitly about environment files, but it's an option to
>> emerge.  For instance, I've added this to my EMERGE_DEFAULT_OPTS to
>> ensure none of the following are built:
>>
>> --buildpkg-exclude "virtual/* sys-kernel/*-sources dev-perl/*
>> perl-core/*"
> Something like this would NOT be desirable. It would have to be done on
> every system. 
It would have to be set on every binhost, not every client system.. that
said, I prefer env approach as it is easier to track changes properly in
a CVS

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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread William L. Thomson Jr.
On Tue, 8 Aug 2017 13:34:00 -0400
Ian Stakenvicius  wrote:

> I'm not sure explicitly about environment files, but it's an option to
> emerge.  For instance, I've added this to my EMERGE_DEFAULT_OPTS to
> ensure none of the following are built:
> 
> --buildpkg-exclude "virtual/* sys-kernel/*-sources dev-perl/*
> perl-core/*"

Something like this would NOT be desirable. It would have to be done on
every system. Package env files, if possible, would be a better
approach as that could be distribute to be consistent on all systems.

-- 
William L. Thomson Jr.


pgpgDp0MP9oVI.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread Ian Stakenvicius
On 08/08/17 01:23 PM, William L. Thomson Jr. wrote:
> On Tue, 8 Aug 2017 19:11:18 +0200
> Kristian Fiskerstrand  wrote:
> 
>> it can already be controlled through env files.
> 
> I was thinking it might, but having used them to skip other hooks. I
> was thinking they could not be used as such for binary packages. Have
> you confirmed such is possible?  Could you provide a link or example?
> Thanks!

I'm not sure explicitly about environment files, but it's an option to
emerge.  For instance, I've added this to my EMERGE_DEFAULT_OPTS to
ensure none of the following are built:

--buildpkg-exclude "virtual/* sys-kernel/*-sources dev-perl/* perl-core/*"





signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread William L. Thomson Jr.
On Tue, 8 Aug 2017 10:18:36 -0700
Rich Freeman  wrote:
>
> Whether it belongs in the ebuild, or in metadata, is another matter.

The how, implementation, etc is not as important to me. I just think
there should be some means to prevent such. If there is not currently.

As mentioned there could be other uses/benefits of such depending on
how it is implemented. That is up to others. I just would like to not
have binaries made of packages I feel are a waste to be re-packaged
into a binpkg.

-- 
William L. Thomson Jr.



Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread Kristian Fiskerstrand
On 08/08/2017 07:23 PM, William L. Thomson Jr. wrote:
> Can you think of any? I cannot see any operator wanting a binary of a
> binary, or a package of sources. When they already have a sources

 - The machine you're installing it on might not have internet access so
you want to have the files stored in a single location for wrapping it up.

 - You might want an audit trail of installed packages, so using the
binary files on specific media ensures same copy is installed everywhere

 - You might be applying local patches through /etc/portage/patches that
are distributed to all clients

On 08/08/2017 07:23 PM, William L. Thomson Jr. wrote:
>> it can already be controlled through env files.
> I was thinking it might, but having used them to skip other hooks. I
> was thinking they could not be used as such for binary packages. Have
> you confirmed such is possible?  Could you provide a link or example?
> Thanks!

try something like:
/etc/portage/env/nobin:
FEATURES="-buildpkg"

/etc/portage/package.env/nobin:
sys-kernel/gentoo-sources nobin

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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread Michał Górny
On wto, 2017-08-08 at 10:18 -0700, Rich Freeman wrote:
> On Tue, Aug 8, 2017 at 10:11 AM, Kristian Fiskerstrand  
> wrote:
> > On 08/08/2017 06:37 PM, William L. Thomson Jr. wrote:
> > > I make a lot of binaries for use on other systems, to expedite updates.
> > > It does not make sense for some packages to ever be a binary package.
> > 
> > Any particular reason this decision shouldn't be left to the operator of
> > the binhost rather than the package maintainer? it can already be
> > controlled through env files.
> > 
> 
> Perhaps, but I could see some value in having some way to mark
> packages that don't compile anything.  This could also overlap
> somewhat with the desire to track arch-independent packages for
> stabilization purposes.  I could see it being useful to be able to
> obtain a list of all the binary packages in the Gentoo repo for QA
> purposes/etc as well.
> 
> Maybe it isn't a flag that outright blocks binary package building,
> but a way to mark such packages so that a user can apply a policy on
> top of this.
> 
> Whether it belongs in the ebuild, or in metadata, is another matter.

Does a package that builds documentation from sources count?

-- 
Best regards,
Michał Górny


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


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread William L. Thomson Jr.
On Tue, 8 Aug 2017 19:11:18 +0200
Kristian Fiskerstrand  wrote:

> On 08/08/2017 06:37 PM, William L. Thomson Jr. wrote:
> > I make a lot of binaries for use on other systems, to expedite
> > updates. It does not make sense for some packages to ever be a
> > binary package.  
> 
> Any particular reason this decision shouldn't be left to the operator
> of the binhost rather than the package maintainer?

Can you think of any? I cannot see any operator wanting a binary of a
binary, or a package of sources. When they already have a sources
tarball. Maybe in the case of shipping binaries without sources. But I
am not sure if an binary ebuild ignores SRC_URI entirely.

I think moving binaries without needing the distfiles would be the
only reason why an operator may prefer binaries of stuff that does not
get compiled, just installed.

> it can already be controlled through env files.

I was thinking it might, but having used them to skip other hooks. I
was thinking they could not be used as such for binary packages. Have
you confirmed such is possible?  Could you provide a link or example?
Thanks!


-- 
William L. Thomson Jr.


pgpmdoJlHwS7Z.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread Rich Freeman
On Tue, Aug 8, 2017 at 10:11 AM, Kristian Fiskerstrand  wrote:
> On 08/08/2017 06:37 PM, William L. Thomson Jr. wrote:
>> I make a lot of binaries for use on other systems, to expedite updates.
>> It does not make sense for some packages to ever be a binary package.
>
> Any particular reason this decision shouldn't be left to the operator of
> the binhost rather than the package maintainer? it can already be
> controlled through env files.
>

Perhaps, but I could see some value in having some way to mark
packages that don't compile anything.  This could also overlap
somewhat with the desire to track arch-independent packages for
stabilization purposes.  I could see it being useful to be able to
obtain a list of all the binary packages in the Gentoo repo for QA
purposes/etc as well.

Maybe it isn't a flag that outright blocks binary package building,
but a way to mark such packages so that a user can apply a policy on
top of this.

Whether it belongs in the ebuild, or in metadata, is another matter.

-- 
Rich



Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread Kristian Fiskerstrand
On 08/08/2017 06:37 PM, William L. Thomson Jr. wrote:
> I make a lot of binaries for use on other systems, to expedite updates.
> It does not make sense for some packages to ever be a binary package.

Any particular reason this decision shouldn't be left to the operator of
the binhost rather than the package maintainer? it can already be
controlled through env files.

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



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread Rich Freeman
On Tue, Aug 8, 2017 at 12:37 PM, William L. Thomson Jr.
 wrote:
>
> As most things I think this would require support in PMS, or next EAPI
> at minimum. But I think the EAPI comes from PMS, so they are related.
>

Actually, I'm not sure about this since it doesn't really affect what
is actually built, but I'll defer to others on that.  For example, in
[1] there is a statement "Package managers may recognise other tokens,
but ebuilds may not rely upon them being supported."  This strikes me
as that sort of thing, and indeed this might be the right place to put
it.  There is no real harm if a particular package manager doesn't
support this feature as it has no affect on what is installed.  I
believe we also use non-PMS variables for things like disabling QA
checks in tinderboxes and such, since this has no impact on package
managers.

A new EAPI would be defined in a new version of the PMS.  The PMS is
the specification that includes EAPI among other things.

1 - https://projects.gentoo.org/pms/6/pms.html#x1-920008.2.8

-- 
Rich



[gentoo-dev] Prevent binary/non-compiled packages from binary package creation

2017-08-08 Thread William L. Thomson Jr.
I make a lot of binaries for use on other systems, to expedite updates.
It does not make sense for some packages to ever be a binary package.

Packages like -bin packages or gentoo-sources, which are just sources.
Having binary ebuilds of those is of no benefit. I can be the opposite
causing things to be much slower. Like in the case of large things
packages like android-studio.

Just seems odd to make a binary of a binary, or repackage
gentoo-sources into a gentoo ebuild binary/binpkg. There is not really
any benefit either way for such packages.

It would be beneficial if ebuilds could have some internal variable
that prevents it from being a binary package. It should not prevent
merge or fail. Just never create a binary of this package, always use
the ebuild as normal. Even if someone is force installing using binary
flag or otherwise.

As most things I think this would require support in PMS, or next EAPI
at minimum. But I think the EAPI comes from PMS, so they are related.

-- 
William L. Thomson Jr.


pgptpvQm0C7kK.pgp
Description: OpenPGP digital signature


[gentoo-dev] Perl 5.26 Unmasking Warning [affects all users]

2017-08-08 Thread Kent Fredric
We're finally at a point where we're nearing the unmasking[1] of Perl
5.26 and making it visible to ~arch users, and a "news item" on this
matter will appear shortly.

Due to a collection of various problems faced in this version,
extensive amounts of work has been needed to simply deliver an ~arch
release that isn't incredibly visibly broken [1][2].

Subsequently, this will require a lot of care from end users who use
~arch versions of Perl, specifically as breakages manifest all over the
tree, in places you wouldn't expect ( for example: make, automake,
autoconf, gcc, and even some python packages have been broken by
changes in this release )

If you use Gentoo as a production server, this will be a good time to
set aside a seperate box for testing the side effects of this release
on your platform, and you should assume this release *will* affect you
in some way.

There are 4 Major types of failures [3]:

1: [build] failiures related to the removal of '.' from @INC [4] such 
as:
 - Can't locate inc:: ... in @INC (you may need to install the ... module)
 - Can't locate t:: ... in @INC (you may need to install the ... module)
 - do "foo.pl" failed, '.' is no longer in @INC; did you mean do "./foo.pl"?

2: [buildtime] The default of internal OP OP_SIBLING/OP_PARENT changing:
 - error: ... has no member named ‘op_sibling'
 
3: [runtime] Unescaped "{" in regex becomming a fatal error:
 - Unescaped left brace in regex is illegal in ...

4: [runtime] The removal of POSIX::tmpname in favour of File::Temp
 - Unimplemented: POSIX::tmpnam()

Our hope is to have all the in-tree bugs [5] fixed long in advance of
needing to stabilize Perl 5.26.

However, special efforts will have to be added for anything using an
overlay, and any of your private code ( such as things you've manually
installed into /opt  or /usr/local/ ) will need additional care as
these are outside the visibility of Gentoo Devs.

Please make sure to report any bugs you find that are clearly caused by
Perl 5.26 ( of course, first skim the lengthy list of known issues for
duplicates [6] ).

For any questions, please follow up in reply to this email, or ask
us on freenode.org#gentoo-perl

1: https://bugs.gentoo.org/show_bug.cgi?id=perl-5.26-unmask
2: https://bugs.gentoo.org/show_bug.cgi?id=612408
3: https://wiki.gentoo.org/wiki/Project:Perl/5.26_Known_Issues
4: https://wiki.gentoo.org/wiki/Project:Perl/Dot-In-INC-Removal
5: https://bugs.gentoo.org/show_bug.cgi?id=perl-5.26
6: https://bugs.gentoo.org/showdependencytree.cgi?id=613764_resolved=1


pgpJuYOFMNMX_.pgp
Description: OpenPGP digital signature


[gentoo-dev] [PATCH] toolchain-glibc.eclass: fix libm.so symlinking for live glibc

2017-08-08 Thread Sergei Trofimovich
The failure happens when live glibc- ebuild is installed:
 * QA Notice: Missing gen_usr_ldscript for libm-2.26.90.so
 * ERROR: sys-libs/glibc-::gentoo failed:
 *   add those ldscripts

The problem here is how upstream glibc version is detected:
dosym ../../$(get_libdir)/libm-${PV}.so $(alt_usrlibdir)/libm-${PV}.so

Change to use 'version.h' to pick upstream version.

Signed-off-by: Sergei Trofimovich 
---
 eclass/toolchain-glibc.eclass | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/eclass/toolchain-glibc.eclass b/eclass/toolchain-glibc.eclass
index 1d6a54a37f1..83d6293c6cb 100644
--- a/eclass/toolchain-glibc.eclass
+++ b/eclass/toolchain-glibc.eclass
@@ -1138,10 +1138,14 @@ toolchain-glibc_do_src_install() {
cp -a elf/ld.so "${ED}"$(alt_libdir)/$(scanelf -qSF'%S#F' 
elf/ld.so) || die "copying nptl interp"
fi
 
+   # Normally real_pv is ${PV}. Live ebuilds are exception, there we need
+   # to infer upstream version:
+   # '#define VERSION "2.26.90"' -> '2.26.90'
+   local upstream_pv=$(sed -n -r 's/#define VERSION "(.*)"/\1/p' 
"${S}"/version.h)
# Newer versions get fancy with libm linkage to include vectorized 
support.
# While we don't really need a ldscript here, portage QA checks get 
upset.
-   if [[ -e ${ED}$(alt_usrlibdir)/libm-${PV}.a ]] ; then
-   dosym ../../$(get_libdir)/libm-${PV}.so 
$(alt_usrlibdir)/libm-${PV}.so
+   if [[ -e ${ED}$(alt_usrlibdir)/libm-${upstream_pv}.a ]] ; then
+   dosym ../../$(get_libdir)/libm-${upstream_pv}.so 
$(alt_usrlibdir)/libm-${upstream_pv}.so
fi
 
# We'll take care of the cache ourselves
-- 
2.14.0




[gentoo-dev] Last Rites: Several obsolete, broken dev-php/PEAR-* packages

2017-08-08 Thread Brian Evans
# Brian Evans 

[gentoo-dev] Packages up for grabs

2017-08-08 Thread Amy Liffey
Hello,
The following packages are up for grabs:

x11-wm/afterstep
mail-client/nmh
dev-util/wsta
dev-util/bats
app-admin/yadm

Best regards,
Amy Liffey







signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Package up for grabs

2017-08-08 Thread tomjbe
Quoting Daniel Campbell (2017-08-07 22:38:53)
> On 08/06/2017 02:27 AM, tom...@gentoo.org wrote:
> > Quoting Daniel Campbell (2017-07-31 04:16:30)
> >> On 07/19/2017 02:33 AM, Amy Liffey wrote:
...
> >>
> > Ok, as I have done some quite Forth programming in the past, let me step in.
> > 
> > Thomas
> > 
> > 
> > 
> Sounds great. Would you like me to do the honors of updating
> metadata.xml later tonight?

Yes, please do as suggested. Be aware that I am just to start my holidays in
next days. I will be back in mid of september. Then I will be glad to help.

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