bug#30879: Commit bc499b113 broke guix on guile@2.0.14, improper field initialization

[Ludovic Courtès]

Eric Bavier  skribis:

> On Wed, Mar 21, 2018 at 12:12:02AM +0100, Ludovic Courtès wrote:
>
>> That sounds a lot like regular ABI breakage: a new 
>> field was added but gnu/tests/base.go wasn’t rebuilt, and thus was
>> expecting the previous struct layout.
>> 
>> Does “rm gnu/tests/base.go && make” suffice to fix this issue?
>
> No, it doesn't help.  Previously I had been running "make clean-go"
> before each "make.
>
> The error/backtrace is issued when build-aux/compile-all.scm tries to
> load gnu/tests/base.scm, before it even gets to compilation.

Oh, can you “rm -rf ~/.cache/guile”?

One thing that could be an issue is that (gnu system install) loads
‘examples/bare-bones.tmpl’.  Thus ‘bare-bones.tmpl.go’ ends up in
~/.cache/guile and could be out of sync.

Thanks,
Ludo’.

bug#30820: Chunked store references in compiled code break grafting (again)

[Ludovic Courtès]

Hello,

Ricardo Wurmus  skribis:

>> Good news!  Commit e288572710250bcd2aa0f69ce88154d98ac69b29 adjusts
>> ‘gcc-strmov-store-file-names.patch’ in ‘core-updates’ to correctly deal
>> with this case:
> […]
>> I built everything about to ‘gcc-final’ in ‘core-updates’.  I checked
>> manually that none of the /gnu/store references in libc-2.26.so were
>> chunked.
>
> Wow, thank you so much for fixing this!

It turned out to be easier than the first time.  ;-)

> Is this an option that we can suggest to the GCC developers to
> officially support?

I don’t know, it’s a Guix-specific hack, and just explaining the
rationale to GCC people may be tricky: they’ll think we’re all mad.  ;-)

Ludo’.

bug#30875: Garbage collector may leave empty files

[Ludovic Courtès]

Mark H Weaver  skribis:

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

[...]

>> Are we sure this is a Guix issue and not a disk or file system
>> corruption issue?  The relevant code in guix-daemon hasn’t changed in
>> ages.
>>
>> What file system are you using?  Btrfs?  :-)
>
> The ext[234] filesystems are well known for leaving zero-length files
> around after a crash.  So far, I've never seen Btrfs do that, and I
> wouldn't expect it to based on its design.  That's partly why I switched
> to it.

Sorry, I didn’t mean to imply that Btrfs is flawed.  It’s just that I’ve
never experienced that with ext[234].

Ludo’.

bug#30898: Warning "No such language bytecode" when pulling guix.

[Fis Trivial]

$ guix pull

---
Updating from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
Building from Git commit e2f9847be0d1fcde201b3ec01f68a9cbdda230a0...
The following derivation will be built:
   /gnu/store/15ncl8zii4kvixwyqqm94v6nzvc3j9z4-guix-latest.drv
copying and compiling to 
'/gnu/store/6kp539k2839870w3r7cmg5j8ryj5w98m-guix-latest' with Guile 2.2.3...
loading...   25.8% of 675 filesrandom seed for tests: 1521662834
compiling... 89.9% of 675 filesIn thread:
no such language bytecode
In thread:
In procedure lambda: bad lambda
compiling... 90.1% of 675 filesIn thread:
no such language scheme
compiling... 90.2% of 675 filesIn thread:
no such language scheme
compiling... 90.4% of 675 filesIn thread:
no such language scheme
compiling... 90.5% of 675 filesIn thread:
no such language scheme
compiling... 90.7% of 675 filesIn thread:
no such language scheme
compiling... 90.8% of 675 filesIn thread:
no such language scheme
compiling...100.0% of 675 files

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
updated GNU Guix successfully deployed under `/home/fis/.config/guix/latest'
---

The build was successful, but the I think I should report it for those
error message.


I'm currently runing guix on Fedora 27, x86_64.
This was actually the forth time of successive pull, due to previous
failures, which is mentioned in another bug report[1]:
---
compiling...100.0% of 675 files
Backtrace:
Exception thrown while printing backtrace:
In procedure public-lookup: Module named (system repl debug) does not exist
---

[1]:https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30602

bug#30896: Guix pull problems on armhf

[Jelle Licht]

I have been running the binary Guix installation on top of Armbian 
on my

Rockchip RK3288 (armhf) based computing platform.

Up till about ~8 days ago, guix pull worked as intended. Recently,
running guix pull leads to the following error message
`./guix/build/pull.scm:44:20: ./guix/build/pull.scm:44:20: Throw 
to key

`match-error' with args `("match" "no matching pattern"' [1]


I already checked that re{moving,naming} 
`$HOME/.config/guix/latest'
does not change anything. Neither does running `./pre-inst-env 
guix

pull' from a git checkout.

[1]: For the full log, see: https://paste.debian.net/1015219/

--
Jelle Licht

bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids

[Tobias Geerinckx-Rice]

Vivien,

On 2018-03-21 7:54, Vivien Kraus wrote:

I don't know on what the hash depends; maybe it also depends on the
URL?


It depends only on the contents. This allows us to use a list of 
different URIs (see the lsof package for an example) or try many 
different mirror://s as long as they serve the right file.



Should I change the hash in virtualization.scm?


In general: yes, but not without prior investigation.

The server might be serving a temporary error page instead of a usable 
tarball (SF.net is currently notorious for doing so), or the tarball 
might have been updated in-place (and you'll have to manually diff the 
contents to make sure it's legitimate), or it might just be a problem 
with your network, or...


Pushing a hash update without explanation in the commit message will 
result in lots of spam from people like me. Avoid that.


Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids

[Tobias Geerinckx-Rice]

Vivien,

On 2018-03-21 18:01, Vivien Kraus wrote:

Sorry for the mess with the mails.  This new versions and its hash work
for me, thanks!


I didn't notice a mess :-)

Works here too. Pushed as 0d73f1481bf732147af7751a6ae58114bd3876db.

Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids

[Vivien Kraus]

Hello,

Sorry for the mess with the mails.  This new versions and its hash work
for me, thanks!

Vivien 

Le mercredi 21 mars 2018 à 17:08 +0100, Tobias Geerinckx-Rice a écrit :
> I couldn't resist, of course.
> 
> On 2018-03-21 16:46, Tobias Geerinckx-Rice wrote:
> > I've not actually been following this thread so I don't know what
> > that
> > means, but it looks like simply using the CVS revision as the SVN
> > one
> > might not work.
> 
> The attached patch solves this by simply updating usb.ids to the
> latest 
> revision.
> 
> I'm building it on the slowest laptop I could find.
> 
> Kind regards,
> 
> T G-R
> 
> Sent from a Web browser. Excuse or enjoy my brevity.

bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids

[Tobias Geerinckx-Rice]

Vivien,

On 2018-03-21 12:05, Vivien Kraus wrote:

Could someone confirm this hash?


I can confirm both.


sha256 hash mismatch for output path
`/gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids'
  expected: 17rg5i0wbyk289gr8v4kgvnc9q5bidz7ldcvv9x58l083wn16hq3
  actual:   1wzkaan87ncx80hgddii01cqk5gw8mrm5kb2xf6w9fwa4h53gin5


Here's the beginning of a very long diff between those two:

--- 17rg5i0wbyk289gr8v4kgvnc9q5bidz7ldcvv9x58l083wn16hq3 (old)
+++ 1wzkaan87ncx80hgddii01cqk5gw8mrm5kb2xf6w9fwa4h53gin5 (‘new’)
@@ -1,16 +1,10 @@
 #
 #  List of USB ID's
 #
-#  Maintained by Stephen J. Gowdy 
-#  If you have any new entries, please submit them via
-#  http://www.linux-usb.org/usb-ids.html
-#  or send entries as patches (diff -u old new) in the
-#  body of your email (a bot will attempt to deal with it).
-#  The latest version can be obtained from
-#  http://www.linux-usb.org/usb.ids
+#  Maintained by Vojtech Pavlik 
+#  If you have any new entries, send them to the maintainer.
 #
-# Version: 2017.02.12
-# Date:2017-02-12 20:34:05
+# $Id: usb.ids,v 1.111 2003-01-02 13:05:30 vojtech Exp $

If those dates are at all reliable, we're now downloading a very old 
copy. Which this suggests:


  $ wc -l OLD NEW # ‘NEW’ being SVN upstream
  20663 OLD
   4043 NEW

I've not actually been following this thread so I don't know what that 
means, but it looks like simply using the CVS revision as the SVN one 
might not work.


Kind regards,

T G-R

Sent from a Web browser. Excuse or enjoy my brevity.

bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids

[Vivien Kraus]

Hello,

I have just finished guix pulling again and the hash is not right:

Starting download of /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-
usb.ids
>From https://svn.code.sf.net/p/linux-usb/repo/trunk/htdocs/usb.ids?r=15
51...
following redirection to `http://svn.code.sf.net/p/linux-usb/repo/trunk
/htdocs/usb.ids?p=1551'...
 usb.ids  97KiB   136KiB/s 00:01
[##] 100.0%
sha256 hash mismatch for output path
`/gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids'
  expected: 17rg5i0wbyk289gr8v4kgvnc9q5bidz7ldcvv9x58l083wn16hq3
  actual:   1wzkaan87ncx80hgddii01cqk5gw8mrm5kb2xf6w9fwa4h53gin5
cannot build derivation `/gnu/store/a12yb6kqv3c6s79xf6l448jb4cs8pk7s-
libosinfo-1.0.0.drv': 1 dependencies couldn't be built
guix package: error: build failed: build of
`/gnu/store/a12yb6kqv3c6s79xf6l448jb4cs8pk7s-libosinfo-1.0.0.drv'
failed

Did you have a problem with the hash?

Vivien

Le mercredi 21 mars 2018 à 08:27 +0100, Ricardo Wurmus a écrit :
> Hi,
> 
> I tested the fix and it worked fine for me.
> 
> Fixed in 0def91208 on master.
> 
> Thanks!
> 

bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids

[Vivien Kraus]

Hello,

Thank you for your reply.  This new URL works, but the file version
does not meet the checksum.

Starting download of /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-
usb.ids
>From https://svn.code.sf.net/p/linux-usb/repo/trunk/htdocs/usb.ids?r=15
51...
following redirection to `http://svn.code.sf.net/p/linux-usb/repo/trunk
/htdocs/usb.ids?p=1551'...
 usb.ids  97KiB   0B/s 00:00
[  usb.ids  97KiB   153KiB/s 00:00
[###   usb.ids  97KiB   161KiB/s 00:01
[##] 100.0%
sha256 hash mismatch for output path
`/gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids'
  expected: 17rg5i0wbyk289gr8v4kgvnc9q5bidz7ldcvv9x58l083wn16hq3
  actual:   1wzkaan87ncx80hgddii01cqk5gw8mrm5kb2xf6w9fwa4h53gin5
cannot build derivation `/gnu/store/qgxidn6qahyg52vgyiwjpq3k93kd5msb-
libosinfo-1.0.0.drv': 1 dependencies couldn't be built
guix package: error: build failed: build of
`/gnu/store/qgxidn6qahyg52vgyiwjpq3k93kd5msb-libosinfo-1.0.0.drv'
failed

I don't know on what the hash depends; maybe it also depends on the
URL?  Should I change the hash in virtualization.scm?

Vivien

Le mercredi 21 mars 2018 à 01:19 +0100, Danny Milosavljevic a écrit :
> Hi,
> 
> apparently linux-usb sourceforge switched over to SVN - so what you
> are getting
> there is an error page.
> 
> Possible fix would be:
> 
> diff --git a/gnu/packages/virtualization.scm
> b/gnu/packages/virtualization.scm
> index 55a92eca0..be8a8bb86 100644
> --- a/gnu/packages/virtualization.scm
> +++ b/gnu/packages/virtualization.scm
> @@ -280,7 +280,7 @@ server and embedded PowerPC, and S390 guests.")
> ("usb.ids"
>  ,(origin
> (method url-fetch)
> -   (uri "http://linux-usb.cvs.sourceforge.net/viewvc/linux-u
> sb/htdocs/usb.ids?revision=1.551")
> +   (uri "https://svn.code.sf.net/p/linux-usb/repo/trunk/htdo
> cs/usb.ids?r=1551")
> (file-name "usb.ids")
> (sha256
>  (base32
> 

bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids

[Vivien Kraus]

Hello,

I am not sure that my mails reach debbugs.gnu.org...

When applying the patch in https://debbugs.gnu.org/cgi/bugreport.cgi?bu
g=30890, it still does not work:

Starting download of /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-
usb.ids
>From https://svn.code.sf.net/p/linux-usb/repo/trunk/htdocs/usb.ids?r=15
51...
following redirection to `http://svn.code.sf.net/p/linux-usb/repo/trunk
/htdocs/usb.ids?p=1551'...
 usb.ids  97KiB   136KiB/s 00:01
[##] 100.0%
sha256 hash mismatch for output path
`/gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids'
  expected: 17rg5i0wbyk289gr8v4kgvnc9q5bidz7ldcvv9x58l083wn16hq3
  actual:   1wzkaan87ncx80hgddii01cqk5gw8mrm5kb2xf6w9fwa4h53gin5
cannot build derivation `/gnu/store/a12yb6kqv3c6s79xf6l448jb4cs8pk7s-
libosinfo-1.0.0.drv': 1 dependencies couldn't be built
guix package: error: build failed: build of
`/gnu/store/a12yb6kqv3c6s79xf6l448jb4cs8pk7s-libosinfo-1.0.0.drv'
failed

Could someone confirm this hash?

Thanks,

Vivien

Le mercredi 21 mars 2018 à 00:10 +0100, Vivien Kraus a écrit :
> Hello,
> 
> I tried to install gnome with guix, but it fails when building this:
> 
> Starting download of /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-
> usb.ids
> From http://linux-usb.cvs.sourceforge.net/viewvc/linux-usb/htdocs/usb
> .i
> ds?revision=1.551...
>  ids  4KiB0B/s 00:00
> [ids  4KiB274KiB/s 00:00
> [### ids  4KiB259KiB/s 00:00
> [##] 100.0%
> sha256 hash mismatch for output path
> `/gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids'
>   expected: 17rg5i0wbyk289gr8v4kgvnc9q5bidz7ldcvv9x58l083wn16hq3
>   actual:   10mcg24vdvbbm9lk2scrfs7ff7n2a0dkl2qlkzzllhn53yyrvkc6
> cannot build derivation `/gnu/store/y7ahn1vd09phqxpz5shgwdggl41rd70a-
> libosinfo-1.0.0.drv': 1 dependencies couldn't be built
> cannot build derivation `/gnu/store/9h84d02l7d8n9l0n0mnqj2294nzmk4wk-
> tracker-1.12.3.drv': 1 dependencies couldn't be built
> cannot build derivation `/gnu/store/ckf5yv041kdm0barjv0ksg1hq0hvizy9-
> nautilus-3.26.2.drv': 1 dependencies couldn't be built
> cannot build derivation `/gnu/store/0c0mkrgwrg4v70gn2rrcqrgk6b7l13g3-
> gnome-3.24.3.drv': 1 dependencies couldn't be built
> guix package: error: build failed: build of
> `/gnu/store/0c0mkrgwrg4v70gn2rrcqrgk6b7l13g3-gnome-3.24.3.drv' failed
> 
> What should I do about this?  Should I trust this?  If so, how should
> I
> proceed?
> 
> Regards,
> 
> Vivien
> 
> 
> 

bug#30879: Commit bc499b113 broke guix on guile@2.0.14, improper field initialization

[Eric Bavier]

On Wed, Mar 21, 2018 at 12:12:02AM +0100, Ludovic Courtès wrote:

> That sounds a lot like regular ABI breakage: a new 
> field was added but gnu/tests/base.go wasn’t rebuilt, and thus was
> expecting the previous struct layout.
> 
> Does “rm gnu/tests/base.go && make” suffice to fix this issue?

No, it doesn't help.  Previously I had been running "make clean-go"
before each "make.

The error/backtrace is issued when build-aux/compile-all.scm tries to
load gnu/tests/base.scm, before it even gets to compilation.

-- 
Eric Bavier, Scientific Libraries, Cray Inc.

bug#30776: FVWM provides no .desktop file

[ng0]

宋文武 transcribed 408 bytes:
> ng0  writes:
> 
> > When adding FVWM to the system profile and not using startx or something
> > like adding fvwm execution to the file in $HOME the login manager would
> > source, it does not appear in the selection of window managers to start.
> >
> > We should install a .desktop file for it.
> 
> Hello, as your commit c217df913e00327f5c9b779fd97e222c4c22dab9 had fix
> this, so I close this bug now.  Thanks!

Oops. I intended to add the bug ID to the commit message.
Sorry, I forgot that I had this bug created.

Thanks!
-- 
A88C8ADD129828D7EAC02E52E22F9BBFEE348588
https://n0.is

bug#30776: FVWM provides no .desktop file

[宋文武]

ng0  writes:

> When adding FVWM to the system profile and not using startx or something
> like adding fvwm execution to the file in $HOME the login manager would
> source, it does not appear in the selection of window managers to start.
>
> We should install a .desktop file for it.

Hello, as your commit c217df913e00327f5c9b779fd97e222c4c22dab9 had fix
this, so I close this bug now.  Thanks!

bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids

[Ricardo Wurmus]

Hi Vivien,

> I have just finished guix pulling again and the hash is not right:
>
> Starting download of /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-
> usb.ids
> From https://svn.code.sf.net/p/linux-usb/repo/trunk/htdocs/usb.ids?r=15
> 51...
> following redirection to `http://svn.code.sf.net/p/linux-usb/repo/trunk
> /htdocs/usb.ids?p=1551'...
> usb.ids97KiB136KiB/s 00:01
> [##] 100.0%
> sha256 hash mismatch for output path
> `/gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids'
>  expected: 17rg5i0wbyk289gr8v4kgvnc9q5bidz7ldcvv9x58l083wn16hq3
>  actual:1wzkaan87ncx80hgddii01cqk5gw8mrm5kb2xf6w9fwa4h53gin5
> cannot build derivation `/gnu/store/a12yb6kqv3c6s79xf6l448jb4cs8pk7s-
> libosinfo-1.0.0.drv': 1 dependencies couldn't be built
> guix package: error: build failed: build of
> `/gnu/store/a12yb6kqv3c6s79xf6l448jb4cs8pk7s-libosinfo-1.0.0.drv'
> failed
>
> Did you have a problem with the hash?

Odd.  No, I downloaded it without problems and the hash was fine.  Now I
cannot access the URL any more.  Could it be more problems with
sourceforge (again)?

--
Ricardo

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

bug#30893: report problem: cannot book guixSD from libreboot

[Wensheng Xie]

Dear guix:

I have downloaded:
https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.x86_64-linux.iso.xz

And follow the instruction
https://www.gnu.org/software/guix/manual/html_node/USB-Stick-and-DVD-Installation.html#USB-Stick-and-DVD-Installation
to make the DVD.

The DVD is ok to boot from a normal laptop (without libreboot).
When I insert the DVD to my laptop with libreboot, and reboot to boot
configuration, and select
*Search ISOLINUX menu (CD/DVD) (d)

The laptop does not boot to guixSD, but stays in the boot configuration
menu after reading the DVD. I have got no error message on the display.

So I want you to check if there is a problem.


best regards,
wxie

-- 
I'm an FSF member -- Help us support software freedom!
https://my.fsf.org/join

bug#30890: Hash mismatch for /gnu/store/bvbs19jg8497ca73i82xmrjspd83lvs2-usb.ids

[Ricardo Wurmus]

Hi,

I tested the fix and it worked fine for me.

Fixed in 0def91208 on master.

Thanks!

-- 
Ricardo

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

bug#30395: bug#30820: Chunked store references in compiled code break grafting (again)

[Ricardo Wurmus]

Hi Ludo,

> Good news!  Commit e288572710250bcd2aa0f69ce88154d98ac69b29 adjusts
> ‘gcc-strmov-store-file-names.patch’ in ‘core-updates’ to correctly deal
> with this case:
[…]
> I built everything about to ‘gcc-final’ in ‘core-updates’.  I checked
> manually that none of the /gnu/store references in libc-2.26.so were
> chunked.

Wow, thank you so much for fixing this!

Is this an option that we can suggest to the GCC developers to
officially support?

-- 
Ricardo