Re: [gentoo-dev] rfc: should openrc be mandatory on all gentoo systems?
On 30 June 2011 04:47, Mike Frysinger vap...@gentoo.org wrote: On Wednesday, June 29, 2011 22:19:09 Michał Górny wrote: On Wed, 29 Jun 2011 16:46:13 -0500 William Hubbs wrote: Ok, the option that I'm looking at now is to set up openrc so that the init scripts are optional and whether or not they are installed is controlled by a use flag which I will default to on in IUSE. Most people would leave this flag alone, but if you want to use something like systemd and do not want the init scripts or the /etc/runlevels directory on your system, you would just re-emerge openrc with this flag disabled. For now this flag will just control init scripts installation, but I will also look into taking it further and not installing other parts of openrc, such as binaries, man pages, etc which are only used if you are working on init scripts. Wouldn't it be better to just leave these people with INSTALL_MASK? USEflag means needless rebuilds just for the benefit of one file. so you're saying the solution for systemd users is to setup INSTALL_MASK and we shouldnt worry about tweaking openrc at all ? -mike Why can't we just split up functions.sh into /lib/output.sh containing the init script independent (but often gentoo specific) output stuff, and have functions.sh source this. Output.sh would be provided by a separate package (why not baselayout) and the packages using those would rewrite their stuff to use the right location. Paul -- Paul de Vrieze Researcher Mail: paul.devri...@gmail.com Homepage: http://www.devrieze.net
Re: [gentoo-dev] metdata.dtd should require herd/
On Wed, Dec 16, 2009 at 7:49 AM, Rémi Cardona r...@gentoo.org wrote: Le 15/12/2009 16:19, Peter Volkov a écrit : we will force all metadata.xml files have strict order of tags: first herd/ then other tags. Currently there are about 200 ebuilds with different order http://bugs.gentoo.org/show_bug.cgi?id=279206#c4 . Others and I actually make use of the order in metadata.xml. The first entry is the one that will get bugs assignment in bugzilla, and the others will get CCed. So if we're really going with herds first in metadata.xml, could we have an optional attribute - or whatever else you see fit - to convey that _this_ herd/maintainer is the main herd/maintainer? Thanks Perhaps we should create a schema to validate the file. XMLSchema (or any of the other standards) allows for much more flexibility in specifying these things. Btw. I did not design the metadata DTD for order to be significant. The only priority is that maintainer goes before herd, that's all. Paul -- Paul de Vrieze
Re: [gentoo-dev] Re: RFC: Make 10.0 profiles EAPI-2 'compliant'
On Saturday 22 August 2009, Chip Parker wrote: 2009/8/21 Robert Buchholz r...@gentoo.org: On Saturday 22 August 2009, Maciej Mrozowski wrote: It's true, but being able to modularize profile may outweights the need to be strict-with-the-book here - it's a matter of usefulness. I think it should be decided by those who actually do the work in profile, whether it's worthy to push this now instead of waiting for EAPI approval. So, can profile developers share their view? We have kept SLOT dependencies and other EAPI-0 features out of the tree profiles, introduced profile EAPI versioning to foster interoperability. Now what you propose is to break this deliberate upgrade process to introduce a feature no one proposed for the profiles directory in the last years? I wonder what the value of the PMS specification is if every time an inconsistency comes up the argument is raised that it should document portage behavior. EAPI 1, 2 and 3 have been agreed by the council and PMS is in a stage where Portage should obey its definitions and not the other way around. I am not saying that this is the *fastest* way to innovate (although in my opinion it is a good way to keep interoperability). However this PMS process is what council has chosen for Gentoo, and either you follow it, or you try to improve it (working with the PMS subproject people), or you bring up a proposal to redefine how we handle standards within the tree. Trying to ignore the fact this standard exists is a way to breakage. Robert When the PMS subproject is overwhelmingly ruled by a single person who doesn't have official Gentoo developer status and yet it is allowed to remove features from portage (the reference implementation) that predated PMS at the direction of this same non-dev, you start to have a very big problem. If you were building a house, and the blueprints had been signed off on calling for 1 meter high doors, but the builder had built in 2 meter high doors, would you then go back to the builder and require him to do something that makes those doors unusable for the vast majority of people entering the house? If this feature, which HAD been documented (in bugzilla and commitlogs) prior to the first RFC for PMS, had instead been added yesterday, I would completely agree that we should revert it and it should be part of a future specification. Since this is instead a situation where the blueprints were wrong and the builder was correct, let's not go throwing away our normal sized doors. Since I, as well as the only person who's loudly having an issue with portage and PMS not matching up in this respect, are both USERS and NOT Gentoo developers, it's my opinion that portage should be left alone and PMS should be corrected to align with the spirit, if not the letter of what was documented WELL after the initial commit that added the feature. And, since I and the main contributor to PMS are both users, it's also my opinion that NEITHER of us should have anything to do with the policy/specification defining package manager behavior for the most prolific package manager in use today. Could all of you just let this go. In this case Ciaran is actually right. Furthermore, From the beginning of the project there has been behaviour which was technically allowed but not condoned for official packages. The more formalized approach with EAPI/PMS is no different. Now this thread is too long already, just shut up about it. If you find the portage behaviour desirable and want it allowed in the tree. Well, EAPI is the way to go. Remember EAPI is not established by Ciaran, but by the council. Paul -- Paul de Vrieze Email: pau...@gentoo.org
Re: [gentoo-dev] Unmasking of libxcb 1.4 and related libs in !2008.0 profiles
On Tue, Aug 18, 2009 at 5:38 PM, Jeremy Olexadarks...@gentoo.org wrote: On Tue, Aug 18, 2009 at 10:37 AM, Jeremy Olexadarks...@gentoo.org wrote: On Tue, Aug 18, 2009 at 9:52 AM, Rémi Cardonar...@gentoo.org wrote: Hi all, Just a quick heads up that I have just unmasked x11-libs/libxcb-1.4 and its companion libraries in all profiles _except_ 2008.0. Hey Rémi, Next time, mind running echangelog in the appropriate directory? It help us look at a glance for what files are changed and rsync users can't see commit messages. Thanks, Jeremy Oops, I need to recall this message. Sorry folks! =/ -Jeremy As a service to users, you might want to create an empty library: touch foo.c gcc -shared foo.c -o libxcb-x11.so.0.0.0 That's all -- Paul de Vrieze Researcher Mail: paul.devri...@gmail.com Homepage: http://www.devrieze.net
Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay
On Sunday 16 August 2009, Thomas Sachau wrote: Let me introduce a nice project, which was started by some users: Since the emul-linux-x86-* packages for 32bit libs for amd64 users are neither easy to maintain nor up-to-date, some users started to implement an eclass, which allows to build requested libs with additional 32bit support. Later i joined them and helped them improving it a bit, but it was and still is mainly their project, they do the main work keeping this overlay up-to-date. Also this overlay is a nice idea to drop emul-linux-x86-* packages, it either requires continual work or modification of many ebuilds in main tree to support this in long term. To avoid this, i took the original multilib portage patch from kanaka, adjusted it to the current portage code and added the ideas and code from the eclass version. The result is now a portage, which is able to build any ebuild with additional 32bit lib support. The current main regression are ebuilds and eclasses, which do not support this (e.g. perl modules and mysql). If anyone is interested: -for the eclass version, which is mainly maintained by users and is mainly intended to only replace the emul-linux-x86-* package: just add it via layman -a multilib (it should be pretty stable and mostly working). -for the portage version: It is also in the multilib overlay, but in a different branch called portage-multilib. To use this, you should read the instructions at [1] (doc/portage-multilib-instructions). This one should also mainly work, but there is probably a good amount of packages in the main tree, which may refuse to work with it. Bugreports: preferred way is #gentoo-multilib-overlay at irc.freenode.org, but we also have an alias, where you can contact us: multi...@g.o [1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib Good work, Unfortunately my 64 bit system is currently non-functional, but when it is working again (when I replace parts) I'll try the portage stuff out. Paul -- Paul de Vrieze Email: pau...@gentoo.org
Re: [gentoo-dev] Support for multiple ABIs (for Python modules etc.)
On Sun, Jul 26, 2009 at 5:21 PM, Arfrever Frehtes Taifersar Arahesisarfre...@gentoo.org wrote: 2009-07-26 14:40:13 Marijn Schouten (hkBst) napisał(a): Arfrever Frehtes Taifersar Arahesis wrote: I would like to present the plan of support for multiple ABIs. It should be sufficient for Python modules and might be also appropriate for some other ABI types (e.g. for Ruby modules). In the context of which problem are you brainstorming? This proposition is intended to solve multiple problems, but Gentoo Python Project especially would like to have it available during transitions to new Python versions (e.g. Python 3.*). Python 3.1 will be added to the tree in the next week. Over 10 Python modules should work with Python 3, but the majority of packages doesn't work yet. We want to provide possibility of installing Python modules into site-packages directories of multiple Python versions (e.g. 2.6 and 3.1). In currently existing EAPIs we *will* support it, but without checking Python ABI dependencies during dependency calculation. I don't think this is easy to do, but I think the solution to this problem should be the same as the (as yet not existing) solution to the multi-ABI problem as in (x86_64 vs. ix86). The biggest issue is to handle multiple instances of the same package and how to handle overlapping (ABI independent) files. Paul -- Paul de Vrieze
Re: [gentoo-dev] Re: [RFC] global useflags
On Thu, Feb 14, 2008 at 9:58 AM, Duncan [EMAIL PROTECTED] wrote: Markus Meier [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 13 Feb 2008 21:38:36 +0100: djvu: Enable support for DjVu (a digital document format with advanced compression technology and high performance value) I'm not complaining if this is deemed acceptable, but I thought the idea was to keep it to 80 chars, if possible. If that's the case, perhaps leaving it at (a digital document format) might be preferable. That still says at least what it is, so is workable IMO, even if the longer description is certainly nicer if the 80 char limit no longer applies. What about: djvu: support DjVu, a PDF-like document format esp. suited for scanned documents -- Paul de Vrieze Researcher Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
Re: [gentoo-dev] RFC: adding support for running eautoconf to base.eclass
On Feb 13, 2008 10:44 AM, Petteri Räty [EMAIL PROTECTED] wrote:
What do you think about adding support to base.eclass for running
eautoreconf?
so instead of
src_unpack() {
unpack ${A}
cd ${A}
eautoreconf
}
would just add
EAUTORECONF=yes
inherit base
Sounds sensible
Paul
Re: [gentoo-dev] Packages up for grabs
On Thu, 6 Sep 2007 03:15:34 Chris Gianelloni wrote: net-misc/cisco-vpnclient-3des While my current employer uses such a router, I find that the vpnc client works better in that it does not force me to route all traffic through the vpn, but allows me to make my own routes. Of course vpnc does not require binary kernel modules either. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Watch out for license changes to GPL-3.
On Fri, 13 Jul 2007 08:33:04 Steve Long wrote: OFC you require all Gentoo ebuilds to be assigned to Gentoo-- that's fair enough, I accept and support that. It just seems odd that we can't contribute under GPL3 if we so choose. But yeah, all stuff in Gentoo is (C) by the Foundation, and it's all available under GPL2 only. The Foundation can aiui change that to any license it chooses, in the same way as the FSF has changed the license for its copyrighted works to GPL3. Hi Steve, I'm a bit late in replying to you, but I hope the following will clarify things. First the reason why gentoo is not GPL-2 or later. Basically doing so opens your software up to the whims of the FSF without allowing you to consider whether the new version of the license is desirable or not. With central copyright ownership (whether or not it is legal) it would not be an issue either because the foundation / gentoo technologies (in the time) could relicense it when needed. The second one, why not GPL-3. First of all, is an ebuild a derived work of skel.ebuild? Personally and as a trustee I have no idea of whether it is a derived work from skel.ebuild at all. Or whether skel.ebuild could be seen as a creative work in the sense of the Berne convention (International copyright threaty). What I know is that in general deciding this criterion for software is rather hard. Especially with something this short. One of the criteria is whether it would be straightforward to reproduce the code similarly without having seen the original. If you were to remove all comments from skel.ebuild this criterion seem likely to hold (IANAL). So depending your judgement or the legal advice you take (I can not tell you what is the truth, or what is the foundation position on this), you might be able to put any license desired on ebuilds you write yourself. Whether or not we would accept new ebuilds under GPL-3 or not, that is a different issue altogether. Currently all gentoo software that is not in the form of patches to other people's work is released under the GPL-2. At some point in time there used to be some policy about this, but it seems to have disappeared. Perhaps something that might be discussed. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Some ideas on how to reduce territoriality
On Sat, 4 Aug 2007 08:06:07 Chris Gianelloni wrote: - HOMEPAGE changes - LICENSE changes - arch-specific patches/dependencies - If someone is requesting KEYWORD changes on a package and it requires a patch or additional dependencies for your architecture, you are not only permitted, but really are required to make the necessary changes to add support for your architecture. - Typo fixes - SRC_URI changes - If the source has moved, feel free to fix it. We shouldn't have to wait on the maintainer to fix something this simple. - *DEPEND changes due to changes in your packages - If a package that you maintain moves, splits, or otherwise changes in a manner that requires dependency changes on any other packages in the tree, you should make those changes yourself. You're free to ask for assistance, of course, but you have the power to make the changes yourself without asking permission. After all, you're the one breaking the package, so you should be the one to fix it. - Manifest/digest fixes - metadata.xml changes snip So, what do you guys think? From my maintaining perspective it is ok if language support teams come in and fix binding issues with packages that are not specifically for that language but somehow have bindings. Like emacs, bash-completion, perl, python, java, etc. support in subversion. I don't really know some of these languages well, let alone how to best support them in gentoo. I don't mind help from those teams to get that stuff integrated and running well. Paul -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: ML changes
On Fri, 13 Jul 2007 15:11:19 Duncan wrote: Ryan Hill [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 12 Jul 2007 19:01:53 -0600: Why don't we create the gentoo-project mailing list, and, you know, actually wait a bit to see how that actually goes. Then we can talk about how best to handle -dev. One shit at a time, people. +1 It should also be noted that it's council election time, and I don't believe a change such as closing -dev to moderated write status is really urgent enough to have the outgoing council handle. Let the folks running for council now make their positions part of their platforms, and after - project is up and running for a couple months and the new council is in place, /then/ let's see if moderating -dev remains a burning enough issue to be voted on. I agree with you that this should be pulled over the election. That will also allow some time to see how the -project list works out. Paul -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
On Fri, 13 Jul 2007 17:11:55 Seemant Kulleen wrote: This leaves two courses of action. 1. Officially install him as such; or 2. Stop letting him wield his power over you. (yes, you, not us -- concentrate on how much you let him affect you). I guess you know my vote. Option 1 is unacceptable. Paul ps. Not that I've been letting him do so, but I've been otherwise occupied. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
On Sat, 14 Jul 2007 01:34:17 Thomas Tuttle wrote: Personally, I prefer quicker mechanisms to slower ones, but some people dislike real-time communications because they can interrupt their work constantly. I think what's important is not the signal-to-noise ratio, per se, but the relevant-to-irrelevant ratio. To me, it makes no difference whether the traffic that I don't care about is spam/trolls or just discussion of another project. So I'd support -dev being for coordination of core development and -project being for other things, so that people can read all of -dev easily and simply pay attention to only what they want to see on -project. But I see no reason to moderate either -- #-dev is moderated because IRC is an easy medium to disrupt. It's a lot harder to wander on to a mailing list and start trolling, and it's easier to block. Many people also have very little time to invest into gentoo. For those it is not possible to be on IRC often, while for e-mail you can indeed save up things until the end of the day and reply when it is convenient to you. As such a -dev mailing list is much more useful than a #-dev IRC channel. Ignoring the list is ignoring many developers who want to do work instead of monitoring IRC. Paul -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] package with funny licence
On Wed, 4 Jul 2007 03:01:52 Jeroen Roovers wrote: On Tue, 3 Jul 2007 12:21:12 +0200 Ulrich Mueller [EMAIL PROTECTED] wrote: Today I stumbled over a package that has the following funny licence in its file headers: ;; Bozoup(P) 1995 The Bozo(tic) Softwar(e) Founda(t)ion, Inc. ;; See the BOZO Antipasto for further information. ;; If this is useful to you, may you forever be blessed by the Holy Lord ;; Patty. ATT you will. That's not a license, it's a copyright notice with added fluff. The package was marked as GPL-2 but I think this does not really hit the spot. ;-) If I were you, I would ask the author and not simply label it as-is. GPL-2 it definitely isn't. The whole license is especially completely unintelligeable. Is one actually allowed to distribute/modify/use the software at all? It is probably best to dump the package. Paul -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff)
On Sat, 30 Jun 2007 01:12:02 Olivier Crête wrote:
On Fri, 2007-29-06 at 09:30 +0200, Luca Barbato wrote:
Paul de Vrieze wrote:
There are various problems that need to be addressed for cross
development and (especially) multilib/abi. One of the other ones that
you didn't mention is some kind of subpackage support. For example when
one installs 32 bit gtk+ to use binary firefox on an 64bit system it
can share the headers and docs etc. with the 64 bit version. Removing
either of them must however still preserve those files.
A quick and dirty way implies that:
- only the main abi can install stuff /usr/
The secondary need to be able to install into their /usr/${libdir} ..
its actually the only place where stuff from the non-main abis should be
imho.
If one requires synchronized versions, there should in 99% of the cases not be
any issue with header files and documentation. It will be equal, so can be
shared. It might indeed be an option to require the main abi to be always
present.
Paul
ps. for include headers it is rather straightforward to make forwarding
headers with architecture dependent redirects (using the architecture
defines) in case the headers are not arch independent.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [PMS] new dep list (useful just for cross stuff)
On Wednesday 06 June 2007, Luca Barbato wrote: yesterday we discussed about cross development and why the gentoo support for it works just to a point (and then has something missing) There are already some convoluted ideas about multiabi/multilib support with patches being discussed and there are some handy scripts that let you cross emerge stuff to a point (it has to be an autotooled package or has to be cross aware, it shouldn't depend on running certain programs). There are various problems that need to be addressed for cross development and (especially) multilib/abi. One of the other ones that you didn't mention is some kind of subpackage support. For example when one installs 32 bit gtk+ to use binary firefox on an 64bit system it can share the headers and docs etc. with the 64 bit version. Removing either of them must however still preserve those files. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpdr1YxYA5mq.pgp Description: PGP signature
[gentoo-dev] Re: Hiatus (sort of)
On Saturday 31 March 2007, you wrote: Hi all, Me and my wife and son are moving to Australia. We are now waiting for the visa's to arrive, and after that will need some time to set ourselves up. Our computers however are being shipped as we speak and will only arive in australia after roughly 6 weeks. I'm looking to buy a laptop, but connectivity will be problematic anyways. As such I will not be able to contribute as much as I would like. It took a while longer, but I finally have broadband again, and my computers back etc. I'll first be catching up on the email, but I'm back in action again. Now from Hobart, Tasmania (Australia) Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpT5CxtoeLta.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
Seemant Kulleen wrote: On Thu, 2007-04-05 at 13:29 +0200, Denis Dupeyron wrote: Why not simply allow trustees to veto a council decision ? This does not give trustees enough power to be a second council, but would permit them to stop something that they believe will damage Gentoo. This is very little red tape IMHO. I believe that the trustees do not necessarily have any jurisdiction over the council. They are concerned with legal type matters that affect the foundation, not with technical and political things within Gentoo itself. I could be wrong about this, but that's how I read it. Actually much of the hardware that supports gentoo is owned by or lend to the foundation. The trustees have legal control over that (while infrastructure has technical control), so if it comes to a pissing context, the foundation would probably win. It is not a situation anyone would want to get into. There is no other formal relationship between the foundation and the council. Paul (Gentoo dev/trustee) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Hiatus (sort of)
Petteri Räty wrote: Paul de Vrieze kirjoitti: Hi all, Me and my wife and son are moving to Australia. We are now waiting for the visa's to arrive, and after that will need some time to set ourselves up. Our computers however are being shipped as we speak and will only arive in australia after roughly 6 weeks. I'm looking to buy a laptop, but connectivity will be problematic anyways. As such I will not be able to contribute as much as I would like. Paul So I am guessing this means that we are free to touch your packages? Well, If you don't completely restructure them. I currently maintain sys-libs/db and subversion (and sort of look a bit after neon as being orphaned and required for svn). Robbat2 sometimes also looks after db so he's the guy who can tell you what to do with it. It's a bit complex in its relationship with dependants. (So be very very diligent if you want to unmask it, doing so will cause a number of bugs that I'll not be able to investigate properly due to a lack of a gentoo host. We now also got the visa's and will fly on April 21th. After that I'll probably buy a laptop and be up and running ASAP, depending on the internet access. Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April
Danny van Dyk wrote: If anybody is interested, i can provide you (this is all gentoo ebuild devs*) either with lists of QA problems in the tree to fix, or with tools that enable you to search for one particular (kind of) QA violation in the whole tree, whatever your prefer. It might be an idea if the QA team would post a QA issue of the week. It is my opinion that many QA issues come about because the developers just don't know it is wrong. The same mistakes get repeated again and again. To (anonymized) publish a QA issue of the week might help educate developers and help them to prevent doing the thing wrong again. It might also set a general QA awareness. Paul -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Hiatus (sort of)
Hi all, Me and my wife and son are moving to Australia. We are now waiting for the visa's to arrive, and after that will need some time to set ourselves up. Our computers however are being shipped as we speak and will only arive in australia after roughly 6 weeks. I'm looking to buy a laptop, but connectivity will be problematic anyways. As such I will not be able to contribute as much as I would like. Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] {Guide,Project, Foo}XML too confusing for many devs?
On Wednesday 28 March 2007, Josh Saddler wrote: Denis Dupeyron wrote: I find that as long as you read and follow the Gentoo XML Guide, writing docs is easy and using XML is handy. What I like the most is, as it was already noted, that I don't have to take care of the layout. However I have never found anything about writing project pages. Is there anything out there that I have overlooked ? If not, I'd really love to see this as a small addition to our XML guide. We don't maintain ProjectXML. Not sure who does, if anyone. It's definitely not the GDP's area of responsibility. FYI, we do have nice guides on writing GuideXML: [1] http://www.gentoo.org/doc/en/xml-guide.xml [2] http://www.gentoo.org/proj/en/gdp/doc/doc-tipsntricks.xml I do (sort of), and it is documented at: http://www.gentoo.org/proj/en/metastructure/projectxml.xml Unfortunately I don't know of any page that uses all features, but if you look around you can find some. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpGInWKoiyb5.pgp Description: PGP signature
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Tuesday 27 March 2007, Ciaran McCreesh wrote: On Tue, 27 Mar 2007 15:19:29 -0400 Mike Frysinger [EMAIL PROTECTED] wrote: one of Gentoo's priorities is to enable alternative package managers to coexist sanely ... it is not one of Gentoo's priorities at this time to replace Portage with a different package manager Do you acknowledge that Portage is a severe limiting factor when it comes to improving the Gentoo user experience as a whole? If it is not a limiting factor, portage is certainly a critical part of the distribution. And yes there are many features that should be offered but are not. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpHbA1mbup1V.pgp Description: PGP signature
Re: [gentoo-dev] {Guide,Project, Foo}XML too confusing for many devs?
On Wednesday 28 March 2007, Denis Dupeyron wrote: On 3/28/07, Paul de Vrieze [EMAIL PROTECTED] wrote: I do (sort of), and it is documented at: http://www.gentoo.org/proj/en/metastructure/projectxml.xml Unfortunately I don't know of any page that uses all features, but if you look around you can find some. Thanks Paul, that's exactly what I was needing. I didn't think of looking for it in the metastructure pages. I wrongly assumed it was GDP stuff. Denis. Well, googling for gentoo projectxml does get you to the right place immediately ;-). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpEWpIQnJk0f.pgp Description: PGP signature
Re: [gentoo-dev] Suggestion: INVALID - NOCHANGE in bugzilla
On Saturday 24 March 2007, Jakub Moc wrote: Kevin F. Quinn napsal(a): [snip] See, I don't really care how the reporter feels, if something's not a bug, then it's not a bug. Don't invent confusing 'politically correct' junk for this just because someone might feel 'offended'. One issue is actually with how to close bugs that were caused by a failure at the user side that was resolved. That might be marked NOCHANGE instead of INVALID. Sometimes the bugs are even valid in the sense that it makes sense that the user did something wrong, or forgot to run revdep-rebuild. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpewwhso5Dme.pgp Description: PGP signature
Re: [gentoo-dev] Re: Suggestion: INVALID - NOCHANGE in bugzilla
On Sunday 25 March 2007, »Q« wrote: Kevin F. Quinn [EMAIL PROTECTED] wrote: Closing INVALID is like saying they never had an issue - when clearly they did have an issue, even if it was just an issue of understanding. If bugs.gentoo.org users think that it's like saying there's no issue, ISTM the problem is with their understanding of bugzilla. To me indeed closing a bug as INVALID sends the signal to the user that what they filed as a bug was not a bug at all. Personally when I close a bug as invalid I have normally actually helped the user with the problem. And then I give a better explanation of the closure in the comment that goes along. So yes, I do think that closing as INVALID can be received as you actually wasted our time (and what that means to a user). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpssWSJOstrB.pgp Description: PGP signature
Re: [gentoo-dev] {Guide,Project,Foo}XML too confusing for many devs?
On Monday 26 March 2007, William L. Thomson Jr. wrote: On Mon, 2007-03-26 at 08:05 -0700, Alec Warner wrote: my basic question is do you as a developer find writing web pages to be confusing or difficult? As one who does a fair amount of web development myself. I rather like the guidexml formatted docs. Writing them is not a big deal at all. Do you find that you bump up against restrictions in the DTD or other problems that prevent you from expressing yourself properly? Haven't felt limited or restricted on anything yet. ;) Do you have any idea how to actually go about extending GuideXML (or the other XML's we provide) Have you ever tried? No clue on extension, and no I have not tried. Haven't had the need just yet. As author of the projectxml I can say that extension is not trivial (projectxml is somewhat an extension of guidexml). The main problem is that the documents must remain compliant to the DTD of the format. Extending as such is nontrivial. The way projectxml does it is accepting all the relevant guidexml tags, just copy those over and then run the guidexml stylesheet over the result (which then also includes the project specific stuff). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgptWlolmiQmR.pgp Description: PGP signature
Re: [gentoo-dev] {Guide,Project,Foo}XML too confusing for many devs?
On Monday 26 March 2007, Lars Weiler wrote: There are for sure some difficulties with our DTD, especially for our project-pages. Adding a news-entry at top or putting the elements in a fixed order. And that is mostly because of the nature of DTD's. As soon as you want to require items you have to give order or write out all possible orderings. The stylesheet hapilly accepts any ordering, but expects certain things to be there. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpGhYLZrAX4l.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-core] Re: two more tentative SOC ideas
On Thursday 22 March 2007, Grant Goodyear wrote: So basically the proper choices I can think of are to ask you to either a) install a _p.a version of berkdb that would be static but PIC-compiled or b) copy berkdb library in /$(get_libdir) and link dynamically. What do you think? Unfortunately Paul does not seem to have much time lately (he answered me though, but I leave up to him to quote his mail or not). At the moment I do have some time available. One can't think about packing stuff all the time (We're moving to Hobart, Australia early of April, as soon as the visa's are aranged). The library problem is complicated though. I could look at a static version though guarded by a useflag. The biggest problem though is that berkdb is not easy on version changes. Things tend to break when the used version changes. One might actually look at checking the actual version used and using big fat warnings if that changes. The static version is probably better as it protects against the berkeley db version used just disappearing from below. And breaking an authentication system really sucks (as in not being able to log in). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpHqumEIQcck.pgp Description: PGP signature
Re: [gentoo-dev] dont use `which` in ebuilds
On Friday 16 March 2007, Petteri Räty wrote: Ned Ludd wrote: Here are the remaining offenders for sync 1174037821 that match '$(which ' or '`which ' in eclasses and ebuilds. dev-db/hsqldb/hsqldb-1.7.3.1-r1.ebuild:48: This one just echos which to a script so it's safe I think. The reasons why not to use which still apply. Even though which is used in a script instead of the ebuild itself. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpY9jyEZ0nad.pgp Description: PGP signature
Re: [gentoo-dev] Introducing the Proctors - Draft Code of Conduct for Gentoo
On Wednesday 14 March 2007, Stephen Bennett wrote: On Wed, 14 Mar 2007 16:38:20 +0100 Ioannis Aslanidis [EMAIL PROTECTED] wrote: Ciaran, honestly and without any offense intention, what would be your answers to the questions you formulated? If you ask all that, assuming it's all rethoric, what is your opinion? I think his intention was to demonstrate that the idea is implausible, at best counterproductive and at worst disastrous. Which it is, and which he did fairly well. Could you explain how this is implausible. Removing contributions by a certain person may be silly or impossible. Refusing to accept new contributions is, while a very harsh measure, a possibility. Paul ps. Let me remind everyone that this is about new conduct, not about past behaviour. If anyone is afraid of the measures, all they have to do is behave properly. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpNuifNQkgI3.pgp Description: PGP signature
Re: [gentoo-dev] Introducing the Proctors - Draft Code of Conduct for Gentoo
On Wednesday 14 March 2007, Ciaran McCreesh wrote: So you consider it acceptable to remove the user's ability to use packages and dependencies of those packages because of some personal dislikes? It should not be personal dislikes. Such a strong position should be well considered by the ones responsible. Making things personal is highly unprofessional and would hopefully lead to many developers leaving. What gives Gentoo the right to screw over users in such a manner? Gentoo is gentoo. As a developer I like to think that we keep long term user interests at heart. I also know that I mainly do things out of my own desire. I don't go out looking for users to find out what they want. I look at what I want. (And yes that includes an improved/replaced package manager) What I really don't want however is anyone strongholding gentoo. If it is hurting gentoo to reject the contributions of someone, the situation has already gotten out of hand. I don't believe that people are that irreplaceable. Even if they are, that is something that is damaging to the projects continuity. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpj2RsoW22bZ.pgp Description: PGP signature
Re: [gentoo-dev] Re: Distrowatch
On Wednesday 14 March 2007, Kevin F. Quinn wrote: That's the exact opposite of my reading. The so-called mess in the last couple of weeks is nothing so unusual - happens every few months or so, and IMO it's more about steam venting than the specific issues at hand at the time. Responding to the sort of pathetic blogging seen on Distrowatch is a bad thing, its sends the signal that rantings on the blog-o-sphere are due some respect, which the article of the 13th certainly does not. Personally I couldn't care less what anyone (e.g. distrowatch) is writing about gentoo. What I do see however is that the atmosphere on -dev has become such (and is still, even after the latest big flame) that arguments (that often get personal) dominate the discussions. The bad part about it is that it drives away users interested in development, and even worse, developers. This has developed to a point where development discussions is hardly held on the -dev list. I want to stop the main gentoo development forum from becomming a debian^H^H^H^H^H^Hgentoo-politics. Paul ps. If someone wanted to start a gentoo-politics, by all means, go ahead, just don't expect anyone to read it. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgprrQKZpDyVy.pgp Description: PGP signature
Re: [gentoo-dev] Introducing the Proctors - Draft Code of Conduct for Gentoo
On Tuesday 13 March 2007 13:05, Sune Kloppenborg Jeppesen wrote: I wrote to Christel earlier today about this. But AFAIR we usually have at least a week to discuss such proposals. Apart from that enforcing our users this code of conduct with only three days of discussion is not what I find user friendly. First of all, I think most part of the code is just common sense. That's also the reason that it is not explicit about many things. Strictly defined rules don't apply in all situations, and jerks find ways around them or to argue that the rule does not apply to them. The modus operandi should be: We (council) define what is acceptable behaviour. If you don't like it, vote us off and get a better council. Until that time, comply. To me that is the only way to avoid free for all. We have seen that taping things over doesn't work. Before getting into any detail, perhaps in another mail, I have one objection to this proposal. I think it is a waste of time giving more paper rules for Devrel to enforce as long as they are in effect powerless to stop Gentoo developers from bad behaviour. As long as we as a group of developers can't even live up to the code of conduct we have agreed upon I don't think it is wise to enforce such conduct on the rest of the community. I don't see how this is an objection. It sound more like a remark or observation. Naturally the enforcement needs to happen and infrastructure must be supportive to that (e.g. by providing do-it-yourself tools to devrel). I do support more power to Devrel but lets try to keep the house clean before we take care of the garden. Well, I don't consider -dev to be our garden, but rather gentoo's living with an open door policy. Most participants are either devs, or are close to being devs. In any case they are not general users. Paul ps. I would also like to suggest that the devrels looks at things like micro bans. That is, banning someone for a couple of days from sending to the mailing list. This could be effective against e.g. people who continue to feed trolls after being warned not to do so. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpraoQ9QYRxV.pgp Description: PGP signature
Re: [gentoo-dev] Some council topics for March meeting
On Tuesday 06 March 2007, Grant Goodyear wrote: If I understand the process correctly, spb et al are writing their best vision of an ebuild spec, while trying to strike a reasonable compromise between what portage does and what it should be doing, but once they're done it's going to be submitted to the Council and the community to be analyzed, commented upon, and accepted in part, in whole, or not at all by the Council. If they take too long, or their work is too paludis-biased, or if people just don't trust the authors, then nothing is preventing anybody else from writing a competing spec. I actually know so, but as it seems that much work to write, it is quite a hurdle for someone else to step up with an alternative. It might be tempting to ignore a bias. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpk6cZyx7lLG.pgp Description: PGP signature
Re: [gentoo-dev] Some council topics for March meeting
On Saturday 03 March 2007, Ciaran McCreesh wrote: No, it's that you're dead set on derailing it and being as unhelpful as possible. You have absolutely nothing to contribute, as evidenced by every previous time you've gotten involved with anything I've done, and given how badly you tried to screw up GLEP 42 and how much of my time you wasted doing so, I really don't want to deal with your noise ever again. You also have a lot to gain by wrecking the process, and your past behaviour has shown that you'll stoop to any kind of dirty trickery and abuse of the system that you think you can get away with rather than having a proper technical discussion. Ciaran, could you please do this in private. We don't need pissing contests and flamefests on this list. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpdayJ6857k1.pgp Description: PGP signature
Re: [gentoo-dev] Some council topics for March meeting
On Sunday 04 March 2007, Andrej Kacian wrote: Dňa Sat, 3 Mar 2007 20:46:35 -0700 Daniel Robbins [EMAIL PROTECTED] napísal: On 3/3/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: Why is it a developer-only privilege? You just made that up. To co-lead a Gentoo project? You need to be a dev to do that. I couldn't join any projects even as a member until I became a dev, and I created the distro. You are effectively co-leading (likely leading) PMS as a non-dev - worse than that, as someone who has been explicitly removed from a dev role. Daniel, could you please stop that? You're being ridiculous and just wasting everyone's time with this. The guy wants to do some work on PMS, let him do it - in my opinion he's one of the most qualified people to do it. That remainst to be debateable. It is however also true that he is a party with a vested interest in the process. As such we must be warry of what we allow. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpCYS0DOWj7a.pgp Description: PGP signature
Re: [gentoo-dev] Some council topics for March meeting
On Saturday 03 March 2007, Simon Stelling wrote: Daniel Robbins wrote: 1) Any material created by Gentoo developers, as part of an official Gentoo Project, needs to have copyright assigned to the Gentoo Foundation, whether or not it is currently included in the Portage tree. This protects all of our collective contributions against misuse, which is why it is policy. Except that in many European countries you can't even re-assign your copyright. Oops. Only the moral copyright. You can reassign everything else. Or irrevocably license it or similar. It is not actually an issue at all. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgphaDr9SBWEN.pgp Description: PGP signature
Re: [gentoo-dev] Little respect towards Daniel please
On Sunday 04 March 2007, Ilya A. Volynets-Evenbakh wrote: Hubert Mercier wrote: That's probably why it is so hard to renew developer pool. Why do people keep repeating this myth? As kloeri pointed out, developer base keeps growing constantly. Which is a problem, because the growth without any proper structure just makes things even harder to manage. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpbEJeycMGz3.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] custom-cflags global USE
On Friday 23 February 2007, Chris Gianelloni wrote: On Fri, 2007-02-23 at 01:40 +0100, Carsten Lohrke wrote: And I'd be fond of having all the -ffast-math filtering ripped out of the tree as well. Except some things really do not compile with it enabled. Now, if you're meaning you'd prefer patch every compilation failure using -ffast-math instead, then I'd say go for it. Patches are always a better solution than workarounds. Except that software not working with -ffast-math is not in the wrong at all. It is like specifying -fno-rtti for a c++ program. If rtti is not used, this is fine. It is a part of the standard however, and this makes the compiler not except all standard-compliant code. These options are there to enable better code generation when it is known that the named features are not needed. They should never be globally enabled. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp571Z4qaVt7.pgp Description: PGP signature
Re: [gentoo-dev] Reliance upon || ( use? ( ) ) behaviour
On Saturday 24 February 2007, Jason Stubbs wrote: On Saturday 24 February 2007 12:34, Ciaran McCreesh wrote: On Sat, 24 Feb 2007 12:27:35 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: | For the 14 cases you mentioned that were making a mistake, they | probably can be rewritten so as to force an install of the first | matching package, but when that isn't what is wanted it becomes a bit | of a headache. That should *always* be what's wanted. Packages should only alter dependencies / build parameters based upon USE flags, not based upon what else happens to be installed. Okay, I must be missing something here. If package foo can work with either bar or baz equily as well but not both, why should it force an artificial preference? Also, if packages should not specify dependencies based on what is installed, the semantics of || ( ) would need to be changed such that the first non-masked packages is always installed. The only reason I can see for the above is to be able to have non-broken binary packages. However, that can be addressed by replacing *DEPEND in binary packages with their resolved forms. That is something that needs to be done anyway. In general a binary package has SLOT dependencies on the libraries it uses. It is also unwise to use it with an older version of a dependency. So RDEPEND==libfoo-1.2 Against libfoo-1.3.5(SLOT=3) (where 1.4(SLOT=4) exists too becomes something like: BDEPEND= ( =libfoo-1.3.5 libfoo[SLOT=3] ) I know this is not valid syntax, but it is just to convey the idea. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp6oF8eRTQsv.pgp Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thursday 22 February 2007, Ciaran McCreesh wrote: On Thu, 22 Feb 2007 04:04:37 + Steve Long [EMAIL PROTECTED] wrote: | I'm saying that until there is an independent implementation, the | specification is worthless and will contain huge numbers of errors. | | Seriously? Without an implementation, your spec of what should happen | will have loads of errors? Yes. It will describe what people think is allowed, rather than what really is. Perfect example -- we'd never have caught the multiple sourcing issue without an independent implementation. I'm sorry, but this was already a known issue over 3 years ago. And yes, the way portage handles ebuilds does not necessarilly win any beauty contest. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpYNgPY0OcPR.pgp Description: PGP signature
Re: [gentoo-dev] Re: EAPI spec (was Re: Re: let's clear things up (was Slacker archs))
On Thursday 22 February 2007, Ciaran McCreesh wrote: By that same argument, anybody who ever had to deal with abuse from bug wranglers wouldn't be using Gentoo. Which would mean a whole lot fewer users. Grow up. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpLKVFb7JPUU.pgp Description: PGP signature
Re: [gentoo-dev] Google Summer of Code 2007
On Friday 16 February 2007 19:38, Grant Goodyear wrote: Rémi Cardona wrote: [Fri Feb 16 2007, 12:14:31PM CST] To complement the both of you, how about proposing projects to 2 students at the same time and have them work as a team? It's against the rules to have two students working on exactly the same project, or at least it was last year. Perhaps the google people might have some suggestions on this. It seems that they should also be interested in getting value for their money. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpPc3urF9TGA.pgp Description: PGP signature
Re: [gentoo-dev] Network configuration and bash
On Friday 09 February 2007, Roy Marples wrote: On Thu, 8 Feb 2007 14:49:57 -0700 Daniel Robbins [EMAIL PROTECTED] wrote: In other words: busybox + single rcS file = fastest and simplest, smallest, best for very small filesystems, not as flexible bash + gentoo baselayout = most flexible, biggest, slower, best for feature-rich systems busybox + gentoo baselayout = ? FreeBSD sh + Gentoo baselayout = cold boot in around 4 seconds Going to multi-user from single user after a boot is under 2 seconds (times measured from when init starts rc - the difference is probably because the all my local mounts are still mounted) I have this running on a 2Ghz P4 Laptop right now. Admittedly, no network scripts are started expect for the loopback interface, but all default scripts + openvpn, ssh, dnsmasq, metalog and vixie-cron are started. Ladies and gentlemen, this has always been about one thing - speed. Ever since I got my 300Mhz Sparc64 to play around with FreeBSD, I've realised that baselayout + bash is just too damn slow. I think that's worth it. If that's what you want, don't use bash in the first place. I would agree that using bash for parsing is a pain in the but Daniel is right in that you're not going to be able to maintain posix compatibility. If you find an acceptable way to add the functionality to the network configuration files, it is ok, but sacrificing usability over an unmaintainable improvement doesn't work. If you want to speed up boot, the dependency generation is probably what's eating most time. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpS9X5o4MDYx.pgp Description: PGP signature
Re: [gentoo-dev] Abusing RESTRICT={no,}userpriv (was [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT)
On Friday 12 January 2007 22:35, Chris Gianelloni wrote: It has nothing to do with the sandbox. It's because /usr/games/lib isn't readable to people outside the games group. Isn't that a rather silly restriction. What is there in /usr/games/lib that may not be seen by people outside the group? The shared data shouldn't be. The binaries don't live there either, and could be restricted themselves. This seems to be an arbitrary restriction of the shoot yourself in the foot kind. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpYSx2u9FVL1.pgp Description: PGP signature
Re: [gentoo-dev] Abusing RESTRICT={no,}userpriv (was [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT)
On Sunday 14 January 2007 18:46, Chris Gianelloni wrote: On Fri, 2007-01-12 at 22:46 +, Stephen Bennett wrote: On Fri, 12 Jan 2007 19:36:06 + Tristan Heaven [EMAIL PROTECTED] wrote: On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote: They have to be able to read /usr/games/lib. In which case adding the portage user to the games group seems overall to be a better solution than requiring root privileges to build. Sure, and it means getting every single user that merges games to change their systems. It's possible, but something that would take a very long time to accomplish. No, just have some hack that fixes the permission on the /usr/games/lib directory to include read for others (if needed). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp2f46FSkZKQ.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wednesday 10 January 2007 19:03, Jakub Moc wrote: Mike Frysinger napsal(a): On Wednesday 10 January 2007 09:34, Jakub Moc wrote: Huh? I was referring to this link [1] on Bug 161045 (which presumably started this whole debate) so you're replying to a non-gentoo-dev thread on a gentoo-dev thread when the threads arent even closely related ? how does that make sense ? this thread has nothing to do with commercial packages No, it does not. And RESTRICT=sandbox is still completely unneeded, commercial packages or not... We don't need to introduce a special RESTRICT because of two borked packages in the tree and we should not introduce any more packages borked in a similar way into the tree. I agree. The restrict should only be even considered when it is clear that the sandbox is indeed flawed by concept and cannot be fixed. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpWhO94WyagX.pgp Description: PGP signature
Re: [gentoo-dev] Re: GPL-2 vs GPL-2+
On Wednesday 03 January 2007 22:54, Steve Long wrote: Paul de Vrieze wrote: I know that I'm a bit late on this, but to me the version 2 or later is a license by itself. Let's call it GPL-RENEW and let the file have contents like: This package is licensed with the version x or later clause for the GPL. The LICENSE would then be: LICENSE=GPL-2 GPL-RENEW The advantage being that the renew clause is version independent, we don't lose information, don't have to mutilate licenses (by adding text). If desired it could even be used as LICENSE=|| (GPL-2 GPL-3) GPL-RENEW That last bit's excessive IMO. It seems to add complexity- does it mean you can have either of the GPL2 or 3 plus any later from that version? Why not just cover that with your first example, which I like a lot- it spells out the later clause, and as you say, is version-independent. So GPL-3 GPL-RENEW could be specified, as well as simple GPL-2, or GPL-2 GPL-RENEW. (Just spelling it out, sorry.) I'm thinking about your example and I can see how it covers a user who *wants* to use GPL-3 (eg for their own code) but I still think that comes under GPL-2 GPL-RENEW as it's clearly allowed. My idea for the second way is basically to make the life of tools easier. It would make explicit that someone accepting GPL-3, but not GPL-2 would be able to accept a GPL-2 and later license. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpXrFy0X15tg.pgp Description: PGP signature
Re: [gentoo-dev] GPL-2 vs GPL-2+
On Friday 22 December 2006 22:53, Yuri Vasilevski wrote: Hi, On Fri, 22 Dec 2006 21:56:54 +0100 Diego 'Flameeyes' Pettenò [EMAIL PROTECTED] wrote: At the moment we represent the software we consider under GNU General Public License, version 2 of the license, but we cannot be sure it's alright to license it to any later version. Linux kernel for instance is licensed _only_ under GPLv2, but not any later version. I don't think this is a good solution, as in any case the package is licensed under GPL-2, so how about for the packages that only support GPL-2 we set: LICENSE=GPL-2 While for the ones that support v2 or later (this is actually a special case of multiple licensing) we do: LICENSE=GPL-2 GPL-3 I know that I'm a bit late on this, but to me the version 2 or later is a license by itself. Let's call it GPL-RENEW and let the file have contents like: This package is licensed with the version x or later clause for the GPL. The LICENSE would then be: LICENSE=GPL-2 GPL-RENEW The advantage being that the renew clause is version independent, we don't lose information, don't have to mutilate licenses (by adding text). If desired it could even be used as LICENSE=|| (GPL-2 GPL-3) GPL-RENEW Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpnjrniXQsr2.pgp Description: PGP signature
Re: [gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2006-12-17 23:59 UTC
On Monday 18 December 2006 20:14, Robin H. Johnson wrote: On Mon, Dec 18, 2006 at 10:02:00AM -0500, Chris Gianelloni wrote: On Sun, 2006-12-17 at 23:20 -0800, Robin H. Johnson wrote: The attached list notes all of the packages that were added or removed from the tree, for the week ending 2006-12-17 23h59 UTC. OK. Here's a fun question for you... Is it possible to have a slightly modified version of this script run, and the output sent to gwn-feedback for inclusion in the GWN? This would make my life tremendously easier, since currently I have to completely reformat this by hand. I'll just send you the CSV file that I script into the email, and you can come up with your own reformatting into GuideML, esp. as I don't have any easy way of resolving dev handle to their name for you. Actually we have a ready made xslt script available. It is the template named fullname in the util.xsl file. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpYIxnH2ngC4.pgp Description: PGP signature
Re: [gentoo-dev] missing metadata.xml
On Thursday 23 November 2006 11:20, Jakub Moc wrote: Bryan Østergaard napsal(a): I think the most important thing about adding empty metadata.xml files with maintainer-needed as maintainer is that it _changes_ the package to be unmaintained by definition (that's what maintainer-needed means after all) and that we can't be sure that's actually true unless we spend a lot of time examining each package and asking potential maintainers if it's unmaintained. Actually, I don't mind much. There's a developers or two who keep on adding packages without metadata.xml all the time (won't name anyone, I'm pretty sure they'll find themselves here :P). This will either force them to reclaim their packages via fixing the metadata.xml thing or will leave the ebuilds orphaned to m-needed - and then they shouldn't have been added in the first place. Above, I'm not talking about legacy stuff maintained in an ad-hoc manner for ages, but about fairly recent additions to the tree (~1 year or even less). However, even for legacy stuff, nothing is preventing the people from claiming their ebuilds the right way and adding themselves to metadata.xml - will make assigning bugs much easier for me. ;) Repoman should check for missing metadata. The only packages that are allowed not to have metadata.xml would be those that have not been changed for over 3 years (since the introduction of metadata.xml). Developers who violate the repoman checks by omitting a metadata.xml brought mayhem over themselves. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp3YMOUSQ20U.pgp Description: PGP signature
Re: [gentoo-dev] GNOME 1.x and GNOME 1.x dependent package masking
On Friday 10 November 2006 16:28, Daniel Gryniewicz wrote: On Fri, 2006-11-10 at 08:56 +0100, Marius Mauch wrote: Ok, the list definitely isn't accurate. If there is a legitimate reason to mask sylpheed-claws-1.x you also have to mask it's reverse deps. However I'm still waiting for the explanation why it is on that list. (I don't mind if it's masked for a good reason, but I need to know that reason). There is no immediate reason, of course. However, gtk+-1 and glib-1 will be removed as soon after the big cleanup as is feasible, and sylpheed-clasws-1.x is a gtk+-1 app, and therefore must go as well. I didn't generate the list, but my understanding was that it was intended to include all packages with a hard dep on gtk+-1, in addition to gnome 1.x. Gtk1 actually is broken for --as-needed. It's linking is broken thanks to a libtool which refuses to link against a non-installed libgdk. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpVuNDHFCX0V.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for November
On Wednesday 08 November 2006 04:47, Steve Long wrote: I understand the ABI changes at major compiler upgrades, especially for C++. Is this such a problem for C? I thought that was the whole point of the Linux ABI (so developers can in fact use the same binary for different distros.) I'm guessing you're going to point out all the posts about recompiling your whole system after a toolchain upgrade. So if I understand this right, we can't all compile for the same ABI since it changes according to which version of the C compiler/ glibc you're using. The problem is that for the applications, it is not only glibc+gcc that determines the ABI. It is all libraries used (sometimes useflags even make a difference) that are also ABI for applications. That would lead to a gazillion configurations that would be nearly impossible to track. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpVlCyUrNbpK.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Tuesday 07 November 2006 13:24, Michael Cummings wrote: On Mon, 2006-11-06 at 17:48 -0500, Mike Frysinger wrote: - make sending gentoo.org mail via gentoo.org mail server friendly/recommended -mike Not an option for everyone without a lot of needless hoop jumping, like ssh port forwarding. Cox (rhyme it as you will), my cable provider, doesn't allow 25 to leave their network. To send mail, I *have* to relay through their mail servers. For that reason there is a special port (587) for mail submission that should be supported by the gentoo servers. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpibnjTmwVKP.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Sunday 05 November 2006 10:59, Ciaran McCreesh wrote: On Sun, 05 Nov 2006 01:35:43 -0800 Peter Gordon Clearly this is one of those easy to understand issues where everyone has an opinion, and rather than fix their mail client or behaviour they try to have a huge debate about it... Don't you people have any bugs to fix? Also please remember that you can easilly do this yourself if you so desire. procmail (and thus formail too) is available on woodpecker, so you can add them/remove them from the core list as desired. As it considers -core you have access to woodpecker and the mail flows through it too. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpCLX7xLtF5c.pgp Description: PGP signature
Re: [gentoo-dev] Retirement
On Friday 03 November 2006 20:15, Jon Portnoy wrote: I've been mostly inactive for a good while but hanging on mostly for sentimentality's sake, it's past time for that to stop. I mostly only maintain a small handful of ebuilds, I'm sure they can find proper homes quickly. None are maintenance-intensive. And of course, the only thing anyone is really concerned about; robbat2 has already laid claim to fortune-mod-gentoo-dev ;) Later. It's been fun, it's been real, but it hasn't been real fun. :) I'll be around #gentoo/#-dev. I feel a bid sad to see you go. Even sadder that because of legalities you never got to serve on the board of trustees. For the rest, all the best of luck and see you around. Greetings, Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpoVl6oTu06M.pgp Description: PGP signature
Re: [gentoo-dev] RFC: put new additions along with removals in GWN
On Thursday 26 October 2006 00:57, Alec Warner wrote:
Caleb Cushing wrote:
reporting additions of new programs aren't feasible? or are you
referring to version updates and package bumps and such
Reporting removals will be done by treecleaners once I have it implemented.
Reporting additions may require some cvs foo on lark; such as new
directories in ${PORTDIR}/$CAT/
Someone needs to implement the foo; however.
(Not on cvs, but on a normal tree, but maybe works on cvs. There is a sanity
check by checking that a dir contains at least 1 ebuild)
= start =
OLDPKGS=/var/cache/gwn/oldpkgs
NEWPKGS=`mktemp -t`
find /usr/portage -mindepth 2 -maxdepth 2 |while read in
do
EB=`echo $in/*.ebuild`
if [ -n $EB ]; then
echo $in
fi
done $NEWPKGS
#These are new packages
cat $OLDPKGS $OLDPKGS $NEWPKGS|sort |uniq -u
#Old packages can be retrieved almost similarly:
#cat $OLDPKGS $NEWPKGS $NEWPKGS|sort |uniq -u
mv $NEWPKGS $OLDPKGS
= end =
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net
pgp2RvKjuIfSk.pgp
Description: PGP signature
Re: [gentoo-dev] The Dreaded herd tag
On Saturday 28 October 2006 08:11, George Shapovalov wrote: Which is exactly why these are disallowed. Or at least that was the original intention, which (unfortunately) was not enforced strong enough. But then, given that we started with *no herds at all*, I don't see how it would be possible to realistically enforce from the beginning. Now it looks like we are actually strating to get there. Besides, there is no no-herd tag, no matter what excuses people putting it in the metadata come up with. Being the one who came up with the no-herd tag I'd like to explain things a bit. Basically when we started there were no herds and packages didn't belong to them. It was agreed that every package should be put in a herd, but also that metadata.xml files were to be added and their existence enforced by repoman. This enforcing was easy so it happened before it could be expected that all maintained packages (they needed metadata.xml files) could have found themselves a herd. Then I thought it is better to temporarilly allow adding no-herd than to have everyone come up with his own version of the same. I should have remembered that there is nothing as permanent as a temporary solution. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpAVlEqEbNKP.pgp Description: PGP signature
Re: [gentoo-dev] RFC: per-package default USE flags
Simon Stelling wrote: Paul de Vrieze wrote: I would go for the EAPI bump. Even then I think it would be smart to wait a short while for packages to use this as we ensure that the supporting portage version is stable. Err, EAPI was designed to assure that a supporting version is actually used, no need to wait then. The waiting time is for a sanity check on the portage that as the new EAPI. One doesn't want to force users to use a portage with bugs and issues just to use newer packages. Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
Ciaran McCreesh wrote: On Fri, 13 Oct 2006 20:12:40 +0100 Stuart Herbert [EMAIL PROTECTED] wrote: | As the default USE flags are metadata about the package (not the | profile), it makes sense to store that data in the ebuild, along with | the rest of the package's metadata. No no on. Default USE flags are a property of the profile. Don't believe me? Go and have a look in an ebuild, and then in a profile. See which one specifies defaults for USE flags. I'm sorry, but Stuart's right. These flags specify what the recommended useflag usage is for a particular version of a package. The profile's version is specific to a particular tree, or even architecture. I would indeed argue that a nonempty global package specific use file in the profile is not needed. Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
Ciaran McCreesh wrote: | It's a stupid statement, not providing any further backing for your | position; please dear god spare us all the waste of time reading | your emails if that's how you're going to push for what you want... Not at all. Your argument could be rephrased like this: There are already lots of people dying in Africa, so it's ok to poison their food supply. That's a nonargument. But let me put it easier. Don't blame us when paludis made a design mistake and try to force that mistake on the rest of us. Instead fix paludis. Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Seeking the missing dates that past and present developers joined Gentoo.
Maurice van der Pot wrote: On Fri, Oct 13, 2006 at 05:42:59AM -0700, Robin H. Johnson wrote: I added ~100 joined dates thus far, however the archives (esp. for -core) that I have access to are not complete, and don't go back nearly as far as the depths of Gentoo history, Have you considered using the recruiters bugs in bugzilla? For me at least the date it was closed is the closest date I can come up with. Many people in that list were members before bugzilla was used for recruiting (and before we had a recruiters team). Some of the people even retired before that. Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: per-package default USE flags
Zac Medico wrote: Hi everyone, I've written a patch for portage [1] that implements per-package default USE flags at both the ebuild and profile levels (discussed a couple of months ago [2] on this list). At the ebuild level, default flags are specified in IUSE with a + prefix as described in bug #61732 [3]. At the profile level, I've added support for package.use which behaves like /etc/portage/package.use that everyone is familiar with. The intention is that the IUSE defaults will be used for default flags that should be enabled regardless of profile. Then, package.use will be used for flags that might vary depending on the profile. For example, a server profile might enable server flags and a desktop profile might enable client flags. Aside from being package specific, the per-package default USE flags behave much like USE flags that are currently listed in profiles' make.defaults. The flags are stacked incrementally as usual. The ebuild level defaults are at the bottom of the stack, followed by make.defaults, and finally package.use. The user can override these new flags in the same was as make.defaults USE flags could always be overridden (make.conf and package.use). Should we include support in portage for one or both types of per-package default USE flags? If support is included for IUSE defaults now, we won't be able to use them in the tree until after a waiting period or an EAPI bump [4]. I would go for the EAPI bump. Even then I think it would be smart to wait a short while for packages to use this as we ensure that the supporting portage version is stable. Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Missing: Universal-CD - Gentoo discriminates shell and networkless users
Duncan wrote: Anybody doing Gentoo on even a Pentium original is going to be compiling for awhile unless they do GRP only, and that's inadvised as GRP isn't security updated until the next release, six months later! A couple years ago when I first started with Gentoo and was on the main user list, I believe I saw a thread where a couple folks claimed to have done it on 486 mainly to be able to say they'd done so, taking weeks of course to do it, even compiling 24/7, but a 386? IMO there are better ways to spend your years... g Personally, I'd say 686 is the lowest reasonable to support at this point. Below that, try an appropriate binary distribution and save the days/weeks of compiling. Of course, Gentoo is highly customizable, and folks could try it on 386 if they wanted, but I don't believe it's worth supporting below 686 at this point. That's personally. I'm sure there are folks that would argue we should at least support 586, but I simply don't believe it's worth it. A couple of years ago (when we were still using gcc-2.95 I used to run gentoo on my server machine which was a pentium-60 (with fdiv bug). While it took a while to compile the bigger packages it was certainly workable. I did it because I didn't have a better machine, not to be able to say I did it. Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users
Steev Klimaszewski wrote: No... but didn't one download and burn that CD that is being used for the _networkless_ install? One could also download the stage needed, slap it on a usb key, and viola! Of course, the other option, is to use that crazy installer option Networkless - I could be wrong, but I do believe that is the option I would choose. (Actually I did this just the other day because of the issues I am having at home with my networking. And it worked splendidly on a P2 366 - so kudos to the releng team) The thing is, they guy does not want to use the installer. I don't remember there being a way to just extract the stages/packages manually either. At this point though I think using the installer is reasonable enough. Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
Maybe it depends on what you mean by 'in control'. What I mean is that you have a good stable base from which to work on, but nothing prevents you to tweak things like you want: Gentoo doesn't get in your way. http://www.gentoo.org/main/en/about.xml mentions Extreme Configurabiliy and the main picture states Larry the Cow was in control. And he liked it.. It certainly is, but if you do something against the developers advice there is a simple rule: If it breaks you get to keep the pieces. I agree (how could I say otherwise after spending several days with a hole in my foot finally finding that I had a gun named fast-math in my hand :-) ). Apparently many developpers think that it might be in CFLAGS though (see the amount of 'filter-flags -ffast-math' in ebuilds) so a reminder might not be wasted for some users. Those ebuilds should be changed to die instead of filtering. -ffast-math is just stupid to enable globally. Paul -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New project: Gentoo Seeds
On Wednesday 20 September 2006 23:06, Ciaran McCreesh wrote: A GLEP doesn't have to be bureaucracy. It can be nothing more than a way of ensuring that the correct technical decisions are made. For a project that could end up affecting a lot of people, getting the design right and determining exact goals is a very useful first step. As much as ISO-9002 certification doesn't guarantee quality products/services, a GLEP does not ensure correct decisions. It just ensures that some things will not get done because they are red-taped to death. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp3XFlEo4k9g.pgp Description: PGP signature
Re: [gentoo-dev] colon separated variables in /etc/env.d/
On Monday 11 September 2006 03:44, Zac Medico wrote: Hi everyone, Portage currently has two hard-coded lists of variables that control the behavior of env-update. I'd like to make these variables configurable so that package maintainers have direct control over them. The variables break down into two basic types: colon separated and space separated. What is the best way to propagate information about these two variable types? For example, we can have a list of variable names stored in a new variable called COLON_SEPARATED that will reside in either the profiles or /etc/env.d/ itself. Variable names not listed in COLON_SEPARATED can be assumed to be space separated. Does anyone have any ideas to share about how this information should be propagated? There should also be a third list (or the absense of inclusion in the above). That is those variables that can only have one value and are overridden instead of appended. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpNjh6gLevKm.pgp Description: PGP signature
Re: [gentoo-dev] Re: packages going into the tree with non-gentoo maintainers
On Sunday 03 September 2006 13:57, Stefan Schweizer wrote: Kevin F. Quinn wrote: I don't think it's a good idea for devs to be putting stuff into the tree without taking responsibility for it. sure I can put myself in there but it will help no one because I cannot test the thing. Furthermore I am actually part of maintainer-needed and commit fixes there. I am also on the maintainer-needed email alias. Also maintainer-needed makes obvious to everyone that they do not have to ask me to fix sth. or take over the package - less communication overhead. For this stuff, add a comment to the metadata.xml file. Don't do it in this less than obvious way. The maintainer must still be someone with a gentoo email. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgppqk7iNIoRS.pgp Description: PGP signature
Re: [gentoo-dev] cdrtools license issues
On Friday 01 September 2006 15:08, Diego 'Flameeyes' Pettenò wrote: I'm the first to not like Schilling's ways, but... On Friday 01 September 2006 14:44, Carsten Lohrke wrote: building GPL software with CDDL licensed makefiles Can't see how this is pertinent, I can build BSD licensed software with autoconf that is GPL, and use GCC to compile.. The build scripts are part of the source code. And as such must be licensed under the GPL. A system to create make files (such as autoconf) is not as such part of the work. Completely automatically generated makefiles do not qualify either as they do not fall under copyright law (they are not original works). It seems however that the makefiles included in the cdrtools package should fall under the GPL. This however does not mean necesarilly that Joerg Schilling violates the GPL as one cannot violate ones own copyright. If there is code that is not his however, he would violate the GPL. as well as linking mkisofs to libscg, which he relicensed to CDDL lately. This is a bit more debatable, he *can* link it, if he can change mkisofs license to allow linking to non-GPL-compatible code. Of that, I'm not sure tho. The GPL sucks in linking respect. Given the GPL however linking GPL-ed software to non-system libraries that are not GPL licensed (Not even LGPL) is a violation of the GPL. The GPL is very vague on the subject though. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpbMZk1WFJYM.pgp Description: PGP signature
Re: [gentoo-dev] cdrtools license issues
On Friday 01 September 2006 16:31, Diego 'Flameeyes' Pettenò wrote: On Friday 01 September 2006 15:36, Paul de Vrieze wrote: The build scripts are part of the source code. And as such must be licensed under the GPL. It's opinable, as you don't mix them with the actual code. I think it's one of the gray points. Actually the GPL specifically states that build scripts are part of the source code explicitly. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpSGyeAsFqMt.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for September
On Friday 01 September 2006 15:53, Chris Gianelloni wrote: I have a proposal for an agenda item. I would like the council to decide on the removal of the requirement that everything must come as an agenda item so they can be allowed to make decisions in a timely manner, if necessary. Of course, with my proposal, the council can always decide themselves that something is not an emergency, and postpone decision, or even require that the item go for discussion before a decision is made, but the current agenda requirement blocks the ability for quick decisions. I would like to second this. I particularly find the notification 7 days before setting the agenda troublesome. It basically means that decisions can only be made half a month after the discussion has finished on -dev. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpJGxOLZBtue.pgp Description: PGP signature
Re: [gentoo-dev] Xmms needs to die.
On Thursday 24 August 2006 20:46, Alec Warner wrote: Robert Cernansky wrote: What bothers me also, is that it has not plugin design like xmms. Support for plugins is very good because lot of people can write plugins for lot of things. This is why people do not want to switch from xmms because thanks to plugins it have so many features that currently no player is able to overcome it. So port the plugins from xmms to $NEW_CLIENT, since xmms is an old piece of crap. Who cares. It works (mostly), it is lightweight, and there are enough people using it to keep it in the tree. As long as things don't break beyond repair I see no reason whatsoever to remove xmms (or any other largely unmaintained package in the tree). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpBsdir4vVPi.pgp Description: PGP signature
Re: [gentoo-dev] Democracy: No silver bullet
On Thursday 24 August 2006 02:17, Donnie Berkholz wrote: If I could go back in time a couple of years and prevent this democracy from ever happening, I would. If I could fix these problems myself, I would. But it requires buy-in from the entire Gentoo community if we're to do anything about it. I think you're right. I liked the way that gentoo was not a democracy. As it is now I think an indirect democracy is the way to go, where the council sets out the lines, makes decisions fast and before everything has been repeated over and over in the next huge flamefest. If one does not agree with the council, vote someone else the next year. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpmG5syi0nDV.pgp Description: PGP signature
Re: [gentoo-dev] Democracy: No silver bullet
On Thursday 24 August 2006 10:26, Wernfried Haas wrote: On Thu, Aug 24, 2006 at 12:54:23AM -0700, Donnie Berkholz wrote: The council doesn't actually do anything AFAICT, it just approves GLEP decisions that have already been made. So in effect we have no leadership. Suspending sunrise was a decision, as was unsuspending it. However i agree that currently their main role is approving GLEPs and other decisions which makes them official Gentoo decisions. If that's a good or bad thing (tm) depends on the POV, i mainly think it's good to have it like that and no leader whatsoever. A big issue, that I hope to correct is exactly this indeciciveness in the council. It is my position that the council needs to be proactive in decisions and in setting a goal for the distribution. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpXMmxIZe3Dq.pgp Description: PGP signature
Re: [gentoo-dev] Democracy: No silver bullet
On Friday 25 August 2006 21:41, Stuart Herbert wrote: Personally, I'm opposed to a return that that hierarchy. The idea that somehow desktop, server, and other such projects should sit at an exclusive top-table doesn't work for me. While I am partly responsible for setting it up I have to admit that not only did it not work then, it has never really worked. Worst of all was that most of the work being done was not part of any project at all. Attempts like desktop-research to develop some extra strengths for gentoo failed utterly. It opened my eyes that indeed an open source community distribution is not an organisation in the traditional sense. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpc3EzIIn3kS.pgp Description: PGP signature
Re: [gentoo-dev] Democracy: No silver bullet
On Thursday 24 August 2006 16:58, Lance Albertson wrote: True, that might work, but then you run the risk of losing cohesion of what everyone knows. To me, the same person(s) should be at all those meetings if possible. Its better to have one or two people who know whats going on with all council-related stuff than one here, one there. It can become disjointed rather easily. This actually comes down to a very real problem. It is almost impossible. Leading gentoo would be more than a full time job. As gentoo can not pay that (and it also burned Daniel down, as it is very lonely) this is not easy to achieve. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgplWnkKfBDKa.pgp Description: PGP signature
Re: [gentoo-dev] [treecleaner] Last rites: media-sound/alsaplayer
On Monday 21 August 2006 14:59, Abhay Kedia wrote: I use alsaplayer to play KDE sounds as it works well with dmix and I can keep aRts disabled. All KDE sounds are ogg files and when I play them with mpg321, it just exits without producing any sound. I guess the only thing left for me to use is mplayer? Use the aplay binary provided by alsa-utils. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpAwtHYbRzzH.pgp Description: PGP signature
Re: [gentoo-dev] If I may interject...
On Thursday 17 August 2006 03:01, Mike Lundy wrote: I told a friend that there were some in the community who called proprietary software slaveryware. His response? Holy shit! If that term spreads, we can forget about convincing otherwise logical people that free software is the Right Way. There are two problems with it: I can't help to respond here. 1) It's incorrect. There is nothing at this point in time that causes you to be enslaved by proprietary software. There are stories of speculative fiction, such as Right to Read and other, better written stories; those stories are just that- fiction. Microsoft does not beat you or chain you to their operating system. Sun does not whip you to use java. Members of the wider computer community may, through their own adoption, but Sun has nothing to do with it. You must convince members of your community to stay away from proprietary software. This leads me to the second error. Actually, it is more subtle. Microsoft does not force you to use windows. One uses windows because of office. One uses microsoft office not because of microsoft, but because *the whole world* uses microsoft office. It is called network effects and is the cause of the microsoft monopoly. The slavery part is that we are basically at the mercy of the owner of the monopoly. (You know the main competitor of windows XP? It's the earlier releases, same goes for office) 2) It's intentionally offensive. The end goal of the free software movement, as I understand it, is to convince everyone that freedom in software is something to strive for. Some people do not immediately see the light of this, and must be convinced through logical means. Convincing people to see the benefits of free software is difficult enough. Stealing a cliche- can you imagine explaining to your mother about slaveryware? If you use that term, you then have to convince people that that term is accurate. The discussion will be about the slaveryware /word/ instead of the free software /idea/. That is counterproductive, and will likely cause you to be dismissed as a extremist (though, hopefully not by your mother). Intentionally offending the very people we need to convince does not help us at all. While it is accurate, I agree with you that it is indeed offensive. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpDLU0KKVyj5.pgp Description: PGP signature
Re: [gentoo-dev] Re: User support system [WAS: Sunrise contemplations]
On Thursday 17 August 2006 16:37, Enrico Weigelt wrote: * Duncan [EMAIL PROTECTED] schrieb: snip You ever seen the term slaveryware? You have now. We are still talking about the java *language* ? I aggree that we shouldn't be bound to some certain proprietary software. But the java language is not software, it is couple of abstract concept for actually writing software. You forget the main part of a language is the library. Basically there is not yet a good complete open java standard library available. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpxqRdJf2FVe.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Masking practics
On Tuesday 08 August 2006 22:36, Enrico Weigelt wrote: As an end user and also an administrator, I am very pleased to see this laid out so clearly. I mean, I knew it, but it seems like it needs to be yelled once in a while... hmm, now that I know of these flags, I can take a look at them (although its not very comfortable having to look at those details). Yes, I could have read the whole docs to learn about this, but I never expected such things. IMHO many people may get into such pitfalls. You're probably one of the new users of the installer. I knew that we shouldn't do that. The whole point of gentoo having (a reputation of having) good documentation is because people need it. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpseQ8PrKYKO.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for advanced useflag-syntax
On Monday 07 August 2006 15:16, Enrico Weigelt wrote: * Luca Barbato [EMAIL PROTECTED] schrieb: snip For example: mplayer It has it's gui-less player and an gtk-based frontend in one package. We should split this into two packages: mplayer and gmplayer. The chances to get this done in the upstream *before* some major distro like gentoo does the split by its own are quite low. We do not split packages for frivolous reasons. Well, I don't consider reducing complexity frivolous ;-o Which reduction for which complexity? Do you want to bring everyone's systems to a grinding halt, just because you can't understand the complexity of useflags. Useflags are one of the distinguishing features of gentoo. Now you opt to do away with them. I do not see the reason. It is also against the gentoo philosophy of offering software the way upstream provides it. snip Some people @mplayerhq are quite aeh, unfortunate, about changes in the build procedure. Maybe you like to have a look at the discussion about my patches introducing pkg-config utilization. pkg-config is a broken concept. Libraries themselves should state dependency information. Pkg-config is a solution that introduces at least as many problems as it solves. Only libtool (esp. old versions) is worse in it's incomplete use of the linker and the way it encourages broken library linking. That's the right ways. And so gmplayer stuff should be dropped completely. If you like, I'll sit down and fix the ebuilds. First fix your attitude problem, then come with good suggestions stated in a more friendly way. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp3sJxZmsRPa.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for advanced useflag-syntax
On Monday 07 August 2006 22:09, Marius Mauch wrote: *sigh*, if you want to use a source based Debian (as the combination of all your posts seems to indicate) then do so, stop trying to convert Gentoo into that. Or create your own private fork. I start to get *really* annoyed by your overall behavior in the last weeks, and I can tell you that takes quite a bit of effort. Really, re-evaluate your motivation for being on this list. Marius I second this as should be clear from my earlier rant. Enrico should stop barking about how everything in gentoo is broken without having actually been active and built up a reputation. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpsZB8sBqVs8.pgp Description: PGP signature
Re: [gentoo-dev] Proposal for advanced useflag-syntax
On Monday 07 August 2006 16:18, Enrico Weigelt wrote: I just want to keep things simple. We're talking about introducing new (additional) logic. This has to be maintained. And it doesn't actually *solve* the problem which is this discussion was started. Removing the stuff from the ebuild and maintaining two ebuilds that must be synchronized with eachother is complex. Rember: we started with the thesis, grandma wants graphical frontends whereever possible. This is in fact not an technical issue, instead a matter of personal taste, or lets say, an individual system configuration. Grandma wants to click, okay, so she should use graphical applications. She's not interested what sits behind, she just wants to have a buch of applications. And she also doesn't wann have anything to do with emerge and useflags. She just wants to have a choice between a bunch of end-user applications. That's the job of an Grandma-(sub-)distro. gentoo is not a grandma distro and does not try to be so. Okay, let's say we want to intruduce an meta-useflag for GUI (although having additional GUIs in the same package as the backend isn't what I consider clean design). If there's just *one* than it's easy - just an alias. But what's if we have more ? Who makes the decision, which one to take ? Based on what rules ? The council makes the decisions. Yes. For optional features. Additional programs aren't features of some other program, but additional programs. You should read up on your history. Useflags are as well for additional programs as for features. This is especially true when things should be kept together as they are tightly coupled. Ah, and this philosophy is more important than quality and maintainability ? You fail to see that what we do has quality and is certainly maintainable. pkg-config is a broken concept. Ah ? I consider it *very* clean. What could be easier than have an consistent database which *knows* what's installed on the system instead of having to run lots of esoteric tests which shall *guess* it somehow ?! The tests don't actually guess. The main problem though is that pkg-config encourages wrong linking. Linking should happen properly such that libraries link in their own dependencies, so that library users don't have to. If necessary, this database query can be intercepted easily. With the esoteric testing its very complicated or at least work intensive. There is nothing esoteric about checking for the existence of libfoo. Well, how would you get certain search pathes (-I, -L, ...) additional includes, dependency info for evrything but elf-so, ie .a ? The thing is you don't should not link the dependent libs of a dependency. That way you don't need to recompile if (say gtk was compiled with a new libpng version) Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp5RxbtO9jVz.pgp Description: PGP signature
Re: [gentoo-dev] Make FEATURES=test the default
On Saturday 05 August 2006 11:05, Kevin F. Quinn wrote: On Fri, 04 Aug 2006 20:18:40 -0400 Alec Warner [EMAIL PROTECTED] wrote: Give me some numbers on how many things still fail with that enabled because I would be concerned if the number is too high. I don't have numbers, but if you have FEATURES=test set yourself you should know how many fail. It's not insignificant. Part of the problem is that many test suites themselves are broken. Or broken on some architectures. Other times the tests fail because of broken dependencies. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp9EcZ6Havhp.pgp Description: PGP signature
Re: [gentoo-dev] Make FEATURES=test the default
On Saturday 05 August 2006 18:07, Tim Yamin wrote: Agreed. It may be better to instead have a FORCE=test on certain ebuilds (mainly sci-* stuff where you want to be sure the numbers are coming out correctly) -- adding FEATURES=test to the default set will cause serious breakage and will take quite some time to be fully fixed across the whole tree. Comming to it. Packages that I maintain such as sys-libs/db and subversion have test suites that only run correctly when all kinds of bindings are compiled. They do not work in most useflag configurations because they unconditionally test the bindings. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpdZdw3ru1yg.pgp Description: PGP signature
Re: [gentoo-dev] Resignation
On Monday 31 July 2006 14:53, Bryan Ãstergaard wrote: On Mon, Jul 31, 2006 at 01:01:20PM +0200, Christian Andreetta wrote: Many users (and I'm both a dev *and* a user) just could do much for Gentoo, but when you're interested in a niche sector package, you *don't have other choices* but 1) an endless wait for an open bug 2) becoming dev for the good of all :-) 3) just use your personal overlay, without sharing the results of your efforts. If the bug in 1) is still open, why updating it with your latest patches/revision bumps? 4) Bash devs to add your ebuild Which one exactly. The point is that it is not on a dev's turf. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgplHPp1Cr8hj.pgp Description: PGP signature
Re: [gentoo-dev] Re: Resignation
On Monday 31 July 2006 10:21, Ciaran McCreesh wrote: On Mon, 31 Jul 2006 10:10:45 +0200 Simon Stelling [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | Good intentions and trying to be helpful don't keep users or | developers. Screwups lose users and developers. | | It's really funny to hear such a statement from a person who made | several great developers leave the project. No, what's funny is watching people do nothing when Sunrise really is making developers leave. Ciaran, The point is as valid now as it was 3 years ago. We accept that developers leave and don't care. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp005qMvHD7d.pgp Description: PGP signature
Re: [gentoo-dev] Re: webdav global use flag and default
On Friday 28 July 2006 15:40, Stefan Schweizer wrote: right you are. Putting the default useflag into base/make.defaults has the same effect as a nowebdav useflag without being a no* useflag and confusing with other useflags that do not have the no* bit. If there are no objections and you agree with the solution I will make webdav global and default after a week from now and you can remove the old nowebdav useflag. If there are any problems with putting it in base/ for example neon does not work on hardened, embedded or anything else I would like to know about it. Go ahead. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpuKE5PEkgS4.pgp Description: PGP signature
Re: [gentoo-dev] Re: webdav global use flag and default
On Friday 28 July 2006 23:02, Stefan Schweizer wrote: - leave everything as is: it does work but I do not particularly like the nowebdav useflag tho it is better than having subversion broken. A third option would be to wait for portage to support package level useflag defaults. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp8qZZiR5g58.pgp Description: PGP signature
Re: [gentoo-dev] Resignation (was: Project Sunrise resumed)
On Monday 31 July 2006 04:28, Dan Meltzer wrote: I do not see why it is considdered hard for users to get involved. Users have at least two choices that I can think of right now, and probably a number that I cannot think of. 1) Users can submit patches/ideas to bugs.g.o at whatever frequency they desire, contributing to gentoo casually. And the patch hanging in bugzilla forever because no-one wants to maintain it. Sunrise could help here, by accepting properly written ebuilds that do however not get maintenance. Sunrise should not really be about replacing current ebuilds, but offering some support for those packages that are useful for some, but that do not have enough usage that a developer wants to put it into the tree. 2) Users can take the quizzes and become a developer, I do not see why two quizzes is considdered an insurmountable task, the quizzes are specifically designed to ensure that people writing ebuilds understand what ebuilds can contain and what they cannot, I could not imagine a user wanting to install a package from an ebuild written by someone that does not know this. They first need to be invited to start the whole process. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpTSDLQV40v3.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise resumed again (was Resignation)
On Monday 31 July 2006 08:47, Ciaran McCreesh wrote: Knowing what the problem is is part of making the solution. The problem is not that users can't push arbitrary content into a centralised official repository with no oversight from the herds appropriate for said content quickly enough. I didn't claim to know exactly what the real problem is, merely that it's not what's being solved here. Herds do not have turfs. They specialise in particular areas but that doesn't mean that all packages in that area have to fall under the herd. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpjmmuU20zMl.pgp Description: PGP signature
Re: [gentoo-dev] proxy-dev (an alternative to sunrise?)
On Friday 28 July 2006 20:51, Donnie Berkholz wrote: Robert Cernansky wrote: If I have some application that is not included in portage why I decide to make an ebuild? Because I hope that then it will be accepted and included to portage, so maintained by developers (big thanks for this). If I have to take care of package + ebuild + dependencies, I'll rather choose not to make an ebulid but compile package right from .tar.gz archive. Many people disagree with you here, that's why overlays exist. Somebody wants to use Portage to manage ebuilds that aren't yet in the actual tree. I'm one of those. Portage namely is also a package manager allowing what using the tarbal method does not: file tracking and deinstallation. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpr68D6w9f3V.pgp Description: PGP signature
Re: [gentoo-dev] webdav global use flag and default
On Friday 28 July 2006 10:18, Stefan Schweizer wrote: Hi we currently have both webdav and nowebdav ueflags, this is confusing: # grep webdav /usr/portage/profiles/use.local.desc dev-util/git:webdav - Adds support for push'ing to HTTP repositories via DAV dev-util/subversion:nowebdav - Disables WebDAV support via neon library net-misc/sitecopy:webdav - Enable WebDav (Web-based Distributed Authoring and Versioning) support. This system allows users to collaborate on websites using a web based interface. See the ebuild for an FAQ page. Enables neon as well to handle webdav support. www-apps/open-xchange:webdav - Enable WebDav (Web-based Distributed Authoring and Versioning) support. www-servers/lighttpd:webdav - Enables webdev properties The proposed solution is to make webdav a global useflag and set it as a default use flag to have the same effect as the current nowebdav use flag in subversion. I'd like to explain why subversion has a nowebdav useflag. Basically one of the features of subversion is its ability to work over the http protocol. Many subversion installations use the apache module to serve subversion (even our own overlay project does). To disable webdav support would cripple the subversion client. It is something one should only do when aware of the consequences. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgplBDFU7dRLt.pgp Description: PGP signature
Re: [gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
On Monday 10 July 2006 01:51, Ryan Hill wrote: No, that would be a major pain in the ass for anyone wanting to use -fast-math, which does have legitimate uses. I want to pose here that -ffast-math has NO LEGITIMATE use as a global CFLAG. In some apps it doesn't matter as they don't use math. For others it is fatal. If users want to use it on a particular app, they better use /etc/portage/bashrc. 2) If yes, are there any other flags that ebuilds should die on ? There's a million, and they're constantly changing. For example, -frename-registers is generally safe on GCC 3.4, broken in 4.0, and enabled by default on 4.1. The flags that would apply are those that break apps because their use is broken. Not because the particular compiler is broken in this instance. Users playing with CFLAGS get to keep the pieces. Trying to dummy-proof the system doesn't help anyone but the dummies. ;) I don't mind that much not doing anything with -ffast-math, but filtering it out should not be done. It is a broken flag. Filtering it out gives the message that it isn't unsafe to use. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpjjfx3jbrN6.pgp Description: PGP signature
Re: [gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
On Tuesday 11 July 2006 04:32, Ryan Hill wrote: If yes, why ? And what is your better idea ? I prefer a filter-flags with a ewarn (or elog, haven't read that thread yet ;)) message. * The -ffast-math option is known to break this package and has been filtered from your CFLAGS. Link to Safe CFLAGS wiki page, blah blah blah. I like this better because it informs me of what I did wrong, what was done to correct it, and how I can correct it for myself in the future if I choose to. I don't like artificial barriers and things not working without immediate attention. Call me lazy but it's annoying when you know what you're doing yet you have to jump through hoops to get it done. The die would use the same message. Next, it would actually stop immediately instead of letting you continue further and break in the long run. Using -ffast-math globally is just broken. In some packages it may work. In others it doesn't. My argument is that we must not filter -ffast-math or any other dangerous cflags. The reason being that people will request more filters for all packages that don't work with it. Many users will either ignore or miss the warning messages. Filtering the flag basically tells them that even though the message says it is dangerous, their use of the flag is still more or less supported, while it is not. Okay, bad joke aside, there are always going to be users who tweak GCC flags. This has to be expected, as they're mysterious, and technical, and kinda cool. I like the tweaker crowd and I am a dummy, so no offense was intended to either groups. I meant that if you safety-proof a complex system, people never learn that they're doing anything wrong in the first place. Exactly, filtering the flags is safety-proofing. So just die, or not filter at all. Right, but how are people supposed to learn something is dangerous if all the sharp edges have been filed off? And how can you decide which flags are bad and good on a global level when for the most part compiler parameters are akin to black magic? In this case the compiler documentation itself says it is dangerous. That should be enough. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpZInD51vioS.pgp Description: PGP signature
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Thursday 13 July 2006 18:53, Ciaran McCreesh wrote: On Thu, 13 Jul 2006 14:55:57 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: | The dev manual is *wrong*. No, the devmanual reflects what's actually being done, rather than an impractical definition that was written years ago that no longer matches the development model. Then file a bug against the given definition. This only adds to the confusion. As I remember however there have been discussions on this topic and they never came to any conclusion. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpbrgQXmxFw6.pgp Description: PGP signature
Re: [gentoo-dev] Herds suck, fix them
On Thursday 15 June 2006 20:17, Marcus D. Hanwell wrote: I have to agree that I have never understood the need for the distinction between herd and team. It does not seem to add anything, I guess some people do not like being referred to as a herd may be? It really doesn't bother me. I think of a herd as a collection of developers working on a set of packages kept under the same umbrella due to them being related in some way. Basically a team may manage multiple herds, but still separte them because of organizing reasons. At the days, the kde team herded three herds: QT, kde-core, and kde-others. This allowed for example kde-others (random kde apps) to receive different attention than core kde applications. If people really do feel the need to distinguish these things then fine - document it. Otherwise I will continue operating the way I do. I don't see why it matters so much... I agree that in most cases team=herd and there is not formal project and it really doesn't matter if you say that a herd maintains something when it's the herd's maintainers that do so. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpsbU2gYwd9O.pgp Description: PGP signature
