IRC channel logs

2019-11-20.log

back to list of logs

***sturm2 is now known as sturm
<anon987321>hi guix
<sneek>Welcome back anon987321, you have 1 message.
<sneek>anon987321, str1ngs says: pkg-config just make it easier to create the CFLAGS
<anon987321>how can i install chicken scheme eggs in guix?
<anon987321>using chicken-install, that is
<anon987321>i get permission errors on /gnu/store*
<gnutec>I have no reason to install a package without use guix.
<nckx>gnutec: 😊
<gnutec>nckx: Guix is the best thing ever happen.
<kmicu>Guix has trounced computing.
***stallman is now known as akko
<anon987321>i managed to get it working
<anon987321>there's a variable you can use to change where they are stored
<anon987321>so i just put it on my home directory
***catonano_ is now known as catonano
***jonsger1 is now known as jonsger
<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
<brettgilio>Fixed nvm
***gologolo is now known as akko
<mange>brettgilio: What was the issue?
<brettgilio>mange: for some reason my .gnus file wasn't getting loaded.
<brettgilio>Just a stupid mistake i think.
<roptat>hi guix!
<zig>o/
<efraim>hi!
<raghavgururajan>Hello Guix!
<smithras>raghavgururajan: hi!
<efraim>found another manual-config error
<smithras>raghavgururajan: did people on the #fsf channel really claim that guix is violating the FSDG?
<g_bor[m]>Hello guix!
<efraim>hi!
<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.
<cehteh>wtf
<wingo>that is an amusingly bad take :)
<raghavgururajan>efraim You are right. It is just that the current FSDG does not explain things for that scenario.
<raghavgururajan>Once FSDG is revised to explain clearly that scenario. There should be no confusion.
<bdju>how do I set my console keymap in my guix config? on nixos you can do so inside an i18n block
<raghavgururajan>Anyway, at the beginning of FSDG, it is mentioned that it mentioned to be evolved as new situtaions are encountered. :-)
<raghavgururajan>*needs to be
<bdju> https://paste.debian.net/1117087/ like this. so that in a tty or at the sddm login I'm in dvorak
<bdju>found it. looks like it's just "keyboard-layout" from 8.2 in the manual
<bdju>there's not an example and I'm not sure what the syntax should look like here... ugh
<bdju>ah 8.6 of the manual is a whole page about it
<zimoun>raghavgururajan: the FSDG explains with the section Nonfree firmware. And they links to theses scripts http://www.fsfla.org/svn/fsfla/software/linux-libre/scripts/
<bdju> https://paste.debian.net/1117088/ build failure just trying to set my layout. I'll run updates and see if anything changes
<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.
<raghavgururajan>Pardon?
<raghavgururajan>IIRC, SDG distros distributed de-blobbed version of linux kernel.
<raghavgururajan>*FSDG
<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.
<raghavgururajan>zimoun Yep, exactly my point. :)
<zimoun>raghavgururajan: ahah! Other FDSG says: do my my crap for me. (sorry for the language)
<raghavgururajan>xD
<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".
<raghavgururajan>zimoun I understand.
<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
<leoprikler>not that it would make sense
<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.
<raghavgururajan>kmicu Well said!
<bdju>what's that command to make sure you're using the new guix on your system? like from an old shell. a bit like sourcing a config. it slipped my mind
<leoprikler>bdju: perhaps `hash guix`
<raghavgururajan>bdju `guix pull`
<raghavgururajan>My bad.
<bdju>leoprikler: yes that one, thank you
<raghavgururajan>Folks!
<raghavgururajan>While building 'libmediaart', I get this error "./autogen.sh: ./configure: /bin/sh: bad interpreter: No such file or directory".
<raghavgururajan>But the shebangs are already patch in the process.
<raghavgururajan>Why am I getting this error? Or am I misinterpreting the error?
<leoprikler>perhaps libmediaart hardcodes /bin/sh somewhere?
<leoprikler>look at its configure.ac
<raghavgururajan>Okay.
<raghavgururajan>leoprikler configure.ac does not have any line containing "/bin/sh". But autogen.sh has "#!/bin/sh" as first line.
<raghavgururajan> https://gitlab.gnome.org/GNOME/libmediaart/blob/master/configure.ac
<anon987321>hi guix
<raghavgururajan> https://gitlab.gnome.org/GNOME/libmediaart/blob/master/autogen.sh
<anon987321>i wanted to have a modified version of ffmpeg, so i made a package that inherits original ffmpeg, and i defined it as ffmpeg-personal
<raghavgururajan>anon987321 o/
<anon987321>when i search for it, it shows up as ffmpeg
<anon987321>but if i try to install ffmpeg, it just uses the normal ffmpeg
<anon987321>how can i use my ffmpeg?
<leoprikler>anon987321: Give it a custom name after inherit
<leoprikler>or install it directly from the file (`guix package -f`)
<anon987321>how do i give the name after inheriting?
<leoprikler>(inherit <pkg>) (name "my-ffmpeg")
<jonsger>anon987321: with (name "ffmpeg-personal")
<anon987321>oh okay
<anon987321>thanks :)
<anon987321>yeah, it works, thanks :D
<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>as in combined source or as in fallback?
<truby>combined source
<leoprikler>yes
<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
<leoprikler>hmmm
<leoprikler>would it be possible to use the clang source as input, then?
<truby>the thing is they don't support being built separately, if you build them you have to be building clang, and they have to be installed next to the related clang binaries
<leoprikler>and add an 'unpack-clang after 'unpack?
<truby>so I'm not sure how you would make it a separate package (which I suspect is why other distros don't bother)
<leoprikler>so in theory we could not even make them a separate output?
<leoprikler>would they work if you had symlinks to the built clang in the output directory?
<leoprikler>i.e. clang-extra/bin/clang -> clang/bin/clang
<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?
<truby>yeah, you can't
<truby>unless you still had your dirty build tree hanging around
<leoprikler>Hmm...
<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
<leoprikler>that would work too
<str1ngs>s/our/or
<leoprikler>assuming the tools can be separated into an extra output
<str1ngs>in most case there are make target for that
<str1ngs>though clang uses cmake?
<leoprikler>I think, clang just builds the tools into the output directory if the sources are given
<str1ngs>maybe its just a matter of defining extra output prefix
<str1ngs>also I'm not a fan of hiding packages
<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.
<raghavgururajan>Folks! I get this error (https://bin.disroot.org/?af63bbb178f80427#CaS7HtSPe1s3oGsmkF3Lj3rA9k85Q2ovPMhzru6GkGwF) while building a package. I am not able to understand the error. I know it has something to do with exiv2, but it is provided as input. Not sure what went wrong.
<truby>I don't really have an opinion or otherwise on hiding, other than "it's what gcc does"
<truby>leoprikler: clangd is wanted by a lot of text editors these days. It's the main reason I want the package :)
<roptat>raghavgururajan, your paste needs a password?
<raghavgururajan>what? no
<raghavgururajan> https://bin.disroot.org/?673f6513a47590d8#BhyYN2NgvyvTWbQsRFJawfngby7ZdHnS9keQGKwDmPn3
<raghavgururajan>roptat what about now?
<leoprikler>Most text editors aren't Emacs, so I personally do not care :)
<roptat>it's working now
<raghavgururajan>awesome!
<leoprikler>but yeah, these editors would need the "extra" output of clang-toolchain
<roptat>raghavgururajan, my best guess is that you're compiling with an incompatible version of exiv2
<roptat>raghavgururajan, https://gitlab.gnome.org/GNOME/gnome-color-manager/issues/4
<raghavgururajan>roptat Ah I see. Thanks.
<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
<leoprikler>I think you misunderstood how outputs work
<leoprikler>outputs are built with the same package, but are installed in another directory
<leoprikler>see e.g. glib and glib:bin
<leoprikler>when you install an output and have already built the main package you just get the output
<leoprikler>perhaps if you're having network issues, you might get substitutes for one and not the other and then need to build
<leoprikler>but I doubt that's a common case
<truby>oh right so the outputs always get built, but just don't get installed unless you ask for them?
<leoprikler>yep
<truby>well that sounds ideal then. But we still have to work out how to determine which libs/bins come from tools-extra and which come from the core
<anon987321>hmm
<leoprikler>indeed
<anon987321>i inherited the ffmpeg package
<anon987321>and added "--enable-opencl" to the configure flags
<anon987321>and opencl-headers and ocl-icd to the input
<anon987321>now when i try to guix pull, i get https://0x0.st/z6IK.txt
<anon987321>this on the bzcat log
<leoprikler>you're missing fontconfig somewhere
<leoprikler>perhaps this is in the file with your ffmpeg package?
<leoprikler>(are you using a channel here?)
<anon987321>yes, i made a local channel with file://
<anon987321>that's weird, if i remove the opencl stuff it doesn't complain about fontconfig
<anon987321>and fontconfig is in inputs
<raghavgururajan>Is there a to directly view the build log file in a single command from terminal?
<raghavgururajan>*a way
<anon987321>i do bzcat logfile
<raghavgururajan>I usually copy to someplace else, then extract and then view.
<raghavgururajan>anon987321 Ah! so is bzcat a command?
<leoprikler>truby: Looking at clang, it appears you can separate the tools from the objects in installation
<leoprikler>this would however also exclude non-extra tools
<leoprikler>is that worth it?
<leoprikler>(ah, wait, that's for llvm)
<anon987321>yea raghavgururajan
<truby>leoprikler: yeah, including "clang" because I think it just separates the libraries and everything else
<raghavgururajan><anon987321> Thanks so much
<anon987321>:)
<raghavgururajan>Folks! What is the difference between using module (guix buid-system gnu) vs (guix build gnu-build-system) ????
<leoprikler>one is a build system, one is functions associated with it
<raghavgururajan>leoprikler I see. So I used the former. But I am getting error about missing autoconf and automake. They are already part of gnu-build-system right?
<leoprikler>they should implicitly be included, but apparently aren't
<leoprikler>afaik you have to add them to native-inputs
<raghavgururajan>Yeah I ended up doing them.
<raghavgururajan>*adding
<raghavgururajan>leoprikler So I have cloned the guix repo via `git clone`. How do I edit the '.scm' files and generate patch from it. So that I can email.
<raghavgururajan>I never used git before.
<leoprikler>If you don't already have emacs and git, use an environment that has them
<leoprikler>Use Emacs to make your changes and don't forget to indent
<leoprikler>Then do `git commit` and enter a commit message that follows the guidelines.
<leoprikler>Rinse and repeat.
<efraim>I personally use vim. Emacs was a bit much for me. But use what you're comfortable with
<raghavgururajan>Oh wow!
<raghavgururajan>So I cannot use git with nano?
<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
<leoprikler>You can do git with nano
<leoprikler>You want Emacs for the indentation rules
<alextee[m]>i use vim and run git commands separaretly, i don't like having too much stuff done by my editor lol
<raghavgururajan>alextee[m] Thanks so much. Btw, to make changes, I manually edit the respective file in 'my_branch' directory with a text editor, right?
<raghavgururajan>leoprikler I see.
<leoprikler>you don't have branch directories in git
<alextee[m]>raghavgururajan: the directory will stay the same, git automatically changes the files when you change branch
<alextee[m]>(but when you create a new branch from another branch obviously no files will be changed)
<jonsger>wingo: any plans for guile to be libgc-8 "compatible"? See https://issues.guix.gnu.org/issue/36811
<raghavgururajan>What I meant was, after doing `git checkout -b my-branch`, say I want to edit gnu.scm file. How do I open and that edit file? Is there a dedicated to command for it?
<raghavgururajan>*edit that file
<leoprikler>no, you just use whichever editor you want
<alextee[m]>raghavgururajan: just use any editor?
<raghavgururajan>Cool!
<rockandska>Hi guix
<anon987321>hey
<rockandska>hi anon987321
<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>just an example
<raghavgururajan>But wouldn't that edit the main file?
<leoprikler>yep
<raghavgururajan>I am confused.
<raghavgururajan>`guix branch` give me 'master' and 'rg'. But I only see one copy of each file.
<leoprikler>because you're always working on the current branch...
<raghavgururajan>If I edit a file, in which branch I am making the change?
<dustyweb>hm :(
<bavier>hm?
<dustyweb>trying to think if there's a way I can move forward cleanly re: https://lists.gnu.org/archive/html/help-guix/2019-11/msg00157.html
<dustyweb>I wonder if I should try running Nix on Guix
<dustyweb>I've never done it
<dustyweb>haven't looked if it's hard to do
<alextee[m]>raghavgururajan: type "git status"
<bavier>dustyweb: oh I see
<raghavgururajan>Thanks
<dustyweb>ah nix-service-type
<leoprikler>oh, there is one?
<leoprikler>hmm, seems to use /nix/store though, so you have to build your packages twice if you want to use them
<raghavgururajan>leoprikler if do `nix install something` where it gets package definitions from?
<leoprikler>tbh I have no idea
<leoprikler>probably some clone of nixpkgs
<raghavgururajan>I see.
<dustyweb>leoprikler: at this point I just need a newer package of something
<dustyweb>I'd much prefer to get all my packages from guix
<dustyweb>but maybe it's not a bad idea to keep nix around for the goofier stuff
***atw` is now known as atw
<pimi>Hi guys
<pimi>I am looking for an advice
<pimi>I am try to do a guix pull
<pimi>and I get
<pimi>building of `/gnu/store/mx1zqa2h4rk49pq873zhzxxfiq1caik1-guix-package-cache.drv': goal destroyed
<pimi>guix pull: error: | | | bind mounting `/dev/full' to `/gnu/store/mx1zqa2h4rk49pq873zhzxxfiq1caik1-guix-package-cache.drv.chroot/dev/full'
<zig>I think patchelf can make the binary useable on guix. Otherwise, you can use a chroot.
<zig>the synopsis of chroot mention: chroot [OPTION] NEWROOT [COMMAND [ARG]...]
<zig>that is you can: chroot /home/dustucloud/newroot/usr/bin/nodejs foobar.js
<zig>oops
<zig>that is you can: chroot /home/dustyweb/newroot /usr/bin/nodejs foobar.js
<zig>where `foobar.js` must be in /newroot. it is probably better, to use an absolute filepath related to (!) /newroot/
<zig>that is something like: chroot /home/dustyweb/newroot /usr/bin/nodejs /home/dustrycloud/src/javascript/project/foobar.js
<zig>and mount --bind /home/dustyweb/ to /newroot/home/dustyweb.
<anon987321>hey guix
<anon987321>i had added a channel to ~/.config/guix/channels.scm
<anon987321>i removed it now, but it's still there when i do guix pull
<anon987321>how do i actually get rid of it?
<raghavgururajan>You might have to restart guix service/daemon after making to config file.
<raghavgururajan>*making changes
<zig>dustyweb: to get a debian rootfs, you can use guix package -i debootstrap.
<bavier>no, a user's channel config shouldn't affect the daemon
<anon987321>i tried restarting the daemon too
<elais[m]>Do guix gc and pull again
<raghavgururajan>bavier I see.
<elais[m]>Is the channel you added and removed the default guix channel by chance? Or is it included in channel dependencies?
<anon987321>i think it's actually just the pull news
<elais[m]>So it did get removed?
<anon987321>yeah, i think it did actually remove it
<anon987321>just got confused with the message
<anon987321>when i added the channel, the message appeared
<anon987321>so i thought it was from that channel
<anon987321>but maybe the main channel also updated at the same time
<bavier>it would, yes
<zig>systemd vs. docker: https://lwn.net/Articles/676831/
<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".
<raghavgururajan>Ah I got it now. All good.
<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.
<alextee[m]>is there an easy way to try the hurd?
*raghavgururajan is hyper-focusing on getting as many gnome packages as possible
<ArneBab>zig: systemd trying to take over another infrastructure, risking to make them less secure in the process. I’m unsurprised :-/
<ArneBab>alextee[m]: now with Guix, but there is debian hurd: wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz; tar xf de*hu*gz; qemu-system-x86_64 -hda de*hu*g -m 1G # see https://www.draketo.de/english/free-software/howto-hurd-140-chars
<raghavgururajan>> ArneBab‎: zig: systemd trying to take over another infrastructure, risking to make them less secure in the process. I’m unsurprised :-/
<raghavgururajan>Which infrastructure?
***ChanServ sets mode: +o lfam
<anon987321>life's sad when you can't run hurd on bare metal
<alextee[m]>ArneBab: thanks
<ArneBab>raghavgururajan: docker
<raghavgururajan>I wonder why there is not much development in hurd when compared to hurd.
<raghavgururajan>ArneBab Ah I see.
<ArneBab>anon987321: but you can run Hurd on bare metal. It’s just easier with qemu
<raghavgururajan>*when compared to linux
*raghavgururajan needs to sleep xD
<ArneBab>that’s because for the Hurd there are a handful of people hacking in their free time
<ArneBab>one of the reasons: https://www.gnu.org/software/hurd/community/weblogs/ArneBab/what_we_need.html
<alextee[m]>i wish the hurd had more active development. i would be interested in helping
<raghavgururajan>ArneBab `guix container` is/will be better than docker :-)
<raghavgururajan>ArneBab thanks for the link
<raghavgururajan>I will be throwing linux out the window as soon as hurd becomes viable for regular use.
*raghavgururajan hates monolithic design.
<ArneBab>raghavgururajan: do you happen to have low-level-USB-hacking-skills?
<raghavgururajan>ArneBab I am literaly LMAO. I wish I did.
<ArneBab>I’m asking seriously, because that’s theone major missing piece for the Hurd.
<ArneBab>aside from that, there’s much smaller stuff, too. → #hurd
<raghavgururajan>ArneBab I have just started to change my career from Biotechnology to IT. So I have started to learn from smal stuffs.
<raghavgururajan>ArneBab If there is something I can do, I definitely will. Let me subscribe to the mail list and irc channel. If I see something I can do, I will reach to you for advice :-)
<ArneBab>best ask someone on #hurd and maybe have a look here: https://www.gnu.org/software/hurd/community/weblogs/ArneBab/technical-advantages-of-the-hurd.html
<ArneBab>here: https://www.gnu.org/software/hurd/contributing.html
<raghavgururajan>Thanks! I'll have look.
<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
<ArneBab>anon987321: sounds great!
<ArneBab>anon987321: see https://www.gnu.org/software/hurd/hurd/documentation.html and https://www.gnu.org/software/hurd/microkernel/mach/documentation.html
<anon987321>There are lots of basics i need to learn first tho :)
<ArneBab>need to go afk — cu and happy hacking!
<anon987321>hey guix, when modifying the build flags of an existing package (by inheriting to a new one), do i just copy all the #:configure-flags argument, or can i append mine to the original?
<bavier>anon987321: there is a 'substitute-keywords-arguments' form that can be used to append to #:configure-flags; grep the source for examples
<bavier>'substitute-keyword-arguments'
<anon987321>thanks bavier :)
<anon987321>got it working, thanks bavier
<bavier>anon987321: great, np
<anon987321>hmm
<anon987321>it compiled correctly, but using it doesn't seem like the standard (inputs) is used as well as ime
<anon987321>mine*
<anon987321> https://0x0.st/z60W.scm
<anon987321>is there something wrong with the inputs part? it seems to be the same as the others in the guix repos
<anon987321>i mean, not the inputs
<anon987321>the configure flags
<anon987321>sorry
<anon987321>it's only using the ones i added
<anon987321>it's only using vaapi, vdpau and opencl (which i added)
<anon987321>oh, i think i forgot the ,flags in the end of the list
<anon987321>yes, that was the issue
<anon987321>it's working :)
<bavier>anyone else seeing a 'split-string: Wrong type argument: stringp, nil' warning/error from emacs on startup recently?
<anon987321>i had the wrong type argument: stringp, nil a few times
<anon987321>all-the-icons was causing it
<anon987321>had to disable all-the-icons for dashboard.el until they pushed an update
<bavier>anon987321: hmm, interesting
<bavier>I don't have that package installed
<anon987321>try updating your packages
<bavier>only package installed is idris-mode, and removing that didn't help :/
***ChanServ sets mode: +o lfam
<gnutec> https://www.gnu.org/education/education.html
***dftxbs3e_ is now known as dftxbs3e