Re: [gentoo-dev] Re: Last rites sys-apps/855resolution
Rémi Cardona wrote: Markus Ullmann wrote: Because it looks like the 2.x intel driver might still need this type of hack to work properly for some types of machines (my laptop being a good example of this...) Also 2.x breaks on my notebook when using xinerama and dual monitor atm so nothing rock solid yet ;) I'm getting it too, it's far from being stable. Here's the upstream bug for those who could help or just track progress. https://bugs.freedesktop.org/show_bug.cgi?id=10299 Cheers, Rémi I don't think that Xinerama is really supported anymore. It's not really needed, depending on what you're trying to do - Xrandr 1.2 should handle most general/common use cases. Josh signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] It seems our ChangeLogs are quite borked
Petteri Räty wrote: I got annoyed enough about emerge -pl not working when people don't use echangelog like: # $Header: /var/cvsroot/gentoo-x86/x11-libs/libXinerama/ChangeLog,v 1.27 2007/03/22 02:18:21 joshuabaergen Exp $ 22 Mar 2007; Joshua Baergen [EMAIL PROTECTED] +libXinerama-1.0.2.ebuild: Version bump. Includes new documentation and some small code tweaks. Because it's missing *libXinerama-1.0.2 (22 Mar 2007) emerge -pl does not work. This lead me to write the code to detect these cases: https://bugs.gentoo.org/show_bug.cgi?id=171962 You can find the results here: http://dev.gentoo.org/~betelgeuse/changelogs_with_bad_new_revision_entries.txt Most of these probably probably date back to time before echangelog but feel free to fix your packages any way :) Regards, Petteri I actually did use echangelog, so maybe something else is going on here... Josh signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] It seems our ChangeLogs are quite borked
Joshua Baergen wrote: Petteri Räty wrote: I got annoyed enough about emerge -pl not working when people don't use echangelog like: # $Header: /var/cvsroot/gentoo-x86/x11-libs/libXinerama/ChangeLog,v 1.27 2007/03/22 02:18:21 joshuabaergen Exp $ 22 Mar 2007; Joshua Baergen [EMAIL PROTECTED] +libXinerama-1.0.2.ebuild: Version bump. Includes new documentation and some small code tweaks. Because it's missing *libXinerama-1.0.2 (22 Mar 2007) emerge -pl does not work. This lead me to write the code to detect these cases: I actually did use echangelog, so maybe something else is going on here... Josh It appears to be a problem with gentoolkit-dev-0.2.6.3. 0.2.6.2 produces proper changelogs. Josh signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: x11-apps/mkcfm
Masked for removal today (January 13, 2007). Package never went stable on any arches, doesn't build against newer libXfont versions[1], and is deprecated upstream[2][3]. Josh [1] http://bugs.gentoo.org/show_bug.cgi?id=157112 [2] http://lists.freedesktop.org/archives/xorg/2006-November/020106.html [3] https://bugs.freedesktop.org/show_bug.cgi?id=5553 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Herds, take your marks...get set...take stuff!
Donnie Berkholz wrote: Donnie Berkholz wrote: This should be x11-drivers, but somebody misspelled it with a capital X. Same goes for other stuff in this category and x11-base as well as ttmkfdir. With the exception of xdirectfb. Someone please take that if you want it. (Maybe Josh does?) Thanks, Donnie I do not :) I was only fixing bugs until we disowned it, and I'm not sure if it's even feasible to maintain against modular X. Josh signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New developer: Ryan Hill (dirtyepic)
Petteri Räty wrote: His hobbies are quite interesting too: When I'm not enjoying the -40/+40C Canadian weather or dodging lightning That's Saskatchewan weather, actually. We don't get that warm in Edmonton ;) Welcome Ryan! Josh signature.asc Description: OpenPGP digital signature
[gentoo-dev] X.Org 7.1 is Stable
X.Org 7.1 has been released from its binary driver jail to the (un?)stable masses! Does it build? Only on Tuesdays! Does it run? Often! Will it damage your system? I like cheese! A summary of new features, quoted from the GWN: This release features the addition of accelerated indirect GLX (AIGLX), which allows for eye candy such as the Compiz window/compositing manager, as well as running 3D accelerated display walls with Xdmx. X.Org 7.1 also integrates the kdrive (TinyX) servers for embedded systems into the xorg-server package with the kdrive USE flag. The kdrive integration additionally provides Xephyr, an enhanced Xnest-like client. Numerous video drivers also received significant updates. I also add that many, many bugs were fixed. To run Compiz using AIGLX, xorg-server must be build with the aiglx USE-flag. This is known to cause some EXA slowdowns (bug #147841). Joshua Baergen signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] X.Org 7.1 is Stable
Note that this applies to AMD64/x86 only. Many platforms have had this stable for awhile, and some still have 7.1 in the testing tree. Joshua Baergen signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: X.Org 7.1 is Stable
Sven Köhler wrote: Hmm, xorg-server-1.1* is stable now, but xorg-x11-7.1 is not. Did you forget that ebuild? ;-) Sure did! I fixed it a while ago though, so re-syncing now should get you the right keywords on the meta-ebuild. Joshua Baergen signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: compiz
Christian 'Opfer' Faulhammer wrote: So Gnome 2.16 will use AIGLX in Metacity? Not by default. The support wasn't deemed 100% yet and thus slipped to 2.18. You can enabled it through a compiler flag, and Hanno's overlay exposes this through a USE flag. Be warned that a few people are having fairly large problems with it still. See https://bugs.freedesktop.org/show_bug.cgi?id=5999 and note that it doesn't just apply to the r300. Josh signature.asc Description: OpenPGP digital signature
[gentoo-dev] media-video/yanc masked for removal
yanc has not been updated for 2.5 years, has two open bugs[1][2], one of which shows a crash on startup, and no one is really interested in fixing either. The package is unmaintained upstream, though a new rewrite called 'yanc42' has a pre-release that is over half a year old. nvidia-settings may be a suitable replacement for this package, though I've never used either. The ebuilds will be yanked (hah!) in 30 days. [1]http://bugs.gentoo.org/show_bug.cgi?id=72498 [2]http://bugs.gentoo.org/show_bug.cgi?id=83773 -- Joshua Baergen signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Duplicate licences
Ciaran McCreesh wrote: So you propose we go through and change every package in the tree that uses BSD or MIT (or GPL with the copyright disclaimer)? I propose that we decide on the correct way of doing things first, then decide a plan of action from that. And that includes an opinion from someone who knows what they're talking about, whether it be legal advice or a clarification to the point of the licenses directory. As Carsten pointed out one e-mail down in the thread, there's no real documentation about what licenses should be, so currently it's a he said-she said issue. Every other package maintainer manages to get it right. That it's a bit more work to do things properly is no excuse. You seem to contradict your above statement here. In any case, it's less work to just make almost everything MIT. Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Duplicate licences
Ciaran McCreesh wrote:
The duplicate licences situation is getting rather silly... We don't
include each variation for licences that vary only by the copyright
holder (if we did, we'd need a zillion new GPL-2s and BSDs, but instead
they just use placeholders), and we don't care about whitespace
variations.
snip
I'll refer to the MIT license as the one in ${PORTDIR}/licenses,
although I'm sure it exists in roughly the same form under some other
names as well.
The reasons that this system was chosen were correctness and
maintainability. Many of these essentially use the good old MIT license
with various companies' and/or individuals' copyrights at the top, as
you have stated. However, the MIT license does refer to the copyrights
within the license script itself, and many of the licenses have been
slightly altered to include a company's name directly. I'm no lawyer,
but to me this means that the license does indeed include the
copyright. (Note that I'm not intricately familiar with other licenses
that often have copyrights associated, so I don't know if MIT is
unique). If this isn't correct, I'd be very happy to switch all the
packages that use various forms of the MIT license over to it instead
and you can blissfully ignore the next paragraph. However, I'd rather
be on the safe/correct side than save a few MB that have to be
downloaded once.
Now, that splinters the licenses a good amount already, and thus
maintenance becomes an issue. If one half of the licenses are unique,
and we only keep unique ones, packages start depending on other licenses
in a spaghetti-like fashion. We can't just go ahead and change any
given license since it will mess up other packages dependent on that
license. Like good programming practice, I would argue that less is not
necessarily better.
Although I'm happy to take suggestions, my warning is to think from the
maintainer's perspective while proposing. That doesn't mean I'll whine
and say go away, but rather that I'll expect you to provide some
reasonable thought about maintainability, and possibly, like above, some
data to help us out. To me, the argument first comes down to whether or
not my thoughts in the first paragraph are valid.
Joshua Baergen
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuilds creating mountpoints
Stefaan wrote:
Prerequisite:
The ebuild needs to create the /afs directory, and remove that same
directory when it is uninstalled.
Why not just create the directory in ${D} or ${IMAGE} and let Portage
handle the rest? Do you really want to be removing /afs unconditionally
on unmerge?
Joshua Baergen
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ebuilds creating mountpoints
Stefaan wrote: You suggest keeping the /afs dir, this would be an easy solution of course, but it does seem untidy, doesn't it? (Makes me think of the windows uninstallers saying not all files could be removed, have a nice day) Ah, I of course didn't pay enough attention and didn't realize it was a mountpoint, not a storage place. Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] X.Org 7.0 Release
Peter Cech wrote: I solved my problems by commenting RgbPath setting in xorg.conf. I would suggest the line with RgbPath is commented in xorg.conf.example. While I'll respond here, it's generally better to post these sorts of issues on bugs.gentoo.org (searching first!), as they don't really belong on this list and no doubt others will have the same issues. From the xorg-x11 metabuild: # Filter out ModulePath line since it often holds a now-invalid path # Bug #112924 # For RC3 - filter out RgbPath line since it also seems to break things some excluded code that does just that After merging xorg-x11, running etc-update will rid your xorg.conf of these lines. This functionality has been around for a month or so in the ebuild iirc. I believe that xorg.conf.sample is not provided by 7.0 currently, so you're probably looking at a 6.8.x version. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] X.Org 7.0 Release
As many of you no doubt have noticed, spyderous and I finished bumping the modular packages to the newly released 7.0, which includes many changes and bug fixes since 6.8.2. Over the next few weeks we'll be finalizing licenses and other necessities. To whoever has been using modular for awhile: please let us know of any issues you currently have, or had during upgrading. A couple people have also asked if 6.9 will be added to the tree. There are currently no plans for this, and so 6.8.2-r4/6 (depending on platform) will be the last monolithic version barring any major security issues. I've already noted in a bug that bumping to 6.9 will not be as easy as just changing the package version, and we see no reason to provide it if 7.0 will be here anyway and upstream will not release any further monolithic versions. Merry Christmas, Joshua Baergen -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Eclass subdirectory for x-modular.eclass
In an attempt to patch all driver packages automatically, I've modified x-modular.eclass to do something along the lines of what elibtoolize does for its patching. However, this would require the storage of a patch for x-modular.eclass, which I would intend to place in a subdirectory of eclass (my current choice is x-modular-files). Am I allowed to create this subdirectory, or does this break policy/anything else I'm unaware of? -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Eclass subdirectory for x-modular.eclass
Martin Schlemmer wrote:
Use ${P}-patches-{PVER}.tar.bz2, and set PVER (or whatever) before
inheriting the eclass.
Thanks, I will do that.
--
Joshua Baergen
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X: ABI breakage
Rafael Fernández López wrote: Does this X version come with a new ATI RADEON driver ?? Do you know if DRI can be used with Composite extension in ATI cards ?? Thanks, Rafael Fernández López. A little off-topic, but yes, the 'ati' driver contains the new (experimental?) r300 code and EXA acceleration architecture that will accelerate the RENDER extension, and maybe the Composite extension - if not now, then later. Donnie is using this driver and seemed happy with it, but I don't know what card he had. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gcc-3.4 migration guide
Matthias Langer wrote: 2.) emerge -e world on a system with lot of packages will most likley fail somewhere during the process for various reasons. Fixig the problem (for example by unmerging the package which causes it) and restarting the process is not an option, as this may cost you lot's of time. In my case, emerge -e world stopped 3 times. To continiue without starting it all again, i did # emerge --resume -p package.list and then edited this file with vi so that # emerge --oneshot --nodeps `cat package.list` You'd probably be interested in 'emerge --resume --skipfirst'. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new developer Joshua Nichols (nichoj)
Jochen Maes wrote: Joshua, welcome! Another!? Confusion! Pandemonium! -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
Donnie Berkholz wrote: It may be that we'll need to add x11-base/apple-xfree into the || list If the list keeps growing maybe we should consider a GLEP 37-style solution, like was suggested by Jason. It would allow us to make any further changes that are required (agreed, hopefully none) without having to change a bunch of packages in the tree. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Reminder on dependencies.
Donnie Berkholz wrote: - - Packages requiring the headers have to DEPEND on them directly, because DEPENDs don't cascade. (Although this brings to mind the concept of some sort of cascadable DEPEND.) I remember some sort of BDEPEND idea being proposed awhile back, but that was for something different I believe. I wouldn't mind the ability to say that DEPENDing on x at build-time requires y during the build process, especially if more packages follow X's header structure. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Removal of x11-base/y-windows and x11-libs/libiterm-mbt
After thinking about this for awhile I'll just mask (and remove in a week or two) y-windows for now, as it is the only package with outstanding bugs. libiterm-mbt is a hacked version of libiterm and can be replaced by the cjk herd at their leisure. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Removal of x11-base/y-windows and x11-libs/libiterm-mbt
I will soon mask/remove y-windows due to a dead (and abusive) upstream (see bug http://bugs.gentoo.org/show_bug.cgi?id=100072 ). libiterm-mbt is a library associated with y-windows that will also and app-i18n/fbiterm is the only application that depends on it, belonging to the cjk herd. I'm making this public in case someone has issues with any of the three packages disappearing, particularly fbiterm (since it's outside my herd). I won't do anything to any package until I hear back from someone about fbiterm. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] tentative x86 arch team glep
Stuart Herbert wrote: The introduction of the x86 arch team will, at some point, turn the x86 arch team into a bottleneck (just like all the other arch teams already are) A possible way to alleviate this is proactivity on the maintainer's part. Our current rule for going testing-stable is 30 days. If we could alert the arch teams x number of days in advance they could test it before the end of the period minimizing delays. Since all arch teams would need this alert a relevant script could be created/modified. I realize this doesn't help if the arch teams are just plain too busy. Hopefully the 'fast arch' losing its speed will show people that we need more help in testing and bring more people on board. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Player, Stage, Gazebo eBuilds
Forrest Voight wrote: Hello, I made ebuilds for the player, stage and gazebo projects. (playerstage.sf.net) How can I commit them to the ebuild tree? Thank You, Forrest Start a bug at bugs.gentoo.org and attach the ebuilds. If they're not related make separate bugs. We'll review the ebuilds and then developers willing to maintain the packages can add them to the tree as long as there's enough user interest. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] src_configure
Jonathan Smith wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Diego 'Flameeyes' Pettenò wrote:
On Thursday 07 July 2005 02:04, Sven Wegener wrote:
We would like to split up src_compile. The
new src_configure should just do the econf part and src_compile should
do the emake part.
That will be very very interesting but... but not everything uses ./configure,
so we should add a bunch of dummy src_configure, and a call to econf || die
for those packages not fixed to use that will return a bunch of erroneous
packages not compiling.
you could simply make the default:
src_configure() {
[ -f ./configure ] econf || die
}
- --
smithj
Gentoo Developer
[ desktop stuff netmon documentation ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCzHcJl5AvwDPiUowRAqeFAJwIxve3a/X5BnlSBOxfv/Ac2lMAaACg30Pg
62/3CVfdiHVSppJfEe73DsY=
=lK9Q
-END PGP SIGNATURE-
By order of operations that won't work...I think you'll have to do if/then.
if [ -f ./configure ]
then
econf || die
fi
But that's a possible solution for sure. It would still introduce a lot
of ebuild editing for those ebuilds doing special conf stuff though.
Joshua Baergen
P.S. I tried sending this earlier but my client barfed, so I apologize
if it ends up double.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] EBUILD_FORMAT support
Sven Wegener wrote: And EVER automatically was E-VER for me, never had the idea to read it as ever. Does that count as being addicted to Gentoo? Sven Under the influence at the very least... -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: New Developer: Joshua Baergen
R Hill wrote: Mike Doty wrote: All- Please take a moment to welcome our newest developer, Josh_B. Josh is from Canada. Josh has joined to help out the X herd. In his own words, I'm originally from Saskatoon, Saskatchewan, but moved to Edmonton, Alberta in 1992. For the summer I am living in Sylvan Lake where I am the only software developer for a small firm (3 people :P) that develops various electronics. This job is part of my Computer Software Engineering (Co-op) degree at the University of Alberta, which I plan to complete in 2008. Although most of my current interests lie within the computing world, the underlying enjoyment in my activities is usually the opportunity for (difficult) problem solving. Vive les Saskatchewanianians! ;) --de. (in Regina) Nice :) I'll have to retract my land of no technology comments now... Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ATI Radeon Xpress 200 Drivers
This might be a problem with the drivers as well. I have seen this issue on other systems with various ATI cards and I have yet to come across the solution for it. On 6/28/05, Chris Frederick [EMAIL PROTECTED] wrote: Luca Barbato wrote: Chris Frederick wrote: I'd be happy to help test. Is there any testing methodology that I should follow? Or any specific application I should test, or xorg config settings I should try? Just unmask and emerge the .13.4 driver as usual and use it as a standard ati-driver. If it works as should that means that I repackaged it correctly and requires no other patching... lu Everything works. The only problem is that it appears to be painfully slow. I have 4M generic video cards from the mid 90's that are giving faster framerates, and this thing is in an amd64 3K. I'm going to check the bios tonight, the board is using shared memory, and I might have set it really low since it wasn't working before. Other than that it's working well. Thanks Chris Frederick -- gentoo-dev@gentoo.org mailing list -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] chriswhite herd(?) status update
On 6/14/05, Patrick Lauer [EMAIL PROTECTED] wrote: On Tue, 2005-06-14 at 20:24 +0200, Andrej Kacian wrote: On Wed, 15 Jun 2005 11:49:28 +0900 Chris White [EMAIL PROTECTED] wrote: on a minor note, I was thinking of maybe a somewhat small comprehensive list of major problems and ways to solve them. I know we do have bugzilla, but bugzilla is kind of full of noise (look at all them bugs!). Therefore, I think a small page with major stuff like Oh my god, my stuff doesn't compile or It can't find my library! would help. Ways of solving it would also be nice. I was thinking of having the page archive things that are 1 month old and everything else is front page. Let me know what the thoughts are on that. Ok, that's it... That's a good idea, something like topic on #gentoo, but in form of a website (and perhaps a RSS feed?) I like the idea. Questions: - do we want that? - who will take care of it? wkr, Patrick -- Stand still, and let the rest of the universe move BodyID:125254787.2.n.logpart (stored separately) A couple other things I can see becoming an issue: 1) We don't want to undermine bugzilla's function. Yes, it's noisy, but a suitably motivated individual (to use Donnie's catchphrase) can find what they're looking for. Taking people off bugzilla could mean less bugs solved, and it could also mean people saying, Oh, look, it's not on the RSS feed! Let's file a bug. 2) At the risk of merely restating Patrick's second question, maintaining a mini-bugzilla (I know that's not what it will be, but nonetheless) takes developers off of solving bugs, instead tasking them with re-packaging existing solutions that can be found (refer to 1 ;P). That been said, I think it's a great idea for those who don't know a lot about the open source process or even Linux in general. Maybe it would be a good idea to make the page refer back to bugzilla often enough to make people wonder what it is, as well as get them used to the sight of it. That makes it less work, as the maintainers can merely summarize solutions only if necessary, and link up to the bugs. I know this would be really useful for when we have those common bugs where you see a bajillion duplicates. From people who think bugzilla is a forum to post their problems. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] chriswhite herd(?) status update
Ok, so paraphrase. :P On 6/14/05, Donnie Berkholz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joshua Baergen wrote: 1) We don't want to undermine bugzilla's function. Yes, it's noisy, but a suitably motivated individual (to use Donnie's catchphrase) can find what they're looking for. I used the word individual in reference to a person? Please kick me or something, if I actually did. D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCr0xRXVaO67S1rtsRAmNDAKDDrPJ3f6vjofm4+j+G+ScvJkxPYACfaj3R c9ZIF/jPoWoOoYe2fRG5lUc= =HF12 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ekeyword and ordering
On 6/11/05, foser [EMAIL PROTECTED] wrote: On Sat, 2005-06-11 at 17:28 +0900, Jason Stubbs wrote: By lack of policy? Well I'm sort of concerned by the fact that I have to state the obvious, but really by people reordering them for no reason. It's not the lack of policy that is the problem here, it's the use of some self defined not uniform policy. There was no need for policy or regulation until some people set their own rules to play by, I really don't understand why that move gets defended by anyone. - foser BodyID:123219267.2.n.logpart (stored separately) But if the policy doesn't exist there is no reason for new developers to play by the current rules. The mentor certainly doesn't have to mention it because it's not policy, it's not stated anywhere on the devrel guide (unless I missed that section - it's certainly not within the variable description section of the ebuild guide). My point is that unless it's made policy there is no reason to expect that everyone's going to follow what even a group of people consider logical order. Personally, if I'm looking through keywords, I don't care what order they're in. It's not like there are 100 keywords or something, it should take a person paying attention long to look through them and pick out any errors. Therefore, I would not really care what order I put the keywords in unless someone told me, This is the order to put them in. I don't think people set their own rules to play by in spite of the rules, but rather because they didn't know there were any. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ekeyword and ordering
On 6/11/05, Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: On Saturday 11 June 2005 17:21, Joshua Baergen wrote: I don't care what order they're in. It's not like there are 100 keywords or something, Wait until ppc-od, x86-fbsd and amd64-fbsd keywords make their way into the tree... the problem there is worst, and the alphabetical order is really simpler to manage. -- Diego Flameeyes Pettenò Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64) http://dev.gentoo.org/~flameeyes/ Point taken :P I knew that was coming, but I didn't think about it when I wrote that. Personally, I would support any policy as to avoid different people putting different meanings into the orders, especially if there are groups of people who believe that everyone should do it their way (maybe everyone should). I also think things like information pertaining to developer platforms shouldn't be put into variable ordering. When I write software I don't expect people to understand intricacies of my design decisions and requirements from the order I call functions or the order I give to my parameter assignments, despite some rule of thumb I or others believe is the right way. Not everyone thinks like me, and that's what comments and external documentation are for. -- Joshua Baergen -- gentoo-dev@gentoo.org mailing list
