Mike Frysinger posted on Sat, 26 Jan 2013 02:46:12 -0500 as excerpted:
> if the package supports USE=caps, then it means the program is
> intelligent enough to know what capabilities it needs and so it can drop
> all of the rest before executing the main body of code.
> wouldn't it be nice if you
I am starting to think that the real problem is that Gentoo does not
have ebuilds for building kernels (binary kernels). At that point, it
would be easy to add USE flags and virtual packages to solve the
config check problem at the dependencies level once and for all.
--
Fabio Erculiani
Hello,
As spoken earlier, I have split out a set of common functions
from autotools-multilib to multilib-build eclass. The new eclass
provides:
- IUSE for multilib setup,
- MULTILIB_USEDEP for creating deps,
- multilib_foreach_abi() and multilib_parallel_foreach_abi() to run
commands iteratin
I have decided to remove autotools-multilib_* utility functions
completely since the sole consumer of the eclass does not use it.
---
gx86/eclass/autotools-multilib.eclass | 84 +++
1 file changed, 5 insertions(+), 79 deletions(-)
diff --git a/gx86/eclass/autotools
The eclass does:
- export proper USE flags to control the built ABIs,
- provide MULTILIB_USEDEP to write proper USE dependencies,
- provide utility functions to run commands for each ABI.
---
gx86/eclass/multilib-build.eclass | 103 ++
1 file changed, 103 ins
On Wed, 23 Jan 2013 21:40:13 -0300
Alexis Ballier wrote:
> On Thu, 24 Jan 2013 00:23:57 +0100
> Michał Górny wrote:
>
> > This is mostly a proof-of-concept. If approved, I will work on moving
> > the code into a separate eclass, possibly named 'multilib-build' ;).
> > ---
> > gx86/eclass/autot
On Fri, 25 Jan 2013 18:51:44 -0500
Mike Frysinger wrote:
> # Or set it via the global ebuild var FILECAPS:
> # @CODE
> # FILECAPS=(
> # cap_net_raw bin/ping bin/ping6
> # )
> # @CODE
Please don't. We have enough eclasses randomly exporting
pkg_postinst().
The FILECAPS array consumes the sam
On Sat, 26 Jan 2013 13:11:41 +0100
Michał Górny wrote:
> On Wed, 23 Jan 2013 21:40:13 -0300
> Alexis Ballier wrote:
>
> > On Thu, 24 Jan 2013 00:23:57 +0100
> > Michał Górny wrote:
> >
> > > This is mostly a proof-of-concept. If approved, I will work on
> > > moving the code into a separate e
On Sat, 26 Jan 2013 13:11:41 +0100
Michał Górny wrote:
> > (maybe protect it with has_multilib_profile if you wish)
>
> Well, the current code assumes that no flags == non-multilib profile.
.. and I hit send to quickly:
coming back to the skype example, with this assumption, on x86
libitnee
On Sat, 26 Jan 2013 11:51:22 -0300
Alexis Ballier wrote:
> On Sat, 26 Jan 2013 13:11:41 +0100
> Michał Górny wrote:
>
> > On Wed, 23 Jan 2013 21:40:13 -0300
> > Alexis Ballier wrote:
> >
> > > On Thu, 24 Jan 2013 00:23:57 +0100
> > > Michał Górny wrote:
> > >
> > > > This is mostly a proof-
On Sat, 26 Jan 2013 11:54:44 -0300
Alexis Ballier wrote:
> On Sat, 26 Jan 2013 13:11:41 +0100
> Michał Górny wrote:
>
> > > (maybe protect it with has_multilib_profile if you wish)
> >
> > Well, the current code assumes that no flags == non-multilib profile.
>
> .. and I hit send to quick
On Sat, 26 Jan 2013 16:06:35 +0100
Michał Górny wrote:
> On Sat, 26 Jan 2013 11:51:22 -0300
> Alexis Ballier wrote:
>
> > On Sat, 26 Jan 2013 13:11:41 +0100
> > Michał Górny wrote:
> >
> > > On Wed, 23 Jan 2013 21:40:13 -0300
> > > Alexis Ballier wrote:
> > >
> > > > On Thu, 24 Jan 2013 00:
On Sat, 26 Jan 2013 16:08:45 +0100
Michał Górny wrote:
> On Sat, 26 Jan 2013 11:54:44 -0300
> Alexis Ballier wrote:
>
> > On Sat, 26 Jan 2013 13:11:41 +0100
> > Michał Górny wrote:
> >
> > > > (maybe protect it with has_multilib_profile if you wish)
> > >
> > > Well, the current code ass
On 26/01/2013 08:46, Mike Frysinger wrote:
>
> at least, this is all my understanding of things. i could be completely
> wrong, so feel free to correct something if you notice it.
All looks good to me, but just because somebody is going to wonder this
I would add a few words:
While this is bas
On Sat, Jan 26, 2013 at 11:01 AM, Diego Elio Pettenò
wrote:
>
> There's also a different kind of capabilities, in theory, relating to
> users instead and using PAM — but I never got to get it working :(
I naively assumed that if you edit /etc/security/capability.conf this
would set the per-user c
On 26/01/2013 17:13, Rich Freeman wrote:
> I naively assumed that if you edit /etc/security/capability.conf this
> would set the per-user capabilities. However, I have not actually
> tried this. I guess our pam configuration/etc isn't set to check this
> file?
pambase is not enabling pam_caps, s
On Sat, 26 Jan 2013 12:30:16 -0300
Alexis Ballier wrote:
> On Sat, 26 Jan 2013 16:08:45 +0100
> Michał Górny wrote:
>
> > On Sat, 26 Jan 2013 11:54:44 -0300
> > Alexis Ballier wrote:
> >
> > > On Sat, 26 Jan 2013 13:11:41 +0100
> > > Michał Górny wrote:
> > >
> > > > > (maybe protect it wit
On Saturday 26 January 2013 08:21:37 Michał Górny wrote:
> On Fri, 25 Jan 2013 18:51:44 -0500 Mike Frysinger wrote:
> > # Or set it via the global ebuild var FILECAPS:
> > # @CODE
> > # FILECAPS=(
> > # cap_net_raw bin/ping bin/ping6
> > # )
> > # @CODE
>
> Please don't. We have enough eclasses
On Sat, 26 Jan 2013 18:06:32 +0100
Michał Górny wrote:
> On Sat, 26 Jan 2013 12:30:16 -0300
> Alexis Ballier wrote:
>
> > On Sat, 26 Jan 2013 16:08:45 +0100
> > Michał Górny wrote:
> >
> > > On Sat, 26 Jan 2013 11:54:44 -0300
> > > Alexis Ballier wrote:
> > >
> > > > On Sat, 26 Jan 2013 13:
On Sat, 26 Jan 2013 14:43:38 -0300
Alexis Ballier wrote:
> On Sat, 26 Jan 2013 18:06:32 +0100
> Michał Górny wrote:
>
> > On Sat, 26 Jan 2013 12:30:16 -0300
> > Alexis Ballier wrote:
> >
> > > On Sat, 26 Jan 2013 16:08:45 +0100
> > > Michał Górny wrote:
> > >
> > > > On Sat, 26 Jan 2013 11:
On Fri, Jan 25, 2013 at 5:51 PM, Mike Frysinger wrote:
> i've taken Constanze' work and rewritten it a bit to be easier to use (imo) as
> most settings are now defaults
> -mike
>
Good deal. Good idea on using USE=filecaps instead of USE=caps due to
the requirements. Once this hits the tree I'll l
Hello,
Following all the suggestions from Alexis Ballier, I have reworked
the code to remove multiple points of failure. I have also rebased it
on the common multilib-build eclass concept, and updated amd64
no-multilib & x86 profiles as well.
Key points:
1. The list of available flags and corres
This time, following suggestions from Alexis Ballier, the complete list
of USE flags and corresponding ABIs is stored in a single variable.
I have removed the arch hack and all selected ABIs are validated against
$(get_all_abis) from multilib.eclass.
---
gx86/eclass/multilib-build.eclass | 36
It will become especially useful when more ABI flags are introduced.
---
gx86/eclass/multilib-build.eclass | 59 ++-
1 file changed, 34 insertions(+), 25 deletions(-)
diff --git a/gx86/eclass/multilib-build.eclass
b/gx86/eclass/multilib-build.eclass
index d8bd
---
gx86/profiles/base/make.defaults | 4 ++--
gx86/profiles/base/use.mask | 5 +
gx86/profiles/desc/abi_x86.desc | 10 ++
3 files changed, 17 insertions(+), 2 deletions(-)
create mode 100644 gx86/profiles/desc/abi_x86.desc
diff --git a/gx86/profiles/base/make.defaults b/gx86
For example, net-im/skype would depend on:
dev-libs/libfoo[abi_x86_32]
and that dependency would be valid both for amd64 multilib & x86.
---
gx86/profiles/arch/x86/use.force | 5 +
gx86/profiles/arch/x86/use.mask | 5 +
2 files changed, 10 insertions(+)
diff --git a/gx86/profil
---
gx86/profiles/arch/amd64/make.defaults | 4
gx86/profiles/arch/amd64/no-multilib/make.defaults | 4
gx86/profiles/arch/amd64/no-multilib/use.mask | 4
gx86/profiles/arch/amd64/use.force | 4
gx86/profiles/arch/amd64/use.mask
Fabio Erculiani posted on Sat, 26 Jan 2013 10:34:25 + as excerpted:
> I am starting to think that the real problem is that Gentoo does not
> have ebuilds for building kernels (binary kernels). At that point, it
> would be easy to add USE flags and virtual packages to solve the config
> check p
What I always wondered is why we have ebuilds for every kind of binary
except for kernels, yet we build official kernels with official
configs for our livecds.
--
Fabio Erculiani
On Sat, Jan 26, 2013 at 5:30 PM, Fabio Erculiani wrote:
> What I always wondered is why we have ebuilds for every kind of binary
> except for kernels, yet we build official kernels with official
> configs for our livecds.
Yup. I don't think the solution is to have a USE flag for every
kernel par
Just to keep everyone updated, ...
> FYI, the new 13.0 profiles are now all available in profiles.desc, for now
> all with status "dev" (i.e. repoman includes them only when you request
> developer profile checking).
>
> This means the procedure below is complete up to and including point 5)
> no
Rich Freeman wrote:
> having a standardized kernel with a few flags probably isn't a bad idea.
That doesn't scale at all. Suggest instead take a .config as input to
the emerge, maybe something like savedconfig for busybox, and add
shortcuts for common options.
That way, the same mechanism can be
On Sat, Jan 26, 2013 at 7:31 PM, Peter Stuge wrote:
> Rich Freeman wrote:
>> having a standardized kernel with a few flags probably isn't a bad idea.
>
> That doesn't scale at all. Suggest instead take a .config as input to
> the emerge, maybe something like savedconfig for busybox, and add
> shor
# Tim Harder (27 Jan 2013)
# Masked due to deprecated API, use dev-python/PyGithub instead
# Removal in 30 days
dev-python/github2
pgpjD6sKJpimi.pgp
Description: PGP signature
34 matches
Mail list logo
