<florhizome[m]>It’s ok if those are more community channels, guix doesn’t need to officially run them I think but for the one on matrix, we would need contact to the admin anyways to change the description and use it constructively and if guix ppl hit up matrix.org it could help.
<M6piz7wk[m]>i think guix can still use the deployment we set up with ian?
<vdv>mhh guix weather show that no docker binary is avaiable?
<florhizome[m]><M6piz7wk[m]> "florhizome: elaborate guix ppl..." <- Right now the matrix channel does not elaborate that it is not official. So it’s misleading. A person affiliated with guix could basically say „hey this is actually not our channel but the admin is unreachable to make the needed changes, can you help us out here?“ (contacting the admin, maybe appointing others)
<florhizome[m]>which probably would help putting any use into that channel in due time. Or whatever would be the proposed usecase.
<M6piz7wk[m]>ye i originally though that it was official and was very confused there O.o
<florhizome[m]>If it’s just community ppl probably doesn’t have that much power.
<jgart>apteryx, what's left to do for the new build system?
<jgart>will it use python-pypa-build to do the work of building?
<apteryx>I think the pep 517 par is easy, but what may be tricky or at least will need a lot of testing is preserving the current behavior (I think python-pypa-build is able to build setup.py based (legacy) packages -- not sure anymore)
<apteryx>also setuptools has support for pep 517 but it uses is own setup.cfg file rather than project.toml; it feels as things are slowly coming together but it takes time
<jgart>by "follow their practices" I mean support both build practices so that we can continue packaging and then refactor later. Maybe the system can be designed with that flexibility in mind. I realize Lars had proposed something so he might be working on it more: https://issues.guix.gnu.org/46848
<M6piz7wk[m]>+1 to GNUCaptcha.. it's very difficult to make a libre captcha and it's critical for many services
<PurpleSym>jgart, apteryx: Yes, I’m still actively working on a PEP 517-compatible `python-build-system`. I’ve got rid of the pypa-build dependency, which complicates bootstrapping alot. Three lines of Python code essentially do the same. Now there’s just setuptools left as a hard dependency.
<brendyn>So I was thinking: Guix shell/environment, after it has launched the command, it doesn't have anything it needs to do... besides maintain a gc-root for the env, however that works. When I run guix shell emacs, guile is still using 211MB RSS memory, just for the sake of launching bash. It seems there is an opportunity here to save memory somehow, perhaps by letting the running guix die when it launches or somehow allowing it to garbage
<brendyn>I use a webinterface that takes about a minute to load and is very laggy just to send emails to guix, before using git send-email to follow up. maybe one of these years ill get some email solution setup, but its really just too much of a pain
<florhizome[m]>kind of thinking abt making a repo for dotfiles/experiments on codeberg for the moment. doesn’t make much sense for me to selfhost sth just for the few dotfiles. people seem to flock to codeberg but I don’t even like it that much and it’s both Gitta under the hood, I think?
<rekado_>still waiting or the GC lock on ci.guix.gnu.org
<pinoaffe>I saw that `emacs-org-contacts' was recently added, even though the same emacs library is also included in `org-contrib' - is this intentional?
<cbaines>this seems very odd, but does this command only work on x86_64-linux with QEMU? guix time-machine --commit=75dabac633bb9a33efbebf859f8aa4bb3b9582b2 -- build --system=aarch64-linux -e "(@ (gnu packages bootstrap) %bootstrap-guile)"
<cbaines>when trying it on a native aarch64-linux system, I get various No such file or directory errors
<zamfofex>Yeah, use ‘@’ for specifications (e.g. on the command line), but ‘-’ for variable names in Scheme code! (Though they might not necessarily map one‐to‐one.)
<vivien>Note that for meson, (specification->package "meson") will give you a more recent version than the meson variable
<vivien>This is because a lot of stuff depends on meson the variable, and if we update it we will need to rebuild too many packages. So, it is kept frozen until the core-updates-frozen is merged into master
<pkal>What is the intent behind pinning emacs-next to the specific commit it has been pinned to?
<vivien>You can programmatically check the package version of a program with (package-version <your package>), and decide which one to use based on the result.
*M6piz7wk[m] found a cooler replacement for tldrpages
<zamfofex>Sometimes I wonder whether it’d make sense to include some procedure to generate input key/value pairs from package names, so that you could just write e.g. ‘(package-inputs foo bar baz)’ instead of ‘`(("foo" ,foo) ("bar" ,bar) ("baz" ,baz))’ and whatnot in the inputs field in package definitions.
<abrenon>I thought that feature had been already added : S
<robin>zamfofex, me too, i suspect it just hasn't annoyed anyone enough yet ;) (and there are a probably cases where one would want to customize the input name, though ofc your idea needn't conflict with that)
<robin>ty jackhill, i saw some smlnj chatter but wasn't following it closely
<robin>i'll see if my 2018 package still works, not that it's fully bootstrapped from source (i doubt any new package would be either, though i'd be happy to be wrong; i suspect that would require something like a cmucl->sbcl level effort)
<robin>(i.e., afair it didn't have ancient magic lurked in image files as with, say, squeak, but only smlnj could compile smlnj last time i checked, it'd probably take a month+ to fix that, porting the compilation manager to another sml etc.)
<ngz>zamfofex: guix shell is more capable than guix environment. The main difference, however is the reverse logic of ad-hoc and development packages. In "guix environment" you need to specify all ad-hoc packages, since all packages by default are for development. In "guix shell", all packages are ad-hoc. You need to tag specifically development ones.
<zamfofex>ngz: Ah, that’s fair enough! I always found it kinda annoying to have to specify ‘--ad-hoc’ when I want to include a specific package in the environment.
<M6piz7wk[m]>jpoiret: just overeacting over the lack of double quotes for variables
<zamfofex>M6piz7wk[m]: The value of ‘$HOME’ is well‐known, so you don’t need to worry about it potentially containing whitespace when being expanded. It’s fine if you include the quotes for consistency of practice, but I don’t think it can cause problems. Though honestly I wonder why it was used excplicitly instead of ‘~’.
<singpolyma>zamfofex: just to reinforce what was already said https://guix.gnu.org/manual is never the one you want and is just published for historical reasons. Look for one with "develop" in the URL since that describes the version of guix actually in use
<vivien>To me, the malpractice is to put random stuff in your $HOME
<ngz>singpolyma: or, arguably better, use info to browse up-to-date documentation from the comfort of, e.g., Emacs.
<robin>jpoiret, hm i think my patch fixes that, i'll dig it up and post it later (the new patch looks quite a lot cleaner though, mine was largely just "translating" debian's packaging)
<zamfofex>Would it make sense to show a warning when using ‘guix environment’?
<singpolyma>ngz: I can't imagine most people learning to use info and/or emacs just to get answers to their questions, though.
<zamfofex>I wish ‘less’ could allow some form of interactivity. Sometimes I have wished to create a TUI program that wllowed scrolling to be used, but without having to implement it manually, and ‘less’ feels perfect, except that it doesn’t allow changes to be applied to what it displays.
<ngz>This is only a data point, but info is accessible. It boasts a nice tutorial.
<pkal>zamfofex: what would you want to change in the text being displayed and how?
<singpolyma>rekado_: I've always found the web browser and acceptable info browser, since latest info->HTML is usually published. It's in a bit of a... specific style, especially if you try the weird "one node per page" mode navigation can be funny, but it's usable enough
<zamfofex>pkal: E.g. for ‘info’, it’d make sense if it were possible to allow the user to navigate with links. The way I’d do it would be to keep interpreting escape sequences, while still allowing the user to scroll e.g. to the end of the current document.
<civodul>singpolyma: though it lacks indexing, search, easy navigation, etc.
<civodul>i think "info", even the standalone info, is easier and more convenient to use than "man"
<singpolyma>civodul: if you use the "all one one page" HTML it has both search and TOC navigation
<zamfofex>I think the problem with ‘info’ is that it’s divisive. It introduces a completely different model for navigating documentation than people are used to, and not everyone is willing to learn it.
<pkal>zamfofex: TUI command? But yea, since pipes are uni-directional you would probably have to do something else.
<zamfofex>By “TUI command”, I mean “the command of a TUI program”.
<singpolyma>zamfofex: IIRC info displays one "node" at a time similar to the one-node-per-page HTML version. This would be ok if never were well sized, but they are often a sentence or two
<zamfofex>singpolyma: I think it might not matter that much if you can search the entire document transparently.
<singpolyma>zamfofex: right, that's why "all on one page" works so well, easy to search the whole thing
<ngz>vivien: I concur. Org should become the default format for all GNU documentation ;)
<singpolyma>ngz, vivien: I don't mind org, and love org mode, but I fear it suffers the same problem as a lot of this stuff: similar things have gained such a huge mindshare that the format feels "weird" to most who see it
<singpolyma>Like, why are * for titles when * should "clearly" be for list? Of course it doesn't matter what you pick, but so may formats use * for list now that it feels "normal"
<singpolyma>What I'd love is the power of org mode on a data model instead of a raw format, but that sounds like a lot of my life...
<rekado_>singpolyma: what do you think of “yelp info:guix”?
<rekado_>civodul: I’m still waiting for the GC lock on ci.guix.gnu.org. Should it really take so long?
<singpolyma>rekado_: not sure, I will have to look into that
<rekado_>I think it’s not particularly pretty, but a) it can be visited in the default Gnome documentation viewer and b) enables browsing and searching the documentation without Emacs or a terminal.
<vivien>Is webkitgtk still failing on i686-linux? I’m emulating this architecture, and building webkitgtk yields "SSE2 support is required to compile WebKit"
<rekado_>civodul: the GC must have just been stopped. Builds are finally continuing.
<robin>i think html5 has (most of) what'd be needed for decent info browsing, but browsers don't implement things like the 123... shortcuts...
<robin>vivien, oof, you're right about yelp info:guix
<robin>er, s/guix/guile/, but they're pretty similar
<civodul>that probably made sense back in the day, but nowadays it'd be useful to render things live
<robin>there's also the (minor?) problem that traditionally both page-per-node and single-document manuals are published online, so nothing has a canonical url
<robin>i'm a bit skeptical that page-per-node is useful anymore, although it's probably good to have as a display option
<zamfofex>It is a relevant problem, I think. I prefer looking at the single‐page manuals, but people share links to the multipage variant. I also feel compelled to do the same. Also, for larger documents (such as the HTML spec), it takes quite a long time to download the entire page, so I tend to prefer to use the multipage variant then. (Not that the HTML spec is particularly relevant to ‘info’.)
<robin>it's fun to use ITS INFO and see that we're using, essentially, a hypertext system that predated the WWW by many years :) (iirc the texinfo markup itself is inspired by scribe)
<robin>yeah, i don't know of many really huge info manuals except maybe emacs's, maybe glibc's
<singpolyma>zamfofex: if you had it already downloaded that problem might go away, though browser rendering of off screen elements isn't 100% free
<robin>i'd be interested in getting 'info' reader features in a browser-friendly fashion, maybe defining an info 'profile' of html5 for things like node relationships and indices, and a JS polyfill for browsers that don't support it well
<civodul>robin: i always use page-per-node; guix.html is big enough that if feels slow to load
<robin>yeah, that's difficult to fix without depending on js (if only html had native transclusion beyond iframes...)
<robin>i'd have to poke around the current state of html5 to see if there are any plausible workarounds (e.g., if following a link to a section, load that first) but it's a bit doubtful many browsers would want to add special support for that kind of behavior, although it'd be useful for big documents (like the html5 spec ;)) in general
<vivien>Oh no, I can’t switch to core-updates-frozen, orbit2 (a dependency for libreoffice) fails :(
<vivien>gcc: error: libname-server-2.a: No such file or directory
<robin>looks unlikely to succeed this time around ("For late comers: there appears to be no path forward on discussing implementation details because the editors have no interest in such a feature to begin with.")
<robin>the main issue would really be working reasonably well without requiring JS
<singpolyma>What's wrong with requiring JS? It would be libre JS
<robin>i have some experience with whatwg but much more on the JS side than HTML
<singpolyma>Half the web browsers are written in JS these days
<singpolyma>I'm curious how you see HTML inclusions would not complicate the build process in the same way?
<robin>singpolyma, nothing necessarily wrong, but i'd guess a higher-than-average fraction of gnu users don't use JS (perhaps especially on lower-end computers like the mnt reform), that's completely a guess though. perhaps it'd be enough to just work properly (if not necessarily quite as efficiently) without JS
<singpolyma>Well, if you do it as a browser extension I think most js-disabling still keeps the js in extensions enabled?
<zamfofex>singpolyma: I guess they would. Honestly, I feel like it’d be enough to have almost seamless iframes that have their intrinsic sizes determined by their content.
<jpoiret>civodul: disregard that, my local commits are of course not signed :)
<civodul>it could be that musl-nscd listens to the same socket as glibc's but speaks a different protocol
<civodul>jpoiret: then you can --disable-authentication (at your own risks :-))
<civodul>vivien: believe it or not, i'm still building Rust (i've been a few versions already) on my way to build deja-dup
<Olivetree>Ah, I now remember something that might be related: I had to create my own /etc/nsswitch.conf because alpine came with none and nscd complained. Since I know nothing about that file, maybe I did it wrong
<apteryx>Olivetree: I think the key on using Guix on weak machines is to have prebuilt binaries available
<Olivetree>I am using substitutes, yes. Even on my "fast" machine I use them. It's a waste of compute power to not do it except in very select cases. Come on, think about the environment :P
<florhizome[m]>like this "wayfire\.get_variable\(pkgconfig: 'metadatadir'\)"
<Olivetree>But the derivations still need to be built (whatever they are, still didn't have time to read on the subject)
<florhizome[m]>well i'm still baffled how long the step for generating the user profile at the end of pull or other operations soetimes takes and how much tear it has.
<nckx>florhizome[m]: What jpoiret meant is you should write "wayfire\\.get_variable\\(pkgconfig: 'metadatadir'\\)"
<jpoiret>Olivetree: derivations are basically a low-level representation of something that should be built by the daemon. You don't need to build most derivations if they're substituted, but some derivations have to be built locally
<roptat>you might have to look at ci status and select a slightly older (usually only a few commits back from master) that is built for your architecture
<nckx>jpoiret: master isn't that busy, but yes, it's kind of… self-defeating isn't the word, but it can feel a bit silly when you're sitting there building derivations that the build farm will/should have finished by the time you get half way.
<apteryx>there's a channel trick you can do to use only substitutable guix pull, it's documented in the manual
<cbaines>I'm not sure "CI" is great for ARM substitutes at the moment
<cbaines>bordeaux.guix.gnu.org shouldn't be doing too badly though
<cbaines>yeah, that's a URL for Cuirass's API, which won't work for substitute servers not using Cuirass
<roptat>cbaines, so according to guix challenge, 119 elements are identical, 15 different and 12737 are not present on bordeaux ^^'
<GNUHacker>when I do "guix package -u" take many hours, is this right?
<roptat>although it looks like some of them are not substitutable anyway
<cbaines>roptat, I'm not very familiar with guix challenge, what command are you running?
<nckx>GNUHacker: Like, morally? It's not suspicious, although it's hardly average. It simply depends on what needs to be updated, and when it was updated upstream (i.e., if substitutes have been built), and whether you've enabled these substitutes.
<roptat>the input doesn't need to be a package, it can be an origin, or any file-like object
<roptat>mh, maybe there's a better way to find the file name indeed
<roptat>I'm not sure how search-patches is implemented, it finds the file name, but it's passed to the patches field of an origin, which turns that into an input to its own derivation
<roptat>but package don't have such a field, so you need to do some of the work yourself
<roptat>not great, but you can maybe use (current-source-directory) to get the directory of the file you use it from, something like (local-file (string-append (current-source-directory) "/../../my-file.txt"))
<Henk94>I tried that, but without the local_file, possibly this works