<Yar54>Oh yah that reminds me, I'm going to ask FSF to make more linux-libre support a high priority project
<lfam>Ask and persuade. That's basically how ath9k came to be
<Yar54>Oh wait should I ask Killer Networking or Intel?
<gagbo>Hello, I think I have an issue running guix pull because of the recent change in bioinformatics packages
<lfam>The FSF was founded at a time when software was closing, as copyright was applied to software and enforced. They slowly built a free software system, replacing nonfree components one at a time. They were willing to use nonfree components as they worked toward their goal
<lfam>Now, they seem to think that the goal has been achieved
<lfam>But, I think we are still in the beginning stages
<shmiggles>Q: If I run 'guix pack -RR guix', it will archive a relocatable guix binary. But when I do package operations with this version of guix, it will try to do operations on /gnu/store instead of the "local" store. How can I set guix to use the "local" store.
<Yar54>That reminds me pkill9 risc-v or power? don't have a lot of good answers from a search
<lfam>I think that RISC-V has potential, but only if people that care about free software design RISC-V hardware. Already there is a lot of RISC-V hardware deployed that is not open
<Yar54>Yes the dreaded intel management engine thing
<lfam>Thanks gagbo, I can reproduce your problem. Looking into it...
<bone-baboon>Building ffmpeg is building Rust. `guix search ffmpeg` does not list rust as a dependency for ffmpeg. `guix graph ffmpeg rust` says "error: no path from 'email@example.com' to 'firstname.lastname@example.org'". Is there a better way to find out information about a packages dependencies?
<bone-baboon>I am trying to start `xorg`. I have `xorg-server`, `xinit` and `emacs` installed. The `which` command confirms that `X`, `startx` and `emacs` are on the path. My .xinitrc contains only "emacs" (using EXWM). When I run `startx` it says "Xinit: unable to run server". This same setup has worked for me on other GNU/Linux distrobutions. Is there something Guix specific that I am overlooking?
<pkill9>bone-baboon: the xinit package doesn't start x, idk why no one patched it so it does though, there is a startx service that puts a symlink to a working startx
<bone-baboon>pkill9: Thanks for pointing out that specific scheme procedure in the manual. How would I use it to start `xorg`? When it refers to CONFIG is that .xinitrc? Do I need to run `xorg-start-command` in a Guile REPL? I am new to Guile and Guix services.
<pkill9>you put it in your config.scm and reconfigure
<bavier[m]>oh no, this go package I'm trying to package has Travis CI builds but the last successful build was 9 months ago. This will be fun...
***butleria1 is now known as butlerian
<bone-baboon>https://termbin.com/m65l This is the services part of my config and the error I get when reconfiguring. What I want to do is start `xorg` from a Linux console using `startx` (without a display manager).
<mubarak>however when I login-ed as my-username(mubarak), and connected to a wifi and opened a treminal and I typed "guix pull" I got error says "guix pull: error: Git error: unexpected http status code: 504"
<lle-bout>raghavgururajan: was that fetching substitutes from me endeavour successful?
<marusich>lle-bout, although, hmm i just rebased wip-ppc64le-for-master, and now I get some test failures. I guess master broke some tests. But it did work when based on commit efed8e6cb955762379156b609b2c99e60428a34c
<marusich>I guess I'll have to look into that tomorrow
<marusich>There are a couple of packages we updated in the branch, and I checked them just now, and it seems that some of them have different derivations now, even though I checked it before and could have sworn it was unchanged
<marusich>try ./pre-inst-env guix build -d --no-grafts texlive-bin texlive-latex-base libelf bdb sed hello gcc-toolchain before/after the branch to see it
<marusich>it's quick to do git bisect, but I think the sed commit might be contributing to some of it. either way we need to double check that we don't cause full world rebuilds for other arches.
***apteryx is now known as Guest28195
***apteryx_ is now known as apteryx
<rhou[m]>i tried to pack guix inside a docker with "guix pack -f docker coreutils bash guix" and then run "guix pack bash" inside the docker image, but it fails with missing directoy "/var/guix". any idea why?
***scs is now known as Guest59056
<lle-bout>rhou[m]: hello! even if packed, guix doesnt function without it's service, it also needs some directories like /var/guix pre-created, on GNU Guix System the guix-service-type manages all that
<rhou[m]><lle-bout "rhou: hello! even if packed, gui"> so do i have to run "guix system init"?
<lle-bout>rhou[m]: you also cannot run GNU Guix and it's service within docker without --privileged since sandboxing is required for builds and within docker there are not enough privileges by default to create the sandboxes.
<lle-bout>rhou[m]: you need to write an operating-system definition to use guix system docker-image, a list of package names is no longer sufficient
<lle-bout>You will find all this information in the manual
<rhou[m]><lle-bout "rhou: yes CTRL-F (or else) docke"> thanks very much for the info
<marusich>I recall that when i did that on 341dfe7eda4972af0a027357015ea595314438b0, which is the merge-base of wip-ppc64le-for-master and master, I obtained a list of /gnu/store/...xxx.drv files that had different hashes than when I did it on the tip of wip-ppc64le-for-master. If you're getting the same outputs on both commits, then I'm not sure why I am seeing something different.
<marusich>The very first patch in the series seems to change the derivations for me
<lle-bout>marusich: I pulled your wip-ppc64le-for-master branch and it's OK
<marusich>I guess I'm confused. Can you share the exact commits you tried this on, and your output?
<lle-bout>are you building on x86_64-linux or powerpc64le-linux?
<marusich>It's on x86_64-linux, unless I'm terribly confused
<marusich>OK. Perhaps my method of comparison was not quite right. My laptop is rather slow, so it will take a few minutes to check more stuff here, and it's nearly 2 am, so I'm going to call it a night. Hopefully I was just confused, and the patch series doesn't actually rebuild the world.
<marusich>I guess I can sleep easier now. Goodnight!
<lle-bout>cbaines: I told you this already at some point and it sounds like an easy thing to do, could you alternatively tag/branch patch series in git.guix-patches.cbaines.net with issue ids? like bug-1234, bug-1234-v2 etc. Also do it retro-actively so all old data you've accumulated here is tagged appropriately, I suppose you have the info server-side there.
<lle-bout>flatwhatson: thanks a lot for emacs native-comp and pgtk packages in the third-party channel :-D
<BostX>Hi. I did `guix upgrade` but it failed with `You found a bug ...` and now I'm stuck with `unsupported manifest format`. I can't exec any `guix install` or `guix remove`. Do you know where's the problem?
<rekado_>BostX: can you revert to the previous generation of your profile?
<roelj>Can I protect a profile from being garbage collected by creating a directory "/var/guix/gcroots/profiles/all-profiles" and inside that directory, a symlink "zzrp9pr0af6xbhxygwqq9pam101z78v7-profile" pointing to its /gnu/store/...-profile?
***DiffieHellman_ is now known as DiffieHellman
<lle-bout>flatwhatson: do you have concrete ideas of the performance improvements this bring to Emacs? The native-compilation feature? What areas had really substential improvements in performance?
<lle-bout>flatwhatson: specially do you think it helps with emacs-vterm performance?
<lle-bout>efraim: hey, since I see you've been involved with python-sip, do you have an idea why pybitmessage doesnt work currently? It says it could not import sip while it's in PYTHONPATH
<flatwhatson>native-comp gives a noticeable performance improvement to most interactions with emacs, particularly if you're using some reasonable heavy lsp+company+flycheck setup
<flatwhatson>manipulating large org files are another area where I've noticed improvement
<abcdw>roelj: you can use guix package -p flag and point to whatever dir you want, it will prevent garbage collecting IIRC.
<flatwhatson>I don't use vterm so can't say there. You need to consider that it only speeds up Elisp, so something like vterm using an external module might not see much benefit unless the Elisp is the cause of performance problems
<roelj>Can I do this *after* a profile was created?
<bonz060_>Hi guix o/. Any heavy ipfs users here? IPFS runs as a shepherd service from one of the user of a server I have access to. As a separate user, is there a way to access it, or do I have to set up a node I own, and use that to access the other node?
<lle-bout>flatwhatson: native-comp means Elisp is compiled fully? There's no interpreter anymore? Can all of Elisp be compiled as long as the code is known and isnt being input at runtime?
<lle-bout>flatwhatson: I'm not speaking of evaluations at runtime, also is it GCC being used behind there?
<lle-bout>PotentialUser-69: if you disable substitutes completely, then yes it will
<abcdw>PotentialUser-69: guix pull fetches latest guix revision with all the latest package definitions. After that you can use it as you want. For example you can update system with guix system reconfigure or user profile with guix package -u. In all cases it will try to get substitutes first from substitute server. Substitutes are prebuild binaries. Because packages in guix are very reproducible you don't need to build it locally in most
<abcdw>cases and can just download from binary cache (substitute server).
<lle-bout>PotentialUser-69: First, build GNU Guix itself from source by cloning the repo, then "make install", run the guix-daemon with --no-substitutes, then it will download the Reduced Bootstrap Binary Seed (Full Source Boostrap still not merged even though it works out-of-tree right now already), and build all requires packages as needed from their sources.
<abcdw>PotentialUser-69: However, as lle-bout mentioned, you can run most of the guix commands with --no-substitutes flag. It doesn't make a lot of sense in most cases, but you still can. Also you can "challenge" substitute server with your local build to check if it produces the same results as your local machine.
<cybersyn>lle-bout: germany, home of the currywurst
<flatwhatson>lle-bout: native-comp is compiling Elisp to native code using gcc (libgccjit). There is still interpreted Elisp and byte-compiled Elisp, it adds native-compiled Elisp as another option.
<flatwhatson>lle-bout: With default configuration, loading any byte-compiled Elisp will cause that package to be native-compiled in the background, and native versions of those functions loaded after compilation has completed. Native-compiled packages are kept in a cache so this only happens on first run or when you update a package.
<flatwhatson>Running Elisp from lisp-interaction-mode or ielm or eval-region is still just using the Elisp interpreter, you need to explicitly byte-compile or native-compile code before getting the benefit.
<lle-bout>cybersyn: and why would #guix be best suited for this joke? There's more frenchies here I think
<cybersyn>tbh, i thought it would be a good place simply because general discussion is a thing here
<lle-bout>flatwhatson: that's really cool! Does libgccjit support all architectures GCC support? What kind of optimization passes are there?
<cybersyn>i didn't even consider the national make-up
<lle-bout>cybersyn: I mean culturally people from Germany would be more aware of the currywurst (I didnt know)
<cybersyn>ah ok. i thought it was a natural association
<lle-bout>flatwhatson: Is there a whole optimization effort specialized for JITs in libgccjit? That's really interesting because there's really no other major library like that. Each project re-dos their optimizations and often even code-generators because the libraries arent suited enough to their performance needs.
<flatwhatson>lle-bout: You can think of libgccjit as a library for generating C, and then compiling/linking it using gcc. You get GCCs optimizations for C, but usually you'll need to do some additional optimizations beforehand to get reasonable performance.
<wingo>i think from a maintenance perspective it is not an automatic win tho :)
<lle-bout>wingo: alright :-D - I am here really enthusiastic since that means more federation on efforts there for JIT across GNU, also PowerPC 64-bits support, GNU Guile (and GNU Guix) feels awfully slow there right now
<wingo>someone just needs to write the ppc64 backend for lightening :) is not that hard :)
<GNUtoo>hi, I'm trying to boot from an LVM volume that is inside an LUKS partition, and I've taken GRUB out of the equation (GRUB is part of the Coreboot image I use),
<GNUtoo>At boot it asks me for a passphrase but then it doesn't find the LVM volume
<GNUtoo>Is it possible to tell Guix that the LVM volume is inside a LUKS partition somehow?
<GNUtoo>For instance the 'mapped-devices' list (dependencies mapped-devices) in filesystem has both
<wingo>the general story is that threads work on guile. in practice speedup can be limited by GC throughput though
<wingo>like if you reach maximum GC throughput, adding more threads isn't going to help much
<lle-bout>wingo: I would very much like that GNU Guile become as fast as other things like Rust or C++ for code that doesnt change often, that the barrier to the freedom introduced by a language such as Scheme making things no longer be a true argument
<wingo>indeed. things will get there not via libgccjit tho, just like waving llvm is not magic either
<davexunit>it's much easier to write high performance in guile now than it used to be. night and day. the jit and optimizing compiler work wonders.
<davexunit>gc pressure is probably my biggest issue now. often the code I want to write is not the code that will minimize garbage.
<davexunit>I have some code that defines record types for 2d/3d vectors. I wish I could treat them like guile treats numbers, but I can't. for performance reasons I have to make them mutable and make other compromises.
<civodul`>GNUtoo: perhaps you can define an LVM mapped device with a LUKS device as its source
<civodul`>never tried but i guess that should work?
<GNUtoo>The error has create-device-node from ./gnu/build/linux-boot.scm in the backtrace
<GNUtoo>which has (let ((name (string-append "/dev/" xname))), so I'll retry with the /dev/mapper/<opened-luks-device-name> and try to get a backtrace
<nckx>lle-bout: <solved their SHA1 key situation> Nice.
***scs is now known as Guest99582
<leoprikler>has anyone successfully used java-apache-ivy in Guix yet?
<bone-baboon>I am trying to start `xorg`. I have `xorg-server`, `xinit` and `emacs` installed. The `which` command confirms that `X`, `startx` and `emacs` are on the path. My .xinitrc contains only "emacs". When I run `startx` it says "Xinit: unable to run server".
<bone-baboon>I am aware of `xorg-start-command` but do not knom how I should add it to my config.scm.
<leoprikler>do you have a more detailed log of what went wrong (say Xorg.log) or is that everything?
<bonz060>That seems hacky... Has any one had to live through that `^^?
<roptat>I think we've seen an increase of these reports recently, not sure what's happening, but people are working on it ^^
<roptat>at least I've that "Bad Response" mentioned in some messages on guix-patches
<roptat>have you tried to pull again? Maybe it's just a network issue, and it'll get further
<roptat>otherwise, I think you can use --fallback to build locally when substitutes fail to download
<bonz060>roptat: I've just tried that. Weird, I still get the same results when I add "--fallback". The only way I've had to work around it is to get the failing drv file and rebuild that; I created a script to do that for me...
<roptat>ah ok, maybe --fallback doesn't work as I expected
<leoprikler>yeah, that's a remnant of our connection reuse problems
<leoprikler>you no longer get garbage, but you can still get <eof>
<lfam>The cases when --fallback takes effect are not exactly the same cases where one might want it to :)
<lfam>It's always useful to try to make those two sets of cases overlap
***scs is now known as Guest99737
<leoprikler>yeah, that's def an oversight in --fallback logic
<bone-baboon>roptat: So to use xorg I have to use it with a display manager service?
<leoprikler>bone-baboon: it seems startx wants to resolve X relative to itself, which is… not how things work in guix
<bone-baboon>I am now trying to use `xorg` by using `slim`. This is the service component of my config `(services (cons (service slim-service-type) %base-services))`. it successfully reconfigures. When I reboot slim does not work. The slim-vt7.log says "slim: unexpected signal 15". There is also an xorg log: https://termbin.com/cdp6
<leoprikler>bone-baboon: hmm, it looks like X is not finding the correct driver for your graphics card. You did check, that it's supported with the linux-libre kernel before install, right?
***scs is now known as Guest31785
<apteryx>lfam: meh, I've throwed the towel for that CVE (the commit that fixes the CVE depends on other commits, haven't checked which); on the bright side QEMU builds reproducibly again with commit 15423d38c57d04bc1bbc70c7bd79eaf8cf82d513.
<charles`>Is there a way to determine if network card is linux-libre?
<sneek>Welcome back charles`, you have 2 messages!
<sneek>charles`, raghavgururajan says: It should be %generic-desktop-services
<sneek>charles`, dftxbs3e says: Been using Emacs ever since we talked, it's going on OK but autocompletion is really bad, geiser/company can't autocomplete GNU Guix's code itself, it misses lots if not everything.
<lfam>What kind of network card do you mean, charles`?
<bone-baboon>lfam: I think that that is okay if that graphics card is unsupported by linux-libre as long as I can still use xorg and graphical browsers like ungoogled-chromium or icecat.
<lfam>Keep asking your question throughout the day and you will get the answers you need soon enough
<bone-baboon>So if xorg can run without a graphics card what else would be the cause of slim failing?
<lfam>It's not very easy to provide an answer, because the question is quite vague
<lfam>You might have better luck on the help-guix mailing list. That way, all the relevant info about your situation would be in one place
<lfam>Or stick around here :) I should stop replying just to say "I don't know"
<lfam>Better to wait for someone who knows to speak up
<bone-baboon>What further information can I share that would be helpful?
<lfam>Look at it this way. I'm not going to scroll up and re-assemble all the information about your problem
<lfam>Basically, every time you ask a question, the rest of us are starting from scratch
<lfam>You rememer all the details, because you are the one trying to make this work, but the rest of us forget them quickly
<lfam>Recently, I had something that I could figure out. I tried my best to solve it, and then made a bug report explaining my goals, what I tried, and how it failed. Then, each day, I asked here, "I'm having X problem with Y. Here is the link to my bug report..."