Re: [gentoo-dev] Packages without source code
On Thu, 3 Jan 2013, Rich Freeman wrote: On Thu, Jan 3, 2013 at 9:39 AM, Ulrich Mueller u...@gentoo.org wrote: We could easily solve this by adding a binary-only or no-source-code tag to such packages. It would be included in the @BINARY-REDISTRIBUTABLE license group, but not in @FREE. So such packages would be excluded for users with ACCEPT_LICENSE=-* @FREE. As long as it is also marked with the BSD license I don't have a problem with this. The license is, in fact, BSD, so we do need to keep that info around. Thinking about the name, no-source-code might be a better choice than binary-only. As the GPL defines it, The source code for a work means the preferred form of the work for making modifications to it. This may be binary, e.g. for pictures in a bitmap format. I understand the distinction adds value to our users, but I find it amusing that a computer scientist would even try to define the term source code. :) Coming back to this old thread. I've recently added a no-source-code license file [1]. This should be used for packages whose license would otherwise match @FREE, but that don't qualify as free software because of the missing source code. Obviously, no-source-code alone isn't a license, so it cannot be the only element of an ebuild's LICENSE variable. Ulrich [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/licenses/no-source-code?view=markup pgpAXW63fq3P2.pgp Description: PGP signature
[gentoo-dev] multilib RFC: improving wrapping compatibility with non-multilib and multilib-portage systems
Hi, all.
Following the issue brought up in bug #508278
(${CHOST}-pango-querymodules not available on non-multilib systems),
I was thinking how to improve the wrapping conditionals so that it
would work best for both multilib and non-multilib systems, while
keeping it compatible with multilib-portage.
The underlying issue there is that multilib-portage has its own
executable wrapping that is incompatible with the wrapping done
by the eclass. For this reason, Tommy has requested the eclass wrapping
to be disabled when a single ABI is used (which multilib-portage
pretends to do) -- so that the binary would be simply installed for
further wrapping by multilib-portage.
Sadly, this means that ebuild authors have to consider two cases --
when ${CHOST}-executable is available, and when it is not. For most
of the multilib packages, autotools automatically find the correct
option. However, direct references in ebuild aren't that easy.
I think it would be better if ebuild authors would be able to use
${CHOST}-executable consistently for all systems. Therefore, I'd like
to make the wrapping code suitable for all the use cases, including
non-multilib systems and multilib-portage.
I'm proposing the following changes to the eclasses:
1. move wrapping conditionals from different eclasses into
multilib_prepare_wrappers and multilib_install_wrappers -- for improved
consistency and decreased amount of code,
2. replace the 'if at least two ABIs are built' conditional with plain
'if multilib-portage is not used' -- that is, enable the wrapping for
non-multilib systems. It may deem unnecessary but it doesn't hurt
and improves consistency.
3. add additional compatibility code for multilib-portage -- that
creates working '${CHOST}-executable - executable' symlinks, utilizing
multilib-portage executable wrapping and providing compatibility with
both called names.
Patches sent as replies. What are your thoughts?
[1]:https://bugs.gentoo.org/show_bug.cgi?id=508278
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH 1/3] Move wrapping conditionals to the wrapping functions.
This way, we don't have to repeat them in each eclass involved, and we
make use of the low-level functions easier.
---
eclass/cmake-multilib.eclass | 9 +++--
eclass/multilib-build.eclass | 4
eclass/multilib-minimal.eclass | 8 +++-
3 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/eclass/cmake-multilib.eclass b/eclass/cmake-multilib.eclass
index 02d6008..a6711bf 100644
--- a/eclass/cmake-multilib.eclass
+++ b/eclass/cmake-multilib.eclass
@@ -50,12 +50,9 @@ cmake-multilib_src_install() {
cmake-multilib_secure_install() {
cmake-utils_src_install ${@}
- # Do multilib magic only when 1 ABI is used.
- if [[ ${#MULTIBUILD_VARIANTS[@]} -gt 1 ]]; then
- multilib_prepare_wrappers
- # Make sure all headers are the same for each ABI.
- multilib_check_headers
- fi
+ multilib_prepare_wrappers
+ # Make sure all headers are the same for each ABI.
+ multilib_check_headers
}
multilib_foreach_abi cmake-multilib_secure_install ${@}
diff --git a/eclass/multilib-build.eclass b/eclass/multilib-build.eclass
index 0ba54bf..02f9634 100644
--- a/eclass/multilib-build.eclass
+++ b/eclass/multilib-build.eclass
@@ -295,6 +295,8 @@ multilib_prepare_wrappers() {
[[ ${#} -le 1 ]] || die ${FUNCNAME}: too many arguments
+ [[ ${#MULTIBUILD_VARIANTS[@]} -le 1 ]] return
+
local root=${1:-${ED}}
local f
@@ -419,6 +421,8 @@ multilib_install_wrappers() {
[[ ${#} -le 1 ]] || die ${FUNCNAME}: too many arguments
+ [[ ${#MULTIBUILD_VARIANTS[@]} -le 1 ]] return
+
local root=${1:-${ED}}
if [[ -d ${ED}/tmp/multilib-include ]]; then
diff --git a/eclass/multilib-minimal.eclass b/eclass/multilib-minimal.eclass
index 2fec9cf..4647127 100644
--- a/eclass/multilib-minimal.eclass
+++ b/eclass/multilib-minimal.eclass
@@ -108,11 +108,9 @@ multilib-minimal_src_install() {
emake DESTDIR=${D} install
fi
fi
- # Do multilib magic only when 1 ABI is used.
- if [[ ${#MULTIBUILD_VARIANTS[@]} -gt 1 ]]; then
- multilib_prepare_wrappers
- multilib_check_headers
- fi
+
+ multilib_prepare_wrappers
+ multilib_check_headers
popd /dev/null || die
}
multilib_foreach_abi multilib-minimal_abi_src_install
--
1.9.2
[gentoo-dev] [PATCH 2/3] Disable wrapping only if multilib-portage is used.
In other words, enable wrapping for non-multilib systems as well. While
this isn't necessary, it shouldn't hurt and it improves consistency
between systems. As a result, ebuilds can now safely use
'${CHOST}-executable' calls without checking whether the system is
multilib.
---
eclass/multilib-build.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/multilib-build.eclass b/eclass/multilib-build.eclass
index 02f9634..4b6a953 100644
--- a/eclass/multilib-build.eclass
+++ b/eclass/multilib-build.eclass
@@ -295,7 +295,7 @@ multilib_prepare_wrappers() {
[[ ${#} -le 1 ]] || die ${FUNCNAME}: too many arguments
- [[ ${#MULTIBUILD_VARIANTS[@]} -le 1 ]] return
+ [[ ${COMPLETE_MULTILIB} == yes ]] return
local root=${1:-${ED}}
local f
@@ -421,7 +421,7 @@ multilib_install_wrappers() {
[[ ${#} -le 1 ]] || die ${FUNCNAME}: too many arguments
- [[ ${#MULTIBUILD_VARIANTS[@]} -le 1 ]] return
+ [[ ${COMPLETE_MULTILIB} == yes ]] return
local root=${1:-${ED}}
--
1.9.2
[gentoo-dev] [PATCH 3/3] Create '${CHOST}-executable' symlinks in multilib-portage.
To support multilib-portage abi-wrapper properly, we need to install
executables non-prefixed on all ABIs. However, we can safely create
prefixed symlinks to the executable to improve compatibility with
non-multilib-portage systems.
All of the symlinks point to the same executable but since it is wrapped
by abi-wrapper, it will work correctly in portage context.
---
eclass/multilib-build.eclass | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/eclass/multilib-build.eclass b/eclass/multilib-build.eclass
index 4b6a953..755d774 100644
--- a/eclass/multilib-build.eclass
+++ b/eclass/multilib-build.eclass
@@ -295,11 +295,26 @@ multilib_prepare_wrappers() {
[[ ${#} -le 1 ]] || die ${FUNCNAME}: too many arguments
- [[ ${COMPLETE_MULTILIB} == yes ]] return
-
local root=${1:-${ED}}
local f
+ if [[ ${COMPLETE_MULTILIB} == yes ]]; then
+ # symlink '${CHOST}-foo - foo' to support abi-wrapper while
+ # keeping ${CHOST}-foo calls correct.
+
+ for f in ${MULTILIB_CHOST_TOOLS[@]}; do
+ # drop leading slash if it's there
+ f=${f#/}
+
+ local dir=${f%/*}
+ local fn=${f##*/}
+
+ ln -s ${fn} ${root}/${dir}/${CHOST}-${fn} || die
+ done
+
+ return
+ fi
+
for f in ${MULTILIB_WRAPPED_HEADERS[@]}; do
# drop leading slash if it's there
f=${f#/}
--
1.9.2
Re: [gentoo-dev] [PATCH 2/3] Disable wrapping only if multilib-portage is used.
Dnia 2014-04-23, o godz. 14:57:00
Michał Górny mgo...@gentoo.org napisał(a):
In other words, enable wrapping for non-multilib systems as well. While
this isn't necessary, it shouldn't hurt and it improves consistency
between systems. As a result, ebuilds can now safely use
'${CHOST}-executable' calls without checking whether the system is
multilib.
Note to self: this also enables header wrapping on arches where it
doesn't come with proper template. I need to revamp the patch to do
that only on multilib-capable arches.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] Last rites: dev-python/manifestdestiny
# Mike Gilbert flop...@gentoo.org (23 Apr 2014) # Unused python library. Should have been removed with the moz* packages. # Removal in 30 days. dev-python/manifestdestiny
Re: [gentoo-dev] ARM64 stable keyword
On Tue, Apr 22, 2014 at 09:43:24PM +0200, Tom Wijsman wrote: On Tue, 22 Apr 2014 22:13:16 +0400 Mikle Kolyada zlog...@gentoo.org wrote: 22.04.2014 21:59, Mike Gilbert пишет: Ok, then the stable keyword is going to get lost when I drop old versions. Vapier can restore stable keywords for newest version if needed, i think Repeating that is a flashing experience for the minor arches users. How so? The arm64 profiles are marked exp in profiles.desc, so we don't have to care about the keyword status. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: ARM64 stable keyword
On Wed, Apr 23, 2014 at 12:26 AM, Duncan 1i5t5.dun...@cox.net wrote: Yes, but... I think stable keywords on such archs must be used differently, and by virtue of necessity, mean something else than they mean on more mainstream archs. This was basically the gist of the Council meeting that discussed this issue. The arch is not stable, thus maintainers are not restricted from dropping the last stable version. The arch team is still welcome to mark things stable if they wish, and if they do so it is up to them to work with their users to define what this means and (ideally) document it. The Council decided not to interfere with the stable keywording, since the arch team felt it useful. Maintainers just need not pay it any attention. Rich
Re: [gentoo-dev] ARM64 stable keyword
On Wed, 23 Apr 2014 15:50:03 -0500 William Hubbs willi...@gentoo.org wrote: The arm64 profiles are marked exp in profiles.desc, so we don't have to care about the keyword status. Ah okay; nevermind then, my concern didn't take that into account. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] ARM64 stable keyword
On 04/23/2014 05:04 PM, Tom Wijsman wrote: On Wed, 23 Apr 2014 15:50:03 -0500 William Hubbs willi...@gentoo.org wrote: The arm64 profiles are marked exp in profiles.desc, so we don't have to care about the keyword status. Ah okay; nevermind then, my concern didn't take that into account. I like this technique because it allows us to build catalyst stages based on stable packages while keeping the entire arch exp. Eg. with mips, I have to build catalyst stages with KEYWORDS=mips ~mips. I'm always on the bleeding edge of the latest packages committed to the tree. Sometimes these builds fail because the ~arch edge is not well tested for consistency and I have to resort to masking. It nicer to just build on KEYWORDS=mips and then just stabilize the versions that are known to work. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
