Re: Documentation videos are being uploaded!

2019-05-24 Thread Ricardo Wurmus


Timothy Sample  writes:

>> As regards Paul's voice, I believe it depends on each person. For me
>> it is a little slow but also very clear and kind of calm. And I guess
>> the timing is based on the recordings that I did with my voice, so
>> sorry for that :/
>
> I should be clear that I think Paul did a fantastic job.  (Thanks Paul!)
> The pace in general is quite nice.  Like you say, it is very calm and
> easy to follow.  It was only the URL part that felt a little slow.

I agree with everything you wrote, Tim.  Laura and Paul have done an
excellent job.

When I originally drafted the project I wasn’t sure if and how we’d
bridge the gap between idea and watchable video with narration, but you
worked around all of the little problems that come with translating an
idea into an actual workflow, which is really great.

--
Ricardo




Can the builder access channel code?

2019-05-24 Thread Pierre Neidhardt
Hi,

I'm working on a new build-systems from a channel.
When building a package using this build-system, I get

--8<---cut here---start->8---
building 
/gnu/store/j1qracwgv7qbxslbf6755z8wcwlv3bcf-foobar-qux-hires-2010.drv...
Backtrace:
   4 (primitive-load "/gnu/store/v4yp12m19g3bnn901kxa65xpifp?")
In ice-9/eval.scm:
   191:35  3 (_ #f)
   213:21  2 (_ #f)
   223:20  1 (proc #)
In unknown file:
   0 (%resolve-variable (7 . foobar-build) #)

ERROR: In procedure %resolve-variable:
Unbound variable: foobar-build
builder for 
`/gnu/store/j1qracwgv7qbxslbf6755z8wcwlv3bcf-foobar-qux-hires-2010.drv' failed 
with exit code 1
build of /gnu/store/j1qracwgv7qbxslbf6755z8wcwlv3bcf-foobar-qux-hires-2010.drv 
failed
View build log at 
'/var/log/guix/drvs/j1/qracwgv7qbxslbf6755z8wcwlv3bcf-foobar-qux-hires-2010.drv.bz2'.
guix build: error: build of 
`/gnu/store/j1qracwgv7qbxslbf6755z8wcwlv3bcf-foobar-qux-hires-2010.drv' failed
--8<---cut here---end--->8---

Here is the offending part:

--8<---cut here---start->8---
(define* (foobar-build store name inputs
#:key
(tests? #f)
(build-targets #f)
(phases '(@ (my-guix build foobar-build-system)
%standard-phases))
(outputs '("out"))
(search-paths '())
(system (%current-system))
(guile #f)
(substitutable? #t)
(imported-modules %foobar-build-system-modules)
(modules '((my-guix build foobar-build-system)
   (guix build utils
   ...
--8<---cut here---end--->8---

The default value of the key argument "modules" is the problem.  Is it
possible that the builder cannot find channel modules, or any module out
of the Guix tree?

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


signature.asc
Description: PGP signature


Re: Rust 1.19 fails to build on i686 on ‘staging’

2019-05-24 Thread Danny Milosavljevic
Hi,

can we give thepowersgang (author of mrustc) an ssh account on a guix machine
reachable from the internet, for debugging this problem?

It would be good if "guix build -K" kept the sources on that machine.

Thanks!


pgp_prUbn7rtD.pgp
Description: OpenPGP digital signature


Re: Rust dependency on git

2019-05-24 Thread Marius Bakke
Hi Ivan,

Ivan Petkov  writes:

> Hi Guix,
>
> The latest stable rust (version 1.35.0) appears to require git as a
> native-input since the tidy test (which checks for code formatting in the rust
> repo) fails because it cannot run `git ls-files`.
>
> I saw a comment in the rust package definition that git changes too frequently
> to be kept as an input[1]. Is anyone aware if this is still a problem?
> I'd rather avoid having to patch the test suite tools to ignore this test
> if it is as simple as adding "git" as a native input.

I would prefer to keep Git out of the Rust bootstrap still.  The reason
is that I don't want to rebuild the whole toolchain for every Git update.

Obviously there are other ways to deal with that, so it's not a very
hard opinion.

It seems odd to me that the release tarballs would run 'git ls-files'
anyway.  Do they actually contain a git repository?  Would it work to
simply replace the invokation with 'find'?


signature.asc
Description: PGP signature


Add helper for .desktop file creation?

2019-05-24 Thread Pierre Neidhardt
Hi,

Quite a bunch of packages need to provide their own .desktop since
upstream does not provide them.  It's very evident in games.scm in
particular.

It seems to be a good opportunity to factor this out.  What about the
following?

--8<---cut here---start->8---
(define* (make-desktop-file destination #:key
(encoding "UTF-8")
name
(generic-name name)
comment
exec
icon
(startup-notify "true")
(terminal "false")
(type "Application")
(categories "Application"))
  "Create a desktop file at DESTINATION for executable EXEC with name NAME.
Other arguments are optional."
  (let ((maybe-print (lambda (key value)
   (if value
   (string-append key "=" value "\n")
   ""
(mkdir-p (dirname destination))
(with-output-to-file destination
  (lambda _
(display
 (string-append
  "[Desktop Entry]" "\n"
  "Encoding=" encoding "\n"
  "Name=" name "\n"
  "GenericName=" generic-name "\n"
  (maybe-print "Comment" comment)
  "Exec=" exec "\n"
  (maybe-print "Icon" icon)
  "StartupNotify=" startup-notify "\n"
  "Terminal=" terminal "\n"
  "Type=" type "\n"
  "Categories=" categories "\n"))
--8<---cut here---end--->8---

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


signature.asc
Description: PGP signature