May 2016 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] release-notes-openSUSE requires google-opensans-fonts
by Felix Miata 23 Apr '17

23 Apr '17

TW $SUBJECT can't be right, but trying to zypper rm opensans wants to remove releasenotes. :-( -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- 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] python3 - Symbol PYTHON-NOT-FOUND
by Axel Braun 05 Jun '16

05 Jun '16

Hello, in between I managed to get some python3 packages build. But on Installation I get an error from an unsolved requirement: Requires python < PYTHON-NOT-FOUND python >= PYTHON-NOT-FOUND python python3 python(abi) = 3.4 python3-base .... Anyone seen this before? and knows how I could suppres the requirement? Thanks Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 8

[opensuse-packaging] SuperLU 5.2.1 and CMake: Please review and test
by Christoph Grüninger 02 Jun '16

02 Jun '16

Dear openSuse packagers, I created a merge request for SuperLU to update it to version 5.2.1 and switch to CMake as the build-sytem. I am pretty sure that not everything works now, both packaging-wise and compatiblity-wise. SuperLU 5 changed the signature for dgssvx et al. and packaging relying on SuperLU must be updated. So please help me improving the package by reviewing and testing it. I am not sure whether my merge request should be accepted and we try to fix it in the devel project. SR 398781: https://build.opensuse.org/request/show/398781 My forked and updated package: > https://build.opensuse.org/package/show/home:mathletic:branches:devel:libra… Bye Christoph -- 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] Crash and extensions package versioning
by Petr Tesarik 31 May '16

31 May '16

(Sorry for resend, my auto-complete chose the wrong mailing list and I hit Enter too fast. :-( ) Hi all, I'm wondering how to tackle an issue with the crash utility and its eppic extension. I'd like to build crash-eppic as a subpackage of eppic, because that's where the source code is maintained by upstream these days. The trouble is that crash-eppic is now a subpackage of the crash package, which is at version 7.1.5. There is no versioned release of eppic, but the upstream maintainer told me that the next versioned release would be 4.0, so I can safely use a bogus version of 3.99.$something for the libeppic package. I'm unsure what to do about the version of crash-eppic. If it inherits the version number from eppic, it would be downgraded from 7.1.5 to 3.99.$something. I assume this is a problem for Tumbleweed. If I keep 7.1.5 as the version number, then it's a completely arbitrary one - it would merely indicate the last crash version where the extension was built from the incorrect sources. I could probably change the version if I name the package differently, but "crash-eppic" is in fact the perfect name, as there are other crash extensions named "crash-something". FTR Fedora doesn't seem to package crash extensions... Any ideas are welcome! Petr T P.S. Some background if you want to ask how we ended up in this situation: Originally, the eppic extension was part of the upstream crash tarball. Consequently, crash-eppic was built as a subpackage of the crash package. At some point, upstream development of eppic was split off (see https://github.com/lucchouina/eppic) This repo now contains the library (which is also used by other projects, e.g. makedumpfile) and the crash extension code. -- 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] Services In Update Repo's
by Simon Lees 30 May '16

30 May '16

Hi All, Is it possible to modify osc's service handling to not run certain services in update repo's by default. For example from within an update repo I almost never want to run a source or git service, it seems I accidentally run these on a regular occurrence by accident and I can't think of many cases where I would actually want to do that in a update repo. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

2 2

[opensuse-packaging] how to uninstall a removed package?
by Olaf Hering 23 May '16

23 May '16

What are the options to uninstall a removed package? With SR#390485 the meta pkg "ffmpeg-devel" was removed. There is no package which would be a good place for the usual 'Obsoletes/Provides'. So I wonder how to run the 'zypper rm ffmpeg-devel' during 'zypper dup'. Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 20

[opensuse-packaging] packaging unofficial rubygem version
by Olaf Hering 23 May '16

23 May '16

Current cucumber requires gherkin 3.2, which is tagged on github since a few months. But on rugygems.org the version is still at 3.1.2. As a result plain gem2rpm wont pick it up, and current cucumber can not be installed. What is the workflow to package an inofficial rubygem? gem2rpm --help gives no hints. Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 1

[opensuse-packaging] status 'broken' ?
by Per Jessen 20 May '16

20 May '16

>From "osc results" - what does this mean? openSUSE_Tumbleweed i586 broken openSUSE_Tumbleweed x86_64 broken openSUSE_Leap_42.1 x86_64 broken openSUSE_Factory_images i586 broken openSUSE_Factory_images ppc64p7 * openSUSE_Factory_images aarch64 broken openSUSE_Factory_images armv7l broken openSUSE_Factory_images armv6l broken openSUSE_Factory_images local * openSUSE_Factory_images s390x broken openSUSE_Factory_images ppc64 broken openSUSE_Factory_images ppc broken openSUSE_Factory_images x86_64 broken openSUSE_Factory_images ppc64le broken openSUSE_Factory_PowerPC ppc broken openSUSE_Factory_PowerPC ppc64 broken openSUSE_Factory_PowerPC ppc64le broken openSUSE_Factory_ARM aarch64 broken openSUSE_Factory_ARM armv7l broken openSUSE_Factory x86_64 broken openSUSE_Factory i586 broken openSUSE_13.2 i586 broken openSUSE_13.2 x86_64 broken SLE_12 x86_64 broken SLE_11_SP4 i586 broken SLE_11_SP4 x86_64 broken thanks Per -- Per Jessen, Zürich (13.4°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 8

[opensuse-packaging] Packaging binary SDK libraries (CrossToolchain:xtensa)
by Thomas Zimmermann 18 May '16

18 May '16

Hi, for the https://build.opensuse.org/project/show/CrossToolchain:xtensa I've packaged the SDK for the ESP8266 micro controller. As this SDK is not fully available in source code I've made a download script that downloads the SDK during the installation similar to fetchmsttfonts. The community around this micro controller is now providing more and more open source replacement libraries for the binary ones. But these can't be build without some of the binary libraries. Therefore I would like to change the SDK package so that it actually contains the binary libraries. These binary libraries are distributed under MIT license. Am I allowed to put these binary libraries into the package? The current package can be found here: https://build.opensuse.org/package/ show/CrossToolchain:xtensa/fetch-esp8266-sdk Regards, Thomas -- 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] How to do a library merge?
by Michal Kubecek 18 May '16

18 May '16

I'm trying to submit an upgrade of Firebird RDBMS to version 3.0 and I encountered an issue with other packages depending on its libraries, namely libreoffice. Firebird 2.5 provided two libraries with the same API: libfbclient and libfbembed. The libfbclient library allows to connect to a firebird server (local or remote) via TCP while libfbembed allows a direct access to a database stored in a local file (also called embedded server mode). LibreOffice and some other software use the "embedded server" library to store data in a local database file as a smarter alternative to e.g. sqlite. In openSUSE, we have three devel packages: firebird-devel (with common files, including all header files) libfbclient2-devel (libfbclient.so and fbclient.pc) and libfbembed-devel (libfbembed.so and fbembed.pc). With version 3.0, both access modes are now provided by a single library, libfbclient. I added Provides and Obsoletes for both libfbclient2-devel (the "2" was an old mistake) and libfbembed-devel but that doesn't really help. First, a package linking against -lfbembed won't be really satisfied by libfbclient-devel package. Second, this doesn't resolve build dependency on pkgconfig(fbembed) which libreoffice uses (and an explicit "Provides: pkgconfig(fbembed)" won't help even if it works). One idea is to provide a fbembed.pc file with Libs and Cflags copied from fbclient.pc so that any package using pkgconfig would still build. But that doesn't seem to be a clean solution. It would be nice if one could say "require either libfbclient-devel >= 3 or libfbembed-devel" but I don't think it's possible. Any other ideas? Or is it something that needs to be sorted out in packages depending on libfbembed? Michal Kubeček -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 5