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
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
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
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:
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
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
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
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,
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
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
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 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
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
> >> > > 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
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
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 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
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,
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
22 matches
Mail list logo