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