Re: [gentoo-dev] New Developer: Jonathan Smith (smithj)

[Diego 'Flameeyes' Pettenò]

On Tuesday 14 June 2005 02:59, Mike Doty wrote:
> Introducing our newest victim^H^H^H^H^H^Hdev
This time at least someone who is interested in Gentoo/FreeBSD (and helped out 
with a couple of desktop-misc bugs about OpenPAM helping us and AMD64.. well 
us and us.. I feel confused...).

Welcome aboard Jonathan!

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

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



pgpJBVBkkskwX.pgp
Description: PGP signature

Re: [gentoo-dev] use.force support

[Diego 'Flameeyes' Pettenò]

On Tuesday 14 June 2005 04:43, Jason Wever wrote:
> 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.
+1 for this, from the Gentoo/FreeBSD team :P

We also have similar problems because sometimes there are supports which just 
works for some packages because the same useflag enables other things we 
can't support.
Just for example, xorg-x11's pam flag load to compilation failures on OpenPAM 
systems (yeah I should work around that but I don't know the server too much, 
also if lately I'm having troubles..) but the rest of the pam support is 
usually ok.

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

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



pgplnh3imzaxj.pgp
Description: PGP signature

Re: [gentoo-dev] intention for kde-themes eclass

[Michael Cummings]

Is this even pursuable given the direction KDE itself is taking? Not meant as 
a nock (specially not after someone brought up a g-cpan-esque clone:) but I 
know in 3.4.0 that you can install new wallpapers live from kde-org with an 
already integrated single-click. That and in following the developer blogs, 
it seems to be intended that by the time 4.0 rolls out that functionality is 
going to spread to other areas. I am by no means knocking the idea, just 
playing devil's twin brother advocate :)

On Tuesday 14 June 2005 12:57 am, Shyam Mani wrote:
> ?: subkeys.pgp.net: Connection refused
> gpgkeys: HKP fetch error: Connection refused
>
> On 06/14/2005 04:03 PM, Chris White wrote:
> > 1) get the general skeletal eclass file going
> > 2) work with multilib
> > 3) integrating with kde eclasses
>
> Would it be easier for you chaps to write up something like gnome-art?
> That way, the user can preview, download and install *any* of the
> themes/splashscreens/whatnots from kde-look.org
>
>
> --
> Shyam Mani | <[EMAIL PROTECTED]>
> docs-team  | http://gdp.gentoo.org
> GPG key| 0xFDD0E345

-- 

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


pgpFKpMikDhJr.pgp
Description: PGP signature

Re: [gentoo-dev] intention for kde-themes eclass

[Diego 'Flameeyes' Pettenò]

On Tuesday 14 June 2005 11:22, Michael Cummings wrote:
> know in 3.4.0 that you can install new wallpapers live from kde-org with an
> already integrated single-click
The KNewStuff is great but it installs in home directory.. I think it's simple 
to replicate this using portage instead of using the KNewStuff, for example 
to spread the same setup over different machines.

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

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



pgp04waMhLXE4.pgp
Description: PGP signature

Re: [gentoo-dev] New Developer: Jonathan Smith (smithj)

[Markus Nigbur]

On Tuesday 14 June 2005 02:59, Mike Doty wrote:
> Hey all-
>
> Introducing our newest victim^H^H^H^H^H^Hdev, Johnathan Smith.
> smithj(as he's known to his friends) hails from North Carolina, here in
> the US.  He's going to be helping out with desktop-misc items as well as
> hopefully helping with the GDP.

Welcome to the team!
Saw you already fixed a bunch of desktop-misc bugs last night.. nice work 
mate.

-- 
 (o_  Markus Nigbur
 //\  Gentoo GNU/Linux Developer
[ ]/_ http://www.gentoo.org
  GPG Fingerprint: 9E31 187A 6C78 210C F248  EDBB F2FB A77F 707D F8C1


pgpaRdrtasaEz.pgp
Description: PGP signature

[gentoo-dev] The results of an evening of Apache and PAM debugging

[Anthony Gorecki]

This message is fairly long, however I've decided to pass it along in the hope 
that someone may find it useful as a reference source. It was originally 
intended to be a problem description and debugging request for the gnomes to 
ponder over.


I've recently encountered an interesting debugging paradox. Upon deploying 
Subversion with an Apache-based server, I discovered an interesting issue 
with PAM that seems to be intent on defying explanation:

I have a repository that's accessible through , with 
the repository root set at location / (using Subversion 1.2.0, which has a 
fix for the cache bug that prevented repositories from being located at the 
root of a web address). The server is setup to allow read-only access to the 
repository through unencrypted HTTP connections, while write operations must 
use HTTPS (TLSv1, AES256). 

When accessing the repository through HTTPS, Apache dispatches an 
authorization request to mod_auth_pam and PAM, which in turn passes the 
request off as follows:

The username and password authentication (auth) process is passed to pam_krb5 
and the accompanying KDC. This process works flawlessly on every service, 
including Apache's requests. The logs indicate successful logins when 
submitting a username and password via web request.

The account management (account) process is passed to pam_unix, which then 
does a bit of nsswitch magic to tie everything together. In this context, 
only network-based user accounts are permitted, therefore nsswitch uses the 
NSVS (MySQL backend) service to retrieve all of the information. For example, 
calls to getspnam are handled as follows:

getspnam \
SELECT \
'%1$s','x',1,0,9,7,0,DATEDIFF(expiration_date,'1970-01-01'),0 \
FROM users \
WHERE username='%1$s' \
LIMIT 1

Herein lies the problem. During the authorization process, PAM will fail 
during the account stage with the error: "PAM: user 'agorecki'  - invalid 
account: Authentication service cannot retrieve authentication info."

For whatever reason, the debug and audit flags in the pam_unix module are not 
functional. As a result, I extracted the information I needed directly from 
the source code, and found the error location to be:

./Linux-PAM-0.78/modules/pam_unix/pam_unix_acct.c:
127 spent = _pammodutil_getspnam (pamh, uname);
128 else
129 return PAM_SUCCESS;
130
131 if (!spent)
132 if (on(UNIX_BROKEN_SHADOW,ctrl))
133 return PAM_SUCCESS;
134
135 if (!spent)
136 return PAM_AUTHINFO_UNAVAIL;/* Couldn't get username from 
shadow */

The call on line 127 takes place, and the error originates on line 136.

For the purposes of debugging, I've removed all chroot restrictions from 
Apache and have given it complete access to the filesystem. The Apache 
Subversion interface works through the unencrypted connections, which do not 
require authentication.

Hours of Google searching turned up nothing of use; what I don't understand is 
how Apache can fail to retrieve the shadow information when it's accessible 
by any unprivileged--

While writing the above, it occurred to me to run a final check on the debug 
output of nsvsd, which produced: 

run_query: query: SELECT 'agorecki','x',user_id,group_id,CONCAT(first_name,' 
',last_name),CONCAT('/home/',username),'/bin/bash' FROM users WHERE 
username='agorecki' AND group_id IS NOT NULL LIMIT 1
send_response: sending 120-byte response
main_loop: pid 12314 unauthorized for type 8
main_loop: pid 12314 unauthorized for type 8

The obligatory check of the code found:

./nsvs/src/nsvsd/nsvsd.c:
449   /*
450* Don't allow shadow queries to non-root users
451* It is CRITICAL that this code occurs AFTER reading the 
key
452* to avoid clientside sigpipe issues
453*/
454   if ((req.type == GETSPBYNAME || req.type == GETSP) && 
caller.uid != 0)
455 {
456   nsvs_log (LOG_DEBUG, "%s: pid %d unauthorized for type 
%d",
457 __FUNCTION__, caller.pid, req.type);


Having non-root users access the shadow-emulated MySQL information is of no 
consequence to me as I don't use that system for password storage, however 
I'd prefer not to start patching software to work around the above 
restriction. 

Having wasted forty-five minutes typing the above only to find the cause of 
the problem that was illuding me, I'm left with the next problem: 

My network authentication scheme cannot solely rely on Kerberos' built-in 
account expiration and suspension system, because a user could still login 
through SSH using a certificate. As a result, I've tied the entire system's 
account expiration process into the emulated shadow suite so that I can 
expire all access simply by changing the expiration date of the account in 
the MySQL database. Consequently, I can't use the broken_shadow option of 
pam_unix to

Re: [gentoo-dev] New Developer: Jonathan Smith (smithj)

[Jonathan Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Markus Nigbur wrote:
> On Tuesday 14 June 2005 02:59, Mike Doty wrote:
> 
>>Hey all-
>>
>>Introducing our newest victim^H^H^H^H^H^Hdev, Johnathan Smith.
>>smithj(as he's known to his friends) hails from North Carolina, here in
>>the US.  He's going to be helping out with desktop-misc items as well as
>>hopefully helping with the GDP.
> 
> 
> Welcome to the team!
> Saw you already fixed a bunch of desktop-misc bugs last night.. nice work 
> mate.
> 
yep... sorry for the deluge of emails.

thanks for the warm welcome, everyone

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

iD8DBQFCrsa0l5AvwDPiUowRAijkAKDejsKKlFBJ3Te/K9CkoSUyfk9uNQCcD5Sl
aZr2lpm/XXTQ9DplteL+7yo=
=EfhT
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] intention for kde-themes eclass

[Gregorio Guidi]

On Tuesday 14 June 2005 04:19, Brian Jackson wrote:
> Chris White wrote:
> > Here's the nitty gritty:
> >
> > --
> > BACKGROUND
> > --
> >
> > kde-look.org is a site that hosts various kde themes to change the look
> > and feel of the kde desktop.
> >
> > -
> > REASONING
> > -
> >
> > An eclass such as this would be benificial to users that want to create
> > custom ebuilds for various kde themes, as well as getting popular kde
> > themes into the portage tree.
>
> I actually half wrote a g-cpan.pl like thing for kde-look.org once. It
> could handle themes and wallpapers. I never got around to the rest. I think
> something like this would be better in the long run since the eclass will
> only serve to make people file more new ebuild bugs for stuff the kde team
> won't add.

I second that, that's exactly what I thought when I saw the proposal.
A few other points to consider:
- As Michael pointed out, kde-look.org already tries to be a 
install-with-few-clicks portal, and kde is going more and more in this 
direction with the integration in kde 4.
- Often there's no real consistency in content packaged on kde-look, users 
just offer for public download things packaged as they feel.
- Projects appear and become obsolete on kde-look at an _impressive_ rate.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Developer: Jonathan Smith (smithj)

[Markus Nigbur]

On Tuesday 14 June 2005 13:59, Jonathan Smith wrote:
> yep... sorry for the deluge of emails.

Oh, those kind of mails are always a welcomed addition to the standard deluge 
of mails flooding my mailserver.

-- 
 (o_  Markus Nigbur
 //\  Gentoo GNU/Linux Developer
[ ]/_ http://www.gentoo.org
  GPG Fingerprint: 9E31 187A 6C78 210C F248  EDBB F2FB A77F 707D F8C1


pgpPpDkE3e1Nq.pgp
Description: PGP signature

Re: [gentoo-dev] use.force support

[Jan Kundrát]

Mike Frysinger wrote:
> and is the EXACT reason we have the 'nocxx' USE flag instead of 'cxx' ... if 
> we put 'USE=cxx' into profiles' make.defaults, people who have USE=-* will 
> get a broken gcc

Well, if you really consider setting USE=-* to cause so much harm, then
if you introduce the "cxx" USE flag, lot of people will realise that as
well, so you'll make them a favour, in fact :-).

-jkt

-- 
cd /local/pub && more beer > /dev/mouth


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: Re: Removal of articles.xml from website

[Shyam Mani]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06/11/2005 12:44 PM, Duncan wrote:

> I like this idea very much, and would find it highly appropriate for
> Daniel's work, the filesystems article, for instance, both because it's
> still very useful and informative (with updates adding the
> writeback/ordered/data options for reiserfs, and the like, obviously), and

The first of this is up now at http://www.gentoo.org/doc/en/articles/

We will slowly convert everything possible to GuideXML...will take
sometime though.

Regards,

- --
Shyam Mani | <[EMAIL PROTECTED]>
docs-team  | http://gdp.gentoo.org
GPG Key| 0xFDD0E345
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCruSzYZNYgP3Q40URAoKMAJ0QF9ZKM9TrZWhAHnC8p8Nlxdt1HgCbBzUN
htrb19kslLmNWZeVCfyZ5Bo=
=CdAU
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] master-metastructure2005

[Aron Griffis]

Here is the master ballot for the metastructure2005 election.  I will
send out individual emails with confirmation numbers shortly.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer

- confirmation 28b6 -
Oldschool-small
Oldschool-small-with-slacker-boot
Task-force
Keep-current
Alternative
FOSDEM
- confirmation 28d2 -
FOSDEM
Oldschool-large
Oldschool-small Oldschool-small-with-slacker-boot
Task-force
Reopen-nominations
Keep-current
Alternative Oldschool-large-with-slacker-boot
- confirmation 2e09 -
Oldschool-small-with-slacker-boot
Oldschool-large-with-slacker-boot
Oldschool-large
Oldschool-small
Reopen-nominations
Task-force
FOSDEM
Alternative
Keep-current
- confirmation 3010 -
Alternative
FOSDEM
Oldschool-large Oldschool-small Keep-current Oldschool-large-with-slacker-boot 
Task-force Oldschool-small-with-slacker-boot
Reopen-nominations
- confirmation 3012 -
Oldschool-small-with-slacker-boot
Oldschool-large-with-slacker-boot
Oldschool-small
Oldschool-large
Alternative
FOSDEM
Reopen-nominations
Keep-current
Task-force
- confirmation 31f2 -
Oldschool-small-with-slacker-boot
Oldschool-small
Keep-current
Reopen-nominations
Oldschool-large-with-slacker-boot
Oldschool-large
Task-force
Alternative
FOSDEM
- confirmation 321e -
Alternative
Oldschool-small-with-slacker-boot
Oldschool-small
Oldschool-large-with-slacker-boot
Oldschool-large
FOSDEM
Task-force
Reopen-nominations
Keep-current
- confirmation 051d -
Oldschool-small-with-slacker-boot
Oldschool-small
FOSDEM
Oldschool-large-with-slacker-boot
Oldschool-large
Alternative
Task-force
Keep-current
Reopen-nominations
- confirmation 0522 -
Oldschool-small Oldschool-large
Alternative
FOSDEM
Oldschool-small-with-slacker-boot Oldschool-large-with-slacker-boot
Task-force
Keep-current
Reopen-nominations
- confirmation 33b2 -
Oldschool-small-with-slacker-boot
- confirmation 340e -
Alternative
FOSDEM
Task-force
- confirmation 3441 -
Task-force
Oldschool-small Oldschool-large
Alternative FOSDEM
Keep-current
Oldschool-small-with-slacker-boot Oldschool-large-with-slacker-boot
Reopen-nominations
- confirmation 3dad -
Oldschool-small-with-slacker-boot
Oldschool-small
Oldschool-large-with-slacker-boot
Oldschool-large
Alternative
Task-force
Reopen-nominations
FOSDEM
Keep-current
- confirmation 3e94 -
Task-force
Oldschool-small-with-slacker-boot
Oldschool-small
Alternative
FOSDEM
Oldschool-large-with-slacker-boot Oldschool-large
Reopen-nominations
Keep-current
- confirmation 3f23 -
Keep-current
FOSDEM
Alternative
Oldschool-small
Oldschool-large
Reopen-nominations
Oldschool-large-with-slacker-boot
Oldschool-small-with-slacker-boot
Task-force
- confirmation 3ff4 -
Oldschool-large-with-slacker-boot
Oldschool-small-with-slacker-boot
Oldschool-large
Oldschool-small
Alternative
FOSDEM
Task-force
Keep-current
Reopen-nominations
- confirmation 4038 -
Oldschool-small-with-slacker-boot
Oldschool-small
Alternative FOSDEM
Reopen-nominations Keep-current
Task-force
Oldschool-large-with-slacker-boot Oldschool-large
- confirmation 427f -
Task-force
Oldschool-small
Alternative
Reopen-nominations
Oldschool-large
Oldschool-small-with-slacker-boot
Oldschool-large-with-slacker-boot
FOSDEM
Keep-current
- confirmation 4a21 -
FOSDEM
Alternative
Oldschool-small
Reopen-nominations
Keep-current
Task-force
Oldschool-small-with-slacker-boot
Oldschool-large
Oldschool-large-with-slacker-boot
- confirmation 4bb8 -
Oldschool-small
Keep-current
Oldschool-large
Oldschool-small-with-slacker-boot
Alternative
FOSDEM
Task-force
Reopen-nominations
Oldschool-large-with-slacker-boot
- confirmation 4d17 -
Keep-current
Reopen-nominations
Alternative
FOSDEM
Oldschool-small Task-force Oldschool-large-with-slacker-boot 
Oldschool-small-with-slacker-boot Oldschool-large
- confirmation 4e46 -
Alternative FOSDEM
Oldschool-small Oldschool-large Oldschool-small-with-slacker-boot 
Oldschool-large-with-slacker-boot
Keep-current Task-force
Reopen-nominations
- confirmation 5069 -
Oldschool-small-with-slacker-boot
Oldschool-small
Oldschool-large-with-slacker-boot
Alternative
Reopen-nominations
Keep-current
Task-force Oldschool-large
FOSDEM
- confirmation 53e2 -
Oldschool-small
Oldschool-large
Oldschool-small-with-slacker-boot
Oldschool-large-with-slacker-boot
FOSDEM
Keep-current
Alternative
Reopen-nominations
Task-force
- confirmation 5426 -
Oldschool-small-with-slacker-boot
Oldschool-large-with-slacker-boot
Oldschool-small
Oldschool-large
Alternative
FOSDEM
Task-force
Reopen-nominations
Keep-current
- confirmation 57de -
FOSDEM
Alternative
Oldschool-small Oldschool-large
Oldschool-small-with-slacker-boot Oldschool-larg

[gentoo-dev] Re: [gentoo-core] Metastructure vote preliminary results

[Grant Goodyear]

Lance Albertson wrote: [Tue Jun 14 2005, 12:04:48AM CDT]
> Considering the amount of information we had to go through and parse,
> plus the fact some of us were busy, I would say thats not the case at
> all. This election so happen to hit in the middle of a large move and
> starting of a new job for me. I'm sorry that I 'didn't care' because I
> had real life issues to deal with. Personally, I should have spoken up
> to suggest we keep the polls open longer than a week considering the
> amount of material we needed to go through, but I didn't get a chance
> between things. That's my fault for not addressing that concern.

I've heard from a couple of people that the timing was poor, and that 
perhaps we should have kept the polls open longer.  I'm not opposed to a
longer polling period, at least in principle, but I do wonder if a long
polling period makes it easy for people to procrastinate and then forget
about it at the end (which I know is what happened in at least one
case).  

-g2boojum-
-- 
Grant Goodyear  
Gentoo Developer
[EMAIL PROTECTED]
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76


pgp1CvTpyCZXO.pgp
Description: PGP signature

[gentoo-dev] Release Engineering Status Update

[Chris Gianelloni]

In response to Patrick's request for status updates, I'm posting the
current Release Engineering status.

Release Engineering is well into doing QA and testing for 2005.1 on x86,
amd64, ppc, ppc64, ia64, and alpha.  We are currently testing a new
version of livecd-tools, catalyst, and genkernel, all of which are
masked in the tree.  We have been on a massive bug-squashing session to
try to solve any problems before we start building the final release.

Once we work out the few blocking issues we are reaching now, such as
the perl->ssl issue Robin was talking about, then we will build a "beta"
release for 2005.1, which we will start selecting groups of users,
mostly people who filed bugs against 2005.0, to help us with testing,
specifically on platforms or hardware which we do not possess ourselves.

-- 
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] master-metastructure2005

[Grant Goodyear]

Aron Griffis wrote: [Tue Jun 14 2005, 10:12:40AM CDT]
> Here is the master ballot for the metastructure2005 election.  I will
> send out individual emails with confirmation numbers shortly.

Thanks to ciaranm, we now have pretty graphs to go along with the
results. 

-g2boojum-
-- 
Grant Goodyear  
Gentoo Developer
[EMAIL PROTECTED]
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76
Metastructure vote popularity graphs. Options which were usually ranked
highly will have taller bars to the left, and options which were usually
ranked as unfavourable will have taller bars towards the right.

1. Oldschool-small-with-slacker-boot   2. Oldschool-small
|  |
|# |
|# |
|# |
|# |
|# |#  # #
|#  #  |#  # #
|#  #  |## # #
|## # ## # #   |## # #  #  #
|## #  ##  |#  #
|##|#
+---   +---

3. Oldschool-large 4. Alternative
|  |
|  |
|  |
|  |
| #|#
|   # ##   |#
|   # ##   |#
|   # ##   |#  #  ##
|#  # ###  |## #  # # ##
|   ## | ###
|# | #
+---   +---

5. FOSDEM  6. Oldschool-large-with-slacker-boot
|  |
|  |
|# |
|# |
|# |
|# |
|# | #
|#  ###|## # ##   #
|## # #  #  # #|## # ###  # #
|## # ##  #|## # ### #
|## ###| #
+---   +---

7. Task-force  8. Keep-current
|  |
|  |
|  |
|  | #
|  #   | #
|  #   | #
|  #   |   # #
|# ##  |  ####
|# ### |# # # 
|#  # #|##### 
|##|## # #
+---   +---

9. Reopen-nominations
|
|
|
|   #
|   #
|   ##
|  
|  
|  #   
|   # ###  
|##
+---



pgp7ju1egomsT.pgp
Description: PGP signature

[gentoo-dev] Kernel status update

[Daniel Drake]

John Mylchreest posted these objectives in January. I'm not John so I guess
he'll follow up with anything I missed :)

>> Migrate all existing ebuilds to kernel-2 and linux-* eclasses.

This is progressing and can realistically be completed before the end of the 
year.

>> Push 2.6 for default where possible for headers and sources.

This is done as of 2005.0

>> Consolidate appropriate source packages.
  ie: dev-sources -> vanilla-sources,
  gentoo-dev-sources -> gentoo-sources.

This is done as of 2005.0

>> Further improve our current eclass framework to better support
  - Additional kernels (fbsd, darwin etc)

As far as I am aware, we haven't looked into supporting these alternative
kernels yet.

  - Headers

This is done, kernel-2.eclass now handles headers as well as sources.

>> Start sanity checks for 2.7 prep

Since January it has become increasingly clear that 2.7 is not currently in
the pipeline at all.



As well as the above, the genpatches patchset has greatly improved in quality
- we've been able to drop some of the big feature patches such as pegasos
support and multipath device mapper because they are merged upstream. There
are 3 other feature patches that I expect to be merged upstream before the end
of this year.

The new linux-stable upstream branch greatly reduces our genpatches
maintenance, and patches are regularly contributed from genpatches into
linux-stable to benefit other distro's too.

In January, genpatches was only used for gentoo-sources. The 'base' section of
genpatches is now used for gentoo-sources, hardened-sources, ck-sources,
win4lin-sources and usermode-sources. This makes maintaining the kernel
packages easier because its easier to keep up to date with the security patches.

genpatches also gained an automatically generated website which users seem to
like, and moved out of bitkeeper and into gentoo-hosted subversion.

Some kernels such as wolk-sources have been removed from portage to slim down
our sys-kernel category.

To keep up with the constant flow of kernel security patches, plasmaroo is
developing a security patch tracking site to be used instead of kernel GLSA's.
The site is used internally at the moment and proving very useful, and will
probably be finished and made public before the end of this year.

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

kde-theme.py (formerly [gentoo-dev] intention for kde-themes eclass)

[Chris White]

Ok, so plans have changed.  Now I've made a nice little script called 
kde-theme.py, which I haven't released yet because the code needs more 
effecient "what on earth are you trying to make me do.. I can't do that!" error 
handling.  Here's the just of it:

http://dev.gentoo.org/~chriswhite/kde-theme.log

so here's how it works:

1) Check out kde-look.org and select any kde 3.2+ style/theme or window 
decorations (it may handle more, but that's about what I've tested so far)
2) the program assumes 
a) it's a 3.2+ style/theme
b) you're using kde 3.4
c) the file is GPL
(all that will change btw.. I plan on working on some html parsing that will 
parse information straight off the page on license and kde version)
3) so you give it a download url for the source from the theme/style or w indow 
decorations page (like from here for example):

http://www.kde-look.org/content/show.php?content=21107

4) It downloads the file into a directory called .temp_directory, which must be 
empty (it will yell if it's not)
5) it does a directory listing to get the name of the source archive (yes, it 
must be empty because it has to be the only file there, since currently wget is 
handling the download and kde-theme.py has no true way of handling that saving 
doing a directory listing where the download is the only file there).  I plan 
on adding some kind of download library later on to take care of this.
6) it checks the filename against a list of regex's.  This tells it what type 
of file it's dealing with.  By doing so, I can add support for rpm/deb/other 
strange files by simply updating the regex list.  Right now it handles the 
following:

#-packagename-version.extension (kde-look.org hosted source archive)
packagename-version.extension (standard source archive)

7) it pulls packagename and ${P} by packagename+version
8) it creates /usr/portage/x11-themes/[packagename]/files
(I plan to work with PORTDIR_OVERLAY later on so files don't get removed on 
sync)
9) then it writes the ebuild, also if you use the '-a' option, you can set the 
arch it uses for KEYWORDS, otherwise it assume x86 (yes.. I know other archs 
exist ;p).  Keywording is done on an ~arch basis since it uses kde 3.4 anyways. 
 Also, if '-d' option is set (don't merge), the newly created ebuild will not 
be merged.
10) ebuild [file] digest is run to create the manifest
11) the file is emerged with --oneshot to prevent world udpates from going 
screwy

viola, that's all there is too it.
Chris White


pgpoQtu8z047s.pgp
Description: PGP signature

Re: [gentoo-dev] use.force support

[Alec Warner]

Sven Wegener wrote:

On Mon, Jun 13, 2005 at 05:08:09PM -0400, Alec Warner wrote:


Sven Wegener wrote:



use.force might not be the best name, but it's what we do with it for
most of our users. Being able to -flag in /etc/portage/profile/use.force
is just because /etc/portage/profile gets added to the cascaded profile
chain.  Everything we add to portage that allows a profile to revert
some behaviour added by parent profiles, can also be done with
/etc/portage/profile and it's good that way. So, that we're able to
-flag in use.force is just part of the way cascaded profiles work. It's
not a feature that will be added just to support use.force. Primary
reason for use.force is to have a way to activate flags even if USE="-*"
is in make.conf or environment.


How is this not just a consequence of USE="-*"...that is what this does; 
turns off ALL use flags.  How is use.force ( or the concept thereof ) 
not breaking the 'easy' interpretation of USE="-*" because now things 
aren't -*, they are -* + use.force things.


It's one of those "if you use USE="-*" you should know the consequences 
of it...kind of deals.



There are some USE flags that must survive the -* thing and already do
it. One of them being ARCH, which is always there. And the USE_EXPANDed
ones, the current important being being userland_*, kernel_* and elibc_*
which are needed for special dependencies and checks. They are not to be
modified by users by using USE in make.conf or the environment. They
depend on the chosen profile and should always be enabled. We're not
talking about every day USE flags, but really special USE flags, like
multilib, selinux or the USE_EXPANDed ones that *must* be turned on for
the chosen profile. Don't think of them like every day USE flags that
allow you to tweak your system, they are used to pass some information
from profiles to the ebuilds in a way portage can easily handle it.

Hm, use.must sounds bad once I think about it more.

Sven

I'm probably a little behind here, since this has been used for a while, 
but I guess more discussion and ideas are good.


It seems like this is an abuse of USE flags, somewhat.  I guess programs 
could have support for elibc_X or elibc_Y or userland_GNU or 
userland_DARWIN/BSD but why a USE flag for these?  If they must be 
forced, force them in the environment outside of USE flag usage.  USE 
flags are for turning off optional support for programs, that is their 
overall purpose.  There isn't a use flag for kernel version, there is a 
function for that.  Why is there not a function to determine 
userland/arch/libc?


In this case I think this use.force deal will create more complexity in 
the USE flag area than help.  This is not what use flags are for ( also 
for multilib and SELINUX ).

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] use.force support

[Diego 'Flameeyes' Pettenò]

On Tuesday 14 June 2005 19:46, Alec Warner wrote:
> It seems like this is an abuse of USE flags, somewhat.  I guess programs
> could have support for elibc_X or elibc_Y or userland_GNU or
> userland_DARWIN/BSD but why a USE flag for these?
Because sometimes we must disable some dependency depending on the libc or the 
userland or the kernel used.

> There isn't a use flag for kernel version, there is a
> function for that.  Why is there not a function to determine
> userland/arch/libc?
Actually there's a variable for them but as said above, variables aren't 
allowed to change the deps. And there are quite a few dependencies which are 
needed just on some systems.
Another thing is use_enable and use_with functions, takes for example kdelibs 
ebuild which has a $(use_enable kernel_Linux dnotify) as dnotify support is 
only for Linux kernels.

It's true that the forced flags shouldn't show up on emerge -pv output (at 
least for base ones, other which can be optional on some arch and forced on 
others can always show up, take for example nopie/nossp which are going to be 
forced on Gentoo/FreeBSD (I actually was working on a similar use.force file 
before so I already have this done locally).

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

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



pgpbo7EgKYpeY.pgp
Description: PGP signature

[gentoo-dev] chriswhite herd(?) status update

[Chris White]

Since I'm really not in a particular herd, here's a couple of goals I have for 
getting Gentoo into a better state:

1) First off, working on the kde-theme.py package.  I've been working on it 
left and right and it's nicely progressing, we'll see where it goes
2) Helping get some ebuilds that are sort of collecting dust in bugzilla up and 
running
3) Helping other devs/herds with general bug wrangling (ie. creating obscure 
patches by staying up for 5 hours on lots of Pepsi)
4) Helping out with some documentation (and sending it to the right people this 
time ;p)

and that's the short list.. here's the long one:

1) Ok, I think that's about as well said as it's going to get :P
2) Getting these new ebuilds in the tree will definately help grow the number 
of usefull tools for users, as well as re-initiating the developer-user 
relationship.
3) Helping out general bug wrangling will, well, close more bugs :P.  Not only 
that, but it will vastly prevent the situation of "ARGG, MY WORLD UPDATE :(".  
I'm running emerge world pretty consistantly, so if I hit something, I'll most 
likely be fixing it (I hate interrupted world updates like everyone else :P)
4) There is no such thing as too many docs :P.  

on a minor note, I was thinking of maybe a somewhat small comprehensive list of 
major problems and ways to solve them.  I know we do have bugzilla, but 
bugzilla is kind of full of noise (look at all them bugs!).  Therefore, I think 
a small page with major stuff like "Oh my god, my stuff doesn't compile" or "It 
can't find my library!" would help.  Ways of solving it would also be nice.  I 
was thinking of having the page archive things that are 1 month old and 
everything else is front page.  Let me know what the thoughts are on that.  Ok, 
that's it...

Chris White


pgpbLU7jBQwyt.pgp
Description: PGP signature

Re: [gentoo-dev] chriswhite herd(?) status update

[Andrej Kacian]

On Wed, 15 Jun 2005 11:49:28 +0900
Chris White <[EMAIL PROTECTED]> wrote:

> on a minor note, I was thinking of maybe a somewhat small comprehensive list
> of major problems and ways to solve them.  I know we do have bugzilla, but
> bugzilla is kind of full of noise (look at all them bugs!).  Therefore, I
> think a small page with major stuff like "Oh my god, my stuff doesn't
> compile" or "It can't find my library!" would help.  Ways of solving it
> would also be nice.  I was thinking of having the page archive things that
> are 1 month old and everything else is front page.  Let me know what the
> thoughts are on that.  Ok, that's it...

That's a good idea, something like topic on #gentoo, but in form of a website
(and perhaps a RSS feed?)

-- 
Andrej "Ticho" Kacian 
Gentoo Linux Developer - net-mail, antivirus, amd64


pgpx8WdyXEUoI.pgp
Description: PGP signature

Re: [gentoo-dev] chriswhite herd(?) status update

[Patrick Lauer]

On Tue, 2005-06-14 at 20:24 +0200, Andrej Kacian wrote:
> On Wed, 15 Jun 2005 11:49:28 +0900
> Chris White <[EMAIL PROTECTED]> wrote:
> 
> > on a minor note, I was thinking of maybe a somewhat small comprehensive list
> > of major problems and ways to solve them.  I know we do have bugzilla, but
> > bugzilla is kind of full of noise (look at all them bugs!).  Therefore, I
> > think a small page with major stuff like "Oh my god, my stuff doesn't
> > compile" or "It can't find my library!" would help.  Ways of solving it
> > would also be nice.  I was thinking of having the page archive things that
> > are 1 month old and everything else is front page.  Let me know what the
> > thoughts are on that.  Ok, that's it...
> 
> That's a good idea, something like topic on #gentoo, but in form of a website
> (and perhaps a RSS feed?)
I like the idea. 
Questions:
- do "we" want that?
- who will take care of it?

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] chriswhite herd(?) status update

[Joshua Baergen]

On 6/14/05, Patrick Lauer <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-06-14 at 20:24 +0200, Andrej Kacian wrote:
> > On Wed, 15 Jun 2005 11:49:28 +0900
> > Chris White <[EMAIL PROTECTED]> wrote:
> >
> > > on a minor note, I was thinking of maybe a somewhat small comprehensive 
> > > list
> > > of major problems and ways to solve them.  I know we do have bugzilla, but
> > > bugzilla is kind of full of noise (look at all them bugs!).  Therefore, I
> > > think a small page with major stuff like "Oh my god, my stuff doesn't
> > > compile" or "It can't find my library!" would help.  Ways of solving it
> > > would also be nice.  I was thinking of having the page archive things that
> > > are 1 month old and everything else is front page.  Let me know what the
> > > thoughts are on that.  Ok, that's it...
> >
> > That's a good idea, something like topic on #gentoo, but in form of a 
> > website
> > (and perhaps a RSS feed?)
> I like the idea.
> Questions:
> - do "we" want that?
> - who will take care of it?
> 
> wkr,
> Patrick
> --
> Stand still, and let the rest of the universe move
> 
> 
> BodyID:125254787.2.n.logpart (stored separately)
> 
> 
A couple other things I can see becoming an issue:

1) We don't want to undermine bugzilla's function.  Yes, it's noisy,
but a suitably motivated individual (to use Donnie's catchphrase) can
find what they're looking for.  Taking people off bugzilla could mean
less bugs solved, and it could also mean people saying, "Oh, look,
it's not on the RSS feed!  Let's file a bug."
2) At the risk of merely restating Patrick's second question,
maintaining a mini-bugzilla (I know that's not what it will be, but
nonetheless) takes developers off of solving bugs, instead tasking
them with re-packaging existing solutions that can be found (refer to
1 ;P).

That been said, I think it's a great idea for those who don't know a
lot about the open source process or even Linux in general.  Maybe it
would be a good idea to make the page refer back to bugzilla often
enough to make people wonder what it is, as well as get them used to
the sight of it.  That makes it less work, as the maintainers can
merely summarize solutions only if necessary, and link up to the bugs.
 I know this would be really useful for when we have those common bugs
where you see a bajillion duplicates.  From people who think bugzilla
is a forum to post their problems.

-- 
Joshua Baergen

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] chriswhite herd(?) status update

[Simon Stelling]

Hi,

Chris White wrote:
> on a minor note, I was thinking of maybe a somewhat small
> comprehensive list of major problems and ways to solve them.
> I know we do have bugzilla, but bugzilla is kind of full of noise
> (look at all them bugs!).  Therefore, I think a small page with
> major stuff like "Oh my god, my stuff doesn't compile" or "It can't
> find my library!" would help.  Ways of solving it would also be nice.
> I was thinking of having the page archive things that are 1 month
> old and everything else is front page.  Let me know what the thoughts
> are on that.  Ok, that's it...

I don't like this idea, it doesn't look like a solution but rather like
an ugly work-around to me. I agree that some things should be handled
outside bugzilla, but bugs belong to bugzilla. We already have a tool to
track bugs, setting up another one wouldn't help reducing bugs, it'd
rather cost us even more time (you have to check two sources for
informations) and there will be more duplications. All in all, it looks
like twice the effort for the same result to me.

Regards,

blubb

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

Re: [gentoo-dev] chriswhite herd(?) status update

[Chris Gianelloni]

On Tue, 2005-06-14 at 21:01 +0200, Simon Stelling wrote:
> Hi,
> 
> Chris White wrote:
> > on a minor note, I was thinking of maybe a somewhat small
> > comprehensive list of major problems and ways to solve them.
> > I know we do have bugzilla, but bugzilla is kind of full of noise
> > (look at all them bugs!).  Therefore, I think a small page with
> > major stuff like "Oh my god, my stuff doesn't compile" or "It can't
> > find my library!" would help.  Ways of solving it would also be nice.
> > I was thinking of having the page archive things that are 1 month
> > old and everything else is front page.  Let me know what the thoughts
> > are on that.  Ok, that's it...
> 
> I don't like this idea, it doesn't look like a solution but rather like
> an ugly work-around to me. I agree that some things should be handled
> outside bugzilla, but bugs belong to bugzilla. We already have a tool to
> track bugs, setting up another one wouldn't help reducing bugs, it'd
> rather cost us even more time (you have to check two sources for
> informations) and there will be more duplications. All in all, it looks
> like twice the effort for the same result to me.

I tend to agree.

Want to make something nice to help with bugzilla?  How about a page
with some good queries already setup for different things that would be
common.  Say something like searching for all bugs that are NEW that
have EBUILD in the KEYWORDS?  How about all bugs that have been
REOPENED?  All bugs that have been RESOLVED-TESTREQUEST?

I think these pre-built queries would be much better than yet another
page to find bugs.

-- 
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] chriswhite herd(?) status update

[Chris White]

> I tend to agree.
> 
> Want to make something nice to help with bugzilla?  How about a page
> with some good queries already setup for different things that would be
> common.  Say something like searching for all bugs that are NEW that
> have EBUILD in the KEYWORDS?  How about all bugs that have been
> REOPENED?  All bugs that have been RESOLVED-TESTREQUEST?
> 
> I think these pre-built queries would be much better than yet another
> page to find bugs.

Come to think of it.. I think kloeri had a page for that.  Maybe we could ask 
him :P.

Chris White


pgphGpNz3r35t.pgp
Description: PGP signature

[gentoo-dev] New developer: Stefan Briesenick (sbriesen)

[Tom Martin]

Hi list,

Stefan is joining us to help with the net-dialup herd for isdn-related
packages. He comes from Gaggenau in the Alsace region (near the French
border, for those unfamiliar with the geography of the region) of
Germany and he is 35 years old.

Stefan has been married for five years, and he has a son who is
two. He works in a job as a Linux administrator and system programmer.
He's experienced in many languages (not least C and x86 asm). He's also
written a few shareware and freeware programs for OS/2 and DOS in the
past, for instance, EasyERP (a FidoNet request processor) and PMEurit (a
telephony application for ASCOM Eurit ISDN phones).

Please welcome Stefan on board.

Regards,
Tom

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


pgp5ltwwviyuJ.pgp
Description: PGP signature

[gentoo-dev] New developer: Senno During (st3vie)

[Aaron Walker]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Greetings,

Please give a nice Gentoo-ized welcome to Senno During (st3vie).  Senno will be
leading the Dutch GWN Translation team (actually he has been for several weeks).

Ripped from his quiz:

i'm 28 years old, from a city called Beverwijk (30km west from Amsterdam,
near the coast) located in The Netherlands. The last year i've spent
my time at home, mostly, getting an illness under control, in which
i currently succeeded, so far, and i'm currently looking for a job again,
a programming job. In the past i've done programming for desktop
applications and webapplications.
Most of the languages i know are self-taught. Other hobbies, i tend to
pick up again shortly, are mountain biking (yes, eventhough we hardly
have mountains here), running, indoor soccer, music (making and
listening), programming and more. Any other info needed... just ask.  :)

Everyone welcome him aboard.
- --
Laughter is the closest distance between two people.
-- Victor Borge

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

iD8DBQFCrzsRC3poscuANHARAsNtAKC8va+eOwDubHE150BVOQ/G/ElkYACgkSf1
VxK5MuNECgnPArJ8gM6E/uc=
=NySa
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

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

[Chris White]

> >>might I suggest not kicking #gentoo-dev visitors who ask for voice to
> >>speak to the devs without a 'rtfm & go get a gentoo job' smokescreen ?

My intentions in this email were regarding the above worries about things.  I 
plan to create somewhat of a consistant contact point between irc users that 
want a voice in dev.  If anyone has disagreements, I'll be happy to hear them 
out and hopefully address them.  My plan of interaction is as follows:


Plan


if you want a voice in #gentoo-dev, please ask me
if I'm not active, send me an email to this address letting me know what it is 
you'd like to discuss in dev

if you feel that I have handled the situation properly regarding your voicing, 
please send an email to dev-relations and I'll be happy to work things out.

Also if you send me an email, please put [gentoo-dev voicing request] in the 
topic, as well as your irc name and timezone for contact purposes.

I'll be leaving for work for about 8 hours from the time of this email, so 
don't expect too much of an immediate response.

Chris White


pgpNIzYLx5vq8.pgp
Description: PGP signature

Re: [gentoo-dev] New developer: Senno During (st3vie)

[Jonathan Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Aaron Walker wrote:
> Greetings,
> 
> Please give a nice Gentoo-ized welcome to Senno During (st3vie).  Senno will 
> be
> leading the Dutch GWN Translation team (actually he has been for several 
> weeks).
> 
> Ripped from his quiz:
> 
> i'm 28 years old, from a city called Beverwijk (30km west from Amsterdam,
> near the coast) located in The Netherlands. The last year i've spent
> my time at home, mostly, getting an illness under control, in which
> i currently succeeded, so far, and i'm currently looking for a job again,
> a programming job. In the past i've done programming for desktop
> applications and webapplications.
> Most of the languages i know are self-taught. Other hobbies, i tend to
> pick up again shortly, are mountain biking (yes, eventhough we hardly
> have mountains here), running, indoor soccer, music (making and
> listening), programming and more. Any other info needed... just ask.  :)
> 
> Everyone welcome him aboard.


We've been having alot of new devs recently... maybe us n00bs should
stick together so we won't be picked on by the meanies "above" us :-P

welcome aboard

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

iD8DBQFCrz9Nl5AvwDPiUowRAlauAJ9uwF8cSpr61PwUTs+c+bI7AKje+gCgxKkD
NPj1ka8bxCt9k7Cq48FZTxE=
=30mu
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

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

[Jan Kundrát]

Chris White wrote:
> I plan to create somewhat of a consistant contact point between irc users 
> that want a voice in dev.

Are you awake 24/7/365? If not, I probably misunderstood your message.
If someone goes to IRC, he (IMHO) wants to discuss stuff *right now* and
don't want to wait for you to return from job/shopping/vacation/whatever.

-jkt

-- 
cd /local/pub && more beer > /dev/mouth


signature.asc
Description: OpenPGP digital signature

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

[Jonathan Smith]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris White wrote:
> [snip]
> if you feel that I have handled the situation properly regarding your 
> voicing, please send an email to dev-relations and I'll be happy to work 
> things out.
> [snip]

just to clarify: you mean improperly, right? why would a user send an
email to devrel if you did a good job?

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

iD8DBQFCr0EMl5AvwDPiUowRAtO4AKCQl7FjLy7CQYdjvRFx6AujlglpvwCfSjGP
FDWCMPNhGfnmyR7iQvJoaxk=
=wJYK
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

On Monday 13 June 2005 19:18, Robin H. Johnson wrote:
> The bug hit me while working with GLI last night, and now I really do
> need a solution for it. Looking at the dep tree to see why perl pulls
> in openssl, the critical parts of the tree are this:
>
> (Trimmed to make things shorter)
> [ebuild  N] dev-lang/perl-5.8.6-r4  +berkdb
> [ebuild  N]  sys-libs/db-4.2.52_p2  +java
> [ebuild  N]   dev-java/blackdown-jdk-1.4.2.01-r2
> (glibc, gcc, gcc-config, portage)
> [ebuild  N]dev-lang/python-2.4.1  +berkdb +ssl
> [ebuild  N] dev-libs/openssl-0.9.7g
>
> This suggests the following solutions:
> 1. split berkdb support out of perl.
> 2. split ssl support out of python.
> 3. split java support out of db.
>
> #1 may be possible with mcumming's minimal perl (untested by me)
> #2 appears to work (tested via package.use having 'python -ssl', and
> looking at 'emerge -e -p system') #3 appears to work (tested via
> package.use having 'db -java', and looking at 'emerge -e -p system')
>
> I tried implementing #3, but the ebuild work involved is very messy, and
> non-ideal, as a large part of db is then built twice.
>
> Could the python and perl folk please comment here on the possibility of
> moving those chunks (berkdb/ssl) of their packages to seperate packages?

What I wonderis why blackdown-jdk (or any other jdk) actually depends on 
python. These jdk's are binary only packages that have no buildtime 
dependencies. The only source of the python dependency is java-config. In any 
case python should be a system package.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpvZhBkk2dFS.pgp
Description: PGP signature

Re: [gentoo-dev] New developer: Senno During (st3vie)

[Maurice van der Pot]

On Tue, Jun 14, 2005 at 04:16:17PM -0400, Aaron Walker wrote:
> i'm 28 years old, from a city called Beverwijk (30km west from Amsterdam,

30km, ey? I hope you're a good swimmer ;)

Anyway, welcome to the team!

Groeten,
Maurice

-- 
Maurice van der Pot

Gentoo Linux Developer   [EMAIL PROTECTED] http://www.gentoo.org
Creator of BiteMe!   [EMAIL PROTECTED]   http://www.kfk4ever.com



pgpn9cs3ykaUA.pgp
Description: PGP signature

Re: [gentoo-dev] New developer: Stefan Briesenick (sbriesen)

[Stefan Schweizer]

Am Dienstag 14 Juni 2005 22:11 schrieb Tom Martin:
[..]
> Please welcome Stefan on board.
>
> Regards,
> Tom

Welcome Stefan, now you are finally able to add your work to the tree 
yourself, congrats!

Regards,
Stefan


pgpOyCXAPhZbW.pgp
Description: PGP signature

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

[Marius Mauch]

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

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

[snip]

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

Marius

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

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


pgplbWIF5gXXr.pgp
Description: PGP signature

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

[Joshua Baergen]

On 6/14/05, Jonathan Smith <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Chris White wrote:
> > [snip]
> > if you feel that I have handled the situation properly regarding your 
> > voicing, please send an email to dev-relations and I'll be happy to work 
> > things out.
> > [snip]
> 
> just to clarify: you mean improperly, right? why would a user send an
> email to devrel if you did a good job?
> 
> - -smithj
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFCr0EMl5AvwDPiUowRAtO4AKCQl7FjLy7CQYdjvRFx6AujlglpvwCfSjGP
> FDWCMPNhGfnmyR7iQvJoaxk=
> =wJYK
> -END PGP SIGNATURE-
> --
> gentoo-dev@gentoo.org mailing list
> 
> 
Because devrel gets grumpy if they only hear about bad things! :P

-- 
Joshua Baergen

-- 
gentoo-dev@gentoo.org mailing list

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

[Robin H. Johnson]

On Tue, Jun 14, 2005 at 10:50:05PM +0200, Paul de Vrieze wrote:
> > (Trimmed to make things shorter)
> > [ebuild  N] dev-lang/perl-5.8.6-r4  +berkdb
> > [ebuild  N]  sys-libs/db-4.2.52_p2  +java
> > [ebuild  N]   dev-java/blackdown-jdk-1.4.2.01-r2
> > (glibc, gcc, gcc-config, portage)
> > [ebuild  N]dev-lang/python-2.4.1  +berkdb +ssl
> > [ebuild  N] dev-libs/openssl-0.9.7g
> What I wonderis why blackdown-jdk (or any other jdk) actually depends on 
> python. These jdk's are binary only packages that have no buildtime 
> dependencies. The only source of the python dependency is java-config. In any 
> case python should be a system package.
java-config only has a RDEPEND on python.

The stage2 command is 'emerge -e system'.

blackdown-jdk DEPEND="virtual/libc"
glibc DEPEND="sys-devel/gcc"
gcc DEPEND="sys-devel/gcc-config"
- Maybe this should be an RDEPEND only?
gcc-config DEPEND="sys-devel/portage"
- Maybe this should be an RDEPEND only?
portage RDEPEND="dev-lang/python"




-- 
Robin Hugh Johnson
E-Mail : [EMAIL PROTECTED]
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#   : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpPS2V4vpHYk.pgp
Description: PGP signature

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

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Marius Mauch wrote:
> Won't work. First it would introduce a single point of failure. If we'd
> really follow this route there has to be a role for this, not a user.
> Then how are people supposed to know about this in teh first place? I
> wouldn't expect that users with a question/topic for -dev have read the
> dev handbook. Often that is spontaneous, which brings me to my next
> point: email definitely won't work for this, I mean if someone writes
> an email they can just as well ask their question on the gentoo-dev
> list directly.

Yeah maybe we should make a #-dev FAQ and stick it in the topic.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCr0v8XVaO67S1rtsRArgUAKDfSQOjiFneeXInhcB1qs6JjcfdiwCgq/Dy
qov9Ah+ZBkV/nS1donQp0jY=
=RxO2
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Even More Portage Bashrc Fun

[Michael Tindal]

Rumen Yotov wrote:
> Michael Tindal wrote:
> 
> 
>>Hello,
>>
>>So a long time ago solar wrote a bashrc for portage, and posted it on
>>this mailing list for everyone to see.  I took it, and started extending
>>it with various things of my own design, and some contributions from
>>others.  I've since updated it with the things solar's been adding to
>>his bashrc, plus adding the functionality from ChrisWhites bashrc.
>>Well, adding all of that stuff made the bashrc quite large.  In addition
>>I was using CVS for a while, and wrote a lot of hooks to work with CVS,
>>when I went back to 2.0.51, I didnt want to lose all of those, so I
>>backported in a way the hooks from CVS (I mean in a way because the post
>>hooks arent really post hooks, they just run before the pre hook of the
>>next phase), but that meant the bashrc was huge.
>>
>>So, sometime last night or this morning I set out to create a modular
>>portage bashrc [1], and I have done so.  I'll admit, the code is ugly,
>>and it probably could've been done better.  But it does lay a good
>>framework for future extensions.
>>
>>The bashrc file is just a skeleton that loads the modules, and handles
>>the pseudo-hook implementation.  The real magic happens in the
>>bashrc-modules subdirectory.  core-functions.bmod contains the basic
>>functions and handles loading other modules.  hooks.bmod defines the
>>hooks used and defines functions used to add new function calls to the
>>hooks.  The other bmod files define some sort of library for other
>>modules (like an eclass) or functions that get loaded into the hooks.  I
>>don't have any documentation written up for that, so read through the
>>source and you should get an idea of how it all works.
>>
>>The BASHRC_DYN_MODULES variable can be defined in make.conf to limit the
>>modules that are loaded by the bashrc.  This is useful if you only want
>>to use a subset of the functionality available in the modules, and dont
>>want to load them all.  The default behavior is to load all of the
>>modules under ${ROOT}/etc/portage/bashrc-modules/.  To extend the
>>bashrc, for example, to add another feature, you simply create a new
>>bmod following the examples given, then either let it load automatically
>>or add it to BASHRC_DYN_MODULES.
>>
>>I've done some thorough testing and beu did some testing as well, so
>>there shouldnt be any major bugs, but if you find some, please e-mail me
>>with them.  I'm especially interested in command not found errors.  This
>>is some really ugly bash code, so if you run into obscure errors, dont
>>freak out, theyre a result of how I deal with the infrastructure.
>>Overall though, it appears to be stable, and I'm currently using it on
>>my system.
>>
>>Finally, I'd like to thank the people who directly or indirectly helped
>>with this bashrc and the bashrc system:  solar, ChrisWhite, beu,
>>bluefoxicy, and anyone else who I forgot to name.  Enjoy everyone!
>>
>>Mike Tindal
>>
>>PS:  Heed the warning given in the setup phase, you *cannot* modify
>>variables that affect depends because the environment the bashrc
>>modifies isnt picked up by depends.  Be very careful with what you do
>>with category.use, since that can very easily break builds.
>>
>>[1]
>>http://dev.gentoo.org/~urilith/portage-tools/bashrc-2.0.51-modular-20050612.tar.bz2
>>
>>I've got some sample files in that dir for the random files the bashrc
>>supports.
>> 
>>
> 
> Hi,
> Till now used the old/org bashrc-script plus package.* files.
> Now when replaced them with the new one get some errors, seems just
> syntax ones.
> Here's the log when using it:
> ...
> 
Loading module hooks.bmod...
Loading module string-utils.bmod...
Loading module audit.bmod...
Loading module autooverlay.bmod...
Loading module autopatch.bmod...
Loading module conf.bmod...
Loading module distdir-clean.bmod...
Loading module enotice.bmod...
Loading module etc-portage.bmod...
> 
> //etc/portage/bashrc-modules/core-functions.bmod: eval: line 103:
> unexpected EOF while looking for matching `''
> //etc/portage/bashrc-modules/core-functions.bmod: eval: line 104: syntax
> error: unexpected end of file
> //etc/portage/bashrc-modules/core-functions.bmod: eval: line 108:
> unexpected EOF while looking for matching `''
> //etc/portage/bashrc-modules/core-functions.bmod: eval: line 109: syntax
> error: unexpected end of file
> //etc/portage/bashrc-modules/core-functions.bmod: eval: line 103:
> unexpected EOF while looking for matching `''
> //etc/portage/bashrc-modules/core-functions.bmod: eval: line 104: syntax
> error: unexpected end of file
> //etc/portage/bashrc-modules/core-functions.bmod: eval: line 108:
> unexpected EOF while looking for matching `''
> //etc/portage/bashrc-modules/core-functions.bmod: eval: line 109: syntax
> error: unexpected end of file
> //etc/portage/bashrc-modules/core-functions.bmod: eval: line 103:
> unexpected EOF while looking for matching `''
> //etc/portage/bashrc-modules/core-functions.bmod:

Re: [gentoo-dev] chriswhite herd(?) status update

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joshua Baergen wrote:
> 1) We don't want to undermine bugzilla's function.  Yes, it's noisy,
> but a suitably motivated individual (to use Donnie's catchphrase) can
> find what they're looking for.

I used the word "individual" in reference to a person? Please kick me or
something, if I actually did.

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

iD8DBQFCr0xRXVaO67S1rtsRAmNDAKDDrPJ3f6vjofm4+j+G+ScvJkxPYACfaj3R
c9ZIF/jPoWoOoYe2fRG5lUc=
=HF12
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

On Tuesday 14 June 2005 23:15, Robin H. Johnson wrote:
> On Tue, Jun 14, 2005 at 10:50:05PM +0200, Paul de Vrieze wrote:
> > > (Trimmed to make things shorter)
> > > [ebuild  N] dev-lang/perl-5.8.6-r4  +berkdb
> > > [ebuild  N]  sys-libs/db-4.2.52_p2  +java
> > > [ebuild  N]   dev-java/blackdown-jdk-1.4.2.01-r2
> > > (glibc, gcc, gcc-config, portage)
> > > [ebuild  N]dev-lang/python-2.4.1  +berkdb +ssl
> > > [ebuild  N] dev-libs/openssl-0.9.7g
> >
> > What I wonderis why blackdown-jdk (or any other jdk) actually depends on
> > python. These jdk's are binary only packages that have no buildtime
> > dependencies. The only source of the python dependency is java-config. In
> > any case python should be a system package.
>
> java-config only has a RDEPEND on python.
>
> The stage2 command is 'emerge -e system'.
>
> blackdown-jdk DEPEND="virtual/libc"
> glibc DEPEND="sys-devel/gcc"
> gcc DEPEND="sys-devel/gcc-config"
> - Maybe this should be an RDEPEND only?
> gcc-config DEPEND="sys-devel/portage"

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

> - Maybe this should be an RDEPEND only?
> portage RDEPEND="dev-lang/python"

Portage does provide some very simple binary python modules. These depend at 
compiletime on python headers. Providing those headers separately might help 
though. Just as well as splitting out those modules.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpc8ZjAmBJGj.pgp
Description: PGP signature

Re: kde-theme.py (formerly [gentoo-dev] intention for kde-themes eclass)

[Paul de Vrieze]

On Wednesday 15 June 2005 03:06, Chris White wrote:
> 4) It downloads the file into a directory called .temp_directory, which
> must be empty (it will yell if it's not) 5) it does a directory listing to
> get the name of the source archive (yes, it must be empty because it has to
> be the only file there, since currently wget is handling the download and
> kde-theme.py has no true way of handling that saving doing a directory
> listing where the download is the only file there).  I plan on adding some
> kind of download library later on to take care of this. 6) it checks the
> filename against a list of regex's.  This tells it what type of file it's
> dealing with.  By doing so, I can add support for rpm/deb/other strange
> files by simply updating the regex list.  Right now it handles the
> following:

You do know that wget has the "-O" option to specify the name of the 
downloaded file. Of course that means you can't regex, but you could probably 
do that from wget's output.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpZ6TtmpQblJ.pgp
Description: PGP signature

Re: [gentoo-dev] The results of an evening of Apache and PAM debugging

[Paul de Vrieze]

On Tuesday 14 June 2005 13:17, Anthony Gorecki wrote:
>
> Does anyone have a suggestion that would fit the requirements, other than
> using mod_auth_external, coupled with an authentication program? An
> interface to Cyrus-SASL would be ideal since I already have saslauthd
> running for Postfix.
>
> In addition, does anyone have an idea as to what authentication program
> could be used as the aforementioned intermediary?

You know that the "normal" way of doing this is to use ldap and krb5 together. 
Ldap even has it's own apache module. Mind you though that pam_ldap, 
mod_auth_pam, apache2, and mod_dav_svn seem to not be able to work together 
reliably. There is some kind of strange issue there that's very hard to 
diagnose. Using direct ldap authentication does work.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpsCtTYtur21.pgp
Description: PGP signature

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

[Mike Frysinger]

On Tuesday 14 June 2005 05:32 pm, Paul de Vrieze wrote:
> I don't think gcc-config should depend on portage at all. Or does it
> actually use portage services. In any case it should be an RDEPEND, as
> building does not depend on portage being there.

it was added when `portageq` didnt exist everywhere so we had to make sure the 
portage on the system ran a new-enough version

we can drop it now if it'll break this circular DEPEND
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] chriswhite herd(?) status update

[Bryan Oestergaard]

On Wed, Jun 15, 2005 at 01:02:45PM +0900, Chris White wrote:
> 
> > I tend to agree.
> > 
> > Want to make something nice to help with bugzilla?  How about a page
> > with some good queries already setup for different things that would be
> > common.  Say something like searching for all bugs that are NEW that
> > have EBUILD in the KEYWORDS?  How about all bugs that have been
> > REOPENED?  All bugs that have been RESOLVED-TESTREQUEST?
> > 
> > I think these pre-built queries would be much better than yet another
> > page to find bugs.
> 
> Come to think of it.. I think kloeri had a page for that.  Maybe we could ask 
> him :P.
> 
> Chris White
I'm about to embark on a major redesign of the http://bugday.gentoo.org
website so I'm obviously happy to have ideas thrown at me. That said you
need to throw ideas at me using irc as nothing is set in stone yet and I
want you to explain your ideas to me clearly before I even consider
them.

And I'm not going to explain my ideas so far unless it's in a
semi-private forum (#gentoo-bugs works well) as I don't want to commit
to any features yet.

So anybody interested should just catch me on irc which shouldn't be too
hard.. And please make sure to keep your ideas/requests related to
bugday.

Thanks,
Bryan Østergaard
kloeri at #gentoo-bugs, irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

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

[Marius Mauch]

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

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

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

Marius

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

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


pgpT2nVsvTGn7.pgp
Description: PGP signature

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

[Mike Frysinger]

On Tuesday 14 June 2005 06:52 pm, Marius Mauch wrote:
> On Tue, 14 Jun 2005 23:32:06 +0200
>
> Paul de Vrieze <[EMAIL PROTECTED]> wrote:
> > I don't think gcc-config should depend on portage at all. Or does it
> > actually use portage services. In any case it should be an RDEPEND,
> > as building does not depend on portage being there.
>
> Hmm, how do you build an ebuild without portage? Not trying to defend
> that dependency, but technically all ebuilds DEPEND on portage (or a
> compatible package manager), that's the most implicit dependency of all.

i assume you didnt read the reply i made already ...

gcc-config DEPEND-ed on a specific version of portage (the first one to 
provide portageq to userspace)
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] chriswhite herd(?) status update

[Joshua Baergen]

Ok, so paraphrase. :P

On 6/14/05, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Joshua Baergen wrote:
> > 1) We don't want to undermine bugzilla's function.  Yes, it's noisy,
> > but a suitably motivated individual (to use Donnie's catchphrase) can
> > find what they're looking for.
> 
> I used the word "individual" in reference to a person? Please kick me or
> something, if I actually did.
> 
> D
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFCr0xRXVaO67S1rtsRAmNDAKDDrPJ3f6vjofm4+j+G+ScvJkxPYACfaj3R
> c9ZIF/jPoWoOoYe2fRG5lUc=
> =HF12
> -END PGP SIGNATURE-
> --
> gentoo-dev@gentoo.org mailing list
> 
> 


-- 
Joshua Baergen

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] use.force support

[Sven Wegener]

On Tue, Jun 14, 2005 at 01:46:22PM -0400, Alec Warner wrote:
> Sven Wegener wrote:
> >On Mon, Jun 13, 2005 at 05:08:09PM -0400, Alec Warner wrote:
> >
> >>Sven Wegener wrote:
> >>
> >>
> >>>use.force might not be the best name, but it's what we do with it for
> >>>most of our users. Being able to -flag in /etc/portage/profile/use.force
> >>>is just because /etc/portage/profile gets added to the cascaded profile
> >>>chain.  Everything we add to portage that allows a profile to revert
> >>>some behaviour added by parent profiles, can also be done with
> >>>/etc/portage/profile and it's good that way. So, that we're able to
> >>>-flag in use.force is just part of the way cascaded profiles work. It's
> >>>not a feature that will be added just to support use.force. Primary
> >>>reason for use.force is to have a way to activate flags even if USE="-*"
> >>>is in make.conf or environment.
> >>
> >>How is this not just a consequence of USE="-*"...that is what this does; 
> >>turns off ALL use flags.  How is use.force ( or the concept thereof ) 
> >>not breaking the 'easy' interpretation of USE="-*" because now things 
> >>aren't -*, they are -* + use.force things.
> >>
> >>It's one of those "if you use USE="-*" you should know the consequences 
> >>of it...kind of deals.
> >
> >
> >There are some USE flags that must survive the -* thing and already do
> >it. One of them being ARCH, which is always there. And the USE_EXPANDed
> >ones, the current important being being userland_*, kernel_* and elibc_*
> >which are needed for special dependencies and checks. They are not to be
> >modified by users by using USE in make.conf or the environment. They
> >depend on the chosen profile and should always be enabled. We're not
> >talking about every day USE flags, but really special USE flags, like
> >multilib, selinux or the USE_EXPANDed ones that *must* be turned on for
> >the chosen profile. Don't think of them like every day USE flags that
> >allow you to tweak your system, they are used to pass some information
> >from profiles to the ebuilds in a way portage can easily handle it.
> >
> >Hm, use.must sounds bad once I think about it more.
> >
> >Sven
> >
> I'm probably a little behind here, since this has been used for a while, 
> but I guess more discussion and ideas are good.
> 
> It seems like this is an abuse of USE flags, somewhat.  I guess programs 
> could have support for elibc_X or elibc_Y or userland_GNU or 
> userland_DARWIN/BSD but why a USE flag for these?  If they must be 
> forced, force them in the environment outside of USE flag usage.  USE 
> flags are for turning off optional support for programs, that is their 
> overall purpose.  There isn't a use flag for kernel version, there is a 
> function for that.  Why is there not a function to determine 
> userland/arch/libc?

As Diegeo already wrote in his mail, the USE_EXPANDed ELIBC and KERNEL
are also available as variables, but as variables we can't use them to
enable or disable optional dependencies for specific kernels or libcs.
Currently only USE flags are able to do it. I just had a quick look into
our handbook[1] and it mentions the following definition for an USE
flag:

"Such a flag is a keyword that embodies support and
dependency-information for a certain concept."

And for sure, elibc_uclibc or kernel_linux stand for a certain concept.
Same goes for multilib and selinux you mentioned further down in your
mail. And they might have special dependency information and need
special treatment in packages. IMHO they match the definition of USE
flags just like any other USE flag we have. Even though, as I wrote in
my previous mail, they are special, because they are not to be set or
unset by users. You chose to activate them by chosing your profile.
With use.force we're just making sure that they are actually enabled. We
can give elibc_* or kernel_* another name, but in the end, they will
serve the same purpose as USE flags and will be handled by portage in
the same way.

> In this case I think this use.force deal will create more complexity
> in the USE flag area than help.  This is not what use flags are for (
> also for multilib and SELINUX ).

I don't see the complexity here. We're just creating a couple of files
in our profiles that force some flags to be turned on.

Sven 

[1] 
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=2#doc_chap1_sect2

-- 
Sven Wegener
Gentoo Linux Developer
http://www.gentoo.org/


pgpA51AYpPfFV.pgp
Description: PGP signature

Re: [gentoo-dev] The results of an evening of Apache and PAM debugging

[Anthony Gorecki]

On Tuesday, June 14, 2005 2:44 pm, Paul de Vrieze wrote:
> You know that the "normal" way of doing this is to use ldap and krb5

In my opinion, LDAP, by design, is a piece of garbage. I understand the 
principle of its design, however I've never found that design to be 
beneficial for my needs. Before I made the switch to a MySQL-backed database 
to store the account information, I was using OpenLDAP; it just couldn't do 
the job.


> pam_ldap, mod_auth_pam, apache2, and mod_dav_svn seem to not be able to
> work together reliably. There is some kind of strange issue there that's
> very hard to diagnose. Using direct ldap authentication does work.

It's not the user authentication that's the problem, but rather that NSVS 
denies shadow access (appropriately) even though I don't personally need that 
requirement. I think, after a night's rest and a bit of thought, that I'll 
just add a USE flag to the NSVS ebuild to allow users to patch out that 
built-in restriction.


-- 
Anthony Gorecki
Ectro-Linux Foundation


pgpRKpg7A3tF8.pgp
Description: PGP signature

Re: [gentoo-dev] use.force support

[Sven Wegener]

On Mon, Jun 13, 2005 at 06:56:43PM -0400, Ned Ludd wrote:
> I'm in favor of this. Would you mind calling it package.autouse, 
> package.use.auto or are you set on .force?

As Mike already wrote those names are too confusing with the automatic
activated USE flags. We already had some suggestions in this thread, but
none of them actually matched the purpose of the file. At least in my
opinion. use.force matches it best, but the "force" part is a quite hard
term. How about use.profile? Because these USE flags are activated or
needed by the profile.

-- 
Sven Wegener
Gentoo Linux Developer
http://www.gentoo.org/


pgpWHrl8bbsox.pgp
Description: PGP signature

Re: [gentoo-dev] use.force support

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sven Wegener wrote:
> On Mon, Jun 13, 2005 at 06:56:43PM -0400, Ned Ludd wrote:
> 
>>I'm in favor of this. Would you mind calling it package.autouse, 
>>package.use.auto or are you set on .force?
> 
> 
> As Mike already wrote those names are too confusing with the automatic
> activated USE flags. We already had some suggestions in this thread, but
> none of them actually matched the purpose of the file. At least in my
> opinion. use.force matches it best, but the "force" part is a quite hard
> term. How about use.profile? Because these USE flags are activated or
> needed by the profile.

How about use.required, since they're required by the profile?

Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCr5dlXVaO67S1rtsRApFKAKC917D/EwbWvRLY4R8uZ5WwcCk5zgCgw1jE
5solEKLmab3YZXV7qehfXSg=
=VfRe
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New developer: Stefan Briesenick (sbriesen)

[Alin Nastac]

Tom Martin wrote:

>Please welcome Stefan on board.
>
>Regards,
>Tom
>
>  
>
The source of ISDN-related bugs has been shut down :)
Congratulatons, Stefan!



signature.asc
Description: OpenPGP digital signature

Re: kde-theme.py (formerly [gentoo-dev] intention for kde-themes eclass)

[Chris White]

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

> You do know that wget has the "-O" option to specify the name of the 
> downloaded file. Of course that means you can't regex, but you could probably 
> do that from wget's output.

well I did know about -O (in fact, it uses -P for the directory writing), 
however, I'm not sure how well that would work with the actual ebuild writing 
code (SRC_URI and all).


pgpFyiKuKO037.pgp
Description: PGP signature