git-ubuntu

Bug #1836286
Comment #3

Comment 3 for bug 1836286

Revision history for this message

Bryce Harrington (bryce) wrote on 2021-07-08:

Hi Utkarsh,

That traceback is a bit generic, it gets triggered whenever build.fetch_orig() finds no tarballs, for whatever reason. The actual bug in these cases is the 'whatever reason' part but the traceback doesn't really tell anything about that. The steps to reproduce are important in this case, due to that.

For additional background, build.fetch_orig() is just a wrapper that iterates through a set of different tarball-retrieval mechanisms. It iterates through this set until one of them works. "pristine-tar" is one of the first attempted but (for me at least) it rarely works. (Using "--no-pristine-tar" is kind of irrelevant in such cases since it isn't going to work anyway.)

It also tries to download from launchpad, which is what usually works for me, although it's subject to launchpad outages and so on. Notably, the launchpad mechanism also fails if you're doing a merge, since the new tarball obviously isn't uploaded to launchpad yet. In this case, the established workaround is to do:

$ git ubuntu export-orig --for-merge

It seems like this should be something git-ubuntu could figure out for itself, but for now just remember to use '--for-merge' when you're doing export-orig for merges.

The other mechanisms attempt to pull from local caches, which can make export-orig succeed even in cases where the above two mechanisms normally would fail.

A workaround I have been using often when git ubuntu export-orig fails, is to run:

$ uscan -dd

Note that this works *only* for packages that have debian/watch files with valid url patterns, but I've usually been lucky. It occurs to me that adding 'uscan -dd' as another mechanism for fetch_orig() might be worth considering, although Robie might know a reason why this isn't implemented there already...

Anyway, back to the traceback in question; this is actually a side-effect of the above, because exportorig.py's code tries to do len(tarballs) but tarballs==None, for any of the reasons outlined above. LP: #1868631 shows my original idea for papering over this crash, although looking at it now I see the actual coding error is in fetch_orig()... I'll send in an MP for that.

Hi Utkarsh,

That traceback is a bit generic, it gets triggered whenever build.fetch_orig() finds no tarballs, for whatever reason.  The actual bug in these cases is the 'whatever reason' part but the traceback doesn't really tell anything about that.  The steps to reproduce are important in this case, due to that.

For additional background, build.fetch_orig() is just a wrapper that iterates through a set of different tarball-retrieval mechanisms.  It iterates through this set until one of them works.  "pristine-tar" is one of the first attempted but (for me at least) it rarely works.  (Using "--no-pristine-tar" is kind of irrelevant in such cases since it isn't going to work anyway.)

It also tries to download from launchpad, which is what usually works for me, although it's subject to launchpad outages and so on.  Notably, the launchpad mechanism also fails if you're doing a merge, since the new tarball obviously isn't uploaded to launchpad yet.  In this case, the established workaround is to do:

$ git ubuntu export-orig --for-merge

It seems like this should be something git-ubuntu could figure out for itself, but for now just remember to use '--for-merge' when you're doing export-orig for merges.

The other mechanisms attempt to pull from local caches, which can make export-orig succeed even in cases where the above two mechanisms normally would fail.

A workaround I have been using often when git ubuntu export-orig fails, is to run:

$ uscan -dd

Note that this works *only* for packages that have debian/watch files with valid url patterns, but I've usually been lucky.  It occurs to me that adding 'uscan -dd' as another mechanism for fetch_orig() might be worth considering, although Robie might know a reason why this isn't implemented there already...

Anyway, back to the traceback in question; this is actually a side-effect of the above, because exportorig.py's code tries to do len(tarballs) but tarballs==None, for any of the reasons outlined above.  LP: #1868631 shows my original idea for papering over this crash, although looking at it now I see the actual coding error is in fetch_orig()...  I'll send in an MP for that.