December 2013 - openSUSE Packaging - openSUSE Mailing Lists

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

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

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

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

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

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

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

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

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

2 1

Re: [opensuse-packaging] python issue I don't understand
by Dmitriy Perlow 28 Dec '13

28 Dec '13

Hi. There are no Internet access from build machine. Your package' postin shouldn't use it. ______________ Dmitriy Perlow via SE J10i

1 0

[opensuse-packaging] factory openssl and ec
by Matwey V. Kornilov 21 Dec '13

21 Dec '13

Hi, Why has elliptic curve cryptography been disabled in factory openssl? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] Re: Up coming changes to Enlightenment (e16, e17, e18) + libraries
by Tomas Cech 20 Dec '13

20 Dec '13

Hi, On Thu, Dec 19, 2013 at 12:07:13PM +1030, Simon wrote: > Hi All, > before everyone heads off for Christmas / summer / winter breaks, i'd like > to give a heads up of some changes coming to openSUSE:factory over the > next few weeks we will try to limit breakages however some temporary > issues may be unavoidable. > Firstly the existing enlightenment package will be removed and replaced > with one called e16, this is the only change for e16 users i'll get back > to whats happening with the enlightenment package in a little bit. > > The biggest change will be to the enlightenment foundation libraries (efl) > used by e17, e18 and terminology. As of efl 1.8 all the components of the > efl with the exception of elementary are shipped as one source tar and are > built together as such we have added one new package efl and will be > removing the following packages, eina, eet, evas, eio, emotion, efreet, > e_dbus, embryo, edje and eeze. E_dbus is exception here as it is still needed for e17 to run. But that is OK, because single-source efl doesn't contain it. > As not all the extra modules / themes are available with e18 and because > it requires compositing to be enabled we have had some requests to keep > e17 around. For now we will be keeping e17 pretty much as is but probably > at version 0.17.6 instead of 0.17.3 unless it is found unusable by a > number of people, it will also build from the new efl package rather then > the older split libraries. > > Enlightenment e18 will be built in the enlightenment package, this is > because upstream have indicated they would like to do a new release at > least every year possibly less and i don't want to change the package name > that often. I will try and come up with a way for e17.3 in 13.1 to > automaticlly update to the new enlightenment e18 package that doesn't ask > people who are using e17.6 from 13.2 to update, if someone could help with > that it would be great, i don't know how to do it. > > Previously themes were named e-theme-* and modules e-module-* as themes > and modules need to be built against the right version of enlightenment > the package naming will change to e17-module-* and e17-theme-* for e17 and > enlightenment-module-* and enlightenment-theme-*, e17 users who use > terminology will also need both the e17 and enlightenment theme as e18 and > later themes are used by the libraries as well > > Currently we don't plan to keep e18 around when e19 etc come out like we > have with e16 and e17. > > Summary of changes: > Stage 1 (Basics): > * Add efl > * replace existing enlightenment package with e16) > Stage 2 (core components) > * Update elementary, terminology and e17 to use efl rather then older > libs. > * add new enlightenment package > Stage 3 (everything else) > * replace / add modules, themes and branding > * update other packages i forgot about. > * remove old libraries Thanks for this mail. Until all the changes will be done, EFL and E17 + E18 is expected to be broken. Sleep_Walker

2 1

[opensuse-packaging] Upcoming changes to Enlightenment (e16, e17, e18) + libraries, Includes package add remove and rename
by Simon 19 Dec '13

19 Dec '13

Hi All, before everyone heads off for Christmas / summer / winter breaks, i'd like to give a heads up of some changes coming to openSUSE:factory over the next few weeks we will try to limit breakages however some temporary issues may be unavoidable. Firstly the existing enlightenment package will be removed and replaced with one called e16, this is the only change for e16 users i'll get back to whats happening with the enlightenment package in a little bit. The biggest change will be to the enlightenment foundation libraries (efl) used by e17, e18 and terminology. As of efl 1.8 all the components of the efl with the exception of elementary are shipped as one source tar and are built together as such we have added one new package efl and will be removing the following packages, eina, eet, evas, eio, emotion, efreet, e_dbus, embryo, edje and eeze. As not all the extra modules / themes are available with e18 and because it requires compositing to be enabled we have had some requests to keep e17 around. For now we will be keeping e17 pretty much as is but probably at version 0.17.6 instead of 0.17.3 unless it is found unusable by a number of people, it will also build from the new efl package rather then the older split libraries. Enlightenment e18 will be built in the enlightenment package, this is because upstream have indicated they would like to do a new release at least every year possibly less and i don't want to change the package name that often. I will try and come up with a way for e17.3 in 13.1 to automaticlly update to the new enlightenment e18 package that doesn't ask people who are using e17.6 from 13.2 to update, if someone could help with that it would be great, i don't know how to do it. Previously themes were named e-theme-* and modules e-module-* as themes and modules need to be built against the right version of enlightenment the package naming will change to e17-module-* and e17-theme-* for e17 and enlightenment-module-* and enlightenment-theme-*, e17 users who use terminology will also need both the e17 and enlightenment theme as e18 and later themes are used by the libraries as well Currently we don't plan to keep e18 around when e19 etc come out like we have with e16 and e17. Summary of changes: Stage 1 (Basics): * Add efl * replace existing enlightenment package with e16) Stage 2 (core components) * Update elementary, terminology and e17 to use efl rather then older libs. * add new enlightenment package Stage 3 (everything else) * replace / add modules, themes and branding * update other packages i forgot about. * remove old libraries Almost all the changes have already been made in the X11:Enlightenment:Factory Thanks for your time Simon (Simotek) Maintainer for enlightenment on openSUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] keep services enabled during upgrade
by Olaf Hering 18 Dec '13

18 Dec '13

What is the best way to keep an already enabled sysv runlevel script enabled when the package moves from sysv init scripts to .service files? To me it looks like having the service file listed in the preset-branding files is not enough when doing rpm -Fvh X.rpm. The result is a disabled service if the previous version of X.rpm had an active /etc/init.d/X and the current version has a X.service. I'm forced to run 'systemctrl start X.service' after every reboot. Would at least a "zypper dup" allow that because it sets YAST_IS_RUNNING? Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] New OBS notification mails
by Adrian Schröter 17 Dec '13

17 Dec '13

Hi, coolo and Christopher Hofmann created an initial implementation of notification support in OBS. In the long run we want to obsolete hermes.o.o with that approach in the hope that we can offer * improved email content * in the right situations * and way better direct integration in OBS, without the need to change interfaces. For a smooth migration, we want to enable the emails in OBS next week, while we will also de-register the notifications in hermes at the same point of time. There is also already a very-very first interface in build.opensuse.org where you can configure your notifications already (but it will have no effect until we enable the mail delivery): https://build.opensuse.org/user/notifications We know that the interface is not yet designed under usability aspects, the functionality was our first goal. But an improved interface and more optoins will come for sure. thanks adrian -- Adrian Schroeter email: adrian(a)suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 15

[opensuse-packaging] EXE-File of mono application is not included in OBS generated package
by Dirk Brünig 15 Dec '13

15 Dec '13

Hello I try to packaging the mono application Tracer2Server for openSUSE. https://build.opensuse.org/package/show/home:dBruenig:Tracer2Server/Tracer2… But I still have some issues I don't understand. 1. EXE-File of mono application is not included The generation of i586 package ends with succeeded. But in the RPM file the tracer2server.exe is not included. I don't know way this happens. Because the compilation succeeded (13 warnings). 2. Package generation for x86_64 failed While the generation for i586 succeeded. The generation for x86_64 failed. So where are the difference between these too. I am a newbie in Linux, so please help me to get this working. Regards Dirk -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 8

[opensuse-packaging] OBS storage system problems, home:* areas currently disabled.
by Adrian Schröter 14 Dec '13

14 Dec '13

Hi, due to storage system problem, I am unable to solve atm, I have disabled access to home:* projects binary area. This make the entire system working again at least, but it means you have currently no access to build results of home:* projects. we will fix that asap ... have a nice weekend and grab a Glühwein instead :) adrian -- Adrian Schroeter email: adrian(a)suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] factory-repo-checker and noarch packages
by Jean Delvare 13 Dec '13

13 Dec '13

Hi all, hi Stephan, I am trying to submit quilt to openSUSE:Factory. It gets rejected by factory-repo-checker with the reason: quilt is disabled or does not build against factory. Please fix and resubmit Quilt is enabled against openSUSE_Factory in devel:tools:scm, but only for x86_64. It is a noarch package so I see no reason to waste build resources to build it on more than one architecture. I suspect this is the reason for the reject above. Can we please fix factory-repo-checker so that it is happy with noarch packages as long as they are enabled on at least one architecture and do not fail to build on any architecture? Thanks, -- Jean Delvare Suse L3 Support -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 7

[opensuse-packaging] not dissolubles dependences - oS 13.1 RC 1 - Updates
by Jens 13 Dec '13

13 Dec '13

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

3 9

[opensuse-packaging] d:l:p : drop-in replacement for python-gmp
by denisart benjamin2 11 Dec '13

11 Dec '13

Hello everyone, I wan't to add a package in d:l:p, python-gmp2 which is maintained, and provides more functions like support for MPFR but a drop-in replacement for python-gmp as it provides same libraries name/function. My idea is to upload package and remove python-gmp. Doesit would pose problem to someone ? Regards. Benjamin -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 4

[opensuse-packaging] How to use package from another repo from build?
by Andrey Borzenkov 11 Dec '13

11 Dec '13

Let's say I want to test whether change in one package A will fix build pf package B. I branch both packages: osc branch devel1 A osc branch devel2 B hack A and commit. How can I now build B in home:me:branches:devel2 against package home:me:branches:devel1/A *and* the remaining of original repos, normally used by B? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] Packages failing to link
by Michael Matz 10 Dec '13

10 Dec '13

Hello, the last binutils update broke linking of executables in some packages. E.g. php5. The symptom looks like this: $ gcc -o conftest conftest.c -lc-client -lssl -lpam /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/libc-client.so: undefined reference to `pam_start' So an application linking against some libx (c-client above) needing symbols of liby (libpam above), where libx itself isn't linked against liby. I.e. it's expected that all users of libx need to link against liby themself. This situation _is_ normally okay. Except that the recent binutils (in connection with link with --as-needed which is the default in our build-system) update broke it when those symbols are only provided in a versioned variant (like the pam symbols from libpam.so). There's a work-around, namely explicitely linking against liby when producing libx. Otherwise you'll have to wait for an updated and fixed binutils. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 5

[opensuse-packaging] Ghost (the blogging platform) for openSUSE
by Sascha Manns 09 Dec '13

09 Dec '13

Hello list, actually i'm working on a package which provides Ghost (https://ghost.org/) for openSUSE. My workspace is there: https://ghost.org/ Maybe anyone want's to have a look on this? Specially the init-files aren't my strengh. I'm enjoying your feedback... -- Sincerly yours Sascha Manns (bdvb) openSUSE Packager / Membership team http://saigkill.homelinux.net -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] Fwd: Request 209576: Review wanted
by Stephan Kulow 07 Dec '13

07 Dec '13

Hi, I'm in the process of replacing Hermes mails by built in OBS notifications and to avoid any surprises on your side: here is an example mail in case you want to prepare your mail filters - or have other wishes on their headers (or content). I basically tried to mimic what bugzilla adds in the mail headers. It will be possible to disable notifications in OBS, but we're not sure yet how and when it will be ready. So I will roll this out very slowly :) Greetings, Stephan

4 6

[opensuse-packaging] Base:System/apport upstream update
by Bruno Friedmann 07 Dec '13

07 Dec '13

apport has an upstream update. (from 0.114 to 2.12.7) Lot's of changes there, and I will not be able to maintain it any longer. If you have some python packaging skill and are interested to maintain it, it's the perfect time to stand up :-) Thanks for your attention. -- Bruno Friedmann openSUSE Member GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] request to unlock x11vnc package
by Gábor Nyers 02 Dec '13

02 Dec '13

Hi, I've noticed that the x11vnc package is locked in 13.1 on all architectures and ports. https://build.opensuse.org/package/show/openSUSE:13.1/x11vnc Is it possible to unlock and publish it? Thanks, Gábor -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2

[opensuse-packaging] noarch (sub-)package with ELF files in it
by Andrey Borzenkov 01 Dec '13

01 Dec '13

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

2 1