Bug#291911: workaround for missing e2fsadm for lvm2: remove package lvm10

[ingo]

Got the same error:

# lvextend -L +16.8G -r -v /dev/smvg/movies
Finding volume group smvg
  Rounding up size to full physical extent 16.80 GB
Executing: fsadm check /dev/smvg/movies (null)
  fsadm: execlp failed: No such file or directory
  fsadm failed: 2

Even without using the -r option.
Workaround for me was to:

Remove package lvm10 (while leaving configuration files)

Then redo:
# lvextend -L +16.8G -v /dev/smvg/movies
Finding volume group smvg
  Rounding up size to full physical extent 16.80 GB
Archiving volume group "smvg" metadata.
  Extending logical volume movies to 316.80 GB
Creating volume group backup "/etc/lvm/backup/smvg"
Found volume group "smvg"
Found volume group "smvg"
Loading smvg-movies
  Logical volume movies successfully resized
# e2fsck -f /dev/smvg/movies
e2fsck 1.37 (21-Mar-2005)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/smvg/movies: 951/307200 files (6.2% non-contiguous), 39875158/78643200 
blocks
# resize2fs /dev/smvg/movies 332188876K
resize2fs 1.37 (21-Mar-2005)
Resizing the filesystem on /dev/smvg/movies to 83047219 (4k) blocks.
The filesystem on /dev/smvg/movies is now 83047219 blocks long.


The lvm10 package got installed while webmin-lvm package was installed. Thought 
I might try a web based system configuration tool for a change and immediately 
regretted it :o)


I'm working with Debian "testing", package versions:
lvm-common 1.5.17
lvm10  1-1.0.8-8  (now removed)
lvm2   2.01.04-5




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#396115: ion3: crash in 3ds-20061020 with tiling_placement_alt handler

[ingo]

Package: ion3
Version: 20061020-1
Severity: normal


I had a crash while toying around with the new tiling_placement_alt handler.

It can be reproduced with the debian package ion3_20061020-1_i386.deb:

- commenting out mod_statusbar (quite strange)

- executing the following code at the lua prompt

  ioncore.get_hook("tiling_placement_alt"):add(function(tbl) return false end)

- open a new window (eg. F2)

My idea was that returning false from the handler should behave as if
the handler was not there.


regards, ingo



here follows the backtrace:

obj_cast (obj=0xc, descr=0x8081a28) at obj.c:104
104 obj.c: No such file or directory.
in obj.c
(gdb) bt
#0  obj_cast (obj=0xc, descr=0x8081a28) at obj.c:104
#1  0xb7c2ac47 in placement_mrsh_extl (fn=19, param=0xbfb0b2bc) at 
placement.c:64
#2  0x080735f5 in hook_call_alt (hk=0x812b270, p=0xbfb0b2bc, m=0x8073569 
, em=0xb7c2ab70 ) at hooks.c:373
#3  0x080736b9 in hook_call_alt_p (hk=0x812b270, p=0xbfb0b2bc, em=0xb7c2ab70 
) at hooks.c:416
#4  0xb7c2aad2 in tiling_prepare_manage (ws=0x80e7880, cwin=0x814d4b0, 
mp=0xbfb0b534, redir=0) at placement.c:90
#5  0x08062b16 in region_prepare_manage (reg=0x80e7880, cwin=0x814d4b0, 
param=0xbfb0b534, redir=0) at manage.c:136
#6  0x0806ff6b in groupws_prepare_manage (ws=0x80f4790, cwin=0x814d4b0, 
param=0xbfb0b534, redir=0) at group-ws.c:291
#7  0x08062b16 in region_prepare_manage (reg=0x80f4790, cwin=0x814d4b0, 
param=0xbfb0b534, redir=0) at manage.c:136
#8  0x08067d2f in mplex_prepare_manage (mplex=0x80a4cd0, cwin=0x814d4b0, 
param=0xbfb0b534, redir=0) at mplex.c:1413
#9  0x08062b16 in region_prepare_manage (reg=0x80a4cd0, cwin=0x814d4b0, 
param=0xbfb0b534, redir=0) at manage.c:136
#10 0x08062d5f in clientwin_do_manage_default (cwin=0x814d4b0, 
param=0xbfb0b534) at manage.c:83
#11 0x080735e7 in hook_call_alt (hk=0x808aa20, p=0xbfb0b560, m=0x805e000 
, em=0x805e933 ) at hooks.c:371
#12 0x0805f4e4 in ioncore_manage_clientwin (win=16777219, maprq=1) at 
clientwin.c:577
#13 0x080612e9 in ioncore_handle_map_request (ev=0xbfb0b634) at eventh.c:122
#14 0x08061318 in ioncore_handle_event (ev=0xc) at eventh.c:48
#15 0x080735e7 in hook_call_alt (hk=0x808aab0, p=0xbfb0b634, m=0x8073569 
, em=0) at hooks.c:371
#16 0x080736b9 in hook_call_alt_p (hk=0x808aab0, p=0xbfb0b634, em=0) at 
hooks.c:416
#17 0x08059566 in ioncore_x_connection_handler (conn=4, unused=0x0) at 
event.c:211
#18 0x08072772 in mainloop_select () at select.c:86
#19 0x08059662 in ioncore_mainloop () at event.c:235
#20 0x08057ec4 in main (argc=134733787, argv=0x8081b00) at ion.c:289



-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages ion3 depends on:
ii  libc62.3.6.ds1-7 GNU C Library: Shared libraries
ii  libice6  1:1.0.1-2   X11 Inter-Client Exchange library
ii  liblua5.1-0  5.1.1-2 Simple, extensible, embeddable pro
ii  libsm6   1:1.0.1-3   X11 Session Management library
ii  libx11-6 2:1.0.3-2   X11 client-side library
ii  libxext6 1:1.0.1-2   X11 miscellaneous extension librar
ii  libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library
ii  rxvt-beta [x-terminal-emulat 2.7.10-3VT102 terminal emulator for the X 

Versions of packages ion3 recommends:
ii  xfonts-100dpi 1:1.0.0-3  100 dpi fonts for X
ii  xfonts-75dpi  1:1.0.0-3  75 dpi fonts for X

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#420155: zsh: zcompile fails at installation

[ingo]

Package: zsh
Version: 4.3.3-1
Severity: normal
Tags: patch

hi,

when compiling the function in /usr/share/zsh/4.3.3/functions/Misc
add-zsh-hook fails. the attached patch fixes this

regards,

ingo


--- /usr/share/zsh/4.3.3/functions/Misc/add-zsh-hook.orig 2007-04-20 
13:38:46.0 +0200
+++ /usr/share/zsh/4.3.3/functions/Misc/add-zsh-hook2007-04-20
13:38:55.0 +0200
@@ -52,7 +52,7 @@
 (( ${(P)#hook} )) || unset $hook
   fi
 else
-  if (( ${(P)+hook} )): then
+  if (( ${(P)+hook} )); then
 if (( ${(P)hook[(I)$fn]} == 0 )); then
   set -A $hook ${(P)hook} $fn
 fi


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.20.7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages zsh depends on:
ii  debconf [debconf-2.0] 1.5.13 Debian configuration management sy
ii  libc6 2.5-2  GNU C Library: Shared libraries
ii  libncurses5   5.5-5  Shared libraries for terminal hand

Versions of packages zsh recommends:
ii  libcap1   1:1.10-14  support for getting/setting POSIX.
ii  libpcre3  6.7-1  Perl 5 Compatible Regular Expressi

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#735478: [Pkg-xfce-devel] Bug#735478: fixed in xfce4-weather-plugin 0.7.4-5

[Ingo]

On Wed, Jan 22, 2014 at 05:18:39PM +0100, Alad Wenter wrote:
> With the new version, it doesn't crash anymore, but some of the 
> prediction data are missing (location: Belgium)

The same here in Germany - all high temperatures are now "NA" as the
patch is supposed to do. However this applies to all days as shown on
the first tab with "today" *and* "4 days of forecast".

I now installed the version as Christoph Biedl recommended in the
first "Message #5" which is 0.7.4-4 with his patch "dropping the
assertion check".

This gives me the 4 high-temperatures for the coming 4 days correctly,
while only "today" displays "99".

This only happenes in the afternoon, when high temperature is still
displayed.

So what weather.com just did:
they only dropped (empty) the high value for today when either noon
has passed or otherwise the value has become obsolete. For the 4
subsequent days of forecast they supply valid temperatures. However5
0.7.4-5 does also replace those with "NA".


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

Bug#735478: [Pkg-xfce-devel] Bug#735478: this bug is in debian-stable

[Ingo]

Am 26.01.2014 23:17, schrieb Yves-Alexis Perez:
> It's in stable-proposed-updates right now, and should be available
> in the next point release.

As posted before in message #50, that version from proposed is missing
*all* maximum/high temperatures in the forecast tab. First patch from
Christoph Biedl works smoothly here.


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

Bug#735478: Version 0.8.3 can be easily built from Jessie sources

[Ingo]

Just installing "build-dep xfce4-weather-plugin" in Wheezy and getting
source tarballs from Jessi is all you need. It smoothly builds with
"dpkg-buildpackage -us -uc".

Works fine without any glitches here in Wheezy-amd64.

I also tried compiling from original sources
(http://git.xfce.org/panel-plugins/xfce4-weather-plugin/snapshot/xfce4-weather-plugin-0.8.3.tar.bz2)
- all prerequisites are met and result works fine as well.



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

Bug#704987: system freezes

[Ingo]

According to my tests this nasty bug (which I observed mainly with
VirtualBox and OS/2 guest) has been fixed with the recent kernel update
in Wheezy to 3.2.0-51.

My guess is this commit which cured the freezes:

commit 884020bf3d2a3787a1cc6df902e98e0eec60330b upstream.

After any "soft gfx reset" we must manually invalidate the TLBs
associated with each ring. Empirically, it seems that a
suspend/resume or D3-D0 cycle count as a "soft reset". The symptom is
that the hardware would fail to note the new address for its status
page, and so it would continue to write the shadow registers and
breadcrumbs into the old physical address (now used by something
completely different, scary). Whereas the driver would read the new
status page and never see any progress, it would appear that the GPU
hung immediately upon resume.


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

Bug#703494: system freezes appearently fixed by recent kernel update

[Ingo]

According to my tests this nasty bug (which I observed mainly with
VirtualBox and OS/2 guest) has been fixed with the recent kernel update
in Wheezy to 3.2.0-51.

My guess is this commit which cured the freezes:

commit 884020bf3d2a3787a1cc6df902e98e0eec60330b upstream.

After any "soft gfx reset" we must manually invalidate the TLBs
associated with each ring. Empirically, it seems that a
suspend/resume or D3-D0 cycle count as a "soft reset". The symptom is
that the hardware would fail to note the new address for its status
page, and so it would continue to write the shadow registers and
breadcrumbs into the old physical address (now used by something
completely different, scary). Whereas the driver would read the new
status page and never see any progress, it would appear that the GPU
hung immediately upon resume.


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

Bug#727628: This bug affects me too in Wheezy and is really nasty

[Ingo]

I do hope we get the fix backported to Wheezy soon.

/Ingo


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

Bug#727628: xfce4-weather-plugin Wheezy

[Ingo]

with version 0.7.4-4 my weather-plugin is alive again, thanks for the
quick fix.

/Ingo


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

Bug#722097: This bug afects me too im Wheezy - with only "local mail" configured

[Ingo]

I only have configured a local mailbox (mbox).

It appears that if the mailwatch-plugin fails to fetch the local system
mail (forwarded from root -> my user account) or has another problem, it
generates another mail and thus ends up in a dead loop. This happens
quite seldom, maybe once par 2 weeks or so. Today I saw new mail
notification (yellow letter) with a tiny warning sign (red triangle with
exclamation mark in) when it happened.

In that case I also get full load on 1 or 2 (of my 4) CPU-cores. The
desktop finaly becomes unusable/frozen.
I now removed the xfce4-mailwatch-plugin an will report the result.


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

Bug#722097: xfce4-mailwatch-plugin: uses all available CPU (update)

[Ingo]

I now have removed the mailwatch-plugin and since 2 weeks all is fine -
no glitches anymore.
Tests were done with version 1.1.0-5+b1 in Wheezy-amd64

I also reviewed my logs, recordings and local mail:
There appears to be a correlation between "arriving of local mail" and
the "lock-up of the desktop". I have configured a cron-job which
"depending on result" sends a local mail to root which is aliased to my
user account. The last 2 desktop lock-ups's exactly happened when such a
mail was generated (and of course triggered the plugin).

I don't know whether this information is also helpfull:
when the lock-up's happened also a VM in VirtualBox was running and the
NIC was in promiscuous mode for "bridged networking".

Now all is fine and I have uninstalled the xfce4-mailwatch-plugin. I
would appreciate if it is removed from the dependencies of the
"xfce4-goodies", so it is not automatically installed.

/Ingo


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

Bug#747021: hugin: crash with segfault on loading multiple pictures in step 1 of assistent

[Ingo]

Package: hugin
Version: 2014.0.0~rc2+dfsg-1
Severity: important

Dear Maintainer,

I just started Hugin and following the introduchtion hit I wanted to load 3
 photos. Clicking on the "step 1 button" opens the usual file selection window
and after marking/selecting 3 *.jpg pictures to load pressing "Apply" button
makes 'hugin' crash with following message in dmesg:

[  812.020979] hugin[5570]: segfault at 48 ip 7f8379dc5dbe sp 
7fff252651a0 error 6 in libhuginbase.so.0.0[7f8379b0e000+73e000]

Did try that several times, but always the same.

A workaround is to load pictures step by step, only 1 at a time - but who 
expects
such a beheaviour?



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

Kernel: Linux 3.13-1-amd64 (SMP w/4 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 hugin depends on:
ii  enblend   4.1.2+dfsg-2
ii  enfuse4.1.2+dfsg-2
ii  hugin-tools   2014.0.0~rc2+dfsg-1
ii  libboost-system1.55.0 1.55.0-1
ii  libboost-thread1.55.0 1.55.0-1
ii  libc6 2.18-5
ii  libexiv2-12   0.23-1
ii  libgcc1   1:4.9.0-1
ii  libgl1-mesa-glx [libgl1]  10.1.0-5
ii  libglew1.10   1.10.0-3
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libimage-exiftool-perl9.57-1
ii  libpano13-3   2.9.19~beta1+dfsg-2
ii  libstdc++64.9.0-1
ii  libtiff5  4.0.3-8
ii  libwxbase2.8-02.8.12.1+dfsg2-1
ii  libwxgtk2.8-0 2.8.12.1+dfsg2-1
ii  make  3.81-8.3

hugin recommends no packages.

hugin 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#692234: Processed: severity of 689268 is important

[Ingo]

Am 26.01.2013 19:06, schrieb Debian Bug Tracking System:
> Processing commands for cont...@bugs.debian.org:
> 
>> severity 689268 important
> Bug #689268 [src:linux] linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) 
> graphics freeze
> Bug #692234 [src:linux] Intel DH77EB (H77): sporadic freeze and increased 
> power consumption during interactive use
> Bug #692500 [src:linux] [linux-image-amd64] system freezes with Ivy Brigde CPU
> Bug #692862 [src:linux] linux-image-3.2.0-4-amd64: hangs with Intel i5-3210M 
> CPU / Intel HD 4000 graphics
> Severity set to 'important' from 'serious'
> Severity set to 'important' from 'serious'
> Severity set to 'important' from 'serious'
> Severity set to 'important' from 'serious'
>> thanks
> Stopping processing here.
> 
> Please contact me if you need assistance.


Does that really mean that this bug is going to be released with Wheezy?
If yes, this means Wheezy should not be installed on Ivy-Bridge systems
with HD4000.

Wouldn't it be a feasible alternative to accept kernel 3.4.x as an
alternative in the repository (besides Wheezy's 3.2)? 3.4 is a long term
kernel and well maintained by Greg K-H.. I am currently on 3.4.25 from
kernel.org which is distributed by openSuse as well. It runs flawlessly
on said hardware and does not show any incompatibilities with any
Wheezy-component here.

I did nort yet install 3.4.26 which appearently got a major backport of
Intel's drm/i915 - 25 commits in total.


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

Bug#689268: Bug#692234: Processed: severity of 689268 is important

[Ingo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am 26.01.2013 23:37, schrieb Ben Hutchings:

> Julien Cristau prepared some packages for testing before we make
> this change.  Here's how you would install them with APT:
> 
> gpg --no-default-keyring --keyring
> /usr/share/keyrings/debian-keyring.gpg --export 310180050905E40C |
> apt-key add - echo deb
> http://people.debian.org/~jcristau/wheezy-drm34/ ./ >
> /etc/apt/sources.list.d/jcristau-wheezy-drm34.list apt-get update 
> apt-get install linux-image-3.2.0-4.drm-amd64  # or -486, or
> -686-pae
> 
> Please test and send your results (good or bad) to 
> 687...@bugs.debian.org


I already posted here several weeks ago:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692234#433
that I cannot test without the matching linux-header package! This
headers are still missing in his repo. I'll test as soon as headers
are available - please let me know.

/Ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlEFDI8ACgkQx2YcFfrwLxMAUACfQ/9YomlVoJk1V1+YBfrMo+Op
AckAnA1XiU/xGlRnoT+LV3cGhOtpK6XV
=I+mX
-END PGP SIGNATURE-


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

Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

Am 10.01.2013 09:39, schrieb Riku Voipio:

> getting hangs on anything other than the Debian 3.2.32-1 has
> been challenging. If if's just timing based, I might just have
> been lucky during my bisects.

Here vanilla 3.4.24 from kernel.org runs absolutely stable since a few
weeks. But me came up another idea:

'modinfo i916' list an option which appears to be a watchdog function:

"parm:   enable_hangcheck:Periodically check GPU activity for
detecting hangs. WARNING: Disabling this can cause system wide hangs.
(default: true) (bool)"

which actually describes the symptoms. Could it be that in the
Debian-kernel either the hangs are not detected securely, or that it
just fails to reset the module?

/Ingo


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

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

Am 03.11.2012 09:14, schrieb Jonathan Nieder:
> found 689268 linux/3.2.32-1
> fixed 689268 linux/3.3.6-1~experimental.1 , linux/3.5.5-1~experimental.1
> quit

Just a proposal:
is it possible to apply this patch from Intel to the 3.2 kernel:
http://lists.freedesktop.org/archives/intel-gfx/2012-February/015005.html?

This would allow to figure out by manually activating different rc6
states whether rc6 implementation is the root cause.
>From kernel 3.3 on the settings and default beheavior of the parameter
i915_enable_rc6 have changed. Wheezy's 3.2 kernel does not include this
patch according to 'modinfo i915'

Ingo


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

Bug#692234: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

Am 03.11.2012 22:11, schrieb Jonathan Nieder:
> Jonathan Nieder wrote:
> 
>> Hi Ingo,
> [...]
>> There seem to be some differences in symptoms here, so please file a
>> separate bug.  We can merge them later if they turn out to have the
>> same cause.
> 
> I've assigned you bug#692234.

Many thanks

  Please attach output from
> "reportbug --template linux-image-$(uname -r)"


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

** Command line:
BOOT_IMAGE=/vmlinuz root=/dev/sda2 ro i915_enable_rc6=0 drm.debug=0x2

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[5.067690] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[5.068703] wmi: Mapper loaded
[5.071376] [drm] Initialized drm 1.1.0 20060810
[5.073829] input: Power Button as
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
[5.073906] ACPI: Power Button [PWRF]
[5.080647] input: PC Speaker as /devices/platform/pcspkr/input/input5
[5.082947] snd_hda_intel :00:1b.0: PCI INT A -> GSI 22 (level,
low) -> IRQ 22
[5.083058] snd_hda_intel :00:1b.0: irq 43 for MSI/MSI-X
[5.083082] snd_hda_intel :00:1b.0: setting latency timer to 64
[5.088670] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni)
[5.128078] input: HDA Digital PCBeep as
/devices/pci:00/:00:1b.0/input/input6
[5.133604] input: HDA Intel PCH Headphone as
/devices/pci:00/:00:1b.0/sound/card0/input7
[5.133814] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[5.133881] i915 :00:02.0: setting latency timer to 64
[5.187108] mtrr: type mismatch for e000,1000 old: write-back
new: write-combining
[5.187192] [drm] MTRR allocation failed.  Graphics performance may
suffer.
[5.187514] [drm:intel_opregion_setup], graphic opregion physical
addr: 0xda3d1018
[5.187537] [drm:intel_opregion_setup], SWSCI supported
[5.187561] i915 :00:02.0: irq 44 for MSI/MSI-X
[5.187566] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[5.187636] [drm] Driver supports precise vblank timestamp query.
[5.187769] [drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call
failed
[5.188079] vgaarb: device changed decodes:
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[5.242913] [drm:gm45_get_vblank_counter], trying to get vblank count
for disabled pipe B
[5.242918] [drm:gm45_get_vblank_counter], trying to get vblank count
for disabled pipe B
[5.243687] [drm:gm45_get_vblank_counter], trying to get vblank count
for disabled pipe C
[5.243690] [drm:gm45_get_vblank_counter], trying to get vblank count
for disabled pipe C
[5.244761] [drm:intel_enable_rc6], RC6 enabled
[5.430264] [drm:init_status_page], render ring hws offset: 0x
[5.430505] [drm:init_status_page], gen6 bsd ring hws offset: 0x00022000
[5.430660] [drm:init_status_page], blt ring hws offset: 0x00043000
[5.452946] [drm:pch_irq_handler], PCH HDCP audio interrupt
[5.653336] fbcon: inteldrmfb (fb0) is primary device
[5.710016] [drm:intel_dp_mode_set], Enabling DP audio on pipe A
[5.710020] [drm:intel_write_eld], ELD on [CONNECTOR:18:DP-2],
[ENCODER:19:TMDS-19]
[5.710023] [drm:ironlake_write_eld], ELD on pipe A
[5.710029] [drm:ironlake_write_eld], Audio directed to unknown port
[5.710033] [drm:ironlake_write_eld], ELD: DisplayPort detected
[5.710037] [drm:ironlake_write_eld], ELD size 8
[5.841720] Console: switching to colour frame buffer device 240x67
[5.847013] [drm:intel_prepare_page_flip], preparing flip with no
unpin work?
[5.852403] fb0: inteldrmfb frame buffer device
[5.852404] drm: registered panic notifier
[5.890468] acpi device:4a: registered as cooling_device9
[5.890772] input: Video Bus as
/devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input8
[5.890932] ACPI: Video Device [GFX0] (multi-head: yes  rom: no
post: no)
[5.891043] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on
minor 0
[   20.511015] EXT4-fs (sda2): re-mounted. Opts: (null)
[   20.861214] EXT4-fs (sda2): re-mounted. Opts: errors=remount-ro
[   20.887405] loop: module loaded
[   20.897977] w83627ehf: Found NCT6775F chip at 0xa00
[   20.904046] fuse init (API version 7.17)
[   21.766490] EXT4-fs (sdb1): mounted filesystem with ordered data
mode. Opts: errors=remount-ro
[   22.076108] e1000e :00:19.0: irq 40 for MSI/MSI-X
[   22.128572] e1000e :00:19.0: irq 40 for MSI/MSI-X
[   22.129385] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   23.682466] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow
Control: Rx/Tx
[   23.682536] e1000e :00:19.0: eth0: 10/100 speed: disabling TSO
[   23.683348] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   27.733909] input: Sundt

Bug#692234: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

Am 04.11.2012 08:46, schrieb Jonathan Nieder:
> Ingo wrote:
> 
>> -- Package-specific info:
> [...]
> 
> Thanks much.
> 
>> BOOT_IMAGE=/vmlinuz root=/dev/sda2 ro i915_enable_rc6=0 drm.debug=0x2
> 
> There's a spelling mistake here: the kernel parameter disabling
> rc6 should be spelled "i915.i915_enable_rc6=0", since it's a module
> parameter for the i915 module.

Many thanks an shame on me.
With correct spelling I can disable rc6 and power consumption goes 8
watts up. That's for sure not how it should be, so I removed the module
parameter again. But with 'drm.debug=0x2' it only reports:

[drm:intel_enable_rc6], RC6 enabled

so rc6p is not enabled if I understand right.

I am currently running kernel 3.2.32-1 from Sid and intend to run till I
get freezes.

Ingo


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

Bug#692234: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

> I am currently running kernel 3.2.32-1 from Sid and intend to run till I
> get freezes.

That happened already 1 hour ago. I was watching a HTML5 video on
YouTube when machine froze totally, even SysRq doesn't work. Sound was
looping the last fraction of a second endlessly. Power consumtion up at
80 watts!

Hard reset took almost a minute till it responded (as already described
in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689268).

I now installed kernel 3.3.0-rc6-amd64 - we'll see.

P.S.: probably watching videos is a good trigger?


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

Bug#692234: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

Seems this kernel has full support for Ivy Bridge and HD4000 grapkics
and H77 chipset compared to 3.2.0:

'cat /var/log/kern.log | grep RC6'
[drm:intel_enable_rc6], RC6 enabled
[drm:intel_enable_rc6], RC6 and deep RC6 enabled
[drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off
[drm:intel_enable_rc6], RC6 enabled


'dmesg | grep HDA'
input: HDA Digital PCBeep as /devices/pci:00/:00:1b.0/input/input7
input: HDA Intel PCH Line as
/devices/pci:00/:00:1b.0/sound/card0/input8
input: HDA Intel PCH Front Mic as
/devices/pci:00/:00:1b.0/sound/card0/input9
input: HDA Intel PCH Rear Mic as
/devices/pci:00/:00:1b.0/sound/card0/input10
input: HDA Intel PCH Front Headphone as
/devices/pci:00/:00:1b.0/sound/card0/input11
input: HDA Intel PCH Line Out CLFE as
/devices/pci:00/:00:1b.0/sound/card0/input12
input: HDA Intel PCH Line Out Surround as
/devices/pci:00/:00:1b.0/sound/card0/input13
input: HDA Intel PCH Line Out Front as
/devices/pci:00/:00:1b.0/sound/card0/input14


I'll report as soon as I get any freeze,
Ingo


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

Bug#679218: Update: Bug#679218

[Ingo]

Am 07.11.2012 22:53, schrieb intrigeri:
> Hi Laurent,
> 
> Ingo Steiner wrote (05 Jul 2012 14:09:46 GMT) :
>> When booted via systemd I am unable to launch applications requiring
>> authentication, like synaptic from the desktop.
> 
> Ingo Steiner wrote (06 Jul 2012 16:30:36 GMT) :
>> After today's (July 6.) updates which came into Wheezy all works as
>> expected, also when started via systemd.
> 
> These two messages in a row from Ingo tend to make me think this bug
> was fixed at some point. Can you reproduce it on current Wheezy?

Current Wheezy with systemd v44-5 is absolutely ok as well, all works.

Ingo


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

Bug#692234: Intel DH77EB (H77): sporadic freeze and increased power consumption

[Ingo]

I have now been running kernel 3.3.0-rc6-amd64 for 4 days. I did even
try with different BIOS settings for "IGD DVMT Memory" especially with
"Maximum DVMT" which according to the manual corresponds to 1.7GB. With
this configuration I did have freezes few times a day with Wheezy stock
kernel before.

This is *fixed in kernel 3.3.0-rc6-amd64*. All is 100% stable.

Do you want me to continue with this test?
Or may I now switch to kernel 3.4.4-1 which should have full support for
Ivy Bridge and matching Panther Point chipsets. It is to avoid the
stress on my hardware especially by CPU heating up without proper fan
regulation.

Regards,
Ingo


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

Bug#692234: Intel DH77EB (H77): sporadic freeze and increased power consumption

[Ingo]

I have now been running vanilla 3.4 from kernel.org for 4 weeks.
Starting with 3.4.18 I have continuosly updated as new builds were
released - recently 3.4.21 and now 3.4.23.

All versions ran smoothly without any problems. Also no
incompatibilities with other Wheezy packages have been noticed.


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

Bug#692234: Intel DH77EB (H77): sporadic freeze and increased power consumption

[Ingo]

Am 15.12.2012 20:33, schrieb Ingo:
> All versions ran smoothly without any problems. Also no
> incompatibilities with other Wheezy packages have been noticed.
> 

CORRECTION:

with vanilla kernel 3.4.23, I now had 2 freezes within 6 days!

I now switched back to 3.4.21 (which ran 8 days without freezes) and
will test it thoroughly for another 2 weeks. If that turns out stable,
it will narrow down the commits drastically and the commons with patches
applied to the Debian kernel can hopefully be located.

/Ingo


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

Bug#692234: Intel DH77EB (H77): sporadic freeze and increased power consumption

[Ingo]

The crashes with vanilla 3.4.23 kernel as reported im
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692234#443 could now be
assigned to a corrupted VM in VirtualBox 4.1.18 which did not survive
the many kernel updates in saved state. Moreover those crashes were not
as hard as with Debian 3.2.32 kernel - power consumption remained normal
and reset button responded immediately.

I am now with vanilla kernel 3.4.24 from kernel.org and all is fine.

/Ingo


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

Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

I can confirm this bug here too and found a temporarly workaround.

Ivy-Bridge i5-3570K on Intel DH77EB MoBo (H77 chipset), latest BIOS
EB0089.BIO.

These freezes happend most of the time when hitting a link in Iceweasel.
They are so severe that even the MoBo reset button does not respond
immediately, I had to hit it several times. Additionally when PC stalls,
monitor continues to display the frozen desktop (via displayport) and
power consumption rises from idle 38 watts to constant 86 watts - verry
dangerous if also fan regulation fails. Upon next boot I get "orphaned
inodes" - very much the same as Per Foreby describes.

System here is Wheezy-amd64 with
- kernel 3.2.23-1
- xserver-xorg-video-intel 2:2.19.0-5

Now I'll give the history what I did try with which result. Sorry if
it's not scientific, but probably helps to pin down the root cause.


It started when I was examining my logs and discovered the messages:

  [drm] MTRR allocation failed.  Graphics performance may suffer.

Checking mtrr's showed:

cat /proc/mtrr
reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back
reg01: base=0x2 ( 8192MB), size=  512MB, count=1: write-back
reg02: base=0x0e000 ( 3584MB), size=  512MB, count=1: uncachable
reg03: base=0x0dc00 ( 3520MB), size=   64MB, count=1: uncachable
reg04: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable
reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable
reg06: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable

So I decided to boot with kernel parameter enable_mtrr_cleanup which
seemed to solve the problem:

reg00: base=0x0 (0MB), size= 2048MB, count=1: write-back
reg01: base=0x08000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x0c000 ( 3072MB), size=  512MB, count=1: write-back
reg03: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable
reg04: base=0x0dc00 ( 3520MB), size=   64MB, count=1: uncachable
reg05: base=0x1 ( 4096MB), size= 4096MB, count=1: write-back
reg06: base=0x2 ( 8192MB), size=  512MB, count=1: write-back
reg07: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable
reg08: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable
reg09: base=0x0e000 ( 3584MB), size=  256MB, count=1: write-combining

At least since then (don't know whether before as well) the
freezes/crashes were observed, sometimes more than once a day.

Did try a lot to find the root cause and finally found following workaround:

Default setting in the BIOS of the DH77EB for video agp-aperture is
"max" (values of 64, 128, 256 and 512MB are offered as options).
I played around with different BIOS settings and observed that these
settings are not respected by the i915 module. Dmesg always reports
256MB for the aperture:

dmesg | grep agp
Linux agpgart interface v0.103
agpgart-intel :00:00.0: Intel Ivybridge Chipset
agpgart-intel :00:00.0: detected gtt size: 2097152K total, 262144K
mappable
agpgart-intel :00:00.0: detected 65536K stolen memory
agpgart-intel :00:00.0: AGP aperture is 256M @ 0xe000

So I decided to set the BIOS AGP-aperture to 256MB as well and removed
the kernel parameter 'enable_mtrr_cleanup'.

I now get for the mtrr's:

reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back
reg01: base=0x2 ( 8192MB), size=  512MB, count=1: write-back
reg02: base=0x0e000 ( 3584MB), size=  512MB, count=1: uncachable
reg03: base=0x0dc00 ( 3520MB), size=   64MB, count=1: uncachable
reg04: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable
reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable
reg06: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable

still suffering graphics performance and "mtrr missmatch" according to
dmesg:

mtrr: type mismatch for e000,1000 old: write-back new:
write-combining
[drm] MTRR allocation failed.  Graphics performance may suffer.

But since then I have never obseved any cras/freeze for days now.

If more information is required, please let me know (logs did never
contain any information related to the crashes). My suspicion for the
cause is some memory or communication missmatch between BIOS-setting,
mtrr's and agp-aperture.


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

Bug#689268: linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

>> But since then I have never obseved any cras/freeze for days now.
> 
> Keeping my fingers crossed for the same outcome.
> 
> /Per
> 

Still ok here - good luck.

Me came up another thing which probably relates to that. As far as I
could extract from internet searches regarding this issue, I concluded:

1. i915 drm driver uses kms and additionally requires framebuffer support.

2. for normal graphics operation and 3D acceleration it uses
 "agp" communication (use of "mtrr" is depreciated).

3. however framebuffer seems to use "mtrr" for communication.

So finally both have to match somehow or properly switch over.

When the problem/freeze occurred I had beforehand booted into my service
system which is a minimal Wheezy without graphics, just terminal. This
of course just uses framebuffer.

Maybe the this switching also triggered the freeze?

This is just a guess from me, beeing definitely no expert in Linux and I
do not have any idea of the internals of driver or kernel.


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

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

Am 05.10.2012 23:53, schrieb Jonathan Nieder:
> Per Foreby wrote:
> 
>> So far I'm running whith the default wheezy kernel but with the iGPU memory
>> set to 256 MB. My plan was to run with this setting, and if I had another
>> crash, try the experimental kernel.
> 
> That seems like a good plan.
> 

With me all is still fine since 1 week, however that does not mean its
fixed. I am right now trying to stress my machine with high memory loads
and graphics to verify the workaround.

So far we have only 2 common things in all cases:

a) it happens when browsing with iceweasel -  Javier can you also
confirm this?

b) appears to be hardware/BIOS dependent and we all have > 4GiB RAM
installed.

There obviously is different memory allocvation/interpretation,
depending from where you gather the information:

physical RAM installed
8GiB = 8.192MiB = 8.388.608 kiB

cat /proc/mtrr
reg00: base=0x0 (0MB), size= 8192MB, count=1: write-back
reg01: base=0x2 ( 8192MB), size=  512MB, count=1: write-back
reg02: base=0x0e000 ( 3584MB), size=  512MB, count=1: uncachable
reg03: base=0x0dc00 ( 3520MB), size=   64MB, count=1: uncachable
reg04: base=0x0db80 ( 3512MB), size=8MB, count=1: uncachable
reg05: base=0x21f80 ( 8696MB), size=8MB, count=1: uncachable
reg06: base=0x21f60 ( 8694MB), size=2MB, count=1: uncachable

cat /proc/meminfo
MemTotal:8095128 kB
MemFree: 7543424 kB
Buffers:   37428 kB
Cached:   285136 kB
SwapCached:0 kB
Active:   178696 kB
Inactive: 280040 kB
Active(anon): 136512 kB
Inactive(anon):68272 kB
Active(file):  42184 kB
Inactive(file):   211768 kB
Unevictable:   0 kB
Mlocked:   0 kB
SwapTotal: 0 kB
SwapFree:  0 kB
Dirty:28 kB
Writeback: 0 kB
AnonPages:136164 kB
Mapped:58996 kB
Shmem: 68620 kB
Slab:  37120 kB
SReclaimable:  16488 kB
SUnreclaim:20632 kB
KernelStack:2096 kB
PageTables:16172 kB
NFS_Unstable:  0 kB
Bounce:0 kB
WritebackTmp:  0 kB
CommitLimit: 4047564 kB
Committed_AS: 712296 kB
VmallocTotal:   34359738367 kB
VmallocUsed:  367656 kB
VmallocChunk:   34359368791 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total:   0
HugePages_Free:0
HugePages_Rsvd:0
HugePages_Surp:0
Hugepagesize:   2048 kB
DirectMap4k:   49152 kB
DirectMap2M: 8247296 kB

It would also be interesting whether Javier
gets a mtrr with write-combining with the new kernel and
whether BIOS settings for videoRAM are respected by the i915 module.

Ingo


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

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

Interesting to see the differences between the 2 kernels. Compared to
my messages I found following lines in dmesg have disappeared with 3.5:

mtrr: type mismatch for e000,1000 old: write-back new:
write-combining

[drm] MTRR allocation failed.  Graphics performance may suffer.
[drm:intel_dsm_platform_mux_info] *ERROR* MUX INFO call failed

i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 :00:02.0: restoring config space at offset 0xf (was 0x100,
writing 0x10b)
i915 :00:02.0: restoring config space at offset 0x1 (was 0x97,
writing 0x900407)
i915 :00:02.0: setting latency timer to 64

while enabling RC6 states has been added:

[drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off


Probably a hint to the root cause?

I also compared the BIOS settings:

Javier has these options/settings:
Integrated Graphics Share Memory   [64MB]
DVMT Memory   [256MB]

I only have:
IGD DVMT Memory [256MB]

(which I called previously "agp-aperture" - ancient name when PC's had
a dedicated AGP-Port). This is the setting which I did change from
"max" -> "256MB" and got my system stable - which still holds right now.

However the "mtrr" setups (/proc/mtrr) are still identical with both
kernels. Seems the "write-combining area" has become obsolete - or
still not implemented in i915?

Ingo


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

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

With 256MB of RAM assigned to graphics all is 100% stable here since
over 2 weeks. Also 512MB seem to be no problem, just if I enable
"Maximum DVMT".

I checked with the specifications of my MoBo (Intel DH77EB) and it says:

 Dynamic Video Memory Technology (DVMT) 5.0 support
 Support of up to 1.7 GB Video Memory with 4 GB and above system memory
configuration

So these 1.7GB probably exceeds what the driver (or PAT) is capable?

Regards,
Ingo


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

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

Per,

I am still watching this issue for interest (my case I do consider as
"wrong" BIOS setting which solved it for me).

To my knowledge mtrr's are still used (not by i915 as Ben Hutchings
stated) and probably here certain manufacturers of boards/BIOS probably
set up different configurations.

Probably it ist worth to try this kernel parameter with Wheezy's
standard kernel:

"enable_mtrr_cleanup"

to allow kernel to re-arrange them and see if it has any influence in
your case?

Ingo


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

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

Am 21.10.2012 14:20, schrieb Per Foreby:

> Note that this is 1023 memory banks, not 1024, so it's not exactly 64 MB
> (65536 kB). Maybe the reason why it almost works with 256 MB is that the
> kernel always thinks that we have exactly 256 MB but the Mobo supplies
> one memory bank less. Just a theory..

Per, me came another idea. Some postings up Ben Hutching stated:

"The driver calls ioremap_wc() which will enable write-combining through
the PAT in recent processors."

Isn't this "address translation" how I/O remapping (IOMMU) also called
VT-d works?

Per's CPU i7-3770 should support VT-d (in case the motherboard offeres
it), while mine i5-3570K does not support VT-d (like all K-CPU's).

Worth to try to switch off VT-d in the BIOS, Per?

Ingo

P.S.: I am still assuming that Per's and mine obeservations have the
same root cause: some mismatch of I/O-memory areas caused by whatever,
BIOS-bug, Kernel-bug or even hardware.


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

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

Am 21.10.2012 14:20, schrieb Per Foreby:

> [22.177] (II) VESA(0): Total Memory: 1023 64KB banks (65472kB)
> [22.200] (II) VESA(0): VESA VBE Total Mem: 65472 kB
> 
> Note that this is 1023 memory banks, not 1024, so it's not exactly 64 MB
> (65536 kB). Maybe the reason why it almost works with 256 MB is that the
> kernel always thinks that we have exactly 256 MB but the Mobo supplies
> one memory bank less. Just a theory..

I checked here (with 256MB VideoRAM set in BIOS and i915 loaded) - all
is stable now.
dmesg says:
...
[0.985848] agpgart-intel :00:00.0: detected 65536K stolen memory
...

Don't know where they have gone or who did reserve them. Maybe thats
what Intel's "Dynamic Video Memory Technology (DVMT)" uses?

Isn't there anybody out who has more insight into this issue and could
give some explanation how things should work and give hints how to pin
that down?


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

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

Am 24.10.2012 02:39, schrieb Jonathan Nieder:
> Hi Per,
> 
> Per Foreby wrote:
> 
>> Just to clear some confusion: In a previous comment you suggested trying
>> 3.2.30-1 first (which seems to have been replaced by 3.2.32-1 a few days
>> ago).
>>
>> So what should I try, and in what order? I have downloaded the following
>> packages:

What I just found in the german Debian Forum
https://debianforum.de/forum/viewtopic.php?f=26&t=137332 is the same
observed on a ThinkPad T430 with a i5-3320M 2.60 GHz, HD4000 graphics
and Wheezy (reported 2012-07-26) - translated into English:

" ... to avoid *priodic freezes* I updated the kernel to 3.4.4-1 from
experimental ..."

Meanwhile the author has updated to kernel 3.5.5-1-amd64 and all appears
still fine.

Just my 2 cents,
Ingo


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

Bug#689268: Intel HD 4000 (Ivy Bridge) graphics freeze

[Ingo]

I am back and join the injured.

today I again had the known freeze after 3 weeks of freedom with 256MB
GPU-RAM BIOS setting. So my remedy did not cure the root cause. I now
installed kernel 3.5.5-1 from experimental - let's see.


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

Bug#692234: Intel DH77EB (H77): sporadic freeze and increased power consumption

[Ingo]

Am 08.11.2012 16:55, schrieb Jonathan Nieder:

> Ingo wrote:
> 
>> I have now been running kernel 3.3.0-rc6-amd64 for 4 days. I did even
>> try with different BIOS settings for "IGD DVMT Memory" especially with
>> "Maximum DVMT" which according to the manual corresponds to 1.7GB. With
>> this configuration I did have freezes few times a day with Wheezy stock
>> kernel before.
>>
>> This is *fixed in kernel 3.3.0-rc6-amd64*. All is 100% stable.
> 
> That's a comfort.  Thanks for checking.
> 
>> Do you want me to continue with this test?
> 
> No, please use whatever kernel is most convenient for now.  Hopefully
> we will find some patch to test against 3.2.y soon.

I have now extensively tested with kernel 3.4.4-1~experimental.1 from
snapshots with all available BIOS settings for "IGD DVMT Memory" as:
  128 MB
  256 MB
  512 MB
  Maximum DVMT (1.7 GB)

All is 100% stable, s2ram works smoothly, ...

BIOS setting is totally ignored and Wheezy always assigns 256 MB video
RAM according to 'dmesg':

  agpgart-intel :00:00.0: AGP aperture is 256M @ 0xe000

This kernel also enables RC6p:

  [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp off

I can't go with a newer kernel, because VirtualBox 4.1.18 does not
support (and crashes) with kernels >= 3.5.

Ingo


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

Bug#692234: Intel DH77EB (H77): sporadic freeze and increased power consumption

[Ingo]

Some additional information, probably it helps:

As stated above, when system freezes power consumption rises by some 30
watts. I now checked under normal operating conditions and it turns out
that this value is precisely the same when 2 cores (out of 4) run under
full load (checked with seti@home).

The odd thing is that CPU-fan regulation also fails during freeze
leading to overheating of the CPU.


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

Bug#670046: still buggy in Wheezy

[Ingo]

Problems still persist in xfce4-sensors-plugin (version 1.2.5-1+b1) in
Wheezy, maybe showing up in a different way.

For some reason package 'hddtemp' is installed automatically, despite I
do not need it. My PC does not have any rotational HD, just an Intel
520series SSD which does not contain any temperature sensor (at least
those S.M.A.R.T. attributes are missing).

In this situation at every login to XFCE desktop I got a warning like
this (in German):

  WARNUNG: Laufwerk /dev/sda scheint keinen Temperatur-Sensor zu haben.
  WARNUNG: Das bedeutet nicht, dass es keinen besitzt.
  WARNUNG: Falls Sie sicher sind, dass es einen besitzt, kontaktieren
Sie mich bitte (hddt...@guzu.net).
  WARNUNG: Siehe Optionen --help, --debug und --drivebase.
  /dev/sda: INTEL SSDSC2CW120A3: kein Sensor

To get rid of this I edited /etc/default/hddtemp and set:
  DISKS_NOPROBE="/dev/sda"

That did not help either as well as un-installing 'hddtemp'. Without
hddtemp installed sensors-plugin complaions about hddtemp missing.

Then I did edit the user configuration of the sensors-plugin in
  ~/.config/xfce4/panel/xfce4-sensors-plugin-36.rc

and set:
  Suppress_Hddtemp_Message=false-> true

This as well did not help. I finally recognized that this user
configuration file gets overwritten at any login and the option is reset
to "false"!

A current workaround I found meanwhile:
make sure you are not logged in to any XFCE session (i.e. switch to a
console at light-dm) and edit your
~/.config/xfce4/panel/xfce4-sensors-plugin-36.rc. this at least
suppresses the popup's at every login, but does not solve the problem
that sensors-plugin does insist on checking for a non existent
HDD-temperature using hddtemp.


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

Bug#704987: system freezes after hibernate/suspend

[Ingo]

@ colliar

I just checked with your syslog and found that system has resumed from
hibernate just a few minutes before the crash happened.

I did see also random cashes/freezes in Wheezy when system was suspended
before (s2ram). Since I no longer use suspend all the troubles have gone
away.

I must admit that this did not happen with early Wheezy kernels, but it
shows up with latest kernels and also with any vanilla 3.4 kernel.

I really cannot decide the root cause of this observation, but I feel
it's worth to test on your hardware without suspend/hibernate. My
hardware is Ivy Bridge i5-3570k.


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

Bug#692234: Intel DH77EB (H77): sporadic freeze and increased power consumption

[Ingo]

Since 2 weeks I an running kernel 3.4 from kernel.org. I used config from
Debian's 3.4.4-1~experimental.1 with "make silentoldconfig" and accepted
defaults fo 5 new items. This is a long term kernel as well and thus
still maintained.

I started with 3.4.18, updated to 3.4.19 and now using 3.4.20.
All without any problems including VirtualBox 4.1.18 from Wheezy repo.

This also appears a viable alternative to current 3.2?


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

Bug#692234: Intel DH77EB (H77): sporadic freeze and increased power consumption

[Ingo]

> Julien Cristau wrote at bug #687442
> ---
> New image is up at
> http://people.debian.org/~jcristau/linux-image-3.2.0-4.drm-amd64_3.2.34-1~jcristau.1_amd64.deb

> That kernel image is based on 3.2 with graphics system backported from 3.4
> It would help if you can test that version too.

Unfortunately I do need my PC for daily work with VirtualBox. However
that site does not supply any matching header packages, so it won't
support VBox.

Regards,
Ingo


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

Bug#703494: virtualbox: host system hangs and needs reboot after s2ram

[Ingo]

I now can definitely confirm that it is virtualbox 4.1.18-dfsg-2+deb7u1
which causes the hangs.

During an uptime of 1 week I performed 22x s2ram including 7x over night
*without any VM up and running*. I did not notice any problems or glitches.

The VM is running OS/2 as a guest with 1 CPU and 96MB of RAM assigned.
Networking is in bridged mode, so NIC is in promiscous mode when VM is
running.


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

Bug#703828: linux-headers for kernel 3.2.41-1 incomplete, missing at least "kconfig.h"

[Ingo]

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

Dear maintainer,

I just wanted to test the new kernel 3.2.41-1 from Sid for amd64.
Trying to recompile the virtualbox-modules aborts with error:



# dpkg-reconfigure virtualbox-dkms

 Uninstall Beginning 
Module:  virtualbox
Version: 4.1.18
Kernel:  3.2.0-4-amd64 (x86_64)
-

Status: Before uninstall, this module version was ACTIVE on this kernel.

vboxdrv.ko:
 - Uninstallation
   - Deleting from: /lib/modules/3.2.0-4-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


vboxnetadp.ko:
 - Uninstallation
   - Deleting from: /lib/modules/3.2.0-4-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


vboxnetflt.ko:
 - Uninstallation
   - Deleting from: /lib/modules/3.2.0-4-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


vboxpci.ko:
 - Uninstallation
   - Deleting from: /lib/modules/3.2.0-4-amd64/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod

DKMS: uninstall completed.

 Uninstall Beginning 
Module:  virtualbox
Version: 4.1.18
Kernel:  3.4.36+ (x86_64)
-

Status: Before uninstall, this module version was ACTIVE on this kernel.

vboxdrv.ko:
 - Uninstallation
   - Deleting from: /lib/modules/3.4.36+/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


vboxnetadp.ko:
 - Uninstallation
   - Deleting from: /lib/modules/3.4.36+/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


vboxnetflt.ko:
 - Uninstallation
   - Deleting from: /lib/modules/3.4.36+/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.


vboxpci.ko:
 - Uninstallation
   - Deleting from: /lib/modules/3.4.36+/updates/dkms/
 - Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod

DKMS: uninstall completed.

--
Deleting module version: 4.1.18
completely from the DKMS tree.
--
Done.
Loading new virtualbox-4.1.18 DKMS files...
Building for 3.2.0-4-amd64 and 3.4.36+
Building initial module for 3.2.0-4-amd64
Error! Bad return status for module build on kernel: 3.2.0-4-amd64 (x86_64)
Consult /var/lib/dkms/virtualbox/4.1.18/build/make.log for more information.
[ ok ] Stopping VirtualBox kernel modules.
[] Starting VirtualBox kernel modules[] No suitable module for
running k[FAIL found ... failed!
 failed!
invoke-rc.d: initscript virtualbox, action "restart" failed.



Checking the log claims missing "kconfig.h":

4 cat /var/lib/dkms/virtualbox/4.1.18/build/make.log

DKMS make.log for virtualbox-4.1.18 for kernel 3.2.0-4-amd64 (x86_64)
So 24. Mär 11:56:54 CET 2013
make: Entering directory `/usr/src/linux-headers-3.2.0-4-amd64'
  LD  /var/lib/dkms/virtualbox/4.1.18/build/built-in.o
  LD  /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/built-in.o
  CC [M]  /var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.o
cc1: fatal error:
/usr/src/linux-headers-3.2.0-4-common/include/linux/kconfig.h: Datei
oder Verzeichnis nicht gefunden
compilation terminated.
make[4]: ***
[/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv/linux/SUPDrv-linux.o]
Fehler 1
make[3]: *** [/var/lib/dkms/virtualbox/4.1.18/build/vboxdrv] Fehler 2
make[2]: *** [_module_/var/lib/dkms/virtualbox/4.1.18/build] Fehler 2
make[1]: *** [sub-make] Fehler 2
make: *** [all] Fehler 2
make: Leaving directory `/usr/src/linux-headers-3.2.0-4-amd64'


I am back on kernel 3.2.39-2 and all works as expected.

Ingo


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

Bug#703828: linux-headers-3.2.0-4-common_3.2.41-1_amd64.deb is almost empty

[Ingo]

I checked the package from

http://ftp.debian.org/debian/pool/main/l/linux/linux-headers-3.2.0-4-common_3.2.41-1_amd64.deb

it is just 209k and almost empty, whereas it usually is 3-4M.


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

Bug#692234: Julien's kernel looks promising

[Ingo]

I now tested Julien's kernel for 4 days under various conditions and all
ist solid so far. No freezes, everything works fine. I'll keep on
testing and report finally in bug #687442.

Ingo


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

Bug#687442: Success with linux-image-3.2.0-4.drm-amd64_3.2.35-3~jcristau.1_amd64.deb

[Ingo]

I now tested Julien's kernel
(http://people.debian.org/~jcristau/wheezy-drm34/linux-image-3.2.0-4.drm-amd64_3.2.35-3~jcristau.1_amd64.deb)
with
DRM/KMS subsystem backported from 3.4, thoroughly. For 12 days it ran
absolutely smoothly without any freezes!

I did stress it in many ways, but did not observe any glitches. So this
kernel fixes bug #692234 and merged bugs 689268, ... for me.

My hardware in short form:

Ivy Bridge i5-3570k with
HD4000 graphics (no external cards), display connected to Display-Port
Intel DH77EB MoBo

All standard Wheezy-kernels up to 3.2.35 exhibited regular hard freezes
- sometimes more than once a day with power consumption some 30 watts up.

Juliens kernel for sure is an excellent alternative to using vanilla 3.4
kernel which also does the job. If Julien's fix/patches is ported to
Wheezy's kernel, please drop a short note here, so I can switch back to
standard Wheezy-kernel without beeing scared for my hardware.

Ingo


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

Bug#687442: Thanks, I am already testing 3.2.0-39

[Ingo]

Many THANKS to Julien and Ben for fixing this (and pending) bugs.

I have immediately switched from vanilla 3.4 kernel to Debian's
3.2.0-39-1 from unstable.

Ingo


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

Bug#700092: Simple solution with a cron job

[Ingo]

Solution is quite simple:
setup a cron job in /etc/cron.daily or /etc/cron.weekly with these lines:
#!/bin/sh
test -x /usr/sbin/update-flashplugin-nonfree || exit 0
/usr/sbin/update-flashplugin-nonfree --install --quiet


This even reports updates in a mail to root. If you don't lige that, add
>/dev/null 2>&1 to the command line.

/Ingo


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

Bug#708622: No notification on available (security)-updates

[Ingo]

Package: lxde
Version: 4+nmu1
Severity: normal

I did install Wheezy from netinstall-image, choosing LXDE as desktop
environment. All went fine until yesterday:

A security-update (kernel) was available, but there was no notification
on the desktop. This is working under Gnome3 and XFCE (which have their
own notification installed automatically), but not in LXDE.

Solution:
just install package 'update-notifier'.
This should be installed automatically with LXDE for security reasons.

Maybe this has to be assigned to the debian-installer?


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

Bug#708622: No notification on available (security)-updates

[Ingo]

Addition:

Package "update-notifier" cannot be installed directly with apt-get,
instead you have to:

'apt-get install update-notifier-core'
which also pulls in python-vte and update-manager-gnome.

This adds the essential configuration file
/etc/apt/apt.conf.d/10periodic and 99update-notifier.


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

Bug#708622: Addition

[Ingo]

package "/update-notifier-common" is also required.
This supplies the configuration for /etc/apt/apt.conf.d/.

/

Bug#695062: This bug is fixed in version 1.9.92-1

[Ingo]

I did contact the author and he kindly has fixed this bug in December 2012.

The new package can be downloaded from:
http://www.photofilmstrip.org/builds/photofilmstrip_1.9.92-1_all.deb

However Jens stated that this build would need some more testing before
it is released. Here, on Wheezy-amd64 all is fine. I'd recommend to pull
it into Wheezy.

Thanks Jens


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

Bug#715501: flashplugin-nonfree: Update of plugin to 11.2.202.297 fails

[Ingo]

Package: flashplugin-nonfree
Version: 1:3.2
Severity: important

Dear Maintainer,

Recently Adobe updated its Flash-Plugin to version 11.2.202.297.

I did execute:
'/usr/sbin/update-flashplugin-nonfree --install --verbose'

options :  --install --verbose --
temporary directory: /tmp/flashplugin-nonfree.L5Cu08nohN
importing public key ...
selected action = --install
installed version = 11.2.202.291
upstream version = 11.2.202.291
upstream version 11.2.202.291 is already installed
end of action --install
cleaning up temporary directory /tmp/flashplugin-nonfree.L5Cu08nohN ...
end of update-flashplugin-nonfree


which of course is not correct, as checked here:
http://www.adobe.com/software/flash/about/.

Now executing:
'/usr/sbin/update-flashplugin-nonfree --status --verbose'

options :  --status --verbose --
temporary directory: /tmp/flashplugin-nonfree.oh6F1AJpCB
importing public key ...
selected action = --status
Flash Player version installed on this system  : 11.2.202.291
Flash Player version available on upstream site: 11.2.202.297
flash-mozilla.so - auto mode
  link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.so'.
end of action --status
cleaning up temporary directory /tmp/flashplugin-nonfree.oh6F1AJpCB ...
end of update-flashplugin-nonfree


tells the correct version available upstream.

So update fails as I am still on 11.2.202.291.

Kind regards,
Ingo
Subject: flashplugin-nonfree: Update of plugin to 11.2.202.297 fails
Package: flashplugin-nonfree
Version: 1:3.2
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***


-- Package-specific info:
Debian version: 7.1
Architecture: amd64
Package version: 1:3.2
Adobe Flash Player version: LNX 11,2,202,291
MD5 checksums:
e9225d179e601f71cc4e0d5a54ae30bc  
/var/cache/flashplugin-nonfree/get-upstream-version.pl
7cb981b2189f4bdd38c6fac29964036b  
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz
4efd7f0a0041a26e6c148120bcc311bb  
/var/cache/flashplugin-nonfree/install_flash_player_11_linux_x86_64.tar.gz
9f9df6a45f6a7acbb0f144b601ee770f  
/usr/lib/flashplugin-nonfree/libflashplayer.so
Alternatives:
flash-mozilla.so - auto mode
  link currently points to 
/usr/lib/flashplugin-nonfree/libflashplayer.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
Current 'best' version is 
'/usr/lib/flashplugin-nonfree/libflashplayer.so'.
lrwxrwxrwx 1 root root 34 Jul  9 18:42 
/usr/lib/mozilla/plugins/flash-mozilla.so -> /etc/alternatives/flash-mozilla.so
/usr/lib/mozilla/plugins/flash-mozilla.so: symbolic link to 
`/etc/alternatives/flash-mozilla.so'

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

Kernel: Linux 3.2.0-4-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 flashplugin-nonfree depends on:
ii  binutils   2.22-8
ii  debconf [debconf-2.0]  1.5.49
ii  gnupg  1.4.12-7
ii  libatk1.0-02.4.0-2
ii  libcairo2  1.12.2-3
ii  libcurl3-gnutls7.26.0-1+wheezy3
ii  libfontconfig1 2.9.0-7.1
ii  libfreetype6   2.4.9-1.1
ii  libgcc11:4.7.2-5
ii  libglib2.0-0   2.33.12+really2.32.4-5
ii  libgtk2.0-02.24.10-2
ii  libnspr4   2:4.9.2-1
ii  libnss32:3.14.3-1
ii  libpango1.0-0  1.30.0-1
ii  libstdc++6 4.7.2-5
ii  libx11-6   2:1.5.0-1+deb7u1
ii  libxext6   2:1.3.1-2+deb7u1
ii  libxt6 1:1.1.3-1+deb7u1
ii  wget   1.13.4-3

flashplugin-nonfree recommends no packages.

Versions of packages flashplugin-nonfree suggests:
pn  hal
ii  iceweasel  17.0.7esr-1~deb7u1
pn  konqueror-nsplugins
ii  ttf-dejavu 2.33-3
pn  ttf-mscorefonts-installer  
pn  ttf-xfree86-nonfree

-- no debconf information

Bug#710565: Working workaround

[Ingo]

I just installed the Wheezy packages:
  update-notifier
  update-notifier-common
and its dependencies. Then purged packagekit and ...

Now apt-pin above 2 packages and you are done for the time beeing.
Uptdate-notification works fine as before.

It is sad to see how Gnome invades the whole system :-(


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

Bug#710355: Workaround

[Ingo]

I just installed following packages from Wheezy using 'dpkg -i':
  libgdu0_3.0.2-3_amd64.deb (same version also in Jessie)
  python-vte_0.28.2-5_amd64.deb (same version also in Jessie)
  update-manager-core_0.200.5-2.1_all.deb
  update-manager-gnome_0.200.5-2.1_all.deb
  update-notifier_0.99.3debian11_amd64.deb
  update-notifier-common_0.99.3debian11_all.deb

Entered following in /etc/apt/preferences for pinning:

 Explanation: Wheezy packages for update-notification
 Package: update-notifier
 Pin: version 0.99.3debian11
 Pin-Priority: 1001

 Package: update-notifier-common
 Pin: version 0.99.3debian11
 Pin-Priority: 1001

and execute 'apt-cache gencaches' to update the cache.

 Then *purged* packagekit and all related stuff, keeping
 only "gir1.2-packagekitglib-1.0", "libpackagekit-glib2-16"

That frees some 14MB of space.

Reboot and uptdate-notification works fine as before.

It is sad to see how Gnome invades the whole system :-(


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

Bug#724787: linux: CPU scaling: higher frequencies and sometimes even "performance" after s2ram

[Ingo]

Subsystem: Intel Corporation Device [8086:2032]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: lpc_ich

00:1f.2 SATA controller [0106]: Intel Corporation 7 Series/C210 Series Chipset 
Family 6-port SATA Controller [AHCI mode] [8086:1e02] (rev 04) (prog-if 01 
[AHCI 1.0])
Subsystem: Intel Corporation Device [8086:2032]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ahci

00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family 
SMBus Controller [8086:1e22] (rev 04)
Subsystem: Intel Corporation Device [8086:2032]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
pn  initramfs-tools | linux-initramfs-tool  
pn  kmod | module-init-tools
pn  linux-base  

Versions of packages linux-image-3.10-3-amd64 recommends:
pn  firmware-linux-free  

Versions of packages linux-image-3.10-3-amd64 suggests:
pn  debian-kernel-handbook 
pn  grub-pc | extlinux | lilo  
pn  linux-doc-3.10 

Versions of packages linux-image-3.10-3-amd64 is related to:
pn  firmware-atheros
pn  firmware-bnx2   
pn  firmware-bnx2x  
pn  firmware-brcm80211  
pn  firmware-intelwimax 
pn  firmware-ipw2x00
pn  firmware-ivtv   
pn  firmware-iwlwifi
pn  firmware-libertas   
pn  firmware-linux  
pn  firmware-linux-nonfree  
pn  firmware-myricom
pn  firmware-netxen 
pn  firmware-qlogic 
pn  firmware-ralink 
pn  firmware-realtek
pn  xen-hypervisor  

-- debconf information:
  linux-image-3.10-3-amd64/postinst/ignoring-ramdisk:
  linux-image-3.10-3-amd64/postinst/missing-firmware-3.10-3-amd64:
  linux-image-3.10-3-amd64/postinst/depmod-error-initrd-3.10-3-amd64: false
  linux-image-3.10-3-amd64/prerm/removing-running-kernel-3.10-3-amd64: true



Here an example with idle desktop, scaling driver "intel_pstate":

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave

$ cat /proc/cpuinfo | grep -i mhz
cpu MHz : 1632.000
cpu MHz : 1632.000
cpu MHz : 1666.000
cpu MHz : 1666.000

# cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
1666000
1598000
1666000
1666000

Now s2ram + resume:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave

cat /proc/cpuinfo | grep -i mhz
cpu MHz : 3060.000
cpu MHz : 1598.000
cpu MHz : 3366.000
cpu MHz : 1598.000

cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
1598000
2652000
3264000
1598000


I even noticed once that after resume only core0 was on "powersave" while cpu's 
1,2,3 were on "performance".

This has also been reported with kernel 3.10-rcX in Gentoo:
http://comments.gmane.org/gmane.linux.kernel.cpufreq/11000

and a fix/patch was published here:
https://lkml.org/lkml/2013/7/11/661

/Ingo


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

Bug#724788: linux: CPU scaling: higher frequencies and sometimes even "performance" after s2ram

[Ingo]

rol: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- 
Kernel driver in use: lpc_ich

00:1f.2 SATA controller [0106]: Intel Corporation 7 Series/C210 Series
Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e02] (rev 04)
(prog-if 01 [AHCI 1.0])
Subsystem: Intel Corporation Device [8086:2032]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- 
Kernel driver in use: ahci

00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset
Family SMBus Controller [8086:1e22] (rev 04)
Subsystem: Intel Corporation Device [8086:2032]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- 
pn  initramfs-tools | linux-initramfs-tool  
pn  kmod | module-init-tools
pn  linux-base  

Versions of packages linux-image-3.10-3-amd64 recommends:
pn  firmware-linux-free  

Versions of packages linux-image-3.10-3-amd64 suggests:
pn  debian-kernel-handbook 
pn  grub-pc | extlinux | lilo  
pn  linux-doc-3.10 

Versions of packages linux-image-3.10-3-amd64 is related to:
pn  firmware-atheros
pn  firmware-bnx2   
pn  firmware-bnx2x  
pn  firmware-brcm80211  
pn  firmware-intelwimax 
pn  firmware-ipw2x00
pn  firmware-ivtv   
pn  firmware-iwlwifi
pn  firmware-libertas   
pn  firmware-linux  
pn  firmware-linux-nonfree  
pn  firmware-myricom
pn  firmware-netxen 
pn  firmware-qlogic 
pn  firmware-ralink 
pn  firmware-realtek
pn  xen-hypervisor  

-- debconf information:
  linux-image-3.10-3-amd64/postinst/ignoring-ramdisk:
  linux-image-3.10-3-amd64/postinst/missing-firmware-3.10-3-amd64:
  linux-image-3.10-3-amd64/postinst/depmod-error-initrd-3.10-3-amd64: false
  linux-image-3.10-3-amd64/prerm/removing-running-kernel-3.10-3-amd64: true
--

Here an example with idle desktop, scaling driver "intel_pstate":

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave

$ cat /proc/cpuinfo | grep -i mhz
cpu MHz : 1632.000
cpu MHz : 1632.000
cpu MHz : 1666.000
cpu MHz : 1666.000

# cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
1666000
1598000
1666000
1666000

Now s2ram + resume:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
powersave
powersave
powersave
powersave

cat /proc/cpuinfo | grep -i mhz
cpu MHz : 3060.000
cpu MHz : 1598.000
cpu MHz : 3366.000
cpu MHz : 1598.000

cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
1598000
2652000
3264000
1598000


I even noticed once that after resume only core0 was on "powersave"
while core 1,2,3 were on "performance".

This has also been reported with kernel 3.10-rcX in Gentoo:
http://comments.gmane.org/gmane.linux.kernel.cpufreq/11000

and a fix/patch was published here:
https://lkml.org/lkml/2013/7/11/661

/Ingo


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

Bug#724788: Please delete this bug #724788, is duplicate of #724787

[Ingo]

Delete me


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

Bug#724787: CPU scaling: higher frequencies and sometimes even "performance" after s2ram

[Ingo]

Today I tried to gather further information and found:

before s2ram:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
160
160
160
160

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
380
380
380
380


after resume from s2ram:

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq
160
380
380
380

cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq
380
380
380
380

which clearly indicates there is some data altered during s2ram cycle.
Also fan regulation indicates increased speed/power consumpition after
s2ram.

FYI (because not reported automatically):
I got a quad-core Ivy Bridge processor, here the info for 1st core:

cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 58
model name  : Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz
stepping: 9
microcode   : 0x12
cpu MHz : 1734.000
cache size  : 6144 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 4
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx
rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx
est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb
xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase
smep erms
bogomips: 6800.74
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


If more information is required, please let me know.


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

Bug#744753: situation with anacron is even worse in Jessie

[Ingo]

anacron is also not invoked when system boots on battery and later on
connected is to AC power, because systemd does not detect this change!
This is a no go for laptop users as they very rarely get notified of
pending updates, because the usual way is to connect the laptop to AC
power only when battery capacity is/gets low. Currently notification for
updates only works if laptop runs on AC power when booted up!

My workaround with good old udev rules I took from Arch-wiki:
https://wiki.archlinux.org/index.php/Power_management#Tools_and_scripts

I set up two udev-rules:

/lib/udev/rules.d/98-powersave.rules
# ATTR values:  "0" = on battery;   "1" = on AC power
SUBSYSTEM=="power_supply", ATTR{online}=="0",
RUN+="/usr/sbin/pm-powersave true"
SUBSYSTEM=="power_supply", ATTR{online}=="1",
RUN+="/usr/sbin/pm-powersave false"

Woirks great.

Bug#851066: Latest checksums for Flash Plugin not available at https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/

[Ingo]

> The problem is not a technical one, but just a simple question of
maintenance of the site "debian.people.org/~bartm/..." in order to
follow the latest version from Adobe.

Thats right, seems Bart Marten no longer receives mail directed to his
debian account. I found another email address in the *.deb package,
probably he will react on mails to it:

ba...@knars.be

Bug#807418: proposed workaround

[Ingo]

In case it is too difficult to build the deb-package with correct
timestamps, a woraround is to "touch" those files after unpacking by the
post-installation script.

That's my current solution, I do the "touch" in my rsync backup-script.

Bug#807418: This bug applies also to Firefox-esr in Stretch

[Ingo]

This bug applies also to Firefox-esr in Stretch:

The only difference is the directory name, here affected files are:


/usr/share/firefox-esr/browser/defaults/preferences/webide-prefs.js
/usr/share/firefox-esr/browser/defaults/preferences/firefox.js
/usr/share/firefox-esr/browser/defaults/preferences/devtools.js

All 3 files have a modification date of 2010, January 1st, which did not
change since Firefox 45 was introduced in Stretch.

Bug#770064: package list isn't updated automatically

[Ingo]

Am 19.11.2014 um 18:39 schrieb Matthias Klumpp:
> Control: reassign -1 gnome-packagekit 3.14.0-1
> 
> Hi!
> The network-interface issue is a problem of GNOME-PackageKit (and a
> pretty stupid one...).
> That the notifier does not notify after the Apt cronjob was run is
> another bug, can you please report that one against pk-update-icon?
> What happens if you run pkcon refresh instead of apt update?
> Cheers,
> Matthias
> 

'pkcon refresh' appearently updates the package cache:

~$ pkcon refresh
Zwischenspeicher wird aktualisiert[=]
Zwischenspeicher wird geladen [=]
Software-Liste wird aktualisiert[=]
Pakete werden heruntergeladen [=]
Ausführen[=]
Fertig[=]

There of course are no updates pendig for today - they got installed
during my recent tests. Have to wait until tomorrow for new updates
available.

What wonders me: 'pkcon' can be invoked by a normal user, isn't that a
security risk?


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

Bug#770064: additional information

[Ingo]

I just checked the timestamps in following directory (Jessie):

ls -l /var/lib/apt/periodic
insgesamt 0
-rw-r--r-- 1 root root 0 Nov 16 13:07 update-stamp
-rw-r--r-- 1 root root 0 Nov 17 12:47 update-success-stamp

These are outdated despite I installed the updates with packagekit GUI.
Seems that those timestamps did not get updated anymore since I
converted to packagekit.

--
On my Wheezy-system with update-manager those are up-to-date from today:
-rw-r--r-- 1 root root 0 Nov 19 11:07 update-stamp
-rw-r--r-- 1 root root 0 Nov 19 11:07 update-success-stamp
Here I installed the updates using update-manager.


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

Bug#770064: package list isn't updated automatically

[Ingo]

Am 19.11.2014 um 21:34 schrieb Matthias Klumpp:

> Yes - I would like to know if that also triggers a notification (it
> should do that).

Ok, today there are updates available.

1. Without any manual action nothing happens.


2. executing 'pkcon refresh' as normal user gives following output:

~$ pkcon refresh
Zwischenspeicher wird aktualisiert[=]
Zwischenspeicher wird geladen [=]
Software-Liste wird aktualisiert[=]
Pakete werden heruntergeladen [=]
Ausführen[=]
Fertig[=]
 Aktivierthttp://security.debian.org
jessie/updates InRelease
 Aktivierthttp://security.debian.org
jessie/updates/main Sources
 Aktivierthttp://security.debian.org
jessie/updates/contrib Sources
 Aktivierthttp://security.debian.org
jessie/updates/non-free Sources
 Aktivierthttp://security.debian.org
jessie/updates/main amd64 Packages
 Aktivierthttp://security.debian.org
jessie/updates/contrib amd64 Packages
 Aktivierthttp://security.debian.org
jessie/updates/non-free amd64 Packages
 Aktivierthttp://security.debian.org
jessie/updates/contrib Translation-en
 Aktivierthttp://security.debian.org
jessie/updates/main Translation-en
 Aktivierthttp://security.debian.org
jessie/updates/non-free Translation-en


Afterwards package cache is emptied (only subdir archives exists):

~$ ls -l /var/cache/apt/
drwxr-xr-x 3 root root77824 Nov 19 17:39 archives

No notification shows up after waiting for some 15 minutes.

3. Reboot

Now after a short while notification icon shows up and announces 9
pending updates (pop-up message on desktop).

And /var/cache/apt/ is populated again:

~$ ls -l /var/cache/apt/
insgesamt 48296
drwxr-xr-x 3 root root77824 Nov 19 17:39 archives
-rw-r--r-- 1 root root 24777164 Nov 20 12:59 pkgcache.bin
-rw-r--r-- 1 root root 24633214 Nov 20 12:59 srcpkgcache.bin


4. Update of packages asks for root-PW and works fine (eth0 managed by
network-manager).

Seems that packagekit is not properly invoked. Apt-configuration:

~$ ls -l /etc/apt/apt.conf.d/
insgesamt 32
-rw-r--r-- 1 root root   82 Aug 31  2013 00CDMountPoint
-rw-r--r-- 1 root root   40 Aug 31  2013 00trustcdrom
-rw-r--r-- 1 root root  643 Mai  5  2014 01autoremove
-rw-r--r-- 1 root root  959 Nov 12 14:58 01autoremove-kernels
-rw-r--r-- 1 root root  141 Jun 30  2012 20listchanges
-rw-r--r-- 1 root root 1040 Okt 21 15:55 20packagekit
-rw-r--r-- 1 root root  182 Mai  5  2013 70debconf
-rw-r--r-- 1 root root   32 Nov 18 12:34 99synaptic


Also worth to mention: notification only happens *after rebooting*!
Not very Linux-like :-( Should be immediately for security reasons.

If more help is needed: I have done this in a VM and taken a snapshot
before, so I can repeat any time.

Cheers,
Ingo


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

Bug#770064: Root cause for not updating found, network-manager issue remains

[Ingo]

I digged into documentation of PK and found in

/usr/share/doc/packagekit/README.Debian

> The following components of PackageKit aren't shipped in the packages:
>  - cron job: APT does this already, no need for doubling the functionality
>
> The following components of PackageKit aren't shipped in the packages:
>  - cron job: APT does this already, no need for doubling the functionality

However purging update-notifier-common also removed these configuration
files:
/etc/apt/apt.conf.d/10periodic
/etc/apt/apt.conf.d/15update-stamp

So I took them from Wheezy and copied them to Jessi

GREAT!
And Updates are notified immediately as they are available and not after
next reboot!

Those 2 files should be included in pk-update-icon or PK itself:

/etc/apt/apt.conf.d/10periodic
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";

/etc/apt/apt.conf.d/15update-stamp
APT::Update::Post-Invoke {"touch
/var/lib/apt/periodic/update-success-stamp 2>/dev/null || true";};



But as stated in the header: the network-manager issue remains as a bug!


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

Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie

[Ingo]

Package: nfs-common
Version: 1:1.2.8-9
Severity: severe

Since upgrade of the client from Wheezy to Jessie I am no longer able to
mount nfs4-exports from a host (leo) running Wheezy as a normal user
(UID=1000):

# showmount -e leo
Export list for leo:
/srv/nfs4/Bilder 192.168.33.0/24
/srv/nfs4192.168.33.0/24


/etc/fstab entries on the clients (Jessi and Wheezy):
leo:/Bilder /home/ingo/leo.Bilder nfs4 noauto,rw,user,soft,relatime 0 0

In Wheezy all works as expected, in Jessie mount fails with:
$ LANG=en_US.UTF-8 mount leo:/Bilder
mount: leo:/Bilder: No such file or directory

However it is possible to perform the mount as "root".

Umount as user (UID=1000) fails with same "non informative" message:
$ LANG=en_US.UTF-8 umount leo:/Bilder
umount: leo:/Bilder: No such file or directory

This is a security flaw as users cannot mount/umount on demand without
root-privileges.


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

Bug#788547: nfs4 mount.nfs does not respect option "user" in fstab in Jessie

[Ingo]

Package: nfs-common
Version: 1:1.2.8-9
Severity: serious

Since upgrade of the client from Wheezy to Jessie I am no longer able to
mount nfs4-exports from a host (leo) running Wheezy as a normal user
(UID=1000):

# showmount -e leo
Export list for leo:
/srv/nfs4/Bilder 192.168.33.0/24
/srv/nfs4192.168.33.0/24


/etc/fstab entries on the clients (Jessi and Wheezy):
leo:/Bilder /home/ingo/leo.Bilder nfs4 noauto,rw,user,soft,relatime 0 0

In Wheezy all works as expected, in Jessie mount fails with:
$ LANG=en_US.UTF-8 mount leo:/Bilder
mount: leo:/Bilder: No such file or directory

However it is possible to perform the mount as "root".

Umount as user (UID=1000) fails with same "non informative" message:
$ LANG=en_US.UTF-8 umount leo:/Bilder
umount: leo:/Bilder: No such file or directory

This is a security flaw as users cannot mount/umount on demand without
root-privileges.


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

Bug#776995: snd-usb-audio: micrphone "Unlikely big volume range"

[Ingo]

Please close this bug, I found a workaround.

It is just because the webcam's microphone was not set to default in
pulseaudio configuration.

Executing:
pactl "set-default-source
alsa_input.usb-046d_09a4_F89C6650-02-U0x46d0x9a4.analog-mono"

resolves the issue. Can be made persistent in /etc/pulse/default.pa.

(Command not documented in 'man pactl')

The message "Unlikely big volume range" in syslog is just cosmetic.

Ingo


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

Bug#776995: snd-usb-audio: micrphone "Unlikely big volume range" with QuickCam E3500

[Ingo]

Package: src:linux
Version: 3.2.65-1+deb7u1
Severity: normal
Tags: upstream

Dear Maintainer,

Whezy does not apply the volume_control_quirk to usb_audio. This results
in following messages in syslog:

Feb  3 17:56:10 tux kernel: [21351.605840] usbcore: registered new
interface driver uvcvideo
Feb  3 17:56:10 tux kernel: [21351.605842] USB Video Class driver (1.1.1)
Feb  3 17:56:11 tux kernel: [21352.606925] 2:3:1: cannot get freq at ep 0x86
Feb  3 17:56:12 tux kernel: [21353.296272] usb_audio: Warning! Unlikely
big volume range (=3072), cval->res is probably wrong.
Feb  3 17:56:12 tux kernel: [21353.296277] usb_audio: [5] FU [Mic
Capture Volume] ch = 1, val = 5888/8960/1

The result is the microphone beeing "dead".

The bug has been reported already on launchpad in 2012:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1265103

and has been fixed upstream on github:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/sound/usb/mixer.c?id=e182534d4bd3a779941f2868f35e1f66a8d36cea

Jessie kernel works fine and has the patched version of /sound/usb/mixer.c.

Please include the patch in next update of Wheezy kernel.

Regards,
Ingo


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

Bug#764864: xfce4-weather-plugin: Old API ceased working, need to update to v1.2

[Ingo]

Package: xfce4-weather-plugin
Version: 0.8.3-1
Severity: important
Tags: upstream

Dear Maintainer,

due to the crippled functionality of v7.4-5 in Wheezy I am using the
version 0.8.3-1~bpo70+1 from wheezy-backports. However since a few days
the old API stopped working and thus the applet does not receive/display
any forecast data.

The situation is already discussed upstream:
https://bugzilla.xfce.org/show_bug.cgi?id=10916

and a patch available. This patch has been applied in Debians version
0.8.3-2 in Sid and I confirmed that it solves the issue. The Jessie
version 0.8.3-1 does show the same problem, while updating to 0.8.3-2
solves it.

I kindly ask for applying that patch(es) also to Wheezy-backport to have
weather forecast available again.

Unfortunately I am not able to compile the Sid-Sources for Wheezy (which
worked fine for 0.8.3-1 over a year ago).



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

Kernel: Linux 3.2.0-4-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 xfce4-weather-plugin depends on:
ii  libatk1.0-0 2.4.0-2
ii  libc6   2.13-38+deb7u4
ii  libcairo2   1.12.2-3
ii  libfontconfig1  2.9.0-7.1
ii  libfreetype62.4.9-1.1
ii  libgdk-pixbuf2.0-0  2.26.1-1
ii  libglib2.0-02.33.12+really2.32.4-5
ii  libgtk2.0-0 2.24.10-2
ii  libpango1.0-0   1.30.0-1
ii  libsoup2.4-12.38.1-3
ii  libxfce4ui-1-0  4.8.1-1
ii  libxfce4util4   4.8.2-1
ii  libxml2 2.8.0+dfsg1-7+wheezy1
ii  xfce4-panel 4.8.6-4

xfce4-weather-plugin recommends no packages.

xfce4-weather-plugin 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#782505: Workaround to prevent installation of the broken packages

[Ingo]

Just prevent installation by apt-pinning:

/etc/apt/preferences

Package: libxrender*
Pin: version 1:0.9.7-1+deb7u1+b1
Pin-Priority: -1

Hope it gets fixed soon.


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

Bug#796713: system-config-printer: Option "fit-to-page" broken, always on. Cannot print out true to size.

[Ingo]

Package: system-config-printer
Version: 1.4.6-1
Severity: important

Dear Maintainer,


   * What led up to the situation?

Just creating a page with a frame in LibreOffice-writer and printing it out 
results
in a downscale to appr. 90% of the exact measures. (I use that feature as a 
place
holder for photo). Checking the printer settings in "system-config-printer", tab
"Job properties" shows the chaeck-box "scale to fit page" de-selected. I cannot
check/unchech that box even though root-PW is requested and given. 
Whatever I do, the page is always scaled down ihnoring measures as suppied 
within
the document by LibreOffice.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I found that there by default is an option in /etc/cups/printers.conf:
Option fitplot True
As it cannot be changed by "system-config-printer" I set it manually to "False"
and not suprising: it works. I get perfectly sized printouts.

   * What was the outcome of this action?

The outcome unfortunately is that this manual setting in /etc/cups/printers.conf
is reset to "True" or, if I erase the whole line the Option is added again as
soon as I use the graphical printer configuration to apply changes. Th checkbox
does not report the actual setting instead it always resets to "True".

   * What outcome did you expect instead?

This usefull tool to configure printers on XFCE4-dsesktop should work as 
exüpected
and as it did for years in Wheezy and still does.


-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages system-config-printer depends on:
ii  gir1.2-gdkpixbuf-2.0   2.31.1-2+deb8u2
ii  gir1.2-glib-2.01.42.0-2.2
ii  gir1.2-gtk-3.0 3.14.5-1
ii  gir1.2-notify-0.7  0.7.6-2
ii  gir1.2-packagekitglib-1.0  1.0.1-2
ii  gir1.2-pango-1.0   1.36.8-3
ii  gnome-icon-theme   3.12.0-1
pn  python-cairo   
ii  python-cups1.9.63-1
ii  python-cupshelpers 1.4.6-1
ii  python-dbus1.2.0-2+b3
ii  python-gi  3.14.0-1
pn  python-gobject-2   
ii  python-libxml2 2.9.1+dfsg1-5
pn  python:any 

Versions of packages system-config-printer recommends:
ii  cups-pk-helper  0.2.5-2+b1
ii  gir1.2-gnomekeyring-1.0 3.12.0-1+b1
ii  python-smbc 1.0.15.3-0.1
ii  system-config-printer-udev  1.4.6-1

Versions of packages system-config-printer suggests:
pn  gnome-packagekit-session  

-- no debconf information

Bug#807418: iceweasel: missing/incorrect timestamps (for 3 files) in iceweasel*.deb package

[Ingo]

Package: iceweasel
Version: 38.2.1esr-1~deb8u1
Severity: normal

Dear Maintainer,

Iceweasel package contains 3 files with incorrect timestamp.
All 3 files have a modification date of 2010, February 1st:

/usr/share/iceweasel/browser/defaults/preferences/firefox-branding.js
/usr/share/iceweasel/browser/defaults/preferences/firefox.js
/usr/share/iceweasel/browser/defaults/preferences/webide-prefs.js

This timestamps are the very same since numerous versions of iceweasel,
depite the fact that the content of the last 2 files changes with every
new version/update of Iceweasel.

This is especially annoying with backups using "rsync" without the "-c"
option for performance reasons. Those files are skipped and not transrferred,
even if the content has changed. This is only discovered when using checksums.

I think with current Debians "reproducible builds" aktivities such things
should not happen anymore.

-- Package-specific info:

-- Extensions information
Name: Classic Theme Restorer
Location: ${PROFILE_EXTENSIONS}/classicthemeresto...@arist2noia4dev.xpi
Status: enabled

Name: Deutsch (DE) Language Pack locale
Location: 
/usr/lib/iceweasel/browser/extensions/langpack...@iceweasel.mozilla.org.xpi
Package: iceweasel-l10n-de
Status: enabled

Name: Ghostery
Location: ${PROFILE_EXTENSIONS}/fire...@ghostery.com.xpi
Status: enabled

Name: HTTPS-Everywhere
Location: ${PROFILE_EXTENSIONS}/https-everywhere-...@eff.org
Status: enabled

Name: Privacy Badger
Location: ${PROFILE_EXTENSIONS}/jid1-mnnxcxisbpnsxq-...@jetpack.xpi
Status: enabled

Name: Standard theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

-- Plugins information
Name: DivX Browser Plug-In
Location: /usr/lib/mozilla/plugins/gecko-mediaplayer-dvx.so
Package: gecko-mediaplayer
Status: enabled

Name: mplayerplug-in is now gecko-mediaplayer 1.0.9
Location: /usr/lib/mozilla/plugins/gecko-mediaplayer.so
Package: gecko-mediaplayer
Status: enabled

Name: QuickTime Plug-in 7.6.9
Location: /usr/lib/mozilla/plugins/gecko-mediaplayer-qt.so
Package: gecko-mediaplayer
Status: enabled

Name: RealPlayer 9
Location: /usr/lib/mozilla/plugins/gecko-mediaplayer-rm.so
Package: gecko-mediaplayer
Status: enabled

Name: Windows Media Player Plug-in
Location: /usr/lib/mozilla/plugins/gecko-mediaplayer-wmp.so
Package: gecko-mediaplayer
Status: enabled


-- Addons package information
ii  gecko-mediapla 1.0.9-2  amd64Multimedia plug-in for Gecko brow
ii  iceweasel  38.2.1esr-1~ amd64Web browser based on Firefox
ii  iceweasel-l10n 1:38.2.1esr- all  German language package for Icewe

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

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages iceweasel depends on:
ii  debianutils   4.5.1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.29-1
ii  libatk1.0-0   2.18.0-1
ii  libc6 2.19-22
ii  libcairo2 1.14.4-1
ii  libdbus-1-3   1.10.4-1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2+b1
ii  libffi6   3.2.1-3
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6.1-0.1
ii  libgcc1   1:5.2.1-23
ii  libgdk-pixbuf2.0-02.32.2-1
ii  libglib2.0-0  2.46.2-1
ii  libgtk2.0-0   2.24.28-1
ii  libhunspell-1.3-0 1.3.3-3+b2
ii  libpango-1.0-01.38.1-1
ii  libsqlite3-0  3.9.2-1
ii  libstartup-notification0  0.12-4
ii  libstdc++65.2.1-23
ii  libx11-6  2:1.6.3-1
pn  libxcomposite1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.9-2
ii  libxt61:1.1.5-1
ii  procps2:3.3.10-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages iceweasel recommends:
ii  gstreamer1.0-libav 1:1.6.1-dmo1
ii  gstreamer1.0-plugins-good  1.6.1-1

Versions of packages iceweasel suggests:
ii  fonts-mathjax  2.5.3-1
pn  fonts-oflb-asana-math  
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-2.1
ii  libgnomeui-0   2.24.5-3
ii  libgssapi-krb5-2   1.13.2+dfsg-4
pn  mozplugger 

-- no debconf information

Bug#797791: gv displays pdf-file incorrectly with 0.05mm white lines/edges right and bottom

[Ingo]

Package: gv
Version: 1:3.7.4-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
I prepared a book cover measuring 434.2x275.0mm in LibreOffice and exported to 
PDF.
I submitted that PDF to the printing company to check for compliance wit their 
machines.
They did a few corrections to eliminate glitches introduced by LibreOffice,
including removal of a fine white line at the bottom edge and returned the
corrected PDF to me for submission.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I rechecked that PDF carefully on my PC running Jessie and gv 1:3.7.4-1

   * What was the outcome of this action?
gv shows very fine white borders (background is seamlessly dark green)
on the right and bottom edges. Easily seen when placing cursor in bottom-right
corner and selecting 64x magnification. The width of the white can roughly
calculated to 0.05mm. Said  PDF and screenshot will be uploaded later.

   * What outcome did you expect instead?
gv not displaying a white border, where there isn't one. Printing company
sent me a screenshot of same file in Acrobat PRO and there is no white
borders seen.


-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gv depends on:
ii  ghostscript-x  9.06~dfsg-2+deb8u1
ii  libc6  2.19-18
ii  libx11-6   2:1.6.2-3
ii  libxinerama1   2:1.1.3-1+b1
ii  libxmu62:1.1.2-1
ii  libxt6 1:1.1.4-1+b1
ii  xaw3dg 1.5+E-18.2

Versions of packages gv recommends:
ii  xaw3dg  1.5+E-18.2

gv suggests no packages.

-- no debconf information

Bug#774532: gvfs-backends: syslog messages about index.bdmv also happens with *all mounts* defined in /etc/fstab with "noauto"

[Ingo]

Whatever piece of volume I mount from fstab creates an entry in
/var/log/messages (can nicely be monitored with "tail -f").

Be it a partitition, a NFS-export ...

And even a local partition which is declared in fstab to be mounted at
boot time:
UUID=279cee0c-5a0 /home/ingo/data ext4   errors=remount-ro 0  2
will produce such an entry every time I boot Jessie

And worse: "mount.nfs" as declared in fstab:
b3:/storage /home/ingo/b3.storage nfs4 noauto,rw,user,soft,relatime 0 0
does not respect the option "user", only root can mount it, resulting in:

tux org.gtk.Private.UDisks2VolumeMonitor[1593]: index_parse.c:190:
indx_parse(): error opening /home/ingo/nas.share/BDMV/BACKUP/index.bdmv
I have already filed a bug against nfs-utils here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788547

It seems, here is really something broken in Jessie, be it "mount",
gvfs, udisks - whatever?


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

Bug#709197: More GLib-CRITICAL **: messages produced by networking applications

[Ingo]

package: libglib2.0-0
severity: important

All Debian-Jessie-amd64 with XFCE-desktop.
Happens on both, freh installs and also on uprgades from Wheezy.

It's not just Iceweasel, the very same message is generated on every
startup of Icedove:
GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

Following message is generated on every download of weather-data
(happens every 20 min.) by xfce4-weather-plugin 0.8.3-2
(wrapper:3061): GLib-CRITICAL **: Source ID 7763 was not found when
attempting to remove it

These messages come in blocks of 4 lines from xfce4-netload-plugin
1.2.0-1 when changing properties and closing the settings dialogue:
(xfce4-netload-plugin:1679): GLib-CRITICAL **: Source ID 167 was not
found when attempting to remove it

There are some other bugs which assign similar problems to the
applications which trigger it, i.e: #782536. But appearently this all
points to libglib2.0 + glib-networking-services.

As this all happens in Debian-stable I'd suggest to raise severity to
"important".


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

Bug#790121: xfce4-weather-plugin: Source ID 2485 was not found when attempting to remove it

[Ingo]

Package: xfce4-weather-plugin
Version: 0.8.3-2
Severity: important

Dear Maintainer,

   * What led up to the situation?
Just running the weather-plugin in the panel of XFCE-Desktop

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I did already report that as a bug against libglib2.0-0
(see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709197#38)

   * What was the outcome of this action?
Reply from Simon McVittie was:

This is not related to the g_slice_set_config thing; it is GLib
diagnosing a bug in the way xfce4-weather-plugin, or some other library
used by xfce4-weather-plugin, is using it.

Specifically, the bug is that something in xfce4-weather-plugin or a
library that it uses added an event source to GLib, for which GLib
happens to have allocated source ID 7763, and then asked to remove event
source 7763 twice. The first time, it gets removed; the second time
triggers a warning. Older GLib versions didn't warn about that; but it
is actually a potentially serious bug, because if source ID 7763 had
been reused for something else, that something else would have been
removed instead. That's why newer GLib warns when applications do this,
in an attempt to get it fixed.

My .xsession-errors still gets filled with pairwise messages like tis:

weather-Message: hole 
http://api.yr.no/weatherapi/sunrise/1.0/?lat=49.986395;lon=7.968520;date=2015-06-27
weather-Message: hole 
http://api.yr.no/weatherapi/locationforecastlts/1.2/?lat=49.986395;lon=7.968520;msl=100

(xfdesktop:2661): GLib-GIO-CRITICAL **: g_file_get_path: assertion 'G_IS_FILE 
(file)' failed
weather-Message: hole 
http://api.yr.no/weatherapi/locationforecastlts/1.2/?lat=49.986395;lon=7.968520;msl=100

(wrapper:2728): GLib-CRITICAL **: Source ID 1241 was not found when attempting 
to remove it
weather-Message: hole 
http://api.yr.no/weatherapi/locationforecastlts/1.2/?lat=49.986395;lon=7.968520;msl=100

(wrapper:2728): GLib-CRITICAL **: Source ID 2485 was not found when attempting 
to remove it
weather-Message: hole 
http://api.yr.no/weatherapi/locationforecastlts/1.2/?lat=49.986395;lon=7.968520;msl=100

(wrapper:2728): GLib-CRITICAL **: Source ID 3724 was not found when attempting 
to remove it


   * What outcome did you expect instead?
Smooth opreation without the risk that some valid "Source ID" gets removed by 
accident.



-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xfce4-weather-plugin depends on:
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18
ii  libcairo21.14.0-2.1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-3
ii  libgdk-pixbuf2.0-0   2.31.1-2+b1
ii  libglib2.0-0 2.42.1-1
ii  libgtk2.0-0  2.24.25-3
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libsoup2.4-1 2.48.0-1
ii  libxfce4ui-1-0   4.10.0-6
ii  libxfce4util64.10.1-2
ii  libxml2  2.9.1+dfsg1-5
pn  xfce4-panel  

xfce4-weather-plugin recommends no packages.

xfce4-weather-plugin 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#790123: xfce4-netload-plugin: GLib-CRITICAL **: Source ID 5101 was not found when attempting to remove it

[Ingo]

Package: xfce4-netload-plugin
Version: 1.2.0-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
Running Jessie with XFCE-Desktop and the netload-plugin in the panel.
Right-clicking on the panel-icon opens the properties/settins box.
On closing the settings-box (even if nothing has been changed) generates 4 
Glib-CRITICAL messages.

(xfce4-netload-plugin:2733): GLib-CRITICAL **: Source ID 5 was not found when 
attempting to remove it

(xfce4-netload-plugin:2733): GLib-CRITICAL **: Source ID 5 was not found when 
attempting to remove it

(xfce4-netload-plugin:2733): GLib-CRITICAL **: Source ID 5099 was not found 
when attempting to remove it

(xfce4-netload-plugin:2733): GLib-CRITICAL **: Source ID 5099 was not found 
when attempting to remove it

(xfce4-netload-plugin:2733): GLib-CRITICAL **: Source ID 5101 was not found 
when attempting to remove it

(xfce4-netload-plugin:2733): GLib-CRITICAL **: Source ID 5101 was not found 
when attempting to remove it


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I reported this issue against libglib2.0-0, see here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709197

   * What was the outcome of this action?
The maintainer Simon McVittie replied and suggests that it is a bug in the 
netload-plugin:

> These messages come in blocks of 4 lines from xfce4-netload-plugin
> 1.2.0-1 when changing properties and closing the settings dialogue:
> (xfce4-netload-plugin:1679): GLib-CRITICAL **: Source ID 167 was not
> found when attempting to remove it

This is similar to the xfce4-weather-plugin one; it could be a bug in a
library that they both use, or it could be a similar but unrelated bug
in xfce4-netload-plugin code.

   * What outcome did you expect instead?
Not running the risk to get a valid "Suorce ID" removed. 

As Simon McVittie  states:
... but it is actually a potentially serious bug, because if source ID 7763 had
been reused for something else, that something else would have been
removed instead.


-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xfce4-netload-plugin depends on:
ii  libc6   2.19-18
ii  libcairo2   1.14.0-2.1
ii  libgdk-pixbuf2.0-0  2.31.1-2+b1
ii  libglib2.0-02.42.1-1
ii  libgtk2.0-0 2.24.25-3
ii  libxfce4ui-1-0  4.10.0-6
ii  libxfce4util6   4.10.1-2
pn  xfce4-panel 

xfce4-netload-plugin recommends no packages.

xfce4-netload-plugin 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#790121: [Pkg-xfce-devel] Bug#790121: xfce4-weather-plugin: Source ID 2485 was not found when attempting to remove it

[Ingo]

Am 27.06.2015 um 14:33 schrieb Yves-Alexis Perez:
> control: tag -1 moreinfo

> Unfortunately, that's not really helpful here. Finding “a bug in xfce4
> -weather-plugin or some other library” without any clue where it might
> lies, isn't really possible with that kind of information.
> 
> So feel free to debug this and provide any insight if you really feel
> bad about it.

Thanks for your response. If I understand Simon McVittie right, this bug
might already be in earlier versions of the plugin, it just was not
reported by glib. On the other hand the entries in ~/.xsession-errors
should show up on every Jessie installation with XFCE and weather-plugin
every 20 minutes - that's the interval the data are refreshed.

Please advise which additional information is needed.

Regards, Ingo


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

Bug#788547: nfs4 mount.nfs does not respect option "user" in fstab in Jessie

[Ingo]

Some additional information, discovered by accident:

What does completely fail, is the "mount" command as reported above
(mounting a nfs-export as user).

Executing mount.nfs as a user with full path does not respect the
mountpoint as configured in fstab:

~$ /sbin/mount.nfs leo:/Bilder
~$ mount.nfs: no mount point provided

Adding the mountpoint works for both mount and umount:

~$ /sbin/mount.nfs leo:/Bilder /home/ingo/leo.Bilder
~$ /sbin/umount.nfs /home/ingo/leo.Bilder

So, the dead end lies in /sbin/mount which is unable to evaluate the
fstab and parse it properly to mount.nfs.

Remark:
it is somehow strange that the mount-binary shrunk in filesize from 90kB
in Wheezy to only 40kB in Jessi?

So this bug should be assigned to package "mount" in Jessie as well.

Regards,
Ingo


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

Bug#790880: mount does not parse option "user" in fstab to mount.nfs and fails

[Ingo]

Package: mount
Version: 2.25.2-6
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
Trying to mount a nfs4-export as declared in fstab with option "user" as a 
normal user

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I already filed a bug on this against "mount.nfs" as bug # 788547.
But now it appears it is the "mount" command which does not handle th option 
user correctly. Seems it gets no attention there. This bug does not exist in 
Wheezy, showed up after upgrade to Jessie.
I already asked there to assign this bug also to the package "mount" without 
any reaction, so I do report it here against "mount".

   * What was the outcome of this action?
fstab entry:
leo:/Bilder /home/ingo/leo.Bilder nfs4 noauto,rw,user,soft,relatime 0 0

# showmount -e leo
Export list for leo:
/srv/nfs4/Bilder 192.168.33.0/24
/srv/nfs4192.168.33.0/24

Mounting as user (UID=1000) fails:
$ LANG=en_US.UTF-8 mount leo:/Bilder
mount: leo:/Bilder: No such file or directory

However it is possible to perform the mount as "root".

Umount as user (UID=1000) fails with same "non informative" message:
$ LANG=en_US.UTF-8 umount leo:/Bilder
umount: leo:/Bilder: No such file or directory

Using "mount.nfs" instead allows  mounting by a user:

Executing mount.nfs as a user with full path does not respect the
mountpoint as configured in fstab:

~$ /sbin/mount.nfs leo:/Bilder
~$ mount.nfs: no mount point provided

Adding the mountpoint works for both mount and umount:

~$ /sbin/mount.nfs leo:/Bilder /home/ingo/leo.Bilder
~$ /sbin/umount.nfs /home/ingo/leo.Bilder

This is a security flaw as users cannot mount/umount on demand without
root-privileges.

   * What outcome did you expect instead?
mount to work as it does in Wheezy and according to documentation (mount, 
fstab), which means respect the option "user"


-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mount depends on:
ii  libc6  2.19-18
ii  libmount1  2.25.2-6
ii  libselinux12.3-2
ii  libsmartcols1  2.25.2-6

mount recommends no packages.

Versions of packages mount suggests:
ii  nfs-common  1:1.2.8-9

-- 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#763811: gedit: Unable to open/handle plain text files containing a "zero byte"

[Ingo]

Package: gedit
Version: 3.12.2-2
Severity: normal
Tags: upstream

Dear Maintainer,

when trying to open (even to just read) a plain text file containing a
"zero byte" gedit is unable to display it correctly and does not allow to
edit and save it. "zero bytes" are not forbidden in plain text files and
are are used i.e. in programming languages.

This file which I do attach later is a logfile (only first 4 lines) as
generated and downloaded from my (commercial) router for internet access.
If the file gets bigger, gedit even displays rabbish. Commandline tools like
'cat' and also 'nano' handle this file correctly. 


-- Package-specific info:
Active plugins:

No plugin installed in $HOME.

Module versions:
  pkg-config unavailable


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

Kernel: Linux 3.16-2-amd64 (SMP w/4 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 gedit depends on:
ii  gedit-common   3.12.2-2
ii  gir1.2-peas-1.01.12.1-1
ii  gnome-icon-theme-symbolic  3.12.0-1
ii  gsettings-desktop-schemas  3.14.0-1
ii  iso-codes  3.56-1
ii  libatk1.0-02.12.0-1
ii  libc6  2.19-11
ii  libcairo-gobject2  1.12.16-5
ii  libcairo2  1.12.16-5
ii  libenchant1c2a 1.6.0-10.1
ii  libgdk-pixbuf2.0-0 2.30.8-1+b1
ii  libgirepository-1.0-1  1.42.0-1
ii  libglib2.0-0   2.42.0-1
ii  libgtk-3-0 3.12.2-3+b1
ii  libgtksourceview-3.0-1 3.12.3-1
ii  libpango-1.0-0 1.36.7-1
ii  libpangocairo-1.0-01.36.7-1
ii  libpeas-1.0-0  1.12.1-1
ii  libx11-6   2:1.6.2-3
ii  libxml22.9.1+dfsg1-4
ii  python3-gi 3.14.0-1
ii  python3-gi-cairo   3.14.0-1
pn  python3:any

Versions of packages gedit recommends:
ii  yelp3.12.0-1
ii  zenity  3.14.0-1

Versions of packages gedit suggests:
pn  gedit-plugins  

-- 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#763811: sample file adde to demonstrate failure

[Ingo]

Datum/Uhrzeit	Meldung
30.09.2014 15:21:59 192.168.33.12 Anmeldung erfolgreich. (G101)
30.09.2014 15:10:47 Die IPv6 Systemzeit wurde erfolgreich aktualisiert. (NT101)
30.09.2014 14:40:45 DNSv6-Fehler: Der angegebene Domainname kann nicht von 2003:180:2:8000::53  aufgelöst werden. Fehler: Timeout (P008)

Bug#710355: This will be a security issue for Jessie once it is frozen!

[Ingo]

Once Jessie is frozen, this will be a security issue for XFCE-desktop users:

*Not getting any notification on pending (security)-updates.*

The proposed solution as described in the previous message still works
perfectly.
Just using Gtk2-versions of update-manager and update-notifier should
also make MATE-desktop users happy.

Please leave users the choice between "package-kit" and "update-manager"
- at least when desktop environment supports it or even requires a
certain solution.


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

Bug#770064: pk-update-icon: Fails to work if network interface not managed by network-manager

[Ingo]

Package: pk-update-icon
Version: 1.0.0-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
Testing pk-update-icon (instead of update-manager + -notifier) in jessie with 
XFCE4

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Puged update-manager + update-notifier and installed pk-update-icon with all 
its dependencies.
Next day I booted up and did wait for almost 1 hour withount any notification
for available updates. Then in a X-term did
apt-get update
apt-get upgrade (showed 9 available updates), but I did not install 
them.
Rebooted.
   * What was the outcome of this action?
5 minutes after boot-up the notification appeared and showed the available 
updates.
Selecting "install" resulted i a pop-up saying "No network connection 
available" an exited
   * What outcome did you expect instead?
I did expect that the updates get installed and also the first step of updating 
the package list
is handled automatically.
As I for sure have a working internet connection configured in 
/etc/networ/interfaces:
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

I just commented out that configuration and let network-manager control
the interface eth0.

And - what a miracle: pk-update-icon works as expected"
*


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

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

Versions of packages pk-update-icon depends on:
ii  gnome-packagekit3.14.0-1
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-13
ii  libcairo2   1.14.0-2.1
ii  libfontconfig1  2.11.0-6.1
ii  libfreetype62.5.2-2
it  libgdk-pixbuf2.0-0  2.31.1-2+b1
ii  libglib2.0-02.42.0-2
ii  libgtk2.0-0 2.24.25-1
ii  libnotify4  0.7.6-2
ii  libpackagekit-glib2-18  1.0.1-1
ii  libpango-1.0-0  1.36.8-2
ii  libpangocairo-1.0-0 1.36.8-2
ii  libpangoft2-1.0-0   1.36.8-2
ii  libsqlite3-03.8.7.1-1
ii  libunique-1.0-0 1.1.6-5

pk-update-icon recommends no packages.

pk-update-icon 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#788546: Sorry for late answer, got no notification on your posting

[Ingo]

Das mit den Locales hat es nicht gebracht, da ist sowohl auf dem nas als
auch auf dem PC die gleiche:

PC:$ echo $LANG
de_DE.utf8

nas: $ echo $LANG
de_DE.UTF-8

But a workaround is documented in this Bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790880
which has been merged here. This states:

Using "mount.nfs" instead allows  mounting by a user:

Executing mount.nfs as a user with full path does not respect the
mountpoint as configured in fstab:

~$ /sbin/mount.nfs leo:/Bilder
~$ mount.nfs: no mount point provided

Adding the mountpoint works for both mount and umount:

~$ /sbin/mount.nfs leo:/Bilder /home/ingo/leo.Bilder
~$ /sbin/umount.nfs /home/ingo/leo.Bilder

That's why I assigned it also to Package: mount.

Today I checkes in Stretch: still the same issue.

Bug#771531: pk-update-icon: Necessary reboot is not notified

[Ingo]

Package: pk-update-icon
Version: 1.0.0-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
Today a dbus update for Jessie was available. During install
gnome-packagekit indicated by a computer symbol for package "dbus" the
necessarry reboot?
(don't know if thats the purpose of the symbol?)
I performed installation of the updates using packagekit's GUI.

   * What was the outcome of this action?
Update notification icon disappeared in the notification aerea - that's all.

   * What outcome did you expect instead?
Notification about a necessary reboot required after dbus-update.
This is handled correctly by good old "update-notifier" + "update-manager".

Remark:
Additionally, after installing the updates by GUI is finished
there are 2 identical pop-up windows (one precisely on top of the
other). So you have to click on the OK-button twice to close
gnome-packagekit


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
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 pk-update-icon depends on:
ii  gnome-packagekit3.14.0-1
ii  libatk1.0-0 2.14.0-1
ii  libc6   2.19-13
ii  libcairo2   1.14.0-2.1
ii  libfontconfig1  2.11.0-6.3
ii  libfreetype62.5.2-2
it  libgdk-pixbuf2.0-0  2.31.1-2+b1
ii  libglib2.0-02.42.0-2
ii  libgtk2.0-0 2.24.25-1
ii  libnotify4  0.7.6-2
ii  libpackagekit-glib2-18  1.0.1-1
ii  libpango-1.0-0  1.36.8-2
ii  libpangocairo-1.0-0 1.36.8-2
ii  libpangoft2-1.0-0   1.36.8-2
ii  libsqlite3-03.8.7.1-1
ii  libunique-1.0-0 1.1.6-5

pk-update-icon recommends no packages.

pk-update-icon 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#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie

[Ingo]

Am 24.07.2016 um 22:07 schrieb Andreas Henriksson:
>
> Are you sure this is the correct syntax? I would expect that you
> should specify the mountpoint (target directory) rather than the
> source of the mount. eg. mount /home/ingo/leo.Bilder
> Do using that still give you the same problem?

Great, at least that works as expected if target directory is used.

But "man mount" explicitely states:

"When mounting a filesystem mentioned in fstab or mtab, it suffices to
give only the device, or only the mount point."
Moreover my syntax (using the device/source has worked flawlewssly since
I am using Linux. In Debian I use it since Lenny! And it works if the
command is issued as 'root'.

>
> Might also be useful to have a log of what strace tells you about
> running the command.

For completenes here the stace output:

~$ strace -Ff -tt mount leo:/Bilder 2>&1 | tee strace-mount.log

09:54:06.486801 execve("/bin/mount", ["mount", "leo:/Bilder"], [/* 36
vars */]) = 0
09:54:06.487198 brk(0)  = 0x1295000
09:54:06.487350 fcntl(0, F_GETFD)   = 0
09:54:06.487410 fcntl(1, F_GETFD)   = 0
09:54:06.487438 fcntl(2, F_GETFD)   = 0
09:54:06.487465 access("/etc/suid-debug", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.487533 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.487571 mmap(NULL, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4315787000
09:54:06.487629 access("/etc/ld.so.preload", R_OK) = 0
09:54:06.487704 open("/etc/ld.so.preload", O_RDONLY|O_CLOEXEC) = 3
09:54:06.487742 fstat(3, {st_mode=S_IFREG|0644, st_size=28, ...}) = 0
09:54:06.48 mmap(NULL, 28, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0)
= 0x7f4315786000
09:54:06.487810 close(3)= 0
09:54:06.487846 open("/opt/lib/libmediaclient.so", O_RDONLY|O_CLOEXEC) = 3
09:54:06.487880 read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\35\0\0\0\0\0\0"...,
832) = 832
09:54:06.487914 fstat(3, {st_mode=S_IFREG|0755, st_size=64168, ...}) = 0
09:54:06.487948 mmap(NULL, 2161808, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4315359000
09:54:06.487981 mprotect(0x7f4315368000, 2093056, PROT_NONE) = 0
09:54:06.488017 mmap(0x7f4315567000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe000) = 0x7f4315567000
09:54:06.488061 close(3)= 0
09:54:06.488094 munmap(0x7f4315786000, 28) = 0
09:54:06.488130 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
09:54:06.488163 fstat(3, {st_mode=S_IFREG|0644, st_size=144332, ...}) = 0
09:54:06.488195 mmap(NULL, 144332, PROT_READ, MAP_PRIVATE, 3, 0) =
0x7f4315763000
09:54:06.488227 close(3)= 0
09:54:06.488259 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.488297 open("/lib/x86_64-linux-gnu/libmount.so.1",
O_RDONLY|O_CLOEXEC) = 3
09:54:06.488333 read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\254\0\0\0\0\0\0"...,
832) = 832
09:54:06.488366 fstat(3, {st_mode=S_IFREG|0644, st_size=284096, ...}) = 0
09:54:06.488400 mmap(NULL, 2383648, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4315113000
09:54:06.488432 mprotect(0x7f4315156000, 2097152, PROT_NONE) = 0
09:54:06.488465 mmap(0x7f4315356000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x43000) = 0x7f4315356000
09:54:06.488504 mmap(0x7f4315358000, 3872, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4315358000
09:54:06.488542 close(3)= 0
09:54:06.488577 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.488611 open("/lib/x86_64-linux-gnu/libselinux.so.1",
O_RDONLY|O_CLOEXEC) = 3
09:54:06.488644 read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20c\0\0\0\0\0\0"...,
832) = 832
09:54:06.488677 fstat(3, {st_mode=S_IFREG|0644, st_size=142728, ...}) = 0
09:54:06.488709 mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4315762000
09:54:06.488745 mmap(NULL, 2246896, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f4314eee000
09:54:06.488777 mprotect(0x7f4314f0f000, 2097152, PROT_NONE) = 0
09:54:06.488814 mmap(0x7f431510f000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x21000) = 0x7f431510f000
09:54:06.488852 mmap(0x7f4315111000, 6384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f4315111000
09:54:06.488890 close(3)= 0
09:54:06.488924 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such
file or directory)
09:54:06.488960 open("/lib/x86_64-linux-gnu/libc.so.6",
O_RDONLY|O_CLOEXEC) = 3
09:54:06.488995 read(3,
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P\34\2\0\0\0\0\0"...,
832) = 832
09:54:06.489028 fst

Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie

[Ingo]

Some additional Information which probably helps to find the root cause:

The very same beheaviour (as in Jessie) is still shown in Stretch.

I already tried to assign that bug to package "mount", but this was not
accepted. The corresponding bug report demonstrates some more
possibilities of "how you can workaroung" this faulty beheaviour.

See here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788547#12

Bug#788546: nfs4 mount.nfs does not respect option "user" in fstab in Jessie

[Ingo]

Am 01.08.2016 um 15:33 schrieb Andreas Henriksson:
> Hello again Ingo.
> 
> On Mon, Jul 25, 2016 at 10:13:29AM +0200, Ingo wrote:
>> Am 24.07.2016 um 22:07 schrieb Andreas Henriksson:
>>>
>>> Are you sure this is the correct syntax? I would expect that you
>>> should specify the mountpoint (target directory) rather than the
>>> source of the mount. eg. mount /home/ingo/leo.Bilder
>>> Do using that still give you the same problem?
>>
>> Great, at least that works as expected if target directory is used.
>>
>> But "man mount" explicitely states:
> [...]
> 
> You're right, the manpage explicitly says in multiple places
> that what you're doing should work... I'm still thinking ...
... to adjust the manpages?
> using the mountpoint is always preferrable/recommended though. ;)
> 
> I got a chance to discuss this with upstream and I'll try to summarize
> some of the useful information here for the record (and as a personal
> reminder for the future):
> 

> 
> Despite knowing where we stumble, it's not easy to come up with a solution
> that suites both the people who wants to avoid path disclosure and your
> usecase. Given you now know about using the mountpoint (which also
> upstream said is really the way to go when specifying mounts, rather
> than the source) would you agree that this isn't strictly Release Critical
> severity anymore?

I do agree!
Thanks to your explanation I understand the background and will change
my habits.

> 
> Hopefully everything works as you expect it to when you mount as non-root
> using "mount /mountpoint" or did you see any additional problems with that?

No further problems here with NFSv4 mounts, I won't forget what I have
learned with this bug.

Regards,
Ingo

Bug#831228: closed by Bart Martens (flashplugin-nonfree: update-flashplugin-nonfree references wrong version)

[Ingo]

An alternative solution is to apply the patch locally:

1. get the patch from
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=831228;filename=flash.patch;msg=15

2. Copy it into the directory /var/cache/flashplugin-nonfree/

3. change to that directory and apply the patch by executing:
"patch get-upstream-version.pl flash.patch"

Bug#831228: update-flashplugin-nonfree references wrong version

[Ingo]

Package: flashplugin-nonfree
Version: 1:3.6.1
Severity: important

# update-flashplugin-nonfree --status
Flash Player version installed on this system  : 11.2.202.626
Flash Player version available on upstream site: 22.0.0.209

Current latest version for Linux is 11.2.202.632

Bug#831228: update-flashplugin-nonfree references wrong version

[Ingo]

Shouldn't the bug severity be raised to "Grave" to get it fixed very
soon im Jessie?

This bug is not restricted to just query the plugin-version, it is also
used to install/update the plugin. Currently users are stuck with the
outdated version 11.2.202.626.

Current version 11.2.202.632 conmtains a lot of security fixes and Adobe
strongly recomends to update asap. This is pending since July 12.

Bug#1076566: sssd: removed from testing (trixie) breaks authentication on local network entirely

[Ingo]

Package: sssd
Version: 2.9.5-3
Severity: important
Tags: upstream

Dear Maintainer,

* What led up to the situation?
Doing full-upgrade on my testing (trixie) workstation.

* What exactly did you do (or not do) that was effective (or
* ineffective)?
~$ sudo apt full-upgrade

* What was the outcome of this action?
The sssd package and all its dependent packages are removed, e.g.
sssd-common, sssd-krb5, sssd-krb5-common, sssd-ldap, and so on (not a
complete list). This breaks authentication on all my testing
workstations on the local network. I cannot login anymore.

* What outcome did you expect instead?
Even if migration from unstable to testing fails the package should not
be removed entirely from testing. The latest migrated package should be
preserved. In this case it is sssd 2.9.4-1.
https://tracker.debian.org/pkg/sssd

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

Kernel: Linux 6.6.15-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1076646: linux-image-6.9.8-amd64: Errors reported with initializing amdgpu that works with older kernel

[Ingo]

Package: src:linux
Version: 6.9.8-1
Severity: normal

Dear Maintainer,

* What led up to the situation?
Regular upgrade of trixie.

* What exactly did you do (or not do) that was effective (or ineffective)?
sudo apt full-upgrade

* What was the outcome of this action?
On boot up the kernel reports errors with initializing amdgpu. It fails 
after a timeout and boot up takes a very long time. Detailed logs from 
the systemd journal see below.


* What outcome did you expect instead?
No error messages from the kernel and normal quick boot up as given with 
previous kernels.



-- Package-specific info:
** Version:
Linux version 6.9.8-amd64 (debian-ker...@lists.debian.org)
(x86_64-inux-gnu-gcc-13 (Debian 13.3.0-1) 13.3.0, GNU ld (GNU Binutils
for Debian) 2.42.50.20240625) #1 SMP PREEMPT_DYNAMIC Debian 6.9.8-1
(2024-07-07)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.9.8-amd64 root=/dev/mapper/titan.vg-deb13 ro 
b43.allhwsupport=1


product_name: Aspire 5253G
product_version: V1.15
chassis_vendor: Acer
chassis_version: V1.15
bios_vendor: Acer
bios_version: V1.15
board_vendor: Acer
board_name: JE50-BZ
board_version: Base Board Version

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 
14h Processor Root Complex [1022:1510]

Subsystem: Acer Incorporated [ALI] Device [1025:0520]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium 
>TAbort- SERR- 
Latency: 0

00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Wrestler [Radeon HD 6310] [1002:9802] (prog-if 00 [VGA 
controller])

Subsystem: Acer Incorporated [ALI] Device [1025:0521]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 27
Region 0: Memory at e000 (32-bit, prefetchable) [size=256M]
Region 1: I/O ports at 4000 [size=256]
Region 2: Memory at f040 (32-bit, non-prefetchable) [size=256K]
Expansion ROM at 000c [virtual] [disabled] [size=128K]
Capabilities: 
Kernel driver in use: radeon
Kernel modules: radeon, amdgpu

00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] 
Wrestler HDMI Audio [1002:1314]

Subsystem: Acer Incorporated [ALI] Device [1025:0520]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
SERR- 
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 29
Region 0: Memory at f0444000 (32-bit, non-prefetchable) [size=16K]
Capabilities: 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD/ATI] 
SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] [1002:4391] (prog-if 01 
[AHCI 1.0])

Subsystem: Acer Incorporated [ALI] Device [1025:0520]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium 
>TAbort- SERR- 
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: I/O ports at 4118 [size=8]
Region 1: I/O ports at 4124 [size=4]
Region 2: I/O ports at 4110 [size=8]
Region 3: I/O ports at 4120 [size=4]
Region 4: I/O ports at 4100 [size=16]
Region 5: Memory at f044c000 (32-bit, non-prefetchable) [size=1K]
Capabilities: 
Kernel driver in use: ahci
Kernel modules: ahci

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

Subsystem: Acer Incorporated [ALI] Device [1025:0520]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium 
>TAbort- SERR- 
Latency: 64, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at f044b000 (32-bit, non-prefetchable) [size=4K]
Kernel driver in use: ohci-pci
Kernel modules: ohci_pci

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

Subsystem: Acer Incorporated [ALI] Device [1025:0520]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium 
>TAbort- SERR- 
Latency: 64, Cache Line Size: 64 bytes
I

Bug#1069425: uid-wrapper: FTBFS on armhf: 15: [ LINE ] --- ./tests/test_syscall.c:53: error: Failure!

[Ingo]

On Sun, 21 Jul 2024 23:00:48 +0200 Drew Parsons  wrote:

Just to be clear, I'm not supporting dropping armv7 support.

It's only one test that's failing.  Skipping the one test (on 32-bit 
arm) is all that's needed.  It's passing the other tests.


Yes, that's what I mean. But a failing test indicates a failure on 
platform with armv7. Skipping the test may result in an unexpected 
behavior on that platform.


Ingo


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1032256: Additional information

[Ingo]

I found further information on my device (ear-buds) in
/var/lib/bluetooth/80:38:FB:D6:A7:62/3C:F8:A8:B9:CE:A1/info:

Name=Hama Freedom Light
Class=0x240404
SupportedTechnologies=BR/EDR;
Trusted=true
Blocked=false
Services=110b--1000-8000-00805f9b34fb;110c--1000-8000-00805f9b34fb;110d--1000-8000-00805f9b34fb;110e--1000-8000-00805f9b34fb;111e--1000-8000-00805f9b34fb;1200--1000-8000-00805f9b34fb;

[DeviceID]
Source=1
Vendor=1494
Product=10
Version=576

[LinkKey]
Key=< 32 hex characters long, maybe secret? >
Type=4
PINLength=0