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
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
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
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
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#dnscrypthttps://en.opensuse.org/SDB:LXC#Populate_the_container_filesystemhttps://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
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
>
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
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
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