Bug 1180367 - complete source and dependencies to generate a binary rpm are not given in its source rpm
On 2021/02/09 05:34, bugzilla_noreply@suse.com <mailto:bugzilla_noreply@suse.com> wrote:
Richard Brown <mailto:rbrown@suse.com> changed bug 1180367 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367> <http://bugzilla.opensuse.org/show_bug.cgi?id=1180367 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367>> What Removed Added Status REOPENED RESOLVED CC rbrown@suse.com <mailto:rbrown@suse.com> Resolution --- INVALID
*Comment # 7 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367#c7> <http://bugzilla.opensuse.org/show_bug.cgi?id=1180367#c7 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367#c7>> on bug 1180367 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367> <http://bugzilla.opensuse.org/show_bug.cgi?id=1180367 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367>> from Richard Brown <mailto:rbrown@suse.com> *
Due to the following reasons, this bug is INVALID
1) Title is factually incorrect - complete sources are shipped. This alone makes this bug INVALID.
--- The rpms are supposed to include the source needed to regenerate a package. Using the source rpm for a specific binary doesn't allow for generation. Thus the claim that the complete sources for generating a given binary package. That users cannot generate a given binary rpm from the source rpm has been been noted by others on the public lists. If you want to claim the title is incorrect, you are welcome to retitle it to be sufficiently precise.
2) Component is incorrect - this is not a valid upgrade problem.
But it is an upgrade problem in that it is trying to upgrade the rpm-package that is failing from opensuse sources.
3) Bug report claims a GPL violation, but the GPLv2 (Clause 3) clearly spells out the obligation of the licensee is to distribute "all the source code for all modules it contains.
By definition opensuse claims that the src-rpm is sufficient to reproduce the binary package. If this is not the case, then the src-rpm is broken. If you feel the src-rpm is broken, you welcome to re-assign this to someone who handles the release of rpm.
plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable". openSUSE fulfills this obligation. Bug reporter clearly states a desire to use their own scripts and tools to control
I desire to be able to use the src.rpm's open suse delivered to me to be able to generate them. They are not my own scripts or tools -- but ones delivered by open suse. Requiring that one can only install them via a proprietary build system is breaking the GPL. I cannot verify that the tools and sources on a remote machine are the ones I have installed and are trustworthy. Being able to generate those binaries that the vendor claims the sources for reside in the corresponding src rpms are the claim that is broken. Suse's published sources for rpms won't generate the binaries for those rpms.
4) openSUSE's rpms are all buildable when using any rpmbuild binaries that support boolean dependencies.
And the rpm-source is supposed to list the tools needed to generate those tools. If it does not, that is out of my control.
It is not a valid bug just because the reporter wishes to use an unsupported rpmbuild binary of their own choosing.
I used the listed rpm provided by opensuse. It is not my version -- it is opensuse's version. If the src rpm requires some other binary version then open suse needs to include the source for that version as well. The problem is that the binary you claim is necessary to build the rpm is the same rpm that doesn't build. That's a catch-22. I have rpm V4.11. I'm trying to build the rpm-v4.15 binary from the v4.15 sources. But you are claiming that I need rpm 4.15 in order to build 4.15. That is not possible. If you require a specific version of rpm it, needs to be included in some "reasonable" pre-req list. So I can upgrade from my opensuse rpm to the current one. That chain is what is broken.
To Summarise:
Original bug title: complete sources to generate rpms are not shipped with the binaries, violating GPL
Objective reality: complete sources to generate rpms ARE shipped with the binaries, openSUSE's GPL is not violated.
--- Complete sources are noted to be the src rpm of the binary. The src-rpm doesn't generate the given binaries. This is a FAIL.
Reporters reality: sources do not work with rpmbuild binary chosen by reporter.
---- The binary supplied by opensuse. If you have a different binary you want me to install, I'm more than open to it.
Actual issue: Reporter needs to choose a different rpmbuild binary or manually build rpmbuild using the sources that are shipped with openSUSE.
the rpmbuild shipped with openSUSE is the exact binary I am trying to build. You are claiming I need some specific version of rpm, like rpm-4.15-build to build rpm-4.15? Too clearly, that is not possibly. The rpm.spec is supposed to include the requirements needed to build that rpm. It doesn't specify a version of rpm.
On 2/10/21 4:18 AM, L A Walsh wrote:
On 2021/02/09 05:34, bugzilla_noreply@suse.com <mailto:bugzilla_noreply@suse.com> wrote:
Richard Brown <mailto:rbrown@suse.com> changed bug 1180367 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367> <http://bugzilla.opensuse.org/show_bug.cgi?id=1180367 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367>> What Removed Added Status REOPENED RESOLVED CC rbrown@suse.com <mailto:rbrown@suse.com> Resolution --- INVALID
*Comment # 7 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367#c7> <http://bugzilla.opensuse.org/show_bug.cgi?id=1180367#c7 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367#c7>> on bug 1180367 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367> <http://bugzilla.opensuse.org/show_bug.cgi?id=1180367 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367>> from Richard Brown <mailto:rbrown@suse.com> *
Due to the following reasons, this bug is INVALID
1) Title is factually incorrect - complete sources are shipped. This alone makes this bug INVALID.
The rpms are supposed to include the source needed to regenerate a package. Using the source rpm for a specific binary doesn't allow for generation. Thus the claim that the complete sources for generating a given binary package. That users cannot generate a given binary rpm from the source rpm has been been noted by others on the public lists.
The source rpm's should include all the source needed to regenerate a package, under the right environment which involves a version of rpm that is new enough, and having the right macro's / defines for leap you can find them here https://build.opensuse.org/projects/openSUSE:Leap:15.2/prjconf I guess someone could make an argument that the project config could go in source rpm's however this would make it harder to rebuild a source rpm for a different distro.
2) Component is incorrect - this is not a valid upgrade problem.
But it is an upgrade problem in that it is trying to upgrade the rpm-package that is failing from opensuse sources.
Do you mean trying to rebuild the rpm package with an old version of rpm is failing? Because i'm not sure thats something we need to support.
3) Bug report claims a GPL violation, but the GPLv2 (Clause 3) clearly spells out the obligation of the licensee is to distribute "all the source code for all modules it contains.
By definition opensuse claims that the src-rpm is sufficient to reproduce the binary package. If this is not the case, then the src-rpm is broken. If you feel the src-rpm is broken, you welcome to re-assign this to someone who handles the release of rpm.
With the right tooling it is sufficient, all the tooling we use is open source and you are able to download it and install it yourself if you wish.
plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable". openSUSE fulfills this obligation. Bug reporter clearly states a desire to use their own scripts and tools to control
I desire to be able to use the src.rpm's open suse delivered to me to be able to generate them. They are not my own scripts or tools -- but ones delivered by open suse.
Requiring that one can only install them via a proprietary build system is breaking the GPL. I cannot verify that the tools and sources on a remote machine are the ones I have installed and are trustworthy. Being able to generate those binaries that the vendor claims the sources for reside in the corresponding src rpms are the claim that is broken. Suse's published sources for rpms won't generate the binaries for those rpms.
I'm not sure where your getting the idea of a "Proprietary build system" to install them, I presume you mean build them. openSUSE uses Open Build Service (https://openbuildservice.org/) to build its rpm's its completely open source and has detailed instructions on how you can install it so it could be considered as part of the source required and if you did need to use it to build our rpm's it wouldn't be a GPL violation.
4) openSUSE's rpms are all buildable when using any rpmbuild binaries that support boolean dependencies.
And the rpm-source is supposed to list the tools needed to generate those tools. If it does not, that is out of my control.
The fact that the rpm spec file doesn't list a minimum required version for rpm-build is probably a very minor bug. It is the kind of bug that probably exists in a very large number of packages, generally as packagers if the builds everywhere we care about (generally all supported openSUSE and maybe SLE distros) then we wont bother going through and updating all the minimum required versions unless we see it break somewhere. For example if I was building a package that required Meson 0.56.0 i'd put an explicit version there as that version is unavailable on Leap and then i'd get a clear error saying I can't build this package due to not having a new enough meson on OBS rather then a build fail that i'd have to dig into. On the other hand if my package requires cmake 3.0.0 or later I probably won't bother mentioning that because its pretty reasonable to assume that we have atleast that version of cmake everywhere because its been around forever. (Also I wouldn't hit an error anywhere so I probably wouldn't bother checking the version needed).
It is not a valid bug just because the reporter wishes to use an unsupported rpmbuild binary of their own choosing.
I used the listed rpm provided by opensuse. It is not my version -- it is opensuse's version. If the src rpm requires some other binary version then open suse needs to include the source for that version as well. The problem is that the binary you claim is necessary to build the rpm is the same rpm that doesn't build. That's a catch-22. I have rpm V4.11. I'm trying to build the rpm-v4.15 binary from the v4.15 sources. But you are claiming that I need rpm 4.15 in order to build 4.15. That is not possible. If you require a specific version of rpm it, needs to be included in some "reasonable" pre-req list. So I can upgrade from my opensuse rpm to the current one. That chain is what is broken.
No I think we are at least somewhat sane and probably required that rpm v4.14 also built v4.15 so with the right collection of source rpm's for rpmbuild you probably could upgrade. I don't think its our responsibility to continue to provide old versions indefinitely. We provide multiple ways that would allow you to create a new chroot capable of building the rpm source package, either using obs or rpmbuild.
To Summarise:
Original bug title: complete sources to generate rpms are not shipped with the binaries, violating GPL
Objective reality: complete sources to generate rpms ARE shipped with the binaries, openSUSE's GPL is not violated.
--- Complete sources are noted to be the src rpm of the binary. The src-rpm doesn't generate the given binaries. This is a FAIL.
Reporters reality: sources do not work with rpmbuild binary chosen by reporter.
---- The binary supplied by opensuse. If you have a different binary you want me to install, I'm more than open to it.
You could use the binaries for open build service, you could use the current rpm 4.16 binaries provided in tumbleweed, there is also a high chance that you could use the 4.14 binaries provided for leap
Actual issue: Reporter needs to choose a different rpmbuild binary or manually build rpmbuild using the sources that are shipped with openSUSE.
the rpmbuild shipped with openSUSE is the exact binary I am trying to build. You are claiming I need some specific version of rpm, like rpm-4.15-build to build rpm-4.15? Too clearly, that is not possibly. The rpm.spec is supposed to include the requirements needed to build that rpm. It doesn't specify a version of rpm.
Yep this is a minor rpm packaging bug, you could file a bug and the maintainer will fix it if they have time, alternatively it would probably take you 10 minutes to fork the package on obs fix it then resubmit it, i'm happy to help with that process if you'd like. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 10/02/2021 03.16, Simon Lees wrote:
On 2/10/21 4:18 AM, L A Walsh wrote:
On 2021/02/09 05:34, bugzilla_noreply@suse.com <mailto:bugzilla_noreply@suse.com> wrote:
2) Component is incorrect - this is not a valid upgrade problem.
But it is an upgrade problem in that it is trying to upgrade the rpm-package that is failing from opensuse sources.
Do you mean trying to rebuild the rpm package with an old version of rpm is failing? Because i'm not sure thats something we need to support.
Yes, we do, IMHO. Distribution ships version A of rpm, then upgrades to version B of rpm. Version B of necessity has to be built with version A installed and running.
3) Bug report claims a GPL violation, but the GPLv2 (Clause 3) clearly spells out the obligation of the licensee is to distribute "all the source code for all modules it contains.
By definition opensuse claims that the src-rpm is sufficient to reproduce the binary package. If this is not the case, then the src-rpm is broken. If you feel the src-rpm is broken, you welcome to re-assign this to someone who handles the release of rpm.
With the right tooling it is sufficient, all the tooling we use is open source and you are able to download it and install it yourself if you wish.
I also believe the src rpm is the right tooling, not an OBS instance. Otherwise, IMHO we are breaking the license terms. ...
the rpmbuild shipped with openSUSE is the exact binary I am trying to build. You are claiming I need some specific version of rpm, like rpm-4.15-build to build rpm-4.15? Too clearly, that is not possibly. The rpm.spec is supposed to include the requirements needed to build that rpm. It doesn't specify a version of rpm.
Yep this is a minor rpm packaging bug, you could file a bug and the maintainer will fix it if they have time, alternatively it would probably take you 10 minutes to fork the package on obs fix it then resubmit it, i'm happy to help with that process if you'd like.
If my memory serves, the bug was submitted and rejected. It is a major issue for L A Walsh, her machine is not upgradeable because of this failure. AFAIK, the machine suffered a hardware problem that blocked normal update for some time (months?). After that the existing rpm program on the machine can not handle the upgrade because it can not handle the new compression scheme, and she can not build a new rpm program on her machine, either, because of bug after bug that has been closed without solution. That's my understanding from memory and with gaps. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Sun, Feb 28, 2021 at 03:56:51AM +0100, Carlos E. R. wrote:
On 10/02/2021 03.16, Simon Lees wrote:
On 2/10/21 4:18 AM, L A Walsh wrote:
On 2021/02/09 05:34, bugzilla_noreply@suse.com <mailto:bugzilla_noreply@suse.com> wrote:
the rpmbuild shipped with openSUSE is the exact binary I am trying to build. You are claiming I need some specific version of rpm, like rpm-4.15-build to build rpm-4.15? Too clearly, that is not possibly. The rpm.spec is supposed to include the requirements needed to build that rpm. It doesn't specify a version of rpm.
Yep this is a minor rpm packaging bug, you could file a bug and the maintainer will fix it if they have time, alternatively it would probably take you 10 minutes to fork the package on obs fix it then resubmit it, i'm happy to help with that process if you'd like.
If my memory serves, the bug was submitted and rejected. It is a major issue for L A Walsh, her machine is not upgradeable because of this failure.
No, the root cause is something different. Having rpm 4.11 which was obsoleted in 2014 on a Tumbleweed machine in 2020 is definitely a configuration problem. It is quite possible to use rpm packages from obsolete Leap releases for increental upgrade. Thanks Michal
On 28/02/2021 10.07, Michal Suchánek wrote:
On Sun, Feb 28, 2021 at 03:56:51AM +0100, Carlos E. R. wrote:
On 10/02/2021 03.16, Simon Lees wrote:
On 2/10/21 4:18 AM, L A Walsh wrote:
On 2021/02/09 05:34, bugzilla_noreply@suse.com <mailto:bugzilla_noreply@suse.com> wrote:
the rpmbuild shipped with openSUSE is the exact binary I am trying to build. You are claiming I need some specific version of rpm, like rpm-4.15-build to build rpm-4.15? Too clearly, that is not possibly. The rpm.spec is supposed to include the requirements needed to build that rpm. It doesn't specify a version of rpm.
Yep this is a minor rpm packaging bug, you could file a bug and the maintainer will fix it if they have time, alternatively it would probably take you 10 minutes to fork the package on obs fix it then resubmit it, i'm happy to help with that process if you'd like.
If my memory serves, the bug was submitted and rejected. It is a major issue for L A Walsh, her machine is not upgradeable because of this failure.
No, the root cause is something different. Having rpm 4.11 which was obsoleted in 2014 on a Tumbleweed machine in 2020 is definitely a configuration problem. It is quite possible to use rpm packages from obsolete Leap releases for increental upgrade.
Se has 4.11, if memory serves, because a hardware problem impeded updating for some time (months), and when she finally could attempt the update it was impossible because packages were compressed with a different compressor that 4.11 would not process. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 28.02.21 13:08, Carlos E. R. wrote:
Se has 4.11, if memory serves, because a hardware problem impeded updating for some time (months),
over 6 years are "some months"?
and when she finally could attempt the update it was impossible because packages were compressed with a different compressor that 4.11 would not process. Then, doing incremental updates (to the 13.2 version first, then 42.{123],15.{012} to finally Tumbleweed would have been the way to try to fix this. Or just booting from the DVD and updating from there.
But Linda obviously is not interested in a solution, but in the problem, at least that's the impression I have gained throughout this thread. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 28/02/2021 13.49, Stefan Seyfried wrote:
On 28.02.21 13:08, Carlos E. R. wrote:
Se has 4.11, if memory serves, because a hardware problem impeded updating for some time (months),
over 6 years are "some months"?
I don't know when this happened. Yes, AFAIR the machine was off for some months.
and when she finally could attempt the update it was impossible because packages were compressed with a different compressor that 4.11 would not process. Then, doing incremental updates (to the 13.2 version first, then
No, she was on Tumbleweed. When connected zypper dup failed.
42.{123],15.{012} to finally Tumbleweed would have been the way to try to fix this. Or just booting from the DVD and updating from there.
But Linda obviously is not interested in a solution, but in the problem, at least that's the impression I have gained throughout this thread.
You have to take the context in consideration and read or remember the rest of threads. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Sonntag, 28. Februar 2021 14:55:31 CET Carlos E.R. wrote:
On 28/02/2021 13.49, Stefan Seyfried wrote:
On 28.02.21 13:08, Carlos E. R. wrote:
Se has 4.11, if memory serves, because a hardware problem impeded updating for some time (months),
over 6 years are "some months"?
I don't know when this happened. Yes, AFAIR the machine was off for some months.
and when she finally could attempt the update it was impossible because packages were compressed with a different compressor that 4.11 would not process.
Then, doing incremental updates (to the 13.2 version first, then
No, she was on Tumbleweed. When connected zypper dup failed.
No, she was on Frankenweed, Linda Walsh edition.
42.{123],15.{012} to finally Tumbleweed would have been the way to try to fix this. Or just booting from the DVD and updating from there.
But Linda obviously is not interested in a solution, but in the problem, at least that's the impression I have gained throughout this thread.
You have to take the context in consideration and read or remember the rest of threads.
One has also to take into consideration Lindas complaints from the past. Whatever she has installed on her computer(s), it by no way resembles any Leap or Tumbleweed release, but a more or less random selection of packages thereof. She can install whatever she wants, but as the saying goes, "If you break it, you may keep both parts". Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On 28.02.21 14:55, Carlos E.R. wrote:
On 28/02/2021 13.49, Stefan Seyfried wrote:
On 28.02.21 13:08, Carlos E. R. wrote:
Se has 4.11, if memory serves, because a hardware problem impeded updating for some time (months),
over 6 years are "some months"?
I don't know when this happened. Yes, AFAIR the machine was off for some months.
But 4.11 is apparently, as mentioned in this thread, gone from tumbleweed since 2014.
and when she finally could attempt the update it was impossible because packages were compressed with a different compressor that 4.11 would not process. Then, doing incremental updates (to the 13.2 version first, then
No, she was on Tumbleweed. When connected zypper dup failed.
Yes. Since 6 year old tumbleweed snapshots will be hard to find, she would need to find a path to update to current rpm. And one of these paths would be to use the -- still available on the internet -- rpm versions of released Leap products to get up to a rpm version that can install the current tumbleweed rpm.
42.{123],15.{012} to finally Tumbleweed would have been the way to try to fix this. Or just booting from the DVD and updating from there.
But Linda obviously is not interested in a solution, but in the problem, at least that's the impression I have gained throughout this thread.
You have to take the context in consideration and read or remember the rest of threads.
That is exactly how I came to this conclusion. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Tue, Feb 9, 2021 at 9:16 PM Simon Lees <sflees@suse.de> wrote:
On 2/10/21 4:18 AM, L A Walsh wrote:
On 2021/02/09 05:34, bugzilla_noreply@suse.com <mailto:bugzilla_noreply@suse.com> wrote:
Richard Brown <mailto:rbrown@suse.com> changed bug 1180367 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367> <http://bugzilla.opensuse.org/show_bug.cgi?id=1180367 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367>> What Removed Added Status REOPENED RESOLVED CC rbrown@suse.com <mailto:rbrown@suse.com> Resolution --- INVALID
*Comment # 7 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367#c7> <http://bugzilla.opensuse.org/show_bug.cgi?id=1180367#c7 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367#c7>> on bug 1180367 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367> <http://bugzilla.opensuse.org/show_bug.cgi?id=1180367 <https://bugzilla.opensuse.org/show_bug.cgi?id=1180367>> from Richard Brown <mailto:rbrown@suse.com> *
Due to the following reasons, this bug is INVALID
1) Title is factually incorrect - complete sources are shipped. This alone makes this bug INVALID.
--- The rpms are supposed to include the source needed to regenerate a package. Using the source rpm for a specific binary doesn't allow for generation. Thus the claim that the complete sources for generating a given binary package. That users cannot generate a given binary rpm from the source rpm has been been noted by others on the public lists.
The source rpm's should include all the source needed to regenerate a package, under the right environment which involves a version of rpm that is new enough, and having the right macro's / defines for leap you can find them here https://build.opensuse.org/projects/openSUSE:Leap:15.2/prjconf I guess someone could make an argument that the project config could go in source rpm's however this would make it harder to rebuild a source rpm for a different distro.
Actually, we should be migrating macros and definitions from the OBS prjconf into packages. Most macros defined in the prjconf *are* already migrated to macros packages, with the notable exception of the release macros (%suse_version, %sle_version, etc. which should be in openSUSE-release or rpm-config-SUSE) and the compiler macros (which should be in rpm-config-SUSE). When I first created rpm-config-SUSE, I *had* migrated these into that package[1][2][3], but that work was not carried over by the final version of the package that was shipped into openSUSE. Part of the reason I had done that migration was to enable doing builds of distribution packages properly *without* being connected to the openSUSE Build Service. As it stands today, you actually *cannot* build packages in openSUSE the same way they're done in OBS because the compiler macro definitions are not available in the distribution itself. This was particularly a problem for me when I tried to do CI or test builds of packages (which would be outside of OBS). I would like to have this fixed someday before SUSE Linux Enterprise 16 is branched from Tumbleweed, but I don't know if I want to push that boulder up that mountain again... [1]: https://github.com/openSUSE/rpm-config-SUSE/blob/neal/macros.d/suse_dist_mac... [2]: https://github.com/openSUSE/rpm-config-SUSE/blob/neal/suse/macros [3]: https://github.com/openSUSE/rpm-config-SUSE/blob/neal/suse/rpmrc -- 真実はいつも一つ！/ Always, there's only one truth!
On 09/02/2021 18.48, L A Walsh wrote:
the rpmbuild shipped with openSUSE is the exact binary I am trying to build. You are claiming I need some specific version of rpm, like rpm-4.15-build to build rpm-4.15
This very much reminds me of what the people over at http://bootstrappable.org/ are trying to do. They struggle with things like Haskell's ghc that needs ghc to build. The solution here would be to find the intermediate version of rpm-4.15 that did not require rpm-4.15 yet. E.g. try https://code.opensuse.org/package/rpm/c/eb41fdc109 The other parts are just plain reproducible builds [1]. You can use my 'nachbau' script from https://github.com/bmwiedemann/reproducibleopensuse/ on a checkout of the sources. I.e. osc co openSUSE:Factory/rpm && cd $_ nachbau Currently, it still needs OBS to provide the prjconf and to resolve+fetch build dependencies, but that will be improved sooner or later. And I still need to invest some effort to publish my index of old binary rpms[2]. We are not so far away from being able to build from https://code.opensuse.org/package/rpm Also worth noting, that the _buildenv file available at https://build.opensuse.org/package/binaries/openSUSE:Factory/rpm/standard now contains the prjconf that was used to build this artifact, because it can affect the build result. It also contains info on what exact version of what BuildRequires was used. Ciao Bernhard M. [1] https://reproducible-builds.org/ [2] http://opensuse.zq1.de/history/
On Wed, 10 Feb 2021, Bernhard M. Wiedemann wrote:
On 09/02/2021 18.48, L A Walsh wrote:
the rpmbuild shipped with openSUSE is the exact binary I am trying to build. You are claiming I need some specific version of rpm, like rpm-4.15-build to build rpm-4.15
This very much reminds me of what the people over at http://bootstrappable.org/ are trying to do. They struggle with things like Haskell's ghc that needs ghc to build.
The solution here would be to find the intermediate version of rpm-4.15 that did not require rpm-4.15 yet. E.g. try https://code.opensuse.org/package/rpm/c/eb41fdc109
It's of course also "nice" if these kind of core packages do not try to live on the edge with respect to these kind of features... For rpm itself you can of course "bootstrap" it by editing out the not supported parts in the .spec file and build a "bootstrap" rpm (of the newer version) you can then use to (re-)build the original unaltered sources. There's similar issues with gcc packages which require an Ada compiler to build the Ada compiler parts. Richard.
The other parts are just plain reproducible builds [1]. You can use my 'nachbau' script from https://github.com/bmwiedemann/reproducibleopensuse/ on a checkout of the sources. I.e. osc co openSUSE:Factory/rpm && cd $_ nachbau
Currently, it still needs OBS to provide the prjconf and to resolve+fetch build dependencies, but that will be improved sooner or later. And I still need to invest some effort to publish my index of old binary rpms[2].
We are not so far away from being able to build from https://code.opensuse.org/package/rpm
Also worth noting, that the _buildenv file available at https://build.opensuse.org/package/binaries/openSUSE:Factory/rpm/standard now contains the prjconf that was used to build this artifact, because it can affect the build result. It also contains info on what exact version of what BuildRequires was used.
Ciao Bernhard M.
[1] https://reproducible-builds.org/ [2] http://opensuse.zq1.de/history/
-- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
participants (11)
-
Bernhard M. Wiedemann -
Carlos E. R. -
Carlos E. R. -
Carlos E.R. -
L A Walsh -
Michal Suchánek -
Neal Gompa -
Richard Biener -
Simon Lees -
Stefan Brüns -
Stefan Seyfried