Summary: | net-firewall/ipsec-tools enable-stats compile option leads to too much garbage output in logs | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Arhont <mlists> |
Component: | [OLD] Server | Assignee: | Anthony Basile <blueness> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gem, gentoo, mmokrejs, Phil, stlman |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 326647 |
Description
Arhont
2009-05-11 19:23:33 UTC
Robert, cc'ing you since you are the last person with a non-trivial commit. +1 Also, can we get this line removed from /etc/conf.d/racoon: RACOON_OPTS="-4" When I build with the ipv6 USE flag I epxect to get IPv6. Less then two years now until IPv4 exhaustion. (In reply to comment #2) > +1 > > Also, can we get this line removed from /etc/conf.d/racoon: > > RACOON_OPTS="-4" > > > When I build with the ipv6 USE flag I epxect to get IPv6. Less then two years > now until IPv4 exhaustion. > I even don't know what that should be useful for. I'd guess to enable IPv4 only but does racoon support such a flag at all? # /etc/init.d/racoon start * Loading ipsec policies from /etc/ipsec.conf. The result of line 3: File exists. * Starting racoon ... /usr/sbin/racoon: invalid option -- '4' usage: racoon [-BdFv] [-a (port)] [-f (file)] [-l (file)] [-p (port)] -B: install SA to the kernel from the file specified by the configuration file. -d: debug level, more -d will generate more debug message. -C: dump parsed config file. -L: include location in debug messages -F: run in foreground, do not become daemon. -v: be more verbose -a: port number for admin port. -f: pathname for configuration file. -l: pathname for log file. -p: port number for isakmp (default: 500). -P: port number for NAT-T (default: 4500). * start-stop-daemon: failed to start `/usr/sbin/racoon' [ !! ] * ERROR: racoon failed to start This trivial to fix bug has been open almost 2 years! Can we get it fixed please? Congratulations, you made it! By today, this bug has completed it's second year of existence. Note that it didn't get any more complicated or obscure in it's time being - all the old, trivial to fix and highly annoying bug we got to know two years ago. Good luck for the next two years, and keep on annoying us as you did so well until today! I recently adopted this package and bumped to 0.8.0. I added a USE flag for stats which addresses the point of the bug, so I'm closing this one. As for comment #2, its still in there but I have no objections to removing RACOON_OPTS="-4". Usually its up to the user to mess with the conf.d but I see your point. Please test by removing it with 0.8.0 and let me know if there are any issues --- I know its trivial, but I don't use ipsec with ipv6 and I'd like to proceed cautiously with an important package I just adopted. As for comment #5, I can assure you that I am a responsive maintainer. I was shocked when I came across such an important package that was left without a maintainer. (In reply to comment #6) > As for comment #2, its still in there but I have no objections to removing > RACOON_OPTS="-4". Usually its up to the user to mess with the conf.d but I see > your point. Please test by removing it with 0.8.0 and let me know if there are > any issues --- I know its trivial, but I don't use ipsec with ipv6 and I'd like > to proceed cautiously with an important package I just adopted. IMHO it shouldn't hurt as long as it's commented out by default. Problem is, the option (along with -6) only exists when having IPv6 support compiled into racoon. So in fact only those users could make use of it which obviously seem to not want it due to their choice of USE flags. ;) > As for comment #5, I can assure you that I am a responsive maintainer. I was > shocked when I came across such an important package that was left without a > maintainer. Good to know, although it makes me a bit sad seeing this bug finally die after it has survived for almost three years now. :) I'm testing now. So far so good. Thanks so much! Next: how do we get this in stable? (In reply to comment #8) > I'm testing now. So far so good. Thanks so much! > > Next: how do we get this in stable? 30 days in the tree without major bugs open. Wait about a month and then open a stablereq. In the mean time, I have to at least address an issue in the build system where it looks for a header file in /usr/src/linux/include/linux rather than /usr/include/linux. In fact the whole ebuild makes the dangerous assumption that the running kernel = the kernel source + config in /usr/src/linux. This is seldom the case as people update/change kernels often. |