I'd still like to see this merged. It is optional and default-off, so it should
not negatively affect anyone.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2762#issuecomment-2360145822
You are receiving this because you are subscribed t
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
"--de
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
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/discu
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/S
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 po
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.
Mes
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 co
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).
--
R
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_epo
> %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 `%
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 exp
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-18096414
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
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 nam
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
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 GitHu
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
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.
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:
htt
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_bu
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.
Messag
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.
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 `ma
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
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-137820
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
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 us
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";
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 CP
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 o
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 o
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.ht
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
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___
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__
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
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___
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 dif
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#pullreq
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/
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
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.rp
> 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.
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 em
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 we
Set Build Date from changelog again
This is needed because fa303d5ba6 had moved the code that used
`getenv("SOURCE_DATE_EPOCH")` to run before we do `setenv` here.
See https://reproducible-builds.org/ for why this is good.
Fixes #932
You can view, comment on, or merge this pull request online a
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/9
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 Da
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-551710
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
Initialize verifyFlags for specialdir, because
FileEntryFree(&fl->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-manageme
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)
--
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
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
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
ht
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-mana
@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..166a65a333636dae65c4a844206821
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-managem
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_j
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 (
OK. Commit 2cf7096ba534b065feb038306c792784458ac9c7 should be good enough for
now, though there might be some corner cases where management tools took the
old value into account and now might overcommit.
--
You are receiving this because you are subscribed to this thread.
Reply to this email di
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.o
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 whe
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 wit
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_
> And this outlaws commenting multiline macros. Which, if you really think
> about it, seems totally absurd.
The point is that commenting out multi-line macros never worked. If I
understand it correctly, it expanded to a commented first line and left the
remaining lines uncommented which can ca
@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__
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
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
Limit the maximum date to SOURCE_DATE_EPOCH, if defined
similar to the tar --clamp-mtime option
based on a patch by Nicolas Vigier
together with previously merged
#143
b8a54d6a1e9bb6140b6b47e23dc707e4b967537e from @boklm
22588250baa1bfa5c00f57d39329d0c144fc8112
This allows rpmbuild to produce
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@l
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-softwa
@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 t
This change is not about changing changelog dates, but using the topmost
changelog date to set a variable that can be used inside the built software.
Please have another look.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
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 ha
76 matches
Mail list logo
