Re: Issue with my version of guix

[Laura Lazzati]

Hi Danny and znavko :)

Thank you very much for your help :)
 I should have mentioned that I am running it on a foreign distro.
Yesterday on IRC the folks helped me and I just needed to modifiy
guix-daemon.service, reload it, and restart it.

The only awkward thing is that difference between guix-daemon versions.

Regards :)
Laura

Re: Migrating to Guile-JSON 3.x

[zimoun]

Dear,

What is the status of this migration?

All the best,
simon

Re: GDM update!

[Marco van Hulten]

Ludovic et al—

On 10 Feb 23:30 Ludovic Courtès wrote:
> I’m happy to report that GDM basically works, including choosing among X
> session… and it has a neat Guix theme!
> [...] 
> 
> The one thing I didn’t get to work is ~/.xsession support.  Any ideas?
> 
> I’d real like to get that fixed and then we can finally replace SLiM
> with GDM as the default.
> 
> BTW, at the Guix Days, there were discussions about defaulting to
> LightDM instead of GDM.  I forgot to mention then that using LightDM
> wouldn’t solve the GNOME use case; in particular, closing the lid under
> GNOME wouldn’t lock the screen, and clicking the lock button wouldn’t
> have any effect, which is pretty bad.

I have had problems (on different GNU distro's and OpenBSD) with at
least SLiM, GDM and LightDM, ranging from usability ("Do I press Tab or
Enter now?") to forgettability ("I didn't order GNOME!") to not
using .xsession.

Now I tend to use XDM where I can.  For me it is always working as
expected in all the above respects.

—Marco

It's time to build "guix deploy"

[Christopher Lemmer Webber]

Hi,

This has come up several times.  A lot of us want "guix deploy".
Personally, I'm running a variety of Debian servers and one Guix server
and I am terrible at maintaining all of them.

It's time for Guix Deploy... or it's time for me to give up and use
something like Ansible + Debian.  (Egads!  I don't want to do that.)

David's thoughts on this are below, and here's the original thread:

Original thread can be found at the links below:
  https://lists.gnu.org/archive/html/guix-devel/2015-04/msg00525.html
  https://lists.gnu.org/archive/html/guix-devel/2015-05/msg7.html
  https://lists.gnu.org/archive/html/guix-devel/2015-06/msg6.html

There is a heavily, heavily bitrotted branch named "wip-deploy" where
David originally started exploring these ideas.  Conveniently, it's all
in one commit:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-deploy&id=fcd6fc84e493d05be1f7590ee77509c81ac315c2

That seems like a good starting point.  But I know David feels that with
real-world experience in devops type work that actually things would be
a bit different than what's described in his original email.  I'm not
sure myself what would be different.  It would be helpful to hear Dave
weigh in on that point.

Maybe Dave and I can meet up IRL now that we're close enough to each
other to chat about it.  But I know it's less fun than it used to be for
Dave to consider this because now that's Dave's actual job... but all
the more reason we need Dave's wisdom! :)


David Thompson writes:

> Hey folks,
>
> I'm writing this in an attempt to "think out loud" about a deployment
> automation tool for GuixSD.
>
> Guix needs a NixOps[0] equivalent.  NixOps is the Nix project's
> deployment automation tool.  I read the source code[1] a bit, and here's
> what I've learned about it:
>
> * The central data type is a "deployment", which is a Nix expression
>   consisting of one or more named OS configs
>
> * The OS configs contain extra data that specifies the target platform:
>   VirtualBox, EC2, NixOS container, etc.  Each platform implements the
>   generic MachineDefinition and MachineState interfaces.
>
> * The 'nixops' command is stateful.  It stores necessary state about
>   deployed systems in a special directory ($HOME/.nixops by default),
>   such as the IP addresses of the deployed systems.  Because of this,
>   each deployment needs a unique identifier.
>
> * Deployments may be parameterized by values known only at deploy time.
>   This covers cases such as a web application server needing to know the
>   IP address of the database server.
>
> * There are useful subcommands to check the status of each system or ssh
>   into one of them.
>
> Here's a rough outline of how I'm thinking of implementing similar
> features in Guix:
>
> * Introduce new data types:
>
>   * : The generic interface type for implementing deployment
> targets.  Its fields hold procedures for various actions like
> 'provision', 'destroy', 'boot', or 'reboot'.  I haven't determined
> the precise list of actions needed, but it will become apparent as
> platforms are added.
>
>   * : Describes a single system in the deployment.  Contains a
> name string, an , and a .
>
>   * : Contains a name string and a list of  and
> procedures.  Procedures in the list should accept an argument
> containing the deployment results of the non-parameterized machines
> and return a .
>
> * Use a simple s-exp deployment state format.  Store the state in
>   $HOME/.config/guix by default.
>
> * Implement a 'guix ops' subcommand roughly the same actions as NixOps:
>   create, deploy, start, stop, destroy, list, info, check, ssh, etc.
>
> * The bulk of the work will be creating  objects that actually
>   provision various types of resources.  For prototyping, a
>   'local-vm-platform' would be enough to test that the whole system
>   works.
>
> Anyone want to join in on this brainstorming party?  Your thoughts are
> appreciated!
>
> [0] http://nixos.org/nixops/
> [1] https://github.com/NixOS/nixops

Re: FOSDEM 2019: Thank you!

[Marco van Hulten]

Hi all—

This message is a bit belated... but thank you for the good
organisation of the Guix days (that I could only participate near the
end), as well as the organisation and high-quality talks in the
minimalistic languages track!  I only met good people.  I knew already
that they were pleasant as well as knowledgable through the Internet,
and now I experienced that this is also true in real life!

Best,

—Marco

Re: It's time to build "guix deploy"

[Pjotr Prins]

I am also interested in 'guix deploy', especially if it can run on top
of Debian and handle HOME directories. Currently using a mixture of
sysadmin heroics and my own cfengine style Ruby deploy tool ;). Happy
to switch, test and hack. But not enough time to run with it.

Pj.

New topic: asking for help

[Laura Lazzati]

Hi Guix!

Another topic is about asking for help, that is very useful for people
even when reading the documentaiton.

This should include this mailing-list (ie, how to fill the form, maybe
sth about the CoC?), and IRC channel.

Discussion starts :)

Regards!
Laura

New topic: packaging

[Laura Lazzati]

Hi Guix again!

Another topic is about showing how to package.

Gábor suggested maybe using my experience about creating a new R package.

My idea is to show how to look for a package that is not packaged,
package it and the workflow for testing it with git am and send it to
the patches list. WDTY?

Again, let's the discussion start and let's have in mind our friendly
reminder that it is introductory, not the whole manual, and it is also
a note to self ;)

Regards!
Laura

Re: GDM update!

[Danny Milosavljevic]

Hi Ludo,

https://github.com/GNOME/gdm/commit/0bb8a777cfc0a3bc53c2c2830dd7e6e2baeeef38#diff-9b802b1ffb5f0ff95bfaa85046d262e7
 says:

>custom is a magic name we used to allow for having the user decide their 
>session by a ~/.xsession file.  We no longer support that construct and 
>haven't for many years. Instead, users who want that functionality can just 
>add a xsession file to accomplish it.
>This commit just removes some left over cruft that never got cleaned up.

Another part is still there:

if [ "x$command" = "xdefault" ] ; then
  if [ -x "$HOME/.Xclients" ]; then
command="$HOME/.Xclients"
  elif [ -x /etc/X11/xinit/Xclients ]; then
command="/etc/X11/xinit/Xclients"
  elif [ -x /etc/X11/Xclients ]; then
command="/etc/X11/Xclients"
  else
if [ -n "$zenity" ] ; then
disptext=`gettextfunc "System has no Xclients file, so starting a 
failsafe xterm session.  Windows will have focus only if the mouse pointer is 
above them.  To get out of this mode type 'exit' in the window."`
  "$zenity" --info --text "$disptext"
else
  echo "$0: Cannot find Xclients"
fi
exec xterm -geometry 80x24+0+0
  fi
fi

... but not sure how to use it.


pgpxwDGpRnqHJ.pgp
Description: OpenPGP digital signature

Re: It's time to build "guix deploy"

[Christopher Lemmer Webber]

Pjotr Prins writes:

> I am also interested in 'guix deploy', especially if it can run on top
> of Debian and handle HOME directories. Currently using a mixture of
> sysadmin heroics and my own cfengine style Ruby deploy tool ;). Happy
> to switch, test and hack. But not enough time to run with it.
>
> Pj.

I am trying to think, "what can I do to help advance things further",
and maybe my best next step is to write minimalist user stories with
mockups of configurations and deployments based off of davexunit's old
branch?  That way I can think through what's there and what I need yet.

 - Chris

Re: It's time to build "guix deploy"

[Christopher Lemmer Webber]

Pjotr Prins writes:

> I am also interested in 'guix deploy', especially if it can run on top
> of Debian and handle HOME directories.

I should also say: I'm not considering how "guix deploy" could or would
handle running on top of Debian *or* handle HOME directories.  Both of
those feel out of scope to me, but for different reasons:

 - "guix deploy" would deploy by, well, building guix system profiles
   and then pushing them out.  So I'm not sure how Debian would fit in
   there...
 - Mutable state of the system is hard to tackle.  We might need to
   tackle some degree of it, but I think that would be in
   post-install-hooks type things which might sometimes do that
   on server?

Re: GDM update!

[Timothy Sample]

Hi Ludo,

Ludovic Courtès  writes:

> Hello Guix!
>
> I’m happy to report that GDM basically works, including choosing among X
> session… and it has a neat Guix theme!

Woohoo!  I like the background!

I have some changes that are more-or-less ready.  It’s mostly just
cleaning up, but it makes it so that GNOME does not have to be in the
system profile for GDM to work.  (Note that the GDM service references
GNOME Shell, which requires most of GNOME, but it doesn’t end up in the
profile.)

I spent some time trying to get “libgdm” split out from GDM, but GNOME
Shell kept getting killed with SIGTRAP.  This happens during the
execution of JavaScript code, and the recommended way to get a backtrace
did not work, so I’m stuck there.

I will try and send patches in the next day or two.

> The one thing I didn’t get to work is ~/.xsession support.  Any ideas?

Digging around in the source code, there’s a comment that says that the
distributed “Xsession” script should run “~/.xsession” if passed the
special keyword “custom”.  However, looking at the actual script
suggests that this comment is mistaken.  (If it did work, you might be
able to make a “custom.desktop” file with “Exec=custom” that would
trigger the right behaviour.  I did not test this.)

Debian provides a custom “Xsession” script and a custom
“default.desktop” file, which runs the script with the special argument
“default”.  With this argument, the “Xsession” does a bunch of stuff by
running all of the scripts in an “Xsession.d” directory, including one
that tries running “~/.xsession”.

In short, it looks like we have to either fix or customize the
“Xsession” script.  Making the script work like the comment suggests and
using “custom.desktop” is probably the simplest thing to do.

> I’d real like to get that fixed and then we can finally replace SLiM
> with GDM as the default.
>
> BTW, at the Guix Days, there were discussions about defaulting to
> LightDM instead of GDM.  I forgot to mention then that using LightDM
> wouldn’t solve the GNOME use case; in particular, closing the lid under
> GNOME wouldn’t lock the screen, and clicking the lock button wouldn’t
> have any effect, which is pretty bad.

Of course, it is good to have a nice alternative to SLiM that is simpler
than GDM.  GDM is needed for the proper GNOME experience, but it is too
much for most non-GNOME setups.  Ultimately, Guix is nice and
configurable, so I’m everyone can find a way to be happy.  :)


-- Tim

Re: GDM update!

[Timothy Sample]

Hi Danny,

Danny Milosavljevic  writes:

> Hi Ludo,
>
> https://github.com/GNOME/gdm/commit/0bb8a777cfc0a3bc53c2c2830dd7e6e2baeeef38#diff-9b802b1ffb5f0ff95bfaa85046d262e7
>  says:
>
>>custom is a magic name we used to allow for having the user decide
>> their session by a ~/.xsession file.  We no longer support that
>> construct and haven't for many years. Instead, users who want that
>> functionality can just add a xsession file to accomplish it.
>>This commit just removes some left over cruft that never got cleaned up.
>
> [...]

Thanks!  I didn’t see this before writing my other message, but it
explains why the comments and code don’t match.

Maybe the GDM folks expect that we write a custom “.desktop” file that
runs a custom script that checks for “~/.xsession” and runs it.  It
could use “TryExec” to figure out if “~/.xsession” exists, and offer it
to the user (in the session selector) in that case.  To be concrete, we
would create a “user.desktop” session file with the following contents.

[Desktop Entry]
Name=User Session
Comment=Start a user-defined session
Exec=run-user-xsession
TryExec=xsession-exists-p
Icon=
Type=Application

Here, “run-user-xsession” and “xsession-exists-p” are custom scripts
that we would write.  If this file were somewhere that GDM knows about
(e.g., “/run/current-system/profile/share/xsessions”), it should work.


-- Tim

Re: It's time to build "guix deploy"

[Pjotr Prins]

On Mon, Feb 11, 2019 at 09:57:59AM -0500, Christopher Lemmer Webber wrote:
> Pjotr Prins writes:
> 
> > I am also interested in 'guix deploy', especially if it can run on top
> > of Debian and handle HOME directories.
> 
> I should also say: I'm not considering how "guix deploy" could or would
> handle running on top of Debian *or* handle HOME directories.  Both of
> those feel out of scope to me, but for different reasons:
> 
>  - "guix deploy" would deploy by, well, building guix system profiles
>and then pushing them out.  So I'm not sure how Debian would fit in
>there...
>  - Mutable state of the system is hard to tackle.  We might need to
>tackle some degree of it, but I think that would be in
>post-install-hooks type things which might sometimes do that
>on server?

Sure. There was a message recently about having Guix doing
'outer' state too. I lost what thread it was in. I am interested not
least because I need a transition path to GuixSD. If we were on VMs it
would be relatively easy, but our servers are on bare metal.

Pj.

Re: New topic: asking for help

[znavko]

Hello, Laura! Your posts are awesome, cause me too want to have better 
connection with gurus.

There are lists I've subscribed to: 

Guix Help https://lists.gnu.org/archive/html/help-guix/ 

Guix Devel https://lists.gnu.org/archive/html/guix-devel/ 

Bug Guix https://lists.gnu.org/archive/html/bug-guix/ 


You may find Guix IRC channel from here https://www.gnu.org/software/guix/help/ 

I think Freenode is hard to use though tor, proxy.

Here are very responsive people. I like it. Maillists are the secure and useful 
way for communications. Do you want something else?


Feb 11, 2019, 2:29 PM by laura.lazzati...@gmail.com:

> Hi Guix!
>
> Another topic is about asking for help, that is very useful for people
> even when reading the documentaiton.
>
> This should include this mailing-list (ie, how to fill the form, maybe
> sth about the CoC?), and IRC channel.
>
> Discussion starts :)
>
> Regards!
> Laura
>

Re: GDM update!

[Alex Griffin]

On Mon, Feb 11, 2019, at 1:55 AM, Ludovic Courtès wrote:
> BTW, at the Guix Days, there were discussions about defaulting to
> LightDM instead of GDM. I forgot to mention then that using LightDM
> wouldn’t solve the GNOME use case; in particular, closing the lid under
> GNOME wouldn’t lock the screen, and clicking the lock button wouldn’t
> have any effect, which is pretty bad.

According to Hans de Goede's talk[1] at FOSDEM (around 27:00), GDM is currently 
the only option for running Xorg without root privileges. If true, that's a 
very compelling reason to default to GDM.
-- 
Alex Griffin

[1]: https://fosdem.org/2019/schedule/event/flickerfree/

Re: New topic: packaging

[znavko]

GuixSD declared features are academic way of evolution.
Guile instead of self-made language.
Transactions and wide control of packages versions instead of on the wing 
updates that break the system.
Sorry my French.
If we describe the advantages of Guix for the users, there will be many sites 
where discussions will go on.


Feb 11, 2019, 2:38 PM by laura.lazzati...@gmail.com:

> Hi Guix again!
>
> Another topic is about showing how to package.
>
> Gábor suggested maybe using my experience about creating a new R package.
>
> My idea is to show how to look for a package that is not packaged,
> package it and the workflow for testing it with git am and send it to
> the patches list. WDTY?
>
> Again, let's the discussion start and let's have in mind our friendly
> reminder that it is introductory, not the whole manual, and it is also
> a note to self ;)
>
> Regards!
> Laura
>

Re: New topic: asking for help

[Laura Lazzati]

Hi znavo!

> Hello, Laura! Your posts are awesome, cause me too want to have better 
> connection with gurus.
Thank you! But i am the Outreachy intern that is making the videos
that are the start point for newcomers :)
>
> There are lists I've subscribed to:
>
> Guix Help https://lists.gnu.org/archive/html/help-guix/
> Guix Devel https://lists.gnu.org/archive/html/guix-devel/
> Bug Guix https://lists.gnu.org/archive/html/bug-guix/
>
> You may find Guix IRC channel from here 
> https://www.gnu.org/software/guix/help/
> I think Freenode is hard to use though tor, proxy.
>
> Here are very responsive people. I like it. Maillists are the secure and 
> useful way for communications. Do you want something else?
I know, the community is lovely :) thanks for the links, I was just
planning to show how to join guix-devel.
What do others think about it?

Regards!
Laura

Haskell dependencies for custom cabal builds

[John Soo]

Hi Guix,

I’ve been working on some Haskell packages and got stuck recently and I didn’t 
know why until I realized the cabal files have `build-type: Custom` 
(http://hackage.haskell.org/package/termonad-1.1.0.0/termonad.cabal). I always 
get missing dependencies even though I have the dependencies listed in `inputs` 
(haskell-gi-base and friends in the example above). What do I need to do to fix 
this?

Thanks!

John

Re: It's time to build "guix deploy"

[Thompson, David]

Hi Chris,

Here we go again, eh? :)

On Mon, Feb 11, 2019 at 8:31 AM Christopher Lemmer Webber
 wrote:
>
> Hi,
>
> This has come up several times.  A lot of us want "guix deploy".
> Personally, I'm running a variety of Debian servers and one Guix server
> and I am terrible at maintaining all of them.

I have just a single Linode VPS that I can't be bothered to maintain
most of the time. I would like to switch to Guix, as well.

> It's time for Guix Deploy... or it's time for me to give up and use
> something like Ansible + Debian.  (Egads!  I don't want to do that.)
>
> David's thoughts on this are below, and here's the original thread:
>
> Original thread can be found at the links below:
>   https://lists.gnu.org/archive/html/guix-devel/2015-04/msg00525.html

Wow, 2015. I was so young and full of hope then. ;)

>   https://lists.gnu.org/archive/html/guix-devel/2015-05/msg7.html
>   https://lists.gnu.org/archive/html/guix-devel/2015-06/msg6.html
>
> There is a heavily, heavily bitrotted branch named "wip-deploy" where
> David originally started exploring these ideas.  Conveniently, it's all
> in one commit:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=wip-deploy&id=fcd6fc84e493d05be1f7590ee77509c81ac315c2

Useful for context, but the code can probably be tossed at this point.

> That seems like a good starting point.  But I know David feels that with
> real-world experience in devops type work that actually things would be
> a bit different than what's described in his original email.  I'm not
> sure myself what would be different.  It would be helpful to hear Dave
> weigh in on that point.

Sure, since 2015 I've become the lead devops person at my company, so
I like to think I'm a bit wiser now.

> Maybe Dave and I can meet up IRL now that we're close enough to each
> other to chat about it.  But I know it's less fun than it used to be for
> Dave to consider this because now that's Dave's actual job... but all
> the more reason we need Dave's wisdom! :)

We could meet up IRL about this and I can try to make an earnest
effort to deal with this. I think what has stopped me in the past is
the sheer size of this project, and maybe dramatically scaling down
the scope will allow us to get *something* out the door.  Here are
some general use-cases I know about for deployments, roughly ordered
from small scale to large scale, and least complex to most complex:

* Managing a physical machine or two that have been given memorable
names that you update in-place (home scale)
* Managing a virtual machine or two that have been given memorable
names that you update in-place (blog scale)
* Managing a large number of virtual machines whose names don't matter
that you update in-place (proto-cloud scale)
* Managing a large number of virtual machines whose names don't matter
that are replaced when there is an update (cloud scale)
* Managing 1 or more clusters of physical machines (datacenter scale)
* Managing 1 or more clusters of physical machines and virtual
machines ("corporation with a datacenter that is moving some stuff to
the cloud" scale)

There are, of course, more scenarios to consider (haven't even touched
upon things like a Kubernetes cluster), but this is enough to
illustrate the point that is a great diversity in setups.  How many
machines are there? Are the bare metal, virtual machines, or a mix of
both? In the case of virtual machines, are updates applied in an
immutable fashion or not?  If immutable, which technique (blue-green,
rolling release, etc.)?  It makes my head spin to think about all the
use-cases.

So... let's start small. Can we write a tool that handles in-place
updates to machines (physical or virtual) whose name and IP address we
know well (our special pet servers) without precluding the possibility
of scaling up to more sophisticated architectures?  This would address
the "home" and "blog" scale items above, which is probably what most
of the people actually using Guix today would want.  I got stuck
trying to do in-place updates to remote machines years ago, but that
was before Ludo made it easy to connect to remote systems.

Other thoughts?

Yours in vaporware,

- Dave

Guix gets a distribution called PantherX

[Jonathan Brielmaier]

Hi Guix folks,

following a link from bug#34435 I found a pretty interesting website:
https://www.pantherx.org

They creating a "modern, Unix-like computer operating system" based on
GNU Guix[0] with focus on ease of use and privacy.

I never heard about it before, but to me it looks quite promising.
According to their timeline a public beta will be released in August
2019. Before there seem to be some (closed) alpha and beta versions.

Their team consists of 9 Members[1], which is pretty impressive.

They also develop an ARM based Mini-Computer called "Panther Alpha"[2].

Though I couldn't find any of the team members in some Guix commits or
patches...

Kind Regards
Jonathan Brielmaier

[0] https://wiki.pantherx.org/PantherX-compared-to-other-distributions/
[1] https://www.pantherx.org/about/
[2] http://www.panther-mpc.com/panther-alpha/

Re: It's time to build "guix deploy"

[Amirouche Boubekki]

On 2019-02-11 15:47, Christopher Lemmer Webber wrote:

Pjotr Prins writes:


I am also interested in 'guix deploy', especially if it can run on top
of Debian and handle HOME directories. Currently using a mixture of
sysadmin heroics and my own cfengine style Ruby deploy tool ;). Happy
to switch, test and hack. But not enough time to run with it.

Pj.


I am trying to think, "what can I do to help advance things further",
and maybe my best next step is to write minimalist user stories with
mockups of configurations and deployments based off of davexunit's old
branch?  That way I can think through what's there and what I need yet.

 - Chris



Great idea!

Package gmsh: best practise with test-suite?

[zimoun]

Hi Guix,

I am working on packaging GetDP [1] the companion finite element solver of Gmsh.

[1] http://getdp.info/

GetDP depends on some part of Gmsh. So I have a working
gmsh-minimal-no-x package, turning off FLTK, OpenCascade and
non-necessary features.

Then the full test suite fails. As expected. :-)
Now they are all turned off with "#:tests? #f".
Which is okish... but I am not fully satisfied.

Well, the issue is that the tests are generated with this piece of CMake:

  include(CTest)
  file(GLOB_RECURSE TESTFILES
   tutorial/*.geo demos/*.geo benchmarks/?d/*.geo benchmarks/extrude/*.geo)
  foreach(TESTFILE ${TESTFILES})
# use relative path for cygwin/mingw (the pure win exe built with the mingw
# compilers does not understand a full cygwin-style path)
FILE(RELATIVE_PATH TEST ${CMAKE_CURRENT_BINARY_DIR} ${TESTFILE})
add_test(${TEST} ./gmsh ${TEST} -3 -nopopup -o ./tmp.msh)
  endforeach()

What is the better?
 a- Patch the CMakeLists.txt to generate only the right tests
 b- Turn off all the tests

What do you think?

Thank you in advance for any comment.


All the best,
simon

Re: Package gmsh: best practise with test-suite?

[Christopher Baines]

zimoun  writes:

> What is the better?
>  a- Patch the CMakeLists.txt to generate only the right tests
>  b- Turn off all the tests

There may be a third option, run only the tests that are known to pass.

I know very little about CMake, but I searched for ctest, which is
something mentioned in the CMakeLists.txt file, and it brought up this
[1] which mentions --exclude-regex and --label-exclude. Maybe these
could somehow be passed in, or maybe set through environment variables?

1: http://bima.astro.umd.edu/nemo/man_html/ctest.1.html

If that's possible, it might be less britle than patching the file.


signature.asc
Description: PGP signature

Re: Package gmsh: best practise with test-suite?

[zimoun]

Hi Chris,

Thank you for your tip.

On Mon, 11 Feb 2019 at 20:38, Christopher Baines  wrote:
> zimoun  writes:
>
> > What is the better?
> >  a- Patch the CMakeLists.txt to generate only the right tests
> >  b- Turn off all the tests
>
> There may be a third option, run only the tests that are known to pass.
>
> I know very little about CMake, but I searched for ctest, which is
> something mentioned in the CMakeLists.txt file, and it brought up this
> [1] which mentions --exclude-regex and --label-exclude. Maybe these
> could somehow be passed in, or maybe set through environment variables?

>From my understanding, the cmake-build-system calls "make test" and
not "ctest". Right?

If I understand well, the idea should be to turn off the all tests
("#:tests? #f") and to add a final phase calling "ctest" with the
correct tests. Does this make sense?


All the best,
simon

Re: Haskell dependencies for custom cabal builds

[Timothy Sample]

Hi John,

John Soo  writes:

> Hi Guix,
>
> I’ve been working on some Haskell packages and got stuck recently and I 
> didn’t know why until I realized the cabal files have `build-type: Custom`
> (http://hackage.haskell.org/package/termonad-1.1.0.0/termonad.cabal). I 
> always get missing dependencies even though I have the dependencies listed in 
> `inputs` (haskell-gi-base and
> friends in the example above). What do I need to do to fix this?

You might be able to take some inspiration from git-annex, which I
believe has the same problem.

In short, the issue is that the haskell-build-system unsets
“GHC_PACKAGE_PATH” before calling “runhaskell Setup.hs”.  This is
because it assumes that “Setup.hs” will use Cabal in a pretty direct
way, and that Cabal will setup the required packages from the command
line (Cabal complains if you try to use “GHC_PACKAGE_PATH”, because it
wants to be in control of the environment).  If the custom build code
needs dependencies, they will not be available (unless it does what
Cabal does and reads package paths from the command line and sets
everything up from within Haskell).

For git-annex, I was able to skirt the problem.  I don’t know how to
solve it.  If you keep “GHC_PACKAGE_PATH” set, the Cabal part of the
build will likely complain.  However, without it, the custom part of the
build can’t find its dependencies.

That’s about all I can recall right now.  I hope that helps at least a
little bit!  :)


-- Tim

Re: Package gmsh: best practise with test-suite?

[Christopher Baines]

zimoun  writes:

> On Mon, 11 Feb 2019 at 20:38, Christopher Baines  wrote:
>> zimoun  writes:
>>
>> > What is the better?
>> >  a- Patch the CMakeLists.txt to generate only the right tests
>> >  b- Turn off all the tests
>>
>> There may be a third option, run only the tests that are known to pass.
>>
>> I know very little about CMake, but I searched for ctest, which is
>> something mentioned in the CMakeLists.txt file, and it brought up this
>> [1] which mentions --exclude-regex and --label-exclude. Maybe these
>> could somehow be passed in, or maybe set through environment variables?
>
> From my understanding, the cmake-build-system calls "make test" and
> not "ctest". Right?

I think CMake generates the Makefile, so I would guess that "make test"
might end up running "ctest".

> If I understand well, the idea should be to turn off the all tests
> ("#:tests? #f") and to add a final phase calling "ctest" with the
> correct tests. Does this make sense?

That would work, but in my opinion a neater approach would be to keep
#:tests? as #t, and replace the 'check phase to call ctest with the
required arguments. Then #:tests? still works as an argument. Something
like...

(arguments
 '(#:phases
   (modify-phases %standard-phases
 (replace 'check
   (lambda* (#:key tests? #:allow-other-keys)
 (when tests?
   (invoke "ctest" "--exclude-regex" "..."))
 #t)

Hope that helps,

Chris


signature.asc
Description: PGP signature

Re: Guix gets a distribution called PantherX

[Pjotr Prins]

On Mon, Feb 11, 2019 at 06:58:25PM +0100, Jonathan Brielmaier wrote:
> Hi Guix folks,
> 
> following a link from bug#34435 I found a pretty interesting website:
> https://www.pantherx.org
> 
> They creating a "modern, Unix-like computer operating system" based on
> GNU Guix[0] with focus on ease of use and privacy.
> 
> I never heard about it before, but to me it looks quite promising.
> According to their timeline a public beta will be released in August
> 2019. Before there seem to be some (closed) alpha and beta versions.
> 
> Their team consists of 9 Members[1], which is pretty impressive.
> 
> They also develop an ARM based Mini-Computer called "Panther Alpha"[2].
> 
> Though I couldn't find any of the team members in some Guix commits or
> patches...
> 
> Kind Regards
> Jonathan Brielmaier
> 
> [0] https://wiki.pantherx.org/PantherX-compared-to-other-distributions/
> [1] https://www.pantherx.org/about/
> [2] http://www.panther-mpc.com/panther-alpha/

This is an interesting start. GNU Guix, GNU Hurd and other projects
may change the shape of computing in the coming 10 years. All we need
is a clued in chip manufacturer.

Pj.

Asking Open Source Design for Videos?

[Björn Höfling]

Hi,

Laura found on FOSDEM the stand of Open Source Design:

https://opensourcedesign.net/

She asked if we should get in contact with them for the videos.
Unfortunately, I missed to go to their stand and talk to them directly
and make my own view.

I'm a bit hesitating with it: First, we yet have a design and if we
need more help, we could ask here on the dev-list where probably
knowing people are around. Second they have a long list of jobs on
their homepage. And last, they say "open source" and not "free
software".

WDYT?

Björn


pgp63MxgGaoVv.pgp
Description: OpenPGP digital signature

English Voice Wanted

[Björn Höfling]

For the upcoming Guix videos we are searching for a (near) native
speaker to speak the transcript. Any candidates?

I'm putting you Chris in CC because I personally enjoy your calm
British accent :-)

Björn




pgp4ONNacR46T.pgp
Description: OpenPGP digital signature

Re: It's time to build "guix deploy"

[Ricardo Wurmus]

Thompson, David  writes:

> Other thoughts?

Just for reference: to update Berlin build nodes I use this script:


https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/install-berlin.scm

It’s not great, but it’s been helpful.

Berlin consists of a head node and many almost identical servers.  To
update one or more servers I run the script on the head node, which
generates operating system configuration variants for each of the
requested servers, builds the systems (offloading to all of the
connected build nodes), copies the system closures to the target
systems, and then runs “reconfigure” on the targets.

Since the operating system configuration record cannot be serialized,
the build nodes need to have a copy of the code that’s used to generate
the operating system configuration.  Not great.  (They only need it to
run “reconfigure”; they wouldn’t need that if “reconfigure” could
operate remotely.)

Anyway, I thought I’d share this with y’all.

--
Ricardo

Using GPG Subkeys with git/savannah

[Björn Höfling]

Hi Laura,

you wanted to know how to use GPG subkeys. You want to use them for
virtual machines. I found a very nice, practical explanation from the
Debian wiki:

https://wiki.debian.org/Subkeys

What I haven't found out is how/if you can use multiple subkeys for
savannah.gnu.org. Does anyone know about that?

Thanks,

Björn


pgpD1_SvdGY68.pgp
Description: OpenPGP digital signature

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

[Danny Milosavljevic]

Hi Chris,

upstream says that compiling rust 1.19.0 works fine for them on i686 with their 
mrustc
master (since they have applied our variable-length integer decoding patch):

https://github.com/thepowersgang/mrustc/issues/108

>Hmm... works for me, using gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 on 
>linux 4.9.0-8-686-pae
>Compiling cargo ran sucessfully.

Would you have some time and a free computer to be able to build rust 1.19.0 
with 

  ./pre-inst-env guix build -K -s i686-linux rust@1.19.0

on guix master with the patch below?

My laptop is currently trying to survive the merge of staging to master and 
keeps
running out of memory if I try to start a rust build in parallel, even with 
swap.

The patch to use mrustc master is:

diff --git a/gnu/packages/rust.scm b/gnu/packages/rust.scm
index e128bb22b..f2a01ded6 100644
--- a/gnu/packages/rust.scm
+++ b/gnu/packages/rust.scm
@@ -97,17 +97,35 @@
 (package
   (name "mrustc")
   (version "0.8.0")
+  ;(source (origin
+  ;  (method git-fetch)
+  ;  (uri (git-reference
+  ;(url "https://github.com/thepowersgang/mrustc.git";)
+  ;(commit (string-append "v" version
+  ;  (file-name (git-file-name name version))
+  ;  (sha256
+  ;   (base32
+  ;"0a7v8ccyzp1sdkwni8h1698hxpfz2sxhcpx42n6l2pbm0rbjp08i"))
+  ;  (patches
+  ;   (search-patches "mrustc-0.8.0-fix-use-after-free.patch"
+  ;   
"mrustc-0.8.0-fix-variable-length-integer-receiving.patch"
+  ;   
"mrustc-0.8.0-fix-emulated-i128-multiply-divide.patch"
+  ;   
"mrustc-0.8.0-fix-i128-overflow-handling.patch"
   (source (origin
 (method git-fetch)
 (uri (git-reference
   (url "https://github.com/thepowersgang/mrustc.git";)
-  (commit (string-append "v" version
+  (commit "7b6fa5c6e7d6838c2479280dd3f8d14a43c13899")))
 (file-name (git-file-name name version))
 (sha256
  (base32
-  "0a7v8ccyzp1sdkwni8h1698hxpfz2sxhcpx42n6l2pbm0rbjp08i"))
+  "0ki5jv76gmvd0q9y2lixzn4xhy1jamba3f77bk8cz2k4ix6yx5z1"))
 (patches
- (search-patches 
"mrustc-0.8.0-fix-variable-length-integer-receiving.patch"
+ (search-patches ;"mrustc-0.8.0-fix-use-after-free.patch"
+ 
;"mrustc-0.8.0-fix-variable-length-integer-receiving.patch"
+ 
;"mrustc-0.8.0-fix-emulated-i128-multiply-divide.patch"
+ 
;"mrustc-0.8.0-fix-i128-overflow-handling.patch"
+ 


Also have to make rust@1.19.0 public or use an "-e" expression.

If you don't have time, no worries, I'll eventually get to it.


pgppdubEse_rZ.pgp
Description: OpenPGP digital signature

Re: Using GPG Subkeys with git/savannah

[Leo Famulari]

On Mon, Feb 11, 2019 at 10:00:20PM +0100, Björn Höfling wrote:
> What I haven't found out is how/if you can use multiple subkeys for
> savannah.gnu.org. Does anyone know about that?

I use GPG subkeys and I use them for Guix.

Regarding Savannah, I think that the only thing required is to upload
the main public key to one's Savannah account. This key should include
everything necessary.


signature.asc
Description: PGP signature

Re: Haskell dependencies for custom cabal builds

[John Soo]

Thanks Tim,

I’ll check out git-annex as a start. Custom Cabal builds would be a nice 
feature to add to the haskell-build-system. Would it be sufficient to add some 
extra argument to the build system?

Best,

John

> On Feb 11, 2019, at 12:19 PM, Timothy Sample  wrote:
> 
> Hi John,
> 
> John Soo  writes:
> 
>> Hi Guix,
>> 
>> I’ve been working on some Haskell packages and got stuck recently and I 
>> didn’t know why until I realized the cabal files have `build-type: Custom`
>> (http://hackage.haskell.org/package/termonad-1.1.0.0/termonad.cabal). I 
>> always get missing dependencies even though I have the dependencies listed 
>> in `inputs` (haskell-gi-base and
>> friends in the example above). What do I need to do to fix this?
> 
> You might be able to take some inspiration from git-annex, which I
> believe has the same problem.
> 
> In short, the issue is that the haskell-build-system unsets
> “GHC_PACKAGE_PATH” before calling “runhaskell Setup.hs”.  This is
> because it assumes that “Setup.hs” will use Cabal in a pretty direct
> way, and that Cabal will setup the required packages from the command
> line (Cabal complains if you try to use “GHC_PACKAGE_PATH”, because it
> wants to be in control of the environment).  If the custom build code
> needs dependencies, they will not be available (unless it does what
> Cabal does and reads package paths from the command line and sets
> everything up from within Haskell).
> 
> For git-annex, I was able to skirt the problem.  I don’t know how to
> solve it.  If you keep “GHC_PACKAGE_PATH” set, the Cabal part of the
> build will likely complain.  However, without it, the custom part of the
> build can’t find its dependencies.
> 
> That’s about all I can recall right now.  I hope that helps at least a
> little bit!  :)
> 
> 
> -- Tim

Re: bug#34211: error running container: mingetty cannot find ttys

[Ludovic Courtès]

Hi Giovanni,

Giovanni Biscuolo  skribis:

> plase is there someone else that could reproduce this issue with "guix
> system container": https://issues.guix.info/issue/34211 ?

[...]

> Feb  6 12:45:44 localhost 
> /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[217]: 
> tty5: No such file or directory
> Feb  6 12:45:44 localhost 
> /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[216]: 
> tty6: No such file or directory
> Feb  6 12:45:44 localhost 
> /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[218]: 
> tty3: No such file or directory
> Feb  6 12:45:44 localhost 
> /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[219]: 
> tty2: No such file or directory
> Feb  6 12:45:44 localhost 
> /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[220]: 
> tty1: No such file or directory
>
> I have to TERM the the container since the "ttN: No such file or
> directory" message loops indefinitely

I also get this behavior.

What happens is that the /dev/ttyN nodes do not exist (understandably),
and thus the ‘console-font-ttyN’ Shepherd services fail to start, and
get restarted, indefinitely.

The container is working as expected though.  If you find the PID of the
container’s ‘shepherd’ process (its PID 1, which obviously has a
different PID outside the container), then you can do:

  guix container exec NNN /bin/sh

where NNN is that PID of that ‘shepherd’ process (I use ‘pstree’ to find
the PID… not very convenient.)

In that shell, you can do:

--8<---cut here---start->8---
sh-4.4#  . /etc/profile 
sh-4.4# ls
bin  dev  etc  gnu  home  proc  root  run  sys  tmp  var
sh-4.4# herd status
Started:
 + containerized-shepherd
 + file-systems
 + guix-daemon
 + host-name
 + loopback
 + nscd
 + root
 + root-file-system
 + ssh-daemon
 + syslogd
 + term-tty1
 + term-tty2
 + term-tty3
 + term-tty4
 + term-tty5
 + term-tty6
 + udev
 + urandom-seed
 + user-file-systems
 + user-processes
 + virtual-terminal
Stopped:
 - console-font-tty1
 - console-font-tty2
 - console-font-tty3
 - console-font-tty4
 - console-font-tty5
 - console-font-tty6
 - networking
 - term-auto
 - user-homes
--8<---cut here---end--->8---

So in that sense everything is working “as expected.”

Now, it would make more sense to simply remove those ‘console-font-ttyN’
services in a container and everything that depends on them.  Not sure
if we should do that automatically.

Thoughts?

Thanks,
Ludo’.