On Mon, Sep 25, 2023 at 02:03:35AM +0200, Bastian Blank wrote:
> The current way does not work. See all the bug reports about
> uninstallable packages and what not with dkms.
>
> To build modules against version x, you'll need to install version x of
> the headers, not x-1 or x+1. This
On Mon, Jan 10, 2022 at 05:10:04PM -0800, Vagrant Cascadian wrote:
> Package: u-boot
> Version: 2022.01+dfsg1-1
> Severity: serious
> X-Debbugs-Cc: debian-powe...@lists.debian.org, q...@packages.debian.org,
> binut...@packages.debian.org
>
> Something in the toolchain recently changed which
Now Debian has a release with a useful package missing. What ever
happened to orphaning a package if you didn't want to maintain it anymore?
I certainly see nothing that make the claim that it isn't suitable for
release justified. It is working very well and does not appear to have
any serious
On Tue, Sep 08, 2020 at 05:35:45PM -0400, Lennart Sorensen wrote:
> On Tue, Sep 08, 2020 at 10:35:26PM +0200, Andreas Tille wrote:
> > Control: tags -1 help
> >
> > Hi Debian Arm team,
> >
> > I admit I have no idea how to deal with this except by excluding
>
On Tue, Sep 08, 2020 at 10:35:26PM +0200, Andreas Tille wrote:
> Control: tags -1 help
>
> Hi Debian Arm team,
>
> I admit I have no idea how to deal with this except by excluding
> arm64 from the list of supported architectures which is definitely
> not my prefered way of action.
>
> Any help
I found this:
https://bugs.freedesktop.org/show_bug.cgi?id=66722
Seems to indicate they have no intention of supporting python3 since
they believe it can be used from python3 in a different way already.
So semms they think the answer in python3 is to use GObject Introspection
(GIR)
--
Len
On Fri, Jan 26, 2018 at 04:21:08PM +0100, melissa M. wrote:
> Package: debian-installer
> Version: stable
> Severity: grave
>
> hi maintainer,
>
> big graphical bug with the installer netinstall of Debian Stretch 9.3, but
> also Testing and Sid.
>
> Ditto with the installer mini iso-Stretch 9.3
On Mon, Oct 31, 2016 at 04:18:55PM +0100, Cyril Brulebois wrote:
> No, the “certainly did” and “worked fine” bits are wrong.
>
> And that's not just me, we've had users report it, Philip Hands saw it
> as well. So no it did *NOT* work (in the specific case where it actually
> matters).
Yes,
On Sun, Oct 30, 2016 at 05:28:57PM +0100, Cyril Brulebois wrote:
> Package: debootstrap-udeb
> Version: 1.0.85
> Severity: grave
> Justification: renders package unusable
>
> The (re)addition of InRelease support broke debootstrap(-udeb) in a d-i
> context. The sed|tr|sed dance doesn't kill the
On Fri, Feb 19, 2016 at 03:10:08PM -0500, Yaroslav Halchenko wrote:
>
> On Fri, 19 Feb 2016, Lennart Sorensen wrote:
>
> > On Fri, Feb 19, 2016 at 12:11:35PM -0500, Yaroslav Halchenko wrote:
> > > Thanks for looking into it. Fwiw, for such cases better to use python
On Fri, Feb 19, 2016 at 12:11:35PM -0500, Yaroslav Halchenko wrote:
> Thanks for looking into it. Fwiw, for such cases better to use python-dbg so
> you could then py-bt and do more introspection within attached gdb. You would
> need -dbg packages for numpy etc
I hadn't ever needed to debug
On Thu, Feb 18, 2016 at 04:35:09PM -0500, Lennart Sorensen wrote:
> On Mon, Feb 15, 2016 at 08:36:49AM -0500, Yaroslav Halchenko wrote:
> >
> > On Thu, 02 Jul 2015, Aaron M. Ucko wrote:
> >
> > > Source: pandas
> > > Version: 0.16.2+git65-g054821d-1
>
On Mon, Feb 15, 2016 at 08:36:49AM -0500, Yaroslav Halchenko wrote:
>
> On Thu, 02 Jul 2015, Aaron M. Ucko wrote:
>
> > Source: pandas
> > Version: 0.16.2+git65-g054821d-1
> > Severity: serious
> > Justification: fails to build from source (but built successfully in the
> > past)
>
> > The
On Thu, Dec 24, 2015 at 12:33:31AM +0100, Gianluca Renzi wrote:
> In this case I suppose even the userspace code (dynamic linking library)
> could not to be used
> with this linker bug and not only the kernel module loader tool. The
> undefined symbols are discarded in every way. The only way to
I just tried building and installing binutils from sid on jessie, and
then building a kernel module for the current kernel on the machine.
Module built with binutils from jessie loads fine, modules built with
binutils from sid has the mcount symbol error.
So I would agree, these two bugs do not
I found indications that perhaps both problems are in fact caused by ld
no longer including undefined symbols in the output.
Here is a section from the working module built with old binutils:
0012980: 0047 4343 3a20 2844 6562 6961 6e20 342e .GCC: (Debian 4.
0012990: 392e 322d 3130 2920 342e
On Mon, Dec 21, 2015 at 12:19:17PM -0500, wrote:
> I was looking at the module headers and found this pattern:
>
> In 4.2.1-2, 4.2.5-1, and 4.2.6-1 the order of the header for fat.ko says:
>
> 17 .data.rel.ro 01c0 00011418 2**3
>
On Mon, Dec 21, 2015 at 02:55:16PM -0500, wrote:
> I tried various binutils versions, and any version starting from
> 2.25.51.20151014-1 seems to be reordering the sections, even though
> the arch/powerpc/kernel/vmlinux.lds file explicitly says to use the
> order with .toc at the end. So somehow
I was looking at the module headers and found this pattern:
In 4.2.1-2, 4.2.5-1, and 4.2.6-1 the order of the header for fat.ko says:
17 .data.rel.ro 01c0 00011418 2**3
CONTENTS, ALLOC, LOAD, RELOC, DATA
18 .opd 0af8
On Fri, Apr 24, 2015 at 10:01:19AM +0200, Christoph Biedl wrote:
The report against php5 is #783107. This is #783108 against file. However, do
you have any indication file is affected? I'd already written an analysis
about
this but accidentially sent it to #783099, I could not reproduce the
Taken from testcase in php bug report and run on amd64 sid.
/tmp/test.php:
?php
$string = '';
// These two in any order
$string .= \r\n;
$string .= ;
// Total string length 8192
$string .= str_repeat(chr(rand(32, 127)), 8184);
// Ending in this string
$string .= say;
$finfo = new
Applying the patch linked to above
(https://git.php.net/?p=php-src.git;a=commitdiff;h=f938112c495b0d26572435c0be73ac0bfe642ecd)
makes the segfault go away and the expected output occur.
So this bug IS in php (and also exist in file apparently). Reassigning to
file is wrong, given the bug exists
There is a bug (726530) that mentions random segfaults in fvwm. I wonder
if this one is related. It sure sounds much more like an fvwm bug than
a gimp bug. Sure gimp might be good at triggering it, but I don't think
it is correct at all to assign the bug to gimp. That is not likely to
get a
On Sun, Mar 08, 2015 at 09:48:50PM +0100, Aurelien Jarno wrote:
Thanks for your work, it's nice we have been able to understand the real
issue.
Well I thing the best summary of the problem is that the aux-cache
handling code is awful and doesn't check anything before using the
incoming data as
Here is a patch which I believe should detect a modern MBR format
and refuse to overwrite it, and hence avoid breaking windows vista+,
although of course with an option to use --force to do it anyhow.
I did not test it yet since I don't have a system handy that I could
test it on.
Fixing
On Sun, Mar 01, 2015 at 10:22:05PM +0100, Niels Thykier wrote:
Excellent, thanks.
I am taking the liberty of adding the patch tag for this one. If
nothing else, I would greatly appreciate having ldconfig not seg. fault. :)
That makes sense to me.
Sounds like the aux-cache could do with a
I looked at ways the aux-cache could cause a segfault, and given the
file is mmap'd and has data offsets in it that are used as pointers
without being checked it is not hard to see how a corrupt file could
cause a segfault. The following patch makes the segfaults I was able
to think of and create
The biggest change between grub 1.99 and 2.00 that I think could be an
issue is taht it started reading EDID data from the monitor and using
that to try and select the mode to use. So if 1.99 worked with the
default mode, and 2.00 no longer does, quite likely there is something
wrong with reading
On Mon, Feb 09, 2015 at 06:29:47AM +0100, Heiko Ernst wrote:
This is my etc/network/interfaces file I have wrote hope this is a workaround
for this time but why show me the network manager in kde not the connection?
I
see only a ? over the icon.
I believe that any interface you put in
On Tue, Nov 25, 2014 at 04:35:52PM -0500, wrote:
Hmm, interesting, I can try and see if I can reproduce it on more systems.
So the machine I was building on is an IBM x3650 with 2 quad core 2.5GHz
xeons. Kernel is amd64, userspace is i386 wheezy, chroot is i386 jessie
buildd variant.
So
On Wed, Nov 26, 2014 at 05:16:43PM +0100, Simon Chopin wrote:
I think we should downgrade it and maybe tag it moreinfo, but it
shouldn't be closed. The case of a Jessie kernel on a machine running a
kernel that is not Jessie's is a valid use case IMHO.
Not that I'm volunteering to track down
Source: pytest
Version: 2.6.3-2
Severity: serious
Justification: fails to build from source
Dear Maintainer,
I was trying to do a rebuild of some of the packages in jessie, and
pytest fails the testsuite for python3.4 as far as I can tell.
I used debootstrap --variant=buildd to create a jessie
Source: pytest
Version: 2.6.3-2
Severity: serious
Justification: fails to build from source
Dear Maintainer,
I was trying to do a rebuild of some of the packages in jessie, and
pytest fails the testsuite for python3.4 as far as I can tell.
I used debootstrap --variant=buildd to create a jessie
On Tue, Nov 25, 2014 at 08:55:05PM +0100, Sebastian Ramacher wrote:
Control: tags -1 + moreinfo unreproducible
On 2014-11-25 11:43:32, Lennart Sorensen wrote:
Source: pytest
Version: 2.6.3-2
Severity: serious
Justification: fails to build from source
Dear Maintainer,
I
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
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 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
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, 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 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
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 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
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 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
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 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 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 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 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 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
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 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
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 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 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 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 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 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 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
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
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
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:
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 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
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
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 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
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 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 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
1 - 100 of 134 matches
Mail list logo
