Re: CouchDB packaging for Ubuntu
Hi, I have CouchDB 1.2.0 with Erlang R15B01 on Ubuntu 12.10 up and running. Unfortunately, I've never built a deb package, so, I cannot provide such a package. Nevertheless, if you have any problem in building it, just let me know and I will try to help. About the mailing list, I suppose adding the CouchDB users (to get an idea which is the desired Ubuntu distro) and/or Debian (you may get support in testing and debugging) lists wouldn't be such a bad idea, but it's your call here. CGS On Sat, Jun 9, 2012 at 9:15 PM, till wrote: > Hey, > > I've been scratching my own itch and started building 1.2.0 for a couple > Ubuntu distributions. > > It's a WIP but I was wondering the following: > > 1) It builds – but does it work? Is the best bet to run the test suite in > futon, or is there something I could run on the command line when the > package is installed? I'd prefer the command line to include it in some > sort of continuous testing without a browser. > > 2) Who'd have some interest in testing this? > > 3) Which distributions are wanted – I started with karmic and lucid and > had planned to build all the way up to 12.10. > > 4) Is there a mailing list to discuss this, or is dev@ fine? > > Till
CouchDB packaging for Ubuntu
Hey, I've been scratching my own itch and started building 1.2.0 for a couple Ubuntu distributions. It's a WIP but I was wondering the following: 1) It builds – but does it work? Is the best bet to run the test suite in futon, or is there something I could run on the command line when the package is installed? I'd prefer the command line to include it in some sort of continuous testing without a browser. 2) Who'd have some interest in testing this? 3) Which distributions are wanted – I started with karmic and lucid and had planned to build all the way up to 12.10. 4) Is there a mailing list to discuss this, or is dev@ fine? Till
replication problems
I'm not exactly sure how to report this, so I figured I'd send a message here instead of just keeping it to myself. Since I've switched from Couchbase Single to Apache CouchDB for (almost) all of my couches, I've been hitting a couple of replication bugs that I used to experience in Couchbase Single and Filipe eventually fixed. The fixes seemed to have not made it to Apache CouchDB. I don't know exactly what happens, so I'm hoping Filipe or someone remembers enough to know what's going on. Problem #1: Replication stops. This happens very frequently on my laptop. I end up killing CouchDB and watch it catch up after it restarts. However, it also happens on my Mac Mini at home (notable difference: It doesn't go to sleep a couple times a day). Last night, I discovered I was very far behind on a replication stream on a particular database. This was not the case for all databases. Restarting brought them all back. Problem #2: Replication... replicates I've had another case where I've ended up with duplicate replication streams. Again, restarting puts the count back to the expected 1. I'm not sure this causes any problems, but it might correlate with the other. I only notice it when I go to check status. -- dustin sallings
Re: So, how do we get the Mac binary on the home page?
On Sat, Jun 9, 2012 at 11:40 AM, Hans J Schroeder wrote: > Hi Dave, > >> #1 and #2 make sense, but might not be immediately obvious. They could >> wait, its more >> about documenting somewhere. > > It is exactly where to put them. What would be your choice? > I also disagree about documentation needs for this. Apple users don't want > and don't need to know such details. It just works. :) > The exact locations are also visible from the configuration page. Every > CouchDB user is familiar with this. > Paths to find dqtq and ibi should be documented somewhere though. So someone that want to delete the application can delete the data. (data shouldn't be in the application resources) . >> If its not hard to fix #3 and #4 we should do that first. This means >> CouchDB.app could >> run read-only in /Applications, which it doesn't atm. > > That would be nice and falls in the sandboxing category which we definitely > should adopt. > But I see no immediate need for this for the current version. Since 1st june, OSX qpps qre required to be sandboxed. Which is ino better for the end user. We should really adapt the current version to have it. Tjis isn't a show stopper, but still something usefull qnd not so hard to implement. > > Changing is also not that easy because there are dependencies: > The log is connected to the logfile viewer. > The uri is connected to the shutdown scripts to do a final commit. Well such things are already working in rcouchx. I will have a look in the code of these new version for that. > > Would you stop publishing without these changes. > > Is this a question ? :) Anyway for the port part I still think it`s important. I think we could have a default to 5984 and if it`s used, use another port automatically and notify it. - benoit - benoît
Re: So, how do we get the Mac binary on the home page?
Hi Dave, > #1 and #2 make sense, but might not be immediately obvious. They could > wait, its more > about documenting somewhere. It is exactly where to put them. What would be your choice? I also disagree about documentation needs for this. Apple users don't want and don't need to know such details. It just works. :) The exact locations are also visible from the configuration page. Every CouchDB user is familiar with this. > If its not hard to fix #3 and #4 we should do that first. This means > CouchDB.app could > run read-only in /Applications, which it doesn't atm. That would be nice and falls in the sandboxing category which we definitely should adopt. But I see no immediate need for this for the current version. Changing is also not that easy because there are dependencies: The log is connected to the logfile viewer. The uri is connected to the shutdown scripts to do a final commit. Would you stop publishing without these changes. - Hans On Jun 8, 2012, at 8:54 PM, Dave Cottlehuber wrote: > On 8 June 2012 16:40, Jan Lehnardt wrote: >> >> On Jun 8, 2012, at 16:31 , Hans J Schroeder wrote: >> >>> Hi Jan, >>> Can you specify what systems should use which versions, so we can label them correctly on the website? >>> >>> For Mac OS X 10.6.8 to 10.7.2: >>> https://github.com/downloads/cloudnode/couchdbx-app/CouchDB%20Server-1.2.0.zip >>> >>> For Mac OS X 10.7.3 and later >>> https://github.com/downloads/cloudnode/couchdbx-app/CouchDB%20Server-1.2.0-OS%20X%2010.7.3.zip >> >> Thanks Hans! >> >> With this, I think we are good to go to put this on the website. Anyone >> disagreeing? :) >> >> Cheers >> Jan > > Some things, files are scattered across various places. > > #1 dbs & views are in ~/Library/Application Support/CouchDBServer/ > #2 there's no local.ini as such, its in > ~/Library/Preferences/couchdb-server.ini > #3 couch.log is in $APPROOT/Contents/Resources/couchdbx-core/var/log/couch.log > #4 couch.uri is in $APPROOT/Contents/Resources/couchdbx-core/var/run/couch.uri > > If its not hard to fix #3 and #4 we should do that first. This means > CouchDB.app could > run read-only in /Applications, which it doesn't atm. > > #1 and #2 make sense, but might not be immediately obvious. They could > wait, its more > about documenting somewhere. > > A+ > Dave
