Last patches for 1.1.0?
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.
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
Nicolas Baradakis <nbk@sitadelle.com> 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.
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 <nbk@sitadelle.com> 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) Paul.Hampson@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 License: http://creativecommons.org/licenses/by/2.1/au/ -----------------------------------------------------------
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
Nicolas Baradakis <nbk@sitadelle.com> 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.
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
Paul TBBle Hampson <Paul.Hampson@Pobox.com> 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.
participants (3)
-
Alan DeKok -
Nicolas Baradakis -
Paul TBBle Hampson