Bug#1059871: alsa-ucm-conf should be a required package by libasound2-data, it's essential on some sound hardware

2024-01-02 Thread Marc MERLIN 
Package: libasound2-data
Version: 1.2.10-3

As per https://github.com/thesofproject/linux/issues/4758 ,
alsa-ucm-conf is absolutely required for any sound to come out on
speakers on a Dell 9730. Without it, you get sound on headphones, but
the speakers won't work, and there is nothing you can unmute with
alsamixer. I tried literally all alsamixer channels, nothing worked or
did anything for the speakers.

After may many hours (by that I mean over 10 hours over many days of
googling, building new kernels, diffing ubuntu where sound worked, and
debian 12 where sound did not work), I got notwhere until this bug and
being told about alsa-ucm-conf I had never heard about and was mentioned
nowhere in the copious pages I read (most talked about alsamixer,
pipewire and wireplumber that add their own levels of things that can go
wrong)

So the 2 bugs, I'd lke to file here
1) This should be a Requires, not Recommends
Package: libasound2-data
Source: alsa-lib
Version: 1.2.8-1
Installed-Size: 200
Maintainer: Debian ALSA Maintainers 
Architecture: all
Replaces: libasound2 (<< 1.2.8-1)
Recommends: alsa-ucm-conf, alsa-topology-conf

2) Package gives 0 clue that it is an absolutely essential pacakge for
some sound hardware.

Package: alsa-ucm-conf
Version: 1.2.10-1
Installed-Size: 828
Maintainer: Debian ALSA Maintainers 
Architecture: all
Depends: libasound2 (>= 1.2.7)
Description-en: ALSA Use Case Manager configuration files
 This package contains ALSA Use Case Manager configuration of audio
 input/output names and routing for specific audio hardware. They can be
 used with the alsaucm tool.

Thanks for making it more clear that this package is very essential for
some hardware that needs something close to half-secret knock code
before speakers will work.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
 
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

Bug#955309: ZM 1.32.3-2 upgrade from 1.30 (i386) broke many monitors

2020-03-29 Thread Marc MERLIN 
Package: zoneminder
Version: 1.32.3-2

I asked for help on ZM forums, lots of details here
https://forums.zoneminder.com/viewtopic.php?f=38=28830

I tried many things, but at the end of the day the agreement is that the 
1.32 debian package is broken, and it's also obsolete as it contains many bugs
fixed in newer versions.
This doesn't mean there was anything wrong with the packaging, but that
the ZM version at the time was unfortunately broken.

I have found no newer versions that work in i386 (the single one I found
required a lot of systemd dependencies I can't install all, I tried, but
failed). I also found amd64 packages, but hat's not compatible with my
system.

I would really love an up to date ZM package for i386, ideally without
any requirement on systemd.
I looked into building my own, but it looks somewhat non trivial.

Can you help by releasing a newer package?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
 
Home page: http://marc.merlins.org/   | PGP 7F55D5F27AAF9D08

Bug#888237: Fwd: Re: diffoscope and file renames

2018-01-24 Thread Marc MERLIN 
On Wed, Jan 24, 2018 at 05:21:08PM +0530, Chris Lamb wrote:
> [Adding m...@merlins.org to CC - please retain all CCs when replying!]
> 
> Hi Marc!
> 
> Thanks again for your bug report.
> 
> > I just installed the debian/unstable version and got version 90, indeed
> > a big jump :)
> > 
> > Seems the same though:
> 
> Ah! Do you have the optional "python3-tlsh" installed? This does the fuzzy
> matching heavy lifting:

I did not, and in this case, I should have looked at all the suggested
dependencies, although they were kind of daunting as you mentioned in
your talk if I installed them out.

I had no idea I should have installed it, and indeed I was missing it.

Thanks for the pointer and sorry for the false alert.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901

Bug#858296: Info received (/usr/lib/xorg/modules/drivers/modesetting_drv.so: driver spams log file with page flip failure complaints)

2017-07-17 Thread Marc MERLIN 
I have opened this bug to track the issue with the intel folks:
https://bugs.freedesktop.org/show_bug.cgi?id=101825
and in my case the workaround was to blacklist the nouveau driver.
However, this now prevents me from mirroring my display onto the nvidia
chip, which is required to display things on my hdmi or DP external
connections.
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/

Bug#858296: Info received (/usr/lib/xorg/modules/drivers/modesetting_drv.so: driver spams log file with page flip failure complaints)

2017-07-06 Thread Marc MERLIN 
More info:
1) Skylake CPU
2) I've already removed all the module loading options for i915. Now I have:
saruman:~#  grep . /sys/module/i915/parameters/*
/sys/module/i915/parameters/alpha_support:0
/sys/module/i915/parameters/disable_display:N
/sys/module/i915/parameters/disable_power_well:1
/sys/module/i915/parameters/edp_vswing:0
/sys/module/i915/parameters/enable_cmd_parser:Y
/sys/module/i915/parameters/enable_dc:-1
/sys/module/i915/parameters/enable_dpcd_backlight:N
/sys/module/i915/parameters/enable_dp_mst:Y
/sys/module/i915/parameters/enable_execlists:1
/sys/module/i915/parameters/enable_fbc:1
/sys/module/i915/parameters/enable_guc_loading:0
/sys/module/i915/parameters/enable_guc_submission:0
/sys/module/i915/parameters/enable_gvt:N
/sys/module/i915/parameters/enable_hangcheck:Y
/sys/module/i915/parameters/enable_ips:1
/sys/module/i915/parameters/enable_ppgtt:3
/sys/module/i915/parameters/enable_psr:0
/sys/module/i915/parameters/enable_rc6:1
/sys/module/i915/parameters/error_capture:Y
/sys/module/i915/parameters/fastboot:N
/sys/module/i915/parameters/force_reset_modeset_test:N
/sys/module/i915/parameters/guc_log_level:-1
/sys/module/i915/parameters/inject_load_failure:0
/sys/module/i915/parameters/invert_brightness:0
/sys/module/i915/parameters/load_detect_test:N
/sys/module/i915/parameters/lvds_channel_mode:0
/sys/module/i915/parameters/lvds_use_ssc:-1
/sys/module/i915/parameters/mmio_debug:0
/sys/module/i915/parameters/modeset:1
/sys/module/i915/parameters/nuclear_pageflip:N
/sys/module/i915/parameters/panel_ignore_lid:1
/sys/module/i915/parameters/prefault_disable:N
/sys/module/i915/parameters/reset:Y
/sys/module/i915/parameters/semaphores:0
/sys/module/i915/parameters/use_mmio_flip:0
/sys/module/i915/parameters/vbt_sdvo_panel_type:-1
/sys/module/i915/parameters/verbose_state_checks:Y

-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/

Bug#858296: /usr/lib/xorg/modules/drivers/modesetting_drv.so: driver spams log file with page flip failure complaints

2017-07-06 Thread Marc MERLIN 
I'm also seeing gobs of
[  5031.435] (WW) modeset(0): flip queue failed: Invalid argument
[  5031.435] (WW) modeset(0): Page flip failed: Invalid argument
[  5031.435] (EE) modeset(0): present flip failed
[  5031.519] (WW) modeset(0): flip queue failed: Invalid argument
[  5031.519] (WW) modeset(0): Page flip failed: Invalid argument
[  5031.519] (EE) modeset(0): present flip failed


saruman:~$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7a cap: 0xf, Source Output, Sink Output, Source Offload,
Sink Offload crtcs: 3 outputs: 1 associated providers: 0 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload,
Sink Offload crtcs: 4 outputs: 3 associated providers: 0 name:modesetting

[73.575] (II) xfree86: Adding drm device (/dev/dri/card1)
[73.576] (II) xfree86: Adding drm device (/dev/dri/card0)
[73.588] (--) PCI:*(0:0:2:0) 8086:191b:17aa:222d rev 6, Mem @
0xd200/16777216, 0x6000/536870912, I/O @ 0x6000/64, BIOS @
0x/131072
[73.588] (--) PCI: (0:1:0:0) 10de:13b2:17aa:222d rev 162, Mem @
0xd300/16777216, 0xc000/268435456, 0xd000/33554432, I/O @
0x5000/128, BIOS @ 0x/524288
[73.597] (II) LoadModule: "modesetting"
[73.597] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[73.598] (II) Module modesetting: vendor="X.Org Foundation"
[73.598]compiled for 1.19.2, module version = 1.19.2
[73.598]Module class: X.Org Video Driver
[73.598]ABI class: X.Org Video Driver, version 23.0
[73.598] (II) LoadModule: "fbdev"
[73.598] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[73.598] (II) Module fbdev: vendor="X.Org Foundation"
[73.598]compiled for 1.19.0, module version = 0.4.4
[73.598]Module class: X.Org Video Driver
[73.598]ABI class: X.Org Video Driver, version 23.0
[73.598] (II) LoadModule: "vesa"
[73.598] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[73.599] (II) Module vesa: vendor="X.Org Foundation"
[73.599]compiled for 1.19.0, module version = 2.3.4
[73.599]Module class: X.Org Video Driver
[73.599]ABI class: X.Org Video Driver, version 23.0
[73.599] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[73.599] (II) FBDEV: driver for framebuffer: fbdev
[73.599] (II) VESA: driver for VESA chipsets: vesa
[73.637] (II) modeset(0): using drv /dev/dri/card0
[73.637] (II) modeset(G0): using drv /dev/dri/card1

ii  libdrm-intel1:amd642.4.74-1
ii  xserver-xorg-core  2:1.19.2-1
ii  xserver-xorg-video-intel   2:2.99.917+git20161206-1

Bug#855803: xserver-xorg-video-intel 2:2.99.917+git20161206-1 improve NEWS.Debian

2017-02-21 Thread Marc MERLIN 
Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20161206-1

This is a followup to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854934 
which because it's closed, my update seem to have gone nowwhere.

NEWS.Debian could definitely be improved. I did read it during upgrade
time, and what I read did not warn me that the new driver could just
stop being autodetected and not load at all as a result.

When read that message, it did not seem like it was the problem I was
having. Let me explain so that you can maybe improve the message?

1) I have been using modsetting for a long time (at least I
thought/think I was), so that part of the message did not seem
relevant to me.

2) you mention "triggers bugs" which read to me like "cause display problems"
not "The driver will fail to detect your hardware and not even load"
Note that average user will probably not even notice that the X server
fell back to vesa or framebuffer mode (I did however).
Could you add a blurb mentioning "this may cause the driver not to
detect your hardware and refuse to load, requiring the driver to be
manually loaded in xorg.conf" ?

3) you say "please file them against the xserver"
Can you add details on which package exactly?
xserver-xorg-core ?

Ultimately I'm still not super clear what's going on, the core server
talks to each driver to auto detect hardware and load the driver, or
not.
Is the bug in the core server where it somehow fails to load the intel
driver, or is the intel driver failing the initial autodetection,
requiring a force load to actually work?

As an extra suggestion, I know you said intel does not make releases of
the intel driver, which is a shame, but would you consider versioning
the driver on your side at least to reflect changes in abi
compatibility?
In this case, between 201602 and 201612, the driver changed abi version
and there was no way to apt-get install an older one. I had to manually 
fetch one from /var/cache/apt/archives/ on my system and be thankful
that I always keep old packages to revert in cases just like this one.
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901

Bug#854934: xserver-xorg-video-intel 2:2.99.917+git20161206-1 removed intel skylake support?

2017-02-12 Thread Marc MERLIN 
Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20161206-1

I've been using xserver-xorg-video-intel 2:2.99.917+git20160218-1 for quite
a while on a thinkpad P70 (skylake) without problems.

I've recently upgraded to xserver-xorg-video-intel 2:2.99.917+git20161206-1
and after doing this, the intel driver would not load when I started X
anymore -logverbose 9 didn't show anything outside of the fact that the
driver was not loading.
Reverting to 2:2.99.917+git20160218-1 (and downgrading to 
xserver-common_2%3a1.18.1-1_all.deb xserver-xorg-core_2%3a1.18.1-1_amd64.deb
due to ABI compatibility) fixes the problem.


X worked fine with the old driver and output:
[46.135] (II) xfree86: Adding drm device (/dev/dri/card0)
[46.152] (--) PCI:*(0:0:2:0) 8086:191b:17aa:222d rev 6, Mem @ 
0xd200/16777216, 0x6000/536870912, I/O @ 0x6000/64, BIOS @ 
0x/131072
[46.152] (--) PCI: (0:1:0:0) 10de:13b2:17aa:222d rev 162, Mem @ 
0xd300/16777216, 0xc000/268435456, 0xd000/33554432, I/O @ 
0x5000/128, BIOS @ 0x/524288
[46.152] (II) LoadModule: "glx"
[46.153] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[46.161] (II) Module glx: vendor="X.Org Foundation"
[46.161]compiled for 1.18.1, module version = 1.0.0
[46.161]ABI class: X.Org Server Extension, version 9.0
[46.161] (**) AIGLX enabled
[46.161] (==) Matched intel as autoconfigured driver 0
[46.161] (==) Matched intel as autoconfigured driver 1
[46.161] (==) Matched modesetting as autoconfigured driver 2
[46.161] (==) Matched fbdev as autoconfigured driver 3
[46.161] (==) Matched vesa as autoconfigured driver 4
[46.161] (==) Assigned the driver to the xf86ConfigLayout
[46.161] (II) LoadModule: "intel"
[46.161] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
[46.165] (II) Module intel: vendor="X.Org Foundation"
[46.165]compiled for 1.18.1, module version = 2.99.917
[46.165]Module class: X.Org Video Driver
[46.165]ABI class: X.Org Video Driver, version 20.0
[46.165] (II) LoadModule: "modesetting"
[46.166] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[46.166] (II) Module modesetting: vendor="X.Org Foundation"
[46.166]compiled for 1.18.1, module version = 1.18.1
[46.166]Module class: X.Org Video Driver
[46.166]ABI class: X.Org Video Driver, version 20.0
[46.166] (II) LoadModule: "fbdev"
[46.166] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[46.167] (II) Module fbdev: vendor="X.Org Foundation"
[46.167]compiled for 1.18.0, module version = 0.4.4
[46.167]Module class: X.Org Video Driver
[46.167]ABI class: X.Org Video Driver, version 20.0
[46.167] (II) LoadModule: "vesa"
[46.167] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[46.167] (II) Module vesa: vendor="X.Org Foundation"
[46.167]compiled for 1.18.0, module version = 2.3.4
[46.167]Module class: X.Org Video Driver
[46.167]ABI class: X.Org Video Driver, version 20.0
[46.167] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets:
i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G,
915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM,
Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33,
GM45, 4 Series, G45/G43, Q45/Q43, G41, B43
[46.167] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000
[46.167] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100
[46.167] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 6200, 
P6300
[46.167] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[46.167] (II) FBDEV: driver for framebuffer: fbdev
[46.167] (II) VESA: driver for VESA chipsets: vesa
[46.203] (II) intel(0): Using Kernel Mode Setting driver: i915, version 
1.6.0 20161121
[46.203] (II) intel(0): SNA compiled: xserver-xorg-video-intel 
2:2.99.917+git20160218-1 (Timo Aaltonen )
[46.203] (II) intel(0): SNA compiled for use with valgrind


With the new driver, Loadmodule Intel never happens:
[  3141.109] (II) xfree86: Adding drm device (/dev/dri/card0)
[  3141.121] (--) PCI:*(0:0:2:0) 8086:191b:17aa:222d rev 6, Mem @ 
0xd200/16777216, 0x6000/536870912, I/O @ 0x6000/64, BIOS @ 
0x/131072
[  3141.121] (--) PCI: (0:1:0:0) 10de:13b2:17aa:222d rev 162, Mem @ 
0xd300/16777216, 0xc000/268435456, 0xd000/33554432, I/O @ 
0x5000/128, BIOS @ 0x/524288
[  3141.121] (II) LoadModule: "glx"
[  3141.121] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[  3141.123] (II) Module glx: vendor="X.Org Foundation"
[  3141.123]compiled for 1.19.1, module version = 1.0.0
[  3141.124]ABI class: X.Org Server Extension, version 10.0
[  3141.124] (==) Matched modesetting as autoconfigured driver 0
[  3141.124] (==) Matched fbdev as

Bug#845153: new ifconfig has incompatible output, please revert

2016-11-23 Thread Marc MERLIN 
First, thanks for your answer.

On Wed, Nov 23, 2016 at 04:25:42PM +0100, Martín Ferrari wrote:
> > Well, never mind, that new ifconfig output is almost entirely different
> > from the old one, the one that's been around for 20 years and that
> > countless people rely on being that way.
> 
> I am sorry these changes have caused you problems. What happens is that
> nettools has been unmaintained for a very long time, that's why nothing
> has changed in all these years.

Understood. It had become a de facto API though, whether that was desired,
or not.

> Now upstream is working again, fixing many issues and adding features.
> As part of that, they have changed some of the tools' output.

Needlessly so, just enough to break just about anyone parsing ifconfig
output.
I'm specifically unhappy because the breakage was really "just because"

> These days, I'd recommend parsing the one-line format from iproute2:
> # ip -o addr list
 
Just looked at it
1) it's worse output to parse
3: wlan0inet 192.168.205.9/24 brd 192.168.205.255 scope global wlan0\ 
valid_lft forever preferred_lft forever

2) if ifconfig output can be changed now, who says ip output (which quite
frankly is weird looking in comparison) will not change too?

This is madness

> But this can change too, and has changed in the past. I had already to
> fix code that broke because of those changes.

Correct.

> I understand you are frustrated. But I don't want to patch this in
> Debian, nor I want to try to convince upstream to revert the output
> format, as the old one had many problems. You are free to discuss this
> issue with them, though.

I hear that you don't want to unbreak ifconfig locally in debian, I was
hoping you'd be willing to relay to them, but if not, I will.

On your side, this is sadly a gravely incompatible update that will
break an unknown amount of users as it rolls out. At the very least, you
should have some pre-install warning because once you're hit by the problem
1) your machine is likely not to reboot and come back on the net, or your
networking related stuff will break
2) people will waste valueable time tyring to figure out what broke,
potentially in a stressful environment (server down, slow serial console,
possibly on call late at night).

If debian had at had least warned me this was a potentially dangerous
upgrade, I would have stopped it an looked at it later in a proper
environment.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/

Bug#845153: new ifconfig has incompatible output, please revert

2016-11-20 Thread Marc MERLIN 
Package: net-tools
Version: 1.60+git20150829.73cef8a-2

before:
eth0 Link encap:Ethernet HWaddr bc:ae:c5:e3:33:fa
inet addr:192.168.205.3 Bcast:192.168.205.255 Mask:255.255.255.0
inet6 addr: 2603:3024:180d:9900:beae:c5ff:fee3:33fa/64 Scope:Global
inet6 addr: fe80::beae:c5ff:fee3:33fa/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7270392 errors:0 dropped:0 overruns:0 frame:0
TX packets:4543918 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:10473484308 (9.7 GiB) TX bytes:312638423 (298.1 MiB)

after:
eth0: flags=4163 mtu 1500
inet 192.168.205.3 netmask 255.255.255.0 broadcast 192.168.205.255
inet6 2603:3024:180d:9900:beae:c5ff:fee3:33fa prefixlen 64 scopeid 0x0
inet6 fe80::beae:c5ff:fee3:33fa prefixlen 64 scopeid 0x20
ether bc:ae:c5:e3:33:fa txqueuelen 1000 (Ethernet)
RX packets 7078604 bytes 10198858797 (9.4 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4416898 bytes 303820942 (289.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

let's add ":" after the interface name, so that if you have eth0:0, you
end up with eth0:0:
let's remove "addr' after 'inet' so that it can break every single
script that gets the ip address from ifconfig output.

Well, never mind, that new ifconfig output is almost entirely different
from the old one, the one that's been around for 20 years and that
countless people rely on being that way.

Sure, parsing ifconfig output is not great, but countless stuff on the
internet does it. ipmasq, a package I've been using for 15 years to do
custom firewalling heavily parses ifconfig output, and it's only one
amongst many. Also, sorry, but I don't think there is an easy way to get
the IP from an interface, or even your default GW in shell.

Obviously this came from upstream, please forward this complaint to them
and/or ensure that this new (IMO broken) ifconfig does not spread
further in debian.
If someone feels the need to change ifconfig output that much, they can
call it ifconfig2, or ip2.

Thank you
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901

Bug#844652: mdadm 3.4-4's new initramfs script location broke my system boot

2016-11-17 Thread Marc MERLIN 
Package: mdadm
Version: 3.4-4

Howdy,

The old mdadm had scripts/local-top/mdadm
Due to maybe random lucky ordering, it was being run on my system before
local-top/cryptroot

My system's rootfs is an raid1 which used to be detected by the kernel
a long time ago, but that's been deprecated and does not work anymore.
Now it relies on an mdadm command for it to show up and work.
Without it showing up, cryptroot does not have a partition it can mount
from and everything falls over
I boot with:
root=/dev/mapper/cryptroot ro rootflags=subvol=root 
cryptopts=source=/dev/md13,keyscript=/sbin/cryptgetpw

Anyway, it's been working fine for years, until I upgraded mdadm and it
all broke because mdadm moved its initramfs init script to run much
later (too late) in the initramfs process (local-block/mdadm):

> Begin: Mounting root file system ... Begin: Running /scripts/local-top ...   
> Reading all physical volumes.  This may take a while...
> Begin: Waiting for encrypted source device... ...   Reading all physical 
> volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
> (...)
>   Reading all physical volumes.  This may take a while...
>   Reading all physical volumes.  This may take a while...
> done.
>   ALERT! /dev/md13 does not exist.
> Check cryptopts=source= bootarg: cat /proc/cmdline
> or missing modules, devices: cat /proc/modules; ls /dev
> -r Dropping to a shell. Will skip /dev/md13 if you can't fix.
> Rebooting automatically due to panic= boot argument
> done.

To recover, I had to manually copy the old scripts/local-top/mdadm from
the old mdadm package, and copy it in 
/usr/share/initramfs-tools/scripts/local-top/a_mdadm

This also sadly cost me quite a bit of unexpected downtime and 4 to 6H
of slow debugging since I thought my problem was due to a new kernel and
in fact it was simply that any new initrd created was unable to boot
because of an mdadm upgrade, and not due to the kernel (my old kernels
had an old generated initrd that still worked).

Now, I still seem to rely on pseudo random ordering to run mdadm before 
cryptroot but I'm not sure the mdadm package is able to stick itself as
prereq of the cryptroot script...

Either way, this upgrade broke me and may brake others.
I realize the whole thing is not trivial. What do you think is the
right fix foreveryone?

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/

Bug#815726: initramfs-tools requires newer coreutils for ln -r

2016-02-23 Thread Marc MERLIN 
Package: initramfs-tools
Version: 0.123

Upgrading initramfs-tools creates non working initrds if you don't upgrade
coreutils;
Adding config /etc/initramfs-tools/conf.d/resume
Adding binary-link /sbin/modprobe
ln: invalid option -- 'r'
Try `ln --help' for more information.
Adding binary /bin/kmod
Adding library-link /lib/x86_64-linux-gnu/libc.so.6
(...)

Fix was:
Unpacking coreutils (8.24-1) over (8.13-3) ...

But initramfs-tools should have a dependency on the minimal coreutils it
needs to avoid such issues.

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/

Bug#783143: docker.io does not need cgroupfs-mount

2015-04-22 Thread Marc MERLIN 
Package: docker.io
Version: 1.6.0~rc4~dfsg1-1
Severity: normal

Bug 782480 was poorly worded, closed, and left closed after I explained what
went wrong, so I'm opening a new bug.

docker.io recommends cgroupfs-mount which doesn't do anything useful since
docker.io already ships cgroupfs_mount in its initscript.

By default apt will install cgroupsfs-mount and mountall (which does nothing
useful on debian, it was written for ubuntu and upstart), and in turn
plymouth (likely because mountall requires plymouth on ubuntu)).

docker.io does not need any of cgroupfs-mount, mountall, or plymouth.

Can you please remove this dependency, even if it's just a recommend?

Thanks,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


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

Bug#783140: docker.io could help users misconfigured with /sys/fs/cgroup mounted in fstab

2015-04-22 Thread Marc MERLIN 
Package: docker.io
Version: 1.6.0~rc4~dfsg1-1
Severity: normal

docker.io will not work if you have this in fstab
cgroup /sys/fs/cgroup  cgroup  defaults0   0

But the initscript just runs, skips the cgroup mounting and doesn't tell the
user that docker will not work, or why.

It's not a bug with the package, just something it doesn't catch for people
with old systems that mounted cgroups differently.
Docker than fails and it's not super obvious to fix.

I had the above line to mount /sys/fs/cgroup in my fstab

The docker initscript in your package does already mount everything in
/sys/fs/cgroup/* just fine, but fails if the above is mounted from fstab.

No problem, 
/usr/share/docker.io/contrib/check-config.sh
reports the error, but due to apparently a kernel bug, unmounting 
/sys/fs/cgroup as cgroup, making one as tmpfs, and trying to mount the
cgroup subdirs fails with:
mount: cgroup is already mounted or /sys/fs/cgroup/cpuset busy
   cgroup is already mounted on /sys/fs/cgroup

I finally found on the net that there seems to be no fix but rebooting
and sure enough, rebooting fixed this.

I have kernel 3.19, and I can swear that I had no cgroups mounted anywhere when 
I
got this error.

It could be useful for the docker initscript to detect this, and give an 
error message to remove the fstab line, and tell the user to reboot (for
real) to clear the cgroup state in the kernel and allow subdir cgroup
mounts.


This is the unfixed kernel bug:
https://bugzilla.kernel.org/show_bug.cgi?id=60795


The same bug also happens in reverse:
docker is working, unmount cgroups
legolas:~# umount /sys/fs/cgroup/*
legolas:~# /etc/init.d/docker stop
[ ok ] Stopping Docker: docker.
legolas:~# umount /sys/fs/cgroup
legolas:~# mount -t cgroup cgroup /sys/fs/cgroup
mount: cgroup is already mounted or /sys/fs/cgroup busy
legolas:~# grep cgroup /proc/mounts
legolas:~# 

Thanks,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


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

Bug#783143: docker.io does not need cgroupfs-mount

2015-04-22 Thread Marc MERLIN 
On Wed, Apr 22, 2015 at 02:03:25PM -0600, Tianon Gravi wrote:
 On 22 April 2015 at 13:32, Marc MERLIN marc_s...@merlins.org wrote:
  By default apt will install cgroupsfs-mount and mountall (which does nothing
  useful on debian, it was written for ubuntu and upstart), and in turn
  plymouth (likely because mountall requires plymouth on ubuntu)).
 
 You can install and use upstart in Debian, and it's still a fully
 supported init system at this point.
 
I didn't realize that, thanks for correcting me.

 As to this specific issue, I'm more inclined to figure out why
 cgroupfs-mount (and the cgroup-lite package it descended from) felt
 the need to include mountall in the first place, and see if we can

If that can be fixed, it would also address my concern.

 I'd also be +1 to patching out the /sys/fs/cgroup code from the
 upstream init scripts since it really falls very directly under
 Convenience copies of code (Debian Policy 4.13 [1]), and upstream
 includes it to be more tolerant of systems that don't have either
 cgroupfs-mount or cgroup-lite available (older suites, for example,
 like Ubuntu Precise).

Ah, I see, so you prefer to
1) remove the cgroup mounting code from the docker.io initscript
2) make cgroupfs-mount required instead of recommended
3) fix cgroupfs-mount not to require mountall

If so, that sounds like a fine alternative plan to me.

Thanks
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


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

Bug#782480: docker.io: Recommends on cgroupfs-mount mountall plymouth from ubuntu is very suboptimal

2015-04-12 Thread Marc MERLIN 
Package: docker.io
Version: 1.6.0~rc4~dfsg1-1
Severity: normal

Dear Maintainer,

docker.io recommends cgroupfs-mount which in turn installs ubuntu stuff
I don't want full of upstart configs, including plymouth which I really
don't want on my system.

And from what I can tell this is only because of a single shell script
/usr/bin/cgroupfs-mount
which only does this:
legolas:~# /usr/local/bin/cgroupfs-mount 
cgroups mounted from fstab, not mounting /sys/fs/cgroup
or mounts the directory for those who don't have it in fstab.

I haven't looked in great details, but is this dependency chain really
just for a single mount which I can add as one line in my fstab (and
already had)?

If so, could you please just add this one script to the docker package
as opposed to bloating debian with a bunch of ubuntu packages that don't
belong? (especially plymouth and all those upstart configs?)

Thanks,
Marc


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (650, 'testing'), (600, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.3-amd64-i915-volpreempt-20150327ds1 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages docker.io depends on:
ii  adduser  3.113
ii  init-system-helpers  1.18
ii  iptables 1.4.20-2
ii  libapparmor1 2.8.0-1+b2
ii  libc62.19-13
ii  libdevmapper1.02.1   2:1.02.90-2.1
ii  libsqlite3-0 3.8.6-1
ii  perl 5.20.1-3

Versions of packages docker.io recommends:
ii  aufs-tools1:3.2+20130722-1.1
ii  ca-certificates   20140325
pn  cgroupfs-mount | cgroup-lite  none
ii  git   1:2.0.1-1
ii  xz-utils  5.1.1alpha+20110809-3

Versions of packages docker.io suggests:
ii  btrfs-tools  3.17-1.1
ii  debootstrap  1.0.53
ii  lxc  0.9.0~alpha3-2+deb8u1
pn  rinsenone

-- 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#781002: initramfs-tools: no kernel modules are insert into initrd

2015-04-02 Thread Marc MERLIN 
On Thu, Apr 02, 2015 at 02:29:28PM +0200, maximilian attems wrote:
 On Wed, Apr 01, 2015 at 06:10:05PM -0700, Marc MERLIN wrote:
  Could I make a few suggestions while we're at it?
  1) I sometimes build an initrd for a kernel I haven't installed yet. Yes,
  it's a mistake, but it happily succeeds and creates an initrd without any
  modules which then creates a non booting system.
  = initramfs should abort if its generated /lib/modules/kernel is empty
 
 I thought this was caught.
  
I have multiple initrd images that show otherwise, including this bug :)

  2) initramfs creates a temporary directory where it puts everything, and
  then deletes it before you can inspect it for debugging.
  = Add a --debug that leaves that directory behind for inspection.
  Right now I have to unpack the initrd image which is more and more of a
  pain as it becomes a bundled binary of concatenated cpio images and god
  knows what.
 
 -k :P
 as usual read the nice man mkinitramfs (;

Argh. I need new eyes... Sorry.

  3) document the binwalk method of unpacking initrd to debug if needed
  (somewhere in the manpage):
  http://unix.stackexchange.com/questions/163346/why-is-it-that-my-initrd-only-has-one-directory-namely-kernel
  .
  Or for the archives:
  legolas [mc]# binwalk initrd.img
  pick up the offset of the 2nd initrd image, and unpack like so:
  legolas [mc]# cd subdir; dd if=../initrd.img bs=21136 skip=1 | gunzip |
  cpio -idv
 
 lsinitramfs shows you the content.

Yes, I found that, that's better, but sometimes you do want to actually
unpack it to physically inspect the inside (like why is my modules.dep file
21 bytes, what's inside?).

Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


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

Bug#781002: initramfs-tools: no kernel modules are insert into initrd

2015-04-01 Thread Marc MERLIN 
Could I make a few suggestions while we're at it?
1) I sometimes build an initrd for a kernel I haven't installed yet. Yes,
it's a mistake, but it happily succeeds and creates an initrd without any
modules which then creates a non booting system.
= initramfs should abort if its generated /lib/modules/kernel is empty

2) initramfs creates a temporary directory where it puts everything, and
then deletes it before you can inspect it for debugging.
= Add a --debug that leaves that directory behind for inspection.
Right now I have to unpack the initrd image which is more and more of a
pain as it becomes a bundled binary of concatenated cpio images and god
knows what.

3) document the binwalk method of unpacking initrd to debug if needed
(somewhere in the manpage):
http://unix.stackexchange.com/questions/163346/why-is-it-that-my-initrd-only-has-one-directory-namely-kernel
.
Or for the archives:
legolas [mc]# binwalk initrd.img
pick up the offset of the 2nd initrd image, and unpack like so:
legolas [mc]# cd subdir; dd if=../initrd.img bs=21136 skip=1 | gunzip |
cpio -idv


Thanks for your work,
Marc


On Mon, Mar 30, 2015 at 4:02 AM, Ian Campbell i...@debian.org wrote:

 On Fri, 2015-03-27 at 06:47 -0700, Marc MERLIN wrote:
  On Fri, Mar 27, 2015 at 08:10:31AM +, Ian Campbell wrote:
   Control: retitle -1 initramfs-tools: does not support
 CONFIG_MODULE_COMPRESS
  
   On Fri, 2015-03-27 at 00:31 -0700, Marc MERLIN wrote:
Sure, there you go
   
   
Now I see the problem. It runs
modprobe --all --set-version=3.19.2-amd64-i915-volpreempt-20141114
--ignore-install --quiet --show-depends multipath.ko
but I have
   
 /lib/modules/3.19.2-amd64-i915-volpreempt-20141114/kernel/drivers/md/multipath.ko.gz
  
(trailing .gz)
  
   Ah, yes. I see this is a new kernel option, CONFIG_MODULE_COMPRESS
 (with
   gz and xz variants) which seems to have been introduced in v3.18-rc1.
  
   I suppose disabling that in your local builds would work around the
   issue until initramfs-tools can be taught to cope.
 
  Yes, it was late last night when I found this, but indeed this was my
  plan :)
 
  All I needed was the way to run initramfs in debug mode and then it was
  obvious.
  Would you mind adding this in the man page? I could have debugged this a
  while ago had I had the easy way to run it in debug mode.

 Adding some sort of --debug-trace option would be nicer than documenting
 run it under sh -x, but yes, it could be made easier/more obvious that
 this was a useful debugging technique.

 Ian.




-- 
A mouse is a device used to point at the xterm you want to type in -
A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet
cooking
Home page: http://marc.merlins.org/

Bug#781002: initramfs-tools: no kernel modules are insert into initrd

2015-03-27 Thread Marc MERLIN 
On Fri, Mar 27, 2015 at 08:10:31AM +, Ian Campbell wrote:
 Control: retitle -1 initramfs-tools: does not support CONFIG_MODULE_COMPRESS
 
 On Fri, 2015-03-27 at 00:31 -0700, Marc MERLIN wrote:
  Sure, there you go
  
  
  Now I see the problem. It runs
  modprobe --all --set-version=3.19.2-amd64-i915-volpreempt-20141114
  --ignore-install --quiet --show-depends multipath.ko
  but I have 
  /lib/modules/3.19.2-amd64-i915-volpreempt-20141114/kernel/drivers/md/multipath.ko.gz
 
  (trailing .gz)
 
 Ah, yes. I see this is a new kernel option, CONFIG_MODULE_COMPRESS (with
 gz and xz variants) which seems to have been introduced in v3.18-rc1.
 
 I suppose disabling that in your local builds would work around the
 issue until initramfs-tools can be taught to cope.

Yes, it was late last night when I found this, but indeed this was my
plan :)

All I needed was the way to run initramfs in debug mode and then it was
obvious.
Would you mind adding this in the man page? I could have debugged this a
while ago had I had the easy way to run it in debug mode.

Thanks,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901


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

Bug#781205: initramfs-tools fails to include modules for 3.19 kernel

2015-03-25 Thread Marc MERLIN 
Package: initramfs-tools
Version: 0.119

I have MODULES=most

With a 3.16 kernel, the cpio image contains:

/lib/modules/3.16.7-amd64-i915-volpreempt-20141114-cm1
drwxr-xr-x 6 root root   4096 Mar 25 16:57 kernel/  modules are here
-rw-r--r-- 1 root root   2047 Mar 25 16:57 modules.dep good
-rw-r--r-- 1 root root   3662 Mar 25 16:57 modules.dep.bin 

With 3.19, I get an empty modules.dep file due tol no modules

/lib/modules/3.19.2-amd64-i915-volpreempt-20141114:
 no kernel directory, no modules 
-rw-r--r-- 1 root root0 Mar 25 16:54 modules.dep 
-rw-r--r-- 1 root root   12 Mar 25 16:54 modules.dep.bin

As a result, the resulting image will not boot since no modules will load.

I'm not too sure how to debug initramfs-tools' code that fails to include 
modules
for my 3.19 kernel.
I did rebuild the initrd for my 3.16 kernel and all modules are there, no 
problem.

Thanks,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


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

Bug#721857: btrfs-tools should include /sbin/btrfs-zero-log in initramfs

2013-09-04 Thread Marc MERLIN 
Package: btrfs-tools
Version: 0.19+20130315-5

When a btrfs filesystem is unmounted uncleanly, it can get in a situation
where it is not possible to mount it anymore, until you run btrfs-zero-log
to clean the log data that the kernel cannot process on its own and will not 
discard the log because it doesn't know that't the right thing to do.

In my case, I have an SSD that unfortunatley locks up on occasion and
triggers this state. At that point, the way to recover is to run 
btrfs-zero-log /dev/mapper/cryptroot
which I cannot do from the initramfs unless it's present in there.

I modified
/usr/share/initramfs-tools/hooks/btrfs
to copy_exec /sbin/btrfs-zero-log

I'm good, but suggesting that you do this to the official package as a handy
rescue other people who might otherwise end up with an umountable filesystem
and no way to self-rescue without boot media.

Note that the admin would still need to know to run that command, Im' not
suggesting to run it automatically if the rootfs somehow failed to mount.

Thanks,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


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

Bug#386368: /dev/shm or /run/shm is still not mounted with noexec

2012-05-28 Thread Marc MERLIN 
On 7 Jun 2010 the last update said shm would be noexec again.

Is it still going to happen?

Thanks,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  



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

Bug#671589: bootlog does not work if the kernel boot command line is too long

2012-05-04 Thread Marc MERLIN 
Package: initscripts
Version: 2.88dsf-13.1

Courtesy of Maciej Zenczykowski:

sysvinit - kernel command lines can be longer than 256 characters. 

Fix a bug where a kernel commandline option of 'console=ttyS0,115200n8'
was not being parsed correctly by bootlogd because it was 253 bytes into
the string, and thus would get truncated by a 255-byte read into the 256
byte buffer. This results in bootlogd not seeing the console=ttyS0 kernel
parameter, and it effectively turns off the serial console.

--- /tmp/g4-4428/cache/modules/sysvinit/src/src/bootlogd.c#2   2011-04-11 
15:10:58.0 -0700
+++ /tmp/g4-4428/29844861/modules/sysvinit/src/src/bootlogd.c  2012-05-04 
19:40:37.0 -0700
@@ -244,7 +244,7 @@
unsigned intkdev;
 #endif
struct stat st, st2;
-   charbuf[256];
+   charbuf[4096];
char*p;
int didmount = 0;
int n, r;

-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  



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

Bug#667651: alien does not install deb postinst to fix perms from rpm conversion when rpm had no postinst

2012-04-05 Thread Marc MERLIN 
Package: alien
Version: 8.86

Alien has some logic that preserves special rpm owner/group/permissions
by putting them as shell commands in a debian postinst when called with 
--scripts 

However the current logic in the code never fires if the original rpm
did not have a postinst.

This is a dirty patch that creates an empty postinst in the RPM just so
that the deb converter can see the postinst and add its package perm
fixing commands to it.

You can apply the patch to see the difference, but the patch is just a
'get it work for me now' patch, not something that should be applied as
is in the main tree.

--- 
/tmp/g4-4428/cache/depot//production/tools/prodimage/lib/Alien/Package/Deb.pm#1 
 2012-04-05 07:46:23.0 -0700
+++ /home/merlin/src//production/tools/prodimage/lib/Alien/Package/Deb.pm   
 2012-04-05 08:17:38.979101000 -0700
@@ -448,6 +448,9 @@
foreach my $script (qw{postinst postrm preinst prerm}) {
my $data=$this-$script();
next unless defined $data;
+   # Skip empty scripts, like an empty postinst that 
+   # didn't get any perm fix changes.
+   next if $data eq '#!/bin/sh';
next if $data =~ m/^\s*$/;
open (OUT,$dir/debian/$script) ||
die $dir/debian/$script: $!;
--- 
/tmp/g4-4428/cache/depot//production/tools/prodimage/lib/Alien/Package/Rpm.pm#1 
 2012-04-05 07:46:23.0 -0700
+++ /home/merlin/src//production/tools/prodimage/lib/Alien/Package/Rpm.pm   
 2012-04-05 08:18:57.096166000 -0700
@@ -545,7 +545,16 @@
 }
 sub postinst {
my $this=shift;
-   $this-_script_helper('postinst', @_);
+   # Force postinst generation so that debian chown/chmod
+   # conversion can happen. See Deb.pm.
+   if (not @_)
+   {
+   $this-_script_helper('postinst','#!/bin/sh');
+   }
+   else
+   {
+   $this-_script_helper('postinst', @_);
+   }
 }
 sub postrm {
my $this=shift;

-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/



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

Bug#659517: latest debian powertop (1.97-2) does not show wattage with 3.0.6 and above (3.1.x and up to today's 3.2.5)

2012-02-11 Thread Marc MERLIN 
Package: powertop
Version: 1.97-2

Powertop doesn't seem well maintained and many of its source locations (or
git tree) have disappeared, but 1.98 seems to be the latest:
http://ftp.osuosl.org/pub/linux/status/powertop/powertop-1.98.tar.bz2

Watts used while on battery does not work anymore with unpatched powertop
since the deprecated /proc/acpi/battery is now gone. See:
https://bugs.archlinux.org/task/26416

I found this:
https://aur.archlinux.org/packages.php?ID=48935
and this patch fixed it for me:
http://www.tinloaf.de/~tinloaf/software/powertop-1.98-sysfs.patch

I'm attaching the patch to this Email just in case it disappears from the
net at some point (too many bad links for powertop already).

Could you upgrade debian powertop so that it provides a usable binary for
laptop battery tuning again?

Thanks,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
diff -N -r -u powertop-1.98/Makefile powertop-patched/Makefile
--- powertop-1.98/Makefile  2011-05-11 06:48:37.0 +0200
+++ powertop-patched/Makefile   2011-10-20 16:06:37.753900039 +0200
@@ -13,7 +13,7 @@
 OBJS += process/process.o process/do_process.o process/interrupt.o 
process/timer.o process/work.o process/powerconsumer.o process/device.o
 DEVS += devices/device.o devices/backlight.o devices/usb.o devices/ahci.o 
devices/alsa.o devices/rfkill.o devices/i915-gpu.o devices/thinkpad-fan.o 
devices/network.o devices/thinkpad-light.o
 DEVS += devices/runtime_pm.o
-DEVS += measurement/measurement.o measurement/acpi.o measurement/extech.o
+DEVS += measurement/measurement.o measurement/acpi.o measurement/sysfs.o 
measurement/extech.o
 OBJS += $(DEVS)
 OBJS += parameters/parameters.o parameters/learn.o parameters/persistent.o
 OBJS += calibrate/calibrate.o
diff -N -r -u powertop-1.98/measurement/measurement.cpp 
powertop-patched/measurement/measurement.cpp
--- powertop-1.98/measurement/measurement.cpp   2011-05-11 06:48:37.0 
+0200
+++ powertop-patched/measurement/measurement.cpp2011-10-20 
16:00:50.305782326 +0200
@@ -24,6 +24,7 @@
  */
 #include measurement.h
 #include acpi.h
+#include sysfs.h
 #include extech.h
 #include ../parameters/parameters.h
 #include ../lib.h
@@ -103,7 +104,7 @@
return total;
 }
 
-void power_meters_callback(const char *d_name)
+void power_meters_callback_acpi(const char *d_name)
 {
class acpi_power_meter *meter;
meter = new(std::nothrow) class acpi_power_meter(d_name);
@@ -111,9 +112,23 @@
power_meters.push_back(meter);
 }
 
+void power_meters_callback_sysfs(const char *d_name)
+{
+   if (strstr(d_name, AC) ||
+   strstr(d_name, .)) {
+   return;
+   }
+   
+   class sysfs_power_meter *meter;
+   meter = new(std::nothrow) class sysfs_power_meter(d_name);
+   if (meter)
+   power_meters.push_back(meter);
+}
+
 void detect_power_meters(void)
 {
-   process_directory(/proc/acpi/battery, power_meters_callback);
+   process_directory(/proc/acpi/battery, power_meters_callback_acpi);
+   process_directory(/sys/class/power_supply, 
power_meters_callback_sysfs);
 }
 
 void extech_power_meter(const char *devnode)
diff -N -r -u powertop-1.98/measurement/sysfs.cpp 
powertop-patched/measurement/sysfs.cpp
--- powertop-1.98/measurement/sysfs.cpp 1970-01-01 01:00:00.0 +0100
+++ powertop-patched/measurement/sysfs.cpp  2011-10-20 16:19:29.289720272 
+0200
@@ -0,0 +1,134 @@
+/*
+ * Copyright 2010, Intel Corporation
+ *
+ * This file is part of PowerTOP
+ *
+ * This program file is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program in a file named COPYING; if not, write to the
+ * Free Software Foundation, Inc,
+ * 51 Franklin Street, Fifth Floor,
+ * Boston, MA 02110-1301 USA
+ * or just google for it.
+ *
+ * Authors:
+ * Lukas Barth m...@tinloaf.de
+ */
+#include measurement.h
+#include sysfs.h
+#include iostream
+#include fstream
+#include string.h
+#include stdio.h
+#include stdlib.h
+
+using namespace std;
+
+sysfs_power_meter::sysfs_power_meter(const char *sysfs_name)
+{
+   rate = 0.0;
+   capacity = 0.0;
+   voltage = 0.0;
+   strncpy(battery_name, sysfs_name, sizeof(battery_name));
+}
+
+void sysfs_power_meter::measure(void)
+{
+   char filename[4096];
+   char line[4096];
+   ifstream

Bug#620958: I had to downgrade to dpkg 1.15.5.6

2011-08-03 Thread Marc MERLIN 
Raphael,

No offense, but I went through the entire bug, tried the ruby script
which did not work reliably (added duplicate architecture lines and
forgot some), and then I spent 1h trying to fix the file by hand, and
the more errors I fixed, the more dpkg --list would report more a few at
a time.

Back to dpkg 1.15.5.6 everything is happy.

I got hundreds of
dpkg: warning: parsing file '/var/lib/dpkg/status' near line 50983 package 
'fortunes-min':
 missing architecture

So yes, I installed all my debian systems in the late 90's and they have
been upgraded every since then. This is why debian is great, and why I
keep using it.

dpkg was changed to assume that systems were installed more recently and
offers no fixup for old but then acceptable databases.
Note that clearing available does not fix anything since I have hundreds
of errors in the /var/lib/dpkg/status file.

My recommendation is that you provide a post-install that checks the
syntax of /var/lib/dpkg/status|available and fixes the files.

Until then, for the first time in 12 years, I'll be unable to further
upgrade my debian systems.

Thanks,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/



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

Bug#620958: I had to downgrade to dpkg 1.15.5.6

2011-08-03 Thread Marc MERLIN 
On Wed, Aug 03, 2011 at 08:46:40AM -0700, Marc MERLIN wrote:
 My recommendation is that you provide a post-install that checks the
 syntax of /var/lib/dpkg/status|available and fixes the files.

To make your life easier, I tared up my entire /var/lib/dpkg
if you want to see what an old DB looks like:
http://marc.merlins.org/tmp/dpkg-db.tar.gz (15MB)

Note that I also have packages which got called -gargamel1 by make-kpkg
which is indeed invalid too (kernel packages), but that's only a few of
them and maybe I can hand edit the databases to put -1gargamel1 instead
(or if your postinstall script could fix that too, that'd be awesome)

Thanks,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/



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

Bug#604886: iproute has misbuild tc-bfifo.8.gz due to dh_link problem

2010-11-25 Thread Marc MERLIN 
On Thu, Nov 25, 2010 at 10:34:05AM +0100, Andreas Henriksson wrote:
 On Wed, Nov 24, 2010 at 06:13:37PM -0800, Marc MERLIN wrote:
  Package: iproute
  Version: 20100519-3
  
  debian rules has:
  dh_link -a
  (...)
  dh_installman -a
  
  This is a problem because dh_link tries to do:
  rm -f debian/iproute/usr/share/man/man8/tc-bfifo.8.gz
  ln -sf tc-pfifo.8.gz debian/iproute/usr/share/man/man8/tc-bfifo.8.gz
  
  This does not work if dh_link is run before dh_installman since
  debian/iproute/usr/share/man/man8 does not exist before dh_installman
  is run.
  
  Swapping the lines fixes the problem.
 
 Thanks for the details and the fix! :)
 
 For some reason all the links are there in the new version of the package
 (that was supposed to be uploaded to unstable before the freeze but the
 release team managed to freeze just before I was about to upload).
 
Gotcha. Note that in the package I originally built, tc-bfifo and tc-pfifo
man pages were both there, but they were copies of the same file, not
symlinked.

 I don't quite see why the newer package doesn't fail the same way
 and I'll have to investigate that...

I did notice that the makefile already makes the symlink too. I'm not too
sure what was going on. I just found the wrong dh_* order while debugging,
swapped them and then it worked, so I moved on :)

(note that I was using debhelpers 8, and that was on ubuntu, I have a custom
bulid system while is likely different from the average person's).

It may be that your version works already as is, but since it may be by
luck, or dependent on maybe undefinied behaviour of the dh programs in the
situation I described, I thought I'd report it.
If it's not really a problem that needs fixing, feel free to close :)

Best,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  



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

Bug#604886: iproute has misbuild tc-bfifo.8.gz due to dh_link problem

2010-11-25 Thread Marc MERLIN 
On Thu, Nov 25, 2010 at 04:34:54PM +0100, Andreas Henriksson wrote:
 On Thu, Nov 25, 2010 at 06:37:14AM -0800, Marc MERLIN wrote:
   
  Gotcha. Note that in the package I originally built, tc-bfifo and tc-pfifo
  man pages were both there, but they were copies of the same file, not
  symlinked.
 
 I've played around a bit with this now in the updated package while
 rewriting parts of the packaging and it seems dh_installman
 will turn the symlinks into file copies when it runs
 install -p -m644 ... over all the manpages. :/

That's indeed what I experienced, and my build system then rejected the
package since it checks all files and complains if two are identical but not
linked together.

 Oh well... They should atleast all be there now in the git version
 of the packaging.

Cool. It wasn't a big deal, but since I spent some time debugging it and
fixing it, I thought I'd share :)

Best,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  



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

Bug#604885: devpts.sh gets the uname wrong

2010-11-24 Thread Marc MERLIN 
Package: iproute
Version: 20100519-3

debian rules has:
dh_link -a
(...)
dh_installman -a

This is a problem because dh_link tries to do:
rm -f debian/iproute/usr/share/man/man8/tc-bfifo.8.gz
ln -sf tc-pfifo.8.gz debian/iproute/usr/share/man/man8/tc-bfifo.8.gz

This does not work if dh_link is run before dh_installman since
debian/iproute/usr/share/man/man8 does not exist before dh_installman
is run.

Swapping the lines fixes the problem.

Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  



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

Bug#557038: list of google domains

2009-12-03 Thread Marc MERLIN 
What you want it
http://www.google.com/supported_domains

Also, a way to check if a domain that somehow wouldn't be in this list is
legit, or not, would be to check its SOA record, NS, and MX.
If they all point to google, that's a pretty good indication that it's legit
:)

Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  



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

Bug#449538: mc: fish hangs when try to copy file with size 2G

2008-10-21 Thread Marc MERLIN 
I can confirm the 2G file limit bug is fixed with
mc_2%3a4.6.2~git20080311-4_i386.deb, however it is replaced by a graver bug
which prevents traversing directories with spaces.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488497

Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  



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

Bug#488497: mc: entering directories with spaces over fish doesnt work

2008-10-21 Thread Marc MERLIN 
I'd like to confirm that with
mc_2%3a4.6.2~git20080311-4_i386.deb

Downgrading to mc_4.5.55-1.2_i386.deb fixes the problem, however that
version suffers from the 2G file limit problem.

Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  



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

Bug#401761: libpam-mount makes cron segfault

2006-12-07 Thread Marc MERLIN 
On Thu, Dec 07, 2006 at 10:51:26PM +0100, Bastian Kleineidam wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Marc MERLIN schrieb:
  Indeed. 0.12 was the latest in my distro, but I downloaded the latest 0.18
  from packages.debian.org/testing/ and I still have the same problem
 You normally don't need to use pam_mount together with su. If you do,
 there unfortunately will be a prompt reenter password when su is
 started from root. And this breaks cron jobs using the su program.
 
 I attached a patch which gets rid of the password prompting. This might
 also fix the segfault you are experiencing when using cron and su
 configured for pam_mount.
 
Indeed, I'm not quite sure why because cron would segfault on
* * * * * root date  /tmp/file
in /etc/crontab since this does not involve su, and I've removed pam-mount
from /etc/pam.d/su, and I only have it in /etc/pam.d/cron for testing.

But sure enough, it seems to have worked. 
I.e. your patch seems to have fixed the SEGV I was seeing.

Thanks
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


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

Bug#401761: libpam-mount makes cron segfault

2006-12-06 Thread Marc MERLIN 
On Tue, Dec 05, 2006 at 09:22:31PM +0100, Bastian Kleineidam wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Marc MERLIN schrieb:
  cron (Version: 3.0pl1-87ubuntu2) / libpam-mount (0.12.0-1ubuntu1)
 Please try a newer version of pam_mount. The current one is 0.18, which
 has a lot of fixes compared to 0.12.
 You can find .deb packages of pam_mount 0.18 here:
 http://packages.debian.org/testing/admin/libpam-mount

Indeed. 0.12 was the latest in my distro, but I downloaded the latest 0.18
from packages.debian.org/testing/ and I still have the same problem

Mind you, I'm ok now, because I removed pam-mount from /etc/pam.d/su, but a
segfault in pam or cron is never good.

Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


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

Bug#401761: Acknowledgement (libpam-mount makes cron segfault)

2006-12-05 Thread Marc MERLIN 
On Tue, Dec 05, 2006 at 09:18:08PM +0100, Javier Fernández-Sanguino Peña wrote:
 On Tue, Dec 05, 2006 at 11:04:43AM -0800, Marc MERLIN wrote:
   pam_mount: error trying to retrieve authtok from auth code
   Dec  5 11:03:01 polgara kernel: [6102582.658784] cron-debug-g2[7141]: 
   segfault at  rip  rsp d3fc 
   error 14
  
  I guess this means that it's a pam library segv and not a cron bug?
  
  But now, I have no idea if the bug is in pam, or pam_mount...
 
 I would say that the error is in pam_mount. I'm not sure if cron's segfault
 is due to the fact that pam crashes behind him or he does not handle properly
 PAM's error.
 
 Can you please explain what kind of cron tasks are you using and what do you
 use pam_mount for? Do you auto-mount home directories and use per-user
 crontabs?

for cron, anything will crash it.
Right now, I just have 
* * * * *   root date  /tmp/date
in /etc/crontab

pam_mount, I use to decrypt and mount a directory when users log in.
Initially, the install docs I saw recommended putting the pam_mount config
like so:

/etc/pam.d/common-auth:
authsufficient  pam_unix.so
authoptionalpam_mount.so use_first_pass
authsufficient  pam_krb5.so retain_after_close forwardable 
refresh_creds use_first_pass
authrequiredpam_deny.so

/etc/pam.d/common-session:
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define tasks to be performed
# at the start and end of sessions of *any* kind (both interactive and
# non-interactive).  The default is pam_unix.
#
session requiredpam_unix.so
session requiredpam_limits.so
session optionalpam_mount.so

Turns out I only really need to include this in
/etc/pam.d/kdm|gdm|login|ssh|xscreensaver
but indeed, sourcing it in other places shouldn't still shouldn't cause 
cron/pam to
segv

Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


signature.asc
Description: Digital signature

Bug#401761: libpam-mount makes cron segfault

2006-12-05 Thread Marc MERLIN 
Package: cron
Version: 3.0pl1-87

libpam-mount makes cron segfault each time it forks off a child to run 
tasks if it's built with pam support.

strace -f cron -f shows
[pid  3298] setrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, 
rlim_max=RLIM_INFINITY}) = 0
[pid  3298] setrlimit(RLIMIT_LOCKS, {rlim_cur=RLIM_INFINITY, 
rlim_max=RLIM_INFINITY}) = 0
[pid  3298] setrlimit(RLIMIT_SIGPENDING, {rlim_cur=RLIM_INFINITY, 
rlim_max=RLIM_INFINITY}) = 0
[pid  3298] setrlimit(RLIMIT_MSGQUEUE, {rlim_cur=RLIM_INFINITY, 
rlim_max=RLIM_INFINITY}) = 0
[pid  3298] setpriority(PRIO_PROCESS, 0, 0) = 0
[pid  3298] write(2, pam_mount: error trying to retrieve authtok from auth 
code\n, 59pam_mount: error trying to retrieve authtok from auth code
) = 59
[pid  3298] time([1165283281])  = 1165283281
[pid  3298] stat64(/etc/localtime, {st_mode=S_IFREG|0644, st_size=1017, ...}) 
= 0
[pid  3298] stat64(/etc/localtime, {st_mode=S_IFREG|0644, st_size=1017, ...}) 
= 0
[pid  3298] stat64(/etc/localtime, {st_mode=S_IFREG|0644, st_size=1017, ...}) 
= 0
[pid  3298] send(7, 83Dec  4 17:48:01 CRON-DEBUG-G[3298]: pam_mount: error 
trying to retrieve authtok from auth code\n, 99, MSG_NOSIGNAL) = 99
[pid  3298] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
Process 3298 detached

The problem is indeed linked to:
 polgara [mc]$ cat /etc/pam.d/common-auth 
 authsufficient  pam_unix.so
 authoptionalpam_mount.so use_first_pass
^
 authsufficient  pam_krb5.so retain_after_close forwardable 
 refresh_creds use_first_pass
 authrequiredpam_deny.so

I can move this in all the necessary pam files and remove it from
common-auth so that it's not sourced in /etc/pam.d/cron, but it shouldn't
cause cron to crash.

I can't quite decide if I should file a bug with libpam-mount if it violates 
the pam API
with its output, or with cron for the segv

What's your take on this?

Thanks,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


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

Bug#401761: Acknowledgement (libpam-mount makes cron segfault)

2006-12-05 Thread Marc MERLIN 
More debugging shows that cron dies in 
do_command.c between 7 and 8:
fprintf(stderr, 7\n);
retcode = pam_open_session(pamh, PAM_SILENT);
fprintf(stderr, 8\n);

output is:
 7
 pam_mount: error trying to retrieve authtok from auth code
 Dec  5 11:03:01 polgara kernel: [6102582.658784] cron-debug-g2[7141]: 
 segfault at  rip  rsp d3fc error 
 14

I guess this means that it's a pam library segv and not a cron bug?

But now, I have no idea if the bug is in pam, or pam_mount...

Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


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

Bug#401462: Acknowledgement (Please build exim4-dev package with local_scan-related header files)

2006-12-04 Thread Marc MERLIN 
On Mon, Dec 04, 2006 at 06:21:35PM +0100, Magnus Holmgren wrote:
 On Monday 04 December 2006 08:11, Marc Haber wrote:
  On Mon, Dec 04, 2006 at 04:32:20AM +0100, Magnus Holmgren wrote:
   One closely related thing: I don't know if you saw it on exim-dev, but
   I've noticed that LOCAL_SCAN_ABI_VERSION_MAJOR and
   LOCAL_SCAN_ABI_VERSION_MINOR haven't changed since Exim 4.14 where you
   introduced the localscan_dlopen patch, even though new functions have
   been added to the API.
 
  The localscan_dlopen patch has been provided by Marc Merlin, whom I
  have not heard of in a long time. Sorry, I am not in a position to
  modify the patch as I totally don't know what's going on there.
 
 Too bad. Also too bad that the patch hasn't been incorporated upstream yet, 
 which would make it easier to keep track of these changes. But as the 
 comments say:
 
The major number is increased when the ABI is changed in a non
backward compatible way.
The minor number is increased each time a new feature is added (in a
way that doesn't break backward compatibility)
 
Pretty much. I was hoping that the revision numbers would get updated by the
exim developers after I submitted the patch, but I have indeed not been
working much on exim since then, outside of being an end user.
I'm guessing that since few to no people have been using the localscan API
outside of sa-exim, it hasn't been kept up to date.
 
  I am willing to accept changes from knowledgeable third parties though.
 
 I think I can say this: LOCAL_SCAN_ABI_VERSION_MINOR should have been 
 incremented some time ago, but since nothing actually has depended on it, 
 incrementing it with the addition of exim4-dev should work.
 
 (I intend to use some of the newer functions if the ABI version = 1.1 when 
 building. This is so the same package can be built for use with older 
 versions of Exim.)

Magnus and I talked about this, and I'm perfectly happy with what he's
proposing and the work he's willing to put in (where I've been focussing my
time on other things lately).
Feel free to go with what he proposes.

Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


signature.asc
Description: Digital signature

Bug#401462: Acknowledgement (Please build exim4-dev package with local_scan-related header files)

2006-12-04 Thread Marc MERLIN 
On Mon, Dec 04, 2006 at 06:43:27PM +0100, Magnus Holmgren wrote:
 On Monday 04 December 2006 18:21, Magnus Holmgren wrote:
   On Mon, Dec 04, 2006 at 04:32:20AM +0100, Magnus Holmgren wrote:
One closely related thing: I don't know if you saw it on exim-dev, but
I've noticed that LOCAL_SCAN_ABI_VERSION_MAJOR and
LOCAL_SCAN_ABI_VERSION_MINOR haven't changed since Exim 4.14 where you
introduced the localscan_dlopen patch, even though new functions have
been added to the API.
 
  I think I can say this: LOCAL_SCAN_ABI_VERSION_MINOR should have been
  incremented some time ago, but since nothing actually has depended on it,
  incrementing it with the addition of exim4-dev should work.
 
 Hmm. Upon closer inspection, it seems that upstream included the 
 LOCAL_SCAN_ABI_VERSION* defines in Exim 4.20. Then upstream is to blame, 
 after all.

Yes, I did get Philip to accept my patch, but he put it as is, and IIRC said
he wouldn't necessarly be responsible for keeping it up to date.
So, I wouldn't blame him for that.
Now, if you ask the current maintainers if they could remember to update
this number every time they make an ABI change that is incompatible with
prior versions, we'd be all set. I'm obviously to blame for not following
development and not asking them to update it every time it would have been a
good idea to do so.

Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  


signature.asc
Description: Digital signature

Bug#356090: kernel: Can't access PCMCIA card adapter

2006-08-20 Thread Marc MERLIN 
I have to report the exact same bug than Bill.

Kernel 2.6.17.6
Dazzle 4 in 1 PCMCIA adapter
I used to have a 1G SD card that worked fine

I upgraded to a 2G card, and I get this:
kernel: pccard: PCMCIA card inserted into slot 0
kernel: cs: memory probe 0xe800-0xefff: excluding 0xe800-0xefff
kernel: cs: memory probe 0xc020-0xcfff: excluding 0xc020-0xc11f 
0xc1a0-0xc61f 0xc6a0-0xc71f 0xc7a0-0xc81f 
0xc8a0-0xc91f 0xc9a0-0xca1f 0xcaa0-0xcb1f 
0xcba0-0xcc1f 0xcca0-0xcd1f 0xcda0-0xce1f 
0xcea0-0xcf1f 0xcfa0-0xd01f
kernel: pcmcia: registering new device pcmcia0.0
kernel: setup_irq: irq handler mismatch
kernel:  c013fd6b setup_irq+0x10b/0x130  f9be4c70 test_action+0x0/0x10 
[pcmcia]
kernel:  c013ff02 request_irq+0x82/0xa0  f9be4e61 
pcmcia_request_irq+0x1e1/0x230 [pcmcia]
kernel:  f9be4c70 test_action+0x0/0x10 [pcmcia]  f9aef53e 
ide_config+0x3de/0x6c0 [ide_cs]
kernel:  f9be248e pcmcia_device_probe+0x6e/0x100 [pcmcia]  c02a0cfc 
driver_probe_device+0xbc/0xe0
kernel:  c02a0da0 __driver_attach+0x0/0x80  c02a0e10 
__driver_attach+0x70/0x80
kernel:  c02a0049 bus_for_each_dev+0x69/0x80  c0231103 
kobject_set_name+0x43/0xe0
kernel:  c02a0e45 driver_attach+0x25/0x30  c02a0da0 __driver_attach+0x0/0x80
kernel:  c02a0618 bus_add_driver+0x88/0xd0  c02a1357 
driver_register+0x97/0xa0
kernel:  c02a12a0 klist_devices_get+0x0/0x10  c02a12b0 
klist_devices_put+0x0/0x10
kernel:  f9be22f7 pcmcia_register_driver+0x17/0x50 [pcmcia]  f00f 
init_ide_cs+0xf/0x11 [ide_cs]
kernel:  c0133d62 sys_init_module+0xf2/0x180  c0102f87 syscall_call+0x7/0xb
kernel: Probing IDE interface ide2...
kernel: hde: Memory Card Adapter, CFA DISK drive
kernel: ide2 at 0x4100-0x4107,0x410e on irq 4
kernel: hde: max request size: 128KiB
kernel: hde: 1992704 sectors (1020 MB) w/1KiB Cache, CHS=3892/16/32
kernel:  hde:hde: status error: status=0x7f { DriveReady DeviceFault 
SeekComplete DataRequest CorrectedError Index Error }
kernel: hde: status error: error=0x00 { }
kernel: ide: failed opcode was: unknown
kernel: hde: drive not ready for command
kernel: ide2: reset: master: ECC circuitry error
kernel:  hde1
kernel: ide-cs: hde: Vpp = 0.0
kernel: hde: task_in_intr: status=0x51 { DriveReady SeekComplete Error }
kernel: hde: task_in_intr: error=0x10 { SectorIdNotFound }, LBAsect=3985271, 
sector=3985278
kernel: ide: failed opcode was: unknown
(...)

If I remove the card, my machine hangs hard.

It is possible that my 1GB card was really 0.99GB or something.
It also works with a 512MB card of the same brand than the 2GB card.

Has anyone found any info on how to handle this problem?

Thanks
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/


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

Bug#379323: mesa-utils: glxinfo does not report library open problems

2006-07-23 Thread Marc MERLIN 
On Sun, Jul 23, 2006 at 01:44:59PM +0200, Michel Dänzer wrote:
 On Sat, 2006-07-22 at 15:48 -0400, Marc MERLIN wrote:
  
  libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)
  libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so
  libGL error: dlopen /usr/X11R6/lib/modules/dri/fglrx_dri.so failed 
  (/usr/X11R6/l
  ib/modules/dri/fglrx_dri.so: cannot open shared object file: No such file 
  or dir
  ectory)
  libGL error: unable to find driver: fglrx_dri.so
  
  This was due to a packaging bug, 
 
 Which I hope has been reported as well?
 
Yes, but that wasn't part of debian proper, so I sent it to the packager
directly. But I'm sure there would/will be other similar problems/bugs
for other people now, or in the future.

 Maybe glxinfo could still provide a clue though, such as output that
 goes something like 'Setting the environment variable
 LIBGL_DEBUG=verbose may help find out why direct rendering is disabled'.
 Do you think that would be useful?

Absolutely, that would be a great compromise and would have been enough
to help me out

Thanks
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/


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

Bug#379323: mesa-utils: glxinfo does not report library open problems

2006-07-22 Thread Marc MERLIN 
Package: mesa-utils
Version: 6.3.2-2.1
Severity: important


I unfortunately just spent hours of debugging trying to find why I wasn't
getting accelerated GL after installing 3D drivers, and having the right
/usr/lib/libGL.so.1 and friends.

I would have killed for having glxinfo tell me what the problem was until
I found out a day later about LIBGL_DEBUG=verbose glxinfo, which then
gave me:
gandalf:~$ LIBGL_DEBUG=verbose glxinfo
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 8.26.18 fglrx (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/fglrx_dri.so
libGL error: dlopen /usr/X11R6/lib/modules/dri/fglrx_dri.so failed (/usr/X11R6/l
ib/modules/dri/fglrx_dri.so: cannot open shared object file: No such file or dir
ectory)
libGL error: unable to find driver: fglrx_dri.so

This was due to a packaging bug, which I fixed with a simple symlink in about
30 seconds, but I would really really have liked for glxinfo to tell me that
it couldn't open the driver and that's why I was still getting Mesa.
Please consider making LIBGL_DEBUG=verbose or equivalent, a default to help
out the countless people on the net like me who have spent too much time
tracking this problem.

I'm adding extra un-needed info so that google indexes it, and that
hopefully other people can find this instead of spending the time I spent.
With fglrx (fglrx-driver), and xorg 7.0.22, the driver was loading, dri was
initializing, but glxinfo would tell me:
gandalf:~$ glxinfo | grep direct
direct rendering: No
OpenGL renderer string: Mesa GLX Indirect

After ln -s /usr/lib /usr/X11R6/lib/modules, it allowed libGL to find
/usr/X11R6/lib/modules/dri/fglrx_dri.so which really had been installed
in /usr/lib/dri/fglrx_dri.so

Now, I do get:
gandalf:~$ glxinfo | grep -E '(direct|renderer)'
direct rendering: Yes
OpenGL renderer string: MOBILITY FIREGL T2 Pentium 4 (SSE2) (FireGL) (GNU_ICD)

Thanks
Marc


-- System Information:
Debian Release: woody
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'oldstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17.6-pmup-desktop-marc1y
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 
(charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO-8859-15)

Versions of packages mesa-utils depends on:
di  freeglut3 2.4.0-4OpenGL Utility Toolkit
ii  libc6 2.3.6-15   GNU C Library: Shared libraries
pi  libgl1-mesa-glx [libgl1]  6.4.2-1A free implementation of the OpenG
pi  libglu1-mesa [libglu1]6.4.2-1The OpenGL utility library (GLU)
ii  libx11-6  6.9.0.dfsg.1-1 X Window System protocol client li

mesa-utils recommends no packages.

-- no debconf information


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

Bug#375880: initramfs-tools: typo in /scripts/local Running /scripts/log-bottom - local-bottom

2006-06-28 Thread Marc MERLIN 
Package: initramfs-tools
Version: 0.65b
Severity: minor
Tags: patch


At the end of /usr/share/initramfs-tools/scripts/local , you have:
[ $quiet != y ]  log_begin_msg Running /scripts/log-bottom
run_scripts /scripts/local-bottom

This should be local-bottom, not log-bottom

Thanks
Marc

-- System Information:
Debian Release: woody
  APT prefers unstable
  APT policy: (900, 'unstable'), (500, 'oldstable'), (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14swsusp-2.2rc15-marc1y
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 
(charmap=ISO-8859-15) (ignored: LC_ALL set to en_US.ISO-8859-15)

Versions of packages initramfs-tools depends on:
ii  busybox   1:1.1.3-1  Tiny utilities for small and embed
ii  cpio  2.6-10 GNU cpio -- a program to manage ar
ii  klibc-utils   1.3.35-1   small statically-linked utilities 
ii  module-init-tools 3.2-pre9-3 tools for managing Linux kernel mo
ii  udev  0.083-1/dev/ and hotplug management daemo

initramfs-tools recommends no packages.

-- no debconf information


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

Bug#296083: xmms 1.2.10-2 still buggy with alsa

2005-03-14 Thread Marc MERLIN 
On Sun, Mar 13, 2005 at 04:26:37PM -0500, Christopher Martin wrote:
   I included this fix (well, actually, a CVS snapshot of the file in
   question) with 1.2.10-2, so the bug should no longer be present. If you
   still have the problem, let me know.
 
  Sorry, that's the one I have and it doesn't work:
  gandalf:~$ xmms 
  [2] 8799
  gandalf:~$ Message: alsa mixer timed out
 
  ** WARNING **: snd_pcm_pause() failed: File descriptor in bad state
 
  ** WARNING **: snd_pcm_pause() failed: File descriptor in bad state
 
 Then the problem you have is not the one fixed in the patch you linked to 
 originally - or have you tested xmms 1.2.10 with that patch and found it to 
 work (meaning that the CVS snapshot I borrowed from introduced the problem 
 a second time)?

No, I just assumed I was missing the same patch since it described exactly
the problem I was having.
In other words, I might have a different issue, but with the same exact
symptoms.

If there is anything I can do to provide more info, let me know.

Thanks,
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   |   Finger [EMAIL PROTECTED] for PGP key


signature.asc
Description: Digital signature

Bug#296083: xmms 1.2.10-2 still buggy with alsa

2005-03-12 Thread Marc MERLIN 
I'm not sure how to reopen, could you do this for me?

On Tue, Mar 01, 2005 at 10:48:31AM -0800, Debian Bug Tracking System wrote:
  Package: xmms
  Version: 1.2.10-2
 
  The alsa plugin doesn't work right on some sound cards.
  This is a known problem that is already fixed, but there hasn't been an
  xmms release since then, so debian doesn't have the fix.
 
 I included this fix (well, actually, a CVS snapshot of the file in question=
 )=20
 with 1.2.10-2, so the bug should no longer be present. If you still have=20
 the problem, let me know.

Sorry, that's the one I have and it doesn't work:
gandalf:~$ xmms 
[2] 8799
gandalf:~$ Message: alsa mixer timed out

** WARNING **: snd_pcm_pause() failed: File descriptor in bad state

** WARNING **: snd_pcm_pause() failed: File descriptor in bad state

gandalf:~$ type xmms
xmms is hashed (/usr/bin/xmms)
gandalf:~$ dpkg -S /usr/bin/xmms
xmms: /usr/bin/xmms
gandalf:~$ dpkg -l xmms
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  xmms   1.2.10-2   Versatile X audio player that looks like Win

Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   |   Finger [EMAIL PROTECTED] for PGP key


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

Bug#296083: xmms is missing an alsa patch from cvs

2005-02-19 Thread Marc MERLIN 
Package: xmms
Version: 1.2.10-2

The alsa plugin doesn't work right on some sound cards.
This is a known problem that is already fixed, but there hasn't been an xmms
release since then, so debian doesn't have the fix.

Could you look at
http://bugs.xmms.org/long_list.cgi?buglist=1611
and apply this patch from the author:
http://bugs.xmms.org/attachment.cgi?id=209action=view

Thanks
Marc
-- 
A mouse is a device used to point at the xterm you want to type in - A.S.R.
Microsoft is to operating systems  security 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/   |   Finger [EMAIL PROTECTED] for PGP key


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