Re: [Rpm-maint] [rpm-software-management/rpm] rpmsign --delsign leaves behind 0 padding (Issue #2965)
I think, the problem has 2 components. 1. The obs-sign we use in OBS has its own signing code and adds bytes to the header instead of using the reserved space. 2. The `rpm --delsign` leaves the (increased) size as is, only zeroes it out. I was able to get bit-identical results to OBS using "--define=%__gpg_reserved_space 4688" in the replication build to add as many header bytes as obs-sign did, but that is certainly not the nicest solution. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2965#issuecomment-2020319475 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpmsign --delsign leaves behind 0 padding (Issue #2965)
After 2022-06-20 we changed to a new rsa4096 signkey for the project.
%__gpg_reserved_space seems to default to 4096 bytes so that should fit. And
indeed, rpm --delsign leaves the size as is.
With [this
dump-rpm-headers.py](https://gist.github.com/koseki/9737a4490128bcb8b426c22a0b7c3885)
I get this diff between our delsigned OBS build and my local build:
```diff
--- dump-rpm-headers.py binaries/strip-nondeterminism-1.13.1-33.11.src.rpm
+++ dump-rpm-headers.py
binaries.nachbau/strip-nondeterminism-1.13.1-33.11.src.rpm
@@ -13,15 +13,15 @@
version: b'\x01'
reserved: b''
nindex: 7
- hsize: 4868
+ hsize: 4276
Signature Section - Index Entries
-[ 0] tag: 62 type: BIN offset:4852 count: 16 #
RPMTAG_HEADERSIGNATURES
+[ 0] tag: 62 type: BIN offset:4260 count: 16 #
RPMTAG_HEADERSIGNATURES
[ 1] tag: 269 type: STRING offset: 0 count: 1 # RPMSIGTAG_SHA1
[ 2] tag: 273 type: STRING offset: 41 count: 1 # Unknown
[ 3] tag: 1000 type: INT32offset: 108 count: 1 # RPMSIGTAG_SIZE
[ 4] tag: 1004 type: BIN offset: 112 count: 16 # RPMSIGTAG_MD5
[ 5] tag: 1007 type: INT32offset: 128 count: 1 #
RPMSIGTAG_PAYLOADSIZE
-[ 6] tag: 1008 type: BIN offset: 132 count:4720 #
RPMSIGTAG_RESERVEDSPACE
+[ 6] tag: 1008 type: BIN offset: 132 count:4128 #
RPMSIGTAG_RESERVEDSPACE
Signature Section - Data
[ 1] RPMSIGTAG_SHA1
b'34a3e2de398c3a6598b6b4b9d01d9a7fa96fda48'
@@ -42,43 +42,6 @@ RPMSIGTAG_RESERVEDSPACE
-*
```
So there is a difference of 592 bytes, which is around the size of a 4096-bit
sig.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2965#issuecomment-2005753254
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
I did not mean to alter signing time - but keep it as it is (it is dropped by delsign anyway), while changing "Build Date" instead to something that does not vary in (changeless) rebuilds. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8641508 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
When I normalize BUILDTIME with `%use_source_date_epoch_as_buildtime`, the signature still gives the real date. Is there a value in keeping both? e.g. [this package](https://build.opensuse.org/package/show/home:bmwiedemann:reproducible/strip-nondeterminism) `rpm -ql` has ``` Signature : RSA/SHA256, 2024-02-26T12:00:49 UTC, Key ID 8adc26dbb49c2121 Source RPM : strip-nondeterminism-1.13.1-33.9.src.rpm Build Date : 2023-07-28T16:19:49 UTC ``` Not overriding BUILDHOST is fine as it still allows easy verification. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8640953 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
I'm always thinking about rebuild+compare as one operation. In the Debian and Archlinux space there were also discussions about centralized collections of multiple rebuilder-results. Those are signed data containing "$rebuildername built $package $version and got output $hash". That would work poorly with fuzzy-matching. It could work with a custom rpmhash tool, but how do you prove that it indeed covers all relevant bits? I don't like that and would rather see us reach bit-reproducible rpms (after delsign) that work with generic `sha256sum`. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8629486 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
Yes, but needing build outputs in addition to build inputs is still needing more. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8619915 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Discussion #2934)
keszybz wrote: > any party can recreate copies of the artifacts that are identical except for > the signatures and parts of metadata I don't think it is a good idea to exclude metadata. One benefit that you can only get with bit-identical reproducibility is that you can list the one and only correct hash value of the build result. (that also works with signed rpms + delsign). However with weaker variants, you always need another full rpm to compare to. I.e. for our 16k packages, instead of publishing a list of 16k hashes you then need to keep the full archive (100GB) to allow people to reproduce any package. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/discussions/2934#discussioncomment-8618492 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Issue #2894)
As long as a constant buildtime value is provided, it will also result in constant (reproducible) mtime. Reproducible builds requires that you can produce bit-identical output from identical inputs. And inputs would include buildtime here (or whatever it is based on, e.g. changelog date). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1961317158 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Issue #2894)
We have open-build-service (OBS) that uses obs-worker to call obs-build to call rpmbuild. The current way documented in [our wiki](https://en.opensuse.org/openSUSE:Reproducible_Builds) is to add a project-conf in OBS ``` Macros: %source_date_epoch_from_changelog 1 %clamp_mtime_to_source_date_epoch 1 %use_source_date_epoch_as_buildtime 1 %_buildhost reproducible :Macros ``` and the constants here are `1` and `reproducible` -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1956161964 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Reproducible builds improvements (Issue #2894)
> %clamp_mtime_to_buildtime seems sensible to me, at least if it replaces > %clamp_mtime_to_source_date_epoch. If you care about source_date_epoch, then > you'll surely set buildtime to it, right? With our build system, passing constants into a build is much easier than passing in a variable `%_buildtime`. Not sure how that is with Fedora's or Mageia's build-system. It would be nice to at least have both in parallel until everything is properly integrated. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2894#issuecomment-1956109520 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add option to not store expanded spec (PR #2762)
We do have our share of dynamic magic - e.g. the [python lua scripts](https://github.com/openSUSE/python-rpm-macros) to generate module packages for 39, 310, 311 and 312 from a single .spec. However these inputs all remain available in OBS, so are not a problem to reproducibility. Could the expanded .spec become a separate artifact? e.g. we have generated rpmlint logs and build statistics as extra files, so another one there should be fine. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2762#issuecomment-1810312959 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add option to not store expanded spec (PR #2762)
Besides that, the expanded .spec does not contain all the details e.g. which compiler+libs were used - all that goes into an SBOM outside of the produced package. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2762#issuecomment-1809641411 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add option to not store expanded spec (PR #2762)
Then we will have to carry the patch downstream. Just one more on the [long list](https://github.com/distropatches/rpm/commits/sle15.4-4.14.3) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2762#issuecomment-1809634796 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add option to not store expanded spec (PR #2762)
Add option to not store expanded spec in .src.rpm because some usages of macros are hard to make reproducible. Fixes #2343 This patch was done while working on [reproducible builds for openSUSE](https://en.opensuse.org/openSUSE:Reproducible_Builds). btw: if you have better proposals for the name of the value, Ill take it. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2762 -- Commit Summary -- * Add option to not store expanded spec -- File Changes -- M build/pack.c (4) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2762.patch https://github.com/rpm-software-management/rpm/pull/2762.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2762 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.18.0 embeds build machine CPU count (Issue #2343)
found another breakage:
`sed -i -e 's/-j2/%{?_smp_mflags}/' setup.py`
in
https://github.com/bmwiedemann/openSUSE/blob/master/packages/p/python-python-poppler/python-python-poppler.spec#L61
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2343#issuecomment-1689242765
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.18.0 embeds build machine CPU count (Issue #2343)
Found another reproducibility problem with expanded .spec in
https://code.opensuse.org/package/texlive/blob/d820a867c61524278af352b4febbb115e9dad08f/f/texlive.spec#_287
```spec
%{expand: %%global options %(mktemp /tmp/texlive-opts.)}
```
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2343#issuecomment-1678814874
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.18.0 embeds build machine CPU count (Issue #2343)
And more trouble from https://codeberg.org/cunix/vendored_licenses_packager/src/branch/main/macros.vendored_licenses_packager#L18 that injects a random tmp path into the .src.rpm of [dnscrypt-proxy](https://code.opensuse.org/package/dnscrypt-proxy/tree/master) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2343#issuecomment-1420449964 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.18.0 embeds build machine CPU count (Issue #2343)
Found another problematic case:
https://code.opensuse.org/package/ocaml-rpm-macros/blob/819e56/f/ocaml-rpm-macros.spec#_464
`'%%{?_smp_mflags}'`
becomes
`'-j${RPM_BUILD_NCPUS}'` and the variable does not get expanded now, causing a
compilation failure. I guess, using double-quotes should fix it.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2343#issuecomment-1407598501
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.18.0 embeds build machine CPU count (Issue #2343)
It seems, `$RPM_BUILD_NCPUS` is not set in our older distributions that have rpm-4.14.3. What would be the best way to have https://github.com/mesonbuild/meson/blob/c754f9076/data/macros.meson#L43 be reproducible on both 4.14 and 4.18 ? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2343#issuecomment-1398053168 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.18.0 embeds build machine CPU count (Issue #2343)
There are four .spec files in openSUSE, that use `%{_smp_build_ncpus}`
directly, e.g.
https://code.opensuse.org/package/python3-pyside6/blob/ad8e8792e6ed522cb99332637de53ce6ff5b93f1/f/python3-pyside6.spec#_226
Maybe instead of 0576d24756fe975d890f5535a21cfdfd35fc2ca4, we could redefine
`%_smp_build_ncpus` to `$RPM_BUILD_NCPUS` ?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2343#issuecomment-1381436669
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.18.0 embeds build machine CPU count (Issue #2343)
Yes. It came from https://github.com/openSUSE/obs-build/blob/master/build-recipe#L234 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2343#issuecomment-1379094502 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Determine %_smp_mflags at build time (PR #2344)
I dropped the third commit and left the move to macros.in to not be mangled by installplatform. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2344#issuecomment-1378584592 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.18.0 embeds build machine CPU count (Issue #2343)
I have it with `-j${RPM_BUILD_NCPUS}` in
https://build.opensuse.org/package/view_file/home:bmwiedemann:reproducible/rpm/0576d24756f.patch
, but somehow it gets replaced by `%_smp_mflags -j%{_RPM_BUILD_NCPUS}` in
platform files, which then breaks because the macro is unknown.
With the move to `macros.in`, it works. Is there some special rewriting?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2343#issuecomment-1378546360
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.18.0 embeds build machine CPU count (Issue #2343)
Right something writes it into ~/.rpmmacros . That is our problem then and the
`-j%{_RPM_BUILD_NCPUS}
` rpm patch should still be good.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2343#issuecomment-1378508483
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] WIP: Determine %_smp_mflags at build time (PR #2344)
Something is still not right here.
`/usr/lib/rpm/platform/x86_64-linux/macros` has
```
%_smp_mflags -j%{_smp_build_ncpus}
```
that still gets expanded into .src.rpm
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2344#issuecomment-1378209990
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.18.0 embeds build machine CPU count (Issue #2343)
I checked git log and found some related commits. #2344 now does the trick for me. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2343#issuecomment-1378203226 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Determine %_smp_mflags at build time (PR #2344)
This cherry-picks 3 commits from master to not embed the build machine CPU core count into .src.rpms Fixes #2343 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/2344 -- Commit Summary -- * Calculate number of threads to use during build, not spec parse * Make CPU and thread-related macros available on all platforms * Make %_smp_mflags build rather than parse time determined -- File Changes -- M build/build.c (28) M build/parseSpec.c (24) M macros.in (16) M platform.in (16) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/2344.patch https://github.com/rpm-software-management/rpm/pull/2344.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2344 You are receiving this because you are subscribed to this thread. Message ID: rpm-software-management/rpm/pull/2...@github.com ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.18.0 embeds build machine CPU count (Issue #2343)
I tried
```diff
===
--- rpm-4.18.0.orig/platform.in
+++ rpm-4.18.0/platform.in
@@ -57,7 +57,7 @@
if [ -n "$ncpus_max" ] && [ "$ncpus_max" -gt 0 ] && [
"$RPM_BUILD_NCPUS" -gt "$ncpus_max" ]; then RPM_BUILD_NCPUS="$ncpus_max"; fi;
\\\
echo "$RPM_BUILD_NCPUS";)
-%_smp_mflags -j%{_smp_build_ncpus}
+%_smp_mflags -j${RPM_BUILD_NCPUS}
# Maximum number of threads to use when building, 0 for unlimited
#%_smp_nthreads_max 0
```
But somehow I still get this diff
```diff
-make -j4
+make -j1
```
the produced `/usr/lib/rpm/platform/x86_64-linux/macros` has
```
%_smp_mflags -j%{_RPM_BUILD_NCPUS}
```
Why is that?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2343#issuecomment-1377915374
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] rpm-4.18.0 embeds build machine CPU count (Issue #2343)
While working on [reproducible builds](https://reproducible-builds.org/) for
[openSUSE](https://en.opensuse.org/openSUSE:Reproducible_Builds), I found that
the recent upgrade to rpm-4.18.0
with #2047 / #1241 caused spec files with
```bash
make %{?_smp_mflags}
```
to embed the build machine CPU count into .src.rpm files, making them hard to
bit-reproduce.
binary rpm files embed the .src.rpm header checksum, so suffer as well.
It might also introduce other hard-to-reproduce details, but I have not looked
for these, yet.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2343
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: save the parsed spec in src.rpm (#1241)
I found that unfortunately this change makes many of our rpm builds
unreproducible, because our .spec files contain things like `make
%{?_smp_mflags}` and that gets expanded depending on the build machine CPU core
count.
Is there an easy way to disable this or do you have a different proposal of how
to build bit-identical rpms again?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1241#issuecomment-1373334104
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add parsed and expanded spec to src.rpm header (#1241) (PR #2047)
I found that unfortunately this change makes many of our rpm builds
unreproducible, because our .spec files contain things like `make
%{?_smp_mflags}` and that gets expanded depending on the build machine CPU core
count.
Is there an easy way to disable this or do you have a different proposal of how
to build bit-identical rpms again?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2047#issuecomment-1372488940
You are receiving this because you are subscribed to this thread.
Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add support for generating buildinfo file as subpackage (#1532)
Interested in something like this for openSUSE. We already have something comparable called `_buildenv` (XML) e.g. in https://build.opensuse.org/package/binaries/openSUSE:Factory/bash/standard - but that is created on the obs_worker level. [ArchLinux](https://archlinux.org/pacman/BUILDINFO.5.html) seems to have their own format with = as delimiter. In most places, the buildinfo files can probably be handled as opaque files and just things like source,binary,version would be interesting outside. That is not hard to extract in either format, so there is no strong reason to follow Debian here. OTOH, this is not a .spec file, but just another output from the build process, similar to the build log, so it does not need to follow rpm conventions either. So from my view, using either the Debian or ArchLinux (marshalling) format has some advantage over making up a third format. Though, I would not keep confusing Debianisms in keys that will not be meaningful outside of the respective distribution. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1532#issuecomment-942694178___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 4.15.1 creates unreproducible rpm DEPENDSDICT (#1056)
Still a problem with rpm-4.16.0. I found at least 4 affected packages now and all of them use `cmake` and `gcc-c++` for building * drumstick-devel * gnuradio-devel * poco-devel * qt6-svg-devel (only 1 bit of entropy) a hexdump diff looks thus: ```diff @@ -859,13 +859,13 @@ 004920 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 004930 00 00 00 02 00 00 00 02 00 00 00 02 00 00 00 02 004940 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 00 -004950 50 00 00 01 50 00 00 04 50 00 00 03 50 00 00 02 -004960 50 00 00 00 50 00 00 01 50 00 00 04 50 00 00 03 -004970 50 00 00 02 50 00 00 00 50 00 00 01 50 00 00 04 -004980 50 00 00 03 50 00 00 02 50 00 00 00 50 00 00 01 -004990 50 00 00 04 50 00 00 03 50 00 00 02 50 00 00 00 -0049a0 50 00 00 01 50 00 00 04 50 00 00 03 50 00 00 02 -0049b0 50 00 00 00 50 00 00 08 52 00 00 00 50 00 00 09 +004950 50 00 00 02 50 00 00 00 50 00 00 03 50 00 00 04 +004960 50 00 00 01 50 00 00 02 50 00 00 00 50 00 00 03 +004970 50 00 00 04 50 00 00 01 50 00 00 02 50 00 00 00 +004980 50 00 00 03 50 00 00 04 50 00 00 01 50 00 00 02 +004990 50 00 00 00 50 00 00 03 50 00 00 04 50 00 00 01 +0049a0 50 00 00 02 50 00 00 00 50 00 00 03 50 00 00 04 +0049b0 50 00 00 01 50 00 00 08 52 00 00 00 50 00 00 09 0049c0 52 00 00 00 50 00 00 0a 52 00 00 00 50 00 00 0b 0049d0 52 00 00 00 50 00 00 07 52 00 00 08 52 00 00 13 ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1056#issuecomment-761493176___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFC: Removing unneeded internal macros (such as %__ranlib) (#1211)
There is even online search included: https://github.com/bmwiedemann/openSUSE/search?q=__cc -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1211#issuecomment-626640746___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 4.15.1 creates unreproducible rpm DEPENDSDICT (#1056)
I was able to reproduce the problem with rpm-4.14.1 as well, so not a recent regression. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1056#issuecomment-590672950___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] 4.15.1 creates unreproducible rpm DEPENDSDICT (#1056)
While working on reproducible builds for openSUSE, I found that
our poco package build had variations in the resulting `poco-devel` rpms
in the `DEPENDSDICT` header.
Likely from build/rpmfc.c rpmfcGenerateDepends function.
Steps To Reproduce:
```bash
osc co openSUSE:Factory/poco && cd $_
osc build --no-service --vm-type=kvm --keep-pkgs=RPMS
rpm -qp --qf '%{DEPENDSDICT}\n' RPMS/poco-devel-1.9.3-*.x86_64.rpm
```
Diff looks thus:
```diff
filterdiff printrpmtags RPMS*/*devel*
-DEPENDSDICT=1342177287
+DEPENDSDICT=1342177291
```
When building on a filesystem without variations in readdir order (e.g.
disorderfs in order mode or ext4 with dir_index disabled), differences go away.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1056___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Generate file class dictionary after file classification for stability (#944)
Tested it with our khmeros-fonts build. Results are still reproducible. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/944#issuecomment-557048211___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 4.15 creates unreproducible rpm file magic headers (#934)
The base level of reproducibility just needs us to be able to use the same inputs (that includes the libmagic binary) to give the same output - like a mathematical function. On top of that, you can add advanced levels - e.g. try to get noarch packages that are actually the same when built on different archs (is not always true with pngs coming out of image scalers and svg renderers) - and one can find [interesting](https://bugzilla.opensuse.org/show_bug.cgi?id=1109949) [bugs](https://bugzilla.opensuse.org/show_bug.cgi?id=1109541) with it. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/934#issuecomment-552592075___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Preserve processing order in file classification (#936)
bmwiedemann approved this pull request. Tested with this patch and got bit-reproducible results again. Thanks! -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/936#pullrequestreview-315118642___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 4.15 creates unreproducible rpm file magic headers (#934)
There are ways to do parallel processing and still get reproducible results - it is done in pigz or xz and even make -j . -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/934#issuecomment-552445976___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Only calculate buildhost and buildtime during an actual build (#935)
bmwiedemann approved this pull request. Tested it. Looks good. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/935#pullrequestreview-314875746___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set Build Date from changelog again (#933)
Added it. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/933#issuecomment-552354347___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Set Build Date from changelog again (#933)
> Why do we need this code in two places now? The old one is still needed in case `SOUCE_DATE_EPOCH` is set by the caller of rpmbuild. The new one is now needed for the case where we use the last changelog date via `%source_date_epoch_from_changelog Y` The duplication is rather small, though. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/933#issuecomment-552350993___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Cannot set Build Date from changelog anymore (#932)
OK, so I was just annoyed that it took over 2 years from the commit to me finding this issue and #934 . With 4.15-alpha only out in 2019-06, it is probably fairer to say, that rpm upstream could improve there. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/932#issuecomment-552350110___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] 4.15 creates unreproducible rpm mime headers (#934)
While working on reproducible builds for openSUSE, I found that rpm 4.15 creates rpm headers with mime types in random order. Results become reproducible when I build on a 1-core VM, so it is probably related to the parallelism added in 4.15. To see these headers I used `strings` on rpms that were building identical with 4.14.2 . Diff looks thus: ```diff --- filter/RPMS.2017/khmeros-fonts-5.0-0.0.noarch.rpm +++ filter/RPMS/khmeros-fonts-5.0-0.0.noarch.rpm @@ -146,13 +146,13 @@ cpio noarch-suse-linux directory -TrueType Font data, 23 tables, 1st "GDEF", 37 names, Macintosh, KhmerOS - font for the Khmer language of Cambodia??Copyright 2007 Danh Hong?? ??This font is fr -TrueType Font data, 18 tables, 1st "GDEF", 35 names, Macintosh, KhmerOS - font for the Khmer language of Cambodia??Copyright 2007 Danh Hong?? ??This font is fr +ASCII text TrueType Font data, 18 tables, 1st "GDEF", 35 names, Macintosh, KhmerOS - font for the Khmer language of Cambodia??Copyright 2005 Danh Hong??Copyright 2005 Ope -TrueType Font data, 23 tables, 1st "GDEF", 35 names, Macintosh, KhmerOS - font for the Khmer language of Cambodia??Copyright 2007 Danh Hong?? ??This font is fr TrueType Font data, 18 tables, 1st "GDEF", 36 names, Macintosh, KhmerOS - font for the Khmer language of Cambodia??Copyright 2007 Danh Hong?? ??This font is fr TrueType Font data, 18 tables, 1st "GDEF", 35 names, Macintosh, KhmerOS - font for the Khmer language of Cambodia??Copyright 2007 Danh HongThis font is fre -ASCII text +TrueType Font data, 18 tables, 1st "GDEF", 35 names, Macintosh, KhmerOS - font for the Khmer language of Cambodia??Copyright 2007 Danh Hong?? ??This font is fr +TrueType Font data, 23 tables, 1st "GDEF", 37 names, Macintosh, KhmerOS - font for the Khmer language of Cambodia??Copyright 2007 Danh Hong?? ??This font is fr +TrueType Font data, 23 tables, 1st "GDEF", 35 names, Macintosh, KhmerOS - font for the Khmer language of Cambodia??Copyright 2007 Danh Hong?? ??This font is fr if [ -e /run/fontpackages/reconfigure-fonts ]; then if test -x /usr/sbin/fonts-config ; then ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/934___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Cannot set Build Date from changelog anymore (#932)
CC @kanavin @ffesti because you worked on that patch 2 years ago (yes, openSUSE is slow to adopt new major rpm versions) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/932#issuecomment-551832511___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Cannot set Build Date from changelog anymore (#932)
This is a regression over 4.14.2 and not from #785 I do set ``` %_buildhost reproducible %source_date_epoch_from_changelog Y %clamp_mtime_to_source_date_epoch Y %use_source_date_epoch_as_buildtime Y ``` and I can see with `rpm -qpvl` that the file mtimes are correctly adjusted, but the Build Date header gets the current time with 4.15, where it got the changelog date with 4.14.2 I think commit fa303d5ba6bef5b4a44b884c6dadadc27b594caa broke setting `RPMTAG_BUILDTIME` from `SOURCE_DATE_EPOCH` when that is only parsed from the first changelog entry later. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/932___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow to keep a minimum number of changelog entries (#931)
https://github.com/bmwiedemann/openSUSE/blob/master/packages/r/rpm/rpm-shorten-changelog.diff maybe? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/931#issuecomment-551710004___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Allow to keep a minimum number of changelog entries (#931)
Allow to keep a minimum number of changelog entries because some tools and workflows break when `_changelog_trimtime` dropped all entries. This also helps reproducible builds because `%source_date_epoch_from_changelog` can only work when there is an entry left Note: test is still in progress You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/931 -- Commit Summary -- * Allow to keep a minimum number of changelog entries -- File Changes -- M build/parseChangelog.c (4) M macros.in (4) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/931.patch https://github.com/rpm-software-management/rpm/pull/931.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/931 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Initialize verifyFlags for specialdir (#656)
Initialize verifyFlags for specialdir, because FileEntryFree(>cur) zeroed all fields, including verifyFlags, so we have to fill them again. Closes issue #655 Note: only slightly tested You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/656 -- Commit Summary -- * Initialize verifyFlags for specialdir -- File Changes -- M build/files.c (1) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/656.patch https://github.com/rpm-software-management/rpm/pull/656.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/656 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Document uncompressed payload (#542)
e.g. can be useful for src.rpms where .tar.xz files are already compressed You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/542 -- Commit Summary -- * Document uncompressed payload -- File Changes -- M macros.in (1) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/542.patch https://github.com/rpm-software-management/rpm/pull/542.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/542 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
I'm already producing bit-identical RPMs using the 4 macros documented in https://en.opensuse.org/openSUSE:Reproducible_Builds So no changes on digests or signatures are needed atm. Inaccuracy of $SOURCE_DATE_EPOCH does not matter, as long as it is in the past. Some people always set it to 1 (aka 1970-01-01 00:00:01) and are happy. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/536#issuecomment-417835992___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] build: Make sure SOURCE_DATE_EPOCH is in the past (#536)
Make sure SOURCE_DATE_EPOCH is in the past, otherwise, builds before noon will not have normalized mtimes from %clamp_mtime_to_source_date_epoch This also helps other programs like tar --clamp-mtime Tested successfully on openSUSE. To reproduce, create a changelog entry with only a date ``` * Fri Aug 31 2018 user@host - dummy ``` and build it before 12:00 UTC using macros ``` %source_date_epoch_from_changelog Y %clamp_mtime_to_source_date_epoch Y %use_source_date_epoch_as_buildtime Y %_buildhost reproducible ``` `rpm -qpvl` showed file mtime values to not be normalized and therefore build results were not bit-identical. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/536 -- Commit Summary -- * build: Make sure SOURCE_DATE_EPOCH is in the past -- File Changes -- M build/build.c (7) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/536.patch https://github.com/rpm-software-management/rpm/pull/536.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/536 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] find-debuginfo.sh: sort output of find (#485)
updated to be minimal -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/485#issuecomment-411210510___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] find-debuginfo.sh: sort output of find (#485)
I experimented some more with it and found that only the sort in `dwz_files` makes all the difference to the `shadow` binary rpm. Do you prefer a minimal patch? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/485#issuecomment-409801449___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] find-debuginfo.sh: sort output of find (#485)
@bmwiedemann pushed 1 commit. 166a65a find-debuginfo.sh: ignore locales -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/485/files/388f20dc91c19c762f498d45fbf05401ae18633e..166a65a333636dae65c4a84420682167086248e1 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Add tests/README (#486)
to document how to run tests You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/486 -- Commit Summary -- * Add tests/README -- File Changes -- A tests/README (8) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/486.patch https://github.com/rpm-software-management/rpm/pull/486.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/486 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] find-debuginfo.sh: sort output of find (#485)
We could add on top `export LC_ALL=C` to make sure locales do not influence the result (and drop the other 2 inline instances of that). I did not yet bisect which of the changes makes what difference because test-cycles are slow. >> Note: elfbins.list has remaining indeterminism from the `run_job` >> function running in parallel unless using `-j1` > So, this isn't a problem for creating reproducible builds? No, that seems to not make a difference on rpms - only makes the build filesystem diff a bit messier. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/485#issuecomment-409179734___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] find-debuginfo.sh: sort output of find (#485)
sort output of find in find-debuginfo.sh to make build results more reproducible in spite of indeterministic filesystem readdir order. Even where these lists do not become part of an rpm, it makes it easier to debug unrelated issues by having less overall diff from diffing build filesystem trees (one of the standard reproducibility-debugging techniques I use). For openSUSE, this helped to make squid, openssh, postfix and shadow packages build reproducibly. See https://reproducible-builds.org/ for why this is good. Note: elfbins.list has remaining indeterminism from the `run_job` function running in parallel unless using `-j1` Note: only tested in a slightly different variant on openSUSE's rpm-4.14.1 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/485 -- Commit Summary -- * find-debuginfo.sh: sort output of find -- File Changes -- M scripts/find-debuginfo.sh (9) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/485.patch https://github.com/rpm-software-management/rpm/pull/485.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/485 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Override ghost+dir filesizes (#229)
Closed #229. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/229#event-1112101274___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Override ghost+dir filesizes (#229)
for directories and ghost files we do not want to
record their size in binary rpms
to make builds more reproducible.
See https://reproducible-builds.org/ for why this matters.
Note: I'm not sure if this is the best/correct way to do this, but at least it
made the packages build bit-identical where they did not before.
To test add to %install section:
```
cd %{buildroot}/some/packaged/dir
for i in $(seq 1 $RANDOM) ; do touch xxx$i ; done
rm xxx*
```
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/229
-- Commit Summary --
* Override ghost+dir filesizes
-- File Changes --
M build/files.c (3)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/229.patch
https://github.com/rpm-software-management/rpm/pull/229.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/229
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Do not store digests of ghost files (#228)
Do not store digests of ghost files
when the files exist during build time.
The hash will never be used for verification anyway.
This helps making packages build more reproducibly.
To test use
```
echo $RANDOM > %{buildroot}/var/cache/ghostfile
%files
%ghost /var/cache/ghostfile
```
and check with `rpm -qp --dump $RPM`
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/228
-- Commit Summary --
* Do not store digests of ghost files
-- File Changes --
M build/files.c (2)
-- Patch Links --
https://github.com/rpm-software-management/rpm/pull/228.patch
https://github.com/rpm-software-management/rpm/pull/228.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/228
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow SOURCE_DATE_EPOCH to override file timestamps (#144)
on the semi-offtopic python .pyc timestamp issue see: https://github.com/python/cpython/pull/296 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/144#issuecomment-284450175___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow SOURCE_DATE_EPOCH to override file timestamps (#144)
@ffesti I restructured the code to get rid of the ugly 'static' globals. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/144#issuecomment-278313503___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] set SOURCE_DATE_EPOCH from changelog (#143)
I put it there because the spec says: > Build systems MUST NOT overwrite this variable for child processes to consume > if it is already present. But then, it probably does not apply if we had set it ourselves (and not the user) for the previous rpm to build. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/143#issuecomment-276958227___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Allow SOURCE_DATE_EPOCH to override file timestamps (#144)
On 2017-02-02 13:46, Florian Festi wrote: > I am not too keen on the use of global variable Do you refer to "oneshot" or "SOURCE_DATE_EPOCH"? > I wonder how we want to address the Python .pyc file issue I was thinking that it would be better to do it like Debian and generate those in %post which also reduces the size of rpms and allows it to be noarch -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/144#issuecomment-276951194___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] set SOURCE_DATE_EPOCH from changelog (#143)
test looks good. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/143#issuecomment-276685196___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] set SOURCE_DATE_EPOCH from changelog (#143)
change looks reasonable. I am giving it a round of testing. Under what condition would headerGet return false here? OOM? no changelog entry found? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/143#issuecomment-276678061___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] set SOURCE_DATE_EPOCH from changelog (#141)
@ffesti added to macros.in and disabled the message for now, because I cannot find test 008 and 295 and I do not understand why it would get the message, which should only be output when $SOURCE_DATE_EPOCH is set. Is it set in your test environment? How to test locally? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/141#issuecomment-276617474___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] set SOURCE_DATE_EPOCH from changelog (#141)
set SOURCE_DATE_EPOCH from changelog timestamp if requested by macro to allow for more reproducible builds of packages. See https://reproducible-builds.org/ for why this is good and https://reproducible-builds.org/specs/source-date-epoch/ for the definition of this variable. note: if changelog has only dates without times, time component will always be 12:00:00 but that is usually fine You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/141 -- Commit Summary -- * set SOURCE_DATE_EPOCH from changelog -- File Changes -- M build/parseChangelog.c (10) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/141.patch https://github.com/rpm-software-management/rpm/pull/141.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/141 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
