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.
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.
[gentoo-dev] Re: Major changes to gdesklets.eclass
Hi,
Joe Sapp nixpho...@gentoo.org:
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
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
URL:http://gentoo.faulhammer.org/
signature.asc
Description: PGP signature
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, 28 Dec 2009 23:31:44 +0100 Rémi Cardona r...@gentoo.org wrote: Le 28/12/2009 22:04, Fabio Erculiani a écrit : On Mon, Dec 28, 2009 at 9:51 PM, David Leverton levert...@googlemail.com 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 XTest.h 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 XInput.h 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] QA last rites for sys-apps/count
# Diego E. Pettenò flamee...@gentoo.org (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 Tue, Dec 29, 2009 at 11:15 AM, Doug Goldstein car...@gentoo.org 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
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] 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
[gentoo-dev] Last rites: sys-apps/dchroot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Jonathan Callen a...@gentoo.org (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] 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
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
[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 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
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
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.
[gentoo-portage-dev] Can emerge be instructed not to upgrade a dependency?
Hi. I want package A to incur a rebuild of package B, due to a newly introduced USE flag which affects B. I wish to express this in the package's ebuild. I therefore DEPENDed A in B[use_flag]. When I attempt to emerge A, portage offers to *upgrade* the dependency, taking in the new USE setting (there's an available upgrade in the tree). I want the dependency to be *rebuilt*, maintaining the same version currently installed. Can I tell emerge to do that? I'm looking for a general method of doing this, I.E. I wish to remain unaware of the specific version of the installed B package: If it's there, don't upgrade it, just rebuild w/new USE flag. 10x, Amit
Re: [gentoo-portage-dev] Can emerge be instructed not to upgrade a dependency?
On 12/29/2009 08:23 AM, Amit Dor-Shifer wrote: Hi. I want package A to incur a rebuild of package B, due to a newly introduced USE flag which affects B. I wish to express this in the package's ebuild. I therefore DEPENDed A in B[use_flag]. When I attempt to emerge A, portage offers to *upgrade* the dependency, taking in the new USE setting (there's an available upgrade in the tree). I want the dependency to be *rebuilt*, maintaining the same version currently installed. Can I tell emerge to do that? I'm looking for a general method of doing this, I.E. I wish to remain unaware of the specific version of the installed B package: If it's there, don't upgrade it, just rebuild w/new USE flag. The only way to do that now is to mask the unwanted update in /etc/portage/package.mask. -- Thanks, Zac
[gentoo-portage-dev] binpkg doesn't pull-in dependency required by USE flag
Hi.
amit0 myebuilds # qlist -Iv sys-apps/portage
sys-apps/portage-2.1.6.13
I've binpkg-ed sun-jdk.
I did so w/USE+=jce:
amit0 myebuilds # qtbz2 -x
/usr/portage/packages/dev-java/sun-jdk-1.6.0.16.tbz2
amit0 myebuilds # qxpak -x
/usr/portage/packages/dev-java/sun-jdk-1.6.0.16.xpak environment.bz2
amit0 myebuilds # bzgrep ^USE= environment.bz2
USE='X alsa amd64 elibc_glibc jce kernel_linux multilib nsplugin
userland_GNU'
The reason I did so is because sun-jdk's content depends upon that USE
flag, and I want the extra content in the tbz.
Normally, when jce is on, sun-jdk pulls-in sun-jce-bin:
amit0 myebuilds # USE=${USE} jce emerge -p sun-jdk
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N f ] dev-java/sun-jce-bin-1.6.0
[ebuild R ] dev-java/sun-jdk-1.6.0.16 USE=jce*
However, when I attempt to merge the binpkg-ed sun-jdk, dep isn't pulled:
amit0 myebuilds # USE=${USE} jce emerge -pk sun-jdk
These are the packages that would be merged, in order:
Calculating dependencies... done!
[binary R ] dev-java/sun-jdk-1.6.0.16 USE=jce*
Anyone has a clue as to why this is happening?
Amit
