Re: [gentoo-dev] utf-8 fixes for metadata.xml
On Fri, Aug 05, 2005 at 12:46:13PM +0900, Georgi Georgiev wrote: > What does "set enc?" say? :set enc? encoding=latin1 > Anyway, setting enc=utf-8 when your terminal is using something else > makes the output look like shit. Furthermore, you wouldn't be able to > input any non-ascii characters anyway (or maybe you will, depending on > your locale, but they would appear as garbage on the screen). If you're > not going to go anywhere near non-ascii text it might be OK. I don't plan to edit any non-ascii text in my $EDITOR of choice. The only place I ever write non-ASCII stuff is a word processor. > I guess you're better off using gvim if "locale -k charmap" doesn't say > UTF-8 in your term. I'm using aterm, and I refuse to use a graphical vim. $ locale -k charmap charmap="ANSI_X3.4-1968" -- 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 pgprHEHR3qsai.pgp Description: PGP signature
Re: [gentoo-dev] utf-8 fixes for metadata.xml
maillog: 04/08/2005-19:35:01(-0700): Robin H. Johnson types > On Fri, Aug 05, 2005 at 11:28:46AM +0900, Georgi Georgiev wrote: > > > As a vim workaround, maybe force encoding=utf-8 in the gentoo filetype > > > stuff? > > But utf-8 is supposed to be autodetected, since the default > > fileencodings always contains utf-8, doesn't it? It is not > > autodetected only if the file is not *strictly* utf-8. > It sets 'fileencoding' correctly, but 'encoding' is not set at all. > > Here's the vim settings that I see after opening the file and running :set. > > autoindent hlsearchtabstop=4 ttymouse=xterm > backspace=2 ruler textwidth=80viminfo='20,"500 > history=50 shiftwidth=4ttyfast > commentstring= > fileencoding=utf-8 > fileencodings=ucs-bom,utf-8,default > filetype=gentoo-metadata > suffixes=.bak,~,.o,.h,.info,.swp,.obj,.info,.aux,.log,.dvi,.bbl,.out > syntax=gentoo-metadata What does "set enc?" say? Anyway, setting enc=utf-8 when your terminal is using something else makes the output look like shit. Furthermore, you wouldn't be able to input any non-ascii characters anyway (or maybe you will, depending on your locale, but they would appear as garbage on the screen). If you're not going to go anywhere near non-ascii text it might be OK. I guess you're better off using gvim if "locale -k charmap" doesn't say UTF-8 in your term. -- -* Georgi Georgiev -* Each honest calling, each walk of life, -* *-[EMAIL PROTECTED]*- has its own elite, its own aristocracy *- -* +81(90)2877-8845 -* based on excellence of performance. -- -* *- --- *- James Bryant Conant *- pgpPQHC1ZNRox.pgp Description: PGP signature
Re: [gentoo-dev] digest + manifest = new file format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Whoopse, should have gone to gentoo-portage-dev, my bad ;) Alec Warner wrote: > This is basically a resubmission of Genone's file format merger [1]. > > The code to handle digests and manifests is currently being designed and > rewritten. As such we need two things from the developer community. > One is a decision of what the new format will entail. Two is a firm > agreement on the migration plan. > > 1. The file format is specified in Genone's original mail, but I'll go > over it again to save you the extra linkage ;) > > Inside of the digest-manifest we have: > EBUILD Filename SIZE 1234567 MD5 A4FD085FF SHA-256 A7439FDB1 > > > Where type is the type of file (DIGEST, SRC_URI, EBUILD, PATCH, etc) > > *Note, that the size-tag was added to make the human parsing easier. > > 2. If you didn't notice by now, this format breaks versions of portage > that don't support it ( ie 2.0.X ). This leads us to a few options as > users migrate to a version of portage that supports the new file format. > > A. Write some code into the final stable version to do both kind of > formats and/or use the new format style but fall back to the old style ( > since at release time the new style format probably won't be in the tree > yet ). Either way, the last release of 2.0.X should work with the new > file format in enough of a fashion to not break. This means that when > the old manifest + digests are combined in the tree, most users should > be ok even if they aren't upgraded to 2.1.X. > > B. Have a migration time where both formats are in the tree. For a > while the tree will be larger, and many people will have issues with > this. However, old portage will use the old files, and new releases > will use the new files. Then after a period of however long ( 6 months? > ) announce loudly beforehand that portage-2.0.X will no longer be > supported and pull the old digests/manifests out of the tree. > > C. The Carpaski way ;)[2] Add support for the new format in 2.1, > while also adding support for current format. Force everyone to upgrade > to 2.1.X, while announcing that 2.0.X will not work in the future. When > we have confidence that most users are upgraded, pull the old format and > add the new format to the tree. > > Problems with all of these include the same problems as the cascaded > profiles, some goofball doesn't upgrade for a year, syncs with new > digests...how does he get his portage upgraded? An upgrade path should > be provided and documented in this case. > > The best route is probably some combination of the above. Pre-emptively > add support for the new format to stable, while announcing the death of > the old format after 2.1's release. When most users upgrade normally to > the latest 2.0.X series ( perhaps fearing the changes of 2.1.X ) they > will gain support for the new file format (or if not support, merely a > working portage instead of broken). We should catch the majority of > users who upgrade with either the last 2.0.X release or the new release > of 2.1.X. > > Suggestions, criticisms, etc... welcome. > > [1] http://marc.theaimsgroup.com/?l=gentoo-dev&m=109725383228494&w=2 > [2] http://marc.theaimsgroup.com/?l=gentoo-dev&m=109725779909405&w=2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQvLSLmzglR5RwbyYAQJkEQ//aQFAjvEFJ1tRq988HOEyh/XxHlsPnksm HAQCs8iSkLY6cI9IcRniTgkLuNwLYMqElEMACSWlTWCGmL5lrG/6XDkPaXDBeNLg jyw1h5yCauQnH8THwzuLQ4RVg3pFsmIthrJyB55V4i/DDiAY6JGfs7xwSys1Poih rUohcrWiI/gWr2UHzrlS4xtqO4iWw5kpUBAslDk8D+RZEjn1i5GcW/3J8GBS3RUF TFKkzBf/ruhqN50Cpbo6Q0gEnvKcgtQSrYBlIyCdw+GpGqbalPVbGPVbozApwk6d DQvLbMgZq7G8oM8vo8IL0cThdocNfWcNDAUrPadxzA6szzxxCiu3DiCVNLRoAhOy 2JCyGfTEY3KStX39NvCCcnkGTcP6XbGw3ummPJwLlNxP6x+KwCbHj5Hats+LDO71 dxOjh8+GeOCmafO89OmSD2W2l/zAdmU6KPUYY7OfUttrmbcTZehdTksQBZqlohRg Coz4Fe6BxMn3dQ2C3wplALwRIikLsP95UwH7MSlAIFzrEdy7XPQydPKB/kjOk4e3 r7nrM/EOoW54QbhX8ItY+y3dEDJWNKJduax7uYXbz+tMH0J74oxiVswcu/LTgXFv RkCJ4UqED7zvyQafaL5yTk8UYknI/oeo7x9siiqSJ90J7Y6m2GrX1i8vLoiOnyTf +2gWdQCckT8= =TOrq -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] digest + manifest = new file format
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is basically a resubmission of Genone's file format merger [1]. The code to handle digests and manifests is currently being designed and rewritten. As such we need two things from the developer community. One is a decision of what the new format will entail. Two is a firm agreement on the migration plan. 1. The file format is specified in Genone's original mail, but I'll go over it again to save you the extra linkage ;) Inside of the digest-manifest we have: EBUILD Filename SIZE 1234567 MD5 A4FD085FF SHA-256 A7439FDB1 Where type is the type of file (DIGEST, SRC_URI, EBUILD, PATCH, etc) *Note, that the size-tag was added to make the human parsing easier. 2. If you didn't notice by now, this format breaks versions of portage that don't support it ( ie 2.0.X ). This leads us to a few options as users migrate to a version of portage that supports the new file format. A. Write some code into the final stable version to do both kind of formats and/or use the new format style but fall back to the old style ( since at release time the new style format probably won't be in the tree yet ). Either way, the last release of 2.0.X should work with the new file format in enough of a fashion to not break. This means that when the old manifest + digests are combined in the tree, most users should be ok even if they aren't upgraded to 2.1.X. B. Have a migration time where both formats are in the tree. For a while the tree will be larger, and many people will have issues with this. However, old portage will use the old files, and new releases will use the new files. Then after a period of however long ( 6 months? ) announce loudly beforehand that portage-2.0.X will no longer be supported and pull the old digests/manifests out of the tree. C. The Carpaski way ;)[2] Add support for the new format in 2.1, while also adding support for current format. Force everyone to upgrade to 2.1.X, while announcing that 2.0.X will not work in the future. When we have confidence that most users are upgraded, pull the old format and add the new format to the tree. Problems with all of these include the same problems as the cascaded profiles, some goofball doesn't upgrade for a year, syncs with new digests...how does he get his portage upgraded? An upgrade path should be provided and documented in this case. The best route is probably some combination of the above. Pre-emptively add support for the new format to stable, while announcing the death of the old format after 2.1's release. When most users upgrade normally to the latest 2.0.X series ( perhaps fearing the changes of 2.1.X ) they will gain support for the new file format (or if not support, merely a working portage instead of broken). We should catch the majority of users who upgrade with either the last 2.0.X release or the new release of 2.1.X. Suggestions, criticisms, etc... welcome. [1] http://marc.theaimsgroup.com/?l=gentoo-dev&m=109725383228494&w=2 [2] http://marc.theaimsgroup.com/?l=gentoo-dev&m=109725779909405&w=2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQvLQuGzglR5RwbyYAQLykg//TbNRfPlUutmLIn09IzQ5nX1XR1RZNUVo e4dgiOWbJz+dBbc4jU8NxrMlSp7tv1rMhSaHw+oqhtPFZGCBbTXIFEZkBgvq9H2L AYO62Oht8xgfYgIl/KIJgWTJTmlbC2mLRMhceD83pfJKDhp6px435g+7oUyK/sPz rxcDHn95veT+4WdkrwrGK8rGbAsWQ9NivyUySzfPyZN83/mc50XLd7x2cyHHKmkx wwPORG8wdhWYFeLD16SZPyBmiVW1MkA1LIK95fDRV3j9wA2mqftZlSMR0lO76fJr tgbrKewJKVvms4+MbFJwRJGL9R6mg4VstjFeNw6smZtTSUgXtGV6qJX4S3Zj+YQJ 37gpl/zCVVvmGEa8uN0gGRDnVHEyeAAHeZbeniukc6m3fn/6JvXeDqPRFGTwWorS B4G2DyaoJCg0Sia5lwAYBqgnikKXOZ4Q3eD0fMP1kCwBZdTUG2CTV1hNvF6FfV/e +V26rqI2R/rXmPnXmnipM1XsajT2GLnhqY1L7OUZfWF52QuqJI4sta7VybQ4lBny cSFEmjJM+nHoCnTW90iYWhEcwNC7/F20LZEsin/uim0/rHhqhuLPyTZ6hkg3CauW BeLfRfGC4NY00M/xamkVzPlnoMsIZzsX9W7WkpBgwgB4lljwzUmQ6CXPiQsu8tLC SYKtXlGJhI8= =At7Y -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] utf-8 fixes for metadata.xml
On Fri, Aug 05, 2005 at 11:28:46AM +0900, Georgi Georgiev wrote: > > As a vim workaround, maybe force encoding=utf-8 in the gentoo filetype > > stuff? > But utf-8 is supposed to be autodetected, since the default > fileencodings always contains utf-8, doesn't it? It is not > autodetected only if the file is not *strictly* utf-8. It sets 'fileencoding' correctly, but 'encoding' is not set at all. Here's the vim settings that I see after opening the file and running :set. autoindent hlsearchtabstop=4 ttymouse=xterm backspace=2 ruler textwidth=80viminfo='20,"500 history=50 shiftwidth=4ttyfast commentstring= fileencoding=utf-8 fileencodings=ucs-bom,utf-8,default filetype=gentoo-metadata suffixes=.bak,~,.o,.h,.info,.swp,.obj,.info,.aux,.log,.dvi,.bbl,.out syntax=gentoo-metadata -- 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 pgp77CL7le3Iz.pgp Description: PGP signature
Re: [gentoo-dev] utf-8 fixes for metadata.xml
maillog: 04/08/2005-19:15:15(-0700): Robin H. Johnson types > On Fri, Aug 05, 2005 at 01:13:31AM +0100, Ciaran McCreesh wrote: > > I've just gone through and fixed all of the broken utf-8 in metadata.xml > > files. I think... There was rather a lot of it due to various editor > > bugs which I'm hoping are no longer an issue. Requests: > > > > - Could anyone who can read whatever language 'vi' is please check a few > > of the category metadata.xml files? > vim-6.3.084 still breaks them, unless you set encoding=utf-8 in your vim > settings. It's the same bug I spoke to you about earlier today. > > Open the metadata.xml (see no '[converted]' text). > Save metadata.xml (see the '[converted]' text). > File is now broken. > > As a vim workaround, maybe force encoding=utf-8 in the gentoo filetype > stuff? But utf-8 is supposed to be autodetected, since the default fileencodings always contains utf-8, doesn't it? It is not autodetected only if the file is not *strictly* utf-8. -- () Georgi Georgiev () C-3PO: We're doomed! () ()[EMAIL PROTECTED]() () () +81(90)2877-8845 () () pgpryKdiwJjwF.pgp Description: PGP signature
Re: [gentoo-dev] utf-8 fixes for metadata.xml
On Fri, Aug 05, 2005 at 01:13:31AM +0100, Ciaran McCreesh wrote: > I've just gone through and fixed all of the broken utf-8 in metadata.xml > files. I think... There was rather a lot of it due to various editor > bugs which I'm hoping are no longer an issue. Requests: > > - Could anyone who can read whatever language 'vi' is please check a few > of the category metadata.xml files? vim-6.3.084 still breaks them, unless you set encoding=utf-8 in your vim settings. It's the same bug I spoke to you about earlier today. Open the metadata.xml (see no '[converted]' text). Save metadata.xml (see the '[converted]' text). File is now broken. As a vim workaround, maybe force encoding=utf-8 in the gentoo filetype stuff? -- 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 pgppFlV5e6EfJ.pgp Description: PGP signature
Re: [gentoo-dev] Re: where goes Gentoo?
On Thu, Aug 04, 2005 at 05:31:43PM -0400, Chris Gianelloni wrote: > The only things I could see being needed out of portage itself is the > ability to control "emerge" commands remotely, such as forcing an update > of apache to $version to resolve a vulnerability. The requirements of portage, or whatever component supplies (essentially) pkg management of remote boxes is going to be a bit more complex then just pushing emerge commands out; aside from config data, it'll probably centralize the vdb type contents somewhere, let alone avoiding N copies of the ebuild tree on each server. Basically, whatever daemon is running clientside for all of this will have to support a good bit of handing off commands to portage, hence the interest (since from my point of view, it's a starting point). > Some things I could see as needed: > > 1. applying updates on any file that is under CONFIG_PROTECT where the > md5/file-size matches that in /var/db for the file without user > interactio That would have to be determined prior to starting the update push. I'd think basically a CONFIG_PROTECT limited scan of boxes to be updated, verifying things are in order according to the vdb (whether remote or local to that box) probably would fly. > 2. automatic removal of files under CONFIG_PROTECT where the > md5/file-size matches that in /var/db during unmerge current vdb implementation relies on md5/file-size, future should rely on refcount, and be a good bit more configurable. > > It's not an overnight thing, glep19 (stable portage tree) addresses a > > chunk of concerns when/if it's implemented, but I'm a bit more > > interested in the the other tools people desire alongside. Offhand, responding to my own snippet, I'd love to know what's going on with glep19... > > As am I. The Installer is one such project. We do not have any project > that I am aware of that is designed to resolve the problem of remotely > managing a server. There is nothing for pushing config changes/package > updates/new packages. There would need to be some interface for doing > these things. Stop by any trade show, such as LWE, and you'll see guys > pushing their wares on remotely managing Linux. We should provide > something like this ourselves. > > eg. If I want to change the subnet mask or default router on 50 machines > on my network, I should be able to do so via a simple interface and have > the work done automatically. Approach I've been thinking about (that fits semi-neatly exempting collision-protect) is essentially config pkgs, binding them on the fly to pkgs being pushed out. Essentially, base apache pkg (that out of an ebuild tree), with it's depend tweaked automatically to pull in a matching configuration pkg. Pushing out config updates wouldn't be too hard if handled in this manner, although generation of the config pkgs themselves would be a bit tricky. > > Re: a drop-in solution, considering that gentoo is effectively all > > over the map (seriously, look at the tree), define the profile for the > > drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc. > > I meant a drop-in management solution, not a specific set of server > profiles, though those could be created with the Installer. In fact, I > see the Installer as one of the first pieces of the framework necessary > for deployment and management of a large number of servers. Once the > netfe interface is completed with the Installer, you will be able to PXE > boot your server and have it load a specific installer profile, and it > will install Gentoo to those specifications. Beyond that, we lose > control of the server and must manually perform all other actions. Niete. > > Specifics... > > > > Hell, I have yet to see what I would define as a proper solution for > > config manamagent for N gentoo boxes. NFS solution possibly, but that > > seems a bit hackish to me. > > There isn't a proper solution yet. Honestly, something like a > repository holding configuration information with revision control would > probably be best, so you can revert changes. There are quite a few > systems like this out for Red Hat and others, but nothing that is > Gentoo-specific, or even Gentoo-capable, as far as I know. We should > beat people to the punch and design one ourselves. > > The main things we need to provide are: > > Provisioning - building a server from bare metal to some pre-determined > state Installer... > Management - being able to make changes to existing servers without > manually logging into each to make the changes Domain class should provide for it > Updates - this somewhat goes with management, but a facility for > disseminating patches or updated packages to servers Same as above > Our tools. Currently, we have very few "Gentoo tools" used for managing > a system. We would need to define the requirements for these tools, and > then work on ways of getting them built. It's like I said, I think the > primary w
Re: [gentoo-dev] python module
Rene Zbinden wrote: Yes in the meantime I found that eclass. The problem was, that there was no setup.py file. I created my own and put it into the files directory. If that works for you then I can't really see any reason why you shouldn't do it, but I find it far easier and cleaner to simply not use all the functions provided by distutils. It should be much simpler to implement whatever you need in ebuild functions, instead of doing them in setup.py and then calling that from the ebuild. I'm sure many python module ebuilds could show examples of this, but the only one I can direct you to for certain is dev-python/visual-3.2.1. --Colin -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] utf-8 fixes for metadata.xml
I've just gone through and fixed all of the broken utf-8 in metadata.xml files. I think... There was rather a lot of it due to various editor bugs which I'm hoping are no longer an issue. Requests: - Could anyone who can read whatever language 'vi' is please check a few of the category metadata.xml files? - Could anyone editing metadata.xml files please do a 'cvs diff' and check that whatever you did didn't screw up any encodings? Usually you can tell by checking that cvs diff isn't giving you any expected lines changed on things that contain strange characters. If things do seem to be going screwy, please let me know what you were doing that did it so that I can figure out whether we still have broken editors / tools out there... If you're entering utf-8 I'd hope that you'd know how to check already :) - If anyone is still going to throw a hissy fit and refuse to play nice with this utf-8 thing, please let me know now so that I don't waste more time fixing things. There are still broken ChangeLogs and one or two h0rked ebuilds in the tree. I'll get to those once I'm sure that I'm not wasting my time. -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Any outstanding dodgy finds?
On Friday 05 August 2005 07:21, Ciaran McCreesh wrote: > Is anyone aware of any outstanding problems with the stricter find > argument ordering required by findutils 4.2.20? xorg is no longer > holding up 4.2.20 going stable -- are there any others? > > For those not aware of the problem, find must only be used in the > following form: > > find paths program-options search-options actions > > Older findutils versions would silently accept most orderings. Newer > versions will either barf or make lots of noise. > > (Sidenote: the paths part is mandatory. Current findutils will default > to the current directory if no path is provided, but other > implementations and future findutils versions may exit with an error.) I think portage has a one or two cases of this issue. -- Jason Stubbs pgpZc4EiAzBCV.pgp Description: PGP signature
Re: [gentoo-dev] Bugday announcement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bjarke Istrup Pedersen wrote: > Alright everybody, here we go again :-) > > This is my first announcement, so let?s hope I get everything > right. On next Saturday it will be bugday again, unfortunately the > new bugday website isn't done yet, but the little dwarf sitting > under my table doing all the coding has run away, and I haven't > been able to find him yet. > > Well, back to business, it will be on #gentoo-bugs on > irc.freenode.net on Saturday. (Thanks to time zones, it almost > lasts two days, so join in early). > > Bugday has existed two years now, and we have an article in the > newest GWN, so if you haven't read it yet, take the time to do so, > you can find it here: > http://www.gentoo.org/news/en/gwn/20050801-newsletter.xml > > Hope to see a lot of you there; unfortunately there won't be free > cookies this time. > > Best Regards Bjarke Istrup Pedersen I'll be there as much as I can. I'd like to get going on the new site. ~Scott -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC8pT+10ekhar8gdURAsOcAJkBfA0yg/e6m7fYq5hFCZQ6X5Xn/QCeIHKR tNNtW4A3hM44aXuaGJUkBEk= =CRPd -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Any outstanding dodgy finds?
Is anyone aware of any outstanding problems with the stricter find argument ordering required by findutils 4.2.20? xorg is no longer holding up 4.2.20 going stable -- are there any others? For those not aware of the problem, find must only be used in the following form: find paths program-options search-options actions Older findutils versions would silently accept most orderings. Newer versions will either barf or make lots of noise. (Sidenote: the paths part is mandatory. Current findutils will default to the current directory if no path is provided, but other implementations and future findutils versions may exit with an error.) -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgp1UyRBVLkDe.pgp Description: PGP signature
[gentoo-dev] Bugday announcement
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alright everybody, here we go again :-) This is my first announcement, so let?s hope I get everything right. On next Saturday it will be bugday again, unfortunately the new bugday website isn't done yet, but the little dwarf sitting under my table doing all the coding has run away, and I haven't been able to find him yet. Well, back to business, it will be on #gentoo-bugs on irc.freenode.net on Saturday. (Thanks to time zones, it almost lasts two days, so join in early). Bugday has existed two years now, and we have an article in the newest GWN, so if you haven't read it yet, take the time to do so, you can find it here: http://www.gentoo.org/news/en/gwn/20050801-newsletter.xml Hope to see a lot of you there; unfortunately there won't be free cookies this time. Best Regards Bjarke Istrup Pedersen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC8pSzO+Ewtpi9rLERAtI4AJ9wdTbg/iWpkNwzLNqR1QtpYZzqLgCgzYBR LHTDe2BKRzT9+SldEjIesyY= =IALR -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: where goes Gentoo?
On Thu, 2005-08-04 at 14:37 -0500, Brian D. Harring wrote: > Elaborate on what you explicitly want out of portage please- the > domain concept (aside from being useful design wise) *should* allow > groupping of boxes (groupping of domains really) behind it, so you can > effectively have a set of boxes, pushing changes to each. > > Mind you no code written, but current design is intended to allow > remote chunks to be swapped in/out of portagelib on the fly > (including the actual portage configuration). The only things I could see being needed out of portage itself is the ability to control "emerge" commands remotely, such as forcing an update of apache to $version to resolve a vulnerability. Besides the back-end portage pieces, there would need to be a front-end interface for performing these tasks. > Better angle of discussion rather then "we aren't there yet" is the > specifics of what is needed to *get* there in peoples opinion. Agreed completely. Some things I could see as needed: 1. applying updates on any file that is under CONFIG_PROTECT where the md5/file-size matches that in /var/db for the file without user interaction 2. automatic removal of files under CONFIG_PROTECT where the md5/file-size matches that in /var/db during unmerge > It's not an overnight thing, glep19 (stable portage tree) addresses a > chunk of concerns when/if it's implemented, but I'm a bit more > interested in the the other tools people desire alongside. As am I. The Installer is one such project. We do not have any project that I am aware of that is designed to resolve the problem of remotely managing a server. There is nothing for pushing config changes/package updates/new packages. There would need to be some interface for doing these things. Stop by any trade show, such as LWE, and you'll see guys pushing their wares on remotely managing Linux. We should provide something like this ourselves. eg. If I want to change the subnet mask or default router on 50 machines on my network, I should be able to do so via a simple interface and have the work done automatically. > Re: a drop-in solution, considering that gentoo is effectively all > over the map (seriously, look at the tree), define the profile for the > drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc. I meant a drop-in management solution, not a specific set of server profiles, though those could be created with the Installer. In fact, I see the Installer as one of the first pieces of the framework necessary for deployment and management of a large number of servers. Once the netfe interface is completed with the Installer, you will be able to PXE boot your server and have it load a specific installer profile, and it will install Gentoo to those specifications. Beyond that, we lose control of the server and must manually perform all other actions. > Specifics... > > Hell, I have yet to see what I would define as a proper solution for > config manamagent for N gentoo boxes. NFS solution possibly, but that > seems a bit hackish to me. There isn't a proper solution yet. Honestly, something like a repository holding configuration information with revision control would probably be best, so you can revert changes. There are quite a few systems like this out for Red Hat and others, but nothing that is Gentoo-specific, or even Gentoo-capable, as far as I know. We should beat people to the punch and design one ourselves. The main things we need to provide are: Provisioning - building a server from bare metal to some pre-determined state Management - being able to make changes to existing servers without manually logging into each to make the changes Updates - this somewhat goes with management, but a facility for disseminating patches or updated packages to servers > Moot point frankly, considering we're all volunteers; someone > *could* get off their butts and start up an attempt to provide hand > holding (effectively what you're coloring the management arg as) > services, but even if they did, the followup arg would be that you > can't yet trust this new support company, because they're new. > Etc. Not entirely moot, as a company could be formed in cooperation with the Foundation, as I stated earlier in the thread. This symbiotic relationship would give the new company a bit more credit, as it will be supported by the Foundation. This could be a Foundation-owned company, or a completely separate entity. Anyway, this isn't so much my point, as many people *are* willing to forgo having a human voice on the end of a phone. > Basically, we don't have control over that portion, so... what > can be mangled that we *do* have control over, and has an effect? Our tools. Currently, we have very few "Gentoo tools" used for managing a system. We would need to define the requirements for these tools, and then work on ways of getting them built. It's like I said, I think the primary weakness in Gentoo's enterpris
[gentoo-dev] Last rites for media-video/DFBsee
This is my first "last rites" post, yay :) Ok well I just seen this today and I looked for it: media-video/dfbsee is just a copy of media-video/DFBsee, that doesn't seems maintained anymore. ChrisWhite started moving it but the job is stuck at December 2004. If nobody has a good reason against this, I'm going to remove media-video/DFBsee from the tree a week from now. -- Diego "Flameeyes" Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgppFhu4uRu7u.pgp Description: PGP signature
RE: [gentoo-dev] Re: where goes Gentoo?
I think Brian is right, we should stick to being constructive. Let's start an enterprise project on Gentoo.org Goals: 1) provide documentation on existing tools and practices for business/enterprise users. 2) try to enhance the set of tools to build a comprehensive framework that makes it easy to use and deploy Gentoo in a business/enterprise environment. 3) provide information so that concerned parties can find companies that specialize in Gentoo deployment/management/support. Any ideas? --Eric -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: where goes Gentoo?
Long one kiddies... responses inlined, bit more interested in discussion of what's required/desired then "your definition of enterprise sucks"... (throws on the flamesuit)... On Thu, Aug 04, 2005 at 02:35:08PM -0400, Chris Gianelloni wrote: > On Thu, 2005-08-04 at 11:48 -0400, Eric Brown wrote: > > Every business application of Gentoo I've done has been different. I don't > > think I could generalize my needs into a single ebuild. Although generally > > I have used rsyncd and apache, I never use them in the same way. What's so > > hard about using the default rsyncd config, and adding distfiles to your > > apache document root? (what 90% of people would use). > > You completely missed the management aspect here. I'm talking about > some form of actual enterprise-ready management framework for > controlling a set of Gentoo servers centrally from deployment to > maintenance and upgrades. Elaborate on what you explicitly want out of portage please- the domain concept (aside from being useful design wise) *should* allow groupping of boxes (groupping of domains really) behind it, so you can effectively have a set of boxes, pushing changes to each. Mind you no code written, but current design is intended to allow remote chunks to be swapped in/out of portagelib on the fly (including the actual portage configuration). > > About automating updates and etc-update: you can rsync your config file > > sometimes and just bypass all of the portage stuff. You could mount some > > config dirs over nfs even. You could even remove config_protect on some > > dirs and roll your own custom packages. > > You can... You can... You can... > > All I heard here was a bunch of excuses about how a person can take the > time to implement something that's been implemented by countless other > people, because Gentoo does not provide a framework for doing this. The > whole idea of being enterprise-ready is having a drop-in solution that > works right off the bat, with minimal to no configuration for basic > services. All of your solutions requires manpower to accomplish that > not every enterprise can afford to spend. Once again, this is why > Gentoo is currently not used in these situations. Better angle of discussion rather then "we aren't there yet" is the specifics of what is needed to *get* there in peoples opinion. It's not an overnight thing, glep19 (stable portage tree) addresses a chunk of concerns when/if it's implemented, but I'm a bit more interested in the the other tools people desire alongside. Re: a drop-in solution, considering that gentoo is effectively all over the map (seriously, look at the tree), define the profile for the drop-in; drop-in ftp, drop-in web server, drop-in mosix node... etc. Specifics... Hell, I have yet to see what I would define as a proper solution for config manamagent for N gentoo boxes. NFS solution possibly, but that seems a bit hackish to me. > > This brings me to your last point about calling someone when there are > > problems: There are companies that provide Linux services, even Gentoo > > specific services. Some of these companies might even provide > > enterprise-grade portage mirrors with support for the packages they > > maintain there. > > I don't think I would stake my company's infrastructure on the reliance > on Bob and Joe's Gentoo Support Hotline, sorry. Not to mention you > haven't actually given a single example of someone who can provide this > level of enterprise support. There's a reason why you haven't given an > example. None exists. Moot point frankly, considering we're all volunteers; someone *could* get off their butts and start up an attempt to provide hand holding (effectively what you're coloring the management arg as) services, but even if they did, the followup arg would be that you can't yet trust this new support company, because they're new. Etc. Basically, we don't have control over that portion, so... what can be mangled that we *do* have control over, and has an effect? > > [snip] > In the computer industry, an enterprise is an organization that uses > computers. In practice, the term is applied much more often to larger > organizations than smaller ones. > > We are using this in practice. Therefore, we are speaking of large > organizations, and not just *any* organization. That's a really crappy description, rather nebulous. :) And... nobody probably cares about loose definitions, 'cause loose definitions are moving targets. Again, specific suggestions/requests would rock. Mentioned management tools, well, get into specifics; pxe network installs/imaging? Single tree/cache for N servers? Ability to push updates out to a specific box, or set of servers? Integration of portage contents db with IDS tools? > Novell has several tools, that when used in combination, form a cohesive > framework for deploying, managing, and upgrading systems. What's even > better, is it isn't just lim
Re: [gentoo-dev] Re: where goes Gentoo?
050804 Chris Gianelloni wrote: -- long interesting account of life in the enterprise snipped -- > I want to see Gentoo as an enterprise-capable distribution myself, > but I also understand that it is a long, hard road ahead of us > and there will still be things we cannot provide as a community distro. > There would need to be an entity responsible when something goes wrong > and that has the manpower and resources to fix it. There's no way a volunteer organisation like Gentoo could undertake that. What would be essential is a company with capital invested & probably an insurance policy somewhere in the background, which employs Gentoo-knowledgeable staff to build & fix systems. It would probably have its own mirror with a selection of Gentoo packages, which it is prepared to guarantee as reliable & safe to use, & would develop all the enterprise-level management tools you describe. Hopefully, it would give something back to the underlying volunteer Gentoo by way of free staff time & some tools all of us might benefit from. The first step is a visit to your friendly neighbourhood bank manager (smile). -- ,, SUPPORT ___//___, Philip Webb : [EMAIL PROTECTED] ELECTRIC /] [] [] [] [] []| Centre for Urban & Community Studies TRANSIT`-O--O---' University of Toronto -- gentoo-dev@gentoo.org mailing list
RE: [gentoo-dev] Re: where goes Gentoo?
On Thu, 2005-08-04 at 11:48 -0400, Eric Brown wrote: > Every business application of Gentoo I've done has been different. I don't > think I could generalize my needs into a single ebuild. Although generally I > have used rsyncd and apache, I never use them in the same way. What's so > hard about using the default rsyncd config, and adding distfiles to your > apache document root? (what 90% of people would use). You completely missed the management aspect here. I'm talking about some form of actual enterprise-ready management framework for controlling a set of Gentoo servers centrally from deployment to maintenance and upgrades. > About automating updates and etc-update: you can rsync your config file > sometimes and just bypass all of the portage stuff. You could mount some > config dirs over nfs even. You could even remove config_protect on some dirs > and roll your own custom packages. You can... You can... You can... All I heard here was a bunch of excuses about how a person can take the time to implement something that's been implemented by countless other people, because Gentoo does not provide a framework for doing this. The whole idea of being enterprise-ready is having a drop-in solution that works right off the bat, with minimal to no configuration for basic services. All of your solutions requires manpower to accomplish that not every enterprise can afford to spend. Once again, this is why Gentoo is currently not used in these situations. > About a slower moving portage tree for enterprise users: Great idea, I think > there's a GLEP about that. I think it's best handled by third parties who > can spend the money/man power on that kind of QA. Yes, there is a GLEP about this. This is also the first step to being able to provide any level of enterprise-readiness. You simply cannot tell someone to upgrade glibc to some new version if something is wrong with the current one. They want a patch for the current one. Think bug-fixes only with absolutely zero new features between whatever form of releases are created. > This brings me to your last point about calling someone when there are > problems: There are companies that provide Linux services, even Gentoo > specific services. Some of these companies might even provide > enterprise-grade portage mirrors with support for the packages they maintain > there. I don't think I would stake my company's infrastructure on the reliance on Bob and Joe's Gentoo Support Hotline, sorry. Not to mention you haven't actually given a single example of someone who can provide this level of enterprise support. There's a reason why you haven't given an example. None exists. > I'm sorry, I never ran 1000 Gentoo machines in production like that, I > thought enterprise meant this (answers.com): > > en·ter·prise (ĕn'tər-prīz') pronunciation > n. > >1. An undertaking, especially one of some scope, complication, and risk. >2. A business organization. >3. Industrious, systematic activity, especially when directed toward > profit: Private enterprise is basic to capitalism. >4. Willingness to undertake new ventures; initiative: “Through want of > enterprise and faith men are where they are, buying and selling, and spending > their lives like serfs” (Henry David Thoreau). Wow. A dictionary definition that is completely out of context and doesn't account for the word enterprise being used as a technical representation. I've got a few "enterprise" definitions for you, too. The Enterprise type is a two-man hiking sailing dinghy with a distinctive blue sail and no spinnaker. Despite being one of the older classes of dinghies, it remains popular and well used for both cruising and racing. It has a combination of stability, size and power which contiues to appeal to all ages, and to sailing schools. ...or... Star Trek: Enterprise is a science fiction television series set in the Star Trek universe.(Until the third season its title was simply Enterprise, and it is often abbreviated as ST:ENT or ENT).The series follows the adventures of the crew of the Enterprise (NX-01), the first human interstellar ship that can achieve Warp 5.Enterprise premiered in the United States on September 26, 2001, and is presently in its fourth, and final, season. ...though the one I am looking for, and the one that fits the scope of this conversation is this one: In the computer industry, an enterprise is an organization that uses computers. In practice, the term is applied much more often to larger organizations than smaller ones. We are using this in practice. Therefore, we are speaking of large organizations, and not just *any* organization. > Doesn't this just go to show that in business, everyone wants something > different from Gentoo? What does Novell offer to manage large numbers of > linux boxen? Are you sure projects like OpenMosix don't have tools you could > use to manage such a large number of machines? Not really.
RE: [gentoo-dev] Re: where goes Gentoo?
>On Thu, 2005-08-04 at 09:04 -0400, Eric Brown wrote: >> >> Interesting thread. I have used Gentoo in enterprise situations very >> successfully, and I think the whole QA/live-tree argument is moot. In >> an enterprise environment, you might have a backup/testing machine to >> run your updates on first before they went live. You also wouldn't run >> new packages unless they passed your own QA tests first. >> >> Given the incredible flexibility of portage to support local mirrors, >> binary package preparation, and localized versions of packages >> (portdir_overlay), I would say that Gentoo is quite a contender in the >> enterprise environment. >> >> Perhaps we need some enterprise documentation to help people realize the >> full potential of portage? > >I think you've missed some of the idea of "enterprise" support. See, >for starters, every person shouldn't have to create their own >implementation of everything. Perhaps a better solution would be a >package that when installed, builds up a local mirror, a binary package >repository (with revision control), an automated update system, a system >for updating rolled out machines without forcing the use of etc-update >on each machine, a slower moving stable tree capable of being certified >with applications, and most likely a phone number of someone to call >when the shit hits the fan. Every business application of Gentoo I've done has been different. I don't think I could generalize my needs into a single ebuild. Although generally I have used rsyncd and apache, I never use them in the same way. What's so hard about using the default rsyncd config, and adding distfiles to your apache document root? (what 90% of people would use). About automating updates and etc-update: you can rsync your config file sometimes and just bypass all of the portage stuff. You could mount some config dirs over nfs even. You could even remove config_protect on some dirs and roll your own custom packages. About a slower moving portage tree for enterprise users: Great idea, I think there's a GLEP about that. I think it's best handled by third parties who can spend the money/man power on that kind of QA. This brings me to your last point about calling someone when there are problems: There are companies that provide Linux services, even Gentoo specific services. Some of these companies might even provide enterprise-grade portage mirrors with support for the packages they maintain there. > >While I will completely agree that Gentoo *can* be used in the >enterprise successfully, that does not make it "enterprise-ready", in >any sense. Many people also seem to misunderstand the concept of >"enterprise" when we are referring to it in this manner. We don't mean >"I'm running it on 10 servers in production" or anything like that. We >mean "I'm running this as our production platform for Linux services >across our entire enterprise, that could be hundreds or even thousands >of servers" instead. While it might be possible to maintain a handful >of Gentoo servers, it is next to impossible to maintain an army of them, >without spending significant up-front manpower to design, test, and >implement your own set of management tools. Gentoo has no real >management tools. There are a few here and there that do specific >tasks, but there isn't anything designed to really take control over >your network of systems. To be fair, Red Hat doesn't have anything like >this, either. Their "Satellite Server" product is good for initial >builds and for updates, but falls short on the management aspects. >Novell's offerings are probably the best examples of what we really >need. Of course, most people would be happy with even rudimentary >management capabilities, as currently, we have none. We don't have any >form of update server. You have to build one yourself. We don't have >any form of "jump-start" or "kickstart" for rapid automated deployments. >You have to build one yourself. Now, we do have the Gentoo Linux >Installer project, which has this as one of its goals, so we will have >this component at some point in the future. I'm sorry, I never ran 1000 Gentoo machines in production like that, I thought enterprise meant this (answers.com): en·ter·prise (ĕn'tər-prīz') pronunciation n. 1. An undertaking, especially one of some scope, complication, and risk. 2. A business organization. 3. Industrious, systematic activity, especially when directed toward profit: Private enterprise is basic to capitalism. 4. Willingness to undertake new ventures; initiative: “Through want of enterprise and faith men are where they are, buying and selling, and spending their lives like serfs” (Henry David Thoreau). Doesn't this just go to show that in business, everyone wants something different from Gentoo? What does Novell offer to manage large numbers of linux boxen? Are you sure projects like OpenMosix don't have tools you could use to manage such a l
RE: [gentoo-dev] Re: where goes Gentoo?
On Thu, 2005-08-04 at 09:04 -0400, Eric Brown wrote: > > Interesting thread. I have used Gentoo in enterprise situations very > successfully, and I think the whole QA/live-tree argument is moot. In > an enterprise environment, you might have a backup/testing machine to > run your updates on first before they went live. You also wouldn't run > new packages unless they passed your own QA tests first. > > Given the incredible flexibility of portage to support local mirrors, > binary package preparation, and localized versions of packages > (portdir_overlay), I would say that Gentoo is quite a contender in the > enterprise environment. > > Perhaps we need some enterprise documentation to help people realize the > full potential of portage? I think you've missed some of the idea of "enterprise" support. See, for starters, every person shouldn't have to create their own implementation of everything. Perhaps a better solution would be a package that when installed, builds up a local mirror, a binary package repository (with revision control), an automated update system, a system for updating rolled out machines without forcing the use of etc-update on each machine, a slower moving stable tree capable of being certified with applications, and most likely a phone number of someone to call when the shit hits the fan. While I will completely agree that Gentoo *can* be used in the enterprise successfully, that does not make it "enterprise-ready", in any sense. Many people also seem to misunderstand the concept of "enterprise" when we are referring to it in this manner. We don't mean "I'm running it on 10 servers in production" or anything like that. We mean "I'm running this as our production platform for Linux services across our entire enterprise, that could be hundreds or even thousands of servers" instead. While it might be possible to maintain a handful of Gentoo servers, it is next to impossible to maintain an army of them, without spending significant up-front manpower to design, test, and implement your own set of management tools. Gentoo has no real management tools. There are a few here and there that do specific tasks, but there isn't anything designed to really take control over your network of systems. To be fair, Red Hat doesn't have anything like this, either. Their "Satellite Server" product is good for initial builds and for updates, but falls short on the management aspects. Novell's offerings are probably the best examples of what we really need. Of course, most people would be happy with even rudimentary management capabilities, as currently, we have none. We don't have any form of update server. You have to build one yourself. We don't have any form of "jump-start" or "kickstart" for rapid automated deployments. You have to build one yourself. Now, we do have the Gentoo Linux Installer project, which has this as one of its goals, so we will have this component at some point in the future. Last, there's the "Our servers just went belly up, and I want to call up someone on the phone and give them a piece of my mind" issue which gives managers a warm, fuzzy feeling, that we cannot provide. If something goes wrong with RHEL or SLES, you call up Red Hat or Novell and get them to work on the problem. If something goes wrong with Gentoo, you hop on IRC, or file a bug, and hope that somebody can help you in the time you need it done in, and not in 3 weeks when the maintaining developer gets back from his tour of the African Dung Beetle in it's own environment. Liability is a big selling point for the enterprise. I work for a telecommunications company, and we run Linux and Solaris. For our Linux, we run Red Hat, even though they have, on staff, one of the people that understands Gentoo's deployment capabilities better than most, via catalyst and the GLI. Why do we run Red Hat? When something breaks with one of their packages, we call them, and expect them to fix it. It is also a name that gives upper management the warm fuzzies. Gentoo has neither the brand recognition, nor the support capabilities to be a good sale to management. I'm not denying that Gentoo is very powerful, flexible, and gives the power back to the administrator, but that doesn't make it enterprise ready or friendly. A few success stories from a few people isn't much to support the position, when we are lacking in so many simple and obvious ways. Remember, if a manager can think of multiple ways to knock down the use of Gentoo, like the ones I've given above, what are you going to do to refute his claims? I want to see Gentoo as an enterprise-capable distribution myself, but I also understand that it is a long, hard road ahead of us, and there will still be some things we simply cannot provide as a community distribution, which was my reasoning behind the "fork". There would need to be an entity that is responsible, liable, if you will, when something goes wrong, and that has the manpower and resources
RE: [gentoo-dev] Re: where goes Gentoo?
Interesting thread. I have used Gentoo in enterprise situations very successfully, and I think the whole QA/live-tree argument is moot. In an enterprise environment, you might have a backup/testing machine to run your updates on first before they went live. You also wouldn't run new packages unless they passed your own QA tests first. Given the incredible flexibility of portage to support local mirrors, binary package preparation, and localized versions of packages (portdir_overlay), I would say that Gentoo is quite a contender in the enterprise environment. Perhaps we need some enterprise documentation to help people realize the full potential of portage? -Eric -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X plans
that's great :) Thanks for doing that. That's exactly what I done with XCB ebuilds. Maybe some of you don't know xcb, it a remplacement for Xlib. Currently it only available on cvs. I think it couldn't have to be ignore it. Some ebuilds for : http://guybrush.ath.cx/svn/public/portage/x11-libs/ Website : http://freedesktop.org/Software/xcb Also It's on heavy devlopment, and I'not a dev. So take the choice you'll find the best :) ++ Beber On 8/1/05, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > (This is an expanded, updated version of a recent blog post, so some of > you may have already seen parts of it.) > > Background: Upstream is splitting up the monolithic X.Org X11 release > into a huge number of modular releases, the combination of which will be > released as X11R7. Simultaneously, a source-identical monolith will be > released as X11R6.9. > > Gentoo will only add X11R7, the modular release. Roughly 280 packages > will comprise this release, so this will entail adding a few new > categories to deal with them. > > Here's the categories I'm looking at using, which is mostly a mirror of > how upstream breaks it down: > > ~* x11-apps: The various applications that come along with all X11RX > releases. 86 ebuilds. > > ~* x11-proto: The protocol headers. 30 ebuilds. > > ~* x11-libs: 43 ebuilds. > > ~* media-fonts: 35 ebuilds. > > ~* x11-drivers: All the video and input drivers. 68 ebuilds. > > ~* x11-base: The actual X server, and meta-ebuilds. <10 ebuilds. > > ~* app-doc: Old-format docs that haven't been broken into individual > packages yet. Probably just a couple ebuilds. > > ~* x11-misc: The data module, which contains bitmaps and xkbdata. > Also the util module, with imake, etc. <10 ebuilds. > > The new categories are x11-apps, x11-proto and x11-drivers. Of these, > the name for x11-proto (the protocol headers) is debatable. The upstream > module they're all in is called "proto," and their pkg-config (*.pc) > files are called fooproto. But I'm also open to names such as > x11-protocol or x11-headers, so let me know what you think makes the > most sense, both in understanding the meaning and in combination with > upstream's naming. > > My plan is to have a series of "submetabuilds" that combine into a > "supermetabuild," which will be the actual xorg-x11 ebuild. There will > be one submetabuild for each major component: apps, drivers, libraries, > etc. This will allow me to split USE flags out a bit (so e.g., x11-fonts > would have 100dpi, 75dpi, truetype as flags) as well as allow people who > only want e.g. libraries for a headless server to get them cleanly. > > I intend to begin adding these packages to the tree shortly after the > first release candidate, which should be happening very soon. > > > Repercussions: > > All packages in the tree will need to clearly enunciate exactly which > parts of X they need as DEPENDs and RDEPENDs, down to the library or > application level. > > Until such time as that becomes possible for everyone to do, the > x11-libs metabuild will PROVIDE virtual/x11. But realize that not > everybody will have or want all the X libraries installed, when they > only need a few. > > If your package depends on virtual/x11 for any reason besides libraries, > it will require a dependency update to work with the new packages. > > > My preliminary work on the modular ebuilds is at > http://dev.gentoo.org/~spyderous/x-modular/ -- browse this at your > leisure. The metabuilds are all in x11-base/. There will be no tarball > of this overlay available because I'm not interested in dealing with > other testers before the first release candidate has even come out. > > I eagerly await your questions and concerns. > > Thanks, > Donnie > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.1 (GNU/Linux) > > iD8DBQFC7owDXVaO67S1rtsRAu68AJwISOSEwUChCvgQ96Y1KJGFmNYb/wCfaOEz > WURqd84yUyrb9cJqmiZE6sc= > =L4yH > -END PGP SIGNATURE- > -- > gentoo-dev@gentoo.org mailing list > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] python module
Yes in the meantime I found that eclass. The problem was, that there was no setup.py file. I created my own and put it into the files directory. Here is my ebuild: http://bugs.gentoo.org/show_bug.cgi?id=101296 pyamazon is a Python wrapper for the Amazon web API. Homepage: http://www.josephson.org/projects/pyamazon/ You can check it out if you want. Comments are welcome. On Thursday 04 August 2005 09:15, Alin Dobre wrote: > Rene Zbinden wrote: > > Hi > > > > I want to write an ebuild, that installs a python module. After unpacking > > the zipfile there is only one module module.py. What is the best way to > > install that package. Is there an eclass that I can use? > > # The distutils eclass is designed to allow easier installation of > # distutils-based python modules and their incorporation into > # the Gentoo Linux system. > > > -- > Alin DOBRE > Romanian Lead Translator > Gentoo Documentation Project: http://www.gentoo.org/doc/en/ > Gentoo.RO Community: http://www.gentoo.ro/ -- cheers, reen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] python module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rene Zbinden wrote: > Hi > > I want to write an ebuild, that installs a python module. After unpacking the > zipfile there is only one module module.py. What is the best way to install > that package. Is there an eclass that I can use? > # The distutils eclass is designed to allow easier installation of # distutils-based python modules and their incorporation into # the Gentoo Linux system. - -- Alin DOBRE Romanian Lead Translator Gentoo Documentation Project: http://www.gentoo.org/doc/en/ Gentoo.RO Community: http://www.gentoo.ro/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC8cCEmG51ym6Hu9gRAk9gAKCRMqjuq6p/2Ol3IWe+PJ8w9QIwngCg7bqZ EW6k7a7lCsDq+vABZDPR+dg= =3coQ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
