[opensuse-factory] Re: rpmbuild error, result of circular deps, result: source not included with gnu binaries.
TLDR: rpm(s) >= 4.15, can't be read, built or installed by rpm < 4.15 (specifically, 4.11). On 2020/10/29 03:55, Simon Lees wrote:
I asked:
I don't suppose anyone thought about how users who missed a few months of internet connectivity might resync or make use of the new format rpms if they can't even install + build source-rpms.
I'm not sure how much we claim to support building openSUSE rpm's as source rpm's on there own. openSUSE rpm spec files often depend on variables that are defined in project config files in open build service, as such just using rpmbuild may result in packages not building or building with different configurations.
---- But is *installing* "rpms" from tumbleweed, with "rpm" on a tumbleweed install, supported? The reason I was trying to build _rpm_ from source is to get an rpm with the "PayloadIsZstd" feature, since my local rpm doesn't have that feature. It really wouldn't help to build rpm on OBS if it would just give me an 'rpm' that I can't install on my machine due to prereqs. The thing is, is that I was able to get down to building "rpm" but only had PayloadIsZstd as a requirement of a local attempt to build that would run with the packages and libraries I currently have installed. I don't want to rebuild the same uninstallable binary rpm package that is currently distributed with "encrypted" (using a "secret", new new encoding(compression lib) that can _only_ be built from packages that require the same encoding in order to be installed. I.e. I can't install the binary rpm, because it has 8 pre-reqs on other rpm packages that expand to some 30+ packages all that cannot be installed due to the fact that they require the "PayloadIsZstd" rpm feature. I find myself unable to build the binary rpm on my system because it requires 'devel' packages all that require the 'PayloadisZstd'. I tried building the Zstd lib, but it also requires binary packages that require the same feature -- i.e. a **circular dependency**. This disallows INSTALLING any needed rpm's that one might need to even build those same rpm's from their source rpms. I realize that sources for GNU licensed binaries appears to be included but the sources for those new binaries are inaccessible because they are encoded in the new compression scheme. I'm pretty sure that requiring a user to only build tools in suse's OBS, as a pre-condition for satisfying GNU's requirement for including source with redistributed binaries is not considered a valid way of establishing a "locally trusted" build environment. _Part_ of the reason the sources are open is that the user may regenerate binaries on their local machines to satisfy various "chain of trust" requirements on the build tools and machine. This, ultimately, boils down to variations on Ken Thompson's "Reflections on Trusting Trust" (as from: http://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustin... ). Perhaps this sounds a bit remote, but being unable to install rpm's because rpm can't read +install the dependency libs it needs to run itself, reminds me a bit of having 'mount' on your root partition and a 'libmount' on a yet-to-be-mounted '/usr/ partition. :-/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op zaterdag 7 november 2020 05:10:54 CET schreef L A Walsh:
TLDR: rpm(s) >= 4.15, can't be read, built or installed by rpm < 4.15 (specifically, 4.11).
On 2020/10/29 03:55, Simon Lees wrote:
I asked:
I don't suppose anyone thought about how users who missed a few months of internet connectivity might resync or make use of the new format rpms if they can't even install + build source-rpms.
I'm not sure how much we claim to support building openSUSE rpm's as source rpm's on there own. openSUSE rpm spec files often depend on variables that are defined in project config files in open build service, as such just using rpmbuild may result in packages not building or building with different configurations.
---- But is *installing* "rpms" from tumbleweed, with "rpm" on a tumbleweed install, supported?
The reason I was trying to build _rpm_ from source is to get an rpm with the "PayloadIsZstd" feature, since my local rpm doesn't have that feature. It really wouldn't help to build rpm on OBS if it would just give me an 'rpm' that I can't install on my machine due to prereqs.
The thing is, is that I was able to get down to building "rpm" but only had PayloadIsZstd as a requirement of a local attempt to build that would run with the packages and libraries I currently have installed.
I don't want to rebuild the same uninstallable binary rpm package that is currently distributed with "encrypted" (using a "secret", new new encoding(compression lib) that can _only_ be built from packages that require the same encoding in order to be installed.
I.e. I can't install the binary rpm, because it has 8 pre-reqs on other rpm packages that expand to some 30+ packages all that cannot be installed due to the fact that they require the "PayloadIsZstd" rpm feature.
I find myself unable to build the binary rpm on my system because it requires 'devel' packages all that require the 'PayloadisZstd'.
I tried building the Zstd lib, but it also requires binary packages that require the same feature -- i.e. a **circular dependency**. This disallows INSTALLING any needed rpm's that one might need to even build those same rpm's from their source rpms. I realize that sources for GNU licensed binaries appears to be included but the sources for those new binaries are inaccessible because they are encoded in the new compression scheme.
I'm pretty sure that requiring a user to only build tools in suse's OBS, as a pre-condition for satisfying GNU's requirement for including source with redistributed binaries is not considered a valid way of establishing a "locally trusted" build environment. _Part_ of the reason the sources are open is that the user may regenerate binaries on their local machines to satisfy various "chain of trust" requirements on the build tools and machine.
This, ultimately, boils down to variations on Ken Thompson's "Reflections on Trusting Trust" (as from: http://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustin gTrust.pdf ).
Perhaps this sounds a bit remote, but being unable to install rpm's because rpm can't read +install the dependency libs it needs to run itself, reminds me a bit of having 'mount' on your root partition and a 'libmount' on a yet-to-be-mounted '/usr/ partition. :-/ Did you ever hear of zypper ?
-- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 07/11/2020 05.22, Knurpht-openSUSE wrote:
Op zaterdag 7 november 2020 05:10:54 CET schreef L A Walsh:
TLDR: rpm(s) >= 4.15, can't be read, built or installed by rpm < 4.15 (specifically, 4.11).
On 2020/10/29 03:55, Simon Lees wrote:
I asked:
I don't suppose anyone thought about how users who missed a few months of internet connectivity might resync or make use of the new format rpms if they can't even install + build source-rpms.
I'm not sure how much we claim to support building openSUSE rpm's as source rpm's on there own. openSUSE rpm spec files often depend on variables that are defined in project config files in open build service, as such just using rpmbuild may result in packages not building or building with different configurations.
---- But is *installing* "rpms" from tumbleweed, with "rpm" on a tumbleweed install, supported?
The reason I was trying to build _rpm_ from source is to get an rpm with the "PayloadIsZstd" feature, since my local rpm doesn't have that feature. It really wouldn't help to build rpm on OBS if it would just give me an 'rpm' that I can't install on my machine due to prereqs.
The thing is, is that I was able to get down to building "rpm" but only had PayloadIsZstd as a requirement of a local attempt to build that would run with the packages and libraries I currently have installed.
I don't want to rebuild the same uninstallable binary rpm package that is currently distributed with "encrypted" (using a "secret", new new encoding(compression lib) that can _only_ be built from packages that require the same encoding in order to be installed.
I.e. I can't install the binary rpm, because it has 8 pre-reqs on other rpm packages that expand to some 30+ packages all that cannot be installed due to the fact that they require the "PayloadIsZstd" rpm feature.
I find myself unable to build the binary rpm on my system because it requires 'devel' packages all that require the 'PayloadisZstd'.
I tried building the Zstd lib, but it also requires binary packages that require the same feature -- i.e. a **circular dependency**. This disallows INSTALLING any needed rpm's that one might need to even build those same rpm's from their source rpms. I realize that sources for GNU licensed binaries appears to be included but the sources for those new binaries are inaccessible because they are encoded in the new compression scheme.
I'm pretty sure that requiring a user to only build tools in suse's OBS, as a pre-condition for satisfying GNU's requirement for including source with redistributed binaries is not considered a valid way of establishing a "locally trusted" build environment. _Part_ of the reason the sources are open is that the user may regenerate binaries on their local machines to satisfy various "chain of trust" requirements on the build tools and machine.
This, ultimately, boils down to variations on Ken Thompson's "Reflections on Trusting Trust" (as from: http://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustin gTrust.pdf ).
Perhaps this sounds a bit remote, but being unable to install rpm's because rpm can't read +install the dependency libs it needs to run itself, reminds me a bit of having 'mount' on your root partition and a 'libmount' on a yet-to-be-mounted '/usr/ partition. :-/ Did you ever hear of zypper ?
AFAIK, zypper uses the command rpm or the rpm libraries to do the actual installation. Same problem. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sun, Nov 8, 2020 at 1:46 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 07/11/2020 05.22, Knurpht-openSUSE wrote:
Op zaterdag 7 november 2020 05:10:54 CET schreef L A Walsh:
TLDR: rpm(s) >= 4.15, can't be read, built or installed by rpm < 4.15 (specifically, 4.11).
On 2020/10/29 03:55, Simon Lees wrote:
I asked:
I don't suppose anyone thought about how users who missed a few months of internet connectivity might resync or make use of the new format rpms if they can't even install + build source-rpms.
I'm not sure how much we claim to support building openSUSE rpm's as source rpm's on there own. openSUSE rpm spec files often depend on variables that are defined in project config files in open build service, as such just using rpmbuild may result in packages not building or building with different configurations.
---- But is *installing* "rpms" from tumbleweed, with "rpm" on a tumbleweed install, supported?
The reason I was trying to build _rpm_ from source is to get an rpm with the "PayloadIsZstd" feature, since my local rpm doesn't have that feature. It really wouldn't help to build rpm on OBS if it would just give me an 'rpm' that I can't install on my machine due to prereqs.
The thing is, is that I was able to get down to building "rpm" but only had PayloadIsZstd as a requirement of a local attempt to build that would run with the packages and libraries I currently have installed.
I don't want to rebuild the same uninstallable binary rpm package that is currently distributed with "encrypted" (using a "secret", new new encoding(compression lib) that can _only_ be built from packages that require the same encoding in order to be installed.
I.e. I can't install the binary rpm, because it has 8 pre-reqs on other rpm packages that expand to some 30+ packages all that cannot be installed due to the fact that they require the "PayloadIsZstd" rpm feature.
I find myself unable to build the binary rpm on my system because it requires 'devel' packages all that require the 'PayloadisZstd'.
I tried building the Zstd lib, but it also requires binary packages that require the same feature -- i.e. a **circular dependency**. This disallows INSTALLING any needed rpm's that one might need to even build those same rpm's from their source rpms. I realize that sources for GNU licensed binaries appears to be included but the sources for those new binaries are inaccessible because they are encoded in the new compression scheme.
I'm pretty sure that requiring a user to only build tools in suse's OBS, as a pre-condition for satisfying GNU's requirement for including source with redistributed binaries is not considered a valid way of establishing a "locally trusted" build environment. _Part_ of the reason the sources are open is that the user may regenerate binaries on their local machines to satisfy various "chain of trust" requirements on the build tools and machine.
This, ultimately, boils down to variations on Ken Thompson's "Reflections on Trusting Trust" (as from: http://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustin gTrust.pdf ).
Perhaps this sounds a bit remote, but being unable to install rpm's because rpm can't read +install the dependency libs it needs to run itself, reminds me a bit of having 'mount' on your root partition and a 'libmount' on a yet-to-be-mounted '/usr/ partition. :-/ Did you ever hear of zypper ?
AFAIK, zypper uses the command rpm or the rpm libraries to do the actual installation. Same problem.
openSUSE Tumbleweed maintains backward compatibility to the latest openSUSE Leap/SLE 15.x release. Compatibility beyond that is not assured in any way. You should update your SLE 12 system to SLE 15, if you can. Alternatively, you can use a tool like Mock[1] or osc[2] to bypass this restriction. [1]: https://github.com/rpm-software-management/mock/wiki [2]: https://en.opensuse.org/openSUSE:Build_Service_Tutorial#Build_your_package_l... -- 真実はいつも一つ！/ 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 08/11/2020 20.06, Neal Gompa wrote:
On Sun, Nov 8, 2020 at 1:46 PM Carlos E. R. <> wrote:
On 07/11/2020 05.22, Knurpht-openSUSE wrote:
Op zaterdag 7 november 2020 05:10:54 CET schreef L A Walsh:
TLDR: rpm(s) >= 4.15, can't be read, built or installed by rpm < 4.15 (specifically, 4.11).
On 2020/10/29 03:55, Simon Lees wrote:
I asked:
I don't suppose anyone thought about how users who missed a few months of internet connectivity might resync or make use of the new format rpms if they can't even install + build source-rpms.
I'm not sure how much we claim to support building openSUSE rpm's as source rpm's on there own. openSUSE rpm spec files often depend on variables that are defined in project config files in open build service, as such just using rpmbuild may result in packages not building or building with different configurations.
---- But is *installing* "rpms" from tumbleweed, with "rpm" on a tumbleweed install, supported?
The reason I was trying to build _rpm_ from source is to get an rpm with the "PayloadIsZstd" feature, since my local rpm doesn't have that feature. It really wouldn't help to build rpm on OBS if it would just give me an 'rpm' that I can't install on my machine due to prereqs.
The thing is, is that I was able to get down to building "rpm" but only had PayloadIsZstd as a requirement of a local attempt to build that would run with the packages and libraries I currently have installed.
I don't want to rebuild the same uninstallable binary rpm package that is currently distributed with "encrypted" (using a "secret", new new encoding(compression lib) that can _only_ be built from packages that require the same encoding in order to be installed.
I.e. I can't install the binary rpm, because it has 8 pre-reqs on other rpm packages that expand to some 30+ packages all that cannot be installed due to the fact that they require the "PayloadIsZstd" rpm feature.
I find myself unable to build the binary rpm on my system because it requires 'devel' packages all that require the 'PayloadisZstd'.
I tried building the Zstd lib, but it also requires binary packages that require the same feature -- i.e. a **circular dependency**. This disallows INSTALLING any needed rpm's that one might need to even build those same rpm's from their source rpms. I realize that sources for GNU licensed binaries appears to be included but the sources for those new binaries are inaccessible because they are encoded in the new compression scheme.
I'm pretty sure that requiring a user to only build tools in suse's OBS, as a pre-condition for satisfying GNU's requirement for including source with redistributed binaries is not considered a valid way of establishing a "locally trusted" build environment. _Part_ of the reason the sources are open is that the user may regenerate binaries on their local machines to satisfy various "chain of trust" requirements on the build tools and machine.
This, ultimately, boils down to variations on Ken Thompson's "Reflections on Trusting Trust" (as from: http://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustin gTrust.pdf ).
Perhaps this sounds a bit remote, but being unable to install rpm's because rpm can't read +install the dependency libs it needs to run itself, reminds me a bit of having 'mount' on your root partition and a 'libmount' on a yet-to-be-mounted '/usr/ partition. :-/ Did you ever hear of zypper ?
AFAIK, zypper uses the command rpm or the rpm libraries to do the actual installation. Same problem.
openSUSE Tumbleweed maintains backward compatibility to the latest openSUSE Leap/SLE 15.x release. Compatibility beyond that is not assured in any way. You should update your SLE 12 system to SLE 15, if you can.
She needs forward compatibility. She has to update a TW machine that was not working for two months, so that it missed the rpm upgrade to the new payload compression scheme. Zypper fails because the packages she now downloads are compressed with an algorithm that the zypper and rpm she has in the machine can not decode. L A Walsh, check this: https://lists.opensuse.org/opensuse-factory/2018-02/msg01152.html http://download.opensuse.org/history/
Alternatively, you can use a tool like Mock[1] or osc[2] to bypass this restriction.
[1]: https://github.com/rpm-software-management/mock/wiki [2]: https://en.opensuse.org/openSUSE:Build_Service_Tutorial#Build_your_package_l...
-- 真実はいつも一つ！/ Always, there's only one truth!
-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sunday 2020-11-08 20:27, Carlos E. R. wrote:
openSUSE Tumbleweed maintains backward compatibility to the latest openSUSE Leap/SLE 15.x release. Compatibility beyond that is not assured in any way. You should update your SLE 12 system to SLE 15, if you can.
She needs forward compatibility.
She has to update a TW machine that was not working for two months, so that it missed the rpm upgrade to the new payload compression scheme. Zypper fails because the packages she now downloads are compressed with an algorithm that the zypper and rpm she has in the machine can not decode.
That's why rpm itself is always packaged with bzip2, so that you can upgrade rpm using rpm to a version that knows how to decode zstd. But, what do I see just now, is that rpm's deps are not bzip2. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 08/11/2020 20.47, Jan Engelhardt wrote:
On Sunday 2020-11-08 20:27, Carlos E. R. wrote:
openSUSE Tumbleweed maintains backward compatibility to the latest openSUSE Leap/SLE 15.x release. Compatibility beyond that is not assured in any way. You should update your SLE 12 system to SLE 15, if you can.
She needs forward compatibility.
She has to update a TW machine that was not working for two months, so that it missed the rpm upgrade to the new payload compression scheme. Zypper fails because the packages she now downloads are compressed with an algorithm that the zypper and rpm she has in the machine can not decode.
That's why rpm itself is always packaged with bzip2, so that you can upgrade rpm using rpm to a version that knows how to decode zstd.
But, what do I see just now, is that rpm's deps are not bzip2.
Right. So she would need a version of rpm with static linking. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sunday 2020-11-08 21:06, Carlos E. R. wrote:
On Sunday 2020-11-08 20:27, Carlos E. R. wrote:
openSUSE Tumbleweed maintains backward compatibility to the latest openSUSE Leap/SLE 15.x release. Compatibility beyond that is not assured in any way. You should update your SLE 12 system to SLE 15, if you can.
She needs forward compatibility.
She has to update a TW machine that was not working for two months, so that it missed the rpm upgrade to the new payload compression scheme. Zypper fails because the packages she now downloads are compressed with an algorithm that the zypper and rpm she has in the machine can not decode.
That's why rpm itself is always packaged with bzip2, so that you can upgrade rpm using rpm to a version that knows how to decode zstd.
But, what do I see just now, is that rpm's deps are not bzip2.
Right. So she would need a version of rpm with static linking.
It'd be easier to just build the deps with appropriate compression. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Citeren Jan Engelhardt <jengelh@inai.de>:
On Sunday 2020-11-08 20:27, Carlos E. R. wrote:
openSUSE Tumbleweed maintains backward compatibility to the latest openSUSE Leap/SLE 15.x release. Compatibility beyond that is not assured in any way. You should update your SLE 12 system to SLE 15, if you can.
She needs forward compatibility.
She has to update a TW machine that was not working for two months, so that it missed the rpm upgrade to the new payload compression scheme. Zypper fails because the packages she now downloads are compressed with an algorithm that the zypper and rpm she has in the machine can not decode.
That's why rpm itself is always packaged with bzip2, so that you can upgrade rpm using rpm to a version that knows how to decode zstd.
But, what do I see just now, is that rpm's deps are not bzip2.
The rpm package in Factory requires libbz2.so.1()(64bit) (which is provided by libbz2-1, the bzip2 runtime library), so that should be fine as far as I can see. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2020-11-09 12:38, Arjen de Korte wrote:
She has to update a TW machine that was not working for two months, so that it missed the rpm upgrade to the new payload compression scheme. Zypper fails because the packages she now downloads are compressed with an algorithm that the zypper and rpm she has in the machine can not decode.
That's why rpm itself is always packaged with bzip2, so that you can upgrade rpm using rpm to a version that knows how to decode zstd.
But, what do I see just now, is that rpm's deps are not bzip2.
The rpm package in Factory requires libbz2.so.1()(64bit) (which is provided by libbz2-1, the bzip2 runtime library), so that should be fine as far as I can see.
No, I'm talking about rpm -q --requires glibc | grep -i payload -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/7/20 2:40 PM, L A Walsh wrote:
TLDR: rpm(s) >= 4.15, can't be read, built or installed by rpm < 4.15 (specifically, 4.11).
On 2020/10/29 03:55, Simon Lees wrote:
I asked:
I don't suppose anyone thought about how users who missed a few months of internet connectivity might resync or make use of the new format rpms if they can't even install + build source-rpms.
I'm not sure how much we claim to support building openSUSE rpm's as source rpm's on there own. openSUSE rpm spec files often depend on variables that are defined in project config files in open build service, as such just using rpmbuild may result in packages not building or building with different configurations.
But is *installing* "rpms" from tumbleweed, with "rpm" on a tumbleweed install, supported?
Well we still support upgrading from Leap to Tumbleweed and upgrading older tumbleweed installs so if people update using the supported method of zypper dup someone has put in the effort to make it work I haven't looked at how they have done that.
The reason I was trying to build _rpm_ from source is to get an rpm with the "PayloadIsZstd" feature, since my local rpm doesn't have that feature. It really wouldn't help to build rpm on OBS if it would just give me an 'rpm' that I can't install on my machine due to prereqs.
The thing is, is that I was able to get down to building "rpm" but only had PayloadIsZstd as a requirement of a local attempt to build that would run with the packages and libraries I currently have installed.
I don't want to rebuild the same uninstallable binary rpm package that is currently distributed with "encrypted" (using a "secret", new new encoding(compression lib) that can _only_ be built from packages that require the same encoding in order to be installed.
I.e. I can't install the binary rpm, because it has 8 pre-reqs on other rpm packages that expand to some 30+ packages all that cannot be installed due to the fact that they require the "PayloadIsZstd" rpm feature.
I find myself unable to build the binary rpm on my system because it requires 'devel' packages all that require the 'PayloadisZstd'.
I tried building the Zstd lib, but it also requires binary packages that require the same feature -- i.e. a **circular dependency**. This disallows INSTALLING any needed rpm's that one might need to even build those same rpm's from their source rpms. I realize that sources for GNU licensed binaries appears to be included but the sources for those new binaries are inaccessible because they are encoded in the new compression scheme.
I'm pretty sure that requiring a user to only build tools in suse's OBS, as a pre-condition for satisfying GNU's requirement for including source with redistributed binaries is not considered a valid way of establishing a "locally trusted" build environment. _Part_ of the reason the sources are open is that the user may regenerate binaries on their local machines to satisfy various "chain of trust" requirements on the build tools and machine.
In a supported up to date system we provide all the tools required to view and install source rpm's, additionally to the tools you'd expect programs such as ark can open and read our rpm's just fine.
This, ultimately, boils down to variations on Ken Thompson's "Reflections on Trusting Trust" (as from: http://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustin...
From our build service you can find and inspect all the build logs along with the source tarballs, beyond that obs has the ability to verify that upstream tarballs have been used along with signature checking. The Reproducible builds team has also done a lot of work in this area so generally i'd say we are doing better then most distro's. -- 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 2020/11/07 02:51, Simon Lees wrote:
On 11/7/20 2:40 PM, L A Walsh wrote:
TLDR: rpm(s) >= 4.15, can't be read, built or installed by rpm < 4.15 (specifically, 4.11).
On 2020/10/29 03:55, Simon Lees wrote:
I'm not sure how much we claim to support building openSUSE rpm's as source rpm's on there own. openSUSE rpm spec files often depend on variables that are defined in project config files in open build service, as such just using rpmbuild may result in packages not building or building with different configurations.
---- But is *installing* "rpms" from tumbleweed, with "rpm" on a tumbleweed install, supported?
Well we still support upgrading from Leap to Tumbleweed and upgrading older tumbleweed installs so if people update using the supported method of zypper dup someone has put in the effort to make it work I haven't looked at how they have done that.
In a supported up to date system we provide all the tools required to view and install source rpm's,
But not build? The point here, is that my linux server was off-the-internet for a couple of months. Before it went off line, I was able to install rpm's from tumbleweed or build them. After a few months offline, my system came back online but without my local copies of the tumbleweed repo. I downloaded a copy and found I wasn't able to install any binary packages due to the binary format changing. Simply trying to build from the source required I install other binary (all 'devel') packages that were unreadable/inaccessible. FWIW, system was offline because of main disks becoming corrupted by a flakily repaired RAID card that eventually overheated due to the bad repair -- I didn't know it was bad until I got a replacement and noticed that the older card probably wasn't 'new' -- it was missing pressure screws that held a heat sink on a hot chip -- and to keep it on, someone had used something like superglue -- not a great heat conductor IMO. While the backup went offline as well and had some problems, I was able, with new enclosures and a new card, to restore OS+most files from those backups. The problem was keeping my system "up-to-date" when the primary disks were down -- obviously that was not possible. This was an up-to-date system, that got out of sync as a transition was made to a new rpm format. One of the problems I am highlighting is the inability to resync a local installation after being forced offline for a few months. This is being complicated by suse-rpms's that, it seems, are no longer supported being used to rebuild rpms locally, primarily because there is no stand-alone converter to convert binary-rpms to a readable format for systems more than a few months old (more like 6 months, now) that only have the old rpm installed and don't have a matching set of binary-rpms for what is installed. They were on a disk that wasn't part of the backups because I had just downloaded them and thought I'd be able to do so again.
...boils down to variations ..."Reflections on Trusting Trust" (as from: http://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustin...
From our build service you can find and inspect all the build logs along with the source tarballs, beyond that obs has the ability to verify that upstream tarballs have been used along with signature checking. The Reproducible builds team has also done a lot of work in this area so generally i'd say we are doing better then most distro's.
---- That may be true, I haven't examined enough others to say, but that doesn't address the ability to build locally or examine which patches get applied to various rpms during the build process. Some of suse's rpm's apply huge numbers of unsigned patches...for example, in looking at opensuse's rpm source for 4.15.1, there are 63 patches. Then there are: ..."the spec files" that include dependencies and variables "that are [only] defined in project config files in in the open build service". <<< Some or most of those should be able to be set in a script as part of a non-obs build phase. Otherwise, you have: "just using rpmbuild may result in packages not building or building with different configurations". It's the "not building" part that I'm hitting right now. As for zypper -- will try it again, but last try had it trying to switch in over 200 packages -- just to upgrade 'rpm' -- and that was after I ignored some problems. Sigh. -l -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11/8/20 7:50 PM, L A Walsh wrote:
On 2020/11/07 02:51, Simon Lees wrote:
On 11/7/20 2:40 PM, L A Walsh wrote:
TLDR: rpm(s) >= 4.15, can't be read, built or installed by rpm < 4.15 (specifically, 4.11).
On 2020/10/29 03:55, Simon Lees wrote:
I'm not sure how much we claim to support building openSUSE rpm's as source rpm's on there own. openSUSE rpm spec files often depend on variables that are defined in project config files in open build service, as such just using rpmbuild may result in packages not building or building with different configurations.
But is *installing* "rpms" from tumbleweed, with "rpm" on a tumbleweed install, supported?
Well we still support upgrading from Leap to Tumbleweed and upgrading older tumbleweed installs so if people update using the supported method of zypper dup someone has put in the effort to make it work I haven't looked at how they have done that.
In a supported up to date system we provide all the tools required to view and install source rpm's,
But not build?
Not without additional effort, there are a number of macro's and definitions here ( https://build.opensuse.org/projects/openSUSE:Factory/prjconf ) for example that you would need to teach rpm about if you were going to do a build outside open build service.
The point here, is that my linux server was off-the-internet for a couple of months. Before it went off line, I was able to install rpm's from tumbleweed or build them. After a few months offline, my system came back online but without my local copies of the tumbleweed repo. I downloaded a copy and found I wasn't able to install any binary packages due to the binary format changing. Simply trying to build from the source required I install other binary (all 'devel') packages that were unreadable/inaccessible. FWIW, system was offline because of main disks becoming corrupted by a flakily repaired RAID card that eventually overheated due to the bad repair -- I didn't know it was bad until I got a replacement and noticed that the older card probably wasn't 'new' -- it was missing pressure screws that held a heat sink on a hot chip -- and to keep it on, someone had used something like superglue -- not a great heat conductor IMO. While the backup went offline as well and had some problems, I was able, with new enclosures and a new card, to restore OS+most files from those backups.
The problem was keeping my system "up-to-date" when the primary disks were down -- obviously that was not possible. This was an up-to-date system, that got out of sync as a transition was made to a new rpm format. One of the problems I am highlighting is the inability to resync a local installation after being forced offline for a few months. This is being complicated by suse-rpms's that, it seems, are no longer supported being used to rebuild rpms locally, primarily because there is no stand-alone converter to convert binary-rpms to a readable format for systems more than a few months old (more like 6 months, now) that only have the old rpm installed and don't have a matching set of binary-rpms for what is installed. They were on a disk that wasn't part of the backups because I had just downloaded them and thought I'd be able to do so again.
...boils down to variations ..."Reflections on Trusting Trust" (as from: http://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustin...
From our build service you can find and inspect all the build logs along with the source tarballs, beyond that obs has the ability to verify that upstream tarballs have been used along with signature checking. The Reproducible builds team has also done a lot of work in this area so generally i'd say we are doing better then most distro's.
That may be true, I haven't examined enough others to say, but that doesn't address the ability to build locally or examine which patches get applied to various rpms during the build process. Some of suse's rpm's apply huge numbers of unsigned patches...for example, in looking at opensuse's rpm source for 4.15.1, there are 63 patches.
Then there are: ..."the spec files" that include dependencies and variables "that are [only] defined in project config files in in the open build service". <<< Some or most of those should be able to be set in a script as part of a non-obs build phase. Otherwise, you have: "just using rpmbuild may result in packages not building or building with different configurations". It's the "not building" part that I'm hitting right now.
As for zypper -- will try it again, but last try had it trying to switch in over 200 packages -- just to upgrade 'rpm' -- and that was after I ignored some problems. Sigh.
I would expect that if rpm and its dependencies all came from the standard repo and that you had been updating your system with `zypper dup` in the past you should be able to still upgrade your system with `zypper dup` not being able to would be a bug worth reporting. Unfortunetly if you don't have a standard setup there might not be so much we can do to help. -- 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 2020-11-06 20:10:54 -0800, L A Walsh wrote:
TLDR: rpm(s) >= 4.15, can't be read, built or installed by rpm < 4.15 (specifically, 4.11).
Hmm this really depends on what "reading" exactly means (querying the rpm metadata or extracting the (compressed) payload (for instance, via rpm2cpio) should work).
On 2020/10/29 03:55, Simon Lees wrote:
I asked:
I don't suppose anyone thought about how users who missed a few months of internet connectivity might resync or make use of the new format rpms if they can't even install + build source-rpms.
I'm not sure how much we claim to support building openSUSE rpm's as source rpm's on there own. openSUSE rpm spec files often depend on variables that are defined in project config files in open build service, as such just using rpmbuild may result in packages not building or building with different configurations.
But is *installing* "rpms" from tumbleweed, with "rpm" on a tumbleweed install, supported?
The reason I was trying to build _rpm_ from source is to get an rpm with the "PayloadIsZstd" feature, since my local rpm doesn't have that feature. It really wouldn't help to build rpm on OBS if it would just give me an 'rpm' that I can't install on my machine due to prereqs.
Just rebuild it and disable/choose a different payload compression. For instance, adding something like this to the spec file disables payload compression for the binary rpms: %define _binary_payload w.ufdio Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 07/11/2020 05.10, L A Walsh wrote:
TLDR: rpm(s) >= 4.15, can't be read, built or installed by rpm < 4.15 (specifically, 4.11).
On 2020/10/29 03:55, Simon Lees wrote:
I asked:
I don't suppose anyone thought about how users who missed a few months of internet connectivity might resync or make use of the new format rpms if they can't even install + build source-rpms.
I'm not sure how much we claim to support building openSUSE rpm's as source rpm's on there own. openSUSE rpm spec files often depend on variables that are defined in project config files in open build service, as such just using rpmbuild may result in packages not building or building with different configurations.
But is *installing* "rpms" from tumbleweed, with "rpm" on a tumbleweed install, supported?
The reason I was trying to build _rpm_ from source is to get an rpm with the "PayloadIsZstd" feature, since my local rpm doesn't have that feature. It really wouldn't help to build rpm on OBS if it would just give me an 'rpm' that I can't install on my machine due to prereqs.
...
I.e. I can't install the binary rpm, because it has 8 pre-reqs on other rpm packages that expand to some 30+ packages all that cannot be installed due to the fact that they require the "PayloadIsZstd" rpm feature.
There is another way. Install from a TW rescue system that has your installation as target. One way is to download a current TW DVD, boot it, and try to do an "offline upgrade" on your installation. As it uses its own rpm, it will work. If you allow it to connect to internet, it will use remote packages to install if they are not in the DVD. I'm assuming that the TW DVD doesn't have the upgrade functionality disabled. The other alternative would be to boot the TW XFCE Rescue Stick: <http://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-Rescue-CD-i686-Current.iso> (burned to an USB stick) Boot it, mount your system under /mnt, and then use zypper or rpm operating on /mnt. This I have not done in a long time, but it should be possible as it is the mechanism used by the installation DVD to do installs/upgrades. rpm: --root DIRECTORY Use the file system tree rooted at DIRECTORY for all operations. Note that this means the database within DIRECTORY will be used for dependency checks and any scriptlet(s) (e.g. %post if installing, or %prep if building, a package) will be run after a chroot(2) to DIRECTORY. zypper: Target Options: -R, --root dir Operates on a different root directory. This option influences the location of the repos.d directory and the metadata cache directory and also causes rpm to be run with the --root option to do the actual installation or removal of packages. See also the FILES section. --installroot dir Behaves like --root but shares the repositories with the host system. HTH -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Fri, 2020-11-06 at 20:10 -0800, L A Walsh wrote:
TLDR: rpm(s) >= 4.15, can't be read, built or installed by rpm < 4.15 (specifically, 4.11).
On 2020/10/29 03:55, Simon Lees wrote:
I asked:
I don't suppose anyone thought about how users who missed a few months of internet connectivity might resync or make use of the new format rpms if they can't even install + build source-rpms.
I'm not sure how much we claim to support building openSUSE rpm's as source rpm's on there own. openSUSE rpm spec files often depend on variables that are defined in project config files in open build service, as such just using rpmbuild may result in packages not building or building with different configurations.
---- But is *installing* "rpms" from tumbleweed, with "rpm" on a tumbleweed install, supported?
YES - But: as the payload compression changed, we have always been aware that no matter how long we will make the payload change, there will be some user takign n+1 days until they will update. To be clear: we enabled zstd support in RPM in Tumbleweed before we switched to zstd compresson method. And the timing was already quite conservative: RPM had zstd support in Tumbleweed since July 2019 (2019 - aka > 1 year ago) TW changed the default compression scheme to zstd on August 25 2020 (i.e. more than a tear after we added support to rpm reading those payloads) Leap 15.2 also received a maintenannce update to be able to read those zstd payloaded rpms. Upgrading to TW has always been supported from the 'latest openSUSE stable release and from Tumbleweed' A TW user that actually managed to miss the 1-year period to upgrade RPM to support zstd payload, still is not lost: the TW instance cna be 'offline upgraded' (i.e. boot the NET install/DVD and pick 'upgrade' in the bootloader. This will use RPM on the DVD/NEt and allow to move to a current TW snapshot). Anything else you're trying to do, is out of the supported scenarios, Cheers, Dominique
On 09/11/2020 13.00, Dominique Leuenberger / DimStar wrote:
On Fri, 2020-11-06 at 20:10 -0800, L A Walsh wrote:
TLDR: rpm(s) >= 4.15, can't be read, built or installed by rpm < 4.15 (specifically, 4.11).
On 2020/10/29 03:55, Simon Lees wrote:
I asked:
I don't suppose anyone thought about how users who missed a few months of internet connectivity might resync or make use of the new format rpms if they can't even install + build source-rpms.
I'm not sure how much we claim to support building openSUSE rpm's as source rpm's on there own. openSUSE rpm spec files often depend on variables that are defined in project config files in open build service, as such just using rpmbuild may result in packages not building or building with different configurations.
---- But is *installing* "rpms" from tumbleweed, with "rpm" on a tumbleweed install, supported?
YES - But: as the payload compression changed, we have always been aware that no matter how long we will make the payload change, there will be some user takign n+1 days until they will update.
To be clear: we enabled zstd support in RPM in Tumbleweed before we switched to zstd compresson method. And the timing was already quite conservative:
RPM had zstd support in Tumbleweed since July 2019 (2019 - aka > 1 year ago) TW changed the default compression scheme to zstd on August 25 2020 (i.e. more than a tear after we added support to rpm reading those payloads)
Leap 15.2 also received a maintenannce update to be able to read those zstd payloaded rpms. Upgrading to TW has always been supported from the 'latest openSUSE stable release and from Tumbleweed'
A TW user that actually managed to miss the 1-year period to upgrade
She said the machine was current, then had hard disk trouble for two months. Then it failed to update.
RPM to support zstd payload, still is not lost: the TW instance cna be 'offline upgraded' (i.e. boot the NET install/DVD and pick 'upgrade' in the bootloader. This will use RPM on the DVD/NEt and allow to move to a current TW snapshot).
This is one of the procedures I recommended. She has not commented back yet.
Anything else you're trying to do, is out of the supported scenarios,
-- Cheers. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2020/11/09 04:04, Carlos E. R. wrote:
On 09/11/2020 13.00, Dominique Leuenberger / DimStar wrote:
...as the payload compression changed, we have always been aware that no matter how long we will make the payload change, there will be some user takign n+1 days until they will update.
Of course! Though am making progress -- am able to build a copy of zstd from the source rpm, but the source rpm gets errors which I haven't sorted out yet. But at least I can install files via rpm2cpio. rpm2cpio worked before, but produced a zstd-compressed cpio archive. But now I can uncompress that with zstd -d and then work from the cpio archive.
She said the machine was current, then had hard disk trouble for two months. Then it failed to update.
---- Actually I said I was able to install rpm's from from the then current TW stream. However, looking at the rpm on my system shows an unreasonably old, non-tumbleweed version from 13.2. Not sure how that missed getting updated, but that's one cause.
RPM to support zstd payload, still is not lost: the TW instance cna be 'offline upgraded' (i.e. boot the NET install/DVD and pick 'upgrade' in the bootloader. This will use RPM on the DVD/NEt and allow to move to a current TW snapshot).
---- Well, yeah, basically like doing a reinstall over the old installation without formatting. I'm pretty sure that would result in a non-working (if even bootable) result. I'm in the middle of moving several partitions, and haven't really dealt with the problem of moving boot+root from 'd' to 'c' in lilo after I remove the old sys-drives.
This is one of the procedures I recommended. She has not commented back yet.
--- I'd rather not write over everything from my current install. I don't think it would correctly upgrade/update my config files
Anything else you're trying to do, is out of the supported scenarios,
I've had to adapt to various support-scenarios since evaluating and adopting it for the basis of sgi's linux in ~98 or 99. Think I started with SuSE Linux 5.3 for my home machine. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 09/11/2020 18.15, L A Walsh wrote:
On 2020/11/09 04:04, Carlos E. R. wrote:
On 09/11/2020 13.00, Dominique Leuenberger / DimStar wrote:
...as the payload compression changed, we have always been aware that no matter how long we will make the payload change, there will be some user takign n+1 days until they will update.
Of course! Though am making progress -- am able to build a copy of zstd from the source rpm, but the source rpm gets errors which I haven't sorted out yet.
But at least I can install files via rpm2cpio. rpm2cpio worked before, but produced a zstd-compressed cpio archive. But now I can uncompress that with zstd -d and then work from the cpio archive.
She said the machine was current, then had hard disk trouble for two months. Then it failed to update.
---- Actually I said I was able to install rpm's from from the then current TW stream. However, looking at the rpm on my system shows an unreasonably old, non-tumbleweed version from 13.2. Not sure how that missed getting updated, but that's one cause.
RPM to support zstd payload, still is not lost: the TW instance cna be 'offline upgraded' (i.e. boot the NET install/DVD and pick 'upgrade' in the bootloader. This will use RPM on the DVD/NEt and allow to move to a current TW snapshot).
Well, yeah, basically like doing a reinstall over the old installation without formatting. I'm pretty sure that would result in a non-working (if even bootable) result.
No, this is a documented procedure. It is the same procedure as used to upgrade a machine from 13.1 to 13.2 before zypper dup was invented. And, it can be used as well for emergency recovery of broken systems. Try it out in a virtual machine.
I'm in the middle of moving several partitions, and haven't really dealt with the problem of moving boot+root from 'd' to 'c' in lilo after I remove the old sys-drives.
If you have lilo it is possible that the DVD upgrade could refuse to start.
This is one of the procedures I recommended. She has not commented back yet.
I'd rather not write over everything from my current install. I don't think it would correctly upgrade/update my config files
You would get them converted to .rpmold, or get .prmnew, as with any other update. AFAIK, the procedure never deletes your config files.
Anything else you're trying to do, is out of the supported scenarios, I've had to adapt to various support-scenarios since evaluating and adopting it for the basis of sgi's linux in ~98 or 99. Think I started with SuSE Linux 5.3 for my home machine.
-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020/11/09 10:55, Carlos E. R. wrote:
RPM to support zstd payload, still is not lost: the TW instance cna be 'offline upgraded' (i.e. boot the NET install/DVD and pick 'upgrade' in the bootloader. This will use RPM on the DVD/NEt and allow to move to a current TW snapshot).
Well, yeah, basically like doing a reinstall over the old installation without formatting. I'm pretty sure that would result in a non-working (if even bootable) result.
No, this is a documented procedure. It is the same procedure as used to upgrade a machine from 13.1 to 13.2 before zypper dup was invented. And, it can be used as well for emergency recovery of broken systems. Try it out in a virtual machine.
As soon as I get to a point where they work again -- an ongoing problem when one upgrades the kernel from source.
I'm in the middle [disk maintenance] in a lilo-boot
If you have lilo it is possible that the DVD upgrade could refuse to start.
That's sorta what I meant by non-working (if even bootable) result.
--- I'd rather not write over everything from my current install. I don't think it would correctly upgrade/update my config files
You would get them converted to .rpmold, or get .rpmnew, as with any other update. AFAIK, the procedure never deletes your config files.
But it would likely result in a non-bootable or non-working system. There are likely certain boot & service related issues that would have to be worked out as well. I need to figure out how to update the rpm format w/o throwing out the kitchen sink. Being able to essentially boot off a mini-root on disk is a big aid to recovering from many (though not all) HW probs.
On 11/11/2020 00.20, L A Walsh wrote:
On 2020/11/09 10:55, Carlos E. R. wrote:
RPM to support zstd payload, still is not lost: the TW instance cna be 'offline upgraded' (i.e. boot the NET install/DVD and pick 'upgrade' in the bootloader. This will use RPM on the DVD/NEt and allow to move to a current TW snapshot).
Well, yeah, basically like doing a reinstall over the old installation without formatting. I'm pretty sure that would result in a non-working (if even bootable) result.
No, this is a documented procedure. It is the same procedure as used to upgrade a machine from 13.1 to 13.2 before zypper dup was invented. And, it can be used as well for emergency recovery of broken systems. Try it out in a virtual machine.
As soon as I get to a point where they work again -- an ongoing problem when one upgrades the kernel from source.
I'm in the middle [disk maintenance] in a lilo-boot
If you have lilo it is possible that the DVD upgrade could refuse to start.
That's sorta what I meant by non-working (if even bootable) result.
Well, I described another method to do it without using the DVD upgrade method.
--- I'd rather not write over everything from my current install. I don't think it would correctly upgrade/update my config files
You would get them converted to .rpmold, or get .rpmnew, as with any other update. AFAIK, the procedure never deletes your config files.
But it would likely result in a non-bootable or non-working system.
There are likely certain boot & service related issues that would have to be worked out as well. I need to figure out how to update the rpm format w/o throwing out the kitchen sink.
Being able to essentially boot off a mini-root on disk is a big aid to recovering from many (though not all) HW probs.
I recover from another partition, or from an USB stick for the purpose. Far less trouble than having to do that many adjustments to non standard boot methods ;-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 09/11/2020 13.00, Dominique Leuenberger / DimStar wrote:
RPM had zstd support in Tumbleweed since July 2019 (2019 - aka > 1 year ago) TW changed the default compression scheme to zstd on August 25 2020 (i.e. more than a tear after we added support to rpm reading those payloads)
it should also be possible to use an xz-compressed rpm toolchain from before the zstd switch happened: https://opensuse.zq1.de/history/20200824/tumbleweed/repo/oss e.g. https://opensuse.zq1.de/history/20200824/tumbleweed/repo/oss/x86_64/libzstd1...
On 2020/11/10 23:20, Bernhard M. Wiedemann wrote:
https://opensuse.zq1.de/history/20200824/tumbleweed/repo/oss/x86_64/libzstd1...
Well it installs no prob, (no conflicts), but I think I also need the -devel rpm: I tried: libzstd1-devel-1.4.5-2.2.x86_64.rpm, but that returns a pkgconfig(libzstd) is needed by rpm-4.15.1-7.2.x86_64 Does the devel hold that info? Thanks!
On 12/11/2020 21.51, L A Walsh wrote:
On 2020/11/10 23:20, Bernhard M. Wiedemann wrote:
https://opensuse.zq1.de/history/20200824/tumbleweed/repo/oss/x86_64/libzstd1...
---- Well it installs no prob, (no conflicts), but I think I also need the -devel rpm: I tried: libzstd1-devel-1.4.5-2.2.x86_64.rpm, but that returns a
pkgconfig(libzstd) is needed by rpm-4.15.1-7.2.x86_64
From the same history link? Then try perhaps the previous history point.
Does the devel hold that info?
Thanks!
-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020/11/12 13:55, Carlos E. R. wrote:
On 12/11/2020 21.51, L A Walsh wrote:
On 2020/11/10 23:20, Bernhard M. Wiedemann wrote:
https://opensuse.zq1.de/history/20200824/tumbleweed/repo/oss/x86_64/libzstd1...
---- Well it installs no prob, (no conflicts), but I think I also need the -devel rpm: I tried: libzstd1-devel-1.4.5-2.2.x86_64.rpm, but that returns a
pkgconfig(libzstd) is needed by rpm-4.15.1-7.2.x86_64
From the same history link? Then try perhaps the previous history point.
that came from the current rpm source in TW when I tried building it again, but the previous link was for the runtime libs, not the devel files. Do you know the location of the corresponding devel link? How do you know what is in what history point and what names are in the history point? Thx, -l
On 13/11/2020 21.43, L A Walsh wrote:
On 2020/11/12 13:55, Carlos E. R. wrote:
On 12/11/2020 21.51, L A Walsh wrote:
On 2020/11/10 23:20, Bernhard M. Wiedemann wrote:
https://opensuse.zq1.de/history/20200824/tumbleweed/repo/oss/x86_64/libzstd1...
---- Well it installs no prob, (no conflicts), but I think I also need the -devel rpm: I tried: libzstd1-devel-1.4.5-2.2.x86_64.rpm, but that returns a
pkgconfig(libzstd) is needed by rpm-4.15.1-7.2.x86_64
From the same history link? Then try perhaps the previous history point. that came from the current rpm source in TW when I tried building it again, but the previous link was for the runtime libs, not the devel files. Do you know the location of the corresponding devel link? How do you know what is in what history point and what names are in the history point?
I don't know that much. I posted links to information on that on another posts. Let me see if I can find them again... https://lists.opensuse.org/opensuse-factory/2018-02/msg01152.html http://download.opensuse.org/history/ -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 2020/11/13 12:48, Carlos E. R. wrote:
On 13/11/2020 21.43, L A Walsh wrote:
On 2020/11/12 13:55, Carlos E. R. wrote:
On 12/11/2020 21.51, L A Walsh wrote:
On 2020/11/10 23:20, Bernhard M. Wiedemann wrote:
https://opensuse.zq1.de/history/20200824/tumbleweed/repo/oss/x86_64/libzstd1...
---- Well it installs no prob, (no conflicts), but I think I also need the -devel rpm: I tried: libzstd1-devel-1.4.5-2.2.x86_64.rpm, but that wasn't found.
https://lists.opensuse.org/opensuse-factory/2018-02/msg01152.html
--- Thanks, found devel package named libzstd-devel-1.4.5-2.4.x86. Trying to install it though gives: # rpm -Uhv libzstd-devel-1.4.5-2.4.x86_64.rpm error: Failed dependencies: rpmlib(PayloadIsZstd) <= 5.4.18-1 is needed by libzstd-devel-1.4.5-2.4.x86_64 --- Um...the libstd1 suggested by Bernhard W., that I installed with no conflicts/problems came from: https://opensuse.zq1.de/history/20200824/tumbleweed/repo/oss/x86_64/libzstd1... or essentially history date: https://opensuse.zq1.de/history/20200824. Comparing that to the history on download.opensuse.org that was originally announced to have 50 snapshots + 2 months of distribution. ("As a side-node, Tumbleweed Snapshots are limited to 50 snapshots due to a hosting restriction [5], but that should generally be over two months worth." - https://lists.opensuse.org/opensuse-factory/2018-02/msg01152.html) Instead I find about 20 snaps with 1 month on our local download.opensuse.org. The one at opensuse.zq1.de seems to go back to 20190205, showing about 32TB space usage, but seems unreliable depending on content (or at least so slow that my browser timed out multiple times). Ah, it works now.... Installed the devel for libzstd (libzstd-devel-1.4.5-2.2.x86_64.rpm)....and rpmbuild rpm...oh poo Time for some more investigating.... make[2]: Leaving directory '/home/packages/build/rpm-4.15.1' Making all in plugins make[2]: Entering directory '/home/packages/build/rpm-4.15.1/plugins' ... /bin/sh ../libtool --tag=CC --mode=link gcc -D_REENTRANT -Wall -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -fno-strict-aliasing -fstack-protector -Wempty-body -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -ffunction-sections -avoid-version -module -shared -Wl,-Bsymbolic-functions -ffunction-sections -o prioreset.la -rpath //usr/lib64/rpm-plugins prioreset.lo ../lib/librpm.la ../rpmio/librpmio.la -laudit -ldl -lpthread audit.c: In function ‘audit_tsm_post’: audit.c:83:43: error: ‘AUDIT_SOFTWARE_UPDATE’ undeclared (first use in this function); did you mean ‘AUDIT_FILTER_UNSET’? audit_log_user_comm_message(auditFd, AUDIT_SOFTWARE_UPDATE, ^~~~~~~~~~~~~~~~~~~~~ AUDIT_FILTER_UNSET audit.c:83:43: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [Makefile:667: audit.lo] Error 1 It looks like I still need to build rpmlib with 'PayloadIsZstd', but building rpm(lib) needs pc
On 11/13/20 7:21 AM, L A Walsh wrote:
On 2020/11/10 23:20, Bernhard M. Wiedemann wrote:
https://opensuse.zq1.de/history/20200824/tumbleweed/repo/oss/x86_64/libzstd1...
---- Well it installs no prob, (no conflicts), but I think I also need the -devel rpm: I tried: libzstd1-devel-1.4.5-2.2.x86_64.rpm, but that returns a
pkgconfig(libzstd) is needed by rpm-4.15.1-7.2.x86_64
Does the devel hold that info?
Yes, its looking for /usr/lib64/pkgconfig/libzstd.pc (or something similar). -- 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 2020/11/12 16:27, Simon Lees wrote:
On 11/13/20 7:21 AM, L A Walsh wrote:
Well it installs no prob, (no conflicts), but I think I also need the -devel rpm: I tried: libzstd1-devel-1.4.5-2.2.x86_64.rpm, but that returns a
pkgconfig(libzstd) is needed by rpm-4.15.1-7.2.x86_64
Does the devel hold that info?
Yes, its looking for /usr/lib64/pkgconfig/libzstd.pc (or something similar).
--- Sorry my sentence came out screwed up... I tried finding the "-devel" package, by using a similar version as the rpm for the 'libzstd', but couldn't find it. Do you know the name of the corresponding 'devel' rpm that would install libzstd.pc (as well as libzstd.a & libzstd.h)? I tried constructing one manually(**-below) and putting it in /usr/lib64/pkgconfig/libzstd.pc, but the rpm build process still complained about a missing pkgconfig(libzstd) being needed by the rpmbuild. I think I need a libzstd.sa from the devel pckg as well as well as some needed header. I tried using the zstd.h from the package build, but don't know if it is what is needed.
Citeren L A Walsh <suse@tlinx.org>:
On 2020/11/12 16:27, Simon Lees wrote:
On 11/13/20 7:21 AM, L A Walsh wrote:
Well it installs no prob, (no conflicts), but I think I also need the -devel rpm: I tried: libzstd1-devel-1.4.5-2.2.x86_64.rpm, but that returns a
pkgconfig(libzstd) is needed by rpm-4.15.1-7.2.x86_64
Does the devel hold that info?
Yes, its looking for /usr/lib64/pkgconfig/libzstd.pc (or something similar).
--- Sorry my sentence came out screwed up...
I tried finding the "-devel" package, by using a similar version as the rpm for the 'libzstd', but couldn't find it. Do you know the name of the corresponding 'devel' rpm that would install libzstd.pc (as well as libzstd.a & libzstd.h)?
Finding which package provides something is easily done with zypper zypper se --provides "pkgconfig(libzstd)" So you probably need to install 'libzstd-devel'
I tried constructing one manually(**-below) and putting it in /usr/lib64/pkgconfig/libzstd.pc, but the rpm build process still complained about a missing pkgconfig(libzstd) being needed by the rpmbuild. I think I need a libzstd.sa from the devel pckg as well as well as some needed header. I tried using the zstd.h from the package build, but don't know if it is what is needed. _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org
On 11/14/20 7:16 AM, Arjen de Korte wrote:
Citeren L A Walsh <suse@tlinx.org>:
On 2020/11/12 16:27, Simon Lees wrote:
On 11/13/20 7:21 AM, L A Walsh wrote:
Well it installs no prob, (no conflicts), but I think I also need the -devel rpm: I tried: libzstd1-devel-1.4.5-2.2.x86_64.rpm, but that returns a
pkgconfig(libzstd) is needed by rpm-4.15.1-7.2.x86_64
Does the devel hold that info?
Yes, its looking for /usr/lib64/pkgconfig/libzstd.pc (or something similar).
--- Sorry my sentence came out screwed up...
I tried finding the "-devel" package, by using a similar version as the rpm for the 'libzstd', but couldn't find it. Do you know the name of the corresponding 'devel' rpm that would install libzstd.pc (as well as libzstd.a & libzstd.h)?
Finding which package provides something is easily done with zypper
zypper se --provides "pkgconfig(libzstd)"
So you probably need to install 'libzstd-devel'
Yeah rpm automatically adds this provides as part of the build process. So its checking for the rpm that provides that rather then for something on the filesystem. -- 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
participants (10)
-
Arjen de Korte -
Bernhard M. Wiedemann -
Carlos E. R. -
Dominique Leuenberger / DimStar -
Jan Engelhardt -
Knurpht-openSUSE -
L A Walsh -
Marcus Hüwe -
Neal Gompa -
Simon Lees