Re: 01/05: doc: Add note about .

[Ludovic Courtès]

Mark H Weaver  skribis:

> guix-comm...@gnu.org writes:
>
>> civodul pushed a commit to branch version-1.0.0
>> in repository guix.
>>
>> commit 542e7fb57fe5626970e9321cd23645270a427388
>> Author: Ludovic Courtès 
>> Date:   Sat May 4 22:16:53 2019 +0200
>>
>> doc: Add note about .
>> 
>> * doc/guix.texi (Guided Graphical Installation): Add node about
>> .
>> (System Installation): Refer to it.
>
> Did you intend to push this and a few other commits to the
> 'version-1.0.0' branch, ~3 days after 'version-1.0.0' was already merged
> into 'master' and released?  Or was it meant to go to 'master'?

It was meant for ‘version-1.0.0’.  I updated the on-line copy of the
manual accordingly.

The idea being to have a prominent notice until we release 1.0.1,
hopefully in a few days, the time to fix the most critical bugs related
to the installer.

Thanks,
Ludo’.

problem installing on RAID partition and hot to rescue

[Giovanni Biscuolo]

Hello Guix!

yesterday I installed Guix 1.0.0 on bare metal (HP ProLiant DL380 G8)
using the Graphical Installation

I "manually" created a RAID 1 device /dev/md0 and used that device with
the "guided partitioning" method: Guix was installed on /mnt (up until
"populating '/mnt') but grub-install failed with this error:

  error: diskfilter writes are not supported

the command used by the installer was this:

  /gnu/store/6b2f9iz8...-grub-2-02/sbin/grub-install --no-floppy 
--target=i386-pc --boot-directory /mnt/boot /dev/md0

(I copied the above command from a picture of the console, no log sorry)

since I used a "workaround" and creating a RAID device is (still) not
supported by the Graphical Install guided/manual procedure (am I
wrong?), I guess I have to "manually" fix the grub-install step

AFAIU grub-install does not support using /dev/md? devices but I have to
install grub using the underlying physical devices (/dev/sda and /dev/sdb
in this case): correct?

after the failure I tried to remount /dev/md0 as /mnt to try to
grub-install again (on /dev/sda and /dev/sdb) *but* /dev/md0 was busy by
some process and I could not mount it again... I was in a hurry and I
had to stop there, but I suppose this kind of "block" (sorry I had no
time to investigate what process was still using /dev/md0) should be
addressed

late this week I'll be able to work on this again, I plan to start Guix
from the USB install media and use it as a rescue disk to complete
the grub-install on the physical devices: I've done this kind of fixes
several times with several rescue-distros, I should have no problem
using Guix this time

as a side note: what about raplacing mdraid with brtfs?  I have not much
experience with btrfs (especially as a boot filesystem) so I tend to be
conservative and use what I know (and is maybe more mature?)

...anyway: is btrfs formatting using raid1 (or raid10) mode supported
using the Guix Graphical Installer?

last but not least: should we add a guided RAID partitioning
method to the Graphical Installer?

thank you Guix!

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Linting, and how to get the information in to the Guix Data Serivce

[Ludovic Courtès]

Hello!

Christopher Baines  skribis:

> Christopher Baines  writes:
>
>> I've never worked with this part of Guix before, and some of it is quite
>> complex, so I've started by attempting to do the first bit, storing
>> warnings as data before outputting them. I've attached a patch.

Providing more structure sounds like a good idea to me (though in the
end it’s still just text; not sure if that’s good enough for what you
had in mind?).

>From a UI viewpoint, it’s important that ‘guix lint’ prints warning as
they come, rather than eat CPU for some time and eventually spit out
everything at once.

> From cd16443893afdacf9f3e4d8256cc943a5928aed4 Mon Sep 17 00:00:00 2001
> From: Christopher Baines 
> Date: Mon, 6 May 2019 19:00:58 +0100
> Subject: [PATCH] scripts: lint: Handle warnings with a record type.
>
> Rather than emiting warnings directly to a port, have the checkers return the
> warning or warnings.
>
> This makes it easier to use the warnings in different ways, for example,
> loading the data in to a database, as you can work with the 
> records directly, rather than having to parse the output to determine the
> package and location.

[...]

> +(define-record-type* 
> +  lint-warning make-lint-warning
> +  lint-warning?
> +  (package  lint-warning-package)
> +  (message  lint-warning-message)
> +  (location lint-warning-field
> +(default #f)))

It could be useful to have a ‘checker’ field linking to the checker that
produced the warning.

>(define (check-not-empty description)
>  (when (string-null? description)
> -  (emit-warning package
> +  (make-warning package
>  (G_ "description should not be empty")
> -'description)))
> +#:field 'description)))

This procedure returns either a warning or the unspecified value, which
is probably not intended?  I suppose a lot of the code is currently
written with ‘emit-warning’ in effect position, which will have to be
changed.

I suppose tests/lint.scm needs to be converted to the new API?

Thanks!

Ludo’.

Re: Setting up a Hurd build node

[Ludovic Courtès]

Hello,

Ricardo Wurmus  skribis:

> I just built Guix in a Debian GNU/Hurd VM and wanted to set it up as a
> build node.  I applied a patch to use the i586-gnu bootstrap binaries
> from my previous attempt in late 2018, which are published at
> https://berlin.guixsd.org/guix/bootstrap/i586-gnu/20180908/.  These were
> built with the old patched glibc 2.23.  (The patch to add the bootstrap
> binaries is 3.5MB in size because it includes the statically linked
> binaries, so I’m not attaching it here.)

I think we should fix our cross-compiled bootstrap Guile so we can
finally upload bootstrap binaries to ftp.gnu.org:

  https://issues.guix.info/issue/34427
  https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00364.html

> root@debian:~/guix-1.0.0# ./pre-inst-env guix-daemon 
> --build-users-group=guixbuild --disable-chroot &
> root@debian:~/guix-1.0.0# ./pre-inst-env guix build -S hello
> madvise failed: Function not implemented

This warning comes from Guile; it’s fixed in our guile 2.2 package and
upstream.

> The following derivation will be built:
>/gnu/store/qihk8cf98xqc7q577wb2nc5axy2ryp8m-hello-2.10.tar.gz.drv
> error: cannot kill processes for uid `999': Operation not permitted
> guix build: error: cannot kill processes for uid `999': failed with exit code 
> 1

EPERM comes from ‘waitpid’; weird!

> Uid 999 belongs to guixbuilder01.  (The gid for the guixbuild group is
> also 999.)
>
> I also tried building “hello”, but I only get the message
>
> madvise failed: Function not implemented
>
> printed endlessly.  (This is probably harmless, but nothing else
> happens.)

Looks like the bootstrap Guile is broken somehow.

Ludo’.

Re: Setting up a Hurd build node

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello,
>
> Ricardo Wurmus  skribis:
>
>> I just built Guix in a Debian GNU/Hurd VM and wanted to set it up as a
>> build node.  I applied a patch to use the i586-gnu bootstrap binaries
>> from my previous attempt in late 2018, which are published at
>> https://berlin.guixsd.org/guix/bootstrap/i586-gnu/20180908/.  These were
>> built with the old patched glibc 2.23.  (The patch to add the bootstrap
>> binaries is 3.5MB in size because it includes the statically linked
>> binaries, so I’m not attaching it here.)
>
> I think we should fix our cross-compiled bootstrap Guile so we can
> finally upload bootstrap binaries to ftp.gnu.org:
>
>   https://issues.guix.info/issue/34427
>   https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00364.html

The new cross-compiled bootstrap Guile is 2.2; for older architectures
it’s 2.0.

I made it work simply by changing all references to “2.0” in “raw-build”
of (gnu packages bootstrap) to “2.2” because the bootstrap Guile really
is version 2.2.  Prior to that the bootstrap Guile would segfault.

>> root@debian:~/guix-1.0.0# ./pre-inst-env guix-daemon 
>> --build-users-group=guixbuild --disable-chroot &
>> root@debian:~/guix-1.0.0# ./pre-inst-env guix build -S hello
>> madvise failed: Function not implemented
>
> This warning comes from Guile; it’s fixed in our guile 2.2 package and
> upstream.
>
>> The following derivation will be built:
>>/gnu/store/qihk8cf98xqc7q577wb2nc5axy2ryp8m-hello-2.10.tar.gz.drv
>> error: cannot kill processes for uid `999': Operation not permitted
>> guix build: error: cannot kill processes for uid `999': failed with exit 
>> code 1
>
> EPERM comes from ‘waitpid’; weird!
>
>> Uid 999 belongs to guixbuilder01.  (The gid for the guixbuild group is
>> also 999.)

I punted by running the daemon with only “guix-daemon --disable-chroot”,
no build users group at all.  Of course, perform-download doesn’t like
that we’re downloading things as root, so I disabled the assertion…

>> I also tried building “hello”, but I only get the message
>>
>> madvise failed: Function not implemented
>>
>> printed endlessly.  (This is probably harmless, but nothing else
>> happens.)
>
> Looks like the bootstrap Guile is broken somehow.

I replaced the bootstrap binaries with more recent ones.  I also had to
disable set-thread-name (because the Hurd doesn’t have it) and took a
step back to build something simpler:

/pre-inst-env  guix build -e '(@@ (gnu packages commencement) 
gnu-make-boot0))'

This eventually calls

/gnu/store/dqlhjyvg0n8v1kdvwfpliqy46n7kpjqb-bootstrap-binaries-0/bin/tar 
cvfa \
   /gnu/store/p278mqb3aa0xrkrrw4rg1fxbb19hbdyh-make-4.2.1.tar.xz \
   --mtime=@0 --owner=root --group=root --sort=name \
   make-4.2.1

which segfaults.  Turns out that it doesn’t segfault after removing
“--mtime=@0” from the arguments.

Weird!  This is all very familiar, because that’s where I stopped when I
last tried all of this.  I gave up when I couldn’t figure out why tar
segfaulted.

--
Ricardo

Re: guile-bash updated source url

[Mark H Weaver]

FYI, David might not have seen my reply below, because my mail server is
unable to perform DNS lookups for his domain, and thus is unable to look
up the MX record to deliver mail to him.  I'm not yet sure what's going
wrong, maybe something in my firewall configuration.

  Mark


Mark H Weaver  writes:

> Hi David,
>
> david.lars...@selfhosted.xyz writes:
>
>> On Fri, 3 May 2019, Ludovic Courtès wrote:
>>
>>> david.lars...@selfhosted.xyz skribis:
>>>
 This is my first contribution to guix and it's just a minor fix for
 the guile-bash package which had an outdated source url. I was able to
 retrieve the same revision of the package via the software-heritage
 project's website and upload it to gitlab. Then I installed it
 successfully via guix package -f my-guile-bash.scm using the gitlab
 url, then copied it to the existing guile-xyz.scm in gnu/packages.
>>>
>>> [...]
>>>
 --- a/gnu/packages/guile-xyz.scm
 +++ b/gnu/packages/guile-xyz.scm
 @@ -294,23 +294,21 @@ dictionary and suggesting spelling corrections.")
  (license license:gpl3+)))

  (define-public guile-bash
 -  ;; This project is currently retired.  It was initially announced here:
 -  ;; 
 .
 -  (let ((commit "1eabc563ca5692b3e08d84f1f0e6fd2283284469")
 +(let ((commit "49099fe6a592aa3b8001e826b939869fe5811785")
  (revision "0"))
>>>
>>> Why is the commit different?  Looks like it’s more than just a mirror.
>>>
>>> If you made changes on top of the original code, that’s actually great.
>>> However, I’d prefer to first see a patch that simply changes the URL,
>>> not the commit and hash, and later updates to a different revision.
>>>
>>> Does that make sense?
>>>
>>
>> I made a commit since I was unable figure out how to create a
>> git-mirror from the Software Heritage website but was able to retrieve
>> the correct commit as a tarball. Then I guix init'ed the folder, and
>> made a commit in order to push it to gitlab.
>
> Hmm.  If I understand correctly, it sounds like this will discard the
> entire previous git history.  If you want to maintain this package and
> host the repository yourself (as opposed to us relying on Software
> Heritage), I would advocate trying again until you can properly clone
> the existing repository.  We can help if needed.  It's important to get
> this right now, because git history cannot be rewritten after the fact,
> and it's important to preserve the existing history.
>
>   Thanks,
> Mark

Adding "nss-certs" to "%base-packages"

[Raghav Gururajan]

Hello Guix!

It appears "nss-certs" package is required in system profile for using "https" 
in guix. My suggestion is to add this package to "%base-packages". Any thoughts?

Thank you!

Regards,
RG.