[gentoo-dev] Re: lua upgrade plan
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
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)
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)
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
[gentoo-dev] Last rites: kde-misc/krecipes
# Andreas Sturmlechner (01 Jul 2017) # Depends on vulnerable qtwebkit:4. Dead upstream. # Masked for removal in 30 days. Bug #621558. kde-misc/krecipes
Re: [gentoo-dev] lua upgrade plan
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
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
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
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
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
> 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
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 (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 (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 (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 (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
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
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
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
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