The newer versions of gnutls don't ship libgnutls-config any longer and only use pkg-config files; csync2 should update its checking macros.
Created attachment 194765 [details] Build log
I too have this problem with *stable* i686/amd64 systems. I see this bug is blocking bug#253709, so why gnutls-2.8.3 got stable? Since upstream seems not in big hurry adapting the code to recent gnutls versions, please add an "ssl" flag to csync2 ebuild so that we can turn off the ssl stuff in this package (see --disable-gnutls csync2's configure option).
Is this the right patch for it? http://groups.google.com/group/mailing.freebsd.ports-bugs/browse_thread/thread/061882269981af1a?pli=1 Could gentoo maintain an own patchset, as Linbit does not have the resources right now to maintain csync2? There are a few known bugs, but this project seems to be dead too: http://archloss.fr/projets/csync2/index.html (I'm struggling with -C + conflicts getting autoresolved, despitve auto none; in the config)
(In reply to comment #3) > Is this the right patch for it? Yes and no. It would, but ld fails with it because the libgnutls-openssl library invokes some entries from the libgnutls one which are GNUTLS_PRIVATE. Infact, csync2 also needs libgnutls-openssl. A rework about this from upstream would be needed in order to adapt for recent libgnutls versions. That missing, I would strive to at least add a "ssl" flag to the csync2 ebuild. Unfortunately, csync2 is not easily replaceable with something else (like rsync, in example) because it avails of some unique features (merge conflict resolution, external app execution on tree change, etc. etc.).
Our systems rely on csync2 to keep master/slave servers in check. As there is no decent alternative to csync2 that I've found, I have had to mask net-libs/gnutls greater than 2.7.1 so that it won't impact the servers. It's just not an option to live without csync2 here.
Created attachment 204892 [details, diff] Drop gnutls-openssl in favor of native gnutls The attached patch fixes the configure problems with net-libs/gnutls >= 2.7.1 AND drops using the openssl-compatible API in favor of the gnutls native one. PLEASE NOTE. This patch needs to be tested by people having working ssl-enabled csync2 clients and/or servers, since I don't have any handy and the patch is meant to maintain interoperability with previous csync2 versions. The patch had also been posted upstream, in the csync2@lists.linbit.com list.
Created attachment 205047 [details, diff] Drop gnutls-openssl in favor of native gnutls -- v2 In the patch I recently submitted there was a quite blatant bug which caused the storing of and comparison against only half of the peer certificate. This probably caused a regression failure on existing setups (if anybody really attempted to use it ;) ), while new setups could even work. The patch I submit here fixes it. It is meant to be run against csync2-1.34. In order to patch "on the fly" your csync2-1.34 from gentoo, do the following: ebuild $(equery which sys-cluster/csync2) unpack this will unpack the csync2 package in a build directory, which is shown in the last line of the output, like ">>> Source unpacked in /THE/PATH/TO/BUILD/DIR". Then enter into that path and further into the csync2 source package: cd /THE/PATH/TO/BUILD/DIR/csync2-1.34 at this point you may patch the sources. Assuming the patch is stored in /THE/PATCH/DIR/, issue: patch -p1 </THE/PATCH/DIR/csync2-1.34-pure-gnutls.patch You should get this from patch: patching file aclocal.m4 patching file autogen.sh patching file config.h.in patching file configure patching file configure.ac patching file conn.c patching file csync2.c patching file csync2.h patching file daemon.c patching file m4/libgnutls.m4 patching file Makefile.in patching file update.c Then compile and install the patched package: ebuild $(equery which sys-cluster/csync2) install ebuild $(equery which sys-cluster/csync2) qmerge Now you should have a patched csync2 install. After the patch, new setups made with the previous patch may not work anymore. In this case please use the sqlite command to remove the certificate which the previous patch stored into the x509_cert table. The database should be in /var/lib/csync2/ . The new patch had been sent also upstream.
Created attachment 205049 [details, diff] Drop gnutls-openssl in favor of native gnutls -- v2 In the patch I recently submitted there was a quite blatant bug which caused the storing of and comparison against only half of the peer certificate. This probably caused a regression failure on existing setups (if anybody really attempted to use it ;) ), while new setups could even work. The patch I submit here fixes it. It is meant to be run against csync2-1.34. In order to patch "on the fly" your csync2-1.34 from gentoo, do the following: ebuild $(equery which sys-cluster/csync2) unpack this will unpack the csync2 package in a build directory, which is shown in the last line of the output, like ">>> Source unpacked in /THE/PATH/TO/BUILD/DIR". Then enter into that path and further into the csync2 source package: cd /THE/PATH/TO/BUILD/DIR/csync2-1.34 at this point you may patch the sources. Assuming the patch is stored in /THE/PATCH/DIR/, issue: patch -p1 </THE/PATCH/DIR/csync2-1.34-pure-gnutls.patch You should get this from patch: patching file aclocal.m4 patching file autogen.sh patching file config.h.in patching file configure patching file configure.ac patching file conn.c patching file csync2.c patching file csync2.h patching file daemon.c patching file m4/libgnutls.m4 patching file Makefile.in patching file update.c Then compile and install the patched package: ebuild $(equery which sys-cluster/csync2) install ebuild $(equery which sys-cluster/csync2) qmerge Now you should have a patched csync2 install. After the patch, new setups made with the previous patch may not work anymore. In this case please use the sqlite command to remove the certificate which the previous patch stored into the x509_cert table. The database should be in /var/lib/csync2/ . This patch had been sent also upstream. PS: Sorry, previous one was compressed...
Created attachment 206362 [details] ebuild for native gnutls support For those who are as lazy as I am - ebuild and associated patch file. Extract tar in /usr/local/portage - or wherever your portage overlay is. I had to re-create the patch file due to issues with different numbers of directories (slashes) in the names. Thank you very much, Giampaolo, for providing the necessary patches in the first place.
in CVS. thank you
(In reply to comment #10) > in CVS. > > thank you Erm, are we *sure* the patch is ready/suitable for inclusion into portage?? See the comment from Giampaolo: > PLEASE NOTE. > This patch needs to be tested by people having working ssl-enabled csync2 > clients and/or servers, since I don't have any handy and the patch is meant to > maintain interoperability with previous csync2 versions.
It looks like this patch went straight to stable. Unfortunately it's causing segfaults, as noted in #293835.
A new patch that fixes the existing patch has been added to bug#293835 which solves the segfault on sync. I've tested on my machines and it is working well.
Created attachment 210757 [details, diff] Patch substituting the gnutls patch shipped with portage This patch is meant to *substitute* any previously issued csync2-1.34-pure-gnutls*.patch . Urs and Christian, if you can, I think this should be re-distributed ASAP, since people may find problems with the currently ditributed one. You may see it is only 1 byte bigger: it was a single, stupid, missing '&'. Is there any way to have a check to the product before shipment? I'm not an expert about ebuilds.
(In reply to comment #13) > A new patch that fixes the existing patch has been added to bug#293835 which > solves the segfault on sync. I've tested on my machines and it is working well. Adam, your setup was working well before all this patchwork, right? Do you have a server or client running a bare, unpatched csync2? I'm asking this to you to address the "interoperability matter" Wolfram spotted some messages ago.
(In reply to comment #15) Short version: - Before the net-libs/gnutls-2.7.1 update, my csync2 installation was stable and working without fail - After the net-libs/gnutls-2.7.1 update, I could not build csync2 (this bug) and manually masked all versions of net-libs/gnutls after and including 2.7.0 - The recent update to the csync2 ebuild (I'm guess) required it to use net-libs/gnutls greater than my current 2.6.6 version. After unmasking net-libs/gnutls, I updated net-libs/gnutls and rebuild csync2 with no problems. Upon testing (and production use) I found that it segfaulted whenever a sync was performed. With help from another in bug#293835 I was able to get a patched version that worked as expected during sync. I then posted that history here. Long Version: My history with csync2 was as follows: In late 2008 I set up csync2 on 10 machines (which grew to 11) running fully up-to-date gentoo versions (though the kernels remain somewhat old due to never restarting them....). During this time I had no issues with any of the servers running csync2 other than normal csync2 issues (multi-master/many slave type stuff). When gnutls-2.7.1 was stabilized the csync2-1.34 did not work, reporting build errors. That's what this bug represents, obviously. Since I required csync2 to be working, I manually masked all gnutls versions above 2.7.0 in my /etc/portage/packages.mask (I think in that file at least, I'm not around gentoo at the moment). This pushed me back to gnutls-2.6.6 and fixed my csync2 issue. Note: The only software depending on gnutls on our servers was csync2, so downgrading to 2.6.6 was not an issue. This week it seems that the csync2 ebuild updated,and it required a version of gnutls greater than the 2.6.6 I had settled on. Oddly, the csync2 version did not change as it seems it was the patch that bumped it up. I'm only speculating here though as I don't know the full change history. Whatever it was, csync2 wanted to rebuild and had a new greater version dependency. On my dev server (lore) I removed the mask I placed on gnutls and let it perform updates. To my delight csync2 built without error with the gnutls-2.8.4. With this knowledge I unmasked gnutls on all my servers and had them perform their updates as well (since they all failed in our automated routine). Once all machines were updated I started noticing the segfaults coming from my csync2 cron job. I did a few things to try and get things working. The first was to update to the highest version of gnutls I could find, which was 2.8.5 (2.9.8 and 2.9.9 both seem to be hard masked, so says the package list at least). Unfortunately this didn't do anything productive. Around the same time I found bug#293835 which covered the same segfault issue I was having. The second thing I tried to do was try building csync2 without SSL support by using -ssl with the USE environment variable: USE="-ssl" emerge -qv sys-cluster/csync2 That produced a syntax error during compilation (of which I've entered a report on as well). After this I found that someone started helping on bug#293835, which ultimately lead to a patch being produced to fix the issue. Following his instructions it allowed my csync2 installation to work without fail exactly as it had before.
Oh, I forgot, one of my systems did not get updated this week because it's being moved from one building to another. I didn't do it in time for this morning's update because I've been waiting for our weather here in the Seattle area to be less like Seattle area weather :) Anyway, this means that this offline machine likely has an unpatched csync2 ebuild, and is running with gnutls-2.6.6. What I will do when I get back into the office Monday is bring it back up and try syncing with a server running the new version of csync2. I will also try the other direction with the patched csync2 syncing to the unpatched server. I'll let you know what I find.
Thank you Adam, and wave the Space Needle for me. ;)
Created attachment 210768 [details, diff] New version of the shipped patch Ok, occasionally thinks have to go wrong. This seems one of these times. The supplied patch substitutes the one shipped with portage, fixing both the problem with ssl connections and a typo leading to a compile error with USE=-ssl . Urs, if you can, please pack this into a portage package the way you already did, such that I, and possibly Adam, will have a check to it before shipment. Thanks.
(In reply to comment #18) > Thank you Adam, and wave the Space Needle for me. ;) > That might be difficult...it's heavy :)
Just got done with interoperability testing. From my limited testing I was not able to find any interoperability issues between pre and post patch csync2. The un-updated server was running net-libs/gnutls-2.6.6 and the unpatched sys-cluster/csync2-1.34 and the new system is running net-libs/gnutls-2.8.4 with the patched sys-cluster/csync-1.34. I did bidirectional testing where I pushed files to each other in a master/master type mode. SHIP IT! :)
