Re: building asterisk and xmlstarlet

[jnemeth%CornerstoneService.ca@localhost (John Nemeth)]

On Jul 7, 18:20, Greg Troxel wrote:
} Rob Whitlock <rwhitlock22%gmail.com@localhost> writes:
} >> On Jul 5, 2025, at 4:01 PM, Greg Troxel <gdt%lexort.com@localhost> wrote:
} >> 
} >> I've been rebuilding for the branch, and found that asterisk19 would
} >> fail:
} >> 
} >>  => Creating installation directories
} >>  menuselect/menuselect --check-deps menuselect.makeopts
} >>  menuselect/menuselect --check-deps menuselect.makeopts /tmp/work/comms/asterisk19/work/asterisk-19.8.1/pkgsrc.makeopts 
} >>  Installing modules from channels...
} >>  sh: 6: Syntax error: Bad substitution
} >>  make[1]: *** [/tmp/work/comms/asterisk19/work/asterisk-19.8.1/Makefile.moddir_rules:110: install] Error 2
} >>  gmake: *** [Makefile:580: channels-install] Error 2
} >>  *** Error code 2
} >
} > I was unable to reproduce this error but the location of the error
} > is the same as the one I reported in pkg/59478 for asterisk22.
} > I found a way to get it to build here:
} >
} > https://mail-index.netbsd.org/pkgsrc-bugs/2025/06/24/msg074140.html
} >
} > Does applying those changes to the asterisk19 package
} > allow the build to proceed? If so, it might shed some light
} > on what is going wrong.

     asterisk19 went EOL two years ago, so I don't spend much time
on it.

} With the following diff (taken from your PR submission), asterisk19
} builds with or without xmlstarlet installed, and seems to produce the
} same bits.

     If it ends up with the same bits, then it is likely that
something wasteful is being done when xmlstarlet is installed.

} I conclude that the asterisk build expects bash, and while that's buggy
} (period, and plus it isn't documented) , they probably won't see it that
} way.

     Asterisk is very much focused on Linux.  I also found that
even really simple patches can take years to apply, so I stopped
bothering.  However, now that Asterisk is owned by Sangoma, that
might change.

     As for bashisms, I generally patch them out whenever possible.
However, given that the package is EOL and ripe for removing, I'm
inclined to accept quick hacks and move on.  For active packages,
I would want to take a closer look.

} I think we should commit the diff below, and apply it to all the
} versions.  That seems better than patches to turn off looking for xml to
} avoid the bug, and more robust against future issues.
} 
} I don't see any comments from John in the PR (assigned 24 June), but
} I'll give it another few days.
} 
}-- End of excerpt from Greg Troxel