forcemerge 391744 391833 391857
thanks
This bug (the cause is the same as #391744) has been fixed in
subversion 1.4.0-4, which I suppose will hit the archive tomorrow.
Thanks,
Peter
signature.asc
Description: Digital signature
[Ulf Harnhammar]
the svnshell program crashes with an ugly error message, if you run
it with a valid SVN repository as the parameter, and then issue a
setrev command with a non-integer parameter or no parameter at all.
Thanks, I'll take a look.
I know it is not _only_ python programmers who
severity 391744 grave
thanks
[EMAIL PROTECTED]
Poking around a bit, I think the culprit is in line 50 of the apr-abi
patch. The alternatives as they stand lead to an SVN_LT_SOVERSION of
0 if in apr.h APR_HAS_LARGE_FILES is true, which is the opposite of
what is really desired.
No,
[Pierre Habouzit]
it barfs on an external reference:
[madcoder hades] LC_ALL=C svn up
Fetching external item into 'kdebase/debian/cdbs'
[1]13303 segmentation fault LC_ALL=C svn up
As discussed on IRC, this is believed to be another symptom of #391744.
It should be solved in
# Believed to be fixed by this upstream patche:
# svn diff -c449724 http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x
reassign 387610 libapr0
thanks
[Daniel Kahn Gillmor]
Perhaps i'm not following the thread on bug #367610 properly, but it
sounds to me like this isn't actually a
Package: apache2-redirtoservname
Version: 0.1-1
Tags: patch
Please upload a version of apache2-redirtoservname that compiles and
works with apache 2.2, since that may go into sid and etch soon. The
main problem is the use of apr-1 instead of apr-0. You can test with
apache 2.2 in experimental.
Package: libapache-mod-auth-mysql
Version: 4.3.9-2.1
Tags: patch
Please update and test this package for use with Apache 2.2, which may
go into sid and etch soon. The following patch may help. It allows
the package to compile, but I did not test runtime functionality.
Apache 2.2 is currently
Package: libcrypto++5.2c2a
Version: 5.2.1c2a-3
Severity: serious
It appears that libcrypto++ is compiled with support for the IDEA block
cipher algorithm, which is patented in the US and in Europe until 2010
or thereabouts. Please see Bug #65368 for details.
It may be that RC2, RC5 and RC6
[Loïc Minier]
When upgrading a system with libsvn-javahl installed via aptitude from
subversion 1.3.2-6, subversion, subversion-tools, libsvn0 are upgraded
and libsvn-javahl is removed. libsvn-java is not selected.
I propose you keep libsvn-javahl as a dummy package depending on
[martin f krafft]
debdiff does not compare binary packages, it compares the source.
Have you tried it? It certainly does compare binary packages.
signature.asc
Description: Digital signature
[Sean Finney]
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///home/seanius/svn/cacti'
svn: Berkeley DB error for filesystem '/home/seanius/svn/db' while opening
environment:
svn: No such file or directory
svn: bdb: no absolute path for the current
[Andrew Schulman]
I don't actually know if this is a bug in libsvn-dev, but I'm guessing
that it is, for the following reason: At the moment I'm trying to
build anjuta 2.0.2. configure sees that libsvn-dev is present and so
wants to built the subversion plugin, but the build then fails
[Max Kellermann]
Test suite fails, here the part of the build log which I believe is
relevant
No, it's not relevant. That is the Java testsuite failing, which
happens in every Debian release on every architecture; we are ignoring
it until gcj proves it can make it pass some day.
The build
[Eugen Dedu]
I do not know if this helps, but in the log you have attached there
is a null pointer error...:
Indeed, but it's in the Java section. We've pretty much been ignoring
the Java testsuite ever since we added it to the build, because free
JVMs have _never_ been able to complete it
[Roman Zippel]
I looked at the failing self tests. The first one is a bug in the
created wrapper. The basic problem is that in
svn_delta.c:_wrap_svn_txdelta_apply_wrapper() the value of temp3 is
not modified by svn_txdelta_apply_wrapper(), so the return is
basically random.
Thanks for that,
[Erik Rose]
I still get this error dependably in Testing (and I just dist-
upgraded and restarted everything a few minutes ago). On the server,
I have subversion 1.3.2-5+b1 and libssl0.9.8b-3.
This bug report is about a client error related to libssl. We know the
two things that caused it
forcemerge 387396 387558
thanks
[Bin Tian]
When I run svnadmin help in shell, it told me that svnadmin: Bad
database version: compiled with 4.4.20, running against 4.3.29
Already reported, already fixed, we'll upload soon.
The workaround is easy: upgrade libapr0 to 2.0.55-4.2.
Thanks,
Peter
Package: subversion
Version: 1.4.0-1
Severity: serious
Tags: help
subversion 1.4.0 FTBFS on ia64 with the appended error. I don't
understand the code in question at all, either on the subversion side
or on the libdb4.4 side. I particularly don't understand why an error
of this nature would
[Rajko Albrecht]
- in subversion faq them tell that the apache/apr has reconfigured with
ac_cv_func_poll=no; export ac_cv_func_poll
Would nice to get a newer version of subversion/apr modules in
testing to get a working subversion-http-server.
The FAQ entry concerning this is about APR
[Karl Chen]
$ svnadmin --version
svnadmin: Bad database version: compiled with 4.4.20, running against 4.3.29
Thanks - will be fixed in the next version. (Coincidentally, this was
also reported to me in person a few hours ago.) Arguably it's a
libapr0 shlibs bug, but I'll work around it. As
If a bug was in a prerm script in unstable for 7 days, but never
appeared in stable or testing, should we include cruft in present and
future prerm versions to work around it?
[Henrique de Moraes Holschuh]
It depends only on the ammount of damage the bug causes.
No damage, it simply
CC: debian-devel, as I'm asking about packaging best practices.
[Agustin Martin]
* python-subversion.{prerm,postinst}: use pyversions, fix stupid
bug (Closes: #379278) in prerm. Tighten python build-dep to
ensure availability of pyversions.
Note that some upgrades might
[Roberto Pariset]
Package: subversion
Version: 1.3.2-6
Severity: important
Please pay attention to the version when reporting a bug.
/bin/sh /build/buildd/subversion-1.4.0/BUILD/libtool --tag=CC --silent
--mode=compile gcc -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE
Package: libneon26-dev
Version: 0.26.1-1
Could I suggest removing the .la file from libneon26-dev?
Yes, will do.
Please do. I was going to use neon26 for uploading svn 1.4.0 today,
but I can't because the .la file is still present. I'll revert to
neon25 until you fix this.
(If I upload
[Chris Snyder]
Import (result of svn add or svn import) fails consistently, but only
on some files.
So, both client and server are blaming _each other_ for breaking the
connection. (That is what Connection reset by peer means.) This
indicates that it is quite likely caused by something that
[Roman Zippel]
I attached a slighty different version of the previous patch, which
simply tries to open the port. It also correctly waits for a possible
exit of the server.
Added to Subversion 1.3.2-6. We shall see how it goes.
Thanks,
Peter
signature.asc
Description: Digital signature
[Michael Biebl]
You closed the bug on 20 Aug 2006 but the fixed version you mentioned
(1.4.0~rc4-2) is still not available in unstable (there is only a
version in experimental which is imho not sufficient to close this
bug).
It was what's known as a versioned close, which means that if you
[Vitalie Lazu]
We host a lot of repositories at www.assembla.com, sometimes we have
problems because in db/ directory of svn repository appears log files
owned by root, apache run as www-data user and it can not serve that
repository anymore.
If apache does not have permission to create
tags 385288 upstream wontfix
thanks
[Vitalie Lazu]
Only nightly backup, but it can not break repositories
That's the culprit, then. With the bdb backend, _no_ operation is
truly read-only - even 'svnlook youngest' writes to log files, and can
create new log files. This is an implementation
[Jens Seidel]
- to the mouse data in configurations where it would otherwise only be
available
+ to the mouse data in configurations where it would otherwise only be
available
to only X or GPM.
.
Enter 'none' to turn repeating off.
which only removes a space at the line end to
[Jens Seidel]
oops() invoked from gpn.c(454)
Repeating into autops2 protocol not yet implemented :-(: File exists
Please do not allow autops2 if it's not supported.
ps2, imps2, exps2 are also unsupported, msc works.
Allow it where? In the debconf prompts? I'll see what I can do. Note
[Richard Atterer]
However, if I only want to list the contents of /dir inside the
repository with svn list file:///repo/dir, I run into trouble if
/dir no longer exists ***in the most recent revision***. Specifying
an earlier revision using the -r switch does not change this. Here is
a
[Kai Hendry]
sam$ bplay dreamhost-angry2.wav
bplay: input is not a PCM WAV file
sam$ file dreamhost-angry2.wav
dreamhost-angry2.wav: RIFF (little-endian) data, WAVE audio, IMA ADPCM, mono
8000 Hz
Indeed ... there are a lot of formats of wav files, bplay doesn't
handle a very big range of
[Kai Hendry]
How did you end up playing back the file btw?
'play' from the sox package.
signature.asc
Description: Digital signature
[Jay Berkenbilt]
When debian-changelog-mode is updated, we need to make sure that it
properly recognizes the new upstream version as well. I haven't
looked at the code to generate a patch, but I might if I have time.
This seems to be close. It's only lightly tested, mind.
---
[martin f krafft]
It is my understanding that HTTP GET is only a convenience method to
look at subversion files, and subversion actually uses DAV to obtain
data over HTTP, if that is the protocol.
*nod*
it would be nice to have keyword expansion when files are obtained
via GET.
I agree,
[Amaya Rodrigo Sastre]
This program also shows soundwaves which makes it easier for
subtitles synchronisation that most other subtitle editors like
ksubtile or gaupol.
This program also shows sound waves, which makes it easier to
synchronise
[Mario Iseli]
is there already a fix available?
What version of openssh-client do you have installed on your client
machine? This was supposed to be fixed in version 1:4.2p1-6.
Note also what I said earlier - this is a harmless warning, it looks
annoying but doesn't actually mean anything.
[Wouter Verhelst]
Isn't there a way for svnserve to signal somehow that the port is
opened? Like, say, create a PID file once the daemon is listening,
and not before?
Or fork to background after the daemon is listening, but that can be
problematic and does not cover all cases.
signature.asc
[Kurt Roeckx]
/var/lib/dpkg/info/python-subversion.prerm: line 8: cd:
/usr/lib/python2.5/site-packages: No such file or directory
Sorry about that, stupid shell script bug, clearly I wasn't paying any
attention at all (I intended for the logic in the prerm to be the same
as in the postinst).
# 'important' is a compromise. If you don't like it, appeal to the TC.
# Have a nice day.
severity important
tags 376103 upstream
forwarded 376103 [EMAIL PROTECTED]
thanks
[Adam Borowski]
You cannot assume that an important attribute like the timestamp
won't ever change outside of your
[EMAIL PROTECTED]
A full build log can be found at:
http://buildd.debian.org/build.php?arch=m68kpkg=subversionver=1.3.2-4
I still have the full build tree, and suspect that the issue can be
fixed by someone more familiar with the build than myself. Can you
help me out?
Yes, I know the
[Tim Phipps]
I've got /dev/input/mice as my GPM mouse device (I think it was the
default) and I'm using udev. If a mouse isn't plugged in udev does
not load the mousedev driver at boot (which is probably correct)
Right, that's probably reasonable on udev's part. Although, can I
assume this
[Steve Langasek]
This is actually a bug of the subversion package which provides
libsvn-core-perl. It should have versioned Depends or Conflicts
between subversion and libsvn-core-perl to avoid installing
incompatible versions of those packages.
Eh, how do you figure? The current
[François Pinard]
I quite object to the principle that Subversion limitations may be
turned into Recode bugs, and even go as far as being considered
grave.
The severity 'grave' may or may not be correct - when redirecting the
bug report to 'recode', I simply left it at the severity it was
# Where in the world did 378266 come from? It seems to have been
# cloned from 377467 for no reason at all, then merged with 376565 for
# no reason at all.
#
# People seem to be emailing 378266 as though it were 376565, but
# there's no history in the bug to indicate why they are doing this.
#
[Resending - I originally sent this to the wrong bug number]
[François Pinard]
I quite object to the principle that Subversion limitations may be
turned into Recode bugs, and even go as far as being considered
grave.
The severity 'grave' may or may not be correct - when redirecting the
Forwarding to #376124 (this was sent to #376103)
[Bernhard R. Link]
This does not only harm subversion, but everything else that looks for
timestamps, be it making backups with tar, or using make. If you think
it is a good idea to break semantics of the timestamps, tag it wontfix,
but please
We received this bug report on subversion 1.3.2 in the Debian bug
tracking system. Can anybody shed some light on this? I haven't yet
tried to reproduce it with trunk or 1.4.
Thanks,
Peter
--
From: Daniel Jacobowitz [EMAIL
Package: libaprutil1-dev
Version: 1.2.7-2
Severity: minor
Tags: patch
$ pkg-config --libs apr-util-1
-laprutil-1 -lldap -llber -ldb-4.3 -lpq -lsqlite3 -lexpat -lapr-1
$ apu-1-config --libs
-lldap -llber -ldb-4.3 -lpq -lsqlite3 -lexpat
These really should not list recursive
[Thijs Kinkhorst]
While I can understand that it's good if the package names are all
according to some specified scheme, I don't think that the wrong name
makes the package in such a broken state that we should prevent it
from being released.
I've renamed the package to libsvn-java for the
[EMAIL PROTECTED]
Log:
For svn-javahl, add dependency alternative on java2-runtime.
This rests on the dubious assumption that svn-javahl.jar does not use
any of the methods from Java 1.1 that have been deprecated in Java 2,
to quote Debian Java Policy section 2.1. Of course, we can change
[Robson Roberto Souza Peixoto]
Why libsvn-javahl don't need the java2-runtime?
The sun-java5 don't solve the dependence of javahl
It's a bit hard to understand your report, but I assume what you mean
is that sun-java5-jre does not provide 'java1-runtime' because it
doesn't support some
[Charles Fry]
According to the current java policy, section 2.4:
Java libraries packages must be named libXXX[version]-java (without
the brackets), where the version part is optional and should only
contain the necessary part.
[...]
In other words, if distributing the jar
[Vincent Lefevre]
mv *must be* supported. It's a Unix command and the user is allowed to
use it.
That's a poor argument - the user is allowed to use 'rm -fr .svn' and
subversion can't recover from that state. It's equally plausible, in
fact, that a user who doesn't know how to use svn will do
[Vincent Lefevre]
The Subversion book says concerning changes in the working copy:
To make file changes, use your text editor, word processor, graphics
program, or whatever tool you would normally use.
And mv is one of these tools.
That is a point.
And again, this problem is not
Package: debian-policy
Version: 3.7.2.1
Severity: minor
Tags: patch
One change from 3.7.2.0 - 3.7.2.1 was incorrect - by which I mean, the
old and new text are both incorrect. See patch.
--- policy.sgml.old 2006-06-30 04:22:43.0 -0500
+++ policy.sgml 2006-06-30 04:22:50.0
clone 376103 -1
retitle -1 recode: bad default: hides file modifications by restoring mtimes
reassign -1 recode
severity 376103 normal
thanks
[Vincent Lefevre]
The recode utility does not update the timestamp (I assume this is
a feature).
Yeah, well ... I don't know whose brilliant idea it
severity 376103 normal
thanks
[Vincent Lefevre]
I'm copying this bug to recode. In my opinion, 'svn' and 'make'
should be entitled to assume that the user has been honest about
modifications of her own files.
I agree about make, but concerning svn, one can't rely on that.
I'm still
unblock 373387 by 373628
thanks
(This block was a false positive. While we use cdbs a little, we don't
actually use it for anything python-related.)
First, it's not clear to me what advantages anyone would get from
fixing the subversion packaging to comply with current python policy.
I do not
Package: debian-policy
Version: 3.7.2.0
From upgrading-checklist:
* All fields, apart from the Uploaders field, in the control file are
supposed to be a single logical line, which may be spread over
multiple physical lines (newline followed by space is elided).
Policy 5.1:
Some
Troy Heber is debugging this on alpha and he reports that rebuilding
ruby1.8 with gcc 4.1 fixes it. Also, downgrading to ruby1.8 1.8.4-1
fixed it, which I attribute to the fact that this too used a
different version of gcc for the alpha build. (Nobody has checked
whether any of this is
Package: ruby1.8
Version: 1.8.4-2
On alpha and arm, the testsuite for libsvn-ruby1.8 fails. See for
example:
http://buildd.debian.org/fetch.php?pkg=subversionver=1.3.2-1arch=armstamp=1149299703file=logas=raw
Troy Heber is debugging this on alpha and he reports that rebuilding
ruby1.8 with
[Bastian Blank]
There was an error while trying to autobuild your package:
Yes, I noticed. I've wanted to move away from kaffe for a long time.
Several months ago both Adam Conrad and Adam Heath offered to help
migrate subversion to something that actually works on most platforms,
such as gcj,
[martin f krafft]
Could we change the line
sensible-editor ../${SOURCE}-${VERSION_NO_EPOCH}-nmu.diff
to
${EDITOR:-sensible-editor} ../${SOURCE}-${VERSION_NO_EPOCH}-nmu.diff
Why? That's exactly what sensible-editor does already.
(Except that it also honors $VISUAL.)
signature.asc
[Steve Kowalik]
I feel this check is useful is someone is using DH_COMPAT 5 and is
only Build-Depending on debhelper ( 3).
That's useful, yes. I am only asking for the check to be reduced in
scope. My situation is that I'm using DH_COMPAT 4 and I don't feel
that I should have to version the
Package: linda
Version: 0.3.22
E: foo; DH_COMPAT is greater than the major version of debhelper depended on.
This is compat level 4, meaning woody or newer. If someone tries to
build my package on a system older than woody, believe me, debhelper
will be the _least_ of their problems.
I
[Roland Stigge]
I've got a BDB 4.3 repository with a strings file of size 4230414336.
Running svn ci, svnadmin verify, etc., the process stalls without
an error (waiting for me to kill the process).
Yeah, that's pretty odd. Are you reasonably certain it is related to
the file size? I know
[I wrote]
That's not subversion crashing, that's subversion killing ssh.
Upgrade openssh-client to version 1:4.2p1-6 or newer.
I should have mentioned, as well, that the situation is harmless even
if you don't upgrade openssh-client.
subversion has always killed ssh when it is done using the
[Vincent Lefevre]
This is a very bad idea, as the encoding of the files from the
repository is common for every user, thus does not necessarily
correspond to the locales.
subversion has to guess, one way or another. Guessing that you want
your files to look like UTF-8 but your filenames to
severity 365987 wishlist
thanks
[Thomas Schlegel]
If I create a Repository as root, I can't use it as user.
If I create a Repository as normal user in my $HOME, other users
can't use it.
That's simply a matter of Unix permissions management. It's not
specific to Subversion and it's not a
Package: vorbis-tools
Version: 1.1.1-5
Severity: wishlist
Tags: patch
I often want to edit tags of ogg vorbis files using an editor, so I
wrote a new option 'vorbiscomment -e' (similar to 'crontab -e').
I was a bit lazy, using the current directory for the temp file rather
than getenv(TMPDIR),
[Davor Ocelic]
I suppose the $(date +'%d %b %Y') was meant to have the
effect of backticks, but $( is expanded by Makefile, resulting
in the build called with --release=.
Right, obviously I meant $$(date +'%d %b %Y').
At that point, the build stops with:
Option release requires an
[Jean-Luc Coulon (f5ibh)]
This doesnt work because $(DEB_HOST_ARCH) is empty.
The package build fine with dpkg-buildpackage -rfakeroot
I believe the recommended debian/rules business is:
DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
This sets DEB_HOST_ARCH only if it is not
Thanks for your patience, everybody, while we've been busy doing other
things than fixing this very long-standing bug, which was reported four
times and relegated for a long time to a corner labeled hmmm, what
*should* we do with this one, anyway?
I just wrote and documented a little
tags 363983 upstream wontfix
thanks
[Przemyslaw Grzywacz]
There is currently a major bug with locales on debian, which makes
them unusable (what you can see in System Information) and it makes
svn completly useless too. svn dies immediately, it doesn't even show
the help screen.
Subversion
It may be an openssh bug that it refuses to operate when nobody is
listening on the control socket, but the reason the socket wasn't
cleaned up is indeed subversion's fault. svn kills ssh with SIGKILL
for reasons I won't get into right now, except to say that I'm about to
patch it not to do
[Jacobo Tarrio]
Project-Id-Version: gpm\n
Language-Team: Galician [EMAIL PROTECTED]\n
Thanks - added to the next upload, which may not be for a little while,
as we have other things going on. I hadn't realised until now how
similar Galician is to Italian - I could understand your translation
[Max Bowsher]
Perhaps subversion should
Depends: libsvn0 (= ${Source-Version}) ?
This would avoid potential for confusion.
Hmmm. On the one hand, in Debian we try to keep our dependencies only
as tight as they need to be - to support partial upgrades as best we
can, and maintain as much
[Daniel Schepler]
The patch didn't help. After some more investigation, I found that
installing official i386 ruby1.8 packages fixed the test failure, and
in fact if I rebuild ruby1.8 locally adding -fno-strict-aliasing to
the CFLAGS, the rebuilt packages also fix the test failure.
Thank
[Petr Salinger]
the current version of subversion has unsatisfied Build-Depends under
kfreebsd-amd64 port.
Your package belong between packages which already have specific
Build-Depends for kfreebsd-i386, the same are also needed for
kfreebsd-amd64.
I suppose this is a scripted bug
[Christian Ohm]
Now what will someone do who doesn't know how to investigate a failed
./configure run? In my opinion this fits the description of
'important' (a bug which has a major effect on the usability of a
package, without rendering it completely unusable to everyone),
depending on the
[Daniel Schepler]
1) Error:
test_apply(SvnDeltaTest):
ArgumentError: NULL pointer given
Since you can reproduce this bug and I can't, could you please test a
patch? Simply replace the file debian/patches/swig-1.3.28.patch with
the attached file and rebuild, and let us know whether it makes
[Arthur de Jong]
svn2cl has been included into the subversion repository [1] and will
probably be included with some future release of subversion.
Thanks for the reminder. I did notice when it was merged upstream
recently, but forgot to note it as something to make sure Debian ships.
I
[Daniel Schepler]
Reading the report again, it seemed to me that it could be read as a
chastisement; I apologize for this.
I didn't worry about the tone. I knew we would be getting this bug
report sooner or later, since the powerpc FTBFS keeps refusing to go
away.
I looked at the buildd logs
tags 359679 confirmed
thankee
[Julian Gilbey]
burnside:~/debian/tex/tetex-bin $ perl -MSVN::Client -e \
'sub print_names { print $_[0]\n; } $ctx=new SVN::Client;
$ctx-status(, BASE, \print_names, 1, 1, 0, 1);' | head -5
.pc
.pc/.version
configure
INSTALL.generic
I reproduced your
[Daniel Schepler]
Loaded suite test
Started
.E.
Finished in 303.083982 seconds.
1) Error:
test_apply(SvnDeltaTest):
ArgumentError: NULL pointer given
Right, I'm not sure
[Jari Aalto]
I believe it is more common for regular use to define:
kdeprint | lpr= lpr | kdeprint
konqueror | www-browser = www-browser | konqueror
This would be least surprise, than having to install lot of KDE related stuff
to a system that neither use KDE or
[Bill Allombert]
libapache2-svn modules have a rpath pointing to /tmp:
Ah, quite so. I ported the nuke-the-rpaths patch to 1.2.3 but
incompletely, intending to finish it when I got a chance (the part with
the apache modules was very confusing to me). Extra rpaths are usually
quite harmless,
[Mike Charlton]
[EMAIL PROTECTED]:~$ svn --version
svn, version 1.2.3 (r15833)
compiled Dec 4 2005, 03:38:36
You're seeing the version of libsvn0 there. In my opinion this isn't a
bug: for most purposes (including BDB backend version), libsvn0 is what
really matters. Try downgrading that
Could somebody kick a buildd to binNMU subversion 1.3.0-4 on i386 only?
A well-known bug where we don't cleanse quite all the rpaths suddenly
became a security issue because the last version uploaded on i386 was
built in /tmp, so the two apache modules have built-in rpaths that
would let an
On Tue, Mar 21, 2006 at 07:08:02AM +0100, Christian Perrier wrote:
Well, I have one very little argument against doing so: why do it
for Dzongkha and why not do it for, say, French...:-)
[Lionel Elie Mamane]
Because French is the adjective in English (the language the
package description
[Marc 'HE' Brockschmidt]
Package: libsvn-core-perl
Version: 1.2.3dfsg1-3
First question, have you tried 1.3.0-3? I'm not saying it's
necessarily fixed, but I'd appreciate if you could try it.
I guess it tries to use . for some tempfile when doing the
merge. Which is, err, not a good idea.
[Christoph Berg]
currently the subversion-tools description is quite useless. I know
what subversion is, and I suspect that a -tools package would contain
tools.
Yes, the subversion-tools package is *also* quite useless. (:
I've been intending for a long time to look at the various other
[Chip Salzenberg]
TypeError in method 'svn_ra_reporter2_invoke_set_path', argument 6 of type
'char const *'
This appears to me to be an error in the SWIG glue, but I haven't
investigated yet. I'm hoping the bug and its solution are obvious to
you, the esteemed maintainer. :-)
[Christof Douma]
Without this touch svn does not record any changes, which should not
happen. A quick fix would be to touch all WC files which have
svn:keywords changed/removed.
This fix, effectively, seems to be in 1.3.0, which is now in unstable.
'svn status' / 'svn diff' notice that the
Christof Douma points out that svn pdel svn:keywords does not
un-expand a file's keywords in the working copy. He thinks it should,
and I tend to agree. Present behavior leaves a working copy diff due
to keyword expansion, even if the file is otherwise unchanged.
(He also reports a bug in
close 356499 1.3.0-2
merge 356499 355356
thanks
[alex]
The following packages have unmet dependencies:
subversion: Depends: libneon24 (= 0.24.7.dfsg) but it is not installable
The fixed package has been sitting in the NEW queue
(http://ftp-master.debian.org/new.html) for 2 and a half weeks.
[Rafal Jan Czlonka]
I've just read the description of bug #324599, but the one I've found
is quite opposite - checkbashisms fails to recognise functions where
the word function is omitted, like first() or second ().
What's the problem? foo() { bar; } is not a bashism. All POSIX
shells
unmerge 355716
severity 355716 grave
merge 355716 355356
thanks
[Michael Biebl]
The current subversion packages are linked against libneon24.
Yes, this is #355356. We fixed it the day after libneon25 hit the
archive, but our fixed package has been stuck in the NEW queue
501 - 600 of 793 matches
Mail list logo
