Re: Subversion's Berkeley DB detection with APR trunk
On 06/21/2011 08:03 AM, Philip Martin wrote: apr trunk combines apr and apr-util into a single library and there is only a single apr-2-config script. Subversion can be configured by using this script for both apr and apr-util, but Subversion's Berkeley DB detection doesn't work. This is because the apr-2-config script doesn't support the --db-version parameter that the old apu-config script provided. Should we rework Subversion's Berkeley DB detection or should we change APR? I'd be interested in knowing why the --db-version parameter was dropped. In the absence of a solid reason, I think APR should be changed to support as much. -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand
Re: Subversion's Berkeley DB detection with APR trunk
On 06/21/2011 09:42 AM, Philip Martin wrote: C. Michael Pilato cmpil...@collab.net writes: I'd be interested in knowing why the --db-version parameter was dropped. In the absence of a solid reason, I think APR should be changed to support as much. Probably it's because apr is now modular and BDB support is one of the things that is loaded dynamically. It's easy enough to reinstate --db-version, but that doesn't fix Subversion because apr no longer explicitly links against the BDB library. Subversion's configure fails its link test with 'undefined reference to db_version'. Hrm. I seem to recall that it used to be extremely important for Subversion to use the same BDB to which APR was linked. mod_dav_svn used APR's DB support for its activities database, and couldn't deal with having APR's DB being one flavor of BDB while the Subversion repositories which it also needed to read/write needed a different flavor of BDB. Has any of this changed since our move (back in 1.5) away from DB-based activities databases? I mean, could we move BDB detection into Subversion proper and that not be catastrophic? -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: Buffer overflow in apr_brigade_vprintf() ?
C. Michael Pilato wrote: [Please Cc: me in responses -- I think I still have APR commit privs, but I'm not active here and not subscribed to the mailing lists.] In the past couple of weeks, I've seen two different reports of what appears to be corruption in the stream of data transmitted by Subversion's mod_dav_svn through Apache and back to the Subversion client. What is seen client-side is an opening XML tag, a truncated bit of CDATA inside the tag, and then a missing XML closing tag. The problem seems to occur with magically sized chunks of data, so it can be hard to reproduce[1]. [...] Just to bring this to closure, the bug was fixed by committing the removal of the code that tacks the NULL byte onto a possibly-already-full buffer: http://svn.apache.org/viewvc?view=revrevision=768417 (Thanks, Ruediger and Jeff!) -- C. Michael Pilato cmpil...@collab.net CollabNet www.collab.net Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: confusion about largefile support
Erik Huelsmann [EMAIL PROTECTED] writes: On 5/31/05, Ben Collins-Sussman [EMAIL PROTECTED] wrote: On May 31, 2005, at 11:49 AM, Ben Collins-Sussman wrote: Funny, KDE is using fsfs, and I would have expected them to run into a 2GB revision file. Well, whattya know. Now Timothee Besset (ttimo) in IRC has just reported the same File size limit exceeded error that we saw on users@ earlier today. In both cases, the users were loading a dumpfile into an fsfs repository. And ttimo verified my fear. There's a 2GB file being assembled in db/txns/. So, um, maybe we should write a FAQ? One which tells folks that the only workaround here is to recompile subversion against apr 1.x? (And to upgrade to httpd 2.1 if necessary.) or use a BDB repos. In TTimo's case, I seem to recall that the use of a BDB repos was a cause of entirely different source of pain, and therefore, not as viable an option.
Re: uuid generation on linux boxes
Ian Holsman [EMAIL PROTECTED] writes: I have a issue with a linux box not having enough entropy and hanging on a call to apr_uuid_get (as it calls /dev/random) I was wondering why we don't just use /proc/sys/kernel/random/uuid and use that for our uuid? If you are building APR yourself, I believe you can pass --with-devrandom=/dev/urandom to its configure script to solve this problem.
