Repository navigation
feat(linux): empaquetar y documentar un build local verificable #108
Description
Objetivo y motivo
Cerrar Linux portability con un paquete local y evidencia funcional real en la matriz acordada, sin prometer distribución pública.
Alcance
- Configurar el formato de paquete Linux local decidido en #105, preservando instaladores NSIS/MSI y configuración Windows.
- Probar instalación local, primer arranque, persistencia, sesión/secretos/login, widget, bandeja y recuperación de errores en el entorno aprobado.
- Actualizar README.md, README.es.md y CONTRIBUTING.md con prerequisitos Linux, comandos de build, límites de X11/Wayland y guía de diagnóstico; conservar instrucciones Windows y coordinación macOS.
- Excluye firma, notarización, artefactos públicos, CI/release Linux, updater Linux publicado, prometer todas las distribuciones y cambios de visibilidad.
Dependencias
#105 baseline y contrato, #106 sesiones/login y #107 escritorio integrados y aceptados. No depende de integrar el port macOS ni WSL.
Criterios de aceptación
- Build y paquete local del formato acordado generados e instalados en Linux real; rutas/iconos/configuración y primer arranque comprobados.
- Prueba end-to-end de configuración, Secret Service, CLI disponible, bandeja/widget y recuperación sin credenciales expuestas; límites por proveedor y compositor explícitos.
- Documentación ES/EN y CONTRIBUTING coherentes con la matriz comprobada y con Windows vigente; no afirmar soporte general ni release.
-
npm test,npm run typecheck,npm run build,cargo testensrc-tauri, build nativo y regresión Windows pertinentes, con comandos, exit codes y evidencia; fallos abiertos documentados, no ocultos.
Orientación
src-tauri/tauri.conf.json, configuración de bundle, README.md, README.es.md, CONTRIBUTING.md. Reusar artefactos/configuración donde sea compatible; no activar workflow público ni firma al validar el paquete local.
Comprobaciones y ODD
Observar resultados de #105–#107 y formato elegido → decidir criterios de empaquetado/cierre sin ampliar matriz → desarrollar paquete y docs con comprobaciones estructurales/funcionales → verificar instalación y funcionamiento Linux reales, suites aplicables y regresión Windows. Salida: aceptación de las cuatro unidades y evidencia reproducible; una PR no equivale a integración ni una build local a release.
Coordinación y entrega
Planificada y bloqueada por #105/#106/#107. Sin assignee inicial; revalidar responsables/PR/dependencias antes de empezar. Mantener #66 como primer objetivo nuevo recomendado; tests y docs con cada unidad. Commit, PR, merge, release y cierre requieren autorización/política aparte.
Activity
feat(linux): port egdev6#106 CLI login + secrets + keyring hint (egde…
chore(linux): infra local lista para revisión de egdev6#108 (parked, …
ci: retirar linux-ci redundante y roto (no AppImage sin objetivos/mon…
ci(linux): consolidar en un único Linux CI (linux-ci.yml) en el set de …
sosan commentedon Oct 17, 2026
Preparación de PR de packaging (sin autoasignación) — requiere tu decisión
Rama
sosan:chore-linux-build-local-108(fork privado, empujada, commit4ffd147): set completo de empaquetado local —targets deb/appimage entauri.conf.json, Makefile,.testcontainer/(build-verify deb/AppImage),devcontainer y
.dockerignore— más una propuesta de extensión dealcance: mantener un único workflow Linux manual (
linux-ci.yml) en vezdel par build-linux/test-linux, sin trigger por tag.
La rama está parked desde el 16/10 y la PR solo se abrirá cuando nos
indiques que procede (tras #105→#107 integradas). Dos preguntas para
aprobar el alcance antes de abrir la PR:
linux-ci.yml(manual por ref,subida de artefactos para verificación en escritorio) y descartar
build-linux.yml/test-linux.yml? Si quieres releases por tag como parte
del set, proponemos añadir el trigger dentro del mismo fichero.
workflow), sin publicación en releases?
Evidencia técnica disponible:
38961455193: tests Rust 171/0 + frontend en verde.38981116643: deb + AppImage empaquetados, AppImage viva 60 s víaFUSE y ambos verificados en contenedor limpio (rama unión test-only
ci/linux-union-107; el arranque del AppImage requiere el fix delpánico de
taoque llega con feat(linux): hacer funcional el escritorio y widget nativos #107).≥6.12 (Ubuntu 26.04/kernel 6.17 falla 'Can't open squashfs'); en 22.04
monta sin problema.
docs(linux): correcciones del review de baseline en egdev6#114
docs(linux): baseline, contrato y referencias Linux (#105) (#114)
chore(linux): packaging local deb/appimage + Linux CI único (#108) (#127
feat(linux): port #106 CLI login + secrets + keyring hint (#106) (#122)
docs(linux): refresh CONTRIBUTING + §5 to match merged #127 and #122 (#…
feat(linux): detección backend de compositor y superficies del escrit…
docs(linux): W0 Wayland evidence — workflow + validated matrix (issue #…
egdev6 commentedon Nov 13, 2026
@sosan perdón por la demora en responder. Repasando el estado actual, la rama
chore-linux-build-local-108queda superada pormain: lo que proponía ya entró por otras PRs (#176, #203 y siguientes).debyappimageentauri.conf.json,.testcontainer/(verify deb/AppImage),.devcontainer/,Makefiley.dockerignoreya están enmain, en una versión más evolucionada.linux-ci.ymles el workflow Linux único y manual por ref, con tier vivo bajo xvfb y gate de bundles; ademáslinux-pr-ci.ymlcorre tests y build en cada PR.main, la rama solo resta código, así que no hace falta abrir la PR. Se puede borrar cuando quieras.Sobre tus dos preguntas, quedan respondidas por lo integrado:
linux-ci.ymlmanual, sin trigger por tag.La instalación local ya está probada (
.debinstalado y arrancando en host, verdocs/build-linux.md§2 y §4). Para cerrar #108 queda:Si te interesa llevar ese cierre, adelante. Gracias por todo el trabajo de base, se nota en cómo quedó la infraestructura.