IRC channel logs

2023-11-11.log

back to list of logs

<Kabouik>Any idea what could be the issue with the test phase at the end here? https://0x0.st/HtRM.txt The package definition is here: https://0x0.st/HtRu.txt
<Kabouik>I think this would be a really nice addition to Guix, as it supports both Telegram and Whatsapp, and there's never enough TUI alternatives to such heavy apps.
<Andronikos>Does it have no tests?
<Kabouik>I admit I don't know that
<Andronikos>In that case, add #:tests #f in arguments
<Kabouik>But I think packages with tests disabled usually don't get into the Guix channel. How can I test if the program normally has tests?
<Andronikos>Ah it has tests. Look at the make.sh file
<Kabouik>For another program made by the same developer, I have https://0x0.st/HtR1.txt in the package definition. I don't understand it, but since the program is in the same language, maybe I can try that and hope that the dev used the same tests.
<Andronikos>I honestly don't know either. I am new as well. But it looks like at least to me the right way. Replacing the phase and instead execute that script with the test argument.
<Andronikos>I think you can skip the tests to be honest. It seems that it is not implemented. It just looks up if TESTS env is set to 1 and returns true.
<Kabouik>I see. Could you please show me how exactly I should modify the packge definition to add #:tests #f? I'm not sure where/how to nest that in the arguments exactly.
<Andronikos> https://paste.debian.net/1297826/ see in arguments. Try if it builds now
<peanuts>"debian Pastezone" https://paste.debian.net/1297826
<Andronikos>(btw, this is the old syntax definition you are using)
<Kabouik>Thanks! Oh. Mmh.
<Kabouik>Where can I see what changed in the new syntax?
<Andronikos> https://guix.gnu.org/en/manual/devel/en/guix.html#package-Reference scroll down to propagted inputs. Basically it is now a cleaner syntax. You can use guix style which should convert your file automatically.
<peanuts>"GNU Guix Reference Manual" https://guix.gnu.org/en/manual/devel/en/guix.html#package-Reference
<Kabouik>This is what I got after guix style -f nchat.scm: https://0x0.st/HtRL.txt
<Andronikos>Hmm. Which version of Guix are you using? Maybe you are still on a version that doesn't use the new syntax.
<Kabouik>I probably just misused guix style, no? Maybe I need to tell it I want --styling=inputs
<Andronikos>Yeah I think thats it. Thought it works out of the box to be honest.
<Andronikos>Ah here it says. The default is formatting. Do with arguments as well and you should be good to go
<Kabouik>Weirdly, guix style --styling=inptus nchat returns "guix style: error: mkstemp: Read-only file system". I could use it first with -f nchat.scm, but -f and --styling are incompatible.
<Andronikos>Ah yeah. Having same issue
<Andronikos>Is nmchat.scm in your own channel or where is that stored?
<Andronikos>Hmm. Don't actually know why that permission error comes.
<Andronikos>Ah. I think you need to specifiy which package it should rewrite the inputs. It now thinks you want to edit Guix itself.
<mwette>I think issue is that my channel repo is not signed. But I gpg with a yubkey. Is there something I have to add to get gpg-agent to recognize the yubkey in the USB ?
<mwette>s/yubkey/yubikey/
<Andronikos>Kabouik: do again but -S inputs nchat. You want only the inputs of nchat to be converted.
<Kabouik>First things first: it did install nicely without the tests Andronikos, thanks a lot!
<Kabouik>And yeah, it's in my private channel. I get the same error with `guix style -S inputs nchat`.
<Kabouik>Perhaps it doesn't work with private channels, but I find it weird since I guix pulled already.
<Andronikos>Kabouik: You need to add -L ~/path/to/your/channel
<Kabouik>Heh, that was it. Does it look better to you? https://0x0.st/HtRW.txt
<Andronikos>Perfect. Now run it again but instead of inputs use arguments
<Kabouik>Nice. Here: https://0x0.st/HtR4.txt
<Andronikos>As a beginner it looks good to me. Now it only needs to work
<Kabouik>The package does work, but I'll make sure it still does after the styling.
<Andronikos>Ah, well in that case you are done.
<Kabouik>Still need to submit the patch too. But it's great that it works, telegram-desktop was such a CPU hog on my machine
<Andronikos>If you want to make a patch for upstream anyways, you should edit the Guix repository directly. This makes it easier to integreate the patch. You may want to read https://guix.gnu.org/en/manual/devel/en/guix.html#Contributing
<peanuts>"GNU Guix Reference Manual" https://guix.gnu.org/en/manual/devel/en/guix.html#Contributing
<ekaitz>i guess it's ok to add myself to a Guix team right?
<Kabouik>I submitted a few patches when I first started using Guix, some of which got merged, but the most important was nmail and it was not merged. nchat is from the same dev, so once I get rid of my laziness I'll update my nmail patch and submit nchat at the same time.
<Kabouik>I ended up adding nmail in a private channel because I needed it in my daily workflow and couldn't wait.
<singpolyma>Kabouik: guixrus is a good high velocity channel for submitting stuff like that
<Andronikos>That channel feature is really nice. Just like many other features Guix has to offer.
<Kabouik>Hum, somehow guix pull fails after the styling edits: https://0x0.st/HtRx.txt
<Andronikos>You need (use-modules (guix gexp))
<Andronikos>I meant #:use-module (guix gexp)
<Kabouik>I don't understand how guix pull works without it before the styling
<singpolyma>Probably weren't using any gexp syntax before
<Kabouik>Oh, it's used for the syntax. Makes sense then, thank.
<Andronikos>You need that because of the new syntax for the arguments field. Those #~ can be done only if that module is imported (G-Expression is it called)
<Andronikos>It should be the same hash and not even try to build
<Kabouik>Actually I have another silly question concerning the build phase that I am not sure how to build. The default cmake procedure takes >5GB of RAM to build, and will fail on any machine that has less available. There is a way to make it 1.5GB only if setting env variables before cmake to CC=/usr/bin/clang CXX=/usr/bin/clang++. How would I do that in Guix? This would be a better default than the faster build that fails on some machines.
<Kabouik>But I guess hardcoding paths to clang and clang++ is not a good idea in Guix, and would I need new inputs?
<singpolyma>Generally those paths won't exist in guix
<Kabouik>Yeah
<singpolyma>What is it you're doing that trkes the 5GB?
<Kabouik>See the first paragraph here: https://github.com/d99kris/nchat/blob/master/LOWMEMORY.md
<peanuts>"nchat/LOWMEMORY.md at master ? d99kris/nchat ? GitHub" https://github.com/d99kris/nchat/blob/master/LOWMEMORY.md
<singpolyma>Oh I see
<singpolyma>Something odd about nchat build process
<singpolyma>You can use substitute* to put in the paths to where those things actually are
<singpolyma>Or gust set the env vars I guess it all you need
<singpolyma>Use (which clang) or similar
<Kabouik>Okay, thanks. I don't know how to script that in Scheme butt I'll do some trials and errors
<Kabouik>I'm weak, I used ChatGPT to get this: https://0x0.st/HtRU.txt But still not sure about these hardcodd /bin/clang and /bin/clang++.
<singpolyma>Any hardcoded paths like that have to be replaced when packaging for guix
<Kabouik>So I could remove the whle (let ...) and just use (setenv "CC" (which clang)), if I added llvm in inputs?
<singpolyma>Unless you mean (string-append something "/bin/clang")
<Kabouik>Yes
<singpolyma>That's fine assuming the something is correct
<singpolyma>Findieg manually in the right input is more correct usually than being lazy and using (which clang)
<Kabouik>Alright. Let's try then. Sorry for asking here before, but the build is quite long so even if I'm happy to do trials and errors, any obvious error is always good to skip.
<singpolyma>But either approach can work in many cases
<Kabouik>I think the CC env var works but CXX fails because clang++ is nowhere to be found.
<Kabouik>The script does set its path to /gnu/store/blahblah-llvm-13.0.1/bin/clang++, but it is not there.
<Kabouik>s/script/package definition
<singpolyma>There might be a clang++ package or something?
<Kabouik>I could not find one singpolyma
<Kabouik>There's a clang package but no clang++. Unless the package clang-toolchain provides both, maybe?
<saravia>Hi question, we have a version of guix wich work with 160MB of ram or some for that?
<saravia>^ with X included?
<roptat>hi guix!
<roptat>saravia, I'd say no, guix itself needs a lot of RAM already
<roptat>doable if you exclude guix itself I'd say
<saravia>roptat: and dbus are in your repository?
<saravia>roptat: for example if I have a not dbus distro, adding guix, I'll install dbus functionality?
<saravia>beacose if I'll install dbus and pulseaudio <-- maybe with that is posible go near to 160MB of ram but with guix like a VENNON package respository
<saravia>^ I say vennon for the movie xD!! : P guix package repository make me thnink in some similar to vennon fiction sciens
<Kabouik>Is there a package providing clang++? I need to use it as a compiler for a package definition, and tried to add clang-toolchain and set CXX env var in the.scm, but it fails with this: https://0x0.st/Ht7R.txt
<lilyp>clang itself already provides clang++
<roptat>saravia, I don't know vennon. Many packages indeed depend on pulseaudio and dbus
<lilyp>same with gcc
<Kabouik>Thanks lilyp, then there is something wrong in the arguments I tried in my package definition when I was just adding llvm as input
<Kabouik>Maybe that was my mistake actually, adding llvm instead of clang as input
<lilyp>yep, you shouldn't need more than clang (and perhaps lld)
<Kabouik>The package is building (not over yet) when I just put clang instead of llvm, but I am not sure yet if the CC and CXX env vars were properly taken into account. Here's the package: https://0x0.st/Ht7h.scm
<roptat>Kabouik, if it's building, it didn't take your env vars into account, they point to an inexistant binary
<roptat>clang and clang++ are in clang, not in llvm
<roptat>also, you can probably specify (setenv "CC" "clang") instead of the full path
<Kabouik>I actually pasted the wrong version of the package, my bad. But I'll try what you said, sounds simpler.
<Kabouik>Does that mean I could just removes lines 51-52 and only keep the three setenv after the lambda line?
<Kabouik>To clarify, I pasted the wrong package version above. The one that's building is https://0x0.st/Ht7F.scm and I think the clang full paths should be correct in that one
<roptat>Kabouik, yes
<bumble>hey guix hope all is well these days
<Franciman>hi!
<Franciman>i'm about to get started with guix system
<bumble>you will love it
<bumble>well, you won't love it if you are a CJK user because you will encounter this issue https://issues.guix.gnu.org/65546#3
<peanuts>"[PATCH] guix: Properly compute progress bar width." https://issues.guix.gnu.org/65546#3
<Franciman>lol
<bumble>I wish that patch would be applied...
<Franciman>are you a cjk user?
<bumble>yes
<Franciman>auch, hope it gets fixed soon!
<Franciman>i was a bit worried about icecat :P
<bumble>have not tried icecat... this system uses qutebrowser
<roptat>somehow I had missed all those emails before
<Franciman>oh ok, nice
<bumble>qutebrowser is great because you can use scripts like this one there, which aren't available for firefox https://greasyfork.org/ja/scripts/459541-youtube%E5%8E%BB%E5%B9%BF%E5%91%8A-youtube-ad-blocker
<peanuts>"YouTube??? YouTube AD Blocker" https://greasyfork.org/ja/scripts/459541-youtube%E5%8E%BB%E5%B9%BF%E5%91%8A-youtube-ad-blocker
<bumble>this scripts blocks youtube ads so that youtube is restored to its early 2000s goodness
<Franciman>awesome
<futurile>Franciman: have you used Guix at all previously, or you jumping right in to using the full thing?
<Franciman>i tried it some years ago
<Franciman>now i have a machine i can fully dedicate to it
<Franciman>so i'm going to test it on that side machine
<futurile>ah - interesting - so what made your 'go away' and what 'got you back' - o rjust the machien available?
<Franciman>go away the usual non-free firmware issues |: and the browser was very limited, i could not even watch youtube videos
<Franciman>and the slowness of some guix commands, especially guix pull
<Franciman>go back: guix's ideas! i loved them all along
<futurile>Franciman: uhuh and you're aware of the 'other' channels that we don't discus here?
<Franciman>oh yes, i do, but i had severely propertary laptops :P
<Franciman>now i have something more reasonable
<futurile>ack - firmware - <shudder>
<Franciman>can't wait to try guix system again!
<futurile>cool - be interesting how the experience has changed in the last few years
<Franciman>another thing i couldn't deal with [because of my inexpertise, to be honest] was that i use kakoune as my main text editor and wanted to have parinfer-rust for editing scheme. I was not able to package it, because i had to package all the single rust dependencies it had
<Franciman>so it was a rabbit hole thing i couldn't manage to get to the bottom of
<Franciman>now i see that parinfer-rust is already packaged :D
<roptat>bumble, it's applied now :)
<bumble>wonderful! oh that is great news
<futurile>Franciman: yeah I've run into that, for me - I missed Spotify a lot - and so landed up packaging SpotifyD which was about 60 Rust crates when I started - hilariously annoying.
<futurile>Franciman: one thing to be aware of is `guix shell` with the FHS option - as then you can run binaries compiled for 'normal' Linux in Guix - it's a way to get around having to package things immediately
<futurile>Franciman: just makes transitioning that much easier really
<Franciman>thanks for the spotifyd tip, i was not aware of it, looks awesome. Oh great
<Kabouik>roptat I edited the package definition to only use (setenv "CC" "clang") (setenv "CXX" "clang++") and the build proceeeds, but I don't think the env var are taken into account because it still uses 5GB of RAM instead of the 1.5 it should use if that was working. Also, its says here (https://0x0.st/Hthp.png) that the CXX compiler detection was skipped, why?
<roptat>Kabouik, looks like it found clang++, but not sure why it says "skipped"
<roptat>probably since you specified it, it skips checking it works?
<Kabouik>Hum, so maybe the skipped part is no issue. It still seems to consume more RAM than it should if it was using clang and clang++. I showed the package definition to the developer. He doesn't know Guix/Scheme but maybe will figure out what is wrong.
<Rovanion>My /boot/efi has a UUID of just 8 characters (D653-845A) according to lsblk but guix's `uuid` doesn't accept that. Any ideas?
<Rovanion>The manual mentions that uuids are used in the way they are shown by tune2fs, which doesn't work on fat filesystems.
<Rovanion>Looking at examples I find you can pass a special last argument `'fat` to `uuid` for it to accept fat uuids. Why not just have it accept both types by default?
<Franciman>ok I installed guix system! Working like a charm so far, just a question. guix pull and system reconfigure takes A LOT of time when computing the derivations
<Franciman>but A LOT of time on my laptop, which has an intel i5 4300M
<Franciman>is there something I am missing or it's expected that it takes quite a bit to compute them?
<Kabouik>It's very l.long for me too on an i7 11th generation, unfortunately.
<Franciman>okay, thanks! I'll have to get used to it then :)
<nutcase_>futurile: as promised, I wrote something down about Java @Guix. For most of you, the information available at https://github.com/nuthub/guix-shell-examples is probably nothing new. However, sometimes newbies like me find it difficult to find information on some issues in the web. Feel free to correct things, if they don't look good to you.
<peanuts>"GitHub - nuthub/guix-shell-examples" https://github.com/nuthub/guix-shell-examples
<theesm>What's the current status of harelang in guix? I've found two issues discussing adding it (#55606 and #64891) from earlier this year.
<peanuts>"[PATCH 2/2] gnu: Add hare." https://issues.guix.gnu.org/55606
<peanuts>"[PATCH] gnu: Add hare" https://issues.guix.gnu.org/64891
<roptat>theesm, no idea, but that last patch is probably the current state
<roptat>at least, there's no "hare" package in guix yet
<futurile>nutcase_: very cool. You've put quite a bit of work into this! Are you subscribed to guix-user? (you should send it there I think)
<futurile>nutcase_: maven_wrapper is new to me - that's a great tool
<voroskoi>Please help me with this: I send in my patches with git send-email, and I write the header part with compose
<voroskoi>the In-Reply-To and References fields are filled in properly
<voroskoi>but every patch opens a separate bug report in the bug trancker, which is not intended
<voroskoi>what should i check with my config?
<Andronikos> https://guix.gnu.org/en/manual/devel/en/guix.html#Single-Patches-1 a little bit down it explains how to send revised patches
<lilyp>voroskoi: send to NNNNN@debbugs.gnu.org instead of guix-patches
<peanuts>"GNU Guix Reference Manual" https://guix.gnu.org/en/manual/devel/en/guix.html#Single-Patches-1
<voroskoi>oh, so it is not my config, just debbugs can not handle this
<voroskoi>ok, i clean up the issue tracker, thanks
<lilyp>thankfully, messaging control@debbugs.gnu.org is as simple as getting the mail wrong :)
<Kabouik>Say I dd-ed my encrypted Guix system SSD to another (larger) SSD. How can I proceed to boot from it? My config.scm has the partitions mapped by their UUID (https://0x0.st/HtCZ.scm), which obviously are invalid for that disk. Can I decrypt it while plugged externally, chroot into it, edit UUIDs and then run guix system reconfigure?
<lilyp>assuming you nail that chroot, yes
<lilyp>alternatively, you could mount and init it, but you'll be losing your previous configs
<lilyp>(been there, done that)
<lilyp>(although actually that was a live reinit of a system that no longer booted for other reason)
<nutcase_>futurile: Well, I am. Maybe I will share the link there later.
<Kabouik>Alright, thanks lilyp. Though if the chroot part is a challenge, then I guess I'm going to fail. :> I'm not even sure how to decrypt it.
<ieure>If I'm sending patches to Guix which add packages, should I be sending one patch per package, or is it okay to combine multiple packages into one patch?
<lilyp>one patch per package please
<ieure>lilyp, Okay, can do, thank you
<ieure>Anyone else having issues with Emacs being unable to launch aspell because it can't find dictionaries?
<ieure>I'm getting: Error enabling Flyspell mode: (Error: No word lists can be found for the language "en_US".)
<ieure>I have aspell and aspell-dict-en installed via Guix Home.
<lilyp>I've got my flyspell set to use enchant, so I can't help ya there
<nutcase_>lilyp: can you briefly describe your enchant setup?
<voroskoi>how can I force guix build to rebuild the a package?
<lilyp>nutcase_: '(ispell-program-name "enchant-2")
<voroskoi>tried --check and --no-substitutes, but no luck
<lilyp>also install some dictionaries, e.g. aspell-dict-en
<lilyp>voroskoi: --check --no-grafts
<lilyp>however, this won't overwrite store items; use --repair if you need that
<nckx>Somebody recently asked about why we name Go packages so oddly, without response. I don't write Go but it does seem like, whatever was smoked, they truly went all Web-galaxy-brain: https://mastodon.social/@cks/111393138822542824
<peanuts>"Chris Siebenmann: "Today, if you publish a popular Go module on a UR?" - Mastodon" https://mastodon.social/@cks/111393138822542824
<ieure>nckx, The entire Go ecosystem is incredibly horked.
<ieure>It is a terrible language. Had a job programming it for 2.5 years, it was excruciating.
<lilyp>I mean, they only had the job of taking over Java's naming scheme and making it worse. What could happen?
<zamfofex>ieure: Perhaps this better fits #guix-offtopic, but what do you think was bad about the language itself? (Bar the tooling and package naming.)
<ieure>This is the funniest thing to me about Go. It's so clearly a reactionary anti-Java, yet they find themselves making the same mistakes as the thing they hate (like: not including generics from the get-go).
<nckx>I try not to judge it too much since I don't 'use' it (although I've played with it), but honestly if you look at something from the outside and all 5 angles look like shit, mayhaps the emperor isn't wearing anything after all.
<ieure>zamfofex, I'll PM.
<nckx>#guix-offtopic is cool for this just FYI. It's not exactly swamped.
<ieure>Ah, alright.
<ieure>I initially had an ignorant negative view of Go. After using it professionally, I have a learned negative view of Go.
<nckx>ieure: I'm not going to join into the discussion if it continues, but thanks for your informed perspective. At least it wasn't just me :-)
<Andronikos>If I add a new package, should the commit only be the package itself without the contents of the "guix-copyright" command?
<voroskoi>speaking of go: is there any particular reason to keep the default version on 1.17 or it is "just" a manpower issue?
<nckx>Andronikos: (Is this a new subcommand?) Copyright lines should be added or updated in the same commit as the first copyrightable changed.
<nckx>s/d\././
<Andronikos>nckx: Ah okay thanks. I created now a commit. Now I need to run "git send-email --annotate -1"?
<nckx>I think --annotate is my default for whatever reason, but looks right.
<Andronikos>--annotate is, if I want to add some text. For example if I have a question or something?
<ieure>Should Guix Home be setting GUIX_PROFILE to ~/.guix-home/profile? It looks like it isn't doing that, so my view of what I have installed is inconsisteny.
<ieure>*inconsistent
<nckx>(Yes, that's the purpose, but git send-email pops up an emacs here regardless.)
<ieure>Hmm, okay, maybe not? Running `export GUIX_PROFILE=~/.guix-home/profile' and `. $GUIX_PROFILE/etc/profile' and `hash' still isn't showing the packages configured in my home.scm.
<nckx>ieure: I don't use Guix Home so this is not authoritative, but GUIX_PROFILE should not be set in regular Guix operation.
<nckx>It's harmless though.
<ieure>I'm trying to square that with `guix pull` printing that I should set it most times I run it.
<nckx>It's optional when sourcing the profile.
<nckx>That doesn't mean it should be set when you open a terminal or whatever.
<ieure>Thoughts on my problem, though? `guix package -l` shows things I've manually installed with `guix install`, and nothing from my home profile.
<ieure>But things that are only configured in the home profile (like aspell) can be executed in my shell.
<nckx>ACTION has no thoughts.
<solene>hello, I'm trying to figure why my freshly installed guix has a 6.0.10-gnu kernel while a newer version exists in git linux.scm file... I tried to use "guix pull" to update, do I need to do something special to use the latest kernel available?
<solene>the computer has relatively new hardware, I'd like to see if it improves the gpu compatibility
<zamfofex>solene: Did you ‘sudo guix system reconfigure’?
<solene>zamfofex: I didn't do it, I followed https://guix.gnu.org/fr/manual/devel/en/html_node/Upgrading-Guix.html
<peanuts>"Upgrading Guix (GNU Guix Reference Manual)" https://guix.gnu.org/fr/manual/devel/en/html_node/Upgrading-Guix.html
<zamfofex>That will upgrade your ‘guix’ tool, which you can then use to upgrade your system.
<solene>make sense :)
<zamfofex>solene: See: https://guix.gnu.org/en/manual/devel/en/html_node/After-System-Installation.html
<peanuts>"After System Installation (GNU Guix Reference Manual)" https://guix.gnu.org/en/manual/devel/en/html_node/After-System-Installation.html
<voroskoi>ieure: this is the intended behaviour: Your home profile is separated from the "default" profile
<voroskoi>whenever You run guix home reconfigure it will install/remove what necessary
<ieure>voroskoi, I understand that it's separate. I don't understand a) Why Guix Home doesn't set my shell configs to use the Guix Home profile b) Why manually activating that profile fails to show the packages that Guix Home has installed.
<Andronikos>Since git email-send is used, I need also to define [sendemail] with my server credentials in the Git config?
<zamfofex>ieure: What do you mean by “doesn't set my shell configs to use the Guix Home profile”? If you mean “without having to close and reopen a terminal window”, it’s because it can’t modify your shell’s variables for you. That’s just not possible.
<ieure>zamfofex, I mean: I open a new shell (or log into the text console), and `GUIX_PROFILE` is not set, and `guix package -I` doesn't show any of the packages declared in my home config.
<zamfofex>‘guix package -I’ is meant to show packages managed by ‘guix package’. It is meant to be separate from ‘guix home’.
<nckx>solene: At the risk of pointing out what you might find obvious, run 'guix pull' before reconfiguring.
<Andronikos>ieure: Do you use the bash service from guix home? This sets your env for guix home or else you need to do it manually.
<ieure>Andronikos, I do.
<nckx>But it does not replace a 'reconfigure', it only updates the *available* packages.
<ieure>zamfofex, Okay, but, aren't all packages installed into a profile? And if I activate that profile and show installed packages, shouldn't it show what's installed there?
<nckx>Most package managers use a similar 2-step scheme. I don't know if the BSDs do (assuming you'r that solene).
<ieure>I guess... it does not work like that. That's surprising.
<Andronikos>You can by guix home describe -I see the installed packages.
<ieure>Okay, that works, but I'm still surprised by the behavior.
<nckx>There isn't really such a thing as 'the currently active profile' that things like 'guix package -I' magically picks up on, no.
<nckx>There is the default profile, which it shows by, er, default; and there are profiles you can source to activate them, but that's it.
<zamfofex>If you really want to use ‘guix package’ to look into your home’s profile, you can use: guix package -p ~/.guix-home/profile -I
<nckx>The this ^^
<ieure>Gotcha, okay.
<zamfofex>Otherwise, by default, it will look into ‘~/.guix-profile’ as far as I know.
<nckx>Yup.
<nckx>Andronikos: Sorry for the late answer but yes, configure your mail that way.
<Andronikos>nckx: I am new to this and needed some help. Maybe this could be added to the manual itself to make it easier for people like me? Also, I sent a patch about 10 minutes ago. The manual says that first time patches take a bit for acknowledgement. Does it take that long?
<Andronikos>Oh and git send-email gave me this question "Which 8bit encoding should I declare [UTF-8]? " and I pressed enter. Is that the expected way to do it?
<zamfofex>Yes.
<nckx>Andronikos: I'll check the queue.
<zamfofex>The value between backets is the default, in this case it’s sensible enough.
<nckx>Nothing yet.
<Andronikos>nckx: Ah good to know. I thought that is the case.
<nckx>But the moderation affects only the mailing list part (sending mail to all subscribers), not the tracker Web sites.
<nckx>I'll let you know if I approve anything tonight.
<Andronikos>nckx: Okay, thank you. Does that mean it is normal to take maybe a day? Since I would add this to the manual.
<Andronikos>git send-email had Result: 250, which means everything went fine? Since if it works I would work on updating the description of browserpass.
<nckx>Honestly, it's extremely variable, and there are multiple variables. For example, it can take several seconds to a day (rarely more) to even hit the moderation queue. Then you wait for a human (I try to review daily, sometimes more, seldom less). Then it should be instant, but who knows.
<nckx>Andronikos: Yes. 250 is the best 2xx.
<nckx>It means that GNU has received your mail gud.
<Andronikos>nckx: Something like (this could take up to a day) would be fine? (not going to do it now but in the future)
<nckx>Yes.
<nckx>Don't resend after 6 hours.
<Andronikos>Okay. Added it to the todo list
<nckx>It's not great but it's what we have.
<Andronikos>I personally think it is just important to let people be aware of it.
<Andronikos>If I make a new commit this is okay (for updating the description of browserpass)?
<nckx>Sounds like it.
<nckx><I personally think it is just important to let people be aware of it.> I agree in spirit, but the more paragraphs we add to the manual the fewer people read IME.
<nckx>We can lament this but it's fact.
<Andronikos>nckx: I see the problem. Took me 2 weeks to get it through (+ cookbook)
<Andronikos>but I learned tons of new stuff and better unstood how this machinery works.
<nutcase_>lilyp: you mean `(setq ispell-program-name "enchant-2")` (with setq) ? thanks, for sharing :-)
<Franciman>is there a way to see where the files of a package are located? (i installed alacritty but can't understand where the alacritty.yml example config file is installed)
<solene>zamfofex: after guix system reconfigure I have latest kernel, thanks :)
<solene>could someone confirm intel GPU can't be used for 3D? I'm trying on a 12th gen i7 with intel Xe gpu
<Xe>what
<Xe>it works fine
<zamfofex>Why would it not work?
<Xe>solene: trust me, it works
<Xe>install mesa
<zamfofex>There is no real reason for it to not work, I feel.
<Franciman>ah found, it was in /run/current/profile
<solene>oh, I would have expected mesa to be always intsalled as long as X was there
<solene>is guix mesa install enough, and then I restart gdm?
<solene>hmm, it's still using software rendering for some reasons
<lilyp>nutcase_: well, that's one way to read it, but i am actually using that as part of custom-set-variables
<solene>ah I see the issue, my device is llvmpipe (from glxinfo)
<Andronikos>error: qemu-guest-agent-service: unbound variable I import gnu services virtualization and still getting this error. What does it want from me?
<solene>hmm, I really don't understand how to get the GPU working.. Xe would you mind sharing your config so I could take a look and compare?
<Xe>I dont' use guix
<Xe>i just know that GPU should work on a decently modern system
<solene>I made a base Guix install with desktop services enabled, GNOME is working fine, but my i7-1260P GPU isn't working, it's using llvmpipe instead. I thought a firmware is required for this gpu
<Andronikos>solene: Do you use linux-libre kernel? If it as fairly new generation it may require proprietary blobs to run
<solene>Andronikos: yes, stock guix config
<Andronikos>I think you CPU is just to modern to run on 3D accel with libre firmware
<ieure>I'm linting some package recipes before I submit patches, and `guix lint` is complaining: "tabulation on line 31363, column 0". The info docs say "Warn about obvious source code formatting issues: trailing white space, use of tabulations, etc."
<ieure>What the heck is a tabulation??
<Andronikos>if you insert a tab char instead of space I guess
<ieure>No, definitely not.
<ieure>At least: my recipe does not contain hard tabs. They're the devil and I never use them.
<ieure>whoa
<ieure>Okay
<ieure>There are hard tabs
<Andronikos>if you use Emacs, try "describe-char" maybe that helps.
<ieure>That is a very poorly worded lint warning.
<Andronikos>Didn't even knew what hard tab was but tabulation was clearly for me.
<ieure>I don't know why it doesn't say "tab character" or have the ASCII code or something.
<ieure>"Tabulation" means something completely different: https://en.wiktionary.org/wiki/tabulation
<peanuts>"tabulation - Wiktionary, the free dictionary" https://en.wiktionary.org/wiki/tabulation
<kbtdr>I am starting a guix home configuration and am trying to customise the bash prompt. I have followed the simple service example in the manual and have created a two line PS1 and a PS2 with a continue statement ("PS2" . "continue-> "). In each case the second line printed has a prompt symbol @ at the start. Why is this?
<solene>Andronikos: I think so too, thanks for confirming
<zamfofex>ieure: “Tab” in this context is short for “tabulate”. They are literally called “tabulation” in both ASCII and Unicode.
<zamfofex>Tabulation characters are used to tabulate text.
<zamfofex>See e.g. https://unicode.org/charts/PDF/U0000.pdf U+0009 “character tabulation” or “horizontal tabulation”.
<ieure>zamfofex, Text can be tabulated by using either spaces or the tab character. Saying "it's tabulated" does not clearly state the problem it noticed.
<ieure>Is the issue here.
<zamfofex>I suppose. Rewording it to “tabulation character” would probably be sensible.
<mwette>Is there issue with using `package' form inside a `let' like here: https://github.com/paperclip4465/guix-zephyr/blob/master/zephyr/zephyr/packages/zephyr.scm#L36
<peanuts>"guix-zephyr/zephyr/zephyr/packages/zephyr.scm at master ? paperclip4465/guix-zephyr ? GitHub" https://github.com/paperclip4465/guix-zephyr/blob/master/zephyr/zephyr/packages/zephyr.scm#L36
<mwette>I have a form like that inside one my channel rtems.scm file and the packages with that form don't show up in `guix search rtems'
<ieure>The Guix manual says to run this command to get a patch series to contribute: `git format-patch -NUMBER_COMMITS -o outgoing --cover-letter --base=auto`
<ieure>This does not work, and I think it's because of `-NUMBER_COMMITS`, which isn't a format-patch option. Is this supposed to stand in for something else, like am I supposed to put the number of commits I want to send in there? Or is it just wrong?
<ieure>git-format-patch can take a bunch of numbering-related options: [-n | --numbered | -N | --no-numbered] [--start-number <n>] [--numbered-files]
<ieure>Passing it -NUMBER_COMMITS gets parsed as -N -U MBER_COMMITS or something similar to that, and complains that the argument to -U needs to be numeric.
<nckx>No, it's literally -1 or -5 or whatever.
<ieure>And that means... what? The number of commits past HEAD to make patches for?
<nckx>Yes.
<ieure>Alright.
<nckx>I am in awe of your overthinking skills which rival my own though. I think it's formatted as a metasyntactic variable but perhaps not all renderings make that clear.
<ieure>nckx, I just want to follow some instructions.
<nckx>Well you came to the wrong place.
<nckx>ACTION looks at 'info guix' — no it's not clear.
<ieure>Git is wild and wooly and it's entirely possible there's something that takes -FOO_BLAH argument syntax; and the Guix documentation says _nothing_ about what NUMBER_COMMITS is, not does it set it off as an obvious thing for me to be filling in, nor make it clear what value would go there.
<nckx>Yeah.
<ieure>Also unclear to me why you'd even want that, instead of saying `git format-patch origin/master', which gives you one patch per new commit.
<nckx>It might be more clear to write -<NUMBER-COMMITS> but (1) people have actually typed that verbatim still and (2) I think it goes against Texinfo conventions.
<ieure>I've seen braces used for this, but the real issue is that the docs don't explain what you should do clearly.
<ieure>Also: git: 'send-email' is not a git command. See 'git --help'.
<nckx>ieure: Speaking for myself, I consistently have >20 patches on top of master that I don't all want to send, but some would say I should use the one true topic branch workflow.
<ieure>Is git-send-email in some other package? Package search didn't turn up anything obvious.
<ieure>Okay, it's a separate output of git for some reason.
<nckx>ieure: guix install git:send-email if you have git in your user profile. If yox have git in your system profile, add `(,git "send-email") to your system packages.
<nckx>Braces as in {}? That's bizarre.
<ieure>nckx, Yes. `git format-patch -{NUMBER_OF_COMMITS}' or similar. Very common.
<zamfofex>Perhaps a simple solution would be clarifying it in prose and writing examples.
<nckx>And yet alien to me, so not that common.
<ieure>Yes, that's the real problem. Typographic convention doesn't really matter.
<nckx>Yes.
<nckx>I bet this looks better in the Texinfo source than in the rendered output :)
<zamfofex>For example, “Where ‘NUMBER_OF_COMMITS’ is the number of commits to include e.g. ‘git ... -5’ to submit five commits” could work.
<ieure>Yes.
<zamfofex>The italics text means “replace this with something”.
<nckx>Problem is not every rendering supports italice
<nckx>*.
<nckx>E.g., there are no italics in 'info guix' [here].
<ieure>Yeah. I'm using Emacs' built-in info reader (in GUI mode), and while that supports italics, that part of the text in the manual isn't italicized.
<nckx>Computers blow.
<ieure>Will also say that the git-format-patch man page doesn't document this way of making patch series at all, either. It says you can specify a commit or range.
<ieure>I'll take this form of blowing over the corporate SaaS hell form of blowing any day.
<nckx>Patch welcome, sincerely.
<nckx>Just keep it short, etc.
<ieure>I would like to, soon as I figure out how. :)
<ieure>Obvs. I'm struggling with that very task.
<nckx>Still stuck?
<ieure>Not at the moment.
<ieure>I'm running into this problem because I'm trying to submit recipes for some of my Emacs packages. First time contributing to Guix, it's definitely more involved than I'm used to.
<ieure>I've contributed to Emacs before, including dealing with the copyright waiver, so this isn't the worst experience I've had. But it's atypically difficult.
<Andronikos>everything in UPPERCASE means it is something you chould change.
<zamfofex>ieure: What do you feel like makes it more difficult than sending patches to Emacs?
<Andronikos>so you should be aware of that syntax. Emacs does it as well.
<ieure>Andronikos, There's no typographical conventions in the manual.
<ieure>zamfofex, It's not more difficult than that. It's the second-most difficult after that.
<nckx>It's pleasant compared to contributing to GitHub projects, which is admittedly a low bar that's hard to limbo under...
<nckx>Had to do that last week. What a nightmare.
<freakingpenguin>I have a system configuration that's written as a module and inherits an os-config from another module/file. Is it possible for both files to appear in /run/current-system for, say, auto-update purposes?
<ieure>zamfofex, What makes it difficult? The manual is unclear. Have to configure Git to be able to send emails. Linter gives weird errors. Have to stop and ask at pretty much every step. I'm sure it gets easier, but going from zero to submitted patch is arduous.
<zamfofex>nckx: It’s fairly easy if you use their web interface. (Though I don’t know if it works transparently without running their proprietary JavaScript.)
<Andronikos>ieure: Run guix build --help Everything in UPPERCASE should be replaced. You can see this behaviour everywhere in the GNU world. At least I always saw this pattern
<Andronikos>ieure: I did my first contribution today. Except configuring git send-email (which was easy to figure it by searching elsewhere) I don't had much trouble. I did not even contribute to Emacs. First time having to deal with this workflow.
<ieure>Andronikos, Yes, common there. Also common: explaining what the value you should put in actually is. "-s, --system=SYSTEM attempt to build for SYSTEM--e.g., "i686-linux""
<ieure>If the Guix manual was like that, I'd have no issue.
<zamfofex>ieure: I feel like you have been having difficulties with things that most people wouldn’t. E.g. most people contributing to Guix would know what a tabulation character is. I guess the “number of commits” thing could be more clear, but I haven’t seen anyone get hang up on that.
<ieure>zamfofex, I also feel that way.
<Andronikos>ieure: What you want is that the manual is writting by technical writers with a consistent style guide. As a perfectionist I want this as well, doubt FSF has the money for it.
<ieure>No, what I want is for the manual to convey the information I need in order to accomplish basic tasks, as a novice to Guix.
<nckx>The in-line explanation makes sense to me. Defining Guix-specific typography that diverges from all other info manuals not so much.
<ieure>nckx, I didn't say it had to diverge, and have *repeatedly* said that the specific convention doesn't matter.
<zamfofex>ieure: My first few contributions to Guix were just sending “git diff” output as an attachment from my email GUI. I’ve heard it makes it more difficult to maintainers (so I’ve learned to do it more correctly thereafter), but for simple patches, I think that would work fine to get started. (Though if it really is a big hassle for anyone, feel free to correct me.)
<zamfofex>ieure: The convention is capitals+italics. It’s already there, but you said you didn’t find it clear enough.
<nckx>ieure: You already said above that the convention doesn't matter.
<nckx>No need to repeat it.
<ieure>zamfofex, It wasn't clear enough for the reasons I stated: My info reader didn't show it in italics, and even if it had, it didn't say what value would be reasonable for NUMBER_COMMITS, the `-3' convention used isn't documented in the git-format-patch man page.
<zamfofex>It is: https://git-scm.com/docs/git-format-patch#Documentation/git-format-patch.txt--ltngt
<peanuts>"Git - git-format-patch Documentation" https://git-scm.com/docs/git-format-patch#Documentation/git-format-patch.txt--ltngt
<ieure>Okay, yep. It's not in the SYNOPSIS, though.
<ieure>And difficult to search for.
<Andronikos>btw. is that -vREVISION bug still present in Git?
<ieure>Ha, these are getting cc'd to a former coworker. Katherine Cox-Buday.
<Andronikos>ieure: Because it is Git documentation and not GNU documentation. Only GNU does this stuff with UPPERCASE is something you need replace (which makes sense, don't know why not more people adopt it)
<ieure>We used to work at Simple, the online bank.
<ieure>Andronikos, Yes, I understand, also man/info conventions are different. I'm not searching for NUMBER_COMMIT in the git-format-patch man page.
<zamfofex>Andronikos: I think a simple reason is that it there are options that are in uppercase.
<Andronikos>My english is getting more and more broken. Guess it is time to go to bed.
<podiki>howdy guixers
<podiki>if anyone has any favorite packages, feel free to check if they built successfully on CI for the mesa-updates branch
<podiki>I hope to merge it in the near future (need to merge in master first)
<nckx>zamfofex: Wait. Uppercase long option? (Not doubting you, just getting popcorn.)
<nckx>I know they exist, but commonly used?
<zamfofex>E.g. ‘less’ has ‘--LINE-NUMBERS’.
<nckx>Right. Less.
<nckx>Of course.
<nckx>Something was itching at the back of my mind. Of course it's less.
<zamfofex>It has many uppercase/lowercase variants. Usually they either negate each other or mean something related.
<podiki>if someone has a few spare cpu cycles, could you try to build skia from mesa-updates branch? i think it built locally for me, bordeaux has it, but berlin keeps segfaulting on the tests
<zamfofex>E.g. ‘--line-numbers’ removes line numbers, ‘--LINE-NUMBERS’ adds them. ‘--long-prompt’ makes the prompt verbose, ‘--LONG-PROMPT’ makes it even more verbose.
<Andronikos>Seems like less uses it for asc or desc sorting. Makes sense for me
<nckx>zamfofex: I even use a few.
<zamfofex>On my shell, after ‘type less’: less is aliased to `less -FISRMN -x3 --tilde --shift=2 --use-color --line-num-width=5'
<nckx>You win.
<podiki>nckx: I don't normally deal with big(ish) merges, anything I should be careful of in merging master into a branch? (and then later branch to master when the time comes)
<podiki>ooo never bothered yak shaving my less (or similar), that sounds fun
<nckx>'Merge conflicts' is all what comes to mind.
<Andronikos>podiki: Does skia take long to build?
<nckx>podiki, zamfofex: Noo, that way madness lies, trust me. Or at least a wasted afternoon.
<podiki>preview looks clean and since I'm touching mostly things that won't be chagned in master it should stay that way I think...
<nckx>You'll have twe perfect pager but at what cost.
<podiki>Andronikos: the build is quick, tests take a bit longer; in total maybe 5 minutes on say 12 fast cores? but it may want a lot of memory, I forget
<nckx>podiki: If git didn't complain you are *likely* safe.
<podiki>line numbers and colors looks like a nice easy addition though :) it is because i haven't tweaked my emacs recently that the itch needs scratching
<Andronikos>podiki: 12 fast cores, well not for me. I thought you meant building. Currently running "guix time-machine --branch=mesa-updates -- guix build skia --rounds=3"
<podiki>nckx: thanks, that's what I'm banking on. I don't see much in the way of commit messages for these either, other than git default
<nckx>Sure. And then you start smoking the lesspipe.
<podiki>Andronikos: thanks! I will try later too, it failed locally for me too but then i guess at some point worked? and on bordeaux. my attempts at restarting on CI keep getting same segfault on a test though
<nckx>podiki: Sure, no changelog or anything here. (Imagine...)
<Andronikos>podiki: I will report in some time. I only have 4 cores that run on 3.5GHz. (yep, that is a 10 year old CPU)
<podiki>while I have mesa-updates on topic; please do check weather/CI builds for anything; been noticing some tests failures and some build failures after ungrafts
<podiki>I'll send an update to guix-devel this weekend too; hopefully merge it to master soon (x86_64 looks pretty good already)
<podiki>Andronikos: appreciated!
<Andronikos>What is better for compiling. More cores on lower frequency or less cores but higher frequency?
<podiki>i think more cores; most builds I see scale quite well with more threads
<ieure>Okay, two questions: Firstly, can someone share a working git-send-email setup? I installed the package and set up all the Git config, then ran `git send-email outgoing/0000-cover-letter.patch --annotate'
<ieure>I got back this error: Unable to initialize SMTP properly. Check config and use --smtp-debug. VALUES: server=localhost encryption= hello=l0p.u37.divs.atomized.org port=25 at /gnu/store/4zsf7lwf0lpjwc5ba1bna43cn1zcgw0m-git-2.41.0-send-email/libexec/git-core/.git-gsend-email-real line 1717.
<ieure>I think the issue here is that it's looking for a server of localhost, which is wrong.
<ieure>In my git config, I have: sendemail.smtpserver=smtp.fastmail.com
<Andronikos>you need [sendemail] config in git
<ieure>I have it, as I mentioned.
<Andronikos>my config looks different
<Andronikos>wait a minute, checking
<podiki>i see smtpServer (captial S); but mine is my localhost name (since i have a local smtp on a different port)
<Andronikos>i don't have that sendemail. I just have smtpServer
<ieure> https://paste.debian.net/1297924/
<peanuts>"debian Pastezone" https://paste.debian.net/1297924
<ieure>Okay, yeah. Capitalization is wrong.
<nckx> https://paste.debian.net/1297925/
<peanuts>"debian Pastezone" https://paste.debian.net/1297925
<ieure>Okay, huh.
<Andronikos>The command you provided gives the same result for me. I think the issue is in your config. Where and how eactly did you configure it?
<ieure>My ~/.config/git/config says "smtpServer = smtp.fastmail.com", I guess the config lister thing lowercases everyting.
<ieure>This is the relevant bit of my Git config, it's in ~/.config/git/config: https://paste.debian.net/1297926/
<peanuts>"debian Pastezone" https://paste.debian.net/1297926
<Andronikos>podiki: Ah it doesn't work because of other channels I have. How can I tell guix time-machine it should only use the official Guix channel?
<podiki>you can use -C for a channels file I believe
<nckx>I've never used fastmail, but don't see any obvious mistakes (so obviously there are non-obvious ones -_-)
<Andronikos>ieure: Looks good to me
<podiki>(i usually have one for time-machine to specify commits for other channels when testing)
<ieure>Second question, manual has this -vREVISON argument. Do I need to specify that for the first time I submit patches, or is that only needed if I need to edit the code and resubmit the patches?
<podiki>what is the write what to gc if you want a build from scratch when it would do a graft? delete referrers of that derivation?
<Andronikos>ieure: If you submit the patch again (revised) because there were mistakes in it.
<ieure>Andronikos, Okay, thank you.
<ieure>Last question, is there some way to integrate the git send-email stuff with my pass(1) setup? That's where I have my credentials, and it's annoying to have to fetch them manually to tell git about.
<podiki>I think you can use a pass command instead of putting in your password in the config?
<ieure>podiki, git has this git-credential thing it uses. I'm not sure it even supports putting password in the config (which is good).
<Andronikos>ieure: If you find out, please tell me. Asked this question myself, too.
<ieure>Andronikos, :(
<ieure>I have successfully sent in some patches for packages: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67114
<peanuts>"#67114 - [PATCH 00/14] Add Emacs Weirdware packages - GNU bug report logs" https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67114
<ieure>I know I'm cranky about computers, but I genuinely appreciate the help.
<ieure>And once I have this stuff sorted, I'll be complaining less and patching more.
<podiki>just found, haven't read/tried https://ryanlue.com/posts/2019-04-19-git-credential-with-pass
<peanuts>"git-credential with Pass" https://ryanlue.com/posts/2019-04-19-git-credential-with-pass
<ieure>Oh nice, thank you. That seems pretty straightforward.
<nckx>ieure: \o/
<podiki>yeah it does
<podiki>and as it notes, using "pass" for passwords is terrible for internet searching (yet this one came up pretty quickly for me!)
<ieure>I think I need a separate pass entry to set the password= prefix, or to wrap the pass command in a script that does that. But not terrible.
<lilyp>tbf the full name is "password-store", but folks be lazy
<ieure>Even the developer(s) use "pass": https://www.passwordstore.org/
<peanuts>"Pass: The Standard Unix Password Manager" https://www.passwordstore.org
<ieure>And yeah, it is hard to search for.
<podiki>to answer my question about guix gc and grafts: use guix build --no-grafts to get the store item to delete so you can build from scratch
<Andronikos>ieure: You can also use this webinterface: https://issues.guix.gnu.org/67114
<peanuts>"[PATCH 00/14] Add Emacs Weirdware packages" https://issues.guix.gnu.org/67114
<Andronikos>podiki: /gnu/store/jhkgvi9gy2514pgl8mhhzrycnm4mispf-skia-112-0.6d0b938 with rounds 3.
<podiki>Andronikos: oh that was quick, all passed?
<podiki>(build took about 5-6 minutes here, tests running now)
<ieure>Andronikos, Nice, thank you.
<Andronikos>podiki: Well I guess, I did run build skia --rounds 3. I had no error message. Building should run tests and error out if they don't pass AFAI
<podiki>yes
<podiki>weird, ci.guix.gnu.org really doesn't like to build skia on mesa-updates
<podiki>i'll have to check my hash, but yours is different than the most recent on ci https://ci.guix.gnu.org/build/2573633/details (mine were too, no idea why)
<peanuts>"Build 2573633" https://ci.guix.gnu.org/build/2573633/details
<podiki>Andronikos: and thanks! probably I won't worry about this then, probably can find some real failures to fix anyway