Re: [gentoo-dev] RFC: Ban dolib and libopts in EAPI 7

2016-10-13 Thread Daniel Campbell
On 10/13/2016 06:53 AM, Ulrich Mueller wrote: > Hi all, > > I suggest that we ban the dolib and libopts commands in EAPI 7. > > Rationale: > 1. There are about 60 instances of dolib in the tree. At least one >third of them appears to be wrong (e.g., should be replaced by >dolib.so for cor

Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: Add tc-check-openmp() function

2016-10-13 Thread M. J. Everitt
On 13/10/16 21:40, Michael Orlitzky wrote: > On 10/13/2016 04:35 PM, David Seifert wrote: >> +ewarn "Your current compiler does not support OpenMP" >> + >> +... >> + >> +die "Active compiler does not have required support > Hey, a message that isn't about comrel.

Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: Add tc-check-openmp() function

2016-10-13 Thread Michael Orlitzky
On 10/13/2016 04:35 PM, David Seifert wrote: > + ewarn "Your current compiler does not support OpenMP" > + > + ... > + > + die "Active compiler does not have required support Hey, a message that isn't about comrel. Since you're going to die(), isn't eerror more

[gentoo-dev] [PATCH] toolchain-funcs.eclass: Add tc-check-openmp() function

2016-10-13 Thread David Seifert
Hey all, I'd like to add a new function to toolchain-funcs, which presents a consist interface to users of packages somehow relying on OpenMP. Currently, (most) ebuilds relying on OpenMP test with tc-has-openmp and if OpenMP is not available, do something, like print a message and die, just print a

Re: [gentoo-dev] RFC: Ban dolib and libopts in EAPI 7

2016-10-13 Thread M. J. Everitt
On 13/10/16 15:04, Michał Górny wrote: > On Thu, 13 Oct 2016 15:53:16 +0200 > Ulrich Mueller wrote: > >> Hi all, >> >> I suggest that we ban the dolib and libopts commands in EAPI 7. >> >> Rationale: >> 1. There are about 60 instances of dolib in the tree. At least one >>third of them appears

Re: [gentoo-dev] Re: rfc: the demise of grub:0

2016-10-13 Thread Ian Stakenvicius
On 13/10/16 10:13 AM, Raymond Jennings wrote: > On Thu, Oct 13, 2016 at 7:01 AM, Fernando Rodriguez > mailto:cyklon...@gmail.com>> wrote: > > On 10/04/2016 06:24 PM, William Hubbs wrote: > > > > This would actually be another reason to get rid of grub-0, if it can't > > build on

Re: [gentoo-dev] Re: rfc: the demise of grub:0

2016-10-13 Thread Raymond Jennings
On Thu, Oct 13, 2016 at 7:01 AM, Fernando Rodriguez wrote: > On 10/04/2016 06:24 PM, William Hubbs wrote: > > > > This would actually be another reason to get rid of grub-0, if it can't > > build on one of our profiles, it will more than likely never be fixed > > upstream because they are now

Re: [gentoo-dev] RFC: Ban dolib and libopts in EAPI 7

2016-10-13 Thread Michał Górny
On Thu, 13 Oct 2016 15:53:16 +0200 Ulrich Mueller wrote: > Hi all, > > I suggest that we ban the dolib and libopts commands in EAPI 7. > > Rationale: > 1. There are about 60 instances of dolib in the tree. At least one >third of them appears to be wrong (e.g., should be replaced by >dol

Re: [gentoo-dev] Re: rfc: the demise of grub:0

2016-10-13 Thread Fernando Rodriguez
On 10/04/2016 06:24 PM, William Hubbs wrote: > > This would actually be another reason to get rid of grub-0, if it can't > build on one of our profiles, it will more than likely never be fixed > upstream because they are now focused on grub-2.x. grub-0 is 32-bit software. You could build it w

[gentoo-dev] RFC: Ban dolib and libopts in EAPI 7

2016-10-13 Thread Ulrich Mueller
Hi all, I suggest that we ban the dolib and libopts commands in EAPI 7. Rationale: 1. There are about 60 instances of dolib in the tree. At least one third of them appears to be wrong (e.g., should be replaced by dolib.so for correct mode). 2. libopts affects only dolib, while the more spec

Re: [gentoo-dev] New portage git sync behavior

2016-10-13 Thread Mike Gilbert
On Wed, Oct 12, 2016 at 2:51 PM, Mike Gilbert wrote: > On Wed, Oct 12, 2016 at 2:45 PM, konsolebox wrote: >> On Wed, Sep 21, 2016 at 11:02 AM, Mike Gilbert wrote: >>> Portage 2.3.1 changes the default behavior for git repositories to >>> sync with a depth of 1. If you are using a development tre