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
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
>
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,
For many (python) packages there are multiple possibilities for the
source URL, e.g. pypi, github, homepage etc. But they all have other
contents.
In many cases, the pypi-archive does not have tests, as opposed to
release-archives from github. Thus personally, I would prefer the
archive with tests over the pypi one.
But as requests with github-URLs get declined[1], I'd like to ask how to
perform the checks?
Probably use both sources, one to build the software, the other one for
the tests?
Sebastian
[1]: https://build.opensuse.org/request/show/420619
--
python programming - mail server - photo - video - https://sebix.at
cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers
Hi,
> Gesendet: Montag, 15. August 2016 um 16:22 Uhr
> Von: "Bjoern Voigt" <bjoernv(a)arcor.de>
> An: opensuse-packaging(a)opensuse.org
> Betreff: [opensuse-packaging] Re: [opensuse-factory] Use of _service file
>
> Axel Braun wrote:
> > _service file is a conveniant way to manage sources for a package
> > automatically: Change the version number in the spec file, and it gets
> > downloaded automatically.
> > Unfortunately this is not allowed in many devel-repos or in Factory. That
> > means additionally I have to provide the source-tarball OR run someting
like
> > osc service localrun download_files
> Personally I think, that _service files provide a slightly better
> security and I wonder, why the a bit more secure solution is forbidden
> in many devel-repos. It's easier to monitor small _service files than
> big tarballs for modifications.
>
> Regardless of the tarball source (upload from a developer or download by
> OBS via _service file), I think, that the tarballs should be verified
> with GPG keys or SHA checksums. This verification is enabled in some
> Factory packages, but not in all.
That makes perfectly sense.
> See the discussion here:
> [opensuse-factory] Build service and checksums for source code archive
> verification
> https://lists.opensuse.org/opensuse-factory/2016-08/msg00213.html
But coming back to the original scope of the mail - why automatic service runs
are not allowed in Factory. I would have expected the whole community of
package maintainers to step-up and grill me.
Except Björn's comment I saw a mail from Oliver
https://lists.opensuse.org/opensuse-factory/2016-08/msg00428.html complaining
basically about the same fact.
So, if we dont have hard reasons to give away this nice feature , why cant we
enable it by default? Or at least, not complain about it in factory?
Cheers
Axel
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Fedora is implementing a system to automatically add reliable,
distro-agnostic provides to their python packages [1]. This
apparently originally came from Mandriva and Mageia, according to the
mailing list discussion [2]. They are also adding macros to make
these easier to use, so you can use the macros to depend on the right
provides automatically.
This seems like something that would make it much easier to handle
python packages in a distro-agnostic manner. The downside is it
requires rebuilding all python packages to work, which may limit its
applicably to previous openSUSE/SLE releases.
What does everything think about implementing this on our end as well?
I am not exactly clear from the discussion what exactly it would
entail.
[1] https://fedoraproject.org/wiki/Changes/Automatic_Provides_for_Python_RPM_Pa…
[2] https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproj…
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
hello folks,
as this got somehow tangled in the big python-python-* thing, I'd like
to announce a working prototype of the new macroset that will let us
easily build Python 2 and Python 3 packages from a single spec file.
Note that this has been possible most of the time, for anyone willing to
manually write two filelists, two descriptions, two sets of
requirements, etc. etc.
But with this new development, it is now possible to run a spec file
through a set of small conversions and get working packages with correct
dependencies (hopefully).
The changes you need to make:
- include `%python_subpackages` macro somewhere in your specfile,
preferably after the `%description` section
- convert `python setup.py build` to `%python_build`
and `python setup.py install` to `%python_install`.
Or copy your python2-specific build instructions and change instances of
python2 to python3 (or vice versa).
- convert all `BuildRequires: python-$something`
to `BuildRequires: %{python_module $something}`
Limitations:
- filelists must be the same. I have not figured out a way to make this
work otherwise, except maybe by forcing the packager to write out both
(all) %files sections by hand, which doesn't seem satisfactory.
- subpackages are not supported just yet. They are on the roadmap.
- no automated handling of update-alternatives, but that's a whole
different story
- i have no idea what happens to packages that don't build with
distutils/setuptools
Anyone interested can have a look at home:matejcik:messing-with-macros
repository [1]. I'll probably use rest of today to fork off
devel:languages:python:singlespec sub-repository and start copying
packages to it. Once a critical mass of packages is there, and unless
there are major objections, I'll go ahead and delete with maximum
prejudice the ill-considered devel:languages:python3 repository which is
a mistake that burdens us to this very day...
It would also be nice to get other distros (by which i really mean
Fedora) in on this. Anyone here knows how to make that happen?
regards
m.
Hi,
When packaging a package for Tumbleweed I get this error:
E: invalid-license (Badness: 100000) LAL-1.2
[ 242s] The specified license string is not recognized. Please refer to
[ 242s] https://spdx.org/licenses/ for the list of known licenses and their exact
[ 242s] spelling.
But according to https://spdx.org/licenses/LAL-1.2.html this should be ok.
spec file content:
%if %{?suse_version} > 1320
License: GPL-2.0+ and LAL-1.2
%else
# Old openSUSE versions do not know LAL-1.2
License: GPL-2.0+ and SUSE-Freeware
%endif
Regards,
Ferdinand
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
HI!
Any reason why so many Python module packages have the misnomer python-python-*
as package names? And the set of this misnomers even grow.
Since ages the convention is that a distribution package name
of a Python module should be "python-<import-name>". This convention is wildly
violated. And it makes authors of cross-platform ansible plays, puppet modules,
chef receipts, etc. even more miserable.
Ciao, Michael.