IRC channel logs

2021-02-25.log

back to list of logs

<pkill9>is there a way to stop guix reconfiguring a machine that hasn't changed?
<pkill9>guix deploy i mean
<pkill9>because it's recofniguring multiple times
<jgart[m]> jackhill xmpp bridge address for the room is #libremiami#matrix.org@matrix.org
<pkill9>is it bad practice to use the same signing key for multiple machines?
<jackhill>jgart[m]: great, I'll see you there.
<pkill9>since when I clone the snapshot it will have the same signing key for each one
<pkill9>i keep thinking I've done something and then it turns out I haven't
<jgart[m]>guix packaging livestream web viewing link: https://tmate.io/t/ro-e2JcV5UDc4chzzngsHGFjWMz3
<jgart[m]>Just keeping the server warm until we start 🔥
<pkill9>in the guix manual under 'guix deploy', does the 'coordinator' refer to the system deploying to the remote host?
<jgart[m]>new link https://tmate.io/t/ro-DCbtGZ4svUtqMGLskpSpEZjWv
<pkill9>can the guix offloader have the machines it offloads to download what it needs itself, instead of having the machine offloading from upload them?
<pkill9>also is there any reason not to have a machine deploy to itself?
<pkill9>it would be good if you could specify services on a remote machine for the guix deploy configuraiton
<pkill9>I am sold on using guix for webserver
<pkill9>i moved domain to a new IP address, added a subdomain including adding ssl certificate, and I didn't need to know how to configure nginx or certbot
<lfam>That is pretty nice
<pkill9>is there a way of adding a manually written block to nginx, as the 'file' field makes it ignore all the server blocks according to the manaul
<pkill9>manual*
<xelxebar>pkill9: Something other than a server-block or upstream-block?
<pkill9>well, it's a server block, but I want it to redirect instead of serve pages
<pkill9>i want to do this https://stackoverflow.com/questions/26801479/nginx-redirect-all-subdomains-to-main-domain
<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 guix-patches@gnu.org for code review :)
<pkill9>well I managed to add that redirect of all subdomains
<lfam>Thanks for that jgart[m] :)
***iyzsong-- is now known as iyzsong-w
<raghavgururajan>lfam: Would you be able to review and push #46584? :)
<gnutec>Here to say that there is a emacs package to play chess in emacs and works perfectly. :-)
<gnutec>Because the xboard doesn't work.
<gnutec>But gnome-chess is fine and small too. But chess, from GNU emacs, is even small and fast.
<jgart[m]><lfam "Thanks for that jgart :)"> lfam: Thank you! Here's the asciinema recording from last night's meetup: https://gitlab.com/libremiami/guix-packaging-meetup-asciinema-recordings
<jgart[m]>Feel free to search it with $EDITOR, ripgrep, etc... or in an asciinema player
<ss2>hello!
<civodul>Hello Guix!
<janneke>hello civodul :)
<jlicht>o/
<cbaines_>marusich, dftxbs3e some more wip-ppc64le revisions have been processed https://data.guix-patches.cbaines.net/repository/2/branch/wip-ppc64le
***cbaines_ is now known as cbaines
<cbaines>one succeeded, but the latest one failed, I think while trying to build guile for the channel instance derivation
<abcdw>hi guix o/
***langdon_ is now known as langdon
***jpoiret8 is now known as jpoiret
***penguwin5 is now known as penguwin
***sneek_ is now known as sneek
***raingloom_ is now known as raingloom
<leoprikler>Hi Guix, Guile recently seems to warn about 'setlocale LC_ALL "" failed with system-error: (setlocale ~A (Das Argument ist ungültig) (22))'
<leoprikler>What's wrong here?
<leoprikler>or is this something I did wrong and should ask in #guile
<civodul>leoprikler: hi! setlocale throws to 'system-error (with EINVAL) when the requested locale is not supporte
<civodul>+d
<leoprikler>So I suppose that's due to a recent glibc change in which I've skipped rebooting?
<civodul>dunno, how did you get that warning?
<civodul>is it from the 'guix' command?
<leoprikler>Hmm, it seems to be a problem with the wisp package.
<leoprikler>guile --language=wisp hello.w prints that
<leoprikler>whereas normal guile doesn't
<civodul>weird
<leoprikler>okay, yeah, wisp is borked
<leoprikler>they call (setlocale LC_ALL "foo"), which will alway fail
<civodul>literally "foo"?
<leoprikler>literally foo
<civodul>ah, interesting :-)
<PotentialUser-86>Hello!
<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 :-)
<civodul>heh
<mothacehe>I'm still having some crashed that I suspect to be related to switch to the message API, but let's see!
<mothacehe>*crashes
<civodul>crossing fingers
<soheil>PotentialUser-86: Yes, that's right
<soheil>PotentialUser-86: I hope they will be packaged soon
<mothacehe>civodul: do you think it would make sense to add an "extra-modules" argument to "open-inferior" so that one can use extra Guile modules within the inferior?
<mothacehe>(my idea is that I could simplify the Cuirass evaluation process if I was able to call a Cuirass procedure from the evaluation inferior to register jobs)
<rekado_>leoprikler: that’s why in the GWL I’m not using the wisp reader directly, because the foo call will always print a warning.
<rekado_>it has already been fixed here: https://hg.sr.ht/~arnebab/wisp/rev/10edeaf387a6f32af224cd94082228055b475174
<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>ifulsoup4 -- jupyter notebook
<rekado_>prittstick: perhaps you’ll also need “python” itself in the environment to benefit from the search path configuration
<rekado_>the search path specification is attached to the Python package and it will only be used when that package is explicitly added to the environment
<prittstick>Yes! That worked! Obvious in hindsight!
<prittstick>guix environment --ad-hoc python jupyter guix-jupyter python-beautifulsoup4 -- jupyter notebook
<prittstick>Thank you very much. Hole in one :)
<leoprikler>If that ever becomes too much typing, you can also write a manifest for it 😉️
<prittstick>Hmm need to read up on manifests...
<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.
<roptat>pazho, oh indeed
<pazho>rotpat, Thanks!
<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!
***rekado_ is now known as rekado
<andreas-e>paulj: This is in the libx11 package.
<andreas-e>There was discussion about an interface to searching package contents, but I do not know what the state of affairs is.
<andreas-e>In general, you could also try this command:
<andreas-e>find /gnu/store -name Xlib.h
<andreas-e>In my case, it returns
<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
<andreas-e>the file /gnu/store/4ildmh169dixyn05mlgjz07x4d2hcq2g-libx11-1.6.A/include/X11/Xlib.h
<andreas-e>among others, so you see the package name.
<paulj>That's a good tip - thank you.
<roptat>paulj, your package builds here
<sertified>rekado_: I don't know how to list failed services using Shepherd
<sertified>rekado_: And I don't know how to run through system logs
<paulj>Looks like it was a schoolboy error - I had added the inputs expression, but not saved it before running the pull command again!!
<rekado>the Shepherd is pretty bad at handling logs — if it does that at all
<pkill9>is there a way to pipe the config text into guix deploy?
<rekado>sertified: you can list services with “herd status” (as root)
<pkill9>currently I copy the file over but, I would like it to be even more stateless
<pkill9>in fitting with guix
<paulj>Thanks andreas-e and roptat : It has now built, and I can work on understanding why it isn't displaying anything (definitely not a guix issue)!
<civodul>mothacehe: looks like there are troubles with the postgres service: https://issues.guix.gnu.org/46737
<mothacehe>civodul: I just replied :)
<civodul>cool :-)
<mdevos>Tip to improve chromium performance: disable ‘use hardware acceleration when available’
<mdevos>(chromium://settings/, under ‘Advanced’)
<mdevos>now chromium isn't maxing out a CPU anymore ... Perhaps this option should be disabled by default, as ‘acceleration’ doesn't actually accelerate anything?
<rekado>this seems… a little backwards
<rekado>is this a bug?
<mdevos>a bug in chromium. Disabling the option only work-arounds the problem, but my laptop doesn't have tons of RAM, and building chromium takes way too long, so I'm not going to debug this
<mdevos>The closest thing I could find to a bug report is https://support.google.com/chrome/thread/20610408?hl=en
<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?
<abcdw>srn: Ask them.
<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>Hello abcdw, thanks for the response
<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?
<abcdw>srn: guix environment --ad-hoc cifs-utils , after that you will be able to use sudo mount.cifs -o SOME_FLAGS_HERE If you want it to add to your system config, it's almost the same as for any other file system: https://guix.gnu.org/manual/en/guix.html#Btrfs-file-system
<andreas-e>Personally I install everything manually, but the fashionable thing to do is to use a manifest for the user profile.
<srn>Use a manifest? Can you expand on that please?
<srn>abcdw: What about a secrets file with your username and password?
<andreas-e>A file describing your user profile. It should be explained somewhere in the documentation...
<srn>I would like to have the shares load at boot and not on the fly
<srn>Would I set that up in Options I guess yes?
<abcdw>srn: The simplest declarative approach for installing software in user profile is to use manifest, there are some other emerging solutions like https://framagit.org/tyreunom/guix-home-manager and https://sr.ht/~abcdw/rde/, which probably not very usable for wider audience yet.
<andreas-e> https://guix.gnu.org/manual/en/guix.html#profile_002dmanifest
<srn>Very interesting. Thank you for the assistance
<abcdw>srn: You can store user/pass in special file somewhere on your filesystem and specify it via options, which unfortunately isn't very reproducible, but easy to do.
<srn>abcdw: Yes thanks I guess I missed that in the manual when looking earlier. I don't use btrfs so!! Thanks
<abcdw>srn: link to btrfs chapter is just an example for defining mount points declaratively in system config, you can change btrfs to cifs and provide proper options and it should work.
<jlicht>How could I register a "time-machine" guix as a gc-root?
*dongcarl would like to know the answer to jlicht's question as well
<srn>abcdw: Yes I will try that. Thank you
<jlicht>after rebuilding the same pinned guix (+ channels, so my own fault :D) for the fifth time this week, I started hoping there might be a better way
<abcdw>jlicht: guix pull -p ~/.guix-tmp-prof
<abcdw>More preciesly guix pull -C channels.scm -p ~/.guix-tmp-profile
<jlicht>abcdw: thank you!
<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
<dongcarl>abcdw: Thank you!
<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
<lf94>But nodejs-10.x works fine
<lf94>Just wondering the direction I need to go.
<dongcarl>civodul: Does the Guix Data Service already have something somewhat similar to what I want?
<jlicht>lf94: what is X in 12.x?
<lf94>20
<lf94>Specifically I'm trying to package 12.20.2
<dongcarl>abcdw: That is true, it seems like I want a lot of customized things so... I should probably write more guile :-)
<lf94>That's the last release of that LTS
<lf94>I need it for work
<lf94>I tried the other day but I failed; I went back to using nvm.
<lf94>Obviously I'm going to keep trying; I think what guix offers is much better.
<lf94>I just can't spend a lot of time on this...
<civodul>dongcarl: yes, except that it can't take a user-provided manifest; it can only compare the whole package set between two revisions
<civodul>at the package level or at the derivation level
<dongcarl>Okay got it
<civodul>so you'd need to write a client that interacts with the Data Service
<civodul>maybe cbaines has ideas
<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.
<civodul>oh i see
<jlicht>lf94: I understand your frustration, but we use exactly the same commit as upstream o.O
<civodul>dongcarl: for now you could look at URLs like this one: http://data.guix.gnu.org/compare?base_commit=25f00a2e443685bda2556aa18ab59df4be698796&target_commit=3c548c3e0eade12d3e86b1201dbd95863ca64ea7
<lf94>jlicht: ?
<lf94>jlicht: I'm not even upset :) Just confused :DD
<lf94>You can't be upset with this stuff.
<srn>For a cifs share what do I put in the device section?
<dongcarl>Interestingly, I can't compare 2 commits which are both on master: http://data.guix.gnu.org/compare?base_commit=a099685659b4bfa6b3218f84953cbb7ff9e88063&target_commit=95aca2991bbc622c7b07c2f404681dde60fd830d&locale=en_US.UTF-8
<lf94>jlicht: are you witnessing the same issue?
<jlicht>lf94: I'm hoppin on ye olde time-machine to see if there was a different situation before the update I pushed to http-parser
<civodul>dongcarl: i think the issue is that the commit must have been processed by the service
<dongcarl>Ah!
<lf94>jlicht: o7
<srn>its not a uuid and not a device-by-label
<civodul>so either it hasn't been processed yet, or it's a commit in between pushes
<jlicht>lf94: do you have some logs on a paste service, by any chance?
<lf94>none
<civodul>dongcarl: ↑
<lf94>it just complained about http-parser
<lf94>jlicht: it will also complain about a test
<lf94>jlicht: I just copied the node definition and removed the test removal
<lf94>(it tries to delete-file on a test which doesn't exist anymore)
<dongcarl>civodul: Right, the one that fails (according to the UI) is the base one, which is the v1.2.0 tag. I presume that one wasn't processed
<lf94>jlicht: we can take this to PM if you want
<lf94>less noise
<civodul>dongcarl: ah that's annoying, we'd have to check with cbaines what the exact problem is
<dongcarl>Sounds good :-)
<cbaines>civodul, dongcarl it's not necessarily a problem, but data.guix.gnu.org is currently configured just to track the master branch
<cbaines>maybe tracking the version-* branches would be useful though
<dongcarl>cbaines: I think both of my commits are on master though
<civodul>oh i see, thanks cbaines
<dongcarl>I specifically chose the v1.2.0 commit that's on master rather than on the version-* branches
*dongcarl doublechecks
<cbaines>dongcarl, data.guix.gnu.org more tracks states, not commits, so the master branch would have had to been pointing at that exact commit at one point in time
<dongcarl>cbaines: Oh I see!
<dongcarl>So if a push has that commit "buried", that commit will not be processed, right?
<cbaines>the reason for that is mostly practical. It would require a lot more time/resources to process information for every single commit, rather than just every state for a branch
<cbaines>dongcarl, yeah
<dongcarl>cbaines: Thanks for the explanation, that makes a lot of sense honestly :-)
<cbaines>not a lot of thought went in to this specifically, but as I say, switching to process every single commit would be a big change in the resource cost and performance
<dongcarl>Oh of course, I don't think it'd make sense :-)
<cbaines>lf94, on node and http-parser, http-parser doesn't look to contain pkg-config metadata, maybe that matters?
<lf94>cbaines: jlicht is on it :)
<abcdw>srn: https://lists.gnu.org/archive/html/help-guix/2018-01/msg00052.html
<cbaines>civodul, while it's being discussed, would tracking the version-* branches be useful? I'm not quite sure how they're normally used, or why they're kept around
<srn>abcdw: Thanks I will look into that
<civodul>cbaines: sure we can track them; they're used while preparing the release and to fix typos in the manual afterwards
<dftxbs3e>hello! :-D
<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)
<civodul>neat
<mdevos>do I understand correctly the manual should eventually be split in many .texi parts?
<mdevos> I'm writing a section on how to define new substituters (I'll be able to send a patch soon I think)
<mdevos>and I'm wondering if I should create a separate .texi for the section
<civodul>mdevos: it would be nice to have one .texi file per chapter
***andi^ is now known as andi-
<civodul>been too lazy to do it so far :-)
<dftxbs3e>civodul, how do we search the entire manual with info then?
<civodul>mdevos: writing new substituters?
<civodul>dftxbs3e: same; mdevos is just talking about the source files
<mdevos>... the section I'm writing isn't really a chapter, only one section of 50 .texi lines
<dftxbs3e>civodul, hmm I thought C-s only searched a single file
<civodul>C-s searches the whole manual, no matter how .info files are split
<dftxbs3e>or .texi is compiled to a single other file
<dftxbs3e>Okay, somehow for me it can't search all manuals from the index info or Emacs generates though!
<mdevos>civodul: not yet, I'm preparing some infrastructure first
<civodul>i'm asking because i removed support for multiple substituters in the daemon a while back :-)
<civodul>there's only one substituter now
<mdevos>I think I use different terminology
<civodul>could be :-)
<mdevos>to me, HTTP/S, IPFS and GNUnet would each have their own substituter, but there's still only one guix/scripts/substitute.scm
<mdevos>the patches I'm writing should be ready (including tests), modulo some documentation bugs, and ...
<mdevos>the IPFS substituter (wip-ipfs-substitutes) doesn't return a port to a nar, but rather directly writes the store item
<civodul>ok
<civodul>i'm not sure there's much to document at this stage, though
<civodul>because there's just HTTP(S)
<civodul>but discussing how to get there would certainly be nice
<mdevos>Let me commit the latest changes & push to private repo ... (will send to mailing list later)
<civodul>great, thanks!
<pineapples>o/
<mdevos>civodul: here it is: https://notabug.org/mdevos/guix-gnunet/src/download-hooks0/doc/substituters.texi
<mdevos>I'll be back afk, for an hour or so I think
<mdevos>I'll be afk, for an hour or so I think
<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...
<marusich>e.g. https://data.guix-patches.cbaines.net/compare?base_commit=38283f5bdb598db16e9556552a9e97d27ccf4fa6&target_commit=b22dcb24207022d9a716893836578e96f4b580a1&locale=en_US.UTF-8
<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
<marusich>sounds good
<dftxbs3e>It is bootstrapping GNU Guile now
<marusich>I'll make the commit and push it upstream once I double check it on my end, probably later today
<dftxbs3e>I can also do it :-)
<marusich>that works!
<marusich>i'll let you do it then; i need to focus on some other things right now, anyway
<marusich>thank you.
<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?
<raghavgururajan>Hello Guix!
<mdevos>thomassgn: the guix.info domain shouldn't be used anymore, it's guix.gnu.org now I think
<rekado>what makes you say that ci.guix.info seems unresponsive?
<rekado>it doesn’t respond to pings
<rekado>that’s on purpose
<rekado>we no longer use the guixsd.org domain
<rekado>the official substitute server is ci.guix.gnu.org
<mdevos>rekado: ... why doesn't it respond to pings? Is there a reason not to respond to pings?
<rekado>the firewall of the data centre where it’s hosted blocks icmp
<rekado>this is not my decision and I don’t feel strongly enough about this to ask anyone to change it.
<mdevos>ok, I was just wondering whether it was a conscious choice by the admins
<mdevos>(the admins of guix ci infrastructure I mean
<mdevos>)
<zimoun>civodul: the recent set-grafting introduced by db45712a67 seems to break “guix graph”.
<rekado>mdevos: no, it’s not our decision.
<rekado>but I’m bringing it up with the network people anyway, because I wonder if it might be related to occasional packet loss
<mdevos>rekado: could be. ICMP is used for signalling packets were/would be fragmented, after all (not sure about the details)
<rekado>yeah, it never occurred to me that there might be a relationship here, so I’m glad this came up
<rekado>see, now I feel more strongly about this than 8 minutes ago
<zimoun>thomassgn: maybe you can try http://bayfront.guix.gnu.org/. It serves few substitutes but it is worth to try “guix weather <your-package> --substitute-urls=http://bayfront.guix.gnu.org/”.
<cbaines>marusich, dftxbs3e I retried processing the latest wip-ppc64le revision, and I think it's going to be successfully processed
<cbaines>once it has been, I'll setup builds for that branch
<marusich>sweet! thank you.
<cbaines>as for that comparison marusich , I guess one of the commits you're using wasn't at the tip of a branch (at some point)?
<cbaines>The Guix Data Service only really processes branch states, rather than each individual commit
<dftxbs3e>cbaines, cool! :-D - FYI the builds wont work but we have a patch that may make them work later (we just merged core-updates in and need gcc-8 for it to work)
<marusich>cbaines, perhaps at the time when the guix data service looked, that commit was not at the tip of a branch, yes.
<adfeno>Hi, how to make minetest_game (subgame of minetest) pick up es (spannish) translation from minetest_game itself ?
<cbaines>dftxbs3e, cool, assuming someone knows about updating that, a commit to do that could either go to the wip-ppc64le branch, or preferably core-updates
<cbaines>I'm not sure about the specific considerations with gcc versions
<cbaines>marusich, you can see the known revisions on this page https://data.guix-patches.cbaines.net/repository/2/branch/wip-ppc64le maybe one of them will be approximately what you want
<adfeno>minetest uses a text file format for mod translations, and it's not gettext's po/mo files, it's actually original string = translation
<adfeno>For some strange reason setting MINETEST_SUBGAME_PATH to the place where subgames are stored in the Guix user profile doesn`t help.
<apteryx>the install script doesn't install any locale package, does it?
<adfeno>apteryx: that is the catch, the mods used in minetest subgames don't use the usual gettext format.
<adfeno>So I don't think this applies.
<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>(it comes from the daemon)
<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. :)
<lfam>cbaines: I am around
<cbaines>lfam, cool, have a read of /root/maintenance/hydra/cuirass-client-certs/ssl-client-certs.org on berlin
<lfam>Ah, it uses client certs. I was wondering where the login interface was
<cbaines>from that file, you ./create.sh ... to create a client certificate
<cbaines>the password you'll need when doing that is also in the file
<apteryx>eh, exposing the SSL paths inside a guix environment container turns out not to be trivial
<lfam>Thanks cbaines. I think I can follow the notes there
<adfeno>j #gdb
<adfeno>oops
<adfeno>forgot slash
<lfam>What goes wrong apteryx?
<apteryx>This for example: guix environment --container --network -E '^SSL.*' --expose=$SSL_CERT_FILE --expose=$SSL_CERT_DIR --ad-hoc wget -- wget https://gnu.org
<apteryx>says: ERROR: The certificate of 'gnu.org' is not trusted.
<apteryx>the user guix profile has nss-certs and the variables referenced set
<apteryx>the wget command works in it
<apteryx>also the -E 'SSL' is sufficient, the above was an experiment
<lfam>Huh
<apteryx>hmm, it works on my Guix System
<lfam>Tricky
<lfam>Use `env` as the "payload" instead of `wget` and compare
<apteryx>ugh, now I seem to remember that wget must be hard-coded to look unter /etc/ssl/certs or something silly
<apteryx>that would explain why it works on Guix System
<lfam>Oh yeah?
<lfam>I thought maybe the symlink reference was broken in the container
<lfam>The package definition of wget doesn't seem to make any special provisions
<apteryx>the doc won't say
*apteryx looks up the source
<apteryx>nothing refers to SSL_CERT in the code, hmm
<lfam>Can also do `guix environment --container --network -E '^SSL.*' --expose=$SSL_CERT_FILE --expose=$SSL_CERT_DIR --ad-hoc coreutils bash wget -- bash` and poke around
<lfam>Within the container:
<lfam>ls -l $(echo $SSL_CERT_FILE)
<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)
<roptat>so it's identical, up to grafting
<apteryx>lfam: yes, there's a long paragraph of comment above this line in our GnuTLS package: "--with-default-trust-store-dir=/etc/ssl/certs"
<apteryx>so anything that uses GnuTLS is going to lookup its certs there
<lfam>Hm
<apteryx>I keep being bit by that
*apteryx creates an issue to remember fixing taht
<apteryx>lfam: actually I'm still a bit confuse, as I'm not exposing /etc/ssl/certs
<apteryx>to the container, and it works on Guix System
<lfam>Did you enter the container and look at the environment?
<apteryx>oh, nevermind, I expose $SSL_CERT_FILE which on Guix System is /etc/ssl/certs/ca-certificates.crt
<apteryx>so that explains what makes GnuTLS happy
<lfam>Btw apteryx, the new version of QEMU obsoletes your patch building an info manual: <https://bugs.gnu.org/45014>. Would you be interested in updating that patch?
<lfam>I'd like to do this update soon-ish
<apteryx>lfam: That's great! I had submitted it upstream, and they ended up changing a bunch of things that should make it easy to build the info manual now
<apteryx>I can maybe look at this the next weekend
<lfam>Oh, that's good news!
<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 :)
<bone-baboon>lfam: Yes understood.
<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.
<lfam>That's great :)
<bone-baboon>Also last time I checked the guix package manager did not work with Void Linux.
<lfam>Well, Guix welcomes all free software, so consider it a "help wanted" situation
***Server sets mode: +cntz
***MidAutumnHotaru8 is now known as MidAutumnHotaru
***leoprikler_ is now known as leoprikler
<lfam>bone-baboon: dhclient is part of the isc-dhcp packages. And like roptat_ says, there's a service too
<nckx>What the.
<bone-baboon>roptat_: lfam: Thanks
<lfam>You broke it nckx
<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
<lfam>Tricky apteryx
<nckx>pkill9: What I use: https://paste.debian.net/plain/1186969 .
<nckx>freenod plz
***Noisytoot_ is now known as Noisytoot
<bone-baboon>I do not see a `firefox` package.
<nckx>There is none.
<nckx>bone-baboon: Firefox as-is is not FSDG-compliant, GNU IceCat (based on the FF codebase) is.
***capnick is now known as cap
***samis is now known as CompanionCube
<pkill9>nckx: the problem is it uses the certificate of the first server in the list
<bone-baboon>nckx: Thanks
<pkill9>now i'm tyring to create a self-signed certificate for it to use instead
<pkill9>trying*
***dftxbs3e_ is now known as dftxbs3e
<bone-baboon>Seeing the `ungoogled-chromium` I was also expecting to see a `librewolf` package.
<lfam>Yeah, GNU already has IceCat, but we'd probably welcome librewolf too
<lfam>It would nice if <https://guix.gnu.org/machines> transparently redirected to <https://guix.gnu.org/donate>. I like the donate URL, but it's a little on the nose
<roptat_>what's the way to use the current directory as the source in a guix.scm again?
<nckx>I must admit it's not entirely clear to me what you want, pkill9. But cool!
<bone-baboon>I see a package for `rust` but I do not see a `rustup` package.
***bkv is now known as bqv
<pkill9>nckx: i just want it so that if someone access the server in the browser via the IP, they don't see the certificate associated with one of the domains
<nckx>I'd never heard of LibreWolf, bone-baboon. If it respects the free software distribution guidelines, we'd be happy to accept a package.
<pkill9>which by default it is doing
<nckx>pkill9: Ah, I use another nginx trick for that, I think...
<pkill9>it just seems to use the first certificate available it seems
<pkill9>oh, what trick is that?
<nckx>I don't remember, let me se 😛
<roptat_>bone-baboon, not a rust expert, but I think it's either included in the rust package, or it's not useful for guix packaging, so nobody took the time to package it
<nckx>pkill9: All I remember is that it involves a self-signed default cert so it's probably what you're thinking of.
<pkill9>yea
<pkill9>do you know how to generate one?
<pkill9>i tried but it doesn't seem to be working, i think nginx is just trying to use the default cert instead
<pkill9>i don't really know what the point of a self-signed certificate is, lol
<madage>Hello guix! I've been a pull bug on one machine on the last few weeks: https://paste.debian.net/1186968. Searching the mailing list I've found this where ludo hints at a memory corruption issue: https://lists.gnu.org/archive/html/bug-guix/2020-05/msg00670.html
<bone-baboon>nckx: LibreWolf https://librewolf-community.gitlab.io/ like a Firefox version of ungoogle-chromium.
<madage>This happens only on one x86 machine, other guix deploys are able to pull, so I'm inclined to think it's a hardware problem
<nckx>pkill9: Oh, it's because SNI needs to send a cert which would leak the name: https://paste.debian.net/plain/1186972
<nckx>not sure if that *is* what you want after all.
<madage>This machine has been having issues lately.. so my question is: is there a way to rescue this system other than reinstall?
<rndd`>btw, is iptables same in guix like in other distros. i mean, do i need to declare my rules in config.scm?
<jonsger>yes
<bone-baboon>roptat_: I do not see `rustup` as an output for the `rust` package.
<madage>things I've tried: rolling back pull, package and system
<madage>nothing seems to help
<nckx>bone-baboon: Right, but does it link to potentially non-free add-ons etc.?
<jonsger>rndd`: like this e.g. https://gitlab.com/jonsger/jonsger-guix/-/blob/master/config/server.scm#L149
<adfeno>Sorry, connection drop, just now I saw that
<roptat_>bone-baboon, indeed, we don't have it
<rndd`>jonsger: omg 0_o
<rndd`>it's like a dream
<rndd`>but it looks crazy
<nckx>pkill9: I guess you can probe around with ‘curl -H Host:<values you want to block> tobias.gr’ and if it does what you want I can tell you what I did 😛
<rndd`>hmmm, (plain-file )
<nckx>adfeno: Freenode just went mad, not your fault.
<bone-baboon>roptat_: It says " rustup is an installer for
<roptat_>bone-baboon, but is it useful if you can already "guix install rust"?
<roptat_>(and actually select any version between 1.29 and 1.50?)
<adfeno>I still have to configure my account so that my own cert used automatically.
<bone-baboon>roptat_: It says "rustup is an installer for the systems programming language Rust" on https://rustup.rs/. So I guess that would be taken care of by the Guix package manager.
<adfeno>(I'm talking about IRC indeed, there is a method of authentication that uses this)
<nckx>adfeno: Yeah.
<rndd`>jonsger: look interesting, i'm gonna read it. thank you
<nckx>SASL.
<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_>nckx, but we also have cargo
<adfeno>roptat_: see above link
<nckx>roptat_: Yes.
<nckx>roptat_: Same applies.
<nckx>adfeno: ‘unless and only if its being operated using guix import’ -- I don't see what makes guix import FSDG-exempt.
<roptat_>I see
***rekado_ is now known as rekado
<roptat_>guix import is not a distribution?
<adfeno>(I could also stretch that bug from the above link to other packages, but I'm stopping now, and decided to only report and discuss cargo in that issue)
***PotentialUser-62 is now known as noproto
<nckx>Nor is FireFox.
<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
***ba is now known as bandali
<noproto>hey lfam
<lfam>Howdy noproto
<jackhill>also, not all of our browsers disable non-free javascript by default
<lfam>We should talk
<nckx>lfam: We already do.
<noproto>lol
<nckx>Nobody's Wi-Fi working out of the box is the nose. It's already gone and floating away. Bye bye nosie.
<bone-baboon>adfeno: Thanks for sharing that link. Not having cargo available would be a problem for anyone developing with rust.
<adfeno>For example, despite my agenda and job seeking, I'm slowly doing a full review of Mastodon (including dependencies, which amount to circa 45, as far as I have read from the first Ruby gemfile)
<lfam>nckx: Yeah, it's definitely a subjective judgment about how far is too far
<lfam>I don't think we disagree
<adfeno>lfam, nckx: browsers do come with JS enabled, but don;t have repo with which one can install those
<adfeno>dont have predefined reop
<adfeno>repo
<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.
<dftxbs3e>marusich, pushed, it did work
<nckx>jackhill: It's confusing for the same reason: it's abitrary, so there's no real logic to it.
<nckx>adfeno: OK, that was jackhill, not me.
<apteryx>lfam: one last thing; exposing SSL_CERT_DIR/FILE cannot work because they are symlinks
<nckx>Disabling non-free JavaScript is unacceptable.
<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>apteryx: I wondered if that was related
<nckx>Anti-freedom to the maxx.
<jackhill>lfam: I guess I care too much ;)
<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.
<rndd`>let's all reject js \0/
<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>anyway :-)
<adfeno>nckx: I agree.
<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.
<bone-baboon>rndd`: Gopher and Gemini
<dftxbs3e>one just needs to do the work to patch cargo
<dftxbs3e>I looked at it a little
<nckx>adfeno: Right, that's how Guix itself works, and how we generally expect other software to work when possible.
<dftxbs3e>The easiest way would be an environment variable where you can specify a different URL for the crates.io registry
<nckx>E.g. use /gnu/store/.../etc/blah.conf by default but allow overrides.
<lfam>Could it be done for linux-libre?
<lfam>So users could load their firmware?
<dftxbs3e>but patching it cleanly requires some work
<adfeno>lfam: linux-libre: I dont know the internals, but would require rebuilds
<adfeno>As far as I know
<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... ☺
*nckx won't.
<nckx>bone-baboon: That's great!
<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.
<rndd`>bone-baboon: dead technologies =/
<bone-baboon>nckx: https://librewolf-community.gitlab.io/docs/addons/
<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.
<adfeno>and I cant type today
<adfeno>(making too many typos)
<adfeno>bone-baboon: re: express commitment to FSDG: also includes having a bug/issue category for GNU FSDG related issues.
<lfam>I think Guix demonstrates its commitment in just about everything it does
<nckx>Previous (abortive) discussion: https://www.mail-archive.com/guix-devel@gnu.org/msg54673.html
<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>There's an idea
<nckx>ls --install guix
<lfam>Sure, I just want to push back on the idea that we aren't committed just because we lack some detail like a bug category. We already consistently work hard to create a big project
<lfam>Like, Guix is *the* FSDG distro
<nckx>Nobody reasonable can deny that fact.
<lfam>There are other options but this one is for GNU, by GNU
<bone-baboon>I do not see a JS package manager like `npm` or `yarn`. What do people use as an alternative?
<nckx>Guile.
<bone-baboon>nckx: Guile as an alternative to a JS package manager?
<nckx>To JS.
<nckx>I guess they use npm or yarn, but not via Guix.
<bone-baboon>nckx: Do you mean Guile compiled to JS?
<dftxbs3e>GNU Guile can interpret ECMAScript though it's support is limited for now I think
<nckx>Oh, that's true, but my quip did not refer to that. bone-baboon: don't we have npm? I thought we did. It's part of node, is it not?
<rndd`>dftxbs3e: do you have any example?
<dftxbs3e>npm inside node package also has npm default repo left as-is?
<nckx>¯\_(ツ)_/¯
<dftxbs3e>rndd`, https://www.gnu.org/software/guile/manual/html_node/ECMAScript.html
<dftxbs3e>nckx, I don't know if it does, just asking
<dftxbs3e>rndd`, I don't have any more information that that
<nckx>I don't know either.
<dftxbs3e>than that *
<bone-baboon>nckx: Just ran `guix search npm` no npm. Also `guix search node` does not have npm as an output.
<rndd`>dftxbs3e: omg, it works
<jackhill>`guix environment --ad-hoc node -- npm --version` says yes, alhtough I don't know about the default repository.
<jackhill>our Python package has pip3 with the default repository.
<roptat>bone-baboon, npm is part of the "out" output of node
<nckx>bone-baboon: ‘guix search’ doesn't search package contents. Nor do most packages have multiple outputs. It's simply ‘node’.
<roptat>(the default output, that means)
<nckx>guix environment --ad-hoc node -- npm --version
<jackhill>Of course its an old node version, but I think that's just because no one has had a chance to update it yet.
<dftxbs3e>It would be easier to replace default repositories if we had another drop-in replacement that only includes FSDG compliant software, for PyPi, crates.io, npmjs.com, ..
<dftxbs3e>As simple as a mirror with whitelist
<dftxbs3e>Could be done with nginx
<dftxbs3e>or blacklist
<nckx>Yeah, the technical implementation isn't the hard part...
<dftxbs3e>so it's a bit less restrictive to use
<roptat>we could also build these plugins ourselves
<nckx>(I don't think blacklist is an option; the FSDG asks for more commitment than that & new packages pop up constantly.)
<dftxbs3e>nckx, I suppose
<dftxbs3e>packages with proprietary licenses on the various repos are actually rarer I mean
<roptat>instead of a whitelist on addons, we could have a whitelist of license of addons? the default firefox addons page lists the module's license
<roptat>that would allow us to easily reject proprietary addons
<dftxbs3e>roptat, yes would be great but it means there's zero auditing of it being actually true
*roptat had to check four times before finding the correct vowels in proprietary
<lfam>You could say that about any package dftxbs3e
<lfam>The package could even include a free license, and yet the source code had been stolen from its rightful owner and distributed without their permission. We can only do our best
<roptat>mozilla is redistributing these addons under these licenses that allow us to redistribute them too
<roptat>if the license is wrong, we still did our best
<roptat>and we can add a blacklist
<dftxbs3e>sure
<dftxbs3e>license blacklist + additional blacklist
<dftxbs3e>sounds good to me
<lfam>This question came up with Chromium, and we decided that we can only take upstream distributors at their word
<dftxbs3e>could also do that for cargo
<dftxbs3e>and PyPi, and npm
<dftxbs3e>it would actually be easier to use for users
<dftxbs3e>vs removing the default repo
<dftxbs3e>It is likely it wont disturb people's workflow that way
<roptat>yeah, though we'd have to maintain a mirror or something :/
<dftxbs3e>Rare are the people who use nonfree packages from
<lfam>I think we should be careful not to push users away from using GNU Guix any more than we already do
<cbaines_>dftxbs3e, I think you've pushed an unsigned commit to wip-ppc64le
<dftxbs3e>roptat, or just add code inside the package manager itself?
<cbaines_>(which makes the Guix Data Service unhappy at least)
<dftxbs3e>cbaines_, I didnt but master wasnt merged in
<dftxbs3e>so .guix-authorizations doesnt contain me
<roptat>if you add code to prevent non-free software, that's removing your freedom to use non-free software
<roptat>tricky ^^
<cbaines_>dftxbs3e, ah, OK
<dftxbs3e>roptat, then I can add an environment variable to override
<roptat>and that would be too easy
<dftxbs3e>too easy?
<roptat>like, it's the same with nix for instance: it packages free software only, until you configure it to use the non-free repo
<roptat>(that and a few other stuff, like the kernel, firefox, etc)
<nckx>lfam: Would you have time to merge .guix-authorizations? ☝ I'm not quite confident to do it without re-reading the policy changes.
<roptat>actively providing instructions on how to install non-free software would be against FSDG
<cbaines_>dftxbs3e, hmm, merging master doesn't look trivial, I see conflicts :/
<roptat>so saying "use NPM_ALLOW_NONFREE" to download non-free software, would not work
<nckx>Oh.
<lfam>Sorry, not at the moment nckx
<dftxbs3e>roptat, NPM_NO_LICENSE_CHECK
<roptat>well, that's the same :)
<nckx>Nvm, cbaines_ mentions more work than that.
<dftxbs3e>cbaines_, would need master to merge in core-updates first
<dftxbs3e>then we re-merge core-updates into wip-ppc64le
<lfam>:/
<lfam>It's a reason to rebase instead of merging very early
<lfam>We also used rebases for WIP branches in the past
<lfam>I mean, we always did
<nckx>wip-branches should always be rebased.
<lfam>I was argued down in this case
<lfam>It was desired to merge for some reason
<nckx>Hm.
<cbaines_>marusich, dftxbs3e builds are now happening for the wip-ppc64le branch for both x86_64-linux and powerpc64le-linux
<roptat>so a mirror or proxy is the only solution I can think of
<dftxbs3e>I think we did rebase but marusich some times didnt want to disturb other people working on the branch
<nckx>lfam: That is unfortunate but I missed that discussion.
<dftxbs3e>roptat, proxy then
<pkill9>what guix needs now is a `guix deploy deploy` command
<lfam>nckx: It's in the hands of the mergers now :)
<nckx>dftxbs3e: That's what wip- means.
<nckx>You may be disturbed.
<dftxbs3e>cbaines_, awesome!!
<dftxbs3e>nckx, marusich was trying to be nice with me :-)
<bone-baboon>Has anybody got Guix running on risc-v hardware?
<lfam>The other problem is that, with merging, it's not very clear what is the "new" work on the branch. With rebasing, it's always on the tip
<dftxbs3e>bone-baboon, not as far as I know
<lfam>But there are a million workflows with Git
<dftxbs3e>yes I would've preferred to always rebase but I think we can rebase now and it will put things on the tip?
<lfam>If it were me, I'd recreate the branch and cherry-pick the new commits onto it
<nckx>So it's too late to wipe wip-ppc64le and push a version without merges?
<lfam>And then rebase, going forward
<nckx>I think that's what lfam just suggested too.
<dftxbs3e>It's not too late someone just has to do it
<nckx>Better to nuke it now than have it spread.
<dftxbs3e>I will try
<nckx>Ideally someone familiar with what the hell happened, or I'd try... 😛
<nckx>Thanks dftxbs3e!
<lfam>It's definitely easiest for someone familiar with the work being done
<dftxbs3e>marusich, it would be nice if you did that one though.. because you did the merges and all
<lfam>But, let us know if you need help
<nckx>++
<dftxbs3e>roptat, npm-free.guix.info ?
<roptat>we don't have guix.info anymore, I think
<roptat>but npm-free.guix.gnu.org would work
<nckx>dftxbs3e: Not ours anymore.
<dftxbs3e>roptat, https://hpc.guix.info/ ?
<dftxbs3e>roptat, if that's OK
<dftxbs3e>the proxy could be made to serve nonfree software if manipulated in special ways I think
<nckx>Maybe it's guixsd.org that expired. One of them did.
<lfam>guixsd.org is gone
<nckx>I deleted the mail ♪
<bone-baboon>Guix download page has "GNU Guix System on GNU Hurd" as a virtual machine image. Has anyone got Guix and Hurd running on bare metal?
<dftxbs3e>bone-baboon, yes some people have, on old hardware
<dftxbs3e>Intel Pentium I think
<bone-baboon>dftxbs3e: Is Guix/Hurd installation on bare metal documented?
<dftxbs3e>bone-baboon, not really as far as I know
<bone-baboon>How is the Guix/Hurd bare metal experience?
<dftxbs3e>Bad
<lfam>Experimental
<dftxbs3e>lfam said it better
<lfam>It's a research project in an early stage
<bone-baboon>Are there any other microkernels that Guix has been tested with?
<dftxbs3e>bone-baboon, nope
<roptat>we only support linux-libre and the hurd for now
<bone-baboon>Can I install all my packages using substitutes and then one by one replace them with packages I build from source gradually over time?
<dftxbs3e>bone-baboon, not exactly I don't think so, but you have the "guix challenge" command which allows you to check if your substitute servers give you the same package you'd build yourself
<dftxbs3e>there's also "guix build --check"
<lfam>bone-baboon: Guix is, by default, a build-from-source distro, but it transparently substitutes pre-built binaries when they are available and you have authorized them
<lfam>So, you could start with substitutes, and then later run your Guix commands with the --no-substitutes option
<bone-baboon>lfam: Okay
<lfam>If you like, you can eventually disable substitutes altogether, by removing the build farm's signing key from /etc/guix/acl and / or running the guix-daemon itself with --no-substitutes
<dftxbs3e>bone-baboon, but replacing store items with ones you build yourself is not going to be that easy
<lfam>Since this is "transparent", there is no meaningful distinction internally between things you downloaded and things you built
<lfam>There are some distinctions, but they aren't really exposed in a useful way
<dftxbs3e>if you already substitued something and want to replace it with something you build on your own it is not going to be that easy if that store item is utilized somewhere else already I think
<lfam>dftxbs3e is correct there
<dftxbs3e>if it's not utilized you can just "guix gc" the item and build it with --no-substitutes
<dftxbs3e>guix gc -D /gnu/store/..
<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
<lfam>This kind of thing happens periodically
<dftxbs3e>lfam, on gnutls or others?
<dftxbs3e>gnutls is the only time I've seen it happen
<lfam>It's happened more than once in the years I've been involved. I don't recall if it is always with GnuTLS or not
<dftxbs3e>especially because we are working on powerpc64le-linux we don't meet much of these issues tbf
<lfam>Some people find it upsetting, but it's not any worse than other distros IMO
<lfam>I think that Guix raises people's expectations, which is great! But sometimes things go awry
<bone-baboon>What is the status of bootstrapping Guix?
<dftxbs3e>bone-baboon, full source bootstrap is WIP but works already somewhat
<dftxbs3e>AFAICT
<dftxbs3e>Right now GNU Guix has Reduced Binary Seed Bootstrap which means there's few MBs of binaries to bootstrap GNU Guix required
<dftxbs3e>bone-baboon, https://www.freelists.org/post/bootstrappable/wipfullsourcebootstrap-from-a-357byte-hex0-to-hello
***wleslie_ is now known as wleslie
<dftxbs3e>lfam, on powerpc64le-linux we had to modify gnutls and lz4 that's it
<lfam>Was lz4 a POWER-specific change? Or did it "expire" too?
<dftxbs3e>lfam, parallel testing was enabled but unsupported upstream so it was causing severe non-deterministic test failures
<lfam>Oh right
<lfam>That applies for all architectures, right? Do you know if we made that change on master, too?
<lfam>(We should)
<dftxbs3e>lfam, we did
<lfam>Great
<dftxbs3e>lfam, https://git.savannah.gnu.org/cgit/guix.git/commit/?id=78bbf6c44394c1024e0a369d0d5947e669606248
<lfam>Looks like upstream is taking action on it too
<bone-baboon>dftxbs3e: Thanks for that link.
<lfam>Great work!
<lfam>It's always extra effort to take things upstream, but it benefits everybody
<dftxbs3e>lfam, are they..?
<lfam>I see the upstream author "tagged" the issue yesterday
<lfam>So, presumably they are going to tweak the build system to avoid this problem in the future
<dftxbs3e>ahh..
<adfeno>lfam, nckx, dftxbs3e, roptat: Re: third-party repos: I think we can have instructions on how to add repos, but not recommend specific repos.
<adfeno>Also, instructions on "disable VARIABLE_X to allow all repos" is also problematic, since it means that the third-party repos would already be made available.
<dftxbs3e>adfeno, it's easier to make proxy repos than do this because for example cargo has the concept of a default registry it's not easy to just remove
<dftxbs3e>cargo also has the concept of an additional registry but it's handled specially as well
<dftxbs3e>the easiest is if we proxy crates.io itself filtering out packages that don't declare an FSDG compliant license
<dftxbs3e>and we also have an additional blocklist
<dftxbs3e>in case of reported violations despite license metadata
*bone-baboon smiles and is impressed by Guix
<adfeno>dftxbs3e: Ah, I see, thenk It would be indeed a good thing to do it the way you described.
<dftxbs3e>bone-baboon, :-D great things were achieved!
<adfeno>Also, other free/libre distros might be able to pitch in into the effort.
<dftxbs3e>adfeno, also that way the actual package managers are usable out of the box instead of being unrealistically broken due to freedom issues
<adfeno>… This would also benefit them and the users.
<bone-baboon>I like: the availability of most of the free software I want to use already packaged, the deblobed kernel, the ability to build from source, the experiments with Hurd and bootstrapping.
<dftxbs3e>the only realistic way someone is going to use cargo after we remove the default registry is by patching in the default registry back.
<bone-baboon>I am sure I would find more to like as I use Guix.
<dftxbs3e>For the case of package managers, most people actually only use them for Free Software
<nckx>adfeno: That is correct.
<adfeno>dftxbs3e: luckly, the third-party package-managers provide ways to do that.
<adfeno>Also if the user does want to surrender, they can do guix -S package; change stuff; guix build [transformation to use local definition] package and that is it.
<adfeno>We *dont* need to even give examples on this.
<adfeno>It is already well documented.
<dftxbs3e>adfeno, provide ways to do what?
<adfeno>dftxbs3e: sorry, can you elaborate on the question?