Re: [gentoo-dev] New developer: Robert Buchholz (rbu)
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-dev] Re: Re: Re: Re: Re: Re: Dependencies on system packages
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 ) 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] openmosix maintainer needed
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] [rfc] transition system loggers to 'adm' user/group
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] Dieing inside subshells will soon work
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
[gentoo-dev] openmosix maintainer needed
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] RFC: making USE_EXPANDed variables incremental
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
Re: [gentoo-dev] RFC: making USE_EXPANDed variables incremental
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] New developer: 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
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] RFC: making USE_EXPANDed variables incremental
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. > 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. I wrote: > > 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. 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: making USE_EXPANDed variables incremental
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
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] New developer: Miroslav Šulc (fordfrog)
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 Gentoo Linux Developer - net-mail, antivirus, sound, x86 signature.asc Description: PGP signature
Re: [gentoo-dev] New developer: Miroslav Šulc (fordfrog)
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)
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=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Re: Re: Re: Re: Re: Dependencies on system packages
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
[gentoo-dev] New developer: Miroslav Šulc (fordfrog)
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
Re: [gentoo-dev] RFC: making USE_EXPANDed variables incremental
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
Re: [gentoo-dev] RFC: making USE_EXPANDed variables incremental
Donnie Berkholz wrote: 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. Ability to subtract comes with incremental stacking, which I think we are talking about here, at least I hope so. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: making USE_EXPANDed variables incremental
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] Dieing inside subshells will soon work
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
[gentoo-dev] RFC: making USE_EXPANDed variables incremental
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
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
Re: [gentoo-dev] Dieing inside subshells will soon work
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] Packages for grabs
-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
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
[gentoo-dev] Dieing inside subshells will soon work
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] [rfc] transition system loggers to 'adm' user/group
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
Re: [gentoo-dev] [rfc] transition system loggers to 'adm' user/group
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
[gentoo-dev] Re: [rfc] transition system loggers to 'adm' user/group
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
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
Re: [gentoo-dev] [rfc] transition system loggers to 'adm' user/group
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 ] [ -p ] [ -C ] [ -u ] [ -g ] ... -u , --group= 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
-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
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] Packages for grabs
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
[gentoo-dev] Re: [rfc] transition system loggers to 'adm' user/group
Diego 'Flameeyes' Pettenò wrote: > It would be really nice, especially if the adm group could be used to be able > to read the logs without using root login :) ++ on that :) Greetz Jokey -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [rfc] transition system loggers to 'adm' user/group
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] Re: Re: Re: Re: Re: Dependencies on system packages
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
[gentoo-dev] Packages for grabs
As arj is retiring (https://bugs.gentoo.org/show_bug.cgi?id=51665) the following list of packages are still without a maintainer: dev-db/sqlite dev-db/sqliteodbc dev-util/archway dev-util/bazaar dev-util/tla If you decide to take care of some of the packages, take also the bugs from the following list. I will be fixing stuff for sqlite now but I have so much other stuff to do that it would be better to find someone else in the long term. http://tinyurl.com/vmu2f Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Monthly Gentoo Council Reminder for January
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
[gentoo-dev] Re: Re: Re: Re: Re: Dependencies on system packages
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] [rfc] transition system loggers to 'adm' user/group
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
