IRC channel logs
2025-06-10.log
back to list of logs
<podiki>efraim: just saw you had a couple of commits for mesa-updates, will the cppdap be a lot of rebuilds? (mesa just looks for riscv64) <meaty>What's the procedure for updating a package with the new rust system? <xelxebar>It barfs a bunch of warnings to stdout when starting. <xelxebar>Looks like we're appending to ZATHURA_PLUGINS_PATH several times, unnecessarily. <xelxebar>I only see a single native-search-path entry setting that variable, though. <xelxebar>ieure: Not well, if you live in the CLI. <PotentialUser-74>Hi, I packaged Gleam, a programming language written in Rust. I don't know if I should create a gnu/packages/gleam.scm file or add it somewhere else. <efraim>podiki: looks like yes, `guix refresh -l cppdap` shows ~6100 packages. I'll adjust it from a snippet to a phase for riscv64-linux <cancername_>I noticed that a shepherd one-shot service will allow dependent services to start even before it completes. How can I ensure that dependent services only get started if the one-shot service exited successfully? <futurile>oh I feel like we're in a stadium with a rolling wave now: \o/ <emmastrck_>i installed Guix on a scrappy hand-me-down laptop during the school break summer of 2015/2016, it was a blast! I love this project, just wanted to thank you guys for the happy memories :) <csantosb>sneek later tell civodul, could you please have a look at #140 in science ? the source tarball being gone, all dependencies on gnat break; guix linting apparently doesn't compute the swh backup of tarballs, I'm afraid <jlicht>Do we still merge 'disruptive' changes to team branches? How does one adjust the AGit workflow to do that? <xelxebar>Finally figured out where what was duplicating several PATH-like envars on my machine. <xelxebar>Turns out that tmux runs a login shell by default, causing /etc/profile to get run again. <meaty>Does anyone have any resources on deploying a PHP web app (specifically FreshRSS) on a guix server? <xelxebar>Have to set-option -g default-command $SHELL to get a non-login shell. <kosto>Hello, is it possible to build all packages from sources (gentoo-like)? <jakef>kosto: on your local machine? yes you can disable substitutes <kosto>Yes, how can I do this? I can't Google it <jakef>during installation of a guix system you can choose not to enable substitutes <jakef>guix commands like guix install also have a --no-substitutes option <decfed>kosto: some package have transformations to fine-tune based on your CPU arch. Not sure if that is your goal. Else you only get more "trust" in building yourself <jakef>re pyproject-build-system, if it wants to import a python package in the 'sanity-check phase, is that an indication to add it to propagated-inputs? <jakef>since it's probably importing the module at runtime i guess? <apteryx>hm, node fails its test suite on my system (non-deterministic failure I guess) <ieure>Does `sudo reboot --kexec' work for anyone? I think it's worked for me maybe once. <ieure>Every time I try it, I get a blank display and a frozen machine. <Tadhgmister>same here, is it supposed to work consistently across different hardware? <hako>ieure: Is the disk LUKS-encrypted? There's no display when prompting for password it seems, so you need to input without the display. <ieure>hako, Yes, I don't run anything cleartext. <apteryx>ieure: seems to work well on head-less systems; otherwise it never works for me (video signal stops) <apteryx>(I do use LUKS-encrypted devices as well, but blindly typin my password doesn't help -- then maybe I never got it right ^^') <ieure>Not like you see the password when you type it in normally! <Tadhgmister>but knowing when the prompt starts would be nice lol <ieure>In the first week or two after the feature landed, I was able to use it fine -- it came back up and prompted me for the disk passphrase. <Tadhgmister>what would it do if there is a keyfile passed to the initrd by grub? not seeing the prompt makes it hard to determine <apteryx>I don't have that experience. It's consistently has not worked on my home machine (works well on a VPS though). <apteryx>is it possible to know the reason why I got a notification on Codeberg? Maybe because of the CODEOWNERS file (teams?). I was looking at this one for example: https://codeberg.org/guix/guix/pulls/504, which I don't think relates to any team I'm in. <apteryx>hako: hm, 'wached the repo automatically' -> the watch button still is off for me? <podiki>efraim: what's the build time like for riscv64 on bordeaux? right now coverage on all architectures is at least as good or better than master <efraim>I'm not sure, I don't have ssh access to bordeaux <podiki>or actually powerpc64le and riscv64 are just a tad less based on the QA page <efraim>on my machine mesa took ~7000 seconds in the 'build phase and cmake takes about the same <efraim>berlin has substitutes for mesa on ppc64le <podiki>i'd say go ahead and make the riscv changes with a rebase to latest processed revision <podiki>probably needs a couple of days to build then? i updated mesa a few days ago and seems everything built <Tadhgmister>installing `ublock-origin-chromium` puts the extension under `~/.guix-profile/share` but our ungoogled-chromium package looked for the extensions under /usr/share which I verified by symlinking that to my guix-profile. Would that be considered a bug that our chromium package isn't patched to point to the guix specific paths? <Tadhgmister>the comment in the function to make extension packages says that installing the package should make it just work but it doesn't seem to and I'd like to ask if I'm just using it wrong or if this is worth opening a bug report. I might be able to fix it if it comes down to tracking down the specific substitution* in the build process <andreas-e>I would say it is a bug. But ungoogled-chromium is severely outdated, so the first useful thing to do is to propose an update before someone decides to remove it ;-) <attila_lendvai>this is all that `guix home reconfigure` tells me: ice-9/eval.scm:196:35: In procedure scm_to_utf8_stringn: Wrong type argument in position 1 (expecting string): #f <attila_lendvai>whoever copied guix/scripts/home.scm from system.scm weeded out the command line arg parsing (but not the (assoc-ref opts 'on-error) part) <attila_lendvai>ACTION is constantly torn between running his own guix fork (with all its headaches) or running vanilla guix <ekaitz>efraim: openssl is failing in riscv? <ekaitz>efraim: i'm trying to guix pull and i'm having issues in the tests <attila_lendvai>i still marvel how come that so many people put so much effort into developing guix, while tolerating the almost complete lack of observability of the codebase, including guile's less-than-useful error messages... <attila_lendvai>it holds back the project to such an extent that i think only a few people realize <ekaitz>attila_lendvai: what do you mean by observability? <attila_lendvai>ekaitz, i think ultimately logging and backtraces. (and while we are at it the lack of proper error handling discipline throughout the codebase) <ekaitz>hmmm i agree that we could improve guile <attila_lendvai>e.g. shepherd is completely undebuggable as-is, and my attempt at adding logging was rejected with a single "baroque" comment, while almost daily i see misbehavior that i could debug relatively easily were my rejected patches not bitrotten... <ekaitz>attila_lendvai: maybe it's me, but I read some resentment in your words <attila_lendvai>and then most of the `guix ...` commands print useless stuff. either an exception is turned into a useless (but at least very localized!) error message, or it's straight out swallowed into the void... <ekaitz>what can we do to make it better? what are those patches about? <ekaitz>do you feel everything is a guix or a guile problem? <attila_lendvai>ekaitz, yes, when i have my coder hat on i'm very frustrated at this point <ekaitz>well, i understand but I try to convert frustration to solutions <attila_lendvai>ekaitz, make sure that patches are judged based on merit, and that the maintainers don't prioritize their own hacking pleasured over reviewing patches and giving feedback when they are rejected. <ekaitz>that's an accusation that I don't like much, but it's understandable <noe>attila_lendvai, I agree, Its so frustrating when you get a backtrace and the info is censored with underscores and ellipses! <noe>Or when you don’t get a backtrace and just a print of the exception variable that is only machine-readable <ekaitz>noe and attila_lendvai let's improve guile then <noe>That’s what my internship is about :) <ekaitz>i've been looking for guix people to contribute to guile <attila_lendvai>ekaitz, but at this point i started to suspect that it's also a personal issue between civodul and me... but i don't really know, because all i see is that there's an enormous discrepancy between how i value some of my contributions and how it's treated. it could easily be just a wrong judgement from me, or "life" on civodul's side... but it feels the same on the receiving end. <noe>ekaitz, contributing to guile is very complicated compared to Guix though <ekaitz>attila_lendvai: i tend to think people are busy, specially the one you mention, and try to avoid adding some layer of intentionality to things that happen <noe>Do you contribute to Guile yourself? <ekaitz>attila_lendvai: also civodul is not a maintainer <ekaitz>noe: i had, yes, but I don't have commit access. And no, I don't think it's more complex than Guix. <attila_lendvai>ekaitz, i've done some hacking on sbcl in the past, but when i looked at guile's source it felt like going back a couple of decades... it felt like wasted effort. but being completely intertwined with guile is a political question, and i have nowhere near enough credit here to question that or propose using a better scheme. <ekaitz>guile is an old project and it's almost unmaintained i think we would all benefit from making it better and having some more committers there that actually care about Guix <ekaitz>complaints and accusations won't help for that <attila_lendvai>ekaitz, civodul seems to be the sole maintainer of shepherd, a core guix component that btw is also one that needs the most love (it causes the most headaches for me) <noe>I don’t share this opinion, I’d rather Guile gets itself some users and contributors external to Guix so it doesn’t become “the guix language” <ekaitz>noe: of course, but us like guixers do require that guile is good enough. So we should do our part. <attila_lendvai>ekaitz, but what if potential guile contributors are shying away because they also see that it's a wasted effort in 2025 to work on guile while there are better solutions <attila_lendvai>ekaitz, i lack the proper knowledge to really judge this, but i'm afraid that it may be less work to grab a better scheme and add a guile compatibility layer than bringing guile up to today's standards <identity>with that attitude, guile will definitely not get any better <ekaitz>ACTION has to go but has a last thought: when people are alone, they are an easy target. If we punish the brave people that try to maintain things, we are discouraging them to do so. We should help. <attila_lendvai>identity, i can't speak for others, but i do have a very hard time doing things that i find unreasonable, and that i know is an inferior strategy in the mid to long term. <attila_lendvai>...which reminds me of the insistance on the ChangeLog format in the commit messages <identity>attila_lendvai: i do not see how improving guile is unreasonable compared to switching to a different scheme implementation <old>Just throwing this but, maybe having a Guile foundation could help regroup the core projects under a same unbrella and perhaps unlock some financing <old>that could help the development of Guile <attila_lendvai>old, i don't think it's due to the lack of financing. i was there in the guile codebase, multiple times, trying to improve backtraces and the debugger, but i groaned and gave up (even though most of my work on sbcl was in the same facilities) <old>what would you say is the problem? The codebase itself? <attila_lendvai>opensource hackers hack on something because it's fun. hacking guile must be fun, but if i see much better scheme implementations, then the fun part is immediately gone (for me)... <old>the legacy codes and the mangling between C and scheme? <ieure>attila_lendvai, One of Guile's core features -- and one which I suspect drives a lot of design decisions, likely some of the ones you're finding grating -- is the bidirectional interop with C. Scheme-to-C FFI is fairly common, but is there another Scheme that has Guile's C-to-Scheme feature? <attila_lendvai>old, first of all there's way too much C in guile, even in parts that never needed to be written in C to begin with. <old>I would not mind dropping the C-to-Scheme part <noe>attila_lendvai: you can also contribute to Guile because its fun, not because its the worlds best scheme <noe>Oh you talked about that <attila_lendvai>ieure, i'm not experienced in the scheme ecosystem. but i think e.g. sbcl can do all that (certainly the C->lisp callbacks, but i think it can be used also as a .so to initiate the lisp part from C code) <attila_lendvai>noe, working on stuff that has already been done, probably multiple times, is *not* fun <ieure>How's things at the institute these days? <noe>attila_lendvai: it can be! Otherwise nothing would be fun. In general, I can crochet, I'm not inventing anything. The satisfaction comes from doing something myself and seeing it work. <attila_lendvai>ekaitz, but what if you see brave people who are hacking on the wrong thing? e.g. you can show them a path around the mountain in which they are digging a tunnel? would you join them, or invite them on the easier path? <ieure>Why do you assume they didn't consider that? <attila_lendvai>noe, old, i didn't say it applies to everyone. i have much more exciting visions than improving a scheme instead of picking a better one and continuing with that. <noe>Sure, so which scheme would you pick? <attila_lendvai>ieure, because i suspect that gnu fundamentalism is also part of this story, and even though the alternatives are there on the shelf, they may not be licence-compatible <old>re: but what if you see brave people who are hacking on the wrong thing <old>that sounded pompus at best <ieure>attila_lendvai, What do you hope to gain from this conversation? <noe>So your own scheme is the only one that should be contributed to because its the best? <attila_lendvai>ieure, two things: 1) venting, as a frustrated coder. 2) but as an enthusiastic user of guix, i hope that i can bring attention to some issues that if they are better dealt with, then it would greatly improve guix, both as a linux distro, and as a project <attila_lendvai>noe, i don't have a scheme implementation. i'm not even experienced enough to propose another scheme on which it would be worth considering creating a guile compatibility layer and make guix work on both schemes. <attila_lendvai>noe, all i see is that the deficiencies of guile is a mayor hindrance <noe>I'm not good enough in compilers to see the deficiencies. I just think its cool, so I'd have fun contributing to guile. <noe>Also there are fun comments by andy wingo <attila_lendvai>i'm no compiler wizard either, but i worked a lot with slime and sbcl, and the guix-guile experience is an enormous step-back <attila_lendvai>and it's not so much about the compiler part itself, but about how the parts are wired together into a computing system <noe>you are being very vague <attila_lendvai>noe, just a glimpse from my personal experience: lisp web server running, hundreds of users online. one of them calls support, i look up his web session, enable debugging. meanwhile my slime (emacs) is connected to the process. i tell the user to click the problematic action... <noe>I’m working on something like that for Guile as part of my internship on Ares <attila_lendvai>...slime debugger pops up in my emacs. i often fix the bug right there, because it's something simple but unexpected. C-c C-c the function, then press a restart to restart the thread at an appropriate point. user's browser stops the hourglass and loads the page successfully <noe>But yes its something that is lacking now, we’d like to have it work like you’re describing <noe>Were you able to connect to the live process with slime? <attila_lendvai>noe, are you aware that there are some half-baked attempts? e.g. slime can be relatively easily hooked up to guile by writing/finishing a new swank backend. <attila_lendvai>noe, yes. connect to the live process, look up the web sessions in the repl and inspector, and enable debugging for one of the sessions <noe>yes, there’s usually geiser but we’re making a fully cooked debugger <noe>attila_lendvai, that’s very cool. I hope I can make it work like that <attila_lendvai>noe, i think sldb, the debugger in slime, is done well enough to work ok with a scheme, too. some CL features wouldn't work, but otherwise most backtrace and inspector stuff would be the same with a scheme backend <attila_lendvai>btw, i even looked into writing a slime backend for guile, but guile's debugger and introspection is not good enough... i looked into improving guile, but... see above. <noe>then you were probably doing some similar things than I’m doing <cwebber>there have been some fun blogposts recently if you missed 'em <attila_lendvai>noe, if i were you i'd certainly research the feasibility of writing a slime backend for guile. i can help finding your way in slime/swank part, i used to hack on it. <noe>but attila_lendvai in reality we don’t have too much limitations with guile itself right now. We can do breakpoints, stepping into instructions etc… The only issue is that the default compilation options can lose a lot of debug info so sometimes breakpoints don’t trigger but we got some ideas to fix it <noe>attila_lendvai, I don’t need slime at all. Since I’m making it for Ares, which you should look up. Its already a fully featured Guile IDE apart from debugger <attila_lendvai>noe, in my experience the most valuable part is proper introspection into the stack, and an interactive inspector that opens when clicking values in the backtrace. stepping i never used in my decade+ of lisping. <noe>Interactive inspector is making evaluations with a variable from the stack? <attila_lendvai>noe, it displays heap (or stack) objects with links to navigate further away. similar to a html browser. <ekaitz>attila_lendvai: i think this is not the correct place for venting but for collaboration and converting the frustration in action <noe>that is what we are doing now :) <ekaitz>attila_lendvai: i don't mean to nag/judge you or anything, just sharing my (unsolicited) opinion <noe>attila_lendvai, we are definitely going to have that then <ekaitz>noe: let's go then! I'm trying to use tropin's work from neovim, too <podiki>efraim: oh, so it won't matter if the riscv fixes go in before/after mesa-updates merge as it won't affect substitute coverage? the branch looks good to me to merge, but feel free to make the riscv changes first and i'll check back in later <noe>That’s the guile side <noe>and the Emacs side is called Arei <noe>and ekaitz must have a vim side <noe>ekaitz, We should collaborate to bring the debugger on vim too :) <ekaitz>noe: there's conjure, but it needs a lot of work to make it work for guile <ekaitz>so i'm thinking on how to make that happen <ekaitz>maybe I should work on conjure or maybe make a client on my own <ekaitz>futurile is also interested on this <noe>In theory, you just need to make an nREPL client <ekaitz>noe: yes, but conjure already has one for clojure, so we could try to reuse it for guile (which it also supports, but via a socket) <ekaitz>i think i prefer to just write an nrepl client from scratch, but I'm a lazy bastard and I just had a kid and have a lot of work to do... <noe>its always good to reuse <ekaitz>yeah... if the kid could write the code... <noe>if it is well made you can maybe extract only the standard nREPL side <noe>then implement the extension for debugging <ekaitz>we should also work on guile directly, it needs lots of love <attila_lendvai>ekaitz, the alternative to this venting is silently losing potential contributors. the *only* reason i'm venting is that i'm enthusiastic enough as a user to "waste" my time discussing these. if i was a little less enthusiastic as a user, then as an experienced lisper i would have been silently gone, long ago. <ekaitz>attila_lendvai: i understand but disagree. I try to vent privately... i don't feel it's right to do that here. Many people is frustrated as you are and are trying to make things better and venting might make them feel bad. <ekaitz>like they are working very hard on something and then someone else comes and is very hard on that specific feature -> i don't think i'd love that situation to happen to me <ekaitz>that doesn't mean we shouldn't criticize things, but at least i'd try to make things more from the encouragement side <ekaitz>so, guile stack traces are poor -> how could we improve them? <attila_lendvai>ekaitz, fair enough. but i wonder, how would you handle the situation i found myself in regarding my ignored shepherd patches? (and then all the patches that i haven't even written, that would clean up error handling in all of guix) <ekaitz>re guile stack traces -> why something so obvious is not fixed yet? there must be something there we are not being aware of <ekaitz>attila_lendvai: i don't have an answer you'd like, but probably i would insist and ping the commiters once per two weeks or so, until my patches are merged <ekaitz>or just let them go without resentment <noe>ekaitz, as I understand it, auto-compile uses optimization level 2 which doesn’t have a lot of debug info, so a lot of _ <noe>anything with optimization level 0 or 1 has ok backtraces <ekaitz>noe: and what about the ellipsis? <ekaitz>what could we do about it anyway, ask guile to use O1 by default instead? <noe>that is a feature because your terminal is not wide enough <ekaitz>but still get the lines cut to 80 chars or so for no reason <noe>you can disable it with some repl variables IIRC <noe>if it was up to me, I’d disable it all together because there is important information in there! <noe>> what could we do about it anyway, ask guile to use O1 by default instead? <noe>I guess or implement a way to have debug info with optimizations like gcc’s -g <attila_lendvai>ekaitz, my way of handling it was to just suck it up and stop contributing (because Ludo clearely decided to hack on instead of giving me feedback, which repeatedly bitrot my patches several times before i stopped rebasing them). but since then i keep seeing issues with shepherd, and every time i'm annoyed that my commits are bitrotten and i can't debug it, because there's no way to introspect shepherd (and guile and <Kolev>Shepherd: Even if your computer doesn't boot, you can still compute. (+ 1 1) <attila_lendvai>:) noe, have you ever tried to use it in the PID 1 shepherd? also, many issues cannot be dealt with without a log, just using a repl. <noe>yeah, did it not work for you? <attila_lendvai>noe, for the slime stuff i wrote above: that was already 10 years ago. <old>re O1 vs O2: You can configure the auto-compilation flags in your .guile for this <attila_lendvai>noe, IIRC i couldn't set it up. but then the error handling inside shepherd guarantees that you'd hang your computer in short order (i improved shepherd's error handling, too) <noe>yeah freezing the shepherd is a real issue <attila_lendvai>i have this among my services, commented out: ((@@ (shepherd service monitoring) monitoring-service) #:period 60) <noe>okay well I have to go <noe>Thanks for the feedback, and hopefully you will be able to try out my awesome debugger soon <attila_lendvai>old, guix invokes guile in interesting ways. i'm pretty sure the user's ~/.guile won't ever be processed. when e.g. the guix codebase invokes guile to compile some shepherd config and modules to be later loaded by the shepherd process... <old>attila_lendvai: then Guix should expose a way to configure Guile in some way I suppose <attila_lendvai>ekaitz, to clarify re venting vs collaboration: i'm primarily venting because my collaboration was rejected without feedback (except the fix). <wehlutyk>Hi all, I'm trying out guile+c, is there a standard guix shell line for that? The default I'm using doesn't find libguile.h <wehlutyk>gcc -fPIC -shared -o libtake.so take.c $(pkg-config --cflags --libs guile-3.0) <ekaitz>attila_lendvai: again i understand your frustration. And I don't think you are venting here on bad faith or anything like that (just clarifying) <wehlutyk>failing with "fatal error: libguile.h: No such file or directory" <futurile>ekaitz, noe: best exchange ever-> Noe" it's good to reuse .." ekaitz: "yeah, if the kit could write the code .." <futurile>though pretty sure it's illegal child labour to make your newborn write an nrepl client <yelninei>wehlutyk: Do you have your C compiler in the guix shell as well? <ekaitz>wehlutyk: what's your guix sell line, then? <wehlutyk>ekaitz: guix shell guile guile-aiscm gcc-toolchain -- fish <luca>For what is worth, the few trivial patches I've sent have been accepted in good time by guix. And even if they don't, I can make a custom channel and throw them there. So I am pretty pleased with guix as a whole from that perspective <ekaitz>wehlutyk: i wouldn't do the -- fish in the end <yelninei>you'll also need pkg-config probably to get the updated PKG_CONFIG_PATH <wehlutyk>and indeed without fish (re using "-- fish" makes it fail) <ieure>I love Testament! (the thrash metal band) <hako>don't know much about that :P <attila_lendvai>ekaitz, no worries, i didn't feel attacked by your comment. i just wanted to clarify that my default attitude is also to fix stuff instead of complaining. i'm venting because i fixed stuff, it was rejected, and i'm regularly frustrated by deficiencies that my rejected commits improved upon. (and as icing on the cake, i got demotivated for any future fixing) <ekaitz>attila_lendvai: from my side, if I see any of your commits to guix and they make sense i'll push (idk if you have commit access) <ekaitz>but in the shepherd there's not much I can do <attila_lendvai>maybe i should consider shepherd and guix to be much more independent than i am currently... <attila_lendvai>somehow my impression was very different, though. now that i think about it, maybe too many of my patches were touching core components... <daviid>wehlutyk: ping me (in #guile preferably) if you need help wrt guile-cv - make sure you read the 'Configuring Guile for Guile-CV', its subsections, and apply : unfortunately, one still need to patch guile and alter the 'default' raised exception system, so it can be configured to truncate its output <meaty>oh, wait, the numbers are shared with issues <ieure>PRs are just issues with code. <ieure>I've gotten one LLM spam issue filed against one of my Codeberg projects, the site admins had deleted it before I could report it myself. <daviid>wehlutyk: the doc explains how to do this 'manually', but the best approach 'nowadays is to clone guile, and cherrypick the authors patch, like this - git cherry-pick ed5e37caa (which cherry-pick lloda's wip-exception-truncate patch) <daviid>then compile install the patched guile version <daviid>wehlutyk: this is not a guile-cv problem, it is a guile 'default' raised exception lack of a truncate option ... anyone of us (just a few afaict) who do work with large to very large data structures, vectors and arrays, must patch guile and configure, otherwise it is just impossible to devel using guile (in this context) <wehlutyk>daviid: aha, great with the cherrypicking -- I was managing this by never having the im printed <daviid>wehlutyk: but even you do not print (which is next to impossible as you devel), the problem araises as soon as a bug occurs <daviid>welcome - let's move guile-cv related discussion(s) to #guile, if you don't mind <Tadhgmister>how does one make use of the packages in gnu/packages/browser-extensions.scm? specifically what are you supposed to do with the icecat ones to have them show up in icecat? <identity>Tadhgmister: does installing extension-name/icecat not work? <hako>Install them into the same profile of icecat, there's a search path. <Tadhgmister>it depends on an environment variable, launching icecat from the terminal I just installed them in was not working <Tadhgmister>I literally figured that out from looking at the source code just as you pinged me lol <hako>you can test with `guix shell librewolf noscript-icecat adaptive-tab-bar-colour-icecat -- librewolf` for example <hako>all firefox-based browsers support -icecat extensions btw. <Tadhgmister>yes, I could have sworn the first thing I tried was using guix shell with the extension and the browser but I guess not, and all subsequent tests involved reconfiguring my home profile or installing the packages to profile and then in the same terminal without the updated environment variables opening the browser to see no extension <ieure>Tadhgmister, If you already had the browser running, new `icecat' (or whatever) invocations would have opened a new window in the running process, which wouldn't see the extension. <ieure>Most likely explanation for what you were seeing. <Tadhgmister>oh... yes that would have messed up the shell test true. thats on me for not using `--pure` <ieure>hako, I was messing with some browser extensions the other day, do you know where I can find the extension UUID I need to package them? <hako>manifest.json -> browser_specific_settings.gecko.id. If it doesn't exist in the source, download the extension from AMO and unpack it.