<vagrantc>acrow: not sure what you mean, debian actually includes all sources in their own archive <acrow>vagrantc: yes, but I'm puzzled as to how I put that archive into a guix origin declaration. <acrow>vagrantc: I've been trying to find the upstream but doesn't appear to openly available. <acrow>vagrantc: seems like maybe guix contains something like (deb-src "http...")? <rekado>why does the script generated by ’guix system container’ need to be run as root? <rekado>initialize-user-namespace messes with /proc/PID; did this work without root permissions before? <acrow>rekado: maybe home container is what you want? <acrow>vagrantc: maybe I need to explore the dak. <rekado>acrow: home container doesn’t answer the question why system container requires root. <rekado>the code seems to indicate that it should be able to run as another user <rekado>(it checks for (zero? uid) for parts of the work) <acrow>rekado: guix depends on the guix-daemon to proxy most of the its rootless magic but it can't do that for root-containers, which system container are. system requires root to change, but home makes due with lesser privs to do things. <acrow>rekado: I think you are correct but/and home is the place to do that because otherwise you leave out people using guix on foreign distros. <civodul`>rekado: 'guix system container' needs to be able to use several UIDs ***civodul` is now known as civodul
<acrow>rekado: I think it makes sense. I also don't believe that using home container requires that you do a guix home installation. that's a separate thing. <civodul>in theory i believe we could work around that with "subuids" (subordinate UIDs) <vagrantc>acrow: the debian repositories are just web sites like any other ... so i'm not sure what you're actually asking about <vagrantc>atka: got the honeycomb building several packages in parallel and drawing probably < 15W <vagrantc>atka: although i don't have a watt meter on it specifically ... but my whole system appears to be drawing under 14-18W including a few other things <atka>vagrantc: thanks for the update, that is great news <vagrantc>atka: oops ... that's whole system under 118W ... <vagrantc>atka: nevermind, it's probably still 20-30W <vagrantc>atka: i'll try to get a more accurate reading on it sometime <atka>vagrantc: ah, no problem, do the sfp interfaces eat much power? are they even enabled in your testing? <vagrantc>atka: not using them ... no idea if they're enabled <atka>vagrantc: ok, I wonder if they need blobs or not <atka>vagrantc: any chance you can paste lscpu output sometime? <whereiseveryone>hi, if anyone finds the time to review and merge these it would be much appreciated: <whereiseveryone>They are all emacs packages except for one which is a common lisp package <vagrantc>atka: i haven't been able to get the ethernet to work, so just using usb thingy <vagrantc>atka: there are several honeycombs in the two guix build farms i think, so they might know more about bloblessness <vagrantc>i think rekado and cbaines set them up, maybe others <atka>ive talked to rekado_ about it in the past but don't think we came to a conclusion <atka>they are visible but no one has sfp hardware to test with :/ <atka>vagrantc: can you tell if it downclocks when idle? <atka>I see the stepping but no frequency ranges <vagrantc>atka: not sure how to tell ... cpufreq-info doesn't say much <vagrantc>atka: but it's also possible that it needs different kernel build <atka>if powertop will run, you can get the info there, or cat /sys/devices/system/cpu/cpu*/cpufreq/etc *vagrantc -> apt install guix <atka>huh, yeah, lscpu seems to be missing a bunch too <atka>bogoMIPS is incorrect etc <atka>well it would be different if the clocks were reported no? <vagrantc>it seemed a little faster than building u-boot on my pinebook pro ... but those builds don't parallelize all that well <atka>shouldn't it be significantly faster than the pbp, like two or 3 times? <vagrantc>uh-oh. the guix debian package is very borkened. <atka>yeah I dunno if it scales linearly or if theres overhead, do the little cores not do anything on the pbp for compiling? <atka>I thought the same with my laptop vs server compiling the kernel and was a bit disappointed <vagrantc>u-boot doesn't parallelize much, so it's not surprising <atka>4 2.8ghz skylake cores vs 16 zen2 cores at 4.5 ghz and it was 60 minutes and 20 minutes respectively <atka>*mobile skylake cores that is <atka>thought zen would be faster <atka>just applied the retbleed mitigations to the server, interested to see how much performance I lose :( <vagrantc>might just need to be rebuilt with all the current dependencies ... but ... that will be hard to track in debian :/ <atka>doesn't sound fun, are you going to tackle it? <vagrantc>also, haven;t much tested the non-x86 packages ... so ... who knows, maybe it was always broken <atka>sad day for solar today, 14w :/ ***lukedashjr is now known as luke-jr
***cedb is now known as yeet
***xMopxx is now known as xMopx
<apteryx>phew, tested that XDMCP works in lightdm (it didn't in GDM) ***regtur_ is now known as regtur
<aadcg>is it possible to write to a file on an origin snippet? <klm>how can I list the files installed by a package? the `pacman -Ql` equivalent <klm>and is there also a `pkgfile` quivalent? If I'd like to find which package contains a file without installing anything <unmatched-paren>atka: I'm pretty sure all the debian sources are on salsa.debian.org, aren't they? <unmatched-paren>it's just a matter of figuring out which team it goes under, then git-fetching from there <atka>unmatched-paren: sorry, are you replying to the correct person? <atka>unmatched-paren: don't think so <atka>unless I've lost my mind <nerthus>one day you will find that paren that matches and it'll be ok <unmatched-paren>Okay, then: acrow: Aren't all the debian sources on their gitlab instance at salsa? <unmatched-paren>klm: I don't know why i didn't realize that replace would have been correct before :P <klm>unmatched-paren: oh, and `guix build`, interesting. I'm starting to understand how it all fits together. <unmatched-paren>klm: Is there any part of that package that doesn't make sense to you, or are you able to figure out what each part does by looking at it? <unmatched-paren>(Also, you might want to run `guix style -f` on that Scheme file; it goes a bit far to the right :P <klm>yeah, it is very ugly. guix style - I'll keep that in mind. but how can I fix emacs to indent properly? <unmatched-paren>The dir-locals in the Guix repo fix the indentation of Guix's special forms <unmatched-paren>(The indentation is weird because Guix adds a lot of macros and syntax extensions, but Emacs doesn't know that they're syntax, so it just indents them like procedures) <klm>dir-locals, I'll give it a try. do I put it in my ~/.config where config.scm lives? <unmatched-paren>The dir-locals.el is an Emacs script that runs when you're working in the Guix repo <klm>but if my config.scm uses the same setup, shouldn't I copy it? <klm>I don't suppose geiser can help with this? I think I'm completely confused. <klm>I need to look into a proper Emacs setup for guix, it's really looking like it's a keeper <klm>I'm enjoying this. I'm surprised of the consequences of it "just" being deterministic build system - it changes the game completely! <unmatched-paren>Well, the Nix design is very elegant :) And it allows us to support more than just package builds, of course. <klm>how much from Nix does guix use? Everything but the DSL or is guix mostly taking ideas from Nix? <unmatched-paren>Well, the Guix daemon *is* literally a very old fork of the Nix daemon <unmatched-paren>there have been some efforts to write an original version in Scheme, though that hasn't gone anywhere <unmatched-paren>(nix-daemon is written in C++, so I understand why rewriting it would be desirable :P) <unmatched-paren>but Guix has more abstractions, a better DSL, and generally better ways of doing things imo *iyzsong tried port guix-daemon to guile, but it seems too much for he :) <klm>iyzsong: credit for the effort! <unmatched-paren>'Code Staging in GNU Guix' is very helpful for figuring out how gexps work <civodul>efraim: re lint-hidden-cve, could you add comments as to why they're appropriate? (for our future selves) <klm>unmatched-paren: will read, thanks! <unmatched-paren>klm: I think the first one and the code staging one are essential, the others probably aren't that useful for a casual guix user, most likely <klm>My ambition is to replace the "archlinux rescue disk" USB-disk that I always carry with my own desktop setup. It feels that's a good use-case for guix. Is it? <unmatched-paren>Guix allows you to regenerate your system from nothing but a config.scm, so maybe <unmatched-paren>(It's especially nice if you're using Guix Home too, because then you can regenerate most of /home :)) <unmatched-paren>It's a system for managing your dotfiles and user packages declaratively <rekado_>civodul: guile-netlink sadly doesn’t yet support bridge networks AFAICS. And unfortunately I’ve got a whole herd of yaks lined up before I could take care of this one. <klm>oh, so `guix home` is for things that don't belong in `guix reconfigure`? I was wondering about that. <unmatched-paren>klm: Yes, `guix home reconfigure` is like `sudo guix system reconfigure` but for $HOME instead of / <unmatched-paren>actually this is a bit outdated, because i haven't pushed my recent changes <klm>oooh nice, that makes sense. It's a nice way to put it - could it belong in the official documentation? <unmatched-paren>Instead of using `guix package ...` to mutate your profile, you remake it every time you reconfigure (like with guix system <klm>I've been looking around for other people's config.scm's, but duckduckgo.com clearly doesn't scrape sr.ht as much as github. I suspect not all of them are perfect <unmatched-paren>I've actually got 0 packages in my ~/.guix-profile, they're all in ~/.guix-home :) <unmatched-paren>you can do pretty advanced things with it, for example that %waybar-config <unmatched-paren>it's like an invocation of (local-file ...) to fetch a local file and put it in the store, but it uses a computed-file to first remove all the comments from the file <klm>unmatched-paren: you're also a fan of fish? :-) I can't live without the implicit C-r anymore <unmatched-paren>because i wanted to be able to write comments in it, but json doesn't support comments obviously :) <unmatched-paren>though you will need to install guixrus first, I'm not sure how to bootstrap that <unmatched-paren>maybe i could do something fancy to fetch guixrus and temporarily add it to the load-path if it isn't already installed <civodul>rekado_: oh too bad, i was pretty sure it supports bridges <klm>this is great, lots of inspiration! <klm>I'm confused, isn't guixrus just a channel? And you specified to use it in channels.scm <klm>ah, so channels.scm must also be installed by guix system? <klm>I don't quite follow, but I will look around your conf repo and I might at some point <unmatched-paren>The channels.scm simply tells guix pull which channels to fetch, so root isn't needed for it <antipode>acrow: Take for example the 'hello' package in Debian: <antipode>There is a link 'Download Source Package' <antipode>Those are URIs that can be added to the 'uri' field of 'origin' <antipode>WDYM with "Guix Home installs channels.scm"? <antipode>It hasn't overwritten my ~/.config/guix/channels.scm. <antipode>O you probably meant the home.scm in your git repository does that <pkill9>was any more work done on making wrappers for packages? <rekado_>nsenter segfaults when trying to enter a Guix container’s mount namespace :-/ *civodul reconfigures grunewald & pankow <civodul>i can't log in on kreuzberg, something about expired password ***califax_ is now known as califax
<rekado_>“guix container exec” executes also in the “user” namespace, so it’s not quite the same thing. <rekado_>also inconvenient: the generated container script does not accept “--share” or “--expose” options, so it is necessary to build a different script for every container that wants to mount a different location. <rekado_>so I can’t generate a container once and reuse it with different directories <civodul>being able to use subuids instead of running as root would be a significant improvement, too <kabouik>Has anyone tried Guix System on a GPD Pocket 3 ? I don't know much about GPD, initially the brand is mostly focused on gaming so I don't expect much from them regarding Linux support, let alone Libre (I WLAN won't work with Libre on the Pocket 3). However it seems that more and more people are using them with Linux now, especially the device line that's more focused towards IT than gaming (Micro PC, Pocket 1, 2 and 3) <atka>kabouik: shouldn't be any show stoppers with that hardware, I think linux runs on a few of their computers <atka>not sure if the intel xe graphics need blobs for some hardware acceleration or encode/decode though <atka>but yeah wlan bt aren't going to work, but that's true of pretty much everything since 2012ish <atka>kabouik: a peek around their forums may give some insight to linux distros people have tried <Xe>also you think you have it bad, you don't have a nick that's the same as a GPU that causes people grief lol <unmatched-paren>I'll make sure not to write it with a capital in the future, sorry :) <Xe>don't worry, my IRC client is case insensitive for ping matching <Xe>i've gotten used to it lol <Xe>though hilariously sometimes my nick collides with someone's pronouns <gerbil|42>Hi, I've just installed Guix from latest (https://ci.guix.gnu.org/927) and after single guix system reconfigure and one restart later I receive "unsupported manifest format" on every attempt to run either guix pull or guix system *whatever* commands, which means I'm pretty much stuck. <unmatched-paren>gerbil|42: Yep, known and fixed, but requires manual intervention iirc <Xe>unmatched-paren: no, that's not my name <gerbil|42>unmatched-paren: nice, my google-fu did not find this one. will try. thanks! <Xe>unmatched-paren: however I have a pretty great understanding of common Intel Xe issues! <atka>unmatched-paren: do you know if 12th gen X_E needs blobs? *unmatched-paren is really hoping it doesn't because they're planning to get a 12th gen framework laptop :/ <atka>that's strange, there needs to be a database somewhere with this info <atka>I have heard all intel igpu since skylake have blobs <atka>and you are the second person to say 11th gen doesn't, but I heard 12th gen does.. <atka>I was thinking of the frameworks as well <atka>it they don't need blobs would that make the X_E the most powerful libre gpu? <unmatched-paren>maybe we could look at the linux-libre scripts and see whether they remove 12th gen xe firmware? <Xe>atka: you don't have to adapt your writing for my sake <atka>unmatched-paren: that's a good idea <Xe>unmatched-paren: maybe search for "alchemist", "arc", or "iris"? <atka>that would be nice, theres some decent hardware out there with those chips <atka>yeah I see lots of i915 stuff unfortunately <unmatched-paren>atka: Hmm, interesting. I have Comet Lake, but my integrated GPU works fine. <atka>i think its only some features <atka>I have skylake but i've never gamed or anything with it <atka>what does sysctl dev.i915.perf_stream_paranoid=0 return? <unmatched-paren>Now it just returns 0, which I presume is why you didn't want me to write =0... <atka>I think its when the driver is loaded early in the boot process it isn't fully ready <atka>so starts in paranoid mode <atka>steam will complain in the cli <atka>and recommend setting it to zero <atka>thats how I discovered it <atka>MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0 <atka>that is what it says if it is set to one <unmatched-paren>Wait, if it's recommending that you run `sysctl dev.i915.perf_stream_paranoid=0`, doesn't that mean it *does* set it? <atka>On boot, the i915 kernal module enables the paranoid performance collection mode by default. To use the VK_INTEL_performance_query extension, this paranoid mode must be disabled. <atka>yes but you need sudo to set it <atka>I have it in my kernel arguments to set to zero every boot personally <atka>it disables a vulkan performance extension as I state above <atka>how much that matters I do not know <unmatched-paren>Ah, yeah. I skimmed over that part because I was too worried about "Uhm, I did use sudo :(" :) I'm very paranoid about modifying things like that :P <atka>eh all those sysctl commands get reset at reboot <atka>sysctl dev.unmatched-paren.perf_stream_paranoid=0 <atka>there now you aren't paranoid anymore <atka>and crap, i've done it again <atka>the sun is rising and I haven't slept :'( <unmatched-paren>Though if you're okay with steam, why not just use normal linux, which presumably will fix this? <atka>vanilla kernel does it too <atka>but you may be leaving some performance on the table with some vulkan applications <atka>but its easy enough to rectify <atka>unmatched-paren: As of January 29th, 2020, their implementation/patches are now in kernel 5.5, and the Mesa branches in 20.0 and 19.3. The VK_INTEL_performance_query extension is designed specifically for 8th generation or newer Intel GPUs including Broadwell, Skylake, Kaby Lake and Coffee Lake. <atka> Intel's Vulkan VK_INTEL_performance_query extension which was first published in the Khronos VulkanDocs repository as part of the 1.1.109 specification. <atka>if you want to know more <unmatched-paren>atka: So, conclusion, 12th gen Xe graphics are no worse than Skylake :) <atka>unmatched-paren: you've gone and pinged em again :) <acrow>antipode: Thanks. Finding a good origin is pivotal. :) <Cairn>This thread (https://issues.guix.gnu.org/57052) has flipped into being a suggestion for changing the default value of `handle-lid-switch-external-power` to "suspend". How much consensus would be needed to get this change committed? ***yeet is now known as cedb
<apteryx>Cairn: as i mentioned in the thread, it was discussed a bit in the past; I think we have consensus to change it but it's good to check! lilyp nckx any opinion? <Cairn>apteryx: Are you one of the people in that thread? I'm still trying to learn names <podiki[m]>that sounds like a good change to me, fits the default I've always experienced <podiki[m]>we should aim for "not surprising" and I think having a laptop stay on with the lid closed is "surprising" <Cairn>I was definitely surprised by it, as well as someone else in the thread <unmatched-paren>There's also a Maxime, which could be a little confusing if you don't know about it :) <Cairn>Thanks for letting me know =) <dominicm>when I try to do a minor version bump on a rust app and slowly realize I have to add/update like 50 packages :( <shcv[m]>it would also be nice if it was a little clearer how to prevent suspension when using %desktop-services; I made a server once that I wanted to be able to log into graphically, but then it would go to sleep if nobody had logged in (and it wasn't clear how to fix that) <unmatched-paren>Although it gets worse: "when I try to package a text user interface that sends json messages to a socket and realize it depends on multiple web frameworks that haven't been packaged yet" <shcv[m]>still probably a pain though, since you'd have to apply the patched definitions in the right places <dominicm>shcv: yes, but it seems to still spit out existing packages, plus you have to put all the packages in the right place and create duplicate packages for different versions when appropriate <unmatched-paren>And you still have to fix up any idiosyncracies in the imported packages: fix descriptions, remove bundled stuff, etc <podiki[m]>not sure about specific importers, but generally it should know when guix has a package and not write a new definition...unfortunately for rust usually does need a new version, and sometimes see it not pick up packages that have different names <unmatched-paren>Also, sometimes the version specs in a Cargo.toml are stricter than semver. <podiki[m]>I've used guix import -r to import hundreds of lines of code and it "just worked", not always, but saves so much work <unmatched-paren>So you have serde 1.0.89 or something, and the package you just imported needs 1.0.92 <podiki[m]>usually spend more time on synopsis/description/license checks than actual codeing :-P <unmatched-paren>You also have to check every single package for stupidity like bundling of libraries in -sys crates <dominicm>It would be nice if there was some combo refresh/import since a lot of that back-and-forth seems it could be automated, but I don't know how feasible that is because the updaters aren't specific to the build system ***Noisytoot_ is now known as Noisytoot
<trevdev>I have done something stupid(TM) and I can't see where. I can't evaluate this module in the REPL. It seems to have lost the lexical scope and can't find the binding for the funciton "list": https://paste.debian.net/1249825/ <trevdev>Always when I make an IRC post I see it <trevdev>Nope I don't see it. I think I need a break. Help? <shcv[m]>am I correct in my understanding that `guix system image` doesn't support btrfs yet? <unmatched-paren>this is a macro, the arguments aren't evaluated unless the macro decides to <shcv[m]>it looks like it only generates fat and ext* partitions <trevdev>guile -L $(pwd) -l tdev/packages.scm -> error: git:send-email: unknown package. I struggle to recall the last time I was so happy to see some other error <trevdev>Would (use-package-modules) work in the context of a home config? <unmatched-paren>It's just a macro that expands to (use-modules (gnu packages PKG-MODULE) ...) <trevdev>Ok...I think I even understand my blunder now. By exporting list I am overwriting the lexical binding of list? <trevdev>Or perhaps in the #:export form, the lexical scope is sanitary? <trevdev>Reason I wonder is it said list was unbound at 37:3 which is the first in-body application of list <trevdev>They are funky and not-at-all ambiguous at times ;) <trevdev>Gotta remember to always look *before* the supposed problem <nckx>Wish that even that were consistently true. <nckx>trevdev: Protip to make it seem like you know the IRC when you're really just scraping by (ahem): Most clients let you type //foo to echo /foo. <nckx>apteryx: Is there a way to search by message ID through the Web interface? I thought someone added that but it wasn't documented. <nckx>I'm still without a local mailbox. <nckx>I have no idea what I wrote in the past, but I'm roundly in favour of using something similar to your *undefined* adventure, however it ended. <nckx>This was just a limitation of Guix service writing that made it convenient to hard-code ‘defaults’ even when that's a bad idea, it's not a feature. <nckx>Hope that's a strong enough opinion™ for you :) <unmatched-paren>problem: to properly unvendor a C library from a Rust library, you need to use a snippet, because otherwise you have to reapply that change for every dependency <unmatched-paren>but i just read ludo saying that the output of guix build --source should be platform-independent :( <unmatched-paren>which is not possible if the snippet gexp references a package's output path <unmatched-paren>s/for every dependency/in the phases of every dependent (due to cargo-build-system being cargo-build-system)/ <nckx>It needn't. Think of it as: if upstream had properly written their package not to bundle C libraries, what would it do? Not hard-code the library's location! <nckx>They'd have used a variable or pkg-config. Adding pkg-config support in a snippet is overkill, but you can patch it to use a variable, which is then set to the proper output location later. <nckx>It really can't link properly? <nckx>That's general advice, I'm assuming there's nothing particularly nasty about c-b-s that makes it impossible here, but I'm always ready to be disappointed by Cargo. <nckx>Why would it need the source of a different library at build time, unless the library is meant to be embedded? <nckx>Packages don't build their dependencies from source. <nckx>But I don't wanna behold. <Cairn>Hey nckx! Back on that PATH issue again. Seems like the Getting Started part of the manual isn't very clear about local packages and the PATH. It pretty says "if you're on Guix system, don't worry about it." But it *does* say to add those recommended PATH lines to your .bashrc if Guix mentions them. I think that portion needs to be written more clearly to convey that Guix System will take care of it, even if it means you need to log out first <Cairn>Is it possible to submit edits to the manual as "patches" or something? I could try to do that later today <nckx>Of course cmake is a monad(???) in Rust. <nckx>Or am I misreading that pattern. <nckx>Cairn: The manual is maintained in guix.git, any edits are just packages; see ‘git log doc/guix.texi’. <Cairn>nckx: So it's cool to submit changes then. Great, I'll have to learn how to do that, thank you. =) <nckx>It reminded me (superficially) of how I/O monads tend to work. <nckx>Probably a good sign of your sanity? <unmatched-paren>IO is just a wrapper that means 'the type in here is evil and bad because it came from an impure function'. <nckx>Cairn: If you already know the Guix patch workflow, you're good to go, and if you don't you'll be learning skills that apply to all of Guix, so also good. <Cairn>Yeah, it'll be fun to learn! <lilyp>apteryx: I think we should use the unspecified trick to fill in defaults, cheers <nckx>unmatched-paren: Wait a sec, you sound like you have opinions™ about I/O monads and you might not be teaching me 100% objective truths™. <unmatched-paren>I see how you could interpret "evil and bad" that way, it sounds a little sarcastic in retrospect :) <nckx>Cairn: Can you link me to the place where it says to add those recommended PATH lines to your .bashrc if Guix mentions them? <unmatched-paren>Anyway, yeah, some monster either implemented CMake in Rust or wrapped the executable in a Rust library. <Cairn>It says something like "unless you're using Guix System, these lines will show up" <nckx>unmatched-paren: Anyway: ‘.define("BUILD_SHARED_LIBS", "TRUE")’ — aargh. <Cairn>But it's unclear about what to do when those lines show up when using Guix System <Cairn>Prone to causing confusion, and clearly worth rephrasing <nckx>Cairn: Got it. I was searching for ‘bashrc’ specifically. <nckx>Cairn: Yes, the unless is too far away from the end of the long description of something you shouldn't do. <Cairn>Oh yeah, I guess it says bash_profile <nckx>Yeah, .bashrc would be terribly wrong, hence my worry. <nckx>.bash_profile is merely not needed on Guix System, but not fundamentally insane anywhere. <nckx>(It {c,w}ould basically break ‘guix shell’ for one, hence why it grew a ‘--check’ option.) <nckx>But I digress, sorry. Please do edit it to be more clear, commit it using our style of commit message (‘git log’ will help you with that), and git send-email -1 --to=guix-patches@ it for review. <nckx>There's a Web site that helps you set up git send-email, I think it's git-send-email.io, but you can use your own MUA if you prefer. <nckx>I've saved you time, send me bitcoin. *nckx conversely has never tried git send-email HEAD~N, assumes it works too. <unmatched-paren>I don't know why it requires you to use HEAD^ instead of just HEAD, it just does -.o.- <nckx>HEAD would be -0 in its mind. <nckx>It is (at least on the surface) strange that it's exclusive. <lostleonardo>Hi, noob here. I am trying to package the latest version of dwl. I have figured out how to use the --with-source flag to build/install with the new source code, but the latest version of the software also requires a new version of an input (wlroots specifically) and the new version of wlroots requires a new version of wayland... I've not followed <lostleonardo>the chain any further than that as I'm not sure how to go about making an alternative package input available to another package build. Would anybody be able to point me towards an example of how to create multiple package alternatives, which depend one on the other? <unmatched-paren>I guess SPEC in `git send-email SPEC` means 'everything after this ref'. <Cairn>nckx: Sweet, thanks. I do know about some of git send-mail, since I use sourcehut. But I'm very new so I'll be sure to review everything <nckx>You're right that writing HEAD^ not sending HEAD^ but HEAD is weird, I'd never questioned that. <nckx>Another reason to use -N IMO. <Cairn>Is there a way to add an output to a package list in my config? <nckx>substitute: In procedure write_wait_fd: unimplemented <nckx>Which returns multiple values which can be hard to handle if you're not familiar with those (and sometimes even if you are). <Cairn>Sorry I'm not quite sure what that looks like unmatched-paren <nckx>Can you also not write (list foo `(bar ,"junk") baz) ? <nckx>Which is what I use in my configurations 🤷 <unmatched-paren>Me too, but most people seem to use specification->package in my experience <Cairn>Is one of your configs public, so I could check out examples? <unmatched-paren>I love how I can just regenerate most of what matters on my system from a single git repo. <Cairn>I'm excited to get to that point too =) <Cairn>What does the package "senpai" unmatched-paren? <unmatched-paren>I've sent a patch for it to the mailing list but it hasn't been merged yet <Cairn>Well gosh, that manifesto's pretty fancy. What's that all about? <Cairn>Nice. That's fun, maybe I'll grab some packages from it some time soon <apteryx>nckx: I have no clue myself homw to use message IDs, but since seems to do, I thought I'd share it ;-) <vagrantc>notmuch search id:messageid works for me! <nckx>Sure, I know how to do so with a local MUA, but I think support for it was recently(?) added to Mumi as well. <nckx>vagrantc: No have working mu4e ATM ☹ <apteryx>surely, Gnus can do that too? I haven't stumbled on such feature yet though. <nckx>Maybe I should just, y'know, paste the message ID into the box and see what oozes out. <nckx>Works perfectly once you remember how to copy & paste. <teddd>Hi guix! Is there a way to add channels modules to GUILE_LOAD_PATH? It seems guix pull is not doing that, right? <jpoiret>back from the holidays (gradually though) <jpoiret>nckx, apteryx: you can use msgid:<id> <apteryx>jpoiret: msgid as in M-x msgid? from which buffer does that work <jab>jpoiret: I use gnus for mailing lists...that's about it. I find it's interface difficult to use... <jpoiret>public-inbox is pretty useful for the MLs that have such instances <teddd>jpoiret: I would like to play around with the code of some modules in a channel. Guess I'll just git clone it and add it to my GUILE_LOAD_PATH. But somehow I have the impression it would be nie to have it at least in guix repl. I mean sometimes I just want to have the exact same environment that package definitions would have at runtime. It's a bit clumsy to have to do things manually <shcv[m]>is "service" the best abstraction / interface to use for `guix home` configuration setup? Because a lot of configuration (e.g. setting up global git configs) are a one-time thing that I wouldn't usually think of as a "service" <shcv[m]>and if not, what other options are there? Or should we make a new one specifically for profile construction purposes? <teddd>shcv[m]: Services are not necesserally daemons running in the background. They are not to be confused with shephered services. For the purpose of creating config files with guix home I can recommend using home-files-service-type <jpoiret>teddd: you can use -L for most guix commands <jpoiret>i'm not sure whether it works with guix repl, but for the others it works fine <teddd>jpoiret: Ah yes that would be better. Thanks <yewscion>Can someone point me to an example of a source-only definition? <unmatched-paren>yewscion: If you just need a source-only package as an input for others, you can just use a standalone (origin ...) <nckx>jpoiret: Welcome back by the way. *unmatched-paren testing lilyp's emacs-build-system native-comp patches <yewscion>unmatched-paren: Would that end up being something like (define pkg-symbol (origin …))? Or is there something I'm missing there? Guix seems to not know what to do with such a definition as an input. <nckx>Why do you want it to be a package? Guix handles origins as inputs just fine; what to ‘do’ with it is your responsibility. <nckx>Turning sources into packages is usually (if not necessarily) a mistake. <yewscion>unmatched-paren: nckx: Ohhhhhhhhhh, I hadn't realized I could just pass the origin to the inputs. I was trying to add it to the package's source field. <nckx>No, a package can have only 1 ‘source’, all extras need to be (native- by the way) inputs. <nckx>It's not. The limitation is somewhat artificial. It's just that everything as it currently is (guix build --source, package-source, etc.) assumes 1 source. <nckx>= It's not: a weird question. <nckx>I think git has its man pages in a separate tarball for example. <nckx>If you want a simple example. <unmatched-paren>Btw, to reference the origin without a label, you can probably use search-input-file <yewscion>nckx: unmatched-pared: I see, that makes sense. I'll check out the git manpages, then. And that was the follow-up I was about to ask, about referencing it, haha! You beat me to it. <nckx>I am almost 100% certain that the git package still uses labels. <nckx>unmatched's trick is conceptually ugly (I don't think there's one that isn't) but should work. <unmatched-paren>It also means you don't have to provide the origin as an input, i think. <yewscion>It's less characters, but I'm not familiar enough with gexps to know if it is dangerous at all. <unmatched-paren>yewscion: The `inputs` in (lambda* (#:key inputs #:allow-other-keys) ...) is just an alist of labels consed to the result of building the input gexp. <nckx>Side quest(ion): would #+ be the right thing to use in such cases? I'm not always 100% sure about the subtleties (if any). <unmatched-paren>Anything that's usually a native-input should be ungexped natively, I think. <nckx>That was my understanding too. <yewscion>unmatched-paren: Ahh, okay, I didn't know inputs was built that way. <yewscion>nckx: unmatched-paren: Will do, I hadn't learned #+ yet, thanks for letting me know! <nckx>Strictly speaking the alist is no{t, longer} API. You shouldn't rely on it, if possible and mosty you don't need to. <nckx>Not that it's going anywhere fast. <yewscion>Copy that, yeah. I don't want to use it so much as it helps me understand the code I'm writing a bit better. <unmatched-paren>nckx: Really? I thought search-input-file was just an additional useful API, but is the alist actually deprecated? <nckx>It's definitely deprecated. <nckx>search-input-file isn't the only abstraction. <nckx>Whether it will ever actually go away, I can't say. <nckx>TBC, we don't have a nice abstraction (yet) for everything the alist was good (or OK) at. Like: the ‘problem’ with using a gexp here means you can't use package transformations to pass a different source. It will always use that exact variable. Not a huge problem, but it's there. <nckx>As implemented? Yes. But I don't think they expose that fact? <nckx>I think ‘deprecated wherever it's not strictly needed, with the intention to expand the abstractions to cover all old alist use cases’ is the more accurate if verbose summary. But that implies more of a roadmap than their really is, so there's some of my own opinion in that :) <nckx>Their. Bad nckx. Bed time. 'night! <apteryx>where is the background used for GDM defined? <ordoflammae>Is there a way to make it so that the user-defined xsession is just another entry in the window manager, instead of overriding everything else?