<ng0>jonsger: i mean, it's nice to know and being able to patch in time, but the next default version bump for pkgsrc will be to 2.2 as far as I can remember. parallel version installs remain, and most packages (which aren't many) are 2.2 by now.
<ng0>or something like that, email thread was too long ago
<jonsger>ng0: I wont toggle 3.0 as default when it's released. But I already try to make the packages 3.0-ready :) The first batch I'll migrate when Guix is ready for 3.0
<nckx>‘Avoid @@, which doesn't work on Guile 3.’ 😮
<str1ngs>yes, when generating the dist taball the manual is created.
<str1ngs>you could use ./configure --localstatedir=/var then make info
<str1ngs>but that will probably fail because you need all of guix depends. best to use the info from the tarball.
<plasma41>How is the tarball created from a git commit? I had (falsely, apparently) assumed that simply checking out the correct tag would give me an exact copy of the contents of the tarball.
<roptat>plasma41, once you have all the dependencies, it's created with make dist
<smithras>hi guix! Today during a system reconfigure, I got a message saying 'error: executing SQLite query: database disk image is malformed' and now any guix command that modifies the store is raising the same error
<peanutbutterandc>Since guile3 will be out tomorrow, I was wondering if guix will start using guile3 from the bottom up really soon... We'll probably have guile3 as guile instad of guile-next in a few days, won't we? And from what I've understood, `guix pull` and friends will work noticably faster (?)
<str1ngs>peanutbutterandc: this tuxguitar build is not an easy fix. as far as I can see to build the tuxguitar-alsa-jni it needs to use maven .
<str1ngs>peanutbutterandc: though I have fixed up the build somewhat at least.
<str1ngs>peanutbutterandc: if you do a guix pull mercurial show be fixed now
<peanutbutterandc>str1ngs, Umm... sorry, how do I get that, please? I tried `guix build --dry-run tuxguitar` but couldn't see it. Also it's not in my /gnu/store. Also, I see that you are working on tuxguitar 1.5.3. Truely a man of culture. :)
<str1ngs>peanutbutterandc: oh this is my local build
<str1ngs>peanutbutterandc: once I get it working I need to mail a patch
<str1ngs>this build was messy it was doing chdir etc. I at least wrapped it in a guard.
<peanutbutterandc>Oh... I see. So you meant to say that you've got the library working. Sorry I don't yet speak the langauge of the wizards.
<nckx>smithras: You could try using the sqlite command-line tool to repair or dump the database, but it has a low chance of success (and will you ever trust the result?). Just go straight to ‘guix system init’ from the installer (it won't touch anything but /gnu and /var/guix). Happened to me too ☹ This fragility is unfortunate.
<str1ngs>peanutbutterandc: so good news I have sound but need to use timidity
<nckx>peanutbutterandc: If I'm not mistaken the mercurial update would not cause this because sources are fixed-output: the only hash inputs are the source files themselves, not the tools used to fetch them.
<str1ngs>it would only happen to build were the source changed correct?
<str1ngs>or I guess you can test with guix build -S ?
<str1ngs>I think the biggest issue really with mecurial was the build farm timing out
<nckx>Oh, it passed? I haven't checked yet. Yay then.
<str1ngs>yes, weather seems to be good for mercurial.. pun intended
<nckx>Apart from the -v thing I also raised the ‘internal’ time-out. It was quite low and the test suite would kill its own children. That's Guix's job!
<str1ngs>peanutbutterandc: timidity is the output tuxguitar is the synthesizer input
<str1ngs>peanutbutterandc: so definitely need this alsa plugin minimum.
<str1ngs>peanutbutterandc: but should probably add jack too
<str1ngs>peanutbutterandc: I don't know about the keyboard issue yet. I need to clean this build up more
<peanutbutterandc>str1ngs, I still need to read that book on linux sound/audio. I don't precisely understand how jack and alsa and pulseaudio work, yet. Perhaps it is one of the plug-ins of TuxGuitar? Also, it seems the XDG thing needs to be fixed for tuxguitar. I only see flatpak-installed tuxguitar on my machine
<str1ngs>peanutbutterandc: probably needs a desktop file
<str1ngs>peanutbutterandc: can you describe how the keyboard should work so I can test this?
<peanutbutterandc>str1ngs, I just type a key (number) and the number shows up in the tab (and plays a sound). If I want to change strings, I can use the up/down arrow keys to change them. right-left to navigate between notes on the same string
<str1ngs>peanutbutterandc: any number or number pad?
<str1ngs>peanutbutterandc: hmmm arrows keys don't even work. do you need to be in an edit mode?
<peanutbutterandc>str1ngs, Perhaps you might be interested in seeing the flatpak? I don't need to be in edit mode... It just works.. but I might have to check again. Number keys. Sorry.
<peanutbutterandc>It doesn't help that I have supertuxkart installed via guix. Which ships the very excellent 1.0. One of these days, I am going to learn blender just to create custom supertuxkart tracks.
<peanutbutterandc>str1ngs, Edit > Selection Mode seems to be the one checked in flatpak. Not edit mode...
<peanutbutterandc>I feel like the only thing that makes flatpak more appealing than guix is that it works well out-of-the-box. Which is what I hope to do with guix with the patch for install script. (Which does need to be updated, but still)
<peanutbutterandc>The first time I installed guix, I couldn't figure out why I couldn't run the programs that I just installed. Turns out, I did not have PATH set up correctly. Neither did the programs show up on the menus. That did turn me away from guix for quite some time until I finally read the reference manual
<str1ngs>unfortunately foreign distro does not get as much love at times.
<peanutbutterandc>str1ngs, I understand. I am one. And I plan to remain a foreign distro user (foreigner?) for some while. :)
<str1ngs>it's the best way to try and use guix I think.
<peanutbutterandc>The great thing is: I get to teach my friends/sibilings how to install programs via terminal without the 'sudo' part. And they understand it. It's so much fun to see them loving it. Guix is just great. It has put fun back in computing for me. :)
<peanutbutterandc>str1ngs, I have one question, however. I hypothesize that even if there were a malicious package definiton somewhere that ran `rm -rvf /*`, and a normal user of a system ran it, it wouldn't do much harm as all the builds happen inside of a chroot
<nckx>peanutbutterandc: You can't compare Guix to Flatpack. Flatpack is just ‘guix pack -RR’ which also generates binary blobs that also run out of the box and also don't require $PATH. You had to set PATH because you wanted a real package manager, not just a blobware downloader 😉
<str1ngs>peanutbutterandc: I've actually even got the guix daemon to run inside a rootless cgroup. so you don't need root ever
<nckx>Flatpak probably does do sandboxing, so they have that over us.
<peanutbutterandc>nckx, "For now". :) I love it! You know what I am most excited about? In the reference manual it says that the end goal is to have peer-to-peer substitutes (using something like gnu net perhaps). That is the thing.
<peanutbutterandc>I understand that guix is, indeed the best "universal package manager" out there.
<g_bor[m]>that makes it not feasible to use in an automatic installation context.
<g_bor[m]>I have two ways around that, one is to add a parameter to run-shell if the pause is requested, but then I would also have to add it to all calling functions, or maybe I could add a parameter instead.
<g_bor[m]>I believe a parameter would make more sense. Wdyt?
<nckx>g_bor[m]: I think I'd have written run-shell in a way that captures and returns the output for the caller to display or ignore as needed. With a run-and-display variant for use throughout the interactive installer.
<potential-alex>Good morning! I have a channel / GUIX_PACKAGE_PATH for some experimental packages. I need to apply patches to one of the packages during the build process. I know I can use the package field in <origin> — but it can't seem to find patches in my channel. How do I specify the path to the patch?
<leoprikler>if the patch lives in the root of your channel things should be a-ok
<leoprikler>if it lives elsewhere you'll have to write your own procedure to find it
<lxsameer>but when i build a package guix start downloading some packages including openldap, gcc, git and several others but i didn't define any dependencies in my package definition. is that normal ?
<nckx>lxsameer: I strongly recommend just calling ‘tar’, using SYSTEM or (in Guix) INVOKE. Something like (invoke "tar" "xvf" (assoc-ref %build-inputs "source") or (invoke (string-append (assoc-ref inputs "tar") "/bin/tar"). Those are just two random examples from gnu/packages.
<zimoun>brettgilio, roptat: I am looking at ocaml.scm for examples about package-with-explicit-<lang> and I see the variant ocaml-4.01; symbol in default-ocaml4.01 if I understand well. But I do not find ocaml-4.01 in (gnu packages ocaml). Is it expected? Does this code about variant still work?
<zimoun>ok, let the code for now and see if 4.09 happens soon, then s/4.01/4.07/g :-)
<roptat>The real difficulty is that we'll have some duplicate packages that don't fit well with package-with-explicit-ocaml
<roptat>None of the janestreet packages support both versions in any version, and there dependency graph was rewritten between 0.11 and 0.13
<roptat>But I might be able to come up with something. It means lots of duplicates and new packages, but we can do it
<roptat>I mean, bap is not compatible with 4.09 and requires the janestreet packages, which is why we would need both variants for them
<zimoun>I see. My point of view is: the default is supported which mean Guix ensures it works. Other can be tried by the user without any guarantee. Or the user can build its own packages with the other version than the default one if they knows it will works; otherwise it is painful, even when the user knows their packages compile with several versions
<zimoun>Yes for sure. Pragmatical is always better. But I feel a piece is lacking kind in the build systems. I mean, OCaml has code for variant, which looks very similar to Python one. Now I am looking at supporting 2 versions of R. We can think to build with GCC 7 or 8 or 9. From my point of view, it should be easy to tweak the compiler behing the build system; at the end-user level (CLI or package definition level, e.g., properties).
<zimoun>I am not sure neither multiple versions should exist, but I find useful to have an interface to easily change the compiler of any build systems.
<NieDzejkob>nckx: Well, in response to a cursed idea, one does not simply answer "yeah, this is running in production"
<zimoun>For example, the package Gmsh which is C++ but does not depend explicitely on GCC, so it is not easy to compile it using GCC 7 or 8 or 9. And I would like to do that, for example to compare performances or see if one bug is present using this compiler or not in this other one.
<refpga>Hello, I'm using Simple Login manager (Slim) and it runs in -nodaemon mode with CPU usage 100% (one complete core). It's configured as shown here: http://ix.io/27zh. Has anybody encountered this before? I suspect because of this my cpu temperature reaches 100°C quickly.
<efraim>did we drop the guix.d subdirectory for emacs packages?
<NieDzejkob>hmm, my immediately-sent x got received just fine
<zimoun>roptat: I am asking for to see build-systems as a function where the compiler is an argument :-). Then I do not know what is the correct level to modify and provide such argument. And I am not convinced that package-with-ocaml4.01 package-with-ocaml4.07 package-with-ocaml4.09 etc. is the right abstraction. Something like (package-with-<build-name> <version>) seems more appropriate, or using the properties of the package.
<NieDzejkob>refpga: slim is running with -nodeamon, but (at least when logged in) the CPU usage is 0
<NieDzejkob>finfin: I reproduced the problem, I'll send a patch that fixes this to the ML in a moment
<jonsger>it's nice how few processes run on a basic Guix system :)
<moesasji>Hi all; is there any logic why I see multiple occurrences of gtk+-3.24.12 as to be downloaded when running "guix install emacs-next --dry-run"? The weird bit is that 2 out of the 3 even have the same hash.
<str1ngs>moesasji: and if you do guix build emacs-next? does it download only one?
<moesasji>Just tried. It only downloads one; the links that end with -bin in the dry-run are missing when omitting the --dry-run.
<finfin>NieDzejkob, hi, sorry for not reporting earlier, have you managed to find a workaround around this issue?
<pkill9>moesasji: the -bin means it's the 'bin' output of the package, you can see with 'guix show gtk+'
<roptat>And remembered there was a wip-ocaml branch or something, I need to check it
<roptat>also we had a talk on the legion programming language, which might be of interest to HPC people :)
<roptat>so the plan: add ocaml-4.09 and findlib, add package-with-ocaml4.09, then update any package not from janestreet to a version that can compile with both compilers, then switch with a renaming of janestreet packages and use of #:ocaml and #:findlib arguments in those and dependents, finaly reimport janestreet packages in their latest version for ocaml 4.09 and switch any dependent that supports 4.09