<vats>I'm a baby schemer as of now. Much more familiar with Common Lisp. <solene>vats: no (loop ..), no :tag, strictier macros :) otherwise it's not that different <leoprikler>quick run-through, you'll be using (guix transformations) to replace the propagated input found in the one by the one in the other <leoprikler>I should go to bed now, I'll have to wake up early tomorrow. <solene>vats: and if you do scheme, the syntax and libraries may slightly change dependning on the implementation you use, which is tricky... If you use guile it will work for guile but maybe not for other (certainly not) <vats>Ah. Thank you so much leoprikler. That clarifies a lot. ***sneek_ is now known as sneek
<vats>solene: I see. I could never get used to loop in CL anyway. <civodul>vagrantc: that leaves you until the next release, which is not scheduled yet :-) <drakonis>hmm, what's lined up for next release at this point? <solene>vats: I'm pretty sure loop macro in common lisp is turing complete :P <civodul>drakonis: nothing! but there've been discussions on guix-devel <drakonis>i'm always wondering whether ambrevar's work will finally make into a release <civodul>i don't think i've seen patches though? <drakonis>yeah, service searching was part of it too, right? <drakonis>okay it wasnt part of the nlnet work he was doing <civodul>yeah i remember that, but AFAIK, it never materialized :-/ <civodul>yeah, i don't know what happened to the grant <drakonis>there was a recent email by ambrevar regarding file searching <drakonis>so i suppose it has to be going somewhere? <cbaines>I think some of the remaining work around file searching was creating/updating the database <cbaines>I've had ideas around filesearch for a while, and I hope things like the Guix Build Coordinator and/or subscribing to the Guix Data Service will enable some of those things <civodul>the Data Service is in a good position to do that IMO <drakonis>oh there's even a recent one by ambrevar <ss2>hi! I'm not quite sure if I've nailed my problem quite right yet, but the recent kernel is very unstable for my laptop. I haven't tested it on other hardware yet. <drakonis>civodul: it seems to still be happening, thankfully <ss2>but now I downgraded to 5.10.39, which seems fine now. <ss2>I've got an error message or two, but I think I might need some more testing to get more messages. <ss2>the quickest way to provoke a freeze would be to invoke an rsync, moving a 30GB file, which would hang after a minute or two. <ss2>It's a virtual machine, which I've moved back and forth several times. It's fine. <ss2>it hasn't got to do with the file though. with the current kernel, any user process that is heavy on the disk would eventually freeze the sytem. <ss2>spent the whole day with this, installing the system. Funny thing is, that any guix related job would never fail. <ss2>only user related. Should it be loading the browser, emacs desktop session, or networking.. <ss2>then, there's something else I've noticed on this fresh system: tramp hangs, while it spawns an sh instance, that sits at 100%, until it finally responds. <lfam>ss2: Did you look for related bug reports in the kernel bugzilla or other distros? <lfam>Or in QEMU (or whatever VM you use)? <raghavgururajan>> vagrantc: the problem with xmpp is that people who are too excited about matrix will balk at it, and the problem with matrix is that the people who are happily using xmpp for ages will balk at it *raghavgururajan is a XMPP person <lfam>I'm seeing a large number of duplicated grafting derivations while updating my profile <lfam>For example, 4 different grafting derivations for webkitgtk <lfam>I don't know what's going on but it seems suboptimal <lfam>Maybe some part of the dependency graph has forked somehow due to package variants <raghavgururajan>jackhill and roptat: Regarding Qt apps, may be Twinkle? Or Psi/Psi-Plus? <raghavgururajan>nckx/cbaines/civodul: IIRC, users don't have to have xmpp account to join a chat. <oriansj>raghavgururajan: emacs is probably the big limiter here. Because IRC has erc in emacs. What would an emacs users use to do xmpp in emacs? <roptat>ok, had a bit of troubles to connect with nheko, it forced me to use SSO, which didn't work, but clicking on connect before it can remove the password field worked... <achow101>`guix challenge python` is telling me that it differs. is this expected? <raghavgururajan>oriansj: Ah I see. I saw somewhere that emacs can use gajim as backend, to connect to XMPP. <oriansj>raghavgururajan: no first hand experience? <mange>I've used Emacs Jabber before. It's pretty bare-bones, but it's quite usable. I can't really remember using it with MUCs, though. ***iskarian is now known as Guest6944
<jackhill>raghavgururajan: thanks for the infromation about the gajim integration ***iskarian is now known as Guest9180
<jackhill>bone-baboon: ☝ someone recently made me aware of an emacs-jabber repository with more recent commits recently <drakonis>why is it that clang-toolchain has a cc/c++ symlink but gcc-toolchain does not? <jackhill>drakonis: there was a mailing list discussion about that, but I can't offhand remember the outcome or even which list it was on, sorry! <bone-baboon>jackhill: Do you have a link for the emacs-jabber repository you mentioned? ***sneek_ is now known as sneek
<jackhill>drakonis: I see, I guess we'll have to ask civodul :) <raghavgururajan>I use Gajim (even this message), but don't have experience with emacs. ***lukedashjr is now known as luke-jr
***rovanion1 is now known as rovanion
<solene>is it possible to ask guix to display the url that is used to download sources for a package? <solene>I suppose I can add -n to not do anything :-) <civodul>ah but it won't display URLs in that case (and it wouldn't know what to display because URLs are chosen dynamically) <solene>my point was to get the url to download, compare checksum to what upstream provide, and use guix hash to put into the store <solene>guix build something -v2 | grep // | head -n1 maybe <mange>solene: Isn't that essentially what Guix does already? It compares the hash of the download against the hash in the package definition, so if you just want to make sure it matches upstream you could use "guix build -S $package" to get the source, then do your own checksum (after it's already in the store). <solene>mange: if the checksums differs from the package definition, guix will stop and delete the file <solene>I don't know if -S make a change about this? <mange>Right, okay. Do you currently have a package that's failing to build because the sources aren't what Guix expects, and you want to download the source yourself and get Guix to use your downloaded sources instead? <solene>mange: no, it's because I'm updating packages <yoctocell>Is there a reason for not generating Texinfo docs from the docstring of procedures in all the (guix ...) modules? <soheil>Is there a way to solve this problem? <solene>it seems the test is trying to run on port 8080 and it says it's already in use <solene>trying to shutdown what run on that port may help, or the test step should be fixed to not do that <yoctocell>The build happens in a container so maybe it doesn't have access to the port? <soheil>Anyway, it would be good if you send answer to these pages to solve the problem of these two people; Thanks <ss2>lfam: I haven't yet. Will have a look. <solene>it's missing gsettings-desktop-schemas in inputs <civodul>yoctocell: re docstrings: i think the manual and docstrings serve somewhat different purposes; the manual gives context, examples, etc., which are usually missing from docstrings <leoprikler>yes, but there might be some (small) convenience issues when using it <projectmoon>I'm technically the maintainer for Element desktop on Void <projectmoon>Though it's been quite a while since I've done any maintaining <leoprikler>just some weird exceptions flying around if you don't use the correct arguments on the command line <leoprikler>also flatpaks don't seem to integrate too well into the system, but that's probably on them <leoprikler>If none of that turns you off, go ahead and `guix install flatpak` <solene>it works fine for me, but for example firefox can't be registered as a default browser but I'm fine with that <chikamungus>Hi all. More emacs related woes... I have installed emacs-guix and i <chikamungus>...and the packege is in the load-path, however, according to the docks, I should be able to now just m-x guix but the command is not found. Any ideas? <leoprikler>I further assume this is within the context of EXWM? <yoctocell>civodul: that's a good point, but not metioning them in the manual makes it harder to know that something exists. For example, I only just discovered (guix http-client) because I am writing an importer for CHICKEN eggs and looked at other importers to get an idea of how to start. <chikamungus>Just noticed my spelling. I really shouldn't ask sailors for advice <leoprikler>yarr, mate, have ya tried addin the contents of site-start.el to yar .exwm <pkill9>is there an alternative build system to make, cmake, etc that uses guile? <leoprikler>chikamungus: I guess site-start.el runs before your packages are added to load-path, so you'd have to load it once more or otherwise include the blurb that says "here, generate me all autoloads" <pkill9>i should just learn to write a configure and makefile <leoprikler>(when (require 'guix-emacs nil t) (guix-emacs-autoload-packages)) <leoprikler>I don't understand why you're missing site-start.el then <chikamungus>ooh I had (require 'guix-emacs nil t) but not the rest <chikamungus>the only thing that isn't a symlink to a package directory in there is subdirs.el <chikamungus>I'm not following you. I am a fluffhead though. I'll add the incantation you showed to my init.el. Thank you lots leoprikler <leoprikler>there should be a site-start.el next to the subdirs.el <projectmoon>Thinking of installing guix and configuring it in a VM I'm preparation for real hardware. Then just take config to real hardware once I get it. Does this make sense? <civodul>yoctocell: true1 i don't have a good answer to that, other than "we should document more things in the manual" <civodul>i had forgotten about Potato Make, fun! <Rohit>Hello, is this official guix irc channel ? <nckx_>I hope you weren't misled anywhere. <leoprikler>sneek later tell chikamungus: In that case it's likely you have emacs installed system-wide (i.e. /run/current-system/profile if you're running Guix System), so you need to refer to that instead <leoprikler>projectmoon it does make sense in some case, but the VM obviously can't check for hardware incompatibilities <leoprikler>I suggest keeping the most minimal config.scm, that you can work with around just in case you have to deal with issues related e.g. to the GPU, that would still allow all else (most importantly file-systems) to function properly <leoprikler>then you can `guix init minimal.scm`, reboot to Guix on metal, `guix pull`, `sudo guix system reconfigure desired.scm` <leoprikler>if generation #2 fails to boot afterwards you can go back to #1, make changes to desired.scm until it fits and redo <leoprikler>trust me, it's a lot less headache than running init over and over :) <projectmoon>leoprikler: it'll be a librem 14. So it Should Work 🤔 <leoprikler>In that case, you might be on the safe side. Guix folks are at least working on Librem, but I don't know the current status of it. <projectmoon>Well I assume all the necessary drivers are already present <leoprikler>If you want to get an estimate of whether it will work h-node.org might be a good resource. <leoprikler>Otherwise if someone within this channel uses a similar setup, they'll surely tell you. <projectmoon>Yeah. I should in theory have the laptop in a few weeks... Maybe... <munksgaard>`guix import hackage -r futhark`, is what I meant. <munksgaard>Huh, it seems like there are plenty of problems like that reported already on issues.guix.gnu.org <nckx_>munksgaard: The error I get doesn't look related to #36690. Here it complains that version is #f, i.e. it's missing or Guix was unable to extract it. <pkal>Hi, does anyone know if the situation with Guix has improved on the Pinebook Pro since last year? <dstolfa>bone-baboon: yeah... i realized my error ~10 minutes ago :) <dstolfa>i was trying to find logs and asking around until people pointed out to me that it's in a few hours <nckx_>/join #fsf ‘you need to be identified with services’ -- what a day to lose my bouncer. <abcdw>Few weeks ago geiser started to missbehave. Updated it to latest version. C-c C-k evals buffer correctly, but if I do C-c C-c or similar eval of one or few forms it throws an error. It can be fixed by switching current REPL's module, but it's not convinient, when you work in few different modules at the same time. Am I doing something wrong? <mjw>nckx_, yeah, it seems the fsf is slightly late here. Having a discussion on freenode while most people have already left... ***apteryx_ is now known as apteryx
<zap>abcdw: I'm not having this problem. Geiser and geiser-guile were updated recently in guix btw <nckx_>mjw: It's just a very FSF thing to do. <civodul>abcdw: i noticed issues quite recently <civodul>for example, C-c . u (from Emacs-Guix actually) fails with: <abcdw>zap, evaling subform happens in the context of currents repl module, not current file's module. Some guys from my local community have the same problem <abcdw>civodul: I workaround evaluation issues by switching repl's module with C-c C-a, but it's not very convinient. <abcdw>civodul: BTW, have you had time to try out Guix Home? <yoctocell>abcdw: Why was commit 1009d9ae262c611ae3b338be26f745bfee120665 reverted? In what way did the rde channel fail to build? <abcdw>I could reconfigure too, but guix pull was failing, give me a minute, will send you an error message <pineapples>Hi! Does anyone know why there's a discrepancy between an amount of free space on a zstd-compressed partition, reported by `df -h' and an amount of space (in GiBs) freed up by `guix gc -F'? In my case, to free up 11GiB of disk space, I had to `guix gc -F 20GiB' <dstolfa>yeah, FSF is just very slow at these things <civodul>abcdw: not yet unfortunately! getting closer... *dstolfa is itching to move to guix but still needs to sort out a few issues before he can <civodul>abcdw: it can try it as a channel, right? <pineapples>However, when I ran `guix gc -F 11GiB' and then `compsize -x /', the latter reported 11GiB of disk space being free. Is Guix somehow compression-aware? <zap>abcdw: really? I thought it's a normal behaviour. I always C-c C-a'ed to repl :) <nckx_>‘guix gc -F <N>GiB’ always deletes far less than N GiB here too. If I run in several times it always deletes more. I'm installing compsize now... <nckx_>compsize -x / → /etc/rpc: SEARCH_V2: Bad file descriptor <nckx_>They are trying to compete with Guile on the error message front. <nckx_>From what I can tell, compsize is btrfs-specific(??). <nckx_>munksgaard: Interesting, thanks for digging. <nckx_>‘Common stanzas can import other common stanzas’ — across packages? <nckx_>pineapples: I use lz4 compression on / and noticed the same thing. I can't believe the daemon is compression-aware. I think it's more likely a bug that happens to roughly match up with your compression ratio. <efraim>pineapples: I found that compression from the guix daemon is about 3-to-1 and compression from zstd is about 2-to-1 <munksgaard>nckx_: I'm not sure. My guess would be no. I've submitted a new bug report with the additional information. <nckx_>efraim: Compression from dedup? <civodul>abcdw, yoctocell: i got: guix pull: error: could not authenticate commit 416dba8bfc347775bc8e53bfc1c84c364028e76a: key 0158 61E3 2C8A E7E4 84CA 4233 ACF5 0999 A2FB 5C79 is missing; am i missing something? <efraim>i'll run compsize on my store and post the results <munksgaard>nckx_: My bugs are not showing up on issues.guix.gnu.org though. Perhaps I just need to wait a bit for some moderation to take place? <nckx_>munksgaard: Your not in moderation and that wouldn't affect the Web UI anyway. Your mail is just lost in the FSF's mail dungeons. It'll come out of the other end within seconds or hours. <nckx_>Is there a clever way to calculate file system compression without using compsize's ioctl? <efraim>apparently my store is very big, it's still calculating <abcdw>civodul: probably I didn't sync keyring branch with github repo. Now I did it and both repos should be ok, but git.sr.ht is a main one. <apteryx>civodul: hi! Would you set my pw on overdrive1 to something; I'd like to strace the running sshd. <yoctocell>abcdw: The problem was that I made a typo in (gnu home-services xorg). <nckx_>pineapples: What you describe sounds consistent with Guix being completely *unaware* of transparent file system compression. <nckx_>E.g., df -h says you have 5G free. You run guix gc -F 20G. Guix looks at df once, then proceeds to delete 15G of uncompressed data. It never checks df again. It exits, claiming to have freed 15G, whilst df reports only 10G free now because those 15G compressed to 33%. <pineapples>nckx_: Oddly enough, the amount of disk space that guix frees up matches disk usage reported by compsize <roptat>if it deletes 1GB of files that are also hard linked from somewhere else, df will not report any change <nckx_>Because when you run guix gc -F 11G with 11G free, it has up-to-date df info and decides to delete nothing? The disparity only accrues during GC. <civodul>anyone has a cluster-like Guix setup, where clients talk to the daemon with GUIX_DAEMON_SOCKET=guix://somehost? <civodul>i'm seeing weird perf behavior, but i can't tell where it comes from <pineapples>roptat: Perhaps, but as the end user I expect that the result of running `guix gc -F 11GiB' is that `df -h' and `btrfs fi usage /' report 11GiB of free disk space <nckx_>Because Guix subtracts uncompressed $FILE_SIZE from its internal ‘I need to free this much’ counter, without checking *actual* df numbers (which would be lower) after each file. So Guix's idea of how much it's freed diverges more and more from the actual free space when you use compression. <pineapples>If this is not a bug, perhaps this should be documented? <nckx_>Only if btrfs fi usage and df report the same number. <nckx_>I'm not saying your expectation is wrong. I'm saying why Guix fails to fulfill it. <nckx_>A quick fix would be to check the actual free space, as reported by df, after deleting each store item. <pineapples>Ah. Okay. Sorry, I think I need to re-read everything to comprehend what has been said <nckx_>Or I made a mistake somewhere ;-) Thinking about transparent compression too much does my head in. <nckx_>Even the btrfs devs themselves got it wrong on several occasions. <pineapples>All things considered, I still induce you to run `compsize -x /'; it'll only make everything more confusing than it already is, I promise :') <nckx_>FWIW, I agree that your DWIM expectation is the more reasonable one and just as easy to implement without having to be aware of compression at all. <nckx_>pineapples: compsize doesn't support my file system. <nckx_>Or my file system does not support it. <nckx_>SEARCH_V2 was tailor-made for btrfs, I have no idea if it's well designed. I guess we'll see. <nckx_>OK, so s/tailor-made/straight-out exposes btrfs internals so any file system implementing it will have to share or emulate those/ :-/ <pineapples>nckx_: I see. Either way, I wouldn't be bothered by this discrepancy, if it wasn't for the fact that I intentionally leave a fixed amount of free disk space on my main drive so that the SSD doesn't slow down due to an exhaustion of free space or something (it's said that modern drives do not require this treatment anymore, but I do it anyway) <nckx_>I'll open a bug when I'm sure my understanding is correct (that ‘guix gc -F N’ is really just a dumb alias for ‘guix gc -C (N - $df)’). <pineapples>nckx_: Thanks a lot! I lack the grasp of `guix gc' to open one myself; though, I doubt anyone would bite me for simply sharing my expectation from the end-user's POV, rather than also provide technical information on how to solve this <nckx_>Could somebody merge bugs 48414 and 48260? <nckx_>I don't like calling people end users. I had the same expectation as you; it's simply a bug; I just didn't care. :-p <nckx_>Care enough to wade through C++ that is. <lfam>Can I get op on this channel? <nckx_>You've had secret powers since the 20th. ***ChanServ sets mode: +o lfam
***ChanServ sets mode: -o lfam
<lfam>solene: I just sent comments to your gnutls patch submission. We're almost done! <solene>lfam: nice, do you have an example of this in the packages? I also have an issue with the file local.mk (IIRC) that contain the list of all the patches, should I also remove the patches in it? <lfam>The only change that is required for the gnutls package is to add a replacement field. The patches will not go anywhere <lfam>But, in general, when creating or deleting patch files in the distro, they have to be registered or unregistered from gnu/local.mk <solene>lfam: as I removed them, my guix stopped building because of this file <solene>should I redo the patch to update gnu/local.mk or add another commit? <lfam>You should simply discard that commit <solene>this file is not documented in the manual :( <lfam>`git reset --hard origin/master` <lfam>Sorry, it's something we learn by doing :) <lfam>solene: Please let us know if you have more questions or want advice <nckx>Thanks. Let's never fight again. <solene>lfam: I don't understand why you say I should discard the commit. In the gnutls update commit I also removed useless patches, it is done. I have to make a new commit for the graft thing. So, I can add a new commit for the graft + fixing gnu/local.mk in the commit. Or I can drop my existing commit to make a new one including the graft + updating gnutls + not removing patch files <nckx>Low-budget VPS hosting is the best VPS hosting. <solene>if the patches files are not required, I don't see why we should not remove them <nixo>Hi guix! Something strange is going on with julia. I had to re-install guix today (because of a disk failure) and julia won't run, throwing: "ERROR: Your CPU does not support the CX16 instruction, which is required by this version of Julia! This is often due to running inside of a virtualized environment. Please read https://docs.julialang.org/en/v1/devdocs/sysimg/ for more." <lfam>solene: "Or I can drop my existing commit to make a new one including the graft + updating gnutls + not removing patch files" <-- This is what you should do <lfam>The patch files are still required by the 'gnutls' variable. They won't be required in the 'gnutls-3.6.16' variable <nckx>nixo: Which CPU is that? Were you previously successfully using the same version of Julia? <solene>lfam: ok, I understand now, this make sense to me <lfam>solene: The reason we use a graft here is to avoid changing the derivation of the 'gnutls' variable <nixo>nckx: hi, yep it's the same X200 I've been using for the past ~4 years <nckx>And the same Julia version? <lfam>solene: (It will change if you do `guix build --derivations gnutls`, but not if you do `guix build --derivations --no-grafts gnutls`) <nixo>cpu is Intel(R) Core(TM)2 CPU P8600 @ 2.40GHz <lfam>I can also give tips about how to check if the graft "worked" or not <nckx>Then the Julia build is probably auto-detecting newer CPU features on the Berlin build farm. <lfam>Maybe we should have a blog post: all about security updates <solene>lfam: that would be fine! indeed <solene>or in the documentation or the cookbook <lfam>I remember offering this at the Guix Days skillshare, and people looked at me like a talking lizard :) It was too quotidian for the Guix Days <lfam>Everybody else's skill was much cooler <nckx>nixo: You could build julia locally, by uninstalling it, running ‘guix package --delete-generations=0s’, and running ‘guix gc /gnu/store/*-julia-*’. If that works, run ‘guix environment julia -- true && guix install julia --no-substitutes’. <nckx>guix gc -D /gnu/store/*-julia-* <nckx>I knew I'd make a typo somewhere. <jackhill>lfam: there was a good email by Léo about the process they used (at least for going the the CVE lists) that would be cool to get documented in a more perminent place. <lfam>I'm thinking more about "how to graft" and "how to make sure the graft works" <nixo>nckx: thanks I'll have give it a try later, as it takes ages to build julia <nckx>lfam: Maybe, but I wonder how many of those lizardlookers would have been able to answer a basic quiz about all your experiences. <nckx>nixo: Yeah, that's the trade-off. <lfam>I was a little sad but it wasn't about me <civodul>lfam: i'm all for the howto on security updates! <lfam>It's clear that security updates are not something that everybody is excited to do <lfam>We all have different things that make us happy <civodul>precisely: let's turn it into something exciting :-) <lfam>I'm not sure I can do that <lfam>I can at least demystify it, I think <lfam>It's only exciting for those of us who enjoy maintenance and cleaning <civodul>of course we could have a monthly "best grafter award" <lfam>No! We already have too many grafts :) <nckx>Does lfam have the shelf space tho. <lfam>It takes longer to graft than to download things when doing `guix upgrade` these days <jackhill>lfam: ah, cool, yes I would happily read such documentation <lfam>Anyways, I'm going to write the quick guide on "testing the graft" now *lfam copies and pastes the neat "cut here" thing from somebody else's email <nckx>lfam: You don't use emacs? <jackhill>speaking of: would anyone like to review https://issues.guix.gnu.org/48573 botan crypto library update? The release notes don't mention security fixes specifically, but it's still probably one of those things that's good to keep up to date. Especially now while it doesn't have too many dependents :) ***lfam is now known as lfam-vim
<nckx>Yes, emacs is such an up & coming new thing. <lfam-vim>I just mean I started with something else <nckx>Well look at you now, copying and pasting. <lfam-vim>On the other hand, my CTRL key is not in danger of wearing out <jackhill>I actually had a keyboard where the CTRL key did where out. I don't think it was emacs though … later on the e key wore out. <civodul>nckx: look at you, killin' and yankin'! <lfam-vim>Oh, before I go for real. I'm going to give my opinion in the FSF / GNU discussion on "where to IRC", today on the freenode channels at 13hrs NYC time <lfam-vim>I think we can still have a voice there, if we want <nckx>Oh right, I can /join again. <projectmoon>so i'm testing guix in a VM. downloaded the binary firefox, and it says no such file or directory when executing firefox from the command line o_O <nckx>I'll see you there, although I don't have anything to say yet. <nckx>projectmoon: It's a classic misleading error. It's because you're missing /lib/ld-linux-x86-64.so.2, which is hard-coded by pre-built binaries, and which Guix lacks. <projectmoon>and i suppose there's no smart way of getting that file <nckx>Guix doesn't support running them out of the box, but there are hacks like patchelf that let you change the location of libraries & the linker/loader, or you add (extra-special-file* "/lib/ld-linux-x86-64.so.2" glibc) to your system configuration & mess around with LD_LIBRARY_PATH to point firefox to the other libraries it needs. <nckx>The extra-special-file is that way but it's only the first step. *nckx also has to step AFK. ***lfam-vim is now known as lfam
<ix>Maybe he's right, maybe I should switch to guix <ix>But I did try and I missed flakes immediately *roptat should learn more about flakes <roptat>I've heard they're like channels here, but not sure what they do exactly <ix>Like channels, but pure and more composable <roptat>"pure" in the sense they depend on a specific commit of other flakes? <ix>Yes, as a tree, down to leaves, and locked formally in a file that is part of the repository/flake <ix>So you can revert a commit to go back in time <ix>Even if you've "guix pull"'d <civodul>"locked formally" is like "guix describe -f channels > channels.scm" <civodul>channels can have dependencies too, perhaps that's similar to what you describe? <lfam>Does anyone have an example of a package that depends directly on OpenSSL and that is very cheap to build / does not have many dependencies? <abcdw>roptat: There is a pure evaluation mode in flakes enabled by default, which prevents accessing anything outside of you current flake (git repo) or flakes declared in the inputs of current flake. I had a introductionary stream on this topic: https://youtu.be/98EwejpIJzE <lfam>roptat: Good choice, but bad for my article, since the similar names will confuse readers <rekado>lfam: r-rserve is another example <abcdw>ix: BTW, channels+inferiors seems to cover 90% of what flakes do. The setup process is a little more involved, but still managable, maybe later I'll experiment around with some nicer API + tooling for managing lock files and outputs to get more flake-like experience in Guix. <ix>abcdw: yeah, you're the third person I've seen say that now :D <lfam>On second thought I might not participate in the discussion on #fsf freenode. It's already a torrent of bullshit <ix>abcdw: would be appreciated though! <ix>I'm tempted to make the switch now drakonis <ix>drakonis: nixos moving to matrix pisses me off, frustration at nixpkgs, and guix might now actually be big enough that I won't risk losing all my packages. I was already on the verge of switching, guix is nearly unilaterally better, just held back by the whole flakes thing. Flakes are such a tidy and nice experience <apteryx>civodul: is overdrive1 managed via 'guix deploy' ? <ix>solene: less anally pure, which in some contexts is freeing. Uses a nice and well established language, which is refreshing. Development seems less pained (even if its not on github), which pleases me. The OS doesn't use systemd, which is a petpeeve of mine so rather happy about that. There's better toolage for new packages, which seems tidier than the nixpkgs way. And y'all don't use goddamn matrix <lfam>Maybe we'll use matrix in the future, I don't know <lfam>Using IRC instead of Matrix is not a particular value of the Guix project <drakonis>civodul: say, why does clang-toolchain have cc/c++ symlinks but not gcc-toolchain? <ix>Downsides; no flakes, and there's a worse repl experience, but thats it really <lfam>It's more a matter of history <ix>lfam: appreciated, but its more the straw that broke the camels back tbh <ix>I've hated nixos for months now. Its a traumatic relationship <civodul>drakonis: it's a long story; in short, "gcc" is getting special treatment because it's a close relative of Guix :-) <drakonis>i needed it to build some opam packages that explicitly look for the symlink <civodul>but not just Guix really: build systems are used to looking for "gcc", not so much for "clang" <civodul>apteryx: nope, it manually reconfigured when needed <civodul>only the x86_64 build machines are managed via 'guix deploy' currently <apteryx>civodul: OK! Trying to 'guix pull' on overdrive1, I get: guix pull: error: while creating symlink '/home/maxim/.config/guix/current': No such file or directory. <drakonis>i'm keeping clang installed just for the symlink, for the time being. <drakonis>needed to install owl and it needs ocaml's eigen bindings ***stikonas_ is now known as stikonas
<ix>So, I'll switch my local machine to guix first, for sanity's sake <ix>But the nice thing is "profiles" make that easier <ix>Make all the programs guix-based, then just port the services with a system definition <ix>Its actually not hard to do piecemeal <civodul>apteryx: i think that's an old 'guix pull' bug (because you're running an old version) whereby you had to "mkdir -p ~/.config/guix" <nckx>dstolfa: Go ahead, thanks for asking. <nckx>If I'm blocking you let me know. <ix>abcdw: I wonder if it'd be possible to just dump channels.scm as part of every commit, so its somewhat versioned, as a stopgap solution <solene>on battery MATE is asking me regularly to type my root password to change the brightness, this is extremely annoying. Nobody has this issue? <nckx>solene: Definitely heard that complaint before. ***efraim is now known as efraim-desktop
***efraim-desktop is now known as efraim
<nckx>soheil: ‘guix pull’ gets the latest upstream Guix. solene's patch isn't upstream. <nckx>You have to build Guix from git to test it. <nckx>I'll test it and push it if it works (should be a formality). <abcdw>ix: Probably `guix describe -f channels > current-channels.scm` should serve your needs. After that you can do `guix pull -C ./current-channels.scm && guix WHATEVER --args` or `guix time-machine -C ./current-channels.scm -- WHATEVER --args`. <soheil>nckx: Yes it is true, I wanted to tell the news of the new comments. <jackhill>ix: that's interesting to hear about the REPL experience. Having not paid too much attention to Nix, I didn't even realize they had a REPL, and was blinded by the assumption that of course lisps have great REPLs :) <ix>jackhill: it was one of the first things I tried. I use it extensively in nix, have special attrset hooks just for it, and even have it plumbed into emacs <ix>As far as I can tell everythings still "possible", just less neat <apteryx>civodul: that indeed fixes it, thanks <jackhill>ix: yeah, for me there are two aspect to it, there is the REPL mechanics, and then how good the programming interface is. I think we could improve the latter. <nckx>I give up. It doesn't matter anyway. I'll push solene's patch shortly. <jackhill>My impression is that on the whole we could use more high level abstractions for common tasks. But first, we have to identify those common tasks by more people using it more :) <abcdw>civodul: I have to go now, but if you get any problems with or questions about Guix Home let us know in rde-discuss/rde-devel mailing list. Will appreciate any feedback. <ix>jackhill: I can help with the last bit :p <jackhill>I recall a discussion here in the past where I said I was interested in adding some recipes for using the programming interface to the cookbook. I haven't done that yet, bit it hasn't lost its attractiveness to me. <drakonis>when is it time to merge guix home into the main tree? <abcdw>ix: guix have a good repl experience, but sometimes geiser missbehaves. <civodul>the new publications page of the website uses new Haunt features, which breaks the web site's build process <ix>By the way, is SRFI-110 usable? <civodul>more of a question for #guile tho :-) <jackhill>wisp is 119, and I think Arne is acvtive in Guix, so there's probably more energy around that :) <abcdw>drakonis: ix: We only proposed to start a new guix-home branch for moving Guix Home from rde repo to guix repo. Idk how much time it will take. https://lists.sr.ht/~abcdw/rde-devel/%3C871raw856c.fsf%40trop.in%3E We also have activation refactoring and one more feature to finish before upstreaming. Also, need to get more feedback from other maintainers on what they think on Guix Home. <civodul>oops, i just removed all my profile generations due to a trailing "-d" on my "guix package" line <nckx>soheil: Pull. Update! Enjoy. <ix>civodul: see, reasons to want flakes :') <civodul>abcdw: bye! i'll let you know what i manage to do! <lfam>Time to test your backups civodul! <civodul>lfam: it's just that i can't rollback, like anyone using a "normal" distro, not the end of the world ;-) <civodul>(the current generation is still here of course) <civodul>i had "guix build -m ... -d", then i replaced "build" with "package", and here i am <civodul>ix: i'm not sure flakes are good to the point they avoid PEBKAC problems, are they? :-) <lfam>I figured it was something like that. The -d is tricky! <ix>Nono, but you can backup your repo online, and then the profile history being part of the flake and not just floating in /gnu means its a bit more solid <lfam>A good reason to use long options ;) <ix>I never treat profiles as anything but ephemeral in nix <ix>So I can kill them on a whim <drakonis>where is the guix website repo even hosted anyways? <lfam>Can whoever is discarding the spam on guix-security please set it to discard all future messages from that domain? <lfam>I keep trying to do this, but somebody else is discarding it before I notice <nckx>lfam: Did I miss *which* domain? (Wasn't me, for the simple reason that guix-sec wasn't on my moderation checklist; I've added it now.) <lfam>I count 4 emails trying to sell us marble / stone <lfam>All from the same address <nckx>We should check our configuration. <nckx>By which I mean, I will. <lfam>I mean, unless somebody wants some marble <nckx>I've added the domain to the blacklist. This is the first time I've used Mailman's regex syntax, we'll see. <nckx>lfam: Truthfully, I recently sold some marble. Do you want to censor me too? What if I want to inform the security team about future sweet marble deals that might occur? <lfam>My bias against marble is showing <lfam>Better remove my op powers <nckx>Also, marble, not as profitable as you think. Reconsider, Chinese friends. <drakonis>idk, cole was checking it out a while back after i tried to convince him <drakonis>(i think i succeeded but he didnt show up here after the move) <ix>he's gone full matrix I think <nckx>I mean, popcorn budgets might be impacted, but otherwise: not. <lfam>It doesn't affect us at all <nckx>I care because I care about the FSF, but if they point the gun down & pull it won't hurt us this time. <guix-guest>Hi 👋🏻 I’m new to guix system I really appreciate your great effort as a pure free software <guix-guest>Currently I’m using guix system and I use gstreamer ecosystem heavily <roptat>🍿 let me contribute to the popcorn budget :) <lfam>guix-guest: That's cool that you are using GStreamer <lfam>Are you interested in sharing what you use it for or how you use it? <guix-guest>I think there are missing packages like gst-rtsp-server <lfam>I use FFmpeg at my job (live video) but I'm interested in exploring GStreamer <lfam>I'm not sure if anyone in Guix is using GStreamer for work, or work-type stuff <guix-guest>I simply use it for client side application using vala programming language <guix-guest>Is the step by step to contribute for add missing packages for Gstreamer? <lfam>I guess it's similar to adding any other package. Just make sure to use the same version as the rest of the GStreamer packages <lfam>We can help you through the process <guix-guest>I need step by step guid because Im new to guix and guile too <guix-guest>Currently during COVID19 I’m free at home so contributing to make guix system better and better :) <lfam>I recommend beginning with that Packaging Tutorial, and coming here if you have questions or get stuck <apteryx>civodul: seems like the inferior attempts to write a system-error exception with message "Broken pipe" <apteryx>but the port being broken, it's read on the other side as an EOF <pricly_yellow>Hello, guix. Anything changes for building packages on the tree procces? I can't build new version of package, guix download substitute for older one. <lfam>It sounds like you need to redo `./configure --localstatedir=/var && make` <lfam>I'd guess you deleted the development dependencies with `guix gc` since you last did that <lfam>So, `guix environment --pure guix` and then `./configure --localstatedir=/var && make` <lfam>The behaviour you describe sounds like the case I describe <pricly_yellow>Thank you, try to call make, manual do not mention it for running guix on src tree <lfam>It says to run `make && make check` <lfam>You have to do what it says in that section if you want to use pre-inst-env <dstolfa>for those interested, the matrix bridge to libera is up and running <dstolfa>roptat: i think you just connect to channels with @channel:libera.chat or something along those lines. i'm not sure as i'm not using it but i see a lot of people from matrix show up <jonsger>hm, installing via graphical installer doesn't work with 1.3.0 in the Hetzner Cloud :( <cbaines>does it try and use EFI? I think the Hetzner machines I've got running don't use EFI <jonsger>ah yes it tried to use EFI and offered a pretty strange partitioning (efi and boot/bios partition) <jonsger>cbaines: what is the mount point for a BIOS partition on guix? never did that before <maximed>Also, spammers, please send your mail to verdacht@safeonweb.be. Thanks in advance for your cooperation! <lfam>Seems unlikely that Belgium will be able to do anything about spammers from China <lfam>But, I'll forward you the email <cbaines>jonsger, I'm not sure what you mean, but the target in the configuration is just /dev/sda (at least for the VM I'm looking at) <lfam>Please don't report me for spam maximed <jonsger>cbaines: I'm in the graphical installer, so I don't need to set a mount point <maximed>lfam: Unlikely, yes, but safeonweb adds links in spam to blocklists. And I guess they have the right contacts to add phishing sites and such to the DNS blocklist. (Well, at least the one for Belgium) <lfam>I'm not sure if what I forwarded to you will include the headers <lfam>So, it might not be useful <maximed>lfam: It includes some juicy domain names (and name of the company, presuming it's actually a real company) <maximed>(I don't think it's phishing, just spamming, though I didn't (and will not) look at the website) <jonsger>cbaines: didn't worked. Will have a look on another day... <jonsger>seems like the bootloader part is still the most difficult and difficile part of the Guix installation process, at least for me... <lfam>Later today I'll try again installing Guix System on my Macchiatobin <lfam>The BIOS and bootloader have been the hardest parts by far <apteryx>civodul: overdrive1 is physically reachable to you right? Meaning, I can experiment without fear with SSH (should I do something dumb and cut my link) :-) ? <lfam>The Macchiatobin uses Tianocore / EDK2 / UEFI for the BIOS. For config.scm, does I use grub-efi? Or just grub? <lfam>I tried building the installer image for aarch64 but had some trouble <lfam>I seem to have misplaced my notes about that :( <lfam>Anyways, there was something about the installer OS declaration that is x86-only. I tweaked the code to remove that, built the image, flashed the USB, and it failed to boot <nckx>maximed: Will do! Currently dinnering. <nckx>Wait, is there still a question? :) <nckx>Is what lfam sent sufficient? <lfam>solene: Let me know if it makes any sense <solene>lfam: sure, I'm not sure I'll have time to check that tonight though ;) ***lukedashjr is now known as luke-jr
<bandali>thank you drakonis :-) tried my best <nckx>I was enjoying fine foods and unable to attend but I hope it wasn't too bad. As an (emeritus) doer: was it at all productive? <bandali>nckx, i think it was pretty productive, and went better than expected in ways! <nckx>Oh, that's really great. <nckx>Yes. The unmoderated pre-discussion was terrible. <dstolfa>bandali: out of curiosity, do you know if #trisquel has moved/will move? <maximed>nckx: What lfam sent appears sufficient. <nckx>‘<Noisytoot> justJanne, Libera has a Matrix bridge’ — that's (good) news! <solene>is there such a program like "steam-run" on Nix (not realted to Steam itself) which allow to run a "normal" linux binary like in steam-run ./firefox.linux ? ***lukedashjr is now known as luke-jr
<solene>I had a trick a few years ago to reset LDCONFIG_PATH and use ld.so to run a program but it's not really nice and practical <nckx>I'm not aware of such a script. ***lukedashjr is now known as luke-jr
<lfam>How did we install Guix System on the Overdrives? Did we use `guix system init` from another distro? <andreas-e>Yes, I think so. At least that is what I did on dover, probably following others' lead. <nckx>It wasn't a coordinated effort. They came with OpenSuSE. I wiped the hard drive, then booted a Debian or Fedora live ISO and installed Guix from there. Others borged the existing distribution without wiping /. <lfam>I have a running Debian. Maybe I can `guix system init` from it and then delete the leftovers afterwards <lfam>andreas-e: Do you remember if you did it from the installed OS? Or did you do it from a live ISO? <lfam>drakonis: I know that I can try it. I'm wondering if it will work <drakonis>the cookbook has an example on how to do it with linode <lfam>It will work if it works <drakonis>i've done it from an existing debian install. <lfam>I'm concerned about the /boot partition being handled properly. I know that one can run `guix system init` from another OS and that something will occur <lfam>I'm asking for specific advice about UEFI aarch64 systems <nckx>lfam: Can't you add storage, put Debian on *that*, etc.? <lfam>Yeah, I could. It's already installed and working <lfam>But, porting the Cuirass worker and its associated services to Debian is too hard <lfam>I guess it doesn't matter if the existing OS is borked <lfam>I don't know what you mean <drakonis>having to put up with the bureaucracy is the hardest part <lfam>I don't think we are talking about the same things <nckx>The whole ‘replace the running distro’ is a cool party trick but... meh, I don't know. I'll never deploy such a system myself. You can almost always find a better way. <lfam>I'll try booting a Debian ISO and doing it from there. It's just such a drag to install Guix on a USB-backed ISO <lfam>We should get the Guix System installer working on UEFI aarch64 systems for the next release <lfam>Uboot systems, we can punt on those <nckx>I've never had an existing Debian installation so the experience was quite similar. Either a new OEM Debian to which I need to apt stuff & build Guix, or a live environment to which I need to apt stuff & build Guix. <drakonis>i want to go for a live environment for running debian instead <lfam>My options for USB / external storage are very slow <drakonis>flip the situation around and be able to successfully build a rescue usb using guix <lfam>So, booting the USB-backed Debian live ISO, installing Guix, running `guix system init`, it's going to be slow <lfam>But, it sounds like that's what I have to do <nckx>If you're lowish on RAM it will be. <drakonis>you can install it directly on the OS and do system init <lfam>Hopefully the kernel will do the right thing <drakonis>i have succeeded at installing on a running system <lfam>I guess I'll try that first drakonis <lfam>If it fails then I can try doing it from the ISO <drakonis>you might want to move the data out of the way first *roptat shows off his shiny new cloak :) <nckx>drakonis: You can replace another OS in-place with ‘guix system init’, it's just that the result is full of old OS left-overs and always a bit dodgy. <drakonis>nixos, afaik, has a file it checks on boot that automates the process <drakonis>it moves everything into a folder and then proceeds with setting up the system <drakonis>it isnt very elegant, but its what they did <nckx>I don't understand what you're saying. Do you have a link to said script? <nckx>If you're running an OS, you can't move it out of the way... <nckx>Does it reboot into a pre-Nix that moves the old OS, then installs Nix for real? <drakonis>having NIXOS_LUSTRATE on /etc/ tells the scripts that they should move everything not written down in the file into a directory <nckx>That is very inelegant indeed. <solene>the guix weather command is interesting <vagrantc>lfam: on (nearly) all my aarch64 Guix Systems i installed Debian and then used "guix system init" onto a separate partition <drakonis>its for in-place installs in the least elegant manner <nckx>It's so dirty and hacky and... oh the cool things we could do 😛 <nckx>☝ that is cool, although the real magic isn't really in the lustrate part. <drakonis>well, all those cool things can be done because guix has a different approach to things <lfam>vagrantc: Do you think it has a chance of setting up the bootloader properly if I do it onto the same partitions? <lfam>I don't have another disk / partition available <nckx>drakonis: I meant ‘the cool things we could do if we secrecly copied that’, to be clear. <vagrantc>lfam: it's certainly a chance it will work, but likely leave some cruft behind <vagrantc>lfam: i'd scrounge up a way to have some free space if you possibly can <nckx>drakonis: Thanks for pointing me to it, it seems to have happened (just) after I jumped ship to Guix. <drakonis>there are a couple things still worth taking from it <lfam>I have the space. I guess with btrfs it's easy to shrink filesystems and redo partitions <drakonis>but in general its gotten pretty stagnant since that happened <drakonis>i will admit that the one nix family member worth taking from, is what xiden has been trying to do <drakonis>one interesting nix thing that was built during the period flakes were developed that never went anywhere was the command "nix run" <drakonis>which would use flakes for defining metadata for launching applications <solene>emojis are not rendered (I have a square with 6 hexa numbers in it) in Dino, is it something that can be fixed by adding an input? <rekado>solene: probably by installing a suitable font and updating the font caches. <drakonis>there's a lot of room for using it as means to attract more users <drakonis>however there's always the caveat related to the kind of people that it might draw in <ix>drakonis: I thought guix pack was similar at first <drakonis>guix pack is more like a archive generator <ix>But it generates self-sufficient pack..ages? Modulo that thing you need to run them <dstolfa>does guix support TL WN812N (i think it's rtl8192eu) out of the box? <lfam>I don't know for sure but it's unlikely <lfam>You really need to stick with atheros 802.11n (ath9k) <dstolfa>alright, ath9k it is, i'm not maintaining a driver <lfam>Debian has a different set of standards for this stuff <nckx><But it generates self-sufficient pack..ages? Modulo that thing you need to run them> What's it, ix? <ix>nckx: I can't remember, don't you know? <nckx>Free out-of-tree drivers are fine, we have plenty. <drakonis>it can generate them not unlike how nix does them <ix>nckx: ah, singularity <ix>`guix pack --list-formats` <dstolfa>lfam: thanks for the information, i think i'll find an ath9k just to be sure <drakonis>i do like how easy it is to add more formats <drakonis>thank goodness for the design ethos behind lisp based applications <nckx>ix: It sounded like were talking about ‘guix pack’ but that doesn't describe Guix packs, so maybe you mean Nix, I don't know either :) <apteryx>anyone knows why downloading OS images in gnome-boxes doesn't work? <nckx>Guix packs don't need anything to run. <ix>nckx: they aren't binaries <ix>The supported formats for 'guix pack' are: <ix> tarball Self-contained tarball, ready to run on another machine <ix> squashfs Squashfs image suitable for Singularity <ix> docker Tarball ready for 'docker load' <drakonis>you have to do some extra stuff for executing it atm according to the docs <philip>aptery: I think someone needs to submit a patch to libosinfo now that we have an uncompressed .iso <drakonis>nix has a appimage-ish experience when generating self contained binaries <ix>`nix run` is a real convenience <ix>I literally just used it <drakonis>but hardly anything uses it and it isnt ready for prime time yet <drakonis>it currently assumes that the binary that has to be run has the same name as the package <ix>As an alternative, nix shell 'blah' -c realname <drakonis>regarding not being ready for prime time is that it is missing a lot of useful features it could have <ix>But thats just guix env <nckx>ix: ‘Guix packs don't need anything to run.’ ‘they aren't binaries’ is moving the goalposts by several blocks. <ix>drakonis: actually the apps don't have that requirement <ix>E.g. I do `nix run '.#delta'` in my flake <nckx>You could add a trivial self-extracting wrapper script around the tarball if you care about that. <ix>Which does not run ./delta <solene>is it possible to find which package provide file foobar.so.4.0 ? <ix>drakonis: its just nix run <nckx>I was just looking at hosted Web IRC clients... for $reasons... <nckx>...it's written in PERL! <rekado>I *still* encounter self-extracting tarballs with Perl wrappers <rekado>for some reason this practice has survived the cold winters of the 90s <rekado>of course only proprietary software <rekado>(they probably also think that nobody will realize that this “installer” is really just a wrapped tarball) <nckx>This reminds me of gzexe. I loved gzexe. <nckx>rekado: I remember them well, although I encountered more shell scripts. <ix>rekado: even that would be better than a dry tarball or the singularity thing ***iskarian is now known as Guest2656
<nckx>Now *that* is the universal executable. <nckx>ix: What is your beef with tarballs? <ix>It's just a pointless indirection, not slick at all. I wanted something like nix run, not nix export. No shade on tarballs themselves at all <nckx>Self-extracting executables are the pointless indirection. <nckx>‘Decompression is so cool, let's pay this penalty on every single invocation.’ <vagrantc>if you have fast CPU and slow disks, it's not really a penalty <solene>is it possible to uise guix package -u and tell it to not build if there is no subtitute available? <vagrantc>yeah, fail-on-missing-substitutes is a long-requested feature <dstolfa>has anyone seen https://deb.trendtechcn.com/? this looks like it's fully free but the drivers are not in mainline. i'm not sure if any firmware is requried, but given that they support trisquel i assume there isn't any <dstolfa>would perhaps be worth packaging if it is fully free? <vagrantc>there are also some hooks out there to basically wrap around guix pull and pull to the most recent generation that has substitutes for a given profile or something <nckx>vagrantc: <if you have fast CPU and slow disks, it's not really a penalty> Only if you add caching. But it's less obvious then, true. <nckx>dstolfa: If it's free it's welcome. <drakonis>it works significantly better than in nix due to not abusing wrappers like it <nckx>dstolfa: Do you have such a device? <drakonis>the most painful thing about nix is dealing with language ecosystems in there due to everything being designed with the assumption that you'll run a function to coerce the packages into an environment with them <dstolfa>nckx: i don't, but i might buy one. i've emailed them asking about firmware and if their installer works on guix (it's GPLv3) <dstolfa>if it does, i'll probably get one and give it a good test. if it's satisfactory, i'd be happy to package it up <vagrantc>dstolfa: evaluate the source code first; it may contain obfuscated code or binary blobs <ix>drakonis: I mean sure I just don't see any convenience whatsoever from guix pack, whereas nix run I actually end up using day-to-day <vagrantc>dstolfa: that might block it from being includable in guix <ix>Thats the only reason I have reservations <vagrantc>dstolfa: the fact that they distribute source code only as a .deb is ... not promising :) <drakonis>so, let me tell you about how simple it is to add a new format to guix <ix>I believe you, but nobody's done it, so $shrug <dstolfa>vagrantc: yeah, i've emailed them about these concerns already so i'll just wait to see what they say <apteryx>philip: good, that's one thing (the Guix iso missing from the list), but there's more; trying Debian netinst i386 (or anything else) fails to produce anything <dstolfa>it looks somewhat promising, so it's probably worth pursuing <drakonis>ah yes, before i forget, debian has guix packaged, thanks to vagrantc <drakonis>so the process of setting up guix is very simple now <drakonis>on the other hand, the nix package is in terrible condition :| <nckx>dstolfa: ...that is a lot of code. <ix>Nixpkgs is a dumpster fire <nckx>I was not expecting this much code. <drakonis>some of it could stand to be moved into a library <dstolfa>nckx: i'm looking into it now as well <nckx>I was talking about the driver dstolfa linked to. The source is offered only as a .deb, so that was a great start. <drakonis>dumpster fire might not be the right expression here <drakonis>you forgot to append radioactive dumpster fire <vagrantc>dstolfa: at least one of those drivers references firmware that isn't free <dstolfa>vagrantc: hmm, how the hell do they claim to support trisquel then ***jsoo_ is now known as jsoo
<nckx>vagrantc: ...could you elaborate? <vagrantc>os_dep/linux/os_intfs.c:char *rtw_fw_file_path = "/system/etc/firmware/rtlwifi/FW_NIC.BIN"; <vagrantc>os_dep/linux/os_intfs.c:char *rtw_fw_wow_file_path = "/system/etc/firmware/rtlwifi/FW_WoWLAN.BIN"; <apteryx>has anyone managed to build QEMU on ARM? <nckx>Yes yes, I ran the same grep. <chikamungus>trying out emacs-guix: it looks lovely, however, when I tried to get it to list installed packages, I got this error: guix-geiser-eval: Error in evaluating guile expression: While executing meta-command: <sneek>chikamungus, you have 1 message! <sneek>chikamungus, leoprikler says: In that case it's likely you have emacs installed system-wide (i.e. /run/current-system/profile if you're running Guix System), so you need to refer to that instead <apteryx>it seems to hangs in the test suite at 20% <vagrantc>nckx: weather it does anything with that, who knows <drakonis>ix: i do certainly hope to help solving any issues you might have <apteryx>chikamungus: hmm, yeah, emacs-guix is not very much maintained these days, which is a shame. But at the same time until the performance problems of Geiser are fixed it wasn't as useful at it could be. <chikamungus>leoprikler: I installed emacs in my personal profile and guix-emacs runs but see above <drakonis>installing to your profile is a supported use case though <drakonis>so it might be a lot less painful than trying to copy nix run <chikamungus>that is a shame - it has favourable mentions on the web <ix>drakonis: oh I'm not actively wanting nix run, I was just musing. Guix environment will suffice where I need similar <nckx>dstolfa: Because supporting Trisquel does not imply abiding by Trisquel's rules. <nckx>Software doesn't have to be FSDG-free to run excellently on Guix. <dstolfa>nckx: yeah but how do they get the firmware in if it's needed <ix>I was perplexed by guix pack when I looked into it cause I was expecting a runner <nckx>dstolfa: It's a kernel module, it can do whatever it likes. <nckx>I'm not saying it loads firmware, but there's nothing stopping it. <Noisytoot>FSDG-nonfree software can't run excellently, because it's not excellent (for freedom) <dstolfa>oh yeah, i mean it could do anything in theory, but i wonder if it does anything malicious here <dstolfa>i'll wait for their response, then bring this up <apteryx>git am gives me 'error: corrupt patch at line 71' for the first patch at #48622; anyone else? <nckx>Loading the firmware to make the thing work isn't malicious. <vagrantc>dstolfa: i wouldn't rely on their response; it needs to be independently audited <nckx>Unethical if you follow the FSF's reasoning but not malicious since the users is running the software for that express purpose. <nckx>Freedom -1 is classified. <nckx>(What will the FSF do if a new freedom is discovered? I worry.) <drakonis>the gnu distros have a recurring problem where the maintainers decide what you're going to run with it <dstolfa>doing a quick grep through the source, i can't really find these 2 variables used anywhere <dstolfa>they are just defined as module parameters, but not much more <dstolfa>i need to look a bit deeper it seems <nckx>dstolfa: I was hopefully thinking the same thing. <drakonis>trisquel doesnt have a package that blocks the installation of other packages they deem unacceptable, right? <nckx>I'd certainly suggest trying to run it with them patched out or so. If it still works, and you can't find any obfuscated firmware in ‘source code’ form, it might just be all right. <vagrantc>dstolfa: it may be possible to remove the references to them, then ... <drakonis>both of arch's gnu derivatives have those and its very obnoxious <nckx>drakonis: Do you include Guix? I'm not aware of that at all. The maintainers choose what to put maintenance effort into supporting, yes, as that is only reasonable. <apteryx>lfam: thanks for checking. I tried applyin on top of origin/core-updates <lfam>drakonis: To me that's unacceptable <drakonis>i cant include guix because it does not deliberately excise half of the archive and then include a package that conflicts with the removed packages or things that conflict with their own personal beliefs <nckx>drakonis: There are a few ‘app store’ like things that we block because of the FSDG but we don't block loading user-supplied plug-ins on purpose. <lfam>There is a real problem within the free software movement of people not believing in freedom zero <drakonis>but there are distros that block on purpose <drakonis>parabola and hyperbola are the ones i can immediatly think of <drakonis>trisquel has a package that checks if you have non free software, right? <drakonis>besides that, it just doesnt have non-free and some bits of contrib removed? <dstolfa>i don't remember having anything like that <lfam>It's one thing to check and warn, another thing to prevent the user from exercising their rights <nckx>drakonis: By the way, I'm a firm believer in freedom 0 so am always interested if you find a needless hurdle in Guix that wouldn't be a maintenance burden to fix. <nckx>It's something I explicitly tell people about Guix. <drakonis>i dont have trisquel on hand to check that and i havent figured out how to properly spin up another distribution's container without docker <nckx>Weirdly, it allows me to invest more fully in software freedom than I used to, before I knew the Hyperbola's of the world were twisting it. <nckx>It's been a long time since I looked at that repo but I swear the last time I did somebody had just run sed on the OpenBSD code. It was legitimately... creepy. <drakonis>hyperbola is parabola without systemd and any kind of emulators <nckx>I hope they've progressed in all ways since then. <dstolfa>nckx: vagrantc: looking at it more, it seems that those are under a compile time guard CONFIG_FILE_FWIMG. i can't see this being turned on anywhere, so i think it actually doesn't use any blobs <dstolfa>i need to do more digging, but i think it's actually fine <dstolfa>vagrantc: see autoconf.h in include. they commented out the #define CONFIG_FILE_FWIMG, which means it's compiled out <vagrantc>dstolfa: would be nice to find other libre wifi options <lfam>Sometimes I think a lot of people in our movement would rather not use computers at all <drakonis>because it has a dependency on pulseaudio? <ae>lfam: I installed Guix on dover from the installed OS. A somewhat frightening moment... <lfam>I'm glad to hear that it worked, ae :) <nckx>ae has the best nick and now I want to put on an Autechre record again. <lfam>drakonis: Maybe it's the same people who think that systemd isn't free software, and thus also don't use pulseaudio, because it was started by the same author <dstolfa>from what i can see, this driver is fully free and should be fine in linux-libre. i'll still wait to see their reply and follow up on this. they say that they offer full refunds if the customer is not satisfied up to 2 years, so i might snag one and play with it more <dstolfa>i don't want to get too excited too soon, but if this is fully free, it would be great <nckx>drakonis: What's the in-universe rationale for such blacklists? <lfam>Because of the magical 5th freedom: The freedom for things to never change ***ae is now known as andreas-e
<lfam>They also blacklisted openssl <drakonis>because it has a "nonfree json implementation" <nckx>Don't they blacklist youtube-dl for that reason? <lfam>It's truly a new world of computing <nckx>I definitely remember somebody from that world contacting us about it. <lfam>dstolfa: I've noticed it a lot! People say that systemd isn't free because it changed things too much <drakonis>no wonder there's nobody using gnu distros <lfam>It's like "democratic". The word "free" has come to mean "good" and so all kinds of things are "not free" <nckx>‘Linux is about choice HEY STOP CREATING’ ***andreas-e is now known as ae
<lfam>Just say you don't like it. Don't call it nonfree <drakonis>it states "ruby2.6:ruby2.6:parabola:674:[semifree] json module has nonfree CVTUTF code; replace with pure Ruby implementation" <nckx>Well, that could very well be legit. <drakonis>its not worth tossing out an entire language over this <nckx>Several free projects have a non-free $weird_old_parser. <lfam>Well, their operating system represents a true fork of what the free software world has to offer. If anything it will be interesting <dstolfa>nckx: vagrantc: right, so the only concern i have about this is that they distribute source as deb packages, which would make packaging it in guix a bit of a nightmare. i will prod them about it based on their response and as i find more things out in these drivers <nckx>I must disagree with drakonis here, it's even less possible to legally distribute a little bit of non-free code. <ae>I am confused. Why am I "ae"? I registered "andreas-e". <drakonis>i honestly have difficulty believing their judgement <nckx>ae: You were briefly andreas-e. <lfam>I see the blacklist has different categories. So, some things are in the "technical" category, rather than whatever the "not free" category is called <lfam>So, I'm sure that at least some of my incredulous finger pointing was misinformed <ae>Then I /nick'ed back by hand to ae, which prompted the message that I should identify for "Elwell" with a password, but apparently worked nevertheless. <vagrantc>maybe the cow could be abused to promote non-free ideas! <apteryx>lfam: how do you apply the patch, out of curiosity? <qyliss>the unicode consortium relicensed the file, but ruby didn't pull in the version with the updated header yet <qyliss>that's it, that's the whole issue <lfam>apteryx: From mutt, I use the pipe function. That means I press the '|' key, and then type 'cd ~/work/guix && git am -s' and then press ENTER <nckx>ae: I don't have enough info to say much, but yes, you're logged in as the user andreas-e with the nick ae <drakonis>nckx: i believe they are extremely heavy handed <ae>I am twofold. That is also weird. <lfam>Something to note is a lot of these people form the core of the gnu-linux-libre working group, of which Guix is ostensibly a member <nckx>drakonis: What they did to Ruby is the right thing: replace the non-free code which they are not legally allowed to distribute with a free bit. Users win. They should get props for *that*. <drakonis>ruby 3.0 has pulled in the newer one btw <lfam>I'm curious what you had tried that didn't work, apteryx <drakonis>they have a patched version of ruby anyways <apteryx>lfam: yeah, that's what I do from Gnus/Debbugs, and it usually works very well. This time it would fail with a patch corrupted message. <nckx>drakonis: Of course the whole sophomoric people-we-don't-like blacklist bit is ridiculous. <nckx>It's normal (or not uncommon) for your nick and account name to differ. <nckx>I have several nicks registered to the account nckx. <nckx>See ‘/ns info’, and by the way ae is way cooler. 😉 <drakonis>hyperbola goes neck deep into people we dont like <lfam>In some ways, I see their point. Linux is not going in their direction <nckx>If Libera supported Unicode nicks you could use a ligature. <drakonis>i can generally excuse the blacklist on parabola but not hyperbola <lfam>It will be a probably for the world of GNU in the fture <lfam>I mean, it will be a problem <apteryx>lfam: yeah, it's reproducible from Gnus: error: corrupt patch at line 71 <vagrantc>well, at least that's the *only* problem! <lfam>Major components of computers will not have free software support in the future <lfam>Already we see it with wifi <drakonis>weird how even packages with optional dependencies like unrar are blacklisted <lfam>If our movement cannot rise to the challenge it will regress to the status quo of the early 90s, when a fully free operating system was not possible <lfam>Especially if we turn on the CPU makers themselves, as big parts of our movement seem to be doing <andreas-e>I do not know who I am any more. Trying to sort it out now. <dstolfa>lfam: the CPU maker thing is a real problem. <lfam>We need to work on building the movement enough that we can write new firmware and drivers <drakonis>its really difficult to attract people when you don't even give them the option <lfam>Which options are those? <dstolfa>he's probably referring to freedom 0 :) <nckx>It's really difficult to attract people if your software doesn't do anything on any of their computers. <lfam>Like, what are we doing? Are we trying to use computers? Or not? <drakonis>hexchat gets blacklisted for hardcoding firefox? (i'm sure it doesnt do that lol) <lfam>I wonder if anyone has ever had a conversation like this about Guix ;) <lfam>Yeah, but it's definitely a hurdle <dstolfa>lfam: computers are scary, i can see why some people don't want to use them :D <nckx>Using Guix build --source: yes, it does. <jackhill>I've been very impressed by the Ashai Linux folks of progress towards making that hardware useful even if it will never be fully free <nckx>src/common/hexchat.c: "NAME Open Link in a new Firefox Window\n""CMD !firefox -new-window %s\n\n"; <nckx>Obviously not something that could be fixed with a one-line patch. <nckx>Better blacklist the thing. <lfam>jackhill: Their work will be so valuable <dstolfa>but they are also scary, they give me nightmares (okay, it's mostly C and C++ that give me nightmares, but still) <drakonis>you could clearly just have it redirect it to xdg-open lol <lfam>I'm sure that XDG is verboten <nckx>drakonis: Why u hate freedom. <drakonis>hyperbola straight up hates freedesktop and lennart poettering <nckx>grep XDG freedesktop.org && echo ERROR <lfam>What can I say. I think all that stuff is really good <nckx>Oh, sorry, I confuse Parabola & Hyperbola because they are really well-chosen names. <rekado>apteryx: you can also get the whole patch set <lfam>You know that Emacs is considered unfree because nobody can understand it ;) <lfam>You got to let it go drakonis <apteryx>rekado: I forgot how to do that with mumi, but I'm interested to be refreshed :-) <drakonis>why not blacklist emacs because you can do unfree things with it out of the box? <lfam>You don't have to pay attention to it <lfam>If they want to do their thing, I hope they have a great time <dstolfa>emacs is non-free because it lets you write software which could potentially be non-free. it should force you to release your source under the GPLv3 <drakonis>wasnt that an argument rms used with irony mode? <Rooks>The hexchat blacklist just feels like a grep for firefox lmao <drakonis>dont expose AST because you could use it for writing nonfree things? <lfam>To be fair, I think that was more of a strategic choice <dstolfa>it's a bit of a different argument i think <nckx>drakonis: It's more than that. Building a cool blacklist in your own back yard is one thing, but occasionaly people try to pressure other distributions (through GNU & the FSF) to apply the same broken logic. That's when it gets dangerous, because the most extreme opinion often wins by default. <lfam>I disagree with it, but I have hindsight <drakonis>nckx: that's exactly the problem and it has been propagating <lfam>You have to be firm if you are faced with it. It's only email and chat <drakonis>the hyperbola blacklist is so incredibly extensive <lfam>It's okay to disregard sophistry and warped logic <nckx>I'm glad Guix has stood up to them. Well, ignored them mostly. As is correct. <lfam>Language is not logical either, so trying to combine them is a fraught exercise <lfam>We all have to interpret our shared values for ourselves and do what we think is right <dstolfa>speaking of all of this, has rust resolved their weird trademark thing that got people yelling yet? <drakonis>i feel like folks have been boxing themselves with things like these <drakonis>the only people i've seen yelling about it have been the hyperbola folks <lfam>It's being discussion on our ML currently <dstolfa>drakonis: other people have been yelling about it too because it's an annoying gotcha if someone modifies the compiler. hyperbola is just being a bit extreme about it <nckx>Hyperbola is not a reliable source. <drakonis>they manage to be the zealots within the zealots of the gnu project <lfam>I mean, I don't disagree with Rust. If somebody made some nasty "GNU Guix" project I'd want the trademark enforced too <lfam>It's a right you want to reserve ***andreas-e is now known as ae
<drakonis>the only time i've seen the python foundation exercise their rights was with python 2.8 <pkill9>who did guix stand up to for what? ***ae is now known as andreas-e
<Rooks>What are some common gotchas with guix? Like software I may miss? <drakonis>not being as warped as other gnu distros <dstolfa>it's just a weird situation because it's unclear if it should be "rust" in linux or of it should be "oxide" or whatever <andreas-e>nckx: So finally I understand: ae is registered by a user Elwell. <drakonis>nvidia, vanilla linux kernel, some other little bits <lfam>Rooks: Current Firefox. Many drivers from the kernel <nckx>Zealots has to positive a connotation, and I'm not trying to be provocative. I'm not saying they should be pragmatic. I'm saying they're wrong and unwilling to listen to facts that contradict their prejudice. <drakonis>if you need it, you can find it with a cursory search engine <nckx>andreas-e: That would do it. I can't see your registered nicks, only you can. <Rooks>Yeah, I looked for a general guix-nonfree to see if I could find a compiled list, but aside from that I didn't really look oops <nckx>So I didn't know it wasn't ‘yours’. <drakonis>did the hyperbola people coveniently forget that both perl and python have exercised their rights in the past? <lfam>dstolfa: I think it's a situation where you have to make a judgment about "Is the Rust Foundation going to sue us?" <lfam>And "Can we act in a way that won't make them want to?" <lfam>It seems clear the answers are No and Yes <drakonis>i dont want to ever get to a point where guix has to decide to split because it isnt meeting a very exceedingly high bar set by the most excessive folks <lfam>The law does not apply automatically like a computer program <dstolfa>lfam: the weird problem arises when $DOWNSTREAM makes a change in the rust compiler and then redistributes it under the GPL, but it is no longer rust <lfam>Yeah, some changes will be acceptable, and some won't. Guix policy is not avoid unecessary diversions from upstream <nckx>Not binding etc. etc. but who knows. <lfam>Yeah, but it's a good sign <drakonis>in my opinion, i think guix has the most pleasant stance <drakonis>the problem is that the expectations that come with a gnu distro work against it <drakonis>people expect the user experience to be worse than the upstream distro by default <lfam>It's a nice thing about not being a "clone minus" of some other distro <nckx>What's an upstream distro? <lfam>We are compelling on our own merits <drakonis>the distribution in which a gnu distribution is based on <nckx>Gotcha, I was thinking only of Guix. <lfam>I think Trisquel is an Ubuntu <drakonis>i thought it was debian based due to the numbering scheme <drakonis>it is definitely its own thing now and it is what makes it stronger. <lfam>There isn't a "freed" Debian currently, if I undersatnd correctly <lfam>You know. Except for Debian <drakonis>debian itself if you dont run most of contrib or nonfree is find <lfam>I wonder why they use testing, which doesn't receive security updates in a timely manner <dstolfa>lfam: it's a laptop distribution by purism, so i assume it's for new software? <lfam>Yeah, but it doesn't get maintained to the level of current or unstable <drakonis>they technically do get security updates but they arent in a fixed point <dstolfa>yeah, i dunno. maybe they apply them themselves, i really have no clue <lfam>Their testing branch is more like a development playground than something you are supposed to use, unlike the stable and unstable branches <lfam>Yeah, Debian always works :) <dstolfa>(unless it's jessie, jessie wanted to rm -rf itself on every update until i decided to let it for me) <drakonis>now that might actually have issues as packages might not be always available <lfam>Yes, it always works, and it always breaks <lfam>It's the magic of old-school Linux distros <lfam>Solid as a rock, blown over by a breath <lfam>An installation might work for 15 years, or it might turn itself inside out. Humans love gambling <leoprikler>epiphany:epiphany:parabola:367:[uses-nonfree] has non-privacy search engines e.g. Google <- can't they simply make use of freedom 2 and 3 to distribute versions of Epiphany, that have those disabled? <vagrantc>admittedly, the whole rolling release model of guix drives me a bit crazy ... i can see the appeal on some level, i just can't stop running "guix pull && guix system reconfigure ... && guix upgrade ..." obsessively <projectmoon>where can i find documentation on how to append to two sets of services in a single `(services)` definition? <projectmoon>i have an entry for %desktop-services, but i also want to update %base-services <vagrantc>leoprikler: that would require more effort than a one-line blacklist <nckx>projectmoon: They are just lists, you append those. <nckx>(append list1 list2 list3 ...) <apteryx>rekado: thanks! is that somehow discoverable from the UI? <nckx>I don't know where that's documented. Guile manual? <leoprikler>I used to `guix pull` daily, but now maybe weekly or on special occasions <projectmoon>i have (services (append (list ...) %base services) (append (list...) %desktop-services)) <lfam>%desktop-services includes %base-services <nckx>(services (append (list ...) (list ...) %desktop-services)) <lfam>I think so, but it depends on the specifics <nckx>projectmoon: That's not the reason you got an error. (services (append (list ...) %desktop-services (list ...) %base-services)) would get you a duplicate service error, but (services (append (list ...) %base services) (append (list...) %desktop-services)) was just plain bad syntax. <drakonis>vagrantc: you can always follow the branches for the releases <drakonis>but i'm not aware whether it has people that support it for people that want to use it with deployments <vagrantc>drakonis: and miss out on security updates? ... and all that shiny new stuff? <drakonis>that's a only for people that have to deploy it for work <nckx>projectmoon: Sure, and you will. It's (services LIST), you were trying to do (services LIST LIST). You could have wrapped the whole thing in yet another append and it would have worked! Ugly, but worked. <drakonis>as they all have to..., whatchamacallit, ratify it? <nckx>Well, and if you'd removed %base-services, anyway, /me → reboot. <dstolfa>having started making more and more cleanup commits in git, i am really being tempted to set up my emacs config again with magit... <projectmoon>but in general, would one only add stuff to desktop-services? <drakonis>vagrantc: its pretty much for people that want to use it on enterprise environments <drakonis>however, with how guix works, i'd say it isnt quite as necessary <drakonis>thank goodness for ease of usage and pinning here <drakonis>its hardly a big deal to have a rolling release model when it is simple to pin specific pieces <drakonis>read the backlog discussion for the context <drakonis>basically the majority of distributions dont believe in letting you decide how to use your system <drakonis>most gnu distros only respect the four freedoms starting on index 1 <vagrantc>it seems like a tiny minority of distributions, just to be clear <drakonis>there are some linux distributions that do have that stance as well <drakonis>its awkward, really, that's why they're niche <drakonis>vagrantc: are you going to submit a talk to debconf this year? <ix>Egh, ill fiddle with guix later. My head feels screwy <vagrantc>drakonis: maybe i could compare and contrast reproducible builds as done by guix and debian :) <drakonis>i know debian had spent some time there while lamby was DPL <drakonis>its no longer a main thing but its still there <drakonis>reproducible builds were a big thing during lamby's time as a DPL <vagrantc>we're still doing more of the same, and a bit better at it :) <vagrantc>i've really meant to do more systematic reproducible builds testing ... but it seems like guix build coordinator kind of does that already sort of <dstolfa>i'm like 99% sure that the driver is fully free (i say 99% because i didn't read through all of the loading and initialization code yet, but i have looked at anything that could possibly load blobs and it doesn't) <dstolfa>at some point, i might need to borrow someone's time who's skeptical about it so that i can try to convince them in hopes of getting some more certainty about it :)