Re: [gentoo-dev] Packages up for grabs due lack of time

[Thomas Kahle]

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.

[Michał Górny]

On Tue, 5 Feb 2013 22:32:59 -0300
Alexis Ballier  wrote:

> On Tue,  5 Feb 2013 21:19:23 +0100
> Michał Górny  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] Introduce cmake-multilib wrapper for cmake-utils.

[Michał Górny]

---
 gx86/eclass/cmake-multilib.eclass | 56 +++
 1 file changed, 56 insertions(+)
 create mode 100644 gx86/eclass/cmake-multilib.eclass

diff --git a/gx86/eclass/cmake-multilib.eclass 
b/gx86/eclass/cmake-multilib.eclass
new file mode 100644
index 000..7e929b2
--- /dev/null
+++ b/gx86/eclass/cmake-multilib.eclass
@@ -0,0 +1,56 @@
+# Copyright 1999-2013 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/eclass/cmake-multilib.eclass,v 1.8 
2013/02/01 21:39:50 mgorny Exp $
+
+# @ECLASS: cmake-multilib.eclass
+# @MAINTAINER:
+# Michał Górny 
+# @BLURB: cmake-utils wrapper for multilib builds
+# @DESCRIPTION:
+# The cmake-multilib.eclass is a cmake-utils.eclass(5) wrapper
+# introducing support for building for more than one ABI (multilib).
+#
+# Inheriting this eclass sets IUSE and exports cmake-utils phase
+# function wrappers which build the package for each supported ABI
+# if the appropriate flag is enabled.
+#
+# Note that the multilib support requires out-of-source builds to be
+# enabled. Thus, it is impossible to use CMAKE_IN_SOURCE_BUILD with
+# it.
+
+# EAPI=5 is required for meaningful MULTILIB_USEDEP.
+case ${EAPI:-0} in
+   5) ;;
+   *) die "EAPI=${EAPI} is not supported" ;;
+esac
+
+if [[ ${CMAKE_IN_SOURCE_BUILD} ]]; then
+   die "${ECLASS}: multilib support requires out-of-source builds."
+fi
+
+inherit cmake-utils multilib-build
+
+EXPORT_FUNCTIONS src_configure src_compile src_test src_install
+
+cmake-multilib_src_configure() {
+   multilib_parallel_foreach_abi cmake-utils_src_configure
+}
+
+cmake-multilib_src_compile() {
+   multilib_foreach_abi cmake-utils_src_compile
+}
+
+cmake-multilib_src_test() {
+   multilib_foreach_abi cmake-utils_src_test
+}
+
+cmake-multilib_src_install() {
+   cmake-multilib_secure_install() {
+   cmake-utils_src_install
+
+   # Make sure all headers are the same for each ABI.
+   multilib_check_headers
+   }
+
+   multilib_foreach_abi cmake-multilib_secure_install
+}
-- 
1.8.1.2

[gentoo-dev] [PATCH] Convert virtualgl to cmake-multilib.

[Michał Górny]

---
 ...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

[Ralph Sennhauser]

On Mon, 04 Feb 2013 09:16:32 +0800
Patrick Lauer  wrote:

> On 02/03/2013 09:45 PM, Ralph Sennhauser wrote:
> > On Sun, 03 Feb 2013 13:46:52 +0100
> > Pacho Ramos  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

[Dennis Lan (dlan)]

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
#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  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?

[Markos Chandras]

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=2&chap=4

-- 
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] /var/run or /run for init scripts?

[Diego Elio Pettenò]

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?

[Ian Stakenvicius]

-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?

[Markos Chandras]

On 6 February 2013 13:55, 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
>
> --
> 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.

[Alexis Ballier]

On Wed,  6 Feb 2013 11:07:21 +0100
Michał Górny  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?

[Diego Elio Pettenò]

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.

[Michał Górny]

On Wed, 6 Feb 2013 11:02:35 -0300
Alexis Ballier  wrote:

> On Wed,  6 Feb 2013 11:07:21 +0100
> Michał Górny  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

[Ian Stakenvicius]

-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

[Ian Stakenvicius]

-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

[Markos Chandras]

On 6 February 2013 14:18, Ian Stakenvicius  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

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/02/13 09:53 AM, Markos Chandras wrote:
> On 6 February 2013 14:18, Ian Stakenvicius  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

[Mike Gilbert]

On Wed, Feb 6, 2013 at 10:03 AM, Ian Stakenvicius  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  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

[William Hubbs]

On Wed, Feb 06, 2013 at 10:23:06AM -0500, Mike Gilbert wrote:
> On Wed, Feb 6, 2013 at 10:03 AM, Ian Stakenvicius  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  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

[Cyprien Nicolas]

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

[Alec Warner]

On Tue, Feb 5, 2013 at 11:25 AM, Richard Yao  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

[Richard Yao]

On 02/06/2013 02:12 AM, Sergei Trofimovich wrote:
> On Tue, 05 Feb 2013 14:25:56 -0500
> Richard Yao  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

[Richard Yao]

On 02/06/2013 11:26 AM, Alec Warner wrote:
> On Tue, Feb 5, 2013 at 11:25 AM, Richard Yao  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

[Samuli Suominen]

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?

[Philip Webb]

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

[Peter Stuge]

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