<lilyp>drop them into ~/.fonts like a monkey <morgansmith>I haven't been here for a while. I just wanna say: guix home really rules!! It makes me very happy :) <morgansmith>I still don't quite understand how all the service stuff works though. I'd like to setup my mpd daemon using guix home which I think is possible using shepherd but I have no clue how all that works :P <lilyp>I have an almost working mpd setup, but without Guix Home :( <lilyp>Almost working in that I still need to manually herd start mpd <lilyp>Olivetree: Bonus thing, if you use containers, you can set an arbitrary folder to ~/.fonts and the fontconfig inside the container will eat that <nckx>lilyp: Don't drop monkeys into ~/.fonts! >:( <lilyp>sorry, I meant "like a monkey would" š£ļø *nckx adds lilyp's emojo to their auto-replace list like a cruel trophy. <lilyp>does hexchat offer a way to version-control those? <nckx>I use an hourly rsync to a btrfs-snapshotting backup server. <nckx>I wish I could say it's just for my HexChat emojo list. <nckx>Any samaritans feel like quickly testing Guix's geeqie? It's an image viewer, so if you can use it to view images, it works. <nckx>Here it's a grey rectangle peruser. <morgansmith>although when I guix environment --pure I get a little angry paper image instead of the actual image <lilyp>works for me too, perhaps a gnome vs. others thing? <nckx>Yeah, should've mentioned this is on Sway. <nckx>morgansmith: No, I just get what are presumably the dimensions of the image worth of grey on a black background. <Olivetree>lilyp: don't usually use containers, but will keep in mind. thanks! <nckx>All right, 3 against one, I'm convinced it's my fault :) Thanks. <lilyp>anything interesting in the logs? <lilyp>from my work over at komikku, I "know" that gdk-pixbuf fills missing data with grey <nckx>Your usual āThe name org.a11y.Bus was not provided by any .service filesā that every gnomey thing does here, then a few āCreating Geeqie dir:/home/nckx/.config/geeqieā, fin. <Noisytoot>When I ran it I also got Error: XMP Toolkit error 201: Error in XMLValidator <nckx>Isn't reproducible statelessness fun. <lilyp>do we have some known-good images like the Guix logo? <nckx>Uh, all my images are high-quality. <Noisytoot>the "Error: XMP Toolkit error 201: Error in XMLValidator <Noisytoot>Warning: Failed to decode XMP metadata." error only appears on some images <nckx>Don't look straight at it or you'll be awoken. <lilyp>Sorry, I might be busy giggling for some time <nckx>lilyp: :) I forgot why I made it, but it was some silly discussion in #guix. <ss2>It feels like years since coming across a gui with detachable menues. <nckx>One of the useful things I learnt from the GIMP which the GIMP then took away from me. <ss2>thanks for mentioning geeqie. Never came across it before. <lilyp>doesn't GIMP still have that, but not as the default? <ss2>Is there a hidden option? Just double checked.. <nckx>The context menus still are. <nckx>Is that the kind of tunnelling that e.g. HE does? <nckx>I wrote an ad hoc āserviceā for that that just called the required ip(?) command directly for a server without IPv6. <nckx>Mind you, this wasā¦ 2016? I'll check my backups but I doubt itā¦ <lilyp>ss2: the last option in the "Windows" group <nckx>lilyp: Are you translating from German? I have only āWindow Managementā and āImage Windowsā but neither match. <lilyp>I am, but I also tried with LC_ALL=C <nckx>Noisytoot: Nope. Lost to time. *nckx guix upgrades 28 milligimps. <nckx>Yeah, still nothing, pointer handedness & window positions. <lilyp>The option itself is called "Single Window Mode" and defaults to true. <nckx>We seem to have miscommunicated on āgroupā. <lilyp>Are you looking in preferences? <nckx>I was looking in Preferences, you meant the Windows menu. <nckx>Yay oldschool noobconfusing gimpmode ā„ <lilyp>To be fair, old school mode was ahead of its time <lilyp>like we now have multi-monitor 4K setups, where each dialog could be put on another monitor <nckx>Mh. I wonder if I'll ever bother whatevergrading to 4K. ***jonsger1 is now known as jonsger
<apteryx>the world doesn't only struggle with Python 2 -> 3. It also struggles with Python 3.9 -> 3.10 <apteryx> BoostConfig: find_package(boost_python310 1.77.0 EXACT CONFIG REQUIRED QUIET HINTS /gnu/store/y5k4wr58l9ypj10v5vjbawvh2ls1kynp-boost-1.77.0/lib/cmake) --> Could not find a package configuration file provided by "boost_python310" <apteryx>s/boost_python310//boost_python3/ did it for now <apteryx>wisp: so mpd is working fine? what needed adjustment in your config? I may be hitting the same gotcha. <apteryx>uh, mariadb installs tons of 'mysql-test' files; I think on debian they're moved to another 'test' package <dhruvin>yggdrasil has released v0.4.0 in June 2021, which is incompatible with v0.3.16 (current guix version). I don't think anyone can current package/service right now. <dhruvin>I'm updating the package definitions. Should I also update its dependencies (if any)? <florhizome[m]>Does the system profile install fonts different then User? I moved some essential ones to system but after removing them from user, my xfce gui just shows rectangles š¤ <civodul>check-description-typo should return a list, so you should use 'map' rather than 'for-each' <civodul>or append-map even, so that the lists of warnings are concatenated ***vagrantcweb is now known as vagrantc-pbp
<civodul>so (append-map (match-lambda ...) descriptions) <vagrantc-pbp>reasonably well... bordeaux is providing pretty good aarch64 coverage now, at least <vagrantc-pbp>major things like linux-libre, notably ... limited set of web browsers ... best found is epiphany so far, though that didn't have a substitute on either of the build farms <vagrantc-pbp>civodul: the "descriptions" is what it's appending to? outputting? inputting? <vagrantc-pbp>foolishly rebased against origin/master, enough so that i need to rebuild the local guix ... <civodul>vagrantc-pbp: so see the difference between map and append-map, you can try this at the REPL: <civodul>(map 1+ (list 1 2)) vs. (map list (list 1 2)) vs. (append-map list (list 1 2)) <civodul>in the first case, map applies the function '1+' (that its name :-)) to all the elements of the list and returns a new list with those results <civodul>in the second case, it applies 'list', thereby building one-element lists for each element of (list 1 2) <civodul>ah yes, append-map is from (srfi srfi-1) <civodul>so you need to type this at the REPL: ,use(srfi srfi-1) <civodul>which is shorthand for (use-modules (srfi srfi-1)) <civodul>so in (guix lint), each "checker" is expected to return a list of "warning" objects, as returned by make-warning <civodul>the check-description-typo function should return such a list <civodul>so i think s/for-each/append-map/ and you should be done or almost :-) <vagrantc-pbp>so it should return empty lists for all the things that passed, and append the lists for things that failed the check <vagrantc-pbp>took me a painfully long time to even figure out what was expecting an empty list ... <civodul>well maybe backtraces are suboptimal... <civodul>i find it always help to fiddle with reduced test cases at the REPL or Geiser <vagrantc-pbp>tried a reduced test case little script, but it worked "fine" until i plugged it into guix/lint.scm <civodul>hmm on GNU/Hurd the shepherd does not produce /var/log/shepherd.log <civodul>but i don't see why it does on GNU/Linux <civodul>in (shepherd support), %user-log-dir cannot be %localstatedir AFAICS <efraim>maybe its trying to write to the store <nckx>florhizome[m]: This sounds like you're using an old copy of Guix (e.g., the one installed by your distribution package manager) instead of a pulled copy. Unless that's deliberate, make sure you're running ~/.config/guix/current/bin/guix . <nckx>florhizome[m]: In a different location (/run/current-system/profile/share/fonts vs ~/.guix-profile/share/fonts) but both should be searched. Maybe an application's caching the previous location (either on disc or in RAM), or fontconfig itself is confused (fc-cache -r should fix that). ***tom is now known as tom19281
<tom19281>Hi. I'm trying to install transmission-gtk on Guix System. I see package "transmission" has an output "gui". I am using (specification->package+output "transmission:gui") to install this, but I cannot see transmission-gtk in my $PATH afer a system reconfigure. Any ideas why this isn't in $PATH? <tom19281>I see that /gnu/store/s698nhfqckpkf3zb2kkcm4329qrqcvih-transmission-3.00-gui/bin/transmission-gtk exists, and I can execute that. <tom19281>(Other transmission binaries, such as transmission-show, are in $PATH) <lilyp>i.e. ((compose list specification->package+output) "transmission:gui") <lilyp>alternatively (list (specification->package "transmission") "gui") <nckx>āexpires: 2021-10-25 14:40:48ā Very posterior. <lilyp>in your stead I'd simply map (compose list specification->package+output) <tom19281>lilyp: Thanks, I'll play around with that. <teddd>I'm having a problem running pdflatex on a .tex file. <teddd>More specifically I can run the command when I rollback to a certain generation but not in the one after <teddd>The command works when I am in generation 204 but not 205 <teddd>the problem is I don't see any difference between generation 204 and 205 when I run guix package --list-generations <vivien>teddd, could you describe the problem? <teddd>So I'm having trouble understanding what might cause the command to fail in generation 205 <teddd>I get two error messages from the pdflatex command when running in the older generation <teddd>! Font OMX/cmfileex/m/n/5=cmex7 at 5.0pt not loadable: Metric (TFM) file not found. <teddd>! Font U/msa/m/n/10=msam10 at 10.0pt not loadable: Metric (TFM) file not found. <vivien>Can you make the .tex file as short as possible, while reproducing these errors, and publish it? <teddd>where do you suggest I publish it ? <florhizome[m]><nckx> "florhizome: This sounds like you..." <- I think i have the appropriate lines in my .bash-profile.. and i've tried running guix package --search-package-paths (or similar) after pulling, too.. <teddd>just added it to github gist <vivien>teddd, Iām not proficient in latex enough to understand what goes wrong. Your document seems fine to me. If I had your problem, I would try to first delete ~/.texlive2019 and retry, but maybe you have valuable files in there. <teddd>I didn't know about this folder. I'll check it out <civodul>efraim: actually i'm silly: /var/log/shepherd.log is a thing of the past, now it writes to /dev/log (syslog) <teddd>how come however that the difference doesn't appear in the generation list ? <teddd>anyway removing ~/.texlive2019 didn't solve the problem :/ <teddd>I would be interested in investigating the differences between two generations. Which way would you suggest ? <rekado>fixed blender on core-updates-frozen <rekado>this leaves one package on my list: diffoscope <rekado>diffoscope has four failing tests, all in test_wasm.py, all related to a problem with python-magic. <civodul>rekado: great that you were able to fix those <civodul>does upgrading diffoscope help, just in case?... *apteryx has been checking whether Python 3.10 is doable on cufbc <civodul>if you mean whether upgrading Python is doable, i'd recommend against trying :-) <civodul>i know how tempting it is and now i speak like an old wise person ;-) <florhizome[m]>Another thing- on guix system profile generation runs extremly long. I thought i had too many packages, but i'm down to 10 in the user profile and don't experience much change. It seems to jump between cores while exhausting them each time. <civodul>florhizome[m]: "profile generation" as in when running "guix install foo bar baz"? <civodul>for instance, there's the mandb hook that takes time proportional to the number of man pages in the profile <rekado>I know now that upgrading python-magic does *not* help. Will try upgrading diffoscope. <roptat>also some packages have propagated-inputs, and that can add quite a lot of packages to the profile <rekado>do other people here have a list of things that still need work on core-updates-frozen? <rekado>because Iām out of work once diffoscope builds <lilyp>civodul: Could we make hooks explicit? <katco>hey all, i'm creating a new service, and i'd like to see in my guile repl what the `define-configuration` record looks like, serialized. i found `(gnu services configuration):serialize-configuration`, but it returns a gexp which i have not entirely understood yet. what's the best way to do this? <lilyp>I.e. if I "guix install man-db" I'm requesting the man-db hook, otherwise not? <rekado>upgrading diffoscope doesnāt fix the problem. We already disable one other test because of a problem with our libfile. <rekado>Iāll just disable that one too. <civodul>lilyp: some of them work like this (the GTK, GHC, etc. hooks) <civodul>for mandb, why not, but usually mandb is installed in the system profile <civodul>but yeah, maybe that's a good way to remove it without removing it entirely <civodul>i like it when we can make half-decisions like this :-) <lilyp>half-decisions are the best decisions :) <rekado>diffoscope is now upgraded and fixed. <lilyp>plus imho this gives (some) power to the user <rekado>Iāll try to build pigx on core-updates-frozen next and fix whatever might still be broken. <civodul>katco: hi! i'm not really familiar with define-configuration, but the way i do in similar circumstances is by building just the relevant derivation <civodul>so for instance, in the output of "guix system build", you look for whatever.conf.drv <civodul>and then you explicitly run "guix build /gnu/store/...-whatever.conf.drv" to see the result <katco>civodul: hiya! yes, i'm surprised there's not more documentation on this! i think i could certainly get into a workflow where i'm using the guix CLI to build things and then look at the store, but i'd really rather have a repl driven workflow for something with a quicker iterative loop <katco>i tried some `(with-store store (run-with-store` shenanigans, but i don't fully understand how to drive that code yet. <civodul>katco: i guess you could apply the trick above to the 'computed-file' object that builds the config file <civodul>tpefreedom: Guix has nothing against AppImage :-), i guess it should work? <lilyp>AppImage has something against Guix tho :P <civodul>it could fail to work if the ELF file includes absolute file names like /lib/ld-linux.so that don't exist on Guix System <lilyp>Without patchelf, they will typically not find system libraries. <civodul>aren't they supposed to be self-contained though? <teddd>Hi! the package texlive-amsfonts appears to be defined twice in my config. When running "guix show" I get the same location for both. How do I investigate the where this duplicate comes from ? <lilyp>If you say "config", you could try good ol' grep <lilyp>Though perhaps if they're the same item it's not necessary to do so? <teddd>Hum there is a "define-public texlive-amsfonts" and a "define-public texlive-amsfonts/patched" in tex.scm <teddd>I ran grep in "/gnu/store/8861za9cqhsqm9awjs818wi65kz18g63-guix-module-union/share/guile/site/3.0" <lilyp>Nah, that's just a graft, those are normal <teddd>Hum ok. I guess this might be related to a problem I have with fonts in latex I explained sooner in the chat. I'll write an email to the help mailing list with all the details <katco>civodul: i'm having some success with just defining a new function that looks like `serialize-configuration`, but just returns a string. <jpoiret>hmmm, where is hurd specific code for eg mounts? <civodul>katco: nice; perhaps you can eventually share your debugging tricks on the list, and maybe someone will come up with a nice way to factorize it <civodul>jpoiret: there is not :-) there are things in hurd-boot.scm to set up essential translators (which is akin to "mounting" something) <katco>civodul: yeah, i am really bad at following through on this kind of thing, but i'd like to do a little write-up on my experience of developing a guix service having never done so before. i don't think there is enough documentation, and i am wishing their were a more iterative approach to hack on one. <jpoiret>civodul: but then, when does guix discriminate between both methods in the file-system services? <civodul>jpoiret: it doesn't, it's just not implemented <civodul>essential translators are set up in hurd-boot.scm and that's all <rekado>the TBB upgrade on core-updates-frozen broke quite a few packages <rekado>I had to downgrade to tbb-2020 for a few packages already <jpoiret>that looks a bit complicated for me for now. is it because the driver for NICs is one from the linux kernel, and we should switch to a different one? <jpoiret>i'll wait until i boot my first hurd image to look more into it (don't tell anyone I haven't ever done that yet) <jpoiret>one of the reasons i switch to guix though was the tighter hurd integration/development process <civodul>jpoiret: yeah, we're currently using one of the Linux 2.6 (!) drivers that are built into Mach <civodul>and this is superseded by netdde, which has more drivers, for modern hardware, etc. <jpoiret>yes, that'd be a good idea then! is netdde in the hurd repo? <civodul>yes, and we even have a package actually <jpoiret>i'm not sure how we should differentiate between both systems thoughā¦ maybe have a hurd-swap-service instead of swap-service in a separate file? but then, that'd be a lot of redundant code too <civodul>jpoiret: for this patch set, i'd recommend just using the 'swapon' procedure <civodul>it'll throw on GNU/Hurd, but that's already the case anyway <civodul>IOW: don't worry about swap support on GNU/Hurd for now <civodul>it can come in a separate patch later <rekado>there will be rumpkernel-based network drivers for the Hurd eventually. <nckx>jpoiret: Do you think my points make sense? <jpoiret>civodul: it'd be great to have something akin to guix build syscalls for hurd, something like guix build herd-protocols <jpoiret>also, tangentially, what's the exact dichotomy between guix and gnu? eg gnu build file-systems vs guix build syscalls <jpoiret>i'd say guix is the "base" library while gnu is the actual definitions using that but it might be quite blurry in some instances <civodul>jpoiret: yes, it'd be nice to have a module implementing the Hurd RPCs <lilyp>GNU has stuffs to build the GNU system, where as Guix has internal machinery <civodul>right, (gnu ...) is for the distro/packages, whereas Guix is for the core machinery <jpoiret>nckx: thanks for the review by the way. The initial motivation behind the naming difference is that we might want to know that it is a swap file (eg to make use of it in automatic hibernation file offset detection) <jpoiret>i could be inclined though to instead remove the string device support and keep only uuid and file-system-label instead, so that strings would always denote actual files (and so we could simply it a bit) <vats>Hello. How can I set the kernel parameters to be set by bootloader for the default menuentry? I want to install GuixSD with an LVM on LUKS setup, and want to configure the bootloader to prompt for the decryption passphrase. <jpoiret>i'll send a follow up mail tomorrow i think with the changes you suggested. <jpoiret>vats: by default, without specifying anything, the bootloader prompts for the decryption passphrase <vats>Yes, I'll be using grub. And thank you. <jpoiret>let me check my configuration first if I did write something specific <rekado>oof, lots of broken bioinfo packagesā¦ <jpoiret>yeah, iirc guix automatically detects that your store depends on a mapped LUKS device, so it will add the necessary configuration to grub <jpoiret>also, now it is just called 'guix system' since guix-the-distribution and guix-the-program are one and the same <vats>jpoiret: How does one enable TRIM then? I think it needs to be set from kernel parameters as well. <jpoiret>in general, for kernel parameters, you just add a (kernel-arguments (cons* "param1=val" "param2=val" %default-kernel-arguments)) line to your operating-system reference <jpoiret>nckx: what would you think of a root-filesystem-service rename to filesystem-/? <jpoiret>this would make it more consistent with dependencies <jpoiret>that's why the example (that i should've rightfully tested) did not work <jpoiret>or just keep the corner-case of "don't specify a dependency on the root filesystem or otherwise expect breakage" <robin>vats, i *think* there's a way to enable TRIM on LVM without kernel arguments, setting a flag in its internal configuration info, presumably. i switched to plain btrfs-without-LVM though so i'm not sure <robin>or a sysctl setting, possibly <robin>ah, yeah, btrfs-on-LUKS without LVM (i wasn't using LVM for anything but a swap partition and btrfs has good enough swapfile support now...) <robin>(and the FS might need an option set to enable auto-TRIMming too, although i think the preferred approach is to use...hdparm, iirc, to manually TRIM once in a while, a bit like reference counting vs. GC) <jpoiret>the current package doesn't have --host x86_64-gnu <robin>(s/hdparm/fstrim/, apparently, though hdparm -I can tell you whether TRIM is *supported* at least) <jpoiret>but you should still be able to cross-compile, right? <notmaximed>jpoiret: "guix build hurd --target=i586-pc-gnu" should work <notmaximed>The absence of "--host=..." in the package definition of the hurd package shouldn't be a problem, because that is set by gnu-build-system <notmaximed>(Unless the 'configure' phase is replaced or something) <notmaximed>jpoiret: Does "guix build hurd --target=i586-pc-gnu" work? <jpoiret>oh sorry, just noticed your message. currently trying out ***vagrantc-pbp is now known as vagrantc
***vagrantc is now known as vagrantc-pbp
<cybersyn>hiya guix, I have packaged notcurses and i'm ready to send it upstream but have a few questions <cybersyn>when linting, I get a couple errors that don't really make sense to me: <cybersyn>"the source file name should contain the package name" -- what does this mean? the field "name" contains the name, as well as "define-public". should it appear elsewhere? <notmaximed>According to guix/lint.scm, it's the origin record in the 'source' field you need to look at <cybersyn>"the source URI should not be an autogenerated tarball" -- the source URI points to an official release tarball on get hub; an explicit release that wasn't autogenerated. should I change it? <jpoiret>i think it's asking for the file pulled by the (source ...) form to have the name of the package <jpoiret>if it's a github release, you could simply use git-fetch with tags <notmaximed>Could I see the web page pointing to the tarball? <notmaximed>It could be both an āofficial, explicit releaseā _and_ autogenerated <jpoiret>these are in fact auto-generated tarballs by github <cybersyn>and last, should I add this definition to an existing package or send it as a new package? i didn't see guidelines for this in the contributing section of the manual, although its a bit long so i could have missed it <notmaximed>do you mean adding it to a new file/module, or an existing file/module? <notmaximed>Normally they are put together with other packages of a āsimilar natureā <cybersyn>i can add it to the ncurses, for example, which is a similar package, (this is not-curses), but it adds about twice the number of include modules, so it feels a bit excessive <notmaximed>notcurses is definitively not ncurses, so I wouldn't put it in (gnu package ncurses) <cybersyn>i considered gtk, because they share a lot of dependencies, but its not really "of the same nature" <notmaximed>āwhat it is not: a source-compatible..., nor a replacement for NCURSES ...ā <notmaximed>Though a reviewer might suggest a different location <vagrantc-pbp>hrm. so I have u-boot almost ready to update to 2021.10, but i haven't tested on x86_64 the only place where the test suite runs... <vagrantc-pbp>although the test suite itself is kind of weirdly tied to u-boot-tools ... <notmaximed>If it's x86, you could, depending on the processor, do --system=x86_64-linux <notmaximed>Possibly transparent emulation with QEMU might work? <vagrantc-pbp>or i just boot guix on x86_64 that i have bitrotting somewhere <vagrantc-pbp>without split /boot working on guix, i'm not sure how i could get the pinebook-pro booting with (nearly) full disk encryption <notmaximed>Or you could create a x86_64-linux VM and run "guix build ..." inside? <notmaximed>or set up offloading to the x86_64-linux machine <notmaximed>There is a āchildhurdā service to make "--system=i586-gnu" work on ARCH-linux machines, maybe it can be generalised? *vagrantc-pbp reboots to test new arm-trusted-firmware and u-boot <kozo[m]>Are you running guix system on your pbp vagrantc-pbp? <notmaximed>That might avoid the ā(non-system) QEMU emulation is somewhat flawed and causes build failuresā issues, at cost of extra memory usage <notmaximed>(to be clear, qemu-system-ARCH seems to work fine, but sometimes qemu-ARCH doesn't work perfectly) <rekado>on core-updates-frozen bowtie fails to build because of curly quotes in an unused ifdef branch. <rekado>Iām surprised this is an issue, because this branch should not be reached when GCC is used. <rekado>Iām fixing this now by patching out the curly quotes, but I wonder if thereās a more serious problem underneath. <awb99_>I am searching java 17. It seem openjdk-16 is the last version. Java 17 is current LTS. Is it supported somehow? <lilyp>awb99_: See `guix edit openjdk' for our OpenJDK bootstrap chain <lilyp>it just takes one to add openjdk17 <awb99_>lilyp - thanks. I looked the source up on guix rep. there is no openjdk-17 <awb99_>you mean that openjdk needs to be written? <lilyp>the package definition for it, yes <awb99_>crazy that it is nto there, as openjdk 17 is already LTS and 16 is depreciated. <lilyp>As a wise person in this channel once said, motivation is not fungible. <lilyp>There is a mailing list open to patches, you know :) <rekado>java-commons-io fails to build on core-updates-frozen <rekado>reason: Unbound variable: %build-inputs <awb99_>The point for me is: I want to use guix as my main distro. If something as important as openjdk falls behind LTS, then this is an issue to me. <awb99_>I really wish guix would be more adopted. <awb99_>But then, if I want to use it, I need to be sure that I get current versions. <awb99_>Just want to be honest as to how things are. <lilyp>Distros are community efforts. Mainstream ones like Debian have much more manpower behind them than we do, sadly. <singpolyma>awb99_: unless openjdk is particularly complicated it should be pretty easy for you to write a few lines and install a newer version <singpolyma>lilyp: because Debian *never* "falls behind" a version someone might want . Heh, heh. ;) <lilyp>I actually enjoy using Java 18 on my Debian oldoldstable. <singpolyma>awb99_: definitely can. That's basically the whole point of guix is to make making new packages, especially just variants of existing packages, very easy <singpolyma>OpenJDK is probably beyond the reach of --with-latest but hopefully not super complex ***jonsger1 is now known as jonsger
<rekado>help needed: python-pandas fails to build on core-updates-frozen. <rekado>civodul: search-input-file looks great! Unfortunately, thereās a problem with java-commons-io, which does not know the file name of the junit jar. <rekado>civodul: we used to just take the first result of (find-files ā¦) over the output directory of the java-junit input. <jgart>Hi, what's the workflow for using ocaml libraries with guix? Is there any environment variables I have to set that are not documented? <roptat>jgart, OCAMLPATH, which should be provided as long as you also install ocaml <jgart>because I'm having trouble importing guix installed ocaml libs <jgart>I installed ocaml alongside the libs <drakonis>hm, that is neat and i didnt know it was a thing <drakonis>all i need is native-search-path to create environment variables <drakonis>guess i'm going to use that for including tesseract's lookup path <jgart>guix environment ocaml-findlib ocaml-yojson --ad-hoc ocaml <jgart>then I got into the repl with `ocaml` <jgart>tried: open Yojson.Basic.Util;; <jgart>but I get: Error: Unbound module Yojson <jgart>any ocaml newb mistake I might be making? <roptat>ocaml-findlib needs to be ad-hoc too ***jonsger1 is now known as jonsger
<roptat>guix environment --ad-hoc ocaml-findlib ocaml-yojson ocaml <roptat>although, I think I never managed to use the ocaml repl like this <jgart>tried --ad-hoc too like you suggested above but doesn't work still <jgart>`ocamlfind list` is able to find yojson <jgart>\/gnu/store/5wqw5fqsp7hyr8li2h1rybwfvfbgx8gy-profile/lib/ocaml/site-lib/yojson <jgart>ignore the backslash at the beginning if that's visible <roptat>(it's double / to escape the first one on IRC ;)) <jgart>`ocamlfind query yojson` prints the store path for yojson <roptat>yeah, again I never managed to get "ocaml" working <jgart>how do you normally use ocaml libs? <roptat>but if you create a file with that content, you can build it, with "ocamlfind ocamlc -package yojson test.ml" <jgart>roptat, can I try building the composer-build-system from the open issue with your last patches? <jgart>In other words are the latest patches for composer-build-system on that issue page? <jgart>I'd like to hack on it a bit <roptat>great! thanks for the help, I don't think I have the courage to finish them ^^' <jgart>I'll muster some courage together and give it a try :() <jgart>It seems common lisp libraries also don't get sourced at the repl <jgart>I'll have to try again on Guix System. I've tried with/without --ad-hoc <jgart>I've been able to load sbcl libs by importing the full store path but I'd like the experience to be similar to python libs in guix <jgart>where I can just enter the cl repl and they're there <civodul>rekado: re search-input-file & java: i found a similar issue in hdf-java, fixed in 22e753b9b1aedc74b50d79c048ac34037add8193; that problem was already there AIUI but the wrong file name just went through silently <civodul>the issue in this case is that the .jar is installed in a maven subdir, with a versioned file name <civodul>which apparently has not always been the case <jgart>I'm able to compile the .cmo (bytecode) and .cmi (interface code) files but I get the above error <tom4345>Hi. I'm trying to get Emacs daemon to start on GNOME login. I'd like to do this with Shepherd user services, so I can manage the lifecycle of this in a uniform way. Does this exist? If not, is guix/gnu/home/services/emacs.scm a reasonable place to put this? <jgart>Might be nice to add an emacs service in upstream for convenience or an entry in the cookbook <jgart>So, we won't have to find these basic services in random blog posts/user configs in the wild <civodul>roptat, jgart: re composer, it was also quite a chore to review so i'm all for pushing it past the finish line :-) <jgart>civodul, Yes, the php ecosystem managed by scheme/guix would be quite interesting to experience. I'll get to work on it in my free time. If anybody would like to work on it together just ping me. I could use some help. *vagrantc allows to This packages <jgart>Does it make sense to have two versions of php packaged in master? <jgart>For example, 7.4.25 and 8.0.12 <civodul>vagrantc: speaking of which, i'm wearing the 1.2 t-shirt just today, and i had a good laugh rereading the lyrics on the back <jgart>same question goes for lilypond. lilypond always releases a stable and unstable version. Those current lilypond versions are 2.22.1 and 2.23.3 <vagrantc>civodul: i too happen to be wearing that shirt, and much to my dismay noticed a typo in the typo poem ... "cancelation" was spelled correctly! <jgart>Current lilypond stable version in master is out of date (2.20.0). I'm working on it. It doesn't build with just a version and hash bump. <singpolyma>vagrantc: some of the world spells that with two l so could be a typo for some <jonsger>I would assume in 751b68981c57031d6f093dda688f92ebdbf50848 by rekado :) <jgart>ah ok, I should have checked there first <vagrantc>wow, 1.2 was released less than a year ago ... feels sort of somewhere between yesterday and forever 
