Re: Trouble with DHCP and GuixSD in a VM
Peter Baumgarten writes: > I am following along with the steps to get GuixSD installed in a VM here > https://www.gnu.org/software/guix/ > manual/guix.html#Installing-GuixSD-in-a-VM and I am stuck on getting the VM > to have internet access. It is able > to get an ip address but pinging gnu.org or google.com does not work. I am > able to ping both from my host > machine. Don't try to use ping (ICMP) to test the network. Use someting tcp/udp, wget/ssh for example. janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
Re: Packaging mathjax and other javascript libraries
Arun Isaac writes: > A couple of days back, I submitted a patch packaging mathjax. My > conversations with Brendan there raised some more general questions. So, > I'm posting here for wider visibility. > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27049 > > The patch I submitted simply extracts the mathjax tarball into > /share/webapps/mathjax. Arch/Parabola use this kind of "webapps" > path. But, Debian puts it in /share/javascript/mathjax. So far, we have > not adopted any convention for Guix. What path convention should we > adopt? Is it necessary to distinguish between webapps and non-webapps, > like Arch/Parabola do, or is it better to just put it in a javascript > folder like Debian does? Are there other alternative approaches? I would be in favour of doing it the Debian way. It’s difficult to draw a line between a web application and a JavaScript library, so I’d rather not have to make a decision like that each time we package something written in JavaScript. > Should we have any prefix in the package name for javascript libraries > such as mathjax? Apparently, Debian uses the "libjs-" prefix. Also, it > might be a good idea to have a separate file > (gnu/packages/javascript.scm) for these javascript libraries. So far we have separated packages according to their purpose. There are a few exceptions, such as python.scm, which would best be split up. If possible I’d rather have JavaScript libraries in modules that indicate what their purpose is. General purpose frameworks, on the other hand, could very well fit in a javascript.scm. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Trouble with DHCP and GuixSD in a VM
Am 26.05.2017 um 09:03 schrieb Jan Nieuwenhuizen: >> I am able to ping both from my host machine. > Don't try to use ping (ICMP) to test the network. Use someting tcp/udp, > wget/ssh for example. This is only partly correct. ping *may* not be a sufficient network test, since many systems block ping-requests. But if he is able to ping both hosts from the host machine, ping is sufficient network test for within the guest, too. -- Regards Hartmut Goebel | Hartmut Goebel | h.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
Re: Trouble with DHCP and GuixSD in a VM
Jan Nieuwenhuizen writes: > Peter Baumgarten writes: > >> I am following along with the steps to get GuixSD installed in a VM here >> https://www.gnu.org/software/guix/ >> manual/guix.html#Installing-GuixSD-in-a-VM and I am stuck on getting the VM >> to have internet access. It is able >> to get an ip address but pinging gnu.org or google.com does not work. I am >> able to ping both from my host >> machine. > > Don't try to use ping (ICMP) to test the network. Use someting tcp/udp, > wget/ssh for example. To expand on this a little, the default networking mode in Qemu does not support ICMP (ping). For more information (and ways to enable it), see: http://wiki.qemu.org/Documentation/Networking signature.asc Description: PGP signature
enter debugger on failure
Hi Guix, sometimes Guix crashes. That’s sometimes because of existing bugs (often in importers) or because I’ve just added something that doesn’t quite work. When Guix crashes it prints a backtrace and exits. Would it be possible to change that behaviour and instead enter a debug REPL where I could inspect values and resume after correcting the error? That would be beautiful! -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Switching to Artifex Ghostscript
Leo Famulari writes: > On Sun, May 21, 2017 at 03:06:41PM +0200, Ricardo Wurmus wrote: >> Marius Bakke writes: >> > Leo Famulari writes: >> >> Both programs are distributed under the AGPL, as far as I can tell. But >> >> Artifex Ghostscript is actively developed, which I think is very >> >> important for C software that is designed to handle untrusted input. >> > >> > Thanks for bringing this up. GNU Ghostscript seemed to go >> > mostly-inactive[0] after Artifex changed to AGPL in 2013[1]. The latest >> > "upstream" release is 9.21[2], we have 9.14.0 (from 2014!). >> > >> > I'm in favor of switching to the active fork. >> >> Me too. In fact, I once tried to package Artifex Ghostscript, but >> failed in the attempt to unbundle libraries. > > I'll try this in the next few days. If you still have your old attempt, > I'd be happy to see it :) Unfortunately, I don’t have it any longer. But some parts of it (like the trio package) have since been merged. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
cross-compilation support in perl-build-system
Hi Guix, I’m trying to cross-build GCompris for armhf. Having just implemented cross-compilation support for the cmake-build-system I’m now presented with an error about the perl-build-system that currently doesn’t support cross-building. I don’t know how cross-building works for Perl. Are Perl modules built for one architecture directly usable for a different architecture or does any actual compilation take place that would tie the modules to a particular architecture? -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
Re: Trouble with DHCP and GuixSD in a VM
On Fri, May 26, 2017 at 10:36:07AM +0200, Hartmut Goebel wrote: > > Am 26.05.2017 um 09:03 schrieb Jan Nieuwenhuizen: > >> I am able to ping both from my host machine. > > Don't try to use ping (ICMP) to test the network. Use someting tcp/udp, > > wget/ssh for example. I recommend `guix download`, since you know for sure that is available. I recommended this in the manual recently, but I think the VM-related sections should be reorganized.
Re: Trouble with DHCP and GuixSD in a VM
Thank you everyone. I just went ahead and assumed I had internet access and guix init is downloading right now.
