<maximed>PotentialUser-19: the development images aren't signed with PGP keys. <maximed>Technically, these are substitutes that are signed by the CI machine. <maximed>However, that's a nix(?) signature, not a GPG signature. <maximed>So it's not a signature you can verify if you don't already have guix set up. <civodul>maximed: that's a raw libgcrypt signature sexp :-) <PotentialUser-19>ok thank you, then i will stick to the latest release until i installed the system. <vagrantc>hah. of course tests/keys/* were formally just in tests/ and renamed. :) <lechner>Hi, I have a patch to upgrade xcb-proto to 1.15. Is the new mentors process documented anywhere? Thanks! <vagrantc>lechner: i don't think it's sorted out yet <vagrantc>lechner: definitely targeted at core-updates: Building the following 7431 packages would ensure 15670 dependent packages are rebuilt: <lechner>vagrantc: thanks! should i mention the core-updates part? <vagrantc>lechner: anyone reviewing ought to look, but doesn't hurt to be upfront just in case :) <vagrantc>though the long list is admittedly a little on the intimidating side :) <lechner>vagrantc: yeah, i'm still getting friendly with that list one by one <vagrantc>i vaguely recall some sort of "fsck" like think for /gnu/store, but not finding it amoungst all the plausible commands. <vagrantc>there's "guix build --repair" ... does that just check everything? <macrobenis[m]>To elaborate: keyboard and mouse are not working even after I installed libinput <iyzsong-w>macrobenis[m]: how you start 'xorg'? and gave a link of the 'Xorg.0.log' file here. <iyzsong-w>is your user in the 'input' group, it need permission to access /dev/input* <iyzsong-w>okay, maybe then we need to see the log file for more information.. <iyzsong-w>macrobenis[m]: seems no permission for '/dev/tty0', the user also need to be in the 'tty' group. <iyzsong-w>macrobenis[m]: looks better now, why it terminated successfully, what's in your ~/.config/sx/sxrc <iyzsong-w>you should put '#!/bin/sh' in sxrc first, and make it an executable by 'chmod +x'. <iyzsong-w>macrobenis[m]: um, try 'sx sh -c xterm' to run 'xterm' or some other X prog. <iyzsong-w>macrobenis[m]: did the stumpwm start, but without mouse/keyboard now? maybe you removed 'xf86-input-libinput' from 'xorg-configuration'? <macrobenis[m]>Xterm runs and shows up but I can't type anything as if there is no input <iyzsong-w>macrobenis[m]: did you use the 'xorg-server-service-type'? <macrobenis[m]>little bit of a noob to guix but anything xorg I configure through guix-home <iyzsong-w>okay, if you use that service in system, then libinput will be available to xorg. if you install 'xorg' and 'xf86-input-libinput' into profile, it won't find it unless you pass some commandline flags... <macrobenis[m]>was able to use my existing sway config of like 2 years with no problems whatsoever <iyzsong-w>see 'ModulePath set to' in the Xorg log, that directory should contain xf86-input-libinput, but i guess it doesn't in your case. <iyzsong-w>it can also use (need writing) a xorg home service, just like the system wide 'xorg-server-service-type', to add the needed commandline flags to set this 'ModulePath'. <vldn>how to copy a local textfile to the source directory? (writing a package definition..) <vldn>or maybe better, how to access the source directory? <iyzsong-w>vldn: something like in the 'phases': #~(copy-file #$(local-file "./foo") "./foo") <local-file> will be 'ungexp' into a store path when making the package's derivation. <vldn>like you do with "out" or $output" <macrobenis[m]>i think ill just use wayland and xwayland instead of xorg for now because i just want to get setup :) thanks for the help <vldn> (snippet #~(copy-file #$(local-file "dwm-config.h") "config.h")) works :) ty very much! <char[m]>I have confirmed that just adding #:use-module (gnu packages commencement) to haskell.scm causes tcc: unbound variable. I think it has something to do with cycles, but I do not understand. <char[m]> 'gcc-toolchain) causes it but at 14% instead of 11%. <maximed>char[m]: As written in a comment at the beginning of (gnu packages commencement), that module may not be imported. <maximed>Whether (module-ref ... ...) would be fine depends on the context <maximed>(it can be done in thunked or delayed context, but not elsewhere) <maximed>So FWIW it cannot be put in (inherit ...) or directly in (properties ...) <bdju>when is the next guix iso planned for release? it would be cool to have Sway in there as one of the default picks <maximed>Aurora_v_kosmose: --with-latest/--with-branch does not do any review (it's just some automated code, so it's not really in a position to review code) <jpoiret>i'm feeling lucky, it's time to reconfigure on staging <jpoiret>bdju: the issue i can see with sway as default is that you'll need a bunch of other apps too to have it be useable <vldn>how to prettyprint text with lot of regex e.g. "'§//'';''§\'" something like this, without intreptate that as gexp or something? <maximed>vldn: I don't see the relevancy of G-exps here? <maximed>G-exps don't care whether they contain regular expressions or not. <maximed>Is this about pretty-printing Guile code in Guix? <bdju>jpoiret: gui installer, yeah. <bdju>well, could ship it with basics like grim and slurp and wl-clipboard then <jpoiret>i'm talking about a default terminal though <jpoiret>the rest can be user-installed once there's a terminal <bdju>probably foot is the better choice <jpoiret>foot handles fonts in a unusual matter, no? <jpoiret>FTR, i am interested in adding a default "minimal" desktop experience with possibly sway and greetd <jpoiret>but the out-of-the-box experience needs to be polished still <jpoiret>maybe wayfire + wf-shell would be a better choice ***donofrio__ is now known as donofrio
<mothacehe>rekado: hey! I have root@10.0.0.10: Permission denied (publickey) when trying to ssh the aarch64 nodes using berlin root account <pmk>Hey guix. Does anyone here use emacs-guix? For me it fails to start guix repl. I am using version 0.5.2 which as far as I can tell is the lates. <nckx>pmk: I got the same error last week. <nckx>jpoiret: <unusualfootfonts> How so? <jpoiret>nckx: i think it doesn't use fontconfig at all <nckx>It's definitely not feeling too good. <nckx>jpoiret: I think you're thinking of another TE, or perhaps a very old version of foot. <jpoiret>it's literally written on the README that they use fontconfig <jpoiret>i may switch from kitty to foot then <nckx>jpoiret: Thinking about it a bit more, maybe there's something ‘different’ in how they handle fallback fonts. Still using fontconfig, but… different? Very vague because I don't know more. <nckx>But certainly shouldn't be a blocker. <nckx>jpoiret: And I haven't tried kitty. Maybe we should both switch for a week for a hi-larious reality TV show. <jpoiret>"They Switched Terminals For a Week, See What Happens Next!" <jpoiret>kitty takes a long time to start (because GPU-accel apparently) <nckx>Narrator: ‘…jpoiret is upset because the subpixel rendering is slightly wrong, whilst nckx is catting 4-GiB files to kitty to demonstrate it's 4% slower.’ <nckx>That's actually been my experience with alacritty, the ‘accelerated’ TE, but then I don't have a mining rig GPU so I have obviously failed as a consumer. <jpoiret>vte benchmarks everyone, the apex of human intelligence <jpoiret>because My VT is Faster Than Yours, and You Should Feel Bad™ <nckx>Meanwhile people obsessed with ‘bloat’ are using the Linux framebuffer, literally orders of magnitude slower than any of them. <jpoiret>I mean, no reason it couldn't be as fast as a Wayland VT <jpoiret>I don't think so, now that you're asking <jpoiret>it's been dead for years though (which I why I kind of dread using it for the installer and proposed switching to cage) <nckx>Have you been around that long? How time flies. <nckx>Ah, it would be more like running a TE in an X root window? Or am I butchering the comparison? <reyman>I finally take time to look at the jres2022 (fr) presentation of guix, great ! <reyman>i have one question about package management, what's the difference between guix upgrade ? and guix system reconfigure --xx.scm ? from the point of view of one user logged into guix os <ardon>Hi Guix! I get this error on virt-manager: "spice-client-error-quark: Could not auto-redirect USB device at 3-39: Could not open usb device (insufficient permissions)" when trying to redirect a USB device to a virtual machine. I've added a `spice` group to my system configuration, and added my home user to it, as well as the following udev rule https://dpaste.org/d2roa . However, after doing all of this, it still prompts me for <nckx>reyman: Short answer: the first is run as a regular user, and updates the packages installed by that user (using ‘guix install’, or a manifest). The latter must be run with root privilegeds and updates the OS (your ‘guix os’, which we call Guix System). <jpoiret>first tests indicate foot feels nicer than kitty, more tests to follow <nckx>Guix allows each user to install their own packages: bob can type ‘guix install gimp’ and then type ‘gimp’ to run, well, the GIMP, just like on a regular distro (but notice the lack of sudo). When alice logs in, she won't have the GIMP in $PATH or on her desktop unstill she also chooses to install it. The profiles are separate. <bdju>jpoiret: I'm not aware of unusual stuff with fonts in foot... unless you mean prioritizing emoji or something <nckx>reyman: When running Guix on another distribution, say Trisquel, that's it. But when you run Guix System, there's also a ‘system profile’ managed by root, that provides a set of base packages. <nckx>The ‘guix system’ commands manage that system, and aren't used on other distributions where Guix is just a package manager. <nckx>jpoiret: Yep, that's why I use it. No arguments. I just like the feel. <reyman>ok i understand, that's overlap if one user (me) use one os (me), i have a .scm for my home, a .scm for system, and package could overlap. <reyman>i run a guix system reconfigure without sudo, and that seems working because my user is wheel. Sudo is not needed in this case i see ? <maximed>reyman: FWIW you can make the packages field in the system configuration almost empty (maybe only nss-certs) and install everything in the user's profile, to avoid overlap <nckx>Yeah, if you are the only user the choice of what's a ‘system’ package is entirely yours. Most people would advise you to keep your system profile small (not include a Web browser etc.) because to upgrade your kernel you'd need to update the entire profile. <nckx>reyman: No, it will fail. <maximed>The download step ‘let's download the required packages for the new system’ will work <maximed>but the actual reconfiguration will fail <nckx>It will build everything but fail at the very end, when Guix actually (and almost atomically) switches to the new ‘profile generation’. But that's not a disaster, just run it again with sudo and everything will already be built and the switch will be almost instant. <nckx>But Guix does not do any (icky) ‘oh, you're in the wheel group, time to do some magic’ magic. <reyman>ok ! good to know ahah, i cut he compilation of linux kernel ... and rerun with sudo :) <nckx>maximed is an optimist and says download instead of build, in practice you'll see a mix of both :) <nckx>reyman: You can just let it finish to save the time you've already invested in building Linux. <nckx>Otherwise Guix will start from the beginning. If you let it finish, the result will be cached. <nckx>* Linux-Libre, to be precise. <maximed>I often put at least a day or so between "guix pull" and "guix package -u/guix system reconfigure" to avoid having to build too much locally <nckx>Normally I'd be surprised that you're building Linux-Libre but I did see an update scroll by… <nckx>reyman: Guix has build servers that build all packages. Your guix command will first check if such a pre-built package exists, and download it instead of building locally. <nckx>This is optional but should be enabled by default. <reyman>ok, good to know, if i want to have guix on multiple machine like say a rpi4 and my current machine, i have two .scm for each, and the same .scm for user, that's good <nckx>The link above is to that build server. It implies that prebuilt packages (‘substitutes’) should be available, at least if you're on x86. <nckx>aarch64 builds are currently broken because of hardware trouble. <maximed>reyman: if the two machines are on the same network, maybe have a look at --discover and whatever the option is for announcing in guix publlish *nckx AFK for coffee kletsing. <maximed>That way, one machine can share a locally built package to the other machine <maximed>And with some luck, a machine can get a substitute (pre-built package) from the other machine even if the ‘official’ build farm is down <reyman>And, to be sure, guix pull download new source code of package + guix only, this is guix upgrade that do the job isn't it ? <maximed>"guix pull" downloads the new version of Guix (including packaging definitions, but not the source code of the packages) <maximed>guix upgrade actually upgrades the packages (according to the package definitions in the version of guix you have pulled) <maximed>(guix pull ≃ apt get update, guix upgrade ≃ apt-get upgrade) <pmk>Is there any way to find which profile "owns" a specific directory in the store? <nckx>‘guix pull’ is ingeniously designed to make you think it's rebuilding the world, but no, it's just updating Guix + the package ‘repo’. <maximed>pmk: a directory can be used by multiple profiles <maximed>pmk: Maybe try guix gc --referrers /gnu/store/s5pd3rnzymliafb4la5sca63j86xs0y0-hello-2.12.1/bin/hello ? <pmk>I see. I will try that, thanks! <maximed>(to find out where the HASH-hello-2.12.1 store item is used) <vldn>Someone using SX and Starts xorg manually? <vldn>My Keyboard and mouse doesnt Work after Start <vldn>I'm using the xorg-server-service-type as suggested by a few others <iyzsong[m]>vldn: make sure you uninstall xorg-server from your profile, sx should start '/run/current-system/bin/X' <pmk>I am trying to debug a multithreaded application that I compiled in a guix shell container. When I start it in gdb I get this warning: `warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.` I did install both `gcc-toolchain:debug` and `glibc:debug` and I did set `libthread-db-search-path` to <pmk>`/gnu/store/xgarlnscgbm9l04karj15xpc4nn14ak1-glibc-2.33-debug/lib/debug/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib` in my gdbinit but still the issue persists. (`/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33` is where the executable finds `libpthread.so.0` according to ldd). <guixuser-87>Hi ! Is there someone who has NFS mounts working? I'm using the (service nfs-service-type), I've installed nfs-utils and libnfs on system level, but NFS filesystem entrys ain't working and manual mounts aren't either. (mount.nfs: Protocol not supported) Thanks. <rekado>mothacehe: oh, I’m using the MDC local IPs for that. <rekado>mothacehe: 141.80.167.133 (pankow), 141.80.167.132 (kreuzberg), 141.80.167.188 (grunewald) ***jesopo is now known as jess
<lechner>iyzsong[m]: It might be helpful to document your X advisories somewhere, if they aren't already. I have/had similar problems in userland <attila_lendvai>using home services: if i want to set some gnome defaults using `gsettings set ...`, where would i put it? <iyzsong[m]>lechner: yes, but i feel some difficult for docs, since i'm not a native english speaker, and i do not have internet access at home (only mobile data) now, hope i 'll back into hacking guix soon.. <reyman>I'm interested if someone have an exemple with (gnu home) <ekaitz>hi, i'm using guix shell with a manifest and even if I update the manifest it's still using packages from a previous build, how can I make totally sure that it's using the current manifest to build? it's like something stays cached <ekaitz>in any case, there's some caching happening, how can I clear everything? `guix gc`? <maximed>ekatiz: "guix shell --rebuild-cache etcetera" <maximed>However, it should be using the latest manifest (unless the manifest loads another file, which the caching code doesn't know about) <apteryx>ekaitz: the idea of 'guix shell' is that as a user, you need not care about managing the cache yourself <apteryx>I think it sets a temporary 'root' to avoid its cache being garbage collected, which gets refreshed when you use it. Thus, over time, unused 'guix shell' environments get garbage collected. <ekaitz>ooh ok maybe it's because I'm loading another file and mixing stuff <ekaitz>any idea of why the strip phase would drop a lot of "unable to recognize the format of the input file" messages? <maximed>ekaitz: Is it trying to strip .go files? <ekaitz>maximed: nope, they are c libraries, (.a) <maximed>Also, are you compiling a cross-compiler? <ekaitz>can I supress the warnings somehow? <maximed>maybe it's calling "strip" on the cross-compiled libraries, instead of only on the (natively-compiled) compiler <maximed>In the gnu-build-system module there are some #:strip-??? arguments <ekaitz>now you mention it... yes it's trying to strip the cross compiled things :D <maximed>Or maybe: fix the strip phase, such that it uses the right TARGET-strip / strip for everything <maximed>Alternatively, a big hammer would be to delete the strip phase entirely. <ekaitz>leaving it with the errors is the super big hammer option right? :D <ekaitz>even if it fails, could it be breaking anything? it shouldn't right? <maximed>ekaitz: the binaries wouldn't be stripped, but that only costs some disk space <ekaitz>maximed: doesn't sound dangerous <lechner>iyzsong[m]: Hi, I would be happy to write it up for you. I am new to Guix but have sufficient experience to translate any bullet points or irc messages, if needed. Also, my X is likewise spotty <civodul>apteryx: probably that's because Geiser renders its manual with texi2html rather than makeinfo <civodul>and texi2html has a different naming convention for HTML pages <civodul>(there's no point in using it these days IMO) <iyzsong[m]>lechner: thanks! i can anwser questions in irc later, we should talk later. going sleep now 🥱 <maximed>If I apply the compiler's hint, then the error disappears, but other errors about Debug appear in use sites. <apteryx>civodul: I see! Thanks for tipping in. I'll try adjusting Geiser to use makeinfo, if that's not too difficult to compare the result <vagrantc>maximed: FAIL: tests/channels.scm - latest-channel-instances #:validate-pull FAIL: tests/channels.scm - channel-news, no news FAIL: tests/channels.scm - channel-news, one entry FAIL: tests/channels.scm - latest-channel-instances, missing introduction for 'guix' FAIL: tests/channels.scm - latest-channel-instances, authenticate dependency <vagrantc>(guess it used to build reproducibly on armhf, too) <civodul>vagrantc: is that before changing the OpenPGP keys? <vagrantc>civodul: fixed that issue, that's why it builds on amd64 and arm64 <vagrantc>civodul: thanks for the pointer to that, by the way, it was non-obvious from my rough read of the test suite failure <maximed>IIUC, the test failure has been resolved? <maximed>FWIW there's a bug in guile-git w.r.t. endianity (it assumes size_t = big endian) (I've sent a PR upstream) <maximed>maybe there's a 64-bit assumption somewhere as well <vagrantc>there are other issues around the probably real soon now removal of guile-2.2 from debian, which guix in debian itself isn't a blocker, but dependencies of it's dependencies still use guile-2.2 ... *vagrantc is tempted to fix that by breaking the other packages... <vagrantc>if i CC only NNN@debbugs.gnu.org ... do i need to keep guix-patches@gnu.org in CC ? <maximed>vagrant only NNN@debbugs.gnu.org is required I think <maximed>Though FWIW, if you add both NNNN@ and guix-patches@gnu.org, then I've observed that no new bug entry is made, it's just added to NNN@ IIUC <char[m]>What package do I need to install to get GUILE_PKG m4 macro? <maximed>No clue how autoconf finds the .m4 though (autoconf doesn't have search paths) <char[m]>I have guile already and pkg-config too <maximed>char[m]: FWIW, maybe you could try "guix shell --pure -D gnunet-scheme" and run autoreconf etc. inside? <maximed>(gnunet-scheme is a Guile library that uses autoconf and the GUILE_PKG macro) <lechner>char[m]: my package cannot find GUILE_PKG, either <maximed>I'd give running autoreconf inside "guix shell autoconf automake pkg-config guile" a try. <rekado>also use ‘guix shell --check’ to be sure you’re not overriding variables <jpoiret>currently reconfiguring on staging 8) <voroskoi>how can i export encironment variables in a guix shell manifest file? <maximed>voroskoi: Currently, you can't (except for search paths). Though it's definitely something that could be implemented <maximed>There were some ideas for that in ML. <voroskoi>but it woukd be useful to set secrets and so <maximed>ok, that's not currently supported yet <maximed>Though for secrets this seems problematic because the store is public <maximed>(unless with secret you mean: this environment variable points at that file, which contains secrets, instead of password=1234) <PotentialUser-95>i defined a custom package with a higher version to override an existing one, but guix show does not pick it up <jpoiret>PotentialUser-95: how/where did you define it? <peonerovv>hi. i was trying to compile dwm with some patches pre-installed. one of the patches requires Xft.h. It in tern requires ft2build.h. I installed freetype but the header files are in the .guix-profile/include/freetype2 and not .guix-profile/include where Xft.h is looking. What am I supposed to do? <char[m]>maximed: I dont have guix on this system. Im trying to build one of the dependencies (guile-sqlite) so I can build guix. <PotentialUser-95>in .config/guix/system/.. , guix build -f works , guix package --install-from-file also works <jpoiret>so in ~/.config/guix/ PotentialUser-95? <jpoiret>in any case, Guix won't pick up packages defined in random files <jpoiret>you can either modify a local checkout of Guix, or add your own channel <jpoiret>the manual describes how to setup your own channel <jpoiret>what's the use case? you want a new version of an app installed in your profile, or you want a library used by lots of guix packages to be a newer version PotentialUser-95? <jpoiret>in the former, you can just guix package --install-from-file, for the latter, you'll need to upgrade the package in your own guix checkout, or use package transformers <peonerovv>unmatched-paren: no? I'm just compiling it with make? Im not totally sure what you mean. I installed guix a few days ago and am still not very familiar with it <unmatched-paren>peonerovv: as you have experienced, you may hit problems just compiling it with make <unmatched-paren>the Guix Way(TM) is to write a new package for your patched dwm that inherits the original dwm <jpoiret>PotentialUser-95: you want the updated xkeyboard-config to be used by the whole system? if so, the only way would be to modify guix source itself to update it <peonerovv>yes, that would be appreciated, Im very confused <jpoiret>note although that that package has many dependents, and a patch to upgrade it would go through a core-updates cycle (ie a merge into master every ~6 months) <unmatched-paren>peonerovv: ok, you'll want to create a `.scm` file for your patched dwm. what are the changes that have been made compared to vanilla dwm? <PotentialUser-95>any easier alternative is welcome (that doesn't imply fiddling with session) <unmatched-paren>peonerovv: now you'll probably need to import (gnu packages suckless), which defines the dwm package <unmatched-paren>my-dwm is now bound to a new package that is exactly the same as dwm <unmatched-paren>now, you'll need to hash that git repo, since guix requires a sha256 checksum to check that the download hasn't been modified/tampered with <jpoiret>xkeyboard-config would need a patch i think <Aurora_v_kosmose>maximed: That's not the part I was particularly worried about. The "automate 'update trains'" part is what I understood as a suggestion to use that to automate updating packages too. <unmatched-paren>peonerovv: you following me? have i explained everything well enough? <peonerovv>i am following slowly, just not keeping up with you <unmatched-paren>tell me when you're done with what i've already said and i'll continue <peonerovv>ill report when im done or if i have any questions. thanks! <unmatched-paren>oh, yeah, i *think* you may need to override (version) too: (version (package-version dwm)) for a reason i'll explain later when i show you how to reconfigure the package's source <nckx>Aurora_v_kosmose: I don't read it that way, ‘update trains’ is explained in parenthesis. You might be reading your worries into it. <nckx>Machine-prepared patches can be reviewed as much as human- ones. <peonerovv>unmatched-paren: the my-dwm.scm file you provided doesnt have the same parts as the examples you gave me, where and how am i supposed to import (gnu packages suckless)? <jpoiret>well, it's possible you'd have to modify xkeyboard-config's source <jpoiret>to be able to have layouts defined in multiple directories, one of which could be /run/current-system/lib/whatever/ <unmatched-paren>peonerovv: just in that (use-modules) form: (use-modules ... (gnu packages suckless) <peonerovv>but in the examples you gave me they use define-modules and not use-modules <nckx>Not to import modules. To define the name of the current one. <unmatched-paren>peonerovv: ah, that's because they're in a channel, so they need to be in modules. you're just making a standalone file, so there's no need to define a NEW module, you only need to import othrs <unmatched-paren>(define-module)'s #:use-modules MODULE is basically syntatic sugar for using define-module and then use-modules <nckx>Aurora_v_kosmose: I agree that review is important. I don't think automation threatens that though, an optimistic view could even be that it makes review more likely since the insane bottleneck pressure we currently put on human reviewers is reduced. <nckx>A bit rosy, but not illogical :) <peonerovv> so it should be (use modules \n (guix packages suckless))? <unmatched-paren>peonerovv: (use-modules \n (guix packages) \n (gnu packages suckless)) <unmatched-paren>whereas (guix ...) contains guix itself, i.e. the internals of the actual package manager <unmatched-paren>(gnu packages ...) provides the actual definitions of various packages, like suckless.scm's dwm package <peonerovv>i have never programmed in lisp or guile so this is very confusing to me <unmatched-paren>peonerovv: imagine some imaginary C-like language with a module system. this (use-modules) is basically equivalent to -- in our imaginary language -- something like `import gnu.packages.suckless.*, guix.packages.*` <peonerovv>now after that i put in "(define my-dwm (package (inherit dwm)))"? <unmatched-paren>that my-dwm is now bound to a package that is functionally equivalent to the original dwm <unmatched-paren>peonerovv: you'll want to add (name "my-dwm"), (version (package-version dwm)), and (home-page "URL-OF-NEW-DWM-CONFIG") to the package object <jeandudey>hi! I'm trying to package PySDL2 for Guix, but it requires that the libSDL2-2.0.so.0 library is available on LD_LIBRARY_PATH to search it (using Python 3 ctypes.find_library), any ideas on how to make PySDL2 find the library path? <unmatched-paren>and then do that hashing thing i told you about, and keep the hash somewhere <unmatched-paren>now you need to override the source, to download the dwm code from that repo instead of the suckless repo <unmatched-paren>now add (guix git-download) to your use-modules to import things that let you fetch git repos <unmatched-paren>git-reference is yet another record, and you need to fill it to tell guix which commit to use, etc <peonerovv>what am i supposed to put into "URL-OF-NEW-DWM-CONFIG" <unmatched-paren>since you're using a git commit instead of a version, you need to replace (package ...) with (let ((commit "COMMIT AT HEAD") (revision "0")) (package ...)) <unmatched-paren>(let ((NAME VAL) ...) EXPR) binds the symbol NAME to VAL inside EXPR <unmatched-paren>outside the (let) form, you won't be able to access the NAME variable <unmatched-paren>and then you need to replace (version (package-version dwm)) with (version (git-version (package-version dwm) revision commit)) <unmatched-paren>back to git-reference. you can now do (commit commit) and (url "THAT CODEBERG URL") in (git-reference ...) <unmatched-paren>and hopefully, the package is now complete! you then need to make the file return the package object by putting `my-dwm` on its own at the bottom <avp_>nckx: Thanks, I checked 'guix download' myself and I see that it dowloads the archive indeed. That's strange. Could it be that a regular 'guix build' uses differend request parameters? <avalenn>Is it possible to use plain-file and to set executable permission bit on resulting file ? <nckx>avp_: It must! Strange indeed. <nckx>Guess I'll point both at my server & see what differs, if anything. <peonerovv>unmatched-paren: on another thought, i think it would be better to do it with stock dwm, since this one is on an old version is unlikely to be supported. <peonerovv>yes, but i can do it myself. you said that this the "guix way" and im kind of interested in finishing it. i just think that it might be better with regular dwm. And just one thing to clarify - I would be able to modify the source code, right? Since this is the way dwm is configured <nckx>When built, it downloads a file with the right hash, same as ‘guix download’. <avp_>Well, I'm using Tor proxy with Guix -- maybe this is the source of my problems. <maximed>jeandudey; it doesn't actually need LD_LIBRARY_PATH (LD_LIBRARY_PATH leads to fragilities, so we try to avoid it) <maximed>Usually, we can avoid it by modifying the call to Python's equivalent of dlopen("blabla.so") to dlopen("/gnu/store/.../blabla.so"), by using substitute* + search-input-file in a phase. <maximed>I don't know what the Python equivalent of 'dlopen' is though. <peonerovv>unmatched-paren: so in that case, what are the changes I should make to that file? <avp_>nckx: Does 'guix download' uses the same proxy settings as the 'guix build'? <nckx>‘guix build’ doesn't download anything itself, it just fires off a build job to the daemon. <nckx>If you're setting your proxy settings (=variable?) only in your shell, that won't work. <maximed>jeandudey: Maybe have a look at the definition of 'python-screenkey'? <nckx>(…or grep for ‘proxy’ :) <nckx>avp_: Don't bother following either link though. <maximed>sneek: LD_LIBRARY_PATH is fragile and can be avoided by using search-input-file, substitute* and an extra phase, see the package definition of 'python-cairocffi' for an example. <sneek>I could be wrong, but LD_LIBRARY_PATH is fragile and can be avoided by using search-input-file, substitute* and an extra phase, see the package definition of 'python-cairocffi' for an example. <jeandudey>maximed: thanks, I've got it working by adding a `setenv` just before the 'check phase to ensure that the module loads correctly <nckx>vagrantc: You're starting from %standard-phases, not the phases of the inherited package. You need to capture those, then modify-phases those. I'll seek an example… <maximed>jeandudey: That's not sufficient -- it is sufficient for making the 'check' phase pass, but the resulting pysdl2 will be broken. <maximed>Because when it will be used in a dependency, LD_LIBRARY_PATH isn't set anymore. <nckx>…or grep for 'modify-phases ,phases' yourself vagrantc. See zile-on-guile for a sane example. <maximed>vagrantc: I think a ) is missing afet ,flags) <nckx>That won't do anything on its own, you need to ‘capture’ a variable in the (#:phases HERE) too. It can be called whatever; but yes, phases is common. <jeandudey>maximed: you're right, I guess I could just remove the search routine on the library directly and replace it with the input file. The 'check phase passes but, yeah fails when trying to use it <maximed>(Shouldn't there be a #~ (or `) before (modify-phases ? <unmatched-paren>peonerovv: you'd need to either add extra build phases or use a patch <nckx>vagrantc: In this case `(modify-phases …), not #~, because it depends on whether the inherited package (vtk here) uses gexps or not. That's unfortunate. <nckx>Eventually gexps will take over the world, I'm told, so it's temporary… <nckx>vagrantc: More people should. <nckx>I bring important tidings. *vagrantc will be sure to add this information in a comment verbatim <peonerovv>so do i still have to do this source override thing? since im going to use stock dwm <vagrantc>i didn't think it was allowed to use stock dwm on principle :) <singpolyma>I mean, there is no "stock" it doesn't compile until you make a config.h somehow ;) <unmatched-paren>peonerovv: depends on whether you use (patches) or not. personally i would just do the phases thing, it's easier than generating a patch with diff <maximed>nckx,vagrantc: FWIW, you can use #~(modify-phases ...) in the inheriting package even if the inherited package uses ` <peonerovv>maybe? sometimes they clash with each other or are for an older version and you have to patch them manually <maximed>the problem is using `(...) in the inheriting package if the inherited package uses #~. <nckx>I broke master that way. <singpolyma>#~ just looks like noise every time someone brings it up. Someday I'll find a package actually using it and break my brain <maximed>(i.e., the other way around than nckx wrote?) <peonerovv>but i can deal with patches later. can we make this file compile just stock dwm for now? <nckx>you're right, I swapped them. <nckx>vagrantc: I am fallible after all, good bye. <maximed>singpolyma: Have a look at the configure-flags of 'bamm' <nckx>singpolyma: It's quite common already and only getting commoner. <maximed>FWIW I recommend just always writing #~(...) in #:phases instead of quasiquote <singpolyma>maximed: just another string of symbols to know about <vagrantc>maximed: thanks, i'll be sure to pick the appropriate line noise :) <peonerovv>do i keep the git-download git-stuff in the file as well? you wrote that it should be in the (origin), but now that its deleted... <maximed>OTOH you don't have to remember how the quasiquote/unquote noise works in #:configure-flags & #:phases <unmatched-paren>remove the (let ... (package ...)) and replace with just (package ...) <maximed>vagrantc: Another recommendation: don't do (arguments `(#:tests? ... #:phases ...)), but do (arguments (list #:tests? ... #:phases #~(...) ...)) <vagrantc>maximed: yeah, that is a bit more readable in general ... <maximed>According to htgoebel, civodul and me, it looks a little nicer. <vagrantc>though when updating packages, i try not to change conventions i don't understand :) <maximed>And htgoebel says (or implied or something, I don't remember the details) that the ` and , is complicated and might best be avoided <maximed>Maybe "guix style" could be taught to perform quasiquote/quote -> list in 'arguments' (and basic G-expification of #:phases for consistency?) <peonerovv>unmatched-paren: i accidently closed the chat and now I cant see what you wrote before. this is hard to follow, since im not really sure what exactly you are talking about. im sorry if im asking to much, but can you write this file and maybe add comments where they are needed and then put the link here? like you did before <peonerovv>i think it might be easier to just modify the file itself <unmatched-paren>also, small mistake: (package-origin dwm) should be (package-source dwm) i think <peonerovv>no, myself. config.h contains keybindings and such <peonerovv>.patch files are usually making changes to dwm.c <unmatched-paren>peonerovv: as in, replacing its contents entirely with your version? <peonerovv>no, just making so that terminal opens with super+return and not super+shift+return for example <nckx>Yes to list, no to #true (of which you seem a fan :) ***mark_ is now known as mjw
<peonerovv>So something happened, but I'm not sure if I can run dwm, I'll have to deal with some other stuff that doesn't work. Thanks for help anyway! <maximed>unmatched-paren: because there's only a single thing inside the 'begin', it doesn't need to be wrapped in 'begin'. <reyman>I'm searching exemple of filesystem mounting of smb:// in guix home, someone already try this ? <lilyp>does anyone know why openssl checks fail on c-u? <davidl>Im defining a package and wondering is there any way to use PCRE in guix substitute* function - if not, are there any suggested/typical workarounds? I need to use a negative lookbehind. <lilyp>you can invoke sed or emacs, but then you need to add them as native inputs <lilyp>I think at this point it's probably wiser to use patch files <lilyp>they get the point across easier too <vldn>mhh my guix system doesn't use ~/.guix-profile for guix pull but instead .config/guix/current <unmatched-paren>vldn: ~/.config/guix/current is populated when you `guix pull`, ~/.guix-profile is populated when you do pretty much anything else :) the seperation is intended, and why you shouldn't install the `guix` package <vldn>thanks for the clarification! :) <vagrantc>well, vtk-7 has demonstrated my complete lack of understanding of guile. <vagrantc>i just want to change one line in the source, but i'm lost <jackhill>vagrantc: what change would you like to make? <vagrantc>jackhill: i'm lost between ' ` #~(modify-phases ... <vagrantc>jackhill: i've done this sort of thing on many packages, but i don't get how to do this when it is inherited from another package <vagrantc>jackhill: it's obviously wrong ... trying to figure out how to not use %standard-phases ... ((#:phases phases) (modify-phases ,phases ... seems to be a common enough pattern <vagrantc>jackhill: apparenlty the inherited from package uses (arguments '(#:a #:b #:c ... which affects how it needs to be modified in the inherited package <jackhill>I think my current advice is to try to stick to just using gexps for now, and everything will be a little clearer (at least to me) <davidl>lilyp: thx for the tip reg sed & emacs. I believe patch files won't be suitable, because the code base is like 10k+ lines of bash. <vagrantc>jackhill: well, i'm not sure what exactly, but cargo-culting your nginx-* package seemed to help <jackhill>ah, um, well, hopefully lightning from heaven won't strike me down, but it's a way of saying some code should run in the build environment, as opposed to when the package definition is being evaluated. Scheme already has two "levels" for running code: 1) expansion/compilation time 2) regular run time. I think gexps are an extention of that. I probably don't understand it quite well enough to teach, <jackhill>there was a lot of staring at the computer to get that one to work. <jackhill>anyway, the `((#:phases phases` part is just binding the name phases to the value of the original keyword-argument list. It could be foo, and then line would be `modify-phases foo` (modulo quoting) <vagrantc>that part i got ... although calling it #$phases was elusive to me till just copying your example <jackhill>ah, that's because it I was using the gexp-syle of quoting. I didn't need it there, but for something else deeper in the phases, so I needed to use the gexp unquote there. <vagrantc>i can get by modifying many package definitions, but then hit something like this and realize... well... i don't know what i'm doing :) <vagrantc>so are #~ the magic runes to make something a gexp ... rather than ... a ... something else? <vagrantc>gotta say, i'd prefer a gexp be called something like, say, "gexp" :) <jackhill>vagrantc: yes. #~(whatever is equivilent to (gexp whatever, just like '(something-else is equivalent to (quote something-else <jackhill>I always get confused by the difference between '(foo and (list foo <vagrantc>magic symbols are a bit rough for me to grasp ... i guess the code is moving away from `( and '( to ... (list ? <jackhill>I think all those are subtly different, maybe. Like '( won't do any evaluation in the whole thing, but (list (foo a b) c) will try to apply the foo procedure to a and be (except if it's in some sort of macro in an operating system definition or whatever that precludes the application. No wonder it's confusing! <jackhill>anyways, I have to run. Good luck! Maybe someone with more guile will come along <vagrantc>i think i need the right level of guile, i think there were some very guile advice floating around earlier, but i was still underwater trying to peer through the murky, turbulent, distorted waters see what was so plainly obvious floating at the surface <vagrantc>"oh, i get it!" ... only to find ./pre-inst-env guix build ... still explodes just as badly as ever :) <vagrantc>/gnu/store/i6yya67fr5rz8njpsbh1sqwhga55bacx-vtk-7.1.1 ... yay... now to see if the fix works! <nckx>avp_: Thanks for the patch! Does that mean you figured out the proxy problem? <nckx>civodul: The Guix or Guile manual? <vagrantc>civodul: anonymous functions are those things that make you type lambda all the time? <nckx>(Was that a serious question?) <vagrantc>civodul: i think i read that back in that day, and it got me through apparently enough to trick y'all :) <nckx>They aren't a different kind of function/procedure, just procedures that you never bothered to bind to a variable. All procedures are ‘lambdas’. (define (foo) …) is syntactic sugar for (define foo (lambda …)). But the name foo is optional, sometimes you don't bother to give a procedure a name, like you wouldn't write (define a 5) (define b 2) (+ a b) either. <nckx>Sorry if that's too basic. I was shocked to hear you were just bluffing so far :) <nckx>You're pretty good at it.