February 2016 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Changelog for subpackage
by Karl Ove Hufthammer 14 Feb '16

14 Feb '16

I have a .spec file for a package and subpackage, and wish to have a separate changelog for each. The following *used to* work (a few years ago): %changelog * … changelog for main package … %changelog subpackage_name * … changelog for subpackage … But now OBS doesn’t like this, and gives me this error message: error: line 152: second %changelog How can I fix this? Here’s the .spec file: https://build.opensuse.org/package/view_file/home:huftis:ordbanken/ordbanke… -- Karl Ove Hufthammer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Creating Maintenance Request for non included software [Leap]
by Bruno Friedmann 12 Feb '16

12 Feb '16

[short summary] During the creation of Leap, I've tried to sr postgresql94-plr to Leap. It was refused, at that time postgresql94 wasn't yet properly submitted to factory, casue 94 version was directly coming from SLE. postgresql93-plr was submitted to Leap and accepted. Now dust has settle. Actually here the situation : On Leap you can choose between postgresql 9.3 and 9.4 version. Unfortunately for user of 9.4 they can benefit the postgresql94-plr due to the refused sr. I would like to create a Maintenance ticket to push postgresql94-plr to Leap. It's a non sense to tell users to broke their system by using the -devel projet. I know how to do that for existing package, but for a non existing one. Someone has an example of how to do this ? Thanks. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 4

[opensuse-packaging] OBS Users - kindly verify your credentials!
by Axel Braun 10 Feb '16

10 Feb '16

Ladies & Gents, if you have a role (maintainer, bug owner, etc) in OBS, please be so kind and verify your contact details (EMail) is working. Every now and then you get bounces because the address is not working, currently it is <someuser>@fsf.hu no valid MX hosts found (tried already to contact the domain owner....) Thanks Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] Making more packages relocatable?
by SF Markus Elfring 09 Feb '16

09 Feb '16

Hello, The documention "Maximum RPM: Taking the Red Hat Package Manager to the Limit" contains a description like the following. http://rpm.org/max-rpm/ch-rpm-reloc.html "… Chapter 15. Making a Relocatable Package RPM has the ability to give users some latitude in deciding where packages are to be installed on their systems. …" I would like to use this functionality more often. Example: elfring@Sonne:~> rpm --install --prefix ~/Probe http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_Factory/x86_64… error: package Mesa-libGL1 is not relocatable Would any more software builders like to design their packages in a way so that they give various users such an installation freedom by the usual package management interfaces? https://forums.opensuse.org/showthread.php/513334-Installation-into-an-alte… Regards, Markus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 5

[opensuse-packaging] why there are so few packages in Factory, revisited
by Michal Kubecek 05 Feb '16

05 Feb '16

Hello, you might remember recent discussion in opensuse-factory mailing list on this topic. While the statistics that started it were inherently flawed, there seemed to be a consensus that Factory doesn't have as many packages as it could and that there are many packages in devel projects or home projects that are never submitted to Factory. I considered sending my opinion why but I was afraid it might start a flame without any positive outcome. Recent experience conviced me to try anyway. Disclaimer: the sole purpose of this e-mail is to present my view on the problem and to give responsible people something to think about. It is definitely not meant as a complaint about the particular case (which serves only as an example) or some kind of pointing fingers. Short version: I believe main reason why too many packages never move from home or devel projects to Factory is that on one hand, OBS made it extremely easy to build a package for a set of distributions and even add your own repository with such packages; on the other hand, once you decide to get the Factory, you have to tackle constantly increasing amount of "bureaucracy" to even get the package in and then face a stream of pointless changes in the name of some high standards which are apparently constantly changing and actually not even universally accepted at any given moment. There is a popular phrase about "scratching an itch". The problem, as I see it, is that to scratch one's itch, home project is sufficient. If you are an altruist, you might even push the package into a devel project so that it stands out in the search. But getting it into Factory, that's no more about scratching your itch; you must have really strong motivation for that - and even stronger to do it again once you know what you are going to face. Let's look at an example. Few years ago, I discovered tcpreplay, a set of network utilities which are quite handy when investigating networking issues. I created a package, did my best to avoid OBS warnings and put it into a project under my home so that I could easily install it on my machines. That scratched my itch. Later some guy created a submit request for network:utilities; I checked the package, updated it to new versions, did some cleanup and package ended up in network:utilities. After the December discussion, I decided to submit the tcpreplay to Factory. I checked the build, polished the specfile a bit and submitted it. The request was declined by a check script because a copyright was missing. OK, fair enough, while I don't consider that particular specfile such a great piece of art to need a copyright, why not. I ran the specfile through the spec cleaner service (which often happens automatically with "osc build" but for some reason this wasn't the case). It did some rearrangement and style changes; some I didn't quite like but nothing crucial, so I resubmitted the package. With that submit request still waiting in staging repo, on Sunday I got a request against network:utilities. I didn't have time to review it so I left it to the morning. Before I could do so, 5 hours after creation of the request, to my surprise, it was accepted by the guy who originally poked me to submit the package to network:utilities (but never contributed to the package in any way since). I checked the changes anyway (after all, I'm bugowner so I feel responsible for the package) and I really don't know what to think: https://build.opensuse.org/package/rdiff/network:utilities/tcpreplay?linkre… - replace xz compressed tarball by the original gzipped one For years I've been told by OBS that I should repack gzipped tarballs to save resources. It's not true any more? OK, it allows for checking the signature so it makes sense. - make BuildRoot specification unconditional For years I've been told that it is obsolete. The only reason I keep it is to allow build for SLE11. Why forcing it on distributions that don't need it? - replace source files by full URL I don't like this change. More precisely: I hate it. - add "-q" to %setup Why? No idea. - add "V=1" to make Why? To make build warnings harder to see? - break configure line into two If it needed breaking, I would do so. This one had 32 characters... Seriously? - replace ${RPM_BUILD_ROOT} with %{buildroot} The only rule I have ever seen about this was there is no rule. - add %{?_smp_mflags} also to make install Well, why not. But definitely not _after_ the argument. - add LICENSE to the package OK, why not. - %files: expand wildcards to explicit lists Some people apparently prefer package build to fail whenever a file is added or renamed. I don't force them not to do so in their packages, could they respect my preferences in mine? Apparently not. - reorder tags in specfile header I'm confused. The previous order was what spec cleaner did. Wasn't it supposed to be The Right Order(TM)? And what happens next time spec cleaner service is run? Is it going to change the order back, masking real changes? Summary: lot of meaningless churn, one useful change, two I dislike and two (or two and a half) I really dislike. And a bad feeling that while I took responsibility for the package, I apparently have no say in what should its specfile look like. Don't understand me wrong: I have no problem with reasonable rules, even if they are quite strict (like the tagging policy in our kernel packages or strict coding style policy in kernel networking). But here I feel this crosses a line of harassment. OK, I'll learn to live with it. I'll bite the bullet with packages like firebird or twinkle which are kind of "heart thing". But next time I stumble upon a package that might be useful, I'll think twice before submitting it to Factory. Had I known what was going to happen, well, there would be one less package in Factory (assuming tcpreplay is going to make it). And just today, I got a reaction like "Been there. I know exactly what you are talking about." Sure, you may say that it's my fault I don't understand openSUSE high standards. You might even say openSUSE is not interested in packagers who don't understand its high standards. But you should understand in the end it's always packager's choice if he is going to submit the package to Factory or not. And remember, to "scratch an itch", putting it into a home project is enough in most cases; submitting to Factory is not about "scratching an itch", it's about helping others; things like this work as an active discouragement. Think about it next time you ask yourself why so many packages stay in home or devel project without ever being submitted to Factory. Or, even better, think about it next time you feel urge to completely rearrange a package you are not maintaining (and not going to) just to force your aesthetic criteria on it (and its maintainer). Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

20 50

[opensuse-packaging] Need help with hugin update
by Dave Plater 05 Feb '16

05 Feb '16

Hi I'm trying to make a provides script for Leap:42.1 hugin and although it works in home:plater hugin in : https://build.opensuse.org/package/show/home:plater:branches:openSUSE:Leap:… gives an error : [ 2196s] Finding Provides: /home/abuild/rpmbuild/SOURCES/find-hugin-provides.prov [ 2196s] error: Dependency tokens must begin with alpha-numeric, '_' or '/': ()(64bit) [ 2196s] ()(64bit) [ 2196s] ()(64bit) [ 2196s] ()(64bit) [ 2196s] ()(64bit) [ 2196s] ()(64bit) [ 2196s] ()(64bit) [ 2196s] ()(64bit) [ 2196s] [ 2196s] error: Failed to find Provides: for each of the packages libraries with sonames. If I leave out find-hugin-provides.prov then the libraries are provided normally but no appdata.xml and desktop files are provided resulting in a zypper and yast verify error. Any help appreciated, Dave Plater -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 6

[opensuse-packaging]
by Zbigniew Reszela 02 Feb '16

02 Feb '16

Hello, In my institute we are selecting the operating system and Leap 42.1 is a strong candidate. In the selection process we are deeply analyzing the packaging and package management aspects. Currently we use openSUSE 11.1 and some custom GUI packaging and installation tools based on RPM. With the new OS we would like to follow the packaging good practices of the distribution. We have already tried building packages for the python projects, using the python setup.py bdist_rpm (based on distutils), but we also wanted to give a try to the "openSUSE:Packaging guidelines [1]. We mostly use Python and C++ projects, hosted on sourceforge/github or our local repositories. We do want to implement Continuous Delivery, so automatic packaging and deployment to the testing environment is crucial for us. Initially we do not foresee to publish our packages to the distribution, but maybe in the future we would like to do that for some of our projects. In your portal we have found several recommendation to use the OBS [2]. But our understanding is that OBS is just for the packages aimed to be public. We have not found information on how to build locally packages apart of a link to the Fedora How to create RPM packages [3]. There is also a possibility to setup our private OBS system, but maybe it is too complicated solution for what we need right now. Could you provide us a guide on how to do packaging in the most compatible with the openSUSE standards way. Thanks a lot for your help! Zibi [1] https://en.opensuse.org/openSUSE:Packaging_guidelines [2] https://en.opensuse.org/Portal:Build_Service/Documentation [3] http://fedoraproject.org/wiki/How_to_create_an_RPM_package -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

9 13

Re: [opensuse-packaging] Re: [opensuse-factory] why there are so few packages in Factory, revisited
by Michael Ströder 02 Feb '16

02 Feb '16

İsmail Dönmez wrote: > On 02 Feb 09:59, Jan Engelhardt wrote: >> >> On Tuesday 2016-02-02 08:25, Michael Ströder wrote: >>> Jan Engelhardt wrote: >>>> Sometimes I really have to cringe at some specfiles and wonder how >>>> they got through the opensuse factory review team. I do not want to >>>> say openSUSE is the sloppiest distros of all, but claiming openSUSE >>>> has too high a specfile standard is just untrue. >>> >>> Personally two things annoying me: >>> >>> 1. Some reviewers insist on adding a lot of lines to .changes files claiming >>> that there are common practices to do so. [...] for all upstream changes to >>> fit into .changes when simply updating to a new upstream release. >> >> That is utterly nonsensical to do. Call those maintainers out. >> 1. The package maintainer may not have as much understanding what >> each upstream changelog entry is supposed to mean >> 2. The reader of rpm -q --changelog may have even lesser understanding >> than that >> 3. Avoid redundant information. >> >> Especially point #3 mandates that the full changelog with >> technobabble should, if so desired, provided via %files, and the rpm-changelog >> be short and concise. Like freshcode.club messages. Because #2. > > Just to add my point here. We don't want the ChangeLog, nor output of the git > log, svn log whatever. We want the useful stuff which is mostly included in the > NEWS file and/or the release announcement. Sorry, given the wide range of variants in upstream release this advice is very blurry. Ciao, Michael.

1 0

Re: [opensuse-packaging] Re: [opensuse-factory] why there are so few packages in Factory, revisited
by Martin Pluskal 02 Feb '16

02 Feb '16

On úterý 2. února 2016 8:35:56 CET Marcus Meissner wrote: > On Tue, Feb 02, 2016 at 12:49:46AM +0100, Dominique Leuenberger / DimStar wrote: > > Michal, et.al. > > > > > - add "V=1" to make > > > Why? To make build warnings harder to see? > > > > A constant battle - I know that one. I myself consider V=1 great for > > debug perpose... as long as gcc's warnings are there if it's not > > specified, I don't enable it. > > Actually we are parsing the gcc commandline to spot if you are using > optflags and do some post build checks. (post-build-checks, check_gcc) Indeed there are actually several cases when lack of of usage of optflags was not observed due to silent build, such as in ninja, thin-provisioning tools and himeno - and those are just few cases which I noticed in last few days. > > > > - add %{?_smp_mflags} also to make install > > > Well, why not. But definitely not _after_ the argument. > > > > Parallel installation - how big is that package :) I doubt it makes > > much difference (but then: the latest version of spec-cleaner does this > > automatically IIRC - so the submitter might not have done this > > explicitly) > > I fixed several packages that build fine with -j2 but did not with -j8, > which was annoying. so this actually has the cause to break things, but > it is rare. > > Ciao, Marcus

2 1