October 2009 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Why devel projects for openSUSE:Factory?
by Andreas Jaeger 15 Oct '09

15 Oct '09

I've been asked why we have devel projects and why a package should use one. Looking around I found not directly a good answer - and only these two pages: http://en.opensuse.org/Build_Service/Concepts/Upstream_Project http://news.opensuse.org/2009/06/18/opensuse-factory-is-now-open/ Do we have anything better? If not: Anybody interested in writing something up? 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

2 1

[opensuse-packaging] boinc client: shared-lib-calls-exit
by Sascha 'saigkill' Manns 13 Oct '09

13 Oct '09

Hello Mates, i'm packaging boinc client 6.6.40 and i'm getting: boinc-client.x86_64: W: shared-lib-calls-exit /usr/lib64/libboinc_graphics2.so.6.6.40 exit(a)GLIBC_2.2.5 boinc-client.x86_64: W: shared-lib-calls-exit /usr/lib64/libboinc_api.so.6.6.40 exit(a)GLIBC_2.2.5 This library package calls exit() or _exit(), probably in a non-fork() context. Doing so from a library is strongly discouraged - when a library function calls exit(), it prevents the calling program from handling the error, reporting it to the user, closing files properly, and cleaning up any state that the program has. It is preferred for the library to return an actual error code and let the calling program decide how to handle the situation Does anyone knows how to fix it? -- Sincerely yours Sascha Manns openSUSE Member openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://saigkill.wordpress.com ClaimID: http://claimid.com/saigkill -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] cmake and %_libdir
by Cristian Morales Vega 13 Oct '09

13 Oct '09

Trying to package OpenCV 2.0 I found this line in the CMakeLists.txt file: set(CMAKE_LIB_DIRS_CONFIGCMAKE "${CMAKE_INSTALL_PREFIX}/lib") that ends specifying the libraries install dir. It should be fixed... but doesn't seems to be a standard variable in cmake to specify the libdir. The only thing I have found is this thread from 2007 (http://lists.opensuse.org/opensuse-buildservice/2007-08/msg00332.html)... but as pointed by Andreas LIB_SUFFIX isn't an standard variable. Looking at the Fedora %cmake macro (https://fedoraproject.org/wiki/PackagingDrafts/cmake) this doesn't looks any better. So... two years after cmake still hasn't a way to specify the libraries install directory? I can't submit upstream a patch with a non standard variable. I'm supposed to use LIB_SUFFIX and maintain the patch forever? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 2

[opensuse-packaging] Junior Jobs
by Michal Hrusecky 13 Oct '09

13 Oct '09

Hi, lately we formulated concept of openSUSE Junior Jobs[1]. Maintainers of openSUSE packages can choose some of theirs easy bugs and mark them as Junior Jobs. Then anybody from community can volunteer and fix these issues. These tasks will be easily fixable and their purpose is to let people learn how to contribute and to create some easy task so anybody can join and start participating. [1] http://en.opensuse.org/Junior_Jobs -- Michal HRUSECKY SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xFED656F6 19000 Praha 9 mhrusecky[at]suse.cz Czech Republic http://michal.hrusecky.net http://www.suse.cz

1 0

[opensuse-packaging] [python] fixing "no module named" (and packaging modules properly)
by Jan Matejek 08 Oct '09

08 Oct '09

Dear fellow packagers, since our switch to noarch-capable python, a number of bugs for arch-dependent python module packages have popped up, where some module can't be imported even though it seems to be installed properly. Root cause of those bugs is common to all of them: half of the files are installed in platform-independent /usr/lib dir, while the other half goes into /usr/lib64 (on 64bits only, of course), causing all sorts of confusion. That is Bad Style (tm). Don't do it. in short: Fix your package so that it goes either into /usr/lib (in which case it should be noarch too), or into /usr/lib64. The bug will then go away. long version: In Python, the arch-independence is on a per-module level. Either the whole module is arch-independent, then it belongs to %python_sitelib, or some of it is arch-dependent and then the whole module belongs to %python_sitearch. Historically, sitelib and sitearch were in the same directory. Now that they are separate, two classes of problems have arisen. One, many python modules depend on being installed within a single directory. Sometimes explicitly and sometimes they make the assumption in some not-really-trivial way. There is even a feature called "relative imports" that relies on the fact that a whole module is installed in a single directory. Two, sometimes modules are not installed on python search path. Python doesn't search subdirectories automatically, so modules from e.g. %python_sitearch/gtk-2.0 can't be imported, even though modules from %python_sitearch itself can. For that reason, such module often installs a file.pth pointing to its directory. When python finds something.pth on its search path, it appends all directories listed in that file to the search path. Some packages install into two different locations but use only one pth file pointing into only one of them. Why is that a problem is left as an exercise for the reader. Distutils know all this and do the right thing, unless your upstream is extremely clever and installs two separate modules (wxGTK) or beats distutils into submission (egenix-mx-base). Also, prusnak volunteered and checked all packages in d:l:py that don't use --record-rpm, and they are all OK. hope this helps regards m. -- 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] query - opensuse equavilant of elfutils-libelf, elfutils-devel, beecrypt-devel, bzip2-devel, perl-devel
by doiggl＠velocitynet.com.au 08 Oct '09

08 Oct '09

I got an expansion error for a project. nothing provides elfutils-libelf, elfutils-devel, beecrypt-devel, bzip2-devel, perl-devel Question: Is there any equivalent opensuse modules to these ones ? project -> https://build.opensuse.org/package/show?package=rpm5&project=home%3Adoiggl Thanks Glenn -- 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] What is the correct way for a maintainer to submit to factory?
by Dave Plater 08 Oct '09

08 Oct '09

Hi, I'm trying to work out if it was me or something else that caused the devel project tarball to fail to arrive in factory along with all the other files. 1) Should I disable building before making a submit request? 2) Should the link to the factory package disappear when the submit request is accepted? 3) Does the link need to be present for a new submit request? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 2

[opensuse-packaging] Question about KDE >= 4.2. Building in openSUSE 11.1
by Sascha 'saigkill' Manns 07 Oct '09

07 Oct '09

Hello Mates, i have an big Problem (for me) with building skrooge for 11.1. Since the 0.5.x Tags skrooge uses Functions from KDE 4.2. So i have declared the BuildRequires libkde4 >= 4.2. But 11.1 comes without KDE 4.2. So the Build only runs only for Factory. So i have tried to Link the kdelibs4 Package to my home:saigkill Repository But that linked Package don't builds, because osc finds unpackaged Files. But it builds just for Factory. Has anyone an Idea? I'm happy for every Proposal, i have tried all my thoughts. As Attachement i'm adding the Spec. Maybe i have an Error there. -- Sincerely yours Sascha Manns openSUSE Member openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://saigkill.wordpress.com ClaimID: http://claimid.com/saigkill

1 0

[opensuse-packaging] removing gecko-sharp2
by Andrew Jorgensen 07 Oct '09

07 Oct '09

gecko-sharp2 has not been maintained in a long while and, as far as I can tell, is not required by anything that can't be compiled without it. In fact PDB seems to think that nothing requires it except a package called jscall-sharp which is supposed to be a JS-C# bridge. The maintainer of that source says it should be dropped as he's been recommending for years that people adopt the source if they actually need it. What's the process for removing a package? We should do this before 11.2 is released if possible as one of the goals for 11.2 seems to be removing xulrunner 1.9.0 and older and gecko-sharp will not likely work w/ 1.9.1. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] Projekt rename: Subversion related packages now in devel:tools:scm:svn
by Dirk Müller 07 Oct '09

07 Oct '09

Hi, The subversion related packages in the buildservice project "Subversion" are now being maintained in devel:tools:scm:svn. The duplicates in devel:tools:scm will be removed as soon as the develproject changerequests are being approved by the build team. the packages have been removed from Subversion and publishing has been disabled. Please change your repo entries to the new location. The old Subversion project will be completely removed by October 16th. Thanks a lot for your understanding. Greetings, Dirk -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0