IRC channel logs

2022-02-08.log

back to list of logs

<leonarth>guix pull: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused
<civodul>leonarth: this indicates that the daemon is not running
<leonarth>thank you civodul
<civodul>you need to restart it with "sudo herd restart guix-daemon" or similar with systemctl
<leonarth>I don't have any herd, I installed guix on debian
<leonarth>didn't know it had a daemon, thought it's just a package manager
<vivien>Hi guix, is there a foreign distribution where https://issues.guix.gnu.org/35308 is not a problem?
<vagrantc>"just a package manager" :)
<leonarth>:))))
<leonarth>Installed it today, still exploring what's all the fuss about it
<vagrantc>leonarth: you install from the guix package or install.sh script? what version?
<civodul>vivien: dunno but there've been discussions at https://issues.guix.gnu.org/53447
<leonarth>guix (GNU Guix) 1.2.0
<leonarth>apt installed it on debian11
<leonarth>free debian, no contrib :)
<vagrantc>leonarth: does "systemctl status guix-daemon" tell you anything interesting? maybe missing build users?
<vivien>OK so I should expect that guix won’t work on foreign distributions, right?
<vivien>Because of the environment variable problem
<vagrantc>there are some things that might not work, sure
<leonarth>yes: systemd[1]: guix-daemon.service: Failed with result 'oom-kill'.
<leonarth>restarting
<vagrantc>leonarth: are you on a system with limited memory ?
<vagrantc>e.g. oom ~= out of memory
<leonarth>it's my personal mail server on a vps
<leonarth>8G
<vagrantc>it shouldn't take a huge amount of memory, but it will use some
<leonarth>thank you for the help vagrantc, appreciate
<leonarth>around 2gig for now
<leonarth>the guile process is
<leonarth>guess it's not just a pkg manager, it's pulling the world :)
<KE0VVT>leonarth: Imagine using Guix on dialup.
<mbakke>Guix is a package manager in the same sense that Emacs is a text editor
<leonarth>perfect explanation mbakke !
<the_tubular>I do KE0VVT
<the_tubular>My scheme skills aren't the best so I'm running a dirty bash script to do somethings I didn't find a way to do with scheme
<KE0VVT>the_tubular: Oh...
<the_tubular>Also, a bit of stuff is dockerized
<vagrantc>leonarth: yeah, a lot has happened since guix 1.2, so there's a lot to pull. hopefully substitutes are working? e.g. it's downloading rather than building packages (unless you don't want to use substitutes)
<leonarth>vagrantc I have no idea what substitutes are, I'll research the project tomorrow in order to understand it
<vagrantc>leonarth: guix is a source-based distro with pre-built "substitute" packages ...
<vagrantc>so guix first checks if the substitute server has already built the package(s) your're installing or whatever
<leonarth>guix basically downloads and builds sources directly on my machine rather than download precompiled packages
<leonarth>although substitutes change that behavior
<leonarth>I guess I don't want substitutes then, defeats the purpose of guix
<vagrantc>depends on what you want
<vagrantc>but you don't have to change your behavior to use source or substitutes. it's the same commands to build/install/whatever packages
<AwesomeAdam54321>vagrantc: Does guix use only reproducible substitutes?
<vagrantc>AwesomeAdam54321: no, but it reproducible builds are strongly encouraged, and the build environment is set up to maximize the chances of a reproducible build
<vagrantc>there's a "guix challenge" command you can use to check the reproducibility of things you've built against the substitute servers
<leonarth>are substitute servers on by default?
<vagrantc>there are also some interesting properties where you can download from an untrusted server if the signature matches a trusted one :)
<KE0VVT>Not using substitutes sounds painful, worse than Gentoo.
<vagrantc>leonarth: typically, yes
<vagrantc>KE0VVT: depends on your needs, goals, etc.
<leonarth>and can I disable it to have everything built from source?
<vagrantc>leonarth: yup
<leonarth>awesome
<KE0VVT>vagrantc: My needs and goals are to not have a melted computer.
<vagrantc>leonarth: don't recall how off the top of my head
<leonarth>how free software should be
<vagrantc>KE0VVT: i've built many a package, and have very few melted computers to show for it :P
<singpolyma>I've built many too, but would like to avoid it wherever possible, heh. I can just imagine running guix install ghc rustc node ruby python with no substitutes and then just leaving for vacation :P
<vagrantc>fwiw, i usually use substitutes
<vagrantc>although i once set up a machine without using any substitutes just to test the reproducibility of a basic system
<vagrantc>think it was in the ballpark of 80% reproducible
<vagrantc>though, that was a couple years ago now, who knows if it's better or worse now :)
<char[m]>has anyone tried writting a quicklisp importer?
***califax- is now known as califax
<ryanprior[m]>vivien: I've used Guix on Ubuntu and elementary OS, neither one is affected by #35308 in my experience
<ryanprior[m]>regarding Guix being seen as "just a distro" or "just a package manager" I wrote a thorough explainer: https://www.ryanprior.com/posts/what-is-guix-really/
<ryanprior[m]>I'd love to help write a more apt description for the Guix website. Don't know where I should send my proposal to.
<ryanprior[m]>Echoing what florhizome asked earlier: if I'm adoping Guix Home, how do I migrate an existing file into it so that it's saved as part of the home config? Anybody have a good example or tutorial for migrating from ad-hoc dotfile management to Guix Home?
<Ribby>Hello, does anyone know how to troubleshoot a flickering ethernet connection?
<Ribby>Surprising, irc still works.
<ryanprior[m]>Ribby: at a high level, try rebooting your computer, router & modem. If that doesn't work, you could try taking a pcap dump and inspecting it for clues using tcpdump or wireshark.
<Ribby>Ok, I can restart my computer easy, but restarting the router is by reset button?
<ryanprior[m]>I usually hard power cycle mine to be extra sure, but on some routers the reset button is fine.
<apteryx>ryanprior[m]: perhaps the unholy slurp-file-gexp?
*apteryx doesn't really know
<Ribby>Do I hold onto the reset button for 10 seconds or no?
<ryanprior[m]>apteryx: how unholy are we talking? If it just copies a file into the store that sounds reasonable.
<apteryx>I think it's just the name that confused some, but I've never used it.
<ryanprior[m]>Ribby: if it were me, I'd unplug it, wait a minute, then plug in again. Or if you want to try the reset button, hold it down at least a few seconds until you see some kind of change in the pattern of lights, assuming the router has lights.
<apteryx>I think it's supposed to return the content of the file as a gexp
<ryanprior[m]>"as a gexp" implies that the resulting path points into the store, right?
<apteryx>I don't know more; you'll have to check its source :-)
<ryanprior[m]>I kinda ~40% know what a gexp is, I think it's like a data structure that's used with a store monad to represent a file or package at some checkpoint?
<apteryx>please enlight us if/when you do :-)
<ryanprior[m]>XX I will definitely write a thorough gexp explainer if I get to that point
<apteryx>It was explained to me as a sexp + metadata.
<Ribby>Ok, I will power cycle it, brb?
<ryanprior[m]>That's compatible with my understanding, but doesn't capture much of the intent of it
<ryanprior[m]>Ribby: good luck and godspeed!
<apteryx>I think your understanding is good, at least that's also how I see it.
<ryanprior[m]>I haven't been able to build `python-importmagic` for a while, how do I check in the Guix CI if that package is broken?
<ryanprior[m]>If I go to ci.guix.gnu.org and search importmagic it brings me this record: https://ci.guix.gnu.org/build/14575/details
<ryanprior[m]>Which says the build is green, but is dated mid-December 2021
<ryanprior[m]>Oh hold on, the cuirass search just sucks, that's what's got me confused.
<ryanprior[m]>Searching for "importmagic" doesn't include results for "python-importmagic", you have to type the whole thing
<ryanprior[m]>Now I can see it's broken in CI
<janneke>hmm, no linux-libre-5.15.19 substitute yet?
*janneke wonders if they should pull to an earlier commit
<civodul>ah ha!
*civodul goes check the "guix gc" status
<civodul>janneke: it should be building shortly i suppose
<janneke>civodul: okay, thank -- just wondering if i had missed someting
<roptat>hey, found out why maven would warn about an unsupported logger :)
<roptat>I forgot to copy the resources in one of its dependencies
<roptat>and I added the maven-slf4j-provider for good measure, now we get the expected colors
<jpoiret>apteryx: there's a third important feature of gexps, it is sexp + metadata, but you are also able to insert many specific objects into them for which a gexp compiler is declared
<jpoiret>For example, packages can be inserted into g-exps
<jpoiret>things like local-file, plain-file and friends aren't actually procedures that return gexps, but rather they return objects of their own corresponding record types, and there's a gexp compiler for those
<jpoiret>it's a tad bit more complicated but guix/gexp.scm is actually pretty readable
<roptat> https://issues.guix.gnu.org/53872 :)
<jpoiret>(with some guile knowledge of course)
<janneke>ah, my kernel built
<janneke>yeah, system upgrade fixes "Process org.gnome.Terminal exited with status 9" -- probably caused by dbus (+glibc?) update
<janneke>for exwm users, just found a helpful a hack for ungoogled-chromium: https://github.com/ch11ng/exwm/issues/759
<civodul>roptat: heh, good catch! :-)
<roptat>the --tune option doesn't do anything?
<civodul>janneke: oh i had noticed that behavior but somehow got used to it
<civodul>roptat: no, it's a no-op; it was easier to implement that way
<civodul>it's a placebo for HPC folks
<roptat>sure, but then why implement it at all?
<civodul>i told you, placebo effect!
<civodul>(just kidding!)
<roptat>does it only work on a small set of packages?
<civodul>right, it's documented as applying only to "tunable" packages: https://hpc.guix.info/blog/2022/01/tuning-packages-for-a-cpu-micro-architecture/
<civodul>if you have reasons to believe a package would benefit from it, you need to add the tunable property
<roptat>oh, I see thanks
<roptat>that's why it wasn't doing anything, I was just curious to see what it would do, so I tried it on hello
<roptat>I don't have good reasons to believe it would do anything on that package :)
<civodul>heh see? :-)
<civodul>but maybe it's confusing that it apparently does nothing
<efraim>(package-supported-systems ghc) and (package-supported-systems pandoc) give different results
<efraim>I would've thought that pandoc would also only show ("x86_64-linux" "i686-linux")
<roptat>yeah, I was expecting it to use -march=native or something
<roptat>or at least tell me why it won't do anything
<civodul>yeah
<roptat>alright, let's do some review :)
<civodul>you can try "guix build --tune gsl" to see the difference
<efraim>'(member (or (%current-system)(%current-target-system)) (package-supported-systems (specification->package "ghc")))' => (define (member-of-package-supported-systems foo) ...) in (guix utils)?
<efraim>on my machine I'm tuning for broadwell, that can't be right
<efraim>... i think
<efraim>how does it choose the micro-architecture again?
<civodul>efraim: it uses an approximation of what "gcc -march=native" does to identify the micro-architecture
<civodul>it's in (guix cpu)
<civodul>it you think it's making the wrong choice, please report a bug
<civodul>it's simpler and more naive than gcc
<efraim>I have a package for https://github.com/mgorny/cpuid2cpuflags, which might help actually
<roptat>oh no I pushed a commit the wrong author :/
<roptat>Ryan Sundberg via Guix-patches via <guix-patches@gnu.org>
<efraim>time for a git hook to check that the author's email isn't guix-patches@gnu.org?
<efraim>I think most of us have done it at this point
<roptat>closing two bugs with one patch :)
<efraim>civodul: looking at (guix cpu) it looks like you added more target options in (gnu packages gcc) but not the detection for them in (guix cpu). I'll take a look at that myself and see what I come up with
<gnoo>how can i set load-path or equivalent for guix system reconfigure ?
<sikmir>Anybode know what's up with debbugs.gnu.org? I tried to send 3 mails 4 hours ago, but nothing delivered yet.
<roptat>sikmir, if it's your first time, you have to be patient. You'll be moderated by a human
<roptat>next times won't have to go through moderation
<sikmir>no, not a first time
<efraim>civodul: I'm going to try to poke (guix cpu) a bunch
<roptat>then I don't know, I don't have issues
<efraim>match is case-sensitive, right?
<efraim>there really isn't much overlap when it comes to identifyable fields between different architectures
<civodul>efraim: nice! you should really try to mimic the GCC code mentioned there
<libh>Is it proper to make package requests in this channel?
<civodul>libh: hi! not sure what you mean by "package request", but go ahead!
<libh>I was wondering if this was where you make requests for packages to be added to guix as an official package. That was what I meant.
<AwesomeAdam54321>libh: There's https://libreplanet.org/wiki/Group:Guix/Wishlist for making package requests, but putting it here is also ok
<jpoiret>efraim, re the guix-patches@gnu.org git hook: great idea :)
<libh>There's a package called opentoonz already available in Parabola GNU/Linux, I was hoping that could be added to guix.
<gnoo>about the tor browser requirement there, won't it be enough to add a patch that disables addons.mozilla.org ?
<jpoiret>libh: it doesn't look like it has too many dependencies, although I don't know if it would be very Guix friendly
<gnoo>waiting till guix gets support for every platform is weird, and since it's not recommended to use addons with tor-browser, that shouldn't be a problem for the most part
<libh>Well the guidelines said you should check if it's already conveniently setup in a libre distro already. Which opentoonz is.
<libh>Not sure what you mean by "guix friendly" though.
<jpoiret>oh, by that I meant that i don't know if it will need patches to have it run properly on guix
<jpoiret>taking into account the difference between guix and "usual" distros
<libh>What kind of differences?
<jpoiret>it doesn't look like it is packaged for Nix, so no way to know unless someone tries :)
<libh>It is actually packaged for NixOS.
<jpoiret>well, sometimes you have hardcoded paths in code that don't exist in Guix (eg trying to run /usr/bin/hello or things like that)
<jpoiret>and some other specifics
<libh>jpoiret, OpenToonz is already a part of NixOS, I don't see how Guix would be any different.
<jpoiret>oh, a simle search didn't find it, but you're right :) doesn't seem to need specific patches
<civodul>libh: re requesting packages, note that in general, this is volunteer work that everyone's welcome to join
<civodul>in general, instead of "requesting" that someone do the work, people volunteer to do it by themself
<civodul>perhaps you can give it a try, too?
<civodul>there's introductory material on the web site and helper tools
<libh>I'll give it a shot. I was nervous because I don't know much about scheme.
<civodul>you shouldn't need to know much about Scheme
<jpoiret>if you need any help, there are always people on IRC to help you
<civodul>+1
<jpoiret>i was trying to hint at that above but i didn't want to sound rude :p
<civodul>oh, i hope what i wrote didn't sound rude, then!
<civodul>libh: as a starting point you can take a look at https://guix.gnu.org/manual/devel/en/html_node/Defining-Packages.html
<civodul>and yes, feel free to ask for guidance here
<jpoiret>note also that we don't have per-package maintainers like Nix
<jpoiret>civodul: no, of course not, let's just say i was too conservative
<civodul>:-)
<civodul>ah well, they left, so maybe i was rude after all?
<jpoiret>maybe they felt overwhelmed by the process, i don't think it was rude
<civodul>yeah
<civodul>roptat: i was looking at https://github.com/CatalaLang/Catala and look, they have Nix files (and not Guix) :-)
<roptat>hey, fun :)
<roptat>but how mean of them not to use guix
<civodul>isn't it?
<civodul>i thought: if Haskellers use Nix, OCamlers(?) ought to use Guix
<roptat>we can still import it
<roptat>guix import opam catala -r should work
<roptat>or not, it crashes in beautify-description
<roptat>oh but it doesn't anymore with the patch you pushed today
<roptat>I need to do something so it doesn't import ocaml-menhirLib which is part of our menhir package
<roptat>also I suppose ocaml-ANSITerminal is not a good package name
<roptat>and same with ocaml-js-of-ocaml, ocaml-js-of-ocaml-compiler and ocaml-js-of-ocaml-ppx. They're all in js-of-ocaml
<gnoo>libh left :/
<gnoo>this thing starts to compile: http://ix.io/3P23 (opentoonz)
<jpoiret>by the way, the github mirror hasn't updated in two weeks
<gnoo>guix gc cleaned 26GB
<gnoo>fresh fresh clean clean
<attila_lendvai>the package updater mechanism seems a bit complex. would it be easy to extend it so that it can handle my binary packages? see e.g. https://github.com/attila-lendvai/guix-crypto/blob/main/src/guix-crypto/packages/swarm.scm#L36 (it has multiple hashes for different systems). i'm willing to reshape my package if that helps.
<jpoiret>attila_lendvai: since guix is source-based, i'm not sure this would be something desirable
<attila_lendvai>jpoiret, we've been through that discussion. this is in my own channel now.
<jpoiret>if i understand correctly, the gotcha here is you need a different source per arch?
<attila_lendvai>jpoiret, yep. each with a different hash...
<jpoiret>you could split this package in 3, one for each arch, maybe?
<vivien>Dear guix, if I set up cryptsetup as cryptsetup luksFormat /dev/sda2, grub understands that the system is encrypted and decrypts it.
<jpoiret>eh, that'd make inputs more difficult to manage. Sorry, maybe someone else would have a better idea
<attila_lendvai>jpoiret, oh, hrm. i didn't consider that yet... what would it look like? same name, version, but different supported-systems field?
<vivien>If I set it up with cryptsetup luksFormat --type luks2 --pbkdf pbkdf2 /dev/sda2 (cf the manual), grub won’t ask me for a key and fail, not finding the files it needs.
<jpoiret>attila_lendvai: maybe, but having a different symbol for each would make it more complicated
<jpoiret>vivien: yes, this is an issue with grub-install
<vivien>Oh it’s known
<jpoiret>I thought i had it working because I have /boot/ on a different partition (my ESP)
<vivien>jpoiret, I have too
<jpoiret>if you're installing manually, I recommend bind mounting /esp/EFI/Guix/ to /boot
<vivien>Instead of /esp to /boot/efi?
<jpoiret>yes
<jpoiret>that way, the whole /boot partition is available on the ESP
<jpoiret>since you'll most likely have only /boot/grub/ on it
<jpoiret>and grubx64.efi
<vivien>OK. Is there a reason to use --type luks2 --pbkdf pbkdf2, if the default works?
<zimoun>rekado_: are you reproducing the error about texlive-base and an itemize and the doc?
<sneek>Welcome back zimoun, you have 1 message!
<sneek>zimoun, rekado says: Yes, with itemize it fails because the tcrm1000 font file isn’t found. It’s provided by texlive-fonts-ec.
<zimoun>rekado_: thanks for the sneek message. :-)
<efraim>civodul: I'm wondering if it's worth combining x86_64 and i686 in (guix cpu), then I wouldn't have to worry about where the cut-off line is
<jpoiret>vivien: luks2 headers are theoretically "better", but for a personal use case they don't add much
<jpoiret>you could argue that the argon PBKDF are better because they require specific memory constraints
<jpoiret>but they're not supported in grub yet
<jpoiret>for the luks2 grub-install patches, I have one pending at https://lists.gnu.org/archive/html/grub-devel/2021-12/msg00076.html
<efraim>civodul: hopefully the last one for a bit, gcc/config/i386/driver-i386.c got cleaned up for gcc-11, so I think it'd be best to "rewrite" the logic to check primarily by flags, rather than by vendor
***Guest42 is now known as davidl
<paladhammika>hello guix, getting this (https://termbin.com/7lys) error message when attempting to install protonvpn-cli
<civodul>efraim: yeah, no strong opinion; i tried to more or less follow what GCC's doing for Intel CPUs, and i thought we'd eventually add similar handling for AMD CPUs and ARM CPUs
<pmk>Hi #guix. I was wondering if someone can help me understand why my installation attempt fails, or how to debug it? I downloaded the installation iso version 1.3.0, and booted it from a usb stick. I attempted both the Graphical and the Manual installation methods. Both fail, I believe at the same point: the command `guix system init /mnt/etc/config.scm /mnt` fails about half way through copying with the message: "guix system: error:
<pmk>readlink: Input/output error".
<jpoiret>paladhammika: this failure is weird, no new changes in a long time to that package, and wrap-program has had that behaviour since at least the core-updates merge
<civodul>pmk: hi! it would seem like there was a problem while reading data from the USB stick or from your hard disk
<civodul>perhaps you can see details about i/o errors on tty12, by pressing f12?
<jpoiret>anyone know how to find out when a commit was merged (preferably using magit)? I see the commit date but want to know when it actually appeared on master
<jpoiret>pmk, civodul: also, the latest installer should hopefully be more stable
<civodul>true!
<civodul>jpoiret: for the real date, the only trustworthy source is the guix-commits mailing list
<civodul>but the commit data should usually be good in practice
<jpoiret>civodul: https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=refuse+to+wrap+.X-real&submit=Search&idxname=guix-commits only gives me when it was committed to core-updates, but I'd like to know when that particular commit was merged in master
<jpoiret>if that's possible at all of course (I assume the Dec merge)
<pmk>Thanks for the suggestions, people. Unfortunately tty12 does not seem very helpful. The latest entries there are: "Feb 8 15:46:24 localhost -- MARK --"
<civodul>jpoiret: oh, got it; then i don't know how to get that info
<civodul>pmk: alternatively, could you check /var/log/messages? you can press F3 to get a console
<pmk>civodul: Exactly the same content in /var/log/messages as in tty12. I also tried the --verbosity switch, but I still got just the progress bar.
<pmk>I will re-try with another usb stick just in case this is the issue.
<civodul>pmk: if you scroll up in /var/log/messages, do you see anything related to input/output errors?
<pmk>civodul: No, the only error I see is from a failed ssh attempt I did. Other than that it is pretty standard boot messages.
<raingloom>hey, i'm trying to build a system with a kernel from ~The Forbidden Channel~ using the ~Forbidden Substitute Server~ and all the kernel versions I tried show up in guix weather but then building the system results in the kernel also being built from source. what the heck is up with that?
<paladhammika>jpoiret: perhaps an error relative to my system
<raingloom>i'm passing --substitute-urls with the two default servers and this one. the only kinda weird thing I'm doing is appending $PWD to GUILE_LOAD_PATH because my config is modular.
<jpoiret>paladhammika: no, it's definitely the package definition that's wrong
<jpoiret>i'll send a patch
<jpoiret>raingloom: did you check that the derivation you're building is actually the one built by the substitute server?
<paladhammika>jpoiret: much appreciated
<raingloom>jpoiret: how do i check that? weather does not show the drv path. but it should be the same, i'm not customizing it anywhere.
<jpoiret>you can try guix build -d nameofthepackage to get the derivation
<jpoiret>but yeah, it should be the same
<raingloom>that already tries downloading the linux sources. wtf.
<raingloom>or... wait. what is it downloading?
<raingloom>oh, nvm, it's just downloading the package?? i think? i thought -d just printed the drv.
<raingloom>but guix build -n shows that it would download it, not build it.
<raingloom>oh. Oh. nevermind. in the mess of that sh invocation I did not notice that I was actually passing another directory to GUILE_LOAD_PATH
<raingloom>:facepalm:
<raingloom>well, hopefully this will get rid of amdgpu crashing all the time :)
<jpoiret>anyone used to Python's sanity-check phase? protonvpn-cli has an entry_point that is made for interactive use, and desperately needs to create a file in the user's home directory, should I just disable testing it and if so how?
<vldn>somebody know a good way/lib to plot dot charts to terminal with guile?
<PurpleSym>jpoiret: Have you tried `(setenv "HOME" "/tmp")`?
<mothacehe>apteryx: hey! i pushed the daemon warning patch :). I see that we are at 16/22T on the SSD array, is rsying giving an eta?
<mothacehe>*rsync
<civodul>good to see the SSDs are being filled!
<pmk>After trying with a different usb stick, installation was successful. Thanks for help!
<gnoo>jpoiret, PurpleSym or: (setenv "HOME" (getcwd))
<jpoiret>that way won't work, it tries to expand ~user
<gnoo>have a substitute rle changing ~usr to ~+ ?
<gnoo>rule*
<apteryx>sneek: later tell mothacehe no ETA on rsync, but it's currently at (xfr#32698611, ir-chk=955547/33654336), so it unless it scans and adds yet more directories bumping up the total files, it should be done somewhere about somewhere tomorrow
<sneek>Got it.
<apteryx>(i.e. 1 M files remaining to copy)
<apteryx>I guess we didn't know how much space /var/cache was using up, since just running df on the old HDD would have taken days to give an answer
<apteryx>s/df/du/
<jpoiret>asking again because I don't think I can find a satisfying solution: is it okay to remove the sanity-check phase for a package? the sole entry_point of protonvpn-cli wants to write to a log file depending on the user's home directory, and that's not really possible in the build environment
<jpoiret>i don't want to remove that entry_point either, since it's how users interact with the program
<apteryx>I wonder why setting HOME wouldn't satisfy it?
<lfam>jpoiret: You can set HOME=/tmp in the build environment
<jpoiret>it uses os.path.expanduser("~user")
<jpoiret>where user is determined through some shenanigans
<lfam>~user is standard for "user's home directory"
<jpoiret>python will use the passwd database
<jpoiret>yes, so I can't just set HOME=something
<jpoiret>if it was ~ only, that'd work
<PurpleSym>jpoiret: Yes, as a last resort you can delete 'sanity-check.
<lfam>I would report it upstream and remove the sanity-check phase
<lfam>This won't work for any distro that aims to build reproducibly
<lfam>I'm sure this program is still maturing and they could use the feedback
<jpoiret>sanity-check isn't really part of the build process though
<jpoiret>i'd say it's more a question of the tests not having proper environments for testing
<lfam>Well, it's up to you
<jpoiret>I'll just remove sanity-check here, i don't think upstream will do anything about this
<jpoiret>this project isn't maintained anymore too
<lfam>Oh good
<paladhammika>on a scale of one to no thank you, how difficult would it be to package onlykey for guix?
<roptat>what's onlykey?
<roptat>oh, it's at package the whole NPM repository difficulty
<paladhammika>roptat: https://github.com/trustcrypto/python-onlykey
<roptat>ah, you found a python version?
<paladhammika>yeah there is a GUI and a cli. i can live with the cli, probably easier to package.
<roptat>looks easier, it's a redefine the python-build-system level
<roptat>one dependency at least doesn't have a setup.py, but a pyproject.toml which I have never seen before
<roptat> https://github.com/trustcrypto/onlykey-solo-python/tree/786034139fcbe57e997449bfbc25f1f3d868ad95
<roptat>but other than that, most of the dependencies are already in guix or can be imported painlessly
<davidl>mbakke: just fyi: I have succesfully tested the updated ganeti-instance-guix pkg by adding a package transformation to my config.scm and reconfigured:
<davidl>(use-modules (guix transformations))
<davidl>(define transform1
<davidl>  (options->transformation
<davidl>    '((with-latest . "ganeti-instance-guix"))))
<davidl>(define ganeti-instance-guix
<davidl>  (transform1 (specification->package "ganeti-instance-guix")))
<davidl>then ran a gnt-instance reinstall <my-instance> and it worked!
<attila_lendvai>anything wrong with updating libssh2 in core-updates? been there for a while: https://issues.guix.gnu.org/53345
<jpoiret>paladhammika, roptat: pyproject.toml should be a pep 517 thing, i recall a patch somewhere adding support for it
<paladhammika>there are a handful of packages substituting pyproject.toml
<ngz>rekado_: Good news. I can compile almost all my documents with modular LaTeX. I only need some tikz stuff to complete the list.
<paladhammika>So I produced the basic package definition (https://termbin.com/oai6y) what comes next are the arguments which I'm unsure how to handle.
<jpoiret>arguments are only there to modify things most of the time
<jpoiret>if it builds properly, good, no need to do anything :)
<paladhammika>jpoiret: no modifications are needed to substitute for pyproject.toml?
<jpoiret>well, I don't know how PEP 517 works wrt python-build-system
<jpoiret>doesn't look like PEP 517 is supported at the moment, at least not automatically
<jpoiret> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/python-xyz.scm#n18771 uses it manually
<jpoiret>by the way, the substitutions to pyproject.toml I found were only to relax the build requirements
<jpoiret>that's nothing mandatory in general
<atomizedalex>I just did my first Guix install but I'm have a problem with the file system.
<atomizedalex>My root partition is marked for both mounting at both "/" and "/gnu/store"
<atomizedalex> Normally I would edit /etc/fstab. I tried edit the /etc/config.scm but I don't see where it specifies /gnu/store mount and adding my /home to the (file-systems) doesn't change the fstab.
<jpoiret>atomizedalex: that is normal, /gnu/store is remounted read-only on boot
<jpoiret>it is to prevent even the root user from touching the store, as it is a very dangerous operation
<jpoiret>the fstab isn't used for the automatically mounted file systems, they are mounted through normal mount commands, run as shepherd services
<KE0VVT>Anybody know how to set up a media server (ReadyMedia/MiniDLNA)?
<atomizedalex>Thanks. Where do I look for info on how to set up my /home to automatically mount?
<jpoiret>atomizedalex: if it is listed in (file-systems ...) it will be automatically mounted on boot
<jpoiret>you need to reconfigure for the changes to take effect though (and I'm not sure changes to file-system will work without rebooting)
<atomizedalex>Ok. I think I might just be missing the reconfigure step. This is all a bit strange to me.
<paladhammika>i see. the build goes smoothly until reaching 'running build_ext' then it hangs.
<jpoiret>basically, /etc/config.scm describes your system configuration, but for it to take effect you have to ask Guix to reconfigure your system according to the new /etc/config.scm file (which could be anywhere else by the way)
<jpoiret>whenever you reconfigure, guix creates a new system generation and switches to it
<jpoiret>that way, if the new system generation doesn't work to your liking, you can rollback (either in a booted system or directly from the bootloader)
<atomizedalex>That makes sense. Pretty basic. I was thinking of it more like a .Xresources
<jpoiret>it's way more :) it's a whole guile file that returns an operating-system instance, you could do basically anything in it
<jpoiret>guix system ingests what that file evaluates to and actually instantiates that operating system
<KE0VVT>I don't know how to use the package "readymedia".
<atomizedalex>Thanks again!
<jpoiret>atomizedalex: you should have a look at the manual (accessible from the command line through `info`, or online at https://guix.gnu.org/en/manual/devel/en/html_node/)
<atomizedalex>I was about to say that I need to do more rtfming. Ive just been too busy with my academic work and I couldn't resist Guix's allure any longer.
<jgart>Hi Guixers!
<paladhammika>hello there
<jgart>It looks like if I garbage collect with `guix gc` and I do a `guix pull` Guix will try to build all packages in a channel that doesn't have substitutes. How can I pull only from upstream GNU Guix and not the channel?
<rekado_>sneek: later tell ngz That’s great news about the modular LaTeX. If you have recommendations about documentation (since the experience is still fresh in you mind), I’m all ears!
<sneek>Will do.
<rekado_>sneek: good bot!
<jgart>Unless I'm mistaken on the above, otherwise let me know
<rekado_>sneek: botsnack
<sneek>:)
<paladhammika> https://termbin.com/dp06 -- build stalling on 'running build_ext'
<rekado_>paladhammika: do you see ‘build_ext’ earlier in the log as well?
<rekado_>is this library supposed to be tested with ‘python setup.py check’ or does it use a different mechanism?
<rekado_>(e.g. pytest)
<paladhammika>no just at this point. i'm unsure.
<mbakke>davidl: guix transformations are very powerful, but 'guix pull' would work too :-)