On Fri, 23 Sep 2005 09:47:17 +0900
Georgi Georgiev <[EMAIL PROTECTED]> wrote:
> 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 unm
Jason Stubbs posted <[EMAIL PROTECTED]>, excerpted
below, on Fri, 23 Sep 2005 10:19:14 +0900:
> 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 s
maillog: 22/09/2005-22:48:06(-0700): Duncan types
> Diego 'Flameeyes' Pettenò posted
> <[EMAIL PROTECTED]>, excerpted below,
> on Thu, 22 Sep 2005 12:52:45 +0200:
>
> > On Thursday 22 September 2005 12:30, Aaron Walker wrote:
>
> >> Everyone give Chris a warm welcome.
> > Hi Chris and welcome :)
Diego 'Flameeyes' Pettenò posted
<[EMAIL PROTECTED]>, excerpted below,
on Thu, 22 Sep 2005 12:52:45 +0200:
> On Thursday 22 September 2005 12:30, Aaron Walker wrote:
>> Everyone give Chris a warm welcome.
> Hi Chris and welcome :)
>
> Btw... you're clee or it's just an omonimity (or whatever is
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 s
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 i
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
On Fri, Sep 23, 2005 at 09:47:17AM +0900, Georgi Georgiev wrote:
> 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
> pass
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 lo
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.
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.
Would the x86 team prefer it if
Since the acceptance of GLEP 40 and the creation of the x86 team, any
package maintainers that are not on the x86 team must make arrangements
with the team before marking their packages stable on x86. This is
stated right in the GLEP. We'll likely defer to the maintainers
judgement in the case th
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 som
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
us
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 much
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 much everything since I *re
Hi, all.
app-admin/gwcc has security issues, and has been unmaintained upstream
for 3 years. The Gnome herd is no longer interested in maintaining it.
I've masked it, and will remove it in a couple of weeks, if no one steps
forward to maintain it.
Daniel
--
gentoo-dev@gentoo.org mailing list
On Thu, Sep 22, 2005 at 01:30:00PM -0400, Chris Gianelloni wrote:
> 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
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 kee
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 n
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 idea, but it's hideously buggy. vim7 supports native
> spellchecking which actually w
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 ha
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
> > fr
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
Cory Visi <[EMAIL PROTECTED]> wrote:
> I think this is a good idea. We just need to call it something that
> doesn't cause endless confusion.
Sticking something like a "non-complete version" sticker on it would
help.
> On a related note, keeping with the philosophy here, I would say that
> Oper
-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, 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
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 im
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 r
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 m
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 ba
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 e
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 fi
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
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
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 packa
-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
-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
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
On Wed, Sep 21, 2005 at 05:47:09PM +0100, John Mylchreest wrote:
> First of all, falling back on `uname -r` isn't going to happen for
> several reasons. I can understand for some why this might seem sensible
> (what happens if you remove your kernel sources for example). But the
> fact remains that
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 sti
-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 hav
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 sa
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 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 ar
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
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".
--
47 matches
Mail list logo
