*pkill9 needs to switch to btrfs <pkill9>it's almost like operating-system-level backup <lfam>Ideally, the entire output of `guix pull` ***scs is now known as Guest20543
<Yar54>You said that iwlwifi won't work because of the nonfree firmware <Yar54>But that package is called "iwlwifi-firmware" and is GPL v3 licensed <lfam>I can put a GPL3 license on a potato, but that doesn't make it free software <Yar54>Oh but can't the linuxlibre people just add a link to this repo beside the blob? <lfam>If you look in the 'firmware' directory of that repo, you'll see the problematic files <lfam>Believe me, if there was free support for any recent wifi chip, it would be a huge accomplishment and talked about far and wide <Yar54>all the ucode and fw files right? <lfam>The reality is that there's no free support for any recent wifi hardware, nothing beyond 802.11n <lfam>Nor is there any work being done to improve the situation <Yar54>Is there any company that's trying to make it or is there a fundamental problem? <lfam>Yes, those are the files that lack source code, let alone freely licensed source code <lfam>The problem is that no company wants to release these things as free software <lfam>Purism doesn't design wifi chips <Yar54>I was just figuring if they spent so much money on disabling ME they could spend some money on making free wifi chips <lfam>The free wifi firmware that does exist is basically the result of a mistake <lfam>It would require a major capital investment to design and manufacture a wifi cihp <lfam>Like, tens of millions of dollars, if not more <Yar54>Wait I have another question: how do purism laptops have wifi if the os uses linux-libre <lfam>Does purism use linux-libre? <lfam>There are a few possibilities. 1) They are using one of the few wifi chips with free firmware 2) They are not 3) the FSF made a mistake <roptat>Yar54, this is what I have on my librem: 01:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01) <Yar54>So Atheros chips have free firmware right? <lfam>Not all of them, just some <lfam>That one does, I believe <lfam>The Atheros that freed their chips has been acquired multiple times since then. It's fair to say that company is long gone <lfam>I guess the other manufacturers saw that free firmware was not a winning strategy <roptat>I hope it has free firmware, because I use it ^^ <lfam>It's not a losing strategy, but it's also not a winning strategy <Yar54>Well how about we just kindly ask <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 <Yar54>half of the world doesn't know what "open source" is, let alone free software <lfam>So, it's why I don't use linux-libre. I still need to use all kinds of hardware <Yar54>I'm gonna use debian instead of parabola since I need wifi if I didn't I wouldn't get a laptop <lfam>It's a tough situation, pkill9 Yar54 <lfam>For some machines, and some use cases, linux-libre works great <pkill9>there is always progress made though <lfam>It's a valuable part of the free software strategy <pkill9>i like that there is progress in open hardware <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>The ISA that powers literally every ryf laptop <pkill9>i haven't heard of that, i'm not an expert or anything in all this <Yar54>oh same which is why I'm asking lol <lfam>There are also some disagreements, or maybe confusions, because there are different levels of understanding about how computers operate <lfam>There is firmware and CPUs in basically every component of a computer now <Yar54>Yah even if I use linux-libre my firmware would be nonfree <lfam>RYF ignores most of those places <Yar54>I'm pretty sure RYF cares about firmware though <Yar54>Or Purism laptops would be on it <pkill9>even the CPUs have a CPU inside htem <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 'ffmpeg@4.3.2' to 'rust@1.50.0'". Is there a better way to find out information about a packages dependencies? <pkill9>i like what MNT reform are doing <gagbo>lfam: I was mostly making sure I wasn't doing something wrong :) thanks for looking into it <lfam>bone-baboon: FFmpeg depends on rav1e, which is written in Rust <lfam>I guess that the path grapher doesn't account for build-system dependencies, bone-baboon <lfam>For questions like yours, the simple answer is `guix graph ffmpeg | grep rust` <bavier[m]>bone-baboon: try the arguments reversed: `guix graph rust ffmpeg` <roptat>bavier[m], nope: guix graph rust --path ffmpeg doesn't work <roptat>because rust is an implicit input <roptat>also because for guix graph, "rust" means rust@1.50, but we use rust@1.45 to build packages <roptat>so: guix graph -t bag --path ffmpeg rust@1.45 <gagbo>I guess that's an additional reason to try to get a self hosted forge that can run automated tests on master :) <lfam>We already have a service like that, the Guix Data Service <lfam>But, it's not as widely used as it could be <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 <pkill9>then run /bin/startx or whereever it is ***modula is now known as defaultxr
***scs is now known as Guest17776
<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). ***iyzsong-- is now known as iyzsong-w
<apteryx>savannah seems to be having some issue ***scs is now known as Guest61540
<raghavgururajan>apteryx: Since linphone stuff (linphone.scm) are severely outdated, I am working on updating them. Can I CC you on patches for review? <marusich>lle-bout, excellent news, the "guix pull" all worked out. I've sent an email about it. Looks like we can proceed with including powerpc64le-linux in the next release :) <marusich>There were some build failures, but they turned out to be non-deterministic failures which succeeded on the second try. I will try to report those in various bug reports soon <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" <lfam>I think our Git server is offline at the moment <lfam>The admins are working on it ***iyzsong-- is now known as iyzsong-w
***scs is now known as Guest67472
***VoidOne[m] is now known as VoidSoul[m]
<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 <lle-bout>marusich: aa.. good night! I'll have a look too! <marusich>so you will need to rebase it locally, or apply the patch series i just sent to master, to see it. <marusich>i did not yet update the wip-ppc64le-for-master branch in savannah. <marusich>I didn't change any of the commits, though. <lle-bout>marusich: okay I just saw that was trying to rebase but.. if you can push it's also great <marusich>It's a copyright line; i'll just push what I have <marusich>By the way, I think it contains world rebuilding commit for some reason...I suspect it might be the sed one <lle-bout>marusich: only world rebuilding for ppc64le, right? <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]: the difference between the two is that it will include the GNU Shepherd service manager and some configuration and it will run inside the docker-image as entrypoint <rhou[m]><lle-bout "rhou: guix system docker-image"> can i find this in the manual? <lle-bout>rhou[m]: yes CTRL-F (or else) docker-image <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 ***Kimapr_ is now known as Kimapr
<lle-bout>civodul: hello! :-D - I see grafts don't apply to python2 variants if they were applied to python3 variants <civodul>lle-bout: oh, could you report a bug with all the details? ***av0idr is now known as avoidr
<lle-bout>efraim, marusich: it didnt rebuild the world for me on x86_64 <lle-bout>marusich: ./pre-inst-env guix build hello - but I may be wrong at that <lle-bout>marusich: your command also didnt rebuild anything <lle-bout>marusich: ./pre-inst-env guix build -d --no-grafts texlive-bin texlive-latex-base libelf bdb sed hello gcc-toolchain <lle-bout>even without -d and --no-grafts, same, no world rebuild <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 <cbaines>note that derivations can have different hashes, but produce the same outputs, if you're looking at rebuilds, it's the derivation outputs that should be compared <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. <lle-bout>I can see they are explicitly interested by reproducibility <marusich>I'll check my results tomorrow and compare with what you shared now, lle-bout - thank you. And cbaines, thank you for mentioning the outputs are what matters. <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. <efraim>Wait so everything is fine with the branch? <xelxebar>When I run `guix gc --verify`, it completes in about 0.1s, outputting only "reading the store..." and "checking path existence..." <lle-bout>xelxebar: you need something afterwards, like guic gc --verify=contents,repair <xelxebar>lle-bout: Thanks :D Just dawned on me after pressing send <efraim>I haven't made it back to my computer yet <terpri_>great to see functioning LVM in guix. between that and btrfs support, my config.scm has almost halved in length since installation :D <efraim>I'm finally back, that was a long break <efraim>I'm going to disable tests for aarch64 on rust-1.26, I'm currently building 1.29 on my aarch64 board ***scs is now known as Guest16313
<fnstudio>hi! :) to see whether a certain app comes from (from which package), i suppose one can do "namei $(which a-given-app)", is there a more guixy way of doing this? <lle-bout>nckx: it seems git upstream has solved their SHA1 key situation now, I have weak-digest SHA1 and their signature passed in refresh <lle-bout>cbaines: I just realized I kind of misunderstood your comment while replying to the MongoDB issue.. I squashed everything, you told to squash only some commits.. <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? <BostX>mubarak: I get the same error. Hmm. <ennoausb`> Hello. Is it possible to do a GUIX installation with static IPs? <ennoausb`> How can I set DNS server during manual installation? <ennoausb`>I am trying to install via guix-system-install-1.2.0 iso into a proxmox virtualizer ***scs is now known as Guest63903
<rekado_>BostX, mubarak: I can’t reproduce this. <apteryx>raghavgururajan: about linphone, sure! <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 <efraim>roelj: ^^ what I was going to say <efraim>lle-bout: no idea. hasn't it been broken for a while? <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>efraim: It wasnt on 20th of August 2020, but couldnt find a way to bisect since pybitmessage would spawn a window on success and that's blocking. <lle-bout>flatwhatson: I see thank you, I am thinking libvterm is performant but emacs-vterm buffer text processing etc. would be slower. <PotentialUser-69>In the handbook under Section 14 the command(s) to build from scratch are not mentioned. I only see the guix graph command to print the dependency graphs. ***stikonas_ is now known as stikonas
<cybersyn>i just thought up a terrible joke and figured y'all could be the perfect test subjects <abcdw>PotentialUser-69: guix pull && sudo guix system reconfigure <cybersyn>what nation of hackers prides itself on the worst currying? <PotentialUser-69>abcdw: I just looked at the Invoking guix system Section under the reconfigure Option. Your command does not seem to build from source? Or does it? <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. ***vup is now known as __vupbot
***__vupbot is now known as vup
<flatwhatson>Andrea has implemented a number of Elisp-specific optimizations, particularly type propagation, unboxing values, lots I can't think of right now. <lle-bout>flatwhatson: I see so the optimizations passes are the same as GCC's or you can customize that? Because obviously speed of compilation plays a big role here. <lle-bout>flatwhatson: oops you answered some of it already. Well thanks a lot for the info. I would be really interested in GNU Guile adopting libgccjit because of wider architecture support. <flatwhatson>I'm not familiar with Guile's new JIT, but yeah libgccjit *might* make sense on the output side to emit portable native code. ***scs is now known as Guest93585
<lle-bout>flatwhatson: GNU Guile's is an adaptation of GNU Lightning bundled in for GNU Guile's own purposes <lle-bout>wingo: ^ Now that Emacs uses it and has optimization passes also specialised for Elisp, what do you think? <lle-bout>efraim: that Tor upgrade is interesting, it didnt appear in any of my feeds, where did you get the information? <davexunit>need to double check but I think libgccjit was considered and found to not be a good fit <wingo>i haven't really considered it recently fwiw <lle-bout>davexunit: yes but since then there's been change <wingo>dunno. sounds like a great self-contained project for someone to work on :) <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 :) *jonsger tried that and didn't come far ^^ <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 <lle-bout>wingo: another thing it's that IBM POWER series processors are designed for SMP in essence so single-thread performance is worse off, JavaScript for example being mainly single-threaded suffers, even with JIT, what about GNU Guile here though? <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 <wingo>so, depends on your workload <lle-bout>wingo: Would you say GNU Guile's Scheme is suited for pure computational workloads? Or more so suited for combining I/O streams and sleeping on them while doing light stuff with them <wingo>lle-bout: depends on what your workload is. guile isn't fortran, but it's not python or ruby either. i would not hesitate to use it, fwiw :) <wingo>of course getting the best performance is an art <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>civodul`: you mean that I add the 2 sources? ***daviid is now known as Guest14771
<GNUtoo>(one for the vg and one for luks) <wingo>i would dearly like to rewrite the gc one of these days <efraim>lle-bout: it's one of the email lists I've signed up for <GNUtoo>civodul`: with (source (list "<vg-name>" "/dev/mapper/<opened-luks-device-name>")) it didn't work <GNUtoo>I'll try with only (source (list "/dev/mapper/<opened-luks-device-name>")) <GNUtoo>civodul`: it did wrong type to apply <joshuaBPMan>I've finally pushed a patch for an endlessh service: issues.guix.gnu.org/39136 <joshuaBPMan>Oddly though the issues.guix.gnu.org does not show the patch series. <joshuaBPMan>also said endlessh patch is probably slightly subpar. I'm not certain if syslog works for it. <joshuaBPMan>I was just wanted to submit something. I'm open to suggestions for improving the service. <roptat>joshuaBPMan, you need to let issues discover that, it can take some time <pinoaffe>hi folks, it seems like (recursive? #t) to input definitions does not trigger a rebuild - is this correct and is this intended behaviour? <GNUtoo>Is it supposed to work? If so in which conditions is it supposed to work? <GNUtoo>Does it really require an already booted system to work? or does it not support nested device mappers? <roptat>pinoaffe, if you don't change the hash, guix already have a cached result (although probably wrong) <davexunit>wingo: do you happen to have any Andy-approved GC-related literature that folks interested in such a thing could study? <pinoaffe>roptat: yeah I was expecting an "incorrect hash" message <roptat>no, because you already fetched something with the same name and same hash <roptat>so it's already in the store, guix will not try to fetch it again <roptat>that's what happens with fixed-output derivations <roptat>but you can change the first 0 to a 1 (or 1 to 0) and see that now guix will give you a totally different hash in the mismatch message <pinoaffe>roptat: ah right, thanks for the explanation! <wingo>i really enjoyed the ocaml result that a simple parallel stop-the-world collector can outperform a mostly-concurrent collector, while mostly preserving C compatibility <wingo>the gc handbook is really good tho; if you are interested in the topic you might want to order it :) <GNUtoo>It does the same for (source (list "<vg-name>" "/dev/mapper/<opened-luks-device-name>")) <davexunit>it would be interesting to demystify the topic a bit and maybe implement a toy gc <GNUtoo>(I didn't pay attention to the error before) <GNUtoo>I've retrieved and written down the backtrace <davexunit>looking from a distance C compat seems scary <GNUtoo>* (source (list "<vg-name>" "<opened-luks-device-name>")) <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? <bone-baboon>leoprikler: Is there somewhere else specific I should look in /var/log/ for more log information? <bone-baboon>Myon[m]1: I get the same result when the .xinitrc contents is "exec emacs" as when it is "emacs". <bone-baboon>Myon[m]1: What command should I run to check if I have a video driver installed? <bone-baboon>I have not explicitly installed a video diver. Working from the base packages I have installed xorg-server, xinit and some graphical web browsers. <roptat>if you didn't use a service for xorg, I don't think you have one that startx/xinit can use <roptat>not sure about the details, but I think the dm services also configure xorg with a set of default drivers <roptat>if you just install xorg in your profile, you don't have any configuration, and I don't think it knows where to read config outside of their store path's etc <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 <roptat>but you probably need a service to configure it, not necessarily a dm <lfam>People have, in the past, figured out how to use `xinit` "by hand" on Guix System <lfam>You might have to search the mailing list archives to see what they did <lfam>It might even be documented, not sure <leoprikler>the real X lives in $(guix build xorg-server)/bin/X <lfam>If it's not documented, it would make a great cookbook entry. Starting it "by hand" is still my preferred method <leoprikler>see also xorg-start-command from (gnu services xorg) <bone-baboon>leoprikler: I have been reading the manual section that has `xorg-start-command` but I do not know how to use it in my config. <leoprikler>but I'm sure one can set it up differently as well <lfam>apteryx: There are always more bugs in QEMU <lfam>"In rare circumstances, this flaw could be used by a malicious user to elevate their privileges within the guest." <lle-bout>apteryx: QEMU upstream is really bad and doesnt make security releases.. <lle-bout>Well they patch the issues at least, but investigating and pulling the fixes is troublesome <lfam>Well, it's also a misuse of QEMU to use it as a security boundary <lfam>I agree, I wish they would release more often <lfam>I have worked on patching QEMU many times and they don't make it easy as it could be <lfam>It's not designed that way, and it provides basically no security against the guest system <lle-bout>lfam: QEMU/KVM's threat model for most people is not that <lfam>I'm talking about QEMU specifically, not the KVM system <lle-bout>lfam: I think maybe this issue also affects QEMU/KVM? <apteryx>how does the linter gets educated about if a CVE has been patched? <lfam>I agree, we should fix bugs in QEMU when they are reported <lle-bout>apteryx: (properties `((lint-hidden-cve . ("CVE-2011-0433")))) <apteryx>I haven't used it, but the linter got it anyway (I used a patch named with qemu-CVE-[...].patch) <lle-bout>apteryx: I realized that too, I think it checks patch names <apteryx>maybe we should just use git checkout and tracks whatever commit is known to be CVE free. <lle-bout>apteryx: actually this would make it better for us.. <lle-bout>apteryx: e.g. vim has a release per commit <lfam>And Vim almost never builds successfully <lfam>Those can hardly be called releases <apteryx>OK, I managed to rebase it on v5.2.0 ***pkill9_ is now known as pkill9
<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. <apteryx>I wonder if other meson-built packages are affected similarly <lfam>Does that mean we have a qemu-only meson package now? <apteryx>seems we don't have many php packages available ***Guest14771 is now known as daviid
<roptat>I still have a pending patch series... I should give it some love <roptat>it adds a few packages and creates php-xyz.scm <roptat>I think we have only one, cat-avatar-generator <leoprikler>What's the rationale on (sha256 (base32 hash)) vs (sha256 hash)? <roptat>no idea, probably historic, and maybe also because we wanted to support more formats? <lfam>Se already so support multiple formats <dongcarl>Are there existing procedures to parse target triples? <leoprikler>there is at least a gnu-triplet <-> nix conversion scheme <leoprikler>but most of those parsers are pretty ad-hoc, sadly <bone-baboon>leoprikler: CPU: AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx <bone-baboon>How would I determine of my graphics card is supported by linux-libre? <lfam>I don't think any recent cards are supported <lfam>Not sure but that's my impression <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`? <lfam>Do you know the model number? You can find it in `lspci` <lfam>That looks like an Intel model number <lfam>Nothing by Intel is supported, sorry <lfam>linux-libre has very limited wifi support <lfam>Or, juse a different kernel <bone-baboon>lfam: So GPU: AMD ATI 05:00.0 Picasso is not supported? Does that mean that xorg will not work? <civodul>hmm there really is something wrong in the evening between the free.fr ISP and berlin <lfam>I don't know if it's supported bone-baboon <lfam>I don't think that X requires a graphics card, in any case <lfam>I use X and I've never had a graphics card <lfam>civodul: I had trouble accessing berlin, I think two nights ago. Something about the peering from that datacenter is not optimal <lfam>I do think it's unlikely that your card is supported <lfam>But, you need a graphics card expert :) <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..." <lfam>That worked after a couple days <lfam>I meant to write that, recently, I had something that I couldn't figure out <bone-baboon>lfam: I will look at putting something together to send to the help mailing list. <lfam>Sometimes, everything gets solved in one continuous IRC conversation, and that works too. But if the conversation is stalling, it can be more effective to create a linkable summary ***scs is now known as Guest97525
<leoprikler>bone-baboon: Sorry to say this, but your graphics card is very likely not going to work with the linux-libre kernel <leoprikler>h-node lists a similar one, that seems to work on Trisquel (without 3D acceleration), but that's the 3400G, not the 3500U. ***daviid` is now known as daviid
<leoprikler>that said, there is the faint possibility, that the two are similar enough for the latter to also work without 3D acceleration <charles`>is there a way to inspect the values of variables like %desktop-services? I'm thinking interactively at a repl