I've started working on a2server basically out of necessity and I'm
trying to reduce diffs with a2cloud for basically identical code, so I'm
changing things like a2cSource to top_src, that way I can reuse blocks
of code more easily without stupid "off by one letter" mistakes.
Plan to be able to use /usr/local/lib/raspple2 for other things, so
moved the nulib2-version file to a pkginfo subdir.
This gave me an excuse to create something I've wanted for awhile: A
place to stick legacy code that fixes our mistakes that probably doesn't
need to exist forever. I can count the number of people who downloaded
1f8afb6 on a few fingers of one hand most likely, but the change still
got published and I can silently fix my mistake without having to stick
mostly useless code in install_archive_tools someone's gonna look at
three years from now and ask, "does that still need to be there?" No,
no it doesn't. And fixup describes succinctly how long that code needs
to remain there. And the fix is encapsulated into a nice little blob
that's easily removed when the time comes.
Fixes an unfiled bug using the old snapshot where nulib2 fails to
compile on buster/sid systems. Additionally, we now include the version
of nulib2 we've installed in /usr/local/lib/raspple2 so that we can
upgrade this stuff when the time comes to do so.
As noted, Ivan has agreed to allow these scripts to be relicensed under
CC0. We have one file under LGPL (a unit file we lifted wholesake from
systemd) and the ADTPro wrapper which I'm pretty sure Ivan wrote, but if
he didn't we need to fix its license to be the same as ADTPro.
Either way, to the best of my knowledge, this resolves the question of
how things are licensed explicitly. (Closes#21)
Installing archive tools now happens before ivan.sh. This actually
means that installing archive tools happens before you're asked if you
want to continue. That'll be the next thing I work on I think.
The Unarchiver for UNIX is available on Debian, Ubuntu, Fedora, and on
macOS under the package name "unar". It's in Arch Linux as well called
"unarchiver". What this means is we really have no need whatsoever to
download the source code and compile it, so we won't.
Also made install_archive_tools ignore args it doesn't understand.
I chose to make the arg parsing in install.sh a function because it
simplifies handling positional arguments in the interim without messing
with arrays. Just serves to get our foot in the door for arg processing
for now.
We don't do unar picopkgs anymore. We probably shouldn't even compile
it actually. The reason why we do is because I don't want to give up on
the idea that a2cloud may run on macOS at some point—but I'm as likely
to just depend on Homebrew for that on the Mac.
Why Homebrew? Well, I don't like its installation still (same reason I
don't like ours. Running a command off a website is unwise. And of
course people do stuff like that all the time, but Homebrew encourages
it and shouldn't! So again, why Homebrew?
With fink, you build everything from source, but you inherit the Debian
library dependency hell nonetheless. MacPorts solves the dependency hell
and is very robust, but it's also pretty (subjectively) unfriendly to
new users who don't grok UNIX or even know where to find the M to RTFM.
So we come to brew. It's pretty lightweight, it feels modern. It's
distributed so that you need not be part of the in-crowd to work with
it, and its Cellar approach provides makes maintenance easy. When I
first looked at it, it'd been around for years but it had never really
caught on. Lots of things were not there or just really outdated and
unloved. I'm glad to say that's changed and the project feels more
mature now.
We can probably do better with the aliases, but I really think what we
want is a wrapper script that enables readline, ansi, and 280 character
tweets. An update to oysttyer could remove the need for settings
changes for 280.
Added all the user-visible changes to a2cloud to the changelog for the
currently released vision. It's a pretty large set of changes thus far,
which I thin helps explain why this needs to be a major version upgade
when it's all finished.
I went with a Debian changelog format because I figured a2cloud would
probably wind up in Debian someday. But a Debian changelog is probably
not appropriate for what we want in this file, and I'd prefer something
easier to parse by script anyway. So I'm transitioning to a markdown
based format described in https://keepachangelog.com/.
Fixed the wrong date on 1.6.7. November, what?
And what do you think install_java does? If you just say it's going to
install the latest version of perl, I'm going to hit you.
On Raspbian systems it defaults to oracle-java8-jdk because that's what
Raspbian defaults too _for now_. Apparently openjdk 9 can keep up with
it and possibly run circles around it, in which case maybe we want to
use default-jre everywhere. I'm for not using Oracle Java regardless
because … Oracle, but if it's not just as fast, those of you running
armv6-based Pis are going to not be happy if we drop it.
We now install oysttyer 2.9.1 instead of old 2.7.2. While I was at it,
I made the installation prefer the Debian package for oysttyer if you
have it available (in buster and sid), while falling back on local
installations if you don't.
Changed how we remove local installations for Term::ReadKey. The way we
do it now is less complete, but also less likely to break stuff that we
didn't install maybe. It doesn't heart anything to leave it behind, but
it requires a manual touch to clean it up.
Finally fixed some missing sudos. Really the whole installation should
be run with root privs if it's going to run with root privs, but I'm not
ready to begin thinking about that since we don't necessarily know who
the normal user is otherwise, and we still modify the normal user's
account. (That should change, but we're not in a position to change it
yet.)
…why? Because show_changes will become the "do you want to install
this?" confirmation at some point. That's not what it does now, it just
shows you the version for now. But eventually it will tell you the
version you have installed, compare to the version you are going to
install, show you the changes between here and there, and ask you if you
actually want to proceed with installation. When that happens it'll be
appropriate to rename the script, but for now it's a placeholder.
What ivan.sh does now is a lot of fairly complicated shtuff that is
going to get harder to extract from here on out.
set versions/directories
find a2cSource
ID system
set Pi/computer (me/fullme)
detect systemd or not (the way RPF does it)
report installed/available version
parse argv
prompt for installation
skip a whole lot of questions
try to change your password
update package lists
install udev trigger
install random scripts like cppo and aliases
install motd
disable virtualbox screen blanking
write the version
install avahi
install at (why?)
install xdg-utils (less useful than it used to be at present)
install ADTPro:
check for java or free space to install it
install X11/LXDE
set boot to command line via systemd/grub (why here?)
install java
remove adtpro if it's old
install adtpro if needed
install applecommander
install modified adtpro.sh
if adtpro was updated, install new a2cloud disk images
install rxtx
install xvfb
make netatalk share a2cloud disk images if that's installed
make samba share a2cloud disk images if that's installed
install shell scripts for controlling adtpro, vsd
install acmd, mkpo, dos2pro
WHEW!
install xrdp
install the serial port handler script
create udev rules for usb-serial
install serial port login on the Pi (doesn't currently check for rpi)
install serial scripts: baud, term, usbgetty
install systemd service or modify inittab for serial console
call install_comm_tools
call install_emulators
call install_archive_tools
Create .desktop files for ADTPro and LXterminal
Decide whether we need to make/update a2cloud disks
If we do:
See if we need to update it
If we do and have most of what we need:
Extract files and add them where they go
If we're not going to make disks from scratch:
Extract files elsewhere and add them where they go
Otherwise:
Kill adtpro if running
Download a2cloud disk images if we can
If we cannot:
Get an 800k .po named A2CLOUD
delete files we'll replace
Download GSOS 6.0.1 disk 3 for its BASIC.SYSTEM
Grab STARTUP.BAS and add that
Grab VEDRIVE and add that
Grab Apple System Utilities and add that
Grab ProTERM and add that
Patch ProTERM for IIc printer port
Add ProTERM macros
Download Z-Link and add that
Download ShrinkIt and add that
Download DSK2FILE and add that
Add Apple System Utilities (check above)
Download Filer and add
Add ADTPro client
Add VSDRIVE
Create 140k image and add the basics
make vsd files symlinks if they're not already
create a2cloud.hdv compatibility symlink
If we need to make a new blank image:
make it
set up the a2cloud-setup command
decide what to do about rebooting, restarting, starting, whatever.
Okay, the first thing to do here seems to probably be moving the
installation of Java out. If we can just call "make sure java is
installed" from ivan.sh, we can from install_archive_tools too and pull
acmd and the other Ivan-written archiver scripts into that file.
I think at some point we need a "go download this" tool. We often don't
waste a lot of effort on this for random programs, but we have for stuff
that comes from eg Apple or archive.org or … let's just not duplicate
that code anymore.
Making a2cloud disks is a high priority for its own file. It's also a
bit of a jumbled mess right now, installing things in somewhat jumbled
order. Let's be clear where we get our ProDOS, where we get our
BASIC.SYSTEM, and then handle things in stages.
How we install ProTERM etc should be compared with how it's done in
a2server at some point. It's not hte same to install it to a directory
as it is to a disk image (or is it?) Reducing effort could pay off
later in that regard.
We'll see how this pans out and where it leaves us with ivan.sh.
There's also a lot of bugs left to fix compiling things like nulib on
buster and we'd like to be able to start pulling AppleCommander and
mabye ADTPro as well out of GitHub revisions we trust… That sort of
thing.
I don't like how this is done, but I don't like any part of how the
emulators are handled right now. At least the mess is in the right spot
now, save for the thing that conditionally execs a login shell to make
sure gsport groups take effect at the end. That whole restart thing is
also a mess I haven't thought about yet.
The install for both LinApple and GSPort is still kind of a mess. In
LinApple's case that's mostly upstream (tinu.) and GSPort is a
combination of multiple clusterf—it's gonna take some doing. :)
At some point in the very near future GSPlus will replace GSPort and
that'll clean up some of it.
We don't actually download any picopkg files in install_comm_tools
anymore—oysttyer was the only one and we just always pull that from git
and the Readline module from CPAN now. (In buster we'll only need the
CPAN module if Debian doesn't package it.)
Really the only picopkgs which are optional to download are gsport,
linapple, and nulib. And since none of those exist at the moment, you
don't even really have much of an "option" about them either. Yeah, I
know, I'm working on it.
We need to conditionally pass -c to other scripts if we don't want
picopkg downloads. That's totally fine, but that's easier to do in bash
if something is set vs. unset. If set you can use :+, so that's
desirable.
Like with archive tools before it, comm tools have been split out of
ivan.sh now to someplace we can hopefully work on them. Unlike the
archive tools, however, this was not a simple copy out the code block
and patch the script to run independently of the big script. Here's
what was done:
ADDED
- lftp, a powerful ftp client, command-line based but much more
friendly than standard ftp because it operates in binary mode by
default, has bookmarks, can handle ftp:// URLs, has useful batching
and mirroring commands, and can directly read things like readme
files on the server in the client. Also tab completion.
- mc, Midnight Commander, a full-screen file manager reminiscent of
Norton Commander. This isn't a comm tool per se, but it's well loved
by a lot of people and it can connect to ftp clients and access them
the same way you would any other directory in mc.
CHANGED
- For oysttyer, we no longer use a locally-installed perl readline
module. Debian packages this, so we'll use this. That means we no
longer need/want the locally installed version, so we try to clean up
after ourselves.
- Rewrote the oysttyer installation process to be hopefully more
robust overall.
REMOVED
- cftp. This program is barely alpha-quality proof of concept. It's
buggy, it's unreliable, it's undocumented, and it is of no use when
it crashes (and it will) and leaves your terminal in a broken state
you don't know how to fix. There's nothing "comfortable" about that,
even for new users. If you need your ftp client to work with arrow
keys, I recommend connecting to your ftp server with lynx. Like most
web browsers predating OS-integration, it includes a decent-enough
(non-persistent-connection) ftp client which generates a very basic
directory listing webpage for you. It works; cftp doesn't.
Did you know if you're at the top of a directory listing and press up,
it segfaults immediately, leaving your terminal in a modified state
without a visible cursor, forcing you to know how to fix that kind of
broken terminal state with stty, tput, and/or reset? Yes!
It is at version 0.12 and it was last touched in 2002. It has no
manpage, no help screen, and the wrong keypress causes it to randomly
die badly. This is not a "user friendly" program. If you want ftp with
arrow keys, use lynx!
We're no longer installing this pile of alpha-quality abandonware.
Don't like it? Make something good or adopt this program and fix its
bugs, then talk to me. I just can't justify this thing.
ipv6 should be enabled on Raspbian nowadays, so we should no longer need
to modify the stock exim configuration. If it gives you an error on
startup, let me know and we'll put it back.
It turns out nc does a pretty decent ftp client and might be a good
alternative to cftp which … really never went anywhere and is awfully
easy to crash.
Another temporary script. This performs the tasks from ivan.sh related
to installCommTools. It differs from that block (which has not yet been
formally replaced) primarily by having a rewritten and hopefully more
logical installation for oysttyer.
Oysttyer probably should be broken into its own script—all of these
things should be really—but this one in particular because it's so
involved even compared to other installations because we have stuff we
need to clean up first.
The FIXME about unsafe file handling is resolved. However since nulib2
doesn't build on sid, we need to get that fixed before sid becomes
buster, so a new FIXME is needed.
For quite some time now, and since before this codebase came to github,
if you didn't say yes to all, things broke. So we've assumed yes to all
is required since about 2015 or so. Let's make that official as we work
here.
Now install_archive_tools creates its own temp directories for
installation. Nulib2 doesn't build for me on sid/buster though, we're
going to need a patch I think. We may as well patch it at that point
for building libnufx as a shared lib while we're at it. I really don't
want another project right now. :( This is why we don't get releases
out.
The archiver installation was a pretty simple, isolated chunk of code,
and thus easily pulled into its own script with minimal external
dependencies.
I made few changes, so the new script isn't very tidy unless it's run
from ivan.sh. It should create temp directories for anything it
downloads and clean up after itself when it's finished, but for now it
assumes ivan.sh is doing that. Mostly that's to keep the intellectual
diff small from the code in ivan.sh to the script.
I'll clean this up in an upcoming commit. Feel free to offer PRs that
do this kind of thing to other easily isolated (or not so easily
isolated) chunks. Once ivan.sh is split apart into nice logical pieces,
it will be a lot easier to test and fix individual pieces independent of
the whole. That's something we can't even say for a2server yet.
I'd removed debianMajor and the like in the last commit, but I missed
one instance of it being used: To install the unar package on jessie and
greater systems. Well, jessie is now oldstable and wheezy is so
obsolete you're not even recommended to upgrade from it. Nowadays, we
should just be installing the package.
We ought to check for it in /usr/local and see if we can determine if
its an old version and remove it, probably. If someone else would like
to tackle that, feel free.
Cherry-picked the system_ident script from the refactor branch. This
sets ras2_os and ras2_arch in a way that would be more useful for
selecting a filename from among arch-specific alternatives. It's less
good for identifying a Pi vs. desktop Debian or anything else, so I've
kept around the isRpi variable for now.
May revisit the variables in system_ident later on if it really would be
useful to have ras2_os not include the release codename. For now
though, this is fine. If nothing else this will encourage me to do more
to get rid of the specific checks for the Pi. The major places the
check seems to be used at the moment are:
1. Text output
2. Determining which version of java to install
3. Whether to spew out the USB lower/upper udev rules
4. How to compile GSport
The question of which java to install is easily answered: The one you
have available. Currently we're calling for java8 on RPi and ORACLE
java7 on Debian. That doesn't actually make sense. On Debian we'd
probably want to use openjdk, and the only reason to use Oracle's JDK on
Raspbian is because you might already have it installed. I'm inclined
to suggest that we should check if you have RPF's Oracle java installed,
and if you don't install openjdk—unless someone can give me a good
reason to use the JDK from those evil bastards at Oracle who believe
that implementing a standard library compatible with theirs from
published specs is somehow a Copyright infringement… Needless to say I
have a bias against evil/stupid companies.
GSport should literally use $ras2_arch if that once we have it replaced
with GSplus. That just leaves the udev rules and flavor text. I think
the problem will solve itself in time.
Added a new script that sets two variables when sourced, $ras2_os and
$ras2_arch. These are different than the existing variables we've been
using in a2cloud/a2server and they don't (in and of themselves) presume
Debian. That said, nothing's likely to work with these scripts except
on Debian, so … yeah. But the script is designed not to tie you to that
ultimately.
Outputs the variable assignments to stdout unless you pass -q.
