Date: Thu, 18 Dec 2003 22:42:36 +0100
From: Haakon Riiser <haakon.riiser@fys.uio.no>
To: sensors@Stimpy.netroedge.com
Subject: lm_sensors 2.8.2 / DESTDIR / root
The reason for this email is that I always try to avoid running
Makefiles as root, even during 'make install'. Therefore, I
always use the DESTDIR feature, when it's available. Until today,
I always built i2c and lm_sensors by doing
$ make
$ make -i install DESTDIR=/foo
$ cd /foo && su root && fix permissions/ownership && install
The -i flag to make install is a kludge to avoid having to be root
while installing to the DESTDIR, and it's only required because
the files are installed with "-o root -g root". Using the -i
flag is of course not a good idea, since more fatal errors can
easily fly by undetected.
Today, I upgraded to Linux 2.6.0, and tried a similar install
procedure for lm_sensors, except that the make target is now "user"
and the install target is "user_install". I now noticed that the
DESTDIR variable is not used everywhere in "user_install", so I
couldn't use the -i kludge anymore. Instead, I wrote a patch that
removes the "-o root -g root" arguments to install everywhere, and
I also tried to add DESTDIR to all files/directories installed.
(The patch only applies to lm_sensors, not i2c, since only
lm_sensors is required in Linux 2.6.0.)
There's really no reason to say -o root -g root anyway, since if you
do install directly with make install, you have to be logged in as
root, and then the files will get the right ownership by default.
Much of the point of installing to a temporary DESTDIR is that you
don't have to be root, and that you can prepare the installation
by hand. Fixing the ownership is trivial:
chown -R root.root $DESTDIR
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2189 7894878c-1315-0410-8ee3-d5d059ff63e0
Subject:
[PATCH] Re: SOLVED: Ticket #1409
Date:
Fri, 03 Oct 2003 16:48:32 +0200
From:
Bjørn Mork <bjorn@mork.no>
Organization:
m
To:
Mark Studebaker <mds@paradyne.com>
CC:
lm78@stimpy.netroedge.com, LM_Sensors developers <sensors@stimpy.netroedge.com>
References:
1 , 2 , 3
Bjørn Mork <bjorn@mork.no> writes:
> Mark Studebaker <mds@paradyne.com> writes:
>
>> If you port over the super i/o code from one of the 3 drivers listed
>> above
>> and send us a patch we'll include it.
>
> OK. Will do.
Here's the patch as promised. Took the code from smsc47m1.c. It
currently only changes behaviour for the IT8712F since I cannot test
on any other IT87-chips, and the comments in sensors-detect made me
uncertain whether they really use the same key/exit sequence.
Also changed sensors-detect somewhat to support longer devids and exit
sequences. Don't know if you'll approve my perl though...
Bjørn
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2170 7894878c-1315-0410-8ee3-d5d059ff63e0
detected at the same address, cause the driver to be told to
ignore this address. Untested.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@2000 7894878c-1315-0410-8ee3-d5d059ff63e0
Mainly targetted (and tested) with the 6651, but should work with
the MAX6550.
See doc/chips/max6650 for notes, bugs, assumptions, etc.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1987 7894878c-1315-0410-8ee3-d5d059ff63e0
Detect which of /dev/i2c-*, /dev/i2c/* or /dev/i2c* should be
used.
Stop if no i2c device files exist.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1944 7894878c-1315-0410-8ee3-d5d059ff63e0
- separate detection sub for W83L784R/AR
- ranges limited to what the specs say for I2C-only chips
- add detection for the AS99127F rev.2 and explicit detection of
the ASB100 Bach
- improve code readability
- do not ignore the chipset ID LSB anymore; explicit acceptation
of 0x11 as a W83781D ID instead
- fix a bug in secondary LM75 address extraction
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1903 7894878c-1315-0410-8ee3-d5d059ff63e0
Change the name and URI for rivatv (was i2c-riva).
Better handling of disabled drivers (for future use).
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1883 7894878c-1315-0410-8ee3-d5d059ff63e0
Jean Delvare