IRC channel logs
2024-07-13.log
back to list of logs
<ieure>I've packaged some of my own software in Guix, I pretty much send in a patch to update the package when I make a change I care about using myself. <spenc>jackhill, if the problem with fossil is that the .zip format is nondeterministic, would it be possible to unzip the file and hash the results there, as opposed to comparing to the hash of the zip <spenc>downsides would be that getting the hash is not as easy as 'guix download' and that it still doesn't solve for 'amended' checkins <rickame>if i want to implement guix package manager on another OS in python, what's the process like? i looked at guix source of .scm files and is there any half way solution to rewriting all of that? <rickame>like maybe to get started i can just parse a user's .scm config in python and translate that to the actions needed for the host OS? <rickame>guix daemon used to be made in another lang than guile right? <rickame>but it takes in derivations and our configs which are in guile format no? <rickame>if i want to implement guix package manager on another OS in python, what's the process like? i looked at guix source of .scm files and is there any half way solution to rewriting all of that? like maybe to get started i can just parse a user's .scm config in python and translate that to the actions needed for the host OS? <rickame>what do you think is the easiest way to do "guix on unsupported OS in different lang"? <Gooberpatrol66>the very simplest explanation of guix is something like "download source code, make a hash of it, store it under the hash file path, build the source code, hash the output + the hash of the source, store it under the hash" recursively <rickame>ok that part is easy. the tough part to me is how do i handle interpreting the data files. so all the configs done in guile, derivations <Gooberpatrol66>i imagine you would need to write a grammar to parse .scm if there's not a library for it <rickame>so you basically gotta make a scheme parser and a guile/guix interpreter? <rickame>because you can put "code" in your config as it's the same as data in guile <rickame>there's gotta be a better way. i think the guix config format and idea is all great. just need to figure out how to like, bring it to windows using python <rickame>im trying to think of how i could take all the input text (configs and derivations or whatever) and just give it to a guile compiler to handle <rickame>but i guess it somehow needs to have the standard lib our configs and derivations use to do things like change the local_platform host-name <lilyp>Why bring it to Windows using Python specifically? <lilyp>What are your requirements and would they be served using existing package managers for windows? <lilyp>Or could you even do with the mingw cross-compilation already present in Guix? <rickame>well py is what i know so that's that. and bring it to windows instead of making yet another new thing <lilyp>Well, so are existing package managers for Windows – what benefit do you hope to get from reimplementing Guix over using one of them? <lilyp>(Note that reimplementing Guix is very much "making yet another new thing") <rickame>and ignore windows, it's not about which OS it is, it's about "currently unsupported OS" <lilyp>Is there a way of specifying a particular version for guix refresh? <necto>Does `guix build` run in offline mode? <necto>I'm trying to understand why my package for an npm-based application fails with ENOTCACHED <lilyp>`guix build` does not have any network access whatsoever <lilyp>npm-build-system ought to set up your dependencies <ente1>I have a freshly installed GUIX and I noticed that some fonts are apparently missing (the manual has blank spots where code snippets should be) <lilyp>that's… interesting, there ought to be at least one monospaced font <necto>Do I understand correctly that if I an npm-based app has some dependencies in its package.json, I have to package them first with guix and list explicitly as the guix package dependencies? <ente1>but good point, let me check the stylesheet <lilyp>necto: yep, that's how it is <lilyp>we do have a procedure for stripping *unwanted* dependencies, but if your application needs them… well, tough luck, you ought to package it <rickame>serious question, why not use a simpler config format than guile? like json or yaml <Franciman>uhm, the pros of guile is that you can have a full programming environment <Franciman>while json and yaml are just syntactic forms <rickame>but why do you want that in your OS config? <Franciman>rickame: wait, i think you have to distinguish syntax and semantics <Franciman>json and yaml (which i find very ugly lol) are just syntactic forms <Franciman>so are you saying that you would prefer a less powerful language for the config <rickame>ya because otherwise, what really common thing could we NOT do? <Franciman>or are you saying you don't like s-expressions and would prefer config to be written in json but with the same expressive power? <spenc>and fwiw, as a n00bie who is clearly missing the point, I do agree that writing a package.scm aint easy <spenc>compared to a dockerfile or a npm package.json <rickame>why? why do you want a full fledged programming environment in your OS config? <hiecaq>I mean, you have to examine and trust the source code anyway <spenc>again, as a n00b- i think the point is that the underlying data structure, the derivation, needs to be generated <spenc>because it's too annoying to work with directly, and doing so with a language is the most flxible <spenc>and if you're going to have a language, why not scheme <hiecaq>Also Nix and other package manager's DSLs (pacman's makepkg etc) involves invoking some bash code at some point in many package definitions. With guile some of these can be just done in Guile. <spenc>i've wondered why more of that isnt bash tbh, it would make it easier to go from: "source's normal install instructions" -> guix package, which i gotta say is a challenge for a beginner <rickame>maybe it's not pure enough for guix? <spenc>but idk, i assume there's definitely good reasons, and as a beginner I wouldn't know them yet <spenc>it seems like a very competently run project <lilyp>I mean, using a non-Turing-complete language to shell out to a Turing-complete one smells like a bad design decision imho. <spenc>lilyp, i think maybe the confusion is that language specific package managers can usually get away with a pretty simple config file, that just speifies what to download while guix is solving a more general problem <lilyp>Yeah, Guix very much tries to be a system, not a language package manager. <lilyp>IMHO language package managers were a mistake that was born out of Windows and Apple not having a distribution model. <spenc>ive been trying to decide how i feel about that for the last week or so <spenc>certainly, something like guix benefits a lot from having everthing packaged in the same place, so language specific ones work against that <spenc>and it does seem silly to switch languages and have to also learn a new config format because no two projects can agree apparently, despite efforts like conda to make a general one <spenc>and it does seem like guix solves most of the same problems npm does, (except specifying exact version ranges, though time-travel and channels and inferiors lets you do this in a more complicated way) <spenc>but wow is it definitely more complicated <spenc>and it isn't easily done in guix yet, i assume for good reasons <spenc>but i can't see very many (any?) people working on a node project to want to switch to guix <Mileo>why when i use guix live cd the characters of my language are displayed correctly, but if i press ctrl alt f3 the window shows question marks instead of the characters of my language.and it seems that after installation the problem with these question marks instead of letters persists <spenc>also, the language package managers are a standard, installing things with an OS-specific one has been a hassle for me so far <lilyp>language package managers are the very definition of "the implementation is the specification" <spenc>because one instruction gives the rpm names, but apt has a different name (lib-) and guix has a different one too, and they don't all have the same versions of things <spenc>ok standard in the , theres only one version , not standard in the nice engineering-y way <spenc>though I guess that can mostly be solved with channels, so there'd be a language-specific channel for things <spenc>or maybe not even language specific, but somehow getting everyone to agree on it, that seems like the hard part <attila_lendvai>so, a `guix system image --system=armhf-linux ...` on an x86_64 fires up a qemu, and apparently seems to take forever... can i instead just cross-compile from the x86_64 host? <attila_lendvai>hrm, it progressed to downloading just now. apparently it's just quite slow, not hopeless. <Franciman>i wonder what news this guix pull are bringing over <Franciman>rickame: imho one advantage of the current guix system config language is that it allows you to access guix internals <jab>is anyone else having the problem with guix deploy silently failing? It will look like it worked, but "guix system describe" is not updated even after a reboot. <elpogo>attila_lendvai: it might be faster if you run a debian bookworm armhf vm, install apt's guix on that vm, update guix and then build the image inside the vm. that way you're more likely to find substitutes than for cross compiles <elpogo>attila_lendvai: i'm an idiot. ignore what i wrote. i mistook --sytem for --target <jpoiret>efraim: hey, coming back from the dead to say that the python-certifi ungrafting on core-updates leads to some packages not building, since there might not be a SSL_CERT_FILE to rely on in build environments <jpoiret>I patched two packages locally to set a dummy SSL_CERT_FILE to one coming from nss-certs, but I wonder if this should be done for dependents individually or some other way <rickame>Franciman what can you get out of accessing guix internals? <elpogo>rickame: i asked in #fosdem about that, but didn't get a good answer <lfam>Did they give an answer at all? <elpogo>lfam: i did ask efraim in this chatroom about 8 hours ago <lfam>Probably will answer later <lfam>I mean, it's likely the video was not capture due to technical or organizational difficulties <rickame>good thing it's a technical conf and ppl in 2023 can't figure out the record button <rickame>i found corrupted fosdem 2023 vids the other day too. they're definitely not running zfs <lfam>It's a conference that is run by volunteers. Easier said than done <lfam>I actually do video production as my job and I've been to fosdem. They do a good job considering the circumstances and the budget <ente1>speaking as a volunteer who helps out whoever he goes.. worth it though <ente1>I missed this year's fosdem (and particularly offdem) though <lfam>"can't figure out the record button" is something that happens sometimes even at the highest levels of television and film production <ente1>I'm trying xfce now after a long time and I gotta say it's still decent <ente1>didn't become bloated and is still user friendly <ente1>I am going to do a workshop and I don't want to get people distracted by my regular window manager <ente1>anyway gotta sit down and prepare <dariqq>is there a way i can increase the size of /tmp resp the build environment? I got builds failing halfway through due to lack of space but plenty seems available? <lfam>What is your /tmp? Is it a tmpfs? Part of your root partition? Its own partition? <dariqq>i didnt set up anything special for it. So i think just part of tthe root partition <PotentialUser-56>is there a way to install guix as a distro from an already existing system <lfam>dariqq: Run `mount` to find out the answer <lfam>PotentialUser-56: Yes, the `guix system init` command can do that <lfam>Read the manual for details <ente1>spenc: window manager wise? notion <dariqq>lfam: it is part of the root partion and 15G should be avilable. But when building i get a low space warning and eventually the build fails. <lfam>dariqq: You are probably running out of space <lfam>Which package are you tring to build? <lfam>Yes, you are probably running out of space <lfam>Try running this command during the build and observe the free space: `watch -n1 df -h` <dariqq>building the kernel needs 15 free gb space now? Probably need to increase my vm then <lfam>dariqq: Just try monitoring the space to be sure <lfam>Are you building with multiple cores? <lfam>There are ways to adjust the space requirements but you should be sure before you start changing things <dariqq>it takes 40 mins or so . So trying again now. <lfam>Then maybe redirect the output of the command to a log file so you don't have to pay attention <lfam>I'll do it here too, building with 12 cores <lfam>I gotta go AFK but I'll report back later <dariqq>gced some extra 10GB and changed from 6 to 4 cores now. <lfam>`watch` does something funny that makes it hard to log <lfam>I'm using this instead: `while true; do df -h; echo ; sleep 1; done | tee -a log` <dariqq>after 40 mins still 20GB free (out of the 30 is tartted with). Now the interesting part begins <dariqq>lfam: it got down to 11 GB but is now finished. After the build dir is deleted i am back at 30 gb free so appearently 20GB+ free space is needed, not sure what uses that much