Re: [GSOC 2020] network-boot-service

[Brice Waegeneire]

Hello Vagrant,

On 2020-07-02 16:34, Vagrant Cascadian wrote:

On 2020-07-02, Brice Waegeneire wrote:

To support the widest hardware and boot options possible I went with
iPXE
as a chainloader. Meaning that any machine doing a PXE boot (or with
builtin iPXE with restricted feature set) will load the iPXE 
bootloader

first, which will then properly load the initrd.


iPXE is really cool! The main downside is I don't think the support for
non-x86 architectures is there, but would be happy to find out
otherwise.



It looks like it does support arm 32 and 64 bits EFI:
https://ipxe.org/appnote/buildtargets. Anyway dnsmasq can be configured 
to
provide PXE entries by on the client's architecture or feature it 
support.
For example using network-boot-service, a iPXE client without http 
support

will chainload Guix's iPXE which has http support.

Currently I'm working on the initrd part to add NFS mounting 
capability

to
it. At this point I'm blocked by building a lightweight staticly built
'nfs-utils' package to be included in the initrd. It's current total
size
219.2 MiB, I manage to reduced it to 162.2 MiB which is still one 
order

of
magnitude larger than my initrd at 19 MiB.

My issue building a static 'nfs-utils' is that it can't find
'getrpcbynumber{,_r}' “configure: error: Neither getrpcbynumber_r nor
getrpcbynumber are available”. This function should be provided by the
libc
or by libtirpc if it's not that first one. The problem is that
'libtirpc'
don't build it's own 'getrpcbynumber' because it find one in libc but
nfs-utils can't find it...


Have you looked into using klibc (or maybe busybox) instead? They might
be smaller and have enough capability to mount NFS.


Non I did not, thanks for the tip. Busybox is smaller that was I
expecting, 1.0 MiB by itself, but it doesn't seems it would follow the
Guix way of doing most of the work in Guile (and using boot-to-Guile™)
and it's unique binary forbid us to extract only the NFS part. As for
klibc, it seems to be what NixOS[1] is using and TIL that it also the
the original source of Arch's mkinitcpio-nfs-utils which is 
unmaintained.

So klibc may work here, I'll try packaging it.


Some other distros are using the kernel parameter 'nfsroot'[2], but we
probably don't want to use it since it can't be used together with an
initrd and it also mean we need built-in modules for NFS and network
card
driver in the kernel.


Debian at least implements support for the nfsroot kernel parameter by
emulating the behavior in the initrd, using kernel modules instead of
built-ins. Seems like Guix could do the same?


Do you happen to know which package implement it in Debian? Yes, there
will be a need to pass parameters to the initrd so we better use the
common syntax.


If you're trying to use user-space NFS, I suspect you'll run into a lot
of issues... Debian at least dropped support for parts of the 
user-space

NFS stack years ago as it had huge numbers of bugs and little activity
upstream.


What do you mean by “user-space NFS”, be it nfs-utils, busybox or klibc,
they all are user-space tools to used to mount NFS shares?
Do you have some reference about this, I would like to learn more about
it. It's true that I did not find anyone trying to build a static
nfs-utils...


Great to hear about progress on this work!


live well,
  vagrant


[1]: 
https://github.com/NixOS/nixpkgs/commit/d25c1a8fdc383b8997f6e7b4e1479875df1f06b2
[2]: 
https://github.com/NixOS/nixpkgs/blob/84cf00f98031e93f389f1eb93c4a7374a33cc0a9/pkgs/os-specific/linux/mkinitcpio-nfs-utils/default.nix


- Brice

Re: [GSOC 2020] network-boot-service

[Vagrant Cascadian]

On 2020-07-02, Brice Waegeneire wrote:
> To support the widest hardware and boot options possible I went with 
> iPXE
> as a chainloader. Meaning that any machine doing a PXE boot (or with
> builtin iPXE with restricted feature set) will load the iPXE bootloader
> first, which will then properly load the initrd.

iPXE is really cool! The main downside is I don't think the support for
non-x86 architectures is there, but would be happy to find out
otherwise.


> Currently I'm working on the initrd part to add NFS mounting capability 
> to
> it. At this point I'm blocked by building a lightweight staticly built
> 'nfs-utils' package to be included in the initrd. It's current total 
> size
> 219.2 MiB, I manage to reduced it to 162.2 MiB which is still one order 
> of
> magnitude larger than my initrd at 19 MiB.
>
> My issue building a static 'nfs-utils' is that it can't find
> 'getrpcbynumber{,_r}' “configure: error: Neither getrpcbynumber_r nor
> getrpcbynumber are available”. This function should be provided by the 
> libc
> or by libtirpc if it's not that first one. The problem is that 
> 'libtirpc'
> don't build it's own 'getrpcbynumber' because it find one in libc but
> nfs-utils can't find it...

Have you looked into using klibc (or maybe busybox) instead? They might
be smaller and have enough capability to mount NFS.


> Some other distros are using the kernel parameter 'nfsroot'[2], but we
> probably don't want to use it since it can't be used together with an
> initrd and it also mean we need built-in modules for NFS and network 
> card
> driver in the kernel.

Debian at least implements support for the nfsroot kernel parameter by
emulating the behavior in the initrd, using kernel modules instead of
built-ins. Seems like Guix could do the same?

If you're trying to use user-space NFS, I suspect you'll run into a lot
of issues... Debian at least dropped support for parts of the user-space
NFS stack years ago as it had huge numbers of bugs and little activity
upstream.


Great to hear about progress on this work!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [GSOC 2020] network-boot-service

[Danny Milosavljevic]

Hi Brice,

On Thu, 02 Jul 2020 10:11:28 +
Brice Waegeneire  wrote:
> My issue building a static 'nfs-utils' is that it can't find
> 'getrpcbynumber{,_r}' “configure: error: Neither getrpcbynumber_r nor
> getrpcbynumber are available”. This function should be provided by the 
> libc
> or by libtirpc if it's not that first one. The problem is that 
> 'libtirpc'
> don't build it's own 'getrpcbynumber' because it find one in libc but
> nfs-utils can't find it...

Since glibc:static doesn't seem to contain it
(/gnu/store/rj4il3jjqg23cm3a0h17yzq3b5wa8llm-glibc-2.31-static/lib$
 objdump -t *.a |grep -i getrpcby returns nothing), we could make our
own variant of libtirpc that does enable their version.

> You can find the part of my work which is committed in the
> 'wip-network-boot' at https://git.sr.ht/~bricewge/guix.

Thanks!

I've checked it out, looks good so far!


pgpjOQbXaIJzM.pgp
Description: OpenPGP digital signature

Re: [GSoC 2020] [Proposal draft #1] Clojars importer for Guix

[Pjotr Prins]

Hi all,

There are some project proposals on GNU Guix that have no mentors
assigned including Leandro's. Please announce so now on GNU GSoC if you
are interested. 

Pj.

On Fri, Mar 27, 2020 at 04:47:41PM -0300, Leandro Doctors wrote:
> On Fri, 27 Mar 2020 at 01:09, Leandro Doctors  wrote:
> > Below, I share my second draft.
> 
> I've just realized I haven't used the template from the GNU GSoC
> Guidelines page[1]...
> Sorry for that. I will use that template for my next draft.
> 
> Best,
> Leandro
> 
> [1]: GNU guidelines for Summer of Code projects:
> https://www.gnu.org/software/soc-projects/guidelines.html
> 

Re: [GSOC 2020] Booting via network

[Vincent Legoll]

Hello,

On 15/04/2020 20:57, Brice Waegeneire wrote:

On 2020-03-30 22:10, Vincent Legoll wrote:

that's a great project, I hope to be able to lend a hand,
here and there...


Looks like you already started by packaging iPXE. :)
Thanks!



That one was a "release early", but I can't promise you

a "relase often"... ;-)


--

Vincent Legoll

Re: iPXE network booting (was Re: [GSOC 2020] Booting via network)

[Brice Waegeneire]

Hello Giovanni,

On 2020-04-10 13:44, Giovanni Biscuolo wrote:


[...]

I never used iPXE but... please consider using iPXE (if possible) for
Guix network booting and consider that this feature is a prerequisite
for seamless remote desktop with Guix (using x2go or xrdp like the new
LTSP is doing [1]) in addition to "diskless fat clients"; a very cool
feature, I think :-D


Since the proposal has already been submitted I can't promise to add 
iPXE

support in the context of this GSoC, however I will keep it in mind when
implementing PXE booting. If I'm able to finish it early I'll look into
adding iPXE booting as a bonus.


In addition to LAN booting, iPXE supports booting from:

* a web server via HTTP/HTTPS
* an iSCSI SAN
* a Fibre Channel SAN via FCoE
* an AoE SAN
* a wireless network
* a wide-area network
* an Infiniband network

inlcuding "code signing" to verify the authenticity and integrity of
files downloaded by iPXE.

Users will have many interesting, configurable [2] and secure ways to
boot Guix with iPXE :-D (imagine booting from a remote host connected
via a wireguard network connection... could it be possible?!?)


Wow, that sounds cool. I would like to find out if it's possible too.



[...]

HTH! Thanks, Gio'


Yes it is helping, really, that was dense with information.

Cheers,
- Brice

Re: [GSOC 2020] Booting via network

[Brice Waegeneire]

Hello Vagrant,

On 2020-03-30 23:16, Vagrant Cascadian wrote:
I was just thinking Guix needed network boot support yesterday! Happy 
to

hear you're looking into it...

I've been the LTSP maintainer in Debian for almost 15 years, so have a
good amount of experience with network booting. LTSP was rewritten from
scratch last year and there might be elements of it useful to you:

  https://ltsp.org

None of it is scheme code, but there are possibly some useful ideas in
there you could make use of. One of the big changes is making extensive
use of iPXE, though that might need some further auditing to meet the
FSDG (Free Software Distribution Guidelines?) for inclusion into Guix.


I see the rewrite has been done during a GSoC too; it's interesting that 
it

has mostly been done in shell. It looks like a interesting project, I'll
keep reading...

- Brice

Re: [GSOC 2020] Booting via network

[Brice Waegeneire]

Hello Vincent,

On 2020-03-30 22:10, Vincent Legoll wrote:

Hello,

that's a great project, I hope to be able to lend a hand,
here and there...


Looks like you already started by packaging iPXE. :)
Thanks!

- Brice

Re: iPXE network booting (was Re: [GSOC 2020] Booting via network)

[Vincent Legoll]

Hello,


in order to start the discussion and the project, what

about the patch in [1] ?


It's marked RFC as there are a few debatable points.


And it can be enhanced (building the efi firmwares, etc.)


[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=40579


--

Vincent Legoll

iPXE network booting (was Re: [GSOC 2020] Booting via network)

[Giovanni Biscuolo]

Hello Brice and Vagrant

Vagrant Cascadian  writes:

> On 2020-03-30, Brice Waegeneire wrote:
>> I know it's quite late to submit a GSOC proposal but here it's.
>> I would like to work on the project suggested by Danny to
>> add PXE support to Guix. Which has been requested several
>> times on IRC and in the ML. This would get us a step closer
>> to provisioning bare bone machines directly from Guix.

Great feature, I hope you are not too late

[...]

>   https://ltsp.org

Thanks Vagrant for your work with LTSP in Debian!!!

I'm an _enthusiastic_ user of LTSP (LTSP5 now, but soon I'll experiment
20.04) and I'll be very happy to test (and help as I can) develop this
Guix feature (network booting, I mean).

I never used iPXE but... please consider using iPXE (if possible) for
Guix network booting and consider that this feature is a prerequisite
for seamless remote desktop with Guix (using x2go or xrdp like the new
LTSP is doing [1]) in addition to "diskless fat clients"; a very cool
feature, I think :-D

In addition to LAN booting, iPXE supports booting from:

* a web server via HTTP/HTTPS
* an iSCSI SAN
* a Fibre Channel SAN via FCoE
* an AoE SAN
* a wireless network
* a wide-area network
* an Infiniband network

inlcuding "code signing" to verify the authenticity and integrity of
files downloaded by iPXE.

Users will have many interesting, configurable [2] and secure ways to
boot Guix with iPXE :-D (imagine booting from a remote host connected
via a wireguard network connection... could it be possible?!?)

> None of it is scheme code, but there are possibly some useful ideas in
> there you could make use of. One of the big changes is making extensive
> use of iPXE, though that might need some further auditing to meet the
> FSDG (Free Software Distribution Guidelines?) for inclusion into Guix.

Vagrant plz do you have some specific potential issue in mind?

iPXE AFAIU is completely free software https://ipxe.org/licensing , it
also contains a tool that produces a detailed license analysis for each
ROM file.

On Guix iPXE could be used in "chainloading mode" [3] if the network
card already have a PXE implementation or - for advenced users - could
replace the network card ROM [4]: Guix service configuration should then
allow disabling chainloading for advanced users.

iPXE is still not packaged for Guix but it should not be hard to package
since AFAIU it uses standard GNU build tools and deps are all already
packaged (not sure about mkisofs and syslinux):

https://ipxe.org/download:
--8<---cut here---start->8---

[...]

build it using:

  cd ipxe/src
  make

You will need to have at least the following packages installed in order to 
build iPXE:

gcc (version 3 or later)
binutils (version 2.18 or later)
make
perl
liblzma or xz header files
mtools
mkisofs (needed only for building .iso images)
syslinux (for isolinux, needed only for building .iso images)

[...]

--8<---cut here---end--->8---

Making a iPXE ISO image could be useful to boot from CD-ROM/USB on
machines lacking NIC supporting PXE (do they still exist?)


HTH! Thanks, Gio'




[1] https://github.com/ltsp/community/issues/4: «thin client support is
now reduced to "remote desktop with xfreerdp / x2go / VNC".»
Exept VNC (that I do not consider useful in this scenario), x2go and
xrdp are still not packaged in Guix but we can work it out

[2] https://ipxe.org/embed and https://ipxe.org/scripting (including
dynamic scripts)

[3] https://ipxe.org/download#chainloading_from_an_existing_pxe_rom

[4] https://ipxe.org/howto/romburning

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: [GSoC 2020] [Final Proposal] Clojars importer for Guix

[Pierre Neidhardt]

Hi Leandro,

A quick message to let you know that I'm very excited by your project!
I've recently started developing with Clojure and I'd love to see a
Clojars importer become reality!

Good luck!

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


signature.asc
Description: PGP signature

Re: [GSoC 2020] [Final Proposal] Clojars importer for Guix

[Leandro Doctors]

On Tue, 31 Mar 2020 at 15:06, Leandro Doctors  wrote:
> Below, I share the final version I uploaded to the GSoC website.

Another bug: I didn't mention how I plan to publicly report my
progress over the course of my work. Besides the normal interaction
via this list, I will send (at least) three progress reports. One
progress report to this list (with a post on the Guix blog) after each
Evaluation. Additionally, I may also send irregular updates when I
achieve important milestones.

Sorry for this oversight,
Leandro

Re: [GSOC 2020] Final proposal

[Alberto EFG]

Ricardo Wurmus writes:

> Hi Alberto,
>
>> Hello, this is my final proposal for GSoC, there is still time to do
>> some changes in case anyone has feedback, otherwise this is it :)
>
> Thank you for this thorough proposal!
>
> For 8.5 it would be good to provide criteria that allow us to evaluate
> your progress.  Being able to look at the code is obviously a
> precondition, but what we really want to know is what features will have
> to have been completed (and to what degree) at the time of the
> evaluation.
>
> For some of the deliverables and goals it would be good to see a little
> more detail if possible.  You mention systemd.device and systemd.socket
> files, but I can’t imagine what your goals with regards to the Shepherd
> are — is it to implement a similar feature (what exactly would that
> be?), or support for reading these files…?

Thank you so much for all the feedback!! I add my proposal with the
suggested changes.

I tried to be more specific with the goals, and the milestones. I added
a section, so number 8.5 is now 8.6, however I tried to be more specific
in the timeline than in 8.5.

Ludovic told me to focus my main goal on improving Shepherd internals,
rather than the systemd unit files parsing as that would be the "icing on
the cake", I hope that it is reflected on my proposal.

There is still a really short amount of time for last minute changes,
but this will probably be it.


proposal-final.pdf
Description: Adobe PDF document

Re: [GSOC 2020] Booting via network

[Vagrant Cascadian]

On 2020-03-30, Brice Waegeneire wrote:
> I know it's quite late to submit a GSOC proposal but here it's.
> I would like to work on the project suggested by Danny to
> add PXE support to Guix. Which has been requested several
> times on IRC and in the ML. This would get us a step closer
> to provisioning bare bone machines directly from Guix.

I was just thinking Guix needed network boot support yesterday! Happy to
hear you're looking into it...

I've been the LTSP maintainer in Debian for almost 15 years, so have a
good amount of experience with network booting. LTSP was rewritten from
scratch last year and there might be elements of it useful to you:

  https://ltsp.org

None of it is scheme code, but there are possibly some useful ideas in
there you could make use of. One of the big changes is making extensive
use of iPXE, though that might need some further auditing to meet the
FSDG (Free Software Distribution Guidelines?) for inclusion into Guix.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: [GSOC 2020] Booting via network

[Vincent Legoll]

Hello,

that's a great project, I hope to be able to lend a hand,
here and there...

-- 
Vincent Legoll

Re: [GSOC 2020] Final proposal

[Ricardo Wurmus]

Hi Alberto,

> Hello, this is my final proposal for GSoC, there is still time to do
> some changes in case anyone has feedback, otherwise this is it :)

Thank you for this thorough proposal!

For 8.5 it would be good to provide criteria that allow us to evaluate
your progress.  Being able to look at the code is obviously a
precondition, but what we really want to know is what features will have
to have been completed (and to what degree) at the time of the
evaluation.

For some of the deliverables and goals it would be good to see a little
more detail if possible.  You mention systemd.device and systemd.socket
files, but I can’t imagine what your goals with regards to the Shepherd
are — is it to implement a similar feature (what exactly would that
be?), or support for reading these files…?

--
Ricardo

Re: [GSoC 2020] [Proposal draft #1] Clojars importer for Guix

[Leandro Doctors]

On Fri, 27 Mar 2020 at 01:09, Leandro Doctors  wrote:
> Below, I share my second draft.

I've just realized I haven't used the template from the GNU GSoC
Guidelines page[1]...
Sorry for that. I will use that template for my next draft.

Best,
Leandro

[1]: GNU guidelines for Summer of Code projects:
https://www.gnu.org/software/soc-projects/guidelines.html

Re: [GSoC 2020] [Proposal draft #0] Initial JVM support for Guix

[Leandro Doctors]

On Mon, 23 Mar 2020 at 14:00, Julien Lepiller  wrote:
> Le 23 mars 2020 12:06:12 GMT-04:00, Leandro Doctors  a 
> écrit :
> >Even though I don't have data to back up this claim, in the
> >Guix-Jupyter Scicloj video session [1] they mention that, in the case
> >of Clojure, most packages usually include sources.
> I'll check, thanks :)

If you only are interested in the Clojure-related comments, only watch
the last 25' or so from the video.


> >I guess this means I should focus on Clojars?
> From what you say, yes.

> Does it sound doable?

I think it does. It will be a Clojars importer, then :-)
We'll see how far can I take the idea...


Best,
Leandro

Re: [GSoC 2020] [Proposal draft #0] Initial JVM support for Guix

[Julien Lepiller]

Le 23 mars 2020 12:06:12 GMT-04:00, Leandro Doctors  a 
écrit :
>On Mon, 23 Mar 2020 at 12:39, Julien Lepiller 
>wrote:
>
>> Hi Leandro!
>
>Hi, Julien,
>
>Thanks a lot for your feedback! I add my comments below.
>
>
>> I'm glad you're interested in JVM languages.
>
>In fact, I am only interested in Clojure... However, given that
>Clojure is hosted on the JVM, it seems very difficult to me not to
>think in JVM terms when describing a "Clojure importer". This is the
>main reason behind the proposal name change from my previous emails.
>
>
>> I cannot find a way to I am currently trying to build a proper
>maven-build-system (it's a matter of days now).
>
>Again, I am only speaking in JVM terms because of Clojure's hosted
>nature.

Actually, I'm interested in android apps, but maven ended up being a 
requirement ^^"

>
>
>> Some of the issues we have with JVM languages and that you should
>take into account  for your proposal:
>[...]
>
>Thanks for this!
>
>
>> - maven allows programmers to upload a "source" jar, but it is meant
>for debugging, contains generated sources and might be incomplete.
>
>Even though I don't have data to back up this claim, in the
>Guix-Jupyter Scicloj video session [1] they mention that, in the case
>of Clojure, most packages usually include sources.
>
>[1] Guix-Jupyter Scicloj video session from January 9th, 2020.
>https://scicloj.github.io/posts/2020-03-07-guix-jupyter/

I'll check, thanks :)

>
>
>> - maven doesn't link to source repositories
>
>You're right.
>
>However, Clojars (the primary hub for Clojure packages) does. Maybe
>implementing Clojars support could be a first step?
>(I still have to assess this, as there are many Clojure packages that
>are published primarily in Maven Central...)
>
>
>> - how to find a source repository from a groupId and an artifactId is
>not clear to me.
>
>Considering the previous points, this seems mostly a Java-specific
>problem?
>
>
>> Considering that, I don't know if your project is doable. At least,
>all other importers are able to give you a working source, but if it's
>> really impossible, having a list of dependencies would already be
>great :)
>
>I agree with you in that this does seem non-trivial...
>Perhaps, this could be a research-oriented project? I mean, to see
>whether it is feasible to (eventually) support the JVM, and the major
>milestone being a minimalistic POC implementation for Clojars support?
>
>
>> We have a lot of java packages, but none of them are usable with
>maven yet. I've worked on those that are directly required to run
>> maven and its common plugins already, and will send patches as soon
>as everything works. There will need to be a huge work on
>> these packages to rebuild them, probably with the maven-build-system.
>
>I guess this means I should focus on Clojars?

From what you say, yes. A clojars importer would be great. If/when we find 
other ways to be able to import other JVM packages, we'll be able to improve 
upon that work :). Maybe the importer could work in that way:

Import from Clojars, if it fails, import from central, without source 
information. Basically, try multiple repos, from the most specific (that have 
source info) to more generic (that at least haveqversion and dependency 
information).

If you leave some space to be able to plug in other sources (eg. when we have 
scala, for sbt repos), I think you'll have a substantial contribution :). Does 
it sound doable?

>
>
>Best,
>Leandro

Re: [GSoC 2020] [Proposal draft #0] Initial JVM support for Guix

[Leandro Doctors]

On Mon, 23 Mar 2020 at 12:39, Julien Lepiller  wrote:

> Hi Leandro!

Hi, Julien,

Thanks a lot for your feedback! I add my comments below.


> I'm glad you're interested in JVM languages.

In fact, I am only interested in Clojure... However, given that
Clojure is hosted on the JVM, it seems very difficult to me not to
think in JVM terms when describing a "Clojure importer". This is the
main reason behind the proposal name change from my previous emails.


> I cannot find a way to I am currently trying to build a proper 
> maven-build-system (it's a matter of days now).

Again, I am only speaking in JVM terms because of Clojure's hosted nature.


> Some of the issues we have with JVM languages and that you should take into 
> account  for your proposal:
[...]

Thanks for this!


> - maven allows programmers to upload a "source" jar, but it is meant for 
> debugging, contains generated sources and might be incomplete.

Even though I don't have data to back up this claim, in the
Guix-Jupyter Scicloj video session [1] they mention that, in the case
of Clojure, most packages usually include sources.

[1] Guix-Jupyter Scicloj video session from January 9th, 2020.
https://scicloj.github.io/posts/2020-03-07-guix-jupyter/


> - maven doesn't link to source repositories

You're right.

However, Clojars (the primary hub for Clojure packages) does. Maybe
implementing Clojars support could be a first step?
(I still have to assess this, as there are many Clojure packages that
are published primarily in Maven Central...)


> - how to find a source repository from a groupId and an artifactId is not 
> clear to me.

Considering the previous points, this seems mostly a Java-specific problem?


> Considering that, I don't know if your project is doable. At least, all other 
> importers are able to give you a working source, but if it's
> really impossible, having a list of dependencies would already be great :)

I agree with you in that this does seem non-trivial...
Perhaps, this could be a research-oriented project? I mean, to see
whether it is feasible to (eventually) support the JVM, and the major
milestone being a minimalistic POC implementation for Clojars support?


> We have a lot of java packages, but none of them are usable with maven yet. 
> I've worked on those that are directly required to run
> maven and its common plugins already, and will send patches as soon as 
> everything works. There will need to be a huge work on
> these packages to rebuild them, probably with the maven-build-system.

I guess this means I should focus on Clojars?


Best,
Leandro

Re: [GSoC 2020] [Proposal draft #0] Initial JVM support for Guix

[Julien Lepiller]

Le 23 mars 2020 11:21:06 GMT-04:00, Leandro Doctors  a 
écrit :
>On Fri, 20 Mar 2020 at 21:41, Leandro Doctors 
>wrote:
>>  On Tue, 3 Mar 2020 at 19:32, zimoun 
>wrote:
>> > Based on your interests (Clojure, Leiningen, etc.), you should
>> > consider something around a Clojure "importer".
>>
>> I am preparing my proposal. I will send it in the next few days.
>
>Hello, everybody!
>
>This is my first draft (at the bottom of this message). Please note
>that the document is in a very early stage, so at this point there are
>still many questions unanswered (to which I have added some notes
>below).
>
>Your feedback will be crucial in answering questions and evolving the
>attached draft into a full proposal.
>
>Best,
>Leandro
>
>
>** Notes **
>- Whereas I may switch to org-mode, I am currently using LyX for
>writing the proposal.
>- I thought plain text was the best for getting feedback. If you think
>another format is better (Markdown, LaTeX, PDF...) please let me know.
>Pandoc is my friend :-)
>- I watched the whole Guix-Jupyter Scicloj video session from last
>January 9th, 2020.
>https://scicloj.github.io/posts/2020-03-07-guix-jupyter/
>- From what I see, in Guix there are compilers and importers (I'm in
>the process of getting familiar to this terminology).
>- There is already a compiler for Clojure, and Clojure has been
>packaged into Guix. However, there is no importer for Clojure
>packages...
>- I agree with some comments from the talk: given that Clojure is a
>hosted language, merely importing "Clojure packages" is impossible. In
>this case, as Clojure is hosted in the JVM, we should aim to importing
>Maven (an eventually, also Clojars) packages. So, adding "Clojure
>support" would mean "adding JVM support".
>- I guess that supporting tools/deps.edn would enable supporting Maven
>dependencies?
>- Packaging clojupyter would be a potential task to consider during
>the first coding period (maybe even before?)
>
>
>
>
> Draft **
>
>
>Initial JVM support for Guix
>
>Leandro Doctors
>
>
>1 Overview
>
>Add support for importing JVM packages (jar files) into Guix.
>
>
>2 Status Quo
>
>Guix supports importing package metadata from multiple sources.
>Currently, these sources are as diverse as GNU packages,
>repositories such as the Python Package Index and the
>Comprehensive R Archive Network, and JSON files. However, there
>is another source not yet supported by Guix: JVM-based languages.
>Currently, Guix does not support importing from any JVM-based
>language, such as Java, Clojure. Considering Java is the most
>used programming language, this would be a very valuable addition
>for Guix.
>
>
>3 Status Desideravit
>
>
>3.1 Objectives
>
>1. Add a JVM importer.
>
>2. Also support Clojure jars.
>
>
>3.2 Benefits
>
>• Gain access to the JVM environment.
>
>
>4 Implementation Plan
>
>
>4.1 Stages & Deliverables
>
>
>
>4.2 Timeline & Milestones
>
>
>Note: I have considered 5-days weeks for all periods, so there
>can be slack time if needed.
>
>1. Student Application Period (March 16th - 31st) (2 weeks)
>
>  • Start flicking through Guix's code. [done]
>  • Set up a development environment. [done]
>  • Start learning the basics about Guix's internal processes
>(release management, developer interactions, codes of
>conduct...).
>  • Start reading Guix documentation. [in progress]
>  • Start exploring possible approaches to implement proposed
>features. [in progress]
>
>2. Application Review Period (March 31st - April 27th) (4 weeks)
>
>  • Open PRs with small code and/or documentation glitches
>discovered during the first step of this list.
>  • Finish reading introductory material.
>  • Start experimenting with possible approaches to implement
>proposed features.
>  • Finish learning the basics about Guix internal processes
>(release management, developer interactions, codes of
>conduct...).
>  • Continue hacking into Guix's codebase to get to know it
>better.
>  • Engage with the Community and develop possible features not
>initially considered.
>
>
>3. Student Projects Announced (April 27th) (1 day)
>
>4. Community Bonding (April 27th - May 18th) (3 weeks)
>
>  • Continue hacking into Guix's codebase to get to know it
>better.
>  • Finish experimenting with possible approaches found during
>the Application Review period with which to implement
>proposed features.
>  • Explore options to implement proposed features.
>  • Re-assessment of implementation difficulty proposed features.
>
>5. Coding #1 (May 18th - June 12th) (4 working weeks)
>
>  Implement Stage #1:
>
>  (a) Weeks 1 & 2: 
>i. 
>
>Milestones:
>i. M1.1: 
>
>  (b) Weeks 2 & 3
>
>  (c) Week 4
>
>6. Partial Evaluation #1 (June 15th - 19th) (1 buffer week)
>
>  (a) Week 5: (Buffer)
>
>Milestones:
>i. (finish unfinished milestones)
>
>7. Coding #2 (June 23rd - July 10th) (3 working weeks)
>
>  Implement Stage #2:
>
>  (a) Week 6
>
>  (b) Week 7
>
>  (c)

"Technical preview" / "Beta" features in Guix? (it was Re: [GSoC 2020] Clojure importer for Guix?)

[Leandro Doctors]

On Sat, 21 Mar 2020 at 14:56, Pjotr Prins  wrote:
> On Fri, Mar 20, 2020 at 09:41:05PM -0300, Leandro Doctors wrote:
> > I am also checking Jelle Licht's 2016 GSoC project (the npm importer).
> > From what I understand, Jelle's code was never merged back into guix.
> > As I'm trying to learn from the past, could anyone please ellaborate
> > on why was that code never merged?
> Circular dependencies on a large scale. We don't really have an answer
> for that.

I see.

That being considered, why not enable that importer as "technical
preview" or "beta"? This would enable other people to realize the code
already exists, and enable potential contributors to eventually
improve the feature.

Think would be something similar to Debian's "llibgstreamer-plugins-bad1.0-0":

"GStreamer Bad Plug-ins is a set of plug-ins that aren't up to par compared
to the rest. They might be close to being good quality, but they're missing
something - be it a good code review, some documentation, a set of tests, a
real live maintainer, or some actual wide use. [...] The API is not
guaranteed to be stable."

https://packages.debian.org/sid/libgstreamer-plugins-bad1.0-0


Or is it just that I'm missing something from the documentation?

--Leandro

Re: [GSoC 2020] Clojure importer for Guix?

[Pjotr Prins]

On Fri, Mar 20, 2020 at 09:41:05PM -0300, Leandro Doctors wrote:
> I am also checking Jelle Licht's 2016 GSoC project (the npm importer).
> From what I understand, Jelle's code was never merged back into guix.
> As I'm trying to learn from the past, could anyone please ellaborate
> on why was that code never merged?

Circular dependencies on a large scale. We don't really have an answer
for that.

Pj.

Re: [GSoC 2020] Clojure importer for Guix?

[Ludovic Courtès]

Hi,

Leandro Doctors  skribis:

> I am preparing my proposal. I will send it in the next few days.

Nice!

> I am currently checking current guix importers, and their documentation.
> In particular, I have been reading the source code from the Python and
> Haskell importers.
>
> I am also checking Jelle Licht's 2016 GSoC project (the npm importer).
> From what I understand, Jelle's code was never merged back into guix.
> As I'm trying to learn from the past, could anyone please ellaborate
> on why was that code never merged?
>
> Regarding packaging clojupyter... I understand that I will need at
> least one full application to eventually test the importer. That being
> said... is there any particular value in packaging clojupyter? Could
> you please name a few "essential" Clojure projects you would like to
> see packaged for guix?

I think Clojupyter would be nice to have.  One could then run:

  guix environment --ad-hoc jupyter clojupyer -- jupyter notebook

to spawn a Clojure-enabled notebook.

Thanks,
Ludo’.

Re: [GSOC 2020] Introduction and asking for feedback

[Ludovic Courtès]

Hi Alberto,

Blackbeard  skribis:

> I want to apply to Google Summer of Code. The ideas I am most interested are
> a) for GNU Guix: 'Content-addressed protocol for substitutes' and b) for
> GNU Shepherd:  "Syntax and semantics of systemd units in the Shepherd",
> because I have a feeling any of this two would improve the experience
> of most
> Guix users.
>
> However, I would like to ask for feedback in which might be a better option,
> I would like to chose a project that I can get help and the community is
> interested in.
>
> Any help with the project and proposal would be much appreciated.

I’ll answer because I’m listed as mentor at
, though honestly, I
think this would have to be someone else or you’ll get very frustrated.
:-)

For both projects, I encourage you to follow the links to get a better
understanding of what the project means.  For project (a), please also
familiarize yourself with substitutes, how they work, and perhaps have a
look at the (guix scripts substitute) and (guix scripts publish) modules
(they may be intimidating at first, so don’t expect to grasp every
detail from day 1, that’s fine!).

For project (b), I’d encourage you to take a look at the Shepherd: it’s
a small project and relatively easy to follow, I think.  If you’re not
familiar with systemd units, you can read

and find what mechanisms are missing from the Shepherd’s API at
.
Pick a specific feature (e.g., “socket activation”), and think about
what it would take to implement it in the Shepherd.

>From there, you can go ahead and ask specific questions about things you
don’t understand here or on IRC.

Happy hacking!  :-)

Ludo’.

Re: [GSOC 2020] Guix Deploy, round 2!

[Ludovic Courtès]

Hi!

Gábor Boskovits  skribis:

> Ludovic Courtès  ezt írta (időpont: 2020. márc. 8., Vas
> 23:10):

[...]

>> What I miss the most, especially on the build farm, is the ability to
>> tell ‘guix deploy’ which services to restart upon completion.
>> Currently, like ‘guix system reconfigure’, it conservatively doesn’t
>> restart any running services.  However, often, you’d like it to run
>> “herd restart X” upon completion.
>>
>> Another thing discussed at the Guix Days, but more relevant to more
>> advanced use cases, is the ability to define “roles”: often you’d rather
>> want to think in terms of the services machines offer and abstract over
>> the actual machines.
>>
>
> These are both great ideas. It would be also nice to access these in a
> single machine setup. I don't know where to implement this, it might make
> sense to add these to the common part of deploy and reconfigure. IIRC we
> also discussed the idea of a local deployer to be able handle the deploy
> node the same way as the rest.

If you talking about the first point above, I think it’s not that
difficult.  As I see it, we could provide a command-line option and/or a
 option (?) specifying which services should be restarted right
away.  Restarting can be implemented as in (guix scripts system
reconfigure).

> Regarding the roles thing it would be nice to get a discussion going
> regarding the interface, so that we have an idea how it should look
> like. Wdyt?

Yes, that would be nice!  There were good ideas discussed at the Guix
Days and knowledgeable people, but I can’t see the notes at

and I’m not sure who was involved.  There was probably Chris Marusich,
who else?  People, please step up!  :-)

Ludo’.

Re: [GSOC 2020] Guix Deploy, round 2!

[Gábor Boskovits]

Hello,

Ludovic Courtès  ezt írta (időpont: 2020. márc. 8., Vas
23:10):

> Hi Chris!
>
> Christopher Lemmer Webber  skribis:
>
> > Let me also put out a goal for the Guix community: I think we'll see
> > Guix Deploy as a success if a bunch of us can switch over to using it on
> > our own servers (that includes me).  To that end, I'd love to know, how
> > many people are doing so, or have attempted to do so?  What features
> > would you like/need?
>
> We’re using it for the build farm, and I’m also using it for a couple of
> single servers.  It’s great!  :-)
>
> What I miss the most, especially on the build farm, is the ability to
> tell ‘guix deploy’ which services to restart upon completion.
> Currently, like ‘guix system reconfigure’, it conservatively doesn’t
> restart any running services.  However, often, you’d like it to run
> “herd restart X” upon completion.
>
> Another thing discussed at the Guix Days, but more relevant to more
> advanced use cases, is the ability to define “roles”: often you’d rather
> want to think in terms of the services machines offer and abstract over
> the actual machines.
>

These are both great ideas. It would be also nice to access these in a
single machine setup. I don't know where to implement this, it might make
sense to add these to the common part of deploy and reconfigure. IIRC we
also discussed the idea of a local deployer to be able handle the deploy
node the same way as the rest. Regarding the roles thing it would be nice
to get a discussion going regarding the interface, so that we have an idea
how it should look like. Wdyt?

>
> Ludo’.
>
Best regards,
g_bor

>
>

Re: [GSOC 2020] Guix Deploy, round 2!

[Ludovic Courtès]

Hi Chris!

Christopher Lemmer Webber  skribis:

> Let me also put out a goal for the Guix community: I think we'll see
> Guix Deploy as a success if a bunch of us can switch over to using it on
> our own servers (that includes me).  To that end, I'd love to know, how
> many people are doing so, or have attempted to do so?  What features
> would you like/need?

We’re using it for the build farm, and I’m also using it for a couple of
single servers.  It’s great!  :-)

What I miss the most, especially on the build farm, is the ability to
tell ‘guix deploy’ which services to restart upon completion.
Currently, like ‘guix system reconfigure’, it conservatively doesn’t
restart any running services.  However, often, you’d like it to run
“herd restart X” upon completion.

Another thing discussed at the Guix Days, but more relevant to more
advanced use cases, is the ability to define “roles”: often you’d rather
want to think in terms of the services machines offer and abstract over
the actual machines.

Ludo’.

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[Gábor Boskovits]

Hello Leandro,

Leandro Doctors  ezt írta (időpont: 2020. márc. 3., Ke
23:45):

> On Tue, 3 Mar 2020 at 19:32, zimoun  wrote:
> > Based on your interests (Clojure, Leiningen, etc.), you should
> > consider something around a Clojure "importer". (Note that I am
> > ignorant about the Java ecosystem.)
>
> Thanks for the idea, Simon!
>
>
> > Currently, it is possible to import Python packages from PyPI, or
> > Haskell packages from Hackage, or etc. see [1] and something about
> > Clojure seems missing. I am quoting Ludo from [2]:
>
> Thanks for the pointers!
> I will check these projects and let you know.
>
>
> On another side, I will be offline for a fer days, so I expect to
> start working on my proposal draft from March 16th onwards.
> Would it be OK if I publish a project draft on
> GoogleDocs/GitHub/GitLab in (let's say) MarkDown by March 20th, so
> people can easily comment on it? I think getting feedback on a
> document via email may be quite difficult...
> Please, state your preference.
>

Another option would be to add it to the ideas page in a comment. When it
is ready, it would be easy to publish it by uncommenting. That way the
ideas would stay om the same place.

Best regards,
g_bor

>
> Best,
> Leandro
>
>

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[Leandro Doctors]

On Tue, 3 Mar 2020 at 19:32, zimoun  wrote:
> Based on your interests (Clojure, Leiningen, etc.), you should
> consider something around a Clojure "importer". (Note that I am
> ignorant about the Java ecosystem.)

Thanks for the idea, Simon!


> Currently, it is possible to import Python packages from PyPI, or
> Haskell packages from Hackage, or etc. see [1] and something about
> Clojure seems missing. I am quoting Ludo from [2]:

Thanks for the pointers!
I will check these projects and let you know.


On another side, I will be offline for a fer days, so I expect to
start working on my proposal draft from March 16th onwards.
Would it be OK if I publish a project draft on
GoogleDocs/GitHub/GitLab in (let's say) MarkDown by March 20th, so
people can easily comment on it? I think getting feedback on a
document via email may be quite difficult...
Please, state your preference.

Best,
Leandro

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[zimoun]

Dear Leandro,

On Wed, 26 Feb 2020 at 23:42, Leandro Doctors  wrote:

> I am interested in the Scheme-based ideas. (I have recently
> rediscovered LISP, and I am a Clojure fan.) However, I haven't found
> any indication on how to proceed in the Ideas page [1].

Elsewhere, you have been discussing a proposal of about "Guile build
tool"; which IMHO a large and hard task.

Based on your interests (Clojure, Leiningen, etc.), you should
consider something around a Clojure "importer". (Note that I am
ignorant about the Java ecosystem.)

Currently, it is possible to import Python packages from PyPI, or
Haskell packages from Hackage, or etc. see [1] and something about
Clojure seems missing. I am quoting Ludo from [2]:

--8<---cut here---start->8---
Now we should keep in touch with the Clojure folks to work on an
importer (I learned about “tools.deps”) and to get Clojupyter packaged…
--8<---cut here---end--->8---

and then Jupyter is a "poor-man web-browser" version of Org-mode (very
opinionated! ;-)) and Clojupyter [3] is one of its kernel.


[1] https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-import.html
[2] https://lists.gnu.org/archive/html/guix-devel/2020-01/msg00189.html
[3] https://github.com/clojupyter/clojupyter


Well, hope that helps as feedback.

Thanks,
simon

Re: [GSOC 2020] Idea: Guile based build-tool

[Leandro Doctors]

Thanks for the link, Simon!
--Leandro

On Mon, 2 Mar 2020, 07:03 zimoun,  wrote:

> Dear,
>
> Perhaps, some inspiration about build systems in this paper [1] by
> Haskellers.
>
> [1]
> https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems-final.pdf
>
>
> All the best,
> simon
>

Re: [GSOC 2020] Idea: Guile based build-tool

[zimoun]

Dear,

Perhaps, some inspiration about build systems in this paper [1] by Haskellers.

[1] 
https://www.microsoft.com/en-us/research/uploads/prod/2018/03/build-systems-final.pdf


All the best,
simon

Re: [GSOC 2020] Guix Deploy, round 2!

[Gábor Boskovits]

Hello Chris,

Christopher Lemmer Webber  ezt írta (időpont: 2020.
febr. 29., Szo 17:55):

> Hello,
>
> I'd be interested in doing a round 2 of mentoring for Guix Deploy.
> The previous student (Jakob L. Kreuze) will not be a GSoC student this
> year but is willing to co-mentor.  (Maybe David Thompson is as well but
> I won't speak for him since we haven't discussed it yet.)
>

Wonderful idea, please add it to the GSoC 2020 ideas page if you haven't
done so.


> I don't know what the situation with Outreachy slots are, but I'd also
> be happy to mentor this for there as well, obviously.
>

The proposal deadline for this round has passed, so we can't do that right
now. If we still have work to do in this area ( I believe we will) when the
next round comes around, I will be happy to help in forming the proposal. I
will soon publish a blog post with the relevant deadlines for both program.


> I think there's probably more that can be done to improve environments.
> This includes initial bootstrapping of environments, making more
> environments available, etc.
>
> Let me also put out a goal for the Guix community: I think we'll see
> Guix Deploy as a success if a bunch of us can switch over to using it on
> our own servers (that includes me).  To that end, I'd love to know, how
> many people are doing so, or have attempted to do so?  What features
> would you like/need?
>

I believe this is a great initiative. Thanks for bringing this up.

>
>  - Chris
>

Best regards,
g_bor

>
>

Re: [GSOC 2020] Idea: Guile based build-tool

[Christopher Lemmer Webber]

There have been some conversations about using Guix's tooling as a build
tool in the past.

Personally, what I would prefer to see is a Guile-based build tool that
is standalone; an alternative for autotools basically.  That then could
be used *in combination with* Guix quite nicely... use the Guile-based
build tool for describing how to build your packages, use "guix
environment" to pull in all the dependencies and create the dev
environment, and of course this tool would then be used for package
definitions too.

However I think this is not a small task, and would take someone who is
willing to do a fair amount of research, or is already familiar with the
problem domain.  It may be hard to finish in a single summer.


Leandro Doctors writes:

> Hi, all,
>
> I am starting to do some research on this idea.
>
> Even though I haven't checked Guix's code yet (I plan to flickr it in
> the upcoming days), I am thinking on getting some inspiration from the
> architecture of similar Clojure-focused tools (which, as I stated
> earlier, is what I know).
>
> I know about three such tools: leiningen[1], boot[2], and clojure.deps[3].
>
> I plan to flickr over their code, and see what architectural decitions
> could be proposed.
> What do you think about this?
>
> Best,
> Leandro
>
> [1] leiningen: https://github.com/technomancy/leiningen
> [2] boot: https://github.com/boot-clj/boot
> [3] clojure.deps: https://github.com/clojure/tools.deps.alpha

Re: [GSOC 2020] Improving the manual?

[Leandro Doctors]

On Thu, 27 Feb 2020 at 21:39, sirgazil  wrote:
> On Thu, 27 Feb 2020 at 21:37, zimoun  wrote:

>> The source of the manual lives under doc/ of what is cloned above;

> The documentation is in the same repository of the guix source code (see the 
> doc directory).

Thanks, guys. I see it now. I had missed it.

And thanks for the pointer to the "contributing" section. Even thought
I had skimmed it, as I could not find the doc sources, I thought the
process for the docs was different.

Best,
Leandro

Re: [GSOC 2020] Improving the manual?

[sirgazil]

  On Thu, 27 Feb 2020 19:22:17 -0500 Leandro Doctors  
wrote 
 > On Thu, 27 Feb 2020 at 11:44, zimoun  wrote:
 > > Are you using Guix yet?
 > >
 > > If no, the first easy step is to install the "package manager".
 > [...]
 > 
 > Thanks for the instructions, Simon!
 > I have just successfully installed Guix :-)
 > 
 > 
 > > If yes, the easy way to start is:
 > > git clone https://git.savannah.gnu.org/git/guix.git
 > 
 > > from the note in the manual
 > > http://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html#Binary-Installation
 > 
 > While cloning the guix repo above, I found a minor omission in the
 > documentation. However, I could not find its repo in the list from the
 > Savannah group [1] in order to fix it and create a pull/merge request
 > or patch...
 > 
 > [1]: https://savannah.gnu.org/git/?group=guix
 > 
 > 
 > Could anyone please point me to in the manual repo?

The documentation is in the same repository of the guix source code (see the 
doc directory).

https://git.savannah.gnu.org/cgit/guix.git/tree/doc


 > Besides... Where
 > could I find documentation on the workflow for working on the manual
 > proper so I can actually send my patch? I could not find it in the
 > online manual version [2]...

I don't think there are specific steps to work in the manual, but a general 
section on Contributing (see 
https://guix.gnu.org/manual/en/html_node/Contributing.html#Contributing).

I guess you could create a patch and send it to guix-patches as decribed in 
https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html#Submitting-Patches.

Re: [GSOC 2020] Improving the manual?

[zimoun]

On Fri, 28 Feb 2020 at 01:22, Leandro Doctors  wrote:

> > If yes, the easy way to start is:
> > git clone https://git.savannah.gnu.org/git/guix.git
>
> > from the note in the manual
> > http://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html#Binary-Installation
>
> While cloning the guix repo above, I found a minor omission in the
> documentation. However, I could not find its repo in the list from the
> Savannah group [1] in order to fix it and create a pull/merge request
> or patch...
>
> [1]: https://savannah.gnu.org/git/?group=guix

Hum? I am not sure to understand what you are asking.

The source of the manual lives under doc/ of what is cloned above; i.e.,

https://git.savannah.gnu.org/cgit/guix.git/tree/doc


The submission of patches is done via "git format-patch" and by email
via "git send-email --to=guix-patc...@gnu.org" (package
git:send-email).


> Could anyone please point me to in the manual repo? Besides... Where
> could I find documentation on the workflow for working on the manual
> proper so I can actually send my patch? I could not find it in the
> online manual version [2]...
>
> [2]: https://guix.gnu.org/manual/en/

Maybe you could be interested by this section of the manual:

https://guix.gnu.org/manual/devel/en/guix.html#Contributing


Hope that helps.

All the best,
simon

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[zimoun]

Hi Leandro,

On Thu, 27 Feb 2020 at 12:54, Leandro Doctors  wrote:

> I will clone Guix's repo, read the code and try building it, and get
> back with more specific details, if that's OK with you.

Are you using Guix yet?

If no, the first easy step is to install the "package manager". It
works on any recent Linux distro and it will not interfere with it.
Using the shell script helper, it is quick; and nothing to do. See:
https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
from the note in the manual
http://guix.gnu.org/manual/devel/en/html_node/Binary-Installation.html#Binary-Installation

If yes, the easy way to start is:

git clone https://git.savannah.gnu.org/git/guix.git
cd guix
guix environment guix
./bootstrap
./configure --localstatedir=/var/
make

then you can tweak any scheme file and recompile with make. And to use
this checkout version, you can just run the ./pre-env-inst hook.

 ./pre-inst-env guix help


Hope that helps.

All the best,
simon

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[Leandro Doctors]

On Thu, 27 Feb 2020 at 08:52, Leandro Doctors  wrote:
> I will clone Guix's repo, read the code and try building it, and get
> back with more specific details, if that's OK with you.

I checked the Guix group page [1], and found several repos...

[1] https://savannah.gnu.org/git/?group=guix


Could anyone please advise me which one(s) to clone first in to get started?


Best,
Leandro

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[Leandro Doctors]

On Thu, 27 Feb 2020 at 05:16, Ricardo Wurmus  wrote:
> Usually we just discuss things right here on the mailing list.

That is a great starting pointer, Ricardo. Thanks! :-)


> A draft for what exactly?

Well, as I said before, I have only started reading the Ideas page.
All I know right now is that I would like to work on a Scheme-related
project :-)

I will clone Guix's repo, read the code and try building it, and get
back with more specific details, if that's OK with you.

Best,
Leandro

Re: [GSOC 2020] Discussing GNU Guix project ideas?

[Ricardo Wurmus]

Hi Leandro,

> My name is Leandro Doctors. I am seriously considering applying to
> GSoC 2020 with GNU Guix.

Oh, that’s nice!

> I am interested in the Scheme-based ideas. (I have recently
> rediscovered LISP, and I am a Clojure fan.) However, I haven't found
> any indication on how to proceed in the Ideas page [1].

Is there any project in particular that you find interesting?

> Could you please point me in the right direction? I mean, is there a
> place where I should publish a draft to get feedback (like, a gist or
> similar), or should I just send emails here?

A draft for what exactly?  Usually we just discuss things right here on
the mailing list.  The mentors of the proposed projects are also reading
this list.

--
Ricardo

Re: GSoC 2020

[Ludovic Courtès]

Hi Gábor,

Gábor Boskovits  skribis:

> The organization application is now open for GSoC 2020. I expect that
> we soon hear something from the GNU coordinator. I will keep you
> updated.

Thanks a lot for keeping an eye on it in addition to Outreachy!

Ludo’.