[gentoo-dev] [rfc] transition system loggers to 'adm' user/group

2007-01-01 Thread Mike Frysinger
how do people feel about transitioning the Gentoo standard system logger from 
running as root/root to adm/adm ?  the latest version of sysklogd includes 
some patches so that it can run as non-root and a user requested we make this 
the default ... however, i certainly dont want to start adding a different 
user/group for each system logger cause that's wicked lame
-mike


pgp8CXMVqsDNH.pgp
Description: PGP signature


[gentoo-dev] Re: Re: Re: Re: Re: Dependencies on system packages

2007-01-01 Thread Steve Long
Alec Warner wrote:
 The tricky part then is figuring out whether something doesn't dep upon
 c-compiler because it doesn't need one or because the ebuilds haven't
 been updated.

 I'm out of my depth here- I can't see where that would be a problem?
 
 
 Er, his point being that if you don't do the upgrade all at once, you
 have two classes of package.
 
 1. Packages that don't require C-compiler
 2. Packages that don't yet depend upon C-compiler
 
 When doing the upgrade over a period of time the two classes of package
 become indistinguishable.  Does Foo not need a C compiler, or has it
 just not gotten updated yet, it's impossible to tell without looking, so
 it's very difficult for people to report 'problem packages' because they
 have to unpack and examine the package every time (at worst).
 
I understand that there'd be two types of pkg in the tree; what I don't get
is why that is such a problem. Excuse my missing something obvious. What do
you mean by a `problem package' in this context?

-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] Monthly Gentoo Council Reminder for January

2007-01-01 Thread Mike Frysinger
This is your monthly friendly reminder !  Same bat time (typically the
2nd Thursday at 2000 UTC), same bat channel (#gentoo-council @
irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even
vote on, let us know !  Simply reply to this e-mail for the whole
Gentoo dev list to see.

Keep in mind that every GLEP *re*submission to the council for review
must first be sent to the gentoo-dev mailing list 7 days (minimum)
before being submitted as an agenda item which itself occurs 7 days
before the meeting.  Simply put, the gentoo-dev mailing list must be
notified at least 14 days before the meeting itself.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Re: Re: Re: Re: Re: Dependencies on system packages

2007-01-01 Thread Robert Buchholz
Steve Long wrote:
 Alec Warner wrote:
 Er, his point being that if you don't do the upgrade all at once, you
 have two classes of package.

 1. Packages that don't require C-compiler
 2. Packages that don't yet depend upon C-compiler

 When doing the upgrade over a period of time the two classes of package
 become indistinguishable.  Does Foo not need a C compiler, or has it
 just not gotten updated yet, it's impossible to tell without looking, so
 it's very difficult for people to report 'problem packages' because they
 have to unpack and examine the package every time (at worst).

 I understand that there'd be two types of pkg in the tree; what I don't get
 is why that is such a problem. Excuse my missing something obvious. What do
 you mean by a `problem package' in this context?

A problem package would be one that does not need a C compiler. It can't
be distinguished from the one which was not yet changed to depend on C.

The problem here is that one can not say when the whole tree is updated
to the new standard, because for the packages which were not touched, it
could mean that they needed no change or that they were not looked at yet.

A solution to distinguish the two categories is to mark the packages
which were checked, so you know:
1. If it's checked and doesn't depend on cc - category 1
2. If it's not checked and doesn't depend on cc - category 2

Then, when all packages are checked, the tree is upgraded.

Regards,

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



Re: [gentoo-dev] [rfc] transition system loggers to 'adm' user/group

2007-01-01 Thread Diego 'Flameeyes' Pettenò
On Monday 01 January 2007 10:29, Mike Frysinger wrote:
   how do people feel about transitioning the Gentoo standard system logger
 from running as root/root to adm/adm ?  the latest version of sysklogd
 includes some patches so that it can run as non-root and a user requested
 we make this the default ... however, i certainly dont want to start adding
 a different user/group for each system logger cause that's wicked lame
It would be really nice, especially if the adm group could be used to be able 
to read the logs without using root login :)

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpY6MLGNAeeR.pgp
Description: PGP signature


Re: [gentoo-dev] Packages for grabs

2007-01-01 Thread Seemant Kulleen
Betelgeuse,

I'll take sqlite if you and I can co-maintain it.

Thanks,
-- 
Seemant Kulleen
Developer, Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [rfc] transition system loggers to 'adm' user/group

2007-01-01 Thread Doug Goldstein

Diego 'Flameeyes' Pettenò wrote:

On Monday 01 January 2007 10:29, Mike Frysinger wrote:

  how do people feel about transitioning the Gentoo standard system logger
from running as root/root to adm/adm ?  the latest version of sysklogd
includes some patches so that it can run as non-root and a user requested
we make this the default ... however, i certainly dont want to start adding
a different user/group for each system logger cause that's wicked lame
It would be really nice, especially if the adm group could be used to be able 
to read the logs without using root login :)




Awesome idea Mike. And allowing people to read the logs if they were in 
the adm group would be perfect too.


--
Doug Goldstein [EMAIL PROTECTED]
http://dev.gentoo.org/~cardoe/


--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [rfc] transition system loggers to 'adm' user/group

2007-01-01 Thread Mike Doty
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mike Frysinger wrote:
 how do people feel about transitioning the Gentoo standard system logger from 
 running as root/root to adm/adm ?  the latest version of sysklogd includes 
 some patches so that it can run as non-root and a user requested we make this 
 the default ... however, i certainly dont want to start adding a different 
 user/group for each system logger cause that's wicked lame
 -mike

does syslog-ng and metalog have similar functionality?

- --
===
Mike Doty  kingtaco -at- gentoo.org
Gentoo/AMD64 Strategic Lead
Gentoo Council
Gentoo Developer Relations
Gentoo Recruitment Lead
Gentoo Infrastructure
GPG: E1A5 1C9C 93FE F430 C1D6  F2AF 806B A2E4 19F4 AE05
===
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)

iQCVAwUBRZlJDYBrouQZ9K4FAQLdbgP/QOqeFcCu0zmJ09rWUdFCh3tK59gkhs7R
tCafkQD8zUKiwCwHqMFRQWIUfgjfLn4fOYtcjalu2p4x+//BYEjFIf0trhzOAGRT
8Yxh5zj4KvYJtOJakGKueNmyWtYYlBKuiSZ/9zF4LikVTL7hYQzwobafcBnTU6AY
Y6TvbOBRAdA=
=bXQ9
-END PGP SIGNATURE-
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [rfc] transition system loggers to 'adm' user/group

2007-01-01 Thread Stephen Bennett
On Mon, 01 Jan 2007 09:46:55 -0800
Mike Doty [EMAIL PROTECTED] wrote:

 does syslog-ng and metalog have similar functionality?

SYNOPSIS
   syslog-ng  [ -dFsvVy ] [ -f config-filename ] [ -p
pid-filename ] [ -C chroot-dir ] [ -u user ] [ -g group ]
...
   -u  user, --group=user
  Switch to user.


I'd have to guess so.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] [rfc] transition system loggers to 'adm' user/group

2007-01-01 Thread Petteri Räty
Diego 'Flameeyes' Pettenò kirjoitti:
 On Monday 01 January 2007 10:29, Mike Frysinger wrote:
   how do people feel about transitioning the Gentoo standard system logger
 from running as root/root to adm/adm ?  the latest version of sysklogd
 includes some patches so that it can run as non-root and a user requested
 we make this the default ... however, i certainly dont want to start adding
 a different user/group for each system logger cause that's wicked lame
 It would be really nice, especially if the adm group could be used to be able 
 to read the logs without using root login :)
 

Why not use the wheel group?

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: [rfc] transition system loggers to 'adm' user/group

2007-01-01 Thread Ryan Hill
Petteri Räty wrote:
 Diego 'Flameeyes' Pettenò kirjoitti:
 It would be really nice, especially if the adm group could be used to be 
 able 
 to read the logs without using root login :)

 Why not use the wheel group?

adm is the standard unix group used to access system logs.  there's a
few good reasons you might want to give someone those permissions
without full wheel access.


-- 
by design, by neglect
dirtyepic gentoo orgfor a fact or just for effect
9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [rfc] transition system loggers to 'adm' user/group

2007-01-01 Thread Diego 'Flameeyes' Pettenò
On Monday 01 January 2007 19:38, Petteri Räty wrote:
 Why not use the wheel group?
wheel can su (and sudo usually); you might want to give an user access to the 
logs without using wheel group.

-- 
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ...


pgpkquWyTLEEQ.pgp
Description: PGP signature


Re: [gentoo-dev] [rfc] transition system loggers to 'adm' user/group

2007-01-01 Thread Ciaran McCreesh
On Mon, 1 Jan 2007 20:14:17 +0100 Diego 'Flameeyes' Pettenò
[EMAIL PROTECTED] wrote:
| On Monday 01 January 2007 19:38, Petteri Räty wrote:
|  Why not use the wheel group?
|
| wheel can su (and sudo usually); you might want to give an user
| access to the logs without using wheel group.

Then don't list them in sudoers or give them the root password.

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster   : http://ciaranm.org/show_post.pl?post_id=61



signature.asc
Description: PGP signature


[gentoo-dev] Dieing inside subshells will soon work

2007-01-01 Thread Petteri Räty
It already works in ~arch so will hit stable too sometime in the future.

Regards,
Petteri R=C3=A4ty



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Dieing inside subshells will soon work

2007-01-01 Thread Ciaran McCreesh
On Mon, 01 Jan 2007 22:12:09 +0200 Petteri Räty [EMAIL PROTECTED]
wrote:
| It already works in ~arch so will hit stable too sometime in the
| future.

Better to say, you might soon be able to get away with it, but don't
rely upon it actually working...

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster   : http://ciaranm.org/show_post.pl?post_id=61



signature.asc
Description: PGP signature


Re: [gentoo-dev] Packages for grabs

2007-01-01 Thread Ferris McCormick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 01 Jan 2007 10:51:56 -0500
Seemant Kulleen [EMAIL PROTECTED] wrote:

 Betelgeuse,
 
 I'll take sqlite if you and I can co-maintain it.
 
 Thanks,
 -- 
 Seemant Kulleen
 Developer, Gentoo Linux
 
 -- 
 gentoo-dev@gentoo.org mailing list
I can also help with sqlite if no one else can (i.e., I can help
Seemant with it).

- -- 
Ferris McCormick (P44646, MI) [EMAIL PROTECTED]
Developer, Gentoo Linux (Sparc, Devrel)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6-ecc01.6 (GNU/Linux)

iD8DBQFFmW6wQa6M3+I///cRAo0PAJ9rXuaSog/hypExHgNCEvWvnw1iiACfRAtb
yb8TPvRNkDfP6Sa3gdn5+ho=
=6wif
-END PGP SIGNATURE-

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Dieing inside subshells will soon work

2007-01-01 Thread Petteri Räty
Ciaran McCreesh kirjoitti:
 On Mon, 01 Jan 2007 22:12:09 +0200 Petteri Räty [EMAIL PROTECTED]
 wrote:
 | It already works in ~arch so will hit stable too sometime in the
 | future.
 
 Better to say, you might soon be able to get away with it, but don't
 rely upon it actually working...
 

Well one valid usage I can think of are eclass functions that are called
are called like FOO=$(eclassfunc).

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Dieing inside subshells will soon work

2007-01-01 Thread Ciaran McCreesh
On Mon, 01 Jan 2007 22:28:10 +0200 Petteri Räty [EMAIL PROTECTED]
wrote:
| Ciaran McCreesh kirjoitti:
|  On Mon, 01 Jan 2007 22:12:09 +0200 Petteri Räty
|  [EMAIL PROTECTED] wrote:
|  | It already works in ~arch so will hit stable too sometime in the
|  | future.
|  
|  Better to say, you might soon be able to get away with it, but don't
|  rely upon it actually working...
| 
| Well one valid usage I can think of are eclass functions that are
| called are called like FOO=$(eclassfunc).

Which is all nice and pretty, when it works, yes. But whilst my die
trick is a lot smarter than Aron's, it's still not entirely reliable.
In particular, if you do $(foo || die ; bar ), there's a race condition
which means bar might be executed anyway, and if you do enough arcane
shell voodoo then the die might still end up being lost completely (we
had this with eselect at one point...).

So basically, don't rely upon it working. It means you're much less
likely to be screwed over if you *do* accidentally do a subshell die,
but it doesn't mean that subshell die works.

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster   : http://ciaranm.org/show_post.pl?post_id=61



signature.asc
Description: PGP signature


[gentoo-dev] RFC: making USE_EXPANDed variables incremental

2007-01-01 Thread Stephen Bennett
Following a discussion in #gentoo-portage earlier this evening, it was
suggested that I send out an RFC email for this. So, does anyone object
to requiring that any variable listed in USE_EXPAND be treated as
incremental, at least as far as profile inheritance is concerned?
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Dieing inside subshells will soon work

2007-01-01 Thread Petteri Räty
Ciaran McCreesh kirjoitti:
 On Mon, 01 Jan 2007 22:28:10 +0200 Petteri Räty [EMAIL PROTECTED]
 wrote:
 | Ciaran McCreesh kirjoitti:
 |  On Mon, 01 Jan 2007 22:12:09 +0200 Petteri Räty
 |  [EMAIL PROTECTED] wrote:
 |  | It already works in ~arch so will hit stable too sometime in the
 |  | future.
 |  
 |  Better to say, you might soon be able to get away with it, but don't
 |  rely upon it actually working...
 | 
 | Well one valid usage I can think of are eclass functions that are
 | called are called like FOO=$(eclassfunc).
 
 Which is all nice and pretty, when it works, yes. But whilst my die
 trick is a lot smarter than Aron's, it's still not entirely reliable.
 In particular, if you do $(foo || die ; bar ), there's a race condition
 which means bar might be executed anyway, and if you do enough arcane
 shell voodoo then the die might still end up being lost completely (we
 had this with eselect at one point...).
 
 So basically, don't rely upon it working. It means you're much less
 likely to be screwed over if you *do* accidentally do a subshell die,
 but it doesn't mean that subshell die works.
 

Well at least seeing the stack trace should alarm some bells. If you
have a suggestion on how to to call an eclass function and having die
working, please share it with the rest of us.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: making USE_EXPANDed variables incremental

2007-01-01 Thread Donnie Berkholz
Stephen Bennett wrote:
 Following a discussion in #gentoo-portage earlier this evening, it was
 suggested that I send out an RFC email for this. So, does anyone object
 to requiring that any variable listed in USE_EXPAND be treated as
 incremental, at least as far as profile inheritance is concerned?

That means that the base profiles must have a minimal setting that is
added to in lower profiles, rather than a reasonable default that's
entirely reset in lower profiles (perhaps to a smaller setting), correct?

I'm not a huge fan of that, if that's what it requires, since there is
no way of subtracting USE_EXPAND settings that I know about.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: making USE_EXPANDed variables incremental

2007-01-01 Thread Stephen Bennett
On Mon, 01 Jan 2007 13:24:49 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:

 That means that the base profiles must have a minimal setting that is
 added to in lower profiles, rather than a reasonable default that's
 entirely reset in lower profiles (perhaps to a smaller setting),
 correct?

It would mean that all USE_EXPANDed variables get stacked in the same
way that USE does. The base profile defines a set of defaults, which
gets flags added to or removed from it in other profiles. At present,
from what zmedico told me, it's handled in a weird manner which
essentially does half the job, letting you add flags but not remove
them in subprofiles.
-- 
gentoo-dev@gentoo.org mailing list



[gentoo-dev] New developer: Miroslav Šulc (fordfrog)

2007-01-01 Thread Petteri Räty
It's my pleasure to introduce to you Miroslav fordforg Šulc. He is
joining the über cool java people. Expect him to spend endless night
battling with the horrors of bundled jars and sucky build systems.

He hails from Beroun, Czech Republic. He owns his own IT company. On the
personal side he is married and has a little daughter. He likes soccer,
taking trips on bikes and hiking.

In his dark past he has contributed to the Mozilla Open Directory
Project and learned how to code in a bunch of different programming
languages.

So please give fordfrog the usual froggy welcome.

--
Petteri Räty (Betelgeuse)









signature.asc
Description: OpenPGP digital signature


[gentoo-dev] Re: Re: Re: Re: Re: Re: Dependencies on system packages

2007-01-01 Thread Steve Long
Robert Buchholz wrote:
 A problem package would be one that does not need a C compiler. It can't
 be distinguished from the one which was not yet changed to depend on C.
 
 The problem here is that one can not say when the whole tree is updated
 to the new standard, because for the packages which were not touched, it
 could mean that they needed no change or that they were not looked at yet.

I can understand that as a maintenance issue. My query is whether having two
different types of pkg would effect users in any way.

 A solution to distinguish the two categories is to mark the packages
 which were checked, so you know:
 1. If it's checked and doesn't depend on cc - category 1
 2. If it's not checked and doesn't depend on cc - category 2
 
 Then, when all packages are checked, the tree is upgraded.
 
Sure, that makes sense. It sounds a heckuva lot like a database ;)

Minor point- how can you tell in cat 2 that it definitely does not need a C
compiler if it hasn't been checked? I'm guessing you were tired :) In any
event in terms of maintenance, we'd need a tri-state: unchecked, checked
and needs compiling, checked and doesn't (eg scripts).

In terms of maintaining the metadata, am I right in thinking it's all just
kept within the text files in the tree?

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New developer: Miroslav Šulc (fordfrog)

2007-01-01 Thread Jakub Moc
Petteri Räty napsal(a):
 He hails from Beroun, Czech Republic. He owns his own IT company. On the
 personal side he is married and has a little daughter. He likes soccer,
 taking trips on bikes and hiking.

Yay, the Czech beer conspiracy is growing! Welcome!

*plop*


-- 
Best regards,

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

 ... still no signature   ;)



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New developer: Miroslav Šulc (fordfrog)

2007-01-01 Thread Markus Ullmann
Jakub Moc schrieb:
 Yay, the Czech beer conspiracy is growing! Welcome!

You'd share your beer? :D

Jokey

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New developer: Miroslav Šulc (fordfrog)

2007-01-01 Thread Andrej Kacian
On Tue, 02 Jan 2007 00:40:55 +0200
Petteri Räty [EMAIL PROTECTED] wrote:

 It's my pleasure to introduce to you Miroslav fordforg Šulc. He is
 joining the über cool java people. Expect him to spend endless night
 battling with the horrors of bundled jars and sucky build systems.

Welcome aboard, Miro ! :)

-- 
Andrej Ticho Kacian ticho at gentoo dot org
Gentoo Linux Developer - net-mail, antivirus, sound, x86


signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC: making USE_EXPANDed variables incremental

2007-01-01 Thread Donnie Berkholz
Stephen Bennett wrote:
 On Mon, 01 Jan 2007 13:24:49 -0800
 Donnie Berkholz [EMAIL PROTECTED] wrote:
 
 That means that the base profiles must have a minimal setting that is
 added to in lower profiles, rather than a reasonable default that's
 entirely reset in lower profiles (perhaps to a smaller setting),
 correct?
 
 It would mean that all USE_EXPANDed variables get stacked in the same
 way that USE does. The base profile defines a set of defaults, which
 gets flags added to or removed from it in other profiles. At present,
 from what zmedico told me, it's handled in a weird manner which
 essentially does half the job, letting you add flags but not remove
 them in subprofiles.

I'd rather not make USE_EXPAND incremental if we can't subtract flags.
At present, we accomplish that by simply resetting the whole thing in
subprofiles. But the proposal seems to make impossible any subprofile of
a valid profile that wishes to negate a setting of the parent.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] RFC: making USE_EXPANDed variables incremental

2007-01-01 Thread Ciaran McCreesh
On Mon, 01 Jan 2007 15:27:43 -0800 Donnie Berkholz
[EMAIL PROTECTED] wrote:
| I'd rather not make USE_EXPAND incremental if we can't subtract flags.

You mean via -flag? Or via -*? Both are valid in incrementals.

-- 
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis is faster   : http://ciaranm.org/show_post.pl?post_id=61



signature.asc
Description: PGP signature


Re: [gentoo-dev] RFC: making USE_EXPANDed variables incremental

2007-01-01 Thread Donnie Berkholz
Stephen Bennett wrote:
 The proposal means that all variables listed in USE_EXPAND get handled
 exactly as USE does where profile inheritance is concerned. Subprofiles
 can add to and remove from the value in the parent profile just as they
 can for USE.

Did I misread what you said earlier?

Stephen Bennett wrote:
 At present,
 from what zmedico told me, it's handled in a weird manner which
 essentially does half the job, letting you add flags but not remove
 them in subprofiles.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] New developer: Miroslav Šulc (fordfrog)

2007-01-01 Thread Miroslav Šulc (fordfrog)

Thanks for the greetings from Czechoslovakia :-)

Jakub Moc wrote:

Petteri Räty napsal(a):
  

He hails from Beroun, Czech Republic. He owns his own IT company. On the
personal side he is married and has a little daughter. He likes soccer,
taking trips on bikes and hiking.



Yay, the Czech beer conspiracy is growing! Welcome!

*plop*


  

--
Miroslav Šulc (fordfrog)
Java Team

--
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: making USE_EXPANDed variables incremental

2007-01-01 Thread Stephen Bennett
On Mon, 01 Jan 2007 17:24:03 -0800
Donnie Berkholz [EMAIL PROTECTED] wrote:

 Stephen Bennett wrote:
  The proposal means that all variables listed in USE_EXPAND get
  handled exactly as USE does where profile inheritance is concerned.
  Subprofiles can add to and remove from the value in the parent
  profile just as they can for USE.
 
 Did I misread what you said earlier?
 
 Stephen Bennett wrote:
  At present,
  from what zmedico told me, it's handled in a weird manner which
  essentially does half the job, letting you add flags but not remove
  them in subprofiles.

At present -- that's the behaviour that I want to change by making
them incremental.
-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] RFC: making USE_EXPANDed variables incremental

2007-01-01 Thread Donnie Berkholz
Stephen Bennett wrote:
 On Mon, 01 Jan 2007 17:24:03 -0800
 Donnie Berkholz [EMAIL PROTECTED] wrote:
 
 Stephen Bennett wrote:
 The proposal means that all variables listed in USE_EXPAND get
 handled exactly as USE does where profile inheritance is concerned.
 Subprofiles can add to and remove from the value in the parent
 profile just as they can for USE.
 Did I misread what you said earlier?

 Stephen Bennett wrote:
 At present,
 from what zmedico told me, it's handled in a weird manner which
 essentially does half the job, letting you add flags but not remove
 them in subprofiles.
 
 At present -- that's the behaviour that I want to change by making
 them incremental.

Oh, I see. I thought you were describing the present behavior of the
change as it would affect USE_EXPAND. As long as I can do
VIDEO_CARDS=-vesa, I'm happy with it.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature


[gentoo-dev] openmosix maintainer needed

2007-01-01 Thread Daniel Drake

Hi,

openmosix has been hardmasked for a long time:

# Tim Yamin [EMAIL PROTECTED] (07 Aug 2006)
# Security mask
# Bugs #135167, #137623, #137626, #138617, #139321,
# #139475, #139641, #140444, #141503, #142616, #142617
sys-kernel/openmosix-sources
sys-cluster/openmosixview
sys-cluster/openmosixtest
sys-cluster/openmosix-user
sys-cluster/openmosixwebview
sys-cluster/openmosix-3dmon-stats

It should be removed from portage, but as this is quite a big thing I'm 
expressing some haste before kicking it. Is anyone working on bringing 
this back up to date? Any strong objections to the actual removal 
(despite it being hardmasked already)?


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



Re: [gentoo-dev] Dieing inside subshells will soon work

2007-01-01 Thread Mike Frysinger
On Monday 01 January 2007 15:12, Petteri Räty wrote:
 It already works in ~arch so will hit stable too sometime in the future.

until it completely works (versus just mostly works), why mention this ?  it'd 
be better to continue on with the 'dont use subshells' especially since it 
hasnt really been limiting us in terms of ebuild development
-mike


pgpAjwZj3BQWR.pgp
Description: PGP signature


Re: [gentoo-dev] [rfc] transition system loggers to 'adm' user/group

2007-01-01 Thread Mike Frysinger
On Monday 01 January 2007 12:46, Mike Doty wrote:
 Mike Frysinger wrote:
  how do people feel about transitioning the Gentoo standard system logger
  from running as root/root to adm/adm ?  the latest version of sysklogd
  includes some patches so that it can run as non-root and a user requested
  we make this the default ... however, i certainly dont want to start
  adding a different user/group for each system logger cause that's wicked
  lame

 does syslog-ng and metalog have similar functionality?

maybe, but no one has this as the default behavior, so ...
-mike


pgpY5pGNaKsRh.pgp
Description: PGP signature


Re: [gentoo-dev] openmosix maintainer needed

2007-01-01 Thread Josh Saddler
Daniel Drake wrote:
 Hi,
 
 openmosix has been hardmasked for a long time:
 
 # Tim Yamin [EMAIL PROTECTED] (07 Aug 2006)
 # Security mask
 # Bugs #135167, #137623, #137626, #138617, #139321,
 # #139475, #139641, #140444, #141503, #142616, #142617
 sys-kernel/openmosix-sources
 sys-cluster/openmosixview
 sys-cluster/openmosixtest
 sys-cluster/openmosix-user
 sys-cluster/openmosixwebview
 sys-cluster/openmosix-3dmon-stats
 
 It should be removed from portage, but as this is quite a big thing I'm
 expressing some haste before kicking it. Is anyone working on bringing
 this back up to date? Any strong objections to the actual removal
 (despite it being hardmasked already)?

Please let the GDP know when and if this package is removed, as we still
have a document for it (though it hasn't been touched since 2003...).

Thanks,

Josh



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: Dependencies on system packages

2007-01-01 Thread Robert Buchholz
Steve Long wrote:
 Robert Buchholz wrote:
 The problem here is that one can not say when the whole tree is updated
 to the new standard, because for the packages which were not touched, it
 could mean that they needed no change or that they were not looked at yet.
 I can understand that as a maintenance issue. My query is whether having two
 different types of pkg would effect users in any way.

You're right, it would not be a problem for usability.


 A solution to distinguish the two categories is to mark the packages
 which were checked, so you know:
 1. If it's checked and doesn't depend on cc - category 1
 2. If it's not checked and doesn't depend on cc - category 2

 Then, when all packages are checked, the tree is upgraded.

 Sure, that makes sense. It sounds a heckuva lot like a database ;)
 
 Minor point- how can you tell in cat 2 that it definitely does not need a C
 compiler if it hasn't been checked? I'm guessing you were tired :) In any
 event in terms of maintenance, we'd need a tri-state: unchecked, checked
 and needs compiling, checked and doesn't (eg scripts).

No, no. I did not mean that category 2 does not need a C compiler. I
referred to Alec's mail which had 2. Packages that don't yet depend
upon C-compiler.
As for the state problem, when saving checked and unchecked as a
package's metadata, you will get the other properties (needs cc, needs
insert system dep) out of its DEPEND.


 In terms of maintaining the metadata, am I right in thinking it's all just
 kept within the text files in the tree?

Since the tree itself is the best database of the packages available,
anything else would be a lot more overhead.

But I had the impression the idea was discarded anyway. So I should
focus my thoughts somewhere else :-)


Ciao,

Robert

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] New developer: Robert Buchholz (rbu)

2007-01-01 Thread Robert Buchholz
Petteri Räty wrote:
 It's my pleasure to introduce to you Robert rbu Buchholz. 

Before it's too late, I wanted to send thanks to Jokey who was and is a
great mentor.
And also to all who sent greetings. Hope to see some of you at the next
German conspiracy meeting.

Robert


-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-portage-dev] Masked by corruption

2007-01-01 Thread James Cloos
Thanks for the replies; my apologies for the delay in repying
back

Based on the replies, I was able to track the problem down.  The cdb
patch is incompatable with the latest version of portage.  Removing
that from /etc/portage/modules allows portage to work.

That said, there is still the bug of using the filesystem as a
database.  It now takes about thirty minutes for any emerge run
to finish reading in /var/cache/edb/dep and most of /var/db/pkg.

It is imperative that portage use a single file for those databases.
(One per db is fine, in case the above is ambiguous.)

This is the same problem that git ran into, leading to pack files,
or that cnews and inn hit, leading to the rotating spool files.  

It may work reasonably well on a headless server, with only a few
packages installed.  But on a general purpose workstation with
many packages installed it falls over hard.

Incidently, the above 30 minute minimum run time is even when
running with --nodeps.

I'll also be posting a bug report about unmerging.  Portage is
stat(2)ing *every* file under a directory that might need removal
rather than just checking whether there are any entries in the dir.
Running stat(2) on everything in /usr/lib, /usr/bin, /usr/share/doc
and similar completely thrashes the dirent cache.  It is even worse
than running ldconfig when no changes were made in dirs that ldconfig
monitors.

Thanks for the work; I hope to see performance improvements this year.

-JimC
-- 
James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6


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



Re: [gentoo-portage-dev] Masked by corruption

2007-01-01 Thread Zac Medico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James Cloos wrote:
 Thanks for the replies; my apologies for the delay in repying
 back
 
 Based on the replies, I was able to track the problem down.  The cdb
 patch is incompatable with the latest version of portage.  Removing
 that from /etc/portage/modules allows portage to work.
 
 That said, there is still the bug of using the filesystem as a
 database.  It now takes about thirty minutes for any emerge run
 to finish reading in /var/cache/edb/dep and most of /var/db/pkg.
 
 It is imperative that portage use a single file for those databases.
 (One per db is fine, in case the above is ambiguous.)

In =portage-2.1.2_rc4-r2 t does that now for installed package (see
bug #158931).  For /var/cache/edb/dep the sqlite module is available
(requires pysqlite or python-2.5 with sqlite support enabled).

 This is the same problem that git ran into, leading to pack files,
 or that cnews and inn hit, leading to the rotating spool files.  
 
 It may work reasonably well on a headless server, with only a few
 packages installed.  But on a general purpose workstation with
 many packages installed it falls over hard.
 
 Incidently, the above 30 minute minimum run time is even when
 running with --nodeps.

That's been fixed for bug #158649.  If you make extensive use of
PORTDIR_OVERLAY then you will probably want to run emerge --regen
after each sync to avoid having to generate cache at other times.

 I'll also be posting a bug report about unmerging.  Portage is
 stat(2)ing *every* file under a directory that might need removal
 rather than just checking whether there are any entries in the dir.
 Running stat(2) on everything in /usr/lib, /usr/bin, /usr/share/doc
 and similar completely thrashes the dirent cache.  It is even worse
 than running ldconfig when no changes were made in dirs that ldconfig
 monitors.
 

Thanks.  Thats fixed in svn r5443.

 Thanks for the work; I hope to see performance improvements this year.
 
 -JimC

Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFmeX6/ejvha5XGaMRAugNAJ9fD272i73k7I+OPdLoKwT4L5LutQCbBdbB
zV1QY1Wd2icP8AzagGcyg5E=
=XLFd
-END PGP SIGNATURE-
-- 
gentoo-portage-dev@gentoo.org mailing list