<KarlJoad>podiki[m]: I think the package that generates a scheme program would be more guixy, because the xrandr input would be explicitly known by Guix. <KarlJoad>But I am not sure how much work that would really be, which is the other problem. <nckx>Cairn: I'm no expert either. I'm sure Postgres will handle it finely for a good while to come, but still. Cuirass isn't *that* old. <podiki[m]>ah yes, if you have some things that are needed inputs/paths, that would make sense <pashencija[m]>What file in the repo do I put the package? It's a simple GUI note taking app <KarlJoad>podiki[m]: The script just resets my monitors, because one of them is stupid and is not picked up by X to nicely for some reason. So, xrandr fixes that. So a package generating the Guile program makes more sense in that case? <pashencija[m]>> What file in the repo do I put the package? It's a simple GUI note taking app <pashencija[m]>Like I packaged FeatherPad to text-editors.scm. However, note taking app is not a text editor, so I need another place <podiki[m]>I don't think it will matter much, sounds pretty simple as either a bash script as a package (xrandr input, you don't need to install xrandr then) or package that makes that little guile script. I don't have much experience with the latter <podiki[m]>but if you wanted to learn guile scripts, sounds like a nice little project <nckx>pashencija[m]: task-management.scm? (Bit funny in its bombast, but hey.) Or you could create a new notes.scm. <nckx>It's more apt than text-editors.scm for sure. <podiki[m]>KarlJoad: I also messaged you on another channel with a reference <nckx>pashencija[m]: Thank you! <podiki[m]>if I was being cheeky I would say a new module called you-could-use-emacs-instead.scm :-P *podiki[m] prepares to duck from the vimers <KarlJoad>podiki[m]: What other channel? I don't appear to have gotten the message. <nckx>Web site generator choked on my glorious placeholder front page so now it's gone. <podiki[m]>a non-free related one, so that's all I'll say here <nckx>Our bug database is bigger than our CI database. <nckx>Don't you kids dare take that as a metaphor. It's not!!! No. *Cairn takes the metaphor and runs off with it, laughing <lilyp>Well, it is the database of *all* GNU bugs, though <Cairn>But ci is the database off all (and more) gnu packages ;P <nckx>(It's also duplicative as hell, unlike the postgres one.) <nckx>Hmm, Cuirass isn't logging why evaluations are aborted anywhere I can find it. <lilyp>even if guix did contain all gnu packages (which for one, i doubt), the store items take up much more size than db space *nckx always forgets to expect a torrent of log activity when they paste something here. *nckx frowns at the bot fetching /railsapp/config/storage.yml — no, just no. <KarlJoad>Is there a way to interact with Guix through Guile? Meaning a guile script I write calls something like "guix shell"? <lilyp>pashencija[m]: we're just recovering from complete failure and even before that patches took time until they were visible <pashencija[m]>I just hope my FeatherPad and FeatherNotes patches do not get lost :) <kabouik>I initially thought those issues were due to another package I was trying to get working (Discord), but I removed it from the private channel and the errors are still there. If I disabled my channels, errors are gone when doing guix pull. But I can't relate the errors to the only remaining package I have in the channel. <pashencija[m]>kabouik: Your discord package uses binary from the website, right? <pashencija[m]>If so, double check the code related to enumerating architectures <KarlJoad>lilyp: Is there going to be a post about the outage? I'm curious what happened. <kabouik>The Discord package is gone temporarily pashencija[m], so the errors are not due to it (but it will bring some more) <kabouik>It's based on the .tar.gz from the website by the way *lilyp points at the don't discuss malware sign. <kabouik>You can find it in earlier commits of the git URL I shared above pashencija[m], but since I get issues even without it, I need to fix them first <kabouik>Yes I'm not posting about it, just wanted to elaborate what I thought was the issue, then removed this package.scm, and still got issues on the remaining package which yet used to build fine some months ago; and I don't see the link between that package and the error I'm getting in the logs. <kabouik>Weird, not for me. Let me use another paste bin for you <pashencija[m]>I don't mind chinese characters, but I'm afraid I don't understand them <kabouik>Wait. Is that possible that guix is trying to pull package.scm files from the hidden .git folder in my private channel directory? That'd explain things <kabouik>It might still try to pull packages.scm I deleted but that still appear in the git history <pashencija[m]>Secondly, I doubt it's possible to guess the error without channel source code <kabouik>I posted the channel source code above (10 min back in the logs) <pashencija[m]>kabouik: It's not possible. Check if you're using the correct branch <kabouik>My channels.scm uses the local folder (file://) pashencija[m], so I don't think the branch should matter? <pashencija[m]>kabouik: It should! Guix clones local repo and switches to the latest commit of the predefined (in channels.scm) branch <kabouik>That's a good question; something I was probably advised to do 7 months ago without fully understanding; but it did build at the time (I have nnn installed from this package still). But I am not sure how the errors still refer to discord while the scm file has been deleted locally and remotely <pashencija[m]>I think something in your system points at the wrong commit. Are you sure you "delete" commit is HEAD on the correct branch in both local and remote repos? Double check <kabouik>4b4344f209 commit is head on both as far as I can see <the_tubular>I have a package in my /gnu/store repository, that I did not specifically asked to be installed, is there a way to see which packages pulled it ? <the_tubular>I know there is like guix graph, but is there something else ? <podiki[m]>guix gc --referrers I think (or --references?) <clever>`nix-store -q --referrers` on the nix side of things <podiki[m]>for the path you want to see the references/referrers of <podiki[m]>e.g. guix gc --referrers /gnu/store/<hash>-program-version/ <clever>and `nix-store --query --roots` to see exactly why it cant be GC'd <clever>podiki[m]: i know nix better, and i assume the guix flags are named similarly enough to translate over <the_tubular>I'll note that somewhere I like seeing where my packages are coming from <podiki[m]>yes, guix gc has all those "investigate the store" type stuff <podiki[m]>though can't say I browse my /gnu/store directly, tis huge <clever>its also in its own zfs dataset, so i can just "df -h /nix" <podiki[m]>it is more the amount of files than the size that takes a while to navigate <the_tubular>I guess you do this so you can just backup your other dataset correct ? <clever>the_tubular: yeah, i have automatic snapshots setup on every other dataset <clever>mostly so i have an undo button if i delete something by accident <clever>and /nix is excluded so gc actually works <podiki[m]>I actually haven't done any snapshots, but yeah, would make it cleaner <clever>i started an `ndcu -x` on my store, its only found 12gig so far, lol <hako>is there any way to delete an extension from a service-type? <hako>e.g. the service-type mounts some filesystems by extending file-systems, but I want to do this manually instead, how could I achieve this? <kabouik>Is there anything to do to optimize guix operation times? <kabouik>I started `guix install steam firefox` hours ago and then wanted to install a couple other things that came up to my mind minutes later, but I can't since guix is busy, and I'm out of ideas of what to do while waiting <kabouik>(Wish guix could roughly predict how long an operation will take, at least, but I know this is difficult; the problem is the time it takes is not the same order of magnitude as package managers I'm used to, so I didn't expect there would be such inertia between my commands) <kabouik>It does say it's building but there's no indication of how far it is or how much remains to be built <kabouik>I suppose nonguix takes longer than guix due to the lack of build farm, so Steam might have been responsible for quite some time spent there; Firefox is in guix though I believe <kabouik>I guess I'm going to try a `sleep 2h && guix install xxx` and actually go to sleep for 10 hours! :P <kabouik>Because guix is busy installing/building other stuff <podiki[m]>kabouik: you should discuss those things in the appropriate channel (only free software here); but that other channel does indeed have substitutes <podiki[m]>browers like icecat, ungoogled-chromium, etc. take forever to build and need a ton of memory <kabouik>I didn't think my question was related to that other channel initially, and still am not sure it fully is, since Firefox is in guix <kabouik>But I think I'm just not used yet to how long building everything can be (I've never used Gentoo for instance), and don't know how to predict when an install will need many dependencies to build <podiki[m]>you can see the "guix weather" command to see substitute availability <kabouik>Oh, you're absolutely right, thanks! And sorry for the confusion, my bad. <podiki[m]>though with some issues this past week some things are a little behind <podiki[m]>what you say applies for icecat/chromium as well, they take a long time to build; or if you need to do the full rust toolchain bootstrap, very long <kabouik>I just read about substitutes on the web some minutes ago, still reading to understand what they are. I assume they are like precompiled dependencies that may or may not be up to date to the latest versions available <podiki[m]>assuming you are trying to build what has been built on the build farm, with substitutes you will just download the result instead <podiki[m]>(done by the build hash to know if it is the same or not) <podiki[m]>anyway, gotta get going, but if you don't want to compile everything, generally you don't have to <kabouik>Actually if I had noticed icecat was there, I would have picked it over Firefox. I use Nyxt as my browser anyway, but wanted a backup one because Nyxt is not very stable yet. However I don't think I can cancel my Firefox install without losing the other packages I installed at the same time, so I'll wait until it ends. <podiki[m]>you would only lose any progress in what is currently being built, I think everything else built/downloaded will still be in your /gnu/store to be reused if needed (unless you do a garbage collection of course) <kabouik>So substitutes are automatically picked by `guix install xxx` if xxx has a matching hash substitute? That's nice, and now I know I can use guix weather to check if this will be quick or not (even though I can't predict how *not quick* it may be when no substitutes are availabel). <podiki[m]>as long as you have substitutes enabled, which I think is the default <trevdev[m]>I did a reconfigure that broke my user pretty badly. The $PATH is presumably gone. I cannot invoke guix. <trevdev[m]>I fixed the typo as root. How do I reconfigure home when invoking .config/guix/current/bin/guix does nothing? <trevdev[m]>Got it, just forcibly removed the bash profile as root and relogged in with my user. That was fun <philip>How can I start a shell to run mescc? If I try `guix shell --pure --container mes nyacc coreutils -- mescc zuo.c`, I get `error:include-from-path: not found: :(nyacc/lex.scm)`. ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net/ | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: https://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
<nckx>kabouik: Running multiple ‘guix install‘s in parallel used to be possible, but it was deliberately disabled. It still works with ‘guix build’, however! The builds will still happen in parallel, and you can almost instantly ‘guix install’ the result later. <nckx>Still can't say I understand the rationale for that big ‘guix install’ lock, but it's easy to work around. <nckx>issues.guix.gnu.org is now synchronised with debbugs. <nckx>Thanks to rekado for the dirty secret behind *that*… <nckx>kabouik: <So substitutes are automatically picked by `guix install xxx`> To add to podiki[m]'s answer: you also need to make sure that the public key is authorised, or Guix will not trust the server even if present in the list of URLs. This is unfortunately the case with bordeaux if you installed from 1.3.0. If ‘grep 7D602902D3 /etc/guix/acl’ returns nothing, you're missing out on FREE substitutes included in your subscription, and you should add it ( <lilyp>nckx: IIUC the lock is there because `guix install' constructs manifests early on <nckx>But did it do so before the lock was added? ***Dynom_ is now known as Guest4982
<nckx>I used parallel ‘guix install’s with abandon in the before times, and I'm not usually that lucky. <nckx>lilyp: What's the rationale for that? <lilyp>I'm not sure, I think people got some unexpected result. <lilyp>E.g. `guix install hello & guix install bash' installing either hello or bash but not both <lilyp>the real deal breaker would be roll-back tho <nckx>If they did, holding a lock during the entire build only coincidentally addresses it. <lilyp>like if you have a bunch of `guix package' commands running side by side, one of which is a roll-back, then the end result is super undefined <nckx>OK, that one does make sense. <nckx>(People use roll-back? Wild.) <lilyp>Well, it's an advertised feature. I suppose they do when stuff breaks <lilyp>Which fortunately is rare, but still <nckx>I understand that lock_wait && build && mkprofile && unlock is simple (and therefore safest) to implement but I think it's much more restrictive than is needed to protect against that. It wouldn't matter if builds didn't take hours. They just make that very obvious. <nckx>I mean, the obvious work-around is to literally move the build part outside of the lock by hand, there's no reason Guix couldn't do that, but it would add a little bit of complexit (roll-backs waiting for extra locks). <lilyp>I think failing early is a good design choice here, though <lilyp>Imagine having `guix install' run for 7h+ and then failing because it couldn't claim some lock <nckx>This was somebody's argument then, too, and it makes as much sense to me now as it did then. <nckx>How is failure suddenly being introduced here? <lilyp>well that's the status quo: you run two guix package process and whoever is sad that the other has the lock goes boom <nckx>Hm, wait, this is the package manager that crashes if you're out of build users rather than just waiting for one to finish. I can see the appeal. <nckx>We have no problems waiting for build slots, though, so I have hope. <atka>*nckx's hope intensifies <nckx>lilyp: IIRC the boom was introduced together with the lock, it's only been the status quo since then. <nckx><How is failure suddenly being introduced here?> s/How/Why/ really. <lilyp>I mean, you could revive bug #38649 <nckx>That's not mine. It was just a conversation with Ludo'. <nckx>It's not *hard* to implement, but it seemed clear that it wouldn't convince him. <unmatched-paren>Ah, issues.guix.gnu.org is working now. The magic cable's been plugged in, I guess :) <nckx>Ah, ditto here: ‘IMO, there’s no reason to run multiple ‘guix package’ on the same profile concurrently. With a wait-for-lock policy, the result would be non-deterministic: you cannot tell which one of the two processes will complete first.’ <nckx>I literally don't know how to argue with that. <nckx>unmatched-paren: More like the magic rsync-bash-loop-running-in-GNU-screen. <nckx>I guess we just fundamentally disagree, which is fine, and I'm not going to try to convince the world I'm righter. <nckx>Seeing people artificially cheated out of a productive night of building IceCat just breaks my heart 😉 <nckx>ncbfg36: Could you give me a ping when you're around? Thanks. <minima>Hi, I was looking for a LaTeX package called xesoul, via 'guix shell texlive-base -- tlmgr info xesoul' but that doesn't seem to return any result <minima>is it possible that my tlmgr database may have got out-of-date? (not terribly guix specific I imagine...) <minima>'guix import' also fails for that particular package <lilyp>minima: texlive is on version 20210325 (read that as calver) whereas xesoul was contributed on 2021-03-30 <minima>ah lilyp I see, thanks, that makes sense <minima>so a possible (but not sure how big of a task) solution would be to update the texlive definition... <minima>philip: I think I had the same issue, but it works for me if I do: 'guix shell subversion -- guix import texlive ...' <minima>Or you can simply install subversion once and for all... not sure why my past me was so reluctant in having svn... ahah <lilyp>texlive updates are usually nontrivial <unmatched-paren>Hmm, the given description of the subversion package is quite surprising <minima>lilyp: ok, thank you very much, I'll see if I find a workaround for now <unmatched-paren>it looks like the kind of enterprise-speak you'd find on the Apache website, but not in a Guix description :) <sailorCa`>Hi, could you please help me with the `guix build` command? I think I miss something basic. My expectation: I can write a file, i.e. repo/packages/npm.scm, put a package difinition here and then I can build it with `cd repo; guix build -L . package-name`. Also, please see my file: https://pastebin.com/XBm4PECM. In reality I've got the `guix build: error: npm-yarn: unknown package` error although `strace` shows me, that g <unmatched-paren>sailorCa`: hello! could you please use paste.debian.net instead of pastebin.com? <sailorCa`>I don't know what I'm doing :-), so I've took other packages definitions and going to compose/modify them until it works. <unmatched-paren>well, if you have a hidden package, it won't be visible for the `guix package` commands <sailorCa`>confirm, after removing `hidden's properties` guix found the package's definition. <sailorCa`>yes, I think so. That's far away from a final version. <unmatched-paren>It'll fail. Guix doesn't allow anything to access the internet in the build environment. <sailorCa`>I'm not very happy to touching it. But I don't see another way how to install the signal messenger to my guix's pc. <sailorCa`>Anyway, I'm going to try. At least I'll learn guix better after that. <sailorCa`>Unfortunately, people start to forgot how to use emails. And I need to contact them. Apart of that I agree with your message about js/node/electron. It's just wrong. But popular. But wrong. <jab>unmatched-paren: and nckx hello! <jab>nckx: you said that you might watch my peertube playlist to see how relative new comers to guix get started devleoping for guix... <jab>I would say it would be nice to see an addition to the guix manual: "Conventions for writing services" <jab>I am starting to thing that define-configuration is better than define-record-type*, but I really do like for define-record-type* lets you define sanitize functions. <nckx>I agree. There is little (if that?) to help folks actually write new services. ‘Look at the existing ones’ is literally your best option. <nckx>Great if you're the inductive type, but nothing to be proud of. <nckx>Oh, and ‘figure out what still commonly exists but has actually been deprecated since then’. <redsith>Hi guys, trying to install guixsd on a ryzen laptop but i can't get the iso to boot, anyone had a similar issue? <jab>nckx: I personally have been using the nginx service as my example service. <jab>example service --> service that I reference. <jab>redsith: can't get the iso to boot --> can you say that in paragraph form? <jab>How far in the boot process did you get? <jab>how new is the laptop? <nckx>jab: I never understood services and was frankly too intimidated to dive in until someone gave me a 10-minute 1-on-1 chat in person at FOSDEM. We sorely need that kind of guidance in the manual, but I'm not the right person to write it. <nckx>(It was actually a BoF session but I was the only B, which was great :) <redsith>not long into the boot process, its a lenovo ryzen 3 system <redsith>it crashes almost instantly (no log, just black screen) <jab>redsith: did you ever get to the grub screen? *nckx wouldn't know much about modern laptops so watch out, I believe anything you say, do not abuse this power unmatched. <unmatched-paren>I think linux-libre has some issues with anything other than Intel or old Nvidia <redsith>i cant get a guix dev snapshot for testing, i get 502 bad gateway <nckx>redsith: What I'd do first is edit your kernel command line by pressing ‘e’ at the GNU Guix menu entry in GRUB, and adding ‘nomodeset’ to the end of the line that starts with ’linux’, then pressinc C-x to boot. <nckx>redsith: Sadly, whilst some code is, IIUC some isn't (packaged as ‘firmware’) and it's needed for a good experience. <nckx>redsith: But the problem would very likely not be solved by a newer ISO. <nckx>I'm not aware of any big leaps in that department. *nckx would love to be wrong. <redsith>yeah, so may need to build iso with firmware embedded i guess, thanks <nckx>unmatched-paren: <Not much of a review> No no, you painstakingly reviewed every line of my patch and were forced to conclude that it was perfect in every way. This is what I am hearing. Thanks! <nckx>I wasn't sure if that was unguixy, since the package might already offend (IMO unjustified) FSDG purists. <nckx>So putting the editor right there with the game was my way of saying: look, go, create. <nckx>Maybe overthinking as usual :) <jab>nckx: yeah do you have a link to a youtube video that gives advice about service definitions? <jab>also, way to go nckx for helping redsith with the booting issue. I knew that there was a way to fix it with grub... <jab>yeah that video is way too long! Maybe I should try to condense it. <jab>I could easily make a video covering endlessh. <nckx>I think videos are valuable and a good way to reach a large group of people, who just aren't me. Nothing against videos. <muradm>56858 - updates libcgroup to 2.0.2 <muradm>kind reminder for show stoppers: 56690 and 56699 seatd-service-type and greetd-service-type fixes. <muradm>kind reminder: 56579 and 56608 fail2ban package and fail2ban-service-type <muradm>minor reminder 56689 (mako update) 56688 (new package sworkstyle) <Cairn>Hey, I'm having some trouble that I haven't seen before. I'm trying to run certain binary files, and I'm simply getting a `bash: ./program: No such file or directory` error. And of course, they're right there. <Cairn>With hugo, it's only the extended release that does that (near the bottom of the release list) <lilyp>Cairn: and what about the dynamic libraries ./program links against? <Cairn>Would that be what's causing this trouble, do you think? <Cairn>Hm, alright. Didn't know that. <Cairn>I was just surprised by the incredibly unhelpful error. <Cairn>I'll look into what each package needs. <nckx>Cairn: Start with /lib/ld-linux-x86-64.so.2. <nckx>The patchelf programme might be handy here. <Cairn>Wait, so do these libraries tend to be packaged with guix? Like, by start with, do you mean install? Or do you mean figure out? <nckx>Cairn: Installing glibc (which provides this file) won't suffice, since the binary hard-codes its location at /lib, where Guix puts everything in /gnu/store. <Cairn>Hold on, so does that mean I can rebuild these programs instead? They're both foss. <nckx>I believe that the above service (which I've not tested) sets up this and more. If this is all Greek to you, it might be the easiest way forward. <Cairn>I just need to make sure they find the right paths to libraries? <nckx>Cairn: It might, if they don't depend on a bajillion Rust/JavaScript/Go/… packages. <Cairn>Well I'll try rebuilding brogue I guess, just to get a taste <Cairn>Do all guix packages that relies on stuff like this get modified in this way? Or is it that they're provides those files within their own package directory? <nckx>An FHS compatibility option for Guix containers is probably coming in future, but sadly it's not here yet. <nckx>Cairn: When you build something with Guix, the Guix build systems take care of 97% of this transparently. The other 3% is indeed manual patching. <nckx>By ‘build with Guix’ I do mean as a Guix package. <nckx>I'm afraid I have to go. Good luck. ***califax_ is now known as califax
<oriansj>civodul: wouldn't the correct term be unpaid interns as we don't pay the workers? <oriansj>and since they don't have a choice to work, wouldn't the more technically correct title be Slaves? Or would we be going with the Grandmaster term: "the prisoners with jobs" have resumed their tasks <roptat>\o/ the French translation of the manual is at 100% <lilyp>oriansj: like a reverse python? ***user3456_ is now known as user3456
<oriansj>lilyp: well it is hard to add music to IRC but... Cheer up Brian, you know what they say? Some things in life are bad They can really make you mad Other things just make you swear and curse When you're chewing on life's gristle Don't grumble, give a whistle And this'll help things turn out for the best And ♫♫ always look on the gloomy side of life ♫♫ <bdju>perhaps a new dependency needs to be added to the recipe <bdju>it says module QtQuick.Dialogs is not installed <unmatched-paren>instead of restarting the daemon and running it again inside the shell <unmatched-paren>there does not seem to be a :guix-shell or :guix-environment command provided