[gentoo-dev] Distro Development Talk
(I'm subscribed in digest mode, so please CC me on any responses you want me to see) I'm a developer for a neighbour distro, Arch Linux, and I'm starting up a site to discuss distro development issues. The goal is to have a site that describes solutions to common distro problems and shares information between distros more. Because the site is just starting, I'm looking for some people from the other distros to add content. If you're interested in sharing distro development information, please contribute to this site. http://distrodev.org Thanks, Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are. pgpKKHEejuy5i.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On 8/16/05, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > GLEP 31 is withdrawn until Gentoo gets some means of removing commit > access from people who say "nyah nyah I don't feel like following the > rules and so I'll just carry on breaking stuff as I see fit". As it > stands I've been told by various people that they have no interest in > ensuring that their commits are UTF-8 safe (even if there's an > automated check that warns them when they're about to break something), > and I don't consider it fair to force lots of repoman warnings upon > other developers who *do* care about that kind of thing who just happen > to be the next person to touch a package that got broken. Seems to me that such people should have their developer status revoked. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] USE_EXPAND and IUSE
On Wednesday 22 June 2005 02:07, Donnie Berkholz wrote: > Alec Warner wrote: > > Donnie Berkholz wrote: > > The reasoning for that is that hardware support doesn't make sense as > > USE flags, so it should be something else. In this case, that was > > INPUT_DEVICES. We haven't been able to take much advantage of it yet, > > but it may work out better after X's upstream modularization. > > > >> So those make no sense but 3dnow,sse,sse2,makemyprocessorgrow are > >> fine as USE flags? Those also enable support for special hardware. > > I think we had that argument already. Try searching the archives and see > whether you can find it. I tried searching but no luck. Care to elaborate on how "building optional support for drivers" doesn't fall under the umbrella of "building optional support"? -- Jason Stubbs pgprRwCi8t55Z.pgp Description: PGP signature
Re: [gentoo-dev] Devconference archives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: > That being said, thanks to IU for doing the webcast... now everybody > gets to see what we look like... *grin* If you're like me, you have a perfect face... for email. :P -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDAqRe2QTTR4CNEQARAseAAKCjAE5e4Lu5nfw337AcKR1jiPc8/ACeNdTs ALsdqQbyiJnsaoc5a+0J3H8= =vCyM -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tuesday 16 August 2005 09:52 pm, Ciaran McCreesh wrote: > On Wed, 17 Aug 2005 10:46:23 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | On Wednesday 17 August 2005 08:38, Ciaran McCreesh wrote: > | > GLEP 31 is withdrawn until Gentoo gets some means of removing commit > | > access from people who say "nyah nyah I don't feel like following > | > the rules and so I'll just carry on breaking stuff as I see fit". > | > As it stands I've been told by various people that they have no > | > interest in ensuring that their commits are UTF-8 safe (even if > | > there's an automated check that warns them when they're about to > | > break something), and I don't consider it fair to force lots of > | > repoman warnings upon other developers who *do* care about that > | > kind of thing who just happen to be the next person to touch a > | > package that got broken. > | > | Repoman could check the commit message for being valid UTF-8 and > | simply not allow the commit if it isn't. :) > > Well, I have a tool already that checks that. But it doesn't help when > we have developers who don't use repoman, who forcibly override repoman > fatal errors and who just randomly remove anything they think is > causing errors... yes, but lets work with what we have ... besides, it'll be easy to pick out who used repoman and who didnt by checking who has broken UTF8 commit messages ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wed, 17 Aug 2005 10:46:23 +0900 Jason Stubbs <[EMAIL PROTECTED]> wrote: | On Wednesday 17 August 2005 08:38, Ciaran McCreesh wrote: | > GLEP 31 is withdrawn until Gentoo gets some means of removing commit | > access from people who say "nyah nyah I don't feel like following | > the rules and so I'll just carry on breaking stuff as I see fit". | > As it stands I've been told by various people that they have no | > interest in ensuring that their commits are UTF-8 safe (even if | > there's an automated check that warns them when they're about to | > break something), and I don't consider it fair to force lots of | > repoman warnings upon other developers who *do* care about that | > kind of thing who just happen to be the next person to touch a | > package that got broken. | | Repoman could check the commit message for being valid UTF-8 and | simply not allow the commit if it isn't. :) Well, I have a tool already that checks that. But it doesn't help when we have developers who don't use repoman, who forcibly override repoman fatal errors and who just randomly remove anything they think is causing errors... -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpjJiB3xd2EH.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wednesday 17 August 2005 08:38, Ciaran McCreesh wrote: > GLEP 31 is withdrawn until Gentoo gets some means of removing commit > access from people who say "nyah nyah I don't feel like following the > rules and so I'll just carry on breaking stuff as I see fit". As it > stands I've been told by various people that they have no interest in > ensuring that their commits are UTF-8 safe (even if there's an > automated check that warns them when they're about to break something), > and I don't consider it fair to force lots of repoman warnings upon > other developers who *do* care about that kind of thing who just happen > to be the next person to touch a package that got broken. Repoman could check the commit message for being valid UTF-8 and simply not allow the commit if it isn't. :) -- Jason Stubbs pgp2l17QeUQGd.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wednesday 17 August 2005 07:18, Mike Frysinger wrote: > suggestion: > stop keeping ChangeLog files in CVS and instead, let them be generated > automagically by the cvs server using the last of > commit messages. You stole my idea! I guess I better ack it then. ;) -- Jason Stubbs pgpkxElZpa6Zd.pgp Description: PGP signature
[gentoo-dev] New GPG key
Hi guys, i had to reinstall my system so i lost my GPG key. So i generated another and the new one is 0xAAC32A11. If any other thing is needed (to update the dev-list page on www.gentoo.org for example), please mail me or contact me on irc. Thanks, Carlos "r3pek" Silva signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tue, 16 Aug 2005 21:03:21 -0400 Alec Warner <[EMAIL PROTECTED]> wrote: | Also forcing a Changelog syntax makes portage's -l feature useful, | since it attempts to parse the Changelog to provide sane | entries...but some Changelogs don't seem to be in the correct syntax | that the -l functionality requires. With a changelog standard this | tool will be much more useful. There is a standard. It's called "whatever echangelog generates". If everyone used echangelog, nearly all of Mike's original points would be invalid. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpgIA6I8hx3o.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Huddleston wrote: > On Tue, 2005-08-16 at 18:18 -0400, Mike Frysinger wrote: > >>suggestion: >>stop keeping ChangeLog files in CVS and instead, let them be generated >>automagically by the cvs server using the last of commit >>messages. if you really want to keep a commit message out of the changelog, >>then we come up with a simple policy of prefixing the message with a period >>(to keep it hidden :P). > > > I like the idea. This should force people to actually make their cvs > commit statements worth something. Also forcing a Changelog syntax makes portage's -l feature useful, since it attempts to parse the Changelog to provide sane entries...but some Changelogs don't seem to be in the correct syntax that the -l functionality requires. With a changelog standard this tool will be much more useful. - -Alec Warner (antarus) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQwKM2GzglR5RwbyYAQIWDw//WqWVf7BUhU++4RjHUYeLd95xxpPo7fmk EEebEFF7XMjIij9YYticJvOfDKsjzndU1Vkd/F27WHdDe/NCTGJQcCmTGjJfuKKa JRlD2U5Em5QF/j93dOeRJzOIBCbNRbxQevze4fU8SBfDdB1MRb0g3Y5fd0An991h 4GiO9UtCrNmSV51R6KFCBW76YbaV7pWFhDNJRjsWLhfQZh/sCKfugduv4boJVOih e2GIyiP4C0dUJnXlpbfsJuNsdxA783inKfSyy4p9+iuCdDd11rSvua2mz2HdZIVB 3BvWatoWTDflNpcxrmpHnmTj1MN9usC4van1Yq9KPogSBcwkIjyCmA7YVB5stFxs e2sBGDftmBXzC3ZOCa0IiWkE3Kr4gC5eCSHkDDJ7lW+u8FojSCxUm2my5RO4rSAr Wm0cB+LojvANZV93bz4qfF90B4IBr6w8fE6vCfC4WsoeW9G/EVtsjYvIHjvv20YZ cLQAgWDPsOT9bxfsHgJXAKqot3erKmVksBbV6cwWvxRkjwp0k09IpbEytxxFUs+3 CtC2TOERPk2NWdsfRimRSZz0zUUBOMzSUX1+88W4L7GASG7DuuXK7TpaZvMOwxEy UaBXhH+oAwk3lePXx/3HvQpC0T2oSUwGGr7CBR3z7VRhwAcO04AiHVt7tQie8dvO G5eWBwF0UCE= =Yj6C -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Looking for developers for a new 'Planet' web-app
Daniel Drake wrote: Examples of what people are requesting: - Ability to browse the 'archives' (i.e. the content which has dropped off the end of the page, which planet discards) - Ability to search the content and the archives - Ability to browse by Gentoo herd, i.e. view the weblogs of the apache maintainers. I patched the Planet source to add all the entries to an sql database then wrote a quick CherryPy demo [1] that uses the existing Planet's template system. The example just has the entries for a few random developers. You can search the titles or full text. Source code available [2] for the curious. You'll need dev-python/cherrypy and USE='sqlite' dev-python/sqlobject. If I can get ahold of the config.ini and template for the actual Planet Gentoo I'll be able to get the herd info from usernames (and make it look like the real deal). [1] http://gentooexperimental.org:9898/ [2] http://dev.gentoo.org/~pythonhead/planetdb.tbz2 -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tue, 2005-08-16 at 18:18 -0400, Mike Frysinger wrote: > suggestion: > stop keeping ChangeLog files in CVS and instead, let them be generated > automagically by the cvs server using the last of commit > messages. if you really want to keep a commit message out of the changelog, > then we come up with a simple policy of prefixing the message with a period > (to keep it hidden :P). I like the idea. This should force people to actually make their cvs commit statements worth something. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
Mike Frysinger wrote: > suggestion: > stop keeping ChangeLog files in CVS and instead, let them be generated > automagically by the cvs server using the last of commit > messages. As I already use a bash function called ecommit which writes a ChangeLog entry before it runs repoman and finally commits with the same message, I'm obviously all for this. -- [EMAIL PROTECTED] [EMAIL PROTECTED] http://citizen428.net/http://dev.gentoo.org/~citizen428/ GnuPG key: 0x90CA09E3/4D21 916E DBCE 72B8 CDC5 BD87 DE2D 91A2 90CA 09E3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tue, 16 Aug 2005 19:18:21 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: | On Tuesday 16 August 2005 07:03 pm, Robin H. Johnson wrote: | > On Tue, Aug 16, 2005 at 06:18:29PM -0400, Mike Frysinger wrote: | > > logic: | > Question: | > - are CVS commit messages UTF8 safe? | | GLEP 31 came to mind when i was writing the e-mail but i forgot to | mention it ... maybe ciaran can hop in here GLEP 31 is withdrawn until Gentoo gets some means of removing commit access from people who say "nyah nyah I don't feel like following the rules and so I'll just carry on breaking stuff as I see fit". As it stands I've been told by various people that they have no interest in ensuring that their commits are UTF-8 safe (even if there's an automated check that warns them when they're about to break something), and I don't consider it fair to force lots of repoman warnings upon other developers who *do* care about that kind of thing who just happen to be the next person to touch a package that got broken. *shrug* So, if you want to be nice and use UTF-8, please do so. CVS is fine with it. Chances are whoever writes the CVS -> changelog tool will get it wrong with text wrapping at least once, but it's easy enough to fix. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpEvO7qnt4ds.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tuesday 16 August 2005 07:03 pm, Robin H. Johnson wrote: > On Tue, Aug 16, 2005 at 06:18:29PM -0400, Mike Frysinger wrote: > > logic: > Question: > - are CVS commit messages UTF8 safe? GLEP 31 came to mind when i was writing the e-mail but i forgot to mention it ... maybe ciaran can hop in here -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tue, Aug 16, 2005 at 06:18:29PM -0400, Mike Frysinger wrote: > stop keeping ChangeLog files in CVS and instead, let them be generated > automagically by the cvs server using the last of commit > messages. if you really want to keep a commit message out of the changelog, > then we come up with a simple policy of prefixing the message with a period > (to keep it hidden :P). I'm in favour of this. As an upstream developer of phpMyAdmin, we've used this procedure for a long time, using cvs2cl for this purpose (see my name in the cvs2cl contributers list as well ;-). We'd need to add a bit of code to put in the new ebuild extra stuff, but other than that, it should work out of the box. > logic: Question: - are CVS commit messages UTF8 safe? -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpdvjQkemmFv.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Aug 16, 2005, at 5:18 PM, Mike Frysinger wrote: logic: - i'm lazy - i hate typing the samething twice (yes, bash scripting with echangelog can kind of take care of this) ... it doesnt handle if you want to use different commit messages for different files - shrinks ChangeLog size for packages which have been around a very long time - forces cvs log messages to actually be worthwhile to read and makes browsing cvs history much nicer (it's very easy to look at the differences between two files and match up a good commit message rather than trying to figure out what message in the ChangeLog goes with it, assuming there is one) - easily standardize ChangeLog format wrt to header, copyrights, licensing, message formatting, name/date format - generate dates in UTC down to the second rather than having devs hand type them in their local timezone for just the current day - maybe some other things i havent thought of - i'm lazy Me likey. --Kito -mike -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] generating ChangeLog files automatically from `cvs commit`
suggestion: stop keeping ChangeLog files in CVS and instead, let them be generated automagically by the cvs server using the last of commit messages. if you really want to keep a commit message out of the changelog, then we come up with a simple policy of prefixing the message with a period (to keep it hidden :P). logic: - i'm lazy - i hate typing the samething twice (yes, bash scripting with echangelog can kind of take care of this) ... it doesnt handle if you want to use different commit messages for different files - shrinks ChangeLog size for packages which have been around a very long time - forces cvs log messages to actually be worthwhile to read and makes browsing cvs history much nicer (it's very easy to look at the differences between two files and match up a good commit message rather than trying to figure out what message in the ChangeLog goes with it, assuming there is one) - easily standardize ChangeLog format wrt to header, copyrights, licensing, message formatting, name/date format - generate dates in UTC down to the second rather than having devs hand type them in their local timezone for just the current day - maybe some other things i havent thought of - i'm lazy -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect modules
> My opinion is this: Keeping eselect modules inside eselect's SVN repo > results in: > a) More eyes reading the code (read: QA) I think the point you're trying to make here is that the QA is easier to accomplish for you, and that certainly is true. I think having modules in app-admin/eselect-/files/ or in > b) The possibility to change all modules in one move in case we change > ~ something like a default behaviour, or function names, etc. Well, this default behavior shouldn't change once 1.0 is finished, so I think ciaranm's point is valid. Once 1.0 is released, the API should stabilize, and you should let developers utilize this framework, but until then, perhaps a little bit tighter control is prudent. > Having all modules in the same repository is imho more important than > having only one package to distribute it. I can happily live with > x11-base/opengl-update installing a module inside > ~ /usr/share/eselect/modules > and creating a symlink for opengl-update. Ok, then I can certainly live with this until 1.0 stabilizes (and perhaps longer if the development model works well) as long as it's the repository we're talking about and not the package or tarball (meaning I'd like to bzip2 my eselect module from the repository and use that in the package rather than getting it out of an eselect- tarball). > I'd prefer app-admin/eselect-, but i could happily live with > app-eselect/. But i don't think that we need a whole new > category for eselect modules. Not right now, and probably not in future, > either. Yeah, app-admin/eselect- seems reasonable. > Jeremy, do you know about the 'old-script-name' feature that Ciaran > introduced? > By symlinking /usr/bin/eselect to one of these > > ~ -update, -config, -manager, config-, > ~ update- or manage-, > > a call to it will be handles as if the user called 'eselect '. > You might probably want to consider this for your opengl-update package. Actually, no I didn't, but I'll look into it later tonight. Thanks, Jeremy signature.asc Description: This is a digitally signed message part
[gentoo-dev] Smalltalk packages
Hello, I am writing this email to ask for opinions and discuss some issues of the SmallTalk packages that we have in the tree. We currently have the following smalltalk implementations in the tree (STI): dev-lang/gnu-smalltalk dev-lang/smalltalkx dev-lang/squeak dev-lang/squeak-basicimage dev-lang/squeak-fullimage Let's consider the following points about the STI's before we go on: 1 - They are usually written in smalltalk itself (e.g squeak). 2 - STI's don't make a clear distinction between the programming language, the IDE and even the installer of the implementation. 3 - STI's have their own configuration scripts (dialog-based sometimes) to customize and compile (from point 2 also). Because of these reasons, and probably others i forget at the moment, vendors usually release the STI's in binary form, with all the standard classes compiled by default, only making a compilation necessary if the user needs a very specific feature _and_ which is usually enabled through special scripts/options/magic/vodoo and that aren't really something easy to tweak with our ebuilds. Now, for a brief report of these packages in our tree: dev-lang/squeak-*: compiles/installs fine so far. Though it isn't the latest stable release, who takes care of this package anyway?, i heard someone was proposing to remove it from the tree actually. (yes, kind of hard to mantain) dev-lang/gnu-smalltalk: compiles *fine* , though we need to patch it with kind of an ugly hack to allow re-installations of the implementation. dev-lang/smalltalkx: this package is _horribly_ outdated, plus, it doesn't compile fine here, (does it work for anyone else out there?). Of all of these packages, i think gnu-smalltalk is the only one who could survive in the tree (As long as we apply ugly patches). The main reason of this email is that I am trying to keep alive some of these implementations in the tree, updating smalltalkx to the new 5.6 version, _BUT_ , installing the version in binary form instead, since apparently can't be compiled with <= glibc2.2. The binary version works fine here (using glibc2.3.x/gcc3), anyone interested can test the ebuild http://dev.gentoo.org/~araujo/stuff/ebuilds/smalltalkx-5.2.6.ebuild , and fetch the binaries from http://dev.gentoo.org/~araujo/stuff/bin/ . Please test it and send me feedbacks, to this list or my email if you are interested to address these issues, if not, well.. i think we'll end up removing these packages, and though ST is dying, it is the only TRUE OO language ;-) Cheers, -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect modules
On Tue, 16 Aug 2005 21:52:25 +0200 Danny van Dyk <[EMAIL PROTECTED]> wrote: | b) The possibility to change all modules in one move in case we change | ~ something like a default behaviour, or function names, etc. That kind of thing shouldn't happen once a stable release is out... -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpHsPftqAxYu.pgp Description: PGP signature
Re: [gentoo-dev] eselect modules
On Tue, 16 Aug 2005 15:38:08 -0400 Chris Gianelloni <[EMAIL PROTECTED]> wrote: | There's also the size issue. I use opengl-update on the LiveCD | builds, and have exactly zero need for *any* other eselect module, so | why should I be required to have them all to just get the one that I | need? Heh. You complain about the size of an eselect module, and then go and include a stinkin' great bitmap splash screen. Anyway, I'm in favour of separate distribution of modules once eselect reaches a 1.0 release. Until then there's still a chance someone might go and change the API... -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp57cnfewKex.pgp Description: PGP signature
Re: [gentoo-dev] eselect modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jeremy, (Just a note: the follwing expresses my opinion, i don't speak for the other eselect devs) Jeremy Huddleston schrieb: | I've recently updated opengl-update to use the eselect framework. I | think the team has done a great job as it was extremely easy to port the | bash script to an eselect module. However, when I placed it in the :-) | portage tree, it sparked a little bit of a policy discussion between | myself and the core eselect devs on how to best include modules in the | tree, so I'd like to let other devs chime in as well. [snip] | The eselect developers want to keep all eselect modules in their svn | repository and distributed through a single package (app-admin/eselect). | Their main reasons for this are better QA and less overhead for releases | and merging. My opinion is this: Keeping eselect modules inside eselect's SVN repo results in: a) More eyes reading the code (read: QA) b) The possibility to change all modules in one move in case we change ~ something like a default behaviour, or function names, etc. Having all modules in the same repository is imho more important than having only one package to distribute it. I can happily live with x11-base/opengl-update installing a module inside ~ /usr/share/eselect/modules and creating a symlink for opengl-update. | I have a problem with this policy because: | 1) Stability of the modules should not be tied to stability of the core | package. Basically, I'd like to determine when my modules get pushed | into stable without considering how it'll effect the eselect modules of | other developers. Similarly, I don't want bugs in another module | holding up my module from going into stable. Understandable. | 2) Not all users will want all modules. The goal of the eselect project | is to provide a framework to replace java-config, motif-config, | gcc-config, binutils-config, opengl-update, etc, but not all users will | need all modules. I agree here as well... | 3) Some modules require extra files (opengl-update installs header | files, gcc-config installs a wrapper, etc), and the app-admin/eselect | package is not the correct place to provide these files. jupp... | Also, what should the correct way to introduce these modules into | portage? | Should we keep them in the packages they're replacing | (x11-base/opengl-update)? | Should we place them in a new package in the same category as the script | they're replacing (x11-base/eselect-opengl)? | Should we place them in app-admin/eselect- or perhaps | app-eselect/? I'd prefer app-admin/eselect-, but i could happily live with app-eselect/. But i don't think that we need a whole new category for eselect modules. Not right now, and probably not in future, either. | Note that for backwards compatibility in all cases, | x11-base/opengl-update will RDEPEND on this eselect module and install a | backwards-compatible frontend to the eselect module until all packages | in portage have been updated to use the eselect module instead. Jeremy, do you know about the 'old-script-name' feature that Ciaran introduced? By symlinking /usr/bin/eselect to one of these ~ -update, -config, -manager, config-, ~ update- or manage-, a call to it will be handles as if the user called 'eselect '. You might probably want to consider this for your opengl-update package. app-admin/eselect currently installs these symlinks automatically: ~ kernel-config, profile-config, rc-config, bashcomp-config Btw: Thx for you feedback on eselect. It really appreciated it :-) Danny - -- Danny van Dyk <[EMAIL PROTECTED]> Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDAkP4aVNL8NrtU6IRAhEkAJ9zqqfiaruWxy+PQ1e57ybNOcgWIgCff6Y8 q0TidAU1r1rlCb6uuAwRiMM= =BY+s -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect modules
On Tue, 2005-08-16 at 12:21 -0700, Donnie Berkholz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jeremy Huddleston wrote: > | The eselect developers want to keep all eselect modules in their svn > | repository and distributed through a single package (app-admin/eselect). > | Their main reasons for this are better QA and less overhead for releases > | and merging. > > And unnecessarily tying releases together of things that have no reason > to be tied together. > > It's fine to keep all the source in the same repository, but don't lock > releases of unrelated modules together. That's the same thing X went > through and has finally learned with the modularization effort. There's also the size issue. I use opengl-update on the LiveCD builds, and have exactly zero need for *any* other eselect module, so why should I be required to have them all to just get the one that I need? -- Chris Gianelloni Release Engineering - Strategic Lead/QA Manager Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] eselect modules
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Huddleston wrote: | The eselect developers want to keep all eselect modules in their svn | repository and distributed through a single package (app-admin/eselect). | Their main reasons for this are better QA and less overhead for releases | and merging. And unnecessarily tying releases together of things that have no reason to be tied together. It's fine to keep all the source in the same repository, but don't lock releases of unrelated modules together. That's the same thing X went through and has finally learned with the modularization effort. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDAjzGXVaO67S1rtsRAt/jAKC5iEbkyTvqTAm44EB1PVur7wqDiwCcC/HD umiI6mrs67f+YBVxDAJz/0U= =yK5P -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] eselect modules
I've recently updated opengl-update to use the eselect framework. I think the team has done a great job as it was extremely easy to port the bash script to an eselect module. However, when I placed it in the portage tree, it sparked a little bit of a policy discussion between myself and the core eselect devs on how to best include modules in the tree, so I'd like to let other devs chime in as well. Firstly if you don't know what eselect is, check out: http://www.gentoo.org/proj/en/eselect/index.xml The eselect developers want to keep all eselect modules in their svn repository and distributed through a single package (app-admin/eselect). Their main reasons for this are better QA and less overhead for releases and merging. I have a problem with this policy because: 1) Stability of the modules should not be tied to stability of the core package. Basically, I'd like to determine when my modules get pushed into stable without considering how it'll effect the eselect modules of other developers. Similarly, I don't want bugs in another module holding up my module from going into stable. 2) Not all users will want all modules. The goal of the eselect project is to provide a framework to replace java-config, motif-config, gcc-config, binutils-config, opengl-update, etc, but not all users will need all modules. 3) Some modules require extra files (opengl-update installs header files, gcc-config installs a wrapper, etc), and the app-admin/eselect package is not the correct place to provide these files. Also, what should the correct way to introduce these modules into portage? Should we keep them in the packages they're replacing (x11-base/opengl-update)? Should we place them in a new package in the same category as the script they're replacing (x11-base/eselect-opengl)? Should we place them in app-admin/eselect- or perhaps app-eselect/? Note that for backwards compatibility in all cases, x11-base/opengl-update will RDEPEND on this eselect module and install a backwards-compatible frontend to the eselect module until all packages in portage have been updated to use the eselect module instead. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Looking for developers for a new 'Planet' web-app
Sebastian Bergmann wrote: Have you looked at the software [1] that runs on Planet PHP [2]? -- [1] http://svn.bitflux.ch/repos/public/planet-php/trunk/ [2] http://www.planet-php.net/ Thanks, I hadn't heard of that. It seems in tune to what we need: Storing entries in a MySQL database, providing a loose form of archives and a search facility. I'll make sure we consider this. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Looking for developers for a new 'Planet' web-app
Daniel Drake schrieb: > planet is a nice system and makes it dead easy to set up a Planet-style > aggregator. However the feature requests that I am recieving go out of > the scope of what a simple script can do. Have you looked at the software [1] that runs on Planet PHP [2]? -- [1] http://svn.bitflux.ch/repos/public/planet-php/trunk/ [2] http://www.planet-php.net/ -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Looking for developers for a new 'Planet' web-app
Daniel Drake wrote: Hi, As the Planet Gentoo admin (http://planet.gentoo.org), I often get feature ideas and requests for ways to enhance the Planet website. Right now, a python script called "planet" (www.planetplanet.org) powers the site. planet is a nice simple script, which is invoked by cron every hour - it fetches the weblog content for all the developers it knows about, finds the most recent 60 articles, and formats them into a HTML page which is saved to an area of disk served up by apache at http://planet.gentoo.org. planet is a nice system and makes it dead easy to set up a Planet-style aggregator. However the feature requests that I am recieving go out of the scope of what a simple script can do. Examples of what people are requesting: - Ability to browse the 'archives' (i.e. the content which has dropped off the end of the page, which planet discards) - Ability to search the content and the archives - Ability to browse by Gentoo herd, i.e. view the weblogs of the apache maintainers. I'm seeking people who would be interested in developing and maintaining a more dynamic Planet web-application which could handle features such as these. I hope that this will create a new open-source project (or an effort to extend an existing system, if there are any) which would be used to power Planet Gentoo in the future, and be easily available for other communities who wish to use it. I envision this being a database-driven application but all implementation details will be up to the volunteers who take up the task :) Unfortunately I don't have time to get heavily involved with the development, but I will "oversee" the project. This is open to everyone (not only Gentoo developers...) - infact I'd like to see this bringing a few more people into Gentoo development. If you are interested, please send me an email ([EMAIL PROTECTED]) with the following info: 1. Your preferred web development languages/platforms/etc. 2. Other languages/platforms you would be prepared to work with should the majority of other volunteers wish to work with those instead. 3. Your previous experience developing web-applications and working with related software (don't worry if this isn't much). 4. Any experience you have with blogs/aggregation/RSS/... Feel free to spam me with related ideas/comments if you have any :) Thanks, Daniel As i suppose i could help some programming with that site but not earlier than on november. If you will need some help then we could talk more about then. -- Paul -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Looking for developers for a new 'Planet' web-app
Hi, As the Planet Gentoo admin (http://planet.gentoo.org), I often get feature ideas and requests for ways to enhance the Planet website. Right now, a python script called "planet" (www.planetplanet.org) powers the site. planet is a nice simple script, which is invoked by cron every hour - it fetches the weblog content for all the developers it knows about, finds the most recent 60 articles, and formats them into a HTML page which is saved to an area of disk served up by apache at http://planet.gentoo.org. planet is a nice system and makes it dead easy to set up a Planet-style aggregator. However the feature requests that I am recieving go out of the scope of what a simple script can do. Examples of what people are requesting: - Ability to browse the 'archives' (i.e. the content which has dropped off the end of the page, which planet discards) - Ability to search the content and the archives - Ability to browse by Gentoo herd, i.e. view the weblogs of the apache maintainers. I'm seeking people who would be interested in developing and maintaining a more dynamic Planet web-application which could handle features such as these. I hope that this will create a new open-source project (or an effort to extend an existing system, if there are any) which would be used to power Planet Gentoo in the future, and be easily available for other communities who wish to use it. I envision this being a database-driven application but all implementation details will be up to the volunteers who take up the task :) Unfortunately I don't have time to get heavily involved with the development, but I will "oversee" the project. This is open to everyone (not only Gentoo developers...) - infact I'd like to see this bringing a few more people into Gentoo development. If you are interested, please send me an email ([EMAIL PROTECTED]) with the following info: 1. Your preferred web development languages/platforms/etc. 2. Other languages/platforms you would be prepared to work with should the majority of other volunteers wish to work with those instead. 3. Your previous experience developing web-applications and working with related software (don't worry if this isn't much). 4. Any experience you have with blogs/aggregation/RSS/... Feel free to spam me with related ideas/comments if you have any :) Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gstreamer + Use Flags
On Tuesday 16 August 2005 12:38, Fabian Zeindl wrote: > So my proposal is putting UseFlags for additional GstreamerPlugins in the > Gstreamerpackage and remove it in the packages depending on Gstreamer > (totem for example). While I can't decide anything about this as it's up to GStreamer herd, I'd like to say that this proposal has all my approval. I can tell as sound member (amaroK) and video too (Kaffeine now): adding useflags to packages to add mere "fake dependencies" doesn't seem to be user-oriented at all. As they all depends on gstreamer-plugins, that seems to be the most feasible place where to put the useflags. But as I said, I can't do anything about this. -- Diego "Flameeyes" Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpKtXTb1BUYt.pgp Description: PGP signature
[gentoo-dev] Gstreamer + Use Flags
Hi Some time ago I opened a bug concerning Gstreamer's useflags, which are handled completely unlogical at the moment. *every* package depending on the gstreamer multimediaframework brings it's own use flags for gstreamer-plugins, instead of putting the use flags centrally in the gstreamer package itself. I know this has been discussed before on bugzilla and the lists, and I read through all discussions I found. I certainly don't want to waste any developer's time with this, but the current handling of this is unlogical and not "the gentoo way". I think that many users share my opinion here although some devs (foser e.g.) don't agree with this. https://bugs.gentoo.org/show_bug.cgi?id=100872 and https://bugs.gentoo.org/show_bug.cgi?id=84663 decribe the problem. So my proposal is putting UseFlags for additional GstreamerPlugins in the Gstreamerpackage and remove it in the packages depending on Gstreamer (totem for example). Benefits of this: * you have ONE place where you can decide what gstreamer plugins to install * you don't have 'wasted useflags'. It's not logical if I compile amarok without mad and still can use mad, cause another application already used this useflag... * you don't have to reemerge EVERY single application that has gstreamer useflags, when you want to install ONE additional gstreamerplugin, that's completely UNNECESSARY * people don't get confused when using xine and useflags doesn't have an impact. (mp3 doesn't work -> recompile amarok with xine and mad -> mp3 still doesn't work cause mad useflag doesn't influence xine) CONS: * you have to understand that you use gstreamer: when you want to have additional capabilities simple recompiling of amarok (p.e.) doesn't work, you have to recompile gstreamer or emerge -uDN world For me the PROS outweigh the CONS. What do you say? greetings and hoping that I don't annoy anyone with this mail fabian -- ... I want something good to die for To make it beautiful to live. I want a new mistake, lose is more than hesitate. Do you believe it in your head? - Queens of the Stone Age - "Go with the Flow" I prefer signed/encrypted Mail: Fingerprint: CFE8 38A7 0BC4 3CB0 E454 FA8D 04F9 B3B6 E02D 25BA -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] package.mask cleanup
Hi, Yesterday I was tinkering with a ruby script and the p.mask file to get a few data about packages (long, off-topic story). Looking at package.mask I found that there are quite a few packages listed there that doesn't exists at all in portage, a few versions completely vanished, and a few packages "masked as it doesn't work" since 2002 or so. Is it time to cleanup package.mask ? -- Diego "Flameeyes" Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpcqeFO7wFbO.pgp Description: PGP signature
