<h​andpickencounter:matrix.org> Nowhere in the documentation does it mention whether or not you can specify a unix domain socket (UDS) proxy and in what format. Tor provides UDS socks5 proxy when configured. Is it available for monerod?

<h​andpickencounter:matrix.org> example usage: monerod running in empty network namespace. no possibility for any leaks.

why do so many people use a matrix bridge

vm or remote os

mullvad

BNC BRO i forgot about those

i'm a 90s efnet skid. alright yall be good now

<h​andpickencounter:matrix.org> also unclear if RPC can be served over UDS. workaround for both problems is to run SOCAT. however now you have two additional processes.

man installing guix pulls in a ton of crap that's totally irrelevant to the monero software being built

this is really the way of the future? pure bloat.

You want bloat? Try a "vibe coding" codebase

ogawd

i.e. people with zero knowledge copy pasted some unintelligible LLM crap

<o​frnxmr:monero.social> hyc, have you tried a btc guix build? (i have not). Wondering if same situation there

that is not software development...

that's not ANY development

ofrnxmr this is just installing the base guix system, so of course it must be the same there

That's just speedrunning idiocracy

<o​frnxmr:xmr.mx> Oh ok

I think this design approach is wrong. it means everyone who uses guix as a build system is running the identical guix binaries. if any guix repos get compromised, everyone will be using the same tainted binaries.

with gitian, we were using project-specific versions of source code to build our dependencies

using arbitrarily chosen versions of build tools

a single upstream tool repo exploit would not taint every builder's builds.

<t​obtoht:monero.social> hyc: I don't follow your argument. With gitian we trusted hundreds of opague packages provided by ubuntu, with guix we have full transparency and control over what source code is used to compile monero.

hmmm, ok good point

not off to a good start tho:

Invalid configuration 'viola': machine 'viola-unknown' not recognized

sha256sum: hosts/.mk: No such file or directory

sha256sum: hosts/.mk: No such file or directory

this was an `apt install guix` on ubuntu, then `guix pull`

<t​obtoht:monero.social> does depends support that target?

and then try to run contrib/guix/guix-build

all defaults

this is an x86-64 Ubuntu install, so what target does it think it's looking for?

<t​obtoht:monero.social> echo $HOSTS ? is it set to anything

"viola" is a hostname, not a target name

HOSTS is unset

<t​obtoht:monero.social> and HOST ?

HOST=viola

<t​obtoht:monero.social> ok, let me try to reproduce

.merge+ 9891

Added

shouldn't we discontinue arm-linux and i686-linux builds by now?

32bit is dead

<t​obtoht:monero.social> hyc: arm-linux is useful for raspberry pi since it still ships with a 32-bit OS by default

<t​obtoht:monero.social> I don't care for i686-linux

ah I thought pi5 finally defaulted to 64bit.

nuts...

<t​obtoht:monero.social> hyc: I was able to reproduce, I'll submit a fix for the script. In the meantime you can work around this with `env -u HOST ./contrib/guix/guix-build`.

ok

it's crunching along now ... I guess you guys never use csh on your machines

<t​obtoht:monero.social> need +1 approval on 9891

<t​obtoht:monero.social> thanks SyntheticBird (Matrix.org)

heh. looks like I just did a guix build of master, instead of the tagged release

hyc: we still use gitian on the release branch

doh

guix clean just wiped out all of my build subtrees. many of which had unique test data. ugh.

hyc: #9896

shouldn't it only be concerned with the contents of its own guix subtree?

why should it ever touch anything outside of that?

the monero source dir is bind-mounted into the guix build container

auto-generated files like the protobuf messages, leftover submodules or other untracked files may introduce non-determinism in the build process

hence why guix-build complains if the worktree is dirty

the upside to this approach is that build system changes can be tested rapidly (FORCE_DIRTY_WORKTREE=1 for dev builds when you don't care about reproducibility)

you can get a shell access to the build container, which makes updating depends packages a breeze for instance

hmm. now I'm getting I/O errors on my SSD. man, just hitting roadblocks everywhere trying to get a clean build

<s​yntheticbird:monero.social> POV me when I will need to call a wizard to enchant brand new CPUs and SSDs to build Monero with Guix during 12 hours because of Rust bootstrapping:

<s​yntheticbird:monero.social> The SSD and CPU will burn before the end of compilation.