Marius Mauch wrote:
My other concern is that
there is no clear criteria for commercial packages, e.g. are sun-jdk /
other fetch restricted packages commercial?
+1
I think the world isn't black and white and we might find things in the
grey area between commercial and non-commercial.
--
Koon
On Wednesday 21 September 2005 19:52, Chris Gianelloni wrote:
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
On Wednesday 21 September 2005 23:17, Jan Kundrát wrote:
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...
One of the drawbacks of DTD's. In general schema's are better
But how?
If I do a du -hc /usr/lib/lib*.a | tail -n1, it shows 63M. And I
really don't need them.
Why INSTALL_MASK=*.a is bad?
* It would break bash, because the ebuild expects a static libcurses.
* It would not save compile time. I would really appreciate if gtk+
compiled twice as fast.
On Thursday 22 September 2005 11:23, Ervin Németh wrote:
But how?
If I do a du -hc /usr/lib/lib*.a | tail -n1, it shows 63M. And I
really don't need them.
Why INSTALL_MASK=*.a is bad?
* It would break bash, because the ebuild expects a static libcurses.
* It would not save compile
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greeting,
Allow me to introduce our latest addition to the team, Chris Lee aka LabMonkey.
Chris has joined us to help the app-backup herd, mainly to maintain bacula.
He also will probably be helping sparc (once he gets one).
- From his quiz:
I
This seems to be something we should start thinking of soon, very soon..
The original USERLAND variable was originally set to GNU or BSD to indicate
the flavor of the system commands. This dicotomic assignment demonstrated
itself too generic, and we currently have GNU, BSD and Darwin.
This is
On Thursday 22 September 2005 12:30, Aaron Walker wrote:
(for anyone feeling
generous I don't mind a pizza either ;p).
You have to do your homework before (read: install G/FBSD) or you won't get
any pizza :P
Everyone give Chris a warm welcome.
Hi Chris and welcome :) That strange character
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wernfried Haas wrote:
Ok, here's a warm welcome to nelchael and mkay. Would you like fries
with it?
Will You bring salt too? ;)
- --
Krzysiek 'Nelchael' Pawlik
GPG:0xBC51
Always remember you're unique, just like everyone else.
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Elfyn McBratney wrote:
Krzysiek Pawlik (nelchael) is going to help with the influx of
desktop-misc bugs. I'll let Krzysiek introduce himself:
/me prods nelchael
;)
/me pokes beu
/me pokes beu again
/me pokes beu again and again
*cough* ..
On Thursday 22 September 2005 05:23 am, Ervin Németh wrote:
* It would break bash, because the ebuild expects a static libcurses.
well, yes and no ... if static ncurses is unavailable, the bash ebuild will
use the bundled gnutermcap (which sucks hard compared to ncurses)
For automake
On Thu, 2005-09-22 at 00:31 +0200, Marius Mauch wrote:
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
On Wed, 2005-09-21 at 17:55 -0500, Lance Albertson wrote:
Is this just a one-off implementation until GLEP 23 is implemented, or
something that will complement it? Whats going to happen to this data
after GLEP23 gets implemented? I'd hate to see something added simply
because its a quick
On Thu, 2005-09-22 at 10:14 +0200, Thierry Carrez wrote:
Marius Mauch wrote:
My other concern is that
there is no clear criteria for commercial packages, e.g. are sun-jdk /
other fetch restricted packages commercial?
+1
I think the world isn't black and white and we might find things
On Thu, 2005-09-22 at 10:46 +0200, Paul de Vrieze wrote:
On Wednesday 21 September 2005 19:52, Chris Gianelloni wrote:
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
maillog: 22/09/2005-09:28:53(-0400): Chris Gianelloni types
I thought I had made it fairly clear, but I can elaborate.
commercial would be anything that requires a purchase to use. This
could be anything from specific media (such as most games) to a CD key
or license file.
The basic idea
On Fri, 2005-09-23 at 00:37 +0900, Georgi Georgiev wrote:
maillog: 22/09/2005-09:28:53(-0400): Chris Gianelloni types
I thought I had made it fairly clear, but I can elaborate.
commercial would be anything that requires a purchase to use. This
could be anything from specific media (such
Paul de Vrieze wrote:
AFAIK CDATA will be satisfied by one single space as well...
One of the drawbacks of DTD's. In general schema's are better in
specifying an xml format, as they allow restrictions on CDATA, and more
freedom in other areas (like true order independence).
Is there a
On Thu, Sep 22, 2005 at 09:30:20AM -0400, Chris Gianelloni wrote:
On Wed, 2005-09-21 at 17:55 -0500, Lance Albertson wrote:
Is this just a one-off implementation until GLEP 23 is implemented, or
something that will complement it? Whats going to happen to this data
after GLEP23 gets
On Thu, Sep 22, 2005 at 11:54:25AM -0400, Chris Gianelloni wrote:
On Fri, 2005-09-23 at 00:37 +0900, Georgi Georgiev wrote:
maillog: 22/09/2005-09:28:53(-0400): Chris Gianelloni types
I thought I had made it fairly clear, but I can elaborate.
commercial would be anything that requires
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Gianelloni wrote:
| On Fri, 2005-09-23 at 00:37 +0900, Georgi Georgiev wrote:
|So, how do you treat icc? It requires a license key, but you can get the
|key for free after registering. The package does not cost money and does
|not work out of
On Thu, 2005-09-22 at 11:46 -0500, Brian Harring wrote:
Actually, it does have to deal with glep23, and you already stated in
one of you emails (an interim solution *now* since I've not heard
anything from GLEP23 for some time).
This is an interim solution only in that it flags a package as
On Thursday 22 September 2005 18:14, Grobian wrote:
Paul de Vrieze wrote:
AFAIK CDATA will be satisfied by one single space as well...
One of the drawbacks of DTD's. In general schema's are better in
specifying an xml format, as they allow restrictions on CDATA, and more
freedom in
Unless anyone can come up with a good reason not to, I'm seriously
considering masking then removing app-vim/{vimspell,vimirc}.
vimspell is a nice idea, but it's hideously buggy. vim7 supports native
spellchecking which actually works, so development on the various plugin
spelling related tools
On Thu, 22 Sep 2005 21:32:23 +0200 Martin Schlemmer [EMAIL PROTECTED]
wrote:
| On Thu, 2005-09-22 at 20:20 +0100, Ciaran McCreesh wrote:
| Unless anyone can come up with a good reason not to, I'm seriously
| considering masking then removing app-vim/{vimspell,vimirc}.
|
| vimspell is a nice
On Wed, 2005-09-21 at 18:07 -0400, Alec Warner wrote:
-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
Chris Gianelloni wrote:
On Thu, 2005-09-22 at 15:29 -0500, Brian Harring wrote:
Alternatives/better approaches I'd be open to, although I'll admit up
front I think what you're attempting needs to be pkg specific, which
implies DESCRIPTION in the ebuild (to me at least).
Snipping pretty
On Thu, 22 Sep 2005 17:57:16 -0400 warnera6 [EMAIL PROTECTED]
wrote:
| Or just modify the DESCRIPTION field. Doom3 -
| DESCRIPTION = A popular first person shooter. This game requires a
| license key to play. Simple no?
Yick. I'd rather see metadata.xml long descriptions becoming more
useful
Tom Fredrik Blenning Klaussen wrote:
The average gentoo users are not stupid.
Many people would not agree with that statement ;)
come so far as to adjust something beyond the most basic USE flags at
all, you're probably advanced enough to deciphre such a message. (It
would be nice to have
Ciaran McCreesh wrote:
On Thu, 22 Sep 2005 18:36:18 -0400 Mark Loeser [EMAIL PROTECTED]
wrote:
| I'm sending this email because I have seen some packages marked stable
| on x86 without the permission of the x86 team, and would like the
| people who can mark stable for x86 to contact us.
Should pkg_setup() be run in a sandbox?
The current reasons to not have it sandboxed include:
- ebuilds need to add users
- ... (any others?)
So, would it make sense to sandbox pkg_setup() and only unmask the
passwd files needed for adding users? enewuser friends can be made to
unmask those
On Friday 23 September 2005 05:28, Tom Fredrik Blenning Klaussen wrote:
Now as for the USE flag system. It has actually become so big that it's
difficult to use it effectively. I would actually suggest that a two
level system of USE flags could be employed. Something like
wtk/gtk (Windowing
Vim 7 includes a native spellchecker. It uses its own spell file
format which can be created using Myspell *.aff/*.dic files (the same
as for Mozilla and OpenOffice). The spell files are rather large, so
it's not feasible to bundle them with vim unconditionally.
Building a spell file from source
On Friday 23 September 2005 06:09, Chris Gianelloni wrote:
it would be a good idea to give the user some way of knowing that a
package requires some additional purchased (or otherwise obtained)
portion that is not a distfile/tarball.
It would be a good idea, indeed. RESTRICT=purchase or
Well, my aim is mainly perl, python, nautilus, gtk+ modules... As for
kernel modules, i'd rather all gentoo-provided kernel modules are
updated properly without exaustive search (too slow). People who
manually install kernel modules should take care of themselves :)
On 9/22/05, Finn Thain [EMAIL
35 matches
Mail list logo
