[gentoo-dev] Allow upstream tags in metadata.xml

[Marcelo Góes]

Fellow Gentooers,

Here is a draft of an enhancement proposal that should allow upstream
information to be included in metadata.xml:

http://dev.gentoo.org/~vanquirius/glep-0099.txt

It is authored by ciaranm and me (vanquirius).
Please comment :-).

Cheers,
Marcelo

--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Allow upstream tags in metadata.xml

[Marcelo Góes]

On 12/27/05, John Myers <[EMAIL PROTECTED]> wrote:
> What if upstream is more than one person, but less than an organization? What
> if there is more than one upstream such as for gentoo-sources, where the
> maintainer of each of the patchsets could be considered an upstream?

I don't see a problem with having multiple "name" and "email" fields.
Perhaps there could be an additional "description" tag to discriminate
what each person is responsible for.

> if this is to be subject to automated processing, shouldn't there be a
> registry of valid "type" values maintaining a definition of what the value of
> the element corresponds to for each type?

Yes. Thus far, I have in mind freshmeat, sourceforge and cpan, but
other types can be added later.

On 12/27/05, Grobian <[EMAIL PROTECTED]> wrote:
> The bugs-to tag can hold either an email address or URL.  Not a big
> issue, but why not make it an URI, such that an email address is written
> as "mailto:[EMAIL PROTECTED]"?  Using an URI gives a nice specified format
> (already including the http(s) which you require) and should go with
> regular URI parsers.

Sounds good enough.

> Given the URI thing, maybe it can be useful to define the changelog tag
> to have an URI as well, since some upstreams ship the changelog with the
> sources and don't put them on the web.  In such case you might want to
> use a "file://" URI to point to the file on disk when installed?  I
> realise this is tricky.

Hmmm... I'm not sure about this one. Not only is it tricky, but the
whole point of this GLEP is to facilitate the finding of online
up-to-date information. If there is no online changelog, I think it
may be better just to ommit this field.

> What I wanted to say, where is
> the logic stored on how to make this id into some resource?  And if you
> store that logic somewhere, why not in the XML structure?  Any reason to
> use an id, and not for instance an URI to the remote 'developers'
> homepage/resource?

Yes, there is a logic. I think it is easier to maintain an external
list, such as we do with "thirdpartymirrors". The point of listing
alternative resources is that they may include features not provided
by upstream itself. For example, an announce list that lets one know
when a new version has been released.

On 12/27/05, Paul de Vrieze <[EMAIL PROTECTED]> wrote:
> What is the reason for having an upstream tag?

Aggregate useful upstream information in one place.

> Wouldn't it be easier to just name the tags properly.

How?

> And what about just using a general attribute tag
> like 

It's not bad, but isn't it better to have it in the structured way we
suggest? It's graphically easier to read/write.

Cheers! I'll be back the first week of January :-).
Marcelo

--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Last rites for media-libs/xpm

[Marcelo Góes]

Hello,

media-libs/xpm is currently just a dummy ebuild that depends on
virtual/x11. All ebuilds in the tree have already been adapted to
depend directly on virtual/x11 and/or modular X equivalents. Thus I'm
scheduling it for removal within a week or so if nobody complains.

Cheers,
Marcelo

--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Last rites for media-libs/xpm

[Marcelo Góes]

On 1/22/06, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> On Sunday 22 January 2006 09:48, Marcelo Góes wrote:
> > media-libs/xpm is currently just a dummy ebuild that depends on
> > virtual/x11. All ebuilds in the tree have already been adapted to
> > depend directly on virtual/x11 and/or modular X equivalents. Thus I'm
> > scheduling it for removal within a week or so if nobody complains.
>
> you cant remove the package until you update the things depending on it
>
> xpm is no longer a dummy package, it's x11-libs/libXpm now in modular X terms
> -mike

Like I said, this has already been taken care of. There are no more
packages that still depend on media-libs/xpm. Instead, they depend
either on virtual/x11 or x11-libs/libXpm and whatever else your
scripts show...
--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Last rites for media-libs/xpm

[Marcelo Góes]

On 1/22/06, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> i have no scripts
> -mike

Sorry, I was tripping. The scripts are spyderous's.

Marcelo
--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unmasking modular X

[Marcelo Góes]

On 1/24/06, Carlos Silva <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-01-24 at 13:38 +0100, Christian Heim wrote:
> > On Tuesday 24 January 2006 09:34, RH wrote:
> > > On Mon, Jan 23, 2006 at 11:06:12PM -0800, Donnie Berkholz wrote:
> > > > A) You have commit access to gentoo-x86, AND
> > > > B) you're comfortable with the porting process OR are adept with ebuilds
> > > > and would like to help
> > >
> > > I'm up for being a volunteer here.
> >
> > Same for me.
> >
>
> Add me there

volunteer++;

> --
> Carlos "r3pek" Silva
> Gentoo Developer (kernel/amd64/mobile-phone)
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux)
>
> iD8DBQBD1iMmttk+BQds59QRAvnVAKCH/SahwwKfVxeTU95fULRg8SFm1wCfTlq3
> 0Q/HwMiAQdF2DaCe/X8HnR4=
> =SXF6
> -END PGP SIGNATURE-
>
>
>


--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] package.mask cleanups

[Marcelo Góes]

On 1/24/06, Alec Warner <[EMAIL PROTECTED]> wrote:
> Please have a look and see if any of the packages are yours.  Entries in
>  package.mask should have a corresponding ebuild in the tree somewhere.
>  I'd like to see the number of entries chopped by a fair margin.

I masked prelude stuff so that it wouldn't be a moving target and we
can stabilize a 0.9.x release. For example, even though
>dev-libs/libprelude-0.9.3 does not match anything in the tree, if
somebody bumps it to 0.9.4 ~arch users will still get 0.9.3. This
should only go off after a 0.9.x release is stabilized or if a
security bug comes up. Just FYI.

Marcelo

--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: bootstrapping since gcc 3.4 is stable

[Marcelo Góes]

On 1/26/06, Mikey <[EMAIL PROTECTED]> wrote:
> If you actually downloaded a "pristine" stage1 or a stage3 tarball you might
> notice that there are, in fact, packages already present in world.  Glibc,
> gettext, nano, gzip, and linux-headers.

Like it was already said, those are parts of system.
Have we any need of extending this flamewar?

--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Re: bootstrapping since gcc 3.4 is stable

[Marcelo Góes]

On 1/26/06, Mikey <[EMAIL PROTECTED]> wrote:

> Your point?  My point was that they don't belong there.

Are you saying glibc should not be in system?
Do you know what system is for?

--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Polish translator shadoww (Damian Kuras)

[Marcelo Góes]

On 1/27/06, Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> wrote:
> I think he meant that we shouldn't welcome him with "use repoman || die" as
> that's something useful only for ebuild developers :P

Ah, but instead of repoman there is repodoc!

http://dev.gentoo.org/~yoswink/repodoc/
http://dev.gentoo.org/~vanquirius/repodoc.html (ripped off ^)

Welcome aboard Damian!
--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: RFC: emerge snapshots

[Marcelo Góes]

On 1/27/06, Duncan <[EMAIL PROTECTED]> wrote:
> attempt at adding a bit of humor to what otherwise might get too dry
> and technical to be tolerable.

This list _is_ for technical discussion. Please keep it that way.
Thanks.
--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: tcsh vs. csh, removal of the latter

[Marcelo Góes]

On 1/28/06, Grobian <[EMAIL PROTECTED]> wrote:

> The question here now actually is: "is csh worth the hassle, or not?"
> My opinion is that it is not.

csh_is_not_worth_it++;
It is causing trouble and not adding functionality. Unless there are
cases where tcsh is not backwards compatible, I say it is a good
riddance.

--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Make logrotate a global USE flag?

[Marcelo Góes]

It seems there are some ebuilds with a logrotate USE flag:

use.local.desc:34:app-backup/bacula:logrotate - Install support files
for logrotate
use.local.desc:550:mail-filter/dspam:logrotate - Install support files
for logrotate
use.local.desc:899:net-ftp/vsftpd:logrotate - Use logrotate for rotating logs
use.local.desc:1011:net-misc/ntp:logrotate - Install support files for logrotate
use.local.desc:1079:net-proxy/squid:logrotate - Use logrotate for rotating logs
use.local.desc:1284:sys-power/acpid:logrotate - Use logrotate for rotating logs
use.local.desc:1290:sys-power/hibernate-script:logrotate - Use
logrotate for rotating logs
use.local.desc:1303:www-apps/dspam-web:logrotate - Build logrotate
support for dspam

Perhaps it should be a global USE flag?

Marcelo

--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Make logrotate a global USE flag?

[Marcelo Góes]

On 1/28/06, Francesco Riosa <[EMAIL PROTECTED]> wrote:
> Doug Goldstein wrote:
> > How about the packages that don't even ask and just install logrotate
> > stuff? Like Apache, lighttpd, and mysql?
> >
>
> they should use it, MySQL will be updated when Marcelo make "logrotate"
> uf global

Indeed, logrotate functionality should be optional. Ebuilds that
install logrotate stuff without asking should be updated to use the
logrotate USE flag.

I'm making it a global USE flag if nobody complains.

--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Make logrotate a global USE flag?

[Marcelo Góes]

Reposting since I don't think my last e-mail got through...

On 1/29/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> People who don't want it can set INSTALL_MASK. It should be installed by
> default and not switchable with a USE flag.

If INSTALL_MASK is the correct way to prevent logrotate stuff from
being installed, then those 8 ebuilds I mentioned earlier should drop
the USE flag and install it by default. That's probably easier to fix,
too.

Regardless of how one controls whether logrotate stuff is installed or
not, we should make it one way only. Each package doing its own thing
is confusing.

While at it, we might want to mention it in our documentation, too
(cron-guide.xml and/or hb-install-tools.xml perhaps?). I don't
remember reading anything about this, and neither does grep/Google.

Marcelo

--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Find apps not ported to modular X

[Marcelo Góes]

Works for me.

On 2/3/06, Jason Wever <[EMAIL PROTECTED]> wrote:
> On Thu, 02 Feb 2006 13:39:15 -0800
> Donnie Berkholz <[EMAIL PROTECTED]> wrote:
>
> > Latest list:
> > http://dev.gentoo.org/~spyderous/broken_modular/broken_modular_maintainers.txt.20060202
>
> Returns a 404
>
> --
> Jason Wever
> Gentoo/Sparc Team Co-Lead
>
>
>


--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Dev: antarus (Alec Warner)

[Marcelo Góes]

On 2/5/06, Brian Harring <[EMAIL PROTECTED]> wrote:

> I am currently a senior, going after a Computer Science Bachelors
> with a cognate ( minor basically ) in Japanese.
> GO gentoo-jp :)

Yay, nihongo++!
Welcome aboard Alec!

--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Beware DESCRIPTION clobbering

[Marcelo Góes]

On 2/20/06, Michael Cummings <[EMAIL PROTECTED]> wrote:
> 'given' to us) but if you're (NOT ciaranm, general reply) going to add a
> package and then proceed to assign it to a herd, it would be really keen
> if you told the herd, or at least took care of the bugs you generated as
> a result. Maybe there should be a policy or something about not willy
> nilly adding packages to a herd without some sort of exchange. And yes,
> unfortunately we catch these things months, even a year later, then
> scratch our heads on what happened.

I agree. Adding a package to a herd is basically the same as adding
someone as a package maintainer. If one doesn't belong to the target
herd, he/she should drop a line asking first.

Cheers

--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] New Glep 46 Draft: Allow upstream tags in metadata.xml

[Marcelo Góes]

Hello,

I am basically mailing this new draft on behalf of Ciaran, I just ok'd it :-).
Please read and comment.

Cheers,
Marcelo
--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]
GLEP: 46
Title: Allow upstream tags in metadata.xml
Version: $Revision: 1.1 $
Last-Modified: $Date: 2005/12/27 00:26:58 $
Author: Marcelo Goes <[EMAIL PROTECTED]>, Ciaran McCreesh <[EMAIL PROTECTED]>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 26-Dec-2005

Abstract


Tree ``metadata.xml`` files are currently used to specify maintainer and
description information for packages. This GLEP proposes extensions to
``metadata.xml`` to allow storage of information about upstream.

Motivation
==

The range of upstream-related data currently available to developers and
tool authors is currently limited to ``DESCRIPTION`` and ``HOMEPAGE`` in
ebuilds.

There have been several attempts at creating tools that check a
package's versions against Freshmeat to see whether an ebuild version
bump is required. Currently identifying a package's Freshmeat entry is a
matter of guesswork, and not something that can reliably be automated.

Similarly, various scripts exist to check a package's status against a
specialist external data source. One of the authors, for example, has a
shell script hack that tries to determine whether any ``app-vim``
packages need bumping by checking the associated ``vim.org`` script
page. Again, tying packages to external data source entries is not
particulaly straight forward.

Making additional upstream-related data easily available will have other
benefits:

* It will allow systems such as the Packages website to provide more
  useful information to end users.

* It will reduce the time spent by developers trying to find how to
  contact upstream.

Specification
=

``metadata.dtd`` should allow the use of a upstream tag in
``metadata.xml``.  Inside the upstream tag, developers should be able to
add upstream related information.

This GLEP defines the following four tags for ``upstream``:
``maintainer``, ``changelog``, ``bugs-to`` and ``remote-id``, none of
which are mandatory. Future GLEPs may extend this -- tools processing
metadata.xml should ignore unrecognized elements.

``maintainer`` can contain the tags ``name`` and ``email``, indicating
the person or organization responsible for upstream maintainership of
the package.

``name`` should contain a block of text with upstream's name.

``email`` should contain an e-mail address in the format [EMAIL PROTECTED]

``changelog`` should contain a URL prefixed with ``http://`` or
``https://`` where the location of the upstream changelog can be found.

``bugs-to`` should contain a place where bugs can be filed, a URL
prefixed with ``http://`` or ``https://`` or an e-mail address prefixed
with ``mailto:``.

``remote-id`` should specify a type of package identification tracker
and the identification that corresponds to the package in question.
``remote-id`` should make it easier to index information such as its
Freshmeat ID or its CPAN name.

The ``remote-id`` element has a ``type`` attribute, which is a string
identifying the type of upstream source. Examples are ``freshmeat``, in
which case the element content should be the Freshmeat ID or ``vim``, in
which case the element content should be the ``vim.org`` script
identifier. This GLEP does not specify a complete list of legal values
for ``type`` -- developers should email the ``gentoo-dev`` mailing list
before using a new ``type`` value.

For example, a ``metadata.xml`` upstream snippet may look like::



Foo Bar
[EMAIL PROTECTED]

http://foo.bar/changelog.txt
https://bugs.foo.bar
12345
foobar



Backwards Compatibility
===

No changes are necessary to existing ``metadata.xml`` files. Information
in the new tags is not be mandatory. Any sane tool that currently
handles ``metadata.xml`` files will simply ignore unrecognised elements.

Copyright
=

This document has been placed in the public domain.

.. vim: set ft=glep tw=72 :

Re: [gentoo-dev] Re: New Glep 46 Draft: Allow upstream tags in metadata.xml

[Marcelo Góes]

On 3/12/06, R Hill <[EMAIL PROTECTED]> wrote:
> i think a 'status' tag might also be handy to indicate if the package has an
> active upstream or not.  either a text field or a predetermined set of
> possibilities ("active"/"inactive").

active/inactive sounds good enough for me, as long as people don't
start tagging upstream as inactive if they do not reply within the
hour...

> multiple maintainer tags allowed?

Sure, why not? That is how it is done with Gentoo maintainers in
metadata.xml already, AFAIK.

Cheers
--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [last rites] media-gfx/sodipodi

[Marcelo Góes]

On 4/2/06, Carsten Lohrke <[EMAIL PROTECTED]> wrote:
> This is not the case. At least unless the user actively looks at package.mask.
> Since Portage doesn't provide the information, this point is void. And even
> if - four weeks are a too long, imho.

I still do not understand what the rush is with removing a package.
Readding a package if necessary will be much more troublesome than
just keeping it masked for a month. I believe this is the general
consensus on the subject.

Marcelo
--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Developer: bbj

[Marcelo Góes]

Welcome!

brazilian_conspiracy++;
Ok, there may not be a lot of us out there, but it's a start!

Cheers,
Marcelo

On 4/4/06, Danny van Dyk <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> [Another late one. You know already, I'm a slacker]
>
> Please help me to welcome Benigno Batista Júnior aka bbj, the latest addition
> to the growing population of the Gentoo/ALT Project.
>
> bbj is located somewhere between Sao Paulo, Rio de Janeiro and Minas Gerais
> (Related to Minas Tirith? ;-)). His current work is a research job at the
> Federal University of Itajubá where he tries to build Cylons^H^H^H neural
> networks. At least this is more exciting than his brother's job who's a math
> professor.
>
> bbj, welcome aboard!
>
> Danny
> --
> Danny van Dyk <[EMAIL PROTECTED]>
> Gentoo/AMD64 Project, Gentoo Scientific Project
>
> --
> gentoo-dev@gentoo.org mailing list
>
>


--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] net-wireless/aircrack users: please migrate to aircrack-ng

[Marcelo Góes]

Hello,

As some may have noticed, net-wireless/aircrack's upstream vanished a
few months ago. However, a new project named aircrack-ng [1] should
take over where aircrack left.

An ebuild for aircrack-ng-0.4 [2] is now in Portage as
net-wireless/aircrack-ng. Please test and migrate to aircrack-ng if
possible.

I have the intention of masking net-wireless/aircrack as soon as an
aircrack-ng release can be made stable and removing it from Portage
one month after that.

[1]: http://www.aircrack-ng.org
[2]: http://bugs.gentoo.org/show_bug.cgi?id=127210

Cheers,
Marcelo
--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Ati driver

[Marcelo Góes]

On 4/21/06, Francesco Riosa <[EMAIL PROTECTED]> wrote:
> Complimenti, ottimo atteggiamento, hai meno di 10 anni vero ?
> Allora forse devi ancora imparare che:
> a) offendere qualcuno di un gruppo quando si fa una richiesta 'e
> perlomeno stupido.
> b) offenderlo in italiano ti fara' solo odiare dagli altri italiani che
> leggono questa lista, perche ci vergognamo di te.
> c) la domanda che hai posto veramente non ha senso qui, stai chiedendo
> aiuto per un problema di installazione, non per lo sviluppo di gentoo.
> trovati un altro posto dove possano rispondere alle tue domande, sui
> forum di gentoo oppure in quei tre quarti di palazzina che hai menzionato.

Congratulations, great attitude, you are not even 10, are you?
Maybe you should still learn that:
a) to offend anyone when you are asking a question is at the very least stupid.
b) to do so in Italian will only bring hate from the other Italians
who read this list, because it is shameful.
c) the question you asked really makes no sense here, you are asking
about an installation issue, not about Gentoo development. Try posting
in a place where people can reply to your questions, like the Gentoo
Forums or in that whore house [is this correct?] that you mentioned.

>From now on let us please resist the temptation of replying...? :-)

Marcelo
--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] net-analyzer/acid users: please migrate to net-analyzer/base

[Marcelo Góes]

Hello there,

net-analyzer/base is a web front-end for the net-analyzer/snort IDS.
It is actively maintained and based on net-analyzer/acid, whose last
release is from 2003. For this reason, migration from ACID to BASE is
recommended.

There is a guide [0] in the forums that you may find useful.
There is one bug [1] related to ACID and old php ebuilds, but
acid-0.9.6_beta23-r1.ebuild should work ok nonetheless, in case you
want to try it.

I just added net-analyzer/acid to package.mask and I intend to remove
it in a month or so if nobody complains.

Cheers,
Marcelo

[0]: http://forums.gentoo.org/viewtopic-t-399801.html
[1]: http://bugs.gentoo.org/show_bug.cgi?id=130980

--
Marcelo Góes
[EMAIL PROTECTED]
[EMAIL PROTECTED]

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] A Gentle Reminder

[Marcelo Góes]

Both sides have valid points:

1) we should remove vulnerable cruft from the tree
2) we should not break dependencies for any arch, regardless of their
response time

I believe some communication adjustments could avoid unnecessary conflict.

If a package cannot be removed because a newer version must stabilized
first in $arch,
use something like this:

"$arch,
Please stabilize package X, for earlier versions have security
vulnerabilities. For more information, see GLSA-."

When (and only then) there are no impediments, use something like this:

"$maintainer,
Please remove versions Y and earlier of package X, for they have
security vulnerabilities. All architectures already have a newer
version stable and will not be affected. For more information, see
GLSA-."

Let us not get at each others throats over this, we are better than that!

Cheers,
Marcelo

On 2/11/07, Jakub Moc <[EMAIL PROTECTED]> wrote:

Matti Bickel napsal(a):
> How about cc'ing arches, which are affected by this? You still get your
> point across and maybe arches move it up their priority list if they see
> a removal "b/c of centuries old vulnerabilities".

I did CC mips, and did write that it needs version x.y.z stabilized
first. Sorry, enough babysitting here, either devs can read or they
shouldn't have commit access.

Period.


--
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)






--
Marcelo Góes
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] doenvd vs. insinto /etc/env.d

[Marcelo Góes]

Hello,

I just did a quick grep of the tree and found 129 ebuilds that
use doenvd and 134 that use insinto /etc/env.d.

As far as I can see, doenvd is more correct because it is
1) cleaner and easier to read
2) more portable (for systems that use something other than
/etc/env.d, for example)

Does it make sense to allow both styles?
Is it worth it to convert everything to doenvd?

Cheers,
Marcelo

--
Marcelo Góes
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Remove app-emulation/plex86

[Marcelo Góes]

Hello there,

plex86 has many issues and no simple solution to all of them. Considering the
amount of very old kernel code it has, including the way it deals with devfs,
for example, it does not look like it will be easy to fix.

plex86 has three outstanding bugs at the time of this writing: bug 54526 
, bug
29159  and bug 17388 
. I have the feeling that if anybody 
was going to get them
fixed, they would have done so by now.

qemu should fill plex86's role in the future.

I'll probably remove plex86 from the tree very shortly. If anybody feels
different, you're welcome to reopen plex86 bugs and fix them :-)

Cheers,
Marcelo

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Remove app-emulation/plex86

[Marcelo Góes]

Mike Frysinger wrote:


usually we mask for a while before punting ... easier to unmask than to re-add
-mike
 

It's been masked for a week, but I doubt anyone has been able to compile 
it for much longer than that :-).

Anyway, when I say "remove shortly" I am thinking a couple of weeks.

Cheers,
Marcelo
--
gentoo-dev@gentoo.org mailing list