bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
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://AvatarAcademy.com
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
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, which we've been using for many > years, since the early days of Guix. Yes, I understand the last bit. However, it is only now with my failure to remove them that we found something possiblby fishy? IWBN if we knew that the hashes are reproducible before we remove them. Hmm, that might be a good argument to have two packages, a merely static/content stripped version and a hashes-stripped version. > I'd like to build the new bootstrap binaries, but I'm unsure how to > proceed. In your new batch of commits, you reference the commit that > was used to perform the build: > I guess that I should build from a checkout of commit > 2e13b6fff94027158b3de5d3a1469dc9f89b0c39. However, that commit is not > on Savannah, as demonstrated by the following URL, which reports "Bad > commit reference: 2e13b6fff94027158b3de5d3a1469dc9f89b0c39". > > > https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2e13b6fff94027158b3de5d3a1469dc9f89b0c39 Right, that commit is two commits up or my core-updates branch @ gitlab https://gitlab.com/janneke/guix @ core-updates it's core-updates plus the two first patches I sent. I could push a wip-core-updates branch (but I'll first try the master thing, see below). > The other issue is that your proposed new fixes do not seem to apply to > 'master'. Did you build the newly fixed bootstrap tarballs from > something based on 'core-updates'? If so, that leaves me no way to > independently verify the new bootstrap without putting my trust in the > slightly older bootstrap -- the same one that I just failed to > reproduce. Ah, hadn't thought about that... > What I need is a way to build the new bootstrap tarballs without using > the existing 'core-updates' branch. I need a way to build them from a > branch that's based upon the much older bootstrap binaries that we've > been using for many years. Preferably, they should be built from > something close to current 'master'. > > Is this feasible? Hmm, I'm not sure how much work it would be. If we're lucky then the recipes from gnu/packages/bootstrap.scm for mescc-tools-static-stripped and mes-minimal-stripped and their tarballs could be put into and used on master to build. I'll have a look into this. If we could find how you can reproduce the current flawed hash-containing bootstrap binaries that we have on core-updates, that would be nice...I'm hoping for Ludo' to step in and say something insightful about the differences you found :) janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
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 best way? > > Making a reference invalid helps making sure that it isn't used. But if > it cannot be used anyway, removing it could hide the fact that it may > differs accros builds, as we are finding out right now. Thoughts? 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, which we've been using for many years, since the early days of Guix. I'd like to build the new bootstrap binaries, but I'm unsure how to proceed. In your new batch of commits, you reference the commit that was used to perform the build: > From 172ee1045689cd42d2de837ee560d32c43730cc3 Mon Sep 17 00:00:00 2001 > From: Jan Nieuwenhuizen > Date: Sun, 21 Jul 2019 14:38:52 +0200 > Subject: [PATCH 3/4] bootstrap: bootstrap-mescc-tools: Update. > > Built with > 2e13b6fff94027158b3de5d3a1469dc9f89b0c39 bootstrap: > mes-minimal-stripped: Remove store references. > > * gnu/packages/bootstrap.scm (%bootstrap-mescc-tools): Update. I guess that I should build from a checkout of commit 2e13b6fff94027158b3de5d3a1469dc9f89b0c39. However, that commit is not on Savannah, as demonstrated by the following URL, which reports "Bad commit reference: 2e13b6fff94027158b3de5d3a1469dc9f89b0c39". https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2e13b6fff94027158b3de5d3a1469dc9f89b0c39 The other issue is that your proposed new fixes do not seem to apply to 'master'. Did you build the newly fixed bootstrap tarballs from something based on 'core-updates'? If so, that leaves me no way to independently verify the new bootstrap without putting my trust in the slightly older bootstrap -- the same one that I just failed to reproduce. What I need is a way to build the new bootstrap tarballs without using the existing 'core-updates' branch. I need a way to build them from a branch that's based upon the much older bootstrap binaries that we've been using for many years. Preferably, they should be built from something close to current 'master'. Is this feasible? Thanks, Mark
bug#36754: New linux-libre failed to build on armhf on Berlin
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.savannah.gnu.org/cgit/guix.git/commit/?id=1ad9c105c208caa9059924cbfbe4759c8101f6c9 The following queries show that the updated packages built successfully on x86_64, i686, and aarch64, but they all failed on armhf: https://ci.guix.gnu.org/search?query=linux-libre-5.2.2 https://ci.guix.gnu.org/search?query=linux-libre-4.19.60 https://ci.guix.gnu.org/search?query=linux-libre-4.14.134 https://ci.guix.gnu.org/search?query=linux-libre-4.9.186 https://ci.guix.gnu.org/search?query=linux-libre-4.4.186 https://ci.guix.gnu.org/search?query=linux-libre-arm-veyron-5.2.2 https://ci.guix.gnu.org/search?query=linux-libre-arm-generic-5.2.2 https://ci.guix.gnu.org/search?query=linux-libre-arm-generic-4.19.60 https://ci.guix.gnu.org/search?query=linux-libre-arm-generic-4.14.134 https://ci.guix.gnu.org/search?query=linux-libre-arm-omap2plus-5.2.2 https://ci.guix.gnu.org/search?query=linux-libre-arm-omap2plus-4.19.60 https://ci.guix.gnu.org/search?query=linux-libre-arm-omap2plus-4.14.134 Unfortunately, I'm unable to get *any* information about what went wrong from Cuirass. None of the failed builds have associated log files, and the build details page has no useful information either. For example: https://ci.guix.gnu.org/build/1488517/details My first guess was that something went wrong in the 'computed' origin that runs the deblobbing script. However, that's apparently not the case, because all of the updated 'linux-libre-headers' packages built successfully on armhf, and those use the same source tarballs as the main 'linux-libre' packages. https://ci.guix.gnu.org/search?query=linux-libre-headers-5.2.2 https://ci.guix.gnu.org/search?query=linux-libre-headers-4.19.60 https://ci.guix.gnu.org/search?query=linux-libre-headers-4.14.134 Can someone help me find out what's going on here? Until then, I'm sorry to say that armhf-linux users will be unable to update their systems. Mark
bug#36728: LibreOffice fails to open hyperlinks
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 normally push this > directly to master because no packages depend on libreoffice, but the > long build time gave me pause. > > Should I commit this change to master or to somewhere else? I've committed this to the master branch as afb986e77cd669c2f21953f501f7893237730ca7. Closing. -- Chris signature.asc Description: PGP signature
bug#36706: "guix gc --verify" fails with "FOREIGN KEY constraint failed"
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 with a quick&dirty: > > $ sqlite3 /var/guix/db.sqlite > delete from Refs where reference in (select id from ValidPaths where path > glob "*libreof*"); > delete from Refs where referrer in (select id from ValidPaths where path > glob "*libreof*"); > delete from DerivationOutputs where path glob "*libreof*"; > delete from ValidPaths where path glob "*libreof*"; > > Which I assume is what `guix gc --verify=repair` was trying to do, but it's > not cleaning up Refs table and thus failing at the FOREIGN KEY constraint. > > $ sqlite3 /var/guix/db/db.sqlite > [...] > sqlite> .schema > [...] > CREATE TABLE Refs ( > referrer integer not null, > reference integer not null, > primary key (referrer, reference), > foreign key (referrer) references ValidPaths(id) on delete cascade, > foreign key (reference) references ValidPaths(id) on delete restrict > < this one here > ); That might work, or it might not. Since manual manipulation of the store and the database is not supported, and your Guix installation might now be in an unknown, invalid state. At the very least, you should probably run "guix gc --verify=contents,repair". The safest (but admittedly heavy-handed) thing to do is to reinstall Guix completely. The guix-daemon is carefully designed to maintain several critical invariants regarding the state of the store and its database. If by manually modifying the store or the database you have accidentally invalidated one of those invariants (or if you have made a change that is not detected now but which later on might invalidate one of those invariants), there is no guarantee you can easily recover. -- Chris signature.asc Description: PGP signature
bug#36667: crates-io.scm packages should build on master
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 attached patch sets the CARGO_HOME environment variable to "." > much earlier than it previously was, just after the configure > phase. With the attached patch all packages in crates-io.scm build > without errors. > > I hope I did everything right, Unfortunately, your patch does not apply cleanly to the current tip of the master branch (d1e766e5c6b9e25ff0fa8e0a2adf3e764401a3a2). Could you please tell me what commit or branch it applies against, or send a new patch that applies cleanly to the current tip of the master branch? Thank you, -- Chris signature.asc Description: PGP signature
bug#36363: let's encrypt hash mismatch
Ludovic Courtès writes: > Julien Lepiller skribis: > >> expected hash: 0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y >> actual hash: 0zycy85ff9ga53z1q03df89ka9iihb9p8bjhw056rq2y4rn3b6ac >> hash mismatch for store item >> '/gnu/store/1drx7dy1zakc0xs60nb0im1jbvxp11dj-isrgrootx1.pem' build > > I believe you’d be fine if substitutes were enabled, but they’re not. > > In the meantime, you can fetch those files with something like: > > wget -O /tmp/isrgrootx1.pem \ > > http://berlin.guix.gnu.org/file/isrgrootx1.pem/sha256/0zhd1ps7sz4w1x52xk3v7ng6d0rcyi7y7rcrplwkmilnq5hzjv1y > guix download file:///tmp/isrgrootx1.pem > > But yeah, like Tobias writes, it’s a bit of a problem. Should we mirror > them somewhere? Does Let’s Encrypt have them under a versioned URL > elsewhere? What is Guix using these files for? I realize it's got something to do with TLS, but it isn't clear to me why Guix downloads these certs. I don't have the full context, so please forgive me if my comments are unhelpful, but before deciding to use stale versions, I think it's worth asking, "Could using a stale version introduce any security risk?" Maybe there's a reason why LE doesn't publish the old versions. -- Chris signature.asc Description: PGP signature
bug#36634: Virtual Machine Manager (virt-manager)
> 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 problematic 5.5.0 release, and the working 5.4.0 release. So, by reverting changes, do you mean you patched and made a new commit? Thank you! Regards, RG.
bug#36634: Virtual Machine Manager (virt-manager)
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 changes in [1], and that seems to solve the issue. Unfortunately, I don't have any insight in to what's different between the problematic 5.5.0 release, and the working 5.4.0 release. 1: 458fe419232844d2021608d20dcd8f6e095eb2b4 https://git.savannah.gnu.org/cgit/guix.git/commit/?id=458fe419232844d2021608d20dcd8f6e095eb2b4 signature.asc Description: PGP signature
bug#36685: ant-bootstrap fails on core-updates (409 dependents)
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 2.28 or gcc-5)? > > What do you think? > I will have a look at reducing the patch later today. I will report back tomorrow morning with the results. > > -- > Ricardo >
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
#:phases (modify-phases %standard-phases
+ (delete 'configure)
+ (add-after 'install 'strip-store-references
+(lambda _
+ (let* ((out (assoc-ref %outputs "out"))
+ (bin (string-append out "/bin")))
+(for-each (lambda (file)
+ (let ((target (string-append bin "/" file)))
+ (format #t "strippingg `~a'...~%" target)
+ (remove-store-references target)))
+ '( "M1" "blood-elf" "hex2"))
(define-public %mes-minimal-stripped
;; A minimal Mes without documentation dependencies, for bootstrap.
@@ -791,7 +802,7 @@ for `sh' in $PATH, and without nscd, and with static NSS modules."
(define %mescc-tools-bootstrap-tarball
;; A tarball with MesCC binary seed.
- (tarball-package %mescc-tools-static))
+ (tarball-package %mescc-tools-static-stripped))
(define %mes-bootstrap-tarball
;; A tarball with Mes ASCII Seed and binary Mes C Library.
--
2.21.0
>From 2e13b6fff94027158b3de5d3a1469dc9f89b0c39 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen
Date: Sun, 21 Jul 2019 14:27:07 +0200
Subject: [PATCH 2/4] bootstrap: mes-minimal-stripped: Remove store references.
* gnu/packages/make-bootstrap.scm (%mes-minimal-stripped): Remove store
references.
---
gnu/packages/make-bootstrap.scm | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/gnu/packages/make-bootstrap.scm b/gnu/packages/make-bootstrap.scm
index 8cc4eef430..af89ca8c3c 100644
--- a/gnu/packages/make-bootstrap.scm
+++ b/gnu/packages/make-bootstrap.scm
@@ -621,6 +621,7 @@ for `sh' in $PATH, and without nscd, and with static NSS modules."
#:configure-flags '("--mes")
#:phases
(modify-phases %standard-phases
+ (delete 'patch-shebangs)
(add-after 'install 'strip-install
(lambda _
(let* ((out (assoc-ref %outputs "out"))
@@ -628,10 +629,16 @@ for `sh' in $PATH, and without nscd, and with static NSS modules."
(delete-file-recursively (string-append out "/lib/guile"))
(delete-file-recursively (string-append share "/guile"))
(delete-file-recursively (string-append share "/mes/scaffold"))
- (for-each
- delete-file
- (find-files (string-append share "/mes/lib")
- "\\.(h|c)")))
+
+ (for-each delete-file
+ (find-files
+(string-append share "/mes/lib") "\\.(h|c)"))
+
+ (for-each (lambda (dir)
+ (for-each remove-store-references
+ (find-files (string-append out "/" dir)
+ ".*")))
+ '("bin" "share/mes")))
(define %guile-static
;; A statically-linked Guile that is relocatable--i.e., it can search
--
2.21.0
>From 172ee1045689cd42d2de837ee560d32c43730cc3 Mon Sep 17 00:00:00 2001
From: Jan Nieuwenhuizen
Date: Sun, 21 Jul 2019 14:38:52 +0200
Subject: [PATCH 3/4] bootstrap: bootstrap-mescc-tools: Update.
Built with
2e13b6fff94027158b3de5d3a1469dc9f89b0c39 bootstrap: mes-minimal-stripped: Remove store references.
* gnu/packages/bootstrap.scm (%bootstrap-mescc-tools): Update.
---
gnu/packages/bootstrap.scm | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gnu/packages/bootstrap.scm b/gnu/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")
+(version "1")
(source #f)
(build-system trivial-build-system)
(arguments
@@ -735,12 +735,12 @@ exec ~a/bin/.gcc-wrapped -B~a/lib \
(method url-fetch)
(uri (map
(cute string-append <>
-"/i686-linux/20181020/"
-"mescc-tools-static-0.5.2-0.bb062b0-i686-linux.tar.xz")
+"/i686-linux/20190721/"
+"mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz")
%bootstrap-base-urls))
(sha256
(base32
- "11lniw0vg61kmyhvnwkmcnkci9ym6
bug#36685: ant-bootstrap fails on core-updates (409 dependents)
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/packages/java.scm
index 403c446a82..60363d60c3 100644
--- a/gnu/packages/java.scm
+++ b/gnu/packages/java.scm
@@ -116,6 +116,9 @@
(base32
"1qqldrp74pzpy5ly421srqn30qppmm9cvjiqdngk8hf47dv2rc0c"
(build-system gnu-build-system)
+(native-inputs
+ `(("libc" ,glibc-2.28)
+ ("gcc" ,gcc-5)))
(home-page "http://jikes.sourceforge.net/";)
(synopsis "Compiler for the Java language")
(description "Jikes is a compiler that translates Java source files as
@@ -152,12 +155,20 @@ and binary format defined in The Java Virtual Machine Specification.")
"--disable-gjdoc")
#:phases
(modify-phases %standard-phases
+ (add-after 'unpack 'foo
+ (lambda _
+ (substitute* "native/jni/java-io/java_io_VMFile.c"
+ (("result = cpio_isFileExists.*" m)
+(string-append m "\n//")))
+ #t))
(add-after 'install 'install-data
(lambda _ (invoke "make" "install-data"))
(native-inputs
`(("jikes" ,jikes)
("fastjar" ,fastjar)
("libltdl" ,libltdl)
+ ("gcc" ,gcc-5)
+ ("libc" ,glibc-2.28)
("pkg-config" ,pkg-config)))
(home-page "https://www.gnu.org/software/classpath/";)
(synopsis "Essential libraries for Java")
@@ -191,6 +202,9 @@ language.")
`(("classpath" ,classpath-bootstrap)
("jikes" ,jikes)
("zlib" ,zlib)))
+(native-inputs
+ `(("libc" ,glibc-2.28)
+ ("gcc" ,gcc-5)))
(home-page "http://jamvm.sourceforge.net/";)
(synopsis "Small Java Virtual Machine")
(description "JamVM is a Java Virtual Machine conforming to the JVM
@@ -302,7 +316,9 @@ JNI.")
`(("jikes" ,jikes)
("jamvm" ,jamvm-1-bootstrap)
("unzip" ,unzip)
- ("zip" ,zip)))
+ ("zip" ,zip)
+ ("gcc" ,gcc-5)
+ ("libc" ,glibc-2.28)))
(home-page "http://ant.apache.org";)
(synopsis "Build tool for Java")
(description
@@ -627,7 +643,9 @@ machine.")))
("fastjar" ,fastjar)
("jamvm" ,jamvm-1-bootstrap)
("libltdl" ,libltdl)
- ("pkg-config" ,pkg-config))
+ ("pkg-config" ,pkg-config)
+ ("gcc" ,gcc-5)
+ ("libc" ,glibc-2.28))
(define jamvm
(package (inherit jamvm-1-bootstrap)
@@ -656,7 +674,9 @@ machine.")))
`(("guile" ,guile-2.2)
("ecj-bootstrap" ,ecj-bootstrap)
("jamvm" ,jamvm)
- ("classpath" ,classpath-devel)
+ ("classpath" ,classpath-devel)
+ ("gcc" ,gcc-5)
+ ("libc" ,glibc-2.28)
;; The bootstrap JDK consisting of jamvm, classpath-devel,
;; ecj-javac-wrapper-final cannot build Icedtea 2.x directly, because it's
@@ -740,6 +760,9 @@ machine.")))
(with-directory-excursion "openjdk"
(invoke "tar" "xvf" (assoc-ref inputs "hotspot-src"))
(rename-file "hg-checkout" "hotspot"))
+ (substitute* "patches/freetypeversion.patch"
+ (("REQUIRED_FREETYPE_VERSION = 2.2.1")
+"REQUIRED_FREETYPE_VERSION = 2.10.1"))
(substitute* "Makefile.in"
(("echo \"ERROR: No up-to-date OpenJDK zip available\"; exit -1;")
"echo \"trust me\";")
@@ -907,7 +930,8 @@ machine.")))
("fastjar" ,fastjar)
("fontconfig" ,fontconfig)
("freetype" ,freetype)
- ("gcc" ,gcc-4.9) ; there's a segmentation fault when compiling with gcc-5 or gcc-7
+ ("gcc" ,gcc-5)
+ ("libc" ,glibc-2.28)
("gtk" ,gtk+-2)
("gawk" ,gawk)
("giflib" ,giflib)
@@ -1107,6 +1131,18 @@ bootstrapping purposes.")
((name . _) name))
inputs
#t)))
+ (add-after 'unpack 'patch-bitrot
+ (lambda _
+ (substitute* '("patches/boot/revert-6973616.patch"
+ "openjdk.src/jdk/make/common/shared/Defs-versions.gmk")
+ (("REQUIRED_FREETYPE_VERSION = 2.2.1")
+ "REQUIRED_FREETYPE_VERSION = 2.10.1"))
+ ;; As of attr 2.4.48 this header is no longer
+ ;; included. It is provided by the libc instead.
+ (substitute* '("configure"
+ "openjdk.src/jdk/src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c")
+ (("attr/xattr.h") "sys/xattr.h"))
+ #t))
(add-after 'unpack 'fix-x11-extension-include-path
(lambda* (#:key inputs #:allow-other-keys)
(substitute* "openjdk.src/jdk/make/sun/awt/mawt.gmk"
@
