Bug#854866: Confirmation

[Maik Zumstrull]

Hi Stephen,

It seems the original submitter lost interest, but I can confirm that
this happens. Not sure this is the only problem, but
/lib/udev/rules.d/60-solaar.rules only has a limited set of device
IDs:

ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52b", GOTO="solaar_apply"
ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c532", GOTO="solaar_apply"
ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c52f", GOTO="solaar_apply"
ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c526", GOTO="solaar_apply"

That doesn't match mine:
Bus 003 Device 002: ID 046d:c539 Logitech, Inc. USB Receiver

But solaar does recognize and use it if run as root.

Upstream has a much longer list:
https://github.com/pwr-Solaar/Solaar/blob/master/rules.d/42-logitech-unify-permissions.rules

But Debian has the latest upstream release, so I'm not sure why this
hasn't made it into the package. Probably a minor bug in the build
process.


Thanks for maintaining the package

Maik

Bug#906958: needrestart: Complains when the microcode is newer than what Debian has

[Maik Zumstrull]

Package: needrestart
Version: 3.3-1

On this box, needrestart gives this message:

The currently running processor microcode revision is 0x20 which is
not the expected microcode revision 0x1f.

Unless I'm misunderstanding the versioning scheme, this release is
newer than what intel-microcode 3.20180703.2 ships. It's uploaded to
the CPU pre-boot thanks to a mainboard firmware update.

The check should probably be adjusted to warn about versions smaller
than what's available from the OS, not just different.

Bug#884784: systemd-network segfaults

[Maik Zumstrull]

On Sat, Mar 17, 2018 at 3:20 AM, Michael Biebl  wrote:
> On Tue, 19 Dec 2017 19:50:49 +0200 =?utf-8?q?R=C3=A9mi_Denis-Courmont?=

>> systemd-networkd from version 236-1 systematically segfaults at start-up.
>
> Could you test with v238 please and report back with your results.

My system was affected by the routing rule segfault on 236 but works
with 238. 237 already worked as well. I think it's safe to say
upstream has fixed it.

Bug#849963: tigervnc-standalone-server: Syntax error in /usr/bin/tigervncserver

[Maik Zumstrull]

Package: tigervnc-standalone-server
Version: 1.7.0-2
Severity: normal


In line 705, in the code path for the -fg option, the script does:

system $cmd[0] (@cmd);

This will lead to a "Can't use string as a subroutine ref" error with
current Perl releases. The correct syntax is

system { $cmd[0] } (@cmd);

or

system { $cmd[0] } @cmd;

The final parentheses are optional but not harmful. The braces are very
not optional. In defense of the author, the Perl documentation for
"system" doesn't indicate this at all; it's in the documentation for the
related "exec" function.

Bug#831390: static global variables are not thread safe

[Maik Zumstrull]

On 15 Jul 2016, at 15:49, Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
> 
> On Fri 2016-07-15 14:19:51 +0200, Maik Zumstrull wrote:

>> As a quick fix, I suggest declaring these variables thread-local:
>> 
>> static __thread FILE *groupsfile = NULL;
>> static __thread FILE *shadowfile = NULL;
>> static __thread FILE *usersfile = NULL;
>> 
>> It's not necessarily the most elegant solution, but it should make the code 
>> fully reentrant.
> 
> Are you sure this wouldn't cause the different thread's understanding of
> the underlying file descriptors to get out of sync?  declaring them
> thread-local wouldn't prevent them sharing the same file descriptor,
> right?

It should. The semantics are that every thread "sees" its own version of that 
pointer, so if thread A opens the file, thread B, C, D, etc will still have 
NULL in their version of the variable and will do groupsfile = 
fopen(GROUPSFILE, "r"); which should create a new FILE structure and open a new 
file descriptor, whether any other thread has the file open or not.

That's why I called the solution inelegant - it's not efficient to open the 
file seven times if seven threads want something - but it should be safe 
because nothing is shared between threads.

> This seems like a way to cause some even more subtle bug, for example:
> 
> thread A causes libnss-extrausers to scan the groups file for some
>value, and it reads up to block X, while
> thread B causes libnss-extrausers to scan the groups file for some
>other value, and it reads up to block Y
> 
> then thread A resumes; the underlying file descriptor is advanced to
> position Y but the FILE* buffers in thread A have only cached enough
> data to represent block X.  what happens then?

That's the situation we have now, because everything from the FILE pointer to 
the FILE struct down to the file descriptor is currently shared.

Bug#831390: static global variables are not thread safe

[Maik Zumstrull]

Package: libnss-extrausers
Version: 0.6-3

The implementation uses three static global pointer variables:

static FILE *groupsfile = NULL;
static FILE *shadowfile = NULL;
static FILE *usersfile = NULL;

Since these are used without locks or atomic operations, this is not 
thread-safe, even though NSS functions are supposed to be reentrant. This is 
leading to occasional "double free or corruption" crashes in libvirtd for us, 
specifically in fclose(groupsfile); in _nss_extrausers_endgrent.

As a quick fix, I suggest declaring these variables thread-local:

static __thread FILE *groupsfile = NULL;
static __thread FILE *shadowfile = NULL;
static __thread FILE *usersfile = NULL;

It's not necessarily the most elegant solution, but it should make the code 
fully reentrant.

Bug#823530: systemd 228 reduced maximum number of tasks in a cgroup to 512 by default

[Maik Zumstrull]

On Sat, May 7, 2016 at 1:25 PM, Santiago Vila  wrote:

> I'm using a hand-made autobuilder which is triggered by cron, asks a
> server for a package to build and uses sbuild to build the package.
> Should I override this for the cron service only?

cron probably shouldn't be running the actual jobs in its own service
scope, applying its own process limits to the jobs.

As long as cron does, you can try adding
https://www.freedesktop.org/software/systemd/man/systemd-run.html to
your job invocation, as in
systemd-run --scope -p TasksMax=infinity your-original-command --your
--original --args

Bug#823530: In favor of keeping the limit

[Maik Zumstrull]

In my opinion, the bugs here are in different packages:

- Packages that provide a way for users to log in to the system, but
don't create a user slice
- Packages that provide services that operate using an unreasonable
number of processes or threads, and can't be bothered to declare as
much in the unit file

The 512 limit is arbitrary, but a plausible point at which to say, if
this isn't an interactive session and the service has not declared
special needs, I should assume it's malfunctioning / fork bombing and
shut it down.

For comparison, RabbitMQ installations also regularly run into the
"1024 open file descriptors" limit, but instead of abolishing that
limit globally, it's been documented that the limit may need to be
raised specifically for RabbitMQ for high-load installations.

Regarding the user slice thing, maybe systemd should consider
depending on libpam-systemd. It's currently quite easy to not install
on custom installations, and not having user slices should break a
number of things. (It's pulled in by ubuntu-standard on Ubuntu, but
people like to remove that because it pulls in things of questionable
usefulness.)

Bug#822341: steam:i386: steam-devices package was not built

[Maik Zumstrull]

Package: steam
Version: 1.0.0.52-1
Severity: normal

With the last upload (1.0.0.51-1), you added a steam-devices package
that installs udev rules for some Valve hardware like the Steam
Controller. It appears with the current version, this package was not
built or at least didn't end up in the archive:

http://ftp.debian.org/debian/pool/non-free/s/steam/

I'm not sure what went wrong, as I still see steam-devices referenced in
the source package. But it's not there in the final build.

Bug#818116: Broken fix

[Maik Zumstrull]

reopen 818116
thanks

You replaced "grep" with "grep | true" which not only fixes the return code but 
also eats the output. The intention was probably to use "grep || true".

The package now prints
/var/lib/dpkg/info/uwsgi-plugin-python.postinst: 61: [: Illegal number:

during install (but no longer totally fails to install).

Bug#814321: Maybe not totally useless?

[Maik Zumstrull]

reopen 814321
thanks

Dropping this dependency led to one of my machines uninstalling
tex-common, which then made dpkg error out:

# dpkg --configure -a
Setting up fonts-lmodern (2.004.5-2) ...
/var/lib/dpkg/info/fonts-lmodern.postinst: 17:
/var/lib/dpkg/info/fonts-lmodern.postinst: update-texmf-config: not
found
dpkg: error processing package fonts-lmodern (--configure):
 subprocess installed post-installation script returned error exit status 127
Errors were encountered while processing:
 fonts-lmodern

So I think it either should depend on tex-common after all, or
shouldn't attempt to call update-texmf-config unless tex-common
happens to be there.

Bug#801869: nvidia-graphics-drivers: setting /dev/nvidia* to root:video 0660 breaks gdm3, sddm, ...

[Maik Zumstrull]

On Thu, 15 Oct 2015 15:14:39 +0200 Andreas Beckmann  wrote:

> For local users logging into X a session-based membership in the video
> group is handled automatically via some consolekit magic (in
> nvidia-kernel-common).

I believe consolekit is deprecated, has this magic been ported to
systemd-logind?

If it has, I don't think it's working quite right - I had to put both
Debian-gdm and my personal account into the video group permanently to
get a GNOME session just now. No magic happening. Consolekit isn't
installed, nothing in the GNOME area seems to depend on it anymore.

Bug#671305: (no subject)

[Maik Zumstrull]

On Thu, Oct 10, 2013 at 12:10 PM, Thomas Lange
la...@informatik.uni-koeln.de wrote:
 Please try the newest dracut version (034-1 atm.) and setting rd.auto=1.

Cryptsetup no longer hangs. Some weirdness handing over to init, which
tries to unlock a device again that dracut already unlocked. But the
issue of this bug seems to be gone.


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

Bug#700975: RAID barely usable on my home machine

[Maik Zumstrull]

On Fri, Apr 5, 2013 at 10:23 AM, Robin Hill ro...@robinhill.me.uk wrote:
 On Thu Apr 04, 2013 at 10:13:05 +0200, Maik Zumstrull wrote:

 I've managed to find a configuration on my home desktop where a
 particular RAID array is barely usable.

 I used to have the same issues on one of my machines. The solution was
 to buy a decent SAS/SATA HBA (I went with the Intel RS2WC080, but see
 http://blog.zorinaq.com/?e=10 for a more complete list), which now works
 perfectly with exactly the same drives as before.

Calling that a solution seems generous, but since it doesn't look
like this'll get fixed any time soon, I decided to go the same way and
just ordered LSI SAS 9211-8i.

Thanks for the list, that seems like a very useful resource.


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

Bug#700975: RAID barely usable on my home machine

[Maik Zumstrull]

On Fri, Apr 5, 2013 at 2:16 AM, Roger Heflin rogerhef...@gmail.com wrote:

 lspci look like this for the controller:
 SATA controller: Marvell Technology Group Ltd. Device 9230 (rev 10)

 4pt sata3.0 6gbit or is yours a different one?

Mine looks slightly different (included somewhere in my mail), but
should be a device in the same family.

 I have the issue also, I have eliminated all smart hits against the
 disks and no incidents since then.

Not a great workaround as such, first of all, running SMART against
your storage is kind of recommended, and secondly, as I said, udisks2
will also SMART your disks occasionally, which you have to uninstall
parts of GNOME to get rid of.

 I have seagate 1.5tb drives on mine that had had the issues.

Suggests it's not something about my drives, as I have WD Red disks.


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

Bug#700975: RAID is still barely usable

[Maik Zumstrull]

Any way to get some attention on this bug? Unless I'm missing
something, it seems to make a fairly major feature (md) nearly
unusable (for me), with issues of potential data loss.

Maybe my hardware is just too exotic? But as far as I can tell, this
is a popular AHCI chip, and those are popular disks.


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

Bug#700975: Marvell 88SE9230: Freaks out and drops all disks if sent SMART command during RAID rebuild

[Maik Zumstrull]

On Thu, Apr 4, 2013 at 9:34 PM, Jonathan Nieder jrnie...@gmail.com wrote:

 Please send a summary of symptoms to linux-r...@vger.kernel.org,
 cc-ing either me or this bug log so we can track it.

Will do. FWIW I think the underlying issue is likely in the SATA code,
with RAID just providing the tons of background I/O load needed to
trigger the issue. But I'm happy to start on that end.


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

Bug#700975: RAID barely usable on my home machine

[Maik Zumstrull]

Hello Linux RAID and ATA people,

I've managed to find a configuration on my home desktop where a
particular RAID array is barely usable.

You can find my initial report at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700975

In summary:

- I create an array across four disks on a Marvell AHCI controller,
which automatically goes into rebuild mode.
- Somebody (e.g. smartd or udisks2 or me, testing) sends a SMART
command to one of the disks.
- The SMART command fails.
- The ATA subsystems freaks out all over the place, until eventually
none of the disks on that controller are responsive.
- The array is dead until reboot. (Curiously, without data loss so
far. Kudos on the RAID code, I guess.)

I've found the issue to be highly reproducible so far. Things mostly
work if the array is not under heavy load (not rebuilding, no big file
copies going on) or I make completely sure nothing sends SMART
commands. I currently do keep real files on that array, but backed-up
ones, so I could wipe it for more tests if really necessary.

I've tried various kernels from Debian (3.2, 3.7, and 3.8 series) and
found them all affected.

Here are some edited excerpts from the kernel log messages as found in
the Debian bug, see unedited transcript there.

Getting our RAID on:

[  122.707833] md127: detected capacity change from 0 to 9001374842880
[  122.707860] RAID conf printout:
[  122.707865]  --- level:5 rd:4 wd:3
[  122.707868]  disk 0, o:1, dev:sde
[  122.707870]  disk 1, o:1, dev:sdf
[  122.707872]  disk 2, o:1, dev:sdg
[  122.707873]  disk 3, o:1, dev:sdh
[  122.707965] md: recovery of RAID array md127
[  122.707968] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[  122.707970] md: using maximum available idle IO bandwidth (but not
more than 20 KB/sec) for recovery.
[  122.707973] md: using 128k window, over a total of 2930135040k.

We see a SMART we don't like:

[  180.531641] ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[  180.531648] ata9.00: failed command: SMART
[  180.531655] ata9.00: cmd b0/d1:01:01:4f:c2/00:00:00:00:00/00 tag 0 pio 512 in
[  180.531655]  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[  180.531658] ata9.00: status: { DRDY }

Woops, a non-critical command failed? Best shoot the controller in the
face until it stops twitching:

[  180.531666] ata9: hard resetting link
[  185.887433] ata9: link is slow to respond, please be patient (ready=0)
[  190.524871] ata9: COMRESET failed (errno=-16)
[  190.524877] ata9: hard resetting link
[  195.872694] ata9: link is slow to respond, please be patient (ready=0)
[  200.510134] ata9: COMRESET failed (errno=-16)
[  200.510141] ata9: hard resetting link
[  205.857925] ata9: link is slow to respond, please be patient (ready=0)
[  235.470518] ata9: COMRESET failed (errno=-16)
[  235.470526] ata9: limiting SATA link speed to 3.0 Gbps
[  235.470529] ata9: hard resetting link
[  240.483102] ata9: COMRESET failed (errno=-16)
[  240.483110] ata9: reset failed, giving up
[  240.483112] ata9.00: disabled
[  240.483134] ata9: EH complete

So now other stuff goes wrong:

[  301.216814] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[  301.216818] ata7.00: failed command: FLUSH CACHE EXT
[  301.216821] ata7.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[  301.216821]  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[  301.216822] ata7.00: status: { DRDY }
[  301.216827] ata7: hard resetting link
[  301.216842] ata10.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[  301.216845] ata10.00: failed command: FLUSH CACHE EXT
[  301.216849] ata10.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[  301.216849]  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[  301.216851] ata10.00: status: { DRDY }
[  301.216855] ata10: hard resetting link
[  301.216861] ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[  301.216864] ata8.00: failed command: FLUSH CACHE EXT
[  301.216868] ata8.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[  301.216868]  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
0x4 (timeout)
[  301.216870] ata8.00: status: { DRDY }

Until eventually, the patient's dead…so let's report success:

[  351.917459] md/raid:md127: Disk failure on sde, disabling device.
[  351.917459] md/raid:md127: Operation continuing on 0 devices.
[  351.921299] md: md127: recovery done.

This is on a cheapo PCIe extension board with four internal SATA3
ports. Chip is a Marvell Technology Group Ltd. 88SE9230 PCIe SATA
6Gb/s Controller [1b4b:9230] using the ahci driver.

It would be really good to see this fixed. I see two issues:
- That SMART command probably shouldn't fail. Weird drive firmware?
Timeout too tight?
- A failing SMART command should probably not trigger a breakdown of
the whole controller. At least, not such a messy one.

I'll make myself available, as time allows, to provide requested
additional information.


--
To UNSUBSCRIBE, 

Bug#671305: New dracut version 026 available

[Maik Zumstrull]

On Mon, Mar 25, 2013 at 2:12 PM, Thomas Lange
la...@informatik.uni-koeln.de wrote:
 I just uploaded dracut_026+71+g78d1d4f-1. Could you please test if
 your problem is fixed in this version.

Nope.

- Didn't boot at all at first (I suspect non-dracut issue, fixed by power off)
- Didn't activate md devices on its own
- cryptsetup hangs the same way

This is on new hw btw, the old system I reported from is gone.
Apparently the issue isn't hardware specific.

Thanks for following up.


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

Bug#700975: Also happens on 3.8

[Maik Zumstrull]

Just tried with 3.8.2, fresh from experimental.

Bug#700975: Happens with wheezy kernel

[Maik Zumstrull]

Tried building an array with linux-image-3.2.0-4-amd64 / 3.2.35-2, same issue.


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

Bug#700975: linux-image-3.7-trunk-amd64: Marvell 88SE9230: Freaks out and drops all disks if sent SMART command during RAID rebuild

[Maik Zumstrull]

Package: src:linux
Version: 3.7.8-1~experimental.1
Severity: normal

Subject says most of it. These are new components: PCIe card with that
Marvell chip, 4 exposed SATA 6G ports, one WD Red 3TB on each port.
Disks are fine according to SMART conveyance test.

Console action:

maik@antares:~/  sudo mdadm -C linux-data -n 4 -l 5 /dev/sde /dev/sdf /dev/sdg 
/dev/sdh
mdadm: /dev/sde appears to be part of a raid array:
level=raid5 devices=4 ctime=Tue Feb 19 22:47:42 2013
mdadm: /dev/sdf appears to be part of a raid array:
level=raid5 devices=4 ctime=Tue Feb 19 22:47:42 2013
mdadm: /dev/sdg appears to be part of a raid array:
level=raid5 devices=4 ctime=Tue Feb 19 22:47:42 2013
mdadm: /dev/sdh appears to be part of a raid array:
level=raid5 devices=4 ctime=Tue Feb 19 22:47:42 2013
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md/linux-data started.
maik@antares:~/  cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md127 : active raid5 sdh[4] sdg[2] sdf[1] sde[0]
  8790405120 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/3] [UUU_]
  []  recovery =  0.0% (679936/2930135040) 
finish=574.4min speed=84992K/sec
  
unused devices: none
maik@antares:~/  sudo smartctl -H /dev/sdg
smartctl 5.43 2012-06-05 r3561 [x86_64-linux-3.7-trunk-amd64] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

maik@antares:~/  sudo smartctl -H /dev/sdg
smartctl 5.43 2012-06-05 r3561 [x86_64-linux-3.7-trunk-amd64] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

maik@antares:~/  sudo smartctl -H /dev/sdg
smartctl 5.43 2012-06-05 r3561 [x86_64-linux-3.7-trunk-amd64] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

Error SMART Thresholds Read failed: scsi error aborted command
Smartctl: SMART Read Thresholds failed.

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: UNKNOWN!
SMART Status, Attributes and Thresholds cannot be read.


I've extended the kernel log below so it covers everything from the
moment of RAID creation, including the failing SMART command.

The problem seems fairly repeatable, so far every attempt at creating a
RAID has failed this way (because smartd eventually pings the disks).


-- Package-specific info:
** Version:
Linux version 3.7-trunk-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.7.8-1~experimental.1

** Command line:
BOOT_IMAGE=/vmlinuz-3.7-trunk-amd64 
root=UUID=06cc1c4c-d190-49bb-9219-0ccfa22e2661 ro acpi_os=Linux quiet

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

** Kernel log:
[  122.445618] md: bindsde
[  122.445783] md: bindsdf
[  122.445952] md: bindsdg
[  122.456452] md: bindsdh
[  122.459351] async_tx: api initialized (async)
[  122.460092] xor: automatically using best checksumming function:
[  122.499742]avx   : 11990.000 MB/sec
[  122.567597] raid6: sse2x14318 MB/s
[  122.635438] raid6: sse2x25419 MB/s
[  122.703278] raid6: sse2x46137 MB/s
[  122.703280] raid6: using algorithm sse2x4 (6137 MB/s)
[  122.703282] raid6: using ssse3x2 recovery algorithm
[  122.706977] md: raid6 personality registered for level 6
[  122.706981] md: raid5 personality registered for level 5
[  122.706983] md: raid4 personality registered for level 4
[  122.707309] md/raid:md127: device sdg operational as raid disk 2
[  122.707312] md/raid:md127: device sdf operational as raid disk 1
[  122.707314] md/raid:md127: device sde operational as raid disk 0
[  122.707711] md/raid:md127: allocated 4338kB
[  122.707797] md/raid:md127: raid level 5 active with 3 out of 4 devices, 
algorithm 2
[  122.707799] RAID conf printout:
[  122.707801]  --- level:5 rd:4 wd:3
[  122.707803]  disk 0, o:1, dev:sde
[  122.707805]  disk 1, o:1, dev:sdf
[  122.707806]  disk 2, o:1, dev:sdg
[  122.707833] md127: detected capacity change from 0 to 9001374842880
[  122.707860] RAID conf printout:
[  122.707865]  --- level:5 rd:4 wd:3
[  122.707868]  disk 0, o:1, dev:sde
[  122.707870]  disk 1, o:1, dev:sdf
[  122.707872]  disk 2, o:1, dev:sdg
[  122.707873]  disk 3, o:1, dev:sdh
[  122.707965] md: recovery of RAID array md127
[  122.707968] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[  122.707970] md: using maximum available idle IO bandwidth (but not more than 
20 KB/sec) for recovery.
[  122.707973] md: using 128k window, over a total of 2930135040k.
[  122.740153]  md127: unknown partition table
[  180.531641] ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[  180.531648] ata9.00: failed command: SMART
[  180.531655] ata9.00: cmd 

Bug#694481: opensc: Lacks support for ePass2003 USB token

[Maik Zumstrull]

Package: opensc
Version: 0.12.2-3
Severity: normal


Upstream apparently has this (epass2003.profile), please upload a build
with this support included as soon as it's convenient.

Thanks,

Maik


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

Bug#689753: linux-image-3.5-trunk-amd64: Please support /boot being vfat, or another way of having the kernel on the EFI system partition

[Maik Zumstrull]

Package: src:linux
Version: 3.5.5-1~experimental.1
Severity: normal

Call me a masochist, but I've been using UEFI boot on systems new enough
to support it. For this, it makes sense to have the kernel and initrd
images on the EFI system partition.

It's not an absolute requirement. One could have grub on the system
partition, and have grub read the kernel off whatever filesystem it's on.

However, as far as I can tell, the direction the boot process is going
is for the kernel to be an EFI executable. No boot loader in the
oldschool sense, just something to select which kernel to run and pass a
command line.

To simply run the kernel as an EFI application, two requirements:
- The kernel image has to be compiled as an EFI executable. Recent
  Debian kernel images are.
- The kernel image has to be on a file system EFI can read. That doesn't
  necessarily mean the system partition, but it does mean vfat.

Now, in linux-image-* packages, the kernel image is simply a file in
/boot. If /boot is the EFI system partition, dpkg will fail to update
the package, because dpkg assumes file systems have hard link support.

When this issue came up back in 2008, it was decided to just accept this
dpkg limitation and officially require /boot to be a POSIX file system.
I suggest to revisit this decision in the context of UEFI boot.

How best to implement this depends on the preferred way of mounting the
system partition. Arguably, the system partition should be /boot, since
that's the point. In that case, one could ship the kernel image beneath
/lib in the package and copy it to /boot from postinst.

Another popular option is to have /boot on the root file system and the
system partition on /boot/efi. In that case, it would be fine to leave
the kernel image in the package as it is now, but the package should
offer to always keep copies of the kernel and the initrd in /boot/efi.


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

Bug#684767: kernel: missing support for Ivy Bridge GT2 Server

[Maik Zumstrull]

On Sun, Sep 30, 2012 at 1:52 AM, Jonathan Nieder jrnie...@gmail.com wrote:
 Hi Maik,

 Maik Zumstrull wrote:

 This is on an Ivy Bridge Xeon E3 with GPU.
 [...]
 3.2 crashes as well, but not as hard as 3.4. With 3.2, X doesn't come
 up, but you can switch to a console and reboot.

 Sorry for the slow reply.  Please test the attached patch, for example
 using the following instructions.

With those instructions and with the patch, 3.2.30 can bring up i915
KMS. Without the patch, it cannot. Seems to hit the spot.


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

Bug#684650: libdrm-intel1: X dies hard on Ivy Bridge GT2 Server graphics

[Maik Zumstrull]

On Sat, Aug 18, 2012 at 6:35 PM, Julien Cristau jcris...@debian.org wrote:

 Please package a version = 2.4.34 or backport the patches mentioned in
 this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=53222

 Why did you file a duplicate then?

I felt a separate bug against libdrm was more appropriate. Jonathan
disagreed, obviously. Feel free to merge/unmerge/reassign/whatever as
you see fit.

FYI, I finished rebuilding the package with the patch that adds the
PCI ID minutes ago, and I have somewhat working X with intel driver
now. OpenGL seems to work, VA-API doesn't, but that may again be a
problem with outdated versions. I can't use the full resolution of the
display, not sure why. Maybe the DVI port on the board isn't dual
link.


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

Bug#684650: libdrm-intel1: X dies hard on Ivy Bridge GT2 Server graphics

[Maik Zumstrull]

Package: libdrm-intel1
Version: 2.4.33-3
Severity: important

If X is started with this libdrm on a machine with Ivy Bridge GT2
Server Intel graphics, it crashes and leaves the machine in an almost
unusable state (network/ssh might remain up). X is certainly completely
unusable, as it won't start.

Please package a version = 2.4.34 or backport the patches mentioned in
this bug report: https://bugs.freedesktop.org/show_bug.cgi?id=53222

Other related reports:
https://bugzilla.redhat.com/show_bug.cgi?id=840180
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683167

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (400, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.5-trunk-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 libdrm-intel1 depends on:
ii  libc6  2.13-33
ii  libdrm22.4.33-3
ii  libpciaccess0  0.13.1-2
ii  multiarch-support  2.13-33

libdrm-intel1 recommends no packages.

libdrm-intel1 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#683167: Attempting to start X with intel driver hangs system

[Maik Zumstrull]

On Mon, Aug 6, 2012 at 2:39 AM, Jonathan Nieder jrnie...@gmail.com wrote:

 One more test and then we should take this upstream: does a boot
 without attempting to start X work ok?  Do you get a working
 framebuffer console?

Yes, that works fine.

 Either way, please report this upstream following instructions from

   http://intellinuxgraphics.org/how_to_report_bug.html

 and let us know the bug number so we can track it.

https://bugs.freedesktop.org/show_bug.cgi?id=53222

 The upstream maintainers will want a kernel log with the boot option
 'drm.debug=0x0e' appended

Their doc says 0x06? Either way, will do that tomorrow or so.


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

Bug#683167: Attempting to start X with intel driver hangs system

[Maik Zumstrull]

On Sat, Aug 4, 2012 at 10:27 PM, Jonathan Nieder jrnie...@gmail.com wrote:

 Please attach a full log from netconsole from booting and
 reproducing the problem.  (It's ok if it doesn't say anything
 interesting at the crucial moment.)

Done.

 If you can get the corresponding Xorg log, that would be interesting,
 too.

It doesn't seem to get around to writing one. The existing file was
for a session with the vesa driver.


netconsole.txt.bz2
Description: BZip2 compressed data

Bug#683167: Attempting to start X with intel driver hangs system

[Maik Zumstrull]

On Sat, Aug 4, 2012 at 10:04 AM, Jonathan Nieder jrnie...@gmail.com wrote:

 Can you get a trace of the crash using a serial console[1] or
 netconsole[2]?

I got netconsole working, and some messages came through (I replugged
a USB device to trigger some), but nothing when it crashes. I don't
have the cabling here for serial (it's only a pinheader on this
board), but I could get it next week if that's what it takes.


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

Bug#683167: Also in 3.5

[Maik Zumstrull]

Now running linux-image-3.5-trunk-amd64 (3.5-1~experimental.1). Still happens.

Note that while I suspect the kernel, I'm in no position to rule out
the X driver. Feel free to loop them in.


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

Bug#683167: Attempting to start X with intel driver hangs system

[Maik Zumstrull]

On Fri, Aug 3, 2012 at 9:01 PM, Jonathan Nieder jrnie...@gmail.com wrote:

 Does the squeeze 2.6.32.y kernel reproduce the same trouble?  (It should run
 fine on a wheezy/sid system.)  Could you retrieve full dmesg output
 from the 3.2.y failure?

2.6.32 has never heard of this GPU, so the i915 module doesn't
initialize. The X server exits immediately, saying no device was
found, but doesn't crash. The kernel panics on trying to reboot, but
the stack trace shows a bunch of EFI-related functions, so it's
probably unrelated.

But let's make a note that yes, I installed with EFI boot, which is
probably a lot less tested than legacy BIOS boot. I haven't tried if
it is happier with BIOS boot, I could do that tomorrow if you think
it's important.

3.2 behavior is now similar: i915.ko doesn't know the GPU, and X just
exits because i915 isn't there. My last tests were with a 2.19 X
driver, presumably the update to 2.20 made the 3.2 crash go away.


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

Bug#683558: s3cmd: Please cherrypick upstream bugfix

[Maik Zumstrull]

Package: s3cmd
Version: 1.1.0~beta3-1
Severity: normal

Upstream issue: https://github.com/s3tools/s3cmd/issues/24
Upstream fix: 
https://github.com/s3tools/s3cmd/commit/9c57a3ba2163915deb2cc63cefa885a66ac377ab

This prevents using s3cmd sync in a cronjob. Upstream has unfortunately
not cut a release that includes this fix, maybe ask them to do so.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (400, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.4-trunk-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 s3cmd depends on:
ii  python  2.7.3-2

s3cmd recommends no packages.

s3cmd 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#683167: linux-image-3.4-trunk-amd64: Attempting to start X with intel driver hangs system

[Maik Zumstrull]

Package: src
Version: 3.4.4-1~experimental.1
Severity: important

This is on an Ivy Bridge Xeon E3 with GPU. I thought it was the X
driver, because i915 KMS works fine for the console, it only crashes
when trying to bring up X. But I pulled in the 2.20.2 driver today and
it still happens. So I now think the problem is in the kernel.

It's entirely possible this is fixed in 3.5, which I will test as soon
as it hits experimental.

3.2 crashes as well, but not as hard as 3.4. With 3.2, X doesn't come
up, but you can switch to a console and reboot. 3.4 needs the reset
button.

-- Package-specific info:
** Version:
Linux version 3.4-trunk-amd64 (Debian 3.4.4-1~experimental.1) 
(debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 SMP 
Tue Jun 26 17:23:03 UTC 2012

** Command line:
BOOT_IMAGE=/vmlinuz-3.4-trunk-amd64 root=/dev/mapper/luks-root ro quiet

** Not tainted

** Kernel log:
[   43.319002] Monitor-Mwait will be used to enter C-3 state
[   43.319016] ACPI: acpi_idle registered with cpuidle
[   43.323450] iTCO_vendor_support: vendor-support=0
[   43.324345] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.07
[   43.324409] iTCO_wdt: Found a Panther Point TCO device (Version=2, 
TCOBASE=0x0460)
[   43.324449] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   43.329003] ACPI Warning: 0xf040-0xf05f SystemIO 
conflicts with Region \_SB_.PCI0.SBUS.SMBI 1 (20120320/utaddress-251)
[   43.329008] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[   43.344385] wmi: Mapper loaded
[   43.344513] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
[   43.344826] ACPI: Power Button [PWRF]
[   43.345309] Bluetooth: Core ver 2.16
[   43.345318] NET: Registered protocol family 31
[   43.345319] Bluetooth: HCI device and connection manager initialized
[   43.345321] Bluetooth: HCI socket layer initialized
[   43.345322] Bluetooth: L2CAP socket layer initialized
[   43.345325] Bluetooth: SCO socket layer initialized
[   43.347792] input: PC Speaker as /devices/platform/pcspkr/input/input7
[   43.348878] Linux media interface: v0.10
[   43.349854] usbcore: registered new interface driver btusb
[   43.349925] microcode: CPU0 sig=0x306a9, pf=0x2, revision=0x10
[   43.351137] Linux video capture interface: v2.00
[   43.352848] snd_hda_intel :00:1b.0: enabling device ( - 0002)
[   43.352902] snd_hda_intel :00:1b.0: irq 55 for MSI/MSI-X
[   43.354422] uvcvideo: Found UVC 1.00 device unnamed (046d:081d)
[   43.366279] usb 4-1.6.1: input irq status -75 received
[   43.367115] input: UVC Camera (046d:081d) as 
/devices/pci:00/:00:1d.0/usb4/4-1/4-1.7/4-1.7:1.2/input/input8
[   43.367167] usbcore: registered new interface driver uvcvideo
[   43.367168] USB Video Class driver (1.1.1)
[   43.371842] asus_wmi: ASUS WMI generic driver loaded
[   43.372554] asus_wmi: Initialization: 0x0
[   43.372568] asus_wmi: BIOS WMI version: 0.9
[   43.372592] asus_wmi: SFUN value: 0x0
[   43.372755] input: Eee PC WMI hotkeys as 
/devices/platform/eeepc-wmi/input/input9
[   43.373301] asus_wmi: Backlight controlled by ACPI video driver
[   43.373916] microcode: CPU1 sig=0x306a9, pf=0x2, revision=0x10
[   43.375110] microcode: CPU2 sig=0x306a9, pf=0x2, revision=0x10
[   43.376077] microcode: CPU3 sig=0x306a9, pf=0x2, revision=0x10
[   43.377564] microcode: Microcode Update Driver: v2.00 
tig...@aivazian.fsnet.co.uk, Peter Oruba
[   43.381261] usbcore: registered new interface driver snd-usb-audio
[   43.390225] usb 4-1.6.1: input irq status -75 received
[   43.402028] input: HDA Intel PCH Line as 
/devices/pci:00/:00:1b.0/sound/card0/input10
[   43.402110] input: HDA Intel PCH Front Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input11
[   43.402165] input: HDA Intel PCH Rear Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input12
[   43.402201] input: HDA Intel PCH Front Headphone as 
/devices/pci:00/:00:1b.0/sound/card0/input13
[   43.402235] input: HDA Intel PCH Line Out Side as 
/devices/pci:00/:00:1b.0/sound/card0/input14
[   43.402276] input: HDA Intel PCH Line Out CLFE as 
/devices/pci:00/:00:1b.0/sound/card0/input15
[   43.402344] input: HDA Intel PCH Line Out Surround as 
/devices/pci:00/:00:1b.0/sound/card0/input16
[   43.402436] input: HDA Intel PCH Line Out Front as 
/devices/pci:00/:00:1b.0/sound/card0/input17
[   46.841151] XFS (sde2): Mounting Filesystem
[   47.759356] XFS (sde2): Ending clean mount
[   47.828292] FAT-fs (sde1): utf8 is not a recommended IO charset for FAT 
filesystems, filesystem will be case sensitive!
[   47.846638] XFS (dm-8): Mounting Filesystem
[   48.029741] XFS (dm-8): Ending clean mount
[   48.053466] XFS (dm-9): Mounting Filesystem
[   48.167516] XFS (dm-9): Ending clean mount
[   48.178220] XFS (dm-7): Mounting Filesystem
[   48.521452] XFS (dm-7): Ending clean mount
[   49.793502] Bridge firewalling registered
[   

Bug#671305: (no subject)

[Maik Zumstrull]

On Sat, May 26, 2012 at 9:20 AM, Thomas Lange
la...@informatik.uni-koeln.de wrote:
 I wonder why this does not work, since the xts kernel modules should
 be included. Please call dracut -v and check if the xts module in not
 loaded into the initramfs.

I can confirm that

- dracut attempts to ship the xts module:
D: Installing /lib/modules/3.2.0-2-amd64/kernel/crypto/xts.ko
- the file ends up in the actual image:
-rw-r--r--   1 root root 7144 May 21 20:47
lib/modules/3.2.0-2-amd64/kernel/crypto/xts.ko

I'm not using XTS on my volumes. So this exactly couldn't be my issue anyway.



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

Bug#646130: parted staleness

[Maik Zumstrull]

How about creating a separate parted3 package, if parted 2.x will be
needed by d-i for the foreseeable future?



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

Bug#671305: dracut: cryptsetup just hangs, making the system unbootable

[Maik Zumstrull]

Package: dracut
Version: 018+32+geb6e141-1

So, I had a bit of a bad experience yesterday evening. :-)

I switched from initramfs-tools to dracut 18, because I like the idea
of dracut, and I had successfully used dracut 17. But after reboot and
entering a LUKS password, nothing happened.

I rebooted and added [rd.luks=0 rd.shell] to the kernel command line.
Trying to open any LUKS device manually showed the same behavior: it
just hangs. No reaction to SIGINT. SIGQUIT gets rid of the cryptsetup
process. At that point, a /dev/dm-? node has shown up, but doesn't
work yet, and none of the symlinks are there.

I reverted the machine to initramfs-tools for now.



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

Bug#664487: xvba-va-driver: Needs to make the multiarch move

[Maik Zumstrull]

Package: xvba-va-driver
Version: 0.8.0-3
Severity: important

With the recent libva update, xvba-va-driver no longer works by default,
because libva looks for drivers in a multiarch path now. Workaround:
LIBVA_DRIVERS_PATH=/usr/lib/dri
LIBVA_DRIVER_NAME=xvba

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-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 xvba-va-driver depends on:
ii  libc6 2.13-27
ii  libgl1-mesa-glx [libgl1]  7.11.2-1
ii  libx11-6  2:1.4.4-4
ii  libxext6  2:1.3.0-3
ii  libxvbaw1 1:12-2-2

xvba-va-driver recommends no packages.

xvba-va-driver 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#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Maik Zumstrull]

On Tue, Feb 28, 2012 at 06:09, Dan Williams d...@redhat.com wrote:

 Notes I'd seen from another driver indicate that it's got a modem/PPP
 port (intf 0), a DIAG/DM port (intf 1 or 2) and the PCUI port (intf 1 or
 2).  At least the PCUI port should be able to respond to AT commands
 too.  Can you talk on ttyUSB1 or ttyUSB2 with AT commands?

 Try AT^GETPORTMODE on any port that takes AT commands and see what you
 get.

ttyUSB0 acts like a modem. That it opens instantly holds with picocom
as well, the other ones hang for a bit.
ttyUSB1 doesn't seem to take AT commands (no response).
ttyUSB2 takes AT commands.

Both AT-capable ports reply COMMAND NOT SUPPORT [sic] to AT^GETPORTMODE.



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

Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Maik Zumstrull]

On Tue, Feb 28, 2012 at 19:19, Dan Williams d...@redhat.com wrote:
 On Tue, 2012-02-28 at 11:14 +0100, Maik Zumstrull wrote:

 ttyUSB0 acts like a modem. That it opens instantly holds with picocom
 as well, the other ones hang for a bit.
 ttyUSB1 doesn't seem to take AT commands (no response).
 ttyUSB2 takes AT commands.

 Both AT-capable ports reply COMMAND NOT SUPPORT [sic] to AT^GETPORTMODE.

 But ttyUSB2 still has the close() blocking problem while ttyUSB0 does
 not?

Yes. ttyUSB2 has the same functionality as 0 and the same timing issues as 1.



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

Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Maik Zumstrull]

On Mon, Feb 27, 2012 at 16:33, Dan Williams d...@redhat.com wrote:

 Ah, yeah, that would make sense.  Does this happen for *all* ports on
 the modem, or only a few ports?

Patched the C snippet to open/close all three. Looks like ttyUSB0 is
fine, 1 and 2 hang.
#include sys/types.h
#include sys/stat.h
#include unistd.h
#include fcntl.h

int main(void)
{
	int fd = -1;
	fd = open(/dev/ttyUSB0, O_RDWR | O_EXCL | O_NOCTTY | O_NONBLOCK);
	close(fd);
	fd = open(/dev/ttyUSB1, O_RDWR | O_EXCL | O_NOCTTY | O_NONBLOCK);
	close(fd);
	fd = open(/dev/ttyUSB2, O_RDWR | O_EXCL | O_NOCTTY | O_NONBLOCK);
	close(fd);
	return 0;
}


ttytest.strace
Description: Binary data

Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Maik Zumstrull]

On Mon, Feb 27, 2012 at 17:19, Dan Williams d...@redhat.com wrote:

 Any chance you can get the Windows driver installer for this device?

Weirdly, ASUS doesn't offer it for download. I wiped the included
Windows first thing.

 Looking at the INF files gives us clues as to what the ports are used
 for.  Also, I'd expect at least *two* AT capable ports on a GSM/UMTS
 device, but perhaps only one on a CDMA/EVDO device.  Is this an EM770
 (CDMA/EVDO) or a GSM/UMTS device?

GSM/UMTS

  Also, again is there any way you can
 get the device model name and firmware version from ATI/AT+GMM/AT+GMR ?

Manufacturer: huawei
Model: EM770
Revision: 11.108.04.01.40
IMEI: [Removed]
+GCAP: +CGSM,+DS,+ES

OK

EM770

OK

11.108.04.01.40



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

Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Maik Zumstrull]

On Mon, Feb 27, 2012 at 16:15, Dan Williams d...@redhat.com wrote:

 What device is this?

Some kind of embedded Huawei USB thing. lsusb was in my first mail to
the list, don't have the netbook next to me right now.



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

Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Maik Zumstrull]

On Sun, Feb 26, 2012 at 18:07, Greg KH g...@kroah.com wrote:
 On Sun, Feb 26, 2012 at 05:38:46PM +0100, Maik Zumstrull wrote:

 I don't see any long delay in your kernel log messages.

The problem isn't visible in dmesg AFAIK. I was asked to include this
output in the report just in case. It's visible in strace (attached to
Bugzilla, can take a fresh trace if you'd like), and to the user
because the whole system ignores user input during the freeze.

 What exactly is stalling so long?

When someone previously looked at the issue with me, the delay seemed
to be in acquiring the big TTY lock.

 Is the device stuck doing something?

Not as far as I know.

 If you enable debugging for usb and/or the driver, what does the kernel
 log show?

I don't think we've done that yet. Quick pointer on how to do this?
I'm reasonably experienced, but not a kernel developer. Just pass
debug=1 to certain modules?

 What driver is bound to this device, the option one?

Yes. The drivers symlink points to bus/usb/drivers/option, anyway, I
hope that's what you meant.



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

Bug#605275: EeePC 1005HAG still freezes when probing the builtin 3G modem

[Maik Zumstrull]

On Sun, Feb 26, 2012 at 18:57, Greg KH g...@kroah.com wrote:
 On Sun, Feb 26, 2012 at 06:35:43PM +0100, Maik Zumstrull wrote:

  Is the device stuck doing something?

 Not as far as I know.

 Are two userspace programs trying to access the device at the same time?

The device exports three virtual serial ports. ModemManager accesses
more than one. On the other hand, we were able to reproduce the freeze
accessing only one port from one process, see Bugzilla.

I've attached a fresh strace of opening the device on 3.2.6. The
open() takes 10s, the close takes 5s. Nothing else was accessing any
ttyUSB*; I killed ModemManager and double checked with lsof.

 Yes.  Please try loading the module with:
        modprobe option debug=1
 and seeing what happens in the kernel log when you open the device.

Output attached. I think it's three option_send_setup for one
open()/close(). At least, that's what happens with the C snippet.


kern.log.bz2
Description: BZip2 compressed data


ttytest.strace
Description: Binary data

Bug#605275: EeePC 1005HAG freezes briefly after resuming

[Maik Zumstrull]

On Wed, Feb 22, 2012 at 22:59, Jonathan Nieder jrnie...@gmail.com wrote:

 Maik Zumstrull wrote:

 Reported as:
 https://bugzilla.kernel.org/show_bug.cgi?id=23962

 Thanks.  Apparently Greg doesn't like the bugzilla interface.  Since
 there has been some BTM elimination work upstream, could you try 3.2
 or newer from unstable?

I tried just a minute ago (the device is next to me) when I saw Greg's
mail, on Debian 3.2. It still happens. That was 3.2.4-1, I will reboot
into 3.2.6-1 and retry. You will loop in linux-usb afterwards?



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

Bug#605275: EeePC 1005HAG freezes briefly after resuming

[Maik Zumstrull]

On Wed, Feb 22, 2012 at 23:03, Maik Zumstrull m...@zumstrull.net wrote:

 I tried just a minute ago (the device is next to me) when I saw Greg's
 mail, on Debian 3.2. It still happens. That was 3.2.4-1, I will reboot
 into 3.2.6-1 and retry.

Also happens on 3.2.6-1.



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

Bug#633116: fcgiwrap: Should make CGI error messages available

[Maik Zumstrull]

Package: fcgiwrap
Version: 1.0.3-3
Severity: normal

It is very useful (I would even say, necessary) to have access to CGI
scripts' stderr output for debugging purposes.

In its current form, the Debian init script for fcgiwrap apparently
sends stderr to /dev/null. I think the actual redirect is performed by
spawn-fcgi, due to the way it is called.

Please make sure that either
- fcgiwrap sends the script's stderr to its own stderr, and this is
  redirected to a file or
- fcgiwrap sends the script's stderr to the FastCGI client (e.g. nginx)
  through the FastCGI error stream.



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

Bug#632641: network-manager should work harder to prevent information leaks with VPN connections

[Maik Zumstrull]

Package: network-manager-openvpn
Version: 0.8.999-1

When opening a VPN connection to an IPv4-only OpenVPN host, the only
thing NetworkManager currently does to direct traffic through the VPN
is switching the IPv4 default route to the tunnel device. In my
opinion, that is not enough to protect the user's communication.

First, if the user has local IPv6 service, it remains open. Any
services that (correctly) prefer v6 over v4 will default to
unencrypted communication.

Second, if the VPN goes down, any packets still queued will be sent
out unencrypted.

I think NetworkManager should take down any local routes, including
v6, to direct all traffic through the VPN. It should also use
source-based routing and/or iptables to make sure traffic meant for
the VPN never goes out through any other device, even if the default
route changes.

I ask that this is not downgraded to wishlist. Sending out unencrypted
traffic after the user has explicitly requested a VPN is kind of a big
deal, in my opinion.



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

Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken

[Maik Zumstrull]

On Wed, Jun 15, 2011 at 20:05, Robert Edmonds edmo...@debian.org wrote:
 Maik Zumstrull wrote:

 I've noticed this on my home router, which has a fairly fresh dnsmasq.
 Apparently, unbound can't resolve through this and just SERVFAILs for
 everything. Obviously, this is primarily a problem in dnsmasq (I
 assume). But since dnsmasq is in tons of home routers and unbound uses
 forwarding by default in Debian, I think it's important to have a
 workaround in place.

 it would be useful if you could get a packet trace of the failure.
 run something like:

 # tcpdump -s1518 -pni any -w dnsmasq-failure.pcap 'tcp port 53 or udp port 53'

Sure, no problem. Attached.

The trace leads me to assume that this might not be dnsmasq's fault, but this:
https://groups.google.com/d/topic/public-dns-discuss/9vXr9AJny4w/discussion

On the other hand, forwarding from dnsmasq to a different server that
can return DS records doesn't fix it. So maybe it's double-broken:
Google doesn't deliver the DS records, but dnsmasq would trash them if
they did.


dnsmasq-failure.pcap
Description: Binary data

Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken

[Maik Zumstrull]

On Wed, Jun 15, 2011 at 21:16, Robert Edmonds edmo...@debian.org wrote:

 you're most likely running unbound in the default debian config which
 enables DNSSEC validation.  if you comment out the
 auto-trust-anchor-file line in /etc/unbound/unbound.conf and restart
 unbound, does it start working with your dnsmasq server?

Yes. For the record, with validation enabled:

No forwarding: works
Forwarding to 8.8.8.8: fails
Forwarding to 4.2.2.1: works
Forwarding to dnsmasq which forwards to 8.8.8.8: fails
Forwarding to dnsmasq which forwards to 4.2.2.1: fails

So, breakage at dnsmasq and 8.8.8.8, I think, the latter officially
being a known issue.

 you can see in the trace that unbound is (repeatedly) attempting to find
 the DS record for com, and dnsmasq is responding with NXDOMAIN:

Yes. Google DNS fails differently, by the way: no record, NOERROR,
authority section for google.com.

 note that dnsmasq is responding with NXDOMAIN for com.  this is
 hilariously wrong, as it means that dnsmasq claims that com does not
 exist.  but apart from that, unbound is unable to find the DS record for
 com and thus DNSSEC validation fails.

Yes.

The problem with DS is, of course, that it is an authoritative member
of the parent zone only, so you have to ask the com. nameservers for
the DS record of google.com., not the google.com. nameservers.
Recursors have to just know that, it isn't covered by basic forwards
compatibility like any other new record type. Google's DNS apparently
doesn't, and dnsmasq is even more broken. (I'm trying to point out
that you may assume I have a detailed understanding of DNS and DNSsec
for the purposes of this discussion, without being a dick about it. I
don't think it's working.)

 i suspect that if you configure your dnsmasq server to forward to a
 server that supports DNSSEC (e.g., level3's 4.2.2.2) that your unbound
 forwarder may work, otherwise there are more bugs in dnsmasq.

See above; doesn't fix it, as far as I can tell.



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

Bug#630145: Problem gone

[Maik Zumstrull]

The problem has fixed itself with today's updates.

It can't have been the kernel or libc after all, neither was in this
round of updates.

Anyway, feel free to close, unless you still want to isolate the cause.



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

Bug#630145: xserver-xorg-core: Segfault with Intel KMS on Asus netbook

[Maik Zumstrull]

Package: xserver-xorg-core
Version: 2:1.10.2-1
Severity: important

Happens reliably on every startup, not on intermittent problem.

This is a very recent development. I suspect either the new kernel or
the new libc.

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

lrwxrwxrwx 1 root root 13 Nov 13  2010 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 201 May 30 14:10 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME 
Express Integrated Graphics Controller [8086:27ae] (rev 03)

Xorg X server configuration file status:

-rw-r--r-- 1 root root 95 Feb 28 14:30 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
Section Device
Identifier  IntelOnboard
Driver  intel
Option  XvMC true
EndSection

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

KMS configuration files:

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

Kernel version (/proc/version):
---
Linux version 2.6.39-2-686-pae (Debian 2.6.39-2) (b...@decadent.org.uk) (gcc 
version 4.4.6 (Debian 4.4.6-3) ) #1 SMP Wed Jun 8 11:33:14 UTC 2011

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 35506 Jun 10 22:55 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[40.473] 
X.Org X Server 1.10.1
Release Date: 2011-04-15
[40.473] X Protocol Version 11, Revision 0
[40.474] Build Operating System: Linux 2.6.32-5-686-bigmem i686 Debian
[40.474] Current Operating System: Linux errai 2.6.39-1-686-pae #1 SMP Fri 
May 20 20:40:05 UTC 2011 i686
[40.474] Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.39-1-686-pae 
root=/dev/mapper/croot ro elevator=deadline acpi_osi=Linux splash quiet
[40.474] Build Date: 01 May 2011  10:14:44AM
[40.474] xorg-server 2:1.10.1-2 (Julien Cristau jcris...@debian.org) 
[40.474] Current version of pixman: 0.21.8
[40.474]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[40.475] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[40.475] (==) Log file: /var/log/Xorg.0.log, Time: Fri Jun 10 17:53:46 
2011
[40.562] (==) Using config file: /etc/X11/xorg.conf
[40.562] (==) Using system config directory /usr/share/X11/xorg.conf.d
[40.600] (==) No Layout section.  Using the first Screen section.
[40.600] (==) No screen section available. Using defaults.
[40.600] (**) |--Screen Default Screen Section (0)
[40.600] (**) |   |--Monitor default monitor
[40.601] (==) No device specified for screen Default Screen Section.
Using the first device section listed.
[40.601] (**) |   |--Device IntelOnboard
[40.601] (==) No monitor specified for screen Default Screen Section.
Using a default monitor configuration.
[40.601] (==) Automatically adding devices
[40.601] (==) Automatically enabling devices
[40.721] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
[40.721]Entry deleted from font path.
[40.721] (WW) The directory /usr/share/fonts/X11/100dpi/ does not exist.
[40.721]Entry deleted from font path.
[40.721] (WW) The directory /usr/share/fonts/X11/75dpi/ does not exist.
[40.721]Entry deleted from font path.
[40.828] (WW) The directory /usr/share/fonts/X11/100dpi does not exist.
[40.828]Entry deleted from font path.
[40.828] (WW) The directory /usr/share/fonts/X11/75dpi does not exist.
[40.828]Entry deleted from font path.
[40.958] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/Type1,
/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType,
built-ins
[40.959] (==) ModulePath set to /usr/lib/xorg/modules
[40.959] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[40.959] (II) Loader magic: 0x8232ac0
[40.959] (II) Module ABI versions:
[40.959]X.Org ANSI C Emulation: 0.4
[40.959]X.Org Video Driver: 10.0
[40.959]X.Org XInput driver : 12.2
[40.960]X.Org Server Extension : 5.0
[40.963] (--) PCI:*(0:0:2:0) 8086:27ae:1043:8340 rev 3, Mem @ 
0xf7e0/524288, 0xd000/268435456, 0xf7dc/262144, I/O @ 0xdc00/8
[40.964] (--) PCI: (0:0:2:1) 8086:27a6:1043:8340 rev 3, Mem @ 
0xf7e8/524288
[40.965] (II) Open ACPI successful (/var/run/acpid.socket)
[40.965] (II) LoadModule: extmod
[40.968] (II) Loading 

Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken

[Maik Zumstrull]

Package: unbound
Version: 1.4.10-1
Severity: normal

I've noticed this on my home router, which has a fairly fresh dnsmasq.
Apparently, unbound can't resolve through this and just SERVFAILs for
everything. Obviously, this is primarily a problem in dnsmasq (I
assume). But since dnsmasq is in tons of home routers and unbound uses
forwarding by default in Debian, I think it's important to have a
workaround in place.

I think a good solution would be for unbound to detect when it can't
reliably resolve through one of the forwarding hosts and stop using
it, falling back to normal recursion if they all end up being dropped.
Ideally, this would happen before the user experiences lookup failures,
for example by immediately resolving a bunch of well-known hosts after
adding new forwarders, so that they will already be dropped with a high
probability if they are broken.

Until this type of workaround is in place, I would suggest disabling
resolvconf forwarders by default, or putting out a clear warning This
might kill your DNS, stop the unbound daemon if you can't resolve
anything anymore.



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

Bug#571196: CherryPy 3.2

[Maik Zumstrull]

Sorry to be a nag about this, but it would be helpful for me to know:
Is anybody on this? Does anybody plan to get on this in the near future?

I looked at 
http://svn.debian.org/viewsvn/python-modules/packages/cherrypy3/trunk/
and the package appears to be stalled for over a year now.

Even a negative statement would be appreciated, just to know what the
situation with this package is.



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

Bug#624131: linux-image-2.6.39-rc4-686-pae: Can somewhat reliably produce kernel panic in btrfs code

[Maik Zumstrull]

On Tue, Apr 26, 2011 at 05:59, Ben Hutchings b...@decadent.org.uk wrote:

 This fix doesn't seem to be in your for-linux branch yet.  Please can
 you ensure that this (or an alternate fix) is included in 2.6.39.

It seems to be in. I also haven't noticed panics with rc5/rc6. Just in
case you want to close this one.



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

Bug#571196: 3.2 is final

[Maik Zumstrull]

retitle 571196 Please package version 3.2.0
thanks

The 3.2 line of CherryPy has been final for a while now. While 3.1 is
working mostly fine, 3.2 is the first version of this (and, actually,
any) Python web framework that supports Python 3 (PEP-).
Especially for this reason, I'd like to see the package in Debian; if
necessary, as both Python 2 and Python 3 packages.



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

Bug#624131: linux-image-2.6.39-rc4-686-pae: Can somewhat reliably produce kernel panic in btrfs code

[Maik Zumstrull]

Package: linux-image-2.6.39-rc4-686-pae
Version: 2.6.39~rc4-1~experimental.1
Severity: normal
Tags: experimental

By simply stressing the system with some I/O, I can make it crash within
seconds. I'm not setting a higher severity because the bug is in an
experimental file system in an experimental kernel.

Here's the important bits (by my guess) I have on screen from the kernel panic:

Bug at fs/btrfs/free-space-cache.c:1246
Bug type: invalid opcode: 
Kernel not tainted, running on an ASUSTek 1005HAG
EIP is at btrfs_add_free_space+0x285/0x39a [btrfs]



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

Bug#624131: linux-image-2.6.39-rc4-686-pae: Can somewhat reliably produce kernel panic in btrfs code

[Maik Zumstrull]

On Mon, Apr 25, 2011 at 22:15, Ben Hutchings b...@decadent.org.uk wrote:
 On Mon, 2011-04-25 at 22:05 +0200, Maik Zumstrull wrote:

 By simply stressing the system with some I/O, I can make it crash within
 seconds. I'm not setting a higher severity because the bug is in an
 experimental file system in an experimental kernel.

 I assume this doesn't happen in 2.6.38?

Not that I've noticed. I don't use that netbook much, but given how
quickly it happens with .39, I say I would have noticed.

 Here's the important bits (by my guess) I have on screen from the kernel 
 panic:

 Bug at fs/btrfs/free-space-cache.c:1246
 Bug type: invalid opcode: 
 Kernel not tainted, running on an ASUSTek 1005HAG
 EIP is at btrfs_add_free_space+0x285/0x39a [btrfs]

 You will probably need to provide a more complete copy of the panic
 message.

I thought as much, but other than taking a picture of the screen, I
don't know how. I am prepared to cooperate fully in the debugging
effort, though. :-) You or they can tell me what is required.



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

Bug#621754: fcgiwrap: Should set USER and HOME correctly or not at all

[Maik Zumstrull]

Package: fcgiwrap
Version: 1.0.3-3
Severity: normal

Right now, with a minimal test script I'm seeing in the environment,
among other things:

HOME=/root
LOGNAME=root
MAIL=/var/mail/root
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
USERNAME=root
USER=root

Of course, the script is not actually running as root. I suggest that
these variables should either be set correctly (corresponding to
FCGI_USER) or unset.



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

Bug#616552: fcgiwrap: Should have settings FCGI_SOCKET_OWNER / FCGI_SOCKET_GROUP

[Maik Zumstrull]

On Fri, Apr 1, 2011 at 20:09, Jordi Mallach jo...@debian.org wrote:
 On Wed, Mar 30, 2011 at 10:31:10PM +0200, Maik Zumstrull wrote:
 Just looked over it again, and actually, it's not right.

 This part is off:

 # Socket owner/group (defaults to FCGI_USER/FCGI_GROUP if not defined)
 FCGI_SOCKET_OWNER=www-data
 FCGI_SOCKET_GROUP=www-data

 Actually, my intention was to have that as a commented example, ie
 #FCGI_SOCKET_OWNER=someuser

 I uncommented it, defaulting to www-data, because I feared it'd make
 people edit the init script instead of the default file to modify this.

I'm okay with the default being www-data instead of $FCGI_USER. It's
actually more useful, I suspect. You should just make sure the
documentation matches whatever you decide.



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

Bug#616552: fcgiwrap: Should have settings FCGI_SOCKET_OWNER / FCGI_SOCKET_GROUP

[Maik Zumstrull]

On Wed, Mar 30, 2011 at 19:12, Jordi Mallach jo...@debian.org wrote:
 Hi Maik!

 On Sat, Mar 05, 2011 at 02:31:36PM +0100, Maik Zumstrull wrote:
 These would correspond to spawn-fcgi's -U and -G options. At the moment,
 you set these the same as -u/-g. To run scripts as a different user than
 the webserver, the needed configuration is:
 -u someuser -g someuser -U www-data -G www-data

 These extra options, set by default to be the same as FCGI_USER /
 FCGI_GROUP, would easily allow that.

 Would you mind having a look at
 http://svn.debian.org/viewsvn/collab-maint/deb-maint/fcgiwrap/trunk/debian/init?revision=18335

 to see if this is what you're looking for?

That's pretty close to what I'm already using, yes. Thanks.



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

Bug#616552: fcgiwrap: Should have settings FCGI_SOCKET_OWNER / FCGI_SOCKET_GROUP

[Maik Zumstrull]

 Would you mind having a look at
 http://svn.debian.org/viewsvn/collab-maint/deb-maint/fcgiwrap/trunk/debian/init?revision=18335

 to see if this is what you're looking for?

 That's pretty close to what I'm already using, yes. Thanks.

Just looked over it again, and actually, it's not right.

This part is off:

# Socket owner/group (defaults to FCGI_USER/FCGI_GROUP if not defined)
FCGI_SOCKET_OWNER=www-data
FCGI_SOCKET_GROUP=www-data

The settings contradict the comment. Instead, you should do something like

FCGI_SOCKET_OWNER=${FCGI_SOCKET_OWNER:-$FCGI_USER}
FCGI_SOCKET_GROUP=${FCGI_SOCKET_GROUP:-$FCGI_GROUP}

after you read the user configuration from /etc/default.

Sorry I didn't catch this the first time.



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

Bug#617800: Please commit to maintaining unbound in squeeze-updates or -backports

[Maik Zumstrull]

Package: unbound
Severity: wishlist

Since DNSsec is just now being somewhat widely deployed, significant
bugs in DNS implementation pop up at an increased rate at the moment.
For example, both unbound 1.4.7 and 1.4.8 consider validation fixes
related to CNAMEs, and support for the (quasi-mandatory) GOST suite of
algorithms.

In my opinion, it's important to get DNS resolver updates deployed
quickly during this phase, even when they are not classical security
problems.

For this reason, I ask that you consider unbound for one or both of the
accelerated update cycles available for the stable squeeze release,
squeeze-updates and squeeze-backports.



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

Bug#616551: fcgiwrap: DAEMON_OPTS are never actually passed to the daemon

[Maik Zumstrull]

Package: fcgiwrap
Version: 1.0.3-1
Severity: normal

Should be easy to fix.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages fcgiwrap depends on:
ii  libc6 2.11.2-11  Embedded GNU C Library: Shared lib
ii  libfcgi0ldbl  2.4.0-8Shared library of FastCGI
ii  spawn-fcgi1.6.3-1A fastcgi process spawner

fcgiwrap recommends no packages.

fcgiwrap 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#616552: fcgiwrap: Should have settings FCGI_SOCKET_OWNER / FCGI_SOCKET_GROUP

[Maik Zumstrull]

Package: fcgiwrap
Version: 1.0.3-1
Severity: wishlist

These would correspond to spawn-fcgi's -U and -G options. At the moment,
you set these the same as -u/-g. To run scripts as a different user than
the webserver, the needed configuration is:
-u someuser -g someuser -U www-data -G www-data

These extra options, set by default to be the same as FCGI_USER /
FCGI_GROUP, would easily allow that.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages fcgiwrap depends on:
ii  libc6 2.11.2-11  Embedded GNU C Library: Shared lib
ii  libfcgi0ldbl  2.4.0-8Shared library of FastCGI
ii  spawn-fcgi1.6.3-1A fastcgi process spawner

fcgiwrap recommends no packages.

fcgiwrap 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#610750: cryptsetup: decrypt_keyctl script needs an initramfs hook to pull in /bin/keyctl

[Maik Zumstrull]

Package: cryptsetup
Version: 2:1.1.3-4
Severity: normal

See subject. Additionally, the key script should fall back to unlocking
just a single device at a time if keyctl doesn't work for any reason. I'd
rather enter the passphrase several times than be left with an
unbootable system. Speaking of an unbootable system, that possibility might
technically qualify this bug for critical. I'm not setting it myself,
but please consider it.

-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=/dev/mapper/cryptroot ro quiet ip=dhcp

-- System Information:
Debian Release: 6.0
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages cryptsetup depends on:
ii  dmsetup  2:1.02.48-4 The Linux Kernel Device Mapper use
ii  libc62.11.2-7Embedded GNU C Library: Shared lib
ii  libdevmapper1.02.1   2:1.02.48-4 The Linux Kernel Device Mapper use
ii  libpopt0 1.16-1  lib for parsing cmdline parameters
ii  libuuid1 2.17.2-5Universally Unique ID library

cryptsetup recommends no packages.

Versions of packages cryptsetup suggests:
ii  busybox   1:1.17.1-8 Tiny utilities for small and embed
ii  dosfstools3.0.9-1utilities for making and checking 
ii  initramfs-tools [linux-initra 0.98.7 tools for generating an initramfs
ii  udev  164-3  /dev/ and hotplug management daemo

-- 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#585568: Late devices

[Maik Zumstrull]

In my opinion, this bug should be upgraded from wishlist and retitled.
There is a real need to scan for btrfs filesystems later than at the
initramfs stage, because of devices that don't exist yet at that
point. That includes not only actual hotplugging of the hardware, but
also late-open cryptsetup and lvm devices, and other things that come
up late like network block devices or complex HW-RAID setups. As a
specific example, two-disk btrfs over dm-crypt fails mount -a even
with initramfs, because the dm-crypt devices don't exist during the
first and only scan.
Initrd-less boot should be supported as a side effect if you have udev
trigger btrfs device scan.



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

Bug#606124: lvm2: Should have an easy way to persistently set device owner/group/permissions

[Maik Zumstrull]

Package: lvm2
Version: 2.02.66-4
Severity: wishlist

As far as I can see, all lvm2 block devices are owned by root:disk and 0660 and
there is no easy way to change it. chown/chmod is lost on reboot when udev
recreates the node. Writing your own udev rules is very iffy, as you would need
a thorough understanding of how Debian orders the rules and includes them in
initramfs.

The primary case where I would like to do this is virtualization. The VM needs
to be able to access block devices exported to the guest, but I don't think the
virtualization user should just be a member of disk, as it doesn't need to
access all devices.

I think lvcreate should have simple options for owner, group and permissions,
with the current situation as the default when not specified, and the necessary
udev magic to make the settings stick across reboots.



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages lvm2 depends on:
ii  dmsetup  2:1.02.48-4 The Linux Kernel Device Mapper use
ii  libc62.11.2-7Embedded GNU C Library: Shared lib
ii  libdevmapper1.02.1   2:1.02.48-4 The Linux Kernel Device Mapper use
ii  libreadline5 5.2-7   GNU readline and history libraries
ii  libudev0 164-2   libudev shared library
ii  lsb-base 3.2-23.1Linux Standard Base 3.2 init scrip

lvm2 recommends no packages.

lvm2 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#606124: lvm2: Should have an easy way to persistently set device owner/group/permissions

[Maik Zumstrull]

Alasdair G Kergon wrote:

 On Mon, Dec 06, 2010 at 04:29:57PM +0100, Maik Zumstrull wrote:
  As far as I can see, all lvm2 block devices are owned by root:disk
  and 0660 and there is no easy way to change it. chown/chmod is lost
  on reboot when udev recreates the node. Writing your own udev rules
  is very iffy, as you would need a thorough understanding of how
  Debian orders the rules and includes them in initramfs.
  
 Upstream provides straightforward udev rule templates with examples
 showing how to do this.

Yeah, it's not that straightforward. I did fiddle with udev rules, and
got it to the point that it works when manually
re-triggering /dev/dm-*, but not on reboot. It has to have to do with
the way initramfs-tools (which is a Debian thing) includes rules in the
initrd image. I could probably get it to work if I spent more time on
it, but even with what I already tried, it's way to complicated for a
requirement as basic as access permissions. There needs to be an
actually straightforward way to do this.

  I think lvcreate should have simple options for owner, group and
  permissions, with the current situation as the default when not
  specified, and the necessary udev magic to make the settings stick
  across reboots.
  
 There are no plans to do this upstream.

Well, I'm suggesting you make some. That's what wishlist bugs are for,
I believe. It doesn't have to be done this exact way, of course, and I
don't insist on an upstream solution. A Debian-way that is convenient
and reliable would be fine.



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

Bug#605246: Built-in 3G modem can prevent sleep mode

[Maik Zumstrull]

Package: eeepc-acpi-scripts
Version: 1.1.11

On the EeePC 1005HAG, the builtin 3G modem (12d1:1001 Huawei
Technologies Co., Ltd. E620 USB Modem) prevents the device from
staying in sleep mode. It goes to sleep fine, according to the logs,
but immediately wakes up. I suspected that the 3G modem is causing
this, because it seems to work for the models without built-in 3G,
according to various reports out there.

I tried putting the device to sleep after telling the kernel to ignore
USB wakeup requests from the 3G modem, and it works, apparently
without nasty side effects, the 3G still works after. I think
eeepc-acpi-scripts should include a sleep.d hook to do this. It's not
enough to set this once at boot, the flag resets itself when returning
from sleep mode. I've attached my own quick-hack attempt at doing
this, feel free to use it, use it as a template, or discard it and
write your own.


80_3Gmodem
Description: Binary data

Bug#605246: [Debian-eeepc-devel] Bug#605246: Built-in 3G modem can prevent sleep mode

[Maik Zumstrull]

 I tried putting the device to sleep after telling the kernel to ignore
 USB wakeup requests from the 3G modem, and it works, apparently
 without nasty side effects, the 3G still works after. I think
 eeepc-acpi-scripts should include a sleep.d hook to do this.

 A better solution would be to see if this is fixed upstream, and if so,
 backport the fix for the kernel in Squeeze. Would you please try the
 kernel in experimental to see if the problem is resolved there?

Okay, I installed the linux-image-2.6.36-trunk-686-bigmem package
(plus linux-base) and moved my sleep.d hook out of the way. Then I
shut down completely and booted into the new kernel.

The system does stay asleep, so that's fixed. However, after waking
up, the system freezes for a few seconds several times. I didn't see
that with 2.6.32 and hook-disabled wakeup. This seems to go away after
a while, it could be one freeze for each USB device while rebinding it
or something. There are reproducibly (I tested three times) four
freezes, and there are four USB-devices other than root hubs.
According to gnokii --monitor once, the 3G device came back up and
registered with the network.



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

Bug#605246: [Debian-eeepc-devel] Bug#605246: Built-in 3G modem can prevent sleep mode

[Maik Zumstrull]

 Please can you test whether the attached patch fixes our package of
 Linux 2.6.32.  You will need to rebuild the kernel package by following
 the instructions at
 http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official.

On it.



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

Bug#605246: [Debian-eeepc-devel] Bug#605246: Built-in 3G modem can prevent sleep mode

[Maik Zumstrull]

 Please can you test whether the attached patch fixes our package of
 Linux 2.6.32.

The system goes to sleep and doesn't immediately wake up. Good. There
are no freezes as in #605275. Wifi comes back up. 3G needs to be left
alone for a moment (immediate gnokii --monitor once fails), but does
come back (second attempt usually works).



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

Bug#605275: EeePC 1005HAG freezes briefly after resuming

[Maik Zumstrull]

 Well there's nothing obvious there but it looks like the wifi driver
 takes some time to start up again after resuming.  Could you test
 whether this happens if you disable wifi before suspending?

Doesn't help, the freezes are still there. I used the Fn+F2 shortcut
to disconnect. That leaves the wifi-related modules loaded. I then
tried again after rmmoding all wifi-related modules I could find.
Still freezes.



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

Bug#605275: EeePC 1005HAG freezes briefly after resuming

[Maik Zumstrull]

 Please report
 this upstream at https://bugzilla.kernel.org under product 'Drivers',
 component 'USB'.  Let us know the bug number or URL so we can track it.

Reported as:
https://bugzilla.kernel.org/show_bug.cgi?id=23962



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

Bug#600280: XKBOPTIONS=compose:rwin doesn't propagate to X

[Maik Zumstrull]

Julien Pinon wrote:

 Le mardi 23 novembre 2010 à 21:40,
 Cyril Brulebois k...@debian.org écrivait :
 
  If you feel like getting this fixed, find the actual culprit (on the
  gnome side, as suggested by Julien), and reassign it there.
 
 I digged a little  bit, and found that maybe the problem  is the same
 as #590534, and linked to
 https://bugzilla.gnome.org/show_bug.cgi?id=613681

Sounds plausible.

 Knowing if the bug appears only while using gdm3 would help.

I am using gdm3. I think I tried going into a session without going
through gdm and had the same problem. If you'd like me to test something
in a specific way, let me know.

 Anyway, don't you think that the bug is a real one even if not
 belonging to  xserver-xorg-input-keyboard,  and  that  Maik who
 reported  it  (in keyboard-configuration package) was let without
 answer and without hope ?

Thank you for noticing. Since I have a viable workaround (set the same
keyboard layout and options in GNOME as in keyboard-configuration), I
had decided not to reopen and bitch about aggressive bug-closing this
time and just let it go.



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

Bug#602087: flush: Should install a magnet: URL handler

[Maik Zumstrull]

Package: flush
Version: 0.9.6-1
Severity: minor

Subject says all. If you're stumped, see the transmission packaging for
how to do this (eg install a gconf template for GNOME).



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

Bug#600280: keyboard-configuration: Setting a compose key with the debconf question does not set a compose key

[Maik Zumstrull]

Anton Zinoviev wrote:

 On Sun, Oct 24, 2010 at 04:05:18PM +0200, Samuel Thibault wrote:
  
  Maik Zumstrull, le Fri 15 Oct 2010 15:24:47 +0200, a écrit :
   All I know is, I set Right Logo to be Compose with
   dpkg-reconfigure and it didn't work, set it again and it didn't
   work, and rebooted and it still does not work.
  
  That works here. Please provide your /etc/default/keyboard, your
  /etc/X11/xorg.conf if you have one, and the output of setxkbmap
  -print in the X session.

ry...@rz-nethiwi:~/  cat /etc/default/keyboard 
# If you change any of the following variables and HAL and X are
# configured to use this file, then the changes will become visible to
# X only if HAL is restarted.  In Debian you need to run
# /etc/init.d/hal restart

# The following variables describe your keyboard and can have the same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.

XKBMODEL=pc105
XKBLAYOUT=de
XKBVARIANT=nodeadkeys
XKBOPTIONS=compose:rwin

# If you don't want to use the XKB layout on the console, you can
# specify an alternative keymap.  Make sure it will be accessible
# before /usr is mounted.
# KMAP=/etc/console-setup/defkeymap.kmap.gz
ry...@rz-nethiwi:~/  cat /etc/X11/xorg.conf  
cat: /etc/X11/xorg.conf: No such file or directory
ry...@rz-nethiwi:~/  setxkbmap -print
xkb_keymap {
xkb_keycodes  { include evdev+aliases(qwertz) };
xkb_types { include complete  };
xkb_compat{ include complete  };
xkb_symbols   { include pc+de(nodeadkeys)+inet(evdev) };
xkb_geometry  { include pc(pc105) };
};
ry...@rz-nethiwi:~/  

 And please tell us what you think the Compose key should do.

I would expect that if I press
Compose, Shift-2 ( on German keyboard), a
I would get an ä. Instead, I get a (no composition effect).



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

Bug#600280: keyboard-configuration: Setting a compose key with the debconf question does not set a compose key

[Maik Zumstrull]

Samuel Thibault wrote:

 Maik Zumstrull, le Tue 26 Oct 2010 12:45:19 +0200, a écrit :

  XKBMODEL=pc105
  XKBLAYOUT=de
  XKBVARIANT=nodeadkeys
  XKBOPTIONS=compose:rwin

 Mmm, I'm getting +compose(rwin) here with your keyboard
 configuration... Just to make sure keyboard-configuration does its
 job, could
 
 grep XKB /dev/.udev/db/input:event*

/dev/.udev/db/input:event1:E:XKBMODEL=pc105
/dev/.udev/db/input:event1:E:XKBLAYOUT=de
/dev/.udev/db/input:event1:E:XKBVARIANT=nodeadkeys
/dev/.udev/db/input:event1:E:XKBOPTIONS=compose:rwin
/dev/.udev/db/input:event4:E:XKBMODEL=pc105
/dev/.udev/db/input:event4:E:XKBLAYOUT=de
/dev/.udev/db/input:event4:E:XKBVARIANT=nodeadkeys
/dev/.udev/db/input:event4:E:XKBOPTIONS=compose:rwin
/dev/.udev/db/input:event5:E:XKBMODEL=pc105
/dev/.udev/db/input:event5:E:XKBLAYOUT=de
/dev/.udev/db/input:event5:E:XKBVARIANT=nodeadkeys
/dev/.udev/db/input:event5:E:XKBOPTIONS=compose:rwin
/dev/.udev/db/input:event7:E:XKBMODEL=pc105
/dev/.udev/db/input:event7:E:XKBLAYOUT=de
/dev/.udev/db/input:event7:E:XKBVARIANT=nodeadkeys
/dev/.udev/db/input:event7:E:XKBOPTIONS=compose:rwin

 if XKBOPTIONS=compose:rwin shows up,

It does.

 it's really not keyboard-configuration's fault and the bug should be
 reassigned to xserver-xorg-input-keyboard (or possibly something else
 that perturbs it, but maintainers there will know more).

Possibly something GNOME-related, though I haven't asked it to mess
with the keyboard and the default is supposed to be to leave X alone.



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

Bug#600269: vlc: Enqueueing a file to playlist doesn't consider the working directory

[Maik Zumstrull]

Package: vlc
Version: 1.1.4-1
Severity: normal

Assuming you have these:
~/f/foo.avi
~/b/bar.avi

Run:
cd ~/f
vlc --one-instance foo.avi

VLC starts playing foo.avi

Elsewhere, run:
cd ~/b
vlc --playlist-enqueue bar.avi

Problem:
When done with foo.avi, VLC will try (and fail) to play ~/f/bar.avi because the
CWD of the enqueueing VLC call is ignored.



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (800, 'testing'), (500, 'squeeze-volatile'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages vlc depends on:
ii  libaa1 1.4p5-38  ascii art library
ii  libavcodec52   5:0.6~svn20100726-0.1 library to encode decode multimedi
ii  libavutil505:0.6~svn20100726-0.1 avutil shared libraries - runtime 
ii  libc6  2.11.2-6  Embedded GNU C Library: Shared lib
ii  libfreetype6   2.4.2-1   FreeType 2 font engine, shared lib
ii  libfribidi00.19.2-1  Free Implementation of the Unicode
ii  libgcc11:4.4.5-2 GCC support library
ii  libgl1-mesa-glx [l 7.7.1-4   A free implementation of the OpenG
ii  libqtcore4 4:4.6.3-1+b1  Qt 4 core module
ii  libqtgui4  4:4.6.3-1+b1  Qt 4 GUI module
ii  libsdl-image1.21.2.10-2+b2   image loading library for Simple D
ii  libsdl1.2debian1.2.14-6  Simple DirectMedia Layer
ii  libstdc++6 4.4.5-2   The GNU Standard C++ Library v3
ii  libtar 1.2.11-6  C library for manipulating tar arc
ii  libva-x11-11.0.1-3   Video Acceleration (VA) API for Li
ii  libva1 0.31.1-1+sds4 Video Acceleration (VA) API for Li
ii  libvlccore41.1.4-1   base library for VLC and its modul
ii  libx11-6   2:1.3.3-3 X11 client-side library
ii  libx11-xcb12:1.3.3-3 Xlib/XCB interface library
ii  libxcb-keysyms10.3.6-1   utility libraries for X C Binding 
ii  libxcb-randr0  1.6-1 X C Binding, randr extension
ii  libxcb-shm01.6-1 X C Binding, shm extension
ii  libxcb-xv0 1.6-1 X C Binding, xv extension
ii  libxcb11.6-1 X C Binding
ii  libxext6   2:1.1.2-1 X11 miscellaneous extension librar
ii  ttf-freefont   20090104-7Freefont Serif, Sans and Mono True
ii  vlc-nox1.1.4-1   multimedia player and streamer (wi
ii  zlib1g 1:1.2.3.4.dfsg-3  compression library - runtime

Versions of packages vlc recommends:
ii  vlc-plugin-notify 1.1.4-1LibNotify plugin for VLC
pn  vlc-plugin-pulse  none (no description available)

Versions of packages vlc suggests:
ii  mozilla-plugin-vlc1.1.4-1multimedia plugin for web browsers
pn  videolan-doc  none (no description available)

Versions of packages vlc-nox depends on:
ii  liba52-0.7.4   0.7.4-14  library for decoding ATSC A/52 str
ii  libasound2 1.0.23-2  shared library for ALSA applicatio
ii  libass40.9.9-1   library for SSA/ASS subtitles rend
ii  libavahi-client3   0.6.27-2  Avahi client library
ii  libavahi-common3   0.6.27-2  Avahi common library
ii  libavc1394-0   0.5.3-1+b2control IEEE 1394 audio/video devi
ii  libavcodec52   5:0.6~svn20100726-0.1 library to encode decode multimedi
ii  libavformat52  5:0.6~svn20100726-0.1 ffmpeg file format library
ii  libavutil505:0.6~svn20100726-0.1 avutil shared libraries - runtime 
ii  libc6  2.11.2-6  Embedded GNU C Library: Shared lib
ii  libcaca0   0.99.beta17-1 colour ASCII art library
ii  libcddb2   1.3.2-2   library to access CDDB data - runt
ii  libcdio10  0.81-4library to read and control CD-ROM
ii  libdbus-1-31.2.24-3  simple interprocess messaging syst
ii  libdc1394-22   2.1.2-3   high level programming interface f
ii  libdca00.0.5-3   decoding library for DTS Coherent 
ii  libdirac-encoder0  1.0.2-3   open and royalty free high quality
ii  libdvbpsi6 0.1.7-1   library for MPEG TS and DVB PSI ta
ii  libdvdnav4 4.1.3-7   DVD navigation library
ii  libdvdread44.1.3-10  library for reading DVDs
ii  libebml0   0.7.7-3.1 access library for the EBML format
ii  libfaad2   2.7-4 freeware Advanced Audio Decoder - 
ii  libflac8   1.2.1-2+b1Free Lossless Audio Codec - runtim
ii  

Bug#600280: keyboard-configuration: Setting a compose key with the debconf question does not set a compose key

[Maik Zumstrull]

Package: keyboard-configuration
Version: 1.56
Severity: normal

The subject will mostly have to do, because I don't understand the keyboard
setup stuff anywhere near well enough to have any idea what's going wrong. All
I know is, I set Right Logo to be Compose with dpkg-reconfigure and it didn't
work, set it again and it didn't work, and rebooted and it still does not work.
I've made sure to set GNOME to not touch the X server keyboard settings, but I
can't promise that it doesn't fiddle with them anyway.



-- System Information:
Debian Release: squeeze/sid
  APT prefers squeeze-volatile
  APT policy: (500, 'squeeze-volatile'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages keyboard-configuration depends on:
ii  debconf [debconf-2.0] 1.5.35 Debian configuration management sy

keyboard-configuration recommends no packages.

keyboard-configuration suggests no packages.

-- debconf-show failed



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

Bug#587792: Please compile with --enable-vaapi

[Maik Zumstrull]

Package: vlc
Version: 1.1.0-1

Since version 1.1.0, VLC supports hardware-accelerated video decoding
through VA-API. The required library is already in Debian and should
fail gracefully if no hardware accelerator is available. Please consider
switching this feature on for the next upload.



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

Bug#585850: claws-mail: forces creation of Queue folder on IMAP even if it's not used

[Maik Zumstrull]

Package: claws-mail
Version: 3.7.6-1
Severity: normal

I have moved the queue folder to a local Maildir while creating the 
account because I don't want it on the IMAP server. I have verified that 
this setting took, it actually uses the local Maildir, not the Queue 
folder on the Server.

Yet, Claws Mail aggressively insisits that Queue exist on IMAP. I 
cannot manually set that folder to a type other than Queue. I cannot 
delete that folder from within Claws Mail. If I delete it on the server 
and rebuild the folder tree, Claws Mail just recreates it.

Again, and I want to stress that: this folder *is not used*.
And Claws Mail *knows that*.

I recommend the following changes:

1) Check if the Queue folder would be used before creating it
2) Allow a Queue folder to be deleted if it is not used

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-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 claws-mail depends on:
ii  libc62.10.2-9Embedded GNU C Library: Shared lib
ii  libcairo21.8.10-4The Cairo 2D vector graphics libra
ii  libcompfaceg11:1.5.2-5   Compress/decompress images for mai
ii  libdbus-glib-1-2 0.86-1  simple interprocess messaging syst
ii  libenchant1c2a   1.4.2-3.6   a wrapper library for various spel
ii  libetpan13   0.58-1  mail handling library
ii  libgcrypt11  1.4.5-2 LGPL Crypto library - runtime libr
ii  libglib2.0-0 2.24.1-1The GLib library of C routines
ii  libgnutls26  2.8.6-1 the GNU TLS library - runtime libr
ii  libgtk2.0-0  2.20.1-1The GTK+ graphical user interface 
ii  libice6  2:1.0.6-1   X11 Inter-Client Exchange library
ii  libldap-2.4-22.4.17-2.1  OpenLDAP libraries
ii  libpango1.0-01.28.0-1Layout and rendering of internatio
ii  libpisock9   0.12.5-2library for communicating with a P
ii  libsm6   2:1.1.1-1   X11 Session Management library
ii  xdg-utils1.0.2+cvs20100307-1 desktop integration utilities from

Versions of packages claws-mail recommends:
ii  aspell-de [aspell-dictionar 20091006-4.1 German dictionary for aspell
ii  aspell-en [aspell-dictionar 6.0-0-6  English dictionary for GNU Aspell
ii  claws-mail-i18n 3.7.6-1  Locale data for Claws Mail (i18n s
ii  xfonts-100dpi   1:1.0.1  100 dpi fonts for X

Versions of packages claws-mail suggests:
pn  claws-mail-doc  none   (no description available)
pn  claws-mail-toolsnone   (no description available)
ii  gedit   2.30.2-1 official text editor of the GNOME 
ii  lynx-cur [www-browser]  2.8.8dev.3-3 Text-mode WWW Browser with NLS sup

-- 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#585541: libxml-libxml-perl: Setting recover = 2 doesn't shut up the HTML loader

[Maik Zumstrull]

Package: libxml-libxml-perl
Version: 1.70.ds-1
Severity: normal

If I understand the documentation correctly,

perl -MXML::LibXML -e 'XML::LibXML-load_html(location =
http://www.yahoo.de/;, recover = 2);'

should be completely silent (the page is parseable with warnings). It is not,
the parser warnings are printed to STDERR.

I suspect the error suppression flags are set only for the XML loader, not or
not correctly for the HTML loader.



-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-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 libxml-libxml-perl depends on:
ii  libc6   2.10.2-9 Embedded GNU C Library: Shared lib
ii  libxml-namespacesupport 1.09-3   Perl module for supporting simple 
ii  libxml-sax-perl 0.96+dfsg-2  Perl module for using and building
ii  libxml2 2.7.7.dfsg-2 GNOME XML library
ii  perl5.10.1-13Larry Wall's Practical Extraction 
ii  perl-base [perlapi-5.10 5.10.1-13minimal Perl system
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

libxml-libxml-perl recommends no packages.

libxml-libxml-perl 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#585544: reportbug: exits without explanation if python-gtkspell is not installed

[Maik Zumstrull]

Package: reportbug
Version: 4.12.2
Severity: normal

reportbug suggests python-gtk2 and python-gtkspell, and the GTK UI needs both
to function. If python-gtk2 is installed and python-gtkspell is not (the
dependencies allow this), the GTK UI starts and the first few dialog pages
work, but when it tries to create the first page with a spell-checked text
entry field, it exits with no visible message. I'm not sure this can be fixed
with dependencies (it would need a conditional dependency like if python-gtk2
is installed, which is optional, then depend on python-gtkspell), but an error
message would be nice.



-- Package-specific info:
** Environment settings:
INTERFACE=gtk2

** /home/ry177/.reportbugrc:
reportbug_version 4.12.2
mode advanced
ui gtk2
email maik.zumstr...@rz.uni-karlsruhe.de
http_proxy http://proxy.rz.uni-karlsruhe.de:3128/;

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-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 reportbug depends on:
ii  apt   0.7.25.3   Advanced front-end for dpkg
ii  python2.5.4-9An interactive high-level object-o
ii  python-reportbug  4.12.2 Python modules for interacting wit

reportbug recommends no packages.

Versions of packages reportbug suggests:
ii  debconf-utils1.5.32  debconf utilities
ii  debsums  2.0.48+nmu1 tool for verification of installed
pn  dlocate  none  (no description available)
pn  emacs22-bin-common | none  (no description available)
ii  exim44.71-4  metapackage to ease Exim MTA (v4) 
ii  exim4-daemon-light [ 4.71-4  lightweight Exim MTA (v4) daemon
ii  file 5.04-2  Determines file type using magic
ii  gnupg1.4.10-4GNU privacy guard - a free PGP rep
ii  python-gtk2  2.17.0-2Python bindings for the GTK+ widge
ii  python-gtkspell  2.25.3-4.1+b3   Python bindings for the GtkSpell l
pn  python-urwid none  (no description available)
ii  python-vte   1:0.24.1-1  Python bindings for the VTE widget
ii  xdg-utils1.0.2+cvs20100307-1 desktop integration utilities from

-- 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#585544: reportbug: exits without explanation if python-gtkspell is not installed

[Maik Zumstrull]

Sandro Tosi wrote:

 I don't have python-gtkspell installed, but I can use GTK+ UI without
 a problem, so I suspect something else is going on here.
 
 Can you launch
 
 $ reportbug --ui=gtk2
 
 from a terminal, generate the error and report the message displayed
 on the terminal?

Take your pick:

ry...@rz-nethiwi:~$ reportbug
ry...@rz-nethiwi:~$ reportbug
ry...@rz-nethiwi:~$ reportbug
*** glibc detected *** /usr/bin/python: double free or corruption (fasttop): 
0x7fb8c402d2a0 ***
=== Backtrace: =
/lib/libc.so.6[0x7fb8dc27fe96]
/lib/libc.so.6(cfree+0x6c)[0x7fb8dc284b3c]
/usr/lib/libgdk-x11-2.0.so.0(gdk_region_union+0x97)[0x7fb8d10bf6c7]
/usr/lib/libgdk-x11-2.0.so.0[0x7fb8d10cd411]
/usr/lib/libgdk-x11-2.0.so.0[0x7fb8d10cdab3]
/usr/lib/libgdk-x11-2.0.so.0[0x7fb8d10cdb8e]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0xa9)[0x7fb8d2d3d3c9]
/usr/lib/libgobject-2.0.so.0[0x7fb8d2d52cc1]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7e6)[0x7fb8d2d54a76]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83)[0x7fb8d2d54fc3]
/usr/lib/libgtk-x11-2.0.so.0[0x7fb8d14d6d9e]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0xa9)[0x7fb8d2d3d3c9]
/usr/lib/libgobject-2.0.so.0[0x7fb8d2d52cc1]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7e6)[0x7fb8d2d54a76]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83)[0x7fb8d2d54fc3]
/usr/lib/libgtk-x11-2.0.so.0[0x7fb8d13c552b]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x15e)[0x7fb8d2d3d47e]
/usr/lib/libgobject-2.0.so.0[0x7fb8d2d52cc1]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7e6)[0x7fb8d2d54a76]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83)[0x7fb8d2d54fc3]
/usr/lib/libgtk-x11-2.0.so.0(gtk_widget_set_child_visible+0xeb)[0x7fb8d1596feb]
/usr/lib/libgtk-x11-2.0.so.0[0x7fb8d13bdf33]
/usr/lib/libgtk-x11-2.0.so.0[0x7fb8d13be02b]
/usr/lib/libgtk-x11-2.0.so.0[0x7fb8d13bec0c]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x15e)[0x7fb8d2d3d47e]
/usr/lib/libgobject-2.0.so.0[0x7fb8d2d533f7]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7e6)[0x7fb8d2d54a76]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83)[0x7fb8d2d54fc3]
/usr/lib/libgtk-x11-2.0.so.0[0x7fb8d13ce235]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x15e)[0x7fb8d2d3d47e]
/usr/lib/libgobject-2.0.so.0[0x7fb8d2d52cc1]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7e6)[0x7fb8d2d54a76]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83)[0x7fb8d2d54fc3]
/usr/lib/libgtk-x11-2.0.so.0[0x7fb8d13ccf3d]
/usr/lib/libgtk-x11-2.0.so.0[0x7fb8d1479c08]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x15e)[0x7fb8d2d3d47e]
/usr/lib/libgobject-2.0.so.0[0x7fb8d2d53040]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x62d)[0x7fb8d2d548bd]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83)[0x7fb8d2d54fc3]
/usr/lib/libgtk-x11-2.0.so.0[0x7fb8d158ff6f]
/usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0xc3)[0x7fb8d14720f3]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x2eb)[0x7fb8d14731ab]
/usr/lib/libgdk-x11-2.0.so.0[0x7fb8d10e73bc]
/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1f2)[0x7fb8d26866c2]
/lib/libglib-2.0.so.0[0x7fb8d268a538]
/lib/libglib-2.0.so.0(g_main_loop_run+0x195)[0x7fb8d268aa45]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x7fb8d1473647]
/usr/lib/pymodules/python2.5/gtk-2.0/gtk/_gtk.so[0x7fb8d1afb826]
/usr/bin/python(PyEval_EvalFrameEx+0x5048)[0x48fc18]
/usr/bin/python(PyEval_EvalFrameEx+0x5f06)[0x490ad6]
=== Memory map: 
0040-00522000 r-xp  00:0f 18430  
/usr/bin/python2.5
00721000-00753000 rw-p 00121000 00:0f 18430  
/usr/bin/python2.5
00753000-0075b000 rw-p  00:00 0 
0245c000-0377e000 rw-p  00:00 0  [heap]
7fb8c109a000-7fb8c400 r--p  00:0f 299740 
/usr/share/icons/gnome/icon-theme.cache
7fb8c400-7fb8c4047000 rw-p  00:00 0 
7fb8c4047000-7fb8c800 ---p  00:00 0 
7fb8c9b91000-7fb8c9ba7000 r-xp  00:0f 6252   
/lib/libgcc_s.so.1
7fb8c9ba7000-7fb8c9da6000 ---p 00016000 00:0f 6252   
/lib/libgcc_s.so.1
7fb8c9da6000-7fb8c9da7000 rw-p 00015000 00:0f 6252   
/lib/libgcc_s.so.1
7fb8c9da7000-7fb8c9f88000 r--p  00:0f 312447 
/usr/share/icons/hicolor/icon-theme.cache
7fb8c9f88000-7fb8c9f8c000 r-xp  00:0f 18391  
/usr/lib/python2.5/lib-dynload/zlib.so
7fb8c9f8c000-7fb8ca18c000 ---p 4000 00:0f 18391  
/usr/lib/python2.5/lib-dynload/zlib.so
7fb8ca18c000-7fb8ca18e000 rw-p 4000 00:0f 18391  
/usr/lib/python2.5/lib-dynload/zlib.so
7fb8ca18e000-7fb8ca193000 r-xp  00:0f 166768 
/lib/libnss_dns-2.10.2.so
7fb8ca193000-7fb8ca392000 ---p 5000 00:0f 166768 
/lib/libnss_dns-2.10.2.so
7fb8ca392000-7fb8ca393000 r--p 4000 00:0f 166768 
/lib/libnss_dns-2.10.2.so
7fb8ca393000-7fb8ca394000 rw-p 5000 

Bug#568363: Timing issue in /etc/network/if-pre-up.d/vde2

[Maik Zumstrull]

Package: vde2
Version: 2.2.2-3
Severity: normal

On this system, I noticed that a vde interface fails to come
up at boot, but ifup/ifdown by hand works when the system
is running.

I found that this is a timing issue. ifup starts the switch
process, then fires off an ifconfig, but occasionally the tap
interface has not been created yet at that point and ifconfig
fails. Afterwards, the tap is created, so you end up with
a switch process running and an unconfigured interface.

On my system, I choose the dirty fix of putting a sleep 2
after start-stop-daemon in the vde2 script. The clean solution
would be to have vde_switch not background itself until the
tap interface exists.

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (600, 'stable'), (400, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-bpo.2-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/bash

Versions of packages vde2 depends on:
ii  adduser 3.110add and remove users and groups
ii  libc6   2.7-18lenny2 GNU C Library: Shared libraries
ii  libpcap0.8  0.9.8-5  system interface for user-level pa
ii  libvdemgmt0 2.2.2-3  Virtual Distributed Ethernet - Man
ii  libvdeplug2 2.2.2-3  Virtual Distributed Ethernet - Plu

vde2 recommends no packages.

Versions of packages vde2 suggests:
pn  kvm   none (no description available)
pn  qemu  none (no description available)
pn  vde2-cryptcab none (no description available)

-- 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#566862: nginx: Initscript should not depend on $all

[Maik Zumstrull]

Package: nginx
Version: 0.7.64-2

Currently, /etc/init.d/nginx specifies:

# Provides:  nginx
# Required-Start:$all
# Required-Stop: $all

I don't believe it's actually true that nginx needs every other
service to be running before it starts or stops, and an $all dependency
means that noone else may depend on nginx. (insserv doesn't allow
indirect dependencies on $all.)

I suggest that this dependency is reduced, probably to $remote_fs or
$remote_fs $time.



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

Bug#554635: fglrx-glx: Should install XvBA (video decoding acceleration) library files

[Maik Zumstrull]

Package: fglrx-glx
Version: 1:9-10-1
Severity: normal

Software is now available to use AMD's proprietary
video decoding acceleration API, XvBA.

I have confirmed on a test system that this works, however,
it requires a few library files that the Debian package
currently ignores (they're in the source package, but don't
get installed).

I copied them manually on my system like this:

-rwxr--r-- 1 root root  316240  3. Nov 23:06 /usr/lib/libAMDXvBA.cap
lrwxrwxrwx 1 root root  17  3. Nov 23:06 /usr/lib/libAMDXvBA.so.1 - 
libAMDXvBA.so.1.0
-rwxr--r-- 1 root root 1979560  3. Nov 23:06 /usr/lib/libAMDXvBA.so.1.0
lrwxrwxrwx 1 root root  15  3. Nov 23:06 /usr/lib/libXvBAW.so.1 - 
libXvBAW.so.1.0
-rwxr--r-- 1 root root   12120  3. Nov 23:06 /usr/lib/libXvBAW.so.1.0

I can confirm that XvBA works if the files are installed
like that, however, I'm not sure if this is the directory
AMD intends them to be in.

Please amend the fglrx-driver source package to get these
files installed. I'm filing the bug against fglrx-glx
because I think that's the one these files should be in,
but the fglrx-driver binary package is also an option.

Note that these files alone are not enough to make XvBA work;
additional software packages are required that are not
currently available in Debian (libva, libva-driver-xvba,
patched mplayer). Installing these files with the fglrx
driver is, however, the first step to make it work.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (600, 'testing'), (400, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-2-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 fglrx-glx depends on:
ii  fglrx-driver  1:9-10-1   non-free AMD/ATI r6xx - r7xx displ
ii  libc6 2.9-25 GNU C Library: Shared libraries
ii  libxext6  2:1.0.4-1  X11 miscellaneous extension librar

fglrx-glx recommends no packages.

fglrx-glx 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#544155: please test this GRUB snapshot

[Maik Zumstrull]

Robert Millan wrote:

 Here's a fixed build.  Please confirm it's working and we'll get this
 fix merged ASAP.
 
   http://people.debian.org/~rmh/ati/dacfix/

Sorry, but no. This falls back to text mode, with unaligned pointers.



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

Bug#544155: please test this GRUB snapshot

[Maik Zumstrull]

Robert Millan wrote:

 On Thu, Sep 10, 2009 at 01:36:41AM +0200, Robert Millan wrote:
  
  Here's a fixed build.  Please confirm it's working and we'll get
  this fix merged ASAP.
  
http://people.debian.org/~rmh/ati/dacfix/
 
 Second attempt:
 
   http://people.debian.org/~rmh/ati/dacfix2/

Still not fixed. Shows an out of range pointer instead of an
unaligned pointer though, so maybe that's an improvement.



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

Bug#544155: please test this GRUB snapshot

[Maik Zumstrull]

Robert Millan wrote:

 On Thu, Sep 10, 2009 at 03:13:29PM +0200, Robert Millan wrote:
  On Thu, Sep 10, 2009 at 01:36:41AM +0200, Robert Millan wrote:
   
   Here's a fixed build.  Please confirm it's working and we'll get
   this fix merged ASAP.
   
 http://people.debian.org/~rmh/ati/dacfix/
  
  Second attempt:
  
http://people.debian.org/~rmh/ati/dacfix2/
 
 Again...
 
   http://people.debian.org/~rmh/ati/dacfix3/

Still broken, not noticably different.



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

Bug#544155: please test this GRUB snapshot

[Maik Zumstrull]

Robert Millan wrote:

 On Thu, Sep 10, 2009 at 09:31:44PM +0200, Maik Zumstrull wrote:
  
  Still broken, not noticably different.
 
 There we go again:
 
   http://people.debian.org/~rmh/ati/dacfix4/

Improvement.

It successfully enters gfxterm, console commands including vbeinfo work
in graphical mode, and it can successfully boot a kernel from graphical
mode.

However, the gfxterm console is insanely slow. You can literally watch
it redraw the screen from top to bottom every time the console scrolls
by one line. This isn't necessary a bug, maybe grub's framebuffer
terminal implementation is slow by design, but it is barely usable this
way. I plan to use it with GRUB_TERMINAL=console anyway, though, so I
don't personally care very much about this.



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

Bug#544155: please test this GRUB snapshot

[Maik Zumstrull]

Robert Millan wrote:

 On Wed, Sep 09, 2009 at 01:58:13AM +0200, Witold Baryluk wrote:
  Dnia 2009-09-08, wto o godzinie 22:55 +0200, Robert Millan pisze:
   Please test:
   
 http://people.debian.org/~rmh/ati/2464/
   
  It works correctly here.
 
 Thanks.  Then please test:
 
   http://people.debian.org/~rmh/ati/2476/
 
 (Maik, please confirm 2464 works as well)

2464 works.

2476 is badly broken. The package has trouble even installing, and
after manually interfering, the actual grub fails, too. Can't go into
graphical mode, can't boot, unaligned pointer.



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

Bug#544155: please test this GRUB snapshot

[Maik Zumstrull]

Robert Millan wrote:

  2476 is badly broken. The package has trouble even installing, and
  after manually interfering, the actual grub fails, too. Can't go
  into graphical mode, can't boot, unaligned pointer.
 
 Great, just as I expected.  Please try this one now:
 
   http://people.debian.org/~rmh/ati/2476-minus-dac/
 
 If 2476 fails but 2476-minus-dac works, then it's definitely the DAC
 commit.

Good news then, because 2476-minus-dac works. The packaging is still
broken, but after manual intervention, the bootloader itself works fine.



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

Bug#544155: please test this GRUB snapshot

[Maik Zumstrull]

Robert Millan wrote:

 Ok, can you try this one as well?  Just to be sure 1.97~beta2-2 works
 fine for you once DAC calls are removed.
 
   http://people.debian.org/~rmh/ati/nodac/

It seems to work okay. Thanks for your efforts.



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

Bug#544155: please test this GRUB snapshot

[Maik Zumstrull]

Robert Millan wrote:

 Ok.  Please try:
 
   http://people.debian.org/~rmh/ati/2392/

Still works.



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

Bug#544155: please test this GRUB snapshot

[Maik Zumstrull]

Robert Millan wrote:

 Ok.  Please test:
 
   http://people.debian.org/~rmh/ati/2440/

20090721 works, 20090808 fails. I switched between the two a couple of
times to make sure. Seems it's pretty well narrowed down now. :-)



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

Bug#544155: please test this GRUB snapshot

[Maik Zumstrull]

Robert Millan wrote:

 Still down.  I guess I'll be your snapshots.debian.net today.

:-)

 Here's the first one:
 
   http://people.debian.org/~rmh/ati/2106/

I'm sorry, my T43p is fairly old (2005 model). Its Pentium M processor
is strictly i686, not amd64 compatible.



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