Re: [gentoo-dev] Updating the list of non-SPARC herd devs keywording for SPARC

[Marius Mauch]

On Wed, 29 Jun 2005 21:46:31 -0600
Jason Wever <[EMAIL PROTECTED]> wrote:

> Hi All,
> 
> In the past, a few folks that aren't part of the SPARC herd had
> communicated that they had the ability to actually test packages on
> SPARC hardware and been giving the blessing of the SPARC team to
> keyword select packages.

Just for reference: portage and gentoolkit follow the portage
keywording policy instead of the normal one -> tested on one arch,
keyworded on all (as this was recently reconfirmed by all arch
maintainers).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgprWhiphmuSM.pgp
Description: PGP signature

Re: [gentoo-dev] GLEP 38: Status of forum moderators in the Gentoo project

[Marius Mauch]

On Tue, 28 Jun 2005 17:34:14 -0500
Lance Albertson <[EMAIL PROTECTED]> wrote:

> On Wed, 2005-06-29 at 00:20 +0200, Christian Hartmann wrote:
> 
> > To host patches, docs etc. Just like every other devs/staff guy does
> > atm. (Sure. toucan isn't meant to be a download server and we're
> > aware of this fact.)
> 
> Patches to our phpbb should only fall under 2-3 people and means
> moderators != forum admins. And those folks should be closely tied to
> the infra folks. So please tell me again what patches/docs they would
> have as moderators? My vote would be no shell access to moderators, I
> simply don't see the point of adding that into our infra. I do however
> see the need for having an alias for email contact. If they want to do
> more than moderate, thats their will and can take the ebuild quiz for
> that or can discuss that with recruiters.

Well, as long as we use toucan for voting they need shell access (not
now, but when they become foundation members in a year).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpfNp445bCbm.pgp
Description: PGP signature

Re: [gentoo-dev] GLEP 38: Status of forum moderators in the Gentoo project

[Marius Mauch]

On Tue, 28 Jun 2005 12:37:46 +0200 (MEST)
Anders Hellgren <[EMAIL PROTECTED]> wrote:

> > Currently I'd be interested if there are any solid numbers how many
> > global moderators/admins want/don't want to get staff status?
> 
> Let's see, all admins and global mods are in the Global Moderators
> group. To the best of my knowledge the staus is the following.
> 
> Nitro: Not necessary, [1]
> amne: Will take
> BonezTheGoon: Don't know, inactive
> curtis119: Has recently taken it 
> Deathwing00: /me is getting confused by his replies in this thread,
> the main authors of the glep never intended anyone to become Gentoo
> staff without taking the staff quiz.
> Earthwings: Will take
> ian!: Will take
> kallamej: Will take
> klieber: Not necessary, [1]
> Maedhros: Will take
> masseya: Don't know, but he thinks the glep is a really good idea.
> phong: Don't know, inactive
> pilla: Reluctant, but hasn't said he would refuse.
> pjp: Not necessary, [1] 
> plate: Not necessary, [1]
> puggy: Not necessary, [1]
> rac: Not necessary, [1]
> tomk: Not necessary, [1]

So that would be 6 "will take", 2 inactive (should be handled like
retired devs IMO), 8 "not necessary" and 2 more or less unknown. No
"definite against". So after all the whole discussion might be a non-
issue ;)

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpwmk2JVIkut.pgp
Description: PGP signature

Re: [gentoo-dev] GLEP 38: Status of forum moderators in the Gentoo project

[Marius Mauch]

On Mon, 27 Jun 2005 19:09:41 +0200
Haas Wernfried <[EMAIL PROTECTED]> wrote:

> Hi,
> With reference to the recent thread about this GLEP's draft [1]
> we're resurrecting the discussion and would like keep you updated
> on the latest changes:
> 1) The term developer has been dropped and replaced by staff. ;-)
> 2) The GLEP is now listed on the GLEP page as GLEP 38 [2] as an
> official GLEP.
> 3) The moderators guide is available (Curtis already posted that to
> the list, just a reminder to have a look at it as well). [3]
> 
> Now would be a great time for everyone to read it and give us some
> feedback. 

ok, looks like the current hot topic is that not all global moderators/
site admins want/can become staff members for unspecified reasons.

(the GLEP says that everyone wanting to become a staff member has to
take the quiz, so I take that as a given)

Currently I'd be interested if there are any solid numbers how many
global moderators/admins want/don't want to get staff status? 

Marius

PS: I'm ignoring the national forum moderator issue on purpose for now.

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpaL0TegG5Rs.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Questions about licenses

[Marius Mauch]

On Fri, 17 Jun 2005 00:12:30 +0200
Torsten Veller <[EMAIL PROTECTED]> wrote:

> * Patrick Lauer <[EMAIL PROTECTED]>:
> > On Wed, 2005-06-15 at 13:18 +0200, Torsten Veller wrote:
> >
> > > Why do we add a license to the licenses/ dir?
> >
> > Because there should be an easy way to find licenses?
> > And you can do "emerge search foo", then read the license and decide
> > wether you want to install foo.
> > 
> > > And in addition: When should a license be added to licenses/ ?
> >
> > When at least one ebuild uses a license that is not already there?
> 
> Ok, here is a license: 
> I couldn't decide if this one is present already.
> All i have checked are slightly different. Maybe someone knows ;)
> 
> If it is not in licenses/, can someone suggest a name for this one?

Looks like as-is.

> > > There are over 3MB in nearly 500 files. How will those licenses be
> > > classified if ACCEPT_LICENSES (GLEP 23) is implemented?
> > I guess groups ... OSI approved, "free", commercial, ...
> 
> Classification <-> groups, sure.
> But how? How can this be done with 500 files? Who wants to do this?

Personally I'd only make groups: needs user confirmation and doesn't
need user confirmation, as those are the only ones that have a
technical reason (and the former group already needs special treatment).
At most also use external lists of licenses like OSI or FSF, but IMO it
would be a bad idea to provide any set of "free" licenses or use other
vague/ subjective limitations.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgp8gLLyzYhFY.pgp
Description: PGP signature

Re: [gentoo-dev] Glibc, non-glibc and external libs

[Marius Mauch]

On Thu, 16 Jun 2005 15:47:35 +0200
"Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote:

> c) main problem is libiconv, but this is required just by a few
> packages (gettext, glib2, bogofilter) the other uses it with gettext;
> as they doesn't require a specific version, we can also add dev-libs/
> libiconv to glibc's PROVIDE and just depend on dev-libs/libiconv.
> 
> What about this?

Sorry, but it's not a good idea to PROVIDE non-virtuals. Creates all
kinds of problems (just search for the gcc-4.7 bug).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgp8j6I3fbk7k.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Glibc, non-glibc and external libs

[Marius Mauch]

On Thu, 16 Jun 2005 11:41:59 +0200
Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote:

> On Thu, 16 Jun 2005 11:26:40 +0200
> Marius Mauch <[EMAIL PROTECTED]> wrote:
> 
> > They can inherit from $PORTDIR profiles, assuming that you know
> > t he values of $PORTDIR and $PORTDIR_OVERLAY, just figure the
> > relative path out. Of course that's a problem if you can't rely
> > on defaults and a cleaner solution is needed anyway (probably
> > coming with profiles2).
> 
> Bug #83613 maybe? That's a rather trivial patch, and i think it
> would help a lot for distributing some non-official profiles.

As a short term solution maybe, don't really like the restriction to
$PORTDIR though (practically not relevant though, just don't like
special cases).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpqp0kTrEjFG.pgp
Description: PGP signature

Re: [gentoo-dev] newb question about emerge ...

[Marius Mauch]

On Thu, 16 Jun 2005 11:42:51 +0200
Thomas Matthijs <[EMAIL PROTECTED]> wrote:

> * Marius Mauch ([EMAIL PROTECTED]) wrote:
> > Thomas Matthijs wrote:
> > >># regenworld
> > >>run that command occassionally as sometimes things that get
> > >>emerged for whatever reason are not part of the world file AND
> > >>not a direct dependancy of something and so the emerge -avuDN
> > >>world would not check -- running this command will check and add
> > >>these entries to the world file so they will be included with
> > >>updates.
> > >
> > >
> > >Don't! do that it will ruin your world file, it'll no longer be
> > >what the world file is supposed to be, but contain everything you
> > >merged. It is only ment as a rescue when you delete your world file
> > >(or lose it in some other way)
> > 
> > Nope. You're mixing that up with the evil `qpkg -I > world`
> > command. regenworld should be fine as long as /var/log/emerge.log
> > is complete.
> 
> It is not.
> it adds alot of junk to my work file (over 250 packages), some i
> merged with --oneshot, other are just deps of other packages

Can you file a bug about that and attach your emerge.log?

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgphXQM4wgEEr.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Glibc, non-glibc and external libs

[Marius Mauch]

On Thu, 16 Jun 2005 08:18:30 +0200
"Diego 'Flameeyes' Pettenò" <[EMAIL PROTECTED]> wrote:

> Anyway, I prefer avoid having to mess with profiles in this way, as
> our profile already needs a lot more loving than the base ones as atm
> we don't inherit from them (profiles in overlays can't inherit
> profiles's in main portdir), adding more cruft over this is going to
> be a great problem to maintain.

They can inherit from $PORTDIR profiles, assuming that you know t
he values of $PORTDIR and $PORTDIR_OVERLAY, just figure the relative
path out. Of course that's a problem if you can't rely on defaults and
a cleaner solution is needed anyway (probably coming with profiles2).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpkZRFbaYXlI.pgp
Description: PGP signature

Re: [gentoo-dev] newb question about emerge ...

[Marius Mauch]

Thomas Matthijs wrote:

# regenworld
run that command occassionally as sometimes things that get emerged
for whatever reason are not part of the world file AND not a direct
dependancy of something and so the emerge -avuDN world would not check
-- running this command will check and add these entries to the world
file so they will be included with updates.



Don't! do that it will ruin your world file, it'll no longer be what the
world file is supposed to be, but contain everything you merged. It is only
ment as a rescue when you delete your world file(or lose it in some
other way)


Nope. You're mixing that up with the evil `qpkg -I > world` command. 
regenworld should be fine as long as /var/log/emerge.log is complete.


Marius
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] perl/openssl circular dep, possible solution (python/perl/db devs please read)

[Marius Mauch]

Paul de Vrieze wrote:
I think you know what I mean. By definition portage is allready there for 
the ebuild to be evaluated. It is therefore unnecessary to specify it as 
a dependency. 


Sure I understood that. However, your post said exactly the opposite:
"... building does not depend on portage being there."
Also note that I said "implicit dependency". Well, guess I shouldn't 
send nitpicking mails anymore.


> Besides that for most packages any compatible package
> manager should work (there just is only portage now though).

Didn't I say that myself?

Marius
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Intent to help with #gentoo-dev voicing issues

[Marius Mauch]

Andrej Kacian wrote:

On Wed, 15 Jun 2005 19:03:44 +0900
Jason Stubbs <[EMAIL PROTECTED]> wrote:



Is that not a win/win situation? Where exactly is the "bureaucracy"?



Maybe I used wrong term - I was thinking about time and effort spent on
setting up and maintaining the ircbot. I've been in charge of a large botnet
in the past (along with quite a lot of tcl scripting), so I know it's not
hard, but still...



I'm pretty sure that could be added to GenBot or jeeves, wouldn't need 
yet another bot.


Marius
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] perl/openssl circular dep, possible solution (python/perl/db devs please read)

[Marius Mauch]

On Tue, 14 Jun 2005 23:32:06 +0200
Paul de Vrieze <[EMAIL PROTECTED]> wrote:

> I don't think gcc-config should depend on portage at all. Or does it
> actually use portage services. In any case it should be an RDEPEND,
> as building does not depend on portage being there.

Hmm, how do you build an ebuild without portage? Not trying to defend
that dependency, but technically all ebuilds DEPEND on portage (or a
compatible package manager), that's the most implicit dependency of all.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpT2nVsvTGn7.pgp
Description: PGP signature

Re: [gentoo-dev] Intent to help with #gentoo-dev voicing issues

[Marius Mauch]

On Wed, 15 Jun 2005 14:05:21 +0900
Chris White <[EMAIL PROTECTED]> wrote:

> > >>might I suggest not kicking #gentoo-dev visitors who ask for
> > >>voice to speak to the devs without a 'rtfm & go get a gentoo job'
> > >>smokescreen ?
> 
> My intentions in this email were regarding the above worries about
> things.  I plan to create somewhat of a consistant contact point
> between irc users that want a voice in dev.  If anyone has
> disagreements, I'll be happy to hear them out and hopefully address
> them.  My plan of interaction is as follows:

[snip]

Won't work. First it would introduce a single point of failure. If we'd
really follow this route there has to be a role for this, not a user.
Then how are people supposed to know about this in teh first place? I
wouldn't expect that users with a question/topic for -dev have read the
dev handbook. Often that is spontaneous, which brings me to my next
point: email definitely won't work for this, I mean if someone writes
an email they can just as well ask their question on the gentoo-dev
list directly.
And finally: I really don't like the idea of telling people "ask Chris
for voice, other devs might not behave nice", if there really is a
problem this will just sidestep it, not solve it.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgplbWIF5gXXr.pgp
Description: PGP signature

Re: [gentoo-dev] unofficial gentoo development guide

[Marius Mauch]

On Wed, 08 Jun 2005 15:19:17 +0800
"Dulmandakh Sukhbaatar" <[EMAIL PROTECTED]> wrote:

> Hi all. 
> 
> Where I can find unofficial gentoo development guide? It isn't
> present where it was week ago. I need it as soon as possible.

see this link:
http://forums.gentoo.org/viewtopic-t-344544-highlight-.html

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpkWFWIkosSe.pgp
Description: PGP signature

Re: [gentoo-dev] .keep files

[Marius Mauch]

Andrej Kacian wrote:

On Sat, 21 May 2005 17:37:53 -0700
Drake Wyrm <[EMAIL PROTECTED]> wrote:



I always thought that they were to keep 'emerge unmerge' from removing
an empty directory, but I could be wrong...


That, and to keep portage from removing empty directories during the
post-merge clean phase. Were it not for the .keep files, portage would
cheerfully remove any empty directories the first time the package was
upgraded.



Wouldn't it be possible for portage to just compare a dir in live filesystem
and in the emerge image, and if the dir in image contains .keep file, the live
dir wouldn't get deleted?



That dir isn't available at that point. And even if it would be, won't 
help as directories can be owned by multiple packages, and you 
definitely don't want to cross-check all installed packages for file 
ownership.


Marius
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] multiple categories for a package

[Marius Mauch]

Alin Nastac wrote:
Marius Mauch wrote:

CVS doesn't support symlinks.
But subversion does ;)
Doesn't help here.
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Naming scheme confusion

[Marius Mauch]

Georgi Georgiev wrote:
maillog: 16/05/2005-11:46:15(-0700): Donnie Berkholz types
Henrik Brix Andersen wrote:
The current ebuild is orinoco-0.15_rc2-r2.ebuild, and the logical name
for a CVS snapshot would, as I see it, be
orinoco-0.15_rc2_pre20050516.ebuild, but mixing _rcX and _preY is not
allowed by portage.
I can't go with just orinoco-0.15_pre20050516.ebuild as _rcX is
considered newer than _preY.
How about rc2_p20050516?

For a moment I thought that the above may actually be valid... Good
thing it's not. I would have been confused.
Well, it's valid with portage-2.1, but not 2.0.
Marius
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] multiple categories for a package

[Marius Mauch]

David Klaftenegger wrote:
Georgi Georgiev wrote:
Would it be inappropriate to start bitching (again) about a flat tree
where each package can go in multiple categories?

So now, that I've read  all messages in this thread, I needed a point to
start at..
I guess my approach isn't a way to go, but I can't find the reason for
it being bad, so:
Why not just create a symlink to the package in the category it *also*
should be in?
For example, net-mail/mutt could be a symlink to ../mail-client/mutt,
allowing to find it in both categories.
Ok, portage would have to do extra work, as it would have to check
wether a package is a symlink or not, ignore "symlink-packages" when it
comes to ambiguous naming, count them as already installed if the
package it points to is already installed and so on...
quite some work, but from my point of view less than some other solutions.
So I hope you understand what I mean, you may now hang me for this
proposal, but if you do please tell me why it is not a good way to allow
multiple categories per package ;-)
CVS doesn't support symlinks.
Marius
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Marius Mauch]

Michael Haubenwallner wrote:
- Original Message -
From: "Marius Mauch" <[EMAIL PROTECTED]>
Ciaran McCreesh wrote:

As for the new metadata variable, I think it should be a complement to
RESTRICT (not limited to prefix). As the name for this var I suggest
SUPPORTS, so for an ebuild that can install into /usr, $PREFIX and $HOME
it would look like:
SUPPORTS="prefix prefix-home" (as /usr is implicit)

For the values of the SUPPORTS-Variable (i like the name) i'd prefer some
words pointing to the package-manager used (primary/secondary/home), fex
"secondarypm homepm" or "2ndpm homepm" or the like (more ideas welcome),
because /usr is a 'prefix' too.
That looks horribly confusing. Doesn't really matter if /usr is a prefix 
or not.

But here's just one point to think of how to avoid redundant information in
ebuilds:
The SUPPORTS-Variable _will_ be necessary for home-installation, sure. But
when an ebuild has KEYWORDS='sparc' and SUPPORTS='2ndpm', this does not
automatically imply that it compiles on a 'sparc-solaris' - this keyword has
to be added explicitly.
But how likely is it that on 'sparc-solaris' portage would be the primary
pkg mgr installing into /usr ?
Depends if there will be a Gentoo/OpenSolaris ...
So when an ebuild has 'sparc-solaris' in keywords, imo one can assume that
it _does_ support "secondarypm" (also look at
http://www.gentoo.org/proj/en/glep/glep-0022.html#reasonable-defaults).
Or is this assumption too much implicit ?
It would be confusing IMO.
Marius
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [ANNOUNCE] eclectic-0.9.1

[Marius Mauch]

Danny van Dyk wrote:
 * profile:
   List and switch Gentoo portage profiles. Check if selected
   profile is valid in regard to used "ARCH".
Hmm, have to check this out and see if I can obsolete my own little hack 
for changing profile.

 * What do we need to accomplish to get the status of an "Official
   Gentoo Project" ? Is a manager voting necessary ?
Just put it as a subproject under base as it doesn't have the substance 
for a TLP, and I don't think azarah would mind it ;)

 * What do the maintainers of Gentoo's various -config and -update
   scripts think about converting their scripts into eclectic modules ?
Neither etc-update nor env-update fall into this domain.
 * What is the best place for eclectic in the portage tree? app-admin as
   it is an administrative tool? Or rather app-portage as it should be
   used together with Gentoo only?
Keep it in app-admin as it isn't really portage related.
Nice to finally see this becoming public.
Marius
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Marius Mauch]

Brian Harring wrote:
Clarify please :)
Offhand, I don't see why a bin repo for a home target isn't viable, 
along with a vdb repo in the same location.  It's a bit trickier, but 
I suspect it might be a bit more flexible in the long run.
I don't think that's possible without a lot of hacking for many packages 
as $HOME will be expanded at build time and might be included in the 
resulting binaries. Or in other words: If it works, we don't need 
$PREFIX support at all as packages could be relocated at merge time.

Marius
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Marius Mauch]

Ciaran McCreesh wrote:
Ok, say we use ICANINSTALLTO (name!). Then if we have "prefix" as the
destination, there's no problem, because we know that all our deps are
installed in ${PREFIX} as well. However, if we're installing to "home",
we need to know where our deps are -- for "home" installs I'm presuming
we don't force a full dep tree in "home" (unlike for "prefix"). This
*could* still be done with ${PREFIX} I guess? Or to avoid confusing
things, ${DEPS_PREFIX}? Not really sure...
As for the new metadata variable, I think it should be a complement to 
RESTRICT (not limited to prefix). As the name for this var I suggest 
SUPPORTS, so for an ebuild that can install into /usr, $PREFIX and $HOME 
it would look like:
SUPPORTS="prefix prefix-home" (as /usr is implicit)

Marius
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Cutting down on non-cascaded profiles

[Marius Mauch]

On Tue, 3 May 2005 14:49:54 -0400
Mike Frysinger <[EMAIL PROTECTED]> wrote:

> On Tuesday 03 May 2005 12:10 pm, Chris Gianelloni wrote:
> > I think an easier solution would be a portage rescue set of
> > profiles.
> 
> afaik the only thing it'd need is a 'make.defaults' and a custom 
> 'packages' (where we'd force a newer version of portage of course)
> 
> i dont think we even need a set, we could just do it with one ...
> after all,  we can stick bash code into make.defaults and have it do
> something ugly like  run `uname` or parse make.defaults to figure out
> the correct ARCH 
> -mike

Please no bash code in make.defaults other than variable assignments,
portage doesn't source it but uses a simle python parser.
Oh, and profile.bashrc isn't available either in those old portage
versions.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgphU6yqoIAMx.pgp
Description: PGP signature

Re: [gentoo-dev] new glep draft: Portage as a secondary package manager

[Marius Mauch]

On Mon, 2 May 2005 21:48:10 -0500
Brian Harring <[EMAIL PROTECTED]> wrote:

> Clarify why portage, which _does_ function as a secondary pkg manager 
> (collision-protect wouldn't exist otherwise) wouldn't suffice if 
> someone gave enough of a damn to do the work?

Off-topic, but collision-protect wasn't written for that purpose but to
detect broken/conflicting packages. The macos project just uses it.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpZhoagFR3fl.pgp
Description: PGP signature

Re: [gentoo-dev] Portage ebuild cruft

[Marius Mauch]

On Sat, 30 Apr 2005 12:31:17 +0200
Sune Kloppenborg Jeppesen <[EMAIL PROTECTED]> wrote:

> On Friday 29 April 2005 16:38, Jason Stubbs wrote:
> > > Heh, I get that after every invocation of emerge. :)
> >
> > Yep. That's the scanning of all installed packages for any provided
> > virtuals.
> Why not let Portage print that before scanning?

Print what?
The scanning is done on the general config parsing, and you can't really
do anything before that.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpddS2nRb6Xf.pgp
Description: PGP signature

Re: [gentoo-dev] How well supported is collision-protect?

[Marius Mauch]

On Wed, 27 Apr 2005 20:37:10 -0400
Mike Frysinger <[EMAIL PROTECTED]> wrote:

> On Wednesday 27 April 2005 08:29 pm, Georgi Georgiev wrote:
> > - How well is it expected to work?
> 
> it's expected to work just fine

Most of the time. However, sometimes there are some issues (the xorg
move, perl modules manpages or portage compilation objects to name a
few) that can't be fixed really. That's why I don't think it will ever
be a default setting.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpw3Ty9EuUgA.pgp
Description: PGP signature

Re: [gentoo-dev] Per-category and per-package eclasses

[Marius Mauch]

On Mon, 25 Apr 2005 14:47:03 +0100
Ciaran McCreesh <[EMAIL PROTECTED]> wrote:

> On Mon, 25 Apr 2005 15:27:12 +0300 Marius Mauch <[EMAIL PROTECTED]>
> wrote:
> | Dan Meltzer wrote:
> | > I can see the use for a category one, but I can see no point for a
> | > package-local one, if you're going to have it specific for one
> | > package, why not just put it in the ebuild, and have no eclass at
> | > all?
> | 
> | Actually I'd say the opposite: There is definitely a use for 
> | package-local eclasses, however I don't see the point for
> | category-local  eclasses (especially as that would very funny to get
> | it working). Example for package-local eclasses? Whenever you define
> | a function in an  ebuild that isn't version specific.
> 
> Category-specific: app-vim/eclass/vim-plugin.eclass
> Package-specific: any package with a non-trivial build system that
> doesn't change too much between versions.
> 
> Making it work is 'easy', just make inherit first try /cat/pkg/eclass/
> then /cat/eclass/ then finally /eclass/ .

well, /cat/eclass will bring us a lot of fun if implemented ;)

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpZw3sPllojY.pgp
Description: PGP signature

Re: [gentoo-dev] Per-category and per-package eclasses

[Marius Mauch]

Dan Meltzer wrote:
I can see the use for a category one, but I can see no point for a
package-local one, if you're going to have it specific for one
package, why not just put it in the ebuild, and have no eclass at all?
Actually I'd say the opposite: There is definitely a use for 
package-local eclasses, however I don't see the point for category-local 
eclasses (especially as that would very funny to get it working).
Example for package-local eclasses? Whenever you define a function in an 
ebuild that isn't version specific.

Marius
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] circular moves

[Marius Mauch]

Hi,

just noticed that there are a number of circular moves in the global
update files (PORTDIR/profiles/update/*). This is a bad thing as they
cause some issues with etc-update and package.* files, see
http://forums.gentoo.org/viewtopic-t-325721.html for an example.

Currently the following entries cause problems:

2Q-2003:move sys-apps/lm_sensors sys-apps/lm-sensors
3Q-2003:move dev-lang/mono dev-dotnet/mono
3Q-2004:move app-laptop/wmbatppc x11-plugins/wmbatppc
3Q-2004:move app-xemacs/eterm app-xemacs/xemacs-eterm
4Q-2002:move net-misc/atftp net-ftp/atftp
4Q-2002:move x11-plugins/gkrellmwireless net-wireless/gkrellmwireless
4Q-2004:move dev-java/wsdl4j-bin dev-java/wsdl4j

Their conterparts being:

1Q-2003:move net-wireless/gkrellmwireless x11-plugins/gkrellmwireless
1Q-2004:move x11-plugins/wmbatppc app-laptop/wmbatppc
1Q-2005:move dev-dotnet/mono dev-lang/mono
1Q-2005:move sys-apps/lm-sensors sys-apps/lm_sensors
2Q-2003:move app-xemacs/xemacs-eterm app-xemacs/eterm
3Q-2003:move net-ftp/atftp net-misc/atftp
3Q-2004:move dev-java/wsdl4j dev-java/wsdl4j-bin

If you maintain one of the mentioned packages please remove the older
entry from the update files.
The following (horrible) bash command was used to find these:

cd profiles/updates; grep ^move * > /tmp/updatelist; for x in $(cut -d\ 
-f 2 < /tmp/updatelist) ; do cat /tmp/updatelist | cut -d\  -f 3 | grep
$x; done > /tmp/indirectlist; l=""; for x in $(< /tmp/indirectlist); do
l="$l\n$(grep $x /tmp/updatelist | cut -d\  -f 2-3)"; done; while read
x; do y=$(echo $x | grep -E '.+/.+ .+/.+ .+/.+ .+/.+'); a=$(echo $y |
cut -d\   -f 1); b=$(echo $y | cut -d\  -f 2); c=$(echo $y | cut -d\  -f
3); d=$(echo $y | cut -d\  -f 4); [ "$a" == "$d" -a "$b" == "$c" ] &&
echo $a $b; done <<< "$(echo -e $l)"|grep -v '^$'|sort -u | while read
x; do grep "$x" *; done

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Portage management change

[Marius Mauch]

Hi everybody,

As some of you may already know Nicholas Jones (carpaski), the portage
lead till now, stepped down of that job recently for various reasons.
This mail is intended to let people know how things will be handled in
the future in portage-land.

First, there will be no single replacement for the position of the
portage lead. Instead there will be a group of three developers (myself,
Jason Stubbs and Brian Harring) who will manage the portage project
together. As for the voting in manager meetings, I'll act as the human
relay for any consensus reached between us.
Even with this change in management the developement will continue and
focus on the release of a new major version of portage.

Meanwhile, we'd like to thank Nick for his contributions and wish him
good luck with life and the door is always open for coming back in the
future.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Sources for the entire OS

[Marius Mauch]

On Thu, 07 Apr 2005 18:09:02 -0700
Kaarthik Sivakumar <[EMAIL PROTECTED]> wrote:

> But that would give me the source tarballs for *all* the packages. I
> guess I just want sources for stuff like glibc, utils like find, grep,
> etc which tend to form the base OS. I could do that on a per-package
> basis, like 'emerge glibc -f', etc but I was hoping for a meta-port (I
> am not sure what it is called here) that has all of this. (I am still
> learning how to use portage and its various utilities; I am a gentoo
> user since about 4 days now, coming from FreeBSD).

emerge -ef system

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.


pgpaHpv6l7INV.pgp
Description: PGP signature