Arch Linux User Repository

@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:

https://aur.archlinux.org/cgit/aur.git/commit/?h=task-spooler&id=6973b2981fa1cf49ad061d309599a6aba026c04e

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

Task spooler works in "any" architecture.

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

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

(ex, https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=yay)

@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=….

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:
  task-spooler
:: 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, https://packages.debian.org/bullseye/task-spooler

Then,

==> 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().
    Aborting...
 -> 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

arch=('x86_64')

to something like

arch=('any')

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

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.

@jneidel,

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.

Yeah @kseistrup, thats exactly what I was thinking.

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

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.