Re: Fennel and Luarocks

[P]

‐‐‐ Original Message ‐‐‐
On Tuesday, June 18, 2019 6:28 PM, Dan Frumin  wrote:

> Hi Marlin!
>
> I am not really familiar with the Lua ecosystem, but wouldn't it be desirable 
> to use Guix to manage Lua package, the way it's done for e.g. Haskell
> right now?
>
> I don't fully understand how luarocks works, but is it possible to have an 
> "importer" for luarocks packages, similar to e.g. the hackage importer?
>
> Best,
> -Dan
>
> On 18-06-19 03:35, Marlin wrote:
>
> > I'm trying to port over fennel and luarocks to guix.
> > Fennel is a lisp language which compiles to lua, and luarocks is a
> > Pypi-like package manager for lua libraries
> > I believe a luarocks build system would be needed.
> > The packges are luarocks.scm and fennel.scm, located at my personal channel.
> > https://framagit.org/marlin1113/marlin-guix-packages

It should definitely be possible, especially for pure Lua packages. What would 
be even cooler is if we could share packages between Lua versions.

luarocks can't do that on its own, but since most pure Lua modules are 
compatible with all three major versions (5.1/luajit,5.2,5.3) it would be 
desirable to be able to only install them once.

It would make testing packages with multiple Lua versions much easier and could 
also cut down on disk usage.

Re: hydra.gnu.org and mirror.hydra.gnu.org service discontinued

[Quiliro's lists]

It is great that Nix had contributed in such a great way to Guix. It is
also nice that now Guix has its own continuos integration software.
Congratulations!

Re: Cuirass enhancements

[Ricardo Wurmus]

Björn Höfling  writes:

> Homepage/Specifications list:
>
> * The list of specifications should be ordered alphabetically by its
> name.

Done.

-- 
Ricardo

[Cuirass] Build details

[Ricardo Wurmus]

Hi Guix,

Cuirass now handles URLs of the pattern /build//details to show you
details of the selected build.  It’s not much at this point and it could
be prettier (e.g. to display the duration in human-readable form, not
just in seconds) and show more information (such as dependencies), but
it’s a start.

Here’s an example so you don’t have to go look for it:

https://ci.guix.gnu.org/build/1399809/details

-- 
Ricardo

Re: Packaging FreeCAD

[Paul Garlick]

Hi John,

> I'm excited to announce that I opened FreeCAD for the first time this
> evening thanks most recently to support on the FreeCAD forum! 

Great news!

> Now where do I put the package definition in gnu/packages? 

How about engineering.scm for FreeCAD?  This module already contains
other CAD-related packages such as LibreCAD and KiCad.

Best regards,

Paul.

Re: Cuirass enhancements

[Ricardo Wurmus]

Hi Björn,

> I would like to see a "build series" for a specific job/system
> combination.
>
> For that, In Hydra I searched for the job name. It first presented me
> with a list of
> "types", like "maven: master/i386" or "maven: staging/x86_64".
>
> Then I had to click one of them to see that specific series.
>
> In the Curiass search, I only have a fulltext search, I cannot choose
> the system.

You can.  E.g. “r-minimal system:armhf-linux spec:guix-master”.

It’s not documented (what’s new…?), but it was the first thing I wanted
after implementing the search itself.

-- 
Ricardo

Re: Packaging FreeCAD

[John Soo]

Hi Gabor!

Thanks!  I’ll let you know when I submit a patch.

- John

Re: Packaging FreeCAD

[Gábor Boskovits]

Hello,p

John Soo  ezt írta (időpont: 2019. jún. 18., Ke 10:27):

> Hi Guix!
>
> I'm excited to announce that I opened FreeCAD for the first time this
> evening thanks most recently to support on the FreeCAD forum! I am no
> expert in the use of the application, however, so I am sure some issues
> might be discovered with use. I already know of the following two issues:
>
>  - Bundled third party packages. Among them: SMESH (from salome or a
> fork), Pivy (from coin3D), libkdtree++ (seems like there is no live source
> or maintainer), and a few others.
>
>  - License help. FreeCAD itself is under the gpl 2.1+, however I think I
> need some guidance providing the correct licenses (both for FreeCAD and the
> bundled source)
>
> Now where do I put the package definition in gnu/packages? I have several
> module definitions in my channel:
>  - salome.scm for libmedfile, smesh and the supporting infrastructure
>  - coin3d.scm for coin3d, soqt, and pivy (WIP)
>  - python-pyside.scm for Shiboken2, Pyside2, and Pyside2-tools
>  - libarea.scm for libarea
>  - libspnav.scm for libspnav and
>  - freecad.scm for FreeCAD itself
>
> I am happy to finally learn to use the app!
>
> - John
>

This is great!

I am not an expert on the where to place things, but if you don't find some
module that is a clear fit for your package, then you can create a new one.
With that said, I believe you can put coin into somewhere graphics related,
and the python stuff to python-xyz.

I also have some freecad projects, so I can help with testing if needed.


> On Thu, May 30, 2019 at 11:23 PM Paul Garlick <
> pgarl...@tourbillion-technology.com> wrote:
>
>> Hi John,
>>
>> > Another question: do we tend to try to use guix packages whenever a
>> package
>> > ships bundled with some third party source?
>>
>> Yes.  The preference is to use Guix packages where possible.
>>
>> Best regards,
>>
>> Paul.
>>
> Best regards,
g_bor

>
>>
>>
>>

Cuirass enhancements

[Björn Höfling]

Hi Guix,

I was a bit sad that Hydra is down now, because I really got used to
its interface. Thanks to Mark and all others who made their fingers
dirty on that machine. After a little chat on IRC, I decided to compare
Cuirass with Hydra and wrote down what I'm missing or find
uncomfortable in its daily usage.

I think I'm pretty good at pulling apart other people's software and
can be quite picky. So, let me say that I really appreciate what all
contributors have done so far and take this as suggestions for
enhancements.

It might also just be the case that I missed something and what I want
is already implemented in a different way.

After some discussions, I could add this as little, compact bugs into
Debbugs. If you know of already existing bugs, it would be nice if you
could mention them.

Homepage/Specifications list:

* The list of specifications should be ordered alphabetically by its
name.
* The specification and input seams to be redundant. Why?:
("staging-staging   INPUT: staging (on staging)"
* A description would be nice to better understand the use of that
specification.

Clicking into a specification gives a list of evaluations, like here:
https://ci.guix.gnu.org/jobset/guix-master

In that list:

* I'm missing a column with start-date of that evaluation.
* Right now, I see one evaluation where column "Success" being "In
progress ..."
The next evaluations have three colored numbers, in green, red and grey.
When I remember it correctly from Hydra, then "grey" would mean
"queued." But then the term "In progress ..." is a bit misleading, as
those with items in queue are also "In progress ...".

If I understand it right, maybe "Preparing ..." would be a better term?

* [unimportant]: The evaluation lists an input change. It would be nice
to directly point to the new commit (and old commit?). That said, it
could get complicated, as Cuirass is a general build system and not
every git repository has a public interface. Thus, we might need to add
another configuration to the input data-structure, like
"webinterface-uri". Sounds more complicated than worth the efford?

Going into one evaluation, like
https://ci.guix.gnu.org/eval/5874

* It would be nice if the summary of good/bad/queued numbers is repeated
in the header.
* The table should be sorted by job name.
* I'm missing a "completion time" for failed jobs. I mean there must be
some instance in time when failure was evaluated.
* I'm really missing the tabs/filters like in Hydra: "succeding",
"newly succeding", "newly failing", ...
In having all jobs in one big list is annoying. I care usually only
about failures.
* If a job failed because of its dependency, I would like to see which
one caused the problem. I don't know how to find that out.
In Hydra, the name and build log of the failing dependency was directly
available.

Job search:

It's nice that there is a search now, but it's not enough for me :-)

The search string disappears from the search box. It would be very nice
if it would be kept, then I can remember and refine it if necessary.

I would like to see a "build series" for a specific job/system
combination.

For that, In Hydra I searched for the job name. It first presented me
with a list of
"types", like "maven: master/i386" or "maven: staging/x86_64".

Then I had to click one of them to see that specific series.

In the Curiass search, I only have a fulltext search, I cannot choose
the system.

How would I find the proper "maven", not all the "maven-*" packages?

In Hydra, there is a link to this "build series":

https://hydra.nixos.org/job/nixpkgs/staging-next/maven3.x86_64-darwin

Even if I find it hard to get to my specific package by search, I can
modify that link to get to my package (and add a bookmark for my loved
package :-)).


Scrolling:

* I would like to know that I'm on page k/n.
* When scrolling through lists, the semantics of "first/prev/next/last"
is not the way I expect it, at first I thought it is totally broken.

For example this evaluation:

https://ci.guix.gnu.org/eval/5862?border-high-time=1560824784&border-high-id=1398865

I'm at the first tab. "Previous" is greyed out. Then I would expect
"First" also to be greyed out: If I cannot go any further back, I am on
the "First" tab (linear, consecutive order of tabs assumed :-))

Even worse at the end: I can click four times on "Next", and then be at
a page that shows only three jobs (the total number of jobs is not
always dividable by the number of jobs per page, so the last page
usually has a smaller remainder to show):
https://ci.guix.gnu.org/eval/5862?border-high-time=1560816540&border-high-id=1398862
So, I cannot go any NEXTer, that button is greyed out. As with the
beginning, I'm expecting to be already on the LAST page. But the button
is clickable. And when I click it, I will receive a FULL PAGE! It took
me a while to figure out that nothing too bad happened: I'm getting the
last n entrys (where n is the number of elements per page, being 10
here). I can 

Re: hydra.gnu.org and mirror.hydra.gnu.org service discontinued

[Vagrant Cascadian]

On 2019-06-18, Ludovic Courtès wrote:
> After seven years of service, the continuous integration service and
> ‘guix publish’ service running at hydra.gnu.org, as well as its mirror
> at mirror.hydra.gnu.org, are now discontinued.

Curious how this will affect armhf systems, as berlin didn't tend to
have many substitutes for armhf. Rekado mentioned on irc that the
builders that were running on hydra could be reconfigured to work with
the berlin build farm?

With armhf machines being generally slow, substitutes are really quite
nice to have working! :)

Thanks everyone for their past, present and future work maintaining
infrastructure for substitute servers!

live well,
  vagrant


signature.asc
Description: PGP signature

Re: where to put helper to send stdout/stderr to syslog?

[Robert Vollmert]

> On 18. Jun 2019, at 15:32, Ludovic Courtès  wrote:
> 
> Hi,
> 
> Danny Milosavljevic  skribis:
> 
>> I think it could be made part of shepherd and be exported there, then 
>> everyone
>> could use it.  Logging to syslog isn't exactly an obscure requirement :)
> 
> +1!
> 
>> Although shepherd already has its own /dev/log (syslog) client 
>> implementation,
>> the external "logger" executable (or similar) is still necessary, because
>> /dev/log is a UNIX domain socket and one can't write to UNIX domain sockets
>> the same way one does pipes.  Although it might be possible (and not
>> advisable) to connect() the socket and then dup it to 1 and 2 for the child 
>> :P
> 
> Yes, that should be enough.
> 
> Robert, would you like to give it a go?

I’d rather not get too deep into shepherd at this point.

Here’s the wrapper updated in response to Danny’s comments, in case you want to
reuse that inside shepherd:

(define* (logger-wrapper name exec . args)
  "Return a derivation that builds a script to start a process with
standard output and error redirected to syslog via logger."
  (define exp
#~(begin
(use-modules (ice-9 popen))
(let* ((pid(number->string (getpid)))
   (logger #$(file-append inetutils "/bin/logger"))
   (args   (list "-t" #$name (string-append "--id=" pid)))
   (pipe   (apply open-pipe* OPEN_WRITE logger args)))
  (dup pipe 1)
  (dup pipe 2)
  (execl #$exec #$exec #$@args
  (program-file (string-append name "-logger") exp))

Cheers
Robert

Re: Fennel and Luarocks

[Dan Frumin]

Hi Marlin!

I am not really familiar with the Lua ecosystem, but wouldn't it be desirable to use Guix to manage Lua package, the way it's done for e.g. Haskell 
right now?


I don't fully understand how luarocks works, but is it possible to have an 
"importer" for luarocks packages, similar to e.g. the hackage importer?

Best,
-Dan

On 18-06-19 03:35, Marlin wrote:

I'm trying to port over fennel and luarocks to guix.
Fennel is a lisp language which compiles to lua, and luarocks is a
Pypi-like package manager for lua libraries
I believe a luarocks build system would be needed.
The packges are luarocks.scm and fennel.scm, located at my personal channel.
https://framagit.org/marlin1113/marlin-guix-packages

Re: hydra.gnu.org and mirror.hydra.gnu.org service discontinued

[Leo Famulari]

On Tue, Jun 18, 2019 at 03:19:41PM +0200, Ludovic Courtès wrote:
> Many thanks to everyone who helped maintain this service over the years,
> and in particular to Mark H Weaver for all the energy put into making it
> run as smoothly as possible!

Indeed, Mark worked tirelessly behind the scenes for years to maintain
our Hydra instance! His effort was instrumental in maintaining the rapid
pace of Guix development during those years. Thank you, Mark!


signature.asc
Description: PGP signature

Re: Down with PYTHONPATH!

[Konrad Hinsen]

Hi Pjotr,

> It would be interesting to see how others solve this problem.
> Including Nix and Conda.

Conda uses the same approach as Python's virtualenv: create a seperate
Python installation made up mainly of linke to files shared with other
such installations.

We could probably do something similar in Guix as well, assuming we can
make the Python executable figure out from which environment it was
started.

Konrad

Re: where to put helper to send stdout/stderr to syslog?

[Ludovic Courtès]

Hi,

Danny Milosavljevic  skribis:

> I think it could be made part of shepherd and be exported there, then everyone
> could use it.  Logging to syslog isn't exactly an obscure requirement :)

+1!

> Although shepherd already has its own /dev/log (syslog) client implementation,
> the external "logger" executable (or similar) is still necessary, because
> /dev/log is a UNIX domain socket and one can't write to UNIX domain sockets
> the same way one does pipes.  Although it might be possible (and not
> advisable) to connect() the socket and then dup it to 1 and 2 for the child :P

Yes, that should be enough.

Robert, would you like to give it a go?

Thanks,
Ludo’.

hydra.gnu.org and mirror.hydra.gnu.org service discontinued

[Ludovic Courtès]

Hello Guix,

After seven years of service, the continuous integration service and
‘guix publish’ service running at hydra.gnu.org, as well as its mirror
at mirror.hydra.gnu.org, are now discontinued.

As a reminder, starting from Guix 0.16.0 in December 2018¹, the default
host for substitutes and for continuous integration is ci.guix.gnu.org, a
mirror of berlin.guix.gnu.org, which was formerly known as ci.guix.info.


Many thanks to everyone who helped maintain this service over the years,
and in particular to Mark H Weaver for all the energy put into making it
run as smoothly as possible!

For the record, hydra.gnu.org used to run Hydra² for continuous
integration, on top of Trisquel; ci.guix.gnu.org runs Cuirass on Guix
and you can find its complete configuration in maintenance.git³.

Ludo’.

¹ https://gnu.org/s/guix/blog/2018/gnu-guix-and-guixsd-0.16.0-released/
² https://nixos.org/hydra/
³ https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/


signature.asc
Description: PGP signature

Re: Packaging Sagemath

[Andreas Enge]

On Tue, Jun 18, 2019 at 01:30:06PM +0200, Andreas Enge wrote:
> We may as well delete the packaged
> items (as I have been doing for two or three I just packaged now), and
> leave only TODO items.

Well, no; I have actually kept packages that I did not yet add to my
preliminary sage recipe, be they available or not. It is just that I have
been packaging "in order", with every new package immediately added to
sage and then deleted from the list.

Andreas

Re: Packaging Sagemath

[Andreas Enge]

On Tue, Jun 18, 2019 at 11:47:29AM +0200, Nicolas Goaziou wrote:
> I followed the link, but, IIUC, it is not up-to-date. For example, we
> already have packaged many of them. Would it be useful to set-up
> a world-writable document (e.g., a pad) somewhere, with a list of the
> packages yet to be packaged, or a checklist with all packages that we
> could tick-off?

Indeed, many of them are already available, this is the list of all
dependencies that we will (probably) have to add to the Sage recipe at
some point. I did not go through it to check which ones we already have.

> For example, here is such an up-to-date list, barring a few FIXME
> I wasn't sure about:

Thanks for the work on the list! As far as I can tell, the web page is
already a world-writable pad; just click on the pencil or the split-page
icons at the top left of the page. We may as well delete the packaged
items (as I have been doing for two or three I just packaged now), and
leave only TODO items.

> I'll try to help when I have time.

Great, I was actually thinking of you when I wrote the message, since
you added a few mathematical software packages already :-)

Andreas

Re: Packaging Sagemath

[Nicolas Goaziou]

Hello,

Andreas Enge  writes:

> My personal goal is to get closer to having Sage in Guix. 

Very nice!

> But there is also a list of (altogether 181!) required dependencies,
> which I extracted here: https://hackmd.io/zatG6NwtTWKF5asn_fmcIw?view

I followed the link, but, IIUC, it is not up-to-date. For example, we
already have packaged many of them. Would it be useful to set-up
a world-writable document (e.g., a pad) somewhere, with a list of the
packages yet to be packaged, or a checklist with all packages that we
could tick-off?

For example, here is such an up-to-date list, barring a few FIXME
I wasn't sure about:

- [ ] appnope
- [X] arb
- [X] babel
- [X] backports_abc
- [X] backports_functools_lru_cache
- [X] backports_shutil_get_terminal_size
- [X] backports_ssl_match_hostname
- [X] bleach
- [ ] brial
- [X] bzip2
- [X] cddlib
- [X] certifi
- [ ] combinatorial_designs
- [X] configparser
- [ ] conway_polynomials
- [X] curl
- [X] cvxopt
- [X] cycler
- [X] dateutil
- [X] decorator
- [X] docutils
- [ ] eclib
- [X] ecm
- [ ] elliptic_curves
- [X] entrypoints
- [X] enum34
- [ ] fflas_ffpack
- [ ] flask_autoindex
- [X] flask_babel
- [ ] flask_oldsessions
- [ ] flask_openid
- [ ] flask_silk
- [X] flask
- [ ] flintqs
- [ ] fplll FIXME: available in version 4, so what?
- [ ] fpylll
- [X] freetype
- [X] functools32
- [X] future
- [ ] gf2x
- [ ] gfan
- [X] giac
- [X] git
- [ ] givaro (next missing, in the works)
- [ ] graphs
- [X] html5lib
- [X] iconv
- [X] imagesize
- [ ] iml FIXME: imlib2?
- [X] ipaddress
- [X] ipykernel
- [X] ipython_genutils
- [X] ipython
- [X] ipywidgets
- [X] itsdangerous
- [X] jinja2
- [ ] jmol
- [X] jsonschema
- [X] jupyter_client
- [X] jupyter_core
- [X] kiwisolver
- [ ] lcalc
- [X] libatomic_ops
- [ ] libgd FIXME: libgdata?
- [X] libpng
- [ ] linbox
- [ ] lrcalc
- [ ] m4rie
- [ ] m4ri
- [X] markupsafe
- [X] mathjax
- [X] matplotlib
- [X] maxima
- [X] mistune
- [X] mpfi
- [X] mpmath
- [X] nauty
- [X] nbconvert
- [X] nbformat
- [X] ncurses
- [X] networkx
- [X] notebook
- [X] openblas
- [X] packaging
- [ ] palp
- [ ] pandocfilters
- [ ] pari_galdata
- [ ] pari_seadata_small
- [X] patch
- [X] pathlib2
- [X] pathpy
- [X] pcre
- [X] pexpect
- [X] pickleshare
- [X] pillow
- [X] pip
- [X] pkgconfig
- [ ] pkgconf
- [ ] polytopes_db
- [ ] ppl
- [X] prometheus_client
- [X] prompt_toolkit
- [X] psutil
- [X] ptyprocess
- [ ] pycygwin
- [X] pygments
- [ ] pynac FIXME: pynacl?
- [X] pyparsing
- [X] python_openid
- [X] pytz
- [X] pyzmq
- [ ] ratpoints
- [X] readline
- [X] requests
- [X] rpy2
- [X] r
- [ ] rubiks
- [ ] sagenb_export
- [ ] sagenb
- [ ] sagetex
- [X] scandir
- [X] scipy
- [X] send2trash
- [X] setuptools_scm
- [X] setuptools
- [X] simplegeneric
- [X] singledispatch
- [X] snowballstemmer
- [ ] speaklater
- [X] sphinxcontrib_websupport
- [X] sphinx
- [X] sqlite
- [X] subprocess32
- [ ] symmetrica
- [ ] sympow
- [X] sympy
- [ ] tachyon
- [X] terminado
- [X] testpath
- [ ] thebe
- [ ] threejs FIXME: r-threejs?
- [X] tornado
- [X] traitlets
- [X] twisted
- [X] typing
- [X] vcversioner
- [X] wcwidth
- [X] webencodings
- [X] werkzeug
- [X] widgetsnbextension
- [X] xz
- [X] yasm
- [X] zeromq
- [X] zlib
- [ ] zn_poly
- [X] zope_interface

> So sooner or later we will need all of these packages, and if you feel
> motivated to package one or the other we do not have yet, you are more
> than welcome!

I'll try to help when I have time.

Regards,

-- 
Nicolas Goaziou

Re: Down with PYTHONPATH!

[Hartmut Goebel]

Am 17.06.19 um 20:34 schrieb Ricardo Wurmus:
> Yes, those solutions aren’t pretty but they are well understood and have
> no surprising behaviour, which is what I meant.  GUIX_PYTHON2/3PATH
> would be a boring solution that works just like the others I listed.

TL;DR: Got for GUIX_PYTHONPATH_3_7.

Sorry, last weekend I did not find the time to pick up my last year's
work and prepare a hand-over. Not sure if I will make it this month
(given I'll be off some days). So just a quick answer:

1) Using some GUIX_PYTHONPATH is an improvement to the current situation
and could be implemented quickly.

If this variable is going to be exposed to the user's environment (say:
used outside of wrapper scripts), I suggest including the version into
the name: e.g. GUIX_PYTHONPATH_3_7. Otherwise one will still get
conflicts if one has installed Python 3.5, 3.6 and 3.8 in the same
environment. (Yes, this is a common case for developers.)

2a) My plan is to make the python executable aware of its "home"
("installation directory", the profile) without using any environment
variable. python already does this (by resolving all symlinks), we just
need to adopt this to stop at the profile. This should bea eay to
implement, I have a draft ready but need to prepare the hand-over.

2b) Another idea is to change the build-system to leverage virtualenvs
for Python scripts/apps/tools. This would not only remove the need for
wrappers, but should also solve conflicts if a script requires a
different versions of packages than installed in the profile.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel  | h.goe...@crazy-compilers.com   |
| www.crazy-compilers.com | compilers which you thought are impossible |

Re: Packaging FreeCAD

[John Soo]

Hi Guix!

I'm excited to announce that I opened FreeCAD for the first time this
evening thanks most recently to support on the FreeCAD forum! I am no
expert in the use of the application, however, so I am sure some issues
might be discovered with use. I already know of the following two issues:

 - Bundled third party packages. Among them: SMESH (from salome or a fork),
Pivy (from coin3D), libkdtree++ (seems like there is no live source or
maintainer), and a few others.

 - License help. FreeCAD itself is under the gpl 2.1+, however I think I
need some guidance providing the correct licenses (both for FreeCAD and the
bundled source)

Now where do I put the package definition in gnu/packages? I have several
module definitions in my channel:
 - salome.scm for libmedfile, smesh and the supporting infrastructure
 - coin3d.scm for coin3d, soqt, and pivy (WIP)
 - python-pyside.scm for Shiboken2, Pyside2, and Pyside2-tools
 - libarea.scm for libarea
 - libspnav.scm for libspnav and
 - freecad.scm for FreeCAD itself

I am happy to finally learn to use the app!

- John

On Thu, May 30, 2019 at 11:23 PM Paul Garlick <
pgarl...@tourbillion-technology.com> wrote:

> Hi John,
>
> > Another question: do we tend to try to use guix packages whenever a
> package
> > ships bundled with some third party source?
>
> Yes.  The preference is to use Guix packages where possible.
>
> Best regards,
>
> Paul.
>
>
>
>

Packaging Sagemath

[Andreas Enge]

Hello,

until Thursday evening, before joining the Guile-Guix-Perl days in
Strasbourg, I am taking part in a coding sprint around packaging Sagemath:
   https://hackmd.io/j5FzB173Q4uaExUw-6Glpg#
My personal goal is to get closer to having Sage in Guix. As usual, I have
started a package definition and am adding dependencies one by one as the
build fails; current status attached. But there is also a list of (altogether
181!) required dependencies, which I extracted here:
   https://hackmd.io/zatG6NwtTWKF5asn_fmcIw?view
So sooner or later we will need all of these packages, and if you feel
motivated to package one or the other we do not have yet, you are more
than welcome!

Andreas

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

(define-module (gnu packages sagemath)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (guix build-system gnu)
  #:use-module (guix build-system python)
  #:use-module (guix download)
  #:use-module (guix git-download)
  #:use-module (guix packages)
  #:use-module (gnu packages algebra)
  #:use-module (gnu packages autotools)
  #:use-module (gnu packages bdw-gc)
  #:use-module (gnu packages boost)
  #:use-module (gnu packages compression)
  #:use-module (gnu packages graph)
  #:use-module (gnu packages lisp)
  #:use-module (gnu packages maths)
  #:use-module (gnu packages multiprecision)
  #:use-module (gnu packages pkg-config)
  #:use-module (gnu packages python)
  #:use-module (gnu packages python-xyz))


(define-public python-cypari2
  (package
(name "python-cypari2")
(version "2.1.1")
(source
 (origin
   (method url-fetch)
   (uri (pypi-uri "cypari2" version))
   (sha256
(base32
 "1nwkzgqvbw6361x0rpggy1q5nx663fswhpvg8md6xhqyfwpgc7nz"
(build-system python-build-system)
(native-inputs
 `(("python-cython" ,python-cython)))
(propagated-inputs
 `(("python-cysignals" ,python-cysignals)))
(inputs
 `(("gmp" ,gmp)
   ("pari-gp", pari-gp)))
(home-page "https://cypari2.readthedocs.io/";)
(synopsis
 "Python interface to the number theory library libpari")
(description
 "Cypari2 provides a Python interface to the number theory library
PARI/GP.  It has been spun off from the SageMath mathematics software system,
but it can be used independently.")
(license license:gpl2+)))

(define-public python2-cypari2
  (package-with-python2 python-cypari2))

;; The stable version of the following package is not young enough to be
;; used with Sage, since it does not support cython. One would need to
;; use an alpha release. On the other hand, Sage can be built without it.
(define-public python-gmpy2
  (package
(name "python-gmpy2")
(version "2.0.8")
(source (origin
  (method url-fetch)
  (uri (pypi-uri "gmpy2" version ".zip"))
  (sha256
   (base32
"0grx6zmi99iaslm07w6c2aqpnmbkgrxcqjrqpfq223xri0r3w8yx"
(build-system python-build-system)
(native-inputs
 `(("unzip" ,unzip)))
(inputs
 `(("gmp" ,gmp)
   ("mpfr" ,mpfr)
   ("mpc" ,mpc)))
(home-page "https://github.com/aleaxit/gmpy";)
(synopsis
 "GMP/MPIR, MPFR, and MPC interface to Python 2.6+ and 3.x")
(description
 "This package provides a Python interface to the GNU multiprecision
libraries GMO, MPFR and MPC.")
(license license:lgpl3+)))

(define-public python2-gmpy2
  (package-with-python2 python-gmpy2))

(define-public cliquer
  (package
(name "cliquer")
(version "1.21")
;; The original source package is available from the home page and
;; has not seen any release since 2010; it comes with only a Makefile
;; without an "install" target. Instead, there is an autotoolized
;; tarball available from the Sage project.
(source
 (origin
   (method url-fetch)
   (uri "http://users.ox.ac.uk/~coml0531/sage/cliquer-1.21.tar.gz";)
   (sha256
(base32
 "1hdzrmrx0nvvj8kbwxrs8swqgkd284khzl623jizixcv28xb77aq"
(build-system gnu-build-system)
(synopsis "C routines for finding cliques in weighted graphs")
(description "Cliquer is a set of reentrant C routines for finding
cliques in a weighted or unweighted graph.  It uses an exact
bran

Re: Porting Lutris over

[L p R n d n]

Hello,


Here is what I had somewhere lost on my computer for lutris:

(arguments
 `(#:tests? #f
   #:phases
   (modify-phases %standard-phases
 (add-after 'install 'wrap-program
   (lambda* (#:key outputs inputs #:allow-other-keys)
 (let* ((out (assoc-ref outputs "out"))
(input-path (lambda (lib path)
  (string-append (assoc-ref inputs lib) path)))
(libraries '("mesa" "glu" "libdrm" "webkitgtk"))

(libs
 (map (lambda (lib) (input-path lib "/lib"))
  libraries))
(gi-typelib-path (getenv "GI_TYPELIB_PATH")))
   (wrap-program (string-append out "/bin/lutris")
 `("GI_TYPELIB_PATH" = (,gi-typelib-path))
 `("LD_LIBRARY_PATH" ":" prefix ,libs))
   #t))

As I remember, it should build but I kind of gave up with runtime stuff.
Also, I'm not sure it's compatible with FSF.
Hope it helps.

Lprndn

Re: Magit is very slow with Guix's Git checkout

[Ricardo Wurmus]

Hi Chris,

> I've been learning to use Magit more and more, and I really enjoy it.
> However, I've noticed that it takes a very long time (minutes) to give
> control back to me when I run "M-x magit-status" in my Guix checkout.
>
> Am I doing something wrong?  Is there a way to avoid this slowdown?

Run “git checkout -- po” to undo the automatically generated changes to
the “po” directory, which in my experience is responsible for the slow
down.

--
Ricardo

Re: Magit is very slow with Guix's Git checkout

[Christopher Baines]

Chris Marusich  writes:

> I've been learning to use Magit more and more, and I really enjoy it.
> However, I've noticed that it takes a very long time (minutes) to give
> control back to me when I run "M-x magit-status" in my Guix checkout.
>
> Am I doing something wrong?  Is there a way to avoid this slowdown?
> Magit is great, but it's painfully slow when I try to use it to interact
> with the Guix's Git repository.

This is probably due to the po directory containing lots of changes. I
normally get rid of these changes, as I never intentionally changed
anything in that directory. Magit is probably slow as it's rendering the
diffs for large files, so I'd watch out for what changes you have in the
repository if Magit is slow.


signature.asc
Description: PGP signature

Re: Magit is very slow with Guix's Git checkout

[Andy Wingo]

On Tue 18 Jun 2019 06:04, Chris Marusich  writes:

> I've been learning to use Magit more and more, and I really enjoy it.
> However, I've noticed that it takes a very long time (minutes) to give
> control back to me when I run "M-x magit-status" in my Guix checkout.
>
> Am I doing something wrong?  Is there a way to avoid this slowdown?
> Magit is great, but it's painfully slow when I try to use it to interact
> with the Guix's Git repository.

Apparently issues like https://github.com/magit/magit/issues/3808 are
being systematically closed in favor of a plan to compute diffs in two
steps.  However I don't entirely understand the argument as magit-status
on a clean tree should be free.  I share the frustration.

Andy

Re: Porting Lutris over

[Pierre Neidhardt]

This is great news!  I won't have too much time either, but maybe in
July I can help!
Ping me :)

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


signature.asc
Description: PGP signature