Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Confirm whether an installed `.deb` auto-updates, and document the answer

Aperta
  • Qualcosa non va?
#2,011 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
65/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
electron, linux
Ambito
desktop, documentation

Direzione di ricerca

Read docs/architecture/updates.md, ADR 0020, and surfsense_local/electron/src/main/updater.ts; inspect resources/package-type in an installed v2.0.2 .deb. On an x64 Linux desktop, allow updates in Settings › About, record whether 2.0.3 is offered, downloads, and installs on restart, and attach the session log with your distribution and version. Replace the table's likelihood and remove the Known gaps line; if a code or configuration change proves necessary, use updater.test.ts and run pnpm test.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

desktop documentation help wanted

The gap

docs/architecture/updates.md lists this under Known gaps:

The deb build likely auto-updates, although the launch plan said it would not: electron-builder writes resources/package-type for a deb, electron-updater picks its deb updater from that file, and v2.0.2's stable-linux.yml on the release lists SurfSense.deb. Not checked on an installed deb.

Why it matters

The doc's release table currently says "likely the deb", and the launch plan said the deb would not update itself. Both cannot be true, and it is deb users who find out which. If it does update, someone who installed through their package manager gets an application that replaces itself outside it, and that deserves to be stated plainly rather than discovered. If it does not, stable-linux.yml advertises an asset no client can use and every deb user is quietly stuck on the version they installed, with the update row in Settings telling them nothing useful.

This is checkable now without cutting anything: v2.0.2 and v2.0.3 are both published, so an installed 2.0.2 deb has a newer release to find.

Where

What done looks like

  • A report on an x64 Linux desktop: install the published v2.0.2 .deb, allow updates in Settings › About, and say what happened — whether 2.0.3 was offered, whether it downloaded, and whether the restart action installed it.
  • resources/package-type inside the installed app is named as present or absent, with its contents. That file is the whole mechanism, so it is the first thing to look at and the cheapest half of the answer.
  • The doc's table cell states the answer rather than a likelihood, and the Known gaps line is gone.
  • Your environment is in the issue: distribution and version, and whether this was a real desktop session or a container. The answer may not be the same everywhere, and the next reader needs to know what was tested.
  • If it does update in a way that leaves the package manager's database stale, say so in the doc. Whether that needs fixing is a separate issue, not this one.

What not to change

Do not change publish.channel or allowPrerelease to make testing easier. The channel names are the only thing keeping 2.x manifests away from the legacy 0.0.x clients, and updater.ts records that dropping allowPrerelease changes behaviour for shipped clients and has to ship on its own.

How to verify

This one is answered by observation, so the report is the deliverable — attach the app's own session log from the update attempt. There is no existing test for it, and the honest thing is not to invent one against a released binary. If the answer turns out to need a code or configuration change, that change is TDD like any other: write its failing test first, in surfsense_local/electron/src/main/updater.test.ts, which already drives the updater.

python scripts/check_docs.py          # from the repo root, for the doc edit
cd surfsense_local/electron && pnpm test

Before you start

Read CONTRIBUTING.md, the updates doc and ADR 0020. Open your PR against dev, not main. Comment here to claim this, and say which distribution you can test on.

Lingua principale
Python
Stelle
16.3k
Fork
1.6k
Merge medio
9h 15m
PR unite (30g)
254

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MODSetter/SurfSense

Tutte le issue di MODSetter/SurfSense

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.