<lfam>I think you should go ahead if it fixes the problem! <lfam>It won't interfere with the 5.15 config in a serious way <lfam>I've been very busy, sorry I haven't replied <nckx>No problem at all, just didn't want to blindside you. <lfam>I did see the patch, sounds fine to me <lfam>Not gonna have a 5.15 patch ready until mid-week, probably <nckx>I am so temporally disoriented I was going to answer that was today. <podiki[m]>drakonis: what is the btrfs subvol problem you are having? I have several subvols and works for me (nothing complicated in my setup though) <drakonis>i'm trying to make guix boot from a subvol but grub isn't seeing it <podiki[m]>ah, sorry don't know. I don't have a boot subvol <drakonis>i want to have a folder named guix on my filesystem root containing guix, generating the correct grub configs works <drakonis>but i'm running into issues with getting grub to find the files <podiki[m]>I've always found grub tricky to figure out; given how behind it can be on filesystem features I also won't be surprised if it doesn't work as easily as it should <singpolyma>Nevermind, I think I finally got a query that does it <apteryx>raghavgururajan: I just checked the state of gtk 4 on fedora; there also it transitively requires qtbase (gtk4 -> gstreamer-plugins-bad -> zbar -> qtbase). <statianzo>How long does your typical "guix pull" take? I'm running it with only 7 new commits, and it's been running for 11 minutes so far. <lfam>It seems suboptimal that GTK would depend on gstreamer-plugins-bad <lfam>I wonder if we can make variants of zbar for different toolkits <lfam>statianzo: That seems like a long time. Does it say what it's doing? <lfam>That is the part that takes the longest <lfam>Would you say your computer is particularly old or slow? <statianzo>It's an older machine, but not ancient. Intel(R) Atom(TM) x5-Z8350 <lfam>Not very old, but designed to operate very slowly <lfam>It uses between 2 to 4 watts, it's optimized for low power consumption <lfam>The compute-guix-derivation is doing some work and it will chug along until it's done. <lfam>I will benchmark one of them on my 15 watt laptop and report back <lfam>We do recognize that these compute-guix-derivation steps are somewhat onerous, especially on slower machines. It's not like some other package managers where the analogous operation does not require any significant computation <apteryx>lfam: I agree! what do you mean 'variants of zbar'; can zbar be built without qtbase? <lfam>Just skimming the zbar repo web site, I see "For application developers, language bindings are included for C, C++, Python 2 and Perl as well as GUI widgets for Qt, GTK and PyGTK 2.0." <lfam>So, I wonder if the qtbase dependency is for one of those widgets <lfam>And we could make like zbar-qt, zbar-gtk, etc <statianzo>Thanks for looking into it. This is a first time trying out guix, and I wasn't sure if I'd configured something incorrectly. <lfam>statianzo: Yeah, I don't think you've done anything incorrectly. It's just that Guix is more resource intensive than other package managers... <lfam>So, my entire `guix pull` run (which includes more than just compute-guix-derivation) lasted for 154.47 seconds on a Core i5-6300U that is mostly not doing anything else <lfam>And this chip uses 15 watts <lfam>I would say the performance will scale with power usage, not sure if it's linear scaling or what <statianzo>That's way more tolerable. My pull finally finished in 25min. Probably scheduling it to run off hours would be best approach to handling updates. <lfam>If you're familiar with Debian / Ubuntu, `guix pull` is kind of similar to `apt update` and then `guix upgrade` is like `apt upgrade` <lfam>So, pulling updates the list of available packages, services, and Guix tooling, and then upgrading upgrades the packages that you've installed with `guix install` <lfam>I have a PC Engines APU2, which is based on another low power CPU. And yeah, I don't really do upgrades "interactively". I'll just do `guix pull && guix upgrade` and then come back later <statianzo>Yes, I'm familiar with it. Also, I'm a Nix user on my laptop that I'm writing this from. Surprised me a bit is that the pull took so long. Expected running `guix system reconfigure` would've been where most of the load came. <lfam>What's special about compute-guix-derivation is that it's not eligible for "substitution". Most other expensive computations can be substituted in Guix, so ideally the computer doesn't have to do very much work <lfam>I haven't used Nix in a couple years but my overall impression is that Guix runs more slowly <statianzo>I haven't run Nix on the Atom, so I can't do a real comparison of performance. Took an interest in Guix because it shares a similar declarative approach. <statianzo>Outside of the pull wait time, the guix experience has been solid so far. I'll just stick to deferred upgrades. <wleslie>iwbni we could drop the optimisation level for all of gnu/packages/ which mostly consists of data and not code <wleslie>and perhaps not even rebuild modules when neither they nor their dependencies have changed <wleslie>I've not actually profiled it, just a guess; the guile compiler optimisation game is next-level <apteryx>is it possible to specify in a package to use an input for a given architecture? <apteryx>that's needed for gcc-multilib (it wants a 32 bit glibc when building on x86_64) <apteryx>wleslie: it's already true I think (gnu/packages/ not being optimized -- it uses the base line compiler) <podiki[m]>apteryx: was just wondering the same question (was looking at wine related things, needing both i686 and x86-64 in same package def) <podiki[m]>looks like specifying a #system argument for the input, so maybe needs an explicit package with that? (I see that in dxvk32) <apteryx>system ends up being passed to gexp->derivation <apteryx>it seems that'd just tell the derivation to build for SYSTEM; hence considering all inputs for it? <podiki[m]>I'm not sure, I meant more maybe you need an explicit package def that always builds for a certain system, then include that as an input if needed? <apteryx>ah; yeah that's starting to make sense for me, thanks <podiki[m]>eg. what dxvk does: there is a dxvk32 package and that's included only for x86-64 systems <podiki[m]>I think it is making sense for me too :) I need it for 32bit and 64bit vulkan for a package, so that's probably what I need to do <podiki[m]>would be nice to modify an input package within the current package, but maybe that's not a good idea/too complicated? <apteryx>some proc could be used if it comes up often I guess <podiki[m]>right, guessing it probably doesn't outside of things like wine, virtualization, mostly <podiki[m]>I don't know much about gcc/glib but that seems like the right idea from my basic understanding. Late here but look forward to seeing how it turns out in the morning! ***lukedashjr is now known as luke-jr
***bonz060 is now known as gn2-bot
***gn2-bot is now known as bonz060
***bonz060 is now known as gn2-bot
***gn2-bot is now known as bonz060
***bonz060 is now known as gn2-bot
***gn2-bot is now known as bonz060
<kittyblam>oh great, your on this server too. Are there any moderators here? <zamfofex>If you are legitimately seeking for help, I think I can help you run binaries that were compiled in non‐Guix distros. <zamfofex>It’s a bit easier than you might imagine, I think! (Which I think is good.) <M6piz7wk[m]>zamfofex: ye though it's just exporting LD_LIBRARY_PATH but seems more complicated <M6piz7wk[m]>(steam-run is a command that has nothing to do with steam platform and is used to this as compatibility layer) <M6piz7wk[m]>> You need to have to following packages installed to make it work: gcc-objc++:lib gtk+ but this may depend on what you are running. <zamfofex>M6piz7wk[m]: For example, my friend uses Waterfox Classic as his browser. I oftentimes want to test web projects I work on also work on his browser, so I can share them with him. I use something like this: https://paste.debian.net/plainh/c5f94a30 <zamfofex>I set up a ‘~/profile/ex` profile for packages that I want to have installed for these kinds of non‐Guix binaries. <zamfofex>I have also established an ‘ex’ Bash function in my ‘~/.bashrc’ that I can use for conveniently running non‐Guix binaries more easily. *M6piz7wk[m] doesn't have that in his profile <M6piz7wk[m]> /home/kreyren/.guix-profile/lib/ld-linux-x86-64.so.2 sane? <M6piz7wk[m]>> ./script.sh: error while loading shared libraries: ./SL.sh: invalid ELF header <zamfofex>I think the problem is that `./SL.sh` is not a binary, but a shell script executable. *M6piz7wk[m] forgot to redact the name x.x <zamfofex>Is the program you want to run completely written in Python? <zamfofex>Well, then you could just run it using the packaged Python, no? <M6piz7wk[m]>yes, but that's not the expected solution as this is a renpy export that i want to run in FHS environment <M6piz7wk[m]>or well in environment where it finds the things and runs them <M6piz7wk[m]>renpy puts those in `lib` directory and then it does `exec $RENPY_GDB "$LIB/$BASEFILE" "$@"` <M6piz7wk[m]>point being packaged for FHS and doesn't work on guix >.> <zamfofex>Ah. Well, I feel like depending on the exact error you are running into, the solution would be different. <zamfofex>Modifying `LD_LIBRARY_PATH` is the same as passing `--library-path` to `ld-2.31.so`. But for binaries, you need to invoke `ld-2.31.so` explicitly because they normally set the interpreter path explicitly to abide to FHS. <zamfofex>But both `LD_LIBRARY_PATH` and `--library-path` will only really modify the path ELF libraries are looked up for binary executables. <zamfofex>They don’t really change the behavior of the system to abide to FHS or anything like that. So you’d need to figure out the exact problem you are running into and try to figure out a work around it. <zamfofex>I think if you posted the error you are getting (verbatim), it would help people figure out the problem and a potential solution. <florhizome[m]>in the guix repl (use-module guix build utils) should make available these procedures, right? shouldn’t they be available anyways? <florhizome[m]>* is trying to alter some meson.build files in build process but nothing happens and wants to check manually <M6piz7wk[m]>hmm so it's actually recreating the FHS in a sandbox x.x *M6piz7wk[m] goes to hell <zamfofex>You could probably solve your problem more easily, depending on what issue you are running into. *M6piz7wk[m] added the `echo "RENPY_PLATFORM is $RENPY_PLATFORM"` <M6piz7wk[m]>ehh is there a way to generate a path e.g. `/nix/store/k6vj0zyqqhpqzmn32jb4hbxgazkz23pr-glibc-2.33-55` on guix? so that the command expands in the path of the current glibc? *M6piz7wk[m] defined the bubblewrap thing already <zamfofex>You should be able to run `guix build glibc`, and it should output the store paths of glibc to stdout. *M6piz7wk[m] used `guix build glibc | grep "[0-9]$"` <zamfofex>I think I figured out a good, simple solution to your problem, by the way. <zamfofex>M6piz7wk[m]: Replace the last line in the `renpy.sh` file with `~/.guix-profile/lib/ld-2.31.so --library-path ~/.guix-profile/lib "$LIB/$BASEFILE" "$@"`. The whole thing should look something like this: https://paste.debian.net/plainh/db3e8b9a <zamfofex>You might then need to also install dependencies. <M6piz7wk[m]>zamfofex: i can't touch that script for this workflow <zamfofex>I see. Can you invoke `./lib/linux-x86_64/renpy` directly? <zamfofex>M6piz7wk[m]: Because then you could just write `~/.guix-profile/lib/ld-2.31.so --library-path ~/.guix-profile/lib lib/linux-x86_64/renpy`. <M6piz7wk[m]>the projected solution is `./script.sh` or `something `./script.sh` in this scenario so depending on accessing the lib path is unreliable <zamfofex>M6piz7wk[m]: Try `RENPY_GDB=~/'.guix-profile/lib/ld-2.31.so --library-path ~/.guix-profile/lib' ./renpy.sh` <M6piz7wk[m]>i can't work with those variables for the workflow though :/ <M6piz7wk[m]>as it should just painlessly make all FSH linux things to work *M6piz7wk[m] is porting the nix's solution in POSIX shell and adapting it to work on both nix and guix <zamfofex>Honestly, I was trying to give an easier ad‐hoc solution for your specific problem, but if you want to work on a general solution for Guix, I think that’s actually great! <zamfofex>If anyone finds interest in it, I have recently decided to continue working on my Hurd endeavors! I was able to get an updated Hurd system image to boot successfully! Though that still hasn’t resolved my issues with the `netdde` package, unfortunately. See here for some updates: https://gist.github.com/zamfofex/bc7279a5bddd25e8603c84c799d835dd I’m not sure if I should ask here or on #hurd, but any help would be appreciated. <kittyblam>oo nice, I need to mess with hurd someday. I don't have any skills that would be of much contribution, but would still be fun to play with what has been done nonetheless <M6piz7wk[m]><zamfofex> "Honestly, I was trying to give..." <- ... didn't realize i am doing that until you said it.. hmm i guess that's good *M6piz7wk[m] goes to add documentation and throws the maintenance on @solene <M6piz7wk[m]>The consequences for submitting broken alternative to thing i need! <tom183>I'd like to hack on a package. I can use guix shell -D $PKG to jump into an environment with a package's dependencies. Is there a command/flag to run "git clone" (or equivalent) PKG's repo? <abrenon>tom183: not that I know of, the guix shell -D command is supposed to help you develop on a local copy of some piece of software that you already have <civodul>tom183: "guix build -S PKG" would give you the source of the currently-packaged version, but not a fresh checkout <sneek>Welcome back civodul, you have 2 messages! <sneek>civodul, apteryx says: I may have asked this before (apologies if I did), but what's an easy way to test a newer guile-ssh with guix offload? do I need to run the daemon from the checkout? <abrenon>but wouldn't the sources be in the store then, so read-only ? <civodul>yes, so you'd need to copy them (or extract them) <civodul>not as convenient as one might like! <civodul>zamfofex: hi! using netdde in our Hurd images instead of the built-in device drivers would be great! <abrenon>but very convenient already ! I didn't know guix build had such an option, thank you <tom183>civodul: Ah, that's pretty close! Thanks. <civodul>IWBN to have "guix hack PKG" which would clone the source and run "guix shell -D PKG" <civodul>it's doable for things that use a git-fetch origin ***o is now known as niko
<zamfofex>civodul: The problem is that `netdde` just segfaults, and I’m not sure why! I thought updating the Hurd packages would resolve the issue (which is what I have done in my Gist), but it didn’t. <jpoiret>where can i find more info about the rationale for a daemon-based approach? <jpoiret>i seem to remember there were some papers about those, but i can't seem to find them <jpoiret>emacs does not require a server to work though <jpoiret>if you're talking about (server-start) it isn't mandatory, it can function as a standalone program without a daemon <mekeor[m]>M6piz7wk[m]: no. emacsclient requires a server/daemon. not emacs in general. <jpoiret>by default it doesn't, see C-h f server-start <rekado_>zamfofex: are you sure you’re using the correct versions? Personally, I’m always confused as to what commits correspond to the known-good Debian version. <zamfofex>rekado_: I just used the latest commits that built. I suppose I should look into Debian for appropriate commit information, then? <M6piz7wk[m]>> applying 2 grafts for /gnu/store/nax6gwgzyj22a7kl1vy8fi6vv55jdb3a-dbus-1.12.16.drv ... <M6piz7wk[m]>> applying 1 graft for /gnu/store/59g3y2rqxmi7pdnwj72plkcribc7flsi-fontconfig-2.13.1.drv ... <florhizome[m]>kinda strange behaviour: when trying to overwrite meson.build files during build, it works in the base-directory but not in subdirs. (those would be crucial, though) <zamfofex>Honestly, I wish I could use something like Valgrind on Hurd to get a stacktrace for the netdde segfault. <jpoiret>Are there no core dumps on the hurd? <jpoiret>basically, you set CRASHSERVER=/servers/crash-dump-core <fcw>Hello, how to I add /bin/sh to the build environment when building a package? <fcw>It seems that the /bin directory is not present when packages are built. <singpolyma>fcw: /bin isn't really a normal part of guix at all. Probably you want to modify the build to look where the desired shell is <florhizome[m]>> <@florhizom:matrix.org> kinda strange behaviour: when trying to overwrite meson.build files during build, it works in the base-directory but not in subdirs. (those would be crucial, though) <florhizome[m]>I tried (chmod “./metadata/meson.build” 0110), not sure if that’s even the right numerical code, but it failed due to permissions <fcw>singpolyma: But how do I add /bin/sh to the build environment? I have already substituted all instances of "/bin/sh" with (which "sh"). <fcw>singpolyma: I am using gnu-build-system, where (which "sh") gives the correct path to sh (a symlink to bash). <attila_lendvai>is anyone using pinentry-gtk-2 on a recent master? does it work as epxected? i'm testing the trezor support, and it hangs unless i override the pinentry from the default ('pinentry' which is pinentry-gtk-2) to pinentry-gnome3 <fcw>singpolyma: Guix's bash package includes a sh -> bash symlink in the "install-sh-symlink" phase. <M6piz7wk[m]>howddya detect Guix system when it doesn't provide `/etc/os-release` <jpoiret>fcw: then, which part of the build fails? <jpoiret>M6piz7wk[m]: no, guix can run on foreign distros <fcw>In the build phase of my package, I tried to create /bin/sh using something like this: `(mkdir-p "/bin") (symlink (which "sh") "/bin/sh")`, but mkdir-p fails with "Permission denied". <jpoiret>you'd have more luck with /run/current-system/configuration.scm (I'm quite sure this is the only distro with a Scheme configuration file in this place) <fcw>I discovered that I can only build the package if /bin/sh is present. <jpoiret>also, I think os-release is coming up soon, i have it on my system at least (i'm not running master) <jpoiret>fcw: in the build environment, /bin is owned by root but the build is not run as root <jpoiret>weird that in the *build* phase it tries to symlink something <singpolyma>fcw: that's where we started I think. You can't make /bin/sh be a thing, you have to patch the package to build without it <civodul>jpoiret: for guix-daemon, i recommend a paper called "secure sharing [...]" by Eelco Dolstra et al. <civodul>or, while you're at it, you might want to take a look at Eelco's thesis <fcw>jpoiret: singpolyma: I am trying to package smlnj (a Standard ML compiler). It seems that /bin/sh is hardcoded somewhere in the binary, so I cannot patch it. <jpoiret>aha yes, i just opened that thesis, although 281 pages is a bit daunting <fcw>It seems to require a binary for bootstrapping purposes, so I cannot avoid the binary either. <jpoiret>oh, smlnj is self-hosting i suppose? <fcw>jpoiret: It seems so. Is it really impossible to create /bin/sh in the build environment? <jpoiret>the thing is, /bin should be owned by root, so i guess not <jpoiret>which binary are you using to bootstrap? <jpoiret>civodul: thanks for that other paper by the way. I think i wasn't considering the security implications of it <jpoiret>well, /bin/sh exists by default i think <fcw>jpoirot: That's how I discovered that the build failure is caused by the absence of /bin/sh. <jpoiret>and can you share your package definition if possible? <fcw>jpoiret: I believe it's SMLNJ-BASIS/.cm/amd64-unix/basis-common.cm from boot.amd64-unix.tgz since it mentions /bin/sh, but I have yet to investigate further. At the moment, I only know that the problem is /bin/sh. <M6piz7wk[m]>Where should i put `~/.guix-profile/lib` in FHS3.0 ? <fcw>In other words, replace `(invoke "./config/install.sh" "-default" "64" "-nolib")` with `(invoke "./config/install.sh" "-default" "64")` to see the build failure caused by the absence of /bin/sh. <jpoiret>M6piz7wk[m]: what do you mean by that? <jpoiret>.guix-profile/lib is where it is supposed to be <M6piz7wk[m]>so that it's a compatibility layer for FHS3.0 from guix to use software that is not packaged for guix <jpoiret>fcw: do you happen to know what that .cm file is? I can only find things about the compilation manager of smlnj but it seems these files are plaintext, whereas this is not <fcw>jpoiret: Unfortunately, I do not know. <zamfofex>M6piz7wk[m]: I think either ‘/lib’ or ‘/usr/lib’. <M6piz7wk[m]>yep either should work.. just confused how the executable finds the library if it's not using LD_LIBRARY_PATH and it's not compiled in <zamfofex>I think `ld.so` will have a default. I’m not sure, though. <jpoiret>fcw: i've been looking into this, here's what i got so far. These .cm files are actually binary files that are outputs of the compiler and are loaded by the smlnj kernel <jpoiret>they're well documented, and it seems that patching that part will be quite easy <jpoiret>i'll let you know if i get something working <fcw>jpoiret: I have made some progress by adding the following before invoking the install.sh script: `(symlink (which "sh") "/tmp/sh") (invoke "sed" "-i" "s,/bin/sh,/tmp/sh," "sml.boot.amd64-unix/SMLNJ-BASIS/.cm/amd64-unix/basis-common.cm")`. I will see where that leads ... <jpoiret>although i think you should use (string-append bash "/bin/bash") instead <jpoiret>since it's the same string length, it should work properly, ahaha. I'm in the middle of writing a binfile patcher in guile <jpoiret>it's also the sole occurrence of /bin/sh in the boot files <apteryx>civodul: I'd also like to see 'guix shell -DD' that'd pull the debug symbols of the used libraries where available; perhaps even with sources added to the GDB search directories. Just thinking out loud. <apteryx>it'd have to warn at least if the direct inputs used by the package do not have debugging symbols available <civodul>apteryx: hey! yes, that's an interesting idea <guixy>guix home reconfigure fails on mkdir. <guixy>Generation 39 Nov 07 2021 15:30:20 (current) <guixy> commit: bd41e590dd24e54797fb8b6854c244efd4d12df5 <jpoiret>on mkdir? whats' the backtrace (use paste.debian.net) <guixy>It doesn't give a backtrace. <jpoiret>mhm, is it when activating, or building the system derivation? <jpoiret>do you know what mkdir command is failing? <guixy>It fails even when I give it an empty home-environment <jpoiret>i'm not sure the default activation scripts use coreutils's mkdir though, since we have mkdir-p in guile <guixy>I'm making a simple config to upload to the pastebin <guixy>I'll also output stderr to another file and upload that to the pastebin <guixy>--verbose doesn't add any more information :( <jpoiret>could you look at your activation script? it should be at /var/guix/profiles/system-nn-profile/activation <jpoiret>oh, i was confused, this is guix home, thought it was system <guixy>err.txt just says `guix home: error: mkdir: Permission denied` <vivien>guixy, I had the issue, I needed to manually create /run/user/xxx <vivien>I was reconfiguring over SSH for the first time <vivien>The home reconfigure wants to write on-first-login-executed or something <guixy>jpoiret: Why does it use /run/user/$UID to write on-first-login-executed? <jpoiret>because it wants to record runtime information for your user. That's the FHS path corresponding to that <vivien>I didn’t investigate much because I fixed the thing by sudoing myself out of the problem, and I was ashamed of myself. <guixy>The system in question didn't automatically create /run/user/$UID for all users. It's a guix system configured as a server. What system service does that? <jpoiret>guixy: at the top of gnu/home/services.scm, it says "It relies on assumption that /run/user/$UID will be created on login by some login manager (elogind for example)." <vivien>This assumptions seems unreliable to me, if you only connect via SSH it will not exist <jpoiret>although the FHS is pretty evasive for the use of /run/user/ vs other /run/ directories <jpoiret>maybe it should be the job of the system's activation service? <jpoiret>about /run, the FHS says "Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process." <jpoiret>so it shouldn't be the login manager's prerogative (although systemd maybe ignores this) <vivien>Looks like a permission error to me <vivien>Can you log in in a TTY and give back ownership of /run/user/you to you? <jpoiret>oh, it's only open-file though, so that's not the problem <vivien>It should be owned by you, group users, with permission drwx------ <guixy>I was able to change the permission for /run/user/$UID and it doesn't complain anymore. <guixy>`ssh user@address sudo ...` thinks `sudo` refers to `/run/current-system/profile/bin/sudo`. Security feature? <vivien>Mmh, it should be in /run/setuid-programs/sudo <jpoiret>although it should be in /run/setuid-programs <guixy>It is at /run/setuid-programs/sudo but it doesn't look there <vivien>But ssh user@host command does not set up the session properly <vivien>You need to type command in ssh user@host <guixy>ssh admin@toon-link.local 'echo $PATH' <guixy>/run/current-system/profile/bin <jpoiret>using guix home we could provide .ssh/environment too i guess <jpoiret>as a workaround, you could just ssh .@. bash -l <awb99>how do I create a shortcut in xfce that would run a bash script? ***lukedashjr is now known as luke-jr
<abrenon>(awb99: that was meant as an attempt to understand better what you were trying to do) <guixy>awb99: On the whisker menu, right-click any program->add to desktop. Then edit the generated .desktop file. <guixy>Or do you mean a keyboard shortcut? <florhizome[m]>> I tried (chmod “./metadata/meson.build” 0110), not sure if that’s even the right numerical code, but it failed due to permissions <roptat>florhizome[m], you probably want to use octal: #o777 or whatever <liltechdude>Good evening, what rss channel (or mail list) about tech without mention of proprietary programs you could reccomend? <zamfofex>Is it not possible to modify ‘origin’ inputs with ‘package-input-rewriting/spec’? <zamfofex>I didn’t even know ‘origin’ inputs were a thing, but it seems the Hurd packages use it for DDE. Using ‘package-input-rewriting/spec’ doesn’t seem to change anything, though. <zamfofex>I’m hopeful that updating the ‘dde-sources’ inputs of the ‘hurd’ and ‘netdde’ packages will be helpful. <guixy>It appears some substitute archives are corrupt. flightgear and rust:doc are two I can name. <guixy>Flightgear says "guix build: error: integer expected from stream" but builds eventually when I disable substitutes. <guixy>rust:doc consistently says "guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet." <awb99>guixy: Where do I find the whisker menu? <KarlJoad>I cannot tell from a guix search, but does Guix define a package that includes all TeXLive packages? <roptat>texlive-* only contain various parts of texlive <KarlJoad>But there is no texlive-all package that I could put in my system.scm file to have all packages defined by Guix be installed to my system? <roptat>it's a single package that contains everything <KarlJoad>Ahhhh... that makes more sense. I thought texlive would only contain the necessary compilers and support packages. I will have to try that then. <roptat>the small necessary package is texlive-tiny, or texlive-minimal <KarlJoad>Gotcha. Coming from NixOS, where their texlive only contains a small subset of packages, and you must specify you want all Texlive packages. <KarlJoad>I just wanto to have all the package savailable all the time, so texlive package is what I want. <podiki[m]>a lot of texlive stuff is packaged separately, but not everything <KarlJoad>Yeah, I saw that in the tex.scm file. I could not find a texlive-all metapackage that included everything, so I figured I would ask some more knowledgeable people. <KarlJoad>Also, a slighlty higher-level question, but does Guix use lazy evaluation? I know Nix does, but does the implementation of scheme that Guix uses do the same? <KarlJoad>This might also be more of a Guile question, rather than Guix. <apteryx>it comes with support to use lazy evaluation with things such as promises and streams though <KarlJoad>Ok. I was wondering why Guix was slower for certain operations compared to Nix. Good to know. <apteryx>KarlJoad: I'm not sure it's due to lazy evaluation; some things which are slow are just intensive computationally <KarlJoad>apteryx: I am mostly talking about searching for a package by its attribute/package name, rather than by "spoken" name. More just a curiosity question than anything. <vdv>how to make a multiline command in guile? <apteryx>info '(guile) Block Comments' says #! !# as you've found <vdv>also inside a definition like (define %packages `( blabla #! thisiscommented !# thisnot )) ? <roptat>yes, but inside a definition, I'd use #;, like (define %packages `( blabla #;thisiscommented thisnot )) <apteryx>not sure, I personally would hit M-; in Emacs in front of thisiscommented and it'll take care of it (via ;; and adding a newline after it) <roptat>well since I discovered #;, it's always been the right answer for me :p <jpoiret>zamfofex: aren't origin inputs just a result of the origin field in the package definition? if so you could rewrite that, no? <lilyp>KarlJoad: Guix does support both delaying and thunking record fields, however <jpoiret>florhizome[m]: uhm, you do, permissions are octal numbers <jpoiret>x is 1, r is 2 and w is 4, you sum them up to get one octal digit <jpoiret>first is the user's rights, second the group's and last is the world permissions (you also have sticky bits and setuid bit but those are special) <jpoiret>mhmmm im completely stupid it's rather r = 4, w = 2 <zamfofex>s/object/value or s/object/record or something else (I don’t know) <florhizome[m]>well with ls -l f.e. it has the exact same permissions as the meson.build file in the base dir of the repo. <roptat>could be a permission issue on a parent directory too <apteryx>florhizome[m]: what problem are you trying to solve? ***iyzsong- is now known as iyzsong
<florhizome[m]><awb99> "guixy: Where do I find the..." <- You have to Install xfce4 Plugins in the system Profile for them to work <jackhill>does guix deploy need an --allow-downgrades option? <awb99>thanks florhizome. do you know the name of the guix package for xfce4 plugins? <awb99>I really just want to do 2 simple things: 1. add shortcuts to the xfce applications menu, and then I want to create xdg open links, because my zoom that I installed via flatpak cannot open links. <podiki[m]>for flatpak make sure you have xdg-destkop-portal-gtk installed <podiki[m]>(or just xdg-desktop-portal, but that might not do much) <podiki[m]>that will handle links, as flatpaks are sandboxed and won't have access to open other things by default <podiki[m]>(and flatpak has .desktop files for the applications it installed, but you'll need to manually add a directory to XDG_DATA_DIRS) <awb99>so the flatpak files will be somehwere in the user home directory? <podiki[m]>I just did a bunch of flatpak updates so I got pretty familiar with them :) <podiki[m]>if you launch a flatpak from a terminal it will probably complain about some directories not being in XDG_DATA_DIRS, one of them won't exist on guix, but the other you can add <podiki[m]>flatpak also has a /etc/profile.d script for sourcing, but we don't directly use i right now <podiki[m]>I manually add it to my profile sourcing (if I remember just for XDG_DATA_DIRS) <florhizome[m]><awb99> "thanks florhizome. do you know..." <- the the ones you don't have by default come single, just guix search whiskermenu or similar :) <lilyp>M6piz7wk[m]: kinda late to the party, but we do have a renpy package <lilyp>though if your game requires blobs besides renpy's you're still effed :) <vldn>how to use meson > 0.57 inside a build-system? <lilyp>not sure what meson-next's version is, but it's pretty much #:meson ,variable-that-holds-meson-0.57 <lilyp>that is using meson-build-system <lilyp>if you need it in another build system, you'd add it as native-input and then use invoke <vldn>yeah but no version greater then 0.57 is packaged in guix or am i seeing it wrong? <vldn>i nead a version greater then 0.58 for new version of sway <lilyp>For the meson package you should be able to just inherit an existing package while bumping version and hash <lilyp>Guix moves a little slower usually, because there's just so much to do and only limited person time :) <vldn>could you give me a hint how to bump the version of a build system package? <vldn>(build-system meson-build-system) <lilyp>sure, you start with (define meson-0.58 (package (inherit meson) ...)) <lilyp>where ... is (version "0.58.whatever") followed by a copypasta of the (source ...), but with changed hash <lilyp>then you use #:meson ,meson-0.58 in arguments of your package <lilyp>for the hash, you can simply flip a bit in the previous hash, try to build meson@0.58 and let guix barf the correct hash at you <roptat>usually, replace the first 0 with a 1, or the first 1 with a 0 <roptat>the other characters are not so easy to replace if you want a valid hash <vldn>yeah i just copy valid hashes from other progrs usually ^^ <vldn>in nixos theres is a helper procedure to generate a fakehash, lib.fakeHash(); <lilyp>pfft, just use overwrite mode in Emacs and spam 0 <lilyp>unless you're paranoid and think someone has made your package a cryptocoin target <lilyp>and with that I wish y'all happy dreams :) <podiki[m]>there's always guix download too (for some things, not git checkouts) <podiki[m]>probably could have a nice emacs function that does that for the source at point and updates the hash? or combine with a guix refresh <florhizome[m]>"kinda strange behaviour: when trying to overwrite meson.build files during build, it works in the base-directory but not in subdirs. (those would be crucial, though) " <florhizome[m]>Element has had better controls :/ i struggled hard ^^ hopping back to my own comment... <roptat>florhizome[m], sounds like you want to chmode the directory the meson.build files are in (recursively?) <apteryx>there's a make-file-writable helper or something <roptat>so for foo/meson.build, you would do (make-file-writable "foo") (make-file-writable "foo/meson.build") *roptat needs to go, but good luck <civodul>apteryx: what's the status of core-updates-frozen*? :-) <zamfofex>From what I can see, it explicitly filters out non‐package inputs from being mapped, and leaves them intact. <florhizome[m]>But it's a lot of cheating (skipping tests some tests...) and plank f.e. ist not really working. Honestly it's just patchwork. If on c-u-f most of the upgraded stuff would be obsolete anyways. Now the first problem with gala is, it doesn't find the new libmutter... But yeah it seems all doable. Except i would like to focus on wayfire etc bc i actually want to use that^^. <civodul>zamfofex: did you want to use them to rewrite origins? <zamfofex>civodul: Yes! I want to update the ‘dde-sources’ inputs of the ‘hurd’ and ‘netdde’ packages. <civodul>you could use input rewriting to replace netdde by netdde-latest, which is your package for the latest version <civodul>but really, you should prepare it as a patch against master :-) <civodul>since that's something we'll want to have anyway <zamfofex>I guess so! I think it’d be much easier if I knew how to clone and update the Guix sources directly and use my local copy for testing. But I’m not sure how I’d go about the latter. <florhizome[m]>hm so what's the difference between make-file-writable and chmod? Actually seems like the explicit one is kind of weaker here ( less flexible) <civodul>florhizome[m]: there's a 'chmod' procedure too when you need more flexibility <zamfofex>Also, note that I do use input rewriting to replace the ‘netdde’ package currently. But what I’m trying to do is rewrite the ‘dde-sources’ native input. Which seems to not work, because the ‘dde-sources’ input is not a package, but an origin. <zamfofex>I think it’s sensible to expect to be able to replace it with ‘package-input-rewriting/spec’, though. <civodul> /spec expects a "package spec" (like "foo" or "foo@1.2"), so it definitely can't work with non-package objects <zamfofex>Ah, I see. I thought it would be referring to the input key/name. <jpoiret>you can just use package-input-rewriting, no? <zamfofex>It doesn’t work either, from what I was able to see. <florhizome[m]><civodul> "florhizome: there's a 'chmod..." <- we were just talking about that. I would need "make-file-writable-recursively". The files in basedir actually work out, my Problems are in subdirs. but yeah next up is chmod dir + chmod file <awb99>when I install xfce4-whiskermenu-plugin - how do I configure it? Does it have to be in the system profile? Or just the user profile? <civodul>florhizome[m]: (for-each make-file-writable (find-files ".")) usually does the trick <vldn>how to append a path from a binary inside the store? <vldn>in guix i do in my config.nix something like ${pkgs.bash}/bin/bash -c blabla <civodul>vldn: for example: #~(invoke #$(file-append bash "/bin/bash") "-c" ...) <florhizome[m]><awb99> "when I install xfce4-whiskermenu..." <- Yes system. Then in the Panel Menu. <civodul>vldn: where #$ is "unquote", similar to ${pkgs.bash} in the Nix snippet above <awb99>do I have to take out some other component for whiskermenu to appear? <florhizome[m]>Just put it in the packages field of your system config and reconfigure. :) <florhizome[m]>Actually i saw a commit to fix this but it's probably Not yet merged to master... <vivien>Dear guix, can someone with texlive knowledge review my patch to fix unison on core-updates-frozen? I would like to switch to that branch, but I need unison to get my mail (I feel safer with unison rather than mbsync or offlineimap): https://issues.guix.gnu.org/51435#2 <civodul>vivien: i can take a look, but i need to update/rebuild my core-updates tree first and it's a bit late here <civodul>i'm not super familiar with texlive but the two patches LGTM <florhizome[m]> seems like this has been forgotten? Seems to have been tested on c-u-f and master, but now s.o. would need to rebase it now i guess? <civodul>florhizome[m]: yes, that series looks pretty complete, it would be a shame to let it gather dust <civodul>if you'd like to give it a spin and comment, that could help a bit