bug#42286: SWH fallback fails (git-fetch)

[zimoun]

Hi,

On Fri, 10 Jul 2020 at 00:24, Ludovic Courtès  wrote:
> Hi!
>
> zimoun  skribis:
>
>> Trying to download from Software Heritage...
>> Backtrace:
>>4 (primitive-load "/gnu/store/s56y8npabah6jc1bqrhsac6wqb1?")
>> In ./guix/swh.scm:
>>573:13  3 (swh-download "https://github.com/zimoun/hello-example?; ?)
>>224:22  2 (call "https://archive.softwareheritage.org/api/1/revi?; ?)
>> In web/client.scm:
>> 563:0  1 (http-get "https://archive.softwareheritage.org/api/1/?; ?)
>> 231:6  0 (tls-wrap # _ # _)
>>
>> web/client.scm:231:6: In procedure tls-wrap:
>> Error while printing exception.
>> builder for `/gnu/store/jn6f86hg9zyyhms1vn56hviv4m9yjm8j-git-checkout.drv' 
>> failed with exit code 1
>
> Should be fixed with commit a7696b9733d4ede9817a0a0accb5ce5b85d9a2d3.
> Let me know if anything’s amiss.

Cool! Works. :-)

I was almost there. :-) The missing trick was because the Guile bug
   
I was not aware and so the new "http-get*".

Is it worth to add the test in guix-build.sh?


All the best,
simon

bug#42291: data service: Show list of files and allow qeuerying

[Bengt Richter]

Hi

On +2020-07-09 11:25:05 +0200, zimoun wrote:
> Dear,
> 
> +Pierre because I am not sure he reads carefully debuugs. ;-)
> 
> On Thu, 09 Jul 2020 at 10:13, Hartmut Goebel  
> wrote:
> > Serverity: wishlist
> > I often find myself checking the content of a package. For this I
> > would like to be able to inspect the list of files in a package, or
> > even query for a specific file.
> 
> Pierre proposed "guix filesearch" some time ago.
> 
> https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html
> 
> 
> > This is much like Debian does in "list of files" for each package (e.g. 
> > ) 
> > and with "Search the contents of packages" 
> > 
> 
> Yes, it could be nice to have that in the Data Service.
>

Since this is about listing files, seems like it wouldn't be that hard to 
provide
a file globbing selection option like find dir -iname globexpr (pass through to 
find itself?)
(hm, also -newerct timespec can be a handy find opt)
and/or output control like "stat -c 'formatstring'" (likewise pass through to 
stat) ?
Also, ls-borrowed options like -B -1 -d -A might be nice.

If you want to consider the general problem of inspecting arbitrary object 
component details,
lsblk -o,selected,fields,listed,here  might be a good model (including -n 
option).

I think it would be nice if all object detail listing functions would converge 
in design
to a few consistent ways of specifying source and output options, so we 
wouldn't have
to re-invent "$(foo -dumpalot|sed -E ad_hoc_hack)" so much.

Are there any system design guidelines for converging?

BTW, please preserve cli and info retrieval independence from GUI systems,
(except when GUI preferences and parameters are the objects being inspected,
of course, but even then, minimize entanglements :)

> 
> All the best,
> simon
> 
> 
> 

-- 
Regards,
Bengt Richter

bug#42301: Build of GNU Solfege fails

[Tim Magee]

GNU Solfege 3.22.2 refuses to build.

Here is what I believe is the relevant part of the log file:

Converting to PNG...LC_ALL=C makeinfo -I topdocs --no-split --no-headers
--output FAQ topdocs/FAQ.texi
utf8 "\xF6" does not map to Unicode at
/gnu/store/w8k9hcigvhzrlrblv8lgqj77sm3833rs-texinfo-6.7/share/texinfo/Texinfo/ParserNonXS.pm
line 1796,  line 169.
Malformed UTF-8 character: \xf6\x20\x41\x63 (unexpected non-continuation
byte 0x20, immediately after start byte 0xf6; need 4 bytes, got 1) in
pattern match (m//) at
/gnu/store/w8k9hcigvhzrlrblv8lgqj77sm3833rs-texinfo-6.7/share/texinfo/Texinfo/ParserNonXS.pm
line 3364.
Malformed UTF-8 character (fatal) at
/gnu/store/w8k9hcigvhzrlrblv8lgqj77sm3833rs-texinfo-6.7/share/texinfo/Texinfo/ParserNonXS.pm
line 3364.
make[1]: *** [Makefile:83: README] Error 25
make[1]: *** Waiting for unfinished jobs

Deleting `inverting-intervals.eps'...
Layout output to `inverting-intervals-1.eps'...
Writing inverting-intervals-systems.texi...
Writing inverting-intervals-systems.tex...
Writing inverting-intervals-systems.count...
Success: compilation successfully completed
make[1]: Leaving directory
'/tmp/guix-build-solfege-3.22.2.drv-0/solfege-3.22.2'
make: *** [Makefile:74: genfiles] Error 2
command "make" "-j" "4" failed with status 2

bug#42212: Guix version rendered as 0.0-git in info manual

[Ludovic Courtès]

Hi Arun,

Arun Isaac  skribis:

> In the info manual, the Guix version is rendered as 0.0-git. For
> example, in "(guix) The Store", see "The ability to connect to remote
> build daemons is considered experimental as of 0.0-git". I am running
> the Guix standalone system. Any idea what's going wrong?

Nothing!  :-)

The “0.0-git” string comes from (guix self).  As noted there, we can’t
really afford to change the version string at each commit, or we’d have
to rebuild the manual at each commit.

We could perhaps choose a more meaningful version string, though, maybe
by looking at the closest tag or something.

Thoughts?

Ludo’.

bug#42247: Channel news raise error on `guix pull`

[Ludovic Courtès]

Hi,

Pierre Neidhardt  skribis:

> However, guix pull chokes on it:
>
> (repl-version 0 0)
> (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value 
> (channel-news)) (value #f))

This suggests that the ‘news.scm’ file of your channel is being picked
up and evaluated as if it were a module, which it’s not.

The solution is to rename it to, say, ‘news.txt’, or to move the actual
modules to a sub-directory and specify that in ‘.guix-channel’ (info
"(guix) Channels").

HTH!

Ludo’.

bug#42286: SWH fallback fails (git-fetch)

[Ludovic Courtès]

Hi!

zimoun  skribis:

> Trying to download from Software Heritage...
> Backtrace:
>4 (primitive-load "/gnu/store/s56y8npabah6jc1bqrhsac6wqb1?")
> In ./guix/swh.scm:
>573:13  3 (swh-download "https://github.com/zimoun/hello-example?; ?)
>224:22  2 (call "https://archive.softwareheritage.org/api/1/revi?; ?)
> In web/client.scm:
> 563:0  1 (http-get "https://archive.softwareheritage.org/api/1/?; ?)
> 231:6  0 (tls-wrap # _ # _)
>
> web/client.scm:231:6: In procedure tls-wrap:
> Error while printing exception.
> builder for `/gnu/store/jn6f86hg9zyyhms1vn56hviv4m9yjm8j-git-checkout.drv' 
> failed with exit code 1

Should be fixed with commit a7696b9733d4ede9817a0a0accb5ce5b85d9a2d3.
Let me know if anything’s amiss.

Thanks!

Ludo’.

bug#42299: ‘guix lint’ should suggest CPE name

[Ludovic Courtès]

Hello!

On IRC earlier today we were looking at
 and wondering about
the CPE suggestions (which are nice!).

I tried the attached hack, which produces a few useless and sometimes
erroneous suggestions, by comparing the “references” of each CVE
(usually URLs of a security advisory or bug report) to the home page of
the package:

--8<---cut here---start->8---
$ ./pre-inst-env  guix lint -c cpe
gnu/packages/admin.scm:1103:2: tcpdump@4.9.3: suggested CPE name: 'libpcap'
gnu/packages/admin.scm:1103:2: tcpdump@4.9.3: suggested CPE name: 'libpcap'
gnu/packages/admin.scm:1103:2: tcpdump@4.9.3: suggested CPE name: 'libpcap'
gnu/packages/admin.scm:1103:2: tcpdump@4.9.3: suggested CPE name: 'libpcap'
gnu/packages/admin.scm:1103:2: tcpdump@4.9.3: suggested CPE name: 'libpcap'
gnu/packages/admin.scm:2866:2: pam-krb5@4.8: suggested CPE name: 'pam-krb5'
gnu/packages/admin.scm:1075:2: libpcap@1.9.1: suggested CPE name: 'libpcap'
gnu/packages/admin.scm:1075:2: libpcap@1.9.1: suggested CPE name: 'libpcap'
gnu/packages/admin.scm:1075:2: libpcap@1.9.1: suggested CPE name: 'libpcap'
gnu/packages/admin.scm:1075:2: libpcap@1.9.1: suggested CPE name: 'libpcap'
gnu/packages/admin.scm:1075:2: libpcap@1.9.1: suggested CPE name: 'libpcap'
gnu/packages/admin.scm:1367:2: sudo@1.9.1: suggested CPE name: 
'element_software_management_node'
gnu/packages/admin.scm:1367:2: sudo@1.9.1: suggested CPE name: 'sudo'
gnu/packages/admin.scm:1367:2: sudo@1.9.1: suggested CPE name: 'sudo'
gnu/packages/admin.scm:1367:2: sudo@1.9.1: suggested CPE name: 'sudo'
gnu/packages/admin.scm:614:2: shadow@4.8.1: suggested CPE name: 'shadow'
gnu/packages/aspell.scm:99:2: aspell-dict-ar@1.2-0: suggested CPE name: 'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-mi@0.50-0: suggested CPE name: 
'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-pl@0.51-0: suggested CPE name: 
'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-ru@0.99f7-1: suggested CPE name: 
'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-sv@0.51-0: suggested CPE name: 
'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-fr@0.50-3: suggested CPE name: 
'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-pt-br@20131030-12-0: suggested CPE 
name: 'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-el@0.08-0: suggested CPE name: 
'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-hi@0.02-0: suggested CPE name: 
'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-de@20161207-7-0: suggested CPE name: 
'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-be@0.01: suggested CPE name: 'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-es@1.11-2: suggested CPE name: 
'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-grc@0.02-0: suggested CPE name: 
'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-fi@0.7-0: suggested CPE name: 'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-da@1.6.36-11-0: suggested CPE name: 
'aspell'
gnu/packages/aspell.scm:99:2: aspell-dict-nl@0.50-2: suggested CPE name: 
'aspell'
gnu/packages/aspell.scm:41:2: aspell@0.60.8: suggested CPE name: 'aspell'
[…]
--8<---cut here---end--->8---

The conclusion is that, to make good suggestions, we need to parse the
CPE dictionary as well:

  https://nvd.nist.gov/Products/CPE

This one is still XML (not JSON) and we’d have to merge duplicates, as
in this example:

--8<---cut here---start->8---
  
GNU cpio

  
  
GNU cpio 1.0

  
  
GNU cpio 1.1

  
  
GNU cpio 1.2

  
  
GNU cpio 1.3

  
  
GNU cpio 2.4.2

  
  
GNU cpio 2.5

  
  
GNU cpio 2.5.90

  
  
GNU cpio 2.6

  
  
GNU cpio 2.7

  https://ftp.gnu.org/gnu/cpio/;>Change Log


  
 --8<---cut here---end--->8---

The references are not always useful, as above, but sometimes there’s a
“Product” reference that is the package home page.

Anyway, would be nice to add that to (guix cve) instead of succumbing to
the convenience of SaaSS!

Ludo’.

diff --git a/guix/cve.scm b/guix/cve.scm
index 7dd9005f09..52a19e0523 100644
--- a/guix/cve.scm
+++ b/guix/cve.scm
@@ -1,5 +1,5 @@
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2015, 2016, 2017, 2018, 2019 Ludovic Courtès 
+;;; Copyright © 2015, 2016, 2017, 2018, 2019, 2020 Ludovic Courtès 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -54,6 +54,7 @@
 vulnerability?
 vulnerability-id
 vulnerability-packages
+vulnerability-references
 
 json->vulnerabilities
 current-vulnerabilities
@@ -255,20 +256,23 @@ records."
   (* 3600 24 (date-month %now)))
 
 (define-record-type 
-  (vulnerability id packages)
+  (vulnerability id packages references)
   vulnerability?
   (id vulnerability-id) ;string
-  (packages   vulnerability-packages))  ;((p1 sexp1) 

bug#42298: Nonexistent Git commit referenced from current Guix package

[Leo Famulari]

The current Guix package points to a Git commit that does not exist,
which breaks the ability to build the package.

The current package version is '1.1.0-16.d3eee3c'.

That commit d3eee3c [0] is the commit that updated the Guix package
previously, to '1.1.0-15.03deb1e'.

However, there is no commit 03deb1e [1].

I'm not sure exactly which contexts will hit this bug, but somebody on
IRC had trouble:

http://logs.guix.gnu.org/guix/2020-07-09.log#232819

Specifically, while trying to build

'/gnu/store/igf09dzbik8id1bh9f0lahib6716fk81-guix-1.1.0-15.03deb1e-checkout',

... it failed with:

"fatal: reference is not a tree: 03deb1e891b8a8b21888e5e047017fd6a3ea7a5f".

[0]
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=d3eee3c0643a20ba06941ba45d9d27146a8b634d

[1]
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=03deb1e

bug#42286: SWH fallback fails (git-fetch)

[zimoun]

On Thu, 9 Jul 2020 at 02:39, zimoun  wrote:

Well, "swh-download" perfectly works directly from the REPL.

> --8<---cut here---start->8---
> guix build -L . hi

[...]

> Trying to download from Software Heritage...
> Backtrace:
>4 (primitive-load "/gnu/store/s56y8npabah6jc1bqrhsac6wqb1?")
> In ./guix/swh.scm:
>573:13  3 (swh-download "https://github.com/zimoun/hello-example?; ?)
>224:22  2 (call "https://archive.softwareheritage.org/api/1/revi?; ?)
> In web/client.scm:
> 563:0  1 (http-get "https://archive.softwareheritage.org/api/1/?; ?)
> 231:6  0 (tls-wrap # _ # _)
>
> web/client.scm:231:6: In procedure tls-wrap:
> --8<---cut here---end--->8---

The error is definitively something related to TLS and the gexp.  In
(guix git-download) "git-fetch", the "define build" returns a gexp and
here something is missing, even if the extension gnutls (module-ref
(resolve-interface '(gnu packages tls)) 'gnutls) is provided.  Hum, I
am not sure to understand what.

BTW, if in "git-fetch" from (guix git), I add these lines:

--8<---cut here---start->8---
  (setenv "GIT_SSL_NO_VERIFY" "true")

  (format #t "git-fetch~%")
  (http-get 
"https://archive.softwareheritage.org/api/1/content/sha256:31e066137a962676e89f69d1b65382de95a7ef7d914b8cb956f41ea72e0f516b/;)
  (format #t "ok~%")

  (mkdir-p directory)
--8<---cut here---end--->8---

Then I also hit:

--8<---cut here---start->8---
The following derivations will be built:
   /gnu/store/wam9fca6vj3rifvqlix9c874vpwn5k82-hi-2.10.drv
   /gnu/store/cvp65m4wzmzd8pqdfvah4mrl4zkcw3vz-git-checkout.drv
building /gnu/store/cvp65m4wzmzd8pqdfvah4mrl4zkcw3vz-git-checkout.drv...
guile: warning: failed to install locale
environment variable `PATH' set to
`/gnu/store/378zjf2kgajcfd7mfr98jn5xyc5wa3qv-gzip-1.10/bin:/gnu/store/sf3rbvb6iqcphgm1afbplcs72hsywg25-tar-1.32/bin'
git-fetch
Backtrace:
   4 (primitive-load "/gnu/store/gcr6v6p6c5gwr4l6xzqcy6wln33?")
In ice-9/eval.scm:
   293:34  3 (_ #)
In ./guix/build/git.scm:
 44:2  2 (git-fetch "https://github.com/zimoun/hello-example.git; ?)
In web/client.scm:
563:0  1 (http-get "https://archive.softwareheritage.org/api/1/?; ?)
231:6  0 (tls-wrap # _ # _)

web/client.scm:231:6: In procedure tls-wrap:
Error while printing exception.
builder for `/gnu/store/cvp65m4wzmzd8pqdfvah4mrl4zkcw3vz-git-checkout.drv'
failed with exit code 1
build of /gnu/store/cvp65m4wzmzd8pqdfvah4mrl4zkcw3vz-git-checkout.drv failed
View build log at
'/var/log/guix/drvs/cv/p65m4wzmzd8pqdfvah4mrl4zkcw3vz-git-checkout.drv.bz2'.
cannot build derivation
`/gnu/store/wam9fca6vj3rifvqlix9c874vpwn5k82-hi-2.10.drv': 1
dependencies couldn't be built
guix build: error: build of
`/gnu/store/wam9fca6vj3rifvqlix9c874vpwn5k82-hi-2.10.drv' failed
--8<---cut here---end--->8---

Then I have tried to turn off the certificate verification with
"#:verify-certification #f" for example in "vault-fetch" or "call"
used by "define-query" but nothing works.  Well, I am a bit
circumspect.

Therefore, I am waiting for a hint or the fix. :-)

Cheers,
simon

bug#42289: recursive import does not dort alphabetically

[Leo Famulari]

On Thu, Jul 09, 2020 at 01:26:03PM +0200, Hartmut Goebel wrote:
> Most file I've been working on ask for sorting alphabetically. (And IMHO
> this is a good recommendation to follow.)

What are the benefits of sorting packages?

The ordering of packages is not usually important to the machine, and
humans can search for the package names.

I think that sorting the packages is not necessarily desired, especially
for modules where a lot of packages may be imported (e.g. Rust). It
makes the Git diffs harder to understand and work with when merging or
rebasing, compared to just adding the new packages at the end of the
file.

In cases where packages are inherited to create multiple package
versions, alphanumerical sorting breaks the inheritance [0], although
inheritance is problematic in its own right and we should probably stop
using it.

[0] See 

bug#26302: Deploying the i18n’d web site

[Christopher Baines]

pelzflorian (Florian Pelz)  writes:

> Sorry, I forgot to address the patch tracker.  I wrote some hours ago:
>
> On Thu, Apr 09, 2020 at 07:31:04PM +0200, pelzflorian (Florian Pelz) wrote:
>> On Thu, Apr 09, 2020 at 05:27:05PM +0200, Ludovic Courtès wrote:
>> > Hi Florian,
>> >
>> > "pelzflorian (Florian Pelz)"  skribis:
>> >
>> > > +   (redirect "/news/porting-guix-and-guixsd.html" 
>> > > "/$lang/blog/2015/porting-guix-and-guixsd")
>> >
>> > Does that mean that /blog/2015/porting-guix-and-guixsd (without /LANG)
>> > will _not_ redirect to /LANG/blog/2015/porting-guix-and-guixsd?
>> >
>> > It’s important that all the current URL, without /LANG, remain valid.
>>
>> With the new test VM, not all is working.
>>
>> /news/porting-guix-and-guixsd.html fails (code 404).
>>
>> /blog/2015/porting-guix-and-guixsd fails (code 404).
>>
>> /blog/2015/porting-guix-and-guixsd fails (404).
>>
>> But /blog/2015/porting-guix-and-guixsd/ works fine.
>>
>> Well this is difficult to figure out.
>>
>> Regards,
>> Florian
>
> An update:
>
> The attached patch for berlin serves more but not all URLs
> properly when testing on a VM.
>
> I found one problem; the nginx locations for redirecting old URLs can
> be given a higher priority via specifying = before the location path.
>
> I am sorry for neglecting this for so long until Christopher Baines
> offered to help a few days ago.  Now I too started investigating
> myself again.

Thanks for your continued time working on this Florian. I've made a
little bit of progress now, I've taken the wip-i18n branch, applied the
patch attached to this email and deployed that at [1].

1: http://guix-website-test.cbaines.net/

This isn't a close test of the configuration for berlin, but might come
in useful when testing the NGinx configuration.

Thanks,

Chris


signature.asc
Description: PGP signature

bug#26302: Deploying the i18n’d web site

[pelzflorian (Florian Pelz)]

The trouble is that I do not have an understanding in what order nginx
tries which redirections/rewrites.  An understanding is needed instead
of investigating dead ends and 3rd party nginx modules.

What I have done a while ago (the berlin patch for guix-maintenance
from my last e-mail contains this):

To redirect accesses only to HTML files I had added

(nginx-location-configuration
 (uri "~ (.html|.htm)$")
 (body (list "try_files $uri /$lang/$uri /$lang/$uri/index.html =404;")))

However, this does not match when nginx redirects URLs like

http://guix.gnu.org/graphics/

to the index file

http://guix.gnu.org/graphics/index.html


For this reason I had added

rewrite (.*)/$ $1/index.html;

Then it matched.  But:

> > Still failing:
> >
> > http://guix.gnu.org/graphics
> >
> > http://guix.gnu.org/blog/2013/back-from-the-european-lisp-symposium
> >
> > worked before wip-i18n but stopped working.  Hrm.

Previously when visiting

http://guix.gnu.org/graphics

then nginx too looked up the index file

http://guix.gnu.org/graphics/index.html

This broke.  “rewrite (.*)/$ $1/index.html;” had not fixed it.

!! I do not know what to do about it.



My last change addressed this:

On Thu, Jul 09, 2020 at 03:09:57PM +0200, Ludovic Courtès wrote:
> "pelzflorian (Florian Pelz)"  skribis:
> > I found one problem; the nginx locations for redirecting old URLs can
> > be given a higher priority via specifying = before the location path.
> 
> One thing that bit me in the past is that regex locations have higher
> precedence that other locations, IIRC.

Yes, I think this is what happened, the

(nginx-location-configuration
 (uri "~ (.html|.htm)$")
 (body (list "try_files $uri /$lang/$uri /$lang/$uri/index.html =404;")))

was run before the

location /news/gnu-dmd-01-released.html {
  return 301 /blog/2013/gnu-dmd-01-released;
}

and therefore no return was performed.


Changing it to

location = /news/gnu-dmd-01-released.html {
  return 301 /$lang/blog/2013/gnu-dmd-01-released;
}

with = in my last described attempt fixed this.  Because the location
uri does not end in a slash, using = does not make a difference when
matching, but gives higher priority.


> > I cleared the browser cache, restarted nscd and tested these URLs
> > (with a changed /etc/hosts file pointing guix.gnu.org to the VM):
> 
> I guess you could check with “wget -v -O /dev/null” or similar, so you
> can be sure there’s no client cache interfering.

This is a good idea.  In the past I had thought things work when in
reality all was broken and it was just cached.



> If you don’t have the manual at hand, you can just make sure you’re
> getting the expected redirect, even if the end result is 404.

You are right, trying to build the manual was pointless.

> > Still failing:
> >
> > http://guix.gnu.org/graphics
> >
> > http://guix.gnu.org/blog/2013/back-from-the-european-lisp-symposium
> >
> > worked before wip-i18n but stopped working.  Hrm.
> What does nginx’s error.log file say?

I can only check later, I have deleted my VM because texinfo for
building the manual consumed too much disk space.




> > http://guix.gnu.org/manual/html_node/Power-management-Services.html
> 

The URL should have been

http://guix.gnu.org/manual/html_node/Power-Management-Services.html

with capital M.  But the old config has the wrong URL as well I think.


I have made some wrong changes since my last mail.  Will go back and
rebuild the VM from my last mail now.  With what I currently have
redirection explodes

http://guix.gnu.org/manual/html_node/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/en/html_node

!! I think this happened too back then.  I have not investigated this yet.




> I’d be happy to go ahead and deploy this so maybe let’s see and hammer
> down those remaining issues and then we can profit!  Let us know how we
> can help!
> 
> Thanks,
> Ludo’.

A solution for the two problems I marked with !! might be important.

Other than that, I would be very happy if first the berlin patch to
guix-maintenance and then after that the wip-i18n branch finally would
go to master.

Regards,
Florian

bug#42289: recursive import does not dort alphabetically

[zimoun]

On Thu, 9 Jul 2020 at 13:26, Hartmut Goebel
 wrote:

> > Because they are generally not alphabetically sorted.
>
> Most file I've been working on ask for sorting alphabetically. (And IMHO
> this is a good recommendation to follow.)

Well, I get:

295 gnu/packages/unsorted-file.scm
204 gnu/packages/sorted-file.scm

And the top 10 bigger files are unsorted:

--8<---cut here---start->8---
crates-io.scm
sort: -:6: disorder: (define-public rust-afl-0.4
emacs-xyz.scm
sort: -:2: disorder: (define-public emacs-ac-geiser
cran.scm
sort: -:3: disorder: (define-public r-dot
python-xyz.scm
sort: -:2: disorder: (define-public python-colorlog
bioinformatics.scm
sort: -:9: disorder: (define-public blasr-libcpp
haskell-xyz.scm
sort: -:238: disorder: (define-public ghc-llvm-hs
java.scm
sort: -:2: disorder: (define-public drip
games.scm
sort: -:13: disorder: (define-public foobillard++
lisp-xyz.scm
sort: -:2: disorder: (define-public cl-alexandria
perl.scm
sort: -:17: disorder: (define-public perl-b-hooks-endofscope
--8<---cut here---end--->8---

BTW, I agree that alphabetical sorting is a good recommendation.

All the best,
simon

bug#24140: Substitute hash mismatches not properly reported

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

> When using ‘guix package’, upon a substitute hash mismatch, all we see
> is something like this:
>
> Found valid signature for 
> /gnu/store/cpw9yca1mcqhqfq450dr3rz2jzr95l69-glib-2.48.0
>>From 
>>https://mirror.hydra.gnu.org/nar/cpw9yca1mcqhqfq450dr3rz2jzr95l69-glib-2.48.0
> Downloading cpw9yc...-glib-2.48.0 (13.5MiB installed)...
>  glib-2.48.0  
>   744KiB/s 00:04 | 2.9MiB transferred
> killing process 11821
> guix system: error: build failed: some substitutes for the outputs of 
> derivation `/gnu/store/lkvlm17z8qm1v6r4n5ja5vcmsp7d860i-graphviz-2.38.0.drv' 
> failed (usually happens due to networking issues); try `--fallback' to build 
> derivation from source 
>
>
> The error message from build.cc:
>
>   if (expectedHash != actualHash)
>   throw SubstError(format("hash mismatch in downloaded path `%1%': 
> expected %2%, got %3%")
>   % storePath % printHash(expectedHash) % printHash(actualHash));
>
> … is only visible when we set-build-options #:print-build-trace? #t
> (like ‘guix build’ does, but ‘guix package’ and others do not.)
>
> The message should always be displayed, regardless of
> #:print-build-trace?.

Fixed long ago, at least with the introduction of (guix status).  Closing!

bug#26302: Deploying the i18n’d web site

[Ludovic Courtès]

Hi Florian,

"pelzflorian (Florian Pelz)"  skribis:

> The attached patch for berlin serves more but not all URLs
> properly when testing on a VM.
>
> I found one problem; the nginx locations for redirecting old URLs can
> be given a higher priority via specifying = before the location path.

One thing that bit me in the past is that regex locations have higher
precedence that other locations, IIRC.

> I am sorry for neglecting this for so long until
> Christopher Baines offered to help a few days ago.  Now I too started
> investigating myself again.
>
> I cleared the browser cache, restarted nscd and tested these URLs
> (with a changed /etc/hosts file pointing guix.gnu.org to the VM):

I guess you could check with “wget -v -O /dev/null” or similar, so you
can be sure there’s no client cache interfering.

> Still failing:
>
> http://guix.gnu.org/graphics
>
> http://guix.gnu.org/blog/2013/back-from-the-european-lisp-symposium
>
> worked before wip-i18n but stopped working.  Hrm.

What does nginx’s error.log file say?

> These seem to fail but I could not properly build the manual yet:
>
> http://guix.gnu.org/manual/en/html_node/Miscellaneous-Services.html
>
> http://guix.gnu.org/manual/html_node/Power-management-Services.html

If you don’t have the manual at hand, you can just make sure you’re
getting the expected redirect, even if the end result is 404.

> The rest looks good:
>
> http://guix.gnu.org/news/timely-delivery-of-security-updates.html
>
> http://guix.gnu.org/security/
>
> http://guix.gnu.org/blog/2016/back-from-the-gnu-hackers-meeting-2016/
>
> http://guix.gnu.org/en/blog/2017/back-from-fosdem-2017
>
> http://guix.gnu.org/de/blog/2016/back-from-gbcuw-2016/
>
> works.
>
> http://guix.gnu.org/news/coming-events
>
> http://guix.gnu.org/news
>
> never worked, so it’s OK that these URLs don’t work.

Sounds good.

> http://guix.gnu.org/news/
>
> This redirect now works but did not work before wip-i18n (??).

Nice.

I’d be happy to go ahead and deploy this so maybe let’s see and hammer
down those remaining issues and then we can profit!  Let us know how we
can help!

Thanks,
Ludo’.

bug#42294: gnujump stores store directory in cfg file

[Efraim Flashner]

I opened ~/.gnujump/gnujump.cfg and I saw that there were two references
to /gnu/store/...-gnujump.../. I noticed because the game wouldn't load
since that directory had been GC'd.

I changed it so that they referred to the directory in ~/.guix-profile,
but that's suboptimal as a patch.


-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

bug#42289: recursive import does not dort alphabetically

[Hartmut Goebel]

Am 09.07.20 um 11:36 schrieb zimoun:
> Do you mean the package definitions in gnu/packages/foo.scm?

Yes.

> Because they are generally not alphabetically sorted.

Most file I've been working on ask for sorting alphabetically. (And IMHO
this is a good recommendation to follow.)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#42134: icecat: can't go back to duckduckgo search results

[Jonathan Brielmaier]

On 09.07.20 05:08, Maxim Cournoyer wrote:
> Hello!
>
> Jonathan Brielmaier  writes:
>
>> When you search for something with DuckDuckGo, click on a result and
>> then click on your browsers back button you end up at DDGs start page
>> and not the results page.
>>
>> 1. Enter "guix" in your search/address bar while having DDG as default
>> search engine.
>> 2. Click on first result -> guix.gnu.org
>> 3. Now click after landing at our beautiful website on the browsers back
>> button (<-)
>> 4. You end up at https://duckduckgo.com/?ia=web and not at
>> https://duckduckgo.com/?q=guix
>>
>> This does NOT happen when you
>> 1. use DuckDuckGo in Chromium via it's address bar
>> 2. use DDG in Icecat starting from duckduckgo.com and not the
>> address/search bar
>> 3. use Bing or Google via Icecat's address/search bar
>>
>> I have disabled the "Spoof Referers" setting which comes from Icecat and
>> is available at about:preferences#privacy
>>
>> Icecat has some custom DDG search plugin:
>> https://git.savannah.gnu.org/cgit/gnuzilla.git/tree/makeicecat#n172
>> https://git.savannah.gnu.org/cgit/gnuzilla.git/tree/data/searchplugins/duckduckgo.xml
>>
>> Maybe that's breaking that. I don't know.
>
> This was already reported upstream here:
> https://lists.gnu.org/archive/html/bug-gnuzilla/2020-02/msg0.html.
> Another user reported the same behavior wwhen using Tor browser.  It
> seems to be an issue with DDG itself, where their HTML only website
> breaks when Javascript support is detected.
>
> You can verify this by re-enabling LibreJS in Icecat; it'll suddenly
> start working again.

Okay, go back does work on https://html.duckduckgo.com/html?q= when
enabling LibreJS.

But their search doesn't break in Chromium or in upstream Firefox. So I
guess something is wrong with our Icecat/shipped search addon.

bug#42289: recursive import does not dort alphabetically

[zimoun]

Dear,

On Thu, 09 Jul 2020 at 09:53, Hartmut Goebel  
wrote:
> In most gnu/packages/*.scm files are (expected to be) sorted
> alphabetically.

Do you mean the package definitions in gnu/packages/foo.scm?
Because they are generally not alphabetically sorted.  Well, it really
depends on which module, from what I see.


All the best,
simon

bug#42291: data service: Show list of files and allow qeuerying

[zimoun]

Dear,

+Pierre because I am not sure he reads carefully debuugs. ;-)

On Thu, 09 Jul 2020 at 10:13, Hartmut Goebel  
wrote:
> Serverity: wishlist
> I often find myself checking the content of a package. For this I
> would like to be able to inspect the list of files in a package, or
> even query for a specific file.

Pierre proposed "guix filesearch" some time ago.

https://lists.gnu.org/archive/html/guix-devel/2019-03/msg00236.html


> This is much like Debian does in "list of files" for each package (e.g. 
> ) and 
> with "Search the contents of packages" 
> 

Yes, it could be nice to have that in the Data Service.


All the best,
simon

bug#42292: committer.scm: Add support for new package definitions

[Hartmut Goebel]

Serverity: wishlistHi Ricardo, many thanks for the "committer script",
which makes packager's live much easier. I'd like committer to be able
to also detect and commit new package definitions. As of today,
committer will take new packages as an update to the package in front.
And if there are several consecutive new package definitions, these will
be put into one commit.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#42291: data service: Show list of files and allow qeuerying

[Hartmut Goebel]

Serverity: wishlist
I often find myself checking the content of a package. For this I would like to 
be able to inspect the list of files in a package, or even query for a specific 
file.

This is much like Debian does in "list of files" for each package (e.g. 
) and 
with "Search the contents of packages" 


Many thanks :-)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#42290: Support other VCS with "guix build --with-commit"

[Hartmut Goebel]

|Serverity: wishlist|


guix build --with-commit only works with git repos.

It would be nice if this would also work with mercurial, SVN, Monotone, CVS, 
etc. repos.

Implementing this should not be too hard, as basically this is just setting a 
value in the source definition. (At least this is what
I would assume it does.)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

bug#42289: recursive import does not dort alphabetically

[Hartmut Goebel]

In most gnu/packages/*.scm files are (expected to be) sorted alphabetically.

Now when importing some packages recursivly, packages are output in
order of the dependency graph, thus authors need to sort them manually.

Example (requires the hex.pm importer from
:

$ ./pre-inst-env guix import hexpm -r idna | grep define-public
(define-public erlang-unicode-util-compat
(define-public erlang-idna
$ ./pre-inst-env guix import hexpm -r idna | grep define-public |
LC_ALL=C sort --check
sort: -:2: disorder: (define-public erlang-idna

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |