Bug#1067201: apt: Improved bash-completion for 'apt edit-sources'
Package: apt
Version: 2.7.13
Severity: minor
Tags: patch
Attached are minor improvements to 'apt edit-sources' bash completion:
- Generate accurate '*.list' list of files, and omit '.list'
suffixes. (I _would_ also list '*.sources', but current 'apt
edit-sources' does not support this newer file format.)
- Quote filenames as needed
- Honor $APT_CONFIG by calling 'apt-config' instead of hardcoding
/etc/apt/sources.list.d. (For efficiency, this is only in the
'edit-sources' codepath.)
Quoting filenames seems like overkill, but _could_ matter for users
who maintain a separate non-default config under $HOME. (I do this in
order to make many additional 'deb-src' available, with corresponding
trusted keys, without encumbering the systemwide 'apt update'.)
Thanks,
Peter
--- a/completions/bash/apt
+++ b/completions/bash/apt
@@ -2,7 +2,6 @@
_apt()
{
-local sourcesdir="/etc/apt/sources.list.d"
local cur prev words cword
_init_completion || return
@@ -211,8 +210,13 @@
return 0
;;
edit-sources)
-COMPREPLY=( $( compgen -W '$( command ls $sourcesdir )' \
--- "$cur" ) )
+ mapfile -t COMPREPLY < <(
+eval $(apt-config shell root Dir etcapt Dir::Etc
sourcesdir Dir::Etc::sourceparts)
+[[ $etcapt == /* ]] || etcapt=$root/$etcapt
+[[ $sourcesdir == /* ]] || sourcesdir=$etcapt/$sourcesdir
+IFS='
+' compgen -W "$(shopt -s nullglob; basename -s.list
"$sourcesdir"/*.list)" -- "$cur")
+compopt -o filenames
return 0
;;
moo)
Bug#1054606: libcap2-bin: Move /sbin/getcap to /bin
Package: libcap2-bin Version: 1:2.66-4 Severity: wishlist In my opinion, getcap(8) is useful to run as a non-root user, so it should be in /bin rather than /sbin. This seems analogous to ip(8) from iproute2, which was moved to /bin many years ago. Thanks, Peter
Bug#1052264: dash: Fix manpage dashes (ASCII '-' / hyphen / en dash / em dash)
Package: dash Version: 0.5.12-6 Severity: minor Tags: patch upstream tl;dr: This patch restores the ability to search manpages for text containing ASCII hyphens, like "-V" or ">&-", using pagers like "less". nroff can render 4 distinct dash characters, if non-ASCII output is supported (as in modern Debian, unless suppressed with, e.g., "export MANOPT=-Eascii"): \- ASCII hyphen. Use: Any place one would type a literal ASCII hyphen: "ls \-F", "$((OPTIND \- 1))", "chdir \-" - non-ASCII hyphen Use: Phrases like "POSIX-compliant", "human-readable", "built-in". Also used by nroff to break a word of text across 2 lines. \(enen dash (the width of "n"). Use: Very rare. I think it's a mathematical minus sign, but of course it's not used in $(( )) shell expressions. \(emem dash (traditionally, the width of lowercase "m"). Use: To break up grammatical phrases: "the shell executes the command asynchronously \(em that is, the shell does not wait for the command to finish" The - vs. \- distinction especially matters, because if you search for "<<-" by typing "/<<-" into "less", but nroff has used a non-ASCII hyphen there, it will not find it. (Also, some older X11 fonts don't have the non-ASCII dash chars. Though that has an easy workaround, "MANOPT=-Eascii".) Thanks, Peter From: Peter Samuelson Date: Tue, 19 Sep 2023 11:53:05 -0500 Subject: Fix manpage dashes (ASCII '-' / hyphen / en dash / em dash) Directs nroff to use ASCII "-" to document the shell's uses of "-". This ensures that expressions like "-V" and ">&-" are searchable using pagers like "less". (Also changes some \(en to \(em for correctness, but that is purely cosmetic.) --- a/src/dash.1 +++ b/src/dash.1 @@ -124,7 +124,7 @@ An interactive shell generally prompts b programming and command errors differently (as described below). When first starting, the shell inspects argument 0, and if it begins with a dash -.Sq - , +.Sq \- , the shell is also considered a login shell. This is normally done automatically by the system @@ -176,7 +176,7 @@ The set name is provided next to the single letter option in the description below. Specifying a dash -.Dq - +.Dq \- turns the option on, while using a plus .Dq + disables the option. @@ -270,7 +270,7 @@ Following is a list of operators: .It "Control operators:" .Dl & && \&( \&) \&; ;; | || \*[Lt]newline\*[Gt] .It "Redirection operators:" -.Dl \*[Lt] \*[Gt] \*[Gt]| \*[Lt]\*[Lt] \*[Gt]\*[Gt] \*[Lt]& \*[Gt]& \*[Lt]\*[Lt]- \*[Lt]\*[Gt] +.Dl \*[Lt] \*[Gt] \*[Gt]| \*[Lt]\*[Lt] \*[Gt]\*[Gt] \*[Lt]& \*[Gt]& \*[Lt]\*[Lt]\- \*[Lt]\*[Gt] .El .Ss Quoting Quoting is used to remove the special meaning of certain characters or @@ -323,14 +323,14 @@ If it does, it replaces it in the input For example, if there is an alias called .Dq lf with the value -.Dq "ls -F" , +.Dq "ls \-F" , then the input: .Pp .Dl lf foobar Aq return .Pp would become .Pp -.Dl ls -F foobar Aq return +.Dl ls \-F foobar Aq return .Pp Aliases provide a convenient way for naive users to create shorthands for commands without having to learn how to create functions with arguments. @@ -404,12 +404,12 @@ Redirect standard input (or n) from file .It [n1] Ns \*[Lt]& Ns n2 Copy file descriptor n2 as stdout (or fd n1). fd n2. -.It [n] Ns \*[Lt]&- +.It [n] Ns \*[Lt]&\- Close standard input (or n). .It [n1] Ns \*[Gt]& Ns n2 Copy file descriptor n2 as stdin (or fd n1). fd n2. -.It [n] Ns \*[Gt]&- +.It [n] Ns \*[Gt]&\- Close standard output (or n). .It [n] Ns \*[Lt]\*[Gt] file Open file for reading and writing on standard input (or n). @@ -433,13 +433,13 @@ subjected to parameter expansion, comman expansion (as described in the section on .Dq Expansions ) . If the operator is -.Dq \*[Lt]\*[Lt]- +.Dq \*[Lt]\*[Lt]\- instead of .Dq \*[Lt]\*[Lt] , then leading tabs in the here-doc-text are stripped. .Ss Search and Execution There are three types of commands: shell functions, builtin commands, and -normal programs \(en and the command is searched for (by name) in that order. +normal programs \(em and the command is searched for (by name) in that order. They each are executed in a different way. .Pp When a shell function is executed, all of the shell positional parameters @@ -578,11 +578,11 @@ the preceding AND-OR-list. .Pp Note that unlike some other shells, each process in the pipeline is a child of the invoking shell (unless it is a shell builtin, in which case -it executes in the current shell \(en but any effect it has on the +it executes in the current shell
Bug#1050875: feh: Escape hyphens in manpage
Package: feh
Version: 3.10-1
Severity: minor
Tags: patch upstream
feh.1, like many manpages, fails to escape the `-` character in option
descriptions. In modern groff, this causes each one to be rendered as
U+2010 "HYPHEN" instead of the ASCII character (U+002D "HYPHEN-MINUS").
The net effect:
- Certain old fonts (I still use the classic X11 'fixed' for my xterms)
don't have the U+2010 glyph
- Searching in "less" (by typing, e.g., "/--auto " does not work.
Fortunately the manpage formats every instance of every option with the
"Cm" macro, so this is easy to fix without also hitting all the
legitimate English-language hyphens that are not options (as in the
phrase "English-language"). Here is a simple patch.
Thanks,
Peter
--- feh-3.10/man/Makefile~ 2023-04-06 09:19:59.0 -0500
+++ feh-3.10/man/Makefile 2023-08-30 11:35:13.557736015 -0500
@@ -15,6 +15,7 @@
-e 's/\$$MAN_INOTIFY\$$/${MAN_INOTIFY}/' \
-e 's/\$$MAN_MAGIC\$$/${MAN_MAGIC}/' \
-e 's/\$$MAN_XINERAMA\$$/${MAN_XINERAMA}/' \
+ -e '/^\(\.Cm\|\.[A-Z][a-z].* Cm\)/{ s/ -\([^ ]\)/ \\-\1/g; s/\(\\-[^
\-]*\)-/\1\\-/g; s/\(\\-[^ \-]*\)-/\1\\-/g }' \
< ${@:.1=.pre} > $@
clean:
Bug#1038155: [Pkg-zfsonlinux-devel] Bug#1038155: zfs-linux: Provide a package based on OpenZFS master branch (a.k.a. 2.1.99)
[M. Zhou] > I'd personally not prefer to upload zfs-X.Y.99 anytime in the future. > Since debian is volunteer-based, we don't seem to have more bandwidth > than Ubuntu for dealing with regressions and serious bugs in a > snapshot version. That's fair - but now that Linux 6.4 is in unstable, zfs-dkms is no longer supported and will not build. For that reason, could you update to 2.2.0-rc3? Peter
Bug#1034697: [PATCH] usb.ids typo fixes
Package: usb.ids Version: 2023.01.16-1 Severity: minor The UI at http://www.linux-usb.org/usb-ids.html, and the email submission interface, do not permit submissions of anything but vendors, devices, and classes. Here are some other typos I found just by paging through the usb.ids file. If you have another way to submit these upstream for me, please do. (To be fair, I have no idea what contexts these strings are even used in.) --- usb.ids 2023-02-04 04:50:18.0 -0600 +++ usb.ids 2023-04-05 23:36:02.489284368 -0500 @@ -23817,7 +23817,7 @@ AT 0201 Microphone AT 0202 Desktop Microphone AT 0203 Personal Microphone -AT 0204 Omni-directional Microphone +AT 0204 Omni-Directional Microphone AT 0205 Microphone Array AT 0206 Processing Microphone Array AT 0300 Output Undefined @@ -23832,8 +23832,8 @@ AT 0401 Handset AT 0402 Headset AT 0403 Speakerphone, no echo reduction -AT 0404 Echo-suppressing speakerphone -AT 0405 Echo-canceling speakerphone +AT 0404 Echo-Suppressing Speakerphone +AT 0405 Echo-Canceling Speakerphone AT 0500 Telephony Undefined AT 0501 Phone line AT 0502 Telephone @@ -24055,7 +24055,7 @@ 0b9 Elevator Trim 0ba Rudder 0bb Throttle - 0bc Flight COmmunications + 0bc Flight Communications 0bd Flare Release 0be Landing Gear 0bf Toe Break @@ -24072,8 +24072,8 @@ 0ca Barrel Elevation 0cb Drive Plane 0cc Ballast - 0cd Bicylce Crank - 0ce Handle Bars + 0cd Bicycle Crank + 0ce Handlebars 0cf Front Brake 0d0 Rear Brake HUT 03 VR Controls @@ -24345,7 +24345,7 @@ 00b High Cut Filter 00c Low Cut Filter 00d Equalizer Enable - 00e Sound Field ON + 00e Sound Field On 00f Surround On 010 Repeat 011 Stereo @@ -24888,7 +24888,7 @@ 02d Display Status 02e Stat Not Ready 02f Stat Ready - 030 Err Not a loadable Character + 030 Err Not a Loadable Character 031 Err Font Data Cannot Be Read 032 Cursur Position Report 033 Row @@ -25156,14 +25156,14 @@ 04 Libya 05 Algeria 06 Morocco - 07 Tunesia + 07 Tunisia 08 Oman 09 Yemen 0a Syria 0b Jordan 0c Lebanon 0d Kuwait - 0e U.A.E + 0e U.A.E. 0f Bahrain 10 Qatar L 0002 Bulgarian @@ -25192,7 +25192,7 @@ 06 Ireland 07 South Africa 08 Jamaica - 09 Carribean + 09 Caribbean 0a Belize 0b Trinidad 0c Zimbabwe @@ -25228,7 +25228,7 @@ 06 Monaco L 000d Hebrew L 000e Hungarian -L 000f Idelandic +L 000f Icelandic L 0010 Italian 01 Italian 02 Swiss @@ -25282,13 +25282,13 @@ L 002f Macedonian L 0036 Afrikaans L 0037 Georgian -L 0038 Faeroese +L 0038 Faroese L 0039 Hindi L 003e Malay 01 Malaysia 02 Brunei Darassalam L 003f Kazak -L 0041 Awahili +L 0041 Swahili L 0043 Uzbek 01 Latin 02 Cyrillic
Bug#1034425: openssh: incorrection in changelog date
Source: openssh Version: 1:9.1p1-2 Severity: minor I have no idea what possessed you to fix the dates on those 20-year-old changelog entries, but since you care ... 1:3.0.2p1-2 is still wrong. The correct fix was not s/Sat/Sun/ but s/2003/2002/.
Bug#1034315: ffmpeg: 5.1, 6.0 libraries not co-installable
Package: libavcodec60
Version: 7:6.0-1
Severity: minor
libavcodec{59,60} cannot be co-installed because both depend on exact
versions of libswresample4. (Also, libavfilter{8,9} have the same
issue.)
This will require an all-or-nothing library transition, and it means I
can't install ffmpeg 6.0 from experimental without rebuilding many
other things.
It was not an issue with the previous ABI update, ffmpeg 7:4.x -> 7:5.x,
because libswresample SONAME was updated as well.
Bug#1026423: ykls: Crashes when smartcard reader present
Package: ykls Version: 1.3.4-2+b7 Severity: normal $ lsusb | grep -e Yubi -e Smart Bus 001 Device 098: ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID Bus 001 Device 099: ID 04e6:5116 SCM Microsystems, Inc. SCR331-LC1 / SCR3310 SmartCard Reader $ ykls Reader: SCM Microsystems Inc. SCR 3310 [CCID Interface] (53311904213994) 00 00 panic: ykpiv ykpiv_connect: Generic Error (-7) - Something went wrong. goroutine 1 [running]: main.ohshit(...) pault.ag/go/ykpiv/cmd/ykls/ykls.go:31 main.main() pault.ag/go/ykpiv/cmd/ykls/ykls.go:44 +0x6bc If I unplug the smartcard reader, it works: $ lsusb | grep -e Yubi -e Smart Bus 001 Device 098: ID 1050:0407 Yubico.com Yubikey 4/5 OTP+U2F+CCID $ ykls Reader: Yubico YubiKey OTP+FIDO+CCID 01 00 Version: 5.2.4 Serial: [correct] Slot Authentication (9a): [correct] -- System Information: Debian Release: bookworm/sid APT prefers stable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ykls depends on: ii libc6 2.36-6 ii libykpiv2 2.2.0-1.1 ii pcscd 1.9.9-1
Bug#991896: 2.1.1 works
Can confirm that Lukas's patch builds zfs 2.1.1 when I update abigail build-dep to (>= 1.8) and unfuzz patches. Seems to work, too, at least with the kernel I'm booted into, 5.13.0-trunk-amd64 from experimental. (Which zfs 2.0.x does not support.) Peter
Bug#879969: ssh-keygen confused by ssh1 keys in known_hosts
Package: openssh-client Version: 1:7.6p1-2 Severity: minor ssh-keygen refuses to edit my known_hosts file because: $ ssh-keygen -f kh -R foo kh:17: invalid line kh:146: invalid line kh is not a valid known_hosts file. Not replacing existing known_hosts file because of errors Those "invalid lines" are rsa1 keys: rs.site,10.4.4.45 1024 35 120827615620379168038156516080013624848700791268368119108785611376697029075954168094441677159367035018806129401832284850511192692275527462656470026121334403761902147037130809809803347554587276791586677089854981982248968857488459287470369817017855272224015513609748298558561687103816296851327327397457764845141 foo-net1 512 65537 12916953485480363298334219922262685358649329403718569541545235269691512584713088346570238216084763622340697442750588053760444848729916916068416583187159093 (Yep, a managed switch from around 2006 used a 512-bit rsa1 host key!) Even though we no longer support protocol 1, it seems normal for a known_hosts file to still have such entries in it. Would be nice if ssh-keygen could still parse (or ignore) those lines. signature.asc Description: PGP signature
Bug#834975: zgrep: error if a match not found in _every_ file
Package: gzip Version: 1.6-5 Severity: normal Given multiple files, zgrep's return value is inconsistent with grep: $ echo foo > a $ true > b $ grep -q foo a b; echo $? 0 $ zgrep -q foo a b; echo $? 1 That is: grep succeeds, because at least one file contains a match. But: zgrep fails, because at least one file does _not_ contain a match. The grep behavior is far more useful.
Bug#693424: ssh: Please include HPN (high performance networking) patches for SSH
[Colin Watson] > Sorry, but I am not going to include any more large and invasive patch > sets in Debian's OpenSSH package, especially not ones that add new > configuration options (upstream has a history of giving such things > different names when they accept them, and then I'm stuck maintaining > configuration file compatibility forever). This needs to go upstream. Understandable, but too bad. Apparently this dramatic performance improvement is unlikely to go upstream: "So if HPN-SSH is so awesome why hasn't OpenSSH adopted it? That's a long story and people who know the OpenBSD team probably already know the answer. I understand many of their reasons - it's a big patch which would require additional work on their end (and they are a small team), they don't care as much about performance as security (though there is no security implications to HPN-SSH), etc etc etc. However, even though OpenSSH doesn't use HPN-SSH Facebook does. So do Google, Yahoo, Apple, most ever large research data center, NASA, NOAA, the government, the military, and most financial institutions. It's pretty well vetted at this point." - http://stackoverflow.com/questions/8849240 My own 2c: the NONE cipher and the parallel AES implementation are not very interesting, because with an Intel Sandy Bridge CPU (with hardware acceleration for both AES and GCM), the AES + GCM mode ciphers are _really_ fast. Anyone who cares about performance should be using them, and should buy Sandy Bridge or newer CPUs. But the receive buffer scaling part of the HPN patchset is still relevant, and in fact quite critical for long fat pipes. (Fortunately the various features are broken out into individual patches.) I wonder how long until OpenSSH upstream realises that a 1.2 MB window is not really large enough on today's Internet.
Bug#749014: Please reenable CONFIG_USB_UAS
reassign 749014 src:linux thanks [Ben Hutchings] Your mail server seems to be broken. Right you are, thanks for the extra step to contact me via the BTS. This should be assigned to src:linux not a binary package. Also correct, I just didn't know offhand whether there was a way to assign to a source package via control. Guess it's time to find out. In a sense _all_ bugs, except perhaps binNMU requests, are on source packages. So it strikes me as kinda odd that the BTS and associated infrastructure mostly encourage per-binary-package thinking. Thanks, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749014: Please reenable CONFIG_USB_UAS
reassign 749014 linux-image-3.17.0-trunk-amd64 thanks CONFIG_USB_UAS was enabled but then later disabled due to problems with a particular Seagate USB enclosure (#755995). Upstream found a workaround, a quirks table / blacklist approach, and this fix was included in 3.17.1 (see below). Therefore could you reenable CONFIG_USB_UAS for 3.17? Thanks, Peter commit c36cac9f20886a5a60d4f9388f6faef547d78d61 Author: Hans de Goede hdego...@redhat.com Date: Mon Sep 15 16:04:12 2014 +0200 uas: Add a quirk for rejecting ATA_12 and ATA_16 commands commit 593078525c8b234a35a36ff551b8716464e86481 upstream. And set this quirk for the Seagate Expansion Desk (0bc2:2312), as that one seems to hang upon receiving an ATA_12 or ATA_16 command. https://bugzilla.kernel.org/show_bug.cgi?id=79511 https://bbs.archlinux.org/viewtopic.php?id=183190 While at it also add missing documentation for the u value for usb-storage quirks. Signed-off-by: Hans de Goede hdego...@redhat.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749014: Please enable CONFIG_USB_UAS
Package: linux-image-3.15-rc5-amd64 Version: 3.15~rc5-1~exp1 Severity: wishlist CONFIG_USB_UAS (USB Attached SCSI) is apparently now solidly supported: a patchset arrived in the 3.15 window to rewrite it and remove it from CONFIG_BROKEN. Please add this to kernels that support USB 3.0 (it may work in USB 2.0 as well, I'm not certain), as it sounds like this can potentially work much better on many devices than the classic usb_storage protocol. Thanks, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745168: gpm: Please use arch:linux-any
Source: gpm This package seems Linux-specific, so it should use Architecture: linux-any in the control file, so its build is not even tried on non-Linux archs. Well, really libgpm2 should be ported to non-Linux platforms. gpm itself may be specific to the Linux console, but libgpm2 shouldn't be. It provides a common API to both gpm and xterm. And xterm is up to date on all 3 non-Linux ports. (And s390x, another platform where the gpm daemon itself doesn't make sense.) Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739790: please provide a python3-subversion package
[Matthias Klose] Please build the subversion bindings for Python3, but keep building the bindings for Python2. I don't think that a hard switch can be made, and we have to provide both at least for some time. Python3 is not supported upstream. A port was done, or at least attempted, a couple years ago by an upstream developer, but the patches were deemed too ugly to mainstream, for not much benefit. The situation may change in the future if, e.g., upstream drops support for Python 2.5. Perhaps the patches to support both 2.6 and 3.x would be less ugly. I'd rather not maintain a patchset for Python 3 compatibility until upstream supports it, as I don't really understand it. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737614: subversion: When updating a repository, please tell from which revision we update
[Fabian Greffrath] So, the question boils down to What should be shown as old revision, if not all files in the repo had the same old revision?. If you really want this feature and are trying to figure out the design, look at 'svnversion'. In the mixed-rev case, it shows a range. (It also explicitly indicates whether there are any switched subdirs or modified files, which you probably don't need here.) Also, note that 'svn update' can be thought of as just a special case of 'svn switch'. (That is, switch does 2 things, changes the repository path _and_ updates to a specified revision, or to HEAD.) With that in mind, as you implement this, you should probably make sure it works for both 'svn update' and 'svn switch'. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737614: subversion: When updating a repository, please tell from which revision we update
Am Dienstag, den 04.02.2014, 23:37 -0600 schrieb Peter Samuelson: What would you expect the software to say in a mixed-rev wc? [Fabian Greffrath] I don't know, I have never worked with such a repository (and my patch only addresses the simple single-rev wc case). I doubt that. Mixed-rev working copies are the common case, not the exception. Almost every time you run 'svn commit', you get a mixed-rev wc. The files you commit are updated to the revision you committed, while the rest of the wc is not. To understand why this happens, consider 2 facts: - You are permitted to commit from an out-of-date wc, so long as the specific files you are committing are up to date; - 'svn commit' does not automatically run 'svn update'. What does it say which revision it updated to in a mixed-rev wc? 'svn update' always updates to a single revision (HEAD by default, or you can specify a revision with -r), so it prints that single revision. (Well, except for externals, but those are handled separately, as though you were running 'svn update' individually for each external.) Of course you can update just a subset of the wc (e.g., 'svn update foo.txt'), to create a mixed-rev wc, but 'update' itself still only has a single target revision to report. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731769: subversion: .svn/pristine size gets huge over time
[Vincent Lefevre] A svn cleanup reduces the pristine size to normal, but 1. this isn't documented (I'm wondering how many users know that); 2. this isn't automatic. Right... I seem to recall that there is a vague plan to keep unused pristines around for awhile in order to reuse them instead of re-downloading, e.g., for 'svn blame' where you currently need to download a big pile of deltas for the file you're blaming. So the accumulation of pristine files is intentional. But I don't _think_ anything is currently implemented on that, so right now it's not a win. About (2), svn could warn the user when a cleanup could be needed. I don't know what is the best solution. Right ... there's not really an obvious time for such a warning to be issued. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731769: subversion: .svn/pristine size gets huge over time
[Vincent Lefevre] Well, the main problem with such unreferenced pristines is big files, and very often big files are binary files, or one doesn't use blame on them. Well, 'svn blame' is just an example. 'svn switch', switching between branches, is another case where caching pristines that are not in active use would be useful. Some people switch between branches often. (I don't, I usually use distinct working copies for multiple branches.) As I said, I'm not sure whether there's a concrete plan to use these or if it's still just we really ought to think about doing this. Right ... there's not really an obvious time for such a warning to be issued. This could also be announced in NEWS.Debian. I hadn't thought of that. Certainly major behavior changes that affect a lot of users, or affect global administration of services, should be noted in NEWS.Debian. I'm not sure I'm convinced that this is such a case. I don't want to increase the useless stuff people who use apt-listchanges have to wade through. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729426: Tighten versioned dependency on SQLite3
reassign 729426 libsvn1 forcemerge 721878 729426 thanks [Wouter Bolsterlee] svn: E200029: Couldn't perform atomic initialization svn: E200030: SQLite compiled for 3.8.0.2, but running with 3.7.13 Thanks. The problem is that there's 3 different opinions on this dependency, and none of them match: (1) sqlite3 shlibs and symbols files; (2) The configure + build process detects SQLite features and optimizes the build to use whatever features it knows it can rely on; (3) To be on the safe side, as it were, libsvn1 does a runtime check to make sure the SQLite version is at least as recent as the one it was built with. (That's the error you see above.) So the problem is that what we need is (2), but what we actually get is (1) which is unsafe because it is not strict enough, and (3) which is too strict. At some point I patched (3) so it only cares about 'major.minor' rather than 'major.minor.patch', but as you can see, that is still too strict. It's been suggested we use runtime detection of SQLite features in libsvn1, but that's not really convenient: if I remember correctly, the build process involves compiling SQL queries which may use newer SQLite features. I'll try to look into it anyway - I expect upstream would be interested. What we will probably do instead is patch out (3), audit the (2) cases, and hard-code a minimum SQLite version, to be adjusted every major new Subversion release that may make use of additional SQLite features. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710498: subversion: enable java components on mips and mipsel
[James McCoy] Peter, what do you think of a) dropping the arch blacklists for Java and b) changing from gcj-jdk to default-jdk? I'm a bit leery of using only OpenJDK everywhere, in principle, if it causes gcj to fade away. Java was always supposed to be an open platform, but these days it seems Oracle controls the only viable implementations. They effectively killed a competing effort at the ASF, after suing Google for daring to use it for the Android platform, a Java implementation they didn't control. (I don't know how the lawsuit went, but the Apache subproject died when its contributors all saw that there was no future in trying to oppose Oracle.) But... If the rest of the Debian Project has voted with their feet, and we support Oracle's de facto hegemony over Java, there's no reason for Subversion to stand against it. Besides, I don't even care much about Java in the first place. So, the main reason I haven't switched to OpenJDK and revisit the per-arch list, is just that it didn't seem worth the effort. If it's worth it now, go ahead. Ubuntu has already done so. (Not surprising, as they employ the openjdk maintainer.) Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726476: Ignores my RFC 1918 reverse zones by default
Package: bind9
Version: 1:9.9.3.dfsg.P2-4
Severity: normal
My RFC 1918 reverse zone definitions no longer work, unless I specify:
disable-empty-zone 168.192.in-addr.arpa;
(one for each reverse zone.) According to the ARM, I should not have
to do that - it should detect that I've defined these zones. My
definitions are very simple:
zone 168.192.in-addr.arpa {
type forward;
forwarders { 192.168.10.6; 192.168.10.7; };
};
I think this broke some time after 1:9.8.4.dfsg.P1-4.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.8-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages bind9 depends on:
ii adduser3.113+nmu3
ii bind9utils 1:9.9.3.dfsg.P2-4
ii debconf [debconf-2.0] 1.5.51
ii init-system-helpers1.11
ii libbind9-901:9.9.3.dfsg.P2-4
ii libc6 2.17-93
ii libcap21:2.22-1.2
ii libcomerr2 1.42.8-1
ii libdns99 1:9.9.3.dfsg.P2-4
ii libgssapi-krb5-2 1.11.3+dfsg-3
ii libisc95 1:9.9.3.dfsg.P2-4
ii libisccc90 1:9.9.3.dfsg.P2-4
ii libisccfg901:9.9.3.dfsg.P2-4
ii libk5crypto3 1.11.3+dfsg-3
ii libkrb5-3 1.11.3+dfsg-3
ii liblwres90 1:9.9.3.dfsg.P2-4
ii libssl1.0.01.0.1e-3
ii libxml22.9.1+dfsg1-3
ii lsb-base 4.1+Debian12
ii net-tools 1.60-25
ii netbase5.1
bind9 recommends no packages.
Versions of packages bind9 suggests:
ii bind9-doc 1:9.9.3.dfsg.P2-4
ii dnsutils1:9.9.3.dfsg.P2-4
pn resolvconf none
pn ufw none
-- Configuration Files:
/etc/bind/named.conf changed:
options {
directory /var/cache/bind;
auth-nxdomain no;# conform to RFC1035
listen-on-v6 { any; };
forwarders { 2001:4de0:1000:a4::2; 2001:4de0:1000:a3::2; };
disable-empty-zone 168.192.in-addr.arpa;
disable-empty-zone 26.172.in-addr.arpa;
disable-empty-zone 28.172.in-addr.arpa;
disable-empty-zone 30.172.in-addr.arpa;
};
zone 168.192.in-addr.arpa { type forward; forwarders { 192.168.10.6;
192.168.10.7; }; };
zone 26.172.in-addr.arpa { type forward; forwarders { 192.168.10.6;
192.168.10.7; }; };
zone 28.172.in-addr.arpa { type forward; forwarders { 192.168.10.6;
192.168.10.7; }; };
zone 30.172.in-addr.arpa { type forward; forwarders { 192.168.10.6;
192.168.10.7; }; };
include /etc/bind/named.conf.default-zones;
-- debconf information:
bind9/run-resolvconf: false
bind9/different-configuration-file:
bind9/start-as-user: bind
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722233: subversion: SQLite problem with new version of subversion, svn upgrade does not work
[Luca Conte] This morning I've dist-upgraded my debian testing and the problem has gone because, as someone said, (lib)sqlite3 unstable version was shifted into testing! You can thank Julien Cristau for making that happen. It's not a fix for this bug but it was an expedient workaround. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722233: subversion: diff for NMU version 1.7.9-1+nmu5
[Julien Cristau] + * Non-maintainer upload. + * Drop SQLite version check (closes: #722233). This is dpkg-shlibdeps' job. Well, you're half right: it's something that should be expressed as package dependencies, at which point the runtime version check would be redundant and perhaps too strict. But dpkg-shlibdeps looks only at C symbols. The effective ABI of the SQLite library includes many things that do not show up as C symbols: it is an interpreter for (a subset of) SQL and the ABI involves passing strings around, which are interpreted. The thing to do is to figure out which SQLite version-specific features are used by a given svn codebase - when it detects the sqlite version at build time - and work out a dependency from _that_. Still thinking about a good way to do that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721878: libsvn1: outdated libsqlite dependency
---8--- svn: E200029: Couldn't perform atomic initialization svn: E200030: SQLite compiled for 3.8.0.1, but running with 3.7.17 ---8--- Sigh. This kind of problem is usually solved by the shlibs system, but that doesn't fully work here. The problem is that the SQLite ABI (usable SQL features, basically) doesn't really correspond to C symbols. Subversion detects the version at build time in order to decide what features to use, so it makes sense to have the runtime check to make sure SQLite is new enough, but it is not obvious how to translate that into the Debian package metadata, except by crude heuristics. Also, the runtime check is very simple, thus it is stricter than it needs to be - probably the sqlite 3.7.17 ABI would have been fine. I've already partially fixed the check, but it appears I need to do more. I have an idea for a better (though hacky) approach. -- To UNSUBSCRIBE, email to debian-bugs-dist-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] 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-dist-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-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602034: jpeg8 vs jpeg-turbo
[Mathieu Malaterre] I do not believe in debian life-span, a package manager ever switch an implementation of a package. So libjpeg9 and libjpeg-turbo will have to co-live. It happens. Look at the source for 'libc6'. It used to be glibc, these days it is a fork called eglibc. Likewise the source for the 'ssh' package was once SSH by Tatu Ylonen, these days it is a fork called OpenSSH maintained by some OpenBSD hackers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706014: ITP: re-name -- mass rename tool using regular expression
[Joao Eriberto Mota Filho] Re-name [...] is a small and quick tool written in C so it's quicker than most rename tools written in shell scripts. [citation needed] I'm suspicious of this claim for two reasons. - The obvious tool to compare with is 'prename' (mentioned up-thread), which we already ship, and that's not shell but Perl. In terms of efficiency, this may be quite significant, as it uses the rename() system call, whereas a shell implementation would have to fork 'mv' for each file. - In my experience and belief, the efficiency of a mass rename operation is dominated by the filesystem overhead. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690998: New tabmixplus needed for new iceweasel
iceweasel 20 in experimental requires a newer tabmixplus. 0.4.0.5 seems to work. (But this is still only a 'wishlist' bug, as I'm only talking about experimental.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702922: libsvn-perl: Fails to use…/libsvn_ra/deprecated.c)
[Kacper Perschke] Additionally I'd like to ask about http://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-graph.pl Whom may I offer my help on beautifying this script with perltidy and documenting it by pod? Anything in http://svn.apache.org/repos/asf/subversion is maintained by Subversion upstream. Patches and discussion are welcome at d...@subversion.apache.org. (You may have to subscribe in order not to be moderated.) I should also note that the Subversion Perl bindings and the example scripts that use them are not very well maintained, because most upstream developers are not really Perl programmers. (Most prefer Python.) So, patches are very much welcome for all of that stuff. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701193: apr: FTBFS on x32: Needs update to ino_t_test
[Daniel Schepler] debian/ino_t_test *** *** 'apr_ino_t' size is 8, expected 4 *** Please report this to the Debian Apache maintainers *** This test exists in order to detect an ABI change from older 1.2 (before lenny!) to present. Obviously the x32 port didn't exist then, so, is there any installed base of x32 binaries outside Debian, built in an environment from 2007, that dynamically link to libapr1 and would break if run on Debian? Seems unlikely. Perhaps we can drop ino_t_test entirely? It seems like at this late date, any problem it still finds will be a false positive. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698724: screenshot is not multi-screen-aware
Package: gimp Version: 2.8.0-2+b1 Severity: normal I have a 3-head X server without Xinerama. (Xinerama doesn't support mixed video drivers - in my case, nouveau + intel + nouveau.) Thus, DISPLAY is :0.0, :0.1, :0.2. gimp Create - Screenshot only captures data from its own screen. Specifically, with gimp running on DISPLAY=:0.2, - Single window: gets the whole :0.2 screen if I select a window on any other screen. (It does DTRT if I select a window on the :0.2 screen.) - Entire screen: gets the whole :0.2 screen but not the others. (That is probably to be expected. You can't count on the total workspace to be rectangular, or to use just one visual.) - Select a region to grab: As I drag a rectangle on :0.1, the rectangle appears in the same relative coordinates on :0.2, and that is what I get. I doubt it matters, but in case it does: window manager is still ion3 from I think lenny/non-free. -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gimp depends on: ii gimp-data 2.8.0-2 ii libaa1 1.4p5-40 ii libatk1.0-0 2.4.0-2 ii libbabl-0.1-0 0.1.10-1 ii libbz2-1.0 1.0.6-4 ii libc6 2.13-35 ii libcairo2 1.12.2-2 ii libdbus-1-3 1.6.2-2 ii libdbus-glib-1-20.100-1 ii libexif12 0.6.20-3 ii libfontconfig1 2.9.0-7 ii libfreetype62.4.9-1 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libgegl-0.2-0 0.2.0-2 ii libgimp2.0 2.8.0-2+b1 ii libglib2.0-02.32.3-1 ii libgs9 9.05~dfsg-6 ii libgtk2.0-0 2.24.10-1 ii libgudev-1.0-0 175-5 ii libjasper1 1.900.1-13 ii libjpeg88d-1 ii liblcms11.19.dfsg-1.1 ii libmng1 1.0.10-3 ii libpango1.0-0 1.30.0-1 ii libpng12-0 1.2.49-2 ii libpoppler-glib80.18.4-3 ii librsvg2-2 2.36.1-1 ii libtiff43.9.6-7 ii libwebkitgtk-1.0-0 1.8.1-3.1 ii libwmf0.2-7 0.2.8.4-10 ii libx11-62:1.5.0-1 ii libxcursor1 1:1.1.13-1 ii libxext62:1.3.1-2 ii libxfixes3 1:5.0-4 ii libxmu6 2:1.1.1-1 ii libxpm4 1:3.5.10-1 ii python 2.7.3-2 ii python-gtk2 2.24.0-3 ii python2.7 2.7.3-2 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages gimp recommends: ii ghostscript 9.05~dfsg-6 Versions of packages gimp suggests: pn gimp-data-extras none pn gimp-help-en | gimp-help none pn gvfs-backends none ii libasound21.0.25-3 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#698443: subversion: fix python multi-arch include issues
[Chris J Arges] This patch fixes issues related python multi-arch include problems. This casues this package to FTBFS when building in Ubuntu raring. Looks good, except that part of your patch (the 'allpydbg' bits) is specific to the Ubuntu packaging. It's a nice clean approach, though, so those bits are easy enough to filter out. I'll put it in the next upload. Which I guess I really should upload soon, eh. (Upstream got a few patchlevels ahead of me again.) Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695229: should be 'Multi-Arch: foreign' so that chromium:{arch} is installable
Package: chromium-inspector
Severity: minor
In order to install chromium:i386 on my amd64 system, its dependency,
chromium-inspector, would need to be Multi-Arch: foreign. This is
because it is Architecture: all, which in a multi-arch context is
calculated as Architecture: {primary installed arch}.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#695229: chromium-inspector: should be 'Multi-Arch: foreign' so that chromium:{arch} is installable
[Jonathan Nieder]
Are you sure? Could you send output from trying to install it?
I used interactive aptitude and it can't install chromium:i386 because
it can't find a candidate for the chromium-inspector dependency.
(I had always thought that in the multi-arch world Arch: all meant
with the same architecture as its dependencies.)
That's what they want you to think! No, for dependency resolution
purposes, arch:all is equivalent to arch:{dpkg's primary arch}. There
are arcane reasons for this, which I only half-understand so I can't
easily explain. The short version:
https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages
The workaround is, for an arch:all package that really should be
Multi-Arch: foreign, to explicitly state that it is Multi-Arch:
foreign.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692789: ITP: hybserv -- IRC services for IRCD-Hybrid
[Dominic Hargreaves] HybServ is a daemon that connects to your IRCD-Hybrid server and automagically provides nickname, channel, memo, and oper services to your entire network if it is configured correctly to talk with your IRC server. Automagically? When you install a server package, configure it, and start it, and it then provides services, would you really describe that as not only automated, but like magic? It seems to me that that's a pretty pessimistic view of server software in general. My own expectation is that if I install, configure and start a daemon - any daemon - it will provide whatever services it is supposed to provide. And if it does, I don't see anything especially automatic or magical about it. I mean, _all_ software is automatic in a sense, and very little software is really magic. All of which is to say, I would drop the word 'automagically'. And not just because I dislike neologisms, although I do. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677788: Re: Bug#677788: multi-arch for lesstif2
31.07.2012, Peter Samuelson wrote (on debian-release): There is no need to remove gromacs in order for lesstif2 to migrate. There's no SONAME bump or anything. The issue only came up at all, because we needed to make sure the new lesstif2 does not add any new FTBFS in other packages. [Tobias Hansen] Did you check the other reverse dependencies? Do you think it's time for an unblock request? I'm pretty sure I found that the only FTBFS actually caused by the new lesstif was mtink, which has now been fixed in wheezy. As for unblocking, I think it would be safe and reasonable, but only if they also want the new empty ia32-libs in wheezy. Otherwise, migrating just lesstif itself is probably a waste of time. Last I heard from the release team, they were not excited about migrating ia32-libs to wheezy, but the security team wants it to happen. Anyway, I think they have the information they need to make a decision on this. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683398: FTBFS: build-indep needed for binary-arch
Package: cmucl Version: 20c-2 Severity: important The cmucl build is split into build-arch and build-indep, but build-indep builds doc files that appear in arch-dependent packages. This issue would cause a buildd to fail. Because it is a single-arch package, it is not normally autobuilt, but a binNMU may someday be needed and it will fail then. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683316: unblock: mtink/1.0.16-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package mtink Two FTBFS issues fixed: one for new lesstif2 (which is not in wheezy yet), the other for dpkg-dev 'binary' vs 'binary-arch'. Unfortunately I wasn't thinking of targetting wheezy at the time, so there are a couple of minor cleanups in 1.0.16-5 and 1.0.16-6. The package is QA-maintained, after all. The debdiff is still quite small. unblock mtink/1.0.16-6 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682929: equivs: Confused by symlinks in Files
[Ian Zimmerman] [50+1]transitional-foo$ grep '^Files:' control Files: foo /usr/bin [51+1]transitional-foo$ file foo foo: broken symbolic link to `bar' [...] Cannot copy foo to /usr/local/var/git/transitional-sp/equivs.nI3JY_/install/0/foo:\ No such file or directory Yeah, equivs uses the Perl File::Copy module, which doesn't seem to handle symlinks - just their targets. In other words, it's like 'cp' rather than 'cp -L'. Which brings up the question of whether equivs users would _expect_ behavior of 'cp' or behavior of 'cp -L'. I'm leaning toward 'cp -L' behavior, as you expected here, because if someone really needs to copy the target of the symlink, that's easy enough to do: create a symlink of the _directory_ that the target is in, rather than a link to the target itself. Thanks for the report, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677788: multi-arch for lesstif2
[Michael Gilbert] Make sure to file an unblock request bug for the release team to review. I doubt they will want it at this point. I should have thought of this earlier: the new lesstif2 causes FTBFSs in dependent packages. I don't know how many yet, as my workstation is still test-building them, but I've already patched one package, mtink, and there's a couple more failed build logs I haven't investigated yet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677788: multi-arch for lesstif2
[Michael Gilbert] If you wouldn't mind. Please go ahead with this. I'm already causing too much trouble for the release team with my efforts on the multiarch release goal. I saw your thread on debian-release. It looks like they aren't very interested in fixing this (and the new ia32-libs) for wheezy. That being the case, should we fix this in unstable now? It means that if any other RC bugs crop up in lesstif2, you have to use t-p-u, which is a bit of a pain. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677788: multi-arch for lesstif2
[Michael Gilbert] This package has not been updated in 3 years, so it is a prime candidate for nmu'ing. In fact, it's perfectly appropriate to nmu without advance permission of the maintainer in general. I noticed later that the new empty/dummy ia32-libs is not in wheezy, so that makes this bug much less urgent than I had thought. Anyway, I'll see if I can find time to do an NMU; if not, go ahead of course. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#677788: [patch] multi-arch for lesstif2
This patch works for me, and allows me to upgrade ia32-libs:amd64 to
the sid version.
IMO, this bug is important enough to fix in wheezy, as it affects the
ability to upgrade ia32-libs. I'd be happy to NMU, if the maintainers
don't mind.
Peter
diff -u lesstif2-0.95.2/debian/rules lesstif2-0.95.2/debian/rules
--- lesstif2-0.95.2/debian/rules
+++ lesstif2-0.95.2/debian/rules
@@ -11,11 +11,16 @@
export DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
+DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
SHELL := sh -e
BUILD := build
+LIBDIR := usr/lib/$(DEB_HOST_MULTIARCH)
+LIB_LIBDIR := debian/lesstif2/$(LIBDIR)
+DEV_LIBDIR := debian/lesstif2-dev/$(LIBDIR)
CARGS := \
+ --libdir=/$(LIBDIR) \
--with-gnu-ld --enable-static --prefix=/usr \
--disable-verbose \
--disable-build-12 --disable-build-20 --enable-build-21 \
@@ -70,15 +75,16 @@
dh_installdirs
$(MAKE) DESTDIR=$(CURDIR)/debian/lesstif2 -C build/lib/Xm-2.1 install
$(MAKE) DESTDIR=$(CURDIR)/debian/lesstif2 -C build/lib/Mrm-2.1 install
- mv debian/lesstif2/usr/lib/*.a debian/lesstif2-dev/usr/lib
- mv debian/lesstif2/usr/lib/*.so debian/lesstif2-dev/usr/lib
- rm -f debian/lesstif2/usr/lib/*.la
+ install -d $(DEV_LIBDIR)
+ mv $(LIB_LIBDIR)/*.a $(DEV_LIBDIR)
+ mv $(LIB_LIBDIR)/*.so $(DEV_LIBDIR)
+ rm -f $(LIB_LIBDIR)/*.la
# Work around libtool bug where make install will relink the libraries
# with the current system libraries.
find build/lib/Xm-2.1/.libs build/lib/Mrm-2.1/.libs \
-type f -name '*.so.*[^T]' | \
- xargs cp --target-directory debian/lesstif2/usr/lib
- chmod a-x debian/lesstif2/usr/lib/*
+ xargs cp --target-directory $(LIB_LIBDIR)
+ chmod a-x $(LIB_LIBDIR)/*
$(MAKE) DESTDIR=$(CURDIR)/debian/lesstif2-dev \
-C build/include/Motif-2.1 install
$(MAKE) DESTDIR=$(CURDIR)/debian/lesstif-doc \
@@ -101,10 +107,8 @@
{ \
cd debian/lesstif-bin; \
rm etc/X11/mwm/*; \
- mv usr/lib/X11/app-defaults etc/X11; \
- rmdir usr/lib/X11; \
- rmdir usr/lib; \
- cd ../..; \
+ mv $(LIBDIR)/X11/app-defaults etc/X11; \
+ rmdir $(LIBDIR)/X11 $(LIBDIR) usr/lib; \
}
for p in man1/uil.1 man1/ltversion.1 man1/mwm.1 man1/lesstif.1 \
man1/xmbind.1 man5/mwmrc.5 man5/VirtualBindings.5; do \
diff -u lesstif2-0.95.2/debian/control lesstif2-0.95.2/debian/control
--- lesstif2-0.95.2/debian/control
+++ lesstif2-0.95.2/debian/control
@@ -11,6 +11,8 @@
Package: lesstif2
Architecture: any
+Pre-Depends: multiarch-support
+Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends}
Conflicts: libmotif
Replaces: libmotif
@@ -22,6 +24,7 @@
Package: lesstif2-dbg
Architecture: any
+Multi-Arch: same
Section: debug
Priority: extra
Depends: lesstif2 (= ${binary:Version}), ${misc:Depends}
Bug#680427: Please add libjack alternative depends
Source: ia32-libs-i386 Version: 20120616 Severity: normal ia32-libs-i386 Depends: libjack0 But libjack0 conflicts with libjack-jackd2-0, so if you have libjack-jackd2-0 installed already, it is not easy to upgrade ia32-libs. We believe the dependency should really be libjack0 | libjack-jackd2-0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680074: subversion: Bad french translation in svn help pset
[Christian Bac] Id - résumé compacte des 4 libellés précédents. and in french it should be: Id - résumé compact des 4 libellés précédents. Compact should not have a e because resumé is male and not female. Fixed upstream: http://svn.apache.org/viewvc?view=revisionrevision=1356753 I also changed another instance in 'svnversion --help', Produit un 'numéro de version' compacte pour la copie de travail précisée which looks like the same error. I will patch the Debian package in a future release. Thanks! Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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#678203: svn-do: Fails with E: Not in a SVN checkout after subversion upgrade to 1.7.5
[Daniel Leidert] --- /usr/bin/svn-do.orig 2010-05-23 17:48:50.0 +0200 +++ /usr/bin/svn-do 2012-06-20 20:12:50.0 +0200 @@ -50,7 +50,7 @@ case $1 in esac done -if ! [ -d .svn ]; then +if ! `svn info /dev/null 21`; then echo E: Not in a SVN checkout 2 exit 1 fi That works, but the code is clearer if you omit the `` operators. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678203: [Svn-bp-devel] Bug#678203: svn-do: Fails with E: Not in a SVN checkout after subversion upgrade to 1.7.5
[Neil Williams] Frankly, the new subversion working copy structure is insane and will break hundreds of tools of all different kinds by removing the .svn directory. Hundreds of tools try to look inside the .svn directory? They shouldn't, and they never should've. The working copy format changed noticeably in svn 1.4, less noticeably in 1.5 and 1.6, and now with 1.7 it's another major change. Tools shouldn't try to frob the svn metadata directly, that's why we have libsvn_client, libsvn_wc, and the Perl/Python/Ruby/Java bindings to same. In the present case, I understand [ -d .svn ] was a handy way to tell you were in a wc, but it was still a hack and a layering violation. As for the insanity of moving away from the every subdir is its own independent checkout model: it caused many problems and I'm mostly not sorry to see it go. I will, however, miss the ability to copy or move a subdir in a larger working copy and treat it as its own wc with its own state. (In fact I'm thinking of writing a tool to do that.) Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679095: svn log segfaults on a certain path after svn upgrade
I had a checked out copy created by svn 1.6; after updating the subversion package to 1.7.5, it insisted on running svn upgrade, which I did. $ svn st ! gif/mobile Trying to run svn log on this directory causes svn to segfault: Huh. Can you reproduce this? I mean, do you have a backup of the old working copy from before 'svn upgrade', or can you recreate one? It seems clear that the 'svn upgrade' went wrong somehow. If you can't reproduce the problem easily, can you make your current working copy available to me or other Subversion developers? E.g., a tarball on an http server would be fine. From that we could probably figure out why 'svn log' crashes, and _maybe_ work backward to how 'svn upgrade' got the working copy into that state in the first place. Thanks for the report, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678664: subversion-tools: Where is svn2cl?
[Arthur de Jong] I'm the upstream author of svn2cl and also a Debian developer. I've filed an ITP for it (http://bugs.debian.org/678664) and I'll provide a package soon. Ah, thanks. (You mean bug #678676.) I know I pinged you about this several months ago, but I should have pinged you again when I actually uploaded Subversion 1.7. Since I've already added 'Recommends: svn2cl' to subversion-tools, I'm glad you're doing this. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650022: subversion: Disabling gnome-keyring does not work anymore
[Sven-Haegar Koch] $ svn ls https://svn.sdinet.de/src/kernel WARNING: gnome-keyring:: no socket to connect to ... (Of course this specific warning from the gnome-keyring library has since been fixed.) I have reason to believe this use of gnome-keyring may actually be caused by libneon27-gnutls and its use of Kerberos / GSSAPI, and not related to the Subversion 'gnome-keyring' module at all. To confirm or refute this, try to run Subversion with the 'serf' http/https backend instead of the 'neon' http/https backend: svn --config-option servers:global:http-library=serf (That is shorthand for editing ~/.subversion/servers, and in the [global] section, adding a line 'http-library=serf'.) If you see evidence of gnome-keyring using the serf backend, or using protocols other than http/https, then the problem must be elsewhere. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678224: subversion-1.7.5 source build fails on hppa due to svn_gnome_keyring version mismatch
BUILD/subversion/svn/svn --version /dev/null svn: E200019: Version mismatch in 'svn_gnome_keyring': found 1.6.17, expected 1.7.5 make: *** [debian/stamp-build-arch] Error 1 This means libsvn1 1.6.17 is installed in the build chroot. Uninstall libsvn1 and try again. This may or may not be something I can patch in the build system. I'll investigate when I get a chance. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539637: subversion: Please split package into *-client and *-server
tags 539637 wontfix thanks Please split the package into corresponding *-client and *-server packages. libapache2-svn is already a *-server package split out from subversion. It isn't named *-server but it is server code. Other than that, a split makes little sense: (a) Subversion is mostly library code; (b) Very little of the 3.9 MB 'subversion' package is either client- or server-specific; (c) We don't ship an init script or an inetd.conf line or anything, so the principle of don't install servers you do not wish to run does not apply; (d) The client libraries link to the server libraries, because a client is also the server in the case of a file:/// repository. Thus, splitting libsvn1 into client and server packages would be largely pointless. What would make more sense would be to move /usr/share/local/*/LC_MESSAGES/subversion.mo into the libsvn1 package. (I haven't checked if that's multi-arch-safe these days.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678346: subversion: svn no longer resolves symlinks (error E155010)
retitle 678346 subversion: 'svn log' output tricked by symlinks in some cases found 678346 1.1.0-1 notfound 678346 1.7.5-1 fixed 678346 1.7.5-1 thanks tl;dr I'm closing this because I believe it is a bugfix, not a bug. I'm marking it found in 1.1.0, not because I've tested it, but because that is when symlink support was added to svn. [Vincent Lefevre] svnadmin create svn svn co file://`pwd`/svn wc cd wc svn mkdir foo ln -s foo bar svn add bar touch foo/file svn add foo/file ... svn log bar/file svn: E155010: The node '/tmp/my-test-svn/wc/bar/file' was not found. In other words, 'svn log' is now more consistent between a working copy and a repository. Compare: svn log bar/file svn log file://`pwd`/svn/bar/file In 1.7, they both fail. In 1.6, one succeeds and one fails. I think the 1.7 behavior is clearer. There is no object in the repository named 'bar/file', and svn log no longer is fooled into reporting one. Also, links are not resolved at the end of the path. Compare 'svn log foo' with 'svn log bar'. In both 1.6 and 1.7, 'bar' is its own object with its own log, independent of what it points to. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621692: 621692
Since serf is now in SID, is it possible to push svn 1.7 ? That's my plan. I uploaded serf last weekend (as you noticed), and have been working on svn 1.7 this week, hope to upload 1.7.5 today or tomorrow. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644438: [libsvn-java] Add OSGi metadata to the java binding
[Jakub Adam] I see you are preparing a package for Subversion 1.6.18 in experimental. Would you please consider including the patch from #644438 [1] into the final upload? I'd like to finally package eclipse-subclipse before Wheezy is frozen. Actually 1.7.5 if I can manage it. I hope to work on that some more tonight, possibly finalize it. Regarding the OSGi patch, thanks for the reminder - and sorry I forgot to do this for the last upload. I'll get it into the next one. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664134: NMU that will hopefully fix the issue.
I just checked the build logs. Every buildd, plus my local amd64 build, used gzip 1.4-5. [Hilko Bengen] Strange. Does a rebuild produce different results? I just downloaded all the libgpm2 debs and compared them and you are right: the amd64 build (the one I uploaded) has a different md5sum on changelog.Debian.gz than all the other builds. After a bit of investigation, I found the culprit: my .bashrc sets 'GZIP=-9n --rsyncable'. And sure enough: when I gzip debian/changelog with and without --rsyncable, I get the two md5sums. ...But I build with cowbuilder. I did not expect cowbuilder / pbuilder to pass my $GZIP into the chroot. Oh well, I learn something new. So I've edited my cowbuilder wrapper script to 'unset GZIP'. I'll verify that this works, then re-upload a fake-bin-NMU as you suggested. Thanks for the report! Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664134: NMU that will hopefully fix the issue.
[Hilko Bengen] I am preparing an NMU to DELAYED/7 right now. You can find the changelog entry below. A binNMU would not work because it would break co-installability with a new changelog entry. In other words, any 'M-A: same' package that is _ever_ binNMU'd is broken. Argh. I just checked the build logs. Every buildd, plus my local amd64 build, used gzip 1.4-5. So why do you think a rebuild would fix this problem? What file caused the conflict, anyway? Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676808: override: libsvn-dev:libdevel/extra, libsvn-ruby:oldlibs/extra, libsvn-ruby1.8:oldlibs/extra
Package: ftp.debian.org Severity: normal libsvn-dev is not for use with a 'vcs' but is for _building_ software that uses a vcs. Thus I think 'libdevel' is more appropriate. libsvn-ruby and libsvn-ruby1.8 are now transition packages, not ruby packages, so I think they should go in 'oldlibs'. They also should probably be 'extra' for this reason. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676651: Please update Build-Depends: libgpm-dev
Package: dosemu Version: 1.4.0+svn.2010-1 Severity: minor Please update your Build-Depends sometime from libgpmg1-dev to libgpm-dev. After multiple releases as a dummy package, I've finally gotten around to dropping libgpmg1-dev entirely. I'm keeping a 'Provides' and of course I can keep it as long as I have to, but someday it would be nice to drop that too. -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-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-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653036: gpm: please default to /dev/input/mice instead of legacy /dev/psaux
[Stefan Lippers-Hollmann] I'd like to ask you to consider uploading the attached NMU diff or something equivalent Ah yes - sorry about that! I completely forgot that this hadn't been done yet. I will try to find time to do an upload in the next couple of days. Thanks for your patch! It looks good, though of course I'll want to test it. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#672157: subversion: update watch file for http://subversion.apache.org
[Petr Vorel] subversion site has been migrated to http://subversion.apache.org some time ago. Please update watch file (actually last version from old site is 1.6.18 - not sure if you're going to package it or if you take 1.7.4). Right, the 1.6 series is still hosted at subversion.tigris.org and always will be, so the watch file is still correct within that series. I will change the watch file when I get around to uploading a 1.7 release. (I don't plan to package 1.6.18, though I did generate a .orig.tar.gz file of it for the Ubuntu maintainer to use, just in case we package it later - no good having two different orig.tar.gz files in the wild.) Thanks, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666794: subversion: sourceful transition towards Apache 2.4
[Arno Töll] as promised lately I investigated the issue with your package manually now. The Debian version of subversion is not compatible with the new upstream release of Apache 2.4, subversion 1.7.4 however is [1]. Thanks for investigating and all that helpful information! Note, subversion is not compatible with the event MPM [3]. Our packaging guidelines [4] cover this situation and describe how to declare MPM conflicts and switch the enabled MPM on purpose. Yeah I knew about the event MPM (actually, it apparently works fine unless you use a bdb format repository, which very few people do these days) - but thanks for the link to how I can declare an MPM conflict. That will save me a little time when I finally find the time to upload svn 1.7.4. Soon, I hope. (But I've been saying soon, I hope for many months. I still need to find a few hours to concentrate on it. svn 1.7 packaging involves a lot of small issues to resolve.) Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669111: subversion: globs in groups should be matched in order of their appearance
[Friedrich Delgado] The problem is that the order of matches is non-deterministic since this monday for me (I can't see a relevant updated package, but it used to work before). I'm guessing this is the fault of apr 1.4.6, which randomizes hash table ordering for security reasons. (Some hash tables are populated by data controlled by untrusted users, and if the hash algorithm is deterministic, they can unbalance it to the point of DOSing the application.) That is just an educated guess, I haven't investigated yet. I agree with you that it seems like a useful feature to define some sort of ordering, whether it be from the file, or longest match. I'll bring it up with upstream and see what people think. Thanks, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668825: libsvn-dev: adds dependency on libsvn-private which makes subcommander uninstallable
reassign 668825 subcommander tags 668825 patch thanks [Robert Luberda] I guess subcommander uses some libsvn symbols that it shouldn't use, however I have no idea how to find which ones. That's why I'm reporting this bug against libsvn-dev. Good guess, but ... oooh. Interesting - I haven't seen this failure mode before. subcommander links to lots of Subversion libraries, including several it does not need (whole libraries are more or less 'private use'). Some of those, in turn, use some of these private symbols. At some point I stopped shipping .la files and .so symlinks for these private libraries, intending to not let you link to them at all, but I do still ship .a files for them, because if you need .a files at all, you need all of them. Thus it happened that subcommander ended up statically linking to the private libraries, and dynamically linking to everything else. I'm attaching a patch to subcommander 'configure.ac'. It builds. I haven't tested to see if subcommander runs properly, as I don't use it. Thanks! Peter --- a/configure.ac +++ b/configure.ac @@ -373,23 +373,11 @@ fi if test $SVN_MAJOR -ge 1; then SVN_LIBS_ALL=$SVN_LIBS -lsvn_client-1 -lsvn_wc-1 -lsvn_repos-1 - SVN_LIBS_ALL=$SVN_LIBS_ALL -lsvn_ra-1 -lsvn_ra_svn-1 -lsvn_ra_local-1 - SVN_LIBS_ALL=$SVN_LIBS_ALL -lsvn_fs-1 -lsvn_fs_fs-1 + SVN_LIBS_ALL=$SVN_LIBS_ALL -lsvn_ra-1 + SVN_LIBS_ALL=$SVN_LIBS_ALL -lsvn_fs-1 SVN_LIBS_ALL=$SVN_LIBS_ALL -lsvn_delta-1 -lsvn_diff-1 SVN_LIBS_ALL=$SVN_LIBS_ALL -lsvn_subr-1 - if test $SVN_MINOR -eq 4; then -SVN_LIBS_ALL=$SVN_LIBS_ALL -lsvn_ra_dav-1 - elif test $SVN_MINOR -ge 5; then -if test x$found_neon = xyes; then - SVN_LIBS_ALL=$SVN_LIBS_ALL -lsvn_ra_neon-1 -fi -if test x$found_serf = xyes; then - SVN_LIBS_ALL=$SVN_LIBS_ALL -lsvn_ra_serf-1 -fi -SVN_LIBS_ALL=$SVN_LIBS_ALL -lsvn_fs_util-1 - fi - fi if test x$goodsvn == xok; then
Bug#664300: [NMU] xsok: Helping to update to packaging format 3.0
[Jari Aalto] I'm planning to NMU with changes listed in previous mail's patch to help migrate away from deprecated dpatch. I don't understand the urgency to get away from dpatch (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646420#17 - I think Marga is right) but I suppose that's a question for the lintian maintainers. In any case, migrating away from dpatch is one thing, migrating to source format 3.0 and dh 9 is quite another. Please don't do the latter with my packages. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664311: [NMU] cplay: Helping to update to packaging format 3.0
[Jari Aalto] I'm planning to NMU with changes listed in previous mail's patch to help migrate away from deprecated dpatch. I don't understand the urgency to get away from dpatch (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646420#17 - I think Marga is right) but I suppose that's a question for the lintian maintainers. In any case, migrating away from dpatch is one thing, migrating to source format 3.0 and dh 9 is quite another. Please don't do the latter with my packages. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663424: please use a VCS and indicate it in debian/control
severity 663424 wishlist tags 663424 wontfix thanks please use a VCS to package equivs and document it in debian/control with the VCS-* lines. Severity normal? Really? Anyway, I'm not really interested. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#605090: Linux 3.2 in wheezy
[Brad Spengler] Frankly it makes more sense for me to offer .debs myself than to deal with a bureaucracy and non-standard kernel in Debian. It contains who-knows-what extra code, and I doubt anyone looked at any of it to see if it allows for some way to leak information I prevent against a vanilla kernel, or a way to bypass any other existing protection. I hope you aren't complaining that the Debian kernel team doesn't include your patch, and also complaining that Debian kernel team includes too many patches, in the same email. Probably that isn't what you tried to say, but that's kinda what it sounded like. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644438: Fwd: Re: Add OSGi metadata to the java binding
[Jakub Adam] upstream accepted my OSGi metadata patch for JavaHL and commited to trunk. Until this version is released and packaged, could you please add the attached file to debian/patches? Ah, yeah, I see, r1234864 upstream. Sure, I'll do the equivalent in my next upload, which I really really hope to have time to do this weekend (I've tried to find time for months, maybe I finally can). Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#621692: Status of 1.7 packaging
[Diego Fernández Durán] What's the state of Subversion 1.7 packaging for Debian? Is there any way in which I can help? I've just been really really short on time. I hope I can find time to get a 1.7 package uploaded this weekend. I will probably disable serf support on kFreeBSD until I can find time to fix that. That would be a useful thing to do, anyone looking for things to do: figure out why the serf 1.0 testsuite hangs on FreeBSD: https://buildd.debian.org/status/fetch.php?pkg=serfarch=kfreebsd-amd64ver=1.0.0-2stamp=1313651587 It is not Debian-specific; this same issue has been reported on other FreeBSD systems as well. I notice the FreeBSD Ports tree has serf 1.0, and did not patch for this issue, so either they don't run the testsuite at all, or it doesn't fail for them. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657304: subversion-tools: svn-bisect doesn't work if good_rev bad_rev
[Nicolas Bonifas] svn-bisect doesn't behave as expected if good_rev bad_rev (a subsequent svn-bisect bad command will select the wrong half of the suspucious revisions). Indeed. When I (re-)wrote it I assumed the only interesting case was to detect a regression (good bad). But 'good' and 'bad' are mere labels and sometimes perhaps it is more convenient to label the older rev as the 'good' one. I'll fix it. Thanks for the report. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#647545: svnserve: CRAM-MD5 authentication implementation is vulnerable to replay attack
Another detail I missed before: nowadays apr_generate_random_bytes() reads from urandom, not /dev/random, so this would not cause bug#285708 to come back. Right. Now that apr reads /dev/urandom, there doesn't seem to still be a need for this patch. I suppose I'll remove it in the next upload. (The famous 1.7 that I will eventually find time to finish.) Thanks for all your work in the Subversion BTS so far, Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646084: swaks: [PATCH] TZ calculation incorrect
Package: swaks
Version: 20100211.0-4
Tags: patch
The timezone field of RFC 822 date format is [+-]HHMM, whereas swaks
calculates it as hundredths-of-an-hour. So it is wrong any time the MM
field is nonzero. For example:
Timezone RFC822 swaks
---
Canada/Newfoundland -0230 -0250
Asia/Tehran +0330 +0350
Asia/Kathmandu+0545 +0575
Australia/Eucla +0845 +0875
Peter
--- swaks
+++ swaks
@@ -1946,7 +1946,8 @@
@l = gmtime($et);
} else {
my @g = gmtime($et);
-$o = (timelocal(@l) - timelocal(@g))/36;
+$o = (timelocal(@l) - timelocal(@g))/60;
+$o = int($o / 60)*100 + ($o%60)*($o 0 ? 1 : -1);
}
$G::date_string = sprintf(%s, %02d %s %d %02d:%02d:%02d %+05d,
(qw(Sun Mon Tue Wed Thu Fri Sat))[$l[6]],
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
