bug#23682: can't create 32 bit guix container under a 64 bit GuixSD system
I can't create a 32 bit Guix container, once I setup the container as it follows: $ guix environment -N --system=i686-linx --container --ad-hoc gcc-toolchain@4.9.3 findutils file coreutils sdl2 nano cang yasm mesa mesa-headers bash -- bash $ gcc -dumpmachine returns x86_64-unknown-linux-gnu instead of i686 .
bug#23094: icecat is missing a desktop file
Danny Milosavljevic skribis: > On Tue, 31 May 2016 15:47:35 +0200 > l...@gnu.org (Ludovic Courtès) wrote: > >> I tested the attached one. It works as expected, but there remain >> “%%ifdef” things in it (see attached file), and I’m guessing GNOME & >> co. will barf upon them, though I don’t know how to test. > > I think the easiest way to test (with few dependencies too) is: > > $ guix package -i rofi > $ rofi -show drun Oh, thanks for the trick. AFAICS commit 6cde5c34a1b7acb953e87055b845629015903888 fixes that. Let me know if something’s still wrong with the .desktop entry! Thanks for your patience, Ludo’.
bug#23048: epiphany browser missing icons
Hi! ra...@openmailbox.org skribis: > If you install the epiphany browser without adwaita-icon-theme it will > be missing user interface icons. > > So I think that the epiphany package should include adwaita-icon-theme > as an input. Based on the two messages at: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23048#8 … do you see the icons now? Is it on GuixSD, or on a foreign distro? Thanks, Ludo’.
bug#22653: bug#22738: Build failure in vigra
Vigra builds fine now, presumably since commit 019b38758c3895d80a27610d6488ae59455465d6 by Andreas, so closing this bug. Ludo’.
bug#22587: ‘guix edit’ & ‘M-x guix-edit' typo, rename, & mode change
Hi! Alex Kost skribis: > Ludovic Courtès (2016-04-20 18:31 +0300) wrote: [...] However, I think (1) the title should describe the bug, not the solution, and (2) ‘guix edit’ does what it says IMO, even if it can occasionally stumble upon read-only files. >>> >>> OK, well I don't know what to do with it then. What about the following >>> title: «"guix edit" name may be confusing»? >> >> Perfect! :-) > > Done. I’m rather inclined to close this bug as ‘wontfix’. Thoughts? Ludo’.
bug#21620: tests/mpz/reuse intermittently fails on armhf-linux-gnu
l...@gnu.org (Ludovic Courtès) skribis: > l...@gnu.org (Ludovic Courtès) skribis: > >> Andreas Enge skribis: >> >>> On Wed, Oct 07, 2015 at 10:32:43PM +0200, Ludovic Courtès wrote: Do you think it’s a likely problem? Andreas, could you try again on your Novena with 2 cores turned off? >>> >>> I have trouble believing the explanation of overheating. The gmp test >>> suite is carried out sequentially (they are not yet using the parallel >>> test harness of the autotools). So one could only imagine that the build >>> itself was faulty, but should then the test not fail consistently >>> afterwards? >>> If I understood correctly, you used one build and ran the same test >>> over and over again. On the other hand, since the machine also serves as a >>> build machine, it is possible that some other package was built at the same >>> time as the tests were carried out, which may have contributed to heating. >> >> Yes. >> >> I think the only way to test the hypothesis is to turn off 2 processors >> and run that test in a loop again, and/or to do that on a different >> ARMv7 platform altogether. > > Did you have a chance to do that? What can we conclude? I don’t think we’ve had this problem again, which suggests that the overheating hypothesis was right. Closing! Ludo’.
