openSUSE Packaging November 2013

packaging@lists.opensuse.org

52 participants
24 discussions

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

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

not dissolubles dependences - oS 13.1 RC 1 - Updates

by Jens

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

6 years, 11 months

noarch (sub-)package with ELF files in it

by Andrey Borzenkov

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

6 years, 12 months

error on upgrade?

by Greg Freemyer

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 years, 12 months

factory-auto will start checking bnc# visibility

by Tomáš Chvátal

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

7 years

lib prefix considered harmful

by Michal Vyskocil

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

7 years

UGG NZ, UGG Boots NZ Sale, UGG Black Friday 2013

by happy123

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

7 years

/var/adm/update-scripts mechanism changed?

by Marguerite Su

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

7 years

desktop file category DataVisualization

by Woski, Michael

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

7 years

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging November 2013