Development December 2024

development@lists.ipfire.org

2 participants
4 discussions

Failure building collectd when autoconf has been updated to 2.72
by Adolf Belka 03 Dec '24

03 Dec '24

Hi All, I did an update run with autoconf taking it from 2.71 to 2.72 autoconf built without any problems, however collectd then failed for a syntax error in the configure file. Confirmed that this was due to autoconf by changing the versions back and forward and the problem went away and then came back again. The collectd build error message is checking for size_t... yes checking for uid_t... yes checking for gid_t... yes ./configure: line 18710: syntax error near unexpected token `newline' ./configure: line 18710: `yes:' make: *** [collectd:120: /usr/src/log/collectd-4.10.9] Error 2 The section around line 18710 in the configure file is 18707 do : 18708 as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh` 18709 ac_fn_c_check_header_mongrel "$LINENO" "$ac_header" "$as_ac_Header" "$ac_includes_default" 18710 if eval test \"x\$"$as_ac_Header"\" = x"yes"; then : 18711 cat >>confdefs.h <<_ACEOF 18712 #define `$as_echo "HAVE_$ac_header" | $as_tr_cpp` 1 18713 _ACEOF 18714 18715 else 18716 with_libiptc="no (header file missing)" 18717 fi However there are 15 occurrences of the exact same text as line 18710 in the configure file so I am not convinced if that line is the root cause for the syntax error but some other earlier error that causes a knock-on effect. However, my knowledge of the coding syntax is definitely not enough to figure out what needs to be fixed/changed. As collectd is a very old version it is likely that some structural coding or syntax was fine in the past but now with the change from autoconf-2.71 to 2.72 it is no longer allowed, or is flagged up when in the past it was just ignored. There are quite a few changes in autoconf-2.72 with some being marked as backwards compatibilities. All of them except one say that existing configure scripts will continue working. The one that doesn't mention that is the following change:- Configure scripts no longer support pre-1989 C compilers. Specifically, compilers that *only* implement the original “K&R” function definition syntax, and not the newer “prototyped” syntax, will not be able to parse the test programs now emitted by AC_CHECK_FUNC, AC_LANG_CALL, and similar macros. AC_PROG_CC still accepts such compilers, but this may change in the near future. This change was necessary in order to support the upcoming 2024 edition of the C standard (often referred to as “C23”), which will officially remove the function declaration syntax used by AC_CHECK_FUNC in Autoconf 2.71 and earlier. We feel that support for compilers that support only C 2024 is more useful, nowadays, than support for compilers that don’t implement a core feature of C 1989. However I am unable to figure out from this if the problem I am experiencing is related to this or not. I would not have thought so as I don't believe we are using a pre-1989 C compiler. Any ideas from anyone on how to fix this issue? There is nothing critical from a security or other vulnerability aspect in autoconf-2.72 but it would be nice to figure this out before we get to a stage where it has to be made to work. Regards, Adolf.

2 12

Testing of rapid_commit patch
by Adolf Belka 03 Dec '24

03 Dec '24

Hi Michael, I had previously tested your rapid_commit patch on my vm network system. However as that network does not have a problem with the rapid_commit option it was not the best test. I said that i would test it out on my production system after the visit to my family. I have now got around to that. My new ISP, that bought out the very good technically based ISP I used to have, is one of the ones that has a DHCP server that just times out if you have the rapid_commit option in the dhcpcd config file. So I updated my production IPFire to Core-Update 190 Development Build: master/1e2abd66 After rebooting the connection was lost as the rapid_commit option is on by default. I then ran the setup program and unchecked the rapid commit box on the red interface and then rebooted and the connection was running. Another reboot still had the connection running. So I can confirm that the patch is working . The only thing that came to mind is when we do the update people who have removed or commented out the rapid_commit option in dhcpcd.conf will lose their connection. So either * we need to have the update check if the rapid_commit option has been commented out or has been removed and then disable the rapid commit option for the red interface. or * we need to make sure that it is well communicated that anyone who has disabled the rapid_commit option needs to run the setup program after the upgrade (maybe before the reboot) to disable the option for the red interface. We can discuss this at our next conf call meeting on 3rd or 4th Dec. Regards, Adolf.

3 8

Re: IPFire 2.29 - Core Update 190 is available for testing
by Adolf Belka 03 Dec '24

03 Dec '24

Hi All, First feedback on CU190 Testing. I have not found any problems so far. I have tested the OpenVPN roadwarrior and net2net connections and all worked well. I also cleared the x509 certificate set and created from new (as there were problems in the past with that) and a new x509 set could be created without any issues. Restore from previous backup also worked without any issues. All graphs look to be running okay. Bug13029 - IPSec problem when PSK had a comma in it was tested and the base64 encoding is working as intended. Existing PSK's stay as they are. If a new PSK is defined or an existing one edited then the PSK is base64 encoded. In all cases the operation continues with the base64 encoding changes being totally transparent. A PSK with any character, except the single quotation mark, can now be used in the PSK. Tested out with a PSK with back ticks, hash symbol and double quotation marks and the IPSec PSK connection was made without any issues. Bug13074 verified to now have the collectd.d directory for custom variations. Actual custom variations not tested so far. Bug13762 ssh login details not being shown in system logs verified to be fixed. Both sshd and sshd-session lines from the logs are now included in the system logs display. Will continue testing but so far looks very good to me. Regards, Adolf. On 30/11/2024 15:37, IPFire Project wrote: > Dear Community, It is time for the last push of the year: The upcoming > release of IPFire is ready to be tested by you, our awesome community. > It comes with a refreshed kernel and includes a lot of changes that have > been developed at the recent IPFire Developer Meetup. It is scheduled to > be the last update for the year, so let's make it an extra special one > before we all sign off for the holidays. > ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ ‌ > > > IPFire_ > > > IPFire 2.29 - Core Update 190 is available for testing > > Dear Community, It is time for the last push of the year: The upcoming > release of IPFire is ready to be tested by you, our awesome community. > It comes with a refreshed kernel and includes a lot of changes that have > been developed at the recent IPFire Developer Meetup. It is scheduled to > be the last update for the year, so let's make it an extra special one > before we all sign off for the holidays. > > Read The Full Post On Our Blog <https://www.ipfire.org/blog/ipfire-2-29- > core-update-190-is-available-for-testing? > utm_medium=email&utm_source=blog-announcement> > > The IPFire Project, c/o Lightning Wire Labs GmbH, Gerhardstraße 8, 45711 > Datteln, Germany > > Unsubscribe <https://www.ipfire.org/unsubscribe> > -- Sent from my laptop

1 0

Changing date for the upcoming December Video Call
by Michael Tremer 02 Dec '24

02 Dec '24

Hello everyone, Next week we have the monthly video call scheduled for December 2nd. Sadly I have a conflict at that time and won’t be able to make it, so I would like to propose the 3rd or 4th as an alternative date. Could we have a quick round of raising hands who is available on these alternative dates? Best, -Michael

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Development December 2024