<oriansj>still need a good deal of chemistry sorted out to enable the lithography of ICs from melted sand but atleast knowing how to create a screw and lathe from wood I guess is a solid start in the right direction
<oriansj>as solving the screw bootstrap problem turns out to be a bigger technical challenge than building a C compiler in assembly in 24 hours
<muradm>faced some wierd rust packages, for instance rust-wayland-client-0.29, why inputs are duplicated in both #:cargo-inputs and (inputs?
<muradm>removing (inputs ...) and leaving just #:cargo-inputs seems working
<SeerLite[m]>Hi! Does anyone know where Guix stores checkouts that come from the --with-git-url transformation?
<SeerLite[m]>I'm trying to install a package but an older revision of the checkout seems to be conflicting with the current one, a directory with files was converted to a separate submodule and git complains with "directory exists and is not empty"
<SeerLite[m]>I don't get the issue when cloning from scratch, but I guess Guix is trying to be smart about it since it's a transformation and tries to update the existing checkout
<nckx`>I'd expect it to live in ~/.cache/guix with the rest of the checkouts.
<muradm>twei: may be a good idea to prepare both packages, and send to guix-patches in a patchset with 2 commits one after another :)
<muradm>i.e. if some tool is needed, dependencies should be present by definition
<tewi>hmm it seems that some links on guix.gnu.org/contribute return 502 bad gateway. is there a page with guidelines on sending a patch? or should i just get the newest file i want to edit from git repo, edit it, and generate patch as normal and send via email?
<tewi>oh by the way, is there a verification that a package submitted to the guix repo actually builds? i'm pinned to the commit 7f672327c0755c20f062819fee4d3d4ff3b9829d (a bit old), and i noticed that wine64-staging has no substitutes, and also fails to build on my machine. so i was wondering if it failed to build on the substitute server too?
<nckx>tewi: To add another to the previous (correct) answer: libraries or other packages aren't rejected or removed simply because they are leaves (i.e., have no dependents).
<nckx>That status might push some over the edge, but it won't get them there.
<tewi>nckx: are there some strict criteria on what package might get rejected, besides licensing issues or straight up broken stuff?
<nckx>Expand licencing to general FSDG issues (e.g., free software that inherently promotes non-free, and nobody can or is willing to patch it) and I think you've got 'em.
<nckx>Being unmaintained with known or too probable security issues is another.
<nckx>So again your point of 'broken' but just broader.
<antipode>muradm: IIUC, the ci always builds _all_ the packages, it doesn't look for sha256 or such. However, it almost always turns out that some packages (here I'm including the dependencies, phases, etc as well in what makes a package a package) of these have been built already, so for many there is nothing to do.
<nckx>Yah. It 'checks' the SHA-256 in the sense that the SHA-256 is one of the ingredients (antipode's examples) that determine the store hash prefix, and the store file name being already valid or not is what determines whether it will need to be built. So yes, kind of, but not explicitly AFAIK.
<jab>morning guix! apparently openBSD's pledge has been ported to linux...
<jab>I found the best way for me to learn was to upload videos of me coding and trying to explain what I was doing...
<fiesh>nckx: how would shell native code be _slower_ than seq? it's almost certainly going to be faster
<nckx>By its nature. Have fun demonstrating the contrary for anything but deliberately low iteration counts.
<fiesh>well I just ran a test of 100000 iterations that seemed to prove my point
<fiesh>besides, a shell-native iteration may allow the shell to represent the variable not as a text representation but as an actual integer (not sure if it does, but theoretically that's possible), something that calling seq could never do
<oriansj>well if the matter of a few seconds matter, using shell or seq is the wrong approach
<fiesh>I successfully proved that a shell-native for-loop severely outperforms seq when using a shell like zsh -- I don't even know how to write a for-loop in bash and don't care. I agree that we should consider this settled
<fiesh>tewi: so then we have no application at all for seq?
<tewi>if it's so useless to you then dike it out or something
<tewi>like i don't use most of the stuff in coreutils either
<fiesh>I really hardly ever use it and could do without, indeed, but I thought there might be a stronger point in its favor
<oriansj>fiesh: tools exist, how useful they are depends more on the user more than anything else
<fiesh>oriansj: true, but for most tools I can come up with a potential use case pretty quickly, even if it's one that probably will never be relevant to me
<tewi>isn't this more of a talk for ##linux or whatever the channel is anyway
<oriansj>for some people guile is life, others just needed for their package manager and others something that should never be installed on their computer. No judgement but people like what they like and there is no talking them into something different.
<oriansj>so don't worry about what use a tool might have, think more of what your needs and wants are and find the things which help address those and ignore the rest until you need them.
<oriansj>Or if you really like playing librarian write up what you found and what the creator described as the functionality with some basic tags and move on
<tewi>it can also do decimals, which is not something the $(( )) can do
<oriansj>even if you only spent a single day per tool from the day you were born to the day you die (at the ripe old age of 190) you would still not have documented all of the tools out there at this very second. (Most just exist with a few thousand users and that is ok)
<tewi>alright, i just checked with dash and it doesnt accept decimals at all
*nckx is returnal. Speaking of integer operations, I was annoyed at not remembering POSIX arithmetic (being corrupted by Bash), so I persisted, and… uhm… let's forget about seq forever; arithmetic absolutely murders dash:
<oriansj>then the languages need to express the different structs differently to the programmers so that they can choose the previous versions as well otherwise they are breaking working code with every update
<fiesh>but for the pledge call's string value, a simple bitmask would have sufficed
<oriansj>or have to provide varargs implementation that 'guesses' the version or requires the user to pass which version to use
<oriansj>fiesh: it is never about a single release of a single feature, it is about all of the tooling around it and the users of it
<fiesh>are you even talking about the string field of pledge()?
<oriansj>fiesh: yes as a class of engineering problems long term
<fiesh>oriansj: but I don't see how a string is any better than a bitfield there, irrespective of any api versioning or whatever -- but I guess it's off topic anyway
<orneb>Hello! The guix-translated-texinfo.drv build is failing . "build of /gnu/store/nzl29...-guix-translated-texinfo.drv failed" The build log shows: "Your input po file ./guix-manual.de.po seems outdated (The amount of entries differ between files: 12447 is not 11997). Please consider running po4a-updatepo to refresh it." Then cannot build guix-manual-
<orneb>Then cannot build guix-manual.drv: 1 dependencies couldn't be built.
<oriansj>fiesh: a string allows arbitrary content, a bitfield can't by definition. So if you want the ability to support arbitrary changes on input without doing versioning, a string is a better solution to bitfields.
<fiesh>oriansj: this theoretical problem will arise if you ever need more than 64 flags, including legacy ones... something that is possible but quite unlikely
<orneb>The guix gc command did the trick for the build error.
<orneb>Maybe it's bad habit to add and remove packages in my config file and then run guix pull and system reconfigure without running the GC every now and then?
<oriansj>fiesh: in something like pledge, you would have 1 (or more) flag(s) for each system call you support, so the number will be much larger than 64 flags. Fortunely one would not need to test every combination...
<oriansj>orneb: depends entirely on the cause of the error. If it is disk exhustion, then yes collecting unneed binaries would solve it but if the problem is something else guix gc is unlikely to do magic
<oriansj>fiesh: for example the open syscall enable/disable flag, if enabled are writes allowed (y/n), how about reads (y/n), what append only (y/n) etc
<vagrantc>e.g. what do you need to do other than read the files
<tewi>rm -rf all of it afterwards, running the garbage collector takes a while
<vagrantc>you can specify which paths you want to garbage collect
<tewi>i thought maybe guix environment would work, but i guess there's no escaping the gc here
<vagrantc>yeah, the model is pretty much build stuff, install stuff, do stuff, leave it in the store until you need or want to gc
<PotentialUser-21>Hello. I wonder why docker images created with guix pack are so much bigger than docker images build via Dockerfile. Packages inside are the same. The difference in my special case is 1.5 GB vs 2.5 GB. That seems a little too much
<vagrantc>does one method include more of the dependency graph than the other?
<PotentialUser-21>Dockerfile is not produced by me, but a colleague. But the base image is called python-3.10.4. My docker image is build with just python3.9.9 and all the pip package he also uses. Nothing more. No vim, no coreutils etc. Thats why I assumed to have a smaller footprint
<ncbfg36>How do I declare kernel options in config.scm such that I would set under GRUB_CMDLINE_LINUX in /etc/default/grub? The docs on bootloader configuration show how to pass kernel options for specific menu entries but not for all menu entries (such as default and previous generations)
<nckx>Putting random fonts into ~/.local/share/fonts is an underdocumented addiction.
<tewi>if you don't supply a file to xinit it will read ~/.xinitrc or something, so it should be fine. i wouldnt know though, when i write a package it doesnt work even when it finally builds without errors
<podiki[m]>nckx: thanks for finding the bug number, color me surprised to realize I was reading my own response at one point
<nckx>It's happened to me more often than I'd admit. ‘Hey, this feller has a point’, but also ‘pff, I used to think that, but—oh.’
<podiki[m]>probably want a "complete" package for anyone that wants it, and then inherit to make individual ones, at least for the most popular fonts
<podiki[m]>when I used to write research papers, I would read an older one, come up with some objection, and see it answered just after having the thought. i guess my thinking remains pretty similar over the years :-P