I finally got the plan9port install to succeed! Here's the tail of the INSTALL output:
* Installing everything in /usr/local/plan9/bin...
* Cleaning up...
* Renaming hard-coded /usr/local/plan9 paths...
* Building web manual...
* Done.
* Add these to your profile environment.
PLAN9=/usr/local/plan9 export PLAN9
PATH=$PATH:$PLAN9/bin export PATH
root@hlcs:/usr/local/plan9#
I had to install several libraries. Here's a snip from .bash_history:
326 # reinstall plan9port after installing libx11-dev to get Xlib.h
327 ./INSTALL
328 date
329 apt-get install libxt-dev # to get Intrinsic.h
330 ./INSTALL
331 date
332 apt-get install libfontconfig1-dev # to get fontconfig.h
333 ./INSTALL
334 date
335 apt-get install libxcb-shape0-dev # This one didn't help to get shape.h.
336 ./INSTALL
337 date
338 apt-get install libxext-dev # to get shape.h
339 ./INSTALL # Success!
Maybe in other systems you have configured it to not use X11?
46 INSTALL writes various autodetected settings to
47 /usr/local/plan9/config. The file
48 /usr/local/plan9/LOCAL.config is appended to config after
49 this auto-detection and can be used to override the choices.
50 If LOCAL.config contains a line WSYSTYPE=nowsys then the
51 system is built without using X11. LOCAL.config may also
52 list settings for CC9 (the host C compiler) and CC9FLAGS
53 (any additional flags to pass to the compiler). Values more
54
55 Page 1 Plan 9 (printed 4/9/21)
56
57 INSTALL(1) INSTALL(1)
58
59 complex than single words should be quoted with single
60 quotes.
61
62 On most Linux systems, the X11 header packages need to be
63 installed to build using X11. On Debian. the required pack-
64 ages are libfontconfig1-dev, libx11-dev, libxext-dev, and
65 libxt-dev. On Ubuntu, it suffices to install xorg-dev.
Duh! So I confess to a bad habit of trying things without re-reading the instructions that I've forgotten after years of, as best as I can remember, installing plan9port on various systems with just ./INSTALL.
Duh! So maybe there might be some difference between the Debian image Hosteroid's installer uses and both the other providers' Debian images I have used as well as the official Debian images that I also have used. I'm not complaining about the Hosteroid image, which seems to work very well in all respects. Maybe somebody who build the Hosteroid image removed some less often useful on servers header files to save space?
Maybe in other systems you have configured it to not use X11?
I've never knowingly changed the plan9port build configuration as described on lines 50 and 51, above. Previously, as best I can remember, plan9port always just worked.
Maybe I can look around some more and figure out something more? At the least I do seem to have plan9port installed and working on hlcs -- the command line parts of plan9port, such as the ed editor, the p pager, awk, troff, and more are what's important to me. Someday maybe I will try the graphical parts, like acme, which might be the more important user applications plan9port brings from Plan 9.
Since ./INSTALL worked on the latter two installs, maybe it's the FONTSRV=fontsrv which caused the issue on Hosteroid. Maybe I can learn more about why that value is different on the Hosteroid Debian 12 versus the Hetzner Cloud Debian 12 and the NetBSD-current.
According to Hetrix Tools, it looks like we might have enjoyed a 2 minute IPv4 outage! The outage probably wasn't caused by our server because hlcs' uptime extends back beyond the outage and because there was no corresponding IPv6 outage reported.
From Hetrix Tools:
Back up:
One of your uptime monitors is now UP.
Monitor: Hosteroid LES Community Server IPv4 Ping Monitor
Target: xxx.xxx.xxx.xxx[ping]
Downtime: 2 min
Noticed at: 2024-12-12 11:09:34 (UTC+00:00)
Down:
One of your uptime monitors is now DOWN.
Monitor: Hosteroid LES Community Server IPv4 Ping Monitor
Target: xxx.xxx.xxx.xxx[ping]
Noticed at: 2024-12-12 11:07:34 (UTC+00:00)
Encountered errors:
Amsterdam: Timeout (5 sec)
London: Timeout (5 sec)
Warsaw: Timeout (5 sec)
Uptime:
root@hlcs:~# date
Thu Dec 12 10:24:05 PM UTC 2024
root@hlcs:~# uptime
22:24:09 up 2 days, 1:20, 4 users, load average: 0.00, 0.07, 0.40
root@hlcs:~#
Of course the short outage doesn't matter (aside from the Low End zillions we lost /s). Nevertheless, I'd love to know what happened. @Hosteroid, any ideas, please?
Thanks again to @Hosteroid for donating our lovely Community server!
We would love to accept more server Neighbors from the LES Community! If you are interested, please review How To Apply in the OP. Thanks!
@Hosteroid Thanks for your kind reply! Thanks also for introducing me to the above helpful and detailed output!
I asked Google Gemini what produced the output.
In case anybody is curious, I talk with Google Gemini on the command line via eliben/gemini-cli. The developer was kind enough to help me by adding to his project the $load facility so that gemini-cli could upload a file containing multi-line input instead of just single line chat. More info about and examples of the use of eliben/gemini-cli is available in this blog post, gemini-cli: Access Gemini models from the command-line.
The file uploaded to Gemini, post-4, looks like this:
Hello!
Please tell me what program provides output like the following:
--------Begin Sample Output--------
[ the full output @Hosteroid posted above, with certain items redacted]
--------End of Sample Output--------
Thanks!
Here is my conversation with Gemini:
chronos@penguin:~/gemini-cli$ clear; gemini-cli chat --model "gemini-1.5-pro-latest"
Chatting with gemini-1.5-pro-latest
Type 'exit' or 'quit' to exit, or '$load <file path>' to load a file
> $load post-4
This output is produced by the Juniper Networks Junos OS command `show interfaces extensive`. Specifically, it shows the detailed status and statistics of interface `ge-1/0/4`.
> Thanks!
You're welcome! Is there anything else I can help you with regarding this output or Junos OS?
> No thank you! All good for now, but more soon! :)
Great! I look forward to it. Have a good one!
> exit
chronos@penguin:~/gemini-cli$
Haha, if I am making a mistake here, or if the output isn't from JunOS, please let me know!
Thanks again @Hosteroid! Thanks again @eliben! Thanks again Google Gemini!
I'm looking forward to your upcoming weekend adventures!
Today, I'm compiling Wireshark out of NetBSD pkgsrc on our fine hlcs Debian 12 server. I'm doing it on hlcs partly to see if it works and partly because the build ran out of space on my wonderful Linveo NetBSD VPS.
If the Wireshark build doesn't break, maybe it will finish before the weekend!? As you know, pkgsrc builds are single threaded. . . . /s
Probably you noticed the file ipv6-up.sh in the /root directory? If you reboot, you probably have to run that script to re-establish IPv6. When I remember, I do restart IPv6 by hand that way because, on some servers, I have more than one IPv6 alternative, and I usually like to run only one at a time. So I sometimes have more than one ipv6-up.sh file. But, if you prefer, it's certainly okay to add the IPv6 info to /etc/network/interfaces or as a cron job or as a systemd service. The last two lines of the script are new. If they cause a problem, please comment them out.
I will stay off the server over the weekend, starting tomorrow, Friday, so that the server is free and clear for you to use. I hope you have fun!
@Not_Oles said:
Today, I'm compiling Wireshark out of NetBSD pkgsrc on our fine hlcs Debian 12 server. I'm doing it on hlcs partly to see if it works and partly because the build ran out of space on my wonderful Linveo NetBSD VPS.
The compile of Wireshark is still running!
The compile started at about
root@hlcs:/usr/pkgsrc/net/wireshark# date
Thu Dec 12 08:50:30 PM UTC 2024
root@hlcs:/usr/pkgsrc/net/wireshark# nohup make
nohup: ignoring input and appending output to 'nohup.out'
Right now
root@hlcs:/usr/pkgsrc/net/wireshark# ls -l nohup.out
-rw------- 1 root root 18263309 Dec 13 05:01 nohup.out
root@hlcs:/usr/pkgsrc/net/wireshark#
So far, 8 hours and 10 minutes, approximately, and still going! I saw what looked like llvm and rust being built, along with a lot of other dependencies. Here's what was happening as I looked at tail -f nohup.out in /usr/pkgsrc/net/wireshark a moment ago. It's getting late here, so time for sleep. Will the build finish by morning?
Looks like the Wireshark compile ran about three hours more and then stopped.
root@hlcs:/usr/pkgsrc/net/wireshark# date
Fri Dec 13 08:58:39 PM UTC 2024
root@hlcs:/usr/pkgsrc/net/wireshark# ls -l nohup.out
-rw------- 1 root root 25306809 Dec 13 08:01 nohup.out
root@hlcs:/usr/pkgsrc/net/wireshark#
nohup.out says:
=> Checking file-check results for qt6-qtbase-6.8.0nb4
ERROR: ************************************************************
ERROR: The following files are in the PLIST but not in /usr/pkgsrc/x11/qt6-qtbase/work/.destdir/us
r/pkg:
ERROR: /usr/pkgsrc/x11/qt6-qtbase/work/.destdir/usr/pkg/qt6/include/QtTest/6.8.0/QtTest/private/callgrind_p.h
ERROR: /usr/pkgsrc/x11/qt6-qtbase/work/.destdir/usr/pkg/qt6/include/QtTest/6.8.0/QtTest/private/valgrind_p.h
*** Error code 1
Stop.
bmake[3]: stopped making "reinstall" in /usr/pkgsrc/x11/qt6-qtbase
*** Error code 1
Stop.
bmake[2]: stopped making "reinstall" in /usr/pkgsrc/x11/qt6-qtbase
*** Error code 1
Stop.
bmake[1]: stopped making "reinstall" in /usr/pkgsrc/devel/qt6-qt5compat
*** Error code 1
Stop.
bmake: stopped making "all" in /usr/pkgsrc/net/wireshark
@Not_Oles said: I'm looking forward to your upcoming weekend adventures!
Thanks, I'll try to mainly work on it from around 16:00 UTC on Saturday to 23:00 UTC (but will hopefully be a lot shorter).
@cmeerw Excellent! I will stop messing around prior to 16:00 UTC on Saturday (tomorrow). Please feel free to work as long as you want and to change / delete / install whatever you want.
@jcn50 said: @Not_Oles Can I get TCP port 81 and UDP port 81 to run a private proxy?... Potentially I could share access to others (via PM).
Hi @jcn50! When you get a chance, could you please review the OP on Rules and How To Apply? Then apply again, please. Thanks!
Hmm.. the proxy is open source but it is not my code~ can I apply?.. I have re-read the Rules again and I do not see anything wrong, currently doing the How To Apply step #1~ am I missing something?.. Nvm if I am, and sorry~
I'm going to edit the OP so it's asking people to do both "steps" together, which is what I intended, but didn't express clearly. It seems like your interpretation involving separate steps is completely reasonable. Sorry for the confusion. Thanks!
@Not_Oles said: In pkgsrc using -j gave me an error. They seem to want pkgsrc to run single threaded. I'm not sure way.
Oh I just noticed it's under pkgsrc. Probably this can cause race conditions. Maybe you could tweak the makefile to add something like MAKE_JOBS= 8 but never done that.
@Not_Oles said: In pkgsrc using -j gave me an error. They seem to want pkgsrc to run single threaded. I'm not sure way.
Oh I just noticed it's under pkgsrc. Probably this can cause race conditions. Maybe you could tweak the makefile to add something like MAKE_JOBS= 8 but never done that.
It's not like I really mind how long the build takes. I can just go eat and sleep. I'm mentioning how long it takes to build Wireshark and its dependencies just because it amazes me how much code is in modern applications and their dependencies. I was compiling Chrome browser a while back. Chrome is another example of how full of wonderful features modern applications have become!
I think I am actually already done with my changes. Here is what I did:
Log into the serverforge portal - this has some rescue options, but I couldn't really figure out what those would do
From the serverforge portal then log into the Console (which gives you an HTML5 viewer of a Java application)
in there mount the netboot.xyz ISO as a virtual CDROM
reboot the server
took me a few attempts until I figured out how to actually boot from that virtual CDROM (seems to be F11 will then eventually show you the boot menu where you can then select the virtual CDROM)
from netboot boot into a live Debian Core system
in there do the filesystem resize, and then also shrink the logical volume
note that I resized the filesystem to 63 GB and the volume to 64 GB (as I wasn't entirely sure if saying 64 GB in both cases wouldn't accidentally overwrite the last few blocks of the filesystem)
unmount the netboot.xyz CDROM and reboot
back in the normal Debian system: first grow the root filesystem to the whole size of the logical volume (64 GB): resize2fs /dev/mapper/M247--X10E--9N--vg-root
create a new logical volume (64 GB): lvcreate -L 64G -n data M247-X10E-9N-vg
install btrfs progs: apt-get install btrfs-progs
create a btrfs filesystem: mkfs.btrfs /dev/mapper/M247--X10E--9N--vg-data
create a mount point for that filesystem: mkdir /mnt/data
copy/move /home to /mnt/data/home
edit /etc/fstab to mount the filesystem under /mnt/data and also add a bind mount for /mnt/data/home as /home
and then did some miscellaneous changes on the server:
added IPv6 configuration to /etc/network/interfaces
changed nameservers in /etc/resolv.conf to 1.1.1.1 and 9.9.9.9 (8.8.8.8 and 8.8.4.4 seem to be 29 ms away, whereas both 1.1.1.1 and 9.9.9.9 are < 1 ms away)
So at the moment we have a 64 GB root volume (ext4) and a 64 GB data volume (btrfs). I think the idea would be to move any large directories to the data volume and create a bind mount to the original location (similar to /home), and grow the data volume as needed (to grow /mnt/data to 128GB we would do lvextend -L 128G /dev/mapper/M247--X10E--9N--vg-data and then btrfs filesystem resize max /mnt/data). For now I am just cautious - growing filesystems is always much easier than shrinking filesystems, so just leaving space empty in case we want to use it for something else - of course, we could just use all the space for the btrfs filesystem...
Now, if you could please put everything back the way it was, then I could try reproducing all the steps which you have explained so well! /s I do expect to read through your post several times and also look up various pieces of what you did. . . .
I logged in to the server. I see that you might already be working on haiku. That's great!
It's fun for me to have you sharing the server! Thank you for joining!
In case someone might be interested, here are the outputs of mount, lsblk, and cat /etc/fstab:
root@hlcs:~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=16388812k,nr_inodes=4097203,mode=755,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,noexec,relatime,size=3281880k,mode=755,inode64)
/dev/mapper/M247--X10E--9N--vg-root on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=1524)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-sysctl.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-sysusers.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
ramfs on /run/credentials/systemd-tmpfiles-setup-dev.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
/dev/nvme0n1p1 on /boot type ext4 (rw,relatime)
/dev/mapper/M247--X10E--9N--vg-data on /mnt/data type btrfs (rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/)
/dev/mapper/M247--X10E--9N--vg-data on /home type btrfs (rw,relatime,ssd,space_cache=v2,subvolid=5,subvol=/)
ramfs on /run/credentials/systemd-tmpfiles-setup.service type ramfs (ro,nosuid,nodev,noexec,relatime,mode=700)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3281876k,nr_inodes=820469,mode=700,uid=1000,gid=1000,inode64)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=3281876k,nr_inodes=820469,mode=700,inode64)
root@hlcs:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 931.5G 0 disk
├─nvme0n1p1 259:1 0 976M 0 part /boot
├─nvme0n1p2 259:2 0 1K 0 part
└─nvme0n1p5 259:3 0 930.6G 0 part
├─M247--X10E--9N--vg-swap 254:0 0 3.8G 0 lvm [SWAP]
├─M247--X10E--9N--vg-root 254:1 0 64G 0 lvm /
└─M247--X10E--9N--vg-data 254:2 0 64G 0 lvm /home
/mnt/data
root@hlcs:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/M247--X10E--9N--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/nvme0n1p1 during installation
UUID=cea09f74-374a-4d7a-9161-b8eae6669bf9 /boot ext4 defaults 0 2
/dev/mapper/M247--X10E--9N--vg-data /mnt/data btrfs defaults 0 2
/dev/mapper/M247--X10E--9N--vg-swap none swap sw 0 0
# bind mounts
/mnt/data/home /home none defaults,bind 0 0
root@hlcs:~#
=> Checking file-check results for qt6-qtbase-6.8.0nb4
ERROR: ************************************************************
ERROR: The following files are in the PLIST but not in /usr/pkgsrc/x11/qt6-qtbase/work/.destdir/usr/pkg:
ERROR: /usr/pkgsrc/x11/qt6-qtbase/work/.destdir/usr/pkg/qt6/include/QtTest/6.8.0/QtTest/private/callgrind_p.h
ERROR: /usr/pkgsrc/x11/qt6-qtbase/work/.destdir/usr/pkg/qt6/include/QtTest/6.8.0/QtTest/private/valgrind_p.h
*** Error code 1
As a temporary and hacky fix just hopefully to get the Wireshark compile to finish, can I just comment out the two relevant lines (callgrind_p.h and valgrind_p.h) in PLIST.Linux?
Does anybody know a good, correct fix? Thanks!
More fundamentally, does anybody know why the two files are not in /usr/pkgsrc/x11/qt6-qtbase/work/.destdir/usr/pkg?
@itsdeadjim said:
Seems like a bug in the package for linux, you could report this.
Yes.
Why you use pkgsrc by the way?
I mostly don't use pkgsrc on Linux. But there are some programs in pkgsrc which are not commonly available in the various Linux distributions. A great example is the still maintained qmail, please see also https://schmonz.com/software/pkgsrc-qmail-run/.
I'm making Wireshark with pkgsrc here on our fine Hosteroid Debian bare metal server just because Wireshark in pkgsrc has so many dependencies that making it on my Linveo NetBSD-current VPS ran that very fun little guy out of space.
QtTest that fails is a qt module that is used for instrumenting/testing a qt application.
These 2 particular files that are missing are probably the interface with valgrind, which by its turn is used for application profiling (finding memory leaks, function call benchmark etc)
Since this functionality is not intended for production use, my guess is that it's optional and someone forgot to make it optional in PLIST.linux, or something like that.
@itsdeadjim said: @Not_Oles said: can I just comment out the two relevant lines (callgrind_p.h and valgrind_p.h) in PLIST.Linux?
Probably yes as these are used for profiling.
Commenting out by adding # at the beginning of the two offending lines in PLIST.Linux didn't work. I received the same error. However, removing the two lines got the build restarted. Why didn't commenting out work?
In case anyone might be interested, the NetBSD pkgsrc Wireshark build on Debian 12 ran another several hours and stopped with this error:
pkg_create: can't stat `/usr/pkgsrc/graphics/qt6-qtquick3d/work/.destdir/usr/pkg/qt6/lib/libQt6Quick3DXr.6.8.0.so'
=> Checking file-check results for qt6-qtquick3d-6.8.0nb3
ERROR: ************************************************************
ERROR: The following files are in the PLIST but not in /usr/pkgsrc/graphics/qt6-qtquick3d/work/.destdir/usr/pkg:
ERROR: /usr/pkgsrc/graphics/qt6-qtquick3d/work/.destdir/usr/pkg/qt6/lib/libQt6Quick3DXr.6.8.0.so
ERROR: ************************************************************
ERROR: The following files are in /usr/pkgsrc/graphics/qt6-qtquick3d/work/.destdir/usr/pkg but not in the PLIST:
ERROR: /usr/pkgsrc/graphics/qt6-qtquick3d/work/.destdir/usr/pkg/qt6/include/QtQuick3DXr/6.8.0/QtQuick3DXr/private/qopenxrgraphics_opengl_p.h
ERROR: /usr/pkgsrc/graphics/qt6-qtquick3d/work/.destdir/usr/pkg/qt6/lib/libQt6Quick3DXr.so.6.8.0
*** Error code 1
Stop.
bmake[3]: stopped making "reinstall" in /usr/pkgsrc/graphics/qt6-qtquick3d
*** Error code 1
Stop.
bmake[2]: stopped making "reinstall" in /usr/pkgsrc/graphics/qt6-qtquick3d
*** Error code 1
Stop.
bmake[1]: stopped making "reinstall" in /usr/pkgsrc/multimedia/qt6-qtmultimedia
*** Error code 1
Stop.
bmake: stopped making "all" in /usr/pkgsrc/net/wireshark
@Not_Oles said: Commenting out by adding # at the beginning of the two offending lines in PLIST.Linux didn't work. I received the same error. However, removing the two lines got the build restarted. Why didn't commenting out work?
iirc PLIST does not support comments
@Not_Oles said: pkg_create: can't stat `/usr/pkgsrc/graphics/qt6-qtquick3d/work/.destdir/usr/pkg/qt6/lib/libQt6Quick3DXr.6.8.0.so'
Comments
Thanks @itsdeadjim!
I finally got the plan9port install to succeed! Here's the tail of the INSTALL output:
I had to install several libraries. Here's a snip from .bash_history:
Duh! So I confess to a bad habit of trying things without re-reading the instructions that I've forgotten after years of, as best as I can remember, installing plan9port on various systems with just
./INSTALL.Duh! So maybe there might be some difference between the Debian image Hosteroid's installer uses and both the other providers' Debian images I have used as well as the official Debian images that I also have used. I'm not complaining about the Hosteroid image, which seems to work very well in all respects. Maybe somebody who build the Hosteroid image removed some less often useful on servers header files to save space?
I've never knowingly changed the plan9port build configuration as described on lines 50 and 51, above. Previously, as best I can remember, plan9port always just worked.
Maybe I can look around some more and figure out something more? At the least I do seem to have plan9port installed and working on hlcs -- the command line parts of plan9port, such as the ed editor, the p pager, awk, troff, and more are what's important to me. Someday maybe I will try the graphical parts, like acme, which might be the more important user applications plan9port brings from Plan 9.
Thanks @Hosteroid!
Thanks again @itsdeadjim! 
I hope everyone gets the servers they want!
Hosteroid Intel (Debian 12):
Hetzner Cloud arm VPS (Debian 12):
Linveo VPS Ryzen (NetBSD-current):
Since ./INSTALL worked on the latter two installs, maybe it's the
FONTSRV=fontsrvwhich caused the issue on Hosteroid. Maybe I can learn more about why that value is different on the Hosteroid Debian 12 versus the Hetzner Cloud Debian 12 and the NetBSD-current.Thanks Hosteroid!
I hope everyone gets the servers they want!
According to Hetrix Tools, it looks like we might have enjoyed a 2 minute IPv4 outage! The outage probably wasn't caused by our server because hlcs' uptime extends back beyond the outage and because there was no corresponding IPv6 outage reported.
From Hetrix Tools:
Back up:
Down:
Uptime:
Of course the short outage doesn't matter (aside from the Low End zillions we lost /s). Nevertheless, I'd love to know what happened. @Hosteroid, any ideas, please?
Thanks again to @Hosteroid for donating our lovely Community server!
We would love to accept more server Neighbors from the LES Community! If you are interested, please review How To Apply in the OP. Thanks!
I hope everyone gets the servers they want!
Maybe ask HetrixTools, last flap is since i rebooted server:
@zgato @yoursunny did you also have downtime?
@Hosteroid Thanks for your kind reply!
Thanks also for introducing me to the above helpful and detailed output! 
I asked Google Gemini what produced the output.
In case anybody is curious, I talk with Google Gemini on the command line via eliben/gemini-cli. The developer was kind enough to help me by adding to his project the $load facility so that gemini-cli could upload a file containing multi-line input instead of just single line chat. More info about and examples of the use of eliben/gemini-cli is available in this blog post, gemini-cli: Access Gemini models from the command-line.
The file uploaded to Gemini, post-4, looks like this:
Here is my conversation with Gemini:
Haha, if I am making a mistake here, or if the output isn't from JunOS, please let me know!
Thanks again @Hosteroid!
Thanks again @eliben! 
Thanks again Google Gemini! 
I hope everyone gets the servers they want!
@cmeerw
I'm looking forward to your upcoming weekend adventures!
Today, I'm compiling Wireshark out of NetBSD pkgsrc on our fine hlcs Debian 12 server. I'm doing it on hlcs partly to see if it works and partly because the build ran out of space on my wonderful Linveo NetBSD VPS.
If the Wireshark build doesn't break, maybe it will finish before the weekend!? As you know, pkgsrc builds are single threaded. . . . /s
Probably you noticed the file ipv6-up.sh in the /root directory? If you reboot, you probably have to run that script to re-establish IPv6. When I remember, I do restart IPv6 by hand that way because, on some servers, I have more than one IPv6 alternative, and I usually like to run only one at a time. So I sometimes have more than one ipv6-up.sh file. But, if you prefer, it's certainly okay to add the IPv6 info to /etc/network/interfaces or as a cron job or as a systemd service. The last two lines of the script are new. If they cause a problem, please comment them out.
I will stay off the server over the weekend, starting tomorrow, Friday, so that the server is free and clear for you to use. I hope you have fun!
Thanks!
Tom
I hope everyone gets the servers they want!
The compile of Wireshark is still running!
The compile started at about
Right now
So far, 8 hours and 10 minutes, approximately, and still going! I saw what looked like llvm and rust being built, along with a lot of other dependencies. Here's what was happening as I looked at
tail -f nohup.outin/usr/pkgsrc/net/wiresharka moment ago. It's getting late here, so time for sleep. Will the build finish by morning?Thanks @Hosteroid!
I hope everyone gets the servers they want!
Thanks, I'll try to mainly work on it from around 16:00 UTC on Saturday to 23:00 UTC (but will hopefully be a lot shorter).
@Not_Oles Can I get TCP port 81 and UDP port 81 to run a private proxy?... Potentially I could share access to others (via PM).
Hi @jcn50! When you get a chance, could you please review the OP on Rules and How To Apply? Then apply again, please. Thanks!
I hope everyone gets the servers they want!
Looks like the Wireshark compile ran about three hours more and then stopped.
nohup.out says:
I downloaded the nohup.out to my Chromebook.
Thanks Hosteroid!
I hope everyone gets the servers they want!
@cmeerw Excellent! I will stop messing around prior to 16:00 UTC on Saturday (tomorrow). Please feel free to work as long as you want and to change / delete / install whatever you want.
Good luck! Have fun!
I hope everyone gets the servers they want!
Hmm.. the proxy is open source but it is not my code~ can I apply?.. I have re-read the Rules again and I do not see anything wrong, currently doing the How To Apply step #1~ am I missing something?.. Nvm if I am, and sorry~
@jcn50 Sure! More information would be nice. For example, which proxy? How much bandwidth?
@jcn50 Want to do step 2 also, please?
I'm going to edit the OP so it's asking people to do both "steps" together, which is what I intended, but didn't express clearly. It seems like your interpretation involving separate steps is completely reasonable. Sorry for the confusion. Thanks!
I hope everyone gets the servers they want!
@Not_Oles
I think a first soft approval @ Step 1 is better~ than just 1+2.
a) This proxy:
https://github.com/shadowsocks/shadowsocks-libev
deployed through a Docker container~
b) Bandwidth: very low, for me it would be less than 2GB/m for sure (but I don't know if other LESbians would be interested~).
c) Will email you in the next few days~ (hopefully I won't forget).
Use -j parameter to parallelize make, i.e.
make -j 8
In pkgsrc using -j gave me an error. They seem to want pkgsrc to run single threaded. I'm not sure way.
Thanks for helping! Best wishes!
I hope everyone gets the servers they want!
Oh I just noticed it's under pkgsrc. Probably this can cause race conditions. Maybe you could tweak the makefile to add something like MAKE_JOBS= 8 but never done that.
It's not like I really mind how long the build takes. I can just go eat and sleep.
I'm mentioning how long it takes to build Wireshark and its dependencies just because it amazes me how much code is in modern applications and their dependencies. I was compiling Chrome browser a while back. Chrome is another example of how full of wonderful features modern applications have become!
@itsdeadjim Thanks again!
Thanks for the lovely server @Hosteroid! 
I hope everyone gets the servers they want!
I think I am actually already done with my changes. Here is what I did:
resize2fs /dev/mapper/M247--X10E--9N--vg-rootlvcreate -L 64G -n data M247-X10E-9N-vgapt-get install btrfs-progsmkfs.btrfs /dev/mapper/M247--X10E--9N--vg-datamkdir /mnt/data/hometo/mnt/data/home/etc/fstabto mount the filesystem under/mnt/dataand also add a bind mount for/mnt/data/homeas/homeand then did some miscellaneous changes on the server:
/etc/network/interfaces/etc/resolv.confto1.1.1.1and9.9.9.9(8.8.8.8and8.8.4.4seem to be 29 ms away, whereas both1.1.1.1and9.9.9.9are < 1 ms away)So at the moment we have a 64 GB root volume (ext4) and a 64 GB data volume (btrfs). I think the idea would be to move any large directories to the data volume and create a bind mount to the original location (similar to
/home), and grow the data volume as needed (to grow/mnt/datato 128GB we would dolvextend -L 128G /dev/mapper/M247--X10E--9N--vg-dataand thenbtrfs filesystem resize max /mnt/data). For now I am just cautious - growing filesystems is always much easier than shrinking filesystems, so just leaving space empty in case we want to use it for something else - of course, we could just use all the space for the btrfs filesystem...@cmeerw
Thanks for all the details of everything you did!
Now, if you could please put everything back the way it was, then I could try reproducing all the steps which you have explained so well! /s
I do expect to read through your post several times and also look up various pieces of what you did. . . .
I logged in to the server. I see that you might already be working on haiku. That's great!
It's fun for me to have you sharing the server! Thank you for joining!
Thanks to @Hosteroid for the wonderful server!
Anyone else?
Best!
Tom
I hope everyone gets the servers they want!
In case someone might be interested, here are the outputs of
mount,lsblk, andcat /etc/fstab:I hope everyone gets the servers they want!
Reposting from above the error that stopped the Wireshark compile with NetBSD pkgsrc running on Linux:
Now I see
As a temporary and hacky fix just hopefully to get the Wireshark compile to finish, can I just comment out the two relevant lines (callgrind_p.h and valgrind_p.h) in PLIST.Linux?
Does anybody know a good, correct fix? Thanks!
More fundamentally, does anybody know why the two files are not in
/usr/pkgsrc/x11/qt6-qtbase/work/.destdir/usr/pkg?Thanks @hosteroid!
I hope everyone gets the servers they want!
Probably yes as these are used for profiling.
Seems like a bug in the package for linux, you could report this. Why you use pkgsrc by the way?
What is "profiling" in this context?
Yes.
I mostly don't use pkgsrc on Linux. But there are some programs in pkgsrc which are not commonly available in the various Linux distributions. A great example is the still maintained qmail, please see also https://schmonz.com/software/pkgsrc-qmail-run/.
I'm making Wireshark with pkgsrc here on our fine Hosteroid
Debian bare metal server just because Wireshark in pkgsrc has so many dependencies that making it on my Linveo 
NetBSD-current VPS ran that very fun little guy out of space.
I hope everyone gets the servers they want!
QtTest that fails is a qt module that is used for instrumenting/testing a qt application.
These 2 particular files that are missing are probably the interface with valgrind, which by its turn is used for application profiling (finding memory leaks, function call benchmark etc)
Since this functionality is not intended for production use, my guess is that it's optional and someone forgot to make it optional in PLIST.linux, or something like that.
Commenting out by adding # at the beginning of the two offending lines in PLIST.Linux didn't work. I received the same error. However, removing the two lines got the build restarted. Why didn't commenting out work?
I hope everyone gets the servers they want!
In case anyone might be interested, the NetBSD pkgsrc Wireshark build on Debian 12 ran another several hours and stopped with this error:
So, wadaya think about the "so"?
I hope everyone gets the servers they want!
iirc PLIST does not support comments
Not familiar with pkgsrc but if I understand correctly qt6 is generally broken in pkgsrc/linux atm:
https://releng.netbsd.org/bulktracker/x11/qt6-qtbase
You can still try removing packages like before (you probably dont need quick3d) but I am not sure how far you can go from here.
@Not_Oles email sent//