Re: [gentoo-dev] What are eblits?
On Sat, May 28, 2016 at 9:11 PM, Joshua Kinard wrote: > > Whether the idea is useful in the present day and age, eh, who knows. For the > mips-sources ebuilds, eblits let me centralize the per-machine notes and > unpacking logic, which reduced each ebuild's size from ~18KB a few years ago > down to ~4.9KB today. It sounds pretty useful to me. I've seen eclasses used by a single package or two at most and full of conditional logic to handle all the times upstream changed their distribution scheme. Eblits sound a whole lot better. Since they're limited in scope there isn't really a need for list review/etc, and they can be created/deleted/etc at will. I wouldn't use them just to turn every 50 line ebuild into a 10 line ebuild, but when you have substantial amounts of code re-used across ebuilds refactoring it just makes sense. What I would love to see is this be standardized. An eclass or a GLEP seems like the logical approach. -- Rich
Re: [gentoo-dev] please remove me off your mailing list
On 05/23/2016 17:37, Kent Fredric wrote: > On 24 May 2016 at 09:22, Kristian Fiskerstrand wrote: >> give a man a fish and he has food for a day, teach a man to fish and he >> has food for a lifetime > > > But if you feed a man while you teach him, he's better equipped to learn. :p > > Hence, the suggestion includes both. > > - Solve the immediate issue. > - Include information to solving the issue in future. The other, less popular option, is to just feed the man to the fish. That also solves the problem :) -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] What are eblits?
On 05/26/2016 21:28, Kent Fredric wrote:
> On 27 May 2016 at 10:28, rindeal wrote:
>>
>> 1) what are they?
>> 2) why are they used?
>
>
> My best explanation is its a way to re-use very large amounts of code
> between 2 ebuilds, without resorting to:
>
> a) Copying the whole ebuild and hoping you find the relevant part in diffs
> b) Not needing reams of version-specific conditional code to make
> copying ebuilds between versions easier.
> c) Not needing confusing eclasses that exist to serve a single
> package, loaded with lots of weird conditional logic.
>
> My understanding is you could effectively roll the eblits back into
> the ebuild statically, just doing so would make keeping the changes
> consistent harder.
>
> Its clearly designed for a system where you have ~10 different
> versions of Perl available or ~10 different versions of glibc
> available, but you don't want to pay the price of duplicating that
> logic wholesale for every minor concurrent revision, and only want to
> update essential differences when you need to, not because you have
> to.
>
> That said, its a very confusing system to get your head around,
> because its *basically* yet another "mixin" system like "inherit", but
> done in bash, which itself is a rather strange language to be doing
> something as complicated as mixins.
An accurate explanation, but probably better to say they're more like "local
eclasses". If you think of the existing eclasses in ${PORTDIR}/eclass as
"global", that is, they contain common code utilized by multiple unrelated
ebuild packages, then eblits were originally envisioned as localized versions
of eclasses to share package-specific code between multiple ebuilds of
differing versions.
Whether the idea is useful in the present day and age, eh, who knows. For the
mips-sources ebuilds, eblits let me centralize the per-machine notes and
unpacking logic, which reduced each ebuild's size from ~18KB a few years ago
down to ~4.9KB today.
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our
lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
Re: [gentoo-dev] What are eblits?
On 05/26/2016 18:28, rindeal wrote:
> I've noticed that ebuilds for at least dev-lang/perl and
> sys-libs/glibc are using some concept of "eblits", which seems like
> parts of ebuilds scattered across $FILESDIR with ebuilds containing
> some logic (involving eval) which includes and runs them.
>
> I haven't found any documentation related to them so I'm asking here:
>
> 1) what are they?
> 2) why are they used?
I'm the other user of eblits in sys-kernel/mips-sources. There's a lot of
common code in that package that doesn't need to be duplicated between multiple
ebuilds, so years ago, I converted to using versioned eblits. It's a touch
manual, in that I have to manually check that all consumers of a specific eblit
version are removed from the tree before I remove the deprecated version, but
it avoids the nasty problem of changing an eblit for a newer ebuild that breaks
an older ebuild.
I started on an "eblits.eclass" a few months ago, but sidetracked and didn't
get back to it. Attached, if anyone wants to play with it. It includes the
core eblit loading functions used in mips-sources, which might be more
updated/robust than the ones in glibc (last I checked the logic, but vapier can
clarify if true or not). The last comment block is incomplete. I sidetracked
in finishing item #2 when pondering how to define a global "check" variable in
the eclass itself to control when the eblit core functions were loaded and all
eblits parsed (see latest mips-sources ebuild, $MIPS_SOURCES_EBLITS_LOADED).
Also handles the case of when installing from binary packages and $FILESDIR
isn't available. The eblit source for the pkg_* phases are packed onto the end
of the bzip2 tarball so they're available to Portage & friends.
The core eblit loading functions are the only duplicated code in the
mips-sources ebuilds, as well as glibc and other eblit users (perl?). I don't
remember what the argument for or against eblits might have been back in the
day, but for ebuilds whose only real changes are datestamps and/or version
numbers, eblits are a nice way to encapsulate and share common code that is too
specific for a global eclass. Centralizing the eblit code will allow
mips-sources and glibc ebuilds to shrink their overall filesize a little-bit
more (~1.5KB per mips-sources ebuild, so 3.4KB per ebuild instead of the
current 4.9KB).
And yes, for anyone wondering, I have new mips-sources ebuilds. Just took a
month to partially rewrite the SGI Origin/IP27 kernel code and then hunt down a
hardware bug on my SGI Octane, so, been distracted...
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our
lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
# Copyright 1999-2016 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Id$
# Description: eblit.eclass contains the core functions for creating "eblits".
# eblits are a place to store common code shared among multiple
# ebuilds for a specific package.
#
# Original Eblit Author: Mike Frysinger
# Original Eclass Author: Joshua Kinard
# Maintainer: base-sys...@gentoo.org
# Implementation Note: Since code in an eblit is used by multiple ebuilds,
# PLEASE revbump the eblit files when changes are made. Then update each
# ebuild to use the new eblit version. Remove old eblit versions when there
# are no more consumers. This makes it a lot easier to debug problems with
# the shared code within an eblit, as well as the affected ebuilds.
# To create an eblit:
# 1. Create an "eblits" subdirectory under ${FILESDIR}, if one does not
# already exist.
# 2. Create a new file name using the following formula:
# [a-z0-9_]-v[0-9]+.eblit
# 3. Add the shared code, save, and close the file.
#
# Try to keep eblits specific to the functions they implement. E.g., if a
# number of ebuilds have a large, but common src_unpack() function, and it
# is not already provided by an eclass, then add that code to an eblit named
# "src_unpack-vX.eblit".
# To load and use eblits:
# 1. Inherit the "eblit" eclass (this class).
# 2. Define a new function called "load_eblit_funcs" in the ebuild immediately
# after the global ebuild variables
# eblit-core
# Usage: [version]
# Main eblit engine
eblit-core() {
local e v func=$1 ver=$2
for v in ${ver:+-}${ver} -${PVR} -${PV} "" ; do
e="${FILESDIR}/eblits/${func}${v}.eblit"
if [[ -e ${e} ]] ; then
. "${e}"
[[ ${func} == pkg_* ]] && eval "${func}() { eblit-run
${func} ${ver} ; }"
return 0
fi
done
return 1
}
# eblit-include
# Usage: [--skip] [version]
# Includes an "eblit" -- a chunk of common code among ebuilds in a given
[gentoo-dev] Re: What are eblits?
Kent Fredric posted on Sat, 28 May 2016 17:07:56 +1200 as excerpted: > Which is a rather bad combination of pressures. > > Hence, eblits as they currently exist are experts-only and a big > danger ground for QA violations *to occur within*, even under the > presumption that they're not inherently a QA violation in themselves. Thanks. You well explained the details of /why/ eblits are experts-only, that I deliberately fuzzed over in my first thread reply. Now I understand them better myself. =:^) -- 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] [PATCH 1/2] rebar.eclass: Run unit tests
From: Amadeusz Żołnowski
---
eclass/rebar.eclass | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
index ca86e88..9f3d9e2 100644
--- a/eclass/rebar.eclass
+++ b/eclass/rebar.eclass
@@ -30,7 +30,7 @@ case "${EAPI:-0}" in
;;
esac
-EXPORT_FUNCTIONS src_prepare src_compile src_install
+EXPORT_FUNCTIONS src_prepare src_compile src_test src_install
RDEPEND="dev-lang/erlang"
DEPEND="${RDEPEND}
@@ -198,6 +198,15 @@ rebar_src_compile() {
erebar compile
}
+# @FUNCTION: rebar_src_test
+# @DESCRIPTION:
+# Run unit tests.
+rebar_src_test() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ erebar eunit
+}
+
# @FUNCTION: rebar_src_install
# @DESCRIPTION:
# Install BEAM files, include headers, executables and native libraries.
--
2.8.3
[gentoo-dev] [PATCH 2/2] rebar.eclass: Optionally provide alternate rebar config to alter
From: Amadeusz Żołnowski
Some packages have separate configs for build and tests. Build config is
always named 'rebar.config' and there seem to be no standard name for
tests config.
---
eclass/rebar.eclass| 14 +++---
eclass/tests/rebar_fix_include_path.sh | 23 +++
eclass/tests/rebar_remove_deps.sh | 23 +++
3 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/eclass/rebar.eclass b/eclass/rebar.eclass
index 9f3d9e2..c8a2cf4 100644
--- a/eclass/rebar.eclass
+++ b/eclass/rebar.eclass
@@ -93,17 +93,20 @@ erebar() {
}
# @FUNCTION: rebar_fix_include_path
-# @USAGE:
+# @USAGE: []
# @DESCRIPTION:
# Fix path in rebar.config to 'include' directory of dependant project/package,
# so it points to installation in system Erlang lib rather than relative 'deps'
# directory.
#
+# is optional. Default is 'rebar.config'.
+#
# The function dies on failure.
rebar_fix_include_path() {
debug-print-function ${FUNCNAME} "${@}"
local pn="$1"
+ local rebar_config="${2:-rebar.config}"
local erl_libs="${EPREFIX}$(get_erl_libs)"
local p
@@ -121,19 +124,24 @@ rebar_fix_include_path() {
next;
}
1
-' rebar.config || die "failed to fix include paths in rebar.config for '${pn}'"
+' "${rebar_config}" || die "failed to fix include paths in ${rebar_config} for
'${pn}'"
}
# @FUNCTION: rebar_remove_deps
+# @USAGE: []
# @DESCRIPTION:
# Remove dependencies list from rebar.config and deceive build rules that any
# dependencies are already fetched and built. Otherwise rebar tries to fetch
# dependencies and compile them.
#
+# is optional. Default is 'rebar.config'.
+#
# The function dies on failure.
rebar_remove_deps() {
debug-print-function ${FUNCNAME} "${@}"
+ local rebar_config="${1:-rebar.config}"
+
mkdir -p "${S}/deps" && :>"${S}/deps/.got" && :>"${S}/deps/.built" ||
die
gawk -i inplace '
/^{[[:space:]]*deps[[:space:]]*,/, /}[[:space:]]*\.$/ {
@@ -143,7 +151,7 @@ rebar_remove_deps() {
next;
}
1
-' rebar.config || die "failed to remove deps from rebar.config"
+' "${rebar_config}" || die "failed to remove deps from ${rebar_config}"
}
# @FUNCTION: rebar_set_vsn
diff --git a/eclass/tests/rebar_fix_include_path.sh
b/eclass/tests/rebar_fix_include_path.sh
index 9047f8d..c8ab178 100755
--- a/eclass/tests/rebar_fix_include_path.sh
+++ b/eclass/tests/rebar_fix_include_path.sh
@@ -77,6 +77,25 @@ test_typical_config() {
[[ ${unit_rc}${diff_rc} = 00 ]]
}
+test_typical_config_with_different_name() {
+ local diff_rc
+ local unit_rc
+
+ # Prepare
+ cd "${S}" || die
+ cp typical.config other.config || die
+
+ # Run unit
+ (rebar_fix_include_path foo other.config)
+ unit_rc=$?
+
+ # Test result
+ diff other.config typical.config.expected
+ diff_rc=$?
+
+ [[ ${unit_rc}${diff_rc} = 00 ]]
+}
+
test_multiple_versions() {
local diff_rc
local unit_rc
@@ -144,6 +163,10 @@ tbegin "rebar_fix_include_path deals with typical config"
test_typical_config
tend $?
+tbegin "rebar_fix_include_path deals with typical config with different name"
+test_typical_config_with_different_name
+tend $?
+
tbegin "rebar_fix_include_path fails on multiple versions of dependency"
test_multiple_versions
tend $?
diff --git a/eclass/tests/rebar_remove_deps.sh
b/eclass/tests/rebar_remove_deps.sh
index 05207a7..32351bf 100755
--- a/eclass/tests/rebar_remove_deps.sh
+++ b/eclass/tests/rebar_remove_deps.sh
@@ -67,6 +67,25 @@ test_typical_config() {
[[ ${unit_rc}${diff_rc} = 00 ]]
}
+test_typical_config_with_different_name() {
+ local diff_rc
+ local unit_rc
+
+ # Prepare
+ cd "${S}" || die
+ cp typical.config other.config || die
+
+ # Run unit
+ (rebar_remove_deps other.config)
+ unit_rc=$?
+
+ # Test result
+ diff other.config rebar.config.expected
+ diff_rc=$?
+
+ [[ ${unit_rc}${diff_rc} = 00 ]]
+}
+
test_deps_in_one_line() {
local diff_rc
local unit_rc
@@ -92,6 +111,10 @@ tbegin "rebar_remove_deps deals with typical config"
test_typical_config
tend $?
+tbegin "rebar_remove_deps deals with typical config with different name"
+test_typical_config_with_different_name
+tend $?
+
tbegin "rebar_remove_deps deals with all deps in one line"
test_deps_in_one_line
tend $?
--
2.8.3
Re: [gentoo-dev] Package up for grabs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On May 28, 2016 5:41:40 AM PDT, rindeal wrote: >On 28 May 2016 at 11:14, Pacho Ramos wrote: >> Markos is not having much time to handle his packages and, then, he >> would like to get other people involved in them. The idea is to keep >> him in metadata as co-maintainer but, please, don't hesitate to add >> yourself if wanted: >> app-admin/verynice >> app-crypt/zuluCrypt >> dev-cpp/luabind >> dev-libs/angelscript >> dev-libs/libntru >> dev-libs/libuv >> dev-lua/luvit >> dev-python/pathtools >> dev-python/pygame_sdl2 >> dev-python/pyuv >> dev-python/watchdog >> dev-vcs/git-imerge >> media-gfx/pornview >> media-sound/pnmixer >> net-firewall/pglinux >> net-im/bitlbee-steam >> net-im/purple-events >> net-misc/connman-gtk >> net-misc/connman-ui >> net-p2p/pybitmessage >> sci-geosciences/cdat-lite >> sci-geosciences/congen >> sci-geosciences/tcd-utils >> sci-libs/libspatialindex >> www-apps/hiawatha-monitor >> www-servers/hiawatha >> x11-plugins/hexchat-javascript >> x11-plugins/pidgin-birthday-reminder >> x11-plugins/purple-libnotify-plus >> x11-terms/terra >> x11-themes/geany-themes >> > >You've posted it here a week ago and already received responses, why >are you posting it again? Unchanged? I don't remember seeing the explanation regarding Markos and asking that people keep him as a co-maint. I'm on my phone right now though so I could be mistaken. - -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -BEGIN PGP SIGNATURE- iQJRBAEBCgA7NBxEYW5pZWwgQ2FtcGJlbGwgKEdlbnRvbyBEZXZlbG9wZXIpIDx6 bGdAZ2VudG9vLm9yZz4FAldJvZYACgkQASQOlFA54XD7XQ//Rsuz0Klivf8o/nAw JbpDs6vuvk0hKBGUy94kTDA8w2h+T8OFqHOer6qaDtmWFGTJKWTkAJoS0M1VtpjR LAkw2TLdpSfgVUTV+bsDiDyCVNk1lxag/oU6rY7N0fFUxvhTn1ran2jkchWJMF5q vs8LN/Cyv8Dxq8IUL9zDMdlw76EuP5Ktw/HBJkSaloZkqPPlLFJka2g5azaAJkez tV6LWv+/gt+B+XMo2ZJ3+dNfm46dB1ye5R9hIxi0vvVhfuIEpcSloCpJrGmUBfiV Qqe/Ik89evri2GWVTKDDqV54BDnrFluG6gqtmwgEgIid7Lb+lF++LACrD8MIOlOX W/m8F3TS/qW7mHE4imrXWwjWVwqhvJKVkXbnUtd0YKSD1ocRPcnQifQSXrH3GvLK b2FXqtpwhl0OrU2y/yR1T/xECefvbzxZXtafZKDpGgvLL2az6tAv5rdd7ZVH n/43zDQH8MM6656aOqby9xzncRl5Twm3G59JygrTmBt6Y5jwcY8/kW8+erd642S4 4JdOdVMUes6p9Osd2N+otfVEE6oEHKXZmueWstz6VgIIOT9x1rbI3p70MTBWANwT XKJS1e9VOpEzp9ccKZA8lsU8uSZWmNmt62Zf0rrnuDD9KTN4vOUZLrlNQ/S2drEf Gq1NwMncjsSotwvWw7BOluyeMMQ= =/9ya -END PGP SIGNATURE-
Re: [gentoo-dev] Package up for grabs
El sáb, 28-05-2016 a las 14:41 +0200, rindeal escribió: > On 28 May 2016 at 11:14, Pacho Ramos wrote: > > > > Markos is not having much time to handle his packages and, then, he > > would like to get other people involved in them. The idea is to > > keep > > him in metadata as co-maintainer but, please, don't hesitate to add > > yourself if wanted: > > app-admin/verynice > > app-crypt/zuluCrypt > > dev-cpp/luabind > > dev-libs/angelscript > > dev-libs/libntru > > dev-libs/libuv > > dev-lua/luvit > > dev-python/pathtools > > dev-python/pygame_sdl2 > > dev-python/pyuv > > dev-python/watchdog > > dev-vcs/git-imerge > > media-gfx/pornview > > media-sound/pnmixer > > net-firewall/pglinux > > net-im/bitlbee-steam > > net-im/purple-events > > net-misc/connman-gtk > > net-misc/connman-ui > > net-p2p/pybitmessage > > sci-geosciences/cdat-lite > > sci-geosciences/congen > > sci-geosciences/tcd-utils > > sci-libs/libspatialindex > > www-apps/hiawatha-monitor > > www-servers/hiawatha > > x11-plugins/hexchat-javascript > > x11-plugins/pidgin-birthday-reminder > > x11-plugins/purple-libnotify-plus > > x11-terms/terra > > x11-themes/geany-themes > > > You've posted it here a week ago and already received responses, why > are you posting it again? Unchanged? For some reason it seemed that neither me and Markos were able to find the mail. Also few days ago I noticed it missing in archives. As that day I also suffered a problem with my mail client, I wasn't sure if maybe the mail got finally wrongly sent or similar
Re: [gentoo-dev] Package up for grabs
On 28 May 2016 at 11:14, Pacho Ramos wrote: > Markos is not having much time to handle his packages and, then, he > would like to get other people involved in them. The idea is to keep > him in metadata as co-maintainer but, please, don't hesitate to add > yourself if wanted: > app-admin/verynice > app-crypt/zuluCrypt > dev-cpp/luabind > dev-libs/angelscript > dev-libs/libntru > dev-libs/libuv > dev-lua/luvit > dev-python/pathtools > dev-python/pygame_sdl2 > dev-python/pyuv > dev-python/watchdog > dev-vcs/git-imerge > media-gfx/pornview > media-sound/pnmixer > net-firewall/pglinux > net-im/bitlbee-steam > net-im/purple-events > net-misc/connman-gtk > net-misc/connman-ui > net-p2p/pybitmessage > sci-geosciences/cdat-lite > sci-geosciences/congen > sci-geosciences/tcd-utils > sci-libs/libspatialindex > www-apps/hiawatha-monitor > www-servers/hiawatha > x11-plugins/hexchat-javascript > x11-plugins/pidgin-birthday-reminder > x11-plugins/purple-libnotify-plus > x11-terms/terra > x11-themes/geany-themes > You've posted it here a week ago and already received responses, why are you posting it again? Unchanged?
[gentoo-dev] Package up for grabs
Because of the current maintainer not having time to take care of them, the following packages are now up for grabs: app-admin/pydf app-arch/lrzip app-arch/xar games-board/stockfish sys-kernel/ck-sources
Re: [gentoo-dev] Package up for grabs
On Sat, 28 May 2016 11:30:44 +0200 Pacho Ramos wrote: >Because of maintainer retiring the following packages are up for grabs: >app-admin/hwreport >app-admin/tmpwatch >app-misc/gramps >app-portage/g-ctan >net-misc/icaclient >virtual/pager > > I can take net-misc/icaclient as I need it for work. Cheers Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 Attention! New gpg key! See https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html pgpL340DbFp9e.pgp Description: Digitale Signatur von OpenPGP
[gentoo-dev] Package up for grabs
Because of maintainer retiring the following packages are up for grabs: app-admin/hwreport app-admin/tmpwatch app-misc/gramps app-portage/g-ctan net-misc/icaclient virtual/pager
[gentoo-dev] Package up for grabs
Markos is not having much time to handle his packages and, then, he would like to get other people involved in them. The idea is to keep him in metadata as co-maintainer but, please, don't hesitate to add yourself if wanted: app-admin/verynice app-crypt/zuluCrypt dev-cpp/luabind dev-libs/angelscript dev-libs/libntru dev-libs/libuv dev-lua/luvit dev-python/pathtools dev-python/pygame_sdl2 dev-python/pyuv dev-python/watchdog dev-vcs/git-imerge media-gfx/pornview media-sound/pnmixer net-firewall/pglinux net-im/bitlbee-steam net-im/purple-events net-misc/connman-gtk net-misc/connman-ui net-p2p/pybitmessage sci-geosciences/cdat-lite sci-geosciences/congen sci-geosciences/tcd-utils sci-libs/libspatialindex www-apps/hiawatha-monitor www-servers/hiawatha x11-plugins/hexchat-javascript x11-plugins/pidgin-birthday-reminder x11-plugins/purple-libnotify-plus x11-terms/terra x11-themes/geany-themes Regards
[gentoo-dev] Packages up for grabs
As talked with current maintainer, this packages are now up for grabs: dev-libs/libxr
