export-orig shows trace when no tarball available

[Bryce Harrington]

When reviewing a merge proposal, this can crop up:

php-transition-php7x4-c-focal+20.04:~/ubuntu/Php7.4/cacti/cacti-gu$ git ubuntu export-orig
03/23/2020 22:22:50 - WARNING:No pristine-tar data found for 1.2.10+ds1
03/23/2020 22:22:55 - INFO:New upstream version detected (1.2.10+ds1) which is after the last published upstream version (1.2.1+ds1).
Traceback (most recent call last):
  File "/snap/git-ubuntu/466/bin/git-ubuntu", line 11, in <module>
    load_entry_point('gitubuntu==0.9.4', 'console_scripts', 'git-ubuntu')()
  File "/snap/git-ubuntu/466/lib/python3.6/site-packages/gitubuntu/__main__.py", line 254, in main
    sys.exit(args.func(args))
  File "/snap/git-ubuntu/466/lib/python3.6/site-packages/gitubuntu/exportorig.py", line 122, in cli_main
    if len(tarballs) > 0:
TypeError: object of type 'NoneType' has no len()

Fix is probably something like:

    tarballs = main(repo, args.commit, orig_search_list)

    if tarballs and len(tarballs) > 0:
        return 0
    else:
        return 1

The problem is that since it's a merge, the necessary tarball is (obviously) not yet in the Ubuntu archive. In this case it's necessary to use the --for-merge argument:

git ubuntu export-orig --for-merge
07/27/2020 09:48:33 - WARNING:No pristine-tar data found for 8.32
07/27/2020 09:48:40 - INFO:Downloading coreutils_8.32.orig.tar.xz from launchpad.net (5.291 MiB)
07/27/2020 09:48:43 - INFO:Downloading coreutils_8.32.orig.tar.xz.asc from launchpad.net (0.001 MiB)
07/27/2020 09:48:45 - INFO:Downloading coreutils_8.32-3.debian.tar.xz from launchpad.net (0.030 MiB)
07/27/2020 09:48:45 - INFO:Successfully fetched:
/home/bryce/pkg/Coreutils/review-mp388088/coreutils-gu/.git/git-ubuntu-cache/coreutils_8.32.orig.tar.xz
using fetch_orig_from_launchpad(source=debian)

[Bryce Harrington (bryce)]

Alternatively, build.fetch_orig() could be modified to always return an empty list on error.

[Bryce Harrington (bryce)]

The underlying problem could be addressed more directly in derive_orig_search_list_from_args(), where it is identifying the search list to use:

    source = 'debian' if for_merge else 'ubuntu'
    orig_search_list = [
        OrigSearchListEntry(
            mechanism=fetch_orig_from_parent_dir,
            source=None,
     must_build=True,
        ),
 OrigSearchListEntry(
            mechanism=fetch_orig_from_cache,
            source=source,
            must_build=False,
        ),
    ]

One thought might be to simply include both 'ubuntu' and 'debian' in this list, so that it falls back to debian if ubuntu doesn't work.

Alternatively, perhaps git-ubuntu could use the changelog version number to heuristically identify merges (i.e. if the version is *ubuntu1).

[Bryce Harrington (bryce)]

The trace also triggers for fetchmail presently:

fetchmail-gu$ git ubuntu export-orig --for-merge
02/10/2021 21:50:28 - WARNING:No pristine-tar data found for 6.4.5
02/10/2021 21:50:31 - INFO:New upstream version detected (6.4.5) which is after the last published upstream version (6.4.15).
Traceback (most recent call last):
  File "/snap/git-ubuntu/474/bin/git-ubuntu", line 11, in <module>
    load_entry_point('gitubuntu==1.0', 'console_scripts', 'git-ubuntu')()
  File "/snap/git-ubuntu/474/lib/python3.6/site-packages/gitubuntu/__main__.py", line 279, in main
    sys.exit(args.func(args))
  File "/snap/git-ubuntu/474/lib/python3.6/site-packages/gitubuntu/exportorig.py", line 122, in cli_main
    if len(tarballs) > 0:
TypeError: object of type 'NoneType' has no len()

In this case, though, it looks like the underlying problem is an incorrect version number comparison, as it appears to think 6.4.5 is after 6.4.15. The invalid logic is:

        if spi.upstream_version < changelog.upstream_version:
            logging.info(
                "New upstream version detected (%s) which is after the last "
                "published upstream version (%s).",
                changelog.upstream_version,
                spi.upstream_version,
            )
            return None

Instead of <, this should probably use a call to version_compare(a, b) from versioning.

[Robie Basak (racb)]

> The trace also triggers for fetchmail presently

I couldn't reproduce this. Maybe something changed in Launchpad publications?

Anyway, the bug you point out is so clear I'll throw up an MP.