IRC channel logs

2021-01-18.log

back to list of logs

<leoprikler>pineapples: missing emojis are known, you're welcome to try and add them in
<ryanprior>I looked recently and saw that all but one of the workers in Guix's Cuirass CI was idle, while `guix weather` reported that only 93% of substitutes were available. Does that mean tasks aren't being sent to workers in a timely fashion?
<ryanprior>Or is the reporting maybe out of date in one or both places?
<Sharlatan>Hi folks
<Sharlatan>Did anyone pack with buildpack :)?
<Sharlatan>it's a CommonLisp SBCL/CCL producer of "binaries"
***flor_ is now known as flor
<jackhill>Hi, how can I record the channel configuration for my current guix to later pass to guix time-machine? I see that the manifest in my guix pull profiles says that "It cannot be passed to the '--manifest' option"
<jackhill>I guess I'm looking for something like /run/current-system/channels.scm for other profiles.
<jackhill>ah, and now that I've asked, I found it: `guix describe --format=channels`
<ryanprior>jackhill: yay, glad you figured it out! It's also in section 4.1.5 of the Guix Cookbook.
<jackhill>ryanprior: thanks for the cookbook reminder!
***daviid is now known as Guest39344
***Guest39344 is now known as daviid
***lukedashjr is now known as luke-jr
<ryanprior>Hey Guix! I wrote a blog post about what Guix is. It's been described in many ways, but none of them capture for me what makes the project so compelling, so I wrote it as kind of a "missing About Page"
<ryanprior> https://www.ryanprior.com/posts/what-is-guix-really/
<raghavgururajan>ryanprior: Very nice post!
*raghavgururajan considers Guix as 'Distrubution Manager' (Distro = Packages + System)
<raghavgururajan>But ryanprior's term 'Software Deployment System' is growing into me.
<raghavgururajan>civodul: Regarding above, what did you initially think of Guix will be?
<raghavgururajan>sneek, later ask pineapples: Any luck with the fonts?
<sneek>Okay.
<mroh>ryanprior: very nice post! Thank you for writing (and sharing) it!
<ryanprior>Thank you mroh!
<Aurora_v_kosmose>How would one list the files inside a given package? "guix archive" has such an option but I'm not sure how to get the location of the NAR archives atm
<Aurora_v_kosmose>Well, I found some other way by looking into the store.
<brown121407>ryanprior: your "What is Guix Really" article is THE best sales pitch for Guix I ever read!
<mroh>Aurora_v_kosmose: try something like `tree $(guix build -q pkg)`
***daviid is now known as Guest7891
***Guest7891 is now known as daviid
<civodul>Hello Guix!
<jlicht>hey civodul!
<efraim>anyone have luck setting up a new VM using virt-manager while running wayland?
<efraim>sneek: seen vagrantc
<sneek>vagrantc?, pretty sure was seen in #guix 2 days ago, saying: /17/12.
*raghavgururajan also finished packaging Telegram-CLI (#45954) \o/
<jlicht>raghavgururajan: You are working on some amazing packages! Thanks for that!
<raghavgururajan>jlicht: :-)
*raghavgururajan is very *desparate* about Telegram-Desktop (#45721), Nexcloud-Client (#45889), and Telegram-CLI (#45954). 😅
<liltechdude>How to specify library directory in receipe? To build package with CMAKE I do:
<liltechdude>1. `fd luajit.h /`
<liltechdude>2. run cmake with path `cmake .. -DWITH_GTK3=1 -DWITH_LUAJIT=1 -DLUA_INCLUDE_DIR=/gnu/store/1ldb9a0k8hpcizrr8vr427qgsdccd2rj-texlive-union-51265/include/texluajit`
<liltechdude>
<liltechdude>How can I specify LUA_DIR_INCLUDE in receipe?
<liltechdude>
<raghavgururajan>liltechdude: cmake -> "-DCMAKE_C_FLAGS=-
<raghavgururajan>ililtechdude: cmake configure-flag -> "-DCMAKE_C_FLAGS=-L<libdir>"
<liltechdude>raghavgururajan: but how to get <libdir>? Information about this place in documetation?
<leoprikler>you'd typically construct it from your package or input
<leoprikler>e.g. (string-append (assoc-ref inputs "some-lualib") "/lib/lua/...")
<leoprikler>or just "/lib" in some cases
<raghavgururajan>#:configure-flags (list (string-append "-DCMAKE_C_FLAGS=-I" (assoc-ref %build-inputs "foo") "/lib"))
<raghavgururajan>liltechdude, ^
*raghavgururajan + zopiclove = zzZZ
<liltechdude>raghavgururajan: How can I interactive see output from (assoc-ref %build-inputs "foo")?
***rekado_ is now known as rekado
<emacsen>Hi, I have a very dumb newbie qustion. When you build a package, how does guix know which files are what types? How does it know which are executables, which are man pages, which are shared libraries, etc. What is the thing that tells Guix that? Is it in the build system or part of the installer? Somewhere else?
<leoprikler>emacsen: I don't think Guix itself makes such distinctions for the most cases.
<leoprikler>For instance, if you use gnu-build-system, you more or less trust the Makefile and toolchain (Autoconf, Automake, etc.)
<emacsen>leoprikler, then how does it build the profile file and the symlinks within?
<leoprikler>It does a union-build of all packages within, merging bin, lib, etc. into one.
<emacsen>leoprikler, perhaps I'm not explaining the question well. Let me rephrase it. Imagine that I have a new package, "foo" and it has an executable, and a man page, etc. Is guix looking at the package and saying "Ah, a 'bin'- these are the binaries" or is something in the build saying "foo.bin" is "tagged as an executable"
<leoprikler>What exactly is it, that you're trying to package? If it builds everything into one directory and has no concept of installation, then you have to engineer something on your own, that makes sense.
<emacsen>leoprikler, I'm merely trying to understand what's going on a bit under the covers
<leoprikler>Projects with reasonable build systems however, will typically install binaries to $prefix/bin, libraries to $prefix/lib, etc. and guix leverages that by simply setting prefix to $store/<long-hash>-<package>-<version>
<emacsen>leoprikler, let's imagine that I didn't use GNU make, and invented my own programming language and builder. Now I have an directory of files. How does guix know which one is the one to put in "bin"?
<leoprikler>It does not. If you're writing your own programming language, such concerns might be part of your language design.
<leoprikler>Also w.r.t. tooling support.
<emacsen>Okay. So I have my file "foo.bizzzzz" and I (the human) know this is the executable. How would I tell guix that?
<leoprikler>You install it to $prefix/bin?
<emacsen>leoprikler, okay, so what happens is that guix knows by looking at the path. That's what I was asking :) And why I was confused when you said it's all in one directory when built! :)
<leoprikler>It's not, files are wherever your build system puts them.
<leoprikler>I was just pointing out, that Guix has no inherent knowledge about the purpose of a specific file in most cases.
<emacsen>how does the guix-profile get built then?
<leoprikler>Again, by union-building.
<leoprikler>You take all the files in all the bin/ directories and put them into bin/, and so on.
<emacsen>leoprikler, but it doesn't know they're executables, only that there is a name match. Is that right?
<emacsen>but then there are processes that must be run, such as updating the mandb based on what man pages are available, so it must know a bit more
<emacsen>leoprikler, I'm sure I'm frustrating you. I apologize. I'm just reading the g-expressions section of the docs and I'm just a bit confused at it
<nefix>hello! Is it possible to run fuse inside a guix environment? I was able to install the package, but I couldn't make fuse work. Thanks! :)
<leoprikler>nefix: I believe fuse needs to be at OS level.
<jlicht>emacsen: I think you are looking for strict rules, where there are none
<emacsen>jlicht, I'm not even looking for strict rules, just "How does it work?"
<leoprikler>"How does it work?" is a very broad question.
<jlicht>"We all follow these conventions" :-).
<nefix>leoprikler: it does work with Docker
<nefix>But you need to set special permissions
<leoprikler>nefix: because docker fakes that for you IIRC.
<leoprikler>it would also work from a guix system container probably
<jlicht>emacsen: one of those conventions is that most packages would not install not-a-manpage files in the location for manpages.
<nefix>leoprikler: hmmm I'm not sure if I have understood you
<emacsen>jlicht, right, but this implies that there is some kind of man page collector, that looks for changes in man pages and then decides what to do.
<leoprikler>IIUC the thing in Guix, that makes fuse work is a udev-service-type in desktop.scm
<leoprikler>emacsen: no it does not
<rndd>hi everyone! i've found this in guix manual "GNU@tie{}Guix itself is a collective work with contributions from a number of people. See the @file{AUTHORS} file in Guix for more information on these fine people." but this file dont have any names in source code. maybe it sould be mentioned?
<nefix>leoprikler: so my only option would be to use a VM?
<leoprikler>for man-pages and some other things, that you might regard in a similar manner (GTK icon caches...), there exist profile hooks, which take all the packages in the profile and then compute something
<nefix>Or you can create a guix system container?
<nefix>Oh, it seems you can!
<leoprikler>Yep, guix system has a container option, that allows you to create docker and some other stuff from a config.scm.
<nefix>Ok, I'll investigate. Thank you!!! :)
***Kimapr_ is now known as Kimapr
<rndd>also, i'm doing a translation of manual. could anybody explain this term "referentially transparent build processes"
<jlicht>rndd: the (result of) a build process is fully dermined by its inputs
<jlicht>*determined
<rndd>jlicht: thanks ^_^
<abcdw>liltechdude: AFAIK, It's not possible to evaluate it interactively, because the context for g-expressions exists only on build daemon.
<liltechdude>abcdw: thank you vary much
<abcdw>emacsen: Every package installs its binaries, docs and so on to subdirectories of $output directory, for example take a look at coreutils package content: cd $(dirname $(dirname $(readlink `which ls`)))
<emacsen>abcdw, okay, so then some logic during the installer knows what the directories mean in terms of post-install actions to take?
<abcdw>emacsen: When profile is defined it basically merges all packages to one folder and after that "someones" sets PATH pointing to that directory.
<abcdw>emacsen: Every package tries to stick to FHS notion for directory structure. https://refspecs.linuxfoundation.org/fhs.shtml
<emacsen>abcdw, got it. okay, and that's just how it works, by path name. Okay :) That's all I wanted to know :)
<emacsen>thank you :D
<abcdw>emacsen: You are welcome!)
<rndd>also, could anybody explain "Installing 'debug' outputs."
<rndd>?
<leoprikler>it's about installing debug outputs 🙃️ What exactly confuses you?
<rndd>leoprikler: \'debug\'
<rndd>btw, thanks
<leoprikler>Debugging is a process of trying to locate programming errors (bugs) and subsequently fixing them.
<rndd>leoprikler, -_-
<rndd>i mean, why debug term was in single quotes
<rndd>🙃️
<abcdw>rndd: The debug output contains some non-essential files, which are useful for debugging (debug symbols for example), but application can work without them.
<leoprikler>because double quotes would be too much in this location
<abcdw>Oh, it was a question about message format? ok.
<rndd>abcdw: ye ^_^. i need to format questions better
<brown121407>Hi! I have a problem setting up PHP on a Guix System server. I tried following the example from the Web Services section of the manual, but everytime I request a PHP file from the server I get "File not found." Here is some relevant information: https://paste.sr.ht/~brown121407/de43cf5380241c3f7765abf5fbda25aadd61a06d
<brown121407>Has anyone encountered this problem before and found a fix?
<pineapples>o/
<sneek>Welcome back pineapples, you have 1 message!
<sneek>pineapples, raghavgururajan says: Any luck with the fonts?
<leoprikler>brown121407: a quick google search suggests, this is a php+nginx problem
<leoprikler>I'm not sure if there is a Guix-specific solution or you simply have to adapt one of the solutions found elsewhere
***zimoun` is now known as zimoun
<apteryx>leoprikler: thanks, about that exec trick! This solution requires the exec to be in a wrapper script, correct? The full guile command would have to call the real Guile script.
<brown121407>leoprikler, it seems that the cat avatar generator works, so it may be indeed something wrong with just my config
<apteryx>rekado: here's a sample output of running the modified test driver, which I find more useful to debug: https://paste.debian.net/1181627/
<leoprikler>This solution relies on your wrapping code ending in exec and bash stopping execution there to let guile take over.
<apteryx>leoprikler: right, so a two script solution.
<leoprikler>two scripts one file
<apteryx>oh!
<apteryx>neat
<leoprikler>you prepend that snippet onto the guile file you wish to wrap
<apteryx>I'll try it, thank you.
<apteryx>leoprikler: it works! #!/bin/sh\nexec guile -e main -s "$0" "$@"\n!#
<rekado>apteryx: we’re using a similar trick with wrap-script
<apteryx>wrap script can use a real Guile shebang though, as it's exact location in the store is known
<apteryx>in my case I wanted to have Guile looked from the PATH, so the exec shell + exec version was perfect :-)
<civodul>rekado: which reminds me, wasn't there a patch to fix something in wrap-script?
<civodul>i'd be great to use it more
<rekado>there was a bug report about wrap-script not doing the right thing wrt to the first argument(?)
<rekado>apteryx: yes, I just meant the general idea of multilingual scripts
<rekado>(or do you call this polyglottal scripts?)
<liltechdude>thank for help with previous problem, I show you result of my work a bit later
<liltechdude>Now I have next question: How to create in some existing packages by installing another
<liltechdude>I would implement something like game distribution for one game engine
<leoprikler>liltechdude: Can you rephrase that question a little. What exactly are you trying to do?
<liltechdude>Sorry for my poor english((
<liltechdude>leoprikler: At this moment, I have game something game engine `G'. G looking for game in internal directory D. Package G-my-game must create symblink of itself to D.
<liltechdude>hope this answer is more clearly
<leoprikler>Ahh, that's somewhat similar to what I did with renpy.
<leoprikler>Well, not exactly, but close enough.
<liltechdude>what ren'py game i have packaged?
<leoprikler>So far we only have "The Question" as a separate output of the Ren'py package.
<leoprikler>If your engine really only looks in one directory, you might want to patch it so that it reads games from G_GAME_PATH and add a search path specification with D.
<liltechdude>it is possible to set G_GAME_PATH to ~/<user_dir> ?
<leoprikler>not really, but you can prepend that in the shell.
<liltechdude>i.e in user ~/.bashrc ?
<leoprikler>better would be bash_profile, but yeah
<pineapples>raghavgururajan: Hi. I haven't had time to recompile the package. Instead, I manually installed the opensans font in my home directory and regenerated the font cache by running "fc-cache", fixing the font problem. I see two ways to handle this: either package and propagate font-opensans (undesirable) or package the font and provide the qt-build-system with it during the build process
<liltechdude>leoprikler: ehh, maybe have another aproarch? Create patch & Writing something in user files is seem's to be hacky
<leoprikler>You're not writing to user files though?
<leoprikler>Ideally, you'd package whatever games you create with your engine in Guix as well and set the relevant paths at build time.
<leoprikler>(And perhaps in wrappers at runtime.)
<liltechdude>I thought in the guix there is a general mechanism for declaring add-ons, how add-ons are made for emacs with site-lisp.d
<leoprikler>No, we are essentially relying on the mechanisms that those packages already provide.
<leoprikler>e.g. Emacs' site-lisp
<apteryx>Anyone knows whether the correct way to specify the store prefix from the environment is NIX_STORE vs NIX_STORE_DIR?
<apteryx>The (guix build utils) uses the former, while test-env sets the later.
<apteryx>hmm, this line in nix/libstore/globals.cc confuses me more than it helps: nixStore = canonPath(getEnv("NIX_STORE_DIR", getEnv("NIX_STORE", NIX_STORE_DIR)));
<leoprikler>I think getEnv here gets the environment variable with the default being the latter one
<leoprikler>meaning NIX_STORE_DIR shadows NIX_STORE shadow the default NIX_STORE_DIR (as per macro)
<liltechdude>leoprikler: could you in more details write about `ideally' variant?
<leoprikler>I don't know how exactly without a concrete example to be honest.
<leoprikler>But assuming you have Emacs with out EMACSLOADPATH, you'd add a patch to add EMACSLOADPATH.
<leoprikler>s/with out/without/
<leoprikler>And you'd package games the same way you package emacs-xyz currently.
<pineapples>raghavgururajan: I've re-read my previous message, and have realised that I might've made myself unclear in the last sentence. What I meant is that we can substitute the font during the build process in this way: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/web-browsers.scm#n421
<apteryx>leoprikler: that's how I understand it: nixStore gets set to the environment variable NIX_STORE_DIR, else the environment variable NIX_STORE else the compile time macro NIX_STORE_DIR
<apteryx>so in (guix build utils) we should really do (getenv "NIX_STORE_DIR")
<liltechdude>leoprikler: GAME_ENGINE_LOAD_PATH in ~/.guix-profile/share/<engine>/games/ currently, without any kind of patch
<apteryx>Nice, this fixes tests I had in builders.scm
<leoprikler>That sounds like a good value already, are there any problems with thaT?
<apteryx>civodul: this change is rebased on your patch-and-repack commit; it includes a fix to %store-prefix that was previously breaking the tests added to builders.scm.
<apteryx> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45774
<civodul>the NIX_STORE{_DIR} situation is sub-optimal
<civodul>it's one of the few things that are pretty much set in stone tho!
<joshuaBP`>morning guix!
<civodul>apteryx: thanks i'll take a look!
<zimoun`>Hi!
<zimoun`>Is it a bug that “guix hackage process --recursive” returns an ugly backtrace? Or do I misuse something?
<civodul>zimoun`: "guix import"?
<civodul>"Invalid keyword", ouch
<civodul>looks like refactor breakage + lack of tests
<zimoun`>ah, ok I will try to dig a bit more.
***zimoun` is now known as zimoun
<civodul>zimoun: it may have to do with bea3b17739fc591b8cf6db1f8d28a6f6c9585577
<zimoun>thanks, but that’s pretty old.
<civodul>zimoun: it was committed quite recently
<civodul>a month ago maybe
<zimoun>On Oct 2020, I reported <http://issues.guix.gnu.org/issue/44115>, so I do not know if it is really a “recent” breakage. Thanks for the pointer.
<zimoun>rekado: have you seen this ~Haskell ~98 compiler from C <https://github.com/blynn/compiler>; I do not know if it is usable to bootstrap instead of nhc98 on Hugs.
<lfam>Howdy
<ryanprior>Posting again for Guix in more time zones: I wrote a blog post about what Guix is! It's been described in many ways, but they typically don't feature what makes the project so compelling to me, so I wrote a kind of "missing about page."
<ryanprior> https://www.ryanprior.com/posts/what-is-guix-really/
<ryanprior>I'd be happy to hear any feedback, and I'm also interested in eventually writing some technical follow-ups with pithy demonstrations of the principles and capabilities I highlight.
<lfam>I wonder if anyone else has noticed `guix gc` becoming much slower in recent days
<lfam>It seems to pause for a second every few seconds
<lfam>I used to be able to garbage collect gigabytes in less than a minute, but now it takes several minutes
<lfam>This is on an SSD
<ryanprior>Maybe try running it under strace or valgrind and investigate those pauses.
<ryanprior>I only run `guix gc` every few months so I don't tend to notice variation.
<lfam>I run it at least once a week
<lfam>The thing is, aside from those pauses, it seems to be running more slowly overall
<ryanprior>Have you tried using time-machine -- gc to see if that brings the old performance back?
<lfam>I will :)
<apteryx>--with-git-url is not document in in 'guix build --help' nor 'guix package --help', it seems.
<apteryx>documented*
<lfam>I'm struggling to match a multi-line string in substitute*
<lfam>For example: https://paste.debian.net/1181659/
<lfam>It doesn't match, but I don't understand why
<lfam>I can make it "eat the newline" with this: " test\\\(\n.*$"
<lfam>But, that's not what I need. I just need to replace this word "test(" with a dummy string
<lfam>(It would be nice if meson have a facility for skipping tests
<lfam>)
<cbaines>I don't think substitute* works across multiple lines, because it matches the pattern against individual lines
<lfam>I see
<lfam>I guess I will have to use a patch for this
<lfam>Pity
<lfam>I don't even know if this technique (renaming the function) will work
<lfam>It seems like we use a hodgepodge of techniques to skip meson tests, since there doesn't seem to be a standard way of declaring tests in meson
<lfam>This is for mesa, which already skips a test for i686, but that test is invoked in a different way that makes it easier to skip it
<lfam>The mesa upstream isn't able to reproduce our test failure: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4091
<pineapples>raghavgururajan: On the second thought, the idea to substitute the opensans font — which, to my understanding of the desktop client's dependency tree, is part of lib_ui — looks daunting to me; although, on the other hand, using the bundled fonts would be against Guix's reproducibility efforts if I'm not mistaken
<lfam>pineapples: How would it be unreproducible to use a bundled font? Presumably, each time you use the bundled font, it's the same font as before
<lfam>Since fonts are not considered code, we don't really need to worry about building them
<lfam>Ah, guess I had it wrong. The fonts are considered "functional data" just like software
<lfam>Seems strange but okay
<urash>Hello!
<urash>I have machines.scm builld-machine configured with its local network ip
<urash>But have a problem:
<urash>root@guix-rocks /home/retard# guix offload test
<urash>guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
<urash>guix offload: error: SSH public key authentication failed for '192.168.1.222': Access denied for 'publickey'. Authentication that can continue: publickey,password
<urash>I think it's common and reproducible on any machine without additional ssh configuration (mine is default)
<urash>I'd be happy to contribute to documentation ;)
<lfam>pineapples: Although fonts require free licenses, I don't think that we usually build them from source in Guix
<lfam>urash: I'd guess that, upon login, something (guix itself?) is not found on the remote server
<lfam>You could try something like `ssh remote -- which guix`
<urash>both systems are guixsd
<lfam>Well, you might hit that later
<lfam>For now you just aren't able to login?
<urash>i'm able to login through ssh
<lfam>But, Guix cannot?
<urash>yes. I can't use Build Offload
<lfam>What command works to login?
<urash>ssh -p port ip. I configured permit-root-login, so root also works
<urash>Also i did ssh-copy-id both on root and normal user both ways.
<lfam>Does Guix know about the custom port?
<urash>yes, it listed in (port
<urash>of machines.scm
<lfam>It always helps to see one's actual code in cases like this
<lfam>You can use <https://paste.debian.net> to share machines.scm
<lfam>Did you try the test command `ssh build-machine guix repl --version`?
<urash>Thanks
<urash>machines.scm: https://paste.debian.net/1181662/
<urash>Tried:
<urash>root@guix-rocks /home/retard# ssh -p 2222 192.168.1.222 -- which guix
<Rovanion>Why does the Python package ship a pip binary? I want to set up development environment with python3.8 as python and pip 20.2 but its turning out hard because python-wrapper shadows python-pip's pip binary.
<urash>sry: # ssh -p 2222 192.168.1.222 -- guix repl --version
<urash>guix repl (GNU Guix) 2f497d94e7f6574b0847025ce29eafaf858008ef
<lfam>I notice in the manual chapter Daemon Offload Setup this text "Note that the default value is the private key of the root account. Make sure it exists if you use the default. "
<lfam>Does that assumption work for your setup?
<urash>Yes. I noticed it too. I created it with empty password
<lfam>I would try to specify it exactly in machines.scm. I haven't set up offloading, so it's not clear to me yet how the 'user' field affects this
<joshuaBPMan>Hey guix people!
<pineapples>lfam: Hmm. So, anything that cannot be possibly built from source, such as fonts, is allowed to be bundled with our packages even though it is freely available as its own separate thing?
<lfam>pineapples: That's not what I said
<lfam>But, I don't think there is any value in unbundling fonts, especially if it is difficult. Many (most?) of our font packages do not build from source
<lfam>My point is that we shouldn't put too much effort into things like this, or let packagers think they have to spend a lot of time unbundling fonts
<pineapples>lfam: In the case of Telegram, unbundling them is the matter of passing a single argument to cmake. The problem arises when we want to substitute them by placing our copy of the fonts in the directory from which we've just deleted the bundled ones. But I see where you're coming from. I'm just confused as to what we need to do to have our packages reproducible.
<lfam>I suppose it depends on what is meant by "reproducible". It's very easy to reproduce a binary by downloading the same pre-compiled binary over and over :)
<pineapples>I'll agree this requires too much effort, but, subjectively speaking, from my perspective, this is as a daunting task as packaging dependencies of rust software hahaha..
<lfam>I think that unbundling is not related to reproducibility. It's important to do, but for software. I don't think it's very important for fonts.
<urash>@joshuaBPMan, hello:)
<urash>@ifam still not working
<urash>Next logical step is adding authorized-keys to os-config.scm...
<urash>thank you for helping!
<lfam>urash: You're welcome! I wish I had actually experience with offloading. If you wait around, you will get some more expert help
<pineapples>lfam: You're probably right. Like I've said, I'm just confused, and have no idea what's the best for the project
<dongcarl>Hi all, just wanted to say that you all are why I have hope in the future of computers. Cheers! <3
<lfam>My opinion is that, ultimately, the best thing for the project is to keep increasing and improving the Guix packages and tools.
<lfam>So, it depends on what will keep the packager motivated to work on Guix :)
<cbaines>dongcarl, I was watching Bitcoin Build System Security again today :)
<lfam>Making it too hard to package things can be demotivating, although it really depends!
<dongcarl>cbaines: I was lost for a year and a half trying to find something I can build on so I didn't have to build everything myself. So glad I found Guix at the right time :-)
<lfam>That's why patch reviewers will often "finish patches" on behalf of new contributors, to keep them from getting discouraged. Once they are more experienced, we usually ask them to make the changes and submit revisions. And eventually they become committers
<cbaines>dongcarl, haha, good good :D
<liltechdude>why this builder in trivial-builder may crash with mkdir: permission deny?
<liltechdude>(let* ((source (assoc-ref %build-inputs "source"))
<liltechdude> (engine (assoc-ref %build-inputs "engine"))
<liltechdude> (game-dir (string-append engine "/share/engine/games")))
<liltechdude> (copy-recursively source game-dir))
<pineapples>lfam: I see where you're coming from. Thanks for your elaboration on the subject. I'll keep this in mind if I ever contribute to the project by myself. Either way, given the new circumstances, I'll just recompile the Telegram package with the bundled fonts included as per raghavgururajan's request
<cbaines>liltechdude, because you can't copy files in to an input
<liltechdude>ohhh, that irc multiline format..
<cbaines>liltechdude, and yeah, please use a pastebin
<lfam>liltechdude: Multiline examples can be pasted on <https://paste.debian.net> :)
<lfam>But, like cbaines said. "Inputs" are read-only
<lfam>I'm not sure exactly what you need to do, but you should check out (guix build union), which can take multiple inputs and combine then into a new input
<joshuaBPMan>hmmm, has anyone heard of https://sequoia-pgp.org/  It's a gpg alternative written in rust.  What's interesting is that one of the main developers used to code for the Hurd.
<joshuaBPMan>They just had their 1.0 release.
<liltechdude>there is no way to write to other `share' directory? https://paste.debian.net/1181664/
<joshuaBPMan>Oh geez, and they used to work code for gpg too!   geez!
<lfam>It's been discussed here, if not also on the mailing list
<lfam>I've noticed that kind of pattern from a few gnupg developers
<lfam>liltechdude: No, it's forbidden with Guix
<lfam>Those files are read-only, and on Guix System, completely immutable
<avalenn>Is there any tool to ease packaging of software written in Go?
<lfam>avalenn: There is a work-in-progress importer for Go: <https://bugs.gnu.org/44178>. Please try it out and provide feedback
<lfam>And, you're not crazy. Packaging Go software is extremely annoying
<apteryx>lfam: just confirming what cbaines said; substitue* is line-oriented; you can't do multi-line substitution in one go.
<apteryx>substitute*
<avalenn>Thank you. I will try that.
<liltechdude>lfam: But `sicp' package can create info entry
<apteryx>rekado: 'polyglottal scripts', ha!
<efraim>lfam: is your store on btrfs? Apparently there's a kernel bug fixed in 5.10.8 that was causing slowdowns on I/O
<lfam>liltechdude: It creates it in an *output* directory
<Enesabianamisik>Can someone help me out? I am getting this error when trying to install Guix freshly:
<Enesabianamisik>thunar-1.8.16 1.2Mib
<Enesabianamisik>substitute: updating substitutes from 'https://ci.guix.gnu.org'... 0.0%guix substitute error: TLS error in procedure 'write_to_session_record_port': Resource temporarily unavailable, try again.
<Enesabianamisik>guix system: error: unexpected end-of-file
<Enesabianamisik>Command failed with exit code 1
<Enesabianamisik>Press Enter to continue.
<lfam>efraim: I'm using ext4 with 5.10.8, and I noticed the slowdown since 5.10
<lfam>Enesabianamisik: It means the network connection failed
<lfam>It's interesting that applying a Git patch does not always create the same commit ID
<Enesabianamisik>I can connect the internet.
<apteryx>lfam: the commit ID it creates depends on the commit it's applied to
<lfam>apteryx: Yes, I know :)
<lfam>I'm starting from the same commit
<apteryx>just covering the bases ;-)
<lfam>Enesabianamisik: Right, but something is going wrong. Probably on the remote server
<cbaines>git commits include timestamps, so it's probably that
<lfam>Ah
<lfam>The timestamp of application?
<cbaines>I guess so, there's definitely at least two timestamps per commit, the author timestamp, then the commit timestamp
<lfam>Like, I have the same commit checked out on two computers. I use `git format-patch -1`, rsync the patch, use `git am patch`, and each computer has a different HEAD
<cbaines>the commit timestamp is probably when the patch was applied in your case
<lfam>It's surprising
<lfam>Well, my explanation is misleading
<lfam>They two computers started from the same commit, but then I made a new commit, which is rsync-ed as a patch
<lfam>Anyways, soon it will be part of history
<urash>how it can be possible that wpa_supplicant connection with SETKA is 'connected' but I can't ping 192.168.1.1 (i can from other machine (i could when we were trying to start offload))
<lfam>We are going to punt on the i686-linux mesa test failure
<lfam>If it masks some real bug, the i686 users will report it :)
<lfam>Here comes a new surge of jobs for the staging branc
<apteryx>urash: wild guess; perhaps the routes are set wrong? ip route
<joshuaBPMan>lfam:  what is your best estimate of how many 32-bit users of guix there are?
<urash>100% right.
<urash>Default routes are working, they show when i deliting, i assume, routes set up by guix on each reboot (I tried, they reappear)
<urash>I have https://paste.debian.net/1181667 in config.scm
<urash>and ip route shows: 192.168.1.0/24 dev wlp2s0 ...
<urash>Ok. Here's a clear picture
<urash>1. ip r shows 1.0
<urash>2. ip r del
<urash>3. ip r shows nothing
<urash>4. herd restart networking-wlp2s0
<urash>5. ip r shows default 1.1 (right one)
<urash>and 1.0 (wrong one)
<urash>both for wlp2s0
<urash>:)
<rekado>zimoun: that blynn-compiler is what the folks over at #bootstrappable are using to bootstrap the world.
<rekado>zimoun: re import breakage: I had to fix the recursive CRAN importer because of that commit.
<ryanprior>apteryx: it's documented in --help-transform
<urash>@ifam Ha-ha-ha.
<urash>One should run guix offload test as a user specified in machine.scm for a given machine to pass
<urash>That line in documentation is misleading then
<urash>Mb i still have half-working solution though
<urash># guix offload test
<zimoun>rekado: I am working on importers; fixing bug#44115. Because they are all almost broken with recursive
<zimoun>rekado: yeah, maybe it is good candidate to bootstrap a GHC 98. I have to compiled backward, using GHC@7.8 to compile GHC@7.6 but piouf! not straighforward…
<apteryx>ryanprior: I see; thanks I had missed it.
<PotentialUser-58>Hi to all, i'm installing guix system 1.2, it's the second time i try but it stop installing when downloading (seems very slow); my internet connecttion is good enough. How can solve ? thank you
<rekado>zimoun: yeah, that change seems to not have been tested well enough
<rekado>zimoun: I once investigated what chain of GHCs is required, and it’s better than Rust, but still very difficult.
<Enesabianamisik>PotentialUser-58: same here.
<zimoun`>rekado: ’gem’, the easiest is fixed now :-)
<jackhill>rekado: has the oulook gotten better since your blog post about tryning to get nhc98 to work?
<rekado>jackhill: not via the routes I explored, which involved building GHC 4 as the first GHC, using a GHC 4 partially hosted on Hugs.
<rekado>jackhill: but the blynn-compiler thing seems promising.
<rekado>I don’t know much about it, though
<zimoun`>from my little attempt this afternoon, I do not know if blynn-compiler is enough to be able to compile GHC@4
<rekado>probably not
<zimoun`>rekado: do you know if the error handling changed recently in Guile?
<rekado>GHC 4 needs its RTS library compiled first, and that needs an old GCC (which we now have, which is a better situation than the one I was in when I last gave up on GHC)
***zimoun` is now known as zimoun
<zimoun>yeah, I agree. Not that GHC@7.8 or 7.10 are not reproducible, I mean compiling GHC (bootstrapped with GHC@7.8) with GHC just compiled, and it is not the same… so the story about trustable Haskell toolchain is not easy…
<jackhill>rekado: cool, thanks. I also like the "Compilers for Contrarians" documentation/educational material that accompanies blynn-compiler
<dongcarl>kernel hackers: would appreciate your help with this ongoing issue: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45165#37
<dongcarl>I've narrowed it down to a few kernel config options, but am too much of a n00b to figure out what's going on behind the scenes
<joshuaBPMan>off topic alert.  I'm thinking about trying to ensure that I DO NOT lose files on my hard drive.  To that end I'm considering setting up a 1 with 2 disks on my Thinkpad T400.  Is this a good strategy for NOT LOSING data on my laptop?
<clone11_>The best strategy for not losing data is making regular backups.
<lfam>joshuaBPMan: Regarding how many Guix people are using 32-bit, hardware, I really have no idea. I think that for i686, it probably very few. More than that on 32-bit ARM
<joshuaBPMan>lfam:  Ok.  I think I saw on here that one of the guix developers wanted a "popularity-contest" for guix.  That would maybe give us better data.  I wonder if guix developers would find that information useful.
<lfam>I agree with clone11_. Using multiple disks will help keep things going if a disk fails, but it won't protect from accidental deletions. I use my backups probably once a month for recovering from that
<joshuaBPMan>Thanks for the tips guys.  How does one do regular backups?