<raghavgururajan>Henselierung, nckx and leoprikler: youtube-viewer uses youtube API and requires google account. straw-viewer uses invidious API. pipe-viewer parses youtube website directly instead using youtube-api, so no google account required, and had fall-back for invidious API.
<ekaitz>civodul and efraim : I want to start to port Guix to RISC-V because I want to make some tests of other things I'm porting and I don't have the chance to run environments... (tar bootstrap binary not found)
<ekaitz>I've been taking a look to the files, looks like bootstrap.scm has more or less everything I need, am I right?
<pineapples>I'd like to define my own *.patch files in a package definition only found in my $GUIX_PACKAGE_PATH, but I don't know how to enable Guix to find them since a directory structure is different from that it expects ("/custom/gnu/packages/patches/", not /gnu/packages/patches/).
<yoctocell>roptat: ah, cool, looking forward to that :)
<dstolfa>leoprikler: yeah, i agree it's a pretty toxic attitude for many companies, but i don't want to give the wrong impression. i work at a research university and am not forced to do that, i just choose to do that because i enjoy the work i do :P
<zap>in modern business setiing your company gives you a laptop and locks you to it
<leoprikler>yeah, I think the people working at our TU also do lots of stuff by laptop
<leoprikler>they've also inherited parts of that laptop lock-in stuff modern businesses do, at least last time i checked
<dstolfa>we don't really have any laptop lock-in here really
<dstolfa>i'm running guix on my laptop with linux-libre and some customization on the laptop itself
<leoprikler>when I was working as an intern some years ago, we've had a share of Linux machines (I guess they were mostly Ubuntu) and I also did some work on my personal laptop
<leoprikler>whereas at least some of the others had uni-sponsored MS machines.
<leoprikler>well, I think the manufacturer was Lenovo, but the operating system was the least free of them all :)
<dstolfa>yeah, here we basically have a datacenter that runs whatever is needed for $WORK and the desktops/laptops can be managed by sysadmins if you choose so, but you can run anything you want if you are happy to manage it yourself
<nckx>No, that shouldn't fix it, you seem to have run into a genuine but hard-to-reproduce bug.
<nckx>It's been a while since you've submitted a bug report, don't you agree?
<dstolfa>i'll try a clean re-run with a clean clone, if that triggers it i guess that time will have to change in not-so-long-ago
<nckx>If it succeeds now I think you just got lucky this time. All should be contained in that /gnu/store/xa6dcd5r93plmjfqk3ygqm2p5zf32g1c-gnutls-3.6.16.drv hash, the build environment doesn't care about your feelings or local checkout.
<apapsch>I'd put hacking in the guix repo between your 1st and 2nd point. It's a bit more involved than invoking one command, but less involved than the custom module as all structure is already there and you just have to find your spot
<char> Does anyone know how to fix broken adwaita icons on gnome?
<nathan_>zhu_zihao: I really liked your approach. From what I understand, I have a manifest file I can keep on git, and after running guix package -m texlive.scm it will install all the packages in my current profile?
<nathan_>if anyone is following my quest: I noticed that I did not have to create a new manifest, nor clone guix. The file obtained from `guix edit texlive` has all the packages definitions. I added the one I want (subfiles) as an input for texlive-base and placed "texlive-base" at the end of the file.
<roptat>in that case, it defines what's installed for everyone on the system, in addition to how it boots and services
<roptat>users can access these packages, but they can also install their own packages
<dstolfa>well, you can manipulate sexps since they're just data right, and they can be evaluated anywhere in almost any context, but in that context you may not be able to infer the type of everything in the sexp in a decidable way because it'd just reduce to the halting problem
<The_tubular>Got it, I'm trying to remove a bit of crust in %base-package
<roptat>dstolfa, oh you mean if you want to execute the sexp as code?
<The_tubular>And reading what package is in %base-pacakge I thought lots of those were in gnucoreutils
<roptat>The_tubular, mh... what do you have in mind?
<roptat>there's a package for coreutils, the other packages are not part of coreutils
<The_tubular>I mean, there's like 3 text editors and wireless tools
<roptat>oh, yeah, you can remove anything you don't want to have
<The_tubular>And a few other things I don't need installed on most of my machines
<roptat>dstolfa, do you know any system that could be helpful in that case?
<nckx>The_tubular: Then remove them from %base-packages using (rnrs lists)'s remove procedure, or (less tediously) by removing %base-packages entirely and specifying (packages (list a mere handful of packages you actually want)).
<dstolfa>roptat: unfortunately in general, such an algorithm doesn't exist, because if it did then you've solved the halting problem (and in turn you have an unsound logic since you've just proven completeness). however, it would be a cool research problem to identify how one could add gradual typing to guile in a way that can handle sexps at least in some cases and perhaps warn or automatically add runtime tags to
<dstolfa>but i would encourage you to pursue it further if you find it interesting, because there are probably a lot of cases you can deal with and others you can add runtime tags to check that the value is in whatever your semantic type set is
<dstolfa>it would add overhead, but maybe that's acceptable at least in debugging scenarios
<roptat>definitely, camlboot starts with a guile implementation :)
<leoprikler>speaking about typed guile, I think tohoyn (frequents #guile) does Theme-D
<dstolfa>ML is quite interesting because it's essentially the basis for any HOL implementation, so having a bootstrappable thing that implements a HOL kernel which can in turn be verified on paper would be really helpful when hitting bugs which are now hard to reproduce potentially across systems
<daveed>leoprikler: I just did printenv in the tty, in my wm, and for the flatpak program with and without guix set up for the user. With guix, it just added guix stuff to the PATH, XDG_DATA_DIRS, and INFOPATH variables and then added GUIX_PROFILE, GUIX_LOCPATH, and EMACLOADPATH.
<daveed>For the flatpak though, the only difference was the prepended INFOPATH and the new EMACSLOADPATH. XDG_DATA_DIRS remained unchanged because flatpak creates the variable itself in the sandbox.
<zap>drakonis: I the latest release is 3.0.7 Or you're talking about the release itself?