The title of this bug is misleading.
Package: libx11-6
Version: 2:1.0.3-6
Severity: important
It should read:
Package: libx11-6
Version: 2:1.0.3-7
Severity: important
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
The title of this bug is misleading.
Package: libx11-6
Version: 2:1.0.3-6
Severity: important
It should read:
Package: libx11-6
Version: 2:1.0.3-7
Severity: important
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
The title of this bug is misleading.
Package: libx11-6
Version: 2:1.0.3-6
Severity: important
It should read:
Package: libx11-6
Version: 2:1.0.3-7
Severity: important
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: autofs
Version: 4.1.4+debian-1
Attached is a patch to fix auto.smb so it can handle double spaces in file share
names (using gsub instead of sub) and also default administration shares.
Autofs did not like the $ symbol in front of the default window share names.
--CUT--
$SMBCLIENT
Steinar H. Gunderson wrote:
On Sat, Mar 24, 2007 at 09:00:22AM -0700, C.Y.M wrote:
After I updated to the latest stable kernel (2.6.20.4), I have been noticing
the
follow errors in syslog. Did the api change? Is there a patch for
nfs-kernel-server? I did not have this problem
Debian Bug Tracking System wrote:
Thank you for the problem report you have sent regarding Debian.
This is an automatically generated reply, to let you know your message has
been received. It is being forwarded to the package maintainers and other
interested parties for their attention; they
Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
#414669: [PATCH] missing link for libwfb.so,
which was filed against the nvidia-glx package.
It has been marked as closed by one of the developers, namely
Randall Donald [EMAIL PROTECTED].
You
Package: cdfs-src
Version: 2.4.20.a+2.6.18-1
Attached is a patch to fix cdfs so it builds with kernels 2.6.19+.
Regards.
diff -ru cdfs/2.6/audio.c cdfs-2.6.20/audio.c
--- cdfs/2.6/audio.c 2006-10-24 12:44:49.0 -0700
+++ cdfs-2.6.20/2.6/audio.c 2006-12-11 12:30:47.0 -0800
@@
Package: lufs-source
Version: 0.9.7-8.1
Attached is a patch to fix the api in lufs to build with kernels 2.6.19+ (the
patch for 2.6.18 is not included, refer to bug #388389).
Regards.
--- lufs/kernel/Linux/2.6/inode.c.orig 2007-03-24 07:15:06.0 -0700
+++ lufs/kernel/Linux/2.6/inode.c
Package: nfs-kernel-server
Version: 1.0.12-4+b1
After I updated to the latest stable kernel (2.6.20.4), I have been noticing the
follow errors in syslog. Did the api change? Is there a patch for
nfs-kernel-server? I did not have this problem with 2.6.17.14 kernels and nfs.
nfsd[16801]: nfssvc:
The problem turned out to be a bad patch introduced in xserver-xorg-core. Please
close.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
I tried removing 42_build_int10_submodules.diff from the patches and rebuild
everything but I still had the same problem. Was there more to revert than just
taking out this patch? I would be happy to test this if I could revert it back
all the way.
Best Regards.
--
To UNSUBSCRIBE, email to
I tried removing 42_build_int10_submodules.diff from the patches and rebuild
everything but I still had the same problem. Was there more to revert than just
taking out this patch? I would be happy to test this if I could revert it back
all the way.
Best Regards.
--
To UNSUBSCRIBE, email to
Package: nvidia-glx
Version: 1.0.9746-2
I was getting a error in Xorg.0.log about a missing shared object. The problem
is that nvidia names the .so differently. The attached patch fixes the problem.
--- nvidia-graphics-drivers-1.0.9746/debian/nvidia-glx.links.in 2007-03-13
00:03:21.0
Package: nvidia-glx
Version: 1.0.9746-2
I am having the following problem loading the int10 submodule with the latest
nvidia drivers. I can not determine if this is an issue with nvidia or with
xserver-xorg-core.
ii xserver-xorg-core 1.1.1-20 X.Org X server -- core
Package: xserver-xorg-core
Version: 1.1.1-20
I am having the following problem loading the int10 submodule with the all my
different nvidia drivers. The nvidia developers tell me this is an issue with
xserver-xorg-core.
This is what Xorg.0.log has in it. I do not see any errors about missing
Additional info as requested.
Thank you.
X Window System Version 7.1.1
Release Date: 12 May 2006
X Protocol Version 11, Revision 0, Release 7.1.1
Build Operating System: UNKNOWN
Current Operating System: Linux nofear 2.6.17.14.20070307.1 #1 PREEMPT Wed Mar
7 17:02:35 PST 2007 i686
Build Date:
I am having the same problem. Although I see one other bug in your log file
that is part of the nvidia-glx package.
I have submitted a patch to fix the libwfb.so missing file error.
Refer to bug# 414669
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
Package: xserver-xorg-core
Version: 1.1.1-20
I am having the following problem loading the int10 submodule with the all my
different nvidia drivers. The nvidia developers tell me this is an issue with
xserver-xorg-core.
This is what Xorg.0.log has in it. I do not see any errors about missing
Additional info as requested.
Thank you.
X Window System Version 7.1.1
Release Date: 12 May 2006
X Protocol Version 11, Revision 0, Release 7.1.1
Build Operating System: UNKNOWN
Current Operating System: Linux nofear 2.6.17.14.20070307.1 #1 PREEMPT Wed Mar
7 17:02:35 PST 2007 i686
Build Date:
I am having the same problem. Although I see one other bug in your log file
that is part of the nvidia-glx package.
I have submitted a patch to fix the libwfb.so missing file error.
Refer to bug# 414669
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
Package: util-linux
Version: 2.12r-14
When hwclock.sh was set to 11 (since we need / to be writable for the adjfile),
it started causing timestamp errors when checking / on reboot (with
S10checkroot.sh). This only affects systems with /usr on a separate partition
and is related to bug # 342887.
>>
>> Thank you for the confirmation. Please include me in this thread if
>> someone
>> finds the answer. This bug seems to occur very frequently on my
>> machine with
>> 2.6.18.1 so I have been forced to revert back to 2.6.17.13 until I can
>> fix it.
>
> I haven't got around to looking at it
Thank you for the confirmation. Please include me in this thread if
someone
finds the answer. This bug seems to occur very frequently on my
machine with
2.6.18.1 so I have been forced to revert back to 2.6.17.13 until I can
fix it.
I haven't got around to looking at it yet, sorry.
Package: nvidia-glx-dev
Version: 1.0.8776-1
There are a few minor bugs that should be cleaned up in the debian packaging
scripts for nvidia.
1) nvidia-glx-dev.links and nvidia-glx-dev.links.in create malformed links
because a # exists before the link name in the links file. Also, the second
2) A diversion is created and referenced to /usr/lib/libGL.so.1.2 (but this
link
is never created in /usr/lib).
I'm not sure what you are getting at here. /usr/lib/libGL.so.1.2 from
libgl1-mesa-glx is diverted to /usr/lib/nvidia/libGL.so.1.2.xlibmesa
which shows up if libgl1-mesa-glx is
So, the libraries in /usr/lib/nvidia are not really used, but kept to store
the
diverted file? I guess I got confused when I saw this in /usr/lib/nvidia:
-rw-r--r-- 1 root root 425320 2006-10-13 03:55 libGL.so.1.2.xlibmesa
lrwxrwxrwx 1 root root 19 2006-11-14 08:53
Oliver Endriss wrote:
Hm - it compiles here without any warnings. ;-(
Maybe some problem with macro expansion.
The attached patch replaces the macros by inline functions.
Does it work now?
That fixed it. It compiles with no warning now, using a 2.6.17.13 kernel.
Thanks! Seems to be working
Oliver Endriss wrote:
Hi,
Thanks to Hartmut, I2C transfers of the saa7146 may now use interrupt
mode. It will be enabled for av7110, budget, budget-ci and budget-av
drivers. This might reduce cpu load and speed-up tuning.
For testing the changesets are in my repositories:
-
Package: nvidia-kernel-source
Version: 1.0.9625-2
Severity: important
The paths are incorrect in the build rules when trying to apply the debian
patches to the source code before building the nvidia-kernel module with
make-kpkg. Also, the patches are not reversing properly when the rules cleans
Chad Flynt wrote:
I am sure this is more widespread than people imagine. I know that
everyone I talk to has this issue. But most don't participate on the
ML. There are forums that have talked bout it all over. Most of us
have just as said, gotten used to it and assumed it will never be
Udo Richter wrote:
C.Y.M wrote:
mplayer -vo mpegpes -ao mpegpes -framedrop -cache 4096 -slave -nolirc
-quiet 001.vdr
Notice that -framedrop is added to the command line. I wonder if
that is the
reason why mplayer is immune to the a/v desync problem.
Definitely not just that. My playback
Torgeir Veimo wrote:
On 22 Oct 2006, at 22:33, C.Y.M wrote:
And just for completeness: No serious CPU load when playing back with
VDR or mplayer.
Yes, if the extra CPU load by mplayer is not even noticeable when
playing back
VDR recordings, and it is not prone to any type or desync
Udo Richter wrote:
C.Y.M wrote:
Utilizing mpegpes is really the best of
both worlds. We would still be using the video output on the FF card
but having
software to process the actual mpeg decoding. There would be no
transcoding
involved because obviously the recording would already
Klaus Schmidinger wrote:
C.Y.M wrote:
... [ problem with A/V desync ]
I would have to say that this is exactly the same thing I have been
experiencing
for years and years. But, this never happens with budget cards.. only
FF cards.
I'm not sure what you mean here. Budget cards can't
My theory is that since audio is typically 600ms ahead of video, maybe
the audio buffers run over. Strange thing is why this happens
reproducible on blackness. Maybe due to extremely low bit rate in this
situation, more frames get packed into one data block, causing data flow
to be
Tero Siironen wrote:
On 20.10.2006 15.09, Klaus Schmidinger [EMAIL PROTECTED]
wrote:
C.Y.M wrote:
Since it has been several years now and I have never been able to solve the
a/v
desync issues with my Nexus-S FF card when playing back recordings...
I'm replaying many recordings (actually
Udo Richter wrote:
Tero Siironen wrote:
However, like Pasi Juppo told earlier in other thread, in last weeks
episode
of Lost there was many fadeout-fadeins between scenes and a/v desync
happened on every one of these.
I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade
C.Y.M wrote:
Udo Richter wrote:
Tero Siironen wrote:
However, like Pasi Juppo told earlier in other thread, in last weeks
episode
of Lost there was many fadeout-fadeins between scenes and a/v desync
happened on every one of these.
I've 'heard of such problems' on ATV+ and Lost. Whenever
Juri Haberland wrote:
Klaus Schmidinger [EMAIL PROTECTED] wrote:
C.Y.M wrote:
Since it has been several years now and I have never been able to solve the
a/v
desync issues with my Nexus-S FF card when playing back recordings...
I'm replaying many recordings (actually most of what I watch
mlists wrote:
I'm running VDR 1.4.3 with hoochster's patches.
I've install xine but I'm not getting any audio. When vdr starts up and
then xine -- I'm getting this:
vdr-xine: Client connecting ...
vdr-xine: Client connected!
[VM]buffered 50.2 frames (v:50.2, a:0.0)
buffered 51.5 frames
Since it has been several years now and I have never been able to solve the a/v
desync issues with my Nexus-S FF card when playing back recordings, I was
thinking about what could be done. As of now, I have been using xine with my FF
card to fix the problem. But, if I use xine, then even live tv
This bug seems to have resurfaced with 2.86.ds1-33. Is this still a lsb-base
issue? Any idea how to fix it again?
Best Regards.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
C.Y.M wrote:
This bug seems to have resurfaced with 2.86.ds1-33. Is this still a lsb-base
issue? Any idea how to fix it again?
As a workaround to this bug, I have rebuilt the ncurses-bin package to place
tput in /bin/tput instead of /usr/bin/tput. Unless there is a better
suggestion
This bug seems to have resurfaced with 2.86.ds1-33. Is this still a lsb-base
issue? Any idea how to fix it again?
Best Regards.
___
Pkg-sysvinit-devel mailing list
Pkg-sysvinit-devel@lists.alioth.debian.org
C.Y.M wrote:
This bug seems to have resurfaced with 2.86.ds1-33. Is this still a lsb-base
issue? Any idea how to fix it again?
As a workaround to this bug, I have rebuilt the ncurses-bin package to place
tput in /bin/tput instead of /usr/bin/tput. Unless there is a better
suggestion
When I look at the control file for nvidia-glx 1.0.8774-3 , I see the
following:
Package: nvidia-glx
Architecture: i386 amd64
Depends: nvidia-kernel-1.0.8762, x11-common (= 1:7.0.0), ${shlibs:Depends}
Suggests: nvidia-settings, nvidia-kernel-source (= 1.0.8762)
Conflicts:
Package: nvidia-glx
Version: 1.0.8774-3
Severity: important
nvidia-glx package conflicts with xorg 7.1 because xorg now provides the virtual
xserver-xorg-video package. A solution would be to remove xserver-xorg-video
provides from the nvidia-glx package.
--
To UNSUBSCRIBE, email to [EMAIL
Randall Donald wrote:
On Sun, 2006-10-08 at 08:14 -0700, C.Y.M wrote:
Package: nvidia-glx
Version: 1.0.8774-3
Severity: important
nvidia-glx package conflicts with xorg 7.1 because xorg now provides the
virtual
xserver-xorg-video package. A solution would be to remove
xserver-xorg-video
Randall Donald wrote:
On Sun, 2006-10-08 at 12:02 -0700, C.Y.M wrote:
Randall Donald wrote:
On Sun, 2006-10-08 at 08:14 -0700, C.Y.M wrote:
Package: nvidia-glx
Version: 1.0.8774-3
Severity: important
nvidia-glx package conflicts with xorg 7.1 because xorg now provides the
virtual
martin wrote:
Hey Darren,
since some days, the xine-lib has changed a bit, so your patches fail
against version 1.1.3. I've updated all necessary patches, to make xine-lib
running with the current cvs version. You may want to update our patches on
your site!
What about
C.Y.M wrote:
This is a quick hack that solves the build problem with kernel 2.6.18. This
is
not a backwards compatible patch.
Apparently, The 2.6.18 stats callback parameters have changed from 2.6.17 so
that it takes a struct dentry* rather than a struct super_block.
Revised patch applied
Eduard Bloch wrote:
#include hallo.h
* C.Y.M [Wed, Sep 20 2006, 07:33:55PM]:
This is a quick hack that solves the build problem with kernel 2.6.18. This
is
not a backwards compatible patch.
Stupid question: why do you need LUFS? I consider requesting its removal
because almost
David Härdeman wrote:
On Tue, October 3, 2006 2:33, C.Y.M said:
David Härdeman wrote:
This series of patches includes a number of bugfixes and changes to the
IR input handling of the budget-ci driver.
If these patches are successful, can they also be implemented into the
regular nexus-s ir
David Härdeman wrote:
On Tue, October 3, 2006 2:33, C.Y.M said:
David Härdeman wrote:
This series of patches includes a number of bugfixes and changes to the
IR input handling of the budget-ci driver.
If these patches are successful, can they also be implemented into the
regular nexus-s ir
David Härdeman wrote:
This series of patches includes a number of bugfixes and changes to the
IR input handling of the budget-ci driver.
They are based on the dvb-ir patchset by Darren Salt and the two budget-ci
patches that I recently sent to the list (meaning that they supercede
patches 1
Oliver Endriss wrote:
Torgeir Veimo wrote:
On 21 Sep 2006, at 09:03, Marko Mäkelä wrote:
On Sun, Sep 17, 2006 at 11:43:09AM +0100, Torgeir Veimo wrote:
Using the remote plugin with a /dev/input/eventX setup for a
hauppauge grey remote via a nova-t sensor with X11/Xv using
softdevice works
- Added -S option to ppmtoy4m call in example image convert script. Suggested
by
Thorsten Gehrig.
I was thinking of something more like this for backwards compatibility:
@@ -61,17 +61,23 @@
#
# now run the conversion
#
+
+# 'chroma subsampling mode' mjpegtools = 1.8.0
+if ppmtoy4m -h
Package: lufs-source
Version: 0.9.7-8
Severity: important
Build fails with kernel-2.6.18.
/usr/src/modules/lufs/kernel/Linux/2.6/inode.c:62: warning: initialization from
incompatible pointer type
/usr/src/modules/lufs/kernel/Linux/2.6/inode.c:414:5: warning:
KERNEL_VERSION_CODE is not defined
Package: cdfs-src
Version: 2.4.20.a+2.6.12-2
Severity: important
Build fails with 2.6.18 kernel release.
/usr/src/modules/cdfs/2.6/root.c:541: warning: initialization from incompatible
pointer type
/usr/src/modules/cdfs/2.6/root.c: In function `cdfs_get_sb':
Package: cdrs-src
Version: 2.4.20.a+2.6.12-2
Severity: important
Build fails with 2.6.18 kernel release.
/usr/src/modules/cdfs/2.6/root.c:541: warning: initialization from incompatible
pointer type
/usr/src/modules/cdfs/2.6/root.c: In function `cdfs_get_sb':
This is a patch that fixes the build problem with kernel 2.6.18. This is not a
backwards compatible patch.
Best Regards.
--- cdfs/2.6/root.c.orig 2006-09-20 18:15:33.0 -0700
+++ cdfs/2.6/root.c 2006-09-20 18:29:39.0 -0700
@@ -543,8 +543,8 @@
#ifdef OLD_KERNEL
static
This is a quick hack that solves the build problem with kernel 2.6.18. This is
not a backwards compatible patch.
Thanks.
--- lufs/kernel/Linux/2.6/inode.c.orig 2006-09-20 18:31:59.0 -0700
+++ lufs/kernel/Linux/2.6/inode.c 2006-09-20 18:33:02.0 -0700
@@ -510,9 +510,9 @@
Package: udev
Version: 0.100-1
Severity: important
Udev is unable to find firmware (/lib/firmware/dvb-ttpci-01.fw). DVB Drivers
fail to load because hotplug does not work. The previous version of udev works
fine.
BR.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
martin wrote:
Just add option -r script.sh
#!/bin/sh
case $1 in
before)
;;
after)
echo After recording $2
/usr/local/bin/startnoad.sh $2
;;
edited)
echo Edited recording $2
;;
*)
Udo Richter wrote:
C.Y.M wrote:
Thanks for your replay, but I was looking for a switch that would make
vdr run a
script right after vdr starts up.
If you want to start a program together with VDR, why don't you put it
into your runvdr script?
Because in the runvdr script, the vdr
Is there a command line switch that would allow me to define a command vdr must
excute after initial startup? I see one for before and after recordings, but I
am looking for a way to execute a command after startup only.
Best Regards.
___
vdr mailing
Here is an example of the changes that I have had to make to runvdr so that my
nexus-s works. I have added a maximum retry value to runvdr so that vdr will
not keep attempting to start over and over if there is a major problem with
reception. Also, I have added a minimum runtime (in seconds)
I have been trying to clean up my builds and when updated softdevice and
softplay via cvs, noticed several warning about unused variables. Also, it
appears that softplay does not have the current Makefile fixes required to build
under the latest VDR.
Best Regards,
---
C.Y.M wrote:
I have been trying to clean up my builds and when updated softdevice and
softplay via cvs, noticed several warning about unused variables. Also, it
appears that softplay does not have the current Makefile fixes required to
build
under the latest VDR.
And this one too..
BR
Darren Salt wrote:
I demand that Stone may or may not have written...
There is a fixed patchset here:
URL:http://www.youmustbejoking.demon.co.uk/patches/vdr-xine/
Darren, should all of these patches in your vdr-xine directory be applied
to current xine development? Thanks for the
Gavin Hamill wrote:
On Sat, 26 Aug 2006 13:37:35 +0300
Lauri Tischler [EMAIL PROTECTED] wrote:
I was wondering is it possible to have Mythtv running
with NEXUS-S FF card only, using it for capture _and_ tv-out
MythTV site seems to be centered around PVR-card.
I don't believe so - that's
Package: apt
Version: 0.6.44
Severity: important
When I type apt-get source, apt fails on the following:
Reading package lists... Done
Building dependency tree... Done
E: Unable to parse package file
/var/lib/apt/lists/sentinel.dk_debian_dists_unstable_contrib_source_Sources (2)
E: Unable to
Michael Vogt wrote:
On Fri, May 12, 2006 at 12:59:42AM -0700, C.Y.M wrote:
Package: apt
Version: 0.6.44
Severity: important
Thanks for your bugreport.
When I type apt-get source, apt fails on the following:
Reading package lists... Done
Building dependency tree... Done
E: Unable
Package: nvidia-glx
Version: 1.0.8756-4
Severity: important
When attempting to build nvidia drivers from the source, I get the following
errors:
dh_testdir
dh_testroot
dh_installchangelogs
dh_installdocs -s
dh_installexamples
dh_installdebconf
dh_installinit
dh_installman
dh_link
dh_strip
BFD:
Package: debhelper
Version: 5.0.34
Severity: grave
When building packages, dh_strip is now failing. For example, the nvidia-glx
package:
dh_testdir
dh_testroot
dh_installchangelogs
dh_installdocs -s
dh_installexamples
dh_installdebconf
dh_installinit
dh_installman
dh_link
dh_strip
BFD:
I don't think this is a bug in dh_strip; it looks like you have a buggy
binutils installed. I've been using this version of debhelper to build all
kinds of packages, without any errors of this kind; and in any case, the
error messages are from strip, not from dh_strip.
There has been a
Going back to binutils_2.16.1cvs20060117-1 fixed the strip problem.
Thanks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Sorry for reporting this against the nvidia-glx package. This is a binutils
problem. Please close this against the nvidia package.
Thanks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Steve Langasek wrote:
On Sat, May 06, 2006 at 02:41:58AM -0700, C.Y.M wrote:
I don't think this is a bug in dh_strip; it looks like you have a buggy
binutils installed. I've been using this version of debhelper to build all
kinds of packages, without any errors of this kind; and in any case
Joey Hess wrote:
C.Y.M wrote:
strip: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: Bad value
BFD: debian/nvidia-glx/usr/lib/nvidia/stVEjyts: The first section in the
PT_DYNAMIC segment is not the .dynamic section
I'll reassign this to the right package (you know, the one with strip
Package: debhelper
Version: 5.0.34
Severity: grave
When building packages, dh_strip is now failing. For example, the nvidia-glx
package:
dh_testdir
dh_testroot
dh_installchangelogs
dh_installdocs -s
dh_installexamples
dh_installdebconf
dh_installinit
dh_installman
dh_link
dh_strip
BFD:
I don't think this is a bug in dh_strip; it looks like you have a buggy
binutils installed. I've been using this version of debhelper to build all
kinds of packages, without any errors of this kind; and in any case, the
error messages are from strip, not from dh_strip.
There has been a
C.Y.M wrote:
Chet Ramey wrote:
Matthias Klose wrote:
C.Y.M writes:
Reverting back to bash 3.0 fixes the problem. It seems bash 3.1 has
broken the
way the arrays are read.
Once again bitten by using a too-general function for consistency
across different expansions :-).
I
Package: libxft-dev
Version: 2.1.8.2-6
Severity: important
Please include /usr/lib/libXft.la in the installation. I use it to link into
some older applications still.
BR.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: libxrender-dev
Version: 0.9.0.2-2
Severity: important
Please include /usr/lib/libXrender.la in the installation. I use it to link into
some older applications still.
BR.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: libxau-dev
Version: 1.0.0-2
Broken manpages
mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory
mandb: warning: /usr/share/man/man3/XauGetBestAuthByAddr.3x.gz: bad symlink or
ROFF `.so' request
mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or
Package: xbase-clients
Version: 7.0.0-2
Broken manpages
mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory
mandb: warning: /usr/share/man/man1/atobm.1x.gz: bad symlink or ROFF `.so'
request
mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory
Package: libxft-dev
Version: 2.1.8.2-6
Severity: important
Please include /usr/lib/libXft.la in the installation. I use it to link into
some older applications still.
BR.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: libxrender-dev
Version: 0.9.0.2-2
Severity: important
Please include /usr/lib/libXrender.la in the installation. I use it to link into
some older applications still.
BR.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: libxau-dev
Version: 1.0.0-2
Broken manpages
mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or directory
mandb: warning: /usr/share/man/man3/XauGetBestAuthByAddr.3x.gz: bad symlink or
ROFF `.so' request
mandb: can't open /usr/share/man/man3x/Xau.3x: No such file or
Package: xbase-clients
Version: 7.0.0-2
Broken manpages
mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory
mandb: warning: /usr/share/man/man1/atobm.1x.gz: bad symlink or ROFF `.so'
request
mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory
Package: nvidia-glx-dev
Version: 1.0.8756-4
Severity: important
nvidia-glx-dev will not install and so I can not link any applications to the
new nvidia drivers.
dpkg: regarding nvidia-glx-dev_1.0.8756-4_i386.deb containing nvidia-glx-dev:
nvidia-glx-dev conflicts with libgl-dev
Randall Donald wrote:
On Fri, 2006-04-14 at 12:05 -0700, C.Y.M wrote:
dpkg: regarding nvidia-glx-dev_1.0.8756-4_i386.deb containing nvidia-glx-dev:
nvidia-glx-dev conflicts with libgl-dev
libgl1-mesa-dev provides libgl-dev and is installed.
dpkg: error processing nvidia-glx-dev_1.0.8756
Package: nvidia-glx-dev
Version: 1.0.8756-1
Severity: important
nvidia-glx-dev conflicts with xlibmesa-gl-dev and can not be installed.
dpkg: regarding nvidia-glx-dev_1.0.8756-1b_i386.deb containing nvidia-glx-dev:
nvidia-glx-dev conflicts with libgl-dev
xlibmesa-gl-dev provides libgl-dev and
Package: htdig
Version: 3.1.6-11.1
Severity: important
Htdig requires libdb2 for installation. libdb2 has been obsoleted from Sid for
i386.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: manpages-dev
Version: 2.25-1
Severity: important
Conflicts with modutils pacakage.
dpkg: error processing /var/cache/apt/archives/manpages-dev_2.25-1_all.deb
(--unpack):
trying to overwrite `/usr/share/man/man2/create_module.2.gz', which is also in
package modutils
dpkg-deb: subprocess
Package: razor
Version: 2.810-1
Severity: important
The libdigest-nilsimsa-perl package has been removed from Sid.
Preparing to replace razor 2.720-1 (using razor_2.810-1_i386.deb) ...
Unpacking replacement razor ...
dpkg: dependency problems prevent configuration of razor:
razor depends on
Package: unixodbc-dev
Version: 2.2.11-11
Dangling symlink in /usr/lib/:
libtemplate.so - libtemplate.so.1.0.0
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: freetds-dev
Version: 0.63-2
Dangling symlink in /usr/lib/:
libtdsodbc.so - libtdsodbc.so.0.0.0
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
1 - 100 of 261 matches
Mail list logo
