Hace unas semanas conseguí que mi primer commit fuera aceptado en el proyecto RTPEngine. Te cuento cómo fue el proceso y qué problema resolvía.

El Problema

Mientras trabajaba en configurar RTPEngine en AlmaLinux 9.7, me encontré con que el módulo kernel nft_rtpengine no compilaba. El error indicaba que la función nft_expr_dump esperaba un parámetro reset que el código no estaba proporcionando.

Lo curioso del caso es que este parámetro se introdujo en el kernel 6.2.0, pero yo estaba usando el kernel 5.14.0-611.11.1.el9_7.x86_64 de AlmaLinux 9. En teoría no debería tener esa característica. Era una situación confusa.

La Investigación con Claude

Aquí fue donde Claude (el asistente de IA de Anthropic) resultó clave. Le planteé el problema y, tras analizar el error de compilación, Claude identificó que la causa estaba en los backports de RHEL.

La explicación que me dio Claude: RHEL (y sus derivados como AlmaLinux y Rocky Linux) mantienen versiones de kernel estables (5.14 para RHEL 9), pero hacen backports selectivos de características y correcciones de versiones más nuevas.

Esto significa que el kernel 5.14 de AlmaLinux 9 incluye características que no existen en el kernel 5.14 vanilla. Específicamente, Red Hat hizo backport del parámetro reset en nft_expr_dump desde el kernel 6.2.0.

Claude no solo identificó la causa, sino que me proporcionó la solución exacta que necesitaba implementar.

La Solución

La corrección fue directa: extender la condición de compilación condicional existente para incluir los kernels RHEL 9.x:

#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,2,0) || \
    (LINUX_VERSION_CODE >= KERNEL_VERSION(5,14,0) && \
     defined(RHEL_RELEASE_CODE) && RHEL_RELEASE_CODE >= RHEL_RELEASE_VERSION(9,0))
    , bool reset
#endif

La lógica es clara:

• Si es kernel 6.2.0 o superior → incluye el parámetro reset
• O si es kernel 5.14 o superior Y tiene definido RHEL_RELEASE_CODE Y es RHEL 9.0 o superior → incluye el parámetro reset

Esto cubre toda la familia RHEL 9 (RHEL, AlmaLinux, Rocky Linux) sin romper nada más.

El Proceso

1. Identificación: Detecté el problema al intentar compilar en AlmaLinux 9.7
2. Diagnóstico con Claude: Claude identificó que la causa eran los backports de RHEL y me proporcionó la solución específica
3. Implementación: Apliqué el fix que Claude me sugirió
4. Testing: Validé la solución en mi sistema (AlmaLinux 9.7, kernel 5.14.0-611.11.1.el9_7.x86_64)
5. Contribución: Abrí el issue #2037 y el pull request #2038
6. Merge: El mantenedor rfuchs aceptó el commit

Lecciones Aprendidas

Sobre RHEL y Backports

• No asumas que un kernel 5.14 siempre se comporta igual. RHEL modifica su kernel base extensivamente
• Usa las macros RHEL_RELEASE_CODE y RHEL_RELEASE_VERSION para detectar versiones específicas de RHEL
• Esta situación afecta a toda la familia: RHEL, CentOS Stream, AlmaLinux, Rocky Linux, Oracle Linux

Sobre Contribuir a Open Source

• Un problema que te afecta probablemente afecta a otros
• La documentación clara es importante: incluí el sistema exacto donde probé (AlmaLinux 9.7, kernel específico)
• El proceso fue más simple de lo que esperaba: issue → PR → merge
• Usar herramientas de IA como Claude puede acelerar significativamente el diagnóstico de problemas complejos. Lo que podría haberme tomado horas o días de investigación, Claude lo identificó en minutos

Impacto

Este fix resuelve la compilación de nft_rtpengine para cualquiera usando RHEL 9 o sus derivados. Es un cambio pequeño pero necesario para que RTPEngine funcione correctamente en estas distribuciones enterprise, que son comunes en entornos de producción.

Recursos

• Commit: https://github.com/sipwise/rtpengine/commit/503c4aaffe492e658df597152ba7...
• Issue: https://github.com/sipwise/rtpengine/issues/2037
• Pull Request: https://github.com/sipwise/rtpengine/pull/2038
• Sistema probado: AlmaLinux 9.7, kernel 5.14.0-611.11.1.el9_7.x86_64

Identificador del commit: MT#55283