tags 479613 +patch
thanks
it looks like libosip renamed it's md5 functions/types (probablly to
avoid symbol conflicts) causing this failure.
I have attatched a patch to make siproxd use the new functions, this can
be dropped straight into the debian/patches directory (the package uses
cdbs
The package seems to require Sun Java as it stated in README.txt. I gave
up with trying to run it on free VM's available in Debian etch.
It would appear that way
In addition, the azureus wrapper expects java in the path, which is
available only with Sun Java package installed.
Afaict this is
tags 477046 +patch
thanks
this bug is caused by some minor misquoting in debian/rules. fixed
debian/rules file is attatched.
#!/usr/bin/make -f
# Sample debian/rules that uses debhelper.
# This file is public domain software, originally written by Joey Hess.
# Uncomment this to turn on
tags 479971 +patch
thanks
The inclusion of asm/page.h in lib/gexec_process.c seems to be
supirous, simply removing the #include makes the file build.
To get the complete package to build (I did my test builds on AMD64) I
also had to add -fPIC to the CFLAGS in debian/rules
--
To
tags 479973 +patch
thanks
removing the #include asm/page.h from base/sched/liblxrt/touchall.c
will make this build (at least on i386).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 479974 +patch
thanks
it seems that simply removing the #include asm/page.h from swapd.c is
enough to make this package build (at least on i386, not tested elsewhere).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 479975 +patch
thanks
simply removing the #include asm/page.h from font/j3100.c makes this
package build successfully (at least on i386).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
simply removing the #include asm/page.h from proc/ps.h will make this
package build (at least on i386).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 480108 +patch
thanks
It seems this problem is actually caused by an over-zelous distclean
target in the doc directories makefile (it removes a load of html files
that are not generated at least not as part of the normal build
process). I tried to fix this in the upstream build system but
Umh, sorry... Didn't do the trick :-(
That is strange because it seems to be working fine here. Are you sure
the tree was in a sane state when you replaced the rules file. The new
rules file won't help if the documentation is already gone.
--
To UNSUBSCRIBE, email to [EMAIL
tags 479977 +patch
thanks
It seems that simply removing the #include asm/page.h from
src/linux/proc/ps.h is enough to make this build (at least on i386).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 479979 +patch
thanks
It seems that simply removing the #include asm/page.h from
um-viewos/um_mmap.c will make this build fine at least on i386
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 479981 +patch
thanks
simply removing the #include asm/page.h from fbcommon.c is enough to
make this build (at least on i386)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 479982 +patch
thanks
it seems that simply removing the #include asm/page.h from
util-linux/mkswap.c is sufficiant to make this build (at least on i386).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 479980 +patch
thanks
simply removing the #include asm/page.h from mount.ocfs2/mount.ocfs2.h
will make this build (at least on i386)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Does libparted have support for that kind of partition table?
it doesn't look like it (both parted and gparted also detect the
partition table type as GPT).
If not, it would have to be implemented there first.
ok
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
tags 476680 +patch
thanks
The problem here is that the packages makefiles break when the quilt
patches are removed (probablly due to DFSG stripping of the source
tree). but debian/rules clean removes the patches before calling make
distclean.
A fixed debian/rules file is attatched.
tags 471004 +patch
thanks
to fix this bug add -fno-strict-aliasing to the line that adds cflags in
base/common.make
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 460191 +patch
thanks
add the following commands to the clean target near the end (I put them
just before dh_clean) to fix this bug.
-rm -rf /cdrdao-1.2.2/scsilib/librscg/OBJ
-rm -rf /cdrdao-1.2.2/scsilib/libscg/OBJ
-rm -rf /cdrdao-1.2.2/scsilib/libschily/OBJ
P.S. this
--
To
tags 477011 +patch
thanks
patch is attatched. just add it to the quilt series.
Index: adonthell-0.3.4.cvs.20050813/src/py_adonthell_wrap.cc
===
--- adonthell-0.3.4.cvs.20050813.orig/src/py_adonthell_wrap.cc 2008-04-20
package: gnat-gps
version: 4.0.1-6
severity: serious
It seems the -dev packages for libgnatprj have now been versioned to
allow multiple versions of gnat to be installed using thier own version
of it. To allow successfull builds on both testing and unstable it
appears the first line of
Package: linux-image-2.6.24-1-amd64
Version: 2.6.24-5
Severity: important
With 2.6.23 and 2.6.24 the onboard ethernet on my brothers desktop PC no
longer works. The system announces the link is up then soon afterwards
announces a timeout then announces it is up again and the process
repeats
tags 474787 +patch
thanks
patch is attatched
diff -ur hugin-0.6.1/debian/rules hugin-0.6.1-plugwash/debian/rules
--- hugin-0.6.1/debian/rules 2008-04-09 20:17:53.0 +
+++ hugin-0.6.1-plugwash/debian/rules 2008-04-09 19:43:49.0 +
@@ -21,7 +21,7 @@
DEB_BUILD_GNU_TYPE ?=
tags 474794 +patch
thanks
patch is attatched.
The patch also fixes an unreported FTBFS if built twice in a row bug.
Only in gnome-color-chooser-0.2.3: config.guess
Only in gnome-color-chooser-0.2.3: config.sub
diff -ur gnome-color-chooser-0.2.3/debian/rules
tags 474795 +patch
thanks
to fix this bug add #include libintl.h to the top of gpar2.cc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
package: gmetadom
severity: important
tags: patch
add #include string.h to src/gdome_cpp_smart/include/GdomeSmartDOM.hh
and src/gdome_cpp_smart/include/GdomeSmartDOMTraitst.hh just before the
existing includes to fix this bug
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
tags 474798 +patch
thanks
add #include string.h to the top of C++/test/main.cc to fix this bug
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
package: partman
severity: wishlist
On mutliboot intel based macs the normal partition table type is a
MBR+GPT hybrid. Currently when used with such a partition table partman
destroys the MBR parition table causing bootloader installation to fail
and thus making installing debian on such
tags 442550 +patch
thanks
to fix this bug add the commands
-rm user/drbdmeta
-rm benchmark/io-latency-test
to the end of the clean target
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I have just tried to reproduce 471606 and 471608 (which seem to be the
same issue just on different packages) in my up to date sid chroot and I
can't reproduce either. Have they been fixed by a new gtk/glib upload or
something?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
peter green wrote:
I have just tried to reproduce 471606 and 471608 (which seem to be the
same issue just on different packages) in my up to date sid chroot and
I can't reproduce either. Have they been fixed by a new gtk/glib
upload or something?
sorry I wrote my message before I finished
tags 471608 +patch
thanks
this can be fixed by removing -DG_DISABLE_DEPRECATED from bse/makefile.in
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 472325 +patch
this is trivially fixed, just add libxml-parser-perl to the
build-depends line in debian/control
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
windowswindow~1.log is 92k, but it has 41 clusters (164k)
ERROR !!!
Ignore
Cancel
dmesg -c on second console didnt showed anything relevant, only
information that swap was mounted/added.
Perhaps the fat system there was damaged before and debian tried to
mount it? But if so then this
The problem is one of wrong include paths getting passed to g++
sucessfull amd64 build:
g++ -c -pipe -g -O2 -g -Wall -O2 -w -D_REENTRANT -fPIC -DNBREAKPAD
-DLINUX -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB
-DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I.
tags 521922 +patch
thanks
from testing with pbuilder login it seems python is the only missing
build-dependency and adding it will fix this bug.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
tags 523935 +patch
thanks
simply changing libgucharmap-dev to libgucharmap2-dev in build-depends
makes this package build successfully.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
tags 524775 +patch
thanks
patch is attatched.
diff -urN ogre-1.6.1.dfsg1/debian/Makefile.dummy ogre-1.6.1.dfsg1.new/debian/Makefile.dummy
--- ogre-1.6.1.dfsg1/debian/Makefile.dummy 1970-01-01 00:00:00.0 +
+++ ogre-1.6.1.dfsg1.new/debian/Makefile.dummy 2009-04-20 18:10:15.0
Looks like some fedora guys have found a fix for this but they don't
seem to have posted it as an actual patch :/
https://fcp.surfsite.org/modules/newbb/viewtopic.php?topic_id=61208forum=11
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
I've done some flyby inspection of this bug and come to the following
conclusions.
* The freeradius build has a check for links with anything in a libssl*
package BUT this check only detects direct links.
* Freeradius normally ends up with an indirect link to libcrypto (from
the libssl*
severity 534089 important
block 534089 by 178840
E: Couldn't find package ppmd
That is because ppmd FTBFS on amd64. It also FTBFS on our other 64 bit
architectures (alpha, ia64 and kfreebsd-amd64). There have been serveral
attempts to fix it but so far it still segfaults during the build.
tags 545593 + sid squeeze
This bug affects sid. It does not affect lenny. Right now it does not
affect squeeze either but I suspect that will change so i'm considering
this as relavent for squeeze.
It seems the headers for simgear have changed a lot with the new version
and this is breaking
tags 605816 +patch
thanks
The attached patch points $HOME for the build at a subdirectory of the
build tree (which is created in build and nuked in clean) allowing the
package to be built by users with a nonexistent homedir and ensuring
that the users homedir can neither affect or be affected
I just took a quick look (i'm just doing flyby looks at rc bugs, I don't
have anything to do with this package) and it appears it isn't a simple
case of missing build-depends. The build-depends is there but qualified
with [linux-any], presumablly that qualification is there because
found 593049 1.0.12.debian-1
thanks
I have just confirmed that this issue also impacts building squeezes
version in squeeze
Looking at config.log for insight it seems something screwy with CFLAGS
configure:5403: checking osso-log.h usability
configure:5403: gcc -c -g -O2 -Wall -g -O2
tags 575856 +patch
thanks
From my testing it appears to be sufficiant to simply drop the
build-dependency on x-dev to fix this.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
tags 614772 +patch
thanks
Looks like /cli-common-dev needs to be moved from build-depends-indep to
build-depends.
/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
As of right now this issue only seems to affect builds on sid not on
squeeze or wheezy.
The offending line is GKeyFile *alarm; which seems to conflict with a
new addition to the standard headers.
The strange thing is I can't seem to find any evidence that variable is
ever used either by
After much trial and erorr I managed to reduce the problem to the
attatched trivial example. I do not know enough C++ to say if this is
supposed to work or not but I can say it builds with 4.4 but not 4.5.
Note: i'm just doing flyby RC bug investigation (yes I know this bug is
marked as
It seems wolfram.com changed the location of fonts or
removed the fonts.
Regardless of what caused the failure IMO with a package of
this style it is not acceptable to leave the package in an
unremovable state if the download fails.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
I have attatched a patch which reduces the optimisation level of the
build to O2 on ia64. I have checked the patch sets the optimisation
level correctly by using a different architecture in the test but I do
not have access to an ia64 box so I can't test to confirm the subitters
statement
tags 506009 +patch
thanks
the issue seems to be caused by upstream defining _FILE_OFFSET_BITS=64
but not _LARGEFILE64_SOURCE causing the zlib header to misbehave.
Defining _LARGEFILE64_SOURCE as well fixes it.
This can be done by adding the following to debian/rules
#needed to make the zlib
package: hardening-wrapper
severity: important
For some reason in my i386 sid chroot I ended up with cc pointing at
gcc-4.2 but gcc-4.2 not installed, I dunno exactly how this happened but
given that this chroot is far from clean i'm not going to blame debian
for it (heck I may have even set
Thanks, peter. John uploaded a fixed package with your patch.
The good news is it built sucessfully on ia64
The bad news is it failed on alpha arm mips s390 and sparc due to a
failure to install the build-depends. I have reproduced this failure on
my qemu arm system and the culprit seems
severity 507113 normal
thanks
If I'm using Root Terminal from GNOME, smart --gui works fine.
If I'm using Konsole and su root smart --gui fails in seg fault
su clears out the environment so x programs won't work hence the can't open
display warning you get from gtk. Use sux instead.
The
severity 506862 normal
thanks
When I try to run inspircd, it dies with the message inspircd: error
while loading shared
libraries: libIRCDchannels.so: cannot open shared object file: No such
file or directory
In my test chroots at least it starts sucessfully using the init script
but fails
the armel issue is a missing #include cstdio in
source/COMMON/logStream.C , I dunno why it only showed on armel though
(maybe the standard library include chains are different or something).
the kfreebsd issue seems to be an issue with the code in
source/SYSTEM/sysinfo.C not being compatible
Abou Al Montacir wrote:
Thank you for the interest you are giving to FPC.
Indeed, FPC is supported upstream on *BSD, and we shouldn't get any
issue making it available for Debian for any of these targets.
However a new FPC version (2.4.0) is being released and we should focus
on it instead of
xpdf might not be shipped with Squeeze.
Your package currently build depends on xpdf-utils. Please adapt it to
xpdf-utils's successor poppler-utils.
However poppler-utils provides xpdf-utils and seems to be compatible
enough for hpodder to build successfully so i'm not sure that this is a
bug.
Architecture: all
-Depends: bzr (= 1.13), bzr ( 2.1~), mercurial (= 1.3.1),
${python:Depends}, ${misc:Depends}
+Depends: bzr (= 1.13), bzr ( 2.1~), mercurial (== 1.3.1),
${python:Depends}, ${misc:Depends}
Suggests: bzr-gtk
That patch is no good for two reasons
Firstly there has never been a
package: e2fsprogs
severity: critical
justification: breaks the entire system
When booting my quemu armel system I get the following
Checking root file system...fsck from util-linux-ng 2.16.1
/dev/sda1: Superblock last mount time (Thu Jan 1 01:03:11 1970,
now = Thu Jan 1 01:00:52 1970)
retitle 559747 zita-convolver: must not use -march=native
thanks
zita-convolver appears to be using -march=native , there are two
problems with this
1: It's not supported on most debian architectures (hence a load of
build failures)
2: Even on architectures where it is supported it's totally
reopen 532971 1:1.6.2.0~dfsg~beta3-1
thanks
This is an automatic notification regarding your Bug report
which was filed against the asterisk package:
#532971: asterisk FTBFS on armel
snip
* Accommodate for the rename of libcap2-dev to libcap-dev (Closes: #532971)
This doesn't seem
This bug has been pending for over a fortnight and the bug that was
marked as blocking it after it was tagged pending was fixed over a week ago.
What is the current status of the bug and if there are still problems is
the work in progress code availible anywhere?
--
To UNSUBSCRIBE, email
I think nbsmtp should conflict with mail implementations, which it does
not support. I use bsd-mailx and it does not work.
Even with the conflicts nbsmtp would still be rc buggy
according to the lenny rc policy (
http://release.debian.org/lenny/rc_policy.txt ) .
The /usr/sbin/sendmail
tags 503800 +patch
thanks
add
ANT_OPTS := -Dant.build.javac.source=1.5 -Dant.build.javac.target=1.5
immeditately after the line that sets DEB_ANT_BUILDFILE in debian/rules
to fix this bug
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
found 503800 1.20.0-1
thanks
btw this bug also affects the version in lenny (which is built using the
propietry sun jdk)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 503771 +patch
thanks
While coco-java does list openjdk in it's build-dependencies it lists
other options too so the class versions will depend on the build machine
setup (as they will for any package that doesn't take explicit steps to
choose the build jdk that matches the
found 503775 2+b58g-3
thanks
ok it seems some of the binaries generated from this source have the
classfile version issue but not others. It looks like
Also given that this package only migrated over from contrib recently I
strongly suspect that the dependencies on the binary packages would
The jar contains a mixture of versions 47 and 48 in the lenny and sid
packages and in a self built version of the sid package so I presume the
build system is already taking steps to control the classfile version
and am closing this as a false positive. reopen if you disagree.
--
To
found 503798 1.0.3.GA-1
thanks
This bug also affects the version in lenny (which is built with the sun
propietry jdk) marking as such
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 503798 +patch
thanks
add
ANT_OPTS := -Dant.build.javac.source=1.5 -Dant.build.javac.target=1.5
immeditately after the line that sets DEB_JARS in debian/rules to fix
this bug
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
Package: gw6c
Version: 6.0.1dfsg.1-8
Severity: important
(some might say this bug deserves critical given the impact it can have on
the boot process)
Someone filed a bug (554911) complaining about unacceptable interaction from
gw6c during init script run. In response to this bug a test was
The issue mentioned in the bug report was easy enough to fix, just a
matter of changing the version specified to configure in debian/rules .
Unfortunately after doing that the build failed in a different error.
cp: cannot stat
`./debian/tmp/usr/lib/epiphany-browser/2.29/extensions/': No such
I believe that the attached patch fixes this bug. However, it has *not*
been tested on any affected architecture.
I tried adding your patch to the end of the quilt series and got a successful
build on a qemu mips system.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
package: adonthell
version: 0.3.5-4
severity: serious
x-debbugs-cc: debian-pyt...@lists.debian.org
During the run up to the lenny release python 2.5 was made the default
and this made adonthell FTBFS on arm(el) with Fatal Python error:
exceptions bootstrapping error.
tags 563306 +patch
thanks
add autoconf, automake and libtool to the build-depends to make this
package buildable
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: ball
version: 1.3.1-1
severity: serious
The most recent version of ball has failed to build on all the buildds
that have tried it so far, this is a rc issue for architectures the
package is currently in the archive for (afaict currently this means
i386, amd64 and s390) and arguablly
This wasn't detected by edos, so it might be a bug anywhere within:
- edos
- sbuild
- java stuff
- your package.
I don't think your package is responsible, but it still currently FTBFS,
so let's open a bug to track this.
brltty now seems to have been successfully built on all architectures,
The most recent version of ball has failed to build on all the buildds
that have tried it so far
It also failed to build in my amd64 pbuiler with the same issue as on
alpha/i386/s390/sparc
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
The bug is not fixed even with latest changes in packaging. It looks
like compiler flag set from debian/rules file is not getting used by
the build system.
mmm, looks like it is to me
/usr/bin/gcc-4.4 -g -Wall -fPIC -I/usr/lib/jvm/default-java/include
severity 565694 important
thanks
downgrading my bugreport to important as it's now built successfull on
all architectures for which there are packages currently in the archive
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
retititle 504181 apt FTBFS with dpkg-buildpackage -B
tags 504181 +patch
thanks
In my amd64 chroot that the package builds with a straight
dpkg-buildpackage but fails with dpkg-buildpackage -B . Since the
buildds always use -B this would explain it building for the maintainers
but not on any
The solution Sven has proposed can be improved, without all the mirror
bloat, I think. The sane thing to do would be for debootstrap to default
to what's in /etc/apt/sources.list when no mirror is given. This avoids
the logistical nightmare of having to make and update
$arch.ftp.debian.org
Peter, is this bug still reproducible with 2.6.26 from Lenny?
yes
and with the 2.6.27 version from that archive someone told me to try
earlier in the bug report.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Can you please report it upstream at bugzilla.kernel.org and add
the bug number to the bug log?
Unfortunately it looks like i'll have to re-test with a vanilla upstream
kernel before i'm allowed to do that.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
package: release-notes
severity: minor
The lenny release notes say
First, run:
# aptitude upgrade
This has the effect of upgrading those packages which can be upgraded
without requiring any other packages to be removed or installed.
However (assuming the user has followed the
package: release-notes
lenny's libc6 will fail preinst on kernels older than 2.6.8 (Afaict this
applies to all architectures except m68k but I could be misreading the
script) and on some architectures will fail on higher than that.
Depending on the order in which the package manager decides
severity 514235 important
retitle 514235 librra build-depends should be stricter
thanks
Justification: no longer builds from source
etch's version builds fine in etch
lenny's version builds fine in lenny
sid's version builds fine in sid
While it is nice for the build-depends to reflect the
Package: metapixel
Version: 1.9.2-5
This looks like a typo, can you confirm/deny that you mean 1.0.2-5?
metapixel cannot be installed because it depends on libugif4g which is no more
available.
From a quick test it looks like a binnmu will fix this. CCing debian-release to
get one scheduled.
tags 536924 +patch
thanks
The upstream build process does not seem to pick up the required include
dir. Adding CFLAGS += -I/usr/include/libgnomeui-2.0/ to debian/rules
between the shebang and the cdbs includes will force it to look in the
right place.
--
To UNSUBSCRIBE, email to
notfound 540147 1.9.2-5
found 540147 1.0.2-5
thanks
Yes, sorry. 9 is just near 0 on the keyboard :/
Fixing version tracking information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
tags 536997 +patch
thanks
patch is attatched.
diff -ur glunarclock-0.32.4/debian/control glunarclock-0.32.4.new/debian/control
--- glunarclock-0.32.4/debian/control 2009-08-09 01:09:28.0 +
+++ glunarclock-0.32.4.new/debian/control 2009-08-07 06:25:40.0 +
@@ -10,7 +10,8 @@
Moritz Muehlenhoff wrote:
On Fri, Nov 14, 2008 at 09:38:53PM +, peter green wrote:
Can you please report it upstream at bugzilla.kernel.org and add
the bug number to the bug log?
Unfortunately it looks like i'll have to re-test with a vanilla upstream
kernel before i'm allowed
tags 534084 +patch
thanks
Patch is attached
diff -ur dwarves-dfsg-1.3/cmake/modules/FindDWARF.cmake dwarves-dfsg-1.3.new/cmake/modules/FindDWARF.cmake
--- dwarves-dfsg-1.3/cmake/modules/FindDWARF.cmake 2009-08-14 22:24:10.0 +
+++ dwarves-dfsg-1.3.new/cmake/modules/FindDWARF.cmake
We'll fix openbabel. Cloning, reassigning and blocking.
The blocking bug was closed nearly a month ago and when I tested
gnome-chemistry-utils in pbuilder it built fine. Should this bug be closed too?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of
It seems you forgot to really attach it. Could you please send it?
Attatched
Gosh, I hate to see different gcc version act so differently. The package
compiled without any problem on my system.
I think it's more an issue of different architectures than different gcc versions.
Index:
reopen 528659
thanks
It seems you dropped the patch into debian/patches but forgot to
actually add it to the series so it's not being used.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
reopen 529161
thanks
The upload did not fully fix the bug, it fixed the issue with the
ssize_t variable but not the issue with the return type of sizeof.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
But the issues is somehow strange because it builded fine on my amd64
machine.
It always did because amd64 is one of the architectures that had a
hardcoded default.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
301 - 400 of 2734 matches
Mail list logo
