IRC channel logs


back to list of logs

<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. crates-io.scm: you modify it manually
<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)
<TopExpert>nevermind I misunderstood the question
*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/ 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>unmatched-paren: which part doesn't work?
<unmatched-paren>singpolyma: The GPU just straight-up refuses to start
<unmatched-paren>it requires evvul i915-firmware package
<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
<unmatched-paren>when you try to use anything beyond tty
<unmatched-paren>> Failed to initialize GPU, declaring it wedged!
*unmatched-paren away
<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>jab: sometimes. My main desktop is all AMD
<singpolyma>lechner: it's so reviewers can apply the patches using git also
<jab>singpolyma: ok.
<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
<lechner>singpolyma: thanks!
<lechner>Hi, is there a reason why an input may be listed twice?
<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 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>Just wanted your opinion.
<nckhexen>singpolyma: ‘desktop operation’ as in GNOME fancyswooshies? That's already something.
<singpolyma>nckhexen: I have a discrete amd
<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
<johnabs[m]>But I found it
<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]>boot, not boto
<nckhexen>podiki[m]: Oh deer.
<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
<nckhexen>This was 1.3.0?
<nckhexen>Or newer?
<nckhexen>(Or older?)
<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
<johnabs[m]>So i'm giving it a shot with guix env
<johnabs[m]>just to see if I can get it to run or something
<podiki[m]>so I would be more hopeful with an upcoming 1.4.0
<nckhexen>johnabs[m]: There's also this, but it's still a patch that needs to be applied manually, meaning you have to have a basic Guix development checkout goin' on already:
<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]>podiki: It's got 2 parts
<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.
<lechner>nckhexen: thanks!
<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
<lechner>sorry, dash
<nckhexen>I thought the manual had such an example, but maybe I'm mistaken.
<nckhexen>If it doesn't, it comes very close.
<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
<nckhexen>It's unique to them, no?
<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
<old>sneek: later tell pkill9: Here's a draft of guile-sourcehut if you want to play with it
<sneek>Got it.
<johnabs[m]>Does anybody here use pass-tomb per chance?
<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>brendyn: i would ask on #emacs
<lechner>Hi, why would this not find version 2.3, please? guix import go
<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.
<unmatched-paren>lechner: maybe the tag is called "v2
<unmatched-paren>"v2.3", not "2.3"?
<lechner>unmatched-paren: thanks! i tried that but guix import: error: version v2.3 of 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>Does it parse the HTML?
<lechner>Hi, can we validate upstream's tarball signatures?
<lechner>FlaminWalrus: Can you share the "very basic program"?
<FlaminWalrus>lechner: one file, three functions, one (sugar) type:
<FlaminWalrus>I'm about to try and test it in a container
<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.
<unmatched-paren>Oh, cool, looks like Rust was updated to 1.61?
<antipode>However, the PGP fingerprint isn't validated yet.
<unmatched-paren>AAAA and now they've released 1.64 :)
<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_>FlaminWalrus: "wget; guix shell ghc@8.10.7 ghc-split ghc-safe gcc-toolchain --pure --container -- runghc 1256441" -> "openFile: does not exist" seems to be 'working' here
<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 ; notice, at the top of the page: "The highest tagged major version is v2.". And indeed, "guix import go" finds different versions, alas, not 2.3 (for reasons I do not know, it is not present on
<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?
<unmatched-paren>Kabouik: Absolutely.
<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.
<unmatched-paren>so, what you want to do is amend the first commit?
<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>Sure you can.
<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
<unmatched-paren>not if you move the third commit's line below the first commit's
<unmatched-paren>you can rearrange the commits
<Kabouik>How I can literally move lines in rebase -i?
<unmatched-paren>see that website
<unmatched-paren>it's a nice wee guide to git rebasing and amending
<unmatched-paren>like is for ``git send-email''
<Kabouik>My reference now is your little for git send-email. :>
<Kabouik>Short and simple
<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>it doesn't matter
<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
<unmatched-paren>otherwise it might be called ``download.tar.gz'' or something
<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"
<unmatched-paren>Kabouik: "Terminal-based bibliography management tool"?
<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?
<unmatched-paren>hnhx[m]: you want to install it with ``guix install'', right?
<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
<unmatched-paren>ah, you haven't written a package before?
<hnhx[m]>no :x
<Kabouik>You may want to check `guix show dwm`
<unmatched-paren>Kabouik: you mean ``guix edit dwm''?
<Kabouik>Erm, I meant `guix edit 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>zpiro: oh, interesting.
<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".
<unmatched-paren>hnhx[m]: since you're writing two packages, you'll need two sexps
<unmatched-paren>sorry, two files
<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
<unmatched-paren>well, i kind of meant graphical terminal apps in general
<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.
<unmatched-paren>Kabouik: also, change latex-to-unicode to LaTeX-to-Unicode
<unmatched-paren>and vice versa
<lechner>antipode: re upstream signatures, don't we have to specify the public key somewhere? i only have one for tthe tarball btw
<unmatched-paren>hnhx[m]: now, presumably you're adding a patch to your dwm/st?
<antipode>It's automatic.
<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.
<hnhx[m]>unmatched-paren: not only a patch
<hnhx[m]>i changed config.h
<hnhx[m]>and other stuff
<unmatched-paren>hnhx[m]: so, you'll need both patches and substitute* build phases
<unmatched-paren>are you following so far?
<lechner>itd_ antipode: thanks for hints regarding the imported. as for, 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.
<hnhx[m]>ye ig
<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>hnhx[m]: <- should look like this so far
<unmatched-paren>next, you'll need to set the ``source'' of the package to an ``origin'' record that inherits from ``(package-source dwm''
<unmatched-paren>argh, missing close paren there :)
<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>and then add your patch to the origin's ``patches'', which i think should look like this:
<xd1le>hi guix
<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
<unmatched-paren>xd1le: hello!
<hnhx[m]>cant i give it the path of my build and tell it to run make?
<unmatched-paren>hnhx[m]: what do you mean?
<unmatched-paren>that's what the original package does
<unmatched-paren>with its gnu-build-system
<unmatched-paren>we are inheriting from it and adding some patches, basically
<unmatched-paren>so, next you'll want to make your config.h changes:
<zpiro>unmatched-paren: just to enforce this rant, "if you can boot the computer through a terminal to it, is is a consol".
<hnhx[m]>unmatched-paren: oh okay
<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>hnhx[m]: this is how you can edit config.h:
<unmatched-paren>the comments should hopefully explain things; don't forget to import (guix gexp)
<hnhx[m]>oh god
<hnhx[m]>cant i just give it the config.h file that i made myself?
<unmatched-paren>don't worry, it's not as bad as it looks
<unmatched-paren>arguments takes a list of properties that control the builhd
<unmatched-paren>like this: (list #:tests? #t #:phases #~(...))
<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>we need to use substitute-keyword-arguments to edit the list
<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>because the phase lambdas are actually passed the 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>but i just realized there was a better way to do this /o\
<unmatched-paren>with snippets to directly modify the source :)
<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
<unmatched-paren>antipode: okay, cool
<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
<unmatched-paren>and use that instead of a code snippet
<hnhx[m]>oh true
<hnhx[m]>thats a good idea
<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
<unmatched-paren>that would be a little convoluted for just a few patches, no?
<unmatched-paren>it's far better to learn to inherit and add patches
<unmatched-paren>also, inheriting is shorter than copying
<unmatched-paren>you don't have to duplicate anything
<hnhx[m]>unmatched-paren: i dont ever plan on using the vanilla version of dwm so it would be fine ig
<unmatched-paren>you'd still be able to use the vanilla dwm regardless
<unmatched-paren>it's just far better and easier to inherit
<hnhx[m]>ye probably
<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
<unmatched-paren>it's just not the default
<kraai>Is there a way to use `go-1.19` to build the package?
<unmatched-paren>i think you can just add #:go go-1.19 to the arguments...
<kraai>Great! I'll try that now.
<kraai>It fails with `In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): go-1.19`.
<unmatched-paren>That's very odd.
<unmatched-paren>kraai: Hmm, are you doing '(#:go go-1.19)?
<unmatched-paren>In that case, you're binding it to a symbol.
<unmatched-paren>Do `(#:go ,go-1.19).
<hnhx[m]>@unmatched-paren... (full message at <>)
<unmatched-paren>Or, better, (list #:go go-1.19).
<unmatched-paren>Ugh, matrix message truncation...
<kraai>That seems to work better.
<unmatched-paren>hnhx[m]: no
<unmatched-paren>not very well, at least
<kraai>unmatched-paren: Thanks!
<nckhexen>There are some weird things going on in that code snippet.
*nckhexen waves hullo.
<unmatched-paren>nckhexen: yeah, like (lambda* (#:allow-other-keys) ...)...
<unmatched-paren>which is effectively equivalent to (lambda _ ...), hnhx[m]
<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>just use patches and a snippet as i showed earlier
<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?
<unmatched-paren>kraai: if possible, package them separately
<unmatched-paren>if they're modified versions of something, then don't bother
<hnhx[m]><unmatched-paren> "just use patches and a snippet..." <- i think i will just give up and use vanilla dwm
<unmatched-paren>Aww. Don't give up :)
<unmatched-paren>what exactly is confusing you with my recommendation?
<hnhx[m]>the config.h part mainly
<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
<unmatched-paren>and allows you to install them of course
<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
<unmatched-paren>hnhx[m]: you can run make and stuff, can't you?
<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]>okay i understand now
<hnhx[m]>i can run make yes but it wont compile
<hnhx[m]>thanks it worked
<hnhx[m]>i had to change my Makefile though
<hnhx[m]>it seems like the cc symlink doesnt exist, not even in that environment thing
<unmatched-paren>you'll want to run ``make CC=gcc ...''
<hnhx[m]>ye that works
<hnhx[m]>thanks again
<unmatched-paren>Hmm, anyone able to run OpenTTD with SDL2 on Wayland?
<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>Ah, our SDL2 isn't built with Wayland support.
*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!
<sneek>dthompson, ArneBab says: Wisp update: Chickadee support ☺ (with a full example and the screencast of live-hacking in the chickadee-REPL using wisp) — thank you again!
<dthompson>oh boy, those are messages from #guile.
<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.
<unmatched-paren>Hmm, okay.
<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
<unmatched-paren>I see.
<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.
<unmatched-paren>Hmm... so now openttd is "unable to open a console terminal".
<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>it's good
<dthompson>that's what I hear
<unmatched-paren>very easy to use, you just run the compositor program, there's no "Wayland server" like there is the "Xorg server"
<dthompson>yeah that's nice
<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.
<unmatched-paren>ArneBab: No.
<dthompson>oh sure, like everything.
<unmatched-paren>ArneBab: An "EXWL" would probably need to be partly written in C.
<unmatched-paren>It'd be awesome though. :)
<hnhx[m]>> <> @unmatched-paren... (full message at <>)
<unmatched-paren>hnhx[m]: don't use that example
<unmatched-paren>it's not a good one
<hnhx[m]>i want to use my config.h instead of adding everything from config.h to the scm file
<unmatched-paren>that's not what that example does
<unmatched-paren>the "add config.h here" won't actually do anything
<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*
<unmatched-paren>that's exactly what you're doing
<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 .-.
<hnhx[m]>* get this to work for
<unmatched-paren>hnhx[m]: The thing is, this *is* a brand new package
*hnhx[m] sent a code block:
<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>(define-public) doesn't return anything
<unmatched-paren>you need to either remove (define-public) or add ``my-dwm'' below the form to return it from the file
<unmatched-paren>also, you can do something like:
<hnhx[m]>unmatched-paren: oh it worked
<unmatched-paren>it's possible to make that much shorter
<unmatched-paren>oops, remember to add the return value at the bottom there.
<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]>ah nvm still doesnt compile
<unmatched-paren>hnhx[m]: hmm. try using the inherited version
<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
<unmatched-paren>try opening the log and seeing what it says
<hnhx[m]>build log is a bunch of gibberish lol
*hnhx[m] sent a code block:
<hnhx[m]> * ye, i dont really understand either
<unmatched-paren>you using the version you sent or the version i sent?
<unmatched-paren>i wonder if you're missing some phase or flag or something
<hnhx[m]>i will try the one you sent now
<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]><unmatched-paren> "" <- > hint: Did you forget `(use-modules (gnu packages suckless))'?
<hnhx[m]>and after i add it
<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>i forgot to do the returning the package thing
<hnhx[m]>how do i do the return thing?
<unmatched-paren>just make the package object the last form in the file
<unmatched-paren>by adding the variable name to the end
<ArneBab>unmatched-paren: wayland devs chose that architecture, breaking all the low-maintenance things that bring lots of value. Updating a system should not break existing tools. They are making everything volatile by making the core architecture volatile. Which should be avoided ⇒
<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
<unmatched-paren>which means it implements windowing and only windowing
<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! :)
<hnhx[m]>time for st now
<hnhx[m]>okay st worked too 🙏
<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...
<unmatched-paren>Should that be added to the default kernel options?
<hnhx[m]><unmatched-paren> "Should that be added to the..." <- do you mean the kernel boot params?
<unmatched-paren>hnhx[m]: no, no, the options we compile our linux-libre with
<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>there's a much better way in guix to do that:
*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?
<unmatched-paren>12th gen Alder Lake Intel CPU
<hnhx[m]>ah nice
<unmatched-paren>Sadly, the integrated GPU requires a non-libre linux
<hnhx[m]>I have a T7200 in my T60 :p
<hnhx[m]>compiling a heavly debloated kernel took like an hour :p
<hnhx[m]>unmatched-paren: what about nomodeset? have you tried that already?
<unmatched-paren>hnhx[m]: i can't use that because wayland requires KMS
<hnhx[m]>use just xorg then
<unmatched-paren>i just use a blobby kernel
<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 no Go files in /tmp/... for one of the included source packages, please?
<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?
*unmatched-paren hnhx[m]
<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
<unmatched-paren>sorry, i meant to /msg
<djeis>Anyone have suggestions for where I should look to resolve this?
<unmatched-paren>djeis: just a guess, but maybe grafting weirdness?
<unmatched-paren>emacs-password-store shouldn't even be propagating password-store
<unmatched-paren>the invocations should be patched to refer directly to the store path
<unmatched-paren>this is one of the reasons we avoid propagation :)
<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
<unmatched-paren>branch, i mean
<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>should be straightforward
<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!.
<unmatched-paren>TopExpert: i don't believe so. Why?
<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
<unmatched-paren>TopExpert: Guix always passes CC=gcc to configure
<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.
<djeis>Different path, rather.
<TopExpert>unmatched-paren: oh yeah thanks
<unmatched-paren>Not sure if clang-for-target is a thing that exists though.
<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.
<unmatched-paren>Perhaps pass is unreproducible?
<unmatched-paren>Seems unlikely, it's just a shell script.
<djeis>Yeah but that wouldn't impact the store location, would it?
<unmatched-paren>yes it would
<unmatched-paren>i think?
<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.
<unmatched-paren>Hmm, okay.
<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>Earlier this morning, even.
<unmatched-paren>...aaand now gpg doesn't want to sign my git commit. Wonderful.
<unmatched-paren>I took a good few minutes typing out that commit message >:(
<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>Oh, hmm... idea...
<djeis>Ha! haha! Now that is Very Strange.
<unmatched-paren>Okay, fixed it.
<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.
<unmatched-paren>native-comp is in mainline guix's emacs-build-system now, i believe
<unmatched-paren>(thanks to lilyp :))
<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?
<unmatched-paren>djeis: <- here you go :)
<unmatched-paren>djeis: almost certainly not
<lilyp>unmatched-paren: nice one
<lilyp>djeis: get your friend, the rubber duck
<unmatched-paren>eh? :)
<lilyp>"parasite to undermine guix"
<unmatched-paren>no, I meant "get your friend, the rubber duck"; what's that mean?
<unmatched-paren>(Sorry if you just heard a very loud wooshing sound.)
<lilyp>rubber duck debugging
*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?
<unmatched-paren>TopExpert: There is not.
<TopExpert>gcc seems to add other things like C_INCLUDE_PATH
<unmatched-paren>Again, try looking at Clang-only things like ungoogled-chromium.
<TopExpert>what I build still seems to pick up gcc for some reason, maybe I apply setenv too late
<TopExpert>thanks I didn't know
<unmatched-paren>gnucode: hi!
<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
<unmatched-paren>lilyp: No, no, I mean like this:
<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.
<unmatched-paren>lilyp: this is what i meant: <- do you think implementing something like that would be plausible?
<unmatched-paren>it would be *incredibly* useful
<djeis>But yeah, I have 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.
<djeis>Shouldn't those match up?
<lilyp>unmatched-paren: you could do something with a little guile-git foo
<unmatched-paren>lilyp: yeah, i thought as much
<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
<unmatched-paren>hang on, what do you mean "better handled as part of CI"?
<unmatched-paren>i don't really understand how this would relate to CI...
<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>maybe it would be better like this:
<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
<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?
<unmatched-paren>I vaguely remember someone mentioning it in this channel.
<pkill9>I think it was a desired feature
<unmatched-paren>I can't remember how, I'm afraid.
<pkill9>dunno if it's been implemented
<Kabouik>That'd be useful I believe, but perhaps a lot of work
<unmatched-paren>Might be misremembering it...
<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!
<sneek>Will do.
<unmatched-paren>sneek: Botsnack!
<djeis>, it's not even guix home, it's... fontconfig, maybe?
<unmatched-paren>Hahahha what.
<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.
<unmatched-paren>rg fontconfig (guix build password-store) returns nothing.
<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 :-(
<old>sneek: bad bot
<pkill9>I got a message from you
<jpoiret>@djei: What do you mean you have a different path to the pass binary?
<old>Oh. Was it private?
<jpoiret>djeis *
<pkill9>it might have been in one of the other channels
<pkill9>but i replied to it
<pkill9>i can't remember what it was about
<old>ahh okay
<old>sneek: botsnack
<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>i get the same with guix build too
<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>I also see the discrepancy when I use guix home build with and look at the profile's bin folder.
<djeis>And I've now reproduced it on a second machine and on a time-machine build from guix master.
<djeis>In (channels list is just the guix channel, that config is the one I linked above) both paths have changed, but the discrepancy remains.
<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).
<nckhexen>It? She? I dunno.
<nckhexen>sneek: botsnack.
<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.
<jpoiret>extremely weird
<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>otherwise they look the same
<jpoiret>oh no
<jpoiret>i think i know what's going on
<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
<unmatched-paren>old: i believe so
<civodul>jpoiret: weird!
<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
<podiki[m]>grafts....brings me back to that I still want to go back to figure out what is happening as well
<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>jgart: Some people are.
<jgart[m]>Currently binaries are required for a basic build:
<antipode>There were some questions on crystal packaging in the ML, IIRC
<jgart[m]>I sent a motivation package a while back:
<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
<jgart[m]>they are not interested
<antipode>‘I talked to unknown the other day ...’: is this meant literally or as a joke (or both)? I can't tell.
<jgart[m]>not sure
<jgart[m]>Maybe both
<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]>Or atleast that would be the goal
<jgart[m]>unmatched-paren: Can you add support for worktrees also while you're at it?
<jgart[m]>That would be nice
<jgart[m]>Or maybe I should do that if I want 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
<unmatched-paren>well, it seems like the last commit was over a year ago...
<unmatched-paren>which might be cause for concern?
<jgart[m]>orangeshark is MIA for a while
<unmatched-paren>'specially since the open MRs have largely gone unnoticed.
<jgart[m]>I'd like to reach out to him at some point
<jgart[m]>He's actually from my hometown
<jgart[m]>small world
<jgart[m]>some random suburb that know one knows about too
<jgart[m]>unmatched-paren: It's like the Huddersfield of the US
<jgart[m]>but probably more obscure
<unmatched-paren>Maybe, given guile-git's status, it would be better to put the ``apply'' and ``buffer->diff'' functions in (guix git)?
<unmatched-paren>s/functions/procedures/, come on (, get it right.
<jgart[m]>I would just send a patch first to orangeshark
<jgart[m]>Looks like upstream in Guix is
<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
<jgart[m]>good for guile
<civodul>jgart[m]: on 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]>But LibreMiami is defunct now
<jgart[m]>That was before OrangeShark started at MS
<jgart[m]>MS took our Guiler 😭
<singpolyma>jgart[m]: you mean your guiler is gonna help drain MS' money ;)
<singpolyma>A noble pursuit
<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 ;()
<unmatched-paren>ric342[m]: Guix isn't an acronym ;)
<unmatched-paren>GUIX is some Microsoft embeddded GUI thing.
<ric342[m]>Oops haha
<jgart[m]>Guix Uninterestingly Is Xorg
<unmatched-paren>ric342[m]: It's an oddly common misspelling.
<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
<unmatched-paren>Guile + Nix
<jgart[m]>ric342: try understanding what gexps are supposed to mean
<jgart[m]>that'll be a harder nut to crack
<unmatched-paren>Gu(uile, N)ix
<ric342[m]>guile expressions?
<antipode>ric342: I don't think Guix is really meant to mean anything
<jgart[m]>ya Guix is Nix for Guile
<jgart[m]>it says it in the module docstring
<ric342[m]>Oh okay that makes sense
<antipode>(beyond being some unique name)
<jgart[m]>unmatched-paren: ric342 antipode civodul: said it was "Nix package management from Guile."
<unmatched-paren>jgart[m]: I believe it actually was originally just a Guile program to talk to the Nix daemon
<jgart[m]>but that's so two thousand and twelve
<jgart[m]>unmatched-paren: it still is a guile program that talks to the Nix daemon
<jgart[m]>that hasn't changed
<jgart[m]>Guile <3 Nix
<jgart[m]>Guile <3 Nix daemon
<ric342[m]>Is a scheme rewrite of nix daemon still in the works?
<unmatched-paren>Eh, the Guix daemon is not the Nix daewon.
<unmatched-paren>nixd has probably significantly diverged from guixd at that point
<jgart[m]>ric342: If it ain't broke don't fix it
<jgart[m]>It's was the Nix daemon
<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
<unmatched-paren>C++ is not a pleasant language by any stretch of the imagination.
<jgart[m]>That's what racket devs thought
<jgart[m]>And why they started using chez scheme
<jgart[m]>to replace the C bits
<jgart[m]>no pun
<ric342[m]>Heh will be so lispy
<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?
<unmatched-paren>guile-steel doesn't exist yet...
<jgart[m]>Nix daemon in guile-steel doesn't exist yet either
<jgart[m]>But we can dream the dream
<jgart[m]>And start planning it out
<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 ?
<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