Bug#735424: nvidia-driver: New vesa test

2014-01-29 Thread Karsten Malcher

Am 29.01.2014 12:52, schrieb Diederik de Haas:

O.K. - but what is the difference?

As user i expect to get the correct headers for the kernel
linux-image-3.12-1-amd64 when i install 'linux-headers-3.12-1-amd64'

That is correct.
But you have the package 'linux-image-amd64' installed (and that's a good
thing), so when a new kernel enters testing, it will be installed on your
system and then you won't have the corresponding headers package on your
system.


No - i only installed the package linux-headers-3.12-1-amd64.

The package linux-image-amd64 was installed automatically!



First i have to install the original nvidia driver now.

If you mean the 'nvidia-driver' package from Debian, then yes, do that.
And report back with the requested information.


Sorry - misstyping - i mean UNinstall the origianl nvidia driver.




Do you think it is a good idea to start with a clean new copy of wheezy now
and upgrade it to jessie? I think everything is really mixed up now.

Not now. Let's try to find (and fix) your issue now, otherwise you may end up in
the same situation again.


Yes - i assume this will be the same.
But there is an system upgrade and the installation of the original nvidia 
package between?
What's about the backup of the system before the installation of the original 
nvidia driver?



But it wouldn't hurt to start *preparing* for a complete new install and
migrating your users files/settings/etc.



Of course - but for 3 users this is really much trouble.
And i must compare to have the same packages installed.
I did this one time and it takes some days work.
There should be a way to upgrade a system ...

Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#736145: nvidia-detect gives no senseful output

2014-01-27 Thread Karsten Malcher

Am 27.01.2014 20:00, schrieb Andreas Beckmann:

On 2014-01-27 17:23, Karsten Malcher wrote:

Am 25.01.2014 16:57, schrieb Andreas Beckmann:

On 2014-01-20 10:30, Karsten Malcher wrote:

When i run nvidia-detect i get this output:

Detected NVIDIA GPUs:
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108
[GeForce GT 430] [10de:0de1] (rev a1)
Your card is supported by the default drivers and version 304.
It is recommended to install the
  nvidia-driver

package.
That's wrong!
Correct should be 319.76 and this is installed:

Why do you think this is wrong? What would you expect instead?

Andreas

Please read exact - current driver is 319.76 or not?

The purpose of nvidia-detect is not to tell you something about upstream
version numbers, ...


O.K. It's not a bug - it's a feature.




nvidia-detect cries for 304.
So how to install something that does not exist? ;-)

... but about Debian package names. And 'nvidia-driver' does exist.
That's what 'default drivers' is about.


The description says:
The 'nvidia-detect' script in this package checks for an NVIDIA GPU in the system and recommends one of the non-free 
accelerated driver meta-packages


When the main function is only to recommend something, everything is perfect. 
:-)



But you are right, we could mark the '304' more prominently as 'legacy'.


Fine. :-)
Close the bug.




Andreas

PS: Note to self: check that nvidia-detect in wheezy-backports outputs
something sane


Then i should update the wiki that this package exists.
It's really not clear how get NVidia running in Debian ...

Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#735424: nvidia-driver: New vesa test

2014-01-27 Thread Karsten Malcher

O.K. Thank you for the advice.

1. I will deinstall all unneeded header packages
2. I will install the correct one and check it with dbsums
3. I will try to install the original nvidia driver and prove if it will work
4. When there is no hope to find the problem up to this point i will make
a new installation of testing on the partition.

Am 27.01.2014 20:28, schrieb Andreas Beckmann:
Is the linux-headers-3.12-1-common package correctly installed? (check with debsums) Before reinstalling, delete the 
manually created link.


Not used up to now - but i will find out.





I tried to correct this by a symbolic link:
linux-headers-3.12-1-common - linux-headers-3.12-1-common-rt

the NVIDIA driver does not work under RT kernels, so get rid of the
linux-headers-3.12-1-rt-amd64 linux-headers-3.12-1-common-rt packages


i can't remember to have this packages installed.
They are not installed under wheezy!




Then i rerun the installer and get make2.log
I have no idea what's going wrong this time?
Nothings works. :-(

you probably don't need the uvm module ...


???




But this is not going to fix your problem. There is something X-related
broken as you could see in the failing vesa test. Maybe some outdated
library, forgotten file or symlink somewhere or a non-default
configuration setting somewhere.

Yes - but how to find out?
I thought it would be easier to get a running NVida-driver first.

Changing the tires does not get your car going if the battery is dead.


Correct. I just wanted to see if this works.
But i only found much problems with headers ...




You should really try to do a clean minimal jessie install on a separate
disk, ensure X is working properly, install the same package set as you
have on the grown system, ensure X is still working, and compare the
two installations.

Hmmm - yes - but that will take really much time.
I will try to do this, it will take time to find a day with some hours ...

Unfortunately I don't see another way to find the tiny difference that
breaks your system.


You have convinced me.


BTW, in your wheezy installation, which driver and kernel version were
you using? Did you test with the nvidia driver from wheezy-backports?

I posted somewhere at the beginning of the bug. It is 304.88-1+deb7u1
You mean i should install the backport driver on wheezy first?
I can try whatever can be done that don't need a half of a day.

319.82 backport was uploaded a few hours ago. See the backports page for
instructions how to use backports.

This should be rather quick and is just to verify that there isn't
something broken w.r.t 319.82 on your card.


But then i must reinstall a copy of my running system first.
I don't want to break my working system.
I think it is more sensefull to try a clean installation of testing?


Andreas


Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#736145: nvidia-detect gives no senseful output

2014-01-27 Thread Karsten Malcher

Am 25.01.2014 16:57, schrieb Andreas Beckmann:

On 2014-01-20 10:30, Karsten Malcher wrote:

When i run nvidia-detect i get this output:

Detected NVIDIA GPUs:
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108
[GeForce GT 430] [10de:0de1] (rev a1)
Your card is supported by the default drivers and version 304.
It is recommended to install the
 nvidia-driver

package.
That's wrong!
Correct should be 319.76 and this is installed:

Why do you think this is wrong? What would you expect instead?

Andreas


Please read exact - current driver is 319.76 or not?
nvidia-detect cries for 304.
So how to install something that does not exist? ;-)

Regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#735424: nvidia-driver: New vesa test

2014-01-24 Thread Karsten Malcher

Hello,

Am 23.01.2014 13:14, schrieb Diederik de Haas:

On Thursday 23 January 2014 12:37:29 Karsten Malcher wrote:

2. Boot jessie, deinstall all Debian NVidia packages

Instead of just deinstalling, I'd suggest purging the package(s), which also
removes configuration files.
Optionally you can also do the following to make sure all config files are
indeed removed:
- check /etc/X11/xorg.conf.d/ to see if there are any config files there (which
could interfere)
- run 'updatedb.mlocate' (as root)
- run 'find -name *nvidia* -type f' (as root) to see whether there are still
nvidia files on your system you'd like to get rid of

Then reboot and install the nvidia driver

HTH,
   Diederik



I have purged all the packages.
But installation of the NVidia driver fails, because compilation does not work.
I atteched the logs.

The directory /usr/src/linux-headers-3.12-1-amd64 exists!
But only with 1,9 MB content?

I already run an package update.
I think there are some things really misconfigured and bad in jessie.

Cheers
Karsten
nvidia-installer log file '/var/log/nvidia-installer.log'
creation time: Thu Jan 23 13:50:56 2014
installer version: 331.38

PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

nvidia-installer command line:
./nvidia-installer

Using: nvidia-installer ncurses user interface
- License accepted.
- Installing NVIDIA driver version 331.38.
- There appears to already be a driver installed on your system (version: 331.38).  As part of installing this driver (version: 331.38), the existing driver will be uninstalled.  Are you sure you want to continue? ('no' will abort installation) (Answer: Yes)
- Would you like to register the kernel module sources with DKMS? This will allow DKMS to automatically build a new module, if you install a different kernel later. (Answer: Yes)
- Installing both new and classic TLS OpenGL libraries.
- Installing both new and classic TLS 32bit OpenGL libraries.
- Install NVIDIA's 32-bit compatibility libraries? (Answer: Yes)
- Parsing log file:
- done.
- Validating previous installation:
- done.
- Uninstalling NVIDIA Accelerated Graphics Driver for Linux-x86_64 (1.0-33138 (331.38)):
- DKMS module detected; removing...
- Unable to delete directories created by previous installation.
- done.
- Uninstallation of existing driver: NVIDIA Accelerated Graphics Driver for Linux-x86_64 (331.38) is complete.
- Skipping installation of the libvdpau wrapper library.
- Searching for conflicting X files:
- done.
- Searching for conflicting OpenGL files:
- done.
- Installing 'NVIDIA Accelerated Graphics Driver for Linux-x86_64' (331.38):
   executing: '/sbin/ldconfig'...
   executing: '/sbin/depmod -aq'...
- done.
- Driver file installation is complete.
- Installing DKMS kernel module:
ERROR: Failed to run `/usr/sbin/dkms build -m nvidia -v 331.38 -k 3.12-1-amd64`: 
Kernel preparation unnecessary for this kernel.  Skipping...

Building module:
cleaning build area
make KERNELRELEASE=3.12-1-amd64 module KERNEL_UNAME=3.12-1-amd64; make -C uvm module KERNEL_UNAME=3.12-1-amd64 KBUILD_EXTMOD=/var/lib/dkms/nvidia/331.38/build/uvm(bad exit status: 2)
Error! Bad return status for module build on kernel: 3.12-1-amd64 (x86_64)
Consult /var/lib/dkms/nvidia/331.38/build/make.log for more information.
- error.
ERROR: Failed to install the kernel module through DKMS. No kernel module was installed; please try installing again without DKMS, or check the DKMS logs for more information.
ERROR: Installation has failed.  Please see the file '/var/log/nvidia-installer.log' for details.  You may find suggestions on fixing installation problems in the README available on the Linux driver download page at www.nvidia.com.
DKMS make.log for nvidia-331.38 for kernel 3.12-1-amd64 (x86_64)
Do 23. Jan 13:51:09 CET 2014
NVIDIA: calling KBUILD...
make[1]: Entering directory `/usr/src/linux-headers-3.12-1-amd64'
make: Entering an unknown directory
make: *** /usr/src/linux-headers-3.12-1-common: Datei oder Verzeichnis nicht gefunden.  Schluss.
make: Leaving an unknown directory
make[1]: *** [all] Fehler 2
make[1]: Leaving directory `/usr/src/linux-headers-3.12-1-amd64'
NVIDIA: left KBUILD.
 nvidia.ko failed to build!
make: *** [nvidia.ko] Fehler 1
make: Entering directory `/var/lib/dkms/nvidia/331.38/build/uvm'
cd /var/lib/dkms/nvidia/331.38/build; make module SYSSRC=/lib/modules/3.12-1-amd64/build SYSOUT=/lib/modules/3.12-1-amd64/build KBUILD_EXTMOD=/var/lib/dkms/nvidia/331.38/build
make[1]: Entering directory `/var/lib/dkms/nvidia/331.38/build'
NVIDIA: calling KBUILD...
make[2]: Entering directory `/usr/src/linux-headers-3.12-1-amd64'
make: Entering an unknown directory
make: *** /usr/src/linux-headers-3.12-1-common: Datei oder Verzeichnis nicht gefunden.  Schluss.
make: Leaving an unknown directory
make[2]: *** [all] Fehler 2
make[2]: Leaving directory `/usr/src/linux-headers-3.12-1-amd64'
NVIDIA: left KBUILD.
 nvidia.ko failed to build!
make[1]: *** [nvidia.ko] Fehler 1
make[1

Bug#735424: nvidia-driver: New vesa test

2014-01-23 Thread Karsten Malcher

Hello Andreas,

Am 22.01.2014 21:41, schrieb Andreas Beckmann:

[Please keep the Bug Cc:ed - therefore fullquote]

On 2014-01-22 10:47, Karsten Malcher wrote:

Hello Diederik,

that's really interesting.
So it must be a configuration problem of previous installations?
Do you have made a fresh installation or an upgrade?

I have made now an additional test:
On a third partition i have a copy of my wheezy installation.
In this installation i have an self compiled kernel V 3.12.6 for some
driver tests with a newer kernel.

Up to now i booted there using the neauveau driver with this configuration:
Section Device
 Identifier  n
 Driver  nv
EndSection

shouldn't that be Driver nouveau ? (nv is an even older driver last
seen in squeeze) but that wouldn't even need an xorg.conf


Yes - this was only a quick and dirty solution to get a running X with a new 
kernel.




Now i deinstalled all Debian NVidia packages in this installation and
installed the actual NVIdia driver
NVIDIA-Linux-x86_64-331.38.run

I did have some problems with compilation of the driver, although i
installed the kernel with a debian building script.
ii  linux-image-3.12.6 3.12.6 amd64
Linux kernel binary image for version 3.12.6
ii  linux-image-3.2.0-3-amd64 3.2.23-1
amd64Linux 3.2 for 64-bit PCs

But the driver could be installed an is running fine!

So something with the configuration or the debian package of 319.82 is
not correct.
The newer driver 331.38 is running on the same installation as the
upgraded one in this bug.

This has only proved that 331.38 is running in a wheezy environment.


Yes and No - it has also proved that my configuration is able to run X with 
kernel 3.12.6


Vesa should work there as well. As I understood your problem so far it
is all xserver video drivers result in a black screen in jessie.


Yes - that's correct.

I will made the following test now:

1. Backup the current upgraded jessie partition (with the chance to recover).
2. Boot jessie, deinstall all Debian NVidia packages
3. Install NVidia driver 331.38

Then we will see if this will work.



Do you have a spare hard disk to make a minimal fresh jessie
installation (installing on a usb stick should work as well) and see if
you can get X running with vesa/nouveau (and nvidia afterwards)?
Thereafter compare /etc contents, maybe install the exactly same
packageset in the new install and look for differences.



I have no doubt that this will work.
The problem is a failing upgrade from wheezy to jessie.

Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#735424: nvidia-driver: New vesa test

2014-01-22 Thread Karsten Malcher

Hi Diederik,

Am 22.01.2014 11:15, schrieb Diederik de Haas:

Hi Karsten,

On Wednesday 22 January 2014 10:47:48 Karsten Malcher wrote:

Now i deinstalled all Debian NVidia packages in this installation and
installed the actual NVIdia driver NVIDIA-Linux-x86_64-331.38.run

I understand your eagerness to fix this asap, but I'm not going to interfere
with Andreas bug-triage efforts.


Of course i understand this.

But from my point of view i never could made an upgrade in Debian without 
problems.
I always where using Nvidia cards.
Before wheezy i never got an running X without original NVidia drivers.
In wheezy the first time the Nvidia Debian package was running for me.
It seems it was the last time. :-(

Any update of the kernel will cause the loose of X.


But I can say this:
- When trying to find a problem, only change 1 variable at a time, otherwise
you don't know which change caused a change in behaviour.


i only made an simple system upgrade from wheezy to jessie.


- Don't use NVidia's .run file if you're reporting an issue on a Debian
package, since they're not meant to be co-installed (and Debian's package
cleans thing up from a possible previous .run installation).


That's why i made this test in a different installation.
It was a simple test if kernel 3.12.6 and the NVidia driver will work together.


- Use the same system/installation on all bug-triage efforts, otherwise you're
comparing completely different systems (btw 3.12 kernel on wheezy and not from
backports?)


Somehow it must be possible to have a working PC. ;-)
In this case i hold back the upgraded installation for this bug.
There is no additional mix up.



I've been running Debian's NVidia packages for years, without any issue,
including on my freshly installed system I'm running now.


That's the main problem.
On a fresh installation you don't have this problems.
In most of the cases this will work.

But what's about of the hundreds of personal configurations for mail, 
programming, viewing and working?
You will loose them with a new installation and need to much time to get them 
back.

In my case i have a master installation with the individual settings for 3 
users!
This installation will be cloned to all working PC's.
When i want to upgrade to a newer distribution it must be an upgrade or it will 
kill me.

I think this problems are not my personal problems and touch many users.
So upgrade problems should also be in a distribution focus.

Cheers
Karsten



HTH,
   Diederik




 Original-Nachricht 
Betreff:Re: Bug#735424: nvidia-driver: New vesa test
Datum:  Wed, 22 Jan 2014 10:47:48 +0100
Von:Karsten Malcher deb...@dct.mine.nu
Antwort an: deb...@dct.mine.nu
An: Diederik de Haas didi.deb...@cknow.org
Kopie (CC): pkg-nvidia-de...@lists.alioth.debian.org



Hello Diederik,

that's really interesting.
So it must be a configuration problem of previous installations?
Do you have made a fresh installation or an upgrade?

I have made now an additional test:
On a third partition i have a copy of my wheezy installation.
In this installation i have an self compiled kernel V 3.12.6 for some driver 
tests with a newer kernel.

Up to now i booted there using the neauveau driver with this configuration:
Section Device
Identifier  n
Driver  nv
EndSection

Now i deinstalled all Debian NVidia packages in this installation and installed 
the actual NVIdia driver
NVIDIA-Linux-x86_64-331.38.run

I did have some problems with compilation of the driver, although i installed 
the kernel with a debian building script.
ii  linux-image-3.12.6 3.12.6 amd64Linux 
kernel binary image for version 3.12.6
ii  linux-image-3.2.0-3-amd64 3.2.23-1   amd64
Linux 3.2 for 64-bit PCs

But the driver could be installed an is running fine!

So something with the configuration or the debian package of 319.82 is not 
correct.
The newer driver 331.38 is running on the same installation as the upgraded one 
in this bug.

Cheers
Karsten


Andreas,

I have the same graphics card (GT 430), the same driver version and (almost)
the same kernel (Linux bagend 3.12-1-amd64 #1 SMP Debian 3.12.8-1 (2014-01-19)
x86_64 GNU/Linux) and everything is running fine here.
So if you want me to check/test things so 'notes' can be compared, just let me
know (I'm subsribed to the pkg-nvidia-devel ML).

Cheers,
   Diederik



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#735424: nvidia-driver: New vesa test

2014-01-22 Thread Karsten Malcher

Am 22.01.2014 13:16, schrieb Andreas Beckmann:
This time the log shows a clean vesa install. And if vesa is not working (even if it would be horribly slow), there 
seems to be something else going on. It's not the nvidia driver being faulty - the same happens there, but you don't 
see the flickering because its too fast. I see the same in the Xorg.log from both drivers - X is started 
successfully. But right now I'm out of clues how to debug this further - the X maintainers might help here to get vesa 
running. And if that is working, switching back to nvidia should be no problem. Andreas 


Thank you for analyzing and trying to solve the problem!

It seems to be a really sucking problem with the configuration of this 
installation.
Is there a chance for a simply and clean reinstall of all the stuff around X 
and Nvida?
Maybe this could save the personal settings and get the same situation as a new 
installation?

Otherwise i think this will cost to much time for further analyzing of this 
problem.
Then there only two options:
1. Wait and try another upgrade from wheezy to jessie in hope that it will work 
later.
2. Uninstall the nvidia debian packages and try to use the original NVidia 
installer.
   (I have no idea what the NVidia installer is making different that it works?)

Best regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#736145: nvidia-detect gives no senseful output

2014-01-20 Thread Karsten Malcher

Package: nvidia-detect
Version: 319.76-1
Severity: important

Hello,

the upgrade from wheezy to jessie failed. Please refer to bug 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735424

When i run nvidia-detect i get this output:

Detected NVIDIA GPUs:
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 
430] [10de:0de1] (rev a1)
Your card is supported by the default drivers and version 304.
It is recommended to install the
nvidia-driver

package.


That's wrong!
Correct should be 319.76 and this is installed:


ii  glx-alternative-nvidia0.4.1  amd64allows the selection of NVIDIA as 
GLX provider
rc  libgl1-nvidia-alternatives-ia32   304.88-1+deb7u1amd64simplifies replacing MESA libGL 
with GPU vendor libraries (32-bit)

ii  libgl1-nvidia-glx:amd64   319.76-1   amd64  
  NVIDIA binary OpenGL libraries
ii  libgl1-nvidia-glx:i386319.76-1   i386   
  NVIDIA binary OpenGL libraries
ii  libgl1-nvidia-glx-i386319.76-1   i386   
  NVIDIA binary OpenGL 32-bit libraries
ii  libnvidia-compiler:amd64  319.76-1   amd64  
  NVIDIA runtime compiler library
ii  libnvidia-ml1:amd64   319.76-1   amd64NVIDIA Management Library (NVML) 
runtime library

rc  libxvmcnvidia1:amd64  304.88-1+deb7u1amd64  
  NVIDIA binary XvMC library
ii  nvidia-alternative319.76-1   amd64allows the selection of NVIDIA as 
GLX provider

ii  nvidia-detect 319.76-1   amd64  
  NVIDIA GPU detection utility
ii  nvidia-driver 319.76-1   amd64  
  NVIDIA metapackage
ii  nvidia-glx319.76-1   amd64  
  transition to nvidia-driver
ii  nvidia-installer-cleanup  20131102+1 amd64cleanup after driver installation 
with the nvidia-installer
ii  nvidia-kernel-common  20131102+1 amd64NVIDIA binary kernel module 
support files
ii  nvidia-kernel-dkms319.76-1   amd64NVIDIA binary kernel module DKMS 
source

ii  nvidia-opencl-common  319.76-1   amd64  
  NVIDIA OpenCL driver
ii  nvidia-opencl-icd:amd64   319.76-1   amd64  
  NVIDIA OpenCL ICD
ii  nvidia-settings   319.72-1   amd64tool for configuring the NVIDIA 
graphics driver
ii  nvidia-support20131102+1 amd64NVIDIA binary graphics driver 
support files

ii  nvidia-vdpau-driver:amd64 319.76-1   amd64  
  NVIDIA vdpau driver
ii  nvidia-xconfig319.72-1   amd64X configuration tool for non-free 
NVIDIA drivers

ii  xserver-xorg-video-nvidia 319.76-1   amd64  
  NVIDIA binary Xorg driver


Regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#735424: nvidia-driver: needed option x for additional information

2014-01-20 Thread Karsten Malcher

Am 19.01.2014 19:00, schrieb Andreas Beckmann:

On 2014-01-15 17:54, Karsten wrote:

Here are the automatic collected informations.

So far I don't see any errors ...
X starts ... and after 30 seconds cleanly shuts down.
Please check the logfile of login manager (gdm3, kdm, xdm or whatever)


That's what i can't understand too.
After boot X does not start and i land on the basic text shell.
So i can log in as user and startx.

Without xorg.conf i only get the error no screens found.
With an xorg.conf i only get an blank black screen.
It seems that the graphic card is not initialized correctly or something else.
Shutdown is with CTRL-C by the user.



Please try the new driver releases 319.82 in unstable and 331.38 in
experimental.


How can i install this driver in jessie?


  And try a minimal config file as decribed in
/usr/share/doc/nvidia-driver/README.Debian.gz


I tried to use nvidia-xconfig with the same result of this black blank screen.
The xorg.conf is attached.

Karsten

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 319.72  (pbuilder@cake)  Sat Nov  9 14:15:48 UTC 2013


Section ServerLayout
Identifier Layout0
Screen  0  Screen0 0 0
InputDeviceKeyboard0 CoreKeyboard
InputDeviceMouse0 CorePointer
EndSection

Section Files
EndSection

Section InputDevice

# generated from default
Identifier Mouse0
Driver mouse
Option Protocol auto
Option Device /dev/psaux
Option Emulate3Buttons no
Option ZAxisMapping 4 5
EndSection

Section InputDevice

# generated from default
Identifier Keyboard0
Driver kbd
EndSection

Section Monitor
Identifier Monitor0
VendorName Unknown
ModelName  Unknown
HorizSync   28.0 - 33.0
VertRefresh 43.0 - 72.0
Option DPMS
EndSection

Section Device
Identifier Device0
Driver nvidia
VendorName NVIDIA Corporation
EndSection

Section Screen
Identifier Screen0
Device Device0
MonitorMonitor0
DefaultDepth24
SubSection Display
Depth   24
EndSubSection
EndSection



Bug#735424: nvidia-driver: Test with minimal NVIDIA xorg.conf

2014-01-20 Thread Karsten
Package: nvidia-driver
Version: 319.76-1
Followup-For: Bug #735424

Thank you for your help and your suggestions!
The first test is to boot with the suggested minimal xorg.conf for NVidia.
Result is a text console after boot!
I logged in as user and startx - result is the blank screen.

I opened a second text console and send this message with reportbug -N,
Following up with the next test (vesa).

Karsten


-- Package-specific info:
uname -a:
Linux PC10 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux

/proc/version:
Linux version 3.12-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 
(Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 22 13:33:19 PST 
2013
GCC version:  gcc version 4.8.2 (Debian 4.8.2-12) 

lspci 'VGA compatible controller [0300]':
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 
430] [10de:0de1] (rev a1) (prog-if 00 [VGA controller])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fd00 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d800 (64-bit, prefetchable) [size=128M]
Region 3: Memory at d600 (64-bit, prefetchable) [size=32M]
Region 5: I/O ports at c800 [size=128]
[virtual] Expansion ROM at fea8 [disabled] [size=512K]
Capabilities: access denied
Kernel driver in use: nvidia

dmesg:
[0.00] No AGP bridge found
[0.00] No AGP bridge found
[0.00] Console: colour VGA+ 80x25
[0.382826] vgaarb: device added: 
PCI::02:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.382828] vgaarb: loaded
[0.382829] vgaarb: bridge control possible :02:00.0
[1.067815] PCI-DMA: Disabling AGP.
[1.067899] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[1.147011] Linux agpgart interface v0.103
[5.275911] hda-intel :02:00.1: Handle VGA-switcheroo audio client
[5.516103] nvidia: module license 'NVIDIA' taints kernel.
[6.139085] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input16
[6.139285] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input15
[6.139439] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input14
[6.139582] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input13
[6.141016] vgaarb: device changed decodes: 
PCI::02:00.0,olddecodes=io+mem,decodes=none:owns=none
[6.142218] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 
22 13:33:19 PST 2013

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jan 14 11:03 /etc/alternatives/glx - 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   41 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Jan 14 11:03 
/etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Jan 14 11:03 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf - 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Jan 14 11:03 
/etc/alternatives/glx--nvidia-bug-report.sh - 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   29 Jan 14 11:03 
/etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   23 Jan 14 11:03 /etc/alternatives/nvidia - 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu

Bug#735424: nvidia-driver: Test with vesa xorg.conf

2014-01-20 Thread Karsten
Package: nvidia-driver
Version: 319.76-1
Followup-For: Bug #735424

This time i booted with the suggested xorg.conf with vesa.
Result is the same.
I land on the text console
After login and startx i got no screens found
Trying now to install driver from unstable ...

Karsten

-- Package-specific info:
uname -a:
Linux PC10 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux

/proc/version:
Linux version 3.12-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 
(Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 22 13:33:19 PST 
2013
GCC version:  gcc version 4.8.2 (Debian 4.8.2-12) 

lspci 'VGA compatible controller [0300]':
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 
430] [10de:0de1] (rev a1) (prog-if 00 [VGA controller])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fd00 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d800 (64-bit, prefetchable) [size=128M]
Region 3: Memory at d600 (64-bit, prefetchable) [size=32M]
Region 5: I/O ports at c800 [size=128]
Expansion ROM at fea8 [disabled] [size=512K]
Capabilities: access denied
Kernel driver in use: nvidia

dmesg:
[0.00] No AGP bridge found
[0.00] No AGP bridge found
[0.00] Console: colour VGA+ 80x25
[0.386397] vgaarb: device added: 
PCI::02:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.386399] vgaarb: loaded
[0.386400] vgaarb: bridge control possible :02:00.0
[1.070997] PCI-DMA: Disabling AGP.
[1.071086] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[1.150122] Linux agpgart interface v0.103
[7.159490] nvidia: module license 'NVIDIA' taints kernel.
[7.175092] vgaarb: device changed decodes: 
PCI::02:00.0,olddecodes=io+mem,decodes=none:owns=none
[7.175347] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 
22 13:33:19 PST 2013
[7.267428] hda-intel :02:00.1: Handle VGA-switcheroo audio client
[8.074148] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input16
[8.074343] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input15
[8.074488] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input14
[8.074630] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input13

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jan 14 11:03 /etc/alternatives/glx - 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   41 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Jan 14 11:03 
/etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Jan 14 11:03 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf - 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Jan 14 11:03 
/etc/alternatives/glx--nvidia-bug-report.sh - 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   29 Jan 14 11:03 
/etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   23 Jan 14 11:03 /etc/alternatives/nvidia - 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives

Bug#735424: nvidia-driver: Test of unstable driver

2014-01-20 Thread Karsten
Package: nvidia-driver
Version: 319.82-1
Followup-For: Bug #735424

Now i installed the driver of the unstable package.
I put the minimum xorg.conf for NVidia into /etc/X11 and tried startx as user.
It says no screens found

Now i rerun the xorg configuration tool and try to reboot ...

Karsten

-- Package-specific info:
uname -a:
Linux PC10 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux

/proc/version:
Linux version 3.12-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 
(Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 22 13:33:19 PST 
2013
GCC version:  gcc version 4.8.2 (Debian 4.8.2-12) 

lspci 'VGA compatible controller [0300]':
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 
430] [10de:0de1] (rev a1) (prog-if 00 [VGA controller])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fd00 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d800 (64-bit, prefetchable) [size=128M]
Region 3: Memory at d600 (64-bit, prefetchable) [size=32M]
Region 5: I/O ports at c800 [size=128]
Expansion ROM at fea8 [disabled] [size=512K]
Capabilities: access denied
Kernel driver in use: nvidia

dmesg:
[0.00] No AGP bridge found
[0.00] No AGP bridge found
[0.00] Console: colour VGA+ 80x25
[0.386397] vgaarb: device added: 
PCI::02:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.386399] vgaarb: loaded
[0.386400] vgaarb: bridge control possible :02:00.0
[1.070997] PCI-DMA: Disabling AGP.
[1.071086] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[1.150122] Linux agpgart interface v0.103
[7.159490] nvidia: module license 'NVIDIA' taints kernel.
[7.175092] vgaarb: device changed decodes: 
PCI::02:00.0,olddecodes=io+mem,decodes=none:owns=none
[7.175347] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 
22 13:33:19 PST 2013
[7.267428] hda-intel :02:00.1: Handle VGA-switcheroo audio client
[8.074148] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input16
[8.074343] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input15
[8.074488] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input14
[8.074630] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input13
[  455.350352] NVRM: API mismatch: the client has the version 319.82, but
[  455.350352] NVRM: this kernel module has the version 319.76.  Please
[  455.350352] NVRM: make sure that this kernel module and all NVIDIA driver
[  455.350352] NVRM: components have the same version.

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jan 20 13:50 /etc/alternatives/glx - 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   41 Jan 20 13:50 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Jan 20 13:50 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 20 13:50 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 20 13:50 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 20 13:50 
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   51 Jan 20 13:50 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Jan 20 13:50 
/etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Jan 20 13:50 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf - 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Jan 20 13:50 
/etc/alternatives/glx--nvidia-bug-report.sh - 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   29 Jan 20 13:50 
/etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   23 Jan 20 13:50 /etc/alternatives/nvidia - 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   49 Jan 20 13:50 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 20 13:50 
/etc/alternatives/nvidia

Bug#735424: nvidia-driver: Test of unstable driver

2014-01-20 Thread Karsten Malcher

Hello,

i am sorry, at least nothing has worked.
With the driver from unstable i get no running X.

All the configurations of xorg.conf i testes result in no screens found.
I attach the last configuration.
The first one was the minimal configuration.file:///sda/etc/X11/xorg.conf

What is to do now?

Regards
Karsten
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 319.72  (pbuilder@cake)  Sat Nov  9 14:15:48 UTC 2013


Section ServerLayout
Identifier Layout0
Screen  0  Screen0 0 0
InputDeviceKeyboard0 CoreKeyboard
InputDeviceMouse0 CorePointer
EndSection

Section Files
EndSection

Section InputDevice

# generated from default
Identifier Mouse0
Driver mouse
Option Protocol auto
Option Device /dev/psaux
Option Emulate3Buttons no
Option ZAxisMapping 4 5
EndSection

Section InputDevice

# generated from default
Identifier Keyboard0
Driver kbd
EndSection

Section Monitor
Identifier Monitor0
VendorName Unknown
ModelName  Unknown
HorizSync   28.0 - 33.0
VertRefresh 43.0 - 72.0
Option DPMS
EndSection

Section Device
Identifier Device0
Driver nvidia
VendorName NVIDIA Corporation
EndSection

Section Screen
Identifier Screen0
Device Device0
MonitorMonitor0
DefaultDepth24
SubSection Display
Depth   24
EndSubSection
EndSection



Bug#686754: Is there any hope that this bug will be fixed?

2014-01-15 Thread Karsten Malcher

Am 14.01.2014 19:00, schrieb Colin Watson:
GRUB doesn't generate those kernel parameters itself; it relies on os-prober to fetch them from the boot loader 
configuration files on those other systems. It's quite possible that the problem is simply that the boot loader 
configuration inside the filesystem on /dev/sda3 (or its associated /boot filesystem) is wrong. Could you find the 
relevant configuration file and attach it? 


Hello Colin,

now i understand more.
I found this description of os-prober here:
http://joeyh.name/code/os-prober/

Calling os-prober only give this information:
# os-prober
/dev/sda2:Debian GNU/Linux (7.2):Debian:linux
/dev/sda3:Debian GNU/Linux (jessie/sid):Debian1:linux


It seems not to merge the information with the UUID of the partitions.
I found an other interesting effect, which explains that this bug has not been 
found.
Now an grub-update produces the correct grub.cfg.


menuentry Debian GNU/Linux, mit Linux 3.12-1-amd64 (on /dev/sda3) --class 
gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(/dev/sda,msdos3)'
search --no-floppy --fs-uuid --set=root 
6bfc15a0-2e9d-4020-9346-9fd52d2696f5
linux /boot/vmlinuz-3.12-1-amd64 
root=UUID=6bfc15a0-2e9d-4020-9346-9fd52d2696f5 ro quiet
initrd /boot/initrd.img-3.12-1-amd64
}
menuentry Debian GNU/Linux, mit Linux 3.12-1-amd64 (Wiederherstellungsmodus) (on /dev/sda3) --class gnu-linux --class 
gnu --class os {

insmod part_msdos
insmod ext2
set root='(/dev/sda,msdos3)'
search --no-floppy --fs-uuid --set=root 
6bfc15a0-2e9d-4020-9346-9fd52d2696f5
linux /boot/vmlinuz-3.12-1-amd64 
root=UUID=6bfc15a0-2e9d-4020-9346-9fd52d2696f5 ro single
initrd /boot/initrd.img-3.12-1-amd64
}

What i did in the history:
1. I unpacked an backup of /dev/sdb1 (Grub partition with Debian wheezy) to 
/dev/sda3
2. I altered the fstab of the copy and run update-grub (After this i got this 
wrong grub.cfg)
3. I boot from /dev/sda3 and made an system-upgrade from wheezy to jessie
4. After the upgrade i run update-grub again from /dev/sdb1 to actualize the new kernel on /dev/sda3 (Now grub.cfg is 
correct)


Is it possible that the (wrong) information is extraced from initrd.img ?

Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#735424: Different drivers for different graphic cards?

2014-01-15 Thread Karsten Malcher

When i search for my graphic card GT 430 at Nvidia, this driver is suggested 
for download:
Version: 331.38
Date:2014.1.13

Again this is a different version!

In Debian there is only one driver package.
How it is able to suffer all the different graphic cards?

This driver is for many different graphic cards, including my card:

*GeForce 700 Series:*

GeForce GTX TITAN, GeForce GTX 780, GeForce GTX 770, GeForce GTX 760, GeForce 
GTX 760 Ti (OEM)

*GeForce 700M Series (Notebooks):*

GeForce GTX 780M, GeForce GTX 770M, GeForce GTX 765M, GeForce GTX 760M, GeForce GT 755M, GeForce GT 750M, GeForce GT 
745M, GeForce GT 740M, GeForce GT 735M, GeForce GT 730M, GeForce GT 720M, GeForce 710M


*GeForce 600 Series:*

GeForce GTX 690, GeForce GTX 680, GeForce GTX 670, GeForce GTX 660 Ti, GeForce GTX 660, GeForce GTX 650 Ti BOOST, 
GeForce GTX 650 Ti, GeForce GTX 650, GeForce GT 645, GeForce GT 640, GeForce GT 630, GeForce GT 620, GeForce GT 610, 
GeForce 605


*GeForce 600M Series (Notebooks):*

GeForce GTX 680MX, GeForce GTX 680M, GeForce GTX 675MX, GeForce GTX 675M, GeForce GTX 670MX, GeForce GTX 670M, GeForce 
GTX 660M, GeForce GT 650M, GeForce GT 645M, GeForce GT 640M, GeForce GT 640M LE, GeForce GT 635M, GeForce GT 630M, 
GeForce GT 625M, GeForce GT 620M, GeForce 610M


*GeForce 500 Series:*

GeForce GTX 590, GeForce GTX 580, GeForce GTX 570, GeForce GTX 560 Ti, GeForce GTX 560 SE, GeForce GTX 560, GeForce GTX 
555, GeForce GTX 550 Ti, GeForce GT 545, GeForce GT 530, GeForce GT 520, GeForce 510


*GeForce 500M Series (Notebooks):*

GeForce GTX 580M, GeForce GTX 570M, GeForce GTX 560M, GeForce GT 555M, GeForce GT 550M, GeForce GT 540M, GeForce GT 
525M, GeForce GT 520M, GeForce GT 520MX


*GeForce 400 Series:*

GeForce GTX 480, GeForce GTX 470, GeForce GTX 465, GeForce GTX 460 SE v2, GeForce GTX 460 SE, GeForce GTX 460, GeForce 
GTS 450, GeForce GT 440, GeForce GT 430, GeForce GT 420


*GeForce 400M Series (Notebooks):*

GeForce GTX 485M, GeForce GTX 480M, GeForce GTX 470M, GeForce GTX 460M, GeForce 
GT 445M

*GeForce 300 Series:*

GeForce GT 340, GeForce GT 330, GeForce GT 320, GeForce 315, GeForce 310

*GeForce 300M Series (Notebooks):*

GeForce GTS 360M, GeForce GTS 350M, GeForce GT 335M, GeForce GT 330M, GeForce GT 325M, GeForce GT 320M, GeForce 320M, 
GeForce 315M, GeForce 310M, GeForce 305M


*GeForce 200 Series:*

GeForce GTX 295, GeForce GTX 285, GeForce GTX 280, GeForce GTX 275, GeForce GTX 260, GeForce GTS 250, GeForce GTS 240, 
GeForce GT 230, GeForce GT 240


*GeForce 200M Series (Notebooks):*

GeForce GTX 285M, GeForce GTX 280M, GeForce GTX 260M, GeForce GTS 260M

*GeForce 100 Series:*

GeForce GT 140, GeForce GT 130, GeForce GT 120, GeForce G100

*GeForce 100M Series (Notebooks):*

GeForce GTS 160M, GeForce GT 130M, GeForce GT 120M, GeForce G 110M, GeForce G 
105M, GeForce G 103M, GeForce G 102M

*GeForce 9 Series:*

GeForce 9800 GX2, GeForce 9800 GTX/GTX+, GeForce 9800 GT, GeForce 9600 GT, GeForce 9600 GSO, GeForce 9600 GSO 512, 
GeForce 9600 GS, GeForce 9500 GT, GeForce 9500 GS, GeForce 9400 GT, GeForce 9400, GeForce 9300 GS, GeForce 9300 GE, 
GeForce 9300 SE, GeForce 9300, GeForce 9200, GeForce 9100


*GeForce 9M Series (Notebooks):*

GeForce 9800M GTX, GeForce 9800M GTS, GeForce 9800M GT, GeForce 9800M GS, GeForce 9700M GTS, GeForce 9700M GT, GeForce 
9650M GT, GeForce 9650M GS, GeForce 9600M GT, GeForce 9600M GS, GeForce 9500M GS, GeForce 9500M G, GeForce 9400M G, 
GeForce 9400M, GeForce 9300M GS, GeForce 9300M G, GeForce 9200M GS, GeForce 9100M G


*GeForce 8 Series:*

GeForce 8800 Ultra, GeForce 8800 GTX, GeForce 8800 GTS, GeForce 8800 GT, GeForce 8800 GS, GeForce 8600 GTS, GeForce 8600 
GT, GeForce 8600 GS, GeForce 8500 GT, GeForce 8400 GS


*GeForce 8M Series (Notebooks):*

GeForce 8800M GTX, GeForce 8800M GTS, GeForce 8700M GT, GeForce 8600M GT, GeForce 8600M GS, GeForce 8400M GT, GeForce 
8400M GS, GeForce 8400M G, GeForce 8200M G, GeForce 8200M


*Quadro Series:*

Quadro K6000, Quadro K5000, Quadro K4000, Quadro K2000, Quadro K2000D, Quadro K600, Quadro 6000, Quadro 5000, Quadro 
4000, Quadro 2000, Quadro 2000D, Quadro 600, Quadro 410, Quadro 400


*Quadro Series (Notebooks):*

Quadro K5000M, Quadro K4000M, Quadro K3000M, Quadro K2000M, Quadro K1000M, Quadro K500M, Quadro 5010M, Quadro 5000M, 
Quadro 4000M, Quadro 3000M, Quadro 2000M, Quadro 1000M


*Quadro FX Series:*

Quadro FX 3400/4400, Quadro FX 3500, Quadro FX 3700, Quadro FX 3800, Quadro FX 4000, Quadro FX 4500, Quadro FX 4500 X2, 
Quadro FX 4600, Quadro FX 4700 X2, Quadro FX 4800, Quadro FX 5500, Quadro FX 5600, Quadro FX 5800


*Quadro FX Series (Notebooks):*

Quadro FX 3800M, Quadro FX 3700M, Quadro FX 3600M, Quadro FX 2800M, Quadro FX 2700M, Quadro FX 1800M, Quadro FX 1700M, 
Quadro FX 1600M, Quadro FX 880M, Quadro FX 770M, Quadro FX 570M, Quadro FX 380M, Quadro FX 370M, Quadro FX 360M


*Quadro Blade/Embedded Series :*

Quadro FX 560M, Quadro FX 770M, Quadro FX 880M, Quadro FX 1600M, Quadro FX 
2800M, Quadro FX 3600M


Bug#686754: Is there any hope that this bug will be fixed?

2014-01-15 Thread Karsten Malcher

Am 15.01.2014 11:48, schrieb Lukas Schwaighofer:

Hi Karsten,

To my knowledge linux-boot-prober does the following:
* Mount the given partition read-only to a temporary directory
* Read the /etc/fstab of this partition to check if /boot is on a
   separate partition. If so, it is also mounted.
* Read and parse the boot loader configuration from the temporary
   directory. For grub2 that is boot/grub/grub.cfg. The parameters to
   the linux kernel (the root=… directive that was wrong in your case)
   should be directly taken from this file.
* Unmount everything again

So your report from your message #15 makes sense, if
the /boot/grub/grub.cfg file on sda3 (I'm assuming you do not have a
separate boot partition) previously contained the wrong parameters for
the Linux kernel
(root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro single).

Regards
Lukas


Hi Lukas,

then we have found the explanation for this problem - thank you!

The grub.cfg on the copy of the installation will be correct only after boot 
and update of this installation.
And i must run update-grub first on the standard installation to get the 
partition with the copy booted.

It's impossible to avoid this error under this circumstances!

So this bug can be closed.

Regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#735424: Only blank screen after system-upgrade from wheezy to jessie

2014-01-15 Thread Karsten Malcher

Hello Andreas,

Am 15.01.2014 12:27, schrieb Andreas Beckmann:

On 2014-01-15 11:01, Karsten Malcher wrote:

Package: nvidia-driver
Version: 319.76-1
Severity: important

Hello,

again i tried to upgrade from a perfect running installation of Debian
wheezy to jessie.

That should be supported :-)


That was my hope also - but i was really disappointed to land on the shell.




This installation has been upgraded more than one time and in the
history there might be the usage of original nvidia packages.

I have put a lot of effort into cleaning up the mess created by having
used the nvidia *.run installer in the past, but I may have missed some
corner cases.


I believe that and thank you for your work!

There are really to many types of NVidia-cards out there.
Is there a way to easy find out which package must be installed for an NVidia 
card?

Here i can't find my card:
http://packages.debian.org/jessie/nvidia-legacy-173xx-driver


Here i can't find any hint what to do on jessie:
https://wiki.debian.org/NvidiaGraphicsDrivers
I would update this Wiki-page with the correct informations.


Right now I don't see an obvious problem.
Please run

   reportbug -N 735424


I will do this.
But after this i would try to install the correct NVida-package for a GT 400 if 
possible.

Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#735424: nvidia-driver: needed option x for additional information

2014-01-15 Thread Karsten
Package: nvidia-driver
Version: 319.76-1
Followup-For: Bug #735424

Here are the automatic collected informations.

-- Package-specific info:
uname -a:
Linux PC10 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux

/proc/version:
Linux version 3.12-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 
(Debian 4.8.2-10) ) #1 SMP Debian 3.12.6-2 (2013-12-29)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 22 13:33:19 PST 
2013
GCC version:  gcc version 4.8.2 (Debian 4.8.2-12) 

lspci 'VGA compatible controller [0300]':
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 
430] [10de:0de1] (rev a1) (prog-if 00 [VGA controller])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fd00 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d800 (64-bit, prefetchable) [size=128M]
Region 3: Memory at d600 (64-bit, prefetchable) [size=32M]
Region 5: I/O ports at c800 [size=128]
Expansion ROM at fea8 [disabled] [size=512K]
Capabilities: access denied
Kernel driver in use: nvidia

dmesg:
[0.00] No AGP bridge found
[0.00] No AGP bridge found
[0.00] Console: colour VGA+ 80x25
[0.382826] vgaarb: device added: 
PCI::02:00.0,decodes=io+mem,owns=io+mem,locks=none
[0.382828] vgaarb: loaded
[0.382828] vgaarb: bridge control possible :02:00.0
[1.067456] PCI-DMA: Disabling AGP.
[1.067547] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
[1.146534] Linux agpgart interface v0.103
[5.848494] hda-intel :02:00.1: Handle VGA-switcheroo audio client
[5.899764] nvidia: module license 'NVIDIA' taints kernel.
[6.730927] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input16
[6.731135] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input15
[6.731285] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input14
[6.731430] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:02.0/:02:00.1/sound/card1/input13
[6.732873] vgaarb: device changed decodes: 
PCI::02:00.0,olddecodes=io+mem,decodes=none:owns=none
[6.734026] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  319.76  Fri Nov 
22 13:33:19 PST 2013

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jan 14 11:03 /etc/alternatives/glx - 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   41 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 14 11:03 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives/glx--libnvidia-cfg.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root root   25 Jan 14 11:03 
/etc/alternatives/glx--linux-libglx.so - /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Jan 14 11:03 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf - 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Jan 14 11:03 
/etc/alternatives/glx--nvidia-bug-report.sh - 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   29 Jan 14 11:03 
/etc/alternatives/glx--nvidia_drv.so - /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   23 Jan 14 11:03 /etc/alternatives/nvidia - 
/usr/lib/nvidia/current
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   49 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-i386-linux-gnu - 
/usr/lib/i386-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   51 Jan 14 11:03 
/etc/alternatives/nvidia--libGL.so.1-x86_64-linux-gnu - 
/usr/lib/x86_64-linux-gnu/nvidia/current/libGL.so.1
lrwxrwxrwx 1 root root   33 Jan 14 11:03 

Bug#686754: Is there any hope that this bug will be fixed?

2014-01-14 Thread Karsten Malcher

Again and again i have to correct the grub.cfg manually.
And you can see this bug in all depending distributions of Debian.

Example today:

# blkid
/dev/sda1: LABEL=P1EXT4-8G UUID=c4aa8129-f5a0-4599-b487-3f63ff736c1b 
TYPE=ext4
/dev/sda2: UUID=5166cbb1-8234-4127-bb0b-bbfda1658b68 TYPE=ext4 
LABEL=P2EXT4-30G
/dev/sda5: UUID=448a6eb5-2173-43e3-b35a-62e9e81a2316 TYPE=swap
/dev/sda6: LABEL=P3EXT20G UUID=d37744be-c228-4add-9cf3-ce42aff94a7f SEC_TYPE=ext2 
TYPE=ext3
/dev/sda7: LABEL=P7-EXT4-900G UUID=f4d36b10-bae9-4b22-a19b-0f34916337b3 
TYPE=ext4
/dev/sda3: LABEL=P3EXT4-30G UUID=6bfc15a0-2e9d-4020-9346-9fd52d2696f5 
TYPE=ext4
/dev/sdb1: LABEL=SSD UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 TYPE=ext4

grub.cfg

menuentry Debian GNU/Linux, mit Linux 3.2.0-3-amd64 (on /dev/sda3) --class 
gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(/dev/sda,msdos3)'
search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5
linux /boot/vmlinuz-3.2.0-3-amd64 
root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro quiet
initrd /boot/initrd.img-3.2.0-3-amd64
}
menuentry Debian GNU/Linux, mit Linux 3.2.0-3-amd64 (Wiederherstellungsmodus) (on /dev/sda3) --class gnu-linux --class 
gnu --class os {

insmod part_msdos
insmod ext2
set root='(/dev/sda,msdos3)'
search --no-floppy --fs-uuid --set=root 6bfc15a0-2e9d-4020-9346-9fd52d2696f5
linux /boot/vmlinuz-3.2.0-3-amd64 
root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro single
initrd /boot/initrd.img-3.2.0-3-amd64


But the first 2 partitions are right now. ;-)
It would be fine if i can boot from all partitions ...

Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Driver for PL-2303 HX not working

2014-01-13 Thread Karsten Malcher

Hello together,

i will close this bug at Debian now.

After the last update this error seems to disappear in Debian stable.
http://ftp.debian.org/debian/dists/wheezy/ChangeLog
USB: pl2303: fix device initialisation at open

The source for this patch can be found here:
http://www.spinics.net/lists/stable/msg30311.html
It's possible that this will not fix the bug under all circumstances depending 
on the application.

Summary:
==

I did need some time to realize that this bug will occur only with PL2303HX 
chips that are China clones.
In fact this type of chips run out of production at Profilic.
http://www.prolific.com.tw/US/ShowProduct.aspx?pcid=41showlevel=0017-0037-0041
Only the PL2303HXD can be buyed as original, so any new PL2303HX is a China 
clone.

I have been contacted by Frank Schäfer and so we tested some of his driver 
improvements in combination with newer kernels.
Up to now this could not be backported to kernel 3.2.x, but i could test a kernel 3.12.6 on Debian wheezy and the 
PL2303HX is running fine.


There are really much products with this clone chips out there, so some further improvements of the driver would be 
really helpful.
I will make further tests together with Frank and hope that this improvements will find a place into the next kernel 
versions starting with Debian jessie and 3.12.6


Best regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#735092: flash-kernel: add Raspberry Pi support

2014-01-12 Thread Karsten Merker
Package: flash-kernel
Version: 3.11
Severity: wishlist
Tags: patch

The attached patch adds Raspberry Pi support to flash-kernel.
It is based on current flash-kernel git (as of
7f52719ab0a607b89555baffd1cc8c14207c0f8f).

It is available for merging in the rpi-support-rebased branch at
http://anonscm.debian.org/gitweb/?p=users/merker/flash-kernel.git;a=shortlog;h=refs/heads/rpi-support-rebased

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
From ff2103a10fc27f77c2763d9dd4b043254b6e489d Mon Sep 17 00:00:00 2001
From: K. Merker mer...@debian.org
Date: Wed, 1 Jan 2014 13:17:13 +0100
Subject: [PATCH] Initial Raspberry Pi support

Add a method rpiconfigtxt and a new machine database entry for
the Raspberry Pi.  The method rpiconfigtxt enables flash-kernel
to update the kernel file name to be booted by the Raspberry Pi
firmware.

As the Raspberry Pi firmware can only boot from a FAT partition,
using symlinks to point to the kernel to be booted is not
possible.  Therefore the kernel filename entry in the firmware
config has to be changed after installation of a new kernel
package.
---
 README|   10 +-
 db/all.db |5 +
 functions |   19 +++
 test_db   |2 +-
 4 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 51aa15f..c7cde61 100644
--- a/README
+++ b/README
@@ -49,6 +49,7 @@ The following systems are supported:
  - QNAP TS-409
  - QNAP TS-410 and TS-410U Turbo NAS
  - QNAP TS-419P and TS-419U Turbo NAS
+ - Raspberry Pi
  - Seagate FreeAgent DockStar
  - SheevaPlug
  - SheevaPlug eSATA
@@ -153,12 +154,19 @@ The supported fields are:
 
 * Method: (optional) indicates how to support this particular machine;
   the default is generic; other available methods are: android, multi,
-  redboot, slug, symlink
+  redboot, slug, symlink, rpiconfigtxt
 
 * Boot-Device: (optional) block device to mount before installing
   kernel,  initrd and U-Boot script; Boot-Kernel-Path, Boot-Initrd-Path and
   Boot-Script-Path are then taken relative to this boot device
 
+* Rpi-ConfigTxt-Path: (optional) Raspberry Pi firmware configuration pathname.
+  The Raspberry Pi firmware configuration is stored in a text file on the
+  first (FAT formatted) partition of the SD card in the system and 
+  contains settings like kernel file name, video mode, memory split 
+  between CPU and GPU, overclocking parameters, etc. Rpi-ConfigTxt-Path
+  contains the full path to this file (default value: /boot/config.txt).
+
 
 Configuration
 - - - - - - -
diff --git a/db/all.db b/db/all.db
index c28432a..c0fdf27 100644
--- a/db/all.db
+++ b/db/all.db
@@ -382,3 +382,8 @@ Method: android
 Android-Boot-Device: /dev/mmcblk0
 Required-Packages: abootimg
 Bootloader-Sets-Root: no
+
+Machine: BCM2708
+Method: rpiconfigtxt
+Rpi-ConfigTxt-Path: /boot/config.txt
+Bootloader-Sets-Root: yes
diff --git a/functions b/functions
index 1233981..26a16ed 100644
--- a/functions
+++ b/functions
@@ -440,6 +440,7 @@ boot_script_path=$(get_machine_field $machine Boot-Script-Path) || :
 boot_dtb_path=$(get_machine_field $machine Boot-DTB-Path) || :
 boot_multi_path=$(get_machine_field $machine Boot-Multi-Path) || :
 android_boot_device=$(get_machine_field $machine Android-Boot-Device) || :
+rpi_configtxt_path=$(get_machine_field $machine Rpi-ConfigTxt-Path) || :
 
 if [ -n $dtb_append_from ]; then
 if dtb_append_required; then
@@ -711,6 +712,24 @@ case $method in
 		}  $imtd || error failed.
 		echo done. 2
 	;;
+	rpiconfigtxt)
+		rpi_configtxt_path=${rpi_configtxt_path:-/boot/config.txt}
+		rpi_configtxt_tempfile=$(tempfile)
+
+		if [ ! -e ${rpi_configtxt_path} ]; then
+			echo ${rpi_configtxt_path} not found. Creating it.
+			touch ${rpi_configtxt_path}
+		fi
+
+		grep -E -v ^#fk-old-  ${rpi_configtxt_path} | \
+		sed -e 's/^kernel=/#fk-old-kernel=/' \
+		-e 's/^initramfs/#fk-old-initramfs/' \
+		-e 's/^ramfsfile/#fk-old-ramfsfile/' \
+		-e 's/^ramfsaddr/#fk-old-ramfsaddr/'  ${rpi_configtxt_tempfile}
+
+		echo -n kernel=$(basename ${kfile})\ninitramfs $(basename ${ifile})\n  ${rpi_configtxt_tempfile}
+		mv ${rpi_configtxt_tempfile} ${rpi_configtxt_path}
+	;;
 esac
 }
 
diff --git a/test_db b/test_db
index aec83f1..217fe64 100755
--- a/test_db
+++ b/test_db
@@ -22,7 +22,7 @@
 MACHINE_DB=$(cat ${FK_CHECKOUT:-$FK_DIR}/db/*.db)
 
 test_no_unknown_fields() {
-local expected='Android-Boot-Device Boot-Device Boot-DTB-Path Boot-Initrd-Path Boot-Kernel-Path Boot-Multi-Path Boot-Script-Path Bootloader-Sets-Root DTB-Append DTB-Append-From DTB-Id Kernel-Flavors Machine Machine-Id Method Mtd-Initrd Mtd-Kernel Optional-Packages Required-Packages U-Boot-Initrd-Address U-Boot-Kernel-Address U-Boot-Kernel-Entry-Point U-Boot-Multi-Address U-Boot-Script-Address U-Boot-Script-Name'
+local expected='Android-Boot-Device Boot-Device Boot-DTB

Bug#735093: flash-kernel: does not correctly handle removal of the highest-versioned installed kernel package

2014-01-12 Thread Karsten Merker
Package: flash-kernel
Version: 3.11
Severity: normal
Tags: patch

Flash-Kernel 3.11 does not properly handle a removal of the
highest-versioned kernel package.  The same applies to current
git as of 2014-01-12 which will probably be released as 3.12.

When called from the kernel postinst in this case, it just aborts
instead of flashing the remaining then-highest-versioned kernel,
which in specific cases could lead to an unbootable system.

Attached is a patch against current mainline flash-kernel git
(as of 7f52719ab0a607b89555baffd1cc8c14207c0f8f).

It is available for merging in the rpi-support-rebased branch at
http://anonscm.debian.org/gitweb/?p=users/merker/flash-kernel.git;a=shortlog;h=refs/heads/rpi-support-rebased

Regards,
Karsten

-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
From 989312441af9bdec76ba571eb3c6ae3d65f93d4e Mon Sep 17 00:00:00 2001
From: K. Merker mer...@debian.org
Date: Thu, 2 Jan 2014 14:34:32 +0100
Subject: [PATCH] Add extended kernel package removal handling

Until now, flash-kernel has not properly handled a removal of the
highest-versioned kernel package.  When called from the kernel
postinst in this case, it just aborted instead of flashing the
remaining then-highest-versioned kernel, which could lead to an
unbootable system.

This patch adds extended removal handling which takes care
of the issue.
---
 debian/copyright|1 +
 flash-kernel.8  |   18 ++---
 functions   |   63 +++
 kernel-hook/zz-flash-kernel |6 +++--
 4 files changed, 71 insertions(+), 17 deletions(-)

diff --git a/debian/copyright b/debian/copyright
index af21da0..e9fb23c 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -6,6 +6,7 @@ Copyright:
 Copyright (C) 2006  Joey Hess  jo...@debian.org
 Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011  Martin Michlmayr t...@cyrius.com
 Copyright (C) 2011  Loïc Minier l...@dooz.org
+Copyright (C) 2014  Karsten Merker mer...@debian.org
 
 This program is free software; you can redistribute it and/or
 modify it under the terms of the GNU General Public License
diff --git a/flash-kernel.8 b/flash-kernel.8
index 7b5bad5..8165372 100644
--- a/flash-kernel.8
+++ b/flash-kernel.8
@@ -3,7 +3,7 @@
 .SH NAME
 flash-kernel \- put kernel and initramfs in boot location
 .SH SYNOPSIS
-.B flash-kernel [--supported] [kvers]
+.B flash-kernel [--machine machine-type] [--context calling-context] [--supported] [kvers]
 .SH DESCRIPTION
 flash-kernel is a script which will put the kernel and initramfs in
 the boot location of embedded devices that don't load the kernel and
@@ -11,7 +11,7 @@ initramfs directly from /boot.  flash-kernel supports devices that
 boot from flash memory (hence the name) as well as some devices that
 require a special boot image on the disk.
 .P
-Optionally, it can be passed a version of the kernel to flash; only
+Optionally, it can be passed a version of the kernel to process; only
 the highest version will be flashed and other versions will be
 ignored.  Kernel and initrd are read from /boot.
 .P
@@ -20,7 +20,17 @@ the subarchitectures of the machine and the image to be flashed
 match. Valid filenames for images to flash are suffixed with the
 subarchitecture.
 .P
-If the \-\-supported option is used, flash\-kernel will test to see if
+If the \-\-supported option is used, flash\-kernel will test whether
 the hardware is supported, and return a true or false value.
+.P
+The \-\-machine option allows to manually override the auto-detected
+machine type string.
+.P
+The \-\-context option is used internally by the kernel
+postinst/postrm scripts which call flash-kernel upon kernel package
+installations and removals.  It provides flash-kernel with the
+information that it is running in the kernel packages
+postinst/postrm context. Valid values are postinst.d* and
+postrm.d*.
 .SH AUTHOR
-Martin Michlmayr t...@cyrius.com
+Martin Michlmayr t...@cyrius.com, Karsten Merker mer...@debian.org
\ No newline at end of file
diff --git a/functions b/functions
index 26a16ed..4b1745e 100644
--- a/functions
+++ b/functions
@@ -351,28 +351,69 @@ android_flash() {
 }
 
 main() {
-if [ x$1 = x--machine ]; then
-	machine=$2
-	shift 2
-else
+
+while [ $# -gt 0 ]
+do
+if [ x$1 = x--machine ]; then
+machine=$2
+shift 1
+elif [ x$1 = x--context ]; then
+context=$2
+shift 1
+elif [ x$1 = x--supported ]; then
+do_check_supported=true
+elif [ $# -eq 1 ]; then
+kvers=$1
+fi
+shift 1
+done
+
+if [ -z $machine ]; then
 	get_machine
 fi
 
-if [ x$1 = x--supported ]; then
+if [ -n $do_check_supported ]; then
 	if check_supported $machine; then
 		exit 0
+	else
+		exit 1
 	fi
-	exit 1
 fi
 
-# kernel

Bug#735092: flash-kernel: add Raspberry Pi support

2014-01-12 Thread Karsten Merker
On Sun, Jan 12, 2014 at 07:01:36PM +, Ian Campbell wrote:
 On Sun, 2014-01-12 at 19:24 +0100, Karsten Merker wrote:
  On Sun, Jan 12, 2014 at 06:00:24PM +, Ben Hutchings wrote:
   On Sun, 2014-01-12 at 18:34 +0100, Karsten Merker wrote:
  
The attached patch adds Raspberry Pi support to flash-kernel.
  [SNIP]
   So the boot partition is mounted at /boot?  Doesn't that make it
   impossible to install packaged kernels (as dpkg needs to create hard
   links)?
  
  Installing a kernel package (locally built using make-kpkg) with
  a VFAT /boot does not show any problems here:
 
 The normal way of dealing with this is to not have the bootloader
 partition mounted on boot, this is described in flash-kernel via the
 Boot-Device field. I think this should be honoured for Rpi too.
 Rpi-ConfigTxt-Path would then be relative to this device.

Having the vfat boot partition as /boot is the standard way in
Raspbian (Debian/armhf rebuild for the Pi/armv6, official OS
distribution for the Pi) and is described this way in all user
documentation for the Pi.  This is also expected by other
software, in particular the firmware update mechanism, which
expects the firmware image to be at
/boot/bootcode.bin, as well as by the Raspberry Pi foundation's
kernel updates (which do not come as a Debian kernel package).

Not mounting the vfat boot partition at /boot would of course be
technically possible, but nobody actually does that on a Pi
and it would pose several problems:

- The firmware update mechanism would have to be changed. This is
  outside the scope of Debian and as installing firmware updates
  is something that happens rather frequently on the Pi, that
  must work without problems.

- All the Pi user documentation would have to be changed, which
  is also outside the scope of Debian.

- In case the vfat boot partition is not mounted at /boot,
  the firmware cannot anymore directly boot the /boot/vmlinuz-*
  and /boot/initrd.img-* files from the kernel package.
  That would therefore require copying the files from /boot
  to the actual vfat boot partition. 

  As having the vfat boot partition mounted on /boot is the
  actual default case, flash-kernel would have to handle this as
  well.  This means either special handling depending on whether
  the vfat partition is at /boot or not, or generally copying the
  kernel to the vfat partition under another name.  The latter
  would in the case vfat-at-/boot result in having the kernel and
  initrd twice on the already quite small system vfat partition,
  which is a route I would like to avoid.

All things taken together I think that we should simply
accept that the vfat boot partition gets mounted at /boot
on the Pi and use it this way.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#735092: flash-kernel: add Raspberry Pi support

2014-01-12 Thread Karsten Merker
On Sun, Jan 12, 2014 at 07:32:56PM +, Ben Hutchings wrote:
 On Sun, 2014-01-12 at 19:24 +0100, Karsten Merker wrote:
  On Sun, Jan 12, 2014 at 06:00:24PM +, Ben Hutchings wrote:

   So the boot partition is mounted at /boot?  Doesn't that make it
   impossible to install packaged kernels (as dpkg needs to create hard
   links)?
  
  Installing a kernel package (locally built using make-kpkg) with
  a VFAT /boot does not show any problems here:
 [...]
 
 Please also test upgrading (or simply reinstalling the same package
 again).

Indeed, reinstalling fails:

dpkg: error processing linux-image-3.12.6-rpi+_2014010201_armhf.deb (--install):
 unable to make backup link of `./boot/vmlinuz-3.12.6-rpi+' before installing 
new version: Operation not permitted

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#732310: xserver-xorg: xserver does not start after dist-upgrade from wheezy

2013-12-16 Thread Karsten
Package: xserver-xorg
Version: 1:7.7+4
Severity: important

Dear Maintainer,
at this time i only have console access and use reportbug.
I will see to attach the xsession-errors as soon as possible.

-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Jan  8  2012 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 2281744 Nov 25 14:55 /usr/bin/Xorg

Diversions concerning libGL are in place

diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by 
glx-diversions
diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by 
glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions
diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to 
/usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions
diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to 
/usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions
diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by 
glx-diversions
diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 
by glx-diversions
diversion of /usr/lib/x86_64-linux-gnu/libGL.so to 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions

VGA-compatible devices on PCI bus:
--
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108 [GeForce GT 
430] [10de:0de1] (rev a1)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 1319 May 30  2011 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 260.19.21  (buildmeister@builder101)  Thu Nov  4 
21:47:28 PDT 2010


Section ServerLayout
Identifier Layout0
Screen  0  Screen0 0 0
InputDeviceKeyboard0 CoreKeyboard
InputDeviceMouse0 CorePointer
EndSection

Section Files
EndSection

Section InputDevice

# generated from default
Identifier Mouse0
Driver mouse
Option Protocol auto
Option Device /dev/psaux
Option Emulate3Buttons no
Option ZAxisMapping 4 5
EndSection

Section InputDevice

# generated from default
Identifier Keyboard0
Driver kbd
EndSection

Section Monitor
Identifier Monitor0
VendorName Unknown
ModelName  Unknown
HorizSync   28.0 - 33.0
VertRefresh 43.0 - 72.0
Option DPMS
EndSection

Section Device
Identifier Device0
Driver nvidia
VendorName NVIDIA Corporation
EndSection

Section Screen
Identifier Screen0
Device Device0
MonitorMonitor0
DefaultDepth24
SubSection Display
Depth   24
EndSubSection
EndSection


/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 3.11-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 
(Debian 4.8.2-7) ) #1 SMP Debian 3.11.10-1 (2013-12-04)

Xorg X server log files on system:
--
-rw-r--r-- 1 webuser webuser 42479 Dec  4  2010 /var/log/Xorg.2.log
-rw-r--r-- 1 webuser webuser 20923 Feb 11  2013 /var/log/Xorg.1.log
-rw-r--r-- 1 rootroot19456 Dec 16 16:28 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[84.752] 
X.Org X Server 1.14.3
Release Date: 2013-09-12
[84.752] X Protocol Version 11, Revision 0
[84.752] Build Operating System: Linux 3.12.0-rc6-patser+ x86_64 Debian
[

Bug#704242: Driver for PL-2303 HX not working

2013-12-16 Thread Karsten Malcher

Am 15.12.2013 18:05, schrieb Greg KH:



Have you tried a newer kernel in a while?  A number of things have been
hopefully fixed since June when you last looked.

greg k-h

no at this time i have not tested it - sorry.
Although i am fascinated from your work i personally prefer to use stable 
releases for my daily work.
This bug here shows that several functionalites in detail can be lost with an 
update.
Then it takes much time to find workarounds - specially when hardware is not 
running any more.

When i look in the Debian repositories i only see kernel 3.11.10 for testing 
and unstable.
The latest one is 3.12.3 in experimental.
I will see to upgrade one copy of my installation to testing on another 
partition with 3.11.10.

Do you mean that will hopefully show a resolution for this problem?

I do not know, 3.11 is pretty old, sorry.


My distribution update fails into a system without X.
So no new tests with Kernel 3.11 so far.
I looked for a CD booting system with a newer kernel, but there seems to be no 
one?

* Knoppix Kernel 3.9.6
* Kubuntu Kernel 3.11 maybe a choice

As you can see - you can only dream of a 3.12.5 stable kernel. ;-)

But when Debian Testing will run i make a retest of the PL-2303 HX.

Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Driver for PL-2303 HX not working

2013-12-15 Thread Karsten Malcher

Hello Greg,

Am 14.12.2013 18:08, schrieb Greg KH:

On Fri, Dec 13, 2013 at 04:06:35PM +0100, Karsten Malcher wrote:

Hello together,

is there anything new for the PL-2303 HX?
It would be fine if it could work like in the past.

Have you tried a newer kernel in a while?  A number of things have been
hopefully fixed since June when you last looked.

greg k-h


no at this time i have not tested it - sorry.
Although i am fascinated from your work i personally prefer to use stable 
releases for my daily work.
This bug here shows that several functionalites in detail can be lost with an 
update.
Then it takes much time to find workarounds - specially when hardware is not 
running any more.

When i look in the Debian repositories i only see kernel 3.11.10 for testing 
and unstable.
The latest one is 3.12.3 in experimental.
I will see to upgrade one copy of my installation to testing on another 
partition with 3.11.10.

Do you mean that will hopefully show a resolution for this problem?

Regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Driver for PL-2303 HX not working

2013-12-13 Thread Karsten Malcher

Hello together,

is there anything new for the PL-2303 HX?
It would be fine if it could work like in the past.

Of course for Linux there are good alternatives.
Here is a new one with the CP2102 suffering easy supply voltage:
http://www.ebay.de/itm/110954294607

Best regards
Karsten


Am 24.06.2013 21:00, schrieb Greg KH:

On Mon, Jun 24, 2013 at 12:38:17PM -0400, Aric Fedida wrote:

I will gladly ship you one. Give me address details, and I'll go to
the post office to send it.

I'll send it off-list, thanks.


Personally, I have resolved to abandon the PL2303 chip, and move to
FTDI instead. But for the sake of other Linux users who might buy that
adapter by mistake, I am willing to donate the hardware to an able
kernel hacker :-)

Yes, I recommend the ftdi devices as well, the specs are availble, and
the driver seems to work better because of it.

thanks,

greg k-h



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#726666: [nepomuk-core-runtime] nepomuk requires virtuoso version 6.1.6

2013-11-20 Thread Karsten Borgwaldt
Package: nepomuk-core-runtime
Version: 4:4.11.3-1

After upgrading to nepomuk 4.11.3-1, the file indexer did not work anymore. 
.xsession-errors:
nepomukstorage(14192)/nepomuk (storage service): NepomukStorage only works 
with virtuoso 6.1.6 and beyond 
kcmshell(14101)/nepomuk (library): Could not find virtuoso to connect to. 
Aborting 

Removing the existing configs and database did not help. After installing 
virtuoso-minimal from unstable (version 6.1.6+dfsg-3) all services work as 
expected.

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.10-3-amd64

Debian Release: jessie/sid
  990 testing security.debian.org 
  990 testing ftp.de.debian.org 
  500 unstableftp.de.debian.org 
  500 testing-updates ftp.de.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-===
libavformat54  (= 6:9.1-1) | 6:9.10-1
libavutil52(= 6:9.1-1) | 6:9.10-1
libc6 (= 2.14) | 
libepub0 (= 0.1.1) | 
libexiv2-12 | 
libgcc1(= 1:4.1.1) | 
libkdecore5 (= 4:4.11) | 
libkdeui5   (= 4:4.11) | 
libkidletime4   (= 4:4.11) | 
libkio5 (= 4:4.11) | 
libnepomukcore4  (= 4:4.11.3-1) | 
libpoppler-qt4-3  (= 0.18) | 
libqt4-dbus(= 4:4.6.1) | 
libqt4-xml (= 4:4.5.3) | 
libqtcore4 (= 4:4.8.0) | 
libqtgui4  (= 4:4.5.3) | 
libsolid4   (= 4:4.11) | 
libsoprano4  (= 2.9.3) | 
libstdc++6 (= 4.6) | 
libtag1c2a (= 1.5) | 


Package's Recommends field is empty.

Package's Suggests field is empty.


smime.p7s
Description: S/MIME cryptographic signature


Bug#728014: [PATCH] Fix cross-building armhf kernel packages

2013-10-27 Thread Karsten Merker
Package: kernel-package
Version: 12.036+nmu3
Tags: patch

I am rather new to the arm architecture and currently trying to
get a couple of things working on a Raspberry Pi.  Building
kernel packages natively on a 700MHz single-core ARMv6 cpu takes
ages, so I have been looking into possibilities for
cross-building kernel packages from faster architectures. 
According to the make-kpkg manpage, the following command

  $ make-kpkg --arch armhf --cross_compile arm-rpi-linux-gnueabi- \
--revision 20131002 --append_to_version -rpi --initrd \
--us --uc --rootcmd fakeroot kernel_image

should build an armhf kernel package on an amd64 host with an
arm-rpi-linux-gnueabi-crosstoolchain installed. With
kernel-package 12.036+nmu3 this fails with

  debian/ruleset/misc/checks.mk:36: *** Error. I do not know
  where the kernel image goes to [kimagedest undefined] The usual
  case for this is that I could not determine which arch or
  subarch this machine belongs to.  Please specify a subarch, and
  try again..  Stop.

It looks like there are just a few definitions for armhf missing,
which are only used in the case of cross-building - native builds
work fine.  With the attached patch, cross-building kernel
packages for armhf works for me, i.e. it results in working
kernel-image packages for the Raspberry Pi.  I had asked on
debian-arm whether anybody sees issues with the patch, but have
received no reply.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
diff -Nur kernel-package-12.036+nmu3/kernel/ruleset/arches/armhf.mk kernel-package-12.036+nmu3.patched/kernel/ruleset/arches/armhf.mk
--- kernel-package-12.036+nmu3/kernel/ruleset/arches/armhf.mk	1970-01-01 01:00:00.0 +0100
+++ kernel-package-12.036+nmu3.patched/kernel/ruleset/arches/armhf.mk	2013-10-02 22:02:47.0 +0200
@@ -0,0 +1,34 @@
+# -*- Mode: Makefile-Gmake -*- 
+## armhf.mk --- 
+## 
+## This program is free software; you can redistribute it and/or modify
+## it under the terms of the GNU General Public License as published by
+## the Free Software Foundation; either version 2 of the License, or
+## (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful,
+## but WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+## GNU General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program; if not, write to the Free Software
+## Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+##
+###
+
+### ARMHF
+ifeq ($(strip $(architecture)),armhf)
+  kimage := vmlinuz
+  target = zImage
+  NEED_DIRECT_GZIP_IMAGE=NO
+  kimagesrc = arch/$(KERNEL_ARCH)/boot/zImage
+  kimagedest = $(INT_IMAGE_DESTDIR)/vmlinuz-$(KERNELRELEASE)
+  DEBCONFIG = $(CONFDIR)/config.armhf
+  kelfimagesrc = vmlinux
+  kelfimagedest = $(INT_IMAGE_DESTDIR)/vmlinux-$(KERNELRELEASE)
+endif
+
+#Local variables:
+#mode: makefile
+#End:
diff -Nur kernel-package-12.036+nmu3/kernel/ruleset/architecture.mk kernel-package-12.036+nmu3.patched/kernel/ruleset/architecture.mk
--- kernel-package-12.036+nmu3/kernel/ruleset/architecture.mk	2012-03-04 02:22:23.0 +0100
+++ kernel-package-12.036+nmu3.patched/kernel/ruleset/architecture.mk	2013-10-02 22:01:08.0 +0200
@@ -59,6 +59,10 @@
 ifeq ($(strip $(architecture)),armeb)
 include $(DEBDIR)/ruleset/arches/armeb.mk
 endif
+ifeq ($(strip $(architecture)),armhf)
+include $(DEBDIR)/ruleset/arches/armhf.mk
+endif
+
 
 # PowerPC and PowerPC architecture 
 ifneq ($(strip $(filter ppc powerpc ppc64 powerpc64,$(architecture))),)
diff -Nur kernel-package-12.036+nmu3/kernel/ruleset/misc/kernel_arch.mk kernel-package-12.036+nmu3.patched/kernel/ruleset/misc/kernel_arch.mk
--- kernel-package-12.036+nmu3/kernel/ruleset/misc/kernel_arch.mk	2012-03-04 02:39:27.0 +0100
+++ kernel-package-12.036+nmu3.patched/kernel/ruleset/misc/kernel_arch.mk	2013-10-02 21:55:54.0 +0200
@@ -56,6 +56,10 @@
   KERNEL_ARCH := arm
 endif
 
+ifeq ($(strip $(architecture)),armhf)
+  KERNEL_ARCH := arm
+endif
+
 ifeq ($(strip $(architecture)),hppa)
   KERNEL_ARCH := parisc
 endif


Bug#727102: wmbattery doesn't report battery status (3.2.0 kernel)

2013-10-22 Thread Karsten M. Self
Package: wmbattery
Version: 2.41
Severity: important

Dear Maintainer,

Following a system update and windowmanager (WindowMaker) restart,
wmbattery would launch but reports no charge in the bell, '00:00'
battery life, and 0% charge status.

APM doesn't appear to be supported by my kernel.  'acpi -b' _does_
report battery status, e.g.:  

$ acpi -b
Battery 0: Unknown, 95%

Providing the '-b 0' option to wmbattery results in a segfault.  '-b 1'
reports as indicated above.


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (999, 'testing'), (500, 'oldstable-updates'), (500, 'oldstable'), 
(400, 'experimental'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages wmbattery depends on:
ii  hal  0.5.14-8
ii  libapm1  3.2.2-14
ii  libc62.17-93
ii  libdbus-1-3  1.6.14-1
ii  libhal1  0.5.14-8
ii  libx11-6 2:1.6.2-1
ii  libxext6 2:1.3.2-1
ii  libxpm4  1:3.5.10-1

wmbattery recommends no packages.

Versions of packages wmbattery suggests:
ii  wmaker  0.95.4-2

-- no debconf information

-- 
Karsten M. Self kars...@linuxmafia.comhttp://linuxmafia.com/~karsten
 What part of gestalt don't you understand?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#723847: [Pkg-postgresql-public] Bug#723847: Bug#723847: Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?

2013-10-19 Thread Karsten Hilbert
On Sat, Oct 19, 2013 at 02:05:34PM +0200, Christoph Berg wrote:

 What we could do is to add this as an example (comment) to the default
 version we ship for createcluster.conf.

I would say that's better than the current situation.

Also, what about a debonf question of medium priority ?

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#723847: [Pkg-postgresql-public] Bug#723847: Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?

2013-10-16 Thread Karsten Hilbert
On Tue, Oct 15, 2013 at 11:15:07PM -0400, Peter Eisentraut wrote:

 On Sat, 2013-10-12 at 11:09 +0200, Karsten Hilbert wrote:
  So, to rephrase the question: I wonder whether --data-checksums
  can be pre-set in /etc/postgresql-common/createcluster.conf's
  initdb_options ?
 
 It doesn't matter where you attach the option, the answer is the same:
 Upstream has decided that checksums should not be the default at this
 time.  If you want to override that for the entire world of Debian, you
 need to come up with a good reason.

No problem. Just asking.

I do have good reasons but they probably only apply to
my universe (p.d.o/gnumed-server).

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#723847: [Pkg-postgresql-public] Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?

2013-10-12 Thread Karsten Hilbert
On Fri, Oct 11, 2013 at 04:29:59PM -0400, Peter Eisentraut wrote:

 On 9/20/13 8:51 AM, Karsten Hilbert wrote:
  Package: postgresql-9.3
  Version: 9.3~rc1-2
  Severity: wishlist
  
  I wonder whether --data-checksums / -k can be made the default for
  creating new clusters starting with PG 9.3.
 
 It's an upstream decision, and it's not our place to override that.

Well, OK, strictly speaking you are right because I
misdirected the report -- it should have gone
to postgresql-common since pg_upgradecluster belongs
to that.

Anything in postgresql-common ultimately is a Debian
decision (as it is not provided by upstream). I agree
those decisions may very well be in the *spirit* of
upstream's defaults.

So, to rephrase the question: I wonder whether --data-checksums
can be pre-set in /etc/postgresql-common/createcluster.conf's
initdb_options ?

Would you take care of re-attaching the report or should I
file a new one ?

Thanks for the work on PostgreSQL,
Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#725691: mc: erratic behaviour of mcedit as subprocess of mc

2013-10-07 Thread Karsten Hilbert
Package: mc
Version: 3:4.8.10-4
Severity: normal
Tags: upstream

With the latest update mcedit started to behave quite erratically:

When mcedit is invoked by typing

mcedit SOMEFILE

from the mc commandline rather then pressing F4 on
the file the editor will behave quite strange:

- at first no file content is shown
- upon pressing the first key the file content shows up
- all keys react very delayed or not at all
- the key delay is not predictable it differs
  from keystroke to keystroke
- which keys don't react at all is not predictable either,
  the affected keys change, even within one and the
  same mcedit session

The following has happened under the same circumstances
but already for a longer time (it worked before):

- ctrl/shift+INS copy/paste doesn't work
- cursor key based text selection doesn't work

Now, the answer might be: don't invoke mcedit manually under mc.
However, mcedit is configured to be my default editor (say,
sensible-editor and such) and thusly is invoked by many tools
(like git for editing commit messages).

Invoking mcedit from the shell makes it behave just fine.

Karsten

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (50, 
'unstable'), (10, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.10-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mc depends on:
ii  e2fslibs  1.42.8-1
ii  libc6 2.17-93
ii  libglib2.0-0  2.36.4-1
ii  libgpm2   1.20.4-6.1
ii  libslang2 2.2.4-15
ii  libssh2-1 1.4.3-1
ii  mc-data   3:4.8.10-4

Versions of packages mc recommends:
ii  mime-support  3.54
ii  perl  5.18.1-4
ii  unzip 6.0-9

Versions of packages mc suggests:
ii  acroread [pdf-viewer]  9.5.5-dmo1
ii  arj3.10.22-11
ii  bzip2  1.0.6-5
ii  catdvi 0.14-12.1
ii  dbview 1.0.4-1
ii  djvulibre-bin  3.5.25.4-2
ii  file   1:5.14-2
ii  genisoimage9:1.1.11-2
pn  gv none
ii  imagemagick8:6.7.7.10-6
ii  odt2txt0.4+git20100620-1+b1
ii  okular [pdf-viewer]4:4.10.5-1
ii  poppler-utils  0.18.4-8
ii  python 2.7.5-5
pn  python-botonone
ii  python-tz  2012c-1
ii  texlive-binaries   2013.20130729.30972-2
ii  w3m0.5.3-11
ii  xpdf [pdf-viewer]  3.03-11
ii  zip3.0-7

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#725692: mc: faulty behaviour of ALT-P

2013-10-07 Thread Karsten Hilbert
Package: mc
Version: 3:4.8.10-4
Severity: normal
Tags: upstream

Regardless of whether mcedit is called from bash
or from within an mc session this happens:

- ALT-P sometimes does not properly wrap the first
  line of a paragraph - it ends considerably
  shorter than what would have fit inside the
  configured maximum width

This has started to occur quite recently, maybe
even with 4.8.10.

Karsten

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (50, 
'unstable'), (10, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.10-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mc depends on:
ii  e2fslibs  1.42.8-1
ii  libc6 2.17-93
ii  libglib2.0-0  2.36.4-1
ii  libgpm2   1.20.4-6.1
ii  libslang2 2.2.4-15
ii  libssh2-1 1.4.3-1
ii  mc-data   3:4.8.10-4

Versions of packages mc recommends:
ii  mime-support  3.54
ii  perl  5.18.1-4
ii  unzip 6.0-9

Versions of packages mc suggests:
ii  acroread [pdf-viewer]  9.5.5-dmo1
ii  arj3.10.22-11
ii  bzip2  1.0.6-5
ii  catdvi 0.14-12.1
ii  dbview 1.0.4-1
ii  djvulibre-bin  3.5.25.4-2
ii  file   1:5.14-2
ii  genisoimage9:1.1.11-2
pn  gv none
ii  imagemagick8:6.7.7.10-6
ii  odt2txt0.4+git20100620-1+b1
ii  okular [pdf-viewer]4:4.10.5-1
ii  poppler-utils  0.18.4-8
ii  python 2.7.5-5
pn  python-botonone
ii  python-tz  2012c-1
ii  texlive-binaries   2013.20130729.30972-2
ii  w3m0.5.3-11
ii  xpdf [pdf-viewer]  3.03-11
ii  zip3.0-7

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#692957: Info received (Bug#692957: linux-image-3.2.0-4-amd64: NFS server causes high load on 3.2 kernel)

2013-09-25 Thread Karsten Suehring
Unforunately I could not follow up on the issue anymore because I had to
get my systems back into a running state.

If nobody else can reproduce it on Debian, then it is possible that the
issue was indeed related to Ubuntu only or the specific kernel version used
there. So this bug can probably be closed.

BR, Karsten


Bug#723847: postgresql-9.3: server - pg_upgradecluster - initdb: --data-checksums ?

2013-09-20 Thread Karsten Hilbert
Package: postgresql-9.3
Version: 9.3~rc1-2
Severity: wishlist

I wonder whether --data-checksums / -k can be made the default for
creating new clusters starting with PG 9.3.

If not it'd still be good to capture the rationale for that decision.

I am aware of

/etc/postgresql-common/createcluster.conf - initdb_options

and that has worked nicely for me.

Karsten

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'stable'), (50, 
'unstable'), (10, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.10-2-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages postgresql-9.3 depends on:
ii  libc6  2.17-92+b1
ii  libcomerr2 1.42.8-1
ii  libgssapi-krb5-2   1.11.3+dfsg-3
ii  libkrb5-3  1.11.3+dfsg-3
ii  libldap-2.4-2  2.4.31-1+nmu2+b1
ii  libpam0g   1.1.3-9
ii  libpq5 9.3~rc1-2
ii  libssl1.0.01.0.1e-3
ii  libxml22.9.1+dfsg1-3
ii  locales2.17-92
ii  locales-all [locales]  2.17-92+b1
ii  postgresql-client-9.3  9.3~rc1-2
ii  postgresql-common  149
ii  ssl-cert   1.0.33
ii  tzdata 2013d-1

postgresql-9.3 recommends no packages.

Versions of packages postgresql-9.3 suggests:
ii  locales-all 2.17-92+b1
pn  oidentd | ident-server  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#721595: KDE network manager does not work

2013-09-02 Thread Karsten Malcher

Package: plasma-widget-networkmanagement
Version: 0.9.0.3-1
Severity: important

Hello,

i am trying desperated to get WLAN working without problems on wheezy.
One time i get a connection, then never again.

I installed the network manager to have a comfortable configuration, but it 
seems not to have the correct rights to work.
The scanning for hotspots does not work and when i manually create a WLAN connection and try to save it, it fails with 
insufficient privileges (see screenshot).


As you can see here i have access to WLAN functionality on the shell:

root@pc# iwlist wlan2 scan
wlan2 Scan completed :
  Cell 01 - Address: 00:1E:58:BB:80:CD
Channel:1
Frequency:2.412 GHz (Channel 1)
Quality=68/70  Signal level=-42 dBm
Encryption key:on
ESSID:dd-wrt
Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
  9 Mb/s; 12 Mb/s; 18 Mb/s
Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
Mode:Master
Extra:tsf=
Extra: Last beacon: 32ms ago
IE: Unknown: 000664642D777274
IE: Unknown: 010882848B960C121824
IE: Unknown: 030101
IE: Unknown: 05040001
IE: Unknown: 2A0104
IE: Unknown: 32043048606C
IE: IEEE 802.11i/WPA2 Version 1
Group Cipher : TKIP
Pairwise Ciphers (1) : TKIP
Authentication Suites (1) : PSK
IE: Unknown: DD0900037F01010020FF7F


But automatically it is not configured correct with the WPA key:

root@pc# iwconfig
wlan2 IEEE 802.11abg  ESSID:dd-wrt
  Mode:Managed  Frequency:2.412 GHz  Access Point: 00:1E:58:BB:80:CD
  Tx-Power=200 dBm
  Retry  long limit:7   RTS thr:off   Fragment thr:off
  Encryption key:off
  Power Management:off


This is my current network configuration file:

root@pc:/etc/network# cat interfaces
...
allow-hotplug eth6
iface eth6 inet static
...
auto wlan2
iface wlan2 inet dhcp
wpa-ssid dd-wrt
wpa-psk mysecretpassword

Why the network manager has not enough privileges?
Any other idea to solve the problem?

Best regards
Karsten



-- System Information:
Debian Release: 7.1
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages plasma-widget-networkmanagement depends on:
ii  kde-runtime 4:4.8.4-2
ii  libc6   2.13-38
ii  libgcc1 1:4.7.2-5
ii  libkcmutils44:4.8.4-4
ii  libkdecore5 4:4.8.4-4
ii  libkdeui5   4:4.8.4-4
ii  libkio5 4:4.8.4-4
ii  libknotifyconfig4   4:4.8.4-4
ii  libplasma3  4:4.8.4-4
ii  libqt4-dbus 4:4.8.2+dfsg-11
ii  libqt4-network  4:4.8.2+dfsg-11
ii  libqt4-svg  4:4.8.2+dfsg-11
ii  libqt4-xml  4:4.8.2+dfsg-11
ii  libqtcore4  4:4.8.2+dfsg-11
ii  libqtgui4   4:4.8.2+dfsg-11
ii  libsolid4   4:4.8.4-4
ii  libsolidcontrol4abi24:4.8.4-6
ii  libstdc++6  4.7.2-5
ii  mobile-broadband-provider-info  20120708-1
ii  network-manager 0.9.4.0-10

Versions of packages plasma-widget-networkmanagement recommends:
ii  kwalletmanager   4:4.8.4-3
ii  network-manager-openvpn  0.9.4.0-1
ii  network-manager-pptp 0.9.4.0-2
ii  network-manager-vpnc 0.9.4.0-1

Versions of packages plasma-widget-networkmanagement suggests:
pn  kdebase-workspace-bin  none

-- no debconf information

attachment: privileges.png

Bug#721595: package not working

2013-09-02 Thread Karsten Malcher

Here is a forum thread with someone where it is not working also.
http://debianforum.de/forum/viewtopic.php?f=30t=138291

The solution was to deinstall the kde networkmanager and to install wicd.

root@weide:/home/hugo# apt-get purge network-manager
root@weide:/home/hugo# rm -r /etc/NetworkManager/
root@weide:/home/hugo# apt-get install wicd wicd-gtk wicd-curses

I think i will test it now.
Is this really the only solution?

Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#721595: KDE network manager does not work

2013-09-02 Thread Karsten Malcher

Hi Michael,

the first thing is that wicd doesn't work also. :-)
So i reinstalled the network-manager-kde.

Am 02.09.2013 14:10, schrieb Michael Biebl:

You've configured your network interface device(s) in
/etc/network/interface, that means they are managed by ifupdown.


It makes no difference if i have only the lines for iface lo in the 
interfaces file
or if the file doesn't exist.
Network is not coming up and the manager is not scanning for WLAN.
The same message with insufficient privileges appers by manual entry and save.

There must be more wrong.



If you want to manage your interface with
network-manager/plasma-widget-networkmanagement, you should remove those
interfaces from /etc/network/interfaces. See also
/usr/share/doc/network-manager/README.Debian


Hmm - this dependencies are not not clear for me and for other users.
It would be fine if the right dependencies would be checked when the package is 
installed.

It seems to be always a struggle to get WLAN running.
I will not think about bluetooth ..


Regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#721595: KDE network manager does not work

2013-09-02 Thread Karsten Malcher

Hi,

Am 02.09.2013 17:10, schrieb Michael Biebl:

Do you have a complete, default KDE desktop installation?


What's complete?
Default is very complicate with an upgraded system.

So i would say - No.


What's the output of 'ck-list-sessions' and 'pkaction'?


karsten@pc:~$ ck-list-sessions
Session1:
unix-user = '1000'
realname = 'Karsten'
seat = 'Seat1'
session-type = ''
active = TRUE
x11-display = ':0'
x11-display-device = '/dev/tty7'
display-device = ''
remote-host-name = ''
is-local = TRUE
on-since = '2013-09-02T15:54:11.303898Z'
login-session-id = '4294967295'

karsten@pc:~$ pkaction
Error getting authority: Error initializing authority: Error calling StartServiceByName for org.freedesktop.PolicyKit1: 
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program 
/usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success




Do you have polkit-kde-1 installed?




Yes
ii  polkit-kde-1 0.99.0-3   amd64KDE dialogs 
for PolicyKit


Thanks for your help so far.
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#721243: rsyslog: $PreserveFQDN on was not honored in some modules.

2013-08-29 Thread Karsten Schoeke
Package: rsyslog
Version: 5.8.11-3
Severity: important

plaese insert commit from rsysloggit 
http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=dec9bcfe2a869b0f70b5f2a18e08a0322ebf5517
I dont use the fqdn.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#720859: kwalletmanager does not start

2013-08-25 Thread Karsten Malcher

Package: kwalletmanager
Version: 4:4.8.4-3
Severity: important

Hello,
today i want to delete two stored passwords from kwallet.
But when i try to open the kwalletmanager nothing happens.
When i try to open it from the shell i get:

karsten@PC:~$ kwalletmanager
QDBusConnection: session D-Bus connection created before QCoreApplication. 
Application may misbehave.

Any ideas to solve the problem?

Best regards
Karsten



-- System Information:
Debian Release: 7.1
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages kwalletmanager depends on:
ii  kde-runtime  4:4.8.4-2
ii  libc62.13-38
ii  libkdecore5  4:4.8.4-4
ii  libkdeui54:4.8.4-4
ii  libkio5  4:4.8.4-4
ii  libqt4-dbus  4:4.8.2+dfsg-11
ii  libqt4-xml   4:4.8.2+dfsg-11
ii  libqtcore4   4:4.8.2+dfsg-11
ii  libqtgui44:4.8.2+dfsg-11
ii  libstdc++6   4.7.2-5

kwalletmanager recommends no packages.

kwalletmanager suggests no packages.

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#705919: Info received (Bug#705919: icedove does not play sounds (notifications when new messages arrive))

2013-07-22 Thread Karsten Malcher

Today after the next reboot it works!

My last actions where to install this two packages:
pulseaudio-esound-compat
alsaplayer-esd

I think this seems to fix the problem.

This bug can be closed.

Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#705919: icedove does not play sounds (notifications when new messages arrive)

2013-07-21 Thread Karsten Malcher

Hi,

Am 21.07.2013 14:20, schrieb Carsten Schoenert:

Hello Karsten,

Where i can see this?
There is no line with something like sound.
You found the related lines as you wrote in the other mail.


No - i opened prefs.js directly with an editor.


Found this two lines in prefs.js now:

user_pref(mail.biff.play_sound.type, 1);
user_pref(mail.biff.play_sound.url, file:///path/mysound.wav);

This means the file would be found in '/path/mysound.wav' ? Is that
true? And if so what about the access right of that file? Icedove is
able access that file (in context of your user permissions)?
A file location like this is very unconventional. Better select a file
inside your home directory.


Of course not - the file name was manually edited for the email from me.



If this want work your sound system is configured wrong.


My soundsystem is working perfect in all other cases.

I have renamed my prefs.js and started Icedove again.
Now i simply added the soundfile as shown in the screenshot.
This does not work!

The only thing i can do now is to try the original Thunderbird.

Cheers
Karsten

attachment: soundconfig.png

Bug#705919: icedove does not play sounds (notifications when new messages arrive)

2013-07-21 Thread Karsten Malcher

Hello Carsten,

i tested now with the original Thunderbird and there is no sound notification 
also.
So this should be a general problem or a sound misconfiguration.
I attached a screenshot for the sound configuration of the Thunderbird.

But how can i find the problem?
All other sound is working!
The file is playing perfect with any other soundplayer including aplay 
siehabenpost.wav.

Best regards
Karsten

attachment: thunderbird.png

Bug#705919: icedove does not play sounds (notifications when new messages arrive)

2013-07-21 Thread Karsten Malcher

One new idea basing on this Link:
http://forums.bodhilinux.com/index.php?/topic/5060-solved-thunderbird-stopped-playing-sound-when-new-messages-arrive/

The libs
libesd0
libcanberra0
libstdc
are installed.

Esound is installed, but the pulseaudio layer was missed first.
# dpkg -l | grep esound
ii  esound-common  0.2.41-10  all  Enlightened Sound Daemon - 
Common files
ii  pulseaudio-esound-compat   2.0-6.1amd64PulseAudio ESD compatibility 
layer


Sound is still not playing.
I found out that the esound daemon is not runnning.
But when i manually start esd this does not matter.

# esd -v
pulseaudio esd wrapper 2.0

I am not shure if this mus really run, because it is also a wrapper?

Regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#705919: icedove does not play sounds (notifications when new messages arrive)

2013-07-21 Thread Karsten Malcher

Hello Carsten,

thank you for response.

Can you supply me with some more details how to proceed your tests?

Am 21.07.2013 11:58, schrieb Carsten Schoenert:

Check your settings in your prefs.js if you have sound support enabled.


Where i can see this?
There is no line with something like sound.


Also check your setting in General if the selected 'Use the following
sound file' is working, if not you have missconfigured soundsystem.


There is a wav file selected, but this does not work.
Even with the play button nor with incoming mail.
This is the reason for this bug report.



If yes, please start with disabled plugins and in safe-mode, maybe there
is something that block the sound output.


I have no idea how to do this?


If that doesn't work backup your current profile and start from scratch
with a fresh clean profile. Very offen problems comes in context with a
old profile.js migrated from the beginning of using Icedove. To be
sure the problem is a real software problem please check if your issue
is not depending on the old profile.


I will try this, but this is really much work, because i have plenty of 
accounts and settings.

When you are waiting for mail response it is very helpful to get an
acoustic sign for incoming mails when you are not working on the
screen the whole time.



For me that isn't importend. I have static times there I check my mails,
I made the decision if I look at the mail, not the MTA.
My life is easier with that rule.


And i want to be notified.



And, Icedove will only play a sound if the mail is the really first one
new in the queue and you have no others unread new messages.
If you have other ones that are unread and a new mail is comming no sound
will played.


That's fullfilled.

Regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#705919: icedove does not play sounds (notifications when new messages arrive)

2013-07-21 Thread Karsten Malcher

Found this two lines in prefs.js now:

user_pref(mail.biff.play_sound.type, 1);
user_pref(mail.biff.play_sound.url, file:///path/mysound.wav);

Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working

2013-06-25 Thread Karsten Malcher

Hello Greg,

Am 24.06.2013 20:56, schrieb Greg KH:

But wiring that up to a real 9pin serial port would be a pain (doable,
but a pain).  Is there any devices out there with a DB-9 output
connector?

You mean if you want to test full handshake with all signals - that's true.

Which is what the driver needs to test, right?  And of course, everone
with this problem is properly hooking up these signals, right?


I can't speak for all applications but i never use the hardware handshake for 
data transfer.
As i have written i don't know applications that will do it. Like most of the 
older mobile adapters.
That's the reason why this PL-2303 HX adapter has no handshake signals outside.

Maybe some people abuse this input and output lines for IO purposes like for 
programmers.
One time is tried such an adapter like this but it does not work. ;-)
http://www.lancos.com/siprogsch.html
(I tried not to use it with an usb serial interface - i used a good and old PC 
UART.)


Otherwise, there will be problems as the pins could float and cause
transmissions / receive data to stop happening.


This should not happen if handshake is disabled.
In the case of this PL-2303 HX adapter it worked with windows and the older 
kernel without handshake.

But of course it is better when everything is tested.



At the least, loop-back testing is important.


This test is sufficient to see if the problem occurs.




The advantage of the adapter is to get directly 5V and 3,3V.

What do you mean by this?


Normally you use this adapters to transfer data from a microcontroller.
It is very useful when you have direct the necessary power supply for the 
microcontroller.
The PL-2303 can work with 5V and 3.3V logic and this adapter has also a 3.3V 
output for some mA.




I don't know some other adapter with exactly this chip, because i don't need 
them.
Only this Adapter which use the other chip ch341-uart which works without 
problems
http://www.ebay.com/itm/USB-to-RS232-Serial-9-Pin-DB9-Adapter-PC-PDA-RS-232-/180399132966

When i think about it i never seen that someone uses the handshake for this 
simple serial communication.
Not in communication with mobiles, ARM-boards or AVR microcontroller.
The built-in UART's in the ARM and AVR don't suffer handshake
signals, so that you must do it by software with additional IO
ports.

What's wrong with software flow control?


Nothing is wrong with it!
I just want to say that in most applications nobody use it.
You communicate from a quick PC to a slower microcontroller with at least slow 
data rates.
The microcontroller has an IRQ on the UART you can use for incoming data.
So this works normally without any problems and additional handshake.


   Why reinvent something that
has been successfully used for 30+ years?


Before 30 years computers where slow and without a multitasking OS.
So you need handshake when you don't want to loose data.

i think you misunderstand me.



thanks,

greg k-h


Regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Driver for PL-2303 HX not working

2013-06-25 Thread Karsten Malcher

Am 24.06.2013 21:00, schrieb Greg KH:

Personally, I have resolved to abandon the PL2303 chip, and move to
FTDI instead. But for the sake of other Linux users who might buy that
adapter by mistake, I am willing to donate the hardware to an able
kernel hacker :-)
Yes, I recommend the ftdi devices as well, the specs are availble, and
the driver seems to work better because of it.


Yes - i agree.
But you have no influence which chip is used when you buy an adapter or 
interface cable.
There are millions out there for mobiles, GPS, PDA, etc.
It's a pity when you can't connect your device because the usb serial chip is 
not supported in Linux.
(When you have a newer device you will find out that bluetooth is not working 
correct also.)



thanks,

greg k-h


Regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working

2013-06-25 Thread Karsten Malcher

Am 25.06.2013 18:54, schrieb Johan Hovold:

On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote:

Hello Greg,

have you buyed one of this jinxed PL-2303 HX adapters?

Yesterday i got this interesting mail from Aric, who has analyzed a
similar problem with this chip.

Why do you think that this is related to the problems you were
experiencing back in April?


Maybe Aric can explain it better?

I only see several problems to use a PL-2303 HX with newer kernels.


Just to be clear, that's your setup. AFAICT Aric never got his setup to
work with any kernel (but for a brief period with the same 3.0 kernel).


The only solution i see is to give up any PL-2303 HX device like Aric.
But the problems for other users will remain ...



As we discussed in April, there has been a lot of changes (including
performance improvements) made to the pl2303 driver since 2.6.32 which
could possibly explain why you did not trigger your (suspected) hw error
on really old kernels.


I remember a similar discussion on not reliable usb connectors with external 
hdd's.
This connectors are often produced cheap and the connection is not reliable 
each time after plugin.

When you argue that you must forget each device or hardware in case of an error, you can forgot much usb devices using 
with Linux.

(In fact windows just ignores the errors.)
My forecast is that the number of sporadic errors will increase, specially with 
usb 3.


Thanks,
Johan


Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working

2013-06-25 Thread Karsten Malcher

Am 25.06.2013 19:29, schrieb Johan Hovold:

Maybe Aric can explain it better?

I only see several problems to use a PL-2303 HX with newer kernels.


Just to be clear, that's your setup. AFAICT Aric never got his setup to
work with any kernel (but for a brief period with the same 3.0 kernel).

The only solution i see is to give up any PL-2303 HX device like Aric.
But the problems for other users will remain ...

Only if the hardware is actually broken, of course. I'm just saying that
it looks like two different (hw related) problems here.


Yes - that's correct. I misunderstood.
I could not detect wrong bytes when i received some bytes after plugin.
In fact we have to different problems here.

I remember a similar discussion on not reliable usb connectors with
external hdd's.
This connectors are often produced cheap and the connection is not
reliable each time after plugin.

When you argue that you must forget each device or hardware in case of
an error, you can forgot much usb devices using
with Linux.
(In fact windows just ignores the errors.)
My forecast is that the number of sporadic errors will increase,
specially with usb 3.

Sure, if it is something that can be worked around in software without
too much overhead for non-broken devices (I have only a working HX
here), then we can try it. Perhaps the device you were gonna send to
Greg can be used to implement such a work-around (or at least be used to
determine the cause of the problem).


This error override seems to work for some devices, but i have no knowledge of 
the general Linux USB architecture.
I only want to remark that it could happen sometimes that a device has a bad 
connection after plugin.
Next time it can work without any error.
Of course there is many cheap (china) hardware that always produces errors.
I have seen many bad usb hubs.



Johan


Hopefully the problem with the PL-2303 HX could be fixed in the future.
As Greg has written the RS-232 is not dead for more than 30 years and it will 
live for many more years.
Only this usb converters make simple and good things problematic ...

Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working

2013-06-24 Thread Karsten Malcher

Hello Greg,

Am 24.06.2013 18:17, schrieb Greg KH:

On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote:

Hello Greg,

have you buyed one of this jinxed PL-2303 HX adapters?

No, I have not been able to find one.  Does anyone know where I can
purchase one?


Just take this one:
http://www.ebay.com/itm/USB-To-RS232-TTL-PL2303HX-Auto-Converter-Module-5V-3-3V-Output-Converter-Adapter-/370812126675
US $1.67 and it is yours.




Yesterday i got this interesting mail from Aric, who has analyzed a
similar problem with this chip.  I think something went wrong in the
usb serial handling, but not in the driver itself.  But the error is
really complicate to figure out in the depth of the software.

The really annoying thing is that it worked with kernel 2.6.32.

That's a really long time ago, loads of things have changed since then.
If someone can run 'git bisect' to track down the problem, that would be
wonderful.


Yes - that would reduce the problem.
But i think it must be debugged with the correspondend hardware too, or not?



thanks,

greg k-h


Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Driver for PL-2303 HX not working

2013-06-24 Thread Karsten Malcher

Am 24.06.2013 18:38, schrieb Aric Fedida:

I will gladly ship you one. Give me address details, and I'll go to the post 
office to send it.

Personally, I have resolved to abandon the PL2303 chip, and move to FTDI 
instead. But for the sake of other Linux users who might buy that adapter by 
mistake, I am willing to donate the hardware to an able kernel hacker :-)


Yes - i will also spend $1,67 and buy one to send to the right destination 
address to help to solve the problem.
Just let me know ...

The advantage of this universal adapters is that you can simply shorten RXD and TXD for a loop with one of the included 
cables.


Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Fwd: Re: Bug#704242: Driver for PL-2303 HX not working

2013-06-24 Thread Karsten Malcher

Am 24.06.2013 20:18, schrieb Greg KH:

On Mon, Jun 24, 2013 at 06:41:38PM +0200, Karsten Malcher wrote:

Hello Greg,

Am 24.06.2013 18:17, schrieb Greg KH:

On Mon, Jun 24, 2013 at 10:41:07AM +0200, Karsten Malcher wrote:

Hello Greg,

have you buyed one of this jinxed PL-2303 HX adapters?

No, I have not been able to find one.  Does anyone know where I can
purchase one?

Just take this one:
http://www.ebay.com/itm/USB-To-RS232-TTL-PL2303HX-Auto-Converter-Module-5V-3-3V-Output-Converter-Adapter-/370812126675
US $1.67 and it is yours.

But wiring that up to a real 9pin serial port would be a pain (doable,
but a pain).  Is there any devices out there with a DB-9 output
connector?


You mean if you want to test full handshake with all signals - that's true.
The advantage of the adapter is to get directly 5V and 3,3V.

I don't know some other adapter with exactly this chip, because i don't need 
them.
Only this Adapter which use the other chip ch341-uart which works without 
problems
http://www.ebay.com/itm/USB-to-RS232-Serial-9-Pin-DB9-Adapter-PC-PDA-RS-232-/180399132966

When i think about it i never seen that someone uses the handshake for this 
simple serial communication.
Not in communication with mobiles, ARM-boards or AVR microcontroller.
The built-in UART's in the ARM and AVR don't suffer handshake signals, so that you must do it by software with 
additional IO ports.




thanks,

greg k-h


Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#711254: It's a problem of PHP and not MySQL

2013-06-10 Thread Karsten Malcher

Hello Bob,

Am 10.06.2013 02:30, schrieb Bob Proulx:
Thank you for the bug report. However this is very little to go upon. From what you have said so far there isn't 
enough information to know what might be happening. At this point the problem could be anything.


Yes - i have the same problem at this time.
But most of the applications are to complex for a simply debug.

Because php has been updated to 5.5.0 it is most likely that your wikimedia and phpbb applications are not updated to 
work with the changes in php 5.5. I think that is the most likely problem.


The server installation is complete new (no upgrade) with wheezy from beginning 
of may.
I installed most of the applications new to the latest stable releases.
So wikimedia is V 1.20.4.
The migration of the previous version seems not make problems.
What can i do more than to install the actual version?

There is other software that has no newer versions.
E.g. http://www.phpmyedit.org/
Here i have the problem that the software is doing nearly nothing.
There is no error message in the apache2 logs and links and buttons are not 
working.
But this error is consistent.

What i cannot understand is why an update is empty depending of the content 
(always simple text)?


If it didn't work at all then there would be many reports.


Yes - i wonder about this also .
And i thought that PHP is more downwards compatible.
Hopefully someone will answer with the same problem.


Therefore this is probably simply an incompatibility with the recent updates 
and changes in upstream php 5.5.


Up to now i can't find similar problem descriptions.

Since you have the problem, and no one else is seeing the problem so far, and you have been making progress debugging 
it then it would be most helpful if you could keep going and get to the bottom of the problem. Thanks, Bob 


I must find out how to increase the debug information of php5?


Here the installed packages:

ii  libapache2-mod-php5  5.4.4-14   i386 server-side, HTML-embedded 
scripting language (Apache 2 module)
ii  php5 5.4.4-14   all  server-side, HTML-embedded 
scripting language (metapackage)
ii  php5-cli 5.4.4-14   i386 command-line interpreter for 
the php5 scripting language
ii  php5-common  5.4.4-14   i386 Common files for packages built 
from the php5 source

ii  php5-curl5.4.4-14   
i386 CURL module for php5
ii  php5-exactimage  0.8.5-5i386 fast image manipulation library 
(PHP bindings)

ii  php5-gd  5.4.4-14   
i386 GD module for php5
ii  php5-geoip   1.0.7-8
i386 GeoIP module for php5
ii  php5-imagick 3.1.0~rc1-1+b2 
i386 ImageMagick module for php5
ii  php5-imap5.4.4-14   
i386 IMAP module for php5
ii  php5-intl5.4.4-14   i386 internationalisation module for 
php5

ii  php5-mcrypt  5.4.4-14   
i386 MCrypt module for php5
ii  php5-mysql   5.4.4-14   
i386 MySQL module for php5
ii  php5-pspell  5.4.4-14   
i386 pspell module for php5
ii  php5-recode  5.4.4-14   
i386 recode module for php5
ii  php5-sqlite  5.4.4-14   
i386 SQLite module for php5

Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#711254: [php-maint] Bug#711254: It's a problem of PHP and not MySQL

2013-06-10 Thread Karsten Malcher

Hello,

Am 10.06.2013 10:42, schrieb Ondřej Surý:

On Mon, Jun 10, 2013 at 9:58 AM, Karsten Malcher deb...@dct.mine.nu 
mailto:deb...@dct.mine.nu wrote:

The server installation is complete new (no upgrade) with wheezy from 
beginning of may.
I installed most of the applications new to the latest stable releases.
So wikimedia is V 1.20.4.


There was something related to the upgrade of mediawiki in Debian:

http://anonscm.debian.org/viewvc/pkg-mediawiki/mediawiki/trunk/debian/NEWS?view=markup

But I am not sure if this is related to your installation.


The user has all rights for the DB.
There is a good and comfatable installer for mediawiki.
Every checkes and migration works without problem.
I have the reported problems with the user.
For this i will ask the mediawiki team.



Does the affected applications use some common (could be PEAR or PECL or just some PHP files somewhere) library which 
you have installed by hand?


No - i only downloaded the installation file and unpacked it.

Thank you for help.
Karsten



Ondrej
--
Ondřej Surý ond...@sury.org mailto:ond...@sury.org



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#711254: It's a problem of PHP and not MySQL

2013-06-09 Thread Karsten Malcher

I activated the general log in MySQL and proofed what SQL is send to the server 
in the problematic updates.

In case of wikimedia no clear update command is send, but in phpbb i could see that the update is blank instead of the 
content.


1339 Query UPDATE phpbb_topics SET topic_title = '', topic_type = 0  WHERE 
topic_id = 1066

The topic_title should contain a text.

Something goes wrong in PHP5.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#711254: Bug reported to MySQL

2013-06-07 Thread Karsten Malcher

Please refer to the bug at mySQL:
http://bugs.mysql.com/bug.php?id=69430

I have done an additional test now.
Up to now i used phpmyadmin to talk to mysql.


Now i tried to use the shell command instead.

mysql -u username -ppassword dbname -e UPDATE user SET user_password = CONCAT(':A:', MD5('public')) WHERE user_name = 
'public'


This seems to work.

mysql -u username -ppassword dbname -eselect * from user WHERE user_name = 
'public'
+-+---++-+--+---+-++--+--+--+--+---++
| user_id | user_name | user_real_name | user_password   | 
user_newpassword | user_newpass_time | user_email  | user_touched   | 
user_token   | user_email_authenticated | user_email_token | user_email_token_expires | 
user_registration | user_editcount |

+-+---++-+--+---+-++--+--+--+--+---++
|   2 | public| Public | :A:4c9184f37cff01bcdc32dc486ec36961 | 
:B:b50fb7bb:e5fcb263a54546d423589c83cc5b1263 | 20130605082126| w...@dct.mine.nu | 20130605082131 | 
6cddefa506a7c33b9a7372af70c69604 | NULL | NULL | NULL | 
20071015111247|   1132 |

+-+---++-+--+---+-++--+--+--+--+---++

So maybe the problem is caused by PHP?


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#711254: mysql-server-5.5: Some inserts and updates with strange effects (missing results)

2013-06-05 Thread Karsten Malcher

Package: mysql-server-5.5
Version: 5.5.31+dfsg-0+wheezy1
Severity: important

Hello,

after my last update i have very strange effects on my webserver regarding 
mySQL.
One example with an installed wikimedia.

I can't use or update the user public.
The user exists - i can see it with

select * from user WHERE user_name = 'public'

but when i try to update the users password with

UPDATE user SET user_password = CONCAT(':A:', MD5('public')) WHERE user_name = 
'public'

no rows are affected.


The user is not found by the wiki when you try to login.
It's the same with the updatescript from wikimedia:

# php changePassword.php --user=public --password=public
No such user: public

There are also strange effects in other software like an phpbb forum.
I can add a thread but the title is missing and empty.
When i try to edit it sometimes a title is accepted and updated and sometimes 
it is empty again.

Everything else seems to work without problems.


I open this bug in hope that someone have the same problems.
Is it possible to roll back the last package updates only for mysql?

Best regards
Karsten


-- System Information:
Debian Release: 7.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-486
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages mysql-server-5.5 depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.49
ii  initscripts2.88dsf-41
ii  libc6  2.13-38
ii  libdbi-perl1.622-1
ii  libgcc11:4.7.2-5
ii  libstdc++6 4.7.2-5
ii  lsb-base   4.1+Debian8
ii  mysql-client-5.5   5.5.31+dfsg-0+wheezy1
ii  mysql-common   5.5.31+dfsg-0+wheezy1
ii  mysql-server-core-5.5  5.5.31+dfsg-0+wheezy1
ii  passwd 1:4.1.5.1-1
ii  perl   5.14.2-21
ii  psmisc 22.19-1+deb7u1
ii  zlib1g 1:1.2.7.dfsg-13

Versions of packages mysql-server-5.5 recommends:
ii  bsd-mailx [mailx]  8.1.2-0.2006cvs-1
ii  libhtml-template-perl  2.91-1

Versions of packages mysql-server-5.5 suggests:
pn  tinyca  none

-- debconf information:
* mysql-server/root_password_again: (password omitted)
* mysql-server/root_password: (password omitted)
  mysql-server/error_setting_password:
  mysql-server-5.5/postrm_remove_databases: false
  mysql-server-5.5/nis_warning:
  mysql-server-5.5/really_downgrade: false
  mysql-server-5.5/start_on_boot: true
  mysql-server/password_mismatch:
  mysql-server/no_upgrade_when_using_ndb:


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#706499: Ethernet with Realtek R8169 only working with IPV6

2013-05-06 Thread Karsten Malcher

Hello Ben,

yesterday i started my tests and the system just wants to blame me.

I connected the 1000 MB card with an additional network cable and i setup the 
/etc/network/interfaces with

# The primary network interface 1000 MB
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.3
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255

# The secondary network interface 100 MB
allow-hotplug eth1
iface eth1 inet static
address 192.168.1.4
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
dns-nameservers 192.168.1.1

and rebootet.
Afterwards the R8169 card works without problem.

# ip addr
1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 00:e0:52:c8:d4:38 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.4/24 brd 192.168.1.255 scope global eth0
inet6 fe80::2e0:52ff:fec8:d438/64 scope link
   valid_lft forever preferred_lft forever
3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 00:13:d4:d2:84:32 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.3/24 brd 192.168.1.255 scope global eth1
inet6 fe80::213:d4ff:fed2:8432/64 scope link
   valid_lft forever preferred_lft forever

# ifconfig
eth0  Link encap:Ethernet  Hardware Adresse 00:e0:52:c8:d4:38
  inet Adresse:192.168.1.4  Bcast:192.168.1.255  Maske:255.255.255.0
  inet6-Adresse: fe80::2e0:52ff:fec8:d438/64 
Gültigkeitsbereich:Verbindung
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
  RX packets:194 errors:0 dropped:0 overruns:0 frame:0
  TX packets:143 errors:0 dropped:0 overruns:0 carrier:0
  Kollisionen:0 Sendewarteschlangenlänge:1000
  RX bytes:21846 (21.3 KiB)  TX bytes:22549 (22.0 KiB)
  Interrupt:20 Basisadresse:0x8c00

eth1  Link encap:Ethernet  Hardware Adresse 00:13:d4:d2:84:32
  inet Adresse:192.168.1.3  Bcast:192.168.1.255  Maske:255.255.255.0
  inet6-Adresse: fe80::213:d4ff:fed2:8432/64 
Gültigkeitsbereich:Verbindung
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
  RX packets:27 errors:0 dropped:0 overruns:0 frame:0
  TX packets:64 errors:0 dropped:0 overruns:0 carrier:0
  Kollisionen:0 Sendewarteschlangenlänge:1000
  RX bytes:3052 (2.9 KiB)  TX bytes:4382 (4.2 KiB)
  Interrupt:17 Basisadresse:0xc400


The problem has come like a ghost and gone like a ghost.
It's hard to say for me but - the bug can be closed.
This problem is really not reproducible.

Now i must master my routing problem - maybe the problem will come up again ...

Best regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#706499: Ethernet with Realtek R8169 only working with IPV6

2013-05-05 Thread Karsten Malcher

Hello Ben,

Am 04.05.2013 23:19, schrieb Ben Hutchings:
No, I want bug reports that have useful information for working towards a solution. 


Then don't close bugs without trying to solve them please.
I am not a maintainer and an expert, but i am learning and do what is possible.


[...]

So this interface has not been brought up.  Neither IPv4 nor IPv6 will
work.


I have written that the server is in use.
Stable ethernet connection only over the built-in 100 network of the mainboard.
The 1000 card with R8169 is not in use at this moment.
I will connect it with an additional network cable to the switch and make a 
retest hopefully this evening.

As final solution i want to connect the internet router near the server to the internal 100 network and route it through 
the server to the 1000 card connected to the LAN. So i have a highspeed connection for the fileserver and only one 
network cable for the server and slower 100 internet router.


Just in this second i found an additional hint to solve the problem:
http://www.fene-blog.de/linux/kein-netzwerk-bei-debian-6-squeeze-und-realtek-r8168/
http://www.fene-blog.de/linux/debian-eth0-link-down-problem-mit-realtek-r8169-beheben/
http://forums.debian.net/viewtopic.php?f=5t=85431 (english)

It's written in german and says the problem is that the driver for 8169 is used 
instead of 8168.
This seems not to make sense but apparently has solved the problem for Debian 
Squeeze ?
(It's not clear if the chip 8168 or 8169 was in use.)
I have a network card with the
02:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI 
Gigabit Ethernet Controller (rev 10)

The driver for the 8168 is not in the testing distribution but seems to be in 
unstable.
http://packages.debian.org/unstable/main/r8168-dkms
I will try to compile it and test if it helps.

Regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#706499: Ethernet with Realtek R8169 only working with IPV6

2013-05-03 Thread Karsten Malcher

Am 02.05.2013 12:20, schrieb Ben Hutchings:
If you want us, as maintainers, to investigate a bug, you must let us decide what information we need. Please provide 
the whole boot log. 


On one side you want to have only bug reports with a solution and on the other side you want to be the only one who 
decides what information will be given in the bug report without any help from me.

Sorry - that don't fit together.


First i could work with eth0 and installed debian without problems.
After a reboot the problems come up.
Now i use eth1, because eth0 comes not up reliable.

I'm still unclear on what you mean by this.  Please provide the output
of 'ip addr' in the case where you consider that eth0 has not come up.

Ben.


O.K. The problem is that this is my server running without keyboard and screen 
standing in the basement.
That's the reason why eth must come up reliable to have access.
So it is running with the onboard 100 MB now and the 1000 MB R8169 is not 
connected.

For test purposes i can connect an additional network cable to the R8169 and 
make the tests you need.
But it seems to be senseless for a closed bug. ;-)


At this time:

# ip addr
1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0: BROADCAST,MULTICAST mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 00:e0:52:c8:d4:38 brd ff:ff:ff:ff:ff:ff
3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP 
qlen 1000
link/ether 00:13:d4:d2:84:32 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.3/24 brd 192.168.1.255 scope global eth1
inet6 fe80::213:d4ff:fed2:8432/64 scope link
   valid_lft forever preferred_lft forever


Best regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#706499: Ethernet with Realtek R8169 only working with IPV6

2013-05-02 Thread Karsten Malcher

Hello Ben,

Am 02.05.2013 01:41, schrieb Ben Hutchings:

Control: tag -1 moreinfo

Please provide:
- Kernel boot log (/var/log/dmesg)


Is provided in the first post.
Nothing special can be seen.

Maybe it is possible to activate a debug mode?

When i have enough information i may ask the kernel team.
But my experience is that the first question is It is working with the actual 
kernel?


- Network configuration files (/etc/network/interfaces and any others)


First i could work with eth0 and installed debian without problems.
After a reboot the problems come up.
Now i use eth1, because eth0 comes not up reliable.


- If you are using DHCP, the DHCP daemon log messages
   (grep dhclient /var/log/daemon.log)


It's configuration with static IP's.



Ben.



Karsten
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface 1000 MB
allow-hotplug eth0
iface eth0 inet static
address 192.168.1.3
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 192.168.1.1

# The secondary network interface 100 MB
allow-hotplug eth1
iface eth1 inet static
address 192.168.1.4
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255


Bug#706499: Ethernet with Realtek R8169 only working with IPV6

2013-05-02 Thread Karsten Malcher

Hello Ben,

maybe you are right and this is not a bug.
But it is caused by an alternating configuration.

I think it is not caused by the firmware and the driver.
As i have written first the eth0 works without no problem.
I have ethernet cards with the same chip on other PC's and the problem does not 
occur.
It must be a special combination so only soome users are affected.

When i boot the backup of this first configuration from the second partition 
eth0 works again.
After some time and additional installation of packages there seems to go 
something wrong.
But the error first occured after a reboot.
I remember that only IPV6 was active but no IPV4.

My question is where IPV4 is activated and configured?

Best regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#706583: Installation report Wheezy DI rc2 amd64 xfce: installation ok

2013-05-01 Thread Karsten Merker
Package: installation-reports

Boot method: isohybrid image booted from USB stick
Image version: 
http://cdimage.debian.org/cdimage/wheezy_di_rc2/amd64/iso-cd/debian-wheezy-DI-rc2-amd64-netinst.iso
Date: 2013-05-01

Mainboard: ECS P35T-A
Processor: Intel E3300
Memory: 4GB

Output of lspci -knn (or lspci -nn):
00:00.0 Host bridge [0600]: Intel Corporation 82G33/G31/P35/P31 Express DRAM 
Controller [8086:29c0] (rev 02)
00:01.0 PCI bridge [0604]: Intel Corporation 82G33/G31/P35/P31 Express PCI 
Express Root Port [8086:29c1] (rev 02)
00:19.0 Ethernet controller [0200]: Intel Corporation 82566DC-2 Gigabit Network 
Connection [8086:294c] (rev 02)
00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #4 [8086:2937] (rev 02)
00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #5 [8086:2938] (rev 02)
00:1a.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #2 [8086:293c] (rev 02)
00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio 
Controller [8086:293e] (rev 02)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 1 [8086:2940] (rev 02)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 2 [8086:2942] (rev 02)
00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 3 [8086:2944] (rev 02)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 4 [8086:2946] (rev 02)
00:1c.4 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express 
Port 5 [8086:2948] (rev 02)
00:1d.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #1 [8086:2934] (rev 02)
00:1d.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #2 [8086:2935] (rev 02)
00:1d.2 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #3 [8086:2936] (rev 02)
00:1d.3 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI 
Controller #6 [8086:2939] (rev 02)
00:1d.7 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
Controller #1 [8086:293a] (rev 02)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 
92)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801IH (ICH9DH) LPC Interface 
Controller [8086:2912] (rev 02)
00:1f.2 IDE interface [0101]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 
port SATA Controller [IDE mode] [8086:2920] (rev 02)
00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller 
[8086:2930] (rev 02)
00:1f.5 IDE interface [0101]: Intel Corporation 82801I (ICH9 Family) 2 port 
SATA Controller [IDE mode] [8086:2926] (rev 02)
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI 
RV505 [Radeon X1550 Series] [1002:7143]
01:00.1 Display controller [0380]: Advanced Micro Devices [AMD] nee ATI RV505 
[Radeon X1550 Series] (Secondary) [1002:7163]
06:00.0 SATA controller [0106]: JMicron Technology Corp. JMB361 AHCI/IDE 
[197b:2361] (rev 02)
06:00.1 IDE interface [0101]: JMicron Technology Corp. JMB361 AHCI/IDE 
[197b:2361] (rev 02)

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Clock/timezone setup:   [O]
User/password setup:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

The installation process worked flawlessly.  Installation
was done using a network mirror; network connectivity was
provided via a TP-Link TL-WN727N 802.11n WLAN dongle
(USB ID: 148f:5370, Ralink RT5370 chipset).

The installer prompted for the WLAN dongle's firmware, which was
provided on a USB stick (downloaded from
http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/wheezy/current/).

Basic X11 functionality worked out of the box, advanced X11
features (in particular XVideo support) required installation of
the non-free radeon firmware from the package firmware-linux-nonfree.

A sidenote: while the WLAN via the TL-WN727N generally works,
interactive use (in particular using logins via ssh) shows that
the connection often has short lags or hangs.  This happens even
when the WLAN dongle is within 2m of the access point with direct
line of sight.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#706499: Ethernet with Realtek R8169 only working with IPV6

2013-04-30 Thread Karsten Malcher

Package: firmware-realtek
Version: 0.36+wheezy.1
Severity: normal

Hello,

please refer to this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611954
and
http://serverfault.com/questions/384165/after-installing-debian-squeeze-ethernet-does-not-come-up

The card only works when you do a manually ifup eth0 with IPV4.
But not every time - sometimes it is simply dead for IPV4.

Here what you see when it comes up:

[   12.096480] uli526x :00:0d.0: eth1: NIC Link is Down
[   12.551617] r8169 :02:07.0: eth0: link up
[   12.551821] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   18.235598] Netfilter messages via NETLINK v0.30.
[   22.568023] eth0: no IPv6 routers present
[   24.229825] device eth0 entered promiscuous mode
[  260.098704] device eth0 left promiscuous mode
[ 1222.481295] r8169 :02:07.0: eth0: link down
[ 1222.481308] r8169 :02:07.0: eth0: link down
[ 1222.481564] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 1225.543046] r8169 :02:07.0: eth0: link up
[ 1225.543248] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 1235.824012] eth0: no IPv6 routers present

lspci shows:

02:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8169 PCI 
Gigabit Ethernet Controller (rev 10)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8169/8110 Family PCI 
Gigabit Ethernet NIC
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 20
I/O ports at e000 [size=256]
Memory at fbff9c00 (32-bit, non-prefetchable) [size=256]
Expansion ROM at fbfc [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Kernel driver in use: r8169

Regards
Karsten


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-486
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools0.109.1
ii  linux-image-3.2.0-4-486 [linux-image]  3.2.41-2

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#705912: edfbrowser: new upstream (1.50) available

2013-04-22 Thread Karsten Hilbert
Package: edfbrowser
Version: 1.48-1
Severity: wishlist
Tags: upstream

Upstream has released 1.50:

http://www.teuniz.net/edfbrowser/

Please package as time permits.

Thanks,
Karsten

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 
'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages edfbrowser depends on:
ii  libc6   2.13-38
ii  libgcc1 1:4.7.2-5
ii  libqtcore4  4:4.8.2+dfsg-11
ii  libqtgui4   4:4.8.2+dfsg-11
ii  libstdc++6  4.7.2-5

edfbrowser recommends no packages.

edfbrowser suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#705919: icedove does not play sounds (notifications when new messages arrive)

2013-04-22 Thread Karsten Malcher

Package: icedove
Version: 10.0.12-1
Severity: normal

This bug still exists for 3 years now!
Please refer to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598379

There are many people affected by this bug mostly with no solution.
For instance look here:
http://crunchbang.org/forums/viewtopic.php?id=18383

Cheers
Karsten


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)

Versions of packages icedove depends on:
ii  debianutils   4.3.2
ii  fontconfig2.9.0-7.1
ii  libasound21.0.25-4
ii  libatk1.0-0   2.4.0-2
ii  libc6 2.13-38
ii  libcairo2 1.12.2-3
ii  libdbus-1-3   1.6.8-1
ii  libdbus-glib-1-2  0.100.2-1
ii  libevent-2.0-52.0.19-stable-3
ii  libffi5   3.0.10-3
ii  libfontconfig12.9.0-7.1
ii  libfreetype6  2.4.9-1.1
ii  libgcc1   1:4.7.2-5
ii  libgdk-pixbuf2.0-02.26.1-1
ii  libglib2.0-0  2.33.12+really2.32.4-5
ii  libgtk2.0-0   2.24.10-2
ii  libhunspell-1.3-0 1.3.2-4
ii  libjpeg8  8d-1
ii  libnspr4  2:4.9.2-1
ii  libnspr4-0d   2:4.9.2-1
ii  libnss3   2:3.14.3-1
ii  libnss3-1d2:3.14.3-1
ii  libpango1.0-0 1.30.0-1
ii  libpixman-1-0 0.26.0-4
ii  libsqlite3-0  3.7.13-1
ii  libstartup-notification0  0.12-1
ii  libstdc++64.7.2-5
ii  libvpx1   1.1.0-1
ii  libx11-6  2:1.5.0-1
ii  libxext6  2:1.3.1-2
ii  libxrender1   1:0.9.7-1
ii  libxt61:1.1.3-1
ii  psmisc22.19-1+deb7u1
ii  zlib1g1:1.2.7.dfsg-13


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#705919: icedove does not play sounds (notifications when new messages arrive)

2013-04-22 Thread Karsten Malcher

Hello Carsten

Am 22.04.2013 11:06, schrieb Carsten Schoenert:

hmm, there is no need to open a new bug for an already existing issue so I 
merge this two bugs together.


Yes - but my try to update the version fails. ;-)


As far as I remember the sound notification work with KDE, but I will check it 
next time.


How can i debug this?
The error should be searched where it occurs or not?

Maybe I just turn this off, because I don't need this. Regards Carsten 


That's maybe the problem.
In the forum they said it is not compiled correctly with the right suppport of 
sound and external links.

When you are waiting for mail response it is very helpful to get an acoustic sign for incoming mails when you are not 
working on the screen the whole time.


Regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Driver for PL-2303 HX not working

2013-04-19 Thread Karsten Malcher

Am 18.04.2013 11:35, schrieb Johan Hovold:

I have used a little perl program that opens the port and send Test
to the looped back device.
The length of the log looks good.

Great. Now I can see what's going on. The only problem (?) is that
everything seems to be working. The write succeeds and the four bytes
are read back as they should by the driver.


But where the data has gone?
With cutecom i can see that some of the first bytes are looped back.

It must be possible to read any binary (streamed) data.



The first thing that comes to mind that could prevent you from reading
the received data would be if the tty device is configured for canonical
input processing. Have you made sure this is not the case? Can you read
the data back if you add a newline to your test string (e.g. test\n)?


Hmmn - i don't know which method is used by programs like cutecom or putty?
But i know everything works fine before.
In this programs every data is terminated with newline, but it does not work.

I use this script with a ch341 adapter and it works.

Hmmm. Did you remember to initialise the device (e.g. set the termios
flags)?


Here you can see what's initialized in Perl:

use Device::SerialPort 0.12;

$port-baudrate(9600)   || die failed setting baudrate;
$port-parity(none)|| die failed setting parity;
$port-databits(8)   || die failed setting databits;
$port-handshake(none) || die failed setting handshake;
$port-write_settings|| die could not write settings;
$port-lookclear || die could not empty buffer;
$port-read_char_time(0);# don't wait for each character
$port-read_const_time(1000);# 1 second per unfulfilled read call
my $STALL_DEFAULT = 1;# how many seconds to wait for new input


Cheers
Karsten



Johan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Driver for PL-2303 HX not working

2013-04-19 Thread Karsten Malcher

Am 18.04.2013 12:56, schrieb Johan Hovold:


Can you generate a log where bytes are actually lost? Nothing seemed to
get lost in the previous log you posted.


This was a log with lost data.
The logs seems to make politics. ;-)


How can i enable the debugging in kernel 3.8.5?

Make sure debugfs is mounted:

mount -t debugfs none /sys/kernel/debug

and then enable debugging:

echo module usbserial +p/sys/kernel/debug/dynamic_debug/control
echo module pl2303 +p/sys/kernel/debug/dynamic_debug/control

Johan


Sorry - this does not work for me?

root@PC# mount -t debugfs none /sys/kernel/debug

root@PC# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=1014924,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=819796k,mode=755)
/dev/disk/by-uuid/5166cbb1-8234-4127-bb0b-bbfda1658b68 on / type ext4 
(rw,relatime,errors=remount-ro,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=1679740k)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
none on /sys/kernel/debug type debugfs (rw,relatime)

root@PC# echo module usbserial +p /sys/kernel/debug/dynamic_debug/control
bash: /sys/kernel/debug/dynamic_debug/control: Datei oder Verzeichnis nicht 
gefunden

root@PC# ls -l /sys/kernel/debug
insgesamt 0
drwx-- 14 root root 0 Apr 19 10:27 .
drwxr-xr-x  6 root root 0 Apr 19 10:27 ..
drwxr-xr-x  2 root root 0 Apr 19 10:27 acpi
drwxr-xr-x 17 root root 0 Apr 19 10:27 bdi
drwxr-xr-x  2 root root 0 Apr 19 10:27 extfrag
-r--r--r--  1 root root 0 Apr 19 10:27 gpio
drwxr-xr-x  4 root root 0 Apr 19 10:27 hid
drwxr-xr-x  2 root root 0 Apr 19 10:27 kprobes
drwxr-xr-x  2 root root 0 Apr 19 10:27 kvm
drwxr-xr-x  2 root root 0 Apr 19 10:27 mce
drwxr-xr-x  2 root root 0 Apr 19 10:27 regmap
drwxr-xr-x  3 root root 0 Apr 19 10:27 regulator
-rw-r--r--  1 root root 0 Apr 19 10:27 sched_features
-r--r--r--  1 root root 0 Apr 19 10:27 suspend_stats
drwxr-xr-x  5 root root 0 Apr 19 10:27 tracing
drwxr-xr-x  2 root root 0 Apr 19 10:27 usb
-r--r--r--  1 root root 0 Apr 19 10:27 wakeup_sources
drwxr-xr-x  2 root root 0 Apr 19 10:27 x86

Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Driver for PL-2303 HX not working

2013-04-19 Thread Karsten Malcher

Hi Johan,

Am 19.04.2013 11:04, schrieb Johan Hovold:

This was a log with lost data.
The logs seems to make politics. ;-)

Then the problem is most likely not in the driver as the characters are
being read back in the log you provided.


Stop - it's really possible that i send not enough bytes.
Sometimes up to 6 Bytes will come back.

This time i send this string (3.2.0):
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890\n
I get back the first 3 Bytes of it.
Log is attached.

Before closing the connection Perl sends a  'stty -aF /dev/ttyUSB0' and prints 
the result:

speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef;
eol2 = undef; swtch = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 16;
-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke


canonical-mode is not enabled and I get back 3 bytes - so data is not lost 
complete.
With cutecom it's -icanon also. So everything should be fine.

There are 2 beasty questions left:
1. Why it works with PL2303H ?
2. Why i receive sometimes the first bytes?



Now that you have compiled your own kernel, you could run a git bisect
to learn if anything else has changed in the kernel (possibly
interacting with your test setup) which can explain why things
stopped working.


I learned much in kernel testing the last time ... :-)
Maybe there is a HowTo for the bisect testing?


Your kernel is not configured to use dynamic debugging. You need to
enable CONFIG_DYNAMIC_DEBUG=y.


Oh - then i must compile again.
I found
   # CONFIG_DYNAMIC_DEBUG is not set
in .config.



Johan


Karsten

[ 1443.104346] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_install
[ 1443.104363] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_open - port 0
[ 1443.104366] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open -  port 0
[ 1443.104581] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x8:0x0  0
[ 1443.106606] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x9:0x0  0
[ 1443.106619] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios -  port 0
[ 1443.108584] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0  7 - 80 25 0 0 0 0 8
[ 1443.108594] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - data bits = 8
[ 1443.108603] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud requested = 9600
[ 1443.108611] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud set = 9600
[ 1443.108618] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - stop bits = 1
[ 1443.108625] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - parity = none
[ 1443.110595] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x21:0x20:0:0  7
[ 1443.112584] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0  7 - 80 25 0 0 0 0 8
[ 1443.114595] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x0:0x0  0
[ 1443.114605] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting read urb
[ 1443.114627] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting interrupt urb
[ 1443.116581] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: set_control_lines - value = 3, retval = 0
[ 1443.116821] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401
[ 1443.116832] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401
[ 1443.116841] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401
[ 1443.116903] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401
[ 1443.116913] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401

Bug#704242: Driver for PL-2303 HX not working

2013-04-18 Thread Karsten Malcher

Am 17.04.2013 15:13, schrieb Johan Hovold:

Can you try to reproduce this on a later kernel (e.g. 3.8) which uses
dynamic debugging?


I have compiled a 3.8.5 kernel now on Debian testing (wheezy).
The result is the same as in 3.2.0 !
I could receive only some of the first bytes after opening the port afterwards 
everything is lost without errors.

How can i enable the debugging in kernel 3.8.5?

root@PC# modprobe usbserial debug=1
ERROR: could not insert 'usbserial': Invalid argument
root@PC# modprobe pl2303 debug=1
ERROR: could not insert 'pl2303': Invalid argument

Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#704242: Driver for PL-2303 HX not working

2013-04-17 Thread Karsten Malcher

Am 17.04.2013 15:13, schrieb Johan Hovold:

The logs look incomplete. It's probably because they're flooded with
serial_write_room and chars_in_buffer messages.


Hmmm - i feared that this happens - the logs where to big.



Can you try to reproduce this on a later kernel (e.g. 3.8) which uses
dynamic debugging?


I will try to compile a kernel 3.8.5 like this way:
http://verahill.blogspot.de/2013/02/342-compiling-kernel-38-on-debian.html
But this will take some time ...



Can you minimise your test setup using a custom program which only opens
the device, initialises it, writes the four characters (e.g. test)
and reads them back (over you hardwired loop) before closing the device
again?


I have used a little perl program that opens the port and send Test to the 
looped back device.
The length of the log looks good.


  Make sure to verify it using a working device first.


I use this script with a ch341 adapter and it works.



Thanks,
Johan


Cheers
Karsten

[ 1714.545685] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_install
[ 1714.545704] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_open - port 0
[ 1714.545708] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open -  port 0
[ 1714.546283] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x8:0x0  0
[ 1714.548272] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x9:0x0  0
[ 1714.548276] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios -  port 0
[ 1714.550281] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0  7 - 80 25 0 0 0 0 8
[ 1714.550284] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - data bits = 8
[ 1714.550287] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud requested = 9600
[ 1714.550289] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - baud set = 9600
[ 1714.550291] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - stop bits = 1
[ 1714.550292] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - parity = none
[ 1714.552272] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x21:0x20:0:0  7
[ 1714.554290] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0  7 - 80 25 0 0 0 0 8
[ 1714.556270] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0x40:0x1:0x0:0x0  0
[ 1714.556283] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting read urb
[ 1714.556305] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - submitting interrupt urb
[ 1714.557255] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_read_int_callback (0)
[ 1714.557261] pl2303 ttyUSB0: pl2303_read_int_callback - length = 10, data = a1 20 00 00 00 00 02 00 8b 00 
[ 1714.557271] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/generic.c: usb_serial_handle_dcd_change - port 0, status 1
[ 1714.558284] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: set_control_lines - value = 3, retval = 0
[ 1714.558522] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401
[ 1714.558534] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401
[ 1714.558543] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401
[ 1714.558604] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401
[ 1714.558613] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401
[ 1714.558622] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401
[ 1714.558856] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401
[ 1714.558866] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd = 0x5401
[ 1714.558875] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not supported = 0x5401
[ 1714.558886] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/usb-serial.c

Bug#704242: Driver for PL-2303 HX not working

2013-04-14 Thread Karsten Malcher

Hi,
Hi, Fri, 12 Apr 2013, 9:43 +02:00 from Karsten Malcher deb...@dct.mine.nu:

Very strange.
As i have written i have an old mobile adapter with PL2303 H that's running 
without no problem in Linux.

I suppose it's a genuine one :)


It seems so.




There are adapters with HL-340 chip (ID 1a86:7523), that are running without 
problems in Linux too.

It's not a PL-2303 clone, but a different device; ch341 kernel module is used 
for it.


Yes - but here the cheap china devices are working.
But often you don't know which chip you get when you buy an adapter.

By the way, have you tried to do the simple loopback test?


No - but now i tested it with 9600 baud.
The result is the same.
No input over RXD without any debug message.


Just connect Rx  Tx pins together, try to send something and check what's 
received,
e. g. with help of some terminal application.


Here the debug output opening TTYUSB0:

[ 3476.251300] 
/build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c:
 pl2303_open -  port 0
[ 3476.252276] 
/build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c:
 0x40:0x1:0x8:0x0  0
[ 3476.254283] 
/build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c:
 0x40:0x1:0x9:0x0  0
[ 3476.254295] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios -  
port 0
[ 3476.256271] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0  7 - 80 
25 0 0 0 0 8
[ 3476.256281] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - 
data bits = 8
[ 3476.256290] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - 
baud requested = 9600
[ 3476.256298] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - 
baud set = 9600
[ 3476.256306] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - 
stop bits = 1
[ 3476.256313] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios - 
parity = none

[ 3476.258281] 
/build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c:
 0x21:0x20:0:0  7
[ 3476.260269] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xa1:0x21:0:0  7 - 80 
25 0 0 0 0 8

[ 3476.262282] 
/build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c:
 0x40:0x1:0x0:0x0  0
[ 3476.262293] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - 
submitting read urb
[ 3476.262315] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_open - 
submitting interrupt urb
[ 3476.264258] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 
pl2303_read_int_callback (0)

[ 3476.264263] pl2303 ttyUSB0: pl2303_read_int_callback - length = 10, data =
[ 3476.264272] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: set_control_lines - 
value = 3, retval = 0

[ 3476.264284] a1 20 00 00 00 00 02 00 8b 02
[ 3476.264302] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd 
= 0x540b
[ 3476.264311] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not 
supported = 0x540b
[ 3476.264327] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd 
= 0x5401
[ 3476.264335] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not 
supported = 0x5401
[ 3476.264345] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd 
= 0x5401
[ 3476.264353] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not 
supported = 0x5401
[ 3476.264365] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd 
= 0x5401
[ 3476.264373] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not 
supported = 0x5401
[ 3476.264381] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd 
= 0x5402
[ 3476.264389] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not 
supported = 0x5402
[ 3476.264399] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_set_termios -  
port 0
[ 3476.264409] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl (0) cmd 
= 0x5401
[ 3476.264417] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: pl2303_ioctl not 
supported = 0x5401

Bug#704242: Driver for PL-2303 HX not working

2013-04-12 Thread Karsten Malcher
:
 0x40:0x1:0x404:0x0  0
[ 1863.394045] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0  
1 - 0
[ 1863.394169] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8383:0x0  
1 - 0
[ 1863.394293] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0  
1 - 0

[ 1863.394419] 
/build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c:
 0x40:0x1:0x404:0x1  0
[ 1863.394544] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8484:0x0  
1 - 0
[ 1863.394700] /build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c: 0xc0:0x1:0x8383:0x0  
1 - 0

[ 1863.394913] 
/build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c:
 0x40:0x1:0x0:0x1  0
[ 1863.395038] 
/build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c:
 0x40:0x1:0x1:0x0  0
[ 1863.395162] 
/build/buildd-linux_3.2.23-1-amd64-zj7gxu/linux-3.2.23/drivers/usb/serial/pl2303.c:
 0x40:0x1:0x2:0x24  0
[ 1863.395269] usb 1-2.3: pl2303 converter now attached to ttyUSB0


I added the output of lsusb -v too.

Cheers
Karsten


Bus 001 Device 018: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize0 8
  idVendor   0x067b Prolific Technology, Inc.
  idProduct  0x2303 PL2303 Serial Port
  bcdDevice2.02
  iManufacturer   0 
  iProduct0 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   39
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x000a  1x 10 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   0
Bus 001 Device 017: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   1.10
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x067b Prolific Technology, Inc.
  idProduct  0x2303 PL2303 Serial Port
  bcdDevice3.00
  iManufacturer   1 
  iProduct2 
  iSerial 0 
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   39
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  100mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer

Bug#704242: Driver for PL-2303 HX not working

2013-03-30 Thread Karsten Malcher

Package: src:linux
Version: 3.2.23-1
Severity: important


Hello,

i have the problem that i have nearly no serial communication with a 
USB-Serial-Adapter type PL-2303 HX.
The interesting point is that i have an older adapter and this is working 
without problems.

When you use the check tool of profilic the running chip is identified as 
PL-2303 H Chip.

The chip not running is a Pl-2303 XA / HXA.
Exact type is Pl-2303HX LF12313A or LF13313A

Both are identified as ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port

When you connect the adapter everything looks fine.
It is recognized and attached as ttyUSB0.
But the PL-2303HX does not receive data!

Sometimes you get only some bytes directly after connection of the serial 
device and then nothing.
I checked the input of the chip, the signal is clear and perfect.
It is the same result with 2 different adapter of the same type.

The sending of data is no problem, that's working.

Maybe you can refer also to this reported problems:
http://ubuntuforums.org/showthread.php?t=1580150
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/661321

Regards
Karsten


-- Package-specific info:
** Version:
Linux version 3.2.0-3-amd64 (Debian 3.2.23-1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-8) ) #1 
SMP Mon Jul 23 02:4$


** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-3-amd64 
root=UUID=5c902625-e63e-446f-a5c5-c24a1176dec7 ro quiet

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[ 3497.136623] usb 1-2.3: new full-speed USB device number 14 using ehci_hcd
[ 3497.245697] usb 1-2.3: New USB device found, idVendor=067b, idProduct=2303
[ 3497.245708] usb 1-2.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[ 3497.245716] usb 1-2.3: Product: USB-Serial Controller
[ 3497.245721] usb 1-2.3: Manufacturer: Prolific Technology Inc.
[ 3497.246184] pl2303 1-2.3:1.0: pl2303 converter detected
[ 3497.247748] usb 1-2.3: pl2303 converter now attached to

** Model information
sys_vendor: To Be Filled By O.E.M.
product_name: To Be Filled By O.E.M.
product_version: To Be Filled By O.E.M.
chassis_vendor: To Be Filled By O.E.M.
chassis_version: To Be Filled By O.E.M.
bios_vendor: American Megatrends Inc.
bios_version: P1.10
board_vendor: ASRock
board_name: M3A770DE
board_version:

** Loaded modules:
pl2303
pci_stub
vboxpci(O)
vboxnetadp(O)
vboxnetflt(O)
ppdev
lp
vboxdrv(O)
snd_hrtimer
cpufreq_powersave
cpufreq_userspace
cpufreq_conservative
cpufreq_stats
fuse
ext3
jbd
w83627ehf
hwmon_vid
loop
snd_hda_codec_hdmi
nvidia(P)
usb_storage
uas
ch341
snd_hda_codec_via
usbserial
snd_hda_intel
snd_hda_codec
snd_seq_midi
snd_hwdep
snd_seq_midi_event
snd_pcm_oss
snd_rawmidi
snd_mixer_oss
snd_pcm
snd_seq
snd_page_alloc
sp5100_tco
k10temp
parport_pc
i2c_piix4
snd_seq_device
psmouse
snd_timer
parport
powernow_k8
snd
pcspkr
serio_raw
evdev
mperf
soundcore
i2c_core
edac_mce_amd
wmi
edac_core
processor
button
thermal_sys
ext4
crc16
jbd2
mbcache
microcode
usbhid
hid
sg
sr_mod
sd_mod
cdrom
crc_t10dif
ata_generic
ohci_hcd
pata_atiixp
floppy
ahci
libahci
ehci_hcd
r8169
libata
mii
usbcore
scsi_mod
usb_common


** PCI devices:
00:12.2 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396] 
(prog-if 20 [EHCI])

Subsystem: ASRock Incorporation Device [1849:4396]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Region 0: Memory at fceff000 (32-bit, non-prefetchable) [size=256]
Capabilities: access denied
Kernel driver in use: ehci_hcd

00:13.0 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0/SB8x0/SB9x0 USB OHCI0 Controller [1002:4397] 
(prog-if 10 [OHCI])

Subsystem: ASRock Incorporation Device [1849:4397]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at fcefc000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci_hcd

00:13.1 USB controller [0c03]: Advanced Micro Devices [AMD] nee ATI SB7x0 USB OHCI1 Controller [1002:4398] (prog-if 10 
[OHCI])

Subsystem: ASRock Incorporation Device [1849:4398]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 32, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory

Bug#689025: Most probably a rsyslog configuration problem

2013-03-05 Thread Karsten Heymann
Hi,

this may be not an openldap, but a rsyslog configuration problem. We
experienced this problem as well with other services (mainly mail
servers) logging to rsyslog via tcp syslog when the remote loghost was
not responding. To the bug reporter: Have you configured a (disk,
memory or combined) queue in rsyslog? As described in
http://www.rsyslog.com/doc/queues.html, this is the recommended setup
to deal with such outages. If no, this bug can probably be closed.

Best
Karsten


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#701153: llvm-dev: LLVM/Clang packages in Wheezy Beta4 are missing files

2013-02-21 Thread Karsten Loesing
Package: llvm-dev
Severity: normal

I'm having issues with the LLVM/Clang packages in Debian Wheezy Beta4.  It
seems these packages are missing files that I can only obtain when building
LLVM/Clang myself.  I'd rather use Debian's packages, and so I am wondering if
these files can be included in either an existing or a new dev package.

The files I am referring to are the LLVM cmake modules -  applications that
build custom LLVM passes require the LLVM cmake modules during the build
process.

For llvm-3.2, the files I'm referring to exist in:
llvm-3.2.src/cmake/modules/*.cmake

And after building LLVM/Cmake like this:
wget http://llvm.org/releases/3.2/llvm-3.2.src.tar.gz
wget http://llvm.org/releases/3.2/clang-3.2.src.tar.gz
tar xaf llvm-3.2.src.tar.gz
tar xaf clang-3.2.src.tar.gz
cp -R clang-3.2.src llvm-3.2.src/tools/clang
cd llvm-3.2.src/
mkdir build
cd build/
cmake -DCMAKE_INSTALL_PREFIX=/home/karsten/.local ../.
make
make install

the files are then installed to:
/home/karsten/.local/share/llvm/cmake/*.cmake

Neither the llvm or llvm-dev packages contain these files. Is there an existing
package that I am missing that contains these files? Otherwise, does it make
sense to include these files in the llvm-dev package?



-- System Information:
Debian Release: 6.0.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#686376: ginkgocadx: this is a non-issue

2013-01-27 Thread Karsten Hilbert
Package: ginkgocadx
Followup-For: Bug #686376

This is a non-issue.

When Ginkgo-CADx is started it will show a start page in the right
hand side (if so configured - and that's the default). On the right hand
side, normally images are displayed in tabs. Ginkgo-CADx does not close
as long as an image is open on the right hand side. In this case the
start page.

Yes, this is unfortunate programming (especially since there's no
feedback) but, no, it is NOT a bug.

Please close this report unless the original poster shows instructions
to replicate the reported behaviour independant of the above explanation.

Karsten


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 
'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ginkgocadx depends on:
ii  libatk1.0-0   2.4.0-2
ii  libc6 2.13-37
ii  libcairo2 1.12.2-2
ii  libdcmtk2 3.6.0-12
ii  libfftw3-33.3.2-3.1
ii  libfreetype6  2.4.9-1.1
ii  libgcc1   1:4.7.2-5
ii  libgdcm2.22.2.0-13
ii  libgdk-pixbuf2.0-02.26.1-1
ii  libgl1-mesa-glx [libgl1]  8.0.5-3
ii  libglib2.0-0  2.33.12+really2.32.4-3
ii  libgtk2.0-0   2.24.10-2
ii  libinsighttoolkit3.20 3.20.1+git20120521-3
ii  libpango1.0-0 1.30.0-1
ii  libpng12-01.2.49-1
ii  libsqlite3-0  3.7.13-1
ii  libssl1.0.0   1.0.1c-4
ii  libstdc++64.7.2-5
ii  libtiff5  4.0.2-5
ii  libvtk5.8 5.8.0-13+b1
ii  libwrap0  7.6.q-24
ii  libwxbase2.8-02.8.12.1-12
ii  libwxgtk2.8-0 2.8.12.1-12
ii  libxml2   2.8.0+dfsg1-7
ii  zlib1g1:1.2.7.dfsg-13

ginkgocadx recommends no packages.

ginkgocadx suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#688952: ginkgocadx: seems resolved

2013-01-27 Thread Karsten Hilbert
Package: ginkgocadx
Version: 2.12.0.4889-1
Followup-For: Bug #688952

This problem seems resolved with the upstream release 3.1.0. Citing from
their README:


Ginkgo CADx Project Changelog
www.ginkgo-cadx.com

Version 3.1.0 (2012-12-12)
---
...
* wrong LGPL3 aditional clause removed


Please close this bug if you agree.

Thanks,
Karsten

-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 
'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ginkgocadx depends on:
ii  libatk1.0-0   2.4.0-2
ii  libc6 2.13-37
ii  libcairo2 1.12.2-2
ii  libdcmtk2 3.6.0-12
ii  libfftw3-33.3.2-3.1
ii  libfreetype6  2.4.9-1.1
ii  libgcc1   1:4.7.2-5
ii  libgdcm2.22.2.0-13
ii  libgdk-pixbuf2.0-02.26.1-1
ii  libgl1-mesa-glx [libgl1]  8.0.5-3
ii  libglib2.0-0  2.33.12+really2.32.4-3
ii  libgtk2.0-0   2.24.10-2
ii  libinsighttoolkit3.20 3.20.1+git20120521-3
ii  libpango1.0-0 1.30.0-1
ii  libpng12-01.2.49-1
ii  libsqlite3-0  3.7.13-1
ii  libssl1.0.0   1.0.1c-4
ii  libstdc++64.7.2-5
ii  libtiff5  4.0.2-5
ii  libvtk5.8 5.8.0-13+b1
ii  libwrap0  7.6.q-24
ii  libwxbase2.8-02.8.12.1-12
ii  libwxgtk2.8-0 2.8.12.1-12
ii  libxml2   2.8.0+dfsg1-7
ii  zlib1g1:1.2.7.dfsg-13

ginkgocadx recommends no packages.

ginkgocadx suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#686376: ginkgocadx: this is a non-issue

2013-01-27 Thread Karsten Hilbert
Sorry this should have been attached to

#684990

Please re-assign.

Thanks,
Karsten

On Sun, Jan 27, 2013 at 01:36:48PM +0100, Karsten Hilbert wrote:

 Package: ginkgocadx
 Followup-For: Bug #686376
 
 This is a non-issue.
 
 When Ginkgo-CADx is started it will show a start page in the right
 hand side (if so configured - and that's the default). On the right hand
 side, normally images are displayed in tabs. Ginkgo-CADx does not close
 as long as an image is open on the right hand side. In this case the
 start page.
 
 Yes, this is unfortunate programming (especially since there's no
 feedback) but, no, it is NOT a bug.
 
 Please close this report unless the original poster shows instructions
 to replicate the reported behaviour independant of the above explanation.
 
 Karsten

-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#686376: ginkgocadx: Upstream 3.1.0 available

2013-01-27 Thread Karsten Hilbert
Package: ginkgocadx
Version: 2.12.0.4889-1
Followup-For: Bug #686376

Upstream has release 3.1.0. This - among fixing bugs - resolves the
inaccurate licensing.

Uploading to experimental would be beneficial to users as they can use
this version even before Testing becomes stable (it runs just fine on
Testing AFAICT).

Please package as time permits.

Thanks,
Karsten


-- System Information:
Debian Release: 7.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 
'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages ginkgocadx depends on:
ii  libatk1.0-0   2.4.0-2
ii  libc6 2.13-37
ii  libcairo2 1.12.2-2
ii  libdcmtk2 3.6.0-12
ii  libfftw3-33.3.2-3.1
ii  libfreetype6  2.4.9-1.1
ii  libgcc1   1:4.7.2-5
ii  libgdcm2.22.2.0-13
ii  libgdk-pixbuf2.0-02.26.1-1
ii  libgl1-mesa-glx [libgl1]  8.0.5-3
ii  libglib2.0-0  2.33.12+really2.32.4-3
ii  libgtk2.0-0   2.24.10-2
ii  libinsighttoolkit3.20 3.20.1+git20120521-3
ii  libpango1.0-0 1.30.0-1
ii  libpng12-01.2.49-1
ii  libsqlite3-0  3.7.13-1
ii  libssl1.0.0   1.0.1c-4
ii  libstdc++64.7.2-5
ii  libtiff5  4.0.2-5
ii  libvtk5.8 5.8.0-13+b1
ii  libwrap0  7.6.q-24
ii  libwxbase2.8-02.8.12.1-12
ii  libwxgtk2.8-0 2.8.12.1-12
ii  libxml2   2.8.0+dfsg1-7
ii  zlib1g1:1.2.7.dfsg-13

ginkgocadx recommends no packages.

ginkgocadx suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#640851: evolution: local mail files no longer accessible

2013-01-11 Thread Karsten Voss
Because of this bug i updated to 3.6.1-1 from experimental - it didn't
help. 

Regards 
Karsten 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#691560: IvyBridge: Gnome in fallback mode

2013-01-09 Thread Karsten Voss
On Tue, 2013-01-08 at 18:32 +0100, Julien Cristau wrote:
 Oh also can you upgrade libdrm-intel1 to 2.4.40, see if that makes any
 difference.
 
This forced me to update libdrm2 too. Installed the versions form
unstable (2.4.40-1~deb7u2 respectively)
Now i works great. 

Thank You! 
Karsten 




signature.asc
Description: This is a digitally signed message part


Bug#691560: IvyBridge: Gnome in fallback mode

2013-01-08 Thread Karsten Voss
The same problem with kernel 3.7.1-1~experimental.2 and driver
2:2.20.14-1 from experimental. 

There are less distortions on the screen than before, but changing VT
does not work. 


[12.906] 
X.Org X Server 1.12.4
Release Date: 2012-08-27
[12.906] X Protocol Version 11, Revision 0
[12.906] Build Operating System: Linux 3.2.0-4.drm-amd64 x86_64 Debian
[12.906] Current Operating System: Linux schnattchen 3.7-trunk-amd64 #1 SMP Debian 3.7.1-1~experimental.2 x86_64
[12.906] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7-trunk-amd64 root=UUID=b40b1a73-1fc8-4fde-990a-cf74eed016e3 ro quiet
[12.906] Build Date: 29 November 2012  07:18:16PM
[12.906] xorg-server 2:1.12.4-4 (Julien Cristau jcris...@debian.org) 
[12.906] Current version of pixman: 0.26.0
[12.906] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[12.906] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[12.906] (==) Log file: /var/log/Xorg.1.log, Time: Tue Jan  8 17:07:20 2013
[12.906] (==) Using system config directory /usr/share/X11/xorg.conf.d
[12.907] (==) No Layout section.  Using the first Screen section.
[12.907] (==) No screen section available. Using defaults.
[12.907] (**) |--Screen Default Screen Section (0)
[12.907] (**) |   |--Monitor default monitor
[12.907] (==) No monitor specified for screen Default Screen Section.
	Using a default monitor configuration.
[12.907] (==) Automatically adding devices
[12.907] (==) Automatically enabling devices
[12.907] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
[12.907] 	Entry deleted from font path.
[12.907] (WW) The directory /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType does not exist.
[12.907] 	Entry deleted from font path.
[12.907] (==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins
[12.907] (==) ModulePath set to /usr/lib/xorg/modules
[12.907] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[12.907] (II) Loader magic: 0x7f02045c3ae0
[12.907] (II) Module ABI versions:
[12.907] 	X.Org ANSI C Emulation: 0.4
[12.907] 	X.Org Video Driver: 12.1
[12.907] 	X.Org XInput driver : 16.0
[12.907] 	X.Org Server Extension : 6.0
[12.907] (--) PCI:*(0:0:2:0) 8086:016a:8086:201c rev 9, Mem @ 0xfdc0/4194304, 0xe000/268435456, I/O @ 0xf000/64
[12.907] (II) Open ACPI successful (/var/run/acpid.socket)
[12.907] (II) LoadModule: extmod
[12.908] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[12.908] (II) Module extmod: vendor=X.Org Foundation
[12.908] 	compiled for 1.12.4, module version = 1.0.0
[12.908] 	Module class: X.Org Server Extension
[12.908] 	ABI class: X.Org Server Extension, version 6.0
[12.908] (II) Loading extension SELinux
[12.908] (II) Loading extension MIT-SCREEN-SAVER
[12.908] (II) Loading extension XFree86-VidModeExtension
[12.908] (II) Loading extension XFree86-DGA
[12.908] (II) Loading extension DPMS
[12.908] (II) Loading extension XVideo
[12.908] (II) Loading extension XVideo-MotionCompensation
[12.908] (II) Loading extension X-Resource
[12.908] (II) LoadModule: dbe
[12.908] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so
[12.908] (II) Module dbe: vendor=X.Org Foundation
[12.908] 	compiled for 1.12.4, module version = 1.0.0
[12.908] 	Module class: X.Org Server Extension
[12.908] 	ABI class: X.Org Server Extension, version 6.0
[12.908] (II) Loading extension DOUBLE-BUFFER
[12.908] (II) LoadModule: glx
[12.908] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[12.908] (II) Module glx: vendor=X.Org Foundation
[12.908] 	compiled for 1.12.4, module version = 1.0.0
[12.908] 	ABI class: X.Org Server Extension, version 6.0
[12.908] (==) AIGLX enabled
[12.908] (II) Loading extension GLX
[12.908] (II) LoadModule: record
[12.908] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so
[12.908] (II) Module record: vendor=X.Org Foundation
[12.908] 	compiled for 1.12.4, module version = 1.13.0
[12.908] 	Module class: X.Org Server Extension
[12.908] 	ABI class: X.Org Server Extension, version 6.0
[12.908] (II) Loading extension RECORD
[12.908] (II) LoadModule: dri
[12.908] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so
[12.908] (II) Module dri: vendor=X.Org Foundation
[12.908] 	compiled for 1.12.4, module version = 1.0.0
[12.908] 	ABI class: X.Org Server Extension, version 6.0
[12.908] 

Bug#695762: python-psycopg2: new 2.4.6 bug-fix only upstream release available

2012-12-12 Thread Karsten Hilbert
Package: python-psycopg2
Version: 2.4.5-1
Severity: wishlist
Tags: upstream

Upstream has released 2.4.6 which is declared bug-fix only.

Here's the release announcement:

http://web.archiveorange.com/archive/v/ZbQiGLotb3e3b7Ph1N3i

Thanks a lot,
Karsten

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 
'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages python-psycopg2 depends on:
ii  libc6  2.13-37
ii  libpq5 9.1.6-1
ii  python 2.7.3~rc2-1
ii  python2.7  2.7.3~rc2-2.1

Versions of packages python-psycopg2 recommends:
ii  python-egenix-mxdatetime  3.2.1-1.1

Versions of packages python-psycopg2 suggests:
pn  python-psycopg2-doc  none

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#693620: [Pkg-opt-media-team] Bug#693620: dvdisaster does not start

2012-11-20 Thread Karsten Malcher

Hi Carsten,

Am 19.11.2012 20:13, schrieb Carsten Gnörlich:


Rogério already summed it up perfectly. Just to add some more
technical info: It's not too uncommon to see a drive freeze in midst
of fulfilling a SCSI request on faulty media due to bugs in its firmware. While this may freeze the calling 
application and maybe

even the whole system if one was unlucky enough to have the root
file system on the same SCSI subsystem, remedy is usually possible by
a) pushing eject on the drive, which is totally unspecified and
unexpected behaviour, but may actually reset the drive and abort
the stuck SCSI command; or by


In my case this does not help.


b) simply waiting for the SCSI timeout specified by the application.
When the timeout is reached, the kernel will abort and unlock the
failed command, and the system will come back to life again.


I would say i have waited for about 5 minutes.
Before i shutdown the system i tested if the processes still exists.
None of the processes did disappear.



On dvdisaster the timeout is 10min. While this might seem a high value,
please resist the temptation to fiddle with it.


O.K.


In Karstens case, the drive was probably already stuck before calling 
dvdisaster.


Yes - of course - the first thing i tried was just to read the CD.
But the CD was so bad that it was not recognized.
It was my second idea to use dvdisaster to check the CD.

I tested the CD on 3 different drives and i could read it only on the 4th drive.
Yesterday it was possible to read the file on the first drive, that's really 
interesting.


Since dvdisaster queries all connected drives for some
of their properties while preparing its main window, it hung up right
off the box. In command line mode, the failure would probably have been
deferred until the first read operation. But anyways, these are really
firmware bugs which can only be corrected by the drive manufacturer,
and neither the kernel nor dvdisaster can work around them in a meaningful way.


It's very simple why i rise this bug.
I give up to use CD's and DVD's, because they are more expensive and reliable 
than hard disks.
The other thing is that my DVD-burner GH22NP20 has give up to write after only 
a few DVD's in 2 years.

So the last time i use dvdisaster was on debian squeeze.
I assumed that it was not working any more after my upgrade to wheezy.
That's all.



Greetings,
  Carsten



Thank you all for your advise.

Cheers
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#693620: Fwd: dvdisaster does not start

2012-11-19 Thread Karsten Malcher

Hi Michael,

i could not believe it, but today the application is running without problems.
Seems not to run on sundays. :-)

Yesterday i inserted a CD that is nearly impossible to read.
Maybe the device was somehow blocked after this, so that the program did not 
start.
Today i can't reproduce this.

So please close the bug.

Best regards
Karsten


Am 18.11.2012 23:33, schrieb Michael Gilbert:

Hi, I've just tested this, and it works fine for me.  Could you post a
debugging backtrace and an strace?

$ gdb dvdisaster
run
backtrace


karsten@PC:/tmp$ gdb dvdisaster
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/dvdisaster...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/dvdisaster
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.

backtrace[Inferior 1 (process 4945) exited normally]
(gdb)
(gdb) backtrace
No stack.




$ strace dvdisaster

Thanks,
Mike


execve(/usr/bin/dvdisaster, [dvdisaster], [/* 39 vars */]) = 0
brk(0)  = 0x1b53000
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f1a54169000
access(/etc/ld.so.preload, R_OK)  = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY)  = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=154236, ...}) = 0
mmap(NULL, 154236, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f1a54143000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0@\7\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=6120, ...}) = 0
mmap(NULL, 2101288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f1a53d4a000
mprotect(0x7f1a53d4b000, 2093056, PROT_NONE) = 0
mmap(0x7f1a53f4a000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0) = 0x7f1a53f4a000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/lib/x86_64-linux-gnu/librt.so.1, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\220!\0\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=31744, ...}) = 0
mmap(NULL, 2128856, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f1a53b42000
mprotect(0x7f1a53b49000, 2093056, PROT_NONE) = 0
mmap(0x7f1a53d48000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f1a53d48000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK)  = -1 ENOENT (No such file or directory)
open(/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0, O_RDONLY) = 3
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\0\200;\7\0\0\0\0\0..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=4442248, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f1a54142000
mmap(NULL, 6546664, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f1a53503000
mprotect(0x7f1a53935000, 2097152, PROT_NONE) = 0
mmap(0x7f1a53b35000, 45056, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x432000) = 0x7f1a53b35000
mmap(0x7f1a53b4, 5352, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f1a53b4
close(3)= 0


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#693620: [Pkg-opt-media-team] Bug#693620: dvdisaster does not start

2012-11-19 Thread Karsten Malcher

Hi,

Am 19.11.2012 01:03, schrieb Rogério Brito:

Hi.

On Nov 18 2012, Karsten Malcher wrote:

i just tried to use dvdisaster - without success.
The application just hangs and does not start.
Every process i started could not be killed manually with kill -9 !

If a given process doesn't get killed even with signal 9, then it is
probably the case that the process is in the D state and the kernel is
waiting for some device (or IO) to fulfill a request.


In this case this must have happen.



Are you trying to create the image of a badly scratched CD/DVD?


Yes - but this CD was nearly fresh burned without any visible defects.


  What if you
do the same operations without dvdisaster? Say, what if you create the image
with ddrescue? Do you still get uninterruptible processes?


For one time i was able to read the CD.
There is only one file with 20 MB on it.
It seems to be pure accident when this problem happens.



Unfortunately, I can't reproduce this myself and I see that Michael has
already tagged this as unreproducible and moreinfo, which is certainly
appropriate here, as we have too few details to continue debugging.


Regards,



Yes - this is only one of this crazy one-time-bugs.

Regards
Karsten


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#693620: dvdisaster does not start

2012-11-18 Thread Karsten Malcher

Package: dvdisaster
Version: 0.72.4-1
Justification: renders package unusable
Severity: grave

Hello,

i just tried to use dvdisaster - without success.
The application just hangs and does not start.
Every process i started could not be killed manually with kill -9 !

Best regards
Karsten


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dvdisaster depends on:
ii  libatk1.0-0 2.4.0-2
ii  libc6   2.13-35
ii  libcairo2   1.12.2-2
ii  libfontconfig1  2.9.0-7
ii  libfreetype62.4.9-1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.32.3-1
ii  libgtk2.0-0 2.24.10-2
ii  libpango1.0-0   1.30.0-1
ii  xdg-utils   1.1.0~rc1+git20111210-6

Versions of packages dvdisaster recommends:
ii  dvdisaster-doc  0.72.4-1

dvdisaster suggests no packages.

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#692957: linux-image-3.2.0-4-amd64: NFS server causes high load on 3.2 kernel

2012-11-11 Thread Karsten Suehring
Package: src:linux
Version: 3.2.32-1
Severity: important

I originally niticed the issue on Ubuntu 12.04.1, but could reproduce it on
Debian as well.

I upgraded a squeeze system to testing and found that NFS access 
creates a high load on the NFS server. A single client machine with 
a single write causes 40% system load, where the original load on Squeeze
was 7-10% (which still is high, but might be causes by running in a test VM).

My Ubuntu production server got completely killed by several clients 
accessing.

Steps to reproduce: 
Server:
- install vanilla Squeeze server system without Graphical UI and standard 
  settings otherwise
- install nfs-kernel-server
- add to exports:
  /export   client(rw,no_root_squash,async,subtree_check)
- exportfs -a

Client:
- same installation, install nfs-common
- mount with
  mount -t nfs server:/export /mnt
- go to /mnt and write a file with
  dd if=/dev/zero of /mnt/t1 bs=1M count=1
- measure the load on the server while writing

- upgrade the server to Wheezy
- do the same writing test and see the load go up

If I boot Wheezy to the still installed 2.6 kernel, the load goes back to 
normal.

I have played around with different nfs export and mount options. The only 
change that I found was using -o proto=uds when mounting. This reduces the
load to 15% which is still higher than the original load, but still much lower
that 40%.

Ubuntu Bug #879334 and it's duplicates report the same issues.

-- Package-specific info:
** Version:
Linux version 3.2.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 4.6.3 
(Debian 4.6.3-12) ) #1 SMP Debian 3.2.32-1

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 
root=UUID=0f95e4ef-e796-41b1-9e14-8878428a61a4 ro quiet

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[1.312867] Switching to clocksource tsc
[1.461471] e1000 :00:03.0: eth0: (PCI:33MHz:32-bit) 08:00:27:f2:11:56
[1.461481] e1000 :00:03.0: eth0: Intel(R) PRO/1000 Network Connection
[1.461562] ohci_hcd :00:06.0: setting latency timer to 64
[1.461574] ohci_hcd :00:06.0: OHCI Host Controller
[1.461590] ohci_hcd :00:06.0: new USB bus registered, assigned bus 
number 1
[1.461649] ohci_hcd :00:06.0: irq 22, io mem 0xf0804000
[1.517407] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
[1.517410] usb usb1: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[1.517412] usb usb1: Product: OHCI Host Controller
[1.517414] usb usb1: Manufacturer: Linux 3.2.0-4-amd64 ohci_hcd
[1.517415] usb usb1: SerialNumber: :00:06.0
[1.517499] hub 1-0:1.0: USB hub found
[1.517511] hub 1-0:1.0: 8 ports detected
[1.517926] ahci :00:0d.0: version 3.0
[1.518083] ahci: SSS flag set, parallel bus scan disabled
[1.518247] ahci :00:0d.0: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 
impl SATA mode
[1.518251] ahci :00:0d.0: flags: 64bit ncq stag only ccc 
[1.518273] ahci :00:0d.0: setting latency timer to 64
[1.519072] scsi0 : ahci
[1.519140] ata1: SATA max UDMA/133 abar m8192@0xf0806000 port 0xf0806100 
irq 21
[1.519212] ata_piix :00:01.1: version 2.13
[1.519276] ata_piix :00:01.1: setting latency timer to 64
[1.520413] scsi1 : ata_piix
[1.520588] scsi2 : ata_piix
[1.520627] ata2: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0xd000 irq 14
[1.520630] ata3: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0xd008 irq 15
[1.676448] ata3.00: ATAPI: VBOX CD-ROM, 1.0, max UDMA/133
[1.676901] ata3.00: configured for UDMA/33
[1.840110] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[1.840185] ata1.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133
[1.840188] ata1.00: 32118784 sectors, multi 128: LBA48 NCQ (depth 31/32)
[1.840284] ata1.00: configured for UDMA/133
[1.840360] scsi 0:0:0:0: Direct-Access ATA  VBOX HARDDISK1.0  
PQ: 0 ANSI: 5
[1.840852] scsi 2:0:0:0: CD-ROMVBOX CD-ROM   1.0  
PQ: 0 ANSI: 5
[1.846811] sd 0:0:0:0: [sda] 32118784 512-byte logical blocks: (16.4 
GB/15.3 GiB)
[1.846844] sd 0:0:0:0: [sda] Write Protect is off
[1.846846] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[1.846860] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[1.847914]  sda: sda1 sda2  sda5 
[1.848330] sd 0:0:0:0: [sda] Attached SCSI disk
[1.848710] sr0: scsi3-mmc drive: 32x/32x xa/form2 tray
[1.848712] cdrom: Uniform CD-ROM driver Revision: 3.20
[1.848949] sr 2:0:0:0: Attached scsi CD-ROM sr0
[1.853273] sd 0:0:0:0: Attached scsi generic sg0 type 0
[1.853324] sr 2:0:0:0: Attached scsi generic sg1 type 5
[1.924105] usb 1-1: new full-speed USB device number 2 using ohci_hcd
[1.961261] PM: Starting manual resume from disk
[1.961264] PM: Hibernation image partition 8:5 present
[1.961265] PM: Looking for hibernation image.
[1.961490] PM: Image not found 

Bug#692957: Typo

2012-11-11 Thread Karsten Suehring
Sorry, I had a typo. It should have read:

The only change that I found was using -o proto=udp when mounting .

(instead of tcp which seems to be the default)


Bug#692957: linux-image-3.2.0-4-amd64: NFS server causes high load on 3.2 kernel

2012-11-11 Thread Karsten Suehring
 Is that with TCP or UDP?


Made a simple mount without specifying any options. So I guess the default
would be TCP because specifying UDP made a difference in previous tests,
right?

--Karsten


Bug#692957: linux-image-3.2.0-4-amd64: NFS server causes high load on 3.2 kernel

2012-11-11 Thread Karsten Suehring
 Can you also measure the speed at which the client can write, when the
 server is running each of the two kernel versions?  If the client can
 write twice as fast (for example) then it should be OK to use twice as
 high a percentage of CPU time on the server, as the total CPU time
 needed for a data transfer will be the same.


I tested the following combinations with 2 GB writes:

Server   Client
Debian testing kernel 2.6Debian stable ~60 seconds
Debian testing kernel 3.2Debian stable ~60 seconds

Debian testing kernel 2.6Ubuntu 12.04.1  ~65 seconds
Debian testing kernel 3.2Ubuntu 12.04.1  ~67 seconds

It seems the speed is comparable in all cases although the load differs. In
general my load number looked a bit smaller this time, maybe because the
host system was freshly booted. So I guess, I should collect some numbers
on an actual machine tomorrow. I also did not have a Debian testing client
yet.

Do you know if the patch mentioned above also affect the client?

--Karsten


Bug#691560: IvyBridge: Gnome in fallback mode

2012-11-04 Thread Karsten Voss
On Sun, 2012-11-04 at 00:59 +0100, Julien Cristau wrote:
 On Sun, Oct 28, 2012 at 13:52:45 +0100, Karsten Voss wrote:
 
  updated xserver-xorg-video-intel to version 2:2.20.5-1 from
  experimental, and kernel to 3.2.32-1 from unstable, but the same
  experience. 
  Karsten 
  
  # dmesg 
  ...
  [  346.203441] [drm:i915_init] *ERROR* drm/i915 can't work without
  intel_agp module!
  
 Looks like you need a newer kernel.
 
I have already tested with kernels 3.5 and 3.6 form experimental, but
with these kernels X is absolutely unusable. X uses then fbdev driver.
Screen does not refresh, up to 3 mouse cursors, switching to a different
virtual console does not work...

Karsten 




signature.asc
Description: This is a digitally signed message part


<    1   2   3   4   5   6   7   8   9   10   >