GothenburgBitFactory
Most repositories stuck on Taskwarrior v2
Perhaps a valid point, but I'm not sure looking at the sea of red on repology is a good way to gauge progress. It seems like most packages are mostly red like that. And judging by the number still on 2.5.x I wonder if they're too stable to upgrade?
Good point. Also, there was a long pause after 2.6.2 so perhaps some of the folks who were maintaining those packages for those distros have moved on to other things, and never spotted the subsequent releases.
@hunterjackson if there's a specific repo/distro you would like to see upgrade, please follow that distro's process to get the update started!
I would like to have people associated with Taskwarrior who know the maintainers for each of the major distros, and can act as liasons -- helping us solve problems they encounter while packaging, and helping them know when to package a new release. Would you be interested in starting such a group?
It's at 2.6.2 in Debian bookworm.
It would be prudent to add explicit release notes warning people that there are breaking changes in 3.x, specifically regarding the sync server, before they confirm via apt installation.
It would be prudent to add explicit release notes warning people that there are breaking changes in 3.x, specifically regarding the sync server, before they confirm via apt installation.
Do you mean in the Debian release notes? If so, that's a suggestion for the Debian packagers, not the TW devs! If not -- that already exists.
I don't know what it's called but when someone updates their packages via apt-get (e.g. apt-get update; apt-get upgrade) some packages require you to read their blurb before you upgrade. They often do this when there are breaking changes, legal changes, or other considerations the user should know about before upgrading.
Sorry, I don't know who does what. I'm just pointing out that a lot of people routinely upgrade their packages without looking at the release notes because they can usually assume there are no major breaking changes without a warning. Of course with millions of developers there are exceptions (pun intended).
Debian stable is still on 2.62 as expected, but I do want to point out that testing and unstable are also still on on 2.62 as well. The freeze for Debian 13 goes into effect on 3/15.
If getting v3 in Debian 13 is a possibility, it would streamline the upgrade process given the # downstream distros.
Randomly read the repo's announcements/history last night so I'm a bit more aware of things now versus when I made that post. (Thanks for all the work and structure you've provided to the project btw djmitche). I've only used tw for about 24 hours, and also do not have the skillset to be a maintainer unfortunately, but if the suggestions below seem worthwhile, I can draft a documentation PR to help out.
I had a Debian focus, but zooming out, many of the non-bleeding edge distros will be providing 2.62 for the foreseeable future. Like many other GH projects, one option is to nudge users towards building from source as a preferred install method if their official distro repo carries a later version. Some potential additions:
- List install instructions for distros that have access to the latest release
- Create a subsection for currently outdated distros that includes the Repology link. Then provide additional context below:
- 2.62 is ideal if: Don't have to build from source, you have an existing sync workflow that is no longer covered, etc (This section can be avoided completely if it's not something that wants to be explicitly pushed)
- Why taskwarrior recommends using the latest version: Touch on the highlights and/or point to the releases tab for a more in-depth listing
- Show the rest of the existing install instructions for distros still on 2.62 for those that want to make that choice
As a tw newbie, I don't have the context to know whether these are feasible/worthwhile ideas, so I'll defer to whatever you think is best.
Disregard the last post for now. Just emailed taskwarrior's Debian maintainers listed here and will report back when I hear more.
No response over the last week. My uneducated guess is that it might be too late, but I'll follow up if/when I hear back.
No response over the last week.
Last upload was 1st of April 2022 (>3 years ago), I wonder if Debian package can be now tagged as orphaned...
Also, there is #1086300, but the maintainer appears to be active.
@chronitis, could you please take a look?
(I'm not sure that edits to a message cause notifications, so re-@'ing): @chronitis
I never heard back btw.
The Debian Freeze is in effect now, so I don't know if maintainers are allowed to tackle major version changes until the summer when Debian stable is released btw.
Only the toolchain is in freeze now, the rest of the packages are due in 10 days. Still a window of opportunity.
Hi @savchenko, @djmitche
Yes, sorry, taskwarrior in debian has not had a lot of work recently. There is in principle a team which maintains taskwarrior and adjacent packages: https://salsa.debian.org/groups/tasktools-team/ but it's been pretty low activity for a while. I'm afraid I put off working on 3.0 both due to the need to figure out the debian rust tooling but also because of how best to deal with incompatibilities. As you say, it is possible to add release notes which are shown when upgrading (but only when using a frontend which displays NEWS items - which apt would normally do, but gui wrappers will not necessarily do). There are requests to keep both 2.6 and 3.0 co-installable, which is unlikely since there isn't really enough maintenance effort for one version.
Anyway, tl;dr I think getting the new major version in the next 10 days is unlikely, but I will have another look.
I'm happy to hear that! Rushing for a deadline does not make sense, but moving forward does. Hopefully the task import-v2 functionality in 3.3.0 makes users' upgrades a little easier.
Hello :) I created an AppImage containing Taskwarrior in a Junest (Arch Linux) environment. Find it here: https://github.com/00sapo/taskwarrior-appimage/releases/tag/continuous
It's not optimized, so we could make it lighter by removing useless stuffs, but I'm not sure what is needed and what not.
You can open it with --appimage-extract and see the base system with ls squashfs-root/.junest. Just tell me what you see that can be removed and I will update the building script.
Currently, the builds are created every 12 hours in order to follow Arch Linux updates. The Github workflow is still not optimal, because even if there are no updates, a new release is created. I will try to optimize this.
Of course, having it in standard debian/ubuntu package would be the best.
Cool!
I don't know much about AppImages, but I followed your instructions and I see basically a full Linux system in there. I suspect almost all of that is not required -- certainly nothing under /usr/bin, and in fact probably most or all of /usr. It might make the most sense to essentially delete everything, then selectively re-add stuff to fix failures. I imagine some shared libraries will be required (ldd $exectuable can probably tell you which). If using the ENABLE_TLS_NATIVE_ROOTS, you'll probably also need the certificates under /etc, but that is not enabled by default.
Do the task* manpages do any good in the AppImage?
Is it possible to start an AppImage from a blank slate? Similar to a Docker image starting with FROM scratch?
I neither know that much about AppImages. I used a nice script which encapsulate a full container inside the AppImage. It uses junest, which is itself based on proot or bwrap, depending on the user's system setup. On most Desktop installation, bwrap will work (it's the same system used by flatpaks), but proot does not need any root access to set it up at the cost of performance.
What's going on here is that the AppImage starts a minimal Arch installation, on top of which there is taskwarrior installed. The minimal Arch installation is setup by Junest.
We can remove any library and useless file by modifying this function.
Regarding man pages, they are not used, actually, but the ArchImage script (which generated the build script) deliberately keeps them, so I followed the same convention. We can diverge, though. There's an old issue about making them available to the user: https://github.com/AppImage/AppImageKit/issues/542
As a side note, it's now available with AM/appman: https://portable-linux-apps.github.io/apps/task.html
So, once AM is installed (root not needed and cross-distro), one can install it with:
appman install task
or
am install task
This looks like a great start! That script seems to have a number of things commented out or deleted, and also to do a lot of stuff that is clearly unnecessary for Taskwarrior, such as installing nvidia drivers. I'm fairly confident that, rather than starting with this long script that includes ArchLinux, you could just create an AppDir containing task (and maybe libc and libc++ and a very small list of other things) and that would be sufficient.
Once this is suitably trimmed down, we can incorporate it into this repo (taskwarrior), testing the build process on every PR and generating a downloadable AppImage for each release. That should be more efficient than doing so on a 12-hour timer.
That would be more efficient for sure
But wouldn't it be even more efficient having a static release? What you are asking is basically that, just inside an AppImage.
To me, AppImages make sense as a compromise between ease of development, portability, and size. Trying to decrease the size of an AppImage too much is difficult, and I'm not sure that we can decrease its size so much: the Arch task binary is ~60MB, while that AppImage is ~45MB. Maybe we can gain other ~15MB...
P.S. all Nvidia references are options that are supposed not to be activated in my build
Good point about a static binary. Hopefully am install task is an easier option than downloading a binary and making it executable.
It's true that there are diminishing returns on trying to reduce the size. I'm a little more concerned with maintenance overhead and security exposure -- if something went wrong, I don't think I could easily find out what was wrong in https://github.com/00sapo/taskwarrior-appimage/blob/fc3ae5e8ab9dcba243a2c8d91732c862abe5b928/task-junest.sh.
So I think the key request here is to simplify, and make a PR that would build an AppImage on every push, and we can work on publishing those on release.
Good point about a static binary. Hopefully
am install taskis an easier option than downloading a binary and making it executable.
AM, as well as soar, can handle both AppImages and static binaries. Honestly I think that a cli tool like taskwarrior should be distributed as a static binary. My AppImage is only a workaround.
I will try to simplify it, though
@chronitis
Anyway, tl;dr I think getting the new major version in the next 10 days is unlikely, but I will have another look.
I understand that this date has passed by now, however, the package could still be added to trixie-backports to make it available for Debian stable. It would be great if this could be done but I also understand if you're busy with other things.
