[opensuse-factory] Use of %defattr in spec files
Hi, most packages in Factory which have been touched recently no longer carry the default %defattr(-,root,root) in the %files section. The reasoning behind this move AFAIK is reduction of noise in the spec file. This is also somewhat enforced by the spec-cleaner, see https://github.com/ openSUSE/spec-cleaner/issues/194 There is no rpmlint check covering this. Unfortunately, this does not match our written down policy, see: https://en.opensuse.org/openSUSE:Specfile_guidelines#Permissions --- Every %files section must include a %defattr(...) --- The %defattr is also repeated in all the language/project packaging guidelines. Fedora specifies the current openSUSE practice: https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions --- The %defattr directive in the %files list SHOULD ONLY be used when setting a non-default value, or to reset to the default value after having set a non- default value. --- Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Brüns, Stefan píše v Po 27. 08. 2018 v 15:05 +0000:
Hi,
most packages in Factory which have been touched recently no longer carry the default %defattr(-,root,root) in the %files section.
The reasoning behind this move AFAIK is reduction of noise in the spec file. This is also somewhat enforced by the spec-cleaner, see https://github.com/ openSUSE/spec-cleaner/issues/194 There is no rpmlint check covering this.
Unfortunately, this does not match our written down policy, see: https://en.opensuse.org/openSUSE:Specfile_guidelines#Permissions --- Every %files section must include a %defattr(...) ---
It is wiki. :) Feel free to update it to no longer mention this requirement. If you check the log it is based on very old policy that simply was not updated. Tom
On Montag, 27. August 2018 17:17:22 CEST Tomas Chvatal wrote:
Brüns, Stefan píše v Po 27. 08. 2018 v 15:05 +0000:
Hi,
most packages in Factory which have been touched recently no longer carry the default %defattr(-,root,root) in the %files section.
The reasoning behind this move AFAIK is reduction of noise in the spec file. This is also somewhat enforced by the spec-cleaner, see https://github.com/ openSUSE/spec-cleaner/issues/194 There is no rpmlint check covering this.
Unfortunately, this does not match our written down policy, see: https://en.opensuse.org/openSUSE:Specfile_guidelines#Permissions --- Every %files section must include a %defattr(...) ---
It is wiki. :)
Feel free to update it to no longer mention this requirement. If you check the log it is based on very old policy that simply was not updated.
Yes, I know, just wanted some "official" confirmation before going ahead. Thanks, Stefan N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
On Monday 2018-08-27 17:05, Brüns, Stefan wrote:
Hi,
most packages in Factory which have been touched recently no longer carry the default %defattr(-,root,root) in the %files section.
Unfortunately, this does not match our written down policy, see: https://en.opensuse.org/openSUSE:Specfile_guidelines#Permissions
The wiki entry is just old in this case. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.08.2018 um 17:05 schrieb Brüns, Stefan:
Hi,
most packages in Factory which have been touched recently no longer carry the default %defattr(-,root,root) in the %files section.
... which kills building an unmodified package on an old distribution (SLES11) by the way... Is there any prjconf trick to re-inject this into the spec-file for less recent distributions? The same is true for the removal of BuildRoot: directive, without it, %buildroot is no longer defined on SLES11... -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Montag, 27. August 2018 17:39:16 CEST Stefan Seyfried wrote:
Am 27.08.2018 um 17:05 schrieb Brüns, Stefan:
Hi,
most packages in Factory which have been touched recently no longer carry the default %defattr(-,root,root) in the %files section.
... which kills building an unmodified package on an old distribution (SLES11) by the way...
Its desecration, not killing - you can not kill a dead one ;-) Its may be an issue for maintenance projects, but for most devel projects its pointless - IMHO having SLE11 in e.g. science is just a waste of resources: https://build.opensuse.org/project/monitor? utf8=%E2%9C%93&commit=Filter%3A&succeeded=1&failed=1&unresolvable=1&broken=1&blocked=1&dispatching=1&scheduled=1&building=1&finished=1&signing=1&locked=1&deleting=1&pkgname=&repo_SLE_11_SP4=1&repo_openSUSE_Factory_PowerPC=1&arch_i586=1&arch_x86_64=1&project=science&defaults=0 If you want to build a package from TW on SLE11, you have to cater for a lot of things. The policy targets updated packages, i.e. packages in devel projects, with new versions at least occasionaly. These will likely introduce new dependencies which are not available on older distributions anyway. Kind regards, Stefan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday, 27 August 2018 18:09 Brüns, Stefan wrote:
On Montag, 27. August 2018 17:39:16 CEST Stefan Seyfried wrote:
... which kills building an unmodified package on an old distribution (SLES11) by the way...
Exactly. I don't say we should go to extremes to keep everything building against older distributions but deliberately breaking the build just to save one line per %file section (%defattr) or even one line per specfile (BuildRoot) doesn't make any sense to me.
Its desecration, not killing - you can not kill a dead one ;-)
SLE11 is not dead, far from it. Actually, SLE11 SP4 is still under regular maintenance, not even LTSS yet (until 2019-03-31), i.e. more alive than e.g. SLE12 up to SP2.
Its may be an issue for maintenance projects, but for most devel projects its pointless
No, it is not pointless. People do build and use latest snapshot on older systems for various reasons.
IMHO having SLE11 in e.g. science is just a waste of resources:
Quite the contrary, actually. Removing the old build targets from devel projects or even needlessly breaking build in the name of more modern specfile style results in people linking the package to their own projects so that in the end, the same package is built more times and more binaries are kept in the repositories. In other words, you end up wasting more resources this way. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Aug 28, 2018 at 4:32 AM Michal Kubecek <mkubecek@suse.cz> wrote:
On Monday, 27 August 2018 18:09 Brüns, Stefan wrote:
On Montag, 27. August 2018 17:39:16 CEST Stefan Seyfried wrote:
... which kills building an unmodified package on an old distribution (SLES11) by the way...
Exactly. I don't say we should go to extremes to keep everything building against older distributions but deliberately breaking the build just to save one line per %file section (%defattr) or even one line per specfile (BuildRoot) doesn't make any sense to me.
Its desecration, not killing - you can not kill a dead one ;-)
SLE11 is not dead, far from it. Actually, SLE11 SP4 is still under regular maintenance, not even LTSS yet (until 2019-03-31), i.e. more alive than e.g. SLE12 up to SP2.
Its may be an issue for maintenance projects, but for most devel projects its pointless
No, it is not pointless. People do build and use latest snapshot on older systems for various reasons.
IMHO having SLE11 in e.g. science is just a waste of resources:
Quite the contrary, actually. Removing the old build targets from devel projects or even needlessly breaking build in the name of more modern specfile style results in people linking the package to their own projects so that in the end, the same package is built more times and more binaries are kept in the repositories. In other words, you end up wasting more resources this way.
Then you guys at SUSE should do what we did in Fedora: add a package that backports semantics from newer versions of RPM so that spec files can follow modern guidelines without issue. I was incredibly happy when I was able to delete no less than two dozen lines of code from one of my spec files because we're dropping SLE 11 support. The amount of hacks and terribleness involved in supporting SLE 11 along with modern versions of SUSE Linux is quite high. I wish you guys would even do this for SLE 12, but I doubt it'll happen. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 28.08.2018 um 14:33 schrieb Neal Gompa:
On Tue, Aug 28, 2018 at 4:32 AM Michal Kubecek <mkubecek@suse.cz> wrote:
On Monday, 27 August 2018 18:09 Brüns, Stefan wrote:
On Montag, 27. August 2018 17:39:16 CEST Stefan Seyfried wrote:
... which kills building an unmodified package on an old distribution (SLES11) by the way...
Exactly. I don't say we should go to extremes to keep everything building against older distributions but deliberately breaking the build just to save one line per %file section (%defattr) or even one line per specfile (BuildRoot) doesn't make any sense to me.
Its desecration, not killing - you can not kill a dead one ;-)
SLE11 is not dead, far from it. Actually, SLE11 SP4 is still under regular maintenance, not even LTSS yet (until 2019-03-31), i.e. more alive than e.g. SLE12 up to SP2.
Its may be an issue for maintenance projects, but for most devel projects its pointless
No, it is not pointless. People do build and use latest snapshot on older systems for various reasons.
IMHO having SLE11 in e.g. science is just a waste of resources:
Quite the contrary, actually. Removing the old build targets from devel projects or even needlessly breaking build in the name of more modern specfile style results in people linking the package to their own projects so that in the end, the same package is built more times and more binaries are kept in the repositories. In other words, you end up wasting more resources this way.
Then you guys at SUSE should do what we did in Fedora: add a package that backports semantics from newer versions of RPM so that spec files can follow modern guidelines without issue.
But epel-rpm-macros has nothing in it for BuildRoot: %defattr (or I was too stupid to find it...) I'll now hack the build package in my OBS instance, to just add these back if necessary when pre-processing the specfile. (I did a similar hack before to remove all "Suggests:", "Recommends:" etc, all keywords that CentOS' rpm did not understand, to allow building unchanged specfiles from openSUSE without lots of noise from "%if 0%{?rhel} ... %endif" changes)
I was incredibly happy when I was able to delete no less than two dozen lines of code from one of my spec files because we're dropping SLE 11 support. The amount of hacks and terribleness involved in supporting SLE 11 along with modern versions of SUSE Linux is quite high.
Unfortunately, SLES11 is what pays the bills or does most of the real work here ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Aug 28, 2018 at 1:50 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 28.08.2018 um 14:33 schrieb Neal Gompa:
On Tue, Aug 28, 2018 at 4:32 AM Michal Kubecek <mkubecek@suse.cz> wrote:
On Monday, 27 August 2018 18:09 Brüns, Stefan wrote:
On Montag, 27. August 2018 17:39:16 CEST Stefan Seyfried wrote:
... which kills building an unmodified package on an old distribution (SLES11) by the way...
Exactly. I don't say we should go to extremes to keep everything building against older distributions but deliberately breaking the build just to save one line per %file section (%defattr) or even one line per specfile (BuildRoot) doesn't make any sense to me.
Its desecration, not killing - you can not kill a dead one ;-)
SLE11 is not dead, far from it. Actually, SLE11 SP4 is still under regular maintenance, not even LTSS yet (until 2019-03-31), i.e. more alive than e.g. SLE12 up to SP2.
Its may be an issue for maintenance projects, but for most devel projects its pointless
No, it is not pointless. People do build and use latest snapshot on older systems for various reasons.
IMHO having SLE11 in e.g. science is just a waste of resources:
Quite the contrary, actually. Removing the old build targets from devel projects or even needlessly breaking build in the name of more modern specfile style results in people linking the package to their own projects so that in the end, the same package is built more times and more binaries are kept in the repositories. In other words, you end up wasting more resources this way.
Then you guys at SUSE should do what we did in Fedora: add a package that backports semantics from newer versions of RPM so that spec files can follow modern guidelines without issue.
But epel-rpm-macros has nothing in it for
BuildRoot:
Look at macros.zzz-epel in epel-rpm-macros 5-7: https://kojipkgs.fedoraproject.org//packages/epel-rpm-macros/5/7/src/epel-rp... In the future, you can always find every build of every package that was ever released through Koji: https://koji.fedoraproject.org/koji/ For this package in particular, this is where I got it from: https://koji.fedoraproject.org/koji/packageinfo?packageID=20323 And the sources Koji builds from is at: https://src.fedoraproject.org/ The Git sources for the package is: https://src.fedoraproject.org/rpms/epel-rpm-macros/tree/el5 There's an obs-service-fedpkg source service floating around somewhere that you can use with Fedora Dist-Git to fetch and build packages in OBS using Fedora package sources. :)
%defattr
RPM 4.4.2 does not require %defattr and sets a default one of "%defattr(-,root,root,-)" when it's not set in the spec file.
(or I was too stupid to find it...)
You're not stupid, it's just you don't know what to look for. :) Also, part of this squarely is SUSE's fault, since their rpmlint policies are out of sync with rpm itself. The rpmlint policy for SUSE distributions was never updated to account for these changes after SLE 10 went fully EOL. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Neal, thanks for all your hints, they are really appreciated. Am 28.08.2018 um 20:08 schrieb Neal Gompa:
On Tue, Aug 28, 2018 at 1:50 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 28.08.2018 um 14:33 schrieb Neal Gompa:
On Tue, Aug 28, 2018 at 4:32 AM Michal Kubecek <mkubecek@suse.cz> wrote:
On Monday, 27 August 2018 18:09 Brüns, Stefan wrote:
On Montag, 27. August 2018 17:39:16 CEST Stefan Seyfried wrote:
... which kills building an unmodified package on an old distribution (SLES11) by the way...
Exactly. I don't say we should go to extremes to keep everything building against older distributions but deliberately breaking the build just to save one line per %file section (%defattr) or even one line per specfile (BuildRoot) doesn't make any sense to me.
Its desecration, not killing - you can not kill a dead one ;-)
SLE11 is not dead, far from it. Actually, SLE11 SP4 is still under regular maintenance, not even LTSS yet (until 2019-03-31), i.e. more alive than e.g. SLE12 up to SP2.
Its may be an issue for maintenance projects, but for most devel projects its pointless
No, it is not pointless. People do build and use latest snapshot on older systems for various reasons.
IMHO having SLE11 in e.g. science is just a waste of resources:
Quite the contrary, actually. Removing the old build targets from devel projects or even needlessly breaking build in the name of more modern specfile style results in people linking the package to their own projects so that in the end, the same package is built more times and more binaries are kept in the repositories. In other words, you end up wasting more resources this way.
Then you guys at SUSE should do what we did in Fedora: add a package that backports semantics from newer versions of RPM so that spec files can follow modern guidelines without issue.
But epel-rpm-macros has nothing in it for
BuildRoot:
Look at macros.zzz-epel in epel-rpm-macros 5-7: https://kojipkgs.fedoraproject.org//packages/epel-rpm-macros/5/7/src/epel-rp...
OK, I only looked back to version 6, not 5 ;-), my bad. Thanks for the pointer. However, the advanced lua rpm magic (and the fact that I somehow would need to inject this via a prjconf) makes me just look at it with awe... ...and then still go on patching build.rpm on the OBS server ;-)
In the future, you can always find every build of every package that was ever released through Koji: https://koji.fedoraproject.org/koji/
For this package in particular, this is where I got it from: https://koji.fedoraproject.org/koji/packageinfo?packageID=20323
And the sources Koji builds from is at: https://src.fedoraproject.org/
The Git sources for the package is: https://src.fedoraproject.org/rpms/epel-rpm-macros/tree/el5
There's an obs-service-fedpkg source service floating around somewhere that you can use with Fedora Dist-Git to fetch and build packages in OBS using Fedora package sources. :)
Yes, Adrian also suggested I use a source service when I tried to submit my "Recommends-eliminator", but just patching build has the advantage for me that a) I don't have to deal with ugly and hard to debug source services on the OBS server b) it is one central place for me to set up and then applies to all projects, without further config
%defattr
RPM 4.4.2 does not require %defattr and sets a default one of "%defattr(-,root,root,-)" when it's not set in the spec file.
I think I encountered abuild-owned files on CentOS7 without %defattr a few days ago.
(or I was too stupid to find it...)
You're not stupid, it's just you don't know what to look for. :)
Also, part of this squarely is SUSE's fault, since their rpmlint policies are out of sync with rpm itself. The rpmlint policy for SUSE distributions was never updated to account for these changes after SLE 10 went fully EOL.
I can easily roll my own rpmlint (in fact I disarm most of the warnings that are only about "bad style", because in "my" private OBS instance, stuff in /opt is the norm, "invalid" licenses are not a problem etc. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Aug 28, 2018 at 2:55 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Hi Neal,
thanks for all your hints, they are really appreciated.
Am 28.08.2018 um 20:08 schrieb Neal Gompa:
On Tue, Aug 28, 2018 at 1:50 PM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 28.08.2018 um 14:33 schrieb Neal Gompa:
On Tue, Aug 28, 2018 at 4:32 AM Michal Kubecek <mkubecek@suse.cz> wrote:
On Monday, 27 August 2018 18:09 Brüns, Stefan wrote:
On Montag, 27. August 2018 17:39:16 CEST Stefan Seyfried wrote: > ... which kills building an unmodified package on an old > distribution (SLES11) by the way...
Exactly. I don't say we should go to extremes to keep everything building against older distributions but deliberately breaking the build just to save one line per %file section (%defattr) or even one line per specfile (BuildRoot) doesn't make any sense to me.
Its desecration, not killing - you can not kill a dead one ;-)
SLE11 is not dead, far from it. Actually, SLE11 SP4 is still under regular maintenance, not even LTSS yet (until 2019-03-31), i.e. more alive than e.g. SLE12 up to SP2.
Its may be an issue for maintenance projects, but for most devel projects its pointless
No, it is not pointless. People do build and use latest snapshot on older systems for various reasons.
IMHO having SLE11 in e.g. science is just a waste of resources:
Quite the contrary, actually. Removing the old build targets from devel projects or even needlessly breaking build in the name of more modern specfile style results in people linking the package to their own projects so that in the end, the same package is built more times and more binaries are kept in the repositories. In other words, you end up wasting more resources this way.
Then you guys at SUSE should do what we did in Fedora: add a package that backports semantics from newer versions of RPM so that spec files can follow modern guidelines without issue.
But epel-rpm-macros has nothing in it for
BuildRoot:
Look at macros.zzz-epel in epel-rpm-macros 5-7: https://kojipkgs.fedoraproject.org//packages/epel-rpm-macros/5/7/src/epel-rp...
OK, I only looked back to version 6, not 5 ;-), my bad.
Thanks for the pointer. However, the advanced lua rpm magic (and the fact that I somehow would need to inject this via a prjconf) makes me just look at it with awe...
You could build the package in your project and then add "Support: extra-rpm-macros" to prjconf. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 28 Aug 2018 at 10:32, Michal Kubecek <mkubecek@suse.cz> wrote:
On Monday, 27 August 2018 18:09 Brüns, Stefan wrote:
On Montag, 27. August 2018 17:39:16 CEST Stefan Seyfried wrote:
... which kills building an unmodified package on an old distribution (SLES11) by the way...
Exactly. I don't say we should go to extremes to keep everything building against older distributions but deliberately breaking the build just to save one line per %file section (%defattr) or even one line per specfile (BuildRoot) doesn't make any sense to me.
Yes , on SLE11 maintenance You need build latest upstream packages ..
Its desecration, not killing - you can not kill a dead one ;-)
SLE11 is not dead, far from it. Actually, SLE11 SP4 is still under regular maintenance, not even LTSS yet (until 2019-03-31), i.e. more alive than e.g. SLE12 up to SP2.
from development view is DEAD .. regular maintenace isnt total change of specfile..
Its may be an issue for maintenance projects, but for most devel projects its pointless
No, it is not pointless. People do build and use latest snapshot on older systems for various reasons.
IMHO having SLE11 in e.g. science is just a waste of resources:
Quite the contrary, actually. Removing the old build targets from devel projects or even needlessly breaking build in the name of more modern specfile style results in people linking the package to their own projects so that in the end, the same package is built more times and more binaries are kept in the repositories. In other words, you end up wasting more resources this way.
Michal Kubecek
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday, 28 August 2018 23:01 Ondřej Súkup wrote:
On Tue, 28 Aug 2018 at 10:32, Michal Kubecek <mkubecek@suse.cz> wrote:
On Monday, 27 August 2018 18:09 Brüns, Stefan wrote:
On Montag, 27. August 2018 17:39:16 CEST Stefan Seyfried wrote:
... which kills building an unmodified package on an old distribution (SLES11) by the way...
Exactly. I don't say we should go to extremes to keep everything building against older distributions but deliberately breaking the build just to save one line per %file section (%defattr) or even one line per specfile (BuildRoot) doesn't make any sense to me.
Yes , on SLE11 maintenance You need build latest upstream packages ..
Its desecration, not killing - you can not kill a dead one ;-)
SLE11 is not dead, far from it. Actually, SLE11 SP4 is still under regular maintenance, not even LTSS yet (until 2019-03-31), i.e. more alive than e.g. SLE12 up to SP2.
from development view is DEAD .. regular maintenace isnt total change of specfile..
Let me remind you that there are people who believe people should install spec-cleaner as a service which would then apply these changes to _any_ submission. (In the beginning, spec-cleaner had "non-intrusive mode" option; last time I checked, the difference against default was negligible.) Anyway, it's a bit funny you copied the following part of my e-mail and yet managed to overlooked that it kind of pre-answers your reply:
Its may be an issue for maintenance projects, but for most devel projects its pointless
No, it is not pointless. People do build and use latest snapshot on older systems for various reasons.
IMHO having SLE11 in e.g. science is just a waste of resources:
Quite the contrary, actually. Removing the old build targets from devel projects or even needlessly breaking build in the name of more modern specfile style results in people linking the package to their own projects so that in the end, the same package is built more times and more binaries are kept in the repositories. In other words, you end up wasting more resources this way.
Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Aug 27, 2018 at 11:39 AM Stefan Seyfried <stefan.seyfried@googlemail.com> wrote:
Am 27.08.2018 um 17:05 schrieb Brüns, Stefan:
Hi,
most packages in Factory which have been touched recently no longer carry the default %defattr(-,root,root) in the %files section.
... which kills building an unmodified package on an old distribution (SLES11) by the way...
Is there any prjconf trick to re-inject this into the spec-file for less recent distributions?
The same is true for the removal of BuildRoot: directive, without it, %buildroot is no longer defined on SLES11...
In Fedora, we had a lot of tricks in the `epel-rpm-macros` package to backport functionality and behaviors from Fedora to RHEL/CentOS, and I believe we did come up with ways to do this for even EL5, which uses the same version of rpm as SLE 11. That said, let SLE 11 rest in peace and move on to SLE 15. :) -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (7)
-
Brüns, Stefan -
Jan Engelhardt -
Michal Kubecek -
Neal Gompa -
Ondřej Súkup -
Stefan Seyfried -
Tomas Chvatal