March 2009 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] osc 0.114
by Peter Poeml 05 Mar '09

05 Mar '09

I have updated the osc package; it's now at version 0.114. Get it from openSUSE:Tools, as usual. While updating the NEWS file, I realized how many people have been working on this, and was amazed how much has happened. I'm sure there's a lot that you'll appreciate as well: 0.114: - the .oscrc config handling has been cleaned up: * use "apiurl" for everything now (== <protocol>://<host>) * added aliases support for [apiurl] sections in the ~/.oscrc. Example: [http(s)://foobar] ... aliases = foo, bar => "osc -A foo <cmd>" will do the same as "osc -A http(s)://foobar ls" * "scheme" and "apisrv" are deprecated and will produce a warning * when writing a new ~/.oscrc, store the apiurl in the conffile (bnc#478054) * fixed bug that made osc ask for credentials when -A was used (bnc#478054) * fixed crash upon password entry (first startup) (bnc#478052) - osc build: * make product builds work * speed up by using a cookie when fetching the binaries (bnc#477690) * support for VM (kvm or xen) builds * obsolete the need to configure download server, get it from the build service instance instead. * be a bit more verbose if the linked package isn't expanded (bnc#470948) - osc branch: * --develproject option fixed (the API calls it 'ignoredevel' instead of 'nodevelproject') * --revision option added - osc jobhistory: new command to see build job history of a project or a package - osc results/rresults: option -l, --last-build added (show last build results) - osc linkpac: fix failure when -A<url> is used (bnc#479156) - osc commit: don't scare users if they want to commit a nonexistent file (bnc#469167) - osc diff: bugfix to make --pretty option work - 11.1 added to the osc project template Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

1 0

[opensuse-packaging] bash 4.0
by Stephan Kulow 05 Mar '09

05 Mar '09

Hi, I'm seeing quite some packages that fail due to bash being updated to 4.0. If you see some new failure that's not to explain, please file a bug report, the bash is still pretty young ;( 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] RFC: openSUSE:Dropped project
by Lars Vogdt 05 Mar '09

05 Mar '09

Hi there Following the "Package foo needs new maintainer" resp. "Drop request for package foo" mails on opensuse-packaging for a while. Community members already asked for more details when a package is dropped from Factory. So what about creating an "openSUSE:Dropped" project, where people can find the latest source of a dropped package - and at least can get an overview about currently dropped packages? Means: 1) Packager sends drop request internally 2) Project manager agrees => drop package ^^^^^ Same as before. 3) the latest checked in package source (regardless if successful building or not) is copied into the project openSUSE:Dropped ^^^^^ New - formerly we just moved the source to an internal backup space and marked it as deleted in PDB. ---- 4) People can always see, which formerly packages are removed from the current Factory (and therefore will not be in the next release) looking at the openSUSE:Dropped repository 5) Interested community packagers can use/copy the latest source from openSUSE:Dropped Open questions: 1) Is this idea worth to be implemented? 2) What about packages with security problems? - Publishing should be disabled for all packages in the openSUSE:Dropped repo. But is this enough? 3) What to do with undropped packages? * If a package is maintained by community - regardless of the project -, should it be removed from openSUSE:Dropped? * Should it be removed ONLY if the package is in openSUSE:Contrib? Best solution for 2 (in my eyes) could be: Community packager wants to maintain a dropped package => he builds it in his home-Project => he sends a request to the openSUSE:Contrib project => openSUSE:Contrib maintainers are also maintainers of openSUSE:Dropped and can remove the package from openSUSE:Dropped as soon as it is accepted for openSUSE:Contrib With kind regards, Lars -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 4

[opensuse-packaging] kde4-skrooge
by Sascha 'saigkill' Manns 04 Mar '09

04 Mar '09

Hello Mates, i've just updated my Skrooge Package. I've written in the Spec: Requires: kde4-skrooge-lang = %{version}-%{release} But RPMLint says: kde4-skrooge.x86_64: E: percent-in-dependency (Badness: 10000) kde4- skrooge-lang %{version}-%{release} This rpm has a dependency whose version part contains the '%' character. It could be an unexpanded macro, please double check. And the other i not understand is: kde4-skrooge-devel.x86_64: W: no-dependency-on kde4-skrooge*/kde4- skrooge-libs/libkde4-skrooge That i don't understand. I have no libkde4-skrooge File in -devel... --- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill DISCLAIMER: Please note that in accordance with the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. http://www.vorratsdatenspeicherung.de http://www.ccc.de -- 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] openSUSE vs Fedora packaging documentation
by Michal Vyskocil 03 Mar '09

03 Mar '09

Hi, I compared a Fedora Packaging Guidelines [1] and SUSE Packaging Convetions [2] and I think that Fedora documentation is really better than we provide. It's not only about amount of information, but mainly in structure of it. For example if we want to read about License policy in SUSE and start on Packaging page [3] - how can user get from this page to equivalent of Licensing guidelines [4]? Fedora way is Packaging -> Packaging/Guidelines -> Packaging/LicensingGuidelines Or another example - is really necessary talk about BuildService account on packaging cookbooks of KDE[5] or Java[6]? In fact with this structure, where they exists outside Packaging/ it makes a sense, but it's really necessary? If we want to help a community to participate on openSUSE (for example packaging in Contrib) we also need a better documentation than we have. So main questions are: - how could be Packaging/ maintained (eg. we would have a Docbook original somewhere and convert it to wiki as SUSE packaging conventions [2])? - how could we structure existing information to be more readable and useful for community? - what is missing, or unclear and needs to be improved? (- and who will do this all ;-)) [1] http://fedoraproject.org/wiki/Packaging:Guidelines [2] http://en.opensuse.org/Packaging/SUSE_Package_Conventions [3] http://en.opensuse.org/Packaging/ [4] https://fedoraproject.org/wiki/Packaging/LicensingGuidelines [5] http://en.opensuse.org/KDE/Packaging/Cookbook [6] http://en.opensuse.org/Java/Packaging/Cookbook Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

15 41

[opensuse-packaging] translation-update-upstream: new package and feature
by Stanislav Brabec 03 Mar '09

03 Mar '09

When we freeze our package versions, new upstream translations are not updated any more. Some of our products have a long life cycle. It would be nice to get translations updated from upstream with a minimal effort. It's the purpose of translation-update-upstream: new package and tool. It's now in Factory and first 94 packages are waiting for submit review. FAQ === Q: How it works? A: It features an updater: a simple tool to update the translation during initial phase of compilation, and the translation collection tool, which collects new or changed strings from one or more upstream resources (versions, branches) using the configuration file (it's called manually outside Build Service and the result is submitted). Q: How you can add its support? A: Edit your spec file: Simply add translation-update-upstream to BuildRequires and call translation-update-upstream as a first action of build after %setup. Then you need to configure translation-update-upstream to point to the correct upstream resources. For more see the translation-update-upstream package HOWTO and the source package. Q: Why is this needed? Don't we get translations in upstream tarballs already? A: Our packages freeze few months before openSUSE release and then they are maintained for years in SLE. Providing a way to backport translations into frozen versions is very welcome. Q: Why a new package? Isn't translation-update sufficient? A: It is sufficient for translations provided in-house. In case of upstream translations, our translators have no control over the translation. We need a way to override upstream mistakes or errors. But translation-update package overrides everything already done forcing back the upstream version. Q: Why to do in compile time? A: It is possible to do the same in using the translation override directory. But it has few disadvantages: - It would introduce strict packaging policy: - No translation fixes in spec files would be possible. - All translation fixes would be done via translation override package. - Increases installations size. We do this only for translations provided in-house. Q: Shouldn't it be better to push translations and fixes upstream? A: In general, yes. But most upstream maintainers care just about the latest stable branch. Who will care about GNOME 2.12 translation in upstream five years from now on? Q: Why not use bundle-lang package? A: You don't know source of each particular string in the bundle-lang. It may come from upstream, from a fix, from a patch. Only upstream one may be replaced by the update tool. In fact, translation-update-upstream works well with bundle-lang package. translations from the build process may get into the bundle-lang package, if the current processes defines so. Q: Does it replace po tarballs in spec files? A: Only those that come from upstream. But it may be technically possible to define Novell LCN as an additional data source. Q: Does it provide 100% translation? A: No, it does not. Only strings that were present and translated in any of newer upstream versions can be provided. Making them 100% complete still may require translators' action. Q: Why we need to pollute openSUSE, if this feature is interesting only for SLE? A: Such large change cannot be done in late beta or rc phase. It must be ready as soon as possible, only translation data file updates will have to be done in the rc phase. Q: What translation files do we have? A: We have: - translations from upstream (in tarball) - translations of strings in patches (e. g. in gnome-patch-translation) - fixes for upstream translations (provided by our testers or Novell LCN team and added in patches or additional tarballs) Now we will have also: - backported upstream translations Q: Isn't it best to modify OBS to support this? A: No: - The tool has to have access to network. - String collecting may require manual intervence in case of upstream errors. Q: Wouldn't it be better to modify %setup? A: No: - It would bring additional "magical" divergence from upstream. - Things may need tuning (e. g. for non-standard po directories) Q: Why not just pick upstream translations and put them in tarball? A: It needs to be handled manually per package. translation-update-upstream is a more sophisticated tool: It searches in all equal or later branches in the upstream SVN and merges everything usable in the old version automatically, once it is set up. Q: Do I need to call autoreconf? A: No, you don't. translation-update-upstream patches configure as well. Q: Does it run during each build? A: Only fast string merge runs during each build. It It uses pre-built tarball in translation-update-upstream and leaves following traces in the build log: Updating or.po using translation-update-upstream. Upstream string collect and compare needs several hours. It is started manually outside Build Service time after time. Q: It would perhaps add something extra to OBS, preferable onyl for SLE, but if I build the package locally with rpmbuild it wouldn't affect anything. A: No. Both use the same rpmbuild. Anything in macros affects all packages. It's cleaner to behave consistently, even at cost of one additional line. Q: It fails. What to do now? A: You can see following failures: can't open ./../foo: No such file or directory at /usr/bin/intltool-extract line 212. xgettext: error while opening "../foo" for reading: No such file or directory Most of them are upstream bugs: They forgot to package some files from their repositories resp. they based their translation on an auto-generated file. It can be considered as a bug, which can be fixed by adding a proper file to the tarball, dropping from POTFILES.in resp. using a proper source file. Upstream should be able to find such bugs by "make distcheck". Q: What is the relation to gnome-patch-translation. A: gnome-patch-translation provides patches from SuSE specific stuff in patches. translation-update-upstream provides translation for upstream things. You can use both tools in a single package. Just call translation-update-upstream first, then gnome-patch-translation-prepare. Transition info: If the submit conflicts with your work, feel free to disapprove it and do it on your own or let me know. The project.diff is really simple. References (restricted access): Feature #301344: Wants a better way to update translations bnc#377971: describes that translation-update packages are always overwriting original translations. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 16

[opensuse-packaging] freeremoted breaks by 90%
by Sascha 'saigkill' Manns 03 Mar '09

03 Mar '09

Hello Mates, since building freeremoted, the build is broken. It says: [ 90%] Building CXX object module/lirc/CMakeFiles/freeremote- lirc.dir/lirccontrolleriface.cpp.o cd /usr/src/packages/BUILD/freeremoted-0.1.4p/module/lirc && /usr/bin/c++ -Dfreeremote_lirc_EXPORTS -fmessage-length=0 -O2 -Wall - D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous- unwind-tables -Wall -O2 -fPIC - I/usr/src/packages/BUILD/freeremoted-0.1.4p/server - I/usr/src/packages/BUILD/freeremoted-0.1.4p/iolib - I/usr/include/dbus++-0.6 -I/usr/include/dbus-1.0 - I/usr/lib64/dbus-1.0/include -o CMakeFiles/freeremote- lirc.dir/lirccontrolleriface.cpp.o -c /usr/src/packages/BUILD/freeremoted-0.1.4p/module/lirc/lirccontrolleriface.cpp Linking CXX shared module libfreeremote-lirc.so cd /usr/src/packages/BUILD/freeremoted-0.1.4p/module/lirc && /usr/bin/cmake -E cmake_link_script CMakeFiles/freeremote- lirc.dir/link.txt --verbose=1 /usr/bin/c++ -fPIC -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 - fstack-protector -funwind-tables -fasynchronous-unwind-tables -Wall -O2 -Wl,-Bsymbolic-functions -shared -Wl,-soname,libfreeremote-lirc.so -o libfreeremote-lirc.so CMakeFiles/freeremote- lirc.dir/lirccontroller.cpp.o CMakeFiles/freeremote- lirc.dir/lirccontrolleriface.cpp.o ../../iolib/libio.a /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse- linux/bin/ld: ../../iolib/libio.a(iodevice.cpp.o): relocation R_X86_64_32S against `vtable for iolib::IODevice' can not be used when making a shared object; recompile with -fPIC .../../iolib/libio.a: could not read symbols: Bad value collect2: ld returned 1 exit status What doe's it mean? -- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill DISCLAIMER: Please note that in accordance with the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. http://www.vorratsdatenspeicherung.de http://www.ccc.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 4

[opensuse-packaging] freeremoted: mussing dbus++
by Sascha 'saigkill' Manns 02 Mar '09

02 Mar '09

Project: home:saigkill Package: freeremoted Hello List, i'm building freeremoted and have an interesting Error. I've builded an Package called libdbus++, and i have included in the freeremoted.spec the libdbus++. For x86 it builds correctly. But for x86_64 the following comes: Could NOT find DBUSPP (missing: DBUS1_CONF_INCLUDE_DIR) Later in the Process comes more Errors based on this (dbuspp was not declared on the Scope). This means, that my libdbus++ are not correct builded? -- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/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] rpm macro to find the standard package doc
by Vincent Untz 01 Mar '09

01 Mar '09

Hey, I was wondering... Right now, we do something like: %doc README AUTHORS ChangeLog NEWS in all packages. However, we certainly forget about some of those files and we also include empty files there (by accident). Would a macro that helps with this be a good idea? It could work like this: + in %install %find_package_doc cat %{name}.package_doc >> %{name}.lst + and then %files: %files -f %{name}.lst %find_package_doc would look for the common files (README, AUTHORS, MAINTAINERS, ChangeLog, NEWS, COPYING, COPYING.LIB, TODO, etc.) by checking their existence and checking they're not empty. And it would output what it finds in %{name}.package_doc. It could take additional arguments if people want to check for additional filenames or ignore some specific files. Opinion? Vincent -- Les gens heureux ne sont pas pressés. -- 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] freeremoted: no job control
by Sascha 'saigkill' Manns 01 Mar '09

01 Mar '09

Project:: home:saigkill Package: freeremoted Hello Mates, i've get the following Error since build the Package: + rm -rf /var/tmp/freeremoted-0.1.4-build + %doc AUTHORS ChangeLog COPYING README /var/tmp/rpm-tmp.83553: line 24: fg: no job control error: Bad exit status from /var/tmp/rpm-tmp.83553 (%clean) And the breaks. Does anyone know what the error is? -- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 2