IRC channel logs

2021-10-24.log

back to list of logs

<Olivetree>What do I do if I want to install some non-packaged fonts, say from https://www.nerdfonts.com/ ?
<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
<Olivetree>lilyp: ah, simple.
<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
<morgansmith>I currently have a "user" mpd working using the system configuration without any manual herd stuff: https://git.sr.ht/~morgansmith/dotfiles/tree/master/item/.config/guix/config.scm#L208
<nckx>lilyp: Don't drop monkeys into ~/.fonts! >:(
<nckx>They go in ~/.monkeys.
<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>I think I will.
<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 does not.
<nckx>Here it's a grey rectangle peruser.
<morgansmith>geeqie works great for me
<nckx>Hm. I wonder what's up.
<nckx>Thanks morgansmith.
<morgansmith>although when I guix environment --pure I get a little angry paper image instead of the actual image
<morgansmith>is that the grey rectangle you where talking about?
<lilyp>works for me too, perhaps a gnome vs. others thing?
<nckx>Yeah, should've mentioned this is on Sway.
<morgansmith>I'm on X11 (exwm)
<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!
<Noisytoot>nckx, geeqie works for me with GNOME
<nckx>All right, 3 against one, I'm convinced it's my fault :) Thanks.
<lilyp>anything interesting in the logs?
<nckx>No, that's the thing.
<lilyp>hmm
<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
<Noisytoot>Warning: Failed to decode XMP metadata.
<nckx>Isn't reproducible statelessness fun.
<nckx>(I don't.)
<lilyp>do we have some known-good images like the Guix logo?
<nckx>Uh, all my images are high-quality.
<nckx>Best images.
<Noisytoot>the "Error: XMP Toolkit error 201: Error in XMLValidator
<Noisytoot>Warning: Failed to decode XMP metadata." error only appears on some images
<nckx>Sorry, but this is the quickest to share: https://www.tobias.gr/thruth.png
<nckx>Don't look straight at it or you'll be awoken.
<lilyp>Sorry, I might be busy giggling for some time
<nckx>And this is what Geeqie looks like: https://tobias.gr/liees.png
<nckx>lilyp: :) I forgot why I made it, but it was some silly discussion in #guix.
<Noisytoot>geeqie works for both of those
<Noisytoot>the first mention of it is https://logs.guix.gnu.org/guix/2020-07-28.log#165135
<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.
<Noisytoot>Is there a Guix service for 6in4 tunnels?
<nckx>No.
<nckx>Is that the kind of tunnelling that e.g. HE does?
<Noisytoot>yes
<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>This is GIMP 2.10.24.
<lilyp>GIMP 2.10.28
*nckx guix upgrades 28 milligimps.
<nckx>Uh, 4.
<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>Yes.
<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
<apteryx>the lib output of mariadb
<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)?
<dhruvin>s/definitions/definition
<florhizome[m]><nckx> "florhizome: Arrived?" <- No guix home.
<florhizome[m]>It's just not in the options
<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 🤔
<vagrantcweb>and the typo checker continues ... https://paste.debian.net/1216571/ ... trying to apply changes suggested by zimon in https://issues.guix.gnu.org/44675#12 ... seems to kind of work, but errors out expecting an empty list
<civodul>hey vagrantcweb :-)
<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 head spins
***vagrantcweb is now known as vagrantc-pbp
<vagrantc-pbp>running guix system on pinebook pro :)
<civodul>so (append-map (match-lambda ...) descriptions)
<civodul>oh!
<civodul>nice
<civodul>everything working as intended?
<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>pretty quick build, though
<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>heh
<civodul>vagrantc-pbp: so see the difference between map and append-map, you can try this at the REPL:
<vagrantc-pbp>given that i don't understand either ... :)
<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>*that's
<civodul>in the second case, it applies 'list', thereby building one-element lists for each element of (list 1 2)
<civodul>does that make sense?
<vagrantc-pbp>append-map is in some srfi-N or something?
<vagrantc-pbp>but the first two examples are slowly sinking in
<vagrantc-pbp>my guile REPL doesn't find append-map
<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))
<vagrantc-pbp>and the third makes some sense
<civodul>ah yes, cool
<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
<civodul>right, exactly
<vagrantc-pbp>ok, well, almost done rebuilding guix :)
<civodul>heheh
<vagrantc-pbp> first time i used libera.chat web interface
<vagrantc-pbp>append-map for the win!
<vagrantc-pbp>took me a painfully long time to even figure out what was expecting an empty list ...
<civodul>yay!
<civodul>well maybe backtraces are suboptimal...
<civodul>i find it always help to fiddle with reduced test cases at the REPL or Geiser
<civodul>*helps
<vagrantc-pbp>tried a reduced test case little script, but it worked "fine" until i plugged it into guix/lint.scm
<civodul>bah
<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
<civodul>ideas?
*civodul is confused
<wigust>hi guix
<efraim>maybe its trying to write to the store
*vagrantc-pbp waves
<nckx>Morning Guix!
<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>tom19281: compose with list
<lilyp>i.e. ((compose list specification->package+output) "transmission:gui")
<lilyp>alternatively (list (specification->package "transmission") "gui")
<tom19281>lilyp: Thank you. That worked. https://paste.debian.net/1216584/ for posterity/logs.
<nckx>”expires: 2021-10-25 14:40:48” Very posterior.
<lilyp>in your stead I'd simply map (compose list specification->package+output)
<tom19281>nckx: Haha, good point. https://paste.debian.net/1216586/ Fixed.
<tom19281>lilyp: Thanks, I'll play around with that.
<nckx>Thanks! :)
<teddd>Hi guix !
<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
<vivien>What are these error messages?
<teddd>! Font OMX/cmfileex/m/n/5=cmex7 at 5.0pt not loadable: Metric (TFM) file not found.
<teddd>and
<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>Ok
<teddd>where do you suggest I publish it ?
<teddd> https://gist.github.com/theottm/948a78f7035c2a9a989eb50591ec43d5
<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
<apteryx>got to mozjs so far
<civodul>apteryx: nice!
<civodul>if you mean whether upgrading Python is doable, i'd recommend against trying :-)
<civodul>it's already lasted a bit too long
<apteryx>yeah
<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"?
<florhizome[m]>Or remove
<florhizome[m]>Yes
<civodul>ok
<civodul>it depends on what's in the profile
<civodul>for instance, there's the mandb hook that takes time proportional to the number of man pages in the profile
<civodul>(and which i'd like to remove)
<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 :)
<civodul>heheh
<rekado>diffoscope is now upgraded and fixed.
<civodul>\o/
<lilyp>plus imho this gives (some) power to the user
<civodul>yeah
<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.
<katco>i found this from i think rekado in irc history: https://elephly.net/paste/1612359274.html
<civodul>katco: i guess you could apply the trick above to the 'computed-file' object that builds the config file
<tpefreedom>Does guix allow you to launch app images?
<civodul>tpefreedom: Guix has nothing against AppImage :-), i guess it should work?
<civodul>you'll have to try and let us know
<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
<civodul>lilyp: heh :-)
<lilyp>Without patchelf, they will typically not find system libraries.
<civodul>aren't they supposed to be self-contained though?
*civodul never tried
<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>maybe that's the reason ?'
<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?
<jpoiret>i only see syscalls everywhere
<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>katco: yes, that makes sense
<civodul>jpoiret: it doesn't, it's just not implemented
<civodul>essential translators are set up in hurd-boot.scm and that's all
<jpoiret>i see!
<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
<civodul>argh
<civodul>jpoiret: in other news, while you're into those things, we should look into switching to netdde for NIC drivers: https://lists.gnu.org/archive/html/bug-hurd/2021-10/msg00036.html
<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
<jpoiret>so running in kernel space?
<civodul>yes, pretty bad!
<jpoiret>so much for microkernels :)
<civodul>and this is superseded by netdde, which has more drivers, for modern hardware, etc.
<civodul>*and* runs in user space
<civodul>:-)
<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>oh, great! i may look into that after I'm done with https://issues.guix.gnu.org/51346
<jpoiret>(what a curveball though)
<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>ooh, i hadn't seen this patch set
<civodul>neat
<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: Heh, sorry :)
<potatoalienof13>based on the netbsd rumpkernel?
<potatoalienof13>or does hurd have its own rumpkernel?
<nckx>jpoiret: Do you think my points make sense?
<rekado>potatoalienof13: netbsd
<jpoiret>nckx: about the naming change?
<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
<jpoiret>(if using grub that is)
<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…
<rekado>I’ll try building them all.
<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>see https://guix.gnu.org/en/manual/devel/en/html_node/operating_002dsystem-Reference.html#operating_002dsystem-Reference
<vats>Thanks jpoiret
<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
<jpoiret>hands up for plain btrfs on luks
<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)
<robin>or maybe that outdated, looks like most FSes support both "continuous TRIM" and "periodic TRIM" https://wiki.archlinux.org/title/Solid_state_drive#TRIM
<robin>that's*
<jpoiret>uhm, hurd cannot be cross-compiled?
<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)
<Gooberpatrol66>jpoiret: hurd is 32 bit only, maybe that's the problem?
<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>hello
***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
<jpoiret>seems like it's working
<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
<cybersyn>(uri (string-append "https://github.com/dankamongmen/" name "/archive/refs/tags/v" version ".tar.gz"))
<cybersyn>this is what I currently have
<notmaximed>That looks like an autogenerated tarball
<cybersyn>ah ok ic
<jpoiret>these are in fact auto-generated tarballs by github
<cybersyn>i'll just do git-fetch in that case
<notmaximed>Alternatively, you could try using https://github.com/dankamongmen/notcurses/releases/download/v2.4.8/notcurses_2.4.8+dfsg.1.orig.tar.xz from https://github.com/dankamongmen/notcurses/releases/tag/v2.4.8
<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?
<cybersyn>yes thats what i meant
<notmaximed>Normally they are put together with other packages of a ‘similar nature’
<notmaximed>E.g., emacs stuff goes in (gnu packages emacs)
<notmaximed>or emacs-xyze
<notmaximed>*emacs-xyz
<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>but it does use ncurses!
<cybersyn>but yeah, i see your point
<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>I would suggest putting it in a new module
<cybersyn>ok will do then
<notmaximed>Though a reviewer might suggest a different location
<cybersyn>alright thanks y'all! happy hacking
<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>What arch do you have?
<vagrantc-pbp>aarch64 :)
<notmaximed>If it's x86, you could, depending on the processor, do --system=x86_64-linux
<notmaximed>nevermind
<notmaximed>Possibly transparent emulation with QEMU might work?
<vagrantc-pbp>yeah, i don't think that would end well :)
<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
<vagrantc-pbp>i guess I could use u-boot's EFI implementation...
<notmaximed>Or you could create a x86_64-linux VM and run "guix build ..." inside?
<vagrantc-pbp>or ssh to a machine running guix :)
<notmaximed>guix system vm --target=x86_64-linux-gnu ...
<notmaximed>or set up offloading to the x86_64-linux machine
<vagrantc-pbp>so many options :)
<notmaximed>There is a ‘childhurd’ service to make "--system=i586-gnu" work on ARCH-linux machines, maybe it can be generalised?
<notmaximed>(cross-arch childlinux instead of childhurd)
*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_>Of course.
<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_>It is so advaned.
<awb99_>But then, if I want to use it, I need to be sure that I get current versions.
<awb99_>Sorry to put it in hard words.
<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
<awb99_>I wish I could , singpolym!
<singpolyma>lilyp: because Debian *never* "falls behind" a version someone might want . Heh, heh. ;)
<lilyp>Neither does Fedora :)
<awb99_>they really do?
<awb99_>I never checked.
<awb99_>hahah
<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>lots of test suite errors
<rekado>b
<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.
<rekado>I’ll try using a gexp
<rekado>works
<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
<roptat>and maybe ocaml-findlib
<jgart>I think I had done that too
<jgart>let me double check
<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>So, I ran this
<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>and: open Yojson;;
<jgart>but I get: Error: Unbound module Yojson
<jgart>in both cases
<jgart>any ocaml newb mistake I might be making?
<roptat>ocaml-findlib needs to be ad-hoc too
<roptat>same for yojson
***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>`ocamlfind query 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
<jgart>:)
<roptat>yeah, again I never managed to get "ocaml" working
<jgart>thanx
<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"
<roptat>or even better, use dune
<jgart>thanks
<jgart>did down ever work for you?
<jgart>ocaml-down, that is
<roptat>never tried
<jgart>oh ok
<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?
<roptat>I think so
<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>ok, cool
<jgart>I'll muster some courage together and give it a try :()
<jgart>courage and time ha
<jgart>It seems common lisp libraries also don't get sourced at the repl
<jgart>atleast on a foreign distro
<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>roptat, https://paste.sr.ht/~jgart/0e3c347e0a51a0bbff899e614e7d844a4e0b1b7a
<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>tom4345, maybe start here: https://github.com/jsoo1/dotfiles/blob/eaf7070a78cbf3d0b43623d00a7feacbbad78068/shepherd/init.scm#L6
<tom4345>jgart: Looks great, thanks!
<jgart>no prob
<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
<vagrantc>singpolyma: that's a small relief :)
<jonsger>jgart: its fixed on c-u-f I think
<jgart>jonsger, lilypond?
<jonsger>I would assume in 751b68981c57031d6f093dda688f92ebdbf50848 by rekado :)
<jgart>ah ok, I should have checked there first
<jgart>cool
<vagrantc>wow, 1.2 was released less than a year ago ... feels sort of somewhere between yesterday and forever