[gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
After some discussion on IRC, it seems like limiting the building of
binaries only for the default ABI is no subject to change, but the
following workaround suggested by ssuminem seems to have been accepted
by every side, so i will include the preferred patch in one week.
workaround: add a variable, which changes the return of the function
checking for the current ABI (always true with variable, without only
true, when $ABI == $DEFAULT_ABI)
first version (multilib1.patch) directly changes the output of the
currently used multilib_is_native_abi() function:
pro: no need to change already modified ebuilds
second version (multilib2.patch) creates a new function, which should
then be used by ebuild authors to check, if they should build
ABI-specific content or not (using build_binaries() function instead of
multilib_is_native_abi() function)
pro: seperate function, so multilib_is_native_abi() can still be used,
when really just one build is needed for everyone
Happy bikesh(r)edding
--
Thomas Sachau
Gentoo Linux Developer
--- /usr/portage/eclass/multilib-build.eclass 2013-08-08 20:57:54.0 +0200
+++ multilib-build.eclass 2013-08-25 15:28:10.0 +0200
@@ -373,7 +373,11 @@
[[ ${#} -eq 0 ]] || die ${FUNCNAME}: too many arguments
- [[ ${ABI} == ${DEFAULT_ABI} ]]
+ if [[ ${COMPLETE_MULTILIB} == yes ]] ; then
+ return 0
+ else
+ [[ ${ABI} == ${DEFAULT_ABI} ]]
+ fi
}
_MULTILIB_BUILD=1
--- /usr/portage/eclass/multilib-build.eclass 2013-08-08 20:57:54.0 +0200
+++ multilib-build.eclass 2013-08-25 15:30:40.0 +0200
@@ -376,5 +376,17 @@
[[ ${ABI} == ${DEFAULT_ABI} ]]
}
+build_binaries() {
+ debug-print-function ${FUNCNAME} ${@}
+
+ [[ ${#} -eq 0 ]] || die ${FUNCNAME}: too many arguments
+
+ if [[ ${COMPLETE_MULTILIB} == yes ]] ; then
+ return 0
+ else
+ multilib_is_native_abi
+ fi
+}
+
_MULTILIB_BUILD=1
fi
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Moving more arches to dev profiles
On Sat, Aug 24, 2013 at 11:39 AM, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: Jeroen Roovers schrieb: Mixing stable and testing is precisely what package maintainers (hopefully) do when committing new versions: building and running new software on a known to be stable platform on the premise that the new software is likely to be merged into the stable branch (before the platform changes too much). At least for x11 maintained packages, we don't support mixing of stable and unstable parts of X in the way that you suggest. We don't mind however whether the rest of the system is stable or not. Ideally such restrictions should be reflected in the dependencies - for many packages they are (for example mythtv and mythplugins require matching versions and this is set in the mythplugins dependencies). However, in general supporting a mixing stable and unstable doesn't mean doing so for what amounts to split packages. Nobody would really expect kwin 4.10 to work with plasma-runtime 4.11, and so on. I don't really think there are any real problems here with Gentoo. I think almost all maintainers evaluate individual bugs on their merits and don't use non-standard configs as a cop-out. If it breaks with reasonable but non-standard CFLAGS they should be filtered (again, within reason). If there is some missing version dep then it should be stated. As jer pointed out sometimes you get reverse dep issues that aren't straightforward to fix. In those cases the solution usually isn't to close as INVALID, but to start a tracker to fix the issue (since sooner or later it has to be fixed when the dep goes stable). Not all bugs can be fixed in 5 minutes, and I think users generally appreciate that. Likewise, some configs just aren't supportable and a brief comment and a close-out is perfectly fine. Like I said - take bugs on their merits. Rich
Re: [gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
On Sun, 25 Aug 2013, Thomas Sachau wrote:
workaround: add a variable, which changes the return of the function
checking for the current ABI (always true with variable, without
only true, when $ABI == $DEFAULT_ABI)
Would this variable be set by the user, in profiles, or in ebuilds?
first version (multilib1.patch) directly changes the output of the
currently used multilib_is_native_abi() function:
I think this would be very misleading. If a function is called
multilib_is_native_abi then it should test for exactly that, not for
something else.
second version (multilib2.patch) creates a new function, which
should then be used by ebuild authors to check, if they should build
ABI-specific content or not (using build_binaries() function instead
of multilib_is_native_abi() function)
+build_binaries() {
Name space pollution? Prefix with multilib please.
+ if [[ ${COMPLETE_MULTILIB} == yes ]] ; then
+ return 0
+ else
+ multilib_is_native_abi
+ fi
This can be expressed much shorter (and clearer):
[[ ${COMPLETE_MULTILIB} == yes ]] || multilib_is_native_abi
But allow me a stupid question, why do you want to build binaries for
other ABIs anyway? It's called multilib, not multibin.
Ulrich
Re: [gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
Dnia 2013-08-25, o godz. 16:15:31 Ulrich Mueller u...@gentoo.org napisał(a): On Sun, 25 Aug 2013, Thomas Sachau wrote: first version (multilib1.patch) directly changes the output of the currently used multilib_is_native_abi() function: I think this would be very misleading. If a function is called multilib_is_native_abi then it should test for exactly that, not for something else. It's for multilib-portage. It hacks over everything in the environment. None of multilib variables are really meaningful in this context, so I don't have a problem with hacking that behavior. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
Ulrich Mueller schrieb:
On Sun, 25 Aug 2013, Thomas Sachau wrote:
workaround: add a variable, which changes the return of the function
checking for the current ABI (always true with variable, without
only true, when $ABI == $DEFAULT_ABI)
Would this variable be set by the user, in profiles, or in ebuilds?
This variable can be set by users and profiles, when they want binaries
for a different ABI (e.g. 64bit toolchain with 32bit userland).
first version (multilib1.patch) directly changes the output of the
currently used multilib_is_native_abi() function:
I think this would be very misleading. If a function is called
multilib_is_native_abi then it should test for exactly that, not for
something else.
second version (multilib2.patch) creates a new function, which
should then be used by ebuild authors to check, if they should build
ABI-specific content or not (using build_binaries() function instead
of multilib_is_native_abi() function)
+build_binaries() {
Name space pollution? Prefix with multilib please.
i dont really care about the naming, so if you prefer some multilib in
there, how about this:
multilib_build_binaries()?
+ if [[ ${COMPLETE_MULTILIB} == yes ]] ; then
+ return 0
+ else
+ multilib_is_native_abi
+ fi
This can be expressed much shorter (and clearer):
[[ ${COMPLETE_MULTILIB} == yes ]] || multilib_is_native_abi
But allow me a stupid question, why do you want to build binaries for
other ABIs anyway? It's called multilib, not multibin.
I already wrote about a setup needing the above. If a user only enables
ab_x86_32 for ebuilds with binary-restrictions, they wont get any binary
at all.
Pretty bad, when you try a reboot with e.g. no udev binaries. ;-)
In addition, users previously had the choice with multilib-portage to
build binaries for some or all target ABIs. Restricting the building of
binaries to the default ABI removes this ability from users.
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
Dnia 2013-08-25, o godz. 21:34:09 Thomas Sachau to...@gentoo.org napisał(a): Ulrich Mueller schrieb: On Sun, 25 Aug 2013, Thomas Sachau wrote: workaround: add a variable, which changes the return of the function checking for the current ABI (always true with variable, without only true, when $ABI == $DEFAULT_ABI) Would this variable be set by the user, in profiles, or in ebuilds? This variable can be set by users and profiles, when they want binaries for a different ABI (e.g. 64bit toolchain with 32bit userland). Where it simply won't work since executables for the native ABI will overwrite earlier ones. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] multilib eclass support for building binaries for none-default ABI
Michał Górny schrieb: Dnia 2013-08-25, o godz. 21:34:09 Thomas Sachau to...@gentoo.org napisał(a): Ulrich Mueller schrieb: On Sun, 25 Aug 2013, Thomas Sachau wrote: workaround: add a variable, which changes the return of the function checking for the current ABI (always true with variable, without only true, when $ABI == $DEFAULT_ABI) Would this variable be set by the user, in profiles, or in ebuilds? This variable can be set by users and profiles, when they want binaries for a different ABI (e.g. 64bit toolchain with 32bit userland). Where it simply won't work since executables for the native ABI will overwrite earlier ones. You obviously dont read my complete mails, otherwise you would have seen my later example, which works perfectly fine, once this patch applied: For the complete userland, set ABI_X86=32, so no 64bit target, no executables for the native ABI, nothing overwriting the 32bit binaries = it works. Of course, if there are further issues with the ebuilds (like only parts of the dependencies converted with those needed for the binaries left out), it may cause issues with the current situation of the eclass and ebuild, but will again allow users of multilib-portage to do exactly, what i described, since they already are able to build the dependencies for their target ABI. :-) -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2013-08-25 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2013-08-25 23h59 UTC. Removals: dev-python/python-quantumclient 2013-08-20 16:38:47 prometheanfire sys-cluster/quantum 2013-08-20 16:39:43 prometheanfire sci-libs/scikits_statsmodels2013-08-20 20:36:23 bicatali sec-policy/selinux-tvtime 2013-08-23 18:11:24 swift dev-ruby/fssm 2013-08-24 06:55:26 graaff dev-ruby/autotest-rails 2013-08-24 07:05:09 graaff dev-ruby/canny 2013-08-24 07:08:27 graaff dev-ruby/cgikit 2013-08-24 07:09:00 graaff dev-ruby/color-tools2013-08-24 07:09:40 graaff dev-ruby/diff 2013-08-24 07:10:21 graaff dev-ruby/eruby 2013-08-24 07:11:06 graaff dev-ruby/extensions 2013-08-24 07:12:03 graaff dev-ruby/fusefs 2013-08-24 07:13:10 graaff dev-ruby/imlib2-ruby2013-08-24 07:14:21 graaff dev-ruby/IO-Reactor 2013-08-24 07:14:50 graaff dev-ruby/jabber4r 2013-08-24 07:15:15 graaff dev-ruby/mega-modules 2013-08-24 07:15:54 graaff dev-ruby/merb-slices2013-08-24 07:16:20 graaff dev-ruby/nano-methods 2013-08-24 07:18:32 graaff dev-ruby/needle 2013-08-24 07:19:13 graaff dev-ruby/net-geoip 2013-08-24 07:19:34 graaff dev-ruby/nora 2013-08-24 07:20:05 graaff dev-ruby/osmlib-base2013-08-24 07:20:22 graaff dev-ruby/piston 2013-08-24 07:20:46 graaff dev-ruby/plruby 2013-08-24 07:22:12 graaff dev-ruby/quixml 2013-08-24 07:22:37 graaff dev-ruby/rbbr 2013-08-24 07:23:00 graaff dev-ruby/rflickr2013-08-24 07:26:14 graaff dev-ruby/ruby-breakpoint2013-08-24 07:26:37 graaff dev-ruby/ruby-chasen2013-08-24 07:27:00 graaff dev-ruby/ruby-eb2013-08-24 07:27:23 graaff dev-ruby/rubyfilter 2013-08-24 07:27:45 graaff dev-ruby/ruby-freedb2013-08-24 07:28:05 graaff dev-ruby/ruby-gd2013-08-24 07:28:31 graaff dev-ruby/ruby-gsl 2013-08-24 07:30:43 graaff dev-ruby/ruby-irc 2013-08-24 07:31:01 graaff dev-ruby/ruby-password 2013-08-24 07:31:20 graaff dev-ruby/ruby-pcap 2013-08-24 07:31:55 graaff dev-ruby/shipping 2013-08-24 07:32:18 graaff dev-ruby/stompserver2013-08-24 07:33:44 graaff dev-ruby/tclink 2013-08-24 07:34:24 graaff dev-ruby/webrat 2013-08-24 07:34:54 graaff dev-ruby/xml-mapping2013-08-24 07:35:19 graaff dev-ruby/xmpp4r 2013-08-24 07:35:41 graaff Additions: x11-plugins/bitlbee-steam 2013-08-19 00:36:18 hasufell dev-ruby/network_interface 2013-08-19 22:41:53 zerochaos dev-ruby/commander 2013-08-19 22:42:44 mrueg dev-ruby/colorator 2013-08-19 22:48:22 mrueg dev-ruby/directory_watcher 2013-08-20 00:16:39 mrueg dev-ruby/fast-stemmer 2013-08-20 00:22:19 mrueg dev-ruby/factory_girl 2013-08-20 03:11:24 zerochaos dev-ruby/database_cleaner 2013-08-20 03:58:12 zerochaos dev-ruby/shoulda-matchers 2013-08-20 04:11:15 zerochaos sys-cluster/neutron 2013-08-20 16:29:16 prometheanfire sys-cluster/openstack-meta 2013-08-20 18:17:49 prometheanfire dev-python/python-neutronclient 2013-08-20 18:37:30 prometheanfire dev-python/statsmodels 2013-08-20 20:29:22 bicatali dev-python/python-quantumclient 2013-08-22 04:49:05 prometheanfire media-gfx/fim 2013-08-23 12:40:04 xmw mail-filter/sieve-connect 2013-08-23 12:40:39 hasufell dev-python/requests-oauthlib2013-08-24 07:36:49 ercpe dev-python/twython 2013-08-24 07:49:44 ercpe dev-haskell/monadcatchio-transformers 2013-08-25 04:48:16 qnikst dev-haskell/maccatcher 2013-08-25 04:54:53 qnikst dev-haskell/aeson 2013-08-25 04:58:59 qnikst dev-haskell/glob2013-08-25 05:08:55 qnikst dev-haskell/ieee754 2013-08-25 05:15:09 qnikst dev-haskell/erf
