<vagrantc>Yay! i got sway running on the veyron-speedy (a.k.a. asus chromebook 201p) ! <vagrantc>and it's actually usable, unlike the last time i tried X.org <joshuaBPMan>vagrantc: I wonder why that is. I use sway, because everything else that I've tried in Guix didn't work so well for me. <vagrantc>well, this is an odd duck machine ... it is basically a bunch of quirks loosely held together with more quirks, and a few oddities to round it out <vagrantc>for example, the meta key is where the capslock normally is (and where the ctrl key *belongs*) <vagrantc>which means the usual tricks i get to put the ctrl key where i want it don't work <nckx>Is this one of those silly Googleboxes with a đ key? <vagrantc>nckx: ding ding ding! a prize for the clever nckx :) <vagrantc>it's pretty free all the way down, running libreboot <vagrantc>though a very old libreboot, as libreboot hasn't made a release since 2015 or 2016? and it's a pain to flash... <vagrantc>now just got to figure out why linux-libre 5.8 doesn't boot... <vagrantc>joshuaBPMan: yeah, sway works the way i want it to ... just bring me to a login prompt and then i run sway when i need to use the mouse for something :) *nckx finally rebased onto 5.8 today and fully expects something to break. I'll just never reboot đ <nckx>New shiny kernel is just for lookenpeepen. <vagrantc>new kernels are for virtual machines! linux 2.6 forever! <joshuaBPMan>Off topic question: anyone know of free software electronic payment methods? Perferably that can transfer credit card of debit card $$. <bavier[m]1>still being worked on. iirc they've had some neat developments lately. <bandali>you may also wanna ask pehjota, who runs Libiquity <joshuaBPMan>alextee[m] What does the FSF use on their site to coilect debit card stuff? <bandali>i seem to recall him being knowledgeable about payment processing <alextee[m]>and some custom credit card input thing, i wonder what that is <alextee[m]>bandali: does civiCRM come with a payment processing thing? <bandali>alextee[m], i think it has integrations with various services like paypal; i think <bandali>not exactly sure how FSF or CiviCRM process direct credit card info though <alextee[m]>i mean it has API so you can theoretically build your own semi-JS-free input thing <davexunit>bandali: fsf uses a payment gateway so they never directly store credit card info <davexunit>as of 2015 (last time I saw internals) it was not stripe <davexunit>my memory is fuzzy, it was one of the non-hip old payment gateways like firstdata or authorize.net <davexunit>and they wrote a custom civicrm plugin to integrate with it. <davexunit>but it's been many years since I've had access to the codebase. <joshuaBPMan>davexunit thanks! By the way I'm learning haunt. gnucode.me....It's pretty basic. <davexunit>I wrote a custom extension for their member benefits area. <davexunit>joshuaBPMan: it's a big ol' php monstrosity. <joshuaBPMan>Ahhh. Yeah. I am making WordPress sites for a while. Once you go scheme, you can never go back. <davexunit>I like to think that I'm a pretty okay programmer but navigating the civicrm codebase was hellish. <davexunit>I did a tiiiiny bit of wordpress way back in the day, that was not bad relatively speaking ***modula is now known as defaultxr
<joshuaBPMan>Hmmm. I didn't realize that civiCRM was that annoying to use. <davexunit>some people like it. fsf has civicrm meetups and some people go to it. lol ***catonano_ is now known as catonano
<davexunit>joshuaBPMan: but hey, nice haunt! glad you like haunt. <davexunit>that project is like a year overdue for a release... sigh... <vagrantc>nothing quite like booting an old guix machine and seeing how troublesome it is to bring it back up to date :) <joshuaBPMan>davexunit Thanks. I do know how to make a site look somewhat respectable...I've just got to learn haunt first. :) I'm actually copying your blog builder for now....obviously. Also, let me know if you wanna do a haunt coding session...Idk how much help I'll be, but I'll be sure to bring rocking music. And virtual cookies. <joshuaBPMan>vagrantc hahaha. I remember those days, Now I upgrade like everyday just in case. <vagrantc>this has been sitting in the closet for maybe 5 months ... and the time before that maybe another 6 months ***caleb_ is now known as KE0VVT
<bdju>I'm having an issue where launching emacs from wofi results in it not using my normal config, but launching from a terminal is normal. what would the difference be? I tried launching by the exact path from `which emacs` in wofi and it has the same problem. `emacs` or that path in terminal works. <bdju>my emacs may have updated recently so maybe it's a difference in environment between my shell where I updated guix and my login session <joshuaBPMan>bdju I haven't actually updated emacs yet...does the problem persist when you downgrade emacs? <bdju>I haven't tried a downgrade but it seems to be very specific to what sort of thing launches it. I tried in another shell I had open since a long time ago and it has the same problem as wofi, but if I source my shell config then it launches fine after that <bdju>so most things point to logging in and out probably being a fix, although that is a bit annoying and I don't understand what's happening exactly ***caleb_ is now known as KE0VVT
***caleb_ is now known as KE0VVT
<apteryx>hmm, any idea how this can happen? "guix build: error: derivation `/gnu/store/z8c3ls6cm77xdrmz2gr8dmcgyhxd6wln-linux-4.19.142.tar.xz.drv' has incorrect output" <apteryx>I'm playing around with the make-linux-libre-source, so that's probably caused by me, but what can of mistake can cause this? <apteryx>I was trying to use (base32 hash), where hash is passed as an argument. <apteryx>ah no, better than this, I had simply omitted a hash variable somewher... sorry for the noise. <lfam>apteryx: Funny you mention it, I am taking a look at that stuff too <apteryx>bdju: Emacs relies on EMACSLOADPATH to find its Elisp libraries <apteryx>lfam: I have the diff almost ready with upstream linux-libre releases from their git <lfam>I was considering changing it to make sure that only the correctly-versioned deblob scripts are used <lfam>So that we don't miss any changes <apteryx>you mean using the scripts from their git release tree instead of grabbing them from the http server? <vagrantc>lfam: as in using the full version, rather than just major+minor? <lfam>I was doing the simplest thing, which is to pass the linux-libre-N-version variable to linux-libre-deblob-scripts, and to not truncate the version number <lfam>The tarballs are deblobbing now... will be a while <lfam>Trying to tune the parallelism <apteryx>is there any parallelism to have? I think the deblob scripts are strictly single threaded for now. <lfam>I tried running one per core but only had 50% utilization <lfam>It's better now with 2.5 per core <apteryx>I was running something like this: ./pre-inst-env guix package -A '^linux-libre$' | awk '{ print("linux-libre@"$2) }' | xargs /gnu/store/xi84y4mp8zwrnxl0skqczp9iaf8ilqp5-profile/bin/time ./pre-inst-env guix build -S <lfam>I am using a large --max-jobs for the guix-daemon, sometimes I reduce it interactively <lfam>Anyways, this change I'm testing is just a short-term thing. If it's better to fetch from Git that's fine as well. I wonder how using Git in more parts of this would affect linux-libre-headers-5.4.20. The comment says it used in the bootstrap process <vagrantc>apteryx: when i made a simple attempt at switching to linux-libre git ... it re-downloaded the whole git history each version and produced a huge store checkout <vagrantc>apteryx: are you doing something more clever to reduce that impact? <apteryx>nope. Are you sure it's failing at doing a shallow checkout? <lfam>It's really only practical with shallow cloning <vagrantc>well it was trying a shallow checkout ... was still quite expensive as compared to downloading a compressed tarball <apteryx>eh, did the hash change for linux-4.19.142? hash mismatch for store item '/gnu/store/3spw1k850mrcskrldqcfa7cnhgwmp4kp-linux-4.19.142.tar.xz' <apteryx>vagrantc: how many MiB? That lz tarball needs to be decompressed anyway. <apteryx>I'll pay attention to it a bit later, when I have the basics working <lfam>As I feared, the load ballooned 𤌠<lfam>apteryx: Or perhaps a wrong hash is being considered? Or wrong file-name? <vagrantc>the store will possibly save some space with hard linking as some files across versions will be identical <apteryx>vagrantc: the decompressed linux 5.8.3 tarball weighs more than 1 GiB. <apteryx>but thanks for pointing it out, I'll monitor that aspect <vagrantc>it was noticeably slower to download ... at least an order of magnitude for me <vagrantc>maybe because git makes more smaller requests and thus more overhead? <vagrantc>i just remember when i tried it, i was thinking "this will never fly ..." <apteryx>git takes some time on the remote to compute what it's about to send, but other than that, it's pretty fast <apteryx>perhaps their server had some bandwith issue or something. When I tried it was saturating my link. <vagrantc>i think there are also git mirrors for linux-libre ... <lfam>They could set up the Git server to generate and cache snapshots <vagrantc>so could maybe configure a mirror:// for it? <lfam>Maybe, by now, there is an implementation that is deterministic <apteryx>vagrantc: even if it was really slow, after we've got the tarball generated ourselves, most people will get it as a substitute <vagrantc>also, i tried getting softwareheritage.org to mirror the linux-libre git, and it never materialized <apteryx>they appear to be picky. They also don't host tarballs, unless that changed recently. <vagrantc>yeah, softwareheritage.org supporting git was one of the reasons i thought it made sense to switch to git :) <samplet>It will take a while before it works, though.... <apteryx>lfam: ok, the hash mismatches were my own mistake(s) <bhartrihari>Hello, is somebody working on packaging sourcehut for guix? *raghavgururajan fixed playing of media (including HTML5 video) in epiphany <apteryx>lfam: I'm building the linux-libre sources with my latest additions; if it looks good, I'll refresh the patch set I've linked to earlier ***caleb_ is now known as KE0VVT
<vits-test>"However, note that package transformations are lost when upgrading;" -- OK, i'll use --manifest after pull. This way 'profile upgrading' and 'system reconfiguring' are similar. Right? <efraim>vits-test: sounds about right, in that they're both declarative and you get exactly what you want <vits-test>`guix weather --manifest=manifest.scm` cool. <jgart[m]>Does anybody happen to know of any example configs demonstrating guile shepherd wrappers around systemd? i.e. I'd like to declaratively manage/wrap systemd on a foreign distro from shepherd. Would this be the right way to do it? <vits-test>Hello jgart[m]. blackbeard[m] have worked on make the systemd units useable by shepherd. It's all i heard close to this topic. <str1ngs>vits-test: they are profile generations. if you want to clean them up do guix package -l to list them and guix package -d to remove them <str1ngs>then you can gc them if that's what you want to do. keep in mind you will not be able to roll-back if you delete the generation. <vits-test>str1ngs: but why ouput of `gc` isn't `sort -u`? <peanutbutterandc>It seems that while `alsa-lib` and `alsa-plugins` are different packages, ALSA lib conf.c expects to find `alsa-plugins`-shared-objects inside 'lib' under an 'alsa-lib' subdirectory within alsa-lib's 'out'... <peanutbutterandc>It is looking for libasound_module_conf_pulse.so in the wrong place. It should have been looking for it in a separate /gnu/store/hash-alsa-plugins-version directory... or something <peanutbutterandc>If anybody wants to look into it, the package is `tuxguitar`. If you build it as-is, you will get an error about libasound_module_conf_pulse.so not being found where it is supposed to be. A quick look at the package definition will show that the `alsa-plugins` is, indeed, not listed as an input. <peanutbutterandc>However, if one adds it as an input, the issue and builds, the issue still persists. <vits-test>peanutbutterandc: there are similar things for some sdl-dependent packages. For those there is 'sdl-union'. Maybe alsa has something like this too? <peanutbutterandc>vits-test, I can seem to `guix show sdl-union` nor can I see anything like alsa-union... <vits-test>peanutbutterandc: sdl-union used in package descriptions, but i didn't found the alsa-union. <vits-test>peanutbutterandc: (arguments `(#:extra-directories ("alsa-lib"))) <peanutbutterandc>vits-test, Oh wow.... sdl-union... oh wow. That is quite clever. Very clever indeed <vits-test>Two clever thoughts: first is to separate each package to its own directory... second is to unite some of them back! <vits-test>peanutbutterandc: IDK what this thing is, though. <brendyyn>When I add (setq guix-load-path "~/guix") to my emacs I get this error that breaks emacs-guix File mode specification error: (error Device 1 is not a termcap terminal device) <bluekeys>hey vits-test, I hope you are well, good to see you again *vits-test "what have we done!? pure elves freely roaming the #guix, being polite; no swearing. vengeance!" <zzappie>any guix-ocamlists here? I'm trying to package frama-c and got stuck at why3 library that requires ocaml-num. Configure script complains that there is no Num library even though PATH, CAML_LD_LIBRARY_PATH, LIBRARY_PATH etc all point to ocaml-num I'm just curious whether ocaml requires extra handling in relation to libraries <vits-test>zzappie: Hello. Try add ocaml-num to propagated-inputs. <zzappie>I think I found the problem. Configure script has hand-written part that finds Num <zzappie>So probably need to substitute* something <roptat>zzappie: I think I have a package for flamand-c <roptat>I thought I had a more recent attempt <zzappie>roptat: Hey! Thanks. Your package falis with compiler error :) <vits-test>lads and lasses: gnu-classic, inuit... ROPTAT! <roptat>zzappie, so I totally forgot about these patches ^^' if you manage to fix frama-c, that'd be great :) <zzappie>roptat: haha :) i'll make a try on the weekend. After looking closely at frama-c and why3 they seem much bigger than they apear at first <nckx>guix(){ case "$1" in tetris) command guix environment --ad-hoc bastet -- bastet;; *) command guix "$@";; esac;}; echo Good morning Guix. *nckx .oO We don't have a non-bastard version of ncurses tetris? Time to package one. <nckx>vits-test: Can't you ask you text editor's upstream to add a Tetris clone? That's the right place to put it. <vits-test>nckx: BTW, i failed to boot in non-"generic" linux-libre on this board. <vits-test>No. Monitor is a black screen. I didn't looked in serial console, out of lazyness. <vits-test>As "generic" worked, so.. why unscrew again? <nckx>Have you tried the new & improved -generic? IIRC the freezer patch was merged. <vits-test>nckx: I didn't pulled yet to that version. From patch, as i see, the only change will be FREEZER config. Others are already there (at least now). <vits-test>Currently i run almost same kernel as in 450dcd1aff741c4f81cc9508ce33f19e62edefb7 <vits-test>btw, nckx: in recent conversation, nly said we can use some already present tools to use p2p with `guix`. Like, share a store via torrent. People can download needed files. Then `guix archive --something`. <vits-test>"and that digital signature is appended" oops. <nckx>Well, the plan was always to use existing tools... Like GNUnet or IPFS (or torrents, I guess, although I don't know if it's a good fit). You can't share the store using bittorrent but you could share static parts of it. <nckx>Using nars (âguix archiveâ) and signatures is probably a given, although last time I heard about IPFS there was talk about using a more ânativeâ format. That was quite a while ago and I forgot most of the salient points. <vits-test>efraim: i see, in many places: (string-append "CC=" (cc-for-target) <mothacehe>vits-test: It is when you are building for your host architecture, it differs when cross-compiling for instance. <mothacehe>In that case you can have CC=aarch64-linux-gnu-gcc or so. <nckx>efraim: I found a functional Haskell one, might package that as my first Haskell package today. Might give up crying! Who knows. <bluekeys>Is anyone using vterm in emacs? Care to share your setup? <vits-test>bluekeys: M-x term. With working less. Thanks, i didn't knew it's there. <mothacehe>hey civodul! Oh, interesting, didn't know about that one. However, definitely better than my raw /proc/*/maps search to find process to kill. <mothacehe>In the meantime, I'm preparing an update of the patch serie with a fork+exec-command/container method that uses container-excursion, as you suggested. <mothacehe>Resulting code is .. less horrible to watch :p <vits-test>bluekeys: M-x ansi-term is better: i can C-o from it. *vits-test `guix search fuck` actually returned one package. It's depends on go and python. *vits-test on SBC: guix install thefuck # FFS, indeed (potentially compile python and go) <mroh>bluekeys: I use vterm in emacs sometimes, but I dont have any emacs setup for it, should work out of the box, no? <stikonas>Aurora_v_kosmose: well, it's not just SBCL that is non-reproducible... There is more stuff that is non-reproducible in Guix <nefix>how do you run dbus in Guix? <nefix>I've added 'dbus-service' to the services definitions, but virt-manager doesn't seem to find the socket <nefix>(internal error: Unable to get DBus system bus connection: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory) <nefix>though there's a file there named the same <stikonas>I don't remember were you can find the statistics but if I recall correctly it was even double digit percentage of packages that is not reproducible <Aurora_v_kosmose>*that Guix had some clever hacks for packages that didn't turn out that way elsewhere. <lfam>Guix has the tools to enable and test for reproducible builds, but we don't enforce them. The idea is that that is the responsibility of the upstream developers <Aurora_v_kosmose>I see. With some leniency in cases where upstream simply can't do it. Like with SBCL-compiled images/packages. <lfam>I'm not sure what you mean â we are always lenient on this subject. We prefer the packages to build reproducibly but, if they don't, that's okay. We won't remove them or anything like that <lfam>It's seen as something that's "nice to have" <lfam>We have done some things to make it more likely that the packages will build reproducibly, and even sent patches upstream <apteryx>lfam: I think reproducibility is is a bit more than a nice to have, otherwise we wouldn't open issues about it on the tracker. It's a goal to be 100% reproducible, and when contributing new packages, it's expected that we do the homework to verify whether the package is reproducible, and try to fix it if it isn't (putting upstream in the loop if something need changing on their side). <apteryx>But you are right that it doesn't block inclusion. Just wanted to stress that it's important :-) <Aurora_v_kosmose>Right. I would imagine in this case that once the compilers get fixed the rest would just naturally follow. <lfam>Yes, it is important. But currently not feasible to require :) <lfam>There are often issues in the build scripts, as well, Aurora_v_kosmose <lfam>And for certain programs, reproducibility may not even be desirable. For example, software that is supposed to be high-performance should be compiled for the CPU it will run on, not a generic platform. That's a use case that is not really addressed by our efforts so far <Aurora_v_kosmose>lfam: In some build systems the case is worse than others. ASDF tends not to carry as much. <Aurora_v_kosmose>lfam: As for CPU-specific flags, I'd think someone should customize their package definitions if they want that. <lfam>civodul: Ah! Well you are by far more of an expert in the area of HPC :) <lfam>The run-time feature detection is a good way to deal with it <civodul>Guix uses the same software as everyone else, but that often means that performance sensitive code has multiple versions <civodul>Aurora_v_kosmose: no, it's just that algebra software or things like glibc, mpv, libgcrypt, etc. selects at load time the "right" version of the CPU at hand <Aurora_v_kosmose>civodul: Huh. How do they do that? I know how to do so at compile-time, but run-time? <civodul>Aurora_v_kosmose: the post has the details :-) *Aurora_v_kosmose slowly reading through it <bluekeys>mroh: I was AFK, yak-shaving. I'm using use-package and am being told that i need to install cmake to compile vterm-module <bluekeys>I have installed emacs-vterm. I assumed everything needed would be included <Formbi>maybe your Emacs reads a vterm from elpa or something <Formbi>remove such a thing if you have it <mroh>bluekeys: try to remove the use-package, just M-x vterm and it should work, because it's already autoloaded (with our emacs). <Formbi>that way you can have the configs and not download other variants <simendsjo>lfam: Ref my "edit command not found" when running `guix edit` - yes, it seems like it was because EDITOR couldn't be launched. I used `--pure` for `environment`, and thus didn't have anything other than guix (and deps) available. Quite cryptic error message though. <lfam>simendsjo: I'm not sure if it's Guix's fault or the system's fault in this case. I do know that "permission denied" and "command not found" can be really misleading on GNU/Linux <lfam>They are overloaded and should really be overhauled <bluekeys>I'm on a foreign distro, the penny has just dropped, I' running its version of emacs, I'm not sure it is loading modules from guix <lfam>simendsjo: If you haven't already, it would be helpful if you filed a bug report about the confusing error message. Maybe we can fix it <mroh>bluekeys: on a foreign distro, with a foreign emacs, vterm is indeed more complicated, because you need the vterm-module.so in a place where your emacs finds it. <stikonas>nckx: yeah, it might be this. Well I didn't really remember exact numbers, I had an impression that it's worse. But I guess that's good news that it's better than I remembered <nckx>It's certainly gone down over the years \o/ <simendsjo>lfam: Tried to reproduce it, but now I get "sh: emacsclient: command not found", which is clear. Not sure how I got "edit" instead of "emacsclient" earlier. <civodul>do we need to promote Android with a top-level module? :-) <civodul>kmicu: heh fun, they list Debian and Guix--what else? <nefix>I've added 'dbus-service' to the services definitions, but virt-manager doesn't seem to find the socket <nefix>(internal error: Unable to get DBus system bus connection: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory) <nefix>how do you run dbus in Guix? <kmicu>nefix: are you on Guix System or Guix, the package manager on a nonâGuix System distro? <nefix>on a `guix system docker-image` built system *civodul learns about NON-BREAKING HYPHEN and wonders <apteryx>civodul: eh, about android-repo-download, the file has been worked on since 2014, but was only recently added? Is that correct? <civodul>could be, or maybe the file includes other code of mine <civodul>it's like "svn-download" and all that <nefix>kmicu: forgot to mention you before <civodul>yeah so all these files have similarities (not a good sign...) <apteryx>yeah, all the downloaders are very similar. I wouldn't carry the copyright lines for a new file though; that's more confusing than helpful, even if the file is heavily based on another one. <kmicu>nefix: do you have anything returned by âenv | grep DBUSâ, âpgrep -a dbusâ, and âls ~/.dbusâ? <kmicu>NONâBREAKING * are useful to keep Guix System together. <kmicu>Especially on fediverse and Tik Tok. <kmicu>Emacs sometimes highlights those glyphs so we could easily spot rad folks. <nefix>the first command didn't return anything <kmicu>nefix: what if you source envars from that session file and then try to run virtâmanager? <nefix>kmicu: which is the session file? ***caleb_ is now known as KE0VVT
<kmicu>nefix: cat /home/dev/.dbus/session-bus/d897d0aef2f90f15d2b938455f4f7ab9-0 <Formbi>I guess there is some bypass option <civodul>uh, people: if you reconfigure, you'll have to do: sudo herd eval root "(reload-module (resolve-module '(gnu build shepherd)))" <nefix>kmicu: it doesn't seem to work even with the ~/.dbus variables sourced manually :/ <civodul>joshuaBPMan: due to a very recent change, the introduction of fork+exec-command/container <civodul>Aurora_v_kosmose: key servers are not used; instead, keys are read from a branch of the repo <joshuaBPMan>civodul I could make a "news" item if you like...I can't do it now, but possibly tomorrow morning. <Aurora_v_kosmose>civodul: Ah good, that solves that problem in a probably more reliable way. <civodul>joshuaBPMan: actually it's only if you "herd restart guix-daemon" <civodul>i've send a message to mothacehe, we'll see <joshuaBPMan>reconfigure followed by a reboot will solve everything? <kmicu>nefix: what about âdbus-test-tool echo' ? Maybe virt-manager is not properly packaged. <nefix>but maybe it's because I'm running it inside a docker <nefix>even with the --privileged mode <nefix>but at some point I managed to make it work >:( <kmicu>nefix: do you try to run virt-manager (and dbus) inside a container? <nefix>and it's possible! (I did it some days ago, and I also do it with alpine!) <nefix>what do you mean with that emoji? xD