[gentoo-dev] packages linked against the kernel sources
After a kernel update, sys-kernel/module-rebuild can be used to rebuild the installed external kernel modules. Software like dev-libs/klibc or app-cdr/cdrtools are linked against the kernel sources and not against the kernel headers. Is it other programs like them in the tree? I am not a gentoo programmer but I want to have a list of those programs, or to make this list if nobody can provide one. So please, if you maintain such a program that is linked against the kernel sources and not against the kernel headers, respond to this mail. Best, Dominique -- Dominique Michel Mes 3 projets préférés auxquels je contribue: * FVWM-Crystal, le bureau basé sur FVWM: http://fvwm-crystal.org * AlsaPlayer, le lecteur audio avec contrôle de vitesse en continu: www.alsaplayer.org * L'overlay pour la MAO sous gentoo: http://proaudio.tuxfamily.org/wiki/index.php?title=Main_Page -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: [treecleaner] Last rites: media-sound/alsaplayer
BTW, alsaplayer is in the proaudio overlay now. http://proaudio.tuxfamily.org/wiki/index.php?title=Main_Page It is 2 versions, a -r5 with the last Debian fixes, and a broken gtk2 cvs version. Dominique On Tue, 22 Aug 2006 15:26:56 + (UTC) "Duncan" <[EMAIL PROTECTED]> wrote: > Abhay Kedia <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Tue, 22 Aug > 2006 14:53:38 +0530: > > > On Monday 21 August 2006 19:53, Olivier Crête wrote: > >> > >> You can use ogg123 > >> > > Some of the files are wav files as well, so I can't play them using > > ogg123 and KDE doesn't allow use to use multiple alternate players for > > playing its files. > > FWIW, I've dealt with the problem as well (altho I have arts, its age is > showing and it gets broken with some versions of KDE), so I know the > frustration. An idea I haven't tried but which popped into my head as I > was reading your post... what about creating a simple shell script that > looks at the file it's handed and determines whether to call ogg123 or > mpg321 or whatever, based on extension or what "file" thinks it is? > > Fortunately arts and the built-in events player are working for me ATM, > but I may try this next time something breaks. > > ... Looking forward to KDE4 and getting rid of arts! > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Democracy: No silver bullet
I am new in this list and waiting at my mentor come back from vacations. It is often the problem with democracy. Every one will have its word said, even if he or she know nothing about the issue. What I think is at the only mean to deal with this problem and still be democratic, is to organize the democracy. For a subject that concern a herd, only those in the herd can vote. After voting, they send the result up in the hierarchy. The hierarchy accept it as it or do some remarks, and the process in the herd can continue, or take in account the proposition from the hierarchy with a new discussion-vote process if needed. For a general subject, the votes must be done in the herds, and when all herbs are done with the vote, some herds representatives can discuss the issue to take a decision. The result can be at a new discussion-vote process is needed in the herds, or at it can go up. After, when it go up, it is the same as with one herd only subjects, it goes up in the hierarchy and down again. In all cases, I think at an absolute majority is needed at all level. If it is a proposition with 3 or more possible choices, but at only one can be chooses, it is imperative at, in all level, it is at least 50% of the votes for the chooses one. By that way, herds will come with strong proposition and it is an insurance at they must stay in focus in case of disagreement. I think at a such democratic structure have many advantages. This list can stay on focus with development issues. The herds can focus on what they have to do at the first place. The discussion can stay on focus because it is easier to discuss in a little structure as in a big one. The democracy is preserved. All levels can say their words. The head will still be in control, and that control will be democratic. I know at no one politician will accept such a process, but we are not doing politics. And it is just what I think. Dominique On Wed, 23 Aug 2006 17:17:17 -0700 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > I just posted this to my blog [1], but I know you don't all read it so I > wanted to post it here as well. Do read all the way through. I very > rarely write anything this long, and when I do, it's something I feel > very strongly about. > > I started my fourth year as a Gentoo developer in June, and Gentoo's > changed a lot since I started back in 2003. We've become a drastically > more democratic organization. But the question remains ___ _Is this a good > thing?_ > > When I think about where Gentoo was when we turned into a democracy > years ago, and where Gentoo is now, I don't see much of a difference on > the large scale. We lack any global vision for where Gentoo is going, we > can't agree on who our audience is, and everyone's just working on > pretty much whatever they feel like. > > When I joined, Daniel Robbins was in charge, period. Seemant Kulleen and > Jon Portnoy were basically his lieutenants. What Daniel said was what > happened, and woe to anyone who angered him. This generally worked out > pretty well, but _as Gentoo grew, it didn't scale_. Everything > significant still had to go through Daniel for personal approval. > > Shortly after I finished training and became an "official" developer, > Gentoo gained its first real structure via Gentoo Linux Enhancement > Proposal (GLEP) 4 ___ "Gentoo top-level management structure proposal". > The GLEP process itself was quite new then; GLEP 4 was really only the > second proposed GLEP (the first two were details related to the GLEP > process) and the first one that was accepted. _Its goal was to improve > communication and coordination as well as increase accountability_. > > GLEP 4 formalized a hierarchy of so-called "top-level" projects ___ > between 5 and 10 major areas into which everything in Gentoo could be > divided. Daniel appointed the original project managers, who served > under him. > > Democratic elections entered Gentoo when we realized that we needed to > create a new top-level project for all the desktop work, because it > didn't fit into any existing project. Since managers already voted > amongst themselves on GLEPs, it seemed like a natural extension for them > to vote on a new manager. The call for nominations is archived online. > I'd been a developer for around six months at this point, and by then I > was the lead X maintainer. Brandon Hale was active in maintaining window > managers and other miscellaneous applets and such. Turns out that the > vote tied, so we became co-managers. > > I didn't realize it at the time, but that was the beginning of a very > slippery slope. > > Gentoo used to be a courteous, friendly development community where > nobody was afraid to speak his mind for fear of insult and injury. I see > a clear correlation between the growth in democracy and the departure of > courtesy. Once people are empowered to vote on every decision, rather > than just having their discussion taken as input in a decision,
Re: [gentoo-dev] Xmms needs to die.
On Thu, 24 Aug 2006 09:12:48 -0400 "Stephen P. Becker" <[EMAIL PROTECTED]> wrote: > Luca Barbato wrote: > > Luis Medinas wrote: > > > >> If noone takes it will be saved on overlays.gentoo.org. Everyone needs > >> to know that xmms is old and tired (obsolete). A few developers on > >> redhat, mandriva and suse marked xmms as obsolete. Now it's our turn to > >> move it to our darkness repository. If you want to be sure it's obsolete > >> just read xmms's website. > >> > > > > fine for me > > > > (please add xmms2) > > > > People could just use mplayer o xine to play any audio sample aud doesn't. > > > > lu > > > > Note that neither mplayer or xine work on mips particularly well. Xine > is especially screwed. And if anybody mentions gstreamer, it flat out > doesn't work at all. > > -Steve It is aqualung that is a very good player with nice features such as oss, alsa, jack and LADSPA support. It have a database support to help to organise yours audio files. http://aqualung.sourceforge.net/ But I don't know if it will work on any architecture. It is still a beta software, but I know users very happy with it. And the development seam to be very fast and active. Dominique -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
Le Sat, 30 Sep 2006 22:35:58 +0200, Lionel Bouton <[EMAIL PROTECTED]> a écrit : > Hi, I just had an unpleasant experience with -ffast-math and GCC 4.1.1 > (it borked my LDAP authentication on several systems which worked with > the same CFLAGS as long as GCC 3.4.6 was used). > > There is a lot of material out there about CFLAGS and Gentoo (google > returns 387000 pages) but what's working for someone might not for > another. There are flags that work for a GCC version and most ebuilds > and don't work with another GCC version (my unfortunate experience) or > some ebuilds. Flag combination/architecture/LDFLAGS might be an issue too. > > There are already good resources (http://gentoo-wiki.com/CFLAGS_matrix > was mentioned to me by robbat2) but they may not be advertised enough. > I'd like to propose a paragraph to the GWN editor which presents some > gotchas and good references on the subject. > > Here's a draft for review. You're welcomed to expand on the subject. > > --- Draft BEGIN --- > > CFLAGS > > > > Being able to tune the CFLAGS is part of one of the core principles of > Gentoo: let the user be in control. Being in control brings both > benefits and problems and CFLAGS tuning is not an exception. > > > The recent upgrade to gcc-4.1.1 for x86 and amd64 users changed the > landscape. Users that spent some time tuning their CFLAGS with gcc-3.4.6 > might find out that an upgrade to gcc-4.1.1 leaves them with an unstable > system. Example of this are : > > nss_ldap stopped working with -ffast-math > ... > > > > Users with unsupported CFLAGS (see the link='http://gentoo-wiki.com/CFLAGS_matrix'>CFLAGS matrix for > example) might want to return to safe CFLAGS (see link='http://gentoo-wiki.com/Safe_Cflags'>Safe CFLAGS) if recent > updates caused them stability problems. On the other hand, more > adventurous users might want to experiment with CFLAGS that didn't work > properly with gcc-3.4.6... As always, the user is in control. > > > > --- Draft END --- > > If possible, I'd like to expand the list of 3.4.6 -> 4.1.1 upgrade > problems which are linked to experimental CFLAGS. If you want to expand > the subject to cover other tuning/stability gotchas that recent updates > might have brought into the light, please feel free to do so. As English > is not my native tongue, feel free to spell check too. > > Cheers, > > Lionel. My personal experience with other CFLAGS as the ones in the handbook is at gcc-4.1.1 have a better optimisation with the default gentoo CFLAGS. Even with -O2, the result is a faster system, and -O3 seam to be safer with math related applications as with gcc-3.4.*. But in the other hand, other flags seam to be more problematic as with gcc-3.4.*. And the new optimisations flags as the vectorisation flags are not easy to use, because the result depend on the code of the program. They can or not brake the code, and when the program run well, they can make it faster or slower. All depend of the size and complexity of the loops. And I think also of the arch. So my conclusion is: For system flags, just keep the default, and if you want to experiment, do profiling for each single program you want to optimize. Cheers, Dominique -- Dominique Michel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Missing: Universal-CD - Gentoo discriminates shell and networkless users
Le Fri, 06 Oct 2006 10:06:41 -0400, Chris Gianelloni <[EMAIL PROTECTED]> a écrit : > On Fri, 2006-10-06 at 09:39 +0200, Paul de Vrieze wrote: > > 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. > > OK. I *said* that I was writing a document on this, but people seem to > just want to keep on postulating and talking about complete > inaccuracies. > > Yes, you can install using portions of the installer from the command > line (not ncurses). Unfortunately, one component necessary for a > complete install from the command line (installing a kernel) was not > added until after 2006.1 shipped, so you cannot do a completely > networkless install with only the LiveCD/LiveDVD. I will just say at this have to be fixed. From the website: "The Gentoo 2006.1 Handbook is an effort to centralize documentation into a coherent handbook. It contains the networkless installation instructions for the 2006.1 release " http://www.gentoo.org/doc/en/index.xml?catid=install#doc_chap2 >From this handbook: "This document covers the installation using a Gentoo Linux Installation CD, a bootable CD that contains everything you need to get Gentoo Linux up and running." http://www.gentoo.org/doc/en/handbook/2006.1/handbook-x86.xml?part=1&chap=1 When an user or a potential user read it and want to do a networkless install, it will just use the Live CD install, and just get in trouble. It is even worse when many Linux magazines will have this CD. And you cannot argue at it is just to use catalyst or to burn a CD from a stage 3, when the doc say "a bootable CD that contains everything you need to get Gentoo Linux up and running." > > > At this point though I think using the installer is reasonable enough. > > I would agree there. > I agree too, but only if it work, and it doesn't completely work for a networless installation. -- Dominique Michel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] new herd suggestion: religion
Le Fri, 2 Feb 2007 06:54:51 -0800, Drake Wyrm <[EMAIL PROTECTED]> a écrit : > Steve Dibb <[EMAIL PROTECTED]> wrote: > > I'd like to propose a new herd: religion. The herd would take care of > > the Bible and religious software along with any genealogy programs in > > the tree, > > Genealogy is a religion? > > How about calling the herd "philosophy" or some such? That would better > include genealogy, would still include any religion-oriented packages, > and might also be appropriate to some other packages. > genealogy have nothing to do with philosophy or religion. I can use a science, genealogy, in order to find who was my ancestors. But it will tell me nothing about their philosophy and religious beliefs. Religion is not about science but about beliefs (some peoples are even saying ideology). Philosophy is also a science. Look at an example. Christian peoples are believing at Maria, the mother of Jesus, was a virgin, and at even Joseph, the father, was not aware of it. They said at it is a mystery, and at the same time, they are trying to explain it. What say philosophy about it? A mystery is by definition something that no one can explain. So it can be only 2 scientific explanations: 1) It is a mystery and they are wrong to try to explain it. 2) They explain it and they are wrong to try to tell at it is a mystery. So, genealogy as philosophy must go in the herd science. As religion is not a science but a belief, it cannot go here. Maybe a herd belief? -- Dominique Michel -- N.B.: Tous les emails que je reçois sont filtrés par spamassassin avant de me parvenir. Si vous attendez une réponse de ma part et que vous ne la recevez pas, cela signifie qu'en toute vraisemblance, votre courrier ne m'est pas parvenu car vous figurez sur une des listes de http://www.spamhaus.org. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Why I don't think the CoC is a good idea
Le Thu, 15 Mar 2007 00:06:28 +0100, Alexandre Buisse <[EMAIL PROTECTED]> a écrit : > Hi all, > > I've been voicing my concern repeatedly on irc, and I believe that it > would probably be more effective here. > > I believe that the solution of adopting a Code of Conduct, especially in > this rushed way, will ultimately hurt us, and that the disadvantages far > outweight the benefits. > > one is right or wrong. As has been repeatedly pointed in many occasions, > the written media and the differences of languages and cultures make it > very difficult to understand the tone of messages and can generate very > different reactions. As user, I can confirm this. I was living a few years in another country as mine, and cultural differences are a reality of our world. It can be 100% normal to say something in one country when in a neighbour country, the same sentence will be taken as an affront. So, be cool. And maybe more important, respect each other. Respect is the only cure against all kind of racism. We are not living i a perfect world and so are we: unperfect. As said a Canadian poet: "Human beings have a problem: they don't like each other, but they don't like solitude either." So, if you feel at someone is showing some kind of disrespect, just ignore him or her. Otherwise, Georges idea to redirect the flame wars to another list sound very good. Ciao, Dominique -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New ALSA maintainers
Le Wed, 28 Mar 2007 11:22:22 +0200, "Ioannis Aslanidis" <[EMAIL PROTECTED]> a écrit : > On 3/28/07, Jakub Moc <[EMAIL PROTECTED]> wrote: > > Josh Saddler napsal(a): > > > I completely disagree with your assessment of the in-kernel hda-intel > > > state. My workstation uses one of those (labelled nVidia MCP 55, for the > > > curious), and my experiences with in-kernel ALSA have been nothing but > > > positive with the intel audio, whether compiled or as modules. > > > > I could say the same about your assessment of the in-kernel hda-intel > > drivers, as could many other users... Same for via82xx - never had much > > luck with the in-kernel drivers, plus upgrading the whole kernel over > > and over again just to test whether something got fixed is a major PITA. > > > > As said, these are two different branches, what works for somebody > > doesn't need to work for someone else. > > > > I'm afraid I experiment the same issues. For my hda-intel, in-kernel > drivers do not work, at least for now. > > Maybe we could find a way to integrate (see replace) the in-kernel > alsa version with the portage one. > All the new features are incorporated first in the alsa-driver. It implies at it will make no difference for peoples using old hardwares. But for peoples using new hardwares, or wanting to have new features such as volume control in dB with some hardwares, they have no other choice as to use the alsa-driver package. Also bug fixes come first in alsa-driver from Alsa, and only later in the in-kernel driver. As I see it, It is necessary to support the in-kernel driver as it come with every kernel, but it is also necessary to support alsa-driver because some users not only want it, but they need it to get alsa to work well with their hardware. And I don't think at replacing the in-kernel driver by the alsa-driver will implies less work. It will be more work for the maintainers of the kernel's ebuilds. It is also much simpler to upgrade the alsa-* packages to get a new alsa version as to upgrade the whole kernel. Ciao, Dominique -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: new herd: theology
Le Fri, 27 Apr 2007 12:59:25 +0200, Alexandre Buisse <[EMAIL PROTECTED]> a écrit : > On Fri, Apr 27, 2007 at 11:25:01 +0200, Duncan wrote: > > > It's a very good question, it was posed at the time, it was never > > > answered and at last we can now say it was almost completely ignored. > > > > I (and I expect others who know) didn't answer this before, as it would > > have been too easy to start an OT subthread I didn't want to start, but I > > trust everyone minding the CoC will prevent that from occurring now. > > > > Briefly (and intended to be neutrally), the Latter Day Saints, commonly > > known as the Mormons (maybe other groups as well??), have a religious > > interest in genealogy, so having it in the religion/theology herd would > > make sense to them. That should answer the question, and give a place to > > start for those interested in looking it up. > > And a sect from the remote regions of Lapland believes that haskell is > a godsend and adore the ghc source code as their Holy Scripture, should > we move the haskell herd to theology as well? > > > > However, I agree the sciences or a general humanities herd will make more > > sense to most folks. I don't feel strongly enough about it to be worth > > arguing a maintainer's choice of herd for their packages, however. After > > all, they're the ones taking responsibility for it in the tree, > > regardless of the herd it's in, and if it's more convenient for them in a > > theology herd, why should it be a problem for those not interested in the > > package? It might raise a few eyebrows here or there, but if it's being > > well maintained, there are more critical things to argue about. > > Sure, there are more critical things out there, but why should people, > on such a critical subject, chose to label packages that have nothing to > do with religion with a "theology" stamp? I fully agree, theology is the worst possible name if the herd will include both religious and scientific softwares. Human beings have the unique possibility to use their critical mind (at least if they understand at we have this unique feature in the creation), and all the theology are based on the assumption at they are true only if we give away our critical mind (Introduction of all the religious book, they said at it is true because it is true...). And they cannot be true otherwise. Religion: the prophet prove the religion and the religion prove the prophet. Science: the theory is true only if it is proved by practical and reproductible experimentation. Words have a meaning. The fact is at genealogy is a science as it is possible to prove it by practical experimentation, and it doesn't matter if the father is a Mormon or the currier, an ADN prove will tell us. And for that it have nothing to do with religious ideology. Theology is about religious study and cannot be proved by practical and reproductible experimentation. For that, it have nothing to do with science. Otherwise: I think at it is a good idea to have that kind of softwares, but I also think at the name of the herd is one of the worst the worst possible. Please, don't call it with a name that is a direct reference to religious ideology if you want to mix those different kind of softwares. I think at at the best solution will be to make 2 herds, one for the religious ideology, one for human-sciences, so at we can know what we are talking about. It was my 2c. contribution on that matter. Ciao, Dominique > > /Alexandre -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: new herd: theology
Le Fri, 27 Apr 2007 20:07:26 -0700, Josh Saddler <[EMAIL PROTECTED]> a écrit : > Steve Dibb wrote: > > Dominique Michel wrote: > > > >> I fully agree, theology is the worst possible name if the herd will > >> include > >> both religious and scientific softwares. > > > > No worries, app-misc/gramps was dropped from the theology herd, and is > > herdless once again. > > So what's the big problem > of sticking it into a herd somewhere, a herd that seems to be maintained > by just one person (beandog in this case)? > > The fact at the herd is maintained by one or more peoples have nothing to do with this. It is about the meaning of the words and consistency. If I put gramps into theology, I can put gnome into kde, mplayer into media-sound and grabcartoons into theology. Otherwise, sci-misc will be a better place for gramps (that seam to be as least as good as some equivalent commercial softwares) as app-misc. Dominique -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: new herd: theology
Le Sat, 28 Apr 2007 13:16:27 + (UTC), Duncan <[EMAIL PROTECTED]> a écrit : > Thomas Rösner <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Sat, 28 Apr 2007 > 14:39:43 +0200: > > > Indeed. That's why while I don't personally agree with the idea of > genealogy in theology, I think it goes in sci-*, I also don't believe > it's a big deal in terms of herd placement. Herd placement is primarily > of "internal Gentoo interest", that is, to Gentoo devs/ATs/etc, not even > most users except for filing bugs and if it's automated there... . > I disagree. When searching for a software to do a given job and when I have no idea of which software can do it, I begin to look for the ebuild descriptions in the portage tree. It goes faster as anything else with mc. And I will never search a genealogy program in theology, so I will just miss it if it is in theology. That said, I agree at it is not a big deal in term of herd placement from a developer point of vue, but it is one, as I already said, in term of consistency and meanings. English is not my first language, and if the portage tree don't have a good consistency regarding to the meaning of the used terms, I vote to replace those terms by numbers. So it will be no consistency problem because it will be no consistency at all. I am joking, the name of the herds are fine. And I prefer to have such a naming policy as something as a/aa/* as on sourceforge. Ciao, Dominique -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: new herd: theology
Le Sat, 28 Apr 2007 22:27:47 + (UTC), Duncan <[EMAIL PROTECTED]> a écrit : > Dominique Michel <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Sat, 28 Apr 2007 > 18:32:50 +0200: > > > I disagree. When searching for a software to do a given job and when I > > have no idea of which software can do it, I begin to look for the ebuild > > descriptions in the portage tree. It goes faster as anything else with > > mc. And I will never search a genealogy program in theology, so I will > > just miss it if it is in theology. > > I think you are missing the distinction between category/package, as seen > in the tree and therefore affecting users and externally visible, and > herd, which many users likely aren't aware of at all, as it's primarily a > Gentoo-internal way for devs to organize packages of a similar theme they > may be interested in working on. > It is well possible as I am not a dev. (still) I will look at it. But it doesn't change at some devs expressed the same concern in this thread. Another fact remain: theology is about religion when genealogy is about sciences. Ciao, Dominique -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] new herd: theology
Le Sat, 28 Apr 2007 18:25:46 -0700, Josh Saddler <[EMAIL PROTECTED]> a écrit : > Nathan Smith wrote: > > On 4/28/07, Rémi Cardona <[EMAIL PROTECTED]> wrote: > >> Josh Sled wrote: > >> > >> > If that's the case, might not "humanities" be a better name? > >> > >> s/theology/humanities/ sounds good. +1 from me. > >> > >> Rémi > >> -- > >> [EMAIL PROTECTED] mailing list > >> > >> > > > > Indeed. Even if we wanted a herd specific to religion, "theology" is > > not the best choice since I've yet to conceive of how a program can do > > theology. Certain types of programs can inform one's theology > > (textual studies programs based on SWORD are a good example of this), > > but the same programs have various other uses. Humanities is a good > > enough description. > > > > It would only be called "humanities" if it was also trying to include > gramps (geneology) with the other 7 packages which are explicitly > religious in nature. As beandog has already said, gramps has been > removed from the herd. religion or theology is clearly the most > appropriate category of the remaining packages. There's no need to > rename the herd to "humanities" just because some folks are > uncomfortable with topics and packages relating to religion. > > Think about your local library (Dewey decimal system) -- you don't find > Bible study guides in the humanities/sociology (300s, 400s, 600s, 800s > and possibly 900s (history))...you find it in 100s and 200s. The > sections on "religion and philosophy". the remaining 7 packages are > clearly religious in nature. Don't try to label them anything else, just > because you ain't comfortable with it or don't like 'em. > I agree with you. And genealogy is somewhere in the sciences or human sciences section. Dominique -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Watch out for license changes to GPL-3.
Le Sun, 08 Jul 2007 09:06:09 -0400, Seemant Kulleen <[EMAIL PROTECTED]> a écrit : > On Sun, 2007-07-08 at 13:50 +0200, Wulf C. Krueger wrote: > > On Sunday, 08. July 2007 13:04:24 Marijn Schouten (hkBst) wrote: > > > What about moving Gentoo stuff to `GPLv3 or later'? > > > > I'm strongly opposed to the "or later" part for the simple reason that > > this implicates we will agree with stuff we don't even know yet. > > Hear hear. That's why we removed the "or later" rubbish from our > licenses about 4 years ago. > > > > I haven't studied GPL-3 fully yet so I haven't formed an opinion about > > moving to it alone. > > > I'm not certain what it buys us to move to v3, to be honest. Unless > there are compelling reasons to do so, I don't think it's worth the > effort to change it. > > Seemant > The problem is when you want to move. If the original statement is "GPL-2 or later", it is just to move to whatever gpl>2 you want to move. With the original statement "GPL-2" alone, you have to take contact and get an authorisation to move from each single programmer that contributed code into the project. I personally think at gpl-3 is better as gpl-2 because GPLv3 will block tivoization. Tivoization means computers (called “appliances”) contain GPL-covered software that you can't change, because the appliance shuts down if it detects modified software. The usual motive for tivoization is that the software has features the manufacturer thinks lots of people won't like. The manufacturers of these computers take advantage of the freedom that free software provides, but they don't let you do likewise. see http://www.gnu.org/licenses/rms-why-gplv3.html If you want to migrate to GPL-3, the most important question to solve will be: is it possible to get an agreement to do that migration from every single programmer involved in gentoo? My 2 c. contrib. Dominique -- N.B.: Tous les emails que je reçois sont filtrés par spamassassin avant de me parvenir. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Watch out for license changes to GPL-3.
Le Mon, 9 Jul 2007 09:39:14 -0700, Greg KH <[EMAIL PROTECTED]> a écrit : > On Sun, Jul 08, 2007 at 04:46:57PM +0200, Dominique Michel wrote: > > > > I personally think at gpl-3 is better as gpl-2 because GPLv3 will block > > tivoization. > > Only if the kernel is changed to v3, which it will not be. > > So this crusade by the FSF to stop what they explicitly said was a legal > use of v2, never succeeded, so please stop trying to worry about it. > > thanks, > > greg k-h I don't want to force anyone to use v3, I was just saying at v3 is better as v2 from my point of vue. Maybe I am wrong, but just to say at I am wrong is not enough. Can you explain more. If the kernel can be tivoized by someone, who will use this kernel? How can this affect the software xyz that have a v3 licence? Dominique -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Watch out for license changes to GPL-3.
> Thus the questions of whether many/most individual ebuilds /could/ be > copyrighted or if so whether it's worth doing so. Certainly, it's the > tree that contains the license, not the individual ebuilds, etc, which > give the copyright statement but little more. Gentoo policy would seem > to be, then, that it's the work of the tree as a whole that's > copyrighted. Individual ebuilds may or may not be, and it's /implied/ > (which isn't necessarily legally binding) that if they are, there'd be > little attempt at enforcement unless a significant portion of the tree > was copied/modified. > I think at current gentoo policy is good. I don't want to have the possibility to have individual licence for individual ebuild because that can block a licence change if such a change become a necessity. > That's a long and predictably controversial debate. See all the > electrons spilled on it debating the Linux kernel, for instance. While I > personally support the FSF and GPL3, there's a definitely valid position > held by some that the code return requirements of GPL2 are sufficient, > that Tivoization should be specifically allowed, because the code is > returned, even if it doesn't work on their specific product without the > signing keys and etc. > It doesn't matter if gentoo tree is v2 or v3 in regard of tivoization because no one single program in portage is linked against the tree or an eclass. I also think at the tivoization issue is not valid for the patches in the ebuild-xyz/files folder, because they are in the tree and the tree is under gpl v2. So in fact, it doesn't matter in regard of tivoization if the tre is under v2 or v3. I am not a layer, but I will be very surprised if I am wrong on that point. I don't know if an individual patches in some ebuild-xyz/files folder can be under v3 or v2 and later in order to be able to legally patch a gpl-v3 xyz software. The situation is: the ebuild-xyz have a patch under gpl-v2 in its files folder because it is in the tree and the whole tree is v2 only. And the software xyz is under gpl-v3. The problem is at I think at it will not be allowed by the software xyz because gpl-v3 is not compatible with a patch under the gpl-v2 only licence. The patch's licence must be gpl-v2 or later, gpl-v3, or gpl-v3 or later. Dominique -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Watch out for license changes to GPL-3.
> > Can you explain more. If the kernel can be tivoized by someone > > I'm sorry, but "tivoized" is not a verb. Please explain what you mean > by this. I mean if someone distribute a kernel with a licence that forbid to remove the functions he added even if we don't want them (as example drm at the kernel level as in Vista), > > > , who will use this kernel? How can this affect the software xyz that > > have a v3 licence? > > I do not understand the question, can you reprase it? > who will use this kernel when we can get a vanilla kernel and plenty of patches and do whatever we want to do with them? Will this affect the licencing or the distribution of the software xyz? > thanks, > > greg k-h You are welcome, Dominique -- [EMAIL PROTECTED] mailing list
