March 2010 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] netcdf package, glibc's debuginfo + valgrind issue
by Filipe Fernandes 08 Mar '10

08 Mar '10

Hello, I have a package (netcdf4.1) that compiles OK for 32 bits but returns the following error for 64 bits: valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: strlen valgrind: in an object with soname matching: ld-linux-x86-64.so.2 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld-linux-x86-64.so.2 valgrind: valgrind: Possible fixes: (1, short term): install glibc's debuginfo valgrind: package on this machine. (2, longer term): ask the packagers valgrind: for your Linux distribution to please in future ship a non- valgrind: stripped ld.so (or whatever the dynamic linker .so is called) valgrind: that exports the above-named function using the standard valgrind: calling conventions for this platform. valgrind: valgrind: Cannot continue -- exiting now. Sorry. I could turn valgrind test off. However I would like to know if there is a way to add glibc's debuginfo as a Build requirement. Thank you, Filipe ps: package: https://build.opensuse.org/package/show?package=netcdf&project=home%3Aocefp… full log: https://build.opensuse.org/package/live_build_log?arch=x86_64&package=netcd…

1 0

[opensuse-packaging] codelite build breaks for openSUSE <=11.1
by Mariusz Fik 08 Mar '10

08 Mar '10

Hi, I just tried to update codelite package in my home repository. But build fails for openSUSE <= 11.1 but for 11.2 and build is successful. http://tinyurl.com/ycpdr5a Any hint how to fix build for oS <= 11.1? -- Pozdrawiam / Best regards, Mariusz Fik, openSUSE Community Member

3 3

[opensuse-packaging] Maintenance reboot for our infrastructure 2010-03-09
by Lars Vogdt 08 Mar '10

08 Mar '10

Hi openSUSE Users There is some maintenance to be done in the following areas of our openSUSE infrastructure: * build.opensuse.org (Buildservice) * download.opensuse.org (Download infrastructure) * svn/git.opensuse.org As result, there will be a brief outage of all services provided by this machines Tuesday, 2010-03-09, 09:00 German time (CET) The downtime is expected to be 15-30 minutes for all hosts. Apologies for inconveniencies this may cause. Please contact admin(a)opensuse.org with any queries. Your openSUSE Admins -- http://en.opensuse.org/Downtime/2010-03-09 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] renaming for nagios-nrpe
by Christian 06 Mar '10

06 Mar '10

Hi, I am not very happy with naming of nrpe and its sub-pkg. we have nagios-nrpe-client, nagios-nrpe-server While seeing the client pkg I'll be misled to install this pkg on the remote box and vice versa. But the "client" pkg has to be installed on the nagios box. That's why I am thinking of: - nagios-nrpe it is the package to be installed on the remote box. - nagios-nrpe-plugin or nagios-plugins-nrpe just the name will let you associate to install this pkg on the nagios box. What do you think ? Any recommendations are welcome Kind Regards Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 3

[opensuse-packaging] FYI: kde-obs-generator
by Lubos Lunak 05 Mar '10

05 Mar '10

Hello, for those who could find this interesting, I've created a tool that automatically creates .spec and .dsc files from a source tarball that make the package build on several (also non-openSUSE) distributions supported by the OBS. It is currently still an experimental work in progress, but it works quite well already. It currently requires a specially set up repository (because of mappings between different distributions). It can now handle CMake-based projects (I've only tried with KDE and Qt) and few various KDE theme formats. See http://en.opensuse.org/KDE/Build_Service/Cross-distro , http://www.kdedevelopers.org/node/4177 and http://gitorious.org/kde-obs-generator for further details. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak(a)suse.cz , l.lunak(a)kde.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] Shared library packaging
by Guido Berhoerster 04 Mar '10

04 Mar '10

Hello, I have a shared library package named libmupen64plus2 (based on its soname libmupen64plus.so.2) and an accompanying development package with the headers and documentation named libmupen64plus-devel (following the shlibs packaging policy). The latter explicitly requires the former (it has a Requires: libmupen64plus2 = %{version}). Yet rpmlint now complains with libmupen64plus-devel.i586: W: no-dependency-on libmupen64plus/libmupen64plus-libs/liblibmupen64plus Is there anything wrong here or can I just ignore that? -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 3

[opensuse-packaging] 13-check-invalid-provides trips over '+' in package name due to grep -E
by Hans-Peter Jansen 03 Mar '10

03 Mar '10

Hi Dirk, this single test actively hinders to correctly release an important package (for me): hylafax+. Yup, one could argue, that using + in project names is somewhat silly, but it's exactly, what is needed here. HylaFAX is effectively forked by HylaFAX+. Now, the situation is unfortunate: hylafax is released with major version 4 and 6, while hylafax+ is released as 5. Keeping the name hylafax will replace the + version with the 6th version on certain occasions, and those, who follow both developments will agree, that this is the least desired. Either use one or the other but don't replace them vice versa, please. You will find my packages here: https://build.opensuse.org/project/show?project=home%3Afrispete%3Ahylafax What I would like to do is letting my hylafax+ package: Provides: hylafax fax_daemon Conflicts: hylafax sendfax Obsoletes: hylafax and all is well, up to 13-check-invalid-provides: the test boils down to: $ echo hylafax | grep -E "^hylafax+[[:space:]]*$" hylafax $ while this is desired here: $ echo hylafax | grep -G "^hylafax+[[:space:]]*$" $ Using basic regex provide exactly the means of the unversioned package name check, while not tripping over the '+'. According to the man page, only ?, +, {, |, (, and ) lose their special meaning, thus: $ echo hylafax+ | grep -G "^hylafax+[[:space:]]*$" hylafax+ $ the + is matched literally, which is desired. I agree, this case is pathologic, but I can't imagine any ill side effects on this change, do you? It's a real pity to not being able to tag this package correctly, e.g. allowing for a clean package replacement. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 12

[opensuse-packaging] Build fails during linking, but executing the command manually goes fine
by Richard Bos 01 Mar '10

01 Mar '10

Hi, about 2 weeks ago I asked the same question, but this time it is caused by a different reason and I can't find a solution for it. I hope someone on this list knows, just like last time. I'm trying to build kfritz version 0.0.4 released some days ago. During linking it stops with the following error: In function `fritz::FritzClient::CalculateLoginResponse(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)': /usr/src/packages/BUILD/kfritz-0.0.4/libfritz++/FritzClient.cpp:73: undefined reference to `gcry_md_hash_buffer' When moving into the 'chroot', I have the following the information: chroot $ rpm -qa | grep crypt libgcrypt11-1.4.4-2.2.i586 libxcrypt-3.0.2-3.2.i586 libgcrypt-devel-1.4.4-2.2.i586 chroot $ grep -A2 gcry_md_hash_buffer /usr/include/gcrypt.h void gcry_md_hash_buffer (int algo, void *digest, So the function seems present.... The linker command is: /usr/bin/c++ -Wnon-virtual-dtor -Wno-long-long -ansi -Wundef -Wcast-align - Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions - fno-check-new -fno-common -Woverloaded-virtual -fno-threadsafe-statics - fvisibility=hidden -fvisibility-inlines-hidden -fexceptions -O2 -g -DNDEBUG - DQT_NO_DEBUG -fPIC -Wl,--enable-new-dtags CMakeFiles/kfritz.dir/kfritz_automoc.o CMakeFiles/kfritz.dir/KFritz.o CMakeFiles/kfritz.dir/KFritzWindow.o CMakeFiles/kfritz.dir/KFonbookModel.o CMakeFiles/kfritz.dir/KSettingsFonbooks.o CMakeFiles/kfritz.dir/KSettingsFritzBox.o CMakeFiles/kfritz.dir/KFritzModel.o CMakeFiles/kfritz.dir/KCalllistModel.o CMakeFiles/kfritz.dir/LibFritzInit.o CMakeFiles/kfritz.dir/Log.o CMakeFiles/kfritz.dir/LogDialog.o CMakeFiles/kfritz.dir/QAdaptTreeView.o CMakeFiles/kfritz.dir/KSettings.o -o kfritz -rdynamic -L/usr/src/packages/BUILD/kfritz-0.0.4/builddir/lib /usr/lib/libkdeui.so.5.3.0 /usr/lib/libknotifyconfig.so.4.3.0 -lgcrypt -lgpg- error lib/libfritz++.a lib/libtcpclient++.a lib/libpthread++.a /usr/lib/libkdeui.so.5.3.0 -lQtSvg /usr/lib/libkdecore.so.5.3.0 -lQtDBus - lQtCore -lpthread -lQtGui Which has the call to -lgcrypt. Copy and pasting the linker command in the 'chroot' environment results in a executable.... (most likely due to the absence of the compiler directive 'AS_NEEDED'. What do I need to add to the spec file, to get the linker command working? Last time, it was suggested to add libcrypto, but I can't find a package that provide it (and that is in the base distribution). -- Richard -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 3

[opensuse-packaging] invalid-lc-messages-dir warning
by Malcolm 01 Mar '10

01 Mar '10

Hi How does one correctly fix the warning; invalid-lc-messages-dir /usr/share/locale/sr@Latn/LC_MESSAGES/ Which produces a second warning because I've used the %dir standard-dir-owned-by-package /usr/share/locale/sr@Latn/LC_MESSAGES standard-dir-owned-by-package /usr/share/locale/sr@Latn This package owns a directory that is part of the standard hierarchy, which can lead to default directory permissions or ownerships being changed to something non-standard. -- Cheers Malcolm °¿° (Linux Counter #276890) SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 2.6.27.42-0.1-default up 13:30, 2 users, load average: 1.51, 0.77, 0.48 GPU GeForce 8600 GTS Silent - CUDA Driver Version: 190.53 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 2