On Sun, Jun 14, 2020 at 9:33 pm, Daniel Ring <dr...@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
<prav...@onenetbeyond.org> wrote:
On Fri, Jun 5, 2020 at 3:10 pm, Pirate Praveen
<prav...@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.
