Please bump to the latest version openconnect 3.12 Reproducible: Always
Renaming ebuild to 3.12 appears to build and work for amd64.
Created attachment 287423 [details, diff] openconnect.ini.in.patch This fixes the problem where the openconnect init script does not stop the openconnect process since it does not know where the pid file is.
Just bumped to 3.13 since it also appears to compile and function properly.
3.15 is now out.
Versions 3.16-3.20, 3.99, and 4.00-4.07 have been released. I tried the ebuild rename trick to get a newer version installed, but I get the following error(from 4.07, but also occured with 3.15): /usr/bin/python "./html.py" -d . changelog.xml > changelog.html || (rm changelog.html; exit 1) File "./html.py", line 32 print "USAGE:" ^ SyntaxError: invalid syntax Also, 4.07, and I suspect 4.00-4.06 as well, have a dependency on net-misc/vpnc.
According to the developer's site, net-misc/vpnc is required from 3.17 on.
Switched to python 2.7 using eselect and commented out the dohtml line in the ebuild. That allowed install of 4.07.
Created attachment 327326 [details, diff] openconnect.init.in.patch This patch changes the executable path to the new location and adds the needed --pid-file for the execution path since openconnect no longer creates a pid file without it for openconnect 4.07.
Created attachment 327328 [details, diff] openconnect-4.07.ebuild.patch This patches the ebuild in portage to 4.07 by removing the dohtml line which no longer works.
Robert Piasek: What's the hold up on bumping this? I requested a version bump over a year ago. Please bump to 4.07. I've successfully compiled, installed and connected to a vpn with these latest patches.
Created attachment 327414 [details, diff] openconnect-4.07.ebuild.patch This patch also uses a newer vpnc script otherwise openconnect calls a non-existent reconnect command.
Created attachment 327416 [details] openconnect-script New openconnect/vpnc script with several changes including the addition of reconnect.
Hello Matthew, thanks for your efforts in maintaining this; unfortunately this package has been orphan for quite some time. I stumbled upon this when looking for an alternative to anyConnect, that route kidnapper. Maybe you'd like to step in as a maintainer for this package.
(In reply to comment #13) > Hello Matthew, thanks for your efforts in maintaining this; unfortunately > this package has been orphan for quite some time. I stumbled upon this when > looking for an alternative to anyConnect, that route kidnapper. > > Maybe you'd like to step in as a maintainer for this package. I'm not a gentoo dev but I'd gladly be a proxy maintainer.
(In reply to comment #14) > I'm not a gentoo dev but I'd gladly be a proxy maintainer. Proxy maintainers, can anyone help out?
Yes I guess we can
Created attachment 331056 [details, diff] openconnect-4.07.ebuild.patch
Created attachment 331058 [details] openconnect-script.bz2
Created attachment 331062 [details] openconnect-4.07.ebuild
Created attachment 331064 [details] openconnect.init.in
Created attachment 331066 [details] metadata.xml
I'm currently trying to get upstream to fix a CSTP restart problem that happens every 30 minutes with 4.07. It will do a CSTP restart every 30 minutes for me which subsequently creates a partially working connection (ping works, tcp packets don't). We may or may not want to keep 3.x around until this is fixed since 3.x doesn't exhibit this problem. I noticed there is a security bug #421273 for 3.18 so it's unclear as to whether 3.x should remain in the tree. If it does remain, then the tree needs to have two versions of the init script since the file location changed between 3.x and 4.x
Created attachment 331068 [details] openconnect.conf.in
We can't put the bz2 file in ${FILESDIR}. Someone has to put it to mirrors or his devspace
(In reply to comment #24) > We can't put the bz2 file in ${FILESDIR}. Someone has to put it to mirrors > or his devspace repoman complains about it being too big, so how do we get it on a mirror? Also, I don't quite understand why ebuild files are hosted in a devspace. It seems that isn't necessarily a stable place to put something like that.
(In reply to comment #25) > (In reply to comment #24) > > We can't put the bz2 file in ${FILESDIR}. Someone has to put it to mirrors > > or his devspace > > repoman complains about it being too big, so how do we get it on a mirror? > Also, I don't quite understand why ebuild files are hosted in a devspace. > It seems that isn't necessarily a stable place to put something like that. We don't store binary files in cvs. mirrors (or even better devspace) is a very stable place ( assuming the developer is not going away anytime soon ) http://devmanual.gentoo.org/general-concepts/mirrors/index.html
(In reply to comment #26) > (In reply to comment #25) > > (In reply to comment #24) > > > We can't put the bz2 file in ${FILESDIR}. Someone has to put it to mirrors > > > or his devspace > > > > repoman complains about it being too big, so how do we get it on a mirror? > > Also, I don't quite understand why ebuild files are hosted in a devspace. > > It seems that isn't necessarily a stable place to put something like that. > > We don't store binary files in cvs. mirrors (or even better devspace) is a > very stable place ( assuming the developer is not going away anytime soon ) > > http://devmanual.gentoo.org/general-concepts/mirrors/index.html The file is here for you to adjust the ebuild http://dev.gentoo.org/~hwoarang/distfiles/openconnect-script.bz2 Could you tell me what this tarball is for?
(In reply to comment #25) > Also, I don't quite understand why ebuild files are hosted in a devspace. > It seems that isn't necessarily a stable place to put something like that. Some people (myself included) also disagree, but indeed it is policy: > Previous policy was to use mirror://gentoo directly, but this is now > deprecated, as that wouldn't allow to have long-term availability and > traceability of the source files, which might be a requirement of the license. Do note however that distfiles initially stored in devspace will be automatically mirrored when the ebuild hits the tree anyway.
(In reply to comment #27) > (In reply to comment #26) > > (In reply to comment #25) > > > (In reply to comment #24) > > > > We can't put the bz2 file in ${FILESDIR}. Someone has to put it to mirrors > > > > or his devspace > > > > > > repoman complains about it being too big, so how do we get it on a mirror? > > > Also, I don't quite understand why ebuild files are hosted in a devspace. > > > It seems that isn't necessarily a stable place to put something like that. > > > > We don't store binary files in cvs. mirrors (or even better devspace) is a > > very stable place ( assuming the developer is not going away anytime soon ) > > > > http://devmanual.gentoo.org/general-concepts/mirrors/index.html > > The file is here for you to adjust the ebuild > > http://dev.gentoo.org/~hwoarang/distfiles/openconnect-script.bz2 > > Could you tell me what this tarball is for? This script file is actually hosted but it is versionless and not tagged: http://git.infradead.org/users/dwmw2/vpnc-scripts.git/history/HEAD:/vpnc-script In this case, I assume it is better that the ebuild doesn't pull it from here since it's a moving target? Could you grab the latest version from there, compress it again and host it so I can test with that script or should I just upload a compressed version of the lastest script again on this bug?
(In reply to comment #28) > (In reply to comment #25) > > Also, I don't quite understand why ebuild files are hosted in a devspace. > > It seems that isn't necessarily a stable place to put something like that. > > Some people (myself included) also disagree, but indeed it is policy: > > > Previous policy was to use mirror://gentoo directly, but this is now > > deprecated, as that wouldn't allow to have long-term availability and > > traceability of the source files, which might be a requirement of the license. > > Do note however that distfiles initially stored in devspace will be > automatically mirrored when the ebuild hits the tree anyway. There should then be a hosted space for files like these not specific to any dev environment but one in which all the devs have access to so that if a dev space does go away (unlikely but it could), then the file wouldn't be lost.
(In reply to comment #30) > (In reply to comment #28) > > (In reply to comment #25) > > > Also, I don't quite understand why ebuild files are hosted in a devspace. > > > It seems that isn't necessarily a stable place to put something like that. > > > > Some people (myself included) also disagree, but indeed it is policy: > > > > > Previous policy was to use mirror://gentoo directly, but this is now > > > deprecated, as that wouldn't allow to have long-term availability and > > > traceability of the source files, which might be a requirement of the license. > > > > Do note however that distfiles initially stored in devspace will be > > automatically mirrored when the ebuild hits the tree anyway. > > There should then be a hosted space for files like these not specific to any > dev environment but one in which all the devs have access to so that if a > dev space does go away (unlikely but it could), then the file wouldn't be > lost. I am not going away anytime soon ;-)
(In reply to comment #29) > (In reply to comment #27) > > (In reply to comment #26) > > > (In reply to comment #25) > > > > (In reply to comment #24) > > > > > We can't put the bz2 file in ${FILESDIR}. Someone has to put it to mirrors > > > > > or his devspace > > > > > > > > repoman complains about it being too big, so how do we get it on a mirror? > > > > Also, I don't quite understand why ebuild files are hosted in a devspace. > > > > It seems that isn't necessarily a stable place to put something like that. > > > > > > We don't store binary files in cvs. mirrors (or even better devspace) is a > > > very stable place ( assuming the developer is not going away anytime soon ) > > > > > > http://devmanual.gentoo.org/general-concepts/mirrors/index.html > > > > The file is here for you to adjust the ebuild > > > > http://dev.gentoo.org/~hwoarang/distfiles/openconnect-script.bz2 > > > > Could you tell me what this tarball is for? > > This script file is actually hosted but it is versionless and not tagged: > > http://git.infradead.org/users/dwmw2/vpnc-scripts.git/history/HEAD:/vpnc- > script > > In this case, I assume it is better that the ebuild doesn't pull it from > here since it's a moving target? > > Could you grab the latest version from there, compress it again and host it > so I can test with that script or should I just upload a compressed version > of the lastest script again on this bug? Ok the newest code is here http://dev.gentoo.org/~hwoarang/distfiles/openconnect-script.tar.gz Maybe it worth adding a version in it (like openconnect-script-4.07.tar.gz) so we can host multiple files for separate ebuilds?
> Ok the newest code is here > > http://dev.gentoo.org/~hwoarang/distfiles/openconnect-script.tar.gz > > Maybe it worth adding a version in it (like openconnect-script-4.07.tar.gz) > so we can host multiple files for separate ebuilds? I like that idea but I think the version number should be the GMT timestamp of the git commit so we know which version it is so that the latest version right now (Thu, 8 Nov 2012 14:59:04 -0600 (20:59 +0000)) would be 20121108205904. Then if we revbump the ebuild, we can have multiple revs with different script versions.
(In reply to comment #33) > > Ok the newest code is here > > > > http://dev.gentoo.org/~hwoarang/distfiles/openconnect-script.tar.gz > > > > Maybe it worth adding a version in it (like openconnect-script-4.07.tar.gz) > > so we can host multiple files for separate ebuilds? > > I like that idea but I think the version number should be the GMT timestamp > of the git commit so we know which version it is so that the latest version > right now (Thu, 8 Nov 2012 14:59:04 -0600 (20:59 +0000)) would be > 20121108205904. Then if we revbump the ebuild, we can have multiple revs > with different script versions. No problem. I renamed it to openconnect-script-20121108205904.tar.gz http://dev.gentoo.org/~hwoarang/distfiles/openconnect-script-20121108205904.tar.gz
Created attachment 331366 [details] openconnect-4.07.ebuild
(In reply to comment #35) > Created attachment 331366 [details] > openconnect-4.07.ebuild Changes: Changed openconnect script to be retrieved from hwoarang's devspace. Added linguas support. Added missing dependency on zlib.
Created attachment 331370 [details] openconnect-4.07.ebuild Added support for selecting gnutls or openssl.
> (In reply to comment #36) > > Added linguas support. Repoman error: IUSE.invalid 3 net-misc/openconnect/openconnect-4.07.ebuild: linguas_ms_MY net-misc/openconnect/openconnect-4.07.ebuild: linguas_tg_TJ net-misc/openconnect/openconnect-4.07.ebuild: linguas_tl_PH The following locales need to be added linguas.desc to support all the locales for this package: ms_MY - Malay locale tg_TJ - Tajik locale tl_PH - Tagalog locale
Created attachment 331372 [details] metadata.xml
(In reply to comment #38) > > (In reply to comment #36) > > > > Added linguas support. > > Repoman error: > > IUSE.invalid 3 > net-misc/openconnect/openconnect-4.07.ebuild: linguas_ms_MY > net-misc/openconnect/openconnect-4.07.ebuild: linguas_tg_TJ > net-misc/openconnect/openconnect-4.07.ebuild: linguas_tl_PH > > > The following locales need to be added linguas.desc to support all the > locales for this package: > > ms_MY - Malay locale > tg_TJ - Tajik locale > tl_PH - Tagalog locale You can use "ms" "tg" and "tl" which already exist in linguas.desc. We already do that for locales which use the long format. For example if ${LINGUAS} has "ms"; then install ms_MY fi etc See http://devmanual.gentoo.org/function-reference/query-functions/index.html
(In reply to comment #40) > (In reply to comment #38) > > > (In reply to comment #36) > > > > > > Added linguas support. > > > > Repoman error: > > > > IUSE.invalid 3 > > net-misc/openconnect/openconnect-4.07.ebuild: linguas_ms_MY > > net-misc/openconnect/openconnect-4.07.ebuild: linguas_tg_TJ > > net-misc/openconnect/openconnect-4.07.ebuild: linguas_tl_PH > > > > > > The following locales need to be added linguas.desc to support all the > > locales for this package: > > > > ms_MY - Malay locale > > tg_TJ - Tajik locale > > tl_PH - Tagalog locale > > You can use "ms" "tg" and "tl" which already exist in linguas.desc. We > already do that for locales which use the long format. For example > > if ${LINGUAS} has "ms"; then > install ms_MY > fi > > etc > > See http://devmanual.gentoo.org/function-reference/query-functions/index.html The problem with this is there already are ms.po, tg.po and tl.po files and they are different from the files I listed above. So I just exclude the locales that don't exist in linguas.desc?
(In reply to comment #41) > (In reply to comment #40) > > (In reply to comment #38) > > > > (In reply to comment #36) > > > > > > > > Added linguas support. > > > > > > Repoman error: > > > > > > IUSE.invalid 3 > > > net-misc/openconnect/openconnect-4.07.ebuild: linguas_ms_MY > > > net-misc/openconnect/openconnect-4.07.ebuild: linguas_tg_TJ > > > net-misc/openconnect/openconnect-4.07.ebuild: linguas_tl_PH > > > > > > > > > The following locales need to be added linguas.desc to support all the > > > locales for this package: > > > > > > ms_MY - Malay locale > > > tg_TJ - Tajik locale > > > tl_PH - Tagalog locale > > > > You can use "ms" "tg" and "tl" which already exist in linguas.desc. We > > already do that for locales which use the long format. For example > > > > if ${LINGUAS} has "ms"; then > > install ms_MY > > fi > > > > etc > > > > See http://devmanual.gentoo.org/function-reference/query-functions/index.html > > The problem with this is there already are ms.po, tg.po and tl.po files and > they are different from the files I listed above. So I just exclude the > locales that don't exist in linguas.desc? In this case yes, that would be preferred.
Created attachment 331402 [details] openconnect-4.07.ebuild Removed the locales that don't exists in linguas.desc.
I am getting this problem when I try to configure this checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes configure: error: /etc/vpnc/vpnc-script does not seem to be executable. OpenConnect will not function correctly without a vpnc-script. See http://www.infradead.org/openconnect/vpnc-script.html for more details. If you are building a distribution package, please ensure that your packaging is correct, and that a vpnc-script will be installed when the user installs your package. You should provide a --with-vpnc-script= argument to this configure script, giving the full path where the script will be installed. The standard location is /etc/vpnc/vpnc-script. To bypass this error and build OpenConnect to use the script from this location, even though it's not present at the time you are building OpenConnect, pass the argument "--with-vpnc-script=/etc/vpnc/vpnc-script" I have no /etc/vpnc/vpnc-script on this box Something is missing?
(In reply to comment #44) > I am getting this problem when I try to configure this > > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... yes > configure: error: /etc/vpnc/vpnc-script does not seem to be executable. > OpenConnect will not function correctly without a vpnc-script. > See http://www.infradead.org/openconnect/vpnc-script.html for more > details. > > If you are building a distribution package, please ensure that your > packaging is correct, and that a vpnc-script will be installed when the > user installs your package. You should provide a --with-vpnc-script= > argument to this configure script, giving the full path where the script > will be installed. > > The standard location is /etc/vpnc/vpnc-script. To bypass this error and > build OpenConnect to use the script from this location, even though it's > not present at the time you are building OpenConnect, pass the argument > "--with-vpnc-script=/etc/vpnc/vpnc-script" > > I have no /etc/vpnc/vpnc-script on this box > > Something is missing? ok, I'll fix that. I have vpnc installed. vpnc isn't a dependency but but obviously I didn't see the resulting error.
(CCing maintainer-needed as metadata still states it's the maintainer, not sure if intended)
(In reply to comment #46) > (CCing maintainer-needed as metadata still states it's the maintainer, not > sure if intended) I will remove this when I commit this bump
Created attachment 331486 [details] openconnect.conf.in Integrated fix for bug #396503.
Created attachment 331488 [details] openconnect.init.in Integrated fix for bug #396503.
Created attachment 331490 [details] openconnect-4.07.ebuild Fixed vpnc-script path problem.
Created attachment 331496 [details] openconnect.logrotate New logrotate script for default logrotate settings.
Created attachment 331498 [details] openconnect.init.in New init script to support multiple vpn tunnels to fix bug #380643.
Created attachment 331500 [details] openconnect.conf.in New conf script to support multiple vpn tunnels and fix bug #380643.
Created attachment 331502 [details] openconnect-4.07.ebuild New ebuild supporting multiple tunnels and logrotate script installation.
(In reply to comment #54) > Created attachment 331502 [details] > openconnect-4.07.ebuild > > New ebuild supporting multiple tunnels and logrotate script installation. Thanks. I will have a look tonight
+*openconnect-4.07 (05 Dec 2012) + + 05 Dec 2012; Markos Chandras <hwoarang@gentoo.org> + +files/openconnect.logrotate, +openconnect-4.07.ebuild, + files/openconnect.conf.in, files/openconnect.init.in, metadata.xml: + Version bump. Thanks to Matthew Schultz <mattsch@gmail.com> who will maintain + it. Bug #384099 +
(In reply to comment #56) > +*openconnect-4.07 (05 Dec 2012) > + > + 05 Dec 2012; Markos Chandras <hwoarang@gentoo.org> > + +files/openconnect.logrotate, +openconnect-4.07.ebuild, > + files/openconnect.conf.in, files/openconnect.init.in, metadata.xml: > + Version bump. Thanks to Matthew Schultz <mattsch@gmail.com> who will > maintain > + it. Bug #384099 > + Clean 3.11 out of the tree as well since the new conf and init scripts are overwritte and might cause confusion with that version.
