openSUSE Packaging August 2009

packaging@lists.opensuse.org

48 participants
45 discussions

Re: [opensuse-packaging] New packages for factory

by Stephan Kulow

Am Montag 10 August 2009 schrieb Andrew Beekhof: > Since you seem to be the contact person then, can you please give me > an update for the two packages I submitted? There are no problems with them. I don't plan to post daily updates for all submitted packages, if there is a problem I'll notify the packager. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 10 months

[opensuse-packaging] python modules as noarch

by Jan Matejek

Fellow python packagers, here's something i've been working on during and post-hackweek, and that is adopting some of Fedora's modifications so that we can build pure python modules as noarch. At the moment, this is enabled in OBS project devel:languages:python:Factory (and the corresponding "bleeding_edge_python" repositories in devel:languages:python) and used successfully in python-setuptools package. I'll be submitting to Factory shortly and i'd love to have this feature in 11.2. But be aware, this might (and will) break things. == Short how-to == is now in Python Packaging guidelines on the wiki: http://en.opensuse.org/Packaging/Python#Noarch_modules Please review your python modules. In many cases, it's enough to put "BuildArch: noarch" into the spec file. (Of course, don't do that now. Once the modified python is accepted into Factory, i'll post another mail.) == Technical details == The modified python now keeps "purelib" at /usr/lib/python2.6, and "platlib" at /usr/lib(64)/python2.6. So this modification is only meaningful on 64bits anyway, 32bits are not affected at all. In addition to this, /usr/lib/python2.6{,/site-packages} is now created and owned by python-base, regardless of platform, and added to python's search path automagically. Platform-dependent search path comes up first, so in case you installed the 32bit and 64bit versions of the same C module, the 64bit version is found and used first. == Troubleshooting / Possible breakage == 32bit side is completely unaffected, all the paths are the same. Platform-dependent modules are not affected too. They still install everything into /usr/lib64 on 64bits. So let's discuss pure python modules on 64bits, shall we? Packages using --record-rpm for keeping filelist should be (and are) working fine with the new python. They will just install into /usr/lib on all platforms. If not changed to noarch, it will make installing 32bit and 64bit versions alongside each other impossible - but on the other hand, you don't need to do it anyway. Packages keeping their own filelists in spec files will break - distutils/setuptools will install into purelib directory, but %py_sitelib macro is pointing into platlib. Such packages need to be changed - either by using --record-rpm, or if that is not possible, using the new macros adopted from Fedora. %python_sitelib points to /usr/lib/python2.6/site-packages %python_sitearch is /usr/lib64/python2.6/site-packages (same thing as %py_sitelib, actually). I'm not aware of any other possible problems besides the file list issue. (apart from the obvious "there's no guarantee that byte-compiled files will stay platform-independent") regards m. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 10 months

[opensuse-packaging] libatlas3

by Sascha 'saigkill' Manns

Project: home:saigkill Package: libatlas3 Hello Mates, maybe anyone can help me. ATM the build are broken, but i couldn't find an Errormessage in the BuildLog. Has anyone an Idea? ----cut--- STAGE 2-1-5: GEMV TUNE make -f Makefile INSTALL_LOG/dMVRES pre=d 2>&1 | ./xatlas_tee INSTALL_LOG/dMVTUNE.LOG gemvN : chose routine 3:ATL_gemvN_1x1_1a.c written by R. Clint Whaley Yunroll=32, Xunroll=1, using 100 percent of L1 Performance = 621.65 ( 8.03 of copy matmul, 26.91 of clock) gemvT : chose routine 105:ATL_gemvT_2x16_1.c written by R. Clint Whaley Yunroll=2, Xunroll=16, using 100 percent of L1 Performance = 569.85 ( 7.36 of copy matmul, 24.67 of clock) STAGE 2-1-6: GER TUNE make -f Makefile INSTALL_LOG/dR1SUMM pre=d 2>&1 | ./xatlas_tee INSTALL_LOG/dR1TUNE.LOG make[1]: *** [build] Error 255 make[1]: Leaving directory `/usr/src/packages/BUILD/ATLAS/x86_64_base' make: *** [build] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.32621 (%build) ---cut--- -- Sincerely yours Sascha Manns openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Project-Blog: http://lizards.opensuse.org/author/saigkill Private-Blog: http://saschasbacktrace.blogspot.com -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 10 months

[opensuse-packaging] RFC: Banning system library paths from .pc files

by Philipp Thomas

https://bugzilla.novell.com/show_bug.cgi?id=529921 shows why encoding system library paths like /usr/lib and /usr/lib64 in pkgconfig files is a very bad idea indeed. I'd propose to add a brp script that checks for -L%{libdir} in .pc files and fails the package if found. That way maintainers of a package that comes with .pc files would be forced to fix their packages. I'd even volunteer to write said brp script. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 10 months

[opensuse-packaging] setuid

by Philippe Makowski

Hi, how can I avoid this : E: permissions-file-setuid-bit (Badness: 10000) I have to put (06550) on a file, these is correct setting for the program -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 10 months

[opensuse-packaging] Question about Preload

by Sascha 'saigkill' Manns

Hello Mates, i try to make Preload Rules for my Program. I've checked http://en.opensuse.org/Preload but it is not clear for me. What is the right Way? * prepare_preload -s -p FreeMedForms * strace FreeMedforms | prepare_preload -s -p or another Way? -- Sincerely yours Sascha Manns openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Project-Blog: http://lizards.opensuse.org/author/saigkill Private-Blog: http://saschasbacktrace.blogspot.com

12 years, 10 months

[opensuse-packaging] Using other repos without rebuilding them

by Hans-Peter Jansen

Hi, given that the build system is "under fire" ATM(*), I'm looking for a way to build - say 11.1 packages, but with Qt from KDE:Qt - without rebuilding Qt. Sure I can link them, but that would rebuild them, and would occupy disk space for all those chunky 111 MB qt archives needlessly. This feature would union the 11.1 and KDE:Qt packages and give the build target a new name. Is anything like this available? Thanks, Pete (*): How many kernels do you build today? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 10 months

[opensuse-packaging] package build in faild state, although rpms build successfully

by Hans-Peter Jansen

Hi, I've build python-qt4 in BS (again), and now I found them in failed state although the build was successful, and rpms are generated. The only issue, rpmlint complains about is: python-qt4-devel-4.5.4-43.1.i586.rpm: directories not owned by a package: - /usr/share/qt4/qsci - /usr/share/qt4/qsci/api - /usr/share/qt4/qsci/api/python Should I %dir those? These directories are usually owned by qscintilla, but I refrained from pulling qscintilla as another build dependency (just for it's existence), should I? Instead, I'm using python-qt4's configure.py switch --qsci-api to always install the api file, not only if qscintilla is found. You can look yourself: home:frispete:branches:KDE:Qt home:frispete:branches:KDE:KDE4:Factory:Desktop Could somebody give me an advise, what's wrong here? Thanks, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 10 months

[opensuse-packaging] New packages for factory

by Stephan Kulow

Hi, I would like to point out something that seems not obvious to everyone: Everyone can maintain packages in factory now There is no limitation anymore on who can maintain packages, _BUT_: - the package has to be submitted and reviewed into an _existant_ devel project - it has to build successfully against factory - the devel project has set a bugowner and maintainer for the package - preferably someone else from the devel project submits it to factory, but this is not a strict requirement - the submitrequest contains a note with informations about the package. Preferably you introduce the package to a mailing list (either topic or opensuse-factory) and point to that introduction in your submitrequest. The information we need are things like this: - who is the bugowner (has to be set in the package)? - how long has it been around? - how well has it been tested? - what is the upstream project? - does it have a track record of security issues? - what is the purpose of having it in the distribution? - what are its users? - what is the license (has to be set in the package)? The main purpose of requiring this informations in the submitrequest is that you think about such things before you write a script that dumps all of freshmeat into factory. I don't want to stop anyone from maintaining a package in our distribution, but I want every package to be maintained, not to be packaged - I hope you understand the difference. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 10 months

[opensuse-packaging] unstripped binary warning

by Tony Jones

Can anyone explain why I'm getting this warning in devel:tools/perf perf.i586: W: unstripped-binary-or-object /usr/bin/perf Log: https://build.opensuse.org/package/live_build_log?arch=i586&package=perf&pr… I'm obeying RPM_OPT_FLAGS for the build so no -g (confirmed with V=1) and debuginfo generation is disabled for this package. Tony -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years, 10 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging August 2009