Package: cdrdao
Version: 1.1.9-3
Tags: security
Severity: important
From the new upstream 1.2.0 ChangeLog:
o SECURITY FIX: cdrdao now gives up its root privileges after setting
up real-time scheduling, as well as before saving settings through
the --save option. This fixes a potential
I don't know if this is related, but using 6.9.0.dfsg.1-2 on amd64
2.6.14 and 2.6.15 systems, I have a similar lockup if the *glx* module
is enabled. Forcing the AGPMode appears to help. My particular card is
a 9200 (non-SE). I've also had two reports of this helping on 9600
cards. In Section
This fix appears to take care of the FTBFS on amd64. I have no idea if
the resulting binaries work though.
diff -Naur bochs-2.2.5.orig/debian/rules bochs-2.2.5/debian/rules
--- bochs-2.2.5.orig/debian/rules 2006-01-12 11:34:24.077308341 +0100
+++ bochs-2.2.5/debian/rules2006-01-12
This bug is actually known since 3 years - c.f. #157084. A fix has
been available for more than a year in #277276. Now, that fix might not
be acceptable for some unknown reason, but I personally never heard
anything on this matter from the maintainer. Is Eterm in effect
orphaned?
-ukh
This is a small fix for handling a number of FTBFS problems in scsilib.
The patch is against cdrdao 1:1.1.9-3. It should take care of:
249634 i386 using amd64 kernel
250031 s390 using s390x kernel
304194 build on ppc64
249642 build on amd64
326472
Package: slimp3
Version: 4.2.6-2
Severity: wishlist
The Debian distributed source of slimp3 contains the following binaries:
bin:
total 20
drwxr-xr-x 2 501 99 4096 Oct 7 2003 MSWin32-x86-multi-thread
drwxr-xr-x 2 501 99 4096 Oct 7 2003 darwin
drwxr-xr-x 2 501 99 4096 Oct 7 2003
Package: pearpc
Version: 0.3.1-4
Severity: wishlist
Adding amd64 to the Architecture line, pearpc 0.3.1-4 builds and runs
out of the box on amd64. I have successfully installed, booted and run
Apple Darwin 7.01, including the shipped X server. The only gotcha is
that since there's no JIT for
kaffe 1.1.4.PRECVS8-2 still leaves dangling symlinks, although the man
ones seems to be taken care of. Unfortunately, this breaks some
buildds. From a pbuilder environment:
visionary:/# dpkg -l kaffe kaffe-pthreads
Desired=Unknown/Install/Remove/Purge/Hold
|
I'm sorry, but my previous posting about dangling symlinks were not
accurate and most probably due to a mishap in my pbuilder environment.
Please disregard.
-ukh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Mon, Mar 21, 2005 at 12:23:58PM +0100, Arnaud Vandyck wrote:
Mon, 21 Mar 2005 11:48:18 +0100,
Kaare Hviid [EMAIL PROTECTED] wrote:
I'm sorry, but my previous posting about dangling symlinks were not
accurate and most probably due to a mishap in my pbuilder environment.
Please
Package: python-simpy
Version: 1.5.1-1
Severity: important
Tags: patch
python-simpy 1.5.1-1 suffers FTBFS in pbuilder due to a missing
dependency on python:
dpkg-source: building python-simpy in python-simpy_1.5.1-1.dsc
debian/rules build
dh_testdir
touch configure-stamp
dh_testdir
python
On Mon, 2005-03-21 at 22:02 -0800, Steve Langasek wrote:
However, the package could build-depend on libkrb5-dev instead. Or, it
could drop the build-conflict and build-depend on heimdal-dev, but be fixed
to not enable support for the deprecated, never-standardized krb4 POP
protocol.
Kerberos
On Tue, Mar 22, 2005 at 03:16:39PM +1000, Dave Whitla wrote:
Jeroen van Wolffelaar wrote:
This will happen post-sarge, amd64 will not get released with sarge, and
adding it to sid now would only cause more work that can better be spent
elsewhere (read: releasing sarge).
--Jeroen
severity 273525 serious
retitle 273525 ldmud: FTBFS: remove bison dependency
tags 273525 patch
thanks
From an i386 pbuilder:
./make_func lang
checking default anonymous rules in bison -y
lang.y:4.6-23: warning: type clash on default action: p !=
...good, it can handle them.
bison -y -d -v
So far, we still have not seen XView actually *working* on amd64, why I
*suggest* the same treatment for amd64 as with ia64:
diff -Naur jove-4.16.0.65/debian/control jove-4.16.0.65.fixed/debian/control
--- jove-4.16.0.65/debian/control 2005-03-22 13:33:48.756683017 +0100
+++
Actually, I also thought it was strange that XView was supported on the
alpha but no other 64-bit architecture, and had a brief look at it some
time ago. However, it seemed to be more than just plain 64-bit issues,
but also how messages were passed around in the system. The alpha port
has some
reopen 253521
tags 253521 patch
thanks
xmpi still suffers FTBFS on amd64. This appears to do the trick, but
I'm not sure if it's the Right Thing to do. Kurt?
diff -Naur xmpi-2.2.3b8/debian/control xmpi-2.2.3b8.fixed/debian/control
--- xmpi-2.2.3b8/debian/control 2005-03-23 11:20:25.202691164
Package: perl
Version: 5.8.4-7
Severity: serious
perl will suffer FTBFS if the kernel revision at build-time of the
previously installed perl does not match the current one. Log from a
pbuilder:
sh mv-if-diff configpm.tmp lib/Config.pm
./miniperl -Ilib lib/lib_pm.PL
Extracting lib.pm (with
severity 298336 important
retitle 298336 cvsutils: FTBFS: aclocal-1.8: command not found
thanks
cvsutils suffers FTBFS on all platforms if automake1.8 isn't installed.
-ukh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: distcc
Version: 2.18.3-1
Severity: serious
Tags: patch
distcc suffers FTBFS on alpha and amd64:
x86_64-linux-gcc -DHAVE_CONFIG_H -D_GNU_SOURCE -I./src -DSYSCONFDIR=\/etc\
-DPKGDATADIR=\/usr/share/distcc\ -Isrc -I./lzo -g -O2 -W -Wall -Wimplicit
-Wshadow -Wpointer-arith -Wcast-align
Package: svn-workbench
Version: 1.0.0-1
Severity: serious
svn-workbench 1.0.0-1 suffers FTBFS in pbuilder:
/usr/bin/make -C WorkBench/Source -f linux.mak wb_version.py \
PYTHON=python \
PYCHECKER_DIR=/tmp/buildd/svn-workbench-1.0.0 \
Package: evolution
Version: 2.0.3-1
Severity: important
While looking for reverse-dependencies of the krb4 package to consider
whether it can be removed from testing to fix an RC bug, I found that the
evolution binaries on i386 are linked against libkrb5-17-heimdal and
Package: xnap-snapshot
Version: 2.4-pre6-cvs1-1
Severity: serious
xnap-snapshot 2.4-pre6-cvs1-1 suffers FTBFS in pbuilder. This is from
an i386 log:
/usr/bin/make jar
make[1]: Entering directory `/tmp/buildd/xnap-snapshot-2.4-pre6-cvs1'
rm -rf /tmp/root/xnap
mkdir -p /tmp/root/xnap
jikes -q
severity 300265 wishlist
thanks
OK, it looks like it's due to a missing Build-Depends on a suitable JDK.
Since it's basically a mess that I can't really see through, and the
policy on the use and abuse of proprietary JDKs eludes me, I'll just
drop this to wishlist.
-ukh
--
To UNSUBSCRIBE,
Package: ttf-mgopen
Version: 1.0-1
Severity: serious
Tags: patch sid
From a pbuilder log:
dh_installdocs
dh_installdefoma
make: dh_installdefoma: Command not found
make: *** [binary-indep] Error 127
pbuilder: Failed autobuilding of package
- Aborting with an error
Missing dependency:
diff
Package: catalog
Version: 1.03-9
Serverity: normal
Tags: patch sid
If the build environment is already running a MySQL server, buildd and
pbuilder builds will FTBFS since catalog has a Build Dependency on
mysql-server. It is apparently not used at all during build time, why
it would be helpful
retitle 304434 bb: segfaults on amd64 and alpha (patch attached)
thanks
I can confirm that bb crashes on alpha too in the same way as on amd64,
thus indeed rendering this RC. Len's patch solves this issue on alpha
too.
-ukh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
On Wed, 2005-04-13 at 13:35 +0200, Helge Kreutzmann wrote:
Hello,
as you might have noticed, a very similar bug was opened 6 years ago
(bug number one order of magnitude lower than current). Unfortunately
I don't have access to an testing/unstable alpha right now.
Falk: Can you confirm
On Wed, 2005-04-13 at 15:36 -0700, Corey Hickey wrote:
Helge Kreutzmann wrote:
Hello,
as you might have noticed, a very similar bug was opened 6 years ago
(bug number one order of magnitude lower than current). Unfortunately
I don't have access to an testing/unstable alpha right now.
tags 304408 patch
thanks
This appears to take care of the issue:
diff -Naur ia32-libs-1.1/debian/rules ia32-libs-1.1.fixed/debian/rules
--- ia32-libs-1.1/debian/rules 2005-04-12 11:40:01.0 +0200
+++ ia32-libs-1.1.fixed/debian/rules2005-04-14 11:04:46.017973835 +0200
@@ -65,6 +65,7
I cannot reproduce the reported crash, but given that
1) it appears from the debian-amd64 mailing list to have something to
do with the daytime service,
2) time() is incorrectly declared, which generally causes major problems
on all 64-bit archs,
could you please try out this patch and report
tags 298601 patch
thanks
OK, inetd indeed crashes if:
1) running on amd64
2) daytime is enabled
It can easily be reproduced on the affected system with telnet
localhost daytime. The patch I sent appears to take of the problem.
-ukh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
Package: daapd
Version: 0.2.3d-4
Severity: minor
Tags: patch
The init.d script won't restart correctly.
diff -Naur daapd-0.2.3d/debian/init.d daapd-0.2.3d.fixed/debian/init.d
--- daapd-0.2.3d/debian/init.d 2005-01-11 09:14:54.0 +0100
+++ daapd-0.2.3d.fixed/debian/init.d2005-01-11
Package: xfonts-artwiz
Version: 1.3-1
Tags: patch
FTBFS in pbuilder environment since bzip2 is missing in control.
diff -Naur xfonts-artwiz-1.3/debian/control
xfonts-artwiz-1.3.fixed/debian/control
--- xfonts-artwiz-1.3/debian/control2005-01-19 12:33:55.798788534 +0100
+++
OK, here's a fix for amd64 and more for apt-build. However, I don't
really like it, since:
1) Both i386 and amd64 will still break when gcc-3.4 is introduced as
default compiler.
2) As someone suggested, the Debian architecture specific stuff should
probably be resolved at build-time rather than
Package: spell
Version: 1.0-12
Severity: minor
This does not work:
echo hello dummy; echo hello dummy2; spell -d dummy dummy2
it yields:
spell: option argument not given
This is because of a now forgotten change in getopt_long().
Also, the '-d/--dictionary' option is
Package: werken.xpath
Version: 0.9.4-3
Severity: important
FTBFS using kaffe 1.1.4.PRECVS6-1. pbuilder log:
# copmile from source
cd src jikes -d ../classes -classpath
/usr/lib/kaffe/lib/rt.jar:/usr/share/java/jdom.jar:/usr/share/java/xerces.jar:/usr/share/java/antlrall.jar:.
`find . -name
Package: smail
Version: 3.2.0.115-6
Severity: important
Tags: patch
smail suffers FTBFS on amd64 due to a bad errno declaration:
gcc -DSTATIC=static -O2 -I/usr/include addlink.o addnode.o domain.o
local.o main.o mapit.o mapaux.o mem.o parse.o printit.o -o pathalias -lresolv
-lresolv
Still suffers FBTFS in pbuilder:
dh_python: Python is not installed, aborting. (Probably forgot to Build-Depend
on python.)
make: *** [binary-indep] Error 1
pbuilder: Failed autobuilding of package
Adding python to the Build-Depends-Indep seems to do the trick.
-ukh
--
To UNSUBSCRIBE,
Sami is probably correct with regards to 32 bit code in the SHA-1
implementation - this little patch *appears* to fix the SHA-1 PRNG on
amd64. However, somebody with deeper understanding than me should
probably do some proper tests on it. (Thanks for the report, Sami, I've
been blindly using APG
On Mon, May 28, 2007 at 09:41:40AM +0200, Brice Goglin wrote:
About 2 years ago, you reported (or replied to) a bug in the Debian BTS
regarding a lock up of the server when running Xorg 6.9 on an Radeon
9200 board. Did any of you guys reproduce this exact same problem
recently? With Xorg/Etch?
On Wed, Jun 20, 2007 at 05:15:10PM +0200, Marc Haber wrote:
On Mon, Mar 19, 2007 at 12:27:41PM +0100, Kaare Hviid wrote:
diff -Naur apg-2.2.3.dfsg.1/sha/sha.c apg-2.2.3.dfsg.1.fixed/sha/sha.c
--- apg-2.2.3.dfsg.1/sha/sha.c 2003-08-07 17:40:30.0 +0200
+++ apg-2.2.3.dfsg.1.fixed
Package: libx11-data
Version: 1.0.3-7
Severity: minor
Tags: patch
The en_DK locales are only partially implemented by the
003_recognize_glibc_2.3.2_locale_names.diff patch. This patch, applied
*after* the 001-022 patches, should make the en_DK locales consistent
with the other locales. The
For what it's worth, the ThinkCentre 8183-PWG is also affected. I have
tried rebuilding the sarge 2.6.8 kernel with ACPI_SLEEP and
X86_UP_IOAPIC disabled, and also updating to the latest 2005-06-14
flash (2AKT50AUS), to no avail.
The problem isn't quite straight-forward to trigger on this
Thanks to Dan Frazier, I now know that my amd64 patch does NOT
work on ia64. Many thanks to Dan Frazier for prompt testing and
patiently answering my questions!
Also, even though olvwm does work on amd64, there clearly are
issues that I don't understand. Until I understand why it doesn't
If /home is mounted over NFS via an automount map, root is unlikely to
be able to create directories in /home. While root can be configured
to be allowed to write in individual home directories, it can't
automatically create an automount map, which is very common in larger
NFS setups. Thus, it's
46 matches
Mail list logo
