[Pkg-javascript-devel] Bug#962039: Bug#962037: Plan B for not being able to replicate upstream exports exactly

[Daniel Ring]

Control: reopen 962037
Control: reopen 962039

Sorry about closing the bugs early, I'm used to close-on-commit instead 
of close-on-release and I forgot Debian handles things differently. I 
updated Rainloop's changelog on Salsa to indicate that these are fixed.

I didn't realize that this bug was due to Rainloop blocking the 
migration of node-less to unstable; my comment about testing 
experimental versions was because this started off as a node-less bug, 
and it looked like most of the issues weren't related to Rainloop. I'm 
happy to help with transitions from the Rainloop side but it may take me 
up to a few weeks to respond to non-security issues.

Is pkg-js-tools stable, and is there good documentation for it? I took a 
quick look but only found a README with a list of debhelper hooks. My 
main argument for using flat files for Rainloop's bundled dependencies 
is that I only look at this package once or twice a year when upstream 
releases a new version, and I don't want to relearn the tooling each 
time. (That's also why I replaced my custom Makefile with upstream's 
build system.) I agree that Quilt is a better way to handle the patches 
to the bundled libraries though.

By "broken in unstable" I just meant Rainloop's code in Salsa, which now 
depends on experimental node-less to build; the compiled package is fine 
either way. (Also, it looks like updated node-less is now in unstable, 
so it's not broken anymore.)

-- Daniel

On 6/15/2020 3:37 AM, Pirate Praveen wrote:
> 
> 
> On Sun, Jun 14, 2020 at 9:33 pm, Daniel Ring <dring at wolfishly.me> wrote:
>> There are several different issues in this bug, I'll address each of 
>> them individually (identified by message date as shown in the BTS for 
>> bug 962037):
>>
>>
>> Date: Tue, 02 Jun 2020 16:30:29 +0530
>>
>> I unfortunately don't have the time to regularly test package versions 
>> in experimental. Javascript development moves very quickly and 
>> packages often change their APIs with each new version, many of which 
>> don't even make it to unstable. The issue will likely be resolved by 
>> updating the bundled version of gulp-less.
> 
> I did not ask you to test with every package in experimental. The idea 
> is to give you a warning that less.js will soon come to untsable and you 
> can be ready with the required changes before that. This is a standard 
> practice (transitions) when uploading breaking changes. In this case, 
> you were asked to test a specific package in experimental after I 
> verified your package breaks with the new version (and no other package 
> breaks). If you prefer not to be notified in advance for breaking 
> changes, I'd be happy to ignore rainloop for any future transitions. You 
> will still get a chance to fix when someone files an FTBFS bug against 
> rainloop.
> 
>> Date: Tue, 02 Jun 2020 16:30:29 +0530
>>
>> Please don't bundle dependencies or dependencies of dependencies 
>> unless absolutely necessary, and if you must then only include the 
>> required files. The Rainloop package is bloated enough due to upstream 
>> bundling as it is. It appears that pkg-js-tools bundling doesn't 
>> handle this, so I didn't use it. The version numbers of the packages I 
>> bundled are included in a comment at the top of each file, but I had 
>> to modify most of them to remove dependencies not in Debian (and not 
>> required for Rainloop to build), so they can't be trivially updated
> 
> Please don't invent your own methods and follow the standards used by 
> the rest of the team. If everyone invents their own methods to embed, 
> that makes it unnecessarily hard to collaborate as a team. I don't think 
> the rest of the js team agrees with your judgement here. This method 
> makes is harder to update embedded dependencies and it essentially 
> become a fork. You can use the normal patching workflow with quilt for 
> modules embedded via pkg-js-tools (it is not even specific to 
> pkg-js-tools, it is supported by dpkg and used across the archive).
> 
> Js Team,
> 
> Please comment your opinion here as we have a difference in embed 
> strategy here.
> 
>>
>> The dependencies I bundled are all build tools pinned to specific 
>> versions by upstream, so updates to them aren't particularly 
>> significant. Any bundled dependency important enough for its version 
>> number to be tracked should be made into its own package instead. 
>> Let's not build a new package management system on top of the existing 
>> one just to dodge the NEW queue.
>>
> 
> No, we did not build this by choice. It was proposed and pushed by ftp 
> masters to reduce the number of node packages in the archive. Many 
> packages in NEW were rejected already because they were too small. 
> https://wiki.debian.org/Javascript/Nodejs/NEW So for node packages, only 
> complex dependencies are expected to be packaged separately. So you are 
> completely wrong here to assert the idea is to dodge the NEW queue.
>>
>> Date: Tue, 02 Jun 2020 16:52:33 +0530
>>
>> This message appears to be meant for the less.js fork of the bug.
>>
>>
>> Date: Tue, 02 Jun 2020 18:56:26 +0530
>>
>> It is not maintainable to call lessc directly instead of using 
>> gulp-less. I created a custom Makefile to build Rainloop in the first 
>> version of this package, but it was unmaintainable; the upstream build 
>> process changes slightly with each release, and I would have to 
>> relearn and rewrite my Debian-specific hacks each time. That's why I 
>> switched to using upstream's build system directly and bundling the 
>> handful of missing Gulp modules in the latest release.
>>
>>
>> Date: Tue, 02 Jun 2020 22:33:01 +0530
>> Date: Wed, 03 Jun 2020 00:29:58 +0530
>>
>> These messages appear to be related to issues with less.js, not Rainloop.
>>
>>
>> Date: Wed, 03 Jun 2020 01:27:35 +0530
>> Date: Fri, 05 Jun 2020 11:36:16 +0530
>> Date: Fri, 05 Jun 2020 11:54:23 +0530
>>
>> The bundled gulp-less version appears to be incompatible with the new 
>> version of node-less. I had modified it to work with the outdated 
>> version currently in the Debian archive; after reverting the relevant 
>> changes, Rainloop now builds with node-less from experimental. Note 
>> that the build will be broken in unstable until node-less migrates 
>> from experimental.
>>
> 
> You don't have to upload broken packages to unstable. You can wait till 
> less.js lands in unstable to upload your changes to experimental. The 
> idea is to give you a chance to fix your package before it actually breaks.
> 
>> Date: Fri, 05 Jun 2020 15:10:04 +0530
>> Date: Fri, 05 Jun 2020 17:11:12 +0530
>> Date: Fri, 05 Jun 2020 21:32:03 +0530
>>
>> The node-autolinker package was updated by yadd (Xavier Guimard) a few 
>> weeks ago and the path of the Autolinker.js file changed. Updating the 
>> path resolved the build error.
>>
>> I pushed the fixes for both issues to the Rainloop repository on 
>> salsa.d.o. Rainloop now builds successfully on current unstable with 
>> node-less from experimental.
>>
> 
> Thanks, I can upload it to unstable.
> 
>> -- Daniel
>>
>> On 6/5/2020 9:02 AM, Pirate Praveen wrote:
>>>
>>>
>>> On Fri, Jun 5, 2020 at 5:11 pm, Pirate Praveen 
>>> <praveen at onenetbeyond.org> wrote:
>>>>
>>>>
>>>> On Fri, Jun 5, 2020 at 3:10 pm, Pirate Praveen 
>>>> <praveen at onenetbeyond.org> wrote:
>>>>> This is likely broken by node-merge-stream update from 1.0 
>>>>> to 2.0. node-merge-stream is a build dependeny of node-autolinker.
>>>>
>>>> Tried building with autolinker 3.x in embed-autolinker-3 branch, 
>>>> but the same failure.
>>>>
>>>> I tried to run the upstream test suite for node-autolinker 
>>>> (yarnpkg install, yarnpkg test), but it seems gulp 3 is 
>>>> segfaulting in debian, tried with node 10 and 12 via npm with the 
>>>> same results. I had seen the same failure when trying to run gulp 
>>>> in node-puka as well.
>>>
>>> All unit tests passed on autolinker master which has gulp 4 with 
>>> merge-stream 2.0, so it is not merge-stream change that broke.
>>>
>>>
> 
>