openSUSE Packaging December 2013

packaging@lists.opensuse.org

40 participants
28 discussions

[opensuse-packaging] krb5 dependency in Base:System

by Stephan Kulow

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

6 years, 8 months

[opensuse-packaging] Proper version scheme for packages from git, hg, svn, ...

by Sascha Peilicke

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)

6 years, 10 months

[opensuse-packaging] Using "~" in package version?

by Andrey Borzenkov

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

6 years, 10 months

[opensuse-packaging] Best practices for a library with backends?

by Martin Vidner

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 for a single(!) library, see https://github.com/openSUSE/libzypp/blob/a01b41c7dfe42a1fae9d9431fbad61997f… - the user-facing ABI of libyui and the backend-facing ABI are not well separated. Is there any project which has figured this out? - expressing the dependency "the core lib needs at least one backend with a matching ABI" is done via the yui_backend symbol but that breaks bootstrapping the build (See Fedora 19 on https://build.opensuse.org/project/monitor/devel:libraries:libyui ) Can you point me to any projects that handle this situation (common api + backends), however well? -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

6 years, 10 months

[opensuse-packaging] Stack protector isues?

by Ilya Chernykh

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/libkdeinit_kaddprinterwizard.la. Exit status 1. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 years, 10 months

[opensuse-packaging] openocd looks for home

by Matwey V. Kornilov

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: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 years, 10 months

[opensuse-packaging] openSUSE ARMм7 BeagleBone Black experience

by Matwey V. Kornilov

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/dtb (is it a bug?) 2. mmcboot command tries to boot the kernel with bootm command: mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${kloadaddr} - ${fdtaddr} when compressed zImage is installed and have to be booted with bootz command. After this issues had been fixed manually from u-boot console, I was able to boot the linux. Here is available full booting log: http://paste.opensuse.org/18807914 Booting is stuck on root partition waiting, easily something wrong with mmc card device driver, but I can not figure out what exactly. dtb-file seems to be correct, u-boot finds that it has to be am335x-boneblack.dtb Will appreciate any help. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 years, 11 months

[opensuse-packaging] python issue I don't understand

by Greg Freemyer

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-cups/upgrade.py", line 19, in <module> [ 113s] from oauth2client import client [ 113s] File "/usr/lib/cloudprint-cups/oauth2client/client.py", line 26, in <module> [ 113s] import httplib2 [ 113s] File "/usr/lib/python2.7/site-packages/httplib2/__init__.py", line 908, in <module> [ 113s] class HTTPSConnectionWithTimeout(httplib.HTTPSConnection): My googling implies I just need to BuildRequires openssl and libopenssl-devel and it should resolve the issue. I've got both in the specfile now, but it is still failing. The other web claim is I need to rebuild python with SSL support, but I'm using openSUSE_13.1 in both my local machine and in the chroot jail, so the python modules should be the same. I'm not sure what I'm doing wrong. Thanks 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 years, 11 months

SOLVED (Was Re: [opensuse-packaging] Files for Two Packages and Do Not Conflict Issues)

by Andi Sugandi

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 >> [ 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 packages do not conflict >> [ 42s] ERROR: /usr/share/ign-sdk/bin/ignsdk-ign-creator is packaged >> in both ignsdk and ignsdk-devtools, and the packages do not conflict >> >> >> ..." >> >> https://build.opensuse.org/package/live_build_log/home:andisugandi/ignsdk/o… >> >> Those files are intended to belong to *only* ignsdk-devtools. >> >> Any suggestions, please? >> > > /usr/share/ign-sdk in %files section includes everything under this > directory. To package directory itself use > > %dir /usr/share/ign-sdk Great! That solved the issue. "... %files %defattr(-,root,root,-) %dir /usr/share/ign-sdk ..." Thank you very much. -- Andi Sugandi. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 years, 11 months

[opensuse-packaging] Files for Two Packages and Do Not Conflict Issues

by 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 [ 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 packages do not conflict [ 42s] ERROR: /usr/share/ign-sdk/bin/ignsdk-ign-creator is packaged in both ignsdk and ignsdk-devtools, and the packages do not conflict ..." https://build.opensuse.org/package/live_build_log/home:andisugandi/ignsdk/o… Those files are intended to belong to *only* ignsdk-devtools. Any suggestions, please? Here is the spec file: https://build.opensuse.org/package/view_file/home:andisugandi/ignsdk/ignsdk… BTW, happy holiday! :) Thanks in advance. -- Andi Sugandi. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 years, 11 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging December 2013