Re: [gentoo-dev] Lastrite app-pda/*synce*

2010-11-04 Thread Olivier Galibert
On Thu, Nov 04, 2010 at 09:03:13PM +0200, Samuli Suominen wrote:
 # Samuli Suominen (04 Nov 2010)
 # Over 20 open bugs,
 # Bugs assigned to a proxy maintainer without CVS access
 # Every package outdated, bug 340007
 # Removal in 30 days

The bug 340007 you're citing shows that people are working on adding
the next version but are not done yet.  What's the point of this
masking/removal besides fucking up the installation of people who use
the software?


Re: [gentoo-dev] SDLMame maintainer with Gnome setup wanted

2008-07-26 Thread Olivier Galibert
On Sat, Jul 26, 2008 at 03:13:36PM +0200, Luca Barbato wrote:
 Christian Birchinger wrote:
 But no matter how wrong i think it is, i usualy respect the
 upstreams wishes.
 If upstream is wrong I think we should help them...

Upstream thinks it's a bad idea not to give the user any possibility
of changing the font.  Upstream does not want to handle questions
about that if the gentoo ebuild is crippled by default in that aspect.


Re: [gentoo-dev] Re: GLEP 55

2008-06-11 Thread Olivier Galibert
On Wed, Jun 11, 2008 at 04:14:58AM +0100, Ciaran McCreesh wrote:
 On Tue, 10 Jun 2008 19:14:11 +0200
 Olivier Galibert [EMAIL PROTECTED] wrote:
  On Tue, Jun 10, 2008 at 03:02:28PM +0100, Ciaran McCreesh wrote:
   Except that currently, the ebuild file isn't opened for read. So
   it's not in memory at all.
  Why would you need the EAPI before the time when you actually want to
  interpret the contents? 
 You need the EAPI before you use the metadata. But you don't need the
 ebuild to get the metadata in the common case.

The metadata should carry its version indicator too.

-- mailing list

Re: [gentoo-dev] Re: GLEP 55

2008-06-11 Thread Olivier Galibert
On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote:
 !-- EAPI=3 --

*Then* would be the time to change the extension.  As long as the
ebuild is bash-parseable with an appropriate environment, it doesn't
make sense to change the extension because a env-variable set or a
comment are more natural methods.

If/when the format changes to something not parseable by bash, then it
will be time to change the extension.  And then how to mark
(sub-)version will depend on the chosen new format, in case of xml
that would be the dtd information.

I suspect the rejection of the extension change will be there as long
as the fundamental format (bash script) doesn't change.


-- mailing list

Re: [gentoo-dev] Re: GLEP 55

2008-06-10 Thread Olivier Galibert
On Tue, Jun 10, 2008 at 12:01:00PM +0200, Rémi Cardona wrote:
 Ciaran McCreesh a écrit :
 Kills the upgrade path completely. No good.
 Lemme sum this up in layman's terms :
 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to 
 avoid that for various reasons, all 100% valid.

sourcing != reading the first line/n first lines/first block and grepping.

-- mailing list

Re: [gentoo-dev] Re: Concerns about WIPE_TMP change

2008-01-19 Thread Olivier Galibert
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 anything important in
  /tmp - but educating our users before blowing away their data isn't a
  bad thing.  We shouldn't assume our users are idiots, but this is an
  obscure enough piece of admin knowledge that I think that users will be
  impacted by the change.
 Obscure?  It's the directory name (says another with both /tmp and /var/
 tmp on tmpfs).  How much less obscure can you get than announcing it 
 every time the path is referenced or specified?  Who could reasonably 
 argue that tmp doesn't mean tmp?

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.

Frankly, if I'm writing a long email (which mutt stores in /tmp) and a
powerloss makes it gone even if I was saving it from time to time
while I was writing it, I'll get annoyed.  Severely annoyed.

It's just another bug of the FHS that shoule be ignored.

-- mailing list

Re: [gentoo-dev] Smoother moderation scheme? (was: ML changes)

2007-07-13 Thread Olivier Galibert
On Fri, Jul 13, 2007 at 03:46:56PM -0400, Thomas Tuttle wrote:
 Questions?  Comments?

You're going to have a hell of a fun time to answer the question of
how a post is judged good or spam.

[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] ML changes

2007-07-12 Thread Olivier Galibert
On Thu, Jul 12, 2007 at 01:24:32PM -0700, Mike Doty wrote:
 We're voting on this next council meeting so if you have input, now would be
 the time.

Any dev can moderate is an illusion.  Most non-dev messages are
perfectly reasonable ones and I'm pretty sure the smart devs know how
to handle filters when they get bored with the flamefests.  So either
the devs get a message when there is something to be moderated, and
it's going to annoy them to see all these messages twice, or they
don't, and I don't see anybody checking a web site or something on a
regular basis to see if there are messages to let go through.  At
least not long term.

[EMAIL PROTECTED] mailing list

[gentoo-dev] How to help an ebuild move along

2007-06-11 Thread Olivier Galibert
I've had decided to do an ebuild for praat[1] as my first
contribution.  I checked in bugzilla just in case there was one added
recently, and I found out there was one since two years and half[2],
regularly kept up to date even.

So my question is, what could I do to help having it end up in the
official package database?


[1] A speech analysis tool, the reference in the domain.
[EMAIL PROTECTED] mailing list

Re: [gentoo-dev] Re: SCM choices

2007-06-04 Thread Olivier Galibert
On Mon, Jun 04, 2007 at 03:30:37AM +0300, Stratos Psomadakis wrote:
 but i think linus is too biased against other scms...

He is biased against technical choices done in other SCMs, which is
not exactly the main thing.  Specifically, from what I can see, he

- centralization (cvs, svn...)

- file ids (cvs, svn, hg, ...)

- hiding what is really going on on the pretext that it's easier
  (lots of interfaces out there, or people who want commit -a as
  default for git)

- lack of ways to be sure we're talking about the same code in the end

- anything slow (almost every other scm out there)

I very probably have missed some.  It's obvious why git doesn't have
properties Linus hates.

[EMAIL PROTECTED] mailing list