openSUSE Packaging February 2009

packaging@lists.opensuse.org

43 participants
33 discussions

[opensuse-packaging] Changelogs need changes?

by anicka＠suse.cz

Hello! I would like to discuss here one aspect of our changelog policy. Unlike other distributions, we have an unusual rule for our RPM changelogs (.changes file): when updating to the new version, we must process an upstream changelog and copy the most important things to RPM changelog. I would like to discuss this policy and its problems and benefits. When this policy became effective, I have heard about two reasons for doing it: 1. Maintainer who does the update is aware of the changes in upstream. 2. We have easily accessible information about upstream changes. As for the first plus, yes: Maintainer is really pretty well aware of all the information because he not only reads the changelog, but he also spents a great amount of time copying it, pasting it, trying to shrink it as most as possible, reformatting it and so one. I do not want to speak for other packagers (their stories might follow), but I have spent countless hours tweaking my scripts for automagical processing the changelogs and although it saved me loads of time, it is the only thing I regularly have to fix manually during my otherwise automatical perl module updates. It is boring and IMHO completely useless work that costs us lots of time that we could spend on hacking something useful. As for the second plus, I am not aware that anyone uses this information. AFAIK we have no tool to present it to our users in a neat way. It is even not a part of the package metadata, so if you want to get it, you must get the complete package - and if you got the package, you can equally easily see upstream changelog with the same information, that you could get from the changelog. Sure, you might say that we should use RPM changelogs just for the most important changes to save our users time of searching for them. But a brief look at our packages shows that we are not doing it and usually we even cannot do it - how to pick up the most important changes from 30 minor bugfixes? How to pick them from a loads of new features in a new major version? We can either duplicate the changelog (usually unfeasible) or randomly pick up some news (this is my most usual choice) to make our policy happy. In fact, when you are interested in upstream changes, in almost every case it is more useful to take a look to upstream changelog because it is complete and better structured. When you are interested in specfile changes instead, you cannot just read them, you have to skip tons of useless information from upstream changelog - in fact, even when there is no upstream changelog, it would be better to maintain some as a patch than to pollute RPM changelog with a noise. I think that we spent countless hours of time working on something that no one is interested in. Even its very presence might be annoying in some cases. Should we really continue doing it? Would not be better to just go back several years and start to do it like others do it? Reference: http://en.opensuse.org/SUSE_Package_Conventions/Changelogs#11.4_Sourcecode_… Anicka -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 11 months

[opensuse-packaging] Please do not bypass the devel projects

by Vincent Untz

Hi, We just got 7 packages in GNOME:Factory that broke because the project.diff files don't apply anymore: the packages were all updated in Factory. It's not the first time it happens, and I'm sure each time it happens, the person doesn't think it will break anything. But sometimes it does :/ Don't get me wrong: I'm really happy to see people contributing to the packages the GNOME team maintains, and especially when it comes to cleaning up things -- it makes the world a better place. But it'd be really nice to submit all updates to GNOME:Factory first. I think Mozilla:Factory was hit by this issue in the past too, and I'd guess other projects too. So, please, think about the pain that people feel when they have to handle those manual merges, and use the devel projects. Thanks, 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

11 years, 11 months

[opensuse-packaging] openSUSE vs Fedora packaging documentation

by Michal Vyskocil

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

11 years, 12 months

[opensuse-packaging] translation-update-upstream: new package and feature

by Stanislav Brabec

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

11 years, 12 months

[opensuse-packaging] rpm macro to find the standard package doc

by Vincent Untz

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

11 years, 12 months

[opensuse-packaging] Inkscape and WPG files

by Fridrich Strba

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Just an advice for whoever is packaging inkscape. It should be possible in the spec file just to make BuildRequires: libwpg-devel and inkscape could have a capacity to open WPG (WordPerfect Graphics) file-format. Libwpg will not be such a huge dependency since it basically does not depend on anything but libstdc++ on runtime and OpenOffice.org already uses it, so it is surely installed on ~90% of our installations. Cheers Fridrich (BTW, also libwpg upstream maintainer :) ) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkmmuyUACgkQu9a1imXPdA+P9QCeLfCFFfbH/OfvLRm6xAHF7bQo q94AoILBBFgia2b6GrDalLlyOv4+gEBS =RQ4F -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 12 months

[opensuse-packaging] So files in devel Packages?

by Sascha 'saigkill' Manns

Hello Mates, actually im working on the Packes libatlas3 and kde4-skrooge (Project: home:saigkill). RPMLint says: libatlas3.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib64/libatlas.so libatlas3.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib64/libcblas.so libatlas3.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib64/libf77blas.so This i don't understand. I thought, that only *.h Files included in - devel Package. And here RPMLint would like to move the so's to devel. Anyone understand this? -- 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

12 years

[opensuse-packaging] Packaging issue / question for libproxy in Factory

by Dominique Leuenberger

Hi everybody... I guess -packaging might be the best list to ask for this. Situation: We have libproxy in factory. libsoup depends on it. libproxy is enhanced with several plugins, which are installed by using 'Supplemnts:packageand() tags. (package openSUSE:Factory/libproxy) Everything works fine (so far)... now the tricky part: libsoup exists as libsoup-32bit package (for compatibility). It requires libproxy, thus it was created as baselib -> libproxy0-32bit Not the real problem: how to get all the plugins also installed together with libprox0-32bit? And how to have their Supplements: tag correctly updated? Example: libproxy0-gnome has Supplements: packageand:libproxy0:gconf2) which results that libproxy0-gnome-32bit should get supplements: packageand(libproxy0-32bit:gconf2-32bit) Any tricks on how to achieve this ? Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years

[opensuse-packaging] Confusion with spec file

by Andrew Wafaa

Aloha all, I have been having issues for quite some time now trying to package my beloved bongo on >=11.0. It goes fine on 10.3 but on anything newer I get: + exit 0 ... checking for files with abuild user/group ... running 00-check-install-rpms ... installing all built rpms Preparing packages for installation... bongo-snapshot-debuginfo-0.4.0svn1009-1.1 bongo-snapshot-debugsource-0.4.0svn1009-1.1 libbongo-snapshot-import-0.4.0svn1009-1.1 bongo-snapshot-data-0.4.0svn1009-1.1 libbongo-snapshot-0.4.0svn1009-1.1 python-bongo-snapshot-0.4.0svn1009-1.1 libbongo-snapshot-dev-0.4.0svn1009-1.1 bongo-snapshot-0.4.0svn1009-1.1 chown: invalid user: `bongo' bongo-snapshot-mta-0.4.0svn1009-1.1 bongo-snapshot-web-0.4.0svn1009-1.1 ... running 01-check-debuginfo ... testing for empty debuginfo packages ... running 02-check-gcc-output ... testing for serious compiler warnings (using /usr/lib/build/checks-data/check_gcc_output) (using //.build.log) E: bongo-snapshot 64bit-portability-issue src/libs/cal/bongo-cal-object.c:262 E: bongo-snapshot 64bit-portability-issue src/libs/cal/bongo-import-tz.c:41 E: bongo-snapshot 64bit-portability-issue src/libs/msgapi/msgcollector.c:435 My spec file has: %pre #Add the bongo user & group /usr/sbin/groupadd -r bongo 2> /dev/null || : /usr/sbin/useradd -r -g bongo -s /bin/false -c "Bongo Mail daemon" -d /etc/bongo bongo 2> /dev/null || : %post #Ensure that the data directory has the correct ownership permissions chown -R bongo /var/bongo %fillup_only bongo %preun %{stop_on_removal} bongo %postun %{insserv_cleanup} Is this correct? Many thanks for your help. Andy -- Andrew Wafaa, openSUSE Member: FunkyPenguin. openSUSE: Get It, Discover It, Create It at http://www.opensuse.org awafaa(a)opensuse.org | http://www.wafaa.eu -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

12 years

[opensuse-packaging] kde4-skrooge

by Sascha 'saigkill' Manns

Package: kde4-skrooge Project: home:saigkill Hello Mates, the last build was suceeded, but now i'm see an expansions Error. Has anyone an idea, how to fix it? -- 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

12 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging February 2009