Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#63099 - [bash-bats] Switch package to maintained upstream

Attached to Project: Community Packages
Opened by Danila Kiver (licryco) - Thursday, 04 July 2019, 16:45 GMT
Last edited by Morten Linderud (Foxboron) - Wednesday, 03 March 2021, 16:50 GMT
Task Type General Gripe
Category Packages
Status Closed
Assigned To Felix Yan (felixonmars)
Morten Linderud (Foxboron)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

The bash-bats package (https://www.archlinux.org/packages/community/any/bash-bats) uses an unmaintained upstream (https://github.com/sstephenson/bats), abandoned by its owner in early 2016 (announced and discussed in https://github.com/sstephenson/bats/issues/150). Last bats version, released from this upstream, is 0.4.0, which is essentially broken because of few serious bugs (e.g. https://github.com/sstephenson/bats/issues/89 - this one breaks any test relying on the default value of IFS variable). There will be no more releases in this upstream (extremely likely).

As discussed in git issue #150 (see the link above), the project is continued in community-maintained fork (https://github.com/bats-core/bats-core), which includes many crucial fixes and already reached stable version 1.1.0.

This ticket is a request to switch the bash-bats package from abandoned upstream to the new one.
This task depends upon

Closed by  Morten Linderud (Foxboron)
Wednesday, 03 March 2021, 16:50 GMT
Reason for closing:  Fixed
Additional comments about closing:  1.2.1-2
Comment by Jorge Luis Martinez Gomez (jol) - Friday, 19 July 2019, 16:45 GMT
Here's an updated PKGBUILD (not official; I'm not a maintainer) for the meantime. I renamed the package as was done with the repo to bats-core. I also set pkgrel to 0, despite documentation saying it should be at least 1, hoping that will cause an automated update when the official PKGBUILD is updated.

To anyone that doesn't know how to use these. Put both files in a new directory and run:

$ makepkg

That will create a package you can then install with:

$ sudo pacman -U bash-bats-core-1.1.0-0-any.pkg.tar.xz
   PKGBUILD (1 KiB)
   lib.patch (0.4 KiB)
Comment by Thomas Weißschuh (t-8ch) - Tuesday, 02 March 2021, 13:37 GMT
FYI Debian is also using the new upstream beginning with their "Bullseye" release:
https://packages.debian.org/bullseye/bats
Comment by Morten Linderud (Foxboron) - Tuesday, 02 March 2021, 13:47 GMT
If people are interested contributing I have a patch to try package the new upstream. The main issue is that there are some failing tests which I have not figured out.

https://github.com/Foxboron/archlinux-pkgbuilds/blob/master/bash-bats/PKGBUILD
Comment by Thomas Weißschuh (t-8ch) - Tuesday, 02 March 2021, 13:56 GMT
@Foxboron check() works for me. package() doesn't.
Comment by Morten Linderud (Foxboron) - Tuesday, 02 March 2021, 13:59 GMT
You ran with devtools or makepkg?
Comment by Thomas Weißschuh (t-8ch) - Tuesday, 02 March 2021, 13:59 GMT
makepkg
Comment by Morten Linderud (Foxboron) - Tuesday, 02 March 2021, 14:01 GMT
Distro packages are not build with makepkg since there is no isolation from the host system. Please use devtools and `extra-x86_64-build`. I assume there is some non-trivial change with the container causing the problem.
Comment by Thomas Weißschuh (t-8ch) - Tuesday, 02 March 2021, 14:04 GMT
Same result using extra-x86_64-build (and plain makechrootpkg)
Comment by Thomas Weißschuh (t-8ch) - Tuesday, 02 March 2021, 14:08 GMT
When calling extra-x86_64-build without environment variables (env -i extra-x86_64-build) I get failures in tests 8,9,10,11,12,40 and 44.
It seems devtools does not properly set up the environment for the container.
Comment by Morten Linderud (Foxboron) - Tuesday, 02 March 2021, 14:09 GMT
What. I get 5-6 failing tests across all the systems I build with.

not ok 8 summary passing tests
# (in test file test/bats.bats, line 54)
# `[ "${lines[1]}" = "1 test, 0 failures" ]' failed
not ok 9 summary passing and skipping tests
# (in test file test/bats.bats, line 60)
# `[ "${lines[3]}" = "3 tests, 0 failures, 2 skipped" ]' failed
ok 10 tap passing and skipping tests
not ok 11 summary passing and failing tests
# (in test file test/bats.bats, line 75)
# `[ "${lines[4]}" = "2 tests, 1 failure" ]' failed
not ok 12 summary passing, failing and skipping tests
# (in test file test/bats.bats, line 81)
# `[ "${lines[5]}" = "3 tests, 1 failure, 1 skipped" ]' failed
Comment by Morten Linderud (Foxboron) - Tuesday, 02 March 2021, 14:10 GMT
I run with all my env variables. So what variables do you have which could affect the build through makechrootpkg?
Comment by Thomas Weißschuh (t-8ch) - Tuesday, 02 March 2021, 14:21 GMT
So makechrootpkg *does* set up the environment.
But it passes through $TERM and when $TERM is not set, it sets it to "unknown".
In my environment $TERM is "xterm-256color".

I can replicate the issues by meddling with $TERM.
Comment by Thomas Weißschuh (t-8ch) - Tuesday, 02 March 2021, 14:24 GMT
Related:
https://lists.opensuse.org/opensuse-factory/2017-02/msg00502.html
https://github.com/bats-core/bats-core/issues/201
Comment by Morten Linderud (Foxboron) - Tuesday, 02 March 2021, 14:25 GMT
It fails because my terminfo is not available in the container I reckon. Thanks for figuring it out!
Comment by Thomas Weißschuh (t-8ch) - Tuesday, 02 March 2021, 14:27 GMT
You're welcome :-)
Comment by Thomas Weißschuh (t-8ch) - Tuesday, 02 March 2021, 14:36 GMT
Their own CI just sets TERM=linux. So we should probably do the same.
Comment by Morten Linderud (Foxboron) - Wednesday, 03 March 2021, 16:50 GMT
Package has been updated and pushed. Thanks for the help!

Loading...