Bug#709758: Replacing a binary package by another one(was: Communication issue?)
[Norbert Preining] On Di, 03 Sep 2013, Peter Samuelson wrote: texlive-lang-european? It doesn't look like it to me (no Breaks or Conflicts), but I haven't actually tried it. conflicts there are, texlive-base conflicts with all the old packages. I misspoke. There is a Conflicts in texlive-base, but what is probably needed is Provides in texlive-lang-european. As I understand it, that will prompt apt to DTRT on upgrade. Since nobody is worried about versioned dependencies here, I think that would suffice. No need for 30 transitional packages. But I haven't tested it. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709758: Replacing a binary package by another one(was: Communication issue?)
[Norbert Preining] I understood your proposal, of course. Still, since there are no rdepends besides very few (1?) build-depends on these two packages, I consider it a a waste of resources. Sounds like you are saying 'texlive-lang-danish' is only useful as a package dependency - in other words, users would never install it explicitly because they want its functionality. Is that correct? This is not clear from the package description, which at least to me looks like something users _would_ install explicitly: Description-en: TeX Live: Danish Support for typesetting Danish. . This package includes the following CTAN packages: hyphen-danish -- Danish hyphenation patterns. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709758: Replacing a binary package by another one(was: Communication issue?)
Sounds like you are saying 'texlive-lang-danish' is only useful as a package dependency - in other words, users would never install it explicitly because they want its functionality. Is that correct? This [Norbert Preining] I never said that. The functionality is now in texlive-lang-european I can see that. But your argument for removing texlive-lang-danish etc. is basically there are almost no rdeps. But that is only half the story. The other half is to explain what will happen to users who installed texlive-lang-danish because they want Danish language hyphenation support. When they upgrade, will they get texlive-lang-european? It doesn't look like it to me (no Breaks or Conflicts), but I haven't actually tried it. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#712004: /usr/lib/apache2/modules/mod_dav_svn.so: undefined symbol: ap_log_perror_
[Salvatore Bonaccorso] Only wanted to ask back: Did you had already a chance to look at the update for 1.7.10 (and the updates needed for the apache2.4 transition? I'm aware of the situation, yes. :/ I keep trying to find time to finish the Apache 2.4 thing, yes. If I can find a bit of extra time tonight, I may be able to finish that upload. But I can't promise it. And unfortunately I will then be away from the Internet for a couple days. Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666794: Subversion module ready
[Arno Töll] could you please let me know if you're able to work on a patch in a foreseeable future? Ah yes - I was looking at this last weekend but then ran out of time. The conflict with the event mpm is probably not critical - it is only a specific unusual configuration that breaks - so I think the main thing is just to update the Depends: apache2.2-common. Anyway I will try to resolve this in the next few days. Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704940: marked as done (subversion: cve-2013-1845 cve-2013-1846 cve-2013-1847 cve-2013-1849 cve-2013-1884)
http://subversion.apache.org/security/CVE-2013-1845-advisory.txt http://subversion.apache.org/security/CVE-2013-1846-advisory.txt http://subversion.apache.org/security/CVE-2013-1847-advisory.txt http://subversion.apache.org/security/CVE-2013-1849-advisory.txt http://subversion.apache.org/security/CVE-2013-1884-advisory.txt Adding closing and version information to the bug, as these where fixed in subversion/1.7.9-1 upload. Thanks. Peter are you working already also on the updates for Wheezy and Squeeze? Yes - with luck, I may have time to do these tonight. (I know it's a security tagged bug, but it's also merely crashing individual Apache child processes. (Unless you use apache2-mpm-worker or equivalent.)) Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690155: libsvn-{dev, java, ruby1.8}: missing copyright file after upgrade from squeeze
[Andreas Beckmann] A test with piuparts revealed that your package misses the copyright file after an upgrade from squeeze to wheezy, which is a violation of Policy 12.5 : Thanks - yeah, looks like a dpkg bug: during the upgrade, the old /usr/share/doc/$pkg directory disappears, but dpkg forgets to remove it before unpacking the new package, where /usr/share/doc/$pkg is a symlink; therefore it fails to add the symlink. Of course dpkg should be careful when replacing symlinks with directories, because it's possible for a local admin to replace a directory with a symlink for filesystem layout reasons. But this is the opposite case, and dpkg certainly has enough information to know it is safe. I'm guessing this dpkg bug hits a lot more packages than just mine. Do you know if it is expected to be fixed soon, or do I need to work around it? Thanks, Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690155: libsvn-{dev, java, ruby1.8}: missing copyright file after upgrade from squeeze
Of course dpkg should be careful when replacing symlinks with directories, because it's possible for a local admin to replace a directory with a symlink for filesystem layout reasons. But this is the opposite case, and dpkg certainly has enough information to know it is safe. [Andreas Beckmann] No, dpkg has not enough information about what was a symlink or directory in the package. This will probably change with 1.17.x as Guillem plans to extend the metadata stored in the dpkg database. When I say it has enough information, I didn't mean the information is necessarily stored in a convenient form by dpkg. I don't know that. What I mean is: (1) the old package ships /usr/share/doc/$pkg as a dir, (2) the new package does not ship the dir, (3) no other package ships the dir, (4) the dir is empty after the old package is removed. That is enough information for dpkg to correctly remove the directory when you remove the package. Thus it should also be enough information for dpkg to remove the directory on upgrade. So for going from directory to a link you will need to add a postinst script that does something like this if [ $1 = configure ]; then if dpkg --compare-versions $2 -lt FIXEDVERSION~ ; then if [ ! -l /u/s/d/$pkg ] [ -d /u/s/d/$pkg ]; then rmdir /u/s/d/$pkg # bombs if not empty ln -s $target /u/s/d/$pkg fi fi fi I assume you mean [ -L ] rather than [ -l ] ... but other than that, looks good. I think the dpkg --compare-versions is not needed either, except for the purpose of self-documentation - to make it obvious when the postinst section can be removed from the packaging. Even if subversion 1.7 is not going into wheezy (is it?), this would become a problem for wheezy-jessie upgrades. The release team blocked subversion 1.7 from wheezy even before the freeze. (The reason was a series of new bugs in other packages which, I believe, have now been fixed for months.) Given the rather huge diff between 1.6 and 1.7, it is not worth their trouble to review it now, so I have not asked them to. But it _does_ mean that if I want to work around the dpkg bug, I'll have to go through t-p-u. Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689859: dpkg: error processing libapache2-svn (--configure)
Setting up libapache2-svn (1.6.17dfsg-4) ... ERROR: Module dav_svn does not exist! dpkg: error processing libapache2-svn (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: libapache2-svn E: Sub-process /usr/bin/dpkg returned an error code (1) This is a puzzle. The postinst just calls 'a2enmod dav_svn' (on new installs only). a2enmod is what throws the error, which indicates that it cannot find /etc/apache2/mods-available/dav_svn.load. And thta file is definitely shipped in the libapache2-svn package. Maybe you can figure out why /etc/apache2/mods-available/dav_svn.load did not get unpacked from the .deb file? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689919: Question on AFL 3.0 section 9
Larry, As author of the AFL v3.0, can you comment on some concerns raised about it by Francesco Poli at https://lists.debian.org/debian-legal/2012/09/msg00082.html ? Francesco's message is somewhat long, so here is the most important concern. (I read the relevant section of your book, http://rosenlaw.com/pdf-files/Rosen_Ch09.pdf, which by the way is impressively clear and detailed, but it doesn't appear to address this question.) | 9) [...] If You distribute or communicate copies of the Original | Work or a Derivative Work, You must make a reasonable effort | under the circumstances to obtain the express assent of | recipients to the terms of this License. The software in question is in the Debian archive, where it can be downloaded manually, using a web browser or other http client, or automatically, using various client tools to install and update a Debian system (commonly apt-get, aptitude, or synaptic). These tools can be run interactively or noninteractively. The same software and processes also exist in Ubuntu, but for the purpose of this email I don't care about Ubuntu, they can look after their own interests. Our question is, what constitutes reasonable under the circumstances? Would this mean that the Debian mirror sites would be required to include click-through license confirmation pages before you could download certain files? Would it mean that OS updater client apps would need to implement license confirmation dialogs before performing certain updates? To put this in perspective, the AFL 3.0 software I'm talking about is around 70 kB, which is around 1 millionth of 1 percent of the Debian archive. As such, I can pretty much guarantee that license dialogs and click-through pages are NOT going to happen. Would this then mean it is inappropriate for Debian to distribute AFL-v3.0-licensed content? Thanks, Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689919: Question on AFL 3.0 section 9
[Francesco Poli] However, asking for clarifications to the license author is not necessarily helpful: the reply you obtained from L. Rosen clarifies *his own* interpretation of one unclear clause of the AFL v3.0. I know the distinction. But he is a lawyer with significant experience in IP and open source. He wrote a book on open source licensing. He used to serve on the board of the ASF - though eventually he resigned due to internal politics. These are credentials which I certainly do not have, and (AFAIK) neither do you. I was hoping he would say this doesn't mean what you think it means, and explain why ... and he did. I think that is not meaningless. Also, that something is unclear to you or to me does not mean it is unclear in the context of the legal profession. To put it another way: there is quite a lot of disagreement out there on how to interpret various points of the GPLv2. Does this mean we should ask every copyright holder of GPLv2 software to clarify their own stance, before accepting their software into Debian? We certainly don't do that today! I think you should get in touch with its *copyright holders*, rather than with the author of the license they adopted. I already did - many years ago - because at the time, svn_load_dirs had no explicit license at all. Blair, the author, spent some time contacting his former employer, the copyright holder, a company named Dolby that is now owned by Sony. Eventually, they added an explicit license. I find it _very_ unlikely that they will be willing to go through all that trouble again, in order to change from one OSI-approved license to another. And not only OSI-approved, but written by a member and former board member of the ASF. I could remove svn_load_dirs again. It turned out to be somewhat disruptive last time I did that (because there was no license at all). It seems people actually use that script, though I do not. While there is a partial replacement available (svn-load by dannf, actually written _because_ of this issue, and packaged separately), I don't want to put people through the disruption of removing this again now that it's back in. That is why I now ship it in the debian subdir, as the whole 'contrib' area is no longer shipped in upstream tarballs. Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683555: subversion: not working at all SASL context error
[Stephen Fox] I rebuilt subversion without SASL after realizing SASL is an optional dependency, and svn is working fine. I suppose a way to isolate it to the ABI issue would be rebuilding the SASL libs, and building svn against that? I don't entirely understand the implications of Bug #665476. I didn't spend any time trying to figure out the implications of #665476 either. It may or may not be related. In any case, Subversion is not failing for me, so I'd appreciate if someone could figure out how to reproduce the problem - is there some specific configuration of the Cyrus SASL library that triggers it, e.g.? The failure is in initializing libsasl2-2. Of course we could figure out how to init the library on demand, so that for cases like yours, it would never even travel that code path, but as this extraneous library init has not been a problem before, I'd rather find and fix the _real_ bug. As for just compiling without SASL support: SASL is indeed 'optional' in that not all servers will require it in order to authenticate. So that's a valid workaround for individual users. Not for the Debian build as a whole, though, as probably some servers _do_ require more advanced SASL authentication modes. Thanks, Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683555: subversion: not working at all SASL context error
[Norbert Preining] $ svn up Updating '.': svn: E170001: Unable to connect to a repository at URL 'svn://u...@server.org/some/path' svn: E170001: Could not create SASL context: generic failure: No such file or directory The same happens with svn+ssh://... on svn.debian.org This is a failed call to sasl_client_new() from libsasl2-2. I can't reproduce the problem. I have the latest libsasl2-2, libsasl2-modules packages. I do wonder if it is somehow related to Bug #665476. I mean, probably not, but possibly? Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678845: [Svn-bp-devel] Bug#678845: svn-buildpackage: svn-inject fails with subversion 1.7
tags 678845 patch
thanks
[Neil Williams]
$ svn-inject -o pycparser_2.07+dfsg-1.dsc \
file:///home/neil/code/debian/svn-buildpackage/test/svn/upstream/
... which fails.
So this is only related to the -o option.
From your log:
cd /tmp/tmp.e9DyJwzOqX/unpdir/pycparser-2.07+dfsg ; tar -c debian/copyright
debian/patches/abort-on-test-failure deb
ian/rules debian/patches/series debian/compat debian/source/ debian/control
debian/python3-pycparser.docs debian/
debian/changelog debian/clean debian/source/format debian/watch
debian/python-pycparser.examples debian/patches/
debian/python-pycparser.docs debian/python-pycparser.install
debian/python3-pycparser.install
debian/python3-pycparser.examples 2/dev/null | tar x -C /tmp/tmp.VW1h6QWbAr
rm -rf /tmp/tmp.e9DyJwzOqX/unpdir/pycparser-2.07+dfsg
mv /tmp/tmp.VW1h6QWbAr /tmp/tmp.e9DyJwzOqX/unpdir/pycparser-2.07+dfsg
svn co
file:///home/neil/code/debian/svn-buildpackage/test/svn/upstream/pycparser/trunk
/tmp/tmp.e9DyJwzOqX/trunk
So as I thought, 'svn co' is run in a deleted cwd. For reporting
purposes, it tries to get the absolute path of '.', which obviously
will not work there.
Arguably this failure mode is a new bug in Subversion 1.7, because in
the present case it shouldn't need to report anything relative to the
cwd, since it was given only absolute paths. But a deleted cwd is a
strange corner case, and I seem to recall that in some Unix kernels it
is not even legal. Plus, I'm told by upstream that this particular
error turns out to not be easy to avoid, as the distinction between
relative and absolute paths is far away from where the getcwd()
happens.
This ought to do the trick:
--- svn-inject
+++ svn-inject
@@ -626,6 +626,7 @@ sub del_unreferenced {
# withecho(cp, -a, --parents, (keys %ourfiles), ../current2);
sucks, cannot ignore errors properly
# this sucks too
withecho(cd $dir ; tar $opt_tarquiet -c .join(' ',keys %list).
2/dev/null | tar x $opt_tarquiet -C $tmpdir);
+chdir /;
withecho(rm, -rf, $dir);
withecho(mv, $tmpdir, $dir);
}
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678760: [patch] Fix FTBFS
tags 678760 patch thanks Trivial patch to fix the FTBFS with libsvn-dev 1.7. This is one of those cases, as we see with major new g++ / libstdc++ releases, where an include has been missing all along, just not previously noticed. From: Peter Samuelson pet...@p12n.org Subject: Include needed headers Origin: other (trivial) Bug-Debian: http://bugs.debian.org/678760 Explicitly include svn_client.h and svn_version.h, as we use functionality from them. svn_version.h in particular used to be included indirectly by other svn headers, but no longer is. --- a/svn-1.0.1/svn.c +++ b/svn-1.0.1/svn.c @@ -33,6 +33,8 @@ #include php_svn.h #include apr_version.h +#include svn_version.h +#include svn_client.h #include svn_pools.h #include svn_sorts.h #include svn_config.h
Bug#678845: svn-buildpackage: svn-inject fails with subversion 1.7
[Stefano Rivera] Since upgrading to subversion 1.7, svn-inject no longer works: ... svn co svn+ssh://purcell/tmp/test/pycparser/trunk /tmp/tmp.jKa9wdfMh5/trunk svn: E125001: Couldn't determine absolute path of '.' svn: E02: No such file or directory mkdir -p /tmp/tmp.jKa9wdfMh5/trunk svn -m Creating trunk directory import /tmp/tmp.jKa9wdfMh5/trunk svn+ssh://purcell/tmp/test/pycparser/trunk svn: E125001: Couldn't determine absolute path of '.' svn: E02: No such file or directory Command 'svn -m Creating trunk directory import /tmp/tmp.jKa9wdfMh5/trunk svn+ssh://purcell/tmp/test/pycparser/trunk' failed in 'unknown', how to continue now? [Qri?]: q Aborting. That is svn complaining because, apparently, it is run inside a directory that has been deleted. How would I reproduce your bug - how did you invoke svn-inject? I tried, and could not. And I can't find where svn-bp _would_ delete the cwd while it is still the cwd. (I am not a svn-bp user, so I don't know the common use patterns.) The fact that svn aborts because it can't turn '.' into an absolute path is arguably a bug, which I've pinged upstream about. svn wants to canonicalize the paths it acts upon, and then report them relative to the current directory - that's why it attempts to getcwd(). In fact this is not relevant if you pass it absolute pathnames, as svn-inject does, but getting svn to look up the absolute cwd only when it is working on relative paths turns out to not be trivial. Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678556: rapidsvn: please drop Build-Depends: libserf-0-0-dev
Package: rapidsvn Version: 0.12.0dfsg-5 Severity: serious Justification: FTBFS Please drop the 'Build-Depends: libserf-0-0-dev' from rapidsvn. It appears not to be needed. If it _is_ needed, note that I have renamed the package to 'libserf-dev'. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678557: lua-svn: please drop Build-Depends: libserf-0-0-dev
Package: lua-svn Version: 0.4.0-6 Severity: serious Justification: FTBFS Please drop the 'Build-Depends: libserf-0-0-dev' from lua-svn. It appears you do not need this build-dep at all. But if you do need it, note the package has been renamed to 'libserf-dev'. Thanks. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677418: gpm shares its clipboard among different users
As one can easily test, gpm uses one clip-board space for all users (including root). So if any of them marks anything sensitive, a following user can gather this information. Likewise, if you log out, your Linux console screen is still readable for the next user. And even if you clear the screen before you log out, the next user can still hit Shift-Prior (aka Shift-PageUp) and see some of your work. Who, in your opinion, should clear the scrollback buffer and the gpm clipboard? .bash_logout? getty? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676455: ${misc:Depends} injects broken versioned depends (Was: Bug#676455: gnumed-doc: uninstallable in sid: depends on outdated libjs-jquery-livequery)
[Raphael Hertzog] It the next upstream version of your javascript library provides new files, they will not be in the symlink tree that you built in your package. So at runtime, it will fail because of the missing file. Forgive me if I'm missing something basic here, but this sounds like a job for a dpkg trigger. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675987: Misses proper Replaces for overwriting /usr/lib/x86_64-linux-gnu/jni/libsvnjavahl-1.so.0.0.0
severity 675987 important thanks [Daniel Leidert] Package misses a proper Replaces, because it overwrites /usr/lib/x86_64-linux-gnu/jni/libsvnjavahl-1.so.0.0.0 also in libsvn-jni 1.6.17dfsg-4~. Argh, you're right. For a package that was in sid for only 2 days, that 1.6.17dfsg-3.1 NMU has caused me a lot of work. I'm downgrading the severity because 1.6.17dfsg-3.1 was never in wheezy, so this issue is not release-critical for wheezy. I hope you don't mind. I will fix it in the next upload, but I'd like the current upload to transition to wheezy first, if possible. Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621460: Accepted subversion 1.6.17dfsg-3.1 (source all amd64)
[OndÅej Surý] I did reply you: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621460#34 and you didn't respond from that time at all. Yes, your reply was: | I thing it is reasonable that in your case it's probably better to | either depend directly on libdb5.1-dev + db5.1-util (and db4.8-util) | or on libdb-dev (= 5.1), libdb-dev ( 5.2), db-util (= 5.1), | db-util ( 5.2). I agree (which is why I didn't reply). That is what I will do, but it is not what your NMU did. There's really no reason to depend on specific libdbX.Y-dev version and dbX.Y-util, you would only break the ability to do binNMUs when needed to switch the default db version in the unstable archive. Correct. I don't want the DB version to change with a binNMU! If that were true, it would mean the new version, and the upgrade, has not been tested! I have good historical reason to believe that each new DB version _does_ need to be tested. 4.2 - 4.3 - 4.4 was quite unpleasant, and I don't trust Oracle not to do that again. Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669494: subversion: FTBFS: tests failed
[Lucas Nussbaum] During a rebuild of all packages in sid, your package failed to build on amd64. This looks a lot like a failure due to apr 1.4.6, which now randomizes hash enumeration for security reasons. This then randomizes the ordering of a lot of things in the Subversion API, which doesn't break Subversion itself, but does break a certain portion of its testsuite. Thanks for the report, Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632573: serf-1.0.1 packaged
close 632573 1.0.1-1 close 525035 1.0.1-1 thanks [Michael Diers] Sorry for the noise, I just noticed that serf (1.0.1-1) is in fact available in experimental. Yes, sorry for not metioning this earlier: the reason I didn't follow up with your sponsor request is that 1.0.0 - 1.0.1 was such a small change that just doing it myself was likely to be no more work than reviewing the same work from somebody else. ...Oh, and it seems, now that most of the buildds (especially kFreeBSD) have had a chance to build this version, I can close these FTBFS bugs. Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642250: Upgrade fails to keep mod_authz_svn enabled
Package: libapache2-svn Version: 1.6.17dfsg-2 Severity: serious Tags: pending As of 1.6.17dfsg-2, I split mod_dav_svn and mod_authz_svn into two .load files, since most people do not actually need the latter. However, the maintscript magic that keeps mod_authz_svn enabled on upgrades does not work. The workaround is to run 'a2enmod authz_svn' as root. I've got a fix queued for the next upload. I'm setting this 'serious' because it will break those installations that configure mod_authz_svn to do anything. But I suspect this is a small minority of installations, though. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632573: serf/experimental: FTBFS (kfreebsd): testsuite failures
[Christoph Egger] There were 7 failures: 1) test_serf_connection_request_create: ../test/test_context.c:166: expected 0 but was 22 2) test_serf_connection_priority_request_create: ../test/test_context.c:265: expected 0 but was 22 3) test_serf_closed_connection: ../test/test_context.c:404: expected 0 but was 22 4) test_serf_setup_proxy: ../test/test_context.c:506: expected 0 but was 22 5) test_keepalive_limit_one_by_one: ../test/test_context.c:657: expected 0 but was 22 6) test_keepalive_limit_one_by_one_and_burst: ../test/test_context.c:811: expected 0 but was 22 7) test_serf_progress_callback: ../test/test_context.c:933: expected 0 but was 22 Thanks - I saw those. serf on Linux was FTBFS in pretty much exactly the same way until I kludged the testsuite to connect to ip6-localhost instead of localhost. There was some confusion about trying to use the 'localhost' IP on an IPv6 socket. I don't fully understand it myself. But if upstream can resolve it at some point, it will probably resolve this failure too. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631736: Processed: sqlite3: PRAGMA case_sensitive_like fails
Attaching the test case for this bug, from
http://svn.haxx.se/dev/archive-2011-06/0866.shtml.
It works with 3.7.6.3-1, fails with 3.7.7-1.
#include assert.h
#include stdio.h
#include sqlite3.h
#define BUSY_TIMEOUT 1
int main(void)
{
sqlite3 *db3;
const char *path = foo.db;
int flags = SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE;
#ifdef SQLITE_OPEN_NOMUTEX
flags |= SQLITE_OPEN_NOMUTEX;
#endif
assert(SQLITE_OK == sqlite3_open_v2(path, db3, flags, NULL));
assert(SQLITE_OK == sqlite3_busy_timeout(db3, BUSY_TIMEOUT));
assert(SQLITE_OK == sqlite3_busy_timeout(db3, BUSY_TIMEOUT));
{
char *errmsg;
int err = sqlite3_exec(db3, PRAGMA case_sensitive_like=1;, NULL, NULL, errmsg);
if (err != SQLITE_OK)
printf(Error %d: %s\n, err, errmsg), sqlite3_free(errmsg);
}
return 0;
}
Bug#631736: Upstream fix for PRAGMA case_sensitive=1
tags patch thanks This bug has now been fixed upstream with a one-line patch: Patch: http://www.sqlite.org/src/ci/faa38c8724 Info: http://www.sqlite.org/src/info/25ee812710 -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619036: [php-maint] Bug#619036: php5: Build-Depends uninstallable
On Sunday 20 March 2011, Raphael Geissert wrote: For apache: Stefan et al, Do you have any objection to switch to libdb5.1-dev (and bd on libdb-dev)? [Stefan Fritsch] Switching libdb version in apr-util has to be coordinated with subversion. I am not sure we want that to happen automatically when the libdb maintainers change the default version, but I could be wrong. Since only a single libdb*-dev can be installed at a time, and since libaprutil1-dev Depends on one of them, any apr-util reverse dep is forced to use the same bdb version. Even though, in Subversion's case, we don't use the apr-util frontend to libdb* at all. My preferred solution is to decouple apr-util and libdb, by not having the Depends in libaprutil1-dev. I note that (at least for Subversion) this should not pose any problems at runtime: libdb uses symbol versioning, and libsvn1 picks up the correct Depends: libdb4.8 via dpkg-shlibdeps. The only reason I can see for libaprutil1-dev to depend on libdb*-dev is /usr/include/apr-1.0/apu_want.h, a feature where an application can request an include of db.h. I wonder if any of its reverse deps are actually using this very minor feature. Subversion can optionally find the right db.h that way, but we don't use it in Debian. Anyway, I wonder if any other reverse deps of apr-util would break if it stopped depending on libdb*-dev. Even if so, adding some Build-Depends: libdb4.8-dev or similar to a few packages seems reasonable to me. To answer your original question, I have not tested Subversion with libdb 5.1. I will try to remember to do that soon. There are upstream indications that it is compatible. Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#608925: Couldn't, perform atomic initialization quick fix
[Arthur de Jong] $ svn commit -m 'msg' some_file.txt Adding some_file.txt Transmitting file data .svn: Commit failed (details follow): svn: While preparing '/home/arthur/test/some_file.txt' for commit svn: Couldn't perform atomic initialization svn: Couldn't perform atomic initialization svn: SQLite compiled for 3.7.4, but running with 3.7.3 This is not actually an SQLite compatibility matter - it is libsvn being too paranoid. I've relaxed the SQLite version check so it only checks for x.y.0, not x.y.z. I will upload shortly and will try to get it into squeeze. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561516: subversion: FTBFS with gcj 4.4: subversion/bindings/javahl/include/*$*: No such file or directory
[Nobuhiro Iwamatsu] I updated debian/patches/java-build. Package build was OK. Please check and apply attached patch. Thanks, looks good. But it won't work with gcj 4.3. So I'll have to either wait until the default gcj is 4.4, or depend on gcj-4.4 explicitly. That, or just switch to openjdk as Ubuntu has done - in which case, I believe this entire patch is obsolete. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561516: subversion: FTBFS with gcj 4.4: subversion/bindings/javahl/include/*$*: No such file or directory
Peter Samuelson wrote: Thanks, looks good. But it won't work with gcj 4.3. So I'll have to either wait until the default gcj is 4.4, or depend on gcj-4.4 explicitly. [Luk Claes] Default gcj is already 4.4. I was misled by packages.debian.org, particularly the 'gcc-defaults' changelog which mentions switching to gcj-4.3 but does not mention switching to gcj-4.4. The correct information exists there if only I'd followed the dependency chain correctly, but I find it confusing. Looking at these packages, it appears I should probably also change Build-Depends from java-gcj-compat-dev to gcj-jdk. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557889: libserf-0-0-dev: Fails to install: missing Replaces for design-guide.txt.gz
[Cyril Brulebois] it looks like your package is missing a Replaces or even a Conflicts against older libserf-0-0 packages: Yeah, just Replaces. Doesn't need Conflicts as it has a strict Depends. Thanks, fixed in -2, -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557457: subversion: FTBFS due to conflicting db-dev requirements in the build-deps
tags 557457 pending thanks [Marc 'HE' Brockschmidt] HE peterS: The problem is that subversion build-depends on libdb4.7-dev, libaprutil1-dev, and libaprutil1-dev depends on libdb4.8-dev. No way to get the build-deps installed. Yes, I'm aware. I have changed the Build-Depends locally, just haven't uploaded yet. (I was trying to find a good block of time to address the other FTBFS, related to the two ruby test failures. I hope I will have enough time this afternoon.) Thanks, Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554028: subversion: Client/server version mismatch
[Jes�gel] $svn --version svn, version 0.28.2 (r6946) compiled Sep 3 2003, 02:19:05 $ svnserve --version svnserve, versión 1.6.6 (r40053) compilado Oct 22 2009, 18:28:41 Sounds like you have a 'svn' binary somewhere else in your path. Make sure you're using /usr/bin/svn specifically. Try 'type -a svn'. Thanks, -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554038: [cdrkit] FTBFS with newer eglibc
[Peter Fritzsche] /home/peter/rebuild/build/cdrkit/cdrkit-1.1.9/wodim/../include/schily.h:193: error: conflicting types for 'getline' /usr/include/stdio.h:651: error: previous declaration of 'getline' was here Fix is pending. I meant to upload it a week or two ago, and didn't. Thanks, -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553535: libapache2-svn: dir-or-file-in-var-www /var/www/apache2-default/svnindex.xsl and two others
[Manoj Srivastava] Package: libapache2-svn Version: 1.6.6dfsg-1 Severity: serious User: lintian-ma...@debian.org Usertags: dir-or-file-in-var-www Thanks, the files in libapache2-svn are just example files, so I've moved them /usr/share/doc/*/examples/. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545372: subversion: FTBFS on powerpc: tests failed
Peter Samuelson wrote: The problem is that I can't reproduce the bug on my platforms, and those who can reproduce it (it sometimes happens on kfreebsd) don't know ruby. Nor do I, for that matter. There was some effort at debugging it awhile back, but it was inconclusive. [Luk Claes] Any reason why you don't try the powerpc porter machine? 1) One of the kfreebsd porters was going to get back to me with more debugging, so I let it go. I mostly forgot to ping him. I think he may have just rebuilt and rebuilt until it happened to pass the test (which appears to be a glitch with timestamp conversions, so not 100% repeatable), then uploaded. 2) Between apache2-threaded-dev, kdelibs5-dev, python-all-dev, and f'ing java-gcj-compat-dev, debugging a full build of svn would require asking DSA to install a _lot_ of stuff. I didn't want to do that until I was sure nobody else was already working on this. Anyway I'll ping upstream again, especially now that 1.6.6 is out and the test failures continue - of the two powerpc test failures from before, one just happened on armel and the other happened on kfreebsd-i386. Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545372: subversion: FTBFS on powerpc: tests failed
[Raphael Geissert] Do you have any updates on this issue? it's been open for more than a month without any sort of visible response from your part, at least on the bug report. The problem is that I can't reproduce the bug on my platforms, and those who can reproduce it (it sometimes happens on kfreebsd) don't know ruby. Nor do I, for that matter. There was some effort at debugging it awhile back, but it was inconclusive. I expect to upload subversion 1.6.6 sometime today. I don't think upstream has addressed this bug, but I'd like to let the buildds reproduce it for me so I'll know for sure. Peter -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544877: libsvn_client-1.la and libsvn_ra-1.la depend on libsasl2 but libsvn-dev doesn't
[Emilio Pozuelo Monfort] The -dev package should thus depend on libsasl2-dev. Right now anjuta FTBFS because of this, thus severity serious. You are correct, of course. I'll add libsasl2-dev to Depends for now, but I've also been thinking of clearing out the dependency_libs field as suggested in the recent debian-devel thread. (I know you know about the thread, as you've posted to it.) The reasons I'm not clearing out dependency_libs immediately are explained n my post at http://lists.debian.org/debian-devel/2009/08/msg00813.html, and Paul's reply at http://lists.debian.org/debian-devel/2009/08/msg00854.html, which indicates that libtool upstream may fix this _properly_ in the future. I guess I'll follow up and ask him if they have a timeframe for what they are talking about. Thanks, -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544877: libsvn_client-1.la and libsvn_ra-1.la depend on libsasl2 but libsvn-dev doesn't
found 544877 1.5.0dfsg1-1 thanks [Emilio Pozuelo Monfort] The -dev package should thus depend on libsasl2-dev. As best I can tell, this bug has been around since I first enabled sasl support in 1.5.0, before the lenny freeze. I wonder why anjuta and other packages didn't FTBFS before now. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543617: svn: warnings about X11 initialization failed when committing
forcemerge 542403 543617 thanks ** (process:13690): WARNING **: couldn't connect to dbus session bus: dbus-launch failed to autolaunch D-Bus session: Autolaunch error: X11 initialization failed. Fixed in 1.6.5dfsg-1. Thanks, -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543110: subversion: FTBFS: Error: tag OUTPUT_DIRECTORY: Output directory `/build/user-subversion_1.6.4dfsg-1-amd64-zplffE/subversion-1.6.4dfs g/BUILD/doc/doxygen' does not exist and cannot be crea
severity 543110 important thanks [Lucas Nussbaum] make[1]: Entering directory `/build/user-subversion_1.6.4dfsg-1-amd64-zplffE/subversion-1.6.4dfsg/BUILD' ( cd /build/user-subversion_1.6.4dfsg-1-amd64-zplffE/subversion-1.6.4dfsg \ sed s,\(OUTPUT_DIRECTORY *= *\),\1/build/user-subversion_1.6.4dfsg-1-amd64-zplffE/subversion-1.6.4dfsg/BUILD/, \ doc/doxygen.conf | doxygen - ) Error: tag OUTPUT_DIRECTORY: Output directory `/build/user-subversion_1.6.4dfsg-1-amd64-zplffE/subversion-1.6.4dfsg/BUILD/doc/doxygen' does not exist and cannot be created Exiting... make[1]: *** [doc-api] Error 1 Thanks! This only happens with -j, so I am downgrading the severity, as I don't think it is release-critical. That said, I've fixed it upstream, and will include it in my next upload. I doubt that the one fix I did is the _only_ thing needed in that makefile for parallel safety, but the targets called by debian/rules seem to work, anyway. Thanks, -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525035: Can you reproduce bug 525035?
Can you still reproduce Debian bug 525035, failure to build the serf package on your local pbuilder installation? If so, please provide more details, especially your Debian version and architecture. I note that in 0.3.0-0.3 I've fixing a FTBFS on FreeBSD that probably isn't related. Thanks, -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542403: mysql-query-browser disturbs functioning other packages
retitle 542403 subversion allows libgnome-keyring to spam the console thanks [Dmitry E. Oboukhov] $ LANG=C svn up ** (process:12603): WARNING **: couldn't connect to dbus session bus: Failed to connect to socket /tmp/dbus-RD1Gn0diy6: Connection refused ** (process:12603): WARNING **: couldn't connect to dbus session bus: Failed to connect to socket /tmp/dbus-RD1Gn0diy6: Connection refused Yeah, this console spam comes to you from libgnome-keyring and libdbus. I haven't yet figured out how to tell those libraries to leave my stderr alone. It should be harmless, except of course for being console spam. The workaround is to disable the gnome-keyring plugin in ~/.subversion/config: [auth] password-stores = -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540958: libvorbis: CVE-2009-2663 vulnerability
CVE-2009-2663[0]: | libvorbis before r16182, as used in Mozilla Firefox before 3.0.13 and | 3.5.x before 3.5.2 and other products, allows context-dependent | attackers to cause a denial of service (memory corruption and | application crash) or possibly execute arbitrary code via a crafted | .ogg file. I've applied upstream's patch[*] to the etch and lenny libvorbis releases: http://p12n.org/tmp/cve-2009-2663/libvorbis_1.1.2.dfsg-1.4+etch1.dsc http://p12n.org/tmp/cve-2009-2663/libvorbis_1.2.0.dfsg-3.1+lenny1.dsc I'm prepared to upload the same patch to sid, as libvorbis 1.2.0.dfsg-6. (I could upload a new upstream version, but I'd like to try and resolve a dfsg situation there first.) [*] svn diff -r16180:16182 http://svn.xiph.org/trunk/vorbis -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#539687: marked as done (libogg-dev: Removal of .la should have been coordinated with other packages)
[Erik de Castro Lopo] I'm think I'm coming in rather late on this, but why were these .la files removed? I've read through bug#539687 and its still not clear. I can't speak for Ron, but in general, the reason to remove .la files is that pkg-config (and the .pc files in /usr/lib/pkgconfig) offers the same functionality, and more, with considerably less brokenness. We'd like to encourage upstreams to ship .pc files and use pkg-config in their configure.ac scripts as the primary means of detecting the presence of other libraries and how to use them. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540958: libvorbis: CVE-2009-2663 vulnerability
CVE-2009-2663[0]: | libvorbis before r16182, as used in Mozilla Firefox before 3.0.13 and | 3.5.x before 3.5.2 and other products, allows context-dependent | attackers to cause a denial of service (memory corruption and | application crash) or possibly execute arbitrary code via a crafted | .ogg file. Thanks, I'll prepare updates for etch, lenny, and sid. I assume the Mozillae in Debian use the system libvorbis, not a separate copy. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#540169: libvorbis-dev: libvorbis*.la refers to non-existant libogg.la
[Tim Muller] /usr/lib/libvorbis*.la refer to a now non-existant libogg.la (which was dropped in the latest libogg upload, ie. 1.1.4~dfsg-1 from August 2nd). Indeed - Christophe Mutricy emailed debian-release a couple days ago to ask for binNMUs of several packages affected by the libogg.la removal. http://lists.debian.org/debian-release/2009/08/msg00034.html This seems better than a sourceful upload. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539991: subversion: a succession of svn up can yield a working copy with local changes
[Vincent Lefevre] In fact, canonicalizing the $Id$ keyword would not be the correct solution, because when the Id keyword is removed, one should get the orignal data back (instead of $Id$), here $Id: lplain.bst,v 4.0 2000/01/31 18:11:53 vlefevre Exp $ I don't agree. I think you should get back $Id$, because that's what the repository was _supposed_ to have in it all along. Somehow it did not have that, due to some other bug, but the solution is to compensate for the other bug, not to compound it. For others following along, further discussion is at http://svn.haxx.se/dev/archive-2009-08/0050.shtml . -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539991: subversion: a succession of svn up can yield a working copy with local changes
[Vincent Lefevre] $ svn co file:///home/vinc17/private/svn-...@1952 wd-test $ cd wd-test $ svn pl -v ensl/these/lplain.bst Properties on 'ensl/these/lplain.bst': svn:keywords Id Date $ grep Id ensl/these/lplain.bst % $Id: lplain.bst 1950 2003-12-08 12:30:36Z lefevre $ $ grep Id ensl/these/.svn/text-base/lplain.bst.svn-base % $Id: lplain.bst,v 4.0 2000/01/31 18:11:53 vlefevre Exp $ How did this file get into this state? Normally, in the .svn/text-base copy of a file, like the copy in the repository, the $Id$ keyword is not expanded. It looks like an RCS identifier. Was this imported via cvs2svn, or by manual 'svn add' of your tree, or something else? Was the svn:keywords property set at the time of initial import, or later? Thanks, -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539384: anjuta: Linked with OpenSSL, seems to be a GPL violation
[Adrian Bunk] It might be enough to change the libneon build dependency to libneon27-gnutls-dev. You don't need a libneon build dependency at all, as I explained in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482512#10 . I even wrote a patch. (It was easy, it was just ripping out unnecessary stuff.) That seems to come through libserf. It seems GPL'ed software without an OpenSSL licence exception linked against libsvn is a candidate for my next batch of GPL violation RC bugs... @Peter: How important is the libserf usage in SVN, and are you aware of this problem? Usage? It is not used at all by default. But I will not remove it without very good reason, as some people need it. I think you have to stretch your logic pretty far to make it a GPL violation, though. Consider: anjuta-subversion.plugin uses libsvn_client libsvn_client uses libsvn_ra libsvn_ra can be configured to use libsvn_ra_serf libsvn_ra_serf uses libserf libserf uses the dreaded openssl These layers are pretty, well, layered. From a copyright perspective, you can't possibly argue that openssl had any influence on how anjuta was written. That is, libsvn_ra had little or no influence on the copyrightable bits of anjuta-subversion.plugin libsvn_ra_serf had little or no influence on the copyrightable bits of libsvn_client libserf had little or no influence on the copyrightable bits of libsvn_ra openssl had little or no influence on the copyrightable bits of libsvn_ra_serf The only way you could argue that they are at all related is that they share an address space at runtime. It is a far cry from software that calls the openssl API directly. If I must, I can enable the libsvn_ra loadable module interface, so that it doesn't even _load_ libsvn_ra_serf at all, unless you enable it in ~/.subversion/servers. That will keep the dirty libssl.so.0.9.8 away from our pretty GPL code. Or at least 'ldd' won't see it. But so far I haven't seen any reason to do this. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508406: Intend to create an -fPIC library package...
2) Runtime linking. This is overhead at application startup time. Something that embeds an SQL engine should not, I think, start up too frequently. Am I wrong? [Bernd Zeimetz] We're talking about amarok here. As a medi aplayer I could imagine it will be starte several times per day... Depends: amarok-common, amarok-engine-xine | amarok-engine-yauap, unzip, kdelibs4c2a, libc6, libgcc1, libgl1-mesa-glx | libgl1, libglib2.0-0, libgpod3-nogtk | libgpod3, libifp4, libkarma0, libmtp7, libmysqlclient15off, libnjb5, libpq5, libqt3-mt, libruby1.8, libsdl1.2debian, libsqlite3-0, libstdc++6, libtag1c2a, libtunepimp5, libusb-0.1-4, libvisual-0.4-0 ...I don't think the 'startup overhead of a shlib' argument holds up. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508406: Intend to create an -fPIC library package...
[Wouter Verhelst] Whether we should recommend using static libraries is another matter entirely; indeed performance does go down a teeny weeny bit when using shared libraries, but the difference shouldn't be *that* large; if it is, that probably means they're using a twisty maze of function calls, all alike, that they probably shouldn't be doing. As I understand it, the performance drawbacks of a shared library are: 1) The PIC code and its use of a GOT. Given that we're talking about a PIC static library, this is not relevant. 2) Runtime linking. This is overhead at application startup time. Something that embeds an SQL engine should not, I think, start up too frequently. Am I wrong? So what is the real performance advantage of this -fPIC static library? To me it looks like a different, less desirable, way to implement the 'prelink' optimization. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#520853: NMU patch
[Peter Eisentraut] +gpm (1.20.4-3.2) UNRELEASED; urgency=low + + * Non-maintainer upload. + * debian/patches/070_struct_ucred: fix FTBFS. Closes: #520853 + + -- Peter Eisentraut pet...@debian.org Thu, 23 Apr 2009 22:04:24 +0300 Ack, please go ahead. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507764: svn merge reverts previous merges
[Ben Hutchings] It turned out to be fairly easy to backport the upstream changes. Here's the patch: Thanks for tracking this down and backporting it, Ben. I hope I'll have time to make an upload in a couple of days. (Like much of the world, I'm out of town today and tomorrow.) A couple of Java tests fail but this appears to be expected. Yeah, that's been true since the beginning of time. Maybe if I switch to openjdk (as Ubuntu did already) that'll help. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#496482: neon v0.25 packages in Lenny
[Laszlo Boszormenyi] In short, do you want Lenny (will be released in 2009 as it seems) to contain a four year old piece of software which contains at least one unpatched security bug? No. That is why I said you should _not_ ship a libneon25 package. By shipping a dummy libneon25, you cause existing installed copies of neon25 to be deleted, which breaks old software that has not been recompiled. Why do you want to do this? Just stop building or shipping anything named libneon25. I still think this bug should be RC. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#495184: wodim: Fails, then asks me to use the option I've already given
[Nigel Horne] write(1, \t1000,2,0 12) 'Optiarc ' 'DVD..., 72 1000,2,0 12) 'Optiarc ' 'DVD RW AD-5170A ' '1.52' Removable CD-ROM ) = 72 write(1, \t1000,3,0 13) *\n..., 20 1000,3,0 13) * ) = 20 write(1, \t1000,4,0 14) *\n..., 20 1000,4,0 14) * ) = 20 write(1, \t1000,5,0 15) *\n..., 20 1000,5,0 15) * ) = 20 write(1, \t1000,6,0 16) *\n..., 20 1000,6,0 16) * ) = 20 write(1, \t1000,7,0 17) *\n..., 20 1000,7,0 17) * ) = 20 I thought you said wodim -scanbus didn't work? Looks to me like it worked. Does 'lsmod' indicate that you have the cdrom or ide_cd or ide_cd_mod modules loaded? Also, does 'cat /proc/sys/cdrom/info' show information about /dev/hdc? -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483996: [PATCH] subcommander: FTBFS: ld: cannot find -lsvn_ra_dav-1
tags 490351 + patch
thanks
[Lucas Nussbaum]
/usr/bin/ld: cannot find -lsvn_ra_dav-1
collect2: ld returned 1 exit status
ra_dav has been renamed to ra_neon, but nobody except subversion
internals should ever link to it. Instead you get its functionality by
linking to libsvn_ra-1. I raised a concern on upstream's dev list a
few months ago about the disappearance of ra_dav, but assumed it would
not affect Debian since we try not to link to libraries we don't need.
I'm attaching an edited version of the patch I already posted to
#483996 (basically the same issue) covering this bug as well.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
diff -urN a/configure.ac b/configure.ac
--- a/configure.ac
+++ b/configure.ac
@@ -249,55 +249,6 @@
##
-# check for neon
-#
-AC_MSG_CHECKING([for neon])
-AC_ARG_WITH(
- [neon],
- AC_HELP_STRING([--with-neon=DIR],[path to neon installation]),
- [
-neon_path=$withval
-with_neon=yes
- ],[
-with_neon=no
- ]
-)
-
-if test x$with_neon = xyes; then
- NEON_INCLUDES=-I$neon_path/include
- NEON_LIBS=`$neon_path/bin/neon-config --libs`
-else
- NEON_INCLUDES=
- NEON_LIBS=
-fi
-
-CPPFLAGS=$NEON_INCLUDES
-
-AC_LANG(C++)
-AC_COMPILE_IFELSE(
- AC_LANG_PROGRAM(
-[[#include neon/ne_socket.h]],
-[[ne_sock_exit()]]
-),
- [
-AC_MSG_RESULT([yes])
-AC_MSG_RESULT([headers $NEON_INCLUDES])
-AC_MSG_RESULT([libraries $NEON_LIBS])
- ],[
-AC_MSG_RESULT([no])
-AC_MSG_ERROR([try setting --with-neon])
- ]
-)
-
-AC_SUBST(NEON_INCLUDES)
-AC_SUBST(NEON_LIBS)
-#
-# end check for neon
-##
-
-
-
-##
# check for openssl
#
AC_MSG_CHECKING([for openssl])
diff -urN a/debian/control b/debian/control
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@
Maintainer: Andreas Fester [EMAIL PROTECTED]
Uploaders: Loic Minier [EMAIL PROTECTED]
Build-Depends: debhelper ( 5.0.0), dpatch, libqt3-mt-dev ( 3.3),
- libboost-dev, libapr1-dev, libdb4.6-dev, libsvn-dev, libneon27-dev,
+ libboost-dev, libapr1-dev, libdb4.6-dev, libsvn-dev,
libssl-dev, xsltproc, docbook-xsl, autotools-dev, dpkg-dev (= 1.13.19)
Standards-Version: 3.7.2
diff -urN a/subcommander/Makefile.am b/subcommander/Makefile.am
--- a/subcommander/Makefile.am
+++ b/subcommander/Makefile.am
@@ -39,16 +39,15 @@
## by apr_time_from_sec
AM_CPPFLAGS= -DQT_THREAD_SUPPORT @APR_CPPFLAGS@ @STLPORT_INCLUDES@ -I.. @QT_INCLUDES@ \
- @SVN_INCLUDES@ @APR_INCLUDES@ @APU_INCLUDES@ @NEON_INCLUDES@ \
+ @SVN_INCLUDES@ @APR_INCLUDES@ @APU_INCLUDES@ \
@SSL_INCLUDES@ @BOOST_INCLUDES@ -D__STDC_CONSTANT_MACROS=1
bin_PROGRAMS = subcommander
subcommander_LDADD = -L../util -L../svn -L../sublib -lsvn -lutil -lsublib @QT_LIBS@ \
-lz @APR_LIBS@ @APU_LIBS@ @SVN_LIBS@ -lsvn_client-1 -lsvn_subr-1 \
- -lsvn_ra-1 -lsvn_wc-1 -lsvn_delta-1 -lsvn_diff-1 -lsvn_ra_dav-1 \
- -lsvn_ra_local-1 -lsvn_ra_svn-1 -lsvn_repos-1 -lsvn_fs-1 \
- -lsvn_fs_fs-1 @STLPORT_LIBS@ @NEON_LIBS@
+ -lsvn_ra-1 -lsvn_wc-1 -lsvn_delta-1 -lsvn_diff-1 \
+ -lsvn_repos-1 -lsvn_fs-1 @STLPORT_LIBS@
subcommander_DEPENDENCIES = ../sublib/libsublib.a ../svn/libsvn.a ../util/libutil.a
diff -urN a/subcommander/subcommander.cpp b/subcommander/subcommander.cpp
--- a/subcommander/subcommander.cpp
+++ b/subcommander/subcommander.cpp
@@ -26,15 +26,11 @@
#include qapplication.h
#include qstylefactory.h
-// neon
-#include neon/ne_socket.h
-#include neon/ne_utils.h
-
// openssl
#include openssl/evp.h
#include openssl/err.h
-// cleanup neon/ssl stuff to avoid a lot of noise when running with
+// cleanup ssl stuff to avoid a lot of noise when running with
// memory leak detection.
void exit_ssl()
@@ -47,11 +43,6 @@
ERR_free_strings();
}
-void exit_neon()
-{
- ne_sock_exit();
-}
-
int main( int argc, char* argv[] )
@@ -95,9 +86,6 @@
#if !defined(Q_WS_X11)
QApplication::setStyle( new MacStyle() );
#endif // Q_WS_X11
-
-// about dialog
-setNeonVersion( ne_version_string() );
}
catch( sc::Exception e )
{
@@ -146,7 +134,6 @@
config.save();
exit_ssl();
-exit_neon();
TargetRepository::teardown();
stopStackProcess();
diff -urN a/sublib/AboutDialog.cpp b/sublib/AboutDialog.cpp
--- a/sublib/AboutDialog.cpp
+++ b/sublib/AboutDialog.cpp
@@ -277,20 +277,6 @@
#endif
trtd align=center valign=bottom colspan=2 * * * /td/tr;
-if( getLongAppName() == subcommander )
-{
- about2 +=
-tr
- td align=right;
- about2 += getNeonVersion();
- about2 +=
- /td
- td align=left http://www.webdav.org; /td
-/tr
-trtd align=center valign=bottom colspan=2 * * * /td/tr;
-}
-
-
about2 +=
tr
td align=right;
diff -urN a/sublib/Utility.cpp b/sublib/Utility.cpp
--- a/sublib/Utility.cpp
+++ b/sublib/Utility.cpp
@@ -201,15
Bug#488996: mod_dav_svn.so: undefined symbol: svn_mergeinfo__remove_prefix_from_catalog
[Ricardo Mones] /etc/apache2/mods-enabled/dav_svn.load: Cannot load /usr/lib/apache2/modules/mod_dav_svn.so into server: /usr/lib/apache2/modules/mod_dav_svn.so: undefined symbol: svn_mergeinfo__remove_prefix_from_catalog Upgrade libsvn1 to 1.5.0dfsg1-2 as well. I guess I forgot to ensure the dependency was tight enough. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486937: DEB_BUILD_OPTIONS must be whitespace-separated
[Raphael Hertzog] Should that fix be backported into the lenny branch? I've already fixed my package to work around this ... but it _would_ be a bit of a shame for the debian/rules example code suggested by Policy section 4.9.1 to not actually work until lenny+1. And maintainers might not even notice the fact that DEB_BUILD_OPTIONS is ignored in their package - I mean, who tests that? So that's kind of bad too. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#486937: DEB_BUILD_OPTIONS must be whitespace-separated
Package: dpkg-dev
Version: 1.14.20
Severity: serious
Tags: patch
Policy 3.8.0.1, section 4.9.1, on DEB_BUILD_OPTIONS:
If multiple flags are given, they must be separated by whitespace.
dpkg-buildpackage uses , separators instead, which breaks any rules
file that follows the example code in Policy.
Presumably this bug is not RC for lenny, as the relevant Policy text is
new to 3.8.0.
diff -urN dpkg-1.14.20.orig/scripts/Dpkg/BuildOptions.pm
dpkg-1.14.20/scripts/Dpkg/BuildOptions.pm
--- dpkg-1.14.20.orig/scripts/Dpkg/BuildOptions.pm 2008-06-18
02:33:30.0 -0500
+++ dpkg-1.14.20/scripts/Dpkg/BuildOptions.pm 2008-06-18 23:45:52.0
-0500
@@ -38,13 +38,13 @@
$overwrite = 1 if not defined($overwrite);
my $env = $overwrite ? '' : $ENV{DEB_BUILD_OPTIONS}||'';
-if ($env) { $env .= ',' }
+if ($env) { $env .= ' ' }
while (my ($k, $v) = each %$opts) {
if ($v) {
- $env .= $k=$v,;
+ $env .= $k=$v ;
} else {
- $env .= $k,;
+ $env .= $k ;
}
}
Bug#482512: subcommander: FTBFS: Unsatisfiable build-dependency: libsvn-dev: Depends: libneon27-gnutls-dev
[Lucas Nussbaum] libsvn-dev depends on libneon27-gnutls-dev, while anjuta and subcommander build-depend on libneon27-dev, libsvn-dev. This causes those packages to FTBFS. The reason for the Depends is to support static linking. As such, it doesn't make sense to make the Depends more permissive; you don't want to statically link the wrong neon. What I could do is _downgrade_ it to a Suggests. However, looking at both anjuta and subcommander: anjuta doesn't need neon at all. Its configure script checks for neon apparently due to an irrational belief that linking to libsvn will fail if neon isn't present; the neon check is a precaution to ensure that it's OK to enable svn support. Thus I'd rather see the anjuta maintainer drop the Build-Depends and patch out the configure check, trusting that libsvn-dev by itself will depend on whatever it needs. (It is probably the same story for the Build-Depends on libdb4.6-dev, but I didn't check that.) Subcommander doesn't actually use neon, but it calls it in 2 places: one to get the neon version to display in the Help/About box; two, it calls ne_sock_exit() at shutdown time, apparently to avoid memory leak detection warnings. (H, where have I heard recently about fixing Purify warning fixes) Thus I think the neon support in subcommander could be patched out as well. So, both anjuta and subcommander think they need neon, but what they really need is libsvn_ra, which talks to libsvn_ra_dav, which uses neon. By removing neon detection from both, we would simplify our dependency graph. I'm attaching (untested) patches. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ diff -urN anjuta-2.4.1.orig/configure.in anjuta-2.4.1/configure.in --- anjuta-2.4.1.orig/configure.in 2008-04-07 01:43:44.0 -0500 +++ anjuta-2.4.1/configure.in 2008-05-23 08:52:34.0 -0500 @@ -44,7 +44,6 @@ GNOMEBUILD_REQUIRED=0.2.0 GLADEUI_REQUIRED=3.2.0 LIBGRAPHVIZ_REQUIRED=1.0 -NEON_REQUIRED=0.24.5 SUBVERSION_REQUIRED=1.0.2 GTKSOURCEVIEW_REQUIRED=2.1.2 GTKSOURCEVIEW_GNOME_REQUIRED=2.14 @@ -80,7 +79,6 @@ AC_SUBST(GLADEUI_REQUIRED) AC_SUBST(GLADEUI_SVN_REQUIRED) AC_SUBST(LIBGRAPHVIZ_REQUIRED) -AC_SUBST(NEON_REQUIRED) AC_SUBST(SUBVERSION_REQUIRED) AC_SUBST(GTKSOURCEVIEW_REQUIRED) AC_SUBST(GTKSOURCEVIEW_GNOME_REQUIRED) @@ -1024,40 +1022,6 @@ else AC_MSG_RESULT([not found]) fi - - dnl - - dnl NEON. Required by subversion (devel) - dnl-- - - dnl Check for neon. It is required by subversion libs, but for - dnl for some strange reason it's not in it's dependencies. - dnl subversion plugin will be disabled if neon (devel) is not - dnl installed, even if subversion (devel) is installed. - - NEON_CONFIGS=neon-config - AC_ARG_WITH(neon-config, - [[ --with-neon-config=FILEUse the given path to neon-config when determining -Neon configuration; defaults to neon-config]], - [ - if test $withval != yes -a $withval != ; then - NEON_CONFIGS=$withval - fi - ]) - AC_MSG_CHECKING([for Neon]) - NEON_CONFIG= - for VALUE in $NEON_CONFIGS ; do - if $VALUE --cflags /dev/null 21 ; then - NEON_CONFIG=$VALUE - break - fi - done - if test $NEON_CONFIG ; then - AC_MSG_RESULT([found]) - else - AC_MSG_RESULT([not found]) - SVN_INCLUDE= - SVN_LIB= - fi fi dnl -- @@ -1219,7 +1183,6 @@ echo Building subversion plugin: NO echo Requires apr (= 0.9.4); http://subversion.org; echo Requires apr-util (= 0.9.4); http://subversion.org; - echo Requires neon (= 0.24.5); http://subversion.org; echo Requires subversion (= 1.0.2); http://subversion.org; fi diff -urN anjuta-2.4.1.orig/debian/control anjuta-2.4.1/debian/control --- anjuta-2.4.1.orig/debian/control 2008-05-23 08:10:38.0 -0500 +++ anjuta-2.4.1/debian/control 2008-05-23 08:53:05.0 -0500 @@ -2,7 +2,7 @@ Section: gnome Priority: optional Maintainer: Rob Bradford [EMAIL PROTECTED] -Build-Depends: debhelper (= 5.0.0), cdbs, chrpath, gnome-common, gtk-doc-tools, gnome-doc-utils, scrollkeeper, libglib2.0-dev, libgtk2.0-dev, liborbit-dev, libglade2-dev, libgnome2-dev, libgnomecanvas2-dev, libgnomeui-dev, libgnomeprint2.2-dev, libgnomeprintui2.2-dev, libvte-dev, libxml2-dev, libpango1.0-dev, libpcre3-dev, libdevhelp-1-dev, libgdl-1-dev, libgbf-1-dev, libgladeui-1-dev, libgraphviz-dev | libgraphviz3-dev, libneon27-dev | libneon26-dev, libsvn-dev, libgtksourceview2.0-dev (= 2.2.0), binutils-dev, libwnck-dev, libxslt1-dev, automake1.9, autogen +Build-Depends: debhelper (= 5.0.0), cdbs, chrpath, gnome-common, gtk-doc-tools, gnome-doc-utils, scrollkeeper, libglib2.0-dev, libgtk2.0-dev, liborbit-dev, libglade2-dev, libgnome2-dev, libgnomecanvas2-dev, libgnomeui-dev, libgnomeprint2.2-dev, libgnomeprintui2.2-dev, libvte-dev, libxml2-dev, libpango1.0-dev, libpcre3-dev, libdevhelp-1-dev
Bug#482259: subversion: FTBFS: configure: error: Berkeley DB 4.0.14 wasn't found.
[Lucas Nussbaum] Package: subversion Version: 1.4.6dfsg1-4 checking for availability of Berkeley DB... no configure: error: Berkeley DB 4.0.14 wasn't found. make: *** [debian/stamp-configure] Error 1 Looks like it's caused by a change in libaprutil1-dev. It's odd because I didn't think such a change had been made recently ... but either way, it shouldn't be hard to patch on my side. Thanks, -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479079: subversion: FTBFS: FAIL: svnsync_tests.py 19: test copying revs with no svn:author revprops
[Kurt Roeckx] File /build/buildd/subversion-1.4.6dfsg1/subversion/tests/cmdline/svntest/main.py, line 286, in run_command_stdin pid, wait_code = os.wait() OSError: [Errno 10] No child processes Yes, this seems to be due to python 2.5. (os.open3 and os.wait cannot be reliably used together.) Fixed in -4. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476467: subversion: http support still broken on amd64 - 1.4.6dfsg1-3 haven't upload to amd64 repository
[Luk Claes] The automatic build failed with a test error: FAIL: import_tests.py 4: import ignored files in imported dirs Yes, there seems to be a bug where the testsuite usually succeeds, but sometimes fails a few random tests. I haven't found it yet. This upload also managed to find a gcc-4.3 crash, a python2.5 crash, and a dirty buildd chroot. But it did build on hppa and m68k! I was hoping the amd64 buildds would have enough spare CPU time to retry the build, but that was 2 days ago, so I will probably go ahead and upload my own amd64 build as soon as I get home to my private key. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476117: Bug#476119: subversion: repository access ra_dav module missing
forcemerge 476117 476119 tags 476117 pending thanks Thanks for the heads-up. I fixed the mess from the NMU and am building/testing it now. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468465: FTBFS: make: execvp: ./configure: Permission denied
[Vincent Bernat] --- gpm-1.20.3~pre3/debian/rules~ 2008-02-29 09:40:30.0 +0100 +++ gpm-1.20.3~pre3/debian/rules 2008-02-29 09:40:50.0 +0100 @@ -19,6 +19,7 @@ autoconf config.status: configure + chmod +x configure ./configure --prefix=/usr --sysconfdir=/etc build: config.status Hmmm ... so apparently it didn't occur to either you or Andi Barth (who applied your patch in an NMU) to wonder _why_ autoconf would produce a non-executable configure file, or why this happens only in gpm and not in the countless other packages that run autoconf. (Turns out we're triggering an autoconf bug. I've fixed this _properly_ for the next upload.) -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#465609: libsvn-ruby: lost (trivial) content, confusing apt/dpkg
[Aaron M. Ucko] Could you please restore the /usr/share/doc/libsvn-ruby - libsvn-ruby1.8 symlink it used to contain Sure, next upload. There was a dangling reference in debian/rules to a variable I'd removed. The only reason it didn't FTBFS is that it's legal to send a single filename argument to ln -s. Thanks, -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#465432: subversion: need db4.6 upgrade instructions
[Peter Samuelson] Until I can do this, please use the instructions at svn export svn://svn.debian.org/pkg-subversion/tags/1.3.0-1/debian/README.db4.3 Scratch that, 'svnadmin recover /path/to/repository' is a lot easier. (: -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#465432: subversion: need db4.6 upgrade instructions
Package: subversion Version: 1.4.6dfsg1-1 Severity: serious We need to resurrect README.db4.3 from the 1.2 era, as we have once again the same issue with migrating a svn repository from db4.4 to db4.6. *Sigh* - when db4.4 auto-upgraded older repositories, I hoped they'd permanently taken care of this issue. Until I can do this, please use the instructions at svn export svn://svn.debian.org/pkg-subversion/tags/1.3.0-1/debian/README.db4.3 ...using the db4.4_* and db4.6_* commands instead of db4.2_* and db4.3_*. signature.asc Description: Digital signature
Bug#460333: FTBFS due to libdb-dev transition
tags 460333 pending thanks [Joey Hess] subversion build-depends on libdb4.4-dev, and on libaprutil1-dev. Yeah, I coordinated the apr-util db4.4 - db4.6 thing with Stefan, and have tested Subversion with db4.6. (Seems to work fine.) The next svn upload has been blocking on #453166 for a long time now - help is welcome! Thanks, -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#458771: subversion: FTBFS: duplicate definition of '_mSWIG'
forcemerge 453166 458771 thanks [Martin Pitt] /tmp/subversion-1.4.4dfsg1/subversion/bindings/swig/proxy/swig_ruby_external_runtime.swg:819: error: redefinition of '_mSWIG' /tmp/subversion-1.4.4dfsg1/subversion/bindings/swig/proxy/rubyhead.swg:107: error: previous definition of '_mSWIG' was here That's an incompatibility between subversion 1.4.x and swig 1.3.33. See svn://svn.debian.org/pkg-subversion/trunk/debian/patches/ruby-newswig for the simple fix, which however doesn't work on swig 1.3.25 (which is what upstream officially supports). Note that after fixing this, the ruby bindings still don't work. (They compile, but the testsuite fails.) Help would be appreciated from anyone who knows swig and/or ruby - I'm afraid I don't know much about either one. I pinged upstream and the Debian swig maintainer several days ago, no reply. (The other obvious fix is not to build from source, but to use upstream's swig-generated files. Alas, I refuse to do this, as I believe the Four Freedoms imply the ability to build from source.) -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#453166: 1.4.x ruby bindings + swig 1.3.33 problem
So, I know swig 1.3.33 is not supported in Subversion 1.4.x (and not in
trunk either?), but it seems to have changed a couple of things that
break the ruby bindings.
The first is removing #include rubyhead.swg from the top of
libsvn_swig_ruby/swigutil_rb.c, which has already been dealt with in
trunk. That change fails to support swig 1.3.25, so it can't be
unconditional in 1.4.x.
The second is a repeated failure in 'make check-swig-rb':
TypeError: Expected argument 1 of type svn_auth_baton_t *, but got Array []
in SWIG method 'auth_baton'
{SRC}/subversion/bindings/swig/ruby/svn/client.rb:74:in `auth_baton='
{SRC}/subversion/bindings/swig/ruby/svn/client.rb:74:in `initialize'
{SRC}/subversion/bindings/swig/ruby/svn/client.rb:60:in `__send__'
{SRC}/subversion/bindings/swig/ruby/svn/client.rb:60:in `new'
{SRC}/subversion/bindings/swig/ruby/test/util.rb:208:in `make_context'
{SRC}/subversion/bindings/swig/ruby/test/util.rb:136:in `setup_wc'
{SRC}/subversion/bindings/swig/ruby/test/util.rb:28:in `setup_basic'
{SRC}/subversion/bindings/swig/ruby/test/test_wc.rb:11:in `setup'
Unfortunately I don't know enough about either swig or ruby to figure
out what's wrong here and how to fix it. Roderich Schupp dug further
in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=453166#22 - can
anyone figure out the rest of the problem and solution?
Thanks.
(This is preventing me from uploading 1.4.6 to Debian, where largely
for philosophical reasons I build the whole package from source.)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
signature.asc
Description: Digital signature
Bug#455427: OPEN_MAX macro removed from linux/limits.h on
[Martin Michlmayr] The OPEN_MAX macro was removed from linux/limits.h on amd64, see #454875. waldi writes sysconf(_SC_OPEN_MAX) ... right. Thanks. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#432467: subversion: svn co on ia64 fails with PROPFIND errors but works just fine on i686
[Al Stone] tomorrow I'll try bringing all of the installed packages up-to-date. just in case. It's only been since Saturday, but there's 76 updated packages in the queue already. The immediate suspect would be libneon26, but there is only one version of that, 0.26.3-1, which satisfies the dependency in libsvn1. So you and Troy surely have the same version of libneon26. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#432467: subversion: svn co on ia64 fails with PROPFIND errors but works just fine on i686
[Al Stone] I then removed /etc/subversion, and now it works. Unfortunately, I did not save a copy of the files that were in that directory. And, I did not check my backup _before_hand -- it turns out that the files weren't in the backup, either. But, that's a different problem. Hrrm. The default /etc/subversion/config and /etc/subversion/servers are entirely empty except for comments and section headers. If you purge then reinstall subversion, it will restore the default files in /etc/subversion. Can you confirm that this does not break your system again? Thanks. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#432467: subversion: svn co on ia64 fails with PROPFIND errors but works just fine on i686
[Al Stone] The following command to get a copy of an SVN repository fails on an ia64 system: $ svn co http://llvm.org/svn/llvm-project/llvm/trunk anywhere svn: PROPFIND request failed on '/svn/llvm-project/llvm/trunk' svn: PROPFIND of '/svn/llvm-project/llvm/trunk': could not connect to server (http://llvm.org) I don't have an ia64 system so I can't try to reproduce this. Can you try with another http server? For example: $ svn co http://svn.collab.net/repos/svn/trunk/subversion/libsvn_subr subr Also, does non-http repository access work? $ svn co svn://svn.debian.org/pkg-subversion/trunk/debian debian-svn (If so, by the way, the bug is not grave as it does not render package unusable.) -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#432467: subversion: svn co on ia64 fails with PROPFIND errors but works just fine on i686
[Troy Heber] This is the error you will get if you are behind a proxy and can not access the machine directly. From your ia64 box can you telnet to port 80 of llvm.org? Or, if it's a transparent proxy, telnet won't necessarily reveal the problem. What will show the problem is to try https, which transparent proxies have to leave alone (or server certs wouldn't be valid): $ svn ls http://svn.collab.net/repos/svn $ svn ls https://svn.collab.net/repos/svn If the second one works and the first does not, you've found your problem. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ signature.asc Description: Digital signature
Bug#428194: CVE-2007-2448: security flaw in 'svn prop*' commands
[Florian Weimer] Subversion 1.4.4 has been released, containing some security fixes: * fixed: security flaw in 'svn prop*' commands [CVE-2007-2448] (r25095, -099, -104, -105, -10) I haven't yet figured out, what the exact problem is, and subversion.tigris.org appears to be down. Sorry. I'm pretty sure this is Debian bug #419348. The security implication is that a user who has SVN repository access but not shell access can screw up a repository beyond what is usually possible, making a big mess for someone to clean up, especially if you are using the old 'bdb' backend. I am not sure whether that counts as a security issue that should be fixed in sarge and etch. (After all, the user _is_ already trusted to commit to the repository.) But if so, we have patches for both. signature.asc Description: Digital signature
Bug#428202: subversion: FTBFS [i386]: Numerous test suite failures
[Daniel Schepler] Running all tests in basic_tests.py...FAILURE Running all tests in commit_tests.py...FAILURE Running all tests in update_tests.py...FAILURE Running all tests in switch_tests.py...FAILURE Thanks for the report. I can't reproduce it using pbuilder here. I guess I'll look more closely at exact version numbers of the packages your pbuilder is using. Is your chroot up-to-date with unstable? signature.asc Description: Digital signature
Bug#423653: apache2.2-common: mod_disk_cache fills /var after etch upgrade
[Ganesh Sittampalam] I am not sure if mod_disk_cache was enabled or not before the upgrade to etch (from sarge), but it was certainly not using disk space in the same way. In the sarge packages, /etc/apache2/mods-available/proxy.load includes four modules: mod_cache, mod_disk_cache, mod_proxy, mod_proxy_http. These have been separated in the etch packages, so the upgrade procedure checks to see whether you had mod_proxy enabled before, and if so, it enables all 4 modules. I do not know why the sarge version of mod_disk_cache did not fill up your disks, unless it is due to the CacheSize configuration setting, but the docs imply that that setting didn't actually work. (It has since been removed from the module.) mod_disk_cache appears to be experimental (http://httpd.apache.org/docs/2.0/mod/mod_disk_cache.html) It was, in Apache 2.0. Etch ships with Apache 2.2; if you read http://httpd.apache.org/docs/2.2/mod/mod_disk_cache.html you will see that it is no longer experimental. You'll also see that the developers chose not to implement the garbage collection within the module, but as an external utility htcacheclean which can either be run periodically from cron, or run as a daemon that wakes itself up on occasion. Arguably we should be starting this daemon automatically. We don't, currently, but unless you have a better idea, I think I will implement this in /etc/init.d/apache2, with options in /etc/default/apache2 to determine whether it is needed and how big the cache show be allowed to grow. Thanks, Peter signature.asc Description: Digital signature
Bug#419348: subversion: rare data loss / repository corruption bug
Package: subversion Version: 1.0.0-1 Severity: grave Justification: remote DoS (data corruption) A race condition was recently discovered in subversion whereby two commits overlapping in time could interact very badly, in certain circumstances. You can not only lose the effect of one of the commits, but with the BDB backend, you can possibly corrupt the whole repository in a fairly spectacular way. (It _does_ require commit access to a repository.) For details, see the upstream report at http://subversion.tigris.org/issues/show_bug.cgi?id=2751. This affects all releases at least as far back as 1.0.0, and will be fixed upstream in 1.4.4. Upstream has produced patches (including a regression test) for all release branches. As soon as I find the time to build and test on sarge and etch, I intend to upload fixed packages to sid, p-u and oldstable-p-u. signature.asc Description: Digital signature
Bug#416231: apache2: fails to start after upgrade from Sarge
reassign 416231 libapache2-mod-perl2 thanks [Frans Pop] Can you send the error.log from apache? Attached. I've also attached a new version of the upgrade log as I noticed I missed a few probably relevant lines at the end. [First of all, the cosmetic issue (You may still have some apache2 processes running) is something we can't really fix, because it is printed by the sarge init script (invoked from the sarge prerm, the sarge postrm and the etch preinst). I could try to make the etch init script more robust against throwing that error unnecessarily, but it _is_ mostly cosmetic and we _are_ near the etch release.] The real bug here is that, at the time apache2.2-common is configured, libapache2-mod-perl2 has not yet been configured. As a result, the conffile /etc/apache2/mods-available/perl.conf has has not yet been upgraded, and the old version of the conffile does not allow the new version of apache2 to start. As discussed with Steve L on IRC, the best solution is probably for libapache2-mod-perl2 to _stop_ shipping the (now empty) conffile /etc/apache2/mods-available/perl.conf, and edit out the offending line in its prerm, in case the user has a modified copy (or, if not, just removing the file and its symlink in mods-enabled). Peter signature.asc Description: Digital signature
Bug#415775: RC-ness (AddDefaultCharset)
[Robert Millan] I recommend in favour of considering this RC. AddDefaultCharset is an *evil* feature that is only intended to be used as a dirty hack for broken setups. I sought more opinions on this issue. People were split, and Steinar Gunderson brought up the good point that it doesn't make too much sense to specify a character encoding for a text file _within_ the same text file. Sure, it works for many encodings, but it doesn't work for UTF-16, and there are reasons one might want to use that. And some people were saying that meta http-equiv is actually the greater evil. So for apache2 2.2.3-4, I've left the AddDefaultCharset=UTF-8 enabled for new installs. I _did_ stop it from creating this file in an existing install, which was the point of this bug. Thanks for your information, Peter signature.asc Description: Digital signature
Bug#407171: proxy stops working after upgrading from sarge
[Frank Küster] Any news on this? A patch maybe or a tip how you intend to solve it, so that someone else can start testing, and NMU in case you won't find time? My work in progress can be seen at: svn diff -c303 svn://svn.debian.org/pkg-apache/branches/etch-apache2 I still have to do something about #416231 before uploading, and I'm also still trying to figure out exactly which modules need to be enabled for which upgrade scenarios. Peter signature.asc Description: Digital signature
Bug#403682: apache2.2: FTBFS: /bin/sh: mawk: command not found
[Aurelien Jarno] | /bin/sh: mawk: command not found The build log is for kfreebsd-amd64, but the same happens in a pbuilder on amd64. The build system is calling mawk, but either gawk or mawk can be installed on the system. It should either call awk, or the package should build-depends on mawk. Right, adding a build-dependency now. Thanks, Peter signature.asc Description: Digital signature
Bug#396631: Same problem with latest version of apache2/libapr1
[H. S. Teoh] i686. But it runs on a modified kernel that my colo provider uses for running virtual servers. I'm not sure if this makes a difference in the build. All I did was `apt-get source libapr1`, copy the new patch into debian/patches, and run `dpkg-buildpackage -r fakeroot`. It makes a small difference in the build because apr actually does try to detect available kernel features at build time. This is why we had this mess in the first place. But anyway, the package should have built just fine and I don't see how it could be related to apache config errors, so I'm not sure what to say about that. Thanks for the effort at testing this, Peter signature.asc Description: Digital signature
Bug#396631: Same problem with latest version of apache2/libapr1
[Marcos Torres Marado] Shouldn't this bug be marked as closed? While the existing fix works, it's not quite in its final form. We were waiting for someone to test my preferred patch. Now that he's done so, we'll use that and close the bug. Thanks, Peter signature.asc Description: Digital signature
Bug#403541: mysql driver missing - closing of #395959 was inappropriate
reassign 403541 apr-util forcemerge 395959 403541 thanks Do not open a new bug because an existing bug was closed. Instead, you can continue the argument in the old bug itself. Does that mean that the Debian Apache Team will not add the apr_dbd_mysql driver? Why? INSTALL.MySQL states: .. and there is no problem with a third party bundling the driver, provided you respect both the ASF and GPL licenses. That is the opinion of the Apache Software Foundation. However, the FSF disagrees - see http://www.gnu.org/licenses/license-list.html. What does of MySQL A.B. say? Their opinion matters because it's their copyright license which is arguably violated. signature.asc Description: Digital signature
Bug#402456: Serious Copyright violation in cdrkit
[Joerg Schilling] I did give an example: use what(1) on a binary compiled from the source before and after the change to see the difference. If you did look at the SVN, if you did have a look at the most recent changes. it would be easy to understand what happened. We have removed a lot of _duplicate_ copyright notices from source files, as a cleanup. We have not removed copyright information from source files; it is still there, just not repeated 2 or 3 times per file, as it was in some cases before. Copyright information is also printed when you run the command wodim -version. Yes, that means it is embedded in the binary, as you can verify with the strings and grep commands. I note that other commands such as 'mkisofs' do not print copyright notices with the -version option - that is probably worth fixing, as some users may look for this information. Users typically look for copyright notices in documentation and other materials that come with a package. (I note that the manpage we got from you includes a copyright notice, but not in the printed text.[*]) They might try running the program with -version or --version; this is the command-line equivalent to the GUI convention of an About box. And, since this is GPL software, users are of course free to get the source code and look there for copyright information. Which, I repeat, is all still present. [*] Believe it or not, this was already on my todo list. I recently _added_ copyright notices to another of your manpages, whilst cleaning it up, but I haven't yet found the time to do the same cleanup job for wodim.1. As for SCCS and what(1), free software users are not in the habit of checking SCCS strings for copyright information. I daresay a vast majority of free software users have never heard of SCCS strings or the what(1) command. I happen to know about it because I've been around Unix for a long time, but even I don't have it installed on my local Linux system. And speaking of my local Linux system, let me check for copyright notices in SCCS strings. The only user binaries aside from yours that embed copyright notices in that way are: iputils ping, netkit telnet, tcsh, aumix, vixie cron, gprof, lsof, util-linux pg, xdaliclock, and the ncftp suite. That is 11 packages (counting yours) out of over 1200 installed packages -- about 1%. By number of binaries it's on the order of 25 out of 2600 -- again, 1%. Hope this helps to clarify things, Peter signature.asc Description: Digital signature
Bug#396631: Same problem with latest version of apache2/libapr1
[H. S. Teoh] Hi, the old patch (currently in unstable) already works---my test was invalid because I upgraded apache2 but forgot to upgrade libapr1. Do you still want me to test the new patch? Ahh - great to hear! Yes, If it's convenient for you, please do test my new patch. It's a little bit cleaner than the old one, and it does fix one bug, unless I'm completely misreading it. Thanks, Peter signature.asc Description: Digital signature
Bug#396631: Same problem with latest version of apache2/libapr1
[H. S. Teoh]
Hi, the fix for #396631 to libapr1 does not work. Apache2 still
serves 0 bytes when running on a 2.4 kernel (on my virtual colo
host). Please look into this problem. Thanks!
My old patch is slightly buggy - can you try rebuilding apr 1.2.7-8.1
with this updated version of debian/patches/015_sendfile_lfs.dpatch?
Thanks,
Peter
#! /bin/sh /usr/share/dpatch/dpatch-run
## 015_sendfile_lfs.dpatch by [EMAIL PROTECTED] [EMAIL PROTECTED]
##
## DP: Fix up sendfile:
## DP: - Detect sendfile64() at runtime (not present on 2.4 kernels.)
## DP: - Ensure that we only send 2GB chunks on 64bit platforms thanks
## DP: to extreme linux kernel bustage.
@DPATCH@
Index: network_io/unix/sendrecv.c
--- a/network_io/unix/sendrecv.c
+++ b/network_io/unix/sendrecv.c
@@ -240,31 +240,77 @@
#if defined(__linux__) defined(HAVE_WRITEV)
+/* Helper function for apr_socket_sendfile.
+ * Takes care of sendfile vs. sendfile64 (must be detected at runtime),
+ * EINTR restarting, and other details. NOTE: does not necessarily
+ * update 'off', as callers don't need this.
+ */
+static
+ssize_t do_sendfile(int out, int in, apr_off_t *off, apr_size_t len)
+{
+#if !APR_HAS_LARGE_FILES
+ssize_t ret;
+do
+ ret = sendfile(out, in, off, len);
+while (ret == -1 errno == EINTR);
+return ret;
+#else
+
+#ifdef HAVE_SENDFILE64
+static int sendfile64_enosys; /* sendfile64() syscall not found */
+#endif
+off_t offtmp;
+ssize_t ret;
+
+/* Multiple reports have shown sendfile failing with EINVAL if
+ * passed a =2Gb count value on some 64-bit kernels. It won't
+ * noticably hurt performance to limit each call to 2Gb at a time,
+ * so avoid that issue here. (Round down to a common page size.) */
+if (sizeof(off_t) == 8 len INT_MAX)
+len = INT_MAX - 8191;
+
+/* The simple and common case: we don't cross the LFS barrier */
+if (sizeof(off_t) == 8 || (apr_int64_t)*off + len = INT_MAX) {
+offtmp = *off;
+do
+ret = sendfile(out, in, offtmp, len);
+while (ret == -1 errno == EINTR);
+return ret;
+}
+
+/* From here down we know it's a 32-bit runtime */
+#ifdef HAVE_SENDFILE64
+if (!sendfile64_enosys) {
+do
+ret = sendfile64(out, in, off, len);
+while (ret == -1 errno == EINTR);
+
+if (ret != -1 || errno != ENOSYS)
+return ret;
+
+sendfile64_enosys = 1;
+}
+#endif
+if (*off INT_MAX) {
+errno = EINVAL;
+return -1;
+}
+offtmp = *off;
+do
+ ret = sendfile(out, in, offtmp, len);
+while (ret == -1 errno == EINTR);
+return ret;
+#endif /* APR_HAS_LARGE_FILES */
+}
+
+
apr_status_t apr_socket_sendfile(apr_socket_t *sock, apr_file_t *file,
apr_hdtr_t *hdtr, apr_off_t *offset,
apr_size_t *len, apr_int32_t flags)
{
int rv, nbytes = 0, total_hdrbytes, i;
apr_status_t arv;
-
-#if APR_HAS_LARGE_FILES defined(HAVE_SENDFILE64)
apr_off_t off = *offset;
-#define sendfile sendfile64
-
-#elif APR_HAS_LARGE_FILES SIZEOF_OFF_T == 4
-/* 64-bit apr_off_t but no sendfile64(): fail if trying to send
- * past the 2Gb limit. */
-off_t off;
-
-if ((apr_int64_t)*offset + *len INT_MAX) {
-return EINVAL;
-}
-
-off = *offset;
-
-#else
-off_t off = *offset;
-#endif
if (!hdtr) {
hdtr = no_hdtr;
@@ -310,12 +356,10 @@
goto do_select;
}
-do {
-rv = sendfile(sock-socketdes,/* socket */
+rv = do_sendfile(sock-socketdes,/* socket */
file-filedes, /* open file descriptor of the file to be
sent */
off,/* where in the file to start */
*len); /* number of bytes to send */
-} while (rv == -1 errno == EINTR);
while ((rv == -1) (errno == EAGAIN || errno == EWOULDBLOCK)
(sock-timeout 0)) {
@@ -326,12 +370,10 @@
return arv;
}
else {
-do {
-rv = sendfile(sock-socketdes,/* socket */
+ rv = do_sendfile(sock-socketdes,/* socket */
file-filedes, /* open file descriptor of the
file to be sent */
off,/* where in the file to start */
*len);/* number of bytes to send */
-} while (rv == -1 errno == EINTR);
}
}
signature.asc
Description: Digital signature
Bug#397874: Uninstallable because of conflicting binary svn-clean which is also in kdesdk-scipts
[Michael Biebl] please coordinate with the kdesdk maintainers to make it possible that both packages are co-installable. Yeah - Fathi Boudra, a KDE maintainer, contacted me a few hours ago and we worked it out: kdesdk will drop their version of the script since the two scripts have exactly the same purpose and basic functionality. (The implementations are independent, though.) Meanwhile I've added a Conflicts header for the kdesdk-scripts packages that still do ship the script, on the understanding that future versions will not. Peter signature.asc Description: Digital signature
Bug#397874: Uninstallable because of conflicting binary svn-clean which is also in kdesdk-scipts
[Michael Biebl] subversion-tools tries to install /usr/bin/svn-clean which is also in package kdesdk-scripts. Thanks for noticing. I'll add a 'Conflicts: kdesdk-scripts' - this requires subversion-tools to be priority 'extra', but fortunately it already is. I think svn-clean is generally useful to have and it's exactly the sort of thing that belongs in a package like subversion-tools, so I don't want to just drop it. I do note that the 'svn-clean' in kdesdk-scripts is pretty much functionally identical, but messing with alternatives is way overkill. Thanks, Peter signature.asc Description: Digital signature
Bug#396435: root builder checking in subversion causes more harm
[Laszlo Boszormenyi] Your check for do-not-build-subversion-as-root makes it FTBFS on several archs: mips, mipsel and alpha. Please rethink this solution. The solution is sound. What is not sound is a detail about how the target dependencies work in debian/rules, which causes the dontberoot check to be done in too many places. Thanks for the heads-up, Peter signature.asc Description: Digital signature
Bug#397539: apache2-mpm-prefork: apache2 no longer works after upgrade (Invalid command 'DAVLockDB')
[Steve Langasek] Forcing reload of web server (apache2)...Syntax error on line 1 of /etc/apache2/mods-enabled/dav.conf: Invalid command 'DAVLockDB', perhaps misspelled or defined by a module not included in the server configuration failed! Alas, I can confirm this; a2enmod dav gives me this error with the dav.conf and dav.load shipped with apache2.2-common. I don't get it - no dav.conf is shipped with the apache2.2-common I've got. I also see no evidence that dav.conf has ever existed in the svn repository. Confused, Peter signature.asc Description: Digital signature
Bug#392189: 2.2.3-2 and 2.2.3-3 segfault
[Beat Birkhofer] Even after a clean install v 2.2.3-2 from testing and 2.2.3-3 from unstable segfault on PowerPC. [Wed Nov 01 08:22:15 2006] [notice] child pid 2990 exit signal Segmentation fault (11) Sounds like #392049. Can you confirm that rebuilding the apr source package with your 2.4 kernel (and then installing the libapr1 .deb file) fixes it? signature.asc Description: Digital signature
Bug#396435: subversion: FTBFS: test switch_tests.py fails
[Lucas Nussbaum] During a rebuild of all packages in etch, I discovered that your package failed to build on i386. Don't build subversion as root. Can I close this bug? signature.asc Description: Digital signature
Bug#393414: Source package contains non-free IETF RFC/I-D's
tags 393414 pending thanks subversion-1.3.2/notes/old/draft-korn-vcdiff-01.txt This file is obsolete cruft, and upstream has indicated an intention to remove it before shipping subversion 1.4.1, which is due in a couple of days. We hope to get 1.4.1 in before the freeze - it's pretty low-risk since upstream has a very conservative policy about what goes into their point releases. signature.asc Description: Digital signature
