Re: Port Guix to my Apple Aluminum PowerBook G4

[Efraim Flashner]

On Wed, Feb 12, 2020 at 06:49:59PM +, Scott C. MacCallum wrote:
> From: Carlos Sánchez de La Lama
> Subject:  Re: [PATCH] gnu: bootstrap-tarballs: Cross-compile for 
> powerpc-linux-gnu.
> Date: Tue, 29 Nov 2016 08:38:17 +0100
> User-agent:   Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
> ---
> 
> Hi!
> 
> I finally found some time to clean-up my work. This patch is for
> core-updates branch, and allows bootstrap tarball generation by
> 
> guix build --target=powerpc-linux-gnu bootstrap-tarballs
> 
> I think the best way to proceed is integrate this onto core-updates
> (once reviewed & approved), then generate a bootstrap binaries on hydra,
> making them available for download on the bootstrap binaries URL. At
> that point I can update the rest of the powerpc-linux-gnu patches (which
> use this binaries) with the correct hashes, and send them to the list.
> 
> As Ludo suggested, I am also preparing a tutorial/blog on the porting
> process.
> 
> BR
> 
> Carlos
> 
> Does anyone know if Carlos ever produced a tutorial/blog post on how he did 
> this? I'd like to port Guix to my Apple Aluminum PowerBook G4 for 
> freedom/knowledge sake but the documentation that I've read, 
> http://guix.gnu.org/manual/devel/en/html_node/Porting.html#Porting and 
> http://guix.gnu.org/manual/devel/en/html_node/Preparing-to-Use-the-Bootstrap-Binaries.html#Building-the-Bootstrap-Binaries
>  has left me with more questions than answers.
> 
> Thank you,
> 
> Scott
> scmguru - irc.freenode.net

I reached out to Carlos a few years ago and he said he had moved on and
was pretty sure he didn't have his code or bootstrap binaries anymore.o

I've attached a few patches to this email, which is about where I am
right now on working on the 32-bit PowerPC bootstrap. So far it looks
promising. The change to bootstrap-guile I applied to master and the
other 3 on core-updates, but I suspect they should all apply on top of
master.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
From e1f761e9969a39190177fda48d60f42d63423ab7 Mon Sep 17 00:00:00 2001
From: Efraim Flashner 
Date: Thu, 13 Feb 2020 08:30:13 +0100
Subject: [PATCH] gnu: Use guile-2.0 for make-bootstrap.

* gnu/packages/make-bootstrap.scm (%guile-static): Inherit from guile-2.0.
[source]: Update patch set.
(%guile-static-stripped): Adjust for guile-2.0.
* gnu/packages/patches/guile-2.0-relocatable.patch: New file.
* gnu/local.mk (dist_patch_DATA): Register it.
---
 gnu/local.mk  |  1 +
 gnu/packages/make-bootstrap.scm   | 30 
 .../patches/guile-2.0-relocatable.patch   | 68 +++
 3 files changed, 84 insertions(+), 15 deletions(-)
 create mode 100644 gnu/packages/patches/guile-2.0-relocatable.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 3f8fa2ed7b..2cd799dca4 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -980,6 +980,7 @@ dist_patch_DATA =   
\
   %D%/packages/patches/guile-finalization-crash.patch  \
   %D%/packages/patches/guile-linux-syscalls.patch  \
   %D%/packages/patches/guile-present-coding.patch  \
+  %D%/packages/patches/guile-2.0-relocatable.patch \
   %D%/packages/patches/guile-relocatable.patch \
   %D%/packages/patches/guile-rsvg-pkgconfig.patch  \
   %D%/packages/patches/guile-emacs-fix-configure.patch \
diff --git a/gnu/packages/make-bootstrap.scm b/gnu/packages/make-bootstrap.scm
index b8d1b2af3e..2c08e31a97 100644
--- a/gnu/packages/make-bootstrap.scm
+++ b/gnu/packages/make-bootstrap.scm
@@ -699,14 +699,14 @@ for `sh' in $PATH, and without nscd, and with static NSS 
modules."
   ;; A statically-linked Guile that is relocatable--i.e., it can search
   ;; .scm and .go files relative to its installation directory, rather
   ;; than in hard-coded configure-time paths.
-  (let* ((patches (cons* (search-patch "guile-relocatable.patch")
- (search-patch "guile-2.2-default-utf8.patch")
+  (let* ((patches (cons* (search-patch "guile-2.0-relocatable.patch")
+ (search-patch "guile-default-utf8.patch")
  (search-patch "guile-linux-syscalls.patch")
- (origin-patches (package-source guile-2.2
- (source  (origin (inherit (package-source guile-2.2))
+ (origin-patches (package-source guile-2.0
+ (source  (origin (inherit (package-source guile-2.0))
 (patches patches)))
- (guile (package (inherit guile-2.2)
-  (name (string-append (package-name guile-2.2) "-static"))
+ (guile (package (inherit guile-2.0)
+  (name (string-append (package-name guile-2.0) "-static"))
   (source 

Re: [gnu-soc] [VERY URGENT] GNU ideas for GSOC 2020

[Jose E. Marchesi]

Hi there.

> For each project idea, we need:
>
> - Name of the GNU program.
>   Example: GNU poke.
>
> - Summary of the project/idea.
>   Example: DWARF to Poke translator
>
> - Little paragraph explaining the project/idea.
>
> - Skills required.
>   Example: Good knowledge of DWARF, C programming.
>
> - Contact address for interested students.
>   Example: poke-de...@gnu.org
>
> If you have an external page where you are documenting your ideas, then
> please send us the URL so we can list it in the main page.

The URL for Guix ideas page is:
https://libreplanet.org/wiki/Group:Guix/GSoC-2020

Added, thanks!

>
> Sorry for the late notice!
> And thanks! :)
>
> [1] https://www.gnu.org/software/soc-projects/ideas.html
>

Thanks for organizing this!

No, thanks to YOU for participating :)

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Bengt Richter]

Hi Guix,

On +2020-02-12 15:16:47 +0100, zimoun wrote:
> Dear,
> 
> On Wed, 12 Feb 2020 at 13:03, Orians, Jeremiah (DTMB)
>  wrote:
> 
> > We also have a scheme bootstrappable from nothing written in C
> > https://github.com/oriansj/mes-m2
> > https://github.com/oriansj/mescc-tools-seed
> 
> The term "nothing" is mitigated; i.e. "nothing" means: a booted system
> running a (linux) kernel. Right?
>

ISTR someone made an initrd with guile in it, and "booted to guile."
If that is so, does that not suggest that "from nothing" could
be independent of a running kernel?

Wouldn't that be cool? !! ;-)

> 
> Thank you for all your contributions!
> e.g., hex0 is amazing! :-)
> 
> All the best,
> simon
> 

-- 
Regards,
Bengt Richter

Re: [gnu-soc] [VERY URGENT] GNU ideas for GSOC 2020

[Gábor Boskovits]

Hello Jose,

Jose E. Marchesi  ezt írta (időpont: 2020. febr. 12.,
Sze, 19:51):
>
>
> Hi people!
>
> Once again, we are applying as a mentoring organization for GSOC 2020.
> At this point, we need to populate our ideas page with projects [1].
>
> This should be done before this Thursday (yes tomorrow).  So, if you
> want your GNU package to participate in GSOC, please send us your ideas
> to summer-of-c...@gnu.org ASAP!

Thanks for the notice.

>
> For each project idea, we need:
>
> - Name of the GNU program.
>   Example: GNU poke.
>
> - Summary of the project/idea.
>   Example: DWARF to Poke translator
>
> - Little paragraph explaining the project/idea.
>
> - Skills required.
>   Example: Good knowledge of DWARF, C programming.
>
> - Contact address for interested students.
>   Example: poke-de...@gnu.org
>
> If you have an external page where you are documenting your ideas, then
> please send us the URL so we can list it in the main page.

The URL for Guix ideas page is:
https://libreplanet.org/wiki/Group:Guix/GSoC-2020

>
> Sorry for the late notice!
> And thanks! :)
>
> [1] https://www.gnu.org/software/soc-projects/ideas.html
>

Thanks for organizing this!

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Port Guix to my Apple Aluminum PowerBook G4

[Scott C. MacCallum]

From:   Carlos Sánchez de La Lama
Subject:Re: [PATCH] gnu: bootstrap-tarballs: Cross-compile for 
powerpc-linux-gnu.
Date:   Tue, 29 Nov 2016 08:38:17 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
---

Hi!

I finally found some time to clean-up my work. This patch is for
core-updates branch, and allows bootstrap tarball generation by

guix build --target=powerpc-linux-gnu bootstrap-tarballs

I think the best way to proceed is integrate this onto core-updates
(once reviewed & approved), then generate a bootstrap binaries on hydra,
making them available for download on the bootstrap binaries URL. At
that point I can update the rest of the powerpc-linux-gnu patches (which
use this binaries) with the correct hashes, and send them to the list.

As Ludo suggested, I am also preparing a tutorial/blog on the porting
process.

BR

Carlos

Does anyone know if Carlos ever produced a tutorial/blog post on how he did 
this? I'd like to port Guix to my Apple Aluminum PowerBook G4 for 
freedom/knowledge sake but the documentation that I've read, 
http://guix.gnu.org/manual/devel/en/html_node/Porting.html#Porting and 
http://guix.gnu.org/manual/devel/en/html_node/Preparing-to-Use-the-Bootstrap-Binaries.html#Building-the-Bootstrap-Binaries
 has left me with more questions than answers.

Thank you,

Scott
scmguru - irc.freenode.net

Re: time-machine broken from 2019-04-07 to 2019-05-04

[zimoun]

The error message is:

--8<---cut here---start->8---
building 
/gnu/store/9lh33jvs123jyfpd3vqv0q2gbynsy0cx-gcc-mesboot-wrapper-4.7.4.drv...
building 
/gnu/store/cjim33x0q1bv1ppkv3qijvr1pvsn4y0q-harfbuzz-2.4.0.tar.bz2.drv...
downloading from
https://www.freedesktop.org/software/harfbuzz/release/harfbuzz-2.4.0.tar.bz2...
/sha256 hash mismatch for
/gnu/store/b4cdp9sp44848348lrpzbfafhmjqf8nr-harfbuzz-2.4.0.tar.bz2:
  expected hash: 1mpah6kwqid1kxsj4rwqsniivqbrx231j65v51yncx6s0dch0dch
  actual hash:   0vrkvdlmihdg62a4c6h5kx27khc33xmb95l50zgnwnavvpwyyw5l
hash mismatch for store item
'/gnu/store/b4cdp9sp44848348lrpzbfafhmjqf8nr-harfbuzz-2.4.0.tar.bz2'
build of /gnu/store/cjim33x0q1bv1ppkv3qijvr1pvsn4y0q-harfbuzz-2.4.0.tar.bz2.drv
failed
View build log at
'/var/log/guix/drvs/cj/im33x0q1bv1ppkv3qijvr1pvsn4y0q-harfbuzz-2.4.0.tar.bz2.drv.bz2'.
cannot build derivation
`/gnu/store/p6gfcdacjcqf2br0zwsyzx1chfvg9gxi-harfbuzz-2.4.0.drv': 1
dependencies couldn't be built
building /gnu/store/jykjkg97dsm1s6dpbjf2aa2s3vpzj3zp-make-boot0-4.2.1.drv...
cannot build derivation
`/gnu/store/f458ygy0q7k2kyvx2dyhbdpdg0bx7fms-graphviz-2.40.1.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/zq8g10nd1a6nap8nahdvcx9c34fzj7ya-texlive-bin-20180414.drv':
1 dependencies couldn't be built
cannot build derivation
`/gnu/store/czqmsdf8h3xmjakxgfpiz78q31lp8i78-guix-manual.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/yqpxm07zm0mirrdvl2c4qvf8biyzg468-guix-56e95d54d.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/7z7p0m7abi246gzigw8as2q3w33k1n31-profile.drv': 1
dependencies couldn't be built
guix time-machine: error: build of
`/gnu/store/7z7p0m7abi246gzigw8as2q3w33k1n31-profile.drv' failed
--8<---cut here---end--->8---

and examining the derivations, the culprit is 'guix-manual'. It needs
'graphviz' which needs a lot of things... and 'harfbuzz'.

Where is 'guix-manual' defined? In 'guix/self.scm'?


Aside the initial question about what to do when the source origin is
not reliable, this issue joins the question about cross-compilation
and lightweight graph. :-)

Re: Guix search, colors and INSIDE_EMACS

[zimoun]

Hi,

On Wed, 12 Feb 2020 at 14:39, Pierre Neidhardt  wrote:
> zimoun  writes:

> > However, I thought that it was fixed in Emacs 27. Ouch!
> I tried with Guix' emacs-next and I get the same problem.

Ok, I should have misread some news. :-)


Well, I am not following what we are talking about. There is 2 issues:

1.
By default with Emacs, *shell* is doing right and EShell not. Is it
coming from Emacs or other? Could the Emacs from Guix do always the
right thing?

Other said, *shell* sets by default INSIDE_EMACS to "26.3,comint". And
EShell does nothing by default. Is it Guix specific or Emacs specific?


2.
In Guix, the environment variable INSIDE_EMACS escapes the special
character OSC (and turns off the colour face).
So, Guix commands can change their behaviour depending if INSIDE_EMACS
is set or not; independently of the terminal emulator.

The patches that I sent are about this point 2.

I am using the terminal emulator 'xterm' which does not support the
special character OSC but does the expected standard when it sees one
(i.e., does nothing). All descent terminal emulator does the correct
thing with the OSC character; which is: a) does nothing if not
supported or b) does fancy display if supported. The only terminal
emulator that I know* which is not doing the standard is terminal
emulator in Emacs. That's why the environment variable to turn on/off
the OSC is named INSIDE_EMACS.

*except when the terminal emulator is incorrectly built, as
terminal-mate in Trisquel shows.

So, I have no idea about the point 1. nor investigate.


All the best,
simon

time-machine broken from 2019-04-07 to 2019-05-04

[zimoun]

Dear,

This bug [1] shows that 1100+ commits are broken for the time machine, i.e,,

  guix time-machine --commit= -- 

will fail.

The reason is the upstream in-place update of the SHA (bad practise!
bouhbouh!! :-)).

Upstream has released the version 2.4.0 of harfbuzz with the hash
1mpah6kwqid1kxsj4rwqsniivqbrx231j65v51yncx6s0dch0dch then changed it
[2] to  0vrkvdlmihdg62a4c6h5kx27khc33xmb95l50zgnwnavvpwyyw5l.

The version 2.4.0 has been introduced in Guix with the commit
2da9b81837fd1e6f08a10952784d3358be982855 using the first hash. Then
the commit  a8bb8fccd82a10a46f127b2235675b4f6cbaaf98 fixes the
upstream mess.

But, it means that all the commits between these two ones cannot be
built by Guix because a SHA mismatch error is raised.


Is the diagnostic correct?


What should be the fix?
Because it is annoying to be dependent of upstream bad practise.

Well, is it fixable?

(The initial tarball could recreated by one of us and then pushed to
SWH, but I am not convinced it is enough... because the time-machine
should check the availability of the source etc. which adds a lot of
complexity.)


What do you think?


All the best,
simon


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39575
[2] https://github.com/harfbuzz/harfbuzz/issues/1641.

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Jan Nieuwenhuizen]

Svante Signell writes:

> On Wed, 2020-02-12 at 15:16 +0100, zimoun wrote:
>> Dear,
>> 
>> On Wed, 12 Feb 2020 at 13:03, Orians, Jeremiah (DTMB)
>>  wrote:
>> 
>> > We also have a scheme bootstrappable from nothing written in C
>> > https://github.com/oriansj/mes-m2
>> > https://github.com/oriansj/mescc-tools-seed
>> 
>> The term "nothing" is mitigated; i.e. "nothing" means: a booted system
>> running a (linux) kernel. Right?
>
> I do also suspect that mes* is only for Linux so far. Any plans for Hurd?

Your suspicion is somewhat correct.  GNU Mes v0.22 added initial support
for the Hurd, and introduced a FreeBSD scaffold.  Support for the Hurd
has always been the plan, see the Guix ROADMAP or the manual
(https://guix.gnu.org/manual/en/html_node/operating_002dsystem-Reference.html#FOOT23).

Greetings,
janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Svante Signell]

On Wed, 2020-02-12 at 15:16 +0100, zimoun wrote:
> Dear,
> 
> On Wed, 12 Feb 2020 at 13:03, Orians, Jeremiah (DTMB)
>  wrote:
> 
> > We also have a scheme bootstrappable from nothing written in C
> > https://github.com/oriansj/mes-m2
> > https://github.com/oriansj/mescc-tools-seed
> 
> The term "nothing" is mitigated; i.e. "nothing" means: a booted system
> running a (linux) kernel. Right?

I do also suspect that mes* is only for Linux so far. Any plans for Hurd? Or are
the old bootstrap binaries still needed (when non-corrupt)?

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[zimoun]

Dear,

On Wed, 12 Feb 2020 at 13:03, Orians, Jeremiah (DTMB)
 wrote:

> We also have a scheme bootstrappable from nothing written in C
> https://github.com/oriansj/mes-m2
> https://github.com/oriansj/mescc-tools-seed

The term "nothing" is mitigated; i.e. "nothing" means: a booted system
running a (linux) kernel. Right?


Thank you for all your contributions!
e.g., hex0 is amazing! :-)

All the best,
simon

Re: Guix search, colors and INSIDE_EMACS

[Pierre Neidhardt]

zimoun  writes:

> However, I thought that it was fixed in Emacs 27. Ouch!
>
>
>>  commit: 
>> ]8;;https://git.savannah.gnu.org/cgit/guix.git/commit/?id=232f344f9b9dc775fe8f9c7db2e45ba20431b071\232f344f9b9dc775fe8f9c7db2e45ba20431b071]8;;\

I tried with Guix' emacs-next and I get the same problem.

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


signature.asc
Description: PGP signature

Re: [Proposal] The Formal Methods in GNU Guix Working Group

[Orians, Jeremiah (DTMB)]

> I'm interested on this topic and I will try to help as much as I can.
Good
> The original idea of Brett is very interesting. In my case I would do the 
> base compiler implemented in C and using yacc (for example) to implement the 
> grammar.
> But it won't make sense in a community like Guix where most people know 
> Scheme rather than C/C++.
> So it may make sense to write a small C compiler for Scheme and then write 
> the ML bootstrap compiler in Scheme, similar to what Guix does to bootstrap 
> itself with nyacc.
Well we already have a C compiler written in scheme, it is called Gnu Mes 
(MesCC to be precise)

We also have a scheme bootstrappable from nothing written in C
https://github.com/oriansj/mes-m2
https://github.com/oriansj/mescc-tools-seed

> This will solve more problems than Guix itself, because it seems this 
> bootstrapping problem comes historically from the very first implementations 
> of ML.
Let us hope

> As we talked yesterday with Brett via chat, PolyML is the only one that has 
> been packaged in Guix but it is very tricky, because they have on the repo 
> the binaries to boostrap itself.
That needs to be fixed

> Writting a Scheme compiler should be easy, if we don't care about 
> optimization techniques. It doesn't need that requirements.
> But if you need any help in the low level area, I can help you guys.
Well I need more help in the high level areas

-Jeremiah

Re: Cross-compilation broken on canonical packages.

[Mathieu Othacehe]

Hello,

> The only downside will be potentially an extra glibc download/build to
> build the locale set, but that’s probably OK.
>
> WDYT?

I think you're right! Pushed it as
f30d84d32db0f4f6cb84e139868e1727a7dc0a51 on core-updates.

Now the good news is that we are one patch away from having core-updates
to cross-compile bare-bones.tmpl system! This is the patch attached,
we've been discussing it here[1] without reaching a conclusion.

WDYT?

Thanks,

Mathieu

[1]: https://lists.gnu.org/archive/html/guix-patches/2019-12/msg00751.html
>From f5d773dc0a627ba6059f1025189d33a9e0d083b5 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe 
Date: Sat, 28 Dec 2019 21:29:06 +0100
Subject: [PATCH 1/2] gexp: Default to current target.

* guix/gexp.scm (lower-object): Set target argument to 'current by default and
look for the current target system at bind time if needed,
(gexp->file): ditto,
(gexp->script): ditto.
---
 guix/gexp.scm | 87 ++-
 1 file changed, 51 insertions(+), 36 deletions(-)

diff --git a/guix/gexp.scm b/guix/gexp.scm
index 12331052a6..11d4e86037 100644
--- a/guix/gexp.scm
+++ b/guix/gexp.scm
@@ -215,7 +215,7 @@ procedure to expand it; otherwise return #f."
 
 (define* (lower-object obj
#:optional (system (%current-system))
-   #:key target)
+   #:key (target 'current))
   "Return as a value in %STORE-MONAD the derivation or store item
 corresponding to OBJ for SYSTEM, cross-compiling for TARGET if TARGET is true.
 OBJ must be an object that has an associated gexp compiler, such as a
@@ -225,7 +225,10 @@ OBJ must be an object that has an associated gexp compiler, such as a
  (raise (condition ( (input obj)
 (lower
  ;; Cache in STORE the result of lowering OBJ.
- (mlet %store-monad ((graft? (grafting?)))
+ (mlet %store-monad ((target (if (eq? target 'current)
+ (current-target-system)
+ (return target)))
+ (graft? (grafting?)))
(mcached (let ((lower (lookup-compiler obj)))
   (lower obj system target))
 obj
@@ -1571,16 +1574,19 @@ are searched for in PATH.  Return #f when MODULES and EXTENSIONS are empty."
#:key (guile (default-guile))
(module-path %load-path)
(system (%current-system))
-   target)
+   (target 'current))
   "Return an executable script NAME that runs EXP using GUILE, with EXP's
 imported modules in its search path.  Look up EXP's modules in MODULE-PATH."
-  (mlet %store-monad ((set-load-path
-   (load-path-expression (gexp-modules exp)
- module-path
- #:extensions
- (gexp-extensions exp)
- #:system system
- #:target target)))
+  (mlet* %store-monad ((target (if (eq? target 'current)
+   (current-target-system)
+   (return target)))
+   (set-load-path
+(load-path-expression (gexp-modules exp)
+  module-path
+  #:extensions
+  (gexp-extensions exp)
+  #:system system
+  #:target target)))
 (gexp->derivation name
   (gexp
(call-with-output-file (ungexp output)
@@ -1609,7 +1615,7 @@ imported modules in its search path.  Look up EXP's modules in MODULE-PATH."
  (module-path %load-path)
  (splice? #f)
  (system (%current-system))
- target)
+ (target 'current))
   "Return a derivation that builds a file NAME containing EXP.  When SPLICE?
 is true, EXP is considered to be a list of expressions that will be spliced in
 the resulting file.
@@ -1620,36 +1626,45 @@ Lookup EXP's modules in MODULE-PATH."
   (define modules (gexp-modules exp))
   (define extensions (gexp-extensions exp))
 
-  (if (or (not set-load-path?)
-  (and (null? modules) (null? extensions)))
-  (gexp->derivation name
-(gexp
- (call-with-output-file (ungexp output)
-   (lambda (port)
- (for-each (lambda (exp)
- (write exp port))
-   '(ungexp (if splice?
-exp
-

Re: Fix installer restart.

[Mathieu Othacehe]

Hey,

> Did you make sure that:
>
>   make check-system TESTS=installed-os
>
> still passes?

Yup, still working :)

In the meantime, while testing those patches, I noticed that:

* If you edit the final operating-system configuration with a syntax
error, start the install, then come back to the final page, your changes
are lost. But I'm not sure we can do much about it.

* If you open a TTY4 during "guix init" is running on TTY1, then the
command fails, the cow-store umount will fail because the bash started
in TTY4 will keep the overlay busy. This is a corner-case but it will
happen. Maybe I should check for all processed using the store overlay
and kill them before umounting?

> I’d recommend using ‘match’ rather than ‘case’, because ‘case’ silently
> returns *unspecified* when it fails to match the value.

Sure.

> PS: I’m still looking at the installer tests we discussed before FOSDEM,
> but life got in the way so progress is slow!

Hehe, same for all of us :)

Anyway, I'll push soon, thanks for the fast review!

Mathieu

[GitHub] [GitHub API] Deprecation notice for authentication via URL query parameters

[Nicolò Balzarotti]

Hello Guix!

Just used `guix refresh enchive` and received this email from github:

> On February 12th, 2020 at 09:19 (UTC) your personal access token (guix 
> refresh) using GNU Guile was used as part of a query parameter to access an 
> endpoint through the GitHub API:

> https://api.github.com/repositories/83831780/releases

> Please use the Authorization HTTP header instead, as using the `access_token` 
> query parameter is deprecated and will be removed July 1st, 2020.

> Depending on your API usage, we'll be sending you this email reminder once 
> every 3 days for each token and User-Agent used in API calls made on your 
> behalf.
> Just one URL that was accessed with a token and User-Agent combination will 
> be listed in the email reminder, not all.

> Visit 
> https://developer.github.com/changes/2019-11-05-deprecated-passwords-and-authorizations-api/#authenticating-using-query-parameters
>  for more information.

> Thanks,
> The GitHub Team

I think the code responsible is import/github.scm:159

A tentative fix is attached, but I'm not sure how to test it


Thanks, Nicolò

>From f5f3b4c88dbc18702581e897354ac14a2763c8aa Mon Sep 17 00:00:00 2001
From: nixo 
Date: Wed, 12 Feb 2020 10:34:11 +0100
Subject: [PATCH] try fix github

---
 guix/import/github.scm | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/guix/import/github.scm b/guix/import/github.scm
index df5f6ff32f..54054cb343 100644
--- a/guix/import/github.scm
+++ b/guix/import/github.scm
@@ -150,22 +150,19 @@ empty list."
(github-user-slash-repository url)
"/tags"))
 
-  (define headers
+  (define (headers)
 ;; Ask for version 3 of the API as suggested at
 ;; .
 `((Accept . "application/vnd.github.v3+json")
-  (user-agent . "GNU Guile")))
+  (user-agent . "GNU Guile")
+  ,(when (%github-token)
+ `(Authorization . ,(string-append "token " (%github-token))
 
-  (define (decorate url)
-(if (%github-token)
-(string-append url "?access_token=" (%github-token))
-url))
-
-  (match (json-fetch (decorate release-url) #:headers headers)
+  (match (json-fetch release-url #:headers (headers))
 (#()
  ;; We got the empty list, presumably because the user didn't use GitHub's
  ;; "release" mechanism, but hopefully they did use Git tags.
- (json-fetch (decorate tag-url) #:headers headers))
+ (json-fetch tag-url #:headers (headers)))
 (x x)))
 
 (define (latest-released-version url package-name)
-- 
2.25.0

Re: [rb-general] Quick reproducible test for GNU Guix

[Christopher Baines]

Ludovic Courtès  writes:

>> Eventually, I'd like to do more systematic test of guix packages, with
>> published logs per-package, rather than whatever I happened to build on
>> the system so far, but this was a quick start to help flesh out ideas
>> for feature requests to "guix challenge" to make this all easier... more
>> on that soon!
>
> That’d be great!
>
> Related to that, Christopher Baines developed a nice feature for the
> Guix Data Service during and after the summit: for each Guix revision,
> there’s a page showing the overall package reproducibility status based
> on the info obtained from our two independent build farms.  The URL is
> something like
> 
> (right now it’s empty for some reason, but normally it shows
> identical/different/inconclusive percentages.)

Hey,

This should be back working now. I changed how cross derivations are
stored and handled, and that broke this page. It's now back showing at
least something, but there's still some work to do before it's showing
representative data.

Chris


signature.asc
Description: PGP signature

Re: Mumi service

[Ricardo Wurmus]

Ricardo Wurmus  writes:

> Ludovic Courtès  writes:
>
>> Hi!
>>
>> Ricardo Wurmus  skribis:
>>
>>> Ludovic Courtès  writes:
>>
>> [...]
>>
 However, the currently packaged snapshot crashes when trying to retrieve
 information about a bug:

 --8<---cut here---start->8---
 $ /gnu/store/qw2c84gnwk3sgivh2i8x98xx5gx73vxl-mumi-0.0.0-5.8a57c87/bin/mumi
 GET /issue/22883
 In mumi/web/server.scm:
  38:9 23 (handler _ _ _)
 In mumi/web/controller.scm:
 38:21 22 (render-with-error-handling _ _)
104:21 21 (_)
 In mumi/web/view/html.scm:
274:19 20 (issue-page #)
 In mumi/messages.scm:
185:16 19 (patch-messages 22883)
 In debbugs/soap.scm:
163:19 18 (soap-invoke* # #>>> get-bug-message-numbe…> …)
 157:7 17 (soap-invoke _ _ . _)
 In sxml/simple.scm:
 143:4 16 (xml->sxml _ #:namespaces _ #:declare-namespaces? _ 
 #:trim-whitespace? _ …)
 143:4 15 (loop # () #f _)
 143:4 14 (loop # () #f _)
 143:4 13 (loop # () #f _)
 143:4 12 (loop # () #f _)
 143:4 11 (loop # () #f _)
 143:4 10 (loop # () #f _)
 In sxml/upstream/SSAX.scm:
   1896:21  9 (_ # #f #>>> at sxml/s…> …)
 In sxml/ssax/input-parse.scm:
103:21  8 (next-token _ (#\< #\& #\return) _ _)
 In ice-9/suspendable-ports.scm:
683:15  7 (read-delimited _ _ _)
184:27  6 (fill-input # _ _)
  72:4  5 (read-bytes # #vu8(10 32 98 121 
 32 109 97 …) …)
 In unknown file:
4 (port-read # #vu8(10 32 98 121 32 
 109 97 …) …)
 In web/response.scm:
254:22  3 (read! #vu8(10 32 98 121 32 109 97 105 108 46 109 101 115 115 
 97 103 …) …)
 In ice-9/suspendable-ports.scm:
284:18  2 (get-bytevector-n! # 
 #vu8(10 32 98 …) …)
  72:4  1 (read-bytes # #vu8(10 32 
 98 121 32 …) …)
 In unknown file:
0 (port-read # #vu8(10 32 98 
 121 32 …) …)
 In procedure custom_binary_input_port_read: Value out of range: 1024
 --8<---cut here---end--->8---

 Does that ring a bell, Ricardo?  Should we update to a newer snapshot?
>>>
>>> This is exactly the same bug I hit when using mumi with (fibers web
>>> server).  With just the regular Guile (web server) it works fine but
>>> seemingly leaks file handles until it is restarted.
>>>
>>> I don’t understand this.
>>
>> Could it be that the ‘read!’ procedure of the custom binary input port
>> (CBIP) returned by ‘make-delimited-input-port’ in (web response) returns
>> 1024 when ‘count’ is in fact lower than 1024, or something along these
>> lines?  I would try adding ‘pk’ calls there to display ‘count’ and the
>> return value.
>>
>> If that is true, then maybe the underlying issue is that
>> ‘get-bytevector-n!’ in (ice-9 suspendable-ports) can return a value
>> greater than ‘count’, presumably in the ‘fill-directly’ case.
>>
>> Hmmm!
>
> FWIW, this problem also exists when using Guile 3.0.
>
> I don’t know when it broke, but obviously there was a time (perhaps a
> year ago) when it worked fine.  Curious.

Just FYI: I begin almost every day by logging in to ci.guix.gnu.org to
restart mumi as it has (is is about to) become unusable due to the leak.

It would be good if we could identify and solve the problem.  I suppose
as a first step we would need to monkey patch (web response) in Guile
Debbugs to introduce some instrumentation (i.e. inserting “pk” here and
there).

--
Ricardo