Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-libs/confuse: confuse-2.7.ebuild ChangeLog
On 10/03/13 20:04, Jeroen Roovers wrote: On Sun, 3 Mar 2013 12:44:18 +0100 Tomáš Chvátal tomas.chva...@gmail.com wrote: If I remember correctly the damn rule is to put it for 30 days into testing, and as you said there was no previous version on arm so users could've reported some issues, i agree that sometimes you have to ignore the rules to really fix stable, but was this such case for sure? I've done straight to stable keywording _many_ times. The rationale is that with no previous version stable for a particular architecture, there really are no users who could see _regressions_, hence waiting the nominal thirty days is meaningless in this case. agreed, this is how I work too
Re: [gentoo-dev] New license - adobe-pcfi
On Sun, 10 Mar 2013 11:10:38 + Robin H. Johnson robb...@gentoo.org wrote: On Sun, Mar 10, 2013 at 11:01:55AM +0100, Ulrich Mueller wrote: CMaps for PDF CJK Fonts --- [...] Permission is granted for redistribution of this file provided this copyright notice is maintained intact and that the contents of this file are not altered in any way from its original form. This would imply that the license cannot be added to the MISC-FREE group. Ok, I think @BINARY-REDISTRIBUTABLE may be workable instead for this license. Thanks to both of you. So the current plan is: license name: Adobe-PCFI license group: BINARY-REDISTRIBUTABLE If there are no further objections within a week I'll commit the license. signature.asc Description: PGP signature
[gentoo-dev] sys-kernel/mknitcpio could use a maintainer
mkinitcpio seems to have lost maintainer, and it's badly behind at this point i'm not sure if the latest even works, as ArchLinux has moved to systemd, but it might if nobody steps up, say, before summer or it starts failing otherwise, it'll propably have to be p.masked and lastrited thanks (beforehand) - Samuli
Re: [gentoo-dev] New license - adobe-pcfi
On Mon, 11 Mar 2013, Ralph Sennhauser wrote: Thanks to both of you. So the current plan is: license name: Adobe-PCFI license group: BINARY-REDISTRIBUTABLE Looks good to me. If there are no further objections within a week I'll commit the license. Ulrich pgpznMFKnJzDL.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] gentoo-openstack project
At Sun, 10 Mar 2013 16:57:07 -0500, Matthew Thode wrote: Starting up a new project (gentoo-openstack). It is currently a subproject of virtualization and our project page can be found here. http://www.gentoo.org/proj/en/virtualization/openstack/ The current goals are to flesh out the support for Openstack on Gentoo (we have the ebuilds in tree, but initscripts and the like need some work). We also want to maintain better security release upstream (as they do not make interim security releases during their release cycle. We have a bug alias as well as a list (openstack and gentoo-openstack respectively). Any advice is welcome :D -- -- Matthew Thode (prometheanfire) I'm interested in this, and I think a lot of folks are. I've noticed there's a pretty thorough, active overlay in the wild: https://github.com/hyves-org/openstack-overlay Have you reached out to that guy? Erik
Re: [gentoo-dev] [RFC] gentoo-openstack project
On 11-03-2013 08:02:43 -0500, Erik Mackdanz wrote: I'm interested in this, and I think a lot of folks are. I've noticed there's a pretty thorough, active overlay in the wild: https://github.com/hyves-org/openstack-overlay Have you reached out to that guy? You definitely should. In case you need it, I can introduce you to e.g. Cor. Fabian -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] [RFC] gentoo-openstack project
On 03/11/13 08:02, Erik Mackdanz wrote: At Sun, 10 Mar 2013 16:57:07 -0500, Matthew Thode wrote: Starting up a new project (gentoo-openstack). It is currently a subproject of virtualization and our project page can be found here. http://www.gentoo.org/proj/en/virtualization/openstack/ The current goals are to flesh out the support for Openstack on Gentoo (we have the ebuilds in tree, but initscripts and the like need some work). We also want to maintain better security release upstream (as they do not make interim security releases during their release cycle. We have a bug alias as well as a list (openstack and gentoo-openstack respectively). Any advice is welcome :D -- -- Matthew Thode (prometheanfire) I'm interested in this, and I think a lot of folks are. I've noticed there's a pretty thorough, active overlay in the wild: https://github.com/hyves-org/openstack-overlay Have you reached out to that guy? Erik Ya, I've talked to him. At first that is where I based some of the ebuilds I used, but it is all in tree now. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: x11-drivers/xf86-input-citron
# Chí-Thanh Christopher Nguyễn chith...@gentoo.org (11 Mar 2013) # Does not build against modern xorg-server, dead upstream # Removal in 30 days x11-drivers/xf86-input-citron
[gentoo-dev] [RFC] patch linux-mod.eclass to add support for module signing V2
This is the same patch posted earlier but with the feedback from Steven J.
Long from the last post on the previous thread. (Thanks!)
Signed kernel modules require that the kernel is compiled with
CONFIG_MODULE_SIG=y so that during compilation, the public key hash is
stored in the kernel so that it can be verified later when insmod'ing an
external module. There is no problem with in-tree modules, this are sign
correctly and loaded, the problem is with out-of-the-tree modules installed
by portage; this ones are not signing ware.
So this patch adds a new USE flag to the linux-mod.eclass named
module-signing. We enabled, it will check if the user has selected all
the correct config options in the kernel, and optionally, where are the
private and public parts of the key so that the module is signed and
install time. If any of this fails, the installation of the module is
aborted.
From the end user perspective, if he wants to add support for this, all he
has to do is enable CONFIG_MODULE_SIG in the kernel. If no keys are found
during the build, it will be generated one. If one wants to create a key
himself, it's also possible to use this key, he just has to name it
signing_key.priv and siging_key.x509 and put it under /usr/src/linux.
After the kernel is compiled, this keys can be moved elsewhere and the path
to them specified in make.conf under the vars KERNEL_MODSECKEY and
KERNEL_MODPUBKEY.
Patch below for review, discussion and testing.
Thanks,
Carlos Silva
--- linux-mod.eclass 2012-09-15 16:31:15.0 +
+++ linux-mod.eclass 2013-03-11 18:58:34.075561064 -0100
@@ -125,9 +125,10 @@
inherit eutils linux-info multilib
EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst src_install
src_compile pkg_postrm
-IUSE=kernel_linux
+IUSE=module-signing kernel_linux
SLOT=0
-RDEPEND=kernel_linux? ( virtual/modutils )
+RDEPEND=kernel_linux? ( virtual/modutils )
+ module-signing? ( app-crypt/gnupg )
DEPEND=${RDEPEND}
sys-apps/sed
kernel_linux? ( virtual/linux-sources )
@@ -208,6 +209,32 @@
fi
}
+
+# internal function
+#
+# FUNCTION: check_module_signing
+# DESCRIPTION:
+# Checks for KERNEL_MODSECKEY, KERNEL_MODPUBKEY and verifies the files
exists
+check_module_signing() {
+ use module-signing || return 1
+
+ # Check that the configuration is correct
+ KERNEL_MODSECKEY=${KERNEL_MODSECKEY:-${KV_DIR}/signing_key.priv}
+ KERNEL_MODPUBKEY=${KERNEL_MODPUBKEY:-${KV_DIR}/signing_key.x509}
+ if [[ -s ${KERNEL_MODSECKEY} ]]; then
+ eerror KERNEL_MODSECKEY points to a missing or empty file:
+ eerror ${KERNEL_MODSECKEY}
+ die Invalid KERNEL_MODSECKEY
+ fi
+ if [[ -s ${KERNEL_MODPUBKEY} ]]; then
+ eerror KERNEL_MODPUBKEY points to a missing or empty file:
+ eerror ${KERNEL_MODPUBKEY}
+ die Invalid KERNEL_MODPUBKEY
+ fi
+
+ return 0
+}
+
# internal function
#
# FUNCTION: update_depmod
@@ -581,6 +608,10 @@
return
fi
+ if use module-signing; then
+ CONFIG_CHECK+=${CONFIG_CHECK} MODULE_SIG
+ fi
+
linux-info_pkg_setup;
require_configured_kernel
check_kernel_built;
@@ -710,6 +741,12 @@
srcdir=${srcdir:-${S}}
objdir=${objdir:-${srcdir}}
+ if check_module_signing; then
+ ebegin Signing module ${modulename}
+ ${KV_DIR}/scripts/sign-file ${KERNEL_MODSECKEY} ${KERNEL_MODPUBKEY}
${objdir}/${modulename}.${KV_OBJ}
+ eend $?
+ fi
+
einfo Installing ${modulename} module
cd ${objdir} || die ${objdir} does not exist
insinto /lib/modules/${KV_FULL}/${libdir}
[gentoo-dev] rfc: patch systemd.eclass to use pkg-config if available
All,
systemd, like udev, stores directory paths in a way that they can be
queried from pkg-config. However, the systemd.eclass currently does not
use this ability.
The following patch models the systemd eclass after the udev eclass and
leaves the current defaults in place if there is an issue with
pkg-config.
Any thoughts?
William
Index: eclass/systemd.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/systemd.eclass,v
retrieving revision 1.21
diff -u -b -B -r1.21 systemd.eclass
--- eclass/systemd.eclass 31 Dec 2012 13:09:09 - 1.21
+++ eclass/systemd.eclass 11 Mar 2013 21:04:16 -
@@ -25,17 +25,25 @@
# }
# @CODE
+inherit toolchain-funcs
+
case ${EAPI:-0} in
0|1|2|3|4|5) ;;
*) die ${ECLASS}.eclass API in EAPI ${EAPI} not yet established.
esac
+DEPEND=virtual/pkgconfig
+
# @FUNCTION: _systemd_get_unitdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed unitdir.
_systemd_get_unitdir() {
+ if $($(tc-getPKG_CONFIG) --exists systemd); then
+ echo $($(tc-getPKG_CONFIG) --variable=systemdsystemunitdir systemd)
+ else
echo /usr/lib/systemd/system
+ fi
}
# @FUNCTION: systemd_get_unitdir
@@ -49,6 +57,18 @@
echo ${EPREFIX}$(_systemd_get_unitdir)
}
+# @FUNCTION: _systemd_get_userunitdir
+# @INTERNAL
+# @DESCRIPTION:
+# Get unprefixed userunitdir.
+_systemd_get_userunitdir() {
+ if $($(tc-getPKG_CONFIG) --exists systemd); then
+ echo $($(tc-getPKG_CONFIG) --variable=systemduserunitdir systemd)
+ else
+ echo /usr/lib/systemd/user
+ fi
+}
+
# @FUNCTION: systemd_get_userunitdir
# @DESCRIPTION:
# Output the path for the systemd user unit directory (not including
@@ -58,7 +78,19 @@
has ${EAPI:-0} 0 1 2 ! use prefix EPREFIX=
debug-print-function ${FUNCNAME} ${@}
- echo ${EPREFIX}/usr/lib/systemd/user
+ echo ${EPREFIX}$(_systemd_get_userunitdir)
+}
+
+# @FUNCTION: _systemd_get_utildir
+# @INTERNAL
+# @DESCRIPTION:
+# Get unprefixed utildir.
+_systemd_get_utildir() {
+ if $($(tc-getPKG_CONFIG) --exists systemd); then
+ echo $($(tc-getPKG_CONFIG) --variable=systemdutildir systemd)
+ else
+ echo /usr/lib/systemd
+ fi
}
# @FUNCTION: systemd_get_utildir
@@ -70,7 +102,7 @@
has ${EAPI:-0} 0 1 2 ! use prefix EPREFIX=
debug-print-function ${FUNCNAME} ${@}
- echo ${EPREFIX}/usr/lib/systemd
+ echo ${EPREFIX}$(_systemd_get_utildir)
}
# @FUNCTION: systemd_dounit
pgpU_JKC54Iqy.pgp
Description: PGP signature
[gentoo-dev] Re: Forming Gentoo Policy - Copyright Assignment and Attribution
On Mon, Mar 11, 2013 at 04:51:17PM -0400, Rich Freeman wrote: If you have any concerns/objections to the policy which was outlined, which includes a mandatory requirement to sign a contributor license agreement and an option to also sign an assignment-like document based on the FSFe FLA, please speak up this week. I've already said this before, but I guess I need to say it again: If a contributor license is required to be signed, I'll have to stop contributing to Gentoo. Other developers will be also affected, and you will find it hard to attract new developers who happen to work for companies that forbid their employees to sign these types of things (a _very_ common thing in the US, I have yet to work for a company in the past 20+ years that would have allowed this without going through the company's legal council for approval, a usually very difficult thing to achieve for a single developer.) I was here when the copyright assignment form was dropped due to all of the problems it was causing new developers (myself included.) Have you somehow figured out how to handle all of the issues that were raised 8+ years ago with the old assignment we had? Is there really no one around now (other than myself) that had to deal with that mess in the past? History, forgetting it, doomed. sadly, greg k-h
Re: [gentoo-dev] rfc: patch systemd.eclass to use pkg-config if available
On Mon, Mar 11, 2013 at 5:18 PM, William Hubbs willi...@gentoo.org wrote: All, systemd, like udev, stores directory paths in a way that they can be queried from pkg-config. However, the systemd.eclass currently does not use this ability. The following patch models the systemd eclass after the udev eclass and leaves the current defaults in place if there is an issue with pkg-config. Any thoughts? William What problem are you trying to solve here? We already know the values that pkg-config will return, so I fail to see the advantage of calling pkg-config in the eclass. If we were to move the /usr/lib/systemd directory between two versions of systemd, then yes, using pkg-config would be helpful. Until/unless such a change occurs, I just don't see the point.
Re: [gentoo-dev] Re: Forming Gentoo Policy - Copyright Assignment and Attribution
On Monday 11 of March 2013 14:19:55 Greg KH wrote: On Mon, Mar 11, 2013 at 04:51:17PM -0400, Rich Freeman wrote: If you have any concerns/objections to the policy which was outlined, which includes a mandatory requirement to sign a contributor license agreement and an option to also sign an assignment-like document based on the FSFe FLA, please speak up this week. I've already said this before, but I guess I need to say it again: If a contributor license is required to be signed, I'll have to stop contributing to Gentoo. Other developers will be also affected, and you will find it hard to attract new developers who happen to work for companies that forbid their employees to sign these types of things (a _very_ common thing in the US, I have yet to work for a company in the past 20+ years that would have allowed this without going through the company's legal council for approval, a usually very difficult thing to achieve for a single developer.) I was here when the copyright assignment form was dropped due to all of the problems it was causing new developers (myself included.) Have you somehow figured out how to handle all of the issues that were raised 8+ years ago with the old assignment we had? Is there really no one around now (other than myself) that had to deal with that mess in the past? History, forgetting it, doomed. sadly, greg k-h I'm not having any personal issue here, but I'm with Greg here, since this action means loosing any single contributor. We're a project ran by volunteers, we get more retirements than additions lately, and we can't even afford loosing anybody. -1 from me as well. Theo signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Forming Gentoo Policy - Copyright Assignment and Attribution
On Mon, Mar 11, 2013 at 02:19:55PM -0700, Greg KH wrote: On Mon, Mar 11, 2013 at 04:51:17PM -0400, Rich Freeman wrote: If you have any concerns/objections to the policy which was outlined, which includes a mandatory requirement to sign a contributor license agreement and an option to also sign an assignment-like document based on the FSFe FLA, please speak up this week. I've already said this before, but I guess I need to say it again: If a contributor license is required to be signed, I'll have to stop contributing to Gentoo. Did you read the entire email? We explicitly listed one of the options as (voluntary FLA/CLA AND mandatory DCO). Could you clarify that you're objecting to that as well? In your case, you could elect NOT to sign the FLA/CLA. Regardless, all of your commits would have the DCO SoB signature. The kernel is where we got the mandatory DCO concept. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] rfc: patch systemd.eclass to use pkg-config if available
On Mon, Mar 11, 2013 at 05:37:12PM -0400, Mike Gilbert wrote: On Mon, Mar 11, 2013 at 5:18 PM, William Hubbs willi...@gentoo.org wrote: All, systemd, like udev, stores directory paths in a way that they can be queried from pkg-config. However, the systemd.eclass currently does not use this ability. The following patch models the systemd eclass after the udev eclass and leaves the current defaults in place if there is an issue with pkg-config. Any thoughts? William What problem are you trying to solve here? We already know the values that pkg-config will return, so I fail to see the advantage of calling pkg-config in the eclass. If we were to move the /usr/lib/systemd directory between two versions of systemd, then yes, using pkg-config would be helpful. Until/unless such a change occurs, I just don't see the point. The reason for this is a topic that Samuli and I want to discuss with the systemd team, probably on irc, but, basically, since gentoo does not have the /usr merge, we think parts of systemd which are in /usr should go in /, and this goes along with systemd upstream's recommendations as well (look at how the autogen.sh script in the systemd git repo works to see what I'm talking about). This would also allow udev and systemd to share the /lib/systemd directory, and we could install compatibility symlinks where necessary to not break users' systems. William pgpD09YVTySll.pgp Description: PGP signature
[gentoo-dev] Re: Forming Gentoo Policy - Copyright Assignment and Attribution
On Mar 11, 2013 6:22 PM, Robin H. Johnson robb...@gentoo.org wrote: On Mon, Mar 11, 2013 at 02:19:55PM -0700, Greg KH wrote: On Mon, Mar 11, 2013 at 04:51:17PM -0400, Rich Freeman wrote: If you have any concerns/objections to the policy which was outlined, which includes a mandatory requirement to sign a contributor license agreement and an option to also sign an assignment-like document based on the FSFe FLA, please speak up this week. I've already said this before, but I guess I need to say it again: If a contributor license is required to be signed, I'll have to stop contributing to Gentoo. Did you read the entire email? We explicitly listed one of the options as (voluntary FLA/CLA AND mandatory DCO). Could you clarify that you're objecting to that as well? In your case, you could elect NOT to sign the FLA/CLA. Regardless, all of your commits would have the DCO SoB signature. The kernel is where we got the mandatory DCO concept. This one is my bad. I wrote CLA when I meant DCO. No change intended. This is what happens when you send a thirty second follow-up to a policy formed over two weeks, and then step away to eat... But, at least we know people read it! Rich
Re: [gentoo-dev] rfc: patch systemd.eclass to use pkg-config if available
On Mon, 11 Mar 2013 17:28:08 -0500 William Hubbs willi...@gentoo.org wrote: On Mon, Mar 11, 2013 at 05:37:12PM -0400, Mike Gilbert wrote: On Mon, Mar 11, 2013 at 5:18 PM, William Hubbs willi...@gentoo.org wrote: All, systemd, like udev, stores directory paths in a way that they can be queried from pkg-config. However, the systemd.eclass currently does not use this ability. The following patch models the systemd eclass after the udev eclass and leaves the current defaults in place if there is an issue with pkg-config. Any thoughts? William What problem are you trying to solve here? We already know the values that pkg-config will return, so I fail to see the advantage of calling pkg-config in the eclass. If we were to move the /usr/lib/systemd directory between two versions of systemd, then yes, using pkg-config would be helpful. Until/unless such a change occurs, I just don't see the point. The reason for this is a topic that Samuli and I want to discuss with the systemd team, probably on irc, but, basically, since gentoo does not have the /usr merge, we think parts of systemd which are in /usr should go in /, and this goes along with systemd upstream's recommendations as well (look at how the autogen.sh script in the systemd git repo works to see what I'm talking about). This would also allow udev and systemd to share the /lib/systemd directory, and we could install compatibility symlinks where necessary to not break users' systems. No. And I don't have the time to repeat that discussion again. Just no. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: patch systemd.eclass to use pkg-config if available
On Mon, Mar 11, 2013 at 11:47:47PM +0100, Michał Górny wrote: On Mon, 11 Mar 2013 17:28:08 -0500 William Hubbs willi...@gentoo.org wrote: On Mon, Mar 11, 2013 at 05:37:12PM -0400, Mike Gilbert wrote: On Mon, Mar 11, 2013 at 5:18 PM, William Hubbs willi...@gentoo.org wrote: All, systemd, like udev, stores directory paths in a way that they can be queried from pkg-config. However, the systemd.eclass currently does not use this ability. The following patch models the systemd eclass after the udev eclass and leaves the current defaults in place if there is an issue with pkg-config. Any thoughts? William What problem are you trying to solve here? We already know the values that pkg-config will return, so I fail to see the advantage of calling pkg-config in the eclass. If we were to move the /usr/lib/systemd directory between two versions of systemd, then yes, using pkg-config would be helpful. Until/unless such a change occurs, I just don't see the point. The reason for this is a topic that Samuli and I want to discuss with the systemd team, probably on irc, but, basically, since gentoo does not have the /usr merge, we think parts of systemd which are in /usr should go in /, and this goes along with systemd upstream's recommendations as well (look at how the autogen.sh script in the systemd git repo works to see what I'm talking about). This would also allow udev and systemd to share the /lib/systemd directory, and we could install compatibility symlinks where necessary to not break users' systems. No. And I don't have the time to repeat that discussion again. Just no. This was also the extent of your objections when I did bring it up to you informally before. It would really help if you would explain your position. Thanks, William pgp7QC1R1GFOf.pgp Description: PGP signature
[gentoo-dev] Re: Forming Gentoo Policy - Copyright Assignment and Attribution
On Mon, Mar 11, 2013 at 6:40 PM, Rich Freeman ri...@gentoo.org wrote: No change intended. This is what happens when you send a thirty second follow-up to a policy formed over two weeks, and then step away to eat... So, clarification now that I'm back at a keyboard... DCO is mandatory, and is simply a declaration that the committer has checked and the new code is distributed under the license chosen for the project (see original email for details, but generally GPL/BSD/etc). The Linux kernel is the main model for this. Since Gentoo is not always being assigned copyright we need to have a clear declaration that the code is available under a suitable free license so that we can further distribute it. FLA is optional, and is essentially a copyright assignment (or reasonable facsimile in certain jurisdictions designed by the FSFe). KDE is the main model for this. But, to whatever extent that anything I just wrote disagrees with the original email, just read the original email. The original email was carefully proofread by the Trustees, the rest is just discussion/reminders/etc. The final policy will be even more carefully reviewed. The whole bit about mandatory copyright assignment was dropped after the last round of discussion for all the reasons that have just been rehashed... Rich
Re: [gentoo-dev] Re: Forming Gentoo Policy - Copyright Assignment and Attribution
On Mon, Mar 11, 2013 at 07:12:43PM -0400, Rich Freeman wrote: On Mon, Mar 11, 2013 at 6:40 PM, Rich Freeman ri...@gentoo.org wrote: No change intended. This is what happens when you send a thirty second follow-up to a policy formed over two weeks, and then step away to eat... So, clarification now that I'm back at a keyboard... DCO is mandatory, and is simply a declaration that the committer has checked and the new code is distributed under the license chosen for the project (see original email for details, but generally GPL/BSD/etc). The Linux kernel is the main model for this. Since Gentoo is not always being assigned copyright we need to have a clear declaration that the code is available under a suitable free license so that we can further distribute it. FLA is optional, and is essentially a copyright assignment (or reasonable facsimile in certain jurisdictions designed by the FSFe). KDE is the main model for this. But, to whatever extent that anything I just wrote disagrees with the original email, just read the original email. The original email was carefully proofread by the Trustees, the rest is just discussion/reminders/etc. The final policy will be even more carefully reviewed. The whole bit about mandatory copyright assignment was dropped after the last round of discussion for all the reasons that have just been rehashed... Ok, good, that's why I didn't object to the first email, only to this one which seemed to say something else, so I assumed it was I who misread the first version. Nevermind then, sorry for the noise :) greg k-h
