<brettgilio>Im trying to configure gnus on Guix system. I am having an issue with gnus not being able to connect to nntpd. I notice nntpd is not an available command on Guix. Thoughts?
***akko is now known as frankzappa
***frankzappa is now known as gologolo
<brettgilio>No matter how I configure gnus I'm getting this error:
<brettgilio>Warning: Opening nntp server on news...failed: >>> (error news/nntp Name or service not known); Server nntp+news previously determined to be down; not retrying; Opening nntp server on news...failed: >>> (error news/nntp Name or service not known); Server nntp+news previously determined to be down; not retrying
<efraim>smithras: if it's anything like the last time we got this complaint, it goes like this: "I have to download non-free code to run the snippet to remove the non-free code. And now it's on my computer"
<efraim>This doesn't address that SOMEONE has to download it and remove it at some point if we want to have, say, a deblobbed kernel
<raghavgururajan>smithras Yes. The phenomenon of downloading source with non-free parts was the concern during the discussion.
<zimoun>raghavgururajan: from my point of view, this discussion is a non-sense because the FSDG speaks about "installable system distribution" and Guix does not install non-free stuff. Moreover, let stretch the "Non-functional Data" section: Data that isn't functional, that doesn't do a practical job, is more of an adornment to the system's software than a part of it. Thus, we don't insist on the free license criteria for non-functional data.
<raghavgururajan>zimoun That's correct. That section explains what should a distribution should be doing while distributing the software.
<raghavgururajan>zimoun You are correct about non-functional data. The left-over source with non-free parts can indeed be considered as non-functional data. As I mentioned earlier, it is just that FSDG needs to revised to redefine things clearly for this scenario. That is all. :-)
<zimoun>raghavgururajan: one needs to read with stretching the FSDG to claim that Guix does not respect them. All the distributions have to remove blobs; at least linux kernel ones -- so applying the argument, they do not respect the FDSG neither.
<zimoun>raghavgururajan: My point is: if it Guix does not respect the FSDG because the arguments of your email, then no distribution using the linux kernel does not respect neither; because they need at some point to remove the blobs. The FSF provides even the script. I mean, you need to download blobbed kernel to apply the script. I think it is a non-sense argument.
<zimoun>raghavgururajan: maybe the FDSG need to be revisited to clearly point such scenarii.
<raghavgururajan>zimoun That is not true. FSDG distros other than guix, distribute deblobbed version of linux kernel. Not scripts/code that allows directly downloading blobbed source on the user's system. There is a difference.
<raghavgururajan>FSDG is concerned with what distributor distributing to the end-user.
<zimoun>raghavgururajan: and the other FDSG distros way is in contradiction with the section: Please Teach Users about Free Software.
<raghavgururajan>zimoun Could be or could be not. That is unrelated to this scenario. That can discussed as a separate matter. :-)
<zimoun>raghavgururajan: I appreciate your effort to improve. My points are: If Guix is non-FDSG, then other FDSG distro too because the linux kernel blobs. If one escapes with the end-user argument, then they contradicts with the section "Please Teach Users about Free Software".
<kmicu>Personally I think that other distros (and package managers) are less flexible and it’s more difficult to get blobbed kernel and deblobbing scripts on user’s disk. Guix blures the line between users and distro maintainers and that’s why the situation is new.
<kmicu>(The situation is simialar to expressive power of Racket and the recent (and sad imo) news “First, it is unclear how to apply the LGPL’s statement about dynamic linking to a language like Racket, where macro expansion can copy code from libraries to applications, and where applications are typically bundled with the Racket runtime and libraries.”)
<leoprikler>zimoun: I think you can as a distro ship the deblobbed kernel only
<raghavgururajan>kmicu EXACTLY!!! The situation is new. That why the confusion arosed.
<kmicu>Being transparent and explicit is the best cure for any confusion so explaining how a source‑based distro with (optional) substitutes and ability to (trivially) put users in maintainer’s shoes handles liberation of proprietary software will be beneficial to us all.
<zimoun>kmicu: I agree with you. My point is that if one carefully reads the current FDSG without any bad faith, one needs to scretch it to claim that Guix is non-FDSG. Everything can always be improved, for sure. But is source-based distro as Guix really new? I am not convinced.
<truby>is it possible to have multiple source archives for one package?
<leoprikler>one very complicated example would be the linux kernel
<truby>I'm trying to think of the best way to package clang-tools-extra, it only supports being built with clang in the clang source tree. Other distros seem to just bundle them in the clang package because there's no real reason not to (other than a slight increase in build time and disk usage)
<truby>but they live in a separate source archive to the main clang source
<truby>possibly, I haven't tried it. I'm not sure how outputs work, if they're like an extra option you can add when building the package then that'd work fine. But if it's effectively a separate package then you end up with the problem that you have to work out, once you've built clang+clang-tools-extra, which binaries and libraries come from tools-extra and which come from clang
<truby>and additionally in order to intsall clang-tools-extra you'd have to build clang to install that as clang, and then build it again just to get the extra tools
<leoprikler>so you can't build clang first and then just build the tools?
<leoprikler>I think the smartest thing would be to have a package that inherits from clang, but also has the extra tools
<leoprikler>though there is the problem that clang itself probably does not work outside of clang-toolchain
<truby>yeah, I think we should hide clang really. In the same way gcc is hidden
<truby>but you'd need to inherit from clang as clang-with-tools and then have a clang-toolchain-with-tools that uses that I guess? the tools also won't work without clang-toolchain though
<leoprikler>so you would have to build clang-with-extras and then use that as input to make-clang-toolchain
<truby>yeah. But then would you have clang-toolchain and clang-toolchain-with-extras separately? if you were just going to bundle it all into clang-toolchain I don't really see the benefit of splitting it at the clang level
<leoprikler>you don't really need the extras to compile most stuff
<leoprikler>you may want clang-tidy in development and what not, but they're still extras
<str1ngs>leoprikler: our maybe have extra as an output
<str1ngs>inherited packages require extra builds. it's kinda redundant
<kmicu>zimoun: Personally I don’t see an issue ‘breaking’ the spirit of FSDG but only with the fact that the road in Guix (System) from blobbed kernel or Chromium to the final libre artifacts on user’s disk (when using substitutes or bootstrapping everything from source) is not clearly stated and that is confusing for newcomers.
<roptat>so you can probably add a patch to support that version of exiv2
<roptat>you could extract it directly from the patch that fixed it in newer versions of gcm
<truby>leoprikler: I also use emacs, lsp-mode wants clangd :)
<truby>I also think that an :extra output would be the best solution, but I don't know how you can actually implement that without having to rebuild all of clang when you want to install just that output
<truby>and then somehow working out which libraries and binaries are already provided by the main output and which ones are exclusive to :extra
<alextee[m]>raghavgururajan: first, create a branch off master: git checkout -b my_branch. then make your changes, do git add --all to add your changes, then git commit to commit them, entering a message (see git log for other messages so you can add a similar one), then git format-patch master will generate a patch for you
<rockandska>If someone is available to talk about the strange behavior i hit with 'guix pull && guix gc', ping me
<raghavgururajan>alextee[m] So I `cd` to the directory that contains guix's '.git' file and did `git checkout -b rg`. I got the output "Switched to a new branch 'rg'". Should I just do `nano gnu.scm` now?
<leoprikler>sure, but why do you want to edit gnu.scm itself rather than some package file?
<raghavgururajan>what? one is a dubbed init system, another is containerization tech.
<anon987321>raghavgururajan: what about systemd-containerd? :P
<zig>raghavgururajan: the gist of the article is that both to do interop with each other. systemd could be run inside a docker container. systemd should keep track of programs that are running inside containers, in order to make it possible to bootstrap a cluster of "micro service".
<malaclyps[m]>anon987321: perhaps you are using a Guix executable that is using a different configuration file (I’ve found this confusing in the past — you can have, say, a Guix System guix executable which reads from a system configuration, a guix installed in ~/.config/guix/current/bin , the one installed in root, etc. If you type ‘which guix’ to find out the one you’re using.
<anon987321>ArneBab: I'm a self learner with too much time in my hands and with no huge necessities when it comes to material possessions (which means i don't really care about spending more hours working to get money)
<anon987321>so maybe in a while i'll be helping hurd some good hours a week :P