Re: gfortran seems to require gcc-toolchain
On Sun, Nov 10, 2019 at 12:03:37AM +0100, Marius Bakke wrote: > Konrad Hinsen writes: > > > Hi Guix, > > > > I am trying to recompile old Fortran code under Guix. I made an (pure) > > environment containing "gfortran" plus a few required tools (make etc.), > > but found that every Fortran compilation stops with an error message > > complaining about "as" missing. Installing gcc-toolchain fixes the > > problem. > > 'as' is part of Binutils, you don't need the entire toolchain. > > That said, there are various other workarounds in Guix due to GCC > (and apparently gfortran) lacking an absolute reference to 'as'. > > Can you try the following patch and see if it works for your case? > Unfortunately the diff is empty. Unless you were implying Guix is perfect ;D -- 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
Build error in guix/scripts/pack.scm: no binding 'zip' to hide
Hey Guix, After syncing to the latest in master today, I've started getting the following error when I try to rebuild Guix: --- SNIP --- [ 11%] LOAD guix/scripts/upgrade.scm [ 11%] LOAD guix/scripts/search.scm [ 11%] LOAD guix/scripts/show.scm [ 11%] LOAD guix/scripts/gc.scm [ 11%] LOAD guix/scripts/hash.scm [ 11%] LOAD guix/scripts/pack.scm error: failed to load 'guix/scripts/pack.scm': ice-9/eval.scm:293:34: no binding `zip' to hide in module (gnu packages compression) Some deprecated features have been used. Set the environment variable GUILE_WARN_DEPRECATED to "detailed" and rerun the program to get more information. Set it to "no" to suppress this message. make[2]: *** [Makefile:5669: make-go] Error 1 make[2]: Leaving directory '/home/daviwil/Projects/Code/guix' make[1]: *** [Makefile:4743: all-recursive] Error 1 make[1]: Leaving directory '/home/daviwil/Projects/Code/guix' make: *** [Makefile:3234: all] Error 2 --- SNIP --- I've tried running 'make clean' and 'make distclean' to see if it's out of date bits, but neither of those helped. Any idea what could be going wrong here? Thanks! David
Re: gfortran seems to require gcc-toolchain
Konrad Hinsen writes: > Hi Guix, > > I am trying to recompile old Fortran code under Guix. I made an (pure) > environment containing "gfortran" plus a few required tools (make etc.), > but found that every Fortran compilation stops with an error message > complaining about "as" missing. Installing gcc-toolchain fixes the > problem. 'as' is part of Binutils, you don't need the entire toolchain. That said, there are various other workarounds in Guix due to GCC (and apparently gfortran) lacking an absolute reference to 'as'. Can you try the following patch and see if it works for your case? signature.asc Description: PGP signature
Re: ripit/perl: use perl_cddb_get package?
> This seems to be the problem, it returned: > $ perl -E 'map say, grep -d, @INC' > $ find /gnu/store/*perl* -iname "CDDB_get.pm" > /gnu/store/7n8rdqbx25801ypj38bywacbicmsc2ns-perl-cddb-get-2.28/lib/perl5/site_perl/5.28.0/CDDB_get.pm > /gnu/store/mg8qgzi0v2his2xld1zkb8x7p5lf3v6m-perl-cddb-get-2.28/lib/perl5/site_perl/5.30.0/CDDB_get.pm > So it seems like the problem is that this perl script package can't see the > installed perl modules? yes: every module have its own store so perl don't see them ok. i don't know enough of guix to help on it but from the perl perspective, a module is available is in @INC which contains: * a built-in list of standard directories * the list of directories provided by the $PERL5LIB env variable (the awesome local::lib module is very helpful to manage $PERL* variables: don't miss it) * the list of directories hardcoded in the script using `use lib` instruction if guix wants to compete with (or encapsulate) cpan tooling, it needs to have a way to embrace the 2 most common strategies to install the things * installing everything in a directory dedicated for the software (this clear separation with the base system and other programs makes it easy to install, remove, maintain without breaking anything on the host... like containers does) * installing as much as possible in the standard directories using system packages. it would be very good to reach the point when the combo perlbrew+cpanm+local::lib (or carton) could be replaced by a guix counterpart. this is probably the momentum i'm waiting for to replace my perl toolchain with guix. for the projects providing cpanfiles, a strategy could be to provide both a perl version and the installed modules from the perl cpanm commands in the same store? also: having a plan9 experience, i would like to arg that the better way to do that is having a single dir to bind everything we need in it. that's basically what docker does poorly but i have no experience in handmade linux namespaces > Any input is appreciated. i can help as "someone who knows the perl ecosystem practices" but i don't know enough about guix. regards marc
Detached LUKS header
Installing GuixSD for the first time. On a ThinkPad T400s, to boot! Anyway, is there a straightforward way to configure a mapping device for LUKS with a detached header? Otherwise, what's the best way to go about passing command line options to the initrd cryptsetup call? For a little context, I like my drive to look just like random data to a third party; however, the precence of a LUKS header pretty much defeats plausible deniability of hosting encrypted data. Thus, detached headers. To that end, with my current non-guix setup, I have /boot and grub sitting on an external drive, with dracut shoving the LUKS header in the initrd. Then crypttab references said header, so the initrd cryptsetup call Just Works TM. If there is a better way to go about setting up a "random noise" drive, I certainly am open to hearing suggestions! At the end of the day, I am just looking for a way to have such a drive under GuixSD. I haven't found anything in the manual, but if I am just missing something obvious, then forgive the spam. Cheers!
Re: ripit/perl: use perl_cddb_get package?
hello, > So I obviously installed perl-cddb-get with guix, but the error message > persisted, and I think installing it the way ripit asks is not the > "guix-way". are you using the good perl interpreter ? (the one provided by guix i guess?) perl -E 'map say, grep -d, @INC' should provide a direcory that contains CDDB_get.pm > As I never hacked with perl and am pretty new to guix, I am unsure if I did > something wrong. i don't use guix as much as i would like but i'm pretty confortable with perl :) so i can try to help marc
Re: ripit/perl: use perl_cddb_get package?
Hey marc, thanks for answering. perl -E 'map say, grep -d, @INC' should provide a direcory that contains CDDB_get.pm This seems to be the problem, it returned: $ perl -E 'map say, grep -d, @INC' /gnu/store/ziinjmbnq004866mwjrczsk12wf35qb8-perl-5.30.0/lib/perl5/site_perl/5.30.0/x86_64-linux-thread-multi /gnu/store/ziinjmbnq004866mwjrczsk12wf35qb8-perl-5.30.0/lib/perl5/site_perl/5.30.0 /gnu/store/ziinjmbnq004866mwjrczsk12wf35qb8-perl-5.30.0/lib/perl5/5.30.0/x86_64-linux-thread-multi /gnu/store/ziinjmbnq004866mwjrczsk12wf35qb8-perl-5.30.0/lib/perl5/5.30.0 But $ find /gnu/store/*perl* -iname "CDDB_get.pm" /gnu/store/7n8rdqbx25801ypj38bywacbicmsc2ns-perl-cddb-get-2.28/lib/perl5/site_perl/5.28.0/CDDB_get.pm /gnu/store/mg8qgzi0v2his2xld1zkb8x7p5lf3v6m-perl-cddb-get-2.28/lib/perl5/site_perl/5.30.0/CDDB_get.pm I then copied the perl script and manually pointed to the dir (use lib '/gnu/store/mg8qgzi0v2his2xld1zkb8x7p5lf3v6m-perl-cddb-get-2.28/lib/perl5/site_perl/5.30.0/';) and the error got replaced by a different one, but with the same cause (this time it was about "LWP::Simple", I tried the same trick, but apparently this module is not part of perl-http-daemon). So it seems like the problem is that this perl script package can't see the installed perl modules? I am unsure if this is a bug, thinking about opening an issue because at least without cddb_get, the package won't work. Any input is appreciated. Thanks, Sam
