Search Criteria
Package Details: task-spooler 1.0.2-4
Package Actions
Git Clone URL: | https://aur.archlinux.org/task-spooler.git (read-only, click to copy) |
---|---|
Package Base: | task-spooler |
Description: | Queue up tasks from the shell for batch execution |
Upstream URL: | https://viric.name/soft/ts/ |
Licenses: | GPL2 |
Submitter: | jneidel |
Maintainer: | jneidel (alub) |
Last Packager: | jneidel |
Votes: | 35 |
Popularity: | 0.33 |
First Submitted: | 2023-05-28 18:05 (UTC) |
Last Updated: | 2023-07-06 18:07 (UTC) |
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:
https://aur.archlinux.org/cgit/aur.git/commit/?h=task-spooler&id=6973b2981fa1cf49ad061d309599a6aba026c04e
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=(…)
inPKGBUILD
, where it should just have beensource=(…)
. When_x86_64
has been removed fromsource_x86_64
andsha256sums_x86_64
, people will be able to answerY
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
(ex, https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=yay)
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 justsource=…
.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,
All seems OK, havent noticed any problem.
But, on my Archlinux ARM system (armv7h), where I have been using task-spooler for years,
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,
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)
@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 thattask-spooler
is the canonical package name. (Tread carefully when requesting which package should merge with which package, or we may end up withts
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 itsPKGBUILD
+ an emitted message from thepre_install()
andpre_upgrade()
functions + a pinned comment on the package page itself) so that as many users as possible can switch totask-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.
1 2 3 4 5 Next › Last »