No ack or ack-grep in artful.

[Vinson Lee]

There is no ack or ack-grep package in artful.

[Hans Joachim Desserud (hjd)]

Thanks for taking your time to report this issue and help making Ubuntu better.

Indeed, it looks like the ack package is currently missing from Artful. There is a proposed package though, but it doesn't seem to have made its way to the release archives. I took a look at the publishing history (click "View full publishing history" from the overview page or see https://launchpad.net/ubuntu/+source/ack/+publishinghistory) and looks like ack was recently removed from artful with the following comment:
"New version is broken according to autopkgtests, old version needs rebuilt for perl transition; remove to make room for perl"

Possibly these tests keep it from migrating from proposed.

(Btw, the ack-grep source package was replaced by ack recently, https://launchpad.net/ubuntu/+source/ack-grep/+publishinghistory)

[Andy Lester (petdance)]

Hi, I'm Andy Lester, the author/maintainer of ack.

I was just alerted to this ticket by a user. I'd like to help solve this problem, but I'm not familiar with the Ubuntu packaging process. Is there anything I can do to help solve this problem? I can be contacted directly at <email address hidden> and would be glad to do whatever I can to help.

[Matthias Niess (mniess)]

The package was taken directly from Debian, so maybe the Debian maintainer can help. The tests only seem to fail with Perl 5.26 (5.24 giving no errors).

https://packages.debian.org/sid/ack
https://autopkgtest.ubuntu.com/packages/ack

[gregor herrmann (gregoa)]

On Fri, 20 Oct 2017 16:01:53 -0000, Matthias Niess wrote:

> The package was taken directly from Debian, so maybe the Debian
> maintainer can help. The tests only seem to fail with Perl 5.26 (5.24
> giving no errors).
>
> https://packages.debian.org/sid/ack
> https://autopkgtest.ubuntu.com/packages/ack

Interesting.
ack passes the same autopkgtest without problems on Debian unstable:
https://ci.debian.net/packages/a/ack/

On https://autopkgtest.ubuntu.com/packages/ack/artful/amd64 I note
that the last test is from 2017-09-21 ...

Cheers,
gregor

[William Ricker (bill-n1vux)]

re gregora #4,
> I note that the last test is from 2017-09-21 ...

Perhaps someone who is authorized to do so can force a re-test?

I tried to reproduce the massive systemic test failures shown in autopkgtest 2017-09-21 log with latest ack2 (2.19_01 via github) and a fresh Perl 5.26.0, and no dice, it worked fine.

I'll try again with a CPAN ack 2.18 or the Debian src tar, but I'd expect same results since CPANTS only reports sporadic failures for ack 2.18 on Windows; Perl 5.26 on GNU/Linux looks fine there.

Bill
ack team // formerly Ubuntu Massachusetts Field team // Boston Perl Mongers // The Perl Shop

[Alex Muntada (alex.muntada)]

William Ricker:

> Perhaps someone who is authorized to do so can force a re-test?

Someone did and today's results were still a fail.

> I'll try again with a CPAN ack 2.18 or the Debian src tar, but I'd
> expect same results since CPANTS only reports sporadic failures for ack
> 2.18 on Windows; Perl 5.26 on GNU/Linux looks fine there.

Please, note that autopkgtest setup is different from the usual
test environment for Perl modules, i.e. you only have the binary
packages installed and the tests, no other build context is
available. Thus, successfully running "make test" after building
the module doesn't mean that autopkgtest will pass those tests
too.

You can find the setup details for Debian in
http://pkg-perl.alioth.debian.org/autopkgtest.html#SETUP

You may need to adapt them a bit to run autopkgtest locally for
Ubuntu, but I think it should work fine to reproduce the fail.
The --shell-fail option for autopkgtest should help with the
debugging of this issue.

Cheers,
Alex

[William Ricker (bill-n1vux)]

On Tue, Oct 24, 2017 at 5:27 PM, Alex Muntada <email address hidden> wrote:
> > Perhaps someone who is authorized to do so can force a re-test?
> Someone did and today's results were still a fail.

Thank you.

> Please, note that autopkgtest setup is different from the usual
> test environment for Perl modules, i.e. you only have the binary
> packages installed and the tests, no other build context is
> available. Thus, successfully running "make test" after building
> the module doesn't mean that autopkgtest will pass those tests
> too.

Does that mean that the test data (in directories under ./t but not
containing *.t files) are not present?

There is likely a URL that would let me inspect the contents of the
package under test, but I didn't spot it in the logs.

> You can find the setup details for Debian in
> http://pkg-perl.alioth.debian.org/autopkgtest.html#SETUP

Wow, that's elegant once it's working but not something I'm going to
do in an idle 20 minutes before dinner.

> You may need to adapt them a bit to run autopkgtest locally for
> Ubuntu, but I think it should work fine to reproduce the fail.
> The --shell-fail option for autopkgtest should help with the
> debugging of this issue.

Since seemingly _all_ tests that actually do any file inspection are
failing, I'm suspecting that our test data is somehow unavailable to
the test?

I note the packagers have patched the Makefile.PL to run the
standalone tests against the library edition, since standalone edition
is not distributed -- unclear to me if that was a Debian decision or
Ubuntu? Perhaps the patch needs re-tweaking to work in latest
autopkgtest environment ?

But that more perplexing, I note that in comment #4, Gregor (gregoa)
said the same package passes the same test upstream on Sid.
https://ci.debian.net/packages/a/ack/unstable/amd64/
If the package passes on Sid, is the problem isolated into Ubuntu
re-packaging of either ack or autopkgtest ?

--
Bill Ricker
<email address hidden> https://www.linkedin.com/in/n1vux
aka <email address hidden>

[sam tygier (samtygier)]

As a quick work around the 18.04 package installs fine on 17.10

https://launchpad.net/ubuntu/+archive/primary/+files/ack_2.18-2_all.deb

[hackel (hackel)]

I went to install the package @samtygier linked above, and it shows "License: Proprietary" for some reason. Seems to be working fine.

[Axel Beckert (xtaran)]

Hi,

William Ricker wrote:
> I note the packagers have patched the Makefile.PL to run the
> standalone tests against the library edition, since standalone edition
> is not distributed -- unclear to me if that was a Debian decision or
> Ubuntu?

Not shipping the standalone edition is a Debian decision and it's like
this for a long time, at least since I took over its maintainership
inside the Debian Perl Team in 2013. According to debian/changelog
it's like that since the second upload of (back then) ack-grep in
2007.

It just does not make sense to ship a packaged version of the
standalone version:

* That's just the library version with all required libraries
  appeneded: You don't need the same functionality twice.

* Maintaining such a standalone version is as painful as maintaining a
  package with a statically linked C program: You need to rebuild the
  package for every security update in any of its recursive reverse
  dependencies. You definitely _don't_ want that.

And accordingly I don't think that not building the standalone has any
relation to this issue.

> Perhaps the patch needs re-tweaking to work in latest
> If the package passes on Sid, is the problem isolated into Ubuntu
> re-packaging of either ack or autopkgtest ?

There is no diff from Debian to Ubuntu in ack according to the version
numbers on https://launchpad.net/ubuntu/+source/ack (*) -- so I also
think that the issue is in the way Ubuntu does autopkgtests, either in
their autopkgtest package or in their setup.

(*) Although there is not listed which version would have been in
    artful, so I can say that for sure. But according to
    https://launchpad.net/ubuntu/artful/+source/ack/+changelog it
    would have been 2.18-2 which is the same version as currently in
    Debian Testing and Unstable.

  Regards, Axel
--
 ,''`. | Axel Beckert <email address hidden>, https://people.debian.org/~abe/
: :' : | Debian Developer, Debian Perl Team member, Debian ack maintainer
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
  `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE

[Hans Joachim Desserud (hjd)]

>Although there is not listed which version would have been in
    artful, so I can say that for sure.

Please see the "View full publishing history" linked to from the overview page, https://launchpad.net/ubuntu/+source/ack/+publishinghistory, it lists all versions which has been in Ubuntu at some point. Don't see any recent versions with Ubuntu delta though.

[Axel Beckert (xtaran)]

Upstream said, he fixed the reason for this issue in his upstream release candidate 2.19_01 which I'll soon upload to Debian as 2.19.01-1.

I'll close this bug report with that upload, so please reopen it, if this doesn't fix the issue. (Can't really test that beforehand as this issue seems ubuntu-specific.)

[Axel Beckert (xtaran)]

Hrm, no, the only upstream commit since 2.18 which mentions Ubuntu is https://github.com/beyondgrep/ack2/commit/66009a140a9d05302546bcd4c1d85fd5d66388f2 and that only fixes a lintian warning about misspellings (which we had overridden already in the Debian package). So I don't see any relation to this issue despite that commit seems to have been caused by my first comment in https://github.com/beyondgrep/ack2/issues/652 — I've now tried to clarify the situation there with citing one of the failing tests explicitly and linking to an full example log of one test.

[Axel Beckert (xtaran)]

Using "pbuilder" I've set up a minimal chroot for Ubuntu 18.04 Bionic as of today. Inside that chroot, I installed autopkgtest, pkg-perl-autopkgtest and ack (version 2.18+dfsg-1, 2.19.01-1 doesn't seem to be on my mirror yet) from bionic-proposed and ran "autopkgtest ./ -- null" inside the unpacked source package.

"Unfortunately" all tests passed successfully. So I can't really reproduce the issue that causes the autopkgtest failures which keep ack out of Ubuntu for quite some months now.

And since ack passes all tests on Debian's autopkgtest infrastructure, I more and more come to the conclusion that this issue isn't with ack but with the way Ubuntu's autopkgtest infrastructure runs the tests.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Axel Beckert (xtaran)]

The following comment by the main ack upstream developer in the
according upstream ticket may give a hint where to look for the
failure reason:

----- Forwarded message from Andy Lester (https://github.com/beyondgrep/ack2/issues/652#issuecomment-350527181) -----
Here's something interesting: Many of the tests I see at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/a/ack/20171024_160017_5333d@/log.gz are showing `-` as filenames found in tests where actual filenames are expected, like so:

```
                # Failed test 'File on command line is always searched'
                # at t/Util.pm line 412.
                # +----+-------+---------------------------------+
                # | Elt|Got |Expected |
                # +----+-------+---------------------------------+
                # | 0|[ |[ |
                # * 1| '-' | 't/swamp/#emacs-workfile.pl#' *
                # | 2|] |] |
                # +----+-------+---------------------------------+
                # actual[
                # '-'
                # ]
                # expected[
                # 't/swamp/#emacs-workfile.pl#'
                # ]
                # Looks like you failed 1 test of 1.
```

It's a pretty consistent pattern happening throughout. Maybe there's something in how the tests get run that confuse STDIN with the filesystem?
----- End forwarded message -----

So does the autopkgtest infrastructure in Ubuntu run on a rather
exotic file system which might result in tools regarding files as
STDIN?

[Andy Lester (petdance)]

Data point: People are asking about it being missing.

https://askubuntu.com/questions/972083/unable-to-find-ack-in-ubuntu-17-10-repositories

[sam tygier (samtygier)]

17.10 is no longer supported. Ack is packaged in 18.04 and 18.10. I think this can be closed.

[Hans Joachim Desserud (hjd)]

Indeed, ack 2.22-1 is available in Ubuntu 18.04, so looks like the issue was resolved :)