December 2013

[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: … [View More]

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 … [View More]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) [View Less]

21 132

[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] Best practices for a library with backends?
by Martin Vidner 09 Jan '14

09 Jan '14

Hi, I am getting involved with https://github.com/libyui , the UI library powering YaST. The basic design is a core library, libyui, which provides the API but has no actual UI. One of the 3 backends, libyui-{ncurses,gtk,qt}, is needed. I am looking for examples of best practices of versioning the shared libraries and setting up the dependencies among the parts of the framework. Current problems of libyui in this area: - not being careful about the so-versioning. That is a solved problem … [View More]

2 1

[opensuse-packaging] Stack protector isues?
by Ilya Chernykh 09 Jan '14

09 Jan '14

What causes this package to fail for 32-bit but build for 64-bit in Factory? https://build.opensuse.org/package/show/KDE:KDE3/kdelibs3 I receive the following error message: [ 666s] /usr/lib/libc_nonshared.a(stack_chk_fail_local.oS): In function `__stack_chk_fail_local': [ 666s] /home/abuild/rpmbuild/BUILD/glibc-2.18.90/debug/stack_chk_fail_local.c:45: undefined reference to `__stack_chk_fail' [ 666s] collect2: error: ld returned 1 exit status [ 666s] Error creating ./kdeprint/management/… [View More]

5 12

[opensuse-packaging] openocd looks for home
by Matwey V. Kornilov 07 Jan '14

07 Jan '14

Hi, We have different forks of openocd package. Even I have my own with CMSIS support. But we don't have devel project for it. openocd is open on-chip debugger. It is a tool to communicate with embedded ARM-based hardware, to upload microcode and to provide interface for gdb for online debugging. I think, It is necessary to have openocd in Factory, but in any case we need devel project. I have not found appropriate project. Any ideas? Who will take care? -- To unsubscribe, e-mail: … [View More]

2 1

[opensuse-packaging] openSUSE ARMм7 BeagleBone Black experience
by Matwey V. Kornilov 02 Jan '14

02 Jan '14

Hi Marcus and all, I was trying to set this up and now I am in stuck. I have a piece of this hardware and want to run openSUSE 13.1 on it. I've collected needed packages (with u-boot-am335xevm 2013.04) in home:matwey:beaglebone,. I took openSUSE:13.1:Ports/JeOS as a base. Fortunately, there even was JeOS-beaglebone.kiwi, but it was not built and published. I've found two thing regarding to u-boot setup (quite strange): 1. u-boot looks for dtb in /boot/, when dtb-s are installed into /boot/… [View More]

3 11

[opensuse-packaging] python issue I don't understand
by Greg Freemyer 30 Dec '13

30 Dec '13

I'm trying to package the Google Cloud Print client home:gregfreemyer:Tools-for-forensic-boot-cd CUPS-Cloud-Print (note: The WebUI seems to be down currently) If I comment out "/usr/lib/cloudprint-cups/upgrade.py" from the %post section it builds fine. Further, after I install the RPM, I can run upgrade.py manually and it works fine. If I uncomment it, then I get a failure during build even against openSUSE_13.1: Traceback (most recent call last): [ 113s] File "/usr/lib/cloudprint-… [View More]

3 4

SOLVED (Was Re: [opensuse-packaging] Files for Two Packages and Do Not Conflict Issues)
by Andi Sugandi 29 Dec '13

29 Dec '13

Hi, On Sun, Dec 29, 2013 at 5:39 PM, Andrey Borzenkov <arvidjaar(a)gmail.com> wrote: > В Вс, 29/12/2013 в 17:31 +0700, Andi Sugandi пишет: >> Hi, >> >> I'm trying to build two packages: ignsdk and ignsdk-devtools. >> >> Right now I'm facing with these issues: >> >> "... >> >> [ 42s] ERROR: /usr/share/ign-sdk/bin/ignsdk-ign-builder is packaged >> in both ignsdk and ignsdk-devtools, and the packages do not conflict >> [ … [View More]

1 0

[opensuse-packaging] Files for Two Packages and Do Not Conflict Issues
by Andi Sugandi 29 Dec '13

29 Dec '13

Hi, I'm trying to build two packages: ignsdk and ignsdk-devtools. Right now I'm facing with these issues: "... [ 42s] ERROR: /usr/share/ign-sdk/bin/ignsdk-ign-builder is packaged in both ignsdk and ignsdk-devtools, and the packages do not conflict [ 42s] ERROR: /usr/share/ign-sdk/template/app.spec is packaged in both ignsdk-devtools and ignsdk, and the packages do not conflict [ 42s] ERROR: /usr/share/ign-sdk/template/main.tpl is packaged in both ignsdk and ignsdk-devtools, and the … [View More]

2 1

Main

Development

Information

Community

Social Media

Other

openSUSE Packaging