• RE: Reproducible builds of ports

    From Mark Millard@marklmi@yahoo.com to muc.lists.freebsd.ports on Sat Nov 8 22:01:44 2025
    From Newsgroup: muc.lists.freebsd.ports

    cen <imbacen_at_gmail.com> wrote on
    Date: Sat, 08 Nov 2025 20:27:28 UTC :

    I would like to know if there is any conceivable way to do independent reproducible builds of the ports tree packages today?

    The biggest obstacle seems to be the fact that FreeBSD does not have a snapshot/archive repo equivalent to snapshot.debian.org.


    My current approach is to fetch the .pkg, extract the ports_top_git_hash metadata, checkout the ports tree to that commit and run e.g. poudriere
    bulk -j "$JAIL" -p "$PORTS_TREE" "$ORIGIN"

    But I am not sure how poudriere handles changes in port tree commit
    hash. If a next package comes in with a different ports_top_git_hash,

    will poudriere be able to reuse any common dependencies that were
    already built or will it have to rebuild the whole tree again?

    The latter scenario is obviously a huge resource waste and an automatic no.


    My first question is whether my approach is generally sound for trying
    to reproduce a single package? If not, how should I correct my workflow?

    My second one is for any workarounds or "close enough" techniques that
    would at least be able to reproduce some amount of packages. I'd be
    happy even with 10% reproducibility.


    If I can find some path forward, I'd like to ultimately add FreeBSD
    support to rebuilderd, a cross-distro effort to make distro packages independently reproducible.

    With 30000+ ports that can build 37000+ port-packages,
    I doubt anyone knows which ones can produce byte-for-byte
    exact matches from correctly matched inputs vs. which ones
    cannot overall. That likely could be a whole research
    topic of its own.

    I also do not know if port-package files (.pkg) would
    always match in cases where the installed materials
    would be a byte-for-byte match. Those two are not the
    same thing. Which are you after? Both types?

    ===
    Mark Millard
    marklmi at yahoo.com



    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cen@imbacen@gmail.com to muc.lists.freebsd.ports on Mon Nov 10 10:29:44 2025
    From Newsgroup: muc.lists.freebsd.ports

    Hi

    On 10/11/2025 03:21, Simon Wright wrote:
    Unless I'm missing something, wouldn't using poudriere with the same make.conf as the package builders and default options from the same
    git build give *functionally* identical packages?

    The goal is bit-for-bit reproducibility, "functionally" is not enough.

    I don't have a need for identical packages but I find it useful and
    elegant to check the git build level being used by the package
    builders, checkout the same build then build my few packages and dependencies locally. That way I get my options included in my
    packages where necessary but the rest of the packages are unaffected.
    Doing this for the whole tree with default options throughout should
    get the OP what he needs. Yes? Or have I misunderstood what is needed?

    Right, I think my current issue is how I rebuild packages. They are sent
    into a queue for rebuild in alphanumeric or random-ish order, which
    means that when I check

    out the ports tree for each one (using the same jail), the tree can jump
    back and forth in commit history.

    I did have an epiphany last night that if I actually grouped packages by
    port tree commit and build them in commit timestamp order,

    I would essentially be tracking what the upstream CI does and only
    progress forward.


    Best regards



    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Simon Wright@simon.wright@gmx.net to muc.lists.freebsd.ports on Mon Nov 10 23:46:10 2025
    From Newsgroup: muc.lists.freebsd.ports

    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------HTyX054KaW9mJpxJZWTMbuvt
    Content-Type: multipart/mixed; boundary="------------NZ00OrMbJznsr0W0pqK9pO6s";
    protected-headers="v1"
    From: Simon Wright <simon.wright@gmx.net>
    To: ports@freebsd.org
    Message-ID: <1ca802fb-84e6-41ea-8d97-3ffd71fa3e66@gmx.net>
    Subject: Re: Reproducible builds of ports
    References: <E78A7ED3-5B05-4033-988A-A5E53D582B86.ref@yahoo.com>
    <E78A7ED3-5B05-4033-988A-A5E53D582B86@yahoo.com>
    <dab64520-1afc-44e2-b60a-7f2512916e24@gmail.com>
    <5ed4a69d-3c18-4d93-82bc-8a2ae3adc648@gmx.net>
    <e8577bda-ac45-4c67-a9d9-248d899f5e1d@gmail.com>
    In-Reply-To: <e8577bda-ac45-4c67-a9d9-248d899f5e1d@gmail.com>

    --------------NZ00OrMbJznsr0W0pqK9pO6s
    Content-Type: multipart/mixed; boundary="------------KNcjezPMSjbLvTjbmqH2jjNm"

    --------------KNcjezPMSjbLvTjbmqH2jjNm
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    DQoNCk9uIDIwMjUtMTEtMTAgMTc6MjksIGNlbiB3cm90ZToNCj4gSGkNCj4gDQo+IE9uIDEw LzExLzIwMjUgMDM6MjEsIFNpbW9uIFdyaWdodCB3cm90ZToNCj4+IFVubGVzcyBJJ20gbWlz c2luZyBzb21ldGhpbmcsIHdvdWxkbid0IHVzaW5nIHBvdWRyaWVyZSB3aXRoIHRoZSBzYW1l IA0KPj4gbWFrZS5jb25mIGFzIHRoZSBwYWNrYWdlIGJ1aWxkZXJzIGFuZCBkZWZhdWx0IG9w dGlvbnMgZnJvbSB0aGUgc2FtZSANCj4+IGdpdCBidWlsZCBnaXZlICpmdW5jdGlvbmFsbHkq IGlkZW50aWNhbCBwYWNrYWdlcz8NCj4gDQo+IFRoZSBnb2FsIGlzIGJpdC1mb3ItYml0IHJl cHJvZHVjaWJpbGl0eSwgImZ1bmN0aW9uYWxseSIgaXMgbm90IGVub3VnaC4NCkFoISBZb3Ug bWVudGlvbmVkIHRoZSAiYnVpbGQgZW52aXJvbm1lbnQiIGJlaW5nIGNsb3NlIHRvIHVwc3Ry ZWFtIGJ1aWxkIA0KZW52aXJvbm1lbnQuIEkgdGhvdWdodCB0aGlzIHJlZmVycmVkIHRvIHRo ZSBiaXQtZm9yLWJpdCBwYWNrYWdlIA0KY3JpdGVyaW9uIHlvdSBoYWQgbWVudGlvbmVkIGVh cmxpZXIgYW5kIHN1cGVyY2VkZWQgaXQuIE15IG1pc3Rha2UuIEdvb2QgDQpsdWNrIQ0KDQpT aW1vbi4NCg==
    --------------KNcjezPMSjbLvTjbmqH2jjNm
    Content-Type: application/pgp-keys; name="OpenPGP_0x3E276F607A844457.asc" Content-Disposition: attachment; filename="OpenPGP_0x3E276F607A844457.asc" Content-Description: OpenPGP public key
    Content-Transfer-Encoding: quoted-printable

    -----BEGIN PGP PUBLIC KEY BLOCK-----

    xsDNBGi1W5wBDAC9xnqQWSS96rO5m1UuwNOvdX4CDbw96+Uxy9pltOlWQQ4ZWOny 5lgvKef3YS79ftlX9t2720E6EvlzeQOMnU0zcUOlfUwwa2fZT23eHRB3ZyPrVuWg NYCa8uZ04zZRLCx03Ng8pUgpCi0B8shFmFOmIz4hOoVyTSbqR8FHR7Yhj4YSLCW9 8m4/bHKZz/40aCVYa/UibOOeySkB0XnjAqrf14rlc8Vy2blw0IFSOA7kiGL/mBFJ s2ed6Y9yuXbWrU/VsG8L8ahoHfkmnU3dcBVe4bkDp5hAKzIl0Sqn006y5r7nqrrc GNv3y20oQDZoKXm/EQSCe8zEpgaMssYi4cm6NUk/3p2JRKV1b6toyJ98X5g37VFC jpor4SLAVTsFdjlWfV1jLUrxKDFyLyFXv2/1rvPXTN3zTlJGVxX3pjrfhD9zkjBv tcaU3vrJm7Jo08K1TsfCCb+sAhEXVibVXjM9g0seE8b4ccRpJrWOl4pR0D1NqK3d mViwFLp/iOfgQj0AEQEAAc0jU2ltb24gV3JpZ2h0IDxzaW1vbi53cmlnaHRAZ214 Lm5ldD7CwQ0EEwEIADcWIQTlQC68fKzaIsqsofk+J29geoREVwUCaLVbngUJAeEz gAIbAwQLCQgHBRUICQoLBRYCAwEAAAoJED4nb2B6hERXUK4L/i0qsL+tW0xUL+uG S68TsC3o0V5NqnO/3xOezImbGwefMim1neI7x6N1hUwoRsz9bdNh9AWCvN5ohRLT FpvEk+0Ud3a4pemQptP+85d7ZclVPIZCJbGI9w25eNHCa6Kurcsjq0OoEF1mgjK5 a+IECTPihiN9WVmi6TVKulF6MEHGIe6N65tmp08un9W3kMZJ1igKwBwpxQO2id68 4p0sKamChNTtC+MzYeccE8W8Pyw8MUMcyqPOFcsh0NI3RPGIM69yiJqp1uIFNNMQ R2Le5OL3uU1YOuFJk+PV+y7JiLJXfhfPdivBNefDGKrlc43aunibSFXMtFTPqEZ/ 8p9//wXyALszsLlIdsYPRYd0vWVlFBNhUGE6WOFxzsHhYSBydQWEAuPNrDm7KWGw hWS5Hh7PjCn2oWcRijz/W+YodDHd8H5+nII3AjGLyotIAgyX9spdA4cBIr6AtOXY th2vTKnT6Rd6zn0+j1c7hBrBmvBkXTedkOpTE7XVl4ETa0MNkc7AzQRotVueAQwA 0slePhZIDGeAVhuau/Ou8tByqFVodn6uCewCm0aBUqUU5Q5YHTUK9aaWjn+JCv3D lN0/qhENJ4SeoLV1vDAVFEKrMW0ED9bbNyX2GiGOvS2GfFcrBrsbv+pDvh8+mfe3 P5EGM5uIWIY79sDxW3of0QpvSdXhN+EaRWC8lwpGC+VFnlr0Ao8zypeDwkNp/NsA 2vAqJQWJkDvB2g6PyjjZF3h5ioMaqm79zrWnJPdzsjQLMwLb03LwrkweVhC/TM70 W1bIA1EyJfWkIB5LAILdzsNSbwlM9D7185vwP3y8QKJ4AbUjQRQkpE+6d6w+oDRh TWFFkpUdL/bwI3UkVZ2yBpAUJJ1AN3sSyV7mKDPCHvLTHsQnSuLq9alHIR1ed8SN 03QjWJVvD45BFbjPzrE4zZyfsL4yA644GjDAMRNUh5k+a6uzOFP+C8ipP61+iA+V pWxbn5rWk7Aq07HjuqIcV9yP+GkPwxlfzHznXliL51HGww5a4Nwp8CB3OgpPedWl ABEBAAHCwPwEGAEIACYWIQTlQC68fKzaIsqsofk+J29geoREVwUCaLVbnwUJAeEz gAIbDAAKCRA+J29geoREV78nDACS/fnbRC6RJr8E2+CmTlBelcSFwGWr2ppaKBqB rL6i4Yo8QZPpAFo4zV8r6F9FaVp8353rsL/InmDUbr+wZgMwLp7hV6xtmeMXagqd qaYQTq/WH+OcIkOpXpKoiXFS3iqbWPZJTJFzVSmgjPTW7i2+oSUiCyo1QdxibCUT CcYGt6M/eHrfmDt0zCe4QbbJBy/5MSh3QhT4SuiNi3Xn2Pix9OE6fGn0JbB4fi1+ RG2Y2lefwEJj30UoZFZbyY5zBQG5dmVEVQMqV030/bT0mErP3U1EtGO1qDABT3c3 Py6NjvPK3YOrCKe5iAgzZJfu/5YXkLccprXybWCS/6/b2kHRXO8S0XDHVI+wSXUD vi4VP4Yjywd8fMurxTabK/vbNEZcYgMYP8ApaH1zxKQsQyGv98+tZ0YEPtzDlme1 gwZpMfUdOfTBwCrjNyh8zYOEweo14cMpS7jYt0MW3fdhT4VuzWbOiKVAuE+Etg1I gncBFSi/oRtENuYjo3CUQV/E63A=3D
    =3DS2zc
    -----END PGP PUBLIC KEY BLOCK-----

    --------------KNcjezPMSjbLvTjbmqH2jjNm--

    --------------NZ00OrMbJznsr0W0pqK9pO6s--

    --------------HTyX054KaW9mJpxJZWTMbuvt
    Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature
    Content-Disposition: attachment; filename="OpenPGP_signature.asc"

    -----BEGIN PGP SIGNATURE-----

    wsD5BAABCAAjFiEE5UAuvHys2iLKrKH5PidvYHqERFcFAmkSCMMFAwAAAAAACgkQPidvYHqERFeQ 1Av8Cz8RTo0ScZQEfRx47uKYBzVHFS8fqqx2DqZi27S5jJ1FalNXO4bQTha1xlas3pCyzA0hGrkP M8CVZTcDHNXTOf/ZYXickL0o3k0gJEaCrdXgI+OD+VFFad1OOrT6f8K1MX7DEYQFBGAnjgwz7AyW YdQ8kJI2D/6805SDElrjEdjUF7yrLsWYesozop/jhQYdUh799h70LOQ8pj7um/8y9dMI+gEGuolL 7ct9KGAxDG01c60M84xXi+p41alsI0LItY2hupZxIQsSKOmXYzO2Ni0dEkuvVlXMmPjzbD2xsADc 1d8pyfdD5LaRq6t/R/G9vNy8dIYXwzgxkcWptKRI7uHvWAD2ooMuJYbYcACmDuz4u4dfJsu7VXCt gWVLBq5+aZGq37mVdpGvrobo1eFij88pC8N27T09GX/J51TjKpM4JegwSljxKw8pGYHu0GjpArT2 CWY9ao2J+1spl0l8ZXBD6/aqXyELA8vNGBs6MTzq4nEK0sIyWzjFbtkjSHSW
    =D55Q
    -----END PGP SIGNATURE-----

    --------------HTyX054KaW9mJpxJZWTMbuvt--


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Andrea Cocito@andrea@cocito.eu to muc.lists.freebsd.ports on Mon Nov 10 17:01:52 2025
    From Newsgroup: muc.lists.freebsd.ports

    N++
    Sent from my iPhone
    On 10 Nov 2025, at 09:05, Tatsuki Makino <tatsuki_makino@hotmail.com> wrote: However, if the reason curl is being rebuilt is due to an upgrade of the it depends on, then rebuilding only ftp/curl can avoid rebuilding rust.
    Hi,
    I am not completely sure this is correct if we are talking in terms of *reprducible* builds.
    In principle an upgrade in libnghttp2 might trigger a change in the behavior of curl which (even if curl is only a build dependency of rust) might change the way rust is built.
    For this example it is merely theoretical but if you consider a build dependency on a compiler which on its turn depends on a lot of stuff I would not bet on it.
    IMHO the only way a port build might be rCLreproduciblerCY is:
    1. Make a clean and empty machine (from release, no ports, no packages).
    2, Check out somehow the port tree at a stable state
    3. cd /usr/ports/some/port ; make
    This has always been *the* way to build a rCLcleanrCY port on FreeBSD. Unfortunately, in the last months/years, this often does not even work; and itrCOs quite sad, when it happens, to see #notabug #wontfix #usepoudriere #usepkg
    All the best,
    A.
    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Charlie Li@vishwin@freebsd.org to muc.lists.freebsd.ports on Mon Nov 10 14:53:54 2025
    From Newsgroup: muc.lists.freebsd.ports

    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------9qU2G8HSGtJUnl85we0krx3q
    Content-Type: multipart/mixed; boundary="------------4RS5LxFSFkqzTjICuMGbPm4M";
    protected-headers="v1"
    Message-ID: <06fee202-efae-47cb-9db2-6fbae8280fcc@freebsd.org>
    Date: Mon, 10 Nov 2025 14:53:54 -0500
    MIME-Version: 1.0
    User-Agent: Mozilla Thunderbird
    Subject: Re: Reproducible builds of ports
    To: cen <imbacen@gmail.com>, ports@freebsd.org
    References: <E78A7ED3-5B05-4033-988A-A5E53D582B86.ref@yahoo.com>
    <E78A7ED3-5B05-4033-988A-A5E53D582B86@yahoo.com>
    <dab64520-1afc-44e2-b60a-7f2512916e24@gmail.com>
    <5ed4a69d-3c18-4d93-82bc-8a2ae3adc648@gmx.net>
    <e8577bda-ac45-4c67-a9d9-248d899f5e1d@gmail.com>
    Content-Language: en-GB
    From: Charlie Li <vishwin@freebsd.org>
    Autocrypt: addr=vishwin@freebsd.org; keydata=
    xjMEaEicoBYJKwYBBAHaRw8BAQdAZBuydpjFLGem4uRJPWaYMXX2e+BN1jDhbD3tcqbxhdfN
    MkNoYXJsaWUgTGkgKEZyZWVCU0QgUHJvamVjdCkgPHZpc2h3aW5ARnJlZUJTRC5vcmc+wpkE
    ExYKAEEWIQTHxcCLnAXo3rFg6k7P+1cn7slqBAUCaEicoAIbAwUJCWYBgAULCQgHAgIiAgYV
    CgkICwIEFgIDAQIeBwIXgAAKCRDP+1cn7slqBM/bAP9bhA4e0LxJYFYJlftZM5WHrMSPpUe6
    G2pVqmQWTQ0EZQEA0PNryfH3qRWWPSI8mFNRnG24hi5/aXFqCnHj1tcJ9Q/OOARoSJygEgor
    BgEEAZdVAQUBAQdAUT4TzYFmV6ueIGwjX0N+445KZV6ns1Wiw67QMsJZxHkDAQgHwn4EGBYK
    ACYWIQTHxcCLnAXo3rFg6k7P+1cn7slqBAUCaEicoAIbDAUJCWYBgAAKCRDP+1cn7slqBPO/
    AQCPuGiyyfJClICRs/ToG0MsT8YcPdBygzuUIIeGpkjJpgEA7AoFCQ0Y28Y3hIDFn2k9PH3B
    nGWL3g05W0ds2qoj+gQ=
    Organization: FreeBSD Project
    In-Reply-To: <e8577bda-ac45-4c67-a9d9-248d899f5e1d@gmail.com>

    --------------4RS5LxFSFkqzTjICuMGbPm4M
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    Y2VuIHdyb3RlOg0KPiBUaGUgZ29hbCBpcyBiaXQtZm9yLWJpdCByZXByb2R1Y2liaWxpdHks ICJmdW5jdGlvbmFsbHkiIGlzIG5vdCBlbm91Z2guDQo+IA0KVGhpcyBpcyBjb21wbGV0ZWx5 IGltcG9zc2libGUgZm9yIGFueSBvcGVyYXRpbmcgc3lzdGVtIHBhY2thZ2UgDQpkaXN0cmli dXRpb24uICJGdW5jdGlvbmFsbHkiIGlzIHRoZSBiZXN0IHlvdSBjYW4gZ2V0Lg0KDQpDb25z aWRlciB0aGF0IFB5dGhvbiBwb3J0cyBidWlsdCB1bmRlciBzb21lIENQeXRob24gKGllIFB5 dGhvbiBmcm9tIA0KcHl0aG9uIGRvdCBvcmcpIGFsbW9zdCBhbHdheXMgaW5jbHVkZSBpbnRl cnByZXRlciBieXRlY29kZSBpbiB0aGUgDQpyZXN1bHRpbmcgcGFja2FnZSwgYXQgbGVhc3Qg Y3VycmVudGx5LiBGb3IgbG9uZywgb2JzY3VyZSBidXQgcHJhY3RpY2FsIA0KcmVhc29ucyB0 aGF0IGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZGlzY3Vzc2lvbiwgYnl0ZWNvZGUg Y29tcGlsZWQgDQpmcm9tIHRoZSBzYW1lIHNvdXJjZSBkdXJpbmcgb25lIHJ1biBpcyBuZXZl ciBiaXQtZm9yLWJpdCBpZGVudGljYWwgdG8gDQphbm90aGVyIHJ1biwgYnV0IGFyZSBvdGhl cndpc2UgZnVuY3Rpb25hbGx5IGlkZW50aWNhbC4gVGhpcyBpcyB0cnVlIGZvciANCnNvbWUg b3RoZXIgaW50ZXJwcmV0ZWQgbGFuZ3VhZ2VzIGFuZCBydW50aW1lcyB0aGF0IGludm9sdmUg Ynl0ZWNvZGUuDQoNCi0tIA0KQ2hhcmxpZSBMaQ0KLi4ubm9wZSwgc3RpbGwgZG9uJ3QgaGF2 ZSBhbiBleGl0IGxpbmUuDQo=

    --------------4RS5LxFSFkqzTjICuMGbPm4M--

    --------------9qU2G8HSGtJUnl85we0krx3q
    Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature
    Content-Disposition: attachment; filename="OpenPGP_signature.asc"

    -----BEGIN PGP SIGNATURE-----

    wnsEABYIACMWIQTHxcCLnAXo3rFg6k7P+1cn7slqBAUCaRJC0wUDAAAAAAAKCRDP+1cn7slqBOPt AP9gJ6oBf4OiDJXxOVKf7typTp/ME521X2x8bShkJhHdcwD/Wm4GoJASYMUlqsFhpXOzXYfYPVl+ WoutKjyMZfCHagE=
    =TZPU
    -----END PGP SIGNATURE-----

    --------------9qU2G8HSGtJUnl85we0krx3q--


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Kurt Jaeger@pi@freebsd.org to muc.lists.freebsd.ports on Tue Nov 11 10:26:23 2025
    From Newsgroup: muc.lists.freebsd.ports

    Hi!

    cen wrote:
    The goal is bit-for-bit reproducibility, "functionally" is not enough.

    This is completely impossible for any operating system package
    distribution. "Functionally" is the best you can get.

    Debian does it, so it does not seem to be out of the realm of
    the possible.
    --
    pi@FreeBSD.org +49 171 3101372 Now what ?


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Ronald Klop@ronald-lists@klop.ws to muc.lists.freebsd.ports on Tue Nov 11 12:54:19 2025
    From Newsgroup: muc.lists.freebsd.ports

    ------=_Part_146898_1632862847.1762862058992
    Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit

    There is a website about this.

    https://reproducible-builds.org/docs/source-date-epoch/

    Regards,
    Ronald.




    Van: Tatsuki Makino <tatsuki_makino@hotmail.com>
    Datum: dinsdag, 11 november 2025 10:17
    Aan: Charlie Li <vishwin@freebsd.org>, cen <imbacen@gmail.com>, ports@freebsd.org
    Onderwerp: Re: Reproducible builds of ports

    Ah, I see, so it was a topic in that direction :)

    ELF format itself doesn't, by default, include information such as the compilation timestamp, maybe.
    Even code that uses preprocessor __DATE__ and __TIME__ won't be reproducible unless we stop the clock, maybe.

    At the very least, we can't make the parts involving such times match perfectly, can we? :)

    Regards.

    On 2025/11/11 4:53, Charlie Li wrote:
    cen wrote:
    The goal is bit-for-bit reproducibility, "functionally" is not enough.

    This is completely impossible for any operating system package distribution. "Functionally" is the best you can get.

    Consider that Python ports built under some CPython (ie Python from python dot org) almost always





    ------=_Part_146898_1632862847.1762862058992
    Content-Type: text/html; charset=us-ascii
    Content-Transfer-Encoding: 7bit

    <html><head></head><body>There is a website about this.<br>

    https://reproducible-builds.org/docs/source-date-epoch/<br>

    Regards,<br>
    Ronald.<br>



    &nbsp;
    <p><strong>Van:</strong> Tatsuki Makino &lt;tatsuki_makino@hotmail.com&gt;<br> <strong>Datum:</strong> dinsdag, 11 november 2025 10:17<br> <strong>Aan:</strong> Charlie Li &lt;vishwin@freebsd.org&gt;, cen &lt;imbacen@gmail.com&gt;, ports@freebsd.org<br>
    <strong>Onderwerp:</strong> Re: Reproducible builds of ports</p>

    <blockquote style="padding-right: 0px; padding-left: 5px; margin-left: 5px; border-left: #000000 2px solid; margin-right: 0px">
    <div class="MessageRFC822Viewer" id="P">
    <div class="TextPlainViewer" id="P.P">Ah, I see, so it was a topic in that direction :)<br>

    ELF format itself doesn't, by default, include information such as the compilation timestamp, maybe.<br>
    Even code that uses preprocessor __DATE__ and __TIME__ won't be reproducible unless we stop the clock, maybe.<br>

    At the very least, we can't make the parts involving such times match perfectly, can we? :)<br>

    Regards.<br>

    On 2025/11/11 4:53, Charlie Li wrote:<br>
    &gt; cen wrote:<br>
    &gt;&gt; The goal is bit-for-bit reproducibility, "functionally" is not enough.<br>
    &gt;&gt;<br>
    &gt; This is completely impossible for any operating system package distribution. "Functionally" is the best you can get.<br>
    &gt;<br>
    &gt; Consider that Python ports built under some CPython (ie Python from python dot org) almost always</div>

    <hr></div>
    </blockquote>

    &nbsp;</body></html>
    ------=_Part_146898_1632862847.1762862058992--


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Charlie Li@vishwin@freebsd.org to muc.lists.freebsd.ports on Tue Nov 11 08:13:10 2025
    From Newsgroup: muc.lists.freebsd.ports

    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------NMFKCzMiPW0ZCBZ9MBCFUscg
    Content-Type: multipart/mixed; boundary="------------ezWvDXRJ1CeD1q9T4sZa2j1M";
    protected-headers="v1"
    Message-ID: <a5f4fafc-a6ef-4dac-846a-24a7907bea31@freebsd.org>
    Date: Tue, 11 Nov 2025 08:13:10 -0500
    MIME-Version: 1.0
    User-Agent: Mozilla Thunderbird
    Subject: Re: Reproducible builds of ports
    To: Kurt Jaeger <pi@freebsd.org>
    Cc: ports@freebsd.org
    References: <E78A7ED3-5B05-4033-988A-A5E53D582B86.ref@yahoo.com>
    <E78A7ED3-5B05-4033-988A-A5E53D582B86@yahoo.com>
    <dab64520-1afc-44e2-b60a-7f2512916e24@gmail.com>
    <5ed4a69d-3c18-4d93-82bc-8a2ae3adc648@gmx.net>
    <e8577bda-ac45-4c67-a9d9-248d899f5e1d@gmail.com>
    <06fee202-efae-47cb-9db2-6fbae8280fcc@freebsd.org>
    <aRMBPwd3_8ooZzQC@fc.opsec.eu>
    Content-Language: en-GB
    From: Charlie Li <vishwin@freebsd.org>
    Autocrypt: addr=vishwin@freebsd.org; keydata=
    xjMEaEicoBYJKwYBBAHaRw8BAQdAZBuydpjFLGem4uRJPWaYMXX2e+BN1jDhbD3tcqbxhdfN
    MkNoYXJsaWUgTGkgKEZyZWVCU0QgUHJvamVjdCkgPHZpc2h3aW5ARnJlZUJTRC5vcmc+wpkE
    ExYKAEEWIQTHxcCLnAXo3rFg6k7P+1cn7slqBAUCaEicoAIbAwUJCWYBgAULCQgHAgIiAgYV
    CgkICwIEFgIDAQIeBwIXgAAKCRDP+1cn7slqBM/bAP9bhA4e0LxJYFYJlftZM5WHrMSPpUe6
    G2pVqmQWTQ0EZQEA0PNryfH3qRWWPSI8mFNRnG24hi5/aXFqCnHj1tcJ9Q/OOARoSJygEgor
    BgEEAZdVAQUBAQdAUT4TzYFmV6ueIGwjX0N+445KZV6ns1Wiw67QMsJZxHkDAQgHwn4EGBYK
    ACYWIQTHxcCLnAXo3rFg6k7P+1cn7slqBAUCaEicoAIbDAUJCWYBgAAKCRDP+1cn7slqBPO/
    AQCPuGiyyfJClICRs/ToG0MsT8YcPdBygzuUIIeGpkjJpgEA7AoFCQ0Y28Y3hIDFn2k9PH3B
    nGWL3g05W0ds2qoj+gQ=
    Organization: FreeBSD Project
    In-Reply-To: <aRMBPwd3_8ooZzQC@fc.opsec.eu>

    --------------ezWvDXRJ1CeD1q9T4sZa2j1M
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    S3VydCBKYWVnZXIgd3JvdGU6DQo+IEhpIQ0KPiANCj4+IGNlbiB3cm90ZToNCj4+PiBUaGUg Z29hbCBpcyBiaXQtZm9yLWJpdCByZXByb2R1Y2liaWxpdHksICJmdW5jdGlvbmFsbHkiIGlz IG5vdCBlbm91Z2guDQo+IA0KPj4gVGhpcyBpcyBjb21wbGV0ZWx5IGltcG9zc2libGUgZm9y IGFueSBvcGVyYXRpbmcgc3lzdGVtIHBhY2thZ2UNCj4+IGRpc3RyaWJ1dGlvbi4gIkZ1bmN0 aW9uYWxseSIgaXMgdGhlIGJlc3QgeW91IGNhbiBnZXQuDQo+IA0KPiBEZWJpYW4gZG9lcyBp dCwgc28gaXQgZG9lcyBub3Qgc2VlbSB0byBiZSBvdXQgb2YgdGhlIHJlYWxtIG9mDQo+IHRo ZSBwb3NzaWJsZS4NCj4gDQpUaGV5IGhhdmUgZWZmb3J0cyB0b3dhcmRzIHRoZSBnb2FsLCBi dXQgaXQgaXMgYSBzdHJldGNoIHRvIHNheSB0aGV5IGhhdmUgDQphY2hpZXZlZCBpdCwgYW5k IHRoZXkgYWRtaXQgaXQgYXMgc3VjaDogDQpodHRwczovL3dpa2kuZGViaWFuLm9yZy9SZXBy b2R1Y2libGVCdWlsZHMNCg0KLS0gDQpDaGFybGllIExpDQouLi5ub3BlLCBzdGlsbCBkb24n dCBoYXZlIGFuIGV4aXQgbGluZS4NCg==

    --------------ezWvDXRJ1CeD1q9T4sZa2j1M--

    --------------NMFKCzMiPW0ZCBZ9MBCFUscg
    Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature
    Content-Disposition: attachment; filename="OpenPGP_signature.asc"

    -----BEGIN PGP SIGNATURE-----

    wnsEABYIACMWIQTHxcCLnAXo3rFg6k7P+1cn7slqBAUCaRM2ZwUDAAAAAAAKCRDP+1cn7slqBC9N AP49W/DJL6jUa5oC2gredUCEDIhdG8jEWseBQcNyv/b6DgEA036Q61N9N8KBGJJYJJ5A0IPfx+K6 HoYSXYPs6c8nfgA=
    =OsR/
    -----END PGP SIGNATURE-----

    --------------NMFKCzMiPW0ZCBZ9MBCFUscg--


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Ronald Klop@ronald-lists@klop.ws to muc.lists.freebsd.ports on Tue Nov 11 14:46:09 2025
    From Newsgroup: muc.lists.freebsd.ports

    ------=_Part_187442_1242871626.1762868769866
    Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable

    Van: Charlie Li <vishwin@freebsd.org>
    Datum: dinsdag, 11 november 2025 14:13
    Aan: Kurt Jaeger <pi@freebsd.org>
    CC: ports@freebsd.org
    Onderwerp: Re: Reproducible builds of ports
    =20
    Kurt Jaeger wrote:
    Hi!

    cen wrote:
    The goal is bit-for-bit reproducibility, "functionally" is not enough=
    .

    This is completely impossible for any operating system package
    distribution. "Functionally" is the best you can get.

    Debian does it, so it does not seem to be out of the realm of
    the possible.

    They have efforts towards the goal, but it is a stretch to say they have =
    achieved it, and they admit it as such: https://wiki.debian.org/Reproducibl= eBuilds
    =20
    --=20
    Charlie Li
    ...nope, still don't have an exit line.
    =20
    =20
    =20
    =20



    At the same time... If you look at the graph at the bottom of that page, th=
    ey came quite far already. =F0=9F=91=8F=F0=9F=91=8F=F0=9F=91=8F

    Regards,
    Ronald.
    =20
    ------=_Part_187442_1242871626.1762868769866
    Content-Type: text/html; charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <html><head></head><body><br>
    <p><strong>Van:</strong> Charlie Li &lt;vishwin@freebsd.org&gt;<br> <strong>Datum:</strong> dinsdag, 11 november 2025 14:13<br> <strong>Aan:</strong> Kurt Jaeger &lt;pi@freebsd.org&gt;<br> <strong>CC:</strong> ports@freebsd.org<br>
    <strong>Onderwerp:</strong> Re: Reproducible builds of ports</p>

    <blockquote style=3D"padding-right: 0px; padding-left: 5px; margin-left: 5p=
    x; border-left: #000000 2px solid; margin-right: 0px">
    <div class=3D"MessageRFC822Viewer" id=3D"P">
    <div class=3D"MultipartMixedViewer">
    <div class=3D"MultipartMixedViewer">
    <div class=3D"TextPlainViewer" id=3D"P.P.P1.P1">Kurt Jaeger wrote:<br>
    &gt; Hi!<br>
    &gt;<br>
    &gt;&gt; cen wrote:<br>
    &gt;&gt;&gt; The goal is bit-for-bit reproducibility, "functionally" is not=
    enough.<br>
    &gt;<br>
    &gt;&gt; This is completely impossible for any operating system package<br> &gt;&gt; distribution. "Functionally" is the best you can get.<br>
    &gt;<br>
    &gt; Debian does it, so it does not seem to be out of the realm of<br>
    &gt; the possible.<br>
    &gt;<br>
    They have efforts towards the goal, but it is a stretch to say they have ac= hieved it, and they admit it as such: <a href=3D"https://wiki.debian.org/Re= producibleBuilds">https://wiki.debian.org/ReproducibleBuilds</a><br>

    --&nbsp;<br>
    Charlie Li<br>
    ...nope, still don't have an exit line.</div>

    <hr></div>

    <div class=3D"DefaultViewer">&nbsp;</div>
    </div>
    </div>
    </blockquote>



    At the same time... If you look at the graph at the bottom of that page, th=
    ey came quite far already. =F0=9F=91=8F=F0=9F=91=8F=F0=9F=91=8F<br>

    Regards,<br>
    Ronald.<br>
    &nbsp;</body></html>
    ------=_Part_187442_1242871626.1762868769866--


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Charlie Li@vishwin@freebsd.org to muc.lists.freebsd.ports on Tue Nov 11 09:34:19 2025
    From Newsgroup: muc.lists.freebsd.ports

    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------VB0tidvxKw0CCKywlEznn0Ao
    Content-Type: multipart/mixed; boundary="------------Jqw0gHKvETM8je070zHwXu4B";
    protected-headers="v1"
    Message-ID: <3217ed83-380f-4fb7-8ef4-9b8429e59b5d@freebsd.org>
    Date: Tue, 11 Nov 2025 09:34:19 -0500
    MIME-Version: 1.0
    User-Agent: Mozilla Thunderbird
    Subject: Re: Reproducible builds of ports
    To: Ronald Klop <ronald-lists@klop.ws>,
    Tatsuki Makino <tatsuki_makino@hotmail.com>
    Cc: ports@freebsd.org, cen <imbacen@gmail.com>
    References: <E78A7ED3-5B05-4033-988A-A5E53D582B86.ref@yahoo.com>
    <E78A7ED3-5B05-4033-988A-A5E53D582B86@yahoo.com>
    <dab64520-1afc-44e2-b60a-7f2512916e24@gmail.com>
    <5ed4a69d-3c18-4d93-82bc-8a2ae3adc648@gmx.net>
    <e8577bda-ac45-4c67-a9d9-248d899f5e1d@gmail.com>
    <06fee202-efae-47cb-9db2-6fbae8280fcc@freebsd.org>
    <SI2PR01MB5036E09B7159CC5C9B9A4927FACFA@SI2PR01MB5036.apcprd01.prod.exchangelabs.com>
    <863665245.146900.1762862059048@localhost>
    Content-Language: en-GB
    From: Charlie Li <vishwin@freebsd.org>
    Autocrypt: addr=vishwin@freebsd.org; keydata=
    xjMEaEicoBYJKwYBBAHaRw8BAQdAZBuydpjFLGem4uRJPWaYMXX2e+BN1jDhbD3tcqbxhdfN
    MkNoYXJsaWUgTGkgKEZyZWVCU0QgUHJvamVjdCkgPHZpc2h3aW5ARnJlZUJTRC5vcmc+wpkE
    ExYKAEEWIQTHxcCLnAXo3rFg6k7P+1cn7slqBAUCaEicoAIbAwUJCWYBgAULCQgHAgIiAgYV
    CgkICwIEFgIDAQIeBwIXgAAKCRDP+1cn7slqBM/bAP9bhA4e0LxJYFYJlftZM5WHrMSPpUe6
    G2pVqmQWTQ0EZQEA0PNryfH3qRWWPSI8mFNRnG24hi5/aXFqCnHj1tcJ9Q/OOARoSJygEgor
    BgEEAZdVAQUBAQdAUT4TzYFmV6ueIGwjX0N+445KZV6ns1Wiw67QMsJZxHkDAQgHwn4EGBYK
    ACYWIQTHxcCLnAXo3rFg6k7P+1cn7slqBAUCaEicoAIbDAUJCWYBgAAKCRDP+1cn7slqBPO/
    AQCPuGiyyfJClICRs/ToG0MsT8YcPdBygzuUIIeGpkjJpgEA7AoFCQ0Y28Y3hIDFn2k9PH3B
    nGWL3g05W0ds2qoj+gQ=
    Organization: FreeBSD Project
    In-Reply-To: <863665245.146900.1762862059048@localhost>

    --------------Jqw0gHKvETM8je070zHwXu4B
    Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

    Um9uYWxkIEtsb3Agd3JvdGU6DQo+IFRoZXJlIGlzIGEgd2Vic2l0ZSBhYm91dCB0aGlzLg0K PiANCj4gaHR0cHM6Ly9yZXByb2R1Y2libGUtYnVpbGRzLm9yZy9kb2NzL3NvdXJjZS1kYXRl LWVwb2NoLw0KPiANCj4gKlZhbjoqIFRhdHN1a2kgTWFraW5vIDx0YXRzdWtpX21ha2lub0Bo b3RtYWlsLmNvbT4NCj4gKkRhdHVtOiogZGluc2RhZywgMTEgbm92ZW1iZXIgMjAyNSAxMDox Nw0KPiAqQWFuOiogQ2hhcmxpZSBMaSA8dmlzaHdpbkBmcmVlYnNkLm9yZz4sIGNlbiA8aW1i YWNlbkBnbWFpbC5jb20+LCANCj4gcG9ydHNAZnJlZWJzZC5vcmcNCj4gKk9uZGVyd2VycDoq IFJlOiBSZXByb2R1Y2libGUgYnVpbGRzIG9mIHBvcnRzDQo+IA0KPiAgICAgQWgsIEkgc2Vl LCBzbyBpdCB3YXMgYSB0b3BpYyBpbiB0aGF0IGRpcmVjdGlvbiA6KQ0KPiANCj4gICAgIEVM RiBmb3JtYXQgaXRzZWxmIGRvZXNuJ3QsIGJ5IGRlZmF1bHQsIGluY2x1ZGUgaW5mb3JtYXRp b24gc3VjaCBhcw0KPiAgICAgdGhlIGNvbXBpbGF0aW9uIHRpbWVzdGFtcCwgbWF5YmUuDQo+ ICAgICBFdmVuIGNvZGUgdGhhdCB1c2VzIHByZXByb2Nlc3NvciBfX0RBVEVfXyBhbmQgX19U SU1FX18gd29uJ3QgYmUNCj4gICAgIHJlcHJvZHVjaWJsZSB1bmxlc3Mgd2Ugc3RvcCB0aGUg Y2xvY2ssIG1heWJlLg0KPiANCj4gICAgIEF0IHRoZSB2ZXJ5IGxlYXN0LCB3ZSBjYW4ndCBt YWtlIHRoZSBwYXJ0cyBpbnZvbHZpbmcgc3VjaCB0aW1lcw0KPiAgICAgbWF0Y2ggcGVyZmVj dGx5LCBjYW4gd2U/IDopDQo+IA0KRm9yIENQeXRob24sIFNPVVJDRV9EQVRFX0VQT0NIIGlz IGJ1dCBhIHNtYWxsIHBpZWNlIG9mIHRoZSBwdXp6bGUuIFRoZSANCmNsYXJpZnlpbmcgYXNr IG9mIHRoaXMgdGhyZWFkIHdhcyBmb3IgImJpdC1mb3ItYml0IHJlcHJvZHVjaWJpbGl0eSIu DQoNClRoZXJlIGlzIHN1cHBvcnQgZm9yIGRldGVybWluaXN0aWMgaGFzaC1iYXNlZCB2YWxp ZGF0aW9uIGluc3RlYWQgb2YgDQp0aW1lc3RhbXAgdmFsaWRhdGlvbiBbMF0gYnV0IGRvZXMg bm90IGFkZHJlc3Mgb3RoZXIgYXNwZWN0cyBvZiB0aGUgDQpDUHl0aG9uIGJ5dGVjb2RlIGZv cm1hdCB0aGF0IG1ha2UgZGlmZmVyZW50IHJ1biBvdXRwdXRzIG5vdCBiaXQtZm9yLWJpdCAN CmlkZW50aWNhbC4gWzFdIFRoZSBiaWdnZXN0IG90aGVyIGlzc3VlIGlzIGhhc2ggcmFuZG9t aXNhdGlvbi4gWzJdDQoNCkhhc2ggcmFuZG9taXNhdGlvbiwgZW5hYmxlZCBieSBkZWZhdWx0 LCBtaXRpZ2F0ZXMgYWdhaW5zdCBjbGFzc2VzIG9mIA0KZGVuaWFsLW9mLXNlcnZpY2UgY29u ZGl0aW9ucy4gWzNdIFN1cmUsIGRpc2FibGluZyB0aGlzIGRlZmF1bHQgYmVoYXZpb3VyIA0K Ynkgc2V0dGluZyBhIHN0YXRpYyBzZWVkIHZhbHVlIGNhbiBtYWtlIHRoZSByZXN1bHRpbmcg Ynl0ZWNvZGUgdG8gYmUgDQpwYWNrYWdlZCBiaXQtZm9yLWJpdCBpZGVudGljYWwuIFRoaXMg aXMgd2hhdCBvdGhlciBzeXN0ZW0gcGFja2FnZSANCmRpc3RyaWJ1dGlvbnMgbGlrZSBvcGVu U1VTRSwgR2VudG9vIGFuZCBBcmNoIGhhdmUgYmVlbiBkb2luZy4gSG93ZXZlciANCnRoaXMg cmVpbnRyb2R1Y2VzIHRoZSBEb1MgY29uZGl0aW9ucyBmb3IgdXNlcnMgb2YgdGhlIHBhY2th Z2VzIG91dHNpZGUgDQpvZiBhIGJ1aWxkIGNvbnRleHQuIE5vdCBnb29kLg0KDQpCYXNlZCBv biBjdXJyZW50IHJlYWxpdGllcywgdGhlIG9ubHkgd2F5IHRvIGdldCBjbG9zZXIgdG8gYml0 LWZvci1iaXQgaXMgDQp0byBub3QgcGFja2FnZSBieXRlY29kZSBhdCBhbGwuIEFsc28gbm90 IGdvb2QsIFswXSBub3QgbGVhc3Qgc2luY2UgdGhlIA0KQ1B5dGhvbiBleGVjdXRpb24gbW9k ZWwgYWx3YXlzIGNvbXBpbGVzIGJ5dGVjb2RlIGF0IHJ1bnRpbWUgaWYgYSANCmNvbXBpbGVk IGNhY2hlIGRvZXMgbm90IGFscmVhZHkgZXhpc3QuDQoNClswXSBodHRwczovL3BlcHMucHl0 aG9uLm9yZy9wZXAtMDU1Mi8NClsxXSBodHRwczovL2dpdGh1Yi5jb20vcHl0aG9uL2NweXRo b24vaXNzdWVzLzczODk0DQpbMl0gaHR0cDovL2Jlbm5vLmlkLmF1L2Jsb2cvMjAxMy8wMS8x NS9weXRob24tZGV0ZXJtaW5pc20gKG1haW4gc2l0ZSANCnNlZW1zIHRvIGJlIGRlYWQsIHVz ZSBJbnRlcm5ldCBBcmNoaXZlIFdheWJhY2sgTWFjaGluZSkNClszXSBodHRwczovL2RvY3Mu cHl0aG9uLm9yZy8zL3VzaW5nL2NtZGxpbmUuaHRtbCNjbWRvcHRpb24tUg0KDQotLSANCkNo YXJsaWUgTGkNCi4uLm5vcGUsIHN0aWxsIGRvbid0IGhhdmUgYW4gZXhpdCBsaW5lLg0K

    --------------Jqw0gHKvETM8je070zHwXu4B--

    --------------VB0tidvxKw0CCKywlEznn0Ao
    Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature
    Content-Disposition: attachment; filename="OpenPGP_signature.asc"

    -----BEGIN PGP SIGNATURE-----

    wnsEABYIACMWIQTHxcCLnAXo3rFg6k7P+1cn7slqBAUCaRNJbAUDAAAAAAAKCRDP+1cn7slqBCAP AQDP18sES1vxCvFOEefRuQ+HaFFT4R4v8+Ip2ex+qk5QsQEAzOfm0Ll3s/Cn+mKaW4WHf7l3wQDu QzFB2dEkLihTfw8=
    =IIwE
    -----END PGP SIGNATURE-----

    --------------VB0tidvxKw0CCKywlEznn0Ao--


    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From cen@imbacen@gmail.com to muc.lists.freebsd.ports on Tue Nov 11 17:04:18 2025
    From Newsgroup: muc.lists.freebsd.ports

    This is completely impossible for any operating system package
    distribution. "Functionally" is the best you can get.

    I just wanted to clarify, perhaps what I wrote wasn't exactly clear in
    regard to what I am trying to achieve.


    My "humble" initial goal is to either:

    1. Rebuild a package locally, compare it to upstream, record whether the result is the same or not, output statistics. I want to do this for a
    subset of ports initially. I am aware about the issues with timestamps,
    worker hostnames etc, these all needs to be addressed in the process.

    2. Alternatively, freeze my local tree to a specific commit, build a
    package twice, see if the result is the same.


    Whether I get a 1% success rate or 90% success rate is besides the point
    for me personally at this stage, I just want to collect the information. Getting the whole ports tree reproducible is probably a decades long
    project if anyone wanted to do it (e.g. Debian efforts).


    I got some encouraging information regarding at least the second
    scenario so I definitely got some good feedback so far.


    Best regards






    --
    Posted automagically by a mail2news gateway at muc.de e.V.
    Please direct questions, flames, donations, etc. to news-admin@muc.de
    --- Synchronet 3.21a-Linux NewsLink 1.2