Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#17872 - makepkg with SVN depots that use self-signed certificates
Attached to Project:
Pacman
Opened by Pierre Chapuis (catwell) - Sunday, 17 January 2010, 13:01 GMT
Last edited by Allan McRae (Allan) - Tuesday, 29 January 2013, 00:24 GMT
Opened by Pierre Chapuis (catwell) - Sunday, 17 January 2010, 13:01 GMT
Last edited by Allan McRae (Allan) - Tuesday, 29 January 2013, 00:24 GMT
|
DetailsAs of now, makepkg will stop when determining the latest svn revision if the repository uses a self-signed certificate (for example https://bosshog.lbl.gov/repos/pyGsi). The packager can not fix this in the package because the command is hardcoded in makepkg.
The simplest way to change this would be to change this line in devel_check(): newpkgver=$(LC_ALL=C svn info $_svntrunk | sed -n 's/^Last Changed Rev: \([0-9]*\)$/\1/p') into: newpkgver=$(LC_ALL=C svn info --non-interactive --trust-server-cert $_svntrunk | sed -n 's/^Last Changed Rev: \([0-9]*\)$/\1/p') Another possibility would be to allow the packager to alter the way makepkg determines the SVN revision... |
This task depends upon
Closed by Allan McRae (Allan)
Tuesday, 29 January 2013, 00:24 GMT
Reason for closing: Fixed
Additional comments about closing: pkgver() function in 4.1 to determine package version
Tuesday, 29 January 2013, 00:24 GMT
Reason for closing: Fixed
Additional comments about closing: pkgver() function in 4.1 to determine package version
Comment by Dan McGee (toofishes) -
Wednesday, 20 January 2010, 04:43 GMT
We have a handful of issues related to VCS package versions at the moment, so we might revisit this issue on a grander scale in the future. However, I don't think adding the two options you gave would be a bad idea for the short-term. Allan?
Comment by jeff (jeff) -
Saturday, 13 March 2010, 06:00 GMT
Even for something as seemingly innocuous as getting a revision number, I'm not sure if explicit trust should ever be hardcoded without user consent. I'm not sure about the subversion internals when it comes to certificates, but can it save a users preference for trust after asking the first time like so many other pieces of software can?
Comment by Pierre Chapuis (catwell) -
Tuesday, 16 March 2010, 12:07 GMT
As far as I know, it can but only on a per checkout basis and it will not do it with these options.