openSUSE Packaging October 2016

packaging@lists.opensuse.org

17 participants
11 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

3 years, 10 months

[opensuse-packaging] python single-spec progress, questions

by jan matejek

hello packagers, i'm happy to announce that i have a macroset that works pretty well, if i say so myself :) Have a look at the d:l:python:singlespec repository [1] and the github repo [2] for details. The gist of it: it is now very possible to build packages for both python 2 and python 3, using a pretty straightforward set of macros. See spec files in the linked repository, and documentation on github. So far this only reliably works on python 2 and 3. It can work with pypy too, but pypy is not building so I can't test against it. Now there is a number of remaining issues to be worked out, and I'd like your feedback on them: 1. Necessary changes to OBS configuration 2. Backwards compatibility 3. Transition to new macros 4. New policies for d:l:py 5. Naming scheme 1. Necessary changes to OBS configuration --- The macro set only works with the one particular repository, that has the macros in its prjconf. In particular, the %python_module macro is problematic, because it needs to be expanded *before* the build starts, by OBS. Usually, we would put the macro definitions inside /etc/rpm/macros.python, as a part of the python/python3/whichever package, but that won't work in this case. Before we can deploy these packages to Factory, either Factory's prjconf, or OBS global config, needs to include at least the %python_module macro. And if possible, I'd like to include all of them, because: 2. Backwards compatibility --- Basically, we would need to build for old distros using new macros. There's a number of options: a) macro definitions in OBS and everything will build everywhere b) macro definitions in python, everything will build with new enough version of python c) macro definitions in prjconf of particular projects (say d:l:py), only packages in those projects build. Personally, i'd go with (a). And if that's not possible, with (b) and (c) combined. The problem with anything other than (a) is that it is going to be difficult to write specs that work both with and without the macros. You could conditionally include the %python_packages macro, but you would have to shim all the others in every spec file, and that is going to be ugly. Which means that by using the new macros, we would be hard-forking the python packages from ALL currently released distributions, unless we could get the macro definitions into them. 3. Transition to new macros --- There is a script called 'process-spec.pl' in the github repo. I'm about to run it first against (some small subset of) python-* in d:l:py, then against python3-* in d:l:py3, and put the results in d:l:py:singlespec:staging. Then it will be necessary to review the packages and submit to d:l:py:singlespec. That's going to be a lot of work, and I would like to ask you to help with this. I'll put up a separate call for volunteers next week. In the meantime, feel free to grab the macro definitions from prjconf and play around. And if you want access rights to d:l:py:singlespec, just send a request. 4. New policies for d:l:py --- If the transition goes smoothly, I'd like to use the opportunity to clean out the devel:languages:python project. One, d:l:py is collecting applications that happen to be *written in* Python, but have nothing to do with python development, and should instead be placed in other topically appropriate projects. We've had some discussions about dependencies only present in d:l:py, but here's a policy proposal: If your package depends on d:l:py and is not appropriate for d:l:py, you can either push your dependencies to Factory, or link them to your topically appropriate project. Two, end-user applications should start to move to Python 3. This is already happening. The relevance here is that we can now build "dual-version" packages. This should be discouraged. There are packages where that is appropriate (pip, nose and similar), but most packages should only provide executables for python3. We have a great number of packages that act as modules (= dependencies for other packages) and also as command-line utilities. Policy proposal: Unless we actually need the executable for all versions of python, all executables should be %py3_only. Finally, three, d:l:py is collecting non-python dependencies of python modules. That should not be happening. Analogously to point one, policy proposal: If your package depends on something that is not appropriate for d:l:py, either get that dependency into Factory, or your package is also not appropriate for d:l:py. How about it? 5. Naming scheme --- Finally some bikeshedding: names of RPM macros for python-related things are inconsistent. We have %py_ver and %py_compile and %python_sitelib and %ifpython2 and %py2_only. I would like to keep "python" and "py" as *generic* versions of the macros, not specifically referring to a particular version or flavor of Python. So for every "py_" and "python_", equivalent "py2_" and "python2_" should be defined. This is partially true in the new macro set already. Another thing is with "short" and "long" versions. I would really prefer to use only one of them, and that's probably the short one. Keep %py_ver and %py2_ver, but make %py2_sitelib etc. The last thing is about executables for pypy. For instance, when installing pip for python2 and python3, you get pip-2.7 and pip-3.5. What should the pypy variant be called? Thoughts, questions, comments? thanks m. [1] https://build.opensuse.org/project/show/devel:languages:python:singlespec [2] https://github.com/openSUSE/multipython-macros

4 years, 3 months

[opensuse-packaging] osc broken?

by sfalken＠cloverleaf-linux.org

Locally, my install of osc seems to be broken, any ideas what python module I'm missing, or what I need to fix here? Running on Tumbleweed osc status Traceback (most recent call last): File "/usr/bin/osc", line 39, in <module> osccli = commandline.Osc() File "/usr/lib/python2.7/site-packages/osc/commandline.py", line 82, in __init__ self._load_plugins() File "/usr/lib/python2.7/site-packages/osc/commandline.py", line 8546, in _load_plugins mod = imp.load_source(modname, os.path.join(plugin_dir, extfile)) IOError: [Errno 2] No such file or directory -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years, 3 months

[opensuse-packaging] Packaging python wheels

by Todd Rme

Currently the primary python-specific way to package compiled Python modules is the "wheel" format [1], which is basically a zip file containing the compiled module with some metadata describing it. Normally, openSUSE disallows using pre-compiled packages. This typically isn't a problem, since python packages are also usually distributed as sources, either in .tar.gz, .zip, or some other similar format, and contain a script (usually setup.py) to build the module. However, some very simple packages, specifically those built using the flit tool [2], only provide wheels. They don't provide any script to install the package, they can only be built from source if flit is already present. However, in those cases, the wheel is composed only of uncompiled python script files (.py files) and metadata. It would conceivably be possible to use flit to build these packages from, for example, github tarballs. However, flit has some serious bootstrapping issues (it depends on packages built using flit), is difficult to install, and it is difficult to get useful files for packaging out of it. So for packages that don't come with their own build script, and whose wheels lack any compiled code, I think it should be allowed to use the wheel for packaging our rpms. What does everyone else think? 1: https://www.python.org/dev/peps/pep-0491/ 2: https://pypi.python.org/pypi/flit -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years, 4 months

[opensuse-packaging] Features list for openSUSE leap 42.2

by Douglas DeMaio

Hi packagers, You all do great work packaging and getting new features into openSUSE. Please consider writing a small or large paragraph for the openSUSE Leap 42.2 features page (https://en.opensuse.org/Archive:Features_42.2) to highlight the packages you submitted for the upcoming release. Once these are complete, the list will replace the https://en.opensuse.org/Features and 42.1 will be archived. You can add new features to the page later if you want, but writing something on the page before the release would help marketing the packages you submitted for the release. v/r Doug -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years, 4 months

[opensuse-packaging] Version-agnostic Qt python dependencies

by Todd Rme

Due to the high degree of API compatibility, a lot of python and python3 packages that use Qt don't care which particular Qt package they get. They work equally well with pyqt4, pyqt5, and pyside. I think that for these packages it would be worthwhile having a generic dependency that could work with any of these packages. Perhaps something like "Provides: python-qt-any" (and a corresponding python 3 package). What does anyone else think? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years, 4 months

[opensuse-packaging] opensuse / SLE conditional logic?

by Greg Freemyer

All, What's the correct way in a spec file to write: %if opensuse/SLE ... %if opensuse ... %if Leap 42.1 or newer (including Factory) ... %endif %endif %endig I've written the below logic, but I don't think is_opensuse is defined in 13.1 / 13.2: ==== %if %{defined suse_version} ... %if 0%{?is_opensuse} ... %if 0%{?suse_version} == 1315 || 0%{?suse_version} > 1320 ... %endif %endif %endif ===== 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

4 years, 4 months

[opensuse-packaging] drupal and update from v6.12 to v8.2.0 specfile help wanted

by doiggl＠velocitynet.com.au

Hello, I used the package from [1] drupal and to update from v6.12 to v8.2.0 , but the compile/spec fails Can anyone have a look at the .spec and list changes so the v8.2.0 builds. log: [ 99s] + cp -pr CHANGELOG.txt /home/abuild/rpmbuild/BUILDROOT/drupal-8.2.0-4.1.i386/usr/share/doc/packages/drupal [ 99s] cp: cannot stat 'CHANGELOG.txt': No such file or directory [ 99s] error: Bad exit status from /var/tmp/rpm-tmp.xzIVLB (%doc) [ 105s] Processing files: drupal-8.2.0-4.1.noarch [ 105s] warning: File not found: /home/abuild/rpmbuild/BUILDROOT/drupal-8.2.0-4.1.x86_64/usr/share/drupal/CHANGELOG.txt [ 105s] warning: File not found by glob: /home/abuild/rpmbuild/BUILDROOT/drupal-8.2.0-4.1.x86_64/usr/share/drupal/INSTALL* [ 105s] warning: File not found: /home/abuild/rpmbuild/BUILDROOT/drupal-8.2.0-4.1.x86_64/usr/share/drupal/MAINTAINERS.txt [ 105s] warning: File not found: /home/abuild/rpmbuild/BUILDROOT/drupal-8.2.0-4.1.x86_64/usr/share/drupal/UPGRADE.txt [ 105s] error: File not found: /home/abuild/rpmbuild/BUILDROOT/drupal-8.2.0-4.1.x86_64/etc/drupal/all [ 105s] warning: File not found: /home/abuild/rpmbuild/BUILDROOT/drupal-8.2.0-4.1.x86_64/etc/drupal/all/README.txt [ 105s] Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.FWAqPL [ 105s] + umask 022 [ 105s] + cd /home/abuild/rpmbuild/BUILD [ 105s] + cd drupal-8.2.0 Thanks --Glenn # osc copypac home:jbrockmeier drupal home:doiggl drupal [1] https://build.opensuse.org/package/show/home:jbrockmeier/drupal [2] https://build.opensuse.org/package/show/home:doiggl/drupal [3] https://build.opensuse.org/build/home:doiggl/openSUSE_13.1/x86_64/drupal/_l… [4] https://build.opensuse.org/package/view_file/home:doiggl/drupal/drupal.spec… # osc home:jbrockmeier > drupal osc copypac home:jbrockmeier drupal home:doiggl drupal # -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years, 4 months

[opensuse-packaging] Can drupal be packaged up -its at version 8.1.10

by doiggl＠velocitynet.com.au

Hello, Can drupal be packaged up -its at version 8.1.10 https://www.drupal.org/download https://www.drupal.org/project/drupal/releases/8.1.10 Thanks --Glenn post link to built rpms/package -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years, 4 months

[opensuse-packaging] update kernel-source to linux-4.8.tar.xz

by doiggl＠velocitynet.com.au

yi, update kernel-source to linux-4.8.tar.xz https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.8.tar.xz from: https://build.opensuse.org/package/show/Kernel:vanilla/kernel-source linux-4.8-rc8-37-gf51fdff.tar.xz --Glenn -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 years, 4 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging October 2016