You are browsing as a guest. Sign up (or log in) to start making projects!

p14277376

@p14277376

Joined June 1st, 2026

  • 6Devlogs
  • 4Projects
  • 0Ships
  • 0Votes
I'm a person. Let's move on.
Open comments for this post

1h 3m 49s logged

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 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.

Replying to @p14277376

0
Open comments for this post

1h 12m 14s logged

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 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.

Replying to @p14277376

1
Open comments for this post

2h 10m 16s logged

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 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.

Replying to @p14277376

0
Open comments for this post

1h 17m 42s logged

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.

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.

Replying to @p14277376

0
Open comments for this post

3h 24m 54s logged

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.

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.

Replying to @p14277376

0
Open comments for this post

1h 45m 44s logged

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.

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.

Replying to @p14277376

1

Followers

Loading…