Re: [gentoo-dev] libpcre.so.3 - Compatibility with Debian

2016-08-10 Thread Kent Fredric
On Thu, 11 Aug 2016 00:10:53 +0100
James Le Cuirot  wrote:

> Hello all,
> 
> We, like almost everyone else and presumably upstream, install PCRE 8
> as libpcre.so.1. Debian, for reasons best known to themselves, install
> it as libpcre.so.3. With Ubuntu still being the most widely accepted
> "standard" Linux desktop, this presents a problem when dealing with
> pre-compiled binaries.
> 
> I have been working on a script to replace the rather lacking
> steam-games-meta ebuild (see steam-overlay). I'm very excited about
> releasing it soon as I think it is a major step forwards in our
> ability to easily run Steam without the official Ubuntu-based runtime.
> 
> Before I put it out there, I'd like to get Alien Isolation working
> properly. It links to libpcre.so.3. Hacking the binary might work but
> this isn't ideal and not always an option as some games use Valve's
> anti-cheat system, which is ruthless.
> 
> I have found that creating a symlink in /usr/lib that points
> to /lib/libpcre.so.1 works, except that when you run ldconfig, it
> automatically creates another symlink from /usr/lib/libpcre.so.1 to
> libpcre.so.3. If you create the first symlink in /lib instead then the
> existing /lib/libpcre.so.1 holds after running ldconfig. The latter
> location is therefore probably preferable.
> 
> Would anyone have any issue with adding this to our libpcre package? I
> don't foresee any problems. libpcre.so would obviously still point to
> libpcre.so.1. I'm pretty sure there will never be another libpcre.so.3
> as upstream have released PCRE2 as libpcre2, effectively an entirely
> separate library.
> 
> I could create a Steam-specific package for this but that would mean
> adding some additional Steam-specific location to ld.so.conf, which
> I'm trying to avoid. It would be nice to solve this generally anyway.
> 
> Thoughts?
> 

I'd say this is the sort of thing that has more application than just
steam.

I'd just suggest a libpcre-debian package, which provides the .so via
symlink and dependency mechanisms.

That way *if* anything happens in the future, we can just introduce
blockers in the right place.

Then the applicable stuff depends on libpcre-debian for the forseeable
future.

And this way, if debian do anything else magical, we can probably copy
them and build a libpcre like they do for interop.

Essentially, the point here is to see debians libpcre is a competing
implementation, even though we can locally pretend they're not at the
technical level, it works as " conceptual model " for the problem we
have.



pgp2NHAFX50Jt.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Empty project: LXDE

2016-08-10 Thread Hanno Böck
On Sun, 07 Aug 2016 10:22:28 +0200
Pacho Ramos  wrote:

> Now https://wiki.gentoo.org/wiki/Project:LXDE is empty
> 
> Feel free to join, anyway, if I don't misremember, LXDE is dead for a
> long time in favor of LXQT... in that case treecleaning the packages
> would also be an option

Oh...

I'm actually using lxde and I have recently pushed a bunch of memory
safety fixes to upstream that were a result of my address sanitizer
testing.

LXDE upstream isn't totally dead, occasionally releases with fixes
happen, yet they're slow.

I'll look that I maintain some of the stuff, yet I'd prefer if I'd be
not the only one.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42



Re: [gentoo-dev] Empty project: LXDE

2016-08-10 Thread james

On 08/10/2016 04:07 PM, Tom H wrote:

On Wed, Aug 10, 2016 at 5:06 PM, james  wrote:


I have not had the time to migrate things to lxqt, despite tinkering
around with it. The next system I install, will go direct to lxqt. I
left KDE for many bloated reasons. I sure hope lxqt is light weight,
easy to setup and config and stable.


If LXQT's too bloated for you, try Lumina:

https://lumina-desktop.org/

There's an ebuild.




Yep the ebuild is clean and well written; I shall put that one in my
EAPI-6 reference folder

I looked at some of the code (https://github.com/trueos/lumina), 
impressive, clean and well organized. I do like what I've seen on quick,

first glance.


I did a quick search and did not find a comparison of lumina to lxqt. 
I'd like to see a feature comparison to lxqt; gotta ref on the 
comparison? I'm interested but cannot commit to a timeline for some test 
deployments. For sure this DE is aimed at security and flexibility

and I do like that.

thx Tom,
James




Re: [gentoo-dev] Asking for permission to update packages from LINGUAS to L10N

2016-08-10 Thread Ben de Groot
On 11 August 2016 at 04:22, NP-Hardass  wrote:
> Looks to me like we can't edit that eclass in place, so if we are to
> keep it, we should probably revbump it, update the -r1 to L10N, and add
> a deprecation warning to the old eclass to help maintainers migrate over.
>
> Any opinions?  I'd be happy work on the revbump for the eclass if we
> decide to go that route.  CC'ing yngwin since it is his eclass.

Feel free to revbump it and change it to whatever works for current needs.

-- 
Cheers,

Ben | yngwin
Gentoo developer



[gentoo-dev] libpcre.so.3 - Compatibility with Debian

2016-08-10 Thread James Le Cuirot
Hello all,

We, like almost everyone else and presumably upstream, install PCRE 8
as libpcre.so.1. Debian, for reasons best known to themselves, install
it as libpcre.so.3. With Ubuntu still being the most widely accepted
"standard" Linux desktop, this presents a problem when dealing with
pre-compiled binaries.

I have been working on a script to replace the rather lacking
steam-games-meta ebuild (see steam-overlay). I'm very excited about
releasing it soon as I think it is a major step forwards in our ability
to easily run Steam without the official Ubuntu-based runtime.

Before I put it out there, I'd like to get Alien Isolation working
properly. It links to libpcre.so.3. Hacking the binary might work but
this isn't ideal and not always an option as some games use Valve's
anti-cheat system, which is ruthless.

I have found that creating a symlink in /usr/lib that points
to /lib/libpcre.so.1 works, except that when you run ldconfig, it
automatically creates another symlink from /usr/lib/libpcre.so.1 to
libpcre.so.3. If you create the first symlink in /lib instead then the
existing /lib/libpcre.so.1 holds after running ldconfig. The latter
location is therefore probably preferable.

Would anyone have any issue with adding this to our libpcre package? I
don't foresee any problems. libpcre.so would obviously still point to
libpcre.so.1. I'm pretty sure there will never be another libpcre.so.3
as upstream have released PCRE2 as libpcre2, effectively an entirely
separate library.

I could create a Steam-specific package for this but that would mean
adding some additional Steam-specific location to ld.so.conf, which I'm
trying to avoid. It would be nice to solve this generally anyway.

Thoughts?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpLo5hr1jlUL.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Asking for permission to update packages from LINGUAS to L10N

2016-08-10 Thread James Le Cuirot
On Wed, 10 Aug 2016 16:22:24 -0400
NP-Hardass  wrote:

> I was going through my packages to make sure that I was compliant with
> this change, and found that I was not.  The l10n eclass makes use of
> the LINGUAS USE_EXPAND and isn't covered in the tracker bug.  I
> attempted to read through the old thread to see if someone mentioned
> that eclass, but I must have missed it if someone mentioned it.  Are
> we EOL'ing that eclass, or keeping it (update or revbump)?

I asked mgorny about it. He said it's not his playground. I was
dealing with MakeMKV, which is an awkward one, but in the end I simply
decided to drop the flags and install all the files. I'm not sure if
using the eclass makes sense any more as it revolves around keeping the
flags up-to-date. In most cases, you're not supposed to use the flags
any more and when you are, it's for optional language packs that
require additional downloads. The eclass can't help you there.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpDCFYtFsniy.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] Empty project: LXDE

2016-08-10 Thread Tom H
On Wed, Aug 10, 2016 at 5:06 PM, james  wrote:
>
> I have not had the time to migrate things to lxqt, despite tinkering
> around with it. The next system I install, will go direct to lxqt. I
> left KDE for many bloated reasons. I sure hope lxqt is light weight,
> easy to setup and config and stable.

If LXQT's too bloated for you, try Lumina:

https://lumina-desktop.org/

There's an ebuild.



[gentoo-dev] Last rites: net-misc/quickshare

2016-08-10 Thread Michael Palimaka
# Michael Palimaka  (10 Aug 2016)
# Fails to build. Dead upstream.
# Masked for removal in 30 days. Bug 443812.
net-misc/quickshare



[gentoo-dev] Last rites: net-im/indicator-messages

2016-08-10 Thread Michael Palimaka
# Michael Palimaka  (10 Aug 2016)
# Fails to build. Dead upstream.
# Masked for removal in 30 days. Bug 543154.
net-im/indicator-messages



[gentoo-dev] Last rites: media-plugins/gmpc-wikipedia

2016-08-10 Thread Michael Palimaka
# Michael Palimaka  (10 Aug 2016)
# Requires vulnerable version of webkit-gtk. Dead upstream.
# Masked for removal in 30 days. Bug 584176.
media-plugins/gmpc-wikipedia



Re: [gentoo-dev] Asking for permission to update packages from LINGUAS to L10N

2016-08-10 Thread NP-Hardass
On 06/23/2016 05:04 PM, Ulrich Mueller wrote:
> I have created tracker bug https://bugs.gentoo.org/586734 for the
> LINGUAS to L10N conversion, and started to file bugs for individual
> packages. (Starting with lightweight stuff like metapackages, so users
> won't spend too much time with rebuilding if they don't get their L10N
> configuration immediately right.)
> 
> However, it looks like filing bugs for all affected packages is going
> to be tedious. Therefore I am asking for permission to update ebuilds
> for the easy cases directly, e.g. when the change is only a simple
> renaming from linguas_* to l10n_*.
> 
> Please speak up if you don't want your packages to be touched and
> prefer bugs to be filed for them.
> 
> Ulrich
> 

I was going through my packages to make sure that I was compliant with
this change, and found that I was not.  The l10n eclass makes use of the
LINGUAS USE_EXPAND and isn't covered in the tracker bug.  I attempted to
read through the old thread to see if someone mentioned that eclass, but
I must have missed it if someone mentioned it.  Are we EOL'ing that
eclass, or keeping it (update or revbump)?

Looks to me like we can't edit that eclass in place, so if we are to
keep it, we should probably revbump it, update the -r1 to L10N, and add
a deprecation warning to the old eclass to help maintainers migrate over.

Any opinions?  I'd be happy work on the revbump for the eclass if we
decide to go that route.  CC'ing yngwin since it is his eclass.

-- 
NP-Hardass



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Last rites: dev-python/pyechonest

2016-08-10 Thread Michael Palimaka
# Michael Palimaka  (10 Aug 2016)
# Interface to an API that has been shut down.
# Masked for removal in 30 days. Bug 587976.
dev-python/pyechonest



Re: [gentoo-dev] Empty project: LXDE

2016-08-10 Thread james

On 08/10/2016 01:46 PM, Pacho Ramos wrote:

El mié, 10-08-2016 a las 07:12 -0500, james escribió:

On 08/10/2016 12:46 AM, Raymond Jennings wrote:


Hey, just a heads up as a user.  I'm currently using LXDE.


+_1
(correctly located).



On Sun, Aug 7, 2016 at 1:22 AM, Pacho Ramos > wrote:

Now https://wiki.gentoo.org/wiki/Project:LXDE
 is empty

Feel free to join, anyway, if I don't misremember, LXDE is dead
for a
long time in favor of LXQT... in that case treecleaning the
packages
would also be an option

Thanks




me too. I have it


LXDE, that is, and I like it very much.

>> on several (older) systems. Hopefully there will be a

news item, when the time comes, with instructions on migration to
lxqt or a listing of other light weight replacement options, with a
wee  bit of migration detail


hth,
James



What is needed apart of emerging the new desktop and starting to use
it?


Changes in config files? Has this been tested? Surely folks have a 
myriad of setups with lxde and those do not automagically migrate to 
lxqt, or do they?  If/when lxde goes away are there other similar 
choices in lieu of lxqt ? The reason I say this, is the lxde installs I 
have done (all 3) have had extensive hacking to get things to work. But 
once that was done, they (lxde setups) require little to nothing, which 
strongly appeals to me. Hack it once and done.


For example on usb, I gave up and just installed udevil. Most DE users 
expect usb usage to be ubiquitous. I know I did before I ever installed 
lxde. likewise dvd burning, particularly double sided medias. Others 
have different solutions. Terminal windows. I spent days reading and 
hacking to get a Kludge I like. I have not had the time to migrate 
things to lxqt, despite tinkering around with it. The next system I 
install, will go direct to lxqt. I left KDE for many bloated reasons. I 
sure hope lxqt is light weight, easy to setup and config and stable.
I have a deep disdain for DEs that require adming work. I want to do my 
admin and dev work on clusters, not the rendering/command/control system

know as a workstation.

To me, the entirety of KDE should be replaced with aggressive and 
ubiquitious clusters, where any mixture of codes, kde included can be 
run. KDE is an OS, and a bloated one at that, that imposes itself on my 
DE. I want no part of the KDE vision, nor any other DE that does more 
than provide a fast environment to display apps. There is a growing 
crowd of folks that like minimal DE environments, imho. Advances should 
be in the cluster or a single local server, imho. So, actually, I'd like 
to keep lxde into perpetuity and it'd be perfect to train folks for 
proxy-maint, imho. Safe, stable, extraordinarily useful and not critical 
to anything in the core system. Folks do not have use it.
Old, stable codes are worth their weight in gold, but we must be trendy, 
right? So we need to removed lxde, right?



I mean thing about it from a different prospective. I have a vintage 
car, not being maintained any more by the manufacturer. It's worthless 
now, right? Let's just toss it away so nobody can use it or maintain it 
right. Turns out old vintige cars are worth a bloody fortune now days.
Who is to say in 20 or 30 years, these old code will not be worth 
extreme value to folks? It costs nothing to just park the codes and 
ignore them. Mark lxde as you like and move it to an overlay and let it 
sit idle, if you have to clean the tree, that's my wisdom on the matter.


My (college aged kids) get down boxes of old electronic toys to play 
with every christmas. It's a blast and friend of all ages enjoy this one 
a year treat too. Whos to say and old DE might not be the same

experience one day?


But, I suspect you are implying the correct answer is "Nothing". I'm 
just saying if/when lxde goes away or a news item first comes out and 
encourages lxde folks to migrate  to lxqt, then some detail as to the 
situation and easy migration steps, shows a kinder  and gentler Gentoo. 
I think that's this is one of the proxy-maint exit test questions; when 
is a News item is warranted. So this is  my opinion, particular if an 
update removes lxde and installs lxqt; a news item is then definitely 
warranted.


I'm not against keeping lxde around, at all. But from the last year of
experiences with tree cleaning it is more of a religious agenda than 
removing what has to be removed. I know, I have dozens of old codes 
sitting quite peacefully in /usr/local and working just fine.


But I do not enjoy the pressures of being a gentoo dev, so do what you 
have to do; news items are great. ymmv. I recommend that you convert 
your (gentoo dev) burdens into a peaceful pleasure as you see fit.


Now if you are asking what's broken with news items, then I have an 
idea, so they do not have to be avoided. Require all news items to be
very short. A 

[gentoo-dev] Last rites: app-mobilephone/smssend and dev-libs/skyutils

2016-08-10 Thread Michael Palimaka
# Michael Palimaka  (10 Aug 2016)
# Requires insecure SSLv3. Unmaintained. Upstream disappeared.
# Masked for removal in 30 days. Bug 590732.
app-mobilephone/smssend
dev-libs/skyutils



Re: [gentoo-dev] Empty project: LXDE

2016-08-10 Thread Pacho Ramos
El mié, 10-08-2016 a las 07:12 -0500, james escribió:
> On 08/10/2016 12:46 AM, Raymond Jennings wrote:
> > 
> > Hey, just a heads up as a user.  I'm currently using LXDE.
> > 
> > On Sun, Aug 7, 2016 at 1:22 AM, Pacho Ramos  > > wrote:
> > 
> > Now https://wiki.gentoo.org/wiki/Project:LXDE
> >  is empty
> > 
> > Feel free to join, anyway, if I don't misremember, LXDE is dead
> > for a
> > long time in favor of LXQT... in that case treecleaning the
> > packages
> > would also be an option
> > 
> > Thanks
> > 
> > 
> 
> +1::
> 
> me too. I have it on several (older) systems. Hopefully there will be
> a 
> news item, when the time comes, with instructions on migration to
> lxqt or a listing of other light weight replacement options, with a
> wee 
> bit of migration detail
> 
> 
> hth,
> James
> 

What is needed apart of emerging the new desktop and starting to use
it? 



Re: [gentoo-dev] Empty project: LXDE

2016-08-10 Thread james

On 08/10/2016 09:44 AM, Nathan Zachary wrote:

On 10/08/16 07:12, james wrote:

On 08/10/2016 12:46 AM, Raymond Jennings wrote:

Hey, just a heads up as a user.  I'm currently using LXDE.

On Sun, Aug 7, 2016 at 1:22 AM, Pacho Ramos > wrote:

Now https://wiki.gentoo.org/wiki/Project:LXDE
 is empty

Feel free to join, anyway, if I don't misremember, LXDE is dead
for a
long time in favor of LXQT... in that case treecleaning the packages
would also be an option

Thanks




+1::

me too. I have it on several (older) systems. Hopefully there will be
a news item, when the time comes, with instructions on migration to
lxqt or a listing of other light weight replacement options, with a
wee bit of migration detail


hth,
James


I was under the impression that both LXDE and LXQT would continue
development, but that LXQT would be favoured.  Is there an official
statement that LXDE is dead?

Cheers,
Nathan Zachary


Upstream:: NO :: Release date and age   February 21, 2016

But upstream is dev light, to say the least. Here at gentoo,
the dev maint situation for lxde is:: skinny, at best [1].

So I guess dev are reading the tea leaves. I'm sure a proxy-maintainer 
stepping forward for either,  would be keenly appreciated, but lxqt has 
always been on my scope ymmv. If you believe upstream, then lxqt is

the future.


[1] https://wiki.gentoo.org/wiki/Project:LXDE

hth,
James






Re: [gentoo-dev] Empty project: LXDE

2016-08-10 Thread Nathan Zachary
On 10/08/16 07:12, james wrote:
> On 08/10/2016 12:46 AM, Raymond Jennings wrote:
>> Hey, just a heads up as a user.  I'm currently using LXDE.
>>
>> On Sun, Aug 7, 2016 at 1:22 AM, Pacho Ramos > > wrote:
>>
>> Now https://wiki.gentoo.org/wiki/Project:LXDE
>>  is empty
>>
>> Feel free to join, anyway, if I don't misremember, LXDE is dead
>> for a
>> long time in favor of LXQT... in that case treecleaning the packages
>> would also be an option
>>
>> Thanks
>>
>>
>
> +1::
>
> me too. I have it on several (older) systems. Hopefully there will be
> a news item, when the time comes, with instructions on migration to
> lxqt or a listing of other light weight replacement options, with a
> wee bit of migration detail
>
>
> hth,
> James
>
I was under the impression that both LXDE and LXQT would continue
development, but that LXQT would be favoured.  Is there an official
statement that LXDE is dead?

Cheers,
Nathan Zachary





signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Empty project: LXDE

2016-08-10 Thread james

On 08/10/2016 12:46 AM, Raymond Jennings wrote:

Hey, just a heads up as a user.  I'm currently using LXDE.

On Sun, Aug 7, 2016 at 1:22 AM, Pacho Ramos > wrote:

Now https://wiki.gentoo.org/wiki/Project:LXDE
 is empty

Feel free to join, anyway, if I don't misremember, LXDE is dead for a
long time in favor of LXQT... in that case treecleaning the packages
would also be an option

Thanks




+1::

me too. I have it on several (older) systems. Hopefully there will be a 
news item, when the time comes, with instructions on migration to
lxqt or a listing of other light weight replacement options, with a wee 
bit of migration detail



hth,
James



Re: [gentoo-dev] [RFC] new eselect module: compiler

2016-08-10 Thread Fabian Groffen
On 10-08-2016 08:39:26 +0800, Lei Zhang wrote:
> 2016-08-09 13:58 GMT+08:00 Fabian Groffen :
> > As a question to Lei, I'm wondering why you chose eselect compiler, and
> > not gcc-config to manage the links.  In a way, gcc-config is tailored
> > towards gcc, but it does a lot of things also for the environment.  With
> > clang, from my experience, you just want it as drop-in replacement for
> > gcc as it doesn't give you too much issues (on Darwin at least).
> 
> In its current form, gcc-config specializes in handling different
> versions of gcc. If we extend it to cover other compilers (and rename
> it to cc-config as James suggested), should it handle different
> versions of clang? What about different versions of icc?
> 
> I'm just afraid gcc-config would become too complex that way, so I
> prefer a simpler approach: let eselect-compiler be version-agnostic.
> Then we can have clang-config to handle the versioning of clang,
> icc-config to handle icc, etc.

Alright.  As Zac pointed out, my gcc-config idea was a bad one.  And it
wouldn't work very well with icc and many other compilers as well.

Reason I thought about it, is that I'd like to avoid setting
CC/CXX/OBJC/OBJCXX/BUILD_CC/BUILD_CXX and whatnot.  Currently,
toolchain-funcs' tc-getPROG does some magic to produce TRIPLET-PROG kind
of thing, and configure gets the triplet passed by Portage as well.  I
was hoping for it to find TRIPLET-clang at some point with all the
tooling in place without "hard-overriding" CC in make.conf.

Fabian


-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: Digital signature