Call for 2.8.0 soon

Call for 2.8.0 soon

[Mark D. Studebaker]

I think things are getting into shape here after a lot of work.
Maybe we can do a release in a week or two?

Open issues, please comment or add to list:

- sensors-detect "UTF" issue
- libsensors numbering because of binary incompatibility..... go to 1.5.0 or 2.0.0?
- Delete sensors.h in sensors/include, move files?
- Incompatibility w/ 2.4 kernel i2c structs
- Need testing against kernel 2.4.9
- Mkpatch - abandon, fix, what?
- Update README, INSTALL, etc.

Call for 2.8.0 soon

[Greg KH]

On Wed, Jun 11, 2003 at 08:16:58PM -0400, Mark D. Studebaker  wrote:
> - Incompatibility w/ 2.4 kernel i2c structs

You need to make sure you get the i2c changes that are now in
2.4.21-rc7.  They fix some serious i2c-dev problems.

thanks,

greg k-h

Call for 2.8.0 soon

[Philip Pokorny]

Mark D. Studebaker wrote:
> 
> I think things are getting into shape here after a lot of work.
> Maybe we can do a release in a week or two?
> 
> Open issues, please comment or add to list:
> 
> - sensors-detect "UTF" issue
> - libsensors numbering because of binary incompatibility..... go to 
> 1.5.0 or 2.0.0?

What about going with 2.8.0...  Then track the lm_sensors version.

> - Delete sensors.h in sensors/include, move files?

Er... kernel/include

If we move sensors.h, should probably move i2c-dev.h from that directory 
as well...

> - Incompatibility w/ 2.4 kernel i2c structs
> - Need testing against kernel 2.4.9
> - Mkpatch - abandon, fix, what?
> - Update README, INSTALL, etc.
> 



-- 
Philip Pokorny, Director of Engineering
Tel: 415-358-2635   Fax: 415-358-2646   Toll Free: 888-PENGUIN
PENGUIN COMPUTING, INC.
www.penguincomputing.com

Call for 2.8.0 soon

[Jean Delvare]

> > - libsensors numbering because of binary incompatibility..... go to 
> > 1.5.0 or 2.0.0?
> 
> What about going with 2.8.0...  Then track the lm_sensors version.

Why that? There is no reason we number the lib version according to the
package version. The lib compatibility is unlikely to change that often.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Call for 2.8.0 soon

[Jean Delvare]

> I think things are getting into shape here after a lot of work.
> Maybe we can do a release in a week or two?

Would be great, but I doubt we'll have all the issues below fixed in two
weeks. I admit there's a need for a new release as soon as possible
though.

> - sensors-detect "UTF" issue

I'm on it.

> - Need testing against kernel 2.4.9

I could take care of this. I could also test on some kernels between
2.4.9 and 2.4.18 (the oldest I'm still using). I just have to avoid the
ones that can destroy the machine... 2.4.11 and 2.4.15 IIRC.

And I'm adding:

- Fix GCC 3 compilation warnings.

I've seen some, I'll have a look and see what I can do.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Call for 2.8.0 soon

[Philip Pokorny]

Jean Delvare wrote:
>>>- libsensors numbering because of binary incompatibility..... go to 
>>>1.5.0 or 2.0.0?
>>
>>What about going with 2.8.0...  Then track the lm_sensors version.
> 
> 
> Why that? There is no reason we number the lib version according to the
> package version. The lib compatibility is unlikely to change that often.

Actually, it is.

Anytime a driver is added to the library, the library version needs to 
change.  This is because the library has compiled in code for every chip 
that it knows about.  And the sensors executable has references to every 
chip that is supported by the matching libsensors.

I think the chances are high that at each release of lm_sensors, at 
least one new driver will be added...

This is also part of my motivation for trying to remove this coupling in 
  the "rewrite" of libsensors...

:v)

-- 
Philip Pokorny, Director of Engineering
Tel: 415-358-2635   Fax: 415-358-2646   Toll Free: 888-PENGUIN
PENGUIN COMPUTING, INC.
www.penguincomputing.com

Call for 2.8.0 soon

[Mark D. Studebaker]

One reason not to have the version numbers track is that we should
advance the major number of the library when there is an incompatibility introduced
within the library.

We generally advance the middle number of the sensors and i2c packages when there
is support removed for a certain kernel version.

In other words the guidelines for the two numbering systems are independent.

Philip Pokorny wrote:
> Jean Delvare wrote:
> 
>>>> - libsensors numbering because of binary incompatibility..... go to 
>>>> 1.5.0 or 2.0.0?
>>>
>>>
>>> What about going with 2.8.0...  Then track the lm_sensors version.
>>
>>
>>
>> Why that? There is no reason we number the lib version according to the
>> package version. The lib compatibility is unlikely to change that often.
> 
> 
> Actually, it is.
> 
> Anytime a driver is added to the library, the library version needs to 
> change.  This is because the library has compiled in code for every chip 
> that it knows about.  And the sensors executable has references to every 
> chip that is supported by the matching libsensors.
> 
> I think the chances are high that at each release of lm_sensors, at 
> least one new driver will be added...
> 
> This is also part of my motivation for trying to remove this coupling in 
>  the "rewrite" of libsensors...
> 
> :v)
> 

Call for 2.8.0 soon

[Mark D. Studebaker]

OK I think we are getting close.

- I copied over Greg's i2c fix from 2.4.21
- GCC 3.3 warnings Khali is working?
- UTF issue fixed for new perls, now we need a fix for old perls
- libsensors renumbered 2.0.0
- sensors.h removed from CVS
- mkpatch fixed, some testing done
- most docs updated.

let's try to wrap things up and release in a week?




Mark D. Studebaker wrote:
> 
> I think things are getting into shape here after a lot of work.
> Maybe we can do a release in a week or two?
> 
> Open issues, please comment or add to list:
> 
> - sensors-detect "UTF" issue
> - libsensors numbering because of binary incompatibility..... go to 
> 1.5.0 or 2.0.0?
> - Delete sensors.h in sensors/include, move files?
> - Incompatibility w/ 2.4 kernel i2c structs
> - Need testing against kernel 2.4.9
> - Mkpatch - abandon, fix, what?
> - Update README, INSTALL, etc.
> 

Call for 2.8.0 soon

[Jean Delvare]

> OK I think we are getting close.

Looks so, yes.

> - GCC 3.3 warnings Khali is working?

I've fixed some warnings these days, but not the GCC 3.2 ones. Note that
I don't have GCC 3.3 anyway, so I can't say anything about this one. We
had a report from a Japanese user (Ishikawa, Chiaki) about GCC 3.3, it
seems that it has more to do with Makefiles than with code by itself. I
think MDS will handle this better than I would.

Two warnings remain (apart from ones possibly generated by GCC 3.2):

1* via686a_find defined but not used. I would #if 0/#endif the function,
is that the right thing to do?

2* Some warnings in the config file parser. AFAIK, this is generated
code. I don't know how to fix these (if it is only possible). Maybe we
can just define -Wno-unused for these specific files, but I don't know
how to do this either. Anyone?

> - UTF issue fixed for new perls, now we need a fix for old perls

Should be working now.

> let's try to wrap things up and release in a week?

Would be great :)

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Call for 2.8.0 soon

[Jean Delvare]

> - GCC 3.3 warnings Khali is working?

GCC 3.2 warnings fixed.

Oh, by the way, I got this message when installing latest CVS:

***********************************************************************
*******
Warning: This is the first installation of the libsensors.so*
         library files in /usr/local/lib !!!
         You must run /sbin/ldconfig to update the library cache or
         the userspace tools may fail or have unpredictable results !!!
***********************************************************************
*******

Though I think the message can be useful in some cases, I already had
the libraries installed there, but a previous version (1.4.0 as opposed
to 2.0.0). I think the message should mention that, or it will seem to
be pointless to users in this case.

Also, why don't we run ldconfig by ourselves in this case? We could even
grep /etc/ld.so.conf for /usr/local/lib and display a warning only if
the line is not found (or add it by ourselves, but I'm not in favor of
this).

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Call for 2.8.0 soon

[Jean Delvare]

> We had a report from a Japanese user (Ishikawa, Chiaki) about GCC
> 3.3, it seems that it has more to do with Makefiles than with code by
> itself. I think MDS will handle this better than I would.

It was actually easy and I could handle it.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/