openSUSE Packaging August 2016

packaging@lists.opensuse.org

37 participants
16 discussions

[opensuse-packaging] release-notes-openSUSE requires google-opensans-fonts

by Felix Miata

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 years

[opensuse-packaging] Fwd: [opensuse-go] building go with go1.4 for openSUSE instead of gcc-go

by Thomas Boerger

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 >

5 years, 7 months

[opensuse-packaging] go* packages failures for Leap 42.2 ppc64le

by Normand

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

5 years, 7 months

[opensuse-packaging] source-urls: github or pypi

by Sebastian

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

5 years, 8 months

Aw: [opensuse-packaging] Re: [opensuse-factory] Use of _service file

by Axel Braun

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

5 years, 8 months

[opensuse-packaging] Automatic Python Provides

by Todd Rme

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

5 years, 8 months

[opensuse-packaging] Python 2 + 3 from single spec

by jan matejek

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.

5 years, 8 months

[opensuse-packaging] E: invalid-license (on Tumbleweed)

by Ferdinand Thiessen

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

5 years, 8 months

[opensuse-packaging] How do you compile the demos in reiser4progs package ?:

by doiggl＠velocitynet.com.au

Hello, How do you compile the demos in reiser4progs package ?: https://build.opensuse.org/package/show/home:doiggl/reiser4progs https://build.opensuse.org/package/view_file/home:doiggl/reiser4progs/reise… - made a osc copy of: # osc copypac filesystems reiser4progs home:doiggl reiser4progs spec:https://build.opensuse.org/package/view_file/home:doiggl/reiser4progs/… applications: dir location: reiser4progs-1.1.0/demos misc.c ls.c stat.c create.c cp.c busy.c log https://build.opensuse.org/build/home:doiggl/openSUSE_13.1/x86_64/reiser4pr… [ 39s] make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/reiser4progs-1.1.0/demos' [ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -D_REENTRANT -D_FILE_OFFSET_BITS=64 -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 -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -c -o busy-misc.o `test -f 'misc.c' || echo './'`misc.c [ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -D_REENTRANT -D_FILE_OFFSET_BITS=64 -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 -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -c -o busy-ls.o `test -f 'ls.c' || echo './'`ls.c [ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -D_REENTRANT -D_FILE_OFFSET_BITS=64 -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 -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -c -o busy-stat.o `test -f 'stat.c' || echo './'`stat.c [ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -D_REENTRANT -D_FILE_OFFSET_BITS=64 -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 -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -c -o busy-create.o `test -f 'create.c' || echo './'`create.c [ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -D_REENTRANT -D_FILE_OFFSET_BITS=64 -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 -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -c -o busy-ln.o `test -f 'ln.c' || echo './'`ln.c [ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -D_REENTRANT -D_FILE_OFFSET_BITS=64 -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 -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -c -o busy-rm.o `test -f 'rm.c' || echo './'`rm.c [ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -D_REENTRANT -D_FILE_OFFSET_BITS=64 -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 -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -c -o busy-cp.o `test -f 'cp.c' || echo './'`cp.c [ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -D_REENTRANT -D_FILE_OFFSET_BITS=64 -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 -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -c -o busy-trunc.o `test -f 'trunc.c' || echo './'`trunc.c [ 39s] gcc -DHAVE_CONFIG_H -I. -I.. -I../include -D_REENTRANT -D_FILE_OFFSET_BITS=64 -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 -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -c -o busy-busy.o `test -f 'busy.c' || echo './'`busy.c [ 39s] /bin/sh ../libtool --tag=CC --mode=link gcc -D_REENTRANT -D_FILE_OFFSET_BITS=64 -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 -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -o busy busy-misc.o busy-ls.o busy-stat.o busy-create.o busy-ln.o busy-rm.o busy-cp.o busy-trunc.o busy-busy.o ../libreiser4/libreiser4.la ../libmisc/libmisc.la -lreadline -lncurses [ 39s] libtool: link: gcc -D_REENTRANT -D_FILE_OFFSET_BITS=64 -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 -fstack-protector -O2 -Wall -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -g -W -Wall -Wuninitialized -Wno-unused-parameter -Wredundant-decls -o .libs/busy busy-misc.o busy-ls.o busy-stat.o busy-create.o busy-ln.o busy-rm.o busy-cp.o busy-trunc.o busy-busy.o ../libreiser4/.libs/libreiser4.so ../libmisc/.libs/libmisc.a -laal -luuid -lreadline -lncurses [ 39s] make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/reiser4progs-1.1.0/demos' [ 39s] make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/reiser4progs-1.1.0' [ 39s] make[2]: Nothing to be done for `all-am'. [ 39s] make[2]: Leaving directory `/home/abuild/rpmbuild/BUILD/reiser4progs-1.1.0' [ 39s] make[1]: Leaving directory `/home/abuild/rpmbuild/BUILD/reiser4progs-1.1.0' [ 39s] + exit 0 I wondered also about a chmod u+x on output file to allow for runable permissions on it ? What spec file alterations needed to allow changes ? Thanks --Glenn -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 years, 8 months

[opensuse-packaging] package names python-python-*

by Michael Ströder

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.

5 years, 8 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging August 2016