+%if 0%{?is_opensuse}
+    -e '/[@sle\_version](https://build.opensuse.org/users/sle_version)@%{?sle_version:nomatch}/d' \
+    -e 's/[@sle\_version](https://build.opensuse.org/users/sle_version)@/%{?sle_version}%{!?sle_version:0}/' \
+%else
+    -e '/[@sle\_version](https://build.opensuse.org/users/sle_version)@/d' \
+%endif

I might be confused (probably) - no sle_version on SLE? (is_opensuse == 0)

Yes, that's correct. SLE sets sle_version in the release packages (/etc/rpm/macros.sle). That's because a new sle service pack doesn't need to include a new rpm package. This is unlike leap, which always rebuilds all packages.

Dominique Leuenberger (dimstar) - over 6 years ago

reviewer

Thanks for the details.

we seem to lose macros we had in place in the old rpm package:

[  215s] + exit 0
[  215s] 
[  215s] 
[  215s] RPM build errors:
[  215s]     File must begin with "/": %{py_sitedir}/gamin.py*
[  215s]     File must begin with "/": %{py_sitedir}/_gamin*

(while building gamin in Staging:A)

Yes, that's done on purpose. Those packages need to be fixed. I think it's '%python_sitelib' nowadays, but I have no experience with python packaging.

(On purpose is a bit strong, actually I wasn't aware that the python-rpm-macros doesn't define that. Still, dropping it is the right thing. I can add it back for until the packages are fixed, though.)

There are some other macros that seem to be needed. See the "legacy macros" section in /etc/rpm/macros.python2.

Having them commented out does not make much sense if rpm (nowadays rpm-config-SUSE) contains a copy...

another package affected - libsolv:

[   89s] + pushd /home/abuild/rpmbuild/BUILDROOT/libsolv-0.6.34-3.7.x86_64//usr/lib64/python2.7/site-packages
[   89s] ~/rpmbuild/BUILDROOT/libsolv-0.6.34-3.7.x86_64/usr/lib64/python2.7/site-packages ~/rpmbuild/BUILD/libsolv-0.6.34
[   89s] + python %py_libdir/py_compile.py solv.py
[   89s] python: can't open file '%py_libdir/py_compile.py': [Errno 2] No such file or directory
[   89s] error: Bad exit status from /var/tmp/rpm-tmp.z0LJz9 (%install)
[   89s] 

(That's already fixed upstream)

Anyway, what should I do? Add the missing macros back and open bugs against all affected packages?

Dominique Leuenberger (dimstar) - over 6 years ago

reviewer

I'm actually curious to find out how many we will have to fix; if the number is 'low', I'd say let's fix - if 'high', we get the macros back in and bug maintainers. (values for low/high can be defined - usually I consider 10 - 15 as low for such simple fixes)

Can you make an overview of what macros all are deprecated? I'll try to find the list over all openSUSE:Factory packages making use of them in their spec files

---

Dominique Leuenberger (dimstar) - over 6 years ago

reviewer

So the complete list of failed (ring) packages is:

Build failed OpenIPMI (i586, x86_64)
Build failed antlr (i586, x86_64)
Build failed gamin (i586, x86_64)
Build failed libsolv (i586, x86_64)
Build failed mtools (i586, x86_64)
Build failed python-gobject2 (i586, x86_64)
Build failed python-wxWidgets-3_0 (i586, x86_64)
Build failed sk1 (i586, x86_64)
Build failed subversion (i586, x86_64)

I'd consider that short enough to get those packages fixed, rather than working around the problem by reintrodcing deprecated macros.

Can you please send a mail to the -factory ML with information about the change that happens and (short) instructions on how to fix it? Woul dbe great for the maintainers to pick up their packages (and anybody else running into the issue could be sent to the mail for reference)