Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
Am Montag, 4. März 2013, 03:19:17 schrieb Peter Stuge: Again, I guess you have to make Mike go away now. I never said that so please just stop it. You threatened to preempt me if I wanted to become a developer and found his practise OK - meaning that the behavior is unacceptable. If you are to be the least consistent you really need to also threaten to remove him. (It would be pretty ridiculously hipocratic and of course harmful for project evolution if the rules apply only to aspiring devs.) But I'd obviously prefer if you didn't do that to him. Seriously. While I'm all for sticking to the rules, I'm also sometimes glad that Gentoo is not as bad as proverbial German bureaucracy. The fact is, people who have been around for a long time, do a lot of important work and are trusted by the dev community may be able to bend the rules *for good reason*. [I personally would prefer if that would occur less frequently though.] This discussion is about whether it was really necessary (the for good reason part) or could have been done in other ways. Starting as a developer or aspiring to become one with that attitude is not acceptable. No discussion of that needed. -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs
On Sun, 03 Mar 2013 22:39:42 +0100 Thomas Sachau to...@gentoo.org wrote: The wrapper is already in a seperate package [1], the currently active and tested version (1.0) is in bash, also there is a (currently masked) version 2.0 written by binki in C doing the same natively. So you even have a choice in what to use. :-) Good and not so good: We don't really have a choice, for portability we need a C version otherwise shebangs are broken with older linux kernels and non-linux platforms. ( Do you remember the python-wrapper mess? :) ) It'd be nice to have a well tested C version. Alexis.
Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs
On Sun, 3 Mar 2013 23:25:03 +0100
Michał Górny mgo...@gentoo.org wrote:
On Sun, 3 Mar 2013 18:18:12 +0100
Alexis Ballier aball...@gentoo.org wrote:
On Sun, 3 Mar 2013 17:58:26 +0100
Michał Górny mgo...@gentoo.org wrote:
What do we need that wrapper for? What does the wrapper do? Does
it just rely on custom 'ABI' variable?
yes -- it must perform some checks though.
What kind of checks?
you are called with ABI=sth argv[0] = your name
if argv[0] = abiwrapper - print some information and exit
getenv ABI - if nothing then set ABI=$DEFAULT_ABI (hardcoded at
buildtime of the wrapper)
execvp(argv[0]_$ABI, argv)
if execvp returns: print a warning, execvp argv[0]_$DEFAULT_ABI
python-wrapper.c is very likely to have such a logic already.
btw, IMHO ABI is a too common name for such a variable, I'd better name
it something like _GENTOO_MULTILIB_ABI so that collisions are much less
likely.
Or maybe should it try to detect
whether it was called by a 64- or 32-bit app?
this wont work: think about a build system, your shell/make will
likely be your default abi's but may call abi-specific tools
depending on what you build _for_ not what you build _with_
That's one side of it. The other is that if it worked, it may be
something really unexpected. Do you expect things to work differently
when called by a 32-bit program?
That's why I asked for examples :)
qmake may do it, I don't think its sane, but that's life for now.
having glxinfo for each abi is useful from a user perspective (it does
not need the wrapper a priori though)
What for?
in order to be transparent from the ebuild perspective.
That depends on what kind of transparency do we want. I prefer being
explicit here rather than assuming something you can't know for sure.
See it something like python-wrapper. EPYTHON=python3.2 python - runs
python3.2 :)
I think we're starting to miss the point of multilib. Multilib was
intended as a cheap way of getting things working. I believe that we
should still consider it so, and keep it in cages rather than
believing that the world is more fun with tigers jumping around.
That said, I wouldn't say that making random executables in system
work differently on ${ABI} is a way to go. That leaves the tricky
imprint of multilib visible to users who shouldn't care about it. If
they do, they're looking for multilib-portage.
To some extent that's what happened to python too :) As a python
maintainer, you could share your thoughts on the topic. python slotting
was intended to make switching between python versions easy but has
been needing wrappers for the python binary.
The whole 'switching' part of multilib should be kept part of our
build system -- eclasses, ebuilds or just some specificities like
libdir or pkg-config path switching.
Maybe, but that would involve perfectly working setups being broken.
It's like packages not respecting CC being broken for cross-compiling,
those not respecting CFLAGS being broken for multilib, etc. packages
calling directly binaries having ABI specific output will be broken for
multilib too (and I don't know of anyone checking for this while the
other two have been long standing issues we tried to fix). We can fix
this, but the fact is that we need multi-binary support for users, then
the only choice to make is if we want to provide a wrapper so that we
do not need to fix build systems or if we want to fix them. The latter
is likely preferred but I do not know what kind of work it will involve.
It'd help if tommy could provide a list of binaries he needed to wrap
through the abiwrapper.
Alexis.
Re: [gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers
On Sun, 3 Mar 2013 15:39:16 -0600 Doug Goldstein car...@gentoo.org wrote: One of the reasons people volunteer in open source projects is to scratch their personal itch. When that itch develops into a festering, gangrenous limb it becomes time to amputate it. That is what I am doing with my involvement in x11-drivers/nvidia-drivers. Sad, but understandable. As a result someone will need to work with spock and rej to figure jer and xarthisius out what aspects they are able to maintain and then maintain the components they aren't able to. For example, different hardware has different series of drivers to support it. I still happen to run all the hardware to test all of the major versions currently supported upstream. jer
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
Andreas K. Huettel wrote: Starting as a developer or aspiring to become one with that attitude is not acceptable. That doesn't make sense to me. If the reason is good, surely it does not matter who is doing the breaking? //Peter pgpvkacjjiVYz.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On Mon, Mar 4, 2013 at 5:58 AM, Peter Stuge pe...@stuge.se wrote: Andreas K. Huettel wrote: Starting as a developer or aspiring to become one with that attitude is not acceptable. That doesn't make sense to me. If the reason is good, surely it does not matter who is doing the breaking? Well there is an implication that new developers are not experienced and are more prone to making choices with faulty reasoning. This is obviously not true of all new developers, but likely remains a good heuristic. -A //Peter
Re: [gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers
On Sun, Mar 03, 2013 at 10:48:07PM -0500, Rick Zero_Chaos Farina wrote I am sorry that this package has been such a headache for you, unfortunately binary drivers (especially) are often like that. Thanks for all your hard work keeping this usable. I'm not a C programmer, let alone a developer, so this may be a stupid question, but here goes... has anyone ever tried doing a HAL (Hardware Abstraction Layer) to present a reasonably stable interface to binary video drivers? Think of it as a shim translating a pseudo-API into the real API that the kernel exposes directly. Surely, we can do better than VESA. Give drivers 2 options... 1) direct kernel access like now 2) access via the HAL/shim -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers
On Mon, Mar 4, 2013 at 3:28 PM, Walter Dnes waltd...@waltdnes.org wrote: I'm not a C programmer, let alone a developer, so this may be a stupid question, but here goes... has anyone ever tried doing a HAL (Hardware Abstraction Layer) to present a reasonably stable interface to binary video drivers? Think of it as a shim translating a pseudo-API into the real API that the kernel exposes directly. Surely, we can do better than VESA. Give drivers 2 options... 1) direct kernel access like now 2) access via the HAL/shim Just read this file and you'll have the answer: /usr/src/linux/Documentation/stable_api_nonsense.txt
Re: [gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers
On Mon, 2013-03-04 at 11:28 -0500, Walter Dnes wrote: On Sun, Mar 03, 2013 at 10:48:07PM -0500, Rick Zero_Chaos Farina wrote I am sorry that this package has been such a headache for you, unfortunately binary drivers (especially) are often like that. Thanks for all your hard work keeping this usable. I'm not a C programmer, let alone a developer, so this may be a stupid question, but here goes... has anyone ever tried doing a HAL (Hardware Abstraction Layer) to present a reasonably stable interface to binary video drivers? Think of it as a shim translating a pseudo-API into the real API that the kernel exposes directly. Surely, we can do better than VESA. Give drivers 2 options... 1) direct kernel access like now 2) access via the HAL/shim For video drivers, there are only a few things that can be abstracted away, e.g. hardware access synchronization, DMA, power management, a memory manager for GPUs without dedicated video memory. And the kernel already does have an API for this, called DRM (direct rendering manager); see https://www.kernel.org/doc/htmldocs/drm.html However, nvidia-drivers does not use this API, probably because they want to share code between their Linux and Windows drivers, and the Linux kernel's DRM API is too different from what Windows does. In addition, there might be licensing issues: I once read an argument that if a proprietary kernel module is too closely integrated with features that exists only in the Linux kernel and that cannot be applicable to other operating systems, the module might legally become a derived work of the Linux kernel, and so would need to be open-sourced under the GPL.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog
On 03/03/13 16:42, hasufell wrote: On 03/03/2013 08:11 AM, Alec Warner wrote: There was a big ole' chat on #gentoo-dev regarding this. My understanding of the summary is that the nvidia-driver Gentoo team only supports kernels that nvidia themselves (upstream) support. The Kernels 3.4 are not supported by upstream, so they are also not supported in Gentoo. I believe the ebuild contains instructions on using user_patches to get these patches. The nvidia maintainers in Gentoo do not want to be responsible for those patches though; this is why they are not included (and why your commit was reverted.) I do not find their stance wholly unreasonable. They offered to point users at an overlay, if someone was willing to maintain the patches there (in lieu of user_patches.) The end result is that if users apply the patches, they will get an unsupported setup. There is a fear as well, that the patches may damage cards (since the patches are not supported by the vendor.) What do we have useflags for in gentoo? add a unsupported-kernels useflag, mask it, add a clear statement in the masking reason and be done IUSE=+vanilla with the + if the maintainer wants should cover all the issues brought up so far - Samuli
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in x11-drivers/nvidia-drivers: nvidia-drivers-313.18.ebuild ChangeLog
On 03/03/13 19:24, Ryan Hill wrote: On Sun, 03 Mar 2013 15:42:56 +0100 hasufell hasuf...@gentoo.org wrote: What do we have useflags for in gentoo? Not for conditional patching, that's for sure. Yet that is exactly what IUSE=vanilla is designed for... ;-)
[gentoo-dev] Re: maintainer-wanted: x11-drivers/nvidia-drivers
Walter Dnes posted on Mon, 04 Mar 2013 11:28:50 -0500 as excerpted: On Sun, Mar 03, 2013 at 10:48:07PM -0500, Rick Zero_Chaos Farina wrote I am sorry that this package has been such a headache for you, unfortunately binary drivers (especially) are often like that. Thanks for all your hard work keeping this usable. I'm not a C programmer, let alone a developer, so this may be a stupid question, but here goes... has anyone ever tried doing a HAL (Hardware Abstraction Layer) to present a reasonably stable interface to binary video drivers? Think of it as a shim translating a pseudo-API into the real API that the kernel exposes directly. Surely, we can do better than VESA. Give drivers 2 options... 1) direct kernel access like now 2) access via the HAL/shim Actually, I believe that's pretty much what the nvidia driver (specifically, in contrast to some other binary kernel modules) does. They have their binary core which is common between supported platforms, and an open-source kernel shim[1] that is what people build when they build the nvidia kernel module. However, due to the kernel's specifically NOT declared stable kernel- space-API[2], the shim code must change with nearly every kernel to match the new kernel code. As might be expected from a proprietary upstream that refuses to open their code and thus must support it themselves, upstream nvidia often falls behind, sometimes quite some way behind, both the kernel and xorg. Thus this thread... Of course it's possible to implement a userspace driver that wouldn't have the same issues as it'd use the stable userspace API, but that's generally accepted to be far too high a performance cost for graphics drivers, regardless of the kernel involved (MS tried it too for stability reasons and gave up at the performance penalty they were taking). --- [1] The shim is licensed MIT or the like, such that the code can link to both the kernel and the binary-core-black-box. So far, it has been allowed by the kernel folks under certain conditions, including that it not ship /with/ the kernel (various distros have run into that issue trying to ship it on their distribution media), and that it not attempt to link to the exported-as-GPL kernel symbols, just the general exported symbols. But the nvidia driver is in somewhat better legal shape than many binary drivers because it /does/ use the same common core, which thus can be argued not to be a derivative of the kernel and thus not to fall under the copyright law which gives the GPL its legal teeth. Between that and the open-sourcing of the shim, as long as they stick to the general exported symbols and don't try to use the GPL-exported symbols, they should be fine. [2] Ever-changing kernel-space-API: This is in contrast to user-space, which they put a LOT of effort into keeping stable. Also see the stable- api-nonsense document another reply already linked. Among other things, this both allows faster development and encourages the open-sourcing and upstreaming of code, since then the person doing the API changes must take care of it. -- 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
Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs
Alexis Ballier schrieb:
On Sun, 3 Mar 2013 23:25:03 +0100
Michał Górny mgo...@gentoo.org wrote:
On Sun, 3 Mar 2013 18:18:12 +0100
Alexis Ballier aball...@gentoo.org wrote:
On Sun, 3 Mar 2013 17:58:26 +0100
Michał Górny mgo...@gentoo.org wrote:
What do we need that wrapper for? What does the wrapper do? Does
it just rely on custom 'ABI' variable?
yes -- it must perform some checks though.
What kind of checks?
you are called with ABI=sth argv[0] = your name
if argv[0] = abiwrapper - print some information and exit
getenv ABI - if nothing then set ABI=$DEFAULT_ABI (hardcoded at
buildtime of the wrapper)
execvp(argv[0]_$ABI, argv)
if execvp returns: print a warning, execvp argv[0]_$DEFAULT_ABI
python-wrapper.c is very likely to have such a logic already.
btw, IMHO ABI is a too common name for such a variable, I'd better name
it something like _GENTOO_MULTILIB_ABI so that collisions are much less
likely.
Or maybe should it try to detect
whether it was called by a 64- or 32-bit app?
this wont work: think about a build system, your shell/make will
likely be your default abi's but may call abi-specific tools
depending on what you build _for_ not what you build _with_
That's one side of it. The other is that if it worked, it may be
something really unexpected. Do you expect things to work differently
when called by a 32-bit program?
That's why I asked for examples :)
qmake may do it, I don't think its sane, but that's life for now.
having glxinfo for each abi is useful from a user perspective (it does
not need the wrapper a priori though)
What for?
in order to be transparent from the ebuild perspective.
That depends on what kind of transparency do we want. I prefer being
explicit here rather than assuming something you can't know for sure.
See it something like python-wrapper. EPYTHON=python3.2 python - runs
python3.2 :)
I think we're starting to miss the point of multilib. Multilib was
intended as a cheap way of getting things working. I believe that we
should still consider it so, and keep it in cages rather than
believing that the world is more fun with tigers jumping around.
That said, I wouldn't say that making random executables in system
work differently on ${ABI} is a way to go. That leaves the tricky
imprint of multilib visible to users who shouldn't care about it. If
they do, they're looking for multilib-portage.
To some extent that's what happened to python too :) As a python
maintainer, you could share your thoughts on the topic. python slotting
was intended to make switching between python versions easy but has
been needing wrappers for the python binary.
The whole 'switching' part of multilib should be kept part of our
build system -- eclasses, ebuilds or just some specificities like
libdir or pkg-config path switching.
Maybe, but that would involve perfectly working setups being broken.
It's like packages not respecting CC being broken for cross-compiling,
those not respecting CFLAGS being broken for multilib, etc. packages
calling directly binaries having ABI specific output will be broken for
multilib too (and I don't know of anyone checking for this while the
other two have been long standing issues we tried to fix). We can fix
this, but the fact is that we need multi-binary support for users, then
the only choice to make is if we want to provide a wrapper so that we
do not need to fix build systems or if we want to fix them. The latter
is likely preferred but I do not know what kind of work it will involve.
It'd help if tommy could provide a list of binaries he needed to wrap
through the abiwrapper.
Alexis.
The actual list of packages with wrapped binaries is in the profiles dir
of the multilib-portage overlay (expect this to be a minimal list, there
are probably more out there we did not yet catch):
dev-db/mysql abiwrapper
dev-lang/perl abiwrapper
dev-lang/python abiwrapper
dev-lang/ruby abiwrapper
dev-libs/gobject-introspection abiwrapper
dev-libs/libIDL abiwrapper
dev-scheme/guile abiwrapper
net-libs/courier-authlib abiwrapper
dev-qt/qtcore abiwrapper
dev-qt/qtgui abiwrapper
media-libs/fontconfig abiwrapper
www-servers/apache abiwrapper
x11-libs/pango abiwrapper
x11-libs/gtk+ abiwrapper
Keep in mind, that multilib-portage does always and unconditionally wrap
*-config binaries. If you dont want to add that logic to the eclass, you
need to add all packages providing such files to the list.
--
Thomas Sachau
Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs
On Mon, 4 Mar 2013 11:02:40 +0100
Alexis Ballier aball...@gentoo.org wrote:
On Sun, 3 Mar 2013 23:25:03 +0100
Michał Górny mgo...@gentoo.org wrote:
On Sun, 3 Mar 2013 18:18:12 +0100
Alexis Ballier aball...@gentoo.org wrote:
On Sun, 3 Mar 2013 17:58:26 +0100
Michał Górny mgo...@gentoo.org wrote:
What do we need that wrapper for? What does the wrapper do? Does
it just rely on custom 'ABI' variable?
yes -- it must perform some checks though.
What kind of checks?
you are called with ABI=sth argv[0] = your name
I'm afraid that's the first potential point of failure. Relying
on argv[0] is a poor idea and means that any application calling exec()
with changed argv[0] on a wrapped binary will fail terribly.
if argv[0] = abiwrapper - print some information and exit
getenv ABI - if nothing then set ABI=$DEFAULT_ABI (hardcoded at
buildtime of the wrapper)
execvp(argv[0]_$ABI, argv)
if execvp returns: print a warning, execvp argv[0]_$DEFAULT_ABI
python-wrapper.c is very likely to have such a logic already.
btw, IMHO ABI is a too common name for such a variable, I'd better name
it something like _GENTOO_MULTILIB_ABI so that collisions are much less
likely.
I'm afraid you are actually starting to go the other way.
Global wrapper means that it is potentially useful to our users.
However I don't really see people who want to compile 32-bit
executables think of setting some custom variable like ABI.
Moreover, if we replace that with a specific, 'private' environment
variable like you suggested, we're actually discouraging people from
using it. So, we're force-installing wrappers which make things fragile
and at the same time provide no benefit for regular users.
Or maybe should it try to detect
whether it was called by a 64- or 32-bit app?
this wont work: think about a build system, your shell/make will
likely be your default abi's but may call abi-specific tools
depending on what you build _for_ not what you build _with_
That's one side of it. The other is that if it worked, it may be
something really unexpected. Do you expect things to work differently
when called by a 32-bit program?
That's why I asked for examples :)
qmake may do it, I don't think its sane, but that's life for now.
having glxinfo for each abi is useful from a user perspective (it does
not need the wrapper a priori though)
Yep, I intended to just have the additional variant of glxinfo directly
callable, with a name chosen specifically by the X11 team. Wrapper
would be more confusing than beneficial here IMO.
What for?
in order to be transparent from the ebuild perspective.
That depends on what kind of transparency do we want. I prefer being
explicit here rather than assuming something you can't know for sure.
See it something like python-wrapper. EPYTHON=python3.2 python - runs
python3.2 :)
Err, python-wrapper respects quite complex logic involving EPYTHON,
and eselect-python. We don't really want people to have eselect-abi,
do we?
If we were to implement abi-wrapper, it will be much simpler than any
logic needed for Python.
I think we're starting to miss the point of multilib. Multilib was
intended as a cheap way of getting things working. I believe that we
should still consider it so, and keep it in cages rather than
believing that the world is more fun with tigers jumping around.
That said, I wouldn't say that making random executables in system
work differently on ${ABI} is a way to go. That leaves the tricky
imprint of multilib visible to users who shouldn't care about it. If
they do, they're looking for multilib-portage.
To some extent that's what happened to python too :) As a python
maintainer, you could share your thoughts on the topic. python slotting
was intended to make switching between python versions easy but has
been needing wrappers for the python binary.
I'm doing just that. Any kind of wrapping is an increasing mess. I'm
still trying to find out good solutions for Python wrapping but there's
no such thing. It's always about choosing one evil over the other.
The whole 'switching' part of multilib should be kept part of our
build system -- eclasses, ebuilds or just some specificities like
libdir or pkg-config path switching.
Maybe, but that would involve perfectly working setups being broken.
It's like packages not respecting CC being broken for cross-compiling,
those not respecting CFLAGS being broken for multilib, etc.
Just to make it clear, multilib.eclass overrides CC for multilib. It
does not rely on CFLAGS. I don't know the rationale, I can guess only.
packages
calling directly binaries having ABI specific output will be broken for
multilib too (and I don't know of anyone checking for this while the
other two have been long standing issues we tried to fix). We can fix
this, but the fact is that we need multi-binary support for users, then
the only choice to
Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs
Michał Górny schrieb:
On Mon, 4 Mar 2013 11:02:40 +0100
Alexis Ballier aball...@gentoo.org wrote:
On Sun, 3 Mar 2013 23:25:03 +0100
Michał Górny mgo...@gentoo.org wrote:
On Sun, 3 Mar 2013 18:18:12 +0100
Alexis Ballier aball...@gentoo.org wrote:
On Sun, 3 Mar 2013 17:58:26 +0100
Michał Górny mgo...@gentoo.org wrote:
What do we need that wrapper for? What does the wrapper do? Does
it just rely on custom 'ABI' variable?
yes -- it must perform some checks though.
What kind of checks?
you are called with ABI=sth argv[0] = your name
I'm afraid that's the first potential point of failure. Relying
on argv[0] is a poor idea and means that any application calling exec()
with changed argv[0] on a wrapped binary will fail terribly.
Nobody said, that one cannot create situations, where such a wrapper
does fail, the point is more an easy and general solution for wrapping
binaries without implementing different solutions for the same issue in
every ebuild.
If you have a better, yet still easy and general solution not requiring
every ebuild to create something on its own, please write it instead of
just complaining how bad the wrapper solution actually is.
if argv[0] = abiwrapper - print some information and exit
getenv ABI - if nothing then set ABI=$DEFAULT_ABI (hardcoded at
buildtime of the wrapper)
execvp(argv[0]_$ABI, argv)
if execvp returns: print a warning, execvp argv[0]_$DEFAULT_ABI
python-wrapper.c is very likely to have such a logic already.
btw, IMHO ABI is a too common name for such a variable, I'd better name
it something like _GENTOO_MULTILIB_ABI so that collisions are much less
likely.
I'm afraid you are actually starting to go the other way.
Global wrapper means that it is potentially useful to our users.
However I don't really see people who want to compile 32-bit
executables think of setting some custom variable like ABI.
Unless you implied, that you want users to compile from hand instead of
using an ebuild, this makes no sense to me.
This ABI variable is of course set when setting up the environment, so
it is around in every phase and any call to an abi-wrapped binary
directly gets the right one for the current ABI.
Or maybe should it try to detect
whether it was called by a 64- or 32-bit app?
this wont work: think about a build system, your shell/make will
likely be your default abi's but may call abi-specific tools
depending on what you build _for_ not what you build _with_
That's one side of it. The other is that if it worked, it may be
something really unexpected. Do you expect things to work differently
when called by a 32-bit program?
That's why I asked for examples :)
qmake may do it, I don't think its sane, but that's life for now.
having glxinfo for each abi is useful from a user perspective (it does
not need the wrapper a priori though)
Yep, I intended to just have the additional variant of glxinfo directly
callable, with a name chosen specifically by the X11 team. Wrapper
would be more confusing than beneficial here IMO.
Ah, you actually want each ebuild to have its own custom hack instead of
one global solution usable everywhere?
What for?
in order to be transparent from the ebuild perspective.
That depends on what kind of transparency do we want. I prefer being
explicit here rather than assuming something you can't know for sure.
See it something like python-wrapper. EPYTHON=python3.2 python - runs
python3.2 :)
Err, python-wrapper respects quite complex logic involving EPYTHON,
and eselect-python. We don't really want people to have eselect-abi,
do we?
If we were to implement abi-wrapper, it will be much simpler than any
logic needed for Python.
Exactly: Just the environment variable, no eselect module, simple, easy
to understand and working.
I think we're starting to miss the point of multilib. Multilib was
intended as a cheap way of getting things working. I believe that we
should still consider it so, and keep it in cages rather than
believing that the world is more fun with tigers jumping around.
That said, I wouldn't say that making random executables in system
work differently on ${ABI} is a way to go. That leaves the tricky
imprint of multilib visible to users who shouldn't care about it. If
they do, they're looking for multilib-portage.
To some extent that's what happened to python too :) As a python
maintainer, you could share your thoughts on the topic. python slotting
was intended to make switching between python versions easy but has
been needing wrappers for the python binary.
I'm doing just that. Any kind of wrapping is an increasing mess. I'm
still trying to find out good solutions for Python wrapping but there's
no such thing. It's always about choosing one evil over the other.
So you are wrapping python, have not yet found anything better and still
dont want to wrap abi-specific binaries, while you dont have a better
solution at hand? Saying no to
Re: [gentoo-dev] Re: [RFC] multilib-build.eclass and restricting unsupported ABIs
On Mon, 04 Mar 2013 23:21:36 +0100 Thomas Sachau to...@gentoo.org wrote: Michał Górny schrieb: On Mon, 4 Mar 2013 11:02:40 +0100 Alexis Ballier aball...@gentoo.org wrote: you are called with ABI=sth argv[0] = your name I'm afraid that's the first potential point of failure. Relying on argv[0] is a poor idea and means that any application calling exec() with changed argv[0] on a wrapped binary will fail terribly. Nobody said, that one cannot create situations, where such a wrapper does fail, the point is more an easy and general solution for wrapping binaries without implementing different solutions for the same issue in every ebuild. There's no such thing as 'easy and general solution'. You always sacrifice something. And in this case, you're creating a point of failure which is completely custom to Gentoo and actually quite hard to track. Just to support a specific package manager feature specific to Gentoo. If you have a better, yet still easy and general solution not requiring every ebuild to create something on its own, please write it instead of just complaining how bad the wrapper solution actually is. The solution is called eclasses. Yep, I intended to just have the additional variant of glxinfo directly callable, with a name chosen specifically by the X11 team. Wrapper would be more confusing than beneficial here IMO. Ah, you actually want each ebuild to have its own custom hack instead of one global solution usable everywhere? Yes. To some extent that's what happened to python too :) As a python maintainer, you could share your thoughts on the topic. python slotting was intended to make switching between python versions easy but has been needing wrappers for the python binary. I'm doing just that. Any kind of wrapping is an increasing mess. I'm still trying to find out good solutions for Python wrapping but there's no such thing. It's always about choosing one evil over the other. So you are wrapping python, have not yet found anything better and still dont want to wrap abi-specific binaries, while you dont have a better solution at hand? Saying no to everything is easy, providing something better if you dont like a suggestion is the challenge. Yes, it is easy and mess-free. Using a cheap hack is mess-full, and is just asking for trouble which will eventually rise. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] proxy-maintainers herd as a backup herd for all the user-maintained packages
On Sun, 03 Mar 2013 19:35:24 + Markos Chandras hwoar...@gentoo.org wrote: A number of packages in the tree are maintained by a Gentoo developer and a user. As a result of which, we are unable to monitor these packages in bugzilla. This is useful in case one of the maintainers goes MIA so we can find an alternative maintainer for them. So I am kindly asking you to add the proxy-maintainers herd as a backup herd for the packages that you proxy-maintain. I will go ahead and do it myself in two weeks if you don't want to bother fixing your metadata. If you want your packages to be excluded please let me know. This is mainly for tracking purposes and we don't intend to take over the maintainership of your packages (unless you want us to). Excellent idea. But how will proxy-maint@ devs know not to take over? jer
Re: [gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers
On Mon, Mar 04, 2013 at 03:44:33PM -0100, Carlos Silva wrote On Mon, Mar 4, 2013 at 3:28 PM, Walter Dnes waltd...@waltdnes.org wrote: I'm not a C programmer, let alone a developer, so this may be a stupid question, but here goes... has anyone ever tried doing a HAL (Hardware Abstraction Layer) to present a reasonably stable interface to binary video drivers? Think of it as a shim translating a pseudo-API into the real API that the kernel exposes directly. Surely, we can do better than VESA. Give drivers 2 options... 1) direct kernel access like now 2) access via the HAL/shim Just read this file and you'll have the answer: /usr/src/linux/Documentation/stable_api_nonsense.txt Thanks. That was an eye-opener. If user-space drivers are really that slow, we may as well stick with VESA as a fallback. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
