Re: FreeBSD FreeRADIUS port updated to 1.1.5, with various enhancements
David Wood wrote: The above patch is tested and working against 1.1.5. Passing --without-docdir to configure generates a warning and prevents the installation of any documentation. If, after any desired tidying up, this can be committed to the CVS for branch_1_1 and HEAD I would be grateful. Thanks for the feedback. I've added in CVS the support for ./configure --without-docdir. The change should be in 1.1.6. -- Nicolas Baradakis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeBSD FreeRADIUS port updated to 1.1.5, with various enhancements
In message [EMAIL PROTECTED], Alan DeKok
[EMAIL PROTECTED] writes
Nicolas Baradakis wrote:
...
+ifeq ($(docdir),no)
+install:
+@echo 'Documentation files will NOT be installed.'
+else
I'd prefer not to have multiple install targets... even if they're
wrapped with 'ifeq'. Sort of like how #ifdef's in the code should be
avoided.
OK - implementing Alan's suggestions on top of Nicolas' patch gives:
Index: configure.in
===
RCS file: /source/radiusd/configure.in,v
retrieving revision 1.198.2.15.2.13
diff -u -r1.198.2.15.2.13 configure.in
--- configure.in26 Mar 2007 12:58:16 - 1.198.2.15.2.13
+++ configure.in1 Apr 2007 15:16:32 -
@@ -115,7 +115,7 @@
[ --with-docdir=DIR Directory for documentation
[DATADIR/doc/freeradius] ],
[ case $withval in
no)
- AC_MSG_ERROR(Need docdir)
+ docdir=no
;;
yes)
;;
@@ -129,6 +129,9 @@
)
AC_SUBST(docdir)
AC_MSG_RESULT($docdir)
+if test x$docdir = xno; then
+ AC_MSG_WARN(Documentation files will NOT be installed.)
+fi
dnl extra argument: --with-logdir
logdir='${localstatedir}/log/radius'
Index: doc/Makefile
===
RCS file: /source/radiusd/doc/Makefile,v
retrieving revision 1.4.4.2.2.3
diff -u -4 -r1.4.4.2.2.3 Makefile
--- doc/Makefile15 Jul 2006 17:16:51 - 1.4.4.2.2.3
+++ doc/Makefile1 Apr 2007 15:16:44 -
@@ -17,13 +17,15 @@
@rm -f *~
install:
- $(INSTALL) -d -m 755 $(R)$(docdir)
- for file in *[!~]; do \
- if [ -f $$file -a $$file != Makefile ]; then \
- $(INSTALL) -m 644 $$file $(R)$(docdir); \
- fi; \
- done
- @$(MAKE) $(MFLAGS) WHAT_TO_MAKE=$@ common
+ @if [ $(docdir) != no ]; then \
+ $(INSTALL) -d -m 755 $(R)$(docdir); \
+ for file in *[!~]; do \
+ if [ -f $$file -a $$file != Makefile ]; then \
+ $(INSTALL) -m 644 $$file $(R)$(docdir); \
+ fi; \
+ done; \
+ $(MAKE) $(MFLAGS) WHAT_TO_MAKE=$@ common ; \
+ fi
common: $(SUBDIRS)
(I apologise in advance that my mailer has probably eaten all the tabs -
if you want a file uploaded somewhere, I can do that).
The above patch is tested and working against 1.1.5. Passing
--without-docdir to configure generates a warning and prevents the
installation of any documentation.
If, after any desired tidying up, this can be committed to the CVS for
branch_1_1 and HEAD I would be grateful.
Many thanks,
David
--
David Wood
[EMAIL PROTECTED]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeBSD FreeRADIUS port updated to 1.1.5, with various enhancements
David Wood wrote:
In message [EMAIL PROTECTED], Nicolas
Baradakis [EMAIL PROTECTED] writes
David Wood wrote:
There's two other things I'm currently modifying the source to achieve,
on which I'd appreciate comments.
patch-doc::Makefile surrounds the contents of the install target in
doc/Makefile with #ifndef NOPORTDOCS ... #endif. FreeBSD ports have to
respect this flag. Is a neater way to pass --with-docdir=/dev/null to
configure if NOPORTDOCS is defined (which I haven't tried) and abandon
the patch. Has anyone any other suggestions?
Every downstream distribution has its own mechanism to mark the
files as documentation.
--with-docdir=/dev/null results in
mkdir: /dev/null: File exists
It looks like the patch (or some other way of modifying doc/Makefile)
will have to stay. I will continue to modify the source in some suitable
way to achieve this.
Currently ./configure --without-docdir throws an error, but it's
possible to modify this option in CVS to cancel doc files installation.
I think it might be useful for the Suse package, too.
Please give a try to the following patch. If it solves the problem I'll
add it to the CVS.
Index: configure.in
===
RCS file: /source/radiusd/configure.in,v
retrieving revision 1.198.2.15.2.13
diff -u -r1.198.2.15.2.13 configure.in
--- configure.in26 Mar 2007 12:58:16 - 1.198.2.15.2.13
+++ configure.in1 Apr 2007 15:16:32 -
@@ -115,7 +115,7 @@
[ --with-docdir=DIR Directory for documentation
[DATADIR/doc/freeradius] ],
[ case $withval in
no)
- AC_MSG_ERROR(Need docdir)
+ docdir=no
;;
yes)
;;
@@ -129,6 +129,9 @@
)
AC_SUBST(docdir)
AC_MSG_RESULT($docdir)
+if test x$docdir = xno; then
+ AC_MSG_WARN(Documentation files will NOT be installed.)
+fi
dnl extra argument: --with-logdir
logdir='${localstatedir}/log/radius'
Index: doc/Makefile
===
RCS file: /source/radiusd/doc/Makefile,v
retrieving revision 1.4.4.2.2.3
diff -u -4 -r1.4.4.2.2.3 Makefile
--- doc/Makefile15 Jul 2006 17:16:51 - 1.4.4.2.2.3
+++ doc/Makefile1 Apr 2007 15:16:44 -
@@ -15,16 +15,21 @@
clean:
@$(MAKE) $(MFLAGS) WHAT_TO_MAKE=$@ common
@rm -f *~
+ifeq ($(docdir),no)
+install:
+ @echo 'Documentation files will NOT be installed.'
+else
install:
$(INSTALL) -d -m 755 $(R)$(docdir)
for file in *[!~]; do \
if [ -f $$file -a $$file != Makefile ]; then \
$(INSTALL) -m 644 $$file $(R)$(docdir); \
fi; \
done
@$(MAKE) $(MFLAGS) WHAT_TO_MAKE=$@ common
+endif
common: $(SUBDIRS)
$(SUBDIRS):
--
Nicolas Baradakis
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeBSD FreeRADIUS port updated to 1.1.5, with various enhancements
Nicolas Baradakis wrote: ... +ifeq ($(docdir),no) +install: + @echo 'Documentation files will NOT be installed.' +else I'd prefer not to have multiple install targets... even if they're wrapped with 'ifeq'. Sort of like how #ifdef's in the code should be avoided. Maybe instead: install: if [ $(docdir) != no ]; \ then \ $(INSTALL) ; \ for file in ... \ done; \ @$(MAKE) ... \ fi install: $(INSTALL) -d -m 755 $(R)$(docdir) for file in *[!~]; do \ if [ -f $$file -a $$file != Makefile ]; then \ $(INSTALL) -m 644 $$file $(R)$(docdir); \ fi; \ done @$(MAKE) $(MFLAGS) WHAT_TO_MAKE=$@ common +endif common: $(SUBDIRS) $(SUBDIRS): -- Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeBSD FreeRADIUS port updated to 1.1.5, with various enhancements
Hi Nicolas, Alan and everyone, In message [EMAIL PROTECTED], Nicolas Baradakis [EMAIL PROTECTED] writes David Wood wrote: The second group of patches that remain I'm going to post below - because I think they might be candidates for committing to FreeRADIUS itself. It was clearly felt by previous contributors to the port that the Makefiles don't always contain $(CFLAGS) when they would be expected to. snip The patch adds $(CFLAGS) during the *link*. (not during compile) The linker doesn't need options such as -O3 or -I/path/to/include therefore I'd like to know the reasons why you believe this patch would be useful. I can't think of a reason why it was useful, and I really can't figure out why it was ever added. As you say, all three of these patches relate to link steps, not compilation ones. I've deleted these three patches from the version of the port in my local Subversion repository. There's one patch I wrote, which I think is a bug in a Makefile for 1.1.4 and 1.1.5 (hence the file name of patch-raddb-Makefile-1.1.4_bug): [...] otppasswd.sample seems to have disappeared from 1.1.4 onwards - is this a bug in that Makefile as I believe? If so, can that be fixed in CVS? Indeed it looks like a bug. I've fixed it in CVS. Thanks for the confirmation - that's another patch I look forward to throwing away. There's two other things I'm currently modifying the source to achieve, on which I'd appreciate comments. patch-doc::Makefile surrounds the contents of the install target in doc/Makefile with #ifndef NOPORTDOCS ... #endif. FreeBSD ports have to respect this flag. Is a neater way to pass --with-docdir=/dev/null to configure if NOPORTDOCS is defined (which I haven't tried) and abandon the patch. Has anyone any other suggestions? Every downstream distribution has its own mechanism to mark the files as documentation. --with-docdir=/dev/null results in mkdir: /dev/null: File exists It looks like the patch (or some other way of modifying doc/Makefile) will have to stay. I will continue to modify the source in some suitable way to achieve this. To install the sample raddb files in the correct location, I'm running sed across all Makefile and Makefile.in files, replacing $(R)$(raddbdir) with the appropriate location. I'd rather do this via configure, but if I use --with-raddbdir, that changes the install location of the files *and* the default location the server looks for those files. The latter change isn't wanted. Every downstream distribution has its own mechanism to handle the config files. I don't know the opinion of the others, but I'm unsure about a configure option that's useful for the FreeBSD port only. We have a consensus on this - Alan suggests a sed script. I have tidied up the way I'm doing this in my local version of the port. It's now a couple of find commands with explanatory comments. The first runs sed across each Makefile and Makefile.in, whilst the second removes the .bak files (so that the one in doc/ isn't installed as documentation). That will do fine. With the changes outlined above, I've got one patch which should be unnecessary in 1.1.6 and onwards (because the underlying problem in the source has been fixed), one patch that I believe is only needed for FreeBSD 4.x compatibility (which I expect to remove when that is discontinued), and one patch that's needed to support NOPORTDOCS. That's much more maintainable than the nine patches the port had when I first took the FreeRADIUS FreeBSD port over. Thanks for your comments and support, David -- David Wood [EMAIL PROTECTED] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeBSD FreeRADIUS port updated to 1.1.5, with various enhancements
David Wood wrote: The second group of patches that remain I'm going to post below - because I think they might be candidates for committing to FreeRADIUS itself. It was clearly felt by previous contributors to the port that the Makefiles don't always contain $(CFLAGS) when they would be expected to. It might be that these patches are also unnecessary with the build system used from 1.1.3 onwards - if so, will someone explain why and I'll remove these patches too. I believe they are still needed judging by the output of make, but I'm willing to be corrected (in Alan's gentle style if needs be!). [...] The patch adds $(CFLAGS) during the *link*. (not during compile) The linker doesn't need options such as -O3 or -I/path/to/include therefore I'd like to know the reasons why you believe this patch would be useful. There's one patch I wrote, which I think is a bug in a Makefile for 1.1.4 and 1.1.5 (hence the file name of patch-raddb-Makefile-1.1.4_bug): [...] otppasswd.sample seems to have disappeared from 1.1.4 onwards - is this a bug in that Makefile as I believe? If so, can that be fixed in CVS? Indeed it looks like a bug. I've fixed it in CVS. There's two other things I'm currently modifying the source to achieve, on which I'd appreciate comments. patch-doc::Makefile surrounds the contents of the install target in doc/Makefile with #ifndef NOPORTDOCS ... #endif. FreeBSD ports have to respect this flag. Is a neater way to pass --with-docdir=/dev/null to configure if NOPORTDOCS is defined (which I haven't tried) and abandon the patch. Has anyone any other suggestions? Every downstream distribution has its own mechanism to mark the files as documentation. To install the sample raddb files in the correct location, I'm running sed across all Makefile and Makefile.in files, replacing $(R)$(raddbdir) with the appropriate location. I'd rather do this via configure, but if I use --with-raddbdir, that changes the install location of the files *and* the default location the server looks for those files. The latter change isn't wanted. Every downstream distribution has its own mechanism to handle the config files. I don't know the opinion of the others, but I'm unsure about a configure option that's useful for the FreeBSD port only. -- Nicolas Baradakis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FreeBSD FreeRADIUS port updated to 1.1.5, with various enhancements
Nicolas Baradakis wrote: .. Every downstream distribution has its own mechanism to handle the config files. I don't know the opinion of the others, but I'm unsure about a configure option that's useful for the FreeBSD port only. It's easier to run a port-specific sed script. i.e. This is the first time in 8 years that a request has been made for this feature. It's not critical that it's added to CVS. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
FreeBSD FreeRADIUS port updated to 1.1.5, with various enhancements
Hi all, Whilst this post is mainly aimed at FreeBSD users, I'd be grateful if the developers could cast a glance at the section between the lines of ***. That section contains patches that may be relevant to all FreeRADIUS users and be worth committing to the main FreeRADIUS CVS, also it contains a couple of comments relating to configure. A new version of the FreeBSD FreeRADIUS port has just been committed to the FreeBSD ports tree. Not only is the port now based on FreeRADIUS 1.1.5, there's been various other changes. This has taken rather longer than I'd hoped (pneumonia got in the way - I still don't feel too great), but I hope I've caught up on the backlog of changes people have requested as well as updating the port to 1.1.5. My notes didn't appear in the commit message, and are only in the PR submitting the update. I thought the other changes were worth mentioning here for any discussion and comment. I've gone on a further round of patch removal with this update. Since Alan and the other developers moved to the 'new' build system in 1.1.3, things are much cleaner than was historically the case. Rather than maintaining historic patches, I've chosen to remove them where possible. This seems much better from a maintenance point of view - I would rather have the fewest possible patches, even if I risk breaking things when initially removing a patch. I'd removed the only historic patch that changed the functionality of the server in one of the 1.1.4 releases - from then on, the server you get with the port behaves exactly the same as the server you get if you build FreeRADIUS yourself from source. That patch was pointed out to me as redundant and I had to agree. FreeRADIUS has had with_ntdomain_hack for some time, which allowed for the same end result. This change didn't lead to a single complaint, though it missed the deadline for FreeBSD 6.2-RELEASE (which actually shipped with 1.1.3), so it may be that quite a few users haven't yet caught up with the change. The patches I've removed this time were all build related. I hope I haven't broken the server on non-i386 platforms - if I have, I'm waiting for the PRs, emails of complaint or tinderbox complaining at me! Unfortunately I don't have access to a FreeBSD amd64 box, which is the main non-i386 platform. All I can say is that the server works fine on my FreeBSD 6.2-RELEASE-p2 i386 box, and has done so for a couple of weeks. I was intending to post a candidate port here for more testing (and/or open up my local Subversion repository for public access), but I felt obliged to submit my own update when someone submitted a (slightly flawed) update to 1.1.5 that I refused to approve. If the submitter is reading, you added dictionary.asn to pkg-plist correctly, but failed to add it to the DICTS= line in the Makefile. I may look at changing the Makefile to be more automatic with regard to dictionaries in the future. One group of patches that remain are patches that I believe from the CVS comments are only needed for FreeBSD 4.x. At the moment, I believe files/patch-src-modules-rlm_attr_rewrite-rlm_attr_rewrite.c is only needed for 4.x. The same is true of some of the lines in the port's Makefile. I'm torn as to what to do with these. I don't like gratuitous breakage, but the ports framework no longer supports FreeBSD 4.x, the FreeBSD project regards 4.x as End of Life (whilst it still has its fans, FreeBSD 4.x is quite outdated in various ways), I can't test the server on FreeBSD 4.x and I've had no feedback since 1.1.3 concerning FreeBSD 4.x support. Even if 1.1.4 worked on FreeBSD 4.x, I might have broken FreeBSD 4.x support with the changes I've made in 1.1.5. If that's the case, I'm pretty sure I know which change has broken things, but I'll probably forget pretty soon unless someone complains. I'm now developing the port with the aid of my local Subversion server. This makes tracking my changes rather easier, but even with good log messages, there's limitations on what I can remember after a while. Unless someone contacts me to request otherwise, I'm likely to rip out FreeBSD 4.x support sooner rather than later. It will definitely be removed in any FreeRADIUS 2.x port. My feeling is that I'll probably rip out the 4.x stuff either in a few weeks' time or with the release of a port based on a future FreeRADIUS 1.1.6 release. The second group of patches that remain I'm going to post below - because I think they might be candidates for committing to FreeRADIUS itself. It was clearly felt by previous contributors to the port that the Makefiles don't always contain $(CFLAGS) when they would be expected to. It might be that these patches are also unnecessary with the build system used from 1.1.3 onwards - if so, will someone explain why and I'll remove these patches too. I believe they are still needed judging by the output of make, but I'm willing to be
