[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
[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] 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
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
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] 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
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] [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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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)
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
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)
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)
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
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)
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
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
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
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
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
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
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
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)
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
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
-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
