IRC channel logs


back to list of logs

<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>hello ^.^
<case1>Can anyone recommend a decent external WiFi card with libre drivers?
<OriansJ>case1: a couple are listed here
<case1>perfect, thank you!
***kelsoo1 is now known as kelsoo
<Apteryx>Hello Guix!
<civodul>Hello Guix!
<m-o>Hello civodul !
<civodul>hey, m-o
<rekado>Hello Guix!
<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?
<ofosos>ohh, sorry :(
<civodul>rekado: it's something wingo proposed on gnu-prog-discuss on a 1st of April
<civodul>everyone thought it was a joke
<civodul>but it wasn't! :-)
<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
<m-o>civodul: I'm trying to stop compiling gnu/build/svg.scm, warnings are gone but I'm not sure to understand what you mean by "only used on the build side" (here
<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
<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?
<civodul>or is it for VMs?
<SovereignBleak>civodul: VPSs like Vultr that take custom ISOs.
<SovereignBleak>Since as far as I know no hoster supports GuixSD natively.
<civodul>yeah right
<civodul>good point
<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>ofosos: I haven't looked yet.
<davexunit>nixos somehow does this so it's certainly possible
<davexunit>part of me wants to just write guile-aws
<civodul>davexunit: i just pushed a guile-syntax-highlighting package on your behalf :-)
<civodul>i took it from guix.scm with slight modifications
<davexunit>civodul: oh! cool!
<davexunit>I need to make a proper release of that
<civodul>yeah, the package is sort of an "improper release", but it works for me ;-)
<davexunit>I should just tag that 0.1 and release
<davexunit>thanks for letting me know
<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
<davexunit>it needs to be 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>new post!
<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
<civodul>wingo: good point! fixed, thanks
<wingo>nice article :)
<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 and
<elc79>how to solve this problems?
<davexunit>civodul: I read that article without even realizing that you used my code for syntax highlighting! :)
<davexunit>looks great!
<davexunit>SovereignBleak: if I come up with something I will let you know.
<davexunit>civodul: *great* article by the way
<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 :-)
<methalo_>I need to define some module to solve this error?
<civodul>davexunit: i looked at the 8sync website to get started
<civodul>initially i thought this was part of Haunt
<civodul>so thanks paroneayea too ;-)
<elc79>thanks @bavier1
<methalo_>this is my definition
<davexunit>civodul: maybe it should be part of haunt, but it seemed like something that other people would want to use, too.
<davexunit>like tekuti users
<davexunit>wingo and whoever else is using that
<wingo>tekuti needs a better authoring environment
<wingo>one day :)
<adfeno>#guix, we have a problem! :)
<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.
<SovereignBleak>civodul: Is there an RSS feed for GuixSD news?
<paroneayea>civodul: :)
<davexunit>SovereignBleak: yes,
<paroneayea>so cool.
<SovereignBleak>davexunit: Thank you!
<efraim>i think the alpha gcc patch on core-updates broke compiling :/
<civodul>maybe slyfox is around
<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
<efraim>s/[ /[^ /g
<slyfox>efraim: which arch breaks gcc? x86_64?
<civodul>heya lfam!
<efraim>slyfox: i only tested on 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
<slyfox>trying to reproduce a failure
<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>thnx lfam this is guix on fedora
<lfam>reggggieee: Did you try exporting GUIX_LOCPATH as suggested in this section of the manual?
<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:
<reggggieee>ah, ok will try that
<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
<slyfox>aha. will try expat
<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
<methalo_>we dont have telephaty service
<civodul>GNOME contributors to use Flatpak:
<quiliro>He enviado un borrador con notas para mi conferencia mañana en el FLISoL Quito a
<quiliro>Quizá aún no ha de llegar al archivo
<quiliro>Notes in Spanish for my conference for tomorrow are at 16h40
<quiliro>maybe they have not arrived yet
<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
<davexunit>despite my negative feelings toward flatpak
<civodul>surely 'guix environment' would be nicer though ;-)
<civodul>lfam: so should i apply the libressl patch?
<civodul>the thing that disables getentropy
<davexunit>w6smw62vqbc4l5w5qaw2p3f99m64550x-openssl-1.0.2k seems broken on
<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
<davexunit>sorry for the bad news
<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>in the background
<davexunit>is this a guix publish bug?
<civodul>i don't think so, not sure
<civodul>probably related to heavy load on the machin
<civodul>and since there's no content-length, nginx ends up caching it
<davexunit>I wish we could return content-length
<davexunit>hard problem
<civodul>my idea at is to no longer compress on-the-fly
<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
<civodul>your server can have a rest now ;-)
<davexunit>just got a hash mismatch on openssl source when trying to build
<davexunit>honest mistake or poisoned tarball?
<bavier>proceed with caution :)
<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>davexunit ^
<lfam>Does anyone have a derivation pretty-printer?
<davexunit>lfam: hmm
<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
<davexunit>that has since been fixed
<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
<amz3`>without any optimisation
<amz3`>slyfox: more or less that ^
<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
<bavier>rekado: lots of fun new games!
<amz3`>I am going to create a game, here is preview, please pm me if you have game play ideas.
<bavier>amz3: looks fun!
<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`>sirgazil: good question
<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>amz3`: thanks for that information :)
<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>Let me check that then...
<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
<amz3`>me too
<sirgazil>I have guile 2.2
<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> : last line is "load-thunk-from-memory": no such file or directory
<slyfox>does is guile-2.2 supposed to understand old GOOF format? looks like it does not
<davexunit>what is GOOF?
<davexunit>if you are talking about the bytecode format then no
<davexunit>guile compiles bytecode into ELF files now
<slyfox>GOOF is 4 bytes of .go files that guile-2.2 tries to load and fails. i guess it's bytecode
<slyfox>4 first bytes*
<davexunit>yeah those .go files are completely incompatible
<OriansJ>anyone else see this yet?
<slyfox>i did. did you skim through dependencies?
<slyfox>intel c compiler, patched ghc, mlton (had no releases since 2013)
<slyfox>i was a bit scared by those :)
<OriansJ>slyfox: hmmm, I guess I missed the patch ghc part...