<rekado_>sneek: later tell unmatched-paren pascal is not bootstrappable. There’s an old unmaintained GCC frontend for pascal, which I failed to package. And there’s the free pascal compiler, which we already have. We build it with an older binary of the free pascal compiler.
<robin>(incidentally, i think it'd be feasible to do clean-room RE of amdgpu firmware -- the blobs are relatively small (<2 MiB usually) and a fair amount can be decompiled with e.g. ghidra, and the kernel module being free is certainly helpful to some extent...)
<singpolyma>How does it get decided to add something to the seed vs just not packaging a thing?
<singpolyma>robin: I asked an expert in the area about the cost to do that and they sort of indicated it would be expensive and not worth it. But not impossible of course
<robin>singpolyma, yeah, funding would be a problem for sure, 2+ experienced people working for several months plus a lawyer to ensure it's all aboveboard
<singpolyma>Yeah, it's hard for me to calibrate my funding efforts because people just say things like "a lot" which means something different in every circumstance
<singpolyma>Two people for several months is probably not what I would usually think of as "a lot"
<robin>i think an amd engineer commented on phoronix(?) that the closed firmware is partly due to drm support and there's not enough obvious demand for such gpus to (economically) justify the effort
<robin>probably more than 2, yeah, that's just the absolute lower bound
<gordon1>is there a way to use a file like a template for config generation?
<singpolyma>IIRC I was specifically told "if you have that much money and hate firmware so much, go hit a bunch of network chips"
<lfam>It's not noise ngz :) Just trying to give advice about how to get information about your problem
<lfam>I don't have anything to push so I can't test myself
<lfam>About the RAM firmware, the reality is that there are mountains of code running in a computer below the OS, and very little of it is freely licensed or even reusable between devices
<ngz>lfam: Actually, I think I solved it. I hadn't updated the keyring branch. Unfortunately, it means "make authenticate" is going to rebuild Guix completely, as it always happen when checking out very different branches.
<sneek>rekado_, bdju says: did you ever get qmk working on guix? what's the best install method, and how do you set up the udev rules?
<rekado_>bdju: I haven’t packaged it. I built it manually.
<rekado_>udev rules are added to the system config
<attila_lendvai>is there a way to add an entry to the requirement field of a service? i.e. the service's code doesn't know which other services are needed for its proper operation, it's only available in the config.scm of the machine.
<jpoiret>attila_lendvai: wdym by "doesn't know which other services are needed for its proper operation"?
<attila_lendvai>jpoiret, the swarm bee node requires an xdai blockchain RPC. this can point to a remote, cloud based service provider, or a local service. in the latter case i need to specify a dependency on the another local service.
<attila_lendvai>well, actually i should try how it behaves when the RPC endpoint is not available... i know that it gets cut off the swarm when the endpoint is lagging, but maybe it tolerates better when it's missing at startup
<jpoiret>you could simply have a procedure `swarm-bee-node-shepherd-service` with a #:local-xdai? keyword, which would return the shepherd service
<jpoiret>and add a local-xdai? field to an hypothetical swarm-bee-node-configuration record
<attila_lendvai>i'm still confused about the extra foo-service-type layer that guix adds on top of shepherd. i managed to set up a simple-service based on a shepherd service instance, so i should be able to set this up if i stare long enough
<attila_lendvai>jpoiret, but the thing is that the swarm-bee-node-config is completely unrelated to any xdai node... (in fact, when it's connecting to the testnet swarm, then it's not even on the xdai blockchain, but on the goerly testnet of ethereum)
<rekado_>oh: successfully built /gnu/store/q0jcxgpl583ch5z6jfghns2bi0pnxqls-ghc-4.08.2.drv
<rekado_>I only wanted to build the RTS, but I guess GHC 4 now exists, too.
<rekado_>(I cheated, of course: I’m using converted hc files.)
<jpoiret>attila_lendvai: i also don't like the name at all because service has an already widely-used meaning, which doesn't really fit here. Shepherd services are usual services, but guix services are not
<attila_lendvai>jpoiret, yeah, it has confused the hell out of me. for a long time i thought that those things in the guix config were just shepherd service instances. expecially that (guix gnu services) also has a <service> type, that really should be called <service-specificaton> or anything else.
<jpoiret>ie, not all guix services are related to programs running on your computer, there are many other different ones. Take etc-service-type, which populates /etc with what the service is extended with on boot
<jpoiret>I don't think it should have service in its name at all
<rekado_>one example: PAM is a system service, but it’s not a daemon
<jpoiret>rekado_: while I agree with the sentiment, service is such a widely-used term that has an accepted meaning in the community, so it will of course cause misunderstandings for new users
<jpoiret>especially since there are shepherd services as well
<attila_lendvai>i'm sure it's documented somewhere. but as a newcomer, the names in the code were misleading me. and if i read the docs before i got my hand dirty, then i would still be reading the docs, without producing anything of use... :)
<jpoiret>and i don't think it does the `extension` idea justice :p
<jpoiret>i definitely learned the distinction myself by looking at gnu/services/*.scm
<jpoiret>now, what I like even more than bikeshedding, is retroactive bikeshedding
<attila_lendvai>in general, i find the guix docs too verbose, and too much leaning towards an endless free-flowing text of paragraphs (as opposed to having more structure that helps skimming it for the relevant parts).
<attila_lendvai>re extra requirements: basically i need to extend my swarm-configuration record with a field for extra-service-requirements that gets append'ed to the defautls. i would fancy if there was a way to communicate the extra requirements without touching the swarm-configuration record.
<rekado_>jpoiret: yeah, I agree that it’s confusing.
<vivien>The CI looks bad, do we know what the issue is?
<gordon1>so i have those scripts with few hacks that get called on some events from mdev, i pulled it from gentoo, what's the best way to put it in the service? It doesn't really makes sense to have them if you don't use mdev, so not sure it makes sense to put it inside the busybox package, but otherwise where can i put it? What is the best approach?
<gordon1>i can just go and make another package like "mdev-support-scripts" or something and put them there
<gordon1>or i guess nothing stops me from making busybox-with-mdev inherited from busybox...
<gordon1>or can i just put few files in the store while registering a service to be called as event trigger?
<jpoiret>if you're writing a guix service, then you could have an mdev-configuration record with some field describing the actions to be taken, and you could totally give it references to other packages or even some (mixed-text-file ...)
<gordon1>so mdev has this kernel handler registered that gets spawned for every kernel event
<gordon1>and this handler reads /etc/mdev.conf where it checks which dev file it needs to create, with which perissions and also optionally it can have a field to call a script
<gordon1>i know that i can give it a reference to a package, sure, i'm just struggling with where to put those scripts
<gordon1>like i gentoo it is just a supply files that get installed alongside with mdev
<gordon1>but in guix you have this logical separation between services and packages in the code
<gordon1>so i'm not sure where and how should i put those scripts
<rekado_>vivien: looks like the database is refusing connections
<jpoiret>are those scripts generic or specific to you? are they your work or under a free license?
<gordon1>just trying to get some information on the best practices
<gordon1>they are i guess under the gpl from gentoo, i need to double-check
<jpoiret>then you could consider packaging them in a neat little package, if that's also what gentoo does
<jpoiret>they must come from a gentoo package, right?
<rekado_>vivien: I just restarted postgres and asked cuirass to retry one evaluation. Let’s see.
<gordon1>gentoo doesn't do that, it just have it along side with ebuild for busybox in files dir, and it installs it as part of busybox
<gordon1>which, i'm not really sure is the best idea
<jpoiret>well, if it's under a free license, you could package them as eg. gentoo-mdev-scripts
<gordon1>okay, then the thing i didn't really figured out yet, how can i make a dependency of a service on some package then?
<gordon1>like if i add mdev-service-type in my services how can i make sure that it will install this package when i do reconfigure?
<gordon1>wasn't able to locate this particular code snipped in gnu/services/*
<ngz>rekado_: I think I read you had implemented a tool to check tlpdb and tell if a package is "complete" or not. When you have some spare time, would you mind explaining how to use it when one wants to add a new TeX package?
<rekado_>ngz: it’s “files-differ?” in (guix import texlive)
<jpoiret>gordon1: how do you fit the /etc/mdev.conf in mdev-service-type?
<rekado_>ngz: start a guile repl, then: ,use (guix import texlive)
<rekado_>and then (files-differ? "/gnu/store/aiknpz049bqbr73s58yaqk3ln7hq8n4x-texlive-amsfonts-fixed-59745/share/" "amsfonts")
<gordon1>for now i'm just using etc-service-type extension, but in future i think i'll patch the mdev.c to get it from somewhere? not really sure yet
<jpoiret>that way, the hypothetical mdev-rule record could have a (script ...) field, which would be something that you can insert inside a gexp, eg (string-append gentoo-mdev-rules "/bin/yourscript.sh")
<jpoiret>you can have mixed-text-file take this whole template as-is (with some patches) and add additional rules
<jpoiret>although it'd be cleaner to have everything under the same interface
<gordon1>i thought using a template and substitute*
<gordon1>but actually there is no reason to, isn't it?
<ngz>sneek later ask rekado_ Since (files-differ? "/gnu/store/05j4my6j7c5a90lb84kbkd0a94hz1lbi-texlive-generic-babel-french-59745" "babel-french") attests "babel-french" is borked, what would be the next steps to get it fixed, i.e., to add missing files? Use simple-text-package, and add a bunch of LOCATIONS?
<jpoiret>no need to install it! if I have a gexp like #~(do something with #$(string-append some-package "/bin/hello")), if that gexp is lowered to a file in the store it will also pull in some-package and build it
<rekado_>ngz: I’d use the importer first; see what it spits out
<sneek>rekado_, ngz says: Since (files-differ? "/gnu/store/05j4my6j7c5a90lb84kbkd0a94hz1lbi-texlive-generic-babel-french-59745" "babel-french") attests "babel-french" is borked, what would be the next steps to get it fixed, i.e., to add missing files? Use simple-text-package, and add a bunch of LOCATIONS?
<munksgaard>`guix environment --pure` doesn't seem to work for me. I'm using guix on NixOS. After running eg. `guix environment --ad-hoc hello --pure`, nothing seems to be added to my PATH. Am I doing something wrong?
<munksgaard>It also doesn't seem to work without --ad-hoc. `guix environment guix --pure` doesn't give me an environment with autoconf
<munksgaard>Seems like /etc/bashrc will run /etc/profile if it doesn't think it has been run yet
<rekado_>ngz: well, the importer is a big step in the right direction. But in my experience my work on the modular texlive primarily produces lots of complaints and “I’m using the monolithic texlive anyway, winking smiley”, and “the modular texlive has been broken for years”, or comments to that effect.
<attila_lendvai>with-parameters is another very unfortunate name. (it's not an alias of parametrize, but rather some gexp specific thingy)
<ngz>rekado_: Is it really useful to build a ".ins" file if generated files are already in the simple-texlive-package definition? I.e., should I use a non-nil trivial? even though files-differ? report no non-doc non-source missing file?
<johnhamelink>Hey friends, I tried to run guix upgrade today (running guix foreign on arch currently), but I'm getting some "conflicting entries" errors which I can't seem to resolve through the hints coming back from guix. After trying to remove one of the problem packages, I can't re-install it anymore due to the same issue. The issue seems to be between emacs-rustic, emacs-elfeed-org and emacs-doom-modeline as
<PotentialUser-41>i'm installing freecad, i will test when it's done, thanks for your responses :)
<apteryx>what do people think about enabling the SND_EMU10K1 driver as a module in our kernel? Is there an alternative, such as packaging it as its own kernel module package, to be manually added to my operating-system config?
<ngz>sneek later tell rekado_ Package texlive-jknappen because, although it appears as jknappen on ctan, Texlive named it jknapltx. So the current package is actually installing nothing. I'll trust texlive.tlpdb and rename it texlive-jknapltx and deprecate texlive-jknappen.
<sneek>rekado_, ngz says: Package texlive-jknappen because, although it appears as jknappen on ctan, Texlive named it jknapltx. So the current package is actually installing nothing. I'll trust texlive.tlpdb and rename it texlive-jknapltx and deprecate texlive-jknappen.
<ngz>rekado_: But they are the same thing, ain't they?
<ngz>And they both should really be texlilve-jknapltx, I suppose.
<rekado_>yes, texlive-jknappen should not have been added as is.
<ngz>For the time being I use texlive-latex-jknapltx
<ngz>rekado_: BTW, trying my modular Texlive, I encounter the following error <https://paste.debian.net/1228747/>. It seems to be a font problem, possibly related to texlive-kpfonts package. However, files-differ? shows no problem with that package. Would you have an idea about the issue?
<nij->If I leave my channel config as default, running `guix pull` will pull the latest dev version of guix, right?
<ngz>Well, I'm far from understanding everything in Texlive, but I can certainly have a look, and try stuff.
<rekado_>we don’t have anyone who is close to understanding everything, so that’s clearly not a requirement :)
<nij->Hmmmm.. my guix machine suddenly doesn't connect to the internet anymore. It's on an ethernet cable and has been working for hours. I have rolled back to the first generation of the whole system, and I've also tested the cable on another computer. Both do not explain why it stops connecting..
<nij->If there's not much else I can do, maybe I'll just reinstall guix again.
<akonai>how does one configure elogind properly? i have elogind-service-type in services and there's a login1 entry in /etc/dbus-1/system-services but on login i get "error in the service module" and it errors out with "unset" on any logind related action
<rekado_>akonai: i don’t configure it at all. What do you intend to configure?
<rekado_>nij-: the urge to reinstall is a habit that has no place in a declarative system
<nij->rekado_ :D but I have rolled back to the first gen.. dunno what could be wrong
<gnoo>akonai: the way i configured it was to remove it, the experience has been great so far ;-)
<gordon1>so i'm trying to make this list of with default mdev rules where i want to use gexp substitution, something like (string-append package "/bin/command"), should i do that?
<lfam>Maybe it's a mistake, maybe on purpose. I recommend asking Mark about it
<lfam>Or, just try enabling it and see what happens for your use case
<nij->Hmm... I have guix pulled and saw it pulling from other channels I specified. `guix pull -l` also shows that the current guix isn't vanilla. However, `guix describe` says it's vanilla.. and the current guix cannot see packages I pulled from other channels.
<jackhill>oh, now I understand, just the bootstrap chain is missing. Well, this seems like a great step, thank you!
<rekado_>but there are two files that are not built at all, so it could be that the resulting GHC isn’t fully functional
<rekado_>gotta make some progress with GHC 6 first to see if that matters
<nij->(Just realized that I have been confused with .config/guix/current/etc/profile and ~/.guix-profile/etc/profile.............
<rekado_>and if it does matter after all we’d have to revisit GHC 4.
<lfam>nij-: Basically, "a profile is a directory containing installed packages". More specifically, when you install some packages with a command like `guix install foo bar`, Guix makes a collection of symbolic links from your profile in $HOME to where foo and bar are kept in /gnu/store
<rekado_>that said: having only two files fail to build is pretty good
<nij->lfam I don't make the current guix the default?? What if I want to reconfigure the system from the end of another user?
<lfam>nij-: The `guix` program contains the Guix commands, the package recipes, definitions of Guix System services, and everything else part of Guix.
<rekado_>it hasn’t always been this way and “guix pull” used to use a completely different (and very error-prone) mechanism to update itself.
<nij->`sudo guix system reconfigure /etc/config.scm` fails - because the guix isn't the current guix.
<lfam>Each user has their own copy of the `guix` program
<rekado_>now it just uses Guix to install itself into a Guix profile.
<jackhill>rekado_: indeed, it's nice to see progress. Your previous experience with nhc left me with the feeling that there was still a huge chasm to cross. Now we at least have the anchor points for a bridge!
<lfam>rekado_: Let's not digress with history at this point :)
<apteryx>I don't know; currently we don't show anything at boot... I guess it'd show the Linux-libre mascott.
<lfam>Tbh, we already added 5.16 and nobody commented on the patches, as always :)
<lfam>Didn't we used to do that? It stopped working?
<rostranj>how come emacs-next is not compiled with xwidgets?
<lfam>I don't see that option upstream apteryx. Is it from linux-libre?
<apteryx>I'm looking because I wanted to add something; so I "guix shell -D linux-libre ncurses" in the sources; cp ~/src/guix-master/gnu/packages/aux-files/linux-libre/5.16-x86_64.conf .config, then 'make oldconfig' and it prompts for that thing.
<lfam>Now, that example is kind of exaggerated, nij-. But it's more likely to happen with certain kinds of packages, especially Python libraries
<nij->But it's indeed possible to have both of them symlinked in the profile, right?
<nij->(specs->manifest '("email@example.com" "firstname.lastname@example.org")) some thing like this
<lfam>nij-: The package recipes would have to create binaries with different in their /gnu/store directories. Like, one of them would have to be "libreoffice" and the other would have to be named "libreoffice-8" or something
<lfam>It's not usually a problem, but it comes up a lot with Python, because Python programs require their libraries to be "installed". They can't link to them. That's what a "propagated-input" is
<lfam>And Python packages also need different versions of their libraries, so you end up with different Python programs "propagating" different versions of the same libraries, and then you get a "collision" when building the profile
<lfam>As an example, you might end up trying to create a profile that contains links to two different files named "~/.guix-profile/lib/python3.9/site-packages/cryptograph"
<lfam>Because different programs would depend on different versions of python-cryptography
<lfam>We do try to avoid it nij-, but it's not possible to avoid it completely now that we have tens of thousands of packages
<singpolyma>resholve is working on this for shell, I'm calling my one for ruby rld for now
<nij->At worst you'll have to modify the source code of the python software, right?
<lfam>The old-school distro idea where you have a "stable" release and only do bug fixes for 2 or 3 years... they don't do that model because they like using old versions of programs. It's because they can't possibly do updates any more quickly than that
<lfam>To summarize, nij-, if you get an error while trying to install or upgrade packages about "conflicting entries", it's telling you that some packages are each trying to install different libraries that create files of the same name. And on linux, a directory cannot contain multiple files with the same name, so Guix cannot proceed
<singpolyma>jackhill: yeah, I was about to try packaging resholve but got distracted and did grunt and half of typescript instead :P
<vivien>Can I create a gexp that return a package definition? I’d like to create a package definition, but I need to do some gexping around before I can build it.
<nij->I spent minutes in the savannah repo frontend just to find it..
<vivien>apteryx, I’m trying to find what to put as `build-the-derivation' in my pseudocode: (mlet %store-monad ((I-expect-a-string (build-the-derivation the-derivation))) (return (something-with-derivation-output I-expect-a-string)))
<vivien>In section 8.8 "The Store", I find a function named "build-derivations". The next paragraph reads: Note that the (guix monads) module provides a monad as well as monadic versions of the above procedures, with the goal of making it more convenient to work with code that accesses the store (see The Store Monad).
<vivien>So I expect to find a monadic function like build-derivations
***lukedashjr is now known as luke-jr
<lilyp>nij-: profiles have a 1:1 mapping to manifests, so they're defined in the same file
<lilyp>savannah only helps you locate stuff through the commit message
<lilyp>that's nice to check when something changed but not so nice when you need to orient yourself; a local checkout with rgrep is better suited for that
<vivien>It looks like it’s built-derivations in (guix derivations), but I don’t know how to use it.
<apteryx>vivien: I'm not sure about your example, but what helps me often in to ,import (guix monad-repl)
<apteryx>and ,import (guix gexp), then I lower any g-exp with (lower-object gexp)
<vivien>I also have derivation->output-path, but it fails too
<apteryx>and turn it into a derivation to build with ,run-in-store $output-of-lower-object
<vivien>I’m trying to find what I do differently from the gexp->derivation unit test
<vivien>I don’t know if I can run in the guix repl
<jeko>Yo Guix ! I want to spawn a dev env to work on a new Guile project. So a made a manifest and added a Guile dependency in the propagated input. But I am still not able to (use-module (my-dependency)) after `guix shell`
<vivien>I fixed my issue, I had not converted all the required lets into mlets
<jeko>maybe I need a scm file in the root of the lib repo to re-export its api ?
<gordon1>so i can define a package "always-fails" that fails if it something tries to install it, and i can do guix install --with-inputs=undesired-package==always-fails "some-package" to make sure that "undesired-package" never going to be installed, but in this case it still will try to compile bunch of dependencies of "some-package" before it fails, but can i be achieved somewhere at dependency resolution
<jpoiret>dependencies of packages are not installed very often
<jpoiret>as opposed to traditional distros, most dependencies of a package will simply reside in /gnu/store/ but not be added to your PATH
<jpoiret>ie if I install gtk, its docs are compiled with latex (iirc), but I won't have `latex` in my PATH
<gordon1>yeah yeah, i know all that, it solves many problems but not all
<jpoiret>there are exceptions to this, propagated inputs
<jpoiret>do you have a more precise example/reason for that?
<jpoiret>there is no `dependency resolution` step in guix by the way
<gordon1>so imagine that i never run pulseaudio for example and i don't want service to be run, and some package that i already have got upgraded to new version that unconditionally depends on pulseaudio, it will silently install pulseaudio and the actual program will fail because service won't be running i guess, so i want to be notified about that during the upgrade stage
<jpoiret>i think you'll need some scheme code for that, package transformations won't be enough I think
<gordon1>is my understanding of its behaviour correct?
<jpoiret>well, it is correct, but I don't think it's very useful: you'd have to do that with all possible services that could be used in the future
<jpoiret>ie cups, dbus, polkit, and everything else
<gordon1>so yeah, i'm basically searching for package mask functionality
<gordon1>btw when i do guix install --with-input=foo=bar somepkg, does it record it somewhere? so for example if somepkg does not have foo as input but after guix pull it does, will guix upgrade pull foo or bar?
<podiki[m]>if you export your profile as a manifest, it will record that transformation so if you use the manifest for upgrades it will apply it again
<vivien>Is there a helper function that generates a package definition (sexp) from a package variable? I guess it’s just importing the modules that define the inputs, the module that defines the build system, and then serialize a guix record
<vivien>I think I could do it, but maybe guix already has it
<podiki[m]>gordon1: I'm not sure if it is the only way, but that will work (it's how I do it for some transformations and I keep all my profiles as manifests)
<gordon1>i mean, it sounds like a reasonable solution
<jpoiret>gordon1: package transformations are recorded in profiles yes