<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. <singpolyma>rekado_: so does that mean free pascal lives in "the seed" for now? <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" <singpolyma>And yeah, a lot of people will support AMD for the free kernel driver. Their economic benefit from also freeing the firmware would be much smaller <robin>haha, probably true. the last (optional) blob to be RE'd for talos raptor systems was network-related and done by a very small team, iirc <singpolyma>Especially since let's be honest 90% of people who want the firmware use it to play nonfree games. Most other use cases work fine with no firmware <ngz>Hello. It seems I cannot push to savannah. It there something wrong with the server? <lfam>I think that pretty much any computer requires RAM training code, whether in firmware or ROM <ngz>lfam: OK. Sorry for the noise. <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. <lfam>If one remembers, it's worthwhile to use worktrees when checking out branches like that <lfam>`git worktree add ~/tmp/keyring origin/keyring` <lfam>It saves me a lot of time and aggravatoin <ngz>I have yet to wrap my head around worktrees. <civodul>ngz: actually "make authenticate" does not rebuild anything, but "make check-channel-news" does <lfam>Just run that command I shared ngz :) <lfam>And then `cd ~/tmp/keyring` <lfam>It's just like `git checkout origin/keyring`, except it happens in a separate directory <lfam>Internally, it's the same copy of your local Git repo <lfam>Trust me, it's worth learning <jgart>if I cache binaries by running `guix build -m manifest.scm` why does Guix still download more stuff sometimes when I try to build a --container with the same manifest? <lfam>Presumably it needs some more things to create the container, since the container is basically a miniature operating system <rekado_>ngz: worktrees are great! Just “git worktree add ../keyring keyring” will create a worktree at “../keyring” that has the local copy of the “keyring” branch checked out. <jgart>How can I ensure that everything needed to build the container and manifest are always remain available so that I can use the hot cache <rekado_>oh, I see lfam already posted a command <lfam>jgart: You can create your container. The next time you try to create it, all the work will already have been performed <ngz>lfam, rekado_: Thank you. I'm going to do that for keyring, staging and core-updates. <lfam>ngz: Yes, I use it like that <jgart>someone should do a TED Talk on git worktrees ha <lfam>jgart: To get more specific, can you say what command you are using to create your container? <lfam>jgart: It would have to be a really short talk <lfam>It's not one of the very esoteric Git features, but it's a new-ish feature, so old-school "how to git" tutorials omit it <lfam>jgart: I would use the --root argument of `guix shell` to make sure the results aren't garbage collected <lfam>You might also run the guix-daemon with the various --keep-[...] options <lfam>I mean the --gc-keep-[...] options <lfam>Hard to get more specific without knowing even more details <jgart>So, I'd have to configure the server's service that the guix daemon is running on to use those? <jgart>lfam, what would you like to know? <lfam>Yes, they are options of the guix-daemon <lfam>Optionally, you could just not collect garbage very often <lfam>Storage is way cheaper than our time <jgart>The app I linked above presents a special problem <ngz>I created my first git worktree \o/ <jgart>lfam, Any user can submit a notebook with a Guix manifest to build in a Guix container. <jgart>That's what the above app does essentially <lfam>ngz: Now learn about `git worktree prune` and `git worktree list`, and you're done! <jgart>Indeed, a rarity on any git forge <jgart>but this user, BonfaceKilz can submit there notebook to the above app and Guix will try to build a container with the deps in the manifest. <jgart>lfam, once the above app is done building the Guix container (linux namespaces), it will redirect BonfaceKilz to their Jupyter notebook running in a Guix container. <drakonis>time to make me a guix daemon with event loops <drakonis>after rewriting the remains of the nix daemon into guile <jgart>The problem is the wait times on the first try for a new user because Guix needs to download all the binaries <lfam>jgart: This isn't the detail I meant <lfam>I mean, what is being downloaded? <lfam>Is the garbage collector being run in between invocations of `guix shell`? etc <jgart>Ohhh, I don't have a log of that currently. I can get it and share <jgart>re: garbage collector. I'm not running the garbage collector <lfam>Then, there's no hot cache that would have been populated, right? <jgart>maybe someone maintaining the server is running the garbage collector on my behalf. <lfam>I assumed you wanted to avoid removing things from your local cache, but you've never created them at all? <jgart>The issue still remains: How do you get a hot cache for a new user? <jgart>That presents the app with new deps that the app hasn't cached <jgart>Build the world and cache it? <lfam>It's a cache. That means it preserves the work of things you've already done <jgart>That's one option I've been thinking about <lfam>So, you have to do the thing in order to populate the cache <jgart>Sure, I'll try the things you suggested above with the guix daemon options <jgart>and forcing the deps to be there (cached) for future container builds <jgart>I mean the container itself deps <jgart>instead of the packages required by the container which I have to ensure also <lfam>It builds fine on current master <jgart>lfam, isn't there a newer audacity fork now? <lfam>Could be, but we remove the telemetry from our package. Also, I think most telemetry is good <lfam>So, I wouldn't use the fork unless it was superior <ngz>There's a CMake build option "audacity_use_ffmpeg", which can be "loaded", "linked", "off", and "loaded" by default. <lfam>ngz: It turns out that the documentation is wrong. The only options are "off" and "loaded" <lfam>I'm checking the Git repo to see if that has changed since our version <lfam>Like I said, unless it's superior, I'm good <ngz>lfam: Indeed I just noticed that the documentation is wrong, too. <lfam>So, what does "loaded" mean? <sam_>probably dlopen or something <lfam>Nix is still using Audacity 3.0.2, which apparently allowed linking <lfam>Nix does mention this in a pull request. It's actually the reason they haven't updatd <lfam>It would be nice to have a tool built-in to Guix that warned if inputs were not referenced <lfam>It's definitely an unusual case and usually indicates a bug <lfam>The built-in dialog for point to FFmpeg doesn't seem to work <lfam>Even manually adding the path to ~/.audacity-data/audacity.cfg does not work <nij->Hi! I'm using the dev latest iso for guix system.. and encounter an error with the graphical installer: https://bpa.st/P4AA (manually typed; I apologize if any typo) <nij->I installed again and ran into the same error. Is it a bug of the latest ISO? <dcunit3d>does /var/log/secure get cleared when you run sudo guix pull? <lfam>nij-: Sounds like it's a bug in Guix <nij->lfam :( what can I do now? I want guix home, so I get the latest iso.. <dcunit3d>no sorry, i was just wondering what would cause the log to be cleared? it cleared for me like 2 days ago <lfam>nij-: I recommend reporting the bug to the bug tracker, by sending email to <bug-guix@gnu.org> <nij->can I use guix home even not using the latest iso? <lfam>Are you trying to install Guix System nij-? <lfam>I recommend using the 1.3.0 installer <lfam>You can install 1.3.0, update it to the latest, and then use Guix Home <nij->what's the 1.3.0 installer? <lfam>It's for the most recent release of Guix, 1.3.0 <dcunit3d>nvm it looks like the logs rotated, but there's only one other file, 2kb. i have to unpack the /var/log/secure.1.gz. <MysteriousSilve4>any idea why right clicking is automatically followed by a left click? for example right clicking a link in icecat automatically opens it in a new tab <drakonis>maybe it is registering it as a middle click? <eonn>MYsteriousSilve4: Is it a touchpad? <eonn>It might just be iffy touchpad registering like drakonis said. Is it a button or a touch sensor? <drakonis>just for the record, if you press and hold while selecting a menu option, it'll select that option <eonn>Do you have a USB mouse you can plug in and test? Also make sure you aren't moving the cursor to a menu option when you click <eonn>Happens when you hold right click? <eonn>Even when the cursor is far away from the context menu? <MysteriousSilve4>if i move the cursor while holding am able to change the menu that is "clicked" <eonn>But releasing rmb invariably selects something in the menu? <MysteriousSilve4>any way to disable this? not sure how to hold the rmb when using two finger tap <eonn>The menu is supposed to work like that. You should be able to right click without moving the mouse to keep the menu open <eonn>Unless the menu is opening in the wrong spot in relation to the cursor, or something. Is a menu item highlighted when you hold right click? <eonn>Really try not to move the cursor <eonn>The mouse cursor is supposed to be just left or right of the menu. Maybe it's a GTK(?) thing. Do you have another application you can try this in? <bdju>does anyone here use qmk and can tell me how to get it set up properly on guix system? <bdju>I see stuff in old logs about rekado doing something with it <bdju>not seeing a satisfying conclusion reading the logs from september ***califax- is now known as califax
<bdju>sneek: later ask rekado did you ever get qmk working on guix? what's the best install method, and how do you set up the udev rules? <bdju>that mouse bug MysteriousSilve4 described sounds incredibly familiar <bdju>I have not run into it lately, though <bdju>I stopped using icecat in favor of qutebrowser, so it's possible it only appears in icecat and that's why I haven't run into it in a while <MysteriousSilve4>"the menu is opening in the wrong spot in relation to the cursor" that's probably the problem <eonn>MysteriousSilve4: I would look at the output of `xrandr` and see if there's a mode the screen shouldn't be in <eonn>Sorry, you should install xrandr <eonn>It lets you mess with some X display settings on the fly <eonn>Peruse the manual and you should be able to understand the output. Where you see + and * next to the numbers, that is the mode your screen is in. <lfam>Icecat development happens solely within the Guix project, so if you confirm that this only happens in Icecat, you should report it to <bug-guix@gnu.org> <eonn>lfam: He says it happens everywhere, which is why I'm chalking it up to X <lfam>It happens in other GUI apps such as Libreoffice? <eonn>He tested in a few different GTK and Qt apps <lfam>"works like before on anki (qt), libreoffice, and jami (gtk)" <lfam>Does that mean it works properly for those applications? Or that the bug occurs there too? <eonn>I took "works like before" as in it didn't work... <lfam>Let's wait for clarification <lfam>Going back, it's not totally true tha Icecat is only developed within Guix (I was wrong). But it was salvaged by a Guix developer <lfam>And you can send reports to us <lfam>Now it looks like there is a small development community for it, which is great <MysteriousSilve4><lfam> "Does that mean it works properly..." <- yeah, works fine outside icecat <lfam>I wonder if anyone else can reproduce the issue? I know there are other icecat users here <lfam>What version of icecat are you using? <lfam>Yeah, that's our latest version <lfam>I do recommend filing a bug report <MysteriousSilve4>2. even on dwm, it does not happen when the application is in fullscreen <Ribby>Anyone know how to get dependencies and compile source code on guix/gnu? <Ribby>Is it me, or each website have their own instructions? <Ribby>Like, there's different instructions for each linux brand. <Ribby>Yeah, something like that, or at least for my case. <Ribby>I'm not sure if it's copyleft, but there are dependencies that split hairs? <Ribby>I guess that will work. I usually mod for ZDoom v2.7.1. The v2.8.1 has some nested script mess among other things. <Ribby>I assume that the page has the instructions for the near basis of download, dependencies (although it just looks simpler somehow), and make installation. <eonn>I think what you're looking for is `guix shell`? <eonn>If you're trying to make a dev environment that contains the dependencies of a package <Ribby>Well... if I fail, I can just run wine... Not sure if it is copyleft though. There are some buggy software that have errors somewhere. <Ribby>You people know how to disable the hardware graphics driver? <eonn>set -nomodeset in the kernel options before booting, in GRUB <Ribby>Do I have to type it down every time? <eonn>If you want it to be permanent, you can add the module to your blacklist <eonn>I'd have to look into how to do that in the scheme system config <eonn>Try setting (kernel-arguments) in your (operating-system) declaration <Ribby>This could be tricky, but it shouldn't be too hard. <eonn>Right, that's manually adding nomodeset to your linux options <eonn>Setting (kernel-arguments) will likely generate the correct arguments in the grub config when `guix system` configures the bootloader <Ribby>You can read further down to Part 2. Said to be permanent, but I don't know if it can be reversible or not. By logic, I'm sure just erasing the keyword would do. <eonn>When they say "permanent" they mean "until you change /etc/default/grub again". <eonn>You are using GuixSD, right? <Ribby>I'm using the stable release. <eonn>Is your operating system the Guix System Distribution, or is it something else? <eonn>Well, your operating system declaration is where you should jot down changes to your configuration. `guix system` handles this automatically <eonn>Being able to declare your system's properties is a benefit of using GuixSD <Ribby>Will keep note of that. I guess it's some effort and time put into research until otherwise, whatever, or whenever that be. <eonn>One moment, I'll post a snippet <eonn>Under (operating-system), declare `(kernel-arguments (cons "nomodeset" %default-kernel-arguments))` <Ribby>Note taken, where did you get your reference material from? <eonn>The guix manual page for operating-system <Ribby>Just in case I need to elaborate on details. <eonn>You can read the manpages on system configuration to get a better grasp of the things you can configure in your system with guix <Ribby>Tons of commands, tons of parameters. okay. ***eonn_ is now known as eonn
***stryan_ is now known as stryan
<gnoo>when building packages, is it containerized? meaning, if i do (mkdir-p "/etc/test"), will it be created in the system as well or only while building? <gnoo>a package is writing to /etc/package.conf but it is getting permission deined but that shouldn't happen if it was containerized, right? <podiki[m]>well maybe containerized isn't the right word <podiki[m]>it can't write anywhere but its build env, if I understand correctly <podiki[m]>you'd want to have it write to (string-append #$output "/etc/package.conf") or something like that <gnoo>yeah, i modified it to "${DESTDIR}${PREFIX}/etc/package.conf" and now it builds <gnoo>also it can't write inside it's build environment as sometimes you get this: mkdir /homeless-shelter: permission denied <gnoo>void solves this by chrooting the build process so it can do whatever it wants inside the build ***daviid` is now known as daviid
<florhizome[m]><gnoo> "also it can't write inside it'..." <- atm I just (setenv “HOME” (getcwd)) for that. <gnoo>florhizome[m]: thanks! i'll try that <florhizome[m]>I think they automatically set HOME, PWD or they talked about that packages sometimes want them... <sneek>rekado_, you have 1 message! <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. <cehteh>aka non intrusive defrag, less than running defrag alone <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 <sneek>zimoun_ was in #guix one day and 12 hours ago, saying: civodul, thanks. I will open an issue once I will access again to my colleague's machine. But I guess it requires a kernel update.. <attila_lendvai>jpoiret, agreed. it should be at least a warning box in the manual to draw attention to the two meanings/usage of `service` <jpoiret>you have account-service-type also that lets you add users to the config, although most users encounter it via the (users ...) field of operating-system <jpoiret>but (actual shepherd) services that need their own users added will extend it <rekado_>the idea was that service are much more general than the shepherd idea of a service as some daemon <rekado_>the blog post explains the motivation <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. *attila_lendvai looks at service-type <rekado_>maybe it’s not too late to change the names… <jpoiret>rekado_: well, if you think so, then maybe it could be a discussion worth having <rekado_>attila_lendvai: could you give an example of something too verbose and with free-flowing text of paragraphs? <jpoiret>tbh I think it could also be grouped up with a factorization of home-service and guix system services <rekado_>I’m just some person with a keyboard and an internet connection, so my opinion doesn’t matter much :) <rekado_>jpoiret: haven’t looked into guix home at all yet, but that does sound like an opportunity <jpoiret>in the end, guix is just a bunch of people with keyboards and internet connections <attila_lendvai>rekado_, sorry, there's nothing in my notes. i'm collecting notes for a kind of 'newcomer's impression' email, i'll add to that when i encounter a good example. <jpoiret>the paragraphs here are a bit too cryptic for a newcomer <attila_lendvai>so, i conclude that there's nothing in a <service-type> instance that could encode extra requirements. maybe i'm missing something, though. <jpoiret>attila_lendvai: service-types don't encode any requirements <jpoiret>only shepherd services have requirements <ss2>anyone using rdiff-backup? It seems broken to me lately. <ss2>--help doesn't work since some time, and now in my little function --exclude doesn't work either. <jpoiret>i don't know the specifics, but aren't you writing a service for a client? if so, isn't how the client connects to the server a part of the configuration? <attila_lendvai>(define-record-type <service> ) with the two fields 'type and 'value is super confusing, too. (value here is actually a custom configuration record instance) <jpoiret>attila_lendvai: value can be *anything* <attila_lendvai>jpoiret, you got it right. but the configuration is just an URL. and the extra requirement is only needed when the other service is implemented as a Guix service on the same machine. <ss2>but the --help switch isn't available anyway. <attila_lendvai>while we are at it, 'requirement is also an unfortunate name for an inter-service start order dependency <jpoiret>attila_lendvai: well, what about adding that local-xdai? field to the record, and making it #f by default? <attila_lendvai>jpoiret, then i'd rather just add a field called 'extra-service-requirements that gets appended to the defaults... no? <jpoiret>note that field names are not symbols <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 <ngz>rekado_: I'm with you so far <rekado_>ngz: this checks that the given directory contains all files that “amsfonts” in the tlpdb mentions <jpoiret>gordon1: but where are the contents of the file specified? <jpoiret>i'd suggest creating an mdev-configuration record describing the mdev configuration, which would be the value of the mdev-service-type service <gordon1>yeah, that's the other question that i didn't yet tackled <rekado_>when you add “#:direction 'whatever” to “files-differ?” it inverts the check, so it will show you files that have been installed that are *not* mentioned in the tlpdb <gordon1>the vague plan is to have a template (out of gentoo) and make a function to append custom rules at the bottom <ngz>rekado_: So assuming I write a tex-foo package, I copy the output directory as the first argument of the function and "foo" as the third one? <jpoiret>then, the service extension to etc-service-type would take that configuration record and produce a file-like <gordon1>i just copy-pasted udev-service-type from base.scm and trying to make my way forward through it <jpoiret>gordon1: can you paste.debian.net what you have so far, so that we can be on the same page? <gordon1>it has udev-configuration, and makes udev.conf in the shepherd service, but i moved this part out to the separate function and feed it to the etc-service-type <ngz>rekado_: Oh, actually the second argument is the canonical CTAN name. <ngz>rekado_: So, if I read it correctly, (files-differ? "/gnu/store/05j4my6j7c5a90lb84kbkd0a94hz1lbi-texlive-generic-babel-french-59745" "babel-french") <ngz> tells me my "babel-french" package is borked =/ <jpoiret>munksgaard: emacs-guix doesn't seem to be an official guix project <gordon1>sorry, it's not cleaned up yet, some residue of udev here and there <jpoiret>ngz: there are more commits on the gitlab though <ngz>Ah. It sounds like a complicated story. <jpoiret>gordon1: i think the first step is to create some record that represents a mdev rule, and then scrap the (local-file ) thing and instead use (mixed-text-file ...) to generate the mdev.conf <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") <gordon1>i mean not _that_ long, but fairly long <jpoiret>you'll need to patch it either way, seems that it uses `ln` for example <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>gordon1: well depends if upstream changes the sample file a lot <jpoiret>but again, guix is so different that it will need some specific behaviours either way <gordon1>i don't think it should be an upstream file... <gordon1>so how the dependencies resolved for a serivce? If i use package X in service Y how can I specify that? <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_, you have 1 message! <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? <rekado_>ngz: the second argument is the name from the texlive.tlpdb <rekado_>I realize that this is a bit annoying, because you can’t just guess that name <rekado_>I always have a copy of texlive.tlpdb (from the texlive-bin package) where I can look for names (and files) <ngz>OK, I'll copy that file. <rekado_>the name of that package — “texlive-generic-babel-french” — shows me that it is an old package, only copying the files from the “generic” directory. <ngz>It is not very old, I added it a few weeks ago, as a fork of texlive-generic-babel-english <ngz>But you're right, it should be texlive-babel-french <ngz>So texlive-generic-babel-english is probably borked too <rekado_>I forgot that other people also contribute texlive packages sometimes :) <ngz>I try to, otherwise, I'll never be able to use modular texlive. <rekado_>for new texlive packages I recommend to always use the importer. <vivien>rekado_, I don’t know what evaluation you retried but every worker is idle <rekado_>that’s better than a red X, I’m sure <rekado_>evaluation does not happen on workers <vivien>Ah yes it doesn’t count as a job <rekado_>vivien: good that you keep an eye on this! <ngz>rekado_: OK. I think I fixed babel-french. I imported it, and, since there was an ".ins" file, I built it, much like texlive-babel-swedish. <ngz>I don't know how to build .dtx file, however. It spits out errors all over the place when I add it to #:build targets <rekado_>gotta look at the files themselves; they should say if they are generated <ngz>Oh. So, know, it is obvious to anyone that I have no clue about Texlive internals. :) <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 <civodul>munksgaard: "guix environment guix --pure" should definitely give an environment that contains autoconf <rekado_>ngz: you give it the root directory of the package output <rekado_>but it needs the same prefix as the tlpdb <civodul>munksgaard: could it be that shell initialization scripts are interfering with env vars that 'guix environment' sets? <civodul>munksgaard: you can try "guix shell -D guix --check" to verify that <rekado_>it probably overrides PATH and a bunch of other vars <civodul>yeah, nothing to add to the hint that's displayed :-) <rekado_>the general rule is: ~/.bashrc is evaluated for *every* shell, but ~/.bash_profile only for the *first* <rekado_>so when you set variables in .bashrc they will override what “guix enviromnent” had just so carefully set up for you <munksgaard>civodul: I need to log out for it to take effect? <rekado_>munksgaard: yes, start a new shell session <munksgaard>But that doesn't seem to change things. I'll try to log out and try again. <rekado_>ngz: do you have a separate “doc” output? <ngz>I dumbly used the package definition generated by the importer. Does it create a "doc" output? <rekado_>otherwise I suggest just adding the relevant doc/ directory to the svn fetch <rekado_>simple-texlive-package will add a “doc” output when the source contains doc/ <ngz>Only if trivial? is non-nil <ngz>Since I need to compile an ".ins" file, I didn't set the trivial? flag. <rekado_>I don’t see your package definition, so you’re in a better position to tell what’s going on :) <rekado_>in that case: no, there’s no “doc” output <rekado_>but also: it won’t copy things automatically either <rekado_>so you better check that after building things you install doc and source <ngz>Apparently, I don't. OK. <rekado_>I should note that this is obviously not great. <ngz>I've seen worse: I packaged Rust stuff. <rekado_>I wanted to overhaul the texlive-build-system and/or simple-texlive-package, but … it’s just so much tedious work with little reward <munksgaard>rekado_, civodul: It doesn't seem to have helped.. <ngz>rekado_: Considering the sheer number of missing packages in "tex.scm", it would be useful, tho. <ngz>So I disagree on the "little reward" part. <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. <ngz>I totally understand. <ngz>In any case, I'm willing to add some texlive packages to tex.scm. So if you need some help, testing… let me know. <ngz>(although my knowledge it limited in that area) <rekado_>for the time being the process you’re following is how it’s best done: use the importer, check with files-differ?, override phases when necessary. <rekado_>improving texlive-build-system probably isn’t terribly difficult, but it’s an expensive change. <rekado_>so getting it just right also depends on an understanding of all the hoops we currently have to jump through in tex.scm <ngz>When trivial? is nil, there's still a copy-files phases, which basically does (copy-recursively "." out) <rekado_>once you’ve added a few new packages I think you’ll have a pretty good grasp of what you’d want the build system to do for you <ngz>my locations contain "doc/generic/babel-french/" and yet files-differ? reports that "texmf-dist/doc/generic/babel-french/frenchb.pdf" is missing. <rekado_>ngz: yeah, not entirely sure why I added this… <ngz>But it should be copied according to (copy-recursively "." out), shouldn't it? <rekado_>ngz: in that case I’d look at the build log and run “find” on the build output <rekado_>sometimes you end up with stuff in the wrong locations <ngz>Hmmm, I have to chdir after 'unpack for compilation. It may be related. <rekado_>munksgaard: what does “direnv hook bash” and “zoxide init bash” do? And where does /run/wrappers/bin get prepended? <rekado_>ngz: it’s a common (anti-)pattern in tex.scm <rekado_>you’ll see that we do this in a couple of places and then also need to adjust what gets copied <ngz>rekado_: Do you have a package in mind that adjusts after chdir'ing? <ngz>texlive-mflogo seems a good candidate. <ss2>I’m having problems loading any file in guile that has the expression (use-module (gnu modules)), the error output is: In procedure git_libgit2_init: Function not implemented <rekado_>ss2: can you reproduce this in a “guix shell -C” session? <gordon1>guix pull takes a lot of time, is there a way to test local channel w/o going through this process every time? <ngz>rekado_: OK, I now have a 100% match for texlive-babel-french! <rekado_>for local stuff it’s much more convenient <ss2>rekado_ no, it says it isn’t a package. It is merely a file now with only the contents: (use-module (gnu modules)) <gordon1>well, it's not really local as per same machine (i test the channel on the VM) <ss2>I just installed guile-git, but that didn’t help. <gordon1>what i'm complaining about is part where it does derivations <ss2>looks much different now. ***attila_lendvai_ is now known as attila_lendvai
<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? <ngz>should I use a nil trivial even though* <munksgaard>rekado_: direnv and zoixide hook up some tools. I can remove them, but I don't think they're the culprit <ss2>rekado_: got it sorted. <rekado_>munksgaard: gotta check those global files then. You need to find a reference to /run/wrappers/bin. Overwriting PATH like that is generally undesirable. <rekado_>ngz: it’s always better to build as much from source as we can <rekado_>ngz: so I usually kick out generated files from the sources <rekado_>…once I know which are generated and which aren’t <rekado_>the texlive.tlpdb is of no use there. <rekado_>attila_lendvai: this is a direct correspondence with SRFI-39 parameters; that module also provides with-parameters*. <munksgaard>rekado_: /run/wrappers/bin is set in the set-environment script referred in my /etc/profile. It's some NixOS thing <ngz>rekado_: OK. So as soon as there's a ".ins" file, I don't use #:trivial #t. Noted. <johnhamelink>Hey friends, I tried to run guix upgrade today, but I'm getting some conflicting entries" <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 <civodul>johnhamelink: hi! you'll probably want to upgrade everything at once, with "guix upgrade" <civodul>that'll make sure all your packages depend on the same emacs-f <jpoiret>ngz: the texlive-latex-enumitem rename just broke `guix pull`, you need to update python-xyz.scm at lines 6547 and 12620 too i think <jeko>AwesomeAdam54321: just saying hello haha <ngz>jpoiret: I forgot to add deprecation. <ngz>I'll add that instead. <ngz>jpoiret: I think it is fixed. <johnhamelink>AwesomeAdam54321 civodul sorry, I got distracted - just took receipt of the new Pinephone running Manjaro linux :o <johnhamelink>civodul: so the guix upgrade produced the same issue, I'm going to try and rollback (haven't done that before so I'll check the manual) <jpoiret>johnhamelink: did you try upgrading the whole profile in one go? <johnhamelink>jpoiret: Yeah, I tried that (that's the command I used originally). I get the same conflict error in that case also <civodul>johnhamelink: you probably don't need to roll back since the upgrade didn't happen <johnhamelink>How should I proceed then? If I needn't rollback, but I can't upgrade? <jpoiret>ngz: now it's a different one, you defined texlive-latex-ulem for the deprecation but it should be texlive-generic-ulem <ngz>jpoiret: I noticed it too, I just fixed that. <ngz>Hopefully this should be good now <nij->Hello! I would like to inspect the scheme object %base-sevices and %desktop-services. What do I have to do? Running `$ guile` wouldn't suffice as it doesn't really load guix. ***califax- is now known as califax
<jpoiret>nij-: `guix repl` will give you a repl with the guix modules in the load path, and you can then type ",use (gnu services base) RET %base-services" <jpoiret>%desktop-services is in (gnu services desktop) <nij->jpoiret: Thank you! I want to see the difference between %base-.. and %desktop-.. , what's a good way to do litharge <nij->do that*. sorry litharge <gordon1> http://ix.io/3NM8/scheme so obviously it complains about package not being a string, how can i do it properly? not yet wrapped my head around all this gexp thing <gordon1>should i make %mdev-default-rules into gexp somehow? <apteryx>woudl someone know why we must keep our linux-libre .configs distinct between i686 and x86_64 ? <apteryx>so, the EMU10K1 (Audigy Soundblaster Live from 200?) driver is disabled because our x86_64 kernel config lacks "Support DMA zone" <johnhamelink>jpoiret civodul so I managed to resolve the issue by removing: emacs-consult, emacs-embark, emacs-elfeed-org and emacs-rustic - now I can run guix upgrade <johnhamelink>I'm going to try and re-install them again after the upgrade and see if that breaks things again <johnhamelink>Still v new to the guix mindset, so I'm not sure if it was my config that's created this issue or if it's something else <apteryx>PotentialUser-41: perhaps try exporting LC_ALL=fr_FR.utf8 ? <apteryx>and make sure you have the glibc-locales packaged installed and GUIX_LOCALES exported as per the manual <jpoiret>apteryx, PotentialUser-41: fr_FR.utf8 is not the name of the locale, but rather fr_FR.UTF-8 <apteryx>thanks for the correction, I wasn't sure <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. <nij->in which hovering your cursor over s-exprs rainbows the corresponding parens! <civodul>nij-: it uses Texinfo to render HTML, and then post-processes it; it's all in doc/build.scm <nij-> it seems that the css magic is fetched from static/base/css/.. do you happen to know the global Aurora_v_kosmose <nij->global url?* -- sorry Aurora_v_kosmose I need to turn off my company mode. <apteryx>when changing our linux-libre configs, do we want to adjust all of them? or is changing only the latest (e.g. 5.16) OK, and the change will be carried into newer configs? <rekado_>ngz: we have both texlive-latex-jknapltx and texlive-jknappen <sneek>Welcome back rekado_, you have 1 message! <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? <nij->gasp.. what if the latest guix has bug? <nij->is it thus a better practice for me to pin to a stabler channel? <rekado_>ngz: I’m really confused about the removal of the texlive profile hook <rekado_>now only packages that use texlive-updmap.cfg get their font maps <rekado_>I’m pretty sure that the same work needs to be done in a profile hook again, to generate pdftex.map and friends <ngz>I didn't follow that move from texlive profile hook to texlive-updmap.cfg <rekado_>texlive-updmap.cfg is merely a less intuitive name than texlive-union :) <rekado_>(well, it also no longer builds a union, so I guess the name change was appropriate) <rekado_>but the work it does is still necessary <nij->Hmmm.. everytime I `sudo guix system reconfigure /etc/config.scm`, it rebuilds ..-grub.cfg.. and -install-bootloader.scm.drv.. <rekado_>the work it does is simple: it runs updmap in an environment containing a bunch of fonts (that depends on the contents of the profile) and then generates appropriate font maps <nij->Why should this be the case? I thought config.scm is a declative file, and thus reconfiguring over it should be an *idempotent* action? <ngz>IIUC, only packages with "execute addMap lm.map" in texlive.tlpdb would need a special treatment? <rekado_>it’s easy to just run updmap all the time, generating font maps appropriate for the given profile <rekado_>if there are no font files we *still* want a font map that corresponds to the contents of the profile <rekado_>having a full font map that contains misleading information would be worse <rekado_>but right now we *always* have *no* font maps at all <rekado_>ngz: the challenge here is just to reconcile this addition of font maps with the search paths of texlive <rekado_>in the past the profile hook would generate a new config file for each profile <rekado_>instead we have a single config with a search path that is specified via the GUIX_TEXMF variable <rekado_>that’s where TEXMFROOT is modified in the installed texmf.cnf <rekado_>so when texlive-bin ends up in the profile (e.g. via texlive-base) it will cause GUIX_TEXMF to be set to the profile’s share/texmf-dist directory <rekado_>when building font maps we just need to make sure that they also end up in the *profile* (not just somewhere in the store), so that the GUIX_TEXMF search path specification includes them <rekado_>I have already reinstated the profile hook locally, and it builds font maps, but they end up in /gnu/store/…texlive-configuration and thus are *outside* of the search path <rekado_>but I can unstash the work and see where we’re at <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? <gordon1>does this list have to be inside gexp? <akonai>rekado_: I'm trying to make a basic system config without most of desktop-services, but like I said elogind seems to error out <gnoo>akonai: also, i had the exact same problem as you <gordon1>or is it possible to define it somehow and then use it inside (computed-file ...) ? *apteryx doesn't grok why DMA_ZONE=n in our kernel, although it should default to =y <apteryx>we have "# CONFIG_ZONE_DMA is not set" <gnoo>akonai: i'm guessing you get the second 'This is the gnu operating system' and then it logs you out? <gordon1>spent whole day, cannot figure it out ***stikonas_ is now known as stikonas
<gnoo>yeah, there's a bug report which can't be reproduced properly <gnoo>so do what i did and remove elogind completely <gnoo>use %base-services instead of %desktop-services <gordon1>if i make this list into gexp like #~(list (mdev-rule (command (string-append $#my-package "/bin/command")))) how should i iterate over it to make computed-file? <gnoo>akonai: interestingly, the bug report mentioned that ssh login worked and if you restart elogind, you can login properly <gnoo>but even ssh didn't work for me <akonai>on my system i can login the second time and it'll work <akonai>but none of the logind related stuff works anyways so there's no point <nij->What's the cute monospace font used by default in the ISO :) <3 <3 <gnoo>also note that if you're used to using 'startx' that won't work, sway and possibly other wayland compositors do work tho <gnoo>for x you preety much need gdm <akonai>you can set xorg-service-type and it'll work with xinit <gnoo>i think i tried that as well, but it didn't work for some reason, can't remember <akonai>just have to setuid xinit otherwise it'll fail <gnoo>setuid is a preety big deal, no? <akonai>it's not recommended to run xorg as root but i'm pretty sure it's not that important <gordon1>ok, simplifying the question, lets say i have a list of packages (list package1 package2 package3) and i want to make a file with their paths using computed-file, how can i do that? <gordon1>ok, if it's so weird so nobody knows that, how i supposed to generate file with bunch of commands that belongs to different packages? is there a way? <mbakke>gordon1: do you mean creating a file system union of a bunch of packages? <gordon1>command1 and command2 belongs to different packages (in default mdev.conf file for example it has modprobe and chmod, first one belonging to kmod package and other one to busybox) <roptat>sneek, later tell zimoun we need to talk about the guix days <gordon1>i want to have a list of those rules in mdev service schema file with ability to specify those commands, something like (mdev-rule "dev1" "root" "root" #o666 package1 "/bin/command1") <gordon1>and then generate a file out of list of such records <gordon1>but the problem is i don't know how to properly use this package1 field to ungexp it <rekado_>ngz: I submitted a patch for the profile hook <rekado_>ngz: could you give this a spin? It may not fix your problem directly, but at least a known obstacle would have been removed. <rekado_>also try setting KPATHSEA_DEBUG to see what files are touched <lfam>apteryx: No idea about ZONE_DMA <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. <nij->Oh.. sometimes I have to source the current profile.. <nij->Is there a way to source it automatically after each `guix pull`? <lfam>Specifically, the recommendation to run `hash guix` after `guix pull` <nij->Hmm.. in the terminal I see it hints me to source the profle first, and then hash guix. <nij->But sourcing the profile requires typing and really should be done automatically, right? <lfam>Presumably, if that was easy, we would have arranged for it to happen. But maybe not <nij->In the manual page you sent, it says: "Unless you’re on Guix System, the first time you run guix pull, be sure.." <nij->This implicitly implies that a Guix System should take care of this automatically. And I'm indeed on a guix system.. so I'm ocnfused. <lfam>You've misunderstood that paragraph <lfam>It says, "Unless you’re on Guix System, the first time you run guix pull, be sure to follow the hint that the command prints" <lfam>"and, similar to what we saw above, paste these two lines in your terminal and .bash_profile: " <nij->Oh, so there are other things that I should do if not on a guix system. <lfam>The instructions are confusing though <lfam>The whole situation is kinda confusing <nij->Yeah. It has multiple meaning, though grammatically corrent. <lfam>But, on Guix System, certains things are handled automatically that cannot be done automatically on other distros <lfam>It would be great to improve this <lfam>I'm not sure how to, but I'm sure it's possible <lfam>Changing the subject, I've seen at least two more problem reports in the last couple days from people who don't understand profile collisions <lfam>Really have to find the energy to write that cookbook chapter about it <lfam>It's a place where the abstraction leaks, unavoidably <lfam>As the package graph gets more complicated, with more package variants and more propagation, collisions will get more and more frequent <lfam>I'm sure many of us can relate to how difficult it is to write good documentation. It's usually harder than writing code <nij->Yeah.. indeed. I don't understand the issue here even. Struggling with a single profile. <lfam>I can help explain it if you want <jackhill>rekado_: woah, does #53609 mean we now have a full-source ghc bootstrap? <lfam>By the way, it's a problem that occurs in a single profile. Using multiple profiles would not make it worse, and in fact is a common method to workaround it <nij->lfam . Thank you. I really appreciate. I will try to understand. <lfam>Okay, first, do you know what a "profile" is? How would you explain what a profile is? <nij->A profile is ... a folder that contains the current state..? <lfam>There's no right or wrong answer. I'm just trying to understand how you see it <rekado_>jackhill: it only means that we have yet another useless old GHC :) <rekado_>but it also means that we *might* be able to use this to build a slightly less useless old GHC <nij->lfam no worries. I'm not stressed. <rekado_>I started work on GHC 6.0, but I also need an old GMP 3, and there are some linker errors that I don’t understand. <jackhill>rekado_: hehe, oh, I guess the source contains the blob. Oh well, still impressive work! <rekado_>no, GHC 4 does not contain any binary blobs as far as I can tell <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 ***df_ is now known as df
<lfam>nij-: As you see, we use profiles in a lot of situations, including for `guix install` and for `guix pull`, as well other tools <nij->So after I run `guix pull`, it updates the "current profile". How do I turn the current profile into my user profile? <rekado_>I just thought I’d share this earlier *nij- feels like he's learning, truly. <rekado_>last time I made progress I made a few notes and then kept quiet about it for two years, and in the meantime not much had happened <lfam>nij-: You don't. The "current guix" profile is only for `guix pull` and only contains Guix itself. Your profile of installed packages is at ~/.guix-profile <rekado_>so I hope that by publishing this promising step I can encourage others to run with it <rekado_>nij-: Guix is eating its own dog food. <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 :) <lfam>The neat thing about profiles is that they are "versioned", and that's how you are able to rollback <lfam>You said that you can't reconfigure because "the guix isn't the current guix". I'm not sure what you mean <rekado_>it’s how we got to have this new confusion: there’s two distinct profiles, but only one of them is for the packages you knowingly installed. <lfam>But, it's not the confusion under discussion. Rather, we are talking about what a profile is, more generally <lfam>The goal is to help nij- understand profile collisions <lfam>I'm gathering information to help write some documentation on that subject <lfam>It's becoming a frequent source of problems for people trying to use Guix <nij->Ok, so if I want to reconfigure the system. <nij->I need to 1. login to root. 2. source the current guix profile (to get the current guix). 3. run `guix system reconfigure ..`. <nij->Now, I cannot do this from the end of a normal user, as `guix system reconfigure ..` will call the wrong (non-current) guix. <lfam>I think that if you actually login as root, then root's own Guix will be effective. That is, if you use `sudo --login` or log in from the Linux console <apteryx>lfam: hello! linux-libre 5.16 has a new option LOGO_LIBRE_CLUT224; should we enable that? <lfam>You can try things like `sudo which guix`, `sudo --login which guix`, `sudo su - which guix`, to see what each one does <lfam>apteryx: I don't know, should we? :) <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>Go for it if you think it's something we should do <lfam>Yes, I use gcc-toolchain, the default version, which is the latest <lfam>In the past, I didn't use GCC from Guix at all <nij->(ok.. so what about profile collision?) <lfam>nij-: Okay, I recommend doing `cd ~/.guix-profile && ls -l` <lfam>Go into the 'bin/' directory in there and do `ls -l` again <lfam>You'll see that it's a bunch of symbolic links <apteryx>lfam: I'm sure this was shared before but I can't find it now; how do you proceed to update the various variants? <lfam>apteryx: You mean the different architectures? <apteryx>do you run 'make oldconfig' for each of them? <lfam>Yes, I copy the previous version's config into the source tree, set up the development environment, and do `make ARCH=$arch oldconfig` <nij->we have everything installed in /gnu/store.. <apteryx>lfam: yes, architectures and their bitness <nij->and the profile is just a bunch of symlinks <lfam>apteryx: The upstream names are i386, arm, arm64, and whatever is default for x86_64 (probably amd64) <lfam>So, then let's talk about these collisions <apteryx>lfam: my initial desire was to build the SND_EMU10K1 as a module; where would this go? <lfam>What do you mean apteryx? <nij->(I'm still confused why can't I hard-code the channels I want in the system config, and therefore changes the global guix that knows the channels I want..........) <apteryx>there are extra-config-flags, then there are arch-specific .config files <lfam>Let's come back to your question later <lfam>Note that this option disappeared at some point apteryx. Maybe figure that out and I'll come back to this later <lfam>nij-: Looking at the symlinks in my "~/.guix-profile/bin", I'll use libreoffice as an example <lfam>I see ~/.guix-profile/bin/libreoffice, which is a symlink to /gnu/store/sm1hznmfrx4qc669nbjlvpgfgq1d735n-libreoffice-7.1.4.2/bin/libreoffice <lfam>So, that's version 71.4.2 of libreoffice <lfam>Imagine that I wanted to test a new version 8 of libreoffice, and compare it to 7.1.4.2 <lfam>I would make a package for libreoffice 8, and then I would try to do `guix install libreoffice@8`. My goal would be to have both versions of libreoffice installed <lfam>But, if both packages of libreoffice create a binary named "libreoffice", I can't have two files both named "libreoffice" in ~/.guix-profile/bin, right? <lfam>We are stuck, because the filenames in ~/.guix-profile/bin are the same as in their /gnu/store directories <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 '("libre@7.2" "libre@8.0")) 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>And, that doesn't really happen usually <faust45>guix environment --container linux what linux mean? <lfam>faust45: We don't have a package called "linux", so that command wouldn't do anything with GNU Guix <lfam>nij-: Usually this limitation does not matter, because why would you try to install 2 versions of libreoffice? <faust45>lfam: works for me, but i run with linux kernel not libre <lfam>faust45: Ah. Then it creates a development environment for your linux package in a container <lfam>nij-: The solution is to carefully change the package recipes so that nobody ever needs to try to install 2 packages that contain files of the same name <nij->Has that been carried out? <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 <lfam>There are some workarounds <nij->I am a bit confused, wait.. <lfam>We can try to downgrade certain packages until all of the packages that depend on python-cryptography, for example, can use the same version of python-cryptography <nij->In package def, we refer to those libs not as their names, <nij->but as package objects, right? (internal to scheme) <nij->Whereas in your libreoffice example, we refer them in the command line by "libreoffice". <nij->So it sounds like two completely different issues. <lfam>The symbolic links that make up the profile are links to files and directories in /gnu/store <lfam>These conflicts are at the level of files, not package recipes <nij->But you mean some packages might dynamically call the files in a profile? <lfam>Yes, certain languages cannot call their dependencies in any other way <nij->What a stupid language @_@ <singpolyma>nij-: the problem in this example is that python does not yet do direct library refs in guix <lfam>So, we have to "install" the dependencies into the profile <lfam>To be fair, Python was created in the early 1990s, long before Guix :) <lfam>I'm sure it made a lot of sense back then <nij->Wait.. but then there's no solution at all, right? <lfam>There are only workarounds <singpolyma>I'm working on it for the same problem in ruby as one of guix related projects <nij->What are some workarounds? <lfam>Like I said, we can be careful about updating Python packages, so that they all can use the same version of a library <nij->that sounds terribly lots of work. <lfam>Or, you can create multiple profiles to use for different Python programs, if that "cuts" the dependency graph in the right way <lfam>Yes, it's a lot of work maintaining the distro! <nij->But the main point of guix is that <singpolyma>nij-: it just takes creating a tool to "link" python scripts and libraries <nij->things should be automatic <lfam>It's more automatic than old-school distros <lfam>But, there's no such thing as magic :) <lfam>I promise, those of us who do long-term maintenance of Guix... we do a huge amount of work. Help wanted :) <nij->im still not sure how it works.. <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>Guix makes it easier to test updates <lfam>nij-: That's an option, but not really feasible for Guix. And it creates a bigger workload in the long-term <singpolyma>nij-: yes, you have to patch the source as part of the guix build to make this work. The goal is to make that patching mostly automatic <jackhill>singpolyma: woah, resholve looks quite nice! Packaing shell for guix as been tedious! <lfam>For shell, that will be great <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. *singpolyma << good at focus <nij->singpolyma has such automatic patching been out? <vivien>If I do it, guix build does nothing and prints nothing (not even an error message) <jackhill>singpolyma: well, those sound more valuable anyways ;) <singpolyma>nij-: resholve is that for shell. I have a project to do it for ruby <nij->where can i check resholve out? <vivien>Like for instance, I have a gexp that outputs a package definition (invoking hall guix), and I need to produce a new package definition that inherit it <vivien>I can create a new gexp that calls (load #$guix.scm) and return a new package inheriting what results from the load invocation, but then I try to return the package object and nothing happens <nij->Is this how the nix community solves the stuff? <nij->So what resholve-for-python will do is.. <nij->it patches so that when libre-office is symlinked to the profile <nij->instead of to "libre-office".. it symlinks to "libre-office@8.0" ? <singpolyma>No, the goal is to not symlink the libraries into the profile at all <nij->And it should also patch the python package so that it dynamically refers to libre-office@8.0? <nij->Getting to my noobie question.. can I specify extra channels in /etc/config.scm so that the global guix always know of those channels? <vivien>nij-, /etc/guix/channels.scm rather <nij->vivien In that case, `guix pull` does the job.. but not declaratively. <nij->It creates the guix I want, but only as the current guix. <nij->current = adhoc .. I wish to have something more declarative. <vivien>You can also configure an unattended-upgrades service that will reconfigure your system in a cron job with the latest commits of a declared set of channels <vivien>(if you use guix system; do you?) <vivien>You can set the 'channels' field of the configuration <faust45>lfam: is it possible to run debian in guix container? <lfam>No, but you could run it in QEMU <lfam>faust45: The command you were asking about creates Guix System containers <vivien>nij-, although I don’t know if it’s possible to trigger a reconfigure at a certain time <nij->Hmm.. yeah.. such thing should exist, right? <nij->lfam do you happen to know? <faust45>lfam: QEMU? maybe better will be docker? <nij->lfam: about if I can declaratively set the global guix <lfam>faust45: QEMU and docker are different. The question of which one is better depends on your goals <lfam>It's better to ask how to achieve your goal, rather than some specific technical questions <faust45>what is the proper way to run docker deamon? do i need shepard? ***lukedashjr is now known as luke-jr
<apteryx>do people think having the running kernel config exposed as /proc/config.gz is a good idea? <vivien>Is there a function that builds a derivation and return its output as a monadic value? <apteryx>vivien: isn't that what lower-object does? <apteryx>hm, it doesn't *build* the derivation, rather it returns one ready to build, if I remember correctly. <apteryx>building a derivation typically returns something in the store <gordon1>is there a way to get a warning or make guix fail if something tries install particular package as a dependency? <nij->Where's the source code of specifications->manifest? <nij->And.. can I use multiple scm files as manifest? Something like `guix package -m 1.scm 2.scm`? <lilyp>yes, but you need multiple -m flags <lilyp>and it should be (guix profiles) <nij->how to you remember that? <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` <jeko>where ynm-web should require ynm-core <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 <gordon1>stage before it goes into the building? <gordon1>what guix does if it encounters cyclic dependency? <jpoiret>gordon1: what are you actually trying to achieve here? <gordon1>i'm trying to make sure that undesired package will never be installed on my system <gordon1>because i don't want to have it there <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>it's just i'm trying to see if there is a functionality to achieve that <jpoiret>but you'll have to switch to a manifest then <gordon1>right, i think i understand that there is no "dependency resolution" in the conventional sense, it just pulls the tree of all the inputs and installs it <jpoiret>it doesn't "install" inputs though. Installing refers to adding a store output to a profile ***GNUfangled is now known as Newfangled
<apteryx>gordon1: note that there's no pulseaudio daemon started by the pulseaudio service in Guix System; it just define its basic config. <jpoiret>i'd suggest using something like (packages->manifest (map your-custom-thing (list your packages here))) <apteryx>pulseaudio is started on demand by applications <gordon1>apteryx: still burns energy and reduces my ssd's resource to have it compiled and pulled to my system <jpoiret>I don't think pulseaudio's closure is that big, but alas <gordon1>and as jpoiret noted above, there are plenty more problematic services i don't have to have on my system <jpoiret>I'm surprised by the number of people discussing dbus/elogind/pulseaudio-less systems here <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 <gordon1>ah ok, so manifests are the only way <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 <jpoiret>there is a user-facing manifest mechanism, and also an internal one, and they aren't the same