9fans
Repos
5

Events

started
Created at 4 hours ago
started
Created at 20 hours ago
started
Created at 22 hours ago
started
Created at 1 day ago
started
Created at 3 days ago
started
Created at 5 days ago
started
Created at 5 days ago
Created at 5 days ago
opened issue
32-bit build prevents compilation on newer macOS releases

While vx32 is a fundamentally 32-bit environment, newer releases of macOS require that all binaries be 64-bit.

How feasible would it be to update vx32 in such a way that it could compile and run as a 64-bit application, but keeping it such that the binaries it runs remain 32-bit only?

Created at 5 days ago
started
Created at 1 week ago
issue comment
Dockerfile to build plan9port in Alpine Linux container

Seems strange to have a Perl requirement, did you confirm if that was needed?

I entirely agree! It only added about 35MB to a 350-400MB image so I left it in to be safe.

I confirmed a number of calls to perl are definitely in the installation code (by simply using Ctrl+F). I believe there was even a commit to specifically call /usr/bin/perl for BSD, relying on my unreliable memory.

I cannot confirm removing perl breaks anything(*) when plan9port is built via a Dockerfile being built. So if perl's not redundant, and something else is broken without it I'm unaware of, perhaps someoen could add a PR that causes the build process should fail more noisily in the absence of perl?

(*) I've only tested running rc and calling ls in it

Created at 1 week ago
issue comment
Dockerfile to build plan9port in Alpine Linux container

Seems strange to have a Perl requirement, did you confirm if that was needed?

Created at 1 week ago
pull request opened
Dockerfile to build plan9port in Alpine Linux container

Hi all.
I'm adding this for others to show which packages are definitely needed in the host environment to build plan9port, and maybe even spin up a container for themselves easily. When building from a docker file, certain errors seem to be suppressed. I hadn't noticed perl was being used at first. So it is possible I've unwittingly removed something essential. But rc seems to work on the surface.

A .gitattributes file is also included. This reduces the pain for Windows users building Docker images from a local plan9port repo (otherwise Git may change the line endings to crlf).

I haven't had much joy with https://pkgs.alpinelinux.org/package/edge/community/x86/plan9port (perhaps I hadn't carried out a final configuration step, but it appears some build directories are hardcoded into it).

This image did work: https://hub.docker.com/r/plan9d/plan9port but I've no clue what was in the hashes it builds from, so I reverse engineered it by diffing apk list--installed with alpine:build-base, and afterwards stripped out the packages unnecessary, simply to compile plan9port, by trial and error.

Created at 1 week ago
Created at 1 week ago
Created at 1 week ago
started
Created at 2 weeks ago
issue comment
acme: allow multiple instances

Yes, wily is an alternative that I could consider. However, the issue is that the current p9p acme functionality requires an additional workaround to allow multiple instances to run simultaneously. There are a number of workarounds listed on the mailing list, but it seems there are no patches that can be merged into upstream plan9port.

I think it would be nicer to support multiple instances of acme (and certain other ported programs which suffer from the same problem) directly in plan9port. I could try writing a diff and opening a pull request, but I don't expect to properly get around to writing one in the near future (I am rather busy at the moment).

Created at 2 weeks ago
started
Created at 2 weeks ago
started
Created at 2 weeks ago
pull request opened
Fix unix build

It seems there is a slight impedance mismatch between extproc and system.Open: the latter returns an int, the former expects a *os.File.

Built on linux, go version 1.20

Created at 2 weeks ago
fork
Created at 2 weeks ago
started
Created at 2 weeks ago
started
Created at 2 weeks ago
issue comment
acme: allow multiple instances

https://github.com/9wm/wily [running autoreconf to generate configure script]

unaware of your specific requirements one might consider to run also an instance of wily

Created at 3 weeks ago
fork
Created at 3 weeks ago
issue comment
imageinit: can't open font
$ grep -n "can't open font" /opt/plan9/src/libdraw/init.c
73:             fprint(2, "imageinit: can't open font %s: %r\n", fontname);
$ grep -n "can't open display" /opt/plan9/src/cmd/acme/acme.c
162:            fprint(2, "acme: can't open display: %r\n");
167:            fprint(2, "acme: can't open display: %r\n");
$ 

Have you incorrect permissions on the files?

$ tree --noreport -L 1 -d /opt/plan9
/opt/plan9
|-- acid
|-- bin
|-- dict
|-- dist
|-- face
|-- font
|-- include
|-- lib
|-- lp
|-- mac
|-- mail
|-- man
|-- ndb
|-- news
|-- plumb
|-- postscript
|-- proto
|-- sky
|-- src
|-- tmac
|-- troff
`-- unix
$ 
Created at 3 weeks ago
Created at 3 weeks ago
started
Created at 3 weeks ago