November 2013 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] krb5 dependency in Base:System
by Stephan Kulow 12 Mar '14

12 Mar '14

Hi, It's currently impossible to submit packages from Base:System due to repo-checker blocking submissions as base packages suddenly require krb5. This is due to a change in libtirpc, that creates a huge cycle. As I'm protecting Factory from having that cycle too, I block such updates. Unfortunately the check hits other packages in the cycle too, so this means: unless this change is reverted, it won't be possible to submit base packages. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

14 48

[opensuse-packaging] Proper version scheme for packages from git, hg, svn, ...
by Sascha Peilicke 24 Jan '14

24 Jan '14

Hi guys, I'd like to gather some input on versioning schemes used for packaging SCM snapshots. Why do we care at all? Ignoring the source pkg and the changes file for the moment, the package version is meant to tell the user exactly which state of the software was provided to him. When you package an upstream tarball, you implicitly provide information about what was released and when. And the package build is reproducable, it won't change how often you download the tarball referenced in Source:. Thus it's enough to just have sth. like this in your spec file: Version: 1.2.3 So if you have to package a (random) SCM snapshot, you want to make sure that it's obvious which commit you picked, so that others can confirm and eventually repeat the build. Here's a small list of flavors that I've come across or used myself. Please not that I replaced the stable (upstream) version with X, since that's not the part I'm interested here. Also, the word "git" can be replaced by whatever SCM at hand: 1) X+git 2) X_20041122git 3) X+git20111213 4) X.a258.g003e7e3 5) X+git.1363873583.8dfab15 Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right? So the best version is indeed number 5), where the first number is the commit date and the second one is the commit hash. The date assures upgradability, because it increments always linearly and the commit hash provides for reproducability. You can of course argue about dots vs, any other separating paragraph. Also, instead of "+git", you may prefer sth. different (along as it won't break RPM's version comparison mechanism). TL;DR ===== My recommendation would be to (at least loosely) follow pattern 5) versioning if you ever have to package from SCMs. While devel projects are rather free to do whatever they prefer, I'd say it's appropriate for Factory submissions. Bonus ===== There is absolutely no reason to do this manually. Use the tar_scm source service (in disabled or local_only mode !!!) if you want to fully automate this. Here are some examples: Cloud:OpenStack:Master / openstack-utils devel:languages:go / go-assert -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

21 132

[opensuse-packaging] not dissolubles dependences - oS 13.1 RC 1 - Updates
by Jens 13 Dec '13

13 Dec '13

hi all Hoping you are my right address I send you "conflicts.txt" for 13.1 RC1 (down) Please look too for acroread -> ask for libidn.so11 it is on the DVD and installed if wanted -> syslog-ng -> ask for libevtlog.so. -> libnet.so1 I tell you, libevtlog is only in eventlog from feodora There is also a Problem with amarok-Update (?) sorry for my english Thank you Regards Jens conflicts: #### YaST2 conflicts list - generated 2013-10-21 09:31:20 #### libQtGStreamer-0.10.so.0()(64bit), benötigt von kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten [ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] Deinstallation von digikam-3.4.0-2.1.4.x86_64 [ ] veraltetes digikam-3.4.0-2.1.4.x86_64 behalten libkdecore.so.5, benötigt von kipi-plugins-3.5.0-2.4.2.i586, wird von keinem Repository angeboten [ ] veraltetes kipi-plugins-3.4.0-2.1.4.x86_64 behalten [ ] kipi-plugins-3.5.0-2.4.2.i586 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] Deinstallation von kipi-plugins-3.4.0-2.1.4.x86_64 libQtGStreamer-0.10.so.0()(64bit), benötigt von kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten [ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] veraltetes kipi-plugins-acquireimage-3.4.0-2.1.4.x86_64 behalten [ ] Deinstallation von kipi-plugins-acquireimage-3.4.0-2.1.4.x86_64 libQtGStreamer-0.10.so.0()(64bit), benötigt von kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten [ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] Deinstallation von kipi-plugins-geolocation-3.4.0-2.1.4.x86_64 [ ] veraltetes kipi-plugins-geolocation-3.4.0-2.1.4.x86_64 behalten #### YaST2 conflicts list END ### conflicts.txt #### YaST2 conflicts list - generated 2013-10-21 09:31:20 #### libQtGStreamer-0.10.so.0()(64bit), benötigt von kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten [ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] Deinstallation von digikam-3.4.0-2.1.4.x86_64 [ ] veraltetes digikam-3.4.0-2.1.4.x86_64 behalten libkdecore.so.5, benötigt von kipi-plugins-3.5.0-2.4.2.i586, wird von keinem Repository angeboten [ ] veraltetes kipi-plugins-3.4.0-2.1.4.x86_64 behalten [ ] kipi-plugins-3.5.0-2.4.2.i586 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] Deinstallation von kipi-plugins-3.4.0-2.1.4.x86_64 libQtGStreamer-0.10.so.0()(64bit), benötigt von kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten [ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] veraltetes kipi-plugins-acquireimage-3.4.0-2.1.4.x86_64 behalten [ ] Deinstallation von kipi-plugins-acquireimage-3.4.0-2.1.4.x86_64 libQtGStreamer-0.10.so.0()(64bit), benötigt von kipi-plugins-3.5.0-2.4.2.x86_64, wird von keinem Repository angeboten [ ] kipi-plugins-3.5.0-2.4.2.x86_64 beschädigen durch Ignorieren einiger Abhängigkeiten [ ] Deinstallation von kipi-plugins-geolocation-3.4.0-2.1.4.x86_64 [ ] veraltetes kipi-plugins-geolocation-3.4.0-2.1.4.x86_64 behalten #### YaST2 conflicts list END ### -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 9

[opensuse-packaging] noarch (sub-)package with ELF files in it
by Andrey Borzenkov 01 Dec '13

01 Dec '13

Background. Currently grub2 is split between grub2 containing user level utilities (should probably be really called grub2-tools or similar) and subpackages for each platform that contain boot-time files (kernel and modules). The actual bootloader binary for each platform is built at run time from those files. From currently running OS PoV those modules are simply opaque data. They are *never* executed on current OS and grub tools that use them to build executable image work identically on every platform. I.e. you can use grub2-mkimage to built usable grub executable (core.img) for SPARC, PPC64 or ARM while being on i386 system as long as files for these platforms are present. Built grub executable will be exactly identical independently of host OS architecture used to create it. Currently all grub2 subpackages are arch-dependent. This already means we have two absolutely identical packages - grub2-i386-pc for i386 and x86_64 (grub2 run-time on legacy BIOS is always 32 bit). As long as this was the only overlap this could be ignored. But now upstream added native support for Xen PV guests (a.k.a. pvgrub2). grub2 core.img must match guest architecture; which would mean that we'd need two *identical* subpackages for each i386 and x86_64 and possibly for other archs (ARM?) So I'm looking at making those subpackages noarch. That would reduce build time (could skip building some of them) and space (omitting identical packages). In principle from pure RPM PoV it works without problems. But our build tools get confused. The problems I hit so far. 1. rpmlint complaints about arch-independent-package-contains-binary-or-object. 2. (special case) rpmlint complaints about suse-filelist-forbidden-noarch due to /usr/lib64/efi/grub.efi - our signed EFI bootloader. Providing rpmlintrc unfortunately does not help for x86_64 case - when package is signed it is apparently being run through rpmlint as extra step *after* being built and fails because rpmlintrc is ignored. For 2 it probably makes sense to split binary in separate subpackage anyway. But for 1? So is it possible to do it? Would it be OK according to policies? Clean way to do it? You can see current work in home:arvidjaar:grub2-next:noarch/grub2 -- 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] error on upgrade?
by Greg Freemyer 30 Nov '13

30 Nov '13

All, I maintain httrack and httrack-3.47.24 installs fine on 12.3 With openSUSE 13.1 it fails: The error is: Error: Subprocess failed. Error: RPM failed: error: unpacking of archive failed on file /usr/share/httrack/html: cpio: rename failed - Is a directory It is actually not a directory, it's a symbolic link > ls -l total 32 lrwxrwxrwx 1 root root 28 Aug 29 14:12 html -> ../doc/packages/httrack/html drwxr-xr-x 2 root root 4096 Aug 29 14:12 lang -rw-r--r-- 1 root root 22442 Aug 26 08:51 lang.def -rw-r--r-- 1 root root 159 Aug 26 08:51 lang.indexes Is a symbolic link from /usr/share/html to /usr/share/doc/packages/httrack/html no longer valid? Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 11

[opensuse-packaging] factory-auto will start checking bnc# visibility
by Tomáš Chvátal 29 Nov '13

29 Nov '13

Hello guys, Just informational mail that we plan to enable bnc# checking in the changelogs to ensure that Factory submissions are in fact only listing visible bugs. [1] [2] The code is set-up the way it checks the changelog and reports back with all occurances of bugs that were not visible (it ignores the bnc if bugzilla does not respond, so no worries if it is down, everything is approved :P). Your actions if cases like this happen are quite simple: 1) make the initial bug visible and mark the internal comments as internal. 2) if not sure ask somebody who knows more to do it for you. As I wrote there in the code [2] it checks the full new changelog in case some bnc should not be there we don't get conflicts when comparing just diff. So you might get request to make really old bugs visible. It is a tiny annoyance but then we ensure that all informations about our fixes can be really read by anybody. Cheers Tom PS: feel free to improv perl in [2] as I am not exactly mage there :) [1] https://progress.opensuse.org/issues/571 [2] https://github.com/coolo/factory-auto/pull/46

20 59

[opensuse-packaging] lib prefix considered harmful
by Michal Vyskocil 29 Nov '13

29 Nov '13

Hi all, I would like to point to quite common anti-pattern when packaging shared libraries. It is great that most of people are aware about our Shared Library Policy[1]. However it is written in some confusing way, where some people (and I made it as well) think it mandate the name of **source** package. It does not, because noone wants to change source package name on each SONAME bump. For source package name there is a naming policy [2], which says package name should be according upstream project or tarball name (there are exceptions for python, perl, ruby, go, ... stuff). And it is legal to omit the %files section for source package (but not for subpackage). Therefor I have fixed and extended the zlib example[3], which should make that more clear. Source package name is zlib, because that is how both upstream and tarballs are named. But shared library package is libz1 according SONAME, where devel files are in zlib-devel. The name libz-devel might be acceptable as well, but it is confusing to me. But as long as pkgconfig(zlib) is the prefered form, the name of devel package is less important nowadays. [1] http://en.opensuse.org/openSUSE:Shared_library_packaging_policy [2] http://en.opensuse.org/openSUSE:Package_naming_guidelines#General_Naming [3] http://en.opensuse.org/openSUSE:Shared_library_packaging_policy#Examples Any objections? Regards Michal Vyskocil

5 6

[opensuse-packaging] UGG NZ, UGG Boots NZ Sale, UGG Black Friday 2013
by happy123 28 Nov '13

28 Nov '13

UGG boots NZ <http://www.2013blackfridaybootsnzsale.com/> , Resilient distinctions vitality the UGG logo manifest in between sure-enough pairs when additional fakes. Livelihood a jelly estimation on its stitched arranged down. Sight alien seeing the entrance boots are packaged guidance. Or glance at what sorts of offers the genuine solitary good. However, a dense notion blame hardly even additional these methods. 2013 Black Friday UGG boots <http://www.2013blackfridaybootsnzsale.com/> , But you do not ugg economical boots lust to strain. Some accepted procedures harmonious subjection shed in that cheated. First, mount unequivocal that you simply merely arranged rightful from a validated retailer. You in inclusion to culpability congregate individuals UGG about the net shops that groove about the congruous trait among the customers. Second, coterminous you picked out the boots you crave to buy, possess a acquire evaluation at their soles and heels. NZ UGG <http://www.2013blackfridaybootsnzsale.com/> , If agnate buy ugg boots images are not available, you price buzz the shop to protected you some. Usually, for proper UGG boots consist of knitted uppers reckon on repaired hide heels to impact packed shelter. Third, glance at when the UGG logo is stitched close to towards the shift through the boots. Palpable UGG boots fall for UGG logo enlightenment that slightly overlaps each and every solitary other. UGG boots Black friday <http://www.2013blackfridaybootsnzsale.com/> , Australian inexpensive ugg boots owing to buy sheepskin boots rest assured make-believe an incredible provide of revered fascination claims till because. Remarkably belonging to the collections illuminates the in inclusion to tendency on footwear. A greater distinction of womanliness is credulous realized these boots hint forgather their desires to glimpse trendy and elegant. <br> <img class="aligncenter" alt="UGG Boots NZ" src="http://www.2013blackfridaybootsnzsale.com/skin/frontend/default/bluescale/i…"> <http://www.2013blackfridaybootsnzsale.com/> <br/> Ugg boots are swiftly obtaining a cozy design merchandise whilst with the US and Canada, and for good reason. Ugg boots are superb Australian footwear that is generating their presence felt whilst with the close to the planet design footwear arena. -- View this message in context: http://opensuse.14.x6.nabble.com/UGG-NZ-UGG-Boots-NZ-Sale-UGG-Black-Friday-… Sent from the opensuse-packaging mailing list archive at Nabble.com. -- 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] /var/adm/update-scripts mechanism changed?
by Marguerite Su 25 Nov '13

25 Nov '13

Hi, guys, Currently I'm (re-)working on steam package in games:tools repository, which is a wrapper, using /var/adm/update-scripts mechanism to fill contents downloaded online into directories pre-created in %install section of specfile. And I found something interesting: In 13.1, the scripts is executed _before_ %install section. Which means, if you don't create the directories again in your script, it will fail. AKA, the `touch` way has gone. Verify here: https://build.opensuse.org/package/show/home:MargueriteSu:branches:games:to… Install the package in your 13.1, if you see "failed /usr/share/doc/packages/steam/steam_* (no such file or directory)", congrats! It indicates it's executed _before_ %install section, after a while (unpacking steam_1.0.0.44.tar.gz and copy), you'll see your %install section is processed. And if you `rpm -qf /usr/bin/steam`, it doesn't belong to any package. Any one tell something about the change? Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 9

[opensuse-packaging] desktop file category DataVisualization
by Woski, Michael 23 Nov '13

23 Nov '13

Hi, I'm trying to package labplot2 and I've created a labplot2.desktop file. Therein I specified Categories=Qt;KDE;Science;DataVisualization; According to http://standards.freedesktop.org/menu-spec/latest/apas02.html this should be a valid category. Yet, I get a packaging error: https://build.opensuse.org/package/live_build_log/home:scalpel4k/labplot2/o… Could you try to fix that? Thanks Michi -- 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] subscribe
by Alberto Planas Dominguez 22 Nov '13

22 Nov '13

-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] Request for testcases on spec-cleaner
by Tomáš Chvátal 22 Nov '13

22 Nov '13

Hello guys, Now for something completely different apart from my previous mail. As part of the hackweek efforts we in openSUSE Team are going to have next week I plan to work forward on spec-cleaner tool that is intended to be superset of the prepare_spec perl magic with something more readable and with testcases. [1] So what I would need is if you could take it on your specs and if it screw up (like for sure it will in its current state) write out start -> desired output files so I can convert it to testsuite and have it checked. There are currently known bugs for sure. Just grep for FIXME in the spec_cleaner subdir to get some picture, also there are few failing tests which already verify for something that it is doing poorly/uttery wrong. Overall one of biggest problems you can see with your specs now is that if you use %if... in your preamble it gets matched poorly and breaks ordering of that section. But when we tried it on mysql.spec it coped quite well and trivial specs are already parsed decently well. In the end really if you could try to run it (after git clone just run "python repo/spec_cleaner/__init__py myspec.spec -o output.spec") and report with issues here as reply or on github. TIA Tom [1] http://github.com/openSUSE/spec-cleaner/

3 5

[opensuse-packaging] Re: Pending reveiw for package dvb
by Jean Delvare 21 Nov '13

21 Nov '13

Le Thursday 21 November 2013 à 17:10 +0100, Juergen Weigert a écrit : > On Nov 21, 13 13:24:14 +0100, Jean Delvare wrote: > > Hi Juergen, hi all, > > > > https://build.opensuse.org/request/show/204184 > > > > is waiting for legal review for a month now. It is a simple license > > clarification between GPL and LGPL, nothing critical as far as I can > > see. What can be done to help this request move forward? > > Review queue length is 143 requests. I raise prio from 2 to 4. Oh, that's really a huge number :( I didn't mean to push you, just wanted to ensure it was not forgotten. If it's in your list already then alright, I'll be patient. For 13.1 I suppose I'll extract the easy bug fixes and forget about the one change which triggered the license re-check, to make everyone's life easier. Thanks, -- Jean Delvare Suse L3 Support -- 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] OBS and package version number
by Henri Gomez 21 Nov '13

21 Nov '13

Hi to all, I'm new to OBS and started to use it to package some stuff from my GitHub repo : https://github.com/hgomez/devops-incubator For one package, mynexus (https://build.opensuse.org/package/show/home:henri_gomez:devops-incubator/m…), I created this _service : <services> <service name="tar_scm"> <param name="scm">git</param> <param name="url">https://github.com/hgomez/devops-incubator.git</ param> <param name="versionformat">2.6.3</param> </service> <service name="recompress"> <param name="compression">gz</param> <param name="file">*.tar</param> </service> <service name="extract_file"> <param name="archive">*devops-incubator*.tar.gz</param> <param name="files">devops-incubator*/rpm-packaging/mynexus/SOURCES/*</param> <param name="files">devops-incubator*/rpm-packaging/mynexus/SPECS/*.spec</param> </service> <service name="download_url"> <param name="host">download.sonatype.com</param> <param name="protocol">http</param> <param name="path">/nexus/oss/nexus-2.6.3-01.war</param> <param name="filename">nexus-2.6.3.war</param> </service> <service name="download_url"> <param name="host">archive.apache.org</param> <param name="protocol">http</param> <param name="path">/dist/tomcat/tomcat-7/v7.0.47/bin/extras/catalina-jmx-remote.jar</param> <param name="filename">catalina-jmx-remote-7.0.47.jar</param> </service> <service name="download_url"> <param name="host">archive.apache.org</param> <param name="protocol">http</param> <param name="path">/dist/tomcat/tomcat-7/v7.0.47/bin/apache-tomcat-7.0.47.tar.gz</param> </service> <service name="set_version"> </service> </services> But I'm wondering with version produced is not 2.6.3 but 2.6.32.6.3-13.1 ie : https://build.opensuse.org/package/live_build_log/home:henri_gomez:devops-i… Advices very welcomed Thanks -- 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] packaging java libraries
by Darin Perusich 21 Nov '13

21 Nov '13

Hello All, I'm not sure if this belongs here or on the buildsvc mailing list but this list seems more appropriate to me. I find myself building and wanting to package more and more apps written in java which use maven as the build/dependency tool. Java devs seem to be more then happy to allow maven to grab and trust xyz.jar from whatever external repo it can found on. Repackaging jar's is unclean and any dependencies need to be available as rpm packages and this is something I've been struggling with for java packages, especially since a few I'd like to push into Factory at some point, examples being puppetdb and wirefly. For other development languages, lets use perl, we have tools like cpanspec which does a great job of grabbing the source and creating the spec files. There are also some automated process on the build service which create packages in devel:languages:perl:CPAN-[A-Z] repo's so it's super easy to branch them and push them into devel:languages:perl and subsequently into Factory or another devel repo. Is anyone aware of a cpanspec like tool for java libraries to accomplish this? I've looked briefly but haven't found anything. I dont' know if anyone as SuSE's put any thought into this, but I figured i'd ask. thanks! -- Later, Darin -- 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] Pending review for package dvb
by Jean Delvare 21 Nov '13

21 Nov '13

Hi Juergen, hi all, https://build.opensuse.org/request/show/204184 is waiting for legal review for a month now. It is a simple license clarification between GPL and LGPL, nothing critical as far as I can see. What can be done to help this request move forward? Thanks, -- Jean Delvare Suse L3 Support -- 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] Building release-notes-openSUSE: automake needed?
by Karl Eichwalder 19 Nov '13

19 Nov '13

ATM, I must BuildRequire automake to build the release-notes-openSUSE package. Do I have a wrong dependency somewhere? In the past, it was not needed. I tried to rebuild the package with the automake and autoconf from 12.3, but with no success. The package is here: home:keichwa:branches:openSUSE:13.1:Update/release-notes-openSUSE -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 8

Re: [opensuse-packaging] package update 12.3 -> 13.1
by Cristian Rodríguez 17 Nov '13

17 Nov '13

El 17/11/13 17:22, Peter Czanik escribió: > cmake does not appear in the spec file, that's why I'm asking :) (And > because the same spec file worked fine with 12.3...) > Bye, > CzP It seems that the cmake call is entangled in ./configure or a different script in the build system.. I have no words to describe how wrong that is.. -- "Judging by their response, the meanest thing you can do to people on the Internet is to give them really good software for free". - Anil Dash -- 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] package update 12.3 -> 13.1
by Peter Czanik 17 Nov '13

17 Nov '13

Hello, I'm trying to upgrade a package from openSUSE 12.3 to 13.1. It compiles fine on 12.3, but the same .spec fails to compile on 13.1. Actually it fails in the install phase: [ 661s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/bro-2.2-1.x86_64/usr/share/bro/magic/m4 [ 661s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/bro-2.2-1.x86_64/usr/share/bro/magic/fortran [ 661s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/bro-2.2-1.x86_64/usr/share/bro/magic/fonts [ 661s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/bro-2.2-1.x86_64/usr/share/bro/magic/troff [ 661s] -- Installing: /home/abuild/rpmbuild/BUILDROOT/bro-2.2-1.x86_64/usr/bin/bro [ 661s] CMake Error at src/cmake_install.cmake:45 (FILE): [ 661s] file RPATH_CHANGE could not write new RPATH: [ 661s] [ 661s] /usr/lib [ 661s] [ 661s] to the file: [ 661s] [ 661s] /home/abuild/rpmbuild/BUILDROOT/bro-2.2-1.x86_64/usr/bin/bro [ 661s] [ 661s] No valid ELF RPATH or RUNPATH entry exists in the file; [ 661s] Call Stack (most recent call first): [ 661s] cmake_install.cmake:64 (INCLUDE) [ 661s] [ 661s] [ 661s] make[1]: *** [install] Error 1 [ 661s] make[1]: Leaving directory `/home/abuild/rpmbuild/BUILD/bro-2.2/build' [ 661s] make: *** [install] Error 2 [ 661s] error: Bad exit status from /var/tmp/rpm-tmp.FawBDs (%install) The package is available at https://build.opensuse.org/package/show/home:czanik:bro/bro in the BuildService. Bye, CzP -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] Problem with %cmake macro - "fg: no job control"
by Michal Srb 13 Nov '13

13 Nov '13

Hello, I am trying to package program build using cmake (not kde). (home:michalsrb:branches:X11:XOrg/tigervnc) I try to use the cmake macro as is defined in /etc/rpm/macros.cmake from cmake package. I use it by simply calling it, it doesn't require any arguments: %cmake It works fine locally, but in buildservice I get following error: [ 203s] + '%cmake' [ 203s] /var/tmp/rpm-tmp.fYOMWM: line 31: fg: no job control [ 203s] error: Bad exit status from /var/tmp/rpm-tmp.fYOMWM (%build) That is shell complaining about % character, so the cmake macro looks to be expanded into nothing (?). I have cmake in BuildRequires. Any ideas what I am doing wrong? Michal -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 3

[opensuse-packaging] Fwd: [devel] CVE Syntax Change
by Sascha Peilicke 13 Nov '13

13 Nov '13

-- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

1 0

[opensuse-packaging] FoxitReader (non free)
by Joschi Brauchle 10 Nov '13

10 Nov '13

Hello, following up on the discussion about the removal of acroread for openSUSE 13.1, I tried to package the FoxitReader PDF viewer here: https://build.opensuse.org/package/show/home:endzone/FoxitReader (publishing is diabled) The reason for doing this is that Foxitreader provides some of the advanced GUI printing functionality that acroread also provided, but OSS PDF viewers are missing currently (due to KDE printing not moving forward). I have some questions about the redistribution license from here: http://www.foxitsoftware.com/pdf/rd_rla.htm Will this allow me to build the package on OBS? The Linux version of FoxitReader has not been updated since 2009, so I dont know if it is currently vulnerable to any security issues... Best regards, J Brauchle

4 10

[opensuse-packaging] Re: [opensuse-factory] Extended Chromium builds for openSUSE !
by Jan Ritzerfeld 05 Nov '13

05 Nov '13

Am Mittwoch, 30. Oktober 2013, 22:44:27 schrieb ich: > [...] > For me (oS 12.3), at least chromium-beta crashes whenever it tries to > autofill. That is, it even crashes in its own settings. This is caused by > a very old bug in libicu 49.1[0][1] that is fixed in 49.1.2, thus not > affecting Factory. However, 12.3 and 12.2 have this 18 months old icu. I > branched icu of 12.3 and updated it to 49.2.1 in > https://build.opensuse.org/package/show/home:jritzerfeld:branches:openSUSE > :12.3:Update/icu.openSUSE_12.3_Update Can anyone else confirm that this > problem really exists and libicu 49.1.2 fixes the problem? > [...] > [0] https://code.google.com/p/chromium/issues/detail?id=122499 > [1] http://bugs.icu-project.org/trac/ticket/9283 I filed a bug report: https://bugzilla.novell.com/show_bug.cgi?id=848553 and prepared maintenance updates for 12.2 and 12.3. According to http://en.opensuse.org/Portal:Maintenance I set its state to NEEDINFO maintenance... Is it still true that I now have to wait for a positive review by the Maintenance Team *before* I create a request for starting a maintenance incident? Gruß Jan -- A system tends to grow in terms of complexity rather than of simplification, until the resulting unreliability is intolerable. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 9

[opensuse-packaging] Home location and submission of Joomla package [Content Management System]
by doiggl＠velocitynet.com.au 05 Nov '13

05 Nov '13

Hello, Would a good home location for Joomla package [Content Management System] be the following: https://build.opensuse.org/project/show/server:php:applications I did a test compile and it builds and installs ok [1] Just build latest relesed versions from http://www.joomla.org/download.html Runs ontop of a lamp subsystem. How can it be submitted to this category ? Would anyone be interested in using this package ? Cheers Glenn [1] Joomla package - test compile https://build.opensuse.org/package/show/home:doiggl/joomla Full build log: https://build.opensuse.org/package/rawlog/home:doiggl/joomla/openSUSE_Facto… From logs: . . [ 90s] 3 packages and 0 specfiles checked; 0 errors, 28 warnings. [ 90s] [ 90s] ... creating baselibs [ 90s] ... saving built statistics [ 90s] ... saving built packages [ 90s] /home/abuild/rpmbuild/RPMS/noarch/joomla-3.1.5-8.1.noarch.rpm [ 90s] /home/abuild/rpmbuild/RPMS/noarch/joomla-installation-3.1.5-8.1.noarch.rpm [ 90s] /home/abuild/rpmbuild/SRPMS/joomla-3.1.5-8.1.src.rpm [ 91s] /home/abuild/rpmbuild/OTHER/_statistics [ 91s] /home/abuild/rpmbuild/OTHER/rpmlint.log [ 91s] [ 91s] cloud132 finished "build joomla.spec" at Fri Oct 4 15:02:26 UTC 2013. [ 91s] [ 94s] [ 82.922491] SysRq : Power Off [ 94s] [ 83.095185] Power down. [ 94s] build: extracting built packages... [ 95s] joomla-3.1.5-8.1.noarch.rpm [ 95s] joomla-installation-3.1.5-8.1.noarch.rpm [ 95s] joomla-3.1.5-8.1.src.rpm Architecture: i586 joomla-3.1.5-8.1.noarch.rpm joomla-3.1.5-8.1.src.rpm joomla-installation-3.1.5-8.1.noarch.rpm Architecture: x86_64 joomla-3.1.5-8.1.noarch.rpm joomla-3.1.5-8.1.src.rpm joomla-installation-3.1.5-8.1.noarch.rpm RPMLINT report: =============== joomla.noarch: W: script-without-shebang /srv/www/htdocs/joomla/administrator/components/com_users/helpers/users.php joomla.noarch: W: script-without-shebang /srv/www/htdocs/joomla/administrator/components/com_users/views/users/tmpl/default.php joomla.noarch: W: script-without-shebang /srv/www/htdocs/joomla/administrator/components/com_users/views/note/tmpl/index.html joomla.noarch: W: script-without-shebang /srv/www/htdocs/joomla/administrator/components/com_users/views/notes/index.html joomla.noarch: W: script-without-shebang /srv/www/htdocs/joomla/administrator/components/com_users/views/note/index.html joomla.noarch: W: script-without-shebang /srv/www/htdocs/joomla/administrator/components/com_users/views/notes/tmpl/index.html joomla-installation.noarch: W: script-without-shebang /srv/www/htdocs/joomla/installation/template/index.php This text file has executable bits set or is located in a path dedicated for executables, but lacks a shebang and cannot thus be executed. If the file is meant to be an executable script, add the shebang, otherwise remove the executable bits or move the file elsewhere. joomla.noarch: W: pem-certificate /srv/www/htdocs/joomla/libraries/joomla/http/transport/cacert.pem Shipping a PEM certificate is likely wrong. If used for the default configuration, this is insecure ( since the certificate is public ). If this is used for validation, ie a CA certificate store, then this must be kept up to date due to CA compromise. The only valid reason is for testing purpose, so ignore this warning if this is the case. joomla.noarch: W: non-executable-script /srv/www/htdocs/joomla/bin/keychain.php 0644L /usr/bin/env This text file contains a shebang or is located in a path dedicated for executables, but lacks the executable bits and cannot thus be executed. If the file is meant to be an executable script, add the executable bits, otherwise remove the shebang or move the file elsewhere. joomla.noarch: W: no-changelogname-tag joomla-installation.noarch: W: no-changelogname-tag joomla.src: W: no-changelogname-tag There is no changelog. Please insert a '%changelog' section heading in your spec file and prepare your changes file using e.g. the 'osc vc' command. joomla.noarch: W: name-repeated-in-summary C Joomla joomla.src: W: name-repeated-in-summary C Joomla The name of the package is repeated in its summary. This is often redundant information and looks silly in various programs' output. Make the summary brief and to the point without including redundant information in it. joomla.src:71: W: macro-in-comment %{buildroot} joomla.src:72: W: macro-in-comment %{name} joomla.src:222: W: macro-in-comment %{apache_serverroot} joomla.src:229: W: macro-in-comment %{apache_serverroot} There is a unescaped macro after a shell style comment in the specfile. Macros are expanded everywhere, so check if it can cause a problem in this case and escape the macro with another leading % if appropriate. joomla.noarch: W: invalid-license GPL joomla-installation.noarch: W: invalid-license GPL joomla.src: W: invalid-license GPL The specified license string is not recognized. Please refer to http://license.opensuse.org/ for the list of known licences and their exact spelling. joomla.noarch: W: incorrect-fsf-address /srv/www/htdocs/joomla/libraries/phpmailer/LICENSE joomla.noarch: W: incorrect-fsf-address /srv/www/htdocs/joomla/libraries/simplepie/idn/LICENCE joomla.noarch: W: incorrect-fsf-address /srv/www/htdocs/joomla/administrator/templates/hathor/LICENSE.txt joomla.noarch: W: incorrect-fsf-address /srv/www/htdocs/joomla/LICENSE.txt joomla.noarch: W: incorrect-fsf-address /srv/www/htdocs/joomla/libraries/idna_convert/LICENCE The Free Software Foundation address in this file seems to be outdated or misspelled. Ask upstream to update the address, or if this is a license file, possibly the entire file with a new copy available from the FSF. joomla.noarch: W: files-duplicate /srv/www/htdocs/joomla/media/jui/index.html /srv/www/htdocs/joomla/administrator/components/com_finder/models/forms/index.html:/srv/www/htdocs/joomla/components/com_finder/views/search/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/statistics/index.html:/srv/www/htdocs/joomla/components/com_finder/helpers/html/index.html:/srv/www/htdocs/joomla/media/jui/css/index.html:/srv/www/htdocs/joomla/media/system/images/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/filters/index.html:/srv/www/htdocs/joomla/administrator/components/com_users/views/notes/tmpl/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/filter/index.html:/srv/www/htdocs/joomla/media/system/images/modal/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/html/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/index.html:/srv/www/htdocs/joomla/components/com_finder/helpers/index.html:/srv/www/htdocs/joomla/modules/mod_ finder/i ndex.html:/srv/www/htdocs/joomla/media/jui/js/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/indexer/stemmer/index.html:/srv/www/htdocs/joomla/media/jui/fonts/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/models/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/indexer/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/sql/index.html:/srv/www/htdocs/joomla/administrator/components/com_users/views/note/index.html:/srv/www/htdocs/joomla/administrator/components/com_users/views/note/tmpl/index.html:/srv/www/htdocs/joomla/plugins/system/highlight/index.html:/srv/www/htdocs/joomla/media/system/images/mooRainbow/index.html:/srv/www/htdocs/joomla/media/com_finder/js/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/index/index.html:/srv/www/htdocs/joomla/administrator/compone nts/com_ users/views/notes/index.html:/srv/www/htdocs/joomla/media/com_finder/css/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/indexer/parser/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/views/statistics/index.html:/srv/www/htdocs/joomla/media/plg_system_highlight/index.html:/srv/www/htdocs/joomla/plugins/finder/categories/index.html:/srv/www/htdocs/joomla/media/system/css/index.html:/srv/www/htdocs/joomla/plugins/finder/contacts/index.html:/srv/www/htdocs/joomla/media/jui/img/index.html:/srv/www/htdocs/joomla/components/com_finder/views/search/tmpl/index.html:/srv/www/htdocs/joomla/components/com_finder/index.html:/srv/www/htdocs/joomla/media/com_finder/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_finder/maps/index.html:/srv/www/htdocs/joomla/administrator/components/com_languages/views/overrides/index.html:/srv/www/htdocs/joomla/plugins/finder/newsfeeds/index.html:/srv/www/htdocs/joomla/media/jui/ less/ind ex.html:/srv/www/htdocs/joomla/components/com_finder/controllers/index.html:/srv/www/htdocs/joomla/plugins/finder/tags/index.html:/srv/www/htdocs/joomla/plugins/finder/content/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/helpers/indexer/driver/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/views/statistics/tmpl/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/models/fields/index.html:/srv/www/htdocs/joomla/components/com_finder/models/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/controllers/index.html:/srv/www/htdocs/joomla/administrator/components/com_finder/views/index.html:/srv/www/htdocs/joomla/administrator/components/com_languages/views/overrides/tmpl/index.html:/srv/www/htdocs/joomla/media/system/index.html:/srv/www/htdocs/joomla/components/com_finder/views/index.html:/srv/www/htdocs/joomla/administrator/components/com_config/models/fields/index.html:/srv/www/htdocs/joomla/med ia/syste m/js/index.html:/srv/www/htdocs/joomla/administrator/templates/hathor/html/com_users/user/index.html:/srv/www/htdocs/joomla/plugins/finder/weblinks/index.html:/srv/www/htdocs/joo[ 79.264141] serial8250: too much work for irq4 mla/administrator/components/com_finder/tables/index.html:/srv/www/htdocs/joomla/modules/mod_finder/tmpl/index.html joomla.noarch: W: explicit-lib-dependency php5-zlib You must let rpm find the library dependencies by itself. Do not put unneeded explicit Requires: tags. 3 packages and 0 specfiles checked; 0 errors, 28 warnings. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 10