Re: [outreachy] am I in the right track to contribute

[Laura Lazzati]

On Fri, Oct 12, 2018 at 3:31 AM Gábor Boskovits  wrote:
>
> Hello Laura,
>
> Laura Lazzati  ezt írta (időpont: 2018.
> okt. 11., Cs, 21:58):
> >
> > On Thu, Oct 11, 2018 at 2:05 PM Gábor Boskovits  wrote:
> > >
> > > Hello Laura,
> > >
> > > Laura Lazzati  ezt írta (időpont: 2018.
> > > okt. 11., Cs, 16:32):
> > > >
> > > > On Thu, Oct 11, 2018 at 6:24 AM Gábor Boskovits  
> > > > wrote:
> > > > >
> > > > > Hello Laura,
> > > > >
> > > > > Laura Lazzati  ezt írta (időpont: 2018. 
> > > > > okt. 11., Cs, 3:25):
> > > > > >
> > > > > > On Wed, Oct 10, 2018 at 3:12 PM Gábor Boskovits 
> > > > > >  wrote:
> > > > > > >
> > > > > > >
> > > > > > > Hello Laura,
> > > > > > >
> > > > > > > Laura Lazzati  ezt írta (időpont: 
> > > > > > > 2018. okt. 10., Sze 18:41):
> > > > > > >>
> > > > > > >> On Tue, Oct 9, 2018 at 1:17 PM Björn Höfling
> > > > > > >>  wrote:
> > > > > > >> >
> > > > > > >> > Hi Laura,
> > > > > > >> >
> > > > > > >> > On Tue, 9 Oct 2018 10:08:44 -0300
> > > > > > >> > Laura Lazzati  wrote:
> > > > > > >> >
> > > > > > >> > > Hi everyone!
> > > > > > >> > >
> > > > > > >> > > I don't know if is it OK to be telling you what I am/ I've 
> > > > > > >> > > been doing
> > > > > > >> > > these days, I kind of like doing so to have feedback, and 
> > > > > > >> > > also to let
> > > > > > >> > > you know
> > > > > > >> >
> > > > > > >> > This is exactly the way to go! It's good to hear where you 
> > > > > > >> > stay, what
> > > > > > >> > you tried, where you succeeded, where you got stuck. If you 
> > > > > > >> > get stuck,
> > > > > > >> > tell us about the paths you already tried out and why you 
> > > > > > >> > don't get
> > > > > > >> > further alone.
> > > > > > >> >
> > > > > > >> Sorry for being absent for a day. After updating and upgrading my
> > > > > > >> computer, I am stuck trying to see why the sound stopped 
> > > > > > >> working. Yes,
> > > > > > >> this kind of thinks happen but just now?
> > > > > > >
> > > > > > >
> > > > > > > No worries, one day off is perfectly ok, however if you did not 
> > > > > > > get an answer in 3 or 4 days, then please contact us, since in 
> > > > > > > that case there is some communications mistake.
> > > > > > > Last time losing sound happened to me after a dist-upgrade in 
> > > > > > > ubuntu, and turned out, that the pulseaudio package shipped with 
> > > > > > > a configuration that was not compatible with the version of the 
> > > > > > > binaries supplied. I ran it in the foreground, and in the startup 
> > > > > > > messages or in the log I found that it could not parse the 
> > > > > > > config. It can be something entirely different though. I hope 
> > > > > > > this helps.
> > > > > >
> > > > > > Thanks :) Unluckily i made a mistake and ended up needing  a fresh
> > > > > > install. But I am the kind of person that always has data backup and
> > > > > > is aware of the software and utilities that needs. Tomorrow I will 
> > > > > > go
> > > > > > on with my VMs, the one with only Guix, and one with GuixSD and 
> > > > > > start
> > > > > > with the package stuff, so that I can contribute as much as I can,
> > > > > > even if I am not chosen for outreachy.
> > > > >
> > > > > Sorry to hear that, but glad that you did not suffer any data loss.
> > > > > Having the VMs back by tomorrow is nice, thanks for the update.
> > > > Luckily yesterday I ended up late at night and found that I could
> > > > import my VM with Ubuntu guest with guix running. I do have a
> > > > question. I use Virtualbox, and Downloaded the .iso file of GuixSD, I
> > > > have just installed the VM for GuixSD in VirtualBox - I read that in
> > > > the documentation it is mentioned to use quemu- but strangely I
> > > > managed to install it without any problems in VirtualBox with the .iso
> > > >  I made the internet connection work, because the interfacewas down,
> > > > running other commands not shown in  the documentation, now I have it
> > > > strangely in state unknown but tried ping and works.
> > > > https://www.gnu.org/software/guix/manual/en/html_node/Preparing-for-Installation.html#Preparing-for-Installation
> > > > (I am writing down in my daily journal everything I am encountering, )
> > > > I have even found that I cannot run shutdown -h now, don't know why
> > > > tried shutdown --help and it does not show the option, or read
> > > > manpages, or fin where .bash_history is located.
> > >
> > > shutdown is handled by shepherd on GuixSD, and it does not have these
> > > options. You can try simply shutdown or halt.
> > > .bash_history on my GuixSD system is located in ~/.bash_history, as
> > > expected. Also on my GuixSD system system
> > > man pages work as expected. Are you facing these issues in the
> > > installation image?
> > >
> > > It is nice that you managed using VirtualBox. I am not suprised that
> > > it works, but worth a mention in the documentation
> > > I think. You wrote that you have a question, what is it?
> > >
> > I guess the question 

Re: Meetup in Paris, Dec. 10th!

[Ludovic Courtès]

Hello!

Konrad Hinsen  skribis:

> Am 11.10.18 um 15:55 schrieb Ludovic Courtès:
>
>> I’ve booked a room at Inria’s offices in Paris for the Dec. 10 gathering
>> I proposed a while back, see:
>
> Great! At what time does it start?

We can aim for 9AM to 6PM.

>> A couple of notes: the room capacity is 16 but I’ll look for a larger
>
> There's actually plenty of space for more in that room, it's just a
> matter of finding chairs.

Excellent.  :-)

> Looking forwards to meeting other Guixers!

Same here!

Cheers,
Ludo’.

Estimating build time

[Ludovic Courtès]

Hello!

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
>> Ricardo Wurmus  skribis:

[...]

>>> Currently, there’s no way to tell if the derivations listed under “These
>>> derivations will be built” are expensive package builds or just simple
>>> graft derivations.
>>
>> Indeed.  A simple trick would be to (ab)use the environment variable
>> part of derivations as a property list, the way Nix has traditionally
>> done it (see ‘user+system-env-vars’ in (guix derivations)).
>>
>> So we could have, say, a ‘hint’ environment variable, and the UI would
>> use that to determine if it’s a graft.
>
> This sounds like a good trick to me.  I think it would be great to give
> more hints to the UI and make it clearer to users what work they can
> expect Guix to perform.

In a similar vein, the attached module provides code to estimate package
build time based on locally-available build logs.  It can be used to
show hints like this:

--8<---cut here---start->8---
The following derivations would be built (estimated time: 54 mn):
   /gnu/store/3627svyhih9cfss8gnxllp9nmxqp23cq-gcc-4.9.4.drv
   /gnu/store/3didvp9c3sfqwmb9kkdr211vg5myygsf-gcc-4.9.4.tar.xz.drv
--8<---cut here---end--->8---

or:

--8<---cut here---start->8---
The following derivations would be built (estimated time: 22 hr):
   /gnu/store/safjgjqhxlf59rknygqdfq175cl5wvks-rust-1.27.2.drv
   /gnu/store/v154ah7f8wqcga104df9ldb25bjk2pm8-rustc-1.27.2-src.tar.gz.drv
   /gnu/store/nz2xzl1yizcwcxhnw2w5mdqnp3q1gggx-rustc-1.25.0-src.tar.gz.drv
   /gnu/store/wn422brymn6ysxq07090ijb4wx78dc1l-rustc-1.24.1-src.tar.gz.drv
   /gnu/store/3cj5083j5aq7az7n5dmkds77g84xqc33-rust-bootstrap-1.22.1.drv
   /gnu/store/rm1nghqrvw43wlbwws49rw921qh58m35-rustc-1.23.0-src.tar.xz.drv
   /gnu/store/a9gzrq0bsc3ynfj4cnrsxxd2jwjgf4zj-rust-1.23.0.drv
   /gnu/store/bmbpbhgby84yrj0mvkv279cy2ira4xqf-rustc-1.24.1-src.tar.xz.drv
   /gnu/store/bxxyzp6kzq88ii4aindgnggbb2m193rk-rust-1.24.1.drv
   /gnu/store/r26s0y5fi055pclhnivvf63llbrj54yw-rustc-1.25.0-src.tar.xz.drv
   /gnu/store/x4l0rsqni9lglfzazkjyxqjp432yr33s-rustc-1.26.2-src.tar.gz.drv
   /gnu/store/03y9zf5imbm0ni1llcmxixb8c78nmxdd-rustc-1.26.2-src.tar.xz.drv
   /gnu/store/ici0m0bia0f6f4wh0ykn12x6wg1ckck0-rust-1.25.0.drv
   /gnu/store/2l6fn1nxs2sfl93khki5jzz6dh7gfqpr-rust-1.26.2.drv
   /gnu/store/9bn1gxnsc59zi8bdpvfgqcjpczmk3ch0-rustc-1.27.2-src.tar.xz.drv
--8<---cut here---end--->8---

(That’s from my x86_64 laptop.)

The obvious downside is that it works by first retrieving the names of
the files under /var/log/guix/drvs, and then opening, decompressing, and
parsing the candidate log files.  That typically takes a few seconds on
a recent SSD laptop, but clearly we don’t want to do that every time.
We could maintain a cache, but even then, it might still be too
expensive.

Perhaps we should keep build times in the database somehow; the daemon
can keep it up-to-date.

Thoughts?

There’s the obvious downside that both approaches rely on having
previously built the package, but I think that’s a necessary limitation,
unless we are to resort to external services (which could hardly provide
estimates that make sense for the user’s machine anyway.)

Ludo’.

;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2018 Ludovic Courtès 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see .

(define-module (guix build-logs)
  #:use-module (guix config)
  #:use-module (guix store)
  #:use-module (srfi srfi-1)
  #:use-module (guix utils)
  #:use-module (ice-9 match)
  #:use-module (ice-9 ftw)
  #:use-module (ice-9 regex)
  #:use-module (ice-9 rdelim)
  #:export (%log-directory
log-file-build-phases
log-file-build-time
estimated-build-time))

(define %log-directory
  (string-append (dirname %state-directory) ; XXX
 "/log/guix/drvs"))

(define %end-of-phase-rx
  (make-regexp "^phase [`']([[:graph:]]+)' succeeded after ([0-9.]+) seconds$"))

(define (log-file-build-phases file)
  "Interpret the build log in FILE and return an alist of name/duration pairs
for each build phase, such as:

  ((unpack . 1.3) (configure . 4.2) (build . 383.8) …)

Duration is expressed in seconds.  Return the empty list if no build phase
information 

Making javadoc reproducible

[Gábor Boskovits]

Hello guix,

I've tracked down the javadoc timestamp problem.
There is a command line flag for javadoc (notimestamp), that disables
generating the comment in the docs that contains the timestamp.
Currently I see two ways forward:
1. Track down the calls to javadoc, and add the flag to all calls.
2. Write a simple patch to make javadoc behave as if notimestamp was
specified, whenever
SOURCE_DATE_EPOCH is defined.
I do not think, that the patch produced by 2 is upstreamable, but it
seems much less work. WDYT?

Re: Meetup in Paris, Dec. 10th!

[Gábor Boskovits]

Ludovic Courtès  ezt írta (időpont: 2018. okt. 12., P, 17:47):
>
> Hello!
>
> Konrad Hinsen  skribis:
>
> > Am 11.10.18 um 15:55 schrieb Ludovic Courtès:
> >
> >> I’ve booked a room at Inria’s offices in Paris for the Dec. 10 gathering
> >> I proposed a while back, see:
> >
> > Great! At what time does it start?
>
> We can aim for 9AM to 6PM.
>

I will only make it some time in the afternoon. Looking forward to seeing you!

> >> A couple of notes: the room capacity is 16 but I’ll look for a larger
> >
> > There's actually plenty of space for more in that room, it's just a
> > matter of finding chairs.
>
> Excellent.  :-)
>
> > Looking forwards to meeting other Guixers!
>
> Same here!
>
> Cheers,
> Ludo’.
>

Re: Making javadoc reproducible

[Gábor Boskovits]

Gábor Boskovits  ezt írta (időpont: 2018. okt.
12., P, 19:00):
>
> Hello guix,
>
> I've tracked down the javadoc timestamp problem.
> There is a command line flag for javadoc (notimestamp), that disables
> generating the comment in the docs that contains the timestamp.
> Currently I see two ways forward:
> 1. Track down the calls to javadoc, and add the flag to all calls.
> 2. Write a simple patch to make javadoc behave as if notimestamp was
> specified, whenever
> SOURCE_DATE_EPOCH is defined.
> I do not think, that the patch produced by 2 is upstreamable, but it
> seems much less work. WDYT?

Also we can simply turn off the timestamp generation unconditionally...

Re: Gradio attempt

[Brett Gilio]

Leo Famulari writes:


On Thu, Oct 11, 2018 at 04:33:31PM -0500, Brett Gilio wrote:
Thank you for your feedback on the description. As for whether 
or not
the application works, yes. I click on "Add stations to 
library". It
takes a few seconds for it to populate, but I am eventually 
shown
several choices and something to click on. From there, after 
clicking on

a station, I receive a missing codec error.


Thanks, I got it to load the stations when run within GNOME.

The missing plugin error is related to GStreamer and the various
GStreamer plugins; I don't think Gradio uses LAME. I tried 
building with
all of the GStreamer libraries and plugins, or installing them 
all

alongside Gradio, but no luck.


I tried the same thing after I sent the initial email and looking 
at the
build process more closely. But, I am in the same position as you, 
no
luck. I am not sure how it is verifying the presence of the codec, 
if it
is looking in a specific path or something. What do you suggest I 
do

from here?

Brett

--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org

Re: Making javadoc reproducible

[Björn Höfling]

On Fri, 12 Oct 2018 19:35:51 +0200
Gábor Boskovits  wrote:

> Gábor Boskovits  ezt írta (időpont: 2018. okt.
> 12., P, 19:00):
> >
> > Hello guix,
> >
> > I've tracked down the javadoc timestamp problem.
> > There is a command line flag for javadoc (notimestamp), that
> > disables generating the comment in the docs that contains the
> > timestamp. Currently I see two ways forward:
> > 1. Track down the calls to javadoc, and add the flag to all calls.
> > 2. Write a simple patch to make javadoc behave as if notimestamp was
> > specified, whenever
> > SOURCE_DATE_EPOCH is defined.
> > I do not think, that the patch produced by 2 is upstreamable, but it
> > seems much less work. WDYT?  
> 
> Also we can simply turn off the timestamp generation
> unconditionally...

Number 2 sounds good, and why not giving it a try to place it upstream?

Björn


pgpgYTOUlMHRt.pgp
Description: OpenPGP digital signature

Flagging packages

[Brett Gilio]

I was wondering if there has been any discussion on introducing a 
way to
flag out-of-date packages either through the guix package website 
or
using a guix package flag. I, personally, come from an 
Arch/Parabola

background, and such a feature was usually a good way to alert the
community of something corrective needing to be done. It could 
trigger a
mailing list alert, which could then be claimed by a member 
willing to

manage it and submit a patch.

Thoughts?


--
Brett M. Gilio
Free Software Foundation, Member
https://gnu.org/s/guix/ | https://emacs.org

Re: Making javadoc reproducible

[Gábor Boskovits]

Björn Höfling  ezt írta (időpont:
2018. okt. 12., P, 20:01):
>
> On Fri, 12 Oct 2018 19:35:51 +0200
> Gábor Boskovits  wrote:
>
> > Gábor Boskovits  ezt írta (időpont: 2018. okt.
> > 12., P, 19:00):
> > >
> > > Hello guix,
> > >
> > > I've tracked down the javadoc timestamp problem.
> > > There is a command line flag for javadoc (notimestamp), that
> > > disables generating the comment in the docs that contains the
> > > timestamp. Currently I see two ways forward:
> > > 1. Track down the calls to javadoc, and add the flag to all calls.
> > > 2. Write a simple patch to make javadoc behave as if notimestamp was
> > > specified, whenever
> > > SOURCE_DATE_EPOCH is defined.
> > > I do not think, that the patch produced by 2 is upstreamable, but it
> > > seems much less work. WDYT?
> >
> > Also we can simply turn off the timestamp generation
> > unconditionally...
>
> Number 2 sounds good, and why not giving it a try to place it upstream?

Ok, i will go for it, and try to get it upsreamed for jdk8 and jdk11.

>
> Björn

Re: Making javadoc reproducible

[Vagrant Cascadian]

On 2018-10-12, Björn Höfling wrote:
> On Fri, 12 Oct 2018 19:35:51 +0200
> Gábor Boskovits  wrote:
>> Gábor Boskovits  ezt írta (időpont: 2018. okt.
>> 12., P, 19:00):
>> > I've tracked down the javadoc timestamp problem.
>> > There is a command line flag for javadoc (notimestamp), that
>> > disables generating the comment in the docs that contains the
>> > timestamp. Currently I see two ways forward:
>> > 1. Track down the calls to javadoc, and add the flag to all calls.
>> > 2. Write a simple patch to make javadoc behave as if notimestamp was
>> > specified, whenever
>> > SOURCE_DATE_EPOCH is defined.
>> > I do not think, that the patch produced by 2 is upstreamable, but it
>> > seems much less work. WDYT?  
>> 
>> Also we can simply turn off the timestamp generation
>> unconditionally...
>
> Number 2 sounds good, and why not giving it a try to place it upstream?

There's been some discussion about this in Debian and in reproducible
builds:

  https://bugs.debian.org/783938

  
https://wiki.debian.org/ReproducibleBuilds/TimestampsInDocumentationGeneratedByJavadoc

  
https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_in_documentation_generated_by_javadoc_issue.html

Hope it's useful!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Ruby 2.5, pushing to staging?

[Christopher Baines]

Christopher Baines  writes:

> A new minor version of Ruby has been out for a while, and it would be
> good to get Ruby 2.5 in to Guix.
>
> I've put up a patch here [1], and tried it locally. I've pushed some
> fixes to master to make some packages compatible [2], and while I do get
> some failures when building the 958 (according to guix refresh -l)
> dependant packages, I'm unsure how many of these are down to the Ruby
> upgrade.
>
> 1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32871
> 2: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32870
>
> Anyway, looking at the contributing guide this is possibly too big of a
> change to push directly to master, so should I push this to the staging
> branch?

I've now gone ahead and pushed to staging. Not really sure what happens
now will berlin and hydra pick this up automatically, and start
building packages?


signature.asc
Description: PGP signature

Reproducible rust builds

[Nikolai Merinov]

Hi,

I made some investigations about reproducible builds of rust packages
(at least of my laptop with x86_64 arch) and I got next results:

1. I failed to make rust 1.25.0 reproducible with LLVM 6.0.1, but this
release reproducible if we build it with LLVM 3.9.1. I also tried to
build rust 1.25.0 with internal LLVM and got same reproducibility issue.
2. Rust 1.26.2 reproducible with LLVM 6.0.1 regardless of which LLVM
used for rust 1.25.0. I failed to find any specific changes that allow
this version to be built in reproducible manner with LLVM 6.0.1.
3. There is a same situation with 1.27.2 as with rust 1.25.0:
Reproducible with LLVM 3.9.1, not reproducible with LLVM 6.0.1. Build
with LLVM 3.9.1 step on reproducibility issue in rustdoc, but there is
patch for this issue.
4. Rust 1.28.0 and 1.29.1 releases builds well with LLVM 6.0.1
5. From very first release we missed cargo dependency on libssh2 and
libgit2 and this dependencies was build internally by rust.

Code of reproducible packages for 1.25.0, 1.27.2, 1.28.0, and 1.29.1
rust releases you can find in
https://github.com/mnd/guix-mnd-pkgs/blob/master/mnd/packages/rust.scm

Can you recommend preferable changes for rust packages in GuixSD? I
suggest to make next changes:

1. Switch back to llvm 3.9.1 in rust 1.25.0, 1.26.2, 1.27.2 rust
packages. NOTE: External LLVM 6.0 in rust 1.26.0 and newer allow to use
#[cfg(target-feature)] to check processor features. Prior to 1.26.0
release this feature was supported only with bundled llvm.
2. Use llvm 6.0.1 for rust 1.28.0 and newer.
3. Add external libssh2 and libgit2 dependencies to rust packages.

Open question: To which release should I add dependency on libgit2 and
libssh2? It can be added to rust-1.19 still it was missed from very
beginning or to rust-1.25, because we should change rust-1.25 package in
any case.

Regards,
Nikolai

Re: Estimating build time

[Clément Lassieur]

Ludovic Courtès  writes:

> In a similar vein, the attached module provides code to estimate package
> build time based on locally-available build logs.  It can be used to
> show hints like this:

[...]

> The obvious downside is that it works by first retrieving the names of
> the files under /var/log/guix/drvs, and then opening, decompressing, and
> parsing the candidate log files.  That typically takes a few seconds on
> a recent SSD laptop, but clearly we don’t want to do that every time.
> We could maintain a cache, but even then, it might still be too
> expensive.
>
> Perhaps we should keep build times in the database somehow; the daemon
> can keep it up-to-date.
>
> Thoughts?
>
> There’s the obvious downside that both approaches rely on having
> previously built the package, but I think that’s a necessary limitation,
> unless we are to resort to external services (which could hardly provide
> estimates that make sense for the user’s machine anyway.)

I think it's an excellent idea!  I agree that the downside is necessary,
and yes, keeping the build times in the database sounds good!

Clément

Channel dependencies

[Ricardo Wurmus]

Hi,

the attached patch allows channel authors to declare other channels as
dependencies of their own channel.  In addition to explicitly requested
channels, “guix pull” will now also download and build channels that
have been declared as dependencies in the file ‘.guix-channel’ in the
repository root.

An example of a simple .guix-channel file is this:

--8<---cut here---start->8---
(channel
 (version 0)
 (dependencies
  (channel
   (name guix-bimsb)
   (url "https://github.com/BIMSBbioinfo/guix-bimsb";
--8<---cut here---end--->8---

What do you think?

--
Ricardo

>From 1783c17582906df970c7e68e89d761619a35caeb Mon Sep 17 00:00:00 2001
From: Ricardo Wurmus 
Date: Sat, 13 Oct 2018 08:39:23 +0200
Subject: [PATCH] guix: Add support for channel dependencies.

* guix/channels.scm (%channel-meta-file): New variable.
(channel-meta, channel-instance-dependencies): New procedures.
(latest-channel-instances): Include channel dependencies.
(channel-instance-derivations): Build derivation for additional channels and
add it as dependency to the channel instance derivation.
* doc/guix.texi (Channels): Add subsection "Declaring Channel Dependencies".
---
 doc/guix.texi | 33 
 guix/channels.scm | 79 ++-
 2 files changed, 97 insertions(+), 15 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 5ae80917a..a4d5477f6 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -3020,6 +3020,39 @@ the new and upgraded packages that are listed, some like @code{my-gimp} and
 @code{my-emacs-with-cool-features} might come from
 @code{my-personal-packages}, while others come from the Guix default channel.
 
+@cindex dependencies, channels
+@cindex meta-data, channels
+@subsection Declaring Channel Dependencies
+
+Channel authors may decide to augment a package collection provided by other
+channels.  They can declare their channel to be dependent on other channels in
+a meta-data file @file{.guix-channel}, which is to be placed in the root of
+the channel repository.
+
+The meta-data file should contain a simple S-expression like this:
+
+@lisp
+(channel
+ (version 0)
+ (dependencies
+  (channel
+   (name 'some-collection)
+   (url "https://example.org/first-collection.git";))
+  (channel
+   (name 'some-other-collection)
+   (url "https://example.org/second-collection.git";)
+   (branch "testing"
+@end lisp
+
+In the above example this channel is declared to depend on two other channels,
+which will both be fetched automatically.  The modules provided by the channel
+will be compiled in an environment where the modules of all these declared
+channels are available.
+
+For the sake of reliability and maintainability, you should avoid dependencies
+on channels that you don't control, and you should aim to keep the number of
+dependencies to a minimum.
+
 @subsection Replicating Guix
 
 @cindex pinning, channels
diff --git a/guix/channels.scm b/guix/channels.scm
index 82389eb58..fbe1b62bb 100644
--- a/guix/channels.scm
+++ b/guix/channels.scm
@@ -1,5 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2018 Ludovic Courtès 
+;;; Copyright © 2018 Ricardo Wurmus 
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -72,7 +73,6 @@
   (commitchannel-commit (default #f))
   (location  channel-location
  (default (current-source-location)) (innate)))
-;; TODO: Add a way to express dependencies among channels.
 
 (define %default-channels
   ;; Default list of channels.
@@ -81,6 +81,10 @@
  (branch "master")
  (url "https://git.savannah.gnu.org/git/guix.git";
 
+(define %channel-meta-file
+  ;; The file containing information about the channel.
+  ".guix-channel")
+
 (define (guix-channel? channel)
   "Return true if CHANNEL is the 'guix' channel."
   (eq? 'guix (channel-name channel)))
@@ -99,20 +103,52 @@
 (#f  `(branch . ,(channel-branch channel)))
 (commit  `(commit . ,(channel-commit channel)
 
+(define (channel-meta instance)
+  "Return an S-expression read from the channel INSTANCE's description file,
+or return #F if the channel instance does not include the file."
+  (let* ((source (channel-instance-checkout instance))
+ (meta-file (string-append source "/" %channel-meta-file)))
+(and (file-exists? meta-file)
+ (call-with-input-file meta-file read
+
+(define (channel-instance-dependencies instance)
+  "Return the list of channels that are declared as dependencies for the given
+channel INSTANCE."
+  (or (and=> (assoc-ref (channel-meta instance) 'dependencies)
+ (lambda (dependencies)
+   (map (lambda (item)
+  (let ((get (lambda* (key #:optional default)
+   (or (and=> (assoc-ref item key) car) default
+(let ((name (get 'name))
+  (url (get 'url))
+