<char[m]>apteryx: Do you know how to get a backtrace out of `make`? <PotentialUser-93>I am having issues building apache maven. i am trying to troubleshoot following the manual. What commands would i invoke to see where the build process fails? <yewscion>Hello Guix, bit of a weird question. I'm still learning gexps. Is there a way to add a gexp to a profile as though it were a package? That is, so that the /bin in the output is merged will all installed packages? <Guest9148>in linux where are the binaries of the guix installed programs ??? <char[m]>I found that if I remove my code, it compiles fine. Then if I add my code back, it compiles fine. If I then run make -B (recompile everything), I get the module issue. <char[m]>Guest9148: each binary will be in its own folder in /gnu/store/<package-specific-folder>/bin/<package-binrary> <char[m]>nckx: It is for the logs then. Then again, that inforation should be findable without irc. <nckx>‘Installed’ programmes are all collected in ~/.guix-profile/bin. <char[m]>nckx: I was about that add that same tidbit 😁 <nckx>I was intrigued by their level of confusion. <nckx>I hope they found answers, or the logs. <char[m]>nckx: Do you have any idea about my modules problem? it is very frusturating. <apteryx>char[m]: perhaps if you share what you have, we could figure out what the problem is <sleepydog>yewscion: yes, you can add a gexp to a profile. for your specific example, i would use the file-union type from (guix gexp) <sleepydog>depending on what you're doing, it might be easier to wrap your head around building a package with `trivial-build-system` instead, though <yewscion>sleepydog: It seems I'm missing some other part then, because it looks like `file-union` returns a computed-file as well. I ended up using an entry in the `home-files-service-type` to point to a binary using the `~/.local/bin` I refuse to get rid of, which works, but seems very clunky. I have a gexp that creates a symlink in its own spot in the <yewscion>store to point to another spot in the store, and I'd like that symlink to be in the `$GUIX_PROFILE/bin` directory. Is there a way I can do that without building a package? <sleepydog>yewscion: sorry, i conflated computed-file with a gexp. i'm not sure how to do what you're saying. i know how to build a profile with file-like objects in it, but i don't know how to make that profile the active profile <sleepydog>if i had to do what you're saying i would construct a package with trivial-build-system and the (guix build union) helper to build a package that is the union of multiple gexps <yewscion>No, thanks for responding! I tried searching a lot, it doesn't seem like something that's documented, or expected. <yewscion>Awesome! Thanks for the link. Always looking to learn something new! ***Guest7325 is now known as yewscion
<swaraj-[m]>hello, i'm new to guix and wanted to try out guix home (i'm running guix on a foreign distribution). from the documentation i can't quite tell if there's a subcommand to generate a home directory into a specified location, so that i can check to make sure everything looks fine first before actually having it replace all my dotfiles (which i know it backs up anyway, but i'd prefer to not move them around here and there). so far i only see <swaraj-[m]>`guix home reconfigure`, but is there a version of it that builds but does not switch immediately? <swaraj-[m]>ah, thanks. i can't see in the manual and just want to clarify, would the command look something like: `guix home build my-home.scm ~/test-home`? <swaraj-[m]>oh, but where will it build it to? ~/.guix-home? <swaraj-[m]>ah, i see, it output the location of the built home directory, which is in /gnu/store, thanks a lot! <civodul>swaraj-[m]: yw! yes, "guix home build" just prints the location of the build result, it doesn't modify your home or anything <swaraj-[m]>i should have googled better, thanks, it looks really well written :) <DivanSantana>with chromium in guix system, can one install extensions? I'm pretty sure it's not recommended, but is it still possible? <civodul>if these are pre-built binaries like .so files, it may or may not work i guess <rekado>DivanSantana: we have some extensions for chromium packaged. I don’t know if you can install them without Guix. <florhizome[m]>I need to patch a go package but the files are not writable. Should I try to do it in the arguments field? <jpoiret>florhizome[m]: see the many 'make-files-writable phases in the gnu/packages/*.scm <florhizome[m]>not sure how to do in (patches), especially since I already have a wrapper procedure around (search–patches ..) <jpoiret>can't you do so after the 'unpack phase instead? <civodul>i hear NixOS now has a graphical installer based on Calamares <rekado>nobody will take away your minimal installer :) <nckx>sneek: later tell char[m]: Oh, I was away. As Maxim says: it might help if you share the offending file/diff. <jpoiret>civodul: we'd need some sort of graphical stack inside the installer for that <jpoiret>but it looks neat definitely, i thought calamares wouldn't flexible enough for that <rekado>calamares was brought up on guix-devel in May 2020; mothacehe pointed out that we’d have to write Python/C++ to use these installer frameworks, whereas now we have everything covered with just Guile. <civodul>rekado: that's a compelling argument for me :-) <rekado>simple solution: release guile-calamares! <rekado>(might require writing guile-calamares first, dunno) <civodul>there's no shortage of fearless hackers out there! <apteryx>'make check-system TESTS=jami-provisioning' is finally passing, phew! It's a big chunk of code rewrite, so I'll send it in for review <apteryx>I used the guile-ac-d-bus library, which turned out to be excellent <apteryx>thanks! was there other system tests failing to fix yet? <rekado>I remember seeing an email about some ldap test failing…? <apteryx>didn't know we had an LDAP server in Guix :-) <civodul>maybe wait-for-service can help fix those tests that just relied on the previous 'start' semantics <rekado>that’s the name of the ldap server <apteryx>civodul`: was the elogind issue fixed definitively? I had patches to poll with 'dbus-service-available?' procedure to wait for a D-Bus service to be up, perhaps that could be useful if there's still something to fix <apteryx>it would basically be adding (with-retries 25 1 (dbus-service-available? "org.freedesktop.login1")) at the end of the start slot of the elogind-shepherd-service, to ensure the service is up before dependent services are started <apteryx>the dbus machinery now being made available from (gnu build dbus-service) <peterpolidoro>I would like convert a set of packages to guix. there might be a 100 or more packages that get released in separate versions they call "distributions", with string names such as "galactic" or "humble". If I wanted to have multiple distributions within guix at the same time, would each package get a name like "package-0-galactic" and <peterpolidoro>"package-0-humble"? Or is there a way to use the "@" symbol to refer to them like "package-0@galactic" or "package-0@humble"? Or is the "@" symbol only for numbered versions? <nckx>Without addressing the (in)sanity of the distribution model itself: package-0-galactic it is. <nckx>(You probably *can* abuse the version field for that, and it will probably ‘work’, but it's abuse.) <peterpolidoro>ok, thanks! how is the version field supposed to be used then? <peterpolidoro>do you mean that it makes more sense to always use rolling releases rather than fixed distribution versions? <jpoiret>peterpolidoro: rather, don't those distributions have some version number aside from the codename? <peterpolidoro>maybe, but everyone in that community uses the codenames to refer to a particular distribution rather than any number. I am hoping to convince members of that community to start using guix and do not want to confuse them <peterpolidoro>this is for the Robot Operating System (ROS). I have a fantasy of adding all of their packages into Guix, but that is thousands of packages so it would have to be automated <peterpolidoro>They now also have a rolling release, but lots of people pick one particular distribution and use that for a few years until switching to another <peterpolidoro>so I could add both a "package-0-humble" and a "package-0-rolling", although perhaps in guix it would be better to leave off "-rolling" and just use "package-0" for the rolling release <peterpolidoro>or maybe the humble packages do not need to be added separately and versions could just be fixed by a channels.scm file <jackhill>peterpolidoro: fist: wow, that sounds like a large undertaking, but very cool, thanks! I like nckx's suggestion best so far. It seems like the package will have version numbers, which might even get incremented over the life of the distribution, so our version field would be good for that. <jackhill>Another example of this sort of thing (which I think could be loosely described as external curation) that we do in Guix is LTS Haskell. However there, I think we only package one LTS version, so don't have to model having multiple in Guix. <jackhill>there's also texlive, but I'm sure that's not a good example of anything 😜 <jackhill>actually it would be cool to have "epoch" or Most Significant version handling in Guix. Then i could package@major-version without having to worry about matching the point release. <jackhill>That's not what I recally, but I should try it again. My memory could very well be faulty <rekado>guix install samtools@1 will install the latest 1.x release; @1.0 will get the latest version wwith a prefix of 1.0 <jackhill>and samtools @0 works too, of course. Sorry for the confusion <peterpolidoro>I guess one problem with locking a set of packages at a particular release version is that the underlying dependencies may slowly become incompatible. <jackhill>peterpolidoro: seems like it might be worth a thread on guix-devel@gnu.org. I suspect there's wisdom out there in the community that is not active here at the moment. <peterpolidoro>Can you lock a package to a specific dependency version? Seems kind of anti-guix to have a big set of packages and dependencies that never change, but it would still add all of the other conveniences of guix <rekado>peterpolidoro: you can use inferiors to pick individual packages from the past <rekado>as time passes you’ll pull in more and more old stuff: old toolchains, old libraries, old dependencies <peterpolidoro>this would be a huge undertaking, but perhaps possible with enough automation <jpoiret>peterpolidoro: general wisdom though is: don't use old dependencies <peterpolidoro>so is it a foolish idea to try to preserve their concept of distributions in guix? <jpoiret>it might sometimes be annoying, but it's really better to update a project to use the latest available, as often packages are updated in guix <lechner>Hi, what's a good way to check how many patches on -patches have not been processed, and whether a planned submittal might already be pending, please? <jpoiret>well, depends on what they mean by distribution, if they handle all low-level libraries, i guess it'd be a bit foolish imo <jpoiret>that would be like asking if we could add debian 9 to guix <peterpolidoro>I think they rely on an Ubuntu distribution to handle the low-level libraries <peterpolidoro>and then say that one of their distributions only works with a particular Ubuntu distribution <peterpolidoro>I could just try to package the rolling distribution, but many people in that community would not use Guix if they could not fix their packages to a particular ROS distribution <peterpolidoro>oh well they also try to make it work with windows so maybe they package everything <unmatched-paren>seems likely, in particular, that it would also work with the debian that that ubuntu was based on <unmatched-paren>i hope they don't, but given how many projects have completely insane packaging procedures i wouldn't be entirely surprised <peterpolidoro>I would hope that once they see the power of guix then that would become the prefered way of installing their packages for many people <apteryx>peterpolidoro: if you want to lock the whole graph you could use inferiors <apteryx>they can be defined per package. I don't use them, and it's probably inefficient, but they're designed for that use case <unmatched-paren>partially due to the (good!) free software only policy, and possibly instability caused by the rolling-release model <peterpolidoro>it just seems painful for me to go back to other methods of installing packages once I get spoiled on guix <peterpolidoro>so I wish I could convert all software I need to guix packages <jpoiret>i don't really understand, what does ROS actually contain? maybe that could help us grasp if it's really guix-compatible or not <peterpolidoro>free open source libraries for sending messages between components in robots <peterpolidoro>they use the data distribution service to send messages between a set of distributed nodes <apteryx>if it's free software, it's welcome in Guix <peterpolidoro>so a camera might send image messages to a image analysis node <jpoiret>hmmm, and do you know if their projects really require fixed dependency versions that we don't have, or if it would compile well with what we have? <peterpolidoro>I would hope that most packages are pretty flexible about dependency versions <peterpolidoro>but they want one of their distributions to be valid for like five years <jpoiret>then there's 0 issues with it being in guix then (if it's FSF, i see something about drivers), don't let the "distribution" term scare you <jackhill>I understood their distrubutions and version of ROS software that work well together and don't break functionality over the life of the distribution. That's why I thought haskell/stackage LTS was a good analogy <peterpolidoro>I dont know if you fixed the top level packages at a particular version and let the underlying dependencies change over five years if gradually many packages would break <jpoiret>how about only having the latest distribution in guix, and if someone wants to use the older they can just time-machine? <peterpolidoro>yes that might be the best way, then there could just be a "humble-channels.scm" file that allows you to time machine to their humble distribution <peterpolidoro>but then again it might be nice to be able to update some of the low level dependencies <peterpolidoro>but it has become very popular in the robotics world so it would be great if guix could be an option for the many people who want to use it <peterpolidoro>the rigs do not look like traditional robots at all, but they do have sensors, actuators, and processing nodes <peterpolidoro>but lots of people use it for drones or warehouse or industrial robots <apteryx>rekado: in the purge-python2-packages branch, I had "4e2ff5a8fc gnu: non-session-manager: Replace with new-session-manager." The later appears better maintained and a near drop-in replacement. I suggest we keep non-session-manager as obsoleted by new-session-manager. What do you think? <apteryx>(without removing 'non-session-manager', since you've now fixed it to build with Python 3) <rekado>we still have all the other non-* things that inherit from non-session-manager <apteryx>synthv1, drumkv1, samplv1, padthv1 will use new-session-manager instead of non-session-manager <apteryx>and non-session-manager will be marked as superseded by new-session-manager <apteryx>sneek: later tell civodul by the way, if you apply https://paste.debian.net/1242590/ on top of the patch fixing the jami test, you'll see the test failing, which suggests something is not right with either Shepherd or Jami (haven't investigated) <zimoun>Where is defined ’map1’ from Guile? <drakonis>rather, the only map1 definition that isnt like the others is the one in rnrs/base <drakonis>no definition that can be invoked in code <drakonis>as happenstance, it is all used inside map <zimoun>drakonis: thanks. So when debuging, ’map1’ can be replaced with ’map’, IIUC. <char[m]>Here are the steps to reproduce my module issue: make -B, add "(display glibc)" anywhere in the toplevel of haskell.scm, make. This results in `ice-9/eval.scm:293:34: error: glibc: unbound variable <char[m]>hint: Did you forget `(use-modules (gnu packages base))'` <sneek>Welcome back char[m], you have 1 message! <sneek>char[m], nckx says: Oh, I was away. As Maxim says: it might help if you share the offending file/diff. <lechner>Hi, can i run 'guix lint' in a repo i cloned in order to submit patches? Thanks! <vagrantc>after doing all the ./bootstrap && ./configure --localstatedir=/var && make ... dance <lechner>hi, thanks! should i be branching in my main 'guix pull' repo instead (wherever that may be located)? <vagrantc>my workflow is basically to have a local git checkout, that i then always guix pull --url=/home/vagrant/src/guix --branch=master ... that way guix pull doesn't re-download what i already have <vagrantc>requires keeping the master and keyring(s?) branches up to date in my local copy <vagrantc>well, it does download it, but from the local copy <vagrantc>and then using a different branch for each package and/or patch series <lechner>they are only version updates for linux-pam and nyacc <vagrantc>long as you're clear about what you're doing <vagrantc>i also included RFC in the subject one of my recent submissions, spelling out everything i knew was wrong with it :) <apteryx>do you mean like unfinished work for someone to take over? <lechner>without running through the whole checklist. i also do not plan to fix "lonely parentheses" errors that have been tolerated hitherto <apteryx>you shouldn't drop your patches there expecting others to be willing to do this work fo you. perhaps you can share them on guix-devel, and if there's someone interested they can pick it up, but I wouldn't put a burden on Guix reviewers otherwise. <unmatched-paren>lechner: you mean there's unmatched-parens in the files? they should not be there... <vagrantc>lechner: i mean, run through as much as you can, but as long as you're transparent about what you have and haven't checked, it seems better to share than now <lechner>unmatched-paren: just lonely gnu/packages/linux.scm:1600:0: linux-pam@1.5.1: parentheses feel lonely, move to the previous or next line <vagrantc>"lonely parens" are when style recommendations would suggest the parens be moved to the previous line, but are syntactically identical <vagrantc>apteryx: ah, so my RFC patches should've gone to guix-devel instead, maybe? <vagrantc>been doing this longer than i realize, and still learning all the time :) <vagrantc>lechner: lonely parens are pretty easy to fix ... or is it an issue that was already there that you don't want to fix to make the patch look more noisy than it already was? *vagrantc finds the recommendation to build for all architectures a little of a steep requirement <vagrantc>and yet, i grumble about how many packages don't build on aarch64 :/ :) <lechner>vagrantc: as a newbie, i wasn't planning on touching anything unless absolutely necessary <lechner>maybe i'll just wait for someone else to update the versions. that'll give me some time to figure out my workflow. <vagrantc>i think nyacc might be at an old version as it's part of the bootstrap chain <vagrantc>though it might be worth adding a nyacc-VERSION to avoid that problem <nckx>lechner: If you didn't introduce the lonely brackets, it's fine to leave them in. In this case the original formatting isn't even indefensible (IMHO). <lechner>nckx: my issue is, i think, that none of the commands like 'guix lint' or 'guix build' run in the repo i'm editing <nckx>Not even with ./pre-inst-env? <nckx>Is there an error we could work with? <nckx>unmatched-paren: use (guix), then (fold-packages cons '()) <nckx>Replace cons with a filter of your preference. <nckx>There's an example in (guix)Running Guix Before It Is Installed (no, I don't know why there of all places). <nckx>I thought (gnu) and wrote (guix). So, the former of course. <nckx>That's where the packages hide. <apteryx>vagrantc: yeah, RFC seems more natural to me on guix-devel, as they're meant for discussion <nckx>unmatched-paren: Yes, because ‘This composite module re-exports core parts the (gnu …) public modules.’ (gnu.scm) <nckx>Hadn't heard of #:select though. <char[m]>Is it possible to deifne a package in a manifest.scm and include it in the environment? <char[m]>nckx: it seems that specifications->manifest is not able to find the package <nckx>No, you can't use spec->man (or spec->anything) that way. <nckx>Just use the variable directly. <char[m]>I see so use packages->manifest and specification->package <nckx>I'd typed up an example but it's right there in (guix)Writing Manifests. <nckx>You can append them if you like. <nckx>You can anything them if you like. It's just code :) <nckx>You could just define the whole (package …) inside package->manifest but I don't recommend it. <nckx>You could read it from the user over stdin. <nckx>Sorry I got carried away. <char[m]>I see your example, but I still get `guix shell: error: sbcl-ninglex: unknown package`, sbcl-ninglex is the package I defined. It doesn't make a difference if I use define-public or just define <nckx>Can you share your actual manifest? <char[m]>my bad, I still had it as a string for specification->package. <nckx>And volunteering for all ‘OMG you removed my $package’ mails for the next week, which is really impressive. <char[m]>Any clue why I'm getting "file exists" error during the copy-source phase. I'm not messing with the phases for this package. <char[m]>It's when It tries to symlink it in the store. <char[m]>I think it might be a caching issue. Is it possible to use just delete that section of the store? I already tried the changing the hash trick. <nckx>Can you share the channel file first? <nckx>paste.debian.net is fine. *jonsger[m] got "his" channel already fixed, was only one package affected :) <rekado>I just purged all python2 stuff from guix-bimsb <jonsger[m]>oef, firefox 101 (released today) requires rust@1.59 :( <jonsger[m]>I fear that firefox 102 (new ESR baseline) which will be released on 2022-06-28 will have this reuquirement as well... <singpolyma>That or higher. Not gonna put it down for a future release :) <nckx>Thanks. Deleting random files is certainly not going to get you anywhere :) <nckx>I've added all the module imports back, but please always share the entire file next time. *nckx is completely unfamiliar with the asdf-build-system, this will take some time… 😛 <char[m]>nckx: The problem is is the copy-source phase which I thought is similar for every build system. <nckx>Mmm, kind of. It's a problem in the sense that it interacts badly with the 'unpack phase. <nckx>I don't pretend to understand why (yet). <char[m]>nckx: I can' believe it kept going after the error, then errored out after the phase finished. Are you saying that the current directory for unpack-phase is /gnu/store/l7pbbpffggdshp896xp4q0ah5v57xzsx-sbcl-ninglex-0.1-0.22a6593/share/common-lisp/source <nckx>No, its cwd is typically the build directory, or thereabouts (exact subdirectory can differ). In this case, in /tmp/guix-build…/source. See guix/build/asdf-build-system.scm for more info if you want. <nckx>(Also, frankly, distracted by pizza.) <nckx>It's worth a bug report if you have the time. A package without arguments shouldn't error out like that. <char[m]>You're a life saver nckx . I'll report a bug later.