IRC channel logs

2020-05-21.log

back to list of logs

<rekado>hmm, I think I have to give up on trying to make the lightdm service “nicer”
<rekado>it would be nice if I could just provide a default greeter, but specifying greeters through independent service types is probably fine, too.
<rekado>I guess we could make lightdm-service-type fail right away when it hasn’t been extended with a greeter
<rekado>that way people can’t accidentally configure broken systems
<rekado>but maybe that’s pushing it.
<nckx>civodul: Trivial ‘third vaule’ typo in patch 3/5 of your downgrade series.
<bricewge>rekado: lprndn explicitly wanted for lightdm-service-type to work without a greeter to be more straight forward for newcomers
<bricewge>Personally I prefer it failing than being half configured. But I don't have strong opinion about it, I would like to see it merged.
<nckx>civodul: Won't this complicate things for people hacking around in local channels? (Maybe that's worth it, dunno.)
<nckx>But hey what do I know about git.
<nckx>'night o/
<civodul>nckx: thanks for the typo report!
<civodul>i don't think it'd complicate things for people hacking local channels
<civodul>at worst they have to pass --allow-downgrades, which is probably fine
<civodul>it's like "sudo" after all
<civodul>:-)
<civodul>alextee[m]: re static linking, i guess the answer is "no"
<civodul>but that's because i'm assuming plugin = .so
<civodul>isn't it the case here?
<alextee[m]>civodul: yes the audio plugin is an external shared library that MUST have its dependencies statically linked, but seems that some distros (including guix) don't do that. i guess the problem is on the plugin side for not being statically linked and requiring other .so's
<alextee[m]>er, plugins not having their dependencies statically linked is a problem that's probably a combination of bad upstream build scripts and distros
<alextee[m]>on windows and macos all audio plugins are completely statically built but some gnu/linux plugin upstreams/distros don't do it
<civodul>alextee[m]: oh i see
<civodul>maybe doing that would help
<Kozo>raingloom: I am using a 5700XT. If you need help getting it running, I can help you.
<raingloom>Kozo: i got it "running" in the end, but performance with radeon in Blender is abysmal (worse than my GTX 650) and amdgpu doesn't work with it.
<Kozo>Do you want me to try running Blender?
<raingloom>Kozo: well, it's not that important now, because i just ordered a GCN 4 card that others told me is well supported.
<raingloom>but it might be useful for others if we got this one working properly as well
<ryanprior>Okay so I've got a nice working version of my wrap-cc system that allows you to invoke your favorite c compiler as "cc" if that's convenient in your build environment. Anybody want to dissuade me from submitting it upstream? Are wrappers considered uncool or problematic? Or am I just the first person to want this?
<raingloom>ryanprior: i think the reason it hasn't been added before is that packages are supposed to explicitly refer to their inputs? but that's just a guess. might be worth taking a look at whether Nix has something similar, and if not, why.
<ryanprior>My reason for wanting this is as an end-user. If I create a manifest that I'm going to load to work on my code, and the upstream build system relies on having "cc," then I'm either going to have to create symlinks myself or patch the build system like a package definition
<ryanprior>Either way is non-obvious to other people who might try and use my manifest if I share it with them
<ryanprior>With this patch in Guix I could just specify `gcc-toolchain-wrapper` in my manifest and have that be the end of it.
<raingloom>how come --with-commit doesn't work in `guix system reconfigure`?
***catonano_ is now known as catonano
<alextee[m]>ryanprior: most packages just do CC=gcc, doesn't that work?
<alextee[m]>doesnt the build system accept a replacement for cc? sounds like a very poorly written build script
<alextee[m]>although i dont get why gnu-build-system doesn't set the CC variable by default
<alextee[m]>and CXX
<reepca`>alextee[m]: from what I've heard the project in question hard-codes "cc" (not a shell, environment, or makefile variable).
<alextee[m]>oof
***jonsger1 is now known as jonsger
<ryanprior>alextee: well behaved build systems definitely should do as you say. Then there's other build systems which...... do all kinds of things.
<raingloom>ryanprior: i think it's worth taking a page from the Arch book and not patching things too much, but fixing things upstream.
<ryanprior>I will not be disappointed if that ends up being the solution.
<ryanprior>As a person coming to Guix from Debian who is used to having `cc` and finds some comfort in having that as an option, this seems like a nice usability feature, so I'm gonna propose it :)
<raingloom>well, people are also used to having a /usr/bin and an /sbin and whatnot.
<raingloom>doesn't necessarily mean it's a good idea to implement them.
<raingloom>anyways, does anyone know why "@@" doesn't work?
<raingloom>i'm trying to invoke something defined in a channel's module to define a custom package in my operating system.
<raingloom>(because i need a different version of the package)
<ryanprior>(I also think it would be neat to have a program that creates you a fake root with symlinks in a unix-like file system layout for those times when you kinda want that.)
<pkill9>that should be easy now that you can add files to the root of the container
<raingloom>to be honest i did want that when i tried using the arch bootstrap chroot.
<pkill9>guix container*
<ryanprior>Has anybody devised a nice format for specifying all the attributes of a guix container yet?
<ryanprior>Using Guile for that could be acceptable, or something like TOML would be even nicer.
<drakonis>its probably going to be guile all the way down
<ryanprior>There's already the JSON package definition format, which is not the nicest format to write but it's a good start.
<reepca`>raingloom: regarding why "@@" might not be working, guile 3.0 added certain optimizations related to bindings in modules. At the optimization level guix compiles at, many non-exported bindings are optimized out entirely.
<apteryx>nckx: thanks! Seems I lost my ability to match parens in my excitement to push that change ;-).
<ryanprior>sneek: later tell lprndn: want to join #elementary to coordinate on pantheon packaging? I'm working on reviewing your packages :)
<sneek>Will do.
<ryanprior>sneek: thank u kindly rowbot
<raingloom>reepca`: i see, that's basically what i expected. well, i worked around it in another way.
<raingloom>incidentally, does anyone know why changing the kernel package required building guix 1.1.0 as part of the system build? does the kernel somehow use it? or is it needed for, idk, computing some derivation or something?
<raingloom>it took quite a while too.
<badair_>If I want libstdc++ but not the rest of gcc, is this the right approach? "cd /path/to/guix/checkout && guix build --system=i686-linux libstdc++-4.9 --load-path=."
<ryanprior>badair_: that does not seem right, no.
<ryanprior>badair_: there is already a libstdc++ package that doesn't hae the rest of gcc in it. However, it is a "hidden package" and I'm not totally sure why those exist or how to use them.
<ryanprior>badair_: they are apparently packages that tend to confuse people... I'm not sure what's confusing about a libstdc++ package but maybe there is some hidden danger in it. If somebody can explain to me I would appreciate that.
<badair_>ryanprior: It confuses people because of the breaking (by default) ABI changes in GCC 5 and later.
<ryanprior>In any case here is where the package is defined badair_: https://github.com/guix-mirror/guix/blob/master/gnu/packages/gcc.scm#L610-L611
<apteryx>ryanprior: usually people who wants libstdc++ wants the full toolchain
<badair_>ryanprior: Thanks, what's the right way to build one of these? That was the intent of my original command.
<lfam>You would define one with the make-libstdc++ procedure
<ryanprior>badair_: to build one for eg gcc-9, you would run
<ryanprior>guix build -e '(begin (use-modules (gnu packages gcc)) (make-libstdc++ gcc-9))'
<badair_>I see, thanks so much!
<ryanprior>or change gcc-9 to whatever version you want
<ryanprior>I tried that just now to make sure I wasn't leading you wrong, and it didn't work. So the true answer is I don't know X.X
<badair_>Indeed, it fails for me with gcc-4.[7-9] and gcc-10. I'll just take the kitchen sink for now
<ryanprior>badair_: if you want to send your build logs for those to bug-guix@gnu.org we can take a look at it. Thanks for understanding :)
<badair_>Thanks for working on this awesome system!
<gnutec>Guix is the best!
<gnutec>:)
<raingloom>is there a way to check the current kernel's config?
<raingloom>also, could we enable amdgpu's Southern Islands support in linux-libre?
<xelxebar>raingloom: guix system describe gives you the path to your kernel
<xelxebar>Under that same directory, there's .config
<raingloom>xelxebar: oh, so it's a hidden file. i didn't expect that.
<xelxebar>Yeah, I just happened to stumble upon it.
<ryanprior>running guix system describe on a foreign distribution causes an error and prints a backtrace =X
<xelxebar>ryanprior: I get a 2 line backtrace, followed by this: no system generation, nothing to describe~%
<xelxebar>Seems pretty reasonable to me. What do you see?
***apteryx is now known as Guest96237
***apteryx_ is now known as apteryx
<raghavgururajan>Hello Guix!
<raghavgururajan>The pam-mount-service-type, how does it authenticate crypt volumes? Using pinentry?
<wingo>moo
<craftyguy>I'm installing guix for the first time, I see the installer is downloading python 3.7.4, which is curious because it looks like 3.8 is the latest here: https://guix.gnu.org/packages/python-3.8.2/
<craftyguy>what's up with that?
<kristofer>yakkity yakkitty yak
<mbakke>craftyguy: the installer was made with an older revision of Guix
<mbakke>once you have installed and run 'guix pull', you will have the latest and greatest
*janneke wonders what would happen if that were a logical and
<boeg>I am trying to add elogind-service-type to my services, but when I do, I get the error "service: 'file-system-/run/systemd' provided more than once". If I remove the (service elogind-service-type ...) the error disappears. Am I trying to configure elogind wrong? Here is the piece of code: https://paste.debian.net/1148103/
<rekado_>boeg: %desktop-services already includes elogind-service-type
<rekado_>so if you want to configure it use (modify-services %desktop-services …)
<boeg>rekado_: ah okay, thank you!
<lprndn>Hello guix
<sneek>Welcome back lprndn, you have 1 message!
<sneek>lprndn, ryanprior says: want to join #elementary to coordinate on pantheon packaging? I'm working on reviewing your packages :)
<lprndn>sneek: later tell ryanprior: Ok, I'll look at #elementary in the next few days.
<sneek>Will do.
<boeg>I had on arch linux a systemd service in /etc/systemd/system/disable-xhc1.service that did `ExecStart=/bin/bash -c "echo XHC1 >> /proc/acpi/wakeup"` to make my laptop not wake up from suspend untimely. How would I configure that on guix?
<rekado_>boeg: does this need to run only once?
<rekado_>then you can use a one-shot shepherd service that does the same
<boeg>rekado_: I think it would be run on each start up
<boeg>Can I can use shepherd service for it?
<boeg>But I can*
<lprndn>rekado_: I answered your email about the lightdm service. ;) I can try to build something and send new patches if you want. Maybe not today but soon.
<rekado_>lprndn: writing a reply to your mail right now. I think we have a way out of this problem.
<lprndn>Nice!
<raingloom>where is one supposed to install mesa-opencl? system wide packages? inside a service?
<rekado_>raingloom: I think that package should really be merged with “mesa” and thus become available to all users of mesa.
<raingloom>rekado_: so ughh, where should i install it until then?
<mbakke>raingloom: what do you need it for?
<boeg>rekado_: Do you have an example of how to create such a service that is run on start up and runs "echo XHC1 >> /proc/acpi/wakeup" - i've tried looking in the manual but, an example of a service would be nice
<sirmacik>damn, ungoogled-chromium and icecat still don't have a substitute >:
<lprndn>rekado_: Just read your mail. I just have a soe questions on your first point.
<lprndn>First, I suppose you mean lightdm-gtk-greeter-service-type, right? Also, It should only override seats that are defined inside its own service or did I miss something?
<mbakke>boeg: maybe something like (define disable-xhc1-service (simple-service 'activation-service-type (let ((port (open-file "/proc/acpi/wakeup" "a"))) (format port "XHC1") (close-port port)))
<mbakke>you can also shell out to bash there, but that's no fun ;-)
<boeg>mbakke: thanks
<PotentialUser-66>Hi, When creating a pkg definition file - Any one know how to impose a version constraint on native-inputs, inputs and propogated-inputs?
<mbakke>PotentialUser-66: Guix uses exact versions of all dependencies, so constraints are not necessary.
<PotentialUser-66>mbakke: showing my ignorance: How can that work? Example:
<PotentialUser-66>I want to create a package that builds only if bash 3.2 is installed. I think I should place bash as a native-input. How do I ensure that v 3,2 gets used if the system currently has 4.3 available everywhere?
<mbakke>PotentialUser-66: then you'll need to create a bash-3.2 variable and use that as native-input
<PotentialUser-66>mbakke: I don't understand. Could you point to a package that does this sort of thing?
<mbakke>package build processes do not have access to the currently running system, so they cannot see what is installed, they can only access the declared inputs
<PotentialUser-66>understand that far.
<mbakke>PotentialUser-66: see the 'pango-1.42' variable and 'librsvg' for example
<PotentialUser-66>OK, FYI I was expecting to use syntax like is used in specification<-manifest in profiles. POLS
<PotentialUser-66>Checking pango and librsvg now
<PotentialUser-66>mbakke: is librsvg a package name in gun/packages?
<mbakke>PotentialUser-66: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnome.scm#n2241 and https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gtk.scm#n277
<PotentialUser-66>OK I got it librsvg is in gnome.scm
<PotentialUser-66>Thanks - slowly getting the hang of the guix toolkit ;)
<mbakke>PotentialUser-66: you can do compile-time checks with something along the lines of (if (version>= (package-version bash) "4") (error "Bash is too new!" '()), but it does not really make sense in Guix.
<PotentialUser-66>Thanks for that tip - will stash it away.
<PotentialUser-66>mbakke: it the librsvg example I see the pango-1.42. Where is that variable defined/set?
<mbakke>PotentialUser-66: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gtk.scm#n277
<rekado_>lprndn: no, I did mean lightdm-service-type. I’m talking about the extensions the lightdm-gtk-greeter-service-type provides.
<PotentialUser-66>mbakke: OK so in guile pango-1.42 can be both a variable and a package name?
<rekado_>looking at all the extensions it provides it looks like we can do without it.
<rekado_>lprndn: having a greeter override the seat configurations that a user may have specified for lightdm-service-type seems wrong.
<rekado_>say I want to have one seat with lightdm-gtk-greeter and another with lightdm-mini-greeter
<rekado_>adding lightdm-gtk-greeter-service-type to the list of services would override all my seat configurations and force the use of lightdm-gtk-greeter for all of them.
<mbakke>PotentialUser-66: inputs always refer to variables, the package name of 'pango-1.42' is still "pango"
<rekado_>service extension seems to be the wrong mechanism to me.
<rekado_>the seat configuration comes from lightdm-service-type, the “top level”. We shouldn’t mess with it downstream.
<rekado_>the only problem I keep running into is how to represent greeters best.
<PotentialUser-66>mabkke on last question: Is there anything stopping me, in this context, from creating a package name, such as bash@3.2.1:bin? This is I'm just co-opting the manifest syntax.
<rekado_>lightdm-service-type could take an arbitrary list of configuration objects, but they all have a different type so we can’t do anything with their values
<rekado_>this suggests some sort of simple inheritance
<PotentialUser-66>mbakke: /on/one/ and /this/that/
<PotentialUser-66>mbakke: apologies I should have said variable name such as...
<lprndn>rekado_: can you tell where lightdm-service-type overrides greeter-session? It was not intentional, hence my poor understanding...
<rekado_>lightdm-service-type does not override anything
<mbakke>PotentialUser-66: if you create a package with name "bash", version "3.2.1" and an output called "bin", you can access it from the CLI with "bash@3.2.1:bin"
<rekado_>it has a “seats” field that takes a list of lightdm-seat-configuration objects
<rekado_>these seat configurations have a greeter-session field
<mbakke>PotentialUser-66: you can probably use (name "bash@3.2.1:bin") too, but that will be all kinds of weird
<rekado_>(the default is “lightdm-gtk-greeter”, but it doesn’t have to be this way)
<PotentialUser-66>mbakke: Understood I quite liked the manifest syntax and in my situation it fits quite well, bash was a bad example.
<rekado_>the lightdm-gtk-greeter-lightdm-service procedure takes the seats from the “config” value and replaces them with a new seat configuration where the “greeter-session” field is overridden with the string "lightdm-gtk-greeter".
<rekado_>that procedure is used by lightdm-gtk-greeter-service-type as an extension to the lightdm-service-type
<PotentialUser-66>mbakke I also like the idea that a package named x@n:lib will look to most people like something they shouldn't touch. Which would be correct.
<mbakke>heh :P
<rekado_>this means that whatever seat configurations lightdm-service-type contains will be changed to use the greeter-session “lightdm-gtk-greeter”
<mbakke>PotentialUser-66: to clarify, you can access the pango-1.42 variable through (specifications->manifest ...) as "pango@1.42"
<PotentialUser-66>mabkke: whoah there. never read anything like that. now x@n:lib does sound bad.
<PotentialUser-66>mbakke: mbakke is guix parsing the pango@1,42 and looking for pango-1.42 or does guix look for name =pnago version>=1.42
<mbakke>PotentialUser-66: both, kinda: when you use specifications->manifest and the guix CLI, you can ask for pango@1.42 and Guix will try to give you any package with name "pango" and "version "1.42.x"
<bricewge>rekado_: What you are saying doesn't look correct to me.
<PotentialUser-66>mbakke: OK understand much better now. Really appreciate you taking the time to help and share your expertise.
<PotentialUser-66>mbakke: cheers
<bricewge>rekado_: FWIU it's not the case, the procedure 'lightdm-gtk-greeter-lightdm-service' which returns a list of seat to extend 'lightdm-service-type' only override the 'greeter-session' field for the seats that this greeter contains.
<mbakke>PotentialUser-66: glad to spread the knowledge! :-)
<lprndn>rekado_: (don't get me wrong I agree with you, I just miss something...) I thought using extension would mean lightdm-gtk-greeter-service would just pass its own (overriden) seats field to lightdm-service-type. But if I understeand correctly, it gets the whole list of seats (it's own + those defined in lightdm-service-type or nother greeter service) and override them before passing them back to lightdm-service-type, is that right?
<haha>guix offload: error: failed to connect to `#<input-output: channel (open) 7f4e4667c600>': Protocol error
<haha>The server I used to build remotely is Guix on Debian. I ran guix offload test and it got this error. Has anyone solved it?
<bricewge>rekado_: In other words it won't override seats in other greeter. The procedure could do without overriding of 'greeter-session' since it seems to only do it to avoid a user misconfiguring lightdm-gtk-greeter seats with an other greeter.
<mbakke>haha: did you authorize the signing key of the offload server?
<mbakke>haha: guix offload error messages are terrible :/
<mbakke>there is a bug report about it somewher
<rekado_>bricewge: oh, I see.
<rekado_>isn’t that all terribly confusing? To have seats in lightdm-service-type and in the greeters? And then also to have “greeter-session”?
<bricewge>lprndn, rekado_: Regarding XDG_CONFIG_DIRS, I recall that lightdm-gtk-greeter does respect it but other greeters may not.
<bdju>I heard btrfs runs slower than ext4. Is that something I'd notice during normal usage?
<rekado_>bricewge, lprndn Other greeters may have to be patched to find their configuration files.
<bricewge>Fair enough
<rekado_>generally, we try to avoid installing global configuration files
<haha>mbakke, I can make sure that the public keys of me and the server have been imported from each other
<lprndn>bricewge: yes + I didn't succeed at using it but It can probably be dealt later if necessary.
<bricewge>rekado_: sddm and gdm does it tho
<rekado_>yeah, that’s not great
<mbakke>haha: ok, are you able to "ssh offload-user@offload-server guile -c '(use-modules (guix config))'" ?
<sirmacik>why it takes so long for chromium prebuilt packages to appear?
<rekado_>sirmacik: can you tell me the derivation that corresponds to the build of chromium?
<bricewge>rekado_: Yes it's confusing, I'm wondering if we are stretching the service extension method or if we are missing a patter here...
<mbakke>sirmacik: probably because the CI seems to be hanging: https://ci.guix.gnu.org/jobset/guix-master
<sirmacik>dbipfrrnjjlx443s52j1cgyl1d3wmz3-ungoogled-chromium-81.0.4044.138-0.c2a89fb.drv
*bricewge go to lunch
<lprndn>rekado_: It's probably a little confusing but I felt your idea of using a package instead of a string was a good candidate solution (need to re read everything to be sure tho)
<mbakke>rekado_: should we restart cuirass? ref https://ci.guix.gnu.org/jobset/guix-master
*janneke wonders when the internet is going to route around those monsters
<sirmacik>jackhill: meaning browsers?
<sirmacik>janneke: ↑
<sirmacik>sorry
<janneke>yeah
<sirmacik>there is next (CL based) browser with a nice community and upcoming 2.0 release (:
<haha>mbakke, It seems I can't guarantee that I can find ~/.guix-profile/bin/guile when logging in with ssh. Is there any way to set it up?
<janneke>yeah, there are all kinds of nice efforts to create "friendlier monsters"
<haha>The profile seems to only take effect for shell sessions.
<lprndn>rekado_, bricewge: To me, our main problem might just a UI one. Do we want to have greeters defined inside the lightdm service or not? I think we have solutions for both (with pros and cons). But I might forget things...
<lprndn>*just be
<sirmacik>janneke: other solution is gopher experience which appears to have a little renaissance
<mbakke>haha: many distro-provided .bashrc files do nothing when invoked "non-interactively" (like ssh host command), you probably should add something like '[[ -n "$SSH_CLIENT" && source ~/.guix-profile/etc/profile ]]' at the top of .bashrc
<rekado_>lprndn, bricewge I’m leaning towards having just one service that accepts a bunch of greeters.
<rekado_>the problem with that approach, however, is that a greeter can be configured
<rekado_>so it needs a way to produce a configuration file
<rekado_>and then it needs to make lightdm-service-type arrange for the config file to be found, e.g. by setting XDG_CONFIG_DIRS
<rekado_>I don’t know enough about greeters in general to know if there are common properties
<rekado_>if there’s nothing in common then I don’t see how lightdm-service-type could do any such setup work *without* the use of service extensions.
<rekado_>lprndn: using *just* the greeter package would probably not be enough.
<haha>mbakke, I added it in bashrc and it doesn't seem to work
<haha>Commands executed directly by ssh do not seem to use the shell
<rekado_>lprndn: since I don’t want to block this while chasing for a vague improvement let’s wait for bricewge and then decide whether to merge it as is.
<rekado_>(well, with the few minor improvements I made on top of your patches)
<sirmacik>mbakke: what are the chances for substitutes to start appearing?
<haha>it like this:
<haha>└── sshd
<haha> └── sshd-notty
<haha> └── process
<haha>Oh, maybe I should modify the PATH variable of sshd
<mbakke>haha: you also need to install 'guix' into the profile (as in guix package -i guix)
<mbakke>haha: and 'guile'
<haha>I installed guile in guix-profile, but it cannot be found.
<mbakke>sirmacik: I started the builds manually on the CI server, substitutes should be available now
<sirmacik>thanks!
<haha>Ok, modified the environment variable of sshd, it didn't work
<mbakke>haha: did you add a line like 'source ~/.guix-profile/etc/profile' at the very top of .bashrc? can you share the .bashrc file?
<mbakke>haha: perhaps the user is configured to use a shell other than bash?
<lprndn>rekado_, bricewge: FYI, greeters "often" use /etc/lightdm/... for their configuration files. But for example, I think elementary-greeter uses GSettings... in this case we might just give up on its configuration all together. So there are ways.
<haha>Thanks, I modified /etc/profile.d/guixenv and then it worked.
<mbakke>oh, good :-)
<mbakke>terrible that these things are so difficult
<haha>root@chromebook ~# ssh dev@10.0.40.1 -- guile -c '\(use-modules \(guix config\)\)'
<haha>ERROR: In procedure read:
<haha>In procedure scm_i_lreadparen: #<unknown port>:1:13: end of file
<haha>I executed this command, but it got this error
<lprndn>rekado_, bricewge : I don't have a strong opinion here but just to improve our possibilities:
<haha>'guix offload test' got this: https://paste.debian.net/1148113/
<mbakke>haha: remove the escape symbols and it should work
<haha>root@chromebook ~# ssh dev@10.0.40.1 -- guile -c '(use-modules (guix config))'
<haha>bash: -c: line 0: syntax error near unexpected token `('
<haha>bash: -c: line 0: `guile -c (use-modules (guix config))'
<mbakke>haha: oh derp, try ssh dev@10.0.40.1 -- "guile -c '(use-modules (guix config))'"
<janneke>sirmacik: gopher, that could be nice
<lprndn>we could pass greeters' configuration as a list of records in a greeters field. Each record would probably be more or less the same as the current implementation. we dispath themwith (case ) or something to specific procedures outputing a list composable with the list of service-extension of lightdm-service-type. compose them. magic happens.
<haha>mbakke, Haha, there is no output from this command, it seems that it passed.
<lprndn>some kind of local service extension really. but I'm throwing out thing passing through my mind so I may be totally wrong here.
<haha>But 'guix offload test' still doesn't work: https://paste.debian.net/1148115/
<lprndn>rekado_, bricewge : Also, reminder for thoughts. LightDM should be able to work without greeter (autologin).
<mbakke>haha: can you verify that /etc/guix/signing-key.pub on the offload machine is present in your /etc/guix/acl ?
<haha>Sorry, I forgot to put the client's public key on the server, I configured too many servers, I forgot this one.
<haha>mbakke, Now it works fine, thank you very much.
<mbakke>haha: great, and sorry you had to go through all this trouble! :)
<nckx>I'm a few years late to the (working) qemu-binfmt party and suitably in love, but… how do I conditionally apply a patch to an origin? Even with --system=armhf-linux, (%current-system) returns x86_64.
<nckx>I mean good morning Guix.
<nckx>It is 13:37.
<nckx>Enjoy that.
<nckx>‘This list of patches must be unconditional.’
<nckx>Muh.
<janneke>nckx: we have ugly workarounds for that, here and there
<janneke>python and cross-libc come to mind
<nckx>I'm making one of my own that will surely rival both.
<nckx>(Thanks, a bit of grepping did turn up the cross-libc example and that helped me a lot.)
<nckx>All this to apply a one-line patch only on armhf though <https://issues.guix.gnu.org/40604>, I feel like it might be overkill…
<janneke>yeah, in general we want patches to be applied, and upsteamed -- unless maybe to prevent rebuild world
<nckx>WDYM?
<nckx>This one isn't about rebuilds (for once), just breaks i686.
<rekado_>lprndn: yes, I also toyed with the idea of a cond to deal with all greeters explictly. Not very elegant, but perhaps it’s unrealistic to want a truly generic mechanism here.
<sirmacik>janneke: I'm in a process of writing static page generator that treats gopher as primary citizen, as an avid gopher fan
<sirmacik>but it'll take some time till I have something to share
<janneke>nckx: sorry, haven't looked -- but a patch that breaks another architecture will be difficult to upstream
<nckx>It's not mine but exactly.
<janneke>so in general, patches need to be OK for all architectures
<janneke>and that's why it makes sense for the list of patches to be unconditional
*janneke got hurt by that several times, creating the bootstrap and doing hurd'y things ;-)
<nckx>Sure. Totally agree in principle.
<nckx>I'm just not going to dive into struct alignment on i686 to write a better one.
<janneke>yeah, i sympathise with that
<nckx>I'm pretty easy to nerd-snipe but you'll need to do better than i686.
<janneke>hehe
<alextee[m]>is there any CI that supports guix?
<alextee[m]>also, can you run guix pack from a foreign distro?
<alextee[m]>(looking to get some automated builds going)
<janneke>alextee[m]: we have cuirass, and yes
<alextee[m]>oh this is nice https://guix.gnu.org/manual/en/html_node/Continuous-Integration.html i suppose it only runs on guix systems though
<alextee[m]>i'll build the packs on a foreign distro probably. idk of any public CI or vps that has guix
<rekado_>you can run cuirass on any GNU+Linux system
<rekado_>but the system service obviously only makes sense on Guix System
<PotentialUser-66>Hi, doe anyone know off hand a 'package' that uses no (source ()) but uses native-inputs. I have some interwebs example that uses (source #f) but guix seems to be spitting the dummy.
<PotentialUser-66>I just want to see the build setup they use.
<nckx>PotentialUser-66: Plenty! One clear one is unicode-emoji in (gnu packages unicode).
<nckx>‘No source, unpack these things, done.’
<PotentialUser-66>nckx: that is the copy build system right?
<nckx>trivial-.
<nckx>It might be portable to the copy-, most things just predate it and work fine.
<PotentialUser-66>Okey great I think I need trivial because I need to setup some symlinks.
<PotentialUser-66>nckx: checking unicode packages
<alextee[m]>rekado_: nice thanks
<mbakke>nckx: patches cannot be conditionally applied
<rekado_>only by doing the application in a build phase
<nckx>I'd noticed.
<bricewge>lprndn, rekado_ : What are we deciding here then?
<janneke>alextee[m]: you can run guix system on several vps's, using the "guix-infect" meme, for inspiration see https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/machine/digital-ocean.scm#n190
<nckx>mbakke: See the manual quote above, but phases work fine.
<nckx>Really? We're going with ‘infect’?
<janneke>we may want to factor-out guix-infect, i kinda like it
<nckx>Liberate, augment, upgrade, even borgify, …
<bricewge>janneke: +1
<janneke>nckx: too late, already in mastert
<janneke>or, "someone" could factor-out and do a stealthy rename
<nckx>Yuck. ☹
<alextee[m]>oh wow janneke: i might just try digital ocean with this then
<janneke>nckx: well, it spreads, so...
<nckx>I'm all for anti-marketing but this is just masochism. 😛
<pkill9>infect is funny
<bricewge>alextee: Good luck, I didn't managed to use it.
<pkill9>how about "guix taint", "guix poison"
<pkill9>or just "guix spread"
<janneke>bricewge, alextee[m]: in the end, i ran guix-infect by hand on digital ocean
*pkill9 is just looking up synonyms for infect
<janneke>that was ~1y ago
<nckx>guix ice-9-obscure-nerd-meme.
<rekado_>bricewge: I’m working on the greeter-aware, cond-augmented lightdm-service-type now
<apteryx>what is guix-infect?
<bricewge>apteryx: It's a script which replace the host system by Guix system
<lprndn>rekado_: Just passing by with a quick idea in case it helps. A greeter record could contain its own processing procedure in a hidden (non documented) field...?
<bricewge>Spelling it out lout, it does sound evil.
<apteryx>bricewge: I see!
<rekado_>the name comes from https://github.com/elitak/nixos-infect doesn’t it?
<bricewge>Parasitoid: “A parasitoid is an organism that lives in close association with its host, at the host's expense and results in the death of the host.”
<bricewge>I suggest guix-parasitize
<bricewge>Let's not fool anyone, it will end badly for the host host system!
<janneke>bricewge: well, after the reboot the host is gone
<janneke>ah, right
<kmicu>WHoa, Maxim has contributed btrfs subvolume support. 🎉 Thank you!
<apteryx>guix-pwn
<nckx>The whole disease metaphor has aged rather poorly.
<bricewge>nckx: It's not a metaphor it's a lifestyle :p
<janneke>yeah, we're actually making the host more guix-aware
<apteryx>kmicu: my pleasure :-)
<rekado_>nckx: agreed
<kmicu>Are you Maxim apteryx?
<rekado_>I think “guixify” has a pleasant “thisness”.
<apteryx>I am!
<kmicu>Thank you so much apteryx. You are doing an amazing job. And double thank you for an excellent documentation!
<bricewge>apteryx: Thank you, I'm really happy to see #37305 merged!
<apteryx>eh, thanks for the kind words! :-)
<apteryx>rekado_: I like guixify!
<nckx>I like guixify, though ‘guix guixify’ (or ‘guix ify’) is a strange subcommand if it ever comes to that.
<apteryx>true...
<nckx>Or maybe I like ‘guix ify’, hm. Oh who cares.
<nckx>‘guix me’.
<bricewge>rekado_: So no greeters service-type anymore, instead just a big lightdm-service that grows with each new greeters that gets added?
<rekado_>bricewge: when you put it that way it sounds bad, but … yeah.
<rekado_>there aren’t *that* many greeters, are there/
<rekado_>also, we can probably confine the conds to just a few procedures
<bricewge>At most a dozen or so I guess
<rekado_>we need one that returns the directory containing the .desktop file for a given greeter, for example
<rekado_>that’s a pretty trivial procedure, so I think the ugliness can be tamed
<raghavgururajan>Hello Guix!
<bricewge>Hey raghavgururajan!
<raghavgururajan>Is it possible to run dbus-daemon inside build container? Just like xorg-server-for-tests?
<bricewge>It would be useful, I remember some package with disabled tests because of it.
<jonsger>do I need to update the guix package itself when adding a new service?
<bricewge>rekado_: Compared to what I suggested lprndn to do (separated greeter types) it's not so bad
<nckx>jonsger: Wouldn't that be a side-effect of adding a system test hint hint? 🙂
<haha>- 'install' phaseguix system: error: cannot close compressed log file (BZip2 error = -6)
<jonsger>nckx: ?
<bricewge>rekado_: I'll like to be able to discern when to apply a pattern and when to do without it. As you are doing here.
<haha>I am guix reconfigure xxx.scm on my Guix System, but it has such an error, am I doing something wrong?
<bricewge>rekado_: How would the interface look like for lightdm-service-type with your work?
<apteryx>what is the error? can you paste it to paste.debian.net?
<raghavgururajan>Also, what would be the difference, if I use (invoke "Xvfb :1 &") instead of (system "Xvfb :1 &")?
<haha> https://paste.debian.net/1148132/
<raghavgururajan>woah! It worked.
<raghavgururajan>bricewge (system "dbus-daemon &") worked for tests
<raghavgururajan>\o/
<jonsger>nckx: I dont understand your answer
<bricewge>raghavgururajan: Thanks, I'll try it
<rekado_>invoke is like system*; it takes the executable as a first value and any arguments as separate values
<rekado_>“system”, on the other hand, takes the given string and runs it in a shell
<apteryx>haha: it seems your problem is with a non-free kernel, which is not supported by Guix. You'll have to seek support where it originated from.
<raghavgururajan>rekado_, Thanks!
<rekado_>generally, you should avoid “system” when “system*” works fine
<rekado_>but for features that involve the shell (like “&”) it’s fine to use it.
<apteryx>haha: You could try adapting your config file to use the supported linux-libre Guix package, and if it fails similarly, we'll have something to work on.
<raghavgururajan>I see.
<raghavgururajan>rekado_, I think (system "dbus-daemon &") never used before. I am glad it worked on my first attempt. ;-)
<haha>This non-free kernel is defined by myself
<apteryx>haha: I'd suggest the same advice; to validate that the problem lies with your package definition
<apteryx>(or not)
<haha> https://github.com/nniixxoossccnn/my-guix/blob/github/packages/luhux/packages/linux-nonfree.scm
<haha>this is my defineition. I am not quite sure if it is wrong.
<haha>There is no error in guix system init, but this error occurs in reconfigure
<haha>I do n’t quite believe that it ’s the package definition error, because it shows the error when bzip2 compressed the log.
<kmicu>Iirc blobs were removed from upstream kernel Linux so the kernel is libre but not fsdg compliant ‘cuz it steers users into loading blobs.
<apteryx>haha: note that you won't get support for a non-free related issues here. Did you try to adapt your config to use the linux-libre Guix package to validate that your custom kernel package is actually the problem?
<kmicu>(So calling upstream kernel nonfree instead nonfsdg seems excessive.)
<apteryx>kmicu: I don't think that's true (that the blobs are all neatly separated from the kernel)
<apteryx>if you read the linux-libre unblobbing scripts, you'll find code that strips blobs embedded in source files
<kmicu>They moved blobs away into a seperate repo iirc.
<kmicu>apteryx: I need to check that for sure but I think today deblobbing script removes blobs loading machinery.
<haha>I also want to use libre's Linux kernel, but my laptop doesn't want to.
<apteryx>My experience with laptops is that usually it's a matter of finding a secondary wifi card
<kmicu>(Iirc https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ exists now for blobs but it would be nice to see the details. Even with blobs removed upstream kernel cannot be included into Guix ‘cuz FSDG issues—so no changes here.)
<jayspeer>is python3.7 still available? I need it for something :)
<mbakke>kmicu: I'm pretty sure the vanilla kernel includes a bunch of blobs that are not in linux-firmware.git, having watched the output of the deblobbing script... What other FSDG issues are you referring to?
<mbakke>jayspeer: you can always access it through 'guix time-machine'
<kmicu>mbakke: that’s possible, alas not clearly stated in https://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/deblob-5.6 Linux‑libre does more than making vanilla kernel libre it also makes it FSDG compliant and complects both tasks. Are you able to spot in the script which parts remove libre code mentioning/loading blobs vs parts really removing blobs?
<mbakke>kmicu: oh looks like you're right, I happened to have an unpacked tarball around and could not find any blobs, so the deblobber only removes the blob-loading facilities
<mbakke>then I'm not sure that vanilla Linux actually violates FSDG
<rekado_>wasn’t *user-controlled* blob loading a missing feature in linux-libre?
<rekado_>can vanilla Linux be told to not load blobs *by default*? Because that would make it FSDG-compliant, wouldn’t it?
<raghavgururajan>I have been trying to patch the source using substitute*. But the patch does not get apply, when I check with guix build -K.
<raghavgururajan> https://disroot.org/upload/vGfxhwESgogTz9-A/diff.txt
<raghavgururajan>That's the diff.
<raghavgururajan>The target package is malcontent.
<kmicu>(That thing in my mind is clear: vanilla kernel Linux spams dmesg with ‘load this blob’, ‘searching for a blob’, it’s source code also mentions blobs and steers me into them. So that part of Linux-libre deblob scripts is sweet. I’m just uneasy about calling vanilla kernel Linux ‘nonfree’ after they moved (notall?) blobs into linux-firmware around 4.4. I personally have troubles with reading with confidence the deblob shell script.)
<raghavgururajan>I am removing the line 569 in the mentioned file. But it is not applying.
<nckx>raghavgururajan: \(Escape your brackets\)
<efraim>raghavgururajan: change the line to (("g_assert_nonnull \\(appinfo\\);") ""))
<nckx>jonsger: Never mind then.
*efraim thinks its two backslashes
<nckx>Well, 1 for regex, then 1 for Scheme.
<nckx>It's like having pets or children.
<NieDzejkob>in case of bash scripts, unknown escapes are left alone, so \( works
<raghavgururajan>nckx, efraim: Thanks!
<nckx>raghavgururajan: To get the regex to match ‘(’, you need to write ‘\(’. To get Guile to put ‘\’ in a string, you need to write ‘\\’.
<rekado_>I’d like to stop using regex strings in Guix
<NieDzejkob>what would be the alternative?
<rekado_>something like irregex
<rekado_>regex is kinda hard to read on its own, and with all that escaping it gets much worse
<rekado_>there’s no good reason to specify regexes inside of strings
<rekado_>let’s use s-exps
<jonsger>parantheses are hard
<NieDzejkob>that could be a good excuse to migrate substitute* to fail-hard, too
<rekado_>NieDzejkob: yes
<rekado_>jonsger: no
<rekado_>they are curved and soft
<NieDzejkob>lmao. Get yourself some paredit
*rekado_ switched to smartparens in paredit-compat mode
<rekado_>I wanted paredit features everywhere, even when writing Ruby or JavaScript
*NieDzejkob still swears at paredit.vim
<rekado_>I kept deleting the whole line instead of just to the end of the string
<NieDzejkob>(yes, *at*, not "by")
<rekado_>so I finally made the switch.
<janneke>oh, sexp regexp'es that would be nice
*janneke hates guessing how many \ go in
<rekado_>also: many of our substitutions are really just simple string substitutions
<rekado_>so we keep having to escape things without ever benefiting from regex features
<janneke>yeah
*kmicu uses (regexp-quote "^The cat$") => \\^The cat\\$
<rekado_>I thought it would also be nice to have a variant of substitute* (perhaps called “patch”) that applies an inline patch
<pkill9>ooo nice
<rekado_>for those cases where it seems excessive to add yet another file to gnu/packages/patches/ and register it in the Makefile
<NieDzejkob>It would be even nicer if you could interpolate /gnu/store paths into the patches
<rekado_>NieDzejkob: you can with gexps
<pinoaffe>janneke: do you mean like http://synthcode.com/scheme/irregex or an extension of regexes that match sexps?
<pkill9>rekado_: you can define a local-file and use that in the patch specification
<NieDzejkob>rekado_: you mean, for the inline patches?
<pkill9>dunno if that's what you mean
<pinoaffe>ah, yes, like irregex, never mind the question :)
<pkill9>no not a local-file, i mean a plain-file
<pkill9>like this https://gitlab.com/pkill-9/guix-packages-free/-/blob/master/pkill9/packages/love.scm#L23
<nckx>Now that's an embedded DSL.
<rekado_>pkill9: and instead of including all that noise (the lines starting with “diff”, “index”, “---”, “+++” and perhaps even “@@”) we could let “patch” accept a bunch of hunks
<janneke>pinoaffe: dunno, i was merely reacting on what rekado_ said...
<rekado_>civodul once worked on replacing the quasiquoted “arguments” field value with g-exps by default
<rekado_>that would allow us to gexp-unquote at arbitrary points
<rekado_>no need for plain-file indirection
<jonsger>NieDzejkob: there is no package yet for vim-paredit?
<chrislck>wow the font bug is solved... I wonder what fixed it
<nckx>It wasn't the known Pango bitmap boycott?
<kmicu>A boycott? Don Knuth disagrees. 😺
<NieDzejkob>jonsger: I would've packaged it by now if vim plugins were loaded from the profile
<nckx>kmicu: Donald Knuth can go use Metafont.
<nckx>It's not like anyone else does.
<jonsger>NieDzejkob: you can load vim plugins from profile
<jonsger>if isdirectory("/run/current-system/profile/share/vim/vimfiles")
<jonsger> set rtp+=/run/current-system/profile/share/vim/vimfiles
<jonsger>endif
<jonsger>add this to the start of your .vimrc
<janneke>nckx: ...wait, wait
<rekado_>doesn’t lilypond use metafont?
<janneke>anyone with the tiniest bit of typographic sense uses metafont
<janneke>rekado_: of course :-)
<rekado_>:)
***rekado_ is now known as rekado
<janneke>it's very popular amongst typographic experts :-P
<janneke>(both of them)
<kmicu>(and enthusiasts!)
<nckx>Now that is interesting. By ‘experts’, do you mean ‘font creators’?
<nckx>Because that is the exact opposite of my impression.
<nckx>Like, ‘nice maths & cool hack, but fonts don't work the way you CS types think they should.’ Roughly.
<nckx>This is super off-topic I'm sorry.
<nckx>‘Nerds (users) who care a lot about fonts’ I can believe though. But that's just because it has that TeX sheen.
<janneke>nckx: something like that, i guess there's hardly any overlap between those two camps of font creators
<nckx>I can accept that.
<janneke>the camp that uses a shoving device to create fonts are more productive ;-)
<nckx>I'm guessing none of us actually know enough font creators (n > 1) to conclude anything.
*janneke knows two -- well one besides themselves
<nckx>Damn. I've only ever created bitmap fonts.
<nckx>Always happy to hear that, the world needs (many) more free fonts.
<janneke>oh that's right, i know three -- in high school we fixed a font on our cpm machine and burned it to eprom
<janneke>that was hardly anywhere professional, though :)
<nckx>Hold on, then I did create a scalable font (and renderer)… for my Z80 calculator. I iz typographer. Hipsters, worship me.
<chrislck>__/\o/
<janneke>nckx: \o/
<nckx>I'm sceptical that either of you count as hipsters.
<nckx>But pleased nonetheless.
<kmicu>[Jokin’] Show us the dagger in your typeface. That’s the only way to tell whether you are worship‑worthy.
<nckx>The only thing that matters is
<nckx>does Metafont support colour emojies.
<nckx>Silence. Q.E.D. ■
<kmicu>Emojies? That’s so ’10. Variable fonts is the next big thing pushed by corporations.
<kmicu>(But yes, CTAN has colored emojies. https://www.ctan.org/pkg/coloremoji ∎ (QED) with 🎤 (mic drop)
*kmicu logs out ’cuz tempted to stay off‑topic. Typ(ography|esetting) is too hot.
<nckx>Whoa, cool.
<nckx>My resume is about to get 36% more professional.
*nckx kicks nckx for the same reason.
<kmicu>(Pro Tip: for resume use https://github.com/berleon/emojicite 100% hired in any startup in the Valley)
*jonsger wonders if the font hipsters do know what font I need for vim-airline
<kmicu>jonsger: iirc patching fonts with Powerline is necessary to add those fancy glyphs.
<rekado>hmm, reconfigured a workstation and I can no longer shut down
<jonsger>so I need to just package one of those patched fonts and add them to my system config?
<rekado>says “System is powering down” and then “error: connect: /var/run/shepherd/socket: No such file or directory”
<rekado>I guess shepherd crashed due to a match error in one of my services
<rekado>bah
<kmicu>jonsger: yep, and fc-cache -r at least five times for a good luck 😺
<bricewge>jonsger: I packaged nerdfonts but never submitted a patch for it since it looks dirty http://ix.io/2mUJ
<bricewge>Nerdfonts patch fonts with a lot of emoji https://www.nerdfonts.com/
<jonsger>I added font-hack which says it supports powerline but even after times of fc-cache its not fixed
<kmicu>jonsger: did you apply hints from FAQ like ‘Adding let g:airline_powerline_fonts = 1 to your vimrc will automatically populate the g:airline_symbols dictionary with the proper font glyphs for various symbols.’?
<kmicu>(Later you could contribute a patch with a properly configured vim-airline for Guix so I guess that’s on topic.)
<kmicu>‘If you are using rxvt-unicode, try using an odd font size, 11, 13, 15 etc. in your .Xdefaults’, that’s a lot of hacks for a status line xD
<jonsger>kmicu: that makes the status bar even worser
***cantstanya is now known as frank
***frank is now known as cantstanya
<kmicu>Psss you could also switch to https://github.com/Malabarba/smart-mode-line with a eVIl modal editing and first class Guix support xD
<nckx>kmicu: I can see the logic for uneven heights here: you can't have a sharp, symmetrical ❯ in an even number of pixels. And all I know about Powerline is that it has ❯s.
<boeg>why i cant do this: (define xhc1-fix-suspend (simple-service 'xhc1-fix-suspend activation-service-type (...))) and then in my services list of operating-system have (xhc1-fix-suspend), but I can directly have (simple-service 'xhc1-fix-suspend activation-service-type (...)) in my services list? Why are they different?
<kmicu>Only rxvt is affected? BTW we can have a sharp > with an even numebr of pixels on a screen with many pixels (and subhinting), but granetd, not on TIC-80 😺
<nckx>kmicu: I'm assuming bitmap fonts here, I was told they are superior.
<nckx>For some reason my Icecat's monospace font changed to a bitmap one after the core-updates merge, and it's… great. Honestly refreshing.
<nckx>GitHub's readable again.
*kmicu shakes fist ✊ on bitmaps and ASCII.
<KE0VVT>Successfully running a desktop and media server on Guix System for the whole house.
<lfam>Would be cool to hear about how you set up the media server KE0VVT
<lfam>Maybe it could be a cookbook recipe or a blog post :)
<kmicu>With Kodi or something else?
<PotentialUser-26>hi, alll
<PotentialUser-26>On my desktop I have an AMD RX 460 GPU is it compatible out of the box with Guix or I need a specific package?
<cbaines>I believe graphics card functionality probably has a Linux component and maybe something in the userspace as well
<cbaines>I found an entry for a RX 560 on h-node: https://h-node.org/videocards/view/en/1914/Advanced-Micro-Devices--Inc---AMD-ATI--Baffin--Polaris11---rev-cf-
<cbaines>which suggests it works to some extent, which I guess is a good sign
<kmicu>PotentialUser-26: It’s a modern GPU so only basic stuff will work.
<PotentialUser-26>Something like: https://hpc.guix.info/package/xf86-video-amdgpu
<drakonis>its not very useful without the blob
<craftyguy>does guix support/have mirrors? doing 'guix pull' on a default installation nets me a whopping 25KB/s download rate on a connection that can easily do 7MB/s
<lfam>craftyguy: What is it downloading?
<lfam>In general, the answer is yes. Specifically, we need more details to help :)
<craftyguy>lfam: everything. every package it wants to download is super slow
<lfam>Can you give an example of one of those URLs?
<craftyguy>it was like this when I was installing guix last night, I just let it run when I went to bed. but now rebooted into the system the situation hasn't improved
<craftyguy>sure one sec
<craftyguy> https://ci.guix.gnu.org/nar/lzip/l1iakyjw5lacjbnynm6z7b31clyh1llx-ghostscript-9.27-doc
<kmicu>PotentialUser-26: Guix System should load that by default.
<craftyguy>I'm wondering if there are mirrors that are closer to my location (west coast US), or maybe I could set up my own local mirror :)
<lfam>Ah, you are quite from from the server
<lfam>Quite far
<lfam>Yes, we have Nginx configs for setting up your own mirror
<lfam>I'm curious, what is your ping to the server?
<lfam>Check out 'mirror.conf': https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/nginx
<kmicu>PotentialUser-26: maybe you need to set some kernel parameter too so describe your situation in details please. Thank you.
<craftyguy>lfam: ci.guix.gnu.org doesn't seem to be responding to pings from me
<lfam>Oh right, it doesn't do ICMP
<lfam>Anyways, I run my own private mirror, too, although it's a holdover from when the build farm frontend was way too under-resourced in every way
<lfam>We don't recommend it anymore but it will help you with this
<craftyguy>are there other public mirrors set up?
<lfam>No
<reepca`>I'm in midwest US on potato internet but still manage to get decent enough speeds
<reepca`>the only exception is sometimes savannah is slow
<lfam>Right, but that's a different server
<lfam>We did use a global CDN for a while but decided not to continue with it.
<KE0VVT>kmicu: Kodi.
<KE0VVT>lfam: Just "guix install kodi". :P
<craftyguy>lfam: yeah i came across the mailing list thread where that was announced when searching for 'guix mirrors' :P
<KE0VVT>lfam: Well, more like "guix install kodi handbrake libdvdcss".
<lfam>craftyguy: I only got double your speed for that download (350 kbps), from the US east coast. Sometimes it's much faster, I think it depends on factors
<PotentialUser-26>kmicu: I just mounted on a x86_64 Guix system an Radeon RX 470, but nothing come up with lspci. Maybe I require some driver package
<craftyguy>lfam: I see, I should just readjust my expectations :)
<lfam>I do think that transit from Germany to western NA is probably a bit crowded these days
<lfam>But, I often get speeds in the multiple megabits
<lfam>You might try traceroute to get more insight
<craftyguy>yep, I did. it takes a long path :/
<lfam>It's 100 ms for me to go from my local international transit point to the first point in Europe
<lfam>Not great
<nckx>There's also WIP (well, unfinished, not sure about the IP part) https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00167.html. That nginx .conf is nice but it's just an HTTP cache, not my definition of a mirror.
<lfam>And then another 100 ms for every hop after that
<KE0VVT>Is Guix ever going to get sued for having libdvdcss available by default?
<craftyguy>yeah it's ~180ms for me, then ~160-180ms for each hop
<lfam>nckx: Right, but if you have multiple clients, it's a big win
<nckx>Sure.
<lfam>It was basically required in the Hydra days
<nckx>I have a similar set-up, it's cool.
<craftyguy>I have a similar setup on my network with squid as a transparent proxy, caching packages downloaded for the main distro I use
<craftyguy>won't work in this case since guix wants to use https
<nckx>lfam: Do you notice any slowness specific to ci.guix compared to the rest of euronet?
<lfam>I wouldn't really notice nckx
<nckx>It's ridiculously slow here compared to what we should get.
<nckx>OK.
<craftyguy>15KB/s on this: https://ci.guix.gnu.org/nar/lzip/sc7z07gim1iq5zvfz1amdwf2irxrzifg-guile-2.2.6
<lfam>I noticed rekado and civodul debugging speed issues in `guix publish` the other day, they found some major improvements
<craftyguy>like it's 2003 all over again
<lfam>That's bad but it may be a cache miss, since that's an older version of Guile. Not sure...
<reepca`>for me it gradually ramps up to around 400 KiB/s
<lfam>But again, I wonder about cross-continental speeds in NA right now
<lfam>There's a lot of TV being watched
<lfam>And video chats
<nckx>Here it ramps *down* from ~20 to ~2 MiB/s. Suspect.
<nckx>Good point lfam.
<craftyguy>why is it fetching an old version of guile?
<lfam>I haven't seen any research about it, but I can't imagine there's any slack, since residential ISPs were already totally oversold
<reepca`>although I should mention any behavior specific to my system is suspect, since the cord is still held together basically with tape...
<nckx>craftyguy: We can't say, but not everything has moved Guile 3 yet.
<nckx>*to
<lfam>craftyguy: Current Guix is based on Guile 3, but a handful of Guile packages are still using Guile 2.2.
<craftyguy>oh I see, that's expected
<lfam>But sometimes people install the previous version of Guix for reasons and then hit issues like this
<craftyguy>this is my first go at using guix, so I don't know what to expect :P
<lfam>Well... sorry it's being slow for you.
<nckx>Our network infra is certainly not… ideal.
<lfam>We know it's an issue and are working on it internally
<craftyguy>I just grabbed the iso for 1.1.0, installed it, rebooted, and 'guix pull'
<lfam>Okay, that's the right move
<craftyguy>no need to apologize about the network speed
<kmicu>KE0VVT: risk is negligible and because Guix is Europe based even more negligible.
<lfam>You might reply to that CDN discussion thread craftyguy, with your findings. It can help us decide if we should reinstate the CDN service
<nckx>Yeah, numbers like ‘15 KiB/s’ are sobering arguments.
<craftyguy>this is the only one I found, talking about the announcement: https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00403.html
<craftyguy>is there another thread where it was discontinued?
<nckx>I don't remember it being formally announced.
<KE0VVT>kmicu: Good, because I love just doing "guix install libdvdcss".
<nckx>I think we ran out of budget (not money) and that was it.
<craftyguy> https://lists.gnu.org/archive/html/guix-devel/2017-02/msg00161.html
<pkill9>does there exist a distribution called "OasiOS"?
<craftyguy>ah ok
<lfam>Basically we were blowing our monthly budget
<lfam>Or whatever the timeframe was
<lfam>Ah, I see the discussion was private to Guix sysadmins. Anyways, an email to guix-devel could be worthwhile
<nckx>I think so. A CDN is nice, it's also a money furnace.
<craftyguy>for some distros, setting up a mirror is basically just having a cron job rsync from some central repo periodically, and then throw on an http interface (e.g. nginx). if it's that easy for guix, maybe volunteers could set up mirrors to help ease the load a little?
<nckx>I wonder what kind of problems rekado ran into with rsync. I really think a ‘CDN’ is a bad fit for us, so many institutions and even individuals would be willing to donate a mirror.
<lfam>There is also work being done to set up an rsync mirror for China
<lfam>I don't know what the status is, however
*nckx answered craftyguy's questions unwittingly.
<lfam>Heh
<craftyguy>I have a mirror for Alpine Linux (well, a derivative of it), on a $5/mo VPS that serves me and anyone else who wants to use it. for example
<nckx>I'd host a mirror in a heartbeat if my server wasn't one city over from Berlin 😛
<craftyguy>haha
<lfam>I'm curious why you think a CDN is a bad fit nckx
<apteryx>has anyone experimented with GNUnet? Say, for sharing large files.
<nckx>We don't have an income stream, people/unis are more than willing to host traditional mirrors for free, but they're not set up to handle not the specific kind we currently require.
<nckx>They want drop-in rsync like 99% of other distroes.
<nckx>lfam: If we had a CDN company willing to sponsor us (like Nix IIRC?) it'd be fine. The CDN model's not technically a bad fit, just not cost-effective IMO.
<lfam>Since we can share content-addressed subsitutes with Nix, I wonder if we could ... sneak into their cache
<nckx>Lol.
<lfam>Already my Guix downloads things from them occassionally
<nckx>Rite.
<lfam>Well, it's a funny idea but most of our stuff is not content-addressed
<boeg>why i cant do this: (define xhc1-fix-suspend (simple-service 'xhc1-fix-suspend activation-service-type (...))) and then in my services list of operating-system have (xhc1-fix-suspend), but I can directly have (simple-service 'xhc1-fix-suspend activation-service-type (...)) in my services list? Aren't they practically the same?
<reepca`>boeg: it looks like you've defined xhc1-fix-suspend to be a service instance, not a procedure, so I'm not sure why you're writing it as (xhc1-fix-suspend) in your services list, it should just be xhc1-fix-suspend, no?
<boeg>reepca`: oh. I suck.
<nckx>boeg: Modulo syntax errors it works fine.
<nckx>Promise.
<boeg>nckx: Modulo syntax errors?
<nckx>An affectation for ‘excluding’.
<nckx>Test.
<reepca`>pong?
<nckx>ack
<nckx>(Thanks. And sorry for the noise.)
<boeg>nckx: ah
<boeg>nckx: ill remember that
<reepca`>also, if someone could look at http://issues.guix.gnu.org/40806, that'd be great. Been around a month and it looks like a simple enough fix.
<nckx>reepca`: Not to be dismissive, but why no patch since it looks trivial?
<reepca`>because my work tree is messy and I'm paranoid about losing something since I haven't committed in so long
<reepca`>I guess I could use my separate guix-master clone now that I have that
<nckx>No problem.
<apteryx>reepca`: you might also like git worktrees
<nckx>Worse: you'll love 'em.
<apteryx>I'm just too lazy to have automated adjusting all of the Geiser related vars set in my ~/.emacs, so I tend to not use them unless I have to.
<lfam>+1 for git worktrees
<lfam>If branches are too expensive then worktrees are the answer
<apteryx>reepca`: also, a simple advice: commit, even if things are in flux. It's too easy loosing uncommited work.
<apteryx>or at least save it in the stash
<apteryx>magit makes this easy, I don't know about 'git stash' from the CLI (it seems not, perhaps I'm not reading right).
<apteryx>ah, it's there
<apteryx>git stash push, git stash apply
<bricewge>nckx: Could you have a look again at https://issues.guix.info/issue/40367 it's quite trivial
<bricewge>BTW could I push such patch without a review of the actual patch?
<efraim>it depends on how confident you feel about it :)
<sirmacik>mbakke: still no substitutes >L
<sirmacik>>:
<nckx>bricewge: I don't think this patch was trivial in its effect (not huge either, but still). But after review, sure
<efraim>I find I'm often pretty hard on myself and really over nitpick my own patches more than others' patches
<nckx>And it's appreciated. But don't be *hard* on yourself.
<nckx>bricewge: Apologies for my absence, by the way. Unforgivable self-indulgence.
*bricewge just saw a an extra patch in it's patch
<boeg>So I have installed some stuff with `guix install` and then afterwards added it to my config. Now I have reconfigured my system so they were installed on "system level" - is there a command to delete stuff from user level that is also installed on system level so I don't have e.g. two of the same gimp installed?
<nckx>I don't have time to review/think now but if you think the patch is bug-free go ahead & push, bricewge.
<nckx>boeg: No. Just do (or script) it yourself.
<Kozo>boeg: guix package -r <package>
<Kozo>boeg: or guix remove <package>
<bricewge>nckx, efraim Thanks, I'll wait wait for reviews for such patch then even if they seems simple
<boeg>Kozo: alright
<bricewge>nckx: No worry, anyone seems to care about this bug and from my point of view it's fixed
<nckx>bricewge: ‘Simple’… hm, matter of opinion I guess. I still think this was a (slight) change in behaviour, not a bugfix. And I'm certainly glad you're pushing v2 and not v1.
<nckx>Printing progress to non-tty stdout just ain't right.
<thorwil>hi! so i could use ocr, which is quite an exception. guix package -s led me to tesseract-ocr. now trying it in the most naive way, i get: “Error opening data file /gnu/store/y3ci4m2vvbmc5nk3jvc28n29qmn8camx-tesseract-ocr-3.04.01/share/tessdata/eng.traineddata”
<thorwil>the path exists, but has no *.traineddata at all
<thorwil>i see no trace of a separate package for any language
<reepca`>thorwil: if I remember correctly you need to download the training data separately and export TESSDATA_PREFIX
<reepca`>I think our package is also somewhat outdated, and so it might be tricky to get training data for its version
<thorwil>that’s what i started to worry. their docs suggest that other distros have “tesseract-ocr-eng” and so on. time for apt-get, then :/
<thorwil>thanks, reepca`
<reepca`>👍
<rekado>nckx: there’s only one small problem with rsync daemon: we need to make sure that “guix publish” generates files that are readable so that rsync users can access them.
<rekado>that’s really all that’s missing
<rekado>craftyguy, lfam There’s likely a problem with the data centre firewall
<rekado>it’s not a problem with the server, which is connected with 10G
<rekado>internal connections are also pretty fast; so I think there might be some silly traffic shaping in effect
<rekado>unfortunately, that’s not under my control and I have asked the network team to double check the firewall settings.
<rekado>another server on the same subnet is *not* affected FWIW
<craftyguy>rekado: yeah I don't know anything about your setup over there, but considering there were >18 hops when I traceroute'd it, my money would be issue(s) between my wall and your datacenter
<rekado>until then I guess I’ll have to bear the complaints
<craftyguy>each hop taking ~160-180ms once it got over the atlantic is a bit silly
<nckx>That doesn't sound excessive?
<nckx>Not great but not silly.
<craftyguy>probably as lfam said, people watching netflix/porn overloading the tubes
<rekado>the ramp down from 20 to 2MB/s has been observed even in the same city, and it only happens when the firewall node is involved
<craftyguy>I don't know, I am not at the system now, but there were something like >8 hops taking that much time
<rekado>I wish I could just tell them to exempt ci.guix.gnu.org from their annoying firewall, but no dice
<nckx>craftyguy: I must not understand your complaint. The last time I had an (admittedly cheap) server in Miami pings were over 100ms. An extra 60-80ms on top of that (I'm assuming you're deeper inland than that, and we know the MDC network is less than stellar ATM) is not out of this world.
<craftyguy>nckx: my complaint is the really slow download speed I see from ci.guix.gnu.org. the ping/hop latency thing may/may not be related to that. but high latencies between hops can lead to TCP throttling back I think..
<nckx>OK, but 160ms total just isn't that high.
<reepca`>methinks "each hop taking Xms" is being understood to mean "N hops taking (X * N)ms", no?
<craftyguy>it could be a red herring, or there could be other things causing the problem (slow DL speeds)
<nckx>reepca`: Possible, but improbable.
<nckx>That's it's happening I mean, no idea what is meant 🙂
<nckx>craftyguy: Is that it?
<craftyguy>reepca`: I don't think that's a correct interpretation, but tbh I don't know what is
<nckx>160 + 160 + 160?
<nckx>Ohgood.
<alextee[m]>so i just installed mingw, but where is the cross compiler?
<craftyguy>yeah sorry for the confusion. the problem is slow download speed from the official repo. I pointed out the hop latencies in case it was related somehow (because they seemed high to me), but I don't know what I'm talking about :D
*reepca` only discovered the existence of traceroute a month or so ago and was initially confused by the way hop latency was reported
<alextee[m]>i installed mingw-w64-x86_64 but it doesn't have any bin dir with gcc and friends
<nckx>reepca`: How networks work in practice doesn't always make it obvious that they're cumulative. There's often some weird outlier in the middle (that doesn't affect your real path) or bizarre MPLS phantom packet loss or…
<alextee[m]>does it only have libraries and im supposed to build the cross compiler myself?
<nckx>alextee[m]: Yes.
<nckx>‘Building myself’ is a big word for calling CROSS-GCC though.
<alextee[m]>is there a reason we dont package the mingw compiler suite for x86_64?
*alextee[m] is looking for a nice environment to cross build stuff so he doesnt have to resort to using windows again (with msys2)
<alextee[m]>so far msys2 is the only thing that seems to work without requiring a lot of effort ... o.o
<rekado>I pinged the network team, pleading my case once more, and even boldly asking for a blanket firewall exception
<rekado>at this point it doesn’t hurt to ask…
<rekado>thorwil: could you please send email to bug-guix@gnu.org to report that the training data might be missing?
<mbakke>sirmacik: substitutes should be available now, there was a commit that caused a new rebuild recently
<sirmacik>oh, ok. thanks
<mbakke>alextee: I think bitcoin does cross-builds to windows from Guix, perhaps dongcarl has some tips on how to set up the cross-compilation toolchain
<mbakke>meson-build-system currently does not support cross-builds though
<dongcarl>alextee[m]: Let me dig up a link for you
<dongcarl>alextee[m]: Here's how we do it: https://github.com/bitcoin/bitcoin/blob/9abed46871a7f44277a0a59c645a8593ce9e5628/contrib/guix/manifest.scm#L123-L151
<dongcarl>This procedure should probably be upstreamed, and I will take a stab at it at the next opportunity
<alextee[m]>mbakke: dongcarl nice, thanks! it looks pretty promising, although im not sure how these things are supposed to work at the low level so this looks a bit cryptic to me. having some sort of build system or wrapper to handle the low level stuff would be awesome
<alextee[m]>meson already supports cross files but it expects you to pass a few paths to binaries and pkgconfig libdir etc...
<alextee[m]>so i'd expect those to be set up by a build system or wrapper or something
<alextee[m]>and have some sort of special prefix for everything built with this toolchain or something
<dongcarl>alextee[m]: Another place that could be worth looking into is the nsis package in (gnu packages installer)
<alextee[m]>nsis is for creating installers right? dongcarl:
<dongcarl>because the nsis package requires a cross compiler as a runtime dependency
<dongcarl>right!
<alextee[m]>ok i see the nsis stuff, thanks
<mbakke>alextee: setting up the cross files should be done by meson-build-system. I tried doing it a while back but ran into complications because Meson propagates the target Python, but needs a native one, and is unable to work with a wrapper ...
<mbakke>alextee: you might be able to hack something together without support from meson-build-system though
<alextee[m]>what about things using autotools? there's a lot of gtk dependencies for example using autotools
<alextee[m]>it would be nice to have some sort of mingw package management system in guix, like we have ruby and python packages
<alextee[m]>something like msys2, except it doesn't need windows!
<alextee[m]>im able to package a lot of stuff, but i dont have much knowledge about linking and object files and whatnot so hacking at that level is probably outside my expertise
<alextee[m]>like you'd install a mingw-w64-gtk3 guix package and then you could just link to it
<mbakke>alextee: autotools and CMake projects should be fine
***reepca` is now known as reepca
<mbakke>is it just me, or do cuirass evaluations complete much faster now?
<defaultxr>hi, according to https://guix.gnu.org/blog/2020/gnu-shepherd-user-services/ shepherd can be used for user services. it seems to work for me, but only if i run 'shepherd' manually after logging in. what's the recommended way to make shepherd automatically start for my user when the system boots? i'm using the guix-system-vm-image-1.1.0.x86_64-linux in qemu if that matters.
<defaultxr>and while i'm asking, is there a recommended template /etc/config.scm to start from for this qemu image?
<jonsger>defaultxr: yes in gnu/system/examples/vm-image.tmpl
<gignomai>hey all! i was wondering if there was a way i could connect to wifi manually and then run the terminal based interface after
<mroh>nckx: thanks for the review of mediainfo. i havent tested, if updating in 2 patches work, will do now...
<nckx>Yay, saving me work, I approve. Thanks.
<nckx>mroh: By the way, I said ‘new version scheme’ in my mail but that's false. There totally was a 18.12 lib release <https://github.com/MediaArea/MediaInfoLib/releases>, ours was just massively out of date I guess?
<nckx>Anyway, that seems to imply that they're not to closely intertwingled.
<nckx>too, even.
<peter_>hey guix
<mroh>hi peter_
<mbakke>can I get some reports on whether 'guix build --check util-linux' works for everyone? there is a bug report about a test failure that looks kernel-related, but I'm not able to reproduce it on 5.6.7.
<mroh>nckx: you are right, mediainfo@18.12 builds and runs w/ libmediainfo@20.03 => 2 patches inc ;)
<nckx>mbakke: Ah perfect, I was unable to build util-linux on aarch64 just now, prolly this.
<mbakke>o_O
<nckx>?
<Kozo>mbakke: My build failed. Where do you want the log?
<mbakke>Kozo: what is your /proc/version ?
<Kozo>mbakke: Linux version 5.6.12 (nixbld@) (gcc version 7.5.0 (GCC)) #1 SMP 1
<mbakke>nckx, Kozo: are the failing tests from "ipcs"?
<nckx>ipcs: mk-rm-ms, yes.
<nckx>mbakke: Why the o_O?
<civodul>mbakke: 3 test failures for me (x86_64): https://paste.debian.net/1148198/
<Kozo>mbakke: I don't know what that means. this is my errors https://paste.debian.net/1148199/
<mbakke>nckx, civodul: what's your /proc/version ?
<nckx>Linux dmitri 5.4.41-gnu #1 SMP 1 aarch64 GNU/Linux
<Kozo>civodul: Beat me by 1!
<nckx>Linux version 5.4.41-gnu (nixbld@) (gcc version 7.5.0 (GCC)) #1 SMP 1
<civodul>mbakke: 5.4.39-gnu
<civodul>Kozo: yay! ;-)
<civodul>so, what do we win?
<civodul>sounds like a tmpfs thing maybe?
<mbakke>is the build working for anyone at all? :-)
<civodul>ah, the person who has a working build wins
<civodul>i see, it's a scam
<civodul>is there a more detailed log somewhere in the build tree?
<nckx>Also fails on a 5.6.0 kernel totally different from Guix's configuration.
<nckx>civodul: I'm building with -K but it's aarch64 so please ninja me.
<civodul>oh everything's in tests/output
<civodul>ipcrm: failed to parse argument: '0x73e4f431
<civodul>0x73e4f431'
<civodul>(with a literal newline)
<mbakke>yes, same as reported in https://issues.guix.gnu.org/issue/41384#2
<mbakke>nckx: interesting that it fails on 5.6.0, probably not a kernel regression then since it works on my 5.6.7 and not kozo's 5.6.12
<mbakke>it also works on Berlin's 5.4.23-gnu
<nckx>N.B. my 5.6.0 is a heavily-, heavily-patched home-brewn thing. I wouldn't assume it fits nicely in a linux-libre line-up feature-wise.
<civodul>"ipcs -q" returns the same key several times for me
<mbakke>civodul: does 'ipcs -a' return sane output on your system? not sure where those tests go wrong
<mbakke>oh nice timing :P
<civodul>yeah so i don't know if that's supposed to happen
<nckx>civodul: What is ‘ipcs -q’ supposed to print? Here it's an empty table.
<nckx>The hex number is different between two subsequent ‘guix build’ runs so not sure what you mean by ‘the same key’.
<civodul>nckx: it's supposed to least IPC "message queues", and the tests creates them
<civodul> https://paste.debian.net/1148202/
<nckx>I just ran the build twice and neither ‘ipcs -q’ nor ‘sudo !!’ show anything.
<cbaines>util-linux builds for me
<nckx>civodul: Heh?
<civodul>aah, cbaines is the winner!
<civodul>wait, prove it!
<cbaines>although I don't know when I pulled last...
<cbaines>is this the right output? /gnu/store/j3vz21b9xgf244z1ivllj61i8975qx6r-util-linux-2.35.1
<nckx> https://paste.debian.net/plain/1148204 for those unsure what ‘empty’ means.
<civodul>cbaines: yup
<civodul>nckx: that looks like emptiness
<nckx>Please send your kernel version and credit card numbers.
<civodul>:-)
<civodul>but note that i built with -K, then ran "make check" in the build tree
<nckx>Oh.
<nckx>(I'd never heard of ipcs before this moment, why do you all so casually know it…)
<cbaines>So I'm running Linux 5.2.21-gnu
<mbakke>cbaines: what is your /proc/version?
<cbaines>"Linux version 5.2.21-gnu (nixbld@) (gcc version 7.4.0 (GCC)) #1 SMP 1"
<cbaines>I'm using a older version of Linux as I found newer versions had graphics issues
<nckx>OK, yeah, I get to queues with that ID.
<Kozo>mbakke: My kernel is nongnu if that helps your testing
<nckx>*two wtf.
<jonsger>I'm with nckx at this linux failing party
<nckx>Yay! It's like an installfest but with puzzles.
<civodul>nckx: i don't really know, it looks arcane to me
<mbakke>jonsger: kernel version? still haven't found a clear common denominator
<jonsger>5.4.41 like ncks
<nckx>jonsger: Arch though?
<nckx>My 5.4 was aarch64.
<jonsger>amd64
<cbaines>would any output from the successful build be helpful?
<mbakke>cbaines: it's available here too: https://ci.guix.gnu.org/log/j3vz21b9xgf244z1ivllj61i8975qx6r-util-linux-2.35.1
<nckx>cbaines: Is your success reproducible?
<cbaines>We'll never know for sure :) but I'll give it another shot
<cbaines>Where's it failing for others?
<civodul>ipc tests
<nckx>cbaines: Test suite, 3 failures, all 3 ‘ipcs: mk-rm-shm’ or similar.
<cbaines>It's worked 3 times now, this is on a system with 6 cores/12 threads
<cbaines>When testing the Guix Build Coordinator stuff recently, I think I hit a problem with building coreutils on machines with only one core, the tests seemed to fail there.
<cbaines>It worked fine on machines with multiple cores.
<cbaines>Hopefully doing lots of builds across different hardware and software setups will allow flagging some of these issues/peculiarities automatically
<nckx>I'm building with --cores=1 to see what happens (and that is: it takes forever).
<cbaines>I wonder if we could do something in the future where --cores=1 actually restricted the number of cores in whatever Linux namespace manages that
<cbaines>Then you could build guile-fibers on a machine with multiple cores :D