IRC channel logs

2022-06-21.log

back to list of logs

<the_tubular>Ur Telcome
<the_tubular>I think it's the same guys that create the package called command-not-found
<the_tubular>It's installed by default on debian and other distro.
<the_tubular>This one : https://packages.debian.org/sid/command-not-found
<nckx>I didn't know it was its own project.
<nckx>I thought it was just an alias to whatever distro package manager was use.
<nckx>*d, even.
<nckx>Ah, it is at once more of a thing & less of a thing than I thought.
<the_tubular>I don't know what that means, but sure.
<nckx>I don't think you're expected to.
<nckx>Anyway, the only time I encountered it personally was on some minimal system that barfed a pointless ‘command-not-found: command not found’ when you typoed something. That was long ago.
<the_tubular>I installed termux yesterday and unninstalled the command-not-found package and got the same error :P
<nckx>the_tubular: I meant that, one, I didn't realise it was its own full-blown package, but two, then was surprised it seems(?) to be just a Debian thing, not a cross distro-effort.
<the_tubular>Well, there website support a few distro
<nckx>Are they related?
<the_tubular>But yeah, seems to be focused on debian/ubuntu
<the_tubular>I think so didn't confirm.
<nckx>(…am I missing a prominent ‘About’ link? Am I blind?)
<the_tubular>Yeah, 404's
<gabber>i configured a home-openssh-service. `guix home container config.scm` and trying one of the ssh rules i get "Bad owner or permissions on /home/gabriel/.ssh/config". owner is pid 65534, group (name?) is overflow. is that a bug?
<civodul>gabber: hi! i noticed that within the container, but it's fine otherwise
<civodul>that's because /gnu/store in the container is owned by the "overflow" user
<gabber>hi! so it is not possible to check whether the home-openssh service works in the container?
<z20>Hello. I've been having some difficulty getting Guix System running on both a Librebooted Thinkpad X200 and a stock BIOS T410. In both cases, I was unable to get as far as the GDM login screen, and had an error saying "ACPI (...) BCTG: evaluate failed". After removing references to power services in config.scm, this error no longer shows up, but I still have no graphical login screen. Does anyone know what the origin of this error
<z20>was able to install Guix with the autoinstaller, somehow.
<gabber>is the binary `more` not part of a basic container toolset? `dd` is, `cat` and `echo` are. if so: which package brings `more` along? it's one of the harder tools to search for..
<nckx>gabber: Yes, util-linux.
<nckx>I don't know what a ‘container toolset’ is.
<the_tubular> https://hpc.guix.info/package/util-linux
<nckx>The examples you give are provided by coreutils, gabber.
<gabber>thanks! and i guess coreutils get included with new containers? because they're not part of my home-config
*nckx no know.
<gabber>np
<nckx>z20: You're certainly not the only X200 Guix user… I think raghavgururajan had an X200 with Guix on it at one point? I'm positive there are several, I just don't know who. The last warning or error printed to the console more often than not has nothing to do with graphics problems.
<nckx>Or the poor PC speaker would have been responsible for most of them.
<drakonis>so, i oughta ask now
<drakonis>add a new field to package and/or service records for encoding some kind of metadata?
<gabber>drakonis: what kind of metadata are you thinking of?
<drakonis>metadata related to the kind of application it is, ie: language used to write it, if it is a library, a game, a browser
<drakonis>it is an example
<drakonis>there are other useful things that can be encoded here
<z20>nckx: It seems specifying the Intel i915 driver in my xorg extra-config section was what was causing the problem. Weird. But I have my graphical session again.
<drakonis>ie: ways to tie recommended packages or whether it has subpackages
<nckx>z20: Why weird?
<drakonis>but initially the goal is to encode more information that you cannot solely acquire through the package or service record alone
<nckx>z20: Which package even provides a driver called i915? I've never heard of that.
<nckx>s/driver/X driver/, of course, before some smartypant answers ‘Linux’ :)
<z20>nckx: Whoops. I wrote the config from memory, thought the driver was named more explicitly than just "intel". I guess this was user error in the end.
<nckx>(Phew!)
<nckx>Glad it worx!
<nckx>z20: The kernel driver *is* called that, by the way, it's just not used directly by X.
<nckx>Night-night Guix 😴💤
<gabber>\o
<KarlJoad>My guix-mode package is behaving strangely. Is it better to install that one through Guix rather than MELPA?
<KarlJoad>Also, is there a convenient way to create a symlink for /bin/bash, for random scripts that don't play the portability game?
<bjc>you can use ‘extra-special-file’
<bjc>ie: (extra-special-file "/bin/bash" (file-append bash "/bin/bash"))
<KarlJoad>bjc: Perfect. Thanks!
<bjc>👍
***namtsui_ is now known as namtsui
***Trev[m] is now known as trevdev[m]
<muradm>sneek: later tell unmatched-paren: i provided gtkgreet package and configuration yesterday isn't it? i didn't follow your last discussion, could you make wlgreet working for you? do you need gtkgreet paste bins again?
<sneek>Got it.
<muradm>morning guix
<unmatched-paren>muradm: oh, yeah, you did! /o\ I've nearly got it working, btw :)
<sneek>unmatched-paren, you have 1 message!
<sneek>unmatched-paren, muradm says: i provided gtkgreet package and configuration yesterday isn't it? i didn't follow your last discussion, could you make wlgreet working for you? do you need gtkgreet paste bins again?
<unmatched-paren>hmm, can i assume shutdown is available in a service?
<unmatched-paren>and how would i run it without root?
<unmatched-paren>would 'halt' work?
<unmatched-paren>wait, no, it wouldn't
<scisssssssors1>hi. does anyone know if it's possible to let ordinary users run 'shutdown' and 'reboot'?
<muradm>sudo shutdown does not help?
<muradm>you can configure sudoers to not ask password for specific command/user combinations
<muradm>i trust me :) => muradm ALL=(ALL) NOPASSWD: ALL
<unmatched-paren>muradm: shutdown is being invoked from swaynag
<unmatched-paren>so i can't really ask for password, and i can't really modify sudoers, can i?
<unmatched-paren>ah, you were replying to scisssssssors1 :)
<scisssssssors1>i want to call shutdown from dmenu so i'd like to avoid sudo if possible
<scisssssssors1>NOPASSWD may be the solution but i will also have to alias shutdown to "sudo shutdown" it seems
<muradm>unmatched-paren: both of you :)
<muradm>(sudoers-file (plain-file "sudoers" %local-sudoers))
<muradm>in your (operating-system ...)
<nikola_>scisssssssors1: why would you need to alias
<nikola_>I just had a case statement based on the output of dmenu
<muradm>and %local-sudoers https://paste.rs/KFt
<nikola_>Basically you can pipe whatever you want into dmenu
<muradm>unmatched-paren: under which user swaynag will be called?
<unmatched-paren>muradm: i mean by default :) i think it's the greetd (greeter?) user that calls swaynag
<unmatched-paren>because the man.sr.ht page for greetd gives a sway wlgreet configuration where the option to shutdown or reboot is given through swaynag
<muradm>greeter ALL=NOPASSWD: SHUTDOWN
<scisssssssors1>nikola_: would you provide an example? i know that i can pipe into dmenu whatever but i'd like to stick to dmenu_path
<muradm>then greeter can do "sudo shutdown" without password
<muradm>unmatched-paren: no idea.. never used shutdown from login/lock screen :)
<muradm>this could be useful to read https://wiki.archlinux.org/title/Allow_users_to_shutdown
<muradm>although no systemd, but some description of sudoers
<nikola_> scisssssssors1: https://github.com/Minnerlas/wm/blob/master/skripte/power.sh
<nikola_>I used loginctl but it's the same idea
<scisssssssors1>thank you all :)
<unmatched-paren>muradm: now i get "failed to open /dev/dri/card0: operation not permitted" from the wlgreet sway...
<unmatched-paren>is there something i have to do to get rid of this?
*unmatched-paren afk
<abralek>Hi Guix!
<jpoiret>muradm: I remember greetd lacking the option to lock the session, is that correct
<jpoiret>?
<muradm>jpoiret: greetd does not suppose to lock screen may be is more correct
<muradm>you may ask that from greeter may be, but that is also not its job
<muradm>ah, you mean session, there is no session in libseat/seatd i think in the way it was with systemd/elogind
<muradm>locking seat is lock screen application's job i think
<muradm>swaylock not enough?
<jpoiret>muradm: there is a concept of session in libseat
<jpoiret>seats can switch sessions
<jpoiret>otherwise you wouldn't be able to switch TTYs and open another session on the same seat
<jpoiret>IMO the session locking/unlocking should be handled by the greeter system
<muradm>there is seat disable operation in api
<muradm>jpoiret: greetd -> greeter in your terms "greeter system" i suppose
<muradm>it depends i suppose. job of greeter is to greet authenticate
<muradm>seatd/libseat controlls session and switching
<muradm>then one who is having handles in your session is seatd/libseat
<muradm>you may ask it disable seat may be, but i don't know if any application is currently doing that
<jpoiret>muradm: the thing is, the greeter already has to handle switching VTs itself
<jpoiret>but i guess that a before-suspend action to just switch VT to the greeter VT could be better
<jpoiret>and then use eg cage which disables VT switching
<muradm>jpoiret: how is that?
<jpoiret>when a session starts, greetd starts it on another VT and switches to it
<muradm>VT switching is different thing
<muradm>jpoiret: are you about greetd-service-type and its configuration?
<muradm>if there is a problem, you maybe missing switch-vt flag?
<muradm>other than VT greetd's working does not have in hands
<muradm>imagine greetd with text agreety, then after login you start sway
<muradm>greetd is now aware of devices used by sway via libseat
<muradm>so switching session is not its job imo
<bonz060>Hi!
<bonz060>In guix, how would you work out what installed a specific package? I'm trying to trouble-shoot a python package, and I'm getting something similar to: <https://github.com/pytorch/pytorch/issues/47569>; and I'm trying to work out what package installed "dataclasses".
<jpoiret>bonz060: you can look up where a specific package is propagated manually in the manifest file present at the root of any profile
<jpoiret>there's no CLI for that right now I think
<jpoiret>the manifest file internal to profiles contains a description of all the installed packages as well as the ones propagated in a tree
<jpoiret>are you getting the issue while building a package?
<bonz060>jpoiret: I've actually found how to do that using guix graph. Here's how that command looks like: "guix graph -L /home/bonface/projects/guix-bioinformatics --path genenetwork2 python-dataclasses"
<jpoiret>right, but you need to know which package pulls it in then :p
<jpoiret>there's no guix graph --path PROFILE-PATH PACKAGE
<bonz060>Right. My original problem was that I had a failing build: <https://ci.genenetwork.org/jobs/genenetwork2/273>; and I was trying to work out why some module was installing "dataclasses" in the profile. Thanks though \m/\m/.
<taeaad>If you are using the Guix package manager, does it still make sense to install Python with Pyenv?
***wielaard is now known as mjw
<jpoiret>taeaad: not really, guix is a superset of that
***kinote[m] is now known as kinote
<taeaad>jpoiret: So I should just install a specific Python version with Guix?
<jpoiret>Ah, for python versions it's a bit more complicated, but as long as the python version is packaged in guix you should be able to use it
<singpolyma>I think there is a channel that contains the stuff that guix deletes?
<jpoiret>I don't know the specifics for python though, such as how you would specifiy a different python version
<singpolyma>So if you get that if may be usable as a version manager
<jpoiret>There's guix-past, yeah
<singpolyma>Guix main unfortunately believes in "current version" and "upgrades"
<singpolyma>But the software is very well suited to a version/environment manager with the right channels
<taeaad>jpoiret: I see, OK.
<taeaad>How can I install R (https://www.r-project.org/) packages with Guix?
<taeaad>If I run install.packages() in an interactive session, it says that my Guix path to the library is not readable. Conversely, I don't know how to specify that I am looking for an R package with "guix install" on the CLI.
<nckx>guix package -A ^r-
<nckx>There's also a ‘cran’ importer to ‘guix import’ to help with packages not yet in Guix, but I have no idea how plug & play the output is.
<taeaad>nckx: Do you have a link to that? Some of the CRAN packages I need are not in Guix.
<nckx>Link to what?
<nckx>There's an ‘Invoking guix import’ section in the manual; you'd start with invoking ‘guix import cran UpstreamRPackageName’, which will give you something vaguely resembling a valid Guix package.
<nckx>It's not automagic though, and could almost certainly use improvement.
*nckx away.
<taeaad>nckx: Thanks.
<taeaad>I'm a bit confused. What are the next steps after running "guix import cran xxx"?
***user3456_ is now known as user3456
<taeaad>Do you have to then create a package?
<maximed>taeaad: Have you run "guix import cran xxx"?
<tricon`>taeaad: yes, echo that out to a file.
<maximed>I could give some explanation but it's easiest to give with concrete examples.
<maximed>I have an example ‘in the wild’ -- it's python instead of R, but it's exactly the same system
<taeaad>I mean, I have two options here. 1) Forget about it and use a personal library with the internal command install.packages or 2) Make a Guix package for the libraries that are not available under "guix install r-*".
<maximed>taeaad: For (2), you first need "guix import cran", as you wrote.
<taeaad>maximed: That works for me and I can echo it out to a file.
<maximed>theaad: Could you upload the file at paste.debian.net (makes the explanations easier)?
<maximed>* taeaad
***wingo_ is now known as wingo
<taeaad>maximed: http://paste.debian.net/plain/1244739
<taeaad>This package isn't particularly important to me, but it was a package that I had intented to test out.
<maximed>taeaad: https://paste.debian.net/1244740/
<maximed>In that paste, the package isturned into a package _definition_ (with 'define-public')
<maximed>(not strictly necessary but sometimes convenient and conventional)
<maximed>at the end, there's (packages->manifest (list r-wavelets r))
<maximed>So then you can use that file as a ‘manifest’, containing r-wavelets and r.
<maximed>And if the file is named 'foo.scm', it can be started with 'guix shell -m foo.scm -- r'
<maximed>(if you use Emacs' R mode, add the relevant emacs packages and emacs itself to the list passed to packages->manifest).
<maximed>For a longer example: https://notabug.org/maximed/dimension-reduction/src/master/manifest.scm (that's for Python, not R, but same principle).
<taeaad>maximed: I use ESS which I assume would use r-mode.
<maximed>(You might need to import some additional modules to get it to load by "guix shell", probably (gnu packages statistics) and (guix licenses))
<dhruvin>I sent a patch for hut (a cli tool for sourcehut) some time ago. Can someone please review it? https://issues.guix.gnu.org/54882
<dhruvin>I'm waiting on it to improve guix support for sourcehut's builds.sr.ht service (and for guixrus, that'll use it).
<maximed>dhruvin: At least looking at the latest patches on https://issues.guix.gnu.org/54882 , I still see a single large patch.
<maximed>Also, input labels aren't required anymore: (propagated-inputs (list go-golang-this go-golang-that ...)).
<maximed>The dsrcription fot 'hut' isn't really descriptive -- maybe spell out sourcehut in full and write a little what kind of things it supports?
<maximed>E.g., creating new git repos on sr.ht, looking at the status of CI, making new bug reports / closing them, making new mailing lists (I don't know if those are supported)
<maximed>The go-... native-inputs in 'hut' look suspect.
<maximed>What's the reason for putting them in 'native-'?
<maximed>recommended style for arguments: (list #:this-keyword "git.sr.ht/..." #:phases #~(modify-phases ...))
<maximed>go-github-com-mattn-go-isatty is already upstreamed, see: https://issues.guix.gnu.org/31939
<maximed>nevermind, misread that
<dhruvin>Oh, I misunderstood you when you asked to send a separate patch for cobra. You meant a separate patch for each dependency, right?
<apteryx>jorge[m]: I just sent a patch to add 'phoronix-test-suite'; you could also use this to run benchmarks on your machine, e.g. 'phoronix-test-suite run fio'. It produces nice graphs.
<maximed>dhruvin: There's already a patch for go-github-com-google-shlex: https://issues.guix.gnu.org/47539#28
<maximed>Maybe compare & pick the best description, etc?
<maximed>dhruvin: Yes.
<maximed>(anyway, TBC: I review patches sometimes, but I don't commit them)
<sneek>wb vagrantc!!
<vagrantc>sneek: botsnack
<sneek>:)
<vagrantc>nice to see you too
<dhruvin>I'll add better synopsis and descriptions to hut and its dependencies and send them separately. Thanks again for reviewing these patches, maximed.
<acrow>Welcome to summer guix!
<acrow>vagrantc: I trust all transportation problems were overcome without difficulty?
<vagrantc>acrow: yup!
*vagrantc didn't expect to run into someone into guix in rural cascadia :)
<dcunit3d>how do i find the path for a guix package?
<dcunit3d>i'm trying to run a command, but i need a path to include bc the tool can't find things that are in the guix package
<dcunit3d>i'm running xkbcomp -I$includepath layout.xkb $DISPLAY
<vagrantc>dcunit3d: it should be findable in PATH ... is this your first package you've installed into your profile?
<vagrantc>dcunit3d: you might need to log out and back in again after installing guix for the first time
<vagrantc>er, installing a package with guix ...
<dcunit3d>i'm running guix system and i have several profiles already
<dcunit3d>i've run into this a few times, but i usually just run `find`, then discover there's a better way to do what i'm trying
<berkowski>If you've already built a package you can run `guix build $package` and it will output the store paths
<acrow>Usually I just do 'readlink -f $(which <your_package>)'.
<acrow>berkowski: +1
<dcunit3d>i hope to start building more packages soon. i have a channel set up on my filesystem
<dcunit3d>what if the package doesn't doesn't include a runnable bin?
<acrow>dcunit3d: yes, that's why 'guix build <your-package>' is probably what you want. To avoid a build you might try something like, 'ls -d /gnu/store/*<pkg_name>*'.
<berkowski>I'm certainly no expert, but that store path will look like the /usr root of a normal system, so it'll contain the usual bin (e.g. /usr/bin), lib, etc
<acrow>Though there will likely be choices if you don't do gc often.
<dcunit3d>ah thanks. i've run into this a few times.
<berkowski>Is there a way to set shell environment variables in a "guix shell" manifest.scm?  I'd like set the equivalent of setting "CC=$(which gcc)" after running `guix shell gcc-toolchain`.  The manifest file will install gcc-toolchain for me, but I'd like it to also set a few environment variables
<dcunit3d>there may be some way to do it with direnv, but that's not a great solution
<dcunit3d>i was looking deeper into manifests the other day and i thought i saw something like that, but now don't see it in the docs
<berkowski>Yeah, I came across an old blog post speaking to that.  But I'd like to keep it in the manifest file as it really only affects those using guix to set up the development environment.  I don't need to do anything special if I use system packages
<lechner>Hi, are traductions the same as upgrades? (on mailing list)
<berkowski>fwiw this is due to having to use user-installed rust through rustup because guix doesn't provide alternate toolchains (thumbv6m for me)
<dcunit3d>the manifest record is defined in guix/guix/profiles.scm:204
<dcunit3d>then the environment is purified/defined when the profile loaded in load-profile at line 2032
<nckx>lechner: Translations? Of? Which mailing list?
<dcunit3d>berkowski: you may be able to use a manifest's properties, but i am unsure. one other way that may allow you to set variables is to abuse a manifest's search-paths functionality
<lechner>nckx: <86letqgj3u.fsf@gmail.com> on devel, but it's not on the web yet
<berkowski>dcunit3d: yeah, looking through the parts you listed.  My lisp is... weak... but it looks like I should be looking at the `manifest-entry-properties`?
<dcunit3d>yeh, it's really tough to parse some scheme. the records are fairly straightforward, but the lambdas/macros and gexps throw me for a loop
<dcunit3d>the `guix edit` command helps me navigate the codebase, but i use emacs with lispy, so i can run through it pretty quick.
<dcunit3d>i haven't had enough time to learn scheme yet though, so i'm afraid i can't help you much more than that. there may be a way to get the manifest to evaluate and create an environment with a path.
<dcunit3d>if nothing else, you can craft a package containing a script to place in the guix shell's path somewhere and run that.
<berkowski>I'll try to hunt down a package defintion for something that exports environment variables.  I know git does
<berkowski>see what they do
<nckx>lechner: Thanks, found it. And what's the question exactly?
<nckx>‘Traductions’ is frenglish for ‘translations’.
<nckx>English being of course merely badly-pronounced French.
<nckx>I.e. https://translate.fedoraproject.org/projects/guix/ (come, join, and bring a friend!)
<lechner>nckx: thanks!
<lechner>Hi, as someone who enjoys dlopen'ing things (my PAM hobby) is nscd the wrong hammer for varous dynamic loading hazards in Guix and Nix? More to point, should our modules be versioned?
<maximed>lechner: I don't think that Guix would disable ELF symbol versioning, if that's what you mean.
<maximed>I suppose it would be possible for Guix to compile its NSS libraries against an old glibc (so only old symbols are used, that would be available on other distros as well).
<maximed>Though that only solves the ABI incompatibility in Guix System, it doesn't things on foreign distros.
<maximed>Unless the foreign distro does the same.
<maximed>Even then, dlopen()-ing system things from $user-things sounds fragile w.r.t. time travel.
<maximed>Also, wouldn't work (as-is) when working on multiple architectures on the same computer (e.g. with QEMU, or because the processor supports that -- e.g., x86_64/i686))
<maximed>berkowski,bcunit: On setting arbitrary environment variables: there's a mail for that on the mailing list (I don't remember the subject line)
<berkowski>maximed: thanks.  I had looked before but that doesn't mean the answer isn't there :)
<maximed>TBC, that functionality doesn't exist yet.
<maximed>The mail was a proposal for implementing such a thing.
<berkowski>Ah, so I should be looking on devel?
<maximed>berkowski: yes.
<maximed>I had some disagreements on how it was presented and the implementation (it does more specifically search paths, which are already handled by packages), but having a method to set arbitrary environment variables in manifests sounds good to me.
<berkowski>maximed, dcunit3d:  Think I've got something workable here, and if I can do it then the bar of entry is pretty low :)   I'll throw it up a gist once I comment it some
<berkowski>just in case this gets dragged up by someone else searching
<berkowski>for the (temporary) record: https://gist.github.com/berkowski/c496b796e0956fcb3a213940045e8ebd
<lechner>maximed: sorry, i meant SONAME versioning. Perhaps Guix needs to develop a custom scheme https://autotools.info/libtool/version.html
<maximed>lechner: Guix just uses whatever versioning is already in place.
<lechner>maximed: it's noteworthy that dlopen'ed libraries elsewhere tend to actually avoid versions https://www.gnu.org/software/libtool/manual/html_node/Modules-for-libltdl.html
<maximed>If the upstream software sets a SONAME, then Guix preseves that soname.
<lechner>my point is that the existing versioning schemes, while perhaps insufficient for Guix, could be repurposed to solve globally the issue nscd addresses for glibc
<maximed>lechner: The problem (or at least a problem), is that these modules use other libraries.
<maximed>E.g., the NSS libraries use glibc.
<lechner>right, but ld.so and nscd are two different hammers
<maximed>And they could be using a function that isn't in the glibc used by the application.
<maximed>lechner: I thought the idea was to replace nscd by shared libraries dlopen()-ed from applications?
<maximed>I.e., I thought your proposal was to switch to the ld.so hammer?
<lechner>actually, from what you said that's not possible, right?
<lechner>you are saying that any module must be mated permanently with an executable
<maximed>Is possible. With some limitations (e.g., QEMU emulation probably broken, i686/x86_64), but those could be resolved.
<maximed>And fragile w.r.t.
<maximed>lechner: It doesn't.
<lechner>"And they could be using a function that isn't in the glibc used by the application"
<maximed>lechner: That's why I suggested to compile the NSS libraries against an old glibc.
<maximed>(glibc is pretty backwards-compatible, but not forwards-compatible)
<maximed>However, that's not done (yet?).
<maximed>* w.r.t. -> w.r.t. time travel
<lechner>it sounded to me that Guix imposes additional (generational) versioning requirements in addition to the standard ld.so resolution
<lechner>something we currently do with paths or the environment, i suppose
<maximed>lechner: WDYM with generational?
<lechner>--list-generations
<maximed>which additional versioning requirements?
<lechner>do we not require that shared objects are provisioned by the current generation?
<maximed>lechner: We do not. By default, you don't even have glibc in a generation.
<maximed>Unless you count transitive references.
<maximed>The library loading mechanism doesn't know about Guix at all.
<maximed>(ld.so)
<lechner>should it?
<maximed>lechner: To do what?
<maximed>ls.so doesn't have an use for generations.
<maximed>Binaries (in Guix) refer to their libraries by absolute file name /gnu/store/.../libc.so (not 100% what happens but close enough) via RUNPATH.
<maximed>(or was it RPATH?)
<lechner>is see
<lechner>i see
<lechner>isn't the issue that such a system does not work with modules?
<maximed>You can even run a binary that doesn't belong to any generation at all: "guix shell hello -- hello" or "$(guix build hello)/bin/hello"
<maximed>lechner: You can use modules & RUNPATH
<maximed>SOme applications packaged in Guix support loading plugins (by using dlopen(...) appropriately).
***samplet`` is now known as samplet
<lechner>how can an ELF binary, generally, encode the RUNPATH for all dependent modules?
<maximed>lechner: by passing the rpath option to the linker.
<lechner>such a system is not extensible
<maximed>(i.e., during compile time)
<maximed>lechner: Seems to work well for Guix.
<maximed>what dependent modules DYM?
<lechner>what if you compile the module after the ELF caller?
<maximed>You don't have to put dlopen()-modules in the RUNPATH of the ELF binary.
<maximed>lechner: then you just do dlopen("the location of the module.so"), and it works.
<lechner>do you know the location?
<maximed>lechner: Application-dependent.
<lechner>or generation dependent?
<maximed>lechner: No, applications and the linker don't even know what a generation is.
<maximed>Often, applications look in $LD_LIBRARY_PATH or their own $CUSTOM_PLUGIN_PATH.
<maximed>(i.e., the environment variable)
<lechner>isn't that the issue fir glibc?
<maximed>lechner: What's ‘that’ here?
<maximed>I don't think I've been pointing out any issues here, only that dlopen(...) works in Guix.
<lechner>"applications and the linker don't even know what a generation is"
<maximed>lechner: What could applications and the linker do with that information to solve things?
<maximed>A generation is just a profile with a timestamp, a version number, a location and provenance information.
<maximed>(and a bunch of files)
<lechner>when does an NSS module require a version of glibc that could vary from the version an application was linked against?
<maximed>lechner: They don't?
<maximed>IIUC, a NSS module requires ‘this version of glibc, and I guess any later version will do too’.
<lechner>sorry, not glibc. another library
<maximed>Ditto for other libraries, though I thought this was about NSS modules and glibc, and not libraries in general?
<maximed>* actually, not ditto, many other libraries have a way more unstable ABI
<maximed>Also, what problem are you trying to solve by eliminating nscd in favour of dlopen(...)-ed modules.
<maximed>* . -> ?
<dcunit3d> https://gist.github.com/berkowski/c496b796e0956fcb3a213940045e8ebdhttps://gist.github.com/berkowski/c496b796e0956fcb3a213940045e8ebd
<Guest2655>Hey everyone, I am new to guix, I'm on kernel 5.17.15, is there an easy way to have it use 5.15.47 in the config.scm instead?
<nckx>(kernel linux-libre-5.15) ; will be 5.15.47 as long as that's the 5.15 release used in Guix
<lechner>maximed: i thought it was the module system in NSS was the reason Guix more or less required nscd
<nckx>Guest2655: To use that variable you'll need to import the ‘linux’ package module if you don't yet.
<Guest2655>Thanks, I tried a variation of that but I think I put the full version length heh
<Guest2655>Will try it
<maximed>lechner: It is. As mentioned previously mentioned, dlopen()-ing system things from the user is super fragile.
<maximed>Hence, the much more stable nscd mechanism is used insteead.
<nckx>Guest2655: Don't know how familiar you are with Guix, but yes, there is only one variable name, and here they're called linux-libre-x.y because that's specific enough for our purposes: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/linux.scm#n370
<nckx>No deeper meaning really.
<nckx>Guest2655: Semantically, if you want ‘the latest LTS kernel’ rather than 5.15 specifically, there's a ‘linux-libre-lts’ variable for that. Of course the two are currently equivalent.
<maximed>Though likely nscd dlopen(..)'s it modules under the hood (not sure though, I remember something about static libraries ...)
<lechner>i think it does. the point is that it is isolated from the caller
<Guest2655>Only been using it a few days :) But it's cool so far!
<nckx>\o/
<nckx>Welcome.
<lechner>maximed: isolated from the ld.so resolution in the caller
<Guest2655>Ty
<podiki[m]>nckx: did you resolve your mesa-22 and wayland compliation problem? I still have to submit that mesa v22 patch
<podiki[m]>nckx: which I now see needs another version bump, mesa is moving quick!
<nckx>Actually, I was going to ask you for your latest WIP [again], because I wasn't sure where I was anymore.
<podiki[m]>sure, just submitting a patch to update polybar and then I'll update mesa to 22.1.2 and check
***mark__ is now known as mjw
<nckx>Coolio.
<podiki[m]>and it was the wayland package that wasn't building? or some other wayland thing?
<podiki[m]>nckx: wayland didn't need a new build with my slight mesa version bump, but could try building from scratch anyway. here my current diff: https://paste.debian.net/1244786/
<nckx>Hm. Honestly, I don't remember.
<nckx>podiki[m]: Thanks!
<podiki[m]>wayland built fine with that patch, for me
<ss2>good evening!
<nckx>Hullo.
<podiki[m]>nckx: welcome! I really will submit that patch today, checking the i686 build and will check those various configure flags
<ss2>I should get my patch submissions for Samba fixed actually. I've been away for some time now while completing my school. Should have a bit more time for this now.
*nckx pulls podiki-glorious-mesa branch.
<podiki[m]>I really should name my local branches more exciting things like that :)
<nckx>ss2: Don't know if you saw it (or it's the reason for your message), but somebuddy was asking about them yesterday.
*nckx finally deleted the one-typo-away-from-a-public-incident F—OU branch earlier this evening.
<podiki[m]>oh, and as I reminder I built with that patch on top of master; core-updates has libdrm and wayland-protocols updates already
<nckx>Great, that's what I'm using.
<ss2>oh, then it is coincidance. Was it in the list? I need to catch up reading the lists too.
<nckx>ss2: https://logs.guix.gnu.org/guix/2022-06-20.log#225404
<ss2>thx
<ss2>right. sorry about it that I vanished the last two months.
<nckx>That's everyone's right.
<nckx>I'm just happy it was for school.
<ss2>Though I've been constantly been reminding myself that this would be great to have it pushed for v1.4.
<nckx>Luckily, we've been postponing 1.4 just for you.
<ss2>hehe, yes, in hindsight I'd have selected a different topic. ^^
<podiki[m]>1.4 waits for all!
<nckx> https://www.tobias.gr/rsync.png
<podiki[m]>oh rsync
<nckx>What if I want to do crimes tho.
<podiki[m]>but does it have any cheeky error messages? is it tar that has a "stubbornly refusing to..." message?
<nckx>(Isn't it ‘cowardly’? But no, not aware of any such in rsync, sadly.)
<podiki[m]>well rsync won't be an accomplice to that, better find another syncing command!
<maximed>Are really all of these hydra-guix-??? on https://ci.guix.gnu.org/workers x86_64/i686?
<maximed>There are so many compared to the three aarch64 and powerpc machines
<nckx>podiki[m]: There is ‘attempt to hack rsync failed’ when it thinks your being evil.
<nckx>rsync really doesn't support crimes.
<nckx>Only typos.
<podiki[m]>nckx: :-D a program of principles
<nckx>maximed: Yes.
<maximed>If someone wants to see lots of activity at https://ci.guix.gnu.org/workers, now's the time (where now=once the latest evaluation completes)
<nckx>2k cores of x86_64 goodness.
<maximed>2000 in total I presume?
<nckx>Something like that.
*vagrantc wonders if bordeaux or ci is lagging ...
<maximed>(2000 per machine would be real crazy)
<nckx>That's what happens when you get a free rack, vs having to shop together early-days aarch64 ‘servers’.
<vagrantc>the reproducibility status of x86_64 is up to ~20% unknown, rather than ~10% before the staging merge
<nckx>maximed: I thought 2k was damn impressive, but OK, yes, no, not per machine.
*vagrantc needs to see the 0.0N% reproducibility increase from earlier in the month
<nckx>maximed: Because you cannot mine Guixcoin on GPUs yet.
<apteryx>has someone packaged a VNC server for Guix yet, or have unfinished patches?
<apteryx>I would gladly pick them up
<maximed>now's the time for looking at /workers for x86_64 activity!
<nckx>apteryx: tigervnc-server.
<apteryx>we have that already?
<nckx>Yes.
<apteryx>uh
<nckx>If you mean service, however, no idea.
<apteryx>cool. problem solved.
<apteryx>merci
<nckx>maximed: Impressive success so far.
<podiki[m]>maximed: what's the big build for?
***rgherdt_ is now known as rgherdt
<nckx>Is this really all antioxidated?
<podiki[m]>oh is it rust?
<nckx>podiki[m]: https://ci.guix.gnu.org/jobset/antiox
<maximed>podiki: There's a bug/feature limitation in antioxidant.
<nckx>podiki[m]: A thing to do hopefully Rust better in Guix.
<maximed>Apparently some build scripts want all the CARGO_FEATURE_etcetera environment variables set.
<maximed>But antioxidant only set CARGO_FEATURE_STD.
<maximed>Is now fixed, should fix rust-wayland-protocols build failure with the "unstable-protocols" feature enabled
<podiki[m]>antioxidated rust sounds promising (I see what they did there)
<maximed>antioxidated rust = iron?
<maximed>* antioxidated rust = iron + oxygen?
<nckx>Wait a minute. maximed was also behind the minetest build system.
<nckx>This explains everything.
<podiki[m]>looking at some mesa options from arch: they build with c/cxxflags -g1 to reduce size (less debug info). is that something guix does at all? should we do?
<nckx>They have been abusing berlin to mine for iron ore.
<nckx>podiki[m]: No.
<nckx>Leave that flag behind where it belongs.
<raingloom>hey, so, i'm trying to install calibre and guix weather says it's available, and yet when i run guix install it tries to build it locally. what gives?
<maximed>raingloom: Is the key authorised?
<maximed>Also, available from which substitute server?
<raingloom>ci.guix.gnu.org
<maximed>Maybe it's available from ci.guix.gnu.org but you only have bordeaux.gnu.org authorised
<maximed>Alternatively:
<raingloom>it's not on bordeaux.
<maximed>"guix weather" runs as your current user, the substitution happens by the daemon. The user has a cache, I don't know if the daemon has a cache but if it has a cache it is an independent cache.
<maximed>Possibly the two caches have a different view on the world.
<maximed>Should resolve itself automatically by waiting a little.
<maximed>(where little=some quantity I don't know the value of)
<nckx>You can delete /var/guix/substitute/cache/* if you want.
<nckx>raingloom: What does ‘guix build -d calibre’ say?
<maximed>nooo the fix caused a build failure ...
<podiki[m]>nckx: did we ever actually sort out any of that gallium driver naming business? I see we don't have "crocus,zink,d3d12"
<nckx>raingloom: What does ‘guix build -d calibre --no-grafts’ say? — to be safe.
<raingloom>/gnu/store/n3s5bizkqa8ydx0kw6kniy88m24sjrz6-calibre-5.36.0.drv is what it tries to build
<raingloom>then it tries to connect to the offload machine, which... why.
<unmatched-paren>maximed: i just found another reason to be excited for antioxidant :)
<raingloom>with --no-grafts it just prints this: /gnu/store/h9vfp3ml67k220mivgcj0fb2n5lwby7d-calibre-5.36.0.drv
<podiki[m]>d3d12 was enabled in Arch for WSL hardware support (does guix work in WSL?)
<ss2>Here in https://issues.guix.gnu.org/54561#25 Ludo meant that I'm supposed to add certain files to local.mk and POTFILES.in. Should they be part of the same commit of when the actual service file is added to the tree?
<unmatched-paren>wlgreet requires rust-wayland-sys
<podiki[m]>crocus is, if I'm remembering what we looked at, for older intel graphics now; zink is for opengl via vulkan
<lilyp>ss2: yes
<unmatched-paren>which dlopens libwayland libraries
<ss2>okay.
<unmatched-paren>and we need to patch those references
<nckx>raingloom: On master, I get neither. I get (without grafts) /gnu/store/dmbvzh9wnkykdcpa5f1hk23r5x52ck2w-calibre-5.36.0.drv → /gnu/store/0jv1b3zhjlay5dqpjkn2yi57h4y2g187-calibre-5.36.0
<nckx>Which is on berlin.
<unmatched-paren>but because cargo it needs to be done directly in the wlgreet package, not the wayland-sys package :( which is obviously painful
<unmatched-paren>so antioxidant will fix that :D
<nckx>podiki[m]: I never looked at anything beyond i915[g].
<podiki[m]>nckx: that's where we saw something about crocus maybe?
<unmatched-paren>(also, smithay-client-toolkit has a similar problem with xkbcommon, which makes it even more annoying...)
<raingloom>nckx: weird. i'm on c546a77, which is only a few hours old.
<unmatched-paren>but good news: WLGREET RUNS! :D this is my first servicey thing
<nckx>podiki[m]: Right, I was about to say I think we need crocus as well.
<podiki[m]>nckx: yes, seems so " i965 through Haswell generations" (with iris for newer)
<nckx>Zink seems fun, but I don't have any hardware that supports Vulkan (lol).
<nckx>unmatched-paren: Congrats.
<podiki[m]>from what I heard zink is catching up in support/speed for opengl on vulkan
<podiki[m]>I'll give zink a shot, but first attempt at giving it what it wants for vulkan failed
<unmatched-paren>what's zink?
<podiki[m]>"The Zink driver is a Gallium driver that emits Vulkan API calls instead of targeting a specific GPU architecture. This can be used to get full desktop OpenGL support on devices that only support Vulkan." (from mesa's docs)
<podiki[m]>in short, to run opengl stuff using vulkan, since opengl support is getting spotty it seems
<nckx>podiki[m]: I think we should ideally aim for -Dgallium-drivers=auto, if that's at all realistic.
<unmatched-paren>interesting! i didn't know there were devices that only supported vulkan
<nckx>Which should be ‘all’, for the architecture.
<unmatched-paren>s/were/are/ s/supported/support/
<nckx>s/should be/should mean/
<nckx>sneek: s/botsnack/healthy fruits/
<nckx>Damn.
<nckx>Too clever for that.
<nckx>(‘Clever’…)
<podiki[m]>is there an actual reference for all these mesa configure flags? i'm always searching blindly
<maximed>unmatched-paren: I recommend opening a bug report (in the antioxidant repo on notabug, or on issues.guix.gnu.org)
<maximed>(such that we don't forget later)
<nckx>podiki[m]: I'm just looking at <https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/meson_options.txt>
<podiki[m]>let me try this auto magic you speak of
<nckx>mEsOn Is DeClArAtIvE
<podiki[m]>thanks
<podiki[m]>I remembe rlooking there, but not if you want to know what the various driver names mean, sadly
<maximed>But yes, looks easy to do with antioxidant.
<podiki[m]>crocus built without chagnes, running with "auto" now and will see what it enabled; might build some crusty old stuff too, but maybe it has been removed
<nckx>I find the driver names impossible to remember. We discussed this only recently, and I already had to swap back in why ‘crocus’ is different from ‘i915’ in that list.
*unmatched-paren not sure what maximed meant, that problem would be fixed by antioxidant without any changes to it, by the very way it works...
<podiki[m]>well with "auto" it complies more stuff (2500 "things" vs 2400)
<nckx>More things == better; ship.
<nckx>(If they all build, I'm even serious.)
*vagrantc proposes to change the name of the autogen package to vagrantc's white whale of reproducibility
<nckx>podiki[m]: About WSL: only if it doesn't put undue burden on the distro to support.
<podiki[m]>....so auto was the same as I had, plus i915 (wut)
<unmatched-paren>Hmm, wlgreet runs, but does not seem to want to launch sway.
<podiki[m]>does guix run on WSL? if so I can see if the d3d12 driver builds without fus
<nckx>podiki[m]: Yeah, there were two i915s, remember. It's all extremely logical and not brain-aneurysm-inducing at all.
<nckx>podiki[m]: Yes, it does.
<podiki[m]>what about on other archetectures, should it just be auto for everything and hope mesa/meson is smart enough? the comments in our mesa package imply svga on aarch64 needed work at some point
<podiki[m]>well auto did not enable d3d12 so must be a missing dependency, will investigate
<unmatched-paren>Oh, I just had to add sway to setuid-programs :)
<unmatched-paren>y
<nckx>podiki[m]: The comment doesn't say, but I'd assume it was also talking about a build failure. So I'll stick by ‘if it builds, try shipping it’.
<unmatched-paren>oops
<nckx>unmatched-paren: Uh.
<nckx>That sound
<nckx>uh.
<podiki[m]>ah d3d12 needs directx-headers, no surprise but a no go for us
<nckx>I don't want my compositor to be setuid-anything.
*unmatched-paren forgot that making sway setuid is deprecated
<unmatched-paren>nckx: it drops setuid as early as possible
<nckx>I didn't know it supported it at all.
<unmatched-paren>like any behaving setuid-supporting program should
<nckx>Is this related to the bizarre ‘the only supported way to start sway is to type sway at a VT’ misguidance upstream has?
<unmatched-paren>nckx: ...potentially. hmm.
<nckx>Or no.
*nckx doesn't know, TBC.
<nckx>Seems like a very X thing, more than Wayland.
<podiki[m]>nckx: is bulding with --system=aarch64-linux for example, good enough? I haven't done much cross compiling
<nckx>podiki[m]: Yes. That is not cross-compiling. It's an emulated native build.
<unmatched-paren>podiki[m]: --target=aarch64-linux-gnu i believe
<nckx>You need to set up qemu-binfmt-service once, but it's worth the magic.
<podiki[m]>ah
<nckx>Yes, but --system= is more important here.
<unmatched-paren>oh, right, you want to build natively? okay
<nckx>The meson-build-system doesn't even support cross-compiling on master AFAIK.
<nckx>If it does, that is very new.
<podiki[m]>--target is cross compiling?
<nckx>Yes.
<nckx>Don't waste time on that yet, though (IMO).
<podiki[m]>well for now -Dgallium-drivers=auto does the trick on x86_64, checking for i686 now
<podiki[m]>reading the manual, useful :)
*nckx checks their sway for signs of setuid… it appears healthy for now.
<nckx>I use SDDM though.
<podiki[m]>vulkan-drivers has an auto too, just adds swrast
<unmatched-paren>I think it's supposed to use libseat when a seat manager is found
<unmatched-paren>instead of root permissions
<podiki[m]>anyway, I think I'll leave the other archetectures for the review process for people that know; I'll submit this one with just some minor cleanups
<vagrantc>sure would be nice to not *need* full setuid in some cases ... https://issues.guix.gnu.org/55683 :)
*podiki[m] takes a break from mesa options, feel free to leave requests for builds
<nckx>TIL the humble sort(1) is multi-threaded by default [dunno… just wasn't expecting that]
<nckx>podiki[m]: Sounds good.
<nckx>vagrantc: I've got a patch series ready for that, I just don't like that it invokes the setcap binary on each file.
<nckx>But doing it in Guile would require bindings which don't seem to exist (i.e., I'd have to write them).
<nckx>But my copy of mtr is already happily capable.
<vagrantc>nckx: oh, would love a comment on the bug/feature request to that effect ... :)
<nckx>I'll write some commit messages that aren't ‘[fixup] xxx wtf’ and submit it soon™.
<efraim>Not all architectures support auto
<nckx>Sounds like a bug.
<nckx>What happens?
<nckx>vagrantc: I hadn't seen the bug/feature request. What kind of comment do you mean?
<efraim>No one has given Mesa a list of drivers to build so it errors out and asks you to tell them what is a good default
<vagrantc>nckx: https://issues.guix.gnu.org/55683
<nckx>Right, I'd clicked that, but what more do you want to know?
<nckx>‘I have an ooold series that I should submit real soon now’ doesn't sound mailworth 😛
<nckx>*y
<vagrantc>nckx: just that there is some working code maybe coming to a repository near you ... :)
<efraim> https://cgit.freedesktop.org/mesa/mesa/tree/meson.build#n204
<vagrantc>oh yeah, i need to push FORCE_SOURCE_DATE to core-updates ...
<vagrantc>now i just need to use my amazing native english skills to update the description betterer
<nckx>I'm going to be optimistic and say that I'll submit the actual content soon enough that it doesn't need a ‘coming soon’ announcement. Also a way to motivate myself to actually do so now that I've promised to.
<vagrantc> \o/
<nckx>vagrantc: Just sed -i s/stubborn boneheads/texlive/ and good to go, no?
<efraim>some OTHER packages know better and demand extra environment variables
<nckx>Noo.
<nckx>Fine. Efraim has always been more diplomatic.
<vagrantc>ARE_YOU_SURE=1
<vagrantc>yeah, i don't really understand what two environment variables gets vs. one environment variable, but there are so many hills and i have only one lifetime :)
<efraim>Efl or enlightenment had a --i-know-what-im-doing-so-listen-to-me flag
<nckx>Why isn't it limited to texlive-build-system?
<efraim>I'm also still undecided about patching out the PANTS environment variable
<vagrantc>nckx: because some packages call texlive to generate their documentation
<nckx>Ah.
<nckx>Curses.
<vagrantc>yes, hexes and curses abound
<nckx>efraim: Que?
<podiki[m]>efraim: thanks for the code link, I can use that then to set auto where it is supported
<efraim>Hold on, I'll find the code
<vagrantc>efraim: is PANTS boolean? that would be extra disappointing.
<efraim>by default PANTS is on
<nckx>Thank god.
<djeis>Does putting a package in the packages list of guix system or guix home add all of its outputs, or just "out"?
<efraim> http://git.enlightenment.org/enlightenment/enlightenment/src/branch/master/src/bin/e_main.c#L346
<djeis>...looks like it's just "out". So, what's the right way to deal with a package like bind that has a "utils" output?
<djeis>If I were just using a user profile I'd guix install bind:utils, but I don't see how to do that with a guix home or guix system config.
<jpoiret>usually (list package "output") works
<efraim>also, you can set environment variables in a guix.scm file that gets loaded with guix shell, like so: https://bpa.st/KELA
<djeis>jpoiret: Indeed, much appreciated :)
<efraim>It seems everything gets evaulated, so calls to setenv also work, not just package definitions/transformations
<jpoiret>efraim: damn, that's terrible
<nckx>efraim: Har har.
<nckx>I was expecting it to do something; I guess it doesn't?
<jpoiret>I wouldn't be surprised if it actually worked
<efraim>the PANTS variable doesn't actually do anything, but setenv in guix.scm does actually work
<vagrantc>i can't even wrap my head around how to explain the need for FORCE_SOURCE_DATE without being at least snarky.
<vagrantc>i thought i had come to terms with it ... but apparently.
<vagrantc>or ... even describe it in a way that ... makes much sense.
*vagrantc fa epalms
<vagrantc>c
<efraim> https://bpa.st/CPDA
<nckx>jpoiret: How is that terrible? It's a lot less offensive to me than the proposal to add this stuff to manifests.
<foobarxyz>Hi, is it possible to write an input whose label doesn't match the package name with the new style? e.g. (inputs `(("gtk" ,gtk+-2))) can be written as (inputs (list ??))
<unmatched-paren>foobarxyz: not currently
<vagrantc>hmmm... here's my attempt at "explaining" why FORCE_SOURCE_DATE is used ... https://paste.debian.net/1244799/
<vagrantc>er ... that doesn't include my changes
<vagrantc> https://paste.debian.net/1244800/
<vagrantc>that's ... "better"
<foobarxyz>unmatched-paren thanks, i suppose the suggestion is then to use `(inputs (list gtk+-2))` and change any occurrence of `gtk` to `gtk+-2` in the package definition?
<foobarxyz>unmatched-paren: or is there a way to mix the two styles?
<nckx>vagrantc: I wouldn't have been able to write that without using at least ‘Unfortunately,’ somewhere.
<nckx>Maybe add a note for people as think as me as to why this is unconditionally set for all builds.
<nckx>*thick, to prove my point 😳
<ardon>Hi Guix, playing with postgres again. I want to set its locale to C.UTF-8 but from my understanding Guix isn't set up with it by default, so I get errors. How can I add the C.UTF-8 locale to my system configuration?
<nckx>Wait for core-updates, I think.
<nckx>There is no such locale yet (I think once more).
<nckx>Yes, C.UTF-8 is new in glibc 2.35.
*vagrantc has never been so excited about something in a new glibc version
<nckx>(= very new, Feb 2022, and very *very* new by Guix rebuild-the-world standards.)
<vagrantc>mostly because numerous other distributions have been patching it in since approximately forever
<nckx>Yep.
<nckx>Glad that's almost over.
<ardon>nckx: Thanks for the heads up! Will wait for it then
<vagrantc>that could definitely be a while. stick with my empire's handy en_US.UTF-8 locale for the near future...
<nckx>With any other package I might have suggested building a custom postgres linked to the new release, but that would asplode your machine in this case so I won't. Sorry for the disappointing answer.
<nckx>At least it is very unlikely to end well.
<nckx>(‘asplode your machine’ = en_US; ‘very unlikely to end well’ = en_GB.)
<vagrantc>nckx: so a reference URL to the documentation isn't enough for this obscure description about time mangling? :)
<nckx>It's not really related?
<nckx>It's probably just me, but the use case of other packages running texlive to build documentation is both (1) perfectly logical and (2) wasn't obvious to me at first.
<vagrantc>ok ... thanks for spelling out your thoughts, that might actually help me write something worth pushing :)
<nckx>I will gladly serve as lowest common denominator for comment testing.
<podiki[m]>on the mesa "auto" front: I can eliminate a few configuration cases we have, but we have architectures that don't support "auto" and also where the "auto" list is less drivers (not sure what that means, maybe a change in v22?)
<vagrantc>nckx: https://paste.debian.net/1244801/ ?
<nckx>vagrantc: I think that's a good balance between giving the immediately relevant facts, and referring to rbo for a more opinionated take.
<nckx>I'm less down on it than you seem to be.
<vagrantc>nckx: your needing the specific use case about why to set it globally actually helped it make sense why to say anything at all :)
<nckx>Yay.
<nckx>I still thought the ‘specialness’ was restricted to building TL, i.e., that setting FORCE_SOURCE_DATE would *build* a TL that respected S_D_E.
<vagrantc>although the longer i spend in the proximity of this environment variable i feel it has a bad effect on my immediate climate :)
<nckx>I don't know why I thought that; you implied no such thing; but it seemed more logical than the truth.
<vagrantc>heh
<vagrantc>i just want to swipe this dirt under the rug as quickly as possible because for some reason this dirt just won't go anywhere else :)
<nckx>I'm 100% with you in not wanting to accidentally promote it.
<nckx>It's silly.
<vagrantc>nckx: thanks for your support! :)
<nckx>This channel is for both technical and emotional support.
***califax_ is now known as califax