Tiny Guix (and containers)
I have been playing around with containers to create something for a book: https://gitlab.com/pjotrp/guix-notes/blob/master/CONTAINERS.org these are (Docker) images that can be run by anyone - which is great! Only (minor) issue is the containers are 1.4GB in size. These are the biggies in this image: wrk@lario /gnu/store [env]# du -sh *|grep -e "[[:digit:]][[:digit:]]M" 36M 0s5manjvfa0gmsv2r71rchky7ab70g1d-icu4c-58.2 36M 15plffwjdv8ii6vbsnvrvy6irbfsz4x4-gfortran-5.4.0-lib 22M 3x53yv4v144c9xp02rs64z7j597kkqax-gcc-5.4.0-lib 16M 42d5rjrdkln6nwvzwdc8dyd4w6iy3n5j-coreutils-8.27 13M 5c9qygcdircjg1dkaw6rnw59c6v4akca-python-cython-0.27 90M 5sv5zy2kgg6iaqyv8zw49w4243j0xkd0-gcc-5.4.0 19M 5vjvxngriskrsrg5lv162i927crciy9x-bioperl-minimal-1.7.0 40M 9c5ip78j3cr6ywx9vjicn545pmq24802-book-evolutionary-genomics-0.2.1-53a7aef 92M 9shcsn90rpzacysklhfiidc9qkcn3f1l-ruby-2.4.2 16M azbfh3i72lbaqvhgg5m7p6ymmqq0ii6q-glib-2.52.3 59M bzn4wyrbdmfc1bd7lq05db5psfl5f8x8-perl-5.26.0 28M d4hwf3w2ca9lmf7nrgk2jsr9mhxcmb40-vim-8.0.1207 15M d5khpb89l7w65qvwry6ikx57sknnnl9p-python-biopython-1.70 46M d8gkn84yqacjr80pzicz1ka3y2s1f2x0-guile-2.2.2 63M f7j1vq0ncc1znrn0cyy07gps3r0h1iaa-openblas-0.2.19 10M fqxyqlpkbm4fc9x91yyqs7zbhm495b2s-ruby-ffi-1.9.18 65M ks27x0mf95gir0cdgb9h573xbava6v1k-python-3.5.3 11M kwzs8k97qy7avxxldnzavlii9zphh3d6-libxml2-2.9.4 13M l95wcgysigi5mkmzgrr9k0irrszzd2m8-profile 41M n6nvxlk2j8ysffjh3jphn1k5silnakh6-glibc-2.25 34M nnykzgwfy8mwh2gmxm715sjxykg8qjwn-binutils-2.28 11M nyd19c9ccykji2lg9jhxfzv6zd67ar55-lapack-3.7.1 423Mp4h18j5dnn7sgajni9pfas0jm4dgdnv6-emboss-6.5.7 22M pc96dryzfghnih9lqrjfa24n205ds7ir-python-numpy-1.12.0 31M sq8yhawx0x3pyvvqrxx8hmw4rnp4mz03-bioruby-1.5.1 45M y8g28w9icanll84llw6xvdyjrw0qvnp9-r-minimal-3.4.2 15M zb662xs7i06l079n2wr5mn56862v6wfm-r-biostrings-2.44.2 14M zbywrj6klakskj0sppq56viqh9l56jl0-util-linux-2.30.1 It is obvious emboss could be trimmed down ;). But I think none of these packages when trimmed down ought to be larger than 15M. Not even gcc. Separately I have been using Travis-Ci for (integration) testing of a C++ project (soon to adding D) which we are working on https://travis-ci.org/genetics-statistics/GEMMA Now it takes forever to set up the image - a tiny Guix Docker container would be great here and probably get attention (most Travis testing time goes up in downloading stuff!). To users it makes a huge difference if they have to wait 10 minutes or 10 seconds. Then there is my idea of creating (mail) servers using Guix. It would be great to go tiny there too. And in the embedded world they may consider Guix when it is tiny. My question is, who else would be interested and how to best to go about this in Guix. It makes no sense to write separate packages (I think) because the maintenance effort would go up hugely. But tiny is also not exactly a subset of existing packages. I mean guix package -i glibc:tiny could be a target. Splitting packages in bioruby:doc, bioruby:dev and bioruby:lib would serve that purpose too. We know Debian struggled with this and we also know that OpenWRT/LEDE went the NIH way. What lessons are there? But, really, I think when talking embedded systems and containers we all want tiny. Even HPC can benefit. Tiny containers may be an attractive proposition. Pj.
Re: Tiny Guix (and containers)
Another route is to create a container using just the essential dependencies, like I did here: https://gitlab.com/pjotrp/guix-relocatable-binary-packages/blob/master/README.org Binary with dependencies distribution down to 18Mb. Of course locales won't work ;) And yes, I am still using relocatable packages to distribute specific software for HPC... It is rather nice. Pj. --
Expat in GuixSD, please update
Hi GuixSD team, from looking at [1] and [2] my impression is that GuixSD is still at version 2.2.2 with Expat, while there is version 2.2.4 with bugfixes upstream. Is there anything blocking an update on your side that needs fixing upstream? Best Sebastian [1] https://repology.org/metapackage/expat/versions [2] https://www.gnu.org/software/guix/packages/e.html
Re: Expat in GuixSD, please update
Hello, maybe you can try to submit a patch for review... That ought to be fairly easy -- Vincent Legoll
Re: Expat in GuixSD, please update
Sorry, no time. On 25.10.2017 16:05, Vincent Legoll wrote: > Hello, > > maybe you can try to submit a patch for review... > > That ought to be fairly easy >
Re: Guix on macOS
Another thing that just came to my mind is the hard-coding of file name separators instead of using a combination of checkers to see if the 'file-name-separator-string matches the *target* system (as is briefly told in `info guile', the GNU Guile Scheme infopage). Although I don't know if macOS uses "\" or "/". If macOS does use "\", besides having to make all the attempts to change paths lookup for that separator evaluation, thus potentially causing extra work, this could require a major rewrite of package definitions and rebuilds. Besides, I agree that things should be built entirely with free/libre software. And I don't know if macOS allows us to do that (thanks to, along other things, the non-existance of community-oriented copyleft enforcement by the copyright holders of the XNU/BSD kernel projects). Chris Marusich writes: > Hi Guix, > > I want to get Guix working on macOS. I recently had a need to do this, > and I was sad to find that although Nix works on macOS, Guix isn't quite > there yet. The manual makes it sound like this should be fairly > straightforward, and I intend to give it a shot [1]. But before I > begin, I wanted to know: has anyone done this already? Is there > interest? I've checked the email lists, and I didn't find much > discussion about this. > > I know a lot of developers who use macOS as their primary workstation, > and most of them use a combination of Homebrew [2] and manual > installation for package management. It'd be great if Guix were easy to > use on macOS! Not only is it the best package manager (of course! :-)), > but it would be a great way to encourage the use and growth of free > software among this group of people. > > Additionally, if you're interested in helping out, please let me know. > To facilitate the work, I'm temporarily renting a Mac from MacStadium > [3] (it's just a weak little Mac Mini [4] for now), and it would be > trivial to give interested parties administrative access (via VNC and > SSH) to facilitate the work. > > Footnotes: > [1] info '(guix) Porting' > > [2] https://brew.sh/ > > [3] https://www.macstadium.com/ > > [4] https://www.macstadium.com/mac-mini/ -- - https://libreplanet.org/wiki/User:Adfeno - Palestrante e consultor sobre /software/ livre (não confundir com gratis). - "WhatsApp"? Ele não é livre. Por favor, veja formas de se comunicar instantaneamente comigo no endereço abaixo. - Contato: https://libreplanet.org/wiki/User:Adfeno#vCard - Arquivos comuns aceitos (apenas sem DRM): Corel Draw, Microsoft Office, MP3, MP4, WMA, WMV. - Arquivos comuns aceitos e enviados: CSV, GNU Dia, GNU Emacs Org, GNU GIMP, Inkscape SVG, JPG, LibreOffice (padrão ODF), OGG, OPUS, PDF (apenas sem DRM), PNG, TXT, WEBM.
Re: Guix on macOS
I hope they get more used to referring to GNU operating system, or GNU/Linux operating system too. I find it puzzling that most people call it Linux, the kernel (Linux) alone isn't an operating system, let alone usable without one. ;) Konrad Hinsen writes: > There are those nasty real-world constraints, indeed. I'd be happy to > run 100% free software on personal hardware. But my employer restricts > the hardware I am allowed to buy and requires me to use Microsoft > Windows (no, LibreOffice won't do). That makes macOS an attractive > choice, the alternative being a Windows/Linux dual boot system. > > A "free software subsystem" inside macOS is definitely attractive for > me, because I could then run strictly the same software as my > Linux-using colleagues. With the features of Guix, it would be even > better. > > Konrad.
Re: Expat in GuixSD, please update
Sebastian, Sebastian Pipping wrote on 25/10/17 at 14:58: > from looking at [1] and [2] my impression is that GuixSD is still at > version 2.2.2 with Expat, while there is version 2.2.4 with bugfixes > upstream. Thanks for the report! I see that 2.2.3 fixed a CVE, so I hurried up a patch[0]. Kind regards, T G-R [0]: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=28996
Re: Expat in GuixSD, please update
On Wed, Oct 25, 2017 at 02:58:13PM +0200, Sebastian Pipping wrote: > Hi GuixSD team, > > > from looking at [1] and [2] my impression is that GuixSD is still at > version 2.2.2 with Expat, while there is version 2.2.4 with bugfixes > upstream. Is there anything blocking an update on your side that needs > fixing upstream? Thank you very much for reaching out, Sebastian. No, there is nothing concrete blocking the update. I've just given Tobias a "LGTM" for his 2.2.4 update patch. There is a slight cost to updating packages with many dependents in Guix [0], so we prefer not to update them between "core update" cycles unless there are security issues affecting our users. Expat 2.2.3's release notes only mentioned CVE-2017-11742, which is a Windows vulnerability and out of scope for Guix. And I didn't see security issues disclosed in the 2.2.4 release notes. But, we can treat Expat as one of those "always update" libraries if that is suggested. It's probably the right choice for any widely-used C library. [0] By treating package building as a pure function, if a lower-level package changes, all dependent packages must be rebuilt. We have a mechanism called grafting to cheat for security updates. signature.asc Description: PGP signature
Re: Expat in GuixSD, please update
Leo Famulari wrote on 25/10/17 at 19:22: > Expat 2.2.3's release notes only mentioned CVE-2017-11742, which is a > Windows vulnerability and out of scope for Guix. And I didn't see > security issues disclosed in the 2.2.4 release notes. Ah, sorry to spread misinfo. I don't have Web access at the moment and erred on the side of caution. I'll adjust the patch accordingly & push. Kind regards, T G-R signature.asc Description: OpenPGP digital signature
Re: Expat in GuixSD, please update
On Wed, Oct 25, 2017 at 07:29:28PM +0200, Tobias Geerinckx-Rice wrote: > Leo Famulari wrote on 25/10/17 at 19:22: > > Expat 2.2.3's release notes only mentioned CVE-2017-11742, which is a > > Windows vulnerability and out of scope for Guix. And I didn't see > > security issues disclosed in the 2.2.4 release notes. > > Ah, sorry to spread misinfo. I don't have Web access at the moment and > erred on the side of caution. I'll adjust the patch accordingly & push. I think we can still mention that we've fixed that bug. Somebody could still use Guix as a source of free source code even if they were developing for Windows. No big deal either way, IMO. signature.asc Description: PGP signature
POWER Support
Are there plans to support POWER 8-9 systems for the GUIX package manager and GUIXSD? I had read about TALOS and was just curious about that support being worked on. -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com 25. Oct 2017 13:36 by gnu-system-discuss-requ...@gnu.org: > Welcome to the > gnu-system-disc...@gnu.org> mailing list! > > To post to this list, send your message to: > > > gnu-system-disc...@gnu.org > > General information about the mailing list is at: > > > https://lists.gnu.org/mailman/listinfo/gnu-system-discuss > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > > > https://lists.gnu.org/mailman/options/gnu-system-discuss/oury.dustin%40tutanota.com > > > You can also make such adjustments via email by sending a message to: > > > gnu-system-discuss-requ...@gnu.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe without confirmation. It is: > > > http://releases.ubuntu.com/16.04.3/ubuntu-16.04.3-desktop-amd64.iso > > Normally, Mailman will remind you of your gnu.org mailing list > passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you.
Re: POWER Support
On Wed, Oct 25, 2017 at 03:47:19PM +0200, oury.dus...@tutanota.com wrote: > Are there plans to support POWER 8-9 systems for the GUIX package > manager and GUIXSD? I had read about TALOS and was just curious about > that support being worked on. I haven't heard of anyone working on it, but we have documentation about porting Guix to a new platform: https://www.gnu.org/software/guix/manual/html_node/Porting.html [...] > > You must know your password to change your options (including changing > > the password, itself) or to unsubscribe without confirmation. It is: > > > > > http://releases.ubuntu.com/16.04.3/ubuntu-16.04.3-desktop-amd64.iso You may want to change this password. signature.asc Description: PGP signature
Re: FOSDEM 2018 Guile devroom
On Thu, Oct 19, 2017 at 10:25:47PM +0200, Ludovic Courtès wrote: > Ricardo Wurmus skribis: > > > “Free Java” is an interesting name for a devroom track. I guess I could > > talk about freedom problems with the Java culture of never building > > software recursively from source, and introduce how we’re approaching > > this problem in Guix. > > > > The Java bootstrap could also be demonstrated in that talk. Also interesting to look into is how the bootstrapping effort works with different architectures. i686 should bootstrap fine, but has problems. Arm needs some loving to be updated from v3 or 4 to v7. Aarch64 didn't exist back then and needs to be written into the source to have an actual bootstrap. > > Indeed, sounds like we have a lot to discuss with “the Java folks.” > > > (Does anyone know how this is done in Debian? Do they actually build > > all of their Java packages from source?) > > No idea, but we should definitely get in touch with the Java team. > I haven't looked at Java specifically, but I assume they may have bootstrapped it in the past, but they use their current versions to build the next version, and so on. I do believe, however, that they do build everything in main (and contrib) from source. -- 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: FOSDEM 2018 Guile devroom
On Thu, Oct 19, 2017 at 09:34:17AM +0200, Ludovic Courtès wrote: > Hello! > > [- guile-devel] > > Thomas Danckaert skribis: > > > Just to get everybody excited: https://fosdem.org/2018/schedule > > includes (among others) devrooms for > > > > - “Package Management” > > > > - “HPC, Big Data and Data Science” > > > > - “Distributions” > > > > - “Containers” > > > > - “Config Management” > > > > -“Free Java” > > Awesome. These tracks are good opportunities to reach out to people who > otherwise wouldn’t hear about Guix(SD). Given how many people were in > the Guile/Guix devroom last year, I’m sure we could afford to have one > talk in each track. ;-) Let’s synchronize! > > Ludo’. > For the distro room I was thinking of a talk along the lines of "living the aarch64 life in an x86 world". -- 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: IcedTea is not linking correctly with libjvm.so
Roel Janssen writes: > gnu/packages/java.scm | 12 > 1 file changed, 12 insertions(+) > > diff --git a/gnu/packages/java.scm b/gnu/packages/java.scm > index 95fba20e8..81cfdc132 100644 > --- a/gnu/packages/java.scm > +++ b/gnu/packages/java.scm > @@ -1404,6 +1404,18 @@ bootstrapping purposes.") > (copy-recursively "openjdk.build/j2re-image" jre) > (copy-recursively "openjdk.build/j2sdk-image" jdk)) > #t)) > + ;; Some of the libraries in the lib/amd64 folder link to > libjvm.so. But that > + ;; shared object is located in the server/ folder, so it cannot > be found. > + ;; This phase creates a symbolic link in the lib/amd64 folder so > that the > + ;; other libraries can find it. > + ;; > + ;; See > https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00169.html > + (add-after 'install 'install-libjvm > + (lambda* (#:key inputs outputs #:allow-other-keys) > + (let* ((lib-path (string-append (assoc-ref outputs "out") > "/lib/amd64"))) > + (system* "ln" "--symbolic" > + (string-append lib-path "/server/libjvm.so") > + (string-append lib-path "/libjvm.so") Please use (symlink foo bar) instead of calling the “ln” tool. Also end the phase with #t. Other than that I think it’s fine as a workaround. Please also add a FIXME to the comment, so that we can revisit this later. Thanks! -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
