> > Unfortunately none of the changes I made seemed to solve this..
> > 10.3.22 is still unreproducible in unstable due to RocksDB, TokuDB and
> > Mroonga.
>
> Mmm, alas, I only managed to get this to "almost reproducible" stage
> before my attention was required elsewhere.
>
> However, I quickly n
Hi Otto,
> Unfortunately none of the changes I made seemed to solve this..
> 10.3.22 is still unreproducible in unstable due to RocksDB, TokuDB and
> Mroonga.
Mmm, alas, I only managed to get this to "almost reproducible" stage
before my attention was required elsewhere.
However, I quickly note
Hello Chris and others,
I reported your results at
- https://github.com/mroonga/mroonga/issues/298
- https://github.com/groonga/groonga/issues/1079
I also updated the upstream issue at
- https://github.com/facebook/rocksdb/issues/6276
Unfortunately none of the changes I made seemed to solve this
Hi Otto,
> I hope you don't mind if I re-post your findings in upstreams' bug
> reports. We want to fix reproducibility globally, not just in Debian.
Good thinking. I, obviously, have no problem whatsoever with this. :)
Best wishes,
--
,''`.
: :' : Chris Lamb
`. `'`
Thanks for this!
Incredible that any build would ever store the path of the original source
code. I can think of anything more useless that having /home/otto/ran/dom
permanently in the resulting binary, but apparently some do this.
I hope you don't mind if I re-post your findings in upstreams' bu
Dear Otto,
> Or some docs on how exactly reprotest changes the build paths?
I not a reprotest user myself but this will not be anything less
convoluted than simply choosing a different directory to build from
each time, eg. /home/otto/1st-build vs. /home/otto/2nd-build.
> Do you have any pointer
Hello!
ti 21. tammik. 2020 klo 2.06 Chris Lamb kirjoitti:
> > As a side note, the search engine groonga itself is also currently
> > unreproducible in a similar way (build-id changes, root cause
> > unclear):
>
> Heh, so sometimes I get the impression that some maintainers see the
> build-id diff
Hi Otto,
> > > For Mroonga I nor the upstream developers have no clue yet of the
> > > root cause
Thanks for your comments. I'm replying quickly on two points as I may
not get a chance to get back to your mail in full until Wednesday.
> As a side note, the search engine groonga itself is also cu
> > For Mroonga I nor the upstream developers have no clue yet of the
> > root cause
>
> Do you happen to have instructions to just build this part of MariaDB?
> Would love to be able help you out but building the entire server on
> my laptop again and again might not be the most efficient use of
>
here, please download them today, as they will then be deleted:
https://tests.reproducible-builds.org/debian/artifacts/r00t-me/mariadb-10.3_bullseye_amd64_tmp-bRl4s/
On Mon, Jan 20, 2020 at 12:40 PM Mattia Rizzolo wrote:
> On Sun, Jan 19, 2020 at 11:57:05PM -, Chris Lamb wrote:
> > (Or, as a
On Sun, Jan 19, 2020 at 11:57:05PM -, Chris Lamb wrote:
> (Or, as a different place to start, Mattia might be able to remind me
> how to instruct the build rescheduler to retain the build artifacts?
> I can't seem to remember how...)
it's an
&keep-artifacts
in the querystring of the schedu
[assuming you aren't subscribed, let me know if you'd like me to drop you from
CC]
Hi Otto,
> For Mroonga I nor the upstream developers have no clue yet of the
> root cause
Do you happen to have instructions to just build this part of MariaDB?
Would love to be able help you out but building the
Hello!
The MariaDB server itself and most of it's additional components are
already reproducible and we are very close to the whole source package
build reproducibly.
For the last remaining issues I now need to request help.
Latest results from
https://tests.reproducible-builds.org/debian/rb-pkg
13 matches
Mail list logo
