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