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
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)
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
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
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
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
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
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
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