[needs-packaging] read-edid-2.0.0 for amd64

Can confirm this to be the case:

read-edid-1.4.1/debian/control:
Package: read-edid
Architecture: i386 powerpc

read-edid 2.0.0 has been released today. The new version should build for x86 and amd64 at least. parse-edid should build for everyone.

depends on libx86 now.

Also, make note of the change of maintainership... John Fremlin gave it up to me over email... his website isn't updated because he forgot the password to his ftp site... the freshmeat page is updated.

homepage for the project: http://www.polypux.org/projects/read-edid/

I tried compiling this on Hardy 64bit, and it still doesn't want to work :( libx86 is installed, but configure can't find it.

hmm... not too familiar with ubuntu, but do you have the -dev package installed?

read-edid-2.0.0 seems to work fine on 64bit intrepid (install libx86-dev as mentioned).

@poly-p: Did you include the functionality of the patch at
  http://archive.ubuntu.com/ubuntu/pool/universe/r/read-edid/read-edid_1.4.1-2.1ubuntu1.diff.gz
already? Then it should be quite easy for the maintainer to create a new package.

I'm working on the package. I'll have a test package in my PPA shortly.

Successfully build-tested for Hardy, Intrepid, Jaunty (i386 and amd64).

Runs on Jaunty amd64 (no results since Nvidia GeForce 7600 + Sony FE41Z don't provide EDID output).
Runs on Jaunty i386 (no results since Intel i815M + Sony SRX51 TFT don't provide EDID output).

Please test the package in my PPA and report back.

https://launchpad.net/~intuitivenipple/+archive/ppa/

Feature Freeze Exception request

  * Upstream added support for amd64 architecture (using libx86) and has a new maintainer

= Install log =

sudo apt-get install read-edid
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed
  read-edid
0 upgraded, 1 newly installed, 0 to remove and 94 not upgraded.
Need to get 0B/12.8kB of archives.
After this operation, 77.8kB of additional disk space will be used.
Selecting previously deselected package read-edid.
(Reading database ... 205161 files and directories currently installed.)
Unpacking read-edid (from .../read-edid_2.0.0-0ubuntu1~tj~ppa1j_amd64.deb) ...
Processing triggers for man-db ...
Setting up read-edid (2.0.0-0ubuntu1~tj~ppa1j) ...

= Tests =

Tested on x86 and amd64 hardware. Reports expected results for monitors that support EDID.

Are these rdepends affected by this upgrade?

Reverse Depends:
  xdebconfigurator
  lm-sensors

It looks like xdebconfigurator is not using read-edid by default. It just suggests read-edid now.

On Wed, 2009-03-18 at 06:40 +0000, Iulian Udrea wrote:
> Are these rdepends affected by this upgrade?
>
> Reverse Depends:
> xdebconfigurator
> lm-sensors
>
> It looks like xdebconfigurator is not using read-edid by default. It
> just suggests read-edid now.

That's correct, and it detects the presence of the read-edid tools
using:

xdebconfigurator:74:chomp($getedid = `which get-edid`); # read-edid exists?

I couldn't find any usage of read-edid's executables (get-edid or
parse-edid) in lm-sensors. The only occurrence of the string "edid" at
all...

pwd

/home/all/SourceCode/lm-sensors-3-3.0.2

grep -rni edid *

debian/control:14:Suggests: sensord, read-edid, i2c-tools
debian/changelog:776: * Suggests: read-edid (closes: bug#265890).
prog/detect/sensors-detect:1212: # for SPD and EDID EEPROMs because some hardware monitoring chips
prog/detect/sensors-detect:1218: name => "EDID EEPROM",

...is in the Debian changelog where it says:

debian/changelog:776: * Suggests: read-edid (closes: bug#265890)

Looking at that Debian bug

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

it seems as if the only reason for the Suggests was because:

"...decode-edid.pl is not present in the package..."

The output of get-edid | parse-edid is the same as it ever was so
packages relying on the output won't be affected. The only change is a
gain in the availability of the tools on 64-bit installations.

I'm fine with it.

ACK #1

I'd like to see testing from more than one person.

I've tested the read-edid from the PPA (read-edid_2.0.0-0ubuntu1~tj~ppa1j_i386.deb) and it seems to work fine. I noticed a difference on STDERR from get-edid though:

$ diff get-edid-1.4.err get-edid-2.0.err1c1
< get-edid: get-edid version 1.4.1
---
> get-edid: get-edid version 2.0.0
9c9
< VBE string at 0x11110 "Intel(r)Crestline Graphics Chip Accelerated VGA BIOS"
---
> VBE string at 0x2110 "Intel(r)Crestline Graphics Chip Accelerated VGA BIOS"

I don't know if this is a problem or not. This is a Thinkpad X61 Tablet running Jaunty.

The STDOUT of get-edid is identical in both versions, and the output of parse-edid given this EDID information is also identical.

I also tested on another computer, a Dell Optiplex SX280 USFF. Basically the same results. Identical STDOUT from get-edid and parse-edid, but a similar difference in STDERR:

$ diff get-edid-1.4.err get-edid-2.0.err
1c1
< get-edid: get-edid version 1.4.1
---
> get-edid: get-edid version 2.0.0
9c9
< VBE string at 0x11110 "Intel(r)915G/915GV/910GL Graphics Chip Accelerated VGA BIOS"
---
> VBE string at 0x2110 "Intel(r)915G/915GV/910GL Graphics Chip Accelerated VGA BIOS"

Thanks for testing.

No, the difference (address of vga Bios) is not a problem, that's quite expected actually (don't ask, and just don't dare to look at libx86 *how* it handles graphic bios calls, you might be frightened *g*...).

What I'm quite failing to understand is the original bug description. I might be wrong, but I doubt that dpkg-reconfigure xserver-xorg has anything to do with read-edid (as read-edid is universe... so it can't be automatically available for xserver).

However with jaunty's X, which can very well read the edid on its own and which to my knowledge uses autotedection in most cases, I see no risk in updating read-edid.

ACK #2 from me (Scott, unless you oppose to it).

setting to confirmed based on my recent ACK #2 (and no opposition).

Please go ahead.

TJ, did you decide not to go ahead with this?

> What I'm quite failing to understand is the original bug description. I might be wrong, but I doubt that
> dpkg-reconfigure xserver-xorg has anything to do with read-edid (as read-edid is universe... so it can't
> be automatically available for xserver).

I am sure that "dpkg-reconfigure xserver-xorg" has something to do with read-edid simply because that's the error I got back when I invoked it! :-) I am not a ubuntu linux hacker, but I did do enough digging back at the time to assure myself that read-edid being missing was in fact the problem that stopped reconfiguration from taking place.

If read-edid is in universe and the xserver is supposed to be (re)configurable without packages that are in universe, then read-edid may need reclassification (or alternately, the reconfiguration process may need changing to avoid the dependency).

This bug was fixed in the package read-edid - 2.0.0-1ubuntu1

---------------
read-edid (2.0.0-1ubuntu1) karmic; urgency=low

  * debian/{control,rules}, Makefile.am:: build amd64 and lpia with
    libx86-dev (LP: #242043, debian bug 534742).

 -- Kees Cook <email address hidden> Fri, 26 Jun 2009 11:31:52 -0700