That is obviously a problem, but so is d-i booting unexpectedly.
D-I doesn't touch anything until told to does it?
i don't really see how unexpectedly ending up at the first screen of the
installer is any worse than unexpectedly ending up at the syslinux boot prompt,
either way you just
-Original Message-
From: Joey Hess [mailto:[EMAIL PROTECTED]
Sent: 20 February 2007 08:36
To: Robert Millan; [EMAIL PROTECTED]
Subject: Bug#411552: please set a timeout in syslinux screen
Here are some scenarios to consider:
* Suppose that I'm blind. I put in the CD, reboot,
Unfortunately, adding good DNS via network-admin doesn't archieve the same
effect, because dhclient will overwrite /etc/resolv.conf whenever
it's run
the most obvious question would be why doesn't network-admin know this and do
something about it?
,
which is going to be quite often if you
As to what network-admin can do, it could easily alter the order (run
dhclient first, then modify resolv.conf), but that would only archieve
temporary unfuckage (i.e., same situation as if resolvconf was installed).
can't it just reconfigure dhclient not to touch dns (i presume dhclient has an
The problem with adding a development task has always been, and
continues to be, that people do not use the same tools for development,
and that there are no good defaults beyond basic C-style development
tools.
mind you a similar thing applies to say the file server task, there are at
I'll try them as soon as Etch is out. As Stable. ;)
If you do that and the problem is still there then it will be too late for etch
to get a fix.
Partman (guided partitioning) will still ask the user to select
which disk to
partition, even if there's only one disk.
personally i think its better that it asks
consider the situation where a user has two drives but the one they want to use
for debian is not detected.
then they select the
reopen 380552
thanks
looks like this is still an issue.
http://buildd.debian.org/fetch.cgi?pkg=coreutils;ver=5.97-5.3;arch=s390;stamp=1170189620
FAIL: pwd-long
package: iceweasel
severity: important
the about box still prominantly shows the firefox name under the globe
also does the stuff about the firefox trademarks still need to be there now
firefox has been rebranded?
Package: iceweasel
Severity: minor
when i first ran iceweasel in a sid chroot that had never run firefox before i
got taken to http://en-us.www.mozilla.org/en-US/firefox/2.0/firstrun.
this page told me to close the tab to get my homepage but no tab bar was
visible.
also the page prominently
any chance of an english translation of those error messages?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 399670 patch
thanks
ok i've done some more investigation
the problem appears to be caused by there being something in
/etc/firefox/profile that wasn't put there by dpkg and so doesn't
get removed by dpkg. The result of this is that dpkg purges the
files it installed but leaves the
package: pidgin-dev
severity: serious
Unpacking pidgin-dev (from .../pidgin-dev_2.0.0+dfsg.1-1_all.deb) ...
dpkg: error processing
/var/cache/apt/archives/pidgin-dev_2.0.0+dfsg.1-1_all.deb (--unpack):
trying to overwrite `/usr/lib/pkgconfig/gnt.pc', which is also in package
gaim-dev
dpkg-deb:
package: pidgin-dev
severity: serious
configure:3906: $PKG_CONFIG --exists --print-errors pidgin
Package gtk+-2.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `gtk+-2.0.pc'
to the PKG_CONFIG_PATH environment variable
Package 'gtk+-2.0', required by
shouldn't this copy be closed as well.
retitle 414944 libapt-pkg-perl and hence apt-file are uninstallable on
systems that preffer unstable
severity 414944 grave
CCing debian-release because a binnmu should be enough to fix this.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
DEB package: http://download.webmin.com/devel/deb/webmin_1.306_all.deb
DSC file:http://download.webmin.com/devel/deb/webmin_1.306.dsc
Original source: http://download.webmin.com/devel/tarballs/webmin-1.306.tar.gz
Diff:http://download.webmin.com/devel/deb/webmin_1.306.diff
I
DEB:http://www.webmin.com/download/deb/webmin_1.340_all.deb
DSC:http://download.webmin.com/download/deb/webmin_1.340.dsc
Diff: http://download.webmin.com/download/deb/webmin_1.340.diff
Source: http://www.webmin.com/download/webmin-1.340.tar.gz
well dpkg-source didn't seem to like
package: binutils
severity: important
the version in unstable seems to be a newer snapshot than the one in
experimental (the date is newer), however the different structure of the
version number means that as far as dpkg/apt is concerned the version in
experimental is newer.
this raises the
nearly a week ago a bug was filed against libc6
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421037) reporting a sigill
when upgrading on a netwinder. Replies to the bug report say that on some
netwinders it does work.
there is still no information in the bug report log on what the
i used force-architecture to install the existing flashplugin-nonfree
package on my amd64 system and manually ran
nspluginwrapper -i /usr/lib/firefox/plugins/libflashplayer.so
afterwards and flash works in firefox (i tested it with youtube). Rob
andrews soloution seems better on that front
peter green wrote:
i used force-architecture to install the existing flashplugin-nonfree
package on my amd64 system and manually ran
nspluginwrapper -i /usr/lib/firefox/plugins/libflashplayer.so
afterwards and flash works in firefox (i tested it with youtube). Rob
andrews soloution seems
tags 411533 +patch
I've attatched a new tar.gz for a version of the package which adds an
amd64 package.
characteristics of the amd64 package
* no symlinks are included in the package, symlink creation and removal
is left up to nspluginwrapper (if symlinks aren't added for your
favorite
Rob Andrews wrote:
On 03-Jul-2007 23:48.57 (BST), peter green wrote:
* no symlinks are included in the package, symlink creation and removal is
left up to nspluginwrapper (if symlinks aren't added for your favorite
browser then imo thats a bug in nspluginwrapper).
nspluginwrapper
package: gaim-librvp
severity: grave
the gaim package in unstable is now a transition package to pidgin.
Gaim-librvp is therefore unusable (and FTBFS) and should be turned into
a transition package as well.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
package: gaim-encryption
severity: grave
the gaim package in unstable is now a transition package to pidgin.
Gaim-encryption is therefore unusable (and FTBFS) and should be turned
into a transition package as well.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
package: gaim-hotkeys
severity: grave
Since gaim in sid is now a transition package your current package is
now unusable (and FTBFS).
gaim-hotkeys has been ported to pidgin by upstream and renamed to
pidgin-hotkeys ( http://pidgin-hotkeys.sourceforge.net/ ). Please update
your package.
package: nautilus-sendto
severity: serious
nautilus-sendto is no longer buildable in unstable because gaim is no
longer in unstable. It is also highly unlikey to be usable with pidgin.
To make it build against pidgin all that is required is to drop ubuntus
patch into debian/patches and
Steve Langasek wrote:
clone 430960 -1
reassign -1 gaim-dev
found -1 1:2.0.0+fake.1
severity 430960 important
thanks
The package *is* buildable in unstable, because gaim support is optional in
the package. Whether this should be the case is debatable, but in practice
the package currently
package:gcc-4.1
version:4.1.2-7
severity:serious
from the relavent buildd logs:
/bin/sh ./libtool --mode=link /build/buildd/gcc-4.1-4.1.2/build/./gcc/xgcc
-B/build/buildd/gcc-4.1-4.1.2/build/./gcc/ -B/usr/arm-linux-gnu/bin/
-B/usr/arm-linux-gnu/lib/ -isystem /usr/arm-linux-gnu/include -isystem
This type of message does not give me a warm and fuzzy feeling
that makes me
want to work on the Debian arm port.
I'd just like to point out that you are addressing your critisism at the wrong
person. your reply seems to be directed at a message from a person replying to
me not to me.
reopen 409685
thanks
seems that this was fixed in 1.0.9 but broken again by 1.0.10 which was
intended for testing but somehow made it into unstable as well.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 415030 -sid mailto:[EMAIL PROTECTED]
thanks
i get the same errors when building on lenny as were reported for
building on sid
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 415034 -sid
thanks
debian:/# apt-get source -b chiark-utils
Reading package lists... Done
Building dependency tree... Done
Need to get 111kB of source archives.
Get:1 http://192.168.1.3 lenny/main chiark-utils 4.1.10 (dsc) [787B]
Get:2 http://192.168.1.3 lenny/main chiark-utils 4.1.10 (tar)
retitle 406816 mailto:[EMAIL PROTECTED]libghc6-missingpy-dev: not
installable (wants missingh-0.16, but missingh-0.18 is in lenny and sid)
tags 406816 -sid mailto:[EMAIL PROTECTED]
thanks
i have just confirmed this bug also happens with lenny
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
tags 414715 -sid
thanks
i just tried to build this in lenny and it fails with the same error
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 409488 -sid
thanks
i've just tested this in lenny and got the same error
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
it seems like it would be a good idea to check for non dpkg owned versions
of problem libraries sitting in that directory in the preinst and either
aborting the upgrade before the system is left in a badly broken state or
moving the files out of the way.
--
To UNSUBSCRIBE, email to [EMAIL
Of course, while this is the correct default behavior, it seems reasonable
to me that we should allow users to override it with preseeding
or the like,
so that's IMHO a valid wishlist request.
a related issue is if you have a cd not loaded through the CD mechanism for
whatever reason and
it seems that this bug was actually in 2.0.0-1 and therefore only effected
updates from 2.0.0-1 to 2.0.0-2. imo since 2.0.0-1 was never in testing this
bug should not be allowed to keep the current version of freepascal out of
testing.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
It seems g++-4.3 has dropped iostream.h. The reason this bug only
affects ia64 is because the file in question is only compiled on ia64.
I think changing
#include iostream.h
to
#include iostream
using namespace std;
will fix this issue but I do not have access to an ia64 machine to test.
The ftbfs on autobuilder issue could be fixed by switching the order of
the optional build-dependencies.
but IMO it is a very bad idea to have a package build against a legally
dubious library just because the system it was built on happened to have
it installed.
--
To UNSUBSCRIBE,
notfound 475812 3.5.20-12
close 475812 3.5.20-12
thanks
This bug was caused by a bug in another package which has since been
fixed. This package has since been built sucessfully by the sparc
autobuilder.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
I managed to reproduce the issue in my amd64 experimental chroot.
I then tried using
make VERBOSE=1 makeverbose.txt 21
but the output file did not seem to contain any new information over
that in the build logs from buildd.debian.org.
the invocation line from the make VERBOSE=1 output was
tags 471487 +patch
thanks
In my tests the package seems to build fine with a nonexistant home
directory but FTBFS if the home directory exists but is inaccessible.
A quick fix is to add the following to debian/rules between the
hash-bang and the cdbs includes
HOME := $(shell
package: mixxx
version: 1.6.0~beta2-1
severity: serious
tags:patch
The package fails to build on the second run through with a series of
unreprasentable changes to source errors from dpkg-source
add the following to the clean target just above the call to dh_clean to fix
this bug
--
To
tags 482238 +patch
thanks
add libqt4-opengl-dev to the build depends to fix this bug
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 474838 +patch
thanks
patch is attatched
diff -ur necpp-1.2.6+cvs20070816/src/c_geometry.cpp necpp-1.2.6+cvs20070816.new/src/c_geometry.cpp
--- necpp-1.2.6+cvs20070816/src/c_geometry.cpp 2006-11-05 02:31:36.0 +
+++ necpp-1.2.6+cvs20070816.new/src/c_geometry.cpp 2008-06-01
oops looks like i forgot the list of lines to add to the clean target
just above the call to dh_clean, they follow below
rm -f src/qt4.pyc
rm -rf .sconf_temp
rm -f `find -P . -name '*.o'`
rm -f mixxx
rm -f .sconsign.dblite
--
To UNSUBSCRIBE, email to
tags 482509 +patch
thanks
IMO it is a very bad idea to have a package build against a legally
dubious library just because the system it was built on happened to
have it installed.
lame itself is not legally dubious, it's just unfortunate in being
liable to software patent enforcement on MP3
tags 484190 +patch
thanks
It seems that the other build dependencies are sufficiant to build this
package and xlibs-static-dev can simply be removed (I removed all x
packages from my sid chroot to test).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
tags 482245 +patch
thanks
The current version of cmake seems to generate a broken makefile.
I have managed to get the package to build by adding a copy of a version
of the makefile in question generated with lennys cmake and doing some
hackery in debian/rules.
A file to drop in root of
tags 483317 +patch
thanks
IMO given that pbuilder and apt-get build-dep both handle this fine and
being arch all this package will never be built on a buildd I think the
severity of this bug is inflated.
Fix is trivial: either swap the order of the build-dependencies or drop
the reference
tags 484191 +patch
thanks
patch is attatched, just add it to the quilt series.
Index: kdebindings-3.5.9/qtruby/rubylib/qtruby/Qt.cpp
===
--- kdebindings-3.5.9.orig/qtruby/rubylib/qtruby/Qt.cpp 2008-06-07 00:48:29.0 +
+++
tags 479872 +patch
thanks
This seems to be a g++ 4.3 issue. The failure happened on all buildds
for architectures that have 4.3 as default and it also fails with the
same error in my amd64 experimental chroot.
Adding #include typeinfo to the top of
src/FertilityCalculatorThreadMessage.cpp
tags 477016 +patch
thanks
Note that even though this option doesn't need any parameter, in some
configurations curl_easy_setopt might be defined as a macro taking
exactly three arguments. Therefore, it's recommended to pass 1 as
parameter to this option.
adding a 1 as an extra parameter to
tags 479935 +patch
thanks
the package seems to contain a broken check for outdated perl versions,
simply disabling the check makes it build.
attatched is a patch that does just that ready to be added to the dpatch
sequence.
#! /bin/sh /usr/share/dpatch/dpatch-run
##
tags 479892 +patch
thanks
add libx11-dev to the build-depends to fix this bug
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 483328 +patch
thanks
The package built fine in my (reasaonblly up to date but not clean) sid
chroot.
Some build log comparisons between the output of my successfull build
and lucas's revealed the following rather weired difference.
my output (successfull build)
# pvm-dev package
cp
It seems that tiddlywiki_cp is under a suitable license though the
licenecing could do with a bit of cleanup (the license headers are
missing from some files but one of those files looks like trivial
boilerplate code to me and the others are just test code, an install
script is lgpl v2 only
tags 485051 +patch
thanks
add the following lines to the top of debian/rules (below the hash-bang
but above everything else) to fix this bug
#it seems upstreams build system uses CFLAGS from the environment in
preference
#to those from it's platform configurations causing a FTBFS with newer
Then this is worse, this package should live in non-free.
Hmm, other packages that are installers for non free software (e.g.
flashplugin-nonfree , ) also seem to live in contrib. IMO they are if
anything worse because they download and install non-free software
without further user
tags 484701 +patch
thanks
add
XS-Python-Version: current
to the first section of debian/control to fix this bug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
investigating 486260 I have discovered the following
the i386 package from the archive (uploaded by the nmuer) segfaults
the amd64 package from the archive (built by a buildd) runs and shows
the GUI (whether it does what it is supposed to I can't say as I don't
use the package)
A self built
peter green wrote:
investigating 486260 I have discovered the following
the i386 package from the archive (uploaded by the nmuer) segfaults
the amd64 package from the archive (built by a buildd) runs and shows
the GUI (whether it does what it is supposed to I can't say as I don't
use
starvoyager refuses to start with the following error:
starvoyager: error while loading shared libraries:
libstdc++-libc6.2-2.so.3: cannot open shared object file: No such file
or directory
I have tried and failed to reproduce this error in my i386 sid chroot.
The starvoyager binary seems to be
tags 486349 +patch
the patch in debian/patches makes an unexplained change from srcdir to
sourcedir that causes the build to silently fail if the source copy is
not done before the build. A new version of the patch with this change
removed is attatched.
Files javatar-2.5.orig/javatar-2.5.tar
tags 490414 +patch
thanks
patch is attatched, just add it to the dpatch series.
#! /bin/sh /usr/share/dpatch/dpatch-run
## 40_fix_const.dpatch by [EMAIL PROTECTED]
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: minor const correctness fixes to make build work
tags 483323 +patch
thanks
The FTBFS happens because lucas's rebuilder does not use the
packagename-upstreamversion naming convention for the directory
containing the extracted package. This causes the following two lines in
debian/rules to give wrong results eventually resulting in a FTBFS.
tags 442529 +patch
thanks
add
-rm -rf .sconsign.dblite
to the clean target in debian/rules to fix this bug
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 424286 +patch
thanks
add the following to debian/rules to fix this bug
makebuilddir/libgalago1.0-cil::
cp galago/galago-api.raw .
clean::
-cp galago-api.raw galago/
-rm galago-api.raw
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
tags 442570 +patch
thanks
add -rm -f po/fr.gmo to the end of the clean target to fix this bug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 424321 +patch
thanks
to fix this bug add the following commands to the end of the clean
target in debian/rules
-rm -rf src/*.o
-rm -rf src/gfslicer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Looks like this failure was taken from the buildd logs.
I have tried to reproduce this in a amd64 sid chroots doing build as
root, build with fakeroot and build with sudo and all builds succeeded.
I also tried with fakeroot in an i386 sid chroot again it was fine.
So I would guess this is
tags 477956 +patch
thanks
It seems even bash was getting confused by some of the stuff in debian/rules
The following modified rules file is enough to make it build ok with
bash and dash, posh fails on the configure script before it gets to the
isntallation sections.
#!/usr/bin/make -f
Are you sure this is a bug?
the debconf message before I get that error seems to ask for a
commercial CD (which I don't have, it seems this package can only be
used if you own the appropriate commercial software.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
I have reproduced this in my experimental chroot and have attatched the
config.log.
Strangely the CFLAGS that dpkg-buildpackage claims to be using do not
seem to match up with the on the compiler is complaining about.
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage:
tags 478503 +patch
thanks
to fix this bug add
chmod 755 src/native/unix/configure
to the beggining of the configure-stamp target in debian/rules.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 482516 +patch
thanks
changet the build-depends line in debian/control to
Build-Depends: libbg1-dev
to fix this bug
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
reassign 482515 hs-plugins
retitle 482515 current version of hs-plugins FTBFS on the buildd and old
version is no longer installable.
tags 482515 +patch
Thanks
The real issue here is that the latest version of libghc6-plugins-dev
failed to build on the build. It seems the issue is that
tags 482513 +patch
thanks
replace bglibs-dev ( 1.022-0) with libbg-dev in the build-depends to
fix this bug
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 482649 +patch
thanks
This is a g++-4.3 issue add #include limits.h to (I put it just under
the inclusion of ogre.h but I doubt the precise location is too
important) to fix it.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
tags 482650 +patch
thanks
this is an issue on any platform that uses g++ 4.3. It is caused by a
couple of missing include statements.
patch is attatched.
diff -ur gigedit-0.1.1/src/gigedit/mainwindow.cpp gigedit-0.1.1.new/src/gigedit/mainwindow.cpp
--- gigedit-0.1.1/src/gigedit/mainwindow.cpp
tags 482676 +patch
thanks
I can confirm that removing configure from the .PHONY line in
debian/rules will make this package build with -rsudo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 482264 +patch
thanks
relavent part of config.log
configure:4503: checking for C compiler default output file name
configure:4525: i486-linux-gnu-gcc -g -O2 -pipe -I/usr/include/xmltok
-I/usr/inc
/usr/bin/ld: cannot find -lmysqlclient_r
collect2: ld returned 1 exit status
configure:4529:
package: apache2-mpm-itk
severity: important
Attempting to build apache2-mpm-itk in an experimental chroot (with the
libmysqlclient-dev installed ) fails with the following error.
/usr/share/apr-1.0/build/libtool --silent --mode=link i486-linux-gnu-gcc
-pthread -g -O2 -pipe
tags 482920 +patch
thanks
add the following to debian/rules immediately below the first endif to
fix this bug
DEB_MAKE_BUILD_TARGET += OCAML_BACKEND=gcc
DEB_MAKE_INSTALL_TARGET += OCAML_BACKEND=gcc
DEB_MAKE_CLEAN_TARGET += OCAML_BACKEND=gcc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
tags 488132 +patch
thanks
DO NOT SEND THIS MESSAGE YET
I'd like to verify the
fix, but there doesn't seem to be an amd64 emulator in the archive...
I have added int casts to all the printf calls the compiler was
complaining about and the package now builds.
patch is attatched
BTW in the
DO NOT SEND THIS MESSAGE YET
Sorry that was a note to myself that I forgot to delete when the message
was finally ready for sending.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: ia32-libs-gtk
Version: 2.5
Severity: important
I have attatched a test app which allows easilly launching the file
chooser, to build it use
gcc `pkg-config --cflags gtk+-2.0` `pkg-config --libs gtk+-2.0` -m32
dialogtest.c -o dialogtest
When I build it without -m32 the dialog
make[4]: Entering directory
`/build/buildd/adonthell-0.3.4.cvs.20080529/src/modules'
../../src/adonthell-0.3 -c
*** warning: prefs::read_adonthellrc: creating config file failed
Fatal Python error: exceptions bootstrapping error.
Something is going wrong with the intitalisation of the embedded
I posted about this to the upstream forum (
http://foro.pixjuegos.com/viewtopic.php?t=224start=0 ) and got some replies.
The good news is that the upstream developers posted a link to a tarball containing the source for the images.
http://pixjuegos.com/descargas/recursospixbros.tar.bz2
The
it seems ocamlopt is only availible on some architectures and ocamlc
needs to be used on those without it. I'm not sure how much of a drop
in replacement it is though.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 487039 +patch
just change the 11 to a 13 to fix this bug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 487051 +patch
thanks
add libboost-thread-dev to the build dependencies to fix this bug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 487054 +patch
thanks
add libxext-dev to the build dependencies to fix this bug
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 487057 +patch
thanks
add libxext-dev to the build-depends to fix this bug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
package: xutils-dev
version: 1:7.4+2
severity: serious
justification: causes another package to FTBFS
When run as part of the build process for 9menu xmkmf generates a
makefile with -lXext in it but xutils-dev has no dependency on
libxext-dev, this causes 9menu to FTBFS.
--
To UNSUBSCRIBE,
tags 475207 +patch
thanks
changing libgnet2.0-dev to libgnet-dev in debian./control makes this
package build succesfully.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tags 479687 +patch
thanks
adding pcp, libglu1-mesa-dev andmesa-common-dev to the
build-dependencies will make this build (at least on i386 and amd64, I
don't have any other platforms handy to test).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
201 - 300 of 2734 matches
Mail list logo
