openSUSE Packaging April 2020

packaging@lists.opensuse.org

33 participants
16 discussions

[opensuse-packaging] How to handle -doc packages?

by Ludwig Nussel

Hi, Some packages split out their man pages or other documentation into a sub package. More often than not that subpackage then is recommended. IOW installed by default which is undesirable. We also have a pattern for documenation though. So IMO it makes sense to link installing such documenation packages to the pattern. The question is how though. Assuming we have foo, foo-doc and patterns-base-documentation I see several ways: 1. pattern is in charge a. in patterns-base-documentation Recommends: foo-doc b. in patterns-base-documentation Recommends: foo-doc if foo 2. package is in charge a. in foo Recommends: foo-doc if patterns-base-documentation b. in foo-doc Supplements: packageand(foo:patterns-base-documentation) 1) pro: when looking at the pattern eg. in YaST one can actually see an overview of what documentation is available. con: pattern needs to be adjusted for every change in packaging. Extra step and easy to forget. 2) pro: packager can add, split, merge or drop packages any time con: package installation is a bit more black magic. The pattern leads to pulling in more packages than expected. Thoughts? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year

[opensuse-packaging] factory_auto declines package with commented out patch

by Atri Bhattacharya

Hi, It seems factory_auto declines packages where a patch needing to be rebased is commented out from the sources entirely, yet this is the only way to avoid applying the patch when using `%autosetup`. See, for example, sr#773323 which has Patch12 marked as 'NEEDS-REBASE' and commented out. It has been duly declined. Is there any way, short of doing away with `%autosetup`, to get this through factory_auto? Thanks for any advice. [1] https://build.opensuse.org/request/show/773323 -- Atri Bhattacharya Sent from openSUSE Tumbleweed 20200214 on tp-yoga260. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 2 months

[opensuse-packaging] packaging qt5 Application

by Axel Braun

Hi, by chance I stumbled over https://build.opensuse.org/package/show/hardware/fingerprint-gui which is a GUI to manage fingerprint scanners. Unfortunately it does not build for TW anymore. I found a port for qt5 https://github.com/Tilka/fingerprint-gui and tried to build this on OBS for Leap 15.1 first, but as I have basically no packaging skills for qt applications, the result was .... suboptimal :-) (And, I could not find any documentation on qt macros in https://en.opensuse.org/Portal:Packaging ) If anyone wants to support during boring hours in home-office ;-) : https://build.opensuse.org/package/show/home:DocB:branches:hardware/ fingerprint-gui Thanks! Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 3 months

[opensuse-packaging] Fwd: Fwd: Can I get commit permission for github opensuse fcoe-utils?

by Lee Duncan

Try 3? Can anyone help? -------- Forwarded Message -------- Subject: Fwd: Can I get commit permission for github opensuse fcoe-utils? Date: Wed, 22 Apr 2020 08:47:00 -0700 From: Lee Duncan <lduncan(a)suse.com> To: opensuse-project(a)opensuse.org Hi: I sent this to Adrian Schroter, but perhaps this is the better email address? (Since I haven't heard back from Adrian.) -------- Forwarded Message -------- Subject: Can I get commit permission for github opensuse fcoe-utils? Date: Tue, 21 Apr 2020 10:18:18 -0700 From: Lee Duncan <lduncan(a)suse.com> To: Adrian Schröter <adrian(a)suse.de> CC: Hannes Reinecke <hare(a)suse.de>, Martin Wilck <mwilck(a)suse.com> Hi: Hannes suggested you might be able to help me with this request. If you are not the right person, please let me know. I am taking over the fcoe-util package from Johannes Thumshim, who left SUSE. Johannes was nice enough to move his repo to the openSUSE organization on github. He granted access to the openSUSE "storage" group, of which he's a member, as well as myself, Hannes, and Martin. But none of us seem to have commit (write) permission to this new-to-openSUSE fcoe-utils package, and I need that permission. Can you grant me that permission for this repo, or in general for any repo that the "storage" team owns? Thank you. -- Lee Duncan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 3 months

[opensuse-packaging] build.opensuse.org scheduling issues?

by Mathias Homann

Hi guys, something's a bit off on OBS, I have builds sitting since 10AM UTC, but repositories are not being created... What's going on? Cheers MH -- Mathias Homann Mathias.Homann(a)openSUSE.org Jabber (XMPP): lemmy(a)tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 3 months

[opensuse-packaging] OSL fails to compile on Tumbleweed

by Hans-Peter Jansen

Dear Stefan, Factory fails to compile OSL 1.10.7 due to some LLVM issues on the surface: https://build.opensuse.org/package/show/graphics/OpenShadingLanguage Well, I updated to 1.10.9, removed your patch, that was applied upstream (well the alternative one at least), and tried a couple of combinations here: https://build.opensuse.org/package/show/home:frispete:blender/ OpenShadingLanguage using a pattern similar to: %if 0%{?suse_version} > 1500 BuildRequires: clang7-devel BuildRequires: gcc7-c++ %else BuildRequires: clang-devel >= 4 BuildRequires: gcc-c++ %endif Interestingly, no combination of LLVM 10, 9, 8 nor gcc7 does work, but the build is failing due to various issues (up to some unsupported -flto=auto arguments). This bears the question, does our TW build chain or some library, that OSL relies on has an issue here? OIIO seems pretty outdated, we are using 1.8.17, while upstream is at 2.1.13.0 now. Any reason, why we lagged behind so far? Thanks, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 3 months

[opensuse-packaging] Corana side effects for SuSE packaging

by Christian

Hi, nowadays there are strage side effects for SuSE packaging (new rules???): ### comment abouts declining a Submit Request ### - "update to 0.95.9" Upper case please. Same for 'rebase' etc... - You should use upper case for the first word. Not "update to 0.95.9" but "Update to 0.95.9". Are you SUSE guys _serious_ ??? Is this the way you encourage community to do volunteer work and deny their effort ? I hope not ... thanks -- Christian ------------------------------------------------------------ https://join.worldcommunitygrid.org?recruiterId=177038 ------------------------------------------------------------ http://www.sc24.de - Sportbekleidung ------------------------------------------------------------

1 year, 3 months

[opensuse-packaging] Lots of problems with Licence strings in SLE_15_SP1

by Detlef Steuer

Hi all! Starting sometime ago I see lots of failed builds due to license strings not valid for exactly SLE_15_SP1, giving no problems whatever for other releases, especially not Leap_15.2. I'm talking about devel:languages:R:released, where a lot of packages from CRAN are (semi-)automatically built. One such package is R-acepack. The spec file says: License: MIT + file LICENSE On CRAN that seems popular and up to now we had no problems with that. Most of the failing packages use exactly this license. The authors use a blank MIT license and add a file with just the copyright holders names etc. What is the intended reaction as a packager? I would like to keep the License specified as intended by upstream. Essentially this is MIT, so it should definitely be ok for OBS. Of course (?) there is no such entry in https://spdx.org/licenses/ Thx for any hints. Detlef -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 3 months

[opensuse-packaging] armv7hl gnueabi vs. gnueabihf

by Olaf Hering

The gccN.spec has the following lines: %if "%{TARGET_ARCH}" == "armv7hl" --with-arch=armv7-a \ --with-tune=cortex-a15 \ --with-float=hard \ --with-abi=aapcs-linux \ --with-fpu=vfpv3-d16 \ --disable-sjlj-exceptions \ %endif The rpm %configure macro runs "./configure --host=armv7hl-suse-linux-gnueabi --build=armv7hl-suse-linux-gnueabi". Also gccN.spec uses the 'gnueabi' suffix despite "--with-float=hard". In OCaml github issue #9431 it turned out third party software relies on a correct --build= value to produce correct binaries. Why do our armv7 builds use 'gnueabi' instead of 'gnueabihf' to indicate that hard floating point is the default? Olaf

1 year, 3 months

[opensuse-packaging] Weird "undefined reference" only for TW x64

by Pierre

Dear all, First of all, a disclaimer, I am NOT a dev and I'm only packaging a few things when I need them on different computers or when I feel it could benefit other people than me (mainly sciency stuff). I've been trying to build a software that performs population genetics simulation: https://build.opensuse.org/package/show/home:flyos:science/Nemo The software has little dependencies and should be relatively easy to build, but I needed to switch the Makefile to g++-7 on my TW install, otherwise it fails. It also fails on OBS, but only on Tumbleweed x64 (succeeded on the 32bit version ?!). Here's the error when it fails: /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: src/ttbdmi.o: in function `TT_BDMI::store_data(BinaryStorageBuffer*)': ttbdmi.cc:(.text+0x421): undefined reference to `BinaryStorageBuffer::store(void*, unsigned int)' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ttbdmi.cc:(.text+0x46e): undefined reference to `BinaryStorageBuffer::store(void*, unsigned int)' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ttbdmi.cc:(.text+0x48b): undefined reference to `BinaryStorageBuffer::store(void*, unsigned int)' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ttbdmi.cc:(.text+0x4a8): undefined reference to `BinaryStorageBuffer::store(void*, unsigned int)' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: ttbdmi.cc:(.text+0x4c5): undefined reference to `BinaryStorageBuffer::store(void*, unsigned int)' /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: src/ttbdmi.o:ttbdmi.cc:(.text+0x4e2): more undefined references to `BinaryStorageBuffer::store(void*, unsigned int)' follow I don't understand why the "undefined reference" is coming up here (binarystoragebuffer.cc has been compiled into an .o object and should link without a problem?), and why it would depend on the arch and version of GCC... At least out of curiosity, if anybody has an idea of what is going on here, I would appreciate any help! Cheers, Pierre. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 year, 3 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging April 2020