Re: [gentoo-dev] Packages up for grabs due lack of time
On 13:46 Sun 03 Feb 2013, Pacho Ramos wrote: Due matsuu lack of time the following packages are up for grabs: dev-cpp/gtest I'll take this one. Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/ signature.asc Description: Digital signature
Re: [gentoo-dev] [PATCH 2/3] Introduce cmake-multilib wrapper for cmake-utils.
On Tue, 5 Feb 2013 22:32:59 -0300
Alexis Ballier aball...@gentoo.org wrote:
On Tue, 5 Feb 2013 21:19:23 +0100
Michał Górny mgo...@gentoo.org wrote:
+cmake-multilib_src_install() {
+ cmake-multilib_secure_install() {
+ cmake-utils_src_install
+
+ # Make sure all headers are the same for each ABI.
+ cmake-multilib_cksum() {
+ find ${ED}usr/include -type f \
+ -exec cksum {} + | sort -k2
+ }
+
+ local cksum=$(cmake-multilib_cksum)
+ local cksum_file=${T}/.cmake-multilib_cksum
+
+ if [[ -f ${cksum_file} ]]; then
+ local cksum_prev=$( ${cksum_file})
+
+ if [[ ${cksum} != ${cksum_prev} ]]; then
+ echo ${cksum} ${cksum_file}.new
+
+ eerror Header files have changed
between ABIs. +
+ if type -p diff /dev/null; then
+ eerror $(diff -du
${cksum_file} ${cksum_file}.new)
+ else
+ eerror Old checksums in:
${cksum_file}
+ eerror New checksums in:
${cksum_file}.new
+ fi
+
+ die Header checksum mismatch,
aborting.
+ fi
+ else
+ echo ${cksum} ${cksum_file}
+ fi
+ }
The eclass uses the same header consistency check as
autotools-multilib
(therefore, I move the function to multilib-build).
You probably forgot to use it here
lolcorrect.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH] Convert virtualgl to cmake-multilib.
---
...algl-2.3.2.ebuild = virtualgl-2.3.2-r1.ebuild} | 77 +-
1 file changed, 17 insertions(+), 60 deletions(-)
copy gx86/x11-misc/virtualgl/{virtualgl-2.3.2.ebuild =
virtualgl-2.3.2-r1.ebuild} (52%)
diff --git a/gx86/x11-misc/virtualgl/virtualgl-2.3.2.ebuild
b/gx86/x11-misc/virtualgl/virtualgl-2.3.2-r1.ebuild
similarity index 52%
copy from gx86/x11-misc/virtualgl/virtualgl-2.3.2.ebuild
copy to gx86/x11-misc/virtualgl/virtualgl-2.3.2-r1.ebuild
index bd3d565..9e00995 100644
--- a/gx86/x11-misc/virtualgl/virtualgl-2.3.2.ebuild
+++ b/gx86/x11-misc/virtualgl/virtualgl-2.3.2-r1.ebuild
@@ -2,8 +2,8 @@
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/x11-misc/virtualgl/virtualgl-2.3.2.ebuild,v
1.3 2013/02/05 17:38:27 pacho Exp $
-EAPI=4
-inherit cmake-utils multilib
+EAPI=5
+inherit cmake-multilib multilib
DESCRIPTION=Run OpenGL applications remotely with full 3D hardware
acceleration
HOMEPAGE=http://www.virtualgl.org/;
@@ -16,14 +16,14 @@
SRC_URI=mirror://sourceforge/${PN}/${MY_PN}/${PV}/${MY_P}.tar.gz
SLOT=0
LICENSE=LGPL-2.1 wxWinLL-3.1 FLTK
KEYWORDS=~amd64 ~x86
-IUSE=multilib ssl
+IUSE=ssl
RDEPEND=ssl? ( dev-libs/openssl )
media-libs/libjpeg-turbo
x11-libs/libX11
x11-libs/libXext
x11-libs/libXv
- multilib? ( app-emulation/emul-linux-x86-xlibs
+ abi_x86_32? ( app-emulation/emul-linux-x86-xlibs
app-emulation/emul-linux-x86-baselibs
app-emulation/emul-linux-x86-opengl )
virtual/glu
@@ -31,7 +31,6 @@ RDEPEND=ssl? ( dev-libs/openssl )
DEPEND=${RDEPEND}
CMAKE_VERBOSE=1
-build32_dir=${WORKDIR}/${P}_build32
src_prepare() {
# Use /var/lib, bug #428122
@@ -42,69 +41,27 @@ src_prepare() {
}
src_configure() {
- # Configure 32bit version on multilib
- use amd64 use multilib (
- einfo Configuring 32bit libs...
-
- local ABI=x86
- local CFLAGS=${CFLAGS--O2 -march=native -pipe} -m32
- local CXXFLAGS=${CFLAGS}
- local LDFLAGS=${LDFLAGS} -m32
- local BUILD_DIR=${build32_dir}
+ local mycmakeargs=(
+ $(cmake-utils_use ssl VGL_USESSL)
+ -DVGL_DOCDIR=/usr/share/doc/${PF}
+ -DTJPEG_INCLUDE_DIR=/usr/include
+ )
- mycmakeargs=(
- $(cmake-utils_use ssl VGL_USESSL)
- -DVGL_DOCDIR=/usr/share/doc/${P}
+ abi_configure() {
+ local mycmakeargs=(
+ ${mycmakeargs[@]}
-DVGL_LIBDIR=/usr/$(get_libdir)
- -DTJPEG_INCLUDE_DIR=/usr/include
-DTJPEG_LIBRARY=/usr/$(get_libdir)/libturbojpeg.so
- -DCMAKE_LIBRARY_PATH=/usr/lib32
- -DVGL_FAKELIBDIR=/usr/fakelib/32
+ -DCMAKE_LIBRARY_PATH=/usr/$(get_libdir)
+ -DVGL_FAKELIBDIR=/usr/fakelib/${ABI}
)
cmake-utils_src_configure
-
- einfo Configuring 64bit libs...
- )
-
- # Configure native version
- mycmakeargs=(
- $(cmake-utils_use ssl VGL_USESSL)
- -DVGL_DOCDIR=/usr/share/doc/${P}
- -DVGL_LIBDIR=/usr/$(get_libdir)
- -DTJPEG_INCLUDE_DIR=/usr/include
- -DTJPEG_LIBRARY=/usr/$(get_libdir)/libturbojpeg.so
- -DCMAKE_LIBRARY_PATH=/usr/lib64
- -DVGL_FAKELIBDIR=/usr/fakelib/64
- )
- cmake-utils_src_configure
-}
-
-src_compile() {
- # Make 32bit version on multilib
- use amd64 use multilib (
- einfo Building 32bit libs...
- local BUILD_DIR=${build32_dir}
- cmake-utils_src_compile
-
- einfo Building 64bit libs...
- )
-
- # Make native version
- cmake-utils_src_compile
+ }
+ multilib_parallel_foreach_abi abi_configure
}
src_install() {
- # Install 32bit version on multilib
- use amd64 use multilib (
- einfo Installing 32bit libs...
- local BUILD_DIR=${build32_dir}
- cmake-utils_src_install
-
- einfo Installing 64bit libs...
- )
-
- # Install native version
- cmake-utils_src_install
+ cmake-multilib_src_install
# Make config dir
dodir /var/lib/VirtualGL
--
1.8.1.2
Re: [gentoo-dev] Packages up for grabs due lack of time
On Mon, 04 Feb 2013 09:16:32 +0800 Patrick Lauer patr...@gentoo.org wrote: On 02/03/2013 09:45 PM, Ralph Sennhauser wrote: On Sun, 03 Feb 2013 13:46:52 +0100 Pacho Ramos pa...@gentoo.org wrote: dev-libs/boehm-gc Will take this one in a few days if no one else grabs it first. Since it's a dependency of one package I maintain (dev-lang/opendylan) I have a marginal interest in keeping it around. Feel free to add me to metadata too if I forget. Added both of us. signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs due lack of time
Hi ALL: I'd like to help with following packages (will proxy via tomka) dev-libs/libev which I see one open bug, but trivial to fix #429526https://bugs.gentoo.org/show_bug.cgi?id=429526 net-misc/ofono need version bump (current 1.10, upstream release 1.12) If any developer willing to help, would be great! ~ and feel free to touch the ebuilds which I maintain Dennis On Wed, Feb 6, 2013 at 4:29 PM, Thomas Kahle to...@gentoo.org wrote: On 13:46 Sun 03 Feb 2013, Pacho Ramos wrote: Due matsuu lack of time the following packages are up for grabs: dev-cpp/gtest I'll take this one. Cheers, Thomas -- Thomas Kahle http://dev.gentoo.org/~tomka/
[gentoo-dev] /var/run or /run for init scripts?
Hi all, I see a lot of inconsistencies in the init scripts. Some of them are using /var/run, others use /run. I just checked my box, and there is no /var/run although some init scripts are trying to use it. Which one is the correct one and why do we have both? The following guide only mentions /var/run http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2chap=4 -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] /var/run or /run for init scripts?
On 06/02/2013 14:52, Markos Chandras wrote: I see a lot of inconsistencies in the init scripts. Some of them are using /var/run, others use /run. I just checked my box, and there is no /var/run although some init scripts are trying to use it. Which one is the correct one and why do we have both? The following guide only mentions /var/run We should be migrating to /run at this point. http://goo.gl/hrWcN -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] /var/run or /run for init scripts?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/02/13 08:55 AM, Diego Elio Pettenò wrote: On 06/02/2013 14:52, Markos Chandras wrote: I see a lot of inconsistencies in the init scripts. Some of them are using /var/run, others use /run. I just checked my box, and there is no /var/run although some init scripts are trying to use it. Which one is the correct one and why do we have both? The following guide only mentions /var/run We should be migrating to /run at this point. http://goo.gl/hrWcN I had thought /var/run was supposed to be compatibility a symlink to /run now ? Is that the case or should /var/run be eliminated from systems? (I realize this is a tangent to the original post) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlESYUIACgkQ2ugaI38ACPBUyQEArLfQfeUnW510aizYrjlHcGRl fjHoZOnHdC10O2Sam6UBALOedX+jKZb5wig4xI/l6lEtFOUVOLNcPU69kk3cpEsU =aueY -END PGP SIGNATURE-
Re: [gentoo-dev] /var/run or /run for init scripts?
On 6 February 2013 13:55, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 06/02/2013 14:52, Markos Chandras wrote: I see a lot of inconsistencies in the init scripts. Some of them are using /var/run, others use /run. I just checked my box, and there is no /var/run although some init scripts are trying to use it. Which one is the correct one and why do we have both? The following guide only mentions /var/run We should be migrating to /run at this point. http://goo.gl/hrWcN -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ Thanks. Would it made sense to symlink /var/run - /run so we don't end up with stable entries in /var/run directory? Some of my init scripts appear to reported as crashed whereas the process is running just fine. I suspect this is because a stale entry is in /var/run directory (or /run I am not sure) -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] [PATCH] Convert virtualgl to cmake-multilib.
On Wed, 6 Feb 2013 11:07:21 +0100 Michał Górny mgo...@gentoo.org wrote: RDEPEND=ssl? ( dev-libs/openssl ) media-libs/libjpeg-turbo x11-libs/libX11 x11-libs/libXext x11-libs/libXv - multilib? ( app-emulation/emul-linux-x86-xlibs + abi_x86_32? ( app-emulation/emul-linux-x86-xlibs app-emulation/emul-linux-x86-baselibs app-emulation/emul-linux-x86-opengl ) again, this will pull in emul libs on x86 there are only two options: convert its deps to multilib before committing or protect the emul libs dep by amd64? () meanwhile
Re: [gentoo-dev] /var/run or /run for init scripts?
On 06/02/2013 14:58, Markos Chandras wrote: Thanks. Would it made sense to symlink /var/run - /run so we don't end up with stable entries in /var/run directory? Some of my init scripts appear to reported as crashed whereas the process is running just fine. I suspect this is because a stale entry is in /var/run directory (or /run I am not sure) I would say that we should have that symlink, and I told WilliamH so before. I think he was going to ask Mike (vapier) about adding the symlink to baselayout itself, so that it doesn't get reaped away. I agree that the symlink should stay there for compatibility at least, which should also answer Ian's question. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [PATCH] Convert virtualgl to cmake-multilib.
On Wed, 6 Feb 2013 11:02:35 -0300 Alexis Ballier aball...@gentoo.org wrote: On Wed, 6 Feb 2013 11:07:21 +0100 Michał Górny mgo...@gentoo.org wrote: RDEPEND=ssl? ( dev-libs/openssl ) media-libs/libjpeg-turbo x11-libs/libX11 x11-libs/libXext x11-libs/libXv - multilib? ( app-emulation/emul-linux-x86-xlibs + abi_x86_32? ( app-emulation/emul-linux-x86-xlibs app-emulation/emul-linux-x86-baselibs app-emulation/emul-linux-x86-opengl ) again, this will pull in emul libs on x86 there are only two options: convert its deps to multilib before committing or protect the emul libs dep by amd64? () meanwhile Ah, sorry, I didn't understand you properly the first time. I agree that 'amd64?' is necessary too. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] The /run migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/02/13 09:02 AM, Diego Elio Pettenò wrote: On 06/02/2013 14:58, Markos Chandras wrote: Thanks. Would it made sense to symlink /var/run - /run so we don't end up with stable entries in /var/run directory? Some of my init scripts appear to reported as crashed whereas the process is running just fine. I suspect this is because a stale entry is in /var/run directory (or /run I am not sure) I would say that we should have that symlink, and I told WilliamH so before. I think he was going to ask Mike (vapier) about adding the symlink to baselayout itself, so that it doesn't get reaped away. I agree that the symlink should stay there for compatibility at least, which should also answer Ian's question. OK - so I've noticed some issues with the way the /run migration has gone down; it seems that a lot of systems do not have a consistent migration and as I don't remember (and my initial look couldn't find) the details for its implementation, I'm hoping someone can chime in and (A) describe the process as it is supposed to work, and (B) point out where it's implemented so that this implementation can be adjusted (or how it's been adjusted can be reviewed) to get everyone's system to a consistent state. Normally i'd just ask WilliamH on irc, but since this is more of a forensic discussion i thought it better to do it here.. So, *my* systems do have /var/run - /run , which means at some point the /run migration did happen and compatibility symlinks were created. If hwoarang's systems don't have this, there must be an issue somewhere. Now, with /run migration itself -- WilliamH and I discussed this issue where /run (when the initial change was to be made if upgrading to openrc-0.11.x) would always have a symlink to /lib/something/openrc/ in the directory itself (that is, underneath the tmpfs mount). However when I investigated, I discovered that two of my systems had actual dead directories and temp files in /run (and no symlink). Code has been added to /etc/init.d/bootmisc to clean out anything in /run underneath the tmpfs, but it might be pertinent to figure out why this happened in the first place, as it might be related to why the /var/run symlink might not have been created (and relate to other inconsistencies we haven't found yet). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF0EAREIAAYFAlESZhsACgkQ2ugaI38ACPC9UgD/c0orcDKEHWpuneSI9ZZ3ZuYo QwQZipdv/bryXly1Ek8A+KrameA53aeF4srZywxS+vjCucIkcS3Rm9x3Yq0O700= =x0lk -END PGP SIGNATURE-
Re: [gentoo-dev] The /run migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/02/13 09:18 AM, Ian Stakenvicius wrote: On 06/02/13 09:02 AM, Diego Elio Pettenò wrote: On 06/02/2013 14:58, Markos Chandras wrote: Thanks. Would it made sense to symlink /var/run - /run so we don't end up with stable entries in /var/run directory? Some of my init scripts appear to reported as crashed whereas the process is running just fine. I suspect this is because a stale entry is in /var/run directory (or /run I am not sure) I would say that we should have that symlink, and I told WilliamH so before. I think he was going to ask Mike (vapier) about adding the symlink to baselayout itself, so that it doesn't get reaped away. I agree that the symlink should stay there for compatibility at least, which should also answer Ian's question. OK - so I've noticed some issues with the way the /run migration has gone down; it seems that a lot of systems do not have a consistent migration and as I don't remember (and my initial look couldn't find) the details for its implementation, I'm hoping someone can chime in and (A) describe the process as it is supposed to work, and (B) point out where it's implemented so that this implementation can be adjusted (or how it's been adjusted can be reviewed) to get everyone's system to a consistent state. Normally i'd just ask WilliamH on irc, but since this is more of a forensic discussion i thought it better to do it here.. So, *my* systems do have /var/run - /run , which means at some point the /run migration did happen and compatibility symlinks were created. If hwoarang's systems don't have this, there must be an issue somewhere. Now, with /run migration itself -- WilliamH and I discussed this issue where /run (when the initial change was to be made if upgrading to openrc-0.11.x) would always have a symlink to /lib/something/openrc/ in the directory itself (that is, underneath the tmpfs mount). However when I investigated, I discovered that two of my systems had actual dead directories and temp files in /run (and no symlink). Code has been added to /etc/init.d/bootmisc to clean out anything in /run underneath the tmpfs, but it might be pertinent to figure out why this happened in the first place, as it might be related to why the /var/run symlink might not have been created (and relate to other inconsistencies we haven't found yet). As a follow up -- there are probably two cases to look at; #1 are stable-only users (so just what happens when the stable bumps occurred), and #2 are ~arch users and/or ~arch keyworders. I'm going to guess that the majority of inconsistencies with the planned results will come from #2 as the different implementations of /run migration would have taken place differently with each ~arch bump depending on who installed what when.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlESZy8ACgkQ2ugaI38ACPDtpAD+N8OuOAL44dwCL2EE72IzGuxX Bmz9YFagyEqauI2da5UA/RIAfpPDdd0of0LDxH1T/9C5stnbovzlRqnQCKi66e+1 =SWm7 -END PGP SIGNATURE-
Re: [gentoo-dev] The /run migration
On 6 February 2013 14:18, Ian Stakenvicius a...@gentoo.org wrote: So, *my* systems do have /var/run - /run , which means at some point the /run migration did happen and compatibility symlinks were created. If hwoarang's systems don't have this, there must be an issue somewhere. My system is a brand new ~testing installation with a stage3-amd64-20130110.tar.bz2. I am not sure who is responsible for creating this symlink. I see the symlink is present on that stage3 tarball so somehow it must have been removed from my system. Even if it was a user error, then shouldn't there be a mechanism of recreating it on every boot if it's gone missing? At least until all init scripts migrate to /run. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] The /run migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/02/13 09:53 AM, Markos Chandras wrote: On 6 February 2013 14:18, Ian Stakenvicius a...@gentoo.org wrote: So, *my* systems do have /var/run - /run , which means at some point the /run migration did happen and compatibility symlinks were created. If hwoarang's systems don't have this, there must be an issue somewhere. My system is a brand new ~testing installation with a stage3-amd64-20130110.tar.bz2. I am not sure who is responsible for creating this symlink. I see the symlink is present on that stage3 tarball so somehow it must have been removed from my system. Even if it was a user error, then shouldn't there be a mechanism of recreating it on every boot if it's gone missing? At least until all init scripts migrate to /run. ..there was a discussion a week or two back about portage cleaning up symlinks, or something that needs to be done to keep portage warning about symlinks, or something. Anyways, I'm wondering if a change was made related to that and for whatever reason portage is now cleaning /var/run -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlEScMgACgkQ2ugaI38ACPAl7wEAj/n6Euiq/8gNn2tb8LjdJB7E 07yk78xCMZJudAHI/NEA/jHR5BoQIHZu2Tm5PRBN3BiK3Fe1miak3Z4UGVuSRudx =j+bI -END PGP SIGNATURE-
Re: [gentoo-dev] The /run migration
On Wed, Feb 6, 2013 at 10:03 AM, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/02/13 09:53 AM, Markos Chandras wrote: On 6 February 2013 14:18, Ian Stakenvicius a...@gentoo.org wrote: So, *my* systems do have /var/run - /run , which means at some point the /run migration did happen and compatibility symlinks were created. If hwoarang's systems don't have this, there must be an issue somewhere. My system is a brand new ~testing installation with a stage3-amd64-20130110.tar.bz2. I am not sure who is responsible for creating this symlink. I see the symlink is present on that stage3 tarball so somehow it must have been removed from my system. Even if it was a user error, then shouldn't there be a mechanism of recreating it on every boot if it's gone missing? At least until all init scripts migrate to /run. ..there was a discussion a week or two back about portage cleaning up symlinks, or something that needs to be done to keep portage warning about symlinks, or something. Anyways, I'm wondering if a change was made related to that and for whatever reason portage is now cleaning /var/run Portage will cleanup the /var/run symlink after unmerging the last package that installed files under /var/run. I think an early init script (bootmisc?) needs to create the /var/run symlink if it is missing.
Re: [gentoo-dev] The /run migration
On Wed, Feb 06, 2013 at 10:23:06AM -0500, Mike Gilbert wrote: On Wed, Feb 6, 2013 at 10:03 AM, Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/02/13 09:53 AM, Markos Chandras wrote: On 6 February 2013 14:18, Ian Stakenvicius a...@gentoo.org wrote: So, *my* systems do have /var/run - /run , which means at some point the /run migration did happen and compatibility symlinks were created. If hwoarang's systems don't have this, there must be an issue somewhere. My system is a brand new ~testing installation with a stage3-amd64-20130110.tar.bz2. I am not sure who is responsible for creating this symlink. I see the symlink is present on that stage3 tarball so somehow it must have been removed from my system. Even if it was a user error, then shouldn't there be a mechanism of recreating it on every boot if it's gone missing? At least until all init scripts migrate to /run. ..there was a discussion a week or two back about portage cleaning up symlinks, or something that needs to be done to keep portage warning about symlinks, or something. Anyways, I'm wondering if a change was made related to that and for whatever reason portage is now cleaning /var/run Portage will cleanup the /var/run symlink after unmerging the last package that installed files under /var/run. I think an early init script (bootmisc?) needs to create the /var/run symlink if it is missing. The only problem with this approach is it doesn't solve the issue for people who are not using OpenRc. William pgpk27MyEyA_Y.pgp Description: PGP signature
Re: [gentoo-dev] The /run migration
On Wed, Feb 06, 2013 at 10:23:06AM -0500, Mike Gilbert wrote: Portage will cleanup the /var/run symlink after unmerging the last package that installed files under /var/run. And if you install back that package, portage will create the /var/run directory, and not the symlink. openssh-6.1_p1 has: keepdir /var/run -- Cyprien Nicolas (Fulax) Gentoo Lisp project contrib signature.asc Description: Digital signature
Re: [gentoo-dev] Porting ZFS to additional architectures
On Tue, Feb 5, 2013 at 11:25 AM, Richard Yao r...@gentoo.org wrote: Dear Everyone, Does anyone have root access to Linux systems on any of the following architectures that is willing to help ZFS development? Alpha HPPA IA-64 MIPS/MIPS64 PPC/PPC64 SH SPARC/SPARC64 http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml -A I want to port ZFSOnLinux to all Gentoo Linux architectures this year. The above architectures either are not currently supported or have not been tested in a while. Most of them will require patching isa_defs.h, which I am in a position to do. I am not distributing the patches because I don't know if ZFS will build on those platforms. People willing (and able) to help should email me with their architecture and distribution. Gentoo Linux is preferred, but not required. No knowledge of programming is required. I will provide you with instructions on how to build and test ZFS on your architecture. Yours truly, Richard Yao
Re: [gentoo-dev] Porting ZFS to additional architectures
On 02/06/2013 02:12 AM, Sergei Trofimovich wrote: On Tue, 05 Feb 2013 14:25:56 -0500 Richard Yao r...@gentoo.org wrote: I want to port ZFSOnLinux to all Gentoo Linux architectures this year. The above architectures either are not currently supported or have not been tested in a while. Most of them will require patching isa_defs.h, which I am in a position to do. I am not distributing the patches because I don't know if ZFS will build on those platforms. Try to use crossdev to make sure it builds. Usermode linux seems to have been ported at least to ppc and ia64. Unfortunately, I cannot run the ZFS Regression Test Suite on cross compiled binaries. Also, ZFS' build system requires a built kernel against which it does numerous autotools checks. It is more desirable to run them against a kernel known to actually work rather than something I built without testing it. You might like to start from there in order to not to ruin poor boxes. I am asking people to test production-quality code, so the systems should be fine. Afterward, anyone on Gentoo that wants to remove the files can run `emerge -C sys-kernel/spl sys-fs/zfs-kmod sys-fs/zfs`. People on non-gentoo systems that want to remove the files can do that manually. I will provide them with the information needed to do that should they want to do it. So far, only people using Gentoo have volunteered to test. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Porting ZFS to additional architectures
On 02/06/2013 11:26 AM, Alec Warner wrote: On Tue, Feb 5, 2013 at 11:25 AM, Richard Yao r...@gentoo.org wrote: Dear Everyone, Does anyone have root access to Linux systems on any of the following architectures that is willing to help ZFS development? Alpha HPPA IA-64 MIPS/MIPS64 PPC/PPC64 SH SPARC/SPARC64 http://www.gentoo.org/proj/en/infrastructure/dev-machines.xml -A I had not thought of those. Thanks for the suggestion. :) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Package up for grabs: dev-util/dwdiff
Feel free to grab dev-util/dwdiff if you want. Thanks! Perhaps shell-tools@ herd?
Re: [gentoo-dev] /var/run or /run for init scripts?
130206 Diego Elio Pettenò wrote: On 06/02/2013 14:58, Markos Chandras wrote: Would it made sense to symlink /var/run - /run so we don't end up with stable entries in /var/run directory? I would say that we should have that symlink and I told WilliamH so before. FWIW I have : root:505 ~ ls -l /var/run lrwxrwxrwx 1 root root 4 Jun 20 2012 /var/run - /run root:506 ~ equery b /var/run * Searching for /var/run ... sys-apps/dbus-1.6.8 (/var/run) -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in virtual/ffmpeg: ffmpeg-9.ebuild ChangeLog ffmpeg-0.10.2-r1.ebuild
Tomáš Chvátal wrote: we as gentoo will provide both while preffered default will be what major distros use. What kind of careless mainstream attitude is that? Really? I mean: You are saying that given two options, Gentoo will do whatever major distros are doing. (Never mind that Gentoo *is* a major distro, and whatever Gentoo does generates collective bias just like whatever any other distro does.) How about making an informed decision instead? Oops, I forgot - that would mean actually having to *get informed* first. We as gentoo must certainly avoid getting informed at all cost111oneone Are you *really* quite serious? Please explain yourself. If you disagree with that and you don't want your lead to make that decision Hm? Where can I learn more about the lead ? So it is a single person's decision, and not we as gentoo that decides? I'd like to understand how this decision making process actually works. Does anyone know? which you and I both don't want. Guess what - I have been on the receiving end of the arguably insanely lame mainstream attitude that you support, and honestly it fucking broke my heart that people working on Linux distributions (it wasn't just Gentoo, it was *every* distro) would be so genuinely uninterested in what happens upstream, especially at a time where a downstream decision may carry a bit of extra weight. I do not want that. (Around the time this happened to me I wrote roughly the same in a private email to developers of another distribution which shall remain unnamed. I found that email in a pastebin a few days later.) It is long since clear to me that I have much too high expectations on people. But are you *REALLY* not able to do *any* better than default will be what major distros use ? Seriously? //Peter
