HI!
I'm trying to fix
https://bugzilla.opensuse.org/show_bug.cgi?id=1180132
Currently roundcubemail has
Requires: http_daemon
So I'd like fix package apache2 with this:
Provides: http_daemon
Is that the right approach? Is there a well-defined list of such
commonly used Provides values?
Ciao, Michael.
... but struggeling with build errors which I have no idea how to fix.
Maybe someone can assist.
It is here:
https://build.opensuse.org/package/live_build_log/home:computersalat:devel:…
[ 49s] + exec rpmbuild -ba --define '_srcdefattr (-,root,root)'
--nosignature --define 'disturl
obs://build.opensuse.org/home:computersalat:devel:python/SLE_12.4/a839c1a5e…'
/home/abuild/rpmbuild/SOURCES/python-qt4.spec
[ 49s] error: lua script failed: [string "<lua>"]:46: bad argument #2
to 'format' (string expected, got nil)
[ 49s] error: line 59: Provides: python2-qt4 = 4.12.3-1.1
[ 49s] %package -n python36-qt4
Thank you :-)
--
Christian
------------------------------------------------------------
https://join.worldcommunitygrid.org?recruiterId=177038
------------------------------------------------------------
http://www.sc24.de - Sportbekleidung
------------------------------------------------------------
Hello,
I recently update the package xreader 2.8.3.
https://build.opensuse.org/package/show/X11:Cinnamon:Factory/xreader
Starting xreader from terminal I got.
symbol lookup error: xreader: undefined symbol: ev_document_model_set_rtl
I did not make change to the spec file macro at all, I just change the version number. The version 2.8.1 work fine with the macro. The issue start with 2.8.2 and 2.8.3.
I'm not sure if this due to missing dependency or not.
I tried installed evince-devel because ev in ev_document_model_set_rtl is relate to evince, but the issue still occur.
I also report in here https://github.com/linuxmint/xreader/issues/452 but no response yet.
Kind regards,
Andy
Hello,
I need help fix build fail for mint-x-icon-theme.
https://build.opensuse.org/package/show/X11:Cinnamon:Factory/mint-x-icon-th…
I update it from version 1.5.5 to 1.5.9 which I did not change any macro except the version.
The issue look like missing symbolic link.
[ 24s] ERROR: link target doesn't exist (neither in build root nor in installed system):
[ 24s] /usr/share/icons/Mint-X/apps/16/file-manager.png -> system-file-manager.png
[ 24s] Add the package providing the target to BuildRequires and Requires
Which I believe this macro have the issue, but I don't know how to fix it, because I did not write that macro.
mkdir -p %{buildroot}%{_datadir}/icons/
ls .%{_datadir}/icons/ | while read icons; do
sed -i 's/^\(Inherits=\).*$/\1Adwaita/' .%{_datadir}/icons/$icons/index.theme
cp -a .%{_datadir}/icons/$icons %{buildroot}%{_datadir}/icons/$icons
# %%icon_theme_cache_create_ghost fails to work here.
touch %{buildroot}%{_datadir}/icons/$icons/icon-theme.cache
done
Any ideas?
Kind regards,
Andy
Hello List subscribers,
people have been complaining that they missed some important messages
because the previous mails were "buried" as answers in some sub threads
and understandably not everyone reads every thread due to high mail
volume. So here is some more volume for you, again posting to 3
mailinglists. Top post without any reference to other mails.
A major change of the python-rpm-macros and matching prjconf definitions
has been introduced to Factory last Friday. Now is the time to fix your
python-foo packages, or specfiles creating python3-foo subpackages.
Quoting the two relevant posts below. Refer to the actual threads for
discussions and comments.
-------- Weitergeleitete Nachricht --------
Betreff: Re: Tumbleweed snapshot 20210115 - python can be bumpy
Datum: Mon, 18 Jan 2021 13:10:21 +0100
Von: Dominique Leuenberger / DimStar <dimstar(a)opensuse.org>
An: factory(a)lists.opensuse.org
On Mon, 2021-01-18 at 12:00 +0000, Dominique Leuenberger wrote:
> Packages changed:
> python-rpm-macros (20200824.8fa42a7 -> 20210112.86f4d9d)
>
> === Details ===
>
>
> ==== python-rpm-macros ====
> Version update (20200824.8fa42a7 -> 20210112.86f4d9d
This change has potential for quite some headaches - it was in Staging
for a long time to get things sorted out 'reasonably well', BUT:
depending on your python-* modules installed, this can be a rough
weekfor you.
There is a large number of packages that did not like the change (none
of the ring packages, so 'most' users probably won't feel it)
If you are a python-* maintainer and see your packages newly fail,
please try to help everybody to get your packages back on track.
Benjamin Greiner has proven to be very helpful in those cases.
The main change is that the python-FOO spec files (when using the long
established python-single-spec style, which we had already for py2/py3
in place) will produce python36-FOO and python38-FOO (the 38-FOO
provides/obsoletes python3-FOO, helping for the migrationpath)
The 'not too distant'; future should see this concept further enhanced
with python39 added to the mix. But that is not even staged. Let's
first iron out glitches with the two python3.x variants.
Cheers,
Dominique
-------- Weitergeleitete Nachricht --------
Betreff: Python 3 parallel install (Re: Tumbleweed - Review of the week
2020/52)
Datum: Sat, 26 Dec 2020 16:01:42 +0100
Von: Ben Greiner <code(a)bnavigator.de>
An: factory(a)lists.opensuse.org, python(a)lists.opensuse.org,
packaging(a)lists.opensuse.org
Hello,
my apologies in advance if this mail reaches you up to three times, but
in my opinion the topic is relevant and important to reach people
subscribed to all three mailing lists.
Am 25.12.20 um 18:34 schrieb Dominique Leuenberger / DimStar an
factory(a)lists.opensuse.org:
> * Multiple python 3 versions parallel installable. Adding to python
> 3.8, version 3.6 will be reintroduced. Python modules will be built
> for both versions.
This line sounds rather innocent, but it has severe implications:
Every package python-foo, which uses the so called singlespec macro
%python_subpackages, will also try to build a python36-foo package. The
whole build process will fail if a step in that particular flavor fails
or if building for more than one flavor will create conflicts. We took
care [1] of all the packages in Ring0 and Ring1, which popped up as
problematic in the staging project. But there are many more packages,
which will see the change the first time, when the staging project will
be accepted into Factory. You can refer to the documented changes in [1]
for examples how to fix a package. There are also some updates to the
wiki [2] and the documentation of python-rpm-macros [3].
In particular, look out for:
- Packages already skipping Python 2 will start to produce more than one
package. Avoid duplicate files by using update-alternatives (there are
macros for it in python-rpm-macros), or put common files into unflavored
subpackages.
- If you provide or require python3-foo, it will only do that for the
primary python interpreter. Replace `BuildRequires python3-foo` by
`BuildRequires %{python_module foo}` and let the %python_subpackages
macro do the work for all Tags and macros where it can replace the
unflavored variants e.g.:
* `Requires: python-bar` instead of python3-bar.
* `%python_sitelib` instead of `%python3_sitelib` in `%files`
- Some packages need extra packages backporting stuff to Python 3.6,
e.g. importlib-metadata or dataclasses. See black as an example how to
deal with this [4]
- If upstream does not support python 3.6 anymore (Numpy already
deprecates to support it in new releases, according to NEP 29 [5]) you
can use `%define skip_python36 1`. All depending packages need to do the
same. Alternatively a branched package can provide an older version for
this flavor, e.g. python-ipython715 has been created to provide the last
version which support Python 3.6.
- Python "apps" not following the flavored python-foo naming scheme,
will only collect files for one (hopefully the primary python3
providing) flavor during the packaging phase. Remove %python_modules,
%python_build, %python_install, %python_expand and the sort, as it
unnecessarily pulls in packages for all python flavors and tries to
build and install into multiple sitelib/sitearch directories. Replace by
calling python3 directly or use the equivalent %python3_* macros.
- Some non-singlespec packages only create python3-foo. They will either
need an update to include python36-foo, python38-foo (and python39-foo
in the near future), or all depending packages must only build for the
primary python3, too. `%define pythons python3` or skip all non-primary
interpreters.
- The previous item is also true for many packages, which have a python
bindings subpackage but are not Python only. We introduced
%python_subpackage_only so that these packages now can take advantage of
the singlespec macros as well. The tracker comment on GitHub [6] has
links to a few examples how to use it.
- %ifpython3 and %python3_only are evil. They have been deprecated for
some months already. Essentially, they fail to recognize the new flavors
python36 and python38 which replace python3. OTOH, older distributions
will continue to use the python3 flavor. We have introduced a new
%python_provides macro, but did not modify %ifpython3 or %python3_only
to incorporate this, because it is not automatically clear whether the
conditioned code block shall apply to all flavors of Python3 packages or
only to the primary interpreter. Replace by something like
* `%if "%{python_flavor}" == "python3" || "%{?python_provides}" ==
"python3"` for sections only provided by the primary flavor.
* `%if 0%{python_version_nodots} > 34` or `%if "%{python_flavor}" !=
"python2"` for section applicable to all Python 3 flavors.
Cheers and happy coding,
Ben
[1] https://github.com/openSUSE/python-rpm-macros/issues/66
[2] https://en.opensuse.org/openSUSE:Packaging_Python
[3] https://github.com/openSUSE/python-rpm-macros/blob/master/README.md
[4] https://build.opensuse.org/request/show/853412
[5] https://numpy.org/neps/nep-0029-deprecation_policy.html
[6]
https://github.com/openSUSE/python-rpm-macros/issues/66#issuecomment-715538…
Hi list,
do we have any guidelines for packaging applications that require nodejs
libraries?
The new release of rstudio includes a web based editor written in
typescript. And as usual, it has a *huge* dependency graph. Would it be
fine if I just bundle them inside rstudio, because there's no way that
I'll be able to package the full dependency graph of those node modules.
Thanks in advance,
Dan
--
Dan Čermák <dcermak(a)suse.com>
Software Engineer Development tools
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nuremberg
Germany
(HRB 36809, AG Nürnberg)
Managing Director: Felix Imendörffer
Hi,
I see suddenly rpmlint-error in TW (Leap builds fine):
mygnuhealth.noarch: E: hardlink-across-partition (Badness: 10000) /usr/lib/
python3.8/site-packages/mygnuhealth/images/mygnuhealth.svg /usr/share/icons/
hicolor/scalable/apps/mygnuhealth.svg
As nothing is changed compared to yesterday, my suspect is:
# menu-entry
desktop-file-install --dir %{buildroot}%{_datadir}/applications
org.kde.mygnuhealth.desktop
Side-effect of the new rpmlint?
Cheers
Axel
Dear fellow packagers,
With PHP8 released a couple of weeks ago, you may have been wondering
when it will be available in Factory. Good news: we're almost there.
For the time being, we are going to provide both php7 and php8
packages. Due to some BC-breaking changes in PHP-8, it is expected
that not all PHP packages will be able to migrate to PHP-8 yet.
Therefor no automatic upgrade will be attempted.
Notable change: the command-line binary will *not* be installed by
default anymore when the base php7 or php8 packages are installed.
Only if no sapi (mod_php, embed, fastcgi or fpm) is installed already,
php-cli will be selected. So in order to guarantee the CLI is present,
you need to explicitly (Build)Require (PHP version independent)
'php-cli' or '/usr/bin/php' or (PHP version dependent) 'php7-cli' or
'php8-cli' respectively. Note that only one of 'php7-cli' and
'php8-cli' can be used (due to hard-coded paths in the command-line
binary /usr/bin/php).
One thing that changed recently, is openssl support. We've build
openssl as a shared module in PHP for years already, but until
recently openssl happened to be built-in through mysqlnd (which was
built-in). Now that has been fixed by building mysqlnd as a shared
module as well, openssl will no longer be built-in. So if you need SSL
support pretty much anywhere in PHP, you *must* require/install
php-openssl.
Last but not least: the base php7 and php8 packages theoretically can
be installed side-by-side, as well as the 'mod_php' and 'embed'
targets (and the shared PHP modules). In theory it should be possible
to run multiple versions on the same system, but do note that in that
case if you install (or require) shared PHP modules, you'll get the
php8 version by default if you don't explicitly tell the system to use
the php7 version. So although it is probably possible to run them
side-by-side, it may give unexpected results and we don't recommend
this.
Best regards,
Arjen de Korte
Dear listmembers,
I am maintaining an application where I have to run two subsequent compilation
processes to care for different screen resolutions.
Now, here is my question: I have to apply a patch after the completion of th
first compilation and after moving the first binary apart. Unfortunately I
cannot do that from the very begin.
There is a declaration
Patch14: ABCD.patch
but I cannot do a
%patch14
in the %prep section because this would cause this patch to be effective from
the start.
Currently I am doing a
patch -p0 < ../../SOURCES/ABCD.patch
after the first build and after having moved the first binary away but within
the %install section of the spec file. However I assume this is not the way it
should be ... I mean, this works but I hope there is a more elegant way to get
this done within the spec file.
Any hints for me?
Thank you very much,
take care
Dieter
--
-----------------------------------------------------------
Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe
