IRC channel logs
2022-12-29.log
back to list of logs
<bjc>i mean, one issue or five? <mirai>What build system should I use for a package that only uses a handcrafted Makefile? <bjc>trivial-build, probably <Kolev>Guile error messages are hard to read. <leg7[m]>So after installing the system grub can't find my luks partition uuid and fails to boot. cryptomount isn't available so I think the grub build hasn't loaded the crypto features. <leg7[m]>Is there a way to load those in the guix config? <mirai>bjc: I remember hearing that trivial-build is not the best idea and it should be used for very very simple projects that don't expect much of anything short of cp or mv <bjc>leg7[m]: there is, though i can't remember off the top of my head <bjc>i'm sure it's in the manual <bjc>mirai: that sounds about right. i'd count calling make as trivial, but ymmv <bjc>otherwise i think your option is to use gnu-build and then just delete a bunch of phases? <oriansj>leg7[m]: would me sharing an install procedure and an example configuration of a whole system encrypted setup be of some use to you? <oriansj> and the guix configuration for study: <bjc>mirai: there's also copy-build-system, which may be more what you're looking for <lfam>lechner: It's checking the value of the #:tests? key that many packages use <lfam>That way, if you replace the check phase, it still honors the value of #:tests? <mfiano>Hello. I'm learning Guile scheme, and trying to install my first guile package with a fresh guix install on top of an existing Linux, and I get a backtrace. I'm not sure if someone here could be able to help me find the cause, or if I should take this to #guile. I'm too new to both to know what I can do here. <lechner>lfam / you mean if other packages inherit the definition, right? <KarlJoad>rekado: I got that documentation patch for .guix-channel's directory field pushed; 60392 on debbugs. <lfam>lechner: That's the not the point of it, but it will work in that case <lechner>mfiano / i am also new, but you should definitely share the error <mfiano>lechner: Ok I will do that. Thank you. <lechner>lfam / is #:tests? ever set outside that package definition? <lechner>mfiano / something cannot find 'unit-name' <ham5urg>I don't understand Scheme (not really), but it does not look too hard. What me bothers is the small size of files/services in https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services?h=v1.4.0 because I believe at the moment that this is most important part of Guix - from a user point of view. And if so, is it right to conclude that writing a service module is indeed hard? Due to the small number of available service <leg7[m]>Maybe because I'm installibg in a vm <drakonis>ham5urg: the files might be few, but the amount of services they collect is not <ham5urg>What I'm thinking about is, how hard is it do build a module for namespacing? <ham5urg>To enable VM-like behaviour to reuse models like samba.scm. <ham5urg>With it's own virtual NIC / IP-address, etc... <drakonis>looks like guile-proba isnt including the modules in the path? <gnucode>if we had to estimate the number of people that get paid to work on guix full time...how many would that be? 10+ <bjc>i assume no one does <gnucode>bjc: some of the cord devs help maintain HPC closuters for scientific stuff at universities. <gnucode>I also wonder how well pantherX is doing. I think they use guix ... <bjc>is that being paid to work on guix, or is working on guix something they do as a part of their bigger duties? <bjc>like, at one point i spent a good portion of my full time job working on ejabberd, but i wasn't being paid for that explicitly. it was what i did in support of building an xmpp platform <gnucode>I mean they are selling their services to help maintain servers running guix and/or guix system. But I have not asked any of these core devs specifically questions about their professional lives. <bjc>story is old and over. this was in like 2010-12 or so <bjc>and once the work that i needed to do was done, we stopped contributing. it's why i don't consider that portion of my life as being a full-time ejabberd developer, even though that's mostly how it was <bjc>maybe it's a distinction without a difference. that's just my perspective on it <mirai>ham5urg: for most of the service modules, their writers tend to be: guix users and <service> users <mirai>you could also throw in: somewhat comfortable with scheme and how driven the person is to have the <service> be provisioned with guix as nothing stops you from just doing it the old way <mirai>perform a set intersection and the reason for the service counts is more or less apparent <mfiano>Hi, I'm reading the Guix manual for the first time. Should I be seeing these references to NIX_* environment variables? <florhizome[m]>ham5urg I wouldn’t say it is hard but it might be harder to contribute <rekado>mfiano: the NIX variables are for the daemon. Nobody uses them unless they have a very unusual use case. <rekado>lechner: respecting #:tests? is also mentioned in the manual. It allows people to disable tests via package transformations. <rekado>lechner: what’s with the “)xLg( Huh?” and the short URL? <bdju>if anyone has some spare time at some point, it seems the gajim package has fallen behind a bit, and there are some useful bug-fixes to be had in the newer versions <bdju>also apparently guix has gained a reputation elsewhere as having "all kinds of bugs" :( <nckx>bdju: Can confirm; dvdstyler is unusable because of this. I'll try the work-arounds mentioned there. <flypaper-ultimat>mirai_: wrt to the build-system for a simple makefile, can confirm that removing steps from gnu-build-system is the easiest way to go about it; run "guix edit adapterremoval" to open an example. You canalso grep .scm files in gnu/packages for "delete 'configure" to get other examples. <mirai>rekado: the chars inside ) ( are some form of shortened bug ID <superkamiguru>Looks like guix/vm.scm has it's own definition for file-system->mount_tag, but I am not sure if there is anyway to use something similar from within guix config <nikken>i'm trying my hands at updating a package for the first time and when i try to build it i get a hash mismatch. when i git pull / checkout / guix hash -rx i still get the same hash and the guix build checks out the correct commit, too. any pointers here? <nikken>oh and while i'm here, anyone else having drag'n'drop not working on a recent (77d4bff) guix/gnome-desktop/wayland? <mirai>nikken: try guix refresh package -u <jman>Hi guix newbie here! When I create a container with `guix shell -C bash` the .bash* files are not loaded. Example the `.bashrc` file must be manually loaded, see this log: <jman>Is there a guix-shell parameter that forces the container to load the profile/shell file for bash? I think I'm not fully understanding what gui-shell does. <mirai>superkamiguru: I'm assuming that will require the networking target <nikken>mirai: you mean on the package i'm trying to update? i realize i didn't put that so clearly, i'm working on a patch to upgrade a port <nikken>and the repo for the package has changed <mirai>did you checkout the version on the repo <nikken>the current repo 404s and i know that the canonical repo for the port has been another repo for a while (the package is oksh and the current repo is github.com/ibara/oksh). i've changed the package definition and got the hash for the checkout but guix build builds a different hash so i'm trying to find out where the mismatch comes from <nikken>oh well, current =/= current. the one in shells.scm 404s and the proper & up2date one is the one i linked <mirai>nikken: I mean, did you clone this new repo, checkout to the commit for the version and run guix hash <mirai>cd repo && guix hash -x --serializer=nar . ? <nikken>git checkout 7ee37a3 (the one that guix build also checks out) && guix hash -x --serializer=nar ., yes <nikken>but guix build finds a different actual hash <patched[m]><jman> "Hi guix newbie here! When I..." <- What is your .bashrc? <jman>patched[m]: some standard stuff guix decided for me + a custom instruction to load `cargo` paths <nikken>mirai: when i use the the 'actual' hash everything builds fine but it'd be good to know where the mismatch comes from <jman>btw patched[m] I've also tried adding "--preserve='^PATH$'" to the "guix shell" command incantation but didnt seem to work (again, probably my bad I'm missing something) <jman>If creating a container *without* FHS env vars can be preserved. If creating a container *with* FHS env vars seems preserve to be not be preserved <jman>*with* FHS env vars seems to not be preserved <jman>ACTION thinks does it make sense? <lechner>rekado / Hi, as the maintainer of Lintian in Debian I responded to many hundreds of bugs reports. Lintian is a highly visible QA tool that enforces packaging standards. Unfortunately, Debian bugs now number in the millions. The short identifier you saw is an experiment to do away with perceived shortcomings. For starters, we would not need more than four digits for a very long time, as the encoding is based on the number 60. Also, the <lechner>least significant digit comes first, so folks are not so easily tripped up by the subtle differences between #1022022, #1021011, #1022011, #1021022, and #1021012. The short URL points to a brief but incomplete explanation <lechner>Aside from the the unusual encoding, people are also annoyed by the horns <lechner>rekado / thanks for the package transformation pointer regarding tests? <omlet[m]>All guix project is gpl3 with exception the linux libre? <lechner>unfortunately, i cannot. i have however been a foreigner for most of my life, and using each other's language even imperfectly furthers affection and understanding among us <omlet[m]>Ich spreche einfach Spanisch portugiesisch und ein wenig Englisch mit Hilfe von libretranslate.de <lechner>omlet[m] / As a kid, I spent some time in the Canary Islands but retained solamente un pocito. Now I live in Cowlifornia but my town is half Chinese and half Indian (as in India) <bjc>protip: don't accidentally run ‘sudo guix home reconfigure’ <bjc>guix should honestly probably refuse to run home stuff if the uid is 0, at least without some kind of explicit confirmation <bjc>if you have herd services, they run as root, for one thing <lechner>maybe the home profile should check the user name, as in "this is the config for bjc's home" <lechner>also, i avoid the use of sudo guix nearly completely with guix deploy although it currently comes some security holes <bjc>i'm not sure how you could check that a particular config belongs to a particular user (the file ownership strikes me as possibly error-prone). but runnin it as root is an easy footgun to stick a safety on <bjc>i ran ‘home reconfigure’ as root accidentally, because it happened right after ‘system reconfigure’, which requires root, and i just swapped the home/system command line arguments without noticing the little ‘sudo’ in front <lechner>please have a look at guix deploy it is a darling <lechner>bjc / i think we should file a bug against 'home' and ask that it checks that the user installing a profile matches the one to be declared within the home config. would you like to do so? <panosalevro>i get this error after 'guix system init': "error: /gnu/store....grub-efi-2.06/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory." any idea what i may be doing wrong? <lechner>panosalevro / you are installing for the first time? <omlet[m]><lechner> "Are you from Portugal or do..." <- Portugal <panosalevro>lechner: im using 1.4.0 and follow the shell-based process <lechner>panosalevro / do you have a link to the documentation you are following, please? <lechner>also, please describe your equipment and pastbin your config somewhere <omlet[m]><lechner> "omlet / glad to have you!" <- I think i not is tha first portugal person here <lechner>your country of origin did not matter. it was your positive and friendly disposition <panadestein[m]>Hey everyone. Would you be willing to share some guix home example configs? I would like to see how many cool stuff we can do with it :)) <luis-felipe>mfiano: Were you able to install guile-proba? I saw that the check phase failed for you... I just tried installing it in a different Guix machine (Guix System) and it worked alright, though. <ecbrown>hi all: anyone have success with fan control in guix system? <luis-felipe>mfiano: If it still doesn't work for you, let me know and I'll see if I can do something in the package definition. <zacchae[m]>efraim: Neat home config. Two questions: First, isn't it a bad idea to have your home config dependent on environment variables? What if you reconfigure from a tty, but want it to work in X? Also, I see you include qutebrowser; is it working for you somehow? I still get pages with bad rendering unless I use guix time-machine with an old commit I saved specifically for this. <the_tubular>Was 77d4bff94c6918eb0c0ccd20ee610e6dfc823aec the only thing separating guix from rootless containers ? <sneek>akirakyle, you have 1 message! <sneek>akirakyle, daviid says: i pushed a fix wrt GI dependency version in the configure.ac file tx for the catch, but the problems you were facing are not related to any bug in g-golf: (b) you need a clean environment to build g-golf, which means you can't build g-golf if it is installed, and (b) to run g-golf, guix needs a specific 'something', i hope those who know will help you and other g-golf users in guix <akirakyle>I think I've figured out some stuff about the build errors I was seeing... <mfiano>luis-felipe: It works on the commit tagged 0.2.0, but not (what was yesterday) the tip, where that error comes from. <luis-felipe>mfiano: Thanks. I'm setting up Guix on a Debian machine to try the installation there as well. <mfiano>luis-felipe: This was on a standalone fresh Guix install on top of Arch Linux, if it helps. <luis-felipe>mfiano: For what it's worth, I just installed guile-proba using a newly installed Guix on Debian, and it worked correctly, so I don't know what when wrong in your case :( <luis-felipe>I tested with the latest revision (030070ccfb31db75b68394a6a50a44496df87a1f)