<rekado>gotta write it in point-free style, because it’s pointless. <unmatched-paren>This is some pretty cursed stuff. ``(StgClosure *)tmp = isAlive((StgClosure *)t);'' <rekado>these aren’t blog posts, by the way. I wrote these notes to myself, because I have a tendency to forget why I even bother. <rekado>back then we didn’t have a package for GCC 2.x, so the latest attempt was to just let GCC 2.x figure out what this all means. <rekado>they come from the same era after all. <unmatched-paren>At this point I'm wondering if it might even be less work to write a Haskell interpreter from scratch. <rekado>the GHC propaganda tells us that at its core lies an elegant and really simple language <unmatched-paren>I think a Haskell interpreter might be significantly harder to write? <unmatched-paren>The Haskell syntax is awful awful awful, and then there's the whole lazyness thing. <rekado>that’s why I thought: Hugs exists and it implements Haskell 98. Surely we could bridge the little gap? <unmatched-paren>I once downloaded the Hugs source. It was not pretty, but it was not the GHC code. <rekado>but much less bad than a gigabyte of GHC binaries. <rekado>with GHC4 we’d have an acceptable bootstrap path: <rekado>4.08.2 -> 6.0 -> 6.6 -> 6.12(?) -> 7.4 -> 7.6 <rekado>we also may not need to use *all* files contained in ghc-4.08.2-hc-unreg.tar.bz2 <rekado>if we can manage to go about this intelligently we might be able to get away with only picking a few of those files. <Andronikos>The package stagit does not come with manuals. Was it forgotten? ***califax_ is now known as califax
<johnabs[m]>Hi guys, can someone quickly give me a heads up on how to get npm working in guix? I thought it was packaged under node, but when I tried to use an environment with node added, npm was not present. Is it packaged elsewhere? <yuu[m]>that makes me wonder: is there cli app for locating arbitrary files in all derivations produced by guix repo? akin to nix-locate <yuu[m]>unmatched-paren: linj home-manager is also a thing. <linj>Sorry, I do not get your point <linj>you mean nix's home-manager can support shepherd like it supports darwin's launchd? <zamfofex>I have been investigating the issues regarding Guix and Repology, and I was wondering if there is any way I can help or incentivize work to be put towards resolving it. It seems that Guix blocked IP address ranges including Repology’s because some such addresses (not including Repology’s) were performing mischievous actions such as port scans. I was wondering whether it’d be possible to choose the address ranges more selectively <zamfofex>(So to not block Repology.) Or conversely to reassess whether there is still an issue regarding those IP addresses at all. <apteryx>Repology's server is in Russia, and it seems the whole (?) of Russian IPs has been blocked from accessing the networking on which the MDC operates (where Berlin is hosted) <apteryx>rekado: do you happen to know why the Russian IPs are being blocked from accessing the network used by the MDC? <GNUtoo>Hi, In an os definition we have: <GNUtoo> (services (append (list (service foo) (service-bar) [...]) %base-services)) <GNUtoo>If I do (if (not (target-x86-64?)) (service foo)) then it works only if I'm not on x86-64, otherwise I've some error like that: In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #<unspecified> <GNUtoo>The examples in the guix source code there are always two statements, one when the if is true and one when the if is false, so the error doesn't happen because it always return something valid in any cases <gnucode>what you could do is something like this: <gnucode>(if (not (target-x86-64?) (service-foo) (service dict-service-type))) <GNUtoo>dict-service-type is a dummy service? <gnucode>GNUtoo: it's is a realy service, but it is a small one. <gnucode>try this in a repl: (string-append (if #f "hello") " world") <gnucode>(string-append (if #f "hello" "other hello") " world") <GNUtoo>I've find a dummy-service inside guix source code maybe it's better? <GNUtoo>ok, I was unsure if there was a way around doing something like that because I'm pretty new to lisp <gnucode>I had the same error a day ago with something I was working on. <GNUtoo>Maybe we should export this dummy service somehow <GNUtoo>For now it's in gnu/tests/reconfigure.scm so I'll copy paste it <flatwhatson>does anyone have a good example for setting up mlocate/plocate? <flatwhatson>seems like some effort is needed to create groups & directories, but we don't have a service for that <apteryx>zamfofex: thanks for the link. it's been many months since; an update would be nice <unwox>it looks simple enough to not require much time to review/test <unmatched-paren>GNUtoo: why not do something like (append (if foo? (list (service ...)) '()) (list ...))? ***Dynom_ is now known as Guest1020
<Kabouik>I've had issues two days ago with LibreOffice Impress crashing when saving and then forgetting all about my environment (my dark GTK theme would be light again, and some fonts (but not all) were missing). I'm not sure how to reproduce that; it occurred several times but rebooting fixed it. Anyone ever observed that too? <rekado>apteryx: no idea about Russian IPs. I don’t know if they are blocked by the MDC or the wider DFN network. All I was told was that there had been a massive increase in attacks on the MDC infrastructure coming from that range of IPs, so someone decided to block them at some level. ***wielaard is now known as mjw
<jonsger[m]>rekado: s/a user/an user/g or? I think its a typo in your last cookbook commit, but I'm not 100% sure with English... <rekado>while ‘u’ is a vowel it is pronounced as a consonant <antipode>unmatched-paren: On antioxidant: antioxidant now supports workspaces, fixing some builds <antipode>The remaining parts (that I know of) are: <antipode>* checking what's going on with some Cargo.toml overriding build flags, does antioxidant need to respect that? <rekado>does anyone know how to extend the monolithic texlive package? <rekado>I install texlive together with a custom tex package into the same profile, but the texlive search path is set to the output of the texlive package only <rekado>(I’m using the monolithic texlive package only to try to debug a problem with our modular packages) <rekado>I tried setting TEXMFCNF to the directory containing a custom texmf.cnf with a new search path, but this doesn’t seem to have any effect <rekado>I guess I can just brute force my way into a modified monolithic texlive <horizoninnovatio>A friend is having trouble installing wine-staging on fedore silver-blue ("immutable operating system"). Could the Guix package manager be a good work-a-round to solve this issue? Are there any potential problems? thank you :) <unmatched-paren>so if you can get guix working on fedora silverblue, then it might be a good workaround :) <rekado>on Fedora SELinux is enabled by default. You would need to disable it, set it to permissive mode, or figure out a way to extend the policies. <horizoninnovatio>I know nix can be installed without root permissions, can guix do you know? <civodul>who's in for a mini release hackathon? <mothacehe>i can have a look to the installer "guix system init" dots issue <mothacehe>your openpty proposal seems like the more reasonable solution <civodul>i guess the other hot topics are: package coverage ("make assert-binaries-available") and the 'staging' branch <mothacehe>although i have no experience with this system call <civodul>there's an example in environment.scm <civodul>however, we probably want to use run-external-command-with-handler more sparsely than is currently the case <sektor[m]>Trying to get an accessible installer still. 90% of the way there. <civodul>sektor[m]: oh that's great! let us know if you notice anything done wrong in the UI <civodul>mbakke, efraim: you around for some 'staging' hacking? <sektor[m]>I am nt sure if I should send patches or something; it tried to load th speakup module but apparently couldn't find it. <sektor[m]>But I see it in the derivation, in the kernel modules. <civodul>sektor[m]: it seems to be missing from the linux-libre package: find $(guix build linux-libre) -iname \*speakup\* <civodul>likewise "zcat /proc/config.gz |grep SPEAKUP" turns up nothing <sektor[m]>Am currently working on the espeakup service and an ISO image. <civodul>cbaines: re childhurds, what hardware do you run them on? Intel CPUs? <cbaines>civodul, currently a machine with an AMD Ryzen 7 CPU, but I'm looking at getting some running on milano-guix-1 as well (which I think uses Intel) <sektor[m]>So where do I paste the configuration->documentation output? The file is quite large. <civodul>cbaines: and so the Hurd VM never fails to start on the AMD CPU? <civodul>sektor[m]: you're using configuration->documentation for a service you're working on, right? <cbaines>sometimes, but if it fails to start the first time, it usually only takes one or two attempts to get it to start <nckhexen>I thought Leo might want to handle it, but it's been a week. sektor[m]: What I don't understand is why use %default-extra-linux-options, and not gnu/packages/aux-files/linux-libre/5.19-x86_64.conf. <sektor[m]>Good question. I was going off what I remember from the cookbook. <civodul>cbaines: i like the optimistic tone of your reply :-) <civodul>sektor[m]: re services, you'll want to have the doc in doc/guix.texi, under the relevant section <civodul>(now solved because ran "guix build xf86-video-vesa" on berlin, but the question remains valid :-)) <nckhexen>sektor[m]: I wonder if anyone has a clear reason. ☺ I think there's no reason not to put these in .config, but I'll take care of that. Thanks! How accessible is our installer after this change? <civodul>mothacehe: maybe it's just the "publish hook" that didn't run or something? <civodul>nckhexen: yes, but i'm fine either way :-) <nckhexen>I was going to add them to the .configs instead, because I'm not convinced that the dichotomy is meaningful (IIUC, our .configs are not ‘vanilla’, they are already ours, so why have another layer?). <civodul>nckhexen: no, you're probably more familiar with this than i am, so i'll defer to you <civodul>actually a significant part of the items that show up in "make assert-binaries-available" are in this situation <sektor[m]>There's still some work to do. I can't seem to get the service to want to load the module; it can't find it fr some reason. <civodul>sektor[m]: which service tries to load the module? <mothacehe>civodul: mmh, there is nothing special in Cuirass logs. The publish hook is just running a URL fetch on 127.0.0.1/xxx.narinfo <mothacehe>i'm not sure if we can find a trace of those in nginx logs <civodul>not nginx, maybe /var/log/guix-publish.log? <civodul>unmatched-paren: the value in home-dbus-environment-variables, with shell constructs, looks dubious (there's no shell doing dollar expansion and all that) <nckhexen>sektor[m]: I think I've noticed the same (the kernel failing to request_module() one that should have been there). It wasn't the core problem at the time so I didn't debug it. I don't know if initrd module loading (as opposed to the brute-force load-linux-module done by linux-boot.scm) is even set up at all. <sektor[m]>Interesting. I was pulling my hair out when I was working on it last week. <gnucode>sektor[m]: what cool guixy things are you building today? <nckhexen>sektor[m]: It's just a hunch! Can't say for sure. Now that there's an in-Guix reason to take another look, I will. <sektor[m]>Accessibility support into the installer via espeakup. <civodul>we should really ditch xz at some point <nckhexen>civodul: What ever happened to the linux-libre.git saga? <civodul>not related to the linux-libre.git saga :-) <nckhexen>But ehm (1) yes (2) zstd. That repack xz is often by far the most taxing part of a local test build, which is a bit silly. <civodul>in some/most cases, we could also choose to not repack <civodul>(i remember discussing it in the past but forgot what the conclusion was) *civodul goes look for a workaround <nckhexen>I think git → git (and maybe → tarball → tarball) repacks would be ideal, but an xz → zstd quick fix for 1.4 would be equally nice. <nckhexen>s/maybe → tarball/maybe tarball/, the point being repack closer to the input format. <nckhexen>Oh, I thought 1.4 had a c-u in between. Never mind. <civodul>nckhexen: did we already hit that before? (xz OOM) <nckhexen>‘Physical’ yes, but I assume you're talking about the 32-bit address space limit here? <nckhexen>So, here's something I was going to say anyway: I've been absent from Guix a lot lately, I know. It does not take an astute reader to correlate this to increased activity by a certain individual, as much as I wish I were stronger than that. *That* is 90% of what I associate with ‘Guix’ now. Which sucks, as I've always got my energy from the social channels. And me being trivially nerd-sniped into fixing/coding/helping, that worked well for everyone <nckhexen> ☺ Until it didn't. I'd like to get over that. Which means that I'm looking for useful work to do to make this fun again. I guess I'll go read the 1.4 thread, which I've been avoiding. <gnucode>nckhexen: if it makes you feel better, you're probably my best "I've never met this person is real life" friend. <gnucode>You've made my laugh a ton with some of the irc/email convos we've had! <mothacehe>civodul: select * from builds where derivation = '/gnu/store/662bis1hbj7a95960g3yslb4bvj82cfh-emacs-28.1.drv'; shows that the build priority is 29 <mothacehe>select count(*) from builds where system = 'aarch64-linux' and priority < 29; reports 1714 builds <mothacehe>which are mostly 'guix' for aarch64 builds that are more prioritary <apteryx>civodul: keeping everything in source form would have benefits for a future 'guix debug' that'd be a 'guix shell' with gdb, symbols, and sources <mothacehe>civodul: looks like the openpty solution works like a charm <mothacehe>the /var/log/messages file is filled with progress bar as predicted but shows "guix system init <mothacehe>otoh the "guix system init" terminal output no longer shows only dots <civodul>mothacehe: nice! i guess we may need a followup to log only upon failure or something? <civodul>(for each progress bar we're probably sending ~1KiB to syslog) <sektor[m]>civodul: Isn't that fairly large for a log file? <mothacehe>i think we can have this as a first step, and maybe aim for a progress bar page hiding the terminal stuff <civodul>or we could simply write to syslog upon failure? <nckhexen>gnucode (and mroh, and others who have been kind to me in private): That is very sweet, and I appreciate it more than you know. *mbakke has been away for a while <mbakke>civodul: yes, let's get it done; anything in particular that needs to be done? <patched[m]>For some reason, `guix package -u` insists on building nheko, even when `guix weather nheko` as that substitutes are available both on ci and bordeaux... Why? And can I fix this somehow? I've had the same problems with other programs in the past too. <nckhexen>I hope you all make it to Brussels this year (if allowed) and we can all celebrate Guix's teenage years in style. <patched[m]>I have too little ram to build the derivation on my own <apteryx>civodul: why do you want to ditch 'xz'? <sektor[m]>Now to figure out how to not have Guix replace the copyright symbols with ? <Baptiste>Hello everyone, I don't think the question I'm about to ask is a borderline question, so please correct me if I'm wrong. Can someone tell me what options do I have left trying not to use the proprietary driver for my GPU when the package xf86-video-nouveau didn't seem to be able to start the X server? <gnucode>Baptiste you could try to blacklist the nouveau driver. <gnucode>then it'll fall back onto Intel graphics or vesa. <nckhexen>sektor[m]: You're probably closer to remembering the solution than I am to debugging your issue, but ‘guix shell glibc -- locale’ might be a start. <gnucode>one of those should work. You won't be gaming anytime soon. :) <apteryx>gnucode: that shouldn't happen (we tell xz to use 50% max the system memory); perhaps there's a bug <Baptiste>gnucode I tried that, the X server does start but my HDMI is not recognized by xrandr and I cannot connect my external monitor <apteryx>civodul: are you perhaps packing multiple tarballs in parallel, or doing more than one build on that i686 machine? xz will use maximum 50% of the system memory <gnucode>Baptiste: I think I vaguely recall something about if you use libre drivers, then you may run into hdmi incompatibilities... <gnucode>Baptiste: wish I colud be more helpful <Sughosha>Hi Guix! I am packaging something and want to build it by trivial-build-system. I want to have the arguments with gexp like "(#~(list #:modules ((guix build utils))))", but I am getting this error: <https://paste.debian.net/1257053>. ***kasper is now known as Boo_
<PotentialUser-93>I'm currently trying out Guix System and I am having difficulty editing base system packages <civodul>Sughosha: hi! it should be (arguments (list #:modules '((guix build utils)))) <civodul>PotentialUser-93: hi! yes, if you used the installer, it stored it in /etc/config.scm <civodul>it's just a convention though, you can store it anywhere and then pass it to "guix system reconfigure" <gnucode>PotentialUser-93 there shouldn't be an (arguments...) entry <gnucode>(arguments is meant for packaging things. <gnucode>If you are trying to edit base system packages... <gnucode>then you are probably going to chang ethis in your config <gnucode> (packages (append (map specification->package '("sway" "nss-certs")) %my-base-packages)) <PotentialUser-26>Hi. Does someone has python-lsp-server running? It seems broken due to python-rope changes <PotentialUser-93>gnucode is there a place that lists all the base packages that are installed? <gnucode>I just pasted it in the chat for you. :) <gnucode>just change %my-base-packages to %base-packages <gnucode>%base-packages is a list of low level base packages installed on by default <gnucode>gnome-web might be installed by default if you run (gnome-desktop-service ) <gnucode>PotentialUser-93 yes you can customize your %base-packages... <Boo_>Does anyone know what could be causing this issue when reconfiguring my guix system after adding the bluetooth service? `No applicable method for "#<<generic> provided-by (1)>" in call (provided-by "#<unspecified>")` My config can be found here: http://paste.debian.net/1257057/ <gnucode>just search for (define %my-base-packages <PotentialUser-93>is system.scm a standard component when the gui installer is used? if so, what is its absolute path? gnucode <Boo_>PotentialUser-93: You should be able to find it in ~/.cache/guix if you run `find . -name system.scm` <gnucode>Boo_: Why are you defining your bluetooth service ? <gnucode>doesn't %desktop-services have a bluetooth-service ? <Boo_>Am I? Is that what (bluetooth-service) dose? <gnucode>I would try to remove the bluetooth-service <gnucode>you've already got it defined in %desktop-services <Boo_>Ok! It configures, but I don't have bluetooth <Boo_>It seems that GNOME can't communicate with bluetoothd <mroh>afaik, %desktop-services doesn't contain bluetooth-service. (and should not, imho). <Boo_>Blueman can't either, says bluez isn't running <gnucode>apparently %desktop-services does NOT enable bluetooth <Boo_>Am I doing something wrong when I add it to my services list? <gnucode>Boo_: I just got this to make sudo guix system vm config.scm happy <gnucode>but I quick configuring it pretty quickly. <Boo_>gnucode: Copied the config you sent (except for the bootloader and file-systems part) but am still facing the same issue <Boo_>It happens after it tries to run eval on service root ***noah is now known as lolcat
***lolcat is now known as lolcat0
<gnucode>Boo_: well let me try configuring it a bit further... <gnucode>my computer is building mutter and crap.... <Boo_>Aren't there substitutes for it? <gnucode>I deleted the gdm-service-type & gnome-service... <gnucode>and it's still trying to build mutter <Boo_>Is gnome-bluetooth in packages? <gnucode>yeah... that's part of the reason why I want to run sway with only %base-services. I have not been able to figure it out though. <gnucode>I have always had to have %desktop-services. <gnucode>I guess I'm out Boo_ I don't feel like building mutter. :( <Boo_>Thanks for trying to help anyways <gnucode>usually #unspecified means something like (if #f #t) <gnucode>that if statement evaulates to #unspecified. <Sughosha>Hi, if there is an example of trivial-build-system invoking gcc, please let me know. Thanks in advance. <sektor[m]>Do ya'all think the espeakup service is ready for submission? <Boo_>I'm not sure about the layout of services but how would me adding the bluetooth-service affect the root service? gnucode <gnucode>Boo_: I've got no idea. Your best bet at this point is to email help-guix@gnu.org <gnucode>it's probably something really silly that I am missing <nckhexen>OK. The way we configure our kernels is a bit odd. <rekado>gnucode: if you’re curious about why mutter is built I suggest looking at the references and prerequisites of your system derivation. <sektor[m]><nckhexen> "OK. The way we configure our..." <- It beats doing it manually. <ekaitz>hi, just git pulled from guix and tried to build in the repo with make and makeinfo gives errors <ekaitz>(i did bootstrap, configure and all that before) <ekaitz>how i'm supposed to build guix now? <nckhexen>I quite enjoy manually configuring my kernel, but I am also a bit odd. What I mean is we seem to have manually curated x86/arm .conf files, but not for any other architectures. So I am going to apply your original patch to linux.scm, because otherwise it wouldn't take effect on riscv64/powerpc64. But I don't understand the rationale if there is one. <nckhexen>ekaitz: Please share the messages, don't just report ‘errors’. <ekaitz>nckhexen: uf it just fails with the references from the docs <nckhexen>Did you make clean as part of re-bootstrapping? <ekaitz>I'm surely missing a stupid step, as always but... <ekaitz>i'm in a `guix shell -D guix` btw <sektor[m]>Actually I didn't know about the aux-files or venture in there. <nckhexen>ekaitz: I'm not an expert on the translations, but that's weird: your .de.texi should not contain English pxrefs if mine is any indication. They are all in German. <nckhexen>Are those English strings actually in the .de.texi file? <ekaitz>I don't know what's going on here tbh hahah it's amazing <ekaitz>btw yes, the references are written in english in the german part of the docs <nckhexen>I don't ‘git pull’, ever, because it confuses me beyond hope and can thoroughly destroy a working repository for the slightest reason. <nckhexen>Interesting. So whatever went wrong went wrong earlier, and ‘make’ is ‘right’ to complain. Here I have @pxref{Senden einer Patch-Reihe} etc. <ekaitz>but I don't have local commits, it should be safe to do a pull <ekaitz>I'm trying again after a git reset --hard <ekaitz>and not looks like it's building .go files <ekaitz>I'm still afraid of what will happen when it tries to build the docs <nckhexen>I don't think these .xx.texi files are tracked in Git anymore. They used to be. <ekaitz>hmm so they are kind of lost in my old git tree for a reason? <nckhexen>I really can't say if there's a good reason, sorry. <nckhexen>If these files keep getting regenerated with English in place of German, I don't know enough about Texinfo (or Gettext) to speculate how. <nckhexen>A workaround is ‘touch’ing the doc/guix.de.info{,-1,-2,-3,…} targets, since you likely don't care about these files anyway. <podiki[m]>docs frequently give me trouble, if I haven't done it in a while I sometimes delete the doc folder, tell git to restore it, then rerun bootstrap and go from there <podiki[m]>right, I think a bunch of the .xx.texi files are touched by bootstrap and are gitignored <ekaitz>podiki[m]: I just downloaded a fresh repo, run bootstrap and saw that happening <ekaitz>so they are gitignored files so I didn't catch them git the git status <podiki[m]>I think we need some info in the manual about keeping up a local git checkout <ekaitz>is there any command in the make like make clean or something to clean them out? <podiki[m]>not sure, but since it is the bootstrap that generates the initial file, maybe not? (since that is supposed to just be run at the beginning, though I guess it doesn't matter) <ekaitz>my bootstrap was ignoring the old files so there should be a way to recreate everything <ekaitz>in the fresh repo it just worked because it created all the fresh things it needed <ekaitz>but anyway, solved, thank you all for the help! <nckhexen>I tried distclean out of curiosity, it didn't delete doc/guix.de.texi. It did delete my Makefile, so now I'm re-bootstrapping 😃 <podiki[m]>yes, maybe a script or make option that deletes generated files and touches ones that need it <nckhexen>Yes. Plus there's no guarantee that the existing rules are ideal, complete, or even correct. <nckhexen>Like, why does ‘distclean’ skip these? I don't know. <podiki[m]>should be an easy enough make option, like a "make doc-reset" <nckhexen>(I now don't have Makefiles to check if that makes sense.) <podiki[m]>(writing touch so much makes me feel...weird) <ekaitz>how does other people manage that? <nckhexen>It nevers causes me grief, but this exact checkout is years old. Who knows what magic left-overs keep it limping along. <podiki[m]>I used to do a delete and start new, but I think I've kept the same one for most of the year now <podiki[m]>the doc texi files are the main one that causes trouble, once I ctrl-c'ed in the middle of a make and it was in a weird state too <podiki[m]>next time I'll try to be more systematic and see if a line or two of bash to delete/touch like bootstrap is enough to then just make <nckhexen>podiki[m]: By the way, it's not that doc-reset was a bad idea per se, but I think this should be handled by a well-known option like (dist)clean, not a Guix-custom one. That is all. <podiki[m]>nckhexen: oh sure. But there needs to be creation of the files too (make will not work without the touched files from bootstrap if I remember) <podiki[m]>Would that be unexpected in a dist clean? (I don't know, I don't makefile) <nckhexen>Mm. Yes, it would be, I didn't get that part. I think any mandatory (re)creation should be implied by whatever requires it. <nckhexen>I got a few warnings when running make but the deleted doc/guix.de.texi was regenerated with the same correct strings (e.g., @pxref{Installation von USB-Stick oder DVD}) <nckhexen>So this is a mystery unless you can reproduce it. <nckhexen>sektor[m]: Silly question: is it annoying if I send you mail with a full Git commit ID? <nckhexen>All this talk of speakup made me forget that speech isn't the only text output option. <sektor[m]>I'm not really qualified to write for that since I don't own a Braille display that functions anymore. <vivien>Is there a special value that passes the license test but means "this is a private thing, it does not have a license"? <vivien>I have ((@@ (guix licenses) license) "no" "no" "no") but maybe there’s something better <nckhexen>Does the previously conventional #f not pass validation? <nckhexen>The argument should technically be a URL, but… <nckhexen>Since ‘private’ code tends to leak out eventually, I don't recommend this. <nckhexen>I've seen it used a lot in the past, so fun will be had. <vivien>Sometimes I do pirate stuff too and if I put a license on that it’s very misleading <singpolyma>nckhexen: well, it's unknown due to laziness usually. Always gets replaced with a real license later <vivien>(by that I mean I copy some copyrighted work without authorization) <nckhexen>vivien: Then (non-copyleft "file:///EULA.txt") would still be ‘better’ than "none", but yeh, this is leaving the realm of #guix. <nckhexen>Actually, do not do what I said, it is bad advice. non-copyleft explicitly marks the licence as free. I didn't know that. <nckhexen>So if #f is now out, I think your (@@ …) example is actually the best of bad options. Maybe it could be exported, but there might be a non-technical reason it's not. <nckhexen>sneek: later ask civodul: Is lookup-qemu-platforms silently ignoring unknown platforms a design decision? <podiki[m]>sneek: later tell daviwil saw you had a stream about the fhs container, sorry I missed it! I see some tips I have would be useful to be shared (better get to that cookbook writing) <daviwil>podiki[m]: yes! Any tips would be good. I think it's a pretty viable option for running arbitrary software but it still requires a decent amount of work to get something running <sneek>daviwil, you have 1 message! <sneek>daviwil, podiki[m] says: saw you had a stream about the fhs container, sorry I missed it! I see some tips I have would be useful to be shared (better get to that cookbook writing) <podiki[m]>just tweeted you actually, with the answer for what you were trying to do :) <podiki[m]>I tend to use -D ungoogled-chromium since that pulls in pretty much everything for any web/graphical apps <podiki[m]>the other trick is the right things to share, especially for hardware access <podiki[m]>the other fun thing is appimages, really all you need the fhs container for is to run it to get the offset as it is called, then you can mount it as a disk image without a container (no fuse mounting in the container allowed I guess) <podiki[m]>(the software you were trying was next on my list for that other package channel, too) <daviwil>Cool! I didn't see the tweet, was it on Mastodon or Twitter? <podiki[m]>oh, mastodon, i'm on there too (well, I rarely use either) <daviwil>So is it possible to package software using fhs or were you just going to patch it the usual way? ***mark_ is now known as mjw
<podiki[m]>I'm not sure how one can use the container for packaging, beyond maybe some scripts that will set up a container to run something? but I meant the usual way of patching <podiki[m]>I would like to think about setting up containers for certain dev environments, like if you have to use latest rust or something and don't want to build the next compiler forever <podiki[m]>guix shell -C -F -N poetry coreutils gcc:lib -D ungoogled-chromium --share=$HOME/temphome=$HOME --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --share=$XAUTHORITY -- poetry shell <podiki[m]>^ another one for spawning poetry shell in a project, say for web development stuff with a home for the container that will persist ***Digitteknohippie is now known as Digit
<lechner>nckhexen: Hi, do you have pinyin input working? ***justHaunted is now known as ffffffradiofree
***ffffffradiofree is now known as jusFffffffradiof
***jusFffffffradiof is now known as justThumbs
***justThumbs is now known as justVain
<pkill9>guix is so powerful it should require a hacker's license to use it <abhiseck`>is it possible to undefine C keywords? I just saw "#undef const"\n "#define const" in a source file. <unmatched-paren>abhiseck`: #undef is sometimes put before #define to "protect" the #define, as ``#define FOO 34'' after ``#define FOO BAR'' will actually do ``#define BAR 34'' because of the already-defined ``FOO'' macro <abhiseck`>Oh I see! since the keyword is replaced in the preprocessor step, and cpp doesn't know about c keywords <abhiseck`>sorry, I don't know a better place, it's related to coreutils though. coreutils doesn't have a irc channel afaik. <sektor[m]>Nw I need to figure out how to mail patches in Emacs so I don't have to context switch. <unmatched-paren>It's fine to discuss non-guix free software/programming related things here, afaik. <abhiseck`>unmatched-paren: that's a relief that I'm not violating channel rules. :-) ***tsv is now known as tsvallender
***tsvallender is now known as help
<lechner>unmatched-paren: Hi, the wording of "non-guix free software" depends on the dash, doesn't it? <unmatched-paren>lechner: Not really. It's supposed to mean "free software that isn't guix". Though I agree that it's a wee bit unclear in general. <unmatched-paren>non guix free software is basically the same as non-guix free software. Just a stylistic difference. <tsvallender>I'm trying to allow non-root users to run the 'light' program, which I believe I do by adding it to setuid-programs, but I must be doing something wrong as it's currently making my entire operating-system invalid. What's the right way to do this? <tsvallender> (program (file-append light "/run/current-system/profile/bin/light")))) <unmatched-paren>also, ``(file-append light "...")'' should be ``(file-append light "/bin/light")'' :) <tsvallender>I just get 'error: base-operating-system: unbound variable' when I try to build. It's definitely that, it build successfully without it ***rgherdt_ is now known as rgherdt
<unmatched-paren>(file-append light "/bin/light") builds ``light'' and does (string-append "/gnu/store/...-light-..." "/bin/light") <tsvallender>Ah okay. It's understandable, good error messages are hard, just makes it difficult to debug! <sektor[m]><pkill9> "guix is so powerful it should..." <- Who issues such licenses? *rekado tries to build perl 5.6 *sektor[m] is going to crash for the day. Have a good evening. <nckhexen>sneek: later tell tsvallender: Import (gnu system setuid). ***TopExpert is now known as amish
***amish is now known as Guest8236
<Kabouik>Am I allowed to ask an emacs workflow question here? I did on #emacs first but was surprised to realize that actually what I want to achieve may not be so common ***Guest8236 is now known as neoluddite
<Kabouik>I suppose #guix is a bit of an emacs antichamber (it did drag me to trying emacs after all these years) <Kabouik>Cool. I want to use emacs -nw exclusively. When emacs opens new emacs windows (which I will call panes here just to avoid the ambiguity with WM windows), like with `C-h ?`, or in my case `M-x R RET`, it splits my terminal window in two panes. <Kabouik>I would want it to actually open a new $TERM window and show the new emacs buffer there. <Kabouik>This would also allow me to more easily move/arrange/resize windows with my WM keybindings, including spreading windows on multiple screens. <unmatched-paren>I suppose you could add some Sway keybinding to do ``foot emacsclient -nw'', maybe? <Kabouik>Yes but that is for when I want to manually start a new emacs client <Kabouik>What about emacs starting new panes on its own, like C-h ? or M-x R RET? <rekado>Kabouik: you’d have to make emacs open a new frame instead of a new window. <rekado>but frames do not appear in a new terminal emulator tab <rekado>they are just ‘fullscreen’ in the terminal emulator <Kabouik>So there's hope, rekado? I don't want a tab, but rather a new $TERM window <rekado>I don’t know what exactly ‘$TERM window’ means <unmatched-paren>Kabouik: I suppose you could also write an Emacs function to do the same. <rekado>sorry, I don’t know what I’m seeing there :) <rekado>are these two window manager windows? <Kabouik>$TERM is just a place holder. I use foot as my terminal. So if emacs is running in one foot window, and I do M-x R RET, I want the R buffer to show up in a new foot window <unmatched-paren>(shell-command (concat (getenv "TERM") " emacsclient -nw")) would this work? *unmatched-paren is not experienced with emacs <rekado>this wouldn’t deal with *any* and *all* window splits, though <Kabouik>I was thinking about exactly something like that unmatched-paren (although I didn't know how to write it). But how can I tell emacs to use that when it starts new panes from my actions in the first window? <rekado>emacs has the deprecated pop-up-frames variable and pop-up-frame-function <Kabouik>I'm really surprised that counting on the WM to manage emacs windows is a corner case. That seems like the best way to use multiple monitors and workspaces. I know I could manually start a new client and then display a buffer from the server, but that would be a lot of manual step, and the buffer would have opened in the server window too, which I do not want <rekado>Kabouik: in Emacs if you want your window manager to handle windows you need to let Emacs create a ‘frame’ whenever a buffer is to be displayed. <rekado>the manual has a lot to say about this in section 29.13.4 Additional Options for Displaying Buffers <Kabouik>I'll look into it then, thanks, both of you <Kabouik>Indeed. Good finding. I hope it won't turn out to be too much work to set up. <Kabouik>I am afraid that I'll need something more to make it work with -nw, probably something like what unmatched-paren posted above (so that emacs knows how to start a new foot window) <Kabouik>Hum, and that'll be annoying for things like the minibuffer <arescorpio>First always save the Human LIFE ! Thus you DID not KILL *rekado built perl 5.6 and now the ghc 4 build looks much better <rekado>the problem with the previous build was that perl 5.14 (which I used before) had changed some default behaviors that the ghc 4 ‘driver script’ depends on <rekado>now the ghc-inplace script seems to perform the expected transformations *rekado is cautiously optimistic <podiki[m]>there's a package for frames-only-mode that does this (that's what I use currently) <rekado>it built the compiler but then failed when using it … ‘Haskell compiler received signal 11’ 