On Sun, Sep 25, 2005 at 12:22:23PM +0200, Frans Pop wrote:
Because LILO is the default installer in some cases (/ on XFS IIRC) and is
also ofter prefered by users for RAID installs.
Also, it is a clear regression from Sarge.
My raid install of sarge used grub. Why ever would you want it to
On Tue, Apr 11, 2006 at 07:21:49PM -0700, Gordon Haverland wrote:
Occasionally I get an email from someone who is reporting back to
many people, but in general I have gotten NO FEEDBACK on this bug
report! It apparently wasn't reproducible to the person fielding
the bug report, but it is
On Wed, Apr 12, 2006 at 02:56:37PM -0700, Gordon Haverland wrote:
I must get better at phrasing things then. There is a lot of
feedback in the bug report. However, within the bug report there
are still many questions which are never answered or commented
upon. As far as feedback goes, a
On Fri, Jun 24, 2005 at 02:29:19AM -0700, Steve Langasek wrote:
So are there any porters alive out there on debian-arm? Being unable to use
cp, mv, and install after upgrading from woody to sarge is a rather serious
problem. If anyone has any ideas about this, or can test the problem with a
The reason for a package to be in contrib, is that it is free itself,
but requries something from non-free to be functional. contrib packages
without access to non-free have no purpose in general.
Hence this is not a bug, but completely correct use of the contrib
section.
I doubt the firmware
It looks like the code uses st in the if just before the deref_stat coll
that fills in st. The following patch moves the deref_stat call before
the if, and keeps the return value for the if inside to use, so that the
messages and behaviour stays the same, but there is no longer a case of
using st
On Tue, Oct 21, 2008 at 11:41:14AM +0200, Aurelien Jarno wrote:
Package: general
Severity: serious
Justification: DFSG
raff.debian.org uses a Compaq Smart 5i RAID card. A flash memory is used
to store the firmware. While the firmware is freely downloadable (as in
beer) on HP website [1],
On Tue, Oct 21, 2008 at 01:30:42PM +0200, Romain Beauxis wrote:
Agreed, though it does not restrain us from asking for free firmware.
If I recall well, one of the origin of the GNU fondation was the fact that
having free drivers alowed one to actually *fix* issues he may have with his
On Sat, Aug 23, 2008 at 01:58:38PM -0700, Randall Donald wrote:
Len,
any news on that 71xx Xen patch?
I am currently trying to do that, but I see 2.6.26 requires a new 71.xx
version from nvidia. I was trying to do this on my amd64 system, but it
would appear 71.xx doesn't come in an amd64
On Fri, May 16, 2008 at 11:55:56AM +0200, MarioDebian wrote:
I have read this bug report and have tried all patches.
I have packaged 173.08 version and don't compile.
All time I get some XEN warnings or errors...
Why CONFIG_XEN is enabled by default?
# grep XEN
On Wed, Jun 18, 2008 at 06:02:33PM -0700, dlakelan wrote:
Tried to install 2.6.25 kernel on AMD64 and to build nvidia-kernel
module from 169.12-4 package using module-assistant. got the same errors
as previous versions reported.
/usr/src/modules/nvidia-kernel/nv/nv-vm.c: In function
On Fri, Jun 20, 2008 at 02:31:05AM +0200, packadal wrote:
Hi, it looks like thge legacy (at leats nvidia-kernel-legacy96xx) are still
suffering from this problem, at least on my machine.
Same kernel (2.6.25-2-686), tried the 'ugly fix' but did'nt worked for me.
Thanks for looking in to this
On Sun, Jun 22, 2008 at 02:01:10PM +0100, Matthew Wakeling wrote:
Just wandering what the progress is on this bug.
I wrote a patch for it a few days ago. Hopefully it will be released
soon.
--
Len Sorensen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
On Sat, Jun 28, 2008 at 02:17:44AM -0400, A. Costa wrote:
On Fri, 30 May 2008 09:50:12 -0400, Len Sorensen wrote:
I am making a patch to fix the legacy driver. Not a kernel problem.
About that patch, over on the 96xx branch, your patch is being used:
On Sat, Jun 28, 2008 at 09:45:09PM +0200, intelcat wrote:
My hardware:
Asus CUV-4X-DLS
2 PIII 1GHz
4GB RAM
Nvidia Geforce6200
Linux Kernel 2.6.25-2-686
Nvidia driver v.177.13 or anyone from v.1xx.xx from Nvidia Site.
Any installations with options:
~$ export CC=gcc-4.1 or with newer gcc
On Sat, Jul 05, 2008 at 10:43:31AM -0700, Randall Donald wrote:
On Sat, 2008-07-05 at 14:01 +0200, Julien Langer wrote:
Also there's no libwfb.so on my system. Maybe because of my slightly
older xserver-xorg-core version 1.3.0?
That's exactly the reason.
You'll need to upgrade or
On Sat, May 17, 2008 at 01:43:04AM +0300, Micha Feigin wrote:
Package: nvidia-kernel-source
Version: 169.12-1
Followup-For: Bug #476504
the kernel driver doesn't compile with kernel 2.6.25 (which is the
current debian default kernel I believe).
This requires either patching the driver
On Fri, May 23, 2008 at 10:22:04AM -0500, M Yudkowsky wrote:
I am able to compile the nvidia-kernel-source, 169.12-1, but I cannot
*install* the resulting module.
KSRC=/usr/src/linux-headers-2.6.25-2-amd64
On modprobe, I receive the error message FATAL: Error inserting
nvidia (path):
On Fri, May 23, 2008 at 01:48:56PM -0500, M Yudkowsky wrote:
Thanks for writing. As far as I can tell from looking at the output
from debian/rules, there are no glaring errors. I get a .deb that I
can install, and the install results in a suitably-named module in
the nvidia directory of
On Tue, May 27, 2008 at 07:06:15PM +0200, Mathias Behrle wrote:
Package: nvidia-kernel-source
Version: 169.12-3
Followup-For: Bug #483074
I am builduing my kernel with
make-kpkg --rootcmd=fakeroot --initrd kernel_image modules_image
and therefore IMHO I have to unpack as user the module
On Fri, May 30, 2008 at 04:49:09AM -0400, A. Costa wrote:
Package: linux-image-2.6.25-2-686
Version: 2.6.25-4
Severity: important
I upgraded to 'linux-image-2.6.25-2-686', then tried to recompile an
'nvidia' module, using 'module-assistant':
% m-a a-i -i -t -f
On Sat, Jun 07, 2008 at 11:45:03AM +, Debian Bug Tracking System wrote:
Processing commands for [EMAIL PROTECTED]:
# Automatically generated email from bts, devscripts version 2.10.28
severity 477643 serious
Bug#477643: nvidia-kernel-legacy-96xx-source: Fails to compile with kernel
On Mon, Sep 29, 2008 at 07:10:31PM -0700, Deekoo L. wrote:
Package: nvidia-kernel-source
Version: 1.0.8776-4
Severity: grave
Justification: renders package unusable
Attempts to build the package according to the instructions in
/usr/share/doc/nvidia-kernel-source/README.Debian fail with
On Sun, Oct 04, 2009 at 12:52:51PM +0200, A Mennucc wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi,
the problem is that module-assistant sets
KSRC=/lib/modules/2.6.30-1-686/build
and then debian/rules calls the nvidia makefile nv/Makefile.kbuild by
$(MAKE) SYSSRC=$(KSRC)
On Sun, Oct 04, 2009 at 10:47:07AM +0200, A Mennucc wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi,
the upstream code (that is,
ftp://download.nvidia.com/XFree86/Linux-x86/96.43.13/
) compiles fine
the difference is AFAICT that the upstream code also runs a file
On Wed, Oct 28, 2009 at 10:24:21AM -0700, Randall Donald wrote:
On Wed, 2009-10-28 at 11:36 -0400, Lennart Sorensen wrote:
On Fri, Aug 21, 2009 at 11:56:32AM -0700, Randall Donald wrote:
On Thu, 2009-08-20 at 10:04 +0200, Pierre Bauduin wrote:
Package: nvidia-glx-ia32
Severity
On Fri, Aug 21, 2009 at 11:56:32AM -0700, Randall Donald wrote:
On Thu, 2009-08-20 at 10:04 +0200, Pierre Bauduin wrote:
Package: nvidia-glx-ia32
Severity: serious
What's funny about this is you want a package to be in testing but
filing a RC bug just added to reasons preventing that.
On Sat, Oct 10, 2009 at 09:26:01AM +0200, alex bodnaru wrote:
Package: nvidia-kernel-legacy-96xx-source
Version: 96.43.13-0.1
Severity: normal
hello,
thanks a lot for bringing nvidia support into debian.
sorry we first communicate when things go wrong. no news is great news
in bug
On Wed, Oct 28, 2009 at 12:08:49PM -0700, Randall Donald wrote:
So can we build and upload the kernel modules or should we bug the
kernel-modules-non-free package person to add us (since that should
now work)?
We probably should go ahead with that soon. For all but 71xx which I
think we
On Wed, Aug 06, 2008 at 01:16:45AM +0300, Jari Aalto wrote:
Any news on this patch moving forward? I'm unable to build the nvidia
driver (for Riva TNT) against the latest kernel as well.
Oh, I forgot to do that one. I will try and get that done this week
then.
--
Len Sorensen
--
To
On Sat, Aug 02, 2008 at 10:06:00PM +0200, Harald Dunkel wrote:
Package: nvidia-kernel-source
Version: 173.14.09-3
Severity: serious
Hi folks,
If I try to build the nvidia modules using module-assistant, then
I get
% export SIGNCHANGES=true
% module-assistant -f -t -u /tmp/modules
On Sun, May 03, 2009 at 08:53:58PM +0200, Stephane Glondu wrote:
Package: nvidia-kernel-legacy-173xx-source
Version: 173.14.18-1
Severity: normal
Compilation with module-assistant with a 2.6.29 kernel fails... Or
let's say doesn't do anything:
Pretty sure it worked here.
[...]
dh_prep
On Mon, May 11, 2009 at 11:43:53PM +0200, Stéphane Glondu wrote:
Lennart Sorensen a écrit :
Compilation with module-assistant with a 2.6.29 kernel fails... Or
let's say doesn't do anything:
Pretty sure it worked here.
On amd64? I know at least one other person who has the same problem
On Tue, May 12, 2009 at 12:47:28AM +0200, Stéphane Glondu wrote:
of course... the conflict should be explicit in the dependencies,
shouldn't it?
Would be nice. I am not sure what the best way to make all the
nvidia-kernel-modules (current and 3 legacy) conflict with each other is.
It works
I finally had time to finish this up along with some cleanup. I failed
to fix openbios (I can't make sense of it), so I instead did some ugly
hack to work around the bad implementation in openbios by keeping the
struct address the same, and wrapping the code and data of first.b around
that
On Tue, May 19, 2009 at 10:32:55AM +0100, Mark Brown wrote:
Package: nvidia-kernel-source
Version: 180.44-2
Severity: normal
The bug log for this bug states that build of the modules works when
using module-assistant. I'm finding that when I attempt to build the
modules with:
Subject: python-kde4: Fails to build from source due to missing libx11-dev
dependancy.
Package: python-kde4
Version: 4:4.3.0-1
Justification: no longer builds from source
Severity: serious
*** Please type your report below this line ***
After installing all the build dependancies listed by
reassign 533897 nvidia-graphics-drivers
thanks
OK, I investigated a bit, and found the problem.
mesa-common-dev depends on libx11-dev
nvidia-glx-dev does not depend on libx11-dev
Both packages provide libgl-dev (either directly or indirectly) which
satisfies that dependancy.
I have
I meant that we should reassign this bug (where did I get that other
number from?) to nvidia-graphics-drivers.
--
Len Sorensen
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
This problem was that yassl in mysql called cpuid without first checking
that it was allowed to do that. It was fixed in a patch (which I helped
get done) in april 2007 and included in mysql as of 5.0.42.
This bug is even listed in a README in the existing etch package. See
I can confirm that first.b does in fact build correctly. I am not sure
what I did wrong before while trying to debug it. Certainly second.b
ends up much too large, and I have not managed to fix first.b to support
a larger second.b, although I am not sure that is because my first.b
changes are
On Thu, Feb 05, 2009 at 12:35:15PM -0500, wrote:
I can confirm that first.b does in fact build correctly. I am not sure
what I did wrong before while trying to debug it. Certainly second.b
ends up much too large, and I have not managed to fix first.b to support
a larger second.b, although I
On Sun, Feb 08, 2009 at 11:46:23AM +0100, Aurelien Jarno wrote:
Great work. Could you please post the patch here, so that it can be
reviewed an included in the next upload of the package?
Yeah I am just cleaning it up and adding a few bits of error checking
(which it was previsouly lacking in).
On Fri, Jan 23, 2009 at 07:07:16PM +0100, Thomas Lundqvist wrote:
Hi all, I'm afraid it's more complicated...
I discovered this problem today as well when upgrading kernel to:
2.6.24-etchnhalf.1-686.
Building from nvidia-kernel-source 1.0.8776-4 didn't work. I also
tried a later
On Mon, Apr 06, 2009 at 10:19:33AM +0200, Ita?? BEN YAACOV wrote:
Package: nvidia-kernel-source
Version: 180.29-1
Severity: normal
After looking for several complicated solutions I found a relatively easy one
-
(after copying the Makefile_32.cpu file of course)
you just need to set the
On Wed, Apr 08, 2009 at 12:44:19AM +0200, Carlo Fusco wrote:
Package: nvidia-kernel-legacy-173xx-source
Version: 173.14.15-2
Severity: serious
*** Please type your report below this line ***
I have a NVIDIA FX5500. As root, in the last debian kernel (2.6.29) I tried
to compile the module
On Mon, Apr 13, 2009 at 01:52:43PM +0400, Alexander Gerasiov wrote:
Package: nvidia-kernel-source
Version: 180.44-1
Severity: serious
Justification: no longer builds from source
Hi.
I've tried to build nvidia-graphics-modules-i386 (updated to 180.44), but it
fails.
The problem is in
On Sun, Apr 12, 2009 at 08:10:13PM +0200, Sven Joachim wrote:
I see. The VERSION variable is supposed to be set by including
/usr/share/modass/include/generic.make, and you apparently do not have
module-assistant installed, do you?
Probably nvidia-kernel-source should stop recommending
On Sun, Apr 12, 2009 at 01:48:27PM -0400, Christopher Martin wrote:
On April 12, 2009 13:36:36 Sven Joachim wrote:
Only because $(VERSION) is empty for you, and that is the problem.
How did you try to build the module?
I tried:
cd /usr/src/modules/nvidia-kernel
(after unpacking
On Sun, Apr 12, 2009 at 09:54:20AM +0200, Sven Joachim wrote:
tags 523716 + patch
thanks
On 2009-04-12 05:51 +0200, Avery Fay wrote:
Package: nvidia-kernel-source
Version: 180.44-1
Severity: grave
Justification: renders package unusable
from m-a build:
/usr/bin/make -C .
On Sun, Apr 12, 2009 at 10:52:59AM +0200, Andreas Tscharner wrote:
Package: nvidia-kernel-source
Version: 180.44-1
Severity: normal
The package does not build here either, but it fails with the following
message:
make[1]: Entering directory `/usr/src/modules/nvidia-kernel'
make[1]: ***
On Mon, Apr 13, 2009 at 08:44:27AM -0700, Randall Donald wrote:
KSRC=/usr/src/linux-headers-2.6.29-1-686-bigmem \
KVERS=2.6.29-1-686-bigmem debian/rules binary_modules
That is no longer a complete set of headers and you can't build against
it like that. The kernel team says
On Mon, Apr 13, 2009 at 12:39:17PM -0400, Christopher Martin wrote:
I guess I'll switch to module-assistant - not a problem. But as was
pointed out elsewhere, it might be best to make the requirement
explicit.
Yeah it should be.
--
Len Sorensen
--
To UNSUBSCRIBE, email to
On Mon, Apr 13, 2009 at 08:06:47PM +0200, Fabio Rosciano wrote:
Hello everyone,
180.44-2 still does not build against 2.6.28, but it does build fine
against 2.6.29, both debian stock kernels and headers.
linux-kbuild are homemade since they seem to be missing from unstable
and they are
On Mon, Apr 13, 2009 at 09:48:44PM +0200, Fabio Rosciano wrote:
I will admit I have not understood half of what you wrote, however
modifying that line as you suggest and then launching:
j...@nostromo:~$ sudo m-a a-i -O -l 2.6.28-1-amd64 nvidia
built the package correctly.
I have not
On Mon, Apr 13, 2009 at 09:59:54PM +0200, Andreas Tscharner wrote:
Lennart Sorensen wrote:
What method are you using to do the build?
kdist_image makes me thing you are using make-kpkg.
Yes, like I always did before. I though that would be the preferred
method. Is this no longer the case
On Mon, Apr 13, 2009 at 01:28:26PM -0700, Randall Donald wrote:
On Mon, 2009-04-13 at 14:07 -0400, Lennart Sorensen wrote:
Yup. I will try again though. Maybe I am on crack.
Or perhaps I am wrong and it still works.
I will have a look at whether make-kpkg still works or not, since it
should
On Mon, Apr 13, 2009 at 09:54:19PM +0200, Andreas Tscharner wrote:
Randall Donald wrote:
On Sun, 2009-04-12 at 10:52 +0200, Andreas Tscharner wrote:
Package: nvidia-kernel-source
Version: 180.44-1
Severity: normal
The package does not build here either, but it fails with the following
On Tue, Apr 21, 2009 at 01:02:33PM +0200, Olivier Berger wrote:
On Tue, Apr 07, 2009 at 04:23:53PM -0400, Lennart Sorensen wrote:
I just posted a patch to the mailing list that makes 180.29 build
perfectly with 2.6.29-2 and also works with linux-modules-nonfree-2.6,
which is something we
On Mon, Apr 27, 2009 at 05:53:06PM +0200, Anders Lager??s wrote:
Package: nvidia-kernel-source
Version: 180.44-2
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
dh_strip
dh_compress
dh_fixperms
dh_installdeb
dh_gencontrol -- -v
dpkg-gencontrol: unknown option `-v'
On Mon, Apr 27, 2009 at 08:23:51PM +0200, Anders Lagerås wrote:
On Mon, 27 Apr 2009 14:09:05 -0400
lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
On Mon, Apr 27, 2009 at 05:53:06PM +0200, Anders Lager??s wrote:
Package: nvidia-kernel-source
Version: 180.44-2
Severity: normal
On Mon, Apr 27, 2009 at 11:15:16PM +0200, Johann Glaser wrote:
Package: nvidia-kernel-legacy-173xx-source
Version: 173.14.18-1
Severity: grave
Justification: renders package unusable
No it doesn't. It works fine with module-assistant.
Running make-kpkg modules as root with unset $LANG
On Tue, Apr 28, 2009 at 05:10:54PM +0200, Anders Lagerås wrote:
I don't use module-assistant
with debian/rules binary_modules
Well that's the problem then. So far it was only tested and setup to
work with module-assistant and linux-modules-2.6-nonfree.
What arguments/environment do you pass
On Tue, Apr 28, 2009 at 12:24:26PM -0700, Randall Donald wrote:
On Tue, 2009-04-28 at 15:06 -0400, Lennart Sorensen wrote:
On Tue, Apr 28, 2009 at 05:10:54PM +0200, Anders Lagerås wrote:
I don't use module-assistant
with debian/rules binary_modules
Well that's the problem then. So
On Tue, Apr 28, 2009 at 09:45:59PM +0200, Anders Lagerås wrote:
On Tue, 28 Apr 2009 15:06:49 -0400
lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
On Tue, Apr 28, 2009 at 05:10:54PM +0200, Anders Lagerås wrote:
I don't use module-assistant
with debian/rules binary_modules
Sane only intends to support the WARMING_UP status in 1.1.0 and since
current is 1.0.20, kdegraphics (specifically libksane) is wrong for
trying to use it. It should have appropriate #ifdef's to check if it
is defined and it not, fall back to a delay loop or similar, just as
the upsteam sane code
Here is a patch that does something similar to what sane itself does
and makes libksane (and all of kdegraphics) compile again. kdegraphics
4.2.3 has the same bug still.
diff -ruN libs.ori/libksane/libksane/sane_widget.cpp
libs/libksane/libksane/sane_widget.cpp
---
On Mon, Aug 24, 2009 at 03:59:27PM -0700, Randall Donald wrote:
On Sun, 2009-08-23 at 18:28 +0300, David Baron wrote:
Package: nvidia-glx-legacy-71xx
Severity: grave
Justification: renders package unusable
Installing this baby will happily remove all of xorg.
Not surprising since
On Sun, Mar 28, 2010 at 12:48:32PM +0100, Julian Gilbey wrote:
On Sat, Mar 27, 2010 at 05:29:04PM -0700, Russ Allbery wrote:
Julian Gilbey j...@polya.uklinux.net writes:
No, it was compilation problems, which I think are to do with the
kernel-headers common package business. Indeed, I
On Tue, Oct 05, 2010 at 07:08:03PM +0200, Jürgen Leibner wrote:
If there would be an addititional menu which gives one the possibility to
choose such a mixed system then I would be able to choose a mixed system.
But in this case, there is an Install, suggesting a 32-bit overall system
and on
On Tue, Oct 05, 2010 at 06:27:55PM +0200, Petter Reinholdtsen wrote:
This is the /proc/cpuinfo in the i686 kvm guest:
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 2
model name : QEMU Virtual CPU version 0.10.0
stepping: 3
cpu MHz
On Tue, Oct 05, 2010 at 08:42:18PM +0200, Jürgen Leibner wrote:
On Tuesday 05 October 2010 19:41 Lennart Sorensen wrote:
...
Most people would prefer the 64bit kernel with 32bit userspace. I
think there is an option in expert mode to select your kernel
yourself from a list, but unless
On Tue, Oct 05, 2010 at 11:07:15PM +0200, Petter Reinholdtsen wrote:
affects 599200 qemu-kvm
thanks
[Lennart Sorensen]
The 'lm' flag means this system has 64bit support. If in fact it
doesn't, then the VM is broken. The installer did the right thing
based on the CPU feature flags
On Wed, Oct 06, 2010 at 12:01:45AM +0200, Petter Reinholdtsen wrote:
[Lennart Sorensen]
I suspect if you run kvm with the -cpu option you can specify what
you desire. I believe the default is to simply match whatever the
host has, so if the host has a 64bit cpu, then the guest will too
On Wed, Oct 06, 2010 at 12:53:04AM +0200, Petter Reinholdtsen wrote:
[Lennart Sorensen]
Well try starting the kvm with '-cpu qemu32'. That should provide
the feature flags of a nice 32bit x86.
I tried this by adding
cpu match='exact'
modelqemu32/model
/cpu
to the libvirtm
On Wed, Oct 06, 2010 at 04:55:18PM +0200, Jan Luebbe wrote:
Hi, i'm the maintainer of the qemu-kvm package and have now tried
serveral combinations:
Host with 64-bit CPU and 32bit squeeze kernel/userspace and 32bit lenny
or squeeze netinst as guest:
lm in the host's /proc/cpuinfo but
On Fri, Oct 29, 2010 at 11:08:59AM -0500, Lukasz Szybalski wrote:
It seems like Grub.cfg is also using proper drive by UUID.
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-amd64' --class debian
--class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
On Fri, Dec 02, 2011 at 11:37:34AM +, Hector Oron wrote:
Hello Lennart,
On Tue, Aug 30, 2011 at 10:08:29AM -0400, Lennart Sorensen wrote:
On Mon, Aug 29, 2011 at 11:48:34PM +0200, Lucas Nussbaum wrote:
Ruby 1.9.3 is going to be released in september, and is a candidate
On Fri, Dec 02, 2011 at 11:37:34AM +, Hector Oron wrote:
Lennart, could you try to rebuild on armhf, we are trying to bootstrap armhf
in
official main and contrib Debian archive, but build seems to hang:
See
On Sat, Dec 03, 2011 at 01:35:40PM -0500, Lennart Sorensen wrote:
On Fri, Dec 02, 2011 at 11:37:34AM +, Hector Oron wrote:
Lennart, could you try to rebuild on armhf, we are trying to bootstrap
armhf in
official main and contrib Debian archive, but build seems to hang:
See
On Fri, Dec 16, 2011 at 09:54:06AM -0500, Chris wrote:
Package: installation-reports
Severity: critical
Justification: breaks the whole system
The system will run a for upto an hour under causual usage (browsing the web,
checking email, writing openoffice docs, etc.). Then suddenly, the
On Fri, Dec 16, 2011 at 08:04:27PM +0100, Christian PERRIER wrote:
Hmmm, from this, I wonder whether I should just close the bug or
reassign it to another package. For sure, we can't keep it assigned to
installation-reports
Certainly either the kernel has a bug for this particular nvidia
On Fri, Mar 02, 2012 at 02:27:46PM +0100, cbd wrote:
Additional notes on 659116 posted by David Kennedy.
Problem: 'grub2' not installing on /boot partition during installation
of Debian Squeeze.
Installation mode: Graphical expert.
Package: grub-installer
Version: 20110106+squeeze4
On Sun, Sep 04, 2011 at 08:47:59AM +0200, Reinhard Tartler wrote:
I strongly disagree that this arch specific defect on ppc is in any way
a blocking bug for recompiling moc-ffmpeg-plugin against the new libav
libraries. It only affects (some?) altivec enabled machines and can be
easily
On Sun, Sep 04, 2011 at 04:13:52PM -0400, Lennart Sorensen wrote:
Are there any that don't experience it?
I just tried running ffmpeg on a power6+ machine under gdb and got:
Program received signal SIGSEGV, Segmentation fault.
0x0f6ff37c in ff_fft_calc_altivec () at
/root/libav-0.7.1
On Mon, Aug 29, 2011 at 11:48:34PM +0200, Lucas Nussbaum wrote:
Ruby 1.9.3 is going to be released in september, and is a candidate for
the default ruby version in wheezy. A snapshot is available in
experimental. Now is an ideal time to work on porting issues and get the
fixes integrated
I see in the sources of bcov that only x86 and x86_64 are supported,
so tring to build on anything else is a waste of time. It will fail
with the #error about not knwing how to do breakpoints.
Seems that flagging it as arch: i386 amd64, would take care of not
wasting the other ports time.
--
On Wed, May 30, 2012 at 10:20:36PM -0400, Mike Bianchi wrote:
Package: installation-reports
Severity: grave
Tags: d-i
Justification: renders package unusable
While installing squeeze from a netinstall cd, after entering the user name
and password,
the message No disk drive was detected
Installing libvtk5.8 and tcl-vtk version 5.8.0-12 makes the symbol
problem go away and volview starts fine. Install 5.8.0-13 or 5.8.0-13+b1,
and the problem occours again.
Not sure which of this caused a problem:
vtk (5.8.0-13) unstable; urgency=low
* Make sure to include VTK/QT cmake file.
On Tue, Apr 16, 2013 at 03:40:51PM -0400, Lennart Sorensen wrote:
Installing libvtk5.8 and tcl-vtk version 5.8.0-12 makes the symbol
problem go away and volview starts fine. Install 5.8.0-13 or 5.8.0-13+b1,
and the problem occours again.
Not sure which of this caused a problem:
vtk
I tried applying the patch from message #16 at
http://code.google.com/p/openvpn-auth-ldap/issues/detail?id=31 and then
changing the runtime from 'GNU' to 'modern' (after running autoconf to
update configure), and also adding libgnustep-base-dev as a Build-Dep.
The result is that it doesn't
Why should the testsuit fail just because of the date you rebuild it?
That seems like a really bad design. And this keeps happening again
and again with devscripts and its use of distro-info-data.
It seems that the test is wrong if it stops working after a certain date.
--
Len Sorensen
--
On Sat, Oct 04, 2014 at 03:48:27PM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
OK, we will need a powerpc machine with more RAM available than the current
powerpc porterbox.
Debian PPC porters: can anyone build qtwebkit with a machine with at least
8GB
of RAM+swap and the included
On Sun, Oct 05, 2014 at 10:36:56AM -0300, Lisandro Damián Nicanor Pérez Meyer
wrote:
Current sid's qtwebkit (2.3.4.dfsg-2)
ppc users says it crashes upon certain time (which seems to be not much).
What
I need is a proper backtrace generated with the patched qtwebkit.
JFTR, qtwebkit
On Mon, Oct 06, 2014 at 10:09:10AM -0400, Lennart Sorensen wrote:
Compiling now.
dpkg-source hates some of the patches in the package and refuses to
unpack it. quilt is fine with it, and using quilt refresh on the patches
makes dpkg-source happy. Seems using a/... and b/... is no longer
On Mon, Oct 06, 2014 at 10:40:56AM -0400, Lennart Sorensen wrote:
On Mon, Oct 06, 2014 at 10:09:10AM -0400, Lennart Sorensen wrote:
Compiling now.
dpkg-source hates some of the patches in the package and refuses to
unpack it. quilt is fine with it, and using quilt refresh on the patches
On Sat, Mar 22, 2014 at 11:53:23AM +0100, intrigeri wrote:
intrigeri wrote (20 Jan 2014 17:58:03 GMT) :
https://rt.cpan.org/Ticket/Display.html?id=89552
Sure. Debian porters, I'll let you subscribe to the RT ticket, and
hopefully take care of this porting problem.
I'd like to see this RC
On Wed, Nov 19, 2014 at 08:37:15PM +, Edmund Grimley Evans wrote:
Finding out which armhf machines have NEON is depressingly difficult,
but I think that abel (Marvell Armada 370/XP CPU @ 1.6GHz on a
Marvell MV78460 SoC Development Board (ARM v7)) doesn't have NEON and
the others do, so it
install-mbr's code currently uses bytes 442 to 445 to store the version
of mbr's data structure (currently 2) and the signature.
So to change this would change the data structure format in a totally
non backwards compatible way (so older install-mbr versions would no
longer recognize this as an
On Mon, Nov 24, 2014 at 09:58:42AM +0100, Santiago Garcia Mantinan wrote:
I think this bug can be fixed, at least on the standard version of mbr (not
on the Y2K version, but machines needing that won't run Windows7 or later
anyway). The problem is that the changes needed point to an upstream
1 - 100 of 134 matches
Mail list logo
