Hey,
Looks good, the more the merrier :) If you are planning on
maintaining that, it should be included in the CVS. If you are
definitely committed to supporting Pd on Gentoo, then I can setup a
Gentoo box in the auto-build farm for a nightly build on Gentoo.
I haven't used Gentoo at all, so I can't be of any help to Gentoo- specific things.
.hc
On Mar 12, 2007, at 11:49 AM, m t wrote:
Grab it while its hot at:
http://bugs.gentoo.org/show_bug.cgi?id=151843
Regards, Miron _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
All information should be free. - the hacker ethic
FYI there is a project related to that. it's hosted on sourceforge.net and it's called pd-overlay. (the svn repository is actually THE overlay: just checkout then 'emerge pd zexy maxlib what-you-want')
maybe (I hope) you and others be interested.
you can find some additional information on my page at pd-portal: http://www.puredata.info/Members/federico/pd-portage/ that is: using the overlay and creating ebuilds, which is simple as writing shell scripts
if anyone is interested in collaborating, please send ebuild (actually I'm restoring all my dev stuff, and commit those new ebuilds soon)
also I can give developer account to active contributors.
actually we have ebuilds for: freeverb~, gem, ggee, gridflow, iem-comport, iemmatrix, iemlib, maxlib, miXed, pdogg, pdp, zexy and others
How about maintaining the Gentoo build files in the pure-data CVS?
There already is debian, Mac OS X, Windows, and RedHat package build
files there. That would make it possible to have nightly auto-builds
on gentoo also.
.hc
On Mar 16, 2007, at 2:54 PM, federico wrote:
FYI there is a project related to that. it's hosted on sourceforge.net and it's called pd-overlay. (the svn repository is actually THE overlay: just checkout then 'emerge pd zexy maxlib what-you-want')
maybe (I hope) you and others be interested.
you can find some additional information on my page at pd-portal: http://www.puredata.info/Members/federico/pd-portage/ that is: using the overlay and creating ebuilds, which is simple as writing shell scripts
if anyone is interested in collaborating, please send ebuild (actually I'm restoring all my dev stuff, and commit those new ebuilds soon)
also I can give developer account to active contributors.
actually we have ebuilds for: freeverb~, gem, ggee, gridflow, iem-comport, iemmatrix, iemlib, maxlib, miXed, pdogg, pdp, zexy and others
-- Federico
On 3/12/07, Hans-Christoph Steiner hans@eds.org wrote:
Hey,
Looks good, the more the merrier :) If you are planning on
maintaining that, it should be included in the CVS. If you are definitely
committed to supporting Pd on Gentoo, then I can setup a Gentoo box in the auto- build farm for a nightly build on Gentoo.I haven't used Gentoo at all, so I can't be of any help to Gentoo- specific things.
.hc
On Mar 12, 2007, at 11:49 AM, m t wrote:
Grab it while its hot at:
http://bugs.gentoo.org/show_bug.cgi?id=151843
Regards, Miron _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
All information should be free. - the hacker ethic
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
it is ok for me. pd-overlay project is hosted on sourceforge too (see http://pd-overlay.sf.net for info), but using svn; anyway it should be simple moving from svn to CVS.
check also project homepage on sourceforge to see whoever is actually working on the project. my username @sourceforge is federico__ as usual :)
On 4/2/07, Hans-Christoph Steiner hans@eds.org wrote:
How about maintaining the Gentoo build files in the pure-data CVS? There already is debian, Mac OS X, Windows, and RedHat package build files there. That would make it possible to have nightly auto-builds on gentoo also.
.hc
On Mar 16, 2007, at 2:54 PM, federico wrote:
FYI there is a project related to that. it's hosted on sourceforge.net and it's called pd-overlay. (the svn repository is actually THE overlay: just checkout then 'emerge pd zexy maxlib what-you-want')
maybe (I hope) you and others be interested.
you can find some additional information on my page at pd-portal: http://www.puredata.info/Members/federico/pd-portage/ that is: using the overlay and creating ebuilds, which is simple as writing shell scripts
if anyone is interested in collaborating, please send ebuild (actually I'm restoring all my dev stuff, and commit those new ebuilds soon)
also I can give developer account to active contributors.
actually we have ebuilds for: freeverb~, gem, ggee, gridflow, iem-comport, iemmatrix, iemlib, maxlib, miXed, pdogg, pdp, zexy and others
-- Federico
On 3/12/07, Hans-Christoph Steiner hans@eds.org wrote:
Hey,
Looks good, the more the merrier :) If you are planning on maintaining that, it should be included in the CVS. If you are definitely committed to supporting Pd on Gentoo, then I can setup a Gentoo box in the auto- build farm for a nightly build on Gentoo.
I haven't used Gentoo at all, so I can't be of any help to Gentoo- specific things.
.hc
On Mar 12, 2007, at 11:49 AM, m t wrote:
Grab it while its hot at:
http://bugs.gentoo.org/show_bug.cgi?id=151843
Regards, Miron _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
All information should be free. - the hacker ethic
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
Ok, I can add you as a developer, but you have to go thru the
standard procedure, which is pretty simple. Just send an email to pd-
dev introducing yourself and talk about what work you want to do in
the pure-data repository. Also, it's always nice to hear about other
projects that you work on using Pd.
As for the ebuild, it would be great if it was merged in with the Pd- extended build system. Then we can share the maintenance of it all.
Also, I can set up a Gentoo box in the auto-build farm if you'll
finish the setup. Just tell me which version of gentoo should be
installed.
.hc
On Apr 9, 2007, at 9:01 AM, federico wrote:
it is ok for me. pd-overlay project is hosted on sourceforge too (see http://pd-overlay.sf.net for info), but using svn; anyway it should be simple moving from svn to CVS.
check also project homepage on sourceforge to see whoever is actually working on the project. my username @sourceforge is federico__ as usual :)
On 4/2/07, Hans-Christoph Steiner hans@eds.org wrote:
How about maintaining the Gentoo build files in the pure-data CVS? There already is debian, Mac OS X, Windows, and RedHat package build files there. That would make it possible to have nightly auto-builds on gentoo also.
.hc
On Mar 16, 2007, at 2:54 PM, federico wrote:
FYI there is a project related to that. it's hosted on sourceforge.net and it's called pd-overlay. (the svn repository is actually THE overlay: just checkout then 'emerge pd zexy maxlib what-you-want')
maybe (I hope) you and others be interested.
you can find some additional information on my page at pd-portal: http://www.puredata.info/Members/federico/pd-portage/ that is: using the overlay and creating ebuilds, which is simple as writing shell scripts
if anyone is interested in collaborating, please send ebuild
(actually
I'm restoring all my dev stuff, and commit those new ebuilds soon)
also I can give developer account to active contributors.
actually we have ebuilds for: freeverb~, gem, ggee, gridflow, iem-comport, iemmatrix, iemlib, maxlib, miXed, pdogg, pdp, zexy and others
-- Federico
On 3/12/07, Hans-Christoph Steiner hans@eds.org wrote:
Hey,
Looks good, the more the merrier :) If you are planning on maintaining that, it should be included in the CVS. If you are definitely committed to supporting Pd on Gentoo, then I can setup a Gentoo box in the
auto-
build farm for a nightly build on Gentoo.
I haven't used Gentoo at all, so I can't be of any help to Gentoo- specific things.
.hc
On Mar 12, 2007, at 11:49 AM, m t wrote:
Grab it while its hot at:
http://bugs.gentoo.org/show_bug.cgi?id=151843
Regards, Miron _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
All information should be free. - the hacker ethic
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
News is what people want to keep hidden and everything else is
publicity. - Bill Moyers
just some notes: I was thinking on how to manage releases, since many externals do not have releases numbers. also: in gentoo binary packages aren't much in use. gentoo *is* a build farm: the user compiles the softwares that wants to installs, choosing compile options via tag-like switches (USE flags). (you can actually use it to build binary packages working out-of-the-box) that information is handled in ebuilds, special shell scripts that have the "version&dependency check,fetch,unpack,compile,test,install,merge" recipe.
so a gentoo repository it's just a collection of ebuilds, metadata and changelogs, no bin packages.
a note about the development: to commit ebuilds properly, automating the check of some rules and the writing of changelog, there's a script (sunrise-commit) wich relies on SVN (didn't look how can be adapted to CVS), so it may be better work on pd-overlay project separately, and sync to pd-cvs or wathever vc when doing point releases of pd/pd-ext (also useful for tracking external's versions) (I can add you as developer of pd-overlay, if you are intended to help testing, or fixing ebuilds, or using it as a build platform.... just give me your sf.net usernmae)
about the gentoo version: latest is fine (should be 2006.1, or 2007.0)
I forgot: actually, in the pd-overlay repository, many ebuilds have version -9999 meaning that they are fetched from CVS (a trick to make they appear the latest version). there is a class that handles abstractions/externals fetching from cvs.
otherwise ebuilds can fetch tgz/zip/rar packages from some snapshot
On 4/16/07, federico mescalinum@gmail.com wrote:
just some notes: I was thinking on how to manage releases, since many externals do not have releases numbers. also: in gentoo binary packages aren't much in use. gentoo *is* a build farm: the user compiles the softwares that wants to installs, choosing compile options via tag-like switches (USE flags). (you can actually use it to build binary packages working out-of-the-box) that information is handled in ebuilds, special shell scripts that have the "version&dependency check,fetch,unpack,compile,test,install,merge" recipe.
so a gentoo repository it's just a collection of ebuilds, metadata and changelogs, no bin packages.
a note about the development: to commit ebuilds properly, automating the check of some rules and the writing of changelog, there's a script (sunrise-commit) wich relies on SVN (didn't look how can be adapted to CVS), so it may be better work on pd-overlay project separately, and sync to pd-cvs or wathever vc when doing point releases of pd/pd-ext (also useful for tracking external's versions) (I can add you as developer of pd-overlay, if you are intended to help testing, or fixing ebuilds, or using it as a build platform.... just give me your sf.net usernmae)
about the gentoo version: latest is fine (should be 2006.1, or 2007.0)
-- Federico
On Mon Apr 16, 2007 at 03:44:25AM +0200, federico wrote:
I forgot: actually, in the pd-overlay repository, many ebuilds have version -9999 meaning that they are fetched from CVS (a trick to make they appear the latest version).
URL pls. i find a link to an XML file on sourceforge, that might have contained a link to the repo, but sourceforge is totally broken right now:
Traceback (most recent call last): File "/usr/local/viewvc-1.0.3.sf-new/lib/viewvc.py", line 3660, in main request.run_viewvc() File "/usr/local/viewvc-1.0.3.sf-new/lib/viewvc.py", line 285, in run_viewvc % self.rootname, "404 Repository not found")
there is a class that handles abstractions/externals fetching from cvs.
otherwise ebuilds can fetch tgz/zip/rar packages from some snapshot
On 4/16/07, federico mescalinum@gmail.com wrote:
just some notes: I was thinking on how to manage releases, since many externals do not have releases numbers. also: in gentoo binary packages aren't much in use. gentoo *is* a build farm: the user compiles the softwares that wants to installs, choosing compile options via tag-like switches (USE flags). (you can actually use it to build binary packages working out-of-the-box) that information is handled in ebuilds, special shell scripts that have the "version&dependency check,fetch,unpack,compile,test,install,merge" recipe.
so a gentoo repository it's just a collection of ebuilds, metadata and changelogs, no bin packages.
a note about the development: to commit ebuilds properly, automating the check of some rules and the writing of changelog, there's a script (sunrise-commit) wich relies on SVN (didn't look how can be adapted to CVS), so it may be better work on pd-overlay project separately, and sync to pd-cvs or wathever vc when doing point releases of pd/pd-ext (also useful for tracking external's versions) (I can add you as developer of pd-overlay, if you are intended to help testing, or fixing ebuilds, or using it as a build platform.... just give me your sf.net usernmae)
about the gentoo version: latest is fine (should be 2006.1, or 2007.0)
-- Federico
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
http://pd-overlay.sourceforge.net/
follow the instructions under "Setting up: manually", "Syncing: manually", "Using".
there was one guy taking care of layman config file, but actually don't know if still works... if you want to try, xml file is here: (long url!)
http://pd-overlay.svn.sourceforge.net/viewvc/*checkout*/pd-overlay/stuff/pd-...
On Mon Apr 16, 2007 at 03:39:25AM +0200, federico wrote:
just some notes: I was thinking on how to manage releases, since many externals do not have releases numbers. also: in gentoo binary packages aren't much in use. gentoo *is* a build farm: the user compiles the softwares that wants to installs, choosing compile options via tag-like switches (USE flags). (you can actually use it to build binary packages working out-of-the-box) that information is handled in ebuilds, special shell scripts that have the "version&dependency check,fetch,unpack,compile,test,install,merge" recipe.
so a gentoo repository it's just a collection of ebuilds, metadata and changelogs, no bin packages.
a note about the development: to commit ebuilds properly, automating the check of some rules and the writing of changelog, there's a script (sunrise-commit) wich relies on SVN (didn't look how can be adapted to CVS), so it may be better work on pd-overlay project separately, and sync to pd-cvs or wathever vc when doing point releases of pd/pd-ext (also useful for tracking external's versions) (I can add you as developer of pd-overlay, if you are intended to help testing, or fixing ebuilds, or using it as a build platform.... just give me your sf.net usernmae)
where are the ebuilds now. sunrise? pro-audio? pdlay?
On Apr 15, 2007, at 9:39 PM, federico wrote:
just some notes: I was thinking on how to manage releases, since many externals do not have releases numbers.
That's the reason why there is Pd-extended version numbers. The idea
is that if you use Pd-0.39.2-extended-RC1, for example, on any
platform, it will be built from the _exact_ same code (the library
versions might differ).
also: in gentoo binary packages aren't much in use. gentoo *is* a build farm: the user compiles the softwares that wants to installs, choosing compile options via tag-like switches (USE flags). (you can actually use it to build binary packages working out-of-the-box) that information is handled in ebuilds, special shell scripts that have the "version&dependency check,fetch,unpack,compile,test,install,merge" recipe.
so a gentoo repository it's just a collection of ebuilds, metadata and changelogs, no bin packages.
The point of the auto-build farm is not only to provide binaries.
Actually it performs more important duties: it builds every night
from to make sure that recent checkins to CVS didn't break anything;
and, it gives developers an easy way to make sure that their code
works on other platforms without having to run builds themselves.
That is why there should be a gentoo machine in the auto-build farm.
a note about the development: to commit ebuilds properly, automating the check of some rules and the writing of changelog, there's a script (sunrise-commit) wich relies on SVN (didn't look how can be adapted to CVS), so it may be better work on pd-overlay project separately, and sync to pd-cvs or wathever vc when doing point releases of pd/pd-ext (also useful for tracking external's versions) (I can add you as developer of pd-overlay, if you are intended to help testing, or fixing ebuilds, or using it as a build platform.... just give me your sf.net usernmae)
I don't use gentoo at all, so I'll leave that up to you. Maybe a
good way to manage this is that you guys make releases of pd-overlay,
I check those releases into the pure-data CVS. Then the nightly auto-
builds run using the stuff in pure-data CVS.
The key to making this work is having pd-overlay use the same
directory structure as the pure-data CVS.
about the gentoo version: latest is fine (should be 2006.1, or 2007.0)
I've never installed gentoo. Could you point me to a CD image to
install? Also, once it's installed, will you install all of the
dependencies? I'll give you shell access to do that. Please
document this on a wiki page too.
.hc
-- Federico
On 4/10/07, Hans-Christoph Steiner hans@eds.org wrote:
Ok, I can add you as a developer, but you have to go thru the standard procedure, which is pretty simple. Just send an email to
pd- dev introducing yourself and talk about what work you want to do in the pure-data repository. Also, it's always nice to hear about other projects that you work on using Pd.As for the ebuild, it would be great if it was merged in with the Pd- extended build system. Then we can share the maintenance of it all.
Also, I can set up a Gentoo box in the auto-build farm if you'll finish the setup. Just tell me which version of gentoo should be installed.
.hc
On Apr 9, 2007, at 9:01 AM, federico wrote:
it is ok for me. pd-overlay project is hosted on sourceforge too (see http://pd-overlay.sf.net for info), but using svn; anyway it should be simple moving from svn to CVS.
check also project homepage on sourceforge to see whoever is
actually
working on the project. my username @sourceforge is federico__ as usual :)
On 4/2/07, Hans-Christoph Steiner hans@eds.org wrote:
How about maintaining the Gentoo build files in the pure-data CVS? There already is debian, Mac OS X, Windows, and RedHat package
build
files there. That would make it possible to have nightly auto-
builds
on gentoo also.
.hc
On Mar 16, 2007, at 2:54 PM, federico wrote:
FYI there is a project related to that. it's hosted on sourceforge.net and it's called pd-overlay. (the svn repository is actually THE overlay: just checkout then 'emerge pd zexy maxlib what-you-want')
maybe (I hope) you and others be interested.
you can find some additional information on my page at pd-
portal:
http://www.puredata.info/Members/federico/pd-portage/ that is: using the overlay and creating ebuilds, which is
simple as
writing shell scripts
if anyone is interested in collaborating, please send ebuild
(actually
I'm restoring all my dev stuff, and commit those new ebuilds
soon)
also I can give developer account to active contributors.
actually we have ebuilds for: freeverb~, gem, ggee, gridflow, iem-comport, iemmatrix, iemlib, maxlib, miXed, pdogg, pdp, zexy and others
-- Federico
On 3/12/07, Hans-Christoph Steiner hans@eds.org wrote:
Hey,
Looks good, the more the merrier :) If you are planning on maintaining that, it should be included in the CVS. If you are definitely committed to supporting Pd on Gentoo, then I can setup a Gentoo box in the
auto-
build farm for a nightly build on Gentoo.
I haven't used Gentoo at all, so I can't be of any help to
Gentoo-
specific things.
.hc
On Mar 12, 2007, at 11:49 AM, m t wrote:
Grab it while its hot at:
http://bugs.gentoo.org/show_bug.cgi?id=151843
Regards, Miron _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
All information should be free. - the hacker ethic
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
If you are not part of the solution, you are part of the problem.
On 4/18/07, Hans-Christoph Steiner hans@eds.org wrote:
also: in gentoo binary packages aren't much in use. gentoo *is* a build farm: the user compiles the softwares that wants to installs, choosing compile options via tag-like switches (USE flags). (you can actually use it to build binary packages working out-of-the-box) that information is handled in ebuilds, special shell scripts that have the "version&dependency check,fetch,unpack,compile,test,install,merge" recipe.
so a gentoo repository it's just a collection of ebuilds, metadata and changelogs, no bin packages.
The point of the auto-build farm is not only to provide binaries. Actually it performs more important duties: it builds every night from to make sure that recent checkins to CVS didn't break anything;
I see. That is good,
and, it gives developers an easy way to make sure that their code works on other platforms without having to run builds themselves. That is why there should be a gentoo machine in the auto-build farm.
ok, got it. My advice is to leave the overlay on SVN, also because (hopefully) one day those ebuilds will go in the official gentoo repository, or at least in gentoo-sunrise (one of the biggest addon repos), so the task of syncing ebuilds will be totally transparent (it est: managed by emerge --sync).
until that day, you can add two commands that sync pd-related ebuilds from our repository, just before the line that compiles everything (that will be: emerge media-sound/pd media-plugins/zexy media-plugins/maxlib ...) into your cron job:
-----------[gentoo nightly build script]--------- pushd /usr/local/overlays svn co https://svn.sourceforge.net/svnroot/pd-overlay/pd-overlay popd # emerging stuff, like: # emerge pd maxlib zexy 2>&1 | tee emerge-pd.log -----------------------[end]---------------------
so, whenever something breaks in the gentoo build farm, it could depend on two factors:
- I (or someone of pd-overlay team) has made some mistake in the
ebuild script. I will fix that (pls file bugs at https://sourceforge.net/tracker/?atid=892936&group_id=180376&func=br...)
- A developer changed something (tipically a Makefile) breaking the
gentoo install someway (this can be fixed by both, just a matter of deciding *what* to fix, if the Makefile or the ebuild) or breaking the gentoo compile (this often should be solved upstream)
I don't use gentoo at all, so I'll leave that up to you. Maybe a good way to manage this is that you guys make releases of pd-overlay, I check those releases into the pure-data CVS. Then the nightly auto- builds run using the stuff in pure-data CVS.
I don't think repo-releases are needed. We try to put into SVN only working ebuilds (tested on our computers); the simplest ebuild that compiles and installs with: ./configure && make && make install should be 100% fail-safe
But the point is: actually 99% of our ebuilds have version -9999 (a convention to mean that their sources are pulled from Pd CVS) so they are more subject to break on CVS changes, especially when Makefile stuff like PREFIX and DESTDIR gets touched (!)
Making releases/snapshots for *every* external would help a lot improving reliability; though this is not primary purpose of the project; would be better to rely that each commit on pd-cvs doesn't break anything :)
Also: like other package management, we could mark ebuilds unstable, testing or stable, with simple use of keywords (please see the gentoo manual for more detail on this)
The key to making this work is having pd-overlay use the same directory structure as the pure-data CVS.
can you explain better what do you mean? pd-overlay has the structure of a gentoo ebuild tree. I don't believe it can be altered in some way
I've never installed gentoo. Could you point me to a CD image to install? Also, once it's installed, will you install all of the dependencies? I'll give you shell access to do that. Please document this on a wiki page too.
if you are going to install gentoo on x86 arch:
- get the install ISO here: http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&os=x86
- refer to the x86 handbook for installing: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml
the same applies for other archs, like ppc, ia64, amd64, ppc64, hppa, alpha, ...
dependencies are checked automatically, so emerge-ing pd would install also Xorg, alsa, tcl, tk, etc....
anyway I can check your box for consistance :) just do the initial part of the install so that it can be bootable, then mail me ssh access, or let us meet on irc
It seems that these ebuild files could use the existing build system
quite easily. The existing system isn't always pretty, but it
works. And ultimately we will both be better off if we join forces
rather than have duplicate efforts. I am definitely open to
improving the existing system. And I can help get you up to speed
via email, IM, IRC, voice, whatever.
For example, in maxlib/maxlib-9999.ebuild, it could call the existing
build system like this:
src_compile() { make -C /path/to/pure-data/externals maxlib }
src_install() { make -C /path/to/pure-data/externals DESTDIR="${D}" maxlib_install }
And that would be enough to build and install. This is how it was
done for PlanetCCRMA. Then you could generate this same .ebuild file
using a script for all of the libraries built by Pd-extended. That
also means that a given developer could manage just their own
Makefile, and the changes will automatically be used in all the
builds, including the gentoo. Otherwise, you'll have to keep up with
the changes that developers make to their own code.
Here is the current list of libraries that are built this way: boids
bsaylor creb cxc cyclone deprecated ekext ext13 flatspace flib
freeverb ggee hardware hcs iem_ambi iem_bin_ambi iemlib jasch_lib
loaders mapping markex maxlib mjlib motex mrpeach msd oscx pan pddp
pdogg pmpd sigpack smlib toxy unauthorized vbap zexy pdcontainer
adaptive iem_delay iem_roomsim iem_spec2 iem_tab flashserver iemgui
iem_adaptfilt iemmatrix iem_matrix iemxmlrpc iem16 earplug hid pdp
pidip hdspm_mixer
On Apr 19, 2007, at 2:53 PM, federico wrote:
My advice is to leave the overlay on SVN, also because (hopefully) one day those ebuilds will go in the official gentoo repository, or at least in gentoo-sunrise (one of the biggest addon repos), so the task of syncing ebuilds will be totally transparent (it est: managed by emerge --sync).
until that day, you can add two commands that sync pd-related ebuilds from our repository, just before the line that compiles everything (that will be: emerge media-sound/pd media-plugins/zexy media-plugins/maxlib ...) into your cron job:
-----------[gentoo nightly build script]--------- pushd /usr/local/overlays svn co https://svn.sourceforge.net/svnroot/pd-overlay/pd-overlay popd # emerging stuff, like: # emerge pd maxlib zexy 2>&1 | tee emerge-pd.log -----------------------[end]---------------------
so, whenever something breaks in the gentoo build farm, it could depend on two factors:
- I (or someone of pd-overlay team) has made some mistake in the
ebuild script. I will fix that (pls file bugs at https://sourceforge.net/tracker/? atid=892936&group_id=180376&func=browse)
- A developer changed something (tipically a Makefile) breaking the
gentoo install someway (this can be fixed by both, just a matter of deciding *what* to fix, if the Makefile or the ebuild) or breaking the gentoo compile (this often should be solved upstream)
I don't use gentoo at all, so I'll leave that up to you. Maybe a good way to manage this is that you guys make releases of pd-overlay, I check those releases into the pure-data CVS. Then the nightly
auto- builds run using the stuff in pure-data CVS.I don't think repo-releases are needed.
Right now, one of the key reasons why the auto-build farm is limited
to the pure-data CVS on SourceForge is because of security.
Basically, anyone who has commit access to the pure-data CVS can run
any script they want on all of the machines. Therefore, I need to
keep tabs on what scripts are being added to the CVS. I also know
who has commit access to the pure-data CVS.
Ideally, I wouldn't have to worry about security, but these machines
are hosted by the university I work at. If they get hacked, IT will
tell me to remove them from the network. Then we have no more auto-
build farm.
We try to put into SVN only working ebuilds (tested on our computers); the simplest ebuild that compiles and installs with: ./configure && make && make install should be 100% fail-safe
But the point is: actually 99% of our ebuilds have version -9999 (a convention to mean that their sources are pulled from Pd CVS) so they are more subject to break on CVS changes, especially when Makefile stuff like PREFIX and DESTDIR gets touched (!)
Making releases/snapshots for *every* external would help a lot improving reliability; though this is not primary purpose of the project; would be better to rely that each commit on pd-cvs doesn't break anything :)
Also: like other package management, we could mark ebuilds unstable, testing or stable, with simple use of keywords (please see the gentoo manual for more detail on this)
The key to making this work is having pd-overlay use the same directory structure as the pure-data CVS.
can you explain better what do you mean? pd-overlay has the structure of a gentoo ebuild tree. I don't believe it can be altered in some way
I mean that when the ebuild is looking for externals/Makefile, it
knows it can find it at ../../external/Makefile, whether in pd-
overlay or pure-data CVS. Make sense? Other than that, it doesn't
matter. This could also be done like this:
PURE-DATA_ROOT=/path/to/pure-data
then the ebuild script would use $PURE-DATA_ROOT/externals/Makefile,
and PURE-DATA_ROOT could be set for each location.
I've never installed gentoo. Could you point me to a CD image to install? Also, once it's installed, will you install all of the dependencies? I'll give you shell access to do that. Please document this on a wiki page too.
if you are going to install gentoo on x86 arch:
- get the install ISO here:
http://bouncer.gentoo.org/?product=gentoo-2006.1-minimal&os=x86
- refer to the x86 handbook for installing:
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml
the same applies for other archs, like ppc, ia64, amd64, ppc64,
hppa, alpha, ...dependencies are checked automatically, so emerge-ing pd would install also Xorg, alsa, tcl, tk, etc....
anyway I can check your box for consistance :) just do the initial part of the install so that it can be bootable, then mail me ssh access, or let us meet on irc
sure, #dataflow? I'll try to start this tomorrow, otherwise Mon or Wed.
.hc
-- Federico
The arc of history bends towards justice. - Dr. Martin Luther
King, Jr.
On 4/20/07, Hans-Christoph Steiner hans@eds.org wrote:
It seems that these ebuild files could use the existing build system quite easily. The existing system isn't always pretty, but it works. And ultimately we will both be better off if we join forces rather than have duplicate efforts. I am definitely open to improving the existing system.
yeah! that sounds good, and is definitely better than having to patch Makefiles from within ebuilds. (like in line21 of maxlib-9999 http://pd-overlay.svn.sourceforge.net/viewvc/pd-overlay/pd-overlay/media-plu... )
I can also help in fixing Makefiles, e.g. by collecting fixes, patches and sed oneliners from our ebuilds
And I can help get you up to speed via email, IM, IRC, voice, whatever.
For example, in maxlib/maxlib-9999.ebuild, it could call the existing build system like this:
src_compile() { make -C /path/to/pure-data/externals maxlib }
src_install() { make -C /path/to/pure-data/externals DESTDIR="${D}" maxlib_install }
And that would be enough to build and install. This is how it was done for PlanetCCRMA. Then you could generate this same .ebuild file using a script for all of the libraries built by Pd-extended.
I also would definitely prefer using your build system, since everything resides in Makefiles, and consequentially everything is less error-prone.
I am making an all-in-one pd-extended ebuild, for testing all the (supported) externals, wich is as simple as writing:
# USE="oscx maxlib zexy" emerge =media-sound/pd-extended-9999
explanation: here I used USE flags to select which externals to compile. generally those flags enable configure switches or compile time features. I used them to make everything fit into one ebuild, but if we like having many separate ebuilds, it is very easy to split it up.
here is the actual ebuild, just in case you want to review how I did use your build system: http://pd-overlay.svn.sourceforge.net/viewvc/pd-overlay/pd-overlay/media-sou... (also submitting it to the gentoo-people's attention)
ciao
Federico
im trying to get the ebuild to build http://www-crca.ucsd.edu/~msp/Software/pd-0.41-0test04.src.tar.gz
and wondering about the necessity of this line:
MY_P="${P/_p/-}"
i think this means i need a
pd-0.41_p0test04.ebuild
but portage says:
!!! media-sound/pd-0.41_p0test04 does not follow correct package syntax.
when trying to generate the digest
latest version is pd-0.40-2.src.tar.gz :d
anyway, if you want to build that version probably you need to change SRC_URI variable to something like: pd-${PV}test04.src.tgz
I haven't worked much with 0.41.x or 0.40.x yet, so I don't really
know the issues. I do know that Pd-extended 0.40.x builds since it's
in the auto-build page.
.hc
On Apr 22, 2007, at 5:49 AM, federico wrote:
latest version is pd-0.40-2.src.tar.gz :d
anyway, if you want to build that version probably you need to change SRC_URI variable to something like: pd-${PV}test04.src.tgz
-- Federico
On 4/19/07, carmen _@whats-your.name wrote:
im trying to get the ebuild to build http://www-crca.ucsd.edu/~msp/Software/pd-0.41-0test04.src.tar.gz
and wondering about the necessity of this line:
MY_P="${P/_p/-}"
i think this means i need a
pd-0.41_p0test04.ebuild
but portage says:
!!! media-sound/pd-0.41_p0test04 does not follow correct package
syntax.when trying to generate the digest
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
I spent 33 years and four months in active military service and
during that period I spent most of my time as a high class muscle man
for Big Business, for Wall Street and the bankers. - General
Smedley Butler
Any interest in expanding that to PD extended? Vanilla PD is so *boring* .... ;-)
m t wrote:
Grab it while its hot at:
-
carmen -
Derek Holzer -
federico -
Hans-Christoph Steiner -
m t