Re: [outreachy] Further steps

[Gábor Boskovits]

Hello Laura,

Congratulations!

Björn Höfling  ezt írta (időpont:
2018. okt. 24., Sze, 7:17):
>
> On Tue, 23 Oct 2018 22:48:30 -0300
> Laura Lazzati  wrote:
>
> > Hi all!
> >
> > I'm really happy that the patch worked :)
> >
> > Tomorrow -yet Tuesday here, I live in the past :P - I will close the
> > in progress contribution.
> >
> > If you don't mind, I have some questions and need some feedback to go
> > on.
> >
> > - As regards patches, for future ones:
> >
> > 1)Why my patch file (the one I sent) does not work applying it with
> > git am in my local cloned repo? Do I need to create a new branch or
> > something like that?
>

The last version you sent worked just fine for me. I could use git am
without a problem. (I downloaded the attachment, and used git am on
that)
I used the current master, created a branch, then used git am to apply
your patch. (I create a branch so that I don't touch master in my checkout,
it should work without it)

How was it failing for you?

> I think that was the problem. Here I already applied your patch and it
> fails (On line 9 already because of the copyright header):
>
> ~/guix/wt/kde$ git log -1 | cat; git am ~/0001-gnu-Add-r-aspi.patch
> commit c3ff36b4aa08caa8131b65a14caa03161b71e564
> Author: Laura Lazzati 
> Date:   Tue Oct 23 01:59:22 2018 -0300
>
> gnu: Add r-aspi.
>
> * gnu/packages/cran.scm (r-aspi): New variable.
> Applying: gnu: Add r-aspi.
> error: patch failed: gnu/packages/cran.scm:9
> error: gnu/packages/cran.scm: patch does not apply
> Patch failed at 0001 gnu: Add r-aspi.
> hint: Use 'git am --show-current-patch' to see the failed patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
>
> My workflow usually is to get the lastest master and then to create and
> work on a branch for that, for example "wip-r-aspi". Then I can create
> another branch "wip-r-aspi2" and go  again from there. Usually I have
> too many of those branches and have to clean up from time to tome.
>

Yes, the workflow Björn described works for me as well :)
I git you often have a lot of branches, as they are cheap,
and help to organize work. I also have to clean them up from time
to time. I also tend to have throwaway branches,  where I just experiment.

>
> > 2)Where can I read about how to set an appropriate commit log? (not
> > running just git log to see how they were generated before)
>
> That's a bit hidden, but documented: In section "7.5 Submitting
> Patches" there is a link to the GNU Coding Standards:
>
> https://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs
>
>
> > 3) I added an eol with emacs editor, just as you mentioned. Could you
> > send me your previous output about the error you were getting about
> > that line break, if you still have it?
>
> I haven't looked into that broken patch. Gabor?
>

As we have those messages, you can have a look at the output yourself, just
try to apply the inline patch from the mail. (You can download in mbox format
from the debbugs interface)

You will see an output similar to what Björn quoted above, except it will say:
'Corrupt patch at line 10' instead of 'patch does not apply'

> > 4) I guess you already answered this one, but Is it ok to send patches
> > attached to an email or is it strict to send them with git send-email
> > when getting much more involved?
>
> It's OK. I think it comes more convenient when you have a long series
> of patches, i.e. you add one package one its 20 dependencies, then you
> get a series Patch[1/21]..., see the patch-tracker for examples. But
> there are also some examples of people sending patches as attachments.
>

Yes, Björn is right here, it is easier to handle longer series with
git send-email,
but it is perfectly ok to send patches as attachments.

>
> > In the thread of mails, I have already asked you, but I would like to
> > know how to continue from now on:
> >
> > I would like to go on contributing as much as possible up to November
> > 6th (the deadline for applying for Outreachy).
> > 1) Is it fine to go on packaging R packages that are not available
> > yet, now that I know how to import them, modify them and the whole
> > process?
> > 2) Do you prefer another tasks to be done?
>
> I would say that R-packages is fine. Gabor do you see any specific
> other tasks?
>

R-packages are fine for now.

> If you have any other favourite packages, you can give them also a try.
> It could just get more difficult, with more manual steps, other build
> systems, dependencies to be packed first, code to be patched, etc.
>

Yes, this would also be good. Please tell us if you have any specific package
in mind.

>
> > - I would like to contribute even after November 6th since I like the
> > project really much and the community made me feel really comfortable,
> > that's why I kept saying thank you almost all the time.
>
> Of c

Re: Promoting the GNU Kind Communication Guidelines?

[Mathieu Lirzin]

Hello Tobias,

Tobias Geerinckx-Rice  writes:

> I've (re-)read the links you've provided (thanks). I guess it's
> supposed to be obvious what you find disagreeable about them, but if
> one doesn't disagree, it's not that obvious. :-)

IMO Discussing what I find disagreeable with the particular form of
Feminism advocated by the links I have provided is off topic.

Without direspecting those who agrees with those ideas, I think it is
reasonably obvious that not everybody supporting Free Software, supports
those unrelated political ideas.

> That said, I hope we can address any perceived lack of merit in (our
> copy of) the CoC without resorting to its original authors. The
> resulting irony blast would level multiple city blocks.

I don't understand the last sentence.  Can you explain it with
simpler words?

>> [1] http://lists.gnu.org/archive/html/info-gnu/2018-10/msg1.html
>> [2] https://www.contributor-covenant.org/
>> [3] https://geekfeminism.wikia.com/wiki/Meritocracy

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

hydra.gnu.org off-line for maintenance

[Ludovic Courtès]

Hello Guix,

The hydra.gnu.org build farm has been off-line since yesterday ~4PM UTC
and will remain off-line roughly until the end of the week.  The FSF
sysadmins (it’s hosted at the FSF’s data center) are performing a major
storage upgrade that happens to need more time than expected.

In the meantime, if you use mirror.hydra.gnu.org, you’ll still get
substitutes, though not the latest one.

If you use berlin.guixsd.org, everything is fine; if you don’t, now is
the time to add it to your substitute URLs!  See
.

Apologies for the inconvenience!

Ludo’.


signature.asc
Description: PGP signature

Re: Promoting the GNU Kind Communication Guidelines?

[Ludovic Courtès]

Hello,

Jack Hill  skribis:

> On Tue, 23 Oct 2018, Alex Griffin wrote:
>
>> FWIW once I noticed that Guix had adopted the Contributor Covenant, it
>> factored strongly into my decision to stop contributing to the project
>> last year.
>
> Interesting. I too am eager understand your thinking on this.

Same here.  For the record, the code of conduct was adopted in Guix
in Dec. 2015.

Ludo’.

Re: Promoting the GNU Kind Communication Guidelines?

[Ludovic Courtès]

Hello Mathieu,

Good to see you here!

Mathieu Lirzin  skribis:

> Following the announcement made by RMS regarding the new GNU Kind
> Communication Guidelines (GKCG) [1], I would like to know if the Guix
> developpers in particular its maintainers would agree to adopt it in
> place of the current Code of Conduct (CoC)?

Speaking for myself: no.  I think the GKCG fails to address important
issues, such as defining what’s acceptable and what’s not as well as
clear processes to address this.

> Adopting the GKCG instead of a CoC would help attracting people (like
> me) who agree to use a welcoming and respectful language which
> encourages everyone to contribute but are reluctant in contributing to
> any project following a CoC due to its punitive nature and the politics
> of its authors [2][3].

Codes of conduct codify acceptable behavior and formalize processes:
what can I do as a contributor if I’m a victim bad behavior or
harassment?  What are the group communication rules?  What if I
knowingly break those rules?

By adopting the code of conduct, we maintainers committed to spend our
time as needed to so your experience contributing to Guix won’t be a
source of stress or worse, as is too often the case in on-line
communities.

The GKCG do not do that.  Problems will be dealt with in an ad hoc
fashion (as they already are in groups that have not codified rules), if
they are addressed at all.

I hope this answers your question.

Happy hacking!

Ludo’.

Re: Packaging gx (for IPFS): Need to update default Go to 1.11?

[Pierre Neidhardt]

Correction: gx itself does not need Go 1.11, but go-ipfs requires that gx be
compiled with Go 1.11+.

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


signature.asc
Description: PGP signature

Re: 01/01: gnu: snap: Update to 4.2.2.2.

[Nicolas Goaziou]

Hello,

Mark H Weaver  writes:

> According to 'git' on my machine, this commit is signed with GnuPG key
> ED0EF1C8E126BA831B485FE9DA00B4F048E92F2D, which is different from the
> key that you uploaded to Savannah (A834B9E080A93738).

Oops!

> Can you please verify that ED0EF1C8E126BA831B485FE9DA00B4F048E92F2D is
> your key

It is.

> and if so, can you please upload it to Savannah?

I think it is now done. Please let me know if something is wrong.

Thank you.

Regards,

-- 
Nicolas Goaziou

Re: Packaging Inferno

[Ludovic Courtès]

Hi Diego,

Diego Nicola Barbato  skribis:

> I have sent a patch incorporating most of your feedback to
> guix-patc...@gnu.org (bug#33080).

Thank you, and sorry that review takes some time.  I guess that’s the
price to pay when submitting non-trivial packages.  ;-)

>> Do you know whether other FSDG distros and Debian provide these fonts?
>
> They do not provide these exact fonts but those from which some of these
> are derived (misc and jis are "based" on X fonts, vera is probably based
> on Bitstream Vera).
> It is harder to find the origin of the other fonts as there is little
> information about them (big5 was "provided by students at the University
> of Hong Kong" according to its README; courier, gb, and minitel do not
> contain any information).  The remaining fonts just reuse "subfonts"
> from the other directories.

OK.  Courier is a standard PostScript font (with a free implementation
by the URW++ foundry), so it’s probably fine.  I don’t know about the
others; it’s probably safe, but perhaps you could ask for advice on the
GNU/Linux-libre mailing list?  (See
.)

>> Note that the page above says that the Lucent PL is incompatible with
>> the GPL.  Are we combining GPL code with Lucent code here?
>
> AFAICT LPL code (libmp libsec) is combined with GPL code when building
> emu.  There is some more LPL code in the os directory, which is only
> needed for building native inferno, and in the appl and module
> directories, which contain Limbo code which is run on inferno but not
> used to build it.
> The NOTICE says that all licenses are compatible with the GPLv2 but that
> is apparently incorrect.
> As I am not very familiar with software licenses I do not know what to
> do about this.  According to the GPL FAQ [*] it is possible to add an
> exception when using incompatible libraries, but I am hesitant to
> suggest this in a bug report to upstream because I do not know if that
> applies here.
>
> Is this a blocker?

What you’re writing about libmp/libsec linked into ‘emu’ sounds like it
could be a GPL violation.  Again, to be sure, I’d suggest getting
feedback from the GNU/Linux-libre mailing list (in a separate thread.)

>> Sounds good.  Note that, if possible, we should stick to the usual file
>> system layout (that is OUT/share, OUT/lib, OUT/bin, etc. and not
>> OUT/usr.)  Though if keeping the /usr/inferno layout style is really
>> important, we can make an exception.
>
> The layout style is not important; I only used OUT/usr/inferno because
> /usr/inferno is the default in mkconfig.  I have changed this to
> OUT/share/inferno, which matches what the Nix package [†] does.

Sounds good.

Thank you!

Ludo’.

Re: GuixSD on AArch64

[Ludovic Courtès]

Vagrant Cascadian  skribis:

> On 2018-10-22, Ludovic Courtès wrote:
>> On IRC earlier today Vagrant mentioned that the Pinebook AArch64 laptop
>> (see ) should be able to run
>> GuixSD when Linux-libre 4.19 and U-Boot 2018.11 are out, with 100% free
>> software.  That may give another incentive to work on AArch64.
>
> Looking like u-boot 2019.01 might be more likely, but modest patches
> work with 2018.11-rc2. I'll probably bring the pinebook with me to the
> Paris meetup in December... though with only 2GB of ram it might not
> make the most exciting GuixSD system... :)

Well, I know there’s still some way to go (in particular wrt. the Guile
compiler memory consumption), but we should aim to make Guix usable on
such systems.

> Very similar is the free open-source hardware Teres-I from olimex:
>
>   https://www.olimex.com/Products/DIY-Laptop/
>
> ... Which is just a kit with all the parts you assemble yourself!

Looks like a lot of fun!

Ludo’.

Re: Guix & IPFS

[Ludovic Courtès]

Hi!

Pierre Neidhardt  skribis:

>> As discussed before (I think?), builds are performed in an isolated
>> environment without network access—this is one of the measures taken to
>> guarantee build reproducibility and statelessness.
>> 
>> So what you’re doing here (running “gx” in a derivation) cannot work.
>
> No, the above error comes from the "gx-fetch" code I've just pushed to the
> wip-ipfs branch.  Downloaders obviously have network access, but maybe I've 
> set
> it up wrong.

To be precise, builders of fixed-output derivations (derivations for
which the hash of the result is known in advance) have network access.

In practice these are downloaders, but it’s because they are
fixed-output derivations that the daemon is more liberal and provides
them with network access.

How did you define ‘gx-fetch’?

Thanks,
Ludo’.

Re: Channel dependencies

[Ludovic Courtès]

Hello!

Chris Marusich  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Good point.  I agree that it’s similar to the question of propagated
>> inputs, which we deal with by reporting an error when a collision
>> arises.
>>
>> So, similarly, I think the safe way would be to report an error when
>> channel requirements conflict.
>
> With profiles, two packages conflict if and only if a file exists at the
> same relative path in both packages' outputs.

What you describe here are “soft collisions”, which the profile builder
reports as warnings (which are invisible with today’s ‘guix package’.)

I was referring to profile collisions where two packages with the same
name end up in the same profile (the ‘&profile-collision-error’
exception.)

This exception would also be raised if ‘guix pull’ ended up adding the
same channels more than once in ~/.config/guix/current.

> Also like you said, we can try to implement some heuristics to reject
> situations in which a "channel conflict" is likely.  Would it be hard to
> change the channel mechanism so that it fails if there are any (normal)
> conflicts while generating the profile that contains all the channels?
> If we could prevent those (normal) conflicts while generating the
> profile, it would prevent a certain class of channel conflicts: namely,
> it would be impossible for two channels to provide the same guile
> modules.

‘union-build’ has a #:resolve-collision parameter.  We could set it when
building ~/.config/guix/current so that an error is raised when the same
file is provided more than once.

(It’s a simple change we can make independently of what Ricardo is
proposing.)

WDYT?

>> We must define what it means for two s to conflict:
>>
>>   • if a channel’s ‘commit’ is #f, then any channel with the same name
>> but a different ‘uri’ and/or a different ‘branch’ and/or a non-#f
>> commit conflicts;
>>
>>   • if a channel’s ‘commit’ is not #f, then any channel with the same
>> name and otherwise different fields conflicts.
>
> This seems like a reasonable heuristic.  What will we do when two
> channels differ only in their name?  What about when two channels only
> have identical fields?  Maybe in those cases we should just pick one,
> ignore the other, and log a warning, since their content will be the
> same.

Yes, they would effectively be ‘equal?’.

>> If we have inspiration later, we can liberalize this, for instance by
>> using several inferiors.  It would be quite a bit of extra work, and
>> it’s not immediately clear to me how that could work.  I believe what
>> Ricardo proposes already covers many use cases anyway.
>
> You're probably right.  I'm just trying to think about how we might
> apply the functional model to this problem, rather than implementing
> heuristics.  But maybe heuristics are good enough!

Sure, and that’s good!

Thanks,
Ludo’.

Re: Come back and graphical installer

[Ludovic Courtès]

Hello Danny!

Danny Milosavljevic  skribis:

> I agree.  I've been meaning to write parted bindings for guile, but
> I got side-tracked with https://github.com/daym/guile-gcc-unit which
> can extract prototypes out of gcc source files (in order to automate
> wrapper generation).  Now I'm motivated to pick it up again.

Fun, and an interesting approach!

In a similar vein, did you read about Matt Wette’s “FFI helper” that
comes with Nyacc?  It shares the same goal of automatic generation of
Guile bindings and apparently it works well enough that Matt has been
able to use it for pretty large and non-trivial libraries.

> Maybe I should just have written the bindings manually - I would have
> been done a long time ago ;-)

Heheh, talk about shaving yaks.  :-)

Personally I’m not entirely sure automatic binding generation is worth
the effort in general, because “good” bindings necessarily require
manual intervention, at least to provide an API that meshes well with
the target language and its conventions.

Parted has a streamlined consistent object-oriented API, so I think it
Shouldn’t Be Hard (ah ha!) to write bindings, with or without automatic
generation tools.

Ludo’.

Re: Package variation

[Ludovic Courtès]

Hi!

Brett Gilio  skribis:

> I am trying to customize my the default gnome-package which gets
> installed with the gnome-desktop-service.

On this topic, don’t miss Chris’s excellent tutorial:

  
https://gnu.org/software/guix/blog/2018/customize-guixsd-use-stock-ssh-agent-everywhere/

:-)

Ludo’.

Re: Mono and .NET Core

[Ludovic Courtès]

Hello!

Brett Gilio  skribis:

> Two questions here.
>
> 1) Has anybody already started taking to try and upgrade Mono to latest?
> If not, I will give it a go.
>
> 2) Have we started any packaging on .NET Core, would like to know to
> prevent redundancy in work.

AFAIK nobody worked in this area yet, so you’ll probably have the
privilege to be a pioneer!  :-)

Mono was added by janneke (Cc’d), who might have something to add?

Ludo’.

Re: Mono and .NET Core

[Ludovic Courtès]

Hello!

Brett Gilio  skribis:

> Two questions here.
>
> 1) Has anybody already started taking to try and upgrade Mono to latest?
> If not, I will give it a go.
>
> 2) Have we started any packaging on .NET Core, would like to know to
> prevent redundancy in work.

AFAIK nobody worked in this area yet, so you’ll probably have the
privilege to be a pioneer!  :-)

Mono was added by janneke (Cc’d), who might have something to add?

Ludo’.

Re: Mono and .NET Core

[Adam Van Ymeren]

I tried to package .NET Core a while ago but didn't produce anything useful.  
Their GNU/Linux story was rapidly changing at the time.

.NET Core was a pain to package partly because it bootstraps from a binary 
version of .NET Core similar to Rust.  Although it may be possible to bootstrap 
via Mono I didn't try it and it's definitely not an upstream supported route ;).

Personally I ended up with just sticking to Mono for my C# needs as I found 
.NET Core didn't integrate as nicely into the GNU/Linux ecosystem.

That being said it would certainly be nice to have packages for it in Guix.

On October 24, 2018 10:03:29 PM GMT+09:00, l...@gnu.org wrote:
>Hello!
>
>Brett Gilio  skribis:
>
>> Two questions here.
>>
>> 1) Has anybody already started taking to try and upgrade Mono to
>latest?
>> If not, I will give it a go.
>>
>> 2) Have we started any packaging on .NET Core, would like to know to
>> prevent redundancy in work.
>
>AFAIK nobody worked in this area yet, so you’ll probably have the
>privilege to be a pioneer!  :-)
>
>Mono was added by janneke (Cc’d), who might have something to add?
>
>Ludo’.

Re: Packaging gx (for IPFS): Need to update default Go to 1.11?

[Pierre Neidhardt]

> First, the implementation of go-build-system is really inefficient for
> Go 1.11, especially since things compiled with Go 1.11 keep a huge
> run-time dependency graph:

Is it _only_ inefficient because of issue 32949 or is there another reason?

> https://bugs.gnu.org/32949
> 
> That could probably be fixed based on the info in that thread.

OK, if Gábor's clue happens to be the right one, it should not be too hard.
I'll look into it later.

> Second, there are packages that don't yet support Go 1.9. Syncthing is a
> case where there are dependencies that need to be updated and tested.

I think you meant Go 1.11 ;)

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


signature.asc
Description: PGP signature

Re: Packaging gx (for IPFS): Need to update default Go to 1.11?

[Leo Famulari]

On Wed, Oct 24, 2018 at 01:40:26PM +0200, Pierre Neidhardt wrote:
> Is there a good reason for sticking to 1.9 or should we update to 1.11?

There are two reasons.

First, the implementation of go-build-system is really inefficient for
Go 1.11, especially since things compiled with Go 1.11 keep a huge
run-time dependency graph:

https://bugs.gnu.org/32949

That could probably be fixed based on the info in that thread.

Second, there are packages that don't yet support Go 1.9. Syncthing is a
case where there are dependencies that need to be updated and tested.


signature.asc
Description: PGP signature

Re: Packaging gx (for IPFS): Need to update default Go to 1.11?

[Leo Famulari]

On Wed, Oct 24, 2018 at 04:02:46PM +0200, Pierre Neidhardt wrote:
> 
> > First, the implementation of go-build-system is really inefficient for
> > Go 1.11, especially since things compiled with Go 1.11 keep a huge
> > run-time dependency graph:
> 
> Is it _only_ inefficient because of issue 32949 or is there another reason?

There is also  but IMO it's not a blocker
considering that Go 1.9 is no longer supported upstream.

> > Second, there are packages that don't yet support Go 1.9. Syncthing is a
> > case where there are dependencies that need to be updated and tested.
> 
> I think you meant Go 1.11 ;)

Yes :)


signature.asc
Description: PGP signature

Re: Guix & IPFS

[Pierre Neidhardt]

> To be precise, builders of fixed-output derivations (derivations for
> which the hash of the result is known in advance) have network access.

Oh, I did not know this detail.  Thanks for pointing it out!

> How did you define ‘gx-fetch’?

It's on the wip-ipfs2 branch.  Find the (broken) patch attached.
From 376a9fa08fa3ffb5a5ab0980acf75abdfc797486 Mon Sep 17 00:00:00 2001
From: Pierre Neidhardt 
Date: Wed, 17 Oct 2018 18:56:38 +0200
Subject: [PATCH] gx-download (DRAFT)

---
 guix/build/gx.scm|  60 
 guix/gx-download.scm | 131 +++
 2 files changed, 191 insertions(+)
 create mode 100644 guix/build/gx.scm
 create mode 100644 guix/gx-download.scm

diff --git a/guix/build/gx.scm b/guix/build/gx.scm
new file mode 100644
index 0..4ba0197b4
--- /dev/null
+++ b/guix/build/gx.scm
@@ -0,0 +1,60 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2018 Pierre Neidhardt 
+;;;
+;;; 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 gx)
+  #:use-module (guix build utils)
+  #:use-module (ice-9 popen)
+  #:export (gx-fetch))
+
+;;; Commentary:
+;;;
+;;; This is the build-side support code of (guix gx-download).  It allows a
+;;; gx hash to be fetched.
+;;;
+;;; Code:
+
+(define* (gx-fetch hash directory
+   #:key (gx-command "gx"))
+  "Fetch IPFS HASH into DIRECTORY.  HASH must be a valid IPFS hash.
+Return #t on success, #f otherwise."
+
+  (mkdir-p directory)
+
+  (with-directory-excursion directory
+;; TODO: Silence verbose output.
+
+;; Initialization is interactive, but we can shut it up by piping it to
+;; nothing.
+(let ((port (open-pipe* OPEN_WRITE gx-command "init")))
+  (display "\n" port)
+  (if (not (eqv? 0 (status:exit-val (close-pipe port
+  (error "Cannot initialize gx package")))
+
+;; Fetch to the "vendor" directory.
+(let ((port (open-pipe* OPEN_WRITE gx-command "import" "--local" hash)))
+  (display "N\n" port)
+  (if (not (eqv? 0 (status:exit-val (close-pipe port
+  (error "Cannot import gx package")))
+
+(delete-file "package.json")
+(mkdir-p   "gx/ipfs")
+(rename-file (string-append  "vendor/gx/ipfs/" hash) (string-append "gx/ipfs/" hash))
+(delete-file-recursively "vendor")
+#t))
+
+;;; gx.scm ends here
diff --git a/guix/gx-download.scm b/guix/gx-download.scm
new file mode 100644
index 0..4acf7bf61
--- /dev/null
+++ b/guix/gx-download.scm
@@ -0,0 +1,131 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2018 Pierre Neidhardt 
+;;;
+;;; 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 gx-download)
+  #:use-module (guix gexp)
+  #:use-module (guix store)
+  #:use-module (guix monads)
+  #:use-module (guix records)
+  #:use-module (guix packages)
+  #:use-module (guix utils)
+  #:use-module (guix modules)
+  ;; #:autoload   (guix build-system gnu) (standard-packages)
+  #:use-module (ice-9 match)
+  #:use-module (ice-9 vlist)
+  #:use-module (srfi srfi-1)
+  #:export (gx-reference
+gx-reference?
+gx-reference-hash
+
+gx-fetch
+gx-version
+gx-file-name))
+
+;;; Commentary:
+;;;
+;;; An  method that uses gx to fetch a specific hash over IPFS.
+;;; See https://github.com/whyrusleeping/gx.
+;;; The hash is specified with a  object.
+;;;
+;;; Code:
+
+(define-record-type* 
+  gx-reference make-gx-reference
+  gx-reference?
+  (hash gx-reference-hash))
+
+(define (gx-package)
+  "Return the default gx package."
+  (let ((distro (resolve-interface '(gnu packages ipfs
+(module-ref distro 'gx)))
+
+(de

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Griffin]

Jack Hill  skribis:
>
> Interesting. I too am eager understand your thinking on this.

I am skeptical of codes of conduct in FLOSS projects because they often 
come bundled with a certain (non-software-related) political orthodoxy.

The Contributor Covenant is the worst offender in this regard, having 
been created specifically for that purpose [1]. Although most of the 
offending text has now been removed from the document itself, the same 
spirit still follows behind it to projects that adopt the CC.

(It is also baffling to me that programmers would want to recreate an 
imitation HR department in their time off from the corporate world, but 
I'll put that aside.)

On Wed, Oct 24, 2018 at 12:02:37PM +0200, Ludovic Courtès wrote:
>
> Same here.  For the record, the code of conduct was adopted in Guix
> in Dec. 2015.

I hadn't noticed when I first started contributing. A bad code of 
conduct can still work out fine with good project leadership in place, 
which is why the Contributor Covenant was only one of several factors 
influencing my decision to move away from Guix.

I hope it is evident that I don't oppose the CoC out of a desire to 
behave badly. Please forgive some vagueness as well; I tried very hard 
not to provoke unnecessary controversy. As a result much of this email 
was edited out before sending.

-- 
Alex Griffin

[1]: https://twitter.com/coralineada/status/1041465346656530432

Re: Promoting the GNU Kind Communication Guidelines?

[Mathieu Lirzin]

Hello Ludo,

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

> Mathieu Lirzin  skribis:
>
>> Following the announcement made by RMS regarding the new GNU Kind
>> Communication Guidelines (GKCG) [1], I would like to know if the Guix
>> developpers in particular its maintainers would agree to adopt it in
>> place of the current Code of Conduct (CoC)?
>
> Speaking for myself: no.  I think the GKCG fails to address important
> issues, such as defining what’s acceptable and what’s not as well as
> clear processes to address this.

I am sad that you feels that the GKCG is not sufficient for defining the
acceptable behavior of the members of a Free Software community.

>> Adopting the GKCG instead of a CoC would help attracting people (like
>> me) who agree to use a welcoming and respectful language which
>> encourages everyone to contribute but are reluctant in contributing to
>> any project following a CoC due to its punitive nature and the politics
>> of its authors [2][3].
>
> Codes of conduct codify acceptable behavior and formalize processes:
> what can I do as a contributor if I’m a victim bad behavior or
> harassment?  What are the group communication rules?  What if I
> knowingly break those rules?
>
> By adopting the code of conduct, we maintainers committed to spend our
> time as needed to so your experience contributing to Guix won’t be a
> source of stress or worse, as is too often the case in on-line
> communities.
>
> The GKCG do not do that.  Problems will be dealt with in an ad hoc
> fashion (as they already are in groups that have not codified rules), if
> they are addressed at all.
>
> I hope this answers your question.

Yes it does perfectly.

I personnaly think dealing with such issues in an ad hoc fashion is the
right approach when acceptable behaviors are the norm, which IME has
been the case.

Anyway I still hope that the Guix community will eventually accept the
GKCG as an acceptable tradeoff in the CoC debate.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Mono and .NET Core

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

Hello!

> AFAIK nobody worked in this area yet, so you’ll probably have the
> privilege to be a pioneer!  :-)
>
> Mono was added by janneke (Cc’d), who might have something to add?

Nothing more than: yes, please go ahead and update it!  I created it for
a client of mine and thought it would be nice to share the result.

janneke

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

Re: Mono and .NET Core

[Brett Gilio]

Adam Van Ymeren writes:

> I tried to package .NET Core a while ago but didn't produce anything useful.  
> Their GNU/Linux story was rapidly changing at the time.
>
> .NET Core was a pain to package partly because it bootstraps from a binary 
> version of .NET Core similar to Rust.  Although it may be possible to 
> bootstrap via Mono I didn't try it and it's definitely not an upstream 
> supported route ;).
>
> Personally I ended up with just sticking to Mono for my C# needs as I found 
> .NET Core didn't integrate as nicely into the GNU/Linux ecosystem.
>
> That being said it would certainly be nice to have packages for it in Guix.
>
> On October 24, 2018 10:03:29 PM GMT+09:00, l...@gnu.org wrote:
>>Hello!
>>
>>Brett Gilio  skribis:
>>
>>> Two questions here.
>>>
>>> 1) Has anybody already started taking to try and upgrade Mono to
>>latest?
>>> If not, I will give it a go.
>>>
>>> 2) Have we started any packaging on .NET Core, would like to know to
>>> prevent redundancy in work.
>>
>>AFAIK nobody worked in this area yet, so you’ll probably have the
>>privilege to be a pioneer!  :-)
>>
>>Mono was added by janneke (Cc’d), who might have something to add?
>>
>>Ludo’.


>From what I see, coreclr https://github.com/dotnet/coreclr/ now uses a
build.sh script. Is it wise to simply use this in the package definition
to build it (I suspect not), or should the build system be configured
from scratch?

Re: Package variation

[Brett Gilio]

Ludovic Courtès writes:

> Hi!
>
> Brett Gilio  skribis:
>
>> I am trying to customize my the default gnome-package which gets
>> installed with the gnome-desktop-service.
>
> On this topic, don’t miss Chris’s excellent tutorial:
>
>   
> https://gnu.org/software/guix/blog/2018/customize-guixsd-use-stock-ssh-agent-everywhere/
>
> :-)
>
> Ludo’.

Thank you for the feedback Ludo. I read the article and made some
customizations, but something about setting the gnome-custom package is
still resulting in the regular gnome meta-package being used. I did some
interactive debugging using Guile, and it seems like nautilus is being
successfully removed, which is why my suspicion is on the package
setting being invalid. I've also tried a myriad of different ways of
setting the gnome-custom package, none of which seem to be resulting in
nautilus being removed. This isn't about "nautilus" per-say, but rather
being able to customize how gnome is used on my system.

Here is my current config.

(use-modules (gnu) (gnu system nss) (guix packages) (srfi srfi-1) (ice-9 match))
(use-service-modules desktop)
(use-package-modules certs gnome)

(define-public gnome-custom
(package (inherit gnome)
  (name "gnome-custom")
  (propagated-inputs (remove
   (match-lambda
 ((name _)
  (string=? name "nautilus")))
   (package-propagated-inputs gnome)


(operating-system

...

(services (cons* (gnome-desktop-service
#:config (gnome-desktop-configuration
  (gnome-package gnome-custom)))
   %desktop-services))


Any ideas?

Re: [outreachy] Further steps

[Laura Lazzati]

On Wed, Oct 24, 2018 at 4:01 AM Gábor Boskovits  wrote:
>
> Hello Laura,
>
> Congratulations!
>
> Björn Höfling  ezt írta (időpont:
> 2018. okt. 24., Sze, 7:17):
> >
> > On Tue, 23 Oct 2018 22:48:30 -0300
> > Laura Lazzati  wrote:
> >
> > > Hi all!
> > >
> > > I'm really happy that the patch worked :)
> > >
> > > Tomorrow -yet Tuesday here, I live in the past :P - I will close the
> > > in progress contribution.
> > >
> > > If you don't mind, I have some questions and need some feedback to go
> > > on.
> > >
> > > - As regards patches, for future ones:
> > >
> > > 1)Why my patch file (the one I sent) does not work applying it with
> > > git am in my local cloned repo? Do I need to create a new branch or
> > > something like that?
> >
>
> The last version you sent worked just fine for me. I could use git am
> without a problem. (I downloaded the attachment, and used git am on
> that)
> I used the current master, created a branch, then used git am to apply
> your patch. (I create a branch so that I don't touch master in my checkout,
> it should work without it)
>
> How was it failing for you?
I guess it was failing because of not branching. I pulled master,
branched, reset to a previous commit on the branch and am worked fine.
>
> > I think that was the problem. Here I already applied your patch and it
> > fails (On line 9 already because of the copyright header):
> >
> > ~/guix/wt/kde$ git log -1 | cat; git am ~/0001-gnu-Add-r-aspi.patch
> > commit c3ff36b4aa08caa8131b65a14caa03161b71e564
> > Author: Laura Lazzati 
> > Date:   Tue Oct 23 01:59:22 2018 -0300
> >
> > gnu: Add r-aspi.
> >
> > * gnu/packages/cran.scm (r-aspi): New variable.
> > Applying: gnu: Add r-aspi.
> > error: patch failed: gnu/packages/cran.scm:9
> > error: gnu/packages/cran.scm: patch does not apply
> > Patch failed at 0001 gnu: Add r-aspi.
> > hint: Use 'git am --show-current-patch' to see the failed patch
> > When you have resolved this problem, run "git am --continue".
> > If you prefer to skip this patch, run "git am --skip" instead.
> > To restore the original branch and stop patching, run "git am --abort".
Yes, I was getting that error too.
> >
> > My workflow usually is to get the lastest master and then to create and
> > work on a branch for that, for example "wip-r-aspi". Then I can create
> > another branch "wip-r-aspi2" and go  again from there. Usually I have
> > too many of those branches and have to clean up from time to tome.
> >
>
> Yes, the workflow Björn described works for me as well :)
> I git you often have a lot of branches, as they are cheap,
> and help to organize work. I also have to clean them up from time
> to time. I also tend to have throwaway branches,  where I just experiment.
>
Great! I will apply it too :)
> >
> > > 2)Where can I read about how to set an appropriate commit log? (not
> > > running just git log to see how they were generated before)
> >
> > That's a bit hidden, but documented: In section "7.5 Submitting
> > Patches" there is a link to the GNU Coding Standards:
> >
> > https://www.gnu.org/prep/standards/html_node/Change-Logs.html#Change-Logs
> >
> >
> > > 3) I added an eol with emacs editor, just as you mentioned. Could you
> > > send me your previous output about the error you were getting about
> > > that line break, if you still have it?
> >
> > I haven't looked into that broken patch. Gabor?
> >
>
> As we have those messages, you can have a look at the output yourself, just
> try to apply the inline patch from the mail. (You can download in mbox format
> from the debbugs interface)
>
> You will see an output similar to what Björn quoted above, except it will say:
> 'Corrupt patch at line 10' instead of 'patch does not apply'
>
> > > 4) I guess you already answered this one, but Is it ok to send patches
> > > attached to an email or is it strict to send them with git send-email
> > > when getting much more involved?
> >
> > It's OK. I think it comes more convenient when you have a long series
> > of patches, i.e. you add one package one its 20 dependencies, then you
> > get a series Patch[1/21]..., see the patch-tracker for examples. But
> > there are also some examples of people sending patches as attachments.
> >
>
> Yes, Björn is right here, it is easier to handle longer series with
> git send-email,
> but it is perfectly ok to send patches as attachments.
>
> >
> > > In the thread of mails, I have already asked you, but I would like to
> > > know how to continue from now on:
> > >
> > > I would like to go on contributing as much as possible up to November
> > > 6th (the deadline for applying for Outreachy).
> > > 1) Is it fine to go on packaging R packages that are not available
> > > yet, now that I know how to import them, modify them and the whole
> > > process?
> > > 2) Do you prefer another tasks to be done?
> >
> > I would say that R-packages is fine. Gabor do you see any specific
> > other tasks?
> >
>
> R-packages are fine for now.
>
> > If you have any other favourite

Re: [outreachy] Further steps

[Ricardo Wurmus]

Hi Laura,

>> > If you have any other favourite packages, you can give them also a try.
>> > It could just get more difficult, with more manual steps, other build
>> > systems, dependencies to be packed first, code to be patched, etc.
>> >
>>
>> Yes, this would also be good. Please tell us if you have any specific package
>> in mind.
> I guess I could package some more R packages, and then let me know
> which ones you think are more convenient, or you find more appealing
> for Guix.

All free R packages on CRAN are appealing from my perspective.  You can
also pick a package from Bioconductor, which might be a tad more
difficult, as that could depend not only on other Bioconductor packages
but also packages on CRAN.  Note that the importer does not
automatically switch between downloading from Bioconductor to
downloading from CRAN, so you may have to run the importer more than
once.

Use “guix import cran -a bioconductor -r PACKAGE” — when it aborts you
may have stumbled upon an unpackaged CRAN package.

R packages from Bioconductor should be added to the (gnu packages
bioconductor) module.

As far as learning new things goes: R packages usually are very simple.
They rarely ever require changes to the build system, so you don’t get
to learn about the “arguments” field of the “package” DSL.

Alternatively, you could look into making changes to the Texinfo
documentation.  For the project you would need to be somewhat familiar
with the manual, so it can’t hurt if you would edit it a little.  An
easy edit is to add a handful of “@cindex” lines to places in the manual
that currently miss them.  A “@cindex” line adds a location in the
manual to the index for a given keyword, so that people can find
relevant places in the manual more easily.

--
Ricardo

Re: Package variation

[Chris Marusich]

Hi Brett,

Brett Gilio  writes:

> Hi chris! Thank you for your feedback, and your insight. I appreciate it
> greatly. I have applied your changes (Both variations) and neither one
> seems to be working and nautilus remains on the system. I am honestly at
> a loss of what is wrong with the approach.

I'm glad to help!  Could you share your full operating system
configuration file?  I'd be happy to take a closer look.

-- 
Chris


signature.asc
Description: PGP signature

Re: GNU Guix Video Documentation

[Björn Höfling]

Hi Larissa,

welcome to Guix!

I'm putting the other Mentors/Coordinators and the developer list on
CC. Please answer to the mailing list, so others can help you out too.

On Wed, 24 Oct 2018 17:51:56 +0100
Larissa Leite  wrote:

> Hello,
> 
> My name is Larissa and I would love to contribute to the project.
> I am having some trouble finding where to start, so I have decided,
> after reading the reccommendations, to e-mail one of the mentors and
> introduce myself.
> I'm currently studying Media Production as an exchange student at the
> University of Lincoln, this project resonated with me the most,
> considering video editing is my passion and I love every opportunity
> to develop my editing skills.
> Besides editing, I would also enjoy helping with translation. I am
> Brazilian, so Portuguese is my native language, and I speak both
> English and Spanish fluently.
> If you could help me start my contribution, it would be great, I'm
> really excited to be a part of this project.

That sounds great. The first step would be to get familiar with Guix
and to make a contribution, that you can formally declare on the
Outreachy website.

To contribute, you can either prepare a package or update
documentation, though we would recommend packaging to get first
familiar with the system.

So your first step would be to install Guix or GuixSD and get into
it. You can either install Guix on top of another distro or you can
install GuixSD, the GNU/Linux-Distribution alone, either in a virtual
machine or a standalone hardware.

I think there is a link for both types from the Guix Outreachy site. I
will post them here too:

https://www.gnu.org/software/guix/manual/en/html_node/Binary-Installation.html#Binary-Installation

https://www.gnu.org/software/guix/manual/en/html_node/System-Installation.html#System-Installation

You can pack whatever software you like and is missing in Guix, though
it could get hard depending on your choice :-) So in general for a
beginner are R-packages recommended, we have also importers for that.


If you have any questions, ask on the mailing list or on IRC. The
community is very welcoming and willing to help.

Yours,

Björn


pgpSYUSZMNKge.pgp
Description: OpenPGP digital signature