<florhizome[m]>There is already one on matrix, i think :D but it's not really running i think^^ <civodul>so i've observed a weird phenomenon: mpv via youtube-dl gets poor bandwidth, much lower than if you play straight from the browser <florhizome[m]><civodul> "if you'd like to give it a..." <- I guess i could. <florhizome[m]>I also wanted to ask for merging a higher meson down to master (i don't think 0.53 , 0.55 and 0.57 are all needed and actually not sufficient already for some newer packages like sway) <rekado>civodul: I see that too. Not only with mpv/youtube-dl, also with Android applications such as Newpipe. <civodul>rekado: ah! for me it started maybe a month ago <civodul>that's a real problem, barely usable <rekado>it’s been like this for a while now; I always just blamed it on my poor wifi. Hadn’t tested with mpv in a while. ***sneek_ is now known as sneek
<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. <florhizome[m]>yeah but they didn’t seem very engaged. Not like it mattered to them. Of course, since its an unofficial channel, actually the channel is not that important <M6piz7wk[m]>Hmm still i would prefer an established matrix space like nixOS has <vdv>would use this because it already attracted people and link it to this irc, so that our admins can talk their too with a bridge.. <vdv>and make it more gnu*ish :) <vdv>connecting the established instead of inventing new :) <vdv>just my 2 cents, gn8 <florhizome[m]>but I think for doing spaces I would even prefer a privately hosted one lik jacobs. Depending how it’s done ;P <kittyblam>eh, matrix is overrated, XMPP does the same job but mostly better imo <kittyblam>IRC is perfect for talking about something like Guix, although perhaps a libre unixporn styled thing would be cool as an XMPP muc <M6piz7wk[m]>> but I think for doing spaces I would even prefer a privately hosted one lik jacobs. Depending how it’s done ;P <M6piz7wk[m]>and the homeserver should be already set up somewhere on FSF's side i helped ian to set it up on fsf.org <podiki[m]>didyou ask if that matrix server wants to be official? <M6piz7wk[m]>also FWIW there is an alternative implementation of matrix homeserver in golang <M6piz7wk[m]>podiki[m]: yes that's what i use in the space i've created <bdju>I use irc, xmpp, and matrix, but I'm pretty happy with guix just being an irc room. Bridging always feels sloppy and then some people will have strangely formatted messages. <bdju>the matrix replies in libera at least look better than what I recall the freenode ones looking like <M6piz7wk[m]>the bridging depends on the implementation from my experience O.o e.g. the matrix to IRC bridge works nice <bdju>they'de quote the whole message but awkwardly truncated and then put the reply on the same line <singpolyma>Yes, I only use IRC via an XMPP bridge. I don't think anyone has ever been able to tell <bdju>singpolyma: are you posting from a phone? <M6piz7wk[m]>mhm bridges are cool lets use them everywhere for everything :p <jgart>Might give us some insights into how to extend the python-build-system <jgart>python3 -m pip wheel --no-deps --use-pep517 --no-clean ... <jgart>If there's some talk on this on the mailing list please do point me in teh right direction. Lars had shared some of the work he was doing on it with me. I'll have to go back and reread that. ***_koolazer is now known as koolazer
***ec_ is now known as ec
<apteryx>jgart: perhaps commit 812a2931de5 on core-updates can be useful <apteryx>I had used python-pypa-build ("python" "-m" "build" "--wheel" "--no-isolation" "."). <jgart>can I send an update to core-updates for jrnl using it? <jgart>or wait for the build-system to be finished? <apteryx>I don't know anyone currently working on it <jgart>jrnl is pretty old in our repos and the latest version only uses pyproject <jgart>great, I'll get working on it <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 <apteryx>that's why it's tempting to punt until they've figured out "the universal" way to build stuff, and every players start adhering to it <jgart>I've seen the setup.cfg files out in the wild <jgart>Could we support both via an optional in the build system? <jgart>Or, we're trying to stay away from implementing two ways <jgart>I guess it depends how long the python world stays in limbo about standardization of this new pep. <jgart>If a year passes and the situation is still the same then it might make sense to follow their practices/lead a bit <apteryx>sure! I didn't mean to discourage you or anyone from tackling it today :-) <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 <jgart>I'd like to arrive at a solution that the guix community will agree on for the python-build-system ***humky_ is now known as humky
<florhizome[m]><M6piz7wk[m]> "> <@florhizom:matrix.org> I..." <- I've seen the Same discussion about Emacs joining gitlab so that's very serious^^ time for GNUcaptcha i guess <M6piz7wk[m]><florhizome[m]> "I've seen the Same discussion..." <- FWIW i would be against gitlab it's UI is annoying and the model is weird x.x <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>collect and unload modules. Opinions? <jgart>I'm planning to self host a smithy soon.. <jgart>maybe once I finish packaging it <M6piz7wk[m]><florhizome[m]> "> <@6piz7wk:tchncs.de> FWIW i..." <- yep lets move guix on that instead of annoying debbugs and cgit~ *M6piz7wk[m] really don't understand why do people even prefer that.. it seems like such a pain to track issues and merge requests in it <PurpleSym>jgart: Note that you’ll probably need updated dependencies too for pypa build. I think it depends on a newer python-pep517 than we have currently. <jgart>how about putting guix on gitile? RIIG <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? <M6piz7wk[m]>and i can make API calls to make build-time configuration that applies bug fixes through making a request to the API <M6piz7wk[m]>brendyn: gitea has cli client that i argue is much nicer to work with <florhizome[m]>I think it’s just important to be able to submit patches the oldschool way via Mail for guix etc... and most forges seem to make that actually hard? <florhizome[m]>think that was another of the points in the emacs/gitlab controversy *M6piz7wk[m] hates the CI on sourcehut and doesn't like the UI <jgart>what is the idea behind this snippet: <jgart>(properties `((python2-variant . ,(delay python2-pep517)) <rekado_>since the early morning I see ‘waiting for the big garbage collector lock...’ on ci.guix.gnu.org <M6piz7wk[m]>also the maintainer hates me for asking him if i can host 120GB of source code that requires daily runs of 240 CI/CD jobs worth of 470K CPU cycles <rekado_>jgart: because python2-pep517 should not be evaluated <rekado_>python2-pep517 inherits from python-pep517 <jgart>why should it not be evaluated? <jgart>just trying to understand it <M6piz7wk[m]>florhizome[m]: BY THE POWER OF DEVOPS I SHALL FIX THE WORLD!!! <jgart>I understand what delay does, it returns a promise <M6piz7wk[m]>also pijul is nice.. it's version manager integrated in rustlang that seems way more effficient then git.. but in early alpha <jgart>then, when is force supposed to be called in that context? <jgart>or it never is because it should not be evaluated? <florhizome[m]>like wayland compatibility forks, emacs variants, patched fonts, git repos of new DEs and compositors :D <florhizome[m]>also there is some pretty nice gnu artwork I would like to adopt into a bit more coherent themeing ... <florhizome[m]>patching some of the DE definitions up... but yeah that’s all way beyond my capacities for the moment <civodul>brendyn: the GC root is kinda important :-) <civodul>so we can't just "tail-call" via execve <brendyn>civodul, but i imagine there is a minimal way to preserve that <civodul>when the thing is cached, we could tail-call, because there's already a GC root <brendyn>pmap shows guile still has many guix package modules loaded plus 100+MB unknown memory <civodul>(also we can't tail-call when using --container) <brendyn>also, the tests use all threads even when i had -c 8 <civodul>BTW, most of the mappings pmap shows are read-only, and shared with other processes, so it should be taken with a grain of salt <civodul>(which is not to say that we shouldn't do anything :-)) <civodul>brendyn: re the util-linux bug above, could you email that bug and explain what you get on which commit? <brendyn>I can, but it was a modified branch with kde updates <brendyn>I think i discovered the issue. the test is only disabled for x86-32 <civodul>vivien: i'm testing the deja-dup upgrade but find myself recompiling Rust and whatnot <vivien>civodul, I hope that’s not my fault ^^ <civodul>hmm we're even lacking substitutes for gtk+ <civodul>wild guess: the merge of master in core-updates-frozen in 1c94392a13cbdf87e03a644633eb775bf45694a1 led to Rust rebuilds, and everything depends on Rust on core-updates-frozen <efraim>civodul: it's happened during the last merge too, I'm not exactly sure why though <efraim>I didn't get a chance to track down which package(s) moved from safe-for-master to only-for-core-updates <efraim>my first bet would be python-something or jemalloc <civodul>efraim: i'd say it's some Rust package, no? because librsvg depends on Rust on core-updates, but not on master <civodul>on master you can happily update any Rust package, whereas on core-updates it leads to a big rebuild <civodul>well, not always but probably often enough <efraim>that shouldn't lead to rust being rebuilt though <brendyn>I imagine Rust will only continue to grow so that will be the case more often <jpoiret>let's just hope mrustc goes a long way <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 <vivien>Like cows watching trains cross the fields, I’m waiting for qtwebkit to finish compiling. <jpoiret>pinoaffe: see bug 51499 for the reason <civodul>cbaines: that's a relatively old commit (March 2019); do you know if that was on master? <civodul>here it just successfully downloaded a substitute for /gnu/store/a6960z7v49vqr1ir2h7lxgrzjvkd3zdb-guile-bootstrap-2.0 <civodul>with --check it works as well (i have qemu-binfmt tho) <cbaines>I guess to reproduce the failure, you might need to add --check <civodul>if i "herd stop qemu-binfmt", it fails with "a `aarch64-linux' is required" (not surprisingly) <cbaines>It works for me on x86_64-linux with QEMU <cbaines>It just fails on native aarch64-linux <pinoaffe>jpoiret: oh okay, thanks, that makes sense! <M6piz7wk[m]>i wonder if there is a tldr pages alternative that is not restricted on stupid 5 entries <xelxebar>About a year ago there was discussion about someone working on a file-name->package-name reverse searcher. Did that gain traction? <M6piz7wk[m]>would be cool if i could get a dummed-down version of infopages in info command 🤔 <zamfofex>Can’t you just use plain ‘man’? Like, manpages are not that long, and you can generally query for information you’re looking for fairly easily with ‘/...’ in ‘less’. <vdv>how to select a specific version of a package while installing via config.scm? guix search found 2 or 3 different versions of meson <zamfofex>vdv: I think you need to specify the name of the declaration of that package explicitly. Something like: ‘foo-1.2’ instead of just ‘foo’. <vivien>Do guix edit <package>, and look around for scheme variables of the form <package>-<version> <vivien>But be aware that when a new release happens and support for older versions is deprecated, guix will delete these variables <vivien>Aside from linux-libre-lts, for instance, which should always point to the latest LTS release. <vivien>You can also use (specification->package "package@version"), but it’s the same problem, when this version is dropped, that will make an error. <vdv>ah :) so @ zamfofex, guix install meson@0.57.2 is working indeed instead of "-" :) <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) <sneek>Welcome back robin, you have 1 message! <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.) <M6piz7wk[m]>Is packaing GNU Hello a good exercise to package for guix? <robin>M6piz7wk[m], as a first package? i'd say so, yes (just name it "my-hello" or something to avoid a conflict with the existing package) <vdv>the 'target' field is deprecated, please use 'targets' instead -> any examples how to update this definition? <vdv>the last example of system installation i saw has this deprecated bootloader definition <zamfofex>vdv: Just rename it to ‘targets’ and add that value inside ‘(list ...)’, and it should work. <ngz>M6piz7wk[m]: Is it? I mean, barring the "guix environment" sub-command (which is still supported) <M6piz7wk[m]>i was lead to believe that the pre-env thing is also deprecated? *M6piz7wk[m] goes to watch then <ngz>You may just replace "guix environment guix --ad-hoc ... more packages..." with "guix shell -D guix ... more packages ..." <ngz>zamfofex: The page you mention is from latest release, "guix shell" sub-command was introduced meanwhile. <jpoiret>zamfofex: I can't seem to find the mail, but I think civodul has a patch with name-less package inputs <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. <ngz>zamfofex: it is not the main difference, but the outstanding one when migrating from "guix environment" <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. <ngz>That would only be for their own good ;) <rekado_>the whole GNU system uses info for extensive documentation. <rekado_>perhaps offering a more accessible info browser would be worth the effort. <dstolfa>rekado_++, i find that info is impossible to read without emacs <vivien>I thought gnome yelp could do some of that with an appropriate stylesheet <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 <singpolyma>Well, man isn't built for books like info is, but it is the best at what it does <zamfofex>pkal: Then you could e.g. pipe a TUI command to ‘less’, and it’d allow for the command UI to be scrolled. Of course there’d also need a way to handle input. <civodul>singpolyma: heh yeah, but it's not like what you get in info (i, p, n, g, 1, 2, 3, and similar key bindings), but maybe good enough? <singpolyma>civodul: I've never used info except by accident so I wouldn't know <vivien>Let’s convert everything to org-mode <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 <vivien>Well, yelp info:guile is not pretty <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 <robin>i wonder if that's a yelp issue (bad info stylesheet? assuming it's using webkit or w/e internally) <singpolyma>robin: yeah, if you just want better keybindings an extension or even a greasemonkey script could handle it <civodul>surely we could contribute a better stylesheet :-) <civodul>still, there's the problem that Info is pre-rendered (unlike man/groff) <rekado_>there was a project to provide info reader features as a JS library <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>zamfofex, intriguing, thanks for the link <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 <zamfofex>I think it’s mostly that it imposes a techical burden on people to have JavaScript enabled. It also adds complications to the build process to serve the correct payloads to be loaded by the scripts. <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. <robin>true, that could definitely be an option *apteryx found the solution to build kexec-tools on i686; binutils needed to be built with --enable-64-bit-bfd :-) <singpolyma>zamfofex: oh yeah, the iframe sizing situation is such a silly mess. Someone should just write a spec for how browsers should treat `<object />` in a sane way <robin>but i'm in cloud-cuckoo-land at this point, texinfo doesn't even generate html5 or even particularly 'semantic' html for pre-html5 ;) <singpolyma>I'm sure whatever it generates we can make something work with it, honestly. Good markup is good, but even really bad markup can have automations done to it so long as it's consistent <roptat>we already apply some changes to the generated html <robin>yeah, i'm sure modifying the html output would be relatively simple, especially just to better reflect info's own semantics <roptat>(colored parenthesis and links to function definitions in code fragments) <vivien>parallel make failures are hard to debug :( <vivien>I had a new error with a parallel make, after applying my patch, but I stupidly disarded it and I can’t reproduce it (the new error). <roptat>mh, try again with --check, until you get the error? <vivien>I’ve set an infinite loop to retry :) <vivien>I’m trying with 8 cores, maybe the error is more frequent with a different number of cores <apteryx>vivien: why not simply disabling parallel make if it fails? (and report the issue upstream) <vivien>Upstream is aware, they provided a fix that I included <vivien>But I think there are other issues <vivien>But I can’t reproduce these other issues <Olivetree>So I was isntalling guix on top of alpine in my raspberry pi 4, and lo and behold, I get this: guix pull: error: the group `guixbuild' specified in `build-users-group' does not exist <Olivetree>If I do `sudo -u guixbuilder01 id' I get `uid=999(guixbuilder01) gid=998(guixbuild) groups=34(kvm),998(guixbuild)' <Olivetree>I bet this is from alpine being musl-based or because some assumed tool is not installed. How can I investigate/fix this? <jpoiret>this is a call to libc getgrnam that fails in nix/libstore/build.cc <jpoiret>see Name Service Switch in "(guix) Application Setup" <roptat>maybe alpine doesn't use /etc/passwd, which the glibc uses to determine who users are? <roptat>although maybe there's another way to make glibc and musl <civodul>glibc's getgrnam should fall back to reading /etc/group anyhow <roptat>what I meant is that on android there's not /etc/group nor /etc/passwd, and no NSS, so glibc couldn't find users/groups. I'm wondering if it's the same for musl <jpoiret>is there any way for guix pull to use a local guix checkout (or even just patches) easily? <jpoiret>i'd have to create the "keyring" branch as well and keep it updated with upstream it looks like, so it feels a bit hacky <awb99>what can I do so that guix will auto-mount my usb drives? <civodul>jpoiret: you can always pass --url=file://..., but yeah, the keyring branch has to be available <civodul>awb99: not sure! isn't that supposed to happen on GNOME? <Olivetree>jpoiret: I have musl-nscd installed and running <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 <Olivetree>I guess it should contain the passwd, group, shadow fields as well(?) <Olivetree>Fuck, what kind of packager shipped out software like this without sane defaults? <florhizome[m]>Is there a different in use for Substitute* if it matches multiple expressions (and i want to overwrite them all) <jpoiret>but yeah, passwd and shadow fields (with the same "files" contents) would be sane defaults <roptat>florhizome[m], substitute* already replaces every occurence <vivien>civodul, I can easily believe it, I hope that it does not put you behind too much for your other work <civodul>vivien: that's ok, i'm trying hard not to hack today <civodul>(preparing my PackagingCon talk for tomorrow) <jpoiret>why was there a world rebuild again on core-updates-frozen? <roptat>will the talks be available somewhere later? <Olivetree>jpoiret: Well, la-di-dah, libnss_files.so not found -.- <jpoiret>mhmmm, maybe musl nscd doesn't have a files backend. <Olivetree>since there are no libnss_*.so files in my system, it has no backends at all <dstolfa>civodul: is there a stream somewhere? <civodul>dstolfa: there's YouTube streaming but unfortunately attendance is not gratis <civodul>jpoiret: maybe musl is so bloat-free that it lacks an /etc/group parser? :-) <jpoiret>maybe… i'm kind of worried that glibc's libnss_files.so implementation is well… tied to glibc <florhizome[m]>install_data('annotate.xml', install_dir: wayfire.get_variable(pkgconfig: 'metadatadir')) <jpoiret>the first element of the list is a regex, so you need to escape special characters such as ( and ) <Olivetree>Is there a way to only do guix pull once for all users? It's a lot of computation just to get an updated package list :( <Olivetree>Or maybe I'm seeing things from the wrong perspective <jpoiret>you could theoretically have .config/guix/current link to a central guix that you update separately <Olivetree>My idea is to have one guix user per service running, but doing guix pull for each service is just silly <jpoiret>Olivetree: why would you need guix for those services though? <jpoiret>they could run binaries in the storte without having guix themselves <Olivetree>dependencies. e.g. one needs php, another needs django. I don't want those things exposed to "everyone" <Olivetree>what about services that guix doesn't have packaged? <jpoiret>and you can quite easily write shepherd services for things without too much code <jpoiret>but about services that guix doesn't have packaged, most likely they won't even run properly on guix system <jpoiret>there's an nginx service in guix, and i suppose starting a php server should be pretty simple <roptat>for php, you can even take inspiration from the cat-avatar-service-type :) <Olivetree>I failed to see how the Features link is helpful :/ I was already aware of all that information <roptat>django might be a bit more difficult, because you have to configure them <Olivetree>jpoiret: "they could run binaries ..." <-- if they don't have the store how do I update their dependencies? <jpoiret>you're talking about multiple user on the same system, right? <jpoiret>the guix store is at /gnu/store and is world-readable/executable <jpoiret>for example, many shepherd services in guix do have their own user, and those don't have their own copy of guix <jpoiret>but then, they'd have to be managed by guix system to work that way (that means you'd need to guix reconfigure) to update them <florhizome[m]>I would like something like an systemd -> shepherd Service converter <florhizome[m]>There are many packages that just come with their systemd Service definition <jpoiret>Olivetree: are you running on a foreign distribution? if so, my bad, i thought you were running on guix system <jpoiret>but still, you could set up scripts to run guix store binaries without them having their own guix, by running /home/youruser/.guix-profile/bin/thebinary <jpoiret>that'd need to be readable by your other users though <Olivetree>jpoiret: well, I did start this conversation talking about Guix on Alpine on RasPi4 :P <Olivetree>And it's still doing that same guix pull, maybe guix really isn't for the Pi <jpoiret>florhizome[m]: did you write "\." instead of "\\."? <jpoiret>guix pull is really computation-intensive <Olivetree>Are there plans to make it faster, or have you already reached an optimization point in which you don't think it's worth it anymore? <Olivetree>I mean, installing python and gcc seems excessive to me <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 <nckx>(Hullo #guix o/ but also TTYL #guix o/) <Olivetree>jpoiret: nice explanation, I feel more knowledgeable already :D <jpoiret>you never know about run-time shenanigans that need to be patched ***xgqtd is now known as xgqt
<apteryx>has anyone managed to sign in gitlab with icecat? <apteryx>for me it hangs with a "checking your browser" dialog <roptat>no, it doesn't work for me either <dstolfa>apteryx: no, it has never worked for me :( <apteryx>it's a bit funny that Gitlab has a better GNU ethical repository criteria score than Github despite it failing at basics such as login with GNU Icecat <apteryx>I'll try to make the issue known to Gitlab, if it isn't already <apteryx>I get a 503 on their users/sign_in endpoint <jgart>Should we always prefer PyPi to the github project page when there's no tests in both? <jgart>I packaged it using the github project page instead of PyPi <apteryx>jgart: if there is no test, I prefer PyPI as our updater works best with it. <jgart>Ok that's good to know about the updater <apteryx>there's no technical reason our updaters cannot be made to work with git, but it currently doesn't, probably for the same reason 'guix download' doesn't understand git yet <apteryx>by updater I mean the updater that also update the hash, via './pre-inst-env guix refresh -u some-package' <jgart>just needs a bit of touch up work <apteryx>jgart: OK, neat! I should have a look <jgart>roptat had implemented it in one of the past guix packaging meetups <apteryx>that's going to make 'guix download' much more useful <jgart>I just sent the patch since it was implemented on a server I was hosting for us to pair on <apteryx>by the way, were you able to try the jami rendezvous point? <jgart>I tried jami the other day on void <apteryx>in a conference setting (rendezvous) point? <jgart>I haven't tried rendezvous iirc <jgart>nope, just adding their jami id and calling <jgart>Is anyone working on a jami update? <apteryx>OK! (I don't think a new release happened yet -- just nightlies) <jgart>Should we update to a new nightly? <attila_lendvai>can someone point me to a working libvirt/virt-manager setup? i get "GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Action org.libvirt.unix.manage is not registered" <jgart>We're using nightlies currently, right? <podiki[m]>attila_lendvai: I haven't used libvirt on guix, but that sounds like a general dbus problem; correct folders in XDG_DATA_DIRS and maybe a relogin/restart? <podiki[m]>there is some issues sometimes with dbus and different profiles, if you have that not in your main user or system profile <attila_lendvai>podiki[m], thanks, i'll try a restart later. iirc, i just logged out and back in <podiki[m]>probably especially if you are just in a WM like me, have to do a few things manually (dbus-run-session in my case) <podiki[m]>I wonder if this is something guix home can smooth over.... <attila_lendvai>my highlevel goal is to run tails in a vm. assuming that using virt-manager is the easiest <apteryx>podiki[m]: I doubt so (due to security considerations); but we should document it <podiki[m]>perhaps more related to having profiles as more first class citizens, as came up in the devel mailing list recently <Olivetree>the_tubular: going to have some in the upcoming weeks with a Raspberrypi <Olivetree>Ah, but not GuixSD, maybe that's what you were expecting <Olivetree>Linux libre kernel won't support wifi drivers, so I don't want to go the GuixSD way <nckx>Hullo again properly Guix! (& in particular drakonis & florhizome[m]) <roptat>the_tubular, I have the guix system on an arm board <nckx>apteryx: Is your failure to log into GitLab due to the FartCloud or have they thrown up a new obstacle since I last tried? <roptat>it's armhf, which doesn't get substitutes from the build farms at the moment, so it's a bit tight *nckx worked in a town called Lisp today, apropos of absolutely nothing. <roptat>(in terms of memory, I have 2GB, and it's not always enough for guix pull) <apteryx>nckx: I've had that issue with Gitlab for... years? <roptat>aarch64 shouldn't have that issue <apteryx>I just now decided to take action ;-) <Olivetree>the_tubular: if you are going the RaspberryPi way, I can tell you that running guix pull on a clean system took well over 1h *with substitutes*. I have the 8GB one <nckx>apteryx: Thank you for doing so! I have to admit that I didn't file a bug at all… <roptat>the_tubular, other than that, no issues on my end; I just had to figure out which kernel modules to add to the initramfs <jpoiret>guix pull still has to build guix locally <Olivetree>others would be more knowledgeable of that, but some derivations must be built locally anyway <roptat>for guix pull, all the expensive derivations can be substituted <nckx>You're not wrong, but the vast majority of ‘guix pull’ should substitutable. Of course that goes out of the window if someone pushed to master briefly before you pull. <nckx>Mh, that was of course meant to follow Olivetree's. <jpoiret>but isn't that what happens most of the time? <roptat>if I had substitutes, it would take ~5 minutes, mainly wasted in "computed guix derivations" <apteryx>jpoiret: no, guix itself is substitutable <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 <roptat>cbaines, really? mh, maybe I haven't enabled it ^^' <roptat>there's no ci page on bordeaux though <cbaines>(probably because I don't know what a ci page is..., someone is welcome to add one though)( <cbaines>I would like to add a fancy web UI at some point, but it's quite low down the list of priorities <roptat>that's ok, I need to challenge bordeaux, see if it has some interesting packages for me <cbaines>please do, it has ~79% of packages available for aarch64-linux and ~68% for armhf-linux, so it should help <roptat>cbaines, I can't use the trick to get the latest commit that has been built :/ <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. <bavier[m]>any hints for debugging a new shepherd service that seems to cause boot to hang? <nckx>GNUHacker: For example (not saying this happened), if something touches Rust, you'll have to bootstrap it and that will take many hours. ***dragestil_ is now known as dragestil
***aweinsto1k is now known as aweinstock
<cbaines>hmm, I see a bunch of "could not challenge ... no substitues" messages, but they mostly seem to be derivations <nckx>GNUHacker: Yes. My answer assumes that your Guix is building something during these hours. If it's not, that's weird. <Henk94>Hello, I have a beginner question, any chance of asking about a hurdle I hit when trying to build a package definition? <Henk94>how can I install a text file to my derivation that is actually stored in the root of my PACKAGE_PATH? <vdv>@ArneBab any possibility to convert scheme code to wisp via a compiler or a simple script? :/ <lilyp>vdv: you could do a pretty boring "pretty-printer" that simply omits brackets and indents per level <lilyp>note that this wouldn't really be beautiful wisp per se though <vdv>true.. but maybe someone already had it done.. D: <vdv>anyone has a raspberry pi guix config for me? <lilyp>wisp is pretty idiosyncratic in some respects, so writing a linter for it is pretty much impossible <lilyp>when do you use the colon, when the dot etc. <roptat>Henk94, I think you want to use an additional phase to install that file <Henk94>Hi! Thanks, I'm just trying to find the file somehow, now looking in gnu packages with something like find-auxiliary-file <roptat>do you want to create the file, or is it an existing file you want to move to the output path? <Henk94>I just have a file in the root of my GUIX_PACKAGE_PATH <roptat>ah, it's not part of the package source code then <roptat>so it can't be referenced from the derivation, unless you make it an input <Henk94>I just wondered how something like search-patches did that <roptat>you could add it to your inputs: (inputs `(("my-file" ,(local-file "my-file.txt")) ...)) <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 <roptat>ah but you were right about search-auxiliary-file <roptat>so maybe (local-file (search-auxiliary-file "my-file.txt")) would work <roptat>ah no, it would need to be in <channel>/gnu/packages/aux-files/ <roptat>well, if you look at (gnu packages) you'll see how you can implement a similar function with search-path <roptat>(yes I'm learning at the same time :p) <Henk94>roptat thanks a whole lot for your great hints <ArneBab>vdv: from scheme to wisp there is nothing (except that you could try sweeten from the readable lisp project) ***avoidr_ is now known as avoidr
<ArneBab>vdv: but you can always prefix any top-level scheme-expression wish ". " (dot space) to make it valid wisp. <ArneBab>vdv: that’s what I do if I need to borrow some scheme code. <Henk94>roptat thanks again, I'm not going to solve this now, but probably will later <vdv>@ArneBab how to do a semiquote parens `( "blabla" "blabal") like this with wisp? <ArneBab>vdv: you tag the line as semiquote-line :-) <vivien>Back on core-updates-frozen :) I missed my round-cornered GNOME! <podiki[m]>welcome back :) I enjoy the newer mesa especially (yay better picom transparency) <vivien>I have to test it more, but my graphics card seems to be better supported, I don’t jump to 50% CPU usage just to play a video. <vivien>I don’t know how much of that is factual, I’ll have to test it more ^^ <podiki[m]>the gtk+ on i686 is one thing missing for me (for wine), and I tried to sort out some python package breakage but ran into some conflicting versions <vivien>Although, the red filter on screen at night isn’t supported yet. <civodul>vivien: the damn thing is still building some Rust version! <civodul>and that's with the reduced Rust bootstrap that apteryx implemented (i think?) <vivien>I’m not sure, but I think each rust version is compiled twice (stage0 and stage1) three times (for src, bin and doc outputs) <vivien>I’m trying to fix gnome-tweaks right now, it wants libhandy 1 and is given libhandy 0.0 <podiki[m]>reduced Rust is just on -batched-changes I think? (still) <podiki[m]>vivien: red filter may be because of now being on wayland? (I don't use Gnome) <ngz>There's a wayland specific red-filter in Guix <vivien>It’s not really a blocker, but I’ll try to know how that wayland thing works <ngz>It's called gammastep, IIRC. <civodul>podiki[m]: oh -batched-changes is still a thing? <podiki[m]>I believe so, but with core-updates-frozen getting lots of rebuilds anyway, perhaps it is due for a merge? <civodul>i thought we'd have the branch merged in master end of August... that's 2 months ago <podiki[m]>-frozen has master as of a few days ago I believe, but not sure if -batched-changes kept up with master as well <podiki[m]>perhaps the pixbuf and svg is the biggest problem? (at least that's one I know about affecting me, via gtk+-3 for i686) <civodul>i'm busy the next few days but i'll try to catch up by the end of the week <podiki[m]>at least the CI is building -batched-changes, it didn't like it for a long while <podiki[m]>oh, I think -batched-changes has a somewhat up to date merge from master, since I see some packages with current versions (patched in the last few weeks at least) <civodul>vivien: "successfully built /gnu/store/kdhw5yhhm3gmnqadkq2f03l7awy8p24n-deja-dup-42.8.drv" \o/ <vivien>I’ve spent the day compiling my system and home for core-updates-frozen 
