[lm-sensors] Call for 2.9.2

[lm-sensors] Call for 2.9.2

[Jean Delvare]

Hi all,

Could we plan a 2.9.2 release by the end of the month? It's three months
ago since the previous release already. The list of changes isn't very
long, but there are a few things people could be interested in: a new
driver (i2c-ali2563), Linux 2.6 support for decode-dimms.pl and rrd, and
a few improvements to sensors-detect which may help our support work.

Thanks,
-- 
Jean Delvare

[lm-sensors] Call for 2.9.2

[Jean Delvare]

Quoting myself:
> Could we plan a 2.9.2 release by the end of the month? It's three
> months ago since the previous release already. The list of changes
> isn't very long, but there are a few things people could be interested
> in: a new driver (i2c-ali2563), Linux 2.6 support for decode-dimms.pl
> and rrd, and a few improvements to sensors-detect which may help our
> support work.

On second thought, and let alone the fact that I obviously meant
i2c-ali1563, we probably want 2.9.2 to have a libsensors which supports
/sys/class/hwmon, as this paves the way to the true separation or
ISA-only hardware monitoring drivers from the i2c core.

Thanks,
-- 
Jean Delvare

[lm-sensors] Call for 2.9.2

[Jean Delvare]

Hi all,

I just committed the extra code libsensors needed to support the
upcoming hwmon class of Linux 2.6. This was the last thing that was
delaying the 2.9.2 release. It seems to work fine for me. I think we are
ready now.

Additionally, I fixed a couple warnings gcc 3.3 was reporting in i2c.
Shouldn't be a problem, these were minor changes only.

I would like us to release i2c 2.9.2 and lm_sensors 2.9.2 by the end of
August, or early September as the last limit. It's over 4 months since
the previous release already, even if the changelog isn't particularly
long. I'll announce that on our news web page.

So, let's decide that CVS is now is a feature freeze state, and only bug
fixes and documentation updates are accepted until the release.

Thanks,
-- 
Jean Delvare

[lm-sensors] Call for 2.9.2

[Jean Delvare]

Hi all,

Quoting myself:
> I would like us to release i2c 2.9.2 and lm_sensors 2.9.2 by the end
> of August, or early September as the last limit. It's over 4 months
> since the previous release already, even if the changelog isn't
> particularly long. I'll announce that on our news web page.

OK, so it seems to be the right time for the 2.9.2 release. Philip, are
you ready to go?

Note that this time libsensors needs a version bump, as we did not
change the version since 2.9.1 was released.

Thanks,
-- 
Jean Delvare

[lm-sensors] Call for 2.9.2

[Philip Edelbrock]

OK, I can do this tomorrow.  Is the libsensors version a minor or major? 
  Currently they are:

LIBMAINVER := 3
LIBMINORVER := 0.8


Phil

Jean Delvare wrote:
> Hi all,
> 
> Quoting myself:
> 
>>I would like us to release i2c 2.9.2 and lm_sensors 2.9.2 by the end
>>of August, or early September as the last limit. It's over 4 months
>>since the previous release already, even if the changelog isn't
>>particularly long. I'll announce that on our news web page.
> 
> 
> OK, so it seems to be the right time for the 2.9.2 release. Philip, are
> you ready to go?
> 
> Note that this time libsensors needs a version bump, as we did not
> change the version since 2.9.1 was released.
> 
> Thanks,

[lm-sensors] Call for 2.9.2

[Mark M. Hoffman]

Hi Jean:

* Jean Delvare <khali@linux-fr.org> [2005-08-30 22:31:52 +0200]:
> OK, so it seems to be the right time for the 2.9.2 release. Philip, are
> you ready to go?

As I pointed out on #linux-sensors, there is what I consider to be a bug in
the /sys/class/hwmon handling: if /sys/class/hwmon is not present, SPD/eeproms
will be read normally by sensors(1); but if it *is* present, then SPD/eeproms
will not be found or displayed.

Even if we plan to get rid of SPD/eeprom reading from sensors(1) (which I
think is sensible), the current behavior is surprising, to say the least.

I'm sorry I haven't had time to work up a fix - I have a four-day weekend
coming up during which I should have some time.  At any rate, IMO it's a
release-stopper.

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

[lm-sensors] Call for 2.9.2

[Jean Delvare]

Hi Philip,

> Is the libsensors version a minor or major?
> Currently they are:
>
> LIBMAINVER := 3
> LIBMINORVER := 0.8

Minor, there are no major changes I can think of, so we should go for
3.0.9.

Thanks,
--
Jean Delvare

[lm-sensors] Call for 2.9.2

[Jean Delvare]

Hi Mark,

On 2005-08-31, Mark M. Hoffman wrote:

> As I pointed out on #linux-sensors, there is what I consider to be a bug
> in the /sys/class/hwmon handling: if /sys/class/hwmon is not present,
> SPD/eeproms will be read normally by sensors(1); but if it *is* present,
> then SPD/eeproms will not be found or displayed.

It's a feature :')

> Even if we plan to get rid of SPD/eeprom reading from sensors(1) (which
> I think is sensible), the current behavior is surprising, to say the
> least.

This is true and is likely to raise an unreasonable number of support
requests.  We need to anticipate that, you are plain right.

> I'm sorry I haven't had time to work up a fix - I have a four-day
> weekend coming up during which I should have some time.  At any rate,
> IMO it's a release-stopper.

I have been thinking of it, and came to the conclusion that it was merely
a documentation issue.  I was planning to add en entry in the FAQ, a
news item on our website when we release, and a note to kernel26.html. 
Don't you think it is sufficient?  What do you suggest?  I would like
to avoid adding temporary code to libsensors if possible, as we will
ultimately drop non-hwmon support anyway.

Thanks,
--
Jean Delvare

[lm-sensors] Call for 2.9.2

[Philip Edelbrock]

Are we ready for release?  Any outstanding issues? (Jean?)


Phil

Mark M. Hoffman wrote:
> Hi Jean:
> 
> * Jean Delvare <khali@linux-fr.org> [2005-08-30 22:31:52 +0200]:
> 
>>OK, so it seems to be the right time for the 2.9.2 release. Philip, are
>>you ready to go?
> 
> 
> As I pointed out on #linux-sensors, there is what I consider to be a bug in
> the /sys/class/hwmon handling: if /sys/class/hwmon is not present, SPD/eeproms
> will be read normally by sensors(1); but if it *is* present, then SPD/eeproms
> will not be found or displayed.
> 
> Even if we plan to get rid of SPD/eeprom reading from sensors(1) (which I
> think is sensible), the current behavior is surprising, to say the least.
> 
> I'm sorry I haven't had time to work up a fix - I have a four-day weekend
> coming up during which I should have some time.  At any rate, IMO it's a
> release-stopper.
> 
> Regards,
> 

[lm-sensors] Call for 2.9.2

[Jean Delvare]

Hi Philip,

[Philip Edelbrock]
> Are we ready for release?  Any outstanding issues? (Jean?)

Let's wait for Mark Hoffman to tell what he thinks about my proposal for
the eeprom issue. If he is fine with it, we just need to update the FAQ
and then we can release. If not, we will have to wait for Mark to
implement whatever he thinks is necessary and test it, which will delay
the release.

Thanks,
--
Jean Delvare

[lm-sensors] Call for 2.9.2

[Philip Edelbrock]

OK, that's why I asked. :')


Phil

Jean Delvare wrote:
> Hi Philip,
> 
> [Philip Edelbrock]
> 
>>Are we ready for release?  Any outstanding issues? (Jean?)
> 
> 
> Let's wait for Mark Hoffman to tell what he thinks about my proposal for
> the eeprom issue. If he is fine with it, we just need to update the FAQ
> and then we can release. If not, we will have to wait for Mark to
> implement whatever he thinks is necessary and test it, which will delay
> the release.
> 
> Thanks,
> --
> Jean Delvare
> 

[lm-sensors] Call for 2.9.2

[Jean Delvare]

Hi again Mark,

> As I pointed out on #linux-sensors, there is what I consider to be a
> bug in the /sys/class/hwmon handling: if /sys/class/hwmon is not
> present, SPD/eeproms will be read normally by sensors(1); but if it
> *is* present, then SPD/eeproms will not be found or displayed.
> 
> Even if we plan to get rid of SPD/eeprom reading from sensors(1)
> (which I think is sensible), the current behavior is surprising, to
> say the least.
> 
> I'm sorry I haven't had time to work up a fix - I have a four-day
> weekend coming up during which I should have some time.  At any rate,
> IMO it's a release-stopper.

Any news about this? We're waiting for you. Can you please at least tell
us what you think should be done to address the issue?

Thanks,
-- 
Jean Delvare

[lm-sensors] Call for 2.9.2

[Mark M. Hoffman]

Hi Jean:

> On 2005-08-31, Mark M. Hoffman wrote:
> > As I pointed out on #linux-sensors, there is what I consider to be a bug
> > in the /sys/class/hwmon handling: if /sys/class/hwmon is not present,
> > SPD/eeproms will be read normally by sensors(1); but if it *is* present,
> > then SPD/eeproms will not be found or displayed.

* Jean Delvare <khali@linux-fr.org> [2005-08-31 11:30:23 +0200]:
> It's a feature :')

> On 2005-08-31, Mark M. Hoffman wrote:
> > Even if we plan to get rid of SPD/eeprom reading from sensors(1) (which
> > I think is sensible), the current behavior is surprising, to say the
> > least.

* Jean Delvare <khali@linux-fr.org> [2005-08-31 11:30:23 +0200]:
> This is true and is likely to raise an unreasonable number of support
> requests.  We need to anticipate that, you are plain right.

> On 2005-08-31, Mark M. Hoffman wrote:
> > I'm sorry I haven't had time to work up a fix - I have a four-day
> > weekend coming up during which I should have some time.  At any rate,
> > IMO it's a release-stopper.

* Jean Delvare <khali@linux-fr.org> [2005-08-31 11:30:23 +0200]:
> I have been thinking of it, and came to the conclusion that it was merely
> a documentation issue.  I was planning to add en entry in the FAQ, a
> news item on our website when we release, and a note to kernel26.html. 
> Don't you think it is sufficient?  What do you suggest?  I would like
> to avoid adding temporary code to libsensors if possible, as we will
> ultimately drop non-hwmon support anyway.

I don't think just documenting it is enough.  Here is an example scenario
that better demonstrates the present "surprising" behavior:

(with just i2c-i801 and eeprom modules loaded using Linux 2.6.12-rc6-mm2)

# sensors

(shows eeprom info)

# modprobe lm78

# sensors

(shows lm78 info but *not* eeprom info)

I know you don't want a lot of temporary code shoved in there, and for that 
matter neither do I.  So here is a minimal patch.  It simply disables eeprom
display for all 2.6.x kernels.  We can rip out the guts of the eeprom code
for the next release - my libsysfs patchset in progress already does some
of that anyway.

This should be easier to document and may also generate fewer bug reports.

Index: lib/proc.c
=================================RCS file: /home/cvs/lm_sensors2/lib/proc.c,v
retrieving revision 1.45
diff -U4 -r1.45 proc.c
--- lib/proc.c	19 Aug 2005 02:59:52 -0000	1.45
+++ lib/proc.c	5 Sep 2005 17:51:22 -0000
@@ -92,8 +92,12 @@
 	/* We don't care about subclients */
 	if (len >= 10 && !strcmp(x + len - 10, " subclient"))
 		return 0;
 
+	/* also, ignore eeproms for all 2.6.x kernels */
+	if (!strcmp(x, "eeprom"))
+		return 0;
+
 	/* Fill in the entry fields */
 	entry.name.prefix = strdup(x);
 	if (entry.name.prefix = NULL)
 		return -SENSORS_ERR_PARSE; /* No better error :( */

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

[lm-sensors] Call for 2.9.2

[Jean Delvare]

Hi Mark,

> * Jean Delvare <khali@linux-fr.org> [2005-08-31 11:30:23 +0200]:
> > I have been thinking of it, and came to the conclusion that it was
> > merely a documentation issue.  I was planning to add en entry in the
> > FAQ, a news item on our website when we release, and a note to
> > kernel26.html.  Don't you think it is sufficient?  What do you
> > suggest?  I would like to avoid adding temporary code to libsensors
> > if possible, as we will ultimately drop non-hwmon support anyway.
> 
> I don't think just documenting it is enough.  Here is an example
> scenario that better demonstrates the present "surprising" behavior:
> 
> (with just i2c-i801 and eeprom modules loaded using Linux
> 2.6.12-rc6-mm2)
> 
> # sensors
> 
> (shows eeprom info)
> 
> # modprobe lm78
> 
> # sensors
> 
> (shows lm78 info but *not* eeprom info)

I can reproduce that too, of course.

> I know you don't want a lot of temporary code shoved in there, and for
> that  matter neither do I.  So here is a minimal patch.  It simply
> disables eeprom display for all 2.6.x kernels.  We can rip out the
> guts of the eeprom code for the next release - my libsysfs patchset in
> progress already does some of that anyway.
> 
> This should be easier to document and may also generate fewer bug
> reports.

Agreed. There are minor problems though.

1* Your minimal hack leaves dead code in libsensors. It's probably not
much of a problem, as long as we don't forget to remove it right after
the release.

2* Eeproms are not the only affected chips. "sensors" displays empty
entries for all i2c chips that have a driver. This includes the adv7176
and saa7110 video devices for me. They too will disappear when one loads
any hwmon driver. It should cause less surprise than for eeprom, because
no useful information is displayed, but it might still confuse the
users. I have no immediate solution though.

Feel free to commit your patch BTW, it looks good.

Thanks,
-- 
Jean Delvare

[lm-sensors] Call for 2.9.2

[Mark M. Hoffman]

Hi:

I wrote:
> > I know you don't want a lot of temporary code shoved in there, and for
> > that  matter neither do I.  So here is a minimal patch.  It simply
> > disables eeprom display for all 2.6.x kernels.  We can rip out the
> > guts of the eeprom code for the next release - my libsysfs patchset in
> > progress already does some of that anyway.
> > 
> > This should be easier to document and may also generate fewer bug
> > reports.

* Jean Delvare <khali@linux-fr.org> [2005-09-05 22:51:42 +0200]:
> Agreed. There are minor problems though.
> 
> 1* Your minimal hack leaves dead code in libsensors. It's probably not
> much of a problem, as long as we don't forget to remove it right after
> the release.

Sure, I didn't think you wanted to perform major surgery just prior to
the release.

> 2* Eeproms are not the only affected chips. "sensors" displays empty
> entries for all i2c chips that have a driver. This includes the adv7176
> and saa7110 video devices for me. They too will disappear when one loads
> any hwmon driver. It should cause less surprise than for eeprom, because
> no useful information is displayed, but it might still confuse the
> users. I have no immediate solution though.

Ooh, I didn't realize that: yeah, it's awkward.  I suppose my suggested
patch could be expanded into a blacklist - diminishing returns though.

> Feel free to commit your patch BTW, it looks good.

OK

Regards,

-- 
Mark M. Hoffman
mhoffman@lightlink.com

[lm-sensors] Call for 2.9.2

[Jean Delvare]

Hi Mark,

> Sure, I didn't think you wanted to perform major surgery just prior to
> the release.

And you were of course right at that. I was merely trying to figure out
what the next (post-release) steps would be if we went that direction.
And it looks OK to me.

> > 2* Eeproms are not the only affected chips. "sensors" displays empty
> > entries for all i2c chips that have a driver. This includes the
> > adv7176 and saa7110 video devices for me. They too will disappear
> > when one loads any hwmon driver. It should cause less surprise than
> > for eeprom, because no useful information is displayed, but it might
> > still confuse the users. I have no immediate solution though.
> 
> Ooh, I didn't realize that: yeah, it's awkward.  I suppose my
> suggested patch could be expanded into a blacklist - diminishing
> returns though.

On second thought, I'm not sure it's even worth the effort, as sensors
doesn't print anything for these chips in the first place, so I doubt
people will complain or even wonder. Also, the list of non-sensors i2c
chips is so long that a blacklist would be impossible to maintain
anyway.

> > Feel free to commit your patch BTW, it looks good.
> 
> OK

Nice. I updated the FAQ to explain why the EEPROMs were disappearing
(4.33.2). I guess we are ready for release this time.

Philip, the next steps are up to you: bump the library version to 3.0.9,
and release!

Thanks,
-- 
Jean Delvare

[lm-sensors] Call for 2.9.2

[Philip Edelbrock]

On Sep 6, 2005, at 12:16 PM, Jean Delvare wrote:
>
> Philip, the next steps are up to you: bump the library version to  
> 3.0.9,
> and release!

OK!


Phil

[lm-sensors] Call for 2.9.2

[Philip Edelbrock]

On Sep 6, 2005, at 12:16 PM, Jean Delvare wrote:

>
>
> Philip, the next steps are up to you: bump the library version to  
> 3.0.9,
> and release!

Whew!  OK, done. MDS, you can do the Freshmeat announce if you wish.


Phil

[lm-sensors] Call for 2.9.2

[Henrik Brix Andersen]

On Tue, 2005-09-06 at 13:16 -0700, Philip Edelbrock wrote:
> Whew!  OK, done. MDS, you can do the Freshmeat announce if you wish.

I've added ebuilds for lm_sensors-2.9.2 and i2c-2.9.2 to Gentoo Portage.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050906/44a49e12/attachment-0001.bin

[lm-sensors] Call for 2.9.2

[Jean Delvare]

Hi Brix,

> > Whew!  OK, done. MDS, you can do the Freshmeat announce if you wish.
>
> I've added ebuilds for lm_sensors-2.9.2 and i2c-2.9.2 to Gentoo Portage.

Great. I have uploaded the i2c patches at the usual place on my site,
updated my i2c installation guide accordingly, and just posted the
announcement on Freshmeat.

Let it also be noted that the project is now 7 year old, and still alive
and improving. Sounds like a great achievement to me, and I would like
to thank once again all the brilliant folks who laid down the project
foundations that long ago.

--
Jean Delvare

[lm-sensors] Call for 2.9.2

[Henrik Brix Andersen]

Hi,

On Wed, 2005-09-07 at 15:53 +0200, Jean Delvare wrote:
> Great. I have uploaded the i2c patches at the usual place on my site,
> updated my i2c installation guide accordingly, and just posted the
> announcement on Freshmeat.

Where is "the usual place"?

> Let it also be noted that the project is now 7 year old, and still alive
> and improving. Sounds like a great achievement to me, and I would like
> to thank once again all the brilliant folks who laid down the project
> foundations that long ago.

I would like to second that.

I hope to be able to contribute a little more to the project in the
future, now that I have taken over maintenance of the lm_sensors and i2c
ebuilds in Gentoo Portage.

Regards,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20050907/b53f6965/attachment.bin

[lm-sensors] Call for 2.9.2

[Jean Delvare]

Hi Brix,

> Where is "the usual place"?

http://khali.linux-fr.org/devel/i2c/

This is a legacy of the i2c 2.8 times. It has much less interest now that
i2c 2.9 is back into a Linux 2.4 compatibility state, but the page
seemed to have success so I decided to keep it online and to update it
on each new i2c release and each new 2.4 kernel release.

--
Jean Delvare