Hi Sean, Thanks for the clear and detailed review! Please see my reply below.
Sean Whitton <spwhit...@spwhitton.name> writes: > Hello Xiyue, > > Alright, looking at commit 8e06c63: > > - Renaming the file from CHANGELOG.org to changelog in a build target > dirties the tree, and could mean the package will fail to build twice. > > You could rename it back in the clean target, but I think it would be > more maintainable to install CHANGELOG.org as changelog -- the > equivalent of doing 'cp ./CHANGELOG.org /usr/share/doc/foo/changelog'. > > I can't remember whether you can make dh_installdocs do this or > whether you have to do it with dh_install; please take a look. > Whatever you do, you'll need to ensure you avoid interfering with the > automatic .gz compression of files under /usr/share/doc. > I was trying to do something clever in 4a92133 so that the file is only moved/renamed in the first build so that build-twice-in-a-row can work. But it does dirty the source tree. I also tried d/install, but it cannot rename files. In fact, all Debian control files supporting the "source destination" format seem to treat destination as a directory only and are created on demand, which I think makes sense. I think manually using install/rename the file in override_dh_installdocs will interfere with the automatic handling of dh_* tools anyway and I'd like to avoid that. So instead, I opt for one of the previous ideas: install changelog as a symlink of CHANGELOG.org in d/links, which should take care of all the unnecessary renaming dance. However, it triggers another lintian warning "debian-changelog-file-is-a-symlink", which it should not as the document says if the file is under /usr/share/doc/*pkg* it should be fine, which CHANGELOG.org is. Anyway, I added a lintian override for that for now and will file a follow up bug to track this false positive case on lintian. > - d/copyright needs a lot of work. Given the addition of all the new > files, this is almost like an ITP. Please go through it again and > ensure it accurately reflects the source. > For example, CODE_OF_CONDUCT.md has its own license and copyright. > icons/vscode/ might indeed be DFSG-compatible, but why would the > emacs-lsp maintainers hold copyright? > Surely it is Microsoft or something? > I'm afraid you need to track these facts down, or the files have to be > excluded again. Please use Comment: fields in d/copyright to explain > your sources, so it's easier to verify. > Thanks for pointing this out. I was under the impression that the files in the source code should be covered by the authors of the source, but I missed the fact that those files were derived work. I have now updated the copyright info with Comments to clarify the situation. PTAL. > By the way, you can combine all the stanza for files under the same > license like this: > > Files: dap-edge.el > dap-node.el > dap-pwsh.el > dap-utils.el > dap-go.el > dap-launch.el > Copyright: (C) 2019 Kien Nguyen > (C) 2018 Aya Igarashi > (C) 2020 Nikita Bloshchanevich > License: GPL-3+ > > etc. > > Be sure you're familiar with the copyright format spec.; there are more > shortcuts allowed than most people seem to realise. > I took a look at the machine-readable copyright format document[1], specifically the example given in the copyright section 6.8, and I think it meant that if a group of file shares any copyright holder(s), those files can be grouped in the same stanza - in the example, Angela Watts appeared in both source files so those files can share the same stanza. I think in the case for dap-mode, each file has only a single copyright holder so may be this simplification doesn't apply, so I opt to provide separate stanza for all files. I surely hope I can list everyone under "Files: *" so that things can be simpler, but keeping it as-is just in case. [1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ > -- > Sean Whitton -- Regards, Xiyue Deng
signature.asc
Description: PGP signature
