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
Morning all,
I'm trying to build the latest version of the Web-Frontend for Tryton (tryton-
sao-4.2.0)
After build I ran into a check-error:
[ 20s] calling /usr/lib/rpm/brp-suse.d/brp-60-hook
[ 20s] calling /usr/lib/rpm/brp-suse.d/brp-65-lib64-linux
[ 20s] calling /usr/lib/rpm/brp-suse.d/brp-72-extract-appdata
[ 21s] Processing files: tryton-sao-4.2.0-0.noarch
[ 21s] error: File must begin with "/": 4
[ 21s] error: File must begin with "/": Contributors
[ 21s] error: File must begin with "/": guide.md
[ 21s] error: File must begin with "/": 4
[ 21s] error: File must begin with "/": Changelog.md
[ 21s] Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.ji0Lee
Anyone an idea what brp-72-extract-appdata is looking for?
Thanks
Axel
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
I propose we remove the SLE 11 repository from devel:languages:python.
Most spec files require special workaround to build at all with this
target and it requires backporting a bunch of system-critical packages
that no other release requires, and even then many packages fail to
build. And the scheduler punishes the repo for having failures.
The amount of effort needed to keep basic, key dependencies working is
growing constantly. And these workarounds means that it will be
essentially infeasible to support it in the upcoming single spec file
system, which means most key packages will no longer be able to
support it anyway.
Anyone who really needs specific packages can always link to them and
build them in their home repo.
So I think we should go ahead and remove it. Once it is removed,
packages that are updated can have the workarounds deleted
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
when building RPMs in OBS, each of them is signed with a private key
that is kept somewhere in the OBS infrastructure.
But it occurred to me, that this might not actually be needed because we
sign repository metadata using the same keys and that metadata contains
hashes of files, so those are already protected against malicious
modification.
Are there tools, processes or people using those sigs on individual rpms?
The background is, that when trying to reproduce a build to verify that
it is bit-by-bit identical to what was published before, we can only
compare parts of it, because the signature and its timestamp will always
be different.
We could try to strip such information that is known-to-vary
but it also has some appeal to get completely identical results.
Ciao
Bernhard M.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi,
I wanted to build gatling in obs.For Tumbleweed it builds. For Leap 42.1
and 42.2 I get errors like this [1]:
[ 48s] dirfd.c:57:62: error: expected ';', ',' or ')' before 'key'
[ 48s] struct dircacheentry** hashtable_lookup(const char* restrict
key,size_t hashval) {
This leads to my conclusion that the C99 keyword restrict [2] is not
recognized for Leap but for Tumbleweed.
Is there a way to build C99 code for Leap?
best regards
Thomas
[1]
https://build.opensuse.org/package/live_build_log/home:Aikhjarto:branches:h…
[2] https://en.wikipedia.org/wiki/Restrict
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello packagers,
we are facing an issue when updating /runc/. It happens that /docker/
requires /runc/, but requires a very specific git commit of it. Thus,
when we packaged a previous version of /docker/ (1.12.1), we did
packaged /runc/ as
/runc-1.0.0+git22222/
(it was not 22222 but the commit, but this is better for explaining it,
see below)
Now, we packaged a new version of /docker/, which requires /runc/ to be
commit 1111, thus we did
/runc-1.0.0+git11111/
However, /zypper/ won't see /1.0.0+git11111/ as an update to
/1.0.0+git22222/, but as a downgrade.
So, how to fix this?
We thought about a solution. Since it is the version required by
/docker/, we could fix this by renaming /runc/ to /docker-runc/, and,
instead of using /1.0.0+git11111/ as a version, use the /docker/ version
(in this case, 1.12.3), thus our package will be
/docker-runc-1.12.3/
or
/runc-docker-1.12.3/
not sure what is semantically better ....
Then, the questions are
*1- Is this a good idea? Have in mind, this is for openSUSE Leap,
openSUSE Factory and also for SLE-12*
*2- Have you had a similar issue with another package? How did you
overcame it?*
*3- Do you have a better idea?*
Here is a link to the bug:
http://bugzilla.opensuse.org/show_bug.cgi?id=1009961
regards
Jordi Massaguer Pla
Hi,
Shamelessly, and possibly rule breaking, using the list to call your
attention to:
https://jobs.suse.com/job/provo/public-cloud-software-engineer/3486/3448533
If you are on this list I assume you enjoy packaging and contributing
patches back to upstream projects. So here is an opportunity to also
contribute to SLE and make a living.
Later,
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
Public Cloud Architect LINUX
rjschwei(a)suse.com
IRC: robjo
Hi, I used to be able to check packages licenses with a license checker
tool, I think it was a part of the rpmdev-tools package, since updating
from 12.1 to Leap:42.1 I can't seem to find it anymore. Is there a tool
to check licenses in package sources available?
Thanks
Dave P
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
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
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