<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
<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
<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>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?).
<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
<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.
<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.
<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>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
<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
<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