Hi Janneke,
Thanks very much for the quick response to this issue.
Jan Nieuwenhuizen wrote:
> In any case, if store references are present in bootstrap binaries, then
> they should be reproducible. Removing store references is one way to
> make them reproducible but I'm not sure if that's the
In commit 1ad9c105c208caa9059924cbfbe4759c8101f6c9, I changed our
linux-libre packages to deblob the linux-libre source tarballs
ourselves, i.e. to run the deblobbing scripts provided by the
linux-libre project to produce linux-libre source tarballs from the
upstream linux tarballs:
Chris Marusich writes:
> Chris Marusich writes:
>
>> I have a fix and will post it in a moment.
>
> I've verified that the attached patch fixes the issue. It took over 4
> hours to build libreoffice on 1 core on my x200 laptop (not including
> the time it took to build dependencies). I would
Ingo Ruhnke writes:
> On Wed, Jul 17, 2019 at 10:02 PM Ricardo Wurmus wrote:
>
>> This is bad and you cannot recover from it. The store should *never* be
>> edited manually as it will become inconsistent with the database (which
>> I assume you have not edited).
>>
>
> I recovered it just fine
Hi Giacomo,
Thank you for taking the time to submit a patch!
goodoldp...@autistici.org writes:
> Rust libraries contained in gnu/packages/crates-io.scm are not
> building anymore because cargo wants to download crate dependencies
> inside the store.
Curious! I wonder when this changed.
> The
Ludovic Courtès writes:
> Julien Lepiller skribis:
>
>> expected hash: 0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y
>> actual hash: 0zycy85ff9ga53z1q03df89ka9iihb9p8bjhw056rq2y4rn3b6ac
>> hash mismatch for store item
>> '/gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem'
> So, I've experienced this too. Even though this is a cgroup thing,
> I'm
> pretty sure this isn't an issue with Linux.
I see.
> I've tried reverting the changes in [1], and that seems to solve the
> issue. Unfortunately, I don't have any insight in to what's different
> between the
Raghav Gururajan writes:
> libvirt.libvirtError: Unable to read from
> '/sys/fs/cgroup/unified/machine/cgroup.controllers': No such file or
> directory
So, I've experienced this too. Even though this is a cgroup thing, I'm
pretty sure this isn't an issue with Linux.
I've tried reverting the
Hello,
Ricardo Wurmus ezt írta (időpont: 2019. júl. 21., Vas
13:29):
> So, with the following change I was able to build all the way up to the
> latest openjdk. Should we use it despite the introduction of a memory
> leak in a bootstrap JVM? Can we make the patch smaller (fewer uses of
>
%MESCC-TOOLS-BOOTSTRAP-TARBALL.
(package
(name "bootstrap-mescc-tools")
-(version "0.5.2")
+(version "1")
(source #f)
(build-system trivial-build-system)
(arguments
@@ -735,12 +735,12 @@ exec ~a/bin/.gcc-wrapped
So, with the following change I was able to build all the way up to the
latest openjdk. Should we use it despite the introduction of a memory
leak in a bootstrap JVM? Can we make the patch smaller (fewer uses of
glibc 2.28 or gcc-5)?
What do you think?
diff --git a/gnu/packages/java.scm
11 matches
Mail list logo
