openSUSE Packaging September 2016

packaging@lists.opensuse.org

19 participants
15 discussions

[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] Missing the obvious - pkgconfig(libyara) not working?
by Greg Freemyer 01 Oct '16

01 Oct '16

I guess I need someone to hit me with a cluestick. I have libyara3-3.5.0 in this package: https://build.opensuse.org/package/show/home:gregfreemyer:Tools-for-forensi… I'm trying to build the python bindings for it in: https://build.opensuse.org/package/show/home:gregfreemyer:Tools-for-forensi… I'm trying to use: BuildRequires: pkgconfig(libyara) = %{version} In the bindings package, but I'm being told "nothing provides pkgconfig(libyara) = 3.5.0" Thanks Greg -- Greg Freemyer Upset at the Hillary/Trump choice So are Utah voters, Evan McMullin is leading there among voters age 25-34 Vote Evan McMullin for President -- 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] packaging for php5 but not php7
by Darin Perusich 30 Sep '16

30 Sep '16

Hello All, I'm packaging a php app which supports php 5.5+ but not php7, what is the best way to set the Requires: in the spec to only php 5.5+? -- Later, Darin -- 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 manage "*.changes" log files for linked projects
by Lee Duncan 30 Sep '16

30 Sep '16

Hi: I maintain several packages in the OBS and in the IBS, and many of them are linked. For example, I am supporting the target-isns package. The newest version of target-isns is 0.6.3 as was updated in Base:system and then in Factory Nov 10 2015 (not by me). So Factory and Base:System have the newest version. But there are several other versions of this package, and they have diverged from each other at different times: Product Version ======== ======================= openSUSE Base:System 0.6.3 openSUSE Factory 0.6.3 openSUSE Leap 42.1 3 commits behind 0.6.3 openSUSE Leap 42.2 1 commit behind 0.6.3 SLES 12 SP1 1 commit behind 0.6.3 SLES 12 SP2 uses SP1 version But the problem is that the "target-isns.changes" files has 4 versions now! There are 3 versions in OBS (for openSUSE) and one other version in IBS (for SLES). On top of this, the new "interlocking" rules seem to require that the version in Leap 42.2 exactly match the version in SLES 12 SP2, including meta-data such as the SPEC file and the *.changes file. My only problem is that I understood there was a rule that the *.changes file for any project be strictly chronological. If that's true, then once two *.changes file diverge, they can never be exactly the same again, as no old entries are ever supposed to be lost. Can anyone help me with this "catch 22"? -- Lee Duncan SUSE Labs -- 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] saving pidfiles
by Sebastian 30 Sep '16

30 Sep '16

Hi, I'm downstream and upstream maintainer of a software which consists of many python modules, which are started individually and are non-root. Previously, we used /opt, but we'd like to drop this now and use LSB-paths. But I'm facing problems with the pidfiles, which should be saved under `/run/name/component.pid`*. But the unprivileged programs can't create the directory or change permissions, so root must do this. I now see these possibilities: 1) Use /opt/name/ - kind of fishy 2) Use /tmp - Better than the solution above and still simple. 3) Saved them somewhere in /var/lib/name, which is writable to the users. 4) Start all components as root, create /run/name if needed and then drop privileges. Has unnecessary complexity in the software, which I'd like to avoid 5) Allow the programs to create the directory /run/name via sudoers Are there other possibilites or best practices? Does systemd has a solution here? Note that units need the pidfiles, not services. I know that systemd can handle the pidfile of the latter. But then I'd again need root to create it. Any ideas are appreciated, Sebastian * as far as I understand non-existing guidelines. But it seems to be handled so by other progams. Some hints that this should be done, can be found here: https://en.opensuse.org/openSUSE:Systemd_services#dnscrypt https://en.opensuse.org/SDB:LXC#Populate_the_container_filesystem https://en.opensuse.org/openSUSE:Packaging_init_scripts#Status_Functions -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers

5 7

[opensuse-packaging] Fwd: [opensuse-go] building go with go1.4 for openSUSE instead of gcc-go
by Thomas Boerger 23 Sep '16

23 Sep '16

Just forwarded this message because it should match also for this mailing list. > Anfang der weitergeleiteten Nachricht: > > Von: Jordi Massaguer Pla <jmassaguerpla(a)suse.de> > Betreff: [opensuse-go] building go with go1.4 for openSUSE instead of gcc-go > Datum: 30. August 2016 17:52:03 MESZ > An: opensuse-go(a)opensuse.org > > Hi, > > I noticed that we are building go with gcc-go for openSUSE Leap and Factory > > See the spec file [1]: > > %if 0%{?suse_version} > 1320 > # openSUSE Factory > %define with_gccgo 1 > %else > %if 0%{?suse_version} == 1315 && 0%{?is_opensuse} > # openSUSE Leap > %define with_gccgo 1 > > According to the go documentation [2], we should use go1.4, except for archs where go1.4 is not available, like ppc64le. > > So I think we should switch to using go1.4, shouldn't we? Or is there anything that I may be missing? > > If we do that, we will have to submit go1.4 to Leap and Factory. > > So, should I create a submit request that makes go build with go1.4? > > regards > > jordi > > [1] https://build.opensuse.org/package/view_file/devel:languages:go/go/go.spec?… > [2] https://golang.org/doc/install/source#go14 > > -- > To unsubscribe, e-mail: opensuse-go+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-go+owner(a)opensuse.org >

2 1

[opensuse-packaging] update-alternatives policies (or lack thereof)
by Todd Rme 21 Sep '16

21 Sep '16

Can we please get some consistent, agreed-upon, publicly-available rules for how update-alternatives should be implemented? In August there was an extensive thread where we were told repeatedly that the --remove part should go in %preun. All the packages I was working with were in %postun, but I changed them all to %preun as I was told. Now, I have had three packages rejected for putting --remove in %preun, telling me it has to go in %postun instead. Assuming this rejection is even correct, I now have dozens of packages where I have to revert the change I was told to make just a few weeks ago. There are no published policies for update-alternatives. All we have to go on is one extremely simple example that doesn't represent the situation of most packages and we are just supposed to figure out how to apply it to our particular situation. Worse, that example uses %postun for one subpackage and %preun for another with no explanation of which we should use under what situations. We really need some specific, detailed rules and guidelines for exactly how we need to implement update-alternatives. Rejecting packages for complying with instructions in the mailing list is a huge waste of everyones' time. -- 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] go* packages failures for Leap 42.2 ppc64le
by Normand 20 Sep '16

20 Sep '16

Hello Marguerite, I am trying to reduce the number of build failure for Leap 42.2 for ppc64le arch, looking specifically for go packages in (1) and (2) I did few build trials in ppc64le guest and identify changes detailed in (3) that raised some actions/questions for Leap 42.2: 1- wait for Leap 42.2 two pending sr (423038, 423063) 2- do we need go-mango-doc to be replaced as per sr 423038 comment ? 3- need to create golang-org-x-crypto in Leap 42.2 <= Do I have to create an osc sr ? 4- need to trigger rebuild of some go* packages for Leap 42.2 ppc64le 5- seems to have a bootstrap problem to build 3 packages for Leap 42.2 ppc64le: golang-org-x-oauth2 depends on golang-google-golangorg-cloud golang-google-golangorg-cloud depends on golang-google-golangorg-api golang-google-golangorg-api depends on golang-org-x-oauth2 * to continue investigation on 5- I am wondering if would be interesting to add Leap 42.2 ppc64le build arch in devel:languages:go project ? what do you think about change in related meta file (4) (1) https://build.opensuse.org/project/monitor/openSUSE:Leap:42.2:Ports?arch_pp… === go failed go-mango-doc failed golang-github-golang-glog failed golang-github-golang-protobuf failed golang-github-shurc...itized_anchor_name failed golang-org-x-text failed === (2) https://build.opensuse.org/project/monitor/openSUSE:Leap:42.2:Ports?arch_pp… === golang-github-cpuguy83-go-md2man unresolvable golang-github-russross-blackfriday unresolvable golang-google-golangorg-api unresolvable golang-google-golangorg-appengine unresolvable golang-google-golangorg-cloud unresolvable golang-org-x-net unresolvable golang-org-x-oauth2 unresolvable golang-org-x-tools unresolvable === (3) === go (1.6.2) need to trigger rebuild in OBS go-mango-doc new osc sr 423038 (update from TW) golang-github-golang-protobuf new osc sr 423063 golang-org-x-text need to trigger rebuild in OBS golang-github-russross-blackfriday has missing golang-org-x-oauth2 failed unresolvable golang-google-golangorg-cloud golang-google-golangorg-cloud unresolvable golang-google-golangorg-api golang-google-golangorg-api unresolvable golang-org-x-net golang-org-x-net mising golang-org-x-crypto golang-org-x-text need to trigger rebuild in OBS golang-org-x-crypto need to be created in Leap 42.2 golang-google-golangorg-api cannot find package "golang.org/x/oauth2" === (4) https://build.opensuse.org/project/meta/devel:languages:go === <repository name="openSUSE_Leap_42.2"> <path project="openSUSE:Leap:42.2" repository="standard"/> <path project="openSUSE:Leap:42.2:Ports" repository="ports"/> <arch>i586</arch> <arch>x86_64</arch> <arch>ppc64le</arch> </repository> === -- Michel Normand -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 8

[opensuse-packaging] Can you fix this error please
by doiggl＠velocitynet.com.au 20 Sep '16

20 Sep '16

Hello, Can you fix this error please ? spec file ? Thanks --Glenn https://build.opensuse.org/package/show/home:doiggl/reiser4progs https://build.opensuse.org/package/view_file/home:doiggl/reiser4progs/reise… Log Shows: https://build.opensuse.org/build/home:doiggl/openSUSE_13.2/x86_64/reiser4pr… [ 51s] gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../include -D_REENTRANT -D_FILE_OFFSET_BITS=no -DENABLE_SYMLINKS -DENABLE_SPECIAL -DENABLE_R5_HASH -DENABLE_FNV1_HASH -DENABLE_RUPASOV_HASH -DENABLE_TEA_HASH -DENABLE_DEG_HASH -DENABLE_LARGE_KEYS -DENABLE_SHORT_KEYS -DENABLE_DOT_O_FIBRE -DENABLE_EXT_1_FIBRE -DENABLE_EXT_3_FIBRE -DENABLE_LEXIC_FIBRE -O3 -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -c oid40.c -fPIC -DPIC -o .libs/liboid40_static_la-oid40.o [ 51s] gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../include -DENABLE_MINIMAL -DENABLE_SYMLINKS -DENABLE_SPECIAL -DENABLE_R5_HASH -falign-jumps=1 -falign-loops=1 -falign-functions=1 -falign-labels=1 -fomit-frame-pointer -fno-inline -fstrength-reduce -DENABLE_LARGE_KEYS -DENABLE_SHORT_KEYS -DENABLE_DOT_O_FIBRE -DENABLE_EXT_1_FIBRE -DENABLE_EXT_3_FIBRE -DENABLE_LEXIC_FIBRE -Os -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -c oid40.c -fPIC -DPIC -o .libs/liboid40_minimal_la-oid40.o [ 51s] gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../include -D_REENTRANT -D_FILE_OFFSET_BITS=no -DENABLE_SYMLINKS -DENABLE_SPECIAL -DENABLE_R5_HASH -DENABLE_FNV1_HASH -DENABLE_RUPASOV_HASH -DENABLE_TEA_HASH -DENABLE_DEG_HASH -DENABLE_LARGE_KEYS -DENABLE_SHORT_KEYS -DENABLE_DOT_O_FIBRE -DENABLE_EXT_1_FIBRE -DENABLE_EXT_3_FIBRE -DENABLE_LEXIC_FIBRE -O3 -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -c oid40_repair.c -fPIC -DPIC -o .libs/liboid40_static_la-oid40_repair.o [ 51s] gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../include -DENABLE_MINIMAL -DENABLE_SYMLINKS -DENABLE_SPECIAL -DENABLE_R5_HASH -falign-jumps=1 -falign-loops=1 -falign-functions=1 -falign-labels=1 -fomit-frame-pointer -fno-inline -fstrength-reduce -DENABLE_LARGE_KEYS -DENABLE_SHORT_KEYS -DENABLE_DOT_O_FIBRE -DENABLE_EXT_1_FIBRE -DENABLE_EXT_3_FIBRE -DENABLE_LEXIC_FIBRE -Os -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -c oid40_repair.c -fPIC -DPIC -o .libs/liboid40_minimal_la-oid40_repair.o [ 51s] oid40.c:206:23: error: static declaration of 'oid40_plug' follows non-static declaration [ 51s] static reiser4_plug_t oid40_plug = { [ 51s] ^ [ 51s] oid40.c:11:23: note: previous declaration of 'oid40_plug' was here [ 51s] extern reiser4_plug_t oid40_plug; [ 51s] ^ [ 51s] Makefile:372: recipe for target 'liboid40_static_la-oid40.lo' failed [ 51s] make[4]: *** [liboid40_static_la-oid40.lo] Error 1 [ 51s] make[4]: *** Waiting for unfinished jobs.... [ 51s] make[4]: Leaving directory '/home/abuild/rpmbuild/BUILD/reiser4progs-1.0.3/plugin/oid/oid40' [ 51s] Makefile:189: recipe for target 'all-recursive' failed [ 51s] make[3]: *** [all-recursive] Error 1 [ 51s] make[3]: Leaving directory '/home/abuild/rpmbuild/BUILD/reiser4progs-1.0.3/plugin/oid' [ 51s] Makefile:387: recipe for target 'all-recursive' failed [ 51s] make[2]: *** [all-recursive] Error 1 [ 51s] make[2]: Leaving directory '/home/abuild/rpmbuild/BUILD/reiser4progs-1.0.3/plugin' [ 51s] Makefile:252: recipe for target 'all-recursive' failed [ 51s] make[1]: *** [all-recursive] Error 1 [ 51s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/reiser4progs-1.0.3' [ 51s] Makefile:178: recipe for target 'all' failed [ 51s] make: *** [all] Error 2 [ 51s] error: Bad exit status from /var/tmp/rpm-tmp.qSf089 (%build) [ 51s] [ 51s] [ 51s] RPM build errors: [ 51s] Bad exit status from /var/tmp/rpm-tmp.qSf089 (%build) [ 51s] [ 51s] lamb09 failed "build reiser4progs.spec" at Tue Sep 20 03:07:58 UTC 2016. [ 51s] [ 51s] ### WATCHDOG MARKER START ### [ 54s] [ 46.195659] SysRq : Power Off [ 54s] [ 46.203759] reboot: Power down [ 54s] ### WATCHDOG MARKER END ### [ 54s] [ 54s] lamb09 failed "build reiser4progs.spec" at Tue Sep 20 03:08:02 UTC 2016. [ 54s] -- 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] Defining a macro if it is NOT yet defined
by Jordi Massaguer Pla 19 Sep '16

19 Sep '16

Hi, I am trying to define a macro unless this is already defined in the project configuration. I am doing this: %{!?go_arches: %define go_arches %ix86 x86_64 aarch64 ppc64le} But the build fails in openSUSE:Factory:Staging:adi:333 where go_arches is not defined. However, if I explicetly define it in the spec file, as in %define go_arches %ix86 x86_64 aarch64 ppc64le the builds success ... so my guess is that I am not really defining go_arches if go_arches is not defined. Does anyone knows how to correctly check that? What am I doing wrong? thanks in advance jordi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging September 2016