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 <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.
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
