Bug#922823: possible fix
Possible fix: I tried adding the missing file arv-viewer.ui as follows: - Modify the source package aravis-0.6.0-1, adding the following line to debian/aravis-tools.install: usr/share/aravis-0.6/arv-viewer.ui - Rebuild the aravis-tools binary package. The modified package contains "arv-viewer.ui", and I can now succesfully use the command "arv-viewer". Kind regards, Joris.
Bug#922823: aravis-tools: arv-viewer fails to start due to missing file arv-viewer.ui
Package: aravis-tools Version: 0.6.0-1 Severity: important Hello, The program "arv-viewer" in package "aravis-tools" fails to start because it can not find "arv-viewer.ui". For example: joris@host:~$ arv-viewer (arv-viewer:16676): Aravis-ERROR **: 08:52:58.292: Cant't load user interface file: Failed to open file “/usr/share/aravis-0.6/arv-viewer.ui”: No such file or directory Trace/breakpoint trap Indeed the file "arv-viewer.ui" is not included in the "aravis-tools" package. I believe this makes the program completely unusable. Kind regards, Joris van Rantwijk -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages aravis-tools depends on: ii libaravis-0.6-0 0.6.0-1 ii libatk1.0-0 2.30.0-2 ii libaudit1 1:2.8.4-2 ii libc6 2.28-7 ii libcairo-gobject2 1.16.0-2 ii libcairo2 1.16.0-2 ii libgdk-pixbuf2.0-0 2.38.0+dfsg-7 ii libglib2.0-02.58.3-1 ii libgstreamer-plugins-base1.0-0 1.14.4-1 ii libgstreamer1.0-0 1.14.4-1 ii libgtk-3-0 3.24.5-1 ii libnotify4 0.7.7-4 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libusb-1.0-02:1.0.22-2 ii libxml2 2.9.4+dfsg1-7+b3 ii zlib1g 1:1.2.11.dfsg-1 aravis-tools recommends no packages. aravis-tools suggests no packages. -- no debconf information
Bug#547339: New upstream release 3.2.14
Hello, I second the request to upgrade, to Linux-GPIB 3.2.14 please. The current version of gpib-modules-source-3.2.11-2 does not compile against recent kernels. This is increasingly a problem, because modern hardware often requires a recent Linux kernel (for network driver, video card, etc.). Upgrading will also be necessary to make this package usable in Debian squeeze. Upgrading would probably fix #550932. I already upgraded the package to Linux-GPIB 3.2.14 for my own use. Only minimal changes to the Debian packaging were needed. You could use my package as a starting point if you like. See http://www.xs4all.nl/~rjoris/debian/gpib/ Joris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#562761: kpicosim: Assembler confuses constant with register
Package: kpicosim Version: 0.6a-1 Severity: important The built-in assembler in kpicosim may generate incorrect code when the PicoBlaze program uses constant names starting with an 's'. When the first two letters of the name of a constant match the name of a register, the assembler uses that register instead of the constant. For example, the following program: constant scratch, 08 load s1, scratch should be assembled into: 00108 ( load s1, scratch ) but kpicosim incorrectly generates: 011C0 ( load s1, sC ) Joris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543272: audacious: incorrectly depends on dbus-x11
The policy manual says: "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality." If I start audacious without D-Bus, I do not see errors but I do see a music player that provides a satisfactory amount of functionality. I fruitlessly grepped the audacious source for "dbus-launch", which is the only feature provided by the package dbus-x11. So even if the dependency on dbus would be correct, the dependency on dbus-x11 remains questionable. Example from another package: xpdf requires lpr to print documents, yet it does not depend on lprng or cups or whatever. This is a good thing because there is a subset of xpdf's full functionality which is useful to me and does not require lpr. I'll rest my case. If I failed to convince you, I will just go install dbus-x11 and learn to live with it. ;) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#543272: audacious incorrectly depends on dbus-x11
Package: audacious Version: 2.1-1 Severity: minor Hello, I noticed that the new audacious package depends on dbus and dbus-x11. This is not correct. Audacious in fact works fine without dbus. Probably there is some advanced functionality in audacious which requires dbus. But the core package works and does everything I want from it. So why would I want to run a D-Bus? Maybe the Recommends or Suggests fields should be used instead of Depends. Greetings, Joris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540622: mp3gain manpage outdated
Package: mp3gain Version: 1.5.1-1 Severity: wishlist Tags: patch Recent versions of mp3gain have an option to write gain information in ID3v2 format instead of APEv2 format. This option is not yet documented in the manpage. Also, the manpage could more clearly explain the two ways of working with mp3gain: changing the encoded stream versus writing replaygain tags. Attached is a copy of the manpage with my suggested changes. Greetings, Joris. manpage.1'. You may view the manual page with: `docbook-to-man manpage.sgml | nroff -man | less'. A typical entry in a Makefile or Makefile.am is: manpage.1: manpage.sgml docbook-to-man $< > $@ The docbook-to-man binary is found in the docbook-to-man package. Please remember that if you create the nroff version in one of the debian/rules file targets (such as build), you will need to include docbook-to-man in your Build-Depends control field. --> STEFAN"> FRITSCH"> February 4, 2004"> 1"> s...@sfritsch.de"> MP3GAIN"> Debian"> GNU"> LGPL"> ]> &dhemail; &dhfirstname; &dhsurname; 2004 Glen Sawyer and &dhusername; &dhdate; &dhucpackage; &dhsection; &dhpackage; lossless mp3 normalizer &dhpackage; options infile infile 2 ... DESCRIPTION This manual page documents briefly the &dhpackage; command. This manual page was written for the &debian; distribution because the original program does not have a manual page. &dhpackage; can analyze and adjust mp3 files so that they have the same volume. &dhpackage; does not just do peak normalization, as many normalizers do. Instead, it does some statistical analysis to determine how loud the file actually sounds to the human ear. Also, the changes &dhpackage; makes are completely lossless. There is no quality lost in the change because the program adjusts the mp3 file directly, without decoding and re-encoding. &dhpackage; optionally writes gain adjustments directly into the encoded data. In this case, the adjustment works with all mp3 players, i.e. no support for a special tag is required. This mode is activated by any of the options -r, -a, -g, or -l. If none of the above options are given, the recommended gain change is instead written to a special tag in the mp3 file. In this case, the adjustment only works with mp3 players that support this tag. Some mp3 players refer to this as ReplayGain. The tag is written either in APEv2 format (default) or in ID3v2 format (with -s i). If you only want to print the recommended gain change (and not modify the file at all) you may use the -s s (skip tag) option. The method mp3gain uses to determine the desired volume is described at http://www.replaygain.org/";>www.replaygain.org. See also /usr/share/doc/mp3gain/README.method . OPTIONS -? -h Show summary of options. -g i apply gain i to mp3 without doing any analysis -l 0 i apply gain i to channel 0 (left channel) of mp3 without doing any analysis (ONLY works for STEREO mp3s, not Joint Stereo mp3s) -l 1 i apply gain i to channel 1 (right channel) of mp3 without doing any analysis (ONLY works for STEREO mp3s, not Joint Stereo mp3s) -r apply Track gain automatically (all files set to equal loudness) -k automatically lower Track gain to not clip audio -a apply Album gain automatically (files are all from the same album: a single gain change is applied to all files, so their loudness relative to each other remains unchanged, but the average album loudness is normalized) -m i modify suggested MP3 gain by integer i -d n modify suggested dB gain by floating-point n -c ignore clipping warning when applying gain -o output is a database-friendly tab-delimited list -t mp
Bug#513218: Unlimited retrying of DNS lookups
Package: sysklogd Version: 1.5-5 When syslogd is configured to send messages to a remote target, and initial DNS lookup of the target host name fails, the lookup will be retried later. The intention has clearly been to retry DNS lookups a limited number of times, and with some time between the attempts. However, the logic of this retry mechanism is flawed. There is effectively no delay between retry attempts. Also, under certain conditions, the number of retry attempts is effectively unlimited. These bugs have bad consequences for a system with broken DNS and remote logging enabled. For every logged message, syslogd will try a DNS lookup and wait until timeout. This slows syslogd down to a crawl. Once socket buffers start to fill up, the clients of syslogd also stall and the system becomes almost unusable. This bug applies to sysklogd 1.5-5 (lenny) as well as 1.4.1-18 (etch). Bugs: 1) syslogd.c, line 1797: Host name lookups are retried only when INET_SUSPEND_TIME has passed since "f->f_time". But once the suspend time has passed, if the first retry attempt fails, f_time is not reset. Therefore, the next log message will immediately cause a second retry, and so on. 2) syslogd.c: The number of retry attempts left is maintained in f->f_prevcount. However, this variable is also used to count the number of duplicate log messages. It is thus possible to keep increasing f_prevcount by sending duplicate messages at a sufficient rate. In this case, syslogd will continue to retry the DNS lookup indefinately. Proposed solution: * Reset the retry delay time after a retry attempt has failed. * Use separate variables for retry time and retry count instead of re-using variables that were created for a different purpose. Joris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513217: Syslogd may deadlock on SIGTERM
Package: sysklogd Version: 1.5-5 Syslogd is vulnerable to a race condition where SIGTERM triggers a futex deadlock, freezing the syslogd process. To demonstrate the bug, I will assume that syslogd is configured to send log messages to a remote target, and also that the DNS server is not responding. Neither condition is necessary, but they make the race condition much more likely. If initial lookup of the remote host name fails, syslogd will retry the lookup later. If a SIGTERM comes in during a retried lookup, this may result in a recursive call to gethostbyname(), causing a futex deadlock inside libc. This bug is related to bug #301511. Even if remote logging is not enabled, SIGTERM may still cause a deadlock through a recurvise call to ctime(), similar to #301511. This bug applies to sysklogd 1.5-5 (lenny) as well as 1.4.1-18 (etch). Steps to reproduce: * Ensure DNS lookups will timeout, e.g. set up an iptables entry to drop all DNS responses. * Put a remote target in /etc/syslog.conf: *.* @aap.noot.com * Start syslogd and monitor with strace. * Observe how initial host name lookup fails. * Wait 180 seconds for the lookup retry mechanism to activate. * Send a message to syslog: "logger blah". Syslogd will retry the host name lookup, waiting for a DNS response in a "poll" system call. * While syslogd is waiting for a DNS response, send SIGTERM. * Observe how syslogd walks into futex() and never recovers. Proposed solution: * Extend the sigprocmask() mechanism to block SIGTERM in addition to SIGHUP and SIGALRM. Joris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509724: ghc does not compile programs using Data.IntSet
Package: ghc6 Version: 6.8.2-7 Severity: important GHC apparently can no longer compile programs that use the package Data.IntSet. A few months ago, this used to work just fine with GHC (lenny). Example Haskell program: import Data.IntSet main = let q = empty in do if notMember 3 q then print "a" else print "b" $ ghc aaa.hs aaa.o: In function `szF_info': (.text+0x192): undefined reference to `containerszm0zi1zi0zi1_DataziIntSet_notMember_closure' aaa.o: In function `szF_info': (.text+0x199): undefined reference to `containerszm0zi1zi0zi1_DataziIntSet_empty_closure' aaa.o: In function `szF_info': (.text+0x247): undefined reference to `__stginit_containerszm0zi1zi0zi1_DataziIntSet_' aaa.o: In function `syF_closure': (.data+0x38): undefined reference to `containerszm0zi1zi0zi1_DataziIntSet_notMember_closure' aaa.o: In function `syF_closure': (.data+0x3c): undefined reference to `containerszm0zi1zi0zi1_DataziIntSet_empty_closure' collect2: ld returned 1 exit status The program runs fine with ghci. Name VersionDescription +++-==-==- ii gcc4:4.3.2-2 The GNU C compiler ii ghc6 6.8.2-7GHC - the Glasgow Haskell Compilation system ii libc6 2.7-16 GNU C Library: Shared libraries Target: i486-linux-gnu / Linux 2.6.27.3-amd64 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#497664: modules fail to build with non-standard linux source directory
Sure I'm fine with waiting until after Lenny. However, the reason for distributing a module source package is to support compiling against a non-standard kernel. So the fact that it works with the standard Debian kernel is of little relevance. Joris. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#497664: modules fail to build with non-standard linux source directory
Package: comedi-source Version: 0.7.76+20080817cvs-1 The build process for the comedi modules appears to ignore the KSRC environment variable. I suggest adding "--with-linuxdir=$(KSRC)" to the invocation of ./configure in debian/rules. jorisvr:/data/comedi/modules/comedi$ KSRC=/data/linux-2.6.22.6 fakeroot debian/rules binary-modules ... checking for Linux build in /lib/modules/2.6.22.6/build... not found checking for Linux build in ../linux... not found checking for Linux build in /usr/src/linux... not found configure: error: Linux build directory not found make: *** [binary-modules] Error 1 Also, the modules do not build against a kernel configured without PCMCIA support. I suggest removing "--enable-pcmcia" from the invocation of ./configure. (It seems that this option is automatically enabled anyway if CONFIG_PCMCIA is detected.) checking Linux config option CONFIG_PCMCIA... no configure: error: Kernel does not support PCMCIA or its API is not supported by Comedi System: Debian 4.0, i386, Linux 2.6.22.6 SMP Thanks, Joris. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419021: Incorrect handling of empty CDATA sections by XML::LibXML::SAX
Package: libxml-libxml-perl
Version: 1.59-2
When XML::LibXML::SAX encounters an empty CDATA section while parsing an
XML file, it will sometimes call the "characters" method of the SAX
handler with an empty hash value as argument. This is wrong, and breaks
XML::RSS::Parser.
When the parser sees , it calls
$handler->characters( { } );
This is wrong. It should either call
$handler->characters( { Data => "" } );
or not call the method at all.
Sample program:
--
use XML::LibXML::SAX;
use strict;
use warnings;
package a;
sub new($) { return bless { }; }
sub characters($$) { my ($s, $d) = @_; print "'$d->{Data}'\n"; }
my $p = XML::LibXML::SAX->new(Handler => a->new());
$p->parse_string(' ');
--
Running the sample program results in:
Use of uninitialized value in concatenation (.) or string at libxmlbug.pl line
7.
Greetings,
Joris.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#230844: libxml-parser-perl: Perl XS code apparently results in 'free unreferenced scalar' error
I believe this bug still exists, but is not specific to
libxml-parser-perl. I can reproduce it now (on Debian sarge)
without making any reference to XML::Parser.
The error message I get is slightly different from the original
report, but so similar that I feel it must be the same thing:
Undefined subroutine &main::foo called at ./test_program line 7.
Attempt to free unreferenced scalar: SV 0x8160bec.
This output comes from running the same test_program
(see original post) with the following test_library
(replacing test_library from original post):
--
# test_library
package Fred;
sub new {
my ($class, %args) = @_;
my $handlers = $args{Key};
bless $handlers;
}
sub parse {
my ($self, $s) = @_;
$self->{'/a'}->($self, 'Fred::Foo'->bar($self));
}
package Fred::Foo;
sub bar {
my $class= shift;
}
sub children {
my $elt= shift;
}
1;
--
Tested on:
Debian 3.1 stable/sarge
Kernel: Linux 2.6.16.2 i686
perl 5.8.4-8sarge4
perl-base 5.8.4-8sarge4
I think this bug should thus be reassigned to the perl package.
Joris.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378411: Buffer overflow in XML::Parser::Expat triggered by utf8
On Sat, 2006-08-05 at 14:12 -0400, Joey Hess wrote:
> Would just calling Encode::decode_utf8 on the input string in Expat.pm
> be the simplest fix?
I'm not sure, but I think not.
First of all, in the case I reported, the parser reads directly from an
input stream. The data is then not touched by Expat.pm, but handled
internally in Expat.xs.
It seems to me that the reported overflow can not be triggered in the
case where a string (as opposed to a stream) is passed to XML::Parser.
It also seems to me that XML parsing on a string will proceed correctly
regardless of whether the string is logical Unicode or raw UTF8, since
both kinds of strings are essentially the same at the level of Perl
internals.
Secondly, the cause of the reported stream parsing problem is not that
Expat does not handle UTF8 data; it handles that fine. The problem is
that it *expects* raw UTF8 bytes but, in my case, gets logical Unicode
characters instead. It breaks on that because of an invalid assumption
in the buffer management code.
I dived into Expat.xs again and believe I have a simple fix that stops
the buffer management from overflowing the heap. Due to Perl's identical
internal treatment of utf8 and Unicode, this should be all that is
necessary to enable correct parsing of Unicode streams.
My patch is attached.
Basic testing suggests that it works as intended. But I have very little
experience with Perl XS coding, so I would recommend that somebody
reviews this before it is applied anywhere.
Thanks for pushing this forward a bit; we should get it fixed.
Joris.
PS. (and slightly off-topic) My personal opinion is that Perl has
utterly messed up Unicode handling. The documentation uses the terms
"Unicode" and "UTF8" as if they were interchangable. In fact, and as we
see with this bug, there is a very important conceptual difference
between "a string containing N raw utf8 bytes" and "a string containing
M logical Unicode characters".
--- XML-Parser-2.34/Expat/Expat.xs.orig 2003-07-28 16:41:10.0 +0200
+++ XML-Parser-2.34/Expat/Expat.xs 2006-08-07 10:37:40.0 +0200
@@ -289,11 +289,10 @@
SV * tbuff;
SV * tsiz;
char * linebuff;
STRLEN lblen;
STRLEN br = 0;
- int buffsize;
int done = 0;
int ret = 1;
char * msg = NULL;
CallbackVector * cbv;
char *buff = (char *) 0;
@@ -334,37 +333,31 @@
&& strnEQ(++chk, cbv->delim + 1, cbv->delimlen - 1))
lblen -= cbv->delimlen + 1;
}
PUTBACK ;
-buffsize = lblen;
done = lblen == 0;
}
else {
tbuff = newSV(0);
tsiz = newSViv(BUFSIZE);
-buffsize = BUFSIZE;
}
while (! done)
{
- char *buffer = XML_GetBuffer(parser, buffsize);
-
- if (! buffer)
- croak("Ran out of memory for input buffer");
+ char *buffer, *tb;
SAVETMPS;
if (cbv->delim) {
- Copy(linebuff, buffer, lblen, char);
+ tb = linebuff;
br = lblen;
done = 1;
}
else {
int cnt;
SV * rdres;
- char * tb;
PUSHMARK(SP);
EXTEND(SP, 3);
PUSHs(ioref);
PUSHs(tbuff);
@@ -382,18 +375,26 @@
if (! SvOK(rdres))
croak("read error");
tb = SvPV(tbuff, br);
- if (br > 0)
- Copy(tb, buffer, br, char);
- else
+ /* br == number of bytes read from stream
+ Note that it is possible that br > BUFSIZE if the input stream
+ is decoding a non-ASCII source. */
+ if (br <= 0)
done = 1;
PUTBACK ;
}
+ buffer = XML_GetBuffer(parser, br);
+ if (! buffer)
+ croak("Ran out of memory for input buffer");
+
+ if (br > 0)
+Copy(tb, buffer, br, char);
+
ret = XML_ParseBuffer(parser, br, done);
SPAGAIN; /* resync local SP in case callbacks changed global stack */
if (! ret)
Bug#378412: Buffer overflow in XML::Parser::Expat triggered by deep nesting
Package: libxml-parser-perl
Version: 2.34-4
Severity: grave
A heap overflow in the Expat library wrapper can be triggered by
XML input with deeply nested elements. This bug has also been reported
to CPAN: http://rt.cpan.org/Ticket/Display.html?id=19860
The error is caused at libxml-parser-perl-2.34/Expat/Expat.xs, line 498:
if (cbv->st_serial_stackptr >= cbv->st_serial_stacksize) {
unsigned int newsize = cbv->st_serial_stacksize + 512;
Renew(cbv->st_serial_stack, newsize, unsigned int);
cbv->st_serial_stacksize = newsize;
}
cbv->st_serial_stack[++cbv->st_serial_stackptr] = cbv->st_serial;
Note that in the case that stackptr == stacksize-1, this code
decides to NOT expand the stack and subsequently writes a value
just outside the allocated buffer.
Because the buffer is overflowed by only 4 bytes, this does not cause
a segmentation fault. But the overflow is detected by Valgrind when
parsing an XML file with elements nested deeper than 512 levels.
Since it involves an input-triggered heap overflow, this is technically
a security vulnerability.
Joris.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378411: Buffer overflow in XML::Parser::Expat triggered by utf8
Package: libxml-parser-perl
Version: 2.34-4
Severity: grave
A heap overflow can be triggered in the Expat library wrapper
when running on an input stream in non-raw mode. This bug has
also been reported at CPAN:
http://rt.cpan.org/Ticket/Display.html?id=19859
The following example program will crash with a segmentation fault
on certain input:
--
use strict;
use encoding 'utf8';
use XML::Parser;
my $parser = XML::Parser->new();
$parser->parse(\*STDIN);
--
The following program generates example input on which the above
program crashes:
--
binmode(STDOUT, ':bytes');
print "\n";
for (my $i = 0; $i < 4; $i++) { print chr(0xc3) . chr(0xa9); }
print "\n\n";
--
The overflow occurs in libxml-parser-perl-2.34/Expat/Expat.xs, line 388:
Copy(tb, buffer, br, char)
At this point, the Expat wrapper assumes that the number of bytes
copied (br), can not exceed the number of characters read from the
input (buffsize). This assumption is incorrect if the input stream is
in a non-raw mode.
The best solution is to have the Perl programmer set the stream
to raw mode, since libexpat expects raw bytes anyway. In the example
program above, this could be accomplished either by removing the
statement "use encoding 'utf8'" or by adding the statement
"binmode(STDIN,':bytes')".
I think, however, that a segmentation fault is not a good way
to inform a Perl programmer that he made a mistake. So this
buffer overflow must still be fixed.
Since it involves an input-triggered heap overflow, this is
technically a security vulnerability.
Joris.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
