bug#38320: Cuirass: Allow to use authenticated Git repositories as inputs

[Clément Lassieur]

Mathieu Othacehe  writes:

>> * Fix the regression mentionned above.
>
> I would need some help for this regression I don't understand, but I
> will take care of the work needed in Guile-Git and (guix git) once this
> is fixed.

Thank you Mathieu for your replies!  I'm looking forward to your work :)

> I think too that extending Cuirass to support new use-cases would be
> really great :).

And some of the new use-cases are low-hanging fruits actually.

bug#38360: Retroarch might violate FSDG

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

Ludovic Courtès 写道：
Would you be able to help with that?  Hopefully there are 
patches we can

take from Debian, no?

If nobody can work on it in a timely fashion, I would propose to 
remove

retroarch until someone can do this work.


I'm looking into this now.

Kind regards,

T G-R


signature.asc
Description: PGP signature

bug#38420: Python 2 end of life: tracking progress

[zimoun]

Dear,

The discussion started on guix-devel [1]. Konrad list (almost) all the
packages impacted there [2] and curated the list here [3].

Hartmut proposed this pad [4] to collect the packages to look at. Feel
free to report there or here if you tackle a package.

Cheers,
simon

[1] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00359.html
[2] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00467.html
[3] https://lists.gnu.org/archive/html/guix-devel/2019-11/msg00515.html
[4] https://annuel.framapad.org/p/guix-python2-eol?lang=en

bug#38414: guix pull error while building gcc-core-mesboot-2.95.3

[Brendan Tildesley]

I'm trying to run guix pull after 4 months. This is guix on Arch.

guix (GNU Guix) fbeb92d7607dc1dc6c3a34a536352636274a69de
guix-daemon (GNU Guix) 1.0.0-1.326dcbf




...
build-@ build-log 3527328 6
gcc-co@ build-log 3527328 6
re-mes@ build-log 3527328 6
boot-2@ build-log 3527328 6
.95.3.@ build-log 3527328 6
drv-0/@ build-log 3527328 6
gcc-2.@ build-log 3527328 6
95.3/g@ build-log 3527328 4
cc'
@ build-log 3527328 13
make: *** [al@ build-log 3527328 15
l-gcc] Error 2
@ build-log 3527328 374
command "make" "CC=tcc -static -D __GLIBC_MINOR__=6" "OLDCC=tcc -static -D 
__GLIBC_MINOR__=6" "CC_FOR_BUILD=tcc -static -D __GLIBC_MINOR__=6" "AR=ar" 
"RANLIB=ranlib" "LIBGCC2_INCLUDES=-I 
/gnu/store/sdwpf8ai39y0hb98gd02qgx32s3las49-tcc-boot-0.9.27/include" 
"LANGUAGES=c" "BOOT_LDFLAGS= 
-B/gnu/store/sdwpf8ai39y0hb98gd02qgx32s3las49-tcc-boot-0.9.27/lib/" failed with 
status 2
builder for 
`/gnu/store/kcyh6k46ijm9nsq1as26rr0aq7rkx4f7-gcc-core-mesboot-2.95.3.drv' 
failed with exit code 1
@ build-failed 
/gnu/store/kcyh6k46ijm9nsq1as26rr0aq7rkx4f7-gcc-core-mesboot-2.95.3.drv - 1 
builder for 
`/gnu/store/kcyh6k46ijm9nsq1as26rr0aq7rkx4f7-gcc-core-mesboot-2.95.3.drv' 
failed with exit code 1
cannot build derivation 
`/gnu/store/slnyk8gbnvfwy1m1was8myivpss58idd-gcc-mesboot0-2.95.3.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/2633565gzh4jqh7c5zf6i0iy9yxqigcv-glibc-mesboot0-2.2.5.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/2lpg626q4x8v7hgqajywpq1rc8y72hzx-binutils-mesboot-2.20.1a.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/7pllq0crksfkr7856y1pawcy4scc7l4q-gcc-mesboot1-4.7.4.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/lp6fycqqd8adndlfylh4mlihm0qakxzw-glibc-mesboot-2.16.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/5ad88jy4a1gpbslzdiksk7zjyh28wzkr-make-mesboot-3.82.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/5xh3f9lxl86imd56fk8n6wcqdcrzh2mb-binutils-cross-boot0-2.32.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/492grrzzhh8z7nv9vrh9vai6kk7zfj8i-diffutils-boot0-3.7.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/56xfnvjd2qv05vx3j0s6b30h9dg3dqcj-file-boot0-5.33.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/b1n16vi8ypfr1bsgrcgk67h6sixghy0c-findutils-boot0-4.6.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/h6pl88jbzlgan2majgy0z6kcphzp2x6q-gcc-cross-boot0-7.4.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/5lcadggb83v1dfyza323lcw8ih199v1l-gcc-mesboot-wrapper-4.9.4.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/rmfsg2dsb88b136arb40z3kgd57kcnzs-glibc-2.29.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/qcx5p89cac2ghvc4k6cq2c6dsm3xncp1-glibc-intermediate-2.29.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/djxlq3ilag624v2zr8ya3zivwcrpiji7-linux-libre-headers-4.19.56.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/88azrsd0d3axcp043yrd4pl78ifd5368-make-boot0-4.2.1.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/my4rsf2nhcxd9n106bjrdmw56k26cc2j-perl-boot0-5.30.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/rhqqd8kmr1fqc9fkzpbh0qca4mwb03xa-texinfo-6.6.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/j5lp13iwcwnsdk545lgg1nh8kn4jdj3d-ghostscript-9.27.drv': 1 
dependencies couldn't be built
Backtrace:
In ./guix/gexp.scm:
859:2 19 (_ _)
720:2 18 (_ _)
In ./guix/monads.scm:
482:9 17 (_ _)
In ./guix/gexp.scm:
590:13 16 (_ _)
In ./guix/store.scm:
1699:8 15 (_ _)
In ./guix/gexp.scm:
859:2 14 (_ _)
720:2 13 (_ _)
In ./guix/monads.scm:
482:9 12 (_ _)
In ./guix/gexp.scm:
590:13 11 (_ _)
In ./guix/store.scm:
1699:8 10 (_ _)
In ./guix/gexp.scm:
859:2  9 (_ _)
720:2  8 (_ _)
In ./guix/monads.scm:
482:9  7 (_ _)
In ./guix/gexp.scm:
590:13  6 (_ _)
In ./guix/store.scm:
1699:8  5 (_ _)
1734:38  4 (_ #)
In ./guix/packages.scm:
948:16  3 (cache! # # ?)
1267:22  2 (thunk)
1200:25  1 (bag->derivation # # ?)
In srfi/srfi-1.scm:
592:17  0 (map1 (("source" # url: "?>) ?))

srfi/srfi-1.scm:592:17: In procedure map1:
Throw to key `srfi-34' with args `(#)'.
guix pull: error: You found a bug: the program 
'/gnu/store/gzmi7pv8pbfk91a2mrhxzybmbmhjjb3b-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"37515553b5678c61f59dd0efb2504c0ccc5152f2"; system: "x86_64-linux";

bug#38360: Retroarch might violate FSDG

[Ludovic Courtès]

Hi Nicolò,

Nicolò Balzarotti  skribis:

> We don't provide them _directly_, but when loading the program the first
> option is "Load core". Then, first option again, is "Download core". Here
> you have a list of "proprietary" .so.zip downloads. Retroarch, as far as I
> understand, is encouraging the download of those programs, with no
> licensing information (see [1]).  I don't know if this is ok or if we can
> patch it (hiding the "Download core" menu maybe?).

Oh, that sounds pretty bad.  In my view, it’s a problem:

  1. from a user freedom viewpoint, because the user might unwillingly
 find themselves downloading non-free code, and thus Guix is not
 fulfilling its mission;

  2. from a security and engineering viewpoint, because we certainly
 don’t want users to run code from arbitrary binaries downloaded
 from the net.

I think it definitely needs to be fixed.

> Debian _does_ provide (from their package manager) some o the cores [2],
> two of them with the non-free tag.
> If we patch retroarch to hide the download menu, to make it functional we
> should also package some free cores.

That sounds like a plan.

Would you be able to help with that?  Hopefully there are patches we can
take from Debian, no?

If nobody can work on it in a timely fashion, I would propose to remove
retroarch until someone can do this work.

WDYT?

Thanks,
Ludo’.

bug#22304: Julia not reproducible

[zimoun]

Hi,

This bug [1] is still present even with the version 1.1.1 of Julia.

[1] http://issues.guix.gnu.org/issue/22304


--8<---cut here---start->8---
guix describe
Generation 57   Nov 25 2019 14:26:15(current)
  guix b5d4d5b
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: b5d4d5b9bcf267fddd02fcc14b88eac0bebf979f
--8<---cut here---end--->8---

--8<---cut here---start->8---
guix build julia # populate the store with dependencies
guix build julia --check -K --no-grafts
[...]
guix build: error: derivation
`/gnu/store/xdy3jjz7dzg1lr231b8zbss8xn44ldjj-julia-1.1.1.drv' may not
be deterministic: output
`/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1' differs from
‘/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1-check’
--8<---cut here---end--->8---

--8<---cut here---start->8---
diff -r /gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1
/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1-check
Binary files 
/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1/lib/julia/sys.so
and 
/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1-check/lib/julia/sys.so
differ
Binary files 
/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1/share/julia/test/depot/compiled/v1.1/Bar/HXSAn.ji
and 
/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1-check/share/julia/test/depot/compiled/v1.1/Bar/HXSAn.ji
differ
Binary files 
/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1/share/julia/test/depot/compiled/v1.1/Baz/rONVA.ji
and 
/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1-check/share/julia/test/depot/compiled/v1.1/Baz/rONVA.ji
differ
Binary files 
/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1/share/julia/test/depot/compiled/v1.1/Foo/MYb1d.ji
and 
/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1-check/share/julia/test/depot/compiled/v1.1/Foo/MYb1d.ji
differ
Binary files 
/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1/share/julia/test/depot/compiled/v1.1/Foo/TeeT6.ji
and 
/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1-check/share/julia/test/depot/compiled/v1.1/Foo/TeeT6.ji
differ
Binary files 
/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1/share/julia/test/depot/compiled/v1.1/Qux/YFfiR.ji
and 
/gnu/store/s2vj70fgv4v4wq66dbi797ss15f8xd3b-julia-1.1.1-check/share/julia/test/depot/compiled/v1.1/Qux/YFfiR.ji
differ
--8<---cut here---end--->8---


Well, then I try to explore with diffoscope but hum? I do not do
correctly because the resulting diff is 845MB ouch!


All the best,
simon

bug#38391: Issues with Environment Variables

[Marius Bakke]

Hi anon987321 (if that is your real name),

anon987321  writes:

> I had two issues caused by ~/.guix-profile/etc/profile. First, Emacs's
> Semantic mode started having issues with GNU Global (both Emacs and
> global were installed with guix). It would complain about not knowing
> where global were located, with `/bin/bash global No Such File or
> Directory`. I did `which global`, revealing it was under
> /gnu/store/*hash*-global-6.6.3/bin/global. It seems Emacs didn't work
> well with looking for global directly under /gnu/store. I did set my
> $PATH to ~/.guix-profile/bin, but sourcing ~/.guix-profile/etc/profile
> caused it to add a /gnu/store/*hash*-profile to my $PATH, and this
> caused issues as the path wouldn't change even if i tried changing
> generations for my profile, doing rollbacks and all. If i tried to
> remove global, it would still be there under the same hash which was on
> $PATH, and Emacs would only work correctly if i launched it without
> sourcing ~/.guix-profile/etc/profile. I ended up removing guix
> completely and reinstalling it in order for it to fix

If you set GUIX_PROFILE=~/.guix-profile before sourcing the profile, the
exported variables will refer to that instead of just the _current_
generation (at the time of sourcing).  It's not very obvious,
improvements to the manual are welcome.  :-)

This topic is better suited for help-g...@gnu.org, so I'm closing the
bug report.

Hope this helps,
Marius


signature.asc
Description: PGP signature

bug#38399: Recent $EMACSLOADPATH changes break emacs-org

[Diego Nicola Barbato]

Hello Maxim,

Maxim Cournoyer  writes:

[...]

>> It stands to reason that the elisp libraries provided by Emacs itself
>> shouldn’t be in EMACSLOADPATH in the first place as they are already in
>> ‘load-path’ to which the directories in EMACSLOADPATH are prepended (as
>> described in the Emacs manual).
>
> That's not true; when using EMACSLOADPATH the Emacs' bundled libraries
> must be included explicitly, or an empty item be present (which means,
> an extra ':' present).
>
> See (elisp)Library Search:
>
> An empty element in the value of the environment variable,
> whether trailing (as in the above example), leading, or embedded, is
> replaced by the default value of ‘load-path’ as determined by the
> standard initialization procedure.  If there are no such empty
> elements, then ‘EMACSLOADPATH’ specifies the entire ‘load-path’.
> You must include either an empty element, or the explicit path to
> the directory containing the standard Lisp files, else Emacs will
> not function.

Thanks for the clarification!  And sorry for the noise, I should have
read it more closely.

Regards,

Diego

bug#37757: Kernel panic upon shutdown

[Ludovic Courtès]

Hello!

The attached patch should allow shepherd (PID 1) to dump core when it
crashes (systemd does something similar).

Jesse (and anyone else experiencing this!), could you try to (1)
reconfigure with this patch, (2) reboot, (3) try to halt the system to
reproduce the crash, and (4) retrieve a backtrace from the ‘core’ file?

For #4, you’ll have to do something along these lines once you’ve
rebooted after the crash:

  sudo gdb /run/current-system/profile/bin/guile /core

and then type “thread apply all bt” at the GDB prompt.

I’ll also try to do that on another machine where I’ve seen it happen.

Thanks in advance!

Ludo’.

diff --git a/gnu/services/shepherd.scm b/gnu/services/shepherd.scm
index 08bb33039c..ec49244cf6 100644
--- a/gnu/services/shepherd.scm
+++ b/gnu/services/shepherd.scm
@@ -277,45 +277,87 @@ and return the resulting '.go' file."
 
   (let ((files (map shepherd-service-file services)))
 (define config
-  #~(begin
-  (use-modules (srfi srfi-34)
-   (system repl error-handling))
+  (with-imported-modules '((guix build syscalls))
+#~(begin
+(use-modules (srfi srfi-34)
+ (system repl error-handling)
+ (guix build syscalls)
+ (system foreign))
 
-  ;; Arrange to spawn a REPL if something goes wrong.  This is better
-  ;; than a kernel panic.
-  (call-with-error-handling
-(lambda ()
-  (apply register-services
- (map load-compiled '#$(map scm->go files)
+(define signal
+  (let ((proc (pointer->procedure int
+  (dynamic-func "signal"
+(dynamic-link))
+  (list int '*
+(lambda (signum handler)
+  (proc signum
+(if (integer? handler);SIG_DFL, etc.
+(make-pointer handler)
+(procedure->pointer void handler (list int)))
 
-  ;; guix-daemon 0.6 aborts if 'PATH' is undefined, so work around
-  ;; it.
-  (setenv "PATH" "/run/current-system/profile/bin")
+(define (handle-crash sig)
+  (dynamic-wind
+(const #t)
+(lambda ()
+  (gc-disable)
+  (pk 'crash! sig)
+  ;; Fork and have the child dump core at the root.
+  (match (clone SIGCHLD)
+(0
+ (setrlimit 'core #f #f)
+ (chdir "/")
+ (signal sig SIG_DFL)
+ ;; Note: 'getpid' would return 1, hence this hack.
+ (kill (string->number (readlink "/proc/self"))
+   sig)
+ (primitive-_exit 253))
+(child
+ (waitpid child)
+ (sync)
+ ;; Hopefully at this point core has been dumped.
+ (pk 'done)
+ (sleep 3)
+ (primitive-_exit 255
+(lambda ()
+  (primitive-_exit 254
 
-  (format #t "starting services...~%")
-  (for-each (lambda (service)
-  ;; In the Shepherd 0.3 the 'start' method can raise
-  ;; '&action-runtime-error' if it fails, so protect
-  ;; against it.  (XXX: 'action-runtime-error?' is not
-  ;; exported is 0.3, hence 'service-error?'.)
-  (guard (c ((service-error? c)
- (format (current-error-port)
- "failed to start service '~a'~%"
- service)))
-(start service)))
-'#$(append-map shepherd-service-provision
-   (filter shepherd-service-auto-start?
-   services)))
+(signal SIGSEGV handle-crash)
 
-  ;; Hang up stdin.  At this point, we assume that 'start' methods
-  ;; that required user interaction on the console (e.g.,
-  ;; 'cryptsetup open' invocations, post-fsck emergency REPL) have
-  ;; completed.  User interaction becomes impossible after this
-  ;; call; this avoids situations where services wrongfully lead
-  ;; PID 1 to read from stdin (the console), which users may not
-  ;; have access to (see ).
-  (redirect-port (open-input-file "/dev/null")
- (current-input-port
+;; Arrange to spawn a REPL if something goes wrong.  This is better
+;; than a kernel panic.
+(call-

bug#22017: Bug #22017 Hunting: Pinning a Guix version

[zimoun]

On Thu, 28 Nov 2019 at 09:34, Ludovic Courtès  wrote:

> Yes, I think we should close this issue and create a new one about
> tagging Guix revisions/channel instances.

done. :-)

bug#38411: HTTP pipelining of narinfo requests broken for https://ci.guix.gnu.org

[Ludovic Courtès]

AFAICS everything is working fine with this config:

--8<---cut here---start->8---
root@berlin ~/maintenance/hydra# guix describe
Generation 45   Nov 28 2019 11:02:51(current)
  guix 18a5575
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 18a5575ec530f0e7a2e27f2aa3b5addf20da0f87
root@berlin ~/maintenance/hydra# git log |head
commit 9fdb990982006a4d0ddb68aa71351cc76ef50cdc
Author: Ludovic Courtès 
Date:   Thu Nov 28 11:23:29 2019 +0100

nginx: berlin: Use nginx 1.17.4.

* hydra/nginx/berlin.scm (nginx-1.17.4): New variable.
(%nginx-configuration)[nginx]: New field.
--8<---cut here---end--->8---

Please let me know if you encounter any issues!

I’ll leave it at that for now, but we’ll have to pay attention to that
in future upgrades.  (Ideally we’d report a bug to nginx but that’s
tricky enough that this alone would take much more time than I can
allocate to it.)

Ludo’.

bug#38405: [PATCH] gnu: qtbase: Use absolute references in .prl files.

[Efraim Flashner]

As I'm sure you noticed, with your patch I was able to build qtwayland.


-- 
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#38411: HTTP pipelining of narinfo requests broken for https://ci.guix.gnu.org

[Ludovic Courtès]

nginx 1.17.6 is similarly broken:

--8<---cut here---start->8---
root@berlin ~/maintenance/hydra# guix describe
Generation 45   Nov 28 2019 11:02:51(current)
  guix 18a5575
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 18a5575ec530f0e7a2e27f2aa3b5addf20da0f87
root@berlin ~/maintenance/hydra# guix build nginx
/gnu/store/6q44kjf59rgkvn0ip8m0454ybszhjpy0-nginx-1.17.6
root@berlin ~/maintenance/hydra# guix gc --references $(guix build nginx)|grep 
ssl
/gnu/store/1dvkm6b97667qd36rsnw4g6isnsmpym7-openssl-1.1.1d
--8<---cut here---end--->8---

Ludo'.

bug#38360: Retroarch does violate FSDG

[Arne Babenhauserheide]

Tobias Geerinckx-Rice via Bug reports for GNU Guix  writes:

> Guix,
>
> This is not about Schrödinger's proprietary-until-proven-innocent
> binary.  The Updater includes at least two cores explicitly marked as
> non-free in Debian:
>
>  libretro-genesisplusgx
>  libretro-snes9x

In non-free because they are non-commercial, not because they
treacherous to users.

This is a distinction the FSF used to make until 2010 but dropped since then:
https://web.archive.org/web/20100126044451/http://www.gnu.org/philosophy/categories.html#semi-freeSoftware

> Disabling the Updater seems like an open & shut case to me.
>
> This is a shame, because I think these non-commercial clauses are
> silly and legally void.  Core authors can't place arbitrary
> restrictions on derivative works of a GPL3 project. Unfortunately,
> that obvious fact is for a court to point out, and until then we must
> act as if it makes any sense.

Retroarch is not a derivative work of the cores. There is an API-layer
between both.

This is similar to a PDF which can place restrictions on what I can do
with a PDF-viewer *while viewing that PDF*. For example I’m not allowed
to charge money for displaying a PDF for which I don’t have commercial
use rights.

(since PDFs can have Javascript embedded, this even applies when we have
a strict discussion about programs)

> Arne, to address your last point first:
>
> Arne Babenhauserheide 写道：
>> It is also not advertised (I just tried) but simply one in a long
>> list of possible cores. A very long list. And you have to actively do
>> the online-lookup.
>
> For the purpose of this (FSDG) discussion, that's exactly what
> ‘advertised’ means.
>
> I install Retroarch with Guix.  When I run Retroarch, it prods me to
> (literally) ‘use the Updater if available’.  When I do that, I can
> select from many cores, at least two of them non-free.
> There is no way for me to know this important fact; I have to type the
> name of the core into a search engine and dig, possibly deep (not
> everyone knows the awesome power of a Debian copyright file :-).

Look at what happens when you have at least one core installed: It shows
you the core with a line for the license (but that says N/A for snes9x,
which is likely a bug).

If we pre-install free cores, then these are what will be shown first.

And different from browser-add-ons, they are not run until you start
them — before which you see the license (barring the N/A bug).

> You're not required to agree with any of the above, but Guix must.

If the license-info line is fixed, then not: You are then clearly
informed of the license *before* you run the core.

>> We’re not restricting software which displays non-free online comics
>> either.
>
> Indeed, that would be against our stated goal of user freedom.
>
> Comics aren't software so don't count

I disagree, but that’s a personal opinion which is not mainstream in GNU.

>> Aren’t we overblocking here? This is not a case of a program
>> restricted
>> to push someone into proprietary software, but a case of a program
>> restricted to not-for-profit for everybody.
>
> It's just as bad for the same reason.

It is not *just as* bad. If I can choose between a
closed-source-likely-spies-on-you-and-you-cannot-do-anything-about-it
tool and a
you-can-see-and-fix-everything-but-noone-can-earn-money-with-it tool,
the latter is clearly better.

Not sufficiently good for inclusion in a free distribution, but in my
opinion also not bad enough to censor from lists.

> That violates a fundamental software freedom (#0: the freedom to run
> the software as you wish, for any purpose).
>
> Contrast this with the GPL, which places zero restrictions on use — I
> don't even have to share the software or my improvements with anyone!

This is not true for the AGPL, because that places the restriction that
you have to provide the source you’re running.

That’s a restriction I like, because it prevents circumvention of the
GPL, but it is a restriction.

The non-commercial clause for emulators was added because otherwise
they would have been struck down.

>> It is a similar case as allowing to ship GPLv3 software in a ROM
>> without
>> the option to modify it, as long as no one is able to modify it on
>> that
>> medium, including the propagator.
>
> I don't see any similarities.  With any GPL3 software, I am always
> allowed to copy the software and do with it what I want, no matter the
> underlying storage at some point in time.

In that case you cannot in practice do with it what you want, because
you cannot run a modified version on your device.

The important distinction is, that the creator cannot do so either.

And this is the symmetry which is also preserved with the non-commercial
cores.

I’m not arguing to include snes9x in Guix, just that this isn’t a case
where redaction of information is needed — if we package the free cores.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP si

bug#38411: HTTP pipelining of narinfo requests broken for https://ci.guix.gnu.org

[Ludovic Courtès]

Ludovic Courtès  skribis:

> You’ll see that it hangs waiting for a response as soon as you pipeline
> 85 requests or more.

When you look at /var/log/guix-publish.log, you see that nginx did not
forward the 85th request (and beyond) to ‘guix publish’.

Interestingly, if you C-c the client while it’s waiting for further
responses, nginx suddenly forwards all the pending requests to ‘guix
publish’.

Ludo’.

bug#38411: HTTP pipelining of narinfo requests broken for https://ci.guix.gnu.org

[Ludovic Courtès]

> The weird thing is that we haven’t change the config of berlin in recent
> days.  Berlin runs nginx 1.17.5 on openssl 1.1.1d, while bayfront runs
> nginx 1.17.0 on openssl 1.0.2p.

A new data point: nginx 1.17.4 from a month ago works fine:

--8<---cut here---start->8---
root@berlin ~/maintenance/hydra# guix system list-generations 2m

[…]
Generation 238  Oct 23 2019 18:02:22
  file name: /var/guix/profiles/system-238-link
  canonical file name: /gnu/store/28xk8ny9qslyqgi7pjyz4d2x0xrxpw07-system
  label: GNU with Linux-Libre 5.3.7
  bootloader: grub
  root device: label: "my-root"
  kernel: /gnu/store/qpasq1pkzb47w5pjzs80pvslv1n7ja1m-linux-libre-5.3.7/bzImage
[…]
root@berlin ~/maintenance/hydra# guix gc -R 
/gnu/store/28xk8ny9qslyqgi7pjyz4d2x0xrxpw07-system|grep nginx
/gnu/store/4gbpgcr4zc4qf59yq2a008maycfwra4n-shepherd-nginx.scm
/gnu/store/3gqi5cahcwjfvv0bbfqv8ifir2vrqirh-nginx.conf
/gnu/store/s9fm4d5ii8bnh9zv5k78mzjvcl3dipbh-shepherd-nginx.go
/gnu/store/zj3mxk3r2dka56favm357kmgywnv5imk-nginx-1.17.4
root@berlin ~/maintenance/hydra# guix gc --references 
/gnu/store/zj3mxk3r2dka56favm357kmgywnv5imk-nginx-1.17.4/sbin/nginx |grep ssl
/gnu/store/1dvkm6b97667qd36rsnw4g6isnsmpym7-openssl-1.1.1d
--8<---cut here---end--->8---

So for now berlin is running this nginx.  I’ll try with 1.17.6 and
1.17.4 on top of current master.

Ludo’.

bug#38411: HTTP pipelining of narinfo requests broken for https://ci.guix.gnu.org

[Ludovic Courtès]

Starting from a couple of days ago (it seems; roughly around the same
time berlin hit ENOSPC), people have been experiencing issues during the
“updating list of substitutes” phase from https://ci.guix.gnu.org, where
they’d get an ugly backtrace when they’re at 80% or so.

Here’s a small reproducer:

(use-modules (guix scripts substitute)
 (srfi srfi-1)
 (srfi srfi-26)
 (web uri)
 (web request)
 (web response)
 (rnrs io ports))

(define http-multiple-get
  (@@ (guix scripts substitute) http-multiple-get))

(define %base-url
  "https://berlin.guix.gnu.org";)

(define %request-count
  ;; Number of requests to send.  Starts failing at 85 (that is, we don't
  ;; receive the 85th response).
  200)

(http-multiple-get (string->uri %base-url)
   (lambda (request response port result)
 (let ((len (or (response-content-length response)
0)))
   (pk 'resp (length result)
   (uri-path (request-uri request)))
   (get-bytevector-n port len)
   (cons result result)))
   '()
   (unfold (cut >= <> %request-count)
   (lambda (n)
 (build-request
  (string->uri
   (string-append
%base-url
"/"
(string-pad (number->string n) 32 #\a)
".narinfo"))
  #:method 'GET
  #:headers '((User-Agent . "GNU Guile"
   1+
   0)
   #:verify-certificate? #f)

You’ll see that it hangs waiting for a response as soon as you pipeline
85 requests or more.

Note that:

  1. https://bayfront.guix.gnu.org doesn’t have that problem;

  2. http://ci.guix.gnu.org doesn’t have that problem;

  3. when you send 85 requests, it hangs waiting for the 85th response;
 but when you send 200 requests, it hangs waiting for the 160th
 response; so it seems it’s not just a matter of TLS record size.

I suspected something having to do with TLS record size limits, but item
#3 above may invalidate that hypothesis.

The weird thing is that we haven’t change the config of berlin in recent
days.  Berlin runs nginx 1.17.5 on openssl 1.1.1d, while bayfront runs
nginx 1.17.0 on openssl 1.0.2p.

I very much welcome any ideas you may have!

Thanks,
Ludo’.

bug#22017: Bug #22017 Hunting: Pinning a Guix version

[Ludovic Courtès]

Hello!

zimoun  skribis:

> You wrote:
>
>   git clone …/guix.git my-pinned-guix
>   (cd my-pinned-guix; git checkout deadbeef)
>   guix package -L my-pinned-guix --manifest=my-manifest.scm
>
>
> which is now possible with
>
>   guix pull --commit=deadbeef
>   guix package -m my-manifest.scm
>
> Moreover, "guix time-machine" also handles such use case. If I understand 
> well.

Yes, pinning is definitely implemented, and much more nicely than what I
was suggesting back in 2015!

> Recently, a lot of new features have been discussed on guix-devel.
> This one has not been raised: add local tags to ease the navigation
> through different versions of Guix. It is not clear to me if it should
> be under "guix pull", e.g., "guix pull --tag=add foo" or another
> command "guix tag add foo".
>
> Because it is an really old bug, I am not sure that this whishlist
> will efficiently work as a reminder, so I am inclined to close it or
> maybe change the title or raise this very tagging feature to
> guix-devel.

Yes, I think we should close this issue and create a new one about
tagging Guix revisions/channel instances.

Thanks!

Ludo’.

bug#38360: Retroarch might violate FSDG

[Arne Babenhauserheide]

Nicolò Balzarotti  writes:

>> Aren’t we overblocking here? This is not a case of a program restricted
>> to push someone into proprietary software, but a case of a program
>> restricted to not-for-profit for everybody.
>>
> This is, by (some) definition, non free.

Yes.

>> It is a similar case as allowing to ship GPLv3 software in a ROM without
>> the option to modify it, as long as no one is able to modify it on that
>> medium, including the propagator.
>>
>
>> In the case of snes9x no one is able to monetize the software, including
>> the creators, because many people have a stake in the non-commercial
>> clause, but the software is freely modifiable and you can share it
>> non-commercially.
>>
>> It is also not advertised (I just tried) but simply one in a long list
>> of possible cores. A very long list. And you have to actively do the
>> online-lookup.
>>
>> We’re not restricting software which displays non-free online comics
>> either.
>>
> Comics aren't software. Free as in Freedom can apply only to software, AFAIK

It can apply to non-software, see for example the Wikipedia and
Stackoverflow. I experience that regularly since I’m writing a
GPL-licensed roleplaying book: it uses graphics from Battle For Wesnoth,
under GPL, and getting cc by-sa GPL-compatible was a major pain point
for many years -> https://www.draketo.de/english/free-software/by-sa-gpl

>> Installing the fastest and most compatible free software cores by
>> default (pre-installed) would minimize the effect of cores bound to
>> non-commercial use being available online without restricting the users
>> in using RetroArch — and it would make retroarch more convenient to use.
>
> If I understand correctly (i.e. shipping free cores with our retroarch
> distribution, while still allowing non-free software download from the
> software), I half-way agree with you. However, IMO, we should not encourage
> the use of non free software, at all. Those non-free cores available in one
> click, and a user might not even know that 1. s/he is downloading some kind
> of software and 2. that this software is non-free (no license details).

Looking at the interface *if you have some cores installed* it first
presents those cores and only afterwards says "download core".

And for available cores there’s actually a license entry (but that
currently says N/A — which looks like a bug to me).

So while there is no license in the listing, you are presented with the
license before running a core.

> I was upset in discovering that I downloaded a non-free core, and I
> realized just because of the ".so.zip" name. If upstream they change
> the name to "core.zip", future users might not even understand what
> they are doing.

The .so file ending is already something that takes domain knowledge to
recognize. But not from the domain of the program: The domain of the
program are emulators and roms. For these "this uses a core for the
specified hardware" is pretty clear.

> Finally, in a purely reproducible interest, having random software
> downloaded is just bad.

I agree in principle but not in practice, because we also ship npm, pip,
gem, package.el, cargo, maven, …

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken


signature.asc
Description: PGP signature