IOhannes m zmoelnig wrote:
the svn client installed on the build-machine (/sw/bin/svn) is somewhat outdated (1.4.4) and refuses to "svn update" the sandbox.
this seems to be a common problem on more of the build machines (e.g. i just noticed it on the ubuntu-hardy-lts-i386)
for me this makes working on these machines a bit strange: you fix the code, login to the build machine, try to "svn update" (or rather: "svn info" or "svnversion" to see which revision was actually used) and get "svn: This client is too old to work with working copy"
what?
i guess, that for performance reasons (the sf repositories often suck) the repository is pulled only to a central machine and then distributed via rsync to the various build hosts. however, i haven't found any documentation on this.
it would be nice if the tools installed on the build hosts would be able to cope with the repository. if this is too much hazzle (e.g. setting up a proxy, or whatever), could somebody learned please document e.g. on http://puredata.info/docs/developer/PdLab (or somewhere linked from there; or in the nice splashscreen on the build-machines) what is to be expected and what not?
the workaround that does work (it seems), is to do another checkout with the system's own svn and work in this sandbox. i usually do this only on 2nd choice (in order to save bandwidth).
i guess it's just a matter of knowing.
fbm,asdr IOhannes
On Dec 1, 2009, at 8:57 AM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
the svn client installed on the build-machine (/sw/bin/svn) is somewhat outdated (1.4.4) and refuses to "svn update" the sandbox.
this seems to be a common problem on more of the build machines (e.g. i just noticed it on the ubuntu-hardy-lts-i386)
for me this makes working on these machines a bit strange: you fix the code, login to the build machine, try to "svn update" (or rather: "svn info" or "svnversion" to see which revision was actually used) and get "svn: This client is too old to work with working copy"
what?
i guess, that for performance reasons (the sf repositories often suck) the repository is pulled only to a central machine and then distributed via rsync to the various build hosts. however, i haven't found any documentation on this.
it would be nice if the tools installed on the build hosts would be able to cope with the repository. if this is too much hazzle (e.g. setting up a proxy, or whatever), could somebody learned please document e.g. on http://puredata.info/docs/developer/PdLab (or somewhere linked from there; or in the nice splashscreen on the build-machines) what is to be expected and what not?
the workaround that does work (it seems), is to do another checkout with the system's own svn and work in this sandbox. i usually do this only on 2nd choice (in order to save bandwidth).
i guess it's just a matter of knowing.
fbm,asdr IOhannes
This is the documentation of the auto-build process, the last step is where it rsyncs over the source tree, which is mainly for rsync's -- delete for a real clean start.
http://puredata.info/docs/developer/AutoBuildProcess
hardy's svn is indeed old (1.4.4). The checkouts are actually done on Debian/stable which has svn 1.5.1. I'd recommend working on Debian/ stable or Ubuntu/karmic. Otherwise on hardy, you'll need to check out the code using its svn version in a separate folder.
.hc
----------------------------------------------------------------------------
All information should be free. - the hacker ethic
Hans-Christoph Steiner wrote:
This is the documentation of the auto-build process, the last step is where it rsyncs over the source tree, which is mainly for rsync's --delete for a real clean start.
obviously i didn't find it from PdLab (the other way round is simple). i modified the page accordingly.
hardy's svn is indeed old (1.4.4). The checkouts are actually done on Debian/stable which has svn 1.5.1. I'd recommend working on Debian/stable or Ubuntu/karmic.
? i recommend working on debian/sid, but this doesn't help me much if one of the autobuilds fails on the osx103 machine. i prefer to investigate directly what is going wrong on the failing machine (and potentially fix the problem there)
Otherwise on hardy, you'll need to check out the code using its svn version in a separate folder.
yep, that's what i did.
speaking of which: are the splashscreen scripts on the PdLab machines in the repository somewhere? (probably in the "hans" CVS). i "had to" fix the one on the osx104-i386. and i'd like to add the info about the SVN there (it's just that i don't know the docs on pd.info by heart; and when i'm fixing a simple problem in C, i don't feel very inclined to reread the page to be able to get rid of the small annoyances)
fgmasdr IOhannes
On Dec 2, 2009, at 3:22 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
This is the documentation of the auto-build process, the last step is where it rsyncs over the source tree, which is mainly for rsync's --delete for a real clean start.
obviously i didn't find it from PdLab (the other way round is simple). i modified the page accordingly.
hardy's svn is indeed old (1.4.4). The checkouts are actually done on Debian/stable which has svn 1.5.1. I'd recommend working on Debian/stable or Ubuntu/karmic.
? i recommend working on debian/sid, but this doesn't help me much if one of the autobuilds fails on the osx103 machine. i prefer to investigate directly what is going wrong on the failing machine (and potentially fix the problem there)
There isn't a 10.3 machine, there is a 10.4/Intel machine, and the 10.4/PowerPC machine should return soon, once I get its dead disk sorted out. The 10.4/Intel machine has svn 1.6.6.
Otherwise on hardy, you'll need to check out the code using its svn version in a separate folder.
yep, that's what i did.
speaking of which: are the splashscreen scripts on the PdLab machines in the repository somewhere? (probably in the "hans" CVS). i "had to" fix the one on the osx104-i386. and i'd like to add the info about the SVN there (it's just that i don't know the docs on pd.info by heart; and when i'm fixing a simple problem in C, i don't feel very inclined to reread the page to be able to get rid of the small annoyances)
Its the ~/.bash_profile. Send me an updated version and I'll distribute it on the machines. I don't really want to get into changing all those files. Its enough work as it is.
.hc
----------------------------------------------------------------------------
Hans-Christoph Steiner wrote:
i recommend working on debian/sid, but this doesn't help me much if one of the autobuilds fails on the osx103 machine. i prefer to investigate directly what is going wrong on the failing machine (and potentially fix the problem there)
There isn't a 10.3 machine, there is a 10.4/Intel machine, and the
right, this was just an example: i want to fix a thing on a certain machine which not necessarily is one of the "suggested" ones.
10.4/PowerPC machine should return soon, once I get its dead disk sorted out. The 10.4/Intel machine has svn 1.6.6.
i'm pretty sure i did log into the osx10/i386 machine. and it had 1.4.4 installed when i did (which was on 24th of november)
i see that now there is 1.6.6 installed (compiled on 26th of november). maybe it was just bad timing.
Its the ~/.bash_profile. Send me an updated version and I'll distribute it on the machines. I don't really want to get into changing all those files. Its enough work as it is.
the "problem" was that on the osx104/i386 there is no "seq" command. so i replaced it with a literal enumeration (i know that a for loop would have been more elegant...)
this way, the first thing you get when logging in, is not an error message any more.
mfgasdr IOhannes
On Dec 2, 2009, at 11:49 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
i recommend working on debian/sid, but this doesn't help me much if one of the autobuilds fails on the osx103 machine. i prefer to investigate directly what is going wrong on the failing machine (and potentially fix the problem there)
There isn't a 10.3 machine, there is a 10.4/Intel machine, and the
right, this was just an example: i want to fix a thing on a certain machine which not necessarily is one of the "suggested" ones.
10.4/PowerPC machine should return soon, once I get its dead disk sorted out. The 10.4/Intel machine has svn 1.6.6.
i'm pretty sure i did log into the osx10/i386 machine. and it had 1.4.4 installed when i did (which was on 24th of november)
i see that now there is 1.6.6 installed (compiled on 26th of november). maybe it was just bad timing.
Its the ~/.bash_profile. Send me an updated version and I'll distribute it on the machines. I don't really want to get into changing all those files. Its enough work as it is.
the "problem" was that on the osx104/i386 there is no "seq" command. so i replaced it with a literal enumeration (i know that a for loop would have been more elegant...)
this way, the first thing you get when logging in, is not an error message any more.
mfgasdr IOhannes <bp.tgz>
FYI: I reparented the PdLab page to the FrontPage rather than the AutoBuildProcess page. The Pdlab is not only for the auto-builds, but also for devs to work on foreign machines. The AutoBuildProcess page already has links to the PdLab pages.
I wasn't having any bash errors on logging in, but I installed your updated .bash_profile
.hc
----------------------------------------------------------------------------
If you are not part of the solution, you are part of the problem.
Hans-Christoph Steiner wrote:
FYI: I reparented the PdLab page to the FrontPage rather than the AutoBuildProcess page. The Pdlab is not only for the auto-builds, but also for devs to work on foreign machines. The AutoBuildProcess page already has links to the PdLab pages.
well, PdLab being child of AutoBuildProcess will automagically give you links to both FrontPage and AutoBuildProcess. it will be automagically visible from FrontPage as well (in the TOC)
i was missing alink from PdLab to AutoBuildProcess and (debatably) thought it more elegant to do reparenting than to add yet another link.
I wasn't having any bash errors on logging in, but I installed your updated .bash_profile
that's because i already applied it on the osx104/i386 when i went there in november. what i sent you was actually directly taken from osx104/i386.
fmgsadr IOhannes
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
FYI: I reparented the PdLab page to the FrontPage rather than the AutoBuildProcess page. The Pdlab is not only for the auto-builds, but also for devs to work on foreign machines. The AutoBuildProcess page already has links to the PdLab pages.
well, PdLab being child of AutoBuildProcess will automagically give you links to both FrontPage and AutoBuildProcess. it will be automagically visible from FrontPage as well (in the TOC)
i was missing a link from PdLab to AutoBuildProcess and (debatably) thought it more elegant to do reparenting than to add yet another link.
read: i don't really care about the parent; and since there is now a link from PdLab to AutoBuildProcess _and_ an mentioning of the svn situation, i'm happy.
fgmadsr IOhannes
On Dec 2, 2009, at 12:16 PM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
FYI: I reparented the PdLab page to the FrontPage rather than the AutoBuildProcess page. The Pdlab is not only for the auto-builds, but also for devs to work on foreign machines. The AutoBuildProcess page already has links to the PdLab pages.
well, PdLab being child of AutoBuildProcess will automagically give you links to both FrontPage and AutoBuildProcess. it will be automagically visible from FrontPage as well (in the TOC)
i was missing a link from PdLab to AutoBuildProcess and (debatably) thought it more elegant to do reparenting than to add yet another link.
read: i don't really care about the parent; and since there is now a link from PdLab to AutoBuildProcess _and_ an mentioning of the svn situation, i'm happy.
Ok, cool, thanks for the update of the page. I just don't want to randomly change the structure of that stuff.
.hc
----------------------------------------------------------------------------
Mistrust authority - promote decentralization. - the hacker ethic
-
Hans-Christoph Steiner -
IOhannes m zmoelnig