Jan Nieuwenhuizen writes:
> Hmm, I'm not sure how much work it would be. If we're lucky then the
> recipes from gnu/packages/bootstrap.scm
*gnu/packages/make-bootstrap.scm
--
Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcade
Mark H Weaver writes:
Hi Mark,
> I agree that store references should be removed, i.e. the hash component
> of the store file names should be replaced with all ee's. Note that
> 'e' is never found in a valid Nix base32 hash string. This is what was
> done in our older bootstrap binaries, wh
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 b
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:
https://git
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 n
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' b
> 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 problemati
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 ch
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
> glibc
nu/packages/bootstrap.scm
index 8dbe52435e..a8a5c93e01 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@@ -703,7 +703,7 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
;; %MESCC-TOOLS-BOOTSTRAP-TARBALL.
(package
(name "bootstrap-mescc-tools")
-(version "0.5.2&q
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 b/gnu/p
13 matches
Mail list logo
