Re: Reproducible Research Hackathon: Friday, July 3rd
Hi Pjotr, Thank you for sharing your plans. On Tue, 30 Jun 2020 at 23:57, Pjotr Prins wrote: > 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. I guess that the recent commit [1] by Efraim is part of this effort. :-) By container, what do you have in mind: guix time-machine --channels=file.scm \ -- environment --container or -- pack -f or -- system *-image ? 1: https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/f9fe4d8ac2706834fcff477db8f5421de537d78e > 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. I agree that Guix does not have (yet!) good management of large data set. The /gnu/store is not designed for that, if I have correctly understood. Even we have already discussed Content-Addressable Storage (CAS) on gwl-de...@gnu.org, AFAIR, we have not ended up with a good plan. Well, it will not be fixed on Friday. :-) But for sure, it is something to keep in mind. So, see you on Friday. :-) Cheers, simon
Re: Reproducible Research Hackathon: Friday, July 3rd
On Wed, Jul 01, 2020 at 11:10:23AM +0200, zimoun wrote: > Hi Pjotr, > > Thank you for sharing your plans. > > On Tue, 30 Jun 2020 at 23:57, Pjotr Prins wrote: > > > 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. > > I guess that the recent commit [1] by Efraim is part of this effort. :-) Part of the effort :) I have a bunch more older packages that I'll probably push to guix-past as time goes on. Right now I have a no-longer-working octave-3.4.3 with some deps, apache-2.2 and possibly php-5.6. They're possibly ready to push as-is, but I want to make sure they actually work for some task before adding them. > > By container, what do you have in mind: > guix time-machine --channels=file.scm \ > > -- environment --container > or > -- pack -f > or > -- system *-image > > ? I think we're looking at 'guix system container' so it can be a "standard" guix service using them (as much as custom guix services are standard). > > 1: > https://gitlab.inria.fr/guix-hpc/guix-past/-/commit/f9fe4d8ac2706834fcff477db8f5421de537d78e > > > > 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. > > I agree that Guix does not have (yet!) good management of large data > set. The /gnu/store is not designed for that, if I have correctly > understood. Even we have already discussed Content-Addressable Storage > (CAS) on gwl-de...@gnu.org, AFAIR, we have not ended up with a good > plan. Well, it will not be fixed on Friday. :-) > > But for sure, it is something to keep in mind. > > > So, see you on Friday. :-) > > Cheers, > simon > -- 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: Frequent locales problems for new users
On 2020-03-17, Leo Famulari wrote: > Warning! Locales! New users seem to have trouble with Guix locales every > day. > > I think we can improve the situation. > > First, we can deprecate the glibc-utf8-locales package and not mention > it in the manual section Application Setup. I've seen users think they > had to install it in order to get UTF-8 support. Everyone should be > using glibc-locales. Eventually we can rename it to > 'glibc-locales-for-tests', and hide the package too. > > Second, we need to make sure that guix-install.sh is setting up > GUIX_LOCPATH correctly. I see that the binary tarball's store includes > glibc-utf8-locales, so it should be possible for things to "just work", > ignoring that it's the wrong locales package. Does anyone know any > particular issues with the installer that would cause trouble? I neglecteed to chime in way back when, but in irc the other day issues around locales came up and I wondered ... Any compelling reason not to put each locale into it's own package and/or output? You could have meta-packages which pull in specific sets "glibc-locales-es" which pull in all spanish locales, or "glibc-locales-all" or "glibc-locales-all-utf8" which pulls in everything. Or some other semi-logical splitting. That way users could install exactly the locales they want. It could be selected from the installer, and install only the specific locales they want, or sets of locales they want, etc. live well, vagrant signature.asc Description: PGP signature
Installing packages auto-container'ed
Would it be possible to make launching applications in Guix with minimum
permissions even easier? Here's just a sketch of an idea.
Borrowing from the new containerizing an application example in the
manual...
In my manifest.scm, what if instead of listing the browser package
eolie, I listed the following:
(define containerized-eolie
(wrap-containerized eolie
#:network? #t
;; Not sure if this line would be needed.
#:other-packages (list coreutils nss-certs dbus)
#:expose '("/etc/machine-id")
#:share '(("/home/cwebber/tmp/shared-with-browser"
. "/home/cwebber/shared"))
#:share-env '("DISPLAY")))
;; now here's my list of packages
(list emacs
containerized-eolie
...)
The idea here is that containerized-eolie actually generates a new
package that "wraps" every binary that would be installed, as well as
all common launchers, to use a script that actually launches them in a
container with the above restrictions.
I'm not sure how feasible or easy this is, but it seems like a good
idea.
If the process of containerizing something tricky like icecat is fairly
common, we could abstract that into a procedure, like
(make-containerized-icecat ...) or something.
Thoughts?
- Chris
Data Services feedback
Hi Chris, I have remarked that, from this webpage: https://data.guix.gnu.org/repository/1/branch/master/package/git/output-history the JSON button is broken, i.e., https://data.guix.gnu.org/repository/1/branch/master/package/git/output-history.json returns an error. BTW, I am currently interested by finding all the (old) versions for one specific package. Well, I fetch the JSON file then find my way. However, it does not contain all -- I think you already mentioned that, start in 2019. And it would like to have something that returns the commit id. Do you plan to add more back history? Then, if I read correctly, the function that returns all the versions is 'package-versions-for-branch' defined in model/package.scm. Well, it is in fact a SQL query. :-) The question is how do you generate the table(s)? Did you started at one point in time and then append since then? Well, I would like to have something which could be run locally even if it is *really* expensive, and so substitutable by the Data Service. Do you think it is doable? Cheers, simon
Securing updates
Hello Guix! Here’s a post pushed earlier today that explains the whole channel authentication story that’s been going on for a few months: https://guix.gnu.org/blog/2020/securing-updates/ Feedback welcome! Ludo’.
Re: Installing packages auto-container'ed
Hi Chris!
Christopher Lemmer Webber skribis:
> Would it be possible to make launching applications in Guix with minimum
> permissions even easier? Here's just a sketch of an idea.
>
> Borrowing from the new containerizing an application example in the
> manual...
>
> In my manifest.scm, what if instead of listing the browser package
> eolie, I listed the following:
>
> (define containerized-eolie
> (wrap-containerized eolie
> #:network? #t
> ;; Not sure if this line would be needed.
> #:other-packages (list coreutils nss-certs dbus)
> #:expose '("/etc/machine-id")
> #:share '(("/home/cwebber/tmp/shared-with-browser"
>. "/home/cwebber/shared"))
> #:share-env '("DISPLAY")))
>
> ;; now here's my list of packages
> (list emacs
> containerized-eolie
> ...)
>
> The idea here is that containerized-eolie actually generates a new
> package that "wraps" every binary that would be installed, as well as
> all common launchers, to use a script that actually launches them in a
> container with the above restrictions.
Definitely, it’s a great idea!
The ‘wrap-containerized’ procedure above wouldn’t be hard to write
((guix scripts pack) has something similar). It could use a trick as in
to
automatically determine some of the default file system mappings.
The next step I think would be to make a package transformation option
for that, so one could say:
guix install eolie --contained=eolie
or similar.
Ludo’.
