Re: [gentoo-dev] Non-free software in Gentoo
Greg KH wrote: > The fact that some people claim that the firmware blobs somehow violate > the GPLv2 license of the kernel is a claim, not a fact, so please do not > state it as such. Hi Greg, Thanks for your reply. I think you misunderstood my point though. I wasn't saying that the firmware violates the GPL, I have no idea whether it does or not. I was saying that some of the firmware is non-free software, and therefore the license should include more than just GPL-2. This especially effects people using ACCEPT_LICENSE to maintain a free system. > Also note that the majority of these firmware blobs are now removed > from the kernel, and are in a separate patckage, so this might be > totally irrelevant at this point in time. This may be true, but the packages in the main tree still contain non-free firmware. If this is fixed in a later release, then GPL-2 would be fine for those. > So please don't state that the Linux kernel is not properly listed as > the GPLv2, because it is. In linux-2.6.31 for example, here are some excerpts from firmware/WHENCE: Regarding the keyspan USB driver: This firmware may not be modified and may only be used with Keyspan hardware. and the emi26 driver: This firmware may not be modified and may only be used with the Emagic EMI 2|6 Audio Interface. I'm not sure if this git repo is part of a separate package or not, but it seems the same terms are present: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=WHENCE;h=83d245bee1ec44cbd5c0e1a53a3989c57f675c91;hb=f20b0674534a444ae74239843cac19f72c64912b Which is why I think the license should be amended. If I'm mistaken, please do correct me, but based on my above notes, I believe it should be updated. Thanks, Vincent.
Re: [gentoo-dev] Non-free software in Gentoo
On Mon, Dec 28, 2009 at 08:16:22PM -0500, Richard Freeman wrote: > On 12/28/2009 05:53 PM, Robin H. Johnson wrote: >> You're wrong there. The kernel does contain additional licenses, and >> EXPLICITLY mentions them. Go and read 'firmware/WHENCE'. >> >> The licenses listed therein range from use-permitted only >> no-modification, to GPL-compliant and BSD-like. >> > > I stand corrected. Somebody should tell Linus that his readme/copying is a > bit misleading. They really shouldn't bury licenses in subdirectories. No, the readme/copying is correct, it covers all of the code that runs on the processor as one body of work. Firmware blobs are different in that they do not run in the same processor, and can be of a different license. thanks, greg k-h
Re: [gentoo-dev] Non-free software in Gentoo
On Mon, Dec 28, 2009 at 12:36:34AM -0500, Vincent Launchbury wrote: > 1) Not all of the licenses are completely accurate. For example, the > Linux kernels are listed as soley GPL-2, yet they contain blobs of > non-free firmware. The fact that some people claim that the firmware blobs somehow violate the GPLv2 license of the kernel is a claim, not a fact, so please do not state it as such. Also note that the majority of these firmware blobs are now removed from the kernel, and are in a separate patckage, so this might be totally irrelevant at this point in time. Also note that the FSF has nothing to do with the Linux kernel project or developers, so their statements have nothing to pertain to it and the kernel's "license purity". So please don't state that the Linux kernel is not properly listed as the GPLv2, because it is. thanks, greg "I made the kernel not-free according to debian-legal in 1999" k-h
[gentoo-dev] RFC: clutter.eclass -- new eclass for packages related to "Clutter"
Hi folks, Clutter is an opengl-based library for creating user interfaces. http://www.clutter-project.org/ It is currently used by gnome-games-2.28.2, and GNOME 3.0 will make extensive use of it. The Moblin project also uses clutter for parts of it's interface. The eclass is attached, and is very simple, consisting of just SRC_URI, DEPEND, LICENSE, DOCS, and src_install. It has been in use in the gnome overlay[1] for quite some time now. Currently 4 packages use the eclass (in the overlay of course) media-libs/clutter media-libs/clutter-gtk media-libs/clutter-gst dev-python/pyclutter in future, the following packages may also be added: media-libs/clutter-cairo media-libs/clutter-box2d media-libs/clutter-qt dev-perl/clutter-perl dev-libs/clutter-vala Thanks, 1. http://git.overlays.gentoo.org/gitweb/?p=proj/gnome.git;a=blob;f=eclass/clutter.eclass;h=e5dce3be9a7779f163554eb8c569d79c8adf2365;hb=HEAD -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team clutter.eclass Description: Binary data
Re: [gentoo-dev] Non-free software in Gentoo
On Tue, Dec 29, 2009 at 06:32:20PM +, Robin H. Johnson wrote: > Can we have USE-deps inside the LICENSE block then? Yes. ~harring pgphPPJZqEGs2.pgp Description: PGP signature
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
Le 29/12/2009 14:43, Henry Gebhardt a écrit : > 4) add a USE-flag, say "devel", that, when enabled, allows > compiling programs against the package. x11-libs/libXtst would > have an RDEPEND like this: > RDEPEND="devel? x11-libs/inputproto" This doesn't solve anything. It will just annoy users as they will have to enable USE=devel. So it's like the current situation, only way more annoying... Rémi
[gentoo-dev] Last rites: sys-apps/dchroot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Jonathan Callen (29 Dec 2009) # Project abandoned upstream (replaced by dev-util/schroot) # Collides with dev-util/schroot[dchroot] # Masked for removal in 30 days, bug 298874 sys-apps/dchroot -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks6V70ACgkQOypDUo0oQOriGwCgymsLu2338AAqL1Fz9YUK/ONo COkAnimOrIEK52d8QZLpDOl1wdkhTx9I =t1zz -END PGP SIGNATURE-
Re: [gentoo-dev] Non-free software in Gentoo
On Tue, Dec 29, 2009 at 12:02:14PM +0300, Peter Volkov wrote: > В Втр, 29/12/2009 в 00:24 -0500, Vincent Launchbury пишет: > > > File a bug with some ebuilds. > > > > It looks like somebody already has. See > > http://bugs.gentoo.org/show_bug.cgi?id=266157. I tested the latest > > ebuild, and it worked fine (see comment #59.) What would have to be > > done to get it in the main tree? > > Without further investigation it looks like ebuild is not a best > approach: http://bugs.gentoo.org/show_bug.cgi?id=266157#c60 Can we have USE-deps inside the LICENSE block then? LICENSE="GPL-2 BSD BSD-2 BSD-4 ... !libre-free? ( other-blob-licenses )" And test with: ACCEPT_LICENSES="-* @FSF-APPROVED" To see that the package is selected. P.S. Those scripts very over-zealous. They remove even firmware marked explicitly with GPL-2/BSD-2 licenses and having source available. The other advantage for the libre-free crowd is not even downloading tarballs that contain "tainted" materials in their eyes. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] Election for the Gentoo Council empty seat
Am Freitag, den 25.12.2009, 19:09 +0100 schrieb Tobias Scherbaum: > Am Dienstag, den 15.12.2009, 23:36 -0100 schrieb Jorge Manuel B. S. > Vicetto: > > nomination: December 17th to 30th > > I'd like to nominate dev-zero. And I accept, thanks. -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Tue, Dec 29, 2009 at 11:15 AM, Doug Goldstein wrote: > Then there was no need to waste everyone's time with a backhanded > comment about the X11 herd. And we can all get on with our lives. > >From your perspective it might've looked like a backhanded comment, but I know that scarabeus and lxnay know each other, and I believe they discussed this on #gentoo-desktop, so it didn't seem that way to me. "Assume people mean well" :) regards, -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] QA last rites for sys-apps/count
# Diego E. Pettenò (29 Dec 2009) # on behalf of QA team # # Another of the Jörg Schilling “fast and enhanced” unix # tools, fails to build with glibc 2.10 (bug #298879), will # most likely file in other ways as that is fixed. Ignore # CFLAGS (bug #241984). Ebuild is very sub-standard (never # dies, the ebuild seem to merge properly), and lacks # a maintainer. # # Removal on 2010-02-27 sys-apps/count
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, 28 Dec 2009 23:31:44 +0100 Rémi Cardona wrote: > Le 28/12/2009 22:04, Fabio Erculiani a écrit : > > On Mon, Dec 28, 2009 at 9:51 PM, David Leverton > > wrote: > >> On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote: > >>> What all this has to do with the fact that they are just > >>> build dependencies? Just wondering. > >> > >> They're not just build dependencies. They're required to > >> use the library in a certain way, namely to compile other > >> programs against it. As long as we don't have > >> compile-against dependencies, the only correct way to > >> express that is RDEPEND (and also DEPEND because > >> they're /also/ needed to build the library itself). > > > > To me you are saying that DEPEND would work just fine. No? > > No, but I understand why you're insisting. It took us a few > weeks to wrap our heads around this to understand it. > > Let's take an example (bug #228211 but there are dozens more). > > In this example, libfakekey does : #include > > and its configure.ac checks for "xtst.pc". Both files are > provided by x11-libs/libXtst so this dep is added to DEPEND and > RDEPEND. > > The problem comes from libXtst's XTest.h which #includes > which was provided by x11-proto/inputproto [1]. > > inputproto is/was a build-time dep of libXtst. > - libXtst _directly_ requires inputproto at build-time only > - libXtst _directly_ requires libXi at build-time and run-time > > However : > - requiring libXtst at build-time _also_ requires inputproto. > > For most users out there, this would never be a problem since > most Gentoo users always keep build-time deps on their systems. > > The problem arises for people who only keep run-time deps, > usually for binary packages. inputproto being a DEPEND-only dep > of libXtst, binary users will never get inputproto when they > build libfakekey. > > So there were 3 solutions : > > 1) add explicit deps in _all_ packages that DEPEND on libXtst > to _also_ depend on inputproto even if they don't use it at all > (most don't, they just use XTest functions). > > 2) add inputproto to libXtst's DEPEND and RDEPEND > > 3) modify EAPI to add a new *DEPEND variable to cater X's very > special needs. Isn't there a fourth solution? 4) add a USE-flag, say "devel", that, when enabled, allows compiling programs against the package. x11-libs/libXtst would have an RDEPEND like this: RDEPEND="devel? x11-libs/inputproto" Anything wrong with that? ~H
[gentoo-dev] Re: Major changes to gdesklets.eclass
Hi, Joe Sapp : > Anyways, a diff would be useless so I've attached the proposed eclass > [2]. Looks fine so far. What puzzled me is the documentation of the SLOT variable. What is the motivation to do so? * Sometimes you give a default on undefined ROOT variable, sometimes not. Please make it consistent for cosmetic reasons. * addwrite "${ROOT}/root/.gnome2": Is this unconditionally necessary? Or could a "boolean" in the ebuild be set to activate it? * DISPLAY variable export could be done with the assignment. Or is the export always needed? * Is the file name LICENSE always used for the license or is COPYING for example also possible? * einfo "Installing Control ${CTRL_DIRNAME}": Is not mirrored in the desklet branch of the if clause. V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://gentoo.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Non-free software in Gentoo
В Втр, 29/12/2009 в 00:24 -0500, Vincent Launchbury пишет: > > File a bug with some ebuilds. > > It looks like somebody already has. See > http://bugs.gentoo.org/show_bug.cgi?id=266157. I tested the latest > ebuild, and it worked fine (see comment #59.) What would have to be > done to get it in the main tree? Without further investigation it looks like ebuild is not a best approach: http://bugs.gentoo.org/show_bug.cgi?id=266157#c60 -- Peter.
Re: [gentoo-dev] Non-free software in Gentoo
В Пнд, 28/12/2009 в 18:41 +0530, Nirbheek Chauhan пишет: > I think we can simply follow debian and fedora's lead on this. They > have the lawyers, and Well, it's possible but not that simple. To do this it's not enough to compare packages, but files and patches should be compared as well (and reasons why files were dropped investigated) E.g. debian dropped rfc files from the packages because license is not free: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=393400 while we'll have to update our LICENSE. So, it's possible but not that easy as just follow debian or fedora. -- Peter.