some of the autobuilds have been failing for ages now, because of a change introduced into Gem's directory layout, the autobuild system's adaption to it and some somewhat out-of-sync autobuild hosts.
Subject: [PD-cvs] autobuild: pd-main+libs debian-testing-i386 Subject: [PD-cvs] autobuild: pd-puredyne debian-testing-i386 Subject: [PD-cvs] autobuild: pd-main+libs ubuntu-hardy-i386 2008-08-26
all of these are failing, because of the following history: - Gem has switched form CVS to SVN - the autobuild system (or rather: the human that is behind that: hans) has tracked Gem's switch to svn - i have tidied up Gem a bit and moved the "manual/" into the "doc/" section - hans has adapted the autobuild system accordingly - somehow some machines got out of sync: they have updated their autobuild system to include the change in the directory layout, but are still using the CVS version of Gem (where this change has not yet occured) - these machines fail to build each night
i think it is related to the re-occuring (e.g. see the current thread on flext-svn) discussion of svn:externals
as i can see it, there are 2 main arguments against svn:externals - (fear of) problems when doing "svn update" (e.g. due to unofficial certificates) - (fear of) problems when re-structuring the repository (e.g. when importing code that was previously integrated via svn:externals)
as can be seen by the example above, also the alternative approach (using scripts to explicitely checkout a remote repository) is not foolproof (well nothing is), and actually exhibits the very problems because of which it is used (apart from legacy reasons for sticking to them)
mfg.dsr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Sorry, I am very slammed right now, so I didn't have time to look at this build issue. I moved everything to point to the Gem SVN now, so it should work fine.
Instead of svn:externals, another option is to import gem releases into the pure-data SVN. I am working a lot now with openembedded, and basically all the code used there is pegged to a certain release version. With big distros like Pd-extended, that is necessary in order to get anything released. I suppose it would also be possible then to have a Gem-only nightly build.
Moving gem development to the pure-data SVN would also solve this issue, so there are many ways to do it. If someone wants to run a build farm and maintain Pd-extended, I'll happily defer to them on these questions. But right now, for me, svn:externals solves no problems and also creates new problems.
.hc
On Aug 27, 2008, at 9:30 PM, zmoelnig@iem.at wrote:
some of the autobuilds have been failing for ages now, because of a change introduced into Gem's directory layout, the autobuild system's adaption to it and some somewhat out-of-sync autobuild hosts.
Subject: [PD-cvs] autobuild: pd-main+libs debian-testing-i386 Subject: [PD-cvs] autobuild: pd-puredyne debian-testing-i386 Subject: [PD-cvs] autobuild: pd-main+libs ubuntu-hardy-i386 2008-08-26
all of these are failing, because of the following history:
- Gem has switched form CVS to SVN
- the autobuild system (or rather: the human that is behind that:
hans) has tracked Gem's switch to svn
- i have tidied up Gem a bit and moved the "manual/" into the
"doc/" section
- hans has adapted the autobuild system accordingly
- somehow some machines got out of sync: they have updated their
autobuild system to include the change in the directory layout, but are still using the CVS version of Gem (where this change has not yet occured)
- these machines fail to build each night
i think it is related to the re-occuring (e.g. see the current thread on flext-svn) discussion of svn:externals
as i can see it, there are 2 main arguments against svn:externals
- (fear of) problems when doing "svn update" (e.g. due to unofficial
certificates)
- (fear of) problems when re-structuring the repository (e.g. when
importing code that was previously integrated via svn:externals)
as can be seen by the example above, also the alternative approach (using scripts to explicitely checkout a remote repository) is not foolproof (well nothing is), and actually exhibits the very problems because of which it is used (apart from legacy reasons for sticking to them)
mfg.dsr IOhannes
This message was sent using IMP, the Internet Messaging Program.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
Hans-Christoph Steiner wrote:
Sorry, I am very slammed right now, so I didn't have time to look at this build issue. I moved everything to point to the Gem SVN now, so it should work fine.
thanks
Instead of svn:externals, another option is to import gem releases into the pure-data SVN. I am working a lot now with openembedded, and basically all the code used there is pegged to a certain release version. With big distros like Pd-extended, that is necessary in order to get anything released. I suppose it would also be possible then to have a Gem-only nightly build.
yes that would be an option, though it might be even more work than it is now. i still think that the svn is more than just the release system for pd-extended.
Moving gem development to the pure-data SVN would also solve this
right, but i won't do that;
issue, so there are many ways to do it. If someone wants to run a build farm and maintain Pd-extended, I'll happily defer to them on these questions. But right now, for me, svn:externals solves no problems and also creates new problems.
no problem; i just wanted to point out that it seemed to me that the main problem with svn:externals (as you described it previously) also exists in the current layout we are using.
mfga.sdr IOhannes
On Mon, 8 Sep 2008, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Sorry, I am very slammed right now, so I didn't have time to look at this build issue. I moved everything to point to the Gem SVN now, so it should work fine.
thanks
Instead of svn:externals, another option is to import gem releases into the pure-data SVN. I am working a lot now with openembedded, and basically all the code used there is pegged to a certain release version. With big distros like Pd-extended, that is necessary in order to get anything released. I suppose it would also be possible then to have a Gem-only nightly build.
yes that would be an option, though it might be even more work than it is now. i still think that the svn is more than just the release system for pd-extended.
I also think it is not just a release system for Pd-extended. The question is more what it should be going forward. I think the pure-data repository has worked really well in bringing the community of developers together. But it is not working so well now, perhaps because it isn't clearly defined, or because we have different needs now.
- For Pd-extended, there needs to be a repository to do code freezes and bug fixes, branches work pretty well for that.
- for making a central place to find code, I think we'd be better off with a 'libraries' page like http://processing.org has.
- for nightly builds, I think that ideally there would be a way to build libraries separately from Pd-extended, but that's a matter of someone doing the work. Running something like buildbot would be really nice.
That's my two bits.
.hc
Moving gem development to the pure-data SVN would also solve this
right, but i won't do that;
issue, so there are many ways to do it. If someone wants to run a build farm and maintain Pd-extended, I'll happily defer to them on these questions. But right now, for me, svn:externals solves no problems and also creates new problems.
no problem; i just wanted to point out that it seemed to me that the main problem with svn:externals (as you described it previously) also exists in the current layout we are using.
mfga.sdr IOhannes
zen \ \ \[D[D[D[D
Hans-Christoph Steiner wrote:
developers together. But it is not working so well now, perhaps because it isn't clearly defined, or because we have different needs now.
do you think so? and why?
- For Pd-extended, there needs to be a repository to do code freezes and
bug fixes, branches work pretty well for that.
which is what we have now. the important thing is (imho), to not distinguish between "upstream" versions and "packaging" versions as far as possible. since the Pd-community is so small, i don't think this is a real problem to maintain (unlike e.g. with debian)
- for making a central place to find code, I think we'd be better off
with a 'libraries' page like http://processing.org has.
yes: yet another page to maintain!
- for nightly builds, I think that ideally there would be a way to build
libraries separately from Pd-extended, but that's a matter of someone doing the work. Running something like buildbot would be really nice.
yes!
gfmadsr IOhannes
On Sep 10, 2008, at 3:26 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
developers together. But it is not working so well now, perhaps because it isn't clearly defined, or because we have different needs now.
do you think so? and why?
One example: There are lots of people who want to use a separate repository. There isn't a clean way to include that code. Plus we are having to discuss how to use the SVN a lot, so there are conflicting ideas of how we should use it.
- For Pd-extended, there needs to be a repository to do code
freezes and bug fixes, branches work pretty well for that.
which is what we have now. the important thing is (imho), to not distinguish between "upstream" versions and "packaging" versions as far as possible. since the Pd-community is so small, i don't think this is a real problem to maintain (unlike e.g. with debian)
That's why I think making a clean and easy to use library format is the #1 priority. Then people maintain their own releases.
- for making a central place to find code, I think we'd be better
off with a 'libraries' page like http://processing.org has.
yes: yet another page to maintain!
If that page was a wiki page, it would open up the maintenance to more people. Plus they wouldn't have to learn/use SVN if they didn't want to. With the current system, you have to be a developer in the pure-data project and you have to use SVN. So it would be a matter of shifting maintenance. Plus this information doesn't change a lot. Here's the page in question:
http://processing.org/reference/libraries/index.html
- for nightly builds, I think that ideally there would be a way to
build libraries separately from Pd-extended, but that's a matter of someone doing the work. Running something like buildbot would be really nice.
yes!
gfmadsr IOhannes
------------------------------------------------------------------------ ----
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
hi
it's early in the morning and while writing the below lines, i notice that i am grumpy as ever. you can probably just skip the rest of the email :-)
Hans-Christoph Steiner wrote:
On Sep 10, 2008, at 3:26 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
developers together. But it is not working so well now, perhaps because it isn't clearly defined, or because we have different needs now.
do you think so? and why?
One example: There are lots of people who want to use a separate repository. There isn't a clean way to include that code. Plus we are having to discuss how to use the SVN a lot, so there are conflicting ideas of how we should use it.
i think there are 2 main reasons why people prefer their own repositories: - they want to be independent - they believe that the puredata repository is not meant for them
#1 is a social issue; i don't think it can nor should be solved! people will always want to have some freedom of choice, even if they finally chose mainstream. for me, it's the main reason to not have Gem in the puredata repo.
#2 is (i guess) mostly because of our (yours and mine) discussion about what the svn is actually for; if people are prohibited to import their code into the repository because it is under development, it is no wonder that they won't want to develop in this repository.
my (well know and simplistic) approaches favour development rather than stability. no need to discuss them again, i think :-)
- For Pd-extended, there needs to be a repository to do code freezes
and bug fixes, branches work pretty well for that.
which is what we have now. the important thing is (imho), to not distinguish between "upstream" versions and "packaging" versions as far as possible. since the Pd-community is so small, i don't think this is a real problem to maintain (unlike e.g. with debian)
That's why I think making a clean and easy to use library format is the #1 priority. Then people maintain their own releases.
hmm; grumpy mode on:
"That's why I think making a clean and easy to use library format is the #1 priority." --> i think we again hit the "social barrier" i was talking about in the last paragraph; (at least if i correctly read the "easy to use library format" as the one and only libdir format proposed so many years ago)
"Then people maintain their own releases" --> sorry i cannot resist: that's a fine piece of freedom, what else to we want
:grumpy mode off
- for making a central place to find code, I think we'd be better off
with a 'libraries' page like http://processing.org has.
yes: yet another page to maintain!
If that page was a wiki page, it would open up the maintenance to more people.
ouch, sarcasm mode on: like all the other well-accepted community-maintained wiki pages on puredata.info? (ok, that's a bad wiki engine, how about...:) or more like pdpedia? (i just wanted to check it, but unfortunately it is currently down)
Plus they wouldn't have to learn/use SVN if they didn't want to.
so what? do you imply that svn is too hard to learn? esp, do you think that it is harder to learn than any markup language?
With the current system, you have to be a developer in the pure-data project and you have to use SVN. So it would be a matter of shifting maintenance. Plus this information doesn't change a lot. Here's the page in question:
yes i was aware of that page (though it took me some time to find it).
it somehow reminds me of http://puredata.info/community/projects/software which is a bit sparse because nobody but me commits to it; even though it is open to all members of the portal to put stuff there... what does this tell us?
fdgmasrd IOhannes
PS: had to changet he subject, cannot read the "sucks" anymore...
Hi,
I tried to use svn to downlad pd sources and a few libraries for developing an external, but whatever the address I put, it always downloads all the stuff from everyone, every versions, this is really inconvenient, I have to be root for deleting the downloaded files, even if it has been downloaded with user account. I might not use the good downloading method?
Hi again,
Sorry for the "I have to be root for deleting the downloaded files",
I've used the wrong command to delete pure-data folder, instead of using rm -rf, I've used sudo rm -r
Le jeudi 11 septembre 2008 à 12:22 +0200, patco a écrit :
Hi,
I tried to use svn to downlad pd sources and a few libraries for developing an external, but whatever the address I put, it always downloads all the stuff from everyone, every versions, this is really inconvenient, I have to be root for deleting the downloaded files, even if it has been downloaded with user account. I might not use the good downloading method?
patco wrote:
Hi,
I tried to use svn to downlad pd sources and a few libraries for developing an external, but whatever the address I put, it always downloads all the stuff from everyone, every versions,
works fine here.
an example of selective download:
claude@minimus:~/tmp/svn$ svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/extra/pique A pique/pique.c A pique/pique-help.pd A pique/makefile Checked out revision 10284. claude@minimus:~/tmp/svn$
Ok I see now what error I've made, instead of using:
svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/
I've used:
svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data pure-data/branches/pd/pd-0.40-3
thanks for fast answer
Le jeudi 11 septembre 2008 à 12:20 +0100, Claude Heiland-Allen a écrit :
patco wrote:
Hi,
I tried to use svn to downlad pd sources and a few libraries for developing an external, but whatever the address I put, it always downloads all the stuff from everyone, every versions,
works fine here.
an example of selective download:
claude@minimus:~/tmp/svn$ svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/extra/pique A pique/pique.c A pique/pique-help.pd A pique/makefile Checked out revision 10284. claude@minimus:~/tmp/svn$
patco wrote:
Hi,
I tried to use svn to downlad pd sources and a few libraries for developing an external, but whatever the address I put, it always downloads all the stuff from everyone, every versions, this is really inconvenient,
well, you can download tarballs directly via the viewvc interface: e.g. getting the hottest zexy (and zexy alone) without any knowledge of svn, just use http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/zexy.t... (you will find a "Download GNU tarball" to a dynamically created tarfile for every subdirectory at (e.g.) http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/
mfga.sdr IOhannes
On 11/09/2008, at 10.08, IOhannes m zmoelnig wrote:
what does this tell us?
grumpy-mode on. Nothing specifically.
Maybe announcing it's existence would help. Maybe the publishing flow is rough. Maybe people don't care to use it. And maybe people don't care to use puredata.info, which might be what you were thinking of.
-
Claude Heiland-Allen -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
patco -
Steffen Juul -
zmoelnig＠iem.at