January 2014 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] -DCMAKE_INSTALL_PREFIX does not work
by Ilya Chernykh 29 Jan '14

29 Jan '14

This problem exists in nearly every package based on cmake. When I am trying to build a cmake application for KDE3 (where it should be in /opt/kde3 prefix), it gets installed in /usr. I already abandoned several packages and in other ones I manually patched the makefiles. Is there a general way, or CMAKE is just a buggy crap? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 5

[opensuse-packaging] What's the problem with this package (autotools bug?)
by Ilya Chernykh 28 Jan '14

28 Jan '14

When building this package: https://build.opensuse.org/package/show/KDE:KDE3/yast2-control-center-qt3 I encounter an error message: [ 57s] configure.ac:18: error: AC_INIT should be called with package and version arguments [ 57s] /usr/share/aclocal-1.13/init.m4:23: AM_INIT_AUTOMAKE is expanded from... This happens only in Factory. Where's the problem? -- 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] Question: Where do I get perl-Email-MIME-Modifier >= 1.442 rpm [which repo] ?
by doiggl＠velocitynet.com.au 25 Jan '14

25 Jan '14

Hello. I have packaged up the bugzilla package but have trouble installing it. Problem: nothing provides perl-Email-MIME-Modifier >= 1.442 needed by bugzilla-4.4.1-30.1.noarch Question: Where do I get perl-Email-MIME-Modifier >= 1.442 rpm ? Thanks Glenn So far I have done: # zypper ar http://ftp5.gwdg.de/pub/opensuse/repositories/home:/doiggl/openSUSE_13.1/ mypackages # zypper in bugzilla Loading repository data... Reading installed packages... Resolving package dependencies... Problem: nothing provides perl-Email-MIME-Modifier >= 1.442 needed by bugzilla-4.4.1-30.1.noarch Solution 1: do not install bugzilla-4.4.1-30.1.noarch Solution 2: break bugzilla-4.4.1-30.1.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/c] (c): other details: bugzilla-4.4.1-30.1.noarch.rpm 24-Jan-2014 10:43 5.4K http://ftp5.gwdg.de/pub/opensuse/repositories/home:/doiggl/openSUSE_13.1/no… Log details ########### # zypper ar http://ftp5.gwdg.de/pub/opensuse/repositories/home:/doiggl/openSUSE_13.1/ mypackages Adding repository 'mypackages' ........................[done] Repository 'mypackages' successfully added Enabled: Yes Autorefresh: No GPG check: Yes URI: http://ftp5.gwdg.de/pub/opensuse/repositories/home:/doiggl/openSUSE_13.1/ -- 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] 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] fix needed for: directories not owned by a package:
by doiggl＠velocitynet.com.au 23 Jan '14

23 Jan '14

Hello What is the spec fix for the following: spec file: https://build.opensuse.org/package/view_file/home:doiggl/bugzilla/bugzilla.… -- Glenn [ 79s] ... running 02-check-gcc-output [ 79s] ... testing for serious compiler warnings [ 79s] (using /usr/lib/build/checks-data/check_gcc_output) [ 79s] (using //.build.log) [ 79s] ... running 03-check-binary-kernel-log [ 79s] ... running 04-check-filelist [ 79s] ... checking filelist [ 79s] bugzilla-contrib-4.2.7-50.1.noarch.rpm: directories not owned by a package: [ 79s] - /usr/share/bugzilla/contrib [ 79s] bugzilla-doc-4.2.7-50.1.noarch.rpm: directories not owned by a package: [ 79s] - /usr/share/bugzilla/docs [ 79s] - /usr/share/bugzilla/docs/en [ 79s] bugzilla-4.2.7-50.1.noarch.rpm: directories not owned by a package: [ 79s] - /etc/httpd [ 79s] - /etc/httpd/conf.d [ 79s] - /usr/share/bugzilla/contrib [ 79s] bugzilla-doc-build-4.2.7-50.1.noarch.rpm: directories not owned by a package: [ 79s] - /usr/share/bugzilla/docs [ 79s] - /usr/share/bugzilla/docs/en [ 85s] [ 73.664374] SysRq : Power Off [ 85s] [ 73.772356] reboot: Power down -- 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] missing lvm2-devel package
by Henrik Kuhn 20 Jan '14

20 Jan '14

Hi, I wonder why there is no officaly released openSUSE 'lvm2-devel' package available? During the packaging of the lvm2 package the header files lvm2cmd.h, lvm2app.h including the pkgconfig lvm2app.pc are explicitly deleted. Why just do not package these separately? Here is my proposal: Index: lvm2.changes =================================================================== --- lvm2.changes (revision 2) +++ lvm2.changes (revision 3) @@ -1,4 +1,10 @@ ------------------------------------------------------------------- +Sat Jan 18 21:19:31 UTC 2014 - henrik.kuhn(a)origenis.de + +- added a lvm2-devel package definition +- added %config macro before /etc/lvm/lvm.conf + +------------------------------------------------------------------- Mon Jan 6 07:43:59 UTC 2014 - dmzhang(a)suse.com - add csm_convert to lvm2-clvm package(bnc#854076) Index: lvm2.spec =================================================================== --- lvm2.spec (revision 2) +++ lvm2.spec (revision 3) @@ -189,9 +189,9 @@ rm $RPM_BUILD_ROOT/etc/lvm/cache/.cache #remove lvm-devel parts -rm -f $RPM_BUILD_ROOT/usr/include/lvm2cmd.h -rm -f $RPM_BUILD_ROOT/usr/include/lvm2app.h -rm -f $RPM_BUILD_ROOT%{_libdir}/pkgconfig/lvm2app.pc +#rm -f $RPM_BUILD_ROOT/usr/include/lvm2cmd.h +#rm -f $RPM_BUILD_ROOT/usr/include/lvm2app.h +#rm -f $RPM_BUILD_ROOT%{_libdir}/pkgconfig/lvm2app.pc #remove device-mapper man page rm -f $RPM_BUILD_ROOT/%{_mandir}/man8/dm* #remove device-mapper systemd events @@ -408,4 +408,25 @@ /usr/lib/ocf/resource.d/lvm2/cmirrord %{_mandir}/man8/cmirrord.8.gz + + +%package devel +Version: 2.02.98 +Release: 0 +Requires: lvm2 = %{version} +Summary: Development files for LVM2 +Group: Development/Libraries/C and C++ + + +%description devel +This package provides development files for the LVM2 Logical Volume Manager. + + +%files devel +%defattr(-,root,root) +/usr/include/lvm2cmd.h +/usr/include/lvm2app.h +%_libdir/pkgconfig/lvm2app.pc + + %changelog Regards, Henrik -- 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] Help with build cycle
by Robert Schweikert 18 Jan '14

18 Jan '14

Hi, Could use some help with the following problem: Getting buildconfig from server and store to /work/rjschwei/obs/filesystems/s3fs/.osc/_buildconfig-openSUSE_13.1-x86_64 buildinfo is broken... it says: unresolvable: have choice for libss.so.2()(64bit) needed by krb5-mini: libcom_err2 libcom_err2-mini, have choice for libcom_err.so.2()(64bit) needed by krb5-mini: libcom_err2 libcom_err2-mini This occurs for filesystems:s3fs, which I am trying to update to 1.74 Help is as always appreciated. Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead Public Cloud Architect rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 6

[opensuse-packaging] Re: RPM in openSUSE 13.1
by Bernhard Voelker 18 Jan '14

18 Jan '14

[forwarding to opensuse-packaging ML] On 01/15/2014 11:50 PM, Marco Cimmino Gibellini wrote: > Hi, > my name is Marco Cimmino and I am the main UI developer for Skype for Linux. > > I am writing to you to ask a question about an odd behaviour of rpm/package manager installed on openSUSE 13.1. > Our main problem is to add a dependency in our Skype rpm package that depends on a 32-bit libraries, regardless the > running openSUSE is either 32-bit or 64-bit. > This is easily achievable on Fedora 20 specifying in the RPM Requires field something like this: > Requires: alsa-plugins-pulseaudio(x86-32) > > As also stated in this document: > http://www.rpm.org/wiki/PackagerDocs/ArchDependencies > > However the same thing does not work on openSUSE 13.1, if I do not mention the architecture then it will pull the same > as the operating system, if I mention it then it fails to install it with unmet dependencies error. > Since rpm version is exactly the same as Fedora 20, v4.11.1, I wonder why this difference and if there is any workaround. > > I hope you can give me more insight, thank you. > > best > Marco Cimmino > ----- > Linux UI team, Skype > UI developer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

15 36

[opensuse-packaging] Using "~" in package version?
by Andrey Borzenkov 13 Jan '14

13 Jan '14

Is using something like 2.02~beta1 acceptable? Brief check suggests that RPM does support it and sorts this before 2.02, but may be there are guidelines for it? Since which openSUSE release is it supported BTW? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 4

[opensuse-packaging] Build for x86_64 platform on x86?
by Andrey Borzenkov 13 Jan '14

13 Jan '14

GRUB2 for legacy BIOS builds two EFI runtime emulation modules - 32 and 64 bits. They are used when booting OS X. As I noticed, those modules are missing in grub2 for i586 because it cannot build 64 bit module. Is it possible at all? Which packages would be need during build? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 5