<mbakke>is 'mesa' still a staging candidate? I see it has amassed almost 4k dependents ... or about 20% of all packages. <the_tubular>is building /gnu/store/69fvdr4nyskb93maaqh35bf94f47diry-python-jedi-0.18.1.drv.. failing for anyone else ? <acrow>I would like to create a guix home simple-service that populates ${XDG_HOME}/sx/sxrc. I'm just using a plain-file and home-xdg-configuration-files-service-type and it is pretty and works BUT sx tells me that the file must be executable and what is in the store is #o444. Can this be done? I'm thinking that the store will not allow this. <acrow>This comes to mind (prog1 ,(plain-file "sxrc" "my file content") (chmod #o555)) ?? <dominicm>Is there a way to find out why a certain package is in my profile? <dominicm>I managed to find my specific case by grepping the guix repo but was hoping there was a better solution. It seems like the machinery is there since propagations are shown with profile conflicts <unmatched-paren>i tried (with-imported-modules '((ice-9 ...) ...) (computed-file "..." #~(begin (use-modules ((ice-9 ...) ...) ...))) <unmatched-paren>guix home: error: file 'ice-9/textual-io.scm' could not be found in these directories: /gnu/store/xdmlndhnjv34ybivlnrkwsf0ndlhr62k-guix-module-union/share/guile/site/3.0 /gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile/3.0 /gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile/3.0 /gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile/site/3.0 /gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8 <unmatched-paren>/share/guile/site /gnu/store/1jgcbdzx2ss6xv59w55g3kr3x4935dfb-guile-3.0.8/share/guile /run/current-system/profile/share/guile/site/3.0 /gnu/store/p3idmdrnsfzm34q7v8wlb0q46pyaqwrs-guixrus/share/guile/site/3.0 <jpoiret>unmatched-paren: you shouldn't need to (with-imported-modules) a basic guile module iirc <jpoiret>but the module is (ice-9 textual-ports), no? <nckx>sneek: later tell maximed: Sounds good, until separate debug outputs are supported (Rust supports them; but our rust-build-system doesn't seem to — another antioxidant feature perhaps? ☺ <nckx>Noo don't eat my ). I won't be ablet to sleep. <nckx>sneek: later tell maximed: ) <nckx>Jus reactin' to yer ‘howdy’ 🤠 ***wielaard is now known as mjw
<phodina[m]>could somebody help me with guix reconfigure. I have Btrfs rootfs and subvolume on /boot. Vfat partition is mounted under /boot/efi. The guix system reconfigure fails with msg: efibootmgr failed to register the boot entry:Input/output error. <apteryx>uh, how is is possible to get " error: profile contains conflicting entries for gcc-toolchain" when using "guix package -m manifest.scm" <apteryx>appeared following adding phoronix-test-suite, which propagates gcc-toolchain <phodina[m]>The system installed normally but now for some reason the reconfigure cmd fails <apteryx>phodina[m]: could be a firmware bug; I've see this before. Try rebooting the box <apteryx>guix deploy is not happy this morning: 'guix deploy: error: #<unspecified>: invalid G-expression input' <phodina[m]><apteryx> "phodina: could be a firmware bug..." <- Yes, I was thinking about that as there is recently released coreboot running. Querying the efibootmgr seems to confirm this as there is some boot entry but it's not visible and can't be removed. In any case I added manually new one and modified the bootOrder. Hopefully it will boot <jpoiret>podiki[m]: thanks for the updated polybar patch! :) <lechner>Hi, is there a way to declare a default EDITOR with Guix Home, please? <lechner>Also, would someone please share their 'fish' shell setup for Guix Home? Thanks! <phodina[m]>Yup, it's definitely broken as the UEFI shell does not see the Guix EFI loader. But I was able to add it so Guix boots but reconfigure command is unusable. Anyway apteryx: thanks <nckx>This is with your latest ‘patch’. <apteryx>is propagating gcc-toolchain from a package a bad idea? <apteryx>the package in question fetches sources from the net and builds them itself (phoronix-test-suite), that's why I propagated it in the first place <nckx>Honestly, it doesn't sound like a *good* idea… <nckx>Can it not just be wrapped? <apteryx>no, because the tool prompts for missing libraries that the user must manually install <apteryx>I guess I should check if it prompts for GCC, I was expecting it might fail if there's not even a toolchain available <nckx>How does it check whether the tool is installed? *nckx installs it to find out. <apteryx>or just "phoronix-test-suite run fio" for a quick test <nckx>podiki[m]: I'm not happy that the wayland failure only happens on my machine, but it seems your code is not to blame :) <nckx>substitution of /gnu/store/m6i62lwb6pzk5mzr2p7nyg3pg760gkxf-rustc-1.39.0-src.tar.xz complete <apteryx>planglois: thanks for the docker update again! it had been a wart waiting for a fix in my setup, and in past attempts I had somehow ended in a place of hurt (Go protobuf madness) *apteryx fixed ibus-anthy, sorry for the breakage <mitchell>apteryx: Speaking of wayland failures, I am having trouble cross-compiling wayland-protocols for aarch64-linux-gnu. Configure fails complaining about no pkg-config binary for the machine choice <podiki[m]>jpoiret: and thanks for the quick and helpful review! <podiki[m]>I think I'm at nearly 50 patches, I think a decent start for my first year here :-) <podiki[m]>nckx: oh it is a test failure? I can try later to run it a few times, maybe nondeterminstic failure? <jpoiret>i have way less patches but i'm trying to pull my weight reviewing instead <podiki[m]>I think a few I did comment on have probably gone stale and need a refresh too <nckx>mitchell: (arrogantly assuming you meant me): Seems like it's calling ‘pkg-config’ instead of ‘aarch64-linux-gnu-pkg-config’. <nckx>I'm not as fluent in Meson as in autotools. <nckx>podiki[m]: I was rather implicit but it built fine on another machine. So yes, non-deterministic. <nckx>jpoiret: Probably a better result/weight efficiency at this time. Thank you very much. <unmatched-paren>(Sometimes unmatched-paren wonders about the quality of their brain. <apteryx>has someone else noticed lisp-fill-paragraph is broken since Emacs 28.1? <apteryx>I traced it down to Emacs commit 9bf367e1848. <apteryx>the problem manifests for example when trying to indent description. It often cause the first line to be wider by its indentation, which makes it ugly and annoying. <apteryx>before I report it, I'd like to know if others also noticed/reproduced it *nckx noticed it, but didn't report it… *nckx closes unmatched-paren. <podiki[m]>nckx: (re: wayland) ah, ok. (un)luck of the draw, but good to catch early <nckx>I'm finally rebuilding my system with an imported copy. <podiki[m]>nckx: actually, on that front, there's one mesa test disabled for that reason (i686 nondeterministic); I re-enabled a different older test we had disabled and passed now for me, might be worth some challenge runs too <podiki[m]>though I think the re-enabled test was a more general failure with the appropriate bug filed and now closed <nckx>podiki[m]: May I briefly PM you? Has nothing to do with Mesa. ***stikonas_ is now known as stikonas
<lilyp>apteryx: Isn't it expected that the description gets an indent? <apteryx>it's not an indent, it's the computation of max width for the first line that gets the indent added somehow <apteryx>our emacs-based indenter must produce borked results too, I suppose? <lilyp>tbf I don't use emacs to figure out fill-column, so I didn't notice that <lilyp>Well, I do use Emacs, but only column-number-mode ^^" <lilyp>I got used to break lines whenever I need to <apteryx>OK! M-q is very handy on comments and descriptions <nckx>apteryx: I had, but like Lily I hardly every use it, if at all. <nckx>It's as likely as anything that I noticed after running it by accident. *nckx uses fill-column-indicator to insert artisanal newlines. *apteryx tries report-emacs-bug <nckx>Hm, phoronix-test-suite is a stateful boy. Do you know where it stores build results, apteryx? <nckx>It's not trying to rebuild libaio now. <nckx>Sigh. I was looking for love in all the XDG places… Silly me. <apteryx>np! I considered extending its mechanism to use the system package manager to install stuff, but decided to punt for now <apteryx>it'd have to use 'guix shell' instead of 'guix install', and consume the environment variables newly defined or something. perhaps not trivial <apteryx>all of this from PHP. sounds fun, just not today *nckx considered it too, but it sounds like a rabbit hole that I'll gladly side-step for now. <podiki[m]>phoronix is a bit of a beast; I ran it some time ago pre-guix package <podiki[m]>I wish my kernel compiled as fast as the test (I assume it doesn't do any driver modules) <apteryx>podiki[m]: the packaging of it doesn't do much; you're still pretty much left fending for yourself installing needed dependencies of tests for now :-) <apteryx>but at least it's easy to get started/discover <apteryx>well it does one thing which was not trivial, which is clean any test profile that was using nonfree software <apteryx>so no Batman whatever test, thank you <apteryx>and disable test metadata updates, which would otherwise bring the bad stuff back <nckx>B.A.T.M.A.N. is in Linux, so you probably don't mean that. <podiki[m]>glad to have it, a future "guix shell" version would be very neat <nckx>apteryx: :) I wasn't joking though. *nckx guesses some 3D game benchmark. <podiki[m]>not to go down the rabbit hole yet, but does phoronix try to call the distro package manager? so it would need to run guix shell instead, at a super basic guess <nckx>podiki[m]: I'm not looking at that today, but my first hunch would be that it won't be that simple: for that to work you'll have to run the ‘continuation’ within the shell, and I bet p-t-s isn't set up for that, only for stateful ‘do x; apt install foo; do y’. <podiki[m]>I'm trying not to get distracted from my other distractions as well <podiki[m]>sure, can take a look this weekend probably; I'd love learning/hacking with guix shell more <podiki[m]>seems like it would be a good fit for something like this <nckx>Probably a better fit that what it does elsewhere, once you convince the code to accept that :) <nckx>It is quite significant. <cwebber>install-info: warning: no info dir entry in `/gnu/store/s3sv7svl9h00swc7b7m3jyd2is2ys9n9-guile-goblins-0.8-pre/share/info/goblins.info' <cwebber>and indeed it doesn't show up in *info* <cwebber>is there a step that's needed to populate info that I'm missing? <cwebber>I'd think that would be enough. Maybe it isn't? <nckx>(I'd be more helpful if I could.) <cwebber>I wonder if I'm missing some important metadata <maximed>mitchell: Cross-compiling wayland-protocol works for me. <sneek>maximed, you have 2 messages! <sneek>maximed, nckx says: Sounds good, until separate debug outputs are supported (Rust supports them; but our rust-build-system doesn't seem to — another antioxidant feature perhaps? ☺ <maximed>It's wayland that cross-compiles, wayland-protocols doesn't. <maximed>Normally the correct pkg-config should be found because it's put in the 'cross-file' <maximed>though the build log speaks a about ‘pkg-config binary not found for machine MachineChoice.BUILD’ <maximed>Assuming Meson terminology is the same, that means it really needs pkg-config, not TARGET-pkg-config <maximed>Looks like it wants a native wayland-scanner. <maximed>Proposed fix: move wayland-protocols to native-inputs, remove pkg-config, add pkg-config-for-build <maximed>Or %pkg-config would work too in this particular case. <nckx>Assuming wayland-protocols → wayland. <nckx>You might be very close though, I just didn't persist. Don't let me discourage you, I'll shut up. <nckx>Well, no, almost certainly tested and not sufficient. But probably a step in the right direction. <sneek>Its been said that Botfruit is good for sneek. <nckx>sneek doesn't believe it for a minute. <maximed>sneek: botfruit is disliked by sneek, but actually I like it very much. <sneek>From what I understand, Botfruit is good for sneek. <sneek>From what I understand, botfruit is disliked by sneek, but actually I like it very much. <maximed>sneek: botfruit is said to be disliked by sneek, but that's all lies, actually I like it very much. <sneek>Someone once said Botmilkshake is delicious. <maximed>sneek: botmilkshake is delicious, but that's no reason to make a milkshake of me. <sneek>botmilkshake is delicious, but that's no reason to make a milkshake of me. <maximed>sneek: :) is a lie when used as a response to botsnack. <maximed>sneek: :) is a lie when used as a response to bot snack. <nckx>sneek is having absolutely none of what you are selling, fiend. <maximed>sneek: smileys are a lie when used as a response to bot snack. <nckx>sneek: good bot, eat snacks. <sneek>I could be wrong, but smileys is a lie when used as a response to bot snack. <unmatched-paren>sneek: What is sneek having absolutely none of what you are selling, fiend. <sneek>I've heard Sneek is forgetful <sneek>Its been said that Sneek is too well-behaved to eat just any food it finds <sneek>Its been said that sneek is me. <maximed>sneek: sneek is having absolutely what you are selling, friend. <nckx>sneek: sneek is tricksy liar who tells maximed only what they want to hear, but secretly adores a good bot-snack. <nckx>sneek: sneek is tricksy liar who tells maximed only what they want to hear, but secretly adores a good snack. <nckx>sneek: sneek tells only lies, including this one. <sneek>From what I understand, perl is the literal opposite of scheme <maximed>sneek: sneek is tricksy liar who tells nckx only what they want to hear, but secretly adores healthy food <sneek>I've heard sneek is a sneek sneek that sneek sneek sneek sneek sneek <apteryx>podiki[m]: the code selecting the script for the host system is pts-core/objects/client/pts_external_dependencies.php <nckx>sneek has gone mad with lies. <sneek>From what I understand, Sneek is forgetful *nckx envies sneek today. <podiki[m]>apteryx: thanks, will look next I get a chance <unmatched-paren>sneek: Suddenly shutting down the server sneek runs on is a really terrib <nckx>You made the same mistake I did. <maximed>sneek: single-words are what sneek can use as subject. <nckx>sneek: abusing-sneek-as-free-key-value-object-storage is c3RpbGwgYmV0dGVyIHRoYW4gSVBGUw== <vagrantc>at least the abuse has a proof of work typing out so many characters <nckx>Damn, should have used base256 encryption 🤦 <sneek>Someone once said IPFS is inferior to Sneekchain™®℠©®. <nckx>Poor dsmith wondering where all the database server free space went. *nckx stops short of uploading a base64'd bored ape JPEG to sneekchain, because some things shouldn't be preserved. <johnjaye>does a gpg signature verify file integrity as well or just authenticity? <johnjaye>the webpage only shows a sig file to download to check the hash of the guix iso <unmatched-paren>sneek: Guixcoin is mined and sent directly to the Guix developers when you run a Guix build. <sneek>Its been said that Guixcoin is mined and sent directly to the Guix developers when you run a Guix build. <nckx>johnjaye: You sign over a hash, so both. <johnjaye>let me check the manual again, have to import some pgp key for it to verify <nckx>Your transaction is currently pending review. Please wait a few months for a committer and ping us if you didn't get your insulin by then. <johnjaye>then warning cannot verify trusted signature. <nckx>‘Good signature’ is good. <johnjaye>i think it's simpler to just provide an md5 or sha1 hash isn't it? <maximed>johnjaye: IIUC, that meants the signature is correct in that the stuff is signed by Maximddd. However, <maximed>GPG doesn't know whether your notion of Maximdd is equal to the Maximeddd mentioned in the signature. <nckx>…did you mean to use 3 different names? Because they are all (or should be) the same. <maximed>To do those things, you need to tell GPG that it's the ‘correct’ Maximddd. <maximed>nckx: if your talking to me, I didn't. <johnjaye>it's Maxim Cournoyer but my connection is unstable <maximed>IIRC the nick<->full name mapping, the public key should be 27D5 86A4 F890 0854 329F F09F 1260 E464 82E6 3562 <maximed>at least, that's what in the .guix-authorizations of Guix <maximed>(and I don't know if apteryx uses the same key for commits as for e-mails) <maximed>unmatched-paren: FWIW there's 'git am' as well. <nckx>unmatched-paren: ‘git apply’, but it adds little value beyond auto-staging the changes. <maximed>unmatched-paren: I wouldn't do 'wget | patch -u'. <nckx>‘git am’ should choke on that input because it's not a complete git patch. <maximed>Unless 'patch' has protections against that, a rogue web server could insert a diff to modify your .git/config <maximed>(and consequently, invoke random binaries at next "git SUBCOMMAND") <nckx>Someone once said Maxim != Maxime. <johnjaye>i see. well at any rate, whichever maxim this is, it said to import the key to verify the tarball in the manual. i assume it is good to verify the .iso as well? *nckx gives self a botsnack. <nckx>johnjaye: It can't hurt. <johnjaye>well. i'm more interested in that i verified the right key. <johnjaye>does the manual mention verifying the iso and i missed it? <johnjaye>either way this is probably fine. don't want to be too paranoid but my connection has problems which can lead to data loss <nckx>See ‘USB Stick and DVD Installation’. <nckx>It should be the same key, so you don't need to re-import. <nckx>That's the advantage and reason of using keys: you don't have to receive a blessed hash over a (potentially compromised) channel for each single new file. <johnjaye>yeah but i'm trusting the website to give me the guix iso to start with. <nckx>You download the key once, then verify all future releases made by Maxim with your securely-stored copy. <nckx>That doesn't make sense. <johnjaye>right. apparently i'll have to verify a lot of stuff based on the manual <nckx>If the ISO is compromised, the signature won't validate. <johnjaye>the link to the iso is next to the link of the sig file <maximed>johnjaye: the sig file is not a hash, it's a signature. <johnjaye>yeah but i want a hash. because i have an unstable connection <nckx>Hashes have the exact weakness you just described. <nckx>And GPG serves both purposes equally. <maximed>johnjaye: To verify it downloaded properly, you can use 'gpg --verify' <maximed>(More formally: at least in the systems I know of and standard assumptions, authenticity implies integrity) <nckx>If you think that an attacker could just replace the key with a tampered key to match a tampered ISO: that won't work (it would be true of hashes, not of GPG signatures). <johnjaye>i guess i have to trust sv.gnu.org as well then? <nckx>You could find another source for the key, but yes, once. <nckx>With hashes you'd have to trust it each time you download a fresh release. <maximed>johnjaye: You don't if you can check via another channel that the _fingerprint_ is correct. <johnjaye>the manual does mention gpg 12 times. not as much as i thought. <johnjaye>nckx: i thought guix was rolling. so i only have to download the iso this one time correct? <nckx>It is rolling, but like all(?) rolling releases we update the installer once in a while. <nckx>Not as often as we should, but still 😛 <johnjaye>and then i could verify the new iso against the already downloaded key then? <nckx>[As long as Maxim does the releases; long may they reign.] <nckx>One day, when all software in Guix (or at least the subset used in the installer) is 100% reproducible, anyone should be able to recreate an ISO that matches Maxim's signature. <nckx>I don't think we're there yet, although I didn't try. <vagrantc>seems like gpgv should be used instead of gpg --verify, as verify outputs scary messages that ... basically need to be ignored <vagrantc>at least for most people who don't have a trust path to the signer <nckx>Those who do (which isn't me, at least I don't think I've ever met Maxim?) should know about --verify. <vagrantc>for people who've signed the key they're verifying against ... they probably know about --verify <nckx>It throws an error about missing /home/nckx/.gnupg/trustedkeys.kbx here. <maximed>sneek: later cwebber: I vaguely remember something about metadata in the .texinfo ... (though it might have been in the call to makeinfo etc, I don't know the details) <nckx>It has to throw at least 1 scary error to prove it genuine PGP® software. <sneek>I could be wrong, but sneek is me. <cwebber>maximed: yeah I was missing metadata :) <nckx>maximed: sneek refuses to ‘later cwebber’ <vagrantc>nckx: ah, yes. i forgot that rule of PGP <nckx>Warning: success detected: somebody might be doing something nasty! <nckx>vagrantc: I can't get gpgv to work as a friendly tool :( <nckx>I can't get it to work at all. <nckx>I'm not against GPG at all, but should we be considering signify or so? Does anybody here consider themselves knowledgeable in both? <vagrantc>nckx: gpgv --keyring /full/path/to/keyring.gpg signedfile <vagrantc>maybe doesn't work with detached signatures <vagrantc>and keyring should be just the key you expect to sign it... <vagrantc>for deteached it assumes the file signed has the same filename with a different extension ... <nckx>Ugh, no, it just needed guix-system-install-1.3.0.x86_64-linux.iso{.sig,} (both, and in that order) arguments, unlike --verify. <nckx>That might be what you meant (but then what extension? ‘No extension’ is what I would expect.) <unmatched-paren>Obviously we'll need to add dub-inputs or some such eventually, but I can't be bothered just now. <unmatched-paren>nckx: Nice! We should be able to gradually whittle that stuff down until we have something a bit gross but workable like our current cargo-build-system <nckx>Basically, it's everything I hate about Rust packaging, without the build-system maturity. <nckx>Anyway, it does mean that yes, I do have the confidence to merge your patches despite not knowing much D. I needed that, so thanks for your patience. <nckx>unmatched-paren: Yeh, haven't got round to that yet. Also probably won't push these at all in their current state. <nckx>unmatched-paren: Well, to be clear, it is objectively overkill for this application. I was trying to think ahead and write something generic, but meh. I'm not wild about putting *that* in the build system. <nckx>I don't like either, #:something-cargo-flashback-inputs is better than relying on labelling conventions. <nckx>unmatched-paren: What does (default (default-ld-gold-wrapper)) do? <nckx>Removed, not yet pushed, but will. ***mark_ is now known as mjw
<phodina[m]>How can I rewrite this definition of a variable `paths-bin` using gexp? I also simplifed the inputs so the `assoc-ref` has to be replaced as well. I have several more definition similar to this one with bigger list as input for lambda. <maximed>G-exps don't care about maps or lambdas. <maximed>Just replace the outermost ' by a #~ or something like that in the package definition and the S-exp becomes a G-exp. <maximed>Are you referring to search-input-file / search-input-directory? <maximed>phodina: replace the arguments by (arguments (list #:phases #~(modify-phases %standard-phases [...]))). <phodina[m]>Lines 44 and 50. The intention is to provide paths for wrap-program <maximed>phodina: are you sure you're asking about turning things into a G-exp? <maximed>You don't need to change anything there to turn it into a G-exp. <phodina[m]>maximed: I've already done that, but now I'm stuck at those 2 variables and I don't know how to rewrite it <phodina[m]>podiki[m]: Yes but I also simplified the inputs and it stopped building <maximed>phodina[m]: Are you looking for G-exps or delabilification? <maximed>You don't need to change paths-bin for G-exps. <maximed>G-exps don't care much what you put into them, likewise for S-exps. <maximed>So I'm thinking you're looking into eliminating input labels instead (‘new style inputs’) <maximed>so maybe: (map (lambda (binary) (dirname (search-input-file inputs (string-append "bin/" binary)))) '("the binary from libc" "the binary from "iptables" ...)) <maximed>also, = instead of prefix (for wrap-program) is less fragile. <maximed>And in Guix GUIX_PYTHONPATH is used instead of PYTHONPATH (to avoid interfering with foreign distros) <gabber>are contributors expected/encouraged/asked to assign their copyrights to the FSF? <unmatched-paren>gabber: This is one of the seemingly rare GNU projects where the answer is no. <maximed>Though I suppose you could volunteer to assign copyright to FSF in your patch submission, and ask for appropriate paperwork? <nckx>The FSF has no copyright in Guix proper so far, barring embedded autotools stuff &c. <nckx>Sure would be… interesting if someone did that for… reasons? <gabber>there's not really a point if i were the only one, no? <nckx>gabber: I don't know why you would bother, no. <maximed>phodina: I thhink that putting a #~ in front of (map (lambda (input) (string-append ...))) will just lead to a build failure. <maximed>Because you can't put a G-exp inside a G-exp (except with an intermediate #$) <maximed>Also, #$input -> input (because 'input' is not defined anywhere outside G-exp context) <maximed>likewise, #~("PYTHONPATH" ...) -> ("PYTHONPATH" ...) <phodina[m]>maximed: It's just some thinkering I've been doing atm <maximed>#~("PATH" ":" prefix #$(append ...)) -> (append ...) <maximed>Waydroid looks Linux-only, so maybe add a 'supported-systems' field that only includes the linux systems? <phodina[m]>maximed: True, it depends on Linux kernel and LXC containers <gabber>the reason being that Guix is (already) licensed GPL3+ and license upgrades aren't as resource hungry as with GPL2? <maximed>gabber: I think it has more to do with Guix being a distribution, which would benefit for drive-by contributions for updating individual packages. <nckx>Only civodul can answer authoritatively. <phodina[m]><phodina[m]> "True, it depends on Linux kernel..." <- Well it depends mainly on the Android image as this has to be compatible to the host architecture. <nckx>unmatched-paren: gnu: packages: Update dub to v1.23.0. → gnu: dub: Update to 1.23.0. <unmatched-paren>nckx: Okay, I'll keep that in mind :) any other commit message changes I should make in future? <nckx>Not so much messages, they were generally OK (we don't add leading whitespace on lines following a *, but that's a nitpick). <nckx>What is going to cost me time is separating commits into smaller chunks. <unmatched-paren>To be honest, the "commits as small as possible" is *really* annoying... <nckx>You rename, gitify, fix-build, update, gexpify d-tools in one commit, I've separated them into 5. <nckx>I sympathise, but now I'm doing it. <maximed>Is convenient for reviewing, and for people looking through the git history later. <nckx>unmatched-paren: I don't mind, and I chose it over committing as-is myself, I've only myself to blame, but IWBN if you could do it on the go next time. It's still much less work, and it is a standard I think we should strive to keep high. <nckx>I've done this to myself plenty of times, you don't always know where a fix will take you, but usually thinking about how you're going to tell the story before you start/commit helps a great deal. <nckx>Often saves almost as much time as it costs. <nckx>When you factor in time saved by the reviewer, it's generally a net win, even if it doesn't always feel like that (‘just push my megacommit, it works, jeez’ — I get it). *nckx lecture over, pick up your free coffee at the exit :) *maximed looks at rust-ncurses <unmatched-paren>Now I just need to find some kind person with enough time to review "[PATCH v3] gnu: Add aerc" :) <nckx>unmatched-paren: So are the ld-gold-wrappers added in patch 1 & 2 obsoleted by patch 3? I'm doing them in order, but I thought you said as much earlier. <unmatched-paren>nckx: They're not necessary _for packages that use the dub-build-system_ *nckx takes a little break. By doing other work, but still. TTYL. <unmatched-paren>Actually, I should write an email reminding me to improve dub-build-system further. <nckx>I hadn't looked at patch 3 (d-b-s improvements) closely yet. <djeis>Is there a recommendation for the, like, "proper" way to package something with an autogen.sh script that directly calls the generated ./configure script (which immediately fails because it attempts to use /bin/sh)? <djeis>Taking a guess, patch or replace the autogen.sh script... But I've not run into this before and I'm unsure as to the convention. <maximed>djeis: Remove the call to ./configure. <maximed>Alternative: replace the bootstrap phase and manually invoke autoreconf, etc. <maximed>Alternative: send a patch upstream to use the standard interpretation of autogen.sh (assuming 'not calling ./configure' = standard convention, which I'm not actually sure about) <maximed>I don't have an example at hand but you could try "git grep -F autogen.sh" in a git checkout of Guix to find examples? <djeis>My understanding is that at the very least guix's interpretation of the convention is it shouldn't... Thanks for the suggestions, I'll try them. <acrow>podiki: Using xinitrc-xsession package you recently delivered. Thank you. Works like a charm and scratched the exactly needed guix itch. <podiki[m]>acrow: most welcome! glad you find it useful too, that's what I've been using for years (in Arch first) ***stikonas_ is now known as stikonas
<acrow>podiki: yes, that xinitrc is lightweight makes experimentation and iteration more fun. <podiki[m]>can be a bit of work getting your own wm set up the way you like it, and cutting out/adding the piece together <maximed>"guix shell emacs emacs-this-package emacs-that-package -- emacs" <maximed>I see that "guix install" is already mentioned there <podiki[m]>I still need to move my emacs package management to guix, right now is a mixture of both <the_tubular>civodul, maybe that could help guix configure emacs ? <the_tubular>well basically use guix home like you would for any other packages, but for emacs <podiki[m]>I use several manifests though, so my emacs manifest just needs to grow in packages and set up my emacs init with some tweaks <trevdev>Hey Guix, I'm chasing my tail trying to appreciate how to add a cron to my `guix-home-config` properly, with the required access to a module written and loaded on my user's GUILE_LOAD_PATH. I assume I need to get this module file into the derivation (and any other required files) store, because it's pretty clear to me at this point that my user's load_path is meaningless to mcron. <trevdev>When it comes to expressing a #~(job) gexp, I obviously don't want my script and any related files moved/built on a clock. I just want the job to execute. I also want the _context_ of the script/related files accessible to said #~(job) gexp, so I'm not sure how to build the job. Is anyone here good at this? <podiki[m]>welcome! actually that reminds me to push some updates too <the_tubular>rest shouldn't be that hard, but they also don't interest me that much