<guixy>Which is better for a service that needs a configurable list of packages (including libraries) the administrator may not need available to all users and may provide a remote terminal interface based on the set environment variables: <guixy>- install the packages to the system profile and load the system profile's search paths to the corresponding shepherd service <guixy>- Install packages to a profile independent of the system and load that profile's search paths to the corresponding shepherd service <guixy>- Don't install the packages, but instead generate a list of search paths for every individual package for the corresponding shepherd service's environment variables <guixy>I'm specifically thinking of Jupyter. <lilyp>I think the Guix way is: "Don't do anything, have the users manage their Jupyter instances". <lilyp>IIRC, there is a project somewhere out there that manages Jupyter notebooks over the web with Guix under the hood. <lilyp>It was at least mentioned some months ago. <singpolyma>If I package a shell script, should I include a shell in my propogated inputs? <robin>singpolyma, probably not; users might want to run the script but have no direct need for the shell in question <singpolyma>Oh, right, shebang line rewrite will do what I want. Duh <robin>(with obvious possible exceptions, like completion info, plugins, ... for a specific shell) <singpolyma>What about utils it uses, though? Like, it will need say grep and curl on path unless I rewrite the script to have store paths everywhere <iskarian>singpolyma, you can also use 'wrap-program' <iskarian>(wherein you would add all those utilities' bin directories to PATH) <singpolyma>iskarian: I see a (wrap-script is that preferred to (wrap-program ? It seems to not quite be working for me, but I'm probably using it wrong <iskarian>Hmm, all I know off the top of my head is wrap-script uses guile <iskarian>whereas the wrap-program wrapper is just a shell script <singpolyma>really since I'm wrapping a shell script could just stuff an export line after the shebang, but why fight the utils that exist, heh <singpolyma>yeah, with wrap-program it seems to work fine. not sure why my wrap-script wasn't working but this is just as good or better ***califax- is now known as califax
<singpolyma>When using go-build-system can I specify which go version to use? <singpolyma>I tried adding a native-input but that didn't seem to change it <Gooberpatrol66>Can anyone provide an explanation for why you cannot install a package if another version of it is propagated from another package? <iskarian>Gooberpatrol66, how would you expect them to coexist in your profile? For example, if both packages contain "bin/foo", then how does Guix know which one to link to in ~/.guix-profile/bin/foo? <Gooberpatrol66>i don't see how the package i want to install already exists in my profile <iskarian>When Guix builds a profile, it links the contents of every package into ~/.guix-profile <iskarian>"<Gooberpatrol66> i certainly can't execute any commands from the package ATM" Huh, *that* is odd though. What is the error you get when you try to install the package? <iskarian>oh, if you're looking for the glib binaries, those are in glib:bin <iskarian>If you run `guix show glib' it will also show which outputs are available <char>Does anyone know what package libwx_gtk3u_xrc-3.0.so.0 is a part of? <vivien>Hi, is there a reason we use guix-specific records for service configurartions instead of GOOPS classes? <vivien>(or records instead of goops classes for packages) <lilyp>records are easier to reason about, plus with Guix' sugar nicer to write as well <vivien>What do you mean by "reason about"? <lilyp>As in "understand the codebase by reading" <vivien>It looks like I asked a sensitive question ^^ <attila_lendvai>i'm badly missing a standalone wiki for guix. a lot of very useful content is sent to be forgotten in the endless noisy flow of guix-devel... *attila_lendvai heads over to guix-devel to search for 'wiki' <cbaines>what content do you think should go on a wiki, and not on the mailing list/bug tracker or documentation? <attila_lendvai>that mail is prett much what i was planning to write up to giux-devel <attila_lendvai>cbaines, but in general: complete, copy-paste ready recepies and descriptions of stuff that anyone can edit, and which is probably too much for the manual. <attila_lendvai>cbaines, and what i'm trying to resolve currently, and there should be a wiki page for: how to have your own guix git clone, with your own branch, and be able to guix pull from it by adding your PGP key to the authorized keys. <attila_lendvai>i have topic branches, and i can set up a channel introduction successfully for an initial commit that adds my key to .guix-authorizations, but when i `git merge this that other mybranch`, then that second commit gets rejected by guix pull. <cbaines>that sounds like a good question for the mailing list, setting out your use case. Then maybe something to document in the manual once it's better understood <attila_lendvai>cbaines, the investment for putting together a patch for the manual, and submitting it, is orders of magnitude more than registering on a wiki, and editing a page. especially for people who don't speak goo english. hence, such a wiki would have a lot more useful content than the manual. <cbaines>putting the opposite spin on that though, the manual is available in multiple languages. A wiki probably wouldn't be <attila_lendvai>cbaines, the wiki would be much more about code snippets than verbose free flowing text. and when something like that grows into the wiki, then it can be imported into the manual, and the wiki edited to point back to the manual. <cbaines>which points towards the general concern, if high quality documentation is the goal, having both a wiki and manual might unnecessarily divide effort <attila_lendvai>cbaines, i strongly disagree. my main argument: a lot of useful content doesn't get published because of the initial fence that needs to be climed wrt submitting a patch for the documentation. <attila_lendvai>cbaines, i know, i've been there. then i searched for something, got back a lot of non-guix-related pages, and started to ignore that wiki. also, there's not much content in in, which might be related to this experience of guix users. <attila_lendvai>i think the number of guix users is reaching a point where the project workflows will need to change if it wants to efficiently accommodate the inflow. a single, public guix-devel mailing list, where anyone can join, or for that matter, the guix-patches list, will soon be congested... and end up being a limiting factor for the adaption. <lilyp>Wikis that are open for everyone to edit without review do cause a significantly larger overhead if you're looking for quality control, though. <lilyp>For the recipe thing, I think the cookbook ought to cover that use case, but may need to be extended with particular instances. <lilyp>As for the rest, I don't particularly think we need to replicate all of ArchWiki :) <attila_lendvai>lilyp, wikipedia is for te general public, and it's full of politically charged topics. a guix wiki won't draw that kind of attention. <lilyp>There's politically charged topics when it comes to free software as well. Emacs vs. vi, what to do with Rust, ... <attila_lendvai>lilyp, the cookbook has the same issue: half a dozen committers who accept changes through a guix-patches mailing list, and expect high standards => a lot of useful code snippets don't get published anywhere <attila_lendvai>lilyp, but do you expect that some people will start arguing about emacs/vi on the guix wiki? maybe i'm being naiive here... <lilyp>In the way that it's currently used, no, but the Wishlist itself is already a target for potentially heated debate. <attila_lendvai>lilyp, i'm not against having authorities who can lock down certain heated entries in the wiki. <attila_lendvai>i'm more after an advertised public namespace where anyone can add and read stuff with very little effort. <nckx>Good morning, Guix. I hope you're having a wonderful Saturday. <nckx>Is the LibrePlanet wiki not editable by all? <oriansj>nckx: I think it restricts who is allowed to edit it <brendyn>I'm finding that I'm getting timestamps updated for directories in tar.bz2 files that are build with cmake-build-system. any ides how to address that? <nckx>Hm. GitHub offers wikis to their users (which you seem to be?). <attila_lendvai>nckx, wikis are also covered by the network effect. a wiki advertised by the project is much more useful because of the network effect. <lilyp>Endorsing a Wiki means taking up time to do quality control, however <nckx>I don't think ‘the project’ is interested though. And nobody ever builds this wiki, so it's hard to believe maintainers will magically appear later. <attila_lendvai>nckx, i'm a newcomer. i found the wiki. i searched for something, and realized that it's full of non-guix stuff. then i wrote it down as non-existent. it doesn't have much useful content, and my suggestion is that the two are related. <dhruvin>We figured out attila_lendvai's issue, it was due to the merge commit not getting authenticated due to not all of its parent commits being authenticated. <dhruvin>There was another issue, guix accepts the first-signed-commit even when .guix-authorizations (of that commit) does not mention first-commit-signer's key. Any ideas why does it do that way? Shouldn't it reject the first-signed-commit anyway? *attila_lendvai is already testing a change to reject such first commits <Noisytoot><nckx> Hm. GitHub offers wikis to their users (which you seem to be?). ***john__ is now known as gaqwas
<attila_lendvai>Noisytoot, i think that was just a snarky comment aimed at me, not an actual suggestion <Noisytoot>because it requires reCAPTCHA to sign up and cloudflare JS to sign in <KE0VVT>Noisytoot: crap i just signed up for gitlab <KE0VVT>guess i need to self host gitlab soon <lilyp>KE0VVT: better self-host gitile :) <roptat>although, it's just a repository viewer currently <oriansj>KE0VVT: well that depends on some things. for many developers self-hosting isn't a good plan (it is actually terrible because they stop dealing with security updates after it gets tedious) <Noisytoot>sr.ht, notabug.org, and codeberg.org would probably be C or higher <Noisytoot>codeberg.org is gitea and sr.ht is sourcehut <oriansj>So the use of github or less than idea repos for personal work is fine but once something becomes a seriously useful Free Software tool, consider getting it into savannah <oriansj>notabug.org is also popular these days <dhruvin>sr.ht has guix support for its ci now, just shamelessly self-promoting. <lilyp>Github should be used to send "Stop using Github" repos into arctic ice. <oriansj>perfection is not required of us, only the willingness to make small improvements in a better direction. <oriansj>also none of those details matter if your only interaction with the service is git clone, git pull and git push <oriansj>for example I host stage0, stage0-posix, mescc-tools, M2-Planet and bootstrap-seeds on Github as just a mirror with explicit comments in the README saying the master repo is on savannah <attila_lendvai>is this a reasonable way to refer to the manual from an error message? "commit ~a is signed by an unauthorized key: ~a; see 'Specifying Channel Authorizations' in the manual." <oriansj>I'd put a \n before the See "Specifying Channel.. bit but other than that it seems quite reasonable. (possibly include a link to the manual??) <attila_lendvai>oriansj, as plain text? that will go stale eventually... but i guess it's still better than not having it there to begin with. <oriansj>that or the info command which would go directly to the info page in question <oriansj>(hint info guix 'Specifying Channel Authorizations' ) <oriansj>but that could break if one renames the section in the info manual <attila_lendvai>oriansj, how about this: "commit ~a is signed by an unauthorized \nkey: ~a; See 'info guix \"Specifying Channel Authorizations\"' for more info." <attila_lendvai>i think it's still good enough even when it breaks due to the chapter renaming <oriansj>the for more info. seems repetive and I'd have the See 'info guix... on a seperate line from the key so that it'll be easier to grep and awk. <stikonas>gitea is not too bad in terms of security updates. I have a self-hosted instance and all upgrades are effortless, just part of distro upgrades <oriansj>stikonas: how is it in regards to hardening? SELinux rules and 2 factor auth? <stikonas>it supports 2 factor auth, I didn't use SELinux though <stikonas>the biggest problem though is spam accounts if you keep registration open... <oriansj>one would hope that registration is entirely disabled on self-hosted and kept that way <oriansj>and iptable rules would drop all traffic that isn't whitelisted via known good IP addresses or port knocking. <stikonas>well, depends if you want to let people file issues, create merge requests, etc... Although, there is an option to disable registration but allow to register oauth accounts from other services <stikonas>oh, depends on whether you want to host for just yourself or for other people to clone your software... <oriansj>at that point, it is full time system administration work. <singpolyma>I don't know what the point of hosting for just yourself would be... <stikonas>yeah, for just yourself you can just use git locally... <oriansj>singpolyma: have something you know and trust having a copy of your work that isn't part of your computer which could die or catch fire or... <oriansj>but yeah a plan server with ssh access is sufficient for that. <singpolyma>oriansj: but you don't need a while forge for that. Just get push <oriansj>once you are dealing with bug reports and issue requests, let someone else play system administrator and tell them thank you for putting up with all that crap. <singpolyma>I just hope someday sr.ht offers an official way to have them host but use your own domain name for web bits and mailing list email <oriansj>singpolyma: offer them money and it'll probably happen. <singpolyma>oriansj: oh, drew is interested, just very busy and it's not where near top of the list <singpolyma>Same as all the feature requests my company gets, so I understand :) <oriansj>singpolyma: money allows one to hire other people to do tedious tasks for you <singpolyma>Oh, you mean her their consulting arm to override their internal priorities? *Maybe* <oriansj>singpolyma: I like to think of it as providing what paying customers wanted. <singpolyma>Well, I'm a happily paying customer now, but not at the consulting arm <sneek>raingloom, you have 1 message! <rekado_>attila_lendvai: your impression about the cookbook is wrong. <rekado_>attila_lendvai: in the past we have added articles that were not in the target format <lilyp>raingloom: can you copy another texlive-babel recipe, e.g. texlive-babel-swedish? <oriansj>singpolyma: well those who need changes more desperately tend to be willing to pay more for change or provide more effort. Hence the $20M/year job offers that are currently being throw around these days for US Done AI researchers. <raingloom>lilyp: i can try. texlive packaging is confusing as hell. <lilyp>I read that as US drone AI researchers <attila_lendvai>rekado_, whatever is the case, i have found very useful information and snippets in hidden corners of e.g. git repos published on github of all places, using github's search engine, that was neither in the manual, nor in the cookbook. i think a dedicated wiki would improve the situation. but i'm new here, so i don't have enough credits to argue much. i can only provide impressions. <lilyp>As a rule of thumb, debates of the "why is savannah not github?" variety typically only serve to exhaust. <oriansj>lilyp: well debates in general only serve to exhaust. As they end the second there is working code or never really mattered in the first place. <attila_lendvai>lilyp, note that i'm not promoting github. i'm promoting to have a *dedicated* wiki where searches are covering only guix content. <lilyp>The Guix subpage of libreplanet has a link to literally every existing subpage <oriansj>attila_lendvai: are you thinking of guix having an Arch/gentoo style wiki? <singpolyma>Guix doesn't really use Savannah for anything but git right? The rest is debbugs, mailing list, irc, and static web pages <raingloom>since a user is already guaranteed to have a clone of the Guix repo, maybe we could document how to search that? I have found that useful on multiple occasions. <oriansj>and a copy of the guix documentation via info <singpolyma>Yeah, I often end up reading the code since docs will only tell you how to do "normal" things <oriansj>singpolyma: that sounds like something missing in the docs <KE0VVT>what if there was something like gnome tweaks but for guix settings? that would be cool. <singpolyma>oriansj: maybe? Last night's discovery was that go-build-system can take a #:go argument to choose the go version, for example. <oriansj>KE0VVT: probably a good deal more user friendly than editing scheme <raingloom>lilyp: uhh, i'm getting an SVN error for my modified package. <lilyp>raingloom: IIUC the correct path should be tex/generic/babel-hungarian <lilyp>so perhaps you need to copy babel-german instead <raingloom>lilyp: still getting SVN error, i think the same one that i got when i tried guix import texlive babel-hungarian <raingloom>oh, i think the texlive-ref function is returning the wrong SVN URL ***Guest4840 is now known as chrislck
<chrislck>Is there a cheatsheet available for guix -- eg LHS "sudo apt install python" RHS "guix install python" <lilyp>there's no rosetta stone, but there is a cheatsheet <lilyp>it's confusingly called "refcard", however <raingloom>lilyp: well i built something but it has no files, only directories. <raingloom>the babel-geman package has a bunch of ldf files, the hungarian one i built has nothing :| <raingloom>hmm, maybe the texlive revision guix uses is too old... <raingloom>but hungarian.ldf is there in the build log of the svn checkout. <raingloom>oh, hm, running build --source on them shows a .ins file for german, but none for hungarian <lilyp>there's no hungarian ins file, could it be you're using the wrong directory somewhere? <lilyp>raingloom: it's in source/generic/babel-german <lilyp>the URL is not the only thing with a directory reference <raingloom>there is no corresponding directory under /source/ like there is for german <raingloom>ignore the #:phases part, that's something i just started writing <lilyp>chances are that tex-directory is wrong if you can't get the svn-ref to match either <lilyp>but maybe someone else knows more about texlive-build-system <vivien>Hello, is it just me or is git pull broken? <vivien>I get 'no code for module (guix records)" <raingloom>vivien: i pulled a few hours ago, worked fine then. <raingloom>vivien: is it working now? i'm not sure what would cause that error but i think i've seen it in the past. <vivien>raingloom, it was not guix pull, it was guix system docker-image with a buggy configuration <vivien>I stacked these commands together and forgot about it <ss2>What would be a way to find out from inside Emacs that a package is installe in any given profile of Guix? <raingloom>ss2: idk the emacs-guix equivalent, but guix package --profile=/path/to/profile --list-installed in a shell. i guess you could run that in an emacs shell, or run the underlying Guile function in Geiser. <ss2>I'd like to modify a function in my init, but make it dependable on the presence of a package. <ss2>emacs-guix doesn't seam helpful here. It might be best then to go with guile in geiser. <raingloom>lilyp: i ended up just using copy-build-system :D texlive is a goddamn mess. <raingloom>hopefully what i built actually works. but at least the file doesn't misteriously disappear. <attila_lendvai>oriansj, probably not, but i'm not that familiar with those wikis. i'm looking for a wiki that contains guix-only topics, i.e. not general linux/gnu topics. <attila_lendvai>lilyp, "it's not that big" -- that's actually the very problem i'm tring to bring attention to. a lot of useful content that should be in a wiki is burried in e.g. the mailing list archives, hidden among an endless stream of unorganized exchanges. <attila_lendvai>e.g. the most recent example is the UI questions and TODO's of the guix command. it keeps coming back on the mailing list, instead of having a place easily viewable and editable for people who has something to say about it (because it's not trivial to search for certain topics in mail archives, like this one, but it's trivial to navigate to on a wiki) <ss2>We've also got a cookbook too. <ss2>And have thought of preparing contributions for it. Sadly I never have the time for that. <lilyp>Searching through mail archives or a wiki is literally the same operation (full text search) <lilyp>Unless you want some clever tagging system, which guess again someone would have to monitor <lilyp>People spend more time organizing their TODO lists than actually removing items from them. <singpolyma>Good wikis are good, but it takes a lot of effort to garden. I am part of communities with dedicated gardeners and they have great wikis. I run wikis for most of my other projects of any size, guess who writes all the content? Me, heh. I love wikis but sometimes the problem is just no one to do the writing and tools can't magically fix that <singpolyma>Things would buried in mailing list even with a wiki unless someone takes the time to extract the context and write something up on the wiki. Which someone could freely do now if they were inclined :) <attila_lendvai>lilyp, the number of wiki pages is a fraction of the mailing list threads, i.e. browsing them is a feasible task. also, searching in a wiki doesn't bring up obsolete content, while a mailing list even contains ideas with broken asusmptions that were argued away <attila_lendvai>singpolyma, i have had impulses to add stuff to a guix wiki (as opposed to my private notes) multiple times. <attila_lendvai>singpolyma, the official wiki is not dedicated. i searched it a couple of times, saw all kinds of non-guix content, and ignored it afterwards. <lilyp>I mean, you could share your private notes – then they'd be public notes. <attila_lendvai>lilyp, i know, and i want to. the question is *where*. if you tell me to put it anywhere, then you're still missing my entire point about the network effect, which is probably my mistake of not wording it well enough. <singpolyma>attila_lendvai: if you want to write things somewhere useful then the official wiki would be a great place to write even if you don't like the search that shouldn't affect writing. <lilyp>if you like their wiki, then open up a pull request or something there <lilyp>But don't expect Guix to list (and thereby endorse) a bunch of third-party repos, for instance. <attila_lendvai>singpolyma, it could be. but how many other people have been turned away from contributing like i was? => the wiki is pretty much empty. <attila_lendvai>but anyway, i don't have enough credit to argue against such an opposition. i thought it'll be much more about stuff like the maintenance burden, but i sense more of a philosophical opposition. <singpolyma>Well, of course it's about maintenance burden. No one wants to run it or garden it especially if there's not going to be an outsized payoff. Also, don't listen to me I'm just some random person on IRC ;) <singpolyma>Maybe someone really does want to run another wiki and they're just not here right now, heh <singpolyma>KE0VVT: yeah, I'm here to ask annoying n00b questions so I can make a lot of packages ;) <raingloom>further LaTeX help is needed: I can't find file `cmr12' <- which package has this file? <KE0VVT>singpolyma: What are you wanting to package? <singpolyma>KE0VVT: i sent a bunch of patches already. I'm going to package all dependencies for the JMP stack is the hope, so we can deploy our new box using profiles for rollback purposes, etc <singpolyma>Started with just the billing webapp (so a bunch of rubygems) and also stuff for SSL/dns infra <KE0VVT>singpolyma: Is JMP going to run on Guix System? :o <raingloom>and ye i figured as much, but i do have texlive-cm in my environment <singpolyma>We're not *quite* ready to leave Debian entirely yet <KE0VVT>guix is pretty foreign. figuring out how to do certain things was hard for me. <KE0VVT>'just edit this file and restart the daemon' - 'im on guix and thats not how any of this works' - 'wtf' <raingloom>ss2: i also have texlive-fonts-ec, which wikibooks says is needed for some font stuff? <singpolyma>But all our apps and configs we hope to deploy using guix, Debian will be for base layer stuff like nginx, prosody, etcetc <ss2>raingloom: Do you have texlive-cm-super installed too? <raingloom>although not with all the other packages... let's try again <ss2>Do you know for sure that your file otherwise is correct? (just asking..) <raingloom>afaik it is, it's a template file that my teacher uploaded <raingloom>current guix invocation is this: guix environment --ad-hoc texlive-latex-fontspec texlive-cm-super texlive-fonts-latex texlive-fonts-ec --manifest=guix.scm -- pdflatex hazi1.tex <raingloom>maybe i should just say "fuck it" and use the huge texlive package :,) <ss2>And then you are adding packages to your user profile? Have you thought of putting it in your declaration? <ss2>I use the big package unfortunately, and live a happy, but cramped live. <KE0VVT>Rule: When both TeX Live and Guix are installed, all disk capacity is used. <KE0VVT>(Guix uses quite a bit of disk space.) <raingloom>i guess i could try installing to a temporary profile but i don't know what that would change <ss2>KE0VVT: yeah, I've pretty much pinned the package now, and leave it as it is. It's taking a huge chunk, but it isn't growing now. <ss2>raingloom: oh, sorry, I missread your link. <ss2>Could it be that amsmath is missing things? <raingloom>ss2: i have no idea, i'm pretty new to LaTeX <lilyp>btw. what's the minimal texlive setup to get texinfo working? <ss2>but there is texlive-tex-texinfo <ss2>lilyp: how about you try it with that with texinfo? <lilyp>texinfo requires texlive for PDF output <raingloom>at this rate it'd be faster to figure out which package i need. <raingloom>(oh nvm, 1.4 MiB/s, it's around 40%. still. not happy about the wasted space and bandwidth.) <g_bor>I received an invite to join guix-meetup room in jitsi, but it looks like I am ther alone <raingloom>goddamit guix build texlive failed a huge download and now i have to restart it. why hasn't the substitute download resumption code been merged yet? <raingloom>oh hey, could someone look at the mypy patch i sent? it makes mypyc work. i'm not a python expert, so it would be nice if someone who knows it better took a look. ***Xenguy_ is now known as Xenguy
<raingloom>ss2: well, texlive did work. why is software like this. maybe LaTeX could have a similar feature to guile's use-modules suggestions for undefined names, except for packages... <awb99>I want to write some services. But I am not sure how I could test them before applying. any ideas? <raingloom>awb99: a minimal VM is what i usually go for ***janneke_ is now known as janneke
<lilyp>raingloom: Funny thing is, Guile doesn't have that. Guix has. <g_bor2>we just tried to guix refesh something and it failed with api.github.com certificate could not be vaildated. <g_bor2>Is this valid for a bug report, or did we miss something? <g_bor2>we just run 'guix refresh go-github-com-muesli-termenv' <maximed>If not, maybe nss-certs needs to be updatedd <g_bor2>so, we just checked, We could use the browser <g_bor2>might that be something with the refresher? <maximed>I forgot the name of the enterprise, but I've encountered DNS proxies (or something, not sure what they call themself) at schools that try to stop you from reading https://xkcd.com and other things <maximed>g_bor2: Could you share the certificate you see in the browser? <maximed>In Firefox derivatives, it can be found from the padlock symbol, clicking on the arrow next to ‘connection secure’, then ‘more information’, then view certificate’, then ‘download PEM (chain)' <maximed>Actually, PEM (cert) is probably sufficient <maximed>FWIW, I see SHA-256 fingerprint ‘78:1A:2D:C5:57:DD:7E:D3:A4:C3:A3:97:30:77:49:06:16:AB:FC:98:3B:47:81:DD:81:0F:10:F2:78:60:62:CE’ over here <maximed>If it's different, that would mean GitHub has an interesting TLS setup, or there is a MITM <raingloom>"stop you from reading https://xkcd.com and other things" honestly reading xkcd got me more interested in STEM than most of my teachers, but that's a topic for another channel <Noisytoot><maximed> I forgot the name of the enterprise, but I've encountered DNS proxies (or something, not sure what they call themself) at schools that try to stop you from reading https://xkcd.com and other things <Noisytoot>My school uses an HTTP proxy to do that, and intercepts TLS connections on port 443. I use Tor to get around it <maximed>raingloom, Noisytoot: To be clear, the teachers didn't seem to mind xkcd, and the school probably just inherited the DNS and Internet setup from their umbrella organisation <lilyp>Is it already time to do so? <lilyp>Oh, I thought it's only done shortly before the other way <podiki[m]>not to wade into the whole wiki discussion exactly, but one thing I would find helpful would be some sort of meta search <podiki[m]>a way to search simultaneously docs, cookbook, source, devel, help, bug, patch lists, irc logs <podiki[m]>you could do most of that locally, but a little web interface that searches all at once would be great. i don't have much web programming skills, though I might take a look <raingloom>podiki[m]: also your guix system might be broken and then you can't use local search. so i'm 100% in favor of better web based mirrors of docs. <podiki[m]>a first pass I was thinking something real basic: shows results from all those sources (by source, until some way to weight the results together?) <podiki[m]>saving some browser tabs. because this is what I do when i'm looking for something, there's lots of good info, somewhere <podiki[m]>later I was thinking any "trending" terms would be pointing out a need for better docs on that feature <maximed>Speaking of web interfaces, does someone know a guile library *maximed looks in GNU Artanis documentation <maximed>* for parsing application/x-www-form-urlencoded <podiki[m]>how are guile's web libraries? might be a way for me to learn some guile, otherwise I tend to reach for common lisp in general <maximed>podiki: There's GNU artanis, guile-webutils and guile's (web ...) modules <podiki[m]>named after starcraft character? a plus in my book <tonos>Hello! Does somebody know the `xorg-start-command' procedure is used? <lilyp>podiki[m]: If wading through the ML is already too much, referencing random IRC timestamps (without context) is hell <iskarian>to definitely wade into the whole wiki discussion: I'm not sure what should serve the role, but I feel there is definitely a gap where a semi-permanent, low-barrier-to-edit, source of information should fit. while a meta-search would definitely help, the fact of the matter is that even with that, if a user (or contributor) can read an overview of something rather than ten or twenty emails, or trawl through the IRC logs, that saves time and <iskarian>increases engagement. The manuals are great for this... when the information is available there (and accurate). <lilyp>All those supposed benefits of a Wiki would be dwarfed by the maintenance overhead imo. <iskarian>Yeah, I'm not sure if a wiki would serve this need, exactly <dstolfa>my take on wikis is that unless you have resources to keep it up to date, it's completely useless. <iskarian>Whatever fits into that needs to have no guarantees attached, such that there's no feeling like it *has* to be polished <dstolfa>in fact, it's actively harmful at times. <dstolfa>we regularly have people being mislead by the wiki in FreeBSD <dstolfa>because they come across some random wiki page that's 10 years out of date <lilyp>yup, plenty of third-party resources still call it GuixSD for example <iskarian>(it would be an interesting feature for a wiki to regularly prune untouched pages) <dstolfa>iskarian: there is potential for people to find that annoying, especially if it's something that doesn't change often <Noisytoot>just add a message saying "this page is out of date" <iskarian>Oh, sure. It would be an experiment for sure. I'm not familiar with any examples of it actually being implemented, so I'm curious what the results would be <podiki[m]>lilyp I never said the ML were too much, but that there are several places you want to look to see if it has been discussed, reported, worked around, whatever <podiki[m]>That could be easier. (And perhaps serves more the potential developer or contributor than casual user) <podiki[m]>I actively search all these things frequently <iskarian>One thing that would be interesting about an everyone-editable thing is to see what kind of information is added to it: it may represent what is missing in the official docs <awb99>do I have to run guix syste reconfigure as root or can I run it as normal user? <awb99>when I run it as normal user, the symlinks do not get created, but I dont get any errors. <awb99>can I include other scripts in my guix system config? <awb99>I would like to add a couple different services configs. <awb99>And to have them all in one file seems to be bad for maintainability. <maximed>awb99: I usually get errors (at the very end) when I run "guix system reconfigure" without errors <maximed>awb99: what is the nature of these ‘other scripts’? <maximed>If you mean splitting some Scheme code into a separate file, see 'use-modules', 'define-module', 'include', 'include-from-path' and 'load' <maximed>These are Guile syntax and procedures. <awb99>how would the os loader then know where the modules are stored in? <awb99>same path as the reconfigure cli call? <maximed>I'm assuming you mean Guile modules here <maximed>"guix system -L . reconfigure the-config.scm" <maximed>Then you can use (use-modules (stuff)) in the-config.scm if stuff.scm is in the current working directory <awb99>I think it is caching my old source code files somewhere. <cwebber>make[2]: *** No rule to make target 'etc/guix-gc.timer', needed by 'all-am'. Stop. <podiki[m]>like the shepherd example gc timer (manual or cookbook)? <iskarian>podiki[m], yeah, it was added officially in #50610