Last patches for 1.1.0?

classic Classic list List threaded Threaded
13 messages Options
| Threaded
Open this post in threaded view
|

Last patches for 1.1.0?

Alan DeKok
  The only thing I can see being relevant is the net-snmp patches, now
in debian/patches.  Odds are other systems need them too, so there's
no reason not to put them into the mainstream.

  Or, should we put them in 1.1.1?  I'd like to have a planned set of
minor features/bug fixes that can go into point releases.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Last patches for 1.1.0?

Fabio Pedretti
I see that in 1.1.0-pre0 there isn't the complete documentation on some options of peap module of eap.conf, while I see it in the CVS:
http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/raddb/eap.conf?rev=1.5&content-type=text/x-cvsweb-markup

Fabio



-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Last patches for 1.1.0?

Nicolas Baradakis
In reply to this post by Alan DeKok
Alan DeKok wrote:

>   The only thing I can see being relevant is the net-snmp patches, now
> in debian/patches.  Odds are other systems need them too, so there's
> no reason not to put them into the mainstream.

I pulled some of the Debian patches in the mainstream CVS, but for 3
of them I was unsure if it was safe to add them between 1.1.0-pre0 and
1.1.0 release. That's why I chose to leave them in debian/patches.

The net-snmp patch may go in 1.1.0, but honestly I don't want to see
the release date delayed just for that.

>   Or, should we put them in 1.1.1?  I'd like to have a planned set of
> minor features/bug fixes that can go into point releases.

If you agree, I'd like to have the upgrade of ltmain.sh in 1.1.1 (also
in debian/patches). I think the libtool upgrade may be useful to other
systems, too.

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Last patches for 1.1.0?

Alan DeKok
Nicolas Baradakis <[hidden email]> wrote:
> I pulled some of the Debian patches in the mainstream CVS, but for 3
> of them I was unsure if it was safe to add them between 1.1.0-pre0 and
> 1.1.0 release. That's why I chose to leave them in debian/patches.

  Ok.

> The net-snmp patch may go in 1.1.0, but honestly I don't want to see
> the release date delayed just for that.

  Sure.  It can go into 1.1.1.

> If you agree, I'd like to have the upgrade of ltmain.sh in 1.1.1 (also
> in debian/patches). I think the libtool upgrade may be useful to other
> systems, too.

  Sounds good to me.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Last patches for 1.1.0?

Nicolas Baradakis
In reply to this post by Fabio Pedretti
Fabio Pedretti wrote:

> I see that in 1.1.0-pre0 there isn't the complete documentation on
> some options of peap module of eap.conf, while I see it in the CVS:
> http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/raddb/eap.conf?rev=1.5&content-type=text/x-cvsweb-markup

Thanks for the report. I've updated the file eap.conf in branch_1_1
of the CVS.

Alan, I think there is a last thing that could be done before 1.1.0.
A few files have wrong access permissions, but I can't change it
with a cvs command line. Can you please run the following command
on the cvs repository?

$ chmod -x /source/radiusd/doc/load-balance.txt,v \
        /source/radiusd/man/man5/rlm_policy.5,v \
        /source/radiusd/man/man5/rlm_sql_log.5,v \
        /source/radiusd/share/dictionary.airespace,v \
        /source/radiusd/src/modules/rlm_ippool/rlm_ippool_tool.c,v

$ chmod +x /source/radiusd/dialup_admin/bin/tot_stats,v \
        /source/radiusd/dialup_admin/bin/monthly_tot_stats,v \
        /source/radiusd/debian/patches/Attic/01_NET-SNMP_build_support.dpatch,v \
        /source/radiusd/debian/patches/Attic/06_libtool14_vs_rlm_eap_tls.dpatch,v

Except this minor detail, there is nothing else I can think of for 1.1.0.
What is the planned date for the release?

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Last patches for 1.1.0?

Alan DeKok
Nicolas Baradakis <[hidden email]> wrote:
> Alan, I think there is a last thing that could be done before 1.1.0.
> A few files have wrong access permissions, but I can't change it
> with a cvs command line. Can you please run the following command
> on the cvs repository?

  OK, those should be fixed, along with a few additional ones in the
"man/man5" directory.

  You'll have to get a fresh checkout to see the permissions change,
though.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Last patches for 1.1.0?

Paul "TBBle" Hampson
In reply to this post by Alan DeKok
Heh, sorry for my absence. My ISP tanked, and four days later I took
over another one, and then somehow went from being a little behind on my
email to two months behind... >_<

Anyway...

On Tue, Jan 03, 2006 at 12:51:59PM -0500, Alan DeKok wrote:
> Nicolas Baradakis <[hidden email]> wrote:
>> I pulled some of the Debian patches in the mainstream CVS, but for 3
>> of them I was unsure if it was safe to add them between 1.1.0-pre0 and
>> 1.1.0 release. That's why I chose to leave them in debian/patches.

>   Ok.

I'll have a look this weekend at what's in 1.1.0. Now that I've actually
skimmed the list rather than just looking at the website, I'm breathing
a sigh of relief that we didn't just roll back the 2.x naming decision.

As it is, it sounds like it won't take ("didn't take Nicolas") much work
to make it build. There're a couple of bugs in the Debian BTS that I
want to address, and last I checked rlm_eap_ttls and rlm_eap_peap were
still not building properly, pulling in the static libeap/rlm_eap_tls
libs instead of linking to the shared libs. However, I'll ignore this
last problem for a Debian upload.

And if I get my ass in gear and become a full DD, I might see about
getting a Sarge backport onto backports.org or similar. (Something else
that suffered due to the new job. -_-)

>> The net-snmp patch may go in 1.1.0, but honestly I don't want to see
>> the release date delayed just for that.

>   Sure.  It can go into 1.1.1.

As I recall, I didn't apply the net-snmp patch to release_1_0 branch
because it choked up some problems with net-snmp (on Fedora Core??)
pulling in incorrect autoconf #defines, and breaking the build. In CVS
HEAD things were rearranged so that none of the .h files pulled in the
net-snmp .h files, only the actual .c files that used them.

It wasn't a problem on Debian partly because the Debian-archive build
doesn't build the SNMP support due to OpenSSL/GPL linkage issues. ^_^

>> If you agree, I'd like to have the upgrade of ltmain.sh in 1.1.1 (also
>> in debian/patches). I think the libtool upgrade may be useful to other
>> systems, too.

>   Sounds good to me.

Keep in mind that this is stolen from the now-defunct Debian libtool1.4
patch, and I make no promises that it'll work on non-glibc platforms. (I
expect it'll work on glibc platforms, but I also don't promise this. ^_^)

Because of this, the libtool upgrade is effectively unmaintained...
Which gives me the screaming heebee geebees, as I can barely follow what
it's doing on a Debian box, let alone guestimating what it's broken on a
Solaris box.

I am kind of hoping 2.x gets releasable in the next six months or so, so
I can get it into Debian/etch (speculatively for release December 2006,
with a final package freeze mid-October) Which means I need to get my
ass in gear with all the neat post-Sarge things I wanted to do to 2.x
(the only ones that come to mind are lsb-init support and debhelper
updates... dbconfig-common scares the bejesus out of me)

--
-----------------------------------------------------------
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[hidden email]

Of course Pacman didn't influence us as kids. If it did,
we'd be running around in darkened rooms, popping pills and
listening to repetitive music.
 -- Kristian Wilson, Nintendo, Inc, 1989

License: http://creativecommons.org/licenses/by/2.1/au/
-----------------------------------------------------------

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html

attachment0 (196 bytes) Download Attachment
| Threaded
Open this post in threaded view
|

Re: Last patches for 1.1.0?

Nicolas Baradakis
Paul TBBle Hampson wrote:

> I'll have a look this weekend at what's in 1.1.0. Now that I've actually
> skimmed the list rather than just looking at the website, I'm breathing
> a sigh of relief that we didn't just roll back the 2.x naming decision.
>
> As it is, it sounds like it won't take ("didn't take Nicolas") much work
> to make it build.

I just did the port of the set of patches you created for the Debian
package 1.0.5-2. I tested the current branch 1.1 of CVS on both sarge
and etch, and it seems to build correctly. (except for rlm_eap_peap
and rlm_eap_ttls)

> There're a couple of bugs in the Debian BTS that I want to address,
> and last I checked rlm_eap_ttls and rlm_eap_peap were still not
> building properly, pulling in the static libeap/rlm_eap_tls libs
> instead of linking to the shared libs.

I think libtool try to link rlm_eap_tls.so to rlm_eap_{peap,ttls}.so
but actually fails to do it because it can't find librlm_eap_tls.so
(with the "lib" prefix) in the *install* directory.

I don't know if we can work around this. More info on:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=335890

> As I recall, I didn't apply the net-snmp patch to release_1_0 branch
> because it choked up some problems with net-snmp (on Fedora Core??)
> pulling in incorrect autoconf #defines, and breaking the build. In CVS
> HEAD things were rearranged so that none of the .h files pulled in the
> net-snmp .h files, only the actual .c files that used them.

Ok, I think we'll definitely leave that for later, after 1.1.0 has
been released.

> Keep in mind that this is stolen from the now-defunct Debian libtool1.4
> patch, and I make no promises that it'll work on non-glibc platforms. (I
> expect it'll work on glibc platforms, but I also don't promise this. ^_^)

It seems to me the changes in ltmain.sh are bugfix only, but I'm not
very sure of it. An other option is to back-port the newer autotools
version from CVS head, but it's a lot more of work...

Either way, it's a post-1.1.0 thing, too.

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Last patches for 1.1.0?

Alan DeKok
Nicolas Baradakis <[hidden email]> wrote:
> I think libtool try to link rlm_eap_tls.so to rlm_eap_{peap,ttls}.so
> but actually fails to do it because it can't find librlm_eap_tls.so
> (with the "lib" prefix) in the *install* directory.

  Yes.  libtool is a piece of shit.

> I don't know if we can work around this.

  See the CVS head.  Move all of the TLS stuff to libeap (where it
really belongs, anyways), and that solves the problem.

  We can do that in 1.1.1.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Last patches for 1.1.0?

Alan DeKok
In reply to this post by Paul "TBBle" Hampson
Paul TBBle Hampson <[hidden email]> wrote:
> As I recall, I didn't apply the net-snmp patch to release_1_0 branch
> because it choked up some problems with net-snmp (on Fedora Core??)
> pulling in incorrect autoconf #defines, and breaking the build.

  Stupid net-snmp.  It installs their "autoconf.h" in a header file
that everyone uses.  So including net-snmp means that suddenly
HAVE_PTHREAD_H is defined, even if you didn't want it.

  I fixed it in the CVS head, and the same fix can be pulled into 1.1.1.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Last patches for 1.1.0?

Nicolas Baradakis
In reply to this post by Alan DeKok
Alan DeKok wrote:

> > I think libtool try to link rlm_eap_tls.so to rlm_eap_{peap,ttls}.so
> > but actually fails to do it because it can't find librlm_eap_tls.so
> > (with the "lib" prefix) in the *install* directory.
>
>   Yes.  libtool is a piece of shit.
>
> > I don't know if we can work around this.
>
>   See the CVS head.  Move all of the TLS stuff to libeap (where it
> really belongs, anyways), and that solves the problem.
>
>   We can do that in 1.1.1.

Sure, that's indeed the best way to solve the problem.

In the meantime I've just figured out what the purpose of the variable
RLM_EAP_LINK_MODE was, so I've created 14_static_rlm_eap_link_mode.dpatch
in branch 1.1 for Debian's sake.

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Last patches for 1.1.0?

Nicolas Baradakis
In reply to this post by Alan DeKok
Alan DeKok wrote:

> Nicolas Baradakis <[hidden email]> wrote:
> > Alan, I think there is a last thing that could be done before 1.1.0.
> > A few files have wrong access permissions, but I can't change it
> > with a cvs command line. Can you please run the following command
> > on the cvs repository?
>
>   OK, those should be fixed, along with a few additional ones in the
> "man/man5" directory.

I didn't see the permissions change in the release 1.1.0 tarball
downloaded from the website. (but it's really a minor detail)

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Last patches for 1.1.0?

Alan DeKok
Nicolas Baradakis <[hidden email]> wrote:
> I didn't see the permissions change in the release 1.1.0 tarball
> downloaded from the website. (but it's really a minor detail)

  Dang.  I'll take a look.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html