Hi,

As per the title. This is annoying because it overrides the setting in
~/.devscripts.conf. Moreover, it can create conflicts when tarballs from
separate projects are named the same. For example, csound publishes the
manual in a separate tarball, both on github. Since both tarballs are
named the same (v6.X.Y), their names clash, and I ended up importing the
program into the manual repo.

Please either respect ~/.devscripts.conf, or default to --rename, since
that will cause less issues.

Control: severity -1 serious

Dear colleagues,

I have to remove the offending '--symlink' arg here:

/usr/lib/python3/dist-packages/gbp/deb/uscan.py:
    cmd = ['uscan', '--symlink', '--destdir=%s' % destdir, '--dehs']

to avoid local repository breakages packaging Kodi binary addons with the same
unmangled version.

Can this behavior be made configurable via gbp.conf or, at least, the switch
removed to honor settings set by developer? Recent versions of uscan treat
'--symlink' options as default anyway if not explicitly specified otherwise.

Regards,
Vasyl

Hi.  This bug came to my attention because I maintain a package with a
dependency on git-buildpackage.  This bug, which is flagged RC, is
causing the testing autoremoval system to want to remove my package,
presumably so that it can eventually remove gbp.

I read this report and I don't see any explanation for the RC status.
As far as I can tell this is not a regression ?  And it doesn't seem
likely that it causes unrecoverable data loss or the upload of badly
corrupted packsges ?  And it only affects one aspect of gbp's
functionality.

For now I am setting the severity back to normal.  Perhaps this is
wrong; if so, please do go ahead and put it back - with an
explaination.

Thanks,
Ian.

Hi Ian!
The problem is, I couls not reach Guido by email or push a request to his Git.
Should I attach the patch here with appropriate patch tag instead?

As for "it does not cause unrecoverable data loss" - yes, the loss is recoverable.
But what if you notice that an inappropriate tarball has been imported by a script
only when your CI pipeline fails? And the same wrong tarball poisoned ~10 repos
by the time you noticed it?

I raised the severity in hope Guido notices it and the new release gets rolled.
My intention is not to remove gbp from bullseye, definitely.

Adding Guido directly because my previous email semt from Gmail has never been
answered.
-- 
Vasyl Gello
==================================================
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.gello@gmail.com

Skype: vasek.gello
==================================================
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Vasyl Gello writes ("Re: git-buildpackage: import-orig --uscan passes --symlink unconditionally"):

You mean it works correctly in buster ?

Certainly.

I can see that this is a nuisance but I think it still does not
warrant an RC bug.  Presumably some script can also fix up the bad git
trees.

I don't think this is really an appropriate way to use the "serious"
severity.

This seems a bit unfriendly to me.  Maybe Guido is busy right now.
We're all volunteers here.  If you think you know how to fix the
problem, you could propose to fix it yourself eg with an NMU, using
the usual process.

Thanks,
Ian.

Hi Ian,

Unfortunately, no. So it is a bug not a regression, you are right.

Then I will just leave the patch here.

OK, noted tgat. Thanks for pointing that!
a kind of unfriendly takeover? I might misunderstand the Policy then!

If NMU is appropriate here, let me fix other bugs in gbp while Guido is busy.
-- 
Vasyl Gello
==================================================
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.gello@gmail.com

Skype: vasek.gello
==================================================
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

1 лютого 2021 р. 12:55:34 UTC, Ian Jackson <ijackson@chiark.greenend.org.uk> написав(-ла):

Hi,

I agree with Ian that the severity isn't correct
and IIRC just dropping the option caused problems with `--tarball-dir`
or similar so it's not just dropping the option.

Cheers,
 -- Guido

Vasyl Gello writes ("Re: Re: git-buildpackage: import-orig --uscan passes --symlink unconditionally"):

Great.


I'm going to reply to your next part in general terms.  I hope Guido
will agree with me.

The way I look at it is that doing an NMU is trying to do the
maintainer a favour.  If you are polite and nice about it, then you
are simply taking a task off their todo list.  That is helpful.

Obviously you want to give the maintainer plenty of early information,
and time.  That avoids a situation where the maintainer come back from
a week or two away to find an unpleasant surprise.  That will give the
maintainer time to let you know what they think.

If you wish to consider an NMU, make a plan for which bugs you will
try to upload fixes for - and of course taking into account the freeze
schedule.  Share that with the maintainer (in one of the bugs, like
this one) is a good way.

When you do upload you should consider the use of one of the DELAYED
queues.


Regards,
Ian.

Hi Ian, Guido!
There is no need for NMU since Guido is here, but noted for the future.

Guido, how is it best for you to review patches?

* Attaching to bugs
* Using Salsa cloned repo in my personal space

As for breakage, the best solution I see here is to introduce new gbp.conf parameter
like USCAN_SYMLINK={rename|symlink} plus check and warn the user if uscan's behavior
is overridden by environment variable somewhere.

What do you think? If the approach is fine, let me craft a PR!
-- 
Vasyl Gello
==================================================
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.gello@gmail.com

Skype: vasek.gello
==================================================
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Hi Vasyl,

I think the best way is to figure out if we can't just drop the option
and have users configure it via `~/.devscripts.conf`. The reason i did (unfortunately)
not act on it yet is that i didn't get around to test all the
possibilities like `--tarball-dir`, multiple tarballs, etc.
I went back in the git history the other day and didn't spot anything
obvious but didn't want to make the change close to Debian release
without thorough testing. So if you want to check that out, that'd be
great.

We have some network based tests see `GBP_NETWORK_TESTS` so if you want
to add some testing the different import cases with `--uscan` based
tests. We could cook up some watch files that pull in things from a
stable location.

Cheers,
 -- Guido