Package Details: task-spooler 1.0.2-4

Git Clone URL: (read-only, click to copy)
Package Base: task-spooler
Description: Queue up tasks from the shell for batch execution
Upstream URL:
Licenses: GPL2
Submitter: jneidel
Maintainer: jneidel (alub)
Last Packager: jneidel
Votes: 37
Popularity: 0.106972
First Submitted: 2023-05-28 18:05 (UTC)
Last Updated: 2023-07-06 18:07 (UTC)

Dependencies (0)

Required by (0)

Sources (1)

Latest Comments

1 2 3 4 5 Next › Last »

jneidel commented on 2023-07-06 18:09 (UTC)

@m040601 & @kseistrup I've reverted to generic source, while keeping the arch as is. Thus communicating that it is an x86 package, but you may try to build it anyway:

kseistrup commented on 2023-06-06 05:14 (UTC)

@m040601 The archcitecture field is meant to indicate which architecture the final package can run on: A *-x86_64.pkg.tar.zst can run only on the x86_64 platform, not on an ARM processor, and so on. A good example of an “any” package is a package containing a python module in pure python.

Task spooler is a binary program that will run only on the platform for which is has been compiled, therefore “any” is the wrong choice. See PKGBUILD(5) for details.

The reason why it failed before was because the maintainer had put source_x86_64=(…) in PKGBUILD, where it should just have been source=(…). When _x86_64 has been removed from source_x86_64 and sha256sums_x86_64, people will be able to answer Y to the “Compile anyway?” question.

It is, of course, also possible to create an array of all possible architectures.

m040601 commented on 2023-06-05 23:00 (UTC)

Task spooler works in "any" architecture.

If you dont want to put "any", just change it to

arch=('x86_64' 'arm' 'armv7h' 'armv6h' 'aarch64' )


kseistrup commented on 2023-06-05 15:39 (UTC) (edited on 2023-06-05 15:42 (UTC) by kseistrup)

@m040601 task-spooler is not an “any” package, additional architectures have to be added explicitly.

However, the PKGBUILD has e.g. source_x86_64=…, something that should be just source=….

m040601 commented on 2023-06-05 15:33 (UTC) (edited on 2023-06-05 15:40 (UTC) by m040601)

Some adjustments are still needed after the recent merges in this PKGBUILD

I was trying to update "task-spooler" in my Archlinux systems. I'm using yay.

On my x86 system,

:: 1 package to upgrade/install.
1  aur/task-spooler  1.0.2-2 -> 1.0.2-4

All seems OK, havent noticed any problem.

But, on my Archlinux ARM system (armv7h), where I have been using task-spooler for years,

:: (1/1) Parsing SRCINFO: task-spooler
 -> The following packages are not compatible with your architecture:
:: Try to build them anyway? [Y/n]

I answered yes, as I have been doing for years, because "task-spooler" does work in multiple architectures. You can see in the Debian page that it is indeed available for x86, arm, mips, etc,


==> Starting prepare()...
/dev/shm/aurdesty/task-spooler/PKGBUILD: line 19: cd: ts-1.0.2: No such file or directory
==> ERROR: A failure occurred in prepare().
 -> error making: task-spooler-exit status 4
 -> Failed to install the following packages. Manual intervention is required:
task-spooler - exit status 4

Hmmmm .... that line "...task-spooler/PKGBUILD: line 19: cd: ts-1.0.2: No such file or directory" is really strange. What is that "ts" still doing there ?. Tried a clean build, same problem.

So anyway, this PKGBUILD needs a change in


to something like


jneidel commented on 2023-05-30 06:54 (UTC)

@alub I've added you as a maintainer to the task-spooler pkg.

alub commented on 2023-05-29 20:44 (UTC) (edited on 2023-05-29 20:44 (UTC) by alub)

Hi @m040601 and @jneidel, thanks for contributing, I agree with you both. I've updated this package's description and opened a request to merge ts into task-spooler.

kseistrup commented on 2023-05-29 09:34 (UTC)


What I meant by “merging” was actually merging the repos: When clicking the “Submit Request” link under “Package Actions” it is possible to choose “Merge”, whereby two packages will be merged into one, and holding comments and votes for both repos. Thus it goes much deeper than just editing a PKGBUILD and deciding that task-spooler is the canonical package name. (Tread carefully when requesting which package should merge with which package, or we may end up with ts being the canonical package.)

However, requesting a merge usually takes time — weeks, or even months — so until such a merge has taken place, I suggest that the ts package “announces” an upcoming merge (as a comment in its PKGBUILD + an emitted message from the pre_install() and pre_upgrade() functions + a pinned comment on the package page itself) so that as many users as possible can switch to task-spooler before the merge.

(Perhaps there are better ways of doing it, but the above is how I visualize it.)

Having “task spooler” in both packages' description, and having “task-spooler” as keyword will probably also help.

jneidel commented on 2023-05-29 08:31 (UTC)

Yeah @kseistrup, thats exactly what I was thinking.

Theres even no need to merge PKGBUILDs, let just go with ts's :)

jneidel commented on 2023-05-29 07:34 (UTC) (edited on 2023-05-29 07:35 (UTC) by jneidel)

Hi, I'm the new maintainer of the task-spooler package referenced by @m040601. I wasn't aware of this package since it didn't show up when I searched for "task spooler" some years back.

I'd be willing to go along with unifying these packages, let's continue that conversation here.

I do like the "task-spooler" package name better. ts is too short and non-specific. And even confusing since the name of the binary is tsp.

Shorthands are all good and nice but for packages a clear, longer name is better. If everyone knows what you're talking about a shorthand can save time, but in other contexts and if you search for it the longform might be better. Examples: typescript/ts, clang/c, golang/go, javascript/js, etc.