Re: Building Docker images of GuixSD
Hi, Christopher Baines writes: > Awesome stuff Chris, I've tried this myself, on a Debian machine with > Docker installed. Great! It's heartening to know that I'm not the only one tinkering with this. :-) > I changed the %base-file-systems in the very-bare-bones system with > %container-file-systems, and then things started working. I see. I'll have to try this, too. > I tried without privileged mode, and got a error related to the firmware > service. This isn't included when you build call > operating-system-derivation with the #:container? #t argument, and sure > enough I was able to get the system up without the Docker --privileged > flag. I think Ludo mentioned this in his reply. Excellent! I'll have to do that, too. > Unfortunately, while I could get a shell using "docker exec ...", I had > to start the guix-daemon manually as the shepherd service didn't seem to > work, at least initially. Also, when I had started it, I tried > installing a package, and there was some promising output to start off > with, but then it failed with: > > guix package: error: build failed: cloning builder process: Operation > not permitted Huh. I'll look into this. > Anyway, this is all pretty great! Awesome work getting this far. I'm > very excited to see what services will run this way, as Docker could > provide, albeit with some overhead, a layer of interoperability between > software that can handle Docker containers, and Guix. I agree! Thank you for taking the time to test this out. It's extremely helpful to get a second pair of eyes on it. -- Chris signature.asc Description: PGP signature
meetup in Boston?
Hi Guix, I’m going to visit Boston, MA for a conference on the 15th of May 2018. Would some of you be interested to meet my colleague and myself on the 14th for lunch or dinner? -- Ricardo
GNU Guix & GuixSD 0.14.0 released
We are pleased to announce the release of GNU Guix & GuixSD 0.14.0, representing 5,192 commits by 88 people over 6 months. • About GNU Guix is a transactional package manager for the GNU system. The Guix System Distribution, GuixSD, is an advanced distribution of the GNU system. In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, and per-user profiles. GuixSD offers a declarative approach to operating system configuration management and is highly hackable. Guix uses low-level mechanisms from the Nix package manager, except that packages are defined as native Guile modules, using extensions to the Scheme language. GuixSD uses the Linux-Libre kernel and the GNU Shepherd init system. At this stage it can be used on an i686 or x86_64 machine. It is also possible to use Guix on top of an already installed GNU/Linux system, including on armv7, aarch64, and mips64el. https://www.gnu.org/software/guix/ • Download Here are the compressed sources and a GPG detached signature[*]: https://alpha.gnu.org/gnu/guix/guix-0.14.0.tar.gz https://alpha.gnu.org/gnu/guix/guix-0.14.0.tar.gz.sig Here are the bootable USB installation images and their signatures[*]: https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.i686-linux.iso.xz https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.i686-linux.iso.xz.sig https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.x86_64-linux.iso.xz https://alpha.gnu.org/gnu/guix/guixsd-install-0.14.0.x86_64-linux.iso.xz.sig Here is the QCOW2 virtual machine (VM) image and its signature: https://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.14.0.x86_64-linux.xz https://alpha.gnu.org/gnu/guix/guixsd-vm-image-0.14.0.x86_64-linux.xz.sig Here are the binary tarballs and their signatures[*]: https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.i686-linux.tar.xz https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.i686-linux.tar.xz.sig https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.x86_64-linux.tar.xz https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.x86_64-linux.tar.xz.sig https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.armhf-linux.tar.xz https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.armhf-linux.tar.xz.sig https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.aarch64-linux.tar.xz https://alpha.gnu.org/gnu/guix/guix-binary-0.14.0.aarch64-linux.tar.xz.sig Use a mirror for higher download bandwidth: http://www.gnu.org/order/ftp.html Here are the SHA1 checksums: 1bc53c49d88600d63a1f195707a6f2cb0df83123 guix-0.14.0.tar.gz 132c890a81f56ad4d8a896a052c6ae1f38b356bd guix-binary-0.14.0.aarch64-linux.tar.xz 73ad2c00e17cb22cf81eae24a4a6480ea63fd0cd guix-binary-0.14.0.armhf-linux.tar.xz cddd2bf2066533426c5b20539afb8f6d8b53ec5b guix-binary-0.14.0.i686-linux.tar.xz 7779f0d6075b4c75900dc813531f87272d4121c9 guix-binary-0.14.0.x86_64-linux.tar.xz ff884c8cdf6ab9a89e66a968562247dfc5512d80 guixsd-install-0.14.0.i686-linux.iso.xz c75ba784b90f2f8e63d7db43bbce8c5dba4a7939 guixsd-install-0.14.0.x86_64-linux.iso.xz 72f66ca9217877fe5fcc5a7e4f29b10a648c2a58 guixsd-vm-image-0.14.0.x86_64-linux.xz [*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify guix-0.14.0.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver pool.sks-keyservers.net \ --recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 and rerun the 'gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.69 Automake 1.15.1 Makeinfo 6.5 Help2man 1.47.4 To install the Guix System Distribution, please see “System Installation” in the manual. To install Guix on a running system, see “Installation” in the manual. • Changes since version 0.13.0 (excerpt from the NEWS file) ** Package management *** ‘guix package’ displays how much will be downloaded *** ‘guix package’ warns about insufficient disk space *** ‘guix package’ now reports package collisions early on *** ‘guix package --search’ sorts results by relevance *** ‘guix pull’ now fetches code directly over Git using Guile-Git *** Substitutes can be downloaded from servers equivalent to the authorized ones *** New ‘guix-daemon’ options: ‘--listen’, ‘--timeout’, ‘--max-silent-time’ *** New ‘guix weather’ command *** ‘guix publish --cache’ now also caches uncompressed items *** ‘guix publish’ no longer removes live items from its cache *** ‘guix challenge’ now displays an overall summary *** ‘guix refresh’ no longer uses FTP for GNU and GNOME packages *** ‘guix refresh’ has a new ‘-m’ or ‘--manifest’ option *** New ‘ref
anyone going to 34c3 / Chaos Congress?
Hi, I'm going to be in Leipzig for the 34c3 at the end of this month. Is there anyone else of us who will be there and would like to meetup? As far as I know the Fahrplan is not ready yet, so I don't even know which talks I'll attend in addition to our GNUnet eV meeting. -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys WWW: https://n0.is signature.asc Description: PGP signature
Re: anyone going to 34c3 / Chaos Congress?
Hi, I will be there too :) Count me in for a small meetup (maybe some hours or so). Jonathan On 07/12/17 15:03, ng0 wrote: > Hi, > > I'm going to be in Leipzig for the 34c3 at the end of this month. > > Is there anyone else of us who will be there and would like to > meetup? > As far as I know the Fahrplan is not ready yet, so I don't even > know which talks I'll attend in addition to our GNUnet eV meeting. >
Re: anyone going to 34c3 / Chaos Congress?
Am 07.12.2017 um 15:03 schrieb ng0: > GNUnet eV meeting We'll meed there. And chances are high to find me at the Digitalcourage booth. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: GNU Guix & GuixSD 0.14.0 released
On 07/12/2017 13:45, Ludovic Courtès wrote: We are pleased to announce the release of GNU Guix & GuixSD 0.14.0, representing 5,192 commits by 88 people over 6 months. Congratulations and thanks to all contributors! The more I use Guix, the more I appreciate its qualities, but also the enormous amount of work that went into it. Konrad.
Re: java: switch to icedtea-8 as default JDK
Hello! The gtk+ patch is now in core-updates. 2017-12-05 8:07 GMT+01:00 Gábor Boskovits : > FAIL: abicheck.sh > PASS: pltcheck.sh > > > Testsuite summary for gtk+ 2.24.31 > > > # TOTAL: 3 > # PASS: 2 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 1 > # XPASS: 0 > # ERROR: 0 > > > See gtk/test-suite.log > Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B > > > > This is what I have now. > > FAIL: abicheck.sh > = > > --- expected-abi2017-12-05 05:45:34.47200 + > +++ actual-abi 2017-12-05 05:45:34.50800 + > @@ -1,3 +1,4 @@ > +g_cclosure_marshal_BOOLEAN__BOXED_BOXED > gtk_about_dialog_get_artists > gtk_about_dialog_get_authors > gtk_about_dialog_get_comments > FAIL abicheck.sh (exit status: 1 > > This is the log. > > > > 2017-12-04 20:15 GMT+01:00 Leo Famulari : > >> On Mon, Dec 04, 2017 at 04:44:00PM +0100, Gábor Boskovits wrote: >> > Now that this problem around glibc is resolved, I think I will do some >> > history rewrite, so that these reverts, reverting the revert does >> not >> > show up. >> > I 'm also willing to rename the branch to have wip in the name, as this >> > seems to be standard for longer runnig parts. WDYT? >> >> In general, we don't rewrite history of any public branches on our >> Savannah instance, except for branches whose name starts with "wip-". >> That, is "work in progress". >> >> But of course we can all follow our own rules on our own Git servers :) >> > >
Re: Problems with setting up prosody with IPv6 and certbot
Thanks a bunch for your answers! Am 07.12.2017 um 01:32 schrieb Clément Lassieur: > Could you please display the output of "ip addr"? > root@tomato ~# ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 26:0d:0d:c3:c5:a4 brd ff:ff:ff:ff:ff:ff inet 185.183.157.103/22 brd 185.183.159.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a03:4000:1d:1cb::/128 scope global valid_lft forever preferred_lft forever inet6 fe80::240d:dff:fec3:c5a4/64 scope link valid_lft forever preferred_lft forever This is after I did the workaround of course. I don't want to the server reboot right now. > 3. your server behaves like a router because IP forwarding is enabled >(most likely). > > See https://tools.ietf.org/html/rfc4862, > https://askubuntu.com/questions/114971/ipv6-auto-configuration-not-working > and > https://serverfault.com/questions/380810/ipv6-stateless-autoconfiguration-not-working-on-centos-6-2. > I haven't looked through all of it, but that is probably the case. What would be the guixsd config to hard-set my ipv6 address for eth0?
Re: ISO image available for testing!
Ludovic Courtès writes: > Hi Chris, > > Christopher Baines skribis: > >> I've attempted to use this to install GuixSD on a Bytemark >> VM. Unfortunately I haven't succeeded yet. I managed to get as far as >> running guix system init, but when I did, it started downloading the >> bootstrap binaries, and then building binutils. >> >> When I run guix system build, or guix build with the --dry-run options, >> it says that it will download, rather than building, but it doesn't. > > It turned out to be issues related to grafts and to what Hydra builds, > fixed with these commits: > > 3e442f85f * gnu: ghostscript-with-cups: Turn into a public variable. > 91c9b5d01 * packages: 'package-grafts' trims native inputs. > ff0e0041f * packages: 'fold-bag-dependencies' honors nativeness in recursive > calls. > f00b85ff8 * gnu: commencement: Do not graft early bootstrap packages. > > The Binutils issue is fixed by f00b85ff8. > > Commit 91c9b5d01 notably fixes the “expat issue”: coreutils had expat in > its dependency graph, via gettext. Thus, the expat graft was picked up > as a candidate graft. However, expat itself was subject to the glibc > graft, and since there was no substitute for this particular expat, we’d > have to build it first, just to throw it away later on because coreutils > does not refer to it at run time. > > Long story short: we were flagging native inputs as potential sources of > grafts even though, by definition, native inputs are not referred to at > run time. > > The last commit ensures that Hydra builds the replacement for > ‘ghostscript-with-cups’. > > What’s tricky is that one doesn’t notice these issues unless starting > from a fresh store. > > I’ve uploaded an updated ISO image, which I used to test substitute > availability and grafts. If you have time in the coming hours, feedback > welcome: Thanks for fixing this Ludo, and congratulations on the release. I'm glad to say that I've now managed to install GuixSD using the 0.14.0 x86_64 ISO, however I did encounter some difficulties. I tried a few times with both the ISO you replied with here, and the released ISO, but each time the virtual machine I was installing on to appeared to restart while guix system init was running. It's difficult to get more information, but the last messages I got out of guix system init relate to grafting and collisions. This evening when I tried again I passed --no-grafts to guix system init, and this time it successfully finished the installation. Interestingly, this is also what is actually tested by the iso-image-installer system test, as it sets the GUIX_BUILD_OPTIONS environment variable. This isn't conclusive, but I'd be very interested to hear from anyone that has had similar issues, or successes in using the ISO installer, both with and without the --no-grafts option. Thanks again, Chris signature.asc Description: PGP signature
Re: the importance of rust-build-system [Fwd: [tor-dev] Tor in a safer language: Network team update from Amsterdam]
Hi, my apologies. Occasionally I have a tendency for very late replies in some threads, as you might have noticed. Danny Milosavljevic transcribed 1.9K bytes: > Hi ng0, > > On Sat, 1 Apr 2017 07:58:41 + > ng0 wrote: > > > Danny, could you list what's left for completion? Is it just circular > > dependencies? > > Very little is missing: > - Rustc and cargo should be disentangled. Right now they have to be updated > in lockstep. That's not really a problem for producing functional rust crate binaries. I consider this optional. Or am I wrong? > - Rust has a new optional maker (instead of makefiles) called rustbuild; > for some reason I didn't get it to work. Future versions will drop > the makefiles, so we have to get it to work eventually. Can you share the issues you had with this? How far did you come? > - Eventually we could try to bootstrap a Rust compiler from the > original ocaml sources. I'm trying to do that now but it's still > broken. It would be fine to make it memory-safe by just not > freeing anything ever - since it would only be used to compile the > Rust compiler. Wouldn't it be easier to help the mrustc project, which is aimed at just that (bootstrapping rustc) in the long run? Is it even possible at this point to bootstrap rustc using OCaml without wasting too much resources? They've come a long way and many releases since they've gone selfhosted. Can you share your findings and work on this? > - Earlier we had an heuristic in that if there's a Cargo.lock file present we > assume > that it's an application, and if there isn't one we assume that it's a > library. > Not sure how safe that heuristic is. What's the official way to find out > what it is? > - There's a design limitation in that our rust build system doesn't API > support > version ranges but cargo does. If multiple libraries depend on the same > library > with differing API version ranges, cargo uses an version range intersection > algorithm in order to find out which implementation version to use. > We don't do that - although we do use cargo, so it will fail in that case (and > not do something invalid silently). Can you explain this a bit more in detail? You seem to have put more time to work/think about these issues than I have done so far. I need to understand most of the issues, so that I can communicate them to people who'd work on them. At least to get them started on the issues. > Note that Rust itself makes a distinction between stable features that > are guaranteed to stay and stay > the same in the future and unstable features that don't. > Many Rust crates use unstable features, among them very basic crates. > That makes us unable to use them, and rightfully so. You mean fundamental basic crates required by many applications? Do you have some insight into the implications of this? I would provide a rustc-nightly outside of Guix master/official, that's not an issue for me. > > Other than that I've got a big number of (unpolished) Rust packages that do > work. Can you share these package definitions somewhere? I'd like to help out and see how many intersections (duplicates) we both have in our unfinished rust crates work. > > days. I hope you don't mind if I list you as a go-to person for getting > > involved in upstream (Guix) to fix up the rust-build-system. > > Okay. -- GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://c.n0.is/ng0_pubkeys/tree/keys WWW: https://n0.is signature.asc Description: PGP signature
Re: Seeding the Linux RNG at first boot
Leo Famulari skribis: > On Wed, Dec 06, 2017 at 12:11:36AM +0100, Marius Bakke wrote: >> FWIW if you control the hypervisor, you can send something along the >> lines of: >> >> qemu -device virtio-rng-pci,bus=pci.0,addr=0x1e,max-bytes=1024,period=1000 >> >> to feed the guest with entropy from the host through virtio, up to 1kB/s. > > Exactly, this is along the lines of what I'm thinking for `guix system > vm`. > > On the guest side, we would extend urandom-seed-service to also draw on > /dev/hwrng, which is where virtio-rng-pci makes the data from the host > available. Maybe ‘virtualized-operating-system’ in (gnu system vm) could automatically customize ‘rngd-service-type’ (or add it)? > Currently there is the rngd-service-type, but that is doing something > slightly different. Using /dev/hwrng to seed urandom could be done > whenever it's enabled in the kernel. > > I have an idea for another improvement: to add an argument like > "--entropy-seed=" to `guix system` that could place the value in > '/var/lib/random-seed', where it would be used on first boot. We could do that, though I very much prefer the idea of a “backdoor” à la virtio-rng-pci, because it allows to stick to bit-reproducible images (well, they’re not bit-reproducible yet I suppose, but let’s not add to it.) WDYT? Ludo’.
Re: ISO image available for testing!
Hello Chris, Christopher Baines skribis: > Thanks for fixing this Ludo, and congratulations on the release. I'm > glad to say that I've now managed to install GuixSD using the 0.14.0 > x86_64 ISO, however I did encounter some difficulties. > > I tried a few times with both the ISO you replied with here, and the > released ISO, but each time the virtual machine I was installing on to > appeared to restart while guix system init was running. It's difficult > to get more information, but the last messages I got out of guix system > init relate to grafting and collisions. I wonder how the VM can restart. Could it be an out-of-memory condition? Though even that should not lead to a reboot. Could you see if you can get more details from the VM? Thanks, Ludo’.
Re: Installing some packages results in "incomplete deployment"
Hi Ludo,
> Perhaps we could offer an option for packages to display hints at
> installation time. Like
>
> (package
> (name "xscreensaver")
> ;; …
> (properties
> `((installation-notice
> . ,(G_ "Please see the documentation of
> @code{screen-locker-service-type} in the manual on how to use this
> screen saver.")
>
> Or maybe something higher level, like:
>
> '((use-with-service . screen-locker-service-type))
>
> Thoughts?
I like the higher-level approach. We can use this in a future system
configuration interface (e.g. to display available service extensions)
as well as on the command line by displaying hints like the above.
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
Re: Seeding the Linux RNG at first boot
On Thu, Dec 07, 2017 at 10:07:38PM +0100, Ludovic Courtès wrote: > Leo Famulari skribis: > > On the guest side, we would extend urandom-seed-service to also draw on > > /dev/hwrng, which is where virtio-rng-pci makes the data from the host > > available. > > Maybe ‘virtualized-operating-system’ in (gnu system vm) could > automatically customize ‘rngd-service-type’ (or add it)? Yes, we could do that, although I don't think it's necessary to run a daemon continuously. It is enough to seed the RNG once. At the same time we handle the random seed, we could also try reading from /dev/hwrng and, if the read is successful, copy some bytes into /dev/urandom. We'd have to try reading and handle failure since we always create /dev/hwrng regardless of whether the Linux kernel module is loaded or not. > > I have an idea for another improvement: to add an argument like > > "--entropy-seed=" to `guix system` that could place the value in > > '/var/lib/random-seed', where it would be used on first boot. > > We could do that, though I very much prefer the idea of a “backdoor” à > la virtio-rng-pci, because it allows to stick to bit-reproducible images > (well, they’re not bit-reproducible yet I suppose, but let’s not add to > it.) I think it would be most useful for disk images, for which there is no host. If one always passes the same value to --entropy-seed, it will not negatively affect the reproducibility of the image ;) This would not be something we do for the official release image, but merely an optional tool. signature.asc Description: PGP signature
Re: Why do we not cross-compile bootstrap binaries?
l...@gnu.org (Ludovic Courtès) writes: > Hello, > > In practice, apart from x86_64-linux which was bootstrapped on NixOS, we > always cross-compile to bootstrap new architectures: > > https://www.gnu.org/software/guix/manual/html_node/Porting.html > > That was the case for all the non-Intel arches and for GNU/Hurd. > > Is that what you meant? My question was more about: why do we check in bootstrap binaries for different architectures, instead of checking in bootstrap binaries for one "base" architecture and then generating the bootstrap binaries for other architectures from that "base" architecture. I think Efraim's answer confirmed my understanding, which is that basically we want to avoid treating any single platform as special. Thank you for the reply! -- Chris signature.asc Description: PGP signature
Is it necessary to run "make" before "make check"?
Hi, Is it necessary to run "make" before "make check", or is it good enough to just run "make check" and rely on Make to build whatever needs to be built to run "make check"? -- Chris signature.asc Description: PGP signature
Re: 01/01: gnu: bedtools: Update to 2.27.0.
Hi, rek...@elephly.net (Ricardo Wurmus) writes: > rekado pushed a commit to branch master > in repository guix. > > commit 0d9824cc127f045d32c22d0c75df46d97cb61624 > Author: Ricardo Wurmus > Date: Wed Dec 6 19:12:16 2017 +0100 > > gnu: bedtools: Update to 2.27.0. > > * gnu/packages/bioinformatics.scm (bedtools): Update to 2.27.0. > [arguments]: Remove custom "install" phase; specify prefix. The standard 'install' phase seems to have failed on Hydra: https://hydra.gnu.org/build/2389354 --8<---cut here---start->8--- starting phase `install' make: *** No rule to make target 'install'. Stop. phase `install' failed after 0.0 seconds builder for `/gnu/store/fq59s5x7kxn8sq9wl62334bacpjgj1b3-bedtools-2.18.0.drv' failed with exit code 1 @ build-failed /gnu/store/fq59s5x7kxn8sq9wl62334bacpjgj1b3-bedtools-2.18.0.drv - 1 builder for `/gnu/store/fq59s5x7kxn8sq9wl62334bacpjgj1b3-bedtools-2.18.0.drv' failed with exit code 1 --8<---cut here---end--->8--- Any idea what happened here? Mark
Re: java: switch to icedtea-8 as default JDK
sra-tools2.8.2-1 builds with no problem. 2017-12-07 18:50 GMT+01:00 Gábor Boskovits : > Hello! > > The gtk+ patch is now in core-updates. > > > 2017-12-05 8:07 GMT+01:00 Gábor Boskovits : > >> FAIL: abicheck.sh >> PASS: pltcheck.sh >> >> >> Testsuite summary for gtk+ 2.24.31 >> >> >> # TOTAL: 3 >> # PASS: 2 >> # SKIP: 0 >> # XFAIL: 0 >> # FAIL: 1 >> # XPASS: 0 >> # ERROR: 0 >> >> >> See gtk/test-suite.log >> Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B >> >> >> >> This is what I have now. >> >> FAIL: abicheck.sh >> = >> >> --- expected-abi2017-12-05 05:45:34.47200 + >> +++ actual-abi 2017-12-05 05:45:34.50800 + >> @@ -1,3 +1,4 @@ >> +g_cclosure_marshal_BOOLEAN__BOXED_BOXED >> gtk_about_dialog_get_artists >> gtk_about_dialog_get_authors >> gtk_about_dialog_get_comments >> FAIL abicheck.sh (exit status: 1 >> >> This is the log. >> >> >> >> 2017-12-04 20:15 GMT+01:00 Leo Famulari : >> >>> On Mon, Dec 04, 2017 at 04:44:00PM +0100, Gábor Boskovits wrote: >>> > Now that this problem around glibc is resolved, I think I will do some >>> > history rewrite, so that these reverts, reverting the revert does >>> not >>> > show up. >>> > I 'm also willing to rename the branch to have wip in the name, as this >>> > seems to be standard for longer runnig parts. WDYT? >>> >>> In general, we don't rewrite history of any public branches on our >>> Savannah instance, except for branches whose name starts with "wip-". >>> That, is "work in progress". >>> >>> But of course we can all follow our own rules on our own Git servers :) >>> >> >> >
Re: java: switch to icedtea-8 as default JDK
Gábor Boskovits writes: > sra-tools2.8.2-1 builds with no problem. Now that things are hopefully fixed up a bit more in core-updates I am trying again to build the "covering" of icedtea to see what still needs to be fixed. I'll let you know how that goes. -- Chris signature.asc Description: PGP signature
Re: java: switch to icedtea-8 as default JDK
Ok, hopefully that will work out. However there was a hint yesterday, that newest core-updates is broken again after a recent merge... It might worth to have a look around to see if it's woth to do on an older revision... I will wait for your results for now... Maybe later this weekend I can start up a few vm-s with guixsd, and have those involved in rebuilding if needed... 2017-12-08 7:55 GMT+01:00 Chris Marusich : > Gábor Boskovits writes: > > > sra-tools2.8.2-1 builds with no problem. > > Now that things are hopefully fixed up a bit more in core-updates I am > trying again to build the "covering" of icedtea to see what still needs > to be fixed. I'll let you know how that goes. > > -- > Chris >
Iso image size
I don't know what we are currently doing to get the installer iso image sized down, but I caught some discussion yesterday on irc, that the image is actually very well compressible, and checking the sizes it really is. Might that be possible to do something like compressing the root filesystem image on the iso image, and decompress it from initrd before mounting? Or do we already do that? It might worth consideration, if that makes the image fit onto a CD.
