IRC channel logs
2026-03-16.log
back to list of logs
<YAR_Oracool>Aaaaa... any one here? I need a bit of trouble shooting. <ieure>YAR_Oracool, Doing okay, just messing with some old equipment. What's your problem? <YAR_Oracool>I'm trying to get scribus and Latex installed system wide but I'm hitting an error. Scribus says did you add "use-module" but doesn't say which one, unlike gimp or rawtherapee <YAR_Oracool>And Latex ... .I just need something that installs everything. <ieure>YAR_Oracool, `guix search package-name will tell you what module it's in. Scribus says "location: gnu/packages/scribus.scm:51:2", which is the (gnu packages scribus) module. <ieure>I don't know anything about LaTeX, I'm not sure if there's a metapackage that has all that stuff in it or what. <ieure>I guess you could install every ^texlive.* package. <YAR_Oracool>Is there a way to just tell guix to use all of guix packages? There is a lot of (gnu packages x) <ieure>YAR_Oracool, No. This would be very slow if it existed. <ieure>There's the short syntax, if you like (use-package-modules foo bar baz) is equivalent to (use-modules (gnu packages foo) (gnu packages bar) (gnu packages baz)). <ieure>But it only works for things in Guix, no third-party channels. <YAR_Oracool>ok... sure.. .but then why do I also have to say (packages (cons* x y z? <YAR_Oracool>Because it's basically writting the package names twice. <ieure>Yes, but doing totally different things. use-modules / use-package-modules imports the package symbols into the scope of the file, (packages (cons* foo bar)) uses them. <ieure>Guix uses the Guile Scheme programming language for it's configuration. This behavior is typical of any programming language with a module or package system. Python, Ruby, Java, Common Lisp, JavaScript, Go, etc etc. All work that way. <ieure>Also the modules you import almost always contain multiple packages. Every package for Emacs is in (gnu packages emacs-xyz). So you're not always repeating the symbols. <YAR_Oracool>Ye.. .I was very supprised when I had to do packages emacs <ieure>Guix is very easy to make your own. It's a very hackable distro. <YAR_Oracool>Your tip about the location field worked. Thanks mate. <YAR_Oracool>I'm suprised GUIX has DRM packages for DVDs and Bluray... <YAR_Oracool>Never thought I'd see that there but ey... that makes it viable for me to use. <ieure>YAR_Oracool, As long as it's Free Software. <ieure>Well, it's old and broken DRM. <YAR_Oracool>I still use blurays and DVDs like a caveman so I need it <ieure>It's not like Widevine, which is DRM and also proprietary / closed-source. <ieure>YAR_Oracool, It's what's used for internet streaming sites like Netflix, Prime Video, etc. <ieure>If someone made a cleanroom Free Software reimplementation of Widevine, that'd probably be allowed in. <YAR_Oracool>I have an aversiion to subscriptions so I don't really face that. <ieure>But the ability to use the things you pay for (including subscriptions) in the way you choose is core to the Free Software ethos. And these days, that includes stuff with DRM. <Gooberpatrol66>guix pull: error: Git error: failed to connect to git.guix.gnu.org: Operation timed out <YAR_Oracool>Well.. .aaa there can be a way... but discussion of non guix isn't allowed <YAR_Oracool>I do have to maitain some packages for my own use a bit down the line since they don't really exist in guix. Like lutris. <YAR_Oracool>Dunno why that's not in the repo. I thought it was foss. <ieure>YAR_Oracool, No, it's because Guix is a volunteer project and nothing gets done unless it scratches someone's itch to do it; and that didn't. <ieure>Disappointing how many Free Software projects are using the slop factories. <YAR_Oracool>ieure: Well.. .guess I start the legwork soon since I need it for those.. .pesky windows programs and games on itch.io <ieure>Gooberpatrol66, What a horrible attitude from the maintainer. <ieure>YAR_Oracool, As long as the software itself is Free, it can go into Guix, even if its purpose is almost completely working with non-Free stuff. <YAR_Oracool>ieure: It's not gonna go away... my problem is that people use it instead of learning the language.. .which isn't great when you need to fix things. <ieure>YAR_Oracool, I was going to suggest that you contribute Lutris, but after seeing what's up with the project... I wouldn't. <ieure>YAR_Oracool, I agree that it's not going to go away, but I don't think it's going to exist in anything like its current form, either. <YAR_Oracool>ieure: Dunno about that. I theonk for the sake of corporate interest, They'll change the copyright law. <ieure>YAR_Oracool, All about the money. The product is heavily subsidized and I think much less attractive to use -- especially for Free Software projects -- once it's priced at what it costs to operate. <YAR_Oracool>Maintaining the package for guix isn't nessessarily contributing. Even if it was. these guys in a way bigger league then me in terms of programing. <ieure>Eh, it's fine. Guix doesn't have maintainers like other distros do. It's all cooperative volunteering. <ieure>I contributed a Firefox fork (LibreWolf) and have kept it current for a couple years, I can't write Rust at all. <YAR_Oracool>I tend to run AI locally. as I said.. .I do not pay subsciptions. If I want AI. I run it on my end. I didnt pay freaking adobe.. .I'm not paying Clude or whatever. <ieure>Any LLM is ethically untenable for me, I don't use it at all, ever. <YAR_Oracool>I use it to make custom websites if I need to remain annonymus. <YAR_Oracool>Good thing abt guix is thattechnically anyone can maintain anything sice any git repo can be a channel <YAR_Oracool>So.. .I want a package... I just throw it in a repo and there we go. a package for guix and everyone can use it. <YAR_Oracool>I never did any.. .co op with anyone on a repo so I'm kinda afraid to touch official repos as maintainer. <Guest3725>I just noticed `dpkg` is a Guix package. If I install it, can I install `.deb`s on Guix System? <adanska>sneek, tell Rutherther: Thanks for your help by the way! The package cloning trick is now working flawlessly! Everything is getting built for aarch64-linux except kernel which is natively cross compiled. Its a pretty neat trick, I wonder if there's a case to be made for putting this little trick into the Cookbook..? <sneek>Rutherther:, adanska says: Thanks for your help by the way! The package cloning trick is now working flawlessly! Everything is getting built for aarch64-linux except kernel which is natively cross compiled. Its a pretty neat trick, I wonder if there's a case to be made for putting this little trick into the Cookbook..? <dcunit3d>i'm using the "base-channels.scm" workflow, where i run `guix describe --format=channels > ~/.config/guix/channels.scm" after the appropriate pull <dcunit3d>should i expect to be able to `guix copy --to=me@adesktop $(readlink -f ~/.config/guix/current)` <dcunit3d>then run `ssh me@adesktop -- guix pull -C ~/.config/guix/channels.scm` if i've updated that "channels.scm" file? <dcunit3d>i've used `guix copy` with my doom emacs profile. that seemed to work <dcunit3d>but i know guix needs to evaluate channels.scm to produce a derivation. <dcunit3d>once it does that, shouldn't the upgrade process be faster? <dcunit3d>also note: i use `guix pull -L $mybadchannel -C ~/.dotfiles/.config/guix/base-channels.scm` <dcunit3d>hmmm for intensive purposes ... that does seem to be what happened <dcunit3d>yeh guix is way better btw... determinism ftw <dcunit3d>one problem is that my omarchy bash has some weird settings. running hash guix reports "hash is disabled" <dcunit3d>and `ssh me@ahost -- guix describe --format=channels` seems to show only the guix channel for some reason. <dcunit3d>but new console sessions on that computer show $XDG_CONFIG_HOME/guix/channels.scm is identical to the `guix describe --format=channels` which i pulled from git <dcunit3d>well this definitely had worked before, now it wants to download texlive again, which is what i avoided last time... hmmm i think my assumptions are incorrect or i should've done everything immediately <dcunit3d>i usually (1) desktop: guix pull, then update channels.scm (2) desktop: update doom profile (3) commit channels.scm to dotfiles, then git pull dotfiles on laptop <dcunit3d>then (4) laptop: guix pull with new channels, so both laptop/desktop are in sync (5) laptop: update doom profile, which is where i had used `guix copy` before in a time crunch <dcunit3d>this time, i instead used tried to update my guix on my laptop. it reports the same channels.scm ... but isn't matching hashes and goes right to finding derivation outputs from substitutes. (this is after derivation calculation, i think, so it should know it already has them) <dcunit3d>when using guix archive, do i need to specify the order of entries in "/etc/guix/acl"? <dcunit3d>YAR_Oracool: yes... i tried using basic emacs. <dcunit3d>i don't use evil-mode though and i have a few basic profiles set up for when i need a basic emacs with consult/magit/etc <efraim>I've never heard the order of /etc/guix/acl mattering <dcunit3d>i think something happened when i updated the main guix profile using `guix copy` then `guix pull -C ~/.config/guix/channels.scm`. that also needed to rebuild <dcunit3d>i guess it looks for at least one substitute provider with that hash <PotentialUser-1>I feel like a complete idiot. I can't even figure out how to set the terminal font in Guix. <yarl>PotentialUser-1: Can you share (the part of) your config failing (paste.debian.net) and the complete error message please? <Rutherther>adanska: I think that generally this could go into cookbook - how to natively compile except for something. As for the linux edge case, I would much rather it was just supported instead of needing to resort to such hacks <adanska>Rutherther, indeed. Well, I might draft up a patch some day if I have the whim. As for supporting a gexp input for the kernel, that would be good. I haven't had a look at the code path yet, but I wonder why a gexp cannot exist there. Surely it's just a matter of lowering it at eval time? <adanska>of course it's not, but im just curious as to why it isnt possible in that field specifically atm <Rutherther>adanska: I think it's mainly that linux-module build system that inherits, so it expects a package. I am not sure what can be done about it, though <csantosb>andreas-e: Hi Andreas ! I think we're good to merge hpc now, I'll have a look at the new failures later on. <andreas-e>Well, not the branch itself, but it is possible that the data service drops the information. I do not know actually. <csantosb>I have the json file; I'm just a bit surprised by the `rocm-validationsuite` failure. <andreas-e>This one I overlooked, the others look like a hodgepodge of things that may or may not even be related to the hpc branch. As to rocm, I am seeing a lot of back and forth on Codeberg recently, it seems to be very volatile. <andreas-e>In any case, it is a "leaf cluster", so can be handled on master. <csantosb>ROCm is; vulkan and associated are deep in the graph. <efraim>do we have a make target to check that patches are registered? <pastaya>does anyone know how a "niri-configuration" record looks like <pastaya>"For more advanced configurations, you can customize the service with a niri-configuration record to specify additional environment variables." <identity>like (make-niri-configuration (list "VAR=val")) <identity>pleased to discover that what with git takes ‹git push origin HEAD:refs/for/master --option topic="my-awesome-topic"›, with Jujutsu is just ‹jj gerrit upload --topic "my-awesome-topic"› <pastaya>when is a nushell home service type coming <identity>pastaya: you could be the one to write it :3 <pastaya>i might try but i literally just installed guix system like 20 minutes ago <pastaya>i still need to learn a bit of guile <identity>i would guess a lot of people here, if not most of them, are using Emacs in some capacity <nmeum>how do I check for circular dependencies? specifically, I would like to make binutils depend on perl but I am not sure if that would introduce a cyclic dependency. is there tooling to figure that out based on the dependency graph? <nmeum>it builds, so does that mean there is no cyclic dependency? <Rutherther>nmeum: yes, if there was a cyclic dependency you would get an error during evaluation <Rutherther>nmeum: to check, you can use guix graph --path between two packages you want to check <Rutherther>make sure to use --expression to match the exact guile symbol you want to check <pastaya>editing config.scm without show-paren-mode and electric-pair-mode is the biggest mistake i have ever made <noe>nmeum, in these cases it can be good to set the user-reviewed tag <nmeum>noe: I think I don't have the required permissions to change labels <bjc>what's the guile procedure for printing a value and returning it? <identity>and there also should be pke for printing to stderr <bjc>oh it's short for “peek”. maybe that'll help me remember <podiki>efraim: thanks for rebasing mesa-updates; any updates on the cargo approach or should we go with what we have currently on there? <andreas-e>podiki: The rebasing was me. So do you think it would be good to add the glibc ungraft? How many packages do you expect to be affected by mesa-updates? <podiki>andreas-e: thanks! that is exactly what i was just thinking about <podiki>seems core-updates-team isn't close and the glibc graft is pretty onerous on everyone doing guix operations <andreas-e>kde-team was also pushed, so gnome-team is next with about 10000 packages. That should take between a few days and a week. <andreas-e>The glibc graft requires a lot of storage space in the end. <podiki>mesa is ~6k itself, i don't think we have anything else on there currently that would change that? but i should check pending PRs <bjc>is there a core-updates coming? is that still a thing? <podiki>core-packages-team i should have said <andreas-e>core-packages-team has not yet filed a merge request. data.qa has started a mesa-updates evaluation about an hour ago, we should soon see the number of packages. <podiki>x86-64 and i686 only on that jobset though <podiki>maybe from libdrm and wayland-protocols, besides mesa itself <podiki>yeah, libdrm is ~16.7k dependents <Rutherther>so adding glibc ungraft would be only ~2x, right? <podiki>i think so? in any event i'm inclined to do it or else it will linger <andreas-e>"guix refresh -l glibc" shows 2800 packages; then everything should depend on glibc, no? But maybe not everything is concerned by the ungrafting. <andreas-e>It would be nice to do it now, the following branches are smaller. <ieure>andreas-e, I think that only shows direct dependents, not the whole tree. I assume glibc would cause a world rebuild (or so close to it as makes no meaningful difference). <podiki>well i'll go ahead and bump mesa and do the ungraft later, and find somewhere to let core-team know <podiki>or actually i might hold off a day or so to search for other patches i'm missing on there first <andreas-e>There is also a comment in glibc/fixed that a patch should be moved to glibc when ungrafting. <Rutherther>andreas-e: you're checking wrong glibc "guix refresh -l --expression="(@ (gnu packages commencement) glibc-final)"", it's 33532 <podiki>the ungraft is just basically the new patch going to the glibc patches list <Rutherther>ieure: guix refresh -l looks transitively, it shows all dependents <podiki>Rutherther: thanks, yeah nearly exactly 2x libdrm for future reference <civodul>andreas-e: ‘guix refresh -l glibc’ isn’t the same as ‘guix refresh -l -e '(@ (gnu packages commencement) glibc-final)'’ <civodul>oh now i see i’m just repeating what Rutherther wrote :-) <Rutherther>it's a common misconception, it needs to be repeated :) <podiki>civodul: any thoughts or objections on the glibc ungraft on mesa-updates? it will just be removing the replacement and putting the new patch on the glibc patch list (but i know core-team has other glibc stuff) <cilekes>Hello. I use Anki, and it seems it was removed from Guix’s package database a few months ago. Are Guix developers planning to add it back, or has the package been completely abandoned? <futurile>cilekes: if it was removed it most probably means it's abandoned <podiki>cilekes: the anki situation is unfortunately very difficult to package in guix currently (combo of python, rust i think, the way it expects to be built downloading sources, etc.) <podiki>(i'll actually have a current package of it in a different channel later today, but i don't see making it in guix without lots of extra work) <ash_2026>Тут есть, у кого русский язык родной? предлагаю пообщаться на #guix-ru <podiki>sounds like they will move away from their whole launcher system, which might help though <futurile>oh wow, I don't use it, but even reading their install page it's a bit yuck <cilekes>podiki: Is it available through third-party Guix channels? <podiki>it is a mess and maddening for a downstream package <podiki>cilekes: can't speak for other channels and someone having it, but i don't think so? <futurile>looks like there's an old version, and not in nonguix (someone tried) <podiki>seems that index needs an update though (not in guix anymore) <cilekes>It’s the only package keeping me from using Guix. The Flatpak version isn’t stable, and I don’t want to install programs any way other than through Guix if I use Guix System. <efraim>I may have a fix for the qtbase->libcamera->gtk issue, but I'm having issues with removing outputs in my new libcamera-minimal <efraim>for libcamera-minimal I've set the outputs to just '("out") but 'compress-documentation tries to compress the doc output also <Rutherther>efraim: huh, it makes for-each on the outputs, so I don't understand how it could see an output that doesn't exist <futurile>cilekes: I would ask in the #nonguix repo. But if the "Flatpak" version isn't stable it sounds pretty difficult since there are a lot of people working on Flatpak packages generally. The only other fallback would be a small VM, but not great I admit <efraim>Rutherther: probably uses the inherited 'compress-documentation phase instead of recalculating the #$outputs <efraim>I might just replace that phase with itself <cilekes>futurile: I see, thanks for your help. <Rutherther>tschilp: presumably you aren't using the (gnu system nss) module, but it's impossible to say since you haven't sent your full config... <andreas-e>For anki, I understood that it now also depends on npm packages, which makes it essentially impossible to add to Guix. <Rutherther>efraim: but it shouldn't matter, compress-documentation uses the argument "outputs" which always matches the current package, it doesn't use gexps <efraim>I've modified the intherited package, including the phases, so the rest of the phases "fall through". or something <Rutherther>efraim: yes, but unless you've done something weird the phases are called from gnu-build procedure where it supplies the arguments, including outputs, for current package, not the one you inherited <tschilp>Rutherther: I have ~(gnu system nss)~ in ~(use modules)~ -- is this the correct place? <tschilp>Mhm, then it has to be something else... <ieure>tschilp, Something else in your config maybe? Are your parens balanced? I've seen this kind of error sometimes with unbalanced parens. <Rutherther>efraim: you're explicitly passing #$outputs, that's the weird thing. Instead you should be passing the outputs argument from args <efraim>my default phases are wrong, but it technically shouldn't matter since I used the inherited ones <Rutherther>efraim: I expect your fix is not going to work because the first argument is going to be matched, I think "(cons* #:outputs #$outputs args)" should work. Or does it work like you have it now? <efraim>Rutherther: what I have now doesn't work. I thought it was last match, not first match <Rutherther>but I don't really know why it's failing without that override <efraim>at least we know it's first match <yelninei>podiki: if you are ungrafting glibc, you could merge glibc and glibc/hurd again as well, there is also another graft for libvpx <efraim>Rutherther: ok, back to it being a me problem, 'compress-documentation succeeded, something else expects the :doc output <efraim>there's nothing aftercompress-documentation <yelninei>i586-gnu substitutes are looking good, x86_64-gnu are failing as expected until the build machines are rebuild <Rutherther>but how is that possible when the doc output doesn't exist... <efraim>I ran into this with qemu-minimal also <Rutherther>I am wondering if that move-doc-and-gst could somehow 'propagate' the information about the output being there <efraim> ;; We cannot fully remove the "doc" output due to the gexp in qemu. <podiki>yelninei: as in glibc/hurd should be incorporated into glibc? (sorry don't have the code in front of me right now); it is a hurd-only variant made to not change current glibc? <yelninei>podiki: yes, it has some hurd specific patches removed and new ones added <efraim>well this is interesting, as long as I create the "doc" and "gst" outputs I can leave (outputs '("out")) and ./pre-inst-env guix show libcamera-minimal only shows the "out" output <Rutherther>efraim: how did you create them? like mkdir #$output:doc? <podiki>yelninei: will take a look later then, but if anything is not obvious feel free to tag me in a PR against mesa-updates :) <Rutherther>I am wondering if this is a fixable bug or a design issue that won't be solvable at all <efraim>I could just swap the inheritance, I think that's what I normally end up doing in this situation <efraim>I'm going to switch from #$output:doc to (assoc-ref outputs "doc") and see if it still works, but I expect it to fail hard on that change <Rutherther>imo it's better to add inputs rather than remove them, it's less cumbersome, so I would default to inheriting from libcamera-minimal. I expected you've done it this way to not change the original package derivation <efraim>my diff was like 20 lines, mostly boilerplate <efraim>full package inheriting from the minimal also prevents all the issues we've had with libinput <efraim>as expected, (assoc-ref outputs "doc") failed <efraim>did we want to add the virtio vulkan-driver for any targets in mesa in mesa-updates? <pastaya>do you guys think theres a bit too little packages on guix <yelninei>backporting x86_64-gnu support to gcc-11 seems easier than I thought, still a bit stuck to get dmd to work properly <efraim>yelninei: dmd for dlang? I'd with gdmd@15 first, it works for onedrive <yelninei>efraim: i have the i586-gnu gdc-11 and gdc-14 more or less working. The reason i want to move to dmd is to easily run the druntime/phobos tests and skip building the lengthy non gdc parts of gcc just for testing a small change. also as dmd is upstream of gdc it is where I would need to add the pr anyway <efraim>yelninei: that makes a lot of sense <yelninei>for dmd i am currently a bit stuck with some c/c++ interop segfaulting. I am able to build it and it can rebuild itself but some tests fail because of this <yelninei>the same d code build with gdc works so i guess it is something with the dmd codegen which i dont understand at all, all i have done is added the hurd targets to places where it checks for linux/bsd <yelninei>maybe i should ask the d people for help <podiki>efraim: i'm always good with adding drivers, might as well have them available. speaking of, was there a reason to remove the legacy dri2 one? i had added it from someone's patch the last cycle (older hardware support) <pastaya>do you guys think theres a bit too little packages on guix <ekaitz>pastaya: nah, we have too many already <csantosb>Hi ! I know there is an elegant way to write this awful changelog, #7181, but how ? Anyone with an example ? <identity>if only you could just throw the list into ‘regexp-opt’… i am afraid you will have to list every file, with something like * gnu/packages/whatever.scm \n … \n gnu/packages/other-whatever.scm: Update imports <csantosb>There is a clever way, I did that in the past, but I don't remember how, hard to find it with so many commits around <identity>gnu/packages/{whatever,other-whatever}.scm is the ‹too clever› style according to (info "(standards) Style of Change Logs") <identity>not sure if keeping with the GNU Change Log format is a good idea if we keep having «and then change it in 50 files» commits… or maybe we should stop having the 50 files, the work on which is on-going, and is the cause of the «and then change it in 50 files» commits <identity>to stop having «change it in 50 files» commits we need more «change it in 50 files» commits <lilyp>Global commits like these are few and far in-between, and deserve to be annoying in ChangeLog terms. <lilyp>The alternative is a slow roll-out: introduce a feature within a specific scope, then use it elsewhere as you update the code. <lilyp>See G-Expressions in arguments as an example. <Wurt>I came across the draft 'The Egg of the Phoenix: a computational time capsule.' I believe the bootstrapping problem is related. Does anyone have any resources that connect these topics? <ieure>There are a lot of good references on the Collapse OS site. I think their overall diagnosis is probably close to the mark, but I do not feel confident that the actual stack they created is going to be very useful. <Wurt>I think it's a little paradoxical that pessimism serves as a good incentive for these hopeful projects. <PotentialUser-7>Something in Guix system is printing `localhost -- MARK --` to stdout every 10 minutes. How do I figure out where this is coming from? <ieure>PotentialUser-7, I believe it's syslog. I have noticed the same thing, it prints to tty1. <ieure>You can turn that off, but tty1 tends to get a lot of log type stuff printed to it, not sure why. <PotentialUser-7>Interesting, thanks. It appears to happen with a fresh system install across several machines. <Rutherther>ieure: it's the default active console, you get dmesg output there on Linux <PotentialUser-46>Hello. I'm trying learn how to do things the Guix way. So I'm looking into creating a manifest.scm file for a new project of mine. <PotentialUser-46>The problem is that I need to use a Python package that is not packaged in Guix, but `guix import` seems to handle that. <PotentialUser-46>Question: Can I combine the package "recipe" in the manifest file? I tried but I'm getting an error. <PotentialUser-46>`specifications->manifest` seems to require strings, so I wrote this (in pastebin, below), but it still gives an error (also in pastebin). <AlgorithmicInfor>Does anyone know if there is any efficient, reproducible way to run an arbitrary program to capture it's memory usage, and be able to reproduce that exact memory dump deterministically later on? <AlgorithmicInfor>I would also like to note by arbitrary program, I mean one that generally runs deterministically like a compressor, not an adversarial program. <PotentialUser-7>For several packages, e.g. dbus-configuration, I get an error "dependencies couldn't be built" when I try to `guix system reconfigure`. How do I figure out what's going wrong? <PotentialUser-7>(I was under the impression that guix was supposed to avoid precisely these issues) <PotentialUser-46>PotentialUser-7 Yeah, I got a few surprises with some Guix. There are some situations that seem unavoidable. <PotentialUser-46>Someone may correct me, but, for example, you need to compile something locally (no substitute available), that compilation may fail (out of memory, out of disk space, or some bug-like issue that was not caught). <PotentialUser-46>Sadly I have seen patches that fail in the CI system being applied anyway. <PotentialUser-7>It's confusing because the same configuration works on another machine :/ <PotentialUser-46>PotentialUser-7 There may be a log file with details mentioned somewhere in the output. Other that that information, I would suggest that you try again in a few days. <PotentialUser-46>It is not just the configuration. You may be using different versions of a channel. <PotentialUser-7>Yeah, maybe. The error above is from the log file. Unfortunately, there isn't much useful (at least to me) information in there <PotentialUser-46>You can try "pinning" the channel to match the state that succeeds in the other machine. <PotentialUser-7>Thanks, I'll try to investigate further and then try that if all else fails.