[Nut-upsdev] openSUSE 11.0 - NUT

Arnaud Quette aquette.dev at gmail.com
Wed May 7 13:02:20 UTC 2008


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.

>   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, ...)

>  Arnaud Quette wrote:
>
>  > I've tested it with "make -j2", and 2 config set (--disable-shared for
>  > full static, and --enable-static for linking clients on the shared lib
>  > while still shipping the static lib) and everything seems fine.
>  > Can you confirm on your side?
>
>  Yes, it seems to fix parallel build. Tried ~10 times, no failure.

perfect

>  Regarding my hald-addon path patch - it is an intermediate solution,
>  which will probably break in SuSE:
>
> https://bugzilla.novell.com/show_bug.cgi?id=304316
>
>  But I guess that upstream will take care of correct setting of
>  hald-addon directory (see bugs in my previous mail).

well, I've asked Dave and Danny to complete hal.pc and provide these
dirs for long.
I hope it will succeed since their solution (the current method in
NUT) is suboptimal!

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.

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...

cheers,
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/



More information about the Nut-upsdev mailing list