Last patches for 1.1.0?

Paul TBBle Hampson Paul.Hampson at
Thu Jan 5 09:45:35 CET 2006

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... >_<


On Tue, Jan 03, 2006 at 12:51:59PM -0500, Alan DeKok wrote:
> Nicolas Baradakis <nbk at> 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 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 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)
Paul.Hampson at Pobox.Com

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the Freeradius-Devel mailing list