Re: [gentoo-dev] rfc: location of portage tree
On 30 March 2012 17:08, Walter Dnes waltd...@waltdnes.org wrote: in the install handbook gives /usr/local/portage as an example overlay directory. I thought it was implicit that one shouldn't edit or create files in /usr/portage because they may be overwritten by the system e.g. during an emerge --sync. Maybe the manual needs to state this explicitly. Also, /usr/local is the standard place to keep one's own software and/or global customizations that aren't handled by the package manager, but don't belong in one user's home directory. Yeah, I don't have that layout /now/, but there was a time where one of my systems had stuff in there, for whatever reason, and I can't recall deciding to put it there myself. But that said, I *have* been using Gentoo since one of the 2004.x releases ... Ah the good old days of having the choice of NPTL ;) -- Kent perl -e print substr( \edrgmaM SPA NOcomil.ic\\@tfrken\, \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 ); http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] rfc: location of portage tree
On 29-03-2012 22:12:40 +0100, Roy Bamford wrote: For example, my /usr/portage/ on this system looks like this: portage/ tree/ profiles/ - tree/profiles/ distfiles/ packages/ layman/ it is a big improvement over the current distfiles-and-packages-mixed-with-tree-while-layman-wanders state :) Lets move packages/ out of there. I share /usr/portage over NFS to several different arches. Sharing /usr/portage/packages is a really bad idea in that set up. As they all run ~arch, they all build packages so I can downgrade quickly. I always use packages/CHOST for that reason. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Arbitrary breakage: sys-fs/cryptsetup
Excerpts from Samuli Suominen's message of 2012-03-29 19:59:17 +0200: I've been told dracut is able to handle this. Unverified. Dracut doesn't need anything built static. -- Amadeusz Żołnowski signature.asc Description: PGP signature
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
Will start to reply but will take some time as I don't have much this days :( El mar, 27-03-2012 a las 20:01 +0200, Sven Vermeulen escribió: On Tue, Mar 27, 2012 at 07:49:00PM +0200, Pacho Ramos wrote: I am a bit surprised handbook still doesn't suggest people to create a separate partition for /usr/portage tree. I remember my first Gentoo systems had it inside / and that lead to a lot of fragmentation, much slower emerge -pvuDN world (I benchmarked it when I changed my partitioning scheme to put /usr/portage) separate and a lot of disk space lost (I remember portage tree reached around 3 GB of disk space while I am now running with 300MB) Could handbook suggest people to put /usr/portage on a different partition then? The only doubt I have is what filesystem would be better for it, in my case I am using reiserfs with tail enabled, but maybe you have other different setups. To be honest, I don't think it is wise to describe it in the Gentoo Handbook just yet. I don't mind having it documented elsewhere, but the separate partition is not mandatory for getting Gentoo up and running. The instructions currently also just give an example partition layout and tell users that different layouts are perfectly possible. We need to take into consideration what is needed (must) for a Gentoo installation, what is seriously recommended (should), what is nice to have (could), etc. And for me, having a separate /usr/portage is a nice-to-have imo. Wkr, Sven Vermeulen My idea is to add a comment about this because it's not obvious having portage tree in a common partition with the rest of the system has some problems like high fragmentation, waste of disk space and also performance problems. I discovered it empirically when trying to get emerge -pvuDN world a bit faster. Also, once a partition scheme is chosen when installing Gentoo at first time, it's sometimes difficult to modify (for example, I was luck in my cases because I had big swap partitions I shrinked a bit for portage tree. You can probably see it's nice-to-have (as partition scheme that is shown in handbook showing partitions for /var, /home...), but it's better than letting people put their portage trees in a standard partition with the rest of the system signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El mar, 27-03-2012 a las 14:34 -0400, Alexandre Rostovtsev escribió: On Tue, 2012-03-27 at 20:01 +0200, Sven Vermeulen wrote: On Tue, Mar 27, 2012 at 07:49:00PM +0200, Pacho Ramos wrote: I am a bit surprised handbook still doesn't suggest people to create a separate partition for /usr/portage tree. I remember my first Gentoo systems had it inside / and that lead to a lot of fragmentation, much slower emerge -pvuDN world (I benchmarked it when I changed my partitioning scheme to put /usr/portage) separate and a lot of disk space lost (I remember portage tree reached around 3 GB of disk space while I am now running with 300MB) Could handbook suggest people to put /usr/portage on a different partition then? The only doubt I have is what filesystem would be better for it, in my case I am using reiserfs with tail enabled, but maybe you have other different setups. To be honest, I don't think it is wise to describe it in the Gentoo Handbook just yet. I don't mind having it documented elsewhere, but the separate partition is not mandatory for getting Gentoo up and running. The instructions currently also just give an example partition layout and tell users that different layouts are perfectly possible. We need to take into consideration what is needed (must) for a Gentoo installation, what is seriously recommended (should), what is nice to have (could), etc. And for me, having a separate /usr/portage is a nice-to-have imo. [...] 2. The handbook should mention that a separate small /usr/portage partition can noticeably improve performance for users with a rotational hard drive, and that it's not needed for solid-state drives. It should also mention that using Gentoo with a separate /usr/portage partition will require some additional configuration (such as changing DISTDIR and PKGDIR to avoid running out of space). -Alexandre. This would be nice :D signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El mar, 27-03-2012 a las 14:53 -0400, Ian Stakenvicius escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 27/03/12 02:47 PM, Rich Freeman wrote: On Tue, Mar 27, 2012 at 2:34 PM, Alexandre Rostovtsev tetrom...@gentoo.org The partitioning scheme is something that the user needs to decide on *before* getting Gentoo up and running. After the user had finished installing the operating system, it's too late to inform him about the advantages of a separate /usr/portage. Yes and no (if you have free space, you could easily move /usr/portage - some other changes are harder). However, you could extend this line of argument to raid, lvm, and even stuff like the use of systemd or an alternative package manager. All of those things are much easier to implement if you just start out with them. I'm all for creating a wiki to talk about some alternative options. Perhaps even link to it at the start of the handbook in the intro (if you're not in a rush and want to read about more advanced configurations, check out ...). However, I tend to agree that the handbook should be a nearly-foolproof no-frills Gentoo installation. You know, we have Code Listing 2.1: Filesystem Example in Section 4, we could always adjust that to have a /usr/portage partition in it (take a bit of space away from /home, or something) It doesn't recommend/require anything, but when users see it they'll think about it. This would be a good option, but I would anyway add a note warning people about the cons of having portage tree in a normal partition with the rest of the system, otherwise people could simply ignore that code listing because they could thing it's there simply on a try to get all system splitted ;) (for example, I don't usually have a separate partition for all what is listed there, only /, /home and /usr/portage) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Arbitrary breakage: sys-fs/cryptsetup
On 03/30/2012 10:56 AM, Amadeusz Żołnowski wrote: Excerpts from Samuli Suominen's message of 2012-03-29 19:59:17 +0200: I've been told dracut is able to handle this. Unverified. Dracut doesn't need anything built static. Thanks for verifying. Expected nothing less. I've reopened the bug[1] for genkernel so it doesn't get lost... [1] http://bugs.gentoo.org/409277
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
El mar, 27-03-2012 a las 16:05 -0400, Alec Moskvin escribió: On Tuesday 27 March 2012 14:34:03, Alexandre Rostovtsev wrote: On Tue, 2012-03-27 at 20:01 +0200, Sven Vermeulen wrote: On Tue, Mar 27, 2012 at 07:49:00PM +0200, Pacho Ramos wrote: I am a bit surprised handbook still doesn't suggest people to create a separate partition for /usr/portage tree. I remember my first Gentoo systems had it inside / and that lead to a lot of fragmentation, much slower emerge -pvuDN world (I benchmarked it when I changed my partitioning scheme to put /usr/portage) separate and a lot of disk space lost (I remember portage tree reached around 3 GB of disk space while I am now running with 300MB) Could handbook suggest people to put /usr/portage on a different partition then? The only doubt I have is what filesystem would be better for it, in my case I am using reiserfs with tail enabled, but maybe you have other different setups. To be honest, I don't think it is wise to describe it in the Gentoo Handbook just yet. I don't mind having it documented elsewhere, but the separate partition is not mandatory for getting Gentoo up and running. The instructions currently also just give an example partition layout and tell users that different layouts are perfectly possible. We need to take into consideration what is needed (must) for a Gentoo installation, what is seriously recommended (should), what is nice to have (could), etc. And for me, having a separate /usr/portage is a nice-to-have imo. The partitioning scheme is something that the user needs to decide on *before* getting Gentoo up and running. After the user had finished installing the operating system, it's too late to inform him about the advantages of a separate /usr/portage. It does not have to be a separate *physical* partition. It could be set up as a loop device without any real downsides: /usr/portage/tree.ext4/usr/portage/tree ext4loop,noatime 0 0 An advantage is that it can be easily resized if necessary. IMHO, chapter 4 of the handbook needs the following changes: 1. ext4, not ext3, needs to be recommended as the default filesystem. We have kernel 3.2 marked stable, there is no need to keep talking about ext4 as if it's something experimental. 2. The handbook should mention that a separate small /usr/portage partition can noticeably improve performance for users with a rotational hard drive, and that it's not needed for solid-state drives. It should also mention that using Gentoo with a separate /usr/portage partition will require some additional configuration (such as changing DISTDIR and PKGDIR to avoid running out of space). -Alexandre. (I think this last reply can complete my replies to this thread for now :)) Looks then that there are several alternatives for portage tree, then, maybe the option would be to add a note to Gentoo Handbook explaining the cons of having portage tree on a standard partition and, then, put a link to a wiki page (for example) where all this alternatives are explained. What do you think about this approach? signature.asc Description: This is a digitally signed message part
[gentoo-dev] Happy 10th birthday (in advance)
Hello, I would like to wish you all a happy birthday, 10 years already since first release (Gentoo 1.0)! Here is a little thing [1] we made to celebrate it. Recipe: two layers of Génoise (for each: 6 eggs, 180g sucre, 180g farine, vanilla sugar), between layers and on top: full cream with beaten eggs and caramel. Add between the middle layers on top of the cream: raspberry. ENJOY ;) [1]: http://imgur.com/iMjLi
Re: [gentoo-dev] Happy 10th birthday (in advance)
On 03/30/2012 04:00 PM, Axel wrote: Hello, I would like to wish you all a happy birthday, 10 years already since first release (Gentoo 1.0)! Here is a little thing [1] we made to celebrate it. Recipe: two layers of Génoise (for each: 6 eggs, 180g sucre, 180g farine, vanilla sugar), between layers and on top: full cream with beaten eggs and caramel. Add between the middle layers on top of the cream: raspberry. ENJOY ;) [1]: http://imgur.com/iMjLi Back to year 2009? http://www.gentoo.org/news/20091004-gentoo-10-years.xml
Re: [gentoo-dev] Happy 10th birthday (in advance)
On 30 March 2012 14:25, Samuli Suominen ssuomi...@gentoo.org wrote: On 03/30/2012 04:00 PM, Axel wrote: Hello, I would like to wish you all a happy birthday, 10 years already since first release (Gentoo 1.0)! Here is a little thing [1] we made to celebrate it. Recipe: two layers of Génoise (for each: 6 eggs, 180g sucre, 180g farine, vanilla sugar), between layers and on top: full cream with beaten eggs and caramel. Add between the middle layers on top of the cream: raspberry. ENJOY ;) [1]: http://imgur.com/iMjLi Back to year 2009? http://www.gentoo.org/news/20091004-gentoo-10-years.xml Even though we already celebrated it, maybe 10-years-since-1.0 is a better event to celebrate. Remember when Gentoo had version numbers? (even though they got stuck at 1.4 for ages?) D'awww
Re: [gentoo-dev] If anyone is intrested in helping around with Xfce...
On 03/22/2012 07:50 PM, Michael Orlitzky wrote:
On 03/22/2012 03:29 AM, Samuli Suominen wrote:
On 03/22/2012 09:25 AM, Samuli Suominen wrote:
If anyone is intrested in helping around with Xfce we have 2 bigger
tasks on going:
1) Pass --libexecdir=${EPREFIX} to all plugins installing to
/usr/libexec/xfce4/ as opposed to /usr/lib/xfce4/
Typing error.
inherit multilib xfconf
--libexecdir=${EPREFIX}/usr/$(get_libdir)
I tested this, works fine. Is there a better way to fix it within the
package, though?
I tend to remember you are the upstream for xfce4-hdaps?
Then absolutely. You should convert the plug-in to the new module
format, check for example here:
http://git.xfce.org/panel-plugins/xfce4-mpc-plugin/commit/?id=11e6ebca679265ff5fb4e2cda585d8a26f3c99c1
Then check the paths used by actual plugins shipped with the
xfce-base/xfce4-panel. For example:
$libdir/xfce4/panel/plugins/libhdaps.so
$datadir/xfce4/panel/plugins/hdaps.desktop
So it's just as you guessed, the --libdir= thing is just a workaround we
can apply for unported plugins...
- Samuli
diff --git a/xfce-extra/xfce4-hdaps/xfce4-hdaps-0.0.7.ebuild
b/xfce-extra/xfce4$
index f987178..6ac70b6 100644
--- a/xfce-extra/xfce4-hdaps/xfce4-hdaps-0.0.7.ebuild
+++ b/xfce-extra/xfce4-hdaps/xfce4-hdaps-0.0.7.ebuild
@@ -29,6 +29,7 @@ DEPEND=${COMMON_DEPEND}
pkg_setup() {
XFCONF=(
--disable-option-checking
+ --libexecdir=${EPREFIX}/usr/$(get_libdir)
$(xfconf_use_debug)
)
[gentoo-dev] RFC: oDesk License
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Find attached a license for an application I'm using. I've already cleared that redistribution of the package is okay. [1] I didn't see anything in there much more than the standard don't blame us if your system blows up, and some fairly standard end-user stuff. [1] https://www.odesk.com/mc/#tickets/thread/122778452 Thanks, Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk912mQACgkQVxOqA9G7/aAzEgD9HJQO8YPpnoR3ZmsZHEUNK+Sn 3fhnGAVud5CQXeLYgHwA/RUaszh+DhLDpcV/zvbmiaOdg+xXo+AQRB1AB4NNc2se =3N3g -END PGP SIGNATURE- ODESK TEAM LICENSE AGREEMENT This License Agreement is a legal agreement between the User (an individual or an entity) and oDesk Corp. for (a) the Software Product identified above, which includes computer software and electronic documentation, and (b) the Service provided by oDesk web-site and web services. The User should carefully read the following terms and conditions before using the Software Product. The Software Product is licensed, not sold. The Software Product is protected by copyright laws and international copyright treaties, as well as other intellectual property laws and treaties. By installing, copying, or otherwise using the Software Product, the User is agreeing to be bound by the terms of this Agreement. If the User does not agree to the terms of this Agreement, the User is not authorized to use the Software Product or the Service. 1. GRANT OF LICENSE. oDesk grants the User the non-exclusive right to install and use the Software Product on a computer system. The Software Product can only be used in conjunction with an oDesk Team Online Account with a valid license to access the Service. 2. ACCESS TO DATA. Subject to the terms of this Agreement, the User grants to oDesk the non-exclusive, worldwide, right to use, copy, store, transmit and display data submitted by the User to the Service (User Data or Content) solely to the extent necessary to provide the Service as requested by User. All User Data shall remain the sole property of User, unless specifically notified in advance. User, not oDesk, shall have sole responsibility for the accuracy, quality, integrity, legality, reliability, appropriateness and copyright of all User Data and oDesk shall not be responsible or liable for the deletion, correction, destruction, damage, loss or failure to store any Data. oDesk will not monitor, edit, or disclose the contents of a user's collected data, except that you agree that oDesk may do so: (a) if required by law; (b) to comply with legal process; (c) to enforce this Agreement and any applicable Guidelines, Rules, or Service-specific Terms of Service; (d) to respond to claims that any Content violates the rights of third-parties; or (e) to protect the rights, property, or personal safety of oDesk, its employees, users and the public. oDesk may remove or disclose collected data on the Service for the same reasons. 3. PRIVACY. oDesk's privacy statement may be viewed at http://team.odesk.com/html/privacy_statement.html. oDesk reserves the right to modify its privacy and security policies in its reasonable discretion from time to time. 4. RESTRICTIONS. (A) The User must comply with all applicable laws regarding the use of the Software Product and the Service. (B) The User may not reverse engineer, decompile, or disassemble the Software Product or the Service, or access the Service in order to build a competitive product or service or copy any ideas, features, functions or graphics of the Software Product or the Service. (C) The User may not rent or lease the Software Product or copy, license, sell, transfer, make available, distribute, or assign this license or the Content to any third-party. (D) The User may not distribute copies of the activated Software Product to third parties. (E) The User is permitted to store, manipulate, analyze, reformat, print, and display the Content only for his internal business use. Unauthorized use, resale or commercial exploitation of the Software Product, the Service and/or the Content in any way is expressly prohibited. (F) The User shall not create Internet links to the Service or frame or mirror any Content contained on, or accessible from, the Service on any other server or Internet-based device. (G) The User accepts oDesk's right to audit the User compliance with this agreement by monitoring computer and product usage. 5. TERMINATION. oDesk may terminate this license agreement if the User fails to comply with the terms and conditions of this license agreement. In such event, the User must destroy all copies of the Software Product. 6. NO WARRANTY. Any use of the Software Product is at the User's own risk. To the maximum extent permitted by applicable law, oDesk and its suppliers disclaim all warranties and conditions, either express or implied, including, but not limited to,
Re: [gentoo-dev] RFC: oDesk License
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/30/2012 12:08 PM, Aaron W. Swenson wrote: Find attached a license for an application I'm using. I've already cleared that redistribution of the package is okay. [1] I didn't see anything in there much more than the standard don't blame us if your system blows up, and some fairly standard end-user stuff. [1] https://www.odesk.com/mc/#tickets/thread/122778452 Thanks, Aaron I was just informed that registration is required to view the link. Here's an excerpt of the transcript: 3/29/2012 8:19:33 AM Winnie: Hello, Aaron Swenson. Can I help you with anything today? 3/29/2012 8:20:24 AM Aaron Swenson: I am a developer for Gentoo Linux and I'd like to package the oDesk application so that others on Gentoo can easily install oDesk. Are there any restrictions? 3/29/2012 8:22:40 AM Winnie: Hi. Do they have their own oDesk accounts? 3/29/2012 8:23:20 AM Winnie: There are no restrictions. Users can install the oDesk team app. 3/29/2012 8:23:38 AM Aaron Swenson: Presumably, they would have an account. 3/29/2012 8:24:31 AM Aaron Swenson: I just want to make sure there aren't any restrictions on redistribution of the software. 3/29/2012 8:25:30 AM Winnie: No, it is fine. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk913GkACgkQVxOqA9G7/aBx0QEAgYBAyk2UaqeC855LV76IGW1G oaGEqbwqs2/FF+aPQrkA/3R0X7rJ8N1ZCE1lP9jgNJRi7ML3xDJFSABPS72Of7lP =q2V2 -END PGP SIGNATURE-
[gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
I wrote sys-freebsd/virtio-kmod (bug 410199) while studying Gentoo/FreeBSD as part of an attempt to port gptzfsloader to Gentoo Linux. naota wrote an improvement that would be useful to send upstream. However, the GPL-2 license poses a problem according to conversations that I had in #gentoo-dev. While I have asked naota for permission to upstream the line he wrote, this poses a more general issue for collaboration, especially if I port more kernel modules from FreeBSD Ports. Would it be possible to relicense sys-freebsd/* under terms of the BSD-2 license? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
On Fri, 30 Mar 2012 12:34:26 -0400 Richard Yao r...@cs.stonybrook.edu wrote: I wrote sys-freebsd/virtio-kmod (bug 410199) while studying Gentoo/FreeBSD as part of an attempt to port gptzfsloader to Gentoo Linux. naota wrote an improvement that would be useful to send upstream. However, the GPL-2 license poses a problem according to conversations that I had in #gentoo-dev. if he wrote the improvement, he can send it upstream under whatever license he wants; generally, it is implicit that a patch follows the same license as the code it applies to, esp. when the author himself agrees to share it with upstream. While I have asked naota for permission to upstream the line he wrote, this poses a more general issue for collaboration, especially if I port more kernel modules from FreeBSD Ports. Would it be possible to relicense sys-freebsd/* under terms of the BSD-2 license? what do you mean by 'relicense' ? for ebuilds, you'll have to ask permission to all contributors to this area, and, afaik, the foundation owns copyrights so it has a word to say too. if you mean the 'LICENSE' field of ebuilds, then this is not the right place to ask. A.
Re: [gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
On 03/30/12 13:34, Alexis Ballier wrote: On Fri, 30 Mar 2012 12:34:26 -0400 Richard Yao r...@cs.stonybrook.edu wrote: I wrote sys-freebsd/virtio-kmod (bug 410199) while studying Gentoo/FreeBSD as part of an attempt to port gptzfsloader to Gentoo Linux. naota wrote an improvement that would be useful to send upstream. However, the GPL-2 license poses a problem according to conversations that I had in #gentoo-dev. if he wrote the improvement, he can send it upstream under whatever license he wants; generally, it is implicit that a patch follows the same license as the code it applies to, esp. when the author himself agrees to share it with upstream. The improvement is to the ebuild itself. It is a variable containing a list of directories upon which the module's build system depends. I spoke to naota and he doesn't have any problem sending this upstream, so I sent an email to the FreeBSD maintainer offering him the improvement. While I have asked naota for permission to upstream the line he wrote, this poses a more general issue for collaboration, especially if I port more kernel modules from FreeBSD Ports. Would it be possible to relicense sys-freebsd/* under terms of the BSD-2 license? what do you mean by 'relicense' ? for ebuilds, you'll have to ask permission to all contributors to this area, and, afaik, the foundation owns copyrights so it has a word to say too. if you mean the 'LICENSE' field of ebuilds, then this is not the right place to ask. A. I am referring to the ebuilds themselves. Right now, all ebuilds in the tree are GPL-2 licensed. This makes contributing FreeBSD-specific improvements to FreeBSD Ports upstream difficult. I want sys-freebsd/virtio-kmod to be BSD-2 licensed, but I do not expect the version that enters the portage tree to be BSD-2 licensed unless people clarify that it is okay to license ebuilds under something other than the GPL-2. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
On Fri, Mar 30, 2012 at 01:52:18PM -0400, Richard Yao wrote: The improvement is to the ebuild itself. It is a variable containing a list of directories upon which the module's build system depends. I spoke to naota and he doesn't have any problem sending this upstream, so I sent an email to the FreeBSD maintainer offering him the improvement. I would argue that a trivial change like that is unlikely to be substantial enough to constitute a copyrightable work at all.
Re: [gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
On 03/30/12 13:52, Richard Yao wrote: I want sys-freebsd/virtio-kmod to be BSD-2 licensed, but I do not expect the version that enters the portage tree to be BSD-2 licensed unless people clarify that it is okay to license ebuilds under something other than the GPL-2. To clarify, I would like the upstream developers to consider improvements in Gentoo/FreeBSD for inclusion to make collaboration easier. I view the GPL-2 to be an issue, particularly because I had to ask naota for permission to contribute his improvement to an ebuild I wrote to the upstream developers. I do not expect the upstream maintainers to familiarize themselves with the intricacies of what they can take and what they cannot take, so I would prefer to relicense all ebuilds in sys-freebsd/* under the terms of the BSD-2 license. It is much easier to say to the upstream developers that everything in portage's sys-freebsd/* category is available to them under the license that they use than it is expect them to learn a list of rules. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
On 03/30/12 14:00, Jon Portnoy wrote: On Fri, Mar 30, 2012 at 01:52:18PM -0400, Richard Yao wrote: The improvement is to the ebuild itself. It is a variable containing a list of directories upon which the module's build system depends. I spoke to naota and he doesn't have any problem sending this upstream, so I sent an email to the FreeBSD maintainer offering him the improvement. I would argue that a trivial change like that is unlikely to be substantial enough to constitute a copyrightable work at all. I brought this to the list specifically because the line between a work being trivial or not is poorly defined. I would prefer something more concrete for the purpose of enabling collaboration with FreeBSD upstream. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
On Fri, 30 Mar 2012, Richard Yao wrote: what do you mean by 'relicense' ? for ebuilds, you'll have to ask permission to all contributors to this area, and, afaik, the foundation owns copyrights so it has a word to say too. if you mean the 'LICENSE' field of ebuilds, then this is not the right place to ask. I am referring to the ebuilds themselves. Right now, all ebuilds in the tree are GPL-2 licensed. This makes contributing FreeBSD-specific improvements to FreeBSD Ports upstream difficult. I want sys-freebsd/virtio-kmod to be BSD-2 licensed, but I do not expect the version that enters the portage tree to be BSD-2 licensed unless people clarify that it is okay to license ebuilds under something other than the GPL-2. I fail to understand what the license of the ebuild has to do with the license of the package itself. Ebuilds in the Portage tree must be licensed under the GPL. This is part of the Gentoo Social Contract [1], so I guess it won't change anytime soon. And IMHO, we would be ill-advised to allow different licenses for ebuilds in the tree, because that would imply that we cannot copy code from one ebuild to another (or from ebuild to eclass) any more. Ulrich [1] http://www.gentoo.org/main/en/contract.xml
Re: [gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
On Fri, Mar 30, 2012 at 2:47 PM, Ulrich Mueller u...@gentoo.org wrote: Ebuilds in the Portage tree must be licensed under the GPL. This is part of the Gentoo Social Contract [1], so I guess it won't change anytime soon. And IMHO, we would be ill-advised to allow different licenses for ebuilds in the tree, because that would imply that we cannot copy code from one ebuild to another (or from ebuild to eclass) any more. Speaking as an individual trustee, I tend to agree. If there are specific pains associated with not being able to submit patches upstream or such, please do point them out and I'm sure we'll consider what can be done to accommodate this. However, if this really is a one-off situation then we're probably better-off if we just ask individual contributors to re-license when needed. I'd think the only thing in the portage tree upstream would be interested in would be patches (including sed operations). Rich
[gentoo-dev] suspicious code in gnustep eclasses
This is from gnustep-base.eclass:
egnustep_doc() {
if [[ -d ./Documentation ]] ; then
# Check documentation presence
cd ${S}/Documentation
if [[ -f ./[mM]akefile || -f ./GNUmakefile ]] ; then
emake ${GS_ENV[@]} all || die doc make failed
emake ${GS_ENV[@]} install || die doc install failed
fi
cd ..
fi
}
Shouldn't those cd calls above rather be pushd/popd? It seems the above
assumes that CWD is ${S} when egnustep_doc is executed, which is
probably true, but pushd/popd seems just safer.
Also, instead of ./Documentation, ${S}/Documentation could be used.
This is from gnustep-2.eclass:
RDEPEND=${DEPEND}
debug? ( =sys-devel/gdb-6.0 )
Is there some gnustep crash-reporting tool that uses gdb? I think it's
reasonable for USE=debug to influence how things are compiled, but
unless gdb is required for something to work, it should be up to the
user to install or not install gdb.
In case something is broken with gdb-6.0, please consider two points:
- there is no gdb-6.0 in the tree now
- you could add a blocker on gdb-6.0 instead, which is not going to
disrupt developers because there is no such version in the tree anyway,
and we have up-to-date systems
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] haskell-cabal.eclass suggestions
Those are really just nits, but I thought I'd share what I've noticed.
cabal-mksetup() {
local setupdir
if [[ -n $1 ]]; then
setupdir=$1
else
setupdir=${S}
fi
rm -f ${setupdir}/Setup.{lhs,hs}
echo 'import Distribution.Simple; main = defaultMainWithHooks
defaultUserHooks' \
$setupdir/Setup.hs
}
I think there should be || die after echo, to catch out-of-disk-space
problems.
cabal-copy() {
has ${EAPI:-0} 0 1 2 ! use prefix ED=${D}
set -- copy --destdir=${D} $@
echo ./setup $@
./setup $@ || die setup copy failed
# cabal is a bit eager about creating dirs,
# so remove them if they are empty
rmdir ${ED}/usr/bin 2 /dev/null
# GHC 6.4 has a bug in get/setPermission and Cabal 1.1.1 has
# no workaround.
# set the +x permission on executables
if [[ -d ${ED}/usr/bin ]] ; then
chmod +x ${ED}/usr/bin/*
fi
# TODO: do we still need this?
}
I think there should be || die after chmod.
haskell-cabal_pkg_setup() {
ghc-package_pkg_setup
if [[ -z ${CABAL_BOOTSTRAP} -z ${CABAL_FROM_GHC} ]] !
ghc-sanecabal ${CABAL_MIN_VERSION}; then
eerror The package dev-haskell/cabal is not correctly installed for
eerror the currently active version of ghc ($(ghc-version)). Please
eerror run ghc-updater or haskell-updater or re-build
dev-haskell/cabal.
die cabal is not correctly installed
fi
if [[ -z ${CABAL_HAS_BINARIES} ]] [[ -z ${CABAL_HAS_LIBRARIES} ]];
then
eerror QA: Neither bin nor lib are in CABAL_FEATURES.
Shouldn't this be eqawarn?
fi
if [[ -n ${CABAL_UNKNOWN} ]]; then
ewarn Unknown entry in CABAL_FEATURES: ${CABAL_UNKNOWN}
Shouldn't this be eqawarn?
fi
if cabal-is-dummy-lib; then
einfo ${P} is included in ghc-${CABAL_CORE_LIB_GHC_PV}, nothing to
install.
fi
}
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
On 03/30/12 14:47, Ulrich Mueller wrote: I fail to understand what the license of the ebuild has to do with the license of the package itself. It has nothing to do with the license of the package. That is completely separate. This has to do with the license of the ebuild itself. FreeBSD Ports inspired Daniel Robbins to create Portage. The issue that is our ability to share FreeBSD-specific improvements between ebuilds in portage and Makefiles in FreeBSD ports. The issues that are similar for both. Collaboration on FreeBSD-specific things in sys-freebsd/* would make life easier for both portage ebuild maintainers and FreeBSD port maintainers. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
On 03/30/12 15:12, Rich Freeman wrote: If there are specific pains associated with not being able to submit patches upstream or such, please do point them out and I'm sure we'll consider what can be done to accommodate this. However, if this really is a one-off situation then we're probably better-off if we just ask individual contributors to re-license when needed. I have already handled this specific case by talking to naota. I will revive the issue on the list should this become a repeat occurrence. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: x11-themes/qgtkstyle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 # Markos Chandras hwoar...@gentoo.org (30 Mar 2012) # Unmaintained. Replaced by x11-libs/qt-gui[gtkstyle] # Removal in 30 days x11-themes/qgtkstyle - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iQIcBAEBCgAGBQJPdgwRAAoJEPqDWhW0r/LCx2oP/jlHm+ofK/9Dg/cAM8RCFvYE CcW0eem/vRmCneYZRc1EEE7tWb5H6EUtQkgYGbCznKVRjJ7V4bbzd81L5xgOP5PF n1rQE9v911+rvrbSwGghiFj+5Io2IGqLuXP6JuGxHVBesHLeLLZU8wgO1PG1g54C PnaPQ3f8M/hBrxDLPeeG7igm3UAjKvapb5TuZEpXxm29ehoLQSTINuqAQkuIPsqo HIYUuHhVGeTHxyVb6FpLW6P3dn+6QlLFw79qlxkYYWcbU2MjaBGqSoulPy8AEu0e vqX71cUDF4AnkkA/+MB1f9vFGO3if/DHtGA/uqaUR81ek5Hw9Hq/nlMPn69Ai/5O C3KIPUGLx7cYiDgzg+OGvwAD8oAou+bIHQOoMAcUrhk10yT+2oLw+tg4sIsjv1E4 57GG1KCbOxowYk77JJjAJ9ZX6CewSsV+HHQ+dBUaNJYqbIipl+SMsDAqnGlCz2CX 26x5ZJKAr1LLHUAGvUW9doPh4+Ry2XiSmVHTAqk2V3Wa9zK/JFEmhrmh2yMRYtp7 1tWZsPFdpjxmqBAONSfn/jX2oixURawUDhAQco/zzOBm06LhGkojx9mHhQbhrOes bovjr8eW6kPWujTRUl30otAu2S7z6EDN96htbc7e0Qt/1/ixwX9WKLRASn5m0zi2 t7NOksZbe/zSpTMj9zgG =myIr -END PGP SIGNATURE-
Re: [gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
On Fri, Mar 30, 2012 at 12:36 PM, Richard Yao r...@cs.stonybrook.edu wrote: On 03/30/12 14:47, Ulrich Mueller wrote: I fail to understand what the license of the ebuild has to do with the license of the package itself. It has nothing to do with the license of the package. That is completely separate. This has to do with the license of the ebuild itself. FreeBSD Ports inspired Daniel Robbins to create Portage. The issue that is our ability to share FreeBSD-specific improvements between ebuilds in portage and Makefiles in FreeBSD ports. The issues that are similar for both. Collaboration on FreeBSD-specific things in sys-freebsd/* would make life easier for both portage ebuild maintainers and FreeBSD port maintainers. I doubt you can get the content re-licensed under a different license. You may be able to convince folks to add an additional license (|| (GPL-2 BSD-2)). That way Gentoo keeps its GPL-2 and freebsd can have the code as BSD-2. -A
Re: [gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
On 03/30/2012 15:36, Richard Yao wrote: It has nothing to do with the license of the package. That is completely separate. This has to do with the license of the ebuild itself. FreeBSD Ports inspired Daniel Robbins to create Portage. The issue that is our ability to share FreeBSD-specific improvements between ebuilds in portage and Makefiles in FreeBSD ports. The issues that are similar for both. Collaboration on FreeBSD-specific things in sys-freebsd/* would make life easier for both portage ebuild maintainers and FreeBSD port maintainers. I would figure that since each is written in its own language (ebuilds in bash, FBSD in Make), that all you have to do is share the idea of the fix. Ideas themselves can't be licensed, but implementations can, and the idea can be implemented in Makefile syntax in Ports under BSD-2, and in Portage in Bash syntax under GPLv2. That said, sometimes you just find entire chunks of BSD code in Linux, complete with only the BSD copyright block: See drivers/scsi/aic7xxx/queue.h -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Happy 10th birthday (in advance)
On 03/30/2012 10:44, James Broadhead wrote: Remember when Gentoo had version numbers? (even though they got stuck at 1.4 for ages?) D'awww Maybe it's time for Gentoo-2.0? At that glacial pace, we should catch up to Firefox's versioning shortly before the heat death of the Universe. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Relicensing sys-freebsd/* under the BSD-2 license
On 03/30/12 16:19, Alec Warner wrote: I doubt you can get the content re-licensed under a different license. You may be able to convince folks to add an additional license (|| (GPL-2 BSD-2)). That way Gentoo keeps its GPL-2 and freebsd can have the code as BSD-2. Dual-licensing is fine by me. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Happy 10th birthday (in advance)
On 03/30/12 17:15, Joshua Kinard wrote: Maybe it's time for Gentoo-2.0? I think we should wait for Portage 2.2 to be stabilized before we declare Gentoo 2.0. @preserved-libs is enough of an advance that I think claiming 2.0 would be merited, if only for the attention it would draw at Phoronix. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Happy 10th birthday (in advance)
On Fri, Mar 30, 2012 at 5:55 PM, Richard Yao r...@cs.stonybrook.edu wrote: On 03/30/12 17:15, Joshua Kinard wrote: Maybe it's time for Gentoo-2.0? I think we should wait for Portage 2.2 to be stabilized before we declare Gentoo 2.0. @preserved-libs is enough of an advance that I think claiming 2.0 would be merited, if only for the attention it would draw at Phoronix. We don't want that kind of attention.
