qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
<MichaelRaskin> Don't you just rebase on Nixpkgs master from time to time?
<qyliss> No I merge
<qyliss> In case other people are following
<qyliss> I'm not rewriting history at this point
<qyliss> And haven't done since I made the Git repos public
<MichaelRaskin> Ah OK
<qyliss> MichaelRaskin: do you know git worktree?
<MichaelRaskin> Nope
<qyliss> git worktree add /tmp/nixpkgs-rust9p
<MichaelRaskin> I mean, by now I already have a -s clone
<MichaelRaskin> And maybe it would make sense to just have one more
<qyliss> It lets you have multiple working trees for one repository
<qyliss> I only have one Nixpkgs clone, but 10 or so working trees
<qyliss> /home/src/{nixlib,nixpkgs,nixpkgs-spectrum}, etc
<MichaelRaskin> What happens when the /tmp-living worktree disappears in an mkfs?
<qyliss> git will notice it's gone when it gcs, I tihnk
<MichaelRaskin> Hm
<qyliss> It certainly doesn't care if it disappears
<MichaelRaskin> OK…
<qyliss> You can git worktree prune manually, too
<MichaelRaskin> Nah, I don't care about it storing a bit too much (git doesn't store enough anyway)
<MichaelRaskin> I did have unfixable corrupted git repos though
<qyliss> Right now I'm experimenting with diod because it was already packaged.
<qyliss> But I don't actually want to be using a 9p server written in C
<MichaelRaskin> Indeed
<MichaelRaskin> OK, let's try to get a worktree
<MichaelRaskin> rust-9p is not that sensitive to rust versions (I hope) (in uses unstable features) (and so RUST_BOOTSTRAP)
<MichaelRaskin> Building against Nixpkgs master…
<qyliss> Just saw the PR :)
<MichaelRaskin> You ask to get it upstream earlier, you get the mention
<MichaelRaskin> Not sure it is worth a PR instead of direct push, but oh well, let's run the ofBorg checks
<qyliss> your style is a little unusual, isn't it?
<MichaelRaskin> It's buildRustPackage, _and_ upstream uses a multi-crate non-flat layout
<qyliss> No I mean like "{\n"
<MichaelRaskin> I cloned the most similar Rust package, I think
<MichaelRaskin> This might have been a copypasted part
<MichaelRaskin> My default package file header is one-line
<MichaelRaskin> (if everything fits)
<MichaelRaskin> I have no idea what is the origin of the formatiing in the package I have cloned
<MichaelRaskin> Worse, I am no longer sure which package it was
<qyliss> My nixpkgs doesn't even have rust.packages
<qyliss> Is that extremely new?
<qyliss> Oh it does
<qyliss> but no users of it
<MichaelRaskin> Hehe
<MichaelRaskin> We-ell
<MichaelRaskin> I hoped to get unstable rust this way
<MichaelRaskin> But failed
<qyliss> But it works with stable?
<qyliss> Did you copy racer or racerd perchance?
<MichaelRaskin> I wouldn't call it fully works…
<qyliss> Those are the only ones with the unusual lack of spaces around the RUSTC_BOOTSTRAP assignment.
<qyliss> What do you mean?
<MichaelRaskin> It needs RUST_BOOTSTRAP=1
<qyliss> What does that do?
<MichaelRaskin> This was probably hacked in after the initial cloning.
<MichaelRaskin> I think it is needed for next rustc that uses now-stable features. Because the old rustc considers them unstable
<MichaelRaskin> But some packages abuse it
<qyliss> oh, right.
<qyliss> hmm.
<qyliss> Do you know what unstable features it requires?
<qyliss> I'm a bit concerned about RUSTC_BOOTSTRAP being used in Nixpkgs at all
<MichaelRaskin> try_trait; it is indeed still unstable in upstream Rust repo
<qyliss> Wonder if we'd be better just patching that out
<MichaelRaskin> I think it actually _uses_ the feature
<qyliss> It does
<MichaelRaskin> Not just declares it
<qyliss> But only for one impl
<qyliss> And I'm not even sure why
<qyliss> pub struct SResult<T>(::std::io::Result<T>);
<qyliss> Oh, horrible operator overloading
<qyliss> Maybe I should ask a Rust person if RUSTC_BOOTSTRAP seems like a safe thing to do
<qyliss> (spacekookie?)
<spacekookie> I don't actually know, sorry
<spacekookie> Prodding eddyb might be good
<MichaelRaskin> Well, safe in what range if Rust versions?
<MichaelRaskin> The feature will probably be changed in an incompatible way at some point
<qyliss> Yeah...
<MichaelRaskin> Then we will see how upstream reacts
<MichaelRaskin> Oh cool, ofBorg has achieved some progress in running the checks
<qyliss> Well I do approve of how rust-9p just works, unlike diod or u9fs
<qyliss> So, once I figure out how to bridge two tap devices together, that's a milestone I think
tilpner_ has joined #spectrum
tilpner has quit [Ping timeout: 240 seconds]
<qyliss> Leaving this here for my own future reference: https://lists.ozlabs.org/pipermail/lguest/2008-March/001064.html
jpo has quit [Ping timeout: 265 seconds]
jpo has joined #spectrum
<MichaelRaskin> So far I find the overhead of socks proxying everything acceptable more often than not
<MichaelRaskin> But yeah, if you are OK with host-namespace-level IP traffic, you should just use a bridge. Or reuse the same TAP interface, by the way
<MichaelRaskin> ARGHHH
<MichaelRaskin> I _think_ I know what was the problem now…
<MichaelRaskin> OK, on the host I should set the nodad (skip duplicate address detection) option, otherwise I need to wait for the dup-detection in the empty network
<MichaelRaskin> This at least gives me proxy.
<MichaelRaskin> I seem to be able to access the permitted ports, but 9p mount requires something more
tilpner_ is now known as tilpner
pie_ has quit [Ping timeout: 258 seconds]
pie_ has joined #spectrum
pie__ has joined #spectrum
pie_ has quit [Ping timeout: 260 seconds]
<tazjin> qyliss: I've been doing some cgit quality-of-life improvements that you're welcome to steal, namely I wrote a filter in Rust that can syntax highlight individual files and render Markdown with properly highlighted code snippets: https://git.tazj.in/tree/tools/cheddar
<tazjin> iirc you mentioned Markdown rendering in the repo the other day
pie__ has quit [Ping timeout: 260 seconds]
<MichaelRaskin> qyliss: re: bridging: by the way, what should bridging give you beyond what a shared TAP device with a firewall would give
<MichaelRaskin> Mystery solved
<MichaelRaskin> sin_server.sin_family = AF_INET;
<MichaelRaskin> Yep, 9p over TCP support in the Linux kernel assumes IPv4.
* multi rolls eyes
<MichaelRaskin> Well, one could always do a NAT46 insided the VM
<MichaelRaskin> But after finding this line in net/9p/trans_fd.c I am more on the «Just use a private IPv4 subnet» side
<puck> oh yeah i hit this issue before
<puck> i ran 9p over wireguard at some point (inside a container) -- but i wanted v6 only in the wireguard bits :(
<MichaelRaskin> Well, you could do endpoint NAT 4-to-6
<multi> alternatively, you could use some sort of userland proxy (such as a combination of s6-ipcserver, s6-tcpclient and s6-ioconnect) if you hard-require single stack v6 network traversal
<multi> and connect to a unix socket and have the connection forwarded over tcp
<MichaelRaskin> I already have a few layers of socat forwarding the stuff
<multi> fair enough
<MichaelRaskin> I mean, in my case it is a fully contained IPv4 subnet _only_ used for VM TAP connecting to socats carrying the actual socket connections
<MichaelRaskin> And I think the dream for SpectrumOS mainline (which I won'y use directly, but I hope to reuse a lot of code from there) is to have just direct sockets one way or another from VM to VM without host-level IP traffic and with virtio 9p mounts