<allana>Question about submitting packages. Say that I want to submit "python-flake8-import-order", which is a plugin for flake8, a linting tool. Would that belong in python.scm, python-check.scm, or python-xyz? I'm not aware of the package organization scheme.
<g_bor>Yesterday I had the opportunity to look at static networking service.
<g_bor>I did a bit of looking around the netlink stuff and I got interested working on it.
<g_bor>I would rather not go along the libnl binding route, libmnl is looking more appealing from our point of view, but as an inspiration. It is a thin wrapper around netlink, without much abstraction, and seems to be small amd easy enought to adapt to guile.
<g_bor>This is also one of the main blockers to more advanced networking features, and I would also like to deal with those later. Wdyt?
<markwork>Hey, I can't seem to find a cargo package and the normal rust package does not make a cargo binary available. What's the best way get a working cargo?
<nckx>markwork: Cargo: try rust:cargo. Working: I don't know.
<markwork>nckx: thanks, running a profile update and then I'll look into the cargo output of rust. That was easy :)
***rekado_ is now known as rekado
<rekado>sneek: later tell rvgn Guix does not ever touch a user’s home directory. “guix system reconfigure” is safe.
<jlicht>civodul: what does `-r' even do for regular files?
<civodul>jlicht: it takes the executable bit into account
<jlicht>aha. Is this usual for tools that support a recursive flag?
<jlicht>civodul: and I got that the executable bit is considered, but I mostly meant if that is /all/ `-r' does
<leungbk>@civodul ah, thanks for that. i noticed that the output of that command ("guix hash ./bar.tgz", with or without ./pre-inst-env) didn't match what "./pre-inst-env guix package -i foo" expected as its hash; once i changed the hash to that of the latter command, my package installed. is there a reason the two hashes here should be different?
<rvgn>Oh you mean since there is already mu package available?
<nckx>‘Lots of use mu4e and more minimal stuff like mutt’. The other stuff isn't missing because we hate it, just because we don't use it and packaging things like Thunderbird/Evolution/… is a lot of work.
<rvgn>mikadoZero I installed the package "emacs". Is that a base package? I have to install "mu" package in addition to that?
<civodul>gipa: this kernel version is from an old Guix it seems; we're at 4.19.28 currently
<mikadoZero>rvgn: When you open Emacs you should see a welcome screen. It makes since to do the tutorial and is helpful to read the manual. Both are mentioned on the welcome screen.
<civodul>gipa: at any rate, it would be great if you email to bug-guix the command and its output, as well as the output of "guix describe" or "guix --version"
<rvgn>nckx I get it. But the devs also should think about other users as well right? Since Guix is a Free Software and has some unique features, some regular users would like to shift from proprietary systems to guix.
<rvgn>Who would require regular GUI mail clients to do their work.
<gipa>civodul then maybe I did something wrong trying to upgrade guix :/
<pkill9_>vejetaryenvampir: packages which include 'share' files will have a '/share' directory within them, and guix creates a directory called a profile containing all the share files of the specified packages
<mikadoZero>In system.scm in the definition of %base-packages what is the significance of this part: (map canonical-package bash coreutils findutils grep sed patch gawk tar gzip bzip2 xz lzip) I am trying to explicitly state all the packages in the system configuration or user manifest instead of using %base-packages.
<kmicu>I don’t recall using - or | during installation process but you can ‘loadkeys en’ to write them ;) not ideal, but that but should be fixed once in kbd-project and not separately in every distro.
<mikadoZero>Blackbeard[m]: On my Guix SD system I managing all my Emacs packages using guix. You can see that there are many to choose from that are already packaged for Guix. `guix package -s emacs | less`
<lfam>Some folks from Arch are trying to improve how free distros communicate and handle security issues in packages. They would like to reduce the duplication of effort between distros regarding finding and testing patches
<lfam>At this point we are basically just introducing ourselves