pmtiles-swarm 0.9.0 → 0.9.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +19 -0
- package/docs/running-as-a-service.md +5 -2
- package/package.json +2 -2
package/CHANGELOG.md
CHANGED
|
@@ -7,6 +7,25 @@
|
|
|
7
7
|
### 🐞 Bug fixes
|
|
8
8
|
- _...Add new stuff here..._
|
|
9
9
|
|
|
10
|
+
## 0.9.1
|
|
11
|
+
### 🐞 Bug fixes
|
|
12
|
+
- **Requires pmtiles-torrent 0.4.2, which is what actually makes a newly built archive visible.**
|
|
13
|
+
0.9.0 said the 0% was the dropped `seedOnly`. That was half of it — the half that made the
|
|
14
|
+
archive *slow*. The half that made it *invisible* was in the sidecar: creation defaults to a
|
|
15
|
+
hybrid v1+v2 torrent, and libtorrent answers `info_hash()` for a hybrid with the truncated v2
|
|
16
|
+
hash, while the catalog, the magnet and every v1 peer use v1. The engine held the archive under
|
|
17
|
+
a name the catalog could not look up, so a correctly seeding archive was reported as one the
|
|
18
|
+
engine had never heard of, and no tile could be served from it. The dependency floor moves to
|
|
19
|
+
0.4.2 rather than being left to whatever a fresh install happens to resolve.
|
|
20
|
+
|
|
21
|
+
Expect hybrid archives to re-check once on the first start after upgrading: their resume files
|
|
22
|
+
are now looked for under the corrected name, and the old ones are not found.
|
|
23
|
+
- **The service documentation pointed its status check at a path that does not exist.** It named
|
|
24
|
+
`/opt/pmtiles-swarm/src`, while a node installed the way the rest of that document describes has
|
|
25
|
+
its executable in `/var/lib/pmtiles-swarm/node_modules/.bin`. Running the documented command
|
|
26
|
+
found no dependencies and failed on the first import — which is the same
|
|
27
|
+
wrong-command-in-documentation problem the status command exists to end.
|
|
28
|
+
|
|
10
29
|
## 0.9.0
|
|
11
30
|
### ✨ Features and improvements
|
|
12
31
|
- **`pmtiles-swarm status`**, which asks a running node what it is doing and reads the answer out
|
|
@@ -441,10 +441,13 @@ Then check it is actually serving:
|
|
|
441
441
|
|
|
442
442
|
```sh
|
|
443
443
|
curl -fsS localhost:8090/feed.xml >/dev/null && echo "public surface ok"
|
|
444
|
-
|
|
445
|
-
--config /etc/pmtiles-swarm/swarm.config.json
|
|
444
|
+
sudo -u pmtiles-swarm -H /var/lib/pmtiles-swarm/node_modules/.bin/pmtiles-swarm \
|
|
445
|
+
status --config /etc/pmtiles-swarm/swarm.config.json
|
|
446
446
|
```
|
|
447
447
|
|
|
448
|
+
Safe to run against a live node: it asks over HTTP and takes no lock, so it is
|
|
449
|
+
not the second process the data directory would refuse.
|
|
450
|
+
|
|
448
451
|
Ask through the status command rather than with `curl`. Reaching the API by hand
|
|
449
452
|
means getting the bind address, the admin port and the credential right in one
|
|
450
453
|
go, and each of them fails in a way that looks like a broken node: a node bound
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "pmtiles-swarm",
|
|
3
|
-
"version": "0.9.
|
|
3
|
+
"version": "0.9.1",
|
|
4
4
|
"description": "BitTorrent distribution for PMTiles map archives: create torrents, watch folders, publish and subscribe to RSS feeds, and seed through qBittorrent or an embedded client",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "src/index.js",
|
|
@@ -39,7 +39,7 @@
|
|
|
39
39
|
"maplibre-gl": "^6.2.0",
|
|
40
40
|
"parse-torrent": "^11.0.24",
|
|
41
41
|
"pmtiles": "^4.4.1",
|
|
42
|
-
"pmtiles-torrent": "^0.4.
|
|
42
|
+
"pmtiles-torrent": "^0.4.2",
|
|
43
43
|
"webtorrent": "^3.0.21"
|
|
44
44
|
},
|
|
45
45
|
"engines": {
|