bug#27064: SOLVED

2017-05-25 Thread Quiliro 
The case is solved. The problem was a bad USB installer. It took 20 minutes to 
install in a Celeron D with bare-bones.scm Thank all of you that were 
persistent enough to sugest hundreds of ideas in about 20 installations (some 
took several hours) and about 13 reboots.

bug#27067: Feature request: please allow for either automatic logging of all output of every guix commands or add an option to each guix command to allow it for all to be logged

2017-05-25 Thread Ricardo Wurmus 

Brenton Horne  writes:

> For example,
> `guix pull && guix package -u` has taken up to 12 hours to run for me
> before, so if it fails and doesn't log it can be quite an irritating waste
> of time and deter people from filing invaluable bug reports about issues
> they've experienced with guix.

“guix package” really does the same as “guix build” and if it fails the
failure will be recorded in the log that belongs to the derivation that
failed.

Not sure about “guix pull”, though.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

bug#27067: Feature request: please allow for either automatic logging of all output of every guix commands or add an option to each guix command to allow it for all to be logged

2017-05-25 Thread Ricardo Wurmus 

Brenton Horne  writes:

> As I understand it only the guix build command has an option to log output
> to a file.

Actually, the output of “guix build” is indeed stored by default.
You can get it by asking for the logs for a given derivation.

For example:

# build something, please
guix build --no-substitutes samtools
…
# show me the derivation
guix build -d samtools
# show me the location of the matching log
guix build --log-file $(guix build -d samtools)

Does this solve the feature request?

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

bug#27067: Feature request: please allow for either automatic logging of all output of every guix commands or add an option to each guix command to allow it for all to be logged

2017-05-25 Thread Brenton Horne 
I'm afraid I have no knowledge of Guile or Scheme. Looking at the Guile
manual seems to indicate to me it's a language quite unlike most languages
I've coded in. The only exception is that it does look a little like Emacs
Lisp.

On 26 May 2017 at 04:10, Arun Isaac  wrote:

>
> Brenton Horne writes:
>
> > Thanks. I did ask in the #guix IRC channel first and no one provided this
> > solution (not using this as some criticism, I realize the IRC channel is
> > people volunteering their time to help others, just mentioning) and one
> > person agreed with my suggestion of reporting this as a feature request.
> > Still this feature would be useful, but your idea makes it less urgent.
> > Automatic logging still sounds like a good idea as Guix is quite slow for
> > some operations at the moment (not dissing the developers of Guix, after
> > all at this early stage of development issues like this are to be
> > expected), for me at least running GuixSD in a QEMU VM with 8 GB RAM and
> 3
> > CPU cores (3.3 GHz i7 cores), so it might save users interested in filing
> > bug reports a lot of time (on re-running the problem command with `| tee
> > output.log` after it) if the output was logged automatically. Saving
> users
> > time will probably mean users will be far more motivated and able to
> > provide bug reports on issues they experience, which is good for the
> entire
> > Guix community as bugs would get reported and resolved faster.
>
> You could work on this issue, and submit a patch. I'm sure that would be
> welcome.
>
> Regards,
> Arun Isaac.
>



-- 
Thanks for your time,
Brenton

bug#27067: Reply to Arun Isaac's reply

2017-05-25 Thread Brenton Horne 
Hi,

Thanks. This feature would still be useful though, but your idea makes it
less urgent. Automatic logging still sounds like a good idea as the Guix
package manager is quite slow for some operations at the moment (not
criticising the developers of Guix, after all at this early stage of
development issues like this are to be expected), for me at least running
GuixSD in a QEMU VM with 8 GB RAM and 3 CPU cores (3.3 GHz i7 cores), so it
might save users interested in filing bug reports a lot of time (on
re-running the problem command with `| tee output.log` after it) if the
output was logged automatically. Saving users time will probably mean users
will be far more motivated and able to provide bug reports on issues they
experience, which is good for the entire Guix community as bugs would get
reported and resolved faster.

Thanks for your time,
Brenton

bug#27069: LUKS partition ruined by guix init

2017-05-25 Thread Marius Bakke 
some...@selfhosted.xyz writes:

> Hi,
>
> I have several times over tried to install to a LUKS-partition with
> btrfs and failed but last time I almost had success. guix init command
> complained that the bios_grub flag wasn't set after many hours of
> compiling packages and therefore didn't install grub at first. I
> checked the partition with "cryptsetup luksUUID /dev/sda1" before
> rerunning guix init and it gives me the luksUUID so the partition
> seemed intact up to that point. However, after setting the bios_grub
> flag and rerunning guix init, the installation is successful but
> afterwards the cryptsetup luksUUID command says that the partition is
> not a valid luks device, so it seems like the GRUB installation part
> is what ruins the partition.

What is your partition layout? The "bios_grub" partition must be a
separate (typically tiny) partition with no other data on it.


signature.asc
Description: PGP signature

bug#27067: Feature request: please allow for either automatic logging of all output of every guix commands or add an option to each guix command to allow it for all to be logged

2017-05-25 Thread Arun Isaac 

> I realize people can already log all output using redirection like
> with:
>
> COMMAND > output.log 2>&1
>
> but with this method no output is shown at the command-line so users can't
> track what guix is doing in real-time.

Somebody else should comment on the feature request. But, for immediate
usage, to both log the output and see it in real-time, you could use
something like:

COMMAND | tee output.log

bug#27069: LUKS partition ruined by guix init

2017-05-25 Thread someone 

Hi,

I have several times over tried to install to a LUKS-partition with
btrfs and failed but last time I almost had success. guix init command
complained that the bios_grub flag wasn't set after many hours of
compiling packages and therefore didn't install grub at first. I
checked the partition with "cryptsetup luksUUID /dev/sda1" before
rerunning guix init and it gives me the luksUUID so the partition
seemed intact up to that point. However, after setting the bios_grub
flag and rerunning guix init, the installation is successful but
afterwards the cryptsetup luksUUID command says that the partition is
not a valid luks device, so it seems like the GRUB installation part
is what ruins the partition.

bug#27067: Feature request: please allow for either automatic logging of all output of every guix commands or add an option to each guix command to allow it for all to be logged

2017-05-25 Thread Brenton Horne 
Hi,

As I understand it only the guix build command has an option to log output
to a file. I would like to request that each guix command have the option
at least (if not automatic like it is for Gentoo's Portage package manager)
to log all output to a file. I believe this will help both users and
developers deal with bugs and alike in the package manager. I realize
people can already log all output using redirection like with:

COMMAND > output.log 2>&1


but with this method no output is shown at the command-line so users can't
track what guix is doing in real-time.

Thanks for your time,
Brenton

bug#27064: after GuixSD installation

2017-05-25 Thread Quiliro 
El Thu, 25 May 2017 00:29:10 -0500
Quiliro  escribió:

> After installation (with no error mesage), I reboot. These is the output of:
> guix system init /mnt/etc/bare-bone.scm /mnt --fallback
> http://sprunge.us/SXgC
> GrUB starts to boot the system. Then the message
> waiting for "my-root" partition
> appears. Finally a Guile prompt appears after the following messages:
> Error: in proceedure scm-error
> failed to resolve partition "my-root"
> I have tryed this 8 times changing different things such as label for uefi in 
> bare-bones.scm:

Sorry. It is not UEFI. It is:
(title 'uuid)
for:
(title 'label)

> http://sprunge.us/AhcN
> http://sprunge.us/ZFAG
> 
> 
> 



-- 
Example of the problems in top posting:

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I leave quotations after my reply?

Saluton,
Quiliro
0987631031

bug#25882: gcc-wrapper doesn't handle response files

2017-05-25 Thread Ludovic Courtès 
Hi Federico,

Federico Beffa  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> The attached version adds handling of unreadable files and recursion.
>> It does not address parsing of quote-delimited options though, but I’m
>> tempted to punt on that one.
>
> My worry is that not handling them may lead to hard to debug, guix
> specific errors.

Since we’re about to freeze ‘core-updates’ and I’d like to make progress
on this front, I pushed the ld-wrapper change as commit
696487d665a616dfdd09272a7bff0bea0e19375d.

It’s not perfect as discussed earlier, but it’s known to be “good
enough” with GHC and Chromium, which are the only users of this I know
of.

Thanks,
Ludo’.

bug#26987: [PATCH 2/2] build: pull: Fix compilation list construction.

2017-05-25 Thread Ludovic Courtès 
Mathieu Othacehe  skribis:

>> I'm having a hard time tring to understand ,trace output.
>
> I get why, it's because guile-ssh is not in my %load-path. So loading
> "ssh/session.scm" fails in "source-module-dependencies".
>
> It's a bit of a vicious circle here : if resolve-interface '(ssh
> session) fails, depends-on-guile-ssh? will fail too.
>
> I'm note sure we can depend on source-module-closure to do the job here.

I believe this is fixed by commit
20ed093977cc80ba1729c38e05ae7955a38069a6, which follows a modification
to the ‘source-module-closure’ so that callers can catch
missing-dependency errors.

Please let me know what you think!

After that, you should be able to reinstate the (guix git) commit,
provided build-aux/build-self.scm does:

  (define guile-git
(package-for-current-guile "guile-git"
   "guile2.2-git"
   "guile2.0-git"))


and passes that down to ‘build-guix’.

Thanks,
Ludo’.