<yewscion>From what my inexperienced eyes can see, I don't think anything inside of java.scm sets CLASSPATH once installed. Is this a bug, or is it intended? <jackhill>yewscion: I haven't looked closely, but probably a bug or a missing feature/something we haven't gotten too yet. Packaging Java application and libraries can be a lot of work because of the complicated dependency graphs, so less work has been done in that area. <jackhill>since I don't have a great answer to your question, I recommend taking a look at our ant and maven build systems to see if there are any clues there, and if you don't get a better answer here send a post to guix-devel@gnu.org about if it would make sense to add search paths for Java stuff. <yewscion>jackhill: Thanks, that makes sense. Will do. <nckx>jackhill: rop tat (no space) ***jesopo is now known as jess
<yewscion>nckx: is rop tat (if I remove the space) the Julien that jackhill mentioned? I see that in my scrollback from before I lost connection. <yewscion>roptat: Do You know if there is a package that sets the CLASSPATH environment variable in Guix? And if there isn't, is that intended, or should I submit a patch to have that added to icedtea/openjdk/etc? <zamfofex>nckx: >“Maybe you already know this” Oh, what do you mean? What does ‘sudo -i’ do? ***taiju is now known as Guest9533
***taiju` is now known as taiju
***f1reflyylmao is now known as f1refly
<FlaminWalrus>Anyone know why cargo-build-system would fail to find a crates.io package that most definitely exists? I'm trying to package texlab, the LaTeX LSP server, since it just recently was put up on crates.io, and one of the dependencies pulls in the crate "windows-sys," which causes the build to fail because that crate isn't found. <zamfofex>Hello, Guix! I wanted to say that I was able to overcome the problem I was undergoing. My solution was to add ‘/root/.ssh/id_rsa.pub’ to the authorized keys of the root user to the Hurd VM service’s OS SSH configuration. Now I’m getting different issue when I try to build GNU Hello: “derivation '/gnu/store/…-module-import-compiled.drv' offloaded to 'localhost' failed: chroot builds are not supported on this platform.” <zamfofex>What does that usually mean? I wasn’t getting that kind of error when trying to build from the VM directly. <tomgrzyb>Fatal install errors: I'm trying to install GuixOS for the first time on my Dell PowerEdge T105 (circa 2008). Immediately upon booting V1.3 (either x64 or 686) from DVD, I see this repeating on the screen: Welcome to Grub - (some message that scrolls off) and "waiting for partition '31393730-3031-3031-3039-343934363833' to appear". This <tomgrzyb>message appears maybe 20 times and then I end up in Guile. If I type in ,q to continue, I get a kernel panic. <tomgrzyb>If anyone wants to get in touch with me later, I am at tomgrzybow@protonmail.com <zamfofex>tomgrzyb: Are you trying to use the installer? Or some other built image? <tomgrzyb>The standard install image I downloaded from the home page. <roptat[m]><yewscion> "roptat: Do You know if there..." <- I think icedtea/openjdk should do it <tomgrzyb>guix-system-install-1.3.0.x86_64-linux.iso <tomgrzyb>I know the SATA hard disk(s) are fine, I've had devuan installed earlier. <tomgrzyb>No, do you have any reason to think this might work? <zamfofex>Well, it is more up to date, but besides that, no. <tomgrzyb>I can give it a try and let you know. Bye. <tomgrzyb>Ugh, same failure with the "latest" build. I was able to glimpse some of the error message that scrolled past. Something to do with ERST not available. <tomgrzyb>Let me see if I can get more, trying again... <tomgrzyb>Looks like the bios does not want to give you access to some memory address... I guess... <tomgrzyb>I can be reached at tomgrzybow@protonmail.com if not here... <yewscion>roptat[m]: I have icedtea:jdk installed already, and for whatever reason it is not set. I've worked around it for now by adding an export to my bashrc; I'll `guix shell --pure openjdk` and see if it is set. <bdju>menus (right click or the ones at the top) are not appearing for me in pcmanfm. can't recall if this is a bug that's already been opened. I'm on Sway. anyone else run into this? <bdju>I need to change the sorting option <bdju>oh sorr, pcmanfm-qt I should same <yewscion>roptat[m]: FWIW, I've run `guix shell --pure openjdk env` and `guix shell --pure icedtea env` and the `CLASSPATH` variable isn't set in either. <Guest8848>yewscion, looks like something changed recently ***Guest8848 is now known as roptat
<roptat>yewscion, nevermind, it's unrelated. It seems it's never set by any package <bdju>problem still happens when run from a guix shell <yewscion>roptat: Ah, kay. At least I know I haven't broken anything, then! Thanks for the confirmation. <bdju>looks like I mentioned the issue off-hand in #51826 but not sure if I filed a separate issue for it <yarl>I added a patch to a definition, this builds fine, then I just saw dist_patch_DATA in gnu/local.mk. What is the purpose of this variable? <yarl>I suppose that the patch path have to be there? <sneek>Welcome back mothacehe, you have 1 message! <sneek>mothacehe, civodul says: i'm fine with removing s390x-linux <cnx>hi, is there an eta for 1.4 (or 2.0)? <civodul>cnx: hopefully by the end of June i'd say... <unmatched-paren>anyone know how i should deal with ABI mismatches while compiling guix? <jpoiret>the harder answer is to code a more complete guile compiler that understands compilation unit dependencies :p <jpoiret>it's definitely something that needs to be done wrt cross-module inlining too <unmatched-paren>how do i make a hidden package? i'm changing tzdata and a comment above tzdata-for-tests says: <unmatched-paren>;;; Please make this a hidden-package if it is different from the primary tzdata ***mark is now known as mjw
<a13x5>Hi, everyone! Do anyone know what's the current state of KDE in Guix? <a13x5>I see a lot of kde packages, but not the whole thing. I've heard that there is some problems with it, but I didn't understand what exactly <unmatched-paren>a13x5: there were some people working on it, but it's a big ecosystem with lots of packages required to build the whole thing. there might be other issues too; i've not looked into it. <civodul>a13x5: hi! i don't think there are problems, i think it just needs love and commitment to be completed :-) <tinybronca[m]><civodul> "a13x5: hi! i don't think there..." <- the amount of individual packages pulled in for a complete/full Plasma desktop on other distros is extremely intimidating ***furrymcg1e is now known as furrymcgee
<a13x5>Yeah, I remember compiling it in my Gentoo days)) And it got even bigger since <civodul>tinybronca[m]: oh yes, that's certainly true! <civodul>there's quite a number of them already, not sure how many are missing *rekado attempts to upgrade the refcard <civodul>hopefully the build.scm file in there still works <ennoausberlin>Hi. I wonder if someone tried to run the openjdk 18 on guix. I unpacked the tar archive, but get no such file or directory when I try to run java or other binaries. It might be a problem with no finding zlib because ldd java claims about zlib.so.1 missing. I installed zlib with guix package -i zlib but the jdk still does not find it. Unfortunately <unmatched-paren>ennoausberlin: precompiled things do not work on nix or guix unless you do <something something patchelf> <a13x5>Actually about contributing. How do you guys are testing your changes? <a13x5>For instance - I want bump up docker version, but I want to check that it will work and add new version to the config.scm (since it's a service) <a13x5>Do I need to create a separate channel for that? Or point guix channel to my local git copy somehow <unmatched-paren>a13x5: I presume you've run `./bootstrap && ./configure --localstatedir=/var && make`. In that case there will be a ./pre-inst-env file in the root of the repo <unmatched-paren>which will allow you to use your local guix repo instead of the one you get when you guix pull <cnx>re 1.4 eta: thanks civodul <cnx>unmatched-paren: as a new comer, 1.3 being entirely different from unstable is a bit incommodating to make a choice <a13x5>unmatched-paren I'll try it. Thank you! <unmatched-paren>cnx: you should _always_ use master. 1.3, as you've probably noticed, is extremely outdated :) They're mostly just milestones that we can celebrate. (btw, master isn't unstable; if you want unstable, try staging or core-updates{,-frozen} >:) <rekado>here’s the proposed update to the refcard: elephly.net/downies/guix-refcard.pdf <rekado>civodul: the build script still works fine <unmatched-paren>/gnu/store/f7an6xc4k90cgrznwz2lq67zdzqy293v-tzdata-2021e-builder:1:2410: Unknown # object: "#<" <rekado>unmatched-paren: open the builder and look for #< <rekado>it could be an opaque representation of a record <cnx>thanks, unmatched-paren <rekado>tzdata uses gexps, so I’m not sure if you can just use substitute-keyword-arguments like you do <rekado>the new refcard has some space on the bottom of the second page; any idea what section we should add there? <florhizome[m]>a13x5 civodul guix kde packages are by now severely outdated (the problem is you need to update the whole bunch of them at once) <florhizome[m]>i would suggest to open a kde–updates branch so that people can work on it separately, maybe targeting the 1.4 release. I think several people have additional packages (personally I have kwinft locally, some people have been trying to get plasma mobile for their pinephones together afaik) <florhizome[m]>i believe the handling of qtplugins should be discussed somewhere, too… style engines as well as the wayland platform plugin don’t work reliably and seem to need wrappers or search path definitions. <florhizome[m]>(I don’t think completing plasma on the current basis makes a lot of sense. Also lxqt has had it’s stable release and would probably need newer frameworks for that but idk) <rekado>unmatched-paren: I don’t know, haven’t done it before. <efraim>we could probably make a branch with qt-5 and kde-frameworks updates <unmatched-paren>rekado: i made it work; all i needed to do was replace quasiquote with gexp and unquote with ungexp <florhizome[m]>Unless there is not a somewhat organized/concerted effort for updating kde it will rot away. We are already at a point where guix packages are outdated for new releases of popular programs. <florhizome[m]>For a single user with an old machine it’s just too much too compile, be it for testing or building… <florhizome[m]>efraim are kde packages upwards compatible? Would older apps work with updated frameworks? <unmatched-paren>hmm... seems as if the hashes of the new tzdata-for-tests and old tzdata differ :( <efraim>florhizome[m]: sometimes, but I was thinking of updating not just kde-frameworks but the packages which use them, like kdeconnect <florhizome[m]>efraim yes sure but there are a lot of kde apps (there are even games etc) <florhizome[m]>if it would be possible to update qt5 and kde frameworks first and merge them into master it would of course ease the rest by a lot since we would have substitutes. <rekado>florhizome[m]: you can have substitutes even without merging into master <rekado>just create a branch and ask someone to add it to cuirass <rekado>I do wonder, though, why kde stuff is seemingly so unpopular among Guix users that for so long only one person had been maintaining the packages. <unmatched-paren>Maybe for the same reason that Rust is somewhat unpopular among Guix users ;) <a13x5>florhizome[m] Yeah I've noticed that most kde packages haven't been updated over a year or so. I think first we should update them to at least 5.81.0 <florhizome[m]>I would say normally people try to adhere to stuff that fits their DE and guix has lxqt but it doesn’t work very well for my experience <florhizome[m]>a13x5: There was a submission for 5.84 or so in November which went completely unreviewed <jpoiret>personally, after getting more firsthand experience of what it's like to maintain desktop stacks, complex software platforms and the like, i now tend to avoid using software that isn't easy to package and use <jpoiret>i think for many Guix users it's the same <civodul>rekado: regarding the refcard, maybe we could have "guix home" on that last column? <unmatched-paren>jpoiret: exactly how I feel re. rust. I used to be a fan of it until I realized how utterly flawed Cargo is <civodul>rekado: not enough space for a home-environment example, but at least the "guix home" commands should fit <jpoiret>yes, i actively try to avoid rust/go or even haskell now <jpoiret>even though i've always loved haskell <civodul>time-machine is missing from the 1st page, too <florhizome[m]>rekado i think of the very active guix users most use gnome, some wm or maybe xfce, new users mostly just follow that. After all why would you use guix for plasma or a DE… <unmatched-paren>because before those tools existed, people were using makefiles, so it's quite easy to build ocaml with makefiles <ennoausberlin>unmatched-paren I fear so. If it is not straight forward I am out:/ The package definition does not look too complicated, but I am not sure if just inheriting works. <jpoiret>i think languages or even development tools/platforms in general could benefit from some degrowth activism <jpoiret>many criticism aimed at big tech conglomerates with closed platforms could be applied to some language ecosystems and big software stacks too <jpoiret>if you can't build it yourself, you don't control it, others do <unmatched-paren>for ocaml, you can just make a .cmx with ocamlopt or .cmo with ocamlc i think... you also need to turn mlis into cmis. cmx/cmo is the equivalent of .o files in ocaml. then you can just link them together... <rekado>civodul: time machine is under ‘guix pull’ <florhizome[m]>You do see new people interested in kde or maybe lxqt (Falkon is oftentimes requested) but I think they don’t find others to stick with to actively contribute to make it better <tinybronca[m]><jpoiret> "yes, i actively try to avoid..." <- what is wrong with Haskell? <jpoiret>too many dependencies on small libraries <jpoiret>yes, comonads are interesting, no, i don't want to have to manage dependencies "comonads" "free-comonads" "comonoidal-transformers" <jpoiret>i'd even say "categories-for-haskell" but alas <florhizome[m]>unmatched–paren jpoiret I don’t really agree with the premise though, guix users might detest cargo but guix has a solid amount of crates/rust based packages and the importer works pretty well so you can build what you want <jpoiret>unmatched-paren: it's a monad, but with the arrows inverted :p <jpoiret>florhizome[m]: yes but they're a nightmare to maintain <unmatched-paren>I actually prefer building random C libraries to random Rust libraries. at least the process isn't mind-numbingly dull <tinybronca[m]>unmatched-paren: how does changing compiler make it not dull? <unmatched-paren>florhizome[m]: the maintainence issue makes you far more aware of the general issue: "whoa, are there really THIS many dependencies? All this code is being downloaded every time I build a Rust package..." <jpoiret>tinybronca[m]: i think it's mostly cargo vs. manual <unmatched-paren>tinybronca[m]: with C you generally have to do a bit of research... with Rust it's just "guix import foo", okay, let's try building again, now bar is missing, "guix import bar", etc <unmatched-paren>and of course there are far more Rust packages than there are C packages <unmatched-paren>you come to realize that the inconvenience of using C libraries is healthy! <unmatched-paren>cargo just allows you to write `foo = "version"` in your Cargo.toml, which makes you lazy and careless <maximed>In my experience, rust isn't too bad as long as you stay away from Cargo and aren't doing things like ‘use multiple different versions of the same dependency from the same dependent’ <sneek>Welcome back maximed, you have 1 message! <sneek>maximed, nckx says: (if they care) ix.io works fine here too (TN), but I'm a business customer with a reputation, soo... I'd send them an e-mail just to hear their excuse if it were blocked for me. <unmatched-paren>maximed: how do you stay away from cargo (or are you talking about using antioxidant? :D) <unmatched-paren>antioxidant just allows us distro packagers to not suffer as much pain <maximed>to be clear, what underlying problem are you referring to? <unmatched-paren>maximed: dependency proliferation, which opens the ecosystem up to supply chain attacks <florhizome[m]>unmatched paren yeah but that’s really a different thing as KDE. <maximed>unmatched-paren: antioxidant (partially) helps with that, in the sense that by default you can't have multiple versions of a single library in the resulting binary (unless setting #:metadata <unmatched-paren>it'll absolutely make our lives so much easier :) thanks for working on it <maximed>(reasoning: less versions -> less package definitions -> less opportunities for sneaking malware in) <florhizome[m]>KDE would mainly need a set of dedicated maintainers for the core. <florhizome[m]>which are quite a bunch of packages but it’s doable. These are very different problems then rust/go and other languages. <rekado>but it’s not something that can be mandated <rekado>for other subsets of packages we have been able to self-organize <florhizome[m]>i just didn’t like the framing that it’s the same/similar problem. <unmatched-paren>florhizome[m]: i see the difference you're talking about, but it's more similar than what you're saying imo. far too many interlinked dependencies. of course it's also an issue of general software bloat left unmanaged (qt is massive.) <rekado>one person’s bloat is another person’s required feature. <rekado>complaining about bloat doesn’t lead to package definitions :) <civodul>(you should bump the version number) <civodul>IWBN to add --export-manifest, but it may not fit <rekado>bump the version number as part of the file name? <civodul>tinybronca[m]: it's meant to be printed :-) <rekado>civodul: I bumped it from 1.1.0 to 1.3.0, but it really is for something after 1.3.0 <tinybronca[m]>civodul: I don't have a printer so I will have to rotate this somehow <florhizome[m]>we have qt, it mainly needs to be updated, same for kde frameworks and it’s not like they are spontaneously multiplying :D rust/go are different animals imo <florhizome[m]>I have to say so far if it was just about building, kde packages often have been pretty easy, but I haven’t tried multi package system ones so far. <maximed>tinybronca: Some pdf viewers can rotate things (control+right arrow in Evince) <apteryx>civodul: thanks for the tip about guile-ac-d-bus, I was able to port (gnu build jami-service) to it <rekado>guess I could just bump it to 1.4.0 in anticipation :) *apteryx is thinking to merge the purge-python2-packages branch; which does away with a few still working Python 2 reliant packages; are people OK with it? <efraim>apteryx: I think wicd got fixed/updated, what else was there? <rekado>apteryx: is there an issue in the bug tracker for the Python 2 packages that would be lost? <rekado>I’d like to move those to guix-past then <apteryx>rekado: but, but you could "git log --grep='gnu: Remove' origin/purge-python2-packages", as I used automated commit messages for the most part <apteryx>efraim: I tried hard to fix wicd, but even its latest commit is still a hot mess, so in the end it's gone. <apteryx>efraim: yep: dcaf7e7863 * gnu: Remove wicd. <apteryx>rekado: for your info, the commit messages were automated using the extended guix-committer.scm (or the yasnippet), see commit e2cf29cfac "etc/committer: Teach it how to commit package removal." <efraim>I've started building qtbase-5.15.4 locally. After that builds I'll update the rest of qt-5 locally and see what needs fixing ***jesopo is now known as jess
<rekado>apteryx: pity about the removed LV2 stuff like raul and ingen etc <rekado>these use Python 2 only because they bundle an old copy of waf <apteryx>do you think it would work easily if we tried using Python-3 waf? <apteryx>last released 2011; I guess we're on our own <rekado>yes, but with a most recent commit from last year <rekado>anyway, I don’t object to the python 2 purge. <rekado>if we want to recover old stuff it’s still in the git log <rekado>it will probably affect the guix-science, guix-past, and guix-bimsb channels. <apteryx>I guess a few core python2 things will need to go to guix-past <apteryx>are the other channels already using guix-past? <rekado>guix-bimsb is; haven’t checked guix-science. <apteryx>at least from a Guix-centric point-of-view, the branch seems to fix things more than it breaks, judging from https://ci.guix.gnu.org/ (78% built vs 71% for master) <civodul>apteryx: hi! i haven't checked the python2-purge branch, but that sounds like a good idea <civodul>apteryx: it'd probably make sense to send a heads-up to guix-devel if you haven't done it already <civodul>to make sure interested parties have a chance to weigh in <civodul>apparently Guix-Past relies on python2-{pillow,numpy,scipy,matplotlib} <PurpleSym>I can fix guix-science if there are any issues, no problem. <rekado>guix-science uses python2-pysam python2-numpy python2-pypdf2 python2-argparse python2-pyflow <rekado>sadly guix-bimsb has quite a few more, but I wouldn’t mind purging packages there as well. <PurpleSym>And “fix” here means removing the offending packages, because they are the product of scientific research and thus – sadly – not maintainted. <apteryx>I've now sent a message to guix-devel about it; I intend to push it tomorrow or after tomorrow unless there are voiced concerns :-) <civodul>BTW, 'staging' looks good on x86_64 (92% coverage or so on x86_64) <civodul>i'll send a heads-up too but i think we should merge it real soon <apteryx>sounds good, although let's try to fix our system tests (I've been trying to fix the jami one, I think I'm making progress) to ensure things keep working :-) <civodul>so maybe we should set up a jobset for the system tests of 'staging' <rekado>I think commit 48efbde7a944acfe4fc944bf27bfa9ff82592024 broke things. The new patch is not listed in gnu/local.mk <efraim>civodul: I wondering if we should drop python-cryptography to 3.4.8 and punt on it using rust for now <efraim>rekado: probably. I fixed it a few commits later <civodul>efraim: maybe we can keep both versions? <efraim>do we have things that need the newer version? <civodul>apparently there are zero dependents <efraim>also, do we actually need multiple versions of python-cryptopgraphy-vectors? <civodul>i know next to nothing in this area, but i think we should arrange not to lose work that's already been done <efraim>I'm seeing ~3100 dependants of python-cryptography on staging <civodul>efraim: oh sorry, i was looking at master <civodul>well yeah, maybe punt on the Rust-based one then (keep it as a separate version) <efraim>Its basically the same problem we have as with librsvg, except there's no bundled rust to fall back to <civodul>for librsvg we fall back to the old C implementation on non-x86_64 <civodul>but maybe it's simpler to keep the old version for all the architectures for now? <efraim>for librsvg I meant there's bundled rust code we don't replace for the low level librsvg <efraim>but yeah, for python-cryptography we'd either need to force a lot of rust packages to stay at a certain version or we could downgrade to the last C version <civodul>efraim: yes, i'm happy to defer that to you, given that you know this well <civodul>i still think the Rust packaging situation is pretty dangerous <apteryx>yes, hopefully the antioxidant effort will help to make it a tad saner (by enabling rust packages to use regular inputs and enabling to use rust inputs as shared libraries) <apteryx>civodul: how would I go to fix "Throw to key `%exception' with args `("#<&non-continuable>")'" in a service? <apteryx>would that be thrown if I use guile's sleep? <apteryx>or is this the error I'd get if there's any kind of error raised during execution of the service code (start slot) ? <jgibbons[m]>Is it possible to configure a guix system with an sshfs mount? <apteryx>network file systems are not well handled currently by guix; perhaps you could hack it as a one-shot Shepherd service <apteryx>(by the declarative file systems machinery, I meant) <jgibbons[m]>Sounds like another topic to cover in an in-depth book on guix. And it'll be obsolete a year after release. <maximed>apteryx: I guess an exception is buggy <maximed>Unless you're trying to use continuable exceptions, don't return a value from the exception handler in with-exception-handler <maximed>(or that for another exception construt) <JonRob>Hi, just investigating guix and trying to see if it can help with some packaging. Target is a Python package inside a monorepo. guix package fails because no setup.py in the root, but I'm struggling to figure out how to change the root directory for the build. Would any body be able to advise if this is possible? <maximed>apteryx: TBC, rust inputs are currently (in antioxidant) more like static libraries than shared libraries <tribals>Is there any adopters of `guix home`? I'm using bash provided by my `guix home` configuration. I'm getting strange error when tried to launch some GUI application from shell (it doesn't run from menu). Error: <tribals>bash: /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6: version `GLIBC_2.34' not found (required by /usr/lib/liblsi-redirect.so) <tribals>Does anyone can explain the source of such error? <apteryx>maximed: OK! could it be improved in the future to make them .so? <maximed>tribals: mixing libraries from two different distributions can lead to ABI errors like that <maximed>probably you have LD_LIBRARY_PATH set, maybe unset it when doing Guix stuff and only set it when actually needed <maximed>Alternatively, Guix' glibc needs to be updated to 2.36 <maximed>apteryx: yes, it's already the case for ‘macro crates’ <tribals>That's the point: I don't have LD_LIBRARY_PATH set. <tribals>Why my libc is "superseded" by Guix' one? <maximed>though for other crates trying to build .so results in errors about ‘panic handler not found etc’ which need to be resolvedd <jpoiret>JonRob: you can use guile's chdir in a phase <maximed>tribals: Do I understand correctly that the GUI application is installed outside Guix? <jpoiret>although ideally the unpack phase should drop you in the root of the unpacked source iirc <maximed>Maybe run "strings THE-APP-BINARY | grep -F /gnu/store/" to test that it doesn't use a mix of Guix and non-Guix things? <JonRob>ah so potentially replace the unpack phase with an additional chdir call? <maximed>(Assuming you've compiled it yourself) <apteryx>was there a way to get a REPL to evaluate things in the context of Shepherd? <tribals>maximed: I think this is rarely the case because it is an application installed through system's package manager. I'm using Guix on foreign distro - Solus. <maximed>I don't think 32-bit / 64-bit matters, unless you mean that the foreign distro and Guix are using a different bitness? <maximed>Though TBC I don't know what's going on <maximed>tribals: WDYM by ‘it is a lib32 one’ then? <jpoiret>JonRob: aha no don't replace the whole unpack phase, otherwise the source won't get unpacked <jpoiret>but you can add an additional phase after it with (add-after 'unpack 'chdir (lambda* (...) ...)) <maximed>tribals: Maybe you have LD_PRELOAD set? <jpoiret>you can scan the gnu/packages/*.scm for loads of examples of that <tribals>There is a clear separation of 32/64-bit binaries in the distro. 32-bit ones can be installed separately. Their package names suffixed with `-32bit`. <jpoiret>tribals: are you sure you're launching the foreign-distro provided one? <jpoiret>i'm not sure how guix's libc could just sneak in like that <patched[m]>Trying to reconfigure system, but I get "invalid G-expression input". Idk what to do about this, or how to search for answers :thinking: <jpoiret>patched[m]: is your guix version recent? there was a bug recently about that <tribals>Is there a work-around of `guix home`-spawned shell? Eg, can I "undo" `guix home`? <maximed>IIRC it says more, ‘invalid G-expression input: <foobar@FEFF ...>" <tribals>I'm also wondering how it could be? May be, my Guix installation is "broken" in some way? Could I check/repair that? <apteryx>civodul: is it possible to use Fiber's non-blocking sleep version in my own Shepherd service? <maximed>tribals: `guix home` doesn't spawn shells AFAICT, unless you mean "guix home container" <maximed>though I don't know much about "guix home" <tribals>are you sure you're launching the foreign-distro provided one? Yes, I'm sure. <jpoiret>patched[m]: then yes, the full error message would help us here <jpoiret>tribals: i don't think it's your guix installation that's broken <tribals>There even no package for that app in guix. It is steam. <jpoiret>could you post which env variables are set in that shell? you can redact anything that's personal of course <tribals>maximed: I mean, I did configure my terminal to spawn shell provided by `guix home`. <maximed>tribals: AFAICT `guix home` doesn't provide any shells? <tribals>I did that by using `~/.guix-home/profile/bin/bash` as a command for terminal. It's arguments is: `--login` <maximed>(Except for installing things in ~/.guix-home & .bashrc) <jpoiret>iiuc, guix home manages your .bashrc/.zshrc <tribals>It does if you're using "home services" provided by `guix home`, like `home-bash-service-type` <tribals>jpoiret: Yes, guix home manages my .bashrc, for terminal application. <civodul>apteryx: possibly, but ideally you wouldn't have to meddle with that in start/stop <civodul>secret-service.scm does nasty things in this area <civodul>but i'd like it to remain the exception :-) <jpoiret>there's no code to fully remove a guix home, although you can do it yourself pretty easily <tribals>Unfortunately, I can't: in fact, it doesn't mater for such case, which exactly `bash` spawned - guix one or system one? - in either case, it reads .profile/.bash_profile/.bashrc generated by `guix home` <jpoiret>just `rm` .guix-home and all the symlinks that guix home created and that are now broken <tribals>But could I do that temporarily? Eg. `guix home unhome -- <command>`? <jpoiret>although i'd rather debug the issue itself <tribals>The problem of "leaking" libc is still bothers me, though. <apteryx>I still do, unless you have a bright idea: in the jami service start slot I need to poll until the Jami D-Bus service has been acquired by the D-Bus daemon, so I have this with-retries loop that tests for it <jpoiret>well, you can do `/usr/bin/bash --login --norc` <jpoiret>the libc should not leak, it's very strange <jpoiret>could you try to rerun the app, but with `LD_DEBUG=libs <command>`? <apteryx>it was using sleep, but what that does is block Shepherd, meaning the above make-forkexec-constructor(/container) call doesn't get to start, thus causing a timeout <jpoiret>this will print a bunch of ld search paths and which libraries are actually loaded <patched[m]><jpoiret> "patched: then yes, the full..." <- Nevermind, first pull was done with sudo, pulling again without it solved the issue <tribals>IIUC, doing `/usr/bin/bash --login --norc` will not prevent bash from loading ~/.profile & ~/.bash_profile, which will "load" guix home again <patched[m]>And #55444 being solved seems to have fixed my issues with guix halting post-boot! <jpoiret>hmmm, it's trying to use bash's ld cache <tribals>Sory, don't know "good" image sharing service <tribals>Isn't "leakage" caused by `/usr/bin/env`? <jpoiret>it's trying to hook low level LD behavior, i'd wager it's the root issue <tribals>Hm, I'll try to disable such "hooks" and report later. <tribals>jpoiret: FYI, seems like disabling both "Use intercept library" and "Use redirect library" fixed the issue. <tribals>jpoiret: Thank you for your time very much. <apteryx>to use fibers' sleep in a shepherd service, would I need to use (with-extensions (list guile-fibers) ... ? <apteryx>civodul: I think the jami service is working again \o/ <civodul>apteryx: yay! so was the service actually broken, or was it just the test that was broken? <apteryx>the service was broken too, due to the unwieldy (post Shepherd 0.9.0) sequential execution of make-fork+exec-constructor + blocking sleep <apteryx>(this is after getting rid of using Shepherd's command-fork+exec to invoke dbus-send, since now we'll be using guile-ac-d-bus <apteryx>I'm not too sure how to maintain containerization now though, because the dbus session would run in a private namespace as 'jami:jami', while the actions code wants to talk to it via root outside the namespace <apteryx>I think I'll have to wrestle (setgid y) (setuid x) before opening the D-Bus connection <apteryx>as dbus-daemon's default config enforces correct user/group for the session bus <sleepydog>when I send a patch that modifies an existing module or package, is it proper ettiquite to cc people who maintain that module? <jpoiret>sleepydog: there is not such thing as a module maintainer <avalenn>I just found out about the "properties" field of package definition and I wonder what is its purpose and cannot find documentation about it; <jpoiret>avalenn: they're used mostly for internal things <rekado>avalenn: we’re using them a lot in gnu/packages/cran.scm to record the upstream name of a package, so that the updaters can do their thing more easily <jpoiret>one use is to tag transformed packages to avoid recalculating transformations (that can be costly) <avalenn>Ok. I kind of see the pattern. Do you have example of the transformations you talk about ? <rekado>avalenn: guix/transformations.scm <rekado>search for package-properties in that module <rekado>this property is dynamically added to packages generated by a transformation procedure <avalenn>Thank you jpoiret and rekado. My curiosity is satisfied for now. <avalenn>Now I have a question about packaging for Go code bases. I try to package gojsonnet and it should deliver several binaries but I can only pass one import-path to the build-system. <avalenn>Is there yet any "standardized" way to deal with multiple-binaries Go packages ? Or must I modify the build system itself ? <avalenn>binaries = executables (or commands in Go linguo) <jpoiret>there wasn't one last time i checked ~5 months ago <avalenn>Just looked at the code and indeed it does not seem supported. I will take a look when I find some free time. ***yewscion is now known as Guest7325
***yewscion20 is now known as yewscion
<efraim>avalenn: I have an example you can use <avalenn>efraim: thanks, why so many "delete-file-recursively" ? <efraim>avalenn: I was working through dependency by dependency and had a few I couldn't get rid of, but I wanted to make sure I didn't forget any when I next upgraded the package <efraim>there's definately cleaner ways of doing it <efraim>if I ever get around to updating it to 5.9.3 I'm going to clean it up a bunch <avalenn>I will try to avoid too many yak shaving even if this build-system have a lot to improve. <PotentialUser-82>hi all, i'm new to guix and i had a question. when i do two successive `guix pull`s and it shows that i am building from the same commit, why does guix still compute the guix derivation (Computing Guix derivation for 'x86_64-linux'...)? is there any way to make it not do that if there weren't any changes? otherwise it takes too long to compute only <PotentialUser-82>to say "nothing to be done", which i would have thought is a conclusion that guix could have arrived at sooner. please do correct me if i've misunderstood anything! thanks in advance <rekado>PotentialUser-82: I guess this could be avoided with some more local caching. <PotentialUser-82>rekado: thanks. so just to confirm, it's not something that just happens to me, right? i was worried i had misconfigured something. do people just ctrl-C out of it when there are no new changes to the channels? <dominicm>PotentialUser-82: Yeah pretty much. I should probably look into this at some point as it makes scripting checks for if Guix is up to date a bit annoying <lechner>Hi, I have an atrocious delay (maybe four minutes) when starting an X session. It is in addition to the two-minute delay or so to get to GDM. Anybody also experience the former? Thanks! <apteryx>dbus-daemon seems to accept a '--systemd-activation' argument... but I can't make it work <apteryx>(start #~(make-systemd-constructor (list #$dbus-daemon "--session" "--systemd-activation" "--address=unix:path=/var/run/jami/bus" "--nofork" "--syslog-only") (list (endpoint (make-socket-address AF_UNIX "/var/run/jami/bus")))) ...) appears to hang <civodul>uh the dbus-daemon(1) man page is broken <rekado>apteryx: I removed python2 from the non-* packages; will push this later. <char[m]>Why am I getting error: glibc: unbound variable when I have #:use-module (gnu packages base)? <apteryx>civodul: perhaps because I was using "--nofork" ? are processes expected to fork when using make-systemd-constructor ? <civodul>apteryx: looking at bus/activation.c, it seems to expect systemd to connect to itself over dbus <apteryx>I see. The warning in the manpage is accurate, after all <civodul>how long before we have dbus in shepherd, i wonder :-) <civodul>it may be that guile-ac-d-bus is capable enough... *civodul had better not think about it <apteryx>perhaps the guile-ac-d-bus work for the jami service will give entry points <apteryx>I'm giving a 2nd try to gave the dbus-daemon spawned for the jami session bus use a pid file <apteryx>it's ugly in that it requires a variant of the dbus package, as it reads only from static locations baked at build time. <apteryx>OK, I was able to use a custom pid file with a variant dbus package <char[m]>Is it possible for the new emacs 28.1 to not use client mode? Having each emacs instance be totally separate? <char[m]>apteryx: the default seems to have changed in 28.1. Most people seem to praise, it but I really like to have different instances be different. <apteryx>launching just 'emacs' as a command it spawn a new instance each time <char[m]>I see. It must be realted to launching it from the app icon <char[m]>It seems quite. apteryx Do you by chance know about my module problem? <apteryx>I don't; perhaps another error gets badly reported <char[m]>Would anyone be willing to call and take a look? 