[gentoo-dev] python module

[Rene Zbinden]

Hi

I want to write an ebuild, that installs a python module. After unpacking the 
zipfile there is only one module module.py. What is the best way to install 
that package. Is there an eclass that I can use?

Thanks in advance.
rene
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Valid Profiles

[Mike Frysinger]

On Monday 01 August 2005 10:22 am, Mike Frysinger wrote:
> On Monday 01 August 2005 10:15 am, Chris Gianelloni wrote:
> > On Sun, 2005-07-31 at 10:59 -0400, Ned Ludd wrote:
> > > - x86/linux24 (deprecated)
> > > - x86/linux26 (deprecated)
> >
> > What should we do with deprecated profiles?  Should we still be checking
> > against them?
> >
> > I would think we would, but what do the rest of you think?
>
> speaking of which, i had an idea to clean up all that crap, i just forgot
> to post it a while back ...
>
> gentoo-x86/profiles/ $ tree obsolete
> obsolete
> 
> then we can punt all the flat profiles and if a user needs an upgrade path,
> they can symlink to these in the meantime

well, no one has said anything about this so i'll go ahead and punt all 
remaining flat profiles and add this obsolete tree once 2005.1 is released

in other words, these people will be served:
default-alpha-1.4
default-alpha-2004.0
default-macos-10.3
default-macos-10.4
default-ppc
default-ppc-1.0
default-ppc-1.4
default-ppc-2004.0
default-ppc-2004.1
default-ppc-2004.2
default-ppc-2004.3
default-ppc64-2004.2
default-ppc64-2004.3
default-sparc-1.4
default-sparc-2004.0
default-sparc64-1.4
default-sparc64-2004.0
default-x86-2004.2
default-x86-obsd-2004
gcc33-sparc64-1.4
hardened-x86-2004.0
-mike
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New global USE flag: logrotate

[Tom Martin]

On Tue, Aug 02, 2005 at 08:58:14PM +0300, Alin Nastac <[EMAIL PROTECTED]> wrote:
> It also controls whether a cron script that use native squid log
> rotation is installed or not. You cannot select your preferred rotation
> mechanism (logrotate or cron job) through other way than useflags.

If it's being used like that there, I think I'll just stick to creating
another local flag. It's a pretty reasonable compromise, considering
some of the criticisms in this thread and the other.

Tom

-- 
Tom Martin, http://dev.gentoo.org/~slarti
AMD64, net-mail, shell-tools, vim, recruiters
Gentoo Linux


pgpPFEKbtvTw8.pgp
Description: PGP signature

[gentoo-dev] IMPORTANT: Network maintenance

[Lance Albertson]

Hey all,

All our servers located at IU (which includes a few rsync servers and
toucan) will have a network outage of approximately one hour tomorrow
(Aug 4) between 0600-0700 CDT (1100-1200 UTC). Hopefully all goes well
and we don't notice them gone that long.

Cheers,

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Base/use.defaults, eds as a X86 default use

[Petteri Räty]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Gianelloni wrote:
> 
>> Course we all know that a simple -eds will fix the problem, I guess 
>> I'm just
>> looking for a why  it was enabled by default?
> 
> 
> Because gnome is enabled by default, and eds/gstreamer are really 
> needed for a properly working default Gnome configuration.
> 

Maybe one day we will have those use flag groups. This really was a
problem to me because emerge -uDpvt does not know how to show PDEPENDS
so I only had new packages in the listing. I just fear that this might
cause a lof of confusion among the users. Maybe someone should send a
mail to gentoo-users.

Regards,
Petteri Räty (Betelgeuse)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC8SX4cxLzpIGCsLQRAu8tAJ98K7Z23sSIYIJPTgO53f4wJDwZ5QCeIfGU
HVuLqjLll0gIcyrTYdoJYPY=
=ga72
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: where goes Gentoo?

[Sven Köhler]

>>>In my humble opinion, Gentoo is missing too many points to be an
>>>enterprise Linux.  We commit to a live tree.  We don't have true QA,
>>>testing or tinderbox.  We don't have paid staff, alpha/beta/rc cycles.
>>>We don't really have product lifecycles, since we don't generally
>>>backport fixes to older versions, requiring instead for people to
>>>update to a more recent release.  We don't have, and probably will
>>>never be able to offer, support contracts.  We support as wide a range
>>>of hardware as the upstream kernel, plus hardware that requires
>>>external drivers; we don't have access to a great deal of the hardware
>>>for which we provide drivers.  We understand when real life gets in
>>>the way of bug-fixing, because all our developers are volunteers.
>>
>>QA is a problem. Bugs get fixed, but often they are only fixed in ~x86
>>versions, not in the stable x86 series. For example baselayout: there
>>are lot of ~x86 - miles ahead of that is marked x86. Maintainers think,
>>it's sufficient to only fix the most recent version. How do they
>>legitimate that?
> 
> This one is easy.  A stable package's ebuild should not change.  Period.

I agree with you there - though sometimes, stable ebuilds are changed -
even without changing the version-number.

> To "fix" the stable version, means that a new revision of the latest
> stable version would need to be made, and that revision would need to be
> tested, before it would go to stable.  The only real exception to this
> is security bugs.  Also, in many cases, the bug in question requires
> changes that are simply not feasible easily in the current stable
> version, but quite easy in the latest version.  It really boils down to
> this:  If you're having an issue with a package in Gentoo and it is
> fixed in the latest ~arch version, then you should *use* the ~arch
> version (remember, it doesn't mean "unstable" it means "testing") and
> you should report back to the maintainers that this is working for you
> so that they can get it moved into stable quicker.  We don't have the
> staff or the time to backport every fix to every stable version.
> Remember that in many cases the "latest stable" version varies between
> architectures.

I chose baselayout for a particular reason. There is baselayout 1.9,
1.11 and 1.12. (i think there was 1.10 too - some time ago - perhaps)

I i reported bugs - as usual - but the bug was fixed for 1.11 or 1.12 (i
can't remeber, it was about a year ago). The problem: the fix was not
backported to 1.9 (which was stable at that time). Since baselayout is a
very important part of Gentoo, i didn't think that it would be a good
idea, to upgrade my x86-version 1.9 to a ~x86-version 1.11. So i would
have expected that such changes would go into a new 1.9-version which
could have become stable after some testing - but they didn't. So
patches the scripts manually - well, and easy task, although i had to
pay attention so they my changes weren't overwritten.


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: where goes Gentoo?

[River Yan]

I think it's value is that gentoo is for the developers.
: )-- Riverfor [A chinese, a gentoo user, a programmer]

[gentoo-dev] Re: where goes Gentoo?

[Duncan]

Chris Gianelloni posted <[EMAIL PROTECTED]>,
excerpted below,  on Wed, 03 Aug 2005 09:39:07 -0400:

>> Administrating a Gentoo system takes time - much time, but ...
> 
> This is something that I think most people forget.  Running Gentoo makes
> you a Linux Systems Administrator.  Sure, you're only being the
> administrator for your machine, which might only have one user, but you're
> the admin.  With some of the other distributions, *they* are the admin,
> and you're just a user.  They make assumptions for you and limit what you
> can and cannot do (without an enormous amount of work to bypass their
> limits).  This is especially apparent in the many cases where users expect
> Gentoo to do everything for them, when it doesn't.

I've found myself emphasizing this same point a number of times.  There
are general system users that don't care /what/ they are on.  Those are
/just/ users.  However, by definition, /Gentoo/ user == sysadmin,
full-stop (period, for those USians not familiar with international
English, "full-stop" seems to me to convey the idea better).  You mention
the lack of limits, and Sven mentioned the time it takes, but my emphasis
tends to be on the responsibilities of the job.  A good sysadmin invests
the time and energy necessary to keep a healthy system, known vuln and
exploit free, but more than that, "clean" and simple, because (s)he
realizes the consequences of a failure to do so.  A good sysadmin knows a
fair amount about how their system works, in ordered to do that.  A good
sysadmin enjoys the job, or finds other work.

Gentoo makes being a good sysadmin easy.  However, by the same token,
because it assumes that admin is in place, it tends to make being an
ordinary "user" on an admin-less Gentoo system very difficult.  Those that
don't like being sysadmins, really should be looking at a distribution
that, as you said, really takes on much of the sysadmin duties as part of
the services provided by the distribution.   The best Gentoo user, then,
because being a Gentoo user by definition means being a sysadmin, truly
enjoys both the responsibilities and privileges of system administration. 
Again, if that's /not/ the case, one really should be reexamining their
choice of Gentoo, as it's really not the best fit distribution available
for those who'd really rather be doing something other than system
administration.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Modular X plans

[Diego 'Flameeyes' Pettenò]

On Wednesday 03 August 2005 07:41, Donnie Berkholz wrote:
> If you want your patch back in, you will _need_ to file it upstream and
> have it committed before we will re-add it.
While I generally agree with this "the closer to upstream, the better", I hope 
that this can be a bit more easy for compile-fixes for arches. Taking this 
upstream can need a bit of time as the problem can manifests just on a 
specific architecture (or os, thinking about g/fbsd) and there can be noone 
on upsteram to take care of that at the moment we need the fix.

I'm wondering about this because latest two snapshot from Xorg doesn't compile 
at all under G/FBSD.. while having it modular will probably resolve the issue 
(at that point we will just p.mask or not keyword a package until it's fixed, 
for example xconsole that doesn't work on fbsd), if the problem manifests in 
one of the core packages needs to be fixed ASAP.

[Unfortunately our "parent project" FreeBSD doesn't seem to send always the 
fixes upstream, that's why there can be problems that we need to address and 
report upstream at the same time]

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


pgpNlCUQPhXRJ.pgp
Description: PGP signature

Re: [gentoo-dev] Re: where goes Gentoo?

[Chris Gianelloni]

On Wed, 2005-08-03 at 13:55 +0200, Sven Köhler wrote:
> > In my humble opinion, Gentoo is missing too many points to be an
> > enterprise Linux.  We commit to a live tree.  We don't have true QA,
> > testing or tinderbox.  We don't have paid staff, alpha/beta/rc cycles.
> > We don't really have product lifecycles, since we don't generally
> > backport fixes to older versions, requiring instead for people to
> > update to a more recent release.  We don't have, and probably will
> > never be able to offer, support contracts.  We support as wide a range
> > of hardware as the upstream kernel, plus hardware that requires
> > external drivers; we don't have access to a great deal of the hardware
> > for which we provide drivers.  We understand when real life gets in
> > the way of bug-fixing, because all our developers are volunteers.
> 
> QA is a problem. Bugs get fixed, but often they are only fixed in ~x86
> versions, not in the stable x86 series. For example baselayout: there
> are lot of ~x86 - miles ahead of that is marked x86. Maintainers think,
> it's sufficient to only fix the most recent version. How do they
> legitimate that?

This one is easy.  A stable package's ebuild should not change.  Period.
To "fix" the stable version, means that a new revision of the latest
stable version would need to be made, and that revision would need to be
tested, before it would go to stable.  The only real exception to this
is security bugs.  Also, in many cases, the bug in question requires
changes that are simply not feasible easily in the current stable
version, but quite easy in the latest version.  It really boils down to
this:  If you're having an issue with a package in Gentoo and it is
fixed in the latest ~arch version, then you should *use* the ~arch
version (remember, it doesn't mean "unstable" it means "testing") and
you should report back to the maintainers that this is working for you
so that they can get it moved into stable quicker.  We don't have the
staff or the time to backport every fix to every stable version.
Remember that in many cases the "latest stable" version varies between
architectures.

> And yes, Gentoo does not backport patches to older version. But is it
> Gentoo's responsibility? If there's a bug in Postgresql 7.x and 8.x, and
> the PostgreSQL people only fix it 8.x-series - well: Debian and Redhat
> will backport the patches propably. They is a big reason why all the
> distrubutions with precompiled packages do that:
> - the updates has to be binary compatible with the old one

I don't feel that this is our responsibility.  While we sometimes do
backport patches, we just don't have the manpower to make it policy.

> Gentoo doesn't suffer from that limitation. Gentoo offers ways to
> migrate a system from openssl 0.9.6 to openssl 0.9.7 for example. Other
> distributions doesn't offer that - although they could with better
> package managers.

Right.

> Administrating a Gentoo system takes time - much time, but ...

This is something that I think most people forget.  Running Gentoo makes
you a Linux Systems Administrator.  Sure, you're only being the
administrator for your machine, which might only have one user, but
you're the admin.  With some of the other distributions, *they* are the
admin, and you're just a user.  They make assumptions for you and limit
what you can and cannot do (without an enormous amount of work to bypass
their limits).  This is especially apparent in the many cases where
users expect Gentoo to do everything for them, when it doesn't.

> ... writing my own packages for - let's say Redhat - takes more time
> than writing an ebuild for Gentoo. If you have to maintain a system with
> very special software, i would recomm Gentoo.

I would agree with you.  Professionally, I work on Red Hat.  I have to
build custom RPMs on a daily basis, and I can say that the simple syntax
of ebuilds is a tremendous advantage.

> Just some days ago, someone reinstalled a Server where we had PostGreSQL
> 8.0 running. He chose to install Debian - which offers PostGreSQL 7.4 -
> so what did he do? He compiled PostGreSQL 8.0 himself, to be abled to
> use our existing database. This will become hell the more packages you
> have to compile on you own. Any configure-make-install-like package,
> Perl-Module, etc... can be easy installed by using an ebuild.

You aren't "supposed" to compile packages on your own on Debian.  You're
supposed to make your own DEB package and install that.  Otherwise, you
are working outside the package manager.  This is no different than on
Gentoo, just for many people, an ebuild is easier to write than creating
a DEB/RPM.

> In addition Gentoo is the only distribution i know, that supports
> installing multiple Java-version etc...
> A must-have for every real java-developer.

Agreed.  This is also very true for proprietary applications that rely
on java.

> So i'd say: use Debian, if you have a relativly normal system to
> maintain, use Gentoo if you have the t

Re: [gentoo-dev] Food For Thought: Bugzilla Localization?

[Ciaran McCreesh]

On Wed, 3 Aug 2005 16:17:38 +0900 Chris White <[EMAIL PROTECTED]>
wrote:
| 2) Can people be brought on board to localize bugzilla, as well as
| provide translation of non-english bugs.

No non-English bugs for anything except docs please. It's hard enough
to get the information we need out of bugs as it is...

I'm pretty sure that providing a translated would encourage more
non-English bug submissions too...

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] The dreaded debug use flag/eclass

[Danny van Dyk]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mike Frysinger schrieb:
| On Wednesday 03 August 2005 07:16 am, Martin Schlemmer wrote:
|
|>On Tue, 2005-08-02 at 09:22 -0400, Mike Frysinger wrote:
|>
|>>On Monday 01 August 2005 10:43 pm, Danny van Dyk wrote:
|>Last time I checked, only --without-pic or --disable-static disable
|>compiling twice.
|
|
| my tests show that with libtool 1.5.18 --without-pic doesnt change
| anything ... obviously --disable-static changes things same as
| --disable-shared would :P
|
| maybe i just did it wrong ... i used imlib2-1.2.0 as a reference
| -mike
According to libtool's source, it only compiles things twice if it shall
build 'old-libs' ($build_old_libs=yes) _and_ shared libraries. If it
builds 'libtool-libs' ($build_libtool_libs=yes) it uses the same object
files for both the static and the shared library.

But I might be comletely wrong... libtool's internals are sometimes so
confusing :-/

Danny
- --
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC8MJ7aVNL8NrtU6IRAh5OAKCLThNfuQH+vq8hCKZUxZZhz/8zuwCcD61l
rBB/S+0uH0MiRt5lNZj3eMo=
=gBww
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] The dreaded debug use flag/eclass

[Mike Frysinger]

On Wednesday 03 August 2005 07:16 am, Martin Schlemmer wrote:
> On Tue, 2005-08-02 at 09:22 -0400, Mike Frysinger wrote:
> > On Monday 01 August 2005 10:43 pm, Danny van Dyk wrote:
> > > Mike Frysinger schrieb:
> > > |>your USE=pic example is wrong, it does not change CFLAGS (and if your
> > > |>package does, it is broken)
> > >
> > > chillispot at least is not wrong. If USE="pic" is set, it compiles
> > > _only with_ -fPIC, ommiting to compile files twice and effectivly
> > > telling libtool not to produce a normal static library.
> >
> > just to review ... `use_with pic` should never be used because if you
> > dont have 'pic' in your USE flags, the ebuild will run `./configure
> > --without-pic` ... that means libtool will try to produce shared and
> > static libraries with object files which were built without PIC ... on
> > many arches (like amd64), the linker will abort
> >
> > btw, where do you get this information ?  my tests show that libtool
> > still compiles all files twice even though --with-pic was used ...
>
> Last time I checked, only --without-pic or --disable-static disable
> compiling twice.

my tests show that with libtool 1.5.18 --without-pic doesnt change 
anything ... obviously --disable-static changes things same as 
--disable-shared would :P

maybe i just did it wrong ... i used imlib2-1.2.0 as a reference
-mike
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] New categories: dev-php4 and dev-php5

[Stuart Herbert]

Hi,

As the feedback from my overlay for mixed PHP4/PHP5 support has been 
entirely positive, I'd like to move this work into the Portage tree 
later this week.


This will create two new top-level categories:
- dev-php4 for PHP4 extensions
- dev-php5 for PHP5 extensions

PHP extensions are additional APIs for PHP, and are compiled against the 
PHP scripting engine.


After a short period of transition, the dev-php/PECL-* packages (and two 
others) will be marked as moved to the corresponding packages in dev-php4.


Best regards,
Stu

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: where goes Gentoo?

[Sven Köhler]

> This is kinda bloggish, because it's basically a transcription of an
> IRC monologue.  My apologies if it's hard to follow...  Nonetheless,
> I'm interested in how other developers feel on the topics I bring up
> below.

Though i'm a developer, i'm not a gentoo-developer.

> In my humble opinion, Gentoo is missing too many points to be an
> enterprise Linux.  We commit to a live tree.  We don't have true QA,
> testing or tinderbox.  We don't have paid staff, alpha/beta/rc cycles.
> We don't really have product lifecycles, since we don't generally
> backport fixes to older versions, requiring instead for people to
> update to a more recent release.  We don't have, and probably will
> never be able to offer, support contracts.  We support as wide a range
> of hardware as the upstream kernel, plus hardware that requires
> external drivers; we don't have access to a great deal of the hardware
> for which we provide drivers.  We understand when real life gets in
> the way of bug-fixing, because all our developers are volunteers.

QA is a problem. Bugs get fixed, but often they are only fixed in ~x86
versions, not in the stable x86 series. For example baselayout: there
are lot of ~x86 - miles ahead of that is marked x86. Maintainers think,
it's sufficient to only fix the most recent version. How do they
legitimate that?

And yes, Gentoo does not backport patches to older version. But is it
Gentoo's responsibility? If there's a bug in Postgresql 7.x and 8.x, and
the PostgreSQL people only fix it 8.x-series - well: Debian and Redhat
will backport the patches propably. They is a big reason why all the
distrubutions with precompiled packages do that:
- the updates has to be binary compatible with the old one

Gentoo doesn't suffer from that limitation. Gentoo offers ways to
migrate a system from openssl 0.9.6 to openssl 0.9.7 for example. Other
distributions doesn't offer that - although they could with better
package managers.

Also i've had too many SuSE- or Redhat-systems in the past that were
unsupported because RedHat and SuSE decide, to stop supplying updates
for older version of their distribution. So what am i supposed to do in
that case? Updating the whole distribution causing me troubles to
migrate everything to the new version (apache2 instead of apache 1.3, etc.)

With Gentoo, this is usually done as time goes by - though you have to
be very careful sometimes.

Administrating a Gentoo system takes time - much time, but ...

... writing my own packages for - let's say Redhat - takes more time
than writing an ebuild for Gentoo. If you have to maintain a system with
very special software, i would recomm Gentoo.

> I like the idea of Gentoo on alternative arches and in embedded
> environments.  Not because I want Sony to start using Gentoo on
> walkmans, but purely because the idea of running Linux on a PDA is
> cool.  I'd like Gentoo to be a place where neat things are developed.
> If RH or SuSE (or another for-profit Linux vendor) wants to take some
> of those developments and use them to make a profit, that's fine with
> me.  We're over here having fun.

I like Gentoo, since everything is compiled - which offers much
flexibility, that precompiled packages don't offer.

Just some days ago, someone reinstalled a Server where we had PostGreSQL
8.0 running. He chose to install Debian - which offers PostGreSQL 7.4 -
so what did he do? He compiled PostGreSQL 8.0 himself, to be abled to
use our existing database. This will become hell the more packages you
have to compile on you own. Any configure-make-install-like package,
Perl-Module, etc... can be easy installed by using an ebuild.

In addition Gentoo is the only distribution i know, that supports
installing multiple Java-version etc...
A must-have for every real java-developer.

> Also I find it amusing when people say that Gentoo exists for the
> users.  I think that is wrong.  Gentoo exists for the *developers*.
> It's our playground, and it's the reason we use a live tree rather
> than switching to an actually sane approach.  The users are cool
> because they point out bugs, help solve problems on bugzilla, suggest
> enhancements, provide patches, and notify us of package updates.
> Sometimes they become developers.  But the truth is that Gentoo sees
> improvement and maintenance in the areas that appeal to the
> developers.  And that is why Gentoo exists for the developers first,
> the users second.

by using Gentoo, you learn much about Linux (the Kernel) and all the
nice little software that makes it a usable OS. Somewhere on the net,
there was page about Gentoo and Debian. The conslusion was, that Gentoo
is a great distribution to learn, and Debian is a stable work-horse.
Well, Debian is stable workhorse - as long as you don't have a very
special configuration. AFAIK, Debian doesn't drop support for their
distributions that fast - and they doen't release a new distribution
every few months (like SuSE does).

So i'd say: use Debian, if you have a rel

Re: [gentoo-dev] Base/use.defaults, eds as a X86 default use

[Sebastian Bergmann]

Chris Gianelloni schrieb:
> Because gnome is enabled by default, and eds/gstreamer are really 
> needed for a properly working default Gnome configuration.

 Not really. I have a properly working (non-default, true) Gnome
 configuration with USE=-eds.

-- 
Sebastian Bergmann  http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Base/use.defaults, eds as a X86 default use

[Chris Gianelloni]

On Aug 3, 2005, at 5:16 AM, Tsunam wrote:

Would like to first thank Carsten Lohrke, Carlo, for helping me  
find the exact

location of the mysterious appearance of eds to a on default status.

*story time* After a recent emerge sync, I came face to face with  
quite a
pecular list of packages that wanted to be installed. As I have - 
gnome in my
make.conf it just was confusing. Until I did a emerge -avuDt world.  
I noticed
that gaim had turned up with a eds use flag. Evolution Data server  
seems like
something that should not be in the base/use.defaults, at least as  
far as I can
tell. Anything that can of course make use of eds, will require the  
new packages
as dependencies. For those not using gnome, this can be a bit of a  
pain to hunt

down and see what is going on.


Well, use.defaults has nothing to do with it.  It was the addition to  
default-linux/$arch/make.defaults that most likely caused this.   
There is a reason for it, too.  Our default configuration must work  
properly.  Well, Gnome was not working properly due to the missing  
eds and gstreamer USE flags.  I added these flags at the request of  
the Gnome team, as they had thought that adding them to use.defaults  
accomplished the job, when it did not.


Course we all know that a simple -eds will fix the problem, I guess  
I'm just

looking for a why  it was enabled by default?


Because gnome is enabled by default, and eds/gstreamer are really  
needed for a properly working default Gnome configuration.



For reference as to the start of this inquiry:
http://bugs.gentoo.org/show_bug.cgi?id=101129


I probably should have sent a note to -dev about this change when I  
did it, but I was in a rush of bug-fixes for 2005.1, so I apologize.


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



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] The dreaded debug use flag/eclass

[Martin Schlemmer]

On Tue, 2005-08-02 at 09:22 -0400, Mike Frysinger wrote:
> On Monday 01 August 2005 10:43 pm, Danny van Dyk wrote:
> > Mike Frysinger schrieb:
> > |>your USE=pic example is wrong, it does not change CFLAGS (and if your
> > |>package does, it is broken)
> >
> > chillispot at least is not wrong. If USE="pic" is set, it compiles _only
> > with_ -fPIC, ommiting to compile files twice and effectivly telling
> > libtool not to produce a normal static library.
> 
> just to review ... `use_with pic` should never be used because if you dont 
> have 'pic' in your USE flags, the ebuild will run `./configure 
> --without-pic` ... that means libtool will try to produce shared and static 
> libraries with object files which were built without PIC ... on many arches 
> (like amd64), the linker will abort
> 
> btw, where do you get this information ?  my tests show that libtool still 
> compiles all files twice even though --with-pic was used ...

Last time I checked, only --without-pic or --disable-static disable
compiling twice.


-- 
Martin Schlemmer



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

Re: [gentoo-dev] Food For Thought: Bugzilla Localization?

[Simon Stelling]

Xavier Neys wrote:

Looks like we'd need to pass bugs through several filters:
bug-translators=>bug-wranglers=>assigned


I don't like that idea, it'd only lead to even more duplicates.

Regards,

--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Base/use.defaults, eds as a X86 default use

[Tsunam]

Would like to first thank Carsten Lohrke, Carlo, for helping me find the exact
location of the mysterious appearance of eds to a on default status.

*story time* After a recent emerge sync, I came face to face with quite a
pecular list of packages that wanted to be installed. As I have -gnome in my
make.conf it just was confusing. Until I did a emerge -avuDt world. I noticed
that gaim had turned up with a eds use flag. Evolution Data server seems like
something that should not be in the base/use.defaults, at least as far as I can
tell. Anything that can of course make use of eds, will require the new packages
as dependencies. For those not using gnome, this can be a bit of a pain to hunt
down and see what is going on. 

Course we all know that a simple -eds will fix the problem, I guess I'm just
looking for a why  it was enabled by default?

For reference as to the start of this inquiry:
http://bugs.gentoo.org/show_bug.cgi?id=101129 

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Food For Thought: Bugzilla Localization?

[Xavier Neys]

Chris White wrote:

Ok, I'm just going to sort of throw this into the mix, so here goes:

I was talking with the -doc people about the bugzilla doc I was working on.  I 
wanted to try and get rid of the pictures, and go with something more ascii 
representative for ease of translation.  But then someone brought up the 
obvious point that our bugzilla is a non-english speaking language bugzilla.  
This brings in mind the issue of how to handle bugs that non-english users want 
solved.  A couple of ideas came to mind:


Good news. It will make the guide easier to read, to translate and to download 
(it weighs as much as 3 full handbooks at the moment).



1) Are there official gentoo i18n groups, and if so, do they have their own 
bugzilla.  If so, maybe we can link to them from the non-bugzilla site, and the 
people their can transition non-english bugs over to standard bugzilla.

2) Can people be brought on board to localize bugzilla, as well as provide 
translation of non-english bugs.

3) Somewhat similiar to 2, explain to users what the english fields mean, and 
have them fill it out in their own language, then have someone come by and 
translate it for the developers.

While I don't have quite all the answers here, I'm wondering if someone has a 
viable solution to this somewhat obscure issue.  Thanks.

Chris White


A translated bugzie howto would be most useful but I doubt a localised 
bugs.g.o would help. IMHO, it will generate more bugs entirely not in English.

Looks like we'd need to pass bugs through several filters:
bug-translators=>bug-wranglers=>assigned

http://bugs.gentoo.org/show_bug.cgi?id=99929 would have to be solved first btw.


Cheers,
--
/  Xavier Neys
\_ Gentoo Documentation Project
/  French & Internationalisation Lead
\  http://www.gentoo.org/doc/en
/\
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Food For Thought: Bugzilla Localization?

[Simon Stelling]

Hi,

Chris White wrote:

2) Can people be brought on board to localize bugzilla, as well as provide 
translation of non-english bugs.

3) Somewhat similiar to 2, explain to users what the english fields mean, and 
have them fill it out in their own language, then have someone come by and 
translate it for the developers.


While it'd be surely a nice idea to translate the field description, I 
don't think it's a good idea to have non-english bug reports. I'm native 
German speaker, and whenever I see German compilation errors I'm like 
"WTF??". I really can't figure out what it's all about. With english 
error messages, it's just clear.
I don't know what it's like in other languages, but at least for German, 
it's PITA to translate technical terms, as many of the words simply 
don't exist. Most people just mix up German and English, and it works 
quite well. Also, I think most people speak at least broken English, or 
they just use google translations/babelfish & co. Translating bugs is 
just a waste of time to me. And having a localized bugzilla with a fat 
note "Please write your bug report in English!" is just ridiculous.


Regards,

--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Food For Thought: Bugzilla Localization?

[Sven Vermeulen]

On Wed, Aug 03, 2005 at 04:17:38PM +0900, Chris White wrote:
> 1) Are there official gentoo i18n groups, and if so, do they have their own 
> bugzilla.  If so, maybe we can link to them from the non-bugzilla site, and 
> the people their can transition non-english bugs over to standard bugzilla.

Nope (to your first question). We don't have a real i18n crew yet. It might
be a good idea for form one; we do have good support for i18n generally
(package maintainers are using the LINGUAS and the documentation has
references to locales and such) but an expertise group can probably improve
the distribution (for instance by adding the necessary man-pages-${LANG}
ebuilds, etc.).

> 2) Can people be brought on board to localize bugzilla, as well as provide 
> translation of non-english bugs.

I'm not in favor of having a non-English official bugzilla. To much
resources to put in it; I'd rather use translation teams to continuously
keep translating interesting stuff, like documentation but also help with
the localisation of Portage if that ever comes this far.

Translating bugs is such a waist of resources...

Wkr,
  Sven Vermeulen

-- 
  Documentation project leader - Gentoo Foundation Trustee

  The Gentoo Project   <<< http://www.gentoo.org >>>


pgptTXX1bxyTO.pgp
Description: PGP signature

[gentoo-dev] Food For Thought: Bugzilla Localization?

[Chris White]

Ok, I'm just going to sort of throw this into the mix, so here goes:

I was talking with the -doc people about the bugzilla doc I was working on.  I 
wanted to try and get rid of the pictures, and go with something more ascii 
representative for ease of translation.  But then someone brought up the 
obvious point that our bugzilla is a non-english speaking language bugzilla.  
This brings in mind the issue of how to handle bugs that non-english users want 
solved.  A couple of ideas came to mind:

1) Are there official gentoo i18n groups, and if so, do they have their own 
bugzilla.  If so, maybe we can link to them from the non-bugzilla site, and the 
people their can transition non-english bugs over to standard bugzilla.

2) Can people be brought on board to localize bugzilla, as well as provide 
translation of non-english bugs.

3) Somewhat similiar to 2, explain to users what the english fields mean, and 
have them fill it out in their own language, then have someone come by and 
translate it for the developers.

While I don't have quite all the answers here, I'm wondering if someone has a 
viable solution to this somewhat obscure issue.  Thanks.

Chris White


pgpvC0LFY8Hi4.pgp
Description: PGP signature