Re: VM image: can we simplify its use?
On Thu, Apr 04, 2019 at 04:56:51PM +0200, Ludovic Courtès wrote: > I had criticism about the VM image: [...] > Thoughts? Originally I added the VM image to address a specific use case at one VM hoster. I had hoped it would catch on more than it did and that the VM image would be improved to avoid these manual steps. In the meantime, people are using the VM image just to try out Guix — for example, in a local QEMU instance. It doesn't give a great impression, so let's change it. We should offer something like a "Live Guix" image for people to try the full Guix system without installing anything, and this should be more fully-featured than the current Guix VM image. Let's replace the current VM image with this "Live Guix" thing for the next release :) Should we adopt 'desktop.tmpl' for this? Eventually we should also offer a Guix system service that works like cloud-init [0] and can replace the manual work around networking, partitioning, etc. Help wanted! [0] https://cloud-init.io/ signature.asc Description: PGP signature
Re: Error building linux-libre on Overdrive 1000
Andreas, Andreas Enge wrote: I confirm after just trying to reconfigure, with commit 36dbad3858ca4229e9ec319bd4983fca7835067d. Cc-ing the bug tracker. Thanks! I wasn't expecting to hit an ‘actual’ bug. Yaay. Kind regards, T G-R signature.asc Description: PGP signature
Re: Error building linux-libre on Overdrive 1000
On Tue, Apr 09, 2019 at 04:37:09PM +0200, Tobias Geerinckx-Rice wrote: > ‘guix system init’ fails for me in the following way on the following > version: > > $ guix describe > Generation 4Apr 08 2019 23:29:08(current) > guix 2afb793 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: 2afb79392d39df05e5b285ea46dd59eafb0616d8 > > I'd attach the system configuration, but it's basically the one from > guix-maintenance/hydra/overdrive.scm. There's nothing custom about the > kernel. I confirm after just trying to reconfigure, with commit 36dbad3858ca4229e9ec319bd4983fca7835067d. Cc-ing the bug tracker. Andreas
Error building linux-libre on Overdrive 1000
Guix, ‘guix system init’ fails for me in the following way on the following version: $ guix describe Generation 4Apr 08 2019 23:29:08(current) guix 2afb793 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 2afb79392d39df05e5b285ea46dd59eafb0616d8 I'd attach the system configuration, but it's basically the one from guix-maintenance/hydra/overdrive.scm. There's nothing custom about the kernel. Kind regards, T G-R --- 8< --- In file included from /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/inc lude/stdint.h:34:0, from /gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/ lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33, In file included from /gnu/store/im7irb1qnmvwypz53dxv5i75wy94dcz5-glibc-2.28/inc lude/stdint.h:34:0, from /gnu/store/7ykq1909hf7jgkvqcxdz7r0dglnbx005-gcc-7.4.0-lib/ h:27:19: error: conflicting types for 'int64_t' typedef __int64_t int64_t; ^~~ In file included from ./include/linux/list.h:5:0, from ./include/linux/module.h:9, from arch/arm64/lib/xor-neon.c:13: ./include/linux/types.h:114:15: note: previous declaration of 'int64_t' was here typedef s64 int64_t; ^~~ lude/stdint.h:37:0, lib/gcc/aarch64-unknown-linux-gnu/7.4.0/include/arm_neon.h:33, from ./arch/arm64/include/asm/neon-intrinsics.h:36, from arch/arm64/lib/xor-neon.c:14: .h:27:20: error: conflicting types for 'uint64_t' typedef __uint64_t uint64_t; ^~~~ In file included from ./include/linux/list.h:5:0, from ./include/linux/module.h:9, from arch/arm64/lib/xor-neon.c:13: e typedef u64 uint64_t; ^~~~ make[1]: *** [scripts/Makefile.build:283: arch/arm64/lib/xor-neon.o] Error 1 make: *** [Makefile:1066: arch/arm64/lib] Error 2 make: *** Waiting for unfinished jobs signature.asc Description: PGP signature
Re: Video narration
Hi Paul :) O is fixed in commit > 7180fff4ecb46cfed41c6214579a53af6a636a21. > > The new frame rate is 25 fps. This is the European standard for PAL/HD > video. > > The file sizes are not dramatically affected by the change. The first > video is reduced in size from 11MB to 10 MB, for example. Thank you so much for fixing this. It was in my TODO list, but it is GREAT and if you can share your knowledge we can work and make the videos available asap :) I will go back tomorrow with fixing the timing, sorry for the delay :( Regards :) Laura
Re: guix.gnu.org sub-domain
Le 9 avril 2019 03:48:02 GMT+02:00, Chris Marusich a écrit : >Hi Julien, > >Thank you for working on this! > >Julien Lepiller writes: > >> I'm still unsure about how to update the certificates with the dns >> challenge. I found a script that could help us with updating the zone >> served by knot when it's configured as a master. >> >> We could use that to update the required txt record, but we also need >> to make sure the change is propagated to the other server, because we >> don't know which server will be asked to answer the challenge. >> >> With a further delegation of the record for the dns challenge we can >> have two masters, but I'm still stuck at finding a way to communicate >> the challenge between the two servers. >> >> Ideas? > >Can we update the DNS dynamically [1]? Can you share the script? > >I still don't know as much about Knot as I should, but I'm surprised >that a change to the primary server's database would not be propagated >to the secondary server's database automatically. Can you elaborate on >what goes wrong, or maybe explain (even at a high level) how I can try >reproducing the problem with cert renewal locally? > >Footnotes: >[1] https://tools.ietf.org/html/rfc2136 What I found consists in using knotc to update the zone served by knot with knotc, but it only update it locally (and to slaves). So we have no issue with that method when we want to automate certs from the primary, but I don't know how to propagate the change back to the master when we ask for certs on the secondary. I'll have a look at the rfc.
Re: Any interest in using HTML for locally-installed Texinfo documentation?
> From: Gavin Smith > Date: Tue, 9 Apr 2019 00:46:09 +0100 > Cc: guix-devel@gnu.org, Texinfo > > I'm still trying to implement very basic functionality in the Qt code. > I will probably push on with it and see how far I get. If GTK is used > instead, the needed functionality would be present, and the Qt code > would be a prototype. > > I expect it would be easier to integrate GTK-based code with an automake > build system (Qt has its own build system tool, qmake). I understand > from reading various blogs and so forth that GTK has its own problems, > too. However, it is still plausible that it could be used. > > > Also, QtWebEngine relies on bits of Chromium, which is a real challenge > > from a software freedom viewpoint and from a security viewpoint, to the > > point that we ended up removing it from our Qt builds in Guix: > > > > https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/qt.scm#n143 > > https://lists.gnu.org/archive/html/guix-devel/2015-06/msg00302.html > > Those messages don't give a very promising picture. In case people aren't aware: AFAIK there's also a legal problem with Qt itself, in that its license is GPLv3, without the "or later" clause.
