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
Hi,
during upgrade to 42.2 I found a small dependency problem which is not
resolved correctly with zypper (in my opinion) but probably I missed
something. (Someone else just reported the same symptom in bugzilla but
closed it again because he fixed it manually.)
Hygiea:~ # rpm -q --recommends MozillaFirefox | grep avcodec
libavcodec-full >= 0.10.16
Hygiea:~ # zypper search -s --provides libavcodec-full
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
S | Name | Typ | Version | Arch | Repository
--+--------------+-------+------------+--------+-----------------------------
i | libavcodec56 | Paket | 2.8.8-24.1 | x86_64 | openSUSE-42.2-0
v | libavcodec56 | Paket | 2.8.8-25.2 | x86_64 | Packman repository
(Factory)
v | libavcodec57 | Paket | 3.2-4.1 | x86_64 |
openSUSE-Leap-42.2-Update
v | libavcodec57 | Paket | 3.1.3-2.1 | x86_64 | openSUSE-42.2-0
i | libavcodec57 | Paket | 3.2-6.2 | x86_64 | Packman repository
(Factory)
I think here is the problem. This output suggests that both variants for
those package (openSUSE and packman) provide that.
But this is not the case as can be seen here:
Hygiea:~ # rpm -q --whatprovides libavcodec-full
libavcodec57-3.2-6.2.x86_64
Therefore this is a typical upgrade problem when the upgrade is
performed via dup and non-official repos turned off which I would
consider best practice but even if the packman repo is enabled again the
recommended package is not automatically being pulled.
Is this a dependency resolving bug in libzypp or did I miss something?
Wolfgang
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
A few packages have "Requires: boost-devel" in their -devel subpackage.
This leads to unresolved dependencies like this:
have choice for boost-devel needed by whatever-devel: boost_1_58_0-devel boost-devel
This happens only in Leap 42.1 and 42.2. How is boost supposed to be
used? If there are indeed two packages providing the same thing within a
prj, then this base prj must add the relevant Prefer:.
And for some reason this started to happen only recently, the last
successful build is from 2016-12-02.
Olaf
Hi,
I'm new to packaging and to Go and I'm working on packaging the
amazon-ssm-agent (https://github.com/aws/amazon-ssm-agent). Using
version 1.2.290.0 on GitHub yields multiple vendor issues which seem to
be caused by the package structure, but I could very likely be doing
something wrong.
I'm using the spec file provided in the codebase,
https://github.com/aws/amazon-ssm-agent/blob/master/packaging/amazon-linux/…,
as an example to build the spec for SUSE. On "go build" an error is
produced:
imports github.com/aws/aws-sdk-go/vendor/github.com/go-ini/ini: use of
vendored package not allowed
To resolve this I removed the vendor directory from aws-sdk-go as both
dependencies exist in the amazon-ssm-agent vendor directory. Is this the
correct resolution for this issue?
Now it produces another error:
imports github.com/aws/aws-sdk-go/vendor/github.com/go-ini/ini: must be
imported as github.com/go-ini/ini
Searching the code base all imports for go-ini are imported as
github.com/go-ini/ini so I'm confused what this error is hinting to.
Does this mean go cannot find the dependency in the proper vendor
directory (amazon-ssm-agent/vendor/...)?
The final thing I noticed with this package is that vendor has an extra
src directory which doesn't match the Go documentation.
(amazon-ssm-agent/vendor/src/github.com rather than
amazon-ssm-agent/vendor/github.com)
I removed the src directory from the tree and attempted to re-build but
it yields the same error. My thinking is that go looks for the
dependencies at vendor/github.com/... and thus the extra directory
prevents all dependencies from being resolved. Is this assumption
correct or am I missing something here?
Sorry for the extensive email I hope it makes some sense and thanks in
advance for any help and/or knowledge you can share.
Cheers!
--
Sean Marlow
Public Cloud Developer
sean.marlow(a)suse.com
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
After a (too) long time, I was able to rework netfilter:shorewall package.
Yes I can accept myself my SR, but as it should goes afterward to Factory,
I'm willing to have at least one second pair of eyes to detect big mistakes if
any.
https://build.opensuse.org/request/show/444768
I've cleanup to all non openSUSE target, and also all %if for older version.
I've tested myself the package and everything seems to goes at I was
expecting.
Thanks for your help.
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch
Bareos Partner, openSUSE Member, fsfe fellowship
GPG KEY : D5C9B751C4653227
irc: tigerfoot
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello packagers,
this is a progress report on the singlespec project. I also have some
things to discuss. These are way down in the e-mail, under a heading. If
you don't want to read all of it, please at least scroll down to the
"Remaining issues" section.
1. Changes from last time
-------------------------
In the last month, I've made a number of significant improvements to the
macro set.
1.1 Backwards compatibility
This one is the biggest: we can now build new-style packages in old
distributions without any prjconf changes.
The trick consists of two parts:
- placing the macro definitions in a separate python-rpm-macros package,
which is then buildrequired. You can simply link the package to your
project, or we might push it into SLE/Leap build base.
- shimming the %python_module definition in the spec file. Since the
main purpose of this macro is to avoid repetitive listing of
buildrequires, we can conditionally define it to expand to "python-$1
python3-$1" -- or, if needed, just "python-$1" -- and this will do the
necessary work.
The d:l:py:singlespec repository now builds packages for all distros
from 13.2 up.
In principle, nothing is stopping us from supporting SLE11 too, but with
all the other compatibility requirements, I consider it not worth the
effort.
This also means that you can now easily build singlespec packages in
your own repository. Just link python-rpm-macros from d:l:py:Factory.
1.2 Macro naming
Naming is now very much unified. Every macro name is prefixed with the
"flavor" name, which is the name of the binary in /usr/bin. That means
no short versions: %python2_version, %python3_version. If we ever add,
say, Jython, it's going to get %jython3_version.
Some short versions are retained as compatibility spellings, namely
"%py_ver". I have, however, dropped the old macro set "%py_sitedir,
%py_incdir" etc. I don't think they are used anywhere; if they are, we
will find out soon enough.
1.3 Fedora compatibility
I have based some macro definitions on Fedora [1]. I claim _partial_
compatibility: we don't have macros for wheels and eggs. They look
simple enough that I'll probably add them.
I also didn't copy SRPM macros, because I have no idea what they are
good for. If some Fedora people want me to include them, please explain :)
As stated above, the primary spelling of all macros is with long names:
%py2_compile in SUSE will be an alias for %python2_compile. The latter
is the preferred spelling.
[1] http://pkgs.fedoraproject.org/cgit/rpms/python-rpm-macros.git/tree/
1.4 Package naming
You can name your package anything (usual scenario is "python-foo"). In
older distros, the result will be python-foo, python3-foo (and possibly
pypy3-foo).
In newer distros (as soon as I submit the new Python 2 package that
Provides "python2-*" symbols), the result will be python2-foo,
python3-foo and an empty package python-foo.
I don't think I can get rid of the empty package, but the python2-foo
packages are created with obsoletes/provides on the name.
In order to accomplish this trick, if your package is called
"python-foo", you have to decorate all %files sections: "%files
%python_files", or "%files %{python_files subpkg}". The build will fail
if it detects an undecorated %files section.
This is not necessary if your top-level package is called "python2-foo",
"python3-foo" or anything else.
1.5 %pycache_only
In addition to %ifpython2, %ifpython3 etc, I have added a %ifpycache
section and a corresponding %pycache_only marker. This is equivalent to
"if not python2", and is applicable for flavors that use the
"__pycache__" directory to store .pyc files.
1.6 %python_expand
This macro will repeat its arguments for every flavor, replacing
"$python" with the flavor name.
For example:
%{python_expand cp command-%$python_bin_suffix
%{buildroot}%{$python_sitelib}/foomodule/command}
I'm still not sure if this is a good idea -- after all, it's introducing
a minilanguage specific to Python packages.
But it sure is useful.
2. Remaining issues
-------------------
New-style packages, "python2-foo", rely on presence of prjconf-based
definition of %python_modules. Before we can submit packages to Factory,
we need to get the definitions there. This should pose no problem, however.
In two packages now I have run into a situation where I want to create a
subpackage that is _not_ automatically replicated. In the first case,
python-pycparser has some data that can be shared between the versions;
in the second, for python-Sphinx, i want to create a subpackage for the
binaries that has a dependency only on the Python 3 version.
Both cases can be solved in a different way, however, the need for
non-replicated looks like an important feature.
How to implement it?
One idea is to not replicate any %package -n something. Subpackages of
this type are currently buggy, changing the bugginess to straight out
ignoring is easy enough :) And conversely, it is unclear how to
replicate packages of this kind anyway, so declaring them to be
non-replicating is sort of natural.
Another option is to delineate packages by a macro, say,
%python_noreplicate.
What do you think?
Requires, Suggests and Recommends are copied from the main package
declaration and changed to match the python flavor. It is somewhat
unclear what to do about Provides and Obsoletes.
They should probably be handled similarly, except the autoconverter
should wrap them in %python2_only by default.
On a related note, the %ifpython2 and %python2_only macros were
originally intended for use both in Requires and %files. However, with
the new style packages, python-foo.spec generating python2-foo.rpm and
empty python-foo.rpm, this will have some flaws.
Namely the requires/provides will be the same in the empty python-foo as
in the correct python2-foo. I foresee this causing problems: "have
choice for python-provided-symbol: python-foo python2-foo".
There is a number of solutions:
1. I can hack %python2_only to work properly, and invent an alternate
spelling for %ifpython2. Maybe %ifpython2_requires? I can then detect
whether the correct spelling is used and halt the build if it is not.
I don't like this too much, for obvious reasons :)
2. I can detect said macros and halt build without alternative, forcing
the packager to rename the whole package to python2-foo or python3-foo,
which would sidestep the problem.
3. I can simply not care and let the empty package have the same
obsoletes/provides. This would be great if we could cripple the empty
package in some other way. Introduce an unsatisfiable requirement?
"Requires: this-does-not-exist" or "Conflicts: aaa_base"? Would this
help zypper resolve the choice?
Is there a different option for saying "this package should always be
preferred" from within the package? "Prefer: python2-foo" but within the
spec?
Unsatisfiable requirement for the empty package would be a good idea in
any case, to make sure the empty packages don't sneak into the
distribution and on people's computers.
As usual, i'll be glad for all your input, answer questions, etc. etc.
regards
m.
Hi,
we reached again new load levels on OBS and need to split
again our main backend servers.
This will happen on coming sunday and will most likely
continue on monday.
What will be affected exactly?
* build.opensuse.org will stay and reachable
* all content on download.opensuse.org will stay
* source changes, requests will remain work
* schedulers for main projects will get stopped.
=> new builds will not start, except for home:*
and openSUSE staging projects.
The builds will get triggered automatically
when we boot the schedulers again.
* projects outside of openSUSE and home namespace may show
an old build state for some time until the final sync
has finished.
* home:* and openSUSE Staging projects will remain to work
all the time, including building and publishing.
The reward will be more IO throughput later one, which
means faster scheduling and publishing :)
--
Adrian Schroeter
email: adrian(a)suse.de
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5
90409 Nürnberg
Germany
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
