On Saturday 27 August 2005 03:38 pm, Martin Schlemmer wrote:
> On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote:
> > On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote:
> > > Which reminds me .. anybody going to scream if I update elibtoolize()
> > > to be able to check if it was al
Hi,
the kernel team has announced this already some time ago, but there are still
some ebuilds in the tree using kernel-mod.eclass in there latest version:
sci-misc/comedi/comedi-0.7.68.ebuild:
herd: no-herd
dev: caleb
media-video/mplayer/mplayer-1.0_pre7.ebuild:
herd: video
net-firewa
On Sat, 2005-08-27 at 15:11 -0400, Mike Frysinger wrote:
> On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote:
> > On Sat, 2005-08-27 at 14:37 -0400, Mike Frysinger wrote:
> > > On Saturday 27 August 2005 08:00 am, Diego 'Flameeyes' Pettenò wrote:
> > > > eautoreconf() {
> > > > lo
On Saturday 27 August 2005 02:58 pm, Martin Schlemmer wrote:
> On Sat, 2005-08-27 at 14:37 -0400, Mike Frysinger wrote:
> > On Saturday 27 August 2005 08:00 am, Diego 'Flameeyes' Pettenò wrote:
> > > eautoreconf() {
> > > local aclocal_opts
> > >
> > > [[ -n ${M4DIR} ]] && aclocal_o
On Sat, 2005-08-27 at 14:37 -0400, Mike Frysinger wrote:
> On Saturday 27 August 2005 08:00 am, Diego 'Flameeyes' Pettenò wrote:
> > eautoreconf() {
> > local aclocal_opts
> >
> > [[ -n ${M4DIR} ]] && aclocal_opts="-I ${M4DIR}"
> >
> > eaclocal $aclocal_opts
> > eaut
On Saturday 27 August 2005 08:00 am, Diego 'Flameeyes' Pettenò wrote:
> eautoreconf() {
> local aclocal_opts
>
> [[ -n ${M4DIR} ]] && aclocal_opts="-I ${M4DIR}"
>
> eaclocal $aclocal_opts
> eautoconf
> eautoheader
> eautomake
> gnuconfig_updat
On Sat, 2005-08-27 at 17:51 +0200, Maurice van der Pot wrote:
> On Sat, Aug 27, 2005 at 04:24:40PM +0200, Martin Schlemmer wrote:
> > I still think a autoreconf is usually enough, except for cases where
> > that do not work,
>
> And what is "not work" in this case?
> - fails with an error so it's
On Saturday 27 August 2005 18:11, Ciaran McCreesh wrote:
> The circular autothing <-> wrapper dependency will be phased out at
> some point in the future once all auto* deps properly specify versions.
> The aim is to remove the need to install certain obscure auto* slots
> that are becoming rarer a
On Sat, 27 Aug 2005 18:05:19 +0200 "Diego 'Flameeyes' Pettenò"
<[EMAIL PROTECTED]> wrote:
| On Saturday 27 August 2005 17:53, Ciaran McCreesh wrote:
| > I don't like it. It removes the ability to DEPEND (which you spelt
| > wrong, btw) upon the correct auto* version.
| Yeah I know I typoed.
| About
On Saturday 27 August 2005 17:53, Ciaran McCreesh wrote:
> I don't like it. It removes the ability to DEPEND (which you spelt
> wrong, btw) upon the correct auto* version.
Yeah I know I typoed.
About the version.. well you just can't depend upon a specified version
anyway.
When you depend on whate
On Sat, 27 Aug 2005 14:00:06 +0200 "Diego 'Flameeyes' Pettenò"
<[EMAIL PROTECTED]> wrote:
| Attached there's an "autotools" eclass, it's basically a way to give
| more information to the user while providing an epatch-like die
| message. the eauto* calls are directly calls to the original command,
On Sat, Aug 27, 2005 at 04:24:40PM +0200, Martin Schlemmer wrote:
> I still think a autoreconf is usually enough, except for cases where
> that do not work,
And what is "not work" in this case?
- fails with an error so it's impossible to miss as a dev, or
- fails to do things properly, causing s
On Sat, 2005-08-27 at 16:24 +0200, Martin Schlemmer wrote:
> On Sat, 2005-08-27 at 14:00 +0200, Diego 'Flameeyes' Pettenò wrote:
> > I was wondering last night with az about the handling of autotools.
> > They not always require to be re-run by scratch, but when you have to run
> > aclocal you usu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bjarke Istrup Pedersen wrote:
> I must say I have been wondering about this for a while too.
> A solution might be add some sort of flag to packages that are binary,
> and then let portage install libstdc++ the first time you install this
> kind of pac
maillog: 27/08/2005-02:46:03(+0200): Bjarke Istrup Pedersen types
> I must say I have been wondering about this for a while too.
> A solution might be add some sort of flag to packages that are binary,
> and then let portage install libstdc++ the first time you install this
> kind of package.
You
On Sat, 2005-08-27 at 14:00 +0200, Diego 'Flameeyes' Pettenò wrote:
> I was wondering last night with az about the handling of autotools.
> They not always require to be re-run by scratch, but when you have to run
> aclocal you usually have to run everything after that.
> Every ebuild handles them
On Sat, Aug 27, 2005 at 03:29:32PM +0200, Kevin F. Quinn wrote:
> On 27/8/2005 13:34:15, Brian Harring ([EMAIL PROTECTED]) wrote:
>
> > Rough filtering stack-
> > profiles/package.mask
> > /etc/make.profile/package.mask (incremental through subprofiles)
> > users package.mask, and users package.un
On 27/8/2005 13:34:15, Brian Harring ([EMAIL PROTECTED]) wrote:
> Rough filtering stack-
> profiles/package.mask
> /etc/make.profile/package.mask (incremental through subprofiles)
> users package.mask, and users package.unmask
>
> Ordered it in that fashion to show that it's effectively repositor
I was wondering last night with az about the handling of autotools.
They not always require to be re-run by scratch, but when you have to run
aclocal you usually have to run everything after that.
Every ebuild handles them in a different way, some ebuilds run them in a &&
list and then || die, ot
On Sat, Aug 27, 2005 at 06:38:36AM -0500, Brian Harring wrote:
> You're masking occurs within the profile itself, not globally.
> Global masking usually is for introduction of new ebuilds that need
> testing and shouldn't be hit by normal arch testers (portage early
> release candidates for examp
On Sat, Aug 27, 2005 at 01:32:33PM +0200, Fernando J. Pereda wrote:
> On Sat, Aug 27, 2005 at 01:17:50PM +0200, Kevin F. Quinn wrote:
> > Not sure about package.mask. I thought that was part of the profile,
> > as different profiles might package.mask separately. I know I use it
> > in /etc/profi
On Sat, Aug 27, 2005 at 01:17:50PM +0200, Kevin F. Quinn wrote:
> On 27/8/2005 10:42:25, Brian Harring ([EMAIL PROTECTED]) wrote:
> > Hola all.
> >
> > Straight to the point, I'm proposing that the following files-
> > arch.list
> > categories
> > use.desc
> > use.local.desc
> > package.mask
> > u
On Sat, Aug 27, 2005 at 01:17:50PM +0200, Kevin F. Quinn wrote:
> On 27/8/2005 10:42:25, Brian Harring ([EMAIL PROTECTED]) wrote:
> > Hola all.
> >
> > Straight to the point, I'm proposing that the following files-
> > arch.list
> > categories
> > use.desc
> > use.local.desc
> > package.mask
> > u
On 27/8/2005 10:42:25, Brian Harring ([EMAIL PROTECTED]) wrote:
> Hola all.
>
> Straight to the point, I'm proposing that the following files-
> arch.list
> categories
> use.desc
> use.local.desc
> package.mask
> updates
>
> be moved out of the profiles directory in the tree
Not sure about packa
Note, sending to dev only, not cc'ing core; the inital -core post was
to make sure those who aren't watching dev ml see the email (annoying,
but it's an old habit I've yet to kick despite needing to).
On Sat, Aug 27, 2005 at 04:48:26AM -0500, Donnie Berkholz wrote:
> Brian Harring wrote:
> >I do
Brian Harring wrote:
I don't recall having kde/gtk crap turned on by default when I first
showed up. Maybe I'm missing something; regardless, the defaults
(which should be minimal from my standpoint) are anything but.
I think you recall wrong, then. The default USE flags have been set so
tha
Hola all.
Straight to the point, I'm proposing that the following files-
arch.list
categories
use.desc
use.local.desc
package.mask
updates
be moved out of the profiles directory in the tree, and into the existing
metadata directory personally, due to the fact that the files above are
essentiall
27 matches
Mail list logo
