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, friends,
Last month I saw some posts in this list complaining that our
devel:languages:go is not packager friendly, eg, we don't have
"golang(google.golang.org/cloud/compute/metadata)" style
BuildRequires, and package names are not intuitive (not following
golang's importpath so when an error about importpath occurs, packager
don't know which package provides it)
So I coded.
https://github.com/marguerite/golang-packaging
devel:languages:go/golang-packaging
This is inspired by the logic behind the nodejs-packaging packge in
devel:languages:nodejs. nodejs-packaging is developed by Fedora/RedHat
package maintainers, using the brand-new system RPM 4.9 provides:
http://www.rpm.org/wiki/PackagerDocs/DependencyGenerator
Basically it has two parts:
* matching rule
* scripts to generate Provides/Requires
When a RPM is being built, if file will install to the dir that
mentioned by the regex matching rule, the self-maintained scripts will
be called and the generated Provides/Requires will be attached along
with the regular Provides/Requires.
So I wrote two scripts:
1. golang.prov will extract importpath from specfile:
"%define importpath xxx" > "%goprep xxx" > URL: xxx
and all the sub-directories in
/home/abuild/rpmbuild/BUILD/gocloud-%{version}(this is detected by
"Source" tag), that is because both "google.golang.org/cloud" and
"google.golang.org/cloud/compute/metadata" are valid importpaths in
golang.
2. golang.req will extract such lines from all *.go files (except for
those .go files inside examples/test directory and *_test.go files,
because examples/tests are useless in production environment, with the
imports inside them):
* import "xxx"
* import {
xxx
"xxx"
}
* import xx "xxx"
these lines can actually be treated as golang's "include" or
build/runtime Requires. and generate such golang() Requires.
So if you're a golang packager, now you can just "BuildRequires:
golang-packaging" and let my scripts to handle Provides/Requires for
you automatically. with this, you can also "BuildRequires:
golang(xxx)" for packages built with golang-packaging.
Additional information:
1. If there're unneeded importpath in examples/tests, just leave them
there, my package will skip them. If such importpath resides in main
.go source codes, "%go_strip_builddep xx" in %prep step can help you
strip them manually.
2. there's one shortcoming, the same as the one for nodejs-packaging:
The build "success" status for a package doesn't mean the package can
be installed without any problem. Because there might be non-fulfilled
Requires for the package, remember to check it again using page like
this:
https://build.opensuse.org/package/binary/devel:languages:go/golang-org-x-t…
As to package renames:
I just follow the Fedora style: golang + importpath like string, eg:
golang-github-golang-glog refers to github.com/golang/glog. basically
importpath with ".org/.net/.com" will be okay with my package. You can
refer to the golang-* packages I recently send to devel:languages:go
as examples.
Welcome to help golang package renaming and contribute to my package :-)
Marguerite
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello,
I came along two issues recently where symbols from C++ class libraries
which were provided by specific software package versions did not fit
together temporarily.
Combinations:
* libmodman1 / libproxy1
https://bugzilla.opensuse.org/show_bug.cgi?id=937157#c5
* yast2-core / libyui6
https://bugzilla.suse.com/show_bug.cgi?id=937665#c2
How are the chances that such name mangling changes because of
application binary interface adjustments will trigger appropriate
updates automatically?
Do dependency descriptions need any more fine-tuning for corresponding
RPM specifications?
Regards,
Markus
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello,
how do I force a specific Lua version as build requirement
independently of the used openSUSE version?
In Tumbleweed, 13.2, etc. the Lua package contains version 5.2. In
Factory the Lua package provides version 5.3. However, the programm I
want to package needs version 5.2. Using
------
BuildRequires: lua
BuildRequires: lua-devel
------
works for Tumbleweed, 13.2, etc. but not for Factory. In contrast
------
BuildRequires: lua52
BuildRequires: lua52-devel
------
works only with Factory because these package are not available in the
other openSUSE versions.
I first tried to distinguish between Factory and Tumbleweed but that
seems to be impossible. Is that correct? I also tried to query the Lua
version but since subshell expansions don't work in OBS for
BuildRequires (see
https://en.opensuse.org/openSUSE:Specfile_guidelines#OBS_Caveat) I was
not successful. My solution is now to use lua52 and lua52-devel as build
requirements and to include the repository devel:languages:lua to
Tumbleweed, 13.2, etc. to have packages with that name. This seems to
work (see
https://build.opensuse.org/package/show/home:greenbasilisk:branches:graphic…)
but I don't know if that is an appropriate solution.
Heinz
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hi, all,
As you may noticed, npm has been splitted from nodejs main package
since openSUSE 13.2.
If I remembered correctly, the reason of the split given was: to get
the latest updated npm.
But now it has been proved that the split is a total failure.
It not only increased the possibility of a broken npm in
openSUSE:Factory but also increased the difficulty to maintain npm.
And it can not even guarantee a latest updated npm at all.
Let me explain the situation now:
0. If npm is built from the nodejs package, we only need to maintain
one package. If npm is splitted as it is now, we have to maintain
about 40 packages and their dependencies, it is about 100+ packages as
I counted.
1. nodejs-packaging is not a tool good for aggegation. eg: if you just
build one package, you can check its dependencies found by
nodejs-packaging through the OBS website; but if you're going to build
100 of such packages, it's very very time-consuming for you to do that
one by one.
And there's no way to have all the dependencies and sub-dependencies
at one time, the only similar tool existed is "npm shrinkwrap", but it
requires the latest npm installed first, or it can only give the
all-in-one dependecy map of the old installed npm.
2. And even this tool has conflicts with nodejs-packaging. "npm
install npm" will always installs a npm. But actually nodejs's
dependency checking is not as strict as nodejs-packaging. so even if
you update the packages based on "npm shrinkwrap" (I don't want to
mention the funny stuff like you want to update npm you have to have
an updated npm installed first), nodejs-packaging will still triggers
a lot of conflicts. Many of them are actually not resolveable at all,
eg: package A needs 0.8 version of package C, but package B needs 1.2
version of package C, package A and B are both dependencies for npm.
what should be done now? As a maintainer you have to read the git
commit logs of package C to see what happened between 0.8 and 1.2, to
see if it is safe to bump/downgrade version for A or B. If you're
lucky enough, it can be done no matter how painful it is. But if
you're not so lucky, you have to provide both 0.8 and 1.2 version,
that comes update-alternatives (which is questionable because in this
case 0.8 and 1.2 will be installed both, what if a file from 0.8 is
used with other files from 1.2? is it safe? no one knows).
3. nodejs-packaging's check result is not shown to you unless you
submit all packages to openSUSE:Factory. This means npm will be always
broken in devel:languages:nodejs because no one knows which package is
a dependency for npm and remember not to touch it! So if you accept a
single request to update a package, it is very likely that the whole
npm chain breaks.
Even if the results are shown to you now, you can't be sure factory
maintainers accepts your requests at the same time. That means npm in
Factory is very likely to break.
And as we introduced staging projects, a single request accepts much
faster than 100+ requests.
4. Actually the person who proposed the split never maintain npm after
2 or 3 submits. And 100+ packages really need lots of manpower. If I
want to update npm today, I can finish the work a month later if I do
nothing but to update nodejs-* packages once I login to OBS. While npm
will see 2 or 3 releases during that time, that means we will be
always late.
So here's what I want to do:
1. everything stops now, all npm dependencies will be removed from
Factory (writing Obsoletes will be a lot of work, see you in a month),
and npm builds from nodejs main package from now on.
2. someone steps in to maintain the packages with a program. Because
it's not doable for a human being as I told above.
Marguerite
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello,
I have a package that contains only bash scripts
(plus documentation) and therefore it is currently
BuildArch: noarch
But depending on the run-time architecture it requires
different packages and therefore it has in its spec file
--------------------------------------------------------------
%ifarch %ix86 x86_64
Requires: syslinux
%endif
%ifarch ppc ppc64
Requires: yaboot
%endif
--------------------------------------------------------------
But that cannot work because when it is built as "noarch"
none of the %ifarch matches which means neither syslinux
nor yaboot will be required by the resulting *.rpm package.
I did not find openSUSE documentation how to solve this.
The Fedora Packaging Guidelines
https://fedoraproject.org/wiki/Packaging:Guidelines
contain an "1.9 Architecture Support" section
that contains (excerpt):
--------------------------------------------------------------
Requires
When your package needs the problematic dependency
at runtime but not at build time then you only need
to keep it from entering the package repositories
for that architecture. There is a relatively simple
workaround for this:
BuildArch: noarch
# List the arches that the dependent package builds on below
ExclusiveArch: %{ix86} %{arm} x86_64 noarch
--------------------------------------------------------------
I don't know if
--------------------------------------------------------------
BuildArch: noarch
ExclusiveArch: %ix86 x86_64 ppc ppc64 noarch
%ifarch %ix86 x86_64
Requires: syslinux
%endif
%ifarch ppc ppc64
Requires: yaboot
%endif
--------------------------------------------------------------
is allowed and/or works on openSUSE.
I found a strange looking example at openSUSE:
--------------------------------------------------------------
$ osc cat openSUSE:13.1 libreoffice-l10n libreoffice-l10n.spec
...
BuildArch: noarch
#!ExclusiveArch: %ix86 x86_64 ppc
ExcludeArch: ia64 s390 s390x
--------------------------------------------------------------
I do not understand that.
In particular what "#!ExclusiveArch:" means?
Why not plain "ExclusiveArch:"?
Furthermore at run-time the bash scripts in that package
actually work only on a few supported architectures
namely %ix86 x86_64 ppc ppc64.
Therefore I like to specify only those architectures where
the package actually works.
I like to avoid that those bash scripts can be "just installed"
on architectures that are actually not supported (i.e. I like
to avoid that the package can be built by accident on
architectures where it actually cannot work).
Would it work to simply have only
--------------------------------------------------------------
ExclusiveArch: %ix86 x86_64 ppc ppc64
%ifarch %ix86 x86_64
Requires: syslinux
%endif
%ifarch ppc ppc64
Requires: yaboot
%endif
--------------------------------------------------------------
Kind Regards
Johannes Meixner
--
SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard,
Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Hello Axel,
"Dr. Axel Braun" <axel.braun(a)gmx.de> writes:
>> However, doesn't it make sense to add
>> provides: lua53
>> to the Lua package to avoid this hassle in future?
>
> Not sure if I understand your approach.
> I think that does not make sense - you can always derive the version
> from the
> package.
What do you mean with _derive_?
However, I will try to explain my thoughts:
The current naming scheme of the Lua packages is
- lua for the latest version at the time point when the openSUSE version
was released
- lua50, lua51, etc. for all older Lua versions
Thus for example in openSUSE 13.2
lua package = Lua 5.2.x
lua51 package = Lua 5.1.x
lua50 package = Lua 5.0.x
Now in Tumbleweed and Factory we have
lua = Lua 5.3.x
lua52 = Lua 5.2
lua51 = Lua 5.1.x
lua50 = Lua 5.0.x
This naming scheme is also explained in
https://en.opensuse.org/openSUSE:Packaging_Lua#Addon_packages
As a consequence, packagers have to fiddle with %if-suse_versions every
time when the Lua versions increases. Additionally, in the period where
Factory had already upgraded the Lua version and Tumbleweed not, one of
them failed to build.
My suggestions is to name in Tumbleweed and Factory the lua package also
lua53. This would make the life easier because if you have to package a
program which requires lua53 you can just write
BuildRequires: lua53-devel
and it will stick to that version.
I don't know if naming the latest lua package also lua53 has any side
effect. However, when upgrading to Lua 5.4, it will be named lua53
anyway.
Best regards,
Heinz
"Dr. Axel Braun" <axel.braun(a)gmx.de> writes:
> Hello Heinz,
>
> Am Montag, 27. Juli 2015, 11:42:05 schrieb Green Basilisk:
>
>> I think the problem vanished because now Tumbleweed and Factory are
>> aligned in terms of Lua versions. :)
>>
>> However, doesn't it make sense to add
>> provides: lua53
>> to the Lua package to avoid this hassle in future?
>
> Not sure if I understand your approach.
> I think that does not make sense - you can always derive the version from the
> package.
> Except you want to replace lets say the gizmo-package with the more advanced
> gizmo-turbo. Then you could add a
> prevides: gizmo > (a version higher than the current gizmo package)
> to gizmo-turbo to force the change
>
> Cheers
> Axel
>
> --
> Dr.-Ing. Axel K. Braun
> Mobile: +49.173.7003.154
> VoIP/Skype: axxite
> PGP Fingerprint: CB03 964D 1CFA E87B AA63 53F3 1BD6 F53A EB48 EF22
> Public Key available at http://www.axxite.com/axel.braun@gmx.de.asc
>
> This mail was *not scanned* before sending.
> It was sent from a secure Linux-Desktop:
>
> ThinkPad T520
> OS: openSUSE 13.1 (x86_64)
> Kernel: 3.11.10-29-desktop
> KDE: 4.14.10
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
What needs to be done to install for example cucumber in SLE_12 or TW?
Since I know next to nothing about ruby my naive approach goes like this:
root@c111:~ # env -i zypper -vv se -sdt package cucumber
...
| ruby2.2-rubygem-cucumber | package | 2.0.2-1.1 | x86_64 | ruby_extensions
...
root@c111:~ # env -i zypper -vv in ruby2.2-rubygem-cucumber
Verbosity: 2
Non-option program arguments: 'ruby2.2-rubygem-cucumber'
Initializing Target
Checking whether to refresh metadata for perl
Checking whether to refresh metadata for python
Checking whether to refresh metadata for ruby
Checking whether to refresh metadata for ruby_extensions
Checking whether to refresh metadata for tw-Essentials
Checking whether to refresh metadata for tw-Extra
Checking whether to refresh metadata for tw-Games
Checking whether to refresh metadata for tw-Multimedia
Checking whether to refresh metadata for tw-debug
Checking whether to refresh metadata for tw-non-oss
Checking whether to refresh metadata for tw-oss
Loading repository data...
Reading installed packages...
Force resolution: No
Selecting 'ruby2.2-rubygem-cucumber-2.0.2-1.1.x86_64' from repository 'ruby_extensions' for installation.
Resolving package dependencies...
Force resolution: No
Problem: nothing provides rubygem(ruby:2.2.0:cucumber-core:1.2) >= 1.2 needed by ruby2.2-rubygem-cucumber-2.0.2-1.1.x86_64
Solution 1: do not install ruby2.2-rubygem-cucumber-2.0.2-1.1.x86_64
Solution 2: break ruby2.2-rubygem-cucumber-2.0.2-1.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/c] (c):
Olaf
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
What is the best way to add recommends for a ruby package? Looks like
rubygem-net-ssh should get a Recommends: on Highline according to
/usr/lib*/ruby/gems/*/gems/net-ssh*/lib/net/ssh/prompt.rb
Otherwise the passphrase is echoed to stdout.
Olaf
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org
Fellow packagers,
after some discussions in our team, we figured that it would be neat if we could
build python modules for Python 2 and 3 from a single spec file. Now that a
great deal of python modules work with both pythons, this makes a lot of sense.
A good deal of work can be done by RPM macros. Then we could even seamlessly
start building modules for PyPy, Jython and other pythons.
A sample specfile, and the corresponding set of RPM macros, is attached. As you
can see, the appropriate subpackage is generated automatically by
%python_subpackages, build and install steps are handled through %python_build
and %python_install respectively. There is some more magic involved, as well as
possibilities for customization.
There is a minor problem with BuildRequires. As long as you only need
python-devel, it's not too bad to just list $flavor-devel requirements by hand.
It's worse when you require more subpackages, because then you need all of them
in both python2 and python3 versions.
It would be nice to be able to specify %{python_require Mako} and expand that to
all the necessary BuildRequires, but OBS blocks us here, because the limited
environment will not expand such macros.
mls, ro, or anyone from the OBS team, would it be possible to solve this?
Still, it basically doesn't matter if you list all the BuildRequires twice in
one spec or in two specs, so there.
Another thing I'm still unclear on are the filelists. It's certainly possible to
make a generic filelist, something along the lines of:
%package -n %flavor-%modname # python3-Mako
%defattr(-, root, root)
%{%flavor_sitelib}/*
%{%flavor_sitearch}/*
but this doesn't solve docs and possible other files.
Again, obviously, we can write the filelists by hand. But if you have good
suggestions for some smart macros here, I'd love to see them.
What do you folks think? Comments, questions?
m.