jfs, jfsutils?

jfs, jfsutils?

[Michael Zucchi]

Morning,

I just built a new computer and thought i'd give guix a go but after 
finally getting everything working to the install stage ... I hit a 
personal showstopper - no jfs support whatsoever.  It's mostly an 
afterthought on every other distribution but this was a surprise.

Any reason for this or is it just that nobody thought of it?

Anyway, I just ended up installing slackware-current and have then 
installed guix atop that, to grab a few packages and to get more 
familiar with it.  I would probably have had to do that anyway as it was 
probably too much to learn at once but I currently have a lot of spare 
time to fill, so tried guix first.

Regards,
  Z

Re: jfs, jfsutils?

[Josh]

Could you catch me up on what "jfs" is?

On 12/11/19 5:31 PM, Michael Zucchi wrote:
>
> Morning,
>
> I just built a new computer and thought i'd give guix a go but after 
> finally getting everything working to the install stage ... I hit a 
> personal showstopper - no jfs support whatsoever.  It's mostly an 
> afterthought on every other distribution but this was a surprise.
>
> Any reason for this or is it just that nobody thought of it?
>
> Anyway, I just ended up installing slackware-current and have then 
> installed guix atop that, to grab a few packages and to get more 
> familiar with it.  I would probably have had to do that anyway as it 
> was probably too much to learn at once but I currently have a lot of 
> spare time to fill, so tried guix first.
>
> Regards,
>  Z
>

Re: jfs, jfsutils?

[Michael Zucchi]

It's an acronym of Journaled File System.  It was written by IBM and has 
been in Linux since 2002.

On 12/12/19 9:08 am, Josh wrote:
> Could you catch me up on what "jfs" is?
>
> On 12/11/19 5:31 PM, Michael Zucchi wrote:
>>
>> Morning,
>>
>> I just built a new computer and thought i'd give guix a go but after 
>> finally getting everything working to the install stage ... I hit a 
>> personal showstopper - no jfs support whatsoever. It's mostly an 
>> afterthought on every other distribution but this was a surprise.
>>
>> Any reason for this or is it just that nobody thought of it?
>>
>> Anyway, I just ended up installing slackware-current and have then 
>> installed guix atop that, to grab a few packages and to get more 
>> familiar with it.  I would probably have had to do that anyway as it 
>> was probably too much to learn at once but I currently have a lot of 
>> spare time to fill, so tried guix first.
>>
>> Regards,
>>  Z
>>
>
>

Re: jfs, jfsutils?

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

Michael,

Michael Zucchi 写道：
> I just built a new computer and thought i'd give guix a go

That's great to hear!  Welcome.

> but after
> finally getting everything working to the install stage ... I 
> hit a
> personal showstopper - no jfs support whatsoever.  It's mostly 
> an
> afterthought on every other distribution but this was a 
> surprise.
>
> Any reason for this or is it just that nobody thought of it?

s/thought/uses/

Nobody's going to add support for a file system they don't use, 
and nobody boots Guix from JFS.

…yet. :-)

> Anyway, I just ended up installing slackware-current and have 
> then
> installed guix atop that, to grab a few packages and to get more
> familiar with it.  I would probably have had to do that anyway 
> as it
> was probably too much to learn at once but I currently have a 
> lot of
> spare time to fill, so tried guix first.

Spare time sucks, consider contributing JFS support to Guix 
instead.

Assuming it's a pretty conventional Linux file system:

- Guix's Linux-Libre kernel already builds the module 
  (CONFIG_JFS_FS=m)
- it just needs to be added to the initramfs when booting from JFS
- jfsutils needs to be packaged for Guix and a static fsck added 
  to the initramfs
- some code must be added to (gnu build file-systems) to read JFS 
  labels & UUIDs: Guix does not use C tools to do this like other 
  distributions.

If you're completely new to Guix that might sound daunting, but 
it's honestly not that hard and you should get plenty of help on 
the mailing list and/or on IRC.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: jfs, jfsutils?

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

Michael & me,

Tobias Geerinckx-Rice 写道：
> - jfsutils needs to be packaged for Guix

I wrote a quick but working package[0].

> - and a static fsck added to the initramfs

I didn't have time for this yet.

Kind regards,

T G-R

[0]: https://issues.guix.gnu.org/issue/38572

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: jfs, jfsutils?

[Michael Zucchi]

[-- Attachment #1: Type: text/plain, Size: 1073 bytes --]

Hi Tobias,

On 12/12/19 12:11 pm, Tobias Geerinckx-Rice wrote:
> Michael & me,
>
> Tobias Geerinckx-Rice 写道：
>> - jfsutils needs to be packaged for Guix
>
> I wrote a quick but working package[0].
>
>> - and a static fsck added to the initramfs
>
> I didn't have time for this yet.
>

Ok so it seems you're half done already, but I've been plodding away 
(and didn't check my email on my old computer) and have both building.

I'm not really sure where to put it or how to compile each part (it just 
build jfsutils, not jfs_fsck/static) and I used the slackware patches, 
but attached is what i have at the moment.  I used jfs_fsck for the 
static fsck because that's the default name but it could be fsck.jfs.

I started with a definitions of e2fsprogs and it's related functions 
from a linux.scm i found in /gnu/store and based it on that.

I've a number of built package 'attempts' building up - should I just 
run guix gc to clear them out or will that delete stuff i'm just going 
to need again?

Cheers,
  Z

(I presume attachments work ok on this list.)



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: jfsutils.scm --]
[-- Type: text/x-scheme; name="jfsutils.scm", Size: 2609 bytes --]

(define-module (jfsutils)
  #:use-module (gnu packages linux)
  #:use-module (gnu packages)
  #:use-module (guix build-system gnu)
  #:use-module (guix build-system trivial)
  #:use-module (guix download)
  #:use-module (guix licenses)
  #:use-module (guix packages)
  #:use-module (guix utils))

(define-public jfsutils
  (package
    (name "jfsutils")
    (version "1.1.15")
    (source (origin
              (method url-fetch)
              (uri (string-append
		    "http://jfs.sourceforge.net/project/pub/jfsutils-"
		    version ".tar.gz"))
              (sha256
               (base32
                "0kbsy2sk1jv4m82rxyl25gwrlkzvl3hzdga9gshkxkhm83v1aji4"))
	      (patches (search-patches "jfsutils.patch"))))
    (build-system gnu-build-system)
    (inputs `(("util-linux" ,util-linux)))
    (home-page "http://jfs.sourceforge.net/")
    (synopsis "IBM JFS file system tools")
    (description "This package provides commands to create and check JFS
file systems.")
    ;; COPYING is gpl3, the headers are gpl2+?
    (license gpl3))
)

(define jfsutils/static
  (static-package
   (package (inherit jfsutils)
	    (inputs `())
	    (native-inputs
	     `(("util-linux:static" ,util-linux "static")
	       ("util-linux" ,util-linux)))
            (arguments
             ;; Force static linkage
             (substitute-keyword-arguments (package-arguments jfsutils)
               ((#:configure-flags _)
                '(list "LDFLAGS=-static")))))))

(define-public jfs_fsck/static
  (package
    (name "jfs_fsck-static")
    (version (package-version jfsutils))
    (build-system trivial-build-system)
    (source #f)
    (inputs
     `(("jfsutils" ,jfsutils/static)))
    (arguments
     `(#:modules ((guix build utils))
       #:builder
       (begin
         (use-modules (guix build utils)
                      (ice-9 ftw)
                      (srfi srfi-26))

         (let ((jfs_fsck (string-append (assoc-ref %build-inputs "jfsutils")
                                      "/sbin/jfs_fsck"))
               (bin    (string-append (assoc-ref %outputs "out") "/sbin")))
           (mkdir-p bin)
           (with-directory-excursion bin
             (copy-file jfs_fsck "jfs_fsck")
             (remove-store-references "jfs_fsck")
             (chmod "jfs_fsck" #o555))
           #t))))
    (home-page (package-home-page jfsutils))
    (synopsis "Statically-linked jfs_fsck command from jfsutils")
    (description "This package provides statically-linked jfs_fsck command taken
from the jfsutils package.  It is meant to be used in initrds.")
    (license (package-license jfsutils))))


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: jfsutils.patch --]
[-- Type: text/x-patch; name="jfsutils.patch", Size: 618 bytes --]

--- ./libfs/devices.c.orig	2009-03-23 10:37:05.000000000 -0500
+++ ./libfs/devices.c	2018-09-18 18:51:00.699063404 -0500
@@ -40,6 +40,7 @@
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <sys/ioctl.h>
+#include <sys/sysmacros.h>
 #if defined(__DragonFly__)
 #include <machine/param.h>
 #include <sys/diskslice.h>
--- ./libfs/devices.h.orig	2005-11-22 14:43:55.000000000 -0600
+++ ./libfs/devices.h	2018-09-19 01:55:37.960336102 -0500
@@ -40,6 +40,8 @@
 #define ERROR_INVALID_PARAMETER	87
 #define ERROR_DISK_FULL		112
 
+#include <inttypes.h>
+
 struct stat;
 
 int ujfs_get_dev_size(FILE *, int64_t * size);

Re: jfs, jfsutils?

[Joshua Branson]

Michael Zucchi <notzed@gmail.com> writes:

> Hi Tobias,
>
> On 12/12/19 12:11 pm, Tobias Geerinckx-Rice wrote:
>> Michael & me,
>>
>> Tobias Geerinckx-Rice 写道：
>>> - jfsutils needs to be packaged for Guix
>>
>> I wrote a quick but working package[0].
>>
>>> - and a static fsck added to the initramfs
>>
>> I didn't have time for this yet.
>>
>
> Ok so it seems you're half done already, but I've been plodding away
> (and didn't check my email on my old computer) and have both building.
>
> I'm not really sure where to put it or how to compile each part (it
> just build jfsutils, not jfs_fsck/static) and I used the slackware
> patches, but attached is what i have at the moment.  I used jfs_fsck
> for the static fsck because that's the default name but it could be
> fsck.jfs.
>
> I started with a definitions of e2fsprogs and it's related functions
> from a linux.scm i found in /gnu/store and based it on that.
>
> I've a number of built package 'attempts' building up - should I just
> run guix gc to clear them out or will that delete stuff i'm just going
> to need again?

I'm not entirely certain...but you would always build them again...

>
> Cheers,
>  Z
>
> (I presume attachments work ok on this list.)
>
>
>
>

-- 
Joshua Branson
Sent from Emacs and Gnus

Packing bcachefs Re: jfs, jfsutils?

[Joshua Branson]

Michael Zucchi <notzed@gmail.com> writes:

> Morning,
>
> I just built a new computer and thought i'd give guix a go but after
> finally getting everything working to the install stage ... I hit a
> personal showstopper - no jfs support whatsoever.  It's mostly an
> afterthought on every other distribution but this was a surprise.
>

It would be kind of cool to package bcachefs...but it might be a little
too premature for that.

>
> Regards,
>  Z
>

--
Joshua Branson
Sent from Emacs and Gnus

Re: Packaging bcachefs

[Tobias Geerinckx-Rice]

[-- Attachment #1.1: Type: text/plain, Size: 1351 bytes --]

Joshua,

Joshua Branson 写道：
> It would be kind of cool to package bcachefs...but it might be a 
> little
> too premature for that.

I've been using bcachefs on Guix System for a bit over 3 months 
now, without any issues that weren't self-inflicted.  The other 
way 'round (/gnu/store on bcachefs) is currently not possible.

Of course you need a kustom kernel, but it should be trivial to 
apply the ~300 bcachefs patches (upstream/v5.3..bcachefs/master) 
on top of Linux-Libre.  I'd share my recipe but it's
a) not -Libre, even though I don't use & want any of the blobs, 
and
b) such an unholy union of other dodgy patches that it would make 
the bcachefs graft look much more difficult than it is.

I've attached my bcachefs-tools package below.  It works fine, I 
just need to finish the boring bits.  Now that I have a reason 
I'll probably do so and submit it soon.

To boot Guix System on bcachefs, we're missing the same thing as 
for JFS: Guile code to read its label & UUID.  But there's one big 
problem: GRUB can't read it.  At all[0].

Either we wait until GRUB grows bcachefs support, or somebody 
(:-)) needs to finally make Guix support kernels + initrds copied 
to a separate /boot partition.

Kind regards,

T G-R

[0]: 
https://lists.gnu.org/archive/html/bug-grub/2019-03/msg00000.html


[-- Attachment #1.2: 0001-XXX-gnu-Add-bcachefs-tools.patch --]
[-- Type: text/x-patch, Size: 3583 bytes --]

From f22d6bdfbf0f31c19936b817f8ffec7d4613650a Mon Sep 17 00:00:00 2001
From: Tobias Geerinckx-Rice <me@tobias.gr>
Date: Sun, 8 Dec 2019 00:40:28 +0100
Subject: [PATCH 1/4] XXX gnu: Add bcachefs-tools.

* gnu/packages/file-systems.scm (bcachefs-tools): New public variable.
---
 gnu/packages/file-systems.scm | 55 ++++++++++++++++++++++++++++++++++-
 1 file changed, 54 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/file-systems.scm b/gnu/packages/file-systems.scm
index 1594cac846..744bcf2b52 100644
--- a/gnu/packages/file-systems.scm
+++ b/gnu/packages/file-systems.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2017, 2018 Tobias Geerinckx-Rice <me@tobias.gr>
+;;; Copyright © 2017, 2018, 2019 Tobias Geerinckx-Rice <me@tobias.gr>
 ;;; Copyright © 2017 Gábor Boskovits <boskovits@gmail.com>
 ;;; Copyright © 2017, 2018 Ricardo Wurmus <rekado@elephly.net>
 ;;; Copyright © 2018 Leo Famulari <leo@famulari.name>
@@ -34,11 +34,13 @@
   #:use-module (gnu packages bison)
   #:use-module (gnu packages check)
   #:use-module (gnu packages compression)
+  #:use-module (gnu packages crypto)
   #:use-module (gnu packages curl)
   #:use-module (gnu packages datastructures)
   #:use-module (gnu packages documentation)
   #:use-module (gnu packages docbook)
   #:use-module (gnu packages flex)
+  #:use-module (gnu packages gcc)
   #:use-module (gnu packages glib)
   #:use-module (gnu packages linux)
   #:use-module (gnu packages onc-rpc)
@@ -47,8 +49,59 @@
   #:use-module (gnu packages readline)
   #:use-module (gnu packages sqlite)
   #:use-module (gnu packages tls)
+  #:use-module (gnu packages valgrind)
   #:use-module (gnu packages xml))
 
+(define-public bcachefs-tools
+  (let ((commit "f712a866a474d70bfbe3a43aad2b04ceec13ddd3")
+        (revision "0"))
+    (package
+      (name "bcachefs-tools")
+      (version (git-version "0.1" revision commit))
+      (source
+       (origin
+         (method git-fetch)
+         (uri (git-reference
+               (url "https://evilpiepirate.org/git/bcachefs-tools.git")
+               (commit commit)))
+         (sha256
+          (base32 "01zwcqdw6kwdyji7c4307dzgiv67jjmjxpavxx2fq4661v3r7pfn"))))
+      (build-system gnu-build-system)
+      (arguments
+       `(#:make-flags
+         (list (string-append "PREFIX=" (assoc-ref %outputs "out"))
+               "INITRAMFS_DIR=$(PREFIX)/share/initramfs-tools"
+               "CC=gcc"
+               "PYTEST=pytest")
+         #:phases
+         (modify-phases %standard-phases
+           (delete 'configure)          ; no configure switch
+           #:tests? #f)))               ; XXX 6 valgrind tests fail
+      (native-inputs
+       `(("pkg-config" ,pkg-config)
+
+         ;; libbcachefs/bkey_methods.c:84:41: error: initializer element is not constant
+         ("gcc" ,gcc-8)
+
+         ;; For tests.
+         ("python-pytest" ,python-pytest)
+         ("valgrind" ,valgrind)))
+      (inputs
+       `(("keyutils" ,keyutils)
+         ("libaio" ,libaio)
+         ("libscrypt" ,libscrypt)
+         ("libsodium" ,libsodium)
+         ("liburcu" ,liburcu)
+         ("util-linux" ,util-linux)     ; lib{blkid,uuid}
+         ("lz4" ,lz4)
+         ("zlib" ,zlib)
+         ("zstd:lib" ,zstd "lib")))
+      (home-page "https://bcachefs.org/")
+      (synopsis "")
+      (description
+       "")
+      (license license:gpl2+))))
+
 (define-public httpfs2
   (package
     (name "httpfs2")
-- 
2.23.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: jfs, jfsutils?

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 2875 bytes --]

Michael,

Michael Zucchi 写道：
> Ok so it seems you're half done already, but I've been plodding 
> away 
> (and didn't check my email on my old computer) and have both 
> building.

That's great!  Shame about the duplicated effort, but such things 
happen.

> I'm not really sure where to put it or how to compile each part 
> (it just

file-systems.scm if possible.  linux.scm is already a bloated 
grab-bag.

For now, you can test each package at a time by adding the 
variable (e.g ‘jfs_fsck/static’) as the last line of your current 
.scm file.  This will make the file ‘evaluate to jfs_fsck/static’, 
so you can:

  $ guix build -f thefile.scm

You'll have to change that last line every time you want to change 
the package being built.

You'll need a Guix git checkout to get much further.  If you 
haven't yet done so, read ‘Building from Git’ in the manual and 
bootstrap yourself some Guix.

Then you can copy your 3 package expressions to file-systems.scm, 
keeping it in alphabetical order or at least not making things 
worse.  After making some small adjustments like adding a license: 
prefix, you can build your packages with:

  ~/guix$ ./pre-inst-env guix build jfsutils

> build jfsutils, not jfs_fsck/static) and I used the slackware 
> patches,
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Typo that should be the other way 'round?

Are you sure that LDFLAGS=-static is needed when using 
static-package?  Here's my aborted static version:

++(define-public jfsutils/static
++  (static-package
++   (package
++     (inherit jfsutils)
++     (name "jfsutils-static")
++     (inputs
++      `(("util-linux" ,util-linux)
++        ("util-linux:static" ,util-linux "static"))))))

I got my patches from Debian, but they do the same job.  There 
were others[0] but they weren't vital or relevant to Guix.

> but attached is what i have at the moment.  I used jfs_fsck for 
> the 
> static fsck because that's the default name but it could be 
> fsck.jfs.
>
> I started with a definitions of e2fsprogs and it's related 
> functions 
> from a linux.scm i found in /gnu/store and based it on that.
>
> I've a number of built package 'attempts' building up - should I 
> just 
> run guix gc to clear them out or will that delete stuff i'm just 
> going 
> to need again?

It will by default remove the ‘build’ dependencies, yes.

I advise against GC'ing unless you desperately need space, and it 
won't come from a handful of relatively tiny stale JFSutils.  Guix 
also deduplicates the store by default.  At file level, even.

> (I presume attachments work ok on this list.)

Sure.

;; COPYING is gpl3, the headers are gpl2+?

That's interesting.  Where'd you find gpl2+?

Kind regards,

T G-R

[0]: https://sources.debian.org/patches/jfsutils/1.1.15-4/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: jfs, jfsutils?

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 504 bytes --]

Tobias Geerinckx-Rice 写道：
> Michael Zucchi 写道：
>> it just build jfsutils, not jfs_fsck/static)
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Typo that should be the other way 'round?

…or if you mean that you're unsure how to build a non-exported 
variable (without define-public):

  ~/guix$ ./pre-inst-env guix build -e \
              '(@@ (gnu packages file-systems) jfs_fsck/static)'

Note that this takes the variable, not the package, name.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: jfs, jfsutils?

[Michael Zucchi]

Hi Tobias,

On 14/12/19 2:37 am, Tobias Geerinckx-Rice wrote:
>
> Michael Zucchi 写道：

>> I'm not really sure where to put it or how to compile each part (it just
>
> file-systems.scm if possible.  linux.scm is already a bloated grab-bag.
>
> For now, you can test each package at a time by adding the variable 
> (e.g ‘jfs_fsck/static’) as the last line of your current .scm file.  
> This will make the file ‘evaluate to jfs_fsck/static’, so you can:
>
>  $ guix build -f thefile.scm
>
> You'll have to change that last line every time you want to change the 
> package being built.
>
Ok cool.  Yeah I was doing that for testing but it seemed clunky.
> You'll need a Guix git checkout to get much further.  If you haven't 
> yet done so, read ‘Building from Git’ in the manual and bootstrap 
> yourself some Guix.
>
Actually before I downloaded the binary I tried that (and creating 
slackware packages of the many dependencies), but although everything 
compiled ok it just crashed with an obtuse stack trace whenever I tried 
doing anything.  Maybe I missed something along the way, but I can't 
remember the details now.  It was a frustrating introduction.

No doubt it will be easier within a guix environment.

>
>> build jfsutils, not jfs_fsck/static) and I used the slackware patches,
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Typo that should be the other way 'round?
>
Oh I just meant that the .scm file only compiles one part of the 
package, but that's covered by your directions above (to add the desired 
name to the end of the file) - which I was doing anyway while developing it.

> Are you sure that LDFLAGS=-static is needed when using 
> static-package?  Here's my aborted static version:
>
> ++(define-public jfsutils/static
> ++  (static-package
> ++   (package
> ++     (inherit jfsutils)
> ++     (name "jfsutils-static")
> ++     (inputs
> ++      `(("util-linux" ,util-linux)
> ++        ("util-linux:static" ,util-linux "static"))))))
>
> I got my patches from Debian, but they do the same job.  There were 
> others[0] but they weren't vital or relevant to Guix.
>
Looks like you're right.  While I was writing the description I didn't 
know about 'outputs' of packages or the 'static' output of util-linux 
and it wasn't building a static binary by default, so the -static flag 
was to force it - and expose the missing build requirement.

Incidentally the e2fsprogs in linux.scm doesn't make the /static build 
public, does it matter?

Also, should it be '(inputs' or '(native-inputs', since it's static it 
has no runtime dependencies?  Is that what they're for?

>
> ;; COPYING is gpl3, the headers are gpl2+?
>
> That's interesting.  Where'd you find gpl2+?
>
I just wasn't sure as the headers in all the .c files are gpl2+ and 
COPYING is gpl3 - but nothing in the archive (or home page - that i 
could find) actually refers to that file or any specific version. But on 
reflection gpl3 should be correct based on COPYING.

Ok well thanks for all the pointers.

I'm currently distracted with some other stuff (all sort of hacking and 
other things) but when I get back to it I guess i'll get a guix 
bootstrapped, add the functions, and then keep poking towards the goal 
of a system image.  I've already noticed gnu/build/file-systems.scm 
needs some additions for example.  I don't particularly like lisps - 
last time i touched any was writing gnome-doc.el about 20 years ago! -  
so I should also brush up on scheme and familiarise myself with the 
guile repl.

Cheers,
  Z

Re: jfs, jfsutils?

[Michael Zucchi]

On 12/12/19 10:27 am, Tobias Geerinckx-Rice wrote:
>
> If you're completely new to Guix that might sound daunting, but it's 
> honestly not that hard and you should get plenty of help on the 
> mailing list and/or on IRC.
>

Sorry Tobias, but I haven't been able to progress any further on this.  
As far as I can tell the guix boostrap process doesn't support 
amd64-only systems so although I can compile it, it doesn't pass 'make 
check' and so I didn't try further.  32-bit executables are disabled in 
my kernel and bootstrap.scm just assumes they work based on the 
architecture.

I asked on IRC but I'm in the 'wrong' timezone to get any useful 
responses and a query to the mailing list went unanswered.

Also, sort of related and I know it's not guix's fault but it's somewhat 
difficult to find anything useful about guix using any search engine.

Regards,
  Z

Re: jfs, jfsutils?

[Josh Marshall]

I would expect guix to bootstrap and run on x86_64.  I thought it worked on
my systems.  I'd be interested to hear more about this.

On Mon, Dec 30, 2019, 18:38 Michael Zucchi <notzed@gmail.com> wrote:

> On 12/12/19 10:27 am, Tobias Geerinckx-Rice wrote:
> >
> > If you're completely new to Guix that might sound daunting, but it's
> > honestly not that hard and you should get plenty of help on the
> > mailing list and/or on IRC.
> >
>
> Sorry Tobias, but I haven't been able to progress any further on this.
> As far as I can tell the guix boostrap process doesn't support
> amd64-only systems so although I can compile it, it doesn't pass 'make
> check' and so I didn't try further.  32-bit executables are disabled in
> my kernel and bootstrap.scm just assumes they work based on the
> architecture.
>
> I asked on IRC but I'm in the 'wrong' timezone to get any useful
> responses and a query to the mailing list went unanswered.
>
> Also, sort of related and I know it's not guix's fault but it's somewhat
> difficult to find anything useful about guix using any search engine.
>
> Regards,
>   Z
>
>
>
>
>

Re: jfs, jfsutils?

[Michael Zucchi]

Well it failed in 'make check' so I stopped going further as I didn't 
want some other fault causing a mess.

The critical detail is that my kernel has "CONFIG_IA32_EMULATION" turned 
off.

In my original query I included some output from tests/challenge.log:

...
warning: authentication and authorization of substitutes disabled!
@ build-started 
/home/notzed/src/guix/test-tmp/store/wr9c2ddgxlgifni61caxd2ain8b7rqv5-guile-bootstrap-2.0.drv 
- x86_64-linux 
/home/notzed/src/guix/test-tmp/var/log/guix/drvs/wr//9c2ddgxlgifni61caxd2ain8b7rqv5-guile-bootstrap-2.0.drv.bz2 
8592
while setting up the build environment: executing 
`/home/notzed/src/guix/test-tmp/store/f0ips0sdyhnhlfdqayvcbddqlijk7iid-bash': 
Exec format error
...

gnu/packages/bootstrap.scm:128 uses the 'i686-linux' directory for 
'x86_64-linux' architecture, and gnu/packages/bootstrap/i686-linux has 
32-bit binaries (obviously!).

I tried adding a x86_64 block to %bootstrap-executables and creating 
softlinks in gnu/packages/bootstrap/x86_64 but most tests want to 
download them from git.savannah.gnu.org, and tests/derivations.scm still 
tries to run the 32-bit binaries anyway.

  Z

On 31/12/19 11:12 am, Josh Marshall wrote:
> I would expect guix to bootstrap and run on x86_64.  I thought it 
> worked on my systems.  I'd be interested to hear more about this.
>
> On Mon, Dec 30, 2019, 18:38 Michael Zucchi <notzed@gmail.com 
> <mailto:notzed@gmail.com>> wrote:
>
>     On 12/12/19 10:27 am, Tobias Geerinckx-Rice wrote:
>     >
>     > If you're completely new to Guix that might sound daunting, but
>     it's
>     > honestly not that hard and you should get plenty of help on the
>     > mailing list and/or on IRC.
>     >
>
>     Sorry Tobias, but I haven't been able to progress any further on
>     this.
>     As far as I can tell the guix boostrap process doesn't support
>     amd64-only systems so although I can compile it, it doesn't pass
>     'make
>     check' and so I didn't try further.  32-bit executables are
>     disabled in
>     my kernel and bootstrap.scm just assumes they work based on the
>     architecture.
>
>     I asked on IRC but I'm in the 'wrong' timezone to get any useful
>     responses and a query to the mailing list went unanswered.
>
>     Also, sort of related and I know it's not guix's fault but it's
>     somewhat
>     difficult to find anything useful about guix using any search engine.
>
>     Regards,
>       Z
>
>
>
>

Re: jfs, jfsutils?

[Gábor Boskovits]

Hello,

Michael Zucchi <notzed@gmail.com> ezt írta (időpont: 2019. dec. 31., K, 7:27):
>
>
> Well it failed in 'make check' so I stopped going further as I didn't
> want some other fault causing a mess.
>
> The critical detail is that my kernel has "CONFIG_IA32_EMULATION" turned
> off.
>
> In my original query I included some output from tests/challenge.log:
>
> ...
> warning: authentication and authorization of substitutes disabled!
> @ build-started
> /home/notzed/src/guix/test-tmp/store/wr9c2ddgxlgifni61caxd2ain8b7rqv5-guile-bootstrap-2.0.drv
> - x86_64-linux
> /home/notzed/src/guix/test-tmp/var/log/guix/drvs/wr//9c2ddgxlgifni61caxd2ain8b7rqv5-guile-bootstrap-2.0.drv.bz2
> 8592
> while setting up the build environment: executing
> `/home/notzed/src/guix/test-tmp/store/f0ips0sdyhnhlfdqayvcbddqlijk7iid-bash':
> Exec format error
> ...
>
> gnu/packages/bootstrap.scm:128 uses the 'i686-linux' directory for
> 'x86_64-linux' architecture, and gnu/packages/bootstrap/i686-linux has
> 32-bit binaries (obviously!).
>
> I tried adding a x86_64 block to %bootstrap-executables and creating
> softlinks in gnu/packages/bootstrap/x86_64 but most tests want to
> download them from git.savannah.gnu.org, and tests/derivations.scm still
> tries to run the 32-bit binaries anyway.
>
>   Z
>
> On 31/12/19 11:12 am, Josh Marshall wrote:
> > I would expect guix to bootstrap and run on x86_64.  I thought it
> > worked on my systems.  I'd be interested to hear more about this.
> >
> > On Mon, Dec 30, 2019, 18:38 Michael Zucchi <notzed@gmail.com
> > <mailto:notzed@gmail.com>> wrote:
> >
> >     On 12/12/19 10:27 am, Tobias Geerinckx-Rice wrote:
> >     >
> >     > If you're completely new to Guix that might sound daunting, but
> >     it's
> >     > honestly not that hard and you should get plenty of help on the
> >     > mailing list and/or on IRC.
> >     >
> >
> >     Sorry Tobias, but I haven't been able to progress any further on
> >     this.
> >     As far as I can tell the guix boostrap process doesn't support
> >     amd64-only systems so although I can compile it, it doesn't pass
> >     'make
> >     check' and so I didn't try further.  32-bit executables are
> >     disabled in
> >     my kernel and bootstrap.scm just assumes they work based on the
> >     architecture.

I believe this is related to the method guix is bootstrapped on x86_64
currently.
As far as I know there is a minimal bootstrap seed which is 32 bits,
and the final
bootstrap is cross-compiled to x86_64. The problem is that for the
sake of simplicity
the current bootstrap binaries were created with 32 bits in mind. I am
sure that they
would appreciate any help to get x86_64 bootstrapped directly. Does
that make sense?

> >
> >     I asked on IRC but I'm in the 'wrong' timezone to get any useful
> >     responses and a query to the mailing list went unanswered.
> >
> >     Also, sort of related and I know it's not guix's fault but it's
> >     somewhat
> >     difficult to find anything useful about guix using any search engine.
> >
> >     Regards,
> >       Z
> >
> >
> >
> >
>

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Re: jfs, jfsutils?

[Michael Zucchi]

On 6/1/20 5:34 am, Gábor Boskovits wrote:
>>>    32-bit executables are
>>>      disabled in
>>>      my kernel and bootstrap.scm just assumes they work based on the
>>>      architecture.
> I believe this is related to the method guix is bootstrapped on x86_64
> currently.
> As far as I know there is a minimal bootstrap seed which is 32 bits,
> and the final
> bootstrap is cross-compiled to x86_64. The problem is that for the
> sake of simplicity
> the current bootstrap binaries were created with 32 bits in mind. I am
> sure that they
> would appreciate any help to get x86_64 bootstrapped directly. Does
> that make sense?
>

Yep sure that matches my take on it.  I'm willing to help if anyone has 
any ideas.

Last week I tried editing bootstrap.scm to add and use a 64-bit section 
with my own files and checksums via my own server, but I couldn't get it 
to work so I just gave up.  It downloaded them ok but the checksum 
failed - despite them being correct as far as i could tell.  I didn't 
make static binaries though so maybe that's related.  It took so long to 
try out each iteration I also lost interest.