Hello. fwknop-2.6.3 was released a while ago. Among other changes client's IP resolution (`-R` option) is done via HTTPS now (unless specifically requested to use plain HTTP). Prior to 2.6.3 it was done via plain HTTP. fwknop client requires either one of the options -a/-s/-R to be specified. The most practical one (IMHO) is `-R`, which uses wget to send HTTPS request. This is why client installation now depends on wget[ssl]. @proxy-maint, please remove ebuild for 2.6.2 and add ebuild for 2.6.3. Please also remove files/fwknop-2.6.0-remove-extra-run-from-paths.patch file and add fwknop-2.6.3-remove-extra-run-from-paths.patch to files/ dir. Reproducible: Always
Created attachment 382742 [details] fwknop-2.6.3.ebuild
Created attachment 382744 [details] fwknop-2.6.3-remove-extra-run-from-paths.patch
Upstream released a new version -- 2.6.4 I'll attach updated ebuild and related files. Noteworthy changes: conversion to autotools-utils eclass, use github sources for build as they are easier to create patches against, libpcap is now optional through udp-server USE-flag. Please push this version instead.
Created attachment 389730 [details] fwknop-2.6.4.ebuild
Created attachment 389732 [details, diff] fwknop-2.6.4-remove-extra-run-from-paths.patch
Created attachment 389734 [details, diff] fwknop-2.6.4-disable-IP-resolution-in-AFL_FUZZING-mode.patch
Created attachment 389736 [details, diff] fwknop-2.6.4-ensure-a-overrides-IP-resolution.patch
Created attachment 389738 [details] metadata.xml --- /var/portage/net-firewall/fwknop/metadata.xml 2014-04-27 14:50:49.000000000 +0400 +++ metadata.xml 2014-11-19 15:40:53.030824968 +0300 @@ -8,9 +8,10 @@ </maintainer> <use> <flag name="client">Build fwknop client</flag> + <flag name="extras">Install example apparmor policy</flag> <flag name="gdbm">Replace file digest-cache with gdbm</flag> <flag name="gpg">Enable GPG support via <pkg>app-crypt/gpgme</pkg></flag> <flag name="server">Build fwknopd server</flag> - <flag name="extras">Install example apparmor policy</flag> + <flag name="udp-server">Build fwknopd with UDP server mode only</flag> </use> </pkgmetadata>
Hello. fwknop-2.6.5 is out. Attaching ebuild, patch, and updated confd and initscript files. Everything with minor changes. @proxy-maint, please bump to 2.6.5.
Created attachment 391870 [details] fwknop-2.6.5.ebuild
Created attachment 391872 [details, diff] fwknop-2.6.5-remove-extra-run-from-paths.patch
Created attachment 391874 [details] fwknopd.init
Created attachment 391876 [details] fwknopd.confd
Since fwknop is struggling to be updated in tree, anybody who wants recent versions of it is welcome to my private overlay available at git://bonespirit.org/bonespirit.git You can grab it there.
@proxy-maint, come on. 5 months to just push a couple of files to the tree? Really?
Created attachment 402084 [details] fwknop-2.6.6.ebuild
Created attachment 402086 [details] fwknopd.init
fwknop-2.6.6 is out. Our strip-/run-from-paths patch was merged upstream and is obsolete now. The attached ebuild is tested and works fine on my machine. Also cleaned up initscript a bit. @proxy-maint, please, do your thing and push this into the tree. Please also remove the current 2.6.2 ebuild and the related patch.
Will CC Pinkbyte in a week or so if this one stays as it is.
1. inherit autotools-utils distutils-r1 systemd 2. RDEPEND="python? ( ${PYTHON_DEPS} ) 3. REQUIRED_USE="python? ( ${PYTHON_REQUIRED_USE} ) Here we go again. This combo generally matches the inheriting of python-r1. In this case you could select python-single-r1 since you have # Does work with python 2.7, does not work with python 3.3 on my machine # More feedback is welcome PYTHON_COMPAT=( python2_7 ) python-single-r1 is after all used for a single python version. Perusal of setup.py should but not always inform you of which major / minot versions of python the code will support. Lines 2. and 3. are NOT required on inheriting of distutils-r1. These facets are all covered in the page prepared by the eclass writer in the wiki for addressing conversions of ebuilds from olde elcass to new. No this isn't a conversion however the page(s) does / do clearly outline examples of code use pertinent to the differing but similar elcasses. e.g. If you use python-single-r1 you will need to add the pkg_setup phase to ensure the selection of the right system python to run the build. If you find an ebuild to illustrate use of lines 1. and 2. in combo with inherit distutils-r1 then that ebuild needs editing. I believe some do in fact exist. I cannot therefore commit this ebuild and bump this package to 2.6.6
(In reply to Ian Delaney from comment #20) > Perusal of > setup.py should but not always inform you of which major / minot versions of > python the code will support. Not applicable in the case. setup.py has no version info as well as documentation and sources I am aware of. Otherwise, these versions would be specified in the ebuild instead of trial and error estimation we have now. > Lines 2. and 3. are NOT required on inheriting of distutils-r1. > > These facets are all covered in the page prepared by the eclass writer in > the wiki for addressing conversions of ebuilds from olde elcass to new. At the time the very first version of this ebuild was created the documentation about new distutils-r1, python-r1 and friends was not as extensive as it is nowadays. IMHO it was poor. I'll look into the recent one. > I cannot therefore commit this ebuild and bump this package to 2.6.6 So, what is your point exactly? Do you suggest conversion to python-single-r1? Wouldn't DISTUTILS_SINGLE_IMPL=1 be enough?
(In reply to Coacher from comment #21) > (In reply to Ian Delaney from comment #20) > > Perusal of > > setup.py should but not always inform you of which major / minor versions of > > python the code will support. > > Not applicable in the case. setup.py has no version info as well as > documentation and sources I am aware of. Otherwise, these versions would be > specified in the ebuild instead of trial and error estimation we have now. > What do you mean not applicable? "does not work with python 3.3 on my machine" is actually fine. It indicates you runtested with py3 and it it didn't 'come up'; it illustrates it does not support py3 which is still not uncommon. > > Lines 2. and 3. are NOT required on inheriting of distutils-r1. > > > > These facets are all covered in the page prepared by the eclass writer in > > the wiki for addressing conversions of ebuilds from olde elcass to new. > > At the time the very first version of this ebuild was created the > documentation about new distutils-r1, python-r1 and friends was not as > extensive as it is nowadays. IMHO it was poor. I'll look into the recent one. > True enough. Do so. I assisted in the prep of the first pages 2 years ago. The pages of conversions are new since then. They also describe new vars and variations added only in recent months. > > I cannot therefore commit this ebuild and bump this package to 2.6.6 > > So, what is your point exactly? Do you suggest conversion to > python-single-r1? Wouldn't DISTUTILS_SINGLE_IMPL=1 be enough? My point is that the ebuild, although not broken and may work, has errors that are not revealed or reported by repoman but take the knowledge of devs experienced in these eclasses. It is in fact close and I have already supplied a number of tips and clues. Switch to python-r1 or python-single-r1 and you are almost there. Keep to the distutils-r1 and remove the Lines 2. and 3 and again you are almost there. Once I see an ebuild that has these I will start runtesting. DISTUTILS_SINGLE_IMPL=1 is something I tried and ran into heavy flack. Try it at your peril.
pause; use of DISTUTILS_OPTIONAL=1 appears to set these options right. I am looking at it further. Not something I normally use.
Use of DISTUTILS_OPTIONAL=1 does make these settings right and I missed it because I have virtually never used it. However; with the dropping of the patch in this bump, # Unset PATCHES since distutils-r1.eclass interferes local PATCHES=() is now superfluous and needs removing. So fwknopd.confd of 2014-12-17 and fwknopd.init of 2015-04-27 should substitute those files present in portage. Just attach either the ebuild with those lines deleted or a unified diff file achieving the same end and it will be ready for addition to portage.
(In reply to Ian Delaney from comment #22) > (In reply to Coacher from comment #21) > > (In reply to Ian Delaney from comment #20) > > > Perusal of > > > setup.py should but not always inform you of which major / minor versions of > > > python the code will support. > > > > Not applicable in the case. setup.py has no version info as well as > > documentation and sources I am aware of. Otherwise, these versions would be > > specified in the ebuild instead of trial and error estimation we have now. > > > > What do you mean not applicable? It means setup.py has no such info.
A setup.py file has a section setup( typically with something like 'Programming Language :: Python', 'Programming Language :: Python :: 2', 'Programming Language :: Python :: 3', It's not that it's not applicable, it's that the makers of this setup.py file simply didn't include it, which they ought to have. If there's any reason it's because the python build is an option but it's still no excuse. They ought to have included it as a matter of course.
1. Awaiting simple diff to delete the 2 lines cited in Comment 24. 2. The changes to the confd and initd files also require clarification. The files once changed will be used by all *fwknop-2.6.6 (29 Apr 2015) 29 Apr 2015; Ian Delaney <idella4@gentoo.org> +fwknop-2.6.6.ebuild, -files/fwknop-2.6.0-remove-extra-run-from-paths.patch, -fwknop-2.6.2.ebuild, files/fwknopd.confd, files/fwknopd.init, metadata.xml: bump; ebuild supplied by Coacher in bug #519716, newinitd and newconfd files updated, removed prior version to avoid any mismatch, closes bug #519716 bumped for the sake of removing 2 trivial and harmless lines. If there is any substantial reason to have kept fwknop-2.6.2.ebuild; 1. Just request and it can be re-added 2. You will need to decide whether the former files newinitd and newconfd need be returned to match, and if yes 3. they will need renaming so as to be distinguished.
Created attachment 402262 [details] fwknop-2.6.6.ebuild (In reply to Ian Delaney from comment #27) > 1. Awaiting simple diff to delete the 2 lines cited in Comment 24. Here it is. Though you've already commited ebuild with these lines removed to the tree, I've slightly updated it: expanded comments a bit, moved a couple of lines around to improve readability and added DISTUTILS_SINGLE_IMPL=1. Please push this one to the tree. Revbump is not needed. > 2. The changes to the confd and initd files also require clarification. fwknopd.confd has only received comment readability updates. fwknopd.init has received minor updates: better error messages, simplified initial variables setup, cleaner internal bash code. > If there is any substantial reason to have kept fwknop-2.6.2.ebuild; No, 2.6.2 should be removed. Actually I've requsted this removal in comment #18. Thanks.
Created attachment 402266 [details] fwknopd.init Replace ugly backslashed double quotes with single quotes (where possible).
Ian, please, push the updated ebuild and initscript to the tree. They both have minor, but useful changes. Revbump is not needed in this case. Once these files are pushed, this bug can be finally closed.
will do these later in the day
01 May 2015; Ian Delaney <idella4@gentoo.org> files/fwknopd.init, fwknop-2.6.6.ebuild: tidy, patches by maintainer from Bug #519716
(In reply to Ian Delaney from comment #32) > 01 May 2015; Ian Delaney <idella4@gentoo.org> files/fwknopd.init, > fwknop-2.6.6.ebuild: > tidy, patches by maintainer from Bug #519716 Thanks, but why you've added an empty line to the end of initscript and added a line break that introduced a trailing whitespace? These are lines 35-36 and 98. These things are not present in the file I've attached here. Please update properly. Reopening.
(In reply to Coacher from comment #33) > (In reply to Ian Delaney from comment #32) > > 01 May 2015; Ian Delaney <idella4@gentoo.org> files/fwknopd.init, > > fwknop-2.6.6.ebuild: > > tidy, patches by maintainer from Bug #519716 > > Thanks, but why you've added an empty line to the end of initscript and > added a line break that introduced a trailing whitespace? These are lines > 35-36 and 98. These things are not present in the file I've attached here. > Please update properly. Reopening. Same goes for fwknopd.conf: there is an additional trailing line, which is not even empty. See line 22. Again no such line fwknopd.conf file I've attached here. Please fix.
(In reply to Coacher from comment #34) > Again no such line fwknopd.conf file I've attached here. *no such line in
Also for some reason you've messed up USE flag ordering in metadata.xml. How is this even possible, Ian?
(In reply to Coacher from comment #36) > Also for some reason you've messed up USE flag ordering in metadata.xml. How > is this even possible, Ian? Quite simple. copy paste. The editor I use added the line break and spaces by copy paste, which I normally pick up and tidy. Normally the editor corrupting the line break would break something in an ebuild. In this case it slipped through by being in files under files/. 1. fwknopd.conf is actually fwknopd.confd 2. metadata; All I did was to add the udp-server use flag to the existing metadata.xml The order of the flags is quite inconsequential. This is simply not an issue from a functional or qa perspective. This can all be avoided by use of a unified; diff -u. All the files you attached were whole files; ebuilds, init files, even the metadata.xml. e.g. copy the file files/fwknopd.confd to files/fwknopd.confd.orig Make the edits Do a diff -u files/fwknopd.confd.orig files/fwknopd.confd > fwknopd-confd.patch or fwknopd-confd.diff. I import the patch and patch the files/fwknopd.confd with $ patch < /path/to/fwknopd-confd.patch and the changes apply cleanly with no involvement of an editor having a chance to corrupt them. This is standard practice in patch making. Sorry for the inconvenience but it should all be fixed now.
(In reply to Ian Delaney from comment #37) > Quite simple. copy paste. The editor I use added the line break and spaces > by copy paste, which I normally pick up and tidy. Normally the editor > corrupting the line break would break something in an ebuild. In this case > it slipped through by being in files under files/. But how the additional data ended up in fwknopd.confd then? > 2. metadata; All I did was to add the udp-server use flag to the existing > metadata.xml The order of the flags is quite inconsequential. This is > simply not an issue from a functional or qa perspective. I'd really prefer alphabetical order, though. But I guess we can leave it as it is for now. > This can all be avoided by use of a unified; diff -u. All the files you > attached were whole files; ebuilds, init files, even the metadata.xml. OK, next time I'll attach patches instead. > Sorry for the inconvenience but it should all be fixed now. Waiting for the mirror sync to confirm.
But how the additional data ended up in fwknopd.confd then? Well there is an answer to that but it I'm more curious about your intense curiosity over it. In saving I accidentally added a 9 and didn't notice. That's it. I took it out and fixed it. Yes I could have done a diff -u before committing like I normally do but I didn't. I'd really prefer alphabetical order, though. But I guess we can leave it as it is for now. Well I can if you REALLY want me to. It won't make the use flags work any better. OK, next time I'll attach patches instead. Clearly you didn't know about patching technique
(In reply to Ian Delaney from comment #39) > Well there is an answer to that but it I'm more curious about your intense > curiosity over it. In saving I accidentally added a 9 and didn't notice. > That's it. I took it out and fixed it. Yes I could have done a diff -u > before committing like I normally do but I didn't. There is an answer to that too. The fact that 3 out of my 4 files that were accepted here made it to the tree with additional yet unintentional changes is unusual to me. Now that you've said that you simply forgot to check the diff before committing I have no further questions. > Well I can if you REALLY want me to. It won't make the use flags work any > better. It's fine with me to leave them as is. > Clearly you didn't know about patching technique Correction: I didn't know about your personal preference. No @proxy-maint member made a point before that diffs are preferred. There are no mentions that diffs are preferred anywhere here: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers https://wiki.gentoo.org/wiki/Bugzilla/Guide https://wiki.gentoo.org/wiki/Beautiful_bug_reports Except for: "Sometimes a developer might ask bug submitters to attach a diff or patch for a file."
(In reply to Ian Delaney from comment #37) > Sorry for the inconvenience but it should all be fixed now. I can confirm that all relevant files are fine now. Thank you for the initial commit and follow-up fixes, Ian. Closing.
