[gentoo-dev] Re: lua upgrade plan

[Duncan]

William Hubbs posted on Sat, 01 Jul 2017 11:53:59 -0500 as excerpted:

> See this article for why using liblua as a shared library is not
> recommended.
> 
> http://article.gmane.org/gmane.comp.lang.lua.general/18519
> 
> Yes, it talks about the interpretor, but it goes further and really
> discourages even making a shared library available.

PMFJI, but...

That reply is from 2005 and is apparently specific to (32-bit) x86's 
extreme shortage of general purpose registers.  Back then it made sense 
as 32-bit x86 was the dominant arch, both for gentoo, and (apparently) 
for that lua discussion (which was in the debian context).

That x86 general lack of registers was one of the big pressures behind 
the switch to amd64, before system memory sizes increased to 4GB+, and 
applies far less to today's dominant amd64, with x86 now legacy/embedded.

Now it may well be that lua performance remains register sensitive even 
with the increased number of registers available in amd64 and other 
modern archs, but quoting an 11+-year-old email written in the extremely 
register-restricted 32-bit x86 context does little to argue that point.

So... got any equivalent links to posts with more modern figures?


All that said, in FLOSS, he who volunteers, makes the rules, and 
particularly given the upstream opposition meaning more gentoo-level work 
required, if there's nobody willing to support lua in gentoo with dynamic 
linking...

... people unable or unwilling to volunteer to support their preferred 
alternative get to live with one they don't like, whether that be 
accepting what their existing distro provides even if it's not optimal, 
switching to another, or supporting their own patches or builds apart 
from gentoo.

At least gentoo makes the latter case relatively easy compared to some 
distros.  I did it with kde twice, when gentoo/kde wasn't supporting 
builds without semantic-desktop. =:^)

And in this case it appears there's even someone already doing it and 
making their work public via the lua overlay. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

[gentoo-dev] Maintainer-needed eclasses

[Michał Górny]

Hi, everyone.

I'm sending a complete list of eclasses that do not have an active
maintainer (or lack a maintainer info). Please take a look at it and see
if you can take up some of them.

alternatives.eclass
aspell-dict-r1.eclass
bsdmk.eclass
cannadic.eclass
common-lisp-common.eclass
common-lisp.eclass
confutils.eclass [@DEAD]
db-use.eclass
font-ebdftopcf.eclass
fox.eclass
freebsd.eclass
freedict.eclass
games-mods.eclass
git-2.eclass [deprecated]
gkrellm-plugin.eclass
gnatbuild.eclass
gnatbuild-r1.eclass
gnuconfig.eclass [supposedly DEAD but used]
l10n.eclass
makeedit.eclass [probably DEAD w/ false positive]
myspell.eclass
myspell-r2.eclass
openib.eclass
qmail.eclass [qmail team was disbanded]
scsh.eclass
ssl-cert.eclass
stardict.eclass
vim-doc.eclass
waf-utils.eclass


-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] Last rites: 12 more packages (broken, obsolete deps)

[Michał Górny]

On sob, 2017-07-01 at 22:51 +0200, Matthias Schwarzott wrote:
> Am 05.06.2017 um 20:13 schrieb Michał Górny:
> > 
> > # Michał Górny  (05 Jun 2017)
> > # (on behalf of Treecleaner project)
> > # Unmaintained in Gentoo. The current Gentoo version no longer builds.
> > # Removal in 30 days. Bug #602820.
> > media-plugins/vdr-xineliboutput
> > 
> 
> I like to take this package.
> It is one of a very small number of pure software output possibilities
> of vdr needed for development.
> 
> There is an new upstream version available that builds.
> 

Please add a note on the bug so nobody accidentally removes it before
you fix it.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] Last rites: 12 more packages (broken, obsolete deps)

[Matthias Schwarzott]

Am 05.06.2017 um 20:13 schrieb Michał Górny:
> 
> # Michał Górny  (05 Jun 2017)
> # (on behalf of Treecleaner project)
> # Unmaintained in Gentoo. The current Gentoo version no longer builds.
> # Removal in 30 days. Bug #602820.
> media-plugins/vdr-xineliboutput
> 

I like to take this package.
It is one of a very small number of pure software output possibilities
of vdr needed for development.

There is an new upstream version available that builds.

Regards
Matthias

Re: [gentoo-dev] lua upgrade plan

[William Hubbs]

On Sat, Jul 01, 2017 at 01:16:02PM +0500, Azamat Hackimov wrote:
> 2017-06-30 22:16 GMT+05:00 William Hubbs :
> 
> > All,
> >
> > Upstream does not support liblua as a shared library, and they do not
> > support installing multiple versions of lua onto a system. After
> > conferring with the other lua maintainer, the decision has been made to
> > remove this custom support from our lua package as well. This has been
> > talked about many times upstream.
> 
> 
> Lua devs very "hostile" to Linux distributers. I don't see why we should do
> as they want to do.
> They not have open vcs to simply see what they changes in new release, they
> don't accepts
> patches for system integration. They didn't even elementary easy-to-use
> build system. Just
> look to another distributives, they all do versioned and shared libraries
> of Lua 5.{1,2,3}. Fedora
> devs did custom Autotools-based buildsystem, Debian - provided pkg-config
> files. There also
> exists excellent LuaDist framework - still outdated, yes, but we can take
> from them CMake
> buildsystem to provide better integration into Gentoo enviroment. You have
> so many options
> but you still want to follow unwelcome Lua rules.

It is Gentoo's policy to stay as close to upstream as possible. However,
there are a couple of things that I can say about lua from what I've
seen so far.


> > They do not want it, and using liblua as a shared library causes
> > performance issues.
> >
> 
> Why, we live in XXI century, where this argument came from? What about
> security, did you
> forgot about it? How do you planning to do backward compatibility with old
> lua5.1 libraries
> and projects? They definitely have breakage since lua 5.2 and 5.3 not
> compatible with each
> other. Why Lua can't have same eclass as multislotted Python or Ruby? Lua
> ecosystem not
> so big, about 500 packages so why there no even little efforts to make Lua
> support in Gentoo
> better?

Portage has improved handling security issues like the ones with static
libraries a lot from what I understand by making --with-bdeps y the
default setting most of the time.

The lua build system seems to have a way to tell it to support
older things, there is a LUA_COMPAT_ALL compile flag. We'll have to see
what that does when it hits ~arch.

See this article for why using liblua as a shared library is not
recommended.

http://article.gmane.org/gmane.comp.lang.lua.general/18519

Yes, it talks about the interpretor, but it goes further and really
discourages even making a shared library available.

> 
> -- 
> From Siberia with Love!

William



signature.asc
Description: Digital signature

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

[Michał Górny]

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(-)

diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
index b2f3742b3ecf..4ef32c519f22 100644
--- a/eclass/flag-o-matic.eclass
+++ b/eclass/flag-o-matic.eclass
@@ -535,6 +535,9 @@ strip-unsupported-flags() {
export CXXFLAGS=$(test-flags-CXX ${CXXFLAGS})
export FFLAGS=$(test-flags-F77 ${FFLAGS})
export FCFLAGS=$(test-flags-FC ${FCFLAGS})
+   # note: this does not verify the linker flags but it is enough
+   # to strip invalid C flags which are much more likely, #621274
+   export LDFLAGS=$(test-flags-CC ${LDFLAGS})
 }
 
 # @FUNCTION: get-flag
diff --git a/eclass/tests/flag-o-matic.sh b/eclass/tests/flag-o-matic.sh
index 92c68b82c3c9..24f2a4c4af4e 100755
--- a/eclass/tests/flag-o-matic.sh
+++ b/eclass/tests/flag-o-matic.sh
@@ -55,7 +55,7 @@ done <<<"
 
 tbegin "strip-unsupported-flags"
 strip-unsupported-flags
-[[ ${CFLAGS} == "" ]] && [[ ${CXXFLAGS} == "-z=2" ]]
+[[ ${CFLAGS} == "" ]] && [[ ${CXXFLAGS} == "-z=2" ]] && [[ ${LDFLAGS} == "" ]]
 ftend
 
 for var in $(all-flag-vars) ; do
-- 
2.13.2

[gentoo-dev] [PATCH] eclass/tests: Fix inheriting multiple eclasses

[Michał Górny]

Fix the inherit function to correctly handle 'inherit' call with
multiple eclasses, instead of returning after the first eclass is
successfully sourced.
---
 eclass/tests/tests-common.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/tests/tests-common.sh b/eclass/tests/tests-common.sh
index 8141425a0dcb..d52cf3a2687b 100644
--- a/eclass/tests/tests-common.sh
+++ b/eclass/tests/tests-common.sh
@@ -17,11 +17,11 @@ inherit() {
local eclass=${path}/${e}.eclass
if [[ -e "${eclass}" ]] ; then
source "${eclass}"
-   return 0
+   continue 2
fi
done
+   die "could not find ${e}.eclass"
done
-   die "could not find ${eclass}"
 }
 EXPORT_FUNCTIONS() { :; }
 
-- 
2.13.2

Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: We only support little-endian Alpha

[James Le Cuirot]

On Sat,  1 Jul 2017 09:55:29 +0100
James Le Cuirot  wrote:

> Funny that no one noticed this for 10 years. :) Thanks to klausman for
> clearing this up.
> ---
>  eclass/toolchain-funcs.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index 121db46e62b5..777fce905f3e 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -572,7 +572,7 @@ tc-endian() {
>   case ${host} in
>   aarch64*be) echo big;;
>   aarch64)echo little;;
> - alpha*) echo big;;
> + alpha*) echo little;;
>   arm*b*) echo big;;
>   arm*)   echo little;;
>   cris*)  echo little;;

Merged.


pgp_U3Q7lKdS7.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: We only support little-endian Alpha

[Matthias Maier]

On Sat, Jul  1, 2017, at 03:55 CDT, James Le Cuirot  wrote:

> Funny that no one noticed this for 10 years. :) Thanks to klausman for
> clearing this up.
> ---
>  eclass/toolchain-funcs.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index 121db46e62b5..777fce905f3e 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -572,7 +572,7 @@ tc-endian() {
>   case ${host} in
>   aarch64*be) echo big;;
>   aarch64)echo little;;
> - alpha*) echo big;;
> + alpha*) echo little;;
>   arm*b*) echo big;;
>   arm*)   echo little;;
>   cris*)  echo little;;

Acked.

Matthias

Re: [gentoo-dev] lua upgrade plan

[Vadim A. Misbakh-Soloviov]

> excellent LuaDist
I'd not say it is excellent :( I'd rather say "NIH-syndromed"

>  Why Lua can't have same eclass as multislotted Python or Ruby?
>  Lua ecosystem not so big, about 500 packages
>  so why there no even little efforts to make Lua support in Gentoo better?

Well... Actually, it does. In Lua overlay. But mgorny (?) had a bunch of 
critics about it, so I just keeping it in Lua overlay and not proposing it to 
the gentoo repo anymore (I just have not enough time to rewrite it in the way 
it will pass mgorny's review :).

Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: We only support little-endian Alpha

[Sergei Trofimovich]

On Sat,  1 Jul 2017 09:55:29 +0100
James Le Cuirot  wrote:

> Funny that no one noticed this for 10 years. :) Thanks to klausman for
> clearing this up.
> ---
>  eclass/toolchain-funcs.eclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
> index 121db46e62b5..777fce905f3e 100644
> --- a/eclass/toolchain-funcs.eclass
> +++ b/eclass/toolchain-funcs.eclass
> @@ -572,7 +572,7 @@ tc-endian() {
>   case ${host} in
>   aarch64*be) echo big;;
>   aarch64)echo little;;
> - alpha*) echo big;;
> + alpha*) echo little;;
>   arm*b*) echo big;;
>   arm*)   echo little;;
>   cris*)  echo little;;
> -- 
> 2.13.1
> 
> 
Looks good.

$ alpha-unknown-linux-gnu-gcc -dM -E - 

pgplmF11P7EIw.pgp
Description: Цифровая подпись OpenPGP

[gentoo-dev] Last rites: media-gfx/picturewall

[Michael Palimaka]

# Michael Palimaka  (01 Jul 2017)
# Depends on vulnerable qtwebkit:4. Dead upstream.
# Masked for removal in 30 days. Bug #620836.
media-gfx/picturewall

[gentoo-dev] Last rites: media-gfx/smile

[Michael Palimaka]

# Michael Palimaka  (01 Jul 2017)
# Depends on vulnerable qtwebkit:4. Dead upstream.
# Masked for removal in 30 days. Bug #620704.
media-gfx/smile

[gentoo-dev] Last rites: kde-misc/semantik

[Michael Palimaka]

# Michael Palimaka  (01 Jul 2017)
# Depends on vulnerable qtwebkit:4. Dead upstream.
# Masked for removal in 30 days. Bug #620700.
kde-misc/semantik

[gentoo-dev] Last rites: app-cdr/acetoneiso

[Michael Palimaka]

# Michael Palimaka  (01 Jul 2017)
# Depends on vulnerable qtwebkit:4. Dead upstream.
# Masked for removal in 30 days. Bug #620688.
app-cdr/acetoneiso

Re: [gentoo-dev] [PATCH] Profile-enforced big-endian USE flag

[James Le Cuirot]

On Thu, 29 Jun 2017 22:19:58 +0100
James Le Cuirot  wrote:

> On Wed, 28 Jun 2017 23:29:03 +0100
> James Le Cuirot  wrote:
> 
> > > On Tue, Jun 27, 2017 at 6:44 PM, James Le Cuirot  
> > > wrote:
> > > > I am therefore proposing a new global big-endian flag. This could be
> > > > masked by default and unmasked + forced in the relevant profiles under
> > > > arch. I will apply this according to the mapping defined in tc-endian of
> > > > toolchain-funcs.eclass.  
> > 
> > I've just been putting the patch together. I made it slightly simpler
> > by masking *and* forcing it by default so that it only needs to be
> > unmasked were necessary.  
> 
> Feedback seems positive so here is the patch. I'll apply it late next
> week as I don't need it immediately and I will be away until then.
> 
> ---
> 
> diff --git a/profiles/arch/powerpc/use.mask b/profiles/arch/powerpc/use.mask
> index 6f993c6628c0..02e97b16f06d 100644
> --- a/profiles/arch/powerpc/use.mask
> +++ b/profiles/arch/powerpc/use.mask
> @@ -1,6 +1,13 @@
> +# Copyright 1999-2017 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +
>  # PPC Specific use flags
>  #
>  
> +# James Le Cuirot  (29 Jun 2017)
> +# Forced and masked by default. Unmask where necessary.
> +big-endian
> +
>  # Matt Turner  (24 Mar 2017)
>  # virtual/opencl is not keyworded
>  opencl

Just noticed a copy/pasta fail here. Obviously should be -big-endian.


pgpqC_NlS_M57.pgp
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] toolchain-funcs.eclass: We only support little-endian Alpha

[James Le Cuirot]

Funny that no one noticed this for 10 years. :) Thanks to klausman for
clearing this up.
---
 eclass/toolchain-funcs.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/toolchain-funcs.eclass b/eclass/toolchain-funcs.eclass
index 121db46e62b5..777fce905f3e 100644
--- a/eclass/toolchain-funcs.eclass
+++ b/eclass/toolchain-funcs.eclass
@@ -572,7 +572,7 @@ tc-endian() {
case ${host} in
aarch64*be) echo big;;
aarch64)echo little;;
-   alpha*) echo big;;
+   alpha*) echo little;;
arm*b*) echo big;;
arm*)   echo little;;
cris*)  echo little;;
-- 
2.13.1

Re: [gentoo-dev] lua upgrade plan

[Azamat Hackimov]

2017-06-30 22:16 GMT+05:00 William Hubbs :

> All,
>
> Upstream does not support liblua as a shared library, and they do not
> support installing multiple versions of lua onto a system. After
> conferring with the other lua maintainer, the decision has been made to
> remove this custom support from our lua package as well. This has been
> talked about many times upstream.


Lua devs very "hostile" to Linux distributers. I don't see why we should do
as they want to do.
They not have open vcs to simply see what they changes in new release, they
don't accepts
patches for system integration. They didn't even elementary easy-to-use
build system. Just
look to another distributives, they all do versioned and shared libraries
of Lua 5.{1,2,3}. Fedora
devs did custom Autotools-based buildsystem, Debian - provided pkg-config
files. There also
exists excellent LuaDist framework - still outdated, yes, but we can take
from them CMake
buildsystem to provide better integration into Gentoo enviroment. You have
so many options
but you still want to follow unwelcome Lua rules.


> They do not want it, and using liblua as a shared library causes
> performance issues.
>

Why, we live in XXI century, where this argument came from? What about
security, did you
forgot about it? How do you planning to do backward compatibility with old
lua5.1 libraries
and projects? They definitely have breakage since lua 5.2 and 5.3 not
compatible with each
other. Why Lua can't have same eclass as multislotted Python or Ruby? Lua
ecosystem not
so big, about 500 packages so why there no even little efforts to make Lua
support in Gentoo
better?

-- 
>From Siberia with Love!

Re: [gentoo-dev] [PATCH] Profile-enforced big-endian USE flag

[Tobias Klausmann]

Hi! 

On Thu, 29 Jun 2017, James Le Cuirot wrote:
> > No. Alpha is little endian.
> 
> Wikipedia says it is bi. tc-native() reports alpha* as big so I guess
> that's the only variant we support? Then again, this page says it is
> usually little. Is tc-native() wrong?
> 
> https://kernelnewbies.org/EndianIssues

For the purposes of explanation, let's distinguish
Alpha-the-processor from Alpha-the-systems here.

Yes, the AtP can be switched between big- and little-endianess.

AtS can't. That is, once built, hardware-wise, it has to be
either, but can never switch. Even the firmware has to be
different between LE and BE systems.

There are a lot of LE Alpha systems, in essence, everything that
was ever sold as an Alpha system by DEC, Compaq, HP and sundry
others (like Samsung, who made the UP1500 and related systems).
As a guideline: if it ever ran True64, OSF/1 or digital alpha
UNIX, it is little-endian.

The machines that run Alpha CPUs in big-endian mode are
exclusively Cray supercomputers like the Cray T3D and T3E series.

Linux only ever supported parts of the former group (e.g. the
high-end Alpha server GS1280 series from Compaq is definitely not,
despite running in little-endian mode). The big endian Crays were
never even close to be supported.

tl;dr: Alpha is little-endian only for (our) practical purposes.

Regards,
Tobias

PS: There may be obscure one-off or developer boards for Alphas
which can switch, but the tl;dr still stands.


-- 
Sent from aboard the Culture ship
GSV (Range Class) Ethics Gradient