bug#33030: Crash in progress-bar

2018-10-15 Thread Leo Famulari
On Mon, Oct 15, 2018 at 11:20:42AM +0200, Ludovic Courtès wrote:
> Could you run:
> 
>   guix build --log-file \
> /gnu/store/iql35g1g5q9dkap5splc7f9ggskr31vl-NamesList.txt
> 
> and post the contents of the file?

This log was actually found on Hydra for me (that private mirror is of
Hydra):

$ guix build --log-file 
/gnu/store/iql35g1g5q9dkap5splc7f9ggskr31vl-NamesList.txt   
https://mirror.hydra.gnu.org/log/iql35g1g5q9dkap5splc7f9ggskr31vl-NamesList.txt

I've attached it instead of pasting it in case my our mail clients
mangle the contents.
/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/bash: 
warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
guile: warning: failed to install locale
warning: failed to install locale: Invalid argument

Starting download of /gnu/store/iql35g1g5q9dkap5splc7f9ggskr31vl-NamesList.txt
From https://www.unicode.org/Public/UNIDATA/NamesList.txt...
warning: TLS warning alert received: unrecognized-name

 NamesList.txt  1.5MiB  0B/s 00:00 []   
0.0%
 NamesList.txt  1.5MiB  265KiB/s 00:00 []   
4.3%
 NamesList.txt  1.5MiB  441KiB/s 00:01 [### ]  
17.1%
 NamesList.txt  1.5MiB  771KiB/s 00:01 [#   ]  
46.9%
 NamesList.txt  1.5MiB  1.2MiB/s 00:01 [### ]  
98.1%
 NamesList.txt  1.5MiB  1.2MiB/s 00:01 [] 
100.0%


signature.asc
Description: PGP signature


bug#32769: Packaging Next browser (Common Lisp) [work in progress]

2018-10-15 Thread Andy Patterson
Hi Pierre,

On Mon, 15 Oct 2018 11:34:14 +0200
Pierre Neidhardt  wrote:

> Question: do we need both "out" and "lib" outputs?
> My understanding is that "lib" is useful when one wants to start the
> program from a REPL.  Correct?

"out" will always depend on "lib" for programs.  We want to build it
the same way as other systems so that all of the source for the
program remains inspect-able at run-time, even if it's just a
one-liner.

--
Andy





bug#32183: New ‘guix pull’ /root/.config/current/bin/guix: Permission denied

2018-10-15 Thread Ludovic Courtès
Hi Konrad,

Konrad Hinsen  skribis:

> This looks like an error in an error-raising procedure, something
> like  a meta-error ;-)

The horror bug department worked hard to deliver this one.  :-)

> Looking at
>
>   ~# ls -l /var/guix/profiles/per-user/root/current-guix
>    lrwxrwxrwx 1 root root 14 oct.  15 13:51
> /var/guix/profiles/per-user/root/current-guix -> current-4-link
>
> yields  a link that is indeed missing. What I do have is
> current-guix-4-link, but not a plain current-4-link.

Yes, it’s one of the thinkos I made, fixed in
aa227b3be3d7728331a08dbd139c47c9b271dc23.

If you’re familiar with Dired in Emacs, I’d suggest opening
/var/guix/profiles/per-user/root and fixing the symlink targets from
there (with C-c C-q).

If not I can try and come up with a script to do that.

Apologies for the mess!

Ludo’.





bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)

2018-10-15 Thread Marius Bakke
Marius Bakke  writes:

> Tim Gesthuizen  writes:
>
>> On 22.08.2018, Tim Gesthuizen wrote:
>>> This bisect passed without a single skip. It reports that the bug was
>>> first introduced by 5318b103ff277efbac248a066d162589a9083baa (which is
>>> the first commit after a larger merge).
>>
>> Maybe you missed that mail. The problem is that reverting the commit
>> does not solve the bug on the current master branch. So I am searching
>> for a good way of finding another bug through bisecting. This would mean
>> that I would need to apply a patch of some form to make sure that the
>> libepoxy problem is fixed before running the bisect script again.
>> This is why I tried to rebase the master branch to not include commits
>> updating libepoxy.
>
> Oh, I see!  Sorry for the confusion.
>
> One thing you can try to narrow down the search space is to try
> reverting that commit at different points in the repository.
>
> For example, I believe 5318b103f was merged in 49b6dc2b4.  If reverting
> on top of 49b6dc2b4 does not work, it means the (other) problem was
> introduced somewhere between 5318b103f^..49b6dc2b4.
>
> For starters, can you try to revert 49b6dc2b4 on top of 0d6f84aab and
> e0c9aed82?  My gut feeling says the first should work and the second
> not :-)

Sorry, I meant "revert 5318b103f" here.  But it does not make sense for
0d6f84aab, since it's not there!  It would be good to test it though,
since it comes from a 'core-updates' merge around the same time.

If 0d6f84aab works, good candidates to try next is reverting 5318b103f
on top of 0d6f84aab, 9a1f92a6e, and faccae1c3.

Hope this helps, and thanks for your patience here!


signature.asc
Description: PGP signature


bug#32458: Acknowledgement (SDL SEGFAULTs on foreign distro)

2018-10-15 Thread Marius Bakke
Tim Gesthuizen  writes:

> On 22.08.2018, Tim Gesthuizen wrote:
>> This bisect passed without a single skip. It reports that the bug was
>> first introduced by 5318b103ff277efbac248a066d162589a9083baa (which is
>> the first commit after a larger merge).
>
> Maybe you missed that mail. The problem is that reverting the commit
> does not solve the bug on the current master branch. So I am searching
> for a good way of finding another bug through bisecting. This would mean
> that I would need to apply a patch of some form to make sure that the
> libepoxy problem is fixed before running the bisect script again.
> This is why I tried to rebase the master branch to not include commits
> updating libepoxy.

Oh, I see!  Sorry for the confusion.

One thing you can try to narrow down the search space is to try
reverting that commit at different points in the repository.

For example, I believe 5318b103f was merged in 49b6dc2b4.  If reverting
on top of 49b6dc2b4 does not work, it means the (other) problem was
introduced somewhere between 5318b103f^..49b6dc2b4.

For starters, can you try to revert 49b6dc2b4 on top of 0d6f84aab and
e0c9aed82?  My gut feeling says the first should work and the second
not :-)

> I hope my problem is more clear now. Maybe there is another way that is
> just too obvious and simple. If you don't have a good idea on how to do
> it, I will do the bisect again and do an input rewriting for the package
> I am building to use the old libepoxy and not the one of that revision.
> This will probably involve tons of package rebuilding so I am open for
> other approaches.

Input rewriting seems like a great workaround, however tedious.  It
would be good to provide better tooling for these kinds of cases (maybe
even "guix bisect").


signature.asc
Description: PGP signature


bug#33047: pypi importer uses incorrect package names

2018-10-15 Thread Julien Lepiller

Hi,

I found that sometimes the pypi importer had trouble importing packages 
correctly. For instance, running "guix import pypi txaio" gave me this 
list of dependencies:


(propagated-inputs
 `(("python-[all]" ,#{python-\x5b;all\x5d;}#)
   ("python-[asyncio]"
,#{python-\x5b;asyncio\x5d;}#)
   ...))

guix import pypi magic-wormhole had this:

(propagated-inputs
  ("python-autobahn[twisted]"
   ,#{python-autobahn\x5b;twisted\x5d;}#)
  ...))

Of course, they break the recursive importer, which makes it difficult 
to import these packages correctly.






bug#33046: pypi importer doesn't print the correct source

2018-10-15 Thread Julien Lepiller
Hi, I tried to use the importer to refresh python-twisted, and got this 
source:


(uri (pypi-uri "twisted" version))

while the correct one should be

(uri (pypi-uri "Twisted" version ".tar.bz2"))





bug#32183: New ‘guix pull’ /root/.config/current/bin/guix: Permission denied

2018-10-15 Thread Konrad Hinsen

Hi Ludo,


Hmm you might need to run, say, ‘guix pull -l’, to make this script
magically appear.  :-)

Concretely, the new ‘guix pull’ migrates things from ~/.config/guix to
/var/guix/profiles the first time you run it, but it may be that you
haven’t yet run the *new* ‘guix pull’.


That looks like the right direction, since running "guix pull -l" starts 
by saying


   Migrating profile generations to '/var/guix/profiles/per-user/root'...

Unfortunately, its next statement is just as magic but less pleasant:

Backtrace:
   6 (primitive-load "/root/.config/guix/current/bin/guix")
In guix/ui.scm:
  1583:12  5 (run-guix-command _ . _)
In ice-9/boot-9.scm:
    829:9  4 (catch srfi-34 # …)
    829:9  3 (catch system-error # …)
    829:9  2 (catch git-error # …)
    829:9  1 (catch system-error # …)
In unknown file:
   0 (raise #)

ERROR: In procedure raise:
Wrong type (expecting exact integer): #&profile-not-found-error [profile: 
"/var/guix/profiles/per-user/root/current-guix"] 338b460>



This looks like an error in an error-raising procedure, something like  
a meta-error ;-)


Looking at

  ~# ls -l /var/guix/profiles/per-user/root/current-guix
   lrwxrwxrwx 1 root root 14 oct.  15 13:51 
/var/guix/profiles/per-user/root/current-guix -> current-4-link


yields  a link that is indeed missing. What I do have is 
current-guix-4-link, but not a plain current-4-link.


Konrad.






bug#32769: Packaging Next browser (Common Lisp) [work in progress]

2018-10-15 Thread Pierre Neidhardt
It could also be a dependency version that's different from the one pulled by
Quicklisp.

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature


bug#33030: Crash in progress-bar

2018-10-15 Thread Ludovic Courtès
Hi Leo,

Leo Famulari  skribis:

> $ guix --version
> guix (GNU Guix) aa227b3be3d7728331a08dbd139c47c9b271dc23
> Copyright (C) 2018 the Guix authors
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> $ ./pre-inst-env guix package -u .
> [...]
> downloading from 
> https://private.mirror/guix/nar/gzip/iql35g1g5q9dkap5splc7f9ggskr31vl-NamesList.txt...
> Backtrace:.txt  347KiB   1.4MiB/s 00:00 
> [  ]  92.3%

[...]

>208:33  2 (display-download-progress _ _ #:start-time _ # _ # _)
>183:12  1 (progress-bar _ _)
> In unknown file:
>0 (make-string -51 #\space)

Could you run:

  guix build --log-file \
/gnu/store/iql35g1g5q9dkap5splc7f9ggskr31vl-NamesList.txt

and post the contents of the file?

This should allow us to bridge the gap with Mark’s analysis.

Thanks in advance,
Ludo’.