Re: Reproducible Research Hackathon: Friday, July 3rd
We at UTHSC are game. We are struggling with an old version of the GeneNetwork web service 1.x which is now running on a 10 year old CentOS. The backup time machine server died recently. GenNetwork1 depends on Python 2.4(!) with modules that have not been updated this century, and an older version of Apache with mod_python, amongst other things. We would like to use the guix time-machine feature to run older versions on demand in containers, also for the recent GeneNetwork2 version which runs on a modern Guix stack. When we get it to work I would like to push the older packages in Guix-Past. Bit much for one day, but let's see where it ends. There is no point in updating the older GeneNetwork1 instances, I mean the code. The point really is that it is a reproducible version tied to older scientific publications that people still can explore. Note that GeneNetwork requires a largisch MySQL/MariaDB (170GB) which is also a snapshot in time. We have 5+ snapshots of that database that go with 5+ versions of the code. We want to run them all under Guix so we no longer have to care about the underlying Linux distro. With the newer GeneNetwork2 stack we are thinking of making use of Guix timemachine to run snapshots, firing containers up on demand. These will have to be tied with a certain version of the database, so we have to force time points maintained outside the package Guix git repo. The databases can be ready to run - listening on a different port for each version. Nice challenge and it will make a great story when it works. Pj. On Tue, Jun 30, 2020 at 02:40:12PM +0200, simon tournier wrote: > Hello, > > We are pleased to announce a Hackathon about Reproducible Science. > > We propose to collectively tackle some issues on *Friday, July 3rd*: > > - identify stumbling blocks in using Guix to write end-to-end > pipelines, > - document how to achieve this, > - feed the Guix-Past channel by other old packages, > - provide guix.scm for some of the ReScience C submissions. > > Feel free to contact us at guix-...@gnu.org if you would like to hack > with us. > > We will meet at *9:30 CEST* on the #guix-hpc channel of > irc.freenode.net. You can use this web client to reach us: > > http://guix.gnu.org/contact/irc/ > > (tweaking the channel name). > > Read more details at: > > https://hpc.guix.info/blog/2020/06/reproducible-research-hackathon > > Hope to see you on Friday.
Re: Installer script on Fedora doesn't work properly
Jan Wielkiewicz writes: >> This means the daemon isn’t running. >> >> If you use SELinux in enforcing mode then the daemon is probably >> prevented from starting. > I'm not aware of this - I just picked all default settings, not that > the choice was big. It’s not Guix, it’s Fedora. Fedora ships with SELinux enabled by default, which means that all software needs to have a policy that declares in what context it runs and what other contexts it can access. >> Sure. We have a draft SELinux policy for systems like yours, but it >> is probably no longer current as Fedora’s SELinux policy is not >> frozen in time. I encourage you to try it and help debug it to >> adjust it for current versions of Fedora. > That's my first day running Fedora, but if someone gives me right > directions, I can help. The first thing to do is to install the guix-daemon.cil file as explained in the manual. That file is part of the Guix source repository. Then as you start guix-daemon you need to look at /var/log/audit/audit.log (or similar) to see why SELinux blocked the daemon from running. -- Ricardo
Re: Installer script on Fedora doesn't work properly
On Tue, 30 Jun 2020 14:07:44 +0200 Ricardo Wurmus wrote: > > Hi Jan, Hi! > > This means the daemon isn’t running. > > If you use SELinux in enforcing mode then the daemon is probably > prevented from starting. I'm not aware of this - I just picked all default settings, not that the choice was big. > > Sure. We have a draft SELinux policy for systems like yours, but it > is probably no longer current as Fedora’s SELinux policy is not > frozen in time. I encourage you to try it and help debug it to > adjust it for current versions of Fedora. That's my first day running Fedora, but if someone gives me right directions, I can help. > > These recommendations wouldn’t help in your case. We can’t feasibly > maintain a farm of different distros (some with SELinux and some > without) where we install Guix all the time. > Even manual testing before making a release would be good. Btw adding checkboxes to the issue tracker would make it easier for everyone. Anyway, Guix should work on disributions considered to be "industry standard" such as Debian, Fedora, etc. What about a list of distributions Guix was tested on in the manual, with a link to it somewhere on the main page. The first impression is really important. Jan Wielkiewcz
Reproducible Research Hackathon: Friday, July 3rd
Hello, We are pleased to announce a Hackathon about Reproducible Science. We propose to collectively tackle some issues on *Friday, July 3rd*: - identify stumbling blocks in using Guix to write end-to-end pipelines, - document how to achieve this, - feed the Guix-Past channel by other old packages, - provide guix.scm for some of the ReScience C submissions. Feel free to contact us at guix-...@gnu.org if you would like to hack with us. We will meet at *9:30 CEST* on the #guix-hpc channel of irc.freenode.net. You can use this web client to reach us: http://guix.gnu.org/contact/irc/ (tweaking the channel name). Read more details at: https://hpc.guix.info/blog/2020/06/reproducible-research-hackathon Hope to see you on Friday.
Re: Installer script on Fedora doesn't work properly
Hi Jan, > I ran the script as root, it installed everything properly, but running > "guix pull" ends up with an error message: "guix pull: failed to connect > to `/var/guix/daemon-socket/socket': No such file or directory". This means the daemon isn’t running. If you use SELinux in enforcing mode then the daemon is probably prevented from starting. > I think the installer script should *just work at all times* - this is > crucial to make Guix popular on other distros. Sure. We have a draft SELinux policy for systems like yours, but it is probably no longer current as Fedora’s SELinux policy is not frozen in time. I encourage you to try it and help debug it to adjust it for current versions of Fedora. > My suggestion: if it's not already done, consider adding automated > tests, checking whether the installer script works on major > distributions (on a VM) and if Guix works there. This should be checked > every release. These recommendations wouldn’t help in your case. We can’t feasibly maintain a farm of different distros (some with SELinux and some without) where we install Guix all the time. -- Ricardo
Re: Installer script on Fedora doesn't work properly
I'm guessing that the systemd service to start the guix daemon failed... Is there a way that you can manually enable & start the systemd daemon that guix ships with? June 29, 2020 6:05 PM, "Jan Wielkiewicz" wrote: > Hello, > > I'm trying to install Guix on Fedora using the install script, but > something is not right. > I ran the script as root, it installed everything properly, but running > "guix pull" ends up with an error message: "guix pull: failed to connect > to `/var/guix/daemon-socket/socket': No such file or directory". > I tried rebooting a few times, running "systemctl enable guix-daemon", > "systemctl start guix-daemon", but with the same result. > Any idea what's wrong? > I think the installer script should *just work at all times* - this is > crucial to make Guix popular on other distros. > My suggestion: if it's not already done, consider adding automated > tests, checking whether the installer script works on major > distributions (on a VM) and if Guix works there. This should be checked > every release. > > P.S. I'm going to resume my work on Jami soon, I've been busy with my > exams lately :P > > Jan Wielkiewicz
Re: guix search: first line(s) not shown
Ekaitz, Ekaitz Zarraga 写道： With the recent adoption of $PAGER in `guix search` I'm experiencing an issue. The some of the firsts lines are not shown if the output long enough to cover the full screen so I can't see the first package name. It forces me to scroll down and up again. […] Is this happening to others too? Yes! It looks like (at least) rendering ‘description’ doesn't account for the length of the "description: " prefix itself, making the first line too long. That confuses less and/or makes it wrap non-deterministically. After invoking ‘guix search foo’, name and version are missing, and: --8<---cut here---start->8--- description: This package aims to provide a one-stop solution to requirements for footnotes. It offers: Multiple footnote + apparatus superior to that of `manyfoot'. Footnotes can be formatted in separate paragraphs, or be run into a --8<---cut here---end--->8--- After scrolling down and then up: --8<---cut here---start->8--- description: This package aims to provide a one-stop solution to requirements for footnotes. It offers: Multiple footnoteus superior to that of `manyfoot'. Footnotes can be formatted in separate paragraphs, or be run into a --8<---cut here---end--->8--- (‘footnoteus’). The description ‘shrinks’ by 2 lines, making room for the name and version fields at the top. Kind regards, T G-R signature.asc Description: PGP signature
guix search: first line not shown
Hi, With the recent adoption of $PAGER in `guix search` I'm experiencing an issue. The some of the firsts lines are not shown if the output long enough to cover the full screen so I can't see the first package name. It forces me to scroll down and up again. If I run `guix search | less` works as expected. Other paged commands like git work as expected too. Is this happening to others too? Best, Ekaitz
