bug#26006: [Website] Integral update proposal

[ng0]

Hi,

I don't have very much to comment on, but I just want to express that I
like the Navigation bar and Home page section changes.
On 17-03-06 21:02:39, sirgazil wrote:
> Hi,
> 
> I'd like to propose some changes to the website based on my current 
> perception of it and some comments I've read from users:
> 
> 
> Navigation bar
> ==
> 
> Bar mockup: 
> https://multimedialib.files.wordpress.com/2017/03/guixsd-menu-2017-03-06.png
> 
> The current navigation bar is growing, so I think it may be good to define a 
> style so that people can build more complex menus if necessary (but I hope it 
> won't get too complex).
> 
> I propose the graphic change you see in the mockup—thin black line at the 
> bottom, navigation items are white while idle, and yellow with a black 
> indicator at the bottom when active— as well as the actual items and their 
> ordering.
> 

I like this proposed style and the possibility of sub navigation
items.
 
> 
> Home page
> =
> 
> Home mockup: 
> https://multimedialib.files.wordpress.com/2017/03/guixsd-home-view-2017-03-06.png
> 
> I propose the changes in the mockup above because of the following reasons:
> 
> 1. Some people still confuse Guix with GuixSD.
> 2. Some people still ask if Guix can be used on top of other distributions.
> 3. Some people think pitching GuixSD and Guix to specific crowds is good (of 
> course it is). [1]
> 
> To address the first two points, I changed the order of the content so that 
> information refers to GuixSD first, Guix as a part of it, and then added a 
> section that mentions specifically the use of Guix in other distros.
> 
> For point three, I added a section that links to blog posts that explain 
> GuixSD and Guix in the context of a particular field (this part requires the 
> current News pages to become a Blog instead. See below).
> 
> Finally, Ricardo Wurmus commented that there were too many styles of buttons, 
> and I agree with him, so I made them homogeneous.
> 

This is very good!

> News pages
> ==
> 
> News list mockup: 
> https://multimedialib.files.wordpress.com/2017/03/guixsd-blog-list-2017-03-06.png
> News details mockup: 
> https://multimedialib.files.wordpress.com/2017/03/guixsd-blog-post-2017-03-06.png
> 
> I suggest to convert News into a blog instead. This could make it easier to 
> add information targeted at different audiences without making the website 
> more complex. Additionally, we could move to the blog content like talks, 
> papers, and posts currently listed in the Help page.

Good idea!

> I remember that Ludovic commented in #guix that he would like a better way to 
> display talks in the website... [2] With the design in the mockup above, you 
> just click on the "Talks" tag, and you have a nice preview and summary of all 
> talks.
> 
> Also, Haunt, the current static site generator used to build the website, can 
> create an atom feed for every tag in the blog, so people can subscribe to 
> whatever topic is more interesting to them. Personally, I'd like to subscribe 
> to a "Security" feed to keep informed about important security updates (see 
> bug #25852). [3]
> 
> 
> Packages pages
> ==
> 
> Package list mockup: 
> https://multimedialib.files.wordpress.com/2017/03/guixsd-package-list-2017-03-06.png
> Package details mockup: 
> https://multimedialib.files.wordpress.com/2017/03/guixsd-package-detail-2017-03-06.png

If single packages could have a page or some unique link (similar to
what debian, archlinux, Gentoo etc does), this would be THE solution
for upstreams who link to the sourcecode in cgit instead currently.

I like the style!

> I actually proposed this update in bug #25227,[4] but decided to review the 
> whole website design, so I put it here for reference.
> 
> 
> Help page
> =
> 
> * Move talks, papers, and posts to the Blog.
> * Allow little boxes to be distributed along the whole width of the screen.
> 
> 
> Contribute page
> ===
> 
> * Allow little boxes to be distributed along the whole width of the screen.
> 
> 
> Infrastructure
> ==
> 
> Personally, I'd like to be able to access the website at "guixsd.org", and 
> use a git repository for deployment of the static website.
> 
> However, we are currently using the resources provided by Savannah for 
> hosting, which means we have to use a CVS repository to deploy the website. 
> As mentioned in bug #25227, using CVS could block the implementation of the 
> packages pages as shown in the mockups above (and maybe filtering blog posts 
> by tag) because CVS could choke on the thousands of pages that would be 
> generated (if we keep using a static website).
> 
> To find a solution to this issue, Ludovic sent an email to Savannah admins 
> asking for the possibility of using a dynamic website instead. I don't 
> remember if there was an answer.
> 
> And that's all I'd like to modify regarding the current website.
> 
> What do you think?
> 
> 
> [1]: https://lists.gnu.org

bug#25852: Users not updating their installations of Guix

[Ludovic Courtès]

Mark H Weaver  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Leo Famulari  skribis:
>>
>>> In my opinion, the recent bug #25775 (Can't install packages after guix
>>> pull) [0] exposed a sort of meta-bug: there are a significant number of
>>> users who were still using the guix-daemon from 0.10.0.
>>>
>>> It seems unlikely that they have been updating all of root's
>>> packages except for the guix package. Rather, I bet they never updated
>>> root's packages at all, for ~1 year.
>>>
>>> I think this is a serious documentation bug.
>>
>> I’m not sure documentation would help.
>>
>> Software like Firefox handles that by calling home to know its latest
>> version, but I’m not sure we want to have that happen automatically.
>>
>> Thoughts on how we could address this?
>
> We could simply issue a warning if the version of guix currently in use
> is more than N hours old, on the assumption that after N hours it's
> likely to be stale.  The default value of N might be in the range 48-96
> (2-4 days).  A quick perusal through the recent commit log on our master
> branch indicates that it's quite rare for 4 days to pass without a
> security update.
>
> What do you think?

That sounds like an easy and reasonable approach.

I wonder what would be the best place to emit this warning.  Upon ‘guix
package -i’ maybe?

Ludo’.

bug#25882: gcc-wrapper doesn't handle response files

[Ludovic Courtès]

Federico Beffa  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Federico Beffa  skribis:
>>
>>> gcc-wrapper doesn't handle compiler/linker flags passed through
>>> response files.
>>>
>>> One package which recently started using such files is GHC (I believe
>>> since 7.10.3).  For this reason we currently need to patch it.
>>> However, the problem is with our tool chain wrapper and not with GHC
>>> itself.
>>>
>>> See discussion at
>>> https://lists.gnu.org/archive/html/guix-devel/2017-01/msg01981.html
>>
>> Given that the GHC patch is so small, I have a slight preference for
>> keeping ld-wrapper unchanged and using the GHC patch.  To put it
>> differently, the GHC patch is smaller and less error-prone than the
>> changes that would need to be made in ld-wrapper.
>
> I don't think that it is a good idea because any upstream change around
> that code will break our package again and, going forward, we may find
> other pieces of software making use of this gcc feature.  The patch is
> small, but the effort to find it wasn't.
>
> I like to fix things where the problem is, not working around it.

On closer inspection, it’s an easy change to make.

Could you test the attached patch with GHC?

The way I would test it without rebuilding the world is by copying the
new ld-wrapper.in to ld-wrapper2.in (and thus keeping ld-wrapper.in
unchanged), and then adding it as an input to GHC (via
‘make-ld-wrapper’).  Commit 77db91addc57faa000db05563820f57a9ffdedfc
might serve as an example.

Thanks,
Ludo’.

diff --git a/gnu/packages/ld-wrapper.in b/gnu/packages/ld-wrapper.in
index ebfd8332c..ff086154a 100644
--- a/gnu/packages/ld-wrapper.in
+++ b/gnu/packages/ld-wrapper.in
@@ -15,7 +15,7 @@ main="(@ (gnu build-support ld-wrapper) ld-wrapper)"
 exec @GUILE@ -c "(load-compiled \"@SELF@.go\") (apply $main (cdr (command-line)))" "$@"
 !#
 ;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2012, 2013, 2014, 2015, 2016 Ludovic Courtès 
+;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017 Ludovic Courtès 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -35,6 +35,7 @@ exec @GUILE@ -c "(load-compiled \"@SELF@.go\") (apply $main (cdr (command-line))
 (define-module (gnu build-support ld-wrapper)
   #:use-module (srfi srfi-1)
   #:use-module (ice-9 match)
+  #:autoload   (ice-9 rdelim) (read-string)
   #:export (ld-wrapper))
 
 ;;; Commentary:
@@ -222,9 +223,28 @@ impure library ~s~%"
   '()
   library-files))
 
+(define (expand-arguments args)
+  ;; Expand ARGS such that "response file" arguments, such as "@args.txt", are
+  ;; expanded.  See 'expandargv' in libiberty.
+  (define (response-file-arguments file)
+(when %debug?
+  (format (current-error-port)
+  "ld-wrapper: reading arguments from '~a'~%" file))
+(string-tokenize (call-with-input-file file read-string)))
+
+  (fold-right (lambda (arg result)
+(if (string-prefix? "@" arg)
+(let ((file (string-drop arg 1)))
+  (append (response-file-arguments file)
+  result))
+(cons arg result)))
+  '()
+  args))
+
 (define (ld-wrapper . args)
   ;; Invoke the real `ld' with ARGS, augmented with `-rpath' switches.
-  (let* ((path (library-search-path args))
+  (let* ((args (expand-arguments args))
+ (path (library-search-path args))
  (libs (library-files-linked args path))
  (args (append args (rpath-arguments libs
 (when %debug?

bug#26008: ‘guix offload test’ provides insufficient details upon failure

[Ludovic Courtès]

See message below.

--- Begin Message ---
Hi Ludo',

on [2017-03-06] at 10:52 Ludovic Courtès writes:

> Myles English  skribis:
>
>> Two hosts, setup the same as far as I can see, behave differently when
>> trying to offload builds, any idea how I can get more information on
>> what the # might indicate?  Looking at
>> guix/scripts/offload.scm:551 suggests the result is not a string.
>>
>> $ guix offload test
>> guix offload: testing 2 build machines defined in '/etc/guix/machines.scm'...
>> guix offload: 'host1.mydomain.co.uk' is running guile (GNU Guile) 2.0.13
>> guix offload: 'host2.mydomain.co.uk' is running guile (GNU Guile) 2.0.13
>> guix offload: Guix is usable on 'host1.mydomain.co.uk' (test returned 
>> "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
>> guix offload: error: failed to use Guix module on 'host2.mydomain.co.uk'
>> (test returned #)
>
> What you see here most likely means that host2 threw an exception while
> executing this code:
>
>   http://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/offload.scm#n543
>
> The reason could be:
>
>   1. That the (guix …) modules could not be found in the search path
>  (your tests suggest this is not the case);
>
>   2. That an exception was thrown, for instance because the ‘with-store’
>  form failed to connect to the daemon on that machine (is the daemon
>  running on that machine? Is it listening on
>  /var/guix/daemon-socket/socket and not some other place?).

Yes, that was probably the problem.  I have since updated the host
systems, rebooted, restarted the daemons and now it works, thanks.

> We should definitely improve that and provide details about the
> exception, at least.

Yes, I agree, because 'guix offload test' should provide useful details
when it fails and not just when it succeeds.

Myles
--- End Message ---

bug#26006: [Website] Integral update proposal

[Catonano]

Overall, I like all your proposals.

The one I like best is the proposal about packages. I hope I won't hurt
your feelings if I state that the new layout makes the packages thing
somewhat similar to the "Software" application in Fedora.
And I think that a degree of resemblance is good both for GuixSD and for
the users.

Too bad there's this roadblock due to csv but I really can't help with that

Thanks for your work !

bug#25953: [PATCH] gnu: mesa: Build LLVM Gallium drivers.

[Ricardo Wurmus]

Mark H Weaver  writes:

> Ricardo Wurmus  writes:
>
>> Fixes .
>>
>> * gnu/packages/gl.scm (mesa)[inputs]: Add llvm.
>> [arguments]: Build LLVM Gallium drivers.
>
> I'm uncomfortable adding llvm as a requirement for our most minimal X11
> system, for several reasons.  Can we find a way to make this optional?

Would it make sense to add a “mesa-minimal” package and a minimal
variant of xorg-server where any mesa package is rewritten to be
mesa-minimal?

--
Ricardo

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

bug#26006: [Website] Integral update proposal

[Ludovic Courtès]

Hello sirgazil!

It’s always a pleasure to read you.  :-)  Basically, I like all of your
proposals.  Some comments below.

sirgazil  skribis:

> Navigation bar
> ==
>
> Bar mockup: 
> https://multimedialib.files.wordpress.com/2017/03/guixsd-menu-2017-03-06.png
>
> The current navigation bar is growing, so I think it may be good to define a 
> style so that people can build more complex menus if necessary (but I hope it 
> won't get too complex).
>
> I propose the graphic change you see in the mockup—thin black line at the 
> bottom, navigation items are white while idle, and yellow with a black 
> indicator at the bottom when active— as well as the actual items and their 
> ordering.

Very good idea, definitely an improvement.

> Home page
> =
>
> Home mockup: 
> https://multimedialib.files.wordpress.com/2017/03/guixsd-home-view-2017-03-06.png
>
> I propose the changes in the mockup above because of the following reasons:
>
> 1. Some people still confuse Guix with GuixSD.
> 2. Some people still ask if Guix can be used on top of other distributions.
> 3. Some people think pitching GuixSD and Guix to specific crowds is good (of 
> course it is). [1]
>
> To address the first two points, I changed the order of the content so that 
> information refers to GuixSD first, Guix as a part of it, and then added a 
> section that mentions specifically the use of Guix in other distros.
>
> For point three, I added a section that links to blog posts that explain 
> GuixSD and Guix in the context of a particular field (this part requires the 
> current News pages to become a Blog instead. See below).
>
> Finally, Ricardo Wurmus commented that there were too many styles of buttons, 
> and I agree with him, so I made them homogeneous.

Agreed.

> News pages
> ==
>
> News list mockup: 
> https://multimedialib.files.wordpress.com/2017/03/guixsd-blog-list-2017-03-06.png
> News details mockup: 
> https://multimedialib.files.wordpress.com/2017/03/guixsd-blog-post-2017-03-06.png
>
> I suggest to convert News into a blog instead. This could make it easier to 
> add information targeted at different audiences without making the website 
> more complex. Additionally, we could move to the blog content like talks, 
> papers, and posts currently listed in the Help page.

Sounds great.

> I remember that Ludovic commented in #guix that he would like a better way to 
> display talks in the website... [2] With the design in the mockup above, you 
> just click on the "Talks" tag, and you have a nice preview and summary of all 
> talks.

Yes!  There’s also the question of how much work it’ll be to maintain
the talks part (like whether we need to manually make “posters” for each
video and so on.)  The less work, the better.

At the same time, we should reach out to people who’d like to contribute
to Guix in a less-technical way.  There’s a lot that could be done to
keep the web site lively, and it would be great to let more people take
care of that.

> Also, Haunt, the current static site generator used to build the website, can 
> create an atom feed for every tag in the blog, so people can subscribe to 
> whatever topic is more interesting to them. Personally, I'd like to subscribe 
> to a "Security" feed to keep informed about important security updates (see 
> bug #25852). [3]

I agree, we should use tags.  A first step will be to add tags to the
existing posts.

> Packages pages
> ==
>
> Package list mockup: 
> https://multimedialib.files.wordpress.com/2017/03/guixsd-package-list-2017-03-06.png
> Package details mockup: 
> https://multimedialib.files.wordpress.com/2017/03/guixsd-package-detail-2017-03-06.png
>
> I actually proposed this update in bug #25227,[4] but decided to review the 
> whole website design, so I put it here for reference.

There’s still the issue that we don’t have screenshots, but other than
that it looks great.

> Help page
> =
>
> * Move talks, papers, and posts to the Blog.
> * Allow little boxes to be distributed along the whole width of the screen.

Good.

> Contribute page
> ===
>
> * Allow little boxes to be distributed along the whole width of the screen.
>
>
> Infrastructure
> ==
>
> Personally, I'd like to be able to access the website at "guixsd.org", and 
> use a git repository for deployment of the static website.
>
> However, we are currently using the resources provided by Savannah for 
> hosting, which means we have to use a CVS repository to deploy the website. 
> As mentioned in bug #25227, using CVS could block the implementation of the 
> packages pages as shown in the mockups above (and maybe filtering blog posts 
> by tag) because CVS could choke on the thousands of pages that would be 
> generated (if we keep using a static website).
>
> To find a solution to this issue, Ludovic sent an email to Savannah admins 
> asking for the possibility of using a dynamic website instead. I don't 
> remember if there was an answer.

bug#25976: man page version is outdated in Guix 0.12.0 tarball

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Now that I think of it, could it be that Ricardo didn’t have help2man
> installed when building the tarball?  Man pages get rebuilt anytime it’s
> needed here.

This could have been the case.  I don’t usually have it installed.
Sorry for screwing this up!

--
Ricardo

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

bug#25852: Users not updating their installations of Guix

[Leo Famulari]

On Tue, Mar 07, 2017 at 07:33:30AM +0100, Tomáš Čech wrote:
> On Mon, Mar 06, 2017 at 04:34:34PM -0500, Leo Famulari wrote:
> > On Mon, Mar 06, 2017 at 10:12:21PM +0100, Ludovic Courtès wrote:
> > > Leo Famulari  skribis:
> > > 
> > > > In my opinion, the recent bug #25775 (Can't install packages after guix
> > > > pull) [0] exposed a sort of meta-bug: there are a significant number of
> > > > users who were still using the guix-daemon from 0.10.0.
> > > >
> > > > It seems unlikely that they have been updating all of root's
> > > > packages except for the guix package. Rather, I bet they never updated
> > > > root's packages at all, for ~1 year.
> > 
> > They could have been stuck with an old daemon if they copied the systemd
> > or upstart service files we provide.
> > 
> > That problem should be fixed by 613d0895b92c677e0639d5e77c55043e38e020c8
> > (build: Don't embed absolute paths in .service and .conf service
> > files.).
> 
> That is right. But
> 
> 1) there was no release with this "fix"
> 2) I (as distro package maintainer) didn't take this patch manually as
>   it is fragile and hacky. Have you considered fresh guix installation?

This will take effect for the next release of Guix; it addresses a
problem that arises when somebody installs the binary release of Guix.

I'm not addressing downstream packages of Guix with this commit.


signature.asc
Description: PGP signature

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

On Tue, Mar 07, 2017 at 02:51:18PM -0500, Leo Famulari wrote:

On Tue, Mar 07, 2017 at 07:33:30AM +0100, Tomáš Čech wrote:

On Mon, Mar 06, 2017 at 04:34:34PM -0500, Leo Famulari wrote:
> On Mon, Mar 06, 2017 at 10:12:21PM +0100, Ludovic Courtès wrote:
> > Leo Famulari  skribis:
> >
> > > In my opinion, the recent bug #25775 (Can't install packages after guix
> > > pull) [0] exposed a sort of meta-bug: there are a significant number of
> > > users who were still using the guix-daemon from 0.10.0.
> > >
> > > It seems unlikely that they have been updating all of root's
> > > packages except for the guix package. Rather, I bet they never updated
> > > root's packages at all, for ~1 year.
>
> They could have been stuck with an old daemon if they copied the systemd
> or upstart service files we provide.
>
> That problem should be fixed by 613d0895b92c677e0639d5e77c55043e38e020c8
> (build: Don't embed absolute paths in .service and .conf service
> files.).

That is right. But

1) there was no release with this "fix"
2) I (as distro package maintainer) didn't take this patch manually as
  it is fragile and hacky. Have you considered fresh guix installation?


This will take effect for the next release of Guix; it addresses a
problem that arises when somebody installs the binary release of Guix.

I'm not addressing downstream packages of Guix with this commit.


I'm sorry, I may not understand correctly your answer.

Are you saying that situation when user freshly installs Guix on
system with systemd (and thus has empty /gnu/store)?

S_W



signature.asc
Description: Digital signature

bug#25865: xinit does not allow non-root startx

[Ludovic Courtès]

Hello,

Alex Vestgaard  skribis:

> xinit suffers from an upstream bug, which does not allow non-root X to be run 
> without a display manager via startx or xinitrc. Several people have reported 
> this on #guix.
>
> Currently if one runs startx as non-root, X reports:
> (EE) parse_vt_settings: Cannot open /dev/tty0 (Permission denied)
>
> This bug is further discussed in [1]. Redhat seems to have a patch [2], but 
> it is unclear to me whether this has been applied upstream.
>
> [1] https://bugs.launchpad.net/ubuntu/+source/xinit/+bug/1562219
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1203780

Did you have a change to try Red Hat’s patch?  It could be a good
starting point.

Thanks for your report,
Ludo’.

bug#25752: go incremental builds broken

[Ludovic Courtès]

Hello,

Hank Donnay  skribis:

> The function for determining staleness is here (after the giant
> comment explaining the reasoning):
> https://golang.org/src/cmd/go/pkg.go#L

This method relies on the build ID to, which is defined like this (info
"(ld) Options"):

  `--build-id'
  `--build-id=STYLE'
   Request the creation of a `.note.gnu.build-id' ELF note section or
   a `.buildid' COFF section.  The contents of the note are unique
   bits identifying this linked file.  STYLE can be `uuid' to use 128
   random bits, `sha1' to use a 160-bit SHA1 hash on the normative
   parts of the output contents, `md5' to use a 128-bit MD5 hash on
   the normative parts of the output contents, or `0xHEXSTRING' to
   use a chosen bit string specified as an even number of hexadecimal
   digits (`-' and `:' characters between digit pairs are ignored).
   If STYLE is omitted, `sha1' is used.

   The `md5' and `sha1' styles produces an identifier that is always
   the same in an identical output file, but will be unique among all
   nonidentical output files.  It is not intended to be compared as a
   checksum for the file's contents.  A linked file may be changed
   later by other tools, but the build ID bit string identifying the
   original linked file does not change.

   Passing `none' for STYLE disables the setting from any
   `--build-id' options earlier on the command line.

I suppose Go uses one of md5 or sha1, which is a good thing since it
allows for reproducible builds.

However, grafting breaks this, similarly to 
since they change file contents without recomputing the build ID.

Having Go use --build-id=uuid would work around the problem, but it
would also prevent bit-reproducible builds.

Perhaps our grafting code will have to handle .note.gnu.build-id
specially.

Thoughts?

Thanks for reporting the issue,
Ludo’.

bug#19973: Grafts break debug outputs

[Ludovic Courtès]

Mark H Weaver  skribis:

> mhw@jojen:~$ guix build guile
> guix build: warning: ambiguous package specification `guile'
> guix build: warning: choosing guile-2.0.11 from gnu/packages/guile.scm:110:2
> /gnu/store/3lhr8q28q6f59774di9av7ncy09jd55d-guile-2.0.11
> /gnu/store/rgv3fvy6xqp6966rfh8v6fv7m48abcbh-guile-2.0.11-debug
> mhw@jojen:~$ guix package -I guile
> guile 2.0.11  out /gnu/store/3lhr8q28q6f59774di9av7ncy09jd55d-guile-2.0.11
> guile 2.0.11  debug   
> /gnu/store/rgv3fvy6xqp6966rfh8v6fv7m48abcbh-guile-2.0.11-debug
> mhw@jojen:~$ ls -l .guix-profile/lib/debug/gnu/store/
> total 8
> lrwxrwxrwx 12 root guixbuild 128 Dec 31  1969 
> 122jv790mv2mlnylbrbzav65vghbw93n-guile-2.0.11 -> 
> /gnu/store/rgv3fvy6xqp6966rfh8v6fv7m48abcbh-guile-2.0.11-debug/lib/debug/gnu/store/122jv790mv2mlnylbrbzav65vghbw93n-guile-2.0.11
> lrwxrwxrwx 15 root guixbuild 127 Dec 31  1969 
> 3g20rdmnavpblsmgppyl8jhg67nidhjk-glibc-2.20 -> 
> /gnu/store/hrny2whqg9c3m0klyfpbmmcyiir9yf8m-gcc-toolchain-4.9.2/lib/debug/gnu/store/3g20rdmnavpblsmgppyl8jhg67nidhjk-glibc-2.20
>
> I guess GDB can't find the debugging information because
> 122jv790mv2mlnylbrbzav65vghbw93n-guile-2.0.11 is the name of the guile
> directory *before* grafting.

I wonder if the problem you described here still exists today.

However, one very likely problem is that .debug files include a CRC of
the binary they correspond to (info "(gdb) Separate Debug Files"), and
that CRC is not updated when we graft things.

We could change our grafting code to specifically address this problem
(using (guix elf) & co.).

Similar issue with build IDs: .

Ludo’.

bug#25852: Users not updating their installations of Guix

[Leo Famulari]

On Tue, Mar 07, 2017 at 09:58:48PM +0100, Tomáš Čech wrote:
> On Tue, Mar 07, 2017 at 02:51:18PM -0500, Leo Famulari wrote:
> > This will take effect for the next release of Guix; it addresses a
> > problem that arises when somebody installs the binary release of Guix.
> > 
> > I'm not addressing downstream packages of Guix with this commit.
> 
> I'm sorry, I may not understand correctly your answer.
> 
> Are you saying that situation when user freshly installs Guix on
> system with systemd (and thus has empty /gnu/store)?

The "fix" I pushed will help anyone who does a new installation of Guix
on a Systemd or Upstart-based system, after the next release of Guix.

Specifically, it is meant to address the issue described here:

http://lists.gnu.org/archive/html/guix-devel/2017-01/msg01199.html

This change won't help anyone who already is affected by that issue.

I view it as one small step towards making it probable that users will
keep their their Guix installations up to date.


signature.asc
Description: PGP signature

bug#25775: Attempts to fix bootstrap Guile bug

[Ludovic Courtès]

Hello,

Thanks Andy & Ricardo for the detailed explanations!

Andy Wingo  skribis:

> It seems that this bug is related to the introduction of
> url-fetch/reset-patch-level.  It takes a #:guile kwarg but defaults to
> #f; if not given #:guile, that #f propagates through instead of a
> package object.

Nasty.

To reproduce the problem reported here, one can:

  1. Revert the “band-aid commit”
 9f05908fb1e3707cae593d94688748294717a546.

  2. Change download.scm to force it to behave as when talking to an old
 daemon.

This gives this:

diff --git a/guix/download.scm b/guix/download.scm
index 86f859881..811abe27b 100644
--- a/guix/download.scm
+++ b/guix/download.scm
@@ -418,10 +418,7 @@ GnuTLS itself and its dependencies.  See ."
;; hash of the expected result.
#:verify-certificate? #f)
 
-  (mlet %store-monad ((guile (package->derivation
-  (or guile
-  (@@ (gnu packages bootstrap) %bootstrap-guile))
-  system)))
+  (mlet %store-monad ((guile (package->derivation guile system)))
 (gexp->derivation file-name builder
   #:guile-for-build guile
   #:system system
@@ -472,7 +469,7 @@ in the store."
 (and uri (memq (uri-scheme uri) '(#f file
 (interned-file (if uri (uri-path uri) url)
(or name file-name))
-(mlet* %store-monad ((builtins (built-in-builders*))
+(mlet* %store-monad ((builtins -> '())
  (download -> (if (member "download" builtins)
   built-in-download
   in-band-download)))

Then run something like:

  guix gc -d /gnu/store/*-bash-4.4.tar.xz
  ./pre-inst-env guix build bash -S --no-substitutes

~~

To mirror what ‘url-fetch’ does, we should change the default value of
#:guile here:

diff --git a/gnu/packages/bash.scm b/gnu/packages/bash.scm
index c3b94391e..b4d0b6777 100644
--- a/gnu/packages/bash.scm
+++ b/gnu/packages/bash.scm
@@ -243,7 +243,8 @@ without modification.")
 
 (define* (url-fetch/reset-patch-level url hash-algo hash
   #:optional name
-  #:key (system (%current-system)) guile)
+  #:key (system (%current-system))
+  (guile (default-guile)))
   "Fetch the Bash patch from URL and reset its 'PATCHLEVEL' definition so it
 can apply to a patch-level 0 Bash."
   (mlet* %store-monad ((name -> (or name (basename url)))

However that leads to a stack overflow unless we patch
‘bootstrap-origin’ the way Andy suggests (which is not desirable IMO).

So, instead, we can simply force the use of the bootstrap Guile for
these derivations, which doesn’t make any difference functionally:

--- a/gnu/packages/bash.scm
+++ b/gnu/packages/bash.scm
@@ -21,6 +21,7 @@
 (define-module (gnu packages bash)
   #:use-module (guix licenses)
   #:use-module (gnu packages)
+  #:use-module (gnu packages bootstrap)
   #:use-module (gnu packages ncurses)
   #:use-module (gnu packages readline)
   #:use-module (gnu packages bison)
@@ -243,14 +244,17 @@ without modification.")
 
 (define* (url-fetch/reset-patch-level url hash-algo hash
   #:optional name
-  #:key (system (%current-system)) guile)
+  #:key (system (%current-system)))
   "Fetch the Bash patch from URL and reset its 'PATCHLEVEL' definition so it
 can apply to a patch-level 0 Bash."
+  ;; Note: Forcefully use %BOOTSTRAP-GUILE here to work around bootstrapping
+  ;; issues when using a daemon that lacks the "download" built-in.  See
+  ;; .
   (mlet* %store-monad ((name -> (or name (basename url)))
(patch (url-fetch url hash-algo hash
  (string-append name ".orig")
  #:system system
- #:guile guile)))
+ #:guile %bootstrap-guile)))
 (gexp->derivation name
   (with-imported-modules '((guix build utils))
 #~(begin
@@ -259,7 +263,6 @@ can apply to a patch-level 0 Bash."
 (substitute* #$output
   (("PATCHLEVEL [0-6]+")
"PATCHLEVEL 0"
-  #:guile-for-build guile
   #:system system)))
 
 (define bash/fixed;CVE-2017-5932 (RCE with completion)

And it does the job.

Pushed as 6c5b56f9fa01b7fe9034bac47b20e08a2fdb2629.  Let me know if
there are still fishy things!

Ludo’.

bug#25852: Users not updating their installations of Guix

[Tomáš Čech]

On Tue, Mar 07, 2017 at 05:22:15PM -0500, Leo Famulari wrote:

On Tue, Mar 07, 2017 at 09:58:48PM +0100, Tomáš Čech wrote:

On Tue, Mar 07, 2017 at 02:51:18PM -0500, Leo Famulari wrote:
> This will take effect for the next release of Guix; it addresses a
> problem that arises when somebody installs the binary release of Guix.
>
> I'm not addressing downstream packages of Guix with this commit.

I'm sorry, I may not understand correctly your answer.

Are you saying that situation when user freshly installs Guix on
system with systemd (and thus has empty /gnu/store)?


The "fix" I pushed will help anyone who does a new installation of Guix
on a Systemd or Upstart-based system, after the next release of Guix.


Unless I'm missing some other commit, this won't work.

When I perform these steps:
1] ./configure && make && sudo make install (or package installation)
2] mkdir /gnu/store
3] attempt to start daemon will fail as there is no guix-daemon in
  @localstatedir@/guix/profiles/per-user/root/guix-profile/bin/guix-daemon
  because there is no guix-daemon in /gnu/store

Without daemon running you won't be able to make one in that location.

Dead end.

Best regards,

S_W


signature.asc
Description: Digital signature