[gentoo-dev] Last Rites: dev-perl/cdk-perl

2016-08-02 Thread Kent Fredric 
# Kent Fredric  (3 Aug 2016)
# No reverse dependencies, was never clear why it was in tree,
# upstream stagnant, dev-libs/cdk is mostly unmaintained.
#
# Please voice concerns on bug 575036 if you still need this.
# Removal in 30 days.
dev-perl/cdk-perl


pgpWMkH4XTW08.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Package up for grab

2016-08-02 Thread Marco Ziebell 

I'm using the new "skype alpha for linux" for some weeks and can say that it is
more stable than the other version ever was. 
- writing and calling is working out of the box
- it looks more or less like the windows version

It ships a "ffmpeg.so" and a "libnode.so".

The only thing I had to emerge on my amd64-XFCE systems was the gnome-keyring,
but that's it!

--
Marco

Am Wed, 3 Aug 2016 11:15:30 +0800
schrieb Jason Zaman :

> On Tue, Aug 02, 2016 at 04:08:34PM -0700, Jigme Datse Rasku wrote:
> > I'd have to say, there is likely a reason we are looking for a new
> > maintainer.  I don't know what is involved, but I might be interested.
> > Might be wanting to start that direction...  
> 
> There is a new alpha skype for linux too now that should be looked into.
> I have no idea how stable it is but it's probably not much worse than
> what we currently have :P.
> 
> https://community.skype.com/t5/Linux/Skype-for-Linux-Alpha-and-calling-on-Chrome-amp-Chromebooks/td-p/4434299
> 
> -- Jason
> 
> > On Aug 2, 2016 16:03, "M. J. Everitt"  wrote:
> >   
> > > On 02/08/16 23:43, Matthew Thode wrote:  
> > > > On 08/02/2016 04:15 PM, Amy Winston wrote:  
> > > >> net-im/skype
> > > >>
> > > >> Anyone interested?
> > > >>
> > > >>  
> > > > I feel like this is a trick question :P
> > > >  
> > > +2
> > >
> > >  
>

[gentoo-dev] Last rites: sci-calculators/qalculate-{bases|currency|units}

2016-08-02 Thread Matthias Maier 
# Matthias Maier  (3 Aug 2016)
# Masked for removal in 30 days. Obsolete packages that are now part of
# sci-libs/libqalculate and/or sci-calculators/qalculate-gtk
sci-calculators/qalculate-bases
sci-calculators/qalculate-currency
sci-calculators/qalculate-units


signature.asc
Description: PGP signature

[gentoo-dev] Last rites: dev-perl/Test-Tester

2016-08-02 Thread Kent Fredric 
# Kent Fredric  (3 Aug 2016)
# Contents superseded by virtual/perl-Test-Simple >=1.1.10
# and now only creates depdendency resolution headaches.
#
# Please migrate overlay dependencies to an exclusive
# >=virtual/perl-Test-Simple-1.1.10
#
# Removal in 30 days. Bug 584238
dev-perl/Test-Tester


pgpNRQRhOdXQh.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Package up for grab

2016-08-02 Thread Jason Zaman 
On Tue, Aug 02, 2016 at 04:08:34PM -0700, Jigme Datse Rasku wrote:
> I'd have to say, there is likely a reason we are looking for a new
> maintainer.  I don't know what is involved, but I might be interested.
> Might be wanting to start that direction...

There is a new alpha skype for linux too now that should be looked into.
I have no idea how stable it is but it's probably not much worse than
what we currently have :P.

https://community.skype.com/t5/Linux/Skype-for-Linux-Alpha-and-calling-on-Chrome-amp-Chromebooks/td-p/4434299

-- Jason

> On Aug 2, 2016 16:03, "M. J. Everitt"  wrote:
> 
> > On 02/08/16 23:43, Matthew Thode wrote:
> > > On 08/02/2016 04:15 PM, Amy Winston wrote:
> > >> net-im/skype
> > >>
> > >> Anyone interested?
> > >>
> > >>
> > > I feel like this is a trick question :P
> > >
> > +2
> >
> >

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

2016-08-02 Thread Mike Gilbert 
On Tue, Aug 2, 2016 at 8:08 PM, Mart Raudsepp  wrote:
> Also, how are they exposed in cpuinfo, do we have first patches
> for cpuid2cpuflags?

cpuid2cpuflags does not use /proc/cpuinfo since version 2.

A patch adding detection for the various avx512 extensions has been
merged upstream.

https://github.com/mgorny/cpuid2cpuflags/commit/8b020e51773c912cca3d6983bd883a6ff08ad637

> tl;dr: Concerned about prematurely adding things without knowing of consumer 
> examples

I agree that there is no point in adding the values to
cpu_flags_x86.desc until there are some ebuild ready to utilize them.

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

2016-08-02 Thread Mart Raudsepp 
Ühel kenal päeval, T, 02.08.2016 kell 15:25, kirjutas Michał Górny:
> On Mon, 1 Aug 2016 17:15:41 -0400
> Mike Gilbert  wrote:
> 
> > On Mon, Aug 1, 2016 at 5:08 PM, David Seifert 
> > wrote:
> > > Dear friends,
> > > while version bumping sci-libs/fftw, I've noticed our
> > > CPU_FLAGS_X86
> > > list could be expanded a bit:
> > > 
> > > avx512 - introduced with Skylake and Knights Landing
> > 
> > According to Wikipedia, "AVX-512 consists of multiple extensions
> > not
> > all meant to be supported by all processors implementing them."
> > 
> > https://en.wikipedia.org/wiki/AVX-512
> > 
> > https://en.wikipedia.org/wiki/CPUID#EAX.3D7.2C_ECX.3D0:_Extended_Fe
> > atures
> 
> Also https://bugs.gentoo.org/show_bug.cgi?id=588628.

Do we actually want to be fast in adding these things, or do we want to
wait for any actual consumers to be possible to start consuming it
right away? Like with all these different variants, will consumers
actually group the variants in the same way and will we be able to map
things cleanly in ebuilds in the future?
Though I guess there are already potential consumers out there that
people have already looked at and I've just not kept up with IRC or
something :)

Also, how are they exposed in cpuinfo, do we have first patches
for cpuid2cpuflags? Since what kernel version are they exposed in
cpuinfo, is it a flag for each CPUID capability? What variants do each
CPU implementing any expose, maybe all CPUs doing e.g avx512f all also
do avx512dq - perhaps all consumers would make such assumptions and
assume things based on real world CPUs? Or maybe all consumers of some
of the variants will always do runtime detection themselves and we
won't even use that flag in an IUSE ever?

tl;dr: Concerned about prematurely adding things without knowing of
consumer examples


Mart

Re: [gentoo-dev] Package up for grab

2016-08-02 Thread Jigme Datse Rasku 
I'd have to say, there is likely a reason we are looking for a new
maintainer.  I don't know what is involved, but I might be interested.
Might be wanting to start that direction...

On Aug 2, 2016 16:03, "M. J. Everitt"  wrote:

> On 02/08/16 23:43, Matthew Thode wrote:
> > On 08/02/2016 04:15 PM, Amy Winston wrote:
> >> net-im/skype
> >>
> >> Anyone interested?
> >>
> >>
> > I feel like this is a trick question :P
> >
> +2
>
>

Re: [gentoo-dev] Package up for grab

2016-08-02 Thread M. J. Everitt 
On 02/08/16 23:43, Matthew Thode wrote:
> On 08/02/2016 04:15 PM, Amy Winston wrote:
>> net-im/skype
>>
>> Anyone interested?
>>
>>
> I feel like this is a trick question :P
>
+2



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package up for grab

2016-08-02 Thread Matthew Thode 
On 08/02/2016 04:15 PM, Amy Winston wrote:
> net-im/skype
> 
> Anyone interested?
> 
> 
I feel like this is a trick question :P

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Package up for grab

2016-08-02 Thread Amy Winston 
net-im/skype

Anyone interested?

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

2016-08-02 Thread Vadim A. Misbakh-Soloviov 
By the way, I know that this is not a bugzilla's mirror, but it seems you did 
something wrong wile bumping. For now it refuses to build on Broadwell telling
> fftw-3.3.5/simd-support/simd-avx2.h:43:2: error: #error "compiling simd-
avx2.h without avx2 support"

Although avx2 do exist in cpuinfo (and in cpuflags_x86 too, although there is 
no such flag for fftw itself).

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

2016-08-02 Thread Michał Górny 
On Mon, 1 Aug 2016 17:15:41 -0400
Mike Gilbert  wrote:

> On Mon, Aug 1, 2016 at 5:08 PM, David Seifert  wrote:
> > Dear friends,
> > while version bumping sci-libs/fftw, I've noticed our CPU_FLAGS_X86
> > list could be expanded a bit:
> >
> > avx512 - introduced with Skylake and Knights Landing
> 
> According to Wikipedia, "AVX-512 consists of multiple extensions not
> all meant to be supported by all processors implementing them."
> 
> https://en.wikipedia.org/wiki/AVX-512
> 
> https://en.wikipedia.org/wiki/CPUID#EAX.3D7.2C_ECX.3D0:_Extended_Features

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

-- 
Best regards,
Michał Górny



pgppczbfoB3Y7.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

2016-08-02 Thread Michał Górny 
On Tue, 2 Aug 2016 10:04:46 -0300
Guilherme Amadio  wrote:

> On Mon, Aug 01, 2016 at 11:08:47PM +0200, David Seifert wrote:
> > Dear friends,
> > while version bumping sci-libs/fftw, I've noticed our CPU_FLAGS_X86
> > list could be expanded a bit:
> 
> I like the idea of expanding the list of CPU_FLAGS_X86, and having flags
> for other arches too, but I would be in favor of dropping the _X86
> suffix and using CPU_FLAGS for all arches. Your machine most likely will
> only have one kind anyway. Not sure what others think about it, though.

One kind is the reason why they are split -- so we can hide
CPU_FLAGS_X86 on non-x86 CPUs etc.

-- 
Best regards,
Michał Górny



pgpKkXakw6Lda.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Augmenting the CPU_FLAGS_X86 list and creating CPU_FLAGS_PPC + CPU_FLAGS_ARM

2016-08-02 Thread Guilherme Amadio 
On Mon, Aug 01, 2016 at 11:08:47PM +0200, David Seifert wrote:
> Dear friends,
> while version bumping sci-libs/fftw, I've noticed our CPU_FLAGS_X86
> list could be expanded a bit:

I like the idea of expanding the list of CPU_FLAGS_X86, and having flags
for other arches too, but I would be in favor of dropping the _X86
suffix and using CPU_FLAGS for all arches. Your machine most likely will
only have one kind anyway. Not sure what others think about it, though.

> avx512 - introduced with Skylake and Knights Landing

Only Skylake Xeons (yet to be launched) will support AVX512, and
as mentioned in another email, the subsets supported by Skylake and
KNL are a bit different. So, adding each subset should be better
(e.g. avx512f, avx512cd, avx512er, etc).

> I also propose creating a CPU_FLAGS_PPC variable containing (at least):
> 
> altivec - PowerPC's SSE
> vsx - PowerPC's AVX
> 
> Finally, I also propose creating CPU_FLAGS_ARM variable containing:
> 
> neon
> 
> Any ideas? Currently cpu-feature flags for non-x86 are package local,
> whereas making them globally available makes masking easier for non-
> applicable archs etc. and makes enabling them easier for users.

Masking flags is not needed if they are determined from /proc/cpuinfo.

Cheers,
—Guilherme