Re: [gentoo-dev] Packages up for grabs
On 03/23/2012 04:54 PM, Christoph Mende wrote: Hi, I'm currently lacking time for some packages, so I'm looking for someone to take over a few, most notably: - net-misc/curl - net-dns/c-ares (preferably both together) I'm at about my limit, but if no one else wants them, I'll take care of these. The both important. (However, if someone else is interested by all means.) And while we're at it there's also some lower maintenance packages I'd like to get rid of just because I don't use them anymore: - app-misc/granule - dev-cpp/libassa (was added for granule, not sure if it's used by anything else, might be last rited soon if upstream doesn't update it) - media-gfx/shotwell - media-sound/audio-entropyd - net-wireless/ndiswrapper - sys-fs/gt5 - x11-misc/launchy - x11-misc/transset-df If you want any of those, just remove me from metadata and add yourself. Thanks. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
> > > oasis_use_enable() {
> > > echo "--override $2 `use $1 && echo \"true\" || echo
> > > \"false\"`" }
> >
> > Mike added 'usex' to 'eutils.eclass' recently, so you might like to
> > use it: (UNTESTED)
> > echo "--override $2 $(usex $1 true false)"
>
> it needs to print the quotes too, so this wont work
It did not print quotes:
$ echo "--override bazz `true && echo \"true\" || echo \"false\"`"
--override bazz true
> i've been copy/pasting this 'formula' for a while, i know it works, and
> i am too lazy to try to rewrite it to usex just for the sake of it :)
>
> >
> > > oasis_src_configure() {
> > > ocaml setup.ml -configure \
> > > --prefix usr \
> > > --libdir /usr/$(get_libdir) \
> > > --docdir /usr/share/doc/${PF}/html \
> > > --destdir "${D}" \
> > > $(oasis_use_enable debug debug) \
> > > $(oasis_use_enable ocamlopt is_native) \
> > > ${oasis_configure_opts} \
> > > || die
> > > }
> >
> > This configure hates gentoo prefix, right?
> > Might worth sprinkling "${EPREFIX}" around absolute paths.
> >
>
> well, this will imply not supporting eapi2, i can live with it
Oh, right. I've forgot. Each EPREFIX usage would require something like the
following:
has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> however, usually, i prefer prefix guys that need it to submit patches
> instead of trying to support it without testing.
Yeah, sounds fair.
--
Sergei
signature.asc
Description: PGP signature
[gentoo-dev] Packages up for grabs
Hi, I'm currently lacking time for some packages, so I'm looking for someone to take over a few, most notably: - net-misc/curl - net-dns/c-ares (preferably both together) And while we're at it there's also some lower maintenance packages I'd like to get rid of just because I don't use them anymore: - app-misc/granule - dev-cpp/libassa (was added for granule, not sure if it's used by anything else, might be last rited soon if upstream doesn't update it) - media-gfx/shotwell - media-sound/audio-entropyd - net-wireless/ndiswrapper - sys-fs/gt5 - x11-misc/launchy - x11-misc/transset-df If you want any of those, just remove me from metadata and add yourself. Thanks.
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, Mar 23, 2012 at 4:24 PM, Alexis Ballier wrote:
> On Fri, 23 Mar 2012 23:11:46 +0300
> Sergei Trofimovich wrote:
>> > oasis_src_configure() {
>> > ocaml setup.ml -configure \
>> > --prefix usr \
>> > --libdir /usr/$(get_libdir) \
>> > --docdir /usr/share/doc/${PF}/html \
>> > --destdir "${D}" \
>> > $(oasis_use_enable debug debug) \
>> > $(oasis_use_enable ocamlopt is_native) \
>> > ${oasis_configure_opts} \
>> > || die
>> > }
>>
>> This configure hates gentoo prefix, right?
>> Might worth sprinkling "${EPREFIX}" around absolute paths.
>>
>
> well, this will imply not supporting eapi2, i can live with it
>
> however, usually, i prefer prefix guys that need it to submit patches
> instead of trying to support it without testing.
> eg: shall it be EPREFIX before the /usr's?shall it be ED instead of
> D? both ?
You probably want ${EPREFIX} in front of every /usr passed to
configure. In other words,
ocaml setup.ml -configure --prefix "${EPREFIX}/usr" --libdir
"${EPREFIX}/blah" --docdir "${EPREFIX}/blargh" etc.
However, destdir should still be ${D}. That way, in src_install() your
package's files will be copied to ${D}${EPREFIX}/usr, better known as
${ED}usr.
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, 23 Mar 2012 23:11:46 +0300
Sergei Trofimovich wrote:
> > oasis_use_enable() {
> > echo "--override $2 `use $1 && echo \"true\" || echo
> > \"false\"`" }
>
> Mike added 'usex' to 'eutils.eclass' recently, so you might like to
> use it: (UNTESTED)
> echo "--override $2 $(usex $1 true false)"
it needs to print the quotes too, so this wont work
i've been copy/pasting this 'formula' for a while, i know it works, and
i am too lazy to try to rewrite it to usex just for the sake of it :)
>
> > oasis_src_configure() {
> > ocaml setup.ml -configure \
> > --prefix usr \
> > --libdir /usr/$(get_libdir) \
> > --docdir /usr/share/doc/${PF}/html \
> > --destdir "${D}" \
> > $(oasis_use_enable debug debug) \
> > $(oasis_use_enable ocamlopt is_native) \
> > ${oasis_configure_opts} \
> > || die
> > }
>
> This configure hates gentoo prefix, right?
> Might worth sprinkling "${EPREFIX}" around absolute paths.
>
well, this will imply not supporting eapi2, i can live with it
however, usually, i prefer prefix guys that need it to submit patches
instead of trying to support it without testing.
eg: shall it be EPREFIX before the /usr's ? shall it be ED instead of
D? both ?
A.
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, Mar 23, 2012 at 12:37 PM, Ciaran McCreesh wrote: > On Fri, 23 Mar 2012 11:17:56 -0700 > Alec Warner wrote: >> In general if you are going to say 'this usage is wrong' then you need >> some kind of tool to detect and report on it; otherwise a subset of >> developers will get it wrong. Don't make it easy to do the wrong >> thing, make it easy to do the right thing. > > Unfortunately, bash really doesn't make it easy for us to do that sort > of thing... Its more a dig at the process in general. I don't aim for perfect checks (bash is hard, waa waa waa), but arguably we don't even try to write checks that are non-perfect. We end up in situations where one guy does it the wrong way, then people copy and paste his code and suddenly it is done wrong in dozens of places. QA warnings help let people know that what they are doing is likely wrong. -A > > -- > Ciaran McCreesh
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
> oasis_use_enable() {
> echo "--override $2 `use $1 && echo \"true\" || echo \"false\"`"
> }
Mike added 'usex' to 'eutils.eclass' recently, so you might like to use it:
(UNTESTED)
echo "--override $2 $(usex $1 true false)"
> oasis_src_configure() {
> ocaml setup.ml -configure \
> --prefix usr \
> --libdir /usr/$(get_libdir) \
> --docdir /usr/share/doc/${PF}/html \
> --destdir "${D}" \
> $(oasis_use_enable debug debug) \
> $(oasis_use_enable ocamlopt is_native) \
> ${oasis_configure_opts} \
> || die
> }
This configure hates gentoo prefix, right?
Might worth sprinkling "${EPREFIX}" around absolute paths.
--
Sergei
signature.asc
Description: PGP signature
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, 23 Mar 2012 11:17:56 -0700 Alec Warner wrote: > In general if you are going to say 'this usage is wrong' then you need > some kind of tool to detect and report on it; otherwise a subset of > developers will get it wrong. Don't make it easy to do the wrong > thing, make it easy to do the right thing. Unfortunately, bash really doesn't make it easy for us to do that sort of thing... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, Mar 23, 2012 at 10:09 AM, Alexandre Rostovtsev
wrote:
> On Fri, 2012-03-23 at 12:50 -0400, Mike Gilbert wrote:
>> On Fri, Mar 23, 2012 at 12:02 PM, Ciaran McCreesh
>> wrote:
>> > On Fri, 23 Mar 2012 11:58:47 -0400
>> > Mike Gilbert wrote:
>> >> > oasis_src_compile() {
>> >> > oasis_src_compile_no_doc
>> >> > if has doc ${IUSE} && use doc; then
>> >> > ocaml setup.ml -doc || die
>> >> > fi
>> >> > }
>> >>
>> >> This should probably call use_if_iuse from eutils.eclass, which
>> >> handles IUSE="[+-]doc".
>> >
>> > Actually, neither way works. The spec says:
>> >
>> > Global variables must only contain invariant values
>> > (see~\ref{sec:metadata-invariance}). If a global variable's value is
>> > invariant, it may have the value that would be generated at any
>> > given point in the build sequence.
>> >
>> > So you can't rely upon IUSE having the "merged" value in an eclass.
>> >
>>
>> use_if_iuse is called from functions in several eclasses already in
>> the tree. See chromium, kde4-base, qt4-build, and toolchain.
>>
>> Are all of these usages incorrect? Do you have an alternate solution?
>
> By my count, there are already at least 19 eclasses in the tree that
> access an ebuild's IUSE from eclass code (autotools-utils, chromium,
> clutter, db, enlightenment, eutils, gnome2, gnome-python-common,
> java-ant-2, java-pkg-2, java-utils-2, mozconfig-3, pam, qt4-build,
> qt4-r2, ruby-ng, xfconf, x-modular, and xorg-2).
Lets be clear here. Just because we do already it does not mean we
should keep doing it.
In general if you are going to say 'this usage is wrong' then you need
some kind of tool to detect and report on it; otherwise a subset of
developers will get it wrong. Don't make it easy to do the wrong
thing, make it easy to do the right thing.
-A
>
> -Alexandre Rostovtsev.
>
>
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, 23 Mar 2012 11:58:47 -0400
Mike Gilbert wrote:
> On Fri, Mar 23, 2012 at 4:15 AM, Alexis Ballier
> wrote:
>
> > DEPEND=">=dev-lang/ocaml-3.12[ocamlopt?]"
> > DEPEND="${RDEPEND}"
>
> That looks like a typo.
yes, thanks for spotting
>
> > oasis_src_compile() {
> > oasis_src_compile_no_doc
> > if has doc ${IUSE} && use doc; then
> > ocaml setup.ml -doc || die
> > fi
> > }
>
> This should probably call use_if_iuse from eutils.eclass, which
> handles IUSE="[+-]doc".
>
hmm, actually, I like the idea of something like OASIS_WANT_DOCS as
suggested by Ciaran, this sounds simpler and, as a side effect, will
allow me to kill the useless oasis_src_compile_no_doc function.
I'll come back with something like this and post an update, most likely
next week, pilling up the reviews :=)
A.
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, 2012-03-23 at 12:50 -0400, Mike Gilbert wrote:
> On Fri, Mar 23, 2012 at 12:02 PM, Ciaran McCreesh
> wrote:
> > On Fri, 23 Mar 2012 11:58:47 -0400
> > Mike Gilbert wrote:
> >> > oasis_src_compile() {
> >> > oasis_src_compile_no_doc
> >> > if has doc ${IUSE} && use doc; then
> >> > ocaml setup.ml -doc || die
> >> > fi
> >> > }
> >>
> >> This should probably call use_if_iuse from eutils.eclass, which
> >> handles IUSE="[+-]doc".
> >
> > Actually, neither way works. The spec says:
> >
> >Global variables must only contain invariant values
> >(see~\ref{sec:metadata-invariance}). If a global variable's value is
> >invariant, it may have the value that would be generated at any
> >given point in the build sequence.
> >
> > So you can't rely upon IUSE having the "merged" value in an eclass.
> >
>
> use_if_iuse is called from functions in several eclasses already in
> the tree. See chromium, kde4-base, qt4-build, and toolchain.
>
> Are all of these usages incorrect? Do you have an alternate solution?
By my count, there are already at least 19 eclasses in the tree that
access an ebuild's IUSE from eclass code (autotools-utils, chromium,
clutter, db, enlightenment, eutils, gnome2, gnome-python-common,
java-ant-2, java-pkg-2, java-utils-2, mozconfig-3, pam, qt4-build,
qt4-r2, ruby-ng, xfconf, x-modular, and xorg-2).
-Alexandre Rostovtsev.
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, Mar 23, 2012 at 12:52 PM, Ciaran McCreesh wrote: > On Fri, 23 Mar 2012 12:50:51 -0400 > Mike Gilbert wrote: >> use_if_iuse is called from functions in several eclasses already in >> the tree. See chromium, kde4-base, qt4-build, and toolchain. >> >> Are all of these usages incorrect? Do you have an alternate solution? > > We had this discussion when the function was introduced, and we were > assured that it "would only be used correctly"... The correct solution > is probably to have ebuilds define a variable like "OASIS_WANT_DOCS", > and to use that. > Ah. I'll have to review chromium.eclass then; I think I'm doing it wrong.
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, 23 Mar 2012 12:50:51 -0400 Mike Gilbert wrote: > use_if_iuse is called from functions in several eclasses already in > the tree. See chromium, kde4-base, qt4-build, and toolchain. > > Are all of these usages incorrect? Do you have an alternate solution? We had this discussion when the function was introduced, and we were assured that it "would only be used correctly"... The correct solution is probably to have ebuilds define a variable like "OASIS_WANT_DOCS", and to use that. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, Mar 23, 2012 at 12:02 PM, Ciaran McCreesh
wrote:
> On Fri, 23 Mar 2012 11:58:47 -0400
> Mike Gilbert wrote:
>> > oasis_src_compile() {
>> > oasis_src_compile_no_doc
>> > if has doc ${IUSE} && use doc; then
>> > ocaml setup.ml -doc || die
>> > fi
>> > }
>>
>> This should probably call use_if_iuse from eutils.eclass, which
>> handles IUSE="[+-]doc".
>
> Actually, neither way works. The spec says:
>
> Global variables must only contain invariant values
> (see~\ref{sec:metadata-invariance}). If a global variable's value is
> invariant, it may have the value that would be generated at any
> given point in the build sequence.
>
> So you can't rely upon IUSE having the "merged" value in an eclass.
>
use_if_iuse is called from functions in several eclasses already in
the tree. See chromium, kde4-base, qt4-build, and toolchain.
Are all of these usages incorrect? Do you have an alternate solution?
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 23 Mar 2012 12:32:05 -0400
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 23/03/12 12:19 PM, Ciaran McCreesh wrote:
> > On Fri, 23 Mar 2012 12:14:39 -0400 Ian Stakenvicius
> > wrote:
> >> I don't know if I follow this one or not. When inheriting an
> >> eclass, all entities within the eclass get merged into the
> >> ebuild. As long as there aren't any special conditional tricks
> >> being used to assign to global variables like IUSE, it would
> >> still be invariant wouldn't it?
> >
> > The point is that the merging might be done inside the package
> > manager (not in bash code) on the IUSE metadata variable, and the
> > changes don't have to be reflected in the IUSE environment variable
> > inside the ebuild.
>
> If that was the case, then eclasses could no longer append deps to
> (R)DEPEND, either .?
The point of the wording is to allow an eclass to do this:
DEPEND="cat/two"
and an ebuild do this:
DEPEND="cat/one"
and to have the package manager, but not necessarily bash code, know
that there are two dependencies. It also makes the annoying RDEPEND
value behaviour that older EAPIs specify possible.
So yes, you *could* argue that with the way it's worded, this in an
eclass isn't guaranteed to work:
DEPEND="cat/three"
DEPEND="${DEPEND} cat/four"
What the wording is supposed to imply is that if some bash code looks
at DEPEND, it could contain either "cat/three cat/four", or "cat/one
cat/three cat/four". If the first DEPEND looked like the second, then
it would also be allowed to contain "cat/one cat/one cat/three
cat/four" and similar.
What this really comes down to is that bash is the wrong tool for doing
what we're doing, and that we can't have this work "the way we want
it to" since bash doesn't provide the interfaces we need to get it
to work, and every time we try to be clever it breaks on newer bash
releases...
- --
Ciaran McCreesh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk9sqFAACgkQ96zL6DUtXhFnJgCfZhLF1/UsWWCARATI2I9pg5Yv
ATMAn3exnOUWgwQTt84v1q9mE9ptOiH/
=BQ2n
-END PGP SIGNATURE-
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/03/12 12:32 PM, Ian Stakenvicius wrote: > On 23/03/12 12:19 PM, Ciaran McCreesh wrote: >> On Fri, 23 Mar 2012 12:14:39 -0400 Ian Stakenvicius >> wrote: >>> I don't know if I follow this one or not. When inheriting an >>> eclass, all entities within the eclass get merged into the >>> ebuild. As long as there aren't any special conditional >>> tricks being used to assign to global variables like IUSE, it >>> would still be invariant wouldn't it? > >> The point is that the merging might be done inside the package >> manager (not in bash code) on the IUSE metadata variable, and >> the changes don't have to be reflected in the IUSE environment >> variable inside the ebuild. > > If that was the case, then eclasses could no longer append deps to > (R)DEPEND, either .? Err, nvm.. i think i'm following the difference now. functions like has_version and so forth don't actually work on the value(s) of *DEPEND themselves, so in the case of (R)DEPEND it wouldn't matter of the package manager didn't expose the merge. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk9spp8ACgkQAJxUfCtlWe1a2wD/YsHDM1hYik+d46fJ90yckI/U OKr1ThK6hhJTbjmqGpgBAMekpXzx8NFIPerRPm037FgWQiCuUPDezAhmj8S73EPV =CNHZ -END PGP SIGNATURE-
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/03/12 12:19 PM, Ciaran McCreesh wrote: > On Fri, 23 Mar 2012 12:14:39 -0400 Ian Stakenvicius > wrote: >> I don't know if I follow this one or not. When inheriting an >> eclass, all entities within the eclass get merged into the >> ebuild. As long as there aren't any special conditional tricks >> being used to assign to global variables like IUSE, it would >> still be invariant wouldn't it? > > The point is that the merging might be done inside the package > manager (not in bash code) on the IUSE metadata variable, and the > changes don't have to be reflected in the IUSE environment variable > inside the ebuild. If that was the case, then eclasses could no longer append deps to (R)DEPEND, either .? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) iF4EAREIAAYFAk9spYUACgkQAJxUfCtlWe1g+QEA1NAl+nl3zCEOmTIjCN1271r7 pCJNO7aCW/iNrXniCQUA/3j1xktcStPmQL8rXPRLSjMy+vqBsclWQwFHa4eytu6B =g3Dz -END PGP SIGNATURE-
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 23 Mar 2012 12:14:39 -0400 Ian Stakenvicius wrote: > I don't know if I follow this one or not. When inheriting an eclass, > all entities within the eclass get merged into the ebuild. As long as > there aren't any special conditional tricks being used to assign to > global variables like IUSE, it would still be invariant wouldn't it? The point is that the merging might be done inside the package manager (not in bash code) on the IUSE metadata variable, and the changes don't have to be reflected in the IUSE environment variable inside the ebuild. > I think 'any point in the build sequence' is still > post-eclass-inheritance isn't it? Nope. It's also at any point during the sourcing of any of the files. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9sonsACgkQ96zL6DUtXhEtFgCgyT/pUwKQIaLE8e28U8P0uS3x HF8An1frYjZvoNYSC2/Qs1eNzqdlgVzT =Kj+k -END PGP SIGNATURE-
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23/03/12 12:02 PM, Ciaran McCreesh wrote:
> On Fri, 23 Mar 2012 11:58:47 -0400 Mike Gilbert
> wrote:
>>> oasis_src_compile() { oasis_src_compile_no_doc if has doc
>>> ${IUSE} && use doc; then ocaml setup.ml -doc || die fi }
>>
>> This should probably call use_if_iuse from eutils.eclass, which
>> handles IUSE="[+-]doc".
>
> Actually, neither way works. The spec says:
>
> Global variables must only contain invariant values
> (see~\ref{sec:metadata-invariance}). If a global variable's value
> is invariant, it may have the value that would be generated at any
> given point in the build sequence.
>
> So you can't rely upon IUSE having the "merged" value in an
> eclass.
>
I don't know if I follow this one or not. When inheriting an eclass,
all entities within the eclass get merged into the ebuild. As long as
there aren't any special conditional tricks being used to assign to
global variables like IUSE, it would still be invariant wouldn't it?
I think 'any point in the build sequence' is still
post-eclass-inheritance isn't it?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
iF4EAREIAAYFAk9soW8ACgkQAJxUfCtlWe1UJQEAuTQriXmsu6YKcpeADGusTNdZ
k8Vr99LdEFwyXicZHMsBAN2bo95GvLvdrpVEj8h1THQ4HMZDvPRx0o/yrWzjxGNZ
=+e3P
-END PGP SIGNATURE-
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, 23 Mar 2012 11:58:47 -0400
Mike Gilbert wrote:
> > oasis_src_compile() {
> > oasis_src_compile_no_doc
> > if has doc ${IUSE} && use doc; then
> > ocaml setup.ml -doc || die
> > fi
> > }
>
> This should probably call use_if_iuse from eutils.eclass, which
> handles IUSE="[+-]doc".
Actually, neither way works. The spec says:
Global variables must only contain invariant values
(see~\ref{sec:metadata-invariance}). If a global variable's value is
invariant, it may have the value that would be generated at any
given point in the build sequence.
So you can't rely upon IUSE having the "merged" value in an eclass.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
On Fri, Mar 23, 2012 at 4:15 AM, Alexis Ballier wrote:
> DEPEND=">=dev-lang/ocaml-3.12[ocamlopt?]"
> DEPEND="${RDEPEND}"
That looks like a typo.
> oasis_src_compile() {
> oasis_src_compile_no_doc
> if has doc ${IUSE} && use doc; then
> ocaml setup.ml -doc || die
> fi
> }
This should probably call use_if_iuse from eutils.eclass, which
handles IUSE="[+-]doc".
Re: [gentoo-dev] [GSoC2012] Cross Container Support Project
On Fri, Mar 23, 2012 at 01:46:17PM +0300, Alexey Shvetsov wrote: > Hi! > > Well i have 2 arm lxc containers on amd64 machine. Its works good if > qemu support most of needed cross arch instructions I'd be curious how much of that is native, vs emulated. The hybrid approach of scratchbox/obs has some definite gains. If we had a clean way to mark which can be native (toolchain), the perf gain is definitely worth the work... ~brian
Re: [gentoo-dev] [GSoC2012] Cross Container Support Project
Hi! Well i have 2 arm lxc containers on amd64 machine. Its works good if qemu support most of needed cross arch instructions Jing Huang писал 2012-03-23 13:36: Hi Everyone, I am a student at Peking University in China. I am very interested in the project of Cross Container Support(). I have some ideas about the project. Please help me to examine the thoughts. First, I think downloading stage and portage packets into specified directory each time needs to be impoved(). It needs to build execution environment every time. So it is not convenient. On the other hand, the files in specified directory would be modified by some process potentially. It is not an isolated execution environment at all. Therefore, I would make some img files for the each arch, including arm, mips, etc. The img file contains arch-stage and portage. When creating the qemu-user container, the iniscript mounts the img file into specified directory then chroot to it. Second, if the process accesses disk frequently, I would to make a tmpfs file for the qemu-user container. The process in the container is running on tmpfs file and been sped up. Third, I would custom a lightweight qemu-user container for the specified process if necessary. In my previous work, I made a custom ramdisk VM for the process by modifying the mkinitrd script. With the help of “ldd –v ” command, I could get the shared libraries of the process and packet them into ramdisk. But in Gentoo, maybe I could custom the qemu-user container using the USE label. In my proposal, this project uses a small quantity of bash to implement just the core tools (create, destroy, enter). In simpler terms, I plan to implement them in this way: 1. create routine # qemu_container_create config_file The config_file specifies arch, arch-img file, chroot directory, additional args of qemu(like "-cpu cortex-a8"). Then the create routine will execute as: 1). If having the arch-img then mount it into chroot directory. 2). If not, make a new img file, download stageball&portage, unpack them to the chroot directory. 2). modprobe binfmt_misc and register the qemu-user-arch to the binfmt_misc. 3). install the static qemu-user into the chroot directory and mount the required directories. 4). register this new container to our managment tool. The register info includes container_id, stageball version, stageball arch, chroot directory, etc. 2. enter routine #qemu_container_enter container_id The enter routine opens a terminal and chroot into the environment. The management tool should also set the container is in "running" state. 3. destroy routine #qemu_container_destroy container_id 1). exits from chroot environment 2). unmount stuff when not in use 3). clear the qemu-user-arch in binfmt_misc register file (maybe other containers use it) 4). remove the container info from managment tool Besides these routines, I would also implement container_list and container_export routines. The former lists the info/state of containers. The latter is used to export system images. Questions: 1). Why integrate qemu-user container with crossdev? Crossdev is a cross compiler. The qemu-user container not only compiles the heterogeneous programs but also tests them. I thought if the qemu-user container was good enough, it could replace the crossdev. 2). "An additional task is to support layered systems so native userspace can be used to further speed up the process (hybrid chroot)." I don't very understand the task. Could someone help me and explain the “hybrid chroot”? Would someone give me some suggestions? Any comments will be much appreciated. Jing Huang. -- Best Regards, Alexey 'Alexxy' Shvetsov Petersburg Nuclear Physics Institute, Russia Department of Molecular and Radiation Biophysics Gentoo Team Ru Gentoo Linux Dev mailto:alexx...@gmail.com mailto:ale...@gentoo.org mailto:ale...@omrb.pnpi.spb.ru
[gentoo-dev] [GSoC2012] Cross Container Support Project
Hi Everyone, I am a student at Peking University in China. I am very interested in the project of Cross Container Support(http://wiki.gentoo.org/wiki/Google_Summer_of_Code/2012/Ideas#Cross_Container_Support). I have some ideas about the project. Please help me to examine the thoughts. First, I think downloading stage and portage packets into specified directory each time needs to be impoved(http://www.gentoo.org/proj/en/base/embedded/handbook/index.xml?part=1&chap=5). It needs to build execution environment every time. So it is not convenient. On the other hand, the files in specified directory would be modified by some process potentially. It is not an isolated execution environment at all. Therefore, I would make some img files for the each arch, including arm, mips, etc. The img file contains arch-stage and portage. When creating the qemu-user container, the iniscript mounts the img file into specified directory then chroot to it. Second, if the process accesses disk frequently, I would to make a tmpfs file for the qemu-user container. The process in the container is running on tmpfs file and been sped up. Third, I would custom a lightweight qemu-user container for the specified process if necessary. In my previous work, I made a custom ramdisk VM for the process by modifying the mkinitrd script. With the help of “ldd –v ” command, I could get the shared libraries of the process and packet them into ramdisk. But in Gentoo, maybe I could custom the qemu-user container using the USE label. In my proposal, this project uses a small quantity of bash to implement just the core tools (create, destroy, enter). In simpler terms, I plan to implement them in this way: 1. create routine # qemu_container_create config_file The config_file specifies arch, arch-img file, chroot directory, additional args of qemu(like "-cpu cortex-a8"). Then the create routine will execute as: 1). If having the arch-img then mount it into chroot directory. 2). If not, make a new img file, download stageball&portage, unpack them to the chroot directory. 2). modprobe binfmt_misc and register the qemu-user-arch to the binfmt_misc. 3). install the static qemu-user into the chroot directory and mount the required directories. 4). register this new container to our managment tool. The register info includes container_id, stageball version, stageball arch, chroot directory, etc. 2. enter routine #qemu_container_enter container_id The enter routine opens a terminal and chroot into the environment. The management tool should also set the container is in "running" state. 3. destroy routine #qemu_container_destroy container_id 1). exits from chroot environment 2). unmount stuff when not in use 3). clear the qemu-user-arch in binfmt_misc register file (maybe other containers use it) 4). remove the container info from managment tool Besides these routines, I would also implement container_list and container_export routines. The former lists the info/state of containers. The latter is used to export system images. Questions: 1). Why integrate qemu-user container with crossdev? Crossdev is a cross compiler. The qemu-user container not only compiles the heterogeneous programs but also tests them. I thought if the qemu-user container was good enough, it could replace the crossdev. 2). "An additional task is to support layered systems so native userspace can be used to further speed up the process (hybrid chroot)." I don't very understand the task. Could someone help me and explain the “hybrid chroot”? Would someone give me some suggestions? Any comments will be much appreciated. Jing Huang.
[gentoo-dev] New eclass: oasis.eclass for oasis-based ocaml packages.
Hi,
Oasis [1] is becoming the de factor standard for ocaml packages. I've
been bored of copy/pasting always the same code from ebuilds to ebuilds
and thus decided to write an eclass simplifying everything.
Attached: said eclass, a diff of a random dev-ml package I've
converted to illustrate and said random ebuild now.
Comments welcome,
Alexis.
[1] http://oasis.forge.ocamlcore.org/
oasis.eclass
Description: Binary data
Index: fieldslib-0.1.2.ebuild
===
RCS file: /var/cvsroot/gentoo-x86/dev-ml/fieldslib/fieldslib-0.1.2.ebuild,v
retrieving revision 1.1
diff -u -B -r1.1 fieldslib-0.1.2.ebuild
--- fieldslib-0.1.2.ebuild 25 Jun 2011 18:56:36 - 1.1
+++ fieldslib-0.1.2.ebuild 23 Mar 2012 08:13:31 -
@@ -3,7 +3,7 @@
# $Header: /var/cvsroot/gentoo-x86/dev-ml/fieldslib/fieldslib-0.1.2.ebuild,v 1.1 2011/06/25 18:56:36 aballier Exp $
EAPI="2"
-inherit findlib multilib
+inherit oasis
DESCRIPTION="Folding over record fields"
HOMEPAGE="http://www.janestreet.com/ocaml";
@@ -12,28 +12,9 @@
LICENSE="LGPL-2.1-linking-exception"
SLOT="0"
KEYWORDS="~amd64"
-IUSE="debug +ocamlopt"
+IUSE=""
-DEPEND=">=dev-lang/ocaml-3.12[ocamlopt?]
- >=dev-ml/type-conv-2.3.0"
+DEPEND=">=dev-ml/type-conv-2.3.0"
RDEPEND="${DEPEND}"
-oasis_use_enable() {
- echo "--override $2 `use $1 && echo \"true\" || echo \"false\"`"
-}
-
-src_configure() {
- ./configure --prefix usr \
- --libdir /usr/$(get_libdir) \
- --destdir "${D}" \
- $(oasis_use_enable debug debug) \
- $(oasis_use_enable ocamlopt is_native) \
- || die
-}
-
-src_install() {
- findlib_src_install
-
- # install documentation
- dodoc README || die
-}
+DOCS=( "README" )
fieldslib-0.1.2.ebuild
Description: Binary data
