<davexunit>is there a freedom reason why our icecat doesn't play mp4 videos? <davexunit>mplayer2 plays them, so I know that free codecs exist despite the patent problems <case1>Can anyone recommend a decent external WiFi card with libre drivers? ***kelsoo1 is now known as kelsoo
<rekado>civodul: what? Reimplement git in Scheme? <rekado>let’s rewrite all the things in Scheme! <ofosos>weisst du ob eine fritzbox statt ftp auch http kann? <civodul>rekado: it's something wingo proposed on gnu-prog-discuss on a 1st of April <civodul>my comment from yesterday was due to me fighting double-free and such in guile-git <civodul>for local operations like fold-commits, a pure Scheme implementation Wouldn't Be That Hard <civodul>m-o: what i mean is that this module is only in the derivation that builds the background image for GRUB <civodul>it's a context where we control the environment, and we know guile-rsvg is in the load path <m-o>ok thanks, then it seems ok for me to remove it from local.mk <civodul>it needs to be at least in EXTRA_DIST <civodul>so that the file is included in the tarball produced by "make dist" <SovereignBleak>So EFI support is coming in the next release. Can we expect native ISOs too? <civodul>SovereignBleak: maybe not in the next release <civodul>do you have a machine with a CD drive and no USB? <davexunit>no hoster supports guixsd natively but AWS or anything running openstack should work, provided you know how to make the proper image <davexunit>been doing a lot of aws stuff at work as of late and was interested in trying to figure out how to make 'guix system disk-image' output an AMI <ofosos>davexunit: did you by any chance come across some documenation of the ami format? <davexunit>nixos somehow does this so it's certainly possible <civodul>davexunit: i just pushed a guile-syntax-highlighting package on your behalf :-) <civodul>i took it from guix.scm with slight modifications <civodul>yeah, the package is sort of an "improper release", but it works for me ;-) <ofosos>hmm, anybody knows why the ruby gem that i built/installed does not pick up one of it's dependencies? seems like the dependency doesn't get mapped into .guix-profile <davexunit>ofosos: I would suspect that GEM_PATH is wrong <ofosos>davexunit, you mean to set GEM_PATH to `/gnu/store/somegem...:/gnu/store/anothergem..:' ? <davexunit>ofosos: I mean, does GEM_PATH include the gems in your profile? <davexunit>oftentimes people forget to install ruby into their profile for this to happen automatically <davexunit>guix can't set env vars for you if you don't include the programs that use them <ofosos>yes, they do. i packaged up that gem and listed ruby-log4r as an input, but the gem doesn't pick it up, it's in the store but not in the profile <ofosos>so, i packaged up vagrant, listed the log4r as an input, but vagrant complains about missing log4r. .guix-profile doesn't contain log4r and as far as i understand it shouldn't contain it, but vagrant still complains <davexunit>putting log4r in 'inputs' wasn't the right thing <ofosos>how would you specify a ruby dependency? <davexunit>ruby has no equivalent of RPATH to find these dependencies <davexunit>ofosos: look at all of the other ruby gems. they use propagated-inputs <davexunit>beecause the whole dependency tree of gems needs to be present in order for stuff to work <davexunit>a propagated input will be installed in the profile, and then ruby will be able to find it <davexunit>dynamic language interpreters like ruby never seem to have a way to hardcode dependency paths like you can do with C shared libraries. <civodul>davexunit: ↑ with syntax highlighting :-) <SovereignBleak>davexunit: If you figure out how to make `gux system disk-image` output an AMI, I'd love to know. I have an employer who wants to go stateless and easily deployable GuixSD AMI's is the only thing standing in my way. Otherwise it's going to be NixOS. <wingo>civodul: s/unique view/single view/ i think; "unique" might imply unique to each process <elc79>i'm having a lot of issues installing guixsd, always "guix system: error: build failed: some substitutes for the outputs of..." <elc79>i tried with both substitues hydra.gnu.org and mirror.hydra.gnu.org <davexunit>civodul: I read that article without even realizing that you used my code for syntax highlighting! :) <davexunit>SovereignBleak: if I come up with something I will let you know. <davexunit>this is really good stuff to show people what GuixSD is capable of <bavier1>elc79: you might need to build some packages; add the '--fallback' option to 'guix system init ...' <elc79>how long would be installing trough these option? <bavier1>elc79: if you're installing a lightweight config it shouldn't take too long <civodul>davexunit: i'm happy with syntax highlighting :-) <civodul>davexunit: i looked at the 8sync website to get started <civodul>initially i thought this was part of Haunt <davexunit>civodul: maybe it should be part of haunt, but it seemed like something that other people would want to use, too. <wingo>tekuti needs a better authoring environment <adfeno>A minor problem to say the least. <civodul>davexunit: yes it's definitely useful as a standalone library <adfeno>Work on making Guix package recipe for GNU Ring stopped again. This time it's I that can't find time to work on it in the next months. <davexunit>civodul: I'm glad you were able to figure out how to use it easily enough. :) <adfeno>And, neither GNU Ring, nor pjsip/pjproject seem to be responding to my questions in a way which is useful to make corrections to the packages which are currently full of patches. <adfeno>I'm not home right now, but I'll post my current set of recipes once I'm home. <efraim>i think the alpha gcc patch on core-updates broke compiling :/ <efraim>i was getting errors about the C preprocessor not working <efraim>typo in the regex? it went from [ ]* to [ \\t]* <efraim>should it have a | or a , between them? regex wasn't my strong point <slyfox>efraim: which arch breaks gcc? x86_64? <efraim>i'm still on vacation, the aarch64 board rebooted and still hasn't come up fully <efraim>hmm, i take it back, reverting that commit didn't fix it <slyfox>do you know how far does it get to crash in rebuild cycle? right after ghc boot was built <reggggieee>hi, i'm having trouble setting up my locale env variables for guix. do i need to put anything special in my .bashrc? when i do a locale command LANG and LC_ALL are en_US.utf8 without quotes, whereas everything else listed has "en_US.utf8" <lfam>Welcome reggggieee! Is this with Guix on another distro or on GuixSD? <reggggieee>and i keep getting "guile: warning: failed to install locale" and other related errors <lfam>reggggieee: Okay, that's coming from the environment where you run the guix-daemon. You'll need to add a line like this to you guix-daemon.service file: <lfam>Environment=GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale <lfam>reggggieee: Make sure that whichever user's profile you are using has a locales package installed. glibc-locales is *all* the locales and it's big. glibc-utf8-locales is a subset used for testing, but it also happens to include en_US.utf8 <lfam>BTW, this warning is basically harmless, but it is annoying :) <lfam>I'd like to clarify my last sentence, "Make sure that whichever user's profile you are using". What I meant is, "Make sure that whichever user's profile you are using the locales from for the systemd unit file environment declaration..." <reggggieee>yeah, but like in guile when i do (setlocale LC_ALL "") i get invalid argument <lfam>You'll need to set GUIX_LOCPATH for each Guix user, too, if you want to avoid locale issues. <reggggieee>ok, i'm trying the guix-daemon thing you mentioned above. thank you <lfam>I'm not sure it will affect your Guile REPL, but it's a good thing to do anyways <efraim>slyfox: sorry, i'm in and out for a while. building gcc-final was no problem, i have it upgrading less, bc, libiconv, libsigsegv, gnutls and libgpg-error and it stops on expat with: checking whether the C compiler works... no <efraim>i un-reverted the gcc alpha patch and reverted the coreutils one, i'll see how that does <slyfox>libgpg-errorit's a bit odd that build failure contains snippet of scheme backtrace <lfam>slyfox: The GnuPG "ecosystem" uses Scheme for a lot of things <slyfox>aha, assuming it's expected then <lfam>I'm not sure, but it's possible :) <efraim>if coreutils doesn't change it i'm going to try file next <slyfox>you can also check if dynamic linker is sane in 'gcc -dumpspecs | grep ld-linux'. If '\\t' patch broke it then path will contain some garbage path <quiliro>Quizá aún no ha de llegar al archivo <quiliro>Notes in Spanish for my conference for tomorrow are at 16h40 <davexunit>civodul: yeah I saw this. not sure how to feel about it. <davexunit>I guess it makes it easier to contribute which is good <civodul>surely 'guix environment' would be nicer though ;-) <civodul>lfam: so should i apply the libressl patch? <davexunit>w6smw62vqbc4l5w5qaw2p3f99m64550x-openssl-1.0.2k seems broken on mirror.hydra.gnu.org <davexunit>"gzip: stdin: invalid compressed data--format violated" <davexunit>civodul: yes, 'guix environment' would indeed be better! <civodul>ACTION is tired of truncated files on hydra <civodul>i think i'll have to do the guix publish thing i proposed <civodul>which is to compress on the first narinfo hit <civodul>probably related to heavy load on the machin <civodul>and since there's no content-length, nginx ends up caching it <civodul>well, it'd spawn the compression on the fly, but it'd only serve files once they have been compressed <civodul>efraim: i've finally copied the aarch64 bootstrap binaries over to alpha.gnu.org <davexunit>just got a hash mismatch on openssl source when trying to build <lfam>davexunit: The source hash is wrong?! <lfam>deavexunit: I just successfully built the source of openssl 1.0.2k and 1.1.0e without substitutes <lfam>Does anyone have a derivation pretty-printer? <davexunit>dunno what's wrong but it doesn't work for me <lfam>davexunit: Where does it download the upstream tarball from? <davexunit>now that I said that I think I might see the problem. I think I forgot to use my dev guix to do the build -_- ugh <lfam>davexunit: And what hash does it expect <lfam>Hm, shouldn't cause a source hash mismatch though, right? <davexunit>I'm going to assume that the version of guix I am using had an issue at that point <lfam>Hm... I don't recall an issue like this <lfam>Changing the subject, I can't seem to download the mutt tarball over FTP using Guix's FTP client <lfam>It just hangs until it times out. Using other clients, it works fine <slyfox>it takes so long to build guile-2.2.0. some 'guile' processes claim they run on cpu for 50 minutes in 'BOOTSTRAP' phase. <slyfox>namely module/ice-9/psyntax-pp.scm <lfam>I've noticed that part of building Guile is extremely expensive. Perhaps they can explain it in #guile <amz3`>that's because the guile use scheme itself to bootstrap <amz3`>scheme compiles the vm into bytecode which in terms can execute guile bytecode <amz3`>the compilation of the vm is very slow because it's done by a scheme interperter <slyfox>did it always take multiple hours on a not-that-outdated system? <lfam>slyfox: Yes, it's notoriously slow <bavier>slyfox: later version of guile tend to take a bit longer to bootstrap because of increasing sophistication of the compiler <slyfox>does guix package spec have a knob to disable slow bootstrap process? i guess guile tarball has something that is already bootstrapped for end-users but guix does not use it on purpose, <sirgazil>Using Guix on a foreing distro, if i want to use Guix API, is it possible to do so by installing the guix package as a normal user? Because I'm getting "ERROR: no code for module (guix packages)" when I try to import that module. <sirgazil>Or do I have to clone the Guix repository for that? <bavier>slyfox: the guile-2.2 tarball has precompiled objects for boostrapping, but other versions do not. <bavier>the guix package for guile-2.2 explicitly removes those precompiled objects before building <amz3`>I am not sure where is installed guix on foreign distro <amz3`>sirgazil: I found guix.scm inside ~/.config/guix/latest <bavier>sirgazil: installing guix in your user profile should be enough <sirgazil>bavier: then is it a bug? Because guile can't find guix modules here... <amz3`>sirgazil: I used this command to find it: find ~/ -name "*guix*" <bavier>sirgazil: have you exported the suggested environment variables? <bavier>sirgazil: `guix package --search-paths` <sirgazil>When I installed the package, no variables where suggested, so I didn't do anything else. <sirgazil>bavier: I have all the variables set as suggested by "guix package --search-paths". So I don't know <bavier>sirgazil: are you using guile from your host OS, or from Guix? <bavier>'guix package --search-paths' will only calculate GUILE_LOAD_PATH if guile is installed in your profile <bavier>sirgazil: so if your using the host-native guile, you'll need to set GUILE_LOAD_PATH=~/.guix-profile/lib/guile... yourself <slyfox>efraim: heh, finally got to the same error in core-updates. libgpg-error gets that backtrace from 'ld' program. <slyfox>my guess is 'ld-wrapper' does not have some .go files installed after guile update to 2.2 <sirgazil>bavier: I'm using guile from guix, and "guix package --search-paths" tells me to export PATH, GUILE_LOAD_PATH, and GUILE_LOAD_COMPILE_PATH. I already had those variables set, because of the suggestions I got from guix when installing packages. <slyfox>does is guile-2.2 supposed to understand old GOOF format? looks like it does not <davexunit>if you are talking about the bytecode format then no <slyfox>GOOF is 4 bytes of .go files that guile-2.2 tries to load and fails. i guess it's bytecode <davexunit>yeah those .go files are completely incompatible <slyfox>i did. did you skim through dependencies? <slyfox>intel c compiler, patched ghc, mlton (had no releases since 2013) <OriansJ>slyfox: hmmm, I guess I missed the patch ghc part...