<div id="geary-body" dir="auto"><div><br></div></div><div id="geary-quote" dir="auto"><br>On Thu, Oct 24, 2019 at 16:19, Jonas Smedegaard <dr@jones.dk> wrote:<br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">Quoting Pirate Praveen (2019-10-24 15:34:15)
<blockquote> On Thu, Oct 24, 2019 at 11:40, Jonas Smedegaard <<a href="mailto:dr@jones.dk">dr@jones.dk</a>> wrote:
 > The source package src:node-lodash states in its debian/copyright 
 > file that its upstream source is <<a href="https://github.com/lodash/lodash">https://github.com/lodash/lodash</a>>
 > 
 
 I don't thik that is how DFSG is intrepreted. If that were the case, 
 then we won't able to modify upstream tarball at all.
</blockquote>
I am not surprised (but frustrated and sad) that you try to argue that 
what is listed as upstream source need not be upstream source.


<blockquote> You need to check with the release tarballs.
 <a href="https://github.com/lodash/lodash/releases">https://github.com/lodash/lodash/releases</a>
</blockquote>
If upstream source is not <a href="https://github.com/lodash/lodash">https://github.com/lodash/lodash</a> but instead 
it is <a href="https://github.com/lodash/lodash">https://github.com/lodash/lodash</a> then it is a(nother) bug that the 
package points at the wrong place for its upstream source.


<blockquote> We don't usually specify the releases page in debian/copyright only 
 the project page. You can verify this against any other package in 
 debian.
</blockquote>
That's no bug if project page _also_ is upstream source, as is commonly 
the case e.g. at Github.

It is a minor bug when project page clearly and unambiguously references 
upstream source.

It is a severe bug when project page serves code which upstream use as 
their prefered form for editing but the code distributed with Debian as 
"upstream source" is *not* that same code but instead some other code, 
regardless how clearly that other non-source code is referenced from 
project page, and regardless if upstream labels that other code as their 
"releases".
<br></div></blockquote><span style="white-space: pre-wrap;"><div><span style="white-space: pre-wrap;"><br></span></div>As far as I understood, the other code you mention here is the vendor directory. Please correct me if I'm mistaken. Or specify which specific files you have a problem with. Files in vendor directory usually have their own separate projects and version control systems.</span><div><span style="white-space: pre-wrap;"><br></span><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">This bug is about the code upstream treats as their source *not* being 
what Debian distributes as upstream *source*.


<blockquote> All files derived from source have their corresponding source code and 
 it is regenerated during build.
</blockquote>
It may very well be "source" but not "upstream source".
<br></div></blockquote><span style="white-space: pre-wrap;"><div><span style="white-space: pre-wrap;"><br></span></div>Then I fail to see how this is a serious bug. Serious bug is usually when the source package does not ship corresponding source code for the shipped binary. I don't think what you describe as a problem here can be considered serious.</span></div><div><span style="white-space: pre-wrap;"><br></span><div><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">
<blockquote> As for lodash-cli, it is included as another source tarball and you 
 can see this in the dsc file.
</blockquote>
This bug is *not* about embedded code, it is about the main code.
</div></blockquote><span style="white-space: pre-wrap;"><br>As far as I understand there is not a requirement to take a git snapshot. Can you tell which files you see as problematic? I can think of only vendor/* that was not seen in the git repo.</span></div></div></div>