Hi all,
I've just talked to Christel, who was the public relations [1] lead, and
we've agreed that because of changing priorities and time, I'll take
over her duties as PR lead. If you have any comments about this, please
email our mail alias, [EMAIL PROTECTED]
You may commence blaming me for
On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote:
In my opinion WIPE_TMP should be in the same state
as RC_PARALLEL_STARTUP.
That's a fair point.
Luckily, the all the Gentoo init scripts that all my computers use are
now at the stage where we could easily flick parallel startup on by
Mark Loeser wrote:
Should an elog statement been put into the ebuild...maybe.
I leave that up to the maintainer to decide what is important enough to
be logged, and they clearly thought this wasn't in this case.
I think that this would probably warrant an elog. Sure, anybody who
knows the
Current state: Deferred
Wanted state: Accepted/Implemented (at least by me)
Open questions from last discussion (March 2006):
- Is it possible/should it be possible to have more than one maintainer
entry?
- Is recording an upstream-status (active/inactive) a good idea?
Possibilities:
An
On Jan 19, 2008 2:07 PM, Tiziano Müller [EMAIL PROTECTED] wrote:
Current state: Deferred
Wanted state: Accepted/Implemented (at least by me)
The GLEP should be updated. Motivation section does not seem to
justify the changes. IMO Meatoo [1] (and its hipothetical rewrite
using Doapspace [2])
Tiziano Müller [EMAIL PROTECTED] said:
Current state: Deferred
Wanted state: Accepted/Implemented (at least by me)
Yea, this sounds like a good thing from reading over the GLEP, unless
I'm missing some glaring problems with it.
Open questions from last discussion (March 2006):
- Is it
Tiziano Müller wrote:
Current state: Deferred
Wanted state: Accepted/Implemented (at least by me)
Open questions from last discussion (March 2006):
- Is it possible/should it be possible to have more than one maintainer
entry?
Yes
- Is recording an upstream-status
Santiago M. Mola wrote:
On Jan 19, 2008 2:07 PM, Tiziano Müller [EMAIL PROTECTED] wrote:
Current state: Deferred
Wanted state: Accepted/Implemented (at least by me)
The GLEP should be updated. Motivation section does not seem to
justify the changes. IMO Meatoo [1] (and its hipothetical
Alistair Bush wrote:
Tiziano Müller wrote:
Current state: Deferred
Wanted state: Accepted/Implemented (at least by me)
Open questions from last discussion (March 2006):
- Is it possible/should it be possible to have more than one maintainer
entry?
Yes
- Is recording an
On Jan 19, 2008 4:13 PM, Tiziano Müller [EMAIL PROTECTED] wrote:
Possibilities:
An element: status{active/inactive}/status
Status of what? seeing you have proposed a upstream-status and a
maintainer status. what else is there left to status :P
There will be a maintainer tag within
On Jan 19, 2008 2:07 PM, Tiziano Müller [EMAIL PROTECTED] wrote:
Your oppinion?
Would this be the right time to discuss about moving other variables
to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those
hardly change and if they ever do we can restrict them to specific
versions.
On Jan 19, 2008 4:24 PM, Denis Dupeyron [EMAIL PROTECTED] wrote:
On Jan 19, 2008 2:07 PM, Tiziano Müller [EMAIL PROTECTED] wrote:
Your oppinion?
Would this be the right time to discuss about moving other variables
to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those
hardly
Regards,
Petteri
[EMAIL PROTECTED] ~/proj-en/devrel/quiz $ cvs diff
Index: ebuild-quiz.txt
===
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/devrel/quiz/ebuild-quiz.txt,v
retrieving revision 1.8
diff -u -r1.8 ebuild-quiz.txt
---
Denis Dupeyron wrote:
On Jan 19, 2008 2:07 PM, Tiziano Müller [EMAIL PROTECTED] wrote:
Your oppinion?
Would this be the right time to discuss about moving other variables
to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ? Those
I'd rather like to see it in a new thread since it
# Stefan Schweizer [EMAIL PROTECTED] (19 Jan 2008)
# Project abandoned. Masked for removal, bug 206105
sys-apps/list
--
gentoo-dev@lists.gentoo.org mailing list
Mark Loeser wrote:
Tiziano Müller [EMAIL PROTECTED] said:
Current state: Deferred
Wanted state: Accepted/Implemented (at least by me)
Yea, this sounds like a good thing from reading over the GLEP, unless
I'm missing some glaring problems with it.
Open questions from last discussion
Robin H. Johnson kirjoitti:
On Fri, Jan 18, 2008 at 06:41:44PM +0100, Christian Faulhammer wrote:
2. Trac doesn't scale well enough, as users of the existing overlay
machine have noted performance problems before. Being replaced with
ViewVC and as yet undecided which Wiki application.
Am I
+# Petteri Räty [EMAIL PROTECTED] (19 Jan 2008)
+# Commercial application for which the devs don't have
+# licenses. Lagging behind in versions. If you want to
+# see this maintained contact [EMAIL PROTECTED] for paying
+# us a license. Otherwise in junkyard after 30 days.
+dev-java/jsx
+
Stefan Schweizer wrote:
# Stefan Schweizer [EMAIL PROTECTED] (19 Jan 2008)
# Project abandoned. Masked for removal, bug 206105
sys-apps/list
Phew I thought this meant the gentoo-dev list was masked for removal --
Hey I just woke up, it's funny!!
-- Fieldy
--
gentoo-dev@lists.gentoo.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is random musing based based on perhaps my own problems.
I need a local color.file to see well what I have going on, and
current xorg ignores that. Thus, at every build, there is in
oscolor.c a constant I must change from 1 to 0.
This is
Ferris McCormick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This is random musing based based on perhaps my own problems.
I need a local color.file to see well what I have going on, and
current xorg ignores that. Thus, at every build, there is in
oscolor.c a constant I must
On Sat, Jan 19, 2008 at 05:43:18PM +, Ferris McCormick wrote:
This is random musing based based on perhaps my own problems.
I need a local color.file to see well what I have going on, and
current xorg ignores that. Thus, at every build, there is in
oscolor.c a constant I must change
On Sat, 19 Jan 2008 16:24:53 +0100
Denis Dupeyron [EMAIL PROTECTED] wrote:
On Jan 19, 2008 2:07 PM, Tiziano Müller [EMAIL PROTECTED] wrote:
Your oppinion?
Would this be the right time to discuss about moving other variables
to metadata.xml ? How about HOMEPAGE, DESCRIPTION and LICENSE ?
On Saturday 19 January 2008, Roy Marples wrote:
On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote:
In my opinion WIPE_TMP should be in the same state
as RC_PARALLEL_STARTUP.
That's a fair point.
how ? these two options are not related in the slightest.
-mike
signature.asc
On 1/19/08, Mike Frysinger [EMAIL PROTECTED] wrote:
using https:// to secure your data here is the wrong way to go. if you have a
man-in-the-middle attacking you, they can do a lot more than inject crap into
your syncs, some of which you wouldnt even notice. for the topic at hand,
this topic
On Friday 18 January 2008, Robin H. Johnson wrote:
On Sat, Jan 19, 2008 at 12:26:44AM +0200, Alon Bar-Lev wrote:
On 1/18/08, Mike Frysinger [EMAIL PROTECTED] wrote:
On Thursday 17 January 2008, Robin H. Johnson wrote:
anonvcs.gentoo.org: anoncvs, anonsvn, anongit
- Anonymous SVN is
On 19-01-2008 15:50:09 -0500, Mike Frysinger wrote:
i'm not suggesting you *not* provide the proper svn:// and git:// ones. i'd
always use those myself when possible (as performance is a ton better as ive
seen many times). i'm suggesting we provide both and tell people to use
svn:// and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Mike Frysinger schreef:
On Saturday 19 January 2008, Roy Marples wrote:
On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote:
In my opinion WIPE_TMP should be in the same state
as RC_PARALLEL_STARTUP.
That's a fair point.
how ? these
On Saturday 19 January 2008, Stefan de Konink wrote:
Mike Frysinger schreef:
On Saturday 19 January 2008, Roy Marples wrote:
On Sat, 2008-01-19 at 02:48 +0100, Stefan de Konink wrote:
In my opinion WIPE_TMP should be in the same state
as RC_PARALLEL_STARTUP.
That's a fair point.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Mike Frysinger schreef:
i can add an elog, but the arguments for not turning it on by default are far
from convincing
Please, only do this, and I'll stop about this subject. :)
So something like *beep*beep*beep* /tmp will now by default cleaned
Richard Freeman [EMAIL PROTECTED] posted [EMAIL PROTECTED],
excerpted below, on Sat, 19 Jan 2008 07:55:53 -0500:
I think that this would probably warrant an elog. Sure, anybody who
knows the correct way to admin unix doesn't put anything important in
/tmp - but educating our users before
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Duncan schreef:
Richard Freeman [EMAIL PROTECTED] posted [EMAIL PROTECTED],
excerpted below, on Sat, 19 Jan 2008 07:55:53 -0500:
Obscure? It's the directory name (says another with both /tmp and /var/
tmp on tmpfs).
...very offtopic but how
On Sat, Jan 19, 2008 at 10:18:35PM +, Duncan wrote:
Richard Freeman [EMAIL PROTECTED] posted [EMAIL PROTECTED],
excerpted below, on Sat, 19 Jan 2008 07:55:53 -0500:
I think that this would probably warrant an elog. Sure, anybody who
knows the correct way to admin unix doesn't put
Olivier Galibert wrote:
Tmp has never meant erase at restart, because restarts are often not
predictable. Tmp has sometimes meant things like erased after a
week, or erased when space gets low, but never erased after
restart which is just unusable.
POSIX wrote:
/tmp
A directory made
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Alec Warner schreef:
But who compiles firefox? :)
Probably everyone that noticed that the segmentation faults coming from
the precompiled versions are annoying?
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment:
Stefan de Konink [EMAIL PROTECTED] posted [EMAIL PROTECTED],
excerpted below, on Sun, 20 Jan 2008 00:17:55 +0100:
...very offtopic but how are you all compiling stuff like firefox on a
ram disk. Or is 8GB of ram very cheap suddenly?
Well, tmpfs is swap-backed if necessary. That's one of its
36 matches
Mail list logo
