<jgart[m]>Thanks to everyone that came and contributed to LibreMiami's Guix Packaging Meetup! It was great to chat and to code together. We got ed25519 (https://github.com/OperatorFoundation/ed25519) packaged! I'll send the patch later tonight to firstname.lastname@example.org for code review :)
<pkill9>well I managed to add that redirect of all subdomains
<PotentialUser-86>Friends, I recently saw the shadowsocks-rust package on the Guix wishlist, but it seems that these packages have not been packaged for a long time (it has not received much attention); Can anyone package (shadowsocks-rust, v2ray-core, Qv2ray)? (Many users in Iran and China need it)
<civodul>mothacehe: hey! great that guile-simple-zmq now has bindings for the "message" type
<civodul>so we no longer need to go through the API that uses fixed-size messages, right? :-)
<mothacehe>civodul: hey! it also uses Autotools and has basic unit tests.
<sneek>Welcome back mothacehe, you have 1 message!
<sneek>mothacehe, jlicht says: thanks for cleaning up my mess. `http-parser' did not show up in the RSS feed, so I was not at my laptop :/
<mothacehe>yep fixed-size messages are no longer needed :)
<civodul>mothacehe: nice, it's becoming serious business :-)
<leoprikler>yeah, basically I'm writing a magic incantation to switch the reader at compile time
<prittstick>Hello! Wondering if anyone can help. I'm trying to figure out how to add a Python package to my ad-hoc Jupyter notebook environment. BeautifulSoup (python-beautifulsoup4 in the guix repo, 'bs4' to Python) specifically. This is what I'm doing, but Python's returning 'No module named 'bs4'': guix environment --ad-hoc jupyter guix-jupyter python-beaut
<prittstick>So far i'm simply running guix of my foreign distro like a conventional package manager 😈
<pazho>Hello guixers! Could anyone help confirm a 'bug' I encountered in the channel dependency specification (before I can report it): If I quote the value in the =name= field of a dependent channel, as in the example at info:guix#Declaring_Channel_Dependencies, =guix pull= errors out. Works fine here when unquoted.
<rekado_>prittstick: a manifest for this would look like this: (specifications->manifest '("python" "jupyter" "guix-jupyter" "python-beautifulsoup4"))
<rekado_>put this in a file “i-know-manifests-now.scm” and run “guix environment -m i-know-manifests-now.scm”
<sertified>Are there any articles on system maintenance for Guix System? Something like the one in the Arch Linux wiki
<rekado_>sertified: is there something you would like to see in the manual that is not mentioned there?
<paulj>Afternoon all! Is there a simple way to see which package provides a header file? I am making a package for dwmblocks and need to add a package which ensures X11/Xlib.h is available, but the obvious choice (to me, at any rate!) of (gnu packages xorg) doesn't seem to be correct. Thanks!
<paulj>Thanks andreas-e - I have put libx11 in the inputs clause, but perhaps I have an error, as it didn't seem to pick up. Let me go and have another look... The code I have used is here: paste.debian.net/1186905
<roptat>if I know the name of the header file, I think ls /gnu/store/*/include/X11/Xlib.h is faster
<srn>Hello all, I'm new here and have been experimenting with guix the distro. I'm currently using NixOS but am contemplating moving to Guix as my desktop OS. I have some questions of confusion that I was hoping someone can help me with please?
<srn>Can I put all of my packages in config.scm? Is that the recommended way or should I just use a base config in the file and install by user basis? Its just me on the sys and I want to be able to easily reproduce the system
<srn>This is a personal desktop system and I am the only person using it
<srn>I have been experimenting with this sys in a VM and got my desktop installed but I have not been able to find and documentation on how to mount cifs or nfs shares. Can someone point me to some examples of this?
<abcdw>srn: My approach is to keep system config as thin as possible (mostly hardware-specific things) and install the rest of software in user profile, but depending on your needs and preferences the approach can be very different.
<srn>abcdw: So you install all the packages manually or do you have a seperate config file in you profile that you load everything from?
<dongcarl>I'm wondering if there's a way to: given a manifest, list all changes packages between 2 guix commits which affect this manifest. I guess I can do `guix time-machine --commit=<from-commit> -- pull --dry-run --commit=<to-commit>`, but that is news for everything, not just my manifest which I care about
<abcdw>srn,jlicht: You are welcome) dongcarl: thank you for what?)
<dongcarl>abcdw: Oh I was curious about jlicht's problem as well, so that helped me :-)
<civodul>dongcarl: not really; 'guix pull -l' and '--news' show the list of upgraded/added package, but that's very abstract
<civodul>then of course there's the Guix Data Service
<civodul>we could write a client for the Data Service
<abcdw>dongcarl: cool!) According to your problem about changed packages: If I understood the task correctly, you can try to implement the same command, but in guile instead of using cli and just find intersection of returned set of packages with your manifest (filter by only interesting for you packages).
<lf94>When you hit a build issue which is about another piece of software, do you move onto that next piece and package it?
<lf94>For nodejs-12.x, I'm hitting an issue about http-parser not being available to pkg-config
<dongcarl>Yeah I'd love tips on this. For some context, a few of our community members were asking about how best to review when I bump our time-machine commit, and I didn't have a best answer for them.
<dftxbs3e>civodul, so I am afraid it is not possible to make so the patches to support PowerPC 64-bits can be merged on master directly. When is the migration to GCC-8 planned? It looks like we will need it as a requirement for PowerPC 64-bits Little Endian on glibc >=2.32
<civodul>dftxbs3e: oh i see, so that's core-updates
<dftxbs3e>civodul, I used this to try it: https://bpa.st/raw/WIBYO - currently waiting for builds but it looks good on the wip-ppc64le branch (it had core-updates merged in few days ago)
<marusich>cbaines, thanks for the link! I was curious to see how the build compared to the build at commit 38283f5bdb598db16e9556552a9e97d27ccf4fa6, which is the merge commit that merges core-updates into wip-ppc64le, but it seems the website doesn't know about that commit...
<dftxbs3e>marusich, I have push access to somewhere I can submit the upstream branch
<dftxbs3e>marusich, wip-ppc64le the branch will fail currently, so do we push that gcc-8 patch or..?
<dftxbs3e>marusich, I have a powerpc64le-linux guix-build-coordinator-agent on cbaines guix-patches infra (separate from guix official repo building), and I also have push access to their guix-patches git repo where all patches from the ML get applied, so I just push a branch there and it builds on my agent basically.
<dftxbs3e>I think we need to ask cbaines for some additional tweaking on their side if we want to build official wip-ppc64le which is in better shape than before
<marusich>I see no harm in upgrading GCC to 8 on the wip-ppc64le branch; we can reset the branch and rewrite its history if we need to. Commits should be authored with the same quality we would expect going to master or core-updates, but that does not mean we can't try "crazy" things.
<marusich>As long as we communicate clearly about what's going on in the branch, I think it's OK.
<marusich>And of course, we must not merge it into master/core-updates/elsewhere without getting wider agreement on the plan.
<dftxbs3e>marusich, alright, let's do it then once a local build gives more clues about it's success
<dftxbs3e>marusich, I came back home so entirely focused now, my turn!
<marusich>OK. ping me when it's pushed and i'll try building it
<zimoun>is it possible to have “guix graph --path” between 2 modules?
<marusich>although, i have already started a build using a locally applied patch you gave me, so maybe i'll just let it build for now
<thomassgn>So, I've not updated my system for some time (I think last time was christmas-ish) and now guix pull fails halfway-ish through saying berlin.guixsd.org is not found. Probably because ci.guix.info seems unresponsive. Should I use other substitute servers/urls?
<apteryx>adfeno: ah, sorry if our questions intertwined, I asked mine without reading back :-)
<apteryx>seen after a fresh install using guix-install.sh, and configuring a user correctly with GUIX_LOCPATH (having installed glibc-locales): LC_ALL: cannot change locale (en_US.utf8)
<apteryx>I think that's because the systemd service installed refers to the root guix profile, which doesn't exist (root hasn't guix pull'd, nor install glibc-locales yet): Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8
<apteryx>civodul: not sure if I'm missing something, but I thought the above shouldn't be possible ^
<adfeno>Altough Minetest is using STATIC_LOCALEDIR="/gnu/store/i38ca5c3dy9291yz4kz1gzmm6xapy0rl-minetest-5.3.0/share/locale" and I can conform that the only things there are folders with languages, including es, each with LC_MESSAGES/minetest.mo … it still says it's using C as locale.
<adfeno>I think I have seen this issue before, it seems to happen also with R
<adfeno>Exporting LANG, LANGUAGE, and LC_ALL either through ~/.profile or ~/.Renviron does't change.
<adfeno>apteryx: I wonder if your issue is also related, since I don`t think it's a good idea for LC_ALL to be in the service declaration.
<adfeno>apteryx: on second thought, I don't think they are
<adfeno>because the service only affects guix executable
<thomassgn>mdevos: Allright, will do; I haven't updated the substitutes in my config for a loooong time and the last year or so I haven't been paying much attention to my system. :) rekado Yes, ICMP/Pings. I understand.
<cbaines>lfam, I can help with the ci.guix.gnu.org Cuirass admin stuff if you're around?
<thomassgn>rekado: about ci.guix.info, I got a few errors about berlin.guixsd... not being reachable, ci.guix.info is first in my defined substitute servers, so I assumed ci.guix.info or some infrastructure between me and it was struggling. When ping gave dropped/missing packets my assumption was fortified. :)
<apteryx>OK, it comes from src/gnutls.c: ca_directory = opt.ca_directory ? opt.ca_directory : "/etc/ssl/certs"
<lfam>ls: cannot access '/home/leo/.guix-profile/etc/ssl/certs/ca-certificates.crt': No such file or directory
<apteryx>ah, yes, it uses GnuTLS, and GnuTLS has that flaw
<roptat>mh... tricky... I'm trying to reproduce OCaml using camlboot in guix. We managed to get no difference when building locally, but with guix packages, I actually find quite a few differences, and they all seem to be caused by the binaries retaining reference to the output directory (which obviously has a different hash)
<apteryx>so, this works for GnuTLS/wget: guix environment --container --network --expose=$SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt --ad-hoc wget -- wget https://gnu.org
<pkill9>does anyone have an example of iptables configurations?
<pkill9>i want to block access to server via it's IP address
<pkill9>so it can only be accessed via domain name
<pkill9>then again maybe I'll just make a self-signed certificae
<bone-baboon>I have been searching the Guix packages with `guix search <package-name>` for packages that I use. I am impressed as a lot of the software I use is packaged for Guix or there is an alternative package I could use. This search has brought up a couple of question.
<bone-baboon>I see a `docker` package but I do not see a package for `kubernetes` or `minikube`. Have they been deliberately excluded? What are people using as an alternative?
<lfam>bone-baboon: They have not been deliberately excluded. It's more that packaging that software is hard work and, so far, nobody has performed it :)
<lfam>In cases like this, many of use Guix as a package manager on other distros. It's designed to work well in that case, and then you can enjoy some of the benefits of Guix, as well as good support for software that we don't yet offer
<bone-baboon>lfam: Yes but I am looking at switching to Guix as an operating system.
<roptat_>freenode seems to be having some issues :/
<apteryx>lfam: there was another catch to what I was doing with the --expose=$SSL* above
<apteryx>--expose mount points cannot be layered; if it touches something already being specially handled by guix, it becomes a no-op it seems
<apteryx>in my case I was executing the command from $HOME; so the working directory was being mounted automatically. Because the SSL_CERT_FILE and DIR variables referred to locations in that $HOME (.guix-profile/etc/ssl/...), they wouldn't be mounted
<adfeno>bone-baboon: if that thing download stuff, i think it's better of with the default repositories stripped if installed from guix, unless and only if its being operated using guix import. see http://issues.guix.gnu.org/45450
<nckx>bone-baboon: That might have the same FSDG issues, since it (according to my reading so far) can install cargo, and cargo can install anything, including free software that recommends non-free software.
<roptat_>ah right, I'm not thinking at the right level ^^'
<jackhill>It's not only carge, we also make pip and I'm sure other language-specific package managers with default repos
<roptat_>ok, so then maybe because it doesn't install software?
<lfam>I wonder where it ends. Already the 'libre' distros suffer from huge gaps in software and hardware support
***roptat_ is now known as roptat
<adfeno>nckx: re: import: the reason for that would be to ease the work of importing from third-parties. Of course the patches would need review, perhaps teaming with Free Software Directory ( https://directory.fsf.org/ )
<nckx>(To be clear, my opinion is that ‘guix import’ is not special, and that adfeno's exemption is arbitrary.)
<lfam>We should be careful not to cut off our noses
<adfeno>single-language package managers have a preset repo, and THAT repo is not explicitly commited to FSDG, that is the issue.
<nckx>lfam: Oh, I'm sure we don't! I just mean that if we do *that* and refer to The Rules, not applying the Rules consistently in *less* vital places makes absolutely no sense.
<jackhill>+1 for applying the rules consistently. It seems sometimes the rules aren't specific enough, so we should clairify them to make them easier to apply.
<lfam>nckx, adfeno: I think we all agree in our goals, which are to create free software operating systems. The details are where we disagree. However, my disagreement does not extend to action, so I'm going to bow out of this conversation
<nckx>adfeno: <browsers do come with JS> We agree on that, but what does it refer to?
<jackhill>Another rule I find confusing sometimes is languages and bootstrapping. Some languages in Guix start from blobs while others are not included because they need blobs.
<lfam>jackhill: It's basically a question of "how much does the person adding the language care?"
<lfam>Starting from a blob is what every other distro does, so it's not any worse for us
<adfeno>nckx: someone said that we should supposedly remove browsers because they come with JS enabled. That is not what I was supporting. I was in favor of removing software that always point to a set of default repositories through which one can install non-free software. Browsers' JS has no such thing.
<apteryx>lfam: one last thing; exposing SSL_CERT_DIR/FILE cannot work because they are symlinks
<jackhill>adfeno, nckx: oops sorry for bringing up browsers if it's a different case, it just seems like real purpose of browsers these days is to run non-free software, so it's odd that we include them :)
<lfam>I guess that I see a situation where it's not possible to use an operating system with only free software support, while some people do think it's possible. And that's where the disagreement lies.
<adfeno>jackhill, lfam, nckx: re: disabling JS: I'm ok with it. What I'm not ok is removing entire browsers just for the simple fact that it runs any JS
<pkill9>i finally got it using the self-signed certificate
<roptat>rndd`, 0.001% of the web is still a huge number of websites, I guess :p
<nckx>jackhill: <real purpose of browsers these days is to run non-free software> Even if that were true (debatable), it's not acceptable to ban browsers because they could be used to do something you don't like.
<apteryx>lfam: Guix appear to resolve symlinks, but in the case of SSL_CERT_DIR, they are nested.
<rndd`>roptat:well, most of sites i use dont have js, so i'm fine
<nckx>Refusing to run non-free software is against what GNU stands for: freedom.
<apteryx>thanks for the help, I was able to find 2 issues to report and now have a better understanding of how thing work/fail
<jackhill>nckx, adfeno: agreed, I found browsers useful to think about, but I think it distracted us from the core of the discussion. Sorry.
<adfeno>This is why there needs to be either a trust or blocklsit, which could be user-controlled.
<nckx>(I mean, don't do it, like you mustn't do the drugs, kids!)
<nckx>jackhill: I'm prone to distraction on the best of days ☺
<adfeno>I can't remember now, but there used to be a software with which if you don't specify the configuration file for its subprocess, it loads from the system-instaled ones. Then, if you do give an override, it modifies only the exact variables that you mention in the override, you could also explicitly exclude one from the original set.
<adfeno>So by analogy, system-installed could be Guix default's for no third-party repos for, for example, cargo. Then, user overrides could be the appropriate user's configuration for cargo.
<dftxbs3e>I am not very motivated to do it since there is many other more worthwhile issues for me
<adfeno>lfam: I`m fetching the source/reference, one sec
<lfam>I see adfeno. As it is, many Guix users build their own kernels anyways, to get support for their computers
<lfam>It's not urgent, since Guix makes it easy for people to use custom kernels
<bone-baboon>nckx: It does not look like LibreWolf links to non free addons. The addons search in the settings is disabled. They list addons in there documentation and link to them directely. All of those addons linked to in the documentation have licences that are green here https://www.gnu.org/licenses/license-list.html
<nckx>lfam: According to linux-libre upstream, not loading user-specified firmware is an unintentional ‘bug’. I don't actually believe them, but if someone were to write a patch that fixes it we'd soon know... ☺
<lfam>nckx: I think it's a bug, but not exactly high-priority. I can relate
<adfeno>lfam, nckx: Ah, nckx was quicker. I was trying to find the exact reference of my allegation, and it was indeed a bug, according to Linux-libre, seems to be caused by the way *Linux* (upstream) is made.
<adfeno>bone-baboon: third-party reop: even if a repo contains only free software now, it might not be in the future. the FSDG does allow third-party repos as long as they express written commitment to follow the GNU FSDG also.
<nckx>lfam: Naturally, but LibreWolf might not (although if they *disable* the Add-On shoppe or whatever it's called, that's fine -- we don't ask for written promises from every single Guix upstream that they won't add an app shoppe to coreutils).
<lfam>But, you can over time transition away from substitutes as you upgrade and build more and more things
<dftxbs3e>lfam, it would be great to expose that distinction in some way
<lfam>It's not always possible to build everything from source
<bone-baboon>lfam: Okay that was what I was thinking when I asked the question.
<dftxbs3e>metadata of where a store item was built?
<lfam>There's already metadata about who signed it
<dftxbs3e>and also information about the machine that built it? might be interesting
<lfam>One just has to temper their expectations somewhat. In a functional package model, sometimes we get stuck requiring substitutes for packages that can no longer be built, until we can schedule the resources to build changed versions of those packages
***link2xt[nm] is now known as link2xt
<lfam>Like, you can no longer build our GnuTLS package, since the source code has an expiration date baked in :/
<lfam>You must use our substitute, or mess around with your system clock