[Nut-upsdev] openSUSE 11.0 - NUT

[Arnaud Quette]

2008/5/7 Stanislav Brabec <sbrabec at suse.cz>:
> Arnaud Quette wrote:
>  > Hey Stanislav,
>  >
>  > 2008/5/2 Stanislav Brabec <sbrabec at suse.cz>:
>  > > Arnaud Quette wrote:
>  > >
>  > >  > I've seen another mail from a SuSE guy, and fwded by Arjen, about
>  > >  > libtool and possibly dependencies. I gotta check it.
>  > >
>  > >  Probably Andreas Schwab. His patch (see the attachment) applies on
>  > >  2.2.2, but breaks the build. Without his patch, it fails on IA64 and
>  > >  S390. I will look deeper into it:
>  >
>  > any news on that side?
>  > I've not yet taken time to investigate deeper this point.
>
>  I already sent a patch with a rewrite of libtool stuff, which should fix
>  it without any tricks.

right, I forgot that while emptying my queue...
I'll look at that one, though there are removal/simplifications that
seems strange at first (15 seconds analysis!)

>  > >   gcc -DHAVE_CONFIG_H -I. -I../include -I../include -O2 -fmessage-length=0 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -Wall -Wsign-compare -MT parseconf.lo -MD -MP -MF .deps/parseconf.Tpo -c parseconf.c  -fPIC -DPIC -o .libs/parseconf.o
>  > >  mv -f .deps/state.Tpo .deps/state.Po
>  > >  mv -f .deps/parseconf.Tpo .deps/parseconf.Po
>  > >  mv -f .deps/common.Tpo .deps/common.Po
>  > >  rm -f libcommon.a
>  > >  /usr/bin/ar cru libcommon.a common.o
>  > >  ranlib libcommon.a
>  > >  mv -f .deps/parseconf.Tpo .deps/parseconf.Plo
>  > >  mv: cannot stat `.deps/parseconf.Tpo': No such file or directory
>  > >  make[1]: *** [parseconf.lo] Error 1
>  > >  make[1]: Leaving directory `/usr/src/packages/BUILD/nut-2.2.2-pre3/common'
>  > >
>  > > make: *** [all-recursive] Error 1
>  > >
>  > >  I am attaching one another cosmetic patch. It prevents warning mentioned
>  > >  in the patch preamble, which is considered as error by SuSE QA tools.
>  > >  Adding an explicit cast lets to know to the compiler, that cast from
>  > >  integer for void * is really intended here.
>  >
>  > I've fixed these calls to conform to the function's prototype (commit underway).
>  >
>  > btw, is there a central point for accessing NUT related stuffs in
>  > opensuse (source packages with patchs, QA reports, ...)
>
>  No, ony Bugzilla and Build Service. But it is possible to create Build
>  Service project for it or join to a similar project.

we'll have to discuss this later. This might integrate in NUT's global QA:
http://test.networkupstools.org/Documentation/UserManual/QualityAssurance

btw, if you can give me the links to complete the above...

>  > What is missing (if you can add this comment to
>  > https://bugs.freedesktop.org/show_bug.cgi?id=15768) is the .fdi path
>  > (something like hal_fdidir) to be able to install our .fdi file, since
>  > we won't be able to guess the right path otherwise.
>  > Note that this is less mandatory since we're not on a binary dependent
>  > path here.
>
>  But it's a good idea as well. Feel free to comment the bug. If not, I'll
>  do it.

please, be my guest ;-)

>  > however, I'm preparing an early fix in m4/nut_check_libhal.m4, so that
>  > when the HAL fix is released, we're already ready.
>  > or at least, the needed change would be limited to the final variable name...
>
>  Well, you will still have to support old HAL and guessing.

that's the intent. I've just commited r1485

>  FYI, I am now trying to get to work NUT HAL in openSUSE 11.0. I have no
>  success yet. Battery service is not correctly registered, even if I
>  apply this patch. It seems, that hal did some changes in the latest
>  snapshot.
>
>  --- scripts/hal/ups-nut-device.fdi
>  +++ scripts/hal/ups-nut-device.fdi
>  @@ -1,7 +1,7 @@
>   <?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
>   <deviceinfo version="0.2">
>    <device>
>  -    <match key="info.bus" string="usb_device">
>  +    <match key="info.subsystem" string="usb_device">
>
>        <!-- MGE UPS SYSTEMS -->
>        <match key="usb_device.vendor_id" int="0x0463">

we'll have to check that, but I'll be on a long week end in 5 mn,
until next tuesday...
have you launched hald in debug mode to see what occurs when you plug
the UPS (ie is the nut addon fired up...)?
you will also want to set NUT_HAL_DEBUG env. var to something that
matches the nut debug level (ie 5 == -DDDDD)
Note that it can have a link with the user and group ownership (ie
user nut in haldaemon group).
I'm interested in these traces.

btw, have you seen Dave's today post about the (non) future of HAL?
http://lists.freedesktop.org/archives/hal/2008-May/011560.html

Arnaud
-- 
Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
Free Software Developer - http://arnaud.quette.free.fr/