IRC channel logs


back to list of logs

<rekado>gotta write it in point-free style, because it’s pointless.
<unmatched-paren>Haha. Well done :)
<rekado>unmatched-paren: maybe this: or this
<unmatched-paren>rekado: thanks!
<unmatched-paren>pkill9: ^^^
<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.
<unmatched-paren>``{ *(--stgCast(StgClosure**,gSp)) = x; }'' MY EYES
<rekado>liSP hAs Too MAny PaRENthesES!
<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>it’s not a new idea
<unmatched-paren>We did that for OCaml, after all.
<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.
<unmatched-paren>Somehow they managed to make it like Python but even worse.
<rekado>that’s why I thought: Hugs exists and it implements Haskell 98. Surely we could bridge the little gap?
<unmatched-paren>I considered that too.
<unmatched-paren>I once downloaded the Hugs source. It was not pretty, but it was not the GHC code.
<unmatched-paren>s/the GHC/that GHC/
<rekado>my latest GHC4 WIP:
<rekado>it’s not much
<rekado>and it’s arguably cheating
<rekado>but much less bad than a gigabyte of GHC binaries.
<unmatched-paren>Perfect is the enemy of good, I guess.
<rekado>with GHC4 we’d have an acceptable bootstrap path:
<rekado>4.08.2 -> 6.0 -> 6.6 -> 6.12(?) -> 7.4 -> 7.6
<ric342[m]>Interesting, thanks for sharing
<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
<linj><unmatched-paren> "I don't think you can install..." <- It can now after this pr using systemd portable service. Of course, systemd is needed to run the service.
<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>Hello, Guix! 🎉
<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?
<zamfofex>From this issue, that doesn’t seem to be the case: <> But maybe things changed since then.
<GNUtoo>Hi, In an os definition we have:
<GNUtoo> (services (append (list (service foo) (service-bar) [...]) %base-services))
<GNUtoo>How can I have an if inside?
<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>
<gnucode>GNUtoo: the error is the following
<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>(if #f #f) -> #<unspecified>
<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.
<GNUtoo>What does it do?
<gnucode>it is a dictionaly service
<gnucode>dictionary service
<gnucode>try this in a repl: (string-append (if #f "hello") " world")
<gnucode>this fix is this:
<gnucode>(string-append (if #f "hello" "other hello") " world")
<GNUtoo>I've find a dummy-service inside guix source code maybe it's better?
<gnucode>use that instead!
<GNUtoo>ok, I was unsure if there was a way around doing something like that because I'm pretty new to lisp
<GNUtoo>thanks a lot
<gnucode>you are welcome!
<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
<gnucode>sounds good.
<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
<flatwhatson>updatedb from findutils is sapping my life energy
<apteryx>zamfofex: thanks for the link. it's been many months since; an update would be nice
<xd1le>hi guix
<Cairn>hi xd1le
<unwox>sorry to bother but can anyone have a look?
<unwox>it looks simple enough to not require much time to review/test
<roptat>hi guix!
<mothacehe>hey guix!
<unmatched-paren>GNUtoo: why not do something like (append (if foo? (list (service ...)) '()) (list ...))?
<unmatched-paren>could somebody please look at this single-line bugfix patch?
<unmatched-paren>oh, huh, it was literally just merged :)
***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>‘a user’ is correct
<rekado>while ‘u’ is a vowel it is pronounced as a consonant
<unmatched-paren>jonsger[m]: it's pronounced like "yooser"
<antipode>unmatched-paren: On antioxidant: antioxidant now supports workspaces, fixing some builds
<antipode>The remaining parts (that I know of) are:
<antipode>* adding remaining missing inputs
<antipode>* checking what's going on with some Cargo.toml overriding build flags, does antioxidant need to respect that?
<unmatched-paren>antipode: brilliant! :)
<jonsger[m]>unmatched-paren "yooser" > "looser" :)
<rekado>does anyone know how to extend the monolithic texlive package?
<Lumine>Good morning #guix
<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
*civodul doesn't know
<rekado>I guess I can just brute force my way into a modified monolithic texlive
<rekado>it’s just a test after all
<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>horizoninnovatio: we do have a ``wine-staging'' package, yes
<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>hey there!
<civodul>who's in for a mini release hackathon?
<mothacehe>hey civodul! i'm in
<mothacehe>i can have a look to the installer "guix system init" dots issue
<civodul>ah, that's great
<civodul>i'm happy to chat on this if needed
<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>i think you'd basically do the same
<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>it's a good time to fix things
<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
<civodul>so maybe we just need to add it?
<sektor[m]>I sent a patch for that last week.
<sektor[m]>Am currently working on the espeakup service and an ISO image.
<civodul>oh great, i hadn't seen the patch
*civodul applies it
<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>mothacehe: is green but substitute is missing; any idea why?
<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?
<mothacehe>civodul: i have the following two lines that seem to indicate that it was fetched yesterday:
<mothacehe>not sure why it disappeared
<civodul>nckhexen: are you taking care of ?
<civodul>mothacehe: maybe it's just the "publish hook" that didn't run or something?
<civodul>that seems to happen occasionally
<nckhexen>civodul: Yes. Were you?
<nckhexen>If so I missed that. Sorry.
<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?).
<nckhexen>Do you know?
<civodul>nckhexen: no, you're probably more familiar with this than i am, so i'll defer to you
<civodul>mothacehe: another example:
<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?
<sektor[m]>Espeakup service. I can paste it here.
<mothacehe>civodul: mmh, there is nothing special in Cuirass logs. The publish hook is just running a URL fetch on
<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)
<sektor[m]>The work I did on the installer.
<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>morning friends!
<sektor[m]>Morning, gnucode.
<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>fun fact: linux-libre*.tar.xz.drv fails on i686-linux due to xz running out of memory:
<civodul>how do we deal with that?
<nckhexen>Noo… not fun again.
<civodul>we should really ditch xz at some point
<nckhexen>civodul: What ever happened to the linux-libre.git saga?
<nckhexen>Oh, this is repack?
<civodul>not related to the linux-libre.git saga :-)
<nckhexen>Consider it unsaid <_< >_>
<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>it is
<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.
<civodul>it's a world-rebuild fix i'm afraid
<civodul>unless we find a trick
<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.
<gnucode>sektor[m]: that's pretty cool!
<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.
*civodul nods
<nckhexen>Sorry for the blog post.
<civodul>mothacehe: looks like is never getting scheduled; do we have insights into that from the logs?
<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!
<civodul>seconded :-)
<mroh>./signed ;)
<gnucode>notarized. :)
<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>" errors
<mothacehe>otoh the "guix system init" terminal output no longer shows only dots
<mothacehe>i'll send that to review
<civodul>mothacehe: nice! i guess we may need a followup to log only upon failure or something?
<civodul>or maybe that's okay?
<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
<mothacehe>but it's way more work as you said
<mothacehe>let's also see what's jpoiret take on that
<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 ?
<sektor[m]>I forgot how I did it last time.
<nckhexen>What exactly is ‘Guix’ here?
<sektor[m]>Guix style.
<sektor[m]>With the pre-inst-env.
<gnucode>apteryx: civodul │ fun fact: linux-libre*.tar.xz.drv fails on i686-linux due to xz running out of memory:
<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
<sektor[m]>nckhexen: Splendid; that did fix it.
<gnucode>Baptiste: I think I vaguely recall something about if you use libre drivers, then you may run into hdmi incompatibilities...
<gnucode>I could be way wrong though.
<gnucode>My monitors all you VGA
<gnucode>I'm old school.
<Baptiste>gnucode: Ok Thank you
<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: <>.
***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>no gexp here
<PotentialUser-93>which file is that in? /etc/config.scm?
<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"
<Sughosha>civodul: It worked. Thank you!
<PotentialUser-93>civodul I can't find the (arguments...) entry
<PotentialUser-93>is it near (packages (append))?
<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>just a second.
<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>(packages ...)
<PotentialUser-93>for example if I wanted to remove gnome web
<PotentialUser-93>it looks like %base-packages is a variable, but what does it reference?
<gnucode>just change %my-base-packages to %base-packages
<gnucode>%base-packages is a list of low level base packages installed on by default
<PotentialUser-93>can I edit it?
<gnucode>gnome-web might be installed by default if you run (gnome-desktop-service )
<gnucode>PotentialUser-93 yes you can customize your %base-packages...
<gnucode>just a second.
<gnucode>I'll link my config
<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:
<gnucode>just search for (define %my-base-packages
<gnucode>base-packages is defined here:
<gnucode>Boo_: let me check
<Boo_>Thanks :D
<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?
<Boo_>lemme check
<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>mroh: is right.
<gnucode>apparently %desktop-services does NOT enable bluetooth
<gnucode>I guess I learned something today
<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
<sektor[m]>Time for lunch.
***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....
<gnucode>this may take a while.
<Boo_>Aren't there substitutes for it?
<gnucode>apparently not.
<gnucode>that's hilarious.
<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>I deleted that too.
<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_>Fair :/
<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?
<sektor[m]>I can't think of anything else to do to it.
<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
<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
<ekaitz>let me build and I'll share
<nckhexen>Did you make clean as part of re-bootstrapping?
<ekaitz>i think so, this is the error:
<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.
<sektor[m]>Now that I remember.
<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>honestly IDK what happened
<ekaitz>let me reset hard
<ekaitz>I don't know what's going on here tbh hahah it's amazing
<ekaitz>I just pulled
<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
<nckhexen>That's true.
<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.
<ekaitz>it's probably a bad one :D
<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/{,-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/ 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>Or make -C doc clean.
<nckhexen>(I now don't have Makefiles to check if that makes sense.)
<podiki[m]>since needs a touch after removal
<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.
<ekaitz>I see
<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>That's what Makefiles are for.
<nckhexen>I got a few warnings when running make but the deleted doc/ 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?
<sektor[m]>nckhexen: I don't see that being a problem.
<sektor[m]>nckhexen: Just gotta sync my messages.
<nckhexen>All this talk of speakup made me forget that speech isn't the only text output option.
<sektor[m]>nckhexen: True; there is also brltty.
<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?
<vivien>Oh maybe
<nckhexen>Otherwise, (non-copyleft "nope").
<nckhexen>The argument should technically be a URL, but…
<nckhexen>Since ‘private’ code tends to leak out eventually, I don't recommend this.
<singpolyma>#f no longer works
<nckhexen>Good to know.
<nckhexen>I've seen it used a lot in the past, so fun will be had.
<singpolyma>guixrus has made a "none license"
<nckhexen>So, proprietary.
<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)
<singpolyma>Just to get stuff to build
<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?
<sneek>Got it.
<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?
<daviwil>Oh! Now i see it
<daviwil>Twitter didn't notify me strangely
<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
<daviwil>Gotcha, makes sense
<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
<sektor[m]>nckhexen: I got your note.
***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
<the_tubular>Welp, I'm definitely failing that license
<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
<unmatched-paren>but you can use #define to replace a keyword.
<abhiseck`>Oh I see! since the keyword is replaced in the preprocessor step, and cpp doesn't know about c keywords
<unmatched-paren>Exactly. :)
<abhiseck`>Thanks for reminding :-)
<unmatched-paren>Although, why are you asking this in #guix? :)
<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>I currently have:
<tsvallender>  (append (list (setuid-program
<tsvallender>                 (program (file-append light "/run/current-system/profile/bin/light"))))
<tsvallender>               %setuid-programs))
<tsvallender>Inside (operating-system)
<unmatched-paren>tsvallender: please use a paste site for code
<tsvallender>Apologies, I thought that was small enough
<unmatched-paren>also, ``(file-append light "...")'' should be ``(file-append light "/bin/light")'' :)
<unmatched-paren>What error do you get?
<tsvallender>How does that work if /bin/light doesn't exist?
<tsvallender>I just get 'error: base-operating-system: unbound variable' when I try to build. It's definitely that, it build successfully without it
<tsvallender>Is there any way to get more useful error messages>
***rgherdt_ is now known as rgherdt
<unmatched-paren>(file-append light "/bin/light") builds ``light'' and does (string-append "/gnu/store/...-light-..." "/bin/light")
<unmatched-paren>basically, it appends a string to the end of the store path
<unmatched-paren>Sorry, Guile's error reporting is kinda bleugh sometimes.
<tsvallender>Ah okay. It's understandable, good error messages are hard, just makes it difficult to debug!
<tsvallender> Here's the whole file if that helps at all
<unmatched-paren>Sorry, I'm not sure what's happening here :/
<tsvallender>Thanks for looking anyway
<sektor[m]><pkill9> "guix is so powerful it should..." <- Who issues such licenses?
*rekado tries to build perl 5.6
<abhiseck`> I don't understand 1. why MIN (SSIZE_MAX, SIZE_MAX) can have wrong alignment and 2. why shifting 30 bits right and then left fixes alignment if it's wrong.
<unmatched-paren>abhieck`: Maybe some oddity on a really old Unix?
*sektor[m] is going to crash for the day. Have a good evening.
<unmatched-paren>sektor[m]: Bye.
<nckhexen>sneek: later tell tsvallender: Import (gnu system setuid).
<sneek>Got it.
<nckhexen>lechner: No, I don't currently need it.
***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>Hmm. You using Sway?
<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.
<unmatched-paren>I don't think panes can be offloaded to other Emacs windows.
<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.
<Kabouik> this
<rekado>sorry, I don’t know what I’m seeing there :)
<rekado>are these two window manager windows?
*rekado reads backlog
<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
<rekado>Kabouik: this may also be of interest:
<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’