Cómo actualicé Mailman a la versión 2.1.33 en pkgsrc

La versión actual (mayo 2020) de Mailman para las zonas nativas SmartOS es la versión 2.1.29, pero tiene problemas de seguridad y los desarrolladores han publicado la versión 2.1.33. Mailman es un programa fácil de actualizar a mano (una vez que ya lo tienes instalado y configurado), pero viendo que en pkgsrc (la distribución de paquetes que usa SmartOS para sus zonas nativas) no se estaba actualizando el paquete de software, decidí que era la oportunidad perfecta para echar una mano.

Este artículo describe los pasos detallados que he seguido para proponer una actualización de Mailman en pkgsrc. Es mi primer intento de colaborar con esa comunidad y el flujo de trabajo que documento aquí seguramente ni es el mejor, ni el definitivo. Básicamente, estoy documentando esto para mí mismo, porque prefiero depender de mi memoria lo mínimo posible en cosas que hago de forma esporádica.

Nota

En lo que sigue, cuando indico un acceso SSH a pkgsrc, me refiero a una conexión a una zona nativa SmartOS de mis servidores con la imagen pkgsrc distribuída por ellos.

Antecedentes

  • pkgsrc utiliza el venerable CVS como sistema de control de versiones. Hay espejos exportando el repositorio en otras tecnologías. Personalmente, prefiero usar Mercurial.

  • La gente de pkgsrc es muy flexible y puedes utilizar infinidad de flujos de trabajo diferentes. Esto es muy bueno a la larga, pero para un novato resulta complicado elegir la "mejor" opción. Por eso digo que el flujo de trabajo que he utilizado en este caso posiblemente no sea ni el mejor, ni el definitivo.

  • Tras un intercambio de emails largo y apasionado, pedí y se me concedió acceso al repositorio WIP (work in progress) de pkgsrc. Lamentablemente, ese repositorio usa Git. Insisto en que yo prefiero usar Mercurial.

  • A la hora de clonar y utilizar repositorios, no necesito la historia completa ni todos los directorios del proyecto en mi disco duro. De hecho, es de esperar que el trabajo sea corto y que preservar su historia resulte irrelevante.

  • SmartOS distribuye una zona nativa con un repositorio pkgsrc listo para ser utilizado. La idea es poder utilizarlo para compilar paquetes personalizados, si es necesario. Yo lo utilizaré como zona de trabajo.

    Por ejemplo, en mi caso:

    [root@xXx ~]# imgadm list | grep -i pkg
51bc0e6a-1d8a-11e9-85da-6f79abb24866  pkgbuild        18.4.0    smartos  zone-dataset  2019-01-21
d001d2b4-3157-11ea-832d-df421d070030  pkgbuild        19.4.0    smartos  zone-dataset  2020-01-07
148e347e-74e0-11ea-ae22-3750f64c3c22  pkgbuild        20.1.0    smartos  zone-dataset  2020-04-02

    No voy a entrar aquí en cómo se crea y administra una zona nativa SmartOS. Doy por hecho que ya la tienes funcionando.

El proceso

Probar a crear el paquete de software actual

El primer paso sería ver cuál es el estado del paquete actual. En particular, si podemos compilarlo sin problemas, si los parches se aplican correctamente, etc.

Veamos:

jcea@jcea:~$ ssh pkgsrc
   __        .                   .
 _|  |_      | .-. .  . .-. :--. |-
|_    _|     ;|   ||  |(.-' |  | |
  |__|   `--'  `-' `;-| `-' '  ' `-'
                   /  ; Instance (pkgbuild 19.4.0)
                   `-'  https://docs.joyent.com/images/smartos/pkgbuild

[root@PkgSrc ~]# run-sandbox 2019Q4-x86_64
Creating /data/chroot/dev-2019Q4-x86_64...done.
Unpacking bootstrap-2019Q4-x86_64 into /data/chroot/dev-2019Q4-x86_64...done.
Setting up environment...done.
Installing additional tools packages...done.
Logging in.  WARNING: On logout the sandbox will be destroyed.
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-<~>--
->

En primer lugar nos conectamos a la zona pkgsrc de nuestro SmartOS y creamos un entorno de experimentación. La primera vez que haces esto, el proceso puede llevar varios minutos al tener que descargar e instalar muchos paquetes de software. En el futuro (mientras no reprovisionemos la zona SmartOS) la tarea será mucho más rápida porque los paquetes de software descargados inicialmente son inmutables y se conservan en caché.

Es interesante ver que todo lo que hagamos se guarda en un entorno virtual que podemos reconstruir siempre que queramos.

Intentemos recrear el paquete Mailman actual:

--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-<~>--
-> cd /data/pkgsrc/mail/mailman/
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> bmake package
[...]
=> Fetching mailman-2.1.29.tgz
[...]
=> Verifying /data/pkgsrc/mail/mailman/patches/patch-ah
=> Applying pkgsrc patch /data/pkgsrc/mail/mailman/patches/patch-ah
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-ah,v 1.3 2009/06/03 06:58:55 adam Exp $
|
|--- Mailman/htmlformat.py.orig 2009-02-23 22:23:35.000000000 +0100
|+++ Mailman/htmlformat.py
--------------------------
Patching file Mailman/htmlformat.py using Plan A...
Hunk #1 succeeded at 647 (offset 36 lines).
Hunk #2 succeeded at 667 (offset 36 lines).
done
[...]
===> Building binary package for mailman-2.1.29nb1
=> Creating binary package /data/packages/SmartOS/2019Q4/x86_64/All/mailman-2.1.29nb1.tgz
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
->

Vemos que el proceso tiene éxito y vemos también que pkgsrc tiene algunos parches propios para Mailman y que estos no se aplican exactamente, sino que es necesario cierto fuzzing. Esto es porque los parches originales son de... ¡2009! Ponerlos al día o no fue tema de discusiones durante días. El equilibrio entre una compilación limpia y el reducir el churn en el repositorio.

Actualización a Mailman 2.1.33

Una vez que vemos que la compilación de la versión actual es fácil e indolora, vamos a proceder a actualizar Mailman a la version 2.1.33.

Como dije al principio, quiero hacer el desarrollo en Mercurial, aunque en este caso el trabajo sea pequeño y me esté complicando la vida por pura cabezonería:

--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> bmake clean
===> Cleaning for mailman-2.1.29nb1
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> pkg_add mercurial
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> hg init .
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> printf "[ui]\nusername = Jesus Cea <jcea@jcea.es>\nmerge=internal:merge\n" >.hg/hgrc
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> hg add
adding DESCR
adding MESSAGE
adding Makefile
adding PLIST
adding distinfo
adding files/DEINSTALL
adding files/INSTALL
adding files/mailman.conf.dist
adding files/mailman.sh
adding files/smf/manifest.xml
adding patches/patch-aa
adding patches/patch-ab
adding patches/patch-ad
adding patches/patch-ae
adding patches/patch-af
adding patches/patch-ag
adding patches/patch-ah
adding patches/patch-ai
adding patches/patch-configure
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> hg comm -m "Punto inicial"

La primero que hacemos es instalar y configurar Mercurial dentro del entorno virtual. Es de señalar que este repositorio Mercurial sobrevivirá si recreamos el entorno virtual (por supuesto, no un reprovisionamiento de la zona SmartOS, que arrasa con todo, como debe ser).

Luego guardamos el estado actual del paquete Mailman por si necesitamos volver atrás o para hacer un diff entre el estado inicial y el estado final.

A continuación editamos el fichero Makefile para cambiar la fuente del paquete de Mailman 2.1.29 a 2.1.33:

[.. editamos Makefile ..]

--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> hg diff
diff -r 3e8ab43ad414 Makefile
--- a/Makefile  Mon May 11 17:51:00 2020 +0000
+++ b/Makefile  Mon May 11 17:57:35 2020 +0000
@@ -1,10 +1,10 @@
 # $NetBSD: Makefile,v 1.89 2019/11/02 16:25:22 rillig Exp $

-DISTNAME=      mailman-2.1.29
-PKGNAME=       mailman-2.1.29
-PKGREVISION=   1
+DISTNAME=      mailman-2.1.33
+PKGNAME=       mailman-2.1.33
+PKGREVISION=   0
 CATEGORIES=    mail www
-MASTER_SITES=  https://launchpad.net/mailman/2.1/2.1.29/+download/
+MASTER_SITES=  https://launchpad.net/mailman/2.1/2.1.33/+download/
 EXTRACT_SUFX=  .tgz

 MAINTAINER=    pkgsrc-users@NetBSD.org
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
->

pkgsrc tiene controles estrictos de integridad, así que necesitaremos actualizar las verificaciones:

-> bmake
=> Bootstrap dependency digest>=20010302: found digest-20190127
=> Fetching mailman-2.1.33.tgz
[...]
checksum: No checksum recorded for mailman-2.1.33.tgz
ERROR: Make sure the Makefile and checksum file
(/data/pkgsrc/mail/mailman/distinfo)
ERROR: are up to date.  If you want to override this check, type
ERROR: "/opt/local/bin/bmake NO_CHECKSUM=yes [other args]".
*** Error code 1

Stop.
bmake: stopped in /data/pkgsrc/mail/mailman
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> bmake distinfo
=> Bootstrap dependency digest>=20010302: found digest-20190127
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> bmake
[...]
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> hg comm -m "Makefile y distinfo"
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
->

El bmake distinfo recrea las verificaciones para la nueva versión de Mailman. Al final guardamos en Mercurial el paso actual, para poder volver atrás si es necesario.

Advertencia

Lo ideal sería comprobar la firma digital del fichero en otra máquina y luego comprobar que las verificaciones almacenadas en pkgsrc coinciden. En este artículo obvio este paso.

Probemos ahora a generar el paquete:

--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> bmake package
[...]
=> Checking file-check results for mailman-2.1.33
ERROR: ************************************************************
ERROR: The following files are in /home/pbulk/build/mail/mailman/work/.destdir/opt/local but not in the PLIST:
ERROR:         /home/pbulk/build/mail/mailman/work/.destdir/opt/local/lib/mailman/tests/bounces/dsn_18.txt
ERROR:         /home/pbulk/build/mail/mailman/work/.destdir/opt/local/lib/mailman/tests/bounces/yahoo_12.txt
*** Error code 1

Stop.
bmake[1]: stopped in /data/pkgsrc/mail/mailman
*** Error code 1

Stop.
bmake: stopped in /data/pkgsrc/mail/mailman
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
->

Lo que ocurre aquí es que Mailman 2.1.33 incluye dos ficheros más a instalar que el viejo 2.1.29. Por suerte, pkgsrc permite actualizar el fichero PLIST automáticamente:

--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> bmake print-PLIST >PLIST
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> hg diff
diff -r 695b13edbe2c PLIST
--- a/PLIST     Mon May 11 18:15:48 2020 +0000
+++ b/PLIST     Mon May 11 18:25:07 2020 +0000
@@ -1,4 +1,4 @@
-@comment $NetBSD: PLIST,v 1.28 2019/03/25 01:52:02 jklos Exp $
+@comment $NetBSD$
 lib/mailman/Mailman/Archiver/Archiver.py
 lib/mailman/Mailman/Archiver/Archiver.pyc
 lib/mailman/Mailman/Archiver/HyperArch.py
@@ -341,17 +341,17 @@
 lib/mailman/bin/update
 lib/mailman/bin/version
 lib/mailman/bin/withlist
-lib/mailman/cgi-bin/admin${MAILMAN_CGIEXT}
-lib/mailman/cgi-bin/admindb${MAILMAN_CGIEXT}
-lib/mailman/cgi-bin/confirm${MAILMAN_CGIEXT}
-lib/mailman/cgi-bin/create${MAILMAN_CGIEXT}
-lib/mailman/cgi-bin/edithtml${MAILMAN_CGIEXT}
-lib/mailman/cgi-bin/listinfo${MAILMAN_CGIEXT}
-lib/mailman/cgi-bin/options${MAILMAN_CGIEXT}
-lib/mailman/cgi-bin/private${MAILMAN_CGIEXT}
-lib/mailman/cgi-bin/rmlist${MAILMAN_CGIEXT}
-lib/mailman/cgi-bin/roster${MAILMAN_CGIEXT}
-lib/mailman/cgi-bin/subscribe${MAILMAN_CGIEXT}
+lib/mailman/cgi-bin/admin
+lib/mailman/cgi-bin/admindb
+lib/mailman/cgi-bin/confirm
+lib/mailman/cgi-bin/create
+lib/mailman/cgi-bin/edithtml
+lib/mailman/cgi-bin/listinfo
+lib/mailman/cgi-bin/options
+lib/mailman/cgi-bin/private
+lib/mailman/cgi-bin/rmlist
+lib/mailman/cgi-bin/roster
+lib/mailman/cgi-bin/subscribe
 lib/mailman/cron/bumpdigests
 lib/mailman/cron/checkdbs
 lib/mailman/cron/cull_bad_shunt
@@ -2164,6 +2164,7 @@
 lib/mailman/tests/bounces/dsn_15.txt
 lib/mailman/tests/bounces/dsn_16.txt
 lib/mailman/tests/bounces/dsn_17.txt
+lib/mailman/tests/bounces/dsn_18.txt
 lib/mailman/tests/bounces/dumbass_01.txt
 lib/mailman/tests/bounces/exim_01.txt
 lib/mailman/tests/bounces/groupwise_01.txt
@@ -2250,6 +2251,7 @@
 lib/mailman/tests/bounces/yahoo_09.txt
 lib/mailman/tests/bounces/yahoo_10.txt
 lib/mailman/tests/bounces/yahoo_11.txt
+lib/mailman/tests/bounces/yahoo_12.txt
 lib/mailman/tests/bounces/yale_01.txt
 lib/mailman/tests/fblast.py
 lib/mailman/tests/msgs/bad_01.txt
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
->

Vemos que con la generación automática vamos a perder el sufijo {MAILMAN_CGIEXT}, que entiendo que es importante. Por ello, recupero la versión anterior de PLIST y edito el fichero a mano para añadir los dos ficheros nuevos. ¡Bendito sistema de control de versiones!

--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> hg revert PLIST ; rm PLIST.orig

[.. Editamos el fichero PLIST ..]

--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> hg diff
diff -r 695b13edbe2c PLIST
--- a/PLIST     Mon May 11 18:15:48 2020 +0000
+++ b/PLIST     Mon May 11 18:29:01 2020 +0000
@@ -2164,6 +2164,7 @@
 lib/mailman/tests/bounces/dsn_15.txt
 lib/mailman/tests/bounces/dsn_16.txt
 lib/mailman/tests/bounces/dsn_17.txt
+lib/mailman/tests/bounces/dsn_18.txt
 lib/mailman/tests/bounces/dumbass_01.txt
 lib/mailman/tests/bounces/exim_01.txt
 lib/mailman/tests/bounces/groupwise_01.txt
@@ -2250,6 +2251,7 @@
 lib/mailman/tests/bounces/yahoo_09.txt
 lib/mailman/tests/bounces/yahoo_10.txt
 lib/mailman/tests/bounces/yahoo_11.txt
+lib/mailman/tests/bounces/yahoo_12.txt
 lib/mailman/tests/bounces/yale_01.txt
 lib/mailman/tests/fblast.py
 lib/mailman/tests/msgs/bad_01.txt
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> hg comm -m "PLIST"
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
->

Creemos el paquete, a ver si ya hemos terminado:

--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> bmake clean
===> Cleaning for mailman-2.1.33
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> bmake package
[...]
===> Building binary package for mailman-2.1.33
=> Creating binary package /data/packages/SmartOS/2019Q4/x86_64/All/mailman-2.1.33.tgz
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> hg st
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
->

Parece que todo ha ido bien y no necesitamos actualizar el repositorio Mercurial y volver a intentarlo. Pkgsrc nos ha dejado el paquete listo en /data/packages/SmartOS/2019Q4/x86_64/All/mailman-2.1.33.tgz.

Probar el paquete de software

Uso Mailman en producción en una zona nativa SmartOS. Quiero reemplazar el paquete de software actual de Mailman (versión 2.1.29) con la versión que acabo de generar (2.1.33).

Si hay problemas, podemos volver a la versión anterior con dos comandos: desinstalar el paquete moderno e instalar la versión del sistema.

  1. Transferimos el paquete de software de la zona SmartOS pkgsrc a la zona donde tenemos Mailman en producción.

    Podemos hacerlo copiándolo a través de la zona global SmartOS, o descargándolo en nuestro portátil y volviéndolo a subir a la zona correcta.

  2. En la zona correspondiente, intentamos instalar la versión nueva:

    [root@Web /home]# pkg_add mailman-2.1.33.tgz
pkg_add: No valid signature found, rejected
pkg_add: 1 package addition failed

    La versión SmartOS de pkgsrc requiere firmas digitales del fabricante que nosotros, obviamente, no podemos suplantar. Podríamos firmar nuestros paquetes y meter nuestra clave pública en la configuración del sistema, pero lo fácil es desactivar temporalmente la verificación de firmas.

  3. Desactivamos la verificación de firmas digitales:

    [root@Web /home]# cat /opt/local/etc/pkg_install.conf
GPG_KEYRING_PKGVULN=/opt/local/share/gnupg/pkgsrc-security.gpg
GPG_KEYRING_VERIFY=/opt/local/etc/gnupg/pkgsrc.gpg
PKG_PATH=https://pkgsrc.joyent.com/packages/SmartOS/2019Q4/x86_64/All
#VERIFIED_INSTALLATION=always

    Aquí hemos desactivado la verificación temporalmente, como puede verse en la última línea.

  4. Volvemos a intentar instalar el paquete:

    [root@Web /home]# pkg_add mailman-2.1.33.tgz
pkg_add: A different version of mailman-2.1.33 is already
installed: mailman-2.1.29nb1
pkg_add: 1 package addition failed
[root@Web /home]# pkg_add -u mailman-2.1.33.tgz
[...]
[root@Web /home]#

    Tenemos ya Mailman instalado, así que tenemos que indicarle a pkg_add que haga una actualización.

  5. Una vez que instalamos el paquete nuevo, reactivamos la verificación de firmas digitales:

    [root@Web /home]# cat /opt/local/etc/pkg_install.conf
GPG_KEYRING_PKGVULN=/opt/local/share/gnupg/pkgsrc-security.gpg
GPG_KEYRING_VERIFY=/opt/local/etc/gnupg/pkgsrc.gpg
PKG_PATH=https://pkgsrc.joyent.com/packages/SmartOS/2019Q4/x86_64/All
VERIFIED_INSTALLATION=always

    Hemos vuelto a activar la última línea.

Ahora solo queda probar a fondo el paquete durante unos días.

Subir la propuesta de cambio a WIP

Cuando estamos seguros de que el nuevo paquete de software funciona correctamente, nos proponemos enviarlo a repositorio WIP de pkgsrc para consideración de la comunidad. [1]

[1] Este flujo de trabajo es uno de los muchos posibles. Aún me falta experiencia con pkgsrc para refinar el proceso.

  1. Volvemos a la zona nativa SmartOS pkgsrc y añadimos un fichero COMMIT_MSG. Este fichero contiene el mensaje a meter en el log cuando alguien con permisos promocione la actualización del paquete del repositorio WIP al repositorio pkgsrc oficial.

    En este caso transcribo tal cual el listado de cambios de la versión 2.1.29 a la 2.1.33 de Mailman:

    --<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> cat COMMIT_MSG
2.1.33 (07-May-2020)

  Security

    - A content injection vulnerability via the private login page has been
      fixed.  (LP: #1877379)

2.1.32 (05-May-2020)

  i18n

    Fixed a typo in the Spanish translation and uptated mailman.pot and
    the message catalog for 2.1.31 security fix.

2.1.31 (05-May-2020)

  Security

    - A content injection vulnerability via the options login page has been
      discovered and reported by Vishal Singh. This is fixed.  (LP: #1873722)

  i18n

    - The Spanish translation has been updated by Omar Walid Llorente.

  Bug Fixes and other patches

    - Bounce recognition for a non-compliant Yahoo format is added.

    - Archiving workaround for non-ascii in string.lowercase in some Python
      packages is added.

2.1.30 (13-Apr-2020)

  New Features

    - Thanks to Jim Popovitch, there is now a dmarc_moderation_addresses
      list setting that can be used to apply dmarc_moderation_action to mail
      From: addresses listed or matching listed regexps.  This can be used
      to modify mail to addresses that don't accept external mail From:
      themselves.

    - There is a new MAX_LISTNAME_LENGTH setting.  The fix for LP: #1780874
      obtains a list of the names of all the all the lists in the installation
      in order to determine the maximum length of a legitimate list name.  It
      does this on every web access and on sites with a very large number of
      lists, this can have performance implications.  See the description in
      Defaults.py for more information.

    - Thanks to Ralf Jung there is now the ability to add text based captchas
      (aka textchas) to the listinfo subscribe form.  See the documentation
      for the new CAPTCHA setting in Defaults.py for how to enable this.  Also
      note that if you have custom listinfo.html templates, you will have to
      add a <mm-captcha-ui> tag to those templates to make this work.  This
      feature can be used in combination with or instead of the Google
      reCAPTCHA feature added in 2.1.26.

    - Thanks to Ralf Hildebrandt the web admin Membership Management section
      now has a feature to sync the list's membership with a list of email
      addresses as with the bin/sync_members command.

    - There is a new drop_cc list attribute set from DEFAULT_DROP_CC.  This
      controls the dropping of addresses from the Cc: header in delivered
      messages by the duplicate avoidance process.  (LP: #1845751)

    - There is a new REFUSE_SECOND_PENDING mm_cfg.py setting that will cause
      a second request to subscribe to a list when there is already a pending
      confirmation for that user.  This can be set to Yes to prevent
      mailbombing of a third party by repeatedly posting the subscribe form.
      (LP: #1859104)

  i18n

    - The Japanese translation has been updated by Yasuhito FUTATSUKI.

    - The German translation has been updated by Ludwig Reiter.

    - The Spanish translation has been updated by Omar Walid Llorente.

    - The Brazilian Portugese translation has been updated by Emerson de Mello.

  Bug Fixes and other patches

    - Fixed the confirm CGI to catch a rare TypeError on simultaneous
      confirmations of the same token.  (LP: #1785854)

    - Scrubbed application/octet-stream MIME parts will now be given a
      .bin extension instead of .obj.

    - Added bounce recognition for a non-compliant opensmtpd DSN with
      Action: error.  (LP: #1805137)

    - Corrected and augmented some security log messages.  (LP: #1810098)

    - Implemented use of QRUNNER_SLEEP_TIME for bin/qrunner --runner=All.
      (LP: #1818205)

    - Leading/trailing spaces in provided email addresses for login to private
      archives and the user options page are now ignored.  (LP: #1818872)

    - Fixed the spelling of the --no-restart option for mailmanctl.

    - Fixed an issue where certain combinations of charset and invalid
      characters in a list's description could produce a List-ID header
      without angle brackets.  (LP: #1831321)

    - With the Postfix MTA and virtual domains, mappings for the site list
      -bounces and -request addresses in each virtual domain are now added
      to data/virtual-mailman (-owner was done in 2.1.24).  (LP: #1831777)

    - The paths.py module now extends sys.path with the result of
      site.getsitepackages() if available.  (LP: #1838866)

    - A bug causing a UnicodeDecodeError in preparing to send the confirmation
      request message to a new subscriber has been fixed.  (LP: #1851442)

    - The SimpleMatch heuristic bounce recognizer has been improved to not
      return most invalid email addresses.  (LP: #1859011)
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> hg add COMMIT_MSG
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
-> hg comm -m "Commit message"
--<root@PkgSrc>-(/data/chroot/dev-2019Q4-x86_64)-</data/pkgsrc/mail/mailman>--
->

  2. Clonamos el repositorio WIP en nuestro portátil:

    jcea@jcea:/tmp$ git clone --depth 1 ssh://jcea@wip.pkgsrc.org/pkgsrc-wip.git/ wip
Cloning into 'wip'...
remote: Enumerating objects: 37946, done.
remote: Counting objects: 100% (37946/37946), done.
remote: Compressing objects: 100% (31457/31457), done.
remote: Total 37946 (delta 5106), reused 29862 (delta 4800)
Receiving objects: 100% (37946/37946), 17.64 MiB | 2.62 MiB/s,
done.
Resolving deltas: 100% (5106/5106), done.
Checking connectivity... done.
Checking out files: 100% (31362/31362), done.

    No necesitamos la historia completa del proceso, así que nos limitamos a lo mínimo con el parámetro depth.

    Nota

    Obsérvese que clono el repositorio usando SSH. Esto identifica mi usuario y me permitirá hacer push cuando haya terminado.

    Nota

    La zona nativa SmartOS pkgsrc incluye una copia del repositorio WIP, en este caso limitado a la rama 2019Q4. Tengo que experimentar cómo sacarle partido.

  3. Copiamos nuestro trabajo en WIP:

    jcea@jcea:/tmp$ cd wip
jcea@jcea:/tmp/wip$ rsync -a --exclude ".hg" pkgsrc:/data/pkgsrc/mail/mailman .
jcea@jcea:/tmp/wip$ git add mailman/
jcea@jcea:/tmp/wip$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   mailman/COMMIT_MSG
        new file:   mailman/DESCR
        new file:   mailman/MESSAGE
        new file:   mailman/Makefile
        new file:   mailman/PLIST
        new file:   mailman/distinfo
        new file:   mailman/files/DEINSTALL
        new file:   mailman/files/INSTALL
        new file:   mailman/files/mailman.conf.dist
        new file:   mailman/files/mailman.sh
        new file:   mailman/files/smf/manifest.xml
        new file:   mailman/patches/patch-aa
        new file:   mailman/patches/patch-ab
        new file:   mailman/patches/patch-ad
        new file:   mailman/patches/patch-ae
        new file:   mailman/patches/patch-af
        new file:   mailman/patches/patch-ag
        new file:   mailman/patches/patch-ah
        new file:   mailman/patches/patch-ai
        new file:   mailman/patches/patch-configure

  4. Todo tiene buena pinta. Grabamos esta versión y la mandamos al servidor:

    jcea@jcea:/tmp/wip$ git commit -m "Mailman 2.1.33"
[master 44da1a8] Mailman 2.1.33
 20 files changed, 2990 insertions(+)
 create mode 100644 mailman/COMMIT_MSG
 create mode 100644 mailman/DESCR
 create mode 100644 mailman/MESSAGE
 create mode 100644 mailman/Makefile
 create mode 100644 mailman/PLIST
 create mode 100644 mailman/distinfo
 create mode 100644 mailman/files/DEINSTALL
 create mode 100644 mailman/files/INSTALL
 create mode 100644 mailman/files/mailman.conf.dist
 create mode 100644 mailman/files/mailman.sh
 create mode 100644 mailman/files/smf/manifest.xml
 create mode 100644 mailman/patches/patch-aa
 create mode 100644 mailman/patches/patch-ab
 create mode 100644 mailman/patches/patch-ad
 create mode 100644 mailman/patches/patch-ae
 create mode 100644 mailman/patches/patch-af
 create mode 100644 mailman/patches/patch-ag
 create mode 100644 mailman/patches/patch-ah
 create mode 100644 mailman/patches/patch-ai
 create mode 100644 mailman/patches/patch-configure

jcea@jcea:/tmp/wip$ git push
Counting objects: 26, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (25/25), done.
Writing objects: 100% (26/26), 20.80 KiB | 0 bytes/s, done.
Total 26 (delta 1), reused 0 (delta 0)
To ssh://jcea@wip.pkgsrc.org/pkgsrc-wip.git/
   8d99bee..44da1a8  master -> master

  5. Ahora enviamos un correo electrónico a la lista de correo pkgsrc-users@netBSD.org pidiendo una revisión de la actualización y la inclusión en la versión oficial de pkgsrc. En el proceso se me pueden pedir cambios y mejoras.

Advertencia

Vuelvo a insistir: Este flujo de trabajo puede variar en el futuro, en función de mi experiencia. No lo estoy recomendando como el único o el mejor.