> In summation, I say hard-enable these:
>
> acl
>
Please don't do this. It would force installation of sys-apps/acl to any user
which I think is not desired by everybody. I'd rather like to see this being
enabled by either the acl or the consolekit USE flag.
Lars Wendler (Polynomial-C)
Gentoo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
> If you feel like reviewing ~140 packages and filing bugs for them, I
> won't stop you. But I'm just going to go and fix the ones that seem
> simple enough to me, and only file bugs for the complex ones.
Ok, I'll do what I can
On Mon, Aug 31, 2009 at 01:00:41AM +0100, Mike Auty wrote:
> > I missed a bit for the config option.
> > If there is NO source of the config data, what do we do?
> > Error out or more warnings?
> Well, if we can't determine whether a config option's set or not, if
> it's not critical (ie, it's ~CHE
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2009-08-30 23h59 UTC.
Removals:
xfce-extra/thunar-archive 2009-08-24 09:19:17 ssuominen
xfce-extra/xfce4-cpu-freq 2009-08-24 09:33:22 ssuominen
xfce-extra/x
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
> Yes, a warning with using /proc/config.gz.
>
> I missed a bit for the config option.
> If there is NO source of the config data, what do we do?
> Error out or more warnings?
Well, if we can't determine whether a config optio
Per my thread on building modules and linux-info, USE=modules will be moving
from being a local USE flag to being a global, AND it will be enabled by
default in the base profile.
Proposed description:
-
Enable building of kernel modules
Existing tree usage:
---
On Mon, Aug 31, 2009 at 12:30:02AM +0100, Mike Auty wrote:
> > Checking a configuration option, for non-module use:
> >
> > 0. (optional) give an env var to make all checks non-fatal.
> > 1. Use existing logic of .config from /usr/src/linux, KERN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
> The existing state is:
> - Force the user to install sources
>
> Our choices are:
> - `uname -r` output.
> - Create an override environment variable for all the checks.
>
> /proc/config.gz comes back here again, in that, we
On Sun, Aug 30, 2009 at 10:58:33PM +0100, Mike Auty wrote:
> Robin H. Johnson wrote:
> > FYI:
> > get_running_version is used in one single ebuild, in the entire tree:
> > sys-fs/evms/evms-2.5.5-r10.ebuild
> > And there it's only for a warning.
> Ok, I was just suggesting that if there was an inten
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
> FYI:
> get_running_version is used in one single ebuild, in the entire tree:
> sys-fs/evms/evms-2.5.5-r10.ebuild
> And there it's only for a warning.
Ok, I was just suggesting that if there was an intention to implement
confi
On Sun, Aug 30, 2009 at 09:21:24PM +0100, Mike Auty wrote:
> [ "${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}" == "$(uname -r)" ] && \
> OUTPUT_DIR="${OUTPUT_DIR:-/lib/modules/${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}${KV_EXTRA}/build}"
This check is inside the get_version call, and is ultimately used t
On Sun, 30 Aug 2009 23:03:42 +0300
Petteri Räty wrote:
> As far as I understand paludis already has the features implemented so
> maybe we could give EAPI 3 some field testing in some overlays to see
> how it works in practice from ebuild writer point of view.
The main issue with that is eclasses
On Sun, 30 Aug 2009 19:06:02 +0200
Mounir Lamouri wrote:
> So I think we should add a new feature in PMS already used in Exherbo
> EAPI, USE flags requirements [1]. That means an ebuild should be able
> to say a USE flag is available only if some other ones are in a
> specific state. Let's take th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
> It does NOT check /proc/config.gz presently. The original logic against
> not checking /proc was that we were targeting the kernel being built,
> but that's moot given the use of `uname -r` in OUTPUT_DIR.
I might be reading t
As many of you know EAPI 3 has been waiting for Portage to implement it
for many months now and I asked zmedico for his estimate on whether it
will be done this year:
19:50 < Betelgeuse> zmedico: Let's put it this way. How likely in
percentages is EAPI 2 this year?
19:50 < Betelgeuse> s/2/3/
19:51
Seeing the debate raised in the udev thread about checking for the
kernel, I'd like to propose that we revise the linux-info.eclass.
linux-info already checks a number of locations:
- KBUILD_OUTPUT,
- KERNEL_DIR, which defaults to /usr/src/linux/
- OUTPUT_DIR, which defaults to /lib/modules/`uname
On Sun, Aug 30, 2009 at 10:36 PM, Mounir Lamouri wrote:
> I think this new feature should help everyones life. We can also imagine
> great features like a minimal USE-flag that will be something like:
> USE_REQUIREMENTS="minimal? ( foo bar )" to set a list of USE flags to
> disable if minimal USE f
On Sun, Aug 30, 2009 at 05:05:05PM +0200, Bruno wrote:
> Is this bound to consolekit or does it rather fall under 'acl' use-flag?
> I guess this includes a kernel requirement (ACL support for tmpfs)
Yes, this would imply CONFIG_TMPFS_POSIX_ACL to actually be used.
> > * usb-db: Provide udev-rules
On Sun, Aug 30, 2009 at 07:06:02PM +0200, Mounir Lamouri wrote:
> Hi,
> However, dying is probably not the best solution too.
> So I think we should add a new feature in PMS already used in Exherbo
> EAPI, USE flags requirements [1]. That means an ebuild should be able to
> say a USE flag is avail
2009-08-30 11:14:53 Petteri Räty napisał(a):
> Arfrever Frehtes Taifersar Arahesis wrote:
> > Python 2.4 is deprecated. There are plans to mask for removal it when
> > remaining packages incompatible with Python 2.5 are fixed.
> > (We will announce masking of Python 2.4 at least 1 month before mask
Hi,
While writing and using some ebuilds, I had to deal with (pseudo) USE
flags requirements. For example, if you install mplayer with
USE="encode" the result will depend on other USE flags: if you have
USE="encode mp3", it will install lame for example. I know a few ebuilds
behave like that in th
On Sun, 30 Aug 2009 12:14:53 +0300
Petteri Räty wrote:
> Arfrever Frehtes Taifersar Arahesis wrote:
> > Python 2.4 is deprecated. There are plans to mask for removal it when
> > remaining packages incompatible with Python 2.5 are fixed.
> > (We will announce masking of Python 2.4 at least 1 month
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
William Hubbs wrote:
> I agree here. The eclass should check /proc/config.gz.
> Also, another reason to use the eclass is it respects KBUILD_OUTPUT if
> it is set.
- From the indenting I can't tell if you wrote this or not, however, we
need to dif
On Sun, Aug 30, 2009 at 08:16:47PM +0530, Nirbheek Chauhan wrote:
> On Sun, Aug 30, 2009 at 7:41 PM, Matthias Schwarzott wrote:
> > Hi there!
> >
> > The new udev-145 and newer have some new kernel requirements. How should the
> > ebuild verify they are met?
> > Some possible ways:
> > 1. Check con
Arun Raghavan posted on Sun, 30 Aug 2009 19:54:47 +0530 as excerpted:
> 2009/8/30 Matthias Schwarzott :
>> Hi there!
>>
>> The new udev-145 and newer have some new kernel requirements. How
>> should the ebuild verify they are met?
>> Some possible ways:
>> 1. Check config under /usr/src/linux
>> 2
On Sun, 30 August 2009 Matthias Schwarzott wrote:
> The new udev-145 and newer have some new kernel requirements. How
> should the ebuild verify they are met?
> Some possible ways:
> 1. Check config under /usr/src/linux
/usr/src/linux is not the best place to look at...
Checks should rather be d
On Sun, Aug 30, 2009 at 7:41 PM, Matthias Schwarzott wrote:
> Hi there!
>
> The new udev-145 and newer have some new kernel requirements. How should the
> ebuild verify they are met?
> Some possible ways:
> 1. Check config under /usr/src/linux
> 2. Check /proc/config.gz
> 3. Print message for user
2009/8/30 Matthias Schwarzott :
> Hi there!
>
> The new udev-145 and newer have some new kernel requirements. How should the
> ebuild verify they are met?
> Some possible ways:
> 1. Check config under /usr/src/linux
> 2. Check /proc/config.gz
> 3. Print message for user in pkg_postinst
All of the
Hi there!
The new udev-145 and newer have some new kernel requirements. How should the
ebuild verify they are met?
Some possible ways:
1. Check config under /usr/src/linux
2. Check /proc/config.gz
3. Print message for user in pkg_postinst
Second point: udev-145 bundles a lot of new extras, but
# Diego E. Pettenò (30 Aug 2009)
# on behalf of QA team
#
# Old version of synce framework; 0.13 and 0.14 are in the
# tree and don't need these packages. synce-rra was just
# fixed after almost an year (at least) of build failure.
#
# Removal on 2009-10-29
# Diego E. Pettenò (30 Aug 2009)
# on behalf of QA team
#
# Unmaintained upstream, unneeded in tree, collides with
# dev-libs/mini-xml (bug #247405) which is actually used.
#
# Removal on 2009-10-29
dev-cpp/libmxmlplus
Arfrever Frehtes Taifersar Arahesis wrote:
> Python 2.4 is deprecated. There are plans to mask for removal it when
> remaining packages incompatible with Python 2.5 are fixed.
> (We will announce masking of Python 2.4 at least 1 month before masking it.)
>
> Please don't add new packages to the tr
32 matches
Mail list logo
