February 2010 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Using the gold linker
by Cristian Rodríguez 22 Feb '10

22 Feb '10

Hi: Is there any way to use the gold linker in a project-wide way and/or per package basis without resorting to export LD=... or gcc -B hacks ? Thanks. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 5

[opensuse-packaging] autoconf 2.65
by Stephan Kulow 22 Feb '10

22 Feb '10

Hi, We skipped autoconf 2.64 and now 2.65 brings some unpleasant suprises to quite some packages. From what I read the build logs, most fail because of the change explained here: http://www.gnu.org/software/hello/manual/autoconf/Expanded-Before-Required.… So if your package runs autoconf during build, then either stop doing that and rely on the configure script provided or look out for warnings like this: configure.in:32: warning: AC_REQUIRE: `AC_PROG_CC' was expanded before it was required ./../lib/autoconf/c.m4:429: AC_LANG_COMPILER(C) is expanded from... ./../lib/autoconf/lang.m4:316: AC_LANG_COMPILER_REQUIRE is expanded from... ./../lib/autoconf/general.m4:2573: AC_COMPILE_IFELSE is expanded from... ./../lib/autoconf/general.m4:2581: AC_TRY_COMPILE is expanded from... This means autoconf will expand the macro twice and that can generate quite funny errors later in the build. Greetings, Stephan -- 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] Build failures in Factory
by Stephan Kulow 22 Feb '10

22 Feb '10

Hi, With gcc 4.5 and autoconf 2.65 hitting factory right after Milestone 2, we have quite some new build failures and I would welcome if this doesn't stay too long, so please have a look at the factory status and fix what you can (most packages are easy to fix, there is no need to wait for the "maintainer" to step up): https://build.opensuse.org/project/status?project=openSUSE:Factory Greetings, Stephan -- 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] Converting factory devel packages to branch
by Stephan Kulow 19 Feb '10

19 Feb '10

Hi, I plan to mass convert all devel packages to branches if they are fall into one of the following categories: - they are a source link now - they contain the same sources as factory This will happen at the end of the week unless someone convinces me this a bad idea, so I would like to stress why I plan to do so: packages that have no relation to factory sources very easily divert as factory follows different white space indentation rules and it's near to impossible to check if a package has pending changes in the devel project or "just" whitespace differences. Source links break easily if you continue working in the devel project after the submit request - as such many projects prefer not to use source links. But branches do not have this problem, they even leave your white space alone - with branches the source server only touches the _link file and nothing else, so nothing can break your sources. That does not mean, there can't be conflicts in case someone pushes something to O:F that conflicts with your changes (which shouldn't happen in devel projects by policy). Converting the devel projects may break some scripts though as I'm pretty sure some rely on the existance of project.diff to see if there is a difference so my mail to talk about it. So what is a branch? It's a _link without diffs, the _link contains the revision of factory and additionally you have the full sources in the devel project. This means you can't easily find out from your osc checkout if the project made changes. Of course we can extend osc to store the md5 of the link target too, so you can adapt your scripts - but for now there is no such possibility from what I can see. Is that problem enough to outweight the advantages? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

6 11

[opensuse-packaging] Library packaging question
by Dave Plater 18 Feb '10

18 Feb '10

Hi, the next generation of the package I maintain, blender has a new feature called collada which enables 3D import and export similar to cad's dxf file format. In order to enable this feature I've had to incorporate a package called openCOLLADA into blender and the build of the package produces several libraries named :- libbuffer.so libftoa.so libGeneratedSaxParser.so libMathMLSolver.so libOpenCOLLADABaseUtils.so libOpenCOLLADAFramework.so libOpenCOLLADASaxFrameworkLoader.so libOpenCOLLADAStreamWriter.so libUTF.so Which following the "Shared_Library_Packaging_Policy" guidlines, I've added a 0.0.0 suffix with symbolic links containing plain .so and .so.0. I've named the resulting subpackages containing these libraries and the include files,libopenCOLLADA0 and libopenCOLLADA-devel, with the .so links and include files in the devel subpackage. I'm getting several rpmlint warning which would indicate to me that I've done something wrong, "W: no-soname" for each lib and "libopenCOLLADA-devel.x86_64: W: no-dependency-on libopenCOLLADA/libopenCOLLADA-libs/liblibopenCOLLADA", I've included Requires libopenCOLLADA0 = %{version} in the libopenCOLLADA-devel section. What am I doing wrong? One other question, these libs are licenced under the MIT licence, hopefully that isn't a problem? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 36

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

16 Feb '10

Hi, I execute the following build command: $ home:rbos/kfritz> osc build openSUSE_11.2 i586 kfritz.spec The last part of the build fails, with the error attached lib/libfritz++.a(FritzClient.cpp.o): In function `fritz::FritzClient::CalculateLoginResponse(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)': /usr/src/packages/BUILD/kfritz-0.0.1/libfritz++/FritzClient.cpp:73: undefined reference to `MD5' But when I copy the command that fails, chroot into the local build root and execute in the correct directory the build is succesful, and I obtain the executable kfritz. Does anyone know what is happening here? Why does the build fail, but can I execute the exact same command manually succesfully? The line that errors out, contains this code: MD5((unsigned char*)challengePwdConv, challengePwd.length()*2, hash); -- Richard

5 10

[opensuse-packaging] SLE Service Packs and binary compatibility
by Cristian Morales Vega 16 Feb '10

16 Feb '10

Hi, I'm trying to understand what SLE Service Packs exactly are (didn't I already asked this here?) openSUSE:Tools SLE_10 repo builds against SUSE:SLE-10:SP3:SDK. The BS web interface adds SUSE:SLE-10:SDK when "SLES/SLED 10" is added. This makes me ask how this is supposed to work. Is a package built against SLE-10 Service Pack X guaranteed to work in SLE-10 Service Pack Y (Y > X, X E [0..inf])? So should I use the minimum SP that allows the package to build? Thanks. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 4

[opensuse-packaging] Moving devel packages from home:hennevogel:TODO to devel:openSUSE:Factory
by Andreas Jaeger 16 Feb '10

16 Feb '10

I propose to move all packages from home:hennevogel:TODO to devel:openSUSE:Factory. home:hennevogel:TODO was created as collection point for packages where it was not clear where the packages belong to - and devel:openSUSE:Factory was created as a collection point for packages where it's not clear where they belong or where the devel projects do not really make sense (see http://lists.opensuse.org/opensuse-packaging/2009-09/msg00156.html). I've BCC'ed all maintainers of packagers with packages in home:hennevogel:TODO. If you like to move your packages elsewhere or have better suggestions, please speakup. I think it's time to get rid of home:hennevogel:TODO as devel project. Otherwise, I'll move the packages starting on Wednesday, 17th of February, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj(a){novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

4 6

[opensuse-packaging] Switch to GCC 4.5
by Richard Guenther 16 Feb '10

16 Feb '10

Factory will switch to GCC 4.5 for the 11.3 release. As a compiler version change should happen sooner than later I ask you to look at build results for your packages with the new compiler. The staging repository of Factory already builds with the current gcc45 packages, so build results and logs are available via the usual commands. To have an idea if you are currently affected compare the output of > osc prjresults -r staging -a i586 -q -s F openSUSE:Factory with > osc prjresults -r standard -a i586 -q -s F openSUSE:Factory Common new errors include stricter source fortification (you can verify if that is the issue by adding -U_FORTIFY_SOURCE at the end of RPM_OPT_FLAGS). As usual there might be new bugs in a new compiler - before blaming the compiler though check the warnings. Fedora has already gone through dealing with the stricter fortification errors, so it might be worth to check their source rpms before digging too deep. Richard. -- Richard Guenther <rguenther(a)suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 4

Re: [opensuse-packaging] What should own /usr/share/man/zh_CN?
by Cristian Morales Vega 16 Feb '10

16 Feb '10

2010/2/14 Cristian Rodriguez <crrodriguez(a)suse.de>: > Am sáb 13 feb 2010 11:48:17 CET schrieb Cristian Morales Vega > <cmorve69(a)yahoo.es>: > > >> - Make my package own /usr/share/man/zh_CN >> - Fix 04-check-filelist to not complain about /usr/share/man/<lang> >> - Fix the filesystem package >> - Another > > Use %find_lang --with-man I will make it own /usr/share/man/zh_CN. But that's a good point. I *am* using "%find_lang --with-man". It should also add the dir when needed? Why it doesn't search for man pages by default is another thing I don't understand. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0