<unmatched-paren>lechner: re. core-updates: rust is a little special, probably no need to work off core-updates at all afaics <unmatched-paren>lechner: re. clojure-build-system: run make clean and retry, it's a known issue <lechner>unmatched-paren: thanks on all three! <TopExpert>lechner: generally what I do is guix --pull--> (custom repo on github) <--pull/merge/push-- (guix core repo) *rekado starts writing a cookbook section on containers <pkill9>rekado: i dunno if you saw my message earlier, but i was wondering if you know what might be causing gnome on wayland to flicker the screen black, which I think you mentioned on one of the mailing lists <brendyn>im trying to migrate to a new drive and use efi, but im getting this error with the root of the drive as the target <brendyn>gnu/store/kdc2...-grub-efi-2.06/sbin/grub-install: error: /gnu/store/kdc2...-grub-efi-2.06/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory. <brendyn>i notice the i386-pc directory doesnt exist, only x86_64-pc <unmatched-paren>PSA: Framework laptop gen 12 Alder Lake integrated Xe GPU will *not* work with linux-libre <singpolyma>Ah, that's not surprising. Won't even work in an unaccelerated mode? <unmatched-paren>well, it causes the kernel to hang up and prints a scary-looking warning in dmesg <singpolyma>Hmm, yeah, reinforcing my decision to stay clear of Intel <jab>singpolyma: Are you choosing ARM over Intel/AMD ? <johnabs[m]>Yo, quick question, is there any plan to bring zotero to the packages or are they not FLOSS enough for the gnu packages? <lechner>Hi, for a patch series the Guix docs suggest submitting one patch per message. Is that just to accomodate submitters who use Git, or is there also a benefit for reviewers? <singpolyma>lechner: it's so reviewers can apply the patches using git also <brendyn>johnabs[m], i had a brief look and it appears to be acceptable. however its all written in javascript which is currently lacking in guix due to being a great big mess. that just means it may take a lot of work to add. <singpolyma>git send-email will do the right thing for you. But with guix you need to send a cover letter email first to get the bug number then use send-email to that address <johnabs[m]>brendyn: aww dang :( I'm a full time academic, any suggestions for alternatives? Maybe there's a good enough emacs package or something... <singpolyma>brendyn: JavaScript isn't a mess so much as the tooling and drive for it in guix hasn't gotten there yet <brendyn>johnabs[m], you would always install if via another package manager like nix or flatpak if it is available. i just find when i do that i cant display non-latin fonts and xdg-open often doesnt work <johnabs[m]>brendyn: There is a tarball, but I'm unsure how to write a guix package...maybe it'll be somewhat easy just following the install instructions on the website? Alternatively, there's a .deb file if it works. I don't really need non-latin fonts or xdg-open, as I only use it to ingest things from the web and organize them, the rest is accessed via emacs <brendyn>johnabs[m], to learn you need to look at examples. i suggest starting by looking at what build-system the package will likely need <johnabs[m]>brendyn: I'm unsure, but it looks like the tarball should "just work"? The install instructions just say "pop it in a bin folder somewhere and run it". I'll see what I can figure out, but I'm brand new to this whole guix thing, so fingers crossed <johnabs[m]>I'll report back if I get it working or get stuck <brendyn>johnabs[m], that means the tar is prebuilt, but usually such things dont work on guix due to the filesystem layout <johnabs[m]>I figured as much, but give me a sec and I'll let you know what cosmic horror pollutes my terminal when I try to run it lmao <johnabs[m]>Strangely, I'm getting a "no such file or directory" from bash when trying to run a file that I can both see with ls and open with vim...so bash is being a bit wacky it seems <johnabs[m]>Hmm, I know this is built on firefox, maybe I can get the firefox package and try recycling it <nckhexen>singpolyma: How's your AMD GPU performance without firmware? <brendyn>johnabs[m], that no such file refers to the linker i think <nckhexen>lechner: No reason beyond humans are weak and fallibre meat-hunks. <singpolyma>nckhexen: for what kind of task? For desktop operation etc it's plenty fine. Obviously if you're gaming much or similar GPU load tasks you'll want the Accel to work but that's just like normal <nckhexen>Oh, I dunno. I've had wildly different reports from (newish) users about how unusable an AMD is without firmware, and I don't have any myself. <nckhexen>singpolyma: ‘desktop operation’ as in GNOME fancyswooshies? That's already something. <singpolyma>I didn't try with gnome, but I expect it would be fine if your CPU isn't garbage <nckhexen>It used to fall back to Gallium or whatever, I guess that would be unnoticable on whatever Ryzen these cool kids are installing Guix on. <johnabs[m]>brendyn: It seems to break at the point of trying to access the zotero-bin file, which is strange. But before I continue, is there a way to get guix package to pull the .scm file but not build the package? I just checked the man page and don't see it as an option <singpolyma>I have a beast CPU and discrete GPU so comparing that to a cheap AMD laptop it's not gonna be the same <nckhexen>So… less that desktop cards are less firmware-crippled but that they limp better than some mobile chipsets run? Would that be a fair oversimplification? <brendyn>johnabs[m], not sure what .scm file you are refering to <johnabs[m]>Oh, I was trying to use the firefox.scm file from the nonguix channel to get some inspiration, since zotero is derived from firefox IIRC <podiki[m]>in my experience (amd 6xxx series card) linux-libre will boto with nomodeset but only gave basic support (1024x768 res?), though I did not try more, I think maybe that was also due to old mesa at the time <nckhexen>The only interpretation I can find for ‘pull but not build’ an .scm file is ‘guix build -d -f …’. But that's a wild guess. <podiki[m]>I thought I got better resolutions when I had built with newer mesa, but I can't say for sure now (this was pre last core-updates merge, mesa was pre-newer amd cards) <nckhexen>Was that because it enabled KMS, or was that still with nomodeset? <podiki[m]>maybe i'll try with the sample desktop configuration for testing the upcoming release <brendyn>johnabs[m], to be frank, i think you are in over your head choosing this as your first package. im not even sure how to build it myself. <nckhexen>To be honest, Frank is right in this case. <brendyn>i know some people have worked on getting binaries for other distros running on guix <podiki[m]>nckhexen: I don't remember for the live image I had tested, but the installer (at the time) needed nomodeset to boot <podiki[m]>I believe both 1.3.0 and from master at the time (~august 2021) <podiki[m]>I had to use installer built from master due to issues with disk partitions <johnabs[m]>brendyn: You're not wrong, but I gotta get it working lol <podiki[m]>so I would be more hopeful with an upcoming 1.4.0 <podiki[m]>zotero is a whole browser thing now, not just a browser extension? (i used it many moons ago) <nckhexen>podiki[m]: There's probably not {much,} we can do at all, but thanks for testing. <podiki[m]>nckhexen: I was wondering if the nomodeset option should be in the boot menu as a "compatibility mode" maybe? seems common for some situations <johnabs[m]>To use the plugin, you need the app, which is basically a firefox re-write <nckhexen>Even if we offer a work-around it'll probably be manual (selecting the ‘oops I bought an AMD/modern computer/non-2010-era ThinkPad’ GRUB menu option) if it needs nomodeset from the start. And then the resulting system will be… unideal. <nckhexen>Ah you typed the thing whilst I was typing also the thing never mind. <podiki[m]>yeah, it is probably indicative of poor hardware support <podiki[m]>I would want to make some live images (or point to how you can do that with guix system) for someone to try as an easy ytest <nckhexen>It's pretty easy, no? Or what are you missing? <nckhexen>johnabs[m]: The ‘plugin’… comes with a huge proprietary (in the literal sense) other thing that's the only thing it'll plug into? That's nice. <podiki[m]>nckhexen: what am I missing? I just meant maybe something in the manual or a pre-built image for people to download to try (or starting point for custom guix-on-a-stick) <lechner>Hi, is our Guix importer for Rust unicode-safe? Try guix import crate unic-emoji and check out what becomes of the hash in the synopsis <podiki[m]>I know how to do it and figured it out when i was first starting, just think it could be good outreach <nckhexen>I thought the manual had such an example, but maybe I'm mistaken. <podiki[m]>yeah, it has the info you need and sorta says it if I remember, but not sure someone looking to try guix would put it together <podiki[m]>plus there's already the system config templates that will work as a configuration to try without changes <johnabs[m]><nckhexen> "johnabs: The ‘plugin’… comes..." <- Why is it proprietary? It's the best current option that is open source, and uses the GNU AFFERO general license <nckhexen>Right. Maybe a specific ‘live’ configuration could be added? If the existing .tmpls aren't a good fit. <nckhexen>Proprietary != non-free. I said nothing about licencing. <nckhexen>lechner: Seems so, yeah. curl | gunzip has no issue with it in the same (Guix System) terminal that prints â, so it's not a system locale issue. <nckhexen>* that prints â when running ‘guix import’. <podiki[m]>I think it is a cool feature of guix that could get more attention: easy live images, from existing system configuration or as a way of making one to install later <nckhexen>Yes. Whilst there are rough edges, making a live (or vm, or…) system is *mostly* the case of typing one guix command and, oh, oh I guess that's it, there it is. Often not what people expect. <nckhexen>It's not perfect but it's actually quite remarkable when you learn how it's done elsewhere. *nckhexen was recently told to ‘just’ make an Arch live ISO. Gave up; used Guix. <johnabs[m]>Okay, so I still don't understand why it's proprietary? The software stores the files in an easily accessible format that's readable by emacs, for example, and other editors, has a freedom respecting license. The only possible complaint is that the plugin slots into the app, and that's really just a convenience. Also, according to most definitions, proprietary software is directly in contract to free sotware, so I'm not getting the <podiki[m]>yeah, I'm sure there's a cool package/AUR package for making live isos, but no way is it going to be as easy as one line *nckhexen → bedwise before the clock strikes three and I turn back into a turnip. 'nite! <brendyn>hmm. it seems its not possible to install a efi grub from a legacy bios booted system <brendyn>i was hoping i could guix system init from my running legacy system to the new drive and it would work <brendyn>but looks like i have to use the installation USB <brendyn>it feel embarrassed that the only way i know how to reply to people on the list is to fish through the mbox archives files until i find them and copy-paste their email out <lechner>Hi, I'm having a super tough time figuring out the right Rust prerequisites for sequoia-pgp. I thought it was supposed to be super easy. Does our Rust setup introduces fuzz around the version strings to limit the number of releases we distribute? <brendyn>how would i turn "C-u M-x debbugs-gnu RET RET guix-patches RET n y" in to a single function in emacs? <lechner>Hi, why would this not find version 2.3, please? guix import go github.com/rfjakob/gocryptfs@2.3 <FlaminWalrus>Anyone know how to tell GHC to find Guix-installed Haskell libraries correctly? I'm getting "ld: cannot find -lHSsafe-0.3.19-Bkx7Obebf6Y5ev72SyoL0z" et. al. when trying to build a very basic program. I do have gcc-toolchain installed, but for whatever reason, it seems the filtering doesn't make it on to GHC's invocation. <lechner>unmatched-paren: thanks! i tried that but guix import: error: version v2.3 of github.com/rfjakob/gocryptfs is not available hint: Pick one of the following available versions: 1.8.0 1.4.2 0.7.2 1.4.3 1.1.1 1.7.1 1.4.1 0.5.1 1.4.4 1.2.1 0.3.1 0.7.1 1.6.1. <lechner>Hi, can we validate upstream's tarball signatures? <lechner>FlaminWalrus: Can you share the "very basic program"? <FlaminWalrus>Behavior preserved—`guix environment ghc ghc-safe -- ghc <file>` fails with the same error <rekado_>pkill9: I don’t know what might cause this. I didn’t feel like investigating this and just went back to X11 for the time being. <antipode>lechner: Yes, signatures are validated already by "guix refresh -u". <sneek>Welcome back antipode, you have 1 message! <sneek>antipode, nckhexen says: We do, through litharge, which is a bot (oh! vile bots!) that remembers to unban the person. Unlike, say, me. That's as high-tech as it gets. That and prodding sneek's owner in #guile. <antipode>However, the PGP fingerprint isn't validated yet. <antipode>There was a proposal to list the PGP fingerprint in 'properties' or such (with a TOFU approach?) <antipode>lechner: If you are interested in the implementation, see guix/import/go.scm ***Dynom_ is now known as Guest3316
<vldn>asked in #guile already, maybe here are more guile users that could now if it is possible to crosscompile an opengl guile app to native windows <vldn>i saw msys has guile 3.0.8 but never used it <itd_>(To clarify: the missing file is "H-H1_GWOSC_4KHZ_R1-1126257415-4096.txt".) <FlaminWalrus>itd_: well, looks like my Haskell needs some work; it started thrashing and wouldn't stop for anything but SIGKILL. In any case, use of "ghc" rather than "runghc" was the issue, thanks for the help. <itd_>lechner: IIRC, the importer asks https://pkg.go.dev/github.com/rfjakob/gocryptfs ; notice, at the top of the page: "The highest tagged major version is v2.". And indeed, "guix import go github.com/rfjakob/gocryptfs/v2@2.3" finds different versions, alas, not 2.3 (for reasons I do not know, it is not present on go.dev). <itd_>FlaminWalrus: Glad it compiles. :) (#haskell isn't that far, maybe they can help out) <Kabouik>Hey unmatched-paren, thanks for the review of cobib! May I ask you a simple workflow question for v2? <Kabouik>Currently I have two commits in my branch for cobib, the first one is for the dep, and the second for cobib. I know how I could rebase to the last commit (cobib) and avoid adding a third one, but I don't know how to do add the requested changes within the first commit, so that in the end I keep only two clean commits for v2. <Kabouik>For my previous packages I simply restarted my changes from scratch every time, but that's not a sustainable workflow in my opinion. <Kabouik>I would like to add the changes you requested for the dependency and have them under the first commit, and same for the changes in cobib under the second commit. If I had only one existing commit I would use rebase, but don't know if I can do that for commits earlier than the last. <unmatched-paren>Just make a third commit, and use ``git rebase -i'' to merge the first and third together with ``fixup''. <Kabouik>That would merge the third to the second <Kabouik>I need to merge the third to the first <Kabouik>How I can literally move lines in rebase -i? <Kabouik>My reference now is your little how-to.sh for git send-email. :> <Kabouik>Well thanks! I'll try to fix the things you pointed out today. <Kabouik>I am not sure (file-name (string-append name "-" version ".tar.gz")) would work, since name in the package defintion is python-something, while on pypi it's just "something" <unmatched-paren>all ``file-name'' does is set what ``${NAME}'' is in /gnu/store/...-${NAME}, which is the path to the downloaded source <unmatched-paren>it's good practice to set it so that you can tell what's in the store path by the file name <Kabouik>So that line does not replace (uri (pypi-uri "pylatexenc" version)) but comes extra <Kabouik>Re "Would "TUI bibliography management tool" be more precise?": I'm not sure, it is actually both CLI and TUI. I could make it "Bibliography management tool with both CLI and TUI" <Kabouik>Might be best to stick to Console-based bibliography management tool though, to stay closer to the dev original wording <unmatched-paren>Eeeh, "terminal" seems to be a far more common wording, at least on Unix-alikes <unmatched-paren>I've almost never heard the Unix terminal described as a console, except for the new gnome-console app <hnhx[m]>I would like to use my custom build of dwm and st instead of the default one in the Guix repos. <hnhx[m]>I know that i have to make a custom .scm file to install my custom build but im not exactly sure how, could someone help? <Kabouik>Thanks a lot for the review and help unmatched-paren. :] <hnhx[m]>doesnt really matter how, i just want to have my custom builds :p <unmatched-paren>just return a corresponding ``package'' object from a file and do ``guix install -f file.scm'' <hnhx[m]>ye but what the .scm file would contain? <unmatched-paren>or, if you want to install system-wide, add the ``package'' object to your system packages list <Kabouik>You may want to check `guix show dwm` <unmatched-paren>hnhx[m]: so, what you'll want is two sexps in the file: (use-modules) and (package) <zpiro>unmatched-paren: console is different from a terminal! the latter doesn't come with guarantees of access to kernel, a console does. A terminal traces itself to time shared system, a console doesn't require an interrupt, it is one. <unmatched-paren>hnhx[m]: you'll need to import these modules at least: ``(guix packages)'' and ``(gnu packages wm)'' <hnhx[m]>i already had packages, i will add the second one too then <zpiro>unmatched-paren: yes, but it can be the difference of, "boss of you", or "waiting to be served". <zpiro>unmatched-paren: the ideas involved are fuzzy, but there is supposed to be a hard desiction, a terminal is a physical access with broad interpreation, a console is a hard interface. <unmatched-paren>anyway, ``(package)'' is a record constructor form that returns a ``<package>'' type <unmatched-paren>zpiro: interesting. so describing an ``xterm'' as a "terminal" is correct, and describing it as a "console" is not? <zpiro>unmatched-paren: you can use xterm as a console, it is supported o_O <zpiro>unmatched-paren: it is more, than serial console is the purest form, and your frame buffer tty is less so. and you can run xterm, generally speaking that can be set up, screen certainly support serial consoles. <zpiro>but, at the stage of, "I can boot the board over console" -- yes, you have a real console. <unmatched-paren>i see. anyway: hnhx[m]: so what you'll want to do is inherit your own package from the existing dwm package <unmatched-paren>because that's a thing you can do with guix records: (package (inherit dwm)) <unmatched-paren>now you'll need to give it a name and version: (package ... (name "my-dwm") (version (package-version dwm)) <Kabouik>Woops I forgot a change in my v3 unmatched-paren, sorry. Working on it. <antipode>Though for future people updating the package, I recommend adding the PGP fingerprint in a comment (for TOFU) <zpiro>a terminal wait to be served, a console have real cpu cycle interrupts. Both can be physical, and for terminal, one expected physically attachement involved in the sentiment, but it can be remote. such that it is a matter of knowing degrees of separation, as a terminal running a console on your little machine over usb serial console can confuse things. <antipode>'(guix)Invoking guix refresh' has some information on upstream keys <zpiro>across the bored, "I have console", implies at least the level of the terminal prvoded to access the bios to the server, mainframe or whatever it is. <lechner>itd_ antipode: thanks for hints regarding the imported. as for go.dev, i'll contact upstream <zpiro>"console" doesn't require that you have ability to cut power to the system, but often it does. anyways, it falls off into trouble. and the very least the most important part of the system you can have access to. <zpiro>anyways, difference between console and terminal in a fuzzy and muddled world :) you are welcome. <zpiro>terminal no longer meaning, that you have control, locally, physically or locally, what would generally be considered a human interface and keyboard to a time shared mainframe or supercomputer. <unmatched-paren>next, you'll need to set the ``source'' of the package to an ``origin'' record that inherits from ``(package-source dwm'' <zpiro>but be warned, and I am done with a small rant over the conceptual difference, the difference may matter more in politics and power hierachies over questions and matters you want a personal and emotional distance from. <unmatched-paren>obviously you'll need to put the patch(es) in the same directory as my-dwm.scm and add them to the list as necessary <hnhx[m]>cant i give it the path of my build and tell it to run make? <zpiro>unmatched-paren: just to enforce this rant, "if you can boot the computer through a terminal to it, is is a consol". <zpiro>unmatched-paren: to trail it off, common convention is that console is the highest priviledged interface to the machine, and generally considered to be prior to peripherals like a graphics card. <unmatched-paren>the comments should hopefully explain things; don't forget to import (guix gexp) <hnhx[m]>cant i just give it the config.h file that i made myself? <unmatched-paren>now, since our original dwm probably already has arguments that are needed for it to build, we can't just verride it <unmatched-paren>and then, since we can't assume that dwm hasn't itself modified the default phases, we can't override the phases entirely, so we modify our ``phases'' variable bound by ``substitute-keyword-arguments'' <unmatched-paren>instead of modifying ``%standard-phases'', which contains the default phases for the build system in use <unmatched-paren>and inside ``modify-phases'', we add a new ``patch-config-h'' phase after ``unpack'', which is simply a lambda that ignores its arguments <unmatched-paren>anyway, then we just do a find-and-replace of the config.h file with ``substitute*'' which should be fairly self-explanatory? <unmatched-paren>although this might lead to a hash mismatch, in which case add a ``sha256'' field to ``origin'' and set it to ``(base32 "HASH")'', where HASH is the ``actual hash: '' given in the error <antipode>unmatched-paren: The hash is computed over the unmodified source code, so no hash mismatch <antipode>(for the same reasons no hash mismatch is created when you modify 'arguments' -- if you add a snippet or patch, a new (non-fixed-output) derivation is made that takes the original source as input) <unmatched-paren>hnhx[m]: you could also just use ``git diff'' to turn your config.h edits into a patch <hnhx[m]>btw couldnt i just modify the original dwm.scm? <hnhx[m]>i could upload a tar.gz on my server and just replace the link <hnhx[m]>unmatched-paren: i dont ever plan on using the vanilla version of dwm so it would be fine ig <kraai>Hi. I've packaged doctl 1.73.0. When I try to package the latest version, 1.83.0, it fails, I think because it requires a Go 1.18 or 1.19. Is there a way to build it using one of those versions? <unmatched-paren>kraai: the ``go'' variable is defined as equivalent to ``go-1.17'', as changing it would trigger mass rebuilds, but we do have a ``go-1.19'' package <kraai>Is there a way to use `go-1.19` to build the package? <kraai>It fails with `In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): go-1.19`. <nckhexen>There are some weird things going on in that code snippet. <unmatched-paren>also, it seems a little misleading, as it's saying "your config.h here" as if writing your config.h in that string will make it work <unmatched-paren>or just patches, with your own patch generated for the config.h changes <kraai>There are a bunch of things in the vendor subdirectory of the doctl source code; is that OK or do they need to be packaged separately? <hnhx[m]><unmatched-paren> "just use patches and a snippet..." <- i think i will just give up and use vanilla dwm <kraai>unmatched-paren: OK, thanks. <hnhx[m]>also i have some projects in C that im working on and i cant seem to compile them at all, do I need to make scm files for these as well? <unmatched-paren>hnhx[m]: ``guix shell --pure gcc-toolchain make [other deps]'' should work <unmatched-paren>it's good to write scm files for them though, as it makes it easier to build and test in one go <hnhx[m]>unmatched-paren: this doesnt really work <antipode>hnhx[m]: 'Doesn't work' isn't really informative, how does it not work? <antipode>(We can't see what's happening on your computer from over here) <antipode>Like, I assume there is some kind of error message. <hnhx[m]>well it puts me into an environment where i cant really do anything <antipode>You can't run "make" because of the --pure, IIUC. <unmatched-paren>it'll put you in an environment with only those packages that you specify available <antipode>If you want make, add it to the [other deps]. <antipode>(Also, --pure is the default for "guix shell", it seems to be a left-over from the old "guix environment") <hnhx[m]><unmatched-paren> "admin: ``guix shell --pure gcc-..." <- i thought this would just run make and compile my program <hnhx[m]>i can run make ye in that environment but nothing else <hnhx[m]>i can run make yes but it wont compile <hnhx[m]>it seems like the cc symlink doesnt exist, not even in that environment thing <unmatched-paren>When I try, with `SDL_VIDEODRIVER=wayland openttd' it simply says there's no suitable video driver <unmatched-paren>and when I try with ``SDL_VIDEODRIVER=wayland openttd -v wayland'', it says there's no video device available. *unmatched-paren reenables xwayland :( <dthompson>unmatched-paren: if that's true, it's a bug because wayland and wayland-protocols are inputs to the sdl2 package. <sneek>Welcome back dthompson, you have 5 messages! <sneek>dthompson, ArneBab says: When using chickadee play, I got chickadee/image/png.scm:354:31: ERROR: <sneek>dthompson, ArneBab says: 1. &message: "PNG images using color palettes are not supported" at In chickadee/graphics/texture.scm: 404:20 2 (call-with-loaded-image "walking_dragon-ari.png" #f #t #) <sneek>dthompson, ArneBab says: The way I found to start a script with the lowest possible latency is to define a module and then run it with guile -L . -e '(module name)' <sneek>dthompson, ArneBab says: Please tell me once you have a new chickadee release so I can link it on the wisp page! <dthompson>sneek I wish you were sensitive to the channel <unmatched-paren>dthompson: looks like we explicitly pass --disable-wayland-shared to sdl2's configure though <dthompson>unmatched-paren: SDL2 has some confusingly named configure flags. I don't think it does what the name looks like. <dthompson>my memory is fuzzy, but I added the sdl2 package back in 2013. <dthompson>I think there's a distinction between explicitly linking against the shared library and using dlopen at runtime. <dthompson>--enable-video-wayland is the configure flag for enabling/disabling wayland support and the default is "yes" which we do not change <kitzman>funny. i've had issues in the past with gnutls having invalid opcodes. first on amd64 hyperv under qemu. changing the processor fixed it. now on gentoo under xen as dom0. tried recompiling with different flags, no success. however, running a daemon i have in the guix store works with no issues. <dthompson>when wayland-shared is enabled, it adds a video mode "wayland(dynamic)" which I think means that it will dlopen wayland. with wayland-shared disabled, it adds the wayland libraies to LDFLAGS. so without actually running this build, it seems that were are opting to link against the wayland libs. <dthompson>someone else added this wayland stuff to the package. I have never actually used wayland, though I should really try. <unmatched-paren>very easy to use, you just run the compositor program, there's no "Wayland server" like there is the "Xorg server" <dthompson>it would be cool to have a wayland window manager written in guile <ArneBab>unmatched-paren: does exwm work with wayland? <unmatched-paren>Nevertheless, teh Interwebz being teh Interwebz, people find a way to claim it's the worst thing in the world. <hnhx[m]>i want to use my config.h instead of adding everything from config.h to the scm file <unmatched-paren>what you actually need to do is modify the config.h directly with either a patch or substitute*'s search-and-replace <hnhx[m]>hnhx[m]: so there is no way to achive this? <unmatched-paren>it'd be silly to copy-and-paste your modified config.h into the recipe <hnhx[m]>what about just making a brand new package? <unmatched-paren>just use guix's builtin support for patching source code with patches/substitute* <hnhx[m]>unmatched-paren: i dont want to patch the existing dwm package, i want to make a brand new package with my fork of dwm <hnhx[m]>i should just go back to parabola i have been trying to get this work for hours .-. <unmatched-paren>(package (inherit foo)) is just a shortcut for copying and pasting ``foo''. <unmatched-paren>hnhx[m]: that's because ``guix package -f'' uses the last object in the file <unmatched-paren>you need to either remove (define-public) or add ``my-dwm'' below the form to return it from the file <ArneBab>unmatched-paren: that’s a showstopper. With exwm I finally have a work environment that really works for me (productively at work) and I don’t have love left for things that break it. <unmatched-paren>ArneBab: well, wayland has an entirely different architecture to xorg <unmatched-paren>so turning an x wm into a wayland compositor basically requires you to nuke the thing and rewrite it <hnhx[m]>\ 'build' phasebuilder for `/gnu/store/b529s119flqib1z02xqaya1zjz4jd37x-dwm-6.0.drv' failed with exit code 1 <hnhx[m]>build of /gnu/store/b529s119flqib1z02xqaya1zjz4jd37x-dwm-6.0.drv failed <hnhx[m]>build log is a bunch of gibberish lol <hnhx[m]> * ye, i dont really understand either <unwox> unmatched-par… you using the version you sent or the version i sent? <unwox> unmatched-par… you using the version you sent or the version i sent? <hnhx[m]>> guix package: error: cannot install non-package object: #<unspecified> <unwox> unmatched-par… you using the version you sent or the version i sent? <unwox>oops, sorry, my irc client freaked out <unmatched-paren>hnhx[m]: ah, replace ``(gnu packages wm)'' with ``(gnu packages suckless)'' and add ``my-dwm'' to the end <unmatched-paren>ArneBab: the problem with x is that it's inherently deeply flawed, and many of the xorg devs understood that <unmatched-paren>wayland ain't x12, it's a completely new library. sometimes you do need to replace things that are aging. <unmatched-paren>that would be a valid criticism if it were intended as an "upgraded X", but it's not <unmatched-paren>i've used libwayland, and i've looked at libxcb, and i can confidently say that the former is far, far better <dthompson>I think it made sense to use an entirely new architecture. computers are very different now than when X came into existence. <dthompson>X working on modern computers is a tower of hacks. having something purpose built for the world of dedicated graphics hardware, among other things, is great. <unmatched-paren>ArneBab: Also, ddevault is one of the most preeminent Wayland advocates and experts, so using one of their blog posts for arguing against wayland is a wee bit ironic :) <unmatched-paren>dthompson: Yeah, there's all the purpose-built XF86 graphics drivers and X drawing APIs <unmatched-paren>Wayland always uses KMS and comes with no drawing procedures; you have to use buffers or EGL instead <hnhx[m]>@unmatched-paren okay so it worked this time, huge thanks again for helping. <hnhx[m]>my only other question that i would have is, is there any way to use just local files instead of (method url-fetch)? <antipode>hnhx[m]: Search for 'local file' in the manual. <unmatched-paren>hnhx[m]: replace (origin ...) with (local-file "PATH" #:recursive? #t) <antipode>(first search result, in (guix)G-expressions) <hnhx[m]>unmatched-paren: this worked, thanks! :) <ArneBab>unmatched-paren: I don’t consider it ironic — it’s just the consequence of following their principle <ArneBab>unmatched-paren: the fun part is that both for drew and me Python 3 is what caused that way of thinking. I lost a tool for several years that I did not have the time to finish fixing, because it was not essential enough to warrant being put first. I expect the same to happen when wayland becomes effectively mandatory. <ArneBab>When that happened, I just stopped doing the things that needed it. And when pulseaudio broke audacity and interaction with my external sound card, I stopped recording music for several years. <unmatched-paren>Hmm, apparently I need to recompile the kernel with HID_MULTITOUCH=m to get my touchpad working right... <hnhx[m]><unmatched-paren> "Should that be added to the..." <- do you mean the kernel boot params? <hnhx[m]>well ye then wdym by default kernel options then? <hnhx[m]>if I were i would run make menuconfig (or edit .config) then just enable the required kernel module and build it via make -jx && make modules_install && make install *unmatched-paren hopes building linux won't take toooooo long <hnhx[m]>unmatched-paren: oh i see, well i wouldnt call it much better since it seems like debloating the kernel for an example would be a pain in the butt compared to just running make menuconfig <hnhx[m]>unmatched-paren: what cpu do you have? <hnhx[m]>compiling a heavly debloated kernel took like an hour :p <hnhx[m]>unmatched-paren: what about nomodeset? have you tried that already? <hnhx[m]>i mean ye i get that xorg is abandonware and whatnot but its still better than running nonfree stuff <lechner>Hi, I am trying to package Gocryptfs. Why would the golang build system say package github.com/jacobsa/crypto: no Go files in /tmp/... for one of the included source packages, please? https://paste.debian.net/1256472/ <djeis>I'm running into a rather strange issue with guix home- it's complaining I have two different versions of a package in my home profile, one I'm pulling in explicitly and the other propagated from a package, but I cannot identify difference between those versions of the package would be. <hnhx[m]><unmatched-paren> "i just use a blobby kernel" <- also does guix have optional non free repos? or are these repos that you use 3rd party? <djeis>The package is password-store, I'm pulling it in explicitly using specification->package in the packages list of the home config and I have a home service putting emacs-password-store into the profile elsewhere. guix home tells me they're two different store locations, but when I try to guix build password-store the one I get matches the one home says propagated from emacs-password-store (not the unlabeled one which, presumably, is the one coming from <djeis>Anyone have suggestions for where I should look to resolve this? <unmatched-paren>the invocations should be patched to refer directly to the store path <djeis>Yeah, makes sense. I suspect that'd be nontrivial though, since you'd have a heck of a time identifying which uses of "pass" are the binary and which are the prefix in front of every function in the elisp. <djeis>And you couldn't do that as a diff, right? Since the thing you're replacing it with is a store path. <djeis>*every defined function, to be clear <unmatched-paren>surely you could just replace every "pass" in double-quotes, though? <djeis>As for grafting weirdness... That's the really odd bit, when I ran guix build password-store it actually had to do the grafting right then. But the source path for the graft was a third path entirely. *unmatched-paren has literally just opened a new wip-emacs-password-store-no-propagated <djeis>I'd need to look at the source, but I could imagine ways that it wouldn't be that simple. <djeis>Launching subprocesses in emacs involves a lot of different strings. <unmatched-paren>s/``(executable-find "pass")''/(search-input-file inputs "bin/pass")/ <TopExpert>hi, is it possible to remove the "gcc" from the "gnu-build-system" automatically as inputs to a package? <TopExpert>I mean gcc is added automatically and I'm not sure how to remove that input <djeis>Yeah, they were good about making a config var, nice!. <TopExpert>unmatched-paren: trying to use clang for a package and it picks up gcc automatically from somewhere idk <TopExpert>and I can't seem to be able to remove it from the inputs <djeis>Still, that doesn't really explain my situation... the ungrafted version of password-store is a different package entirely. <unmatched-paren>you'll want to add #:configure-flags #~(list (string-append "CC=" #$(clang-for-target))) or something. <unmatched-paren>Try looking at the ungoogled-chromium package, I believe it requires clang to build. <djeis>And (for my own sanity, if nothing else) I used guix repl both to build the result of calling specification->package and to extract the input to emacs-password-store and build that- both matched the guix build password-store result and what guix home said was propogated from emacs-password-store... <djeis>I have no idea where this other version of the package is coming from. <djeis>Yeah but that wouldn't impact the store location, would it? <djeis>The store location is based on the build hash, not the content hash, last I checked. <djeis>Afaik guix doesn't implement the content addressed store stuff that's been added to nix. <djeis>The recommendation from guix home was "upgrade both password-store and emacs-password-store", but I feel like that's actually the profile machinery where upgrading individual packages is a thing... In this case I'm pretty sure all of the references already are to the latest versions of the package defs... <djeis>I don't think the guix home profile is, like, stateful in the same way the plain user profile is, right? <djeis>...huh. The version of pass in the currently-active version of my guix home does come from this mysterious other store location. <djeis>But I must have reconfigured my guix home a couple dozen times in the last few days. <djeis>Clearly guix home is getting this package from somewhere, but... the only thing that would've been pulling it in before is the (map specification->package (list ... "password-store" ...)) in my home config. <djeis>Ha! haha! Now that is Very Strange. <djeis>It's something to do with package transformations all right. My emacs packages optionally go through a package transform which replaces emacs-minimal with my custom emacs build, so I get native comp. I just turned that off for emacs-password-store, and now it's propagated password-store isn't giving trouble anymore. <djeis>But... password-store itself doesn't depend on emacs-minimal. So... my only explanation is, I was blocking some package transform that is being applied to the other packages in my profile? <djeis>That would explain why the path in my guix home profile doesn't match the one from guix build. <djeis>It is, yes, but native comp needs to match your emacs build. <djeis>Can't compile with one emacs and use the artifact with another. <lilyp>yep, that's an Emacs limitation <djeis>So... do package transforms not stack? And... why would the other packages in my guix home be getting transformed... <unmatched-paren>Now to deal with the others in the surprisingly large set of pass-related emacs packages... <djeis>The other headache is that emacs-password-store has elisp deps in common with another one of my emacs packages that I would like native-comp'd, so if I turn off comp for emacs-password-store I get a similar "multiple package versions" error but for the propogated elisp deps... So I can't reallu just turn it off. <lilyp>djeis: the trick would be to only apply native-comp to the inputs of password-store, but not password-store itself <lilyp>that's a slightly more complex transformation, though, which isn't easily supported by the CLI <lilyp>in other words, you'd have to write Scheme code <djeis>Yeah, but I'm not doing any of this with the CLI anyway and I've got plenty of scheme machinery in this already. <djeis>It might not be a bad idea to make my emacs packaging home service a little cleverer about which packages need native comp and which don't. <djeis>Plus the problem seems to just be that I'm applying a transform to the password-store dep at all, and that... I guess blocking? blocking some outer transform happening to the other packages in my home profile. <djeis>Okay, so... my guix home profile has a version of password-store which isn't just the result of guix build password-store, and I don't know why. I'm grabbing it with specification->package, and nothing in my guix home config seems to indicate a package transformation (apart from what I'm doing with emacs packages). <djeis>Does guix home implicitly apply any package transforms? <lilyp>djeis: get your friend, the rubber duck <lilyp>"parasite to undermine guix" *unmatched-paren has never heard that term *unmatched-paren looks it up <djeis>I'm trying to make a minimal repro using guix home container now... <TopExpert>unmatched-paren: do you know if there's a build system that uses clang by default? <TopExpert>gcc seems to add other things like C_INCLUDE_PATH <TopExpert>what I build still seems to pick up gcc for some reason, maybe I apply setenv too late <djeis>So, I've managed to reproduce the guix home profile having a different password-store even with just a home config that's empty but for putting password-store in the packages list. I'm now testing with all of my channels off and a recent pull of guix master. <unmatched-paren>Hmm, I should make another attempt at supporting application of patches to Guix channels... <djeis>Yeah, they're still different. <djeis>Both paths are different on guix master (I'm, like 100 commits behind) but guix build still disagrees with what guix home puts in the profile. <lilyp>unmatched-paren: you either write your own search-patches or put them at the channel root, not difficult <lilyp>djeis: (define my-emacs-password-store (package (inherit emacs-password-store) (inputs (map my-transformation (package-inputs emacs-password-store)))) <lilyp>note that you might have to adapt my-transformation to take the labels into account <djeis>package-inputs returns the ... Yeah, the labels. <djeis>But yeah, I have https://paste.debian.net/1256477/ as a minimal guix home config. I run it in guix home container and "ls -al .guix-home/profile/bin/pass" to see pass' store path and compare that with just running guix build password-store. <lilyp>unmatched-paren: you could do something with a little guile-git foo <lilyp>that being said, I think it'd be a little too much maintenance burden for guix proper and those things are better handled as part of CI <lilyp>note that patchwork already applies single patch series <unmatched-paren>ah, that's a shame. i'd like to be able to use patches that haven't been merged yet without maintaining my own fork <djeis>Guix home must be applying a package transform of its own, otherwise I don't see how those could be different paths... <djeis>Except I don't see anything in the guix home source that would be doing that. <unmatched-paren>I think i'll give it a shot, and if it's rejected, then, well, I tried :) <unmatched-paren>Oh, lovely, there's already a guile-email library that can read mboxen :) <Kabouik>How can I know which package provides libwayland-client.so.0? <unmatched-paren>Kabouik: I believe you can look it up on the Guix Data Service somewhere... But it's in ``wayland''. <Kabouik>You know it is in `wayland` just because you are used to it, but is there a way to search which guix packages provides a file? Like for eopkg file manager, there is a search-file option for instance <Kabouik>(But thanks, knowing it is in Wayland will help already, the reason I missed it is because an appimage is complaining about it: I have Wayland installed, but perhaps not in the fhs thingie that pkill9 cooked) <unmatched-paren>There's no such command right now, but it'd likely be possible to write one. <pkill9>unmatched-paren: you can do that? <pkill9>look files up in the guix data service? <pkill9>I think it was a desired feature <Kabouik>That'd be useful I believe, but perhaps a lot of work <unmatched-paren>Kabouik: There's a third-party Nix extension that implements it, so it should be possible with Guix. <unmatched-paren>sneek: later tell cbaines: sorry for the long delay, but I've finally sent a rebased and slightly amended version of the greetd-wlgreet-sway-session patch to its issue :) Thanks for reviewing it! <djeis>...so, it's not even guix home, it's... fontconfig, maybe? <djeis>If I guix shell password-store and look at $GUIX_ENVIRONMENT I get one password-store, if I guix shell password-store fontconfig and look at $GUIX_ENVIRONMENT/bin I have a different path to the pass binary. <djeis>And guix home implicitly puts fontconfig on your profile. <unmatched-paren>If I typed exactly what I'm thinking about that you'd just see a whole flood of "disbelief" ellipsises. <djeis>I don't really understand it myself, it doesn't make any sense to me. <djeis>It also doesn't happen when I pair up password-store with any of fontconfig's propagated deps. <djeis>I'm kinda just lost at this point. <djeis>And... something about applying any package transformation fixes it. <old>Eeeh sneek failed to deliver message to pkill9 :-( <jpoiret>@djei: What do you mean you have a different path to the pass binary? <pkill9>it might have been in one of the other channels <pkill9>i can't remember what it was about <djeis>jpoiret: I mean the symlink in the bin/ folder of the profile goes to a different store location. <jpoiret>if you do `readlink -f $GUIX_ENVIRONMENT/bin/pass`, you should have the "canonical" pass binary path <djeis>It disagrees with what guix build password-store returns <djeis>And with what I get when I build a profile with password-store but without fontconfig. <jpoiret>i do get the same exact path for the bin/pass binary <jpoiret>ah, I did not compar with guix build <jpoiret>are you sure you're using exactly the above command to get the canonical path? <jpoiret>if you are, and you're still getting mismatched paths there's definitely an issue <djeis>Allow me to be a touch more rigorous, one second. <djeis>jpoiret: So, I can't quite seem to reproduce this with guix shell all of a sudden, and I don't really know why... But I have a scheme expressions which build one profile that has both password-store and fontconfig and the other which only has password-store and sure enough they disagree on the cannonical path to the pass script <djeis>And I've now reproduced it on a second machine and on a time-machine build from guix master. <nckhexen>old: sneek is ‘cross channel’ in that it will deliver your message wherever it sees that person next (luckily, she only lurks in about 3). <jpoiret>djeis: well, at least i get the same output as you do <podiki[m]>something something fontconfig has grafts.....? <djeis>The weirdest thing is how I discovered this- I applied a package transform to emacs-password-store and put that in my home config profile, and all of a sudden guix home complains that I have two different versions of password-store in the profile. <djeis>emacs-password-store propagates the password-store dep, at least until the patch for that is merged. But, the version of password-store it was propagating to the profile is the one I get from guix build. <djeis>At least, it was until I stopped applying the transform. <djeis>If I put an untransformed emacs-password-store into the profile I don’t get the conflict. <jpoiret>both password-stores are built using differing derivations <jpoiret>and they seem to be different because the builders (which are just doing grafting) don't have the inputs in the same order <jpoiret>so what I'm thinking is that the grafts caching somehow influences the order in which grafts are performed, and so building two packages with the same store connection will lead to this inconsistency above <jpoiret>but it's just a hunch for now, I don't have anything to base it on <old>nckhexen: Right. Is this the intended behavior? <jpoiret>I've isolated the issue: `(with-store store (run-with-store store (package->derivation (specification->package "password-store"))))` doesn't give the same derivation as `(with-store store (run-with-store store (mbegin %store-monad (package->derivation (specification->package "fontconfig")) (package->derivation (specification->package <jpoiret>right, only "git" gets re-ordered too <jpoiret>in the "wrong" derivation, it's higher up <nckhexen>old: Yes. I've suggested having it say ‘in #guix, foobar said’ or something similar, but that wouldn't address your situation of not notifying the author if you don't share a channel. <nckhexen>I don't think there's a good solution that will please everyone, or at least I don't see one. <old>Also the problem that sneek would talk about Guile in Guix <old>Not a huge problem, but it's out of context <podiki[m]>jpoiret: weird! is that true for packages that don't have grafts? <podiki[m]>(or inputs/propagated inputs without grafts?) <jpoiret>i think this is a grafts specific issue <jpoiret>I mean, yeah, if a package has a graft down in its recursive inputs, maybe it's affected <jgart[m]>Is anyone interested in packaging crystal from bootstrap? <antipode>There were some questions on crystal packaging in the ML, IIRC <jgart[m]>but I haven't found the motivation/time to continue working on it <antipode>Didn't remember "some people" = jgart + unknown. <jgart[m]>Would people be interested in a crystal packaging from bootstrap for Guix meetup? <antipode>Huh someone has 'unknown' as nick. I don't know if unknown is interested. <jgart[m]>The meetup would be themed around reopening and resolving #49158 <jgart[m]>I talked to unknown the other day but ya you're right <antipode>‘I talked to unknown the other day ...’: is this meant literally or as a joke (or both)? I can't tell. <unmatched-paren>looks like i'm gonna have to submit an MR to guile-git to add support for git_diff_from_buffer and git_apply <jgart[m]>I think the meetup will help crystallize the packaging process <jgart[m]>unmatched-paren: Can you add support for worktrees also while you're at it? <jgart[m]>Does orangeshark still maintain guile-git? <unmatched-paren>jgart[m]: It's not too hard, you only need to look at the C API and translate that into FFI calls <jgart[m]>I'd like to reach out to him at some point <jgart[m]>some random suburb that know one knows about too <jgart[m]>unmatched-paren: It's like the Huddersfield of the US <unmatched-paren>Maybe, given guile-git's status, it would be better to put the ``apply'' and ``buffer->diff'' functions in (guix git)? <jgart[m]>I would just send a patch first to orangeshark <jgart[m]>So orangeshark does not maintain it in their GitHub repo since a while <unmatched-paren>Fortunately it looks like (git bindings) provides helpers for writing extra bindings not provided in (git) <jgart[m]>civodul: Where should unmatched-paren send it? <johnabs[m]>possibly off-topic, possibly dumb: is there a point in using pass-tomb if my disk and keys are both already encrypted? <jgart[m]>unmatched-paren: That reminds me of those macros that guile-json provides <jgart[m]>extensibility is how all these libraries roll it looks like <civodul>jgart[m]: on gitlab.com or otherwise guix-patches :-) <civodul>Orangeshark has been MIA for a while <jgart[m]>civodul: He's working for Microsoft last I heard <jgart[m]>Since then he's been MIA at least last time I tried reaching out over a year ago <jgart[m]>OrangeShark was actually part of the LibreMiami meetups before I joined them. He started that with them <jgart[m]>That was before OrangeShark started at MS <singpolyma>jgart[m]: you mean your guiler is gonna help drain MS' money ;) <ric342[m]>Has anyone seen any GUIX router projects to either replace openwrt or create a custom build of it declaratively <jgart[m]><singpolyma> "jgart: you mean your guiler is..." <- I hope so ;() <ric342[m]>I don't quite get what guix is suppose to mean <ric342[m]>At first I thought something for GNU but GNU is already in the name <jgart[m]>ric342: try understanding what gexps are supposed to mean <antipode>ric342: I don't think Guix is really meant to mean anything <unmatched-paren>jgart[m]: I believe it actually was originally just a Guile program to talk to the Nix daemon <jgart[m]>unmatched-paren: it still is a guile program that talks to the Nix daemon <ric342[m]>Is a scheme rewrite of nix daemon still in the works? <jgart[m]>unmatched-paren: iirc very little was changed about it <jgart[m]>upstream Nix daemon is way different now ofc <unmatched-paren>jgart[m]: a scheme guixd would probably be easier to maintain by far... <jgart[m]>It probably has tons of lines of code more <jgart[m]>unmatched-paren: Ya C++ is a blub language <jgart[m]>Maybe we should be rewriting the daemon in guile-steel? <jgart[m]>I mean that's why guile-steel was invented right? <jgart[m]>Nix daemon in guile-steel doesn't exist yet either <antipode>xd1le: don't know why you posted that link here, but I added a correction there. <old>unmatched-paren: Who's working on guile-steel? First time I've heard of it <jpoiret>well, I'm out of my depth on this djeis civodul <jpoiret>I was isolating a more minimal case with subversion being built either with or without texlive-bin, but testing some other things made it match again <jpoiret>although the same behaviour still happens with resp. password-store and texlive-bin <GNUtoo>hi, could someone mark bug #57931 to have the "patch" marker in issues.guix.gnu.org ? <GNUtoo>I sent patches there, some of which were ready some not yet, and they were independently made by someone else <GNUtoo>So while it's nice that fixes got in, it also produce duplication of work which isn't ideal <GNUtoo>I'll try to rebase and see which patches are not necessary anymore