Pre-devlog notes

I did the math recently. I only have enough actual time left in this challenge to get one project done and have time to get it reviewed and rated, and that’s only if I’m lucky.

So I decided that the “My first slack bot”, “Untitled”, and “Arch on your Android” projects are canceled and my other projects will be paused for a few months or more so that I can dedicate the rest of my coding time to easyAPT, which is almost done. Just 3 hours, a demo system, and a Github release left, and the project I’m most proud of will be ready for anyone to use.

Also, I won’t be making a .deb file, and won’t be trying to get it on the Debian or Ubuntu repositories. That would be cool, but that process can take a lot of time. Maybe later, though, but definitely not now.

There’s an even simpler way to install it without even cloning the repo once Github releases are published: just download one of the files there (like the .7z, the standard .zip, etc), make the easyAPT directory in the folder you want to, and other steps that I’ll mention in the Github page because they might change.

I still will have to do research on how I can create a light Debian environment with the easyAPT demo - a limited version of easyAPT that I’m planning to create later. But that’s for later…

Also: an announcement: easyAPT is done!
cue ‘tada’ fanfare
This is the one of the last devlogs I will be posting for it, for this first version anyway. And I can finally make a Github release!

Also this devlog might not be too detailed because there’s still a lot of things I have to do to ship my project.

Devlog 8

Besides a full bug testing of every option, here are the new features:
1. A progress bar on the startup prompt
Just a nice inclusion. It zooms by within 5 seconds.

2. New updater tool
It’s still experimental, but I scraped the old code and started over. It’s a lot more stable, but still has a small chance to delete the wrong thing.

3. Github features finished
In fact, all the main menu options are finished.

Sorry about the limited detail, I have a lot to do. Thanks for reading anyway, and if you have a question, comment, or suggestion, type it down below.

Pre-devlog notes

Sometimes when I’m coding I think it’s only been 5 minutes and then I check the time and I realize It’s been 3 hours…

Also after chasing my own tail for hours trying to troubleshoot and code Arch on your Android, I decided it was a good idea to go back to my first project, which has a bunch of new features now and has no dialog flag mistakes.

easyAPT devlog 6, maybe 7

A ton of new features have been added to easyAPT.

1. .easyaptgithub.sh

This adds an option in the menu to check if Github is working properly on your system. Plus, some options will run it anyway to check if everything is working.

2. Issue/bug reporting

You can now use easyAPT to report issues with it, right there in the menu.

3. About easyAPT

There is a new About easyAPT option in the menu. Just some basic stuff about the version. Plus, it has missing info that I can’t fill in until I do more research, make a Github release, and ship my project.

There’s a ton more, but I don’t have time to discuss it all in a devlog.

Thanks for reading! If you have any questions, comments, or suggestions, please leave them down below!

This is a quick and off the style devlog, but hopefully it’s still informative. This is Devlog 3 for Arch on your Android.

Basically, there is a giant dialog flag bug in my code. It has something to do with missing arguments for a flag.

The way dialog works, if you don’t know, is that there are flags that you can add at the end of the dialog command that customizes it. For example, this dialog --title "Test Title" --msgbox --stdout "Test Contents of a file" 0 0 would display a standard message prompt. But because of some syntax error, I keep getting

Expected no less than 20 tokens for -i, have 4. 
Use dialog --help for all options.

or something similar.
I have to do extended testing and may have to start some 60-line segments of the code over. That will take a while, so the rest of the setup (which is now 4 parts instead of 3) will have to wait.

By the way, this is just a random screenshot of it in action right now.

Pre-devlog notes

By the way: sorry iOS users, but the Termux app doesn’t work on iOS. I don’t have enough time to make “Linux on your iPhone” or something, so this is strictly Android-only.

Actual Devlog 1

I make things easier for myself by counting GitHub releases as versions. This is like version 0.

What changed?

I decided to redo the whole script with the dialog packag e instead. I could make a lot cleaner case statements, haven’t hit a syntax error yet, and, as a bonus, it has the same easy menu used in easyAPT.

What’s next for Arch on your Android?

Here are my next plans:

• All shell scripts for all setup parts being completed
• Bug tested
• Actually tested in a environment on my own Android

Thank you for reading! If you have any questions, comments, or recommendations, please let me know!

Pre-devlog notes

If it wasn’t obvious, I like working with Android and Linux. So expect more of this from me.

Actual Devlog 1

I make things easier for myself by counting GitHub releases as versions. This is like version 0.

What changed?

I was able to get the first script done, but not bug checked. There are three parts of Arch on your Android setup: Part 1 (within Termux), Part 2 (within the proot environment as root, shortest of the whole setup for obvious reasons), and Part 3 (within the proot environment as the specified user.) There are a few syntax errors in the first script, so that’ll be checked for later.
The reason why this part is so short is because saying everything that I added in the about 500-line long would take too long.

What’s next for Arch on your Android?

Here are my next plans:

• All shell scripts for all setup parts being completed
• Bug tested
• Actually tested in a environment on my own Android

Thank you for reading! If you have any questions, comments, or recommendations, please let me know!

Pre-devlog notes

Yes, this is how I do my devlogs now. I want to take advantage of all Stardance’s new devlog features to make them a bit neater.

Also, this may be my first time I made a commit to easyAPT’s Github repository in, like, 2 weeks. I just decided to take a break from coding for a little bit.

Actual Devlog 6

We went from I forgot the other version and the GitHub commit history has missing info for some reason to JUN30-V32.

What changed?

I have changed a good amount of things with easyAPT, including…

• The version system instead of organizing them by what versions were released on what day, I organize them by the date that they were released and the overall version (eg, JUN9-R7 to JUN9-V20). V, in my case, means revision number.)
• The updating tool 90% bug fixed
• Case $? in errors I made this mistake a lot. In case statements, which I use a ton of, you have to use case “$VARIABLE” in or case “TEXT” in, not case $? in, or it’ll always assume the last option. Take this sample code as an example,

#correct
case "$?" in
            0)
                    echo "Success"
            *) 
                    echo "Failure"
esac
#This code displays the right end result for a command. But my mistake was
case $? in 
           0)
                   echo "Success"
            *)
                   echo "Failure"
esac
#Which always assumes it fails, every time, even if $?=0.

Thanks to Vim (the super useful editor that’s my new favorite), what would’ve taken hours took a split second.

How close am I to my first GitHub release of easyAPT?

Pretty close now. All the options menu work fine. When I paste the final contents into easyAPTmenu.sh, then this project will be pretty much finished and ready for anyone to demo. But, there’s still a bunch of bugs I need to fix.

What’s next for easyAPT?

There’s a lot of planning for what’s up next.

• Case statement bug fixes I turned on a Vim feature that highlights some lines red if there are syntax errors. For some reason I haven’t figured out yet, most, if not all, of the ;;s and the esacs in my script are highlighted red. I haven’t experience bash stop the script due to syntax errors, so I’m going to have to look through the code and maybe do research.
• About menu option Takes a few seconds to code. Just a nice little inclusion telling the user who made it, the current version, and possible licensing info (if we get to that stage)
• More bug fixes I’ll test every single possible option before pasting the menu part into another script.
• Making ./easyAPTmenu.sh hidden I’d like to turn easyAPTmenu.sh into .easyAPTmenu.sh. It may seem like a small change, but adding a dot to the beginning hides the file by default, like if you typed “ls”. This is the case for the version files as well as others used for Github and Wakatime.
• Anything else Things will get added and removed from here as releases go.

Thank you for reading! If you have any questions, comments, or recommendations, please let me know!

Devlog 1
(easyAPT development is paused)

projOS is a Scratch project that tries to use every feature of Scratch, but right now it’s not even close to ready (probably another year or so, especially since I’m not really using Scratch this summer). So when I saw the webOS mission, I thought it was absolutely perfect for my case. That is what I’m currently working on.

What I got done was a welcome screen (not winXP’s) that wasn’t very personalized. The image shows the current version. I plan to make a much better version in the future.

Devlog 5

All the menu options have been ready, but the updating tool is really, really buggy. I will fix that later. The next step in easyAPT’s process is to do debugging.

I moved from JUN4-R7 to JUN8-R4.

I plan to test all the options in the menu, including all submenus, and all checks (by failing them). That means that there will be several more sub versions before the first actual Github release.

Devlog 4

There was some syntax error on line 622 I didn’t know about when I was working on this, but besides that I got a lot done with easyAPT and the development phase is almost done.

I moved from JUN4-R3 to JUN5-R7.

The 2 main changes:
One: All menu options except tool updating have been finished but not bug tested - that’s later!

Two: The version string no longer includes the year. That was redundant.

Devlog 3

Small changes have been made from JUN3-R6 to JUN4-R3. I was able to get the remove options done and bugs fixed in the “List installed packages” option (not all of them are fixed though).

I am planning to lock the .rpm to .Deb conversion utilities to experimental versions of this. Their version string is “JUN4-2026-R5-EXP” instead of “JUN4-2026-R5”, for example. This is because the alien utility I am using for it ends by dropping the user in a shell prompt (sh to be exact), which hangs the exit script, and if you run it within the sh shell and try the conversion again, it ends up being a APT, sh, and easyAPT instance and confliction mess that slows down your system and, in the worse case, is hard to regain control of.

I made a sample ./easyAPTmenu.sh that redirects to the ./easyAPT.sh. This is because I was tired of typing :!./ and the up key in the Vim editor EVERY SINGLE TIME I selected an option in the menu and the operation finished. I didn’t do this before because that’s 2 seconds of checks it makes that I have to wait for instead of instantly with the planned ACTUAL easyAPTmenu.sh file, which is coming soon.

This should take a few more days to finish up, and then I can finally make my README.md and my first Github release of easyAPT!

PS: nothing has changed with the menu, I just needed a graphic for the devlog and wanted to see how the menu would change over devlogs.

Things have happened with easyAPT. I went from version JUN2-2026-R6 (June 2, 2026 Revision 6) to JUN3-2026-R5 (June 3, 2026, Revision 5). Here’s what’s new in JUN3 (R5), known bugs, and what’s planned next.

One: An updating tool has been added to the menu powered fully by Github. It hasn’t been implemented yet, but it should test if .version in the repo matches the .version on placed on the device, and if it doesn’t (after user confirmation), it will move the .update.sh to the home directory and run it, which will remove all contents of the easyAPT directory, reclone the whole directory back onto the device, run “chmod +x *” (or chmod +x .) so all the scripts are executable, and remove itself from the home directory.

Two: The first 4 options may have bugs (I haven’t tested them fully yet), but I think they are ready for use. I know for sure that the last option works fine (obviously), but I want to add a line of code to it first.

Three: I can reuse the code from previous options into new ones, so some will get done way faster.

Four: All options when done, instead of going back to the menu, quit with a “No such file or directory” error. This is because it links to a nonexistent “easyAPTmenu.sh” file that I can’t make until the first script (easyAPT2.sh) is fully finished and bug checked.

I haven’t made an actual Github release yet or a README.md (these scripts simply aren’t ready yet), but I plan to soon.

I’m working on a Linux shell script for a terminal-based interface for managing packages. This is especially useful for people who are first timers to Linux and don’t know what “sudo apt update” is.

I’ve got the menu done, but not any of its actions. I am planning to add the version number as part of the startup text.