#1148652 python-trame-client: Transition to Vue version 3.5.x

#1148652#5
Date:
2026-09-21 15:00:47 UTC
From:
To:

Dear maintainer,

You received this because your package has build-depends on node-vue.

I intend to upgrade node-vue from 2.7 to 3.5.x in Debian. I will make
an update here once the package available in Debian.

Please be aware of this upcoming transition. If you have any concerns,
please let me know.

Best regards,

#1148652#10
Date:
2026-09-29 10:54:56 UTC
From:
To:
Dear Team,

I opened #1148652 for python-trame-client. However after close check
how to resolve the version bump from vue 2.7 to vue 3.5 for
python-trame-client.

I found python-trame-client has self-contains vue2 and vue3 apps:
https://salsa.debian.org/python-team/packages/python-trame-client/-/blob/master/debian/README.Debian

There is a script to prepare javascript downloaded from internet and
then built with npm. And then place the buiult app under debian/ with
it's https://salsa.debian.org/python-team/packages/python-trame-client/-/blob/master/debian/vue-apps/update.sh

And then the package ships the vue2 and vue3 apps:
python3-trame-client:
/usr/share/python3-trame-client/vue2-www/coi-serviceworker.js
python3-trame-client:
/usr/share/python3-trame-client/vue2-www/css/app.5a11a13f.css
python3-trame-client: /usr/share/python3-trame-client/vue2-www/index.html
python3-trame-client:
/usr/share/python3-trame-client/vue2-www/js/app.b597bec0.js
python3-trame-client:
/usr/share/python3-trame-client/vue2-www/js/chunk-vendors.c954024b.js
python3-trame-client: /usr/share/python3-trame-client/vue2-www/loading.tpl
python3-trame-client: /usr/share/python3-trame-client/vue2-www/logo.png
python3-trame-client: /usr/share/python3-trame-client/vue2-www/vue.global.js
python3-trame-client:
/usr/share/python3-trame-client/vue3-www/assets/index-BmfI-euc.js
python3-trame-client:
/usr/share/python3-trame-client/vue3-www/assets/index-CNEebpfp.css
python3-trame-client:
/usr/share/python3-trame-client/vue3-www/coi-serviceworker.js
python3-trame-client: /usr/share/python3-trame-client/vue3-www/index.html
python3-trame-client: /usr/share/python3-trame-client/vue3-www/loading.tpl
python3-trame-client: /usr/share/python3-trame-client/vue3-www/logo.png
python3-trame-client: /usr/share/python3-trame-client/vue3-www/vue.global.js

Not sure if it's a magic that all of my package has missing build-deps
on nodejs can follow the same or it's not allowed in Debian policy?
Any idea?

Best regards,

#1148652#15
Date:
2026-09-29 12:18:55 UTC
From:
To:
Quoting Andrew Lee (2026-09-29 12:54:56)
[...]
not permit network access during build.

 - Jonas

#1148652#20
Date:
2026-09-29 12:26:08 UTC
From:
To:
Hi Jonas,

Have you checked the code? The script is not made for running at
build-time from build-daemon but from maintainer in it's packaging
environment to run npm commands.

Best regards,

#1148652#25
Date:
2026-09-29 12:45:48 UTC
From:
To:
Quoting Andrew Lee (2026-09-29 14:26:08)

It is permitted to package dead-end tools to "infect" users' systems
with non-Debian tools, but what is your point in doing that? You cannot
package any code that _needs_ vue if that package is only available
through pulling it in from an external source.

An example of dead-end helpers is the official Debian package rustup
which is nice and convenient for users *not* caring about source, but
totally useless for Debian developers for packaging anything depending
on that side-installed tool.

So back to your original question: Why do you ask? What is the aim?

 - Jonas

#1148652#30
Date:
2026-09-29 12:59:31 UTC
From:
To:
Please have a look so that you can answer my question correctly.

My main goal is to build web front for a golang package. The is a
missing build-deps on vue3. Jermeny suggest to update vue.js 2.7 to
version 3.5 in Debian, and you asked me to make sure all the
reverse-dependency such as python-trame-client works correctly with
updated vue.js versoin 3.5.

And my original question here: I wanted to ask if the way
python-trame-client currently handles its web app is fully compliant
with Debian policy. If this approach is acceptable, I am hoping to
follow the same method to build the web frontend for the golang
package, which would save me from having to package all of the missing
Node.js build-deps from scratch.

Best regards,
-Andrew

#1148652#35
Date:
2026-09-29 13:45:21 UTC
From:
To:
Quoting Andrew Lee (2026-09-29 14:59:31)

No, I will not read the source code for the project you are working on.

I am puzzled that any answer *not* based on that is judged incorrect.

 - Jonas

#1148652#40
Date:
2026-09-29 14:24:42 UTC
From:
To:
Sorry for the confusion. I did not mean for you to check any code.

My question was just about Debian policy in general, asking if using
the way to ship prebuilt web app is okay to avoid complex Node.js
build steps.

Thanks for your help anyway.

#1148652#45
Date:
2026-09-29 15:25:44 UTC
From:
To:
Quoting Andrew Lee (2026-09-29 14:59:31)
look at the below (assuming that's what you meant) and answer based on
that.

Debian packages must include source, where compacted JavaScript code is
not considered source.

If your goal is to build a web front *locally* on your system, then it
you can create an official Debian package containing a shell script
that calls curl or wget to fetch vue somewhere on the internet, install
that package, run that vue-fetcher, and build your web front. Such a
package would in my understanding need to be placed in contrib (not
main), because even if the script is free, it effectively depend on
non-source-code-according-to-the-interpretation-above. An example of
such package is torbrowser-launcher - and an example that surprisingly
seem to be in main is rustup.

If your goal is to build a web front as part of an official Debian
package, then you cannot do the above in main or contrib - only in
non-free (which is technically not official Debian) can you stuff
non-source code into a package.

It does not matter to the above whether other packages are doing it
already: Two wrongs don't make a right.

What might matter is that I can be mistaken. If you are looking for
rock-solid interpretations of the exact boundaries of Debian rules,
because you want to do some cleverness close to the boundary, then I
suspect that consulting a team list is the wrong place to ask: A better
place is debian-devel or debian-legal, I guess.

 - Jonas

#1148652#50
Date:
2026-10-01 09:18:21 UTC
From:
To:
Le mar. 29 sept. 2026 à 17:26, Jonas Smedegaard <jonas@jones.dk> a écrit :

That answers the question of Andrew.

The actual issue is that python-trame-client source package does just that,
it
embeds compiled files to work around Debian Policy:
https://sources.debian.org/src/python-trame-client/3.12.3-2/debian/vue-apps

I can understand that *source files* of other softwares are sometimes
embedded,
but they are unavailable in Debian, and are needed to build the package.
This is not the case here, this violates DFSG 2.2

I am retitling and raising severity.

***
I propose to solve it this way, and even better, I propose to solve it
myself:

python3-trame-server supports multiple client types (vue2, vue3, even react
in latest upstream version).
https://sources.debian.org/src/python-trame-server/3.12.4-2/src/trame_server/core.py#L22
The default client type is vue3.
As this is meant for backward compatibility, and as I don't see any
application in Debian that currently depends
on python3-trame-client and vue2, we can probably move forward and let
trame-client provide the vue3 client type,
using the latest node-vue package, instead of bundling compiled versions of
vue2 and vue3 without providing the sources.

Jérémy

#1148652#59
Date:
2026-10-01 10:29:48 UTC
From:
To:
Le jeu. 1 oct. 2026 à 11:18, Jérémy Lal <kapouer@melix.org> a écrit :
New packages:
- gl-matrix (looks cool enough, but maybe it's simpler to move it to
components for now)
- xmlbuilder2 (maintained, very popular)
- @msgpack/msgpack (the famous msgpack format, super popular)

Add as components:
- @kitware/vtk.js (same upstream)
- wslink (same upstream)
- webworker-promise (wrapper, specific, no release for 4 years)
- utif (used to decode tiff, specific, no release for 7 years)
- spark-md5 (specific, no release for 5 years)
- globalthis (20-lines shim, somewhat useless, as globalThis is widely
available on browsers now)

For @types/webxr, it's different:
It provides standard DOM API types from DefinitelyTyped, and we don't
distribute the whole thing, as it is so huge.
It would make sense to distribute sub-groups of it, like "all the web
browsers API available to javascript":
node-browser-types with components:
@types/web
@types/webxr
@types/w3c-web-usb
@types/w3c-web-serial
@types/w3c-web-hid
@types/web-bluetooth
None of them are already available, yet any typescript app that runs on a
browser will need it (mostly @types/web).

cd vue3-app
pkgjs-depends
# 14 missing npm module(s)


DEPENDENCIES:
  node-autoprefixer (autoprefixer)
  node-babel7 (@babel/preset-env)
  node-commander (commander)
  node-d3-scale (d3-scale)
  node-define-properties (define-properties)
  node-fast-deep-equal (fast-deep-equal)
  node-fflate (fflate)
  node-js-yaml (js-yaml)
  node-pako (pako)
  node-seedrandom (seedrandom)
  node-shelljs (shelljs)
  nodejs (@types/node)

MISSING:
trame-app-vue3@HASH(0x557b73bc1fa8)
 └── @kitware/vtk.js (35.16.0)
     └── @types/webxr (0.5.24)
     └── gl-matrix (3.4.3)
     └── globalthis (1.0.3)
     └── spark-md5 (3.0.2)
     └── utif (3.1.0)
     └── webworker-promise (0.5.0)
     └── xmlbuilder2 (3.0.2)
         └── @oozcitak/dom (1.15.10)
             └── @oozcitak/infra (1.0.8)
                 └── @oozcitak/util (8.3.8)
             └── @oozcitak/url (1.0.4)
                 └── (^) @oozcitak/infra (1.0.8)
                 └── (^) @oozcitak/util (8.3.8)
             └── (^) @oozcitak/util (8.3.8)
         └── (^) @oozcitak/infra (1.0.8)
         └── (^) @oozcitak/util (8.3.8)
     └── wslink (2.5.0)
         └── @msgpack/msgpack (2.8.0)
 └── (^) wslink (2.5.0)

#1148652#64
Date:
2026-10-04 09:28:04 UTC
From:
To:
Hi,
apologies for the later reply: I had forgotten I had worked on python-trame-*
packages.

I am the author of most the "sketchy" scripts/patches that you have found: if
any of them violates the policy, lay the blame on me.
It was an attempt I made 7 months ago, and was my first (and only) time working
on a package with a non-trivial javascript part. I knew it was fishy, and I
didn't pursue the upload at the time due to this.

I can't commit to improving my earlier attempt: I am not knowledgeable in
javascript packaging, and I'd rather spend the time I have available for debian
contributing to packages which are closer to my capabilities.
If anyone of you can improve the current packaging, that would be great. I can
try to help when new versions are released, but only after someone else does the
initial packaging (and by "initial" I mean "dropping my sketchy workarounds").
If nobody can help, then I'll leave it to Roland to decide what to do with the
current upload (i.e., to ask for RM if it not DFSG compliant).

For reference, this is part of four source packages:
python-trame, python-trame-client, python-trame-common, python-trame-server,
which may need to be updated and uploaded at the same time.

Cheers,
Francesco

PS: I am not a member of the debian-js list, so any message sent there outside
of this bug report  would need my email address in cc.

#1148652#69
Date:
2026-10-04 09:48:45 UTC
From:
To:
Le dim. 4 oct. 2026 à 11:31, Francesco Ballarin <ballarin@debian.org> a
écrit :

I will implement the plan above.

In exchange, can you package python3-newspaper ? I need it for Newelle ;)