Re: [GEM-dev] CVS Gem.linux load error: undefined symbol: glUniform4iARB Gem: can't load library
On Mon, 8 May 2006, IOhannes m zmoelnig wrote:
unfortunately right now the CVS is rather bleeding than edge. (the anonymous access is really a month or so behind...)
I can testify that it's at least one month. Thanks for making me notice, it can help me plan in advance.
If this doesn't change by June 1st then I'm 100% sure that I'm forking devel_0_39 pd in order to be able to have a sensible anonymous CVS. Either that or figuring out how to make a 0-minute-delay anonymous-mirror by using a combination of CVS watches and my SourceForget luser account, but I doubt that I'll take the time to learn CVS deep enough to be able to do this. (If anyone can do this for us I'll be grateful)
I say June 1st because by then we'll have a new artengine.ca server running, with Debian (instead of SuSE). I also say that because I want one from the moment that DesireData 0.39.A comes out, so that I can easily send instant bugfixes to users who are not "worthy" enough to get access to the :ext: SourceForget CVS. I don't know when 0.39.A would be ready, but it'll be at about that time.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Mon, 8 May 2006, Mathieu Bouchard wrote:
from the moment that DesireData 0.39.A comes out, so that I can easily send instant bugfixes to users who are not "worthy" enough to get access to the :ext: SourceForget CVS.
I am sorry but it won't be possible to add all users of DesireData 0.39.A to the developer CVS. SF suggest to have at most 20 developers, Pd CVS has already 54. Finding a better host for the CVS would be good though, maybe this can go in line with an svn transition.
Any volunteer to take the lead in that ?
Günter
I don't know when 0.39.A would be ready, but it'll be at about that time.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On 8 May 2006, at 16:43, geiger wrote:
I am sorry but it won't be possible to add all users of DesireData 0.39.A to the developer CVS. SF suggest to have at most 20 developers, Pd CVS has already 54. Finding a better host for the CVS would be good though, maybe this can go in line with an svn transition.
Any volunteer to take the lead in that ?
Are you talking about finding completely alternative hosting to SourceForge, for SVN hosting Puredata on the whole?
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On Mon, 8 May 2006, David Plans Casal wrote:
On 8 May 2006, at 16:43, geiger wrote:
I am sorry but it won't be possible to add all users of DesireData 0.39.A to the developer CVS. SF suggest to have at most 20 developers, Pd CVS has already 54. Finding a better host for the CVS would be good though, maybe this can go in line with an svn transition. Any volunteer to take the lead in that ?
Are you talking about finding completely alternative hosting to SourceForge, for SVN hosting Puredata on the whole?
I don't know whether Günter means switching away from SourceForge, but I really think that the whole Pd CVS should leave SourceForge right now. The web services like patch-tracker and bug-tracker and downloads and such can all stay on SourceForge, I don't mind, but the CVS has to leave because there are too many problems.
Actually, because Chun and I really have to work on DD alot these days and the CVS is just plain down, we'd rather move out tomorrow than waiting June 1st, but if SF is up tomorrow until the 30th I don't mind. If SF has longer downtime I'll make an emergency fork.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Tue, 9 May 2006, Mathieu Bouchard wrote:
On Mon, 8 May 2006, David Plans Casal wrote:
On 8 May 2006, at 16:43, geiger wrote:
I am sorry but it won't be possible to add all users of DesireData 0.39.A to the developer CVS. SF suggest to have at most 20 developers, Pd CVS has already 54. Finding a better host for the CVS would be good though, maybe this can go in line with an svn transition. Any volunteer to take the lead in that ?
Are you talking about finding completely alternative hosting to SourceForge, for SVN hosting Puredata on the whole?
I don't know whether Günter means switching away from SourceForge, but I really think that the whole Pd CVS should leave SourceForge right now. The web services like patch-tracker and bug-tracker and downloads and such can all stay on SourceForge, I don't mind, but the CVS has to leave because there are too many problems.
Actually, because Chun and I really have to work on DD alot these days and the CVS is just plain down, we'd rather move out tomorrow than waiting June 1st, but if SF is up tomorrow until the 30th I don't mind. If SF has longer downtime I'll make an emergency fork.
I think that a DD fork is not a bad idea. It seems that you guys want to make a lot of changes to core and are frustrated with the way things work now. I think that you wouldnt have to complain so much on this list and could run things how you want.
But all I ask is that you try to keep things compatible, and submit patches to the patch tracker for anything that makes sense to have in Miller's sources. For example, a class browser would be nice to have in all Pd branches.
.hc
zen \ \ \[D[D[D[D
On Mon, 8 May 2006, David Plans Casal wrote:
On 8 May 2006, at 16:43, geiger wrote:
I am sorry but it won't be possible to add all users of DesireData 0.39.A to the developer CVS. SF suggest to have at most 20 developers, Pd CVS has already 54. Finding a better host for the CVS would be good though, maybe this can go in line with an svn transition.
Any volunteer to take the lead in that ?
Are you talking about finding completely alternative hosting to SourceForge, for SVN hosting Puredata on the whole?
The principal problem seems to be the host, not CVS. So finding a better host could solve that problem.
The svn transition is just an addon, which could be done at the same time but doesn't address the same problem.
Hope this makes it clearer,
Günter
d
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On 9 May 2006, at 11:32, geiger wrote:
The principal problem seems to be the host, not CVS. So finding a better host could solve that problem.
Other than IEM (sorry if I assume wrongly here), do we have any other offers or candidate hosts?
The svn transition is just an addon, which could be done at the same time but doesn't address the same problem.
It does ;-)
If we moved to something like Trac [1], we could solve the problem whereby we have an svn repository somewhere, and bug/issue tracking somewhere else. Just a thought.
d
[1] http://projects.edgewall.com/trac/
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
On Tue, 9 May 2006, David Plans Casal wrote:
On 9 May 2006, at 11:32, geiger wrote:
The principal problem seems to be the host, not CVS. So finding a better host could solve that problem.
Other than IEM (sorry if I assume wrongly here), do we have any other offers or candidate hosts?
AFAIK there are currently no concrete offers, but IEM is a candidate. We can also switch to any other (probably not so famous and therefore faster) free version control sites such as Berlios (http://developer.berlios.de/) or Savannah (http://savannah.nongnu.org/)
The svn transition is just an addon, which could be done at the same time but doesn't address the same problem.
It does ;-)
It only solves the problem if svn on sourceforge is more stable than CVS. Otherwise its about changing the host, the version control system doesn't matter as long as it is a centralized system such as CVS or SVN.
It would have to be a dezentralized system such as monotone http://www.venge.net/monotone/, git (http://git.or.cz/) or GNU arch (http://www.gnu.org/software/gnu-arch/) in order to really affect the problem that we have with sourceforge.
If we moved to something like Trac [1], we could solve the problem whereby we have an svn repository somewhere, and bug/issue tracking somewhere else. Just a thought.
Thats a possibility, but where to put them and who does the maintainance is the primary question for every centralized service. Our main problem currently is that, for whatever reason, sourceforge doesn't keep up with its maintainance. If we move to something different we should make sure that this gets better.
Günter
d
[1] http://projects.edgewall.com/trac/
-- David Plans Casal Researcher, UEA Studios d.casal at uea dot ac dot uk http://www.davidcasal.com
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 2006-05-09 at 18:28 +0200, geiger wrote:
It would have to be a dezentralized system such as monotone http://www.venge.net/monotone/, git (http://git.or.cz/) or GNU arch (http://www.gnu.org/software/gnu-arch/) in order to really affect the problem that we have with sourceforge.
svk is another powerful decentralized version control system based on svn ... it's based on subversion and i'm currently using it to sync my local svn repository with my university's ... it can be used to maintain (local) mirrors of an svn server ...
tim
-- TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk
I must say I find television very educational. The minute somebody turns it on, I go to the library and read a good book. Groucho Marx
On Tue, 9 May 2006, geiger wrote:
AFAIK there are currently no concrete offers, but IEM is a candidate. We can also switch to any other (probably not so famous and therefore faster) free version control sites such as Berlios (http://developer.berlios.de/) or Savannah (http://savannah.nongnu.org/)
Apparently Savannah requires GPL/LGPL, so we can't use it. Are there such restrictions on Berlios?
It only solves the problem if svn on sourceforge is more stable than CVS.
People on the tcl-core list are afraid that other services than CVS could stop working in the future.
It would have to be a dezentralized system such as monotone http://www.venge.net/monotone/, git (http://git.or.cz/) or GNU arch (http://www.gnu.org/software/gnu-arch/) in order to really affect the problem that we have with sourceforge.
Decentralised systems deal with the problem of outages in general, they don't deal with the problem of sourceforge in particular vs another host in particular.
Our main problem currently is that, for whatever reason, sourceforge doesn't keep up with its maintainance. If we move to something different we should make sure that this gets better.
Yes. In particular it's nice if enough people have enough privileges on the machine so that we can fix problems ourselves.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 10 May 2006, Mathieu Bouchard wrote:
On Tue, 9 May 2006, geiger wrote:
AFAIK there are currently no concrete offers, but IEM is a candidate. We can also switch to any other (probably not so famous and therefore faster) free version control sites such as Berlios (http://developer.berlios.de/) or Savannah (http://savannah.nongnu.org/)
Apparently Savannah requires GPL/LGPL, so we can't use it. Are there such restrictions on Berlios?
It only solves the problem if svn on sourceforge is more stable than CVS.
People on the tcl-core list are afraid that other services than CVS could stop working in the future.
It would have to be a dezentralized system such as monotone http://www.venge.net/monotone/, git (http://git.or.cz/) or GNU arch (http://www.gnu.org/software/gnu-arch/) in order to really affect the problem that we have with sourceforge.
Decentralised systems deal with the problem of outages in general, they don't deal with the problem of sourceforge in particular vs another host in particular.
Our main problem currently is that, for whatever reason, sourceforge doesn't keep up with its maintainance. If we move to something different we should make sure that this gets better.
Yes. In particular it's nice if enough people have enough privileges on the machine so that we can fix problems ourselves.
But this also means that we _have to_ fix things ourselves, which isn't really such a good thing. The goal is to improve service, not just move off of SourceForge. And tto find out how to do that will take some research. Berlios sounds like a good option to research.
.hc
zen \ \ \[D[D[D[D
Hans-Christoph Steiner wrote:
On Wed, 10 May 2006, Mathieu Bouchard wrote:
On Tue, 9 May 2006, geiger wrote:
AFAIK there are currently no concrete offers, but IEM is a candidate. We
the good thing about hosting it at the iem would be the consistent user database: we could use the already existing accounts at puredata.info/puredata.org to grant (write) access to a subversion repository. personally i am a big fan of as little different passwords as possible. i found a "Plone SVN access" product at http://plone.org/products/plone-svn-access, which seems to be pretty what i expected of such a thing. it would need a major upgrade of the puredata-portal though (plone-2.1 is required while we are still running plone-2.0)
It only solves the problem if svn on sourceforge is more stable than CVS.
i guess(!) that sf's cvs-hardware (i suspect the harddisks) just died all the approximately the same time because they were of the same age (probably the same charge?). additionally i guess that the svn-hardware is brandnew and will take some time to degrade to uselessness (well, even brandnew hw can jump out of the window and die)
People on the tcl-core list are afraid that other services than CVS could stop working in the future.
i am afraid that austria will get another right-wing government at the next elections - but i don't expect anybody to care....
It would have to be a dezentralized system such as monotone http://www.venge.net/monotone/, git (http://git.or.cz/) or GNU arch (http://www.gnu.org/software/gnu-arch/) in order to really affect the problem that we have with sourceforge.
Decentralised systems deal with the problem of outages in general, they don't deal with the problem of sourceforge in particular vs another host in particular.
indeed. but the problem we are experiencing is really about centralization rather than sourceforge - they just happen to be the one. any other centralized repository could have a service-failure as well otoh, if i (or matju) was the one who runs the failed central server, chances are high that we spend our time with getting the system running again instead of ranting on people who are trying to the the system running again. the system to restore might be a lot smaller and thus be online faster.
Our main problem currently is that, for whatever reason, sourceforge doesn't keep up with its maintainance. If we move to something different we should make sure that this gets better.
how can you guarantee this without paying someone to do the job? (or taking it granted that some other institution like ucsd, iem or artengine are willing to pay for this)
Yes. In particular it's nice if enough people have enough privileges on the machine so that we can fix problems ourselves.
But this also means that we _have to_ fix things ourselves, which isn't really such a good thing. The goal is to improve service, not just move
i can only second that
off of SourceForge. And tto find out how to do that will take some research. Berlios sounds like a good option to research.
i think this is really important: we do have to evaluate before switching to any other service. and if we do decide to host it ourselves (whoever), we have to evaluate even more, to provide a stable, fast and happy system (sourceforge/savannah/berlios/... have done this already)
mfg.adsr. IOhannes
On Wed, 10 May 2006, Mathieu Bouchard wrote:
It only solves the problem if svn on sourceforge is more stable than CVS.
People on the tcl-core list are afraid that other services than CVS could stop working in the future.
"D. Richard Hipp" (drh on #tcl) is writing a bug database exporter from SourceForge to some XML format. I don't know which #tcl channel it is, but there are 3 #tcl channels joined by gateways, so going in FreeNode's #tcl should be enough except that he won't necessarily be in the userlist.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 10 May 2006, Mathieu Bouchard wrote:
(http://developer.berlios.de/) or Savannah (http://savannah.nongnu.org/)
Apparently Savannah requires GPL/LGPL, so we can't use it. Are there such restrictions on Berlios?
There are no such restrictions on savannah.NONGNU.org. There might be other issues, but before deciding we should take a closer look.
Günter
It would have to be a dezentralized system such as monotone http://www.venge.net/monotone/, git (http://git.or.cz/) or GNU arch (http://www.gnu.org/software/gnu-arch/) in order to really affect the problem that we have with sourceforge.
Decentralised systems deal with the problem of outages in general, they don't deal with the problem of sourceforge in particular vs another host in particular.
Our main problem currently is that, for whatever reason, sourceforge doesn't keep up with its maintainance. If we move to something different we should make sure that this gets better.
Yes. In particular it's nice if enough people have enough privileges on the machine so that we can fix problems ourselves.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Tue, 9 May 2006, David Plans Casal wrote:
On 9 May 2006, at 11:32, geiger wrote:
The principal problem seems to be the host, not CVS. So finding a better host could solve that problem.
Other than IEM (sorry if I assume wrongly here), do we have any other offers or candidate hosts?
Artengine.ca is a possibility starting next month and as long as I don't have to maintain it much more than doing what is needed to integrate the thing in our own services (mailing-lists, etc)
So I'd hand out a user account to, say, Günther and/or some more people. How does SVN manage user perms? Or CVS? Is there a way to be safer than :pserver: but without requiring setting up system-wide accounts for all ~55 developers?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Wed, 10 May 2006 22:38:35 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote: <snip>
So I'd hand out a user account to, say, Günther and/or some more people. How does SVN manage user perms? Or CVS? Is there a way to be safer than :pserver: but without requiring setting up system-wide accounts for all ~55 developers?
If you use svnserve, it uses an MD5 based key exchange mechanism, with user credentials stored in a flat text file. You can also use it in tunnel mode, in which case, you authenticate against unix credentials over SSH. The alternative is to use Apache + mod_dav_svn (more flexible), in which case you can use any authentication mechanisms supported by Apaache, LDAP, http basic auth etc.
I would of thought that the nicest way to do this would be to run an LDAP service and use it to manage svn users/groups as well as Zope users/groups and authentication for the puredata site. Of course, that's significantly more work.
Jamie
Jamie Bullock wrote:
On Wed, 10 May 2006 22:38:35 -0400 (EDT) Mathieu Bouchard matju@artengine.ca wrote:
<snip> > So I'd hand out a user account to, say, GÃŒnther and/or some more people. > How does SVN manage user perms? Or CVS? Is there a way to be safer than > :pserver: but without requiring setting up system-wide accounts for all > ~55 developers?
well, afaik there are special shells for restricted use, so accounts are allowed to only do certain tasks (like cvs) when they login. and use rootjails!
this is the main reason why i would favour a subversion system if the iem was to host the repository (if we really migrate from sf)
If you use svnserve, it uses an MD5 based key exchange mechanism, with user credentials stored in a flat text file. You can also use it in tunnel mode, in which case, you authenticate against unix credentials over SSH. The alternative is to use Apache + mod_dav_svn (more flexible), in which case you can use any authentication mechanisms supported by Apaache, LDAP, http basic auth etc.
I would of thought that the nicest way to do this would be to run an LDAP service and use it to manage svn users/groups as well as Zope users/groups and authentication for the puredata site. Of course, that's significantly more work.
on the long run i think it might well be worth it. especially the user-administration would be eased a lot if we could use the existing framework. no need to ssh to the server and manually edit flat files, the user-managment (setting passwords!) is already handled.
(btw, the user-db of puredata.info is currently not stored in an ldap-tree but rather directly in zope/plone; most likely there exists a possibility to migrate)
most important (on my side - speaking for the iem) security: i am not really willing (and most likely not allowed) to give 54 (and the number is growing) people whom i don't know and who are spread all over the world so i cannot reach them if i need to login access on a host that is within the university's network.
mfg.asd.r IOhannes
On Mon, 8 May 2006, geiger wrote:
On Mon, 8 May 2006, Mathieu Bouchard wrote:
from the moment that DesireData 0.39.A comes out, so that I can easily send instant bugfixes to users who are not "worthy" enough to get access to the :ext: SourceForget CVS.
I am sorry but it won't be possible to add all users of DesireData 0.39.A to the developer CVS. SF suggest to have at most 20 developers, Pd CVS has already 54.
I know that it's not a good idea to be have a huge list of developers who aren't developers, but because there isn't an intermediate :ext:-based read-only access and because :pserver: is broken, there aren't too many options left...
In addition, tonight the :ext: CVS is broken as well, so Chun and I have to exchange files via email or DCC.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
David Plans Casal -
geiger -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jamie Bullock -
Mathieu Bouchard -
Tim Blechmann