Re: [gentoo-dev] Re: lua upgrade plan
Hi, On Sun, 2 Jul 2017 10:30:12 -0500 William Hubbs wrote: > > 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... > > You are correct. Basically we have to write our own build system and > keep it up to date for every version of lua in order to support this. Why should we? We can borrow from other distributions like Debian or Fedora. Of course some Gentoo-specific tuning may be required, but it will be not writing from scratch. > If someone can convince upstream to support it, this would be far better for > everyone. In the ideal world, yes, I agree with this. But we are in real world with real lua developers unwilling to cooperate from what I see. Best regards, Andrew Savchenko pgpfTv0Yi8lEB.pgp Description: PGP signature
[gentoo-dev] Re: lua upgrade plan
William Hubbs posted on Sun, 02 Jul 2017 10:30:12 -0500 as excerpted: > On Sun, Jul 02, 2017 at 03:55:54AM +, Duncan wrote: >> 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 >> >> 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). [...] >> So... got any equivalent links to posts with more modern figures? > > That link actually came from our current lua ebuilds. The shared library > is offered, but the comments in the ebuild basically say the same thing > and cite that link. Thanks. =:^) > Also, x86 is still a stable supported arch in Gentoo. Two points: 1) x86 is indeed still a stable supported arch, as are, I think, a few others. But we're not discussing _breaking_ lua on x86, simply accepting that default-dynamic-linking lua wouldn't be as efficient on x86 as it would be on less register-short archs, including the now dominant amd64. Seems a reasonable tradeoff to be made, particularly given it's the choice other distros as well were choosing even when x86 /was/ the majority arch. Especially when given that on gentoo, those that believe they have reason to can choose to statically link in any case. It's just that gentoo normally defaults to dynamic linking if people haven't specifically chosen static linking. (Or would static linking not be a user-side option in this case if the dynamic-link route were chosen?) 2) Just to be explicitly in case the (quote I've now omitted) bit below that didn't make it clear: I still support killing the shared lib if maintainer-desired, even if the only /technical/ reason is that upstream doesn't support it (for reasons apparently no longer valid on modern archs, but...), due to the extra work then required. I simply believe it's important to be honest about it, if that is indeed the case, and am wondering if it is. -- 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] Automated Package Removal and Addition Tracker, for the week ending 2017-07-02 23:59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2017-07-02 23:59 UTC. Removals: app-admin/checkrestart 20170701-09:13 mgorny f2a65ab8ceb app-shells/z 20170701-09:13 mgorny 9828e288abb mail-client/squirrelmail 20170701-09:09 mgorny d229371435c media-libs/lv2core 20170701-09:11 mgorny 5f05c62d0fb media-libs/lv2-ui20170701-09:11 mgorny 68d75fd287f www-client/xombrero 20170701-09:16 mgorny a39883d8556 x11-misc/outwiker20170701-09:16 mgorny bcaf4b5672c x11-misc/rednotebook 20170701-09:17 mgorny 2f88d4d4249 Additions: app-editors/sublime-text 20170701-22:07 soap 4f90be61f21 app-emacs/puppet-mode20170630-13:04 graaff 5c6de1a2952 app-misc/yq 20170627-20:25 zmedico c899e82068f dev-libs/amdgpu-pro-opencl 20170627-10:52 marecki 777fd2b49b7 dev-ml/angstrom 20170702-15:57 aballier 62fc88e172c dev-perl/Dist-Zilla-Plugin-AuthorsFromGit20170701-23:04 dilfridge 020e70ac211 dev-perl/Dist-Zilla-Plugin-RPM 20170628-18:43 dilfridge 8e66ef1d2e5 dev-perl/Dist-Zilla-Plugin-SurgicalPodWeaver 20170701-19:59 dilfridge 133cdf898a6 dev-perl/Moose-Autobox 20170628-18:40 dilfridge 898ab515044 dev-python/distributed 20170627-04:40 bicatali f613ee08692 dev-python/fastparquet 20170628-03:59 bicatali 6b68d1fc70b dev-python/graphviz 20170629-17:49 bicatali 16b0d7d9471 dev-python/lmdb 20170308-18:28 bicatali cfa182139ea dev-python/python-afl20170629-13:45 mrueg 5d8a889a267 dev-python/thriftpy 20170627-20:49 bicatali b2b55cac125 dev-python/toro 20170627-18:41 bicatali 9d0dcd896f7 dev-python/zict 20170308-18:34 bicatali ea3adf49503 dev-ruby/hocon 20170629-02:51 prometheanfire a0b5dfac8a1 kde-plasma/plasma-vault 20170701-20:46 asturm af51398fe23 sci-libs/h5hut 20170702-23:43 junghans e8827415e76 sys-apps/intel-sa-00075-tools20170626-23:16 chutzpah ec025ee92ca -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: x11-misc/rednotebook,removed,mgorny,20170701-09:17,2f88d4d4249 x11-misc/outwiker,removed,mgorny,20170701-09:16,bcaf4b5672c www-client/xombrero,removed,mgorny,20170701-09:16,a39883d8556 app-shells/z,removed,mgorny,20170701-09:13,9828e288abb app-admin/checkrestart,removed,mgorny,20170701-09:13,f2a65ab8ceb media-libs/lv2core,removed,mgorny,20170701-09:11,5f05c62d0fb media-libs/lv2-ui,removed,mgorny,20170701-09:11,68d75fd287f mail-client/squirrelmail,removed,mgorny,20170701-09:09,d229371435c Added Packages: sci-libs/h5hut,added,junghans,20170702-23:43,e8827415e76 dev-ml/angstrom,added,aballier,20170702-15:57,62fc88e172c dev-perl/Dist-Zilla-Plugin-AuthorsFromGit,added,dilfridge,20170701-23:04,020e70ac211 app-editors/sublime-text,added,soap,20170701-22:07,4f90be61f21 kde-plasma/plasma-vault,added,asturm,20170701-20:46,af51398fe23 dev-perl/Dist-Zilla-Plugin-SurgicalPodWeaver,added,dilfridge,20170701-19:59,133cdf898a6 app-emacs/puppet-mode,added,graaff,20170630-13:04,5c6de1a2952 dev-python/graphviz,added,bicatali,20170629-17:49,16b0d7d9471 dev-python/python-afl,added,mrueg,20170629-13:45,5d8a889a267 dev-ruby/hocon,added,prometheanfire,20170629-02:51,a0b5dfac8a1 dev-perl/Dist-Zilla-Plugin-RPM,added,dilfridge,20170628-18:43,8e66ef1d2e5 dev-perl/Moose-Autobox,added,dilfridge,20170628-18:40,898ab515044 dev-python/fastparquet,added,bicatali,20170628-03:59,6b68d1fc70b dev-python/thriftpy,added,bicatali,20170627-20:49,b2b55cac125 dev-python/toro,added,bicatali,20170627-18:41,9d0dcd896f7 dev-python/distributed,added,bicatali,20170627-04:40,f613ee08692 app-misc/yq,added,zmedico,20170627-20:25,c899e82068f dev-libs/amdgpu-pro-opencl,added,marecki,20170627-10:52,777fd2b49b7 sys-apps/intel-sa-00075-tools,added,chutzpah,20170626-23:16,ec025ee92ca dev-python/zict,added,bicatali,20170308-18:34,ea3adf49503 dev-python/lmdb,added,bicatali,20170308-18:28,cfa182139ea Done.
[gentoo-dev] Last rites: app-eselect/eselect-bashcomp
# Michał Górny (02 Jul 2017) # The eselect module has been integrated into app-shells/bash-completion # and all the old versions (not having it) are gone. Removal in 14 days. app-eselect/eselect-bashcomp -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] lua upgrade plan
On 02/07/17 21:12, Vadim A. Misbakh-Soloviov wrote: > By the way, it will also brake some proprietary games, that distributes via > steam, humble, gog and so on. > > Some of them depends on shared lua and doesn't bundle it (instead, their > installer calls apt (since they're doing games for ubuntu), but since we have > no apt, we (gamerlay/games team) just writing proper DEPENDs, unpacking the > content, and installing it. > > So, if shared lua will be dropped, we will either have a bunch of broken > games > or used to create some kludgy "lua-shared" custom ebuild, which is worse way > of doing the things. > > So, I'm voting for status quo. > > A custom games-lua eclass ... ?! *runs from mgorny et al * signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] lua upgrade plan
By the way, it will also brake some proprietary games, that distributes via steam, humble, gog and so on. Some of them depends on shared lua and doesn't bundle it (instead, their installer calls apt (since they're doing games for ubuntu), but since we have no apt, we (gamerlay/games team) just writing proper DEPENDs, unpacking the content, and installing it. So, if shared lua will be dropped, we will either have a bunch of broken games or used to create some kludgy "lua-shared" custom ebuild, which is worse way of doing the things. So, I'm voting for status quo.
Re: [gentoo-dev] Re: lua upgrade plan
On Sun, Jul 02, 2017 at 03:55:54AM +, Duncan wrote: > 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? That link actually came from our current lua ebuilds. The shared library is offered, but the comments in the ebuild basically say the same thing and cite that link. Also, x86 is still a stable supported arch in Gentoo. > 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... You are correct. Basically we have to write our own build system and keep it up to date for every version of lua in order to support this. If someone can convince upstream to support it, this would be far better for everyone. > ... 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. =:^) The plan is to migrate what can be migrated from there to the tree once everything is up to date. William signature.asc Description: Digital signature
