Hi folks,
This message isn't _directly_ related to reproducible builds, but it
does relate to unexpected differences in text (including, potentially,
source code) checked out from git repositories, and I think that that
could be relevant to the audience here.
Some of the code within the Sphinx
Hi John,
On Fri, 29 Mar 2024 at 19:29, John Gilmore wrote:
>
> kpcyrd wrote:
> > 1) There's currently no way to tell if a package can be built offline
> > (without trying yourself).
>
> Packages that can't be built offline are not reproducible, by
> definition. They depend on outside events
Thanks, Chris,
On Sun, 31 Mar 2024 at 13:01, Chris Lamb wrote:
>
> Hi James,
>
> > Approximately thirty are still set to other severity levels, and I plan to
> > update those with the following adjusted messaging […]
>
> Looks good to me. :)
>
> Completely out of interest, are any of those 30
Hi again,
On Mon, 11 Mar 2024 at 18:24, James Addison wrote:
>
> Hi folks,
>
> On Wed, 6 Mar 2024 at 01:04, James Addison wrote:
> > [ ... snip ...]
> >
> > The Debian bug severity descriptions[1] provide some more nuance, and that
> > reassures me that wishlist should be appropriate for most
Hi folks,
On Wed, 6 Mar 2024 at 01:04, James Addison wrote:
> [ ... snip ...]
>
> The Debian bug severity descriptions[1] provide some more nuance, and that
> reassures me that wishlist should be appropriate for most of these bugs
> (although I'll inspect their contents before making any
> >> > > makes sense, given buildd.debian.org now normalizes them.
> >
> > James Addison via rb-general
> > wrote:
> >> Ok, thank you both. A number of these bugs are currently recorded at
> >> severity
> >> level 'normal'; unless told n
On Wed, 28 Feb 2024 at 12:06, Chris Lamb wrote:
>
> Vagrant Cascadian wrote:
>
> > There are real-world build path issues, and while it is possible to work
> > around them in various ways, I think they are still issues worth fixing
> > to make it easier to debug other issues, although
Hi Chris, Vagrant,
On Tue, 27 Feb 2024 at 17:44, Vagrant Cascadian
wrote:
>
> On 2024-02-27, Chris Lamb wrote:
> >> * Update reprotest to handle a single-disabled-varations-value as a
> >> special case - treating it as vary and/or emitting a warning.
>
> Well, I would broaden this to include
Hello,
A few hundred packages that use reprotest in Salsa-CI appear to be
misconfigured; the remainder of this message explains the problem, and
asks for help figuring out what to do.
Context
---
The reprotest[1] utility tests reproducibility of .deb package builds
by performing two
Hi folks,
A quick recap: in July 2023, Debian's package build infrastructure
(buildd) intentionally began using a fixed directory path during
package builds (bug #1034424). Previously, some string randomness
existed within each source build directory path.
I've two questions related to
Hi David,
Thanks for sharing this.
I think that the problem with this idea and name are:
- That it does not allow two or more people to share and confirm that
they have the same build of some software.
- That it does not allow tests to fail-early, catching and preventing
reproducibility
On Wed, 26 Apr 2023 at 18:48, Vagrant Cascadian
wrote:
>
> On 2023-04-26, James Addison wrote:
> > On Tue, 18 Apr 2023 at 18:51, Vagrant Cascadian
> > wrote:
> >> > James Addison wrote:
> >> This is why in the reproducible builds documentation on timestamps,
> >> there is a paragraph
On Sun, 16 Apr 2023 at 00:25, John Gilmore wrote:
>
> James Addison via rb-general wrote:
> > In general, we should be able to
> > pick two times, "s" and "t", s <= t, where "s" is the
> > source-package-retri
On Fri, 14 Apr 2023 at 19:51, Holger Levsen wrote:
>
> Dear James,
>
> many thanks also from me for your work on this and sharing your findings here.
>
> I'm another happy sphinx user affected by those problems. :)
Thanks, Holger - I think I made a bit of a (verbose) mess of this
particular
A follow-up: after doing more work to try to confirm the behaviour of
the fix -- something I should have done before even starting
development! -- I was confused that I couldn't replicate the original
problem when using a version of the codebase _before_ my proposed fix
pr#10949 was applied.
I
Hi folks,
A set of reproducible-build-related changes[1] that I've developed for
sphinx (a documentation project generator) have been accepted for
inclusion in v6.2.0 of sphinx.
I'm optimistic that those changes can address a sizable category[2] of
reproducible build failures related to
On Thu, Feb 16, 2023 at 6:17 PM Chris Lamb
wrote:
> Thanks. Please feel free to quote my previous email, as well as link
> to my WIP patch.
> Let us know when you have an issue number/URL.
D'oh - unfortunately I only read these after filing the issue, thanks
though. It is reported at:
Hey Chris,
On Wed, Feb 15, 2023 at 7:27 PM Chris Lamb
wrote:
> This change to Sphinx makes alembic reproducible:
>
>
> https://github.com/lamby/sphinx/commit/4ad7670c1df00f82e758aaa8a7b9aaea83b8eaba
>
> Does this patch work for you?
>
Yes! Thank you - that's a much better patch than an
Hi folks,
I noticed what _seemed_ like a quick reproducible-build fix for alembic (a
database migration framework written in Python). A few hours later though,
I'm still puzzled.
The problem appears in a similar pattern across various architectures in
the diffoscope results for alembic -- both
Ah, typical: while trying to figure out where functionality like this
could fit into Debian, I learned that it already exists there.
The 'dpkg-depcheck' and 'dpkg-genbuilddeps' utilities (both included
in the 'devscripts' package) provide this kind of functionality in
Debian.
On Wed, 14 Dec 2022
On Tue, 13 Dec 2022 at 18:15, Vagrant Cascadian
wrote:
>
> It would be interesting to do something more systematic like your
> suggestion, though I'm not aware of anything at the moment.
Thanks Vagrant, that's good to know (it matches my understanding too,
from searching around).
Roughly
Hi folks,
As Debian's buildinfo[1] wiki page hints, it's difficult to determine
whether a build dependency is genuinely required at build-time,
compared to: it was required in the past, but has become dependency
cruft.
I was wondering: are there reproducible-builds efforts underway (in
Debian or
22 matches
Mail list logo
