Re: RFS: mwic 0.7.4-1
On Wed, Mar 21, 2018 at 1:11 AM, Georg Faerber wrote:
> Thanks a lot for your review, and sorry for not responding earlier, too
> much stuff on my table:
There is no need to apologise for being busy :)
> On 18-03-18 11:33:59, Paul Wise wrote:
>> The copyright years are missing 2012, I'm not sure if the ftp-masters
>> would reject the package on that basis.
>
> I've referred to the upstream git history, instead of the licence file.
> Fixed.
I found the missing copyright year in one of the test files, not the
license file.
>> doc/mwic.1 and tests/coverage are generated files, they should be
>> removed from the upstream VCS and tarballs and be always built from
>> source. If upstream refuses, you should remove them in `debian/rules
>> clean` and very early in `debian/rules build` so that the package will
>> never depend on the existing upstream files.
>
> I've searched quite a bit on the Internets how to do this, and leverage,
> for now, dh_clean. I hope that this is an acceptable method for this, I
> didn't found any "official" source. I'll approach upstream regarding
> these files.
It needs to be done in both debian/rules clean and build, otherwise
building the package without the clean step will use the prebuilt
file. dh_clean is fine for the first one, but you need to override
dh_auto_configure or dh_auto_build for the second one.
> Also, the man page is now generated during dh_auto_install. I've added a
> build dependency on python3-docutils for this.
That is the wrong time to generate it, please change that to dh_auto_build.
> After reading your mail I debugged this again: It's not about the top
> level directory, at least if using gbp buildpackage, but about
> 'export-dir'. Placing a symlink inside there which points to the actual
> signature makes this work! :)
...
> For now, I've wrote a wrapper script just for personal use, but I'll
> work on [2] and [3] to get this implemented in a proper way.
Great.
> See above. (Personally, I really dislike the trailing comma.)
The reason for the trailing comma option is that when you add a new
item to the end of a list of dependencies, you don't also have to
modify the line before it, making the diff easier to read, which is
most of the point of the wrap-and-sort tool.
> There is no man page currently, and also, more importantly, out of the
> box this doesn't run in a non-interactive way. I guess, at least some
> people, might run mwic via a CI pipeline, that's why I don't ship this.
> I'll approach upstream regarding this.
Fair enough.
> I'm aware that this was recently added to lintian, and reading
> the bug, again, makes me wonder what's the process of getting a new
> check into lintian.
The process for adding a check is to file a bug on lintian and wait a
day, lamby is incredibly active on incoming lintian requests.
> Correct. Still, my question stands: How do I enable autopkgtests for
> this package?
I haven't yet dealt with autopkgtests so I'm not sure.
> The texts are the same, there are only differences in special chars like
> ", so I guess this is a false positive.
You may want to file a bug on license-reconcile about these false
positives re Expat vs MIT/X11.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Reply to: