On Wednesday 21 September 2005 10:33 am, Henrik Brix Andersen wrote:
> What about the other issue which was brought up? Ebuilds enheriting
> linux-info.eclass requires a configured kernel source? Personally, I
> don't see anything wrong with that, if the above solution is
> implemented (non-fatal c
Chris Gianelloni wrote:
> On Wed, 2005-09-21 at 10:31 -0700, Matthew Marlowe wrote:
>
We could add a license, called "commercial" into the tree. This license
would look like the following.
>>
>>I would definitly support adding "commercial" as a license group as part of
>>GLEP23 implementa
On Wed, 21 Sep 2005 09:51:16 -0400
Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> Basically, we just add "commercial" to LICENSE in the ebuild, and (if
> wanted or necessary) add "check_license
> $licese_required_to_be_accepted" to pkg_setup on the ebuild. While
> this will break completely intera
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Fredrik Blenning Klaussen wrote:
> On Thu, 2005-09-08 at 20:01 +0100, John Mylchreest wrote:
>
>>For the record, there is a bug open for this. (#64009)
>>Personally, I'm not keen on the idea.
>>the only way which we can do this is by detecting whi
On Thu, 2005-09-08 at 20:01 +0100, John Mylchreest wrote:
> For the record, there is a bug open for this. (#64009)
> Personally, I'm not keen on the idea.
> the only way which we can do this is by detecting which arch we are
> installing the sources, for, which immediately means many installs of
>
Chris Gianelloni wrote:
> It should contain text, but I don't think that the dtd requires it.
> Perhaps it should?
AFAIK "CDATA" will be satisfied by one single space as well...
-jkt
--
cd /local/pub && more beer > /dev/mouth
signature.asc
Description: OpenPGP digital signature
I think that it is very good idea.
As a member of Polish PHP Community, I'm going to try to make ebuild's
for Zend Company [1] products. It will resolve my problem with what
license should I enter in ebuild.
[1] http://www.zend.com
Greets
Paul
--
gentoo-dev@gentoo.org mailing list
On Wed, 2005-09-21 at 14:00 -0400, Daniel Ostrow wrote:
> On Wed, 2005-09-21 at 18:54 +0100, José Carlos Cruz Costa wrote:
> > Hi everybody,
> >
> > If it's commercial, the company in question should (and must) allow an
> > ebuild for is product, like what happens with rpms and other packages.
> >
On Wed, 2005-09-21 at 18:54 +0100, José Carlos Cruz Costa wrote:
> If it's commercial, the company in question should (and must) allow an
> ebuild for is product, like what happens with rpms and other packages.
> Adding commercial ebuilds to portage is like tainting the kernel with
> binary drivers
On Wed, 2005-09-21 at 18:54 +0100, José Carlos Cruz Costa wrote:
> Hi everybody,
>
> If it's commercial, the company in question should (and must) allow an
> ebuild for is product, like what happens with rpms and other packages.
> Adding commercial ebuilds to portage is like tainting the kernel wi
On Wed, 2005-09-21 at 18:54 +0100, José Carlos Cruz Costa wrote:
> Hi everybody,
>
> If it's commercial, the company in question should (and must) allow an
> ebuild for is product, like what happens with rpms and other packages.
> Adding commercial ebuilds to portage is like tainting the kernel wi
On Wed, 2005-09-21 at 10:31 -0700, Matthew Marlowe wrote:
> >> We could add a license, called "commercial" into the tree. This license
> >> would look like the following.
>
> I would definitly support adding "commercial" as a license group as part of
> GLEP23 implementation.
This isn't so much t
Hi everybody,If it's commercial, the company in question should (and must) allow an ebuild for is product, like what happens with rpms and other packages. Adding commercial ebuilds to portage is like tainting the kernel with binary drivers.
Maybe a better solution comes with gensync? If companies w
On Wed, 2005-09-21 at 17:47 +0100, John Mylchreest wrote:
> anyways). After much deliberation I feel the actual best way to deal
> with this, is to have an override envvar which will bypass a die, and
> simply warn instead. This will mean that those people who cross-compile
> regularly, or building
>> We could add a license, called "commercial" into the tree. This license
>> would look like the following.
I would definitly support adding "commercial" as a license group as part of
GLEP23 implementation.
As part of adding any new commercial license to the tree, developers would have
to add
On Wed, 2005-09-21 at 12:03 -0400, Chris Gianelloni wrote:
> The current /usr/src/linux method works quite well for releases. The
> only issue we're having is a non-fatal check being fatal, which is going
> to be fixed.
OK, so being the huy who wrote and looks after all this stuff, here is
my 2c
Heya,
I intend to go to along to this and I recommend any Gentoo users/devs
come along for a beer and a chat as well. Good chance to come and ask
questions over an ale :)
-- Forwarded message --
Date: Wed, 21 Sep 2005 16:17:32 GMT
From: Tushar Joshi <[EMAIL PROTECTED]>
To: GLLUG
On Wed, 2005-09-21 at 17:05 +0200, Martin Schlemmer wrote:
> > > The only real argument is that it makes it difficult for people who cross
> > > compile packages for use on other systems only, in which case it might
> > > make
> > > sense for the possibility to override the behaviour.
> >
> > Cro
On Wed, 2005-09-21 at 16:33 +0200, Henrik Brix Andersen wrote:
> What about the other issue which was brought up? Ebuilds enheriting
> linux-info.eclass requires a configured kernel source? Personally, I
> don't see anything wrong with that, if the above solution is
> implemented (non-fatal checks
On Wed, 2005-09-21 at 16:34 +0200, Paul de Vrieze wrote:
> On Wednesday 21 September 2005 16:18, Chris Gianelloni wrote:
> > I think the problem here was that longdescription was in an ebuild, but
> > was empty.
> >
> > Also, packages.gentoo.org doesn't use this data, but rather just the
> > DESCRI
On Wed, 2005-09-21 at 09:26 -0400, Chris Gianelloni wrote:
> On Wed, 2005-09-21 at 14:17 +0100, Daniel Drake wrote:
> > Quoting Georgi Georgiev <[EMAIL PROTECTED]>:
> > > I can only think of a couple of solution:
> > >
> > > - Remove these unnecessary checks completely: Follow the example of all
>
On Wed, 2005-09-21 at 10:27 +0200, Paul de Vrieze wrote:
> On Wednesday 21 September 2005 09:42, Georgi Georgiev wrote:
> >
> > * Determining the location of the kernel source code
> > * Unable to find kernel sources at /usr/src/linux
> > * This package requires Linux sources.
> > * Please make
On Wednesday 21 September 2005 16:18, Chris Gianelloni wrote:
> I think the problem here was that longdescription was in an ebuild, but
> was empty.
>
> Also, packages.gentoo.org doesn't use this data, but rather just the
> DESCRIPTION field in the ebuild, at least for the few that I checked
> that
On Wed, Sep 21, 2005 at 10:22:08AM -0400, Chris Gianelloni wrote:
> I see absolutely no problem with that, so long as it is a warning.
>
> I mean, you can make it beep, pause, display in flashing red lights and
> email [EMAIL PROTECTED] about it for all I care, but it shouldn't *die* on
> somethin
On Wed, 2005-09-21 at 09:07 -0500, Albert Hopkins wrote:
> > Just out of curiosity, what is your project?
> >
> This is for the new packages.gentoo.org.
Cool.
I'd also like to work out some way for us to show that a package is
commercial, either via my "commercial license" (see other thread on
h
On Wed, 2005-09-21 at 16:57 +0300, Alin Nastac wrote:
> Chris Gianelloni wrote:
>
> >CONFIG_PPP is *not* required to build ppp, so it shouldn't be in the
> >ebuild as a requirement.
> >
> >
> >
> I agree with this statement but I also see the warning as a must.
> user should be warned that its k
On Wed, 2005-09-21 at 15:34 +0200, Paul de Vrieze wrote:
> The meaning of the tag is to contain a full description of the package.
> The sense with longdescription is that it is allowed/encouraged to be a
> description that is substantially longer than approprate for the
> DESCRIPTION variable i
On Wed, 2005-09-21 at 09:21 -0400, Chris Gianelloni wrote:
> On Wed, 2005-09-21 at 07:28 -0500, Albert Hopkins wrote:
> > 2. Are metadata.xml files a requirement for categories? There are
> > a few categories that do not have one:
> > * x11-proto
> > * x11-
Chris Gianelloni wrote:
>CONFIG_PPP is *not* required to build ppp, so it shouldn't be in the
>ebuild as a requirement.
>
>
>
I agree with this statement but I also see the warning as a must.
user should be warned that its kernel does not support CONFIG_PPP or,
depending on activefilter flag, CO
I had a nice little discussion with someone today about commercial
software in portage. His basic complaint was that there's no way to
distinguish what software is commercial and what is not. The licenses
are not always apparent in these things. Anyway, I had originally
thought this to be someth
On Wednesday 21 September 2005 15:21, Chris Gianelloni wrote:
> On Wed, 2005-09-21 at 07:28 -0500, Albert Hopkins wrote:
> > 2. Are metadata.xml files a requirement for categories? There
> > are a few categories that do not have one:
> > * x11-proto
> > * x11-apps
On Wed, 2005-09-21 at 14:17 +0100, Daniel Drake wrote:
> Quoting Georgi Georgiev <[EMAIL PROTECTED]>:
> > I can only think of a couple of solution:
> >
> > - Remove these unnecessary checks completely: Follow the example of all
> > other distributions and do not depend on anything kernel-ish for
On Wed, 2005-09-21 at 07:28 -0500, Albert Hopkins wrote:
> 2. Are metadata.xml files a requirement for categories? There are
> a few categories that do not have one:
> * x11-proto
> * x11-apps
> * x11-drivers
They should have one.
> 3.
On Wednesday 21 September 2005 15:11, Chris Gianelloni wrote:
> On Wed, 2005-09-21 at 06:43 -0500, Andrew Gaffney wrote:
> > Paul de Vrieze wrote:
> > > I kindof wonder why it doesn't try the sources of the running
> > > kernel. They are easilly found at "/lib/modules/`uname -v`/build".
> > > Of co
On Wed, 2005-09-21 at 06:43 -0500, Andrew Gaffney wrote:
> Paul de Vrieze wrote:
> > I kindof wonder why it doesn't try the sources of the running kernel. They
> > are easilly found at "/lib/modules/`uname -v`/build". Of course as a
>
> You mean `uname -r` :)
Also, that only works if ppp is a m
Quoting Georgi Georgiev <[EMAIL PROTECTED]>:
> I can only think of a couple of solution:
>
> - Remove these unnecessary checks completely: Follow the example of all
> other distributions and do not depend on anything kernel-ish for such
> packages. A recompilation of the kernel with different o
I'm trying to incorporate into my project the metadata.xml files used in
portage, but I have a few questions:
1. It seems like many of the package metadata.xml files \-escape
"special" characters a la bash. This isn't really necessary in
XML and if there are special character
Paul de Vrieze wrote:
I kindof wonder why it doesn't try the sources of the running kernel. They
are easilly found at "/lib/modules/`uname -v`/build". Of course as a
You mean `uname -r` :)
--
Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/
Gentoo Linux Developer
On Wed, Sep 21, 2005 at 04:42:49PM +0900, Georgi Georgiev wrote:
> The linux-info.eclass is used by a few packages to check for appropriate
> kernel configuration options.
[snip]
This is basically bug #103878 :)
> What do you people think the proper solution is?
I suggest adding a $CONFIG_WARN
Georgi Georgiev wrote:
>I can only think of a couple of solution:
>
>- Remove these unnecessary checks completely: Follow the example of all
> other distributions and do not depend on anything kernel-ish for such
> packages. A recompilation of the kernel with different options can
> easily caus
maillog: 21/09/2005-10:27:21(+0200): Paul de Vrieze types
> On Wednesday 21 September 2005 09:42, Georgi Georgiev wrote:
> >
> > * Determining the location of the kernel source code
> > * Unable to find kernel sources at /usr/src/linux
> > * This package requires Linux sources.
> > * Please mak
On Wednesday 21 September 2005 09:42, Georgi Georgiev wrote:
>
> * Determining the location of the kernel source code
> * Unable to find kernel sources at /usr/src/linux
> * This package requires Linux sources.
> * Please make sure that /usr/src/linux points at your running kernel,
> * (or the
On Wed, 21 Sep 2005 16:42:49 +0900
Georgi Georgiev <[EMAIL PROTECTED]> wrote:
> I can only think of a couple of solution:
>
> - Remove these unnecessary checks completely: Follow the example of
> all other distributions and do not depend on anything kernel-ish for
> such packages. A recompilation
The linux-info.eclass is used by a few packages to check for appropriate
kernel configuration options.
Now, packages that install kernel modules, i.e. packages that inherit
linux-mod.eclass are right to check for those options in pkg_setup and
abort unless these are available. After all, these pac
44 matches
Mail list logo
