Re: Come back and graphical installer

[Chris Marusich]

Mathieu Othacehe  writes:

> First mail since a while ! I'm currently finishing a long bicycle trip,
> and was able to start hacking again.

Welcome back.  I hope you had a great, refreshing trip!

> I picked up the "Graphical installer" task. After studying the branch
> wip-installer-2, I choose to rewrite it for multiple reasons:
>
> [...]
>
> Based on this, I have a first draft for a new installer here[4]. I plan
> to push it on a wip savannah branch soon. Most of the basic features are
> implemented and the last missing part it the partioning one (also the
> bigger ...).

Wow!  This is great to hear.  I'll look into trying this soon, and give
you feedback when I do.  Many thanks for working on it!

-- 
Chris


signature.asc
Description: PGP signature

Re: Channel dependencies

[Chris Marusich]

Ricardo Wurmus  writes:

> [...]
>
>> Chris raises interesting issues.  I think it’s OK to first come up with
>> an implementation that has some limitations but works with the simple
>> use cases we have in mind.
>
> I’ve fixed this according to what we’ve discussed: when more than one of
> the user-provided or channel-required channels have the same name we
> ignore the more recent specification unless it is more specific
> (i.e. the new channel specification mentions a commit while the former
> did not).

As long as the "channel resolution mechanism" is deterministic, it's
probably OK.  But if you have two channels A which depends on C, and B
which depends on C', where C' is a different version of C, then we can
arrive in a situation where the author of A tests and provides support
for their package definitions in the absence of channel B, and the
author of B tests and provides support for their package definitions in
the absence of channel A, and a user who wants to use packages from both
A and B is stuck because one of the channel owners (the one whose
dependency we didn't pick) doesn't want to support that use case.

It sounds to me like we are taking all the channels are merging them
into a single profile, and then we access it using a single Guix
inferior.  That's why we feel like we have to chose a specific version
of C to use with both A and B.  In this way, "installing" multiple
channels into this one profile is similar to the propagation of multiple
packages into a single profile.

Consider package propagation.  If I have a piece of software X which
depends on library Z and another piece of software Y which depends on
Z', where Z' is a different version of Z, then we have a similar
problem.  If I install packages X and Y into my profile and the
libraries Z and Z' are propagated, it will cause conflicts, and we will
need to choose a single version of the library.  When we do that, there
is no guarantee that X or Y will function correctly, since the person
who developed X didn't test using Z', and the person who developed Y
didn't test using Z.

Instead, if we install install X and Y without propagating Z and Z', we
have a solution: X and Y can coexist in the same profile.  X refers to Z
in the store (via its rpath or equivalent), and Y refers to Z' in
another location in the store.  When the user runs X, it runs using the
library Z.  When the user runs Y, it runs using library Z'.  The user
has not "voided their warranty", so to speak, by using a version of the
library that the developer doesn't want to support.  If there's a
problem, the user can go to the developer for support more easily.

I think your proposed solution is basically "channel propagation".
Don't get me wrong: It's great that we can choose a specific version of
channel C deterministically!  This means users can share their
channels.scm file and reproduce the exact channel configuration easily.
However, it might be even better if we could figure out how to avoid
"propagating" the channels and introducing conflicts.  Maybe there is a
way to run one Guix inferior per channel, so that one inferior can be
responsible for packages from channel A (using C), and another inferior
can be responsible for packages from channel B (using C')?

By the way, even if we come up with a solution like this, I think it's
safe to say that the core Guix channel must be the same version always.
I can't currently see how it might make sense for two third-party
channels to depend on different versions of the Guix channel, since the
Guix channel provides not only package definitions but also the Guix
code.

I hope that makes sense.  Either way, your work is already an
improvement.  Thank you for it!

-- 
Chris


signature.asc
Description: PGP signature

Re: openssh vulnerability

[Chris Marusich]

Christopher Lemmer Webber  writes:

> Leo Famulari writes:
>
>> [...]
>>
>> Patch at 
>
> Yay, thanks Leo!

Thank you for the fix!  It looks like this change
(eed00f93e8999712191e39c59c15e23461520f43) went to master:

--8<---cut here---start->8---
$ git branch -a --contains eed00f93e8999712191e39c59c15e23461520f43
* (HEAD detached at 7d1f21c69)
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/wip-next-browser3
--8<---cut here---end--->8---


Will this change trigger many rebuilds?  It has many dependents:

--8<---cut here---start->8---
$ guix refresh -l libssh2
Building the following 1321 packages would ensure 3307 dependent
packages are rebuilt: [...]
--8<---cut here---end--->8---

I looked into this email thread mainly because I was curious to see how
we would apply the security update.  I thought we would use grafts
somehow, but this looks like we just changed the package definition on
master, which will result in more rebuilds than usual - right?

-- 
Chris


signature.asc
Description: PGP signature

Re: Blog: Guix packaging tutorial

[Divan]

Pierre Neidhardt  writes:

> And here is the last version, in Markdown (hopefully the syntax is
> right).

Off topic, but how did you convert this? Guessing pandoc, but it seems
converted better then the standard, =pandoc index.org -t gfm -o
/tmp/index.md= would do.

Re: New Guix reference card

[Chris Marusich]

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

> I’ve written a reference card for Guix, which you can find here:
>
>   https://gnu.org/s/guix/guix-refcard.pdf
>
> The source is at:
>
>   https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/doc/refcard

Excellent!  I was actually thinking about making something like this to
share with people at my upcoming talk at SeaGL, but maybe I'll just
steal yours, instead.  :-)

I see that the second page is mostly blank.  Is that intended?

-- 
Chris


signature.asc
Description: PGP signature

Re: Trying to crosscompile for POWER9

[Tobias Platen]

It is the same error in both cases.
the binary128 type is not avialable in gcc, but requires for glibc to build.
Im now trying out the GCC 7 branch

On 10/20/2018 08:31 PM, Efraim Flashner wrote:

On Sat, Oct 20, 2018 at 05:05:35PM +0200, Tobias Platen wrote:



On 10/16/2018 08:24 PM, Efraim Flashner wrote:

On Tue, Oct 16, 2018 at 08:08:27PM +0200, Tobias Platen wrote:

Hello,

When I try to compile GUIX for POWER9 an old version of GCC is used.
How do I use the gcc version used for cross compiling.

./pre-inst-env guix build --target=powerpc64le-linux hello

checking if powerpc64le-linux-gcc supports
binary128 floating point type... no
checking if the target machine is at least POWER8... yes

configure: error: ***
binary128 floating point type (GCC >= 6.2) is required on powerpc64le.

Tobias "Tomoko" Platen



I'd recommend starting by editing gnu/packages/make-bootstrap.scm:103
and change the line:
`(("cross-gcc"  ,(cross-gcc target
to:
`(("cross-gcc"  ,(cross-gcc target #:gcc-6

there are other places, like lines 110 and 391 (and possibly others) which
should be turned to (inherit gcc-6)

That should work for this round, then you can decide if it's worth
upstreaming and wrap it in 'match' keywords for some of the newer
architectures (like riskv).


It still fails after changing to gcc 6


Where does it fail? It'd be nice if we can get it to work.

Re: Trying to crosscompile for POWER9

[Efraim Flashner]

On Sat, Oct 20, 2018 at 05:05:35PM +0200, Tobias Platen wrote:
> 
> 
> On 10/16/2018 08:24 PM, Efraim Flashner wrote:
> > On Tue, Oct 16, 2018 at 08:08:27PM +0200, Tobias Platen wrote:
> > > Hello,
> > > 
> > > When I try to compile GUIX for POWER9 an old version of GCC is used.
> > > How do I use the gcc version used for cross compiling.
> > > 
> > > ./pre-inst-env guix build --target=powerpc64le-linux hello
> > > 
> > > checking if powerpc64le-linux-gcc supports
> > > binary128 floating point type... no
> > > checking if the target machine is at least POWER8... yes
> > > 
> > > configure: error: ***
> > > binary128 floating point type (GCC >= 6.2) is required on powerpc64le.
> > > 
> > > Tobias "Tomoko" Platen
> > > 
> > 
> > I'd recommend starting by editing gnu/packages/make-bootstrap.scm:103
> > and change the line:
> > `(("cross-gcc"  ,(cross-gcc target
> > to:
> > `(("cross-gcc"  ,(cross-gcc target #:gcc-6
> > 
> > there are other places, like lines 110 and 391 (and possibly others) which
> > should be turned to (inherit gcc-6)
> > 
> > That should work for this round, then you can decide if it's worth
> > upstreaming and wrap it in 'match' keywords for some of the newer
> > architectures (like riskv).
> > 
> It still fails after changing to gcc 6

Where does it fail? It'd be nice if we can get it to work.

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: GuixSD on the SoftIron OverDrive 1000 (AArch64)

[Efraim Flashner]

On Sat, Oct 20, 2018 at 03:20:44PM +0200, Ludovic Courtès wrote:
> Hello Guix!
> 
> The device comes with openSuSE preinstalled and I had first installed
> Guix from the binary tarball.  It’s a “normal” UEFI machine so we can
> use ‘grub-efi’ directly.  I came up with this GuixSD config:
> 
>   
> https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/overdrive.scm
> 

Can I draw your attention to commits
64791eb7e1dceb0940cc881e84820f0170298b34 and
39d7fdce453b0ca23ecbed72048647debbaa58a6 ? :)

> The main difficulty was to come up with the right combination of modules
> for the initrd, without which we’d fail to mount the root file system.
> Fortunately the OverDrive has a serial output that makes it easy to
> debug boot failures.
> 
> With that config, I just run:
> 
>   guix system init overdrive.scm /
> 
> and that’s it!
> 

How did you figure out which modules you needed for the device?

Also, I'd suggest this diff:

diff --git a/hydra/overdrive.scm b/hydra/overdrive.scm
index 072c095..304acd6 100644
--- a/hydra/overdrive.scm
+++ b/hydra/overdrive.scm
@@ -72,7 +72,7 @@
   `(("ludo" ,(local-file "keys/ssh/ludo.pub"))
 ("rekado" ,(local-file "keys/ssh/rekado.pub"))
 ("dannym" ,(local-file 
"keys/ssh/dannym.pub"))
-   (dhcp-client-service)
+   (service dhcp-client-service-type)
(service mcron-service-type
 (mcron-configuration
  (jobs (list gc-job btrfs-job
@@ -84,7 +84,7 @@
  (term "vt220")
  (baud-rate "115200,38400,9600")))

-   (ntp-service)
+   (service ntp-service-type)

(modify-services %base-services
  (guix-service-type config =>
@@ -97,4 +97,4 @@
  (extra-options
   '("--max-jobs=2" "--cores=3")))

-  (packages (cons* screen openssh strace %base-packages)))
+  (packages (cons* btrfs-progs screen openssh strace %base-packages)))

-- 
Efraim Flashner  אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


signature.asc
Description: PGP signature

Re: GuixSD on the SoftIron OverDrive 1000 (AArch64)

[Jan Nieuwenhuizen]

Ludovic Courtès writes:

> Following advice and encouragements from Vagrant and Danny :-), I
> successfully installed GuixSD on the SoftIron OverDrive 1000 machine
> that was donated last January¹ (its PSU died a while back and I just
> received a replacement from SoftIron, and I thought it was also a good
> time to replace the distro.)

Ooh, nice!

> On the first boot, the GuixSD activation snippets fail while trying to
> install /etc, /etc/pam.d, and /etc/skel, and /etc/ssl because these
> directories already exist (from openSuSE) whereas GuixSD assumes that
> they don’t.  The solution is just to remove/rename them from the Guile
> initrd REPL.  Once this is done, booting proceeds flawlessly and
> happiness ensues.

We could do with a more powerful REPL ;-)

> ¹ https://gnu.org/software/guix/blog/2018/aarch64-build-machines-donated/

So...is there an opportunity for someone to start looking at a Reduced
Binary Seed boostrap for AArch64?

janneke.

Re: Come back and graphical installer

[Mathieu Othacehe]

Hi Pierre,

> I'm a bit late to the discussion, so maybe this was discussed before, but what
> about a graphical installer (X / Wayland)?  I think it would offer more appeal
> to a wider audience.  People acquainted to curses-like interfaces are usually
> also familiar with commandline, which is the current way of installing

I remember this topic has been discussed here:

http://lists.gnu.org/archive/html/guix-devel/2017-09/msg00247.html

To give you my opinion, I think that having a X/Wayland installer would
be really nice and totally agree. However, I also think it is important
to capitalize on the work already done. Plus, writting this kind of
installer is quite complicated because:

* Using Anaconda[1] as suggested by Harmut would mean interfacing a huge
  codebase in Python, written for FHS based distributions.
* To write this kind of installer in Guile, we need bindings for a nice
  high level graphical library and we have to be careful not to increase
  too much the installer footprint.

So this seems that something we want in the future but that is a bit out
of reach for the 1.0 release.

Mathieu

[1]: https://en.wikipedia.org/wiki/Anaconda_(installer)

Re: Come back and graphical installer

[Pierre Neidhardt]

Hi Mathieu,

It's very nice that you picked up the task, I guess it's a very important step
for Guix!  Thanks for the hard work! :)

I'm a bit late to the discussion, so maybe this was discussed before, but what
about a graphical installer (X / Wayland)?  I think it would offer more appeal
to a wider audience.  People acquainted to curses-like interfaces are usually
also familiar with commandline, which is the current way of installing

For example, I think Antergos (https://antergos.com/) has a very nice and well
polished installer.

Thoughts?

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


signature.asc
Description: PGP signature

Come back and graphical installer

[Mathieu Othacehe]

Hi Guix !

First mail since a while ! I'm currently finishing a long bicycle trip,
and was able to start hacking again.

I picked up the "Graphical installer" task. After studying the branch
wip-installer-2, I choose to rewrite it for multiple reasons:

* I found the guile-ncurses approach too low level and think that many
  bugs in the current installer could be avoided with a higher level
  library.
* As suggested by Ludo[1], using a network manager seems to be a better
  idea that calling iw, ip and other low level tools.
* I prefer relying on a Guile-parted library rather than calling cfdisk
  and again interfacing with various partioning tools.

While a lot of work have been accomplished by John and Danny, fixing the
above issues mean rewrite it almost completely anyway.

So, I wrote Guile bindings for newt[2], which can be found here[3]. Newt
is the library used by Debian installer and the Anaconda installer
(RedHat, Centos, ...).

I choose to interface with Connman via connmanctl. It would have been
better to use DBus but it implies writing Guile-dbus and I did not have
the courage.

Based on this, I have a first draft for a new installer here[4]. I plan
to push it on a wip savannah branch soon. Most of the basic features are
implemented and the last missing part it the partioning one (also the
bigger ...).

I will soon share some iso files to have some feedbacks. Even if it
might be too late already, I think that releasing the 1.0 with a
graphical installer would be a big plus.

Mathieu

[1]: https://lists.gnu.org/archive/html/guix-devel/2017-01/msg01255.html
[2]: https://en.wikipedia.org/wiki/Newt_(programming_library)
[3]: https://gitlab.com/mothacehe/guile-newt
[4]: https://github.com/mothacehe/guix/tree/installer

Re: Trying to crosscompile for POWER9

[Tobias Platen]

On 10/16/2018 08:24 PM, Efraim Flashner wrote:

On Tue, Oct 16, 2018 at 08:08:27PM +0200, Tobias Platen wrote:

Hello,

When I try to compile GUIX for POWER9 an old version of GCC is used.
How do I use the gcc version used for cross compiling.

./pre-inst-env guix build --target=powerpc64le-linux hello

checking if powerpc64le-linux-gcc supports
binary128 floating point type... no
checking if the target machine is at least POWER8... yes

configure: error: ***
binary128 floating point type (GCC >= 6.2) is required on powerpc64le.

Tobias "Tomoko" Platen



I'd recommend starting by editing gnu/packages/make-bootstrap.scm:103
and change the line:
`(("cross-gcc"  ,(cross-gcc target
to:
`(("cross-gcc"  ,(cross-gcc target #:gcc-6

there are other places, like lines 110 and 391 (and possibly others) which
should be turned to (inherit gcc-6)

That should work for this round, then you can decide if it's worth
upstreaming and wrap it in 'match' keywords for some of the newer
architectures (like riskv).


It still fails after changing to gcc 6

Re: [outreach] Help trying to create R package

[Ludovic Courtès]

Hello!

Björn Höfling  skribis:

> On Fri, 19 Oct 2018 20:10:03 -0300
> Laura Lazzati  wrote:
>
>
>> I ended up sending the patch in plain text mode directly from my
>> email, because even I installed the send-mail command for git, my
>> second factor authenticator complained. I will take a look about how
>> to configure the command properly.
>> Please, let me know if you received it fine, and if so, if you would
>> like me to work on other contributions meanwhile (maybe another r
>> package, or let me know what alse would you like me to do)
>
> Congratulations! Your patch went through:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33099

Or, for a nicer view:

  https://issues.guix.info/issue/33099

Thank you for this first patch, Laura!

Ludo’.

Re: 'package-name-version' and 'strip-store-file-name' does the same thing with different ways

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>>> Similarly, 'file-sans-extension' are defined in both (guix utils) and
>>> (guix build guile-build-system). They are both the same. Should we move
>>> them to (guix build utils) as well?
>>
>> Yes, sounds like a good idea!
>
> ‘file-sans-extension’ is used on the host-side, e.g. in scripts/build.scm.
> Is it still fine to move it to a build-side module only?

I think so because in practice we already use (guix build utils) quite a
lot on the “host side”.

More generally, while I think it’s important to arrange things so that
we don’t end up importing all of Guix on the build side, the advantage
of using the same language on both sides is that we can share code.  I
think we should take advantage of it when there are no downsides.

Ludo’.

Re: [outreach] Help trying to create R package

[Laura Lazzati]

On Sat, Oct 20, 2018 at 3:34 AM Gábor Boskovits  wrote:
>
> Hello Laura,
>
> Björn Höfling  ezt írta (időpont:
> 2018. okt. 20., Szo, 8:08):
> >
> > Hi Laura,
> >
> > On Fri, 19 Oct 2018 20:10:03 -0300
> > Laura Lazzati  wrote:
> >
> >
> > > I ended up sending the patch in plain text mode directly from my
> > > email, because even I installed the send-mail command for git, my
> > > second factor authenticator complained. I will take a look about how
> > > to configure the command properly.
>
> I guess you are using gmail with two factor authentication.
> Then you will have to create an app password, and after that
> you can use git credentials to set up authentication using the app
> password, but sending as plain text is fine for now.
Yes, I will try that for a second commit
>
> > > Please, let me know if you received it fine, and if so, if you would
> > > like me to work on other contributions meanwhile (maybe another r
> > > package, or let me know what alse would you like me to do)
>
> Another R package would be great, in the meanwhile I will have a look
> around what else to do.
Sure, as I said before, once I learn how to package one, I will be
able to package more. I will take a look at the page and check other
packages that are not already in guix. And yes, if you find other
tasks that I can do it is fine for me. I would like to go on
contributing even after November 6th (the outreachy deadline for
applying). Maybe after that I can go on playing with GuixSD and
reading the whole documentation ;)
>
> >
> > Congratulations! Your patch went through:
> >
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33099
> >
>
> That is great!
>
> > Either follow its status on that page and/or subscribe to the
> > guix-patches list:
> >
> > https://lists.gnu.org/mailman/listinfo/guix-patches
> >
> > Someone will review it and give you feedback.
Thank you, I saw that they wrote about it :) But I will ask in that
thread of mails about how to make my changes to be accespted
> >
>
> I will review it later today.
>
> > For Outreachy it is important to document your contributions. So,
> > please also go to the Guix-Outreachy page, there you should find a link
> > to formally report your contribution. When I have understood that
> > right, it is not important that your contribution really get's accepted
> > for that, just that you made one.
Yes, I reported the in progress contribution.
> >
>
> Yes, now you can record this contribution.
>
> > Björn
> >
> Best regards,
> g_bor
Regards :)

Laura

Re: 'package-name-version' and 'strip-store-file-name' does the same thing with different ways

[Ludovic Courtès]

Hi Alex,

Alex Vong  skribis:

> l...@gnu.org (Ludovic Courtès) writes:
>
>> Hello Alex,
>>
>> Alex Vong  skribis:
>>
>>> Btw, I also noticed that the procedure 'flatten' are defined in
>>> (gnu services telephony), (gnu services web) and (guix import utils).
>>> [I was about to define my own version of it...]
>>> I like the version using 'fold-right' together with 'match-lambda*' the
>>> most. Should we move it (guix build utils) and remove the rest?
>>
>> About ‘flatten’ specifically, I feel like it’s not a good sign in terms
>> of programming style when we end up using it (though we’d need to study
>> these specific use cases), so I’m reluctant to “standardizing” it.  :-)
>>
> Your comment lead me to find out that 'append-map' is actually what I
> want. I am curious why it is an indication of bad style.

My intuition is that often, when one feels a need for ‘flatten’, they’d
probably be using ‘append’, ‘concatenate’, etc., or perhaps they’re
using the wrong data structure in the first place.  But again, we’d have
to look more closely at the existing use cases to see more concretely to
what extent they could be written differently.

Ludo’.

GuixSD on the SoftIron OverDrive 1000 (AArch64)

[Ludovic Courtès]

Hello Guix!

Following advice and encouragements from Vagrant and Danny :-), I
successfully installed GuixSD on the SoftIron OverDrive 1000 machine
that was donated last January¹ (its PSU died a while back and I just
received a replacement from SoftIron, and I thought it was also a good
time to replace the distro.)

The device comes with openSuSE preinstalled and I had first installed
Guix from the binary tarball.  It’s a “normal” UEFI machine so we can
use ‘grub-efi’ directly.  I came up with this GuixSD config:

  
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/overdrive.scm

The main difficulty was to come up with the right combination of modules
for the initrd, without which we’d fail to mount the root file system.
Fortunately the OverDrive has a serial output that makes it easy to
debug boot failures.

With that config, I just run:

  guix system init overdrive.scm /

and that’s it!

On the first boot, the GuixSD activation snippets fail while trying to
install /etc, /etc/pam.d, and /etc/skel, and /etc/ssl because these
directories already exist (from openSuSE) whereas GuixSD assumes that
they don’t.  The solution is just to remove/rename them from the Guile
initrd REPL.  Once this is done, booting proceeds flawlessly and
happiness ensues.

Really nice to see that it’s this easy and fully functional with 100%
free software!

Cheers,
Ludo’.

¹ https://gnu.org/software/guix/blog/2018/aarch64-build-machines-donated/

Re: Call for talks: Minimalistic Languages Devroom at FOSDEM 2019

[Pjotr Prins]

Just a heads up. We should have enough room for Guile, Mes and (other)
Guix related talks. Mail your ideas here (or to Manolis or me). Main
goal could be to recruit new people. We also have the two Guix days before
FOSDEM which can be focussed on hacking and discussions rather than
talks.

Pj.

On Wed, Oct 17, 2018 at 05:48:23PM +0200, Ludovic Courtès wrote:
> Hello Guilers & Guix!
> 
> Guile, Guix, and Lua fellows are organizing the “Minimalistic Languages”
> track at this year’s FOSDEM:
> 
>   https://fosdem.org/2019
> 
> Consider submitting a talk about what you’ve been hacking on!
> 
> Ludo’.
> 
> 
> * Minimalistic Languages Devroom call for talks @ FOSDEM 2019
> 
> (posted at https://libreplanet.org/wiki/FOSDEM2019-devroom-minimalism)
> 
> We are excited to announce a devroom on minimalistic languages (with
> big ideas) at FOSDEM on Saturday February 2nd 2019!
> 
> FOSDEM is one of the most important free software conferences and is
> hosted annually at Université libre de Bruxelles in Brussels,
> Belgium. FOSDEM is fantastic, check last year's schedule for Saturday
> (https://archive.fosdem.org/2018/schedule/day/saturday/)
> 
> Minimalism matters. Minimalism allows for smaller systems that take
> less resources and consume less energy. More importantly, free and
> open source minimalism allows for secure systems that are easy to
> understand. Finally, we believe that minimalism is educational and
> brings back the fun of the early days of computing where people learn
> to understand systems from the ground up. Speakers will be asked to
> accentuate the educational side of their projects.
> 
> We have a room Saturday 2 February 2019. We want to invite you to
> submit a talk on the use of minimalistic languages that fits that
> description. We are especially happy to receive talk submissions from
> members of any underrepresented groups.
> 
> If you have something you’d like to share with your fellow developers,
> please head to pentabarf at
> 
>   - https://penta.fosdem.org/submission/FOSDEM19
> 
> The deadline for submission is November 25th. If you have a FOSDEM
> pentabarf account from a previous year, please use that
> account. Otherwise add one on
> https://penta.fosdem.org/user/new_account. Reach out to
> pjotr.public...@thebird.nl if you run into any trouble.
> 
> When submitting your talk make doubly sure to select "Minimalistic
> Languages devroom" as track (if you don't we won't find it), and
> include the following information:
> 
>   * The title and subtitle of your talk
>   * A short abstract of one paragraph
>   * A longer description if you wish to do so
>   * Links to related websites/blogs etc
> 
> Let's make this a fun day!
> 
> ** Organisers
> 
> Pjotr Prins, Manolis Ragkousis, Hisham Muhammad, Ricardo Wurmus,
> Ludovic Courtès, Jan Nieuwenhuizen, Alex Sassmannshausen, and Amirouche 
> Boubekki
> 
> ** Code of conduct
> 
>   - https://fosdem.org/2019/practical/conduct/
> 
> ** Original proposal
> 
>   - https://libreplanet.org/wiki/FOSDEM2019-devroom-proposal
> 
> ** Important dates:
> 
>   - Nov 25th 2018:  submission deadline for talk proposals
>   - Dec 17th 2018:  announcement of the final schedule
>   - Feb  2nd 2019:  FOSDEM!

Re: 25/65: gnu: Add sbcl-slime-swank.

[Ludovic Courtès]

Pierre Neidhardt  skribis:

>> Leftovers?  :-)
>
> No, I kept this on purpose because sionescu's fork is not official and the 
> issue
> is still open upstream.  
> It would be nice at some point to switch back to the official repo.

Oh I see, I hadn’t understood that.

>> For the record this typo made it impossible to build Guix (“license:
>> unbound variable”).  This was easily fixed in
>> 0ee6692a63538e874ba0b4d85584a4a73b75367c so no big deal, though make
>> sure to run “make” before “git push” next time.
>
> Oopsy, very sorry about this!
> Lesson learned, I'll make sure to build before pushing from now on.

OK!  :-)

Ludo’.

Re: Should 'build-expression->derivation' be used for new build systems?

[Ludovic Courtès]

Hello,

Joshua Branson  skribis:

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

[...]

>> The story of ‘build-expression->derivation’ is that of an unfinished
>> transition to G-expressions.  :-)
>>
>> There’s a branch called ‘wip-build-systems-gexp’ that aims to complete
>> that transition, but I haven’t yet gotten around to actually finishing
>> the work.  This is one of the things I want us to complete for 1.0
>> though, so sooner rather than later.
>
> May I ask why the transition?  Just curious.

G-expressions address shortcomings of plain s-expressions when used to
write build expressions as in Guix and for code generation in general
(“code staging”); see:

  https://www.gnu.org/software/guix/manual/en/html_node/G_002dExpressions.html
  https://hal.inria.fr/hal-01580582/en

Ludo’.

Re: New Guix reference card

[Ludovic Courtès]

Hi Laura,

Laura Lazzati  skribis:

> On Fri, Oct 19, 2018 at 10:45 AM Ludovic Courtès  wrote:
>>
>> Hello Guix!
>>
>> I’ve written a reference card for Guix, which you can find here:
>>
>>   https://gnu.org/s/guix/guix-refcard.pdf
> Thanks! I find it really useful. I did not know you call them
> reference card, I generally call them cheatsheets

Yeah I guess both terms work.  :-)  I’m glad you find it useful!

Ludo’.

Re: 'package-name-version' and 'strip-store-file-name' does the same thing with different ways

[Ricardo Wurmus]

Ludovic Courtès  writes:
>> Similarly, 'file-sans-extension' are defined in both (guix utils) and
>> (guix build guile-build-system). They are both the same. Should we move
>> them to (guix build utils) as well?
>
> Yes, sounds like a good idea!

‘file-sans-extension’ is used on the host-side, e.g. in scripts/build.scm.
Is it still fine to move it to a build-side module only?

--
Ricardo

Re: [outreach] Help trying to create R package

[Gábor Boskovits]

Hello Laura,

Björn Höfling  ezt írta (időpont:
2018. okt. 20., Szo, 8:08):
>
> Hi Laura,
>
> On Fri, 19 Oct 2018 20:10:03 -0300
> Laura Lazzati  wrote:
>
>
> > I ended up sending the patch in plain text mode directly from my
> > email, because even I installed the send-mail command for git, my
> > second factor authenticator complained. I will take a look about how
> > to configure the command properly.

I guess you are using gmail with two factor authentication.
Then you will have to create an app password, and after that
you can use git credentials to set up authentication using the app
password, but sending as plain text is fine for now.

> > Please, let me know if you received it fine, and if so, if you would
> > like me to work on other contributions meanwhile (maybe another r
> > package, or let me know what alse would you like me to do)

Another R package would be great, in the meanwhile I will have a look
around what else to do.

>
> Congratulations! Your patch went through:
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33099
>

That is great!

> Either follow its status on that page and/or subscribe to the
> guix-patches list:
>
> https://lists.gnu.org/mailman/listinfo/guix-patches
>
> Someone will review it and give you feedback.
>

I will review it later today.

> For Outreachy it is important to document your contributions. So,
> please also go to the Guix-Outreachy page, there you should find a link
> to formally report your contribution. When I have understood that
> right, it is not important that your contribution really get's accepted
> for that, just that you made one.
>

Yes, now you can record this contribution.

> Björn
>
Best regards,
g_bor

Re: [outreach] Help trying to create R package

[Björn Höfling]

Hi Laura,

On Fri, 19 Oct 2018 20:10:03 -0300
Laura Lazzati  wrote:


> I ended up sending the patch in plain text mode directly from my
> email, because even I installed the send-mail command for git, my
> second factor authenticator complained. I will take a look about how
> to configure the command properly.
> Please, let me know if you received it fine, and if so, if you would
> like me to work on other contributions meanwhile (maybe another r
> package, or let me know what alse would you like me to do)

Congratulations! Your patch went through:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33099

Either follow its status on that page and/or subscribe to the
guix-patches list:

https://lists.gnu.org/mailman/listinfo/guix-patches

Someone will review it and give you feedback.

For Outreachy it is important to document your contributions. So,
please also go to the Guix-Outreachy page, there you should find a link
to formally report your contribution. When I have understood that
right, it is not important that your contribution really get's accepted
for that, just that you made one.

Björn



pgpDWoEwWssY5.pgp
Description: OpenPGP digital signature