[gentoo-dev] last rites: karamba-weather

[Jonathan Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Upstream is dead, package doesn't work, and it has a suitable
replacement which seems to be actively developed that would be put into
portage as its replacement. No reverse dependency issues.

The package has been masked for a week to ensure that noone objects. Any
objections from the list?

see https://bugs.gentoo.org/show_bug.cgi?id=47005

- -smithj

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCsmCbl5AvwDPiUowRArk1AKCoNabT2rFWjeVKom84uiR/7nsxMgCeLtwM
DUUy0f/8NtJ7MHZoDjkzTCc=
=gutI
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] new virtual - xlocker?

[Jonathan Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Beber [Gentoo] wrote:
> Hi guys,
> 
> thanks for you to look of my reply on this bug :)
> 
> It don't think that a virtual need to be use here. 3 softwares for a
> virtual is quite less.
> 
> Why are you placing a REDEPEND instead of a PDEPEND ?
> xautolock *doesn't need* on of theses software to compile. It need one
> of them to be usable. Is the side, it's a post depend.

PDEPEND is for something that is necessary, but can _only_ be compiled
after... RDEPEND is "run-time dependency"

- -smithj
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCsgT/l5AvwDPiUowRAuakAJ0ZjmtPUPCFGcxwy6gfujjHikFP5gCgnBie
AWjJrSw1rlDruvePaJnsK4w=
=5WRk
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

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] splitting one source package into many binaries

[Rafael =?utf-8?q?=C3=81vila_de_Esp=C3=ADndola?=]

Em Thu 16 Jun 2005 14:05, Patrick Lauer escreveu:
> It depends on your point of view.
> Having to install 142 -devel packages just to be able to compile $foo is
> quite frustrating - I prefer the Gentoo way.
I agree. I think that by default emerge  should install everything 
from . My idea is to teach ebuild how to split binary packages but 
install all of then by default. For example, emerge gcc would install all 
parts of gcc that are selected by the use flags (gcc proper, g++, libgcc, 
etc). But now one could do "emerge -C g++".

> I don't know if there is a demand for this, but if you really need to
> shrink stuff, create your own ebuild overlay with "fixed" ebuilds ...
I do that right now. I was wondering if someone else would also be interested.

> Well ... it gets you all kinds of problems because if you split packages
> (e.g. X --> X + X-headers) and you want to compile something you'll pull
> in the second package anyway. So for most packages I think it's not
> really useful.
Qt is the package that made me think about the problem. Maybe some 
client/server split in packages like ssh. X might also be a candidate, but I 
think that in this case it is better to help xorg to do the split.

> wkr,
> Patrick

Rafael


pgpegR0BJFwXs.pgp
Description: PGP signature

Re: [gentoo-dev] new virtual - xlocker?

[Beber [Gentoo]]

On 6/16/05, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-06-16 at 18:01 +0300, Alin Dobre wrote:
> > Jonathan Smith wrote:
> > > The desktop-misc herd (which was sadly neglected until recently) could
> > > benefit from a new virtual. x11-misc/xautolock is a wrapper which locks
> > > the screen via any appropriate program such as xlockmore or xtrlock.
> >
> > xscreensaver locks the screen, too, besides its normal screensaver
> > features (like xlockmore).
> >
> > > This program needs to depend on an xlocker, but we should not lock users
> > > into one specific one.
> > >
> > > See bug 95246 [1]
> > >
> > > I would probably name it virtual/xlocker, but other suggestions are, of
> > > course, welcome.
> > >
> > > Thanks
> > >
> > > [1]: https://bugs.gentoo.org/show_bug.cgi?id=95246
> > >
> 
> You don't have to setup a virtual for this.  In fact, the simpler method
> (especially when dealing with only one package) is to use the || *DEPEND
> syntax.
> 
> RDEPEND="|| (
> x11-misc/xscreensaver
> x11-misc/xlockmore
> x11-misc/xtrlock )"
> 
> This would prefer xscreensaver over the others, but any would satisfy
> the dependency.

Hi guys,

thanks for you to look of my reply on this bug :)

It don't think that a virtual need to be use here. 3 softwares for a
virtual is quite less.

Why are you placing a REDEPEND instead of a PDEPEND ?
xautolock *doesn't need* on of theses software to compile. It need one
of them to be usable. Is the side, it's a post depend.

++
Beber

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting one source package into many binaries

[Rafael =?iso-8859-1?q?=C1vila_de_Esp=EDndola?=]

Em Thu 16 Jun 2005 14:01, Caleb Tennis escreveu:
> On Thursday 16 June 2005 11:50 am, Rafael Espíndola wrote:
> > Is this a bad idea or simply not the Gentoo way?
>
> The idea isn't bad, but the implementation is more work to maintain than
> it's probably worth.
>
> You can, of course, always roll your own ebuild variation and keep it in
> your portage overlay directory.  Or, alternatively, you can just "rm
> -f /usr/qt/3/bin/designer".
I use the rm option currently. A overlay has the disadvantage that I would 
miss updates to the portage tree.

> Caleb

Rafael


pgp8Scr7U6DKK.pgp
Description: PGP signature

[gentoo-dev] Re: Questions about licenses

[Torsten Veller]

* 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?

> > 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?
 
> > Aren't X11 and cdegood and JamesClark and ... the same license?
>
> Maybe there's one paragraph changed - I haven't looked at them yet.

I don't know how to diff them efficiently. I put every word in in a
line of its own. X11 is different - but cdegood and JamesClark differ
in something like "ask cdegroot" and "ask James Clark".
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Discussion: alternative compatible utilities

[Alec Warner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Don't attempt to ignore the complexity because it sucks and gives you a
headache.  The complexity of multiple kernels, userlands, arches and
platforms exists whether you like it or not.  The key being the
management of the complexity.  Currently the tools perform poorly
because it's been primarly GNU userland + Linux kernel + random arches.
 The first two are easy to take care of and the third has arch teams.
Thus we probably need more keywords ( x86-fbsd-bsd...etc it's been said
before ) and we need more people to keyword stuff ( arch-kernel-userland
).  I think the big issue is to adapt to the new requirements without
making the current tools an overpatched mess.

Part of the issue I see is everyone is only focused on their little
problem.  X, Y or Z that I need is broken and I need fix foo; it's
talked about on IRC, it seems to work, it's implemented.  Then a week
later someone who wasn't on at time of discussion notes that it broke
something and and now needs to be 'fixed'.  I think Flameeyes has done
a pretty good job keeping everyone informed of Gentoo/fbsd's needs and
offering pretty good solutions on how to fix them in a general way.  I
think part of the problem is that this doesn't happen often enough and
we end up with a bunch of hacks that need to be integrated together.
- -Alec Warner
Ajec

Dan Meltzer wrote:

>Well it would be nice to have it all abstracted, wouldn't stablizing a
>package get exponetially harder? Not only would each arch need to be
>tested, each combination of packages on each arch would need to be
>tested, if FEX openpam became usable on linux instead of just
>linuxpam, each arch that stableized would now need to say works for
>this arch for linuxpam, and works for this arch for openpam, which
>would cause lots and lots of keywords mess.
>
>Or am I misunderstanding your post?
>
>On 6/16/05, Luca Barbato <[EMAIL PROTECTED]> wrote:
>
>
>>Diego 'Flameeyes' Pettenò wrote:
>>
>>
>>
>>>Let me explain: on Gentoo/Linux systems, all the base utilities
(make, tar,
>>>sed, etc etc) are GNUish; on Gentoo/FreeBSD they are BSDish; on
Gentoo/Darwin
>>>I don't really know :P
>>>This limits a bit the user because to use other kind of utilities it
must use
>>>aliases and he can't change, for example, the tar used by portage or
by other
>>>scripts.
>>>
>>>
>>>
>>Surely it would be interesting for developer that want to make sure
>>their code will build in other userspaces w/out switching os,
>>and if that won't be so painful, would worth testing it.
>>
>>Obviously having it now isn't really needed. Thinking about that when
>>committing/updating ebuild would be good.
>>
>>( still I do hate bsd core utils implementations but that is just my
>>opinion =) )
>>
>>lu
>>
>>--
>>
>>Luca Barbato
>>
>>Gentoo/linux Developer  Gentoo/PPC Operational Leader
>>http://dev.gentoo.org/~lu_zero
>>
>>--
>>gentoo-dev@gentoo.org mailing list
>>
>>
>>
>>
>
>
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQrHuf2zglR5RwbyYAQKz7g//ei85Mupvhm/nLq5FH3re1pKpYhmvREyX
bM51xqH4SXNWB1wCrVgHJXs7YV4nTLnl9lpvg+YKElcrCKwc4wqGTdvYWen9L/Is
IzmgHzKkkinfrDHQAXLylCy753S/fuiJowSAcg6rW+8sPadJHU3zYjunC4mhXLLL
99drUDDihS+8KljclJgVkP+fPFMqBo4GgtZtwHH/wksbeomWIIrlF90JFO1AZuA+
2kLrFcriPxe0/9UD4yZYEjgQ649cA3pYDCMoiNtmVLLeIBqvR7qdNP6LnRjhHD/5
d+f6SVADql2zreUZSxxnCTLN+V32ImRE9Mm6zAafQ/B4C+4uxGUkwQYNpPLrWZfd
TmMbd0qHFjmZVTSjwhk6L1lWvcro7Bp9o1IUTQzaqUcpcF/zhsgB9Av29svnhJgY
oqA9IavcoM6fT+gl1zSaiKoVCdGEGIAIxlwN/ePst5/hmf/AXr76ooAamAcJlKMV
Nrb7Q8crdd7usz4QIuNvjcw/39w/sTrXnPCVStNSdvG887vEVGHMJx0WEsXL7vtU
aG5abQ/rPmoYF//SUhAbhYPXXmQhWopGwBobx1cwnnbUEdqEaiuTqGW8eYWiVo3y
ziULbj5H9oH/k9q0SOtGjfrF7nIUVgp48CfRprSFKsCKFYYdZ5Hj58TmuEoGRTiO
4kDCAXCWK3E=
=/Jnb
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] production vs enterprise and the direction of Gentoo

[Chris Gianelloni]

On Thu, 2005-06-16 at 12:55 -0500, kashani wrote:
>   I'm an admin and have only worked in ISP, NSP, hosting, and startup 
> gigs. These systems tend to be fast moving, customer and feature driven, 
> and a bit on the bleeding edge. I don't believe any of those 
> environments fall into what is normally considered "enterprise", but 
> they are production systems with a premium on flexibility over stability 
> much like a Linux distribution we all know and love. :)

Production != Enterprise

I know what you mean, though.  However, you are definitely not the
target for any of Gentoo's "Enterprise" efforts, as they are, by design,
much slower moving and much less flexible.

> posting on the forums over a QA department of just me. So rather than 
> see Gentoo think about doing or not doing enterprise type stuff like 
> long releases, support contracts, etc I think most of us LAMP, MRTG, 
> Nagios, BIND, Postfix, Qmail, Postgres, thttpd, Courier, etc geeks would 
> like "just a bit more stability" rather than the overhead that comes 
> with enterprise features.

Honestly, the more bleeding edge it is, the less quality that is going
to be associated with it, simply due to new features and other such
things that will not have gotten as much testing/bug-fixing as the more
stable features.  Unless we have our own audit team specifically looking
for bugs and fixing them *before they are reported* then there isn't
much we can do to resolve this situation.

>   To be honest /etc/portage/* tends be enough control for me, but I've 
> been doing admin work for 9 years. And I've got a test environment that 
> I use religiously. I do however answer a lot of questions in the Network 
> and Security forum where up and coming admins aren't so lucky. I don't 
> think any of us expect a foolproof system, but there is room for a bit 
> more stability that'll benefit all users... especially admins. :)

That is one of the problems we have here at Gentoo.  We provide ways of
doing things that you want to do.  Sometimes the methods are very
simple, other times, we expect you to know what you're doing.  The real
problem we have is how to balance between the "do everything for the
user" approach of some distributions and the "don't do a damn thing and
then let the user RTFM" approach that is a bit more common with Gentoo.
Personally, I think we simply need to make sure things get documented
well and leave it up to the community to provide the "support", as it
were.  This has worked quite well for Gentoo, and tends to tighten the
bond between users and developers.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] splitting one source package into many binaries

[Yuri Vasilevski]

Hi,

On Thu, 16 Jun 2005 12:40:39 -0500
Brian Jackson <[EMAIL PROTECTED]> wrote:

> Rafael Espíndola wrote:
> > I am using Gentoo to build some small systems. While things like the
> > minimal useflag is a joy, the monolithic nature of most gentoo
> > packages is a headache.
> > 
> > Kde has been spit and libstdc++ can be installed without gcc but there
> > are many other packages that don't have this feature. For example,
> > installing qt also installs qt designer.
> 
> Use INSTALL_MASK to keep it from getting installed. Keep both pieces.

I think that it's not the way to go because this will create
the exact problem that existed with installing an incomplete
kde before there where split ebuilds for it.

And this problem is that when you emerge a package it expects
it's dependencies to have the things it'll use form them. And
with INSTALL_MASK you brake this assumption in a way that there
is no easy way for an ebuild to verify that it's dependencies
have installed the things that the package needs.

So I think it may be good for some packages to be split in
several packages (but right now I can't think of any), but I
think it'll be much better introduce more granularity into
many ebuils with use flags. This is specially the case (in
my opinion) of packages that can have both client and server
functionality (the best example I can think of is net-fs/samba,
which I mostly use just to mount shares form other servers).

Just my 2 non convertible (i.e. non developers) cents.
Yuri.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Qt4 portage update

[Caleb Tennis]

With the pending release of Qt4 very soon, I wanted to take a moment to update 
the community on what kind of effect it will have on portage:

First, the installation is now FHS compliant - no more stuff going 
into /usr/qt.

Previous Qt versions built one big library; this version builds 9 or 10 
smaller ones (all installed into /usr/lib/qt4).  Since the names are 
different, as well as the sonames, there should not be any runtime linking 
issues with a mixed installation.

Qt4 does not make use of the QTDIR environment variable like Qt3 did.  This 
means that automated build scripts, such as those with most KDE programs, 
will still pick up the correct Qt3 programs (uic, moc, and qmake).  For 
programs that don't use these types of build scripts, ebuild modifications 
may need to be made to tell the package which directory to pick up its binary 
tools in (/usr/qt/3/bin for Qt3, /usr/bin for Qt4).

I currently don't have any plans for any type of xxx-config package to switch 
between versions.  After installing Qt4, those applications will be higher in 
precedence in the PATH.  If you need to run Qt3 applications, you will either 
need to specify the full path or restructure your PATH to make it work.

Even though Trolltech split out the GUI libraries from the rest of the core 
libraries, X11 is still a dependency for the whole package.  The reason for 
this is that, as of now, Trolltech hasn't provided a convenient way to build 
a subset of the libraries - it's really an all or nothing thing.  Eventually 
once the development stabilizes a bit, I think it will be feasible to have a 
gui and non-gui set of ebuilds.

All that said - the latest version in portage ( qt-4.0.0_rc1-r2 ) works and 
installs great for me.  At this point, it may be good for aches to try 
testing the installation, as well as people who use non-traditional setups, 
like icc, ulibc, or "interesting" CXXFLAGS.

At the moment, I don't know of any installable applications that make use of 
this new Qt version, but they'll be springing up very soon.  Hopefully we'll 
be ready for them.

Thanks,
Caleb
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] production vs enterprise and the direction of Gentoo

[kashani]

	I really enjoyed last weeks discussion about enterprise, devs, and 
users. But I think a significant number of users don't fall into any of 
those categories... well at least I don't.


	I'm an admin and have only worked in ISP, NSP, hosting, and startup 
gigs. These systems tend to be fast moving, customer and feature driven, 
and a bit on the bleeding edge. I don't believe any of those 
environments fall into what is normally considered "enterprise", but 
they are production systems with a premium on flexibility over stability 
much like a Linux distribution we all know and love. :)


	Running Gentoo in production has been a competitive advantage for us. 
Need tomcat installed? Here it is. Need PHP5? Here it is. Need XML 
nonsense in PHP? Here it is. Need a Mysql driven virtual mail system? 
Here it is. At the time to do the above on most stable or enterprise 
systems would have involved waiting for the packages I wanted to be 
releases 12-18 months after the fact or becoming a dev. Neither are a 
great use of my time. I'll take a few thousand random Gentoo users 
posting on the forums over a QA department of just me. So rather than 
see Gentoo think about doing or not doing enterprise type stuff like 
long releases, support contracts, etc I think most of us LAMP, MRTG, 
Nagios, BIND, Postfix, Qmail, Postgres, thttpd, Courier, etc geeks would 
like "just a bit more stability" rather than the overhead that comes 
with enterprise features.


	Some people really like the idea of snapshots. I'm not completely sold 
on it, but would find it interesting if it were 6 month snapshots or 
less. I like the idea of meta builds. I'd be even more interested in 
snapshotting only the meta build rather than the whole OS. The mail 
server stays stable, but the rest updates as normal... I'm sure that 
idea will turn out to have significant drawbacks. Reverse dependency 
checking... been discussed to death and we all know it's coming. Once 
it's working well that's going to eliminate a number of problems 
especially if it'll warn you at the emerge -upv level that some updates 
are going to require a revdep-rebuild rather than after the fact.


	To be honest /etc/portage/* tends be enough control for me, but I've 
been doing admin work for 9 years. And I've got a test environment that 
I use religiously. I do however answer a lot of questions in the Network 
and Security forum where up and coming admins aren't so lucky. I don't 
think any of us expect a foolproof system, but there is room for a bit 
more stability that'll benefit all users... especially admins. :)


Hopefully this sparks some more interesting debate.

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

Re: [gentoo-dev] splitting one source package into many binaries

[Brian Jackson]

Rafael Espíndola wrote:

I am using Gentoo to build some small systems. While things like the
minimal useflag is a joy, the monolithic nature of most gentoo
packages is a headache.

Kde has been spit and libstdc++ can be installed without gcc but there
are many other packages that don't have this feature. For example,
installing qt also installs qt designer.


Use INSTALL_MASK to keep it from getting installed. Keep both pieces.



Has someone worked on changing ebuild so that it could create many
binary packages from one source? Something similar to debian's
dpkg-buildpackage. For example, it would be wonderful to be able to do

ebuild qt-something.ebuild split-package

and have in /usr/portage/packages a package for qt-designer and a
package for the rest of the library.

Is this a bad idea or simply not the Gentoo way?

Thanks for any comments

--
Rafael Ávila de Espíndola


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting one source package into many binaries

[Mike Frysinger]

On Thursday 16 June 2005 12:50 pm, Rafael Espíndola wrote:
> libstdc++ can be installed without gcc

that's a bad example, we're debating what to do with the package seeing as how 
many never wanted it in the first place
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Developer: Paul Varner (FuzzyRay)

[Paul Varner]

On Thu, 2005-06-16 at 06:41 -0400, Michael Cummings wrote:
> wait a sec - i've been taking bugs and such from fuzzyray and only now he's a 
> dev?? Does that mean I should expect even *more* pain from texas
> 
But of course!  You actually been taking bugs from me for awhile and
have even accepted some of my patches :)

> =:D
> 
> welcome officially fuzzyray, promise not to make to many fuzzball jokes ;)
> 

Actually, I expect to hear fuzzball or worse when I break something.

Since ka0ttic didn't pull it from my quiz, here is where FuzzyRay came
from:

My nickname was given to me by my coworkers.  It came from the fact that
I rarely show emotions when I'm at work (i.e. my happy face and mad face
both look the same). The first part of the nickname came since I had
such a "warm and fuzzy" demeanor.  The second part comes from being a
"ray of sunshine"  Several years ago, a coworker put the two together
and came up with "Fuzzy Ray Valentine"

Thanks for the welcome!

Regards,
Paul
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] app-admin/mbr.. what to do... Bag somebody else with it!

[Drake Wyrm]

Patrick Lauer <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-06-16 at 11:13 +0200, Diego 'Flameeyes' Petten? wrote:
> > On Thursday 16 June 2005 10:53, Patrick Lauer wrote:
> > > Always a drag to see packages getting dropped, but if noone
> > > maintains them there's not much that can be done.
> > Well maybe we can have a way to define "latest portage version" for
> > removed package (a tag on cvs?) so that someone can prepare a weekly
> > tarball of removed packages waiting for new maintainers or so on.
> you mean a repository of removed ebuilds? I don't know if that is a
> good idea, but it sure has some uses. But if I'm not mistaken files
> can be resurrected from cvs, so they are not "lost", only less
> accessible.

How about if, perhaps, the Gentoo developers make arrangements with the
folks at BreakMyGentoo to have them adopt orphaned packages? That way,
the packages would still be available to users who like to tinker and
don't mind playing with explosives.

-- 
Batou: Hey, Major... You ever hear of "human rights"?
Kusanagi: I understand the concept, but I've never seen it in action.
  --Ghost in the Shell
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] splitting one source package into many binaries

[Patrick Lauer]

On Thu, 2005-06-16 at 13:50 -0300, Rafael Espíndola wrote:
> I am using Gentoo to build some small systems. While things like the
> minimal useflag is a joy, the monolithic nature of most gentoo
> packages is a headache.
It depends on your point of view.
Having to install 142 -devel packages just to be able to compile $foo is
quite frustrating - I prefer the Gentoo way.

> Kde has been spit and libstdc++ can be installed without gcc but there
> are many other packages that don't have this feature. For example,
> installing qt also installs qt designer.
I don't know if there is a demand for this, but if you really need to
shrink stuff, create your own ebuild overlay with "fixed" ebuilds ...
> Has someone worked on changing ebuild so that it could create many
> binary packages from one source? Something similar to debian's
> dpkg-buildpackage. For example, it would be wonderful to be able to do
> 
> ebuild qt-something.ebuild split-package
I haven't heard of anyone trying this, and as far as I can remember it has 
usually been shot down as a bad idea.
> and have in /usr/portage/packages a package for qt-designer and a
> package for the rest of the library.
> 
> Is this a bad idea or simply not the Gentoo way?
Well ... it gets you all kinds of problems because if you split packages
(e.g. X --> X + X-headers) and you want to compile something you'll pull
in the second package anyway. So for most packages I think it's not
really useful.

wkr,
Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] splitting one source package into many binaries

[Caleb Tennis]

On Thursday 16 June 2005 11:50 am, Rafael Espíndola wrote:
> Is this a bad idea or simply not the Gentoo way?

The idea isn't bad, but the implementation is more work to maintain than it's 
probably worth.

You can, of course, always roll your own ebuild variation and keep it in your 
portage overlay directory.  Or, alternatively, you can just "rm 
-f /usr/qt/3/bin/designer".

Caleb

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] splitting one source package into many binaries

[=?ISO-8859-1?Q?Rafael_Esp=EDndola?=]

I am using Gentoo to build some small systems. While things like the
minimal useflag is a joy, the monolithic nature of most gentoo
packages is a headache.

Kde has been spit and libstdc++ can be installed without gcc but there
are many other packages that don't have this feature. For example,
installing qt also installs qt designer.

Has someone worked on changing ebuild so that it could create many
binary packages from one source? Something similar to debian's
dpkg-buildpackage. For example, it would be wonderful to be able to do

ebuild qt-something.ebuild split-package

and have in /usr/portage/packages a package for qt-designer and a
package for the rest of the library.

Is this a bad idea or simply not the Gentoo way?

Thanks for any comments

--
Rafael Ávila de Espíndola

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] where goes Gentoo? Where went Fido?

[Alec Warner]

Jim Northrup wrote:


Aron Griffis wrote:

 


This is kinda bloggish, because it's basically a transcription of an
IRC monologue.  My apologies if it's hard to follow... 

   


This thread started out garnering cheers of elitest developer
sentiment.  There was even some mention of  "if they don't like it they
can run something else".

Then, that notion was reeled in, the developers are part of the user
community.

There is an open debate as to the meaning of support for 'enterprise',
'cluster', and 'hobbyist';

does gentoo mean any of these?

In this thread I posted a suggested hack which must surely have been
suggested before my reading/perusal of gentoo-dev, but also addresses a
tangible element, growth. 


-- Portage's power is too great in one place, it should be forged in the
hottest fires into the form of many rings for the leaders among gentoo,
with one ring to bind them.

Gentoo portage is growing, gentoo's communication network is growing in
complexity, and gentoo's organization is growing.

I saw it interesting that this is what describes the rise and fade of
FIDO net. 


First there were hobbyist, later came zealots, some with bad attitudes,
and eventually a full fledged organization devoted to handling the
politics, which grew large enough for division into zones.  There were
online businesses thriving from its value as well as the very
resourceful and isolated folks who had no other means of communicating
among the world at large.

One of fido's most interesting feature was its initial recognition that
its growth needed structure, and that structure was formed.   fido's own
politiks from around the world failed to vote for survival of the
IFNA(International FidoNet Association).  So fido dissolved its official
entity, and continuted to grow.  Fido became a concept which spun off
saplings and intertwined with the net, but in majority  of years it was
run by the folks with the biggest toys.

I mention fido because of one similarity which is uncannily familiar. 
"only" 26% of the potential voters recently cast a vote for the gentoo

metastructure.  we saw some puzzlement, bordering on grumbling, and some
amusement: "eeeyup that must be us!".

sooo. back to growth...

does the portage design foretell a single monolithic repo growing ad
infinitum?  this is the common watering hole which draws every single
participant to the same well.

it's gotta work, 'emerge world' has gotta fly.   does tinderbox
indicate this is a predictable outcome with a stable margin of error, as
t approaches infinity?

 

The portage team has tons of great ideas up their sleeves to make 
portage better, multiple repos being just one of the many.  I'll let 
them preach their stuff for now, lest I let slip ideas that never see 
the light of day ;)  Regardless changes are coming and they definately 
make me very excited.

-Alec Warner
Ajec

--
gentoo-dev@gentoo.org mailing list

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

[Diego 'Flameeyes' Pettenò]

On Thursday 16 June 2005 18:07, Mike Frysinger wrote:
> no, bsd libc doesnt directly require libiconv, but if you're using a
> bsd/Gentoo system and you have USE=nls, what are the chances you *dont
> want* libiconv ?
Quite a few as 'nls' useflag is already used by freebsd's libc for other 
means.
Maybe an iconv useflag can be acceptable, too? this probably would be better 
but still... when we'll have use-flags deps we should add the right deps.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgpYjjWem3peZ.pgp
Description: PGP signature

[gentoo-dev] List of aging ebuilds?

[Rob Cakebread]

Anyone have the source for the package aging list?

http://article.gmane.org/gmane.linux.gentoo.devel/23231

Maybe we can find a new server to run it on?

--
gentoo-dev@gentoo.org mailing list

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

[Mike Frysinger]

On Thursday 16 June 2005 11:51 am, Diego 'Flameeyes' Pettenò wrote:
> > Just keeping on heaping virtuals for everything is not the only way.  Or
> > just pull them in the profile.
>
> As I said, I'm not considering adding libiconv to profile as an option,
> it's not directly required.

that's fine, but i *still* dont see why putting 'nls? ( libiconv )' into 
PDEPEND of bsd libc isnt acceptable

no, bsd libc doesnt directly require libiconv, but if you're using a 
bsd/Gentoo system and you have USE=nls, what are the chances you *dont want* 
libiconv ?
-mike

-- 
gentoo-dev@gentoo.org mailing list

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

[Diego 'Flameeyes' Pettenò]

On Thursday 16 June 2005 16:13, Martin Schlemmer wrote:
> DEPEND="!userland_GNU? ( dev-libs/libiconv )"
I'd like to do that but there was disagreement about this before.
For me is enough.

> Just keeping on heaping virtuals for everything is not the only way.  Or
> just pull them in the profile.
As I said, I'm not considering adding libiconv to profile as an option, it's 
not directly required.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)


pgpPyV0PsVbDC.pgp
Description: PGP signature

Re: [gentoo-dev] new virtual - xlocker?

[Chris Gianelloni]

On Thu, 2005-06-16 at 18:01 +0300, Alin Dobre wrote:
> Jonathan Smith wrote:
> > The desktop-misc herd (which was sadly neglected until recently) could
> > benefit from a new virtual. x11-misc/xautolock is a wrapper which locks
> > the screen via any appropriate program such as xlockmore or xtrlock.
> 
> xscreensaver locks the screen, too, besides its normal screensaver
> features (like xlockmore).
> 
> > This program needs to depend on an xlocker, but we should not lock users
> > into one specific one.
> > 
> > See bug 95246 [1]
> > 
> > I would probably name it virtual/xlocker, but other suggestions are, of
> > course, welcome.
> > 
> > Thanks
> > 
> > [1]: https://bugs.gentoo.org/show_bug.cgi?id=95246
> > 

You don't have to setup a virtual for this.  In fact, the simpler method
(especially when dealing with only one package) is to use the || *DEPEND
syntax.

RDEPEND="|| (
x11-misc/xscreensaver
x11-misc/xlockmore
x11-misc/xtrlock )"

This would prefer xscreensaver over the others, but any would satisfy
the dependency.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] new virtual - xlocker?

[Alin Dobre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Jonathan Smith wrote:
> The desktop-misc herd (which was sadly neglected until recently) could
> benefit from a new virtual. x11-misc/xautolock is a wrapper which locks
> the screen via any appropriate program such as xlockmore or xtrlock.

xscreensaver locks the screen, too, besides its normal screensaver
features (like xlockmore).

> This program needs to depend on an xlocker, but we should not lock users
> into one specific one.
> 
> See bug 95246 [1]
> 
> I would probably name it virtual/xlocker, but other suggestions are, of
> course, welcome.
> 
> Thanks
> 
> [1]: https://bugs.gentoo.org/show_bug.cgi?id=95246
> 
> -smithj

- --
Alin DOBRE
Registered Linux User #287199
Documentation Team - Gentoo.RO Community
http://www.gentoo.ro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCsZQ+mG51ym6Hu9gRAg5tAJsF3LM5E5CbyzWufUPPIqipNazVCwCg867A
oQNq+uZekbVXRPefDSSqkJE=
=v4Lo
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] new virtual - xlocker?

[Jonathan Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The desktop-misc herd (which was sadly neglected until recently) could
benefit from a new virtual. x11-misc/xautolock is a wrapper which locks
the screen via any appropriate program such as xlockmore or xtrlock.
This program needs to depend on an xlocker, but we should not lock users
into one specific one.

See bug 95246 [1]

I would probably name it virtual/xlocker, but other suggestions are, of
course, welcome.

Thanks

[1]: https://bugs.gentoo.org/show_bug.cgi?id=95246

- -smithj
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCsZLMl5AvwDPiUowRAufJAKCT35XQ7L3DeYtQhW4jQxlooeEQPwCfTqte
Z9SKluceQ6f1lIen7TPFxFU=
=1VSE
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

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

[Martin Schlemmer]

On Thu, 2005-06-16 at 15:47 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 16 June 2005 00:02, Diego 'Flameeyes' Pettenò wrote:
> > There are other solutions a part the new virtuals?
> Ok just to summarize.
> 
> a) getopt_long isn't important right now, FreeBSD 5 already takes care of it, 
> if in the future it will be necessary for NetBSD, OpenBSD or DragonFly, it 
> will be another issue.
> 
> b) most of the packages requiring gettext at runtime already requires it at 
> build time atm... the simple thing to do is moving this on runtime on the 
> packages which needs when we'll stumble across it
> 
> 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.
> 

The issue I guess is that unlike it seems the common belief in the bsd
camp is, virtuals is not the ultimate cure for all that is twisted.

Rather do something like:

DEPEND="!userland_GNU? ( dev-libs/libiconv )"

(or '!elibc_glibc?' if that is more relevant if it might be needed for
uclibc/whatever)

Just keeping on heaping virtuals for everything is not the only way.  Or
just pull them in the profile.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



signature.asc
Description: This is a digitally signed message part

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] app-admin/mbr.. what to do...

[Chris Gianelloni]

On Thu, 2005-06-16 at 10:53 +0200, Patrick Lauer wrote:
> On Fri, 2005-06-17 at 01:41 +0900, Chris White wrote:
> > I just saw a bug report flow by for app-admin/mbr and looked for 
> > maintainers.  I found this:
> > ChangeLog: 1 manson, 1 woodchip
> > from jeeves.  Now, I think those people are retired, or I need to get out 
> > more (or both).  So what to do with said package.  It looks pretty old and 
> > this user wants it bumped so...  I'd do it but I have no solid test method 
> > and I really don't like putting out packages without one.

Ehh... the user that filed the bug could test it for you.

> I think this problem is not limited to this package.
> Maybe someone with some scripting skillz could create a list of all
> "orphaned" packages?
> (no metadata.xml, no active maintainer, ...)

Yes, it would be nice to get a list of these packages, but *not* for
removing them.  In many cases these packages "work" and have no bugs
filed against them, so what is gained by removing them?

> > If anyone is interested, the bug number is here:
> > http://bugs.gentoo.org/show_bug.cgi?id=96254
> > Otherwise we should do something about the fate of this package.

> Either drop it or find a maintainer I guess. 
> Always a drag to see packages getting dropped, but if noone maintains
> them there's not much that can be done.

How about leave it alone?

I can understand if there is no maintainer and there are a ton of bugs
filed against it (or even just one critical one), but for a package
where the only "bug" is a version bump request?  Just ask the user to
test the ebuild, then commit it.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

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

[Chris Gianelloni]

On Thu, 2005-06-16 at 04:41 +0200, Diego 'Flameeyes' Pettenò wrote:
> When I fist needed to install libiconv in the Gentoo/FreeBSD I was tinkering 
> with, was just because I needed it ot have glib2 working for irssi.. I was 
> already using that box as ftp and mail server.

HAHAHAHA

Thanks a ton!  I actually had removed irssi from my uclibc-based LiveCD
build because of this.  Now I should be able to add it back.  Whatever
you come up with on this for Gentoo/FreeBSD will also be needed for
uclibc.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Final proposal: New alias maintainer-needed@g.o or some such (speak now or forever hold your peace ;) )

[Chris Gianelloni]

On Thu, 2005-06-16 at 02:30 +0200, Markus Nigbur wrote:
> - Developer Handbook (which really needs a section about how bugs are 
> treated. 
> I always wanted to write up a draft when I find the time...)

The games team has a "Games Team Bugs FAQ" at games.gentoo.org that we
continue to update with new information.  Having a nice global one would
be cool, for sure.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux


signature.asc
Description: This is a digitally signed message part

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

[Diego 'Flameeyes' Pettenò]

On Thursday 16 June 2005 00:02, Diego 'Flameeyes' Pettenò wrote:
> There are other solutions a part the new virtuals?
Ok just to summarize.

a) getopt_long isn't important right now, FreeBSD 5 already takes care of it, 
if in the future it will be necessary for NetBSD, OpenBSD or DragonFly, it 
will be another issue.

b) most of the packages requiring gettext at runtime already requires it at 
build time atm... the simple thing to do is moving this on runtime on the 
packages which needs when we'll stumble across it

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?
-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


pgpylTysnfeMT.pgp
Description: PGP signature

Re: [gentoo-dev] Final proposal: New alias maintainer-needed@g.o or some such (speak now or forever hold your peace ;) )

[Daniel Drake]

Markus Nigbur wrote:
> Assigning to [EMAIL PROTECTED] and adding the actual fitting herd to CC is 
> the most 
> elegant option, IMHO.
> However we do it, we should really agree on one solution, to get more 
> structure into the chaos.

Here's what I'd propose:

This only applies to new packages, as opposed to version bumps or whatever else:

When an ebuild or ebuild request is posted to bugzilla, the bug wranglers
attempt to find an appropriate herd or developer to assign it to, and the
ebuild is keyworded with EBUILD or REQUEST depending whether an ebuild was
included or not.

If the herd or developer does not want to maintain the package and they feel
that there is another herd or developer where this package would be more
appropriately maintained, then they should reassign it to them.

At any point, if a developer or herd decides that they do not want to maintain
the package at the current time, and there is no more appropriate
herd/developer, then they reassign it to [EMAIL PROTECTED] putting
the most appropriate herd(s)/developer(s) on CC.

Interested developers can then take bugs from the maintainer-needed alias and
reassign to themselves before getting the ebuild included in portage - but the
usual policies still apply, for example if its a web application you'll
probably be asked to join the webapps herd, and if its a kernel then you'll
have to go through the torture chamber and then join our project before adding
the package, etc...

Herds/developers that are CC'd on the maintainer-needed bugs are free to
completely close the bugs if there is a good reason why the package won't be
included in portage at the current time. For example, I'd reject an ebuild for
an external 2.6 kernel module which doesn't work for kernels 2.6.4 and newer,
because we don't support those older kernels at all. (These kind of bugs might
even be closed before it got assigned to maintainer-needed)

Developers can query for open maintainer-needed EBUILD bugs if they are
looking for new packages to maintain, and users can query for open
maintainer-needed REQUEST bugs if they want some ebuild writing practice.

Perhaps a complete list of open maintainer-needed bugs could be added to the
default preset queries..?


Any comments on that?


> - Developer Handbook (which really needs a section about how bugs are 
> treated. 
> I always wanted to write up a draft when I find the time...)

I think we need some real bugzilla documentation that covers both basic usage
and also policies on bugs/resolutions/ownership and what to do if you think
your bug is being ignored. This is also on my todo list but has been for a
long time.

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

Re: [gentoo-dev] use.force support

[Herbie Hopkins]

This is something I've thought about too and I agree that this would be
a useful feature. One possible application of this feature is to
simplify how we handle simd extensions on amd64 (this has been discussed
multiple times). Currently we have the USE flags mmx,sse,3dnow masked on
amd64 because then enable x86 specific assembly in a lot of packages.
Those packages that work on amd64 with the relevent simd extension we
hard-enable on amd64. This has several problems:

1. Users cannot easily disable these features for e.g debugging
purposes.
2. It's not clear to the user that these extensions are being enabled as
emerge -pv shows (-mmx) etc.

Now if we could simply mask the use flags for the packages where it
causes problems and not for the ones that don't we could solve both
these issues.

Herbie.

On Mon, 2005-06-13 at 20:43 -0600, Jason Wever wrote:
> On Mon, 13 Jun 2005 16:40:48 +0200
> Sven Wegener <[EMAIL PROTECTED]> wrote:
> 
> > We just had a short discussion over in #gentoo-portage and the idea of
> > an use.force file for profiles came up.
> 
> One feature that would be more useful (in my honest on Tuesdays
> opinion) for us arch folks is the ability to mask use flags on a
> per-package basis.  Often times use flags will work for 99% of the
> packages they are used in, but the other 1% will not.  Currently the
> workaround is to just make the ebuild ignore that use flag on that arch,
> but there's no real indication to the user that the workaround is
> thwarting their use flag preferences (unless the arch monkey is nice
> enough to put in some einfo love).
> 
> Cheers,


signature.asc
Description: This is a digitally signed message part

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

[Mike Frysinger]

On Thursday 16 June 2005 12:33 am, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 16 June 2005 06:22, Mike Frysinger wrote:
> > tracking packages which need getopt is a waste of time, just force it in
> > your profile/bsd libc/whatever
>
> it's not getopt, it's getopt_long... which is used by few packages.
> well actually freebsd provide it in library in latest releases, aslo if
> it's developed on its own... maybe I can hack a bit the build process to
> have this external as we need.

yes i know the diff between getopt and getopt_long, that doesnt change the 
fact that tracking either is a waste of time
-mike

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Acquiring a deeper understanding of Gentoo

[Mark S Petrovic]

On 15Jun, Mark S Petrovic wrote:
> Is there a principal Gentoo developer in Northern or Southern California
> (preferred) to whom I can pay a visit to gain a deeper understanding of
> who the Gentoo team is, what they are trying to accomplish, and how?

Thank you for the many replies offering help in various forms.  They were
all respectful and speak well of who you are.  With them, I'm sure I
will find what I'm looking for.

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

Re: [gentoo-dev] New Developer: Julien Allanos (dju`)

[Aaron Walker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bryan Oestergaard wrote:
> Hi everybody.
> 
> It's my pleasure to introduce our newest developer, Dju` who hails from
> France. Dju` finished his PHD in computer science last year and has been
> working as a software developer for 6 months. Besides an obvious
> interest in Gentoo Dju` enjoys listening to and playing music.
> 
> Dju` will be helping with web-apps, starting with trac but I'm
> sure he'll soon be busy with other web-apps as well :)

w00t. we definitely need the help.

> Please give him a nice welcome.

Welcome!

- --
Yow!  Are we wet yet?

Aaron Walker <[EMAIL PROTECTED]>
[ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCsXEFC3poscuANHARAqkrAKDOpwGy8WgFMYiRfuoB6bPDJfFehQCdEiCt
yRfkzbomATCvHnJP1G3nKrE=
=MxT6
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Discussion: alternative compatible utilities

[Dan Meltzer]

Well it would be nice to have it all abstracted, wouldn't stablizing a
package get exponetially harder? Not only would each arch need to be
tested, each combination of packages on each arch would need to be
tested, if FEX openpam became usable on linux instead of just
linuxpam, each arch that stableized would now need to say works for
this arch for linuxpam, and works for this arch for openpam, which
would cause lots and lots of keywords mess.

Or am I misunderstanding your post?

On 6/16/05, Luca Barbato <[EMAIL PROTECTED]> wrote:
> Diego 'Flameeyes' Pettenò wrote:
> 
> > Let me explain: on Gentoo/Linux systems, all the base utilities (make, tar,
> > sed, etc etc) are GNUish; on Gentoo/FreeBSD they are BSDish; on 
> > Gentoo/Darwin
> > I don't really know :P
> > This limits a bit the user because to use other kind of utilities it must 
> > use
> > aliases and he can't change, for example, the tar used by portage or by 
> > other
> > scripts.
> >
> 
> Surely it would be interesting for developer that want to make sure
> their code will build in other userspaces w/out switching os,
> and if that won't be so painful, would worth testing it.
> 
> Obviously having it now isn't really needed. Thinking about that when
> committing/updating ebuild would be good.
> 
> ( still I do hate bsd core utils implementations but that is just my
> opinion =) )
> 
> lu
> 
> --
> 
> Luca Barbato
> 
> Gentoo/linux Developer  Gentoo/PPC Operational Leader
> http://dev.gentoo.org/~lu_zero
> 
> --
> gentoo-dev@gentoo.org mailing list
> 
>

-- 
gentoo-dev@gentoo.org mailing list

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] New Developer: Paul Varner (FuzzyRay)

[Michael Cummings]

wait a sec - i've been taking bugs and such from fuzzyray and only now he's a 
dev?? Does that mean I should expect even *more* pain from texas

=:D

welcome officially fuzzyray, promise not to make to many fuzzball jokes ;)

On Wednesday 15 June 2005 09:26 pm, Aaron Walker wrote:
> ?: subkeys.pgp.net: Connection refused
> gpgkeys: HKP fetch error: Connection refused
> Ladies/Gents,
>
> I'd like to introduce a new addition to our team, Paul Varner aka FuzzyRay.
> Paul hails from Dallas, Texas and will be helping out the tools-portage
> herd. He's actually been a dev since the end of May, but is just now
> "official".
>
> Please give him a proper welcome.
> --
> Aaron Walker <[EMAIL PROTECTED]>
> [ BSD | cron | forensics | shell-tools | commonbox | netmon | vim |
> web-apps ]

-- 

-o()o-
Michael Cummings   |#gentoo-dev, #gentoo-perl
Gentoo Perl Dev|on irc.freenode.net 
-o()o-


pgp8du1BjBjZG.pgp
Description: PGP signature

Re: [gentoo-dev] Final proposal: New alias maintainer-needed@g.o or some such (speak now or forever hold your peace ;) )

[Michael Cummings]

If the response is favorable, can you shout it from the rooftops? I have more 
than a few "bugs" that could get better loving in the m-n world than sitting 
hidden under perl/mcummings in bugzilla.

On Thursday 16 June 2005 12:38 am, Lance Albertson wrote:
> I'll be more than happy to mv new-ebuilds maintainer-needed if seemant
> likes the idea. Seems like the two should fit together fine. Let me find
> seemant and see what he thinks since he's kind of in charge of
> bug-wrangler stuff.

-- 

-o()o-
Michael Cummings   |#gentoo-dev, #gentoo-perl
Gentoo Perl Dev|on irc.freenode.net 
-o()o-


pgpZYbr2WW4D2.pgp
Description: PGP signature

Re: [gentoo-dev] bacula needs lovin'!

[Rob Holland]

A few people stepped up to help with this, but nothing visible has
happened. Is work being done on this?

-- 
rob holland - [ [EMAIL PROTECTED] ] - Gentoo Audit Team
[ 5251 4FAC D684 8845 5604  E44F D65C 392F D91B 4729 ]
-- 
gentoo-dev@gentoo.org mailing list

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

[Thomas Matthijs]

* 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
-- 
gentoo-dev@gentoo.org mailing list

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

[Thomas de Grenier de Latour]

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.

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

Re: [gentoo-dev] app-admin/mbr.. what to do...

[Patrick Lauer]

On Thu, 2005-06-16 at 11:13 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Thursday 16 June 2005 10:53, Patrick Lauer wrote:
> > Maybe someone with some scripting skillz could create a list of all
> > "orphaned" packages?
> > (no metadata.xml, no active maintainer, ...)
> I've learned with first-person experience that no metadata doesn't means that 
> a package is orphaned...
ok, but it's still a "bug"
> So maybe it's better said to developers: if you maintain something *please* 
> add a metadata, or update it, so that who looks at bugs know who to ask to.
For that we should have a list of all affected packages I think.

> > Always a drag to see packages getting dropped, but if noone maintains
> > them there's not much that can be done.
> Well maybe we can have a way to define "latest portage version" for removed 
> package (a tag on cvs?) so that someone can prepare a weekly tarball of 
> removed packages waiting for new maintainers or so on.
you mean a repository of removed ebuilds?
I don't know if that is a good idea, but it sure has some uses.
But if I'm not mistaken files can be resurrected from cvs, so they are
not "lost", only less accessible.


Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Acquiring a deeper understanding of Gentoo

[Martin Schlemmer]

On Wed, 2005-06-15 at 22:36 -0500, Michael Tindal wrote:
> Jonathan Smith wrote:
> > M. Edward (Ed) Borasky wrote:
> > 
> >>>I'm not a developer ... and I'm not in California ... but I am a Gentoo
> >>>bigot and I'm certainly willing to help out ... as are most Gentoo
> >>>users/developers.
> >>>[snip]
> > 
> > 
> > I know that I can't speak for all the developers, but I for one am
> > slightly offended by being called a "Gentoo bigot". I work on Gentoo
> > because I love doing it, and I believe it helps people, but if those
> > people use something else (another distro, *BSD, Solaris, OSX, even
> > Windows) and it works for _them_, then so be it...
> > 
> > As for the rest of your email, that information is readily available
> > from the Gentoo Documentation Project, and in a much more readable and
> > detailed format.
> > 
> > -smithj
> 
> It is rather offensive to myself as well, for the reasons detailed
> above.  Please keep such comments to yourself and try to be less
> condescending in your responses in a public forum.
> 

And I am slightly offended by both of you, as he clearly was saying that
_he_ is a Gentoo bigot.  Please reread something 3 or 4 times before
taking offence (and then sleep on it before replying).


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] app-admin/mbr.. what to do...

[Diego 'Flameeyes' Pettenò]

On Thursday 16 June 2005 10:53, Patrick Lauer wrote:
> Maybe someone with some scripting skillz could create a list of all
> "orphaned" packages?
> (no metadata.xml, no active maintainer, ...)
I've learned with first-person experience that no metadata doesn't means that 
a package is orphaned...
So maybe it's better said to developers: if you maintain something *please* 
add a metadata, or update it, so that who looks at bugs know who to ask to.

> Always a drag to see packages getting dropped, but if noone maintains
> them there's not much that can be done.
Well maybe we can have a way to define "latest portage version" for removed 
package (a tag on cvs?) so that someone can prepare a weekly tarball of 
removed packages waiting for new maintainers or so on.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/



pgpgAgPnuPqm5.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] app-admin/mbr.. what to do...

[Patrick Lauer]

On Fri, 2005-06-17 at 01:41 +0900, Chris White wrote:
> I just saw a bug report flow by for app-admin/mbr and looked for maintainers. 
>  I found this:
> ChangeLog: 1 manson, 1 woodchip
> from jeeves.  Now, I think those people are retired, or I need to get out 
> more (or both).  So what to do with said package.  It looks pretty old and 
> this user wants it bumped so...  I'd do it but I have no solid test method 
> and I really don't like putting out packages without one.
I think this problem is not limited to this package.
Maybe someone with some scripting skillz could create a list of all
"orphaned" packages?
(no metadata.xml, no active maintainer, ...)

> If anyone is interested, the bug number is here:
> http://bugs.gentoo.org/show_bug.cgi?id=96254
> Otherwise we should do something about the fate of this package.
Either drop it or find a maintainer I guess. 
Always a drag to see packages getting dropped, but if noone maintains
them there's not much that can be done.

Patrick
-- 
Stand still, and let the rest of the universe move


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Discussion: alternative compatible utilities

[Luca Barbato]

Diego 'Flameeyes' Pettenò wrote:

> Let me explain: on Gentoo/Linux systems, all the base utilities (make, tar, 
> sed, etc etc) are GNUish; on Gentoo/FreeBSD they are BSDish; on Gentoo/Darwin 
> I don't really know :P
> This limits a bit the user because to use other kind of utilities it must use 
> aliases and he can't change, for example, the tar used by portage or by other 
> scripts.
> 

Surely it would be interesting for developer that want to make sure
their code will build in other userspaces w/out switching os,
and if that won't be so painful, would worth testing it.

Obviously having it now isn't really needed. Thinking about that when
committing/updating ebuild would be good.

( still I do hate bsd core utils implementations but that is just my
opinion =) )

lu

-- 

Luca Barbato

Gentoo/linux Developer  Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] app-admin/mbr.. what to do...

[Chris White]

I just saw a bug report flow by for app-admin/mbr and looked for maintainers.  
I found this:

ChangeLog: 1 manson, 1 woodchip

from jeeves.  Now, I think those people are retired, or I need to get out more 
(or both).  So what to do with said package.  It looks pretty old and this user 
wants it bumped so...  I'd do it but I have no solid test method and I really 
don't like putting out packages without one.

If anyone is interested, the bug number is here:

http://bugs.gentoo.org/show_bug.cgi?id=96254

Otherwise we should do something about the fate of this package.

Chris White


pgplIAKAjkvAR.pgp
Description: PGP signature

[gentoo-dev] New Developer: Julien Allanos (dju`)

[Bryan Oestergaard]

Hi everybody.

It's my pleasure to introduce our newest developer, Dju` who hails from
France. Dju` finished his PHD in computer science last year and has been
working as a software developer for 6 months. Besides an obvious
interest in Gentoo Dju` enjoys listening to and playing music.

Dju` will be helping with web-apps, starting with trac but I'm
sure he'll soon be busy with other web-apps as well :)

Please give him a nice welcome.

Regards,
Bryan Østergaard

-- 
gentoo-dev@gentoo.org mailing list