Bug#636550: avoid sed -r in git-fake-bare
Package: mr Version: 1.04 Tags: patch git-fake-bare uses sed's -r option, which isn't supported on OSX. Attached patch avoids the need for it. git-fake-bare-patch Description: Binary data
Bug#479033: Fix in time for lenny?
On Fri, Jun 20, 2008 at 09:12:03AM +0200, Pier Luigi Pau wrote: Greetings, please, could this be fixed in time for lenny? It is a python2.5 regression, after all. I think it is unfortunate that cksfv was removed from Debian (it was removed because it depended on debmake); to the best of my understanding, that left Debian without a binary application to check files against SFV. While SFV is an old and deprecated way to check for file integrity, it is still being used out there, and it would be nice if we could at least have a fixed cfv in lenny. Best regards, Pier Luigi Pau I just released cfv 1.18.2, which contains the fix (among others.) I haven't kept up with the debian release schedules, so Stefan will have to say whether it can make it in. -- Matthew Mueller [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479033: Solution...
On Sun, May 25, 2008 at 05:25:04PM +0200, Stefan Alfredsson wrote:
Stefan Alfredsson wrote:
return struct.pack('i',self.value)
This assumes that self.value should be signed. A problem might arise if it
should really be unsigned.
self.value is assigned from _crc32, which calls zlib.crc32.
According to pydoc, The returned checksum is an integer.
According to intuition, a checksum should not be negative (?).
I'll have to look closer at this.
Interesting indeed. According to http://bugs.python.org/issue1202,
The functions zlib.crc32() and zlib.adler32() return a signed value
in the range(-2147483648, 2147483648) on 32-bit platforms, but an
unsigned value in the range(0, 4294967296) on 64-bit platforms. This
means that half the possible answers are numerically different on these
two kinds of platforms.
This was later fixed, such that
3.0 always returns unsigned.
2.6 always returns signed, 2**31...2**31-1 come back as negative integers.
and they note in http://svn.python.org/view?rev=61459view=rev
zlib.crc32 and zlib.adler32 now return an unsigned value as any sane person
would expect. Fixes issues1202.
So it seems that the long-term solution is to have an unsigned value, but
in current versions it might be either signed or unsigned, depending on 32
or 64 bit archs. Argh!
One solution suggested was to use
x = zlib.adler32(mystr) 0xL
which would force it to be unsigned, and thus work with capital I.
Matthew/Upstream, do you have an opionion in this matter?
Regards,
Stefan
Hey, sorry for not replying earlier. 0x is the solution I
went with. Actually this has been in svn for almost a year but I never
did a release. arg. Must make some time to do that soon...
--
Matthew Mueller
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466591: Cannot verify .md5 and .cfv files containing chars 127
On Tue, Feb 19, 2008 at 09:31:41PM +0100, Alain Kalker wrote: When verifying .md5 or .cfv files which contain filenames containing chars with values 127 (in ISO-8859), cfv reports the corresponding files as missing. I don't know if this problem is related to bug #406761, but that bug suggests a specific problem with the encoding of UTF-8 characters in .torrent files. If these problems are related, please feel free to merge the bugs. It's similar to that bug, but not the same cause. In this case, cfv (1.x) has no understanding of encodings for text checksum files, and since the files are encoded in iso-8859-? but your system is probably using utf-8 for filenames, the bytes just aren't going to match up. For the text-based formats you can work around this pretty easily by manually converting the files: iconv -f iso-8859-1 -t utf-8 foo.md5 foo.utf8.md5 Therefore, I say that this isn't really a bug at all. cfv 1.x certainly can verify files with chars 127 as long as the encoding matches the one used by your system. If you want, you can consider it as a feature request for built-in encoding handling. Actually, the cfv 2.x devel code already has encoding knowledge so you could just do: cfv --encoding=iso-8859-1 -f foo.md5 However I'm (slowly) doing some major refactoring on it and it's not ready for release yet :( -- Matthew Mueller [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406761: more info
On Mon, May 21, 2007 at 11:50:32AM -0400, [EMAIL PROTECTED] wrote: I'm getting the same error. Bittornado has had the same problem for a while now. The cause is in how Unicode is handled in the .torrent file. When a torrent has files in it with Unicode characters, two versions of the file name are stored. One in utf8 format, the other stripped to ASCII. Some broken clients **cough** BitComet **cough** put garbage characters in the ASCII string when they generate a torrent with Unicode characters. When cfv hits these characters, it barfs. Actually there are two different standards for how non-ascii text should be handled in a torrent file. One is to include an 'encoding' field in the torrent metainfo which specifies what encoding is used for all the strings. Cfv supports this. The other is as you mention, where all the filenames contain two versions, one that's useless (in unknown encoding, or maybe just garbage), and the .utf-8 version. Cfv doesn't currently support this, so it just tries to read the normal filename and since it doesn't know the charset it defaults to the safe value, ascii. I'll add handling this type of torrent to my todo list. (Actually there is the third method which lamer/older clients use: just include the raw strings in whatever random encoding and not specify anything. Not much can be done about that, though, other than letting the user specify an encoding to use. (The cfv 2.x devel code does allow that.)) -- Matthew Mueller [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307976: nget: an option to restore broken/partial files to their original names would be nice
As you said, you can get par2 to use them already. (Specify them as extra command line args, in case anyone else wonders.) As far as the feature itself, I'm opposed to it, since the main idea behind giving them the weird name is to avoid problems with either nget or the user thinking they have a correct copy. They can't just be renamed at shutdown, since repeated runs of nget on the same directory would then see them as having the correct name. Likewise for the user looking at the directory some time later where they may have forgotten to run a repair yet.. I am however considering including a cleanup script that would automatically run par2repair and then remove any leftovers. (Perhaps even nget could call it automatically on shutdown if it determined it was needed and that there is enough data to do recovery.) Of course, such a script would have to be very careful to not delete any unrelated files that happen to be laying around.. (I have a prototype that I've been using, but I'd like to maybe make it a bit more automagic before including it...) -- Matthew Mueller [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301442: xxdiff-subversion script has bad path to xxdiff binary hard coded
Package: xxdiff
Version: 1:3.1-1
Severity: normal
Tags: patch
$ svn diff --diff-cmd xxdiff-subversion
[...]
Error: unexpected answer from xxdiff: sh: /home/blais/p/xxdiff/bin/xxdiff: No
such file or directory
Patch attached.
-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.11.1
Locale: LANG=en_US.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Versions of packages xxdiff depends on:
ii libc6 2.3.2.ds1-20.0.0.1.pure64 GNU C Library: Shared libraries an
ii libgcc11:3.4.3-12GCC support library
ii libqt3c102-mt 3:3.3.3-7 Qt GUI Library (Threaded runtime v
ii libstdc++5 1:3.3.5-12The GNU Standard C++ Library v3
ii libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li
ii libxext6 4.3.0.dfsg.1-10 X Window System miscellaneous exte
ii xlibs 4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu
-- no debconf information
--- /usr/bin/xxdiff-subversion 2005-03-24 20:45:22.0 -0700
+++ xxdiff-subversion 2005-03-25 15:09:31.0 -0700
@@ -88,7 +88,7 @@
tmpf = NamedTemporaryFile('rw', prefix=tmppfx)
# run command
-xxdiff_path = '/home/blais/p/xxdiff/bin/xxdiff'
+xxdiff_path = 'xxdiff'
cmd = [xxdiff_path, '--decision']
if opts.merge:
cmd.append('--merge')
Bug#301160: pyzor check processes hanging around
Package: pyzor Version: 1:0.4.0+cvs20030201-1 Severity: normal Lately I've noticed a bunch of pyzor processes hanging around. I use spamassassin (with spamc, from fetchmail+procmail) to evaluate my emails, which calls pyzor automatically. charon 21:11:52 ~$ ps aux | grep pyzor donut 4314 0.0 0.4 34276 5132 pts/1S+ 11:22 0:00 /usr/bin/python /usr/bin/pyzor check donut 4601 0.0 0.5 35320 5252 pts/1S+ 11:22 0:00 /usr/bin/python /usr/bin/pyzor check donut11905 0.0 0.5 34276 5204 pts/1S+ 13:24 0:00 /usr/bin/python /usr/bin/pyzor check donut17759 0.0 0.5 34276 5204 pts/1S+ 15:26 0:00 /usr/bin/python /usr/bin/pyzor check donut20254 0.0 0.5 35320 5152 pts/1S+ 16:12 0:00 /usr/bin/python /usr/bin/pyzor check donut24486 0.0 0.5 34276 5200 pts/1S+ 17:33 0:00 /usr/bin/python /usr/bin/pyzor check donut 5445 0.0 0.5 34276 5200 pts/1S+ 11:23 0:00 /usr/bin/python /usr/bin/pyzor check charon 21:07:39 ~$ gdb python 5445 GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as x86_64-linux...(no debugging symbols found) Using host libthread_db library /usr/lib/debug/libthread_db.so.1. Attaching to program: /usr/bin/python, process 5445 Reading symbols from /lib/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/libpthread-0.60.so...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] [New Thread 46912504471696 (LWP 5445)] (no debugging symbols found)...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.3.2.so...(no debugging symbols found)...done. (no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libutil.so.1...Reading symbols from /usr/lib/debug/lib/libutil-2.3.2.so...(no debugging symbols found)...done. (no debugging symbols found)...done. Loaded symbols for /lib/libutil.so.1 Reading symbols from /lib/libm.so.6...Reading symbols from /usr/lib/debug/lib/libm-2.3.2.so... (no debugging symbols found)...done. (no debugging symbols found)...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.3.2.so...(no debugging symbols found)...done. (no debugging symbols found)...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.3.2.so...(no debugging symbols found)...done. (no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /usr/lib/python2.3/site-packages/_iconv_codec.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.3/site-packages/_iconv_codec.so Reading symbols from /usr/lib/gconv/ISO8859-1.so...Reading symbols from /usr/lib/debug/usr/lib/gconv/ISO8859-1.so...(no debugging symbols found)...done. (no debugging symbols found)...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Reading symbols from /usr/lib/python2.3/lib-dynload/strop.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.3/lib-dynload/strop.so Reading symbols from /usr/lib/python2.3/lib-dynload/sha.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.3/lib-dynload/sha.so Reading symbols from /usr/lib/python2.3/lib-dynload/math.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.3/lib-dynload/math.so Reading symbols from /usr/lib/python2.3/lib-dynload/_random.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.3/lib-dynload/_random.so Reading symbols from /usr/lib/python2.3/lib-dynload/time.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.3/lib-dynload/time.so Reading symbols from /usr/lib/python2.3/lib-dynload/fcntl.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.3/lib-dynload/fcntl.so Reading symbols from /usr/lib/python2.3/lib-dynload/cStringIO.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.3/lib-dynload/cStringIO.so Reading symbols from /usr/lib/python2.3/lib-dynload/_socket.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.3/lib-dynload/_socket.so Reading symbols from /usr/lib/python2.3/lib-dynload/_ssl.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.3/lib-dynload/_ssl.so Reading symbols from /usr/lib/libssl.so.0.9.7...done. Loaded symbols for /usr/lib/libssl.so.0.9.7 Reading symbols from /usr/lib/libcrypto.so.0.9.7...done. Loaded symbols for /usr/lib/libcrypto.so.0.9.7
Bug#298673: mutt: limit ~b does not handle base64 encoded email
Package: mutt Version: 1.5.6-20040907+3 Severity: normal apt-listchanges sends it's changelog emails with: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 mutt displays these emails fine, but using limits doesn't work on them. Ex: l~bdpkg shows nothing, even though I can open up several emails in my inbox in mutt and see that they do indeed contain the text dpkg. -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.11.1 Locale: LANG=en_US.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages mutt depends on: ii exim4 4.50-4metapackage to ease exim MTA (v4) ii exim4-daemon-l 4.50-4lightweight exim MTA (v4) daemon ii libc6 2.3.2.ds1-20.0.0.1.pure64 GNU C Library: Shared libraries an ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [ ii libgnutls111.0.16-13 GNU TLS library - runtime library ii libidn11 0.5.2-3 GNU libidn library, implementation ii libncursesw5 5.4-4 Shared libraries for terminal hand ii libsasl2 2.1.19-1.5Authentication abstraction library -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290333: libboost-thread-dev: bug happened to me too, but can't reproduce it
Package: libboost-thread-dev Version: 1.32.0-2 Followup-For: Bug #290333 I had the same problem, with a few hundred various header files in /usr/include/boost/ missing. (Just noticed it now, but I upgraded to 1.32.0-2 on Jan 12th.) I tried reinstalling all my old 1.31.0 packages with: dpkg -i /var/cache/apt-proxy/debian-amd64/pool/unstable/main/amd64/b/boost/libboost*_1.31.0-9_amd64.deb And tested, all headers were there. Then I reinstalled 1.32.0 with: dpkg -i /var/cache/apt-proxy/debian-amd64/pool/unstable/main/amd64/b/boost/libboost*_1.32.0-2_amd64.deb And tested again, all headers were there now. Looking at my aptitude logs, at the time I had dpkg 1.10.25 installed, and upgraded to 1.10.26 in the same run of aptitude as the boost upgrade. Right now I have dpkg 1.10.27. I tried the procedure again with dpkg downgraded to 1.10.26 and 1.10.25 but couldn't reproduce the bug then either. -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.11.1 Locale: LANG=en_US.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages libboost-thread-dev depends on: ii libboost-dev 1.32.0-2 Boost.org libraries development fi ii libboost-thread1.32.0 1.32.0-2 portable C++ multi-threading -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298359: uim-xim: text does not render in xterm with preeditType: OverTheSpot
Package: uim-xim Version: 1:0.4.6beta2-3 Severity: normal With OverTheSpot preeditType, text does not appear in the xterm until you commit it. An underline is drawn for the number of characters you've typed, but nothing else. -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.11.1 Locale: LANG=en_US.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages uim-xim depends on: ii libatk1.0-01.8.0-4 The ATK accessibility toolkit ii libc6 2.3.2.ds1-20.0.0.1.pure64 GNU C Library: Shared libraries an ii libgcc11:3.4.3-9 GCC support library ii libglib2.0-0 2.6.3-1 The GLib library of C routines ii libgtk2.0-02.6.2-4 The GTK+ graphical user interface ii libpango1.0-0 1.8.0-3 Layout and rendering of internatio ii libstdc++5 1:3.3.5-8 The GNU Standard C++ Library v3 ii libuim01:0.4.6beta2-3Simple, secure, and flexible input ii libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-10 X Window System miscellaneous exte ii uim-common 1:0.4.6beta2-3Common files for uim ii uim-utils 1:0.4.6beta2-3Utilities for uim ii xlibs 4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298358: uim-xim: opens preedit and candidate windows on wrong screen
Package: uim-xim Version: 1:0.4.6beta2-3 Severity: normal I'm running X with dual screens (not xinerama), and the uim-xim windows always appear on the first screen (:0.0), regardless of on which screen the application is running. -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.11.1 Locale: LANG=en_US.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages uim-xim depends on: ii libatk1.0-01.8.0-4 The ATK accessibility toolkit ii libc6 2.3.2.ds1-20.0.0.1.pure64 GNU C Library: Shared libraries an ii libgcc11:3.4.3-9 GCC support library ii libglib2.0-0 2.6.3-1 The GLib library of C routines ii libgtk2.0-02.6.2-4 The GTK+ graphical user interface ii libpango1.0-0 1.8.0-3 Layout and rendering of internatio ii libstdc++5 1:3.3.5-8 The GNU Standard C++ Library v3 ii libuim01:0.4.6beta2-3Simple, secure, and flexible input ii libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-10 X Window System miscellaneous exte ii uim-common 1:0.4.6beta2-3Common files for uim ii uim-utils 1:0.4.6beta2-3Utilities for uim ii xlibs 4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290600: hdup: commas still bork in 2.0.6
Package: hdup Version: 2.0.6-1 Followup-For: Bug #290600 Escaping commas in the exclude list still fails for me. It causes the same behavious as before: nothing is excluded, not even matches for other excludes. [testhost] dir = /tmp/testhdup/ exclude = \.bak$ \ , \,cache\.gz$\ , f $ v -R /tmp/testhdup /tmp/testhdup: total 4 drwxr-xr-x 2 donut donut 200 2005-02-10 13:14 . drwxrwxrwt 38 root root 4032 2005-02-10 13:18 .. -rw-r--r-- 1 donut donut0 2005-02-10 13:14 baaar -rw-r--r-- 1 donut donut0 2005-02-10 13:14 backmeup -rw-r--r-- 1 donut donut0 2005-02-10 13:14 blearg.bak -rw-r--r-- 1 donut donut0 2005-02-10 13:14 borf,cache.gz -rw-r--r-- 1 donut donut0 2005-02-10 13:14 fo # hdup monthly testhost hdup: Line 39: Sparse is always enabled. hdup: testhost: STARTING BACKUP. /bin/tar: Removing leading `/' from member names Hdup version.: 2.0.6 Host.: testhost Date.: 2005-02-10 Scheme...: monthly Archive..: testhost.2005-02-10.monthly.tar.bz2 Encryption...: yes (gpg, [EMAIL PROTECTED]) Archive size.: 858B Elapsed..: 0:00:01 Status...: successfully performed backup # gpg -d testhost/2005-02-10/*.nc | tar jtvf - [snip gpg stuff] -rw-r--r-- donut/donut 0 2005-02-10 13:14:37 tmp/testhdup//baaar -rw-r--r-- donut/donut 0 2005-02-10 13:14:21 tmp/testhdup//backmeup -rw-r--r-- donut/donut 0 2005-02-10 13:14:27 tmp/testhdup//blearg.bak -rw-r--r-- donut/donut 0 2005-02-10 13:14:32 tmp/testhdup//borf,cache.gz -rw-r--r-- donut/donut 0 2005-02-10 13:14:35 tmp/testhdup//fo -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.7-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages hdup depends on: ii libc6 2.3.2.ds1-20.0.0.1.pure64 GNU C Library: Shared libraries an ii libglib2.0-0 2.6.2-1 The GLib library of C routines ii rsync 2.6.3-2 fast remote file copy program (lik ii ssh1:3.8.1p1-8.sarge.4 Secure rlogin/rsh/rcp replacement -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290600: hdup: actually, the config parsing changed
Package: hdup Version: 2.0.6-1 Followup-For: Bug #290600 Actually, it looks like escaped commas do work, what doesn't work is the config parsing changed so that continuation lines no longer work correctly. So I'll file a new bug about it. -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.7-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages hdup depends on: ii libc6 2.3.2.ds1-20.0.0.1.pure64 GNU C Library: Shared libraries an ii libglib2.0-0 2.6.2-1 The GLib library of C routines ii rsync 2.6.3-2 fast remote file copy program (lik ii ssh1:3.8.1p1-8.sarge.4 Secure rlogin/rsh/rcp replacement -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290723: hdup: include example cron file
Package: hdup Version: 2.0.4-1 Severity: wishlist The hdup source includes an example cron file (examples/hdup.cron) It would be good to include it in /usr/share/doc/hdup/examples (There is also examples/no-history-post-run.sh that might be good to include too, but the cron example is what I was looking for.) -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.7-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages hdup depends on: ii libc6 2.3.2.ds1-19.0.0.2.pure64 GNU C Library: Shared libraries an ii libglib2.0-0 2.4.8-1 The GLib library of C routines ii rsync 2.6.3-2 fast remote file copy program (lik ii ssh1:3.8.1p1-8.sarge.4 Secure rlogin/rsh/rcp replacement -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290599: exclude: is it a regex or not?
Package: hdup Version: 2.0.4-1 Severity: normal hdup.conf(5) says The include and exclude keywords take regular expression as there input. But the example hdup.conf has lines like exclude = lost+found/, /proc/, /dev/, /sys/ exclude = /var/*/docs which are clearly not intended to be regular expressions -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.7-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages hdup depends on: ii libc6 2.3.2.ds1-19.0.0.2.pure64 GNU C Library: Shared libraries an ii libglib2.0-0 2.4.8-1 The GLib library of C routines ii rsync 2.6.3-2 fast remote file copy program (lik ii ssh1:3.8.1p1-8.sarge.4 Secure rlogin/rsh/rcp replacement -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290598: hdup: infinite loop on non-existant dir
Package: hdup Version: 2.0.4-1 Severity: normal While testing out hdup, I accidentally missed the comma in specifying multiple dirs, and used: [testhost] dir = /tmp/testhdup/ /tmp/testhdup2/ when I ran: hdup monthly testhost I get an endless stream of: hdup: WARNING: Cannot stat: /tmp/testhdup/ /tmp/testhdup2/! And ctrl-c doesn't stop it, though ctrl-\ does. -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.7-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages hdup depends on: ii libc6 2.3.2.ds1-19.0.0.2.pure64 GNU C Library: Shared libraries an ii libglib2.0-0 2.4.8-1 The GLib library of C routines ii rsync 2.6.3-2 fast remote file copy program (lik ii ssh1:3.8.1p1-8.sarge.4 Secure rlogin/rsh/rcp replacement -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290600: hdup: cannot exclude filenames with comma in them
Package: hdup Version: 2.0.4-1 Severity: normal I tried to exclude a filename with a comma in it: [testhost] dir = /tmp/testhdup/, /tmp/testhdup2/ exclude = \.bak$, \,cache\.gz Not only did it not work, but hdup monthly testhost instead backed up everything in the current directory rather than the dirs specified. - System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.7-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages hdup depends on: ii libc6 2.3.2.ds1-19.0.0.2.pure64 GNU C Library: Shared libraries an ii libglib2.0-0 2.4.8-1 The GLib library of C routines ii rsync 2.6.3-2 fast remote file copy program (lik ii ssh1:3.8.1p1-8.sarge.4 Secure rlogin/rsh/rcp replacement -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
