IRC channel logs

2022-07-28.log

back to list of logs

<jackhill>hmm, debian has a separate gvfs-bin package. Our gvfs package has nothing in /bin. I wonder if we're missing a :bin output?
<apteryx>shocking: (delete 'check) ;)
<jackhill>ah, the description for debian's gvfs-bin package is "userspace virtual filesystem - deprecated command-line tools," so I guess they're not recommended, but what is their replacement?
<jackhill>ahha! the replacement is gio from glib:bin. I have a vague recollection of "learning" this before. Maybe I'll really learn it this time :)
<oriansj>jackhill: I suggest keeping found things found as a book to help
<raghavgururajan>Did CI broke? The last evaluation in master is for a older commit.
<antipode>I noticed it being broken on the 24th
<antipode>(the antiox jobset didn't get new evaluation)
<jackhill>oriansj: good suggestion! Do you maintain an index of your found things?
<oriansj>jackhill: I leverage emacs org-mode quite heavily
<jackhill>ah, of course. I was immagining a physical journal
<oriansj>jackhill: only for the minimal subset needed to be known to bootstrap the world *again*
<jackhill>heheh :)
<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>hello guix
<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.
<SeerLite[m]>Yeah, found it in ~/.cache/guix/checkouts
<SeerLite[m]>It didn't solve my issue though, looks like I still have the problem even when building from scratch
***califax_ is now known as califax
<SeerLite[m]>AFAIK Guix uses a Guile library to clone git repos instead of calling the CLI tool, right? If so I have no idea how to debug this, as I don't get the issue with `git clone`
<lilyp>I don't think Guix usually resolves submodules, you have to do that on your own (using #:recursive)
<SeerLite[m]>Oh that's right, though according to (guix)Package Transformations, --with-git-url fetches submodules, so I don't think that's it
<SeerLite[m]> https://paste.debian.net/hidden/5f2a011d/
<SeerLite[m]>That's the error I get when trying that command
<SeerLite[m]>Yet it works just fine with git clone --recurse-submodules
<SeerLite[m]>I think it's a cache/state issue (just trying using a local clone as the repo uri), not sure what though
<SeerLite[m]>s/trying/tried/
<podiki[m]>thanks lilyp and nckx for discussions recently as I polished up the Haxe patches. got it all shiny and submitted the series #56806
<nckx`>Congrats :)
<nckx`>/me -> work
<nckx`>(Did that even work? Who the hell knows or cares. o/ )
<SeerLite[m]>Figured it out, found the right checkout and removed it. Now it works :)
<tewi>hello, would a package definition for https://github.com/altdesktop/i3ipc-glib be accepted into the main guix channel, or not really?
<muradm>tewi: are there are popular/useful tools which use this library?
<tewi>well i wrote the definition because https://github.com/cornerman/i3-easyfocus depends on it, and i was planning to write a package def for that as well
<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?
<muradm>tewi: there is a section in manual
<muradm> https://guix.gnu.org/manual/en/guix.html#Contributing
<muradm>you may find same in info pages localy
<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?
<muradm>tewi: http://ci.guix.gnu.org/search?query=wine64-staging
<muradm>you can check packages at ci.guix.gnu.org
<tewi>so it failed because the dependencies fail to build?
<muradm>seems so
<muradm>looks like samba sources are not available
<muradm> http://ci.guix.gnu.org/build/1112021/log/raw
<muradm>build log why it is failed
<tewi>does it automatically start a new build when the definition changes? or does it look at the sha256 in the package definition?
<muradm>tewi: looks like there is a button to restart specific build, probably managed by maintainers idk )
<tewi>the man with the powa to push a botan
<tewi>muradm: thanks
*nckx is summoned.
<nckx>tewi: No, master nor any other branch is currently gated on CI builds or tests passing. That might happen at one point.
<nckx>Botan poosed.
<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.
<antipode>* some -> most of them
<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> https://justine.lol/pledge/
***wielaard is now known as mjw
<abcdw>hi guix!
<drakonis>ahoy!
<jab>weird question: What's the use case for the seq command?
<nckx>Convenient for-looping, for example.
<fiesh>jab: seq -w is quite nice when you want fixed-size literals... for looping, I just use zsh's for loop normally since I don't see the need for a separate tool
<jab>hmmm.
<nckx>Any answer will likely contain the words ‘more convenient’, so if that bothers you you'll never be satisfied. Yes, you can probably replace any use of seq with more and slower shell code.
<nckx>…so, ‘more convenient/faster’.
<oriansj>or a much more complicated sequence generator that supports arbitrary number sequences; not that Busy Beaver was ever needed in a shell script
<jbv1[m]>hello guix ! Is somebody looking into upgrading the julia package ? I'd like to help.
<jab>jbv1[m]: sounds like a great idea!
<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
<nckx>Bash doesn't.
<fiesh>% time zsh -c 'j=0; for ((i=0; i!=1000000; ++i)) { j=$(($j+$i)) }'
<fiesh>zsh -c 'j=0; for ((i=0; i!=1000000; ++i)) { j=$(($j+$i)) }' 1.61s user 0.00s system 99% cpu 1.606 total
<fiesh>% time bash -c 'j=0; for i in `seq 0 999999`; do j=$(($j+$i)); done'
<fiesh>bash -c 'j=0; for i in `seq 0 999999`; do j=$(($j+$i)); done' 2.53s user 0.06s system 101% cpu 2.559 total
<fiesh>% time zsh -c 'j=0; for i in `seq 0 999999`; do j=$(($j+$i)); done'
<fiesh>zsh -c 'j=0; for i in `seq 0 999999`; do j=$(($j+$i)); done' 1.67s user 0.21s system 104% cpu 1.804 total
<fiesh>so bash is considerably slower, but still the loop performs fastest with a shell-native loop
<tewi>you posted bash once and zsh thrice didnt you
<nckx>Using seq is twice as fast as native shell.
<tewi>time seq 0 999999 > /dev/null = 0.022s
<tewi>for (( i=0; i!=1000000; ++i )); do printf '%d\n' "$i" > /dev/null; done = 22.028s
<nckx>For fairness, you do still need to loop in the seq example :)
<nckx>But even then it's an almost perfect factor of 2 faster for non-trivial values of i.
<fiesh>tewi: great example, here's one that does this even faster: `time /bin/true`
<tewi>well, if you actually just want to print the numbers (like the man page advertises)
<nckx>Hehe.
<tewi>in the first place, i really despise for <var> in $(subshell) loops
<tewi>either use heredoc or pipe
<fiesh>we were explicitly talking about for-loops
<nckx>Anyway, here's the fairest fight I can think of: https://paste.debian.net/plainh/9d5716e8
<nckx>All this to point out that you shouldn't use seq because it's ugly, full stop, ‘performance’ is irrelevant.
<nckx>*You're writing shell* for Baal's sake.
<fiesh>nckx: zsh's native for-loop is significantly faster than that, so my point stands
<nckx>So is C's. Both are equally relevant to why seq exists.
<tewi>if you are going to write zsh you might as well use a better language
<fiesh>bash is slower in general and its awkward loop performs horrible
<drakonis>at this point, replace all shell in guix packages with a guile implementation of shell
<nckx>The fact that you had to switch to a different language than the one under discussion proved my point.
<fiesh>nckx: I always use zsh and there was no talk about "bash" at any point
<fiesh>simply about a "shell" that you conveniently defined to be your shell
<tewi>need FFI for highly hand optimized assembly loops in the shell
<nckx>Anyway… that's the use case for seq.
<fiesh>(you even said "twice as fast as native shell"...)
<nckx>OK bud. Just drop it.
<fiesh>lol
<nckx>I'm not sure what you're trying to prove, but let's consider the matter settled for all code snippets above.
<nckx>I'm with tewi on this.
<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
<tewi>seq is for printing numbers
<tewi>that's all
<tewi>if you fork a shell and then fork again in seq to capture the output in a for loop, then yeah that's a big penalty to performance
<nckx>fiesh: I mean, sure, ipython exists too.
<nckx>Everything can be a shell if you dream big.
<fiesh>two[m]: what's an application for printing numbers?
<fiesh>oops
<fiesh>tewi: ^
<oriansj>tewi: forking is only 381 clock cycles on AMD64 Linux
<nckx>Let's do it more often.
<oriansj>more time is spent converting the ints to strings and back from strings
<fiesh>nckx: please do treat it as settled after considering it so
<nckx>?
<tewi>fiesh: i don't know, you can pipe it to awk and print primes or something
<oriansj>technical problems are never settled just abandoned
<nckx>If you're just here to be pedantic, I'll leave you to it. o/
<fiesh>oriansj: :)
<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>oh right you can pipe it into bc
<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>7000 users of openbsd
<oriansj>tewi: you can do decimals in $(()) but it is just string manipulations
<tewi>i believe the result is truncated, at least that's what i remember
<oriansj>tewi: if you do integer operations, yes
<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:
<nckx> https://paste.debian.net/plainh/7e96311b
<nckx>(‘POSIX arithmetic’ being ‘oh right you can't ++’.)
<oriansj>bash scripting is for small hacks and light glue; the best advice is to pick up a real language if you want to do anything more complex
<fiesh>tewi: wasn't that from 2002 or something? by now it's probably... 6980
<nckx>oriansj: Advice that is roundly ignored.
<oriansj>nckx: amen
<nckx>fiesh: Is there a (humorous?) significance to the exact number I'm missing?
<oriansj>then you do C-c and discover it only stops the processing step and goes straight to deleting the thing that was hard to get...
<tewi>one user dies every year maybe nckx
<nckx>OpenBSDvictims.org
<nckx>oriansj: Being forced to choose between a shell script that doesn't handle signals and a shell script that — oh god — tries to handle signals is hell.
<nckx>I've seen them and lived, but I'm not happy about either.
<fiesh>nckx: the link further up about linux getting openbsd's pledge() call referenced this number as being indicated by Theo at some point
<nckx>Ah, right, thanks.
<nckx>Gotcha.
<fiesh>:-)
<phf-1>Hello! Is `https://bordeaux.guix.gnu.org` down? Because I've this here: https://paste.debian.net/1248625/
<oriansj>nckx: all software is hell, the question is mostly for whom
<nckx>Possibly interesting discussion (I've read less than half, and this *is* HN) if you had the same pledge() reaction I did: https://news.ycombinator.com/item?id=32107872
<nckx>Referring mainly to the links.
<nckx>phf-1: I'm ssh'd into it at this very moment, and it resolves here.
<nckx>That looks like a local (to your machine or ISP) DNS failure to me.
<phf-1>nckx, ok thanks.
<phf-1>Yes.
<nckx>‘Name or service not known’ is not what happens when a server is ill.
<fiesh>heh the first point is the string interface of pledge()... something that I also found bewildering to say the least
<nckx>(right? Not saying it's bad or wrong, just very suprising, and naively ‘anti-BSD’ to me at first glance)
<fiesh>I think it's bad :) (and I used to use OpenBSD and still have a FreeBSD installation...)
<nckx>Heh.
<fiesh>I guess the rationale is that a typo will not be bad since you just have lacking permissions since it's opt-in, not opt-out... but still
<oriansj>well interface versioning is a hard pattern; you have to at the very beginning pass the version number and most people think it is weird to pass 0 or 1 for no reason
<oriansj>{uint64_t version, ...}
<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.
<orneb>After my first installation I run only a couple of guix pull and guix system reconfigure with this config https://paste.debian.net/hidden/9f284466/
<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
<fiesh>oriansj: https://man.openbsd.org/pledge.2 currently has 33 flags, so you need 33 bits
<oriansj>fiesh: key word there "currently"
<orneb>oriansj: indeed the GC didn't do the trick. I thought it was because it was taking longer to complete the build but I'm still getting the error. Maybe some packages that are messing things up.
<oriansj>orneb: well broken builds shouldn't even be recorded as state you could use to do a build with.
<oriansj>fiesh: also if you look pledge allows one to encode which files are the only files they will talk to; can't really do that with a bitmap; a struct maybe but definitely not a bitmap
<tewi>do i understand properly that all guix build will do by itself is check if a package builds successfully? that is it won't leave anything behind after running, unless specified?
<vagrantc>it leaves the build items in /gnu/store and typically a build log in /var/guix/ ...
<vagrantc>so if you then run "guix install ..." with the same package, it does not need to rebuild it
<tewi>is there something i can use for checking if a package definition works properly, where i can specify a directory where everything should be dumped to in case i want to inspect it?
<vagrantc>guix build outputs the directory or files that it produces ...
<vagrantc>(or directories)
<tewi>well yeah, but you just said it dumps stuff into /gnu/store, and that's immutable as far as i understand
<vagrantc>what sort of inspection are you doing?
<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?
<vagrantc>do both actually work? :)
<PotentialUser-21>vagrantc: Should not. Only python pip packages installed inside
<PotentialUser-21>Both work. Yes
<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)
<ncbfg36>I just want to disable SMT
<antipode>ncbfg36: Have a look at the operating-system record
<antipode>(guix)operating-system reference
<antipode>In particular, look at the fourth field documented there.
<antipode>This covers your new system generation, it does not retroactively apply to your previous generations which you seem to ask?
<ncbfg36>anticomputer: oh great thankyou! I must have missed that as I assumed it would be in bootloader configuration
***mark_ is now known as mjw
<apteryx>tigervnc-server provides a etc/pam.d/tigervnc PAM config; is there anything to do at the service level to ensure it gets used?
***Dynom_ is now known as Guest7254
<apteryx>odd, it seems we can't rename a same-origin via file-name
<apteryx>it produces an empty output
<apteryx>ah nevermind
<ft>Is there a large delay when posting to help-guix@gnu.org? Or are first-time posters moderated maybe? I sent something last night, but I don't see it in the archive yet.
<lilyp>probably moderation to keep spammers away
<lilyp>you don't want to read about penis enlargements on your help mailing list
<ft>True. I was suspecting something like that, because of spammer scum. But I thought maybe someone knew. :)
<ft>These penis enlargement people should just create their own mailing list, and interested parties can subscribe. Problem solved. :)
<lilyp>well, the problem is that they keep adding people to their mailing lists who don't want to be on them :)
<ft>Indeed. Thus making the internet a worse place for everyone. :-/
<yuu[m]>can guix seamlessly manage emacs packages without package.el, straight.el, ...? and do it iteratively
<apteryx>yes but you currently need to restart emacs between 'guix install emacs-something'
<apteryx>lilyp: I don't want to read it either on #guix, to be frank
<yuu[m]>apteryx: i see. do you know why is that? can't emacs just reload the paths to find new stuff?
<lilyp>no you don't
<lilyp>reload subdirs and you're good to go
<lilyp>as for why it doesn't do that normally, doing so has lead to breakages in the past, so now we no longer pull the rug under emacs
<lilyp>you need to explicitly reload it
<yuu[m]>lilyp: that's great thanks for info!!!
<nckx>ft: You've been approved as a worthy human bean and will not be subject to future moderation (...on that specific list; unfortunately the setting is per-list).
<ft>nckx: Hehe, much obliged! :)
<orneb>How often do you run guix pull and guix system reconfigure in a week without substitutes?
<vivien>I have a daily unattended-upgrades service (at 6 AM)
<vivien>(but I have substitutes sorry)
<nckx>~Daily.
<shcv[m]>has anyone looked into packaging nerd-fonts for guix?
<apteryx>what would be the equivalent of /etc/X11/Xsession on Guix System?
<apteryx>(it's a binary)
<vagrantc>binary shell script?
<tewi>.xinit or xinitrc-xsession with display manager?
<tewi>/etc/X11/Xsession is a Bourne shell (sh(1)) script which is run when an X Window System session is begun by startx(1) or a display manager such as xdm(1).
<tewi>doesn't sound like a binary
<apteryx>basically I'm trying to know what I should substitute Xsession for here: https://github.com/TigerVNC/tigervnc/blob/master/unix/vncserver/vncserver.in#L440
<apteryx>the script will refuse to run if it's missing
*nckx uses ~/.xsession.
<nckx>Note line 418 though.
<nckx>Have you tried ‘operating’ without it?
<nckx>(Lovingly adjusting said script accordingly.)
<apteryx>seems to be used as part of the launching command (which does something like 'xinit /path/to/Xsession ratpoison -- Xvnc :1'
<apteryx> https://github.com/TigerVNC/tigervnc/blob/master/unix/vncserver/vncserver.in#L235
<podiki[m]>shcv: nerd fonts would be nice, maybe there were some draft patches for them? I do use a few, but for now I just download and put them in a local font folder
<tewi>apteryx: what if you also patched out the $Xsession, from that line
<nckx>shcv[m]: bugs.gnu.org/44575
<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
<nckx>:)
<tewi>this wasn't a joke it was a cry for help
<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
<nckx>Disappointing ‘‘‘src/’’’ directory.
<podiki[m]>or actually, maybe want the patcher nerd fonts use, and be able to just 'nerd-fonts-build' to any font to patch?
<nckx>I don't understand enough about the project to say, but I was just browsing the patched-fonts/ directory thinking something similar.
<nckx>Our standards for font packages have always been pretty lax tho'.
<podiki[m]>it has been a while since I've looked at it, but I think they just run their patcher script that adds glyphs (and more?)
<podiki[m]>otherwise, yeah, we just use the patched fonts already
<podiki[m]>or make an additional "nerd" (ha) output of the existing fonts to incorporate the nerd variant...maybe confusing to find and different origins
<podiki[m]>or actually, that's when you would use the patcher
<podiki[m]>to generate the addtional output