remove the hard coded libreoffice autopkg test trigger for gcc-*

[Matthias Klose]

please remove the hard coded libreoffice autopkg test trigger for gcc-*. It's there for hysterical reasons, and gcc-* now has a test checking it's runtime packages, so it's not necessary.

The test is already removed in Debian's installation, the test itself is unreliable and regularily fails for other reasons.

[Steve Langasek (vorlon)]

The comment on this in the britney source code is:

        # gcc-N triggers tons of tests via libgcc1, but this is mostly in vain:
        # gcc already tests itself during build, and it is being used from
        # -proposed, so holding it back on a dozen unrelated test failures
        # serves no purpose. Just check some key packages which actually use
        # gcc during the test, and libreoffice as an example for a libgcc user.

If we shouldn't use libreoffice (and I question whether libreoffice is a good package to use for testing libgcc1 functionality), do you have a different package that you think we should use here?

[Martin Pitt (pitti)]

The "libreoffice" bit might have been influenced by Bjoern Michaelsen back then -- at least at that time, LibO was exercising basically every tool chain in the world :)

Any other user of libgcc is fine of course.

[Matthias Klose (doko)]

just added autopkg tests for hello, for a pure C package, and proposing libzstd as a C/C++ package.

[Steve Langasek (vorlon)]

Discussed that gzip is a package in main, with autopkgtests as far back as trusty, that are quick to run and consistently pass on all archs.

Will replace libreoffice with gzip.

[Steve Langasek (vorlon)]

Deployed in dd815d1.

[Iain Lane (laney)]

On Wed, Dec 05, 2018 at 01:56:48PM -0000, Steve Langasek wrote:
> Discussed that gzip is a package in main, with autopkgtests as far back
> as trusty, that are quick to run and consistently pass on all archs.
>
> Will replace libreoffice with gzip.

I believe libreoffice was chosen because it was (a) an 'important'
package that has autopkgtests, and (b) depends on libgcc1.

gzip meets (a) but not (b) - i.e. it wouldn't (AFAICS) normally be
triggered for gcc-X uploads. I'd like it if, if we're going to continue
with this special-casing for gcc, we could find something which
exercises its library when tested.

Cheers,

--
Iain Lane [ <email address hidden> ]
Debian Developer [ <email address hidden> ]
Ubuntu Developer [ <email address hidden> ]

[Steve Langasek (vorlon)]

On Wed, Dec 05, 2018 at 02:39:11PM -0000, Iain Lane wrote:
> On Wed, Dec 05, 2018 at 01:56:48PM -0000, Steve Langasek wrote:
> > Discussed that gzip is a package in main, with autopkgtests as far back
> > as trusty, that are quick to run and consistently pass on all archs.

> > Will replace libreoffice with gzip.

> I believe libreoffice was chosen because it was (a) an 'important'
> package that has autopkgtests, and (b) depends on libgcc1.

> gzip meets (a) but not (b) - i.e. it wouldn't (AFAICS) normally be
> triggered for gcc-X uploads. I'd like it if, if we're going to continue
> with this special-casing for gcc, we could find something which
> exercises its library when tested.

Indeed, sorry, I failed to look at the dependencies to confirm that it had a
libgcc dependency.

Here's a more exact list of candidates with autopkgtests in trusty and
dependencies on libgcc1, found via:

for pkg in $(grep-dctrl -sBinary -n -FTestsuite -r . \
             /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_trusty_main_source_Sources \
             | sed -e's/, /\n/g' | sort -u)
do
    grep-dctrl -FDepends libgcc1 -a -FPackage -X $F -sSource:Package \
        /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_trusty_*_binary-amd64_Packages
done

libreoffice
apt
ceph
doxygen
clamav
glib2.0
graphviz
lapack
leveldb
libproxy
subversion
php5
python-qt4
pyqt5
squid3

I'll take a look which of these are most likely to be suitable in terms of
testsuite runtime / reliability / etc.

[Steve Langasek (vorlon)]

libreoffice: preferred not, for reasons understood.
apt: mixed history of reliability. moderate runtime (half hour to an hour). Most recent tests failed on arm64/trusty, armhf/trusty, armhf/cosmic.
ceph: reliable, quick (<20m).
doxygen: reliable, very quick (<5m). Very unlikely to become unsupported in the future.
clamav: reliable, very quick.
glib2.0: fairly reliable, but currently failing for trusty SRUs. Quick. Unlikely to become unsupported in the near future, although the package name could change with a future ABI change.
graphviz: very quick and reliable, but never passed in trusty and there are better options.
lapack: reliable; moderate runtime. package not built on all archs in trusty.
leveldb: very quick and reliable. but only included in main as a dependency/implementation detail of ceph, so may not be a future-proof choice.
libproxy: reliable, very quick.
subversion: reliable, very quick, but an obsolete technology.
php5: not useful across releases, supported source package name changes over time. No test results on arm64, armhf, s390x.
python-qt4: obsolete library, candidate for removal soon.
pyqt5: not obsolete, but tied to a library ABI version so also not a good candidate.
squid3: useless, test fails everywhere. (also, source package with version in name).

I think doxygen looks like the best choice for a libgcc smoketest, so I'll change to that for now. If anyone thinks there's a reason this is a bad choice, we can always change again.