<raghavgururajan>I was. But I quit the security job two month ago to focus on Guix for a while. :) <darth-cheney>Hey gang, newbie here still trying to wrap my head around some things <darth-cheney>When using something like guix environment with node or python, is the expectation that the packages we would have installed with pip/npm are now in guix instead? <raghavgururajan>derivates: `(device (file-system-label "label"))` VS `(device (uuid "1234-ABCD" 'ext4))` <raghavgururajan>derivates: You may or may not need `(dependencies mapped-devices))`. <darth-cheney>My typical dev flow is to use something called nodeenv (basically virtualenv for node) which allows me to do things like install npm packages "globally"but really they are limited to the ephemeral nodeenv directory <derivates>raghavgururajan: im following exactly the same steps as the manual <raghavgururajan>darth-cheney: We have python packages (do `guix search python*-* | less`). Not sure about npm. For including packages in your env, you have to pass --ad-hoc argument. <kveroneau>In the currently provided qcow2 image, "df -h" does not work. <kveroneau>Cannot read table of mounted file systems, I do see that /proc/mounts does exist. <derivates>its parent OS has it, thought i'd inherit it <darth-cheney>raghavgururajan: so with python development (and using ad-hoc environments) the idea is to never use pip <raghavgururajan>darth-cheney: Not sure what pip does. If it merely includes packages/dependencies to your env, then yeah, you can replace it with --ad-hoc. <darth-cheney>pip is the python package manager and from what I understand it more or less installs packages/modules and places them on your system's pythonpath <darth-cheney>node is of course a little different because wherever you have a node repository it creates a local node_modules folder where it stores the complete graph of all the dependencies <raghavgururajan>darth-cheney: Ah, so you can replace it with guix env --ad-hoc. Its puts stuff in path, <darth-cheney>Are ad-hoc environments (or guix environments generally) what one uses when working on new package definitions? <darth-cheney>As in I'm working on packaging something for guix and I need to test it out as I go <derivates>the issue was probably cons -> append (why?) <raghavgururajan>derivates: No idea. i think cons looks for two lists. But you had only one list (root+boot) and missed second list (%base-file-systems). <rekado>“cons” puts one item onto a list and returns that new list <darth-cheney>gtg my girlfriend is haranguing me about being on the computer <derivates>do you think I should also add (operating-system-file-systems PARENT-OS) ? <rekado>there’s a variant called “cons*” that takes a number of items and a list and returns a new list consisting of all those items followed by the list <rekado>“append” only takes lists (any number of them) and returns a single new list <rekado>instead of (append (list this that) %base-file-systems) you could write <rekado>(cons* this that %base-file-systems) <derivates>could you please answer if you what I asked above? about the parent <rekado>sorry, I haven’t read the whole backlog <rekado>I need to go now, sorry! Hope someone else can answer you <nothingmuch>what consequences can i expect /gnu/store is rolled back to a previous snapshot but my home directory is not? is there a way to check consistency? things seem mostly working <lfam>nothingmuch: The effects will be unpredictable, and it's highly likely to break something <lfam>The /gnu/store cache is managed by a database which is usually found at '/var/guix/db/db.sqlite'. The contents of /gnu/store should only be changed using the `guix` tools <nothingmuch>lfam: ah, i should have specified that /var/guix was also rolled back (/ and /home are separate filesystems), in the meanwhile i did find guix gc --verify=contents, seems happy <jackhill>nothingmuch: in that case, I think the only thing to worry about is that you may have symlinks referencing store items that don't exist (e.g. if you had just run guix pull before the rollback). If you run into that, I think you should just be able to ask guix to make them again and all should be happy. <apteryx>nckx: dmitri.tobias.gr port 2223 seems unreachable ***bkv is now known as bqv
***lukedashjr is now known as luke-jr
<apteryx>our fleet of offload machines is not exactly reliable :-/. The overdrive1 keeps returning #f or some EOF. SSH access seems OK. <apteryx>nckx: I've commented out dmitri.tobias.gr for now in machines.scm ***iyzsong-- is now known as iyzsong-w
<sss>hi all, i know guix does provide tools to create environment for development, how to properly use it, i need some entry points. i need to create environment with set of packages and tools included for development of cmake based project ***apteryx is now known as Guest50260
***apteryx_ is now known as apteryx
<xwx>I have these libs install but still I get this. <xwx>The xrandr commnad has linked to libxrandr.so.2 but why the ./oh-my-git. Am I missing any path variable ? <civodul>xwx: if this is a pre-built binary, you'll have to fiddle with LD_LIBRARY_PATH, but it may not work <xwx>Is it possible to fix it ? <civodul>the safest way is to build from source <civodul>otherwise you can set the LD_LIBRARY_PATH environment variable to point to the relevant directories <civodul>but like i wrote, it's not guaranteed to "work" <sss>xwx: also you can force preload it via LD_PRELOAD=lib:lib:lib <civodul>pre-built binaries in general aren't guaranteed to work :-) <meo>hmmm, I just found out some of my docker containers are using a guix allocated UID <xwx>chivodul: But how does that some lib gets linked ? <sss>xwx: you can also check patchelf tool <meo>guix looks up the build users from the guixbuild group correct? <sss>but both LD_PRELOAD and patchelf is just hacky-tricks *abcdw getting *** #guile: Cannot send to channel <abcdw>Do someone see my messages at #guile? <abcdw>yoctocell: Thank you for the tip, but why it appeared today? Yesterday it was working fine. <abcdw>As a quick solution, I'll just repost the message here. <yoctocell>abcdw: Hmm, I dunno. It only works for me if I use SASL <abcdw> civodul, leoprikler, wingo: I found the place, which cause the problem I mentioned yesterday, found how to workaround it, but stil not know why it happens. The same code works differently with tracing and without, moreover it works differently if evaulaute forms one by one or the whole buffer at once and most interesting it works differently if I wrap the first argument of map into lambda. Very simple version of code to reproduce: <xwx>sss: Thank you. That works but the executable doesnt run. All lib have been linked. <sss>xwx: looks like you need to debug it more deeply. start with strace/ltrace *zzappie or other time of day <civodul>abcdw: so just introducing a lambda makes a difference? <wingo>abcdw: if i run your test here just via "guile foo.scm" it displays "correct behavior" <sss>xwx: but, i had to give up on runingng proprietary closed source executables on linux properly, for now just using steam-run hack from nix for such shit ( <leoprikler>also you seem to want to capture some output, but the only output you ever get is the string "Correct behaviour." <leoprikler>so your code produces expres. and subtop. by side-effect as well as some Correct behaviour by side effect and only ever returns Correct behaviour <xwx>sss: Any suggestion to install itch ? <abcdw>wingo: Wait a second, when I copy the code from pastebin it output correct behavior for me too, it's unexpected. Give me a minute to investigate. <sss>xwx: try steam-run, you can install nix on guix host, and install steam-run in nix, guix does not have such package yet and i think it will not be added into official guix channel due to licenses issue <leoprikler>itch sells proprietary stuff pretty hard as well, just because it's indie doesn't mean it's good :) <leoprikler>(It does mean you don't get AAA "live services" tho.) <sss>itch is good addition to gog, i think <sss>but nowdays i decided what it's more efficient to just build windows play station and not mix proprietary unreliable and unsecure games apps with working system <sss>steam-run is not related to steam <sss>it's generally just FHS emulation with set of common libraries from ubuntu-like system <sss>from my point of view it's best bug-for-bug approach in such case <lisbeths>I just think it's contradictory that I can't get help running nonfree drivers yet someone can get help running proprietary games <lisbeths>it should be limited to tux racer if I am not allowed to install it in my real hardware <leoprikler>Yeah, we actually have a policy in place, that should prohibit both. <leoprikler>Not that such tricks are all impossible in Guix, but we ought not to encourage them. <sss>lisbeths: as for today, for me, guix is not ready to run as host os, but i really like it as package manager, but i am also do not use proprietary drivers, using yellow cards in linux is generally bad idea, just stick with intel or amd <sss>lisbeths: as for installation of proprietary drivers, i belive nonguix channel have such thing, but not tested myself <lisbeths>I abandoned guix for like 2 years becuase there wasn't a nonguix channel when I started <leoprikler>Ahem, please stop distributing nonfree software through IRC. <sss>lisbeths: guix is still young project, and nix-invented package management approach is still young too, so it's ok to have a lot of problems with it <sss>leoprikler: it's just source code example, for reading ), and not software distribution <lisbeths>some of us are itching for a lisp machine not just for an immutable package manager <sss>leoprikler: shell script text, is it forbidden ?, in this case i am sorry <abcdw>wingo: can you do M-x run-guile C-c C-k on this file? I tried right now: rm ~/.cache/guile and guile tmp.scm -> Correct, after that evaluated the same code with geiser in emacs and it produced Wrong, after that guile tmp.scm also producec Wrong behavior. <leoprikler>You still shouldn't advertise it on IRC. The NixOS description for it comes with the clear disclaimer, that it is nonfree. <sss>lisbeths: for now i just do not know much about lisp, so can't appreciate it properly, but guix and nix approach to package management is really big thing <lisbeths>people who can afford a libre wifi dongle are privelaged. I am poor and I need a nonlibre kernel <sss>leoprikler: ok, understood, but it's the only way to solve task <lisbeths>I teach poor romaninan children how to code as well they cant go order some $20 wifi dongle they have to fend with what hardware they can find or often steal <leoprikler>Well, I'm privileged in the sense, that I don't need a Wifi dongle. <wingo>abcdw: i can repro if i "guild compile -O3 foo.scm" <wingo>so it would seem to be a miscompilation bug somehow <wingo>actually it reproes with -O2 also <xwx>sss: The itch io client is under MIT. So it can be added to guix right ? <leoprikler>not quite, it encourages non-free software and thus is not FSDG-compliant <abcdw>wingo: Oh, thank you!) I started suspecting that I'm loosing my mind) <lisbeths>I make minimum wage I can not afford any hardware except scraps that I get often which do not support libre kernel <lisbeths>we would all like to be running purely libre hardware on riscv but this is not heaven <leoprikler>I myself own hardware that doesn't function with linux-libre. <sss>xwx: i think yes, but it will most probably won't work because of most app's is for FHS based system <lisbeths>most of you who can afford open hardware that supports a libre kernel in fact make that money by writing proprietary software which is decietful <leoprikler>But still, there are rules in this place against encouraging such methods. You will find them on your own with the search engine of your choice. <leoprikler>I think most of us frequenting #guix try to write as much free software as capitalism permits. <abcdw>leoprikler: the original code was much bigger and did some miningful things, I just crated a separate file to make a smallest possible example, which demonstrates the issue. BTW, what was about map and for-each? <lisbeths>telling people to run it in a virtual machine is just a nonfree kernel with extra steps <leoprikler>If they're forced into a job, that doesn't allow them to, then that's unfortunate, but they don't get to advertise the produce of their job here. <lisbeths>I could be making 90 thousand dollars a year writing proprietary code and I refuse <lisbeths>instead I work at a gas station part time so I have free time to teach poor kids how to code linux <lisbeths>last summer I taught 5 kids how to use linux <leoprikler>Where do we tell people to use virtual machines? <leoprikler>You mean the Steam thing? I pointed out, that both are against our rules. <leoprikler>It doesn't make a difference, just because it's games. <lisbeths>as long as you are consistent with your tomfoolery :p <leoprikler>Well, there's free software games besides Tux Racer, but I really have to breakfast now. <lisbeths>btw as far as I know the only modern browser the ffs allows is gnu icecat <lisbeths>so please do not use chromium or firefox <jlicht>abcdw: do you think I could port my bespoke emacs config approach to guix home? <abcdw>jlicht: home-emacs-service-type should not restrict you in any way (except making your configs read only), but show me you current config please, I'll take a look and make sure. <rekado_>PotentialUser-60: you can’t install things with dpkg on a Guix system. <jlicht>abcdw: ^ I am aware it is a bit of a mess w.r.t. documentation, so shield your eyes :-) <tissevert>PotentialUser-60: good news is also you don't have to ! because you can do much better <jlicht>abcdw: (the snippet at the bottom of emacs.md is what my config is made of) <abcdw>jlicht: also, gitlab makes it hard to read the source code (: I'll finish sway home service, will review yoctocell's patch and will take a look at your configuration. <rekado_>PotentialUser-60: you can use Guix to install software, but I suspect you’re trying to use dpkg because there’s a .deb package you want to use. <jlicht>abcdw: really no rush implied, if you find some time to look at it in a month I would still be super happy <tissevert>the whole point of guix is to get reproducible package management <PotentialUser-60>rekado_: Unfortunately, many apps are not packaged in Guix, and the update process is very slow! <abcdw>jlicht: cool, added a task to my backlog, will let you know when I finish with it) <jlicht>PotentialUser-60: We are always looking for help, and depending on the specific piece of (free) software you are looking for, there might be alternatives for getting it running on a guix system <Noclip>Compilation fails with "./configure: No such file or directory". What do I need to do? <tissevert>plus, it's surprisingly easy to get things working quick'n'dirty when you really need something in a hurry (I've done that too much) and you learn a lot in the process ! : ) <tissevert>Noclip: disable the 'configure phase in your arguments to gnu-build-system <Noclip><tissevert "Noclip: disable the 'configure p"> Is there a template/tutorial for that? <abcdw>curious_one[m]: Can you make `export | grep GUIX` please? <tissevert>honestly it was a long shot, I have no idea what you're trying to actually do, but it sounded like an issue I had with a trivial package of mine with only a Makefile and no autoconf / automake anything and so no configure script to call <abcdw>curious_one[m]: I'm not sure, but probably you also need to install this package for root user, to make guix daemon find locales too. <tissevert>by the way: so I have this only «PREFIX» parameter to pass and I just have no idea what's the «proper» way to do it <tissevert>so far I've just added #:make-flags (list (string-append "PREFIX=" (assoc-ref %outputs "out"))) and disabled all relevant build phases : 'configure, 'build, 'check… <tissevert>I understand that writing a configure.ac could be the way to go but it seems awfully complicated and after reading about it for several hours yesterday afternoon I still have no idea how to wire a simple --prefix into the Makefile ^^ <rekado_>I think it’s funny that Guix offers more than 17k packages and *still* it’s never enough. <Noclip>The compilation failed now at another point so I guess the .configure issue is fixed now. Eventually I forgot a dependency. <Noclip>Is there a package for "libuuid-dev"? <abcdw>curious_one[m]: Do you mean locales of host OS or from ~/.guix-profile? Anyway, probably it's enough to `sudo guix package -i glibc-utf8-locales` and restart the daemon. <asdf-uiop>Hi! Is it possible to declare optional dependencies for a package? E.g. redshift does not require 'geoclue2', but it can use it. <asdf-uiop>And is there a way to declare minimal versions for dependencies of a package? <tissevert>Noclip: guix search uuid yields a couple interesting results, wouldn't it be in util-linux ? <Noclip>tissevert: At least it lists UUIDs as supported feature in it's description. Maybe I should just try it. <Noclip>Is this the correct way to specify special outputs as package input? `(("util-linux:lib" ,util-linux:lib)) <tissevert>I have no idea because I haven't been so far as to need this sorry ^^' someone else could help here ? <abcdw>curious_one[m]: cat /etc/systemd/system/guix-daemon.service <Noclip><rekado_ "I think it’s funny that Guix off"> nixpkgs has over 67k packages and there are still some missing ... <abcdw>curious_one[m]: it should be: Environment=GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale <leoprikler>abcdw: I think you would want to write this in a different manner <civodul>lemme know if that makes sense to you! <abcdw>curious_one[m]: Yes and drop the single quotes too, I don't know how systmed reads those values. <abcdw>leoprikler: Can you point out the way please? <leoprikler>Hmm, to be honest, I don't know define-configuration in and out <leoprikler>There are a bunch of services doing what you want to do with plain records, e.g. pulseaudio-service-type <curious_one[m]>abcdw: i did that and then systemctl daemon-reload && systemctl restart guix-daemon <Noclip>Guix package building is secure and shouldn't be able to corrupt my host OS, right? <cbaines>civodul, right, I see the issue. I wouldn't be sure what would happen when reading responses, but I guess it must break cleanly <abcdw>curious_one[m]: I don't have any foreign distros to play with, so can't try it myself. I'll try it on Debian someday, but not today. You can wait for zimoun, he probably knows how to deal with it. <civodul>cbaines: i think when it gets to the 'read-response' call, there's a possibility that the port has been closed, hence the read-line exception Florian reported <leoprikler>Noclip: it might not do this on its own, but if it uses many resources to the point that it causes a failure in another program, it might still happen <leoprikler>but potential side channels aside, Guix should be safe <cbaines>civodul, yeah, I get that things will go wrong in the current state, but I was referring to the state with the changes you proposed. <Noclip>Is it normal for a compilation process to ask for git? <Noclip>Mhh, I think it wasn't the build system that asked for it. <cbaines>civodul, no problem, maybe one day I'll be able to write sort of working Guile code! <Noclip>leoprikler: The build logs reported "git: command not found" so I guess git is needed as build-dependency here. <leoprikler>in particular if it's used to determine the version (those sneaky little…) <Noclip>I added it as dependency and now it says "fatal: not a git repository (or any parent up to mount point /tmp)". <leoprikler>That's why you don't just stupidly add stuff to the build and instead try to understand what is done in the build system. <abcdw>leoprikler: Made define-configure to provide this- reference and make default value thunked, now need to learn guile macros to make the implementation cleaner. <leoprikler>that looks pretty nice, what happens without thunking? <leoprikler>in particular, you might want to write the config as a gexp instead of a quasiquoted sexp <Noclip><leoprikler "That's why you don't just stupid"> I was trying to get a programm working with guix in a quick and dirty way. But it looks like that's not as easy as I hoped. <leoprikler>the quicker and dirtier the more likely you are to fail ***zap1 is now known as zzappie
<abcdw>leoprikler: Without thunking I'll get `this-home-sway-configuration: cannot be used outside of a record instantiation in form this-home-sway-configuration` <Noclip>Also this is the first time I'm creating my own package definition for a missing programm. So no, I do not really know what I'm doing ... <leoprikler>Again, first try to understand what the package is doing and why it "needs git". <abcdw>leoprikler: Perhaps I can't write a config as gexp, because at least I won't be able to extend it from other services. <abcdw>leoprikler: Technically it possible, but semantically doesn't seem to be correct. Anyway, even if we do not consider downsides of gexps here, what benifits would we get from using them for sway-config? <tissevert>woow configure.ac and all the stuff seems pretty unusable ^^ I'm gonna stick with a nice homemade configure script : ) <abcdw>BTW, to make the discussion more constructive and detailed, we can go to rde-devel mailing list, I will post the patch for review soon, you can add your thoughts here. <leoprikler>abcdw: the benefit would be, that you could write something like (config (include #~(file-append sway "/etc/..."))) <leoprikler>then again, I don't 100% understand your config options, so I may just be confused by what you're doing here <abcdw>Did you mean (config #~(list (include #$(file-append sway "/etc/...")))) ? <abcdw>leoprikler: And why it is better than (config `((include ,(file-append sway "/etc/...")))) ?) <jlicht>abcdw: I know the dream is to get guix home upstreamed, but do you think it possible to support GUIX_EXTENSIONS_PATH like the GWL? <abcdw>leoprikler: you can just place gexps inside if you want: ,#~(gexp-stuff-here) <leoprikler>yeah, but doing so looks more like a hack than anything else <abcdw>leoprikler: I'm not very expirienced guix dev, but looks okeish to me. Also, it's quite a rare case (at least I think so), when you need a full-fledged gexp inside the config, in most cases file-like objects are more than enough. <abcdw>jlicht: I do not know too much about GUIX_EXTENSIONS_PATH, so I can't answer to your question yet) <jlicht>abcdw: put another way, if "some person" would hand you a patch that would do exactly that, would it be considered for inclusion? <jlicht>provided it doesn't break unrelated parts of the code or lead to a massive refactoring effort, of course <leoprikler>abcdw: it simply means exposing your command inside a (guix extensions) submodule IIRC <jlicht>abcdw: I'll see if I can gather my thoughts and write them down cohesively. <abcdw>leoprikler: Thank you for explanation!), sounds interesting. jlicht: Looking forward to read) <apteryx>civodul: I feel we're very close to have all the artifacts of a first RC ready, but I'm struggling with offloading to overdrive1: Throw to key `match-error' with args `("match" "no matching pattern" #<eof>)'. <apteryx>ah, the tunnel fell again. I'll restart it with autossh <dante>I am using gnu guix as a package manager on top of trisquel... and I have noticed a few strange things. Installing libvirt-glib and/or gnucash from guix caused the user to end up in a login loop <apteryx>dante: yikes. There have been reports of some variables set by Guix interfering with a foreign distribution, such as PYTHONPATH <dante>I looked into the matter and saw that during each of those times, an environment variable (from `guix package --search-paths`) was the culprit <apteryx>have you narrowed which enviornment variable is at cause? <dante>yes... it's GLIB related env vars. I am switching generations right now <dante>are there any tips, please? as to how I might go about mitigating this? <dante>It worked just find on Linux Mint <dante>Another one (for gnucash) is GIO_EXTRA_MODULES <dante>I have succesfully used guix on top of both... and also elementary os <apteryx>glib sets XDG_DATA_DIRS and GIO_EXTRA_MODULES <apteryx>the long term solution is in Guix to patch all the software to use non-leaky versions of the environment variables (e.g, prefix them with GUIX_*) <dante>that sounds like quite a Herculean effort <apteryx>but as a quick stop gap measure perhaps you can install those things in a separate profile, and source the profiles on demand <leoprikler>I still think, that there might be something wrong inside Trisquel, though. <dante>do you think, perhaps, that trisquel is missing some package that Mint was not? <leoprikler>If Mint manages to coexist with Guix, there is no reason why Trisquel shouldn't. <dante>Precisely my thought. But since I don't have my freenode creds w/ me on this machine, I can't talk on #trisquel. I was hoping someone here uses trisquel. <leoprikler>dante: Try to find out how Mint establishes those variables during startup and compare it to how Mint does it. <leoprikler>You'll have to debug a lot of bash_profiles and rcs for that sadly. <leoprikler>My guess is that Trisquel relies on bashrc, which is sourced too late. <dante>should be worth it... I shall try to do it, later (or another day)... in the meantime, I have another query (not guix related) <dante>I have two entries on /etc/crypttab. 2 separate encrypted disks. One used as root (/dev/sda2) and another (/dev/sdb1) used as home. Plain-dm-crypt. <dante>But cryptsetup does not ask for password to encrypt the home partition during boot. In trisquel, again. Any ideas what I might be doing wrong and/or missing, please? I could use some pointers <leoprikler>Does it automatically decrypt home or leave you homeless? <dante>leoprikler, leaves me homeless... actually, it drops me to debug root shell (because /etc/fstab's /home entry fails). I tried commenting out the entry and I was homeless <dante>... I had to CTRL+ALT+F1, decrypt the home drive, and then log in for me to have a home <dante>*(and mount it to /home before logging in) <leoprikler>I assume, this is a "standard" systemd configuration, right? <leoprikler>in that case, since /dev/sdb is on another disk, I suspect systemd might be delaying the mounting of /home until it sees fit <dante>also, on GuixSD, does everything guix-related reside on /var/guix and /gnu/store only, as it does for us foreigners? <leoprikler>do you need to manually mount this or is there a systemctl command you could type for mounting everything? <leoprikler>if the latter, you might want to look at journalctl <leoprikler>In Guix, you also have /run/{current,booted}-system containing the system profiles <leoprikler>but yeah, the nitty gritty resided in /var/guix and /gnu/store <dante>I was expecting cryptsetup to decrypt all the entires in /etc/crypttab before the system looks at /etc/fstab... so I suppose I need to manually mount this <dante>I am setting up my system to have separate /gnu and /var/guix partitions so that I can have a rolling-release portion of my system in one place and normal point release system in another <dante>I tend to use guix as the primary package manager (as far as practicible) <Noclip>"(modules '((guix build utils))) <Noclip> (snippet '(substitute* include/crucible/uuid.h (("uuid/") "")))" <civodul>Noclip: i don't know the context, but syntactically it looks correct, except for include/crucible/uuid.h which should be enclosed in double quotes <Noclip>I want to replace "uuid/" with nothing ("") in the file include/crucible/uuid.h. <balance>Hello! Please help with next issue, want to build litecoin-core, using scm file, first step is "wget https://git.savannah.gnu.org/cgit/guix.git/plain/gnu/packages/finance.scm" and add similar to bitcoin-core-0.21 strings (add link to tar.gz file, calculate hash, add calculated hash etc.) with litecoin-core-0.18. But when i do "guix package -i litecoin-core-0.18 -f finance.scm" i see error: "guix package: error: cannot install non-package o <balance>bject: #<unspecified>". Discovered that this is not a problem with litecoin-core strings... when try to install bitcoin-core from original finance.scm file have the same error. <rekado_>“guix build -f file” is only used to build from a file that evaluates to a package value. <rekado_>it should be sufficient for you to run “guix pull” to get the latest Guix (which includes the latest version of the “(gnu packages finance)” module) and then run “guix install litecoin-core” <rekado_>if you want to define a new package don’t copy that module; instead start a new file that refers to that module. <balance>rekado_: unfortunately there is no litecoin-core in repos <rekado_>so… you added a package definition for litecoin-core-0.18 to that file you downloaded? <rekado_>balance: maybe you can paste your changes to a paste site like paste.debian.net <rekado_>and then we’ll work on this together <balance>rekado_: Could not add your entry to the paste database: do not spam <apteryx>civodul: about the hard dependency on guile-lib; that's because of not using autoload correct? Which I had to do to be able to use the %strict-tokenizer? globally to #true. That's not the only way, but the most convenient (we could bind it every place we call html->sxml, or use the strict? keyword there) <civodul>apteryx: yes, that's what i did: use #:strict? #t <apteryx>I think it could be nice to have warnings in the configure.ac too, advertising some features will be missing <apteryx>I have a patch in the works for that <civodul>in general, side effects from the top level should be avoided <civodul>yes, warnings in configure.ac could be nice <apteryx>also, the requirements of the manual are lacking, e.g. guile-ssh <apteryx>but that's not for version-1.3.0 (string freeze) <balance>rekado_: can we use another resource to share? tryed many times in https://paste.debian.net but "Could not add your entry to the paste database: do not spam" <rekado_>use whatever site where you can paste your changes :) <rekado_>I saved it as litecoin.scm and then ran: guix build -f litecoin.scm <rekado_>note that the file evaluates to a package value <rekado_>(it ends on litecoin-core-0.18, which is a package object) <rekado_>if I wanted to contribute this to the (gnu packages finance) module in Guix, I’d have to get myself a clone of the git repository containing the Guix source code. <rekado_>instructions on how to do that are available in the Contributing section of the manual <rhou[m]>why are there no mingw builds on the ci.guix.gnu.org servers? <rekado_>rhou[m]: generally we aren’t cross-building packages on the build farm. <rhou[m]><rekado_ "rhou: generally we aren’t cross-"> because of build capacity? what about powerpc and armhf? <rekado_>it’s just that with a proper port we have the reasonable assumption that building the package collection at scale will work. <rekado_>but with mingw we don’t have that, and many packages fail to be cross-built <Ikosit>Nvm, xvfb seems to be a part of xorg-server <tissevert>ok, I think I get what propagated-inputs and native-inputs are, but now I can't seem to understand how inputs could be useful when they are not part of the generated profile <tissevert>they are build dependencies too ? but shouldn't they be native- in that case ? <tissevert>(I mean «build dependencies» by opposition to runtime deps) <zzappie>tissevert: this distinction is made for crosscompilation <zzappie>native inputs are things like autotools <rekado_>propagated inputs are packages that are installed into the same Guix profile as the target package <tissevert>but I can't understand how they can be runtime dependencies when they are not in the profile <rekado_>whereas inputs only live in /gnu/store <tissevert>how can they be useful from just living there ? <rekado_>it works through the magic of absolute file names :) <rekado_>for libraries, for example, we embed the absolute file name in the target binary <rekado_>so the binary will open the library not by unqualified name but by its absolute store file name *zzappie so fast... Hard to outtype rekado_ <tissevert>and what enables it, apart from being in the inputs field of the original package ? <rekado_>a propagated input can also be “captured” like that, of course. The distinction here is only that for propagated inputs Guix performs extra work on installation. <tissevert>I have this bash script using unzip, I cited unzip as a dependency of my package, but it didn't get prefixed in the output like you said <tissevert>the documentation mentions that «some script» languages like python or guile would behave like that <rekado_>that’s where a build system comes in. <rekado_>if you have a script that invokes “unzip” it will not be rewritten to use /gnu/store/…-zip/bin/unzip <tissevert>so maybe that's not too surprising, but I wonder how I could've made guix patch my scripts automatically (I use the gnu-build-system, I thought that was magic !) <rekado_>the gnu-build-system patches shebangs as if through magic <rekado_>but it won’t rummage through your source files to replace arbitrary commands <tissevert>but then why does it do so for every object file ? <rekado_>because we can tell the linker to do this <Ikosit>tissevert: You can use the procedure `wrap-programs` to create a wrapper that exports variables <rekado_>or wrap-script for scripts that use # as a comment character <Ikosit>e.g. Appends the location of unzip in /gnu/store... to PATH <tissevert>Ikosit: thanks ! I'll look that. Sorry, I didn't understand your question regarding the output <rekado_>(just noticed that wrap-script is a little broken; I remember a bug report about this…) <tissevert>thank you very much, I think that answers my questions <tissevert>so, inputs for all normal runtime dependencies that are used through compiled code, propagated-inputs for scripts where the dependency is merely text in the middle of text and hard to determine whether it gets executed or not (halting problem, how cruel thou art) ? <balance>rekado_: thank you for help, will test it <pineapples>I need your second opinion, Guix. I'd like to package a FLOSS python library, but there's a twist: from what I've gathered, it's exclusively used in Valve Software's nonfree video games, and their digital game store frontend, Steam, which is also nonfree. My question is as follows: do you think that this python library suitable for inclusion in our package tree, or not? <leoprikler>Just because it's hitherto only used by Steam doesn't mean it's worth less per se. If it requires Steam on the other hand… <pineapples>To be more specific, it's a module for (de)serilization to and from their in-house VDF file format, which these nonfree softwares use to store some metadata <rekado_>pineapples: I assume that it *can* be used in other contexts and its purpose by itself is not to further proprietary software. Given that it is free software I’d say there’s no FSDG conflict. <rekado_>sounds like a perfectly fine thing to add to the package collection. <pkill9>VDF's aren't necessarily used exclusively in nonfree games, for example, you miht want to extract art assets distributed in a VDF files <pkill9>in that case, you're using the VDF on it's own, not in nonfree software <pineapples>Well then. Expect another patch from me in the coming days. Thanks, rekado_, leoprikler and pkill9! <zzappie>are there plans to push guix niceties like define-record-type* to guile? <civodul>zzappie: nothing specific but in general why not <civodul>define-record-type* still evolves from time to time to closely match our needs <civodul>so perhaps it's still too early to move it outside Guix <civodul>note that some things do move out of Guix, like guile-zlib, guile-gcrypt, define-json-mapping, etc. <Ikosit>How can i overwrite only certain arguments in an inheriting package <Ikosit>And how can i select the phases from a package? <leoprikler>Ikosit: substitute-keyword-arguments (i forget if it has a trailing star or not) <nckx>Ikosit: Search gnu/packages for substitute-keyword-arguments examples. <zzappie>civodul: cool I didnt know that these were part of guix once :) I sometimes reach out for derine-record-type* or mlet and forgeting that I need to bring guix along with it <nckx>apteryx: It was already commented out, but not committed, it might've got lost. Thanks for taking care of it (I'm visiting it tomorrow 🤞). <zzappie>civodul: guix is kinda guile library incubator then :) <nckx>zzappie: It's one of(?) the largest & most widely-used Guile projects, so it has no choice :) <yoctocell>Is anybody running xinit/startx? When I run `startx', I get an error about X not being found "xinit: unable to run server "/gnu/store/s1b6sva8zi9ng54wb70d4z4pj5ywr1sx-xinit-1.4.1/bin/X": No such file or directory". But `readlink $(which X)' gives me "/gnu/store/a89ch18dfcjwrxbi35cbybjv9d6f9gwf-xorg-server-1.20.10/bin/X" <yoctocell>Why does it look for X in /gnu/store/...-xinit, and not in /gnu/store/...-xorg-server? <roptat>yoctocell, you need to use xinit directly, but there's also a bit of setup you need to do <roptat>I don't remember precisely, but you should be able to find that in the help-guix or guix-devel archives <yoctocell>roptat: Hmm, on other distros (including NixOS) running `startx' should Just Work. <roptat>I don't really know what's going on, but I guess "it's complicated" :) <balance>just installed guix on i686 but guix pull doesn`t work, when trying to "guix pull" a error occurs: "guix pull: error: Git error: the SSL certificate is invalid". Installed git nss-certs... How to solve this? <yoctocell>roptat: Looking at the xinit package in Nix, they add a configure flag "--with-xserver=${self.xorgserver.out}/bin/X". I think we could do the same thing. <nckx>roptat: Congratulations. <bone-baboon>civodul: In regards to the stress test you shared for bug#47927. I put that snippet in a shell script, made it executable and ran it. It has no output, finishes very fast and `echo $?` outputs 0. <civodul>if everything goes well, it should run endlessly <bone-baboon>civodul: Thank you for sharing that link. If it runs endlessly how long would be a sufficient stress test. <civodul>bone-baboon: 10 minutes or so would already give some confidence <bone-baboon>I just ran ./bootstrap from in the root of the Guix repository after rrunning `guix pull`. I get this error "./bootstrap: 29: exec: autoreconf: not found". <zzappie>bone-baboon: try using guix environment guix <zzappie>it will ensure that things that are needed for development are in your env <zzappie>Contributing section of the manual describes it in more detail <zzappie>don't forget to pass --localstatedir to ./configure <zzappie>I was playing with (guix marionete) and system test yesterday. It didn't occur to me at first that system tests are essentially derivations and only (marionete-eval ...) parts are evaluated in vm. <zzappie>This actually means that you could have several marionettes in one test and connect then via quemu net socket interface backend or something like that <zzappie>Anyone knows wether it already has been done in guix? <balance>How to solve this "guix pull: error: Git error: the SSL certificate is invalid"? <zzappie>balance: are you on foreign distro or on full guix intall? <zzappie>oh no idea then... Did you write config yourself or installed with graphical install? <zzappie>maybe you need nss-certs installed for root not sure. Only had this issue on foreign system <balance>myself config, already installed nss-certs for root <balance>and how to solve this problem on foreign distro? <AleQu[m]>Do you mean you included nss-certs in your system config? Because 'installing for root' is something else. *nckx thanks whomever(s)(t) fixed ‘make’. 👍 <zzappie>balance: I don't think it's related and I was looong time ago. I added env var to point to certs dir <balance>AleQu[m]: included nss-certs in system config, "(name-service-switch %mdns-host-lookup-nss)" <AleQu[m]>I assume you also included the package nss-cert in (packages ...), of course. <bone-baboon>balance: I was also having the same error on a fresh install on i686. <zzappie>AleQu[m]: yeah I meant including in sistem config excuse me for confusion <balance>AleQu[m]: (packages(append(list nss-certs... <balance>bone-baboon: thank you for answer will try it ) <AleQu[m]>Right, then I have no idea either. See what bone-baboon said. ;-D <balance>bone-baboon: yes your answer helped me, thank you!) <lfam>We should probably make the graphical installer include nss-certs and the NTP service by default <bone-baboon>lfam: I think the graphical installer already includes nss-certs. ***prirai is now known as priyanshu
<lfam>The installer image itself may include them, but it's optional to include them in the installed system, IIRC <lfam>I'm saying that they should be included unconditionally <bone-baboon>Yes and I think the default is that nss-certs is to be included. <lfam>When Guix was founded, TLS / X.509 was still seen as an "extra" thing, so it makes sense that they wouldn't be included by default, but now that technology is unavoidable <lfam>Yeah, the box for nss-certs is checked by default <lfam>I guess I don't understand what the problem was for balance :) <andreas-e>lfam: The idea was that people could decide for themselves which certificates they would like to trust or not. But we only have one package... <lfam>Yes, I remember that reasoning as well <lfam>Now, nss-certs / Mozilla is basically the primary decision maker about which certificates are trusted <lfam>They lead the working group that controls this <bone-baboon>lfam: It was the same issue you helped me with. An old i686 that had the wrong date and time. <lfam>bone-baboon: I don't recall the details now :) Is there anything we can do to make sure that doesn't happen for anyone else? <bone-baboon>lfam: So that means indirectely Google through it's financial support of Mozilla. <lfam>No bone-baboon, that's not what it means <lfam>Not every decision is made by the source of money <bone-baboon>lfam: Maybe adding a NTP check box (at the same point as the nss-certs) which is enable by default but can be disable. The issues is when a computers date and time are not correct. Seems to happen with i686 computers. <pineapples>I was in the middle of debugging `seatd' when I discovered that sysrq+k kills some of system proccesses, such as dbus-daemon and syslogd, even though they don't hold TTY fds. Could someone confirm? ***priyanshu is now known as pri
***pri is now known as Guest45995
<lfam>I'm looking at the installer now. I guess I'm not sure how you can use it in a way that leads to NTP being omitted ***Guest45995 is now known as prirai
<lfam>I see, if you don't select any graphical environments, then NTP is not there <lfam>I'm going to see about changing that. It's extremely unusual that somebody would want there clock to be incorrect <bone-baboon>lfam: Yes it is when no graphical environment is selected. However I think it should still be presented to the user so they can deselect it if they do not want it. I do not have it on any of my systems. <lfam>And, do you do something else to keep the clock set correctly? <bone-baboon>lfam: More network traffic and reliance on third party servers. See NTP wikipedia article's Security concerns section. <lfam>I'm familiar with the history security bugs in NTP <lfam>To me, the graphical installer is supposed to guide users along a "happy path" to a working installation, so I think it's fine to enable NTP by default <nckx>OpenNTPd is a thing (a thing which I'd recommend over ntp.org as distro default not because of teh securities, but simply for its size). <lfam>The installer asks users to review the generated config.scm, and advanced users are expected to install manually anyways <bone-baboon>lfam: For me so far setting the date and time has been sufficient. Clock drift has not caused problems for me yet. <lfam>nckx: If we were going to use an off-brand NTP client, I'd suggest chrony <nckx>lfam: I think the installer shows a list of services, some ticked by default, so it wouldn't add an extra step. <lfam>Like, something besides the reference implementation. It's American slang and it's pejorative <bone-baboon>lfam: I think NTP or something like it enabled by default would be fine as long as there is the option to disable in the graphical installer. <nckx>Right, I just don't understand why it applies here. <lfam>OpenNTPD, like many OpenBSD implementations of software grown elsewhere, doesn't implement the full set of network time algorithms <lfam>NTP is *the* network time implementation, and everything else plays catch-up <pineapples>I'm not a fan of dunning and cutting-in, but could someone look into my above-mentioned issue? <lfam>Notably, it doesn't handle leap seconds at all. So, by design, systems that use OpenNTPD will have incorrect clocks at predictable times <lfam>But, it's also less accurate than NTP <nckx>It's time to bust out ‘...and that's the best kind of correct’ again, because... well, it's true. openntpd just keeps your clock set. It doesn't synchronise your home lab to the atomic clock you bought on eBay. Both are valid use cases. <lfam>Sure, it's "good enough" for many use cases, but why choose something is categorically worse at the job <nckx>Doubly so for chrony, which I packaged and use on all my machines but is just objectively overkill. Anyway. <nckx>This is not a discussion that will end in a result. <lfam>I think in the long run, NTP will be replaced by something else. They failed to develop a community around the project and already the algorithms are not understand by anybody <nckx>Huh. Apparently chrony is the default in RH distros, which I didn't know. <lfam>Yeah, and it's used widely in embedded systems <nckx>When you must have all the microseconds. <lfam>Or, a development community that is funded... <lfam>bone-baboon: I don't think that the graphical installer should let non-expert users easily install broken systems. <avalenn>nckx: I was just lagging. Sent before seeing your msg. <lfam>Already, experts can edit the generated config.scm, or install manually <lfam>The graphical installer should guide people to a happy conclusion <nckx>I agree FWIW. Any ntp daemon is part of a good default base system. <lfam>(My memory is that Intel funded and hosted chrony, but I can't find evidence of that. Maybe I'm wrong, maybe things have changed) <lfam>(It's clear that it's well-funded) <nckx>avalenn: Gotcha, thought you might be referring to something on that page. <nckx>lfam: Sure, it doesn't matter who funds it. <lfam>What matters is that it is <lfam>It's a tragedy that NTP is not, but we can't change that <lfam>I'm working on a patch for the installer now <darth-cheney>Hey all, back with a couple more newbie questions about guix environment <darth-cheney>So guix environment --ad-hoc basically creates an ephemeral environment and then launches a shell that has all the correct env variables mapped,correct? <darth-cheney>I am an emacs user and wondering how I could use ad-hoc (or otherwise) guix environments in, say, eshell <darth-cheney>I have added the emacs guix package and that seems nice for installing and exploring packages but it's unclear how to do even an ad-hoc environment <lfam>I recommend doing that, and I also recommend experimenting by running `env` within the environment to see what has actually been done <lfam>Your questions are a little imprecise, so I'm not sure exactly how to answer them <lfam>Basically, a simple invocation of `guix environment foo` creates a development environment for foo. It's ephemeral and uses environment variables to achieve its goal <lfam>`guix environment --ad-hoc foo` makes foo itself available in an ephemeral environment <lfam>When we say that the environment is ephemeral, that means that the environment is created by launching a new interactive shell with some environment variables set <lfam>As soon as you quit the shell, the environment is lost. However, the work required to create the environment is cached in /gnu/store, so the next time you try to use the same command, it may launch more quickly <lfam>I hope that helps, and please ask more questions <darth-cheney>lfam: Thanks. Sorry for being unclear. I'm trying to determine how I could use an ad-hoc (preferably container-ed) guix environment within emacs without having to use a bash shell <lfam>Gotcha. I'll leave that question to the Emacs users :) <lfam>I'm sure it must be possible <jackhill>darth-cheney: I don't know of how to do that, sorry, but would certainly welcome such a feature :) <apteryx>nckx: have you restarted the tunnel with overdrive1 ? <apteryx>nevermind; for some reason even the ssh tunnel is up the offload test ends up failing after a while <civodul>apteryx: there's no tunnel to overdrive1 <apteryx>ah, I see it's exposed via wireguard over the 10.0.0.3 ip, correct? <leoprikler>darth-cheney: At the moment you'll have to pack coreutils and gzip into your emacs container, but with wip-emacs you will no longer have to <lfam>nckx: I sent a patch about NTP and the installer <leoprikler>aside from that, you may want to preserve some additional env vars if you plan on using containered emacs with X, but if you don't it works just fine <lfam>nckx: Oh, I just realized that it's not doing what I meant. Sorry for sending a broken patch and pinging you about it :( <lfam>There will be a revised patch soon <apteryx>civodul: fun, it is 10.0.0.3. I think I got some old comment in the /etc/guix/machines.scm file that induced me in error. I'll update that file. <civodul>apteryx: it even has a DNS entry, overdrive1.guix.gnu.org :-) <apteryx>I guess that way of doing things preceded its wireguard setup <apteryx>ah, so the machine that needs a tunnel hops through overdrive1, hence my confusion <yoctocell>Is there a way to refer to the output path of a package in the `#:configure-flags' argument? Something like `(#:configure-flags ,(list (string-append "--with-xserver=" "/gnu/store/...-xorg-server" "/bin/X")))), but I want the /gnu/store/... path to be inserted automatically somehow. *nckx apologises for defending ‘recent btrfs’ as a usable file system in this channel a few weeks ago. It is a broken toy. Use ext4 until something replaces both. <nckx>lfam: All good! I was out running anyhoo. <lfam>Did something happen to your filesystems nckx <nckx>You regular sherlock you. <nckx>If a user fills up /, btrfs remounts it read-only and refuses any admin rw re-mount to simply delete the offending file. <nckx>You have to reboot the system, then hurry to delete it before the driver notices and remounts it again (= documented answer). <nckx>I rebooted, the machine didn't come back up. <nckx>But apart from that I had a great day and I hope the same for all of you. Good evening, Guix! <lfam>I fill up a btrfs /home partition somewhat frequently, but nothing seems to go wrong <yoctocell>Never mind, using (assoc-ref %build-inputs "xorg-server") worked, I must have done something stupid before... <nckx>There wasn't any ‘weirdness’ in the logs, just straightforward ENOSPC → remounting read-only, which seems to be intentional behaviour. I can't, of course, investigate now :) <nckx>lfam: I'm glad to hear that it's at least possible. <lfam>Make sure to create enough inodes for your new ext4 filesystems ;) <apteryx>nckx: from the internet: If it goes readonly, there is a more critical error than no space. If it were merely out of space, it'd give you ENOSPCs. <nckx>Ironically: been unable to reproduce *that* bug even semi-intentionally (stopping short of creating a deliberately tiny fs). <nckx>apteryx: If the Internet shows this error logged, it wasn't. <nckx>If there are reports of enospc leading to something bad that *doesn't* show up in dmesg I'm inclined to believe them now. <lfam>Just curious, which kernel series were you using? <nckx>fsck (you can fsck a mounted fs with --force) returned no errors though. <nckx>I wish I could answer lfam. <lfam>Sounds like a really bad day <nckx>Good news is it's hosted next to the borkèd Overdrive so I can tend to it tomorrow. I hope something was logged that I can report upstream, but chances are slim. <lfam>jackhill: Usually, it means that the file you have selected for substitution does not exist <lfam>I would add something like (pk (getcwd)) immediately before the substitution <lfam>Or something like (invoke "ls" "-la") <nckx>[still swapping in Guix knowledge] Does cmake-build-system build in a build/ tree? <lfam>Yeah, that's what I'm getting at <lfam>I think that jackhill is mistaken about which directory things are in <lfam>Which directory things are in, and which directory the substitution is running from <lfam>I'm gratified to know that even ci.guix.gnu.org takes forever to compile webkitgtk on a single core <lfam>I hope it doesn't time out :( <apteryx>nckx: Was the system unrecoverable even after managing to free some space? <nckx>apteryx: I couldn't free any space because there's no way to remount rw, the accepted answer on-line is ‘reboot’ (although I welcome alternatives if you've found any!), and the (remote) machine never returned from that adventure. <apteryx>ah, OK, so you don't have physical access to the machine <nckx>I tried resetting the superblock error flag but was (biased me sez: justifiably) cautious about changing a file system under a running kernel, even if ro. <nckx>I used to have time for the consequences 😉 <jackhill>lfam: ding ding ding that was, of course, it. Does substitute* "../source/src/main.c" look like an ok thing to do? (it works with that) <lfam>jachill: Yup, I've done that kind of thing many times :) <lfam>It's maybe more idiomatic to use (with-directory-excursion "../source" (substitute* "src/main.c" ...)) <nckx>It's good that your nastydar goes ding about hard-coding that, but it's commonly accepted, and it's not like the build system is going to change that name any time soon. <lfam>Yeah, I used with-directory-excursion in Syncthing, but I use "../foo" more often <lfam>I just wanted to give a tip <lfam>Or maybe you weren't talking to me <jackhill>lfam: nckx: thanks, yeah, I think if I had to multiple things in that dir with-directory-excursion would look more attractive. If the directory changes, this will fail the build, so it won't go unnoticed. <jackhill>Now to decide if a comment is nessisary for why I'm duing this substitution. The phase name is "reference-nvim" and its purpose is to patch in a absolute reference to a dependency <lfam>That sounds clear enough <lfam>Think about it from the perspective of the reviewer <nckx>lfam: The first was for jackhill, the second unclearly for you. <apteryx>I hope you'll be able to bring it back to life without too much trouble in person! <apteryx>don't hesitate to drop in #btrfs for help, people there (many of them btrfs dev it seems) are keen to help <nckx>apteryx: I did have that open, also ‘First, unmount your filesystem. We cannot operate on a read-only filesystem.’ However, I really appreciate how everyone's so supportive. Now that the RedVision has subsided I consider mine a bit of a low-effort rant. <lfam>I would be feeling really bad if this happened to me nckx <lfam>It would ruin at least my day <chikamungus>I had difficulty installing guix system with an encrypted filesystem... I could enter the password the first time but the second time, my laptop keyboard wasn't functional - it seems to be a usb keyboard! <nckx>It was pent-up energy after staring & thinking for half an hour in mild panic, for sure. I have backups, but they will take days to restore. <nckx>*would; let's be optimistic. <chikamungus>I tried adding a few relevent kernel modules at boot but nothing worked for me. I ended up reinstalling with an unencrypted fs but if anyone has any good ideas about what i could have done, I'd be interested. I have had about 10 years away from linux so go easy with me! <jackhill>ok, I think I'm done tweaking things now. Sorry about forgetting in-reply-to for git-send-email and breaking threads for folks. <jackhill>chikamungus: I don't have any good advice for you, sadly. I've experienced the oposit problem (where grub didn't activate my usb keyboard (if it was plugged into an exteral hub instead of directly), but linux would) <nckx>chikamungus: Would you remind fleshing out that report and posting it to bug-guix at gnu.org? It sounds like you ran into a real bug™. <nckx>‘it seems to be a usb keyboard’ = it is, or it isn't but acts like one (by requiring extra drivers or whatnot)? <chikamungus>nckx: sure. I might not be able to give a thoroughly technical report as I"m effectively a newbie but will do my best <nckx>That's fine, chikamungus. Just give as many details as you're comfortable with. <nckx>And attach a copy of the broken system configuration. <bone-baboon>lfam: That is me. I just sent an email with more information on it bug#47964. <lfam>I linked to the wrong bug report :( <chikamungus>I don't have the config as I reinstalled without encryption <nckx>That's unfortunate but also life. <lfam>civodul: I'm comparing the derivations, and there are many differences <lfam>Like, the derivations of dependencies are different, too <bone-baboon>If there is any more information I can provide for bug#47964 I will. <civodul>lfam: it's likely caused by a wrong #:imported-modules down the road <lfam>In what context would those imports be? <civodul>as in commit 77eaf5fcd1e9d64c52f6d42d44a5d1ea72344d4e <civodul>(on core-updates you get a warning if you get that wrong) <civodul>lfam: false alarm: these are different derivations but they produce the same outputs <civodul>so the different is due to fixed-output derivations <lfam>So, I'm on a wild goose chase <lfam>Working on the installer is a pleasure <civodul>i'm not sure if the bit on the installer is ironic or not <civodul>i think it's a good idea to have well-identified roles/teams <civodul>we have that for some things, like /security, but not all <lfam>I'm never sarcastic about stuff like that! <civodul>i like the installer, it's pretty cool ***sneek_ is now known as sneek
<Noclip>phase `install' fails with "install: cannot create directory '/usr': Permission denied". <lfam>civodul: Do you think you'll reply to the webkitgtk issue? I'm not sure I understand the situation fully enough <lfam>Noclip: Indeed, there is no /usr directory on Guix <nckx>Noclip: No, the build system just needs to be told where it *can* install things. <lfam>The program's build scripts should be amended to make this configurable. In fact, most are, and they use the PREFIX variable for that *nckx → 😴, good night my gooey exes. <Noclip>Is this then my issue or did the programm developer something wrong here? How do I fix this? <lfam>Noclip: Please link to the source code of the program so that we can help you <lfam>In general, help us help you, by providing as much information as possile <lfam>Noclip: Set the PREFIX variable in #:make-flags <lfam>If you search existing Guix packages, you'll find many examples <lfam>This should work because the bees Makefile honors this variable <civodul>lfam: re webkitgtk, it's a build failure, and i have nothing to say on this topic <civodul>i've never fiddled with this package <lfam>I'm not sure there aren't some other errors that weren't included in the bug report <lfam>I've never seen this package fail to build <lfam>But, I'm testing it with -j1 regardless <jackhill>perhaps I should submit that patch to guix-patches. Not sure I'm so happy about all the substitutions, but I don't think it provides another way :/ <Noclip>jackhill: Yes, I'm working on it and at the same time learning guix packaging. <Noclip>jackhill: Is your package definition working? (You said you got distracted so I assume it's not?!) <jackhill>Noclip: awesome, worthy exersize. I'm going to submit my patch to the patch tracker, and perhaps we can collaborate there. Unfortunately, I found bees to be a bit more fiddly than other software since it doesn't have a good way to inject a lot of things autotools configure would take care of. <jackhill>Noclip: it builds and all the files look good, and it can find its libraries, but I haven't run it against a filesystem yet. I was going to do that via a proper Guix service, but I didn't yet know enough about services then. <bone-baboon>lfam: I included all the errors I had in the bug report for bug#47964. I have just done another pull and am trying to do a reconfigure. webkitgtk is being built right now. For this reconfigure that is building it I did not specify cores or jobs. <Noclip>jackhill: Your definition is already much much longer than mine but mine still fails on installing. <lfam>How much memory does your computer have, bone-baboon? <jackhill>Noclip: well, maybe mine could be made shorter, or perhaps you can get inspiration from mine of how to fix the problem in yours. I'm not attatched to mine, so if you come up with a better version :) <bone-baboon>lfam: On the computer building webkitgtk 8GiB installed but `free` says something less than that as total available. <lfam>That should be enough bone-baboon <lfam>I just wanted to make sure it wasn't something way too low like 1GiB <lfam>However, sometimes there are errors hundreds of lines before the end of a log <lfam>Did you search exhaustively? <Noclip>jackhill: However as I also had issues with util-linux and the uuid the main developer of bees (Zygo) made some patches today and removed the dependency on util-linux. According to Zygo util-linux isn't used in bees since a long time but the compilation process still referenced it as dependency ... <bone-baboon>I have the full log but it was too big to email how would you like me to send it? <lfam>Is it too large even when compressed with xz? <jackhill>Noclip: that's good that the last bits of the until-linux dependency got removed <pkill9>i like that guix environments are just stored as guix profiles <jackhill>Noclip: some comments: look what I did with "CC=" ,(cc-for-target). That helps us for cross-compiling. Also, we try to package released versions of software in Guix. Hopefully there'll be a 0.6.6 release soon :) <Noclip>How do I add a new line with "check:" to the end of "Makefile"? <lfam>Noclip: Why would you do that? <Noclip><lfam "Noclip: Why would you do that?"> Because that solves the next issue. <lfam>Okay... adding Makefile targets is not something we usually do in Guix <rekado_>Noclip: do you just want an empty check target to be added? <Noclip>(Already tried it with --with-source) <lfam>We prefer to adapt our package definitions rather than change upstream files, when possible <rekado_>Or do you just want the check phase to be skipped? <Noclip>lfam: Also Zygo (the bees main dev) told me to do so. <lfam>But, what is the goal of this change? <jackhill>Noclip: for bees, the checks can be run with adding '#:test-target "test"' to the arguments <lfam>Is that the reason? Because `make check` was failing? <Noclip><lfam "Is that the reason? Because `mak"> Yes. Without that it fails with "make: *** No rule to make target 'check'. Stop." <lfam>I see. jackhill has the solutoin <lfam>Adding a new make target to work around the problem is not what we'd prefer <bone-baboon>lfam: Compressed the build log for webkitgtk with `lzip --best`. I have emailed it. <Noclip><jackhill "Noclip: some comments: look what"> This is my first self made package definition and my main goal with it was to get it at least working. Making it as clean as possible and then adding it as pull request to the repo wasn't my goal at all. <Noclip>I did however plan to share it here so that someone who has a bit more experience and knows how to make clean guix package definitions could clean up my definition and then add it to the repo. <lfam>From 200 megabytes to less than 1! <Noclip><lfam "From 200 megabytes to less than "> Can't remember ever having seen such a great compression ratio! <Noclip>lfam: Do you mean typical as "typical" or as "can happen with text" here? <lfam>I mean, text is highly compressible with LZMA-type compression <lfam>The algorithms are designed for text, and text is already an extremely compressed form of information <lfam>And for files like this, there is not much variety within the text <jackhill>Noclip: that sounds like a good goal. I didn't mean to rain on your parade. Hopefuly what I shared can help you learn. I feel bad about letting languish on my computer for so long. <lfam>It's basicaly the same words and lines repeated over and over again <civodul>lfam: how 'bout merging wip-ungrafting? 73% vs. 84% for master <civodul>we merge, leave IRC, and come back in two or three days <lfam>It seems to have stalled building <lfam>There's been ~9000 scheduled jobs for a while now <lfam>But, jobs have been completed recently. So maybe it's not stalled, but just running very slowly <Noclip>jackhill: "I didn't mean to rain on your parade." Yea, I was aware of that (or at least guessed it). <lfam>I don't know, civodul. I'm not feeling confident about it <civodul>lfam: ah yes, i think it's only aarch64-linux jobs being queued, with just one worker <lfam>I need to examine the Data Service to get a more complete understanding of it <Noclip><jackhill "Noclip: for bees, the checks can"> I think that did something different than my quick and dirty solution. It was a fraction of a second slower and threw much more log information to the console. <lfam>bone-baboon: I see many results for this error when googling <lfam>Seems like every distro hits it <lfam>I guess the solution is "don't use -j1"