IRC channel logs
2025-02-04.log
back to list of logs
<orahcio>Hi, somebody can help with `(substitute*` on modifying-phases, I want to use a guix path from /gnu/store, how to use (string-append) or (file-append packagename ...) inside that? <eikcaz>nomike: basically, start small and add useful things from whatever cool config (Danny's in this case), as opposed to starting with a cool config and shrinking it down <mange>orahcio: Can you put what you currently have in a paste? <podiki>orahcio: the store path for a package is #$package though often you want helpers like search-input-file <nomike>eikcaz, for the moment, what I'm doing feels fine. What boggles me at the moment is that when I run `guix home --debug=4 -L "${PWD}" reconfigure home-config.scm` the first line it prints is "guix home: warning: unknown keyword or bad argument" and no matter how much I crank up the loglevel, I wasn't able to get out any more information. Like where and what keyword or argument it is complaining about. <orahcio>podiki: I can use just #$package on a function like (string-append? <podiki>looks like you have an extra #~ inside and #~ <eikcaz>nomike: hmm, should there be a space between "-L" and "${PWD}"? <mange>Yeah, I think you either want (string-append #$pixman "/include/pixman-1"), or #$(file-append pixman "/include/pixman-1"). The extra #~ is not needed (and breaks things). <podiki>orahcio: probably better to use somthing like (string-append #$(this-package-input "pixman) "/include/pixman-1)) <podiki>err "pixman" and "/include/pixman-1" <mange>But also, doesn't substitute* need to be different? I haven' used it for a while, but isn't it more like (substitute* path ((pattern args...) replacement))? <eikcaz>nomike: nvm, space should be fine <orahcio>nice podiki and mange, I will try. Thanks! <podiki>those are some things you can search for too in guix packages to see lots of examples of exactly what you are doing <eikcaz>nomike: does it complain without the debug flag? <podiki>yes, also what mange said about substitute* <orahcio>mange: I could see a error to find pixman.h header, after gcc -I/usr/include/pixman-1, I think I need to change this part on one file <nomike>eikcaz, yes, it also complains without the debug flag. In fact, it works and runs fine, after all it's just a warning, but I would still like to learn how to debug stuff like this and I want to figure out where that warning is coming from because it's obviously a bug in my config. <elevenkb>Hey does someone have a guix offload service that you can pay for? <elevenkb>My home environment takes a while to build because: <elevenkb>2. I have to build waybar and typst from source. <elevenkb>I think mostly typst is the problem, I could try to propose it for upstream as well. <orahcio>mange, podiki: I could to build with the correct syntax of (substitute*, now the 'check phase fails, but a victory at a time :) <eikcaz>nomike, The only way I know of to debug that is to start with a config that doesn't complain, and build up, hence my original suggestion. <nomike>Hmmm...then I will file a bug report, because that warning is completely useless then and there should be a way to get a proper warning. Danny (@daym:oxide.computer), a friend of mine who is also a developer at the guix project, mentioned that one of the devs is especially keen to hear about issues newbies face. But I can't remember the name of the person Danny mentioned. <mange>The problem is that "unknown keyword or bad argument" sounds more like it's coming from Guile than from Guix. One consequence of the way Guix handles its configuration is that you're writing a program in Guile. If you Guile program has a problem, then that's not really a bug in Guix - it's a bug in your program/configuration. <mange>FWIW, I don't get that message when I reconfigure my home. If you're going to raise a bug, it would be most helpful if you can cut your failing case down to a minimal input that will provoke the issue. Otherwise it's really hard to investigate what's going on. <nomike>mange, of course I will have to try to condense it to a simplified example. <nomike>mange, and I get what you're saying about guile. I assumed, that there is an error in my scheme files somewhere. What I consider to be the "bug" is, that I guess either guile is producing a more detailed error message, which is then swallowed by guix, or that guile needs some additional parameter (e.g. `--debug`) to produce a proper error message, but guix is not properly adding this when you crank up it's loglevel. <eikcaz>Hi Guix. Would someone mind reviewing my patch that adds the ability to configure syncthing? <eikcaz>(I see others make such a request. I assume it's ok to request that here) <eikcaz>My first submission had an incorrect commit message, hence the bad subject, so see my second patch. <eikcaz>The patch includes strategic and limited use of camelCase. I think this patch constitutes a genuine exception to the no-camelcase rule, but do tell me if you think otherwise. <PuercoPop>guix pull -l list a commit as current that doesn't match the commit listed by guix describe. Is that expected? <PuercoPop>Ok, it seems that the reason is that I don't have ~/.config/guix/bin in user's path so it uses /run/current-system/profile/bin/guix instead <lfam>It makes sense that would be the cause, PuercoPop, but something is wrong to break your $PATH like that <lfam>eikcaz: So, this adds a Scheme interface to configuring Syncthing, basically? <orahcio>eikcaz: Hello, qtile finally can be built, but wayland backend not run, I could to package a version with wayland bakend <eikcaz>It adds a syncthing-cofig-file to syncthing-configuration that can be a file-like object or a (syncthing-config-file) record <lfam>I'm familiar with Syncthing, so I think I can review this <lfam>Do you have time to chat about it now? <lfam>Does it keep what we might call an "escape hatch" where you can still use the Syncthing service without using the Scheme configuration interface? <eikcaz>yes, if syncthing-config-file is #f (the default) then no config file is generated <lfam>So, what's the workflow for the first time you use it? I'm a little confused because, as you point out, it doesn't have a local device ID yet. How does that get sorted out? <eikcaz>Syncthing automatically adds the device at runtime, after reading the config, so it is no issue <lfam>So, Guix creates an XML config file, and runs Syncthing with a reference to the config file. Then, Syncthing automatically generates the keys / ID for the local device, and just keeps them in memory without a <device> block for the local machine ever being added to the config? <lfam>I mean, I assume the keys are persisted on disk, but Syncthing can, like, concatenative the effective configuration at run-time? <eikcaz>yes, it creates some .pem files in the same directory as the config.xml if they are not discovered. <lfam>I see, I'll just assume that directory is writable for now. I'm sure you've tested this <lfam>Can you share a reference to the Syncthing docs that say "The default ~/Sync folder normally includes the current device. The documentaiton makes it clear that this is OK". It will be helpful to include this as a code comment or something <eikcaz>yes, syncthing needs a writable directory to put the .pem files in, which is independent of my patch <Deltafire>eikcaz: "..since I know ~/Sync works.." - does this work if syncthing is run as a different user? <lfam>These questions are kind of preliminary. I will of course look deeper on my own. But it helps <eikcaz>Deltafire: yes it works because $HOME is explicitly set in the syncthnig-shepherd-service based on the user <lfam>I also wonder about "There were a few undocumented behaviors around the absense or presense of a value." As a general issue, there is something gained and something lost when we make these Scheme abstractions for configuration of external programs. You know what is gained. I'll say the loss is that it makes it harder to report bugs upstream and sometimes makes upstream a little mad at us <lfam>Our user could have a bug, and the upstream response would be, basically, "Don't do that." <lfam>Thanks eikcaz, I'll add it to the ticket <eikcaz>lfam: I think this only happened once, and I think it was with folder versioning. You may notice that the configuration has a version set to 37, so later syncthing versions shouldn't break with this config <eikcaz>s/configuration/syncthnig config file/ <lfam>Okay, overall seems fine at a first glance. Except for the camel case, but that's a cosmetic issue. Are you wedded to the camel case or would you allow it to be standardized, at least the user-facing portions? <lfam>Also, have you noticed any other services that break our convention like this? <eikcaz>I haven't noticed other services. I'm not wedded to camel case, I just though it would be good to match syncthing documentation for the end user. (obviously the <record>->sxml functions need to have camel case symbols to create a valid xml) <eikcaz>If we do some translitteration between our documentation and the synching documentation, then we also have to document that camel case <-> snake case mapping <lfam>To be clear, if we were to remove the camel case, it wouldn't be snake case either, but just standard Guile <lfam>For example, encryptionPassword -> encryption-password <lfam>Well, it's not very important. We shouldn't get hung up on it <lfam>I didn't know it was called that :) <mange>FWIW, I've really come around to the idea of preserving foreign identifiers. I don't beat this drum in the Guix world much, but I think using foreign identifiers as they are is really helpful for correlating things. <mange>I think it's helpful, even just as a signal of "the semantics of this are really defined somewhere else". <mange>If the Guix service configuration is defining an actual abstraction, then I think it's proper to use kebab-case. If it's really just a pass-through to the underlying configuration file then matching the precise name is helpful (albeit it hasn't been done in Guix to date). <lfam>Personally I don't care for these Scheme configuration abstractions, but that won't stop me from reviewing and committing them <mange>That's part of why I like the direction that some of NixOS's services have moved, of just having attribute sets which are directly encoded. No special structure, just "write this thing from Nix lang into a config file". <mange>Actually, I don't know if NixOS is moving that way generally, but I've just noticed that I've had to update a few service definitions over the last little while in this sort of way. <eikcaz>lfam: fyi Syncthing will fix and overwrite any malformed config.xml as I learned from experience <lfam>That makes sense. It's not fragile at all from my own experience <eikcaz>the fact that syncthing does not clobber the symlink to /gnu/store/... alone is evidence that the config is valid <apteryx>is shepherd supposed to gracefully close services when closing my gnome session? <orahcio>Hi folks, may I send package definitions directly to bug-guix@gnu.org with no patch? <lfam>orahcio: No, please send them to guix-patches@gnu.org <orahcio>lfam: thank you to give me right way <eikcaz>lfam: do you still need me? If not, I'm off to the gym. (I will of course scour the irc logs for queries tonight) <coyotes4ys>why do i have fn button key functionality on my screen brightness in the login screen, but not once openbox (no desktop is installed) opens up? <eikcaz>This is important to me, so I'm happy to stick around if you are still working on it <wakyct>I don't know coyotes4ys, but thanks for inspiring as I never realized my fn brightness keys worked until now ;) <wakyct>but I'm on xfce so can't help you there <Mystified>hey guys, I don't run systemD based distros, I would like to test Guix om my i5-10th gen dell 5310 2in1 laptop with coffee lake i915 and ath10k_pci qualconm 6174, will I likely have driver/firmware issues ? Thanks kindly ! <lfam>sneek: later tell eikcaz: Sorry I disappeared like that! I'll do a proper review today or tomorrow and send it to the ticket. We'll get it in <lfam>Mystified: At the very least, your ath10k wifi won't work on GNU Guix, because it requires non-free firmware that's not included <lfam>Not sure about the rest of the hardware but the wifi is a classic <lfam>The CPU and the integrated graphics should work fine. Microcode isn't available in GNU Guix <lfam>I'd be curious about the 2-in-1, it might require special drivers <lfam>Yeah, ath9k was famously freed by Atheros, but it's been a long time since Atheros was in the game <lfam>They sold out to Qualcomm years ago, and there's no wifi chips invented in like the last decade that we can include firmware for <RavenJoad>Does cuirass's web interface have a known bug in it? I cannot start the web interface, but everything else seems to work. <PuercoPop>RavenJoad: check if cuirass itself is running <PuercoPop>Q: Why does cuiriass-spec need to use a gexp? <RavenJoad>PuercoPop: It looks like it is. herd status cuirass returns something useful and /var/log/cuirass.log has recent DB contention information. <PuercoPop>But #$rde-channel for example doesn't seem to work either <PuercoPop>Tried to use with-imported-modules unsuccesfully as well <apteryx>seems to have to do with wrong perms in my .cache/guile/ccache directory <apteryx>I think it has to do when reconfigure my system with sudo and using extra channels with -L <apteryx>the channels sources get auto compiled as root in my home, later cause problems. <apteryx>yep, sudo rm -fr /home/maxim/.cache/guile/ccache/3.0-LE-8-4.6 resolved the issue <Rutherther>apteryx are you using sudo with E flag? It seems strange to me it would use your cache otherwise <apteryx>yes I was, you must when you want to reconfigure via ./pre-inst-env <apteryx>sudo -E ./pre-inst-env ... -L some/channel -> boom <apteryx>non-writable cache files for your user <Rutherther>Maybe it would make sense to enter bash in pre inst env and only then sudo guix <podiki>but do you need to do that to reconfigure with pre-inst-env? i think i've just use sudo guix system reconfigure -L (other channels) config.scm and had no issues <podiki>or maybe i did use sudo -E (looking at command history) but didn't end up with cache issues i know of <apteryx>normally we shouldn't use -E, but when using ./pre-inst-env that's needed, for reasons I forget <apteryx>probably otherwise sudo filters out some used vars <Rutherther>podiki I dont think you need to end up with that, as long as new cache isnt needed. Ie if you first built the system, no need for sudo, then you could sudo E reconfigure and be fine <podiki>right, these days i tend to do a guix system build first in general <apoorv569>Can someone look at these patches I sent 6-7 months ago? 72637, 72666, 72665, 72664, 72663, 72662, 72661, 72660, 72659, 72658, 72657, 72656, 72655 and 72673. <FrenchNewbie>does anyone here has a fix to VSCodium not being able to use my polkit agent ? <FrenchNewbie>in my config.scm i added polkit, polkit-gnome and polkit-qt6 <FrenchNewbie>didn't work with any of those (tried speratly qt6 and gnome) <FrenchNewbie>i then tried to add the polkit-service-type but i either get a variable not set or multiple polkit reference <FrenchNewbie>difference between both is that i add dbus in my modules <iyzsong>apoorv569: I could look into some of them later, thanks. <FrenchNewbie>when removing polkit from modules i have variable not set for polkit but not multiple references <FrenchNewbie>polkit is added as a package module and dbus as a service modules <iyzsong>FrenchNewbie: %desktop-services already provides polkit-service-type and polkit-wheel-service, so it's not needed to add them manually. does the agent works for the normal desktop? progrems provides polkit rules should add a service-extension for 'polkit-service-type'. <iyzsong>FrenchNewbie: what error does it produce? 'pkexec' not found or dbus service? <iyzsong>FrenchNewbie: how you install vscodium? if it's flatpak, then it may lack 'pkexec' in its container. <FrenchNewbie>everything is installed throught system packages with config.scm <iyzsong>FrenchNewbie: okay, then you could report this issue to the channel provides vscodium, it should find 'pkexec' in PATH. <sneek>Welcome back civodul, you have 1 message! <civodul>hope those who were in Brussels had a good trip back :-) <FrenchNewbie>does anyone here uses remmina and activates the multi-screen option ? <FrenchNewbie>i'd like to use that option in sway but it only uses 1 monitor <FrenchNewbie>do i have to link all my monitors to one workspace or something related ? <jakef>hey civodul, i caught some of the minimal/declarative track and it was very good! i'm keeping an out eye for the recordings <civodul>jakef: hey, that track was really good overall, and with a good story around all things Guile <civodul>so next time Savannah is down, you know where to go :-) <FrenchNewbie>found that the multi-monitor feature is broken on wayland and remmina team is working on it <FrenchNewbie>can i use another location than /etc/ to reconfigure and boot on config.scm ? <hanker>> can i use another location than /etc/ to reconfigure and boot on config.scm ? <hanker>you just do `guix system reconfigure <path/to/config.scm>` <civodul>good practice is to keep that file/those files under version control <yelninei>iyzsong: Issue with libpciaccess is that hurd wants to link statically but since switching to meson only the shared lib is build (by default). For libxcb the (removed) pthread-stubs seem to be required for non linux (and also an issue with PATH_MAX) <iyzsong>yelninei: oh, I'll take a look later, thank you <csantosb>civodul: great news ! I guess codeberg mirror is a long term solution under control of guix people, not an individual <csantosb>If so, it would be great to communicate about: savannah issues are unfortunately frequent <yelninei>currently i am failing to adjust these s.t. the linux derivations are unchanged <FrenchNewbie>i edited my /etc/guix/channels.scm and /home/user/.config/guix/channels.scm <jakef>FrenchNewbie: did you guix pull after editing? <FrenchNewbie>cannot build derivation `/gnu/store/hna0v77wqvznl3nx2fyiq1dg16yaaf73-profile.drv': 1 dependencies couldn't be built <FrenchNewbie>i'm trying to add the nebula channel to install nerdfonts <iyzsong>yelninei: yes, I can build hurd and netdde with a static libpciaccess. and can't fix libxcb without cause rebuilds, and I don't know if replace PATH_MAX with sth like 4096 for hurd is a correct fix, seems we should report to libxcb's upstream. <yelninei>but not sure what to do with the PATH_MAX. Maybe janneke or civodul have a suggestion? <janneke>iyzsong: usually debian has already has a fix/patch; i always start by googling something like "debian salsa <package-name>" <iyzsong>okay, seems replace PATH_MAX with 4096 is a 'correct' fix here. <PotentialUser-22>Hello. I have an issue with building /gnu/store/j7c4im31ckq3s9k7pgd668s9x02gdhhv-python-3.10.7.drv locally. For some reason on my machine (aarch64-linux) it does not downloads from substitution. There is some test failure in /var/log/guix/drvs/j7/c4im31ckq3s9k7pgd668s9x02gdhhv-python-3.10.7.drv.gz log file. What should i do now? <PotentialUser-22>Also, is there any way to just install some package without upgrading all packages and building its dependencies? Because i just run guix install gnupg but guix then starts to build a tons of something <janneke>PotentialUser-22: before a package can be installed (or built even) all of its dependencies must be available <janneke>there could be several reasons why many packages get built <janneke>the most obvious one being that you ran "guix pull" <janneke>PotentialUser-22: right, so after a "guix pull", there's a good chance all kinds of package descriptions were updated <PotentialUser-22>janneke ok, i get it. but in my case there is an error in python3.10.7, and i don't think they will fix that already. Can i somehow work around it? <iyzsong>yelninei: i sent the patches for you, #76049 libpciaccess-static and #76050 libxcb. <iyzsong>PotentialUser-22: your python drv is different with me, what commit does 'guix describe' report? <janneke>iyzsong: (and maybe use "the Hurd" instead of "hurd" in the commit message; that's a real nit-pick :) <janneke>PotentialUser-22: using the latest guix master, all necessary substitutes for gnupg seem to be available (x86_64-linux) <janneke>one way to avoid building packages is to "guix package --roll-back", another is to do something like "guix time-machine --commit=<some previous commit, possibly from guix package --list-generations> -- package install gnupg <yelninei>iyzsong: Thank you. Having a (seperate) static libpciaccess is probably better than only building it for hurd <PotentialUser-22>iyzsong Is this the responsibility of the GUIX team or the authors of the packages? <Deltafire> build.. fail.. fix.. build.. fail.. fix.. the life cycle of package development ;) <iyzsong>PotentialUser-22: i think it's in the care of CI & infra team/folks, but we currently lacking non-x86 CI resources, so it's a normal situation... <PotentialUser-22>janneke THANKS for time-machine, it helped, although it looks a bit hacky <janneke>PotentialUser-22: yw; of course, it's "always better" to use latest / up to date packages...but one doesn't always have the time for that <PotentialUser-22>iyzsong i mean if i meet build failure, what should i do in general? whom should i report build logs? <iyzsong>PotentialUser-22: send a report email to bug-guix@gnu.org to create a issue <csantosb>Hello Guix ! I was wondering if it is possible to challenge two substitute servers, regardless of local store <csantosb>Something like ? `guix shell -DCPWN guix nss-certs -- guix challenge PACKAGE --verbose` <yelninei>seems like i broke guix pull somehow and i am not sure why: gnu/packages/hurd.scm:317:13: error: libpciaccess: unbound variable <civodul>ACTION .oO( We should push a release someday. ) <cbaines>civodul, now that we're post FOSDEM, when is it best to reboot bayfront? <civodul>cbaines: good question! like i wrote pre-FOSDEM (i think?), i suggest synchronizing mostly with Andreas and Philippe <civodul>Philippe told me he’s gonna go there with the Aquilenet team soonish <yelninei>somehow guix does not like the definition of libpciaccess-static and is failing in interesting ways. I have no idea what to do <csantosb>msavoritias: selfhosting with forgejo, I guess ? <ieure>Outage once a month sounds like an improvement, honestly. <juli>yelninei: been chatting about this on XMPP. inheriting across module boundaries is a no-go within a channel, it seems <msavoritias>short term yes. with a container. long term i am looking at options like "self-hosting" development in xmpp <msavoritias>and also if its for accessibility i feel like Forgejo is the only option currently <juli>Guix self-hosting git infra is a non-option unless folks step up to package, maintain, and host it <juli>but, you know that already :) <msavoritias>yep. was just mentioning in case people were interested ^^ <yelninei>juli: I guess it should move to xorg.scm and made public then? <msavoritias>idk what is the requirments for a new forge anyways. havent been following discussions. came from xmpp here :P <ieure>yelninei, Are you packaging this, or is it in Guix already? Have a paste? <yelninei>it is in guix and guix pull is broken ^^ (and it is partially my fault) <juli>moving to xorg.scm probably makes sense, yeah <juli>annoying hurd needs a static build though <juli>also if you're modifying module defs anyway, it may be worthwile to do a `#:select` and only pull in what you need. Guile is supposed to prune unused imports but that still takes compile time <juli>idk if there's a policy against this <meaty>Is there a way to contribute to the patch review process without being a committer? <yelninei>interestingly I was able to run 'make' without errors but when I then touch xorg.scm it fails again <juli>meaty: yes! simply review patches :) <meaty>nice :) I thought I had to be on a "team" or smth <yelninei>i guess this is an occurence of the common trap described in 'Cyclic Module Dependencies' section <csantosb>Any idea why the command `guix shell -DCPWN guix nss-certs -- guix challenge PKG` --verbose does it with htop, but not with calibre as PKG ? <csantosb>Rutherther: guix challenge: warning: could not challenge '/gnu/store/52f9mb2agz2d6as74ajfivrwki57xmxl-calibre-5.44.0': no local build <csantosb>In the case of htop, there is neither a local build, but I get instead "- 1 (100.0%) were identical" <yelninei>anyway it would be great if some commiter could unbreak it <civodul>ACTION looks for the day where we no longer push to ‘master’ <yelninei>civodul: the libpciaccess-static in hurd.scm inherits from xorg.scm <hanker>I wonder why guix challenge doesn't make a local build automatically <civodul>it seems to be a recent regression too <yelninei>civodul: this might be one of the errors i was trying to address (pciaccess now uses meson and now longer builds the static library which hurd wants) <yelninei>(other one is libxcb which is needed for fibers/libevent and thus shepherd) <yelninei>though the error above seems to be different one <civodul>are there pending patches or bug reports for the fibers/libevent thing you mention? <yelninei>No, 214b9d500f1434f745c26c5d9f826615d754a3ce iyzsong did this earlier as well <civodul>yelninei: i’m testing my change (moving libpciaccess-static next to libpciaccess) and will push if it goes well <FrenchNewbie>why do i get a extraneous field initializers for (password-authentification?) in openssh-configuration <look>FrenchNewbie: its "password-authentication", not "password-authentification" <cbaines>civodul, I see the problem, luckily this one is an easy fix, I'll probably deploy it later in the week when I have some time <df>nckx: belated thanks (re: privileged programs), makes sense <yelninei>civodul: iwas a able to crossbuild my childhurd earlier with the 2 commits (appearently despite the module dependency problem). So i hope the hurd build failure from the ci is also fixed by this <civodul>yelninei: i hope so too, because that prevented me from reconfiguring yesterday :-) <ieure>Just curious, but why are aarch64 substitutes so much worse than x86_64? Lack of hardware? <ieure>I did a `guix home reconfigure' on my aarch64-linux VM and it's been compiling stuff for over 24 hours now. <hanker>i wonder if the hurd is usable as a daily driver at this point <ieure>hanker, My understanding and belief is that it is not. <janneke>i haven't been able to install guix/hurd on newer machines than the thinkpad x60 and haven't heard success stories of newer machines from the debian folks either but yeah, upstream development is ongoing and someone will have to try <janneke>as far as i'm concerned "we" have enough guix'y things to fix before having to worry about running the hurd on hardware, such as fsck at boot and "guix system reconfigure" just to name a few <ieure>Well, I can't fault Hurd's taste in laptops, X60 is one I like a lot. <Moon_Rabbit>The issue with hurd on real hardware is even if your computer has drivers you need the moment you plug-in anything there is a good chance there won't be drivers for that. <nckx>The moment you plug a computer into anything you've ruined it. <Moon_Rabbit>the reality is the GPL is not radical enough. Instead of trying to make vendors play nice with a license what needs to happen is people need to stop playing nice with them. Dump their code if you can find it. Offer it in repos and ignore the stupid IP laws and all the other stuff they've been using for years to stifle innovation. <nckx>o/ (I can't type backslashes or use backslashes now, because I had the audacity to… reboot. So also don't reboot a computer. In fact, don't turn it on, don't touch it, it's the only way to be safe.) <nckx>Has this every happened to anyone? It's happened to me twice, so it's a pattern now. <janneke>ACTION has rebooted at least once and still has a \ <nckx>Ohkay. It's not deterministic, and I don't use linux-libre¹, but was still worth an ask. <nckx>¹ For reasons unrelated to -libre, so don't bug me. <janneke>i guess it's always good to ask, esp for such weird bugs <janneke>so, i've looked at %package's dependencies in guix/self.scm and that already seems pretty minimalistic <janneke>what puzzles me is that transitive-package-dependencies only looks at propagated inputs as i'd figure that all inputs need to be built <janneke>but anyway, even when using all inputs, there's still only 216 packages, ie no ridiculously big closures, apparently <janneke>so...i'm guessing the slowness of interpreting the self.scm %packages lists comes most entirely from the unfortunate distribution of these 216 package definitions in their modules <janneke>wondering how to generate the list of [package] modules that need to be read for these packages <ieure>*Really* appreciating Guix's package management as I struggle to get tree-sitter grammars installed on this cursed work MacBook. <hanker>it's a small thing, but i really appreciate guix builds in a tmpfs by default <hanker>when i was on gentoo you had all kinds of PORTAGE_TMPDIR to go through to build in a tmpfs <eikcaz>The company I work for just acquired some wifi IP. There is some internal push to open source the firmware, but I'm wondering if there is some lower hanging fruit. How much interest would there be in a modern wifi chip with firmware pre-flashed? <sneek>eikcaz, lfam says: Sorry I disappeared like that! I'll do a proper review today or tomorrow and send it to the ticket. We'll get it in <eikcaz>asking here because fsdg OS users are the most likely to be interested <eikcaz>sneek, later tell lfam, No worry! Thanks for the offer to review #75959. Let me know if you have any other questions or concerns. Configuring Syncthing from Guix has been neat, so I hope to share that. <hanker>i just finished reading the user/contributor survey results <hanker>i like the idea of an AUR-like stuff <mra>working on getting a guix vm built to tinker with zfs on guix. my internet connection is really fighting with me for some reason <hanker>especially since AUR is entirely automated <hanker>the guix implementation of an user repo would probably be different <luca>Isn't guix pretty much already there in terms of tooling? Just add another channel and that's the "AUR" <ieure>What does AUR do that running a personal channel doesn't? Provide prebuilt binaries? <ieure>Honest question, I've never run Arch. <luca>There's a couple third party channels already out there <luca>ieure: Actually no, AUR only distributes the specifications/templates to build packages <luca>(and some do just download prebuilt binaries, but guix can do that as well) <hanker>> What does AUR do that running a personal channel doesn't? Provide prebuilt binaries? <ieure>hanker, Can you be more specific? What duplicate work does AUR avoid? <luca>The issue often comes down to the general "why third party when it could be in $DISTRO's main repos". And in guix's case very often the answer is propriatery software which is nono cuz of stuff <hanker>> hanker, Can you be more specific? What duplicate work does AUR avoid? <hanker>if everyone has their own personal overlays, you're bound to have some duplicate packages <hanker>toys does solve a lot of this problem but it's more similar to gentoo repositories <ieure>hanker, Okay, so what do AURs do differently to prevent that than Guix channels? <hanker>> hanker, Okay, so what do AURs do differently to prevent that than Guix channels? <hanker>There's no "AURs", there's a single AUR <luca>It's officially unofficially endorsed <ieure>hanker, You don't need to quote my whole thing every time you answer. <ieure>hanker, But it sounds like a more official place to find/search unofficial channels is the thing you're saying would be valuable. I agree. Is there anything else? <ieure>luca, I do have some non-free stuff in my channel, but it's mostly things that are so niche I think the effort to merge into Guix isn't worth it. Also stuff that supports my personal setup, and sometimes fixed/updated versions of stuff already in Guix (though I try to send patches for anything like this). <ieure>Every package has a license field, an official thing could hide stuff with non-free or missing licenses. Or show a huge warning, or something. <hanker>AUR is basically one big channel where everyone throws their stuff with minimal supervision <hanker>but I think guix-toys covers a very similar use-case <luca>Yeah I also have personal stuff that are just not worth the effort of submitting/cleaning up for one reason or another. But idk if a common place to share half-assed packages like mine is really a good idea <luca>It's not an easy problem to solve at all don't get me wrong <Rutherther>hanker: that would be very dangerous with guix as anyone could introduce breakage, would be hard to avoid that, better if the packages are split to channels and one place links to them <hanker>> hanker: that would be very dangerous with guix as anyone could introduce breakage, would be hard to avoid that, better if the packages are split to channels and one place links to them <ieure>Very possible to break stuff from a 3P channel, too. <luca>On the topic of the guix survey, what counts as a patch (in term of what people here understand the term as)? Is it a commit? A patch series? A merge? <ieure>luca, A patch sent to guix-patches, whether applied or not. <luca>So for example if I submit a new package with 3 new dependencies (so 4 emails/commits in total), is that one patch, or 4 patches? <ieure>luca, Not sure about others' views, but I think (in the context of the survey) that patch and patch series are interchangeable. <luca>> Perhaps there could be a core and community channel with stronger/weaker standards <luca>(from the survey) Actually I kinda disagree with this comment a bit. I, as a completely new comer to guix, submitted 2 packages and they were both accepted with no questions asked. Guix has been surprisingly lax on standards. Which personally I really like because "oh hey I have a commit in guix" is a really good feeling <ieure>luca, It's highly subjective depending on who reviews your patch. <eikcaz>Reading the survey results, I'm surprised people complained as "not enough GNU". At least one person mistakenly thought nonGuix is affiliated with Guix? Also, not sure why people think proprietary firmware is an issue since moste people use nonguix anyway. <luca>Probably the first install experience, where the new user doesn't use nonguix and/or misconfigures it. At least that was my experience <hanker>I think guix has just enough GNU <luca>(also I bought a wifi card like FSF recommends but shitty thinkpad didn't like it and locked down >.<) <ieure>eikcaz, The combination of no firmware + install that depends on the network makes for a very poor out of box experience. Guix is the most difficult to install Linux I've encountered, and I've been installing it since the 1990s. <ieure>eikcaz, Even if you use an unofficial installer that has the firmware, the actual system it installs lacks the firmware, so has no internet access. <eikcaz>I'm certainly very against adding non-free anything to guix proper, but it does seem weird that we can't even direct someone to nonguix. Like, can we craft an approved message pointing new users with locked down devices to nonguix with all the context of why you should try not to buy devices requiring nonguix? <Rutherther>ieure: it is true you can introduce breakage with custom channels, but 1) bigger channels are reviewed by someone, 2) typically small amount of people have it under control, there isn't spur of commits by random people who don't know about each other's work, 3) it's more likely you're using something related to breakage, whereas with one big channel anyone can modify something you don't care about can break <ieure>There are some real costs to the hardline stance of Guix here. One of the ones that I think is the worst is not shipping CPU microcode. The CPU is *already* running microcode. It exists and nothing can work without it. So the stance does absolutely nothing to reduce the amount of proprietary stuff running on the machine, but it *does* mean that Guix users don't get updates to it which fix problems and security issues. <luca>eh, that's FSF stuff. Kinda less guix /shrug <ieure>luca, Well, it's where Guix is today. It doesn't ship CPU microcode, because it's blobs. <hanker>I _really_ hope we don't come to use discourse though <hanker>on my web browser, it greets me with a funky little banner that says <hanker>> Unfortunately, your browser is unsupported. Please switch to a supported browser to view rich content, log in and reply. <luca>Ideally you'd still have the mailing lists and IRC <hanker>but if that wasn't bad enough, discourse _also_ locks down scrolling <hanker>so usually when a post has the answer to some problem stumping me I can read the start of the post <mra>is there a way to install packages on the live medium? i'm trying to install a guix system on zfs to see if i can tinker with initrd stuff to get it to boot, but the live medium image doesn't have zfs installed, and i can't just install packages. i'm doing all of this in a vm, if that helps <luca>Doesn't zfs require some kernel modules? So installing it live is not practical? <mra>i just need the tools so that i can format the disk that i'm installing on <mra>either that or i could figure out how to format a qcow2 disk image file using the zfs on my host system... <hanker>> is there a way to install packages on the live medium? i'm trying to install a guix system on zfs to see if i can tinker with initrd stuff to get it to boot, but the live medium image doesn't have zfs installed, and i can't just install packages. i'm doing all of this in a vm, if that helps <hanker>if you have an internet connection in the vm you can `guix shell` or `guix install` ? <mra>i can `guix install` sure, but it rather quickly runs out of space. i assume that most of the live medium is on rom, and the rest of it is somehow volatile? i'm not really sure how storage for the live medium works <mra>more specifically, running `guix install zfs` gives some message like "trying to install xyz MB, but there is only <xyz MB of free space in the store" <bjc>you can use qemu-nbd on the host to present a qcow2 file as a block device you can put a zpool on <mra>bjc: yeah, but then i'm still going to need the zfs tools on the installation medium so that i can mount it to install guix on it, i think... <bjc>if you're trying to put zfs on your root drive to boot guix from, that'll present a series of challenges <mra>that's what i'm trying to play around with, yes. i'm guessing i'll need to build my own installation medium? <mra>the lack of zfs support on guix is the only thing that's preventing me from switching, so i'm trying to at least figure out what the roadblocks are to see if i can make any progress <bjc>no, you need a bunch of support. for one thing, since guix builds the grub menus, you need code to do that <bjc>for another, you'll need to figure out how to package zfs.ko on the initrd so linux can find it <bjc>it's much simpler to use zfs on a secondary drive you're not booting from <mra>i'm not sure what the zfs.ko issue would be. my understanding is that the zfs package installs the kernel module, and that the `initrd-modules` argument of `operating-system` allows you to specify kernel modules to be loaded by the initrd <mra>to clarify, what i'm talking about is a partitioned drive with an efi boot partition or whatever as well as a zfs partition which the initrd mounts as /. that's what i have on my current system <mra>so i also don't see how building the grub menus would change <bjc>‘initrd-modules’ only applies to modules included in the linux src tree, not arbitrary ones like zfs <bjc>no idea if the patches still apply cleanly <mra>ah, i see. thanks for clarifying that for me. that makes sense. i'll have a look <bjc>guix also builds the grub menu, so that support has to be added. i can't remember if those patches ever got submitted <mra>i am aware of someone having made some efforts to bring some level of zfs support to guix a few years ago, and someone mentioned on the mailing list that they've hacked together zfs support on their personal channel, but that they haven't tried upstreaming any of it <bjc>i don't know how far along the first attempt actually got. it's all pretty ancient history at this point <bjc>i can't remember how far along i got. i think i got the kernel booting, but it was a long time ago too <mra>not very far, by the looks of the code. it sounds like this other person actually has working root on zfs with native encryption working on their personal channel, which is quite impressive, but they haven't upstreamed it <mra>i had a brief exchange about this on the mailing list on 1 oct of last year before the school semester caught up with me and i stopped having free time <nckx>It's not ‘hard’ to write a working ZFS configuration/module per se, but getting it upstream is, due to the ‘oops we forgot some obscure way you could accidentally a binary’ — https://issues.guix.gnu.org/55231#17 <bjc>i still don't understand that <mra>ah, yes, kaelyn was the person who mentioned having working root on zfs working. the lack of upstreaming is definitely a bummer (indeed, i spoke with multiple people at fosdem recently who said that lack of zfs support was the thing stopping them from moving to guix) but just getting it working on my system would be nice... <bjc>how does a substitute for the module even get built in the first place? <bjc>what's the dependent that's getting built on the substitute servers and how did that happen? <mra>it's odd to me that dependents don't set `substitutable?` correctly. shouldn't `substitutable?` be "poisoning", so to speak? as in, something can only be substitutable if none of its dependents are <mra>sorry, if none of its dependencies are <nckx>I don't have an exact answer ready, bjc, but it doesn't sound implausible. <bjc>if you can think of one, it'd be nice to update the ticket <nckx>Isn't the initrd itself substitutable? <bjc>sure, but who's building a version of it that has that module? <bjc>like, how does that initrd end up in a substitute server? <nckx>Someone with a similar system. But if your point is ‘if you use ZFS, it's up to you not to run guix publish’, then I understand. <bjc>if you run *your own* substitute servers i fail to see how any of this is anyone else's problem <bjc>but it wouldn't end up in cuirass or whatever <bjc>who's going to put it there? <nckx>Are you using ‘Cuirass’ as shorthand for ci.guix.gnu.org? <nckx>I don't think that's the argument. <bjc>then i don't understand the argument, i guess <nckx>I think the argument is not that Guix-the-project not doing something solves the problem, but that Guix-the-software should not make it that easy to accidentally do it. <ieure>mra, Are you trying to run your root FS on ZFS? <bjc>can't you accidentally guix publish the zfs module? <nckx>Not if Guix is doing its job. <bjc>ah, because of #:substitutable? <nckx>Actually, you know, I'm not so sure now. <mra>is it easy? it seems kind of contrived. if i'm understanding correctly, for this to happen Bob builds an initrd with ZFS, publishes it, then Alice attempts to build the same, downloads it from Bob, and therefore Bob has redistributed ZFS binary and must go to jail, not pass go, and not colled 200$? <ieure>mra, n/m, I see you are. This is definitely unsupported, but interested if you get it working! <bjc>well then, in that case, why /isn't/ that flag poison? <nckx>We (well, I :-) assume a friendly Guix client that never requests it. I don't actually know whether ‘guix publish’ refuses to publish it. <nckx>bjc: That is the valid question. <nckx>And fixing that would unblock the issue. <bjc>i'm trying to be open minded here, but it's been so many years, and it would have been nice if someone at some point pointed that path forward <bjc>as it is, it just *sat* <mra>i mean this is the guix patch experience <mra>surely the median patch review time is infinite lol <bjc>i'm deeply familiar with the experience <nckx>I don't think Maxime was being deliberately obtuse, but it's certainly a pity if the path forward wasn't clear. <bjc>i'm not blaming maxime, i'm pointing to an apposite example of a deep frustration with the guix patch experience <bjc>i'm not blaming anyone <nckx><it would have been nice if someone at some point pointed> to me implied that the objection wasn't clear, is all. The next step is to fix (or disprove!) the #:substitutable? shortcoming. <nckx>The review problem is real but this isn't stuck waiting for a review. <bjc>i think this patch predates that <eikcaz>also on the guix survey, people complained about the email/patch workflow. If an appropriate git forge was packaged in Guix, would Guix be willing to migrate to said git forge, or are there other considerations? <mra>i think that there's mailing list talk about codeberg <mra>i know that ludovic talked to some codeberg folx at fosdem, actually <nckx>eikcaz: Packaging (→ self-hosting) is not a requirement. In fact the current discussion about migrating to Codeberg does not involve self-hosting. <nckx>But note that there are many (I'm not saying the majority, or a minority, we don't actually know) who prefer the mail-based workflow over a Web UI. The entire community isn't just sitting around waiting for a Web forge. <nckx>Were it but that simple. <bjc>my only beef with the email flow is requiring a cover letter <mra>my understanding was that the discussion stemmed from complaints about the workflow on the contributor survey <mra>there might also be some hope that a web forge would make contribution more accessible, i suppose <nckx><cover letter> So… s/debbugs/email flow/ (really sorry about how pedantic this sounds, but it's not an issue that actual ‘email flow’ projects like Linux have, it's wholly self-inflicted). <nckx>Er, s/email flow/debbugs/, how do sed work. <eikcaz>nckx: I've seen git forges that interoperate with email. It seems like it should be possible to maintain email as a primary means of interacting with a git forge, maybe with a few bots <bjc>seems obvious something has to change. might as well try the forge <luca>eikcaz: What git forges do this? <luca>Or any forge, not just git I suppose <bjc>yeah, i did mean debbugs. in fact, it might just be guix? i can't remember if emacs is like this too <eikcaz>I've definitely had the option to recieve emails of posts in threads I've participated in, and to be able to reply via email such that the response appears in the thread <eikcaz>I'm having trouble remembering which system that was. Maybe it wasn't a git forge, but that kind of functionality doesn't seem IMPOSSIBLE to add <bjc>ime, email is a very second class citizen. you're expected to use the forge ui, so everything's formatted around it. email will strip out most of that context <bjc>it's not impossible to do everything from email while everyone else is on github, but it's harder than you might think <ieure>Have said before, if Guix wants to stick with the email stuff, they ought to look at how Linux does it, since they're successfully managing things. <ieure>Main difference I see is that Linux delegates authority, so you send patches to whoever maintains the thing, and they roll that upstream. <ieure>With Guix, you submit a patch into the void and hope someone notices. <nckx>Yeah. A list of ‘open issues’ on $hip_forge is going to look a whole damn lot like issues.guix.gnu.org. (1) Forge! (2) ??? (3) Profit. skips a lot of, well, step 2. <luca>In guix in theory the maintainers get an email with your patch if you add the correct headers to the email <vagrantc>and then have to rummage around for the rest of the patch series <eikcaz>Is the patch backlog just a symptom of short-term rapid growth? Will it go away as more people become committers? <vagrantc>(e.g. if a patch series affects multiple teams) <vagrantc>eikcaz: the trend so far has been far more patches than new committers <luca>are there any numbers for how many issues/patches are open currently? <ieure>luca, Not sure off the top, I think debbugs has some kind of rrdtool dashboard somewhere. <eikcaz>Then is the problem people not requesting commit access or not enough people qualified to become committers? I imagine it's difficult to become qualified to commit if you can't get patches through in the first place <nckx>eikcaz: The number of committers already makes me nervous. TINA, but I'm still nervous. Trust doesn't scale linearly. <luca>Damn that's a lot more than I would have expected <nckx>Sad thing? I thought ‘huh, that's lower than expected’€ <luca>For comparission void linux hovers around 400 open pull requests <luca>Not that the projects are equivalent, just as another linux distro <luca>(though 400 is only for the packages, not package manager or other tooling around it) <bjc>1500 is much better than i thought. it's small enough that you can make some serious progress on it in a weekend hackathon <vagrantc>triaging out ones that are actually already fixed or no longer relevent could shave off a sizeable portion <vagrantc>a good way to procrastinate when i need to do something more important :) <ieure>bjc, Especially if you focus on the older ones, which are likely not applicable anymore. <nckx>I don't personally think that increasing this number would solve The Problem. <nckx>Mandatory review duty might, or it might reduce the number of committers back to, like, 5, which I might also be OK with. [/s, or not…] <bjc>i have hope that when the gcd process gets approved we can make some serious attempts at The Problem <vagrantc>well, there are people like me, who have domain specific knowledge (e.g. u-boot and reproducible builds) but actualyl do not feel cozy with guile or even worse, texinfo ... that have blocked me from doing much generalized patch review or pushing patches <nckx>Guix Consensus Document. <vagrantc>so i feel there are a very small number of patches i can generally usefully review or push ... <nckx>podiki: Same! I even showed up to a single Guix Day, so you're not rid of me yet. <podiki>nice! sadly i was across the pond, though doing some other guix hacking anyway <mra>was hoping to show up to guix days this year, but room too smal :( <nckx>vagrantc: And the ‘problem’ is that this doesn't make you any less valuable as a committer, so it's not a simple maths problem. <nckx>mra: Sorry about that. It's the first year that room size was such an issue. <mra>no worries! still caught ludovic's talk at fosdem <vagrantc>nckx: yeah, i guess that is the explicit point i was going for, without aggrandizing myself :) <podiki>i need to read the giant "will guix forge or not" thread, an interesting topic (discussing also for another channel, coincidentally) <vagrantc>ACTION also notes that because of the way teams.scm is implemented, reproducible builds patches almost never come my way <podiki>i do admit to having quickly grown to at least rather like the simplicity of sending email patches; for forges having to fork, make changes, do MR is cumbersome in its own ways too <hanker>> was hoping to show up to guix days this year, but room too smal :( <mra>it's an offshoot event of fosdem <nckx>hanker: A two-day prequel to FOSDEM by & about Guix. <mra>actually there's some proper term for the offshoot of fosdem events... but yeah, it's a guix conference <vagrantc>for many years in Debian i take patches sent via debian's debbugs instance as well as gitlab(e.g. salsa.debian.org) merge requests, and because in the end it is just pushing to git repositories, that has largely worked fine ... <luca>IMO submitting a patch is easy by email, but following up is easier on the PR/MR model (where you git push --force to the same branch). At least more natural. I don't dislike email, though I've yet to use it seriously <vagrantc>though i will admit for larger patchsets via email tends to be a bit harder than just merging branches <podiki>yeah, good points, pros and cons! <podiki>would be nice to have both, but i fear we don't have the people/organization/structure for that to be a net positive <podiki>i might push for that in a channel though, migrate over time <vagrantc>i also shy away from large patch series because having to use my OpenPGP passphrase for hundreds of commits is tiring, and i do not like caching such things. <vagrantc>e.g. to me a signature is "really, this is me, the holder of this key, who has signed this thing, and you are foolish enough to trust me" <meaty>if a patch is so old that its patches don't apply anymore, should we mark that in review? <nckx>I don't know if there's a [user]tag for that but I'd definitely ping the author. <hanker>> i also shy away from large patch series because having to use my OpenPGP passphrase for hundreds of commits is tiring, and i do not like caching such things. <hanker>you can cache it in gnome keyring or (even better) in a KeepassXC database <podiki>nckx: can you cache specifically for e.g. git signing requests? my key prompts me for every sign individually but i never looked into the gpg ttl settings <[>vagrantc: git format-patch doesn't preserve signatures <hanker>maybe i should write something about this <hanker>it's not like i invented anything but KeepassXC has a not-well-known feature to cache system-wide secrets <vagrantc>[: yeah, but applying them and pushing them to guix does <hanker>that plays especially well with GPG <luca>meaty: personally for a patch that didn't apply I submitted a v2 with the conflict resolved because I wanted it to be merged <nckx>podiki: I don't know! I cache only for a few (10? ballpark 10) seconds, enough for any reasonable patch series to be applied. <vagrantc>hanker: i do not trust caching my signature. there are technical ways to do it, but i do not trust them. <vagrantc>it's a safety net to prevent me from accidentally pushing some cruft where it shouldn't go <podiki>my gpg-agent caches-ttl is 60 (seconds), max 120, but i guess that's not how this works? <nckx>You holding yourself to higher standards than I do myself is one of the reasons I gladly grant you commit access :) <podiki>nckx is the bar we measure against for trust? <bjc>do any of us really *know* nckx? <vagrantc>it's just four letters, how dangerous could it be? <nckx>Vowels are the Devil's work. <nckx>bjc: Come to Brussels next year, find out :) <podiki>unless it is holiday time, then more letters appear, mysteriously <eikcaz>If I think of a minor improvement to a service patch I submitted, should I update the patch or wait and submit a second one after the first gets through? The original patch is still good without the improvement, and I don't want to slow down a patch that might not get committed. <bjc>does anyone here remember a recent email to one of the lists about tmpfs-mounted root? did i hallucinate that? <bjc>i've dug through them for the last couple months but can't find it <nckx>eikcaz: I would not wait. <nckx>bjc: Mmno... There was discussion this week about tmpfs {/ › /run}/media, but I assume your search already found that & was not what you meant. <bjc>no, this was some weeks ago <bjc>i need to remember to bookmark stuff more often <podiki>re: caching, I think gpg-agent ttl doesn't affect my case since it is a hardware key. but i can set the hardware key to cache a touch for 15s so maybe i'll try that <bjc>no, but thanks. iirc it was a how-to of some variety. it's possible i just dreamed it up <ieure>bjc, I also remember seeing something like this. <nckx>Now I'm interested in a link if anyone finds it. <podiki>which was merged but i don't think any blogpost about it came out <ieure>My brain is really struggling not to read that issue number as 65535. <bjc>hah. i didn't realize it wasn't until you said something <look>it got pretty popular on mastodon #guix for some reason, maybe thats what you saw <bjc>look: that was it! thank you so much <mra>engaged in the rather cursed process of installing guix on nixos to attempt to build my own installer image lol <bjc>i've been wanting to go back to guix at some point, but i don't want to give up tmpfs-root from nix <podiki>mra: if you trust me/someone here, we could build for you <luca>what does tmpfs-root provide? More reproducability? (overly simplified) <mra>i'm not worried about trust, since i'll be running it in a vm, but i need an installer image with zfs installed, which would unfortunately violate copyright law to send me lol <ieure>I would also like tmpfs root, not for my main system, but because it's perfect for live CDs. <ieure>Oh uh I guess... flash drives. <bjc>i don't like cruft accumulating on my systems. tmpfs root is another step in making sure i know what everything is and why it's there <nomike>I just ran into the following issue: I'm running guix on top of Ubuntu 24.04. using gnome. In my ~/.zshrc I'm sourcing "${HOME}/.guix-home/profile/etc/profile" as intended. The problem is, that when I use <alt>+<f2> to run a command, the shell startup files are not used, so guix isn't working properly. Any idea how to solve this? <bjc>source it in .zshenv <podiki>or probably ~/.zprofile should source ~/.profile, thats what i have and i think was in the manual? <bjc>zshenv is loaded with every shell, not sure about zprofile <bjc>it's not the same as bash semantics, though <podiki>i'd stick with .zprofile as per manual and to match what is done with bash here (sourcing .profile)